diff --git a/.azure-pipelines/azure-pipelines.yml b/.azure-pipelines/azure-pipelines.yml index 721fa82a58c..399da3180bb 100644 --- a/.azure-pipelines/azure-pipelines.yml +++ b/.azure-pipelines/azure-pipelines.yml @@ -46,7 +46,6 @@ stages: targets: - test: 1 - test: 2 - - test: 3 - stage: Units dependsOn: [] jobs: diff --git a/.azure-pipelines/commands/sanity.sh b/.azure-pipelines/commands/sanity.sh index 78046f65e1a..10c1968c277 100755 --- a/.azure-pipelines/commands/sanity.sh +++ b/.azure-pipelines/commands/sanity.sh @@ -16,14 +16,8 @@ group2_include=( validate-modules ) -group3_include=( - docs-build - sanity-docs -) - group1_exclude=( "${group2_include[@]}" - "${group3_include[@]}" ) options=() @@ -39,11 +33,6 @@ case "${group}" in options+=(--test "${name}") done ;; - 3) - for name in "${group3_include[@]}"; do - options+=(--test "${name}") - done - ;; esac # shellcheck disable=SC2086 diff --git a/.github/BOTMETA.yml b/.github/BOTMETA.yml index d9346a9b933..7000d29d2ee 100644 --- a/.github/BOTMETA.yml +++ b/.github/BOTMETA.yml @@ -59,20 +59,6 @@ files: .github/BOTMETA.yml: labels: botmeta support: core - docs/: - maintainers: - - acozine - docs/docsite/rst/community/: - maintainers: - - gundalow - docs/docsite/rst/dev_guide/: - maintainers: - - gundalow - docs/docsite/rst/network/: - labels: networking - maintainers: - - samccann - docs/docsite/rst/user_guide/windows: *id001 hacking/report.py: notified: mattclay hacking/shippable/: diff --git a/MANIFEST.in b/MANIFEST.in index 89009b04dd7..929b627fd37 100644 --- a/MANIFEST.in +++ b/MANIFEST.in @@ -1,40 +1,10 @@ include COPYING include SYMLINK_CACHE.json include requirements.txt -recursive-include docs * -include docs/docsite/rst/collections/all_plugins.rst -exclude docs/docsite/rst_warnings -exclude docs/docsite/rst/conf.py -exclude docs/docsite/rst/index.rst -exclude docs/docsite/rst/dev_guide/index.rst -exclude docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst -exclude docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst -exclude docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst -exclude docs/docsite/rst/dev_guide/testing/sanity/release-names.rst -recursive-exclude docs/docsite/_build * -recursive-exclude docs/docsite/_extensions *.pyc *.pyo -include examples/hosts -include examples/ansible.cfg -include examples/scripts/ConfigureRemotingForAnsible.ps1 -include examples/scripts/upgrade_to_ps3.ps1 -include lib/ansible/keyword_desc.yml -recursive-include lib/ansible/executor/powershell *.ps1 -recursive-include lib/ansible/module_utils/csharp *.cs -recursive-include lib/ansible/module_utils/powershell *.psm1 -recursive-include lib/ansible/modules/windows *.ps1 -recursive-include lib/ansible/galaxy/data *.yml *.j2 README.md ansible.cfg inventory .git_keep -recursive-include lib/ansible/config *.yml -recursive-include lib/ansible/modules *.yml -recursive-include lib/ansible/plugins/test *.yml -recursive-include lib/ansible/plugins/filter *.yml recursive-include licenses *.txt -recursive-include packaging Makefile *.py *.j2 +recursive-include packaging *.py *.j2 recursive-include test/ansible_test *.py Makefile recursive-include test/integration * -recursive-include test/lib/ansible_test/config *.yml *.template -recursive-include test/lib/ansible_test/_data *.cfg *.in *.ini *.ps1 *.txt *.yml coveragerc -recursive-include test/lib/ansible_test/_util *.cfg *.ini *.json *.ps1 *.psd1 *.py *.sh *.txt *.yml -recursive-include test/lib/ansible_test/_util/controller/sanity/validate-modules validate-modules recursive-include test/sanity *.in *.json *.py *.txt recursive-include test/support *.py *.ps1 *.psm1 *.cs *.md exclude test/sanity/code-smell/botmeta.* @@ -42,13 +12,9 @@ exclude test/sanity/code-smell/release-names.* exclude test/lib/ansible_test/_internal/commands/sanity/bin_symlinks.py exclude test/lib/ansible_test/_internal/commands/sanity/integration_aliases.py recursive-include test/units * -include Makefile include MANIFEST.in include changelogs/CHANGELOG*.rst include changelogs/changelog.yaml -recursive-include hacking/build_library *.py -include hacking/build-ansible.py -include hacking/templates/*.j2 include hacking/test-module.py include hacking/update-sanity-requirements.py include bin/* diff --git a/Makefile b/Makefile deleted file mode 100644 index 1b72ea822b4..00000000000 --- a/Makefile +++ /dev/null @@ -1,157 +0,0 @@ -# WARN: gmake syntax -######################################################## -# Makefile for Ansible -# -# useful targets: -# make clean ---------------- clean up -# make sdist ---------------- produce a tarball -# make tests ---------------- run the tests (see https://docs.ansible.com/ansible/devel/dev_guide/testing_units.html for requirements) - -######################################################## -# variable section - -NAME = ansible-core -OS = $(shell uname -s) -PREFIX ?= '/usr/local' -SDIST_DIR ?= 'dist' - -# This doesn't evaluate until it's called. The -D argument is the -# directory of the target file ($@), kinda like `dirname`. -MANPAGES ?= $(patsubst %.rst.in,%,$(wildcard ./docs/man/man1/ansible*.1.rst.in)) -ifneq ($(shell command -v rst2man 2>/dev/null),) -ASCII2MAN = rst2man $< $@ -else ifneq ($(shell command -v rst2man.py 2>/dev/null),) -ASCII2MAN = rst2man.py $< $@ -else -ASCII2MAN = @echo "ERROR: rst2man from docutils command is not installed but is required to build $(MANPAGES)" && exit 1 -endif - -PYTHON ?= python -GENERATE_CLI = packaging/pep517_backend/_generate_man.py - -# fetch version from project release.py as single source-of-truth -VERSION := $(shell $(PYTHON) packaging/release/versionhelper/version_helper.py --raw || echo error) -ifeq ($(findstring error,$(VERSION)), error) -$(error "version_helper failed") -endif - -# ansible-test parameters -ANSIBLE_TEST ?= bin/ansible-test -TEST_FLAGS ?= - -# ansible-test units parameters (make test / make test-py3) -PYTHON_VERSION ?= $(shell python2 -c 'import sys; print("%s.%s" % sys.version_info[:2])') -PYTHON3_VERSION ?= $(shell python3 -c 'import sys; print("%s.%s" % sys.version_info[:2])') - -# ansible-test integration parameters (make integration) -IMAGE ?= centos7 -TARGET ?= - -######################################################## - -.PHONY: all -all: clean python - -.PHONY: tests -tests: - $(ANSIBLE_TEST) units -v --python $(PYTHON_VERSION) $(TEST_FLAGS) - -.PHONY: tests-py3 -tests-py3: - $(ANSIBLE_TEST) units -v --python $(PYTHON3_VERSION) $(TEST_FLAGS) - -.PHONY: integration -integration: - $(ANSIBLE_TEST) integration -v --docker $(IMAGE) $(TARGET) $(TEST_FLAGS) - -# Regenerate %.1.rst if %.1.rst.in has been modified more -# recently than %.1.rst. -%.1.rst: %.1.rst.in - sed "s/%VERSION%/$(VERSION)/" $< > $@ - rm $< - -# Regenerate %.1 if %.1.rst or release.py has been modified more -# recently than %.1. (Implicitly runs the %.1.rst recipe) -%.1: %.1.rst lib/ansible/release.py - $(ASCII2MAN) - -.PHONY: clean -clean: - @echo "Cleaning up distutils stuff" - rm -rf build - rm -rf dist - rm -rf lib/ansible*.egg-info/ - @echo "Cleaning up byte compiled python stuff" - find . -type f -regex ".*\.py[co]$$" -delete - find . -type d -name "__pycache__" -delete - @echo "Cleaning up editor backup files" - find . -type f -not -path ./test/units/inventory_test_data/group_vars/noparse/all.yml~ \( -name "*~" -or -name "#*" \) -delete - find . -type f \( -name "*.swp" \) -delete - @echo "Cleaning up manpage stuff" - find ./docs/man -type f -name "*.xml" -delete - find ./docs/man -type f -name "*.rst" -delete - find ./docs/man/man3 -type f -name "*.3" -delete - rm -f ./docs/man/man1/* - @echo "Cleaning up output from test runs" - rm -rf test/test_data - rm -rf logs/ - rm -rf .cache/ - rm -f test/units/.coverage* - rm -rf test/results/*/* - find test/ -type f -name '*.retry' -delete - @echo "Cleaning up symlink cache" - rm -f SYMLINK_CACHE.json - rm -rf docs/json - rm -rf docs/js - @echo "Cleaning up docsite" - $(MAKE) -C docs/docsite clean - -.PHONY: python -python: - $(PYTHON) setup.py build - -.PHONY: install -install: - $(PYTHON) setup.py install - -.PHONY: install_manpages -install_manpages: - gzip -9 $(wildcard ./docs/man/man1/ansible*.1) - cp $(wildcard ./docs/man/man1/ansible*.1.gz) $(PREFIX)/man/man1/ - -.PHONY: sdist_check -sdist_check: - $(PYTHON) -c 'import setuptools, sys; sys.exit(int(not (tuple(map(int, setuptools.__version__.split("."))) > (39, 2, 0))))' - $(PYTHON) packaging/sdist/check-link-behavior.py - -.PHONY: sdist -sdist: sdist_check clean docs - _ANSIBLE_SDIST_FROM_MAKEFILE=1 $(PYTHON) setup.py sdist --dist-dir=$(SDIST_DIR) - -# Official releases generate the changelog as the last commit before the release. -# Snapshots shouldn't result in new checkins so the changelog is generated as -# part of creating the tarball. -.PHONY: snapshot -snapshot: sdist_check clean docs changelog - _ANSIBLE_SDIST_FROM_MAKEFILE=1 $(PYTHON) setup.py sdist --dist-dir=$(SDIST_DIR) - -.PHONY: sdist_upload -sdist_upload: clean docs - $(PYTHON) setup.py sdist upload 2>&1 |tee upload.log - -.PHONY: changelog -changelog: - PYTHONPATH=./lib antsibull-changelog release -vv --use-ansible-doc && PYTHONPATH=./lib antsibull-changelog generate -vv --use-ansible-doc - -.PHONY: generate_rst -generate_rst: lib/ansible/cli/*.py - mkdir -p ./docs/man/man1/ ; \ - $(PYTHON) $(GENERATE_CLI) --template-file=packaging/pep517_backend/_templates/man.j2 --output-dir=docs/man/man1/ --output-format man lib/ansible/cli/*.py - -.PHONY: docs -docs: generate_rst - $(MAKE) $(MANPAGES) - -.PHONY: version -version: - @echo $(VERSION) diff --git a/changelogs/fragments/ansible-test-minimum-setuptools.yml b/changelogs/fragments/ansible-test-minimum-setuptools.yml new file mode 100644 index 00000000000..9c7fbeebc77 --- /dev/null +++ b/changelogs/fragments/ansible-test-minimum-setuptools.yml @@ -0,0 +1,2 @@ +minor_changes: + - The minimum required ``setuptools`` version is now 45.2.0, as it is the oldest version to support Python 3.10. diff --git a/changelogs/fragments/fix-setuptools-warnings.yml b/changelogs/fragments/fix-setuptools-warnings.yml new file mode 100644 index 00000000000..7be3f528497 --- /dev/null +++ b/changelogs/fragments/fix-setuptools-warnings.yml @@ -0,0 +1,2 @@ +minor_changes: + - Use ``package_data`` instead of ``include_package_data`` for ``setup.cfg`` to avoid ``setuptools`` warnings. diff --git a/changelogs/fragments/omit-man-pages-from-sdist.yml b/changelogs/fragments/omit-man-pages-from-sdist.yml new file mode 100644 index 00000000000..da32843b3ce --- /dev/null +++ b/changelogs/fragments/omit-man-pages-from-sdist.yml @@ -0,0 +1,4 @@ +minor_changes: + - The ``ansible-core`` sdist no longer contains pre-generated man pages. + Instead, a ``packaging/cli-doc/build.py`` script is included in the sdist. + This script can generate man pages and standalone RST documentation for ``ansible-core`` CLI programs. diff --git a/docs/bin/find-plugin-refs.py b/docs/bin/find-plugin-refs.py deleted file mode 100755 index d603409d688..00000000000 --- a/docs/bin/find-plugin-refs.py +++ /dev/null @@ -1,85 +0,0 @@ -#!/usr/bin/env python - -# To run this script, first make webdocs in the toplevel of the checkout. This will generate all -# rst files from their sources. Then run this script ./docs/bin/find-plugin-refs.py -# -# No output means that there are no longer any bare module and plugin names referenced via :ref: -# -# For my listing of what needs to be changed after running this script, see the comment at the end -# of the file - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import glob -import os -import re - -from ansible.module_utils._text import to_text - - -TOPDIR = os.path.join(os.path.dirname(__file__), '..', 'docsite', 'rst') - - -def plugin_names(topdir): - plugins = set() - - # Modules are in a separate directory - for module_filename in glob.glob(os.path.join(topdir, 'modules', '*_module.rst')): - module_filename = os.path.basename(module_filename) - module_name = module_filename[:module_filename.index('_module.rst')] - plugins.add(module_name) - - for plugin_filename in glob.glob(os.path.join(topdir, 'plugins', '*', '*.rst')): - plugin_filename = os.path.basename(plugin_filename) - plugin_name = plugin_filename[:plugin_filename.index('.rst')] - plugins.add(plugin_name) - - return plugins - - -def process_refs(topdir, plugin_names): - REF_RE = re.compile(':ref:`([^`]*)`') - LABEL_RE = re.compile('<([^>]*)>$') - - # Walk the whole docs tree looking for :ref:. Anywhere those are found, search for `([^`]*)` - for dirpath, dirnames, filenames in os.walk(topdir): - for filename in filenames: - with open(os.path.join(dirpath, filename), 'rb') as f: - data = f.read() - data = to_text(data) - for ref_match in re.finditer(REF_RE, data): - label = ref_match.group(1) - - # If the ref label includes "<", then search for the label inside of the "<>" - label_match = re.search(LABEL_RE, label) - if label_match: - label = label_match.group(1) - - # If the ref label is listed in plugins, then print that the file contains an unported ref - if label in plugin_names: - print(':ref:`{0}` matching plugin {1} was found in {2}'.format(ref_match.group(1), label, os.path.join(dirpath, filename))) - - -if __name__ == '__main__': - - plugins = plugin_names(TOPDIR) - - process_refs(TOPDIR, plugins) - - # Fixes needed: docs/bin/plugin_formatter.py - # - t = _MODULE.sub(r":ref:`\1 <\1>`", t) - # + t = _MODULE.sub(r":ref:`\1 `", t) - # - # These have @{module}@ in the template and need to have something like module_@{module}@ - # If any of these list plugins as well as modules, they will need to have a conditional or extra - # data passed in to handle that in a generic fashion: - # - # docs/templates/list_of_CATEGORY_modules.rst.j2 - # docs/templates/list_of_CATEGORY_plugins.rst.j2 - # docs/templates/modules_by_support.rst.j2 - # - # These are just a simple manual fix: - # :ref:`command` matching plugin command was found in ./../docsite/rst/user_guide/intro_adhoc.rst - # :ref:`shell` matching plugin shell was found in ./../docsite/rst/user_guide/intro_adhoc.rst - # :ref:`config` matching plugin config was found in ./../docsite/rst/installation_guide/intro_configuration.rst diff --git a/docs/bin/testing_formatter.sh b/docs/bin/testing_formatter.sh deleted file mode 100755 index f3a41e12d41..00000000000 --- a/docs/bin/testing_formatter.sh +++ /dev/null @@ -1,42 +0,0 @@ -#!/bin/sh - -set -eux - -FILENAME=../docsite/rst/dev_guide/testing/sanity/index.rst - -cat <<- EOF >$FILENAME.new -.. _all_sanity_tests: - -Sanity Tests -============ - -The following sanity tests are available as \`\`--test\`\` options for \`\`ansible-test sanity\`\`. -This list is also available using \`\`ansible-test sanity --list-tests --allow-disabled\`\`. - -For information on how to run these tests, see :ref:\`sanity testing guide \`. - -.. toctree:: - :maxdepth: 1 - -$(for test in $(../../bin/ansible-test sanity --list-tests --allow-disabled); do echo " ${test}"; done) - -EOF - -# By default use sha1sum which exists on Linux, if not present select the correct binary -# based on platform defaults -SHA_CMD="sha1sum" -if ! command -v ${SHA_CMD} > /dev/null 2>&1; then - if command -v sha1 > /dev/null 2>&1; then - SHA_CMD="sha1" - elif command -v shasum > /dev/null 2>&1; then - SHA_CMD="shasum" - else - # exit early with an error if no hashing binary can be found since it is required later - exit 1 - fi -fi - -# Put file into place if it has changed -if [ ! -f "${FILENAME}" ] || [ "$(${SHA_CMD} <$FILENAME)" != "$(${SHA_CMD} <$FILENAME.new)" ]; then - mv -f $FILENAME.new $FILENAME -fi diff --git a/docs/docsite/.gitignore b/docs/docsite/.gitignore deleted file mode 100644 index 8fade815d19..00000000000 --- a/docs/docsite/.gitignore +++ /dev/null @@ -1,19 +0,0 @@ -# Old compiled python stuff -*.py[co] -# package building stuff -build -# Emacs backup files... -*~ -.\#* -.doctrees -# Generated docs stuff -ansible*.xml -.buildinfo -objects.inv -.doctrees -rst/dev_guide/testing/sanity/index.rst -rst/modules/*.rst -rst/playbooks_keywords.rst -rst/collections/ - -*.min.css diff --git a/docs/docsite/.nojekyll b/docs/docsite/.nojekyll deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/docs/docsite/.templates/banner.html b/docs/docsite/.templates/banner.html deleted file mode 100644 index 698870fedc1..00000000000 --- a/docs/docsite/.templates/banner.html +++ /dev/null @@ -1,77 +0,0 @@ -{% if is_eol %} -{# Creates a banner at the top of the page for EOL versions. #} - -{% else %} - -{% endif %} diff --git a/docs/docsite/.templates/breadcrumbs.html b/docs/docsite/.templates/breadcrumbs.html deleted file mode 100644 index de006f65aa2..00000000000 --- a/docs/docsite/.templates/breadcrumbs.html +++ /dev/null @@ -1,52 +0,0 @@ -{%- extends "!breadcrumbs.html" %} -{%- block breadcrumbs_aside %} -
  • - {%- if hasdoc(pagename) and display_vcs_links %} - {%- if display_github %} - {%- if check_meta and 'github_url' in meta %} - - {{ _('Edit on GitHub') }} - {%- else %} - - {% if check_meta and pagename.endswith(( - '_module', '_become', '_cache', '_callback', - '_connection', '_inventory', '_lookup', - '_shell', '_strategy', '_vars', - )) %} - {# {{ _('Edit on GitHub') }} #} -
    - - {% elif pagename == 'index' %} -
    - - {% elif pagename.startswith('collections/') %} -
    - - {% elif check_meta and pagename.startswith('cli') and meta.get('source', None) %} - {{ _('Edit on GitHub') }} - {% elif (not 'list_of' in pagename) and (not 'category' in pagename) %} - {{ _('Edit on GitHub') }} - {% endif %} - {%- endif %} - {%- elif display_bitbucket %} - {%- if check_meta and 'bitbucket_url' in meta %} - - {{ _('Edit on Bitbucket') }} - {%- else %} - {{ _('Edit on Bitbucket') }} - {%- endif %} - {%- elif display_gitlab %} - {%- if check_meta and 'gitlab_url' in meta %} - - {{ _('Edit on GitLab') }} - {%- else %} - {{ _('Edit on GitLab') }} - {%- endif %} - {%- elif show_source and source_url_prefix %} - {{ _('View page source') }} - {%- elif show_source and has_source and sourcename %} - {{ _('View page source') }} - {%- endif %} - {%- endif %} -
    • -{%- endblock %} diff --git a/docs/docsite/.templates/version_chooser.html b/docs/docsite/.templates/version_chooser.html deleted file mode 100644 index c32a6ba5398..00000000000 --- a/docs/docsite/.templates/version_chooser.html +++ /dev/null @@ -1,4 +0,0 @@ -{# https://jinja.palletsprojects.com/en/3.0.x/tricks/#null-default-fallback #} -{%- if not is_eol %} - {%- extends "!version_chooser.html" %} -{%- endif %} diff --git a/docs/docsite/Makefile b/docs/docsite/Makefile deleted file mode 100644 index f8e87590984..00000000000 --- a/docs/docsite/Makefile +++ /dev/null @@ -1,220 +0,0 @@ -OS := $(shell uname -s) -PLUGIN_FORMATTER=../../hacking/build-ansible.py docs-build -TESTING_FORMATTER=../bin/testing_formatter.sh -KEYWORD_DUMPER=../../hacking/build-ansible.py document-keywords -CONFIG_DUMPER=../../hacking/build-ansible.py document-config -GENERATE_CLI=../../hacking/build-ansible.py generate-man -COLLECTION_DUMPER=../../hacking/build-ansible.py collection-meta -ifeq ($(shell echo $(OS) | egrep -ic 'Darwin|FreeBSD|OpenBSD|DragonFly'),1) -CPUS ?= $(shell sysctl hw.ncpu|awk '{print $$2}') -else -CPUS ?= $(shell nproc) -endif - -# Intenationalisation and Localisation -LANGUAGES ?= - -# Sets the build output directory for the main docsite if it's not already specified -ifndef BUILDDIR - BUILDDIR = _build -endif - -ifndef POTDIR - POTDIR = $(BUILDDIR)/gettext -endif - -# Backwards compat for separate VARS -PLUGIN_ARGS= -ifdef MODULES -ifndef PLUGINS - PLUGIN_ARGS = -l $(MODULES) -else - PLUGIN_ARGS = -l $(MODULES),$(PLUGINS) -endif -else -ifdef PLUGINS - PLUGIN_ARGS = -l $(PLUGINS) -endif -endif - -ANSIBLE_VERSION_ARGS= -ifdef ANSIBLE_VERSION - ANSIBLE_VERSION_ARGS=--ansible-version=$(ANSIBLE_VERSION) -endif - -DOC_PLUGINS ?= become cache callback cliconf connection httpapi inventory lookup netconf shell strategy vars - -PYTHON ?= python -# fetch version from project release.py as single source-of-truth -VERSION := $(shell $(PYTHON) ../../packaging/release/versionhelper/version_helper.py --raw || echo error) -ifeq ($(findstring error,$(VERSION)), error) -$(error "version_helper failed") -endif - -MAJOR_VERSION := $(shell $(PYTHON) ../../packaging/release/versionhelper/version_helper.py --majorversion || echo error) -ifeq ($(findstring error,$(MAJOR_VERSION)), error) -$(error "version_helper failed to determine major version") -endif - - -assertrst: -ifndef rst - $(error specify document or pattern with rst=somefile.rst) -endif - -all: docs - -docs: htmldocs - -coredocs: core_htmldocs - - -generate_rst: collections_meta config cli keywords plugins testing -core_generate_rst: collections_meta config cli keywords core_plugins testing - -# At the moment localizing the plugins and collections is not required for the ongoing -# localisation effort. It will come at a later time. -gettext_generate_rst: collections_meta config cli keywords testing - -# The following symlinks are necessary to produce two different docsets -# from the same set of rst files (Ansible the package docs, and core docs). -# Symlink the relevant index into place for building Ansible docs -ansible_structure: - # We must have python and python-packaging for the version_helper - # script so use it for version comparison - if $(PYTHON) -c "import sys, packaging.version as p; sys.exit(not p.Version('$(MAJOR_VERSION)') > p.Version('2.10'))" ; then \ - echo "Creating symlinks in ansible_structure"; \ - ln -sf ../rst/ansible_index.rst rst/index.rst; \ - ln -sf ../dev_guide/ansible_index.rst rst/dev_guide/index.rst; \ - ln -sf ../sphinx_conf/ansible_conf.py rst/conf.py; \ - else \ - echo 'Creating symlinks for older ansible in ansible_structure'; \ - ln -sf ../rst/2.10_index.rst rst/index.rst; \ - ln -sf ../sphinx_conf/2.10_conf.py rst/conf.py; \ - fi - -# Symlink the relevant index into place for building core docs -core_structure: - @echo "Creating symlinks in core_structure" - -ln -sf ../rst/core_index.rst rst/index.rst - -ln -sf ../dev_guide/core_index.rst rst/dev_guide/index.rst -# set up the correct core conf.py to use for English vs a translated language -ifdef LANGOPTS - -ln -sf ../sphinx_conf/core_lang_conf.py rst/conf.py -else - -ln -sf ../sphinx_conf/core_conf.py rst/conf.py -endif - -# Symlink the relevant index into place for building core translated docs -gettext_structure: - @echo "Creating symlinks in gettext_structure" - -ln -sf ../rst/core_index.rst rst/index.rst - -ln -sf ../rst/dev_guide/core_index.rst rst/dev_guide/index.rst - -ln -sf ../sphinx_conf/all_conf.py rst/conf.py - -gettext: gettext_structure gettext_generate_rst - CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx gettext - # if msgcat is installed handle all indexes, otherwise use the index from gettext_structure. - -msgcat "$(POTDIR)/core_index.pot" "$(POTDIR)/ansible_index.pot" "$(POTDIR)/2.10_index.pot" > "$(POTDIR)/tmp_index.pot" && mv "$(POTDIR)/tmp_index.pot" "$(POTDIR)/index.pot" - rm "$(POTDIR)/core_index.pot" "$(POTDIR)/ansible_index.pot" "$(POTDIR)/2.10_index.pot" - -generate-po: -ifeq ($(LANGUAGES),) - @echo 'LANGUAGES is not defined. It is mandatory. LANGUAGES should be a comma separated list of languages to support. (Exampe: fr,es)' -else - (cd docs/docsite/; sphinx-intl update -w 0 -d rst/locales -p "$(POTDIR)" -l $(LANGUAGES)) -endif - -needs-translation: -ifeq ($(LANGUAGES),) - @echo 'LANGUAGES is not defined. It is mandatory. LANGUAGES should be a comma separated list of languages to support. (Exampe: fr,es)' -else - (cd docs/docsite/; sphinx-intl stat -d rst/locales -l $(LANGUAGES) | grep -E ' [1-9][0-9]* (fuzzy|untranslated)' | sort) -endif - -htmldocs: ansible_structure generate_rst - CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx html - -core_htmldocs: core_structure core_generate_rst - CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx html - -singlehtmldocs: ansible_structure generate_rst - CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx singlehtml - -core_singlehtmldocs: core_structure core_generate_rst - CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx singlehtml - -# Note: The linkcheckdocs and htmlsingle targets depend on gettext_structure -# because that one does not exclude any rst files in its conf.py. -linkcheckdocs: gettext_structure generate_rst - CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx linkcheck - -htmlsingle: assertrst gettext_structure - sphinx-build -j $(CPUS) -b html -d $(BUILDDIR)/doctrees ./rst $(BUILDDIR)/html rst/$(rst) - @echo "Output is in $(BUILDDIR)/html/$(rst:.rst=.html)" - -webdocs: docs - -#TODO: leaving htmlout removal for those having older versions, should eventually be removed also -clean: - @echo "Cleaning $(BUILDDIR)" - -rm -rf $(BUILDDIR)/doctrees - -rm -rf $(BUILDDIR)/html - -rm -rf htmlout - -rm -rf module_docs - -rm -rf $(BUILDDIR) - -rm -f .buildinfo - -rm -f objects.inv - -rm -rf *.doctrees - @echo "Cleaning up minified css files" - find . -type f -name "*.min.css" -delete - @echo "Cleaning up byte compiled python stuff" - find . -regex ".*\.py[co]$$" -delete - @echo "Cleaning up editor backup files" - find . -type f \( -name "*~" -or -name "#*" \) -delete - find . -type f \( -name "*.swp" \) -delete - @echo "Cleaning up generated rst" - rm -f rst/playbooks_directives.rst - rm -f rst/reference_appendices/config.rst - rm -f rst/reference_appendices/playbooks_keywords.rst - rm -f rst/dev_guide/collections_galaxy_meta.rst - rm -f rst/cli/*.rst - for filename in `ls rst/collections/` ; do \ - if test x"$$filename" != x'all_plugins.rst' ; then \ - rm -rf "rst/collections/$$filename"; \ - fi \ - done - @echo "Cleaning up generated ansible_structure" - find . -type l -delete - @echo "Cleaning up legacy generated rst locations" - rm -rf rst/modules - rm -f rst/plugins/*/*.rst - -.PHONY: docs clean - -collections_meta: ../templates/collections_galaxy_meta.rst.j2 - $(COLLECTION_DUMPER) --template-file=../templates/collections_galaxy_meta.rst.j2 --output-dir=rst/dev_guide/ $(EXTRA_COLLECTION_META_ARGS) ../../lib/ansible/galaxy/data/collections_galaxy_meta.yml - -# TODO: make generate_man output dir cli option -cli: - mkdir -p rst/cli - $(GENERATE_CLI) --template-file=../templates/cli_rst.j2 --output-dir=rst/cli/ --output-format rst $(EXTRA_CLI_DUMPER_ARGS) ../../lib/ansible/cli/*.py - -keywords: ../templates/playbooks_keywords.rst.j2 - $(KEYWORD_DUMPER) --template-dir=../templates --output-dir=rst/reference_appendices/ ../../lib/ansible/keyword_desc.yml $(EXTRA_KEYWORD_DUMPER_ARGS) - -config: ../templates/config.rst.j2 - $(CONFIG_DUMPER) --template-file=../templates/config.rst.j2 --output-dir=rst/reference_appendices/ $(EXTRA_CONFIG_DUMPER_ARGS) ../../lib/ansible/config/base.yml - -plugins: - $(PLUGIN_FORMATTER) full -o rst $(ANSIBLE_VERSION_ARGS) $(EXTRA_PLUGIN_FORMATTER_ARGS) $(PLUGIN_ARGS) - -# This only builds the plugin docs included with ansible-core -core_plugins: - $(PLUGIN_FORMATTER) core -o rst $(EXTRA_PLUGIN_FORMATTER_ARGS) $(PLUGIN_ARGS) - -testing: - $(TESTING_FORMATTER) - -epub: - (CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx epub) diff --git a/docs/docsite/Makefile.sphinx b/docs/docsite/Makefile.sphinx deleted file mode 100644 index 3bae705c6db..00000000000 --- a/docs/docsite/Makefile.sphinx +++ /dev/null @@ -1,26 +0,0 @@ -# Minimal makefile for Sphinx documentation -# - -# You can set these variables from the command line. -SPHINXCONFDIR = rst -LANGOPTS ?= -SPHINXOPTS ?= -j $(CPUS) -n -w rst_warnings -c "$(SPHINXCONFDIR)" $(LANGOPTS) -SPHINXBUILD = sphinx-build -SPHINXPROJ = sdfsdf -SOURCEDIR = rst - -# Sets the build output directory if it's not specified on the command line -ifndef BUILDDIR - BUILDDIR = _build -endif - -# Put it first so that "make" without argument is like "make help". -help: - $(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) - -.PHONY: help Makefile.sphinx - -# Catch-all target: route all unknown targets to Sphinx using the new -# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). -%: Makefile.sphinx - $(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) diff --git a/docs/docsite/README.md b/docs/docsite/README.md deleted file mode 100644 index 4ad565eabe2..00000000000 --- a/docs/docsite/README.md +++ /dev/null @@ -1,26 +0,0 @@ -Ansible documentation -===================== - -This project hosts the source behind the general pages of [docs.ansible.com](https://docs.ansible.com/). Module-specific documentation is hosted in the various collections repositories. See [Ansible Galaxy](https://galaxy.ansible.com/), the list of [Ansible-maintained collections](https://docs.ansible.com/ansible/devel/community/contributing_maintained_collections.html), and the [ansible-collections organization](https://github.com/ansible-collections) for collections sources. - -To create clear, concise, and consistent contributions to Ansible documentation, please refer to the following information. - -Contributions -============= -Contributions to the documentation are welcome. - -The Ansible community produces guidance on contributions, building documentation, and submitting pull requests, which you can find in [Contributing to the Ansible Documentation](https://docs.ansible.com/ansible/latest/community/documentation_contributions.html). - -You can also join the [Docs Working Group](https://github.com/ansible/community/wiki/Docs) and/or the ``#ansible-docs`` IRC channel on [irc.libera.chat](https://libera.chat/) - -Ansible style guide -=================== -Ansible documentation is written in ReStructuredText(RST). The [Ansible style guide](https://docs.ansible.com/ansible/latest/dev_guide/style_guide/index.html#linguistic-guidelines) provides linguistic direction and technical guidelines for working with reStructuredText, in addition to other resources. - -Tools -===== -The Ansible community uses a range of tools and programs for working with Ansible documentation. Learn more about [Other Tools and Programs](https://docs.ansible.com/ansible/latest/community/other_tools_and_programs.html#popular-editors) in the Ansible Community Guide. - -GitHub -====== -[Ansible documentation](https://github.com/ansible/ansible/tree/devel/docs/docsite) is hosted on the Ansible GitHub project and various collection repositories, especially those in the [ansible-collections organization](https://github.com/ansible-collections). For general GitHub workflows and other information, see the [GitHub Guides](https://guides.github.com/). diff --git a/docs/docsite/_static/css/core-color-scheme.css b/docs/docsite/_static/css/core-color-scheme.css deleted file mode 100644 index c61c0b1837f..00000000000 --- a/docs/docsite/_static/css/core-color-scheme.css +++ /dev/null @@ -1,17 +0,0 @@ -.DocSiteProduct-header--core { - background-color: #161b1f; - border-color: #161b1f; -} - -.wy-nav-top, .wy-side-nav-search { - background-color: #161b1f; -} -.wy-nav-side { - background-color: #999999; -} -.wy-menu-vertical header, .wy-menu-vertical p.caption { - color: #161b1f; -} -.ansibleNav ul li a:hover { - color: #161b1f; -} diff --git a/docs/docsite/ansible_2_9.inv b/docs/docsite/ansible_2_9.inv deleted file mode 100644 index 0f726711324..00000000000 Binary files a/docs/docsite/ansible_2_9.inv and /dev/null differ diff --git a/docs/docsite/ansible_6.inv b/docs/docsite/ansible_6.inv deleted file mode 100644 index a03b2b28a2b..00000000000 Binary files a/docs/docsite/ansible_6.inv and /dev/null differ diff --git a/docs/docsite/ansible_7.inv b/docs/docsite/ansible_7.inv deleted file mode 100644 index 4e9556f0591..00000000000 Binary files a/docs/docsite/ansible_7.inv and /dev/null differ diff --git a/docs/docsite/collection-plugins.yml b/docs/docsite/collection-plugins.yml deleted file mode 100644 index 499274b40b8..00000000000 --- a/docs/docsite/collection-plugins.yml +++ /dev/null @@ -1,17 +0,0 @@ -# We also need an example of modules hosted in Automation Hub -# We'll likely move to data hosted in botmeta instead of a standalone file but -# we'll need all of these same details. -module: - purefa_user: - source: 'https://galaxy.ansible.com/' - fqcn: 'purestorage.flasharray' - purefa_vg: - source: 'https://galaxy.ansible.com/' - fqcn: 'purestorage.flasharray' - gcp_compute_firewall_info: - source: 'https://galaxy.ansible.com/' - fqcn: 'google.cloud' -module_utils: - purefa: - source: 'https://galaxy.ansible.com/' - fqcn: 'purestorage.flasharray' diff --git a/docs/docsite/jinja2.inv b/docs/docsite/jinja2.inv deleted file mode 100644 index 37ed7968998..00000000000 Binary files a/docs/docsite/jinja2.inv and /dev/null differ diff --git a/docs/docsite/known_good_reqs.txt b/docs/docsite/known_good_reqs.txt deleted file mode 100644 index 14c968bc2d4..00000000000 --- a/docs/docsite/known_good_reqs.txt +++ /dev/null @@ -1,14 +0,0 @@ -# pip packages required to build docsite -# These requirements drift from test/sanity/code-smell/docs-build.requirements.txt -# only for antsibull-docs minor (bugfix) releases. - -jinja2==3.1.2 -PyYAML==6.0 -resolvelib==0.8.1 -rstcheck==3.5.0 -sphinx == 4.2.0 -sphinx-ansible-theme==0.9.1 -sphinx-notfound-page==0.8.3 -straight.plugin==1.5.0 -antsibull-docs == 1.7.3 # Drifted from CI. currently approved version - diff --git a/docs/docsite/modules.js b/docs/docsite/modules.js deleted file mode 100644 index 103bc2cadb4..00000000000 --- a/docs/docsite/modules.js +++ /dev/null @@ -1,5 +0,0 @@ -function AnsibleModules($scope) { - $scope.modules = []; - - $scope.orderProp = "module"; -} \ No newline at end of file diff --git a/docs/docsite/python2.inv b/docs/docsite/python2.inv deleted file mode 100644 index 7ea2dc1dac2..00000000000 Binary files a/docs/docsite/python2.inv and /dev/null differ diff --git a/docs/docsite/python3.inv b/docs/docsite/python3.inv deleted file mode 100644 index d7ab8c267d9..00000000000 Binary files a/docs/docsite/python3.inv and /dev/null differ diff --git a/docs/docsite/requirements.txt b/docs/docsite/requirements.txt deleted file mode 100644 index dac425dacf7..00000000000 --- a/docs/docsite/requirements.txt +++ /dev/null @@ -1,17 +0,0 @@ -# pip packages required to build docsite -# these requirements are as loosely defined as possible -# if you want known good versions of these dependencies -# use test/sanity/code-smell/docs-build.requirements.txt -# instead - -antsibull-docs >= 1.0.0, < 2.0.0 -docutils -jinja2 -pygments >= 2.10.0 -pyyaml -rstcheck -sphinx -sphinx-notfound-page >= 0.6 -sphinx-intl -sphinx-ansible-theme >= 0.9.1 -resolvelib diff --git a/docs/docsite/rst/2.10_index.rst b/docs/docsite/rst/2.10_index.rst deleted file mode 100644 index 1ff97d0bae0..00000000000 --- a/docs/docsite/rst/2.10_index.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. _ansible_documentation: - -Ansible Documentation -===================== - -About Ansible -````````````` - -Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. - -Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program. - -We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances. - -You can learn more at `AnsibleFest `_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with. - -Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems. - -This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added. - -Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly. - -.. toctree:: - :maxdepth: 2 - :caption: Installation, Upgrade & Configuration - - installation_guide/index - porting_guides/porting_guides - -.. toctree:: - :maxdepth: 2 - :caption: Using Ansible - - user_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Contributing to Ansible - - community/index - -.. toctree:: - :maxdepth: 2 - :caption: Extending Ansible - - dev_guide/index - -.. toctree:: - :glob: - :maxdepth: 1 - :caption: Common Ansible Scenarios - - scenario_guides/cloud_guides - scenario_guides/network_guides - scenario_guides/virt_guides - -.. toctree:: - :maxdepth: 2 - :caption: Network Automation - - network/getting_started/index - network/user_guide/index - network/dev_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Ansible Galaxy - - galaxy/user_guide.rst - galaxy/dev_guide.rst - - -.. toctree:: - :maxdepth: 1 - :caption: Reference & Appendices - - collections/index - collections/all_plugins - reference_appendices/playbooks_keywords - reference_appendices/common_return_values - reference_appendices/config - reference_appendices/general_precedence - reference_appendices/YAMLSyntax - reference_appendices/python_3_support - reference_appendices/interpreter_discovery - reference_appendices/release_and_maintenance - reference_appendices/test_strategies - dev_guide/testing/sanity/index - reference_appendices/faq - reference_appendices/glossary - reference_appendices/module_utils - reference_appendices/special_variables - reference_appendices/tower - reference_appendices/automationhub - reference_appendices/logging - - -.. toctree:: - :maxdepth: 2 - :caption: Release Notes - -.. toctree:: - :maxdepth: 2 - :caption: Roadmaps - - roadmap/index.rst diff --git a/docs/docsite/rst/404.rst b/docs/docsite/rst/404.rst deleted file mode 100644 index 4a869d22667..00000000000 --- a/docs/docsite/rst/404.rst +++ /dev/null @@ -1,12 +0,0 @@ -:orphan: - -***** -Oops! -***** - -The version of the Ansible documentation you were looking at doesn't contain that page. - -.. image:: images/cow.png - :alt: Cowsay 404 - -Use the back button to return to the version you were browsing, or use the navigation at left to explore our latest release. Once you're on a non-404 page, you can use the version-changer to select a version. diff --git a/docs/docsite/rst/ansible_index.rst b/docs/docsite/rst/ansible_index.rst deleted file mode 100644 index 079c7cf605e..00000000000 --- a/docs/docsite/rst/ansible_index.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. _ansible_documentation: -.. - This is the index file for Ansible the package. It gets symlinked to index.rst by the Makefile - -Ansible Documentation -===================== - -About Ansible -````````````` - -Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. - -Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program. - -We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances. - -You can learn more at `AnsibleFest `_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with. - -Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. Also, security exposure is greatly reduced because Ansible uses OpenSSH — the open source connectivity tool for remote login with the SSH (Secure Shell) protocol. - -Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. And if needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems. - -This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and the Ansible documentation, so please be sure you are using the documentation version that covers the version of Ansible you are using. For recent features, we note the version of Ansible where the feature was added. - -Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins hosted in collections since version 2.10 much more quickly. - -.. toctree:: - :maxdepth: 2 - :caption: Ansible getting started - - getting_started/index - -.. toctree:: - :maxdepth: 2 - :caption: Installation, Upgrade & Configuration - - installation_guide/index - porting_guides/porting_guides - -.. toctree:: - :maxdepth: 2 - :caption: Using Ansible - - inventory_guide/index - command_guide/index - playbook_guide/index - vault_guide/index - module_plugin_guide/index - collections_guide/index - os_guide/index - tips_tricks/index - -.. toctree:: - :maxdepth: 2 - :caption: Contributing to Ansible - - community/index - community/contributions_collections - community/contributions - community/advanced_index - dev_guide/style_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Extending Ansible - - dev_guide/index - -.. toctree:: - :glob: - :maxdepth: 1 - :caption: Common Ansible Scenarios - - scenario_guides/cloud_guides - scenario_guides/network_guides - scenario_guides/virt_guides - -.. toctree:: - :maxdepth: 2 - :caption: Network Automation - - network/getting_started/index - network/user_guide/index - network/dev_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Ansible Galaxy - - galaxy/user_guide.rst - galaxy/dev_guide.rst - - -.. toctree:: - :maxdepth: 1 - :caption: Reference & Appendices - - collections/index - collections/all_plugins - reference_appendices/playbooks_keywords - reference_appendices/common_return_values - reference_appendices/config - reference_appendices/general_precedence - reference_appendices/YAMLSyntax - reference_appendices/python_3_support - reference_appendices/interpreter_discovery - reference_appendices/release_and_maintenance - reference_appendices/test_strategies - dev_guide/testing/sanity/index - reference_appendices/faq - reference_appendices/glossary - reference_appendices/module_utils - reference_appendices/special_variables - reference_appendices/tower - reference_appendices/automationhub - reference_appendices/logging - - -.. toctree:: - :maxdepth: 2 - :caption: Roadmaps - - roadmap/ansible_roadmap_index.rst - roadmap/ansible_core_roadmap_index.rst diff --git a/docs/docsite/rst/api/index.rst b/docs/docsite/rst/api/index.rst deleted file mode 100644 index 27afbe42cc3..00000000000 --- a/docs/docsite/rst/api/index.rst +++ /dev/null @@ -1,107 +0,0 @@ -:orphan: - -************************* -Ansible API Documentation -************************* - -The Ansible API is under construction. These stub references for attributes, classes, functions, methods, and modules will be documented in future. -The :ref:`module utilities ` included in ``ansible.module_utils.basic`` and ``AnsibleModule`` are documented under Reference & Appendices. - -.. contents:: - :local: - -Attributes -========== - -.. py:attribute:: AnsibleModule.params - -The parameters accepted by the module. - -.. py:attribute:: ansible.module_utils.basic.ANSIBLE_VERSION - -.. py:attribute:: ansible.module_utils.basic.SELINUX_SPECIAL_FS - -Deprecated in favor of ansibleModule._selinux_special_fs. - -.. py:attribute:: AnsibleModule.ansible_version - -.. py:attribute:: AnsibleModule._debug - -.. py:attribute:: AnsibleModule._diff - -.. py:attribute:: AnsibleModule.no_log - -.. py:attribute:: AnsibleModule._selinux_special_fs - -(formerly ansible.module_utils.basic.SELINUX_SPECIAL_FS) - -.. py:attribute:: AnsibleModule._syslog_facility - -.. py:attribute:: self.playbook - -.. py:attribute:: self.play - -.. py:attribute:: self.task - -.. py:attribute:: sys.path - - -Classes -======= - -.. py:class:: ``ansible.module_utils.basic.AnsibleModule`` - :noindex: - -The basic utilities for AnsibleModule. - -.. py:class:: AnsibleModule - -The main class for an Ansible module. - - -Functions -========= - -.. py:function:: ansible.module_utils.basic._load_params() - -Load parameters. - - -Methods -======= - -.. py:method:: AnsibleModule.log() - -Logs the output of Ansible. - -.. py:method:: AnsibleModule.debug() - -Debugs Ansible. - -.. py:method:: Ansible.get_bin_path() - -Retrieves the path for executables. - -.. py:method:: AnsibleModule.run_command() - -Runs a command within an Ansible module. - -.. py:method:: module.fail_json() - -Exits and returns a failure. - -.. py:method:: module.exit_json() - -Exits and returns output. - - -Modules -======= - -.. py:module:: ansible.module_utils - -.. py:module:: ansible.module_utils.basic - :noindex: - - -.. py:module:: ansible.module_utils.url diff --git a/docs/docsite/rst/collections/all_plugins.rst b/docs/docsite/rst/collections/all_plugins.rst deleted file mode 100644 index 35232f7db63..00000000000 --- a/docs/docsite/rst/collections/all_plugins.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. _all_modules_and_plugins: - -Indexes of all modules and plugins ----------------------------------- - -.. toctree:: - :maxdepth: 1 - :caption: Plugin indexes - :glob: - - index_* diff --git a/docs/docsite/rst/collections_guide/collections_downloading.rst b/docs/docsite/rst/collections_guide/collections_downloading.rst deleted file mode 100644 index ab17ce89412..00000000000 --- a/docs/docsite/rst/collections_guide/collections_downloading.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _collections_downloading: - -Downloading collections -======================= - -To download a collection and its dependencies for an offline install, run ``ansible-galaxy collection download``. This -downloads the collections specified and their dependencies to the specified folder and creates a ``requirements.yml`` -file which can be used to install those collections on a host without access to a Galaxy server. All the collections -are downloaded by default to the ``./collections`` folder. - -Just like the ``install`` command, the collections are sourced based on the -:ref:`configured galaxy server config `. Even if a collection to download was specified by a URL -or path to a tarball, the collection will be redownloaded from the configured Galaxy server. - -Collections can be specified as one or multiple collections or with a ``requirements.yml`` file just like -``ansible-galaxy collection install``. - -To download a single collection and its dependencies: - -.. code-block:: bash - - ansible-galaxy collection download my_namespace.my_collection - -To download a single collection at a specific version: - -.. code-block:: bash - - ansible-galaxy collection download my_namespace.my_collection:1.0.0 - -To download multiple collections either specify multiple collections as command line arguments as shown above or use a -requirements file in the format documented with :ref:`collection_requirements_file`. - -.. code-block:: bash - - ansible-galaxy collection download -r requirements.yml - -You can also download a source collection directory. The collection is built with the mandatory ``galaxy.yml`` file. - -.. code-block:: bash - - ansible-galaxy collection download /path/to/collection - - ansible-galaxy collection download git+file:///path/to/collection/.git - -You can download multiple source collections from a single namespace by providing the path to the namespace. - -.. code-block:: text - - ns/ - ├── collection1/ - │   ├── galaxy.yml - │   └── plugins/ - └── collection2/ - ├── galaxy.yml - └── plugins/ - -.. code-block:: bash - - ansible-galaxy collection install /path/to/ns - -All the collections are downloaded by default to the ``./collections`` folder but you can use ``-p`` or -``--download-path`` to specify another path: - -.. code-block:: bash - - ansible-galaxy collection download my_namespace.my_collection -p ~/offline-collections - -Once you have downloaded the collections, the folder contains the collections specified, their dependencies, and a -``requirements.yml`` file. You can use this folder as is with ``ansible-galaxy collection install`` to install the -collections on a host without access to a Galaxy server. - -.. code-block:: bash - - # This must be run from the folder that contains the offline collections and requirements.yml file downloaded - # by the internet-connected host - cd ~/offline-collections - ansible-galaxy collection install -r requirements.yml \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/collections_index.rst b/docs/docsite/rst/collections_guide/collections_index.rst deleted file mode 100644 index 464db898b86..00000000000 --- a/docs/docsite/rst/collections_guide/collections_index.rst +++ /dev/null @@ -1,6 +0,0 @@ -.. _index_collections: - -Collections index -================= - -You can find an index of collections at :ref:`list_of_collections`. \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/collections_installing.rst b/docs/docsite/rst/collections_guide/collections_installing.rst deleted file mode 100644 index 6ee446aae14..00000000000 --- a/docs/docsite/rst/collections_guide/collections_installing.rst +++ /dev/null @@ -1,126 +0,0 @@ -.. _collections_installing: - -Installing collections -====================== - -.. note:: - - If you install a collection manually as described in this paragraph, the collection will not be upgraded automatically when you upgrade the ``ansible`` package or ``ansible-core``. - -Installing collections with ``ansible-galaxy`` ----------------------------------------------- - -.. include:: ../shared_snippets/installing_collections.txt - -.. _installing_signed_collections: - -Installing collections with signature verification ---------------------------------------------------- - -If a collection has been signed by a :term:`distribution server`, the server will provide ASCII armored, detached signatures to verify the authenticity of the ``MANIFEST.json`` before using it to verify the collection's contents. This option is not available on all distribution servers. See :ref:`distributing_collections` for a table listing which servers support collection signing. - -To use signature verification for signed collections: - -1. :ref:`Configured a GnuPG keyring ` for ``ansible-galaxy``, or provide the path to the keyring with the ``--keyring`` option when you install the signed collection. - - -2. Import the public key from the distribution server into that keyring. - - .. code-block:: bash - - gpg --import --no-default-keyring --keyring ~/.ansible/pubring.kbx my-public-key.asc - - -3. Verify the signature when you install the collection. - - .. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection --keyring ~/.ansible/pubring.kbx - - The ``--keyring`` option is not necessary if you have :ref:`configured a GnuPG keyring `. - -4. Optionally, verify the signature at any point after installation to prove the collection has not been tampered with. See :ref:`verify_signed_collections` for details. - - -You can also include signatures in addition to those provided by the distribution server. Use the ``--signature`` option to verify the collection's ``MANIFEST.json`` with these additional signatures. Supplemental signatures should be provided as URIs. - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --keyring ~/.ansible/pubring.kbx - -GnuPG verification only occurs for collections installed from a distribution server. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files. - -You can also include additional signatures in the collection ``requirements.yml`` file under the ``signatures`` key. - -.. code-block:: yaml - - # requirements.yml - collections: - - name: ns.coll - version: 1.0.0 - signatures: - - https://examplehost.com/detached_signature.asc - - file:///path/to/local/detached_signature.asc - -See :ref:`collection requirements file ` for details on how to install collections with this file. - -By default, verification is considered successful if a minimum of 1 signature successfully verifies the collection. The number of required signatures can be configured with ``--required-valid-signature-count`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. All signatures can be required by setting the option to ``all``. To fail signature verification if no valid signatures are found, prepend the value with ``+``, such as ``+all`` or ``+1``. - -.. code-block:: bash - - export ANSIBLE_GALAXY_GPG_KEYRING=~/.ansible/pubring.kbx - export ANSIBLE_GALAXY_REQUIRED_VALID_SIGNATURE_COUNT=2 - ansible-galaxy collection install my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --signature file:///path/to/local/detached_signature.asc - -Certain GnuPG errors can be ignored with ``--ignore-signature-status-code`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` should be a list, and ``--ignore-signature-status-code`` can be provided multiple times to ignore multiple additional error status codes. - -This example requires any signatures provided by the distribution server to verify the collection except if they fail due to NO_PUBKEY: - -.. code-block:: bash - - export ANSIBLE_GALAXY_GPG_KEYRING=~/.ansible/pubring.kbx - export ANSIBLE_GALAXY_REQUIRED_VALID_SIGNATURE_COUNT=all - ansible-galaxy collection install my_namespace.my_collection --ignore-signature-status-code NO_PUBKEY - -If verification fails for the example above, only errors other than NO_PUBKEY will be displayed. - -If verification is unsuccessful, the collection will not be installed. GnuPG signature verification can be disabled with ``--disable-gpg-verify`` or by configuring :ref:`GALAXY_DISABLE_GPG_VERIFY`. - - -.. _collections_older_version: - -Installing an older version of a collection -------------------------------------------- - -.. include:: ../shared_snippets/installing_older_collection.txt - -.. _collection_requirements_file: - -Install multiple collections with a requirements file ------------------------------------------------------ - -.. include:: ../shared_snippets/installing_multiple_collections.txt - -.. _collection_offline_download: - -Downloading a collection for offline use ------------------------------------------ - -.. include:: ../shared_snippets/download_tarball_collections.txt - -Installing a collection from source files ------------------------------------------ - -.. include:: ../shared_snippets/installing_collections_file.rst - -Installing a collection from a git repository ---------------------------------------------- - -.. include:: ../shared_snippets/installing_collections_git_repo.txt - -.. _galaxy_server_config: - -Configuring the ``ansible-galaxy`` client ------------------------------------------- - -.. include:: ../shared_snippets/galaxy_server_list.txt \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/collections_listing.rst b/docs/docsite/rst/collections_guide/collections_listing.rst deleted file mode 100644 index 03cf125127d..00000000000 --- a/docs/docsite/rst/collections_guide/collections_listing.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _collections_listing: - -Listing collections -=================== - -To list installed collections, run ``ansible-galaxy collection list``. This shows all of the installed collections found in the configured collections search paths. It will also show collections under development which contain a galaxy.yml file instead of a MANIFEST.json. The path where the collections are located are displayed as well as version information. If no version information is available, a ``*`` is displayed for the version number. - -.. code-block:: shell - - # /home/astark/.ansible/collections/ansible_collections - Collection Version - -------------------------- ------- - cisco.aci 0.0.5 - cisco.mso 0.0.4 - sandwiches.ham * - splunk.es 0.0.5 - - # /usr/share/ansible/collections/ansible_collections - Collection Version - ----------------- ------- - fortinet.fortios 1.0.6 - pureport.pureport 0.0.8 - sensu.sensu_go 1.3.0 - -Run with ``-vvv`` to display more detailed information. -You may see additional collections here that were added as dependencies of your installed collections. Only use collections in your playbooks that you have directly installed. - -To list a specific collection, pass a valid fully qualified collection name (FQCN) to the command ``ansible-galaxy collection list``. All instances of the collection will be listed. - -.. code-block:: shell - - > ansible-galaxy collection list fortinet.fortios - - # /home/astark/.ansible/collections/ansible_collections - Collection Version - ---------------- ------- - fortinet.fortios 1.0.1 - - # /usr/share/ansible/collections/ansible_collections - Collection Version - ---------------- ------- - fortinet.fortios 1.0.6 - -To search other paths for collections, use the ``-p`` option. Specify multiple search paths by separating them with a ``:``. The list of paths specified on the command line will be added to the beginning of the configured collections search paths. - -.. code-block:: shell - - > ansible-galaxy collection list -p '/opt/ansible/collections:/etc/ansible/collections' - - # /opt/ansible/collections/ansible_collections - Collection Version - --------------- ------- - sandwiches.club 1.7.2 - - # /etc/ansible/collections/ansible_collections - Collection Version - -------------- ------- - sandwiches.pbj 1.2.0 - - # /home/astark/.ansible/collections/ansible_collections - Collection Version - -------------------------- ------- - cisco.aci 0.0.5 - cisco.mso 0.0.4 - fortinet.fortios 1.0.1 - sandwiches.ham * - splunk.es 0.0.5 - - # /usr/share/ansible/collections/ansible_collections - Collection Version - ----------------- ------- - fortinet.fortios 1.0.6 - pureport.pureport 0.0.8 - sensu.sensu_go 1.3.0 diff --git a/docs/docsite/rst/collections_guide/collections_using_playbooks.rst b/docs/docsite/rst/collections_guide/collections_using_playbooks.rst deleted file mode 100644 index a7665edfe62..00000000000 --- a/docs/docsite/rst/collections_guide/collections_using_playbooks.rst +++ /dev/null @@ -1,119 +0,0 @@ -.. _using_collections: -.. _collections_using_playbook: - -Using collections in a playbook -=============================== - -Once installed, you can reference a collection content by its fully qualified collection name (FQCN): - -.. code-block:: yaml - - - hosts: all - tasks: - - my_namespace.my_collection.mymodule: - option1: value - -This works for roles or any type of plugin distributed within the collection: - -.. code-block:: yaml - - - hosts: all - tasks: - - import_role: - name: my_namespace.my_collection.role1 - - - my_namespace.mycollection.mymodule: - option1: value - - - debug: - msg: '{{ lookup("my_namespace.my_collection.lookup1", 'param1')| my_namespace.my_collection.filter1 }}' - -Simplifying module names with the ``collections`` keyword ---------------------------------------------------------- - -The ``collections`` keyword lets you define a list of collections that your role or playbook should search for unqualified module and action names. So you can use the ``collections`` keyword, then simply refer to modules and action plugins by their short-form names throughout that role or playbook. - -.. warning:: - If your playbook uses both the ``collections`` keyword and one or more roles, the roles do not inherit the collections set by the playbook. This is one of the reasons we recommend you always use FQCN. See below for roles details. - -Using ``collections`` in roles ------------------------------- - -Within a role, you can control which collections Ansible searches for the tasks inside the role using the ``collections`` keyword in the role's ``meta/main.yml``. Ansible will use the collections list defined inside the role even if the playbook that calls the role defines different collections in a separate ``collections`` keyword entry. Roles defined inside a collection always implicitly search their own collection first, so you don't need to use the ``collections`` keyword to access modules, actions, or other roles contained in the same collection. - -.. code-block:: yaml - - # myrole/meta/main.yml - collections: - - my_namespace.first_collection - - my_namespace.second_collection - - other_namespace.other_collection - -Using ``collections`` in playbooks ----------------------------------- - -In a playbook, you can control the collections Ansible searches for modules and action plugins to execute. However, any roles you call in your playbook define their own collections search order; they do not inherit the calling playbook's settings. This is true even if the role does not define its own ``collections`` keyword. - -.. code-block:: yaml - - - hosts: all - collections: - - my_namespace.my_collection - - tasks: - - import_role: - name: role1 - - - mymodule: - option1: value - - - debug: - msg: '{{ lookup("my_namespace.my_collection.lookup1", "param1")| my_namespace.my_collection.filter1 }}' - -The ``collections`` keyword merely creates an ordered 'search path' for non-namespaced plugin and role references. It does not install content or otherwise change Ansible's behavior around the loading of plugins or roles. Note that an FQCN is still required for non-action or module plugins (for example, lookups, filters, tests). - -When using the ``collections`` keyword, it is not necessary to add in ``ansible.builtin`` as part of the search list. When left omitted, the following content is available by default: - -1. Standard ansible modules and plugins available through ``ansible-base``/``ansible-core`` - -2. Support for older 3rd party plugin paths - -In general, it is preferable to use a module or plugin's FQCN over the ``collections`` keyword and the short name for all content in ``ansible-core`` - -Using a playbook from a collection ----------------------------------- - -.. versionadded:: 2.11 - -You can also distribute playbooks in your collection and invoke them using the same semantics you use for plugins: - -.. code-block:: shell - - ansible-playbook my_namespace.my_collection.playbook1 -i ./myinventory - -From inside a playbook: - -.. code-block:: yaml - - - import_playbook: my_namespace.my_collection.playbookX - - -A few recommendations when creating such playbooks, ``hosts:`` should be generic or at least have a variable input. - -.. code-block:: yaml - - - hosts: all # Use --limit or customized inventory to restrict hosts targeted - - - hosts: localhost # For things you want to restrict to the controller - - - hosts: '{{target|default("webservers")}}' # Assumes inventory provides a 'webservers' group, but can also use ``-e 'target=host1,host2'`` - - -This will have an implied entry in the ``collections:`` keyword of ``my_namespace.my_collection`` just as with roles. - -.. note:: - * Playbook names, like other collection resources, have a restricted set of valid characters. - Names can contain only lowercase alphanumeric characters, plus _ and must start with an alpha character. The dash ``-`` character is not valid for playbook names in collections. - Playbooks whose names contain invalid characters are not addressable: this is a limitation of the Python importer that is used to load collection resources. - - * Playbooks in collections do not support 'adjacent' plugins, all plugins must be in the collection specific directories. diff --git a/docs/docsite/rst/collections_guide/collections_verifying.rst b/docs/docsite/rst/collections_guide/collections_verifying.rst deleted file mode 100644 index e3f93d43d4c..00000000000 --- a/docs/docsite/rst/collections_guide/collections_verifying.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _collections_verifying: - -Verifying collections -===================== - -Verifying collections with ``ansible-galaxy`` ---------------------------------------------- - -Once installed, you can verify that the content of the installed collection matches the content of the collection on the server. This feature expects that the collection is installed in one of the configured collection paths and that the collection exists on one of the configured galaxy servers. - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection - -The output of the ``ansible-galaxy collection verify`` command is quiet if it is successful. If a collection has been modified, the altered files are listed under the collection name. - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection - Collection my_namespace.my_collection contains modified content in the following files: - my_namespace.my_collection - plugins/inventory/my_inventory.py - plugins/modules/my_module.py - -You can use the ``-vvv`` flag to display additional information, such as the version and path of the installed collection, the URL of the remote collection used for validation, and successful verification output. - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection -vvv - ... - Verifying 'my_namespace.my_collection:1.0.0'. - Installed collection found at '/path/to/ansible_collections/my_namespace/my_collection/' - Remote collection found at 'https://galaxy.ansible.com/download/my_namespace-my_collection-1.0.0.tar.gz' - Successfully verified that checksums for 'my_namespace.my_collection:1.0.0' match the remote collection - -If you have a pre-release or non-latest version of a collection installed you should include the specific version to verify. If the version is omitted, the installed collection is verified against the latest version available on the server. - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection:1.0.0 - -In addition to the ``namespace.collection_name:version`` format, you can provide the collections to verify in a ``requirements.yml`` file. Dependencies listed in ``requirements.yml`` are not included in the verify process and should be verified separately. - -.. code-block:: bash - - ansible-galaxy collection verify -r requirements.yml - -Verifying against ``tar.gz`` files is not supported. If your ``requirements.yml`` contains paths to tar files or URLs for installation, you can use the ``--ignore-errors`` flag to ensure that all collections using the ``namespace.name`` format in the file are processed. - -.. _verify_signed_collections: - -Verifying signed collections ------------------------------ - -If a collection has been signed by a :term:`distribution server`, the server will provide ASCII armored, detached signatures to verify the authenticity of the MANIFEST.json before using it to verify the collection's contents. This option is not available on all distribution servers. See :ref:`distributing_collections` for a table listing which servers support collection signing. See :ref:`installing_signed_collections` for how to verify a signed collection when you install it. - -To verify a signed installed collection: - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection --keyring ~/.ansible/pubring.kbx - - -Use the ``--signature`` option to verify collection name(s) provided on the CLI with an additional signature. This option can be used multiple times to provide multiple signatures. - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --signature file:///path/to/local/detached_signature.asc --keyring ~/.ansible/pubring.kbx - -Optionally, you can verify a collection signature with a ``requirements.yml`` file. - -.. code-block:: bash - - ansible-galaxy collection verify -r requirements.yml --keyring ~/.ansible/pubring.kbx - -When a collection is installed from a distribution server, the signatures provided by the server to verify the collection's authenticity are saved alongside the installed collections. This data is used to verify the internal consistency of the collection without querying the distribution server again when the ``--offline`` option is provided. - -.. code-block:: bash - - ansible-galaxy collection verify my_namespace.my_collection --offline --keyring ~/.ansible/pubring.kbx \ No newline at end of file diff --git a/docs/docsite/rst/collections_guide/index.rst b/docs/docsite/rst/collections_guide/index.rst deleted file mode 100644 index 04182c9e9cb..00000000000 --- a/docs/docsite/rst/collections_guide/index.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _collections_index: -.. _collections: - -######################### -Using Ansible collections -######################### - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible guide for working with collections. - -Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. -You can install and use collections through a distribution server, such as Ansible Galaxy, or a Pulp 3 Galaxy server. - -.. toctree:: - :maxdepth: 2 - - collections_installing - collections_downloading - collections_listing - collections_verifying - collections_using_playbooks - collections_index \ No newline at end of file diff --git a/docs/docsite/rst/command_guide/cheatsheet.rst b/docs/docsite/rst/command_guide/cheatsheet.rst deleted file mode 100644 index ee141a51937..00000000000 --- a/docs/docsite/rst/command_guide/cheatsheet.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _cheatsheet: - -********************** -Ansible CLI cheatsheet -********************** - -This page shows one or more examples of each Ansible command line utility with some common flags added and a link to the full documentation for the command. -This page offers a quick reminder of some common use cases only - it may be out of date or incomplete or both. -For canonical documentation, follow the links to the CLI pages. - -.. contents:: - :local: - -ansible-playbook -================ - -.. code-block:: bash - - ansible-playbook -i /path/to/my_inventory_file -u my_connection_user -k -f 3 -T 30 -t my_tag -m /path/to/my_modules -b -K my_playbook.yml - -Loads ``my_playbook.yml`` from the current working directory and: - - ``-i`` - uses ``my_inventory_file`` in the path provided for :ref:`inventory ` to match the :ref:`pattern `. - - ``-u`` - connects :ref:`over SSH ` as ``my_connection_user``. - - ``-k`` - asks for password which is then provided to SSH authentication. - - ``-f`` - allocates 3 :ref:`forks `. - - ``-T`` - sets a 30-second timeout. - - ``-t`` - runs only tasks marked with the :ref:`tag ` ``my_tag``. - - ``-m`` - loads :ref:`local modules ` from ``/path/to/my/modules``. - - ``-b`` - executes with elevated privileges (uses :ref:`become `). - - ``-K`` - prompts the user for the become password. - -See :ref:`ansible-playbook` for detailed documentation. - diff --git a/docs/docsite/rst/command_guide/command_line_tools.rst b/docs/docsite/rst/command_guide/command_line_tools.rst deleted file mode 100644 index 232cd25982c..00000000000 --- a/docs/docsite/rst/command_guide/command_line_tools.rst +++ /dev/null @@ -1,23 +0,0 @@ -.. _command_line_tools: - -Working with command line tools -=============================== - -Most users are familiar with `ansible` and `ansible-playbook`, but those are not the only utilities Ansible provides. -Below is a complete list of Ansible utilities. Each page contains a description of the utility and a listing of supported parameters. - -.. note:: - You should not run most Ansible CLI tools in parallel against the same targets. - -.. toctree:: - :maxdepth: 1 - - ../cli/ansible.rst - ../cli/ansible-config.rst - ../cli/ansible-console.rst - ../cli/ansible-doc.rst - ../cli/ansible-galaxy.rst - ../cli/ansible-inventory.rst - ../cli/ansible-playbook.rst - ../cli/ansible-pull.rst - ../cli/ansible-vault.rst diff --git a/docs/docsite/rst/command_guide/index.rst b/docs/docsite/rst/command_guide/index.rst deleted file mode 100644 index 299743d30a3..00000000000 --- a/docs/docsite/rst/command_guide/index.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. _command_guide_index: - -################################ -Using Ansible command line tools -################################ - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the guide for using Ansible command line tools. -Ansible provides ad hoc commands and several utilities for performing various operations and automation tasks. - -.. toctree:: - :maxdepth: 2 - - intro_adhoc - command_line_tools - cheatsheet \ No newline at end of file diff --git a/docs/docsite/rst/command_guide/intro_adhoc.rst b/docs/docsite/rst/command_guide/intro_adhoc.rst deleted file mode 100644 index 2171f292d1e..00000000000 --- a/docs/docsite/rst/command_guide/intro_adhoc.rst +++ /dev/null @@ -1,220 +0,0 @@ -.. _intro_adhoc: - -******************************* -Introduction to ad hoc commands -******************************* - -An Ansible ad hoc command uses the `/usr/bin/ansible` command-line tool to automate a single task on one or more managed nodes. -ad hoc commands are quick and easy, but they are not reusable. -So why learn about ad hoc commands? -ad hoc commands demonstrate the simplicity and power of Ansible. -The concepts you learn here will port over directly to the playbook language. -Before reading and executing these examples, please read :ref:`intro_inventory`. - -.. contents:: - :local: - -Why use ad hoc commands? -======================== - -ad hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad hoc command looks like this: - -.. code-block:: bash - - $ ansible [pattern] -m [module] -a "[module options]" - -The ``-a`` option accepts options either through the ``key=value`` syntax or a JSON string starting with ``{`` and ending with ``}`` for more complex option structure. -You can learn more about :ref:`patterns` and :ref:`modules` on other pages. - -Use cases for ad hoc tasks -========================== - -ad hoc tasks can be used to reboot servers, copy files, manage packages and users, and much more. You can use any Ansible module in an ad hoc task. ad hoc tasks, like playbooks, use a declarative model, -calculating and executing the actions required to reach a specified final state. They -achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state. - -Rebooting servers ------------------ - -The default module for the ``ansible`` command-line utility is the :ref:`ansible.builtin.command module`. You can use an ad hoc task to call the command module and reboot all web servers in Atlanta, 10 at a time. Before Ansible can do this, you must have all servers in Atlanta listed in a group called [atlanta] in your inventory, and you must have working SSH credentials for each machine in that group. To reboot all the servers in the [atlanta] group: - -.. code-block:: bash - - $ ansible atlanta -a "/sbin/reboot" - -By default Ansible uses only 5 simultaneous processes. If you have more hosts than the value set for the fork count, Ansible will talk to them, but it will take a little longer. To reboot the [atlanta] servers with 10 parallel forks: - -.. code-block:: bash - - $ ansible atlanta -a "/sbin/reboot" -f 10 - -/usr/bin/ansible will default to running from your user account. To connect as a different user: - -.. code-block:: bash - - $ ansible atlanta -a "/sbin/reboot" -f 10 -u username - -Rebooting probably requires privilege escalation. You can connect to the server as ``username`` and run the command as the ``root`` user by using the :ref:`become ` keyword: - -.. code-block:: bash - - $ ansible atlanta -a "/sbin/reboot" -f 10 -u username --become [--ask-become-pass] - -If you add ``--ask-become-pass`` or ``-K``, Ansible prompts you for the password to use for privilege escalation (sudo/su/pfexec/doas/etc). - -.. note:: - The :ref:`command module ` does not support extended shell syntax like piping and - redirects (although shell variables will always work). If your command requires shell-specific - syntax, use the `shell` module instead. Read more about the differences on the - :ref:`working_with_modules` page. - -So far all our examples have used the default 'command' module. To use a different module, pass ``-m`` for module name. For example, to use the :ref:`ansible.builtin.shell module `: - -.. code-block:: bash - - $ ansible raleigh -m ansible.builtin.shell -a 'echo $TERM' - -When running any command with the Ansible *ad hoc* CLI (as opposed to -:ref:`Playbooks `), pay particular attention to shell quoting rules, so -the local shell retains the variable and passes it to Ansible. -For example, using double rather than single quotes in the above example would -evaluate the variable on the box you were on. - -.. _file_transfer: - -Managing files --------------- - -An ad hoc task can harness the power of Ansible and SCP to transfer many files to multiple machines in parallel. To transfer a file directly to all servers in the [atlanta] group: - -.. code-block:: bash - - $ ansible atlanta -m ansible.builtin.copy -a "src=/etc/hosts dest=/tmp/hosts" - -If you plan to repeat a task like this, use the :ref:`ansible.builtin.template` module in a playbook. - -The :ref:`ansible.builtin.file` module allows changing ownership and permissions on files. These -same options can be passed directly to the ``copy`` module as well: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.file -a "dest=/srv/foo/a.txt mode=600" - $ ansible webservers -m ansible.builtin.file -a "dest=/srv/foo/b.txt mode=600 owner=mdehaan group=mdehaan" - -The ``file`` module can also create directories, similar to ``mkdir -p``: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.file -a "dest=/path/to/c mode=755 owner=mdehaan group=mdehaan state=directory" - -As well as delete directories (recursively) and delete files: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.file -a "dest=/path/to/c state=absent" - -.. _managing_packages: - -Managing packages ------------------ - -You might also use an ad hoc task to install, update, or remove packages on managed nodes using a package management module such as ``yum``. Package management modules support common functions to install, remove, and generally manage packages. Some specific functions for a package manager might not be present in the Ansible module since they are not part of general package management. - -To ensure a package is installed without updating it: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.yum -a "name=acme state=present" - -To ensure a specific version of a package is installed: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.yum -a "name=acme-1.5 state=present" - -To ensure a package is at the latest version: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.yum -a "name=acme state=latest" - -To ensure a package is not installed: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.yum -a "name=acme state=absent" - -Ansible has modules for managing packages under many platforms. If there is no module for your package manager, you can install packages using the command module or create a module for your package manager. - -.. _users_and_groups: - -Managing users and groups -------------------------- - -You can create, manage, and remove user accounts on your managed nodes with ad hoc tasks: - -.. code-block:: bash - - $ ansible all -m ansible.builtin.user -a "name=foo password=" - - $ ansible all -m ansible.builtin.user -a "name=foo state=absent" - -See the :ref:`ansible.builtin.user ` module documentation for details on all of the available options, including -how to manipulate groups and group membership. - -.. _managing_services: - -Managing services ------------------ - -Ensure a service is started on all webservers: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.service -a "name=httpd state=started" - -Alternatively, restart a service on all webservers: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.service -a "name=httpd state=restarted" - -Ensure a service is stopped: - -.. code-block:: bash - - $ ansible webservers -m ansible.builtin.service -a "name=httpd state=stopped" - -.. _gathering_facts: - -Gathering facts ---------------- - -Facts represent discovered variables about a system. You can use facts to implement conditional execution of tasks but also just to get ad hoc information about your systems. To see all facts: - -.. code-block:: bash - - $ ansible all -m ansible.builtin.setup - -You can also filter this output to display only certain facts, see the :ref:`ansible.builtin.setup ` module documentation for details. - -Patterns and ad-hoc commands ----------------------------- - -See the :ref:`patterns ` documentation for details on all of the available options, including -how to limit using patterns in ad-hoc commands. - -Now that you understand the basic elements of Ansible execution, you are ready to learn to automate repetitive tasks using :ref:`Ansible Playbooks `. - -.. seealso:: - - :ref:`intro_configuration` - All about the Ansible config file - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`working_with_playbooks` - Using Ansible for configuration management & deployment - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/community/advanced_index.rst b/docs/docsite/rst/community/advanced_index.rst deleted file mode 100644 index b07b72ff17a..00000000000 --- a/docs/docsite/rst/community/advanced_index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _advanced_community_guide: - -********************************************** -Advanced Contributor Guide -********************************************** - -This guide focuses on contributors who are committers, GitHub admins, or release managers. - -.. toctree:: - :maxdepth: 1 - - committer_guidelines - release_managers - github_admins diff --git a/docs/docsite/rst/community/code_of_conduct.rst b/docs/docsite/rst/community/code_of_conduct.rst deleted file mode 100644 index 776236a29fe..00000000000 --- a/docs/docsite/rst/community/code_of_conduct.rst +++ /dev/null @@ -1,145 +0,0 @@ -.. _code_of_conduct: - -************************* -Community Code of Conduct -************************* - -.. contents:: Topics - -Every community can be strengthened by a diverse variety of viewpoints, insights, -opinions, skillsets, and skill levels. However, with diversity comes the potential for -disagreement and miscommunication. The purpose of this Code of Conduct is to ensure that -disagreements and differences of opinion are conducted respectfully and on their own -merits, without personal attacks or other behavior that might create an unsafe or -unwelcoming environment. - -These policies are not designed to be a comprehensive set of Things You Cannot Do. We ask -that you treat your fellow community members with respect and courtesy, and in general, -Don't Be A Jerk. This Code of Conduct is meant to be followed in spirit as much as in -letter and is not exhaustive. - -All Ansible events and participants therein are governed by this Code of Conduct and -anti-harassment policy. We expect organizers to enforce these guidelines throughout all events, -and we expect attendees, speakers, sponsors, and volunteers to help ensure a safe -environment for our whole community. Specifically, this Code of Conduct covers -participation in all Ansible-related forums and mailing lists, code and documentation -contributions, public chat (Matrix, IRC), private correspondence, and public meetings. - -Ansible community members are... - -**Considerate** - -Contributions of every kind have far-ranging consequences. Just as your work depends on -the work of others, decisions you make surrounding your contributions to the Ansible -community will affect your fellow community members. You are strongly encouraged to take -those consequences into account while making decisions. - -**Patient** - -Asynchronous communication can come with its own frustrations, even in the most responsive -of communities. Please remember that our community is largely built on volunteered time, -and that questions, contributions, and requests for support may take some time to receive -a response. Repeated "bumps" or "reminders" in rapid succession are not good displays of -patience. Additionally, it is considered poor manners to ping a specific person with -general questions. Pose your question to the community as a whole, and wait patiently for -a response. - -**Respectful** - -Every community inevitably has disagreements, but remember that it is -possible to disagree respectfully and courteously. Disagreements are never an excuse for -rudeness, hostility, threatening behavior, abuse (verbal or physical), or personal attacks. - -**Kind** - -Everyone should feel welcome in the Ansible community, regardless of their background. -Please be courteous, respectful and polite to fellow community members. Do not make or -post offensive comments related to skill level, gender, gender identity or expression, -sexual orientation, disability, physical appearance, body size, race, or religion. -Sexualized images or imagery, real or implied violence, intimidation, oppression, -stalking, sustained disruption of activities, publishing the personal information of -others without explicit permission to do so, unwanted physical contact, and unwelcome -sexual attention are all strictly prohibited. Additionally, you are encouraged not to -make assumptions about the background or identity of your fellow community members. - -**Inquisitive** - -The only stupid question is the one that does not get asked. We -encourage our users to ask early and ask often. Rather than asking whether you can ask a -question (the answer is always yes!), instead, simply ask your question. You are -encouraged to provide as many specifics as possible. Code snippets in the form of Gists or -other paste site links are almost always needed in order to get the most helpful answers. -Refrain from pasting multiple lines of code directly into the chat channels - instead use -gist.github.com or another paste site to provide code snippets. - -**Helpful** - -The Ansible community is committed to being a welcoming environment for all users, -regardless of skill level. We were all beginners once upon a time, and our community -cannot grow without an environment where new users feel safe and comfortable asking questions. -It can become frustrating to answer the same questions repeatedly; however, community -members are expected to remain courteous and helpful to all users equally, regardless of -skill or knowledge level. Avoid providing responses that prioritize snideness and snark over -useful information. At the same time, everyone is expected to read the provided -documentation thoroughly. We are happy to answer questions, provide strategic guidance, -and suggest effective workflows, but we are not here to do your job for you. - -Anti-harassment policy -====================== - -Harassment includes (but is not limited to) all of the following behaviors: - -- Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion -- Derogatory terminology including words commonly known to be slurs -- Posting sexualized images or imagery in public spaces -- Deliberate intimidation -- Stalking -- Posting others' personal information without explicit permission -- Sustained disruption of talks or other events -- Inappropriate physical contact -- Unwelcome sexual attention - -Participants asked to stop any harassing behavior are expected to comply immediately. -Sponsors are also subject to the anti-harassment policy. In particular, sponsors should -not use sexualized images, activities, or other material. Meetup organizing staff and -other volunteer organizers should not use sexualized attire or otherwise create a -sexualized environment at community events. - -In addition to the behaviors outlined above, continuing to behave a certain way after you -have been asked to stop also constitutes harassment, even if that behavior is not -specifically outlined in this policy. It is considerate and respectful to stop doing -something after you have been asked to stop, and all community members are expected to -comply with such requests immediately. - -Policy violations -================= - -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by -contacting `codeofconduct@ansible.com `_, to anyone with administrative power in community chat (Admins or Moderators on Matrix, ops on IRC), or to the local organizers of an event. Meetup -organizers are encouraged to prominently display points of contact for reporting unacceptable -behavior at local events. - -If a participant engages in harassing behavior, the meetup organizers may take any action -they deem appropriate. These actions may include but are not limited to warning the -offender, expelling the offender from the event, and barring the offender from future -community events. - -Organizers will be happy to help participants contact security or local law enforcement, -provide escorts to an alternate location, or otherwise assist those experiencing -harassment to feel safe for the duration of the meetup. We value the safety and well-being -of our community members and want everyone to feel welcome at our events, both online and -offline. - -We expect all participants, organizers, speakers, and attendees to follow these policies at -all of our event venues and event-related social events. - -The Ansible Community Code of Conduct is licensed under the Creative Commons -Attribution-Share Alike 3.0 license. Our Code of Conduct was adapted from Codes of Conduct -of other open source projects, including: - -* Contributor Covenant -* Elastic -* The Fedora Project -* OpenStack -* Puppet Labs -* Ubuntu diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst deleted file mode 100644 index d011fdb0642..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_about.rst +++ /dev/null @@ -1,155 +0,0 @@ -.. _collection_integration_tests_about: - -Understanding integration tests -================================= - -.. note:: - - Some collections do not have integration tests. - -Integration tests are functional tests of modules and plugins. -With integration tests, we check if a module or plugin satisfies its functional requirements. Simply put, we check that features work as expected and users get the outcome described in the module or plugin documentation. - -There are :ref:`two kinds of integration tests ` used in collections: - -* integration tests that use Ansible roles -* integration tests that use ``runme.sh``. - -This section focuses on integration tests that use Ansible roles. - -Integration tests check modules with playbooks that invoke those modules. The tests pass standalone parameters and their combinations, check what the module or plugin reports with the :ref:`assert ` module, and the actual state of the system after each task. - -Integration test example -------------------------- - -Let's say we want to test the ``postgresql_user`` module invoked with the ``name`` parameter. We expect that the module will both create a user based on the provided value of the ``name`` parameter and will report that the system state has changed. We cannot rely on only what the module reports. To be sure that the user has been created, we query our database with another module to see if the user exists. - -.. code-block:: yaml - - - name: Create PostgreSQL user and store module's output to the result variable - community.postgresql.postgresql_user: - name: test_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Check actual system state with another module, in other words, that the user exists - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'test_user' - register: query_result - - - name: We expect it returns one row, check it - assert: - that: - - query_result.rowcount == 1 - - -Details about integration tests --------------------------------- - -The basic entity of an Ansible integration test is a ``target``. The target is an :ref:`Ansible role ` stored in the ``tests/integration/targets`` directory of the collection repository. The target role contains everything that is needed to test a module. - -The names of targets contain the module or plugin name that they test. Target names that start with ``setup_`` are usually executed as dependencies before module and plugin targets start execution. See :ref:`collection_creating_integration_tests` for details. - -To run integration tests, we use the ``ansible-test`` utility that is included in the ``ansible-core`` and ``ansible`` packages. See :ref:`collection_run_integration_tests` for details. After you finish your integration tests, see to :ref:`collection_quickstart` to learn how to submit a pull request. - -.. _collection_integration_prepare: - -Preparing for integration tests for collections -================================================= - -To prepare for developing integration tests: - -#. :ref:`Set up your local environment `. - -#. Determine if integration tests already exist. - - .. code-block:: bash - - ansible-test integration --list-targets - - -If a collection already has integration tests, they are stored in ``tests/integration/targets/*`` subdirectories of the collection repository. - -If you use ``bash`` and the ``argcomplete`` package is installed with ``pip`` on your system, you can also get a full target list. - -.. code-block:: shell - - ansible-test integration - -Alternately, you can check if the ``tests/integration/targets`` directory contains a corresponding directory with the same name as the module. For example, the tests for the ``postgresql_user`` module of the ``community.postgresql`` collection are stored in the ``tests/integration/targets/postgresql_user`` directory of the collection repository. If there is no corresponding target there, then that module does not have integration tests. In this case, consider adding integration tests for the module. See :ref:`collection_creating_integration_tests` for details. - - -.. _collection_integration_recommendations: - -Recommendations on coverage -=========================== - -Bugfixes --------- - -Before fixing code, create a test case in an :ref:`appropriate test target` that reproduces the bug provided by the issue reporter and described in the ``Steps to Reproduce`` issue section. :ref:`Run ` the tests. - -If you failed to reproduce the bug, ask the reporter to provide additional information. The issue may be related to environment settings. Sometimes specific environment issues cannot be reproduced in integration tests, in that case, manual testing by issue reporter or other interested users is required. - -Refactoring code ----------------- - -When refactoring code, always check that related options are covered in a :ref:`corresponding test target`. Do not assume if the test target exists, everything is covered. - -.. _collections_recommendation_modules: - -Covering modules / new features -------------------------------- - -When covering a module, cover all its options separately and their meaningful combinations. Every possible use of the module should be tested against: - -- Idempotency - Does rerunning a task report no changes? -- Check-mode - Does dry-running a task behave the same as a real run? Does it not make any changes? -- Return values - Does the module return values consistently under different conditions? - -Each test action has to be tested at least the following times: - -- Perform an action in check-mode if supported. This should indicate a change. -- Check with another module that the changes have ``not`` been actually made. -- Perform the action for real. This should indicate a change. -- Check with another module that the changes have been actually made. -- Perform the action again in check-mode. This should indicate ``no`` change. -- Perform the action again for real. This should indicate ``no`` change. - -To check a task: - -1. Register the outcome of the task as a variable, for example, ``register: result``. Using the :ref:`assert ` module, check: - - #. If ``- result is changed`` or not. - #. Expected return values. - -2. If the module changes the system state, check the actual system state using at least one other module. For example, if the module changes a file, we can check that the file has been changed by checking its checksum with the :ref:`stat ` module before and after the test tasks. -3. Run the same task with ``check_mode: true`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed. -4. Cover cases when the module must fail. Use the ``ignore_errors: true`` option and check the returned message with the ``assert`` module. - -Example: - -.. code-block:: yaml - - - name: Task to fail - abstract_module: - ... - register: result - - - name: Check the task fails and its error message - assert: - that: - - result is failed - - result.msg == 'Message we expect' - -Here is a summary: - -- Cover options and their sensible combinations. -- Check returned values. -- Cover check-mode if supported. -- Check a system state using other modules. -- Check when a module must fail and error messages. diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst deleted file mode 100644 index a4c8a1096a4..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_add.rst +++ /dev/null @@ -1,250 +0,0 @@ -.. _collection_creating_integration_tests: - -Creating new integration tests -================================= - -This section covers the following cases: - -- There are no integration tests for a collection or group of modules in a collection at all. -- You are adding a new module and you want to include integration tests. -- You want to add integration tests for a module that already exists without integration tests. - -In other words, there are currently no tests for a module regardless of whether the module exists or not. - -If the module already has tests, see :ref:`collection_updating_integration_tests`. - -Simplified example --------------------- - -Here is a simplified abstract example. - -Let's say we are going to add integration tests to a new module in the ``community.abstract`` collection which interacts with some service. - -We :ref:`checked` and determined that there are no integration tests at all. - -We should basically do the following: - -1. Install and run the service with a ``setup`` target. -2. Create a test target. -3. Add integration tests for the module. -4. :ref:`Run the tests`. -5. Fix the code and tests as needed, run the tests again, and repeat the cycle until they pass. - -.. note:: - - You can reuse the ``setup`` target when implementing other targets that also use the same service. - -1. Clone the collection to the ``~/ansible_collections/community.abstract`` directory on your local machine. - -2. From the ``~/ansible_collections/community.abstract`` directory, create directories for the ``setup`` target: - -.. code-block:: bash - - mkdir -p tests/integration/targets/setup_abstract_service/tasks - -3. Write all the tasks needed to prepare the environment, install, and run the service. - -For simplicity, let's imagine that the service is available in the native distribution repositories and no sophisticated environment configuration is required. - -Add the following tasks to the ``tests/integration/targets/setup_abstract_service/tasks/main.yml`` file to install and run the service: - -.. code-block:: yaml - - - name: Install abstract service - package: - name: abstract_service - - - name: Run the service - systemd: - name: abstract_service - state: started - -This is a very simplified example. - -4. Add the target for the module you are testing. - -Let's say the module is called ``abstract_service_info``. Create the following directory structure in the target: - -.. code-block:: bash - - mkdir -p tests/integration/targets/abstract_service_info/tasks - mkdir -p tests/integration/targets/abstract_service_info/meta - -Add all of the needed subdirectories. For example, if you are going to use defaults and files, add the ``defaults`` and ``files`` directories, and so on. The approach is the same as when you are creating a role. - -5. To make the ``setup_abstract_service`` target run before the module's target, add the following lines to the ``tests/integration/targets/abstract_service_info/meta/main.yml`` file. - -.. code-block:: yaml - - dependencies: - - setup_abstract_service - -6. Start with writing a single stand-alone task to check that your module can interact with the service. - -We assume that the ``abstract_service_info`` module fetches some information from the ``abstract_service`` and that it has two connection parameters. - -Among other fields, it returns a field called ``version`` containing a service version. - -Add the following to ``tests/integration/targets/abstract_service_info/tasks/main.yml``: - -.. code-block:: yaml - - - name: Fetch info from abstract service - abstract_service_info: - host: 127.0.0.1 # We assume the service accepts local connection by default - port: 1234 # We assume that the service is listening to this port by default - register: result # This variable will contain the returned JSON including the server version - - - name: Test the output - assert: - that: - - result.version == '1.0.0' # Check version field contains what we expect - -7. :ref:`Run the tests` with the ``-vvv`` argument. - -If there are any issues with connectivity (for example, the service is not accepting connections) or with the code, the play will fail. - -Examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes. - -8. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage` section for details. - -``community.postgresql`` example --------------------------------- - -Here is a real example of writing integration tests from scratch for the ``community.postgresql.postgresql_info`` module. - -For the sake of simplicity, we will create very basic tests which we will run using the Ubuntu 20.04 test container. - -We use ``Linux`` as a work environment and have ``git`` and ``docker`` installed and running. - -We also installed ``ansible-core``. - -1. Create the following directories in your home directory: - -.. code-block:: bash - - mkdir -p ~/ansible_collections/community - -2. Fork the `collection repository `_ through the GitHub web interface. - -3. Clone the forked repository from your profile to the created path: - -.. code-block:: bash - - git clone https://github.com/YOURACC/community.postgresql.git ~/ansible_collections/community/postgresql - -If you prefer to use the SSH protocol: - -.. code-block:: bash - - git clone git@github.com:YOURACC/community.postgresql.git ~/ansible_collections/community/postgresql - -4. Go to the cloned repository: - -.. code-block:: bash - - cd ~/ansible_collections/community/postgresql - -5. Be sure you are in the default branch: - -.. code-block:: bash - - git status - -6. Checkout a test branch: - -.. code-block:: bash - - git checkout -b postgresql_info_tests - -7. Since we already have tests for the ``postgresql_info`` module, we will run the following command: - -.. code-block:: bash - - rm -rf tests/integration/targets/* - -With all of the targets now removed, the current state is as if we do not have any integration tests for the ``community.postgresql`` collection at all. We can now start writing integration tests from scratch. - -8. We will start with creating a ``setup`` target that will install all required packages and will launch PostgreSQL. Create the following directories: - -.. code-block:: bash - - mkdir -p tests/integration/targets/setup_postgresql_db/tasks - -9. Create the ``tests/integration/targets/setup_postgresql_db/tasks/main.yml`` file and add the following tasks to it: - -.. code-block:: yaml - - - name: Install required packages - package: - name: - - apt-utils - - postgresql - - postgresql-common - - python3-psycopg2 - - - name: Initialize PostgreSQL - shell: . /usr/share/postgresql-common/maintscripts-functions && set_system_locale && /usr/bin/pg_createcluster -u postgres 12 main - args: - creates: /etc/postgresql/12/ - - - name: Start PostgreSQL service - ansible.builtin.service: - name: postgresql - state: started - -That is enough for our very basic example. - -10. Then, create the following directories for the ``postgresql_info`` target: - -.. code-block:: bash - - mkdir -p tests/integration/targets/postgresql_info/tasks tests/integration/targets/postgresql_info/meta - -11. To make the ``setup_postgresql_db`` target run before the ``postgresql_info`` target as a dependency, create the ``tests/integration/targets/postgresql_info/meta/main.yml`` file and add the following code to it: - -.. code-block:: yaml - - dependencies: - - setup_postgresql_db - -12. Now we are ready to add our first test task for the ``postgresql_info`` module. Create the ``tests/integration/targets/postgresql_info/tasks/main.yml`` file and add the following code to it: - -.. code-block:: yaml - - - name: Test postgresql_info module - become: true - become_user: postgres - community.postgresql.postgresql_info: - login_user: postgres - login_db: postgres - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is not changed - - result.version.major == 12 - - result.version.minor == 8 - -In the first task, we run the ``postgresql_info`` module to fetch information from the database we installed and launched with the ``setup_postgresql_db`` target. We are saving the values returned by the module into the ``result`` variable. - -In the second task, we check the ``result`` variable, which is what the first task returned, with the ``assert`` module. We expect that, among other things, the result has the version and reports that the system state has not been changed. - -13. Run the tests in the Ubuntu 20.04 docker container: - -.. code-block:: bash - - ansible-test integration postgresql_info --docker ubuntu2004 -vvv - -The tests should pass. If we look at the output, we should see something like the following: - -.. code-block:: shell - - TASK [postgresql_info : Check the module returns what we expect] *************** - ok: [testhost] => { - "changed": false, - "msg": "All assertions passed" - } - -If your tests fail when you are working on your project, examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage` section for details. diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_running.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_running.rst deleted file mode 100644 index 64e610da295..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_running.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _collection_run_integration_tests: - -Running integration tests -============================ - -In the following examples, we will use ``Docker`` to run integration tests locally. Ensure you :ref:`collection_prepare_environment` first. - -We assume that you are in the ``~/ansible_collections/NAMESPACE/COLLECTION`` directory. - -After you change the tests, you can run them with the following command: - -.. code-block:: text - - ansible-test integration --docker - -The ``target_name`` is a test role directory containing the tests. For example, if the test files you changed are stored in the ``tests/integration/targets/postgresql_info/`` directory and you want to use the ``fedora34`` container image, then the command will be: - -.. code-block:: bash - - ansible-test integration postgresql_info --docker fedora34 - -You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. - -In the examples above, the ``fedora34`` test image will be automatically downloaded and used to create and run a test container. - -See the :ref:`list of supported container images `. - -In some cases, for example, for platform-independent tests, the ``default`` test image is required. Use the ``--docker default`` or just ``--docker`` option without specifying a distribution in this case. - -.. note:: - - If you have any difficulties with writing or running integration tests or you are not sure if the case can be covered, submit your pull request without the tests. Other contributors can help you with them later if needed. diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_tests.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_tests.rst deleted file mode 100644 index 9eef463613c..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_tests.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. _collection_integration_tests: - - -***************************************** -Adding integration tests to a collection -***************************************** - -This section describes the steps to add integration tests to a collection and how to run them locally using the ``ansible-test`` command. - -.. toctree:: - :maxdepth: 1 - - collection_integration_about - collection_integration_updating - collection_integration_running - collection_integration_add - - -.. seealso:: - - :ref:`testing_units_modules` - Unit testing Ansible modules - `pytest `_ - Pytest framework documentation - :ref:`developing_testing` - Ansible Testing Guide - :ref:`collection_unit_tests` - Unit testing for collections - :ref:`testing_integration` - Integration tests guide - :ref:`testing_collections` - Testing collections - :ref:`testing_resource_modules` - Resource module integration tests - :ref:`collection_pr_test` - How to test a pull request locally diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst deleted file mode 100644 index b519c4d4d1b..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst +++ /dev/null @@ -1,169 +0,0 @@ -.. _collection_updating_integration_tests: - -Adding to an existing integration test -======================================= - -The test tasks are stored in the ``tests/integration/targets//tasks`` directory. - -The ``main.yml`` file holds test tasks and includes other test files. -Look for a suitable test file to integrate your tests or create and include or import a separate test file. -You can use one of the existing test files as a draft. - -When fixing a bug ------------------ - -When fixing a bug: - -1. :ref:`Determine if integration tests for the module exist`. If they do not, see :ref:`collection_creating_integration_tests` section. -2. Add a task that reproduces the bug to an appropriate file within the ``tests/integration/targets//tasks`` directory. -3. :ref:`Run the tests`. The newly added task should fail. -4. If they do not fail, re-check if your environment or test task satisfies the conditions described in the ``Steps to Reproduce`` section of the issue. -5. If you reproduce the bug and tests fail, change the code. -6. :ref:`Run the tests` again. -7. If they fail, repeat steps 5-6 until the tests pass. - -Here is an example. - -Let's say someone reported an issue in the ``community.postgresql`` collection that when users pass a name containing underscores to the ``postgresql_user`` module, the module fails. - -We cloned the collection repository to the ``~/ansible_collections/community/postgresql`` directory and :ref:`prepared our environment `. From the collection's root directory, we run ``ansible-test integration --list-targets`` and it shows a target called ``postgresql_user``. It means that we already have tests for the module. - -We start with reproducing the bug. - -First, we look into the ``tests/integration/targets/postgresql_user/tasks/main.yml`` file. In this particular case, the file imports other files from the ``tasks`` directory. The ``postgresql_user_general.yml`` looks like an appropriate one to add our tests. - -.. code-block:: yaml - - # General tests: - - import_tasks: postgresql_user_general.yml - when: postgres_version_resp.stdout is version('9.4', '>=') - -We will add the following code to the file. - -.. code-block:: yaml - - # https://github.com/ansible-collections/community.postgresql/issues/NUM - - name: Test user name containing underscore - community.postgresql.postgresql_user: - name: underscored_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Query the database if the user exists - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'underscored_user' - register: result - - - name: Check the database returns one row - assert: - that: - - result.query_result.rowcount == 1 - -When we :ref:`run the tests` with ``postgresql_user`` as a test target, this task must fail. - -Now that we have our failing test; we will fix the bug and run the same tests again. Once the tests pass, we will consider the bug fixed and will submit a pull request. - -When adding a new feature -------------------------- - -.. note:: - - The process described in this section also applies when you want to add integration tests to a feature that already exists, but is missing integration tests. - -If you have not already implemented the new feature, you can start by writing the integration tests for it. They will not work as the code does not yet exist, but they can help you improve your implementation design before you start writing any code. - -When adding new features, the process of adding tests consists of the following steps: - -1. :ref:`Determine if integration tests for the module exists`. If they do not, see :ref:`collection_creating_integration_tests`. -2. Find an appropriate file for your tests within the ``tests/integration/targets//tasks`` directory. -3. Cover your feature with tests. Refer to the :ref:`Recommendations on coverage` section for details. -4. :ref:`Run the tests`. -5. If they fail, see the test output for details. Fix your code or tests and run the tests again. -6. Repeat steps 4-5 until the tests pass. - -Here is an example. - -Let's say we decided to add a new option called ``add_attribute`` to the ``postgresql_user`` module of the ``community.postgresql`` collection. - -The option is boolean. If set to ``yes``, it adds an additional attribute to a database user. - -We cloned the collection repository to the ``~/ansible_collections/community/postgresql`` directory and :ref:`prepared our environment`. From the collection's root directory, we run ``ansible-test integration --list-targets`` and it shows a target called ``postgresql_user``. Therefore, we already have some tests for the module. - -First, we look at the ``tests/integration/targets//tasks/main.yml`` file. In this particular case, the file imports other files from the ``tasks`` directory. The ``postgresql_user_general.yml`` file looks like an appropriate one to add our tests. - -.. code-block:: yaml - - # General tests: - - import_tasks: postgresql_user_general.yml - when: postgres_version_resp.stdout is version('9.4', '>=') - -We will add the following code to the file. - -.. code-block:: yaml - - # https://github.com/ansible-collections/community.postgresql/issues/NUM - # We should also run the same tasks with check_mode: true. We omit it here for simplicity. - - name: Test for new_option, create new user WITHOUT the attribute - community.postgresql.postgresql_user: - name: test_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Query the database if the user exists but does not have the attribute (it is NULL) - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = NULL - register: result - - - name: Check the database returns one row - assert: - that: - - result.query_result.rowcount == 1 - - - name: Test for new_option, create new user WITH the attribute - community.postgresql.postgresql_user: - name: test_user - register: result - - - name: Check the module returns what we expect - assert: - that: - - result is changed - - - name: Query the database if the user has the attribute (it is TRUE) - community.postgresql.postgresql_query: - query: SELECT * FROM pg_authid WHERE rolename = 'test_user' AND attribute = 't' - register: result - - - name: Check the database returns one row - assert: - that: - - result.query_result.rowcount == 1 - -Then we :ref:`run the tests` with ``postgresql_user`` passed as a test target. - -In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: true`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage` for details. - -If we expect a task to fail, we use the ``ignore_errors: true`` option and check that the task actually failed and returned the message we expect: - -.. code-block:: yaml - - - name: Test for fail_when_true option - community.postgresql.postgresql_user: - name: test_user - fail_when_true: true - register: result - ignore_errors: true - - - name: Check the module fails and returns message we expect - assert: - that: - - result is failed - - result.msg == 'The message we expect' diff --git a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst b/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst deleted file mode 100644 index f8ba7edf373..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst +++ /dev/null @@ -1,341 +0,0 @@ -.. _collection_release_with_branches: - -Releasing collections with release branches -============================================ - -Collections MUST follow the `semantic versioning `_ rules. See :ref:`releasing_collections` for high-level details. - -.. contents:: - :local: - - -Release planning and announcement ----------------------------------- - -#. Announce your intention to release the collection in a corresponding pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. Repeat the announcement in any other dedicated channels if they exist. - -#. Ensure all the other repository maintainers are informed about the time of the following release. - - -Releasing major collection versions -------------------------------------- - -The new version is assumed to be ``X.0.0``. - -1. Make sure that ``galaxy.yml`` contains the correct version number ``X.0.0``. If that is not the case, create a PR to update it. This will make sanity tests fail for all deprecations that have to be removed in ``X.0.0``, so this is potentially a lot of work and should have been done weeks before the major release. - -2. Check the collection for deprecations that are planned for removal in the major release that were not reported by the sanity tests. Use past changelogs or run ``grep -r `X.0.0` plugins/`` in the repository. - -3. If you are going to release the ``community.general`` and ``community.network`` collections, create a new ``backport-X`` label in the corresponding repositories. Copy the styles and descriptions from the corresponding existing labels. - -4. Ensure you are in a default branch in your local fork. These examples use ``main``. - - .. code-block:: bash - - git status - git checkout main # if needed - - -5. Update your local fork: - - .. code-block:: bash - - git pull --rebase upstream main - - -Creating the release branch -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Create a branch ``stable-X``. Replace ``X`` with a correct number and push it to the **upstream** repository, NOT to the ``origin``.: - - .. code-block:: bash - - git branch stable-X main - git push upstream stable-X - - -2. Create and checkout to another branch from the ``main`` branch: - - .. code-block:: bash - - git checkout -b update_repo - - -3. Update the version in ``galaxy.yml`` in the branch to the next **expected** version, for example, ``X.1.0``. - - -Creating the changelogs -^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Replace ``changelogs/changelog.yml`` with: - - .. code-block:: yaml - - ancestor: X.0.0 - releases: {} - - -2. Remove all changelog fragments from ``changelogs/fragments/``. Removing the changelog fragments ensures that every major release has a changelog describing changes since the last major release. - -3. Add and commit all the changes made. Push the branch to the ``origin`` repository. - -4. Create a pull request in the collection repository. If CI tests pass, merge the pull request since the ``main`` branch is expecting changes for the next minor/major versions - -5. Switch to the ``stable-X`` branch. - -6. In the ``stable-X`` branch, verify that ``galaxy.yml`` contains the correct version number ``X.0.0``. - -7. In the ``stable-X`` branch, ensure that ``changelogs/changelog.yml`` contains a correct ancestor's version: - - .. code-block:: yaml - - ancestor: X-1.0.0 - releases: {} - - -8. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.0.0.yml`` with the content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - - For example: - - .. code-block:: yaml - - release_summary: This is release 2.0.0 of ``community.foo``, released on YYYY-MM-DD. - - -9. In the ``stable-X`` branch, generate the changelogs: - - .. code-block:: bash - - antsibull-changelog release --cummulative-release - - -10. In the ``stable-X`` branch, verify that the ``CHANGELOG.rst`` looks as expected. - -11. In the ``stable-X`` branch, update ``README.md`` so that the changelog link points to ``/tree/stable-X/`` and no longer to ``/tree/main/``, and change badges respectively, for example, in case of AZP, add ``?branchName=stable-X`` to the AZP CI badge (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI?branchName=stable-X). - -12. In the ``stable-X`` branch, add, commit, and push changes to ``README.md``, ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the ``origin``. - - -Publishing the collection -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.0.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.0.0" - git push upstream NEW_VERSION - - -2. If the collection uses `Zuul `_ for publishing its releases, wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. If the release tarball did not appear within several hours after pushing the tag, try to re-tag the release commit and push the tag again. In the ``stable-X`` branch being at the release commit: - - .. code-block:: bash - - git tag --delete NEW_VERSION - git push upstream :NEW_VERSION - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.0.0" - git push upstream NEW_VERSION - - -4. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - -5. Announce the release through the `Bullhorn Newsletter `_. - -6. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel `_. - -7. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upstream** repository. - - -Releasing minor collection versions -------------------------------------- - -The new version is assumed to be ``X.Y.0``. All changes that should go into it are expected to be previously backported from the default branch to the ``stable-X`` branch. - -Creating the changelogs -^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.0``. If not, update it. - -2. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.0.yml`` with content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - -3. In the ``stable-X`` branch, run: - - .. code-block:: bash - - antsibull-changelog release - - -4. In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected. - -5. In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin. - - -Publishing the collection -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.0" - git push upstream NEW_VERSION - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. The published version will appear in a list of tarballs available to download. - -3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - -4. Announce the release through the `Bullhorn Newsletter `_. - -5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. Additionally, you can announce it using GitHub's Releases system. - -6. In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, if you have released ``X.1.0``, the next expected version could be ``X.2.0``. Add, commit and push to the **upstream** repository. - -7. Checkout to the ``main`` branch. - -8. In the ``main`` branch: - - #. If more minor versions are released before the next major version, update the version in ``galaxy.yml`` to ``X.(Y+1).0`` as well. Create a dedicated pull request and merge. - - #. If the next version will be a new major version, create a pull request where you update the version in ``galaxy.yml`` to ``(X+1).0.0``. Note that the sanity tests will most likely fail since there will be deprecations with removal scheduled for ``(X+1).0.0``, which are flagged by the tests. - - For every such deprecation, decide: - - * Whether to remove them now. For example you remove the complete ``modules/plugins`` or you remove redirects. - * Whether to add ignore entries to the corresponding ``tests/sanity/ignore-*.txt`` file and create issues, for example for removed features in ``modules/plugins``. - - Once the CI tests pass, merge the pull request. Make sure that this pull request is merged not too much later after the release - for ``version_added`` sanity tests not to expect the wrong version for the new feature pull request. - -.. note:: - - It makes sense to already do some removals in the days before the release. These removals must happen in the main branch and must not be backported. - - -Releasing patch versions -------------------------- - -The new version is assumed to be ``X.Y.Z``, and the previous patch version is assumed to be ``X.Y.z`` with ``z < Z``. ``z`` is frequently``0`` since patch releases are uncommon. - -Releasing when more minor versions are expected -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Checkout the ``X.Y.z`` tag. - -2. Update ``galaxy.yml`` so that the version is ``X.Y.Z``. Add and commit. - -3. Cherry-pick all changes from ``stable-X`` that were added after ``X.Y.z`` and should go into ``X.Y.Z``. - -4. Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - Add to git and commit. - -5. Generate the changelogs. - -.. code-block:: bash - - antsibull-changelog release - -6. Verify that ``CHANGELOG.rst`` looks as expected. - -7. Add and commit changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments. - -**Publishing the collection** - - -1. Add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.1" - git push upstream NEW_VERSION - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - - .. note:: - - The data for this release is only contained in a tag, and not in a branch, in particular not in ``stable-X``. - This is deliberate, since the next minor release ``X.(Y+1).0`` already contains the changes for ``X.Y.Z`` as well, since these were cherry-picked from ``stable-X``. - - -4. Announce the release through the `Bullhorn Newsletter `_. - -5. Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `. - - -Releasing when no more minor versions are expected -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.Z``. If not, update it! - -2. In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content: - - .. code-block:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - -3. Generate the changelogs in the ``stable-X`` branch. - - .. code-block:: bash - - antsibull-changelog release - - -4. In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected. - -5. In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin. - -**Publishing the collection** - - -1. In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code-block:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.foo: 2.1.1" - git push upstream NEW_VERSION - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. Add a GitHub release for the new tag. Title should be the version and content, such as: ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``. - -4. Announce the release through the `Bullhorn Newsletter `_. - -5. Announce the release in the pinned issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. diff --git a/docs/docsite/rst/community/collection_contributors/collection_release_without_branches.rst b/docs/docsite/rst/community/collection_contributors/collection_release_without_branches.rst deleted file mode 100644 index 4cef33f03c8..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_release_without_branches.rst +++ /dev/null @@ -1,115 +0,0 @@ - -.. _collection_release_without_branches: - -Releasing collections without release branches -=============================================== - -Since no release branches are used, this section does not distinguish between releasing a major, minor, or patch version. - -.. contents:: - :local: - -Release planning and announcement ----------------------------------- - -#. Examine the collection to determine if there are merged changes to release. - -#. According to the changes made, choose an appropriate release version number. Keep in mind that the collections must follow the `semantic versioning `_ rules. See :ref:`collection_versioning_and_deprecation` for details. - -#. Announce your intention to release the collection in a corresponding pinned release issue or community pinboard of the collection and in the ``community`` :ref:`Matrix/IRC channel `. - -Creating the release branch ----------------------------- - -1. Ensure you are in a default branch in your local fork. We use ``main`` in the following examples. - - .. code:: bash - - git status - git checkout main # if needed - - -2. Update your local fork: - - .. code:: bash - - git pull --rebase upstream main - - -3. Checkout a new release branch from the default branch: - - .. code:: bash - - git checkout -b release_branch - -4. Ensure the ``galaxy.yml`` contains the correct release version number. - - -Generating the changelog -------------------------- - -1. Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content: - - .. code:: yaml - - release_summary: |- - Write some text here that should appear as the release summary for this version. - The format is reStructuredText, but not a list as for regular changelog fragments. - This text will be inserted into the changelog. - - For example: - - .. code:: yaml - - release_summary: |- - This is the minor release of the ``community.mysql`` collection. - This changelog contains all changes to the modules and plugins in this collection - that have been made after the previous release. - - -2. If the content was recently moved from another collection (for example, migrating a module from one collection to another), ensure you have all related changelog fragments in the ``changelogs/fragments`` directory. If not, copy them previously. - -3. Run ``antsibull-changelog release --reload-plugins`` . This package should previously be installed with ``pip install antsibull-changelog``. - -4. Verify that the ``CHANGELOG.rst`` looks as expected. - -5. Commit and push changes to the ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the ``origin`` repository's ``release_branch``. - - .. code:: bash - - git commit -a -m "Release VERSION commit" - git push origin release_branch - - -6. Create a pull request in the collection repository. If CI tests pass, merge it. - -7. Checkout the default branch and pull the changes: - - .. code:: bash - - git checkout main - git pull --rebase upstream main - - -Publish the collection ------------------------------------ - -1. Add an annotated tag to the release commit with the collection version. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_. - - .. code:: bash - - git tag -n # see current tags and their comments - git tag -a NEW_VERSION -m "comment here" # the comment can be, for example, "community.postgresql: 1.2.0" - git push upstream NEW_VERSION - - - -2. Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download. - -3. Update the version in the ``galaxy.yml`` file to the next **expected** version. Add, commit, and push to the ``upstream``'s default branch. - -4. Add a GitHub release for the new tag. Title should be the version and content ``See https://github.com/ansible-collections/community.xxx/blob/main/CHANGELOG.rst for all changes``. - -5. Announce the release through the `Bullhorn Newsletter issue `_. - -6. Announce the release in the pinned release issue/community pinboard of the collection mentioned in step 3 and in the ``community`` :ref:`Matrix/IRC channel `. diff --git a/docs/docsite/rst/community/collection_contributors/collection_releasing.rst b/docs/docsite/rst/community/collection_contributors/collection_releasing.rst deleted file mode 100644 index 481208b007a..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_releasing.rst +++ /dev/null @@ -1,106 +0,0 @@ - -.. _releasing_collections: -.. _Releasing: - -Releasing collections -====================== - -Collection maintainers release all supported stable versions of the collections regularly, -provided that there have been enough changes merged to release. - - -.. contents:: - :local: - -Preparing to release a collection --------------------------------------------- - - -The collections under the `ansible-collections organization `_ follow `semantic versioning `_ when releasing. See :ref:`collection_versioning_and_deprecation` for details. - -To prepare for a release, a collection must have: - -* A publicly available policy of releasing, versioning, and deprecation. This can be, for example, written in its README or in a dedicated pinned issue. -* A pinned issue when its release managers inform the community about planned or completed releases. This can be combined with the release policy issue mentioned above. -* A :ref:`changelog `. -* Releases of the collection tagged in the collection's repository. -* CI pipelines up and running. This can be implemented by using GitHub Actions, Azure Pipelines, Zuul. -* All CI tests running against a commit that releases the collection. If they do not pass, the collection MUST NOT be released. - -See :ref:`including_collection_ansible` if you plan on adding a new collection to the Ansible package. - -.. note:: - - Your collection must pass ``ansible-test sanity`` tests. See :ref:`testing_collections` for details. - - -.. _collection_versioning_and_deprecation: - -Collection versioning and deprecation --------------------------------------- - -.. note:: - - Collections MUST adhere to `semantic versioning `_. - -To preserve backward compatibility for users, every Ansible minor version series (5.1.x, 5.2.x, and so on) will keep the major version of a collection constant. For example, if Ansible 5.0.0 includes ``community.general`` 4.0.2, then each Ansible 5.X.x release will include the latest ``community.general`` 4.y.z release available at build time. Ansible 5.x.x will **never** include a ``community.general`` 5.y.x release, even if it is available. Major collection version changes will be included in the next Ansible major release (6.0.0 in this case). -Ensure that the current major release of your collection included in 6.0.0 receives at least bugfixes as long as new Ansible 6.X.X releases are produced. - -Since new minor releases are included, you can include new features, modules and plugins. You must make sure that you do not break backwards compatibility. See `semantic versioning `_. for more details. This means in particular: - -* You can fix bugs in **patch** releases but not add new features or deprecate things. -* You can add new features and deprecate things in **minor** releases, but not remove things or change behavior of existing features. -* You can only remove things or make breaking changes in **major** releases. - -Ensure that if a deprecation is added in a collection version that is included in 5.x.y, the removal itself will only happen in a collection version included in 7.0.0 or later. -Ensure that the policy of releasing, versioning, and deprecation is announced to contributors and users in some way. For an example of how to do this, see `the announcement in community.general `_. You could also do this in the collection README file. - -.. _collection_changelog: - -Collection changelogs ----------------------- - -Collections MUST include a changelog. To give a consistent feel for changelogs across collections and ensure changelogs exist for collections included in the ``ansible`` package, we suggest you use `antsibull-changelog `_ to maintain and generate this. - -Before releasing, verify the following for your changelogs: - -* All merged pull requests since the last release, except ones related to documentation and new modules/plugins, have :ref:`changelog fragments `. -* New module and plugin pull requests, except jinja2 test and filter plugins, do **not** need a changelog fragment, they are auto-detected by the changelog generator by their ``version_added`` value. -* All the fragments follow the :ref:`changelog entry format `. - -Options for releasing a collection ------------------------------------ - -There are several approaches on how to release a collection. If you are not aware of which approach to use, ask in the ``#ansible-community`` IRC channel or the ``community`` Matrix channel. - -This section assumes that publishing the collection is done with `Zuul `_ and that `antsibull-changelog `_ is used for the changelog. - -Releasing without release branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use releasing without release branches when: - -* There are no prior major releases of the collection. -* There are no breaking changes introduced since the ``1.0.0`` release of the collection. - -See :ref:`collection_release_without_branches` for details. - -When there is a need to introduce breaking changes, you can switch to the next approach. - -Hybrid approach -^^^^^^^^^^^^^^^^^^^^^ - -In this approach, releases for the current major version are made from the ``main`` branch, while new releases for older major versions are made from release branches for these versions. - -Releasing with release branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use releasing with release branches when breaking changes have been introduced. This approach is usually only used by the large community collections, ``community.general`` and ``community.network``. - -See :ref:`collection_release_with_branches` for details. - -.. toctree:: - :maxdepth: 1 - - collection_release_without_branches - collection_release_with_branches diff --git a/docs/docsite/rst/community/collection_contributors/collection_requirements.rst b/docs/docsite/rst/community/collection_contributors/collection_requirements.rst deleted file mode 100644 index bae0f21d37f..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_requirements.rst +++ /dev/null @@ -1,499 +0,0 @@ -.. _collections_requirements: - -************************************************** -Ansible community package collections requirements -************************************************** - -This section describes the requirements for maintainers of Ansible community collections in the `ansible-collections `_ repository or included in the Ansible community package. - -.. contents:: - :local: - - -Overview -======== - -This section provides help, advice, and guidance on making sure your collections are correct and ready for inclusion in the Ansible community package. - -.. note:: - - `Inclusion of a new collection `_ in the Ansible package is ultimately at the discretion of the :ref:`community_steering_committee`. Every rejected candidate will get feedback. Differences of opinion should be taken to a dedicated `Community Topic `_ for discussion and a final vote. - -Feedback and communications -============================== - -As with any project it is very important that we get feedback from users, contributors, and maintainers. You can get feedback and help as follows: - -* Discussing in the `#community:ansible.com Matrix room `_, which is bridged with the ``#ansible-community`` channel on Libera.Chat IRC. See the :ref:`Ansible Communication Guide ` for details. -* Discussing in the `Community Working Group meeting `_. -* Creating `GitHub Issues `_ in the ``ansible-collections`` repository. - -Keeping informed -================ - -You should subscribe to: - -* The `news-for-maintainers repository `_ to track changes that collection maintainers should be aware of. Subscribe only to issues if you want less traffic. -* The `Bullhorn `_ Ansible contributor newsletter. - -.. _coll_infrastructure_reqs: - -Collection infrastructure -========================= - - -The following guidelines describe the required structure for your collection: - -* MUST have a publicly available issue tracker that does not require a paid level of service to create an account or view issues. -* MUST have a Code of Conduct (CoC). - - * The collection's CoC MUST be compatible with the :ref:`code_of_conduct`. - * The collections SHOULD consider using the Ansible CoC if they do not have a CoC that they consider better. - * The :ref:`Diversity and Inclusion working group ` may evaluate all CoCs and object to a collection's inclusion based on the CoCs contents. - * The CoC MUST be linked from the ``README.md`` file, or MUST be present or linked from the ``CODE_OF_CONDUCT.md`` file in the collection root. - -* MUST be published to `Ansible Galaxy `_. -* SHOULD NOT contain any large objects (binaries) comparatively to the current Galaxy tarball size limit of 20 MB, For example, do not include package installers for testing purposes. -* SHOULD NOT contain any unnecessary files such as temporary files. -* MUST only contain objects that follow the :ref:`Licensing rules `. - - -.. _coll_python_compatibility: - -Python Compatibility -==================== - -A collection MUST be developed and tested using the below Python requirements as Ansible supports a wide variety of machines. - -The collection should adhere to the tips at :ref:`ansible-and-python-3`. - -.. _coll_python_reqs: - -Python Requirements -------------------- - -Python requirements for a collection vary between **controller environment** and **other environment**. On the controller-environment, the Python versions required may be higher than what is required on the other-environment. While developing a collection, you need to understand the definitions of both the controller-environment and other-environment to help you choose Python versions accordingly: - -* controller environment: The plugins/modules always run in the same environment (Python interpreter, venv, host, and so on) as ansible-core itself. -* other environment: It is possible, even if uncommon in practice, for the plugins/modules to run in a different environment than ansible-core itself. - -One example scenario where the "even if" clause comes into play is when using cloud modules. These modules mostly run on the controller node but in some environments, the controller might run on one machine inside a demilitarized zone which cannot directly access the cloud machines. The user has to have the cloud modules run on a bastion host/jump server which has access to the cloud machines. - -.. _coll_controller_req: - -Controller environment -~~~~~~~~~~~~~~~~~~~~~~ - -In the controller environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v3.5 if all required libraries support this version. - -Other environment -~~~~~~~~~~~~~~~~~ - -In the other environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v2.6 and v3.5 if all required libraries support this version. - -.. note:: - - If the collection does not support Python 2.6 and/or Python 3.5 explicitly then take the below points into consideration: - - - Dropping support for Python 2.6 in the other environment means that you are dropping support for RHEL6. RHEL6 ended full support in November, 2020, but some users are still using RHEL6 under extended support contracts (ELS) until 2024. ELS is not full support; not all CVEs of the python-2.6 interpreter are fixed, for instance. - - - Dropping support for Python 3.5 means that Python 2.7 has to be installed on Ubuntu Xenial (16.04) and that you have to support Python 2.7. - - Also, note that dropping support for a Python version for an existing module/plugin is a breaking change, and thus requires a major release. A collection MUST announce dropping support for Python versions in their changelog, if possible in advance (for example, in previous versions before support is dropped). - -.. _coll_python_docs_req: - -Python documentation requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* If everything in your collection supports the same Python versions as the collection-supported versions of ansible-core, you do not need to document Python versions. -* If your collection does not support those Python versions, you MUST document which versions it supports in the README. -* If most of your collection supports the same Python versions as ansible-core, but some modules and plugins do not, you MUST include the supported Python versions in the documentation for those modules and plugins. - -For example, if your collection supports Ansible 2.9 to ansible-core 2.13, the Python versions supported for modules are 2.6, 2.7, and 3.5 and newer (until at least 3.10), while the Python versions supported for plugins are 2.7 and 3.5 and newer (until at least 3.10). So if the modules in your collection do not support Python 2.6, you have to document this in the README, for example ``The content in this collection supports Python 2.7, Python 3.5 and newer.``. - -.. _coll_plugin_standards: - -Standards for developing module and plugin utilities -==================================================== - -* ``module_utils`` and ``plugin_utils`` can be marked for only internal use in the collection, but they MUST document this and MUST use a leading underscore for filenames. -* It is a breaking change when you make an existing ``module_utils`` private and in that case the collection requires a major version bump. -* Below are some recommendations for ``module_utils`` documentation: - - * No docstring: everything we recommend for ``other-environment`` is supported. - * The docstring ``'Python versions supported: same as for controller-environment'``: everything we recommend for ``controller-environment`` is supported. - * The docstring with specific versions otherwise: ``'Python versions supported: '``. - -.. _coll_repo_structure: - -Repository structure requirements -================================== - -galaxy.yml ----------- - -* The ``tags`` field MUST be set. -* Collection dependencies must meet a set of rules. See the section on `Collection Dependencies ` for details. -* The ``ansible`` package MUST NOT depend on collections not shipped in the package. -* If you plan to split up your collection, the new collection MUST be approved for inclusion before the smaller collections replace the larger in Ansible. -* If you plan to add other collections as dependencies, they MUST run through the formal application process. - -.. _coll_readme_req: - -README.md ---------- - -Your collection repository MUST have a ``README.md`` in the root of the collection, see `collection_template/README.md `_ for an example. - -meta/runtime.yml ----------------- -Example: `meta/runtime.yml `_ - -* The ``meta/runtime.yml`` MUST define the minimum version of Ansible which this collection works with. - - * If the collection works with Ansible 2.9, then this should be set to `>=2.9.10` - * It is usually better to avoid adding `<2.11` as a restriction, since this for example makes it impossible to use the collection with the current ansible-base devel branch (which has version 2.11.0.dev0) - -.. _coll_module-reqs: - -Modules & Plugins ------------------- - -* Collections MUST only use the directories specified below in the ``plugins/`` directory and - only for the purposes listed: - - :Those recognized by ansible-core: ``doc_fragments``, ``modules``, ``module_utils``, ``terminal``, and those listed in :ref:`working_with_plugins`. This list can be verified by looking at the last element of the package argument of each ``*_loader`` in https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/loader.py#L1126 - :plugin_utils: For shared code which is only used controller-side, not in modules. - :sub_plugins: For other plugins which are managed by plugins inside of collections instead of ansible-core. We use a subfolder so there aren't conflicts when ansible-core adds new plugin types. - - The core team (which maintains ansible-core) has committed not to use these directories for - anything which would conflict with the uses specified here. - -Other directories ------------------ - -Collections MUST not use files outside ``meta/``, ``plugins/``, ``roles/`` and ``playbooks/`` in any plugin, role, or playbook that can be called by FQCN, used from other collections, or used from user playbooks and roles. A collection must work if every file or directory is deleted from the installed collection except those four directories and their contents. - -Internal plugins, roles and playbooks (artifacts used only in testing, or only to release the collection, or only for some other internal purpose and not used externally) are exempt from this rule and may rely on files in other directories. - -.. _coll_docs_structure_reqs: - -Documentation requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -All modules and plugins MUST: - -* Include a :ref:`DOCUMENTATION ` block. -* Include an :ref:`EXAMPLES ` block (except where not relevant for the plugin type). -* Use FQCNs when referring to modules, plugins and documentation fragments inside and outside the collection (including ``ansible.builtin`` for the listed entities from ansible-core. - -When using ``version_added`` in the documentation: - -* Declare the version of the collection in which the options were added -- NOT the version of Ansible. -* If you for some reason really have to specify version numbers of Ansible or of another collection, you also have to provide ``version_added_collection: collection_name``. We strongly recommend to NOT do this. -* Include ``version_added`` when you add new content (modules, plugins, options) to an existing collection. The values are shown in the documentation, and can be useful, but you do not need to add ``version_added`` to every option, module, and plugin when creating a new collection. - -Other items: - -* The ``CONTRIBUTING.md`` (or ``README.md``) file MUST state what types of contributions (pull requests, feature requests, and so on) are accepted and any relevant contributor guidance. Issues (bugs and feature request) reports must always be accepted. -* Collections are encouraged to use z:ref:`links and formatting macros ` -* Including a :ref:`RETURN ` block for modules is strongly encouraged but not required. - -.. _coll_workflow: - -Contributor Workflow -==================== - -.. _coll_changlogs_req: - -Changelogs ----------- - -Collections are required to include a changelog. To give a consistent feel for changelogs across collections and ensure changelogs exist for collections included in the ``ansible`` package we suggest you use `antsibull-changelog `_ to maintain and generate this but other options exist. Preferred (in descending order): - -#. Use antsibull-changelog (preferred). -#. Provide ``changelogs/changelog.yaml`` in the `correct format `_. (You can use ``antsibull-lint changelog-yaml /path/to/changelog.yaml`` to validate the format.) -#. Provide a link to the changelog file (self-hosted) (not recommended). - -Note that the porting guide is compiled from ``changelogs/changelog.yaml`` (sections ``breaking_changes``, ``major_changes``, ``deprecated_features``, ``removed_features``). So if you use option 3, you will not be able to add something to the porting guide. - -.. _coll_versioning_req: - -Versioning and deprecation -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -* Collections MUST adhere to `semantic versioning `_. -* To preserve backward compatibility for users, every Ansible minor version series (x.Y.z) will keep the major version of a collection constant. If ansible 3.0.0 includes ``community.general`` 2.2.0, then each 3.Y.z (3.1.z, 3.2.z, and so on) release will include the latest ``community.general`` 2.y.z release available at build time. Ansible 3.y.z will **never** include a ``community.general`` 3.y.z release, even if it is available. Major collection version changes will be included in the next Ansible major release (4.0.0 in this example). -* Therefore, ensure that the current major release of your collection included in 3.0.0 receives at least bugfixes as long as new 3.Y.Z releases are produced. -* Since new minor releases are included, you can include new features, modules and plugins. You must make sure that you do not break backwards compatibility! (See `semantic versioning `_.) This means in particular: - - * You can fix bugs in patch releases, but not add new features or deprecate things. - * You can add new features and deprecate things in minor releases, but not remove things or change behavior of existing features. - * You can only remove things or make breaking changes in major releases. -* We recommend that you ensure that if a deprecation is added in a collection version that is included in Ansible 3.y.z, the removal itself will only happen in a collection version included in Ansible 5.0.0 or later, but not in a collection version included in Ansible 4.0.0. -* Content moved from ansible/ansible that was scheduled for removal in 2.11 or later MUST NOT be removed in the current major release available when ansible 2.10.0 is released. Otherwise it would already be removed in 2.10, unexpectedly for users! Deprecation cycles can be shortened (since they are now uncoupled from ansible or ansible-base versions), but existing ones must not be unexpectedly terminated. -* We recommend you announce your policy of releasing, versioning and deprecation to contributors and users in some way. For an example of how to do this, see `the announcement in community.general `_. You could also do this in the README. - -.. _ coll_naming_req: - -Naming -====== - -Collection naming ------------------ - -For collections under ansible-collections the repository SHOULD be named ``NAMESPACE.COLLECTION``. - -To create a new collection and corresponding repository, first, a new namespace in Galaxy has to be created by submitting `Request a namespace `_. - -`Namespace limitations `_ lists requirements for namespaces in Galaxy. - -For collections created for working with a particular entity, they should contain the entity name, for example ``community.mysql``. - -For corporate maintained collections, the repository can be named ``COMPANY_NAME.PRODUCT_NAME``, for example ``ibm.db2``. - -We should avoid FQCN / repository names: - -* which are unnecessary long: try to make it compact but clear. -* contain the same words / collocations in ``NAMESPACE`` and ``COLLECTION`` parts, for example ``my_system.my_system``. - -If your collection is planned to be certified on **Red Hat Automation Hub**, please consult with Red Hat Partner Engineering through ``ansiblepartners@redhat.com`` to ensure collection naming compatibility between the community collection on **Galaxy**. - -.. _coll_module_name_req: - -Module naming -------------- - -Modules that only gather information MUST be named ``_info``. Modules that return ``ansible_facts`` are named ``_facts`` and do not return non-facts. -For more information, refer to the :ref:`Developing modules guidelines `. - -.. _coll_licensing_req: - -Collection licensing requirements -=================================== - -.. note:: - - The guidelines below are more restrictive than strictly necessary. We will try to add a larger list of acceptable licenses once we have approval from Red Hat Legal. - -There are four types of content in collections which licensing has to address in different -ways: - -:modules: must be licensed with a free software license that is compatible with the - `GPL-3.0-or-later `_ -:module_utils: must be licensed with a free software license that is compatible with the - `GPL-3.0-or-later `_. Ansible - itself typically uses the `BSD-2-clause - `_ license to make it possible for - third-party modules which are licensed incompatibly with the GPLv3 to use them. - Please consider this use case when licensing your own ``module_utils``. -:All other code in ``plugins/``: All other code in ``plugins/`` must be under the `GPL-3.0-or-later - `_. These plugins - are run inside of the Ansible controller process which is licensed under - the ``GPL-3.0-or-later`` and often must import code from the controller. - For these reasons, ``GPL-3.0-or-later`` must be used. -:All other code: Code outside ``plugins/`` may be licensed under another free software license that is compatible - with the `GPL-3.0-or-later `_, - provided that such code does not import any other code that is licensed under - the ``GPL-3.0-or-later``. If the file does import other ``GPL-3.0-or-later`` code, - then it must similarly be licensed under ``GPL-3.0-or-later``. Note that this applies in - particular to unit tests; these often import code from ansible-core, plugins, module utils, - or modules, and such code is often licensed under ``GPL-3.0-or-later``. -:Non code content: At the moment, these must also be under the `GPL-3.0-or-later - `_. - -Use `this table of licenses from the Fedora Project -`_ to find which licenses are -compatible with the GPLv3+. The license must be considered open source on both the Fedora License -table and the `Debian Free Software Guidelines `_ to be -allowed. - -These guidelines are the policy for inclusion in the Ansible package and are in addition to any -licensing and legal concerns that may otherwise affect your code. - -.. _coll_repo_management: - -Repository management -===================== - -Every collection MUST have a public git repository. Releases of the collection MUST be tagged in said repository. This means that releases MUST be ``git tag``\ ed and that the tag name MUST exactly match the Galaxy version number. Tag names MAY have a ``v`` prefix, but a collection's tag names MUST have a consistent format from release to release. - -Additionally, collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's git repository as that release. Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced. - -We are open to allowing other SCM software once our tooling supports them. - -.. _coll_branch_config: - -Branch name and configuration ------------------------------ - -This subsection is **only** for repositories under `ansible-collections `_! Other collection repositories can also follow these guidelines, but do not have to. - -All new repositories MUST have ``main`` as the default branch. - -Existing repositories SHOULD be converted to use ``main``. - -Repository Protections: - -* Allow merge commits: disallowed - -Branch protections MUST be enforced: - -* Require linear history -* Include administrators - -.. _coll_ci_tests: - -CI Testing -=========== - -.. note:: - - You can copy the free-to-use `GitHub action workflow file `_ from the `Collection Template repository `_ to the `.github/workflows` directory in your collection to set up testing through GitHub actions. The workflow covers all the requirements below. - -* You MUST run the ``ansible-test sanity`` command from the `latest stable ansible-base/ansible-core branch `_. - - * Collections MUST run an equivalent of the ``ansible-test sanity --docker`` command. - * If they do not use ``--docker``, they must make sure that all tests run, in particular the compile and import tests (which should run for all :ref:`supported Python versions `). - * Collections can choose to skip certain Python versions that they explicitly do not support; this needs to be documented in ``README.md`` and in every module and plugin (hint: use a docs fragment). However we strongly recommend you follow the :ref:`Ansible Python Compatibility ` section for more details. - -* You SHOULD suggest to *additionally* run ``ansible-test sanity`` from the ansible/ansible ``devel`` branch so that you find out about new linting requirements earlier. -* The sanity tests MUST pass. - - * Adding some entries to the ``test/sanity/ignore*.txt`` file is an allowed method of getting them to pass, except cases listed below. - * You SHOULD not have ignored test entries. A reviewer can manually evaluate and approve your collection if they deem an ignored entry to be valid. - - * You MUST not ignore the following validations. They must be fixed before approval: - * ``validate-modules:doc-choices-do-not-match-spec`` - * ``validate-modules:doc-default-does-not-match-spec`` - * ``validate-modules:doc-missing-type`` - * ``validate-modules:doc-required-mismatch`` - * ``validate-modules:mutually_exclusive-unknown`` - * ``validate-modules:no-log-needed`` (use ``no_log=False`` in the argument spec to flag false positives!) - * ``validate-modules:nonexistent-parameter-documented`` - * ``validate-modules:parameter-list-no-elements`` - * ``validate-modules:parameter-type-not-in-doc`` - * ``validate-modules:undocumented-parameter`` - - * All entries in ignores.txt MUST have a justification in a comment in the ignore.txt file for each entry. For example ``plugins/modules/docker_container.py use-argspec-type-path # uses colon-separated paths, can't use type=path``. - * Reviewers can block acceptance of a new collection if they don't agree with the ignores.txt entries. - -* You MUST run CI against each of the "major versions" (2.10, 2.11, 2.12, etc) of ``ansible-base``/``ansible-core`` that the collection supports. (Usually the ``HEAD`` of the stable-xxx branches.) -* All CI tests MUST run against every pull request and SHOULD pass before merge. -* At least sanity tests MUST run against a commit that releases the collection; if they do not pass, the collection will NOT be released. - - - If the collection has integration/unit tests, they SHOULD run too; if they do not pass, the errors SHOULD be analyzed to decide whether they should block the release or not. -* All CI tests MUST run regularly (nightly, or at least once per week) to ensure that repositories without regular commits are tested against the latest version of ansible-test from each ansible-base/ansible-core version tested. The results from the regular CI runs MUST be checked regularly. - -All of the above can be achieved by using the `GitHub Action template `_. - -To learn how to add tests to your collection, see: - -* :ref:`collection_integration_tests` -* :ref:`collection_unit_tests` - - -.. _coll_wg_reqs: - -Collections and Working Groups -============================== - -The collections have: - -* Working group page(s) on a corresponding wiki if needed. Makes sense if there is a group of modules for working with one common entity, for example postgresql, zabbix, grafana, and so on. -* Issue for agenda (or pinboard if there are not regular meetings) as a pinned issue in the repository. - -.. _coll_migrating_reqs: - -When moving modules between collections -======================================= - -All related entities must be moved/copied including: - -* Related plugins and module_utils files (when moving, be sure it is not used by other modules, otherwise copy). -* CI and unit tests. -* Corresponding documentation fragments from ``plugins/doc_fragments``. - -Also: - -* Change ``M()``, examples, ``seealso``, ``extended_documentation_fragments`` to use actual FQCNs in moved content and in other collections that have references to the content. -* Move all related issues, pull requests, and wiki pages. -* Look through ``docs/docsite`` directory of `ansible-base GitHub repository `_ (for example, using the ``grep`` command-line utility) to check if there are examples using the moved modules and plugins to update their FQCNs. - -See :ref:`Migrating content to a different collection ` for complete details. - -.. _coll_development_conventions: - -Development conventions -======================= - -Besides all the requirements listed in the :ref:`module_dev_conventions`, be sure: - -* Your modules satisfy the concept of :ref:`idempotency `: if a module repeatedly runs with the same set of inputs, it will not make any changes on the system. -* Your modules do not query information using special ``state`` option values like ``get``, ``list``, ``query``, or ``info`` - - create new ``_info`` or ``_facts`` modules instead (for more information, refer to the :ref:`Developing modules guidelines `). -* ``check_mode`` is supported in all ``*_info`` and ``*_facts`` modules (for more information, refer to the :ref:`Development conventions <#following-ansible-conventions>`). - -.. _coll_dependencies: - -Collection Dependencies -======================= - -**Notation:** if foo.bar has a dependency on baz.bam, we say that baz.bam is the collection *depended on*, and foo.bar is the *dependent collection*. - -* Collection dependencies must have a lower bound on the version which is at least 1.0.0. - - * This means that all collection dependencies have to specify lower bounds on the versions, and these lower bounds should be stable releases, and not versions of the form 0.x.y. - * When creating new collections where collection dependencies are also under development, you need to watch out since Galaxy checks whether dependencies exist in the required versions: - - #. Assume that ``foo.bar`` depends on ``foo.baz``. - #. First release ``foo.baz`` as 1.0.0. - #. Then modify ``foo.bar``'s ``galaxy.yml`` to specify ``'>=1.0.0'`` for ``foo.baz``. - #. Finally release ``foo.bar`` as 1.0.0. - -* The dependencies between collections included in Ansible must be valid. If a dependency is violated, the involved collections must be pinned so that all dependencies are valid again. This means that the version numbers from the previous release are kept or only partially incremented so that the resulting set of versions has no invalid dependencies. - -* If a collection has a too strict dependency for a longer time, and forces another collection depended on to be held back, that collection will be removed from the next major Ansible release. What "longer time" means depends on when the next Ansible major release happens. If a dependent collection prevents a new major version of a collection it depends on to be included in the next major Ansible release, the dependent collection will be removed from that major release to avoid blocking the collection being depended on. - -* We strongly suggest that collections also test against the ``main`` branches of their dependencies to ensure that incompatibilities with future releases of these are detected as early as possible and can be resolved in time to avoid such problems. Collections depending on other collections must understand that they bear the risk of being removed when they do not ensure compatibility with the latest releases of their dependencies. - -* Collections included in Ansible must not depend on other collections except if they satisfy one of the following cases: - - #. They have a loose dependency on one (or more) major versions of other collections included in Ansible. For example, ``ansible.netcommon: >=1.0.0``, or ``ansible.netcommon: >=2.0.0, <3.0.0``. In case the collection depended on releases a new major version outside of this version range that will be included in the next major Ansible release, the dependent collection will be removed from the next major Ansible release. The cut-off date for this is feature freeze. - #. They are explicitly being allowed to do so by the Steering Committee. - -Examples --------- - -#. ``community.foo 1.2.0`` has a dependency on ``community.bar >= 1.0.0, < 1.3.0``. - - * Now ``community.bar`` creates a new release ``1.3.0``. When ``community.foo`` does not create a new release with a relaxed dependency, we have to include ``community.bar 1.2.x`` in the next Ansible release despite ``1.3.0`` being available. - * If ``community.foo`` does not relax its dependency on ``community.bar`` for some time, ``community.foo`` will be removed from the next Ansible major release. - * Unfortunately ``community.bar`` has to stay at ``1.2.x`` until either ``community.foo`` is removed (in the next major release), or loosens its requirements so that newer ``community.bar 1.3.z`` releases can be included. - -#. ``community.foonetwork`` depends on ``ansible.netcommon >= 2.0.0, <3.0.0``. - - * ``ansible.netcommon 4.0.0`` is released during this major Ansible release cycle. - * ``community.foonetwork`` either releases a new version before feature freeze of the next major Ansible release that allows depending on all ``ansible.netcommon 4.x.y`` releases, or it will be removed from the next major Ansible release. - -.. _coll_inclusion_reqs: - -Requirements for collections to be included in the Ansible Package -================================================================== - -To be included in the `ansible` package, collections must meet the following criteria: - -* :ref:`Development conventions `. -* `Collection requirements `_ (this document). - - * The `Collection Inclusion Criteria Checklist `_ covers most of the criteria from this document. -* :ref:`Ansible documentation format ` and the :ref:`style guide `. -* To pass the Ansible :ref:`sanity tests `. -* To have :ref:`unit `_and / or :ref:`integration tests ` according to the corresponding sections of this document. - - -Other requirements -=================== - -* After content is moved out of another currently included collection such as ``community.general`` or ``community.network`` OR a new collection satisfies all the requirements, add the collection to the ``ansible.in`` file in a corresponding directory of the `ansible-build-data repository `_. \ No newline at end of file diff --git a/docs/docsite/rst/community/collection_contributors/collection_reviewing.rst b/docs/docsite/rst/community/collection_contributors/collection_reviewing.rst deleted file mode 100644 index 4a379dcda62..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_reviewing.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _review_checklist: - -Review checklist for collection PRs -==================================== - -Use this section as a checklist reminder of items to review when you review a collection PR. - -Reviewing bug reports ----------------------- - -When users report bugs, verify the behavior reported. Remember always to be kind with your feedback. - -* Did the user make a mistake in the code they put in the Steps to Reproduce issue section? We often see user errors reported as bugs. -* Did the user assume an unexpected behavior? Ensure that the related documentation is clear. If not, the issue is useful to help us improve documentation. -* Is there a minimal reproducer? If not, ask the reporter to reduce the complexity to help pinpoint the issue. -* Is the issue a consequence of a misconfigured environment? -* If it seems to be a real bug, does the behaviour still exist in the most recent release or the development branch? -* Reproduce the bug, or if you do not have a suitable infrastructure, ask other contributors to reproduce the bug. - - -Reviewing suggested changes ---------------------------- - -When reviewing PRs, verify that the suggested changes do not: - -* Unnecessarily break backward compatibility. -* Bring more harm than value. -* Introduce non-idempotent solutions. -* Duplicate already existing features (inside or outside the collection). -* Violate the :ref:`Ansible development conventions `. - - -Other standards to check for in a PR include: - -* A pull request MUST NOT contain a mix of bug fixes and new features that are not tightly related. If yes, ask the author to split the pull request into separate PRs. -* If the pull request is not a documentation fix, it must include a :ref:`changelog fragment `. Check the format carefully as follows: - - * New modules and plugins (that are not jinja2 filter and test plugins) do not need changelog fragments. - * For jinja2 filter and test plugins, check out the `special syntax for changelog fragments `_. - * The changelog content contains useful information for end users of the collection. - -* If new files are added with the pull request, they follow the :ref:`coll_licensing_req`. -* The changes follow the :ref:`Ansible documentation standards ` and the :ref:`style_guide`. -* The changes follow the :ref:`Development conventions `. -* If a new plugin is added, it is one of the :ref:`allowed plugin types `. -* Documentation, examples, and return sections use FQCNs for the ``M(..)`` :ref:`format macros ` when referring to modules. -* Modules and plugins from ansible-core use ``ansible.builtin.`` as an FQCN prefix when mentioned. -* When a new option, module, plugin, or return value is added, the corresponding documentation or return sections use ``version_added:`` containing the *collection* version in which they will be first released. - - * This is typically the next minor release, sometimes the next major release. For example: if 2.7.5 is the current release, the next minor release will be 2.8.0, and the next major release will be 3.0.0). - -* FQCNs are used for ``extends_documentation_fragment:``, unless the author is referring to doc_fragments from ansible-core. -* New features have corresponding examples in the :ref:`examples_block`. -* Return values are documented in the :ref:`return_block`. - - -Review tests in the PR ----------------------- -Review the following if tests are applicable and possible to implement for the changes included in the PR: - - -* Where applicable, the pull request has :ref:`testing_integration` and :ref:`testing_units`. -* All changes are covered. For example, a bug case or a new option separately and in sensible combinations with other options. -* Integration tests cover ``check_mode`` if supported. -* Integration tests check the actual state of the system, not only what the module reports. For example, if the module actually changes a file, check that the file was changed by using the ``ansible.builtin.stat`` module.. -* Integration tests check return values, if applicable. - - -Review for merge commits and breaking changes ---------------------------------------------- - -* The pull request does not contain merge commits. See the GitHub warnings at the bottom of the pull request. If merge commits are present, ask the author to rebase the pull request branch. -* If the pull request contains breaking changes, ask the author and the collection maintainers if it really is needed, and if there is a way not to introduce breaking changes. If breaking changes are present, they MUST only appear in the next major release and MUST NOT appear in a minor or patch release. The only exception is breaking changes caused by security fixes that are absolutely necessary to fix the security issue. - diff --git a/docs/docsite/rst/community/collection_contributors/collection_test_pr_locally.rst b/docs/docsite/rst/community/collection_contributors/collection_test_pr_locally.rst deleted file mode 100644 index 7b01e2df8ce..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_test_pr_locally.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _collection_pr_test: - -**************************** -How to test a collection PR -**************************** - -Reviewers and issue authors can verify a PR fixes the reported bug by testing the PR locally. - -.. contents:: - :local: - -.. _collection_prepare_environment: - -Prepare your environment -======================== - -We assume that you use Linux as a work environment (you can use a virtual machine as well) and have ``git`` installed. - - -1. :ref:`Install Ansible ` or ansible-core. - -2. Create the following directories in your home directory: - - .. code:: bash - - mkdir -p ~/ansible_collections/NAMESPACE/COLLECTION_NAME - - For example, if the collection is ``community.general``: - - .. code:: bash - - mkdir -p ~/ansible_collections/community/general - - If the collection is ``ansible.posix``: - - .. code:: bash - - mkdir -p ~/ansible_collections/ansible/posix - - -3. Clone the forked repository from the author profile to the created path: - - .. code:: bash - - git clone https://github.com/AUTHOR_ACC/COLLECTION_REPO.git ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -4. Go to the cloned repository. - - .. code:: bash - - cd ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -5. Checkout the PR branch (it can be retrieved from the PR's page): - - .. code:: bash - - git checkout pr_branch - - -Test the Pull Request -===================== - -1. Include `~/ansible_collections` in `COLLECTIONS_PATHS`. See :ref:`COLLECTIONS_PATHS` for details. - -2. Run your playbook using the PR branch and verify the PR fixed the bug. - -3. Give feedback on the pull request or the linked issue(s). diff --git a/docs/docsite/rst/community/collection_contributors/collection_unit_tests.rst b/docs/docsite/rst/community/collection_contributors/collection_unit_tests.rst deleted file mode 100644 index 7a758c50155..00000000000 --- a/docs/docsite/rst/community/collection_contributors/collection_unit_tests.rst +++ /dev/null @@ -1,162 +0,0 @@ - -.. _collection_unit_tests: - -****************************** -Add unit tests to a collection -****************************** - -This section describes all of the steps needed to add unit tests to a collection and how to run them locally using the ``ansible-test`` command. - -See :ref:`testing_units_modules` for more details. - -.. contents:: - :local: - -Understanding the purpose of unit tests -======================================== - -Unit tests ensure that a section of code (known as a ``unit``) meets its design requirements and behaves as intended. Some collections do not have unit tests but it does not mean they are not needed. - - -A ``unit`` is a function or method of a class used in a module or plugin. Unit tests verify that a function with a certain input returns the expected output. - -Unit tests should also verify when a function raises or handles exceptions. - -Ansible uses `pytest `_ as a testing framework. - -See :ref:`testing_units_modules` for complete details. - -Inclusion in the Ansible package :ref:`requires integration and/or unit tests ` You should have tests for your collection as well as for individual modules and plugins to make your code more reliable To learn how to get started with integration tests, see :ref:`collection_integration_tests`. - - -See :ref:`collection_prepare_local` to prepare your environment. - -.. _collection_unit_test_required: - -Determine if unit tests exist -============================= - -Ansible collection unit tests are located in the ``tests/units`` directory. - -The structure of the unit tests matches the structure of the code base, so the tests can reside in the ``tests/units/plugins/modules/`` and ``tests/units/plugins/module_utils`` directories. There can be sub-directories, if modules are organized by module groups. - -If you are adding unit tests for ``my_module`` for example, check to see if the tests already exist in the collection source tree with the path ``tests/units/plugins/modules/test_my_module.py``. - -Example of unit tests -===================== - -Let's assume that the following function is in ``my_module`` : - -.. code:: python - - def convert_to_supported(val): - """Convert unsupported types to appropriate.""" - if isinstance(val, decimal.Decimal): - return float(val) - - if isinstance(val, datetime.timedelta): - return str(val) - - if val == 42: - raise ValueError("This number is just too cool for us ;)") - - return val - -Unit tests for this function should, at a minimum, check the following: - -* If the function gets a ``Decimal`` argument, it returns a corresponding ``float`` value. -* If the function gets a ``timedelta`` argument, it returns a corresponding ``str`` value. -* If the function gets ``42`` as an argument, it raises a ``ValueError``. -* If the function gets an argument of any other type, it does nothing and returns the same value. - -To write these unit tests in collection is called ``community.mycollection``: - -1. If you already have your local environment :ref:`prepared `, go to the collection root directory. - - .. code:: bash - - cd ~/ansible_collection/community/mycollection - -2. Create a test file for ``my_module``. If the path does not exist, create it. - - .. code:: bash - - touch tests/units/plugins/modules/test_my_module.py - -3. Add the following code to the file: - - .. code:: python - - # -*- coding: utf-8 -*- - - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - from datetime import timedelta - from decimal import Decimal - - import pytest - - from ansible_collections.community.mycollection.plugins.modules.my_module import ( - convert_to_supported, - ) - - # We use the @pytest.mark.parametrize decorator to parametrize the function - # https://docs.pytest.org/en/latest/how-to/parametrize.html - # Simply put, the first element of each tuple will be passed to - # the test_convert_to_supported function as the test_input argument - # and the second element of each tuple will be passed as - # the expected argument. - # In the function's body, we use the assert statement to check - # if the convert_to_supported function given the test_input, - # returns what we expect. - @pytest.mark.parametrize('test_input, expected', [ - (timedelta(0, 43200), '12:00:00'), - (Decimal('1.01'), 1.01), - ('string', 'string'), - (None, None), - (1, 1), - ]) - def test_convert_to_supported(test_input, expected): - assert convert_to_supported(test_input) == expected - - def test_convert_to_supported_exception(): - with pytest.raises(ValueError, match=r"too cool"): - convert_to_supported(42) - - See :ref:`testing_units_modules` for examples on how to mock ``AnsibleModule`` objects, monkeypatch methods (``module.fail_json``, ``module.exit_json``), emulate API responses, and more. - -4. Run the tests using docker: - - .. code:: bash - - ansible-test units tests/unit/plugins/modules/test_my_module.py --docker - - -.. _collection_recommendation_unit: - -Recommendations on coverage -=========================== - -Use the following tips to organize your code and test coverage: - -* Make your functions simple. Small functions that do one thing with no or minimal side effects are easier to test. -* Test all possible behaviors of a function including exception related ones such as raising, catching and handling exceptions. -* When a function invokes the ``module.fail_json`` method, passed messages should also be checked. - -.. seealso:: - - :ref:`testing_units_modules` - Unit testing Ansible modules - :ref:`developing_testing` - Ansible Testing Guide - :ref:`collection_integration_tests` - Integration testing for collections - :ref:`testing_integration` - Integration tests guide - :ref:`testing_collections` - Testing collections - :ref:`testing_resource_modules` - Resource module integration tests - :ref:`collection_pr_test` - How to test a pull request locally diff --git a/docs/docsite/rst/community/collection_contributors/test_index.rst b/docs/docsite/rst/community/collection_contributors/test_index.rst deleted file mode 100644 index 19a61422cf3..00000000000 --- a/docs/docsite/rst/community/collection_contributors/test_index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _testing_collections_guide: - -********************************************** -Testing Collection Contributions -********************************************** - -This section focuses on the different tests a contributor should run on their collection PR. - -.. toctree:: - :maxdepth: 1 - - collection_test_pr_locally - collection_unit_tests - collection_integration_tests diff --git a/docs/docsite/rst/community/collection_development_process.rst b/docs/docsite/rst/community/collection_development_process.rst deleted file mode 100644 index 3c2f609cce7..00000000000 --- a/docs/docsite/rst/community/collection_development_process.rst +++ /dev/null @@ -1,255 +0,0 @@ -.. _collection_development_process: - -****************************************** -The Ansible Collections Development Cycle -****************************************** - -Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. These repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections. - -Development on collections occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``. - -.. contents:: - :local: - - -Macro development: roadmaps, releases, and projects -===================================================================== - -If you want to follow the conversation about what features will be added to the Ansible package for upcoming releases and what bugs are being fixed, you can watch these resources: - -* the :ref:`roadmaps` -* the :ref:`Ansible Release Schedule ` -* the `Ansible Community Working Group `_ . - -Micro development: the lifecycle of a PR -======================================== - -If you want to contribute a feature or fix a bug in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection. Each collection has its own contributor guidelines so please check there for specific details. - -Here's an overview of the PR lifecycle: - -* :ref:`Contributor opens a PR ` -* CI runs the test suite -* Developers, maintainers, community review the PR -* Contributor addresses any feedback from reviewers -* Developers, maintainers, community re-review -* PR merged or closed - - -Making your PR merge-worthy -=========================== - -We do not merge every PR. See :ref:`collection_quickstart` for tips to make your PR useful, attractive, and merge-worthy. - -.. _collection_changelog_fragments: - -Creating changelog fragments ------------------------------ - -Most changelogs should emphasize the impact of the change on the end user of the feature or collection, unless the change impacts developers directly. Consider what the user needs to know about this change and write the changelog to convey that detail. - -Changelogs help users and developers keep up with changes to Ansible collections. Many collections build changelogs for each release from fragments. For collections that use this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug. - -You do not need a changelog fragment for PRs that: - -* add new modules and plugins, because Ansible tooling does that automatically; -* contain only documentation changes. - -.. note:: - Some collections require a changelog fragment for every pull request. They use the ``trivial:`` section for entries mentioned above that will be skipped when building a release changelog. - - -More precisely: - -* Every bugfix PR must have a changelog fragment. The only exception are fixes to a change that has not yet been included in a release. -* Every feature PR must have a changelog fragment. -* New modules and plugins (including jinja2 filter and test plugins) must have ``version_added`` entries set correctly in their documentation, and do not need a changelog fragment. The tooling detects new modules and plugins by their ``version_added`` values and announces them in the next release's changelog automatically. - -We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR. - -.. _collection_changelogs_how_to_format: - -Creating a changelog fragment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A basic changelog fragment is a ``.yaml`` or ``.yml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it. - -PRs which add a new module or plugin do not necessarily need a changelog fragment. See :ref:`community_changelogs`. Also see :ref:`changelogs_how_to_format` for the precise format changelog fragments should have. - -To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml`` or ``.yml``. For example: ``40696-user-backup-shadow-file.yaml`` - -A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our `release note tool `_. Here are the valid sections and a description of each: - -**breaking_changes** - MUST include changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Breaking changes means the user MUST make a change when they update. Breaking changes MUST only happen in a major release of the collection. Write in present tense and clearly describe the new behavior that the end user must now follow. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - breaking_changes: - - ec2_instance - instance wait for state behavior no longer waits for the instance monitoring status to become OK when launching a new instance. If plays require the old behavior, the action will need to specify ``state: started`` (https://github.com/ansible-collections/amazon.aws/pull/481). - - -**major_changes** - Major changes to ansible-core or a collection. SHOULD NOT include individual module or plugin changes. MUST include non-breaking changes that impact all or most of a collection (for example, updates to support a new SDK version across the collection). Major changes mean the user can CHOOSE to make a change when they update but do not have to. Could be used to announce an important upcoming EOL or breaking change in a future release. (ideally 6 months in advance, if known. See `this example `_). Write in present tense and describe what is new. Optionally, include a 'Previously..." sentence to help the user identify where old behavior should now change. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - major_changes: - - bitbucket_* modules - client_id is no longer marked as ``no_log=true``. If you relied on its value not showing up in logs and output, mark the whole tasks with ``no_log: true`` (https://github.com/ansible-collections/community.general/pull/2045). - -**minor_changes** - Minor changes to ansible-core, modules, or plugins. This includes new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding new values to choices[]. Minor changes are enhancements, not bug fixes. Write in present tense. - - .. code-block:: yaml - - minor_changes: - - nmcli - adds ``routes6`` and ``route_metric6`` parameters for supporting IPv6 routes (https://github.com/ansible-collections/community.general/issues/4059). - - -**deprecated_features** - Features that have been deprecated and are scheduled for removal in a future release. Write in past tense. Include an alternative, where available, for the feature being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - deprecated_features: - - mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in ``community.general`` 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140). - - -**removed_features** - Features that were previously deprecated and are now removed. Write in past tense. Include an alternative, where available, for the feature being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - removed_features: - - acme_account_facts - the deprecated redirect has been removed. Use ``community.crypto.acme_account_info`` instead (https://github.com/ansible-collections/community.crypto/pull/290). - - -**security_fixes** - Fixes that address CVEs or resolve security concerns. MUST use security_fixes for any CVEs. Write in present tense. Include links to CVE information. - - .. code-block:: yaml - - security_fixes: - - win_psexec - ensure password is masked in ``psexec_``command return result (https://github.com/ansible-collections/community.windows/issues/43). - - -**bugfixes** - Fixes that resolve issues. SHOULD NOT be used for minor enhancements (use ``minor_change`` instead). Write in past tense to describe the problem and present tense to describe the fix. - - .. code-block:: yaml - - bugfixes: - - apt_repository - fix crash caused by a timeout. The ``cache.update()`` was raising an ``IOError`` because of a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995). - - -**known_issues** - Known issues that are currently not fixed or will not be fixed. Write in present tense to describe the problem and in imperative tense to describe any available workaround. - - .. code-block:: yaml - - known_issues: - - idrac_user - module may error out with the message ``unable to perform the import or export operation`` because there are pending attribute changes or a configuration job is in progress. Wait for the job to complete and run the task again.(https://github.com/dell/dellemc-openmanage-ansible-modules/pull/303). - - -**trivial** - Changes where a formal release changelog entry isn't required. ``trivial`` changelog fragments are excluded from the published changelog output and may be used for changes such as housekeeping, documentation and test only changes. - You can use ``trivial`` for collections that require a changelog fragment for each pull request. - - .. code-block:: yaml - - trivial: - - aws_ec2 - fix broken integration test (https://github.com/ansible-collections/amazon.aws/pull/1269). - - -Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself. - -Most changelog entries are ``bugfixes`` or ``minor_changes``. - - -Changelog fragment entry format -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When writing a changelog entry, use the following format: - -.. code-block:: yaml - - - scope - description starting with a lowercase letter and ending with a period at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - -The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``). - -For changes that are not really scoped (for example, which affect a whole collection), use the following format: - -.. code-block:: yaml - - - Description starting with an uppercase letter and ending with a dot at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - - -Here are some examples: - -.. code-block:: yaml - - bugfixes: - - apt_repository - fix crash caused by ``cache.update()`` raising an ``IOError`` - due to a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995). - -.. code-block:: yaml - - minor_changes: - - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443). - -.. code-block:: yaml - - bugfixes: - - copy - the module was attempting to change the mode of files for - remote_src=True even if mode was not set as a parameter. This failed on - filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444). - -You can find more example changelog fragments in the `changelog directory `_ for the community.general development branch. - -After you have written the changelog fragment for your PR, commit the file and include it with the pull request. - - -Changelog fragment entry format for new jinja2 plugins, roles, and playbooks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While new modules and plugins that are not jinja2 filter or test plugins are mentioned automatically in the generated changelog, jinja2 filter and test plugins, roles, and playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed: - -.. code-block:: yaml - - # A new jinja2 filter plugin: - add plugin.filter: - - # The following needs to be the name of the filter itself, not of the file - # the filter is included in! - name: to_time_unit - # The description should be in the same format as short_description for - # other plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Converts a time expression to a given unit - - # A new jinja2 test plugin: - add plugin.test: - - # The following needs to be the name of the test itself, not of the file - # the test is included in! - name: asn1time - # The description should be in the same format as short_description for - # other plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Check whether the given string is an ASN.1 time - - # A new role: - add object.role: - - # This should be the short (non-FQCN) name of the role. - name: nginx - # The description should be in the same format as short_description for - # plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: A nginx installation role - - # A new playbook: - add object.playbook: - - # This should be the short (non-FQCN) name of the playbook. - name: wipe_server - # The description should be in the same format as short_description for - # plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Wipes a server diff --git a/docs/docsite/rst/community/committer_guidelines.rst b/docs/docsite/rst/community/committer_guidelines.rst deleted file mode 100644 index 7067a5a266c..00000000000 --- a/docs/docsite/rst/community/committer_guidelines.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _community_committer_guidelines: - -********************* -Committers Guidelines -********************* - -These are the guidelines for people with commit privileges on the repositories in the ansible and ansible-collections GitHub organizations. - -Committers of `Ansible-core `_ are necessarily Red Hat employees acting as members of the Ansible Core team. Committers of `Ansible collections `_ are members of the community or Ansible Engineering. Please read the guidelines before you commit. - -These guidelines apply to everyone. At the same time, this is NOT a process document. So just use good judgment. You have been given commit access because we trust your judgment. - -That said, use the trust wisely. - -If you abuse the trust and break components and builds, and so on, the trust level falls and you may be asked not to commit or you may lose your commit privileges. - -Features, high-level design, and roadmap of ansible-core -======================================================== - -As a core team member, you are an integral part of the team that develops the :ref:`roadmap `. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, and so on, for various releases. Red Hat, the company, and the Ansible team must get these changes completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it affects a lot of other parts within Ansible. - -Any other new features and changes to high level design should go through the proposal process (TBD), to ensure the community and core team have had a chance to review the idea and approve it. The core team has sole responsibility for merging new features based on proposals to `Ansible-core `_. - - -Features, high-level design, and roadmap of Ansible collections -=============================================================== - -Collections maintainers define features, high-level design, and roadmap of the collections themselves and are responsible for merging new features to `Ansible collections `_ based on proposals discussed with their communities. - -Our workflow on GitHub -====================== - -As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you are aware of the following workflow steps: - -* Fork the repository upon which you want to do some work to your own personal repository -* Work on the specific branch upon which you need to commit -* Create a pull request back to the upstream repository and tag the people you would like to review; assign someone as the primary "owner" of your pull request -* Adjust code as necessary based on the comments provided -* Ask someone from the repository committers to do a final review and merge - -Addendum to workflow for committers: ------------------------------------- - -The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules by making direct commits or merging their own pull requests. This section is a set of guidelines. If you are changing a comma in documentation, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work. - -Roles on Core -============= -* Core committers: Fine to do pull requests for most things, but we should have a timebox. Hanging pull requests may merge on the judgement of these developers. -* :ref:`Module maintainers `: Module maintainers own specific modules and have indirect commit access through the current module pull request mechanisms. -* :ref:`Collection maintainers `: Collection maintainers own specific collections and have commit access to them. Each collection can set its own rules for contributions. - -.. _committer_general_rules: - -General rules -============= -Individuals with direct commit access are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement. - -* Do NOT - - - Commit directly. - - Merge your own pull requests. Someone else should have a chance to review and approve the pull request merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes. - - Forget about alternate environments. Consider the alternatives--yes, people have bad environments, but they are the ones who need us the most. - - Drag your community team members down. Discuss the technical merits of any pull requests you review. Avoid negativity and personal comments. For more guidance on being a good community member, read our :ref:`code_of_conduct`. - - Forget about the maintenance burden. High-maintenance features may not be worth adding. - - Break playbooks. Always keep backwards compatibility in mind. - - Forget to keep it simple. Complexity breeds all kinds of problems. - -* Do - - - Squash, avoid merges whenever possible, use GitHub's squash commits or cherry pick if needed (bisect thanks you). - - Be active. Committers who have no activity on the project (through merges, triage, commits, and so on) will have their permissions suspended. - - Consider backwards compatibility (goes back to "do not break existing playbooks"). - - Write :ref:`tests` and be sure that other's pull requests you are reviewing are covered well. Pull requests with tests are looked at with more priority than pull requests without tests that should have them included. While not all changes require tests, be sure to add them for new features, bug fixes, and functionality changes. - - Discuss with other committers, specially when you are unsure of something. - - Document! If your pull request is a new feature or a change to behavior, make sure you have updated all associated documentation or have notified the right people to do so. It also helps to add the version of ``ansible-core`` or ``collection`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on). - - Consider scope, sometimes a fix can be generalized. - - Keep it simple, then things are maintainable, debuggable, and intelligible. - -Committers are expected to continue to follow the same community and contribution guidelines followed by the rest of the Ansible community. diff --git a/docs/docsite/rst/community/communication.rst b/docs/docsite/rst/community/communication.rst deleted file mode 100644 index 1e8bc645434..00000000000 --- a/docs/docsite/rst/community/communication.rst +++ /dev/null @@ -1,179 +0,0 @@ -.. _communication: - -***************************************** -Communicating with the Ansible community -***************************************** - -.. contents:: - :local: - -Code of Conduct -=============== - -All communication and interactions in the Ansible Community are governed by our :ref:`code_of_conduct`. Please read and understand it! - -Asking questions over email -=========================== - -If you want to keep up with Ansible news, need help, or have a question, you can use one of the Ansible mailing lists. Each list covers a particular topic. Read the descriptions here to find the best list for your question. - -Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear. - -* `Ansible Announce list `_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series. Worth subscribing to! -* `Ansible AWX List `_ is for `Ansible AWX `_ -* `Ansible Development List `_ is for questions about developing Ansible modules (mostly in Python), fixing bugs in the Ansible core code, asking about prospective feature design, or discussions about extending Ansible or features in progress. -* `Ansible Outreach List `_ help with promoting Ansible and `Ansible Meetups `_ -* `Ansible Project List `_ is for sharing Ansible tips, answering questions about playbooks and roles, and general user discussion. -* `Molecule Discussions `_ is designed to aid with the development and testing of Ansible roles with Molecule. - -The Ansible mailing lists are hosted on Google, but you do not need a Google account to subscribe. To subscribe to a group from a non-Google account, send an email to the subscription address requesting the subscription. For example: ``ansible-devel+subscribe@googlegroups.com``. - -.. _communication_irc: - -Real-time chat -============== - -For real-time interactions, conversations in the Ansible community happen over two chat protocols: Matrix and IRC. We maintain a bridge between Matrix and IRC, so you can choose whichever protocol you prefer. All channels exist in both places. Join a channel any time to ask questions, participate in a Working Group meeting, or just say hello. - -Ansible community on Matrix ---------------------------- - -To join the community using Matrix, you need two things: - -* a Matrix account (from `Matrix.org `_ or any other Matrix homeserver) -* a `Matrix client `_ (we recommend `Element Webchat `_) - -The Ansible community maintains its own Matrix homeserver at ``ansible.im``, however public registration is currently unavailable. - -Matrix chat supports: - -* persistence (when you log on, you see all messages since you last logged off) -* edits (Lets you fix typos and so on. **NOTE** Each edit you make on Matrix re-sends the message to IRC. Please try to avoid multiple edits!) -* replies to individual users -* reactions/emojis -* bridging to IRC -* no line limits -* images - -The room links in the :ref:`general_channels` or in the :ref:`working_group_list` list will take you directly to the relevant rooms. - -If there is no appropriate room for your community, please create it. - -For more information, see the community-hosted `Matrix FAQ `_. - -Ansible community on IRC ------------------------- - -The Ansible community maintains several IRC channels on `irc.libera.chat `_. To join the community using IRC, you need one thing: - -* an IRC client - -IRC chat supports: - -* no persistence (you only see messages when you are logged on unless you add a bouncer) -* simple text interface -* bridging from Matrix - -Our IRC channels may require you to register your IRC nickname. If you receive an error when you connect or when posting a message, see `libera.chat's Nickname Registration guide `_ for instructions. To find all ``ansible`` specific channels on the libera.chat network, use the following command in your IRC client: - -.. code-block:: text - - /msg alis LIST #ansible* -min 5 - -as described in the `libera.chat docs `_. - -Our channels record history on the Matrix side. The channel history can be viewed in a browser - all channels will report an appropriate link to ``chat.ansible.im`` in their Chanserv entrymsg upon joining the room. Alternatively, a URL of the form ``https://chat.ansible.im/#/room/# {IRC channel name}:libera.chat`` will also work, for example - for the #ansible-docs channel it would be `https://app.element.io/#/room/#ansible-docs:libera.chat`. - -.. _general_channels: - -General channels ----------------- - -The clickable links will take you directly to the relevant Matrix room in your browser; room/channel information is also given for use in other clients: - -- `Community social room and posting news for the Bullhorn newsletter `_ - ``Matrix: #social:ansible.com | IRC: #ansible-social`` -- `General usage and support questions `_ - ``Matrix: #users:ansible.com | IRC: #ansible`` -- `Discussions on developer topics and code related to features or bugs `_ - ``Matrix: #devel:ansible.com | IRC: #ansible-devel`` -- `Discussions on community and collections related topics `_ - ``Matrix: #community:ansible.com | IRC: #ansible-community`` -- `For public community meetings `_ - ``Matrix: #meeting:ansible.im | IRC: #ansible-meeting`` - - We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page `_ - -.. _working_group_list: - -Working groups --------------- - -Many of our community `Working Groups `_ meet in chat. If you want to get involved in a working group, join the Matrix room or IRC channel where it meets or comment on the agenda. - -- `AAP Configuration as Code `_ - Matrix: `#aap_config_as_code:ansible.com `_ -- `Amazon (AWS) Working Group `_ - Matrix: `#aws:ansible.com `_ | IRC: ``#ansible-aws`` -- `AWX Working Group `_ - Matrix: `#awx:ansible.com `_ | IRC: ``#ansible-awx`` -- `Azure Working Group `_ - Matrix: `#azure:ansible.com `_ | IRC: ``#ansible-azure`` -- `Community Working Group `_ (including Meetups) - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community`` -- `Container Working Group `_ - Matrix: `#container:ansible.com `_ | IRC: ``#ansible-container`` -- `Contributor Experience Working Group `_ - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community`` -- `DigitalOcean Working Group `_ - Matrix: `#digitalocean:ansible.im `_ | IRC: ``#ansible-digitalocean`` -- `Diversity Working Group `_ - Matrix: `#diversity:ansible.com `_ | IRC: ``#ansible-diversity`` -- `Docker Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel`` -- `Documentation Working Group `_ - Matrix: `#docs:ansible.com `_ | IRC: ``#ansible-docs`` -- `Galaxy Working Group `_ - Matrix: `#galaxy:ansible.com `_ | IRC: ``#ansible-galaxy`` -- `JBoss Working Group `_ - Matrix: `#jboss:ansible.com `_ | IRC: ``#ansible-jboss`` -- `Kubernetes Working Group `_ - Matrix: `#kubernetes:ansible.com `_ | IRC: ``#ansible-kubernetes`` -- `Linode Working Group `_ - Matrix: `#linode:ansible.com `_ | IRC: ``#ansible-linode`` -- `Molecule Working Group `_ (`testing platform for Ansible playbooks and roles `_) - Matrix: `#molecule:ansible.im `_ | IRC: ``#ansible-molecule`` -- `MySQL Working Group `_ - Matrix: `#mysql:ansible.com `_ -- `Network Working Group `_ - Matrix: `#network:ansible.com `_ | IRC: ``#ansible-network`` -- `PostgreSQL Working Group `_ - Matrix: `#postgresql:ansible.com `_ -- `Remote Management Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel`` -- `Security Automation Working Group `_ - Matrix: `#security-automation:ansible.com `_ | IRC: ``#ansible-security`` -- `Storage Working Group `_ - Matrix: `#storage:ansible.com `_ | IRC: ``#ansible-storage`` -- `Testing Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel`` -- `VMware Working Group `_ - Matrix: `#vmware:ansible.com `_ | IRC: ``#ansible-vmware`` -- `Windows Working Group `_ - Matrix: `#windows:ansible.com `_ | IRC: ``#ansible-windows`` -- `Ansible developer tools Group `_ - Matrix: `#devtools:ansible.com `_ | IRC: ``#ansible-devtools`` - -Want to `form a new Working Group `_? - -Regional and Language-specific channels ---------------------------------------- - -- Comunidad Ansible en español - Matrix: `#espanol:ansible.im `_ | IRC: ``#ansible-es`` -- Communauté française d'Ansible - Matrix: `#francais:ansible.im `_ | IRC: ``#ansible-fr`` -- Communauté suisse d'Ansible - Matrix: `#suisse:ansible.im `_ | IRC: ``#ansible-zh`` -- European Ansible Community - Matrix: `#europe:ansible.im `_ | IRC: ``#ansible-eu`` - -Meetings on chat ----------------- - -The Ansible community holds regular meetings on various topics on Matrix/IRC, and anyone who is interested is invited to participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page `_. - -Ansible Community Topics -======================== - -The `Ansible Community Steering Committee `_ uses the `community-topics repository `_ to asynchronously discuss with the Community and vote on Community topics in corresponding issues. - -Create a new issue in the `repository `_ if you want to discuss an idea that impacts any of the following: - -* Ansible Community -* Community collection best practices and `requirements `_ -* `Community collection inclusion policy `_ -* `The Community governance `_ -* Other proposals of importance that need the Committee or overall Ansible community attention - -Ansible Automation Platform support questions -============================================= - -Red Hat Ansible `Automation Platform `_ is a subscription that contains support, certified content, and tooling for Ansible including content management, a controller, UI and REST API. - -If you have a question about Ansible Automation Platform, visit `Red Hat support `_ rather than using a chat channel or the general project mailing list. - -The Bullhorn -============ - -**The Bullhorn** is our newsletter for the Ansible contributor community. Please `subscribe `_ to receive it. - -If you have any content you would like to share, please `contribute/suggest it `_ for upcoming releases. - -If you have any questions, please reach out to us at ``the-bullhorn@redhat.com``. - -Read past issues on the official Bullhorn's `wiki page `_. diff --git a/docs/docsite/rst/community/contributing_maintained_collections.rst b/docs/docsite/rst/community/contributing_maintained_collections.rst deleted file mode 100644 index f7c0d1d9168..00000000000 --- a/docs/docsite/rst/community/contributing_maintained_collections.rst +++ /dev/null @@ -1,304 +0,0 @@ - -.. _contributing_maintained_collections: - -*********************************************** -Contributing to Ansible-maintained Collections -*********************************************** - -The Ansible team welcomes community contributions to the collections maintained by Red Hat Ansible Engineering. This section describes how you can open issues and create PRs with the required testing before your PR can be merged. - -.. contents:: - :local: - -Ansible-maintained collections -================================= - -The following table shows: - -* **Ansible-maintained collection** - Click the link to the collection on Galaxy, then click the ``repo`` button in Galaxy to find the GitHub repository for this collection. -* **Related community collection** - Collection that holds community-created content (modules, roles, and so on) that may also be of interest to a user of the Ansible-maintained collection. You can, for example, add new modules to the community collection as a technical preview before the content is moved to the Ansible-maintained collection. -* **Sponsor** - Working group that manages the collections. You can join the meetings to discuss important proposed changes and enhancements to the collections. -* **Test requirements** - Testing required for any new or changed content for the Ansible-maintained collection. -* **Developer details** - Describes whether the Ansible-maintained collection accepts direct community issues and PRs for existing collection content, as well as more specific developer guidelines based on the collection type. - - -.. _ansible-collection-table: - -.. raw:: html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Collection detailsTest requirements: Ansible collectionsDeveloper details
    Ansible collectionRelated community collectionSponsorSanityUnitIntegrationCI PlatformOpen to PRs*Guidelines
    amazon.awscommunity.awsAWS✓****✓Zuul✓AWS guide
    ansible.netcommon***community.networkNetwork✓✓✓Zuul✓Network guide
    ansible.posixcommunity.generalLinux✓Zuul✓Developer guide
    ansible.windowscommunity.windowsWindows✓✓****✓Azure Pipelines and Zuul✓Windows guide
    arista.eoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    cisco.asacommunity.asaSecurity✓✓✓Zuul✓Developer guide
    cisco.ioscommunity.networkNetwork✓✓✓Zuul✓Network guide
    cisco.iosxrcommunity.networkNetwork✓✓✓Zuul✓Network guide
    cisco.nxoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    ibm.qradarcommunity.qradarSecurity✓✓Zuul✓Developer guide
    junipernetworks.junoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    kubernetes.corekubernetes.coreKubernetes✓✓✓GitHub Actions✓
    redhat.openshiftcommunity.okdKubernetes✓✓✓GitHub Actions✓
    openvswitch.openvswitchcommunity.networkNetwork✓✓✓Zuul✓Network guide
    splunk.escommunity.esSecurity✓✓Zuul✓Developer guide
    vyos.vyoscommunity.networkNetwork✓✓✓Zuul✓Network guide
    vmware.vmware_restvmware.vmware_restVMware✓✓✓Zuul✓VMware REST guide
    - - -.. note:: - - \* A ✓ under **Open to PRs** means the collection welcomes GitHub issues and PRs for any changes to existing collection content (plugins, roles, and so on). - - \*\* Integration tests are required and unit tests are welcomed but not required for the AWS collections. An exception to this is made in cases where integration tests are logistically not feasible due to external requirements. An example of this is AWS Direct Connect, as this service can not be functionally tested without the establishment of network peering connections. Unit tests are therefore required for modules that interact with AWS Direct Connect. Exceptions to ``amazon.aws`` must be approved by Red Hat, and exceptions to ``community.aws`` must be approved by the AWS community. - - \*\*\* ``ansible.netcommon`` contains all foundational components for enabling many network and security :ref:`platform ` collections. It contains all connection and filter plugins required, and installs as a dependency when you install the platform collection. - - \*\*\*\* Unit tests for Windows PowerShell modules are an exception to testing, but unit tests are valid and required for the remainder of the collection, including Ansible-side plugins. - - -.. _which_collection: - -Deciding where your contribution belongs -========================================= - -We welcome contributions to Ansible-maintained collections. Because these collections are part of a downstream supported Red Hat product, the criteria for contribution, testing, and release may be higher than other community collections. The related community collections (such as ``community.general`` and ``community.network``) have less-stringent requirements and are a great place for new functionality that may become part of the Ansible-maintained collection in a future release. - -The following scenarios use the ``arista.eos`` to help explain when to contribute to the Ansible-maintained collection, and when to propose your change or idea to the related community collection: - - -1. You want to fix a problem in the ``arista.eos`` Ansible-maintained collection. Create the PR directly in the `arista.eos collection GitHub repository `_. Apply all the :ref:`merge requirements `. - -2. You want to add a new Ansible module for Arista. Your options are one of the following: - - * Propose a new module in the ``arista.eos`` collection (requires approval from Arista and Red Hat). - * Propose a new collection in the ``arista`` namespace (requires approval from Arista and Red Hat). - * Propose a new module in the ``community.network`` collection (requires network community approval). - * Place your new module in a collection in your own namespace (no approvals required). - - -Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the ``arista`` namespace, where inclusion and maintenance criteria are much higher. - - -.. _ansible_collection_merge_requirements: - -Requirements to merge your PR -============================== - -Your PR must meet the following requirements before it can merge into an Ansible-maintained collection: - - -#. The PR is in the intended scope of the collection. Communicate with the appropriate Ansible sponsor listed in the :ref:`Ansible-maintained collection table ` for help. -#. For network and security domains, the PR follows the :ref:`resource module development principles `. -#. Passes :ref:`sanity tests and tox `. -#. Passes unit, and integration tests, as listed in the :ref:`Ansible-maintained collection table ` and described in :ref:`testing_resource_modules`. -#. Follows Ansible guidelines. See :ref:`developing_modules` and :ref:`developing_collections`. -#. Addresses all review comments. -#. Includes an appropriate :ref:`changelog `. diff --git a/docs/docsite/rst/community/contributions.rst b/docs/docsite/rst/community/contributions.rst deleted file mode 100644 index e3b3eb8c518..00000000000 --- a/docs/docsite/rst/community/contributions.rst +++ /dev/null @@ -1,29 +0,0 @@ -.. _community_contributions: - -******************************** -ansible-core Contributors Guide -******************************** - -.. toctree:: - :maxdepth: 2 - - reporting_bugs_and_features - documentation_contributions - development_process - other_tools_and_programs - - -If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group `. - -Working with the Ansible repo -============================= - -* I want to make my first code changes to a collection or to ``ansible-core``. How do I :ref:`set up my Python development environment `? -* I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts? -* I want my code to meet Ansible's guidelines. Where can I find guidance on :ref:`coding in Ansible `? -* I would like to connect Ansible to a new API or other resource. How do I :ref:`create a collection `? -* My pull request is marked ``needs_rebase``. How do I :ref:`rebase my PR `? -* I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR `? -* I have an open pull request with a failing test. How do I learn about Ansible's :ref:`testing (CI) process `? -* I am ready to step up as a collection maintainer. What are the :ref:`guidelines for maintainers `? -* A module in a collection I maintain is obsolete. How do I :ref:`deprecate a module `? diff --git a/docs/docsite/rst/community/contributions_collections.rst b/docs/docsite/rst/community/contributions_collections.rst deleted file mode 100644 index 7b1aad4c6c0..00000000000 --- a/docs/docsite/rst/community/contributions_collections.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _collections_contributions: - -************************************* -Ansible Collections Contributor Guide -************************************* - -.. toctree:: - :maxdepth: 2 - - collection_development_process - reporting_collections - create_pr_quick_start - collection_contributors/test_index - collection_contributors/collection_reviewing - collection_contributors/collection_requirements - maintainers - contributing_maintained_collections - steering/steering_index - documentation_contributions - other_tools_and_programs - - - -If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group `. - -Working with the Ansible collection repositories -================================================= - -* How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts? -* Where can I find guidance on :ref:`coding in Ansible `? -* How do I :ref:`create a collection `? -* How do I :ref:`rebase my PR `? -* How do I learn about Ansible's :ref:`testing (CI) process `? -* How do I :ref:`deprecate a module `? -* See `Collection developer tutorials `_ for a quick introduction on how to develop and test your collection contributions. diff --git a/docs/docsite/rst/community/contributor_license_agreement.rst b/docs/docsite/rst/community/contributor_license_agreement.rst deleted file mode 100644 index b0a0f11736c..00000000000 --- a/docs/docsite/rst/community/contributor_license_agreement.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _contributor_license_agreement: - -****************************** -Contributors License Agreement -****************************** - -By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project. diff --git a/docs/docsite/rst/community/contributor_path.rst b/docs/docsite/rst/community/contributor_path.rst deleted file mode 100644 index 124505859f2..00000000000 --- a/docs/docsite/rst/community/contributor_path.rst +++ /dev/null @@ -1,114 +0,0 @@ -**************** -Contributor path -**************** - -This section describes the contributor's journey from the beginning to becoming a leader who helps shape the future of Ansible. You can use this path as a roadmap for your long-term participation. - -Any contribution to the project, even a small one, is very welcome and valuable. Any contribution counts, whether it's feedback on an issue, a pull request, a topic or documentation change, or a coding contribution. When you contribute regularly, your proficiency and judgment in the related area increase and, along with this, the importance of your presence in the project. - -.. contents:: - :local: - - - -Determine your area of interest -================================= - -First, determine areas that are interesting to you. Consider your current experience and what you'd like to gain. For example, if you use a specific collection, have a look there. See :ref:`how_can_i_help` for more ideas on how to help. - -Find the corresponding project -==================================== - -These are multiple community projects in the Ansible ecosystem you could contribute to: - -- `Ansible Core `_ -- `Collections `_ -- `AWX `_ -- `Galaxy `_ -- `ansible-lint `_ -- `Molecule `_ - -Learn -===== - -The required skillset depends on the area of interest and the project you'll be working on. Remember that the best way to learn is by doing. - -Specific knowledge for code developers ----------------------------------------- - -Code development requires the most technical knowledge. Let's sort out what an Ansible developer should learn. - - -You should understand at least the *basics* of the following tools: - -- `Python programming language `_ -- `Git `_ -- `GitHub collaborative development model through forks and pull requests `_ - -You can learn these tools more in-depth when working on your first contributions. - - -Each Ansible project has its own set of contributor guidelines. Familiarize yourself with these as you prepare your first contributions. - -* :ref:`Ansible Core development `. -* :ref:`Ansible collection development ` and the collection-level contributor guidelines in the collection repository. - - -Making your first contribution -============================== - -You can find some ideas on how you can contribute in :ref:`how_can_i_help`. - -If you are interested in contributing to collections, take a look at :ref:`collection contributions` and the `collection repository `_'s ``README`` and ``CONTRIBUTING`` files. To make your first experience as smooth as possible, read the repository documentation carefully, then ask the repository maintainers for guidance if you have any questions. - -Take a look at GitHub issues labeled with the ``easyfix`` and ``good_first_issue`` labels for: - -- `Ansible collections repositories `_ -- `All other Ansible projects `_ - -Issues labeled with the ``docs`` label in `Ansible collections `_ and `other `_ Ansible projects can be also good to start with. - -When you choose an issue to work on, add a comment directly on the GitHub issue to say you are looking at it and let others know to avoid conflicting work. -You can also ask for help in a comment if you need it. - -Continue to contribute -====================== - -We don't expect everybody to know everything. Start small, think big. When you contribute regularly, your proficiency and judgment in the related area will improve quickly and, along with this, the importance of your presence in the project. - -See :ref:`communication` for ways to communicate and engage with the Ansible community, including working group meetings, accessing the Bullhorn news bulletin, and upcoming contributor summits. - - -Teach others -============ - -Share your experience with other contributors through :ref:`improving documentation`, answering questions from other contributors and users on :ref:`Matrix/Libera.Chat IRC`, giving advice on issues and pull requests, and discussing `Community Topics `_. - -Become a collection maintainer -=============================== - -If you are a code contributor to a collection, you can get extended permissions in the repository and become a maintainer. A collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and showed themselves as a specialist in the related area. See :ref:`maintainers` for details. - -For some collections that use the `collection bot `_, such as `community.general `_ and `community.network `_, you can have different levels of access and permissions. - -* :ref:`module_maintainers` - The stage prior to becoming a collection maintainer. The file is usually a module or plugin. File maintainers have indirect commit rights. -* supershipit permissions - Similar to being a file maintainer but the scope where a maintainer has the indirect commit is the whole repository. -* ``triage`` - Access to the repository that allows contributors to manage issues and pull requests. -* ``write`` access to the repository also known as ``commit``. In other words, become a committer. This access level allows contributors to merge pull requests to the development branch as well as perform all the other activities listed in the :ref:`maintainers`. - -For information about permission levels, see the `GitHub official documentation `_. - -Become a steering committee member -================================== - -.. note:: - - You do NOT have to be a programmer to become a steering committee member. - -The :ref:`Steering Committee ` member status reflects the highest level of trust which allows contributors to lead the project by making very important `decisions `_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general. - -To reach the status, as the current Committee members did before getting it, along with the things mentioned in this document, you should: - -* Subscribe to, comment on, and vote on the `Community Topics `_. -* Propose your topics. -* If time permits, join the `Community meetings `_. Note this is **NOT** a requirement. diff --git a/docs/docsite/rst/community/create_pr_quick_start.rst b/docs/docsite/rst/community/create_pr_quick_start.rst deleted file mode 100644 index 5e4ed023df6..00000000000 --- a/docs/docsite/rst/community/create_pr_quick_start.rst +++ /dev/null @@ -1,272 +0,0 @@ -.. _collection_quickstart: - -******************************************** -Creating your first collection pull request -******************************************** - -This section describes all steps needed to create your first patch and submit a pull request on a collection. - -.. _collection_prepare_local: - -Prepare your environment -======================== - -.. note:: - - These steps assume a Linux work environment with ``git`` installed. - - -1. Install and start ``docker`` or ``podman``. This ensures tests run properly isolated and in the same environment as in CI. - -2. :ref:`Install Ansible or ansible-core `. You need the ``ansible-test`` utility which is provided by either of these packages. - -3. Create the following directories in your home directory: - - .. code-block:: bash - - $ mkdir -p ~/ansible_collections/NAMESPACE/COLLECTION_NAME - - - For example, if the collection is ``community.mysql``, it would be: - - .. code-block:: bash - - $ mkdir -p ~/ansible_collections/community/mysql - - -4. Fork the collection repository through the GitHub web interface. - -5. Clone the forked repository from your profile to the created path: - - .. code-block:: bash - - $ git clone https://github.com/YOURACC/COLLECTION_REPO.git ~/ansible_collections/NAMESPACE/COLLECTION_NAME - - If you prefer to use the SSH protocol: - - .. code-block:: bash - - $ git clone git@github.com:YOURACC/COLLECTION_REPO.git ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -6. Go to your new cloned repository. - - .. code-block:: bash - - $ cd ~/ansible_collections/NAMESPACE/COLLECTION_NAME - -7. Ensure you are in the default branch (it is usually ``main``): - - .. code-block:: bash - - $ git status - -8. Show remotes. There should be the ``origin`` repository only: - - .. code-block:: bash - - $ git remote -v - -9. Add the ``upstream`` repository: - - .. code-block:: bash - - $ git remote add upstream https://github.com/ansible-collections/COLLECTION_REPO.git - - This is the repository where you forked from. - -10. Update your local default branch. Assuming that it is ``main``: - - .. code-block:: bash - - $ git fetch upstream - $ git rebase upstream/main - -11. Create a branch for your changes: - - .. code-block:: bash - - $ git checkout -b name_of_my_branch - -Change the code -=============== - -.. note:: - - Do NOT mix several bug fixes or features that are not tightly related in one pull request. Use separate pull requests for different changes. - -You should start with writing integration and unit tests if applicable. These can verify the bug exists (prior to your code fix) and verify your code fixed that bug once the tests pass. - -.. note:: - - If there are any difficulties with writing or running the tests or you are not sure if the case can be covered, you can skip this step. Other contributors can help you with tests later if needed. - -.. note:: - - Some collections do not have integration tests. In this case, unit tests are required. - -All integration tests are stored in ``tests/integration/targets`` subdirectories. -Go to the subdirectory containing the name of the module you are going to change. -For example, if you are fixing the ``mysql_user`` module in the ``community.mysql`` collection, -its tests are in ``tests/integration/targets/test_mysql_user/tasks``. - -The ``main.yml`` file holds test tasks and includes other test files. -Look for a suitable test file to integrate your tests or create and include a dedicated test file. -You can use one of the existing test files as a draft. - -When fixing a bug, write a task that reproduces the bug from the issue. - -Put the reported case in the tests, then run integration tests with the following command: - -.. code-block:: bash - - $ ansible-test integration name_of_test_subdirectory --docker -v - -For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is as follows: - -.. code-block:: bash - - $ ansible-test integration test_mysql_user --docker -v - -You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. - -In the examples above, the default test image is automatically downloaded and used to create and run a test container. -Use the default test image for platform-independent integration tests such as those for cloud modules. - -If you need to run the tests against a specific distribution, see the :ref:`list of supported container images `. For example: - -.. code-block:: bash - - $ ansible-test integration name_of_test_subdirectory --docker fedora35 -v - -.. note:: - - If you are not sure whether you should use the default image for testing or a specific one, skip the entire step - the community can help you later. You can also try to use the collection repository's CI to figure out which containers are used. - -If the tests ran successfully, there are usually two possible outcomes: - -- If the bug has not appeared and the tests have passed successfully, ask the reporter to provide more details. It may not be a bug or can relate to a particular software version used or specifics of the reporter's local environment configuration. -- The bug has appeared and the tests have failed as expected showing the reported symptoms. - -Fix the bug -============= - -See :ref:`module_contribution` for some general guidelines about Ansible module development that may help you craft a good code fix for the bug. - -Test your changes -================= - -1. Install ``flake8`` (``pip install flake8``, or install the corresponding package on your operating system). - -2. Run ``flake8`` against a changed file: - - .. code-block:: bash - - $ flake8 path/to/changed_file.py - - - This shows unused imports, which are not shown by sanity tests, as well as other common issues. - Optionally, you can use the ``--max-line-length=160`` command-line argument. - -3. Run sanity tests: - - .. code-block:: bash - - $ ansible-test sanity path/to/changed_file.py --docker -v - - If they failed, look at the output carefully - it is informative and helps to identify a problem line quickly. - Sanity failings usually relate to incorrect code and documentation formatting. - -4. Run integration tests: - - .. code-block:: bash - - $ ansible-test integration name_of_test_subdirectory --docker -v - - For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is: - - .. code-block:: bash - - $ ansible-test integration test_mysql_user --docker -v - - You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output. - - -There are two possible outcomes: - -- They have failed. Look at the output of the command. Fix the problem in the code and run again. Repeat the cycle until the tests pass. -- They have passed. Remember they failed originally? Our congratulations! You have fixed the bug. - -In addition to the integration tests, you can also cover your changes with unit tests. This is often required when integration tests are not applicable to the collection. - -We use `pytest `_ as a testing framework. - -Files with unit tests are stored in the ``tests/unit/plugins/`` directory. If you want to run unit tests, say, for ``tests/unit/plugins/test_myclass.py``, the command is: - -.. code-block:: bash - - $ ansible-test units tests/unit/plugins/test_myclass.py --docker - -If you want to run all unit tests available in the collection, run: - -.. code-block:: bash - - $ ansible-test units --docker - -Submit a pull request -===================== - -1. Commit your changes with an informative but short commit message: - - .. code-block:: bash - - $ git add /path/to/changed/file - $ git commit -m "module_name_you_fixed: fix crash when ..." - -2. Push the branch to ``origin`` (your fork): - - .. code-block:: bash - - $ git push origin name_of_my_branch - -3. In a browser, navigate to the ``upstream`` repository (http://github.com/ansible-collections/COLLECTION_REPO). - -4. Click the :guilabel:`Pull requests` tab. - - GitHub is tracking your fork, so it should see the new branch in it and automatically offer to create a pull request. Sometimes GitHub does not do it, and you should click the :guilabel:`New pull request` button yourself. Then choose :guilabel:`compare across forks` under the :guilabel:`Compare changes` title. - -5. Choose your repository and the new branch you pushed in the right drop-down list. Confirm. - - a. Fill out the pull request template with all information you want to mention. - - b. Put ``Fixes + link to the issue`` in the pull request's description. - - c. Put ``[WIP] + short description`` in the pull request's title. Mention the name of the module/plugin you are modifying at the beginning of the description. - - d. Click :guilabel:`Create pull request`. - -6. Add a :ref:`changelog fragment ` to the ``changelogs/fragments`` directory. It will be published in release notes, so users will know about the fix. - - a. Run the sanity test for the fragment: - - .. code-block:: bash - - $ansible-test sanity changelogs/fragments/ --docker -v - - - b. If the tests passed, commit and push the changes: - - .. code-block:: bash - - $ git add changelogs/fragments/myfragment.yml - $ git commit -m "Add changelog fragment" - $ git push origin name_of_my_branch - -7. Verify the CI tests pass that run automatically on Red Hat infrastructure after every commit. - - You will see the CI status at the bottom of your pull request. If they are green and you think that you do not want to add more commits before someone should take a closer look at it, remove ``[WIP]`` from the title. Mention the issue reporter in a comment and let contributors know that the pull request is "Ready for review". - -8. Wait for reviews. You can also ask for a review in the ``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel `. - -9. If the pull request looks good to the community, committers will merge it. - -For more in-depth details on this process, see the :ref:`Ansible developer guide `. diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst deleted file mode 100644 index 26f87356048..00000000000 --- a/docs/docsite/rst/community/development_process.rst +++ /dev/null @@ -1,368 +0,0 @@ -.. _community_development_process: - -***************************** -The Ansible Development Cycle -***************************** - -Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository `_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections. - -Development on ``ansible-core`` occurs on two levels. At the macro level, the ``ansible-core`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle. - -Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``. - -.. contents:: - :local: - -Macro development: ``ansible-core`` roadmaps, releases, and projects -===================================================================== - -If you want to follow the conversation about what features will be added to ``ansible-core`` for upcoming releases and what bugs are being fixed, you can watch these resources: - -* the :ref:`roadmaps` -* the :ref:`Ansible Release Schedule ` -* the :ref:`ansible-core project branches and tags ` -* various GitHub `projects `_ - for example: - - * the `2.15 release project `_ - * the `core documentation project `_ - - -.. _community_pull_requests: - - -Micro development: the lifecycle of a PR -======================================== - -If you want to contribute a feature or fix a bug in ``ansible-core`` or in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-core``. -Here's an overview of the PR lifecycle: - -* Contributor opens a PR (always against the ``devel`` branch) -* Ansibot reviews the PR -* Ansibot assigns labels -* Ansibot pings maintainers -* Azure Pipelines runs the test suite -* Developers, maintainers, community review the PR -* Contributor addresses any feedback from reviewers -* Developers, maintainers, community re-review -* PR merged or closed -* PR :ref:`backported ` to one or more ``stable-X.Y`` branches (optional, bugfixes only) - -Automated PR review: ansibullbot --------------------------------- - -Because Ansible receives many pull requests, and because we love automating things, we have automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short. - -`Ansibullbot `_ serves many functions: - -- Responds quickly to PR submitters to thank them for submitting their PR -- Identifies the community maintainer responsible for reviewing PRs for any files affected -- Tracks the current status of PRs -- Pings responsible parties to remind them of any PR actions for which they may be responsible -- Provides maintainers with the ability to move PRs through the workflow -- Identifies PRs abandoned by their submitters so that we can close them -- Identifies modules abandoned by their maintainers so that we can find new maintainers - -Ansibot workflow -^^^^^^^^^^^^^^^^ - -Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow: - -- If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to "reboot" this process.) -- If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state. -- If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while). -- If the pull request is in **community_review** and has received comments from the maintainer: - - - If the maintainer says ``shipit``, the pull request is labeled **shipit**, whereupon the Core team assesses it for final merge. - - If the maintainer says ``needs_info``, the pull request is labeled **needs_info** and the submitter is asked for more info. - - If the maintainer says **needs_revision**, the pull request is labeled **needs_revision** and the submitter is asked to fix some things. - -- If the submitter says ``ready_for_review``, the pull request is put back into **community_review** or **core_review** and the maintainer is notified that the pull request is ready to be reviewed again. -- If the pull request is labeled **needs_revision** or **needs_info** and the submitter has not responded lately: - - - The submitter is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending action**, and the issue or pull request will be closed two weeks after that. - - If the submitter responds at all, the clock is reset. -- If the pull request is labeled **community_review** and the reviewer has not responded lately: - - - The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer. -- If Azure Pipelines tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why. - -There are corner cases and frequent refinements, but this is the workflow in general. - -PR labels -^^^^^^^^^ - -There are two types of PR Labels generally: **workflow** labels and **information** labels. - -Workflow labels -""""""""""""""" - -- **community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community. -- **core_review**: Pull requests for modules that are currently awaiting review by their maintainers on the Ansible Core team. -- **needs_info**: Waiting on info from the submitter. -- **needs_rebase**: Waiting on the submitter to rebase. -- **needs_revision**: Waiting on the submitter to make changes. -- **shipit**: Waiting for final review by the core team for potential merge. - -Information labels -"""""""""""""""""" - -- **backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``. -- **bugfix_pull_request**: applied by the bot based on the templatized description of the PR. -- **cloud**: applied by the bot based on the paths of the modified files. -- **docs_pull_request**: applied by the bot based on the templatized description of the PR. -- **easyfix**: applied manually, inconsistently used but sometimes useful. -- **feature_pull_request**: applied by the bot based on the templatized description of the PR. -- **networking**: applied by the bot based on the paths of the modified files. -- **owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**. -- **pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on). - - -Special Labels -"""""""""""""" - -- **new_plugin**: this is for new modules or plugins that are not yet in Ansible. - -**Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process. - -Human PR review ---------------- - -After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies. - -Each module has at least one assigned :ref:`maintainer `, listed in the `BOTMETA.yml `_ file. - -The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``. - -Once a human applies the ``shipit`` label, the :ref:`committers ` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable. - - -Making your PR merge-worthy -=========================== - -We do not merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy. - -.. _community_changelogs: - -Creating changelog fragments ------------------------------- - -Changelogs help users and developers keep up with changes to ansible-core and Ansible collections. Ansible and many collections build changelogs for each release from fragments. For ansible-core and collections using this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug. - -You do not need a changelog fragment for PRs that: - -* add new modules and plugins, because Ansible tooling does that automatically; -* contain only documentation changes. - -.. note:: - Some collections require a changelog fragment for every pull request. They use the ``trivial:`` section for entries mentioned above that will be skipped when building a release changelog. - - -More precisely: - -* Every bugfix PR must have a changelog fragment. The only exception are fixes to a change that has not yet been included in a release. -* Every feature PR must have a changelog fragment. -* New modules and plugins (including jinja2 filter and test plugins) must have ``version_added`` entries set correctly in their documentation, and do not need a changelog fragment. The tooling detects new modules and plugins by their ``version_added`` values and announces them in the next release's changelog automatically. - -We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR. - -.. _changelogs_how_to: - -Creating a changelog fragment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A basic changelog fragment is a ``.yaml`` or ``.yml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it. - -PRs which add a new module or plugin do not necessarily need a changelog fragment. See the previous section :ref:`community_changelogs`. Also see the next section :ref:`changelogs_how_to_format` for the precise format changelog fragments should have. - -To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml`` or ``.yml``. For example: ``40696-user-backup-shadow-file.yaml`` - -A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our `release note tool `_. Here are the valid sections and a description of each: - -**breaking_changes** - MUST include changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Breaking changes means the user MUST make a change when they update. Breaking changes MUST only happen in a major release of the collection. Write in present tense and clearly describe the new behavior that the end user must now follow. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - breaking_changes: - - ansible-test - automatic installation of requirements for cloud test plugins no longer occurs. The affected test plugins are ``aws``, ``azure``, ``cs``, ``hcloud``, ``nios``, ``opennebula``, ``openshift`` and ``vcenter``. Collections should instead use one of the supported integration test requirements files, such as the ``tests/integration/requirements.txt`` file (https://github.com/ansible/ansible/pull/75605). - - -**major_changes** - Major changes to ansible-core or a collection. SHOULD NOT include individual module or plugin changes. MUST include non-breaking changes that impact all or most of a collection (for example, updates to support a new SDK version across the collection). Major changes mean the user can CHOOSE to make a change when they update but do not have to. Could be used to announce an important upcoming EOL or breaking change in a future release. (ideally 6 months in advance, if known. See `this example `_). Write in present tense and describe what is new. Optionally, include a 'Previously..." sentence to help the user identify where old behavior should now change. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - major_changes: - - ansible-test - all cloud plugins which use containers can now be used with all POSIX and Windows hosts. Previously the plugins did not work with Windows at all, and support for hosts created with the ``--remote`` option was inconsistent (https://github.com/ansible/ansible/pull/74216). - -**minor_changes** - Minor changes to ansible-core, modules, or plugins. This includes new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding additional values to choices[]. Minor changes are enhancements, not bug fixes. Write in present tense. - - .. code-block:: yaml - - minor_changes: - - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443). - - -**deprecated_features** - Features that have been deprecated and are scheduled for removal in a future release. Use past tense and include an alternative, where available for what is being deprecated.. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - deprecated_features: - - include action - is deprecated in favor of ``include_tasks``, ``import_tasks`` and ``import_playbook`` (https://github.com/ansible/ansible/pull/71262). - - -**removed_features** - Features that were previously deprecated and are now removed. Use past tense and include an alternative, where available for what is being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `. - - .. code-block:: yaml - - removed_features: - - _get_item() alias - removed from callback plugin base class which had been deprecated in favor of ``_get_item_label()`` (https://github.com/ansible/ansible/pull/70233). - - -**security_fixes** - Fixes that address CVEs or resolve security concerns. MUST use security_fixes for any CVEs. Use present tense. Include links to CVE information. - - .. code-block:: yaml - - security_fixes: - - set_options -do not include params in exception when a call to ``set_options`` fails. Additionally, block the exception that is returned from being displayed to stdout. (CVE-2021-3620). - - -**bugfixes** - Fixes that resolve issues. SHOULD not be used for minor enhancements (use ``minor_change`` instead). Use past tense to describe the problem and present tense to describe the fix. - - .. code-block:: yaml - - bugfixes: - - ansible_play_batch - variable included unreachable hosts. Fix now saves unreachable hosts between plays by adding them to the PlayIterator's ``_play._removed_hosts`` (https://github.com/ansible/ansible/issues/66945). - - -**known_issues** - Known issues that are currently not fixed or will not be fixed. Use present tense and where available, use imperative tense for a workaround. - - .. code-block:: yaml - - known_issues: - - ansible-test - tab completion anywhere other than the end of the command with the new composite options provides incorrect results (https://github.com/kislyuk/argcomplete/issues/351). - - -Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself. - -Most changelog entries are ``bugfixes`` or ``minor_changes``. The changelog tool also supports ``trivial``, which are not listed in the actual changelog output but are used by collections repositories that require a changelog fragment for each PR. - - - -.. _changelogs_how_to_format: - -Changelog fragment entry format -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When writing a changelog entry, use the following format: - -.. code-block:: yaml - - - scope - description starting with a lowercase letter and ending with a period at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - -The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``). - -For changes that are not really scoped (for example, which affect a whole collection), use the following format: - -.. code-block:: yaml - - - Description starting with an uppercase letter and ending with a dot at the very end. Multiple sentences are allowed (https://github.com/reference/to/an/issue or, if there is no issue, reference to a pull request itself). - - -Here are some examples: - -.. code-block:: yaml - - bugfixes: - - apt_repository - fix crash caused by ``cache.update()`` raising an ``IOError`` - due to a timeout in ``apt update`` (https://github.com/ansible/ansible/issues/51995). - -.. code-block:: yaml - - minor_changes: - - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443). - -.. code-block:: yaml - - bugfixes: - - copy - the module was attempting to change the mode of files for - remote_src=True even if mode was not set as a parameter. This failed on - filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444). - -You can find more example changelog fragments in the `changelog directory `_ for the 2.12 release. - -After you have written the changelog fragment for your PR, commit the file and include it with the pull request. - -.. _changelogs_how_to_format_playbooks: - -Changelog fragment entry format for new playbooks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While new modules, plugins, and roles are mentioned automatically in the generated changelog, playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed: - -.. code-block:: yaml - - # A new playbook: - add object.playbook: - - # This should be the short (non-FQCN) name of the playbook. - name: wipe_server - # The description should be in the same format as short_description for - # plugins and modules: it should start with an upper-case letter and - # not have a period at the end. - description: Wipes a server - -.. _backport_process: - -Backporting merged PRs in ``ansible-core`` -=========================================== - -All ``ansible-core`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch. - -We do **not** backport features. - -.. note:: - - These instructions assume that: - - * ``stable-2.14`` is the targeted release branch for the backport - * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly. - * ``https://github.com//ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly. - -#. Prepare your devel, stable, and feature branches: - -.. code-block:: shell - - git fetch upstream - git checkout -b backport/2.14/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.14 - -#. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary: - -.. code-block:: shell - - git cherry-pick -x [SHA_FROM_DEVEL] - -#. Add a :ref:`changelog fragment ` for the change, and commit it. - -#. Push your feature branch to your fork on GitHub: - -.. code-block:: shell - - git push origin backport/2.14/[PR_NUMBER_FROM_DEVEL] - -#. Submit the pull request for ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.14`` branch - -#. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green. - -.. note:: - - The branch name ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches. - -.. note:: - - If you prefer, you can use CPython's cherry-picker tool (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits from devel to stable branches in Ansible. Take a look at the `cherry-picker documentation `_ for details on installing, configuring, and using it. diff --git a/docs/docsite/rst/community/documentation_contributions.rst b/docs/docsite/rst/community/documentation_contributions.rst deleted file mode 100644 index 082a7b25b02..00000000000 --- a/docs/docsite/rst/community/documentation_contributions.rst +++ /dev/null @@ -1,242 +0,0 @@ -.. _community_documentation_contributions: - -***************************************** -Contributing to the Ansible Documentation -***************************************** - -Ansible has a lot of documentation and a small team of writers. Community support helps us keep up with new features, fixes, and changes. - -Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText `_ (rST). Some collection-level documentation is written in a subset of `Markdown `_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option. - -If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation: - -.. contents:: - :local: - -Editing docs directly on GitHub -=============================== - -For typos and other quick fixes, you can edit most of the documentation right from the site. Look at the top right corner of this page. That ``Edit on GitHub`` link is available on all the guide pages in the documentation. If you have a GitHub account, you can submit a quick and easy pull request this way. - -.. note:: - - The source files for individual collection plugins exist in their respective repositories. Follow the link to the collection on Galaxy to find where the repository is located and any guidelines on how to contribute to that collection. - -To submit a documentation PR from docs.ansible.com with ``Edit on GitHub``: - -#. Click on ``Edit on GitHub``. -#. If you don't already have a fork of the ansible repo on your GitHub account, you'll be prompted to create one. -#. Fix the typo, update the example, or make whatever other change you have in mind. -#. Enter a commit message in the first rectangle under the heading ``Propose file change`` at the bottom of the GitHub page. The more specific, the better. For example, "fixes typo in my_module description". You can put more detail in the second rectangle if you like. Leave the ``+label: docsite_pr`` there. -#. Submit the suggested change by clicking on the green "Propose file change" button. GitHub will handle branching and committing for you, and open a page with the heading "Comparing Changes". -#. Click on ``Create pull request`` to open the PR template. -#. Fill out the PR template, including as much detail as appropriate for your change. You can change the title of your PR if you like (by default it's the same as your commit message). In the ``Issue Type`` section, delete all lines except the ``Docs Pull Request`` line. -#. Submit your change by clicking on ``Create pull request`` button. -#. Be patient while Ansibot, our automated script, adds labels, pings the docs maintainers, and kicks off a CI testing run. -#. Keep an eye on your PR - the docs team may ask you for changes. - -Reviewing or solving open issues -================================ - -Review or solve open documentation issues for: - -- `Ansible projects `_ -- `Ansible collections `_ - -Reviewing open PRs -================== - -Review open documentation pull requests for: - -- Ansible `projects `_ -- Ansible `collections `_ - -To add a helpful review, please: - -- Test the change if applicable. -- Think if it can be made better (including wording, structure, fixing typos and so on). -- Suggest improvements. -- Approve the change with the ``looks good to me`` comment. - -Opening a new issue and/or PR -============================= - -If the problem you have noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the correct underlying repo - ``ansible/ansible`` for most pages that are not plugin or module documentation. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues. - -A great documentation GitHub issue or PR includes: - -- a specific title -- a detailed description of the problem (even for a PR - it's hard to evaluate a suggested change unless we know what problem it's meant to solve) -- links to other information (related issues/PRs, external documentation, pages on docs.ansible.com, and so on) - - -Verifying your documentation PR -================================ - -If you make multiple changes to the documentation on ``ansible/ansible``, or add more than a line to it, before you open a pull request, please: - -#. Check that your text follows our :ref:`style_guide`. -#. Test your changes for rST errors. -#. Build the page, and preferably the entire documentation site, locally. - -.. note:: - - The following sections apply to documentation sourced from the ``ansible/ansible`` repo and does not apply to documentation from an individual collection. See the collection README file for details on how to contribute to that collection. - -Setting up your environment to build documentation locally ----------------------------------------------------------- - -To build documentation locally, ensure you have a working :ref:`development environment `. - -To work with documentation on your local machine, you need to have python-3.9 or greater and install the `Ansible dependencies`_ and `documentation dependencies`_, which are listed in two files to make installation easier: - -.. _Ansible dependencies: https://github.com/ansible/ansible/blob/devel/requirements.txt -.. _documentation dependencies: https://github.com/ansible/ansible/blob/devel/docs/docsite/requirements.txt - -Drop the ``--user`` option in the following commands if you use a virtual environment (venv/virtenv). - -#. Upgrade pip before installing dependencies (recommended). - - .. code-block:: bash - - pip install --user --upgrade pip - -#. Install Ansible dependencies. - - .. code-block:: bash - - pip install --user -r requirements.txt - -#. Install either the unpinned or tested documentation dependencies. - - .. code-block:: bash - - pip install --user -r docs/docsite/requirements.txt # This file installs unpinned versions that can cause problems with the Ansible docs build. - pip install --user -r test/sanity/code-smell/docs-build.requirements.txt # This file installs tested dependency versions that are used by CI. - -.. note:: - - You may need to install these general pre-requisites separately on some systems: - - ``gcc`` - - ``libyaml`` - - ``make`` - - ``pyparsing`` - - ``six`` - On macOS with Xcode, you may need to install ``six`` and ``pyparsing`` with ``--ignore-installed`` to get versions that work with ``sphinx``. - -.. note:: - - After checking out ``ansible/ansible``, make sure the ``docs/docsite/rst`` directory has strict enough permissions. It should only be writable by the owner's account. If your default ``umask`` is not 022, you can use ``chmod go-w docs/docsite/rst`` to set the permissions correctly in your new branch. Optionally, you can set your ``umask`` to 022 to make all newly created files on your system (including those created by ``git clone``) have the correct permissions. - -.. _testing_documentation_locally: - -Testing the documentation locally ---------------------------------- - -To test an individual file for rST errors: - -.. code-block:: bash - - rstcheck changed_file.rst - -Building the documentation locally ----------------------------------- - -Building the documentation is the best way to check for errors and review your changes. Once `rstcheck` runs with no errors, navigate to ``ansible/docs/docsite`` and then build the page(s) you want to review. - - .. note:: - - If building on macOS with Python 3.8 or later, you must use Sphinx >= 2.2.2. See `#6803 `_ for details. - - - -Building a single rST page -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build a single rST file with the make utility: - -.. code-block:: bash - - make htmlsingle rst=path/to/your_file.rst - -For example: - -.. code-block:: bash - - make htmlsingle rst=community/documentation_contributions.rst - -This process compiles all the links but provides minimal log output. If you're writing a new page or want more detailed log output, refer to the instructions on :ref:`build_with_sphinx-build` - -.. note:: - - ``make htmlsingle`` adds ``rst/`` to the beginning of the path you provide in ``rst=``, so you can't type the filename with autocomplete. Here are the error messages you will see if you get this wrong: - - - If you run ``make htmlsingle`` from the ``docs/docsite/rst/`` directory: ``make: *** No rule to make target `htmlsingle'. Stop.`` - - If you run ``make htmlsingle`` from the ``docs/docsite/`` directory with the full path to your rST document: ``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']``. - - -Building all the rST pages -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build all the rST files without any module documentation: - -.. code-block:: bash - - MODULES=none make webdocs - -Building module docs and rST pages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build documentation for a few modules included in ``ansible/ansible`` plus all the rST files, use a comma-separated list: - -.. code-block:: bash - - MODULES=one_module,another_module make webdocs - -To build all the module documentation plus all the rST files: - -.. code-block:: bash - - make webdocs - -.. _build_with_sphinx-build: - -Building rST files with ``sphinx-build`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Advanced users can build one or more rST files with the sphinx utility directly. ``sphinx-build`` returns misleading ``undefined label`` warnings if you only build a single page, because it does not create internal links. However, ``sphinx-build`` returns more extensive syntax feedback, including warnings about indentation errors and ``x-string without end-string`` warnings. This can be useful, especially if you're creating a new page from scratch. To build a page or pages with ``sphinx-build``: - -.. code-block:: bash - - sphinx-build [options] sourcedir outdir [filenames...] - -You can specify filenames, or ``–a`` for all files, or omit both to compile only new/changed files. - -For example: - -.. code-block:: bash - - sphinx-build -b html -c rst/ rst/dev_guide/ _build/html/dev_guide/ rst/dev_guide/developing_modules_documenting.rst - -Running the final tests -^^^^^^^^^^^^^^^^^^^^^^^ - -When you submit a documentation pull request, automated tests are run. Those same tests can be run locally. To do so, navigate to the repository's top directory and run: - -.. code-block:: bash - - make clean && - bin/ansible-test sanity --test docs-build && - bin/ansible-test sanity --test rstcheck - -Unfortunately, leftover rST-files from previous document-generating can occasionally confuse these tests. It is therefore safest to run them on a clean copy of the repository, which is the purpose of ``make clean``. If you type these three lines one at a time and manually check the success of each, you do not need the ``&&``. - -Joining the documentation working group -======================================= - -The Documentation Working Group (DaWGs) meets weekly on Tuesdays in the Docs chat (using `Matrix `_ or using IRC at `irc.libera.chat `_). For more information, including links to our agenda and a calendar invite, please visit the `working group page in the community repo `_. - -.. seealso:: - :ref:`More about testing module documentation ` - - :ref:`More about documenting modules ` diff --git a/docs/docsite/rst/community/getting_started.rst b/docs/docsite/rst/community/getting_started.rst deleted file mode 100644 index b35225163bd..00000000000 --- a/docs/docsite/rst/community/getting_started.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _community_getting_started: - -**************** -Getting started -**************** - -Welcome and thank you for getting more involved with the Ansible community. Here are some ways you can get started. - -.. toctree:: - :maxdepth: 2 - - code_of_conduct - contributor_license_agreement - communication - how_can_I_help - - - -Other ways to get involved -========================== - -Here are some other ways to connect with the Ansible community: - -* Find an `Ansible Meetup near me `_ - communication -* Learn more about Ansible: - - * `Read books `_. - * `Get certified `_. - * `Attend events `_. - * `Review getting started guides `_. - * `Watch videos `_ - includes Ansible Automates, AnsibleFest & webinar recordings. -* See where `new releases are announced `_ diff --git a/docs/docsite/rst/community/github_admins.rst b/docs/docsite/rst/community/github_admins.rst deleted file mode 100644 index 802b180dd1f..00000000000 --- a/docs/docsite/rst/community/github_admins.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _github_admins: - -************* -GitHub Admins -************* - -.. contents:: Topics - -GitHub Admins have more permissions on GitHub than normal contributors or even committers. There are -a few responsibilities that come with that increased power. - - -Adding and removing committers -============================== - -The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke -contributors' ability to commit on their own. GitHub Admins are the people who have the power to -actually manage the GitHub permissions. - - -Changing branch permissions for releases -======================================== - -When we make releases we make people go through a :ref:`release_managers` to push commits to that -branch. The GitHub admins are responsible for setting the branch so only the Release Manager can -commit to the branch when the release process reaches that stage and later opening the branch once -the release has been made. The Release manager will let the GitHub Admin know when this needs to be -done. - -.. seealso:: The `GitHub Admin Process Docs - `_ for instructions - on how to change branch permissions. diff --git a/docs/docsite/rst/community/how_can_I_help.rst b/docs/docsite/rst/community/how_can_I_help.rst deleted file mode 100644 index 38cb1db8d2a..00000000000 --- a/docs/docsite/rst/community/how_can_I_help.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. _how_can_i_help: - -*************** -How can I help? -*************** - -.. contents:: - :local: - -Thanks for being interested in helping the Ansible project! - -There are many ways to help the Ansible project...but first, please read and understand the :ref:`code_of_conduct`. - -Become a power user -=================== - -A great way to help the Ansible project is to become a power user: - -* Use Ansible everywhere you can -* Take tutorials and classes -* Read the :ref:`official documentation ` -* Study some of the `many excellent books `_ about Ansible -* `Get certified `_. - -When you become a power user, your ability and opportunities to help the Ansible project in other ways will multiply quickly. - -Ask and answer questions online -=============================== - -There are many forums online where Ansible users ask and answer questions. Reach out and communicate with your fellow Ansible users. - -You can find the official :ref:`Ansible communication channels `. - -Review, fix, and maintain the documentation -=========================================== - -Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find outdated examples. We offer easy ways to :ref:`report and/or fix documentation errors `. - -.. _ansible_community_meetup: - -Participate in your local meetup -================================ - -There are Ansible meetups `all over the world `_. Join your local meetup. Attend regularly. Ask good questions. Volunteer to give a presentation about how you use Ansible. - -If there is no meetup near you, we are happy to help you `start one `_. - -File and verify issues -====================== - -All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by telling us about it: - -* Filing :ref:`issues for ansible-core `. -* Filing :ref:`issues for collections `. - - -If the bug you found already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information. - -Review and submit pull requests -=============================== - -As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`development process ` to learn how to get your code accepted into Ansible. - -You can also get started with solving GitHub issues labeled with the ``easyfix`` and ``good_first_issue`` labels for: - -- `Ansible collections `_ -- `All other Ansible projects `_ - -When you choose an issue to work on, add a comment directly on the GitHub issue to say you are looking at it and let others know to avoid conflicting work. -You can also ask for help in a comment if you need it. - -Another good way to help is to review pull requests that other Ansible users have submitted. Ansible core keeps a full list of `open pull requests by file `_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback. Alternatively, you can review the pull requests for any collections that interest you. Click :guilabel:`Issue tracker` on the collection documentation page to find the issues and PRs for that collection. - -Become a collection maintainer -============================== - -Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community. - - See :ref:`collection maintainer guidelines ` to learn more about the responsibilities of being an Ansible collection maintainer. - -.. _community_working_groups: - -Join a working group -==================== - -Working groups are a way for Ansible community members to self-organize around particular topics of interest. We have working groups around various topics. To join or create a working group, please read the :ref:`Ansible Working Groups`. - - -Teach Ansible to others -======================= - -We are working on a standardized `Ansible workshop `_ that can provide a good hands-on introduction to Ansible usage and concepts. - -Social media -============ - -If you like Ansible and just want to spread the good word, feel free to share on your social media platform of choice, and let us know by using ``@ansible`` or ``#ansible``. We'll be looking for you. diff --git a/docs/docsite/rst/community/index.rst b/docs/docsite/rst/community/index.rst deleted file mode 100644 index b5ddb51d659..00000000000 --- a/docs/docsite/rst/community/index.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _ansible_community_guide: - -*********************** -Ansible Community Guide -*********************** - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible Community Guide! - -The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary for Ansible's continued success. - - -.. _community_toc: - -.. toctree:: - :maxdepth: 2 - - getting_started - contributor_path diff --git a/docs/docsite/rst/community/maintainers.rst b/docs/docsite/rst/community/maintainers.rst deleted file mode 100644 index bef1567ce6c..00000000000 --- a/docs/docsite/rst/community/maintainers.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _maintainers: - -*************************************** -Guidelines for collection maintainers -*************************************** - -Thank you for being a community collection maintainer. This guide offers an overview of your responsibilities as a maintainer along with resources for additional information. The Ansible community hopes that you will find that maintaining a collection is as rewarding for you as having the collection content is for the wider community. - -.. toctree:: - :maxdepth: 1 - - maintainers_guidelines - maintainers_workflow - collection_contributors/collection_releasing - -In addition to the information here, module maintainers should be familiar with: - -* :ref:`General Ansible community development practices ` -* Documentation on :ref:`module development ` diff --git a/docs/docsite/rst/community/maintainers_guidelines.rst b/docs/docsite/rst/community/maintainers_guidelines.rst deleted file mode 100644 index cfdd0e9595b..00000000000 --- a/docs/docsite/rst/community/maintainers_guidelines.rst +++ /dev/null @@ -1,162 +0,0 @@ -.. _maintainer_requirements: - -Maintainer responsibilities -=========================== - -.. contents:: - :depth: 1 - :local: - -An Ansible collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and who has shown themselves as a specialist in the related area. -Collection maintainers have :ref:`extended permissions` in the collection scope. - -Ansible collection maintainers provide feedback, responses, or actions on pull requests or issues to the collection(s) they maintain in a reasonably timely manner. They can also update the contributor guidelines for that collection, in collaboration with the Ansible community team and the other maintainers of that collection. - -In general, collection maintainers: - -- Act in accordance with the :ref:`code_of_conduct`. -- Subscribe to the collection repository they maintain (click :guilabel:`Watch > All activity` in GitHub). -- Keep README, development guidelines, and other general collections :ref:`maintainer_documentation` relevant. -- Review and commit changes made by other contributors. -- :ref:`Backport ` changes to stable branches. -- Address or assign issues to appropriate contributors. -- :ref:`Release collections `. -- Ensure that collections adhere to the :ref:`collections_requirements`. -- Track changes announced in `News for collection contributors and maintainers `_ and update a collection in accordance with these changes. -- Subscribe and submit news to the `Bullhorn newsletter `_. -- :ref:`Build a healthy community ` to increase the number of active contributors and maintainers around collections. -- Revise these guidelines to improve the maintainer experience for yourself and others. - -Multiple maintainers can divide responsibilities among each other. - -How to become a maintainer --------------------------- - -A person interested in becoming a maintainer and satisfying the :ref:`requirements` may either self-nominate or be nominated by another maintainer. - -To nominate a candidate, create a GitHub issue in the relevant collection repository. If there is no response, the repository is not actively maintained, or the current maintainers do not have permissions to add the candidate, please create the issue in the `ansible/community `_ repository. - -Communicating as a collection maintainer ------------------------------------------ - - Maintainers MUST subscribe to the `"Changes impacting collection contributors and maintainers" GitHub repo `_ and the `Bullhorn newsletter `_. If you have something important to announce through the newsletter (for example, recent releases), see the `Bullhorn's wiki page `_ to learn how. - - -Collection contributors and maintainers should also communicate through: - -* :ref:`communication_irc` appropriate to their collection, or if none exists, the general community and developer chat channels -* Mailing lists such as `ansible-announce `_ and `ansible-devel `_ -* Collection project boards, issues, and GitHub discussions in corresponding repositories -* Quarterly Contributor Summits. -* Ansiblefest and local meetups. - -See :ref:`communication` for more details on these communication channels. - -.. _wg_and_real_time_chat: - -Establishing working group communication ----------------------------------------------------------------- - -Working groups depend on efficient, real-time communication. -Project maintainers can use the following techniques to establish communication for working groups: - -* Find an existing :ref:`working_group_list` that is similar to your project and join the conversation. -* `Request `_ a new working group for your project. -* `Create `_ a public chat for your working group or `ask `_ the community team. -* Provide working group details and links to chat rooms in the contributor section of your project ``README.md``. -* Encourage contributors to join the chats and add themselves to the working group. - -See the :ref:`Communication guide ` to learn more about real-time chat. - -Community Topics ----------------- - -The Community and the `Steering Committee `_ asynchronously discuss and vote on the `Community Topics `_ which impact the whole project or its parts including collections and packaging. - -Share your opinion and vote on the topics to help the community make the best decisions. - -.. _expanding_community: - -Contributor Summits -------------------- - -The quarterly Ansible Contributor Summit is a global event that provides our contributors a great opportunity to meet each other, communicate, share ideas, and see that there are other real people behind the messages on Matrix or Libera Chat IRC, or GitHub. This gives a sense of community. Watch the `Bullhorn newsletter `_ for information when the next contributor summit, invite contributors you know, and take part in the event together. - -Weekly community Matrix/IRC meetings ------------------------------------- - -The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` `Libera.Chat IRC `_ channel or in the bridged `#community:ansible.com `_ room on `Matrix `_ to discuss important project questions. Join us! Here is our `schedule `_. - -Expanding the collection community -=================================== - -.. note:: - - If you discover good ways to expand a community or make it more robust, edit this section with your ideas to share with other collection maintainers. - -Here are some ways you can expand the community around your collection: - - * Give :ref:`newcomers a positive first experience `. - * Invite contributors to join :ref:`real-time chats ` related to your project. - * Have :ref:`good documentation ` with guidelines for new contributors. - * Make people feel welcome personally and individually. - * Use labels to show easy fixes and leave non-critical easy fixes to newcomers and offer to mentor them. - * Be responsive in issues, PRs and other communication. - * Conduct PR days regularly. - * Maintain a zero-tolerance policy towards behavior violating the :ref:`code_of_conduct`. - * Put information about how people can register code of conduct violations in your ``README`` and ``CONTRIBUTING`` files. - * Include quick ways contributors can help and other documentation in your ``README``. - * Add and keep updated the ``CONTRIBUTORS`` and ``MAINTAINERS`` files. - * Create a pinned issue to announce that the collection welcomes new maintainers and contributors. - * Look for new maintainers among active contributors. - * Announce that your collection welcomes new maintainers. - * Take part and congratulate new maintainers in Contributor Summits. - - -.. _collection_new_contributors: - -Encouraging new contributors ------------------------------ - -Easy-fix items are the best way to attract and mentor new contributors. You should triage incoming issues to mark them with labels such as ``easyfix``, ``waiting_on_contributor``, and ``docs``. where appropriate. Do not fix these trivial non-critical bugs yourself. Instead, mentor a person who wants to contribute. - -For some easy-fix issues, you could ask the issue reporter whether they want to fix the issue themselves providing the link to a quick start guide for creating PRs. - -Conduct pull request days regularly. You could plan PR days, for example, on the last Friday of every month when you and other maintainers go through all open issues and pull requests focusing on old ones, asking people if you can help, and so on. If there are pull requests that look abandoned (for example, there is no response on your help offers since the previous PR day), announce that anyone else interested can complete the pull request. - -Promote active contributors satisfying :ref:`requirements` to maintainers. Revise contributors' activity regularly. - -If your collection found new maintainers, announce that fact in the `Bullhorn newsletter `_ and during the next Contributor Summit congratulating and thanking them for the work done. You can mention all the people promoted since the previous summit. Remember to invite the other maintainers to the Summit in advance. - -Some other general guidelines to encourage contributors: - -* Welcome the author and thank them for the issue or pull request. -* If there is a non-crucial easy-fix bug reported, politely ask the author to fix it themselves providing a link to :ref:`collection_quickstart`. -* When suggesting changes, try to use questions, not statements. -* When suggesting mandatory changes, do it as politely as possible providing documentation references. -* If your suggestion is optional or a matter of personal preference, please say it explicitly. -* When asking for adding tests or for complex code refactoring, say that the author is welcome to ask for clarifications and help if they need it. -* If somebody suggests a good idea, mention it or put a thumbs up. -* After merging, thank the author and reviewers for their time and effort. - -See the :ref:`review_checklist` for a list of items to check before you merge a PR. - -.. _maintainer_documentation: - -Maintaining good collection documentation -========================================== - -Maintainers look after the collection documentation to ensure it matches the :ref:`style_guide`. This includes keeping the following documents accurate and updated regularly: - -* Collection module and plugin documentation that adheres to the :ref:`Ansible documentation format `. -* Collection user guides that follow the :ref:`Collection documentation format `. -* Repository files that includes at least a ``README`` and ``CONTRIBUTING`` file. - -A good ``README`` includes a description of the collection, a link to the :ref:`code_of_conduct`, and details on how to contribute or a pointer to the ``CONTRIBUTING`` file. If your collection is a part of Ansible (is shipped with Ansible package), highlight that fact at the top of the collection's ``README``. - - The ``CONTRIBUTING`` file includes all the details or links to the details on how a new or continuing contributor can contribute to this collection. The ``CONTRIBUTING`` file should include: - -* Information or links to new contributor guidelines, such as a quick start on opening PRs. -* Information or links to contributor requirements, such as unit and integration test requirements. - -You can optionally include a ``CONTRIBUTORS`` and ``MAINTAINERS`` file to list the collection contributors and maintainers. diff --git a/docs/docsite/rst/community/maintainers_workflow.rst b/docs/docsite/rst/community/maintainers_workflow.rst deleted file mode 100644 index e14ce5c025d..00000000000 --- a/docs/docsite/rst/community/maintainers_workflow.rst +++ /dev/null @@ -1,95 +0,0 @@ -.. _maintainers_workflow: - - -Backporting and Ansible inclusion -================================== - -Each collection community can set its own rules and workflow for managing pull requests, bug reports, documentation issues, and feature requests, as well as adding and replacing maintainers. Maintainers review and merge pull requests following the: - -* :ref:`code_of_conduct` -* :ref:`maintainer_requirements` -* :ref:`Committer guidelines ` -* :ref:`PR review checklist` - -There can be two kinds of maintainers: :ref:`collection_maintainers` and :ref:`module_maintainers`. - -.. _collection_maintainers: - -Collection maintainers ----------------------- - -Collection-scope maintainers are contributors who have the ``write`` or higher access level in a collection. They have commit rights and can merge pull requests, among other permissions. - -When a collection maintainer considers a contribution to a file significant enough -(for example, fixing a complex bug, adding a feature, providing regular reviews, and so on), -they can invite the author to become a module maintainer. - - -.. _module_maintainers: - -Module maintainers ------------------- - -Module-scope maintainers exist in collections that have the `collection bot `_, -for example, `community.general `_ -and `community.network `_. - -Being a module maintainer is the stage prior to becoming a collection maintainer. Module maintainers are contributors who are listed in ``.github/BOTMETA.yml``. The scope can be any file (for example, a module or plugin), directory, or repository. Because in most cases the scope is a module or group of modules, we call these contributors module maintainers. The collection bot notifies module maintainers when issues/pull requests related to files they maintain are created. - -Module maintainers have indirect commit rights implemented through the `collection bot `_. -When two module maintainers comment with the keywords ``shipit``, ``LGTM``, or ``+1`` on a pull request -which changes a module they maintain, the collection bot merges the pull request automatically. - -For more information about the collection bot and its interface, -see to the `Collection bot overview `_. - - -Releasing a collection ----------------------- - -Collection maintainers are responsible for releasing new versions of a collection. Generally, releasing a collection consists of: - -#. Planning and announcement. -#. Generating a changelog. -#. Creating a release git tag and pushing it. -#. Automatically publishing the release tarball on `Ansible Galaxy `_ through the `Zuul dashboard `_. -#. Final announcement. -#. Optionally, `file a request to include a new collection into the Ansible package `_. - -See :ref:`releasing_collections` for details. - -.. _Backporting: - -Backporting ------------- - -Collection maintainers backport merged pull requests to stable branches -following the `semantic versioning `_ and release policies of the collections. - -The manual backport process is similar to the :ref:`ansible-core backporting guidelines `. - -For convenience, backporting can be implemented automatically using GitHub bots (for example, with the `Patchback app `_) and labeling as it is done in `community.general `_ and `community.network `_. - - -.. _including_collection_ansible: - -Including a collection in Ansible ------------------------------------ - -If a collection is not included in Ansible (not shipped with Ansible package), maintainers can submit the collection for inclusion by creating a discussion under the `ansible-collections/ansible-inclusion repository `_. For more information, see the `repository's README `_, and the :ref:`Ansible community package collections requirements `. - -Stepping down as a collection maintainer -=========================================== - -Times change, and so may your ability to continue as a collection maintainer. We ask that you do not step down silently. - -If you feel you don't have time to maintain your collection anymore, you should: - -- Inform other maintainers about it. -- If the collection is under the ``ansible-collections`` organization, also inform relevant :ref:`communication_irc`, the ``community`` chat channels on IRC or matrix, or by email ``ansible-community@redhat.com``. -- Look at active contributors in the collection to find new maintainers among them. Discuss the potential candidates with other maintainers or with the community team. -- If you failed to find a replacement, create a pinned issue in the collection, announcing that the collection needs new maintainers. -- Make the same announcement through the `Bullhorn newsletter `_. -- Please be around to discuss potential candidates found by other maintainers or by the community team. - -Remember, this is a community, so you can come back at any time in the future. diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst deleted file mode 100644 index fbf21514f5e..00000000000 --- a/docs/docsite/rst/community/other_tools_and_programs.rst +++ /dev/null @@ -1,127 +0,0 @@ -.. _other_tools_and_programs: - -************************ -Other Tools and Programs -************************ - -.. contents:: - :local: - -The Ansible community uses a range of tools for working with the Ansible project. This is a list of some of the most popular of these tools. - -If you know of any other tools that should be added, this list can be updated by clicking "Edit on GitHub" on the top right of this page. - -*************** -Popular editors -*************** - -Atom -==== - -An open-source, free GUI text editor created and maintained by GitHub. You can keep track of git project -changes, commit from the GUI, and see what branch you are on. You can customize the themes for different colors and install syntax highlighting packages for different languages. You can install Atom on Linux, macOS and Windows. Useful Atom plugins include: - -* `language-yaml `_ - YAML highlighting for Atom (built-in). -* `linter-js-yaml `_ - parses your YAML files in Atom through js-yaml. - - -Emacs -===== - -A free, open-source text editor and IDE that supports auto-indentation, syntax highlighting and built in terminal shell(among other things). - -* `yaml-mode `_ - YAML highlighting and syntax checking. -* `jinja2-mode `_ - Jinja2 highlighting and syntax checking. -* `magit-mode `_ - Git porcelain within Emacs. -* `lsp-mode `_ - Ansible syntax highlighting, auto-completion and diagnostics. - - -PyCharm -======= - -A full IDE (integrated development environment) for Python software development. It ships with everything you need to write python scripts and complete software, including support for YAML syntax highlighting. It's a little overkill for writing roles/playbooks, but it can be a very useful tool if you write modules and submit code for Ansible. Can be used to debug the Ansible engine. - - -Sublime -======= - -A closed-source, subscription GUI text editor. You can customize the GUI with themes and install packages for language highlighting and other refinements. You can install Sublime on Linux, macOS and Windows. Useful Sublime plugins include: - -* `GitGutter `_ - shows information about files in a git repository. -* `SideBarEnhancements `_ - provides enhancements to the operations on Sidebar of Files and Folders. -* `Sublime Linter `_ - a code-linting framework for Sublime Text 3. -* `Pretty YAML `_ - prettifies YAML for Sublime Text 2 and 3. -* `Yamllint `_ - a Sublime wrapper around yamllint. - - -Visual studio code -================== - -An open-source, free GUI text editor created and maintained by Microsoft. Useful Visual Studio Code plugins include: - -* `Ansible extension by Red Hat `_ - provides autocompletion, syntax highlighting, hover, diagnostics, goto support, and command to run ansible-playbook and ansible-navigator tool for both local and execution-environment setups. -* `YAML Support by Red Hat `_ - provides YAML support through yaml-language-server with built-in Kubernetes and Kedge syntax support. - -vim -=== - -An open-source, free command-line text editor. Useful vim plugins include: - -* `Ansible vim `_ - vim syntax plugin for Ansible 2.x, it supports YAML playbooks, Jinja2 templates, and Ansible's hosts files. -* `Ansible vim and neovim plugin `_ - vim plugin (lsp client) for Ansible, it supports autocompletion, syntax highlighting, hover, diagnostics, and goto support. - -JetBrains -========= - -An open-source Community edition and closed-source Enterprise edition, integrated development environments based on IntelliJ's framework including IDEA, AppCode, CLion, GoLand, PhpStorm, PyCharm and others. Useful JetBrains platform plugins include: - -* `Ansible `_ - general Ansible plugin provides auto-completion, role name suggestion and other handy features for working with playbooks and roles. - -* `Ansible Vault Editor `_ - Ansible Vault Editor with auto encryption/decryption. - -***************** -Development tools -***************** - -Finding related issues and PRs -============================== - -There are various ways to find existing issues and pull requests (PRs) - -- `PR by File `_ - shows a current list of all open pull requests by individual file. An essential tool for Ansible module maintainers. -- `jctanner's Ansible Tools `_ - miscellaneous collection of useful helper scripts for Ansible development. - -.. _validate-playbook-tools: - -****************************** -Tools for validating playbooks -****************************** - -- `Ansible Lint `_ - a highly configurable linter for Ansible playbooks. -- `Ansible Review `_ - an extension of Ansible Lint designed for code review. -- `Molecule `_ - a testing framework for Ansible plays and roles. -- `yamllint `__ - a command-line utility to check syntax validity including key repetition and indentation issues. - - -*********** -Other tools -*********** - -- `Ansible cmdb `_ - takes the output of Ansible's fact gathering and converts it into a static HTML overview page containing system configuration information. -- `Ansible Inventory Grapher `_ - visually displays inventory inheritance hierarchies and at what level a variable is defined in inventory. -- `Ansible Language Server `_ - a server that implements `language server protocol `_ for Ansible. -- `Ansible Playbook Grapher `_ - a command line tool to create a graph representing your Ansible playbook tasks and roles. -- `Ansible Shell `_ - an interactive shell for Ansible with built-in tab completion for all the modules. -- `Ansible Silo `_ - a self-contained Ansible environment by Docker. -- `Ansigenome `_ - a command line tool designed to help you manage your Ansible roles. -- `antsibull-changelog `_ - a changelog generator for Ansible collections. -- `antsibull-docs `_ - generates docsites for collections and can validate collection documentation. -- `ARA `_ - ARA Records Ansible playbooks and makes them easier to understand and troubleshoot with a reporting API, UI and CLI. -- `Awesome Ansible `_ - a collaboratively curated list of awesome Ansible resources. -- `AWX `_ - provides a web-based user interface, REST API, and task engine built on top of Ansible. Red Hat Ansible Automation Platform includes code from AWX. -- `Mitogen for Ansible `_ - uses the `Mitogen `_ library to execute Ansible playbooks in a more efficient way (decreases the execution time). -- `nanvault `_ - a standalone tool to encrypt and decrypt files in the Ansible Vault format, featuring UNIX-style composability. -- `OpsTools-ansible `_ - uses Ansible to configure an environment that provides the support of `OpsTools `_, namely centralized logging and analysis, availability monitoring, and performance monitoring. -- `Steampunk Spotter `_ - provides an Assisted Automation Writing tool that analyzes and offers recommendations for your Ansible Playbooks. -- `TD4A `_ - a template designer for automation. TD4A is a visual design aid for building and testing jinja2 templates. It will combine data in yaml format with a jinja2 template and render the output. -- `PHP-Ansible `_ - an object oriented Ansible wrapper for PHP. diff --git a/docs/docsite/rst/community/release_managers.rst b/docs/docsite/rst/community/release_managers.rst deleted file mode 100644 index 97949a55f7d..00000000000 --- a/docs/docsite/rst/community/release_managers.rst +++ /dev/null @@ -1,81 +0,0 @@ -.. _release_managers: - -************************** -Release Manager Guidelines -************************** - -.. contents:: Topics - -The release manager's purpose is to ensure a smooth release. To achieve that goal, they need to -coordinate between: - -* Developers with commit privileges on the `Ansible GitHub repository `_ -* Contributors without commit privileges -* The community -* Ansible documentation team - -Pre-releases: what and why -========================== - -Pre-releases exist to draw testers. They give people who don't feel comfortable running from source -control a means to get an early version of the code to test and give us feedback. To ensure we get -good feedback about a release, we need to make sure all major changes in a release are put into -a pre-release. Testers must be given time to test those changes before the final release. Ideally we -want there to be sufficient time between pre-releases for people to install and test one version for -a span of time. Then they can spend more time using the new code than installing the latest -version. - -The right length of time for a tester is probably around two weeks. However, for our three-to-four month -development cycle to work, we compress this down to one week; any less runs the risk -of people spending more time installing the code instead of running it. However, if there's a time -crunch (with a release date that cannot slip), it is better to release with new changes than to hold -back those changes to give people time to test between. People cannot test what is not released, so -we have to get those tarballs out there even if people feel they have to install more frequently. - - -Beta releases -------------- - -In a beta release, we know there are still bugs. We will continue to accept fixes for these. -Although we review these fixes, sometimes they can be invasive or potentially destabilize other -areas of the code. - -During the beta, we will no longer accept feature submissions. - - -Release candidates ------------------- - -In a release candidate, we've fixed all known blockers. Any remaining bugfixes are -ones that we are willing to leave out of the release. At this point we need user testing to -determine if there are any other blocker bugs lurking. - -Blocker bugs generally are those that cause significant problems for users. Regressions are -more likely to be considered blockers because they will break present users' usage of Ansible. - -The Release Manager will cherry-pick fixes for new release blockers. The release manager will also -choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor -release. By themselves, non-blocker bugs will not trigger a new release; they will only make it -into the next major release if blocker bugs require that a new release be made. - -The last RC should be as close to the final as possible. The following things may be changed: - - * Version numbers are changed automatically and will differ as the pre-release tags are removed from - the versions. - * Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime. - However, the release manager may still reject them as they have the potential to cause - breakage that will be visible during the release process. - -.. note:: We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and - :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If - there are extenuating circumstances, the Release Manager is responsible for notifying groups - which would want to test the code. - - -Ansible release process -======================= - -The release process is kept in a `separate document -`_ -so that it can be easily updated during a release. If you need access to edit this, please ask one -of the current release managers to add you. diff --git a/docs/docsite/rst/community/reporting_bugs_and_features.rst b/docs/docsite/rst/community/reporting_bugs_and_features.rst deleted file mode 100644 index a972603af36..00000000000 --- a/docs/docsite/rst/community/reporting_bugs_and_features.rst +++ /dev/null @@ -1,59 +0,0 @@ - -.. _reporting_bugs_and_features: - -************************************** -Reporting bugs and requesting features -************************************** - -.. contents:: - :local: - -.. _reporting_bugs: - -Reporting a bug -=============== - -Security bugs -------------- - -Ansible practices responsible disclosure. To report security-related bugs, send an email to `security@ansible.com `_ for an immediate response. Do not submit a ticket or post to any public groups. - -Bugs in ansible-core --------------------- - -Before reporting a bug, search in GitHub for `already reported issues `_ and `open pull requests `_ to see if someone has already addressed your issue. Unsure if you found a bug? Report the behavior on the :ref:`mailing list or community chat first `. - -Also, use the mailing list or chat to discuss whether the problem is in ``ansible-core`` or a collection, and for "how do I do this" type questions. - -You need a free GitHub account to `report bugs `_ that affect: - -- multiple plugins -- a plugin that remained in the ansible/ansible repo -- the overall functioning of Ansible - -How to write a good bug report ------------------------------- - -If you find a bug, open an issue using the `issue template `_. - -Fill out the issue template as completely and as accurately as possible. Include: - -* your Ansible version -* the expected behavior and what you've tried, including the exact commands you were using or tasks you are running. -* the current behavior and why you think it is a bug -* the steps to reproduce the bug -* a minimal reproducible example and comments describing examples -* any relevant configurations and the components you used -* any relevant output plus ``ansible -vvvv`` (debugging) output -* add the output of ``ansible-test-env --show`` when filing bug reports involving ``ansible-test``. - -When sharing YAML in playbooks, ensure that you preserve formatting using `code blocks `_. For multiple-file content, use gist.github.com, more durable than Pastebin content. - -.. _request_features: - -Requesting a feature -==================== - -Before you request a feature, check what is :ref:`planned for future Ansible Releases `. Check `existing pull requests tagged with feature `_. - -To get your feature into Ansible, :ref:`submit a pull request `, either against ansible-core or a collection. See also :ref:`ansible_collection_merge_requirements`. For ``ansible-core``, you can also open an issue in `ansible/ansible `_ or in a corresponding collection repository (To find the correct issue tracker, refer to :ref:`Bugs in collections` ). diff --git a/docs/docsite/rst/community/reporting_collections.rst b/docs/docsite/rst/community/reporting_collections.rst deleted file mode 100644 index 1d8c2e60f9f..00000000000 --- a/docs/docsite/rst/community/reporting_collections.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. _reporting_bugs_in_collections: - -*********************************** -Requesting changes to a collection -*********************************** - -.. contents:: - :local: - -Reporting a bug -=============== - -Security bugs -------------- - -Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com `_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response. - - -Bugs in collections -------------------- - -Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection `: - - #. Find the collection on `Galaxy `_. - #. Click on the Issue Tracker link for that collection. - #. Follow the contributor guidelines or instructions in the collection repo. - -If you are not sure whether a bug is in ansible-core or in a collection, you can report the behavior on the :ref:`mailing list or community chat channel first `. - -Requesting a feature -==================== - -Before you request a feature, check what is :ref:`planned for future Ansible Releases `. -The best way to get a feature into an Ansible collection is to :ref:`submit a pull request `, either against ansible-core or against a collection. See also the :ref:`ansible_collection_merge_requirements`. - -You can also submit a feature request by opening an issue in the collection repository. diff --git a/docs/docsite/rst/community/steering/community_steering_committee.rst b/docs/docsite/rst/community/steering/community_steering_committee.rst deleted file mode 100644 index 5a5f2672bf2..00000000000 --- a/docs/docsite/rst/community/steering/community_steering_committee.rst +++ /dev/null @@ -1,165 +0,0 @@ - -.. _steering_responsibilities: - -Steering Committee mission and responsibilities -=============================================== - -The Steering Committee mission is to provide continuity, guidance, and suggestions to the Ansible community to ensure the delivery and high quality of the Ansible package. In addition, the committee helps decide the technical direction of the Ansible project. It is responsible for approving new proposals and policies in the community, package, and community collections world, new community collection-inclusion requests, and other technical aspects regarding inclusion and packaging. -The Committee should reflect the scope and breadth of the Ansible community. - -Steering Committee responsibilities ------------------------------------- - -The Committee: - -* Designs policies and procedures for the community collections world. -* Votes on approval changes to established policies and procedures. -* Reviews community collections for compliance with the policies. -* Helps create and define roadmaps for our deliverables such as the ``ansible`` package, major community collections, and documentation. -* Reviews community collections submitted for inclusion in the Ansible package and decides whether to include them or not. -* Review other proposals of importance that need the Committee's attention and provide feedback. - -.. _steering_members: - -Current Steering Committee members ------------------------------------ - -The following table lists the current Steering Committee members. See :ref:`steering_past_members` for a list of past members. - - - -.. table:: Current Steering committee members - - +------------------+---------------+-------------+ - | Name | GitHub | Start year | - +==================+===============+=============+ - | Alexei Znamensky | russoz | 2022 | - +------------------+---------------+-------------+ - | Alicia Cozine | acozine | 2021 | - +------------------+---------------+-------------+ - | Andrew Klychkov | Andersson007 | 2021 | - +------------------+---------------+-------------+ - | Brad Thornton | cidrblock | 2021 | - +------------------+---------------+-------------+ - | Brian Scholer | briantist | 2022 | - +------------------+---------------+-------------+ - | Dylan Silva | thaumos | 2021 | - +------------------+---------------+-------------+ - | Felix Fontein | felixfontein | 2021 | - +------------------+---------------+-------------+ - | James Cassell | jamescassell | 2021 | - +------------------+---------------+-------------+ - | John Barker | gundalow | 2021 | - +------------------+---------------+-------------+ - | Mario Lenz | mariolenz | 2022 | - +------------------+---------------+-------------+ - | Markus Bergholz | markuman | 2022 | - +------------------+---------------+-------------+ - | Maxwell G | gotmax23 | 2022 | - +------------------+---------------+-------------+ - | Sorin Sbarnea | ssbarnea | 2021 | - +------------------+---------------+-------------+ - - -John Barker (`gundalow `_) has been elected by the Committee as its :ref:`chairperson`. - -Committee members are selected based on their active contribution to the Ansible Project and its community. See :ref:`community_steering_guidelines` to learn details. - -Creating new policy proposals & inclusion requests ----------------------------------------------------- - -The Committee uses the `community-topics repository `_ to asynchronously discuss with the Community and vote on Community topics in corresponding issues. - -You can create a new issue in the `community-topics repository `_ as a discussion topic if you want to discuss an idea that impacts any of the following: - - * Ansible Community - * Community collection best practices and requirements - * Community collection inclusion policy - * The Community governance - * Other proposals of importance that need the Committee's or overall Ansible community attention - - -To request changes to the inclusion policy and collection requirements: - -#. Submit a new pull request to the `ansible-collections/overview `_ repository. - -#. Create a corresponding issue containing the rationale behind these changes in the `community-topics repository `_ repository. - -To submit new collections for inclusion into the Ansible package: - -* Submit the new collection inclusion requests through a new discussion in the `ansible-inclusion `_ repository. - -Depending on a topic you want to discuss with the Community and the Committee, as you prepare your proposal, please consider the requirements established by: - -* :ref:`code_of_conduct`. -* :ref:`collections_requirements`. -* `Ansible Collection Inclusion Checklist `_. - -Community topics workflow -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Committee uses the `Community-topics workflow `_ to asynchronously discuss and vote on the `community-topics `_. - -The quorum, the minimum number of Committee members who must vote on a topic in order for a decision to be officially made, is half of the whole number of the Committee members. If the quorum number contains a fractional part, it is rounded up to the next whole number. For example, if there are thirteen members currently in the committee, the quorum will be seven. - -Votes must always have "no change" as an option. - -In case of equal numbers of votes for and against a topic, the chairperson's vote will break the tie. For example, if there are six votes for and six votes against a topic, and the chairperson's vote is among those six which are for the topic, the final decision will be positive. If the chairperson has not voted yet, other members ask them to vote. - -For votes with more than two options, one choice must have at least half of the votes. If two choices happen to both have half of the votes, the chairperson's vote will break the tie. If no choice has at least half of the votes, the vote choices have to be adjusted so that a majority can be found for a choice in a new vote. - -Community topics triage -^^^^^^^^^^^^^^^^^^^^^^^ - -The Committee conducts a triage of `community topics `_ periodically (every three to six months). - -The triage goals are: - -* Sparking interest for forgotten topics. -* Identifying and closing irrelevant topics, for example, when the reason of the topic does not exist anymore or the topic is out of the Committee responsibilities scope. -* Identifying and closing topics that the Community are not interested in discussing. As indicators, it can be absence of comments or no activity in comments, at least, for the last six months. -* Identifying and closing topics that were solved and implemented but not closed (in this case, such a topic can be closed on the spot with a comment that it has been implemented). -* Identifying topics that have been in pending state for a long time, for example, when it is waiting for actions from someone for several months or when the topics were solved but not implemented. - -A person starting the triage: - -#. Identifies the topics mentioned above. -#. Creates a special triage topic containing an enumerated list of the topics-candidates for closing. -#. Establishes a vote date considering a number of topics, their complexity and comment-history size giving the Community sufficient time to go through and discuss them. -#. The Community and the Committee vote on each topic-candidate listed in the triage topic whether to close it or keep it open. - -Collection inclusion requests workflow -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When reviewing community collection `inclusion requests `_, the Committee members check if a collection adheres to the :ref:`collections_requirements`. - -#. A Committee member who conducts the inclusion review copies the `Ansible community collection checklist `_ into a corresponding `discussion `_. - -#. In the course of the review, the Committee member marks items as completed or leaves a comment saying whether the reviewer expects an issue to be addressed or whether it is optional (for example, it could be **MUST FIX:** or **SHOULD FIX:** under an item). - -#. For a collection to be included in the Ansible community package, the collection: - - * MUST be reviewed and approved by at least two persons, where at least one person is a Steering Committee member. - * For a Non-Steering Committee review to be counted for inclusion, it MUST be checked and approved by *another* Steering Committee member. - * Reviewers must not be involved significantly in development of the collection. They must declare any potential conflict of interest (for example, being friends/relatives/coworkers of the maintainers/authors, being users of the collection, or having contributed to that collection recently or in the past). - -#. After the collection gets two or more Committee member approvals, a Committee member creates a `community topic `_ linked to the corresponding inclusion request. The issue's description says that the collection has been approved by two or more Committee members and establishes a date (a week by default) when the inclusion decision will be considered made. This time period can be used to raise concerns. - -#. If no objections are raised up to the established date, the inclusion request is considered successfully resolved. In this case, a Committee member: - - #. Declares the decision in the topic and in the inclusion request. - #. Moves the request to the ``Resolved reviews`` category. - #. Adds the collection to the ``ansible.in`` file in a corresponding directory of the `ansible-build-data repository `_. - #. Announces the inclusion through the `Bullhorn newsletter `_. - #. Closes the topic. - -Community Working Group meetings ---------------------------------- - -See the Community Working Group meeting `schedule `_. Meeting summaries are posted in the `Community Working Group Meeting Agenda `_ issue. - -.. note:: - - Participation in the Community Working Group meetings is optional for Committee members. Decisions on community topics are made asynchronously in the `community-topics `_ repository. - -The meeting minutes can be found at the `fedora meetbot site `_ and the same is posted to `Ansible Devel Mailing List `_ after every meeting. diff --git a/docs/docsite/rst/community/steering/steering_committee_membership.rst b/docs/docsite/rst/community/steering/steering_committee_membership.rst deleted file mode 100644 index 1b636f1302e..00000000000 --- a/docs/docsite/rst/community/steering/steering_committee_membership.rst +++ /dev/null @@ -1,139 +0,0 @@ -.. _community_steering_guidelines: - -Steering Committee membership guidelines -========================================== - -This document describes the expectations and policies related to membership in the :ref:`Ansible Community Steering Committee ` (hereinafter the Committee). - -.. contents:: Topics: - -.. _steering_expectations: - -Expectations of a Steering Committee member -------------------------------------------- - - -As a Committee member, you agree to: - -#. Abide by the :ref:`code_of_conduct` in all your interactions with the Community. -#. Be a Community ambassador by representing its needs within the Committee and throughout the decision making process. -#. Asynchronously participate in discussions and voting on the `Community Topics `_. -#. Review other proposals of importance that need the Committee's attention and provide feedback. -#. Act for the sake of the Community by not promoting corporate or individual agenda during the decision making process. -#. Engage with the Community in a professional and positive manner, encourage community members to express their opinion. - -.. _Joining the committee: - -Joining the Steering Committee -------------------------------- - -Eligibility -^^^^^^^^^^^ - -A person is eligible to become a Committee member if they have: - -#. A wide knowledge of Ansible and/or its related projects. -#. Active contributions to Ansible and/or related projects in any form described in the :ref:`collections_contributions`. -#. A consent to follow the :ref:`steering_expectations`. - -Process -^^^^^^^^ - -The process to join the Steering Committee consists of the following steps: - -#. Any community member may nominate someone or themselves for Committee membership by contacting one of the :ref:`current Committee members `) or by sending an email to ``ansible-community@redhat.com``. -#. A Committee member who receives the nomination must inform the Committee about it by forwarding the full message. -#. The vote is conducted by email. Nominees must receive a majority of votes from the present Committee members to be added to the Committee. -#. Provided that the vote result is positive, it is announced via the `Bullhorn `_ newsletter and the new member is added to the :ref:`Committee member list `. - -Leaving the Steering Committee -------------------------------- - -Steering Committee members can resign voluntarily or be removed by the -rest of the Steering Committee under certain circumstances. See the details -below. - -.. _Voluntarily leaving process: - -Voluntarily leaving the Steering Committee -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A Committee member can voluntarily leave the Committee. -In this case, they notify the other members, create an issue in the `Community Topics `_ repository announcing the resignation, and after that they are no longer considered Committee members. - -Committee members who resign and later change their mind can -rejoin the Committee by following the :ref:`Process for joining the Steering Committee`. - -Involuntarily leaving the Steering Committee -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A Committee member will be removed from the Committee if they: - -#. Do not participate in asynchronous discussions and voting on the `Community Topics `_ for more than 3 months in a row. -#. Participate unreasonably irregularly (for example, once a month for several months). Unreasonably is defined by other Committee members considering circumstances in each particular case. -#. Violate the :ref:`code_of_conduct`. - -.. _Absence or irregular participation removal process: - -Absence or irregular participation in discussing topics and votes -.................................................................. - -In case of absence or irregular participation, the involuntarily removal process consists of the following steps: - -#. Another Committee member (hereinafter the initiator) contacts the person by email asking if they are still interested in fulfilling their Committee member's duties. -#. If they respond that they are not interested, the initiator asks the person to step down on their own following the :ref:`Voluntarily leaving process`. -#. If there has been no response or stepping down issue created by the person within a reasonable time, the initiator notifies other Committee members about the situation. -#. In case of agreement among the Committee about the need for removal, the initiator provides a draft of a corresponding topic's description to the Committee via email for discussion and approval. - - * The topic's title is ``Steering Committee member audit.``. It must not contain the person's name or other identifying information. - - * The description must not contain or imply any forms of condemnation. - - * It must mention that the person has been inactive for an unknown reason for the last N months and that, in accordance with the Steering Committee policies, their place should be freed for another person who can continue their great job. - - * The description must mention person's achievements and thanks for their time and effort they spent serving for the Community, Committee, and the Project, and a hope that one day they will come back. - -#. The initiator creates the topic in the `Community Topics `_ repository containing the description and the title from the draft. -#. The Committee members vote on the topic. - -Ansible Community Code of Conduct violations -............................................. - -In case of the `Ansible Community Code of Conduct `_ violations, the process is the same as above except steps 1-2. Instead: - -#. The initiator reports the case to the Committee via email. - -#. The Committee discusses the case internally, evaluates its severity, and possible solutions. - -#. If the Committee concludes that the violation is not severe, it develops a proposal to the person on how the situation can be corrected and further interactions with the Community improved. - -#. A Committee representative reaches out to the person with the proposal. - -#. The removal process starts if: - - * The Committee decided that the severity of the violation excludes a possibility of further membership. - - * The person does not respond to the proposal. - - * The person explicitly rejects the proposal. - -In case of starting the removal process, the topic's description in the reason's part changes correspondingly. - -.. _chairperson: - -Chairperson ------------- - -The chairperson election will happen once a year around the time of -Ansible Fest. If the current chairperson has to step down early, the election happens immediately. - -The process of the election consist of the following steps: - -#. Members interested in being the chairperson will inform a - person responsible for arranging the election about that. -#. Conduct anonymous voting somewhere. -#. Internally and publicly announce the elected candidate. - -The chairperson has the following powers unlike regular members: - -* The chairperson's vote breaks ties to resolve deadlocks when equal numbers of steering committee members vote for and against a `community topic `_. diff --git a/docs/docsite/rst/community/steering/steering_committee_past_members.rst b/docs/docsite/rst/community/steering/steering_committee_past_members.rst deleted file mode 100644 index 212617372a6..00000000000 --- a/docs/docsite/rst/community/steering/steering_committee_past_members.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. _steering_past_members: - -Steering Committee past members -================================ - -The Ansible Community is very grateful to these amazing **nonreplaceable** -people for their great service to the Community and the project! - - -.. table:: Steering Committee past members - - +------------------+-----------+-------------------+ - | Name | GitHub | Years of service | - +==================+===========+===================+ - | Jill Rouleau | jillr | 2021-2022 | - +------------------+-----------+-------------------+ - | Tadej Borovšak | tadeboro | 2021-2022 | - +------------------+-----------+-------------------+ - | Toshio Kuratomi | abadger | 2021 | - +------------------+-----------+-------------------+ - - -We'd also like to thank our past chairpersons for their contributions to Ansible. - -.. table:: Steering Committee past chairpersons - - +------------------+-----------+-------------------+ - | Name | GitHub | Years of service | - +==================+===========+===================+ - | Tadej Borovšak | tadeboro | 2021-2022 | - +------------------+-----------+-------------------+ diff --git a/docs/docsite/rst/community/steering/steering_index.rst b/docs/docsite/rst/community/steering/steering_index.rst deleted file mode 100644 index 78d435a1252..00000000000 --- a/docs/docsite/rst/community/steering/steering_index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _community_steering_committee: - -************************************ -Ansible Community Steering Committee -************************************ - -This section focuses on the guidelines and membership of the Ansible Community Steering Committee. - -.. toctree:: - :maxdepth: 1 - - community_steering_committee - steering_committee_membership - steering_committee_past_members diff --git a/docs/docsite/rst/core_index.rst b/docs/docsite/rst/core_index.rst deleted file mode 100644 index e76fe7108c7..00000000000 --- a/docs/docsite/rst/core_index.rst +++ /dev/null @@ -1,110 +0,0 @@ -.. _ansible_core_documentation: - -.. - This is the index file for ansible-core. It gets symlinked to index.rst by the Makefile - -************************** -Ansible Core Documentation -************************** - -About ansible-core -=================== - -Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. - -Ansible core, or ``ansible-core`` is the main building block and architecture for Ansible, and includes: - -* CLI tools such as ``ansible-playbook``, ``ansible-doc``. and others for driving and interacting with automation. -* The Ansible language that uses YAML to create a set of rules for developing Ansible Playbooks and includes functions such as conditionals, blocks, includes, loops, and other Ansible imperatives. -* An architectural framework that allows extensions through Ansible collections. - -Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program. - -We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances. - -You can learn more at `AnsibleFest `_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with. - -Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems. - -This documentation covers the version of ``ansible-core`` noted in the upper left corner of this page. We maintain multiple versions of ``ansible-core`` and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added. - - -``ansible-core`` releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly. - -.. toctree:: - :maxdepth: 2 - :caption: Ansible getting started - - getting_started/index - -.. toctree:: - :maxdepth: 2 - :caption: Installation, Upgrade & Configuration - - installation_guide/index - porting_guides/core_porting_guides - -.. toctree:: - :maxdepth: 2 - :caption: Using Ansible Core - - inventory_guide/index - command_guide/index - playbook_guide/index - vault_guide/index - module_plugin_guide/index - collections_guide/index - os_guide/index - tips_tricks/index - -.. toctree:: - :maxdepth: 2 - :caption: Contributing to Ansible Core - - community/index - community/contributions - community/advanced_index - dev_guide/style_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Extending Ansible - - dev_guide/index - -.. toctree:: - :maxdepth: 2 - :caption: Ansible Galaxy - - galaxy/user_guide.rst - galaxy/dev_guide.rst - -.. toctree:: - :maxdepth: 1 - :caption: Reference & Appendices - - collections/index - collections/all_plugins - reference_appendices/playbooks_keywords - reference_appendices/common_return_values - reference_appendices/config - reference_appendices/general_precedence - reference_appendices/YAMLSyntax - reference_appendices/python_3_support - reference_appendices/interpreter_discovery - reference_appendices/release_and_maintenance - reference_appendices/test_strategies - dev_guide/testing/sanity/index - reference_appendices/faq - reference_appendices/glossary - reference_appendices/module_utils - reference_appendices/special_variables - reference_appendices/tower - reference_appendices/automationhub - reference_appendices/logging - -.. toctree:: - :maxdepth: 2 - :caption: Roadmaps - - roadmap/ansible_core_roadmap_index.rst diff --git a/docs/docsite/rst/dev_guide/ansible_index.rst b/docs/docsite/rst/dev_guide/ansible_index.rst deleted file mode 100644 index a660df06e57..00000000000 --- a/docs/docsite/rst/dev_guide/ansible_index.rst +++ /dev/null @@ -1,92 +0,0 @@ -.. _developer_guide: - -*************** -Developer Guide -*************** - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible Developer Guide! - -**Who should use this guide?** - -If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. - -Find the task that best describes what you want to do: - -* I'm looking for a way to address a use case: - - * I want to :ref:`add a custom plugin or module locally `. - * I want to figure out if :ref:`developing a module is the right approach ` for my use case. - * I want to :ref:`develop a collection `. - * I want to :ref:`contribute to an Ansible-maintained collection `. - * I want to :ref:`contribute to a community-maintained collection `. - * I want to :ref:`migrate a role to a collection `. - -* I've read the info above, and I'm sure I want to develop a module: - - * What do I need to know before I start coding? - * I want to :ref:`set up my Python development environment `. - * I want to :ref:`get started writing a module `. - * I want to write a specific kind of module: - * a :ref:`network module ` - * a :ref:`Windows module `. - * an :ref:`Amazon module `. - * an :ref:`oVirt/RHV module `. - * a :ref:`VMware module `. - * I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on). - -* I want to refine my code: - - * I want to :ref:`debug my module code `. - * I want to :ref:`add tests `. - * I want to :ref:`document my module `. - * I want to :ref:`document my set of modules for a network platform `. - * I want to follow :ref:`conventions and tips for clean, usable module code `. - * I want to :ref:`make sure my code runs on Python 2 and Python 3 `. - -* I want to work on other development projects: - - * I want to :ref:`write a plugin `. - * I want to :ref:`connect Ansible to a new source of inventory `. - * I want to :ref:`deprecate an outdated module `. - -* I want to contribute back to the Ansible project: - - * I want to :ref:`understand how to contribute to Ansible `. - * I want to :ref:`contribute my module or plugin `. - * I want to :ref:`understand the license agreement ` for contributions to Ansible. - -If you prefer to read the entire guide, here's a list of the pages in order. - -.. toctree:: - :maxdepth: 2 - - developing_locally - developing_modules - developing_modules_general - developing_modules_checklist - developing_modules_best_practices - developing_python_3 - debugging - developing_modules_documenting - sidecar - developing_modules_general_windows - developing_modules_in_groups - testing - module_lifecycle - developing_plugins - developing_inventory - developing_core - developing_program_flow_modules - developing_api - developing_rebasing - developing_module_utilities - developing_collections - migrating_roles - collections_galaxy_meta - overview_architecture diff --git a/docs/docsite/rst/dev_guide/core_branches_and_tags.rst b/docs/docsite/rst/dev_guide/core_branches_and_tags.rst deleted file mode 100644 index aaef4aa5695..00000000000 --- a/docs/docsite/rst/dev_guide/core_branches_and_tags.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _core_branches_and_tags: - -****************************************** -``ansible-core`` project branches and tags -****************************************** - -``devel`` branch -================ - -All new development on the next version of ``ansible-core`` occurs exclusively in the ``devel`` branch, -and all bugfixes to prior releases must first be merged to devel before being backported to one or more stable branches -for inclusion in servicing releases. Around the Beta 1 milestone, a new ``stable-X.Y`` branch is cut from ``devel``, -which is then updated to host development of the ``X.Y+1`` release. External automated testing of Ansible content from -``devel`` is not generally recommended. - -``stable-X.Y`` branches -======================= - -All ``ansible-core`` ``X.Y.Z`` releases are created from a corresponding ``stable-X.Y`` branch. A -release's stable branch is typically cut from ``devel`` around ``X.Y.0 beta 1`` (when the release is feature complete). -All further bugfixes (no enhancements!) must be made against ``devel`` and backported to applicable stable branches. - -``vX.Y.Z`` tags -=============== - -Each ``ansible-core vX.Y.Z`` release is tagged from the release commit in the corresponding ``stable-X.Y`` branch, -allowing access to the exact source used to create the release. As of ``ansible-core`` 2.13, the auto-generated GitHub -tarball of the tag contents is considered the official canonical release artifact. - - -.. _milestone_branch: - -``milestone`` branch -==================== - -A ``milestone`` branch is a slow-moving stream of the ``devel`` branch, intended for external testing of ``ansible-core`` -features under active development. As described in the :ref:`ansible_core_roadmaps` for a given release, development is -typically split into three phases of decreasing duration, with larger and more invasive changes targeted to be merged to -``devel`` in earlier phases. The ``milestone`` branch is updated to the contents of ``devel`` at the end of each -development phase. This allows testing of semi-stable unreleased features on a predictable schedule without the exposure -to the potential instability of the daily commit "fire hose" from ``devel``. When a release reaches the Beta 1 milestone, -the ``milestone`` branch will be updated to the first ``devel`` commit after the version number has been increased. -Further testing of the same release should be done from the new ``stable-X.Y`` branch that was created. If a severe issue -that significantly affects community testing or stability is discovered in the ``milestone`` branch, the branch contents -may require unscheduled adjustment, but not in a way that prevents fast-forward updates (for example, ``milestone``-only -commits will not be created or cherry-picked from ``devel``). - -The following example is for illustrative purposes only. See the :ref:`ansible_core_roadmaps` for accurate dates. For example, the ``milestone`` branch in 2.13 ``ansible-core`` roadmap updated as follows: - -* 27-Sep-2021: 2.13 Development Phase 1 begins; ``milestone`` contents are updated to 2.12.0b1 with version number set to - ``2.13.0.dev0``. Automated content testing that includes version-specific ignore files (e.g., ``ignore-2.12.txt``) - should copy them for the current version (e.g., ``ignore-2.13.txt``) before this point to ensure that automated sanity - testing against the ``milestone`` branch will continue to pass. -* 13-Dec-2021: 2.13 Development Phase 2 begins; ``milestone`` contents are updated to the final commit from Development Phase 1 -* 14-Feb-2022: 2.13 Development Phase 3 begins; ``milestone`` contents are updated to the final commit from Development Phase 2 -* 11-Apr-2022: ``stable-2.13`` branch created with results from Development Phase 3 and freeze. ``2.13.0b1`` is released from - ``stable-2.13``. Automated content testing should continue 2.13 series testing against the new branch. The ``devel`` - version number is updated to ``2.14.0.dev0``, and ``milestone`` is updated to that point. diff --git a/docs/docsite/rst/dev_guide/core_index.rst b/docs/docsite/rst/dev_guide/core_index.rst deleted file mode 100644 index 3c2fdb73d46..00000000000 --- a/docs/docsite/rst/dev_guide/core_index.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. _developer_guide: - -*************** -Developer Guide -*************** - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible Developer Guide! - -**Who should use this guide?** - -If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. - -Find the task that best describes what you want to do: - -* I'm looking for a way to address a use case: - - * I want to :ref:`add a custom plugin or module locally `. - * I want to figure out if :ref:`developing a module is the right approach ` for my use case. - * I want to :ref:`develop a collection `. - * I want to :ref:`contribute to an Ansible-maintained collection `. - * I want to :ref:`contribute to a community-maintained collection `. - * I want to :ref:`migrate a role to a collection `. - -* I've read the info above, and I'm sure I want to develop a module: - - * What do I need to know before I start coding? - * I want to :ref:`set up my Python development environment `. - * I want to :ref:`get started writing a module `. - * I want to write a specific kind of module: - * a :ref:`network module ` - * a :ref:`Windows module `. - * I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on). - -* I want to refine my code: - - * I want to :ref:`debug my module code `. - * I want to :ref:`add tests `. - * I want to :ref:`document my module `. - * I want to :ref:`document my set of modules for a network platform `. - * I want to follow :ref:`conventions and tips for clean, usable module code `. - * I want to :ref:`make sure my code runs on Python 2 and Python 3 `. - -* I want to work on other development projects: - - * I want to :ref:`write a plugin `. - * I want to :ref:`connect Ansible to a new source of inventory `. - * I want to :ref:`deprecate an outdated module `. - -* I want to contribute back to the Ansible project: - - * I want to :ref:`understand how to contribute to Ansible `. - * I want to :ref:`contribute my module or plugin `. - * I want to :ref:`understand the license agreement ` for contributions to Ansible. - -If you prefer to read the entire guide, here's a list of the pages in order. - -.. toctree:: - :maxdepth: 2 - - developing_locally - developing_modules - developing_modules_general - developing_modules_checklist - developing_modules_best_practices - developing_python_3 - debugging - developing_modules_documenting - sidecar - developing_modules_general_windows - developing_modules_in_groups - testing - module_lifecycle - developing_plugins - developing_inventory - developing_core - developing_program_flow_modules - developing_api - developing_rebasing - developing_module_utilities - developing_collections - migrating_roles - collections_galaxy_meta - overview_architecture diff --git a/docs/docsite/rst/dev_guide/debugging.rst b/docs/docsite/rst/dev_guide/debugging.rst deleted file mode 100644 index 0ed23c5881c..00000000000 --- a/docs/docsite/rst/dev_guide/debugging.rst +++ /dev/null @@ -1,112 +0,0 @@ -.. _debugging_modules: - -***************** -Debugging modules -***************** - -.. contents:: - :local: - -.. _detailed_debugging: - -Detailed debugging steps -======================== - -Ansible modules are put together as a zip file consisting of the module file and the various Python module boilerplate inside of a wrapper script. To see what is actually happening in the module, you need to extract the file from the wrapper. The wrapper script provides helper methods that let you do that. - -The following steps use ``localhost`` as the target host, but you can use the same steps to debug against remote hosts as well. For a simpler approach to debugging without using the temporary files, see :ref:`simple debugging `. - - -#. Set :envvar:`ANSIBLE_KEEP_REMOTE_FILES` to ``1`` on the control host so Ansible will keep the remote module files instead of deleting them after the module finishes executing. Use the ``-vvv`` option to make Ansible more verbose. This will display the file name of the temporary module file. - - .. code-block:: shell-session - - $ ANSIBLE_KEEP_REMOTE_FILES=1 ansible localhost -m ping -a 'data=debugging_session' -vvv - <127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: badger - <127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595 `" )' - <127.0.0.1> PUT /var/tmp/tmpjdbJ1w TO /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595/AnsiballZ_ping.py - <127.0.0.1> EXEC /bin/sh -c 'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595/AnsiballZ_ping.py && sleep 0' - localhost | SUCCESS => { - "changed": false, - "invocation": { - "module_args": { - "data": "debugging_session" - }, - "module_name": "ping" - }, - "ping": "debugging_session" - } - -#. Navigate to the temporary directory from the previous step. If the previous command was run against a remote host, connect to that host first before trying to navigate to the temporary directory. - - .. code-block:: shell-session - - $ ssh remotehost # only if not debugging against localhost - $ cd /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595 - -#. Run the wrapper's ``explode`` command to turn the string into some Python files that you can work with. - - .. code-block:: shell-session - - $ python AnsiballZ_ping.py explode - Module expanded into: - /home/badger/.ansible/tmp/ansible-tmp-1461434734.35-235318071810595/debug_dir - - If you want to examine the wrapper file you can. It will show a small Python script with a large base64 encoded string. The string contains the module to execute. - -#. When you look into the temporary directory you'll see a structure like this: - - .. code-block:: shell-session - - ├── AnsiballZ_ping.py - └── debug_dir - ├── ansible - │   ├── __init__.py - │   ├── module_utils - │   │   ├── __init__.py - │   │   ├── _text.py - │   │   ├── basic.py - │   │   ├── common - │   │   ├── compat - │   │   ├── distro - │   │   ├── parsing - │   │   ├── pycompat24.py - │   │   └── six - │   └── modules - │   ├── __init__.py - │   └── ping.py - └── args - - * ``AnsiballZ_ping.py`` is the Python script with the module code stored in a base64 encoded string. It contains various helper functions for executing the module. - - * ``ping.py`` is the code for the module itself. You can modify this code to see what effect it would have on your module, or for debugging purposes. - - * The ``args`` file contains a JSON string. The string is a dictionary containing the module arguments and other variables that Ansible passes into the module to change its behavior. Modify this file to change the parameters passed to the module. - - * The ``ansible`` directory contains the module code in ``modules`` as well as code from :mod:`ansible.module_utils` that is used by the module. Ansible includes files for any :mod:`ansible.module_utils` imports in the module but not any files from any other module. If your module uses :mod:`ansible.module_utils.url` Ansible will include it for you. But if your module includes `requests `_, then you'll have to make sure that the Python `requests library `_ is installed on the system before running the module. - - You can modify files in this directory if you suspect that the module is having a problem in some of this boilerplate code rather than in the module code you have written. - -#. Once you edit the code or arguments in the exploded tree, use the ``execute`` subcommand to run it: - - .. code-block:: shell-session - - $ python AnsiballZ_ping.py execute - {"invocation": {"module_args": {"data": "debugging_session"}}, "changed": false, "ping": "debugging_session"} - - This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works by using the ``ansible`` or ``ansible-playbook``. - - -.. _simple_debugging: - -Simple debugging -================ - -The easiest way to run a debugger in a module, either local or remote, is to use `epdb `_. Add ``import epdb; epdb.serve()`` in the module code on the control node at the desired break point. To connect to the debugger, run ``epdb.connect()``. See the `epdb documentation `_ for how to specify the ``host`` and ``port``. If connecting to a remote node, make sure to use a port that is allowed by any firewall between the control node and the remote node. - -This technique should work with any remote debugger, but we do not guarantee any particular remote debugging tool will work. - -The `q `_ library is another very useful debugging tool. - -Since ``print()`` statements do not work inside modules, raising an exception is a good approach if you just want to see some specific data. Put ``raise Exception(some_value)`` somewhere in the module and run it normally. Ansible will handle this exception, pass the message back to the control node, and display it. - diff --git a/docs/docsite/rst/dev_guide/developing_api.rst b/docs/docsite/rst/dev_guide/developing_api.rst deleted file mode 100644 index 3ea552a2132..00000000000 --- a/docs/docsite/rst/dev_guide/developing_api.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _developing_api: - -********** -Python API -********** - -.. contents:: Topics - -.. note:: This API is intended for internal Ansible use. Ansible may make changes to this API at any time that could break backward compatibility with older versions of the API. Because of this, external use is not supported by Ansible. If you want to use Python API only for executing playbooks or modules, consider `ansible-runner `_ first. - -There are several ways to use Ansible from an API perspective. You can use -the Ansible Python API to control nodes, you can extend Ansible to respond to various Python events, you can -write plugins, and you can plug in inventory data from external data sources. This document -gives a basic overview and examples of the Ansible execution and playbook API. - -If you would like to use Ansible programmatically from a language other than Python, trigger events asynchronously, -or have access control and logging demands, please see the `AWX project `_. - -.. note:: Because Ansible relies on forking processes, this API is not thread safe. - -.. _python_api_example: - -Python API example -================== - -This example is a simple demonstration that shows how to minimally run a couple of tasks: - -.. literalinclude:: ../../../../examples/scripts/uptime.py - :language: python - -.. note:: Ansible emits warnings and errors through the display object, which prints directly to stdout, stderr and the Ansible log. - -The source code for the ``ansible`` -command line tools (``lib/ansible/cli/``) is `available on GitHub `_. - -.. seealso:: - - :ref:`developing_inventory` - Developing dynamic inventory integrations - :ref:`developing_modules_general` - Getting started on developing a module - :ref:`developing_plugins` - How to develop plugins - `Development Mailing List `_ - Mailing list for development topics - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections.rst b/docs/docsite/rst/dev_guide/developing_collections.rst deleted file mode 100644 index d3fb4f7fcad..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. _developing_collections: - -********************** -Developing collections -********************** - -Collections are a distribution format for Ansible content. You can package and distribute playbooks, roles, modules, and plugins using collections. A typical collection addresses a set of related use cases. For example, the ``cisco.ios`` collection automates management of Cisco IOS devices. - -You can create a collection and publish it to `Ansible Galaxy `_ or to a private Automation Hub instance. You can publish certified collections to the Red Hat Automation Hub, part of the Red Hat Ansible Automation Platform. - -.. toctree:: - :maxdepth: 2 - :caption: Developing new collections - - developing_collections_creating - developing_collections_shared - developing_collections_testing - developing_collections_distributing - developing_collections_documenting - -.. toctree:: - :maxdepth: 2 - :caption: Working with existing collections - - developing_collections_migrating - developing_collections_contributing - developing_collections_changelogs - -.. toctree:: - :maxdepth: 2 - :caption: Collections references - - developing_collections_structure - collections_galaxy_meta - -For instructions on developing modules, see :ref:`developing_modules_general`. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections in playbooks and roles - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Ansible Collections Overview and FAQ `_ - Current development status of community collections and FAQ - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_changelogs.rst b/docs/docsite/rst/dev_guide/developing_collections_changelogs.rst deleted file mode 100644 index 3e164090d2b..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_changelogs.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. _collection_changelogs: - -*************************************************************** -Generating changelogs and porting guide entries in a collection -*************************************************************** - -You can create and share changelog and porting guide entries for your collection. If your collection is part of the Ansible Community package, we recommend that you use the `antsibull-changelog `_ tool to generate Ansible-compatible changelogs. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release. - -.. note:: - - Ansible here refers to the Ansible 2.10 or later release that includes a curated set of collections. - -.. contents:: - :local: - :depth: 2 - -Understanding antsibull-changelog -================================= - -The ``antsibull-changelog`` tool allows you to create and update changelogs for Ansible collections that are compatible with the combined Ansible changelogs. This is an update to the changelog generator used in prior Ansible releases. The tool adds three new changelog fragment categories: ``breaking_changes``, ``security_fixes`` and ``trivial``. The tool also generates the ``changelog.yaml`` file that Ansible uses to create the combined ``CHANGELOG.rst`` file and Porting Guide for the release. - -See :ref:`changelogs_how_to` and the `antsibull-changelog documentation `_ for complete details. - -.. note:: - - The collection maintainers set the changelog policy for their collections. See the individual collection contributing guidelines for complete details. - -Generating changelogs ---------------------- - -To initialize changelog generation: - -#. Install ``antsibull-changelog``: :code:`pip install antsibull-changelog`. -#. Initialize changelogs for your repository: :code:`antsibull-changelog init `. -#. Optionally, edit the ``changelogs/config.yaml`` file to customize the location of the generated changelog ``.rst`` file or other options. See `Bootstrapping changelogs for collections `_ for details. - -To generate changelogs from the changelog fragments you created: - -#. Optionally, validate your changelog fragments: :code:`antsibull-changelog lint`. -#. Generate the changelog for your release: :code:`antsibull-changelog release [--version version_number]`. - -.. note:: - - Add the ``--reload-plugins`` option if you ran the ``antsibull-changelog release`` command previously and the version of the collection has not changed. ``antsibull-changelog`` caches the information on all plugins and does not update its cache until the collection version changes. - -Porting Guide entries from changelog fragments ----------------------------------------------- - -The Ansible changelog generator automatically adds several changelog fragment categories to the Ansible Porting Guide: - -* ``major_changes`` -* ``breaking_changes`` -* ``deprecated_features`` -* ``removed_features`` - -Including collection changelogs into Ansible -============================================= - -If your collection is part of Ansible, use one of the following three options to include your changelog into the Ansible release changelog: - -* Use the ``antsibull-changelog`` tool. - -* If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format `_ for details. - -* Add a link to own changelogs or release notes in any format by opening an issue at https://github.com/ansible-community/ansible-build-data/ with the HTML link to that information. - -.. note:: - - For the first two options, Ansible pulls the changelog details from Galaxy so your changelogs must be included in the collection version on Galaxy that is included in the upcoming Ansible release. - -.. seealso:: - - :ref:`collection_changelogs` - Learn how to create good changelog fragments. - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_contributing.rst b/docs/docsite/rst/dev_guide/developing_collections_contributing.rst deleted file mode 100644 index 86f5fea663b..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_contributing.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _hacking_collections: - -*************************** -Contributing to collections -*************************** - -If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``). -You should first check the collection repository to see if it has specific contribution guidelines. These are typically listed in the README.md or CONTRIBUTING.md files within the repository. - -Contributing to a collection: community.general -=============================================== - -These instructions apply to collections hosted in the `ansible_collections GitHub organization `_. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it. - -This example uses the `community.general collection `_. To contribute to other collections in the same GitHub org, replace the folder names ``community`` and ``general`` with the namespace and collection name of a different collection. - -Prerequisites -------------- - -* Include ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS` -* If that path mentions multiple directories, make sure that no other directory earlier in the search path contains a copy of ``community.general``. - -Creating a PR -------------- - - - -* Create the directory ``~/dev/ansible/collections/ansible_collections/community``: - -.. code-block:: shell - - mkdir -p ~/dev/ansible/collections/ansible_collections/community - -* Clone `the community.general Git repository `_ or a fork of it into the directory ``general``: - -.. code-block:: shell - - cd ~/dev/ansible/collections/ansible_collections/community - git clone git@github.com:ansible-collections/community.general.git general - -* If you clone from a fork, add the original repository as a remote ``upstream``: - -.. code-block:: shell - - cd ~/dev/ansible/collections/ansible_collections/community/general - git remote add upstream git@github.com:ansible-collections/community.general.git - -* Create a branch and commit your changes on the branch. - -* Remember to add tests for your changes, see :ref:`testing_collections`. - -* Push your changes to your fork of the collection and create a Pull Request. - -You can test your changes by using this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of ``ansible/ansible``'s ``devel`` branch. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_creating.rst b/docs/docsite/rst/dev_guide/developing_collections_creating.rst deleted file mode 100644 index 90a13a64c21..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_creating.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _creating_collections: - -******************** -Creating collections -******************** - -To create a collection: - -#. Create a :ref:`collection skeleton` with the ``collection init`` command. -#. Add modules and other content to the collection. -#. Build the collection into a collection artifact with :ref:`ansible-galaxy collection build`. -#. Publish the collection artifact to Galaxy with :ref:`ansible-galaxy collection publish`. - -A user can then install your collection on their systems. - -.. contents:: - :local: - :depth: 2 - -.. _creating_collections_skeleton: - -Creating a collection skeleton -============================== - -To start a new collection, run the following command in your collections directory: - -.. code-block:: bash - - ansible_collections#> ansible-galaxy collection init my_namespace.my_collection - -.. note:: - - Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces `_ on the Galaxy docsite for those requirements. - -It will create the structure ``[my_namespace]/[my_collection]/[collection skeleton]``. - -.. hint:: If Git is used for version control, the corresponding repository should be initialized in the collection directory. - -Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections `_ GitHub Org to get a better idea of what you can place inside a collection. - -Reference: the ``ansible-galaxy collection`` command - -Currently the ``ansible-galaxy collection`` command implements the following sub commands: - -* ``init``: Create a basic collection skeleton based on the default template included with Ansible or your own template. -* ``build``: Create a collection artifact that can be uploaded to Galaxy or your own repository. -* ``publish``: Publish a built collection artifact to Galaxy. -* ``install``: Install one or more collections. - -To learn more about the ``ansible-galaxy`` command-line tool, see the :ref:`ansible-galaxy` man page. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`collection_structure` - Directories and files included in the collection skeleton - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_distributing.rst b/docs/docsite/rst/dev_guide/developing_collections_distributing.rst deleted file mode 100644 index 124d112439c..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_distributing.rst +++ /dev/null @@ -1,406 +0,0 @@ -.. _distributing_collections: - -************************ -Distributing collections -************************ - -A collection is a distribution format for Ansible content. A typical collection contains modules and other plugins that address a set of related use cases. For example, a collection might automate administering a particular database. A collection can also contain roles and playbooks. - -To distribute your collection and allow others to use it, you can publish your collection on one or more :term:`distribution server`. Distribution servers include: - -================================= =================================================================== -Distribution server Collections accepted -================================= =================================================================== -Ansible Galaxy All collections -:term:`Pulp 3 Galaxy` All collections, supports signed collections -Red Hat Automation Hub Only collections certified by Red Hat, supports signed collections -Privately hosted Automation Hub Collections authorized by the owners -================================= =================================================================== - -Distributing collections involves four major steps: - -#. Initial configuration of your distribution server or servers -#. Building your collection tarball -#. Preparing to publish your collection -#. Publishing your collection - -.. contents:: - :local: - :depth: 2 - -.. _config_distribution_server: - -Initial configuration of your distribution server or servers -============================================================ - -Configure a connection to one or more distribution servers so you can publish collections there. You only need to configure each distribution server once. You must repeat the other steps (building your collection tarball, preparing to publish, and publishing your collection) every time you publish a new collection or a new version of an existing collection. - -1. Create a namespace on each distribution server you want to use. -2. Get an API token for each distribution server you want to use. -3. Specify the API token for each distribution server you want to use. - -.. _get_namespace: - -Creating a namespace --------------------- - -You must upload your collection into a namespace on each distribution server. If you have a login for Ansible Galaxy, your Ansible Galaxy username is usually also an Ansible Galaxy namespace. - -.. warning:: - - Namespaces on Ansible Galaxy cannot include hyphens. If you have a login for Ansible Galaxy that includes a hyphen, your Galaxy username is not also a Galaxy namespace. For example, ``awesome-user`` is a valid username for Ansible Galaxy, but it is not a valid namespace. - -You can create additional namespaces on Ansible Galaxy if you choose. For Red Hat Automation Hub and private Automation Hub you must create a namespace before you can upload your collection. To create a namespace: - -* To create a namespace on Galaxy, see `Galaxy namespaces `_ on the Galaxy docsite for details. -* To create a namespace on Red Hat Automation Hub, see the `Ansible Certified Content FAQ `_. - -Specify the namespace in the :file:`galaxy.yml` file for each collection. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. - -.. _galaxy_get_token: - -Getting your API token ----------------------- - -An API token authenticates your connection to each distribution server. You need a separate API token for each distribution server. Use the correct API token to connect to each distribution server securely and protect your content. - -To get your API token: - -* To get an API token for Galaxy, go to the `Galaxy profile preferences `_ page and click :guilabel:`API Key`. -* To get an API token for Automation Hub, go to `the token page `_ and click :guilabel:`Load token`. - -.. _galaxy_specify_token: - -Specifying your API token and distribution server -------------------------------------------------- - -Each time you publish a collection, you must specify the API token and the distribution server to create a secure connection. You have two options for specifying the token and distribution server: - -* You can configure the token in configuration, as part of a ``galaxy_server_list`` entry in your :file:`ansible.cfg` file. Using configuration is the most secure option. -* You can pass the token at the command line as an argument to the ``ansible-galaxy`` command. If you pass the token at the command line, you can specify the server at the command line, by using the default setting, or by setting the server in configuration. Passing the token at the command line is insecure, because typing secrets at the command line may expose them to other users on the system. - -.. _galaxy_token_ansible_cfg: - -Specifying the token and distribution server in configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible Galaxy is configured as the only distribution server. You can add other distribution servers and specify your API token or tokens in configuration by editing the ``galaxy_server_list`` section of your :file:`ansible.cfg` file. This is the most secure way to manage authentication for distribution servers. Specify a URL and token for each server. For example: - -.. code-block:: ini - - [galaxy] - server_list = release_galaxy - - [galaxy_server.release_galaxy] - url=https://galaxy.ansible.com/ - token=abcdefghijklmnopqrtuvwxyz - -You cannot use ``apt-key`` with any servers defined in your :ref:`galaxy_server_list `. See :ref:`galaxy_server_config` for complete details. - -.. _galaxy_use_token_arg: - -Specifying the token at the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can specify the API token at the command line using the ``--token`` argument of the :ref:`ansible-galaxy` command. There are three ways to specify the distribution server when passing the token at the command line: - -* using the ``--server`` argument of the :ref:`ansible-galaxy` command -* relying on the default (https://galaxy.ansible.com) -* setting a server in configuration by creating a :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file - -For example: - -.. code-block:: bash - - ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz --token abcdefghijklmnopqrtuvwxyz - -.. warning:: - - Using the ``--token`` argument is insecure. Passing secrets at the command line may expose them to others on the system. - -.. _building_collections: - -Building your collection tarball -================================ - -After configuring one or more distribution servers, build a collection tarball. The collection tarball is the published artifact, the object that you upload and other users download to install your collection. To build a collection tarball: - -#. Review the version number in your :file:`galaxy.yml` file. Each time you publish your collection, it must have a new version number. You cannot make changes to existing versions of your collection on a distribution server. If you try to upload the same collection version more than once, the distribution server returns the error ``Code: conflict.collection_exists``. Collections follow semantic versioning rules. For more information on versions, see :ref:`collection_versions`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. -#. Run ``ansible-galaxy collection build`` from inside the top-level directory of the collection. For example: - -.. code-block:: bash - - collection_dir#> ansible-galaxy collection build - -This command builds a tarball of the collection in the current directory, which you can upload to your selected distribution server: - -.. code-block:: shell - - my_collection/ - ├── galaxy.yml - ├── ... - ├── my_namespace-my_collection-1.0.0.tar.gz - └── ... - -.. note:: - * To reduce the size of collections, certain files and folders are excluded from the collection tarball by default. See :ref:`ignoring_files_and_folders_collections` if your collection directory contains other files you want to exclude. - * The current Galaxy maximum tarball size is 2 MB. - -You can upload your tarball to one or more distribution servers. You can also distribute your collection locally by copying the tarball to install your collection directly on target systems. - - -.. _ignoring_files_and_folders_collections: - -Ignoring files and folders --------------------------- - -You can exclude files from your collection with either :ref:`build_ignore ` or :ref:`manifest_directives`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. - - -.. _build_ignore: - -Include all, with explicit ignores -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default the build step includes all the files in the collection directory in the tarball except for the following: - -* ``galaxy.yml`` -* ``*.pyc`` -* ``*.retry`` -* ``tests/output`` -* previously built tarballs in the root directory -* various version control directories such as ``.git/`` - -To exclude other files and folders from your collection tarball, set a list of file glob-like patterns in the ``build_ignore`` key in the collection's ``galaxy.yml`` file. These patterns use the following special characters for wildcard matching: - -* ``*``: Matches everything -* ``?``: Matches any single character -* ``[seq]``: Matches any character in sequence -* ``[!seq]``:Matches any character not in sequence - -For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well any ``.tar.gz`` archives, set the following in your ``galaxy.yml`` file: - -.. code-block:: yaml - - build_ignore: - - playbooks/sensitive - - '*.tar.gz' - -.. note:: - The ``build_ignore`` feature is only supported with ``ansible-galaxy collection build`` in Ansible 2.10 or newer. - - -.. _manifest_directives: - -Manifest Directives -^^^^^^^^^^^^^^^^^^^ - -.. versionadded:: 2.14 - -The :file:`galaxy.yml` file supports manifest directives that are historically used in Python packaging, as described in `MANIFEST.in commands `_. - -.. note:: - The use of ``manifest`` requires installing the optional ``distlib`` Python dependency. - -.. note:: - The ``manifest`` feature is only supported with ``ansible-galaxy collection build`` in ``ansible-core`` 2.14 or newer, and is mutually exclusive with ``build_ignore``. - -For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well as any ``.tar.gz`` archives, set the following in your :file:`galaxy.yml` file: - -.. code-block:: yaml - - manifest: - directives: - - recursive-exclude playbooks/sensitive ** - - global-exclude *.tar.gz - -By default, the ``MANIFEST.in`` style directives would exclude all files by default, but there are default directives in place. Those default directives are described below. To see the directives in use during build, pass ``-vvv`` with the ``ansible-galaxy collection build`` command. - -.. code-block:: - - include meta/*.yml - include *.txt *.md *.rst COPYING LICENSE - recursive-include tests ** - recursive-include docs **.rst **.yml **.yaml **.json **.j2 **.txt - recursive-include roles **.yml **.yaml **.json **.j2 - recursive-include playbooks **.yml **.yaml **.json - recursive-include changelogs **.yml **.yaml - recursive-include plugins */**.py - recursive-include plugins/become **.yml **.yaml - recursive-include plugins/cache **.yml **.yaml - recursive-include plugins/callback **.yml **.yaml - recursive-include plugins/cliconf **.yml **.yaml - recursive-include plugins/connection **.yml **.yaml - recursive-include plugins/filter **.yml **.yaml - recursive-include plugins/httpapi **.yml **.yaml - recursive-include plugins/inventory **.yml **.yaml - recursive-include plugins/lookup **.yml **.yaml - recursive-include plugins/netconf **.yml **.yaml - recursive-include plugins/shell **.yml **.yaml - recursive-include plugins/strategy **.yml **.yaml - recursive-include plugins/test **.yml **.yaml - recursive-include plugins/vars **.yml **.yaml - recursive-include plugins/modules **.ps1 **.yml **.yaml - recursive-include plugins/module_utils **.ps1 **.psm1 **.cs - # manifest.directives from galaxy.yml inserted here - exclude galaxy.yml galaxy.yaml MANIFEST.json FILES.json --*.tar.gz - recursive-exclude tests/output ** - global-exclude /.* /__pycache__ - -.. note:: - ``--*.tar.gz`` is expanded with the actual ``namespace`` and ``name``. - -The ``manifest.directives`` supplied in :file:`galaxy.yml` are inserted after the default includes and before the default excludes. - -To enable the use of manifest directives without supplying your own, insert either ``manifest: {}`` or ``manifest: null`` in the :file:`galaxy.yml` file and remove any use of ``build_ignore``. - -If the default manifest directives do not meet your needs, you can set ``manifest.omit_default_directives`` to a value of ``true`` in :file:`galaxy.yml`. You then must specify a full compliment of manifest directives in :file:`galaxy.yml`. The defaults documented above are a good starting point. - -Below is an example where the default directives are not included. - -.. code-block:: yaml - - manifest: - directives: - - include meta/runtime.yml - - include README.md LICENSE - - recursive-include plugins */**.py - - exclude galaxy.yml MANIFEST.json FILES.json --*.tar.gz - - recursive-exclude tests/output ** - omit_default_directives: true - - -.. _signing_collections: - -Signing a collection --------------------------- - -You can include a GnuPG signature with your collection on a :term:`Pulp 3 Galaxy` server. See `Enabling collection signing `_ for details. - -You can manually generate detached signatures for a collection using the ``gpg`` CLI using the following step. This step assume you have generated a GPG private key, but do not cover this process. - -.. code-block:: bash - - ansible-galaxy collection build - tar -Oxzf namespace-name-1.0.0.tar.gz MANIFEST.json | gpg --output namespace-name-1.0.0.asc --detach-sign --armor --local-user email@example.com - - - -.. _trying_collection_locally: - -Preparing to publish your collection -==================================== - -Each time you publish your collection, you must create a :ref:`new version ` on the distribution server. After you publish a version of a collection, you cannot delete or modify that version. To avoid unnecessary extra versions, check your collection for bugs, typos, and other issues locally before publishing: - -#. Install the collection locally. -#. Review the locally installed collection before publishing a new version. - -Installing your collection locally ----------------------------------- - -You have two options for installing your collection locally: - - * Install your collection locally from the tarball. - * Install your collection locally from your git repository. - -Installing your collection locally from the tarball -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To install your collection locally from the tarball, run ``ansible-galaxy collection install`` and specify the collection tarball. You can optionally specify a location using the ``-p`` flag. For example: - -.. code-block:: bash - - collection_dir#> ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections - -Install the tarball into a directory configured in :ref:`COLLECTIONS_PATHS` so Ansible can easily find and load the collection. If you do not specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`. - -.. _collections_scm_install: - -Installing your collection locally from a git repository -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To install your collection locally from a git repository, specify the repository and the branch you want to install: - -.. code-block:: bash - - collection_dir#> ansible-galaxy collection install git+https://github.com/org/repo.git,devel - -.. include:: ../shared_snippets/installing_collections_git_repo.txt - -Reviewing your collection -------------------------- - -Review the collection: - -* Run a playbook that uses the modules and plugins in your collection. Verify that new features and functionality work as expected. For examples and more details see :ref:`Using collections `. -* Check the documentation for typos. -* Check that the version number of your tarball is higher than the latest published version on the distribution server or servers. -* If you find any issues, fix them and rebuild the collection tarball. - -.. _collection_versions: - -Understanding collection versioning ------------------------------------ - -The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) is the version displayed everywhere in Galaxy and Automation Hub. Users can still download older versions. - -Follow semantic versioning when setting the version for your collection. In summary: - -* Increment the major version number, ``x`` of ``x.y.z``, for an incompatible API change. -* Increment the minor version number, ``y`` of ``x.y.z``, for new functionality in a backwards compatible manner (for example new modules/plugins, parameters, return values). -* Increment the patch version number, ``z`` of ``x.y.z``, for backwards compatible bug fixes. - -Read the official `Semantic Versioning `_ documentation for details and examples. - -.. _publish_collection: - -Publishing your collection -========================== - -The last step in distributing your collection is publishing the tarball to Ansible Galaxy, Red Hat Automation Hub, or a privately hosted Automation Hub instance. You can publish your collection in two ways: - -* from the command line using the ``ansible-galaxy collection publish`` command -* from the website of the distribution server (Galaxy, Automation Hub) itself - -.. _upload_collection_ansible_galaxy: -.. _publish_collection_galaxy_cmd: - -Publishing a collection from the command line ---------------------------------------------- - -To upload the collection tarball from the command line using ``ansible-galaxy``: - -.. code-block:: bash - - ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz - -.. note:: - - This ansible-galaxy command assumes you have retrieved and stored your API token in configuration. See :ref:`galaxy_specify_token` for details. - -The ``ansible-galaxy collection publish`` command triggers an import process, just as if you uploaded the collection through the Galaxy website. The command waits until the import process completes before reporting the status back. If you want to continue without waiting for the import result, use the ``--no-wait`` argument and manually look at the import progress in your `My Imports `_ page. - -.. _upload_collection_galaxy: - -Publishing a collection from the website ----------------------------------------- - -To publish your collection directly on the Galaxy website: - -#. Go to the `My Content `_ page, and click the **Add Content** button on one of your namespaces. -#. From the **Add Content** dialogue, click **Upload New Collection**, and select the collection archive file from your local filesystem. - -When you upload a collection, Ansible always uploads the tarball to the namespace specified in the collection metadata in the ``galaxy.yml`` file, no matter which namespace you select on the website. If you are not an owner of the namespace specified in your collection metadata, the upload request fails. - -After Galaxy uploads and accepts a collection, the website shows you the **My Imports** page. This page shows import process information. You can review any errors or warnings about your upload there. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`collections_galaxy_meta` - Table of fields used in the :file:`galaxy.yml` file - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_documenting.rst b/docs/docsite/rst/dev_guide/developing_collections_documenting.rst deleted file mode 100644 index 8f0c00d6460..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_documenting.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. _documenting_collections: - -*********************** -Documenting collections -*********************** - -Documenting modules and plugins -=============================== - -Documenting modules is thoroughly documented in :ref:`module_documenting`. Plugins can be documented the same way as modules, that is with ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN`` blocks. - -Documenting roles -================= - -To document a role, you have to add a role argument spec by creating a file ``meta/argument_specs.yml`` in your role. See :ref:`role_argument_spec` for details. As an example, you can look at `the argument specs file `_ of the :ref:`sensu.sensu_go.install role ` on GitHub. - -.. _build_collection_docsite: - -Build a docsite with antsibull-docs -=================================== - -You can use `antsibull-docs `_ to build a Sphinx-based docsite for your collection: - -#. Create your collection and make sure you can use it with ansible-core by adding it to your :ref:`COLLECTIONS_PATHS`. -#. Create a directory ``dest`` and run ``antsibull-docs sphinx-init --use-current --dest-dir dest namespace.name``, where ``namespace.name`` is the name of your collection. -#. Go into ``dest`` and run ``pip install -r requirements.txt``. You might want to create a venv and activate it first to avoid installing this globally. -#. Then run ``./build.sh``. -#. Open ``build/html/index.html`` in a browser of your choice. - -If you want to add additional documentation to your collection next to the plugin, module, and role documentation, see :ref:`collections_doc_dir`. diff --git a/docs/docsite/rst/dev_guide/developing_collections_migrating.rst b/docs/docsite/rst/dev_guide/developing_collections_migrating.rst deleted file mode 100644 index 834ff92c6ca..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_migrating.rst +++ /dev/null @@ -1,136 +0,0 @@ -.. _migrate_to_collection: - -*************************************************** -Migrating Ansible content to a different collection -*************************************************** - -When you move content from one collection to another, for example to extract a set of related modules out of ``community.general`` to create a more focused collection, you must make sure the transition is easy for users to follow. - -.. contents:: - :local: - :depth: 2 - -Migrating content -================= - -Before you start migrating content from one collection to another, look at `Ansible Collection Checklist `_. - -To migrate content from one collection to another, if the collections are parts of `Ansible distribution `_: - -#. Copy content from the source (old) collection to the target (new) collection. -#. Deprecate the module/plugin with ``removal_version`` scheduled for the next major version in ``meta/runtime.yml`` of the old collection. The deprecation must be released after the copied content has been included in a release of the new collection. -#. When the next major release of the old collection is prepared: - - * remove the module/plugin from the old collection - * remove the symlink stored in ``plugin/modules`` directory if appropriate (mainly when removing from ``community.general`` and ``community.network``) - * remove related unit and integration tests - * remove specific module utils - * remove specific documentation fragments if there are any in the old collection - * add a changelog fragment containing entries for ``removed_features`` and ``breaking_changes``; you can see an example of a changelog fragment in this `pull request `_ - * change ``meta/runtime.yml`` in the old collection: - - * add ``redirect`` to the corresponding module/plugin's entry - * in particular, add ``redirect`` for the removed module utils and documentation fragments if applicable - * remove ``removal_version`` from there - * remove related entries from ``tests/sanity/ignore.txt`` files if exist - * remove changelog fragments for removed content that are not yet part of the changelog (in other words, do not modify `changelogs/changelog.yaml` and do not delete files mentioned in it) - * remove requirements that are no longer required in ``tests/unit/requirements.txt``, ``tests/requirements.yml`` and ``galaxy.yml`` - -To implement these changes, you need to create at least three PRs: - -#. Create a PR against the new collection to copy the content. -#. Deprecate the module/plugin in the old collection. -#. Later create a PR against the old collection to remove the content according to the schedule. - - -Adding the content to the new collection ----------------------------------------- - -Create a PR in the new collection to: - -#. Copy ALL the related files from the old collection. -#. If it is an action plugin, include the corresponding module with documentation. -#. If it is a module, check if it has a corresponding action plugin that should move with it. -#. Check ``meta/`` for relevant updates to ``runtime.yml`` if it exists. -#. Carefully check the moved ``tests/integration`` and ``tests/units`` and update for FQCN. -#. Review ``tests/sanity/ignore-*.txt`` entries in the old collection. -#. Update ``meta/runtime.yml`` in the old collection. - - -Removing the content from the old collection --------------------------------------------- - -Create a PR against the source collection repository to remove the modules, module_utils, plugins, and docs_fragments related to this migration: - -#. If you are removing an action plugin, remove the corresponding module that contains the documentation. -#. If you are removing a module, remove any corresponding action plugin that should stay with it. -#. Remove any entries about removed plugins from ``meta/runtime.yml``. Ensure they are added into the new repo. -#. Remove sanity ignore lines from ``tests/sanity/ignore\*.txt`` -#. Remove associated integration tests from ``tests/integrations/targets/`` and unit tests from ``tests/units/plugins/``. -#. if you are removing from content from ``community.general`` or ``community.network``, remove entries from ``.github/BOTMETA.yml``. -#. Carefully review ``meta/runtime.yml`` for any entries you may need to remove or update, in particular deprecated entries. -#. Update ``meta/runtime.yml`` to contain redirects for EVERY PLUGIN, pointing to the new collection name. - -.. warning:: - - Maintainers for the old collection have to make sure that the PR is merged in a way that it does not break user experience and semantic versioning: - - #. A new version containing the merged PR must not be released before the collection the content has been moved to has been released again, with that content contained in it. Otherwise the redirects cannot work and users relying on that content will experience breakage. - #. Once 1.0.0 of the collection from which the content has been removed has been released, such PRs can only be merged for a new **major** version (in other words, 2.0.0, 3.0.0, and so on). - - -Updating BOTMETA.yml --------------------- - -The ``BOTMETA.yml``, for example in `community.general collection repository `_, is the source of truth for: - -* ansibullbot - -If the old and/or new collection has ``ansibullbot``, its ``BOTMETA.yml`` must be updated correspondingly. - -Ansibulbot will know how to redirect existing issues and PRs to the new repo. The build process for docs.ansible.com will know where to find the module docs. - -.. code-block:: yaml - - $modules/monitoring/grafana/grafana_plugin.py: - migrated_to: community.grafana - $modules/monitoring/grafana/grafana_dashboard.py: - migrated_to: community.grafana - $modules/monitoring/grafana/grafana_datasource.py: - migrated_to: community.grafana - $plugins/callback/grafana_annotations.py: - maintainers: $team_grafana - labels: monitoring grafana - migrated_to: community.grafana - $plugins/doc_fragments/grafana.py: - maintainers: $team_grafana - labels: monitoring grafana - migrated_to: community.grafana - -`Example PR `_ - -* The ``migrated_to:`` key must be added explicitly for every *file*. You cannot add ``migrated_to`` at the directory level. This is to allow module and plugin webdocs to be redirected to the new collection docs. -* ``migrated_to:`` MUST be added for every: - - * module - * plugin - * module_utils - * contrib/inventory script - -* You do NOT need to add ``migrated_to`` for: - - * Unit tests - * Integration tests - * ReStructured Text docs (anything under ``docs/docsite/rst/``) - * Files that never existed in ``ansible/ansible:devel`` - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_shared.rst b/docs/docsite/rst/dev_guide/developing_collections_shared.rst deleted file mode 100644 index 34db6aea696..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_shared.rst +++ /dev/null @@ -1,94 +0,0 @@ -.. _collections_shared_resources: - -************************************* -Using shared resources in collections -************************************* - -Although developing Ansible modules contained in collections is similar to developing standalone Ansible modules, you use shared resources like documentation fragments and module utilities differently in collections. You can use documentation fragments within and across collections. You can use optional module utilities to support multiple versions of ansible-core in your collection. Collections can also depend on other collections. - -.. contents:: - :local: - :depth: 2 - -.. _docfragments_collections: - -Using documentation fragments in collections -============================================ - -To include documentation fragments in your collection: - -#. Create the documentation fragment: ``plugins/doc_fragments/fragment_name``. - -#. Refer to the documentation fragment with its FQCN. - -.. code-block:: yaml - - extends_documentation_fragment: - - kubernetes.core.k8s_name_options - - kubernetes.core.k8s_auth_options - - kubernetes.core.k8s_resource_options - - kubernetes.core.k8s_scale_options - -:ref:`module_docs_fragments` covers the basics for documentation fragments. The `kubernetes.core `_ collection includes a complete example. - -If you use FQCN, you can use documentation fragments from one collection in another collection. - -.. _optional_module_utils: - -Leveraging optional module utilities in collections -=================================================== - -Optional module utilities let you adopt the latest features from the most recent ansible-core release in your collection-based modules without breaking your collection on older Ansible versions. With optional module utilities, you can use the latest features when running against the latest versions, while still providing fallback behaviors when running against older versions. - -This implementation, widely used in Python programming, wraps optional imports in conditionals or defensive `try/except` blocks, and implements fallback behaviors for missing imports. Ansible's module payload builder supports these patterns by treating any module_utils import nested in a block (e.g., `if`, `try`) as optional. If the requested import cannot be found during the payload build, it is simply omitted from the target payload and assumed that the importing code will handle its absence at runtime. Missing top-level imports of module_utils packages (imports that are not wrapped in a block statement of any kind) will fail the module payload build, and will not execute on the target. - -For example, the `ansible.module_utils.common.respawn` package is only available in Ansible 2.11 and higher. The following module code would fail during the payload build on Ansible 2.10 or earlier (as the requested Python module does not exist, and is not wrapped in a block to signal to the payload builder that it can be omitted from the module payload): - -.. code-block:: python - - from ansible.module_utils.common.respawn import respawn_module - -By wrapping the import statement in a ``try`` block, the payload builder will omit the Python module if it cannot be located, and assume that the Ansible module will handle it at runtime: - -.. code-block:: python - - try: - from ansible.module_utils.common.respawn import respawn_module - except ImportError: - respawn_module = None - ... - if needs_respawn: - if respawn_module: - respawn_module(target) - else: - module.fail_json('respawn is not available in Ansible < 2.11, ensure that foopkg is installed') - -The optional import behavior also applies to module_utils imported from collections. - -.. _collection_dependencies: - -Listing collection dependencies -=============================== - -We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. Use the :file:`meta/runtime.yml` file to set the ansible-core version that your collection depends on. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`. - -You can use git repositories for collection dependencies during local development and testing. For example: - -.. code-block:: yaml - - dependencies: {'git@github.com:organization/repo_name.git': 'devel'} - -.. warning:: - - Do not use git repositories as dependencies for published collections. Dependencies for published collections must be other published collections. - -.. seealso:: - - :ref:`collections` - Learn how to install and use collections. - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_structure.rst b/docs/docsite/rst/dev_guide/developing_collections_structure.rst deleted file mode 100644 index 77d4e8bf56d..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_structure.rst +++ /dev/null @@ -1,293 +0,0 @@ -.. _collection_structure: - -******************** -Collection structure -******************** - -A collection is a simple data structure. None of the directories are required unless you have specific content that belongs in one of them. A collection does require a ``galaxy.yml`` file at the root level of the collection. This file contains all of the metadata that Galaxy and other tools need in order to package, build and publish the collection. - -.. contents:: - :local: - :depth: 2 - -Collection directories and files -================================ - -A collection can contain these directories and files: - -.. code-block:: shell-session - - collection/ - ├── docs/ - ├── galaxy.yml - ├── meta/ - │ └── runtime.yml - ├── plugins/ - │ ├── modules/ - │ │ └── module1.py - │ ├── inventory/ - │ └── .../ - ├── README.md - ├── roles/ - │ ├── role1/ - │ ├── role2/ - │ └── .../ - ├── playbooks/ - │ ├── files/ - │ ├── vars/ - │ ├── templates/ - │ └── tasks/ - └── tests/ - -.. note:: - * Ansible only accepts ``.md`` extensions for the :file:`README` file and any files in the :file:`/docs` folder. - * See the `ansible-collections `_ GitHub Org for examples of collection structure. - * Not all directories are currently in use. Those are placeholders for future features. - -.. _galaxy_yml: - -galaxy.yml ----------- - -A collection must have a ``galaxy.yml`` file that contains the necessary information to build a collection artifact. See :ref:`collections_galaxy_meta` for details. - -.. _collections_doc_dir: - -docs directory --------------- - -Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on. - -For certified collections, Automation Hub displays documents written in markdown in the main ``docs`` directory with no subdirectories. This will not display on https://docs.ansible.com. - -For community collections included in the Ansible PyPI package, docs.ansible.com displays documents written in reStructuredText (.rst) in a docsite/rst/ subdirectory. Define the structure of your extra documentation in ``docs/docsite/extra-docs.yml``: - -.. code-block:: yaml - - --- - sections: - - title: Scenario Guide - toctree: - - scenario_guide - -The index page of the documentation for your collection displays the title you define in ``docs/docsite/extra-docs.yml`` with a link to your extra documentation. For an example, see the `community.docker collection repo `_ and the `community.docker collection documentation `_. - -You can add extra links to your collection index page and plugin pages with the ``docs/docsite/links.yml`` file. This populates the links under `Description and Communications `_ headings as well as links at the end of the individual plugin pages. See the `collection_template links.yml file `_ for a complete description of the structure and use of this file to create links. - -Plugin and module documentation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Keep the specific documentation for plugins and modules embedded as Python docstrings. Use ``ansible-doc`` to view documentation for plugins inside a collection: - -.. code-block:: bash - - ansible-doc -t lookup my_namespace.my_collection.lookup1 - -The ``ansible-doc`` command requires the fully qualified collection name (FQCN) to display specific plugin documentation. In this example, ``my_namespace`` is the Galaxy namespace and ``my_collection`` is the collection name within that namespace. - -.. note:: The Galaxy namespace of an Ansible collection is defined in the ``galaxy.yml`` file. It can be different from the GitHub organization or repository name. - -.. _collections_plugin_dir: - -plugins directory ------------------ - -Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by most plugins by using their FQCN. This is a way to distribute modules, lookups, filters, and so on without having to import a role in every play. - -Vars plugins in collections are not loaded automatically, and always require being explicitly enabled by using their fully qualified collection name. See :ref:`enable_vars` for details. - -Cache plugins in collections may be used for fact caching, but are not supported for inventory plugins. - -.. _collection_module_utils: - -module_utils -^^^^^^^^^^^^ - -When coding with ``module_utils`` in a collection, the Python ``import`` statement needs to take into account the FQCN along with the ``ansible_collections`` convention. The resulting Python import will look like ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}`` - -The following example snippets show a Python and PowerShell module using both default Ansible ``module_utils`` and -those provided by a collection. In this example the namespace is ``community``, the collection is ``test_collection``. -In the Python example the ``module_util`` in question is called ``qradar`` such that the FQCN is -``community.test_collection.plugins.module_utils.qradar``: - -.. code-block:: python - - from ansible.module_utils.basic import AnsibleModule - from ansible.module_utils.common.text.converters import to_text - - from ansible.module_utils.six.moves.urllib.parse import urlencode, quote_plus - from ansible.module_utils.six.moves.urllib.error import HTTPError - from ansible_collections.community.test_collection.plugins.module_utils.qradar import QRadarRequest - - argspec = dict( - name=dict(required=True, type='str'), - state=dict(choices=['present', 'absent'], required=True), - ) - - module = AnsibleModule( - argument_spec=argspec, - supports_check_mode=True - ) - - qradar_request = QRadarRequest( - module, - headers={"Content-Type": "application/json"}, - not_rest_data_keys=['state'] - ) - -Note that importing something from an ``__init__.py`` file requires using the file name: - -.. code-block:: python - - from ansible_collections.namespace.collection_name.plugins.callback.__init__ import CustomBaseClass - -In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FQCN is -``community.test_collection.plugins.module_utils.hyperv``: - -.. code-block:: powershell - - #!powershell - #AnsibleRequires -CSharpUtil Ansible.Basic - #AnsibleRequires -PowerShell ansible_collections.community.test_collection.plugins.module_utils.hyperv - - $spec = @{ - name = @{ required = $true; type = "str" } - state = @{ required = $true; choices = @("present", "absent") } - } - $module = [Ansible.Basic.AnsibleModule]::Create($args, $spec) - - Invoke-HyperVFunction -Name $module.Params.name - - $module.ExitJson() - -.. _collections_roles_dir: - -roles directory ----------------- - -Collection roles are mostly the same as existing roles, but with a couple of limitations: - - - Role names are now limited to contain only lowercase alphanumeric characters, plus ``_`` and start with an alpha character. - - Roles in a collection cannot contain plugins any more. Plugins must live in the collection ``plugins`` directory tree. Each plugin is accessible to all roles in the collection. - -The directory name of the role is used as the role name. Therefore, the directory name must comply with the above role name rules. The collection import into Galaxy will fail if a role name does not comply with these rules. - -You can migrate 'traditional roles' into a collection but they must follow the rules above. You may need to rename roles if they don't conform. You will have to move or link any role-based plugins to the collection specific directories. - -.. note:: - - For roles imported into Galaxy directly from a GitHub repository, setting the ``role_name`` value in the role's metadata overrides the role name used by Galaxy. For collections, that value is ignored. When importing a collection, Galaxy uses the role directory as the name of the role and ignores the ``role_name`` metadata value. - -playbooks directory --------------------- - -In prior releases, you could reference playbooks in this directory using the full path to the playbook file from the command line. -In ansible-core 2.11 and later, you can use the FQCN, ``namespace.collection.playbook`` (with or without extension), to reference the playbooks from the command line or from ``import_playbook``. -This will keep the playbook in 'collection context', as if you had added ``collections: [ namespace.collection ]`` to it. - -You can have most of the subdirectories you would expect, such ``files/``, ``vars/`` or ``templates/`` but no ``roles/`` since those are handled already in the collection. - -Also, playbooks within a collection follow the same guidelines as any playbooks except for these few adjustments: - - - Directory: It must be in the ``playbooks/`` directory. - - Hosts: The host should be defined as a variable so the users of a playbook do not mistakenly run the plays against their entire inventory (if the host is set to all). For example - ``hosts: '{{target|default("all")}}'``. - -To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``docs/`` folder or ``README`` file. - -.. _developing_collections_tests_directory: - -tests directory ----------------- - -Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, by using the `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind. - -See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``. - -When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code through a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you. - -.. _meta_runtime_yml: - -meta directory and runtime.yml ------------------------------- - -A collection can store some additional metadata in a ``runtime.yml`` file in the collection's ``meta`` directory. The ``runtime.yml`` file supports the top level keys: - -- *requires_ansible*: - - The version of Ansible Core (ansible-core) required to use the collection. Multiple versions can be separated with a comma. - - .. code:: yaml - - requires_ansible: ">=2.10,<2.11" - - .. note:: although the version is a `PEP440 Version Specifier `_ under the hood, Ansible deviates from PEP440 behavior by truncating prerelease segments from the Ansible version. This means that Ansible 2.11.0b1 is compatible with something that ``requires_ansible: ">=2.11"``. - -- *plugin_routing*: - - Content in a collection that Ansible needs to load from another location or that has been deprecated/removed. - The top level keys of ``plugin_routing`` are types of plugins, with individual plugin names as subkeys. - To define a new location for a plugin, set the ``redirect`` field to another name. - To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal version or date. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal version or date. - - .. code:: yaml - - plugin_routing: - inventory: - kubevirt: - redirect: community.general.kubevirt - my_inventory: - tombstone: - removal_version: "2.0.0" - warning_text: my_inventory has been removed. Please use other_inventory instead. - modules: - my_module: - deprecation: - removal_date: "2021-11-30" - warning_text: my_module will be removed in a future release of this collection. Use another.collection.new_module instead. - redirect: another.collection.new_module - podman_image: - redirect: containers.podman.podman_image - module_utils: - ec2: - redirect: amazon.aws.ec2 - util_dir.subdir.my_util: - redirect: namespace.name.my_util - -- *import_redirection* - - A mapping of names for Python import statements and their redirected locations. - - .. code:: yaml - - import_redirection: - ansible.module_utils.old_utility: - redirect: ansible_collections.namespace_name.collection_name.plugins.module_utils.new_location - -- *action_groups* - - A mapping of groups and the list of action plugin and module names they contain. They may also have a special 'metadata' dictionary in the list, which can be used to include actions from other groups. - - .. code:: yaml - - action_groups: - groupname: - # The special metadata dictionary. All action/module names should be strings. - - metadata: - extend_group: - - another.collection.groupname - - another_group - - my_action - another_group: - - my_module - - another.collection.another_module - -.. seealso:: - - :ref:`distributing_collections` - Learn how to package and publish your collection - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_collections_testing.rst b/docs/docsite/rst/dev_guide/developing_collections_testing.rst deleted file mode 100644 index 50d55ca5b58..00000000000 --- a/docs/docsite/rst/dev_guide/developing_collections_testing.rst +++ /dev/null @@ -1,99 +0,0 @@ -.. _testing_collections: - -******************* -Testing collections -******************* - -Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core. - -.. contents:: - :local: - :depth: 2 - -Testing tools -============= - -The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing` and provided by both the ``ansible`` and ``ansible-core`` packages. - -You can run several sanity tests, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting. - -You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Azure Pipelines both in the ansible/ansible GitHub repository and in the large community collections such as `community.general `_ and `community.network `_. The examples below demonstrate running tests in Docker containers. - -Sanity tests ------------- - -To run all sanity tests: - -.. code-block:: shell-session - - ansible-test sanity --docker default -v - -See :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests ` for details on the sanity tests and how to fix identified issues. - -Adding unit tests ------------------ - -You must place unit tests in the appropriate ``tests/unit/plugins/`` directory. For example, you would place tests for ``plugins/module_utils/foo/bar.py`` in ``tests/unit/plugins/module_utils/foo/test_bar.py`` or ``tests/unit/plugins/module_utils/foo/bar/test_bar.py``. For examples, see the `unit tests in community.general `_. - -To run all unit tests for all supported Python versions: - -.. code-block:: shell-session - - ansible-test units --docker default -v - -To run all unit tests only for a specific Python version: - -.. code-block:: shell-session - - ansible-test units --docker default -v --python 3.6 - -To run only a specific unit test: - -.. code-block:: shell-session - - ansible-test units --docker default -v --python 3.6 tests/unit/plugins/module_utils/foo/test_bar.py - -You can specify Python requirements in the ``tests/unit/requirements.txt`` file. See :ref:`testing_units` for more information, especially on fixture files. - -.. _collections_adding_integration_test: - -Adding integration tests ------------------------- - -You must place integration tests in the appropriate ``tests/integration/targets/`` directory. For module integration tests, you can use the module name alone. For example, you would place integration tests for ``plugins/modules/foo.py`` in a directory called ``tests/integration/targets/foo/``. For non-module plugin integration tests, you must add the plugin type to the directory name. For example, you would place integration tests for ``plugins/connections/bar.py`` in a directory called ``tests/integration/targets/connection_bar/``. For lookup plugins, the directory must be called ``lookup_foo``, for inventory plugins, ``inventory_foo``, and so on. - -You can write two different kinds of integration tests: - -* Ansible role tests run with ``ansible-playbook`` and validate various aspects of the module. They can depend on other integration tests (usually named ``prepare_bar`` or ``setup_bar``, which prepare a service or install a requirement named ``bar`` in order to test module ``foo``) to set-up required resources, such as installing required libraries or setting up server services. -* ``runme.sh`` tests run directly as scripts. They can set up inventory files, and execute ``ansible-playbook`` or ``ansible-inventory`` with various settings. - -For examples, see the `integration tests in community.general `_. See also :ref:`testing_integration` for more details. - -Since integration tests can install requirements, and set-up, start and stop services, we recommended running them in docker containers or otherwise restricted environments whenever possible. By default, ``ansible-test`` supports Docker images for several operating systems. See the `list of supported docker images `_ for all options. Use the ``default`` image mainly for platform-independent integration tests, such as those for cloud modules. The following examples use the ``fedora35`` image. - -To execute all integration tests for a collection: - -.. code-block:: shell-session - - ansible-test integration --docker fedora35 -v - -If you want more detailed output, run the command with ``-vvv`` instead of ``-v``. Alternatively, specify ``--retry-on-error`` to automatically re-run failed tests with higher verbosity levels. - -To execute only the integration tests in a specific directory: - -.. code-block:: shell-session - - ansible-test integration --docker fedora35 -v connection_bar - -You can specify multiple target names. Each target name is the name of a directory in ``tests/integration/targets/``. - -.. seealso:: - - :ref:`developing_testing` - More resources on testing Ansible - :ref:`contributing_maintained_collections` - Guidelines for contributing to selected collections - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_core.rst b/docs/docsite/rst/dev_guide/developing_core.rst deleted file mode 100644 index ce8b95ece4a..00000000000 --- a/docs/docsite/rst/dev_guide/developing_core.rst +++ /dev/null @@ -1,22 +0,0 @@ -*************************** -Developing ``ansible-core`` -*************************** - -Although ``ansible-core`` (the code hosted in the `ansible/ansible repository `_ on GitHub) includes a few plugins that can be swapped out by the playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-core`` work together. - -.. toctree:: - :maxdepth: 1 - - core_branches_and_tags - developing_program_flow_modules - -.. seealso:: - - :ref:`developing_api` - Learn about the Python API for task execution - :ref:`developing_plugins` - Learn about developing plugins - `Mailing List `_ - The development mailing list - `irc.libera.chat `_ - #ansible-devel IRC chat channel diff --git a/docs/docsite/rst/dev_guide/developing_inventory.rst b/docs/docsite/rst/dev_guide/developing_inventory.rst deleted file mode 100644 index 8697e943c30..00000000000 --- a/docs/docsite/rst/dev_guide/developing_inventory.rst +++ /dev/null @@ -1,514 +0,0 @@ -.. _developing_inventory: - -**************************** -Developing dynamic inventory -**************************** - -Ansible can pull inventory information from dynamic sources, including cloud sources, by using the supplied :ref:`inventory plugins `. For details about how to pull inventory information, see :ref:`dynamic_inventory`. If the source you want is not currently covered by existing plugins, you can create your own inventory plugin as with any other plugin type. - -In previous versions, you had to create a script or program that could output JSON in the correct format when invoked with the proper arguments. -You can still use and write inventory scripts, as we ensured backwards compatibility through the :ref:`script inventory plugin ` -and there is no restriction on the programming language used. -If you choose to write a script, however, you will need to implement some features yourself such as caching, configuration management, dynamic variable and group composition, and so on. -If you use :ref:`inventory plugins ` instead, you can use the Ansible codebase and add these common features automatically. - -.. contents:: Topics - :local: - - -.. _inventory_sources: - -Inventory sources -================= - -Inventory sources are the input strings that inventory plugins work with. -An inventory source can be a path to a file or to a script, or it can be raw data that the plugin can interpret. - -The table below shows some examples of inventory plugins and the source types that you can pass to them with ``-i`` on the command line. - -+--------------------------------------------+-----------------------------------------+ -| Plugin | Source | -+--------------------------------------------+-----------------------------------------+ -| :ref:`host list ` | A comma-separated list of hosts | -+--------------------------------------------+-----------------------------------------+ -| :ref:`yaml ` | Path to a YAML format data file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`constructed ` | Path to a YAML configuration file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`ini ` | Path to an INI formatted data file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`virtualbox ` | Path to a YAML configuration file | -+--------------------------------------------+-----------------------------------------+ -| :ref:`script plugin ` | Path to an executable that outputs JSON | -+--------------------------------------------+-----------------------------------------+ - - -.. _developing_inventory_inventory_plugins: - -Inventory plugins -================= - -Like most plugin types (except modules), inventory plugins must be developed in Python. They execute on the controller and should therefore adhere to the :ref:`control_node_requirements`. - -Most of the documentation in :ref:`developing_plugins` also applies here. You should read that document first for a general understanding and then come back to this document for specifics on inventory plugins. - -Normally, inventory plugins are executed at the start of a run, and before the playbooks, plays, or roles are loaded. -However, you can use the ``meta: refresh_inventory`` task to clear the current inventory and execute the inventory plugins again, and this task will generate a new inventory. - -If you use the persistent cache, inventory plugins can also use the configured cache plugin to store and retrieve data. Caching inventory avoids making repeated and costly external calls. - -.. _developing_an_inventory_plugin: - -Developing an inventory plugin ------------------------------- - -The first thing you want to do is use the base class: - -.. code-block:: python - - from ansible.plugins.inventory import BaseInventoryPlugin - - class InventoryModule(BaseInventoryPlugin): - - NAME = 'myplugin' # used internally by Ansible, it should match the file name but not required - -If the inventory plugin is in a collection, the NAME should be in the 'namespace.collection_name.myplugin' format. The base class has a couple of methods that each plugin should implement and a few helpers for parsing the inventory source and updating the inventory. - -After you have the basic plugin working, you can incorporate other features by adding more base classes: - -.. code-block:: python - - from ansible.plugins.inventory import BaseInventoryPlugin, Constructable, Cacheable - - class InventoryModule(BaseInventoryPlugin, Constructable, Cacheable): - - NAME = 'myplugin' - -For the bulk of the work in a plugin, we mostly want to deal with 2 methods ``verify_file`` and ``parse``. - -.. _inventory_plugin_verify_file: - -verify_file method -^^^^^^^^^^^^^^^^^^ - -Ansible uses this method to quickly determine if the inventory source is usable by the plugin. The determination does not need to be 100% accurate, as there might be an overlap in what plugins can handle and by default Ansible will try the enabled plugins as per their sequence. - -.. code-block:: python - - def verify_file(self, path): - ''' return true/false if this is possibly a valid file for this plugin to consume ''' - valid = False - if super(InventoryModule, self).verify_file(path): - # base class verifies that file exists and is readable by current user - if path.endswith(('virtualbox.yaml', 'virtualbox.yml', 'vbox.yaml', 'vbox.yml')): - valid = True - return valid - -In the above example, from the :ref:`virtualbox inventory plugin `, we screen for specific file name patterns to avoid attempting to consume any valid YAML file. You can add any type of condition here, but the most common one is 'extension matching'. If you implement extension matching for YAML configuration files, the path suffix . should be accepted. All valid extensions should be documented in the plugin description. - -The following is another example that does not use a 'file' but the inventory source string itself, -from the :ref:`host list ` plugin: - -.. code-block:: python - - def verify_file(self, path): - ''' don't call base class as we don't expect a path, but a host list ''' - host_list = path - valid = False - b_path = to_bytes(host_list, errors='surrogate_or_strict') - if not os.path.exists(b_path) and ',' in host_list: - # the path does NOT exist and there is a comma to indicate this is a 'host list' - valid = True - return valid - -This method is just to expedite the inventory process and avoid unnecessary parsing of sources that are easy to filter out before causing a parse error. - -.. _inventory_plugin_parse: - -parse method -^^^^^^^^^^^^ - -This method does the bulk of the work in the plugin. -It takes the following parameters: - - * inventory: inventory object with existing data and the methods to add hosts/groups/variables to inventory - * loader: Ansible's DataLoader. The DataLoader can read files, auto load JSON/YAML and decrypt vaulted data, and cache read files. - * path: string with inventory source (this is usually a path, but is not required) - * cache: indicates whether the plugin should use or avoid caches (cache plugin and/or loader) - - -The base class does some minimal assignment for reuse in other methods. - -.. code-block:: python - - def parse(self, inventory, loader, path, cache=True): - - self.loader = loader - self.inventory = inventory - self.templar = Templar(loader=loader) - -It is up to the plugin now to parse the provided inventory source and translate it into Ansible inventory. -To facilitate this, the example below uses a few helper functions: - -.. code-block:: python - - NAME = 'myplugin' - - def parse(self, inventory, loader, path, cache=True): - - # call base method to ensure properties are available for use with other helper methods - super(InventoryModule, self).parse(inventory, loader, path, cache) - - # this method will parse 'common format' inventory sources and - # update any options declared in DOCUMENTATION as needed - config = self._read_config_data(path) - - # if NOT using _read_config_data you should call set_options directly, - # to process any defined configuration for this plugin, - # if you don't define any options you can skip - #self.set_options() - - # example consuming options from inventory source - mysession = apilib.session(user=self.get_option('api_user'), - password=self.get_option('api_pass'), - server=self.get_option('api_server') - ) - - - # make requests to get data to feed into inventory - mydata = mysession.getitall() - - #parse data and create inventory objects: - for colo in mydata: - for server in mydata[colo]['servers']: - self.inventory.add_host(server['name']) - self.inventory.set_variable(server['name'], 'ansible_host', server['external_ip']) - -The specifics will vary depending on API and structure returned. Remember that if you get an inventory source error or any other issue, you should ``raise AnsibleParserError`` to let Ansible know that the source was invalid or the process failed. - -For examples on how to implement an inventory plugin, see the source code here: -`lib/ansible/plugins/inventory `_. - -.. _inventory_object: - -inventory object -^^^^^^^^^^^^^^^^ - -The ``inventory`` object passed to ``parse`` has helpful methods for populating inventory. - -``add_group`` adds a group to inventory if it doesn't already exist. It takes the group name as the only positional argument. - -``add_child`` adds a group or host that exists in inventory to a parent group in inventory. It takes two positional arguments, the name of the parent group and the name of the child group or host. - -``add_host`` adds a host to inventory if it doesn't already exist, optionally to a specific group. It takes the host name as the first argument and accepts two optional keyword arguments, ``group`` and ``port``. ``group`` is the name of a group in inventory, and ``port`` is an integer. - -``set_variable`` adds a variable to a group or host in inventory. It takes three positional arguments: the name of the group or host, the name of the variable, and the value of the variable. - -To create groups and variables using Jinja2 expressions, see the section on implementing ``constructed`` features below. - -To see other inventory object methods, see the source code here: -`lib/ansible/inventory/data.py `_. - -.. _inventory_plugin_caching: - -inventory cache -^^^^^^^^^^^^^^^ - -To cache the inventory, extend the inventory plugin documentation with the inventory_cache documentation fragment and use the Cacheable base class. - -.. code-block:: yaml - - extends_documentation_fragment: - - inventory_cache - -.. code-block:: python - - class InventoryModule(BaseInventoryPlugin, Constructable, Cacheable): - - NAME = 'myplugin' - -Next, load the cache plugin specified by the user to read from and update the cache. If your inventory plugin uses YAML-based configuration files and the ``_read_config_data`` method, the cache plugin is loaded within that method. If your inventory plugin does not use ``_read_config_data``, you must load the cache explicitly with ``load_cache_plugin``. - -.. code-block:: python - - NAME = 'myplugin' - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self.load_cache_plugin() - -Before using the cache plugin, you must retrieve a unique cache key by using the ``get_cache_key`` method. This task needs to be done by all inventory modules using the cache, so that you don't use/overwrite other parts of the cache. - -.. code-block:: python - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self.load_cache_plugin() - cache_key = self.get_cache_key(path) - -Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as by the ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching. - -.. code-block:: python - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self.load_cache_plugin() - cache_key = self.get_cache_key(path) - - # cache may be True or False at this point to indicate if the inventory is being refreshed - # get the user's cache option too to see if we should save the cache if it is changing - user_cache_setting = self.get_option('cache') - - # read if the user has caching enabled and the cache isn't being refreshed - attempt_to_read_cache = user_cache_setting and cache - # update if the user has caching enabled and the cache is being refreshed; update this value to True if the cache has expired below - cache_needs_update = user_cache_setting and not cache - - # attempt to read the cache if inventory isn't being refreshed and the user has caching enabled - if attempt_to_read_cache: - try: - results = self._cache[cache_key] - except KeyError: - # This occurs if the cache_key is not in the cache or if the cache_key expired, so the cache needs to be updated - cache_needs_update = True - if not attempt_to_read_cache or cache_needs_update: - # parse the provided inventory source - results = self.get_inventory() - if cache_needs_update: - self._cache[cache_key] = results - - # submit the parsed data to the inventory object (add_host, set_variable, etc) - self.populate(results) - -After the ``parse`` method is complete, the contents of ``self._cache`` is used to set the cache plugin if the contents of the cache have changed. - -You have three other cache methods available: - - ``set_cache_plugin`` forces the cache plugin to be set with the contents of ``self._cache``, before the ``parse`` method completes - - ``update_cache_if_changed`` sets the cache plugin only if ``self._cache`` has been modified, before the ``parse`` method completes - - ``clear_cache`` flushes the cache, ultimately by calling the cache plugin's ``flush()`` method, whose implementation is dependent upon the particular cache plugin in use. Note that if the user is using the same cache backend for facts and inventory, both will get flushed. To avoid this, the user can specify a distinct cache backend in their inventory plugin configuration. - -constructed features -^^^^^^^^^^^^^^^^^^^^ - -Inventory plugins can create host variables and groups from Jinja2 expressions and variables by using features from the ``constructed`` inventory plugin. To do this, use the ``Constructable`` base class and extend the inventory plugin's documentation with the ``constructed`` documentation fragment. - -.. code-block:: yaml - - extends_documentation_fragment: - - constructed - -.. code-block:: python - - class InventoryModule(BaseInventoryPlugin, Constructable): - - NAME = 'ns.coll.myplugin' - -There are three main options in the ``constructed`` documentation fragment: - -``compose`` creates variables using Jinja2 expressions. This is implemented by calling the ``_set_composite_vars`` method. -``keyed_groups`` creates groups of hosts based on variable values. This is implemented by calling the ``_add_host_to_keyed_groups`` method. -``groups`` creates groups based on Jinja2 conditionals. This is implemented by calling the ``_add_host_to_composed_groups`` method. - -Each method should be called for every host added to inventory. Three positional arguments are required: the constructed option, a dictionary of variables, and a host name. Calling the method ``_set_composite_vars`` first will allow ``keyed_groups`` and ``groups`` to use the composed variables. - -By default, undefined variables are ignored. This is permitted by default for ``compose`` so you can make the variable definitions depend on variables that will be populated later in a play from other sources. For groups, it allows using variables that are not always present without having to use the ``default`` filter. To support configuring undefined variables to be an error, pass the constructed option ``strict`` to each of the methods as a keyword argument. - -``keyed_groups`` and ``groups`` use any variables already associated with the host (for example, from an earlier inventory source). ``_add_host_to_keyed_groups`` and ``add_host_to_composed_groups`` can turn this off by passing the keyword argument ``fetch_hostvars``. - -Here is an example using all three methods: - -.. code-block:: python - - def add_host(self, hostname, host_vars): - self.inventory.add_host(hostname, group='all') - - for var_name, var_value in host_vars.items(): - self.inventory.set_variable(hostname, var_name, var_value) - - strict = self.get_option('strict') - - # Add variables created by the user's Jinja2 expressions to the host - self._set_composite_vars(self.get_option('compose'), host_vars, hostname, strict=True) - - # Create user-defined groups using variables and Jinja2 conditionals - self._add_host_to_composed_groups(self.get_option('groups'), host_vars, hostname, strict=strict) - self._add_host_to_keyed_groups(self.get_option('keyed_groups'), host_vars, hostname, strict=strict) - -By default, group names created with ``_add_host_to_composed_groups()`` and ``_add_host_to_keyed_groups()`` are valid Python identifiers. Invalid characters are replaced with an underscore ``_``. A plugin can change the sanitization used for the constructed features by setting ``self._sanitize_group_name`` to a new function. The core engine also does sanitization, so if the custom function is less strict it should be used in conjunction with the configuration setting ``TRANSFORM_INVALID_GROUP_CHARS``. - -.. code-block:: python - - from ansible.inventory.group import to_safe_group_name - - class InventoryModule(BaseInventoryPlugin, Constructable): - - NAME = 'ns.coll.myplugin' - - @staticmethod - def custom_sanitizer(name): - return to_safe_group_name(name, replacer='') - - def parse(self, inventory, loader, path, cache=True): - super(InventoryModule, self).parse(inventory, loader, path) - - self._sanitize_group_name = custom_sanitizer - -.. _inventory_source_common_format: - -Common format for inventory sources ------------------------------------ - -To simplify development, most plugins use a standard YAML-based configuration file as the inventory source. The file has only one required field ``plugin``, which should contain the name of the plugin that is expected to consume the file. -Depending on other common features used, you might need other fields, and you can add custom options in each plugin as required. -For example, if you use the integrated caching, ``cache_plugin``, ``cache_timeout`` and other cache-related fields could be present. - -.. _inventory_development_auto: - -The 'auto' plugin ------------------ - -From Ansible 2.5 onwards, we include the :ref:`auto inventory plugin ` and enable it by default. If the ``plugin`` field in your standard configuration file matches the name of your inventory plugin, the ``auto`` inventory plugin will load your plugin. The 'auto' plugin makes it easier to use your plugin without having to update configurations. - - -.. _inventory_scripts: -.. _developing_inventory_scripts: - -Inventory scripts -================= - -Even though we now have inventory plugins, we still support inventory scripts, not only for backwards compatibility but also to allow users to use other programming languages. - - -.. _inventory_script_conventions: - -Inventory script conventions ----------------------------- - -Inventory scripts must accept the ``--list`` and ``--host `` arguments. Although other arguments are allowed, Ansible will not use them. -Such arguments might still be useful for executing the scripts directly. - -When the script is called with the single argument ``--list``, the script must output to stdout a JSON object that contains all the groups to be managed. Each group's value should be either an object containing a list of each host, any child groups, and potential group variables, or simply a list of hosts: - - -.. code-block:: json - - { - "group001": { - "hosts": ["host001", "host002"], - "vars": { - "var1": true - }, - "children": ["group002"] - }, - "group002": { - "hosts": ["host003","host004"], - "vars": { - "var2": 500 - }, - "children":[] - } - - } - -If any of the elements of a group are empty, they may be omitted from the output. - -When called with the argument ``--host `` (where is a host from above), the script must print a JSON object, either empty or containing variables to make them available to templates and playbooks. For example: - -.. code-block:: json - - { - "VAR001": "VALUE", - "VAR002": "VALUE" - } - -Printing variables is optional. If the script does not print variables, it should print an empty JSON object. - -.. _inventory_script_tuning: - -Tuning the external inventory script ------------------------------------- - -.. versionadded:: 1.3 - -The stock inventory script system mentioned above works for all versions of Ansible, but calling ``--host`` for every host can be rather inefficient, especially if it involves API calls to a remote subsystem. - -To avoid this inefficiency, if the inventory script returns a top-level element called "_meta", it is possible to return all the host variables in a single script execution. When this meta element contains a value for "hostvars", the inventory script will not be invoked with ``--host`` for each host. This behavior results in a significant performance increase for large numbers of hosts. - -The data to be added to the top-level JSON object looks like this: - -.. code-block:: text - - { - - # results of inventory script as above go here - # ... - - "_meta": { - "hostvars": { - "host001": { - "var001" : "value" - }, - "host002": { - "var002": "value" - } - } - } - } - -To satisfy the requirements of using ``_meta``, to prevent ansible from calling your inventory with ``--host`` you must at least populate ``_meta`` with an empty ``hostvars`` object. -For example: - -.. code-block:: text - - { - - # results of inventory script as above go here - # ... - - "_meta": { - "hostvars": {} - } - } - - -.. _replacing_inventory_ini_with_dynamic_provider: - -If you intend to replace an existing static inventory file with an inventory script, it must return a JSON object which contains an 'all' group that includes every host in the inventory as a member and every group in the inventory as a child. It should also include an 'ungrouped' group which contains all hosts which are not members of any other group. -A skeleton example of this JSON object is: - -.. code-block:: json - - { - "_meta": { - "hostvars": {} - }, - "all": { - "children": [ - "ungrouped" - ] - }, - "ungrouped": { - "children": [ - ] - } - } - -An easy way to see how this should look is using :ref:`ansible-inventory`, which also supports ``--list`` and ``--host`` parameters like an inventory script would. - -.. seealso:: - - :ref:`developing_api` - Python API to Playbooks and Ad Hoc Task Execution - :ref:`developing_modules_general` - Get started with developing a module - :ref:`developing_plugins` - How to develop plugins - `AWX `_ - REST API endpoint and GUI for Ansible, syncs with dynamic inventory - `Development Mailing List `_ - Mailing list for development topics - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_locally.rst b/docs/docsite/rst/dev_guide/developing_locally.rst deleted file mode 100644 index 2eefbc95280..00000000000 --- a/docs/docsite/rst/dev_guide/developing_locally.rst +++ /dev/null @@ -1,145 +0,0 @@ -.. _using_local_modules_and_plugins: -.. _developing_locally: - -********************************** -Adding modules and plugins locally -********************************** - -You can extend Ansible by adding custom modules or plugins. You can create them from scratch or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share plugins and modules by including them in a collection, then publishing the collection on Ansible Galaxy. - -If you are using a local module or plugin but Ansible cannot find it, this page is all you need. - -If you want to create a plugin or a module, see :ref:`developing_plugins`, :ref:`developing_modules_general` and :ref:`developing_collections`. - -Extending Ansible with local modules and plugins offers shortcuts such as: - -* You can copy other people's modules and plugins. -* When writing a new module, you can choose any programming language you like. -* You do not have to clone any repositories. -* You do not have to open a pull request. -* You do not have to add tests (though we recommend that you do!). - -.. contents:: - :local: - -.. _modules_vs_plugins: - -Modules and plugins: what is the difference? -============================================ -If you are looking to add functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you understand what you need: - -* :ref:`Plugins ` extend Ansible's core functionality. Most plugin types execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible: transforming data, logging output, connecting to inventory, and more. -* Modules are a type of plugin that execute automation tasks on a 'target' (usually a remote system). Modules work as standalone scripts that Ansible executes in their own process outside of the controller. Modules interface with Ansible mostly via JSON, accepting arguments and returning information by printing a JSON string to stdout before exiting. Unlike the other plugins (which must be written in Python), modules can be written in any language; although Ansible provides modules in Python and Powershell only. - -.. _use_collections: - -Adding modules and plugins in collections -========================================= - -You can add modules and plugins by :ref:`creating a collection `. With a collection, you can use custom modules and plugins in any playbook or role. You can share your collection easily at any time through Ansible Galaxy. - -The rest of this page describes other methods of using local, standalone modules or plugins. - -.. _local_modules: - -Adding a module or plugin outside of a collection -================================================== - -You can configure Ansible to load standalone local modules or plugins in specific locations and make them available to all playbooks and roles (using configured paths). Alternatively, you can make a non-collection local module or plugin available only to certain playbooks or roles (via adjacent paths). - -Adding standalone local modules for all playbooks and roles ------------------------------------------------------------ - -To load standalone local modules automatically and make them available to all playbooks and roles, use the :ref:`DEFAULT_MODULE_PATH` configuration setting or the ``ANSIBLE_LIBRARY`` environment variable. The configuration setting and environment variable take a colon-separated list, similar to ``$PATH``. You have two options: - -* Add your standalone local module to one of the default configured locations. See the :ref:`DEFAULT_MODULE_PATH` configuration setting for details. Default locations may change without notice. -* Add the location of your standalone local module to an environment variable or configuration: - * the ``ANSIBLE_LIBRARY`` environment variable - * the :ref:`DEFAULT_MODULE_PATH` configuration setting - -To view your current configuration settings for modules: - -.. code-block:: text - - ansible-config dump |grep DEFAULT_MODULE_PATH - -After you save your module file in one of these locations, Ansible loads it and you can use it in any local task, playbook, or role. - -To confirm that ``my_local_module`` is available: - -* type ``ansible localhost -m my_local_module`` to see the output for that module, or -* type ``ansible-doc -t module my_local_module`` to see the documentation for that module - -.. note:: This applies to all plugin types but requires specific configuration and/or adjacent directories for each plugin type, see below. -.. note:: - - The ``ansible-doc`` command can parse module documentation from modules written in Python or an adjacent YAML file. If you have a module written in a programming language other than Python, you should write the documentation in a Python or YAML file adjacent to the module file. :ref:`adjacent_yaml_doc` - -Adding standalone local modules for selected playbooks or a single role ------------------------------------------------------------------------ - -Ansible automatically loads all executable files from certain directories adjacent to your playbook or role as modules. Standalone modules in these locations are available only to the specific playbook, playbooks, or role in the parent directory. - -* To use a standalone module only in a selected playbook or playbooks, store the module in a subdirectory called ``library`` in the directory that contains the playbook or playbooks. -* To use a standalone module only in a single role, store the module in a subdirectory called ``library`` within that role. - -.. note:: This applies to all plugin types but requires specific configuration and/or adjacent directories for each plugin type, see below. - -.. warning:: - - Roles contained in collections cannot contain any modules or other plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new modules, we recommend distributing them in :ref:`collections `, not in roles. - -.. _distributing_plugins: -.. _local_plugins: - -Adding a non-module plugin locally outside of a collection -========================================================== - -You can configure Ansible to load standalone local plugins in a specified location or locations and make them available to all playbooks and roles. Alternatively, you can make a standalone local plugin available only to specific playbooks or roles. - -.. note:: - - Although modules are plugins, the naming patterns for directory names and environment variables that apply to other plugin types do not apply to modules. See :ref:`local_modules`. - -Adding local non-module plugins for all playbooks and roles ------------------------------------------------------------ - -To load standalone local plugins automatically and make them available to all playbooks and roles, use the configuration setting or environment variable for the type of plugin you are adding. These configuration settings and environment variables take a colon-separated list, similar to ``$PATH``. You have two options: - -* Add your local plugin to one of the default configured locations. See :ref:`configuration settings ` for details on the correct configuration setting for the plugin type. Default locations may change without notice. -* Add the location of your local plugin to an environment variable or configuration: - * the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable - for example, ``$ANSIBLE_INVENTORY_PLUGINS`` or ``$ANSIBLE_VARS_PLUGINS`` - * the relevant ``plugin_type_PATH`` configuration setting, most of which begin with ``DEFAULT_`` - for example, ``DEFAULT_CALLBACK_PLUGIN_PATH`` or ``DEFAULT_FILTER_PLUGIN_PATH`` or ``BECOME_PLUGIN_PATH`` - -To view your current configuration settings for non-module plugins: - -.. code-block:: text - - ansible-config dump |grep plugin_type_PATH - -After your plugin file is added to one of these locations, Ansible loads it and you can use it in any local module, task, playbook, or role. For more information on environment variables and configuration settings, see :ref:`ansible_configuration_settings`. - -To confirm that ``plugins/plugin_type/my_local_plugin`` is available: - -* type ``ansible-doc -t my_local_lookup_plugin`` to see the documentation for that plugin - for example, ``ansible-doc -t lookup my_local_lookup_plugin`` - -The ``ansible-doc`` command works for most plugin types, but not for action, filter, or test plugins. See :ref:`ansible-doc` for more details. - -Adding standalone local plugins for selected playbooks or a single role ------------------------------------------------------------------------ - -Ansible automatically loads all plugins from certain directories adjacent to your playbook or role, loading each type of plugin separately from a directory named for the type of plugin. Standalone plugins in these locations are available only to the specific playbook, playbooks, or role in the parent directory. - -* To use a standalone plugin only in a selected playbook or playbooks, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`. -* To use a standalone plugin only in a single role, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`. - -.. warning:: - - Roles contained in collections cannot contain any plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new plugins, we recommend distributing them in :ref:`collections `, not in roles. - -.. _ansible.legacy.custom: - -Using ``ansible.legacy`` to access custom versions of an ``ansible.builtin`` module -=================================================================================== - -If you need to override one of the ``ansible.builtin`` modules and are using FQCN, you need to use ``ansible.legacy`` as part of the fully-qualified collection name (FQCN). For example, if you had your own ``copy`` module, you would access it as ``ansible.legacy.copy``. See :ref:`using_ansible_legacy` for details on how to use custom modules with roles within a collection. diff --git a/docs/docsite/rst/dev_guide/developing_module_utilities.rst b/docs/docsite/rst/dev_guide/developing_module_utilities.rst deleted file mode 100644 index 85ac7aab51e..00000000000 --- a/docs/docsite/rst/dev_guide/developing_module_utilities.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _developing_module_utilities: - -************************************* -Using and developing module utilities -************************************* - -Ansible provides a number of module utilities, or snippets of shared code, that -provide helper functions you can use when developing your own modules. The -``basic.py`` module utility provides the main entry point for accessing the -Ansible library, and all Python Ansible modules must import something from -``ansible.module_utils``. A common option is to import ``AnsibleModule``: - -.. code-block:: python - - from ansible.module_utils.basic import AnsibleModule - -The ``ansible.module_utils`` namespace is not a plain Python package: it is -constructed dynamically for each task invocation, by extracting imports and -resolving those matching the namespace against a :ref:`search path ` derived from the -active configuration. - -To reduce the maintenance burden in a collection or in local modules, you can extract -duplicated code into one or more module utilities and import them into your modules. For example, if you have your own custom modules that import a ``my_shared_code`` library, you can place that into a ``./module_utils/my_shared_code.py`` file like this: - -.. code-block:: python - - from ansible.module_utils.my_shared_code import MySharedCodeClient - -When you run ``ansible-playbook``, Ansible will merge any files in your local ``module_utils`` directories into the ``ansible.module_utils`` namespace in the order defined by the :ref:`Ansible search path `. - -Naming and finding module utilities -=================================== - -You can generally tell what a module utility does from its name and/or its location. Generic utilities (shared code used by many different kinds of modules) live in the main ansible/ansible codebase, in the ``common`` subdirectory or in the root directory of ``lib/ansible/module_utils``. Utilities used by a particular set of modules generally live in the same collection as those modules. For example: - -* ``lib/ansible/module_utils/urls.py`` contains shared code for parsing URLs -* ``openstack.cloud.plugins.module_utils.openstack.py`` contains utilities for modules that work with OpenStack instances -* ``ansible.netcommon.plugins.module_utils.network.common.config.py`` contains utility functions for use by networking modules - -Following this pattern with your own module utilities makes everything easy to find and use. - -.. _standard_mod_utils: - -Standard module utilities -========================= - -Ansible ships with an extensive library of ``module_utils`` files. You can find the module utility source code in the ``lib/ansible/module_utils`` directory under your main Ansible path. We describe the most widely used utilities below. For more details on any specific module utility, please see the `source code for module_utils `_. - -.. include:: shared_snippets/licensing.txt - -- ``api.py`` - Supports generic API modules -- ``basic.py`` - General definitions and helper utilities for Ansible modules -- ``common/dict_transformations.py`` - Helper functions for dictionary transformations -- ``common/file.py`` - Helper functions for working with files -- ``common/text/`` - Helper functions for converting and formatting text -- ``common/parameters.py`` - Helper functions for dealing with module parameters -- ``common/sys_info.py`` - Functions for getting distribution and platform information -- ``common/validation.py`` - Helper functions for validating module parameters against a module argument spec -- ``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 `_ for more information -- ``json_utils.py`` - Utilities for filtering unrelated output around module JSON output, like leading and trailing lines -- ``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules -- ``pycompat24.py`` - Exception workaround for Python 2.4 -- ``service.py`` - Utilities to enable modules to work with Linux services (placeholder, not in use) -- ``six/__init__.py`` - Bundled copy of the `Six Python library `_ to aid in writing code compatible with both Python 2 and Python 3 -- ``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates -- ``urls.py`` - Utilities for working with http and https requests - -Several commonly-used utilities migrated to collections in Ansible 2.10, including: - -- ``ismount.py`` migrated to ``ansible.posix.plugins.module_utils.mount.py`` - Single helper function that fixes os.path.ismount -- ``known_hosts.py`` migrated to ``community.general.plugins.module_utils.known_hosts.py`` - utilities for working with known_hosts file - -For a list of migrated content with destination collections, see the `runtime.yml file `_. diff --git a/docs/docsite/rst/dev_guide/developing_modules.rst b/docs/docsite/rst/dev_guide/developing_modules.rst deleted file mode 100644 index c78b8ed2386..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _developing_modules: -.. _module_dev_should_you: - -**************************** -Should you develop a module? -**************************** - -Developing Ansible modules is easy, but often it is not necessary. Before you start writing a new module, ask: - -1. Does a similar module already exist? - -An existing module may cover the functionality you want. Ansible collections include thousands of modules. Search our :ref:`list of included collections ` or `Ansible Galaxy `_ to see if an existing module does what you need. - -2. Should you use or develop an action plugin instead of a module? - -An action plugin may be the best way to get the functionality you want. Action plugins run on the control node instead of on the managed node, and their functionality is available to all modules. For more information about developing plugins, read the :ref:`developing plugins page `. - -3. Should you use a role instead of a module? - -A combination of existing modules may cover the functionality you want. You can write a role for this type of use case. Check out the :ref:`roles documentation`. - -4. Should you create a collection instead of a single module? - -The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a new collection`. - -* Each module should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well. - -* A module should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected. - -* Modules should typically encompass much of the logic for interacting with a resource. A lightweight wrapper around an API that does not contain much logic would likely cause users to offload too much logic into a playbook, and for this reason the module would be rejected. Instead try creating multiple modules for interacting with smaller individual pieces of the API. - -If your use case isn't covered by an existing module, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps: - -* I want to :ref:`get started on a new module `. -* I want to review :ref:`tips and conventions for developing good modules `. -* I want to :ref:`write a Windows module `. -* I want :ref:`an overview of Ansible's architecture `. -* I want to :ref:`document my module `. -* I want to :ref:`contribute my module to an existing Ansible collection `. -* I want to :ref:`add unit and integration tests to my module `. -* I want to :ref:`add Python 3 support to my module `. -* I want to :ref:`write multiple modules `. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - `Mailing List `_ - Development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst b/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst deleted file mode 100644 index e9cfb6e845d..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst +++ /dev/null @@ -1,175 +0,0 @@ -.. _developing_modules_best_practices: -.. _module_dev_conventions: - -******************************* -Conventions, tips, and pitfalls -******************************* - -.. contents:: Topics - :local: - -As you design and develop modules, follow these basic conventions and tips for clean, usable code: - -Scoping your module(s) -====================== - -Especially if you want to contribute your module(s) to an existing Ansible Collection, make sure each module includes enough logic and functionality, but not too much. If these guidelines seem confusing, consider :ref:`whether you really need to write a module ` at all. - -* Each module should have a concise and well-defined functionality. Basically, follow the UNIX philosophy of doing one thing well. -* Do not add ``get``, ``list`` or ``info`` state options to an existing module - create a new ``_info`` or ``_facts`` module. -* Modules should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module option cannot be documented, the module does not belong in Ansible Core. -* Modules should encompass much of the logic for interacting with a resource. A lightweight wrapper around a complex API forces users to offload too much logic into their playbooks. If you want to connect Ansible to a complex API, :ref:`create multiple modules ` that interact with smaller individual pieces of the API. -* Avoid creating a module that does the work of other modules; this leads to code duplication and divergence, and makes things less uniform, unpredictable and harder to maintain. Modules should be the building blocks. If you are asking 'how can I have a module execute other modules' ... you want to write a role. - -Designing module interfaces -=========================== - -* If your module is addressing an object, the option for that object should be called ``name`` whenever possible, or accept ``name`` as an alias. -* Modules accepting boolean status should accept ``yes``, ``no``, ``true``, ``false``, or anything else a user may likely throw at them. The AnsibleModule common code supports this with ``type='bool'``. -* Avoid ``action``/``command``, they are imperative and not declarative, there are other ways to express the same thing. - -General guidelines & tips -========================= - -* Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-core``. -* Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-core`` from importing your module. -* Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls. -* If you have a local module that returns information specific to your installations, a good name for this module is ``site_info``. -* Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails. -* Don't write to files directly; use a temporary file and then use the ``atomic_move`` function from ``ansible.module_utils.basic`` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept. -* Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server, AWX, or the Red Hat Ansible Automation Platform); do not try to build it into modules. -* If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional. - -Functions and Methods -===================== - -* Each function should be concise and should describe a meaningful amount of work. -* "Don't repeat yourself" is generally a good philosophy. -* Function names should use underscores: ``my_function_name``. -* The name of each function should describe what the function does. -* Each function should have a docstring. -* If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times. - -Python tips -=========== - -* Include a ``main`` function that wraps the normal execution. -* Call your ``main`` function from a conditional so you can import it into unit tests - for example: - -.. code-block:: python - - if __name__ == '__main__': - main() - -.. _shared_code: - -Importing and using shared code -=============================== - -* Use shared code whenever possible - don't reinvent the wheel. Ansible offers the ``AnsibleModule`` common Python code, plus :ref:`utilities ` for many common use cases and patterns. You can also create documentation fragments for docs that apply to multiple modules. -* Import ``ansible.module_utils`` code in the same place as you import other libraries. -* Do NOT use wildcards (*) for importing other python modules; instead, list the function(s) you are importing (for example, ``from some.other_python_module.basic import otherFunction``). -* Import custom packages in ``try``/``except``, capture any import errors, and handle them with ``fail_json()`` in ``main()``. For example: - -.. code-block:: python - - import traceback - - from ansible.module_utils.basic import missing_required_lib - - LIB_IMP_ERR = None - try: - import foo - HAS_LIB = True - except: - HAS_LIB = False - LIB_IMP_ERR = traceback.format_exc() - - -Then in ``main()``, just after the argspec, do - -.. code-block:: python - - if not HAS_LIB: - module.fail_json(msg=missing_required_lib("foo"), - exception=LIB_IMP_ERR) - - -And document the dependency in the ``requirements`` section of your module's :ref:`documentation_block`. - -.. _module_failures: - -Handling module failures -======================== - -When your module fails, help users understand what went wrong. If you are using the ``AnsibleModule`` common Python code, the ``failed`` element will be included for you automatically when you call ``fail_json``. For polite module failure behavior: - -* Include a key of ``failed`` along with a string explanation in ``msg``. If you don't do this, Ansible will use standard return codes: 0=success and non-zero=failure. -* Don't raise a traceback (stacktrace). Ansible can deal with stacktraces and automatically converts anything unparsable into a failed result, but raising a stacktrace on module failure is not user-friendly. -* Do not use ``sys.exit()``. Use ``fail_json()`` from the module object. - -Handling exceptions (bugs) gracefully -===================================== - -* Validate upfront--fail fast and return useful and clear error messages. -* Use defensive programming--use a simple design for your module, handle errors gracefully, and avoid direct stacktraces. -* Fail predictably--if we must fail, do it in a way that is the most expected. Either mimic the underlying tool or the general way the system works. -* Give out a useful message on what you were doing and add exception messages to that. -* Avoid catchall exceptions, they are not very useful unless the underlying API gives very good error messages pertaining the attempted action. - -.. _module_output: - -Creating correct and informative module output -============================================== - -Modules must output valid JSON only. Follow these guidelines for creating correct, useful module output: - -* Make your top-level return type a hash (dictionary). -* Nest complex return values within the top-level hash. -* Incorporate any lists or simple scalar values within the top-level return hash. -* Do not send module output to standard error, because the system will merge standard out with standard error and prevent the JSON from parsing. -* Capture standard error and return it as a variable in the JSON on standard out. This is how the command module is implemented. -* Never do ``print("some status message")`` in a module, because it will not produce valid JSON output. -* Always return useful data, even when there is no change. -* Be consistent about returns (some modules are too random), unless it is detrimental to the state/action. -* Make returns reusable--most of the time you don't want to read it, but you do want to process it and re-purpose it. -* Return diff if in diff mode. This is not required for all modules, as it won't make sense for certain ones, but please include it when applicable. -* Enable your return values to be serialized as JSON with Python's standard `JSON encoder and decoder `_ library. Basic python types (strings, int, dicts, lists, and so on) are serializable. -* Do not return an object using exit_json(). Instead, convert the fields you need from the object into the fields of a dictionary and return the dictionary. -* Results from many hosts will be aggregated at once, so your module should return only relevant output. Returning the entire contents of a log file is generally bad form. - -If a module returns stderr or otherwise fails to produce valid JSON, the actual output will still be shown in Ansible, but the command will not succeed. - -.. _module_conventions: - -Following Ansible conventions -============================= - -Ansible conventions offer a predictable user interface across all modules, playbooks, and roles. To follow Ansible conventions in your module development: - -* Use consistent names across modules (yes, we have many legacy deviations - don't make the problem worse!). -* Use consistent options (arguments) within your module(s). -* Do not use 'message' or 'syslog_facility' as an option name, because this is used internally by Ansible. -* Normalize options with other modules - if Ansible and the API your module connects to use different names for the same option, add aliases to your options so the user can choose which names to use in tasks and playbooks. -* Return facts from ``*_facts`` modules in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them. -* Implement ``check_mode`` in all ``*_info`` and ``*_facts`` modules. Playbooks which conditionalize based on fact information will only conditionalize correctly in ``check_mode`` if the facts are returned in ``check_mode``. Usually you can add ``supports_check_mode=True`` when instantiating ``AnsibleModule``. -* Use module-specific environment variables. For example, if you use the helpers in ``module_utils.api`` for basic authentication with ``module_utils.urls.fetch_url()`` and you fall back on environment variables for default values, use a module-specific environment variable like :code:`API__USERNAME` to avoid conflicts between modules. -* Keep module options simple and focused - if you're loading a lot of choices/states on an existing option, consider adding a new, simple option instead. -* Keep options small when possible. Passing a large data structure to an option might save us a few tasks, but it adds a complex requirement that we cannot easily validate before passing on to the module. -* If you want to pass complex data to an option, write an expert module that allows this, along with several smaller modules that provide a more 'atomic' operation against the underlying APIs and services. Complex operations require complex data. Let the user choose whether to reflect that complexity in tasks and plays or in vars files. -* Implement declarative operations (not CRUD) so the user can ignore existing state and focus on final state. For example, use ``started/stopped``, ``present/absent``. -* Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it. -* Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options. - - -Module Security -=============== - -* Avoid passing user input from the shell. -* Always check return codes. -* You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``. -* Avoid using the shell unless absolutely necessary. -* If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``. -* If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``. -* When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https. -* Sensitive values marked with ``no_log=True`` will automatically have that value stripped from module return values. If your module could return these sensitive values as part of a dictionary key name, you should call the ``ansible.module_utils.basic.sanitize_keys()`` function to strip the values from the keys. See the ``uri`` module for an example. diff --git a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst deleted file mode 100644 index 292bb9061f3..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst +++ /dev/null @@ -1,45 +0,0 @@ -.. _developing_modules_checklist: -.. _module_contribution: - -********************************************************** -Contributing your module to an existing Ansible collection -********************************************************** - -If you want to contribute a module to an existing collection, you must meet the community's objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development `. - -Modules accepted into certain collections are included in every Ansible release on PyPI. However, contributing to one of these collections is not the only way to distribute a module - you can :ref:`create your own collection `, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use `. - -Contributing modules: objective requirements -=============================================== - -To contribute a module to most Ansible collections, you must: - -* write your module in either Python or Powershell for Windows -* use the ``AnsibleModule`` common code -* support Python 2.6 and Python 3.5 - if your module cannot support Python 2.6, explain the required minimum Python version and rationale in the requirements section in ``DOCUMENTATION`` -* use proper :ref:`Python 3 syntax ` -* follow `PEP 8 `_ Python style conventions - see :ref:`testing_pep8` for more information -* license your module under the GPL license (GPLv3 or later) -* understand the :ref:`license agreement `, which applies to all contributions -* conform to Ansible's :ref:`formatting and documentation ` standards -* include comprehensive :ref:`tests ` for your module -* minimize module dependencies -* support :ref:`check_mode ` if possible -* ensure your code is readable -* if a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed. -* Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine. - -Additional requirements may apply for certain collections. Review the individual collection repositories for more information. - -Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out by using the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) or the `Ansible development mailing list `_. - -Contributing to Ansible: subjective requirements -================================================ - -If your module meets these objective requirements, collection maintainers will review your code to see if they think it's clear, concise, secure, and maintainable. They will consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, with no exact standards for acceptance. For the best chance of getting your module accepted, follow our :ref:`tips for module development `. - -Other checklists -================ - -* :ref:`Tips for module development `. -* :ref:`Windows development checklist `. diff --git a/docs/docsite/rst/dev_guide/developing_modules_documenting.rst b/docs/docsite/rst/dev_guide/developing_modules_documenting.rst deleted file mode 100644 index e7b5c2d5fb6..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_documenting.rst +++ /dev/null @@ -1,459 +0,0 @@ -.. _developing_modules_documenting: -.. _module_documenting: - -******************************* -Module format and documentation -******************************* - -If you want to contribute your module to most Ansible collections, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines ` apply.) In addition to following this format, you should review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request. - -Every Ansible module written in Python must begin with seven standard sections in a particular order, followed by the code. The sections in order are: - -.. contents:: - :depth: 1 - :local: - -.. note:: Why don't the imports go first? - - Keen Python programmers may notice that contrary to PEP 8's advice we don't put ``imports`` at the top of the file. This is because the ``DOCUMENTATION`` through ``RETURN`` sections are not used by the module code itself; they are essentially extra docstrings for the file. The imports are placed after these special variables for the same reason as PEP 8 puts the imports after the introductory comments and docstrings. This keeps the active parts of the code together and the pieces which are purely informational apart. The decision to exclude E402 is based on readability (which is what PEP 8 is about). Documentation strings in a module are much more similar to module level docstrings, than code, and are never utilized by the module itself. Placing the imports below this documentation and closer to the code, consolidates and groups all related code in a congruent manner to improve readability, debugging and understanding. - -.. warning:: **Copy old modules with care!** - - Some older Ansible modules have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we are updating and correcting older modules. Please follow the guidelines on this page! - -.. note:: For non-Python modules you still create a ``.py`` file for documentation purposes. Starting at ansible-core 2.14 you can instead choose to create a ``.yml`` file that has the same data structure, but in pure YAML. - With YAML files, the examples below are easy to use by removing Python quoting and substituting ``=`` for ``:``, for example ``DOCUMENTATION = r''' ... '''` ` to ``DOCUMENTATION: ...`` and removing closing quotes. :ref:`adjacent_yaml_doc` - - -.. _shebang: - -Python shebang & UTF-8 coding -=============================== - -Begin your Ansible module with ``#!/usr/bin/python`` - this "shebang" allows ``ansible_python_interpreter`` to work. Follow the shebang immediately with ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded. - -.. note:: Using ``#!/usr/bin/env``, makes ``env`` the interpreter and bypasses ``ansible__interpreter`` logic. -.. note:: If you develop the module using a different scripting language, adjust the interpreter accordingly (``#!/usr/bin/``) so ``ansible__interpreter`` can work for that specific language. -.. note:: Binary modules do not require a shebang or an interpreter. - -.. _copyright: - -Copyright and license -===================== - -After the shebang and UTF-8 coding, add a `copyright line `_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.: - -.. code-block:: python - - #!/usr/bin/python - # -*- coding: utf-8 -*- - - # Copyright: Contributors to the Ansible project - # GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -Additions to the module (for instance, rewrites) are not permitted to add additional copyright lines other than the default copyright statement if missing: - -.. code-block:: python - - # Copyright: Contributors to the Ansible project - -Any legal review will include the source control history, so an exhaustive copyright header is not necessary. -Please do not include a copyright year. If the existing copyright statement includes a year, do not edit the existing copyright year. Any existing copyright header should not be modified without permission from the copyright author. - -.. _ansible_metadata_block: - -ANSIBLE_METADATA block -====================== - -Since we moved to collections we have deprecated the METADATA functionality, it is no longer required for modules, but it will not break anything if present. - - -.. _documentation_block: - -DOCUMENTATION block -=================== - -After the shebang, the UTF-8 coding, the copyright line, and the license section comes the ``DOCUMENTATION`` block. Ansible's online module documentation is generated from the ``DOCUMENTATION`` blocks in each module's source code. The ``DOCUMENTATION`` block must be valid YAML. You may find it easier to start writing your ``DOCUMENTATION`` string in an :ref:`editor with YAML syntax highlighting ` before you include it in your Python file. You can start by copying our `example documentation string `_ into your module file and modifying it. If you run into syntax issues in your YAML, you can validate it on the `YAML Lint `_ website. - -Module documentation should briefly and accurately define what each module and option does, and how it works with others in the underlying system. Documentation should be written for broad audience--readable both by experts and non-experts. - * Descriptions should always start with a capital letter and end with a full stop. Consistency always helps. - * Verify that arguments in doc and module spec dict are identical. - * For password / secret arguments ``no_log=True`` should be set. - * For arguments that seem to contain sensitive information but **do not** contain secrets, such as "password_length", set ``no_log=False`` to disable the warning message. - * If an option is only sometimes required, describe the conditions. For example, "Required when I(state=present)." - * If your module allows ``check_mode``, reflect this fact in the documentation. - -To create clear, concise, consistent, and useful documentation, follow the :ref:`style guide `. - -Each documentation field is described below. Before committing your module documentation, please test it at the command line and as HTML: - -* As long as your module file is :ref:`available locally `, you can use ``ansible-doc -t module my_module_name`` to view your module documentation at the command line. Any parsing errors will be obvious - you can view details by adding ``-vvv`` to the command. -* You should also :ref:`test the HTML output ` of your module documentation. - - -Documentation fields --------------------- - -All fields in the ``DOCUMENTATION`` block are lower-case. All fields are required unless specified otherwise: - -:module: - - * The name of the module. - * Must be the same as the filename, without the ``.py`` extension. - -:short_description: - - * A short description which is displayed on the :ref:`list_of_collections` page and ``ansible-doc -l``. - * The ``short_description`` is displayed by ``ansible-doc -l`` without any category grouping, - so it needs enough detail to explain the module's purpose without the context of the directory structure in which it lives. - * Unlike ``description:``, ``short_description`` should not have a trailing period/full stop. - -:description: - - * A detailed description (generally two or more sentences). - * Must be written in full sentences, in other words, with capital letters and periods/full stops. - * Shouldn't mention the module name. - * Make use of multiple entries rather than using one long paragraph. - * Don't quote complete values unless it is required by YAML. - -:version_added: - - * The version of Ansible when the module was added. - * This is a string, and not a float, for example, ``version_added: '2.1'``. - * In collections, this must be the collection version the module was added to, not the Ansible version. For example, ``version_added: 1.0.0``. - -:author: - - * Name of the module author in the form ``First Last (@GitHubID)``. - * Use a multi-line list if there is more than one author. - * Don't use quotes as it should not be required by YAML. - -:deprecated: - - * Marks modules that will be removed in future releases. See also :ref:`module_lifecycle`. - -:options: - - * Options are often called `parameters` or `arguments`. Because the documentation field is called `options`, we will use that term. - * If the module has no options (for example, it's a ``_facts`` module), all you need is one line: ``options: {}``. - * If your module has options (in other words, accepts arguments), each option should be documented thoroughly. For each module option, include: - - :option-name: - - * Declarative operation (not CRUD), to focus on the final state, for example `online:`, rather than `is_online:`. - * The name of the option should be consistent with the rest of the module, as well as other modules in the same category. - * When in doubt, look for other modules to find option names that are used for the same purpose, we like to offer consistency to our users. - - :description: - - * Detailed explanation of what this option does. It should be written in full sentences. - * The first entry is a description of the option itself; subsequent entries detail its use, dependencies, or format of possible values. - * Should not list the possible values (that's what ``choices:`` is for, though it should explain what the values do if they aren't obvious). - * If an option is only sometimes required, describe the conditions. For example, "Required when I(state=present)." - * Mutually exclusive options must be documented as the final sentence on each of the options. - - :required: - - * Only needed if ``true``. - * If missing, we assume the option is not required. - - :default: - - * If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing). - * Ensure that the default value in the docs matches the default value in the code. - * The default field must not be listed as part of the description, unless it requires additional information or conditions. - * If the option is a boolean value, you can use any of the boolean values recognized by Ansible - (such as ``true``/``false`` or ``yes``/``no``). Document booleans as ``true``/``false`` for consistency and compatibility with ansible-lint. - - :choices: - - * List of option values. - * Should be absent if empty. - - :type: - - * Specifies the data type that option accepts, must match the ``argspec``. - * If an argument is ``type='bool'``, this field should be set to ``type: bool`` and no ``choices`` should be specified. - * If an argument is ``type='list'``, ``elements`` should be specified. - - :elements: - - * Specifies the data type for list elements in case ``type='list'``. - - :aliases: - * List of optional name aliases. - * Generally not needed. - - :version_added: - - * Only needed if this option was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. - * This is a string, and not a float, for example, ``version_added: '2.3'``. - * In collections, this must be the collection version the option was added to, not the Ansible version. For example, ``version_added: 1.0.0``. - - :suboptions: - - * If this option takes a dict or list of dicts, you can define the structure here. - * See :ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`, :ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`, and :ref:`ansible_collections.openstack.cloud.baremetal_node_action_module` for examples. - -:requirements: - - * List of requirements (if applicable). - * Include minimum versions. - -:seealso: - - * A list of references to other modules, documentation or Internet resources - * In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-core``. - * A reference can be one of the following formats: - - - .. code-block:: yaml+jinja - - seealso: - - # Reference by module name - - module: cisco.aci.aci_tenant - - # Reference by module name, including description - - module: cisco.aci.aci_tenant - description: ACI module to create tenants on a Cisco ACI fabric. - - # Reference by rST documentation anchor - - ref: aci_guide - description: Detailed information on how to manage your ACI infrastructure using Ansible. - - # Reference by rST documentation anchor (with custom title) - - ref: The official Ansible ACI guide - description: Detailed information on how to manage your ACI infrastructure using Ansible. - - # Reference by Internet resource - - name: APIC Management Information Model reference - description: Complete reference of the APIC object model. - link: https://developer.cisco.com/docs/apic-mim-ref/ - - - * If you use ``ref:`` to link to an anchor that is not associated with a title, you must add a title to the ref for the link to work correctly. - * You can link to non-module plugins with ``ref:`` using the rST anchor, but plugin and module anchors are never associated with a title, so you must supply a title when you link to them. For example ``ref: namespace.collection.plugin_name lookup plugin ``. - - -:notes: - - * Details of any important information that doesn't fit in one of the above sections. - * For example, whether ``check_mode`` is or is not supported. - -.. _module_documents_linking: - -Linking and other format macros within module documentation ------------------------------------------------------------ - -You can link from your module documentation to other module docs, other resources on docs.ansible.com, and resources elsewhere on the internet with the help of some pre-defined macros. The correct formats for these macros are: - -* ``L()`` for links with a heading. For example: ``See L(Ansible Automation Platform,https://www.ansible.com/products/automation-platform).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation. -* ``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/automation-platform) for an overview.`` -* ``R()`` for cross-references with a heading (added in Ansible 2.10). For example: ``See R(Cisco IOS Platform Guide,ios_platform_options)``. Use the RST anchor for the cross-reference. See :ref:`adding_anchors_rst` for details. -* ``M()`` for module names. For example: ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)``. - -There are also some macros which do not create links but we use them to display certain types of -content in a uniform way: - -* ``I()`` for option names. For example: ``Required if I(state=present).`` This is italicized in - the documentation. -* ``C()`` for files, option values, and inline code. For example: ``If not set the environment variable C(ACME_PASSWORD) will be used.`` or ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.`` This displays with a mono-space font in the documentation. -* ``B()`` currently has no standardized usage. It is displayed in boldface in the documentation. -* ``HORIZONTALLINE`` is used sparingly as a separator in long descriptions. It becomes a horizontal rule (the ``
    `` html tag) in the documentation. - -.. note:: - - For links between modules and documentation within a collection, you can use any of the options above. For links outside of your collection, use ``R()`` if available. Otherwise, use ``U()`` or ``L()`` with full URLs (not relative links). For modules, use ``M()`` with the FQCN or ``ansible.builtin`` as shown in the example. If you are creating your own documentation site, you will need to use the `intersphinx extension `_ to convert ``R()`` and ``M()`` to the correct links. - -.. note:: - To refer to a group of modules in a collection, use ``R()``. When a collection is not the right granularity, use ``C(..)``: - - - ``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.`` - - ``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.`` - -.. note:: - - Because it stands out better, use ``seealso`` for general references over the use of notes or adding links to the description. - -.. _module_docs_fragments: - -Documentation fragments ------------------------ - -If you are writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ `_ or the equivalent directory in a collection. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module documentation. Use the fully qualified collection name for the FRAGMENT_NAME (for example, ``kubernetes.core.k8s_auth_options``). - -Modules should only use items from a doc fragment if the module will implement all of the interface documented there in a manner that behaves the same as the existing modules which import that fragment. The goal is that items imported from the doc fragment will behave identically when used in another module that imports the doc fragment. - -By default, only the ``DOCUMENTATION`` property from a doc fragment is inserted into the module documentation. It is possible to define additional properties in the doc fragment in order to import only certain parts of a doc fragment or mix and match as appropriate. If a property is defined in both the doc fragment and the module, the module value overrides the doc fragment. - -Here is an example doc fragment named ``example_fragment.py``: - -.. code-block:: python - - class ModuleDocFragment(object): - # Standard documentation - DOCUMENTATION = r''' - options: - # options here - ''' - - # Additional section - OTHER = r''' - options: - # other options here - ''' - - -To insert the contents of ``OTHER`` in a module: - -.. code-block:: yaml+jinja - - extends_documentation_fragment: example_fragment.other - -Or use both : - -.. code-block:: yaml+jinja - - extends_documentation_fragment: - - example_fragment - - example_fragment.other - -.. _note: - * Prior to Ansible 2.8, documentation fragments were kept in ``lib/ansible/utils/module_docs_fragments``. - -.. versionadded:: 2.8 - -Since Ansible 2.8, you can have user-supplied doc_fragments by using a ``doc_fragments`` directory adjacent to play or role, just like any other plugin. - -For example, all AWS modules should include: - -.. code-block:: yaml+jinja - - extends_documentation_fragment: - - aws - - ec2 - -:ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection. - -.. _examples_block: - -EXAMPLES block -============== - -After the shebang, the UTF-8 coding, the copyright line, the license section, and the ``DOCUMENTATION`` block comes the ``EXAMPLES`` block. Here you show users how your module works with real-world examples in multi-line plain-text YAML format. The best examples are ready for the user to copy and paste into a playbook. Review and update your examples with every change to your module. - -Per playbook best practices, each example should include a ``name:`` line: - -.. code-block:: text - - EXAMPLES = r''' - - name: Ensure foo is installed - namespace.collection.modulename: - name: foo - state: present - ''' - -The ``name:`` line should be capitalized and not include a trailing dot. - -Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-core``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``. - -If your examples use boolean options, use yes/no values. Since the documentation generates boolean values as yes/no, having the examples use these values as well makes the module documentation more consistent. - -If your module returns facts that are often needed, an example of how to use them can be helpful. - -.. _return_block: - -RETURN block -============ - -After the shebang, the UTF-8 coding, the copyright line, the license section, ``DOCUMENTATION`` and ``EXAMPLES`` blocks comes the ``RETURN`` block. This section documents the information the module returns for use by other modules. - -If your module doesn't return anything (apart from the standard returns), this section of your module should read: ``RETURN = r''' # '''`` -Otherwise, for each value returned, provide the following fields. All fields are required unless specified otherwise. - -:return name: - Name of the returned field. - - :description: - Detailed description of what this value represents. Capitalized and with trailing dot. - :returned: - When this value is returned, such as ``always``, ``changed`` or ``success``. This is a string and can contain any human-readable content. - :type: - Data type. - :elements: - If ``type='list'``, specifies the data type of the list's elements. - :sample: - One or more examples. - :version_added: - Only needed if this return was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. - This is a string, and not a float, for example, ``version_added: '2.3'``. - :contains: - Optional. To describe nested return values, set ``type: dict``, or ``type: list``/``elements: dict``, or if you really have to, ``type: complex``, and repeat the elements above for each sub-field. - -Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field: - -.. code-block:: text - - RETURN = r''' - dest: - description: Destination file/path. - returned: success - type: str - sample: /path/to/file.txt - src: - description: Source file used for the copy on the target machine. - returned: changed - type: str - sample: /home/httpd/.ansible/tmp/ansible-tmp-1423796390.97-147729857856000/source - md5sum: - description: MD5 checksum of the file after running copy. - returned: when supported - type: str - sample: 2a5aeecc61dc98c4d780b14b330e3282 - ''' - - RETURN = r''' - packages: - description: Information about package requirements. - returned: success - type: dict - contains: - missing: - description: Packages that are missing from the system. - returned: success - type: list - elements: str - sample: - - libmysqlclient-dev - - libxml2-dev - badversion: - description: Packages that are installed but at bad versions. - returned: success - type: list - elements: dict - sample: - - package: libxml2-dev - version: 2.9.4+dfsg1-2 - constraint: ">= 3.0" - ''' - -.. _python_imports: - -Python imports -============== - -After the shebang, the UTF-8 coding, the copyright line, the license, and the sections for ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN``, you can finally add the python imports. All modules must use Python imports in the form: - -.. code-block:: python - - from module_utils.basic import AnsibleModule - -The use of "wildcard" imports such as ``from module_utils.basic import *`` is no longer allowed. - -.. _dev_testing_module_documentation: - -Testing module documentation -============================ - -To test Ansible documentation locally please :ref:`follow instruction`. To test documentation in collections, please see :ref:`build_collection_docsite`. diff --git a/docs/docsite/rst/dev_guide/developing_modules_general.rst b/docs/docsite/rst/dev_guide/developing_modules_general.rst deleted file mode 100644 index abffcf191c8..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_general.rst +++ /dev/null @@ -1,186 +0,0 @@ -.. _developing_modules_general: -.. _module_dev_tutorial_sample: - -****************** -Developing modules -****************** - -A module is a reusable, standalone script that Ansible runs on your behalf, either locally or remotely. Modules interact with your local machine, an API, or a remote system to perform specific tasks like changing a database password or spinning up a cloud instance. Each module can be used by the Ansible API, or by the :command:`ansible` or :command:`ansible-playbook` programs. A module provides a defined interface, accepts arguments, and returns information to Ansible by printing a JSON string to stdout before exiting. - -If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module. When you write a module for local use, you can choose any programming language and follow your own rules. Use this topic to learn how to create an Ansible module in Python. After you create a module, you must add it locally to the appropriate directory so that Ansible can find and execute it. For details about adding a module locally, see :ref:`developing_locally`. - -If you are developing a module in a :ref:`collection `, see those documents instead. - -.. contents:: - :local: - -.. _environment_setup: - -Preparing an environment for developing Ansible modules -======================================================= - -You just need ``ansible-core`` installed to test the module. Modules can be written in any language, -but most of the following guide is assuming you are using Python. -Modules for inclusion in Ansible itself must be Python or Powershell. - -One advantage of using Python or Powershell for your custom modules is being able to use the ``module_utils`` common code that does a lot of the -heavy lifting for argument processing, logging and response writing, among other things. - -Creating a module -================= - -It is highly recommended that you use a ``venv`` or ``virtualenv`` for Python development. - -To create a module: - -1. Create a ``library`` directory in your workspace, your test play should live in the same directory. -2. Create your new module file: ``$ touch library/my_test.py``. Or just open/create it with your editor of choice. -3. Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code. -4. Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code. - -.. literalinclude:: ../../../../examples/scripts/my_test.py - :language: python - -Creating an info or a facts module -================================== - -Ansible gathers information about the target machines using facts modules, and gathers information on other objects or files using info modules. -If you find yourself trying to add ``state: info`` or ``state: list`` to an existing module, that is often a sign that a new dedicated ``_facts`` or ``_info`` module is needed. - -In Ansible 2.8 and onwards, we have two type of information modules, they are ``*_info`` and ``*_facts``. - -If a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. -Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed. - -Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. -General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine, or information on individual files or programs. - -Info and facts modules, are just like any other Ansible Module, with a few minor requirements: - -1. They MUST be named ``_info`` or ``_facts``, where is singular. -2. Info ``*_info`` modules MUST return in the form of the :ref:`result dictionary` so other modules can access them. -3. Fact ``*_facts`` modules MUST return in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them. -4. They MUST support :ref:`check_mode `. -5. They MUST NOT make any changes to the system. -6. They MUST document the :ref:`return fields` and :ref:`examples`. - -The rest is just like creating a normal module. - -Verifying your module code -========================== - -After you modify the sample code above to do what you want, you can try out your module. -Our :ref:`debugging tips ` will help if you run into bugs as you verify your module code. - - -Verifying your module code locally ----------------------------------- - -The simplest way is to use ``ansible`` adhoc command: - -.. code:: shell - - ANSIBLE_LIBRARY=./library ansible -m my_test -a 'name=hello new=true' remotehost - -If your module does not need to target a remote host, you can quickly and easily exercise your code locally like this: - -.. code:: shell - - ANSIBLE_LIBRARY=./library ansible -m my_test -a 'name=hello new=true' localhost - -- If for any reason (pdb, using print(), faster iteration, etc) you want to avoid going through Ansible, - another way is to create an arguments file, a basic JSON config file that passes parameters to your module so that you can run it. - Name the arguments file ``/tmp/args.json`` and add the following content: - -.. code:: json - - { - "ANSIBLE_MODULE_ARGS": { - "name": "hello", - "new": true - } - } - -- Then the module can be tested locally and directly. This skips the packing steps and uses module_utils files directly: - -.. code:: console - - ``$ python library/my_test.py /tmp/args.json`` - -It should return output like this: - -.. code:: json - - {"changed": true, "state": {"original_message": "hello", "new_message": "goodbye"}, "invocation": {"module_args": {"name": "hello", "new": true}}} - - - -Verifying your module code in a playbook ----------------------------------------- - -You can easily run a full test by including it in a playbook, as long as the ``library`` directory is in the same directory as the play: - -- Create a playbook in any directory: ``$ touch testmod.yml`` -- Add the following to the new playbook file: - -.. code-block:: yaml - - - name: test my new module - hosts: localhost - tasks: - - name: run the new module - my_test: - name: 'hello' - new: true - register: testout - - name: dump test output - debug: - msg: '{{ testout }}' - -- Run the playbook and analyze the output: ``$ ansible-playbook ./testmod.yml`` - -Testing your newly-created module -================================= - -The following two examples will get you started with testing your module code. Please review our :ref:`testing ` section for more detailed -information, including instructions for :ref:`testing module documentation `, adding :ref:`integration tests `, and more. - -.. note:: - If contributing to Ansible, every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. - In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_. - -Performing sanity tests ------------------------ - -You can run through Ansible's sanity checks in a container: - -``$ ansible-test sanity -v --docker --python 3.10 MODULE_NAME`` - -.. note:: - Note that this example requires Docker to be installed and running. If you'd rather not use a container for this, you can choose to use ``--venv`` instead of ``--docker``. - - -Contributing back to Ansible -============================ - -If you would like to contribute to ``ansible-core`` by adding a new feature or fixing a bug, `create a fork `_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target. - -If you want to contribute a module to an :ref:`Ansible collection `, review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request. - -The :ref:`Community Guide ` covers how to open a pull request and what happens next. - - -Communication and development support -===================================== - -Join the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) for discussions surrounding Ansible development. - -For questions and discussions pertaining to using the Ansible product, join the ``#ansible`` channel. - -To find other topic-specific chat channels, look at :ref:`Community Guide, Communicating `. - -Credit -====== - -Thank you to Thomas Stringer (`@trstringer `_) for contributing source -material for this topic. diff --git a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst b/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst deleted file mode 100644 index b5b8c4a62cb..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst +++ /dev/null @@ -1,744 +0,0 @@ -.. _developing_modules_general_windows: - -************************************** -Windows module development walkthrough -************************************** - -In this section, we will walk through developing, testing, and debugging an -Ansible Windows module. - -Because Windows modules are written in Powershell and need to be run on a -Windows host, this guide differs from the usual development walkthrough guide. - -What's covered in this section: - -.. contents:: - :local: - - -Windows environment setup -========================= - -Unlike Python module development which can be run on the host that runs -Ansible, Windows modules need to be written and tested for Windows hosts. -While evaluation editions of Windows can be downloaded from -Microsoft, these images are usually not ready to be used by Ansible without -further modification. The easiest way to set up a Windows host so that it is -ready to by used by Ansible is to set up a virtual machine using Vagrant. -Vagrant can be used to download existing OS images called *boxes* that are then -deployed to a hypervisor like VirtualBox. These boxes can either be created and -stored offline or they can be downloaded from a central repository called -Vagrant Cloud. - -This guide will use the Vagrant boxes created by the `packer-windoze `_ -repository which have also been uploaded to `Vagrant Cloud `_. -To find out more info on how these images are created, please go to the GitHub -repo and look at the ``README`` file. - -Before you can get started, the following programs must be installed (please consult the Vagrant and -VirtualBox documentation for installation instructions): - -- Vagrant -- VirtualBox - -Create a Windows server in a VM -=============================== - -To create a single Windows Server 2016 instance, run the following: - -.. code-block:: shell - - vagrant init jborean93/WindowsServer2016 - vagrant up - -This will download the Vagrant box from Vagrant Cloud and add it to the local -boxes on your host and then start up that instance in VirtualBox. When starting -for the first time, the Windows VM will run through the sysprep process and -then create a HTTP and HTTPS WinRM listener automatically. Vagrant will finish -its process once the listeners are online, after which the VM can be used by Ansible. - -Create an Ansible inventory -=========================== - -The following Ansible inventory file can be used to connect to the newly -created Windows VM: - -.. code-block:: ini - - [windows] - WindowsServer ansible_host=127.0.0.1 - - [windows:vars] - ansible_user=vagrant - ansible_password=vagrant - ansible_port=55986 - ansible_connection=winrm - ansible_winrm_transport=ntlm - ansible_winrm_server_cert_validation=ignore - -.. note:: The port ``55986`` is automatically forwarded by Vagrant to the - Windows host that was created, if this conflicts with an existing local - port then Vagrant will automatically use another one at random and display - show that in the output. - -The OS that is created is based on the image set. The following -images can be used: - -- `jborean93/WindowsServer2012 `_ -- `jborean93/WindowsServer2012R2 `_ -- `jborean93/WindowsServer2016 `_ -- `jborean93/WindowsServer2019 `_ -- `jborean93/WindowsServer2022 `_ - -When the host is online, it can accessible by RDP on ``127.0.0.1:3389`` but the -port may differ depending if there was a conflict. To get rid of the host, run -``vagrant destroy --force`` and Vagrant will automatically remove the VM and -any other files associated with that VM. - -While this is useful when testing modules on a single Windows instance, these -host won't work without modification with domain based modules. The Vagrantfile -at `ansible-windows `_ -can be used to create a test domain environment to be used in Ansible. This -repo contains three files which are used by both Ansible and Vagrant to create -multiple Windows hosts in a domain environment. These files are: - -- ``Vagrantfile``: The Vagrant file that reads the inventory setup of ``inventory.yml`` and provisions the hosts that are required -- ``inventory.yml``: Contains the hosts that are required and other connection information such as IP addresses and forwarded ports -- ``main.yml``: Ansible playbook called by Vagrant to provision the domain controller and join the child hosts to the domain - -By default, these files will create the following environment: - -- A single domain controller running on Windows Server 2016 -- Five child hosts for each major Windows Server version joined to that domain -- A domain with the DNS name ``domain.local`` -- A local administrator account on each host with the username ``vagrant`` and password ``vagrant`` -- A domain admin account ``vagrant-domain@domain.local`` with the password ``VagrantPass1`` - -The domain name and accounts can be modified by changing the variables -``domain_*`` in the ``inventory.yml`` file if it is required. The inventory -file can also be modified to provision more or less servers by changing the -hosts that are defined under the ``domain_children`` key. The host variable -``ansible_host`` is the private IP that will be assigned to the VirtualBox host -only network adapter while ``vagrant_box`` is the box that will be used to -create the VM. - -Provisioning the environment -============================ - -To provision the environment as is, run the following: - -.. code-block:: shell - - git clone https://github.com/jborean93/ansible-windows.git - cd vagrant - vagrant up - -.. note:: Vagrant provisions each host sequentially so this can take some time - to complete. If any errors occur during the Ansible phase of setting up the - domain, run ``vagrant provision`` to rerun just that step. - -Unlike setting up a single Windows instance with Vagrant, these hosts can also -be accessed using the IP address directly as well as through the forwarded -ports. It is easier to access it over the host only network adapter as the -normal protocol ports are used, for example RDP is still over ``3389``. In cases where -the host cannot be resolved using the host only network IP, the following -protocols can be access over ``127.0.0.1`` using these forwarded ports: - -- ``RDP``: 295xx -- ``SSH``: 296xx -- ``WinRM HTTP``: 297xx -- ``WinRM HTTPS``: 298xx -- ``SMB``: 299xx - -Replace ``xx`` with the entry number in the inventory file where the domain -controller started with ``00`` and is incremented from there. For example, in -the default ``inventory.yml`` file, WinRM over HTTPS for ``SERVER2012R2`` is -forwarded over port ``29804`` as it's the fourth entry in ``domain_children``. - -Windows new module development -============================== - -When creating a new module there are a few things to keep in mind: - -- Module code is in Powershell (.ps1) files while the documentation is contained in Python (.py) files of the same name -- Avoid using ``Write-Host/Debug/Verbose/Error`` in the module and add what needs to be returned to the ``$module.Result`` variable -- To fail a module, call ``$module.FailJson("failure message here")``, an Exception or ErrorRecord can be set to the second argument for a more descriptive error message -- You can pass in the exception or ErrorRecord as a second argument to ``FailJson("failure", $_)`` to get a more detailed output -- Most new modules require check mode and integration tests before they are merged into the main Ansible codebase -- Avoid using try/catch statements over a large code block, rather use them for individual calls so the error message can be more descriptive -- Try and catch specific exceptions when using try/catch statements -- Avoid using PSCustomObjects unless necessary -- Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run through Ansible -- As well as PowerShell module utils, C# module utils are stored in ``./lib/ansible/module_utils/csharp/`` and are automatically imported in a module execution if the line ``#AnsibleRequires -CSharpUtil *`` is present -- C# and PowerShell module utils achieve the same goal but C# allows a developer to implement low level tasks, such as calling the Win32 API, and can be faster in some cases -- Ensure the code runs under Powershell v3 and higher on Windows Server 2012 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly -- Ansible runs modules under strictmode version 2.0. Be sure to test with that enabled by putting ``Set-StrictMode -Version 2.0`` at the top of your dev script -- Favor native Powershell cmdlets over executable calls if possible -- Use the full cmdlet name instead of aliases, for example ``Remove-Item`` over ``rm`` -- Use named parameters with cmdlets, for example ``Remove-Item -Path C:\temp`` over ``Remove-Item C:\temp`` - -A very basic Powershell module `win_environment `_ incorporates best practices for Powershell modules. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met. - -A slightly more advanced module is `win_uri `_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions. - -As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument -spec. The following options can be set at the root level of the argument spec: - -- ``mutually_exclusive``: A list of lists, where the inner list contains module options that cannot be set together -- ``no_log``: Stops the module from emitting any logs to the Windows Event log -- ``options``: A dictionary where the key is the module option and the value is the spec for that option -- ``required_by``: A dictionary where the option(s) specified by the value must be set if the option specified by the key is also set -- ``required_if``: A list of lists where the inner list contains 3 or 4 elements; - * The first element is the module option to check the value against - * The second element is the value of the option specified by the first element, if matched then the required if check is run - * The third element is a list of required module options when the above is matched - * An optional fourth element is a boolean that states whether all module options in the third elements are required (default: ``$false``) or only one (``$true``) -- ``required_one_of``: A list of lists, where the inner list contains module options where at least one must be set -- ``required_together``: A list of lists, where the inner list contains module options that must be set together -- ``supports_check_mode``: Whether the module supports check mode, by default this is ``$false`` - -The actual input options for a module are set within the ``options`` value as a dictionary. The keys of this dictionary -are the module option names while the values are the spec of that module option. Each spec can have the following -options set: - -- ``aliases``: A list of aliases for the module option -- ``choices``: A list of valid values for the module option, if ``type=list`` then each list value is validated against the choices and not the list itself -- ``default``: The default value for the module option if not set -- ``deprecated_aliases``: A list of hashtables that define aliases that are deprecated and the versions they will be removed in. Each entry must contain the keys ``name`` and ``collection_name`` with either ``version`` or ``date`` -- ``elements``: When ``type=list``, this sets the type of each list value, the values are the same as ``type`` -- ``no_log``: Will sanitise the input value before being returned in the ``module_invocation`` return value -- ``removed_in_version``: States when a deprecated module option is to be removed, a warning is displayed to the end user if set -- ``removed_at_date``: States the date (YYYY-MM-DD) when a deprecated module option will be removed, a warning is displayed to the end user if set -- ``removed_from_collection``: States from which collection the deprecated module option will be removed; must be specified if one of ``removed_in_version`` and ``removed_at_date`` is specified -- ``required``: Will fail when the module option is not set -- ``type``: The type of the module option, if not set then it defaults to ``str``. The valid types are; - * ``bool``: A boolean value - * ``dict``: A dictionary value, if the input is a JSON or key=value string then it is converted to dictionary - * ``float``: A float or `Single `_ value - * ``int``: An Int32 value - * ``json``: A string where the value is converted to a JSON string if the input is a dictionary - * ``list``: A list of values, ``elements=`` can convert the individual list value types if set. If ``elements=dict`` then ``options`` is defined, the values will be validated against the argument spec. When the input is a string then the string is split by ``,`` and any whitespace is trimmed - * ``path``: A string where values likes ``%TEMP%`` are expanded based on environment values. If the input value starts with ``\\?\`` then no expansion is run - * ``raw``: No conversions occur on the value passed in by Ansible - * ``sid``: Will convert Windows security identifier values or Windows account names to a `SecurityIdentifier `_ value - * ``str``: The value is converted to a string - -When ``type=dict``, or ``type=list`` and ``elements=dict``, the following keys can also be set for that module option: - -- ``apply_defaults``: The value is based on the ``options`` spec defaults for that key if ``True`` and null if ``False``. Only valid when the module option is not defined by the user and ``type=dict``. -- ``mutually_exclusive``: Same as the root level ``mutually_exclusive`` but validated against the values in the sub dict -- ``options``: Same as the root level ``options`` but contains the valid options for the sub option -- ``required_if``: Same as the root level ``required_if`` but validated against the values in the sub dict -- ``required_by``: Same as the root level ``required_by`` but validated against the values in the sub dict -- ``required_together``: Same as the root level ``required_together`` but validated against the values in the sub dict -- ``required_one_of``: Same as the root level ``required_one_of`` but validated against the values in the sub dict - -A module type can also be a delegate function that converts the value to whatever is required by the module option. For -example the following snippet shows how to create a custom type that creates a ``UInt64`` value: - -.. code-block:: powershell - - $spec = @{ - uint64_type = @{ type = [Func[[Object], [UInt64]]]{ [System.UInt64]::Parse($args[0]) } } - } - $uint64_type = $module.Params.uint64_type - -When in doubt, look at some of the other core modules and see how things have been -implemented there. - -Sometimes there are multiple ways that Windows offers to complete a task; this -is the order to favor when writing modules: - -- Native Powershell cmdlets like ``Remove-Item -Path C:\temp -Recurse`` -- .NET classes like ``[System.IO.Path]::GetRandomFileName()`` -- WMI objects through the ``New-CimInstance`` cmdlet -- COM objects through ``New-Object -ComObject`` cmdlet -- Calls to native executables like ``Secedit.exe`` - -PowerShell modules support a small subset of the ``#Requires`` options built -into PowerShell as well as some Ansible-specific requirements specified by -``#AnsibleRequires``. These statements can be placed at any point in the script, -but are most commonly near the top. They are used to make it easier to state the -requirements of the module without writing any of the checks. Each ``requires`` -statement must be on its own line, but there can be multiple requires statements -in one script. - -These are the checks that can be used within Ansible modules: - -- ``#Requires -Module Ansible.ModuleUtils.``: Added in Ansible 2.4, specifies a module_util to load in for the module execution. -- ``#Requires -Version x.y``: Added in Ansible 2.5, specifies the version of PowerShell that is required by the module. The module will fail if this requirement is not met. -- ``#AnsibleRequires -PowerShell ``: Added in Ansible 2.8, like ``#Requires -Module``, this specifies a module_util to load in for module execution. -- ``#AnsibleRequires -CSharpUtil ``: Added in Ansible 2.8, specifies a C# module_util to load in for the module execution. -- ``#AnsibleRequires -OSVersion x.y``: Added in Ansible 2.5, specifies the OS build version that is required by the module and will fail if this requirement is not met. The actual OS version is derived from ``[Environment]::OSVersion.Version``. -- ``#AnsibleRequires -Become``: Added in Ansible 2.5, forces the exec runner to run the module with ``become``, which is primarily used to bypass WinRM restrictions. If ``ansible_become_user`` is not specified then the ``SYSTEM`` account is used instead. - -The ``#AnsibleRequires -PowerShell`` and ``#AnsibleRequires -CSharpUtil`` -support further features such as: - -- Importing a util contained in a collection (added in Ansible 2.9) -- Importing a util by relative names (added in Ansible 2.10) -- Specifying the util is optional by adding `-Optional` to the import - declaration (added in Ansible 2.12). - -See the below examples for more details: - -.. code-block:: powershell - - # Imports the PowerShell Ansible.ModuleUtils.Legacy provided by Ansible itself - #AnsibleRequires -PowerShell Ansible.ModuleUtils.Legacy - - # Imports the PowerShell my_util in the my_namesapce.my_name collection - #AnsibleRequires -PowerShell ansible_collections.my_namespace.my_name.plugins.module_utils.my_util - - # Imports the PowerShell my_util that exists in the same collection as the current module - #AnsibleRequires -PowerShell ..module_utils.my_util - - # Imports the PowerShell Ansible.ModuleUtils.Optional provided by Ansible if it exists. - # If it does not exist then it will do nothing. - #AnsibleRequires -PowerShell Ansible.ModuleUtils.Optional -Optional - - # Imports the C# Ansible.Process provided by Ansible itself - #AnsibleRequires -CSharpUtil Ansible.Process - - # Imports the C# my_util in the my_namespace.my_name collection - #AnsibleRequires -CSharpUtil ansible_collections.my_namespace.my_name.plugins.module_utils.my_util - - # Imports the C# my_util that exists in the same collection as the current module - #AnsibleRequires -CSharpUtil ..module_utils.my_util - - # Imports the C# Ansible.Optional provided by Ansible if it exists. - # If it does not exist then it will do nothing. - #AnsibleRequires -CSharpUtil Ansible.Optional -Optional - -For optional require statements, it is up to the module code to then verify -whether the util has been imported before trying to use it. This can be done by -checking if a function or type provided by the util exists or not. - -While both ``#Requires -Module`` and ``#AnsibleRequires -PowerShell`` can be -used to load a PowerShell module it is recommended to use ``#AnsibleRequires``. -This is because ``#AnsibleRequires`` supports collection module utils, imports -by relative util names, and optional util imports. - -C# module utils can reference other C# utils by adding the line -``using Ansible.;`` to the top of the script with all the other -using statements. - - -Windows module utilities -======================== - -Like Python modules, PowerShell modules also provide a number of module -utilities that provide helper functions within PowerShell. These module_utils -can be imported by adding the following line to a PowerShell module: - -.. code-block:: powershell - - #Requires -Module Ansible.ModuleUtils.Legacy - -This will import the module_util at ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` -and enable calling all of its functions. As of Ansible 2.8, Windows module -utils can also be written in C# and stored at ``lib/ansible/module_utils/csharp``. -These module_utils can be imported by adding the following line to a PowerShell -module: - -.. code-block:: powershell - - #AnsibleRequires -CSharpUtil Ansible.Basic - -This will import the module_util at ``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` -and automatically load the types in the executing process. C# module utils can -reference each other and be loaded together by adding the following line to the -using statements at the top of the util: - -.. code-block:: csharp - - using Ansible.Become; - -There are special comments that can be set in a C# file for controlling the -compilation parameters. The following comments can be added to the script; - -- ``//AssemblyReference -Name [-CLR [Core|Framework]]``: The assembly DLL to reference during compilation, the optional ``-CLR`` flag can also be used to state whether to reference when running under .NET Core, Framework, or both (if omitted) -- ``//NoWarn -Name [-CLR [Core|Framework]]``: A compiler warning ID to ignore when compiling the code, the optional ``-CLR`` works the same as above. A list of warnings can be found at `Compiler errors `_ - -As well as this, the following pre-processor symbols are defined; - -- ``CORECLR``: This symbol is present when PowerShell is running through .NET Core -- ``WINDOWS``: This symbol is present when PowerShell is running on Windows -- ``UNIX``: This symbol is present when PowerShell is running on Unix - -A combination of these flags help to make a module util interoperable on both -.NET Framework and .NET Core, here is an example of them in action: - -.. code-block:: csharp - - #if CORECLR - using Newtonsoft.Json; - #else - using System.Web.Script.Serialization; - #endif - - //AssemblyReference -Name Newtonsoft.Json.dll -CLR Core - //AssemblyReference -Name System.Web.Extensions.dll -CLR Framework - - // Ignore error CS1702 for all .NET types - //NoWarn -Name CS1702 - - // Ignore error CS1956 only for .NET Framework - //NoWarn -Name CS1956 -CLR Framework - - -The following is a list of module_utils that are packaged with Ansible and a general description of what -they do: - -- ArgvParser: Utility used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules. -- CamelConversion: Utility used to convert camelCase strings/lists/dicts to snake_case. -- CommandUtil: Utility used to execute a Windows process and return the stdout/stderr and rc as separate objects. -- FileUtil: Utility that expands on the ``Get-ChildItem`` and ``Test-Path`` to work with special files like ``C:\pagefile.sys``. -- Legacy: General definitions and helper utilities for Ansible module. -- LinkUtil: Utility to create, remove, and get information about symbolic links, junction points and hard inks. -- SID: Utilities used to convert a user or group to a Windows SID and vice versa. - -For more details on any specific module utility and their requirements, please see the `Ansible -module utilities source code `_. - -PowerShell module utilities can be stored outside of the standard Ansible -distribution for use with custom modules. Custom module_utils are placed in a -folder called ``module_utils`` located in the root folder of the playbook or role -directory. - -C# module utilities can also be stored outside of the standard Ansible distribution for use with custom modules. Like -PowerShell utils, these are stored in a folder called ``module_utils`` and the filename must end in the extension -``.cs``, start with ``Ansible.`` and be named after the namespace defined in the util. - -The below example is a role structure that contains two PowerShell custom module_utils called -``Ansible.ModuleUtils.ModuleUtil1``, ``Ansible.ModuleUtils.ModuleUtil2``, and a C# util containing the namespace -``Ansible.CustomUtil``: - -.. code-block:: console - - meta/ - main.yml - defaults/ - main.yml - module_utils/ - Ansible.ModuleUtils.ModuleUtil1.psm1 - Ansible.ModuleUtils.ModuleUtil2.psm1 - Ansible.CustomUtil.cs - tasks/ - main.yml - -Each PowerShell module_util must contain at least one function that has been exported with ``Export-ModuleMember`` -at the end of the file. For example - -.. code-block:: powershell - - Export-ModuleMember -Function Invoke-CustomUtil, Get-CustomInfo - - -Exposing shared module options -++++++++++++++++++++++++++++++ - -PowerShell module utils can easily expose common module options that a module can use when building its argument spec. -This allows common features to be stored and maintained in one location and have those features used by multiple -modules with minimal effort. Any new features or bugfixes added to one of these utils are then automatically used by -the various modules that call that util. - -An example of this would be to have a module util that handles authentication and communication against an API This -util can be used by multiple modules to expose a common set of module options like the API endpoint, username, -password, timeout, cert validation, and so on without having to add those options to each module spec. - -The standard convention for a module util that has a shared argument spec would have - -- A ``Get-Spec`` function that outputs the common spec for a module - * It is highly recommended to make this function name be unique to the module to avoid any conflicts with other utils that can be loaded - * The format of the output spec is a Hashtable in the same format as the ``$spec`` used for normal modules -- A function that takes in an ``AnsibleModule`` object called under the ``-Module`` parameter which it can use to get the shared options - -Because these options can be shared across various module it is highly recommended to keep the module option names and -aliases in the shared spec as specific as they can be. For example do not have a util option called ``password``, -rather you should prefix it with a unique name like ``acme_password``. - -.. warning:: - Failure to have a unique option name or alias can prevent the util being used by module that also use those names or - aliases for its own options. - -The following is an example module util called ``ServiceAuth.psm1`` in a collection that implements a common way for -modules to authentication with a service. - -.. code-block:: powershell - - Invoke-MyServiceResource { - [CmdletBinding()] - param ( - [Parameter(Mandatory=$true)] - [ValidateScript({ $_.GetType().FullName -eq 'Ansible.Basic.AnsibleModule' })] - $Module, - - [Parameter(Mandatory=$true)] - [String] - $ResourceId, - - [String] - $State = 'present' - ) - - # Process the common module options known to the util - $params = @{ - ServerUri = $Module.Params.my_service_url - } - if ($Module.Params.my_service_username) { - $params.Credential = Get-MyServiceCredential - } - - if ($State -eq 'absent') { - Remove-MyService @params -ResourceId $ResourceId - } else { - New-MyService @params -ResourceId $ResourceId - } - } - - Get-MyNamespaceMyCollectionServiceAuthSpec { - # Output the util spec - @{ - options = @{ - my_service_url = @{ type = 'str'; required = $true } - my_service_username = @{ type = 'str' } - my_service_password = @{ type = 'str'; no_log = $true } - } - - required_together = @( - ,@('my_service_username', 'my_service_password') - ) - } - } - - $exportMembers = @{ - Function = 'Get-MyNamespaceMyCollectionServiceAuthSpec', 'Invoke-MyServiceResource' - } - Export-ModuleMember @exportMembers - - -For a module to take advantage of this common argument spec it can be set out like - -.. code-block:: powershell - - #!powershell - - # Include the module util ServiceAuth.psm1 from the my_namespace.my_collection collection - #AnsibleRequires -PowerShell ansible_collections.my_namespace.my_collection.plugins.module_utils.ServiceAuth - - # Create the module spec like normal - $spec = @{ - options = @{ - resource_id = @{ type = 'str'; required = $true } - state = @{ type = 'str'; choices = 'absent', 'present' } - } - } - - # Create the module from the module spec but also include the util spec to merge into our own. - $module = [Ansible.Basic.AnsibleModule]::Create($args, $spec, @(Get-MyNamespaceMyCollectionServiceAuthSpec)) - - # Call the ServiceAuth module util and pass in the module object so it can access the module options. - Invoke-MyServiceResource -Module $module -ResourceId $module.Params.resource_id -State $module.params.state - - $module.ExitJson() - - -.. note:: - Options defined in the module spec will always have precedence over a util spec. Any list values under the same key - in a util spec will be appended to the module spec for that same key. Dictionary values will add any keys that are - missing from the module spec and merge any values that are lists or dictionaries. This is similar to how the doc - fragment plugins work when extending module documentation. - -To document these shared util options for a module, create a doc fragment plugin that documents the options implemented -by the module util and extend the module docs for every module that implements the util to include that fragment in -its docs. - - -Windows playbook module testing -=============================== - -You can test a module with an Ansible playbook. For example: - -- Create a playbook in any directory ``touch testmodule.yml``. -- Create an inventory file in the same directory ``touch hosts``. -- Populate the inventory file with the variables required to connect to a Windows host(s). -- Add the following to the new playbook file: - -.. code-block:: yaml - - --- - - name: test out windows module - hosts: windows - tasks: - - name: test out module - win_module: - name: test name - -- Run the playbook ``ansible-playbook -i hosts testmodule.yml`` - -This can be useful for seeing how Ansible runs with -the new module end to end. Other possible ways to test the module are -shown below. - - -Windows debugging -================= - -Debugging a module currently can only be done on a Windows host. This can be -useful when developing a new module or implementing bug fixes. These -are some steps that need to be followed to set this up: - -- Copy the module script to the Windows server -- Copy the folders ``./lib/ansible/module_utils/powershell`` and ``./lib/ansible/module_utils/csharp`` to the same directory as the script above -- Add an extra ``#`` to the start of any ``#Requires -Module`` lines in the module code, this is only required for any lines starting with ``#Requires -Module`` -- Add the following to the start of the module script that was copied to the server: - -.. code-block:: powershell - - # Set $ErrorActionPreference to what's set during Ansible execution - $ErrorActionPreference = "Stop" - - # Set the first argument as the path to a JSON file that contains the module args - $args = @("$($pwd.Path)\args.json") - - # Or instead of an args file, set $complex_args to the pre-processed module args - $complex_args = @{ - _ansible_check_mode = $false - _ansible_diff = $false - path = "C:\temp" - state = "present" - } - - # Import any C# utils referenced with '#AnsibleRequires -CSharpUtil' or 'using Ansible.; - # The $_csharp_utils entries should be the context of the C# util files and not the path - Import-Module -Name "$($pwd.Path)\powershell\Ansible.ModuleUtils.AddType.psm1" - $_csharp_utils = @( - [System.IO.File]::ReadAllText("$($pwd.Path)\csharp\Ansible.Basic.cs") - ) - Add-CSharpType -References $_csharp_utils -IncludeDebugInfo - - # Import any PowerShell modules referenced with '#Requires -Module` - Import-Module -Name "$($pwd.Path)\powershell\Ansible.ModuleUtils.Legacy.psm1" - - # End of the setup code and start of the module code - #!powershell - -You can add more args to ``$complex_args`` as required by the module or define the module options through a JSON file -with the structure: - -.. code-block:: json - - { - "ANSIBLE_MODULE_ARGS": { - "_ansible_check_mode": false, - "_ansible_diff": false, - "path": "C:\\temp", - "state": "present" - } - } - -There are multiple IDEs that can be used to debug a Powershell script, two of -the most popular ones are - -- `Powershell ISE`_ -- `Visual Studio Code`_ - -.. _Powershell ISE: https://docs.microsoft.com/en-us/powershell/scripting/core-powershell/ise/how-to-debug-scripts-in-windows-powershell-ise -.. _Visual Studio Code: https://blogs.technet.microsoft.com/heyscriptingguy/2017/02/06/debugging-powershell-script-in-visual-studio-code-part-1/ - -To be able to view the arguments as passed by Ansible to the module follow -these steps. - -- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server. -- Log onto the Windows server using the same user account that Ansible used to execute the module. -- Navigate to ``%TEMP%\..``. It should contain a folder starting with ``ansible-tmp-``. -- Inside this folder, open the PowerShell script for the module. -- In this script is a raw JSON script under ``$json_raw`` which contains the module arguments under ``module_args``. These args can be assigned manually to the ``$complex_args`` variable that is defined on your debug script or put in the ``args.json`` file. - - -Windows unit testing -==================== - -Currently there is no mechanism to run unit tests for Powershell modules under Ansible CI. - - -Windows integration testing -=========================== - -Integration tests for Ansible modules are typically written as Ansible roles. These test -roles are located in ``./test/integration/targets``. You must first set up your testing -environment, and configure a test inventory for Ansible to connect to. - -In this example we will set up a test inventory to connect to two hosts and run the integration -tests for win_stat: - -- Run the command ``source ./hacking/env-setup`` to prepare environment. -- Create a copy of ``./test/integration/inventory.winrm.template`` and name it ``inventory.winrm``. -- Fill in entries under ``[windows]`` and set the required variables that are needed to connect to the host. -- :ref:`Install the required Python modules ` to support WinRM and a configured authentication method. -- To execute the integration tests, run ``ansible-test windows-integration win_stat``; you can replace ``win_stat`` with the role you want to test. - -This will execute all the tests currently defined for that role. You can set -the verbosity level using the ``-v`` argument just as you would with -ansible-playbook. - -When developing tests for a new module, it is recommended to test a scenario once in -check mode and twice not in check mode. This ensures that check mode -does not make any changes but reports a change, as well as that the second run is -idempotent and does not report changes. For example: - -.. code-block:: yaml - - - name: remove a file (check mode) - win_file: - path: C:\temp - state: absent - register: remove_file_check - check_mode: true - - - name: get result of remove a file (check mode) - win_command: powershell.exe "if (Test-Path -Path 'C:\temp') { 'true' } else { 'false' }" - register: remove_file_actual_check - - - name: assert remove a file (check mode) - assert: - that: - - remove_file_check is changed - - remove_file_actual_check.stdout == 'true\r\n' - - - name: remove a file - win_file: - path: C:\temp - state: absent - register: remove_file - - - name: get result of remove a file - win_command: powershell.exe "if (Test-Path -Path 'C:\temp') { 'true' } else { 'false' }" - register: remove_file_actual - - - name: assert remove a file - assert: - that: - - remove_file is changed - - remove_file_actual.stdout == 'false\r\n' - - - name: remove a file (idempotent) - win_file: - path: C:\temp - state: absent - register: remove_file_again - - - name: assert remove a file (idempotent) - assert: - that: - - not remove_file_again is changed - - -Windows communication and development support -============================================= - -Join the ``#ansible-devel`` or ``#ansible-windows`` chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) for discussions about Ansible development for Windows. - -For questions and discussions pertaining to using the Ansible product, -use the ``#ansible`` channel. diff --git a/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst b/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst deleted file mode 100644 index cd44a3ffdc6..00000000000 --- a/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. _developing_modules_in_groups: - -************************* -Creating a new collection -************************* - -Starting with Ansible 2.10, related modules should be developed in a collection. The Ansible core team and community compiled these module development tips and tricks to help companies developing Ansible modules for their products and users developing Ansible modules for third-party products. See :ref:`developing_collections` for a more detailed description of the collections format and additional development guidelines. - -.. contents:: - :local: - -.. include:: shared_snippets/licensing.txt - -Before you start coding -======================= - -This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-core and provide a seamless user experience. - -* Read though all the pages linked off :ref:`developing_modules_general`; paying particular focus to the :ref:`developing_modules_checklist`. -* We encourage PEP 8 compliance. See :ref:`testing_pep8` for more information. -* We encourage supporting :ref:`Python 2.6+ and Python 3.5+ `. -* Look at Ansible Galaxy and review the naming conventions in your functional area (such as cloud, networking, databases). -* With great power comes great responsibility: Ansible collection maintainers have a duty to help keep content up to date and release collections they are responsible for regularly. As with all successful community projects, collection maintainers should keep a watchful eye for reported issues and contributions. -* We strongly recommend unit and/or integration tests. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :ref:`developing_testing` and the `Testing Working Group `_. - - -Naming conventions -================== - -Fully Qualified Collection Names (FQCNs) for plugins and modules include three elements: - - * the Galaxy namespace, which generally represents the company or group - * the collection name, which generally represents the product or OS - * the plugin or module name - * always in lower case - * words separated with an underscore (``_``) character - * singular, rather than plural, for example, ``command`` not ``commands`` - -For example, ``community.mongodb.mongodb_linux`` or ``cisco.meraki.meraki_device``. - -It is convenient if the organization and repository names on GitHub (or elsewhere) match your namespace and collection names on Ansible Galaxy, but it is not required. The plugin names you select, however, are always the same in your code repository and in your collection artifact on Galaxy. - -Speak to us -=========== - -Circulating your ideas before coding helps you adopt good practices and avoid common mistakes. After reading the "Before you start coding" section you should have a reasonable idea of the structure of your modules. Write a list of your proposed plugin and/or module names, with a short description of what each one does. Circulate that list on IRC or a mailing list so the Ansible community can review your ideas for consistency and familiarity. Names and functionality that are consistent, predictable, and familiar make your collection easier to use. - -.. _developing_in_groups_support: - -Where to get support -==================== - -Ansible has a thriving and knowledgeable community of module developers that is a great resource for getting your questions answered. - -In the :ref:`ansible_community_guide` you can find how to: - -* Subscribe to the Mailing Lists - We suggest "Ansible Development List" and "Ansible Announce list" -* ``#ansible-devel`` - We have found that communicating on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) works best for developers so we can have an interactive dialogue. -* Working group and other chat channel meetings - Join the various weekly meetings `meeting schedule and agenda page `_ - -Required files -============== - -Your collection should include the following files to be usable: - -* an ``__init__.py`` file - An empty file to initialize namespace and allow Python to import the files. *Required* -* at least one plugin, for example, ``/plugins/modules/$your_first_module.py``. *Required* -* if needed, one or more ``/plugins/doc_fragments/$topic.py`` files - Code documentation, such as details regarding common arguments. *Optional* -* if needed, one or more ``/plugins/module_utils/$topic.py`` files - Code shared between more than one module, such as common arguments. *Optional* - -When you have these files ready, review the :ref:`developing_modules_checklist` again. If you are creating a new collection, you are responsible for all procedures related to your repository, including setting rules for contributions, finding reviewers, and testing and maintaining the code in your collection. - -If you need help or advice, consider joining the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). For more information, see :ref:`developing_in_groups_support` and :ref:`communication`. - -New to git or GitHub -==================== - -We realize this may be your first use of Git or GitHub. The following guides may be of use: - -* `How to create a fork of ansible/ansible `_ -* `How to sync (update) your fork `_ -* `How to create a Pull Request (PR) `_ diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst deleted file mode 100644 index 25662f018bd..00000000000 --- a/docs/docsite/rst/dev_guide/developing_plugins.rst +++ /dev/null @@ -1,565 +0,0 @@ -.. _developing_plugins: -.. _plugin_guidelines: - -****************** -Developing plugins -****************** - -.. contents:: - :local: - -Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible collections include a number of handy plugins, and you can easily write your own. All plugins must: - -* be written in Python -* raise errors -* return strings in unicode -* conform to Ansible's configuration and documentation standards - -Once you've reviewed these general guidelines, you can skip to the particular type of plugin you want to develop. - -Writing plugins in Python -========================= - -You must write your plugin in Python so it can be loaded by the ``PluginLoader`` and returned as a Python object that any module can use. Since your plugin will execute on the controller, you must write it in a :ref:`compatible version of Python `. - -Raising errors -============== - -You should return errors encountered during plugin execution by raising ``AnsibleError()`` or a similar class with a message describing the error. When wrapping other exceptions into error messages, you should always use the ``to_native`` Ansible function to ensure proper string compatibility across Python versions: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_native - - try: - cause_an_exception() - except Exception as e: - raise AnsibleError('Something happened, this was original exception: %s' % to_native(e)) - -Since Ansible evaluates variables only when they are needed, filter and test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary. - -Check the different `AnsibleError objects `_ and see which one applies best to your situation. -Check the section on the specific plugin type you're developing for type-specific error handling details. - -String encoding -=============== - -You must convert any strings returned by your plugin into Python's unicode type. Converting to unicode ensures that these strings can run through Jinja2. To convert strings: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_text - result_string = to_text(result_string) - -Plugin configuration & documentation standards -============================================== - -To define configurable options for your plugin, describe them in the ``DOCUMENTATION`` section of the python file. Callback and connection plugins have declared configuration requirements this way since Ansible version 2.4; most plugin types now do the same. This approach ensures that the documentation of your plugin's options will always be correct and up-to-date. To add a configurable option to your plugin, define it in this format: - -.. code-block:: yaml - - options: - option_name: - description: describe this config option - default: default value for this config option - env: - - name: NAME_OF_ENV_VAR - ini: - - section: section_of_ansible.cfg_where_this_config_option_is_defined - key: key_used_in_ansible.cfg - vars: - - name: name_of_ansible_var - - name: name_of_second_var - version_added: X.x - required: True/False - type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath - version_added: X.x - -To access the configuration settings in your plugin, use ``self.get_option()``. -Some plugin types hande this differently: - -* Become, callback, connection and shell plugins are guaranteed to have the engine call ``set_options()``. -* Lookup plugins always require you to handle it in the ``run()`` method. -* Inventory plugins are done automatically if you use the ``base _read_config_file()`` method. If not, you must use ``self.get_option()``. -* Cache plugins do it on load. -* Cliconf, httpapi and netconf plugins indirectly piggy back on connection plugins. -* Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method. - -If you need to populate settings explicitly, use a ``self.set_options()`` call. - -Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information. - -Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either through a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use. - -In ansible-core 2.14 we added support for documenting filter and test plugins. You have two options for providing documentation: - - Define a Python file that includes inline documentation for each plugin. - - Define a Python file for multiple plugins and create adjacent documentation files in YAML format. - -Developing particular plugin types -================================== - -.. _developing_actions: - -Action plugins --------------- - -Action plugins let you integrate local processing and local data with module functionality. - -To create an action plugin, create a new class with the Base(ActionBase) class as the parent: - -.. code-block:: python - - from ansible.plugins.action import ActionBase - - class ActionModule(ActionBase): - pass - -From there, execute the module using the ``_execute_module`` method to call the original module. -After successful execution of the module, you can modify the module return data. - -.. code-block:: python - - module_return = self._execute_module(module_name='', - module_args=module_args, - task_vars=task_vars, tmp=tmp) - - -For example, if you wanted to check the time difference between your Ansible controller and your target machine(s), you could write an action plugin to check the local time and compare it to the return data from Ansible's ``setup`` module: - -.. code-block:: python - - #!/usr/bin/python - # Make coding more python3-ish, this is required for contributions to Ansible - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - from ansible.plugins.action import ActionBase - from datetime import datetime - - - class ActionModule(ActionBase): - def run(self, tmp=None, task_vars=None): - super(ActionModule, self).run(tmp, task_vars) - module_args = self._task.args.copy() - module_return = self._execute_module(module_name='setup', - module_args=module_args, - task_vars=task_vars, tmp=tmp) - ret = dict() - remote_date = None - if not module_return.get('failed'): - for key, value in module_return['ansible_facts'].items(): - if key == 'ansible_date_time': - remote_date = value['iso8601'] - - if remote_date: - remote_date_obj = datetime.strptime(remote_date, '%Y-%m-%dT%H:%M:%SZ') - time_delta = datetime.utcnow() - remote_date_obj - ret['delta_seconds'] = time_delta.seconds - ret['delta_days'] = time_delta.days - ret['delta_microseconds'] = time_delta.microseconds - - return dict(ansible_facts=dict(ret)) - - -This code checks the time on the controller, captures the date and time for the remote machine using the ``setup`` module, and calculates the difference between the captured time and -the local time, returning the time delta in days, seconds and microseconds. - -For practical examples of action plugins, -see the source code for the `action plugins included with Ansible Core `_ - -.. _developing_cache_plugins: - -Cache plugins -------------- - -Cache plugins store gathered facts and data retrieved by inventory plugins. - -Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option()``. If you import a cache plugin directly in the code base, you can only access options by the ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin. - -.. code-block:: python - - from ansible.plugins.loader import cache_loader - [...] - plugin = cache_loader.get('custom_cache', **cache_kwargs) - -There are two base classes for cache plugins, ``BaseCacheModule`` for database-backed caches, and ``BaseCacheFileModule`` for file-backed caches. - -To create a cache plugin, start by creating a new ``CacheModule`` class with the appropriate base class. If you're creating a plugin using an ``__init__`` method you should initialize the base class with any provided args and kwargs to be compatible with inventory plugin cache options. The base class calls ``self.set_options(direct=kwargs)``. After the base class ``__init__`` method is called ``self.get_option()`` should be used to access cache options. - -New cache plugins should take the options ``_uri``, ``_prefix``, and ``_timeout`` to be consistent with existing cache plugins. - -.. code-block:: python - - from ansible.plugins.cache import BaseCacheModule - - class CacheModule(BaseCacheModule): - def __init__(self, *args, **kwargs): - super(CacheModule, self).__init__(*args, **kwargs) - self._connection = self.get_option('_uri') - self._prefix = self.get_option('_prefix') - self._timeout = self.get_option('_timeout') - -If you use the ``BaseCacheModule``, you must implement the methods ``get``, ``contains``, ``keys``, ``set``, ``delete``, ``flush``, and ``copy``. The ``contains`` method should return a boolean that indicates if the key exists and has not expired. Unlike file-based caches, the ``get`` method does not raise a KeyError if the cache has expired. - -If you use the ``BaseFileCacheModule``, you must implement ``_load`` and ``_dump`` methods that will be called from the base class methods ``get`` and ``set``. - -If your cache plugin stores JSON, use ``AnsibleJSONEncoder`` in the ``_dump`` or ``set`` method and ``AnsibleJSONDecoder`` in the ``_load`` or ``get`` method. - -For example cache plugins, see the source code for the `cache plugins included with Ansible Core `_. - -.. _developing_callbacks: - -Callback plugins ----------------- - -Callback plugins add new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs. - -To create a callback plugin, create a new class with the Base(Callbacks) class as the parent: - -.. code-block:: python - - from ansible.plugins.callback import CallbackBase - - class CallbackModule(CallbackBase): - pass - -From there, override the specific methods from the CallbackBase that you want to provide a callback for. -For plugins intended for use with Ansible version 2.0 and later, you should only override methods that start with ``v2``. -For a complete list of methods that you can override, please see ``__init__.py`` in the -`lib/ansible/plugins/callback `_ directory. - -The following is a modified example of how Ansible's timer plugin is implemented, -but with an extra option so you can see how configuration works in Ansible version 2.4 and later: - -.. code-block:: python - - # Make coding more python3-ish, this is required for contributions to Ansible - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - # not only visible to ansible-doc, it also 'declares' the options the plugin requires and how to configure them. - DOCUMENTATION = ''' - name: timer - callback_type: aggregate - requirements: - - enable in configuration - short_description: Adds time to play stats - version_added: "2.0" # for collections, use the collection version, not the Ansible version - description: - - This callback just adds total play duration to the play stats. - options: - format_string: - description: format of the string shown to user at play end - ini: - - section: callback_timer - key: format_string - env: - - name: ANSIBLE_CALLBACK_TIMER_FORMAT - default: "Playbook run took %s days, %s hours, %s minutes, %s seconds" - ''' - from datetime import datetime - - from ansible.plugins.callback import CallbackBase - - - class CallbackModule(CallbackBase): - """ - This callback module tells you how long your plays ran for. - """ - CALLBACK_VERSION = 2.0 - CALLBACK_TYPE = 'aggregate' - CALLBACK_NAME = 'namespace.collection_name.timer' - - # only needed if you ship it and don't want to enable by default - CALLBACK_NEEDS_ENABLED = True - - def __init__(self): - - # make sure the expected objects are present, calling the base's __init__ - super(CallbackModule, self).__init__() - - # start the timer when the plugin is loaded, the first play should start a few milliseconds after. - self.start_time = datetime.now() - - def _days_hours_minutes_seconds(self, runtime): - ''' internal helper method for this callback ''' - minutes = (runtime.seconds // 60) % 60 - r_seconds = runtime.seconds - (minutes * 60) - return runtime.days, runtime.seconds // 3600, minutes, r_seconds - - # this is only event we care about for display, when the play shows its summary stats; the rest are ignored by the base class - def v2_playbook_on_stats(self, stats): - end_time = datetime.now() - runtime = end_time - self.start_time - - # Shows the usage of a config option declared in the DOCUMENTATION variable. Ansible will have set it when it loads the plugin. - # Also note the use of the display object to print to screen. This is available to all callbacks, and you should use this over printing yourself - self._display.display(self._plugin_options['format_string'] % (self._days_hours_minutes_seconds(runtime))) - - -Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are required for properly functioning plugins for Ansible version 2.0 and later. ``CALLBACK_TYPE`` is mostly needed to distinguish 'stdout' plugins from the rest, since you can only load one plugin that writes to stdout. - -For example callback plugins, see the source code for the `callback plugins included with Ansible Core `_ - -New in ansible-core 2.11, callback plugins are notified (by the ``v2_playbook_on_task_start``) of :ref:`meta` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks. - -There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user. - -.. _developing_connection_plugins: - -Connection plugins ------------------- - -Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. The most commonly used connection plugins are the ``paramiko`` SSH, native ssh (just called ``ssh``), and ``local`` connection types. All of these can be used in playbooks and with ``/usr/bin/ansible`` to connect to remote machines. - -Ansible version 2.1 introduced the ``smart`` connection plugin. The ``smart`` connection type allows Ansible to automatically select either the ``paramiko`` or ``openssh`` connection plugin based on system capabilities, or the ``ssh`` connection plugin if OpenSSH supports ControlPersist. - -To create a new connection plugin (for example, to support SNMP, Message bus, or other transports), copy the format of one of the existing connection plugins and drop it into ``connection`` directory on your :ref:`local plugin path `. - -Connection plugins can support common options (such as the ``--timeout`` flag) by defining an entry in the documentation for the attribute name (in this case ``timeout``). If the common option has a non-null default, the plugin should define the same default since a different default would be ignored. - -For example connection plugins, see the source code for the `connection plugins included with Ansible Core `_. - -.. _developing_filter_plugins: - -Filter plugins --------------- - -Filter plugins manipulate data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the filter plugins shipped with Ansible reside in a ``core.py``. - -Filter plugins do not use the standard configuration system described above, but since ansible-core 2.14 can use it as plain documentation. - -Since Ansible evaluates variables only when they are needed, filter plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary. - -.. code-block:: python - - try: - cause_an_exception(with_undefined_variable) - except jinja2.exceptions.UndefinedError as e: - raise AnsibleUndefinedVariable("Something happened, this was the original exception: %s" % to_native(e)) - except Exception as e: - raise AnsibleFilterError("Something happened, this was the original exception: %s" % to_native(e)) - -For example filter plugins, see the source code for the `filter plugins included with Ansible Core `_. - -.. _developing_inventory_plugins: - -Inventory plugins ------------------ - -Inventory plugins parse inventory sources and form an in-memory representation of the inventory. Inventory plugins were added in Ansible version 2.4. - -You can see the details for inventory plugins in the :ref:`developing_inventory` page. - -.. _developing_lookup_plugins: - -Lookup plugins --------------- - -Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented through lookup plugins --- and to return values into a variable or parameter. - -Lookup plugins are expected to return lists, even if just a single element. - -Ansible includes many :ref:`filters ` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin. - -Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable: - -.. code-block:: python - - # python 3 headers, required if submitting to Ansible - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - DOCUMENTATION = r""" - name: file - author: Daniel Hokka Zakrisson (@dhozac) - version_added: "0.9" # for collections, use the collection version, not the Ansible version - short_description: read file contents - description: - - This lookup returns the contents from a file on the Ansible controller's file system. - options: - _terms: - description: path(s) of files to read - required: True - option1: - description: - - Sample option that could modify plugin behaviour. - - This one can be set directly ``option1='x'`` or in ansible.cfg, but can also use vars or environment. - type: string - ini: - - section: file_lookup - key: option1 - notes: - - if read in variable context, the file can be interpreted as YAML if the content is valid to the parser. - - this lookup does not understand globbing --- use the fileglob lookup instead. - """ - from ansible.errors import AnsibleError, AnsibleParserError - from ansible.plugins.lookup import LookupBase - from ansible.utils.display import Display - - display = Display() - - class LookupModule(LookupBase): - - def run(self, terms, variables=None, **kwargs): - - # First of all populate options, - # this will already take into account env vars and ini config - self.set_options(var_options=variables, direct=kwargs) - - # lookups in general are expected to both take a list as input and output a list - # this is done so they work with the looping construct 'with_'. - ret = [] - for term in terms: - display.debug("File lookup term: %s" % term) - - # Find the file in the expected search path, using a class method - # that implements the 'expected' search path for Ansible plugins. - lookupfile = self.find_file_in_search_path(variables, 'files', term) - - # Don't use print or your own logging, the display class - # takes care of it in a unified way. - display.vvvv(u"File lookup using %s as file" % lookupfile) - try: - if lookupfile: - contents, show_data = self._loader._get_file_contents(lookupfile) - ret.append(contents.rstrip()) - else: - # Always use ansible error classes to throw 'final' exceptions, - # so the Ansible engine will know how to deal with them. - # The Parser error indicates invalid options passed - raise AnsibleParserError() - except AnsibleParserError: - raise AnsibleError("could not locate file in lookup: %s" % term) - - # consume an option: if this did something useful, you can retrieve the option value here - if self.get_option('option1') == 'do something': - pass - - return ret - - -The following is an example of how this lookup is called: - -.. code-block:: YAML - - --- - - hosts: all - vars: - contents: "{{ lookup('namespace.collection_name.file', '/etc/foo.txt') }}" - contents_with_option: "{{ lookup('namespace.collection_name.file', '/etc/foo.txt', option1='donothing') }}" - tasks: - - - debug: - msg: the value of foo.txt is {{ contents }} as seen today {{ lookup('pipe', 'date +"%Y-%m-%d"') }} - - -For example lookup plugins, see the source code for the `lookup plugins included with Ansible Core `_. - -For more usage examples of lookup plugins, see :ref:`Using Lookups`. - -.. _developing_test_plugins: - -Test plugins ------------- - -Test plugins verify data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the test plugins shipped with Ansible reside in a ``core.py``. These are specially useful in conjunction with some filter plugins like ``map`` and ``select``; they are also available for conditional directives like ``when:``. - -Test plugins do not use the standard configuration system described above. Since ansible-core 2.14 test plugins can use plain documentation. - -Since Ansible evaluates variables only when they are needed, test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary. - -.. code-block:: python - - try: - cause_an_exception(with_undefined_variable) - except jinja2.exceptions.UndefinedError as e: - raise AnsibleUndefinedVariable("Something happened, this was the original exception: %s" % to_native(e)) - except Exception as e: - raise AnsibleFilterError("Something happened, this was the original exception: %s" % to_native(e)) - -For example test plugins, see the source code for the `test plugins included with Ansible Core `_. - -.. _developing_vars_plugins: - -Vars plugins ------------- - -Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins. - -Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are supported by collections starting with Ansible 2.10. - -Older plugins used a ``run`` method as their main body/work: - -.. code-block:: python - - def run(self, name, vault_password=None): - pass # your code goes here - - -Ansible 2.0 did not pass passwords to older plugins, so vaults were unavailable. -Most of the work now happens in the ``get_vars`` method which is called from the VariableManager when needed. - -.. code-block:: python - - def get_vars(self, loader, path, entities): - pass # your code goes here - -The parameters are: - - * loader: Ansible's DataLoader. The DataLoader can read files, auto-load JSON/YAML and decrypt vaulted data, and cache read files. - * path: this is 'directory data' for every inventory source and the current play's playbook directory, so they can search for data in reference to them. ``get_vars`` will be called at least once per available path. - * entities: these are host or group names that are pertinent to the variables needed. The plugin will get called once for hosts and again for groups. - -This ``get_vars`` method just needs to return a dictionary structure with the variables. - -Since Ansible version 2.4, vars plugins only execute as needed when preparing to execute a task. This avoids the costly 'always execute' behavior that occurred during inventory construction in older versions of Ansible. Since Ansible version 2.10, vars plugin execution can be toggled by the user to run when preparing to execute a task or after importing an inventory source. - -The user must explicitly enable vars plugins that reside in a collection. See :ref:`enable_vars` for details. - -Legacy vars plugins are always loaded and run by default. You can prevent them from automatically running by setting ``REQUIRES_ENABLED`` to True. - -.. code-block:: python - - class VarsModule(BaseVarsPlugin): - REQUIRES_ENABLED = True - -Include the ``vars_plugin_staging`` documentation fragment to allow users to determine when vars plugins run. - -.. code-block:: python - - DOCUMENTATION = ''' - name: custom_hostvars - version_added: "2.10" # for collections, use the collection version, not the Ansible version - short_description: Load custom host vars - description: Load custom host vars - options: - stage: - ini: - - key: stage - section: vars_custom_hostvars - env: - - name: ANSIBLE_VARS_PLUGIN_STAGE - extends_documentation_fragment: - - vars_plugin_staging - ''' - -For example vars plugins, see the source code for the `vars plugins included with Ansible Core -`_. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_api` - Learn about the Python API for task execution - :ref:`developing_inventory` - Learn about how to develop dynamic inventory sources - :ref:`developing_modules_general` - Learn about how to write Ansible modules - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels - :ref:`adjacent_yaml_doc` - Alternate YAML files as documentation diff --git a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst deleted file mode 100644 index e858103d6bd..00000000000 --- a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst +++ /dev/null @@ -1,923 +0,0 @@ -.. _flow_modules: -.. _developing_program_flow_modules: - -*************************** -Ansible module architecture -*************************** - -If you are working on the ``ansible-core`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section. - -.. contents:: - :local: - -.. _flow_types_of_modules: - -Types of modules -================ - -Ansible supports several different types of modules in its code base. Some of -these are for backwards compatibility and others are to enable flexibility. - -.. _flow_action_plugins: - -Action plugins --------------- - -Action plugins look like modules to anyone writing a playbook. Usage documentation for most action plugins lives inside a module of the same name. Some action plugins do all the work, with the module providing only documentation. Some action plugins execute modules. The ``normal`` action plugin executes modules that don't have special action plugins. Action plugins always execute on the controller. - -Some action plugins do all their work on the controller. For -example, the :ref:`debug ` action plugin (which prints text for -the user to see) and the :ref:`assert ` action plugin (which -tests whether values in a playbook satisfy certain criteria) execute entirely on the controller. - -Most action plugins set up some values on the controller, then invoke an -actual module on the managed node that does something with these values. For example, the :ref:`template ` action plugin takes values from -the user to construct a file in a temporary location on the controller using -variables from the playbook environment. It then transfers the temporary file -to a temporary file on the remote system. After that, it invokes the -:ref:`copy module ` which operates on the remote system to move the file -into its final location, sets file permissions, and so on. - -.. _flow_new_style_modules: - -New-style modules ------------------ - -All of the modules that ship with Ansible fall into this category. While you can write modules in any language, all official modules (shipped with Ansible) use either Python or PowerShell. - -New-style modules have the arguments to the module embedded inside of them in -some manner. Old-style modules must copy a separate file over to the -managed node, which is less efficient as it requires two over-the-wire -connections instead of only one. - -.. _flow_python_modules: - -Python -^^^^^^ - -New-style Python modules use the :ref:`Ansiballz` framework for constructing -modules. These modules use imports from :code:`ansible.module_utils` to pull in -boilerplate module code, such as argument parsing, formatting of return -values as :term:`JSON`, and various file operations. - -.. note:: In Ansible, up to version 2.0.x, the official Python modules used the - :ref:`module_replacer` framework. For module authors, :ref:`Ansiballz` is - largely a superset of :ref:`module_replacer` functionality, so you usually - do not need to understand the differences between them. - -.. _flow_powershell_modules: - -PowerShell -^^^^^^^^^^ - -New-style PowerShell modules use the :ref:`module_replacer` framework for -constructing modules. These modules get a library of PowerShell code embedded -in them before being sent to the managed node. - -.. _flow_jsonargs_modules: - -JSONARGS modules ----------------- - -These modules are scripts that include the string -``<>`` in their body. -This string is replaced with the JSON-formatted argument string. These modules typically set a variable to that value like this: - -.. code-block:: python - - json_arguments = """<>""" - -Which is expanded as: - -.. code-block:: python - - json_arguments = """{"param1": "test's quotes", "param2": "\"To be or not to be\" - Hamlet"}""" - -.. note:: Ansible outputs a :term:`JSON` string with bare quotes. Double quotes are - used to quote string values, double quotes inside of string values are - backslash escaped, and single quotes may appear unescaped inside of - a string value. To use JSONARGS, your scripting language must have a way - to handle this type of string. The example uses Python's triple quoted - strings to do this. Other scripting languages may have a similar quote - character that won't be confused by any quotes in the JSON or it may - allow you to define your own start-of-quote and end-of-quote characters. - If the language doesn't give you any of these then you'll need to write - a :ref:`non-native JSON module ` or - :ref:`Old-style module ` instead. - -These modules typically parse the contents of ``json_arguments`` using a JSON -library and then use them as native variables throughout the code. - -.. _flow_want_json_modules: - -Non-native want JSON modules ----------------------------- - -If a module has the string ``WANT_JSON`` in it anywhere, Ansible treats -it as a non-native module that accepts a filename as its only command-line -parameter. The filename is for a temporary file containing a :term:`JSON` -string containing the module's parameters. The module needs to open the file, -read and parse the parameters, operate on the data, and print its return data -as a JSON encoded dictionary to stdout before exiting. - -These types of modules are self-contained entities. As of Ansible 2.1, Ansible -only modifies them to change a shebang line if present. - -.. seealso:: Examples of Non-native modules written in ruby are in the `Ansible - for Rubyists `_ repository. - -.. _flow_binary_modules: - -Binary modules --------------- - -From Ansible 2.2 onwards, modules may also be small binary programs. Ansible -doesn't perform any magic to make these portable to different systems so they -may be specific to the system on which they were compiled or require other -binary runtime dependencies. Despite these drawbacks, you may have -to compile a custom module against a specific binary -library if that's the only way to get access to certain resources. - -Binary modules take their arguments and return data to Ansible in the same -way as :ref:`want JSON modules `. - -.. seealso:: One example of a `binary module - `_ - written in go. - -.. _flow_old_style_modules: - -Old-style modules ------------------ - -Old-style modules are similar to -:ref:`want JSON modules `, except that the file that -they take contains ``key=value`` pairs for their parameters instead of -:term:`JSON`. Ansible decides that a module is old-style when it doesn't have -any of the markers that would show that it is one of the other types. - -.. _flow_how_modules_are_executed: - -How modules are executed -======================== - -When a user uses :program:`ansible` or :program:`ansible-playbook`, they -specify a task to execute. The task is usually the name of a module along -with several parameters to be passed to the module. Ansible takes these -values and processes them in various ways before they are finally executed on -the remote machine. - -.. _flow_executor_task_executor: - -Executor/task_executor ----------------------- - -The TaskExecutor receives the module name and parameters that were parsed from -the :term:`playbook ` (or from the command-line in the case of -:command:`/usr/bin/ansible`). It uses the name to decide whether it's looking -at a module or an :ref:`Action Plugin `. If it's -a module, it loads the :ref:`Normal Action Plugin ` -and passes the name, variables, and other information about the task and play -to that Action Plugin for further processing. - -.. _flow_normal_action_plugin: - -The ``normal`` action plugin ----------------------------- - -The ``normal`` action plugin executes the module on the remote host. It is -the primary coordinator of much of the work to actually execute the module on -the managed machine. - -* It loads the appropriate connection plugin for the task, which then transfers - or executes as needed to create a connection to that host. -* It adds any internal Ansible properties to the module's parameters (for - instance, the ones that pass along ``no_log`` to the module). -* It works with other plugins (connection, shell, become, other action plugins) - to create any temporary files on the remote machine and - cleans up afterwards. -* It pushes the module and module parameters to the - remote host, although the :ref:`module_common ` - code described in the next section decides which format - those will take. -* It handles any special cases regarding modules (for instance, async - execution, or complications around Windows modules that must have the same names as Python modules, so that internal calling of modules from other Action Plugins work.) - -Much of this functionality comes from the `BaseAction` class, -which lives in :file:`plugins/action/__init__.py`. It uses the -``Connection`` and ``Shell`` objects to do its work. - -.. note:: - When :term:`tasks ` are run with the ``async:`` parameter, Ansible - uses the ``async`` Action Plugin instead of the ``normal`` Action Plugin - to invoke it. That program flow is currently not documented. Read the - source for information on how that works. - -.. _flow_executor_module_common: - -Executor/module_common.py -------------------------- - -Code in :file:`executor/module_common.py` assembles the module -to be shipped to the managed node. The module is first read in, then examined -to determine its type: - -* :ref:`PowerShell ` and :ref:`JSON-args modules ` are passed through :ref:`Module Replacer `. -* New-style :ref:`Python modules ` are assembled by :ref:`Ansiballz`. -* :ref:`Non-native-want-JSON `, :ref:`Binary modules `, and :ref:`Old-Style modules ` aren't touched by either of these and pass through unchanged. - -After the assembling step, one final -modification is made to all modules that have a shebang line. Ansible checks -whether the interpreter in the shebang line has a specific path configured via -an ``ansible_$X_interpreter`` inventory variable. If it does, Ansible -substitutes that path for the interpreter path given in the module. After -this, Ansible returns the complete module data and the module type to the -:ref:`Normal Action ` which continues execution of -the module. - -Assembler frameworks --------------------- - -Ansible supports two assembler frameworks: Ansiballz and the older Module Replacer. - -.. _module_replacer: - -Module Replacer framework -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Module Replacer framework is the original framework implementing new-style -modules, and is still used for PowerShell modules. It is essentially a preprocessor (like the C Preprocessor for those -familiar with that programming language). It does straight substitutions of -specific substring patterns in the module file. There are two types of -substitutions: - -* Replacements that only happen in the module file. These are public - replacement strings that modules can utilize to get helpful boilerplate or - access to arguments. - - - :code:`from ansible.module_utils.MOD_LIB_NAME import *` is replaced with the - contents of the :file:`ansible/module_utils/MOD_LIB_NAME.py` These should - only be used with :ref:`new-style Python modules `. - - :code:`#<>` is equivalent to - :code:`from ansible.module_utils.basic import *` and should also only apply - to new-style Python modules. - - :code:`# POWERSHELL_COMMON` substitutes the contents of - :file:`ansible/module_utils/powershell.ps1`. It should only be used with - :ref:`new-style Powershell modules `. - -* Replacements that are used by ``ansible.module_utils`` code. These are internal replacement patterns. They may be used internally, in the above public replacements, but shouldn't be used directly by modules. - - - :code:`"<>"` is substituted with the Ansible version. In - :ref:`new-style Python modules ` under the - :ref:`Ansiballz` framework the proper way is to instead instantiate an - `AnsibleModule` and then access the version from - :attr:``AnsibleModule.ansible_version``. - - :code:`"<>"` is substituted with - a string which is the Python ``repr`` of the :term:`JSON` encoded module - parameters. Using ``repr`` on the JSON string makes it safe to embed in - a Python file. In new-style Python modules under the Ansiballz framework - this is better accessed by instantiating an `AnsibleModule` and - then using :attr:`AnsibleModule.params`. - - :code:`<>` substitutes a string which is - a comma-separated list of file systems which have a file system dependent - security context in SELinux. In new-style Python modules, if you really - need this you should instantiate an `AnsibleModule` and then use - :attr:`AnsibleModule._selinux_special_fs`. The variable has also changed - from a comma-separated string of file system names to an actual python - list of file system names. - - :code:`<>` substitutes the module - parameters as a JSON string. Care must be taken to properly quote the - string as JSON data may contain quotes. This pattern is not substituted - in new-style Python modules as they can get the module parameters another - way. - - The string :code:`syslog.LOG_USER` is replaced wherever it occurs with the - ``syslog_facility`` which was named in :file:`ansible.cfg` or any - ``ansible_syslog_facility`` inventory variable that applies to this host. In - new-style Python modules this has changed slightly. If you really need to - access it, you should instantiate an `AnsibleModule` and then use - :attr:`AnsibleModule._syslog_facility` to access it. It is no longer the - actual syslog facility and is now the name of the syslog facility. See - the :ref:`documentation on internal arguments ` - for details. - -.. _Ansiballz: - -Ansiballz framework -^^^^^^^^^^^^^^^^^^^ - -The Ansiballz framework was adopted in Ansible 2.1 and is used for all new-style Python modules. Unlike the Module Replacer, Ansiballz uses real Python imports of things in -:file:`ansible/module_utils` instead of merely preprocessing the module. It -does this by constructing a zipfile -- which includes the module file, files -in :file:`ansible/module_utils` that are imported by the module, and some -boilerplate to pass in the module's parameters. The zipfile is then Base64 -encoded and wrapped in a small Python script which decodes the Base64 encoding -and places the zipfile into a temp directory on the managed node. It then -extracts just the Ansible module script from the zip file and places that in -the temporary directory as well. Then it sets the PYTHONPATH to find Python -modules inside of the zip file and imports the Ansible module as the special name, ``__main__``. -Importing it as ``__main__`` causes Python to think that it is executing a script rather than simply -importing a module. This lets Ansible run both the wrapper script and the module code in a single copy of Python on the remote machine. - -.. note:: - * Ansible wraps the zipfile in the Python script for two reasons: - - * for compatibility with Python 2.6 which has a less - functional version of Python's ``-m`` command-line switch. - - * so that pipelining will function properly. Pipelining needs to pipe the - Python module into the Python interpreter on the remote node. Python - understands scripts on stdin but does not understand zip files. - - * Prior to Ansible 2.7, the module was executed by a second Python interpreter instead of being - executed inside of the same process. This change was made once Python-2.4 support was dropped - to speed up module execution. - -In Ansiballz, any imports of Python modules from the -:py:mod:`ansible.module_utils` package trigger inclusion of that Python file -into the zipfile. Instances of :code:`#<>` in -the module are turned into :code:`from ansible.module_utils.basic import *` -and :file:`ansible/module-utils/basic.py` is then included in the zipfile. -Files that are included from :file:`module_utils` are themselves scanned for -imports of other Python modules from :file:`module_utils` to be included in -the zipfile as well. - - -.. _flow_passing_module_args: - -Passing args ------------- - -Arguments are passed differently by the two frameworks: - -* In :ref:`module_replacer`, module arguments are turned into a JSON-ified string and substituted into the combined module file. -* In :ref:`Ansiballz`, the JSON-ified string is part of the script which wraps the zipfile. Just before the wrapper script imports the Ansible module as ``__main__``, it monkey-patches the private, ``_ANSIBLE_ARGS`` variable in ``basic.py`` with the variable values. When a :class:`ansible.module_utils.basic.AnsibleModule` is instantiated, it parses this string and places the args into :attr:`AnsibleModule.params` where it can be accessed by the module's other code. - -.. warning:: - If you are writing modules, remember that the way we pass arguments is an internal implementation detail: it has changed in the past and will change again as soon as changes to the common module_utils - code allow Ansible modules to forgo using :class:`ansible.module_utils.basic.AnsibleModule`. Do not rely on the internal global ``_ANSIBLE_ARGS`` variable. - - Very dynamic custom modules which need to parse arguments before they - instantiate an ``AnsibleModule`` may use ``_load_params`` to retrieve those parameters. - Although ``_load_params`` may change in breaking ways if necessary to support - changes in the code, it is likely to be more stable than either the way we pass parameters or the internal global variable. - -.. note:: - Prior to Ansible 2.7, the Ansible module was invoked in a second Python interpreter and the - arguments were then passed to the script over the script's stdin. - - -.. _flow_internal_arguments: - -Internal arguments ------------------- - -Both :ref:`module_replacer` and :ref:`Ansiballz` send additional arguments to -the Ansible module beyond those which the user specified in the playbook. These -additional arguments are internal parameters that help implement global -Ansible features. Modules often do not need to know about these explicitly because -the features are implemented in :py:mod:`ansible.module_utils.basic`. However, certain -features need support from modules and some knowledge of the internal arguments is useful. - -The internal arguments in this section are global. If you need to add a local internal argument to a custom module, create an action plugin for that specific module. See ``_original_basename`` in the `copy action plugin `_ for an example. - - -_ansible_no_log -^^^^^^^^^^^^^^^ - -Type: ``bool`` - -Set to ``True`` whenever an argument in a task or play specifies ``no_log``. Any module that calls the :py:meth:`AnsibleModule.log` function handles this action automatically. If you have a module that implements its own logging then you need to check the value of ``_ansible_no_log``. To access ``_ansible_no_log`` in a module, instantiate the ``AnsibleModule`` utility and then check the value of :attr:`AnsibleModule.no_log`. - -.. note:: - ``no_log`` specified in a module's ``argument_spec`` is handled by a different mechanism. - - -_ansible_debug -^^^^^^^^^^^^^^ - -Type: ``bool`` - -Operates verbose logging and logging of external commands that a module executes. If the module uses the :py:meth:`AnsibleModule.debug` function rather than the :py:meth:`AnsibleModule.log` function then the messages are only logged if you set the ``_ansible_debug`` argument to ``True``. To access ``_ansible_debug`` in a module, instantiate the ``AnsibleModule`` utility and access :attr:`AnsibleModule._debug`. For more details, see :ref:`DEFAULT_DEBUG`. - - -_ansible_diff -^^^^^^^^^^^^^ - -Type: ``bool`` - -With this parameter you can configure your module to show a unified diff of changes that will be applied to the templated files. To access ``_ansible_diff`` in a module, instantiate the ``AnsibleModule`` utility and access :attr:`AnsibleModule._diff`. You can also access this parameter using the ``diff`` keyword in your playbook, or the relevant environment variable. For more details, see :ref:`playbook_keywords` and the :ref:`DIFF_ALWAYS` configuration option. - - -_ansible_verbosity -^^^^^^^^^^^^^^^^^^ - -Type: ``int`` - -You can use this argument to control the level (0 for none) of verbosity in logging. - - -_ansible_selinux_special_fs -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Type: ``list`` -Elements: ``strings`` - -This argument provides modules with the names of file systems which should have a special SELinux context. They are used by the ``AnsibleModule`` methods which operate on files (changing attributes, moving, and copying). - -Most modules can use the built-in ``AnsibleModule`` methods to manipulate files. To access in a module that needs to know about these special context file systems, instantiate ``AnsibleModule`` and examine the list in :attr:`AnsibleModule._selinux_special_fs`. - -This argument replaces :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` from :ref:`module_replacer`. In the module replacer framework the argument was formatted as a comma-separated string of file system names. Under the Ansiballz framework it is a list. You can access ``_ansible_selinux_special_fs`` using the corresponding environment variable. For more details, see the :ref:`DEFAULT_SELINUX_SPECIAL_FS` configuration option. - -.. versionadded:: 2.1 - - -_ansible_syslog_facility -^^^^^^^^^^^^^^^^^^^^^^^^ - -This argument controls which syslog facility the module logs to. Most modules should just use the :meth:`AnsibleModule.log` function which will then make use of this. If a module has to use this on its own, it should instantiate the ``AnsibleModule`` method and then retrieve the name of the syslog facility from :attr:`AnsibleModule._syslog_facility`. The Ansiballz code is less elegant than the :ref:`module_replacer` code: - -.. code-block:: python - - # Old module_replacer way - import syslog - syslog.openlog(NAME, 0, syslog.LOG_USER) - - # New Ansiballz way - import syslog - facility_name = module._syslog_facility - facility = getattr(syslog, facility_name, syslog.LOG_USER) - syslog.openlog(NAME, 0, facility) - -For more details, see the :ref:`DEFAULT_SYSLOG_FACILITY` configuration option. - -.. versionadded:: 2.1 - - -_ansible_version -^^^^^^^^^^^^^^^^ - -This argument passes the version of Ansible to the module. To access it, a module should instantiate the ``AnsibleModule`` method and then retrieve the version from :attr:`AnsibleModule.ansible_version`. This replaces :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from :ref:`module_replacer`. - -.. versionadded:: 2.1 - - -_ansible_module_name -^^^^^^^^^^^^^^^^^^^^ - -Type: ``str`` - -This argument passes the information to modules about their name. For more details see, the configuration option :ref:`DEFAULT_MODULE_NAME`. - - -_ansible_string_conversion_action -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This argument provides instructions about what modules should do after the values of the user-specified module parameters are converted to strings. For more details, see the :ref:`STRING_CONVERSION_ACTION` configuration option. - - -_ansible_keep_remote_files -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Type: ``bool`` - -This argument provides instructions that modules must be ready if they need to keep the remote files. For more details, see the :ref:`DEFAULT_KEEP_REMOTE_FILES` configuration option. - - -_ansible_socket -^^^^^^^^^^^^^^^ -This argument provides modules with a socket for persistent connections. The argument is created using the :ref:`PERSISTENT_CONTROL_PATH_DIR` configuration option. - - -_ansible_shell_executable -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Type: ``bool`` - -This argument ensures that modules use the designated shell executable. For more details, see the :ref:`ansible_shell_executable` remote host environment parameter. - - -_ansible_tmpdir -^^^^^^^^^^^^^^^ - -Type: ``str`` - -This argument provides instructions to modules that all commands must use the designated temporary directory, if created. The action plugin designs this temporary directory. - -Modules can access this parameter by using the public ``tmpdir`` property. The ``tmpdir`` property will create a temporary directory if the action plugin did not set the parameter. - -The directory name is generated randomly, and the the root of the directory is determined by one of these: - -* :ref:`DEFAULT_LOCAL_TMP` -* `remote_tmp `_ -* `system_tmpdirs `_ - -As a result, using the ``ansible.cfg`` configuration file to activate or customize this setting will not guarantee that you control the full value. - - -_ansible_remote_tmp -^^^^^^^^^^^^^^^^^^^ - -The module's ``tmpdir`` property creates a randomized directory name in this directory if the action plugin did not set ``_ansible_tmpdir``. For more details, see the `remote_tmp `_ parameter of the shell plugin. - - -.. _flow_module_return_values: - -Module return values & Unsafe strings -------------------------------------- - -At the end of a module's execution, it formats the data that it wants to return as a JSON string and prints the string to its stdout. The normal action plugin receives the JSON string, parses it into a Python dictionary, and returns it to the executor. - -If Ansible templated every string return value, it would be vulnerable to an attack from users with access to managed nodes. If an unscrupulous user disguised malicious code as Ansible return value strings, and if those strings were then templated on the controller, Ansible could execute arbitrary code. To prevent this scenario, Ansible marks all strings inside returned data as ``Unsafe``, emitting any Jinja2 templates in the strings verbatim, not expanded by Jinja2. - -Strings returned by invoking a module through ``ActionPlugin._execute_module()`` are automatically marked as ``Unsafe`` by the normal action plugin. If another action plugin retrieves information from a module through some other means, it must mark its return data as ``Unsafe`` on its own. - -In case a poorly-coded action plugin fails to mark its results as "Unsafe," Ansible audits the results again when they are returned to the executor, -marking all strings as ``Unsafe``. The normal action plugin protects itself and any other code that it calls with the result data as a parameter. The check inside the executor protects the output of all other action plugins, ensuring that subsequent tasks run by Ansible will not template anything from those results either. - -.. _flow_special_considerations: - -Special considerations ----------------------- - -.. _flow_pipelining: - -Pipelining -^^^^^^^^^^ - -Ansible can transfer a module to a remote machine in one of two ways: - -* it can write out the module to a temporary file on the remote host and then - use a second connection to the remote host to execute it with the - interpreter that the module needs -* or it can use what's known as pipelining to execute the module by piping it - into the remote interpreter's stdin. - -Pipelining only works with modules written in Python at this time because -Ansible only knows that Python supports this mode of operation. Supporting -pipelining means that whatever format the module payload takes before being -sent over the wire must be executable by Python through stdin. - -.. _flow_args_over_stdin: - -Why pass args over stdin? -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Passing arguments through stdin was chosen for the following reasons: - -* When combined with :ref:`ANSIBLE_PIPELINING`, this keeps the module's arguments from - temporarily being saved onto disk on the remote machine. This makes it - harder (but not impossible) for a malicious user on the remote machine to - steal any sensitive information that may be present in the arguments. -* Command line arguments would be insecure as most systems allow unprivileged - users to read the full commandline of a process. -* Environment variables are usually more secure than the commandline but some - systems limit the total size of the environment. This could lead to - truncation of the parameters if we hit that limit. - - -.. _flow_ansiblemodule: - -AnsibleModule -------------- - -.. _argument_spec: - -Argument spec -^^^^^^^^^^^^^ - -The ``argument_spec`` provided to ``AnsibleModule`` defines the supported arguments for a module, as well as their type, defaults and more. - -Example ``argument_spec``: - -.. code-block:: python - - module = AnsibleModule(argument_spec=dict( - top_level=dict( - type='dict', - options=dict( - second_level=dict( - default=True, - type='bool', - ) - ) - ) - )) - -This section will discuss the behavioral attributes for arguments: - -:type: - - ``type`` allows you to define the type of the value accepted for the argument. The default value for ``type`` is ``str``. Possible values are: - - * str - * list - * dict - * bool - * int - * float - * path - * raw - * jsonarg - * json - * bytes - * bits - - The ``raw`` type, performs no type validation or type casting, and maintains the type of the passed value. - -:elements: - - ``elements`` works in combination with ``type`` when ``type='list'``. ``elements`` can then be defined as ``elements='int'`` or any other type, indicating that each element of the specified list should be of that type. - -:default: - - The ``default`` option allows sets a default value for the argument for the scenario when the argument is not provided to the module. When not specified, the default value is ``None``. - -:fallback: - - ``fallback`` accepts a ``tuple`` where the first argument is a callable (function) that will be used to perform the lookup, based on the second argument. The second argument is a list of values to be accepted by the callable. - - The most common callable used is ``env_fallback`` which will allow an argument to optionally use an environment variable when the argument is not supplied. - - Example: - - .. code-block:: python - - username=dict(fallback=(env_fallback, ['ANSIBLE_NET_USERNAME'])) - -:choices: - - ``choices`` accepts a list of choices that the argument will accept. The types of ``choices`` should match the ``type``. - -:required: - - ``required`` accepts a boolean, either ``True`` or ``False`` that indicates that the argument is required. When not specified, ``required`` defaults to ``False``. This should not be used in combination with ``default``. - -:no_log: - - ``no_log`` accepts a boolean, either ``True`` or ``False``, that indicates explicitly whether or not the argument value should be masked in logs and output. - - .. note:: - In the absence of ``no_log``, if the parameter name appears to indicate that the argument value is a password or passphrase (such as "admin_password"), a warning will be shown and the value will be masked in logs but **not** output. To disable the warning and masking for parameters that do not contain sensitive information, set ``no_log`` to ``False``. - -:aliases: - - ``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name`` - -:options: - - ``options`` implements the ability to create a sub-argument_spec, where the sub options of the top level argument are also validated using the attributes discussed in this section. The example at the top of this section demonstrates use of ``options``. ``type`` or ``elements`` should be ``dict`` is this case. - -:apply_defaults: - - ``apply_defaults`` works alongside ``options`` and allows the ``default`` of the sub-options to be applied even when the top-level argument is not supplied. - - In the example of the ``argument_spec`` at the top of this section, it would allow ``module.params['top_level']['second_level']`` to be defined, even if the user does not provide ``top_level`` when calling the module. - -:removed_in_version: - - ``removed_in_version`` indicates which version of ansible-core or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``. - - Example: - - .. code-block:: python - - option = { - 'type': 'str', - 'removed_in_version': '2.0.0', - 'removed_from_collection': 'testns.testcol', - }, - -:removed_at_date: - - ``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-core release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``. - - Example: - - .. code-block:: python - - option = { - 'type': 'str', - 'removed_at_date': '2020-12-31', - 'removed_from_collection': 'testns.testcol', - }, - -:removed_from_collection: - - Specifies which collection (or ansible-core) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``. - -:deprecated_aliases: - - Deprecates aliases of this argument. Must contain a list or tuple of dictionaries having some the following keys: - - :name: - - The name of the alias to deprecate. (Required.) - - :version: - - The version of ansible-core or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified. - - :date: - - The a date after which a minor release of ansible-core or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified. - - :collection_name: - - Specifies which collection (or ansible-core) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``. - - Examples: - - .. code-block:: python - - option = { - 'type': 'str', - 'aliases': ['foo', 'bar'], - 'depecated_aliases': [ - { - 'name': 'foo', - 'version': '2.0.0', - 'collection_name': 'testns.testcol', - }, - { - 'name': 'foo', - 'date': '2020-12-31', - 'collection_name': 'testns.testcol', - }, - ], - }, - - -:mutually_exclusive: - - If ``options`` is specified, ``mutually_exclusive`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_together: - - If ``options`` is specified, ``required_together`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_one_of: - - If ``options`` is specified, ``required_one_of`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_if: - - If ``options`` is specified, ``required_if`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - -:required_by: - - If ``options`` is specified, ``required_by`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`. - - -.. _argument_spec_dependencies: - -Dependencies between module options -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following are optional arguments for ``AnsibleModule()``: - -.. code-block:: python - - module = AnsibleModule( - argument_spec, - mutually_exclusive=[ - ('path', 'content'), - ], - required_one_of=[ - ('path', 'content'), - ], - ) - -:mutually_exclusive: - - Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are mutually exclusive. If more than one options of a list are specified together, Ansible will fail the module with an error. - - Example: - - .. code-block:: python - - mutually_exclusive=[ - ('path', 'content'), - ('repository_url', 'repository_filename'), - ], - - In this example, the options ``path`` and ``content`` must not specified at the same time. Also the options ``repository_url`` and ``repository_filename`` must not be specified at the same time. But specifying ``path`` and ``repository_url`` is accepted. - - To ensure that precisely one of two (or more) options is specified, combine ``mutually_exclusive`` with ``required_one_of``. - -:required_together: - - Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are must be specified together. If at least one of these options are specified, the other ones from the same sequence must all be present. - - Example: - - .. code-block:: python - - required_together=[ - ('file_path', 'file_hash'), - ], - - In this example, if one of the options ``file_path`` or ``file_hash`` is specified, Ansible will fail the module with an error if the other one is not specified. - -:required_one_of: - - Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names from which at least one must be specified. If none one of these options are specified, Ansible will fail module execution. - - Example: - - .. code-block:: python - - required_one_of=[ - ('path', 'content'), - ], - - In this example, at least one of ``path`` and ``content`` must be specified. If none are specified, execution will fail. Specifying both is explicitly allowed; to prevent this, combine ``required_one_of`` with ``mutually_exclusive``. - -:required_if: - - Must be a sequence of sequences. Every inner sequence describes one conditional dependency. Every sequence must have three or four values. The first two values are the option's name and the option's value which describes the condition. The further elements of the sequence are only needed if the option of that name has precisely this value. - - If you want that all options in a list of option names are specified if the condition is met, use one of the following forms: - - .. code-block:: python - - ('option_name', option_value, ('option_a', 'option_b', ...)), - ('option_name', option_value, ('option_a', 'option_b', ...), False), - - If you want that at least one option of a list of option names is specified if the condition is met, use the following form: - - .. code-block:: python - - ('option_name', option_value, ('option_a', 'option_b', ...), True), - - Example: - - .. code-block:: python - - required_if=[ - ('state', 'present', ('path', 'content'), True), - ('force', True, ('force_reason', 'force_code')), - ], - - In this example, if the user specifies ``state=present``, at least one of the options ``path`` and ``content`` must be supplied (or both). To make sure that precisely one can be specified, combine ``required_if`` with ``mutually_exclusive``. - - On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` and so on, both ``force_reason`` and ``force_code`` must be specified. - -:required_by: - - Must be a dictionary mapping option names to sequences of option names. If the option name in a dictionary key is specified, the option names it maps to must all also be specified. Note that instead of a sequence of option names, you can also specify one single option name. - - Example: - - .. code-block:: python - - required_by={ - 'force': 'force_reason', - 'path': ('mode', 'owner', 'group'), - }, - - In the example, if ``force`` is specified, ``force_reason`` must also be specified. Also, if ``path`` is specified, then three three options ``mode``, ``owner`` and ``group`` also must be specified. - -Declaring check mode support -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To declare that a module supports check mode, supply ``supports_check_mode=True`` to the ``AnsibleModule()`` call: - -.. code-block:: python - - module = AnsibleModule(argument_spec, supports_check_mode=True) - -The module can determine whether it is called in check mode by checking the boolean value ``module.check_mode``. If it evaluates to ``True``, the module must take care not to do any modification. - -If ``supports_check_mode=False`` is specified, which is the default value, the module will exit in check mode with ``skipped=True`` and message ``remote module () does not support check mode``. - -Adding file options -^^^^^^^^^^^^^^^^^^^ - -To declare that a module should add support for all common file options, supply ``add_file_common_args=True`` to the ``AnsibleModule()`` call: - -.. code-block:: python - - module = AnsibleModule(argument_spec, add_file_common_args=True) - -You can find `a list of all file options here `_. It is recommended that you make your ``DOCUMENTATION`` extend the doc fragment ``ansible.builtin.files`` (see :ref:`module_docs_fragments`) in this case, to make sure that all these fields are correctly documented. - -The helper functions ``module.load_file_common_arguments()`` and ``module.set_fs_attributes_if_different()`` can be used to handle these arguments for you: - -.. code-block:: python - - argument_spec = { - 'path': { - 'type': 'str', - 'required': True, - }, - } - - module = AnsibleModule(argument_spec, add_file_common_args=True) - changed = False - - # TODO do something with module.params['path'], like update it's contents - - # Ensure that module.params['path'] satisfies the file options supplied by the user - file_args = module.load_file_common_arguments(module.params) - changed = module.set_fs_attributes_if_different(file_args, changed) - - module.exit_json(changed=changed) diff --git a/docs/docsite/rst/dev_guide/developing_python_3.rst b/docs/docsite/rst/dev_guide/developing_python_3.rst deleted file mode 100644 index 74385c43f9d..00000000000 --- a/docs/docsite/rst/dev_guide/developing_python_3.rst +++ /dev/null @@ -1,393 +0,0 @@ -.. _developing_python_3: - -******************** -Ansible and Python 3 -******************** - -The ``ansible-core`` code runs Python 3 (for specific versions check :ref:`Control Node Requirements ` -Contributors to ``ansible-core`` and to Ansible Collections should be aware of the tips in this document so that they can write code -that will run on the same versions of Python as the rest of Ansible. - -.. contents:: - :local: - -We do have some considerations depending on the types of Ansible code: - -1. controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`, only needs to support the controller's Python versions. -2. modules - the code which Ansible transmits to and invokes on the managed machine. Modules need to support the 'managed node' Python versions, with some exceptions. -3. shared ``module_utils`` code - the common code that is used by modules to perform tasks and sometimes used by controller-side code as well. Shared ``module_utils`` code needs to support the same range of Python as the modules. - -However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully. - -.. note: - - While modules can be written in any language, the above applies to code contributed to the core project, which only supports specific Python versions and Powershell for Windows. - -Minimum version of Python 3.x and Python 2.x -============================================ - -See :ref:`Control Node Requirements ` and :ref:`Managed Node Requirements ` for the -specific versions supported. - -Your custom modules can support any version of Python (or other languages) you want, but the above are the requirements for the code contributed to the Ansible project. - -Developing Ansible code that supports Python 2 and Python 3 -=========================================================== - -The best place to start learning about writing code that supports both Python 2 and Python 3 -is `Lennart Regebro's book: Porting to Python 3 `_. -The book describes several strategies for porting to Python 3. The one we're -using is `to support Python 2 and Python 3 from a single code base -`_ - -Understanding strings in Python 2 and Python 3 ----------------------------------------------- - -Python 2 and Python 3 handle strings differently, so when you write code that supports Python 3 -you must decide what string model to use. Strings can be an array of bytes (like in C) or -they can be an array of text. Text is what we think of as letters, digits, -numbers, other printable symbols, and a small number of unprintable "symbols" -(control codes). - -In Python 2, the two types for these (:class:`str ` for bytes and -:func:`unicode ` for text) are often used interchangeably. When dealing only -with ASCII characters, the strings can be combined, compared, and converted -from one type to another automatically. When non-ASCII characters are -introduced, Python 2 starts throwing exceptions due to not knowing what encoding -the non-ASCII characters should be in. - -Python 3 changes this behavior by making the separation between bytes (:class:`bytes `) -and text (:class:`str `) more strict. Python 3 will throw an exception when -trying to combine and compare the two types. The programmer has to explicitly -convert from one type to the other to mix values from each. - -In Python 3 it's immediately apparent to the programmer when code is -mixing the byte and text types inappropriately, whereas in Python 2, code that mixes those types -may work until a user causes an exception by entering non-ASCII input. -Python 3 forces programmers to proactively define a strategy for -working with strings in their program so that they don't mix text and byte strings unintentionally. - -Ansible uses different strategies for working with strings in controller-side code, in -:ref: `modules `, and in :ref:`module_utils ` code. - -.. _controller_string_strategy: - -Controller string strategy: the Unicode Sandwich -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Until recently ``ansible-core`` supported Python 2.x and followed this strategy, known as the Unicode Sandwich (named -after Python 2's :func:`unicode ` text type). For Unicode Sandwich we know that -at the border of our code and the outside world (for example, file and network IO, -environment variables, and some library calls) we are going to receive bytes. -We need to transform these bytes into text and use that throughout the -internal portions of our code. When we have to send those strings back out to -the outside world we first convert the text back into bytes. -To visualize this, imagine a 'sandwich' consisting of a top and bottom layer -of bytes, a layer of conversion between, and all text type in the center. - -For compatibility reasons you will see a bunch of custom functions we developed (``to_text``/``to_bytes``/``to_native``) -and while Python 2 is not a concern anymore we will continue to use them as they apply for other cases that make -dealing with unicode problematic. - -While we will not be using it most of it anymore, the documentation below is still useful for those developing modules -that still need to support both Python 2 and 3 simultaneously. - -Unicode Sandwich common borders: places to convert bytes to text in controller code ------------------------------------------------------------------------------------ - -This is a partial list of places where we have to convert to and from bytes -when using the Unicode Sandwich string strategy. It's not exhaustive but -it gives you an idea of where to watch for problems. - -Reading and writing to files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In Python 2, reading from files yields bytes. In Python 3, it can yield text. -To make code that's portable to both we don't make use of Python 3's ability -to yield text but instead do the conversion explicitly ourselves. For example: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_text - - with open('filename-with-utf8-data.txt', 'rb') as my_file: - b_data = my_file.read() - try: - data = to_text(b_data, errors='surrogate_or_strict') - except UnicodeError: - # Handle the exception gracefully -- usually by displaying a good - # user-centric error message that can be traced back to this piece - # of code. - pass - -.. note:: Much of Ansible assumes that all encoded text is UTF-8. At some - point, if there is demand for other encodings we may change that, but for - now it is safe to assume that bytes are UTF-8. - -Writing to files is the opposite process: - -.. code-block:: python - - from ansible.module_utils.common.text.converters import to_bytes - - with open('filename.txt', 'wb') as my_file: - my_file.write(to_bytes(some_text_string)) - -Note that we don't have to catch :exc:`UnicodeError` here because we're -transforming to UTF-8 and all text strings in Python can be transformed back -to UTF-8. - -Filesystem interaction -^^^^^^^^^^^^^^^^^^^^^^ - -Dealing with filenames often involves dropping back to bytes because on UNIX-like -systems filenames are bytes. On Python 2, if we pass a text string to these -functions, the text string will be converted to a byte string inside of the -function and a traceback will occur if non-ASCII characters are present. In -Python 3, a traceback will only occur if the text string can't be decoded in -the current locale, but it's still good to be explicit and have code which -works on both versions: - -.. code-block:: python - - import os.path - - from ansible.module_utils.common.text.converters import to_bytes - - filename = u'/var/tmp/くらとみ.txt' - f = open(to_bytes(filename), 'wb') - mtime = os.path.getmtime(to_bytes(filename)) - b_filename = os.path.expandvars(to_bytes(filename)) - if os.path.exists(to_bytes(filename)): - pass - -When you are only manipulating a filename as a string without talking to the -filesystem (or a C library which talks to the filesystem) you can often get -away without converting to bytes: - -.. code-block:: python - - import os.path - - os.path.join(u'/var/tmp/café', u'くらとみ') - os.path.split(u'/var/tmp/café/くらとみ') - -On the other hand, if the code needs to manipulate the filename and also talk -to the filesystem, it can be more convenient to transform to bytes right away -and manipulate in bytes. - -.. warning:: Make sure all variables passed to a function are the same type. - If you're working with something like :func:`python3:os.path.join` which takes - multiple strings and uses them in combination, you need to make sure that - all the types are the same (either all bytes or all text). Mixing - bytes and text will cause tracebacks. - -Interacting with other programs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Interacting with other programs goes through the operating system and -C libraries and operates on things that the UNIX kernel defines. These -interfaces are all byte-oriented so the Python interface is byte oriented as -well. On both Python 2 and Python 3, byte strings should be given to Python's -subprocess library and byte strings should be expected back from it. - -One of the main places in Ansible's controller code that we interact with -other programs is the connection plugins' ``exec_command`` methods. These -methods transform any text strings they receive in the command (and arguments -to the command) to execute into bytes and return stdout and stderr as byte strings -Higher level functions (like action plugins' ``_low_level_execute_command``) -transform the output into text strings. - -.. _module_string_strategy: - -Module string strategy: Native String -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In modules we use a strategy known as Native Strings. This makes things -easier on the community members who maintain so many of Ansible's -modules, by not breaking backwards compatibility by -mandating that all strings inside of modules are text and converting between -text and bytes at the borders. - -Native strings refer to the type that Python uses when you specify a bare -string literal: - -.. code-block:: python - - "This is a native string" - -In Python 2, these are byte strings. In Python 3 these are text strings. Modules should be -coded to expect bytes on Python 2 and text on Python 3. - -.. _module_utils_string_strategy: - -Module_utils string strategy: hybrid -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In ``module_utils`` code we use a hybrid string strategy. Although Ansible's -``module_utils`` code is largely like module code, some pieces of it are -used by the controller as well. So it needs to be compatible with modules -and with the controller's assumptions, particularly the string strategy. -The module_utils code attempts to accept native strings as input -to its functions and emit native strings as their output. - -In ``module_utils`` code: - -* Functions **must** accept string parameters as either text strings or byte strings. -* Functions may return either the same type of string as they were given or the native string type for the Python version they are run on. -* Functions that return strings **must** document whether they return strings of the same type as they were given or native strings. - -Module-utils functions are therefore often very defensive in nature. -They convert their string parameters into text (using ``ansible.module_utils.common.text.converters.to_text``) -at the beginning of the function, do their work, and then convert -the return values into the native string type (using ``ansible.module_utils.common.text.converters.to_native``) -or back to the string type that their parameters received. - -Tips, tricks, and idioms for Python 2/Python 3 compatibility ------------------------------------------------------------- - -Use forward-compatibility boilerplate -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the following boilerplate code at the top of all python files -to make certain constructs act the same way on Python 2 and Python 3: - -.. code-block:: python - - # Make coding more python3-ish - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - -``__metaclass__ = type`` makes all classes defined in the file into new-style -classes without explicitly inheriting from :class:`object `. - -The ``__future__`` imports do the following: - -:absolute_import: Makes imports look in :data:`sys.path ` for the modules being - imported, skipping the directory in which the module doing the importing - lives. If the code wants to use the directory in which the module doing - the importing, there's a new dot notation to do so. -:division: Makes division of integers always return a float. If you need to - find the quotient use ``x // y`` instead of ``x / y``. -:print_function: Changes :func:`print ` from a keyword into a function. - -.. seealso:: - * `PEP 0328: Absolute Imports `_ - * `PEP 0238: Division `_ - * `PEP 3105: Print function `_ - -Prefix byte strings with ``b_`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Since mixing text and bytes types leads to tracebacks we want to be clear -about what variables hold text and what variables hold bytes. We do this by -prefixing any variable holding bytes with ``b_``. For instance: - -.. code-block:: python - - filename = u'/var/tmp/café.txt' - b_filename = to_bytes(filename) - with open(b_filename) as f: - data = f.read() - -We do not prefix the text strings instead because we only operate -on byte strings at the borders, so there are fewer variables that need bytes -than text. - -Import Ansible's bundled Python ``six`` library -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The third-party Python `six `_ library exists -to help projects create code that runs on both Python 2 and Python 3. Ansible -includes a version of the library in module_utils so that other modules can use it -without requiring that it is installed on the remote system. To make use of -it, import it like this: - -.. code-block:: python - - from ansible.module_utils import six - -.. note:: Ansible can also use a system copy of six - - Ansible will use a system copy of six if the system copy is a later - version than the one Ansible bundles. - -Handle exceptions with ``as`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In order for code to function on Python 2.6+ and Python 3, use the -new exception-catching syntax which uses the ``as`` keyword: - -.. code-block:: python - - try: - a = 2/0 - except ValueError as e: - module.fail_json(msg="Tried to divide by zero: %s" % e) - -Do **not** use the following syntax as it will fail on every version of Python 3: - -.. This code block won't highlight because python2 isn't recognized. This is necessary to pass tests under python 3. -.. code-block:: none - - try: - a = 2/0 - except ValueError, e: - module.fail_json(msg="Tried to divide by zero: %s" % e) - -Update octal numbers -^^^^^^^^^^^^^^^^^^^^ - -In Python 2.x, octal literals could be specified as ``0755``. In Python 3, -octals must be specified as ``0o755``. - -String formatting for controller code -------------------------------------- - -Use ``str.format()`` for Python 2.6 compatibility -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Starting in Python 2.6, strings gained a method called ``format()`` to put -strings together. However, one commonly used feature of ``format()`` wasn't -added until Python 2.7, so you need to remember not to use it in Ansible code: - -.. code-block:: python - - # Does not work in Python 2.6! - new_string = "Dear {}, Welcome to {}".format(username, location) - - # Use this instead - new_string = "Dear {0}, Welcome to {1}".format(username, location) - -Both of the format strings above map positional arguments of the ``format()`` -method into the string. However, the first version doesn't work in -Python 2.6. Always remember to put numbers into the placeholders so the code -is compatible with Python 2.6. - -.. seealso:: - Python documentation on format strings: - - - `format strings in 2.6 `_ - - `format strings in 3.x `_ - -Use percent format with byte strings -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In Python 3.x, byte strings do not have a ``format()`` method. However, it -does have support for the older, percent-formatting. - -.. code-block:: python - - b_command_line = b'ansible-playbook --become-user %s -K %s' % (user, playbook_file) - -.. note:: Percent formatting added in Python 3.5 - - Percent formatting of byte strings was added back into Python 3 in 3.5. - This isn't a problem for us because Python 3.5 is our minimum version. - However, if you happen to be testing Ansible code with Python 3.4 or - earlier, you will find that the byte string formatting here won't work. - Upgrade to Python 3.5 to test. - -.. seealso:: - Python documentation on `percent formatting `_ - -.. _testing_modules_python_3: diff --git a/docs/docsite/rst/dev_guide/developing_rebasing.rst b/docs/docsite/rst/dev_guide/developing_rebasing.rst deleted file mode 100644 index dcd1fb07c43..00000000000 --- a/docs/docsite/rst/dev_guide/developing_rebasing.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. _rebase_guide: - -*********************** -Rebasing a pull request -*********************** - -You may find that your pull request (PR) is out-of-date and needs to be rebased. This can happen for several reasons: - -- Files modified in your PR are in conflict with changes which have already been merged. -- Your PR is old enough that significant changes to automated test infrastructure have occurred. - -Rebasing the branch used to create your PR will resolve both of these issues. - -Configuring your remotes -======================== - -Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork: - -.. code-block:: shell-session - - $ git remote -v - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch) - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (push) - -However, you also need to add a remote which points to the upstream repository: - -.. code-block:: shell-session - - $ git remote add upstream https://github.com/ansible/ansible.git - -Which should leave you with the following remotes: - -.. code-block:: shell-session - - $ git remote -v - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch) - origin git@github.com:YOUR_GITHUB_USERNAME/ansible.git (push) - upstream https://github.com/ansible/ansible.git (fetch) - upstream https://github.com/ansible/ansible.git (push) - -Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote: - -.. code-block:: shell-session - - $ git status - On branch YOUR_BRANCH - Your branch is up-to-date with 'origin/YOUR_BRANCH'. - nothing to commit, working tree clean - -Rebasing your branch -==================== - -Once you have an ``upstream`` remote configured, you can rebase the branch for your PR: - -.. code-block:: shell-session - - $ git pull --rebase upstream devel - -This will replay the changes in your branch on top of the changes made in the upstream ``devel`` branch. -If there are merge conflicts, you will be prompted to resolve those before you can continue. - -After you rebase, the status of your branch changes: - -.. code-block:: shell-session - - $ git status - On branch YOUR_BRANCH - Your branch and 'origin/YOUR_BRANCH' have diverged, - and have 4 and 1 different commits each, respectively. - (use "git pull" to merge the remote branch into yours) - nothing to commit, working tree clean - -Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``. We'll cover what to do next in the following section. - -Updating your pull request -========================== - -Now that you've rebased your branch, you need to push your changes to GitHub to update your PR. - -Since rebasing re-writes git history, you will need to use a force push: - -.. code-block:: shell-session - - $ git push --force-with-lease - -Your PR on GitHub has now been updated. This will automatically trigger testing of your changes. -You should check in on the status of your PR after tests have completed to see if further changes are required. - -Getting help rebasing -===================== - -For help with rebasing your PR, or other development related questions, join us on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - -.. seealso:: - - :ref:`community_development_process` - Information on roadmaps, opening PRs, Ansibullbot, and more diff --git a/docs/docsite/rst/dev_guide/migrating_roles.rst b/docs/docsite/rst/dev_guide/migrating_roles.rst deleted file mode 100644 index ddf79c954ba..00000000000 --- a/docs/docsite/rst/dev_guide/migrating_roles.rst +++ /dev/null @@ -1,416 +0,0 @@ - -.. _migrating_roles: - -************************************************* -Migrating Roles to Roles in Collections on Galaxy -************************************************* - -You can migrate any existing standalone role into a collection and host the collection on Galaxy. With Ansible collections, you can distribute many roles in a single cohesive unit of re-usable automation. Inside a collection, you can share custom plugins across all roles in the collection instead of duplicating them in each role's :file:`library/`` directory. - -You must migrate roles to collections if you want to distribute them as certified Ansible content. - -.. note:: - - If you want to import your collection to Galaxy, you need a `Galaxy namespace `_. - -See :ref:`developing_collections` for details on collections. - - -.. contents:: - :local: - :depth: 1 - -Comparing standalone roles to collection roles -=============================================== - -:ref:`Standalone roles ` have the following directory structure: - -.. code-block:: bash - :emphasize-lines: 5,7,8 - - role/ - ├── defaults - ├── files - ├── handlers - ├── library - ├── meta - ├── module_utils - ├── [*_plugins] - ├── tasks - ├── templates - ├── tests - └── vars - - -The highlighted directories above will change when you migrate to a collection-based role. The collection directory structure includes a :file:`roles/` directory: - -.. code-block:: bash - - mynamespace/ - └── mycollection/ - ├── docs/ - ├── galaxy.yml - ├── plugins/ - │ ├── modules/ - │ │ └── module1.py - │ ├── inventory/ - │ └── .../ - ├── README.md - ├── roles/ - │ ├── role1/ - │ ├── role2/ - │ └── .../ - ├── playbooks/ - │ ├── files/ - │ ├── vars/ - │ ├── templates/ - │ └── tasks/ - └── tests/ - -You will need to use the Fully Qualified Collection Name (FQCN) to use the roles and plugins when you migrate your role into a collection. The FQCN is the combination of the collection ``namespace``, collection ``name``, and the content item you are referring to. - -So for example, in the above collection, the FQCN to access ``role1`` would be: - -.. code-block:: Python - - mynamespace.mycollection.role1 - - -A collection can contain one or more roles in the :file:`roles/` directory and these are almost identical to standalone roles, except you need to move plugins out of the individual roles, and use the :abbr:`FQCN (Fully Qualified Collection Name)` in some places, as detailed in the next section. - -.. note:: - - In standalone roles, some of the plugin directories referenced their plugin types in the plural sense; this is not the case in collections. - -.. _simple_roles_in_collections: - -Migrating a role to a collection -================================= - -To migrate from a standalone role that contains no plugins to a collection role: - -1. Create a local :file:`ansible_collections` directory and ``cd`` to this new directory. - -2. Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_. - -.. code-block:: bash - - $ ansible-galaxy collection init mynamespace.mycollection - -This creates the collection directory structure. - -3. Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead. - -.. code-block:: bash - - $ mkdir mynamespace/mycollection/roles/my_role/ - $ cp -r /path/to/standalone/role/mynamespace/my_role/\* mynamespace/mycollection/roles/my_role/ - -4. Update ``galaxy.yml`` to include any role dependencies. - -5. Update the collection README.md file to add links to any role README.md files. - -.. _complex_roles_in_collections: - -Migrating a role that contains plugins to a collection -====================================================== - -To migrate from a standalone role that has plugins to a collection role: - -1. Create a local :file:`ansible_collections directory` and ``cd`` to this new directory. - -2. Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_. - -.. code-block:: bash - - $ ansible-galaxy collection init mynamespace.mycollection - -This creates the collection directory structure. - -3. Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead. - -.. code-block:: bash - - $ mkdir mynamespace/mycollection/roles/my_role/ - $ cp -r /path/to/standalone/role/mynamespace/my_role/\* mynamespace/mycollection/roles/my_role/ - - -4. Move any modules to the :file:`plugins/modules/` directory. - -.. code-block:: bash - - $ mv -r mynamespace/mycollection/roles/my_role/library/\* mynamespace/mycollection/plugins/modules/ - -5. Move any other plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. See :ref:`migrating_plugins_collection` for additional steps that may be required. - -6. Update ``galaxy.yml`` to include any role dependencies. - -7. Update the collection README.md file to add links to any role README.md files. - -8. Change any references to the role to use the :abbr:`FQCN (Fully Qualified Collection Name)`. - -.. code-block:: yaml - - --- - - name: example role by FQCN - hosts: some_host_pattern - tasks: - - name: import FQCN role from a collection - import_role: - name: mynamespace.mycollection.my_role - - -You can alternately use the ``collections`` keyword to simplify this: - -.. code-block:: yaml - - --- - - name: example role by FQCN - hosts: some_host_pattern - collections: - - mynamespace.mycollection - tasks: - - name: import role from a collection - import_role: - name: my_role - - -.. _migrating_plugins_collection: - -Migrating other role plugins to a collection ---------------------------------------------- - -To migrate other role plugins to a collection: - - -1. Move each nonmodule plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. The :file:`mynamespace/mycollection/plugins/README.md` file explains the types of plugins that the collection can contain within optionally created subdirectories. - -.. code-block:: bash - - $ mv -r mynamespace/mycollection/roles/my_role/filter_plugins/\* mynamespace/mycollection/plugins/filter/ - -2. Update documentation to use the FQCN. Plugins that use ``doc_fragments`` need to use FQCN (for example, ``mydocfrag`` becomes ``mynamespace.mycollection.mydocfrag``). - -3. Update relative imports work in collections to start with a period. For example, :file:`./filename` and :file:`../asdfu/filestuff` works but :file:`filename` in same directory must be updated to :file:`./filename`. - - -If you have a custom ``module_utils`` or import from ``__init__.py``, you must also: - -#. Change the Python namespace for custom ``module_utils`` to use the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. See :ref:`update_module_utils_role`. - -#. Change how you import from ``__init__.py``. See :ref:`update_init_role`. - - -.. _update_module_utils_role: - -Updating ``module_utils`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If any of your custom modules use a custom module utility, once you migrate to a collection you cannot address the module utility in the top level ``ansible.module_utils`` Python namespace. Ansible does not merge content from collections into the Ansible internal Python namespace. Update any Python import statements that refer to custom module utilities when you migrate your custom content to collections. See :ref:`module_utils in collections ` for more details. - -When coding with ``module_utils`` in a collection, the Python import statement needs to take into account the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. The resulting Python import looks similar to the following example: - -.. code-block:: text - - from ansible_collections.{namespace}.{collectionname}.plugins.module_utils.{util} import {something} - -.. note:: - - You need to follow the same rules in changing paths and using namespaced names for subclassed plugins. - -The following example code snippets show a Python and a PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``ansible_example`` and the collection is ``community``. - -In the Python example the ``module_utils`` is ``helper`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.helper``: - -.. code-block:: text - - from ansible.module_utils.basic import AnsibleModule - from ansible.module_utils.common.text.converters import to_text - from ansible.module_utils.six.moves.urllib.parse import urlencode - from ansible.module_utils.six.moves.urllib.error import HTTPError - from ansible_collections.ansible_example.community.plugins.module_utils.helper import HelperRequest - - argspec = dict( - name=dict(required=True, type='str'), - state=dict(choices=['present', 'absent'], required=True), - ) - - module = AnsibleModule( - argument_spec=argspec, - supports_check_mode=True - ) - - _request = HelperRequest( - module, - headers={"Content-Type": "application/json"}, - data=data - ) - -In the PowerShell example the ``module_utils`` is ``hyperv`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.hyperv``: - -.. code-block:: powershell - - #!powershell - #AnsibleRequires -CSharpUtil Ansible.Basic - #AnsibleRequires -PowerShell ansible_collections.ansible_example.community.plugins.module_utils.hyperv - - $spec = @{ - name = @{ required = $true; type = "str" } - state = @{ required = $true; choices = @("present", "absent") } - } - $module = [Ansible.Basic.AnsibleModule]::Create($args, $spec) - - Invoke-HyperVFunction -Name $module.Params.name - - $module.ExitJson() - - -.. _update_init_role: - -Importing from __init__.py -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Because of the way that the CPython interpreter does imports, combined with the way the Ansible plugin loader works, if your custom embedded module or plugin requires importing something from an :file:`__init__.py` file, that also becomes part of your collection. You can either originate the content inside a standalone role or use the file name in the Python import statement. The following example is an :file:`__init__.py` file that is part of a callback plugin found inside a collection named ``ansible_example.community``. - -.. code-block:: python - - from ansible_collections.ansible_example.community.plugins.callback.__init__ import CustomBaseClass - - -Example: Migrating a standalone role with plugins to a collection ------------------------------------------------------------------ - -In this example we have a standalone role called ``my-standalone-role.webapp`` to emulate a standalone role that contains dashes in the name (which is not valid in collections). This standalone role contains a custom module in the ``library/`` directory called ``manage_webserver``. - -.. code-block:: bash - - my-standalone-role.webapp - ├── defaults - ├── files - ├── handlers - ├── library - ├── meta - ├── tasks - ├── templates - ├── tests - └── vars - -1. Create a new collection, for example, ``acme.webserver``: - -.. code-block:: bash - - $ ansible-galaxy collection init acme.webserver - - Collection acme.webserver was created successfully - $ tree acme -d 1 - acme - └── webserver - ├── docs - ├── plugins - └── roles - -2. Create the ``webapp`` role inside the collection and copy all contents from the standalone role: - -.. code-block:: bash - - $ mkdir acme/webserver/roles/webapp - $ cp my-standalone-role.webapp/* acme/webserver/roles/webapp/ - -3. Move the ``manage_webserver`` module to its new home in ``acme/webserver/plugins/modules/``: - -.. code-block:: bash - - $ cp my-standalone-role.webapp/library/manage_webserver.py acme/webserver/plugins/modules/manage.py - -.. note:: - - This example changed the original source file ``manage_webserver.py`` to the destination file ``manage.py``. This is optional but the :abbr:`FQCN (Fully Qualified Collection Name)` provides the ``webserver`` context as ``acme.webserver.manage``. - -4. Change ``manage_webserver`` to ``acme.webserver.manage`` in :file:`tasks/` files in the role ( for example, ``my-standalone-role.webapp/tasks/main.yml``) and any use of the original module name. - -.. note:: - - This name change is only required if you changed the original module name, but illustrates content referenced by :abbr:`FQCN (Fully Qualified Collection Name)` can offer context and in turn can make module and plugin names shorter. If you anticipate using these modules independent of the role, keep the original naming conventions. Users can add the :ref:`collections keyword ` in their playbooks. Typically roles are an abstraction layer and users won't use components of the role independently. - - -Example: Supporting standalone roles and migrated collection roles in a downstream RPM ---------------------------------------------------------------------------------------- - -A standalone role can co-exist with its collection role counterpart (for example, as part of a support lifecycle of a product). This should only be done for a transition period, but these two can exist in downstream in packages such as RPMs. For example, the RHEL system roles could coexist with an `example of a RHEL system roles collection `_ and provide existing backwards compatibility with the downstream RPM. - -This section walks through an example creating this coexistence in a downstream RPM and requires Ansible 2.9.0 or later. - -To deliver a role as both a standalone role and a collection role: - -#. Place the collection in :file:`/usr/share/ansible/collections/ansible_collections/`. -#. Copy the contents of the role inside the collection into a directory named after the standalone role and place the standalone role in :file:`/usr/share/ansible/roles/`. - -All previously bundled modules and plugins used in the standalone role are now referenced by :abbr:`FQCN (Fully Qualified Collection Name)` so even though they are no longer embedded, they can be found from the collection contents.This is an example of how the content inside the collection is a unique entity and does not have to be bound to a role or otherwise. You could alternately create two separate collections: one for the modules and plugins and another for the standalone role to migrate to. The role must use the modules and plugins as :abbr:`FQCN (Fully Qualified Collection Name)`. - -The following is an example RPM spec file that accomplishes this using this example content: - -.. code-block:: text - - Name: acme-ansible-content - Summary: Ansible Collection for deploying and configuring ACME webapp - Version: 1.0.0 - Release: 1%{?dist} - License: GPLv3+ - Source0: acme-webserver-1.0.0.tar.gz - - Url: https://github.com/acme/webserver-ansible-collection - BuildArch: noarch - - %global roleprefix my-standalone-role. - %global collection_namespace acme - %global collection_name webserver - - %global collection_dir %{_datadir}/ansible/collections/ansible_collections/%{collection_namespace}/%{collection_name} - - %description - Ansible Collection and standalone role (for backward compatibility and migration) to deploy, configure, and manage the ACME webapp software. - - %prep - %setup -qc - - %build - - %install - - mkdir -p %{buildroot}/%{collection_dir} - cp -r ./* %{buildroot}/%{collection_dir}/ - - mkdir -p %{buildroot}/%{_datadir}/ansible/roles - for role in %{buildroot}/%{collection_dir}/roles/* - do - cp -pR ${role} %{buildroot}/%{_datadir}/ansible/roles/%{roleprefix}$(basename ${role}) - - mkdir -p %{buildroot}/%{_pkgdocdir}/$(basename ${role}) - for docfile in README.md COPYING LICENSE - do - if [ -f ${role}/${docfile} ] - then - cp -p ${role}/${docfile} %{buildroot}/%{_pkgdocdir}/$(basename ${role})/${docfile} - fi - done - done - - - %files - %dir %{_datadir}/ansible - %dir %{_datadir}/ansible/roles - %dir %{_datadir}/ansible/collections - %dir %{_datadir}/ansible/collections/ansible_collections - %{_datadir}/ansible/roles/ - %doc %{_pkgdocdir}/*/README.md - %doc %{_datadir}/ansible/roles/%{roleprefix}*/README.md - %{collection_dir} - %doc %{collection_dir}/roles/*/README.md - %license %{_pkgdocdir}/*/COPYING - %license %{_pkgdocdir}/*/LICENSE - -.. _using_ansible_legacy: - -Using ``ansible.legacy`` to access local custom modules from collections-based roles -===================================================================================== - -Some roles within a collection use :ref:`local custom modules ` that are not part of the collection itself. If there is a conflict between the custom module short name and the collection module name, you need to specify which module your tasks call. You can update the tasks to change ``local_module_name`` to ``ansible.legacy.local_module_name`` to ensure you are using the custom module. diff --git a/docs/docsite/rst/dev_guide/module_lifecycle.rst b/docs/docsite/rst/dev_guide/module_lifecycle.rst deleted file mode 100644 index 823e2b37388..00000000000 --- a/docs/docsite/rst/dev_guide/module_lifecycle.rst +++ /dev/null @@ -1,126 +0,0 @@ -.. _module_lifecycle: - -******************************************** -The lifecycle of an Ansible module or plugin -******************************************** - -Modules and plugins in the main Ansible repository have a defined life cycle, from the first introduction to final removal. The module and plugin lifecycle is tied to the `Ansible release cycle `. -A module or plugin may move through these four stages: - -1. When a module or plugin is first accepted into Ansible, we consider it in tech preview and will mark it as such in the documentation. - -2. If a module or plugin matures, the 'preview' mark in the documentation is removed. Backward compatibility for these modules and plugins is maintained but not guaranteed, which means their parameters should be maintained with stable meanings. - -3. If a module's or plugin's target API changes radically, or if someone creates a better implementation of its functionality, we may mark it deprecated. Modules and plugins that are deprecated are still available but they are reaching the end of their life cycle. We retain deprecated modules and plugins for 4 release cycles with deprecation warnings to help users update playbooks and roles that use them. - -4. When a module or plugin has been deprecated for four release cycles, it is removed and replaced with a tombstone entry in the routing configuration. Modules and plugins that are removed are no longer shipped with Ansible. The tombstone entry helps users find alternative modules and plugins. - -For modules and plugins in collections, the lifecycle is similar. Since ansible-base 2.10, it is no longer possible to mark modules as 'preview' or 'stable'. - -.. _deprecating_modules: - -Deprecating modules and plugins in the Ansible main repository -============================================================== - -To deprecate a module in ansible-core, you must: - -1. Rename the file so it starts with an ``_``, for example, rename ``old_cloud.py`` to ``_old_cloud.py``. This keeps the module available and marks it as deprecated on the module index pages. -2. Mention the deprecation in the relevant changelog (by creating a changelog fragment with a section ``deprecated_features``). -3. Reference the deprecation in the relevant ``porting_guide_core_x.y.rst``. -4. Add ``deprecated:`` to the documentation with the following sub-values: - - :removed_in: A ``string``, such as ``"2.10"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:. - :remove_by_date: (Added in ansible-base 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:. - :why: Optional string that used to detail why this has been removed. - :alternative: Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``. - -* For an example of documenting deprecation, see this `PR that deprecates multiple modules `_. - Some of the elements in the PR might now be out of date. - -Deprecating modules and plugins in a collection -=============================================== - -To deprecate a module in a collection, you must: - -1. Add a ``deprecation`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to deprecate the module ``old_cloud``, add: - - .. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - deprecation: - removal_version: 2.0.0 - warning_text: Use foo.bar.new_cloud instead. - - For other plugin types, you have to replace ``modules:`` with ``:``, for example ``lookup:`` for lookup plugins. - - Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date after which the module will be removed in a new major version of the collection. - -2. Mention the deprecation in the relevant changelog. If the collection uses ``antsibull-changelog``, create a changelog fragment with a section ``deprecated_features``. -3. Add ``deprecated:`` to the documentation of the module or plugin with the following sub-values: - - :removed_in: A ``string``, such as ``"2.10"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:. - :remove_by_date: (Added in ansible-base 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:. - :why: Optional string that used to detail why this has been removed. - :alternative: Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``. - -Changing a module or plugin name in the Ansible main repository -=============================================================== - -You can also rename a module and keep a deprecated alias to the old name by using a symlink that starts with _. -This example allows the ``stat`` module to be called with ``fileinfo``, making the following examples equivalent: - -.. code-block:: yaml - - ln -s stat.py _fileinfo.py - ansible -m stat -a "path=/tmp" localhost - ansible -m fileinfo -a "path=/tmp" localhost - -Renaming a module or plugin in a collection, or redirecting a module or plugin to another collection -==================================================================================================== - -To rename a module or plugin in a collection, or to redirect a module or plugin to another collection, you need to add a ``redirect`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to redirect the module ``old_cloud`` to ``foo.bar.new_cloud``, add: - -.. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - redirect: foo.bar.new_cloud - -If you want to deprecate the old name, add a ``deprecation:`` entry (see above): - -.. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - redirect: foo.bar.new_cloud - deprecation: - removal_version: 2.0.0 - warning_text: Use foo.bar.new_cloud instead. - -You need to use the Fully Qualified Collection Name (FQCN) of the new module/plugin name, even if it is located in the same collection as the redirect. By using a FQCN from another collection, you redirect the module/plugin to that collection. - -If you need to support Ansible 2.9, please note that Ansible 2.9 does not know about ``meta/runtime.yml``. With Ansible 2.9 you can still rename plugins and modules inside one collection by using symbolic links. Note that ansible-base 2.10, ansible-core 2.11, and newer will prefer ``meta/runtime.yml`` entries over symbolic links. - - -Tombstoning a module or plugin in a collection -============================================== - -To remove a deprecated module or plugin from a collection, you need to tombstone it: - -1. Remove the module or plugin file with related files like tests, documentation references, and documentation. -2. Add a tombstone entry in ``meta/runtime.yml``. For example, to tombstone the module ``old_cloud``, add: - - .. code-block:: yaml - - plugin_routing: - modules: - old_cloud: - tombstone: - removal_version: 2.0.0 - warning_text: Use foo.bar.new_cloud instead. - - Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date. The date should be the date of the next major release. diff --git a/docs/docsite/rst/dev_guide/overview_architecture.rst b/docs/docsite/rst/dev_guide/overview_architecture.rst deleted file mode 100644 index 89677e96d9a..00000000000 --- a/docs/docsite/rst/dev_guide/overview_architecture.rst +++ /dev/null @@ -1,153 +0,0 @@ -******************** -Ansible architecture -******************** - -Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. - -Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time. - -It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English. - -In this section, we'll give you a really quick overview of how Ansible works so you can see how the pieces fit together. - -.. contents:: - :local: - -Modules -======= - -Ansible works by connecting to your nodes and pushing out scripts called "Ansible modules" to them. Most modules accept parameters that describe the desired state of the system. -Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required. - -You can :ref:`write your own modules `, though you should first consider :ref:`whether you should `. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content. You may write specialized modules in any language that can return JSON (Ruby, Python, bash, and so on). - -Module utilities -================ - -When multiple modules use the same code, Ansible stores those functions as module utilities to minimize duplication and maintenance. For example, the code that parses URLs is ``lib/ansible/module_utils/url.py``. You can :ref:`write your own module utilities ` as well. Module utilities may only be written in Python or in PowerShell. - -Plugins -======= - -:ref:`Plugins ` augment Ansible's core functionality. While modules execute on the target system in separate processes (usually that means on a remote system), plugins execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more. Ansible ships with a number of handy plugins, and you can easily :ref:`write your own `. For example, you can write an :ref:`inventory plugin ` to connect to any datasource that returns JSON. Plugins must be written in Python. - -Inventory -========= - -By default, Ansible represents the machines it manages in a file (INI, YAML, and so on) that puts all of your managed machines in groups of your own choosing. - -To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues. - -If there's another source of truth in your infrastructure, Ansible can also connect to that. Ansible can draw inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more. - -Here's what a plain text inventory file looks like: - -.. code-block:: text - - --- - [webservers] - www1.example.com - www2.example.com - - [dbservers] - db0.example.com - db1.example.com - -Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/') or directly in the inventory file. - -Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack. - -Playbooks -========= - -Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible starts to get most interesting. - -Ansible's approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features. - -Here's what a simple playbook looks like: - -.. code-block:: yaml - - --- - - hosts: webservers - serial: 5 # update 5 machines at a time - roles: - - common - - webapp - - - hosts: content_servers - roles: - - common - - content - -.. _ansible_search_path: - -The Ansible search path -======================= - -Modules, module utilities, plugins, playbooks, and roles can live in multiple locations. If you -write your own code to extend Ansible's core features, you may have multiple files with similar or the same names in different locations on your Ansible control node. The search path determines which of these files Ansible will discover and use on any given playbook run. - -Ansible's search path grows incrementally over a run. As -Ansible finds each playbook and role included in a given run, it appends -any directories related to that playbook or role to the search path. Those -directories remain in scope for the duration of the run, even after the playbook or role -has finished executing. Ansible loads modules, module utilities, and plugins in this order: - -1. Directories adjacent to a playbook specified on the command line. If you run Ansible with ``ansible-playbook /path/to/play.yml``, Ansible appends these directories if they exist: - - .. code-block:: bash - - /path/to/modules - /path/to/module_utils - /path/to/plugins - -2. Directories adjacent to a playbook that is statically imported by a - playbook specified on the command line. If ``play.yml`` includes - ``- import_playbook: /path/to/subdir/play1.yml``, Ansible appends these directories if they exist: - - .. code-block:: bash - - /path/to/subdir/modules - /path/to/subdir/module_utils - /path/to/subdir/plugins - -3. Subdirectories of a role directory referenced by a playbook. If - ``play.yml`` runs ``myrole``, Ansible appends these directories if they exist: - - .. code-block:: bash - - /path/to/roles/myrole/modules - /path/to/roles/myrole/module_utils - /path/to/roles/myrole/plugins - -4. Directories specified as default paths in ``ansible.cfg`` or by the related - environment variables, including the paths for the various plugin types. See :ref:`ansible_configuration_settings` for more information. - Sample ``ansible.cfg`` fields: - - .. code-block:: bash - - DEFAULT_MODULE_PATH - DEFAULT_MODULE_UTILS_PATH - DEFAULT_CACHE_PLUGIN_PATH - DEFAULT_FILTER_PLUGIN_PATH - - Sample environment variables: - - .. code-block:: bash - - ANSIBLE_LIBRARY - ANSIBLE_MODULE_UTILS - ANSIBLE_CACHE_PLUGINS - ANSIBLE_FILTER_PLUGINS - -5. The standard directories that ship as part of the Ansible distribution. - -.. caution:: - - Modules, module utilities, and plugins in user-specified directories will - override the standard versions. This includes some files with generic names. - For example, if you have a file named ``basic.py`` in a user-specified - directory, it will override the standard ``ansible.module_utils.basic``. - - If you have more than one module, module utility, or plugin with the same name in different user-specified directories, the order of commands at the command line and the order of includes and roles in each play will affect which one is found and used on that particular play. diff --git a/docs/docsite/rst/dev_guide/shared_snippets/licensing.txt b/docs/docsite/rst/dev_guide/shared_snippets/licensing.txt deleted file mode 100644 index d4b3051f984..00000000000 --- a/docs/docsite/rst/dev_guide/shared_snippets/licensing.txt +++ /dev/null @@ -1,12 +0,0 @@ -.. note:: - **LICENSING REQUIREMENTS** Ansible enforces the following licensing requirements: - - * Utilities (files in ``lib/ansible/module_utils/``) may have one of two licenses: - * A file in ``module_utils`` used **only** for a specific vendor's hardware, provider, or service may be licensed under GPLv3+. - Adding a new file under ``module_utils`` with GPLv3+ needs to be approved by the core team. - * All other ``module_utils`` must be licensed under BSD, so GPL-licensed third-party and Galaxy modules can use them. - * If there's doubt about the appropriate license for a file in ``module_utils``, the Ansible Core Team will decide during an Ansible Core Community Meeting. - * All other files shipped with Ansible, including all modules, must be licensed under the GPL license (GPLv3 or later). - * Existing license requirements still apply to content in ansible/ansible (ansible-core). - * Content that was previously in ansible/ansible or a collection and has moved to a new collection must retain the license it had in its prior repository. - * Copyright entries by previous committers must also be kept in any moved files. diff --git a/docs/docsite/rst/dev_guide/sidecar.rst b/docs/docsite/rst/dev_guide/sidecar.rst deleted file mode 100644 index ccf3aa75efa..00000000000 --- a/docs/docsite/rst/dev_guide/sidecar.rst +++ /dev/null @@ -1,100 +0,0 @@ -.. _adjacent_yaml_doc: - -********************************* -Adjacent YAML documentation files -********************************* - -.. contents:: - :local: - -YAML documentation for plugins ------------------------------- -For most Ansible plugins, the documentation is in the same file as the code. This approach does not work for cases when: - - * Multiple plugins are defined in the same file, such as tests and filters. - * Plugins are written in a language other than Python (modules). - -These cases require plugins to provide documentation in an adjacent ``.py`` file. As of ansible-core 2.14, you can provide documentation as adjacent YAML files instead. -The format of a YAML documentation file is nearly identical to its Python equivalent, except it is pure YAML. - - -YAML format ------------ -In Python each section is a variable ``DOCUMENTATION = r""" ... """`` while in YAML it is a mapping key ``DOCUMENTATION: ...``. - -Here is a longer example that shows documentation as embedded in a Python file: - -.. code-block:: python - - DOCUMENTATION = r''' - description: something - options: - option_name: - description: describe this config option - default: default value for this config option - env: - - name: NAME_OF_ENV_VAR - ini: - - section: section_of_ansible.cfg_where_this_config_option_is_defined - key: key_used_in_ansible.cfg - vars: - - name: name_of_ansible_var - - name: name_of_second_var - version_added: X.x - required: True/False - type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath - version_added: X.x - ''' - - EXAMPLES = r''' - # TODO: write examples - ''' - -This example shows the same documentation in YAML format: - -.. code-block:: YAML - - DOCUMENTATION: - description: something - options: - option_name: - description: describe this config option - default: default value for this config option - env: - - name: NAME_OF_ENV_VAR - ini: - - section: section_of_ansible.cfg_where_this_config_option_is_defined - key: key_used_in_ansible.cfg - vars: - - name: name_of_ansible_var - - name: name_of_second_var - version_added: X.x - required: True/False - type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath - version_added: X.x - - EXAMPLES: # TODO: write examples - -As the examples above show, Python variables already contain YAML. The main change to use YAML documentation is to simply move the YAML out of such variables. - - Any adjacent YAML documentation files must be in the same directory as the plugin or module that they document. This means the documentation is available in any directory that contains the plugins or modules. - - -Supported plugin types ----------------------- -YAML documentation is mainly intended for filters, tests and modules. While it is possible to use with other plugin types, Ansible always recommends having documentation in the same file as the code for most cases. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_api` - Learn about the Python API for task execution - :ref:`developing_inventory` - Learn about how to develop dynamic inventory sources - :ref:`developing_modules_general` - Learn about how to write Ansible modules - `Mailing List `_ - The development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst b/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst deleted file mode 100644 index fcb4abad687..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst +++ /dev/null @@ -1,71 +0,0 @@ -.. _styleguide_basic: - -Basic rules -=========== -.. contents:: - :local: - -Use standard American English ------------------------------ -Ansible uses Standard American English. Watch for common words that are spelled differently in American English (color vs colour, organize vs organise, and so on). - -Write for a global audience ---------------------------- -Everything you say should be understandable by people of different backgrounds and cultures. Avoid idioms and regionalism and maintain a neutral tone that cannot be misinterpreted. Avoid attempts at humor. - -Follow naming conventions -------------------------- -Always follow naming conventions and trademarks. - -.. good place to link to an Ansible terminology page - -Use clear sentence structure ----------------------------- -Clear sentence structure means: - -- Start with the important information first. -- Avoid padding/adding extra words that make the sentence harder to understand. -- Keep it short - Longer sentences are harder to understand. - -Some examples of improving sentences: - -Bad: - The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety. - -Better: - Danger! Stay away from the cliff. - -Bad: - Furthermore, large volumes of water are also required for the process of extraction. - -Better: - Extraction also requires large volumes of water. - -Avoid verbosity ---------------- -Write short, succinct sentences. Avoid terms like: - -- "...as has been said before," -- "..each and every," -- "...point in time," -- "...in order to," - -Highlight menu items and commands ---------------------------------- -When documenting menus or commands, it helps to **bold** what is important. - -For menu procedures, bold the menu names, button names, and so on to help the user find them on the GUI: - -1. On the **File** menu, click **Open**. -2. Type a name in the **User Name** field. -3. In the **Open** dialog box, click **Save**. -4. On the toolbar, click the **Open File** icon. - -For code or command snippets, use the RST `code-block directive `_: - -.. code-block:: rst - - .. code-block:: bash - - ssh my_vyos_user@vyos.example.net - show config diff --git a/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst b/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst deleted file mode 100644 index da06070918d..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst +++ /dev/null @@ -1,201 +0,0 @@ - -Grammar and Punctuation -======================= - -Common Styles and Usage, and Common Mistakes ----------------------------------------------------- - -Ansible -^^^^^^^ -* Write "Ansible." Not "Ansible, Inc." or "AnsibleWorks The only exceptions to this rule are when we're writing legal or financial statements. - -* Never use the logotype by itself in body text. Always keep the same font you are using the rest of the sentence. - -* A company is singular in the US. In other words, Ansible is an "it," not a "they." - - -Capitalization -^^^^^^^^^^^^^^ -If it's not a real product, service, or department at Ansible, don't capitalize it. Not even if it seems important. Capitalize only the first letter of the first word in headlines. - -Colon -^^^^^ -A colon is generally used before a list or series: -- The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill. - -But not if the list is a complement or object of an element in the sentence: -- Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail. - -Use a colon after "as follows" and "the following" if the related list comes immediately after: -wedge The steps for changing directories are as follows: - - 1. Open a terminal. - 2. Type cd... - -Use a colon to introduce a bullet list (or dash, or icon/symbol of your choice): - - In the Properties dialog box, you'll find the following entries: - - - Connection name - - Count - - Cost per item - - -Commas -^^^^^^ -Use serial commas, the comma before the "and" in a series of three or more items: - -- "Item 1, item 2, and item 3." - - -It's easier to read that way and helps avoid confusion. The primary exception to this you will see is in PR, where it is traditional not to use serial commas because it is often the style of journalists. - -Commas are always important, considering the vast difference in meanings of the following two statements. - -- Let's eat, Grandma -- Let's eat Grandma. - -Correct punctuation could save Grandma's life. - -If that does not convince you, maybe this will: - -.. image:: images/commas-matter.jpg - - -Contractions -^^^^^^^^^^^^ -Do not use contractions in Ansible documents. - -Em dashes -^^^^^^^^^ -When possible, use em-dashes with no space on either side. When full em-dashes aren't available, use double-dashes with no spaces on either side--like this. - -A pair of em dashes can be used in place of commas to enhance readability. Note, however, that dashes are always more emphatic than commas. - -A pair of em dashes can replace a pair of parentheses. Dashes are considered less formal than parentheses; they are also more intrusive. If you want to draw attention to the parenthetical content, use dashes. If you want to include the parenthetical content more subtly, use parentheses. - -.. note:: - When dashes are used in place of parentheses, surrounding punctuation should be omitted. Compare the following examples. - -:: - - Upon discovering the errors (all 124 of them), the publisher immediately recalled the books. - - Upon discovering the errors—all 124 of them—the publisher immediately recalled the books. - - -When used in place of parentheses at the end of a sentence, only a single dash is used. - -:: - - After three weeks on set, the cast was fed up with his direction (or, rather, lack of direction). - - After three weeks on set, the cast was fed up with his direction—or, rather, lack of direction. - - -Exclamation points (!) -^^^^^^^^^^^^^^^^^^^^^^ -Do not use them at the end of sentences. An exclamation point can be used when referring to a command, such as the bang (!) command. - -Gender References -^^^^^^^^^^^^^^^^^ -Do not use gender-specific pronouns in documentation. It is far less awkward to read a sentence that uses "they" and "their" rather than "he/she" and "his/hers." - -It is fine to use "you" when giving instructions and "the user," "new users," and so on. in more general explanations. - -Never use "one" in place of "you" when writing technical documentation. Using "one" is far too formal. - -Never use "we" when writing. "We" aren't doing anything on the user side. Ansible's products are doing the work as requested by the user. - - -Hyphen -^^^^^^ -The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary. - -Use hyphens to avoid ambiguity or confusion: - -:: - - a little-used car - a little used-car - - cross complaint - cross-complaint - - high-school girl - high schoolgirl - - fine-tooth comb (most people do not comb their teeth) - - third-world war - third world war - -.. image:: images/hyphen-funny.jpg - -In professionally printed material (particularly books, magazines, and newspapers), the hyphen is used to divide words between the end of one line and the beginning of the next. This allows for an evenly aligned right margin without highly variable (and distracting) word spacing. - - -Lists -^^^^^ -Keep the structure of bulleted lists equivalent and consistent. If one bullet is a verb phrase, they should all be verb phrases. If one is a complete sentence, they should all be complete sentences, and so on. - -Capitalize the first word of each bullet. Unless it is obvious that it is just a list of items, such as a list of items like: -* computer -* monitor -* keyboard -* mouse - -When the bulleted list appears within the context of other copy, (unless it's a straight list like the previous example) add periods, even if the bullets are sentence fragments. Part of the reason behind this is that each bullet is said to complete the original sentence. - -In some cases where the bullets are appearing independently, such as in a poster or a homepage promotion, they do not need periods. - -When giving instructional steps, use numbered lists instead of bulleted lists. - - -Months and States -^^^^^^^^^^^^^^^^^ -Abbreviate months and states according to AP. Months are only abbreviated if they are used in conjunction with a day. Example: "The President visited in January 1999." or "The President visited Jan. 12." - -Months: Jan., Feb., March, April, May, June, July, Aug., Sept., Nov., Dec. - -States: Ala., Ariz., Ark., Calif., Colo., Conn., Del., Fla., Ga., Ill., Ind., Kan., Ky., La., Md., Mass., Mich., Minn., Miss., Mo., Mont., Neb., Nev., NH, NJ, NM, NY, NC, ND, Okla., Ore., Pa., RI, SC, SD, Tenn., Vt., Va., Wash., W.Va., Wis., Wyo. - -Numbers -^^^^^^^ -Numbers between one and nine are written out. 10 and above are numerals. The exception to this is writing "4 million" or "4 GB." It's also acceptable to use numerals in tables and charts. - -Phone Numbers -^^^^^^^^^^^^^ - -Phone number style: 1 (919) 555-0123 x002 and 1 888-GOTTEXT - - -Quotations (Using Quotation Marks and Writing Quotes) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - "Place the punctuation inside the quotes," the editor said. - -Except in rare instances, use only "said" or "says" because anything else just gets in the way of the quote itself, and also tends to editorialize. - -Place the name first right after the quote: - "I like to write first-person because I like to become the character I'm writing," Wally Lamb said. - -Not: - "I like to write first-person because I like to become the character I'm writing," said Wally Lamb. - - -Semicolon -^^^^^^^^^ -Use a semicolon to separate items in a series if the items contain commas: - -- Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner. - -Use a semicolon before a conjunctive adverb (however, therefore, otherwise, namely, for example, and so on): -- I think; therefore, I am. - -Spacing after sentences -^^^^^^^^^^^^^^^^^^^^^^^ -Use only a single space after a sentence. - -Time -^^^^ -* Time of day is written as "4 p.m." diff --git a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter-2.jpg b/docs/docsite/rst/dev_guide/style_guide/images/commas-matter-2.jpg deleted file mode 100644 index 2dec81c4380..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter-2.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter.jpg b/docs/docsite/rst/dev_guide/style_guide/images/commas-matter.jpg deleted file mode 100644 index 1699a31af31..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/commas-matter.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/images/hyphen-funny.jpg b/docs/docsite/rst/dev_guide/style_guide/images/hyphen-funny.jpg deleted file mode 100644 index d642703fe44..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/hyphen-funny.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/images/thenvsthan.jpg b/docs/docsite/rst/dev_guide/style_guide/images/thenvsthan.jpg deleted file mode 100644 index f4851b07813..00000000000 Binary files a/docs/docsite/rst/dev_guide/style_guide/images/thenvsthan.jpg and /dev/null differ diff --git a/docs/docsite/rst/dev_guide/style_guide/index.rst b/docs/docsite/rst/dev_guide/style_guide/index.rst deleted file mode 100644 index b43b9164d31..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/index.rst +++ /dev/null @@ -1,340 +0,0 @@ -.. _style_guide: - -********************************** -Ansible documentation style guide -********************************** - -Welcome to the Ansible style guide! -To create clear, concise, consistent, useful materials on docs.ansible.com, follow these guidelines: - -.. contents:: - :local: - -Linguistic guidelines -===================== - -We want the Ansible documentation to be: - -* clear -* direct -* conversational -* easy to translate - -We want reading the docs to feel like having an experienced, friendly colleague -explain how Ansible works. - -Stylistic cheat-sheet ---------------------- - -This cheat-sheet illustrates a few rules that help achieve the "Ansible tone": - -+-------------------------------+------------------------------+----------------------------------------+ -| Rule | Good example | Bad example | -+===============================+==============================+========================================+ -| Use active voice | You can run a task by | A task can be run by | -+-------------------------------+------------------------------+----------------------------------------+ -| Use the present tense | This command creates a | This command will create a | -+-------------------------------+------------------------------+----------------------------------------+ -| Address the reader | As you expand your inventory | When the number of managed nodes grows | -+-------------------------------+------------------------------+----------------------------------------+ -| Use standard English | Return to this page | Hop back to this page | -+-------------------------------+------------------------------+----------------------------------------+ -| Use American English | The color of the output | The colour of the output | -+-------------------------------+------------------------------+----------------------------------------+ - -Header case ------------ - -Headers should be written in sentence case. For example, this section's title is -``Header case``, not ``Header Case`` or ``HEADER CASE``. - - -Avoid using Latin phrases -------------------------- - -Latin words and phrases like ``e.g.`` or ``etc.`` -are easily understood by English speakers. -They may be harder to understand for others and are also tricky for automated translation. - -Use the following English terms in place of Latin terms or abbreviations: - -+-------------------------------+------------------------------+ -| Latin | English | -+===============================+==============================+ -| i.e | in other words | -+-------------------------------+------------------------------+ -| e.g. | for example | -+-------------------------------+------------------------------+ -| etc | and so on | -+-------------------------------+------------------------------+ -| via | by/ through | -+-------------------------------+------------------------------+ -| vs./versus | rather than/against | -+-------------------------------+------------------------------+ - - -reStructuredText guidelines -=========================== - -The Ansible documentation is written in reStructuredText and processed by Sphinx. -We follow these technical or mechanical guidelines on all rST pages: - -.. _headers_style: - -Header notation ---------------- - -`Section headers in reStructuredText `_ -can use a variety of notations. -Sphinx will 'learn on the fly' when creating a hierarchy of headers. -To make our documents easy to read and to edit, we follow a standard set of header notations. -We use: - -* ``###`` with overline, for parts: - -.. code-block:: rst - - ############### - Developer guide - ############### - -* ``***`` with overline, for chapters: - -.. code-block:: rst - - ******************* - Ansible style guide - ******************* - -* ``===`` for sections: - -.. code-block:: rst - - Mechanical guidelines - ===================== - -* ``---`` for subsections: - -.. code-block:: rst - - Internal navigation - ------------------- - -* ``^^^`` for sub-subsections: - -.. code-block:: rst - - Adding anchors - ^^^^^^^^^^^^^^ - -* ``"""`` for paragraphs: - -.. code-block:: rst - - Paragraph that needs a title - """""""""""""""""""""""""""" - - -Syntax highlighting - Pygments ------------------------------- - -The Ansible documentation supports a range of `Pygments lexers `_ -for `syntax highlighting `_ to make our code examples look good. Each code-block must be correctly indented and surrounded by blank lines. - -The Ansible documentation allows the following values: - -* none (no highlighting) -* ansible-output (a custom lexer for Ansible output) -* bash -* console -* csharp -* ini -* json -* powershell -* python -* rst -* sh -* shell -* shell-session -* text -* yaml -* yaml+jinja - -For example, you can highlight Python code using following syntax: - -.. code-block:: rst - - .. code-block:: python - - def my_beautiful_python_code(): - pass - -.. _style_links: - -Internal navigation -------------------- - -`Anchors (also called labels) and links `_ -work together to help users find related content. -Local tables of contents also help users navigate quickly to the information they need. -All internal links should use the ``:ref:`` syntax. -Every page should have at least one anchor to support internal ``:ref:`` links. -Long pages, or pages with multiple levels of headers, can also include a local TOC. - -.. note:: - - Avoid raw URLs. RST and sphinx allow ::code:`https://my.example.com`, but this is unhelpful for those using screen readers. ``:ref:`` links automatically pick up the header from the anchor, but for external links, always use the ::code:`link title `_` format. - -.. _adding_anchors_rst: - -Adding anchors -^^^^^^^^^^^^^^ - -* Include at least one anchor on every page -* Place the main anchor above the main header -* If the file has a unique title, use that for the main page anchor: - -.. code-block:: text - - .. _unique_page:: - -* You may also add anchors elsewhere on the page - -Adding internal links -^^^^^^^^^^^^^^^^^^^^^ - -* All internal links must use ``:ref:`` syntax. These links both point to the anchor defined above: - -.. code-block:: rst - - :ref:`unique_page` - :ref:`this page ` - -The second example adds custom text for the link. - -Adding links to modules and plugins -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Ansible 2.10 and later require the extended Fully Qualified Collection Name (FQCN) as part of the links: - -.. code-block:: text - - ansible_collections. + FQCN + _module - -For example: - - .. code-block:: rst - - :ref:`ansible.builtin.first_found lookup plugin ` - -displays as :ref:`ansible.builtin.first_found lookup plugin `. - -Modules require different suffixes from other plugins: - -* Module links use this extended FQCN module name with ``_module`` for the anchor. -* Plugin links use this extended FQCN plugin name with the plugin type (``_connection`` for example). - -.. code-block:: rst - - :ref:`arista.eos.eos_config ` - :ref:`kubernetes.core.kubectl connection plugin ` - -.. note:: - - ``ansible.builtin`` is the FQCN for modules included in ``ansible.base``. Documentation links are the only place you prepend ``ansible_collections`` to the FQCN. This is used by the documentation build scripts to correctly fetch documentation from collections on Ansible Galaxy. - -.. _local_toc: - -Adding local TOCs -^^^^^^^^^^^^^^^^^ - -The page you're reading includes a `local TOC `_. -If you include a local TOC: - -* place it below, not above, the main heading and (optionally) introductory text -* use the ``:local:`` directive so the page's main header is not included -* do not include a title - -The syntax is: - -.. code-block:: rst - - .. contents:: - :local: - -Accessibility guidelines -========================= - -Ansible documentation has a goal to be more accessible. Use the following guidelines to help us reach this goal. - -Images and alternative text - Ensure all icons, images, diagrams, and non text elements have a meaningful alternative-text description. Do not include screen captures of CLI output. Use ``code-block`` instead. - - .. code-block:: text - - .. image:: path/networkdiag.png - :width: 400 - :alt: SpiffyCorp network diagram - - -Links and hypertext - URLs and cross-reference links have descriptive text that conveys information about the content of the linked target. See :ref:`style_links` for how to format links. - -Tables - Tables have a simple, logical reading order from left to right, and top to bottom. - Tables include a header row and avoid empty or blank table cells. - Label tables with a descriptive title. - - .. code-block:: reStructuredText - - .. table:: File descriptions - - +----------+----------------------------+ - |File |Purpose | - +==========+============================+ - |foo.txt |foo configuration settings | - +----------+----------------------------+ - |bar.txt |bar configuration settings | - +----------+----------------------------+ - - -Colors and other visual information - * Avoid instructions that rely solely on sensory characteristics. For example, do not use ``Click the square, blue button to continue.`` - * Convey information by methods and not by color alone. - * Ensure there is sufficient contrast between foreground and background text or graphical elements in images and diagrams. - * Instructions for navigating through an interface make sense without directional indicators such as left, right, above, and below. - -Accessibility resources ------------------------- - -Use the following resources to help test your documentation changes: - -* `axe DevTools browser extension `_ - Highlights accessibility issues on a website page. -* `WAVE browser extension `_ from WebAIM - another accessibility tester. -* `Orca screen reader `_ - Common tool used by people with vision impairments. -* `color filter `_ - For color-blind testing. - -More resources -============== - -These pages offer more help with grammatical, stylistic, and technical rules for documentation. - -.. toctree:: - :maxdepth: 1 - - basic_rules - voice_style - trademarks - grammar_punctuation - spelling_word_choice - search_hints - resources - -.. seealso:: - - :ref:`community_documentation_contributions` - How to contribute to the Ansible documentation - :ref:`testing_documentation_locally` - How to build the Ansible documentation - `irc.libera.chat `_ - #ansible-docs IRC chat channel diff --git a/docs/docsite/rst/dev_guide/style_guide/resources.rst b/docs/docsite/rst/dev_guide/style_guide/resources.rst deleted file mode 100644 index 64dc0c1dd57..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/resources.rst +++ /dev/null @@ -1,11 +0,0 @@ -Resources -^^^^^^^^^ -* Follow the style of the :ref:`Ansible Documentation` -* Ask for advice on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) -* Review these online style guides: - - * `AP Stylebook `_ - * `Chicago Manual of Style `_ - * `Strunk and White's Elements of Style `_ - * `Google developer documentation style guide `_ - diff --git a/docs/docsite/rst/dev_guide/style_guide/search_hints.rst b/docs/docsite/rst/dev_guide/style_guide/search_hints.rst deleted file mode 100644 index d9bf3f665a7..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/search_hints.rst +++ /dev/null @@ -1,48 +0,0 @@ - -.. _search_hints: - -Writing documentation so search can find it -------------------------------------------- - -One of the keys to writing good documentation is to make it findable. Readers use a combination of internal site search and external search engines such as Google or duckduckgo. - -To ensure Ansible documentation is findable, you should: - -#. Use headings that clearly reflect what you are documenting. -#. Use numbered lists for procedures or high-level steps where possible. -#. Avoid linking to github blobs where possible. - - -Using clear headings in documentation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -We all use simple English when we want to find something. For example, the title of this page could have been any one of the following: - -* Search optimization -* Findable documentation -* Writing for findability - -What we are really trying to describe is - how do I write documentation so search engines can find my content? That simple phrase is what drove the title of this section. When you are creating your headings for documentation, spend some time to think about what you would type in a search box to find it, or more importantly, how someone less familiar with Ansible would try to find that information. Your heading should be the answer to that question. - -One word of caution - you do want to limit the size of your headings. A full heading such as `How do I write documentation so search engines can find my content?` is too long. Search engines would truncate anything over 50 - 60 characters. Long headings would also wrap on smaller devices such as a smart phone. - -Using numbered lists for `zero position` snippets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Google can optimize the search results by adding a `feature snippet `_ at the top of the search results. This snippet provides a small window into the documentation on that first search result that adds more detail than the rest of the search results, and can occasionally answer the reader's questions right there, or at least verify that the linked page is what the reader is looking for. - -Google returns the feature snippet in the form of numbered steps. Where possible, you should add a numbered list near the top of your documentation page, where appropriate. The steps can be the exact procedure a reader would follow, or could be a high level introduction to the documentation topic, such as the numbered list at the top of this page. - -Problems with github blobs on search results -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Search engines do not typically return github blobs in search results, at least not in higher ranked positions. While it is possible and sometimes necessary to link to github blobs from documentation, the better approach would be to copy that information into an .rst page in Ansible documentation. - -Other search hints -^^^^^^^^^^^^^^^^^^ - -While it may not be possible to adapt your documentation to all search optimizations, keep the following in mind as you write your documentation: - -* **Search engines don't parse beyond the `#` in an html page.** So for example, all the subheadings on this page are appended to the main page URL. As such, when I search for 'Using number lists for zero position snippets', the search result would be a link to the top of this page, not a link directly to the subheading I searched for. Using :ref:`local TOCs ` helps alleviate this problem as the reader can scan for the header at top of the page and click to the section they are looking for. For critical documentation, consider creating a new page that can be a direct search result page. - -* **Make your first few sentences clearly describe your page topic.** Search engines return not just the URL, but a short description of the information at the URL. For Ansible documentation, we do not have description metadata embedded on each page. Instead, the search engines return the first couple of sentences (140 characters) on the page. That makes your first sentence or two very important to the reader who is searching for something in Ansible. diff --git a/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst b/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst deleted file mode 100644 index ce16eba70f3..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst +++ /dev/null @@ -1,327 +0,0 @@ -Spelling - Word Usage - Common Words and Phrases to Use and Avoid ------------------------------------------------------------------ - -Acronyms -^^^^^^^^ - -Always uppercase. An acronym is a word formed from the initial letters of a name, such as ROM for Read-only memory, -SaaS for Software as a Service, or by combining initial letters or part of a series of words, such as LILO for LInux -LOader. - -Spell out the acronym before using it in alone text, such as "The Embedded DevKit (EDK)..." - -Applications -^^^^^^^^^^^^ -When used as a proper name, use the capitalization of the product, such as GNUPro or Source-Navigator. When used as a command, use lowercase as appropriate, such as "To start GCC, type ``gcc``." - -.. note:: - - "vi" is always lowercase. - -As -^^ -This is often used to mean "because", but has other connotations, for example, parallel or simultaneous actions. If you mean "because", say "because". - -Asks for -^^^^^^^^ -Use "requests" instead. - -Assure/Ensure/Insure -^^^^^^^^^^^^^^^^^^^^ -Assure implies a sort of mental comfort. As in "I assured my husband that I would eventually bring home beer." - -Ensure means "to make sure." - -Insure relates to monetary insurance. - - -Back up -^^^^^^^ -This is a verb. You "back up" files; you do not "backup" files. - -Backup -^^^^^^ -This is a noun. You create "backup" files; you do not create "back up" files. - -Backward -^^^^^^^^ -Correct. Avoid using backwards unless you are stating that something has "backwards compatibility." - -Backwards compatibility -^^^^^^^^^^^^^^^^^^^^^^^ -Correct as is. - -By way of -^^^^^^^^^ -Use "using" instead. - -Can/May -^^^^^^^ -Use "can" to describe actions or conditions that are possible. Use "may" only to describe situations where permission is being given. If either "can," "could," or "may" apply, use "can" because it's less tentative. - -CD or cd -^^^^^^^^ -When referring to a compact disk, use CD, such as "Insert the CD into the CD-ROM drive." When referring to the change directory command, use cd. - -CD-ROM -^^^^^^ -Correct. Do not use "cdrom," "CD-Rom," "CDROM," "cd-rom" or any other variation. When referring to the drive, use CD-ROM drive, such as "Insert the CD into the CD-ROM drive." The plural is "CD-ROMs." - - -Command line -^^^^^^^^^^^^ -Correct. Do not use "command-line" or "commandline" as a noun. If used as an adjective, "command-line" is appropriate, for example "command-line arguments". - -Use "command line" to describes where to place options for a command, but not where to type the command. Use "shell prompt" instead to describe where to type commands. The line on the display screen where a command is expected. Generally, the command line is the line that contains the most recently displayed command prompt. - - -Daylight saving time (DST) -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled "Daylight Savings", with an "s" at the end. Other common variations are "Summer Time"and "Daylight-Saving Time". (https://www.timeanddate.com/time/dst/daylight-savings-time.html) - - -Download -^^^^^^^^ -Correct. Do not use "down load" or "down-load." - -e.g. -^^^^ -Spell it out: "For example." - -Failover -^^^^^^^^ -When used as a noun, a failover is a backup operation that automatically switches to a standby database, server or network if the primary system fails or is temporarily shut down for servicing. Failover is an important fault tolerance function of mission-critical systems that rely on constant accessibility. Failover automatically and transparently to the user redirects requests from the failed or down system to the backup system that mimics the operations of the primary system. - -Fail over -^^^^^^^^^ -When used as a verb, fail over is two words since there can be different tenses such as failed over. - -Fewer -^^^^^ -Fewer is used with plural nouns. Think things you could count. Time, money, distance, and weight are often listed as exceptions to the traditional "can you count it" rule, often thought of a singular amounts (the work will take less than 5 hours, for example). - -File name -^^^^^^^^^ -Correct. Do not use "filename." - -File system -^^^^^^^^^^^ -Correct. Do not use "filesystem." The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure. Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection. - -For instance -^^^^^^^^^^^^ -For example," instead. - -For further/additional/whatever information -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use "For more information" - -For this reason -^^^^^^^^^^^^^^^ -Use "therefore". - -Forward -^^^^^^^ -Correct. Avoid using "forwards." - -Gigabyte (GB) -^^^^^^^^^^^^^ -2 to the 30th power (1,073,741,824) bytes. One gigabyte is equal to 1,024 megabytes. Gigabyte is often abbreviated as G or GB. - -Got -^^^ -Avoid. Use "must" instead. - -High-availability -^^^^^^^^^^^^^^^^^ -Correct. Do not use "high availability." - -Highly available -^^^^^^^^^^^^^^^^ -Correct. Do not use highly-available." - -Hostname -^^^^^^^^ -Correct. Do not use host name. - -i.e. -^^^^ -Spell it out: "That is." - -Installer -^^^^^^^^^ -Avoid. Use "installation program" instead. - -It's and its -^^^^^^^^^^^^ -"It's" is a contraction for "it is;" use "it is" instead of "it's." Use "its" as a possessive pronoun (for example, "the store is known for its low prices"). - -Less -^^^^ -Less is used with singular nouns. For example "View less details" wouldn't be correct but "View less detail" works. Use fewer when you have plural nouns (things you can count). - -Linux -^^^^^ -Correct. Do not use "LINUX" or "linux" unless referring to a command, such as "To start Linux, type linux." Linux is a registered trademark of Linus Torvalds. - -Login -^^^^^ -A noun used to refer to the login prompt, such as "At the login prompt, enter your username." - -Log in -^^^^^^ -A verb used to refer to the act of logging in. Do not use "login," "loggin," "logon," and other variants. For example, "When starting your computer, you are requested to log in..." - -Log on -^^^^^^ -To make a computer system or network recognize you so that you can begin a computer session. Most personal computers have no log-on procedure -- you just turn the machine on and begin working. For larger systems and networks, however, you usually need to enter a username and password before the computer system will allow you to execute programs. - -Lots of -^^^^^^^ -Use "Several" or something equivalent instead. - -Make sure -^^^^^^^^^ -This means "be careful to remember, attend to, or find out something." For example, "...make sure that the rhedk group is listed in the output." -Try to use verify or ensure instead. - -Manual/man page -^^^^^^^^^^^^^^^ -Correct. Two words. Do not use "manpage" - -MB -^^ -(1) When spelled MB, short for megabyte (1,000,000 or 1,048,576 bytes, depending on the context). -(2) When spelled Mb, short for megabit. - -MBps -^^^^ -Short for megabytes per second, a measure of data transfer speed. Mass storage devices are generally measured in MBps. - -MySQL -^^^^^ -Common open source database server and client package. Do not use "MYSQL" or "mySQL." - -Need to -^^^^^^^ -Avoid. Use "must" instead. - -Read-only -^^^^^^^^^ -Correct. Use when referring to the access permissions of files or directories. - -Real time/real-time -^^^^^^^^^^^^^^^^^^^ -Depends. If used as a noun, it is the actual time during which something takes place. For example, "The computer may partly analyze the data in real time (as it comes in) -- R. H. March." If used as an adjective, "real-time" is appropriate. For example, "XEmacs is a self-documenting, customizable, extensible, real-time display editor." - -Refer to -^^^^^^^^ -Use to indicate a reference (within a manual or website) or a cross-reference (to another manual or documentation source). - -See -^^^ -Don't use. Use "Refer to" instead. - -Since -^^^^^ -This is often used to mean "because", but "since" has connotations of time, so be careful. If you mean "because", say "because". - -Tells -^^^^^ -Use "Instructs" instead. - -That/which -^^^^^^^^^^ -"That" introduces a restrictive clause-a clause that must be there for the sentence to make sense. A restrictive clause often defines the noun or phrase preceding it. "Which" introduces a non-restrictive, parenthetical clause-a clause that could be omitted without affecting the meaning of the sentence. For example: The car was travelling at a speed that would endanger lives. The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk. Use "who" or "whom," rather than "that" or "which," when referring to a person. - -Then/than -^^^^^^^^^ - "Then" refers to a time in the past or the next step in a sequence. "Than" is used for comparisons. - -.. image:: images/thenvsthan.jpg - -Third-party -^^^^^^^^^^^ -Correct. Do not use "third party". - -Troubleshoot -^^^^^^^^^^^^ -Correct. Do not use "trouble shoot" or "trouble-shoot." To isolate the source of a problem and fix it. In the case of computer systems, the term troubleshoot is usually used when the problem is suspected to be hardware -related. If the problem is known to be in software, the term debug is more commonly used. - -UK -^^ -Correct as is, no periods. - -UNIX® -^^^^^ -Correct. Do not use "Unix" or "unix." UNIX® is a registered trademark of The Open Group. - -Unset -^^^^^ -Don't use. Use Clear. - -US -^^ -Correct as is, no periods. - -User -^^^^ -When referring to the reader, use "you" instead of "user." For example, "The user must..." is incorrect. Use "You must..." instead. If referring to more than one user, calling the collection "users" is acceptable, such as "Other users may wish to access your database." - -Username -^^^^^^^^ -Correct. Do not use "user name." - -View -^^^^ -When using as a reference ("View the documentation available online."), do not use View. Use "Refer to" instead. - -Within -^^^^^^ -Don't use to refer to a file that exists in a directory. Use "In". - -World Wide Web -^^^^^^^^^^^^^^ -Correct. Capitalize each word. Abbreviate as "WWW" or "Web." - -Webpage -^^^^^^^ -Correct. Do not use "web page" or "Web page." - -Web server -^^^^^^^^^^ -Correct. Do not use "webserver". For example, "The Apache HTTP Server is the default Web server..." - -Website -^^^^^^^ -Correct. Do not use "web site" or "Web site." For example, "The Ansible website contains ..." - -Who/whom -^^^^^^^^ -Use the pronoun "who" as a subject. Use the pronoun "whom" as a direct object, an indirect object, or the object of a preposition. For example: Who owns this? To whom does this belong? - -Will -^^^^ -Do not use future tense unless it is absolutely necessary. For instance, do not use the sentence, "The next section will describe the process in more detail." Instead, use the sentence, "The next section describes the process in more detail." - -Wish -^^^^ -Use "need" instead of "desire" and "wish." Use "want" when the reader's actions are optional (that is, they may not "need" something but may still "want" something). - -x86 -^^^ -Correct. Do not capitalize the "x." - -x86_64 -^^^^^^ -Do not use. Do not use "Hammer". Always use "AMD64 and Intel® EM64T" when referring to this architecture. - -You -^^^ -Correct. Do not use "I," "he," or "she." - -You may -^^^^^^^ -Try to avoid using this. For example, "you may" can be eliminated from this sentence "You may double-click on the desktop..." - diff --git a/docs/docsite/rst/dev_guide/style_guide/trademarks.rst b/docs/docsite/rst/dev_guide/style_guide/trademarks.rst deleted file mode 100644 index 6e1fb276d3a..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/trademarks.rst +++ /dev/null @@ -1,95 +0,0 @@ - -Trademark Usage ---------------- -Why is it important to use the TM, SM, and ® for our registered marks? - -Before a trademark is registered with the United States Patent and Trademark Office it is appropriate to use the TM or SM symbol depending whether the product is for goods or services. It is important to use the TM or SM as it is notification to the public that Ansible claims rights to the mark even though it has not yet been registered. - -Once the trademark is registered, it is appropriate to use the symbol in place of the TM or SM. The symbol designation must be used in conjunction with the trademark if Ansible is to fully protect its rights. If we don't protect these marks, we run the risk of losing them in the way of Aspirin or Trampoline or Escalator. - -General Rules: -^^^^^^^^^^^^^^ - -Trademarks should be used on 1st references on a page or within a section. - -Use Red Hat® Ansible® Automation Platform or Ansible®, on first reference when referring to products. - -Use "Ansible" alone as the company name, as in "Ansible announced quarterly results," which is not marked. - -Also add the trademark disclaimer. -* When using Ansible trademarks in the body of written text, you should use the following credit line in a prominent place, usually a footnote. - - For Registered Trademarks: - - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries. - - For Unregistered Trademarks (TMs/SMs): - - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries. - - For registered and unregistered trademarks: - - [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries. - -Guidelines for the proper use of trademarks: -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Always distinguish trademarks from surround text with at least initial capital letters or in all capital letters. - -Always use proper trademark form and spelling. - -Never use a trademark as a noun. Always use a trademark as an adjective modifying the noun. - - Correct: - Red Hat® Ansible® Automation Platform system performance is incredible. - - Incorrect: - Ansible's performance is incredible. - -Never use a trademark as a verb. Trademarks are products or services, never actions. - - Correct: - "Orchestrate your entire network using Red Hat® Ansible® Automation Platform." - - Incorrect: - "Ansible your entire network." - -Never modify a trademark to a plural form. Instead, change the generic word from the singular to the plural. - - Correct: - "Corporate demand for Red Hat® Ansible® Automation Platform software is surging." - - Incorrect: - "Corporate demand for Ansible is surging." - -Never modify a trademark from its possessive form, or make a trademark possessive. Always use it in the form it has been registered. - -Never translate a trademark into another language. - -Never use trademarks to coin new words or names. - -Never use trademarks to create a play on words. - -Never alter a trademark in any way including through unapproved fonts or visual identifiers. - -Never abbreviate or use any Ansible trademarks as an acronym. - -The importance of Ansible trademarks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Ansible trademark and the "A" logo in a shaded circle are our most valuable assets. The value of these trademarks encompass the Ansible Brand. Effective trademark use is more than just a name, it defines the level of quality the customer will receive and it ties a product or service to a corporate image. A trademark may serve as the basis for many of our everyday decisions and choices. The Ansible Brand is about how we treat customers and each other. In order to continue to build a stronger more valuable Brand we must use it in a clear and consistent manner. - -The mark consists of the letter "A" in a shaded circle. As of 5/11/15, this was a pending trademark (registration in process). - -Common Ansible Trademarks -^^^^^^^^^^^^^^^^^^^^^^^^^ -* Ansible® - -Other Common Trademarks and Resource Sites: -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Linux is a registered trademark of Linus Torvalds. -- UNIX® is a registered trademark of The Open Group. -- Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx -- Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html -- Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html -- Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html -- IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml -- Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html - diff --git a/docs/docsite/rst/dev_guide/style_guide/voice_style.rst b/docs/docsite/rst/dev_guide/style_guide/voice_style.rst deleted file mode 100644 index b15029df2fa..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/voice_style.rst +++ /dev/null @@ -1,20 +0,0 @@ - -Voice Style -=========== -The essence of the Ansible writing style is short sentences that flow naturally together. Mix up sentence structures. Vary sentence subjects. Address the reader directly. Ask a question. And when the reader adjusts to the pace of shorter sentences, write a longer one. - -- Write how real people speak... -- ...but try to avoid slang and colloquialisms that might not translate well into other languages. -- Say big things with small words. -- Be direct. Tell the reader exactly what you want them to do. -- Be honest. -- Short sentences show confidence. -- Grammar rules are meant to be bent, but only if the reader knows you are doing this. -- Choose words with fewer syllables for faster reading and better understanding. -- Think of copy as one-on-one conversations rather than as a speech. It's more difficult to ignore someone who is speaking to you directly. -- When possible, start task-oriented sentences (those that direct a user to do something) with action words. For example: Find software... Contact support... Install the media.... and so forth. - -Active Voice ------------- -Use the active voice ("Start Linuxconf by typing...") rather than passive ("Linuxconf can be started by typing...") whenever possible. Active voice makes for more lively, interesting reading. -Also avoid future tense (or using the term "will") whenever possible For example, future tense ("The screen will display...") does not read as well as an active voice ("The screen displays"). Remember, the users you are writing for most often refer to the documentation while they are using the system, not after or in advance of using the system. diff --git a/docs/docsite/rst/dev_guide/style_guide/why_use.rst b/docs/docsite/rst/dev_guide/style_guide/why_use.rst deleted file mode 100644 index 8ed840ac36a..00000000000 --- a/docs/docsite/rst/dev_guide/style_guide/why_use.rst +++ /dev/null @@ -1,23 +0,0 @@ -:orphan: - -Why Use a Style Guide? -"""""""""""""""""""""" - -Style guides are important because they ensure consistency in the content, look, and feel of a book or a website. - -Remember, a style guide is only useful if it is used, updated, and enforced. Style Guides are useful for engineering-related documentation, sales and marketing materials, support docs, community contributions, and more. - -As changes are made to the overall Ansible site design, be sure to update this style guide with those changes. Or, should other resources listed below have major revisions, consider including company information here for ease of reference. - -This style guide incorporates current Ansible resources and information so that overall site and documentation consistency can be met. - -.. raw:: html - -
    - - "If you don't find it in the index, look very carefully through the entire catalogue." - ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue - -.. raw:: html - -
    diff --git a/docs/docsite/rst/dev_guide/testing.rst b/docs/docsite/rst/dev_guide/testing.rst deleted file mode 100644 index 6b4716ddfec..00000000000 --- a/docs/docsite/rst/dev_guide/testing.rst +++ /dev/null @@ -1,245 +0,0 @@ -.. _developing_testing: - -*************** -Testing Ansible -*************** - -.. contents:: - :local: - - -Why test your Ansible contributions? -==================================== - -If you're a developer, one of the most valuable things you can do is to look at GitHub issues and help fix bugs, since bug-fixing is almost always prioritized over feature development. Even for non-developers, helping to test pull requests for bug fixes and features is still immensely valuable. - -Ansible users who understand how to write playbooks and roles should be able to test their work. GitHub pull requests will automatically run a variety of tests (for example, Azure Pipelines) that show bugs in action. However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged. - -Read on to learn how Ansible is tested, how to test your contributions locally, and how to extend testing capabilities. - -If you want to learn about testing collections, read :ref:`testing_collections` - - - -Types of tests -============== - -At a high level we have the following classifications of tests: - -:sanity: - * :ref:`testing_sanity` - * Sanity tests are made up of scripts and tools used to perform static code analysis. - * The primary purpose of these tests is to enforce Ansible coding standards and requirements. -:integration: - * :ref:`testing_integration` - * Functional tests of modules and Ansible core functionality. -:units: - * :ref:`testing_units` - * Tests directly against individual parts of the code base. - - -Testing within GitHub & Azure Pipelines -======================================= - - -Organization ------------- - -When Pull Requests (PRs) are created they are tested using Azure Pipelines, a Continuous Integration (CI) tool. Results are shown at the end of every PR. - -When Azure Pipelines detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example: - -.. code-block:: text - - The test `ansible-test sanity --test pep8` failed with the following errors: - - lib/ansible/modules/network/foo/bar.py:509:17: E265 block comment should start with '# ' - - The test `ansible-test sanity --test validate-modules` failed with the following error: - lib/ansible/modules/network/foo/bar.py:0:0: E307 version_added should be 2.4. Currently 2.3 - -From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Azure Pipelines, for example: - -If you haven't already got Ansible available, use the local checkout by running: - -.. code-block:: shell-session - - source hacking/env-setup - -Then run the tests detailed in the GitHub comment: - -.. code-block:: shell-session - - ansible-test sanity --test pep8 - ansible-test sanity --test validate-modules - -If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the "Details" button under the "checks have failed" message at the end of the PR. - -Rerunning a failing CI job --------------------------- - -Occasionally you may find your PR fails due to a reason unrelated to your change. This could happen for several reasons, including: - -* a temporary issue accessing an external resource, such as a yum or git repo -* a timeout creating a virtual machine to run the tests on - -If either of these issues appear to be the case, you can rerun the Azure Pipelines test by: - -* adding a comment with ``/rebuild`` (full rebuild) or ``/rebuild_failed`` (rebuild only failed CI nodes) to the PR -* closing and re-opening the PR (full rebuild) -* making another change to the PR and pushing to GitHub - -If the issue persists, please contact us in the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - - -How to test a PR -================ - -Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well. - -Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works. - -Setup: Checking out a Pull Request ----------------------------------- - -You can do this by: - -* checking out Ansible -* fetching the proposed changes into a test branch -* testing -* commenting on that particular issue on GitHub - -Here's how: - -.. warning:: - Testing source code from GitHub pull requests sent to us does have some inherent risk, as the source code - sent may have mistakes or malicious code that could have a negative impact on your system. We recommend - doing all testing on a virtual machine, whether a cloud instance, or locally. Some users like Vagrant - or Docker for this, but they are optional. It is also useful to have virtual machines of different Linux or - other flavors, since some features (for example, package managers such as apt or yum) are specific to those OS versions. - - -Create a fresh area to work: - -.. code-block:: shell-session - - git clone https://github.com/ansible/ansible.git ansible-pr-testing - cd ansible-pr-testing - -Next, find the pull request you'd like to test and make note of its number. It will look something like this: - -.. code-block:: text - - Use os.path.sep instead of hardcoding / #65381 - -.. note:: Only test ``ansible:devel`` - - It is important that the PR request target be ``ansible:devel``, as we do not accept pull requests into any other branch. Dot releases are cherry-picked manually by Ansible staff. - -Use the pull request number when you fetch the proposed changes and create your branch for testing: - -.. code-block:: shell-session - - git fetch origin refs/pull/XXXX/head:testing_PRXXXX - git checkout testing_PRXXXX - -The first command fetches the proposed changes from the pull request and creates a new branch named ``testing_PRXXXX``, where the XXXX is the actual number associated with the pull request (for example, 65381). The second command checks out the newly created branch. - -.. note:: - If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor. - -.. note:: - Some users do not create feature branches, which can cause problems when they have multiple, unrelated commits in their version of ``devel``. If the source looks like ``someuser:devel``, make sure there is only one commit listed on the pull request. - -The Ansible source includes a script that allows you to use Ansible directly from source without requiring a -full installation that is frequently used by developers on Ansible. - -Simply source it (to use the Linux/Unix terminology) to begin using it immediately: - -.. code-block:: shell-session - - source ./hacking/env-setup - -This script modifies the ``PYTHONPATH`` environment variables (along with a few other things), which will be temporarily -set as long as your shell session is open. - -Testing the Pull Request ------------------------- - -At this point, you should be ready to begin testing! - -Some ideas of what to test are: - -* Create a test Playbook with the examples in and check if they function correctly -* Test to see if any Python backtraces returned (that's a bug) -* Test on different operating systems, or against different library versions - -Run sanity tests -^^^^^^^^^^^^^^^^ - -.. code:: shell - - ansible-test sanity - -More information: :ref:`testing_sanity` - -Run unit tests -^^^^^^^^^^^^^^ - -.. code:: shell - - ansible-test units - -More information: :ref:`testing_units` - -Run integration tests -^^^^^^^^^^^^^^^^^^^^^ - -.. code:: shell - - ansible-test integration -v ping - -More information: :ref:`testing_integration` - -Any potential issues should be added as comments on the pull request (and it's acceptable to comment if the feature works as well), remembering to include the output of ``ansible --version`` - -Example: - -.. code-block:: text - - Works for me! Tested on `Ansible 2.3.0`. I verified this on CentOS 6.5 and also Ubuntu 14.04. - -If the PR does not resolve the issue, or if you see any failures from the unit/integration tests, just include that output instead: - - | This change causes errors for me. - | - | When I ran this Ubuntu 16.04 it failed with the following: - | - | \``` - | some output - | StackTrace - | some other output - | \``` - -Code Coverage Online -^^^^^^^^^^^^^^^^^^^^ - -`The online code coverage reports `_ are a good way -to identify areas for testing improvement in Ansible. By following red colors you can -drill down through the reports to find files which have no tests at all. Adding both -integration and unit tests which show clearly how code should work, verify important -Ansible functions and increase testing coverage in areas where there is none is a valuable -way to help improve Ansible. - -The code coverage reports only cover the ``devel`` branch of Ansible where new feature -development takes place. Pull requests and new code will be missing from the codecov.io -coverage reports so local reporting is needed. Most ``ansible-test`` commands allow you -to collect code coverage, this is particularly useful to indicate where to extend -testing. See :ref:`testing_running_locally` for more information. - - -Want to know more about testing? -================================ - -If you'd like to know more about the plans for improving testing Ansible then why not join the -`Testing Working Group `_. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/action-plugin-docs.rst b/docs/docsite/rst/dev_guide/testing/sanity/action-plugin-docs.rst deleted file mode 100644 index e3a5d8b838d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/action-plugin-docs.rst +++ /dev/null @@ -1,4 +0,0 @@ -action-plugin-docs -================== - -Each action plugin should have a matching module of the same name to provide documentation. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-doc.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-doc.rst deleted file mode 100644 index 9f2c4f5f458..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-doc.rst +++ /dev/null @@ -1,4 +0,0 @@ -ansible-doc -=========== - -Verifies that ``ansible-doc`` can parse module documentation on all supported Python versions. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-requirements.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-requirements.rst deleted file mode 100644 index f348b07f00b..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-requirements.rst +++ /dev/null @@ -1,4 +0,0 @@ -ansible-requirements -==================== - -``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` must be an identical copy of ``requirements.txt`` found in the project's root. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst deleted file mode 100644 index 43dfe324650..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst +++ /dev/null @@ -1,8 +0,0 @@ -ansible-test-future-boilerplate -=============================== - -The ``_internal`` code for ``ansible-test`` requires the following ``__future__`` import: - -.. code-block:: python - - from __future__ import annotations diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst b/docs/docsite/rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst deleted file mode 100644 index 1906886f4ff..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -ansible-var-precedence-check -============================ - -Check the order of precedence for Ansible variables against :ref:`ansible_variable_precedence`. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst b/docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst deleted file mode 100644 index 5e0cc04444c..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst +++ /dev/null @@ -1,10 +0,0 @@ -:orphan: - -azure-requirements -================== - -Update the Azure integration test requirements file when changes are made to the Azure packaging requirements file: - -.. code-block:: bash - - cp packaging/requirements/requirements-azure.txt test/lib/ansible_test/_data/requirements/integration.cloud.azure.txt diff --git a/docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst b/docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst deleted file mode 100644 index a8e33a7f445..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst +++ /dev/null @@ -1,11 +0,0 @@ -bin-symlinks -============ - -The ``bin/`` directory in Ansible must contain only symbolic links to executable files. -These files must reside in the ``lib/ansible/`` or ``test/lib/ansible_test/`` directories. - -This is required to allow ``ansible-test`` to work with containers and remote hosts when running from an installed version of Ansible. - -Symlinks for each entry point in ``bin/`` must also be present in ``test/lib/ansible_test/_util/target/injector/``. -Each symlink should point to the ``python.py`` script in the same directory. -This facilitates running with the correct Python interpreter and enabling code coverage. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/boilerplate.rst deleted file mode 100644 index 51c0c089428..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/boilerplate.rst +++ /dev/null @@ -1,11 +0,0 @@ -:orphan: - -boilerplate -=========== - -Most Python files should include the following boilerplate: - -.. code-block:: python - - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type diff --git a/docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst b/docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst deleted file mode 100644 index 639bb0bf017..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst +++ /dev/null @@ -1,4 +0,0 @@ -botmeta -======= - -Verifies that ``./github/BOTMETA.yml`` is valid. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/changelog.rst b/docs/docsite/rst/dev_guide/testing/sanity/changelog.rst deleted file mode 100644 index 2d557c72d5f..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/changelog.rst +++ /dev/null @@ -1,19 +0,0 @@ -changelog -========= - -Basic linting of changelog fragments with `antsibull-changelog lint `_. - -One or more of the following sections are required: - -- major_changes -- minor_changes -- breaking_changes -- deprecated_features -- removed_features -- security_fixes -- bugfixes -- known_issues - -New modules and plugins must not be included in changelog fragments. - -See :ref:`collection_changelogs` for details. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/compile.rst b/docs/docsite/rst/dev_guide/testing/sanity/compile.rst deleted file mode 100644 index 40367218cdf..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/compile.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _testing_compile: - -compile -======= - -All Python source files must successfully compile using all supported Python versions. - -.. note:: - - The list of supported Python versions is dependent on the version of ``ansible-core`` that you are using. - Make sure you consult the version of the documentation which matches your ``ansible-core`` version. - -Controller code, including plugins in Ansible Collections, must support the following Python versions: - -- 3.11 -- 3.10 -- 3.9 - -Code which runs on targets (``modules`` and ``module_utils``) must support all controller supported Python versions, -as well as the additional Python versions supported only on targets: - -- 3.8 -- 3.7 -- 3.6 -- 3.5 -- 2.7 - -.. note:: - - Ansible Collections can be - `configured `_ - to support a subset of the target-only Python versions. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/configure-remoting-ps1.rst b/docs/docsite/rst/dev_guide/testing/sanity/configure-remoting-ps1.rst deleted file mode 100644 index e83bc78d897..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/configure-remoting-ps1.rst +++ /dev/null @@ -1,5 +0,0 @@ -configure-remoting-ps1 -====================== - -The file ``examples/scripts/ConfigureRemotingForAnsible.ps1`` is required and must be a regular file. -It is used by external automated processes and cannot be moved, renamed or replaced with a symbolic link. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/deprecated-config.rst b/docs/docsite/rst/dev_guide/testing/sanity/deprecated-config.rst deleted file mode 100644 index 950805a282d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/deprecated-config.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -deprecated-config -================= - -``DOCUMENTATION`` config is scheduled for removal diff --git a/docs/docsite/rst/dev_guide/testing/sanity/docs-build.rst b/docs/docsite/rst/dev_guide/testing/sanity/docs-build.rst deleted file mode 100644 index 23f3c5524ba..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/docs-build.rst +++ /dev/null @@ -1,4 +0,0 @@ -docs-build -========== - -Verifies that ``make singlehtmldocs`` in ``docs/docsite/`` completes without errors. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/empty-init.rst b/docs/docsite/rst/dev_guide/testing/sanity/empty-init.rst deleted file mode 100644 index e87bb71ed60..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/empty-init.rst +++ /dev/null @@ -1,10 +0,0 @@ -empty-init -========== - -The ``__init__.py`` files under the following directories must be empty. For some of these (modules -and tests), ``__init__.py`` files with code won't be used. For others (module_utils), we want the -possibility of using Python namespaces which an empty ``__init__.py`` will allow for. - -- ``lib/ansible/modules/`` -- ``lib/ansible/module_utils/`` -- ``test/units/`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst deleted file mode 100644 index 658ef064442..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst +++ /dev/null @@ -1,51 +0,0 @@ -future-import-boilerplate -========================= - -Most Python files should include the following boilerplate at the top of the file, right after the -comment header: - -.. code-block:: python - - from __future__ import (absolute_import, division, print_function) - -This uses Python 3 semantics for absolute versus relative imports, division, and print. By doing this, -we can write code which is portable between Python 2 and Python 3 by following the Python 3 semantics. - - -absolute_import ---------------- - -When Python 2 encounters an import of a name in a file like ``import copy`` it attempts to load -``copy.py`` from the same directory as the file is in. This can cause problems if there is a python -file of that name in the directory and also a python module in ``sys.path`` with that same name. In -that case, Python 2 would load the one in the same directory and there would be no way to load the -one on ``sys.path``. Python 3 fixes this by making imports absolute by default. ``import copy`` -will find ``copy.py`` from ``sys.path``. If you want to import ``copy.py`` from the same directory, -the code needs to be changed to perform a relative import: ``from . import copy``. - -.. seealso:: - - * `Absolute and relative imports `_ - -division --------- - -In Python 2, the division operator (``/``) returns integer values when used with integers. If there -was a remainder, this part would be left off (aka, `floor division`). In Python 3, the division -operator (``/``) always returns a floating point number. Code that needs to calculate the integer -portion of the quotient needs to switch to using the floor division operator (`//`) instead. - -.. seealso:: - - * `Changing the division operator `_ - -print_function --------------- - -In Python 2, :func:`python:print` is a keyword. In Python 3, :func:`python3:print` is a function with different -parameters. Using this ``__future__`` allows using the Python 3 print semantics everywhere. - -.. seealso:: - - * `Make print a function `_ - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/ignores.rst b/docs/docsite/rst/dev_guide/testing/sanity/ignores.rst deleted file mode 100644 index 69190c8d739..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/ignores.rst +++ /dev/null @@ -1,105 +0,0 @@ -ignores -======= - -Sanity tests for individual files can be skipped, and specific errors can be ignored. - -When to Ignore Errors ---------------------- - -Sanity tests are designed to improve code quality and identify common issues with content. -When issues are identified during development, those issues should be corrected. - -As development of Ansible continues, sanity tests are expanded to detect issues that previous releases could not. -To allow time for existing content to be updated to pass newer tests, ignore entries can be added. -New content should not use ignores for existing sanity tests. - -When code is fixed to resolve sanity test errors, any relevant ignores must also be removed. -If the ignores are not removed, this will be reported as an unnecessary ignore error. -This is intended to prevent future regressions due to the same error recurring after being fixed. - -When to Skip Tests ------------------- - -Although rare, there are reasons for skipping a sanity test instead of ignoring the errors it reports. - -If a sanity test results in a traceback when processing content, that error cannot be ignored. -If this occurs, open a new `bug report `_ for the issue so it can be fixed. -If the traceback occurs due to an issue with the content, that issue should be fixed. -If the content is correct, the test will need to be skipped until the bug in the sanity test is fixed. - - Caution should be used when skipping sanity tests instead of ignoring them. - Since the test is skipped entirely, resolution of the issue will not be automatically detected. - This will prevent prevent regression detection from working once the issue has been resolved. - For this reason it is a good idea to periodically review skipped entries manually to verify they are required. - -Ignore File Location --------------------- - -The location of the ignore file depends on the type of content being tested. - -Ansible Collections -^^^^^^^^^^^^^^^^^^^ - -Since sanity tests change between Ansible releases, a separate ignore file is needed for each Ansible major release. - -The filename is ``tests/sanity/ignore-X.Y.txt`` where ``X.Y`` is the Ansible release being used to test the collection. - -Maintaining a separate file for each Ansible release allows a collection to pass tests for multiple versions of Ansible. - -Ansible -^^^^^^^ - -When testing Ansible, all ignores are placed in the ``test/sanity/ignore.txt`` file. - -Only a single file is needed because ``ansible-test`` is developed and released as a part of Ansible itself. - -Ignore File Format ------------------- - -The ignore file contains one entry per line. -Each line consists of two columns, separated by a single space. -Comments may be added at the end of an entry, started with a hash (``#``) character, which can be proceeded by zero or more spaces. -Blank and comment only lines are not allowed. - -The first column specifies the file path that the entry applies to. -File paths must be relative to the root of the content being tested. -This is either the Ansible source or an Ansible collection. -File paths cannot contain a space or the hash (``#``) character. - -The second column specifies the sanity test that the entry applies to. -This will be the name of the sanity test. -If the sanity test is specific to a version of Python, the name will include a dash (``-``) and the relevant Python version. -If the named test uses error codes then the error code to ignore must be appended to the name of the test, separated by a colon (``:``). - -Below are some example ignore entries for an Ansible collection: - -.. code-block:: text - - roles/my_role/files/my_script.sh shellcheck:SC2154 # ignore undefined variable - plugins/modules/my_module.py validate-modules:missing-gplv3-license # ignore license check - plugins/modules/my_module.py import-3.8 # needs update to support collections.abc on Python 3.8+ - -It is also possible to skip a sanity test for a specific file. -This is done by adding ``!skip`` after the sanity test name in the second column. -When this is done, no error code is included, even if the sanity test uses error codes. - -Below are some example skip entries for an Ansible collection: - -.. code-block:: text - - plugins/module_utils/my_util.py validate-modules!skip # waiting for bug fix in module validator - plugins/lookup/my_plugin.py compile-2.6!skip # Python 2.6 is not supported on the controller - -See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues. - -Ignore File Errors ------------------- - -There are various errors that can be reported for the ignore file itself: - -- syntax errors parsing the ignore file -- references a file path that does not exist -- references to a sanity test that does not exist -- ignoring an error that does not occur -- ignoring a file which is skipped -- duplicate entries diff --git a/docs/docsite/rst/dev_guide/testing/sanity/import.rst b/docs/docsite/rst/dev_guide/testing/sanity/import.rst deleted file mode 100644 index 6a5d3294503..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/import.rst +++ /dev/null @@ -1,126 +0,0 @@ -import -====== - -Ansible :ref:`allows unchecked imports` of some libraries from specific directories. -Importing any other Python library requires :ref:`handling import errors`. -This enables support for sanity tests such as :ref:`testing_validate-modules` and provides better error messages to the user. - -.. _handling_import_errors: - -Handling import errors ----------------------- - -In modules -^^^^^^^^^^ - -Instead of using ``import another_library``: - -.. code-block:: python - - import traceback - - from ansible.module_utils.basic import missing_required_lib - - try: - import another_library - except ImportError: - HAS_ANOTHER_LIBRARY = False - ANOTHER_LIBRARY_IMPORT_ERROR = traceback.format_exc() - else: - HAS_ANOTHER_LIBRARY = True - ANOTHER_LIBRARY_IMPORT_ERROR = None - -.. note:: - - The ``missing_required_lib`` import above will be used below. - -Then in the module code: - -.. code-block:: python - - module = AnsibleModule(...) - - if not HAS_ANOTHER_LIBRARY: - module.fail_json( - msg=missing_required_lib('another_library'), - exception=ANOTHER_LIBRARY_IMPORT_ERROR) - -In plugins -^^^^^^^^^^ - -Instead of using ``import another_library``: - -.. code-block:: python - - try: - import another_library - except ImportError as imp_exc: - ANOTHER_LIBRARY_IMPORT_ERROR = imp_exc - else: - ANOTHER_LIBRARY_IMPORT_ERROR = None - -Then in the plugin code, for example in ``__init__`` of the plugin: - -.. code-block:: python - - if ANOTHER_LIBRARY_IMPORT_ERROR: - raise AnsibleError('another_library must be installed to use this plugin') from ANOTHER_LIBRARY_IMPORT_ERROR - -When used as base classes -^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. important:: - - This solution builds on the previous two examples. - Make sure to pick the appropriate one before continuing with this solution. - -Sometimes an import is used in a base class, for example: - -.. code-block:: python - - from another_library import UsefulThing - - class CustomThing(UsefulThing): - pass - -One option is make the entire class definition conditional: - -.. code-block:: python - - if not ANOTHER_LIBRARY_IMPORT_ERROR: - class CustomThing(UsefulThing): - pass - -Another option is to define a substitute base class by modifying the exception handler: - -.. code-block:: python - - try: - from another_library import UsefulThing - except ImportError: - class UsefulThing: - pass - ... - -.. _allowed_unchecked_imports: - -Allowed unchecked imports -------------------------- - -Ansible allows the following unchecked imports from these specific directories: - -* ansible-core: - - * For ``lib/ansible/modules/`` and ``lib/ansible/module_utils/``, unchecked imports are only allowed from the Python standard library; - * For ``lib/ansible/plugins/``, unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself; - -* collections: - - * For ``plugins/modules/`` and ``plugins/module_utils/``, unchecked imports are only allowed from the Python standard library; - * For other directories in ``plugins/`` (see `the community collection requirements `_ for a list), unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself. - -Public dependencies of ansible-core are: - - * Jinja2 - * PyYAML - * MarkupSafe (as a dependency of Jinja2) diff --git a/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst b/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst deleted file mode 100644 index e14188d6ccd..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst +++ /dev/null @@ -1,184 +0,0 @@ -integration-aliases -=================== - -Integration tests are executed by ``ansible-test`` and reside in directories under ``test/integration/targets/``. -Each test MUST have an ``aliases`` file to control test execution. - -Aliases are explained in the following sections. Each alias must be on a separate line in an ``aliases`` file. - -Groups ------- - -Tests must be configured to run in exactly one group. This is done by adding the appropriate group to the ``aliases`` file. - -The following are examples of some of the available groups: - -- ``shippable/posix/group1`` -- ``shippable/windows/group2`` -- ``shippable/azure/group3`` -- ``shippable/aws/group1`` -- ``shippable/cloud/group1`` - -Groups are used to balance tests across multiple CI jobs to minimize test run time. -They also improve efficiency by keeping tests with similar requirements running together. - -When selecting a group for a new test, use the same group as existing tests similar to the one being added. -If more than one group is available, select one randomly. - -Setup ------ - -Aliases can be used to execute setup targets before running tests: - -- ``setup/once/TARGET`` - Run the target ``TARGET`` before the first target that requires it. -- ``setup/always/TARGET`` - Run the target ``TARGET`` before each target that requires it. - -Requirements ------------- - -Aliases can be used to express some test requirements: - -- ``needs/privileged`` - Requires ``--docker-privileged`` when running tests with ``--docker``. -- ``needs/root`` - Requires running tests as ``root`` or with ``--docker``. -- ``needs/ssh`` - Requires SSH connections to localhost (or the test container with ``--docker``) without a password. -- ``needs/httptester`` - Requires use of the http-test-container to run tests. - -Dependencies ------------- - -Some test dependencies are automatically discovered: - -- Ansible role dependencies defined in ``meta/main.yml`` files. -- Setup targets defined with ``setup/*`` aliases. -- Symbolic links from one target to a file in another target. - -Aliases can be used to declare dependencies that are not handled automatically: - -- ``needs/target/TARGET`` - Requires use of the test target ``TARGET``. -- ``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the git root. - -Skipping --------- - -Aliases can be used to skip platforms using one of the following: - -- ``skip/freebsd`` - Skip tests on FreeBSD. -- ``skip/osx`` - Skip tests on macOS. -- ``skip/rhel`` - Skip tests on RHEL. -- ``skip/docker`` - Skip tests when running in a Docker container. - -Platform versions, as specified using the ``--remote`` option with ``/`` removed, can also be skipped: - -- ``skip/freebsd11.1`` - Skip tests on FreeBSD 11.1. -- ``skip/rhel7.6`` - Skip tests on RHEL 7.6. - -Windows versions, as specified using the ``--windows`` option can also be skipped: - -- ``skip/windows/2012`` - Skip tests on Windows Server 2012. -- ``skip/windows/2012-R2`` - Skip tests on Windows Server 2012 R2. - -Aliases can be used to skip Python major versions using one of the following: - -- ``skip/python2`` - Skip tests on Python 2.x. -- ``skip/python3`` - Skip tests on Python 3.x. - -For more fine grained skipping, use conditionals in integration test playbooks, such as: - -.. code-block:: yaml - - when: ansible_distribution in ('Ubuntu') - - -Miscellaneous -------------- - -There are several other aliases available as well: - -- ``destructive`` - Requires ``--allow-destructive`` to run without ``--docker`` or ``--remote``. -- ``hidden`` - Target is ignored. Usable as a dependency. Automatic for ``setup_`` and ``prepare_`` prefixed targets. -- ``retry/never`` - Target is excluded from retries enabled by the ``--retry-on-error`` option. - -Unstable --------- - -Tests which fail sometimes should be marked with the ``unstable`` alias until the instability has been fixed. -These tests will continue to run for pull requests which modify the test or the module under test. - -This avoids unnecessary test failures for other pull requests, as well as tests on merge runs and nightly CI jobs. - -There are two ways to run unstable tests manually: - -- Use the ``--allow-unstable`` option for ``ansible-test`` -- Prefix the test name with ``unstable/`` when passing it to ``ansible-test``. - -Tests will be marked as unstable by a member of the Ansible Core Team. -GitHub issues_ will be created to track each unstable test. - -Disabled --------- - -Tests which always fail should be marked with the ``disabled`` alias until they can be fixed. - -Disabled tests are automatically skipped. - -There are two ways to run disabled tests manually: - -- Use the ``--allow-disabled`` option for ``ansible-test`` -- Prefix the test name with ``disabled/`` when passing it to ``ansible-test``. - -Tests will be marked as disabled by a member of the Ansible Core Team. -GitHub issues_ will be created to track each disabled test. - -Unsupported ------------ - -Tests which cannot be run in CI should be marked with the ``unsupported`` alias. -Most tests can be supported through the use of simulators and/or cloud plugins. - -However, if that is not possible then marking a test as unsupported will prevent it from running in CI. - -There are two ways to run unsupported tests manually: - -* Use the ``--allow-unsupported`` option for ``ansible-test`` -* Prefix the test name with ``unsupported/`` when passing it to ``ansible-test``. - -Tests will be marked as unsupported by the contributor of the test. - -Cloud ------ - -Tests for cloud services and other modules that require access to external APIs usually require special support for testing in CI. - -These require an additional alias to indicate the required test plugin. - -Some of the available aliases are: - -- ``cloud/aws`` -- ``cloud/azure`` -- ``cloud/cs`` -- ``cloud/digitalocean`` -- ``cloud/foreman`` -- ``cloud/openshift`` -- ``cloud/tower`` -- ``cloud/vcenter`` - -Untested --------- - -Every module and plugin should have integration tests, even if the tests cannot be run in CI. - -Issues ------- - -Tests that are marked as unstable_ or disabled_ will have an issue created to track the status of the test. -Each issue will be assigned to one of the following projects: - -- `AWS `_ -- `Azure `_ -- `Windows `_ -- `General `_ - -Questions ---------- - -For questions about integration tests reach out to @mattclay or @gundalow on GitHub or the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). diff --git a/docs/docsite/rst/dev_guide/testing/sanity/line-endings.rst b/docs/docsite/rst/dev_guide/testing/sanity/line-endings.rst deleted file mode 100644 index d56cfc12e53..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/line-endings.rst +++ /dev/null @@ -1,4 +0,0 @@ -line-endings -============ - -All files must use ``\n`` for line endings instead of ``\r\n``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/metaclass-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/metaclass-boilerplate.rst deleted file mode 100644 index c7327b39fa1..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/metaclass-boilerplate.rst +++ /dev/null @@ -1,23 +0,0 @@ -metaclass-boilerplate -===================== - -Most Python files should include the following boilerplate at the top of the file, right after the -comment header and ``from __future__ import``: - -.. code-block:: python - - __metaclass__ = type - - -Python 2 has "new-style classes" and "old-style classes" whereas Python 3 only has new-style classes. -Adding the ``__metaclass__ = type`` boilerplate makes every class defined in that file into -a new-style class as well. - -.. code-block:: python - - from __future__ import absolute_import, division, print_function - __metaclass__ = type - - class Foo: - # This is a new-style class even on Python 2 because of the __metaclass__ - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/mypy.rst b/docs/docsite/rst/dev_guide/testing/sanity/mypy.rst deleted file mode 100644 index 9eb46bafca8..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/mypy.rst +++ /dev/null @@ -1,14 +0,0 @@ -mypy -==== - -The ``mypy`` static type checker is used to check the following code against each Python version supported by the controller: - - * ``lib/ansible/`` - * ``test/lib/ansible_test/_internal/`` - -Additionally, the following code is checked against Python versions supported only on managed nodes: - - * ``lib/ansible/modules/`` - * ``lib/ansible/module_utils/`` - -See `the mypy documentation `_ diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst deleted file mode 100644 index 489f917f624..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-assert.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-assert -========= - -Do not use ``assert`` in production Ansible python code. When running Python -with optimizations, Python will remove ``assert`` statements, potentially -allowing for unexpected behavior throughout the Ansible code base. - -Instead of using ``assert`` you should utilize simple ``if`` statements, -that result in raising an exception. There is a new exception called -``AnsibleAssertionError`` that inherits from ``AnsibleError`` and -``AssertionError``. When possible, utilize a more specific exception -than ``AnsibleAssertionError``. - -Modules will not have access to ``AnsibleAssertionError`` and should instead -raise ``AssertionError``, a more specific exception, or just use -``module.fail_json`` at the failure point. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-basestring.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-basestring.rst deleted file mode 100644 index f2fea137ebd..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-basestring.rst +++ /dev/null @@ -1,11 +0,0 @@ -no-basestring -============= - -Do not use ``isinstance(s, basestring)`` as basestring has been removed in -Python3. You can import ``string_types``, ``binary_type``, or ``text_type`` -from ``ansible.module_utils.six`` and then use ``isinstance(s, string_types)`` -or ``isinstance(s, (binary_type, text_type))`` instead. - -If this is part of code to convert a string to a particular type, -``ansible.module_utils.common.text.converters`` contains several functions -that may be even better for you: ``to_text``, ``to_bytes``, and ``to_native``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iteritems.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iteritems.rst deleted file mode 100644 index e231c796c47..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iteritems.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-dict-iteritems -================= - -The ``dict.iteritems`` method has been removed in Python 3. There are two recommended alternatives: - -.. code-block:: python - - for KEY, VALUE in DICT.items(): - pass - -.. code-block:: python - - from ansible.module_utils.six import iteritems - - for KEY, VALUE in iteritems(DICT): - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iterkeys.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iterkeys.rst deleted file mode 100644 index 9dc4a978550..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-iterkeys.rst +++ /dev/null @@ -1,9 +0,0 @@ -no-dict-iterkeys -================ - -The ``dict.iterkeys`` method has been removed in Python 3. Use the following instead: - -.. code-block:: python - - for KEY in DICT: - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-itervalues.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-dict-itervalues.rst deleted file mode 100644 index 979450e418d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-dict-itervalues.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-dict-itervalues -================== - -The ``dict.itervalues`` method has been removed in Python 3. There are two recommended alternatives: - -.. code-block:: python - - for VALUE in DICT.values(): - pass - -.. code-block:: python - - from ansible.module_utils.six import itervalues - - for VALUE in itervalues(DICT): - pass diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-get-exception.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-get-exception.rst deleted file mode 100644 index 67f1646f21a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-get-exception.rst +++ /dev/null @@ -1,28 +0,0 @@ -no-get-exception -================ - -We created a function, ``ansible.module_utils.pycompat24.get_exception`` to -help retrieve exceptions in a manner compatible with Python 2.4 through -Python 3.6. We no longer support Python 2.4 and Python 2.5 so this is -extraneous and we want to deprecate the function. Porting code should look -something like this: - -.. code-block:: python - - # Unfixed code: - try: - raise IOError('test') - except IOError: - e = get_exception() - do_something(e) - except: - e = get_exception() - do_something_else(e) - - # After fixing: - try: - raise IOError('test') - except IOErrors as e: - do_something(e) - except Exception as e: - do_something_else(e) diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-illegal-filenames.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-illegal-filenames.rst deleted file mode 100644 index 6e6f565eed8..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-illegal-filenames.rst +++ /dev/null @@ -1,61 +0,0 @@ -no-illegal-filenames -==================== - -Files and directories should not contain illegal characters or names so that -Ansible can be checked out on any Operating System. - -Illegal Characters ------------------- - -The following characters are not allowed to be used in any part of the file or -directory name; - -* ``<`` -* ``>`` -* ``:`` -* ``"`` -* ``/`` -* ``\`` -* ``|`` -* ``?`` -* ``*`` -* Any characters whose integer representations are in the range from 0 through to 31 like ``\n`` - -The following characters are not allowed to be used as the last character of a -file or directory; - -* ``.`` -* ``" "`` (just the space character) - -Illegal Names -------------- - -The following names are not allowed to be used as the name of a file or -directory excluding the extension; - -* ``CON`` -* ``PRN`` -* ``AUX`` -* ``NUL`` -* ``COM1`` -* ``COM2`` -* ``COM3`` -* ``COM4`` -* ``COM5`` -* ``COM6`` -* ``COM7`` -* ``COM8`` -* ``COM9`` -* ``LPT1`` -* ``LPT2`` -* ``LPT3`` -* ``LPT4`` -* ``LPT5`` -* ``LPT6`` -* ``LPT7`` -* ``LPT8`` -* ``LPT9`` - -For example, the file ``folder/COM1``, ``folder/COM1.txt`` are illegal but -``folder/COM1-file`` or ``folder/COM1-file.txt`` is allowed. - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst deleted file mode 100644 index 271f88f1889..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst +++ /dev/null @@ -1,14 +0,0 @@ -no-main-display -=============== - -As of Ansible 2.8, ``Display`` should no longer be imported from ``__main__``. - -``Display`` is now a singleton and should be utilized like the following: - -.. code-block:: python - - from ansible.utils.display import Display - display = Display() - -There is no longer a need to attempt ``from __main__ import display`` inside -a ``try/except`` block. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst deleted file mode 100644 index 50dc7bafc92..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst +++ /dev/null @@ -1,4 +0,0 @@ -no-smart-quotes -=============== - -Smart quotes (``”“‘’``) should not be used. Use plain ascii quotes (``"'``) instead. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-tests-as-filters.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-tests-as-filters.rst deleted file mode 100644 index 0c1f99ac786..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-tests-as-filters.rst +++ /dev/null @@ -1,12 +0,0 @@ -:orphan: - -no-tests-as-filters -=================== - -Using Ansible provided Jinja2 tests as filters will be removed in Ansible 2.9. - -Prior to Ansible 2.5, Jinja2 tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while Jinja2 tests are referenced as ``variable is test_name``. - -Jinja2 tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in Jinja2. This change is to help differentiate the concepts for a better understanding of Jinja2, and where each can be appropriately used. - -As of Ansible 2.5 using an Ansible provided Jinja2 test with filter syntax will display a deprecation error. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-underscore-variable.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-underscore-variable.rst deleted file mode 100644 index 5174a43adf7..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-underscore-variable.rst +++ /dev/null @@ -1,30 +0,0 @@ -:orphan: - -no-underscore-variable -====================== - -In the future, Ansible may use the identifier ``_`` to internationalize its -message strings. To be ready for that, we need to make sure that there are -no conflicting identifiers defined in the code base. - -In common practice, ``_`` is frequently used as a dummy variable (a variable -to receive a value from a function where the value is useless and never used). -In Ansible, we're using the identifier ``dummy`` for this purpose instead. - -Example of unfixed code: - -.. code-block:: python - - for _ in range(0, retries): - success = retry_thing() - if success: - break - -Example of fixed code: - -.. code-block:: python - - for dummy in range(0, retries): - success = retry_thing() - if success: - break diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst deleted file mode 100644 index f8ca1d2c542..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst +++ /dev/null @@ -1,16 +0,0 @@ -no-unicode_literals -=================== - -The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern. The -problems with it are: - -* It makes it so one can't jump into the middle of a file and know whether a bare literal string is - a byte string or text string. The programmer has to first check the top of the file to see if the - import is there. -* It removes the ability to define native strings (a string which should be a byte string on python2 - and a text string on python3) by a string literal. -* It makes for more context switching. A programmer could be reading one file which has - `unicode_literals` and know that bare string literals are text strings but then switch to another - file (perhaps tracing program execution into a third party library) and have to switch their - understanding of what bare string literals are. - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-unwanted-files.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-unwanted-files.rst deleted file mode 100644 index 3d76324eeaa..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-unwanted-files.rst +++ /dev/null @@ -1,13 +0,0 @@ -no-unwanted-files -================= - -Specific file types are allowed in certain directories: - -- ``lib`` - All content must reside in the ``lib/ansible`` directory. - -- ``lib/ansible`` - Only source code with one of the following extensions is allowed: - - - ``*.cs`` - C# - - ``*.ps1`` - PowerShell - - ``*.psm1`` - PowerShell - - ``*.py`` - Python diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-wildcard-import.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-wildcard-import.rst deleted file mode 100644 index fdaf07b097a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/no-wildcard-import.rst +++ /dev/null @@ -1,31 +0,0 @@ -:orphan: - -no-wildcard-import -================== - -Using :code:`import *` is a bad habit which pollutes your namespace, hinders -debugging, and interferes with static analysis of code. For those reasons, we -do want to limit the use of :code:`import *` in the ansible code. Change our -code to import the specific names that you need instead. - -Examples of unfixed code: - -.. code-block:: python - - from ansible.module_utils.six import * - if isinstance(variable, string_types): - do_something(variable) - - from ansible.module_utils.basic import * - module = AnsibleModule() - -Examples of fixed code: - -.. code-block:: python - - from ansible.module_utils import six - if isinstance(variable, six.string_types): - do_something(variable) - - from ansible.module_utils.basic import AnsibleModule - module = AnsibleModule() diff --git a/docs/docsite/rst/dev_guide/testing/sanity/obsolete-files.rst b/docs/docsite/rst/dev_guide/testing/sanity/obsolete-files.rst deleted file mode 100644 index cb237468943..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/obsolete-files.rst +++ /dev/null @@ -1,14 +0,0 @@ -obsolete-files -============== - -Directories in the Ansible source tree are sometimes made obsolete. -Files should not exist in these directories. -The new location (if any) is dependent on which directory has been made obsolete. - -Below are some of the obsolete directories and their new locations: - -- All of ``test/runner/`` is now under ``test/lib/ansible_test/`` instead. The organization of files in the new directory has changed. -- Most subdirectories of ``test/sanity/`` (with some exceptions) are now under ``test/lib/ansible_test/_util/controller/sanity/`` instead. - -This error occurs most frequently for open pull requests which add or modify files in directories which are now obsolete. -Make sure the branch you are working from is current so that changes can be made in the correct location. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/package-data.rst b/docs/docsite/rst/dev_guide/testing/sanity/package-data.rst deleted file mode 100644 index 220872dd28a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/package-data.rst +++ /dev/null @@ -1,5 +0,0 @@ -package-data -============ - -Verifies that the combination of ``MANIFEST.in`` and ``package_data`` from ``setup.py`` -properly installs data files from within ``lib/ansible`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pep8.rst b/docs/docsite/rst/dev_guide/testing/sanity/pep8.rst deleted file mode 100644 index 9424bda8ab4..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pep8.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _testing_pep8: - -pep8 -==== - -Python static analysis for PEP 8 style guideline compliance. - -`PEP 8`_ style guidelines are enforced by `pycodestyle`_ on all python files in the repository by default. - -Running locally ------------------ - -The `PEP 8`_ check can be run locally as follows: - -.. code-block:: shell - - ansible-test sanity --test pep8 [file-or-directory-path-to-check] ... - - - -.. _PEP 8: https://www.python.org/dev/peps/pep-0008/ -.. _pycodestyle: https://pypi.org/project/pycodestyle/ - - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pslint.rst b/docs/docsite/rst/dev_guide/testing/sanity/pslint.rst deleted file mode 100644 index baa4fa034fc..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pslint.rst +++ /dev/null @@ -1,4 +0,0 @@ -pslint -====== - -PowerShell static analysis for common programming errors using `PSScriptAnalyzer `_. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pylint-ansible-test.rst b/docs/docsite/rst/dev_guide/testing/sanity/pylint-ansible-test.rst deleted file mode 100644 index a80ddc1eb05..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pylint-ansible-test.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -pylint-ansible-test -=================== - -Python static analysis for common programming errors. - -A more strict set of rules applied to ``ansible-test``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/pylint.rst b/docs/docsite/rst/dev_guide/testing/sanity/pylint.rst deleted file mode 100644 index 2b2ef9e53bd..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/pylint.rst +++ /dev/null @@ -1,4 +0,0 @@ -pylint -====== - -Python static analysis for common programming errors. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/release-names.rst b/docs/docsite/rst/dev_guide/testing/sanity/release-names.rst deleted file mode 100644 index 359f7ecb54d..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/release-names.rst +++ /dev/null @@ -1,4 +0,0 @@ -Release names -============= - -Verifies that the most recent release name has been added to ``./github/RELEASE_NAMES.yml`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/replace-urlopen.rst b/docs/docsite/rst/dev_guide/testing/sanity/replace-urlopen.rst deleted file mode 100644 index 705195c942f..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/replace-urlopen.rst +++ /dev/null @@ -1,4 +0,0 @@ -replace-urlopen -=============== - -Use ``open_url`` from ``module_utils`` instead of ``urlopen``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/required-and-default-attributes.rst b/docs/docsite/rst/dev_guide/testing/sanity/required-and-default-attributes.rst deleted file mode 100644 index 573c361500a..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/required-and-default-attributes.rst +++ /dev/null @@ -1,5 +0,0 @@ -required-and-default-attributes -=============================== - -Use only one of ``default`` or ``required`` with ``FieldAttribute``. - diff --git a/docs/docsite/rst/dev_guide/testing/sanity/rstcheck.rst b/docs/docsite/rst/dev_guide/testing/sanity/rstcheck.rst deleted file mode 100644 index 8fcbbce3431..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/rstcheck.rst +++ /dev/null @@ -1,4 +0,0 @@ -rstcheck -======== - -Check reStructuredText files for syntax and formatting issues. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/runtime-metadata.rst b/docs/docsite/rst/dev_guide/testing/sanity/runtime-metadata.rst deleted file mode 100644 index 1f3c32ad778..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/runtime-metadata.rst +++ /dev/null @@ -1,7 +0,0 @@ -runtime-metadata.yml -==================== - -Validates the schema for: - -* ansible-core's ``lib/ansible/config/ansible_builtin_runtime.yml`` -* collection's ``meta/runtime.yml`` diff --git a/docs/docsite/rst/dev_guide/testing/sanity/sanity-docs.rst b/docs/docsite/rst/dev_guide/testing/sanity/sanity-docs.rst deleted file mode 100644 index 34265c34be5..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/sanity-docs.rst +++ /dev/null @@ -1,4 +0,0 @@ -sanity-docs -=========== - -Documentation for each ``ansible-test sanity`` test is required. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/shebang.rst b/docs/docsite/rst/dev_guide/testing/sanity/shebang.rst deleted file mode 100644 index cff2aa0914b..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/shebang.rst +++ /dev/null @@ -1,16 +0,0 @@ -shebang -======= - -Most executable files should only use one of the following shebangs: - -- ``#!/bin/sh`` -- ``#!/bin/bash`` -- ``#!/usr/bin/make`` -- ``#!/usr/bin/env python`` -- ``#!/usr/bin/env bash`` - -NOTE: For ``#!/bin/bash``, any of the options ``eux`` may also be used, such as ``#!/bin/bash -eux``. - -This does not apply to Ansible modules, which should not be executable and must always use ``#!/usr/bin/python``. - -Some exceptions are permitted. Ask if you have questions. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/shellcheck.rst b/docs/docsite/rst/dev_guide/testing/sanity/shellcheck.rst deleted file mode 100644 index 446ee1ee782..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/shellcheck.rst +++ /dev/null @@ -1,4 +0,0 @@ -shellcheck -========== - -Static code analysis for shell scripts using the excellent `shellcheck `_ tool. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/symlinks.rst b/docs/docsite/rst/dev_guide/testing/sanity/symlinks.rst deleted file mode 100644 index 017209bdd3b..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/symlinks.rst +++ /dev/null @@ -1,6 +0,0 @@ -symlinks -======== - -Symbolic links are only permitted for files that exist to ensure proper tarball generation during a release. - -If other types of symlinks are needed for tests they must be created as part of the test. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/test-constraints.rst b/docs/docsite/rst/dev_guide/testing/sanity/test-constraints.rst deleted file mode 100644 index 36ceb361309..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/test-constraints.rst +++ /dev/null @@ -1,4 +0,0 @@ -test-constraints -================ - -Constraints for test requirements should be in ``test/lib/ansible_test/_data/requirements/constraints.txt``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/update-bundled.rst b/docs/docsite/rst/dev_guide/testing/sanity/update-bundled.rst deleted file mode 100644 index d8f19385b35..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/update-bundled.rst +++ /dev/null @@ -1,31 +0,0 @@ -:orphan: - -update-bundled -============== - -Check whether any of our known bundled code needs to be updated for a new upstream release. - -This test can error in the following ways: - -* The bundled code is out of date with regard to the latest release on pypi. Update the code - to the new version and update the version in _BUNDLED_METADATA to solve this. - -* The code is lacking a _BUNDLED_METADATA variable. This typically happens when a bundled version - is updated and we forget to add a _BUNDLED_METADATA variable to the updated file. Once that is - added, this error should go away. - -* A file has a _BUNDLED_METADATA variable but the file isn't specified in - :file:`test/sanity/code-smell/update-bundled.py`. This typically happens when a new bundled - library is added. Add the file to the `get_bundled_libs()` function in the `update-bundled.py` - test script to solve this error. - -_BUNDLED_METADATA has the following fields: - -:pypi_name: Name of the bundled package on pypi - -:version: Version of the package that we are including here - -:version_constraints: Optional PEP440 specifier for the version range that we are bundling. - Currently, the only valid use of this is to follow a version that is - compatible with the Python stdlib when newer versions of the pypi package - implement a new API. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/use-argspec-type-path.rst b/docs/docsite/rst/dev_guide/testing/sanity/use-argspec-type-path.rst deleted file mode 100644 index e06d83dd1a5..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/use-argspec-type-path.rst +++ /dev/null @@ -1,10 +0,0 @@ -use-argspec-type-path -===================== - -The AnsibleModule argument_spec knows of several types beyond the standard python types. One of -these is ``path``. When used, type ``path`` ensures that an argument is a string and expands any -shell variables and tilde characters. - -This test looks for use of :func:`os.path.expanduser ` in modules. When found, it tells the user to -replace it with ``type='path'`` in the module's argument_spec or list it as a false positive in the -test. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/use-compat-six.rst b/docs/docsite/rst/dev_guide/testing/sanity/use-compat-six.rst deleted file mode 100644 index 1f4150056da..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/use-compat-six.rst +++ /dev/null @@ -1,4 +0,0 @@ -use-compat-six -============== - -Use ``six`` from ``module_utils`` instead of ``six``. diff --git a/docs/docsite/rst/dev_guide/testing/sanity/validate-modules.rst b/docs/docsite/rst/dev_guide/testing/sanity/validate-modules.rst deleted file mode 100644 index dcb78c05270..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/validate-modules.rst +++ /dev/null @@ -1,140 +0,0 @@ -.. _testing_validate-modules: - -validate-modules -================ - -Analyze modules for common issues in code and documentation. - -.. contents:: - :local: - -Usage ------- - -.. code:: shell - - cd /path/to/ansible/source - source hacking/env-setup - ansible-test sanity --test validate-modules - -Help ------ - -Type ``ansible-test sanity validate-modules -h`` to display help for using this sanity test. - - - -Extending validate-modules ---------------------------- - -The ``validate-modules`` tool has a `schema.py `_ that is used to validate the YAML blocks, such as ``DOCUMENTATION`` and ``RETURNS``. - - -Codes ------- - -============================================================ ================== ==================== ========================================================================================= - **Error Code** **Type** **Level** **Sample Message** ------------------------------------------------------------- ------------------ -------------------- ----------------------------------------------------------------------------------------- - ansible-deprecated-module Documentation Error A module is deprecated and supposed to be removed in the current or an earlier Ansible version - collection-deprecated-module Documentation Error A module is deprecated and supposed to be removed in the current or an earlier collection version - ansible-deprecated-version Documentation Error A feature is deprecated and supposed to be removed in the current or an earlier Ansible version - ansible-module-not-initialized Syntax Error Execution of the module did not result in initialization of AnsibleModule - collection-deprecated-version Documentation Error A feature is deprecated and supposed to be removed in the current or an earlier collection version - deprecated-date Documentation Error A date before today appears as ``removed_at_date`` or in ``deprecated_aliases`` - deprecation-mismatch Documentation Error Module marked as deprecated or removed in at least one of the filename, its metadata, or in DOCUMENTATION (setting DOCUMENTATION.deprecated for deprecation or removing all Documentation for removed) but not in all three places. - doc-choices-do-not-match-spec Documentation Error Value for "choices" from the argument_spec does not match the documentation - doc-choices-incompatible-type Documentation Error Choices value from the documentation is not compatible with type defined in the argument_spec - doc-default-does-not-match-spec Documentation Error Value for "default" from the argument_spec does not match the documentation - doc-default-incompatible-type Documentation Error Default value from the documentation is not compatible with type defined in the argument_spec - doc-elements-invalid Documentation Error Documentation specifies elements for argument, when "type" is not ``list``. - doc-elements-mismatch Documentation Error Argument_spec defines elements different than documentation does - doc-missing-type Documentation Error Documentation doesn't specify a type but argument in ``argument_spec`` use default type (``str``) - doc-required-mismatch Documentation Error argument in argument_spec is required but documentation says it is not, or vice versa - doc-type-does-not-match-spec Documentation Error Argument_spec defines type different than documentation does - documentation-error Documentation Error Unknown ``DOCUMENTATION`` error - documentation-syntax-error Documentation Error Invalid ``DOCUMENTATION`` schema - illegal-future-imports Imports Error Only the following ``from __future__`` imports are allowed: ``absolute_import``, ``division``, and ``print_function``. - import-before-documentation Imports Error Import found before documentation variables. All imports must appear below ``DOCUMENTATION``/``EXAMPLES``/``RETURN`` - import-error Documentation Error ``Exception`` attempting to import module for ``argument_spec`` introspection - import-placement Locations Warning Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN`` - imports-improper-location Imports Error Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN`` - incompatible-choices Documentation Error Choices value from the argument_spec is not compatible with type defined in the argument_spec - incompatible-default-type Documentation Error Default value from the argument_spec is not compatible with type defined in the argument_spec - invalid-argument-name Documentation Error Argument in argument_spec must not be one of 'message', 'syslog_facility' as it is used internally by Ansible Core Engine - invalid-argument-spec Documentation Error Argument in argument_spec must be a dictionary/hash when used - invalid-argument-spec-options Documentation Error Suboptions in argument_spec are invalid - invalid-documentation Documentation Error ``DOCUMENTATION`` is not valid YAML - invalid-documentation-markup Documentation Error ``DOCUMENTATION`` or ``RETURN`` contains invalid markup - invalid-documentation-options Documentation Error ``DOCUMENTATION.options`` must be a dictionary/hash when used - invalid-examples Documentation Error ``EXAMPLES`` is not valid YAML - invalid-extension Naming Error Official Ansible modules must have a ``.py`` extension for python modules or a ``.ps1`` for powershell modules - invalid-module-schema Documentation Error ``AnsibleModule`` schema validation error - invalid-removal-version Documentation Error The version at which a feature is supposed to be removed cannot be parsed (for collections, it must be a `semantic version `_) - invalid-requires-extension Naming Error Module ``#AnsibleRequires -CSharpUtil`` should not end in .cs, Module ``#Requires`` should not end in .psm1 - missing-doc-fragment Documentation Error ``DOCUMENTATION`` fragment missing - missing-existing-doc-fragment Documentation Warning Pre-existing ``DOCUMENTATION`` fragment missing - missing-documentation Documentation Error No ``DOCUMENTATION`` provided - missing-examples Documentation Error No ``EXAMPLES`` provided - missing-gplv3-license Documentation Error GPLv3 license header not found - missing-module-utils-basic-import Imports Warning Did not find ``ansible.module_utils.basic`` import - missing-module-utils-import-csharp-requirements Imports Error No ``Ansible.ModuleUtils`` or C# Ansible util requirements/imports found - missing-powershell-interpreter Syntax Error Interpreter line is not ``#!powershell`` - missing-python-interpreter Syntax Error Interpreter line is not ``#!/usr/bin/python`` - missing-return Documentation Error No ``RETURN`` documentation provided - missing-return-legacy Documentation Warning No ``RETURN`` documentation provided for legacy module - missing-suboption-docs Documentation Error Argument in argument_spec has sub-options but documentation does not define sub-options - module-incorrect-version-added Documentation Error Module level ``version_added`` is incorrect - module-invalid-version-added Documentation Error Module level ``version_added`` is not a valid version number - module-utils-specific-import Imports Error ``module_utils`` imports should import specific components, not ``*`` - multiple-utils-per-requires Imports Error ``Ansible.ModuleUtils`` requirements do not support multiple modules per statement - multiple-csharp-utils-per-requires Imports Error Ansible C# util requirements do not support multiple utils per statement - no-default-for-required-parameter Documentation Error Option is marked as required but specifies a default. Arguments with a default should not be marked as required - no-log-needed Parameters Error Option name suggests that the option contains a secret value, while ``no_log`` is not specified for this option in the argument spec. If this is a false positive, explicitly set ``no_log=False`` - nonexistent-parameter-documented Documentation Error Argument is listed in DOCUMENTATION.options, but not accepted by the module - option-incorrect-version-added Documentation Error ``version_added`` for new option is incorrect - option-invalid-version-added Documentation Error ``version_added`` for option is not a valid version number - parameter-invalid Documentation Error Argument in argument_spec is not a valid python identifier - parameter-invalid-elements Documentation Error Value for "elements" is valid only when value of "type" is ``list`` - implied-parameter-type-mismatch Documentation Error Argument_spec implies ``type="str"`` but documentation defines it as different data type - parameter-type-not-in-doc Documentation Error Type value is defined in ``argument_spec`` but documentation doesn't specify a type - parameter-alias-repeated Parameters Error argument in argument_spec has at least one alias specified multiple times in aliases - parameter-alias-self Parameters Error argument in argument_spec is specified as its own alias - parameter-documented-multiple-times Documentation Error argument in argument_spec with aliases is documented multiple times - parameter-list-no-elements Parameters Error argument in argument_spec "type" is specified as ``list`` without defining "elements" - parameter-state-invalid-choice Parameters Error Argument ``state`` includes ``get``, ``list`` or ``info`` as a choice. Functionality should be in an ``_info`` or (if further conditions apply) ``_facts`` module. - python-syntax-error Syntax Error Python ``SyntaxError`` while parsing module - removal-version-must-be-major Documentation Error According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be removed are major versions (x.0.0) - return-syntax-error Documentation Error ``RETURN`` is not valid YAML, ``RETURN`` fragments missing or invalid - return-invalid-version-added Documentation Error ``version_added`` for return value is not a valid version number - subdirectory-missing-init Naming Error Ansible module subdirectories must contain an ``__init__.py`` - try-except-missing-has Imports Warning Try/Except ``HAS_`` expression missing - undocumented-parameter Documentation Error Argument is listed in the argument_spec, but not documented in the module - unidiomatic-typecheck Syntax Error Type comparison using ``type()`` found. Use ``isinstance()`` instead - unknown-doc-fragment Documentation Warning Unknown pre-existing ``DOCUMENTATION`` error - use-boto3 Imports Error ``boto`` import found, new modules should use ``boto3`` - use-fail-json-not-sys-exit Imports Error ``sys.exit()`` call found. Should be ``exit_json``/``fail_json`` - use-module-utils-urls Imports Error ``requests`` import found, should use ``ansible.module_utils.urls`` instead - use-run-command-not-os-call Imports Error ``os.call`` used instead of ``module.run_command`` - use-run-command-not-popen Imports Error ``subprocess.Popen`` used instead of ``module.run_command`` - use-short-gplv3-license Documentation Error GPLv3 license header should be the :ref:`short form ` for new modules - mutually_exclusive-type Documentation Error mutually_exclusive entry contains non-string value - mutually_exclusive-collision Documentation Error mutually_exclusive entry has repeated terms - mutually_exclusive-unknown Documentation Error mutually_exclusive entry contains option which does not appear in argument_spec (potentially an alias of an option?) - required_one_of-type Documentation Error required_one_of entry contains non-string value - required_one_of-collision Documentation Error required_one_of entry has repeated terms - required_one_of-unknown Documentation Error required_one_of entry contains option which does not appear in argument_spec (potentially an alias of an option?) - required_together-type Documentation Error required_together entry contains non-string value - required_together-collision Documentation Error required_together entry has repeated terms - required_together-unknown Documentation Error required_together entry contains option which does not appear in argument_spec (potentially an alias of an option?) - required_if-is_one_of-type Documentation Error required_if entry has a fourth value which is not a bool - required_if-requirements-type Documentation Error required_if entry has a third value (requirements) which is not a list or tuple - required_if-requirements-collision Documentation Error required_if entry has repeated terms in requirements - required_if-requirements-unknown Documentation Error required_if entry's requirements contains option which does not appear in argument_spec (potentially an alias of an option?) - required_if-unknown-key Documentation Error required_if entry's key does not appear in argument_spec (potentially an alias of an option?) - required_if-key-in-requirements Documentation Error required_if entry contains its key in requirements list/tuple - required_if-value-type Documentation Error required_if entry's value is not of the type specified for its key - required_by-collision Documentation Error required_by entry has repeated terms - required_by-unknown Documentation Error required_by entry contains option which does not appear in argument_spec (potentially an alias of an option?) - version-added-must-be-major-or-minor Documentation Error According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be added are major and minor versions (x.y.0) -============================================================ ================== ==================== ========================================================================================= diff --git a/docs/docsite/rst/dev_guide/testing/sanity/yamllint.rst b/docs/docsite/rst/dev_guide/testing/sanity/yamllint.rst deleted file mode 100644 index 5822bb7c1e0..00000000000 --- a/docs/docsite/rst/dev_guide/testing/sanity/yamllint.rst +++ /dev/null @@ -1,4 +0,0 @@ -yamllint -======== - -Check YAML files for syntax and formatting issues. diff --git a/docs/docsite/rst/dev_guide/testing_compile.rst b/docs/docsite/rst/dev_guide/testing_compile.rst deleted file mode 100644 index 2f258c8b076..00000000000 --- a/docs/docsite/rst/dev_guide/testing_compile.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - - -************* -Compile Tests -************* - -This page has moved to :ref:`testing_compile`. diff --git a/docs/docsite/rst/dev_guide/testing_documentation.rst b/docs/docsite/rst/dev_guide/testing_documentation.rst deleted file mode 100644 index 280e2c03270..00000000000 --- a/docs/docsite/rst/dev_guide/testing_documentation.rst +++ /dev/null @@ -1,44 +0,0 @@ -:orphan: - -.. _testing_module_documentation: -.. _testing_plugin_documentation: - -**************************** -Testing plugin documentation -**************************** - -A quick test while developing is to use ``ansible-doc -t `` to see if it renders, you might need to add ``-M /path/to/module`` if the module is not somewhere Ansible expects to find it. - -Before you submit a plugin for inclusion in Ansible, you must test your documentation for correct HTML rendering and for modules to ensure that the argspec matches the documentation in your Python file. -The community pages offer more information on :ref:`testing reStructuredText documentation `. - -For example, to check the HTML output of your module documentation: - -#. Ensure working :ref:`development environment `. -#. Install required Python packages (drop '--user' in venv/virtualenv): - - .. code-block:: bash - - pip install --user -r requirements.txt - pip install --user -r docs/docsite/requirements.txt - -#. Ensure your module is in the correct directory: ``lib/ansible/modules/mymodule.py`` or in a configured path. -#. Build HTML from your module documentation: ``MODULES=mymodule make webdocs``. -#. To build the HTML documentation for multiple modules, use a comma-separated list of module names: ``MODULES=mymodule,mymodule2 make webdocs``. -#. View the HTML page at ``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html``. - -To ensure that your module documentation matches your ``argument_spec``: - -#. Install required Python packages (drop '--user' in venv/virtualenv): - - .. code-block:: bash - - pip install --user -r test/lib/ansible_test/_data/requirements/sanity.txt - -#. run the ``validate-modules`` test: - - .. code-block:: bash - - ansible-test sanity --test validate-modules mymodule - -For other plugin types the steps are similar, just adjusting names and paths to the specific type. diff --git a/docs/docsite/rst/dev_guide/testing_httptester.rst b/docs/docsite/rst/dev_guide/testing_httptester.rst deleted file mode 100644 index 7c1a9fbbaf7..00000000000 --- a/docs/docsite/rst/dev_guide/testing_httptester.rst +++ /dev/null @@ -1,28 +0,0 @@ -:orphan: - -********** -httptester -********** - -.. contents:: Topics - -Overview -======== - -``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as git or package repos) which, if temporarily unavailable, would cause tests to fail. - -HTTP Testing endpoint which provides the following capabilities: - -* httpbin -* nginx -* SSL -* SNI -* Negotiate Authentication - - -Source files can be found in the `http-test-container `_ repository. - -Extending httptester -==================== - -If you have sometime to improve ``httptester`` please add a comment on the `Testing Working Group Agenda `_ to avoid duplicated effort. diff --git a/docs/docsite/rst/dev_guide/testing_integration.rst b/docs/docsite/rst/dev_guide/testing_integration.rst deleted file mode 100644 index 915281d02cb..00000000000 --- a/docs/docsite/rst/dev_guide/testing_integration.rst +++ /dev/null @@ -1,241 +0,0 @@ -:orphan: - -.. _testing_integration: - -***************** -Integration tests -***************** - -.. contents:: Topics - -The Ansible integration Test system. - -Tests for playbooks, by playbooks. - -Some tests may require credentials. Credentials may be specified with `credentials.yml`. - -Some tests may require root. - -.. note:: - Every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. - In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_. - -Quick Start -=========== - -It is highly recommended that you install and activate the ``argcomplete`` python package. -It provides tab completion in ``bash`` for the ``ansible-test`` test runner. - -Configuration -============= - -ansible-test command --------------------- - -The example below assumes ``bin/`` is in your ``$PATH``. An easy way to achieve that -is to initialize your environment with the ``env-setup`` command: - -.. code-block:: shell-session - - source hacking/env-setup - ansible-test --help - -You can also call ``ansible-test`` with the full path: - -.. code-block:: shell-session - - bin/ansible-test --help - -integration_config.yml ----------------------- - -Making your own version of ``integration_config.yml`` can allow for setting some -tunable parameters to help run the tests better in your environment. Some -tests (for example, cloud tests) will only run when access credentials are provided. For more -information about supported credentials, refer to the various ``cloud-config-*.template`` -files in the ``test/integration/`` directory. - -Prerequisites -============= - -Some tests assume things like hg, svn, and git are installed, and in path. Some tests -(such as those for Amazon Web Services) need separate definitions, which will be covered -later in this document. - -(Complete list pending) - -Non-destructive Tests -===================== - -These tests will modify files in subdirectories, but will not do things that install or remove packages or things -outside of those test subdirectories. They will also not reconfigure or bounce system services. - -.. note:: Running integration tests within containers - - To protect your system from any potential changes caused by integration tests, and to ensure a sensible set of dependencies are available we recommend that you always run integration tests with the ``--docker`` option, for example ``--docker ubuntu2004``. See the `list of supported container images `_ for options (the ``default`` image is used for sanity and unit tests, as well as for platform independent integration tests such as those for cloud modules). - -Run as follows for all POSIX platform tests executed by our CI system in a Fedora 34 container: - -.. code-block:: shell-session - - ansible-test integration shippable/ --docker fedora34 - -You can target a specific tests as well, such as for individual modules: - -.. code-block:: shell-session - - ansible-test integration ping - -You can use the ``-v`` option to make the output more verbose: - -.. code-block:: shell-session - - ansible-test integration lineinfile -vvv - -Use the following command to list all the available targets: - -.. code-block:: shell-session - - ansible-test integration --list-targets - -.. note:: Bash users - - If you use ``bash`` with ``argcomplete``, obtain a full list by doing: ``ansible-test integration `` - -Destructive Tests -================= - -These tests are allowed to install and remove some trivial packages. You will likely want to devote these -to a virtual environment, such as Docker. They won't reformat your filesystem: - -.. code-block:: shell-session - - ansible-test integration destructive/ --docker fedora34 - -Windows Tests -============= - -These tests exercise the ``winrm`` connection plugin and Windows modules. You'll -need to define an inventory with a remote Windows Server to use for testing, -and enable PowerShell Remoting to continue. - -Running these tests may result in changes to your Windows host, so don't run -them against a production/critical Windows environment. - -Enable PowerShell Remoting (run on the Windows host by a Remote Desktop): - -.. code-block:: shell-session - - Enable-PSRemoting -Force - -Define Windows inventory: - -.. code-block:: shell-session - - cp inventory.winrm.template inventory.winrm - ${EDITOR:-vi} inventory.winrm - -Run the Windows tests executed by our CI system: - -.. code-block:: shell-session - - ansible-test windows-integration -v shippable/ - -Tests in containers -========================== - -If you have a Linux system with Docker or Podman installed, running integration tests using the same containers used by -the Ansible continuous integration (CI) system is recommended. - -.. note:: Podman - - By default, Podman will only be used if the Docker CLI is not installed. If you have Docker installed but want to use - Podman, you can change this behavior by setting the environment variable ``ANSIBLE_TEST_PREFER_PODMAN``. - -.. note:: Docker on non-Linux - - Using Docker Engine to run Docker on a non-Linux host (such as macOS) is not recommended. - Some tests may fail, depending on the image used for testing. - Using the ``--docker-privileged`` option when running ``integration`` (not ``network-integration`` or ``windows-integration``) may resolve the issue. - -Running Integration Tests -------------------------- - -To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container: - -.. code-block:: shell-session - - ansible-test integration shippable/ --docker ubuntu1804 - -You can also run specific tests or select a different Linux distribution. -For example, to run tests for the ``ping`` module on a Ubuntu 18.04 container: - -.. code-block:: shell-session - - ansible-test integration ping --docker ubuntu1804 - -.. _test_container_images: - -Container Images ----------------- - -Container images are updated regularly. To see the current list of container images: - -.. code-block:: bash - - ansible-test integration --help - -The list is under the **target docker images and supported python version** heading. - -Other configuration for Cloud Tests -=================================== - -In order to run some tests, you must provide access credentials in a file named -``cloud-config-aws.yml`` or ``cloud-config-cs.ini`` in the test/integration -directory. Corresponding .template files are available for for syntax help. The newer AWS -tests now use the file test/integration/cloud-config-aws.yml - -IAM policies for AWS -==================== - -Ansible needs fairly wide ranging powers to run the tests in an AWS account. This rights can be provided to a dedicated user. These need to be configured before running the test. - -testing-policies ----------------- - -The GitHub repository `mattclay/aws-terminator `_ -contains two sets of policies used for all existing AWS module integratoin tests. -The `hacking/aws_config/setup_iam.yml` playbook can be used to setup two groups: - - - `ansible-integration-ci` will have the policies applied necessary to run any - integration tests not marked as `unsupported` and are designed to mirror those - used by Ansible's CI. - - `ansible-integration-unsupported` will have the additional policies applied - necessary to run the integration tests marked as `unsupported` including tests - for managing IAM roles, users and groups. - -Once the groups have been created, you'll need to create a user and make the user a member of these -groups. The policies are designed to minimize the rights of that user. Please note that while this policy does limit -the user to one region, this does not fully restrict the user (primarily due to the limitations of the Amazon ARN -notation). The user will still have wide privileges for viewing account definitions, and will also able to manage -some resources that are not related to testing (for example, AWS lambdas with different names). Tests should not -be run in a primary production account in any case. - -Other Definitions required --------------------------- - -Apart from installing the policy and giving it to the user identity running the tests, a -lambda role `ansible_integration_tests` has to be created which has lambda basic execution -privileges. - - -Network Tests -============= - -For guidance on writing network test see :ref:`testing_resource_modules`. - - -Where to find out more -====================== - -If you'd like to know more about the plans for improving testing Ansible, join the `Testing Working Group `_. diff --git a/docs/docsite/rst/dev_guide/testing_pep8.rst b/docs/docsite/rst/dev_guide/testing_pep8.rst deleted file mode 100644 index c634914dff2..00000000000 --- a/docs/docsite/rst/dev_guide/testing_pep8.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - - -***** -PEP 8 -***** - -This page has moved to :ref:`testing_pep8`. \ No newline at end of file diff --git a/docs/docsite/rst/dev_guide/testing_running_locally.rst b/docs/docsite/rst/dev_guide/testing_running_locally.rst deleted file mode 100644 index 0d03189bf41..00000000000 --- a/docs/docsite/rst/dev_guide/testing_running_locally.rst +++ /dev/null @@ -1,382 +0,0 @@ -:orphan: - -.. _testing_running_locally: - -******************************* -Testing Ansible and Collections -******************************* - -This document describes how to run tests using ``ansible-test``. - -.. contents:: - :local: - -Setup -===== - -Before running ``ansible-test``, set up your environment for :ref:`testing_an_ansible_collection` or -:ref:`testing_ansible_core`, depending on which scenario applies to you. - -.. warning:: - - If you use ``git`` for version control, make sure the files you are working with are not ignored by ``git``. - If they are, ``ansible-test`` will ignore them as well. - -.. _testing_an_ansible_collection: - -Testing an Ansible Collection ------------------------------ - -If you are testing an Ansible Collection, you need a copy of the collection, preferably a git clone. -For example, to work with the ``community.windows`` collection, follow these steps: - -1. Clone the collection you want to test into a valid collection root: - - .. code-block:: shell - - git clone https://github.com/ansible-collections/community.windows ~/dev/ansible_collections/community/windows - - .. important:: - - The path must end with ``/ansible_collections/{collection_namespace}/{collection_name}`` where - ``{collection_namespace}`` is the namespace of the collection and ``{collection_name}`` is the collection name. - -2. Clone any collections on which the collection depends: - - .. code-block:: shell - - git clone https://github.com/ansible-collections/ansible.windows ~/dev/ansible_collections/ansible/windows - - .. important:: - - If your collection has any dependencies on other collections, they must be in the same collection root, since - ``ansible-test`` will not use your configured collection roots (or other Ansible configuration). - - .. note:: - - See the collection's ``galaxy.yml`` for a list of possible dependencies. - -3. Switch to the directory where the collection to test resides: - - .. code-block:: shell - - cd ~/dev/ansible_collections/community/windows - -.. _testing_ansible_core: - -Testing ``ansible-core`` ------------------------- - -If you are testing ``ansible-core`` itself, you need a copy of the ``ansible-core`` source code, preferably a git clone. -Having an installed copy of ``ansible-core`` is not sufficient or required. -For example, to work with the ``ansible-core`` source cloned from GitHub, follow these steps: - -1. Clone the ``ansible-core`` repository: - - .. code-block:: shell - - git clone https://github.com/ansible/ansible ~/dev/ansible - -2. Switch to the directory where the ``ansible-core`` source resides: - - .. code-block:: shell - - cd ~/dev/ansible - -3. Add ``ansible-core`` programs to your ``PATH``: - - .. code-block:: shell - - source hacking/env-setup - - .. note:: - - You can skip this step if you only need to run ``ansible-test``, and not other ``ansible-core`` programs. - In that case, simply run ``bin/ansible-test`` from the root of the ``ansible-core`` source. - - .. caution:: - - If you have an installed version of ``ansible-core`` and are trying to run ``ansible-test`` from your ``PATH``, - make sure the program found by your shell is the one from the ``ansible-core`` source: - - .. code-block:: shell - - which ansible-test - -Commands -======== - -The most commonly used test commands are: - -* ``ansible-test sanity`` - Run sanity tests (mostly linters and static analysis). -* ``ansible-test integration`` - Run integration tests. -* ``ansible-test units`` - Run unit tests. - -Run ``ansible-test --help`` to see a complete list of available commands. - -.. note:: - - For detailed help on a specific command, add the ``--help`` option after the command. - -Environments -============ - -Most ``ansible-test`` commands support running in one or more isolated test environments to simplify testing. - -Containers ----------- - -Containers are recommended for running sanity, unit and integration tests, since they provide consistent environments. -Unit tests will be run with network isolation, which avoids unintentional dependencies on network resources. - -The ``--docker`` option runs tests in a container using either Docker or Podman. - -.. note:: - - If both Docker and Podman are installed, Docker will be used. - To override this, set the environment variable ``ANSIBLE_TEST_PREFER_PODMAN`` to any non-empty value. - -Choosing a container -^^^^^^^^^^^^^^^^^^^^ - -Without an additional argument, the ``--docker`` option uses the ``default`` container. -To use another container, specify it immediately after the ``--docker`` option. - -.. note:: - - The ``default`` container is recommended for all sanity and unit tests. - -To see the list of supported containers, use the ``--help`` option with the ``ansible-test`` command you want to use. - -.. note:: - - The list of available containers is dependent on the ``ansible-test`` command you are using. - -You can also specify your own container. -When doing so, you will need to indicate the Python version in the container with the ``--python`` option. - -Custom containers -""""""""""""""""" - -When building custom containers, keep in mind the following requirements: - -* The ``USER`` should be ``root``. -* Use an ``init`` process, such as ``systemd``. -* Include ``sshd`` and accept connections on the default port of ``22``. -* Include a POSIX compatible ``sh`` shell which can be found on ``PATH``. -* Include a ``sleep`` utility which runs as a subprocess. -* Include a supported version of Python. -* Avoid using the ``VOLUME`` statement. - -Docker and SELinux -^^^^^^^^^^^^^^^^^^ - -Using Docker on a host with SELinux may require setting the system in permissive mode. -Consider using Podman instead. - -Docker Desktop with WSL2 -^^^^^^^^^^^^^^^^^^^^^^^^ - -These instructions explain how to use ``ansible-test`` with WSL2 and Docker Desktop *without* ``systemd`` support. - -.. note:: - - If your WSL2 environment includes ``systemd`` support, these steps are not required. - -.. _configuration_requirements: - -Configuration requirements -"""""""""""""""""""""""""" - -1. Open Docker Desktop and go to the **Settings** screen. -2. On the the **General** tab: - - a. Uncheck the **Start Docker Desktop when you log in** checkbox. - b. Check the **Use the WSL 2 based engine** checkbox. - -3. On the **Resources** tab under the **WSL Integration** section: - - a. Enable distros you want to use under the **Enable integration with additional distros** section. - -4. Click **Apply and restart** if changes were made. - -.. _setup_instructions: - -Setup instructions -"""""""""""""""""" - -.. note:: - - If all WSL instances have been stopped, these changes will need to be re-applied. - -1. Verify Docker Desktop is properly configured (see :ref:`configuration_requirements`). -2. Quit Docker Desktop if it is running: - - a. Right click the **Docker Desktop** taskbar icon. - b. Click the **Quit Docker Desktop** option. - -3. Stop any running WSL instances with the command: - - .. code-block:: shell - - wsl --shutdown - -4. Verify all WSL instances have stopped with the command: - - .. code-block:: shell - - wsl -l -v - -5. Start a WSL instance and perform the following steps as ``root``: - - a. Verify the ``systemd`` subsystem is not registered: - - a. Check for the ``systemd`` cgroup hierarchy with the following command: - - .. code-block:: shell - - grep systemd /proc/self/cgroup - - b. If any matches are found, re-check the :ref:`configuration_requirements` and follow the - :ref:`setup_instructions` again. - - b. Mount the ``systemd`` cgroup hierarchy with the following commands: - - .. code-block:: shell - - mkdir /sys/fs/cgroup/systemd - mount cgroup -t cgroup /sys/fs/cgroup/systemd -o none,name=systemd,xattr - -6. Start Docker Desktop. - -You should now be able to use ``ansible-test`` with the ``--docker`` option. - -.. _linux_cgroup_configuration: - -Linux cgroup configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. note:: - - These changes will need to be re-applied each time the container host is booted. - -For certain container hosts and container combinations, additional setup on the container host may be required. -In these situations ``ansible-test`` will report an error and provide additional instructions to run as ``root``: - -.. code-block:: shell - - mkdir /sys/fs/cgroup/systemd - mount cgroup -t cgroup /sys/fs/cgroup/systemd -o none,name=systemd,xattr - -If you are using rootless Podman, an additional command must be run, also as ``root``. -Make sure to substitute your user and group for ``{user}`` and ``{group}`` respectively: - -.. code-block:: shell - - chown -R {user}:{group} /sys/fs/cgroup/systemd - -Podman -"""""" - -When using Podman, you may need to stop existing Podman processes after following the :ref:`linux_cgroup_configuration` -instructions. Otherwise Podman may be unable to see the new mount point. - -You can check to see if Podman is running by looking for ``podman`` and ``catatonit`` processes. - -Remote virtual machines ------------------------ - -Remote virtual machines are recommended for running integration tests not suitable for execution in containers. - -The ``--remote`` option runs tests in a cloud hosted ephemeral virtual machine. - -.. note:: - - An API key is required to use this feature, unless running under an approved Azure Pipelines organization. - -To see the list of supported systems, use the ``--help`` option with the ``ansible-test`` command you want to use. - -.. note:: - - The list of available systems is dependent on the ``ansible-test`` command you are using. - -Python virtual environments ---------------------------- - -Python virtual environments provide a simple way to achieve isolation from the system and user Python environments. -They are recommended for unit and integration tests when the ``--docker`` and ``--remote`` options cannot be used. - -The ``--venv`` option runs tests in a virtual environment managed by ``ansible-test``. -Requirements are automatically installed before tests are run. - -Composite environment arguments -------------------------------- - -The environment arguments covered in this document are sufficient for most use cases. -However, some scenarios may require the additional flexibility offered by composite environment arguments. - -The ``--controller`` and ``--target`` options are alternatives to the ``--docker``, ``--remote`` and ``--venv`` options. - -.. note:: - - When using the ``shell`` command, the ``--target`` option is replaced by three platform specific options. - -Add the ``--help`` option to your ``ansible-test`` command to learn more about the composite environment arguments. - -Additional Requirements -======================= - -Some ``ansible-test`` commands have additional requirements. -You can use the ``--requirements`` option to automatically install them. - -.. note:: - - When using a test environment managed by ``ansible-test`` the ``--requirements`` option is usually unnecessary. - -Environment variables -===================== - -When using environment variables to manipulate tests there some limitations to keep in mind. Environment variables are: - -* Not propagated from the host to the test environment when using the ``--docker`` or ``--remote`` options. -* Not exposed to the test environment unless enabled in ``test/lib/ansible_test/_internal/util.py`` in the ``common_environment`` function. - - Example: ``ANSIBLE_KEEP_REMOTE_FILES=1`` can be set when running ``ansible-test integration --venv``. However, using the ``--docker`` option would - require running ``ansible-test shell`` to gain access to the Docker environment. Once at the shell prompt, the environment variable could be set - and the tests executed. This is useful for debugging tests inside a container by following the - :ref:`debugging_modules` instructions. - -Interactive shell -================= - -Use the ``ansible-test shell`` command to get an interactive shell in the same environment used to run tests. Examples: - -* ``ansible-test shell --docker`` - Open a shell in the default docker container. -* ``ansible-test shell --venv --python 3.10`` - Open a shell in a Python 3.10 virtual environment. - -Code coverage -============= - -Code coverage reports make it easy to identify untested code for which more tests should -be written. Online reports are available but only cover the ``devel`` branch (see -:ref:`developing_testing`). For new code local reports are needed. - -Add the ``--coverage`` option to any test command to collect code coverage data. If you -aren't using the ``--venv`` or ``--docker`` options which create an isolated python -environment then you may have to use the ``--requirements`` option to ensure that the -correct version of the coverage module is installed: - -.. code-block:: shell - - ansible-test coverage erase - ansible-test units --coverage apt - ansible-test integration --coverage aws_lambda - ansible-test coverage html - -Reports can be generated in several different formats: - -* ``ansible-test coverage report`` - Console report. -* ``ansible-test coverage html`` - HTML report. -* ``ansible-test coverage xml`` - XML report. - -To clear data between test runs, use the ``ansible-test coverage erase`` command. diff --git a/docs/docsite/rst/dev_guide/testing_sanity.rst b/docs/docsite/rst/dev_guide/testing_sanity.rst deleted file mode 100644 index 93769c1d2a6..00000000000 --- a/docs/docsite/rst/dev_guide/testing_sanity.rst +++ /dev/null @@ -1,52 +0,0 @@ -:orphan: - -.. _testing_sanity: - -************ -Sanity Tests -************ - -.. contents:: Topics - -Sanity tests are made up of scripts and tools used to perform static code analysis. -The primary purpose of these tests is to enforce Ansible coding standards and requirements. - -Tests are run with ``ansible-test sanity``. -All available tests are run unless the ``--test`` option is used. - - -How to run -========== - -.. note:: - To run sanity tests using docker, always use the default docker image - by passing the ``--docker`` or ``--docker default`` argument. - -.. code:: shell - - source hacking/env-setup - - # Run all sanity tests - ansible-test sanity - - # Run all sanity tests including disabled ones - ansible-test sanity --allow-disabled - - # Run all sanity tests against certain file(s) - ansible-test sanity lib/ansible/modules/files/template.py - - # Run all sanity tests against certain folder(s) - ansible-test sanity lib/ansible/modules/files/ - - # Run all tests inside docker (good if you don't have dependencies installed) - ansible-test sanity --docker default - - # Run validate-modules against a specific file - ansible-test sanity --test validate-modules lib/ansible/modules/files/template.py - -Available Tests -=============== - -Tests can be listed with ``ansible-test sanity --list-tests``. - -See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues. diff --git a/docs/docsite/rst/dev_guide/testing_units.rst b/docs/docsite/rst/dev_guide/testing_units.rst deleted file mode 100644 index 3b876455a77..00000000000 --- a/docs/docsite/rst/dev_guide/testing_units.rst +++ /dev/null @@ -1,219 +0,0 @@ -:orphan: - -.. _testing_units: - -********** -Unit Tests -********** - -Unit tests are small isolated tests that target a specific library or module. Unit tests -in Ansible are currently the only way of driving tests from python within Ansible's -continuous integration process. This means that in some circumstances the tests may be a -bit wider than just units. - -.. contents:: Topics - -Available Tests -=============== - -Unit tests can be found in `test/units -`_. Notice that the directory -structure of the tests matches that of ``lib/ansible/``. - -Running Tests -============= - -.. note:: - To run unit tests using docker, always use the default docker image - by passing the ``--docker`` or ``--docker default`` argument. - -The Ansible unit tests can be run across the whole code base by doing: - -.. code:: shell - - cd /path/to/ansible/source - source hacking/env-setup - ansible-test units --docker -v - -Against a single file by doing: - -.. code:: shell - - ansible-test units --docker -v apt - -Or against a specific Python version by doing: - -.. code:: shell - - ansible-test units --docker -v --python 2.7 apt - -If you are running unit tests against things other than modules, such as module utilities, specify the whole file path: - -.. code:: shell - - ansible-test units --docker -v test/units/module_utils/basic/test_imports.py - -For advanced usage see the online help: - -.. code:: shell - - ansible-test units --help - -You can also run tests in Ansible's continuous integration system by opening a pull -request. This will automatically determine which tests to run based on the changes made -in your pull request. - - -Installing dependencies -======================= - -If you are running ``ansible-test`` with the ``--docker`` or ``--venv`` option you do not need to install dependencies manually. - -Otherwise you can install dependencies using the ``--requirements`` option, which will -install all the required dependencies needed for unit tests. For example: - -.. code:: shell - - ansible-test units --python 2.7 --requirements apache2_module - - -The list of unit test requirements can be found at `test/units/requirements.txt -`_. - -This does not include the list of unit test requirements for ``ansible-test`` itself, -which can be found at `test/lib/ansible_test/_data/requirements/units.txt -`_. - -See also the `constraints -`_ -applicable to all test commands. - - -Extending unit tests -==================== - - -.. warning:: What a unit test isn't - - If you start writing a test that requires external services then - you may be writing an integration test, rather than a unit test. - - -Structuring Unit Tests ----------------------- - -Ansible drives unit tests through `pytest `_. This -means that tests can either be written a simple functions which are included in any file -name like ``test_.py`` or as classes. - -Here is an example of a function: - -.. code:: python - - #this function will be called simply because it is called test_*() - - def test_add(): - a = 10 - b = 23 - c = 33 - assert a + b == c - -Here is an example of a class: - -.. code:: python - - import unittest - - class AddTester(unittest.TestCase): - - def SetUp(): - self.a = 10 - self.b = 23 - - # this function will - def test_add(): - c = 33 - assert self.a + self.b == c - - # this function will - def test_subtract(): - c = -13 - assert self.a - self.b == c - -Both methods work fine in most circumstances; the function-based interface is simpler and -quicker and so that's probably where you should start when you are just trying to add a -few basic tests for a module. The class-based test allows more tidy set up and tear down -of pre-requisites, so if you have many test cases for your module you may want to refactor -to use that. - -Assertions using the simple ``assert`` function inside the tests will give full -information on the cause of the failure with a trace-back of functions called during the -assertion. This means that plain asserts are recommended over other external assertion -libraries. - -A number of the unit test suites include functions that are shared between several -modules, especially in the networking arena. In these cases a file is created in the same -directory, which is then included directly. - - -Module test case common code ----------------------------- - -Keep common code as specific as possible within the `test/units/` directory structure. -Don't import common unit test code from directories outside the current or parent directories. - -Don't import other unit tests from a unit test. Any common code should be in dedicated -files that aren't themselves tests. - - -Fixtures files --------------- - -To mock out fetching results from devices, or provide other complex data structures that -come from external libraries, you can use ``fixtures`` to read in pre-generated data. - -You can check how `fixtures `_ -are used in `cpuinfo fact tests `_ - -If you are simulating APIs you may find that Python placebo is useful. See -:ref:`testing_units_modules` for more information. - - -Code Coverage For New or Updated Unit Tests -------------------------------------------- -New code will be missing from the codecov.io coverage reports (see :ref:`developing_testing`), so -local reporting is needed. Most ``ansible-test`` commands allow you to collect code -coverage; this is particularly useful when to indicate where to extend testing. - -To collect coverage data add the ``--coverage`` argument to your ``ansible-test`` command line: - -.. code:: shell - - ansible-test units --coverage apt - ansible-test coverage html - -Results will be written to ``test/results/reports/coverage/index.html`` - -Reports can be generated in several different formats: - -* ``ansible-test coverage report`` - Console report. -* ``ansible-test coverage html`` - HTML report. -* ``ansible-test coverage xml`` - XML report. - -To clear data between test runs, use the ``ansible-test coverage erase`` command. See -:ref:`testing_running_locally` for more information about generating coverage -reports. - - -.. seealso:: - - :ref:`testing_units_modules` - Special considerations for unit testing modules - :ref:`testing_running_locally` - Running tests locally including gathering and reporting coverage data - `Python 3 documentation - 26.4. unittest — Unit testing framework `_ - The documentation of the unittest framework in python 3 - `Python 2 documentation - 25.3. unittest — Unit testing framework `_ - The documentation of the earliest supported unittest framework - from Python 2.6 - `pytest: helps you write better programs `_ - The documentation of pytest - the framework actually used to run Ansible unit tests diff --git a/docs/docsite/rst/dev_guide/testing_units_modules.rst b/docs/docsite/rst/dev_guide/testing_units_modules.rst deleted file mode 100644 index d07dcff9448..00000000000 --- a/docs/docsite/rst/dev_guide/testing_units_modules.rst +++ /dev/null @@ -1,589 +0,0 @@ -:orphan: - -.. _testing_units_modules: - -**************************** -Unit Testing Ansible Modules -**************************** - -.. highlight:: python - -.. contents:: Topics - -Introduction -============ - -This document explains why, how and when you should use unit tests for Ansible modules. -The document doesn't apply to other parts of Ansible for which the recommendations are -normally closer to the Python standard. There is basic documentation for Ansible unit -tests in the developer guide :ref:`testing_units`. This document should -be readable for a new Ansible module author. If you find it incomplete or confusing, -please open a bug or ask for help on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - -What Are Unit Tests? -==================== - -Ansible includes a set of unit tests in the :file:`test/units` directory. These tests primarily cover the -internals but can also cover Ansible modules. The structure of the unit tests matches -the structure of the code base, so the tests that reside in the :file:`test/units/modules/` directory -are organized by module groups. - -Integration tests can be used for most modules, but there are situations where -cases cannot be verified using integration tests. This means that Ansible unit test cases -may extend beyond testing only minimal units and in some cases will include some -level of functional testing. - - -Why Use Unit Tests? -=================== - -Ansible unit tests have advantages and disadvantages. It is important to understand these. -Advantages include: - -* Most unit tests are much faster than most Ansible integration tests. The complete suite - of unit tests can be run regularly by a developer on their local system. -* Unit tests can be run by developers who don't have access to the system which the module is - designed to work on, allowing a level of verification that changes to core functions - haven't broken module expectations. -* Unit tests can easily substitute system functions allowing testing of software that - would be impractical. For example, the ``sleep()`` function can be replaced and we check - that a ten minute sleep was called without actually waiting ten minutes. -* Unit tests are run on different Python versions. This allows us to - ensure that the code behaves in the same way on different Python versions. - -There are also some potential disadvantages of unit tests. Unit tests don't normally -directly test actual useful valuable features of software, instead just internal -implementation - -* Unit tests that test the internal, non-visible features of software may make - refactoring difficult if those internal features have to change (see also naming in How - below) -* Even if the internal feature is working correctly it is possible that there will be a - problem between the internal code tested and the actual result delivered to the user - -Normally the Ansible integration tests (which are written in Ansible YAML) provide better -testing for most module functionality. If those tests already test a feature and perform -well there may be little point in providing a unit test covering the same area as well. - -When To Use Unit Tests -====================== - -There are a number of situations where unit tests are a better choice than integration -tests. For example, testing things which are impossible, slow or very difficult to test -with integration tests, such as: - -* Forcing rare / strange / random situations that can't be forced, such as specific network - failures and exceptions -* Extensive testing of slow configuration APIs -* Situations where the integration tests cannot be run as part of the main Ansible - continuous integration running in Azure Pipelines. - - - -Providing quick feedback ------------------------- - -Example: - A single step of the rds_instance test cases can take up to 20 - minutes (the time to create an RDS instance in Amazon). The entire - test run can last for well over an hour. All 16 of the unit tests - complete execution in less than 2 seconds. - -The time saving provided by being able to run the code in a unit test makes it worth -creating a unit test when bug fixing a module, even if those tests do not often identify -problems later. As a basic goal, every module should have at least one unit test which -will give quick feedback in easy cases without having to wait for the integration tests to -complete. - -Ensuring correct use of external interfaces -------------------------------------------- - -Unit tests can check the way in which external services are run to ensure that they match -specifications or are as efficient as possible *even when the final output will not be changed*. - -Example: - Package managers are often far more efficient when installing multiple packages at once - rather than each package separately. The final result is the - same: the packages are all installed, so the efficiency is difficult to verify through - integration tests. By providing a mock package manager and verifying that it is called - once, we can build a valuable test for module efficiency. - -Another related use is in the situation where an API has versions which behave -differently. A programmer working on a new version may change the module to work with the -new API version and unintentionally break the old version. A test case -which checks that the call happens properly for the old version can help avoid the -problem. In this situation it is very important to include version numbering in the test case -name (see `Naming unit tests`_ below). - -Providing specific design tests --------------------------------- - -By building a requirement for a particular part of the -code and then coding to that requirement, unit tests _can_ sometimes improve the code and -help future developers understand that code. - -Unit tests that test internal implementation details of code, on the other hand, almost -always do more harm than good. Testing that your packages to install are stored in a list -would slow down and confuse a future developer who might need to change that list into a -dictionary for efficiency. This problem can be reduced somewhat with clear test naming so -that the future developer immediately knows to delete the test case, but it is often -better to simply leave out the test case altogether and test for a real valuable feature -of the code, such as installing all of the packages supplied as arguments to the module. - - -How to unit test Ansible modules -================================ - -There are a number of techniques for unit testing modules. Beware that most -modules without unit tests are structured in a way that makes testing quite difficult and -can lead to very complicated tests which need more work than the code. Effectively using unit -tests may lead you to restructure your code. This is often a good thing and leads -to better code overall. Good restructuring can make your code clearer and easier to understand. - - -Naming unit tests ------------------ - -Unit tests should have logical names. If a developer working on the module being tested -breaks the test case, it should be easy to figure what the unit test covers from the name. -If a unit test is designed to verify compatibility with a specific software or API version -then include the version in the name of the unit test. - -As an example, ``test_v2_state_present_should_call_create_server_with_name()`` would be a -good name, ``test_create_server()`` would not be. - - -Use of Mocks ------------- - -Mock objects (from https://docs.python.org/3/library/unittest.mock.html) can be very -useful in building unit tests for special / difficult cases, but they can also -lead to complex and confusing coding situations. One good use for mocks would be in -simulating an API. As for 'six', the 'mock' python package is bundled with Ansible (use -``import units.compat.mock``). - -Ensuring failure cases are visible with mock objects ----------------------------------------------------- - -Functions like :meth:`module.fail_json` are normally expected to terminate execution. When you -run with a mock module object this doesn't happen since the mock always returns another mock -from a function call. You can set up the mock to raise an exception as shown above, or you can -assert that these functions have not been called in each test. For example: - -.. code-block:: python - - module = MagicMock() - function_to_test(module, argument) - module.fail_json.assert_not_called() - -This applies not only to calling the main module but almost any other -function in a module which gets the module object. - - -Mocking of the actual module ----------------------------- - -The setup of an actual module is quite complex (see `Passing Arguments`_ below) and often -isn't needed for most functions which use a module. Instead you can use a mock object as -the module and create any module attributes needed by the function you are testing. If -you do this, beware that the module exit functions need special handling as mentioned -above, either by throwing an exception or ensuring that they haven't been called. For example: - -.. code-block:: python - - class AnsibleExitJson(Exception): - """Exception class to be raised by module.exit_json and caught by the test case""" - pass - - # you may also do the same to fail json - module = MagicMock() - module.exit_json.side_effect = AnsibleExitJson(Exception) - with self.assertRaises(AnsibleExitJson) as result: - results = my_module.test_this_function(module, argument) - module.fail_json.assert_not_called() - assert results["changed"] == True - -API definition with unit test cases ------------------------------------ - -API interaction is usually best tested with the function tests defined in Ansible's -integration testing section, which run against the actual API. There are several cases -where the unit tests are likely to work better. - -Defining a module against an API specification -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This case is especially important for modules interacting with web services, which provide -an API that Ansible uses but which are beyond the control of the user. - -By writing a custom emulation of the calls that return data from the API, we can ensure -that only the features which are clearly defined in the specification of the API are -present in the message. This means that we can check that we use the correct -parameters and nothing else. - - -*Example: in rds_instance unit tests a simple instance state is defined*: - -.. code-block:: python - - def simple_instance_list(status, pending): - return {u'DBInstances': [{u'DBInstanceArn': 'arn:aws:rds:us-east-1:1234567890:db:fakedb', - u'DBInstanceStatus': status, - u'PendingModifiedValues': pending, - u'DBInstanceIdentifier': 'fakedb'}]} - -This is then used to create a list of states: - -.. code-block:: python - - rds_client_double = MagicMock() - rds_client_double.describe_db_instances.side_effect = [ - simple_instance_list('rebooting', {"a": "b", "c": "d"}), - simple_instance_list('available', {"c": "d", "e": "f"}), - simple_instance_list('rebooting', {"a": "b"}), - simple_instance_list('rebooting', {"e": "f", "g": "h"}), - simple_instance_list('rebooting', {}), - simple_instance_list('available', {"g": "h", "i": "j"}), - simple_instance_list('rebooting', {"i": "j", "k": "l"}), - simple_instance_list('available', {}), - simple_instance_list('available', {}), - ] - -These states are then used as returns from a mock object to ensure that the ``await`` function -waits through all of the states that would mean the RDS instance has not yet completed -configuration: - -.. code-block:: python - - rds_i.await_resource(rds_client_double, "some-instance", "available", mod_mock, - await_pending=1) - assert(len(sleeper_double.mock_calls) > 5), "await_pending didn't wait enough" - -By doing this we check that the ``await`` function will keep waiting through -potentially unusual that it would be impossible to reliably trigger through the -integration tests but which happen unpredictably in reality. - -Defining a module to work against multiple API versions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This case is especially important for modules interacting with many different versions of -software; for example, package installation modules that might be expected to work with -many different operating system versions. - -By using previously stored data from various versions of an API we can ensure that the -code is tested against the actual data which will be sent from that version of the system -even when the version is very obscure and unlikely to be available during testing. - -Ansible special cases for unit testing -====================================== - -There are a number of special cases for unit testing the environment of an Ansible module. -The most common are documented below, and suggestions for others can be found by looking -at the source code of the existing unit tests or asking on the Ansible chat channel or mailing -lists. For more information on joining chat channels and subscribing to mailing lists, see :ref:`communication`. - -Module argument processing --------------------------- - -There are two problems with running the main function of a module: - -* Since the module is supposed to accept arguments on ``STDIN`` it is a bit difficult to - set up the arguments correctly so that the module will get them as parameters. -* All modules should finish by calling either the :meth:`module.fail_json` or - :meth:`module.exit_json`, but these won't work correctly in a testing environment. - -Passing Arguments ------------------ - -.. This section should be updated once https://github.com/ansible/ansible/pull/31456 is - closed since the function below will be provided in a library file. - -To pass arguments to a module correctly, use the ``set_module_args`` method which accepts a dictionary -as its parameter. Module creation and argument processing is -handled through the :class:`AnsibleModule` object in the basic section of the utilities. Normally -this accepts input on ``STDIN``, which is not convenient for unit testing. When the special -variable is set it will be treated as if the input came on ``STDIN`` to the module. Simply call that function before setting up your module: - -.. code-block:: python - - import json - from units.modules.utils import set_module_args - from ansible.module_utils.common.text.converters import to_bytes - - def test_already_registered(self): - set_module_args({ - 'activationkey': 'key', - 'username': 'user', - 'password': 'pass', - }) - -Handling exit correctly ------------------------ - -.. This section should be updated once https://github.com/ansible/ansible/pull/31456 is - closed since the exit and failure functions below will be provided in a library file. - -The :meth:`module.exit_json` function won't work properly in a testing environment since it -writes error information to ``STDOUT`` upon exit, where it -is difficult to examine. This can be mitigated by replacing it (and :meth:`module.fail_json`) with -a function that raises an exception: - -.. code-block:: python - - def exit_json(*args, **kwargs): - if 'changed' not in kwargs: - kwargs['changed'] = False - raise AnsibleExitJson(kwargs) - -Now you can ensure that the first function called is the one you expected simply by -testing for the correct exception: - -.. code-block:: python - - def test_returned_value(self): - set_module_args({ - 'activationkey': 'key', - 'username': 'user', - 'password': 'pass', - }) - - with self.assertRaises(AnsibleExitJson) as result: - my_module.main() - -The same technique can be used to replace :meth:`module.fail_json` (which is used for failure -returns from modules) and for the ``aws_module.fail_json_aws()`` (used in modules for Amazon -Web Services). - -Running the main function -------------------------- - -If you do want to run the actual main function of a module you must import the module, set -the arguments as above, set up the appropriate exit exception and then run the module: - -.. code-block:: python - - # This test is based around pytest's features for individual test functions - import pytest - import ansible.modules.module.group.my_module as my_module - - def test_main_function(monkeypatch): - monkeypatch.setattr(my_module.AnsibleModule, "exit_json", fake_exit_json) - set_module_args({ - 'activationkey': 'key', - 'username': 'user', - 'password': 'pass', - }) - my_module.main() - - -Handling calls to external executables --------------------------------------- - -Module must use :meth:`AnsibleModule.run_command` in order to execute an external command. This -method needs to be mocked: - -Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`): - -.. code-block:: python - - with patch.object(basic.AnsibleModule, 'run_command') as run_command: - run_command.return_value = 0, '', '' # successful execution, no output - with self.assertRaises(AnsibleExitJson) as result: - my_module.main() - self.assertFalse(result.exception.args[0]['changed']) - # Check that run_command has been called - run_command.assert_called_once_with('/usr/bin/command args') - self.assertEqual(run_command.call_count, 1) - self.assertFalse(run_command.called) - - -A Complete Example ------------------- - -The following example is a complete skeleton that reuses the mocks explained above and adds a new -mock for :meth:`Ansible.get_bin_path`: - -.. code-block:: python - - import json - - from units.compat import unittest - from units.compat.mock import patch - from ansible.module_utils import basic - from ansible.module_utils.common.text.converters import to_bytes - from ansible.modules.namespace import my_module - - - def set_module_args(args): - """prepare arguments so that they will be picked up during module creation""" - args = json.dumps({'ANSIBLE_MODULE_ARGS': args}) - basic._ANSIBLE_ARGS = to_bytes(args) - - - class AnsibleExitJson(Exception): - """Exception class to be raised by module.exit_json and caught by the test case""" - pass - - - class AnsibleFailJson(Exception): - """Exception class to be raised by module.fail_json and caught by the test case""" - pass - - - def exit_json(*args, **kwargs): - """function to patch over exit_json; package return data into an exception""" - if 'changed' not in kwargs: - kwargs['changed'] = False - raise AnsibleExitJson(kwargs) - - - def fail_json(*args, **kwargs): - """function to patch over fail_json; package return data into an exception""" - kwargs['failed'] = True - raise AnsibleFailJson(kwargs) - - - def get_bin_path(self, arg, required=False): - """Mock AnsibleModule.get_bin_path""" - if arg.endswith('my_command'): - return '/usr/bin/my_command' - else: - if required: - fail_json(msg='%r not found !' % arg) - - - class TestMyModule(unittest.TestCase): - - def setUp(self): - self.mock_module_helper = patch.multiple(basic.AnsibleModule, - exit_json=exit_json, - fail_json=fail_json, - get_bin_path=get_bin_path) - self.mock_module_helper.start() - self.addCleanup(self.mock_module_helper.stop) - - def test_module_fail_when_required_args_missing(self): - with self.assertRaises(AnsibleFailJson): - set_module_args({}) - my_module.main() - - - def test_ensure_command_called(self): - set_module_args({ - 'param1': 10, - 'param2': 'test', - }) - - with patch.object(basic.AnsibleModule, 'run_command') as mock_run_command: - stdout = 'configuration updated' - stderr = '' - rc = 0 - mock_run_command.return_value = rc, stdout, stderr # successful execution - - with self.assertRaises(AnsibleExitJson) as result: - my_module.main() - self.assertFalse(result.exception.args[0]['changed']) # ensure result is changed - - mock_run_command.assert_called_once_with('/usr/bin/my_command --value 10 --name test') - - -Restructuring modules to enable testing module set up and other processes -------------------------------------------------------------------------- - -Often modules have a ``main()`` function which sets up the module and then performs other -actions. This can make it difficult to check argument processing. This can be made easier by -moving module configuration and initialization into a separate function. For example: - -.. code-block:: python - - argument_spec = dict( - # module function variables - state=dict(choices=['absent', 'present', 'rebooted', 'restarted'], default='present'), - apply_immediately=dict(type='bool', default=False), - wait=dict(type='bool', default=False), - wait_timeout=dict(type='int', default=600), - allocated_storage=dict(type='int', aliases=['size']), - db_instance_identifier=dict(aliases=["id"], required=True), - ) - - def setup_module_object(): - module = AnsibleAWSModule( - argument_spec=argument_spec, - required_if=required_if, - mutually_exclusive=[['old_instance_id', 'source_db_instance_identifier', - 'db_snapshot_identifier']], - ) - return module - - def main(): - module = setup_module_object() - validate_parameters(module) - conn = setup_client(module) - return_dict = run_task(module, conn) - module.exit_json(**return_dict) - -This now makes it possible to run tests against the module initiation function: - -.. code-block:: python - - def test_rds_module_setup_fails_if_db_instance_identifier_parameter_missing(): - # db_instance_identifier parameter is missing - set_module_args({ - 'state': 'absent', - 'apply_immediately': 'True', - }) - - with self.assertRaises(AnsibleFailJson) as result: - my_module.setup_json - -See also ``test/units/module_utils/aws/test_rds.py`` - -Note that the ``argument_spec`` dictionary is visible in a module variable. This has -advantages, both in allowing explicit testing of the arguments and in allowing the easy -creation of module objects for testing. - -The same restructuring technique can be valuable for testing other functionality, such as the part of the module which queries the object that the module configures. - -Traps for maintaining Python 2 compatibility -============================================ - -If you use the ``mock`` library from the Python 2.6 standard library, a number of the -assert functions are missing but will return as if successful. This means that test cases should take great care *not* use -functions marked as _new_ in the Python 3 documentation, since the tests will likely always -succeed even if the code is broken when run on older versions of Python. - -A helpful development approach to this should be to ensure that all of the tests have been -run under Python 2.6 and that each assertion in the test cases has been checked to work by breaking -the code in Ansible to trigger that failure. - -.. warning:: Maintain Python 2.6 compatibility - - Please remember that modules need to maintain compatibility with Python 2.6 so the unittests for - modules should also be compatible with Python 2.6. - - -.. seealso:: - - :ref:`testing_units` - Ansible unit tests documentation - :ref:`testing_running_locally` - Running tests locally including gathering and reporting coverage data - :ref:`developing_modules_general` - Get started developing a module - `Python 3 documentation - 26.4. unittest — Unit testing framework `_ - The documentation of the unittest framework in python 3 - `Python 2 documentation - 25.3. unittest — Unit testing framework `_ - The documentation of the earliest supported unittest framework - from Python 2.6 - `pytest: helps you write better programs `_ - The documentation of pytest - the framework actually used to run Ansible unit tests - `Development Mailing List `_ - Mailing list for development topics - `Testing Your Code (from The Hitchhiker's Guide to Python!) `_ - General advice on testing Python code - `Uncle Bob's many videos on YouTube `_ - Unit testing is a part of the of various philosophies of software development, including - Extreme Programming (XP), Clean Coding. Uncle Bob talks through how to benefit from this - `"Why Most Unit Testing is Waste" `_ - An article warning against the costs of unit testing - `'A Response to "Why Most Unit Testing is Waste"' `_ - An response pointing to how to maintain the value of unit tests diff --git a/docs/docsite/rst/dev_guide/testing_validate-modules.rst b/docs/docsite/rst/dev_guide/testing_validate-modules.rst deleted file mode 100644 index 1c74fe39b1a..00000000000 --- a/docs/docsite/rst/dev_guide/testing_validate-modules.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**************** -validate-modules -**************** - -This page has moved to :ref:`testing_validate-modules`. diff --git a/docs/docsite/rst/galaxy/dev_guide.rst b/docs/docsite/rst/galaxy/dev_guide.rst deleted file mode 100644 index 01a92d02900..00000000000 --- a/docs/docsite/rst/galaxy/dev_guide.rst +++ /dev/null @@ -1,226 +0,0 @@ -.. _developing_galaxy: - -********************** -Galaxy Developer Guide -********************** - -You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formatted in pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections `. -You can create roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. Taking this a step further, you can create collections which provide a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins. - -.. contents:: - :local: - :depth: 2 - -.. _creating_collections_galaxy: - -Creating collections for Galaxy -=============================== - -Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. -You can publish and use collections through `Ansible Galaxy `_. - -See :ref:`developing_collections` for details on how to create collections. - -.. _creating_roles_galaxy: - - -Creating roles for Galaxy -========================= - -Use the ``init`` command to initialize the base structure of a new role, saving time on creating the various directories and main.yml files a role requires - -.. code-block:: bash - - $ ansible-galaxy init role_name - -The above will create the following directory structure in the current working directory: - -.. code-block:: text - - role_name/ - README.md - .travis.yml - defaults/ - main.yml - files/ - handlers/ - main.yml - meta/ - main.yml - templates/ - tests/ - inventory - test.yml - vars/ - main.yml - -If you want to create a repository for the role, the repository root should be `role_name`. - -Force ------ - -If a directory matching the name of the role already exists in the current working directory, the init command will result in an error. To ignore the error -use the ``--force`` option. Force will create the above subdirectories and files, replacing anything that matches. - -Container enabled ------------------ - -If you are creating a Container Enabled role, pass ``--type container`` to ``ansible-galaxy init``. This will create the same directory structure as above, but populate it -with default files appropriate for a Container Enabled role. For instance, the README.md has a slightly different structure, the *.travis.yml* file tests -the role using `Ansible Container `_, and the meta directory includes a *container.yml* file. - -Using a custom role skeleton ----------------------------- - -A custom role skeleton directory can be supplied as follows: - -.. code-block:: bash - - $ ansible-galaxy init --role-skeleton=/path/to/skeleton role_name - -When a skeleton is provided, init will: - -- copy all files and directories from the skeleton to the new role -- any .j2 files found outside of a templates folder will be rendered as templates. The only useful variable at the moment is role_name -- The .git folder and any .git_keep files will not be copied - -Alternatively, the role_skeleton and ignoring of files can be configured via ansible.cfg - -.. code-block:: text - - [galaxy] - role_skeleton = /path/to/skeleton - role_skeleton_ignore = ^.git$,^.*/.git_keep$ - -Authenticate with Galaxy ------------------------- - -Using the ``import``, ``delete`` and ``setup`` commands to manage your roles on the Galaxy website requires authentication in the form of an API key, you must create an account on the Galaxy website. - -#. Log in to the Galaxy website and open the `Preferences `_ view. -#. Select **Show API key** and then copy it. - -#. Save your token in the path set in the :ref:`GALAXY_TOKEN_PATH`. - - -Import a role -------------- - -The ``import`` command requires that you first authenticate using the ``login`` command. Once authenticated you can import any GitHub repository that you own or have been granted access. - -Use the following to import to role: - -.. code-block:: bash - - $ ansible-galaxy import github_user github_repo - -By default the command will wait for Galaxy to complete the import process, displaying the results as the import progresses: - -.. code-block:: text - - Successfully submitted import request 41 - Starting import 41: role_name=myrole repo=githubuser/ansible-role-repo ref= - Retrieving GitHub repo githubuser/ansible-role-repo - Accessing branch: devel - Parsing and validating meta/main.yml - Parsing galaxy_tags - Parsing platforms - Adding dependencies - Parsing and validating README.md - Adding repo tags as role versions - Import completed - Status SUCCESS : warnings=0 errors=0 - -Branch -^^^^^^ - -Use the ``--branch`` option to import a specific branch. If not specified, the default branch for the repo will be used. - -Role name -^^^^^^^^^ - -By default the name given to the role will be derived from the GitHub repository name. However, you can use the ``--role-name`` option to override this and set the name. - -No wait -^^^^^^^ - -If the ``--no-wait`` option is present, the command will not wait for results. Results of the most recent import for any of your roles is available on the Galaxy web site by visiting *My Imports*. - -Delete a role -------------- - -The ``delete`` command requires that you first authenticate using the ``login`` command. Once authenticated you can remove a role from the Galaxy web site. You are only allowed to remove roles where you have access to the repository in GitHub. - -Use the following to delete a role: - -.. code-block:: bash - - $ ansible-galaxy delete github_user github_repo - -This only removes the role from Galaxy. It does not remove or alter the actual GitHub repository. - - -Travis integrations -------------------- - -You can create an integration or connection between a role in Galaxy and `Travis `_. Once the connection is established, a build in Travis will -automatically trigger an import in Galaxy, updating the search index with the latest information about the role. - -You create the integration using the ``setup`` command, but before an integration can be created, you must first authenticate using the ``login`` command; you will -also need an account in Travis, and your Travis token. Once you're ready, use the following command to create the integration: - -.. code-block:: bash - - $ ansible-galaxy setup travis github_user github_repo xxx-travis-token-xxx - -The setup command requires your Travis token, however the token is not stored in Galaxy. It is used along with the GitHub username and repo to create a hash as described -in `the Travis documentation `_. The hash is stored in Galaxy and used to verify notifications received from Travis. - -The setup command enables Galaxy to respond to notifications. To configure Travis to run a build on your repository and send a notification, follow the -`Travis getting started guide `_. - -To instruct Travis to notify Galaxy when a build completes, add the following to your .travis.yml file: - -.. code-block:: text - - notifications: - webhooks: https://galaxy.ansible.com/api/v1/notifications/ - - -List Travis integrations -^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the ``--list`` option to display your Travis integrations: - -.. code-block:: bash - - $ ansible-galaxy setup --list - - - ID Source Repo - ---------- ---------- ---------- - 2 travis github_user/github_repo - 1 travis github_user/github_repo - - -Remove Travis integrations -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the ``--remove`` option to disable and remove a Travis integration: - - .. code-block:: bash - - $ ansible-galaxy setup --remove ID - -Provide the ID of the integration to be disabled. You can find the ID by using the ``--list`` option. - - -.. seealso:: - :ref:`collections` - Shareable collections of modules, playbooks and roles - :ref:`playbooks_reuse_roles` - All about ansible roles - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/galaxy/user_guide.rst b/docs/docsite/rst/galaxy/user_guide.rst deleted file mode 100644 index c5a1e19e8fb..00000000000 --- a/docs/docsite/rst/galaxy/user_guide.rst +++ /dev/null @@ -1,497 +0,0 @@ -.. _using_galaxy: -.. _ansible_galaxy: - -***************** -Galaxy User Guide -***************** - -:dfn:`Ansible Galaxy` refers to the `Galaxy `_ website, a free site for finding, downloading, and sharing community developed roles. - -Use Galaxy to jump-start your automation project with great content from the Ansible community. Galaxy provides pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections ` -You can find roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. The collection format provides a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins. - -.. contents:: - :local: - :depth: 2 -.. _finding_galaxy_collections: - -Finding collections on Galaxy -============================= - -To find collections on Galaxy: - -#. Click the :guilabel:`Search` icon in the left-hand navigation. -#. Set the filter to *collection*. -#. Set other filters and press :guilabel:`enter`. - -Galaxy presents a list of collections that match your search criteria. - -.. _installing_galaxy_collections: - - -Installing collections -====================== - - -Installing a collection from Galaxy ------------------------------------ - -.. include:: ../shared_snippets/installing_collections.txt - -.. _installing_ah_collection: - -Downloading a collection from Automation Hub ----------------------------------------------------- - -You can download collections from Automation Hub at the command line. Automation Hub content is available to subscribers only, so you must download an API token and configure your local environment to provide it before you can you download collections. To download a collection from Automation Hub with the ``ansible-galaxy`` command: - -1. Get your Automation Hub API token. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click :guilabel:`Load token` from the version dropdown to copy your API token. -2. Configure Red Hat Automation Hub server in the ``server_list`` option under the ``[galaxy]`` section in your :file:`ansible.cfg` file. - - .. code-block:: ini - - [galaxy] - server_list = automation_hub - - [galaxy_server.automation_hub] - url=https://console.redhat.com/api/automation-hub/ - auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token - token=my_ah_token - -3. Download the collection hosted in Automation Hub. - - .. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection - -.. seealso:: - `Getting started with Automation Hub `_ - An introduction to Automation Hub - -Installing an older version of a collection -------------------------------------------- - -.. include:: ../shared_snippets/installing_older_collection.txt - -Install multiple collections with a requirements file ------------------------------------------------------ - -.. include:: ../shared_snippets/installing_multiple_collections.txt - -Downloading a collection for offline use ------------------------------------------ - -.. include:: ../shared_snippets/download_tarball_collections.txt - -Installing a collection from source files ------------------------------------------ - -.. include:: ../shared_snippets/installing_collections_file.rst - -Installing a collection from a git repository ---------------------------------------------- - -.. include:: ../shared_snippets/installing_collections_git_repo.txt - -Listing installed collections ------------------------------ - -To list installed collections, run ``ansible-galaxy collection list``. See :ref:`collections_listing` for more details. - - -Configuring the ``ansible-galaxy`` client ------------------------------------------- - -.. include:: ../shared_snippets/galaxy_server_list.txt - -.. _finding_galaxy_roles: - -Finding roles on Galaxy -======================= - -Search the Galaxy database by tags, platforms, author and multiple keywords. For example: - -.. code-block:: bash - - $ ansible-galaxy search elasticsearch --author geerlingguy - -The search command will return a list of the first 1000 results matching your search: - -.. code-block:: text - - Found 2 roles matching your search: - - Name Description - ---- ----------- - geerlingguy.elasticsearch Elasticsearch for Linux. - geerlingguy.elasticsearch-curator Elasticsearch curator for Linux. - - -Get more information about a role ---------------------------------- - -Use the ``info`` command to view more detail about a specific role: - -.. code-block:: bash - - $ ansible-galaxy info username.role_name - -This returns everything found in Galaxy for the role: - -.. code-block:: text - - Role: username.role_name - description: Installs and configures a thing, a distributed, highly available NoSQL thing. - active: True - commit: c01947b7bc89ebc0b8a2e298b87ab416aed9dd57 - commit_message: Adding travis - commit_url: https://github.com/username/repo_name/commit/c01947b7bc89ebc0b8a2e298b87ab - company: My Company, Inc. - created: 2015-12-08T14:17:52.773Z - download_count: 1 - forks_count: 0 - github_branch: - github_repo: repo_name - github_user: username - id: 6381 - is_valid: True - issue_tracker_url: - license: Apache - min_ansible_version: 1.4 - modified: 2015-12-08T18:43:49.085Z - namespace: username - open_issues_count: 0 - path: /Users/username/projects/roles - scm: None - src: username.repo_name - stargazers_count: 0 - travis_status_url: https://travis-ci.org/username/repo_name.svg?branch=main - version: - watchers_count: 1 - - -.. _installing_galaxy_roles: - -Installing roles from Galaxy -============================ - -The ``ansible-galaxy`` command comes bundled with Ansible, and you can use it to install roles from Galaxy or directly from a git based SCM. You can -also use it to create a new role, remove roles, or perform tasks on the Galaxy website. - -The command line tool by default communicates with the Galaxy website API using the server address *https://galaxy.ansible.com*. If you run your own internal Galaxy server -and want to use it instead of the default one, pass the ``--server`` option following the address of this galaxy server. You can set permanently this option by setting -the Galaxy server value in your ``ansible.cfg`` file to use it . For information on setting the value in *ansible.cfg* see :ref:`galaxy_server`. - - -Installing roles ----------------- - -Use the ``ansible-galaxy`` command to download roles from the `Galaxy website `_ - -.. code-block:: bash - - $ ansible-galaxy install namespace.role_name - -Setting where to install roles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible downloads roles to the first writable directory in the default list of paths ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``. This installs roles in the home directory of the user running ``ansible-galaxy``. - -You can override this with one of the following options: - -* Set the environment variable :envvar:`ANSIBLE_ROLES_PATH` in your session. -* Use the ``--roles-path`` option for the ``ansible-galaxy`` command. -* Define ``roles_path`` in an ``ansible.cfg`` file. - -The following provides an example of using ``--roles-path`` to install the role into the current working directory: - -.. code-block:: bash - - $ ansible-galaxy install --roles-path . geerlingguy.apache - -.. seealso:: - - :ref:`intro_configuration` - All about configuration files - -Installing a specific version of a role ---------------------------------------- - -When the Galaxy server imports a role, it imports any git tags matching the `Semantic Version `_ format as versions. -In turn, you can download a specific version of a role by specifying one of the imported tags. - -To see the available versions for a role: - -#. Locate the role on the Galaxy search page. -#. Click on the name to view more details, including the available versions. - -You can also navigate directly to the role using the //. For example, to view the role geerlingguy.apache, go to ``_. - -To install a specific version of a role from Galaxy, append a comma and the value of a GitHub release tag. For example: - -.. code-block:: bash - - $ ansible-galaxy install geerlingguy.apache,1.0.0 - -It is also possible to point directly to the git repository and specify a branch name or commit hash as the version. For example, the following will -install a specific commit: - -.. code-block:: bash - - $ ansible-galaxy install git+https://github.com/geerlingguy/ansible-role-apache.git,0b7cd353c0250e87a26e0499e59e7fd265cc2f25 - -Installing multiple roles from a file -------------------------------------- - -You can install multiple roles by including the roles in a :file:`requirements.yml` file. The format of the file is YAML, and the -file extension must be either *.yml* or *.yaml*. - -Use the following command to install roles included in :file:`requirements.yml:` - -.. code-block:: bash - - $ ansible-galaxy install -r requirements.yml - -Again, the extension is important. If the *.yml* extension is left off, the ``ansible-galaxy`` CLI assumes the file is in an older, now deprecated, -"basic" format. - -Each role in the file will have one or more of the following attributes: - - src - The source of the role. Use the format *namespace.role_name*, if downloading from Galaxy; otherwise, provide a URL pointing - to a repository within a git based SCM. See the examples below. This is a required attribute. - scm - Specify the SCM. As of this writing only *git* or *hg* are allowed. See the examples below. Defaults to *git*. - version: - The version of the role to download. Provide a release tag value, commit hash, or branch name. Defaults to the branch set as a default in the repository, otherwise defaults to the *master*. - name: - Download the role to a specific name. Defaults to the Galaxy name when downloading from Galaxy, otherwise it defaults - to the name of the repository. - -Use the following example as a guide for specifying roles in *requirements.yml*: - -.. code-block:: yaml - - # from galaxy - - name: yatesr.timezone - - # from locally cloned git repository (git+file:// requires full paths) - - src: git+file:///home/bennojoy/nginx - - # from GitHub - - src: https://github.com/bennojoy/nginx - - # from GitHub, overriding the name and specifying a specific tag - - name: nginx_role - src: https://github.com/bennojoy/nginx - version: main - - # from GitHub, specifying a specific commit hash - - src: https://github.com/bennojoy/nginx - version: "ee8aa41" - - # from a webserver, where the role is packaged in a tar.gz - - name: http-role-gz - src: https://some.webserver.example.com/files/main.tar.gz - - # from a webserver, where the role is packaged in a tar.bz2 - - name: http-role-bz2 - src: https://some.webserver.example.com/files/main.tar.bz2 - - # from a webserver, where the role is packaged in a tar.xz (Python 3.x only) - - name: http-role-xz - src: https://some.webserver.example.com/files/main.tar.xz - - # from Bitbucket - - src: git+https://bitbucket.org/willthames/git-ansible-galaxy - version: v1.4 - - # from Bitbucket, alternative syntax and caveats - - src: https://bitbucket.org/willthames/hg-ansible-galaxy - scm: hg - - # from GitLab or other git-based scm, using git+ssh - - src: git@gitlab.company.com:mygroup/ansible-core.git - scm: git - version: "0.1" # quoted, so YAML doesn't parse this as a floating-point value - -.. warning:: - - Embedding credentials into a SCM URL is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs. - -Installing roles and collections from the same requirements.yml file ---------------------------------------------------------------------- - -You can install roles and collections from the same requirements files - -.. code-block:: yaml - - --- - roles: - # Install a role from Ansible Galaxy. - - name: geerlingguy.java - version: "1.9.6" # note that ranges are not supported for roles - - collections: - # Install a collection from Ansible Galaxy. - - name: geerlingguy.php_roles - version: ">=0.9.3" - source: https://galaxy.ansible.com - -Installing multiple roles from multiple files ---------------------------------------------- - -For large projects, the ``include`` directive in a :file:`requirements.yml` file provides the ability to split a large file into multiple smaller files. - -For example, a project may have a :file:`requirements.yml` file, and a :file:`webserver.yml` file. - -Below are the contents of the :file:`webserver.yml` file: - -.. code-block:: bash - - # from github - - src: https://github.com/bennojoy/nginx - - # from Bitbucket - - src: git+https://bitbucket.org/willthames/git-ansible-galaxy - version: v1.4 - -The following shows the contents of the :file:`requirements.yml` file that now includes the :file:`webserver.yml` file: - -.. code-block:: bash - - # from galaxy - - name: yatesr.timezone - - include: /webserver.yml - -To install all the roles from both files, pass the root file, in this case :file:`requirements.yml` on the -command line, as follows: - -.. code-block:: bash - - $ ansible-galaxy install -r requirements.yml - -.. _galaxy_dependencies: - -Dependencies ------------- - -Roles can also be dependent on other roles, and when you install a role that has dependencies, those dependencies will automatically be installed to the ``roles_path``. - -There are two ways to define the dependencies of a role: - -* using ``meta/requirements.yml`` -* using ``meta/main.yml`` - -Using ``meta/requirements.yml`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. versionadded:: 2.10 - -You can create the file ``meta/requirements.yml`` and define dependencies in the same format used for :file:`requirements.yml` described in the `Installing multiple roles from a file`_ section. - -From there, you can import or include the specified roles in your tasks. - -Using ``meta/main.yml`` -^^^^^^^^^^^^^^^^^^^^^^^ - -Alternatively, you can specify role dependencies in the ``meta/main.yml`` file by providing a list of roles under the ``dependencies`` section. If the source of a role is Galaxy, you can simply specify the role in -the format ``namespace.role_name``. You can also use the more complex format in :file:`requirements.yml`, allowing you to provide ``src``, ``scm``, ``version``, and ``name``. - -Dependencies installed that way, depending on other factors described below, will also be executed **before** this role is executed during play execution. -To better understand how dependencies are handled during play execution, see :ref:`playbooks_reuse_roles`. - -The following shows an example ``meta/main.yml`` file with dependent roles: - -.. code-block:: yaml - - --- - dependencies: - - geerlingguy.java - - galaxy_info: - author: geerlingguy - description: Elasticsearch for Linux. - company: "Midwestern Mac, LLC" - license: "license (BSD, MIT)" - min_ansible_version: 2.4 - platforms: - - name: EL - versions: - - all - - name: Debian - versions: - - all - - name: Ubuntu - versions: - - all - galaxy_tags: - - web - - system - - monitoring - - logging - - lucene - - elk - - elasticsearch - -Tags are inherited *down* the dependency chain. In order for tags to be applied to a role and all its dependencies, the tag should be applied to the role, not to all the tasks within a role. - -Roles listed as dependencies are subject to conditionals and tag filtering, and may not execute fully depending on -what tags and conditionals are applied. - -If the source of a role is Galaxy, specify the role in the format *namespace.role_name*: - -.. code-block:: yaml - - dependencies: - - geerlingguy.apache - - geerlingguy.ansible - - -Alternately, you can specify the role dependencies in the complex form used in :file:`requirements.yml` as follows: - -.. code-block:: yaml - - dependencies: - - name: geerlingguy.ansible - - name: composer - src: git+https://github.com/geerlingguy/ansible-role-composer.git - version: 775396299f2da1f519f0d8885022ca2d6ee80ee8 - -.. note:: - - Galaxy expects all role dependencies to exist in Galaxy, and therefore dependencies to be specified in the - ``namespace.role_name`` format. If you import a role with a dependency where the ``src`` value is a URL, the import process will fail. - -List installed roles --------------------- - -Use ``list`` to show the name and version of each role installed in the *roles_path*. - -.. code-block:: bash - - $ ansible-galaxy list - - ansible-network.network-engine, v2.7.2 - - ansible-network.config_manager, v2.6.2 - - ansible-network.cisco_nxos, v2.7.1 - - ansible-network.vyos, v2.7.3 - - ansible-network.cisco_ios, v2.7.0 - -Remove an installed role ------------------------- - -Use ``remove`` to delete a role from *roles_path*: - -.. code-block:: bash - - $ ansible-galaxy remove namespace.role_name - - -.. seealso:: - :ref:`collections` - Shareable collections of modules, playbooks and roles - :ref:`playbooks_reuse_roles` - Reusable tasks, handlers, and other files in a known directory structure - :ref:`command_line_tools` - Perform other related operations - diff --git a/docs/docsite/rst/getting_started/ansible_output/first_playbook_output.txt b/docs/docsite/rst/getting_started/ansible_output/first_playbook_output.txt deleted file mode 100644 index e5e1dcb8fd4..00000000000 --- a/docs/docsite/rst/getting_started/ansible_output/first_playbook_output.txt +++ /dev/null @@ -1,27 +0,0 @@ -PLAY [My first play] ********************************************************************** - -TASK [Gathering Facts] ******************************************************************** -ok: [vm01] -ok: [vm02] -ok: [vm03] - -TASK [Ping my hosts] ********************************************************************** -ok: [vm01] -ok: [vm02] -ok: [vm03] - -TASK [Print message] ********************************************************************** -ok: [vm01] => { - "msg": "Hello world" -} -ok: [vm02] => { - "msg": "Hello world" -} -ok: [vm03] => { - "msg": "Hello world" -} - -PLAY RECAP ******************************************************************************** -vm01: ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -vm02: ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -vm03: ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 diff --git a/docs/docsite/rst/getting_started/ansible_output/ping_inventory_output.txt b/docs/docsite/rst/getting_started/ansible_output/ping_inventory_output.txt deleted file mode 100644 index cd7c4dd7c19..00000000000 --- a/docs/docsite/rst/getting_started/ansible_output/ping_inventory_output.txt +++ /dev/null @@ -1,21 +0,0 @@ -vm03 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" -} -vm02 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" -} -vm01 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" -} \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/ansible_output/ping_output.txt b/docs/docsite/rst/getting_started/ansible_output/ping_output.txt deleted file mode 100644 index 9fe88862ef3..00000000000 --- a/docs/docsite/rst/getting_started/ansible_output/ping_output.txt +++ /dev/null @@ -1,21 +0,0 @@ -192.0.2.50 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" - } -192.0.2.51 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" - } -192.0.2.52 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python3" - }, - "changed": false, - "ping": "pong" - } \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/basic_concepts.rst b/docs/docsite/rst/getting_started/basic_concepts.rst deleted file mode 100644 index cc433c81f2f..00000000000 --- a/docs/docsite/rst/getting_started/basic_concepts.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. _basic_concepts: - -**************** -Ansible concepts -**************** - -These concepts are common to all uses of Ansible. -You should understand them before using Ansible or reading the documentation. - -.. contents:: - :local: - -.. include:: /shared_snippets/basic_concepts.txt diff --git a/docs/docsite/rst/getting_started/get_started_inventory.rst b/docs/docsite/rst/getting_started/get_started_inventory.rst deleted file mode 100644 index 8df73302073..00000000000 --- a/docs/docsite/rst/getting_started/get_started_inventory.rst +++ /dev/null @@ -1,102 +0,0 @@ -.. _get_started_inventory: - -********************* -Building an inventory -********************* - -Inventories organize managed nodes in centralized files that provide Ansible with system information and network locations. -Using an inventory file, Ansible can manage a large number of hosts with a single command. -Inventories also help you use Ansible more efficiently by reducing the number of command-line options you need to specify. -For example, inventories usually contain the SSH user so you do not need to include the ``-u`` flag when running Ansible commands. - -In the previous section, you added managed nodes directly to the ``/etc/ansible/hosts`` file. -Now let's create an inventory file that you can add to source control for flexibility, reuse, and for sharing with other users. - -.. note:: - Inventory files can be in ``INI`` or ``YAML`` format. - For demonstration purposes, this section uses ``YAML`` format only. - -Complete the following steps: - -#. Open a terminal window on your control node. -#. Create a new inventory file named ``inventory.yaml`` in any directory and open it for editing. -#. Add a new group for your hosts then specify the IP address or fully qualified domain name (FQDN) of each managed node with the ``ansible_host`` field. - The following example adds the IP addresses of three virtual machines in KVM: - - .. literalinclude:: yaml/inventory_example_vms.yaml - :language: yaml - -#. Verify your inventory. - If you created your inventory in a directory other than your home directory, specify the full path with the ``-i`` option. - - .. code-block:: bash - - ansible-inventory -i inventory.yaml --list - -#. Ping the managed nodes in your inventory. - In this example, the group name is ``virtualmachines`` which you can specify with the ``ansible`` command instead of ``all``. - - .. code-block:: bash - - ansible virtualmachines -m ping -i inventory.yaml - - .. literalinclude:: ansible_output/ping_inventory_output.txt - :language: text - -Congratulations! You have successfully built an inventory. - -Tips for building inventories -============================= - -* Ensure that group names are meaningful and unique. Group names are also case sensitive. -* Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in group names. -* Group hosts in your inventory logically according to their **What**, **Where**, and **When**. - - What - Group hosts according to the topology, for example: db, web, leaf, spine. - Where - Group hosts by geographic location, for example: datacenter, region, floor, building. - When - Group hosts by stage, for example: development, test, staging, production. - -Use metagroups --------------- - -Create a metagroup that organizes multiple groups in your inventory with the following syntax: - -.. code-block:: yaml - - metagroupname: - children: - -The following inventory illustrates a basic structure for a data center. -This example inventory contains a ``network`` metagroup that includes all network devices and a ``datacenter`` metagroup that includes the ``network`` group and all webservers. - -.. literalinclude:: yaml/inventory_group_structure.yaml - :language: yaml - -Create variables ----------------- - -Variables set values for managed nodes, such as the IP address, FQDN, operating system, and SSH user, so you do not need to pass them when running Ansible commands. - -Variables can apply to specific hosts. - -.. literalinclude:: yaml/inventory_variables_host.yaml - :language: yaml - -Variables can also apply to all hosts in a group. - -.. literalinclude:: yaml/inventory_variables_group.yaml - :language: yaml - -Now that you know how to build an inventory, continue by :ref:`learning how to create a playbook`. - -.. seealso:: - - :ref:`intro_inventory` - Learn more about inventories in ``YAML`` or ``INI`` format. - :ref:`variables_in_inventory` - Find out more about inventory variables and their syntax. - :ref:`vault` - Find out how to encrypt sensitive content in your inventory such as passwords and keys. diff --git a/docs/docsite/rst/getting_started/get_started_playbook.rst b/docs/docsite/rst/getting_started/get_started_playbook.rst deleted file mode 100644 index 7ee1be6d3bc..00000000000 --- a/docs/docsite/rst/getting_started/get_started_playbook.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _get_started_playbook: - -******************* -Creating a playbook -******************* - -Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure managed nodes. - -Playbook - A list of plays that define the order in which Ansible performs operations, from top to bottom, to achieve an overall goal. - -Play - An ordered list of tasks that maps to managed nodes in an inventory. - -Task - A list of one or more modules that defines the operations that Ansible performs. - -Module - A unit of code or binary that Ansible runs on managed nodes. - Ansible modules are grouped in collections with a :term:`Fully Qualified Collection Name (FQCN)` for each module. - -In the previous section, you used the ``ansible`` command to ping hosts in your inventory. -Now let's create a playbook that pings your hosts and also prints a "Hello world" message. - -Complete the following steps: - -#. Open a terminal window on your control node. -#. Create a new playbook file named ``playbook.yaml`` in any directory and open it for editing. -#. Add the following content to ``playbook.yaml``: - - .. literalinclude:: yaml/first_playbook.yaml - :language: yaml - -#. Run your playbook. - - .. code-block:: bash - - ansible-playbook -i inventory.yaml playbook.yaml - -Ansible returns the following output: - -.. literalinclude:: ansible_output/first_playbook_output.txt - :language: text - -In this output you can see: - -* The names that you give the play and each task. - You should always use descriptive names that make it easy to verify and troubleshoot playbooks. - -* The ``Gather Facts`` task runs implicitly. - By default Ansible gathers information about your inventory that it can use in the playbook. - -* The status of each task. - Each task has a status of ``ok`` which means it ran successfully. - -* The play recap that summarizes results of all tasks in the playbook per host. - In this example, there are three tasks so ``ok=3`` indicates that each task ran successfully. - -Congratulations! You have just created your first Ansible playbook. - -.. seealso:: - - :ref:`playbooks_intro` - Start building playbooks for real world scenarios. - :ref:`working_with_playbooks` - Go into more detail with Ansible playbooks. - :ref:`playbooks_best_practices` - Get tips and tricks for using playbooks. - :ref:`vars_and_facts` - Learn more about the ``gather_facts`` keyword in playbooks. \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/index.rst b/docs/docsite/rst/getting_started/index.rst deleted file mode 100644 index 818c7fbe379..00000000000 --- a/docs/docsite/rst/getting_started/index.rst +++ /dev/null @@ -1,99 +0,0 @@ -.. _getting_started_index: - -############################ -Getting started with Ansible -############################ - -Ansible automates the management of remote systems and controls their desired state. -A basic Ansible environment has three main components: - - -Control node - A system on which Ansible is installed. - You run Ansible commands such as ``ansible`` or ``ansible-inventory`` on a control node. - -Managed node - A remote system, or host, that Ansible controls. - -Inventory - A list of managed nodes that are logically organized. - You create an inventory on the control node to describe host deployments to Ansible. - -.. image:: ../images/ansible_basic.svg - :width: 400px - :align: center - :height: 200px - :alt: Basic components of an Ansible environment include a control node, an inventory of managed nodes, and a module copied to each managed node. - -Ready to start using Ansible? -Complete the following steps to get up and running: - -#. Install Ansible. Visit the :ref:`installation guide` for complete details. - - .. code-block:: bash - - python3 -m pip install --user ansible - -#. Create an inventory by adding the IP address or fully qualified domain name (FQDN) of one or more remote systems to ``/etc/ansible/hosts``. - The following example adds the IP addresses of three virtual machines in KVM: - - .. code-block:: ini - - [myvirtualmachines] - 192.0.2.50 - 192.0.2.51 - 192.0.2.52 - -#. Verify the hosts in your inventory. - - .. code-block:: bash - - ansible all --list-hosts - - .. code-block:: ansible-output - - hosts (1): - 192.0.2.50 - 192.0.2.51 - 192.0.2.52 - -#. Set up SSH connections so Ansible can connect to the managed nodes. - - a. Add your public SSH key to the ``authorized_keys`` file on each remote system. - b. Test the SSH connections, for example: - - .. code-block:: bash - - ssh username@192.0.2.50 - - If the username on the control node is different on the host, you need to pass the ``-u`` option with the ``ansible`` command. - -#. Ping the managed nodes. - - .. code-block:: bash - - ansible all -m ping - - .. literalinclude:: ansible_output/ping_output.txt - :language: text - -Congratulations! You are now using Ansible. -Continue by :ref:`learning how to build an inventory`. - -.. seealso:: - - `Ansible Demos `_ - Demonstrations of different Ansible usecases - `Ansible Labs `_ - Labs to provide further knowledge on different topics - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels - -.. toctree:: - :maxdepth: 1 - - get_started_inventory - get_started_playbook - basic_concepts \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/yaml/first_playbook.yaml b/docs/docsite/rst/getting_started/yaml/first_playbook.yaml deleted file mode 100644 index dd0ef63f0b3..00000000000 --- a/docs/docsite/rst/getting_started/yaml/first_playbook.yaml +++ /dev/null @@ -1,8 +0,0 @@ -- name: My first play - hosts: virtualmachines - tasks: - - name: Ping my hosts - ansible.builtin.ping: - - name: Print message - ansible.builtin.debug: - msg: Hello world diff --git a/docs/docsite/rst/getting_started/yaml/inventory_example_vms.yaml b/docs/docsite/rst/getting_started/yaml/inventory_example_vms.yaml deleted file mode 100644 index d5edbca5481..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_example_vms.yaml +++ /dev/null @@ -1,8 +0,0 @@ -virtualmachines: - hosts: - vm01: - ansible_host: 192.0.2.50 - vm02: - ansible_host: 192.0.2.51 - vm03: - ansible_host: 192.0.2.52 \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/yaml/inventory_group_structure.yaml b/docs/docsite/rst/getting_started/yaml/inventory_group_structure.yaml deleted file mode 100644 index 93dd6a991ae..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_group_structure.yaml +++ /dev/null @@ -1,30 +0,0 @@ -leafs: - hosts: - leaf01: - ansible_host: 192.0.2.100 - leaf02: - ansible_host: 192.0.2.110 - -spines: - hosts: - spine01: - ansible_host: 192.0.2.120 - spine02: - ansible_host: 192.0.2.130 - -network: - children: - leafs: - spines: - -webservers: - hosts: - webserver01: - ansible_host: 192.0.2.140 - webserver02: - ansible_host: 192.0.2.150 - -datacenter: - children: - network: - webservers: \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/yaml/inventory_variables_group.yaml b/docs/docsite/rst/getting_started/yaml/inventory_variables_group.yaml deleted file mode 100644 index 6f934aaa74f..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_variables_group.yaml +++ /dev/null @@ -1,10 +0,0 @@ -webservers: - hosts: - webserver01: - ansible_host: 192.0.2.140 - http_port: 80 - webserver02: - ansible_host: 192.0.2.150 - http_port: 443 - vars: - ansible_user: my_server_user \ No newline at end of file diff --git a/docs/docsite/rst/getting_started/yaml/inventory_variables_host.yaml b/docs/docsite/rst/getting_started/yaml/inventory_variables_host.yaml deleted file mode 100644 index 98ab165e072..00000000000 --- a/docs/docsite/rst/getting_started/yaml/inventory_variables_host.yaml +++ /dev/null @@ -1,8 +0,0 @@ -webservers: - hosts: - webserver01: - ansible_host: 192.0.2.140 - http_port: 80 - webserver02: - ansible_host: 192.0.2.150 - http_port: 443 \ No newline at end of file diff --git a/docs/docsite/rst/images/ansible_basic.svg b/docs/docsite/rst/images/ansible_basic.svg deleted file mode 100644 index 6217c89ff39..00000000000 --- a/docs/docsite/rst/images/ansible_basic.svg +++ /dev/null @@ -1,333 +0,0 @@ - - - - diff --git a/docs/docsite/rst/images/cow.png b/docs/docsite/rst/images/cow.png deleted file mode 100644 index 9ace4401908..00000000000 Binary files a/docs/docsite/rst/images/cow.png and /dev/null differ diff --git a/docs/docsite/rst/installation_guide/index.rst b/docs/docsite/rst/installation_guide/index.rst deleted file mode 100644 index 332560e885a..00000000000 --- a/docs/docsite/rst/installation_guide/index.rst +++ /dev/null @@ -1,14 +0,0 @@ -****************** -Installation Guide -****************** - -Welcome to the Ansible Installation Guide! - - -.. toctree:: - :maxdepth: 2 - - intro_installation - installation_distros - intro_configuration - diff --git a/docs/docsite/rst/installation_guide/installation_distros.rst b/docs/docsite/rst/installation_guide/installation_distros.rst deleted file mode 100644 index f7200416cbd..00000000000 --- a/docs/docsite/rst/installation_guide/installation_distros.rst +++ /dev/null @@ -1,110 +0,0 @@ -.. _installing_distros: - -Installing Ansible on specific operating systems -================================================ - -The ``ansible`` package can always be :ref:`installed from PyPI using pip ` on most systems but it is also packaged and maintained by the community for a variety of Linux distributions. - -The following instructions will guide you through installing the ``ansible`` package with your preferred distribution's package manager. - -.. contents:: - :local: - -Installing Ansible on Fedora or CentOS --------------------------------------- - -On Fedora: - -.. code-block:: bash - - $ sudo dnf install ansible - -On CentOS: - -.. code-block:: bash - - $ sudo yum install epel-release - $ sudo yum install ansible - -RPMs for currently supported versions of CentOS are also available from `EPEL `_. - - -.. _from_apt: - -Installing Ansible on Ubuntu ----------------------------- - -Ubuntu builds are available `in a PPA here `_. - -To configure the PPA on your system and install Ansible run these commands: - -.. code-block:: bash - - $ sudo apt update - $ sudo apt install software-properties-common - $ sudo add-apt-repository --yes --update ppa:ansible/ansible - $ sudo apt install ansible - -.. note:: On older Ubuntu distributions, "software-properties-common" is called "python-software-properties". You may want to use ``apt-get`` rather than ``apt`` in older versions. Also, be aware that only newer distributions (that is, 18.04, 18.10, and later) have a ``-u`` or ``--update`` flag. Adjust your script as needed. - - - - -Installing Ansible on Debian ----------------------------- - -Debian users can use the same source as the Ubuntu PPA (using the following table). - -.. list-table:: - :header-rows: 1 - - * - Debian - - - - Ubuntu - * - Debian 11 (Bullseye) - - -> - - Ubuntu 20.04 (Focal) - * - Debian 10 (Buster) - - -> - - Ubuntu 18.04 (Bionic) - - -.. note:: - - Ansible releases are only built for Ubuntu 18.04 (Bionic) or later releases. - -Add the following line to ``/etc/apt/sources.list`` or ``/etc/apt/sources.list.d/ansible.list``: - -.. code-block:: bash - - deb http://ppa.launchpad.net/ansible/ansible/ubuntu MATCHING_UBUNTU_CODENAME_HERE main - -Example for Debian 11 (Bullseye) - -.. code-block:: bash - - deb http://ppa.launchpad.net/ansible/ansible/ubuntu focal main - -Then run these commands: - -.. code-block:: bash - - $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367 - $ sudo apt update - $ sudo apt install ansible - - - -.. _from_windows: - -Installing Ansible on Windows ------------------------------- - -You cannot use a Windows system for the Ansible control node. See :ref:`windows_faq_ansible` - -.. seealso:: - - `Installing Ansible on Arch Linux `_ - Distro-specific installation on Arch Linux - `Installing Ansible on Clear Linux `_ - Distro-specific installation on Clear Linux diff --git a/docs/docsite/rst/installation_guide/intro_configuration.rst b/docs/docsite/rst/installation_guide/intro_configuration.rst deleted file mode 100644 index 131c6c44628..00000000000 --- a/docs/docsite/rst/installation_guide/intro_configuration.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. _intro_configuration: - -******************* -Configuring Ansible -******************* - -.. contents:: Topics - - -This topic describes how to control Ansible settings. - - -.. _the_configuration_file: - -Configuration file -================== - -Certain settings in Ansible are adjustable via a configuration file (ansible.cfg). -The stock configuration should be sufficient for most users, but there may be reasons you would want to change them. -Paths where configuration file is searched are listed in :ref:`reference documentation`. - -.. _getting_the_latest_configuration: - -Getting the latest configuration --------------------------------- - -If installing Ansible from a package manager, the latest ``ansible.cfg`` file should be present in ``/etc/ansible``, possibly -as a ``.rpmnew`` file (or other) as appropriate in the case of updates. - -If you installed Ansible from pip or from source, you may want to create this file in order to override -default settings in Ansible. - -An `example file is available on GitHub `_. - -For more details and a full listing of available configurations go to :ref:`configuration_settings`. Starting with Ansible version 2.4, you can use the :ref:`ansible-config` command line utility to list your available options and inspect the current values. - -For in-depth details, see :ref:`ansible_configuration_settings`. - -.. _environmental_configuration: - -Environmental configuration -=========================== - -Ansible also allows configuration of settings using environment variables. -If these environment variables are set, they will override any setting loaded from the configuration file. - -You can get a full listing of available environment variables from :ref:`ansible_configuration_settings`. - - -.. _command_line_configuration: - -Command line options -==================== - -Not all configuration options are present in the command line, just the ones deemed most useful or common. -Settings in the command line will override those passed through the configuration file and the environment. - -The full list of options available is in :ref:`ansible-playbook` and :ref:`ansible`. - diff --git a/docs/docsite/rst/installation_guide/intro_installation.rst b/docs/docsite/rst/installation_guide/intro_installation.rst deleted file mode 100644 index d8627889f62..00000000000 --- a/docs/docsite/rst/installation_guide/intro_installation.rst +++ /dev/null @@ -1,294 +0,0 @@ -.. _installation_guide: -.. _intro_installation_guide: - -****************** -Installing Ansible -****************** - -Ansible is an agentless automation tool that you install on a single host (referred to as the control node). From the control node, Ansible can manage an entire fleet of machines and other devices (referred to as managed nodes) remotely with SSH, Powershell remoting, and numerous other transports, all from a simple command-line interface with no databases or daemons required. - -.. contents:: - :local: - -.. _control_node_requirements: - -Control node requirements -========================= - -For your *control* node (the machine that runs Ansible), you can use nearly any UNIX-like machine with Python 3.9 or newer installed. This includes Red Hat, Debian, Ubuntu, macOS, BSDs, and Windows under a `Windows Subsystem for Linux (WSL) distribution `_. Windows without WSL is not natively supported as a control node; see `Matt Davis' blog post `_ for more information. - -.. _managed_node_requirements: - -Managed node requirements -========================= - -The *managed* node (the machine that Ansible is managing) does not require Ansible to be installed, but requires Python 2.7, or Python 3.5 - 3.11 to run Ansible library code. -The managed node also needs a user account that can SSH to the node with an interactive POSIX shell. - -.. note:: - - Network modules are an exception and do not require Python on the managed device. See :ref:`network_modules`. - -.. _node_requirements_summary: - -Node requirement summary -======================== - -The table below lists the current and historical versions of Python -required on control and managed nodes. - -.. list-table:: - :header-rows: 1 - - * - ansible-core Version - - Control node Python - - Managed node Python - * - 2.11 - - Python 2.7, Python 3.5 - 3.9 `[†]`_ - - Python 2.6 - 2.7, Python 3.5 - 3.9 - * - 2.12 - - Python 3.8 - 3.10 - - Python 2.6 - 2.7, Python 3.5 - 3.10 - * - 2.13 - - Python 3.8 - 3.10 - - Python 2.7, Python 3.5 - 3.10 - * - 2.14 - - Python 3.9 - 3.11 - - Python 2.7, Python 3.5 - 3.11 - -_`[†]`: Has a soft requirement of Python 3.8 as not packaged for older versions - -.. _getting_ansible: - -.. _what_version: - -Selecting an Ansible package and version to install -==================================================== - -Ansible's community packages are distributed in two ways: a minimalist language and runtime package called ``ansible-core``, and a much larger "batteries included" package called ``ansible``, which adds a community-curated selection of :ref:`Ansible Collections ` for automating a wide variety of devices. Choose the package that fits your needs; The following instructions use ``ansible``, but you can substitute ``ansible-core`` if you prefer to start with a more minimal package and separately install only the Ansible Collections you require. The ``ansible`` or ``ansible-core`` packages may be available in your operating systems package manager, and you are free to install these packages with your preferred method. These installation instructions only cover the officially supported means of installing the python package with ``pip``. - -Installing and upgrading Ansible -================================ - -Locating Python ---------------- - -Locate and remember the path to the Python interpreter you wish to use to run Ansible. The following instructions refer to this Python as ``python3``. For example, if you've determined that you want the Python at ``/usr/bin/python3.9`` to be the one that you'll install Ansible under, specify that instead of ``python3``. - -Ensuring ``pip`` is available ------------------------------ - -To verify whether ``pip`` is already installed for your preferred Python: - -.. code-block:: console - - $ python3 -m pip -V - -If all is well, you should see something like the following: - -.. code-block:: console - - $ python3 -m pip -V - pip 21.0.1 from /usr/lib/python3.9/site-packages/pip (python 3.9) - -If so, ``pip`` is available, and you can move on to the :ref:`next step `. - -If you see an error like ``No module named pip``, you'll need to install ``pip`` under your chosen Python interpreter before proceeding. This may mean installing an additional OS package (for example, ``python3-pip``), or installing the latest ``pip`` directly from the Python Packaging Authority by running the following: - -.. code-block:: console - - $ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py - $ python3 get-pip.py --user - -You may need to perform some additional configuration before you are able to run Ansible. See the Python documentation on `installing to the user site`_ for more information. - -.. _installing to the user site: https://packaging.python.org/tutorials/installing-packages/#installing-to-the-user-site - -.. _pip_install: - -Installing Ansible ------------------- - -Use ``pip`` in your selected Python environment to install the Ansible package of your choice for the current user: - -.. code-block:: console - - $ python3 -m pip install --user ansible - -Alternately, you can install a specific version of ``ansible-core`` in this Python environment: - -.. code-block:: console - - $ python3 -m pip install --user ansible-core==2.12.3 - -.. _pip_upgrade: - -Upgrading Ansible ------------------ - -To upgrade an existing Ansible installation in this Python environment to the latest released version, simply add ``--upgrade`` to the command above: - -.. code-block:: console - - $ python3 -m pip install --upgrade --user ansible - -Confirming your installation ----------------------------- - -You can test that Ansible is installed correctly by checking the version: - -.. code-block:: console - - $ ansible --version - -The version displayed by this command is for the associated ``ansible-core`` package that has been installed. - -To check the version of the ``ansible`` package that has been installed: - -.. code-block:: console - - $ python3 -m pip show ansible - -.. _development_install: - -Installing for development -========================== - -If you are testing new features, fixing bugs, or otherwise working with the development team on changes to the core code, you can install and run the source from GitHub. - -.. note:: - - You should only install and run the ``devel`` branch if you are modifying ``ansible-core`` or trying out features under development. This is a rapidly changing source of code and can become unstable at any point. - -For more information on getting involved in the Ansible project, see the :ref:`ansible_community_guide`. For more information on creating Ansible modules and Collections, see the :ref:`developer_guide`. - -.. _from_pip_devel: - -Installing ``devel`` from GitHub with ``pip`` ---------------------------------------------- - -You can install the ``devel`` branch of ``ansible-core`` directly from GitHub with ``pip``: - -.. code-block:: console - - $ python3 -m pip install --user https://github.com/ansible/ansible/archive/devel.tar.gz - -You can replace ``devel`` in the URL mentioned above, with any other branch or tag on GitHub to install older versions of Ansible, tagged alpha or beta versions, and release candidates. - -.. _from_source: - -Running the ``devel`` branch from a clone ------------------------------------------ - -``ansible-core`` is easy to run from source. You do not need ``root`` permissions to use it and there is no software to actually install. No daemons or database setup are required. - -#. Clone the ``ansible-core`` repository - - .. code-block:: console - - $ git clone https://github.com/ansible/ansible.git - $ cd ./ansible - -#. Setup the Ansible environment - - * Using Bash - - .. code-block:: console - - $ source ./hacking/env-setup - - * Using Fish - - .. code-block:: console - - $ source ./hacking/env-setup.fish - - * To suppress spurious warnings/errors, use ``-q`` - - .. code-block:: console - - $ source ./hacking/env-setup -q - -#. Install Python dependencies - - .. code-block:: console - - $ python3 -m pip install --user -r ./requirements.txt - -#. Update the ``devel`` branch of ``ansible-core`` on your local machine - - Use pull-with-rebase so any local changes are replayed. - - .. code-block:: console - - $ git pull --rebase - -.. _shell_completion: - -Adding Ansible command shell completion -======================================= - -You can add shell completion of the Ansible command line utilities by installing an optional dependency called ``argcomplete``. ``argcomplete`` supports bash, and has limited support for zsh and tcsh. - -For more information about installation and configuration, see the `argcomplete documentation `_. - -Installing ``argcomplete`` --------------------------- - -.. code-block:: console - - $ python3 -m pip install --user argcomplete - -Configuring ``argcomplete`` ---------------------------- - -There are 2 ways to configure ``argcomplete`` to allow shell completion of the Ansible command line utilities: globally or per command. - -Global configuration -^^^^^^^^^^^^^^^^^^^^ - -Global completion requires bash 4.2. - -.. code-block:: console - - $ activate-global-python-argcomplete --user - -This will write a bash completion file to a user location. Use ``--dest`` to change the location or ``sudo`` to set up the completion globally. - -Per command configuration -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you do not have bash 4.2, you must register each script independently. - -.. code-block:: console - - $ eval $(register-python-argcomplete ansible) - $ eval $(register-python-argcomplete ansible-config) - $ eval $(register-python-argcomplete ansible-console) - $ eval $(register-python-argcomplete ansible-doc) - $ eval $(register-python-argcomplete ansible-galaxy) - $ eval $(register-python-argcomplete ansible-inventory) - $ eval $(register-python-argcomplete ansible-playbook) - $ eval $(register-python-argcomplete ansible-pull) - $ eval $(register-python-argcomplete ansible-vault) - -You should place the above commands into your shells profile file such as ``~/.profile`` or ``~/.bash_profile``. - -Using ``argcomplete`` with zsh or tcsh -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -See the `argcomplete documentation `_. - - -.. seealso:: - - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning ansible's configuration management language - :ref:`installation_faqs` - Ansible Installation related to FAQs - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory/implicit_localhost.rst b/docs/docsite/rst/inventory/implicit_localhost.rst deleted file mode 100644 index ced98df8e1d..00000000000 --- a/docs/docsite/rst/inventory/implicit_localhost.rst +++ /dev/null @@ -1,40 +0,0 @@ -:orphan: - -.. _implicit_localhost: - -Implicit 'localhost' -==================== - -When you try to reference a ``localhost`` and you don't have it defined in inventory, Ansible will create an implicit one for you.: - -.. code-block:: yaml - - - hosts: all - tasks: - - name: check that i have log file for all hosts on my local machine - stat: path=/var/log/hosts/{{inventory_hostname}}.log - delegate_to: localhost - -In a case like this (or ``local_action``) when Ansible needs to contact a 'localhost' but you did not supply one, we create one for you. This host is defined with specific connection variables equivalent to this in an inventory: - -.. code-block:: yaml - - ... - - hosts: - localhost: - vars: - ansible_connection: local - ansible_python_interpreter: "{{ansible_playbook_python}}" - -This ensures that the proper connection and Python are used to execute your tasks locally. -You can override the built-in implicit version by creating a ``localhost`` host entry in your inventory. At that point, all implicit behaviors are ignored; the ``localhost`` in inventory is treated just like any other host. Group and host vars will apply, including connection vars, which includes the ``ansible_python_interpreter`` setting. This will also affect ``delegate_to: localhost`` and ``local_action``, the latter being an alias to the former. - -.. note:: - - - This host is not targetable via any group, however it will use vars from ``host_vars`` and from the 'all' group. - - Implicit localhost does not appear in the ``hostvars`` magic variable unless demanded, such as by ``"{{ hostvars['localhost'] }}"``. - - The ``inventory_file`` and ``inventory_dir`` magic variables are not available for the implicit localhost as they are dependent on **each inventory host**. - - This implicit host also gets triggered by using ``127.0.0.1`` or ``::1`` as they are the IPv4 and IPv6 representations of 'localhost'. - - Even though there are many ways to create it, there will only ever be ONE implicit localhost, using the name first used to create it. - - Having ``connection: local`` does NOT trigger an implicit localhost, you are just changing the connection for the ``inventory_hostname``. diff --git a/docs/docsite/rst/inventory_guide/connection_details.rst b/docs/docsite/rst/inventory_guide/connection_details.rst deleted file mode 100644 index 5e332160617..00000000000 --- a/docs/docsite/rst/inventory_guide/connection_details.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. _connections: - -****************************** -Connection methods and details -****************************** - -This section shows you how to expand and refine the connection methods Ansible uses for your inventory. - -ControlPersist and paramiko ---------------------------- - -By default, Ansible uses native OpenSSH, because it supports ControlPersist (a performance feature), Kerberos, and options in ``~/.ssh/config`` such as Jump Host setup. If your control machine uses an older version of OpenSSH that does not support ControlPersist, Ansible will fallback to a Python implementation of OpenSSH called 'paramiko'. - -.. _connection_set_user: - -Setting a remote user ---------------------- - -By default, Ansible connects to all remote devices with the user name you are using on the control node. If that user name does not exist on a remote device, you can set a different user name for the connection. If you just need to do some tasks as a different user, look at :ref:`become`. You can set the connection user in a playbook: - -.. code-block:: yaml - - --- - - name: update webservers - hosts: webservers - remote_user: admin - - tasks: - - name: thing to do first in this playbook - . . . - -as a host variable in inventory: - -.. code-block:: text - - other1.example.com ansible_connection=ssh ansible_user=myuser - other2.example.com ansible_connection=ssh ansible_user=myotheruser - -or as a group variable in inventory: - -.. code-block:: yaml - - cloud: - hosts: - cloud1: my_backup.cloud.com - cloud2: my_backup2.cloud.com - vars: - ansible_user: admin - -.. seealso:: - - :ref:`ssh_connection` - Details on the ``remote_user`` keyword and ``ansible_user`` variable. - :ref:`general_precedence_rules` - Details on Ansible precedence rules. - -Setting up SSH keys -------------------- - -By default, Ansible assumes you are using SSH keys to connect to remote machines. SSH keys are encouraged, but you can use password authentication if needed with the ``--ask-pass`` option. If you need to provide a password for :ref:`privilege escalation ` (sudo, pbrun, and so on), use ``--ask-become-pass``. - -.. include:: shared_snippets/SSH_password_prompt.txt - -To set up SSH agent to avoid retyping passwords, you can do: - -.. code-block:: bash - - $ ssh-agent bash - $ ssh-add ~/.ssh/id_rsa - -Depending on your setup, you may wish to use Ansible's ``--private-key`` command line option to specify a pem file instead. You can also add the private key file: - -.. code-block:: bash - - $ ssh-agent bash - $ ssh-add ~/.ssh/keypair.pem - -Another way to add private key files without using ssh-agent is using ``ansible_ssh_private_key_file`` in an inventory file as explained here: :ref:`intro_inventory`. - -Running against localhost -------------------------- - -You can run commands against the control node by using "localhost" or "127.0.0.1" for the server name: - -.. code-block:: bash - - $ ansible localhost -m ping -e 'ansible_python_interpreter="/usr/bin/env python"' - -You can specify localhost explicitly by adding this to your inventory file: - -.. code-block:: bash - - localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python" - -.. _host_key_checking_on: - -Managing host key checking --------------------------- - -Ansible enables host key checking by default. Checking host keys guards against server spoofing and man-in-the-middle attacks, but it does require some maintenance. - -If a host is reinstalled and has a different key in 'known_hosts', this will result in an error message until corrected. If a new host is not in 'known_hosts' your control node may prompt for confirmation of the key, which results in an interactive experience if using Ansible, from say, cron. You might not want this. - -If you understand the implications and wish to disable this behavior, you can do so by editing ``/etc/ansible/ansible.cfg`` or ``~/.ansible.cfg``: - -.. code-block:: text - - [defaults] - host_key_checking = False - -Alternatively this can be set by the :envvar:`ANSIBLE_HOST_KEY_CHECKING` environment variable: - -.. code-block:: bash - - $ export ANSIBLE_HOST_KEY_CHECKING=False - -Also note that host key checking in paramiko mode is reasonably slow, therefore switching to 'ssh' is also recommended when using this feature. - -Other connection methods ------------------------- - -Ansible can use a variety of connection methods beyond SSH. You can select any connection plugin, including managing things locally and managing chroot, lxc, and jail containers. -A mode called 'ansible-pull' can also invert the system and have systems 'phone home' via scheduled git checkouts to pull configuration directives from a central repository. diff --git a/docs/docsite/rst/inventory_guide/index.rst b/docs/docsite/rst/inventory_guide/index.rst deleted file mode 100644 index 7b984eb1d74..00000000000 --- a/docs/docsite/rst/inventory_guide/index.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _inventory_guide_index: - -############################ -Building Ansible inventories -############################ - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the guide to building Ansible inventories. -An inventory is a list of managed nodes, or hosts, that Ansible deploys and configures. -This guide introduces you to inventories and covers the following topics: - -* Creating inventories to track list of servers and devices that you want to automate. -* Using dynamic inventories to track cloud services with servers and devices that are constantly starting and stopping. -* Using patterns to automate specific sub-sets of an inventory. -* Expanding and refining the connection methods Ansible uses for your inventory. - -.. toctree:: - :maxdepth: 2 - - intro_inventory - intro_dynamic_inventory - intro_patterns - connection_details \ No newline at end of file diff --git a/docs/docsite/rst/inventory_guide/intro_dynamic_inventory.rst b/docs/docsite/rst/inventory_guide/intro_dynamic_inventory.rst deleted file mode 100644 index e0d9c204f75..00000000000 --- a/docs/docsite/rst/inventory_guide/intro_dynamic_inventory.rst +++ /dev/null @@ -1,260 +0,0 @@ -.. _intro_dynamic_inventory: -.. _dynamic_inventory: - -****************************** -Working with dynamic inventory -****************************** - -.. contents:: - :local: - -If your Ansible inventory fluctuates over time, with hosts spinning up and shutting down in response to business demands, the static inventory solutions described in :ref:`inventory` will not serve your needs. -You may need to track hosts from multiple sources: cloud providers, LDAP, `Cobbler `_, and/or enterprise CMDB systems. - -Ansible integrates all of these options through a dynamic external inventory system. -Ansible supports two ways to connect with external inventory: :ref:`inventory_plugins` and `inventory scripts`. - -Inventory plugins take advantage of the most recent updates to the Ansible core code. -We recommend plugins over scripts for dynamic inventory. -You can :ref:`write your own plugin ` to connect to additional dynamic inventory sources. - -You can still use inventory scripts if you choose. -When we implemented inventory plugins, we ensured backwards compatibility through the script inventory plugin. -The examples below illustrate how to use inventory scripts. - -If you prefer a GUI for handling dynamic inventory, the inventory database on AWX or :ref:`ansible_platform` syncs with all your dynamic inventory sources, provides web and REST access to the results, and offers a graphical inventory editor. -With a database record of all of your hosts, you can correlate past event history and see which hosts have had failures on their last playbook runs. - -.. _cobbler_example: - -Inventory script example: Cobbler -================================= - -Ansible integrates seamlessly with `Cobbler `_, a Linux installation server originally written by Michael DeHaan and now led by James Cammarata, who works for Ansible. - -While primarily used to kickoff OS installations and manage DHCP and DNS, Cobbler has a generic -layer that can represent data for multiple configuration management systems (even at the same time) and serve as a 'lightweight CMDB'. - -To tie your Ansible inventory to Cobbler, copy `this script `_ to ``/etc/ansible`` and ``chmod +x`` the file. Run ``cobblerd`` any time you use Ansible and use the ``-i`` command line option (for example, ``-i /etc/ansible/cobbler.py``) to communicate with Cobbler using Cobbler's XMLRPC API. - -Add a ``cobbler.ini`` file in ``/etc/ansible`` so Ansible knows where the Cobbler server is and some cache improvements can be used. For example: - -.. code-block:: text - - [cobbler] - - # Set Cobbler's hostname or IP address - host = http://127.0.0.1/cobbler_api - - # API calls to Cobbler can be slow. For this reason, we cache the results of an API - # call. Set this to the path you want cache files to be written to. Two files - # will be written to this directory: - # - ansible-cobbler.cache - # - ansible-cobbler.index - - cache_path = /tmp - - # The number of seconds a cache file is considered valid. After this many - # seconds, a new API call will be made, and the cache file will be updated. - - cache_max_age = 900 - - -First test the script by running ``/etc/ansible/cobbler.py`` directly. You should see some JSON data output, but it may not have anything in it just yet. - -Let's explore what this does. In Cobbler, assume a scenario somewhat like the following: - -.. code-block:: bash - - cobbler profile add --name=webserver --distro=CentOS6-x86_64 - cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3" - cobbler system edit --name=foo --dns-name="foo.example.com" --mgmt-classes="atlanta" --ksmeta="c=4" - cobbler system edit --name=bar --dns-name="bar.example.com" --mgmt-classes="atlanta" --ksmeta="c=5" - -In the example above, the system 'foo.example.com' is addressable by ansible directly, but is also addressable when using the group names 'webserver' or 'atlanta'. Since Ansible uses SSH, it contacts system foo over 'foo.example.com', only, never just 'foo'. Similarly, if you tried "ansible foo", it would not find the system... but "ansible 'foo*'" would do, because the system DNS name starts with 'foo'. - -The script provides more than host and group info. In addition, as a bonus, when the 'setup' module is run (which happens automatically when using playbooks), the variables 'a', 'b', and 'c' will all be auto-populated in the templates: - -.. code-block:: text - - # file: /srv/motd.j2 - Welcome, I am templated with a value of a={{ a }}, b={{ b }}, and c={{ c }} - -Which could be executed just like this: - -.. code-block:: bash - - ansible webserver -m setup - ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd" - -.. note:: - The name 'webserver' came from Cobbler, as did the variables for - the config file. You can still pass in your own variables like - normal in Ansible, but variables from the external inventory script - will override any that have the same name. - -So, with the template above (``motd.j2``), this results in the following data being written to ``/etc/motd`` for system 'foo': - -.. code-block:: text - - Welcome, I am templated with a value of a=2, b=3, and c=4 - -And on system 'bar' (bar.example.com): - -.. code-block:: text - - Welcome, I am templated with a value of a=2, b=3, and c=5 - -And technically, though there is no major good reason to do it, this also works: - -.. code-block:: bash - - ansible webserver -m ansible.builtin.shell -a "echo {{ a }}" - -So, in other words, you can use those variables in arguments/actions as well. - -.. _openstack_example: - -Inventory script example: OpenStack -=================================== - -If you use an OpenStack-based cloud, instead of manually maintaining your own inventory file, you can use the ``openstack_inventory.py`` dynamic inventory to pull information about your compute instances directly from OpenStack. - -You can download the latest version of the OpenStack inventory script `here `_. - -You can use the inventory script explicitly (by passing the `-i openstack_inventory.py` argument to Ansible) or implicitly (by placing the script at `/etc/ansible/hosts`). - -Explicit use of OpenStack inventory script ------------------------------------------- - -Download the latest version of the OpenStack dynamic inventory script and make it executable. - -.. code-block:: bash - - wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py - chmod +x openstack_inventory.py - -.. note:: - Do not name it `openstack.py`. This name will conflict with imports from openstacksdk. - -Source an OpenStack RC file: - -.. code-block:: bash - - source openstack.rc - -.. note:: - - An OpenStack RC file contains the environment variables required by the client tools to establish a connection with the cloud provider, such as the authentication URL, user name, password and region name. For more information on how to download, create or source an OpenStack RC file, please refer to `Set environment variables using the OpenStack RC file `_. - -You can confirm the file has been successfully sourced by running a simple command, such as `nova list` and ensuring it returns no errors. - -.. note:: - - The OpenStack command line clients are required to run the `nova list` command. For more information on how to install them, please refer to `Install the OpenStack command-line clients `_. - -You can test the OpenStack dynamic inventory script manually to confirm it is working as expected: - -.. code-block:: bash - - ./openstack_inventory.py --list - -After a few moments you should see some JSON output with information about your compute instances. - -Once you confirm the dynamic inventory script is working as expected, you can tell Ansible to use the `openstack_inventory.py` script as an inventory file, as illustrated below: - -.. code-block:: bash - - ansible -i openstack_inventory.py all -m ansible.builtin.ping - -Implicit use of OpenStack inventory script ------------------------------------------- - -Download the latest version of the OpenStack dynamic inventory script, make it executable and copy it to `/etc/ansible/hosts`: - -.. code-block:: bash - - wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py - chmod +x openstack_inventory.py - sudo cp openstack_inventory.py /etc/ansible/hosts - -Download the sample configuration file, modify it to suit your needs and copy it to `/etc/ansible/openstack.yml`: - -.. code-block:: bash - - wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack.yml - vi openstack.yml - sudo cp openstack.yml /etc/ansible/ - -You can test the OpenStack dynamic inventory script manually to confirm it is working as expected: - -.. code-block:: bash - - /etc/ansible/hosts --list - -After a few moments you should see some JSON output with information about your compute instances. - -Refreshing the cache --------------------- - -Note that the OpenStack dynamic inventory script will cache results to avoid repeated API calls. To explicitly clear the cache, you can run the openstack_inventory.py (or hosts) script with the ``--refresh`` parameter: - -.. code-block:: bash - - ./openstack_inventory.py --refresh --list - -.. _other_inventory_scripts: - -Other inventory scripts -======================= - -In Ansible 2.10 and later, inventory scripts moved to their associated collections. Many are now in the `ansible-community/contrib-scripts repository `_. We recommend you use :ref:`inventory_plugins` instead. - -.. _using_multiple_sources: - -Using inventory directories and multiple inventory sources -========================================================== - -If the location given to ``-i`` in Ansible is a directory (or as so configured in ``ansible.cfg``), Ansible can use multiple inventory sources -at the same time. When doing so, it is possible to mix both dynamic and statically managed inventory sources in the same ansible run. Instant -hybrid cloud! - -In an inventory directory, executable files are treated as dynamic inventory sources and most other files as static sources. Files which end with any of the following are ignored: - -.. code-block:: text - - ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo - -You can replace this list with your own selection by configuring an ``inventory_ignore_extensions`` list in ``ansible.cfg``, or setting the :envvar:`ANSIBLE_INVENTORY_IGNORE` environment variable. The value in either case must be a comma-separated list of patterns, as shown above. - -Any ``group_vars`` and ``host_vars`` subdirectories in an inventory directory are interpreted as expected, making inventory directories a powerful way to organize different sets of configurations. See :ref:`using_multiple_inventory_sources` for more information. - -.. _static_groups_of_dynamic: - -Static groups of dynamic groups -=============================== - -When defining groups of groups in the static inventory file, the child groups -must also be defined in the static inventory file, otherwise ansible returns an -error. If you want to define a static group of dynamic child groups, define -the dynamic groups as empty in the static inventory file. For example: - -.. code-block:: text - - [tag_Name_staging_foo] - - [tag_Name_staging_bar] - - [staging:children] - tag_Name_staging_foo - tag_Name_staging_bar - - -.. seealso:: - - :ref:`intro_inventory` - All about static inventory files - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory_guide/intro_inventory.rst b/docs/docsite/rst/inventory_guide/intro_inventory.rst deleted file mode 100644 index 3fd6782dbde..00000000000 --- a/docs/docsite/rst/inventory_guide/intro_inventory.rst +++ /dev/null @@ -1,841 +0,0 @@ -.. _intro_inventory: -.. _inventory: - -*************************** -How to build your inventory -*************************** - -Ansible automates tasks on managed nodes or "hosts" in your infrastructure, using a list or group of lists known as inventory. You can pass host names at the command line, but most Ansible users create inventory files. Your inventory defines the managed nodes you automate, with groups so you can run automation tasks on multiple hosts at the same time. -Once your inventory is defined, you use :ref:`patterns ` to select the hosts or groups you want Ansible to run against. - -The simplest inventory is a single file with a list of hosts and groups. The default location for this file is ``/etc/ansible/hosts``. -You can specify a different inventory file at the command line using the ``-i `` option or in configuration using ``inventory``. - -Ansible :ref:`inventory_plugins` support a range of formats and sources to make your inventory flexible and customizable. As your inventory expands, you may need more than a single file to organize your hosts and groups. Here are three options beyond the ``/etc/ansible/hosts`` file: -- You can create a directory with multiple inventory files. See :ref:`inventory_directory`. These can use different formats (YAML, ini, and so on). -- You can pull inventory dynamically. For example, you can use a dynamic inventory plugin to list resources in one or more cloud providers. See :ref:`intro_dynamic_inventory`. -- You can use multiple sources for inventory, including both dynamic inventory and static files. See :ref:`using_multiple_inventory_sources`. - -.. contents:: - :local: - -.. _inventoryformat: - -Inventory basics: formats, hosts, and groups -============================================ - -You can create your inventory file in one of many formats, depending on the inventory plugins you have. -The most common formats are INI and YAML. A basic INI ``/etc/ansible/hosts`` might look like this: - -.. code-block:: text - - mail.example.com - - [webservers] - foo.example.com - bar.example.com - - [dbservers] - one.example.com - two.example.com - three.example.com - -The headings in brackets are group names, which are used in classifying hosts -and deciding what hosts you are controlling at what times and for what purpose. -Group names should follow the same guidelines as :ref:`valid_variable_names`. - -Here's that same basic inventory file in YAML format: - -.. code-block:: yaml - - all: - hosts: - mail.example.com: - children: - webservers: - hosts: - foo.example.com: - bar.example.com: - dbservers: - hosts: - one.example.com: - two.example.com: - three.example.com: - -.. _default_groups: - -Default groups --------------- - -Even if you do not define any groups in your inventory file, Ansible creates two default groups: ``all`` and ``ungrouped``. The ``all`` group contains every host. -The ``ungrouped`` group contains all hosts that don't have another group aside from ``all``. -Every host will always belong to at least 2 groups (``all`` and ``ungrouped`` or ``all`` and some other group). For example, in the basic inventory above, the host ``mail.example.com`` belongs to the ``all`` group and the ``ungrouped`` group; the host ``two.example.com`` belongs to the ``all`` group and the ``dbservers`` group. Though ``all`` and ``ungrouped`` are always present, they can be implicit and not appear in group listings like ``group_names``. - -.. _host_multiple_groups: - -Hosts in multiple groups ------------------------- - -You can (and probably will) put each host in more than one group. For example a production webserver in a datacenter in Atlanta might be included in groups called ``[prod]`` and ``[atlanta]`` and ``[webservers]``. You can create groups that track: - -* What - An application, stack or microservice (for example, database servers, web servers, and so on). -* Where - A datacenter or region, to talk to local DNS, storage, and so on (for example, east, west). -* When - The development stage, to avoid testing on production resources (for example, prod, test). - -Extending the previous YAML inventory to include what, when, and where would look like this: - -.. code-block:: yaml - - all: - hosts: - mail.example.com: - children: - webservers: - hosts: - foo.example.com: - bar.example.com: - dbservers: - hosts: - one.example.com: - two.example.com: - three.example.com: - east: - hosts: - foo.example.com: - one.example.com: - two.example.com: - west: - hosts: - bar.example.com: - three.example.com: - prod: - hosts: - foo.example.com: - one.example.com: - two.example.com: - test: - hosts: - bar.example.com: - three.example.com: - -You can see that ``one.example.com`` exists in the ``dbservers``, ``east``, and ``prod`` groups. - -.. _child_groups: - -Grouping groups: parent/child group relationships -------------------------------------------------- - -You can create parent/child relationships among groups. Parent groups are also known as nested groups or groups of groups. For example, if all your production hosts are already in groups such as ``atlanta_prod`` and ``denver_prod``, you can create a ``production`` group that includes those smaller groups. This approach reduces maintenance because you can add or remove hosts from the parent group by editing the child groups. - -To create parent/child relationships for groups: - -* in INI format, use the ``:children`` suffix -* in YAML format, use the ``children:`` entry - -Here is the same inventory as shown above, simplified with parent groups for the ``prod`` and ``test`` groups. The two inventory files give you the same results: - -.. code-block:: yaml - - all: - hosts: - mail.example.com: - children: - webservers: - hosts: - foo.example.com: - bar.example.com: - dbservers: - hosts: - one.example.com: - two.example.com: - three.example.com: - east: - hosts: - foo.example.com: - one.example.com: - two.example.com: - west: - hosts: - bar.example.com: - three.example.com: - prod: - children: - east: - test: - children: - west: - -Child groups have a couple of properties to note: - -* Any host that is member of a child group is automatically a member of the parent group. -* Groups can have multiple parents and children, but not circular relationships. -* Hosts can also be in multiple groups, but there will only be **one** instance of a host at runtime. Ansible merges the data from the multiple groups. - -Adding ranges of hosts ----------------------- - -If you have a lot of hosts with a similar pattern, you can add them as a range rather than listing each hostname separately: - -In INI: - -.. code-block:: text - - [webservers] - www[01:50].example.com - -In YAML: - -.. code-block:: yaml - - ... - webservers: - hosts: - www[01:50].example.com: - -You can specify a stride (increments between sequence numbers) when defining a numeric range of hosts: - -In INI: - -.. code-block:: text - - [webservers] - www[01:50:2].example.com - -In YAML: - -.. code-block:: yaml - - ... - webservers: - hosts: - www[01:50:2].example.com: - -The example above would make the subdomains www01, www03, www05, ..., www49 match, but not www00, www02, www50 and so on, because the stride (increment) is 2 units each step. - -For numeric patterns, leading zeros can be included or removed, as desired. Ranges are inclusive. You can also define alphabetic ranges: - -.. code-block:: text - - [databases] - db-[a:f].example.com - -.. _using_multiple_inventory_sources: - -Passing multiple inventory sources -================================== - -You can target multiple inventory sources (directories, dynamic inventory scripts -or files supported by inventory plugins) at the same time by giving multiple inventory parameters from the command -line or by configuring :envvar:`ANSIBLE_INVENTORY`. This can be useful when you want to target normally -separate environments, like staging and production, at the same time for a specific action. - -To target two inventory sources from the command line: - -.. code-block:: bash - - ansible-playbook get_logs.yml -i staging -i production - -.. _inventory_directory: - -Organizing inventory in a directory -=================================== - -You can consolidate multiple inventory sources in a single directory. The simplest version of this is a directory with multiple files instead of a single inventory file. A single file gets difficult to maintain when it gets too long. If you have multiple teams and multiple automation projects, having one inventory file per team or project lets everyone easily find the hosts and groups that matter to them. - -You can also combine multiple inventory source types in an inventory directory. This can be useful for combining static and dynamic hosts and managing them as one inventory. -The following inventory directory combines an inventory plugin source, a dynamic inventory script, -and a file with static hosts: - -.. code-block:: text - - inventory/ - openstack.yml # configure inventory plugin to get hosts from OpenStack cloud - dynamic-inventory.py # add additional hosts with dynamic inventory script - on-prem # add static hosts and groups - parent-groups # add static hosts and groups - -You can target this inventory directory as follows: - -.. code-block:: bash - - ansible-playbook example.yml -i inventory - -You can also configure the inventory directory in your ``ansible.cfg`` file. See :ref:`intro_configuration` for more details. - -Managing inventory load order ------------------------------ - -Ansible loads inventory sources in ASCII order according to the filenames. If you define parent groups in one file or directory and child groups in other files or directories, the files that define the child groups must be loaded first. If the parent groups are loaded first, you will see the error ``Unable to parse /path/to/source_of_parent_groups as an inventory source``. - -For example, if you have a file called ``groups-of-groups`` that defines a ``production`` group with child groups defined in a file called ``on-prem``, Ansible cannot parse the ``production`` group. To avoid this problem, you can control the load order by adding prefixes to the files: - -.. code-block:: text - - inventory/ - 01-openstack.yml # configure inventory plugin to get hosts from OpenStack cloud - 02-dynamic-inventory.py # add additional hosts with dynamic inventory script - 03-on-prem # add static hosts and groups - 04-groups-of-groups # add parent groups - -You can find examples of how to organize your inventories and group your hosts in :ref:`inventory_setup_examples`. - -.. _variables_in_inventory: - -Adding variables to inventory -============================= - -You can store variable values that relate to a specific host or group in inventory. To start with, you may add variables directly to the hosts and groups in your main inventory file. - -We document adding variables in the main inventory file for simplicity. However, storing variables in separate host and group variable files is a more robust approach to describing your system policy. Setting variables in the main inventory file is only a shorthand. See :ref:`splitting_out_vars` for guidelines on storing variable values in individual files in the 'host_vars' directory. See :ref:`splitting_out_vars` for details. - -.. _host_variables: - -Assigning a variable to one machine: host variables -=================================================== - -You can easily assign a variable to a single host, then use it later in playbooks. You can do this directly in your inventory file. - -In INI: - -.. code-block:: text - - [atlanta] - host1 http_port=80 maxRequestsPerChild=808 - host2 http_port=303 maxRequestsPerChild=909 - -In YAML: - -.. code-block:: yaml - - atlanta: - hosts: - host1: - http_port: 80 - maxRequestsPerChild: 808 - host2: - http_port: 303 - maxRequestsPerChild: 909 - -Unique values like non-standard SSH ports work well as host variables. You can add them to your Ansible inventory by adding the port number after the hostname with a colon: - -.. code-block:: text - - badwolf.example.com:5309 - -Connection variables also work well as host variables: - -.. code-block:: text - - [targets] - - localhost ansible_connection=local - other1.example.com ansible_connection=ssh ansible_user=myuser - other2.example.com ansible_connection=ssh ansible_user=myotheruser - -.. note:: If you list non-standard SSH ports in your SSH config file, the ``openssh`` connection will find and use them, but the ``paramiko`` connection will not. - -.. _inventory_aliases: - -Inventory aliases ------------------ - -You can also define aliases in your inventory using host variables: - -In INI: - -.. code-block:: text - - jumper ansible_port=5555 ansible_host=192.0.2.50 - -In YAML: - -.. code-block:: yaml - - ... - hosts: - jumper: - ansible_port: 5555 - ansible_host: 192.0.2.50 - -In this example, running Ansible against the host alias "jumper" will connect to 192.0.2.50 on port 5555. See :ref:`behavioral inventory parameters ` to further customize the connection to hosts. - -Defining variables in INI format -================================ - -Values passed in the INI format using the ``key=value`` syntax are interpreted differently depending on where they are declared: - -* When declared inline with the host, INI values are interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple ``key=value`` parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator. Values that contain whitespace can be quoted (single or double). See the `Python shlex parsing rules`_ for details. - -* When declared in a ``:vars`` section, INI values are interpreted as strings. For example ``var=FALSE`` would create a string equal to 'FALSE'. Unlike host lines, ``:vars`` sections accept only a single entry per line, so everything after the ``=`` must be the value for the entry. - -If a variable value set in an INI inventory must be a certain type (for example, a string or a boolean value), always specify the type with a filter in your task. Do not rely on types set in INI inventories when consuming variables. - -Consider using YAML format for inventory sources to avoid confusion on the actual type of a variable. The YAML inventory plugin processes variable values consistently and correctly. - -.. _Python shlex parsing rules: https://docs.python.org/3/library/shlex.html#parsing-rules - -.. _group_variables: - -Assigning a variable to many machines: group variables -====================================================== - -If all hosts in a group share a variable value, you can apply that variable to an entire group at once. - -In INI: - -.. code-block:: text - - [atlanta] - host1 - host2 - - [atlanta:vars] - ntp_server=ntp.atlanta.example.com - proxy=proxy.atlanta.example.com - -In YAML: - -.. code-block:: yaml - - atlanta: - hosts: - host1: - host2: - vars: - ntp_server: ntp.atlanta.example.com - proxy: proxy.atlanta.example.com - -Group variables are a convenient way to apply variables to multiple hosts at once. Before executing, however, Ansible always flattens variables, including inventory variables, to the host level. If a host is a member of multiple groups, Ansible reads variable values from all of those groups. If you assign different values to the same variable in different groups, Ansible chooses which value to use based on internal :ref:`rules for merging `. - -.. _subgroups: - -Inheriting variable values: group variables for groups of groups ----------------------------------------------------------------- - -You can apply variables to parent groups (nested groups or groups of groups) as well as to child groups. The syntax is the same: ``:vars`` for INI format and ``vars:`` for YAML format: - -In INI: - -.. code-block:: text - - [atlanta] - host1 - host2 - - [raleigh] - host2 - host3 - - [southeast:children] - atlanta - raleigh - - [southeast:vars] - some_server=foo.southeast.example.com - halon_system_timeout=30 - self_destruct_countdown=60 - escape_pods=2 - - [usa:children] - southeast - northeast - southwest - northwest - -In YAML: - -.. code-block:: yaml - - all: - children: - usa: - children: - southeast: - children: - atlanta: - hosts: - host1: - host2: - raleigh: - hosts: - host2: - host3: - vars: - some_server: foo.southeast.example.com - halon_system_timeout: 30 - self_destruct_countdown: 60 - escape_pods: 2 - northeast: - northwest: - southwest: - -A child group's variables will have higher precedence (override) a parent group's variables. - -.. _splitting_out_vars: - -Organizing host and group variables -=================================== - -Although you can store variables in the main inventory file, storing separate host and group variables files may help you organize your variable values more easily. You can also use lists and hash data in host and group variables files, which you cannot do in your main inventory file. - -Host and group variable files must use YAML syntax. Valid file extensions include '.yml', '.yaml', '.json', or no file extension. See :ref:`yaml_syntax` if you are new to YAML. - -Ansible loads host and group variable files by searching paths relative to the inventory file or the playbook file. If your inventory file at ``/etc/ansible/hosts`` contains a host named 'foosball' that belongs to two groups, 'raleigh' and 'webservers', that host will use variables in YAML files at the following locations: - -.. code-block:: bash - - /etc/ansible/group_vars/raleigh # can optionally end in '.yml', '.yaml', or '.json' - /etc/ansible/group_vars/webservers - /etc/ansible/host_vars/foosball - -For example, if you group hosts in your inventory by datacenter, and each datacenter uses its own NTP server and database server, you can create a file called ``/etc/ansible/group_vars/raleigh`` to store the variables for the ``raleigh`` group: - -.. code-block:: yaml - - --- - ntp_server: acme.example.org - database_server: storage.example.org - -You can also create *directories* named after your groups or hosts. Ansible will read all the files in these directories in lexicographical order. An example with the 'raleigh' group: - -.. code-block:: bash - - /etc/ansible/group_vars/raleigh/db_settings - /etc/ansible/group_vars/raleigh/cluster_settings - -All hosts in the 'raleigh' group will have the variables defined in these files -available to them. This can be very useful to keep your variables organized when a single -file gets too big, or when you want to use :ref:`Ansible Vault` on some group variables. - -For ``ansible-playbook`` you can also add ``group_vars/`` and ``host_vars/`` directories to your playbook directory. Other Ansible commands (for example, ``ansible``, ``ansible-console``, and so on) will only look for ``group_vars/`` and ``host_vars/`` in the inventory directory. If you want other commands to load group and host variables from a playbook directory, you must provide the ``--playbook-dir`` option on the command line. -If you load inventory files from both the playbook directory and the inventory directory, variables in the playbook directory will override variables set in the inventory directory. - -Keeping your inventory file and variables in a git repo (or other version control) -is an excellent way to track changes to your inventory and host variables. - -.. _how_we_merge: - -How variables are merged -======================== - -By default variables are merged/flattened to the specific host before a play is run. This keeps Ansible focused on the Host and Task, so groups don't really survive outside of inventory and host matching. By default, Ansible overwrites variables including the ones defined for a group and/or host (see :ref:`DEFAULT_HASH_BEHAVIOUR`). The order/precedence is (from lowest to highest): - -- all group (because it is the 'parent' of all other groups) -- parent group -- child group -- host - -By default Ansible merges groups at the same parent/child level in ASCII order, and variables from the last group loaded overwrite variables from the previous groups. For example, an a_group will be merged with b_group and b_group vars that match will overwrite the ones in a_group. - -You can change this behavior by setting the group variable ``ansible_group_priority`` to change the merge order for groups of the same level (after the parent/child order is resolved). The larger the number, the later it will be merged, giving it higher priority. This variable defaults to ``1`` if not set. For example: - -.. code-block:: yaml - - a_group: - vars: - testvar: a - ansible_group_priority: 10 - b_group: - vars: - testvar: b - -In this example, if both groups have the same priority, the result would normally have been ``testvar == b``, but since we are giving the ``a_group`` a higher priority the result will be ``testvar == a``. - -.. note:: ``ansible_group_priority`` can only be set in the inventory source and not in group_vars/, as the variable is used in the loading of group_vars. - -Managing inventory variable load order --------------------------------------- - -When using multiple inventory sources, keep in mind that any variable conflicts are resolved according -to the rules described in :ref:`how_we_merge` and :ref:`ansible_variable_precedence`. You can control the merging order of variables in inventory sources to get the variable value you need. - -When you pass multiple inventory sources at the command line, Ansible merges variables in the order you pass those parameters. If ``[all:vars]`` in staging inventory defines ``myvar = 1`` and production inventory defines ``myvar = 2``, then: - -* Pass ``-i staging -i production`` to run the playbook with ``myvar = 2``. -* Pass ``-i production -i staging`` to run the playbook with ``myvar = 1``. - -When you put multiple inventory sources in a directory, Ansible merges them in ASCII order according to the filenames. You can control the load order by adding prefixes to the files: - -.. code-block:: text - - inventory/ - 01-openstack.yml # configure inventory plugin to get hosts from Openstack cloud - 02-dynamic-inventory.py # add additional hosts with dynamic inventory script - 03-static-inventory # add static hosts - group_vars/ - all.yml # assign variables to all hosts - -If ``01-openstack.yml`` defines ``myvar = 1`` for the group ``all``, ``02-dynamic-inventory.py`` defines ``myvar = 2``, -and ``03-static-inventory`` defines ``myvar = 3``, the playbook will be run with ``myvar = 3``. - -For more details on inventory plugins and dynamic inventory scripts see :ref:`inventory_plugins` and :ref:`intro_dynamic_inventory`. - -.. _behavioral_parameters: - -Connecting to hosts: behavioral inventory parameters -==================================================== - -As described above, setting the following variables control how Ansible interacts with remote hosts. - -Host connection: - -.. include:: shared_snippets/SSH_password_prompt.txt - -ansible_connection - Connection type to the host. This can be the name of any of ansible's connection plugins. SSH protocol types are ``smart``, ``ssh`` or ``paramiko``. The default is smart. Non-SSH based types are described in the next section. - -General for all connections: - -ansible_host - The name of the host to connect to, if different from the alias you wish to give to it. -ansible_port - The connection port number, if not the default (22 for ssh) -ansible_user - The user name to use when connecting to the host -ansible_password - The password to use to authenticate to the host (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`) - - -Specific to the SSH connection: - -ansible_ssh_private_key_file - Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent. -ansible_ssh_common_args - This setting is always appended to the default command line for :command:`sftp`, :command:`scp`, - and :command:`ssh`. Useful to configure a ``ProxyCommand`` for a certain host (or - group). -ansible_sftp_extra_args - This setting is always appended to the default :command:`sftp` command line. -ansible_scp_extra_args - This setting is always appended to the default :command:`scp` command line. -ansible_ssh_extra_args - This setting is always appended to the default :command:`ssh` command line. -ansible_ssh_pipelining - Determines whether or not to use SSH pipelining. This can override the ``pipelining`` setting in :file:`ansible.cfg`. -ansible_ssh_executable (added in version 2.2) - This setting overrides the default behavior to use the system :command:`ssh`. This can override the ``ssh_executable`` setting in :file:`ansible.cfg`. - - -Privilege escalation (see :ref:`Ansible Privilege Escalation` for further details): - -ansible_become - Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation -ansible_become_method - Allows to set privilege escalation method -ansible_become_user - Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation -ansible_become_password - Equivalent to ``ansible_sudo_password`` or ``ansible_su_password``, allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`) -ansible_become_exe - Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected -ansible_become_flags - Equivalent to ``ansible_sudo_flags`` or ``ansible_su_flags``, allows you to set the flags passed to the selected escalation method. This can be also set globally in :file:`ansible.cfg` in the ``sudo_flags`` option - -Remote host environment parameters: - -.. _ansible_shell_type: - -ansible_shell_type - The shell type of the target system. You should not use this setting unless you have set the - :ref:`ansible_shell_executable` to a non-Bourne (sh) compatible shell. By default commands are - formatted using ``sh``-style syntax. Setting this to ``csh`` or ``fish`` will cause commands - executed on target systems to follow those shell's syntax instead. - -.. _ansible_python_interpreter: - -ansible_python_interpreter - The target host python path. This is useful for systems with more - than one Python or not located at :command:`/usr/bin/python` such as \*BSD, or where :command:`/usr/bin/python` - is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's - path to be set right and also assumes the :program:`python` executable is named python, where the executable might - be named something like :program:`python2.6`. - -ansible_*_interpreter - Works for anything such as ruby or perl and works just like :ref:`ansible_python_interpreter`. - This replaces shebang of modules which will run on that host. - -.. versionadded:: 2.1 - -.. _ansible_shell_executable: - -ansible_shell_executable - This sets the shell the ansible controller will use on the target machine, - overrides ``executable`` in :file:`ansible.cfg` which defaults to - :command:`/bin/sh`. You should really only change it if is not possible - to use :command:`/bin/sh` (in other words, if :command:`/bin/sh` is not installed on the target - machine or cannot be run from sudo.). - -Examples from an Ansible-INI host file: - -.. code-block:: text - - some_host ansible_port=2222 ansible_user=manager - aws_host ansible_ssh_private_key_file=/home/example/.ssh/aws.pem - freebsd_host ansible_python_interpreter=/usr/local/bin/python - ruby_module_host ansible_ruby_interpreter=/usr/bin/ruby.1.9.3 - -Non-SSH connection types ------------------------- - -As stated in the previous section, Ansible executes playbooks over SSH but it is not limited to this connection type. -With the host specific parameter ``ansible_connection=``, the connection type can be changed. -The following non-SSH based connectors are available: - -**local** - -This connector can be used to deploy the playbook to the control machine itself. - -**docker** - -This connector deploys the playbook directly into Docker containers using the local Docker client. The following parameters are processed by this connector: - -ansible_host - The name of the Docker container to connect to. -ansible_user - The user name to operate within the container. The user must exist inside the container. -ansible_become - If set to ``true`` the ``become_user`` will be used to operate within the container. -ansible_docker_extra_args - Could be a string with any additional arguments understood by Docker, which are not command specific. This parameter is mainly used to configure a remote Docker daemon to use. - -Here is an example of how to instantly deploy to created containers: - -.. code-block:: yaml - - - name: Create a jenkins container - community.general.docker_container: - docker_host: myserver.net:4243 - name: my_jenkins - image: jenkins - - - name: Add the container to inventory - ansible.builtin.add_host: - name: my_jenkins - ansible_connection: docker - ansible_docker_extra_args: "--tlsverify --tlscacert=/path/to/ca.pem --tlscert=/path/to/client-cert.pem --tlskey=/path/to/client-key.pem -H=tcp://myserver.net:4243" - ansible_user: jenkins - changed_when: false - - - name: Create a directory for ssh keys - delegate_to: my_jenkins - ansible.builtin.file: - path: "/var/jenkins_home/.ssh/jupiter" - state: directory - -For a full list with available plugins and examples, see :ref:`connection_plugin_list`. - -.. note:: If you're reading the docs from the beginning, this may be the first example you've seen of an Ansible playbook. This is not an inventory file. - Playbooks will be covered in great detail later in the docs. - -.. _inventory_setup_examples: - -Inventory setup examples -======================== - -See also :ref:`sample_setup`, which shows inventory along with playbooks and other Ansible artifacts. - -.. _inventory_setup-per_environment: - -Example: One inventory per environment --------------------------------------- - -If you need to manage multiple environments it's sometimes prudent to -have only hosts of a single environment defined per inventory. This -way, it is harder to, for instance, accidentally change the state of -nodes inside the "test" environment when you actually wanted to update -some "staging" servers. - -For the example mentioned above you could have an -:file:`inventory_test` file: - -.. code-block:: ini - - [dbservers] - db01.test.example.com - db02.test.example.com - - [appservers] - app01.test.example.com - app02.test.example.com - app03.test.example.com - -That file only includes hosts that are part of the "test" -environment. Define the "staging" machines in another file -called :file:`inventory_staging`: - -.. code-block:: ini - - [dbservers] - db01.staging.example.com - db02.staging.example.com - - [appservers] - app01.staging.example.com - app02.staging.example.com - app03.staging.example.com - -To apply a playbook called :file:`site.yml` -to all the app servers in the test environment, use the -following command: - -.. code-block:: bash - - ansible-playbook -i inventory_test -l appservers site.yml - -.. _inventory_setup-per_function: - -Example: Group by function --------------------------- - -In the previous section you already saw an example for using groups in -order to cluster hosts that have the same function. This allows you, -for instance, to define firewall rules inside a playbook or role -affecting only database servers: - -.. code-block:: yaml - - - hosts: dbservers - tasks: - - name: Allow access from 10.0.0.1 - ansible.builtin.iptables: - chain: INPUT - jump: ACCEPT - source: 10.0.0.1 - -.. _inventory_setup-per_location: - -Example: Group by location --------------------------- - -Other tasks might be focused on where a certain host is located. Let's -say that ``db01.test.example.com`` and ``app01.test.example.com`` are -located in DC1 while ``db02.test.example.com`` is in DC2: - -.. code-block:: ini - - [dc1] - db01.test.example.com - app01.test.example.com - - [dc2] - db02.test.example.com - -In practice, you might even end up mixing all these setups as you -might need to, on one day, update all nodes in a specific data center -while, on another day, update all the application servers no matter -their location. - -.. seealso:: - - :ref:`inventory_plugins` - Pulling inventory from dynamic or static sources - :ref:`intro_dynamic_inventory` - Pulling inventory from dynamic sources, such as cloud providers - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning Ansible's configuration, deployment, and orchestration language. - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory_guide/intro_patterns.rst b/docs/docsite/rst/inventory_guide/intro_patterns.rst deleted file mode 100644 index 446b7d4ca2f..00000000000 --- a/docs/docsite/rst/inventory_guide/intro_patterns.rst +++ /dev/null @@ -1,253 +0,0 @@ -.. _intro_patterns: - -Patterns: targeting hosts and groups -==================================== - -When you execute Ansible through an ad hoc command or by running a playbook, you must choose which managed nodes or groups you want to execute against. -Patterns let you run commands and playbooks against specific hosts and/or groups in your inventory. -An Ansible pattern can refer to a single host, an IP address, an inventory group, a set of groups, or all hosts in your inventory. -Patterns are highly flexible - you can exclude or require subsets of hosts, use wildcards or regular expressions, and more. -Ansible executes on all inventory hosts included in the pattern. - -.. contents:: - :local: - -Using patterns --------------- - -You use a pattern almost any time you execute an ad hoc command or a playbook. The pattern is the only element of an :ref:`ad hoc command` that has no flag. It is usually the second element: - -.. code-block:: bash - - ansible -m -a "" - -For example: - -.. code-block:: bash - - ansible webservers -m service -a "name=httpd state=restarted" - -In a playbook the pattern is the content of the ``hosts:`` line for each play: - -.. code-block:: yaml - - - name: - hosts: - -For example: - -.. code-block:: yaml - - - name: restart webservers - hosts: webservers - -Since you often want to run a command or playbook against multiple hosts at once, patterns often refer to inventory groups. Both the ad hoc command and the playbook above will execute against all machines in the ``webservers`` group. - -.. _common_patterns: - -Common patterns ---------------- - -This table lists common patterns for targeting inventory hosts and groups. - -.. table:: - :class: documentation-table - - ====================== ================================ =================================================== - Description Pattern(s) Targets - ====================== ================================ =================================================== - All hosts all (or \*) - - One host host1 - - Multiple hosts host1:host2 (or host1,host2) - - One group webservers - - Multiple groups webservers:dbservers all hosts in webservers plus all hosts in dbservers - - Excluding groups webservers:!atlanta all hosts in webservers except those in atlanta - - Intersection of groups webservers:&staging any hosts in webservers that are also in staging - ====================== ================================ =================================================== - -.. note:: You can use either a comma (``,``) or a colon (``:``) to separate a list of hosts. The comma is preferred when dealing with ranges and IPv6 addresses. - -Once you know the basic patterns, you can combine them. This example: - -.. code-block:: yaml - - webservers:dbservers:&staging:!phoenix - -targets all machines in the groups 'webservers' and 'dbservers' that are also in -the group 'staging', except any machines in the group 'phoenix'. - -You can use wildcard patterns with FQDNs or IP addresses, as long as the hosts are named in your inventory by FQDN or IP address: - -.. code-block:: yaml - - 192.0.* - *.example.com - *.com - -You can mix wildcard patterns and groups at the same time: - -.. code-block:: yaml - - one*.com:dbservers - -Limitations of patterns ------------------------ - -Patterns depend on inventory. If a host or group is not listed in your inventory, you cannot use a pattern to target it. If your pattern includes an IP address or hostname that does not appear in your inventory, you will see an error like this: - -.. code-block:: text - - [WARNING]: No inventory was parsed, only implicit localhost is available - [WARNING]: Could not match supplied host pattern, ignoring: *.not_in_inventory.com - -Your pattern must match your inventory syntax. If you define a host as an :ref:`alias`: - -.. code-block:: yaml - - atlanta: - host1: - http_port: 80 - maxRequestsPerChild: 808 - host: 127.0.0.2 - -you must use the alias in your pattern. In the example above, you must use ``host1`` in your pattern. If you use the IP address, you will once again get the error: - -.. code-block:: console - - [WARNING]: Could not match supplied host pattern, ignoring: 127.0.0.2 - -Pattern processing order ------------------------- - -The processing is a bit special and happens in the following order: - -1. ``:`` and ``,`` -2. ``&`` -3. ``!`` - -This positioning only accounts for processing order inside each operation: -``a:b:&c:!d:!e == &c:a:!d:b:!e == !d:a:!e:&c:b`` - -All of these result in the following: - -Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(d, e). - -Now ``a:b:!e:!d:&c`` is a slight change as the ``!e`` gets processed before the ``!d``, though this doesn't make much of a difference: - -Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(e, d). - -Advanced pattern options ------------------------- - -The common patterns described above will meet most of your needs, but Ansible offers several other ways to define the hosts and groups you want to target. - -Using variables in patterns -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can use variables to enable passing group specifiers via the ``-e`` argument to ansible-playbook: - -.. code-block:: bash - - webservers:!{{ excluded }}:&{{ required }} - -Using group position in patterns -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can define a host or subset of hosts by its position in a group. For example, given the following group: - -.. code-block:: ini - - [webservers] - cobweb - webbing - weber - -you can use subscripts to select individual hosts or ranges within the webservers group: - -.. code-block:: yaml - - webservers[0] # == cobweb - webservers[-1] # == weber - webservers[0:2] # == webservers[0],webservers[1] - # == cobweb,webbing - webservers[1:] # == webbing,weber - webservers[:3] # == cobweb,webbing,weber - -Using regexes in patterns -^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can specify a pattern as a regular expression by starting the pattern with ``~``: - -.. code-block:: yaml - - ~(web|db).*\.example\.com - -Patterns and ad-hoc commands ----------------------------- - -You can change the behavior of the patterns defined in ad-hoc commands using command-line options. -You can also limit the hosts you target on a particular run with the ``--limit`` flag. - -* Limit to one host - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit "host1" - -* Limit to multiple hosts - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit "host1,host2" - -* Negated limit. Note that single quotes MUST be used to prevent bash interpolation. - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit 'all:!host1' - -* Limit to host group - -.. code-block:: bash - - $ ansible all -m [module] -a "[module options]" --limit 'group1' - -Patterns and ansible-playbook flags ------------------------------------ - -You can change the behavior of the patterns defined in playbooks using command-line options. For example, you can run a playbook that defines ``hosts: all`` on a single host by specifying ``-i 127.0.0.2,`` (note the trailing comma). This works even if the host you target is not defined in your inventory, but this method will NOT read your inventory for variables tied to this host and any variables required by the playbook will need to be specified manually at the command line. You can also limit the hosts you target on a particular run with the ``--limit`` flag, which will reference your inventory: - -.. code-block:: bash - - ansible-playbook site.yml --limit datacenter2 - -Finally, you can use ``--limit`` to read the list of hosts from a file by prefixing the file name with ``@``: - -.. code-block:: bash - - ansible-playbook site.yml --limit @retry_hosts.txt - -If :ref:`RETRY_FILES_ENABLED` is set to ``True``, a ``.retry`` file will be created after the ``ansible-playbook`` run containing a list of failed hosts from all plays. This file is overwritten each time ``ansible-playbook`` finishes running. - -.. code-block:: bash - - ansible-playbook site.yml --limit @site.retry - -To apply your knowledge of patterns with Ansible commands and playbooks, read :ref:`intro_adhoc` and :ref:`playbooks_intro`. - -.. seealso:: - - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning the Ansible configuration management language - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/inventory_guide/shared_snippets/SSH_password_prompt.txt b/docs/docsite/rst/inventory_guide/shared_snippets/SSH_password_prompt.txt deleted file mode 100644 index dc61ab38b70..00000000000 --- a/docs/docsite/rst/inventory_guide/shared_snippets/SSH_password_prompt.txt +++ /dev/null @@ -1,2 +0,0 @@ -.. note:: - Ansible does not expose a channel to allow communication between the user and the ssh process to accept a password manually to decrypt an ssh key when using the ssh connection plugin (which is the default). The use of ``ssh-agent`` is highly recommended. diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/404.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/404.po deleted file mode 100644 index 5d8e8e8e402..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/404.po +++ /dev/null @@ -1,34 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-11-03 09:23+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/404.rst:5 -msgid "Oops!" -msgstr "Oops!" - -#: ../../rst/404.rst:7 -msgid "The version of the Ansible documentation you were looking at doesn't contain that page." -msgstr "参照している Ansible ドキュメントのバージョンには、そのページが含まれていません。" - -msgid "Cowsay 404" -msgstr "Cowsay 404" - -#: ../../rst/404.rst:12 -msgid "Use the back button to return to the version you were browsing, or use the navigation at left to explore our latest release. Once you're on a non-404 page, you can use the version-changer to select a version." -msgstr "戻るボタンを使用して閲覧していたバージョンに戻るか、左側のナビゲーションを使用して最新リリースを参照してください。404 以外のページでは、バージョン番号変更メニューを使用してバージョンを選択できます。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/api.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/api.po deleted file mode 100644 index 52c296ab6f8..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/api.po +++ /dev/null @@ -1,94 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-02-23 10:50+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/api/index.rst:5 -msgid "Ansible API Documentation" -msgstr "Ansible API のドキュメント" - -#: ../../rst/api/index.rst:7 -msgid "The Ansible API is under construction. These stub references for attributes, classes, functions, methods, and modules will be documented in future. The :ref:`module utilities ` included in ``ansible.module_utils.basic`` and ``AnsibleModule`` are documented under Reference & Appendices." -msgstr "Ansible API を構築中です。属性、クラス、関数、メソッド、およびモジュールのスタブ参照の説明は、今後追加されます。``ansible.module_utils.basic`` および ``AnsibleModule`` に含まれる「:ref:`モジュールユーティリティー `」、「参照および付録」に記載されています。" - -#: ../../rst/api/index.rst:14 -msgid "Attributes" -msgstr "属性" - -#: ../../rst/api/index.rst:18 -msgid "The parameters accepted by the module." -msgstr "モジュールで受け入れられるパラメーターです。" - -#: ../../rst/api/index.rst:24 -msgid "Deprecated in favor of ansibleModule._selinux_special_fs." -msgstr "ansibleModule._selinux_special_fs が導入されたため、非推奨となりました。" - -#: ../../rst/api/index.rst:36 -msgid "(formerly ansible.module_utils.basic.SELINUX_SPECIAL_FS)" -msgstr "(以前は ansible.module_utils.basic.SELINUX_SPECIAL_FS)" - -#: ../../rst/api/index.rst:50 -msgid "Classes" -msgstr "クラス" - -#: ../../rst/api/index.rst:55 -msgid "The basic utilities for AnsibleModule." -msgstr "AnsibleModule の基本的なユーティリティーです。" - -#: ../../rst/api/index.rst:59 -msgid "The main class for an Ansible module." -msgstr "Ansible モジュールのメインクラスです。" - -#: ../../rst/api/index.rst:63 -msgid "Functions" -msgstr "関数" - -#: ../../rst/api/index.rst:67 -msgid "Load parameters." -msgstr "パラメーターを読み込みます。" - -#: ../../rst/api/index.rst:71 -msgid "Methods" -msgstr "メソッド" - -#: ../../rst/api/index.rst:75 -msgid "Logs the output of Ansible." -msgstr "Ansible の出力をログに記録します。" - -#: ../../rst/api/index.rst:79 -msgid "Debugs Ansible." -msgstr "Ansible をデバッグします。" - -#: ../../rst/api/index.rst:83 -msgid "Retrieves the path for executables." -msgstr "実行可能ファイルのパスを取得します。" - -#: ../../rst/api/index.rst:87 -msgid "Runs a command within an Ansible module." -msgstr "Ansible モジュール内でコマンドを実行します。" - -#: ../../rst/api/index.rst:91 -msgid "Exits and returns a failure." -msgstr "終了して、失敗を返します。" - -#: ../../rst/api/index.rst:95 -msgid "Exits and returns output." -msgstr "終了して、出力を返します。" - -#: ../../rst/api/index.rst:99 -msgid "Modules" -msgstr "モジュール" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/cli.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/cli.po deleted file mode 100644 index 2c85c53a2b9..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/cli.po +++ /dev/null @@ -1,1246 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/cli/ansible.rst:7 -msgid "ansible" -msgstr "ansible" - -#: ../../rst/cli/ansible.rst:10 -msgid ":strong:`Define and run a single task 'playbook' against a set of hosts`" -msgstr ":strong:`一連のホストに対して単一のタスク「Playbook」を定義して実行`" - -#: ../../rst/cli/ansible-config.rst:21 ../../rst/cli/ansible-console.rst:21 -#: ../../rst/cli/ansible-doc.rst:21 ../../rst/cli/ansible-galaxy.rst:21 -#: ../../rst/cli/ansible-inventory.rst:21 ../../rst/cli/ansible-playbook.rst:21 -#: ../../rst/cli/ansible-pull.rst:21 ../../rst/cli/ansible-vault.rst:21 -#: ../../rst/cli/ansible.rst:21 -msgid "Synopsis" -msgstr "概要" - -#: ../../rst/cli/ansible-config.rst:30 ../../rst/cli/ansible-console.rst:38 -#: ../../rst/cli/ansible-doc.rst:33 ../../rst/cli/ansible-galaxy.rst:30 -#: ../../rst/cli/ansible-inventory.rst:34 ../../rst/cli/ansible-playbook.rst:39 -#: ../../rst/cli/ansible-pull.rst:38 ../../rst/cli/ansible-vault.rst:30 -#: ../../rst/cli/ansible.rst:38 -msgid "Description" -msgstr "説明" - -#: ../../rst/cli/ansible.rst:41 -msgid "is an extra-simple tool/framework/API for doing 'remote things'. this command allows you to define and run a single task 'playbook' against a set of hosts" -msgstr "「リモートのこと」を行う非常に単純なツール/フレームワーク/API です。このコマンドでは、ホスト 1 台に対して単一タスク「Playbook」を定義および実行できます" - -#: ../../rst/cli/ansible-config.rst:37 ../../rst/cli/ansible-console.rst:66 -#: ../../rst/cli/ansible-doc.rst:43 ../../rst/cli/ansible-galaxy.rst:40 -#: ../../rst/cli/ansible-inventory.rst:41 ../../rst/cli/ansible-playbook.rst:47 -#: ../../rst/cli/ansible-pull.rst:56 ../../rst/cli/ansible-vault.rst:44 -#: ../../rst/cli/ansible.rst:46 -msgid "Common Options" -msgstr "共通オプション" - -#: ../../rst/cli/ansible-console.rst:73 ../../rst/cli/ansible-inventory.rst:48 -#: ../../rst/cli/ansible-playbook.rst:54 ../../rst/cli/ansible-pull.rst:68 -#: ../../rst/cli/ansible-vault.rst:87 ../../rst/cli/ansible-vault.rst:121 -#: ../../rst/cli/ansible-vault.rst:155 ../../rst/cli/ansible-vault.rst:189 -#: ../../rst/cli/ansible-vault.rst:219 ../../rst/cli/ansible-vault.rst:257 -#: ../../rst/cli/ansible-vault.rst:311 ../../rst/cli/ansible.rst:53 -msgid "ask for vault password" -msgstr "Vault のパスワード入力を尋ねます。" - -#: ../../rst/cli/ansible-console.rst:78 ../../rst/cli/ansible-playbook.rst:59 -#: ../../rst/cli/ansible.rst:58 -msgid "privilege escalation method to use (default=sudo), use `ansible-doc -t become -l` to list valid choices." -msgstr "使用する特権昇格方法 (デフォルトは sudo)。有効な選択を一覧表示するには `ansible-doc -t become -l` を使用します。" - -#: ../../rst/cli/ansible-console.rst:83 ../../rst/cli/ansible-playbook.rst:64 -#: ../../rst/cli/ansible-pull.rst:73 ../../rst/cli/ansible.rst:63 -msgid "Become password file" -msgstr "become パスワードファイル" - -#: ../../rst/cli/ansible-console.rst:88 ../../rst/cli/ansible-playbook.rst:69 -#: ../../rst/cli/ansible.rst:68 -msgid "run operations as this user (default=root)" -msgstr "このユーザーとして操作を実行します (デフォルトは root)。" - -#: ../../rst/cli/ansible-console.rst:93 ../../rst/cli/ansible-playbook.rst:74 -#: ../../rst/cli/ansible-pull.rst:88 ../../rst/cli/ansible.rst:73 -msgid "Connection password file" -msgstr "接続のパスワードファイル" - -#: ../../rst/cli/ansible-console.rst:98 ../../rst/cli/ansible-playbook.rst:89 -#: ../../rst/cli/ansible-pull.rst:103 ../../rst/cli/ansible.rst:78 -msgid "outputs a list of matching hosts; does not execute anything else" -msgstr "一致するホストの一覧を出力します。他には何も実行しません。" - -#: ../../rst/cli/ansible-console.rst:103 ../../rst/cli/ansible-doc.rst:60 -#: ../../rst/cli/ansible-inventory.rst:83 ../../rst/cli/ansible.rst:83 -msgid "Since this tool does not use playbooks, use this as a substitute playbook directory. This sets the relative path for many features including roles/ group_vars/ etc." -msgstr "このツールは Playbook を使用しないため、代替の Playbook ディレクトリーとして使用します。これにより、roles/ group_vars/ などの多くの機能の相対パスが設定されます。" - -#: ../../rst/cli/ansible-console.rst:108 ../../rst/cli/ansible-playbook.rst:104 -#: ../../rst/cli/ansible-pull.rst:108 ../../rst/cli/ansible.rst:88 -msgid "use this file to authenticate the connection" -msgstr "このファイルを使用して接続を認証します。" - -#: ../../rst/cli/ansible-console.rst:113 ../../rst/cli/ansible-playbook.rst:109 -#: ../../rst/cli/ansible-pull.rst:118 ../../rst/cli/ansible.rst:93 -msgid "specify extra arguments to pass to scp only (e.g. -l)" -msgstr "scp のみに渡す追加の引数を指定します (例: -l)。" - -#: ../../rst/cli/ansible-console.rst:118 ../../rst/cli/ansible-playbook.rst:114 -#: ../../rst/cli/ansible-pull.rst:123 ../../rst/cli/ansible.rst:98 -msgid "specify extra arguments to pass to sftp only (e.g. -f, -l)" -msgstr "sftp のみに渡す追加の引数を指定します (例: -f、-l)。" - -#: ../../rst/cli/ansible-console.rst:123 ../../rst/cli/ansible-playbook.rst:124 -#: ../../rst/cli/ansible-pull.rst:133 ../../rst/cli/ansible.rst:103 -msgid "specify common arguments to pass to sftp/scp/ssh (e.g. ProxyCommand)" -msgstr "sftp/scp/ssh に渡す一般的な引数を指定します (例: ProxyCommand)。" - -#: ../../rst/cli/ansible-console.rst:128 ../../rst/cli/ansible-playbook.rst:129 -#: ../../rst/cli/ansible-pull.rst:138 ../../rst/cli/ansible.rst:108 -msgid "specify extra arguments to pass to ssh only (e.g. -R)" -msgstr "ssh のみに渡す追加の引数を指定します (例: -R)。" - -#: ../../rst/cli/ansible-console.rst:138 ../../rst/cli/ansible-playbook.rst:144 -#: ../../rst/cli/ansible.rst:113 -msgid "perform a syntax check on the playbook, but do not execute it" -msgstr "Playbook で構文チェックを実行しますが、Playbook は実行しません。" - -#: ../../rst/cli/ansible-console.rst:143 ../../rst/cli/ansible.rst:118 -msgid "set task timeout limit in seconds, must be positive integer." -msgstr "タスクのタイムアウト制限を秒単位で設定します。正の整数である必要があります。" - -#: ../../rst/cli/ansible-console.rst:148 ../../rst/cli/ansible-inventory.rst:98 -#: ../../rst/cli/ansible-playbook.rst:149 ../../rst/cli/ansible-pull.rst:148 -#: ../../rst/cli/ansible-vault.rst:95 ../../rst/cli/ansible-vault.rst:129 -#: ../../rst/cli/ansible-vault.rst:163 ../../rst/cli/ansible-vault.rst:193 -#: ../../rst/cli/ansible-vault.rst:231 ../../rst/cli/ansible-vault.rst:277 -#: ../../rst/cli/ansible-vault.rst:327 ../../rst/cli/ansible.rst:123 -msgid "the vault identity to use" -msgstr "使用する Vault アイデンティティー" - -#: ../../rst/cli/ansible-console.rst:153 -#: ../../rst/cli/ansible-inventory.rst:103 -#: ../../rst/cli/ansible-playbook.rst:154 ../../rst/cli/ansible-pull.rst:153 -#: ../../rst/cli/ansible-vault.rst:99 ../../rst/cli/ansible-vault.rst:133 -#: ../../rst/cli/ansible-vault.rst:167 ../../rst/cli/ansible-vault.rst:197 -#: ../../rst/cli/ansible-vault.rst:235 ../../rst/cli/ansible-vault.rst:281 -#: ../../rst/cli/ansible-vault.rst:331 ../../rst/cli/ansible.rst:128 -msgid "vault password file" -msgstr "Vault パスワードファイル" - -#: ../../rst/cli/ansible-config.rst:44 ../../rst/cli/ansible-console.rst:158 -#: ../../rst/cli/ansible-doc.rst:65 ../../rst/cli/ansible-galaxy.rst:47 -#: ../../rst/cli/ansible-inventory.rst:108 -#: ../../rst/cli/ansible-playbook.rst:159 ../../rst/cli/ansible-pull.rst:163 -#: ../../rst/cli/ansible-vault.rst:51 ../../rst/cli/ansible.rst:133 -msgid "show program's version number, config file location, configured module search path, module location, executable location and exit" -msgstr "プログラムバージョン番号、設定ファイルの場所、設定したモジュール検索パス、モジュールの場所、実行可能な場所、および終了を表示します。" - -#: ../../rst/cli/ansible.rst:138 -msgid "run asynchronously, failing after X seconds (default=N/A)" -msgstr "非同期的に実行し、X 秒後に失敗します (デフォルトは N/A)。" - -#: ../../rst/cli/ansible-console.rst:163 ../../rst/cli/ansible-playbook.rst:164 -#: ../../rst/cli/ansible-pull.rst:78 ../../rst/cli/ansible.rst:143 -msgid "don't make any changes; instead, try to predict some of the changes that may occur" -msgstr "変更を加えないでください。代わりに、発生する可能性のある変更のいくつかを予測してみてください。" - -#: ../../rst/cli/ansible-console.rst:168 ../../rst/cli/ansible-playbook.rst:169 -#: ../../rst/cli/ansible-pull.rst:93 ../../rst/cli/ansible.rst:148 -msgid "when changing (small) files and templates, show the differences in those files; works great with --check" -msgstr "(小規模な) ファイルおよびテンプレートの変更時に、これらのファイルの相違点を表示します。--check と適切に連携します。" - -#: ../../rst/cli/ansible-console.rst:173 ../../rst/cli/ansible-playbook.rst:174 -#: ../../rst/cli/ansible-pull.rst:173 ../../rst/cli/ansible.rst:153 -msgid "ask for privilege escalation password" -msgstr "権限昇格のパスワードを要求します。" - -#: ../../rst/cli/ansible-console.rst:178 ../../rst/cli/ansible-doc.rst:75 -#: ../../rst/cli/ansible-playbook.rst:179 ../../rst/cli/ansible-pull.rst:178 -#: ../../rst/cli/ansible.rst:158 -msgid "prepend colon-separated path(s) to module library (default={{ ANSIBLE_HOME ~ \"/plugins/modules:/usr/share/ansible/plugins/modules\" }})" -msgstr "モジュールライブラリーへのコロン区切りパス (デフォルトは {{ ANSIBLE_HOME ~ \"/plugins/modules:/usr/share/ansible/plugins/modules\" }}) を先頭に追加します。" - -#: ../../rst/cli/ansible.rst:163 -msgid "set the poll interval if using -B (default=15)" -msgstr "-B (デフォルトは 15) を使用する場合はポーリング間隔を設定します。" - -#: ../../rst/cli/ansible-console.rst:183 ../../rst/cli/ansible-playbook.rst:184 -#: ../../rst/cli/ansible-pull.rst:183 ../../rst/cli/ansible.rst:168 -msgid "override the connection timeout in seconds (default=10)" -msgstr "接続タイムアウトを秒単位で上書きします (デフォルトは 10)。" - -#: ../../rst/cli/ansible.rst:173 -msgid "The action's options in space separated k=v format: -a 'opt1=val1 opt2=val2' or a json string: -a '{\"opt1\": \"val1\", \"opt2\": \"val2\"}'" -msgstr "スペースで区切られた k=v 形式のアクションのオプション: -a 'opt1=val1 opt2=val2' または json 文字列: -a '{\"opt1\": \"val1\", \"opt2\": \"val2\"}'" - -#: ../../rst/cli/ansible-console.rst:188 ../../rst/cli/ansible-playbook.rst:189 -#: ../../rst/cli/ansible.rst:178 -msgid "run operations with become (does not imply password prompting)" -msgstr "become で操作の実行 (パスワード入力を意味するものではありません)" - -#: ../../rst/cli/ansible-console.rst:193 ../../rst/cli/ansible-playbook.rst:194 -#: ../../rst/cli/ansible-pull.rst:193 ../../rst/cli/ansible.rst:183 -msgid "connection type to use (default=smart)" -msgstr "使用する接続タイプ (デフォルトは smart)" - -#: ../../rst/cli/ansible-console.rst:198 -#: ../../rst/cli/ansible-inventory.rst:113 -#: ../../rst/cli/ansible-playbook.rst:199 ../../rst/cli/ansible-pull.rst:203 -#: ../../rst/cli/ansible.rst:188 -msgid "set additional variables as key=value or YAML/JSON, if filename prepend with @" -msgstr "ファイル名の前に @ を付ける場合は、追加の変数を key=value または YAML/JSON に設定します。" - -#: ../../rst/cli/ansible-console.rst:203 ../../rst/cli/ansible-playbook.rst:204 -#: ../../rst/cli/ansible.rst:193 -msgid "specify number of parallel processes to use (default=5)" -msgstr "使用する並列プロセス数を指定します (デフォルトは 5)。" - -#: ../../rst/cli/ansible-config.rst:49 ../../rst/cli/ansible-console.rst:208 -#: ../../rst/cli/ansible-doc.rst:85 ../../rst/cli/ansible-galaxy.rst:52 -#: ../../rst/cli/ansible-inventory.rst:118 -#: ../../rst/cli/ansible-playbook.rst:209 ../../rst/cli/ansible-pull.rst:213 -#: ../../rst/cli/ansible-vault.rst:56 ../../rst/cli/ansible.rst:198 -msgid "show this help message and exit" -msgstr "ヘルプメッセージを表示して終了します。" - -#: ../../rst/cli/ansible-console.rst:213 -#: ../../rst/cli/ansible-inventory.rst:123 -#: ../../rst/cli/ansible-playbook.rst:214 ../../rst/cli/ansible-pull.rst:218 -#: ../../rst/cli/ansible.rst:203 -msgid "specify inventory host path or comma separated host list. --inventory-file is deprecated" -msgstr "インベントリーホストパスまたはコンマ区切りホスト一覧を指定します。--inventory-file は非推奨になりました。" - -#: ../../rst/cli/ansible-console.rst:218 ../../rst/cli/ansible-playbook.rst:219 -#: ../../rst/cli/ansible-pull.rst:223 ../../rst/cli/ansible.rst:208 -msgid "ask for connection password" -msgstr "接続のパスワードを要求します。" - -#: ../../rst/cli/ansible-console.rst:223 ../../rst/cli/ansible-playbook.rst:224 -#: ../../rst/cli/ansible-pull.rst:228 ../../rst/cli/ansible.rst:213 -msgid "further limit selected hosts to an additional pattern" -msgstr "選択したホストを追加パターンにさらに制限します。" - -#: ../../rst/cli/ansible.rst:218 -msgid "Name of the action to execute (default=command)" -msgstr "実行する動作の名前 (default=command)" - -#: ../../rst/cli/ansible.rst:223 -msgid "condense output" -msgstr "出力を要約します。" - -#: ../../rst/cli/ansible.rst:228 -msgid "log output to this directory" -msgstr "このディレクトリーにログを記録します。" - -#: ../../rst/cli/ansible-console.rst:228 ../../rst/cli/ansible-playbook.rst:234 -#: ../../rst/cli/ansible-pull.rst:253 ../../rst/cli/ansible.rst:233 -msgid "connect as this user (default=None)" -msgstr "このユーザーとして接続します (デフォルトは None)。" - -#: ../../rst/cli/ansible-config.rst:54 ../../rst/cli/ansible-console.rst:233 -#: ../../rst/cli/ansible-doc.rst:115 ../../rst/cli/ansible-galaxy.rst:57 -#: ../../rst/cli/ansible-inventory.rst:133 -#: ../../rst/cli/ansible-playbook.rst:239 ../../rst/cli/ansible-pull.rst:258 -#: ../../rst/cli/ansible-vault.rst:61 ../../rst/cli/ansible.rst:238 -msgid "Causes Ansible to print more debug messages. Adding multiple -v will increase the verbosity, the builtin plugins currently evaluate up to -vvvvvv. A reasonable level to start is -vvv, connection debugging might require -vvvv." -msgstr "Ansible がより多くのデバッグメッセージを出力する原因になります。複数の -v を追加すると詳細度が増し、現在の組み込みプラグインは -vvvvvv まで評価します。開始するのに適切なレベルは -vvv です。接続のデバッグには、-vvvv が必要になる場合があります。" - -#: ../../rst/cli/ansible-config.rst:193 ../../rst/cli/ansible-console.rst:242 -#: ../../rst/cli/ansible-doc.rst:124 ../../rst/cli/ansible-galaxy.rst:894 -#: ../../rst/cli/ansible-inventory.rst:147 -#: ../../rst/cli/ansible-playbook.rst:248 ../../rst/cli/ansible-pull.rst:267 -#: ../../rst/cli/ansible-vault.rst:342 ../../rst/cli/ansible.rst:247 -msgid "Environment" -msgstr "環境" - -#: ../../rst/cli/ansible-config.rst:195 ../../rst/cli/ansible-console.rst:244 -#: ../../rst/cli/ansible-doc.rst:126 ../../rst/cli/ansible-galaxy.rst:896 -#: ../../rst/cli/ansible-inventory.rst:149 -#: ../../rst/cli/ansible-playbook.rst:250 ../../rst/cli/ansible-pull.rst:269 -#: ../../rst/cli/ansible-vault.rst:344 ../../rst/cli/ansible.rst:249 -msgid "The following environment variables may be specified." -msgstr "以下の環境変数を指定できます。" - -#: ../../rst/cli/ansible-config.rst:199 ../../rst/cli/ansible-console.rst:248 -#: ../../rst/cli/ansible-doc.rst:130 ../../rst/cli/ansible-galaxy.rst:900 -#: ../../rst/cli/ansible-inventory.rst:153 -#: ../../rst/cli/ansible-playbook.rst:254 ../../rst/cli/ansible-pull.rst:273 -#: ../../rst/cli/ansible-vault.rst:348 ../../rst/cli/ansible.rst:253 -msgid ":envvar:`ANSIBLE_CONFIG` -- Override the default ansible config file" -msgstr ":envvar:`ANSIBLE_CONFIG` -- デフォルトの Ansible 設定ファイルを上書きします。" - -#: ../../rst/cli/ansible-config.rst:201 ../../rst/cli/ansible-console.rst:250 -#: ../../rst/cli/ansible-doc.rst:132 ../../rst/cli/ansible-galaxy.rst:902 -#: ../../rst/cli/ansible-inventory.rst:155 -#: ../../rst/cli/ansible-playbook.rst:256 ../../rst/cli/ansible-pull.rst:275 -#: ../../rst/cli/ansible-vault.rst:350 ../../rst/cli/ansible.rst:255 -msgid "Many more are available for most options in ansible.cfg" -msgstr "ansible.cfg のほとんどのオプションで、さらに多くのものが利用できます。" - -#: ../../rst/cli/ansible-config.rst:205 ../../rst/cli/ansible-console.rst:254 -#: ../../rst/cli/ansible-doc.rst:136 ../../rst/cli/ansible-galaxy.rst:906 -#: ../../rst/cli/ansible-inventory.rst:159 -#: ../../rst/cli/ansible-playbook.rst:260 ../../rst/cli/ansible-pull.rst:279 -#: ../../rst/cli/ansible-vault.rst:354 ../../rst/cli/ansible.rst:259 -msgid "Files" -msgstr "ファイル" - -#: ../../rst/cli/ansible-config.rst:208 ../../rst/cli/ansible-console.rst:257 -#: ../../rst/cli/ansible-doc.rst:139 ../../rst/cli/ansible-galaxy.rst:909 -#: ../../rst/cli/ansible-inventory.rst:162 -#: ../../rst/cli/ansible-playbook.rst:263 ../../rst/cli/ansible-pull.rst:282 -#: ../../rst/cli/ansible-vault.rst:357 ../../rst/cli/ansible.rst:262 -msgid ":file:`/etc/ansible/ansible.cfg` -- Config file, used if present" -msgstr ":file:`/etc/ansible/ansible.cfg` -- 存在する場合は、使用される設定ファイル。" - -#: ../../rst/cli/ansible-config.rst:210 ../../rst/cli/ansible-console.rst:259 -#: ../../rst/cli/ansible-doc.rst:141 ../../rst/cli/ansible-galaxy.rst:911 -#: ../../rst/cli/ansible-inventory.rst:164 -#: ../../rst/cli/ansible-playbook.rst:265 ../../rst/cli/ansible-pull.rst:284 -#: ../../rst/cli/ansible-vault.rst:359 ../../rst/cli/ansible.rst:264 -msgid ":file:`~/.ansible.cfg` -- User config file, overrides the default config if present" -msgstr ":file:`~/.ansible.cfg` -- 存在する場合は、デフォルト設定を上書きするユーザー設定ファイル。" - -#: ../../rst/cli/ansible-config.rst:213 ../../rst/cli/ansible-console.rst:262 -#: ../../rst/cli/ansible-doc.rst:144 ../../rst/cli/ansible-galaxy.rst:914 -#: ../../rst/cli/ansible-inventory.rst:167 -#: ../../rst/cli/ansible-playbook.rst:268 ../../rst/cli/ansible-pull.rst:287 -#: ../../rst/cli/ansible-vault.rst:362 ../../rst/cli/ansible.rst:267 -msgid "Author" -msgstr "作成者" - -#: ../../rst/cli/ansible-config.rst:215 ../../rst/cli/ansible-console.rst:264 -#: ../../rst/cli/ansible-doc.rst:146 ../../rst/cli/ansible-galaxy.rst:916 -#: ../../rst/cli/ansible-inventory.rst:169 -#: ../../rst/cli/ansible-playbook.rst:270 ../../rst/cli/ansible-pull.rst:289 -#: ../../rst/cli/ansible-vault.rst:364 ../../rst/cli/ansible.rst:269 -msgid "Ansible was originally written by Michael DeHaan." -msgstr "Ansible は当初、Michael DeHaan によって記述されました。" - -#: ../../rst/cli/ansible-config.rst:217 ../../rst/cli/ansible-console.rst:266 -#: ../../rst/cli/ansible-doc.rst:148 ../../rst/cli/ansible-galaxy.rst:918 -#: ../../rst/cli/ansible-inventory.rst:171 -#: ../../rst/cli/ansible-playbook.rst:272 ../../rst/cli/ansible-pull.rst:291 -#: ../../rst/cli/ansible-vault.rst:366 ../../rst/cli/ansible.rst:271 -msgid "See the `AUTHORS` file for a complete list of contributors." -msgstr "貢献者の完全な一覧は、`AUTHORS` ファイルを参照してください。" - -#: ../../rst/cli/ansible-config.rst:221 ../../rst/cli/ansible-console.rst:270 -#: ../../rst/cli/ansible-doc.rst:152 ../../rst/cli/ansible-galaxy.rst:922 -#: ../../rst/cli/ansible-inventory.rst:175 -#: ../../rst/cli/ansible-playbook.rst:276 ../../rst/cli/ansible-pull.rst:295 -#: ../../rst/cli/ansible-vault.rst:370 ../../rst/cli/ansible.rst:275 -msgid "License" -msgstr "ライセンス" - -#: ../../rst/cli/ansible-config.rst:223 ../../rst/cli/ansible-console.rst:272 -#: ../../rst/cli/ansible-doc.rst:154 ../../rst/cli/ansible-galaxy.rst:924 -#: ../../rst/cli/ansible-inventory.rst:177 -#: ../../rst/cli/ansible-playbook.rst:278 ../../rst/cli/ansible-pull.rst:297 -#: ../../rst/cli/ansible-vault.rst:372 ../../rst/cli/ansible.rst:277 -msgid "Ansible is released under the terms of the GPLv3+ License." -msgstr "Ansible は、GPLv3 以降のライセンスの対象範囲でリリースされています。" - -#: ../../rst/cli/ansible-config.rst:226 ../../rst/cli/ansible-console.rst:275 -#: ../../rst/cli/ansible-doc.rst:157 ../../rst/cli/ansible-galaxy.rst:927 -#: ../../rst/cli/ansible-inventory.rst:180 -#: ../../rst/cli/ansible-playbook.rst:281 ../../rst/cli/ansible-pull.rst:300 -#: ../../rst/cli/ansible-vault.rst:375 ../../rst/cli/ansible.rst:280 -msgid "See also" -msgstr "参照情報" - -#: ../../rst/cli/ansible-config.rst:228 ../../rst/cli/ansible-console.rst:277 -#: ../../rst/cli/ansible-doc.rst:159 ../../rst/cli/ansible-galaxy.rst:929 -#: ../../rst/cli/ansible-inventory.rst:182 -#: ../../rst/cli/ansible-playbook.rst:283 ../../rst/cli/ansible-pull.rst:302 -#: ../../rst/cli/ansible-vault.rst:377 ../../rst/cli/ansible.rst:282 -msgid ":manpage:`ansible(1)`, :manpage:`ansible-config(1)`, :manpage:`ansible-console(1)`, :manpage:`ansible-doc(1)`, :manpage:`ansible-galaxy(1)`, :manpage:`ansible-inventory(1)`, :manpage:`ansible-playbook(1)`, :manpage:`ansible-pull(1)`, :manpage:`ansible-vault(1)`," -msgstr ":manpage:`ansible(1)`、 :manpage:`ansible-config(1)`、 :manpage:`ansible-console(1)`、 :manpage:`ansible-doc(1)`、 :manpage:`ansible-galaxy(1)`、 :manpage:`ansible-inventory(1)`、 :manpage:`ansible-playbook(1)`、 :manpage:`ansible-pull(1)`、 :manpage:`ansible-vault(1)`" - -#: ../../rst/cli/ansible-config.rst:7 -msgid "ansible-config" -msgstr "ansible-config" - -#: ../../rst/cli/ansible-config.rst:10 -msgid ":strong:`View ansible configuration.`" -msgstr ":strong:`ansible 設定を表示します。`" - -#: ../../rst/cli/ansible-config.rst:33 -msgid "Config command line class" -msgstr "設定コマンドラインクラス" - -#: ../../rst/cli/ansible-config.rst:62 ../../rst/cli/ansible-galaxy.rst:65 -#: ../../rst/cli/ansible-vault.rst:69 -msgid "Actions" -msgstr "アクション" - -#: ../../rst/cli/ansible-config.rst:70 -msgid "list" -msgstr "list" - -#: ../../rst/cli/ansible-config.rst:72 -msgid "list and output available configs" -msgstr "利用可能な設定の一覧表示と出力" - -#: ../../rst/cli/ansible-config.rst:80 -msgid "Output format for list" -msgstr "リストの出力形式" - -#: ../../rst/cli/ansible-config.rst:84 ../../rst/cli/ansible-config.rst:118 -#: ../../rst/cli/ansible-config.rst:144 ../../rst/cli/ansible-config.rst:178 -msgid "path to configuration file, defaults to first file found in precedence." -msgstr "設定ファイルへのパス (デフォルトは優先される最初のファイルです)。" - -#: ../../rst/cli/ansible-config.rst:88 ../../rst/cli/ansible-config.rst:122 -#: ../../rst/cli/ansible-config.rst:148 ../../rst/cli/ansible-config.rst:182 -msgid "Filter down to a specific plugin type." -msgstr "特定のプラグインタイプに絞り込みます。" - -#: ../../rst/cli/ansible-config.rst:100 -msgid "dump" -msgstr "dump" - -#: ../../rst/cli/ansible-config.rst:102 -msgid "Shows the current settings, merges ansible.cfg if specified" -msgstr "現在の設定を表示し、指定した場合は ansible.cfg をマージします。" - -#: ../../rst/cli/ansible-config.rst:110 -msgid "Output format for dump" -msgstr "dumb の出力形式" - -#: ../../rst/cli/ansible-config.rst:114 -msgid "Only show configurations that have changed from the default" -msgstr "デフォルトから変更した設定のみを表示します。" - -#: ../../rst/cli/ansible-config.rst:134 ../../rst/cli/ansible-vault.rst:179 -msgid "view" -msgstr "view" - -#: ../../rst/cli/ansible-config.rst:136 -msgid "Displays the current config file" -msgstr "現在の設定ファイルを表示します。" - -#: ../../rst/cli/ansible-config.rst:160 -msgid "init" -msgstr "init" - -#: ../../rst/cli/ansible-config.rst:170 -msgid "Prefixes all entries with a comment character to disable them" -msgstr "無効にするコメント文字を持つすべてのエントリーのプレフィックス" - -#: ../../rst/cli/ansible-config.rst:174 -msgid "Output format for init" -msgstr "init の出力形式" - -#: ../../rst/cli/ansible-console.rst:7 -msgid "ansible-console" -msgstr "ansible-console" - -#: ../../rst/cli/ansible-console.rst:10 -msgid ":strong:`REPL console for executing Ansible tasks.`" -msgstr ":strong:`Ansible タスクを実行する REPL コンソール`" - -#: ../../rst/cli/ansible-console.rst:41 -msgid "A REPL that allows for running ad-hoc tasks against a chosen inventory from a nice shell with built-in tab completion (based on dominis' ansible-shell)." -msgstr "(dominis の ansible-shell に基づく) 組み込みのタブ補完機能を備えた優れたシェルから選択したインベントリーに対して、アドホックタスクを実行できるようにする REPL。" - -#: ../../rst/cli/ansible-console.rst:45 -msgid "It supports several commands, and you can modify its configuration at runtime:" -msgstr "これは複数のコマンドをサポートし、起動時にその設定を変更できます。" - -#: ../../rst/cli/ansible-console.rst:48 -msgid "`cd [pattern]`: change host/group (you can use host patterns eg.: app*.dc*:!app01*)" -msgstr "`cd [pattern]`: ホスト/グループを変更する (app*.dc*:!app01* などのホストパターンを使用できます)" - -#: ../../rst/cli/ansible-console.rst:49 -msgid "`list`: list available hosts in the current path" -msgstr "`list`: 現在のパスで利用可能なホストを一覧表示する" - -#: ../../rst/cli/ansible-console.rst:50 -msgid "`list groups`: list groups included in the current path" -msgstr "`list groups`: 現在のパスに含まれるグループを一覧表示する" - -#: ../../rst/cli/ansible-console.rst:51 -msgid "`become`: toggle the become flag" -msgstr "`become`: become フラグを切り替える" - -#: ../../rst/cli/ansible-console.rst:52 -msgid "`!`: forces shell module instead of the ansible module (!yum update -y)" -msgstr "`!`: Ansible モジュールの代わりにシェルモジュールを強制的に実行する (!yum update -y)" - -#: ../../rst/cli/ansible-console.rst:53 -msgid "`verbosity [num]`: set the verbosity level" -msgstr "`verbosity [num]`: 詳細レベルを設定する" - -#: ../../rst/cli/ansible-console.rst:54 -msgid "`forks [num]`: set the number of forks" -msgstr "`forks [num]`: フォークの数を設定する" - -#: ../../rst/cli/ansible-console.rst:55 -msgid "`become_user [user]`: set the become_user" -msgstr "`become_user [user]`: become_user を設定する" - -#: ../../rst/cli/ansible-console.rst:56 -msgid "`remote_user [user]`: set the remote_user" -msgstr "`remote_user [user]`: remote_user を設定する" - -#: ../../rst/cli/ansible-console.rst:57 -msgid "`become_method [method]`: set the privilege escalation method" -msgstr "`become_method [method]`: 権限昇格方法を設定する" - -#: ../../rst/cli/ansible-console.rst:58 -msgid "`check [bool]`: toggle check mode" -msgstr "`check [bool]`: チェックモードを切り替える" - -#: ../../rst/cli/ansible-console.rst:59 -msgid "`diff [bool]`: toggle diff mode" -msgstr "`diff [bool]`: diff モードを切り替える" - -#: ../../rst/cli/ansible-console.rst:60 -msgid "`timeout [integer]`: set the timeout of tasks in seconds (0 to disable)" -msgstr "`timeout [integer]`: タスクのタイムアウトを秒単位で設定する (無効にするには 0)" - -#: ../../rst/cli/ansible-console.rst:61 -msgid "`help [command/module]`: display documentation for the command or module" -msgstr "`help [command/module]`: コマンドまたはモジュールのドキュメントを表示する" - -#: ../../rst/cli/ansible-console.rst:62 -msgid "`exit`: exit ansible-console" -msgstr "`exit`: ansible-console を終了する" - -#: ../../rst/cli/ansible-console.rst:133 ../../rst/cli/ansible-playbook.rst:139 -msgid "one-step-at-a-time: confirm each task before running" -msgstr "one-step-at-a-time: 実行前に各タスクを確認します。" - -#: ../../rst/cli/ansible-doc.rst:7 -msgid "ansible-doc" -msgstr "ansible-doc" - -#: ../../rst/cli/ansible-doc.rst:10 -msgid ":strong:`plugin documentation tool`" -msgstr ":strong:`プラグインドキュメントツール`" - -#: ../../rst/cli/ansible-doc.rst:36 -msgid "displays information on modules installed in Ansible libraries. It displays a terse listing of plugins and their short descriptions, provides a printout of their DOCUMENTATION strings, and it can create a short \"snippet\" which can be pasted into a playbook." -msgstr "Ansible ライブラリーにインストールされているモジュールに関する情報を表示します。プラグインとその簡単な説明を表示し、DOCUMENTATION 文字列を出力します。これにより、Playbook に簡単に張り付けることができる短い「スニペット」を作成できます。" - -#: ../../rst/cli/ansible-doc.rst:50 -msgid "**For internal use only** Dump json metadata for all entries, ignores other options." -msgstr "**内部使用のみ** すべてのエントリーで json メタデータをダンプし、他のオプション無視します。" - -#: ../../rst/cli/ansible-doc.rst:55 -msgid "**For internal use only** Only used for --metadata-dump. Do not fail on errors. Report the error message in the JSON instead." -msgstr "**内部使用のみ** --metadata-dump にのみ使用します。エラーで失敗しないようにしてください。代わりに JSON でエラーメッセージを報告します。" - -#: ../../rst/cli/ansible-doc.rst:70 -msgid "Show plugin names and their source files without summaries (implies --list). A supplied argument will be used for filtering, can be a namespace or full collection name." -msgstr "要約なしでプラグイン名およびソースファイルを表示します (implmaries --list)。指定した引数は、名前空間または完全なコレクション名になります。" - -#: ../../rst/cli/ansible-doc.rst:80 -msgid "Select the entry point for role(s)." -msgstr "ロールのエントリーポイントを選択します。" - -#: ../../rst/cli/ansible-doc.rst:90 -msgid "Change output into json format." -msgstr "出力を json 形式に変更します。" - -#: ../../rst/cli/ansible-doc.rst:95 -msgid "List available plugins. A supplied argument will be used for filtering, can be a namespace or full collection name." -msgstr "利用可能なプラグインを一覧表示します。指定された引数はフィルタリングに使用され、名前空間または完全コレクション名になります。" - -#: ../../rst/cli/ansible-doc.rst:100 -msgid "The path to the directory containing your roles." -msgstr "ロールを含むディレクトリーへのパス。" - -#: ../../rst/cli/ansible-doc.rst:105 -msgid "Show playbook snippet for these plugin types: inventory, lookup, module" -msgstr "次のプラグインタイプの Playbook スニペットを表示します（inventory、lookup、module）。" - -#: ../../rst/cli/ansible-doc.rst:110 -msgid "Choose which plugin type (defaults to \"module\"). Available plugin types are : ('become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', 'vars', 'module', 'strategy', 'test', 'filter', 'role', 'keyword')" -msgstr "プラグインの種類 (デフォルトは「module」) を選択します。利用可能なプラグインの種類は (「become」、「cache」、「callback」、「cliconf」、「connection」、「httpapi」、「inventory」、「lookup」、「netconf」、「shell」、「vars」、「module」、「strategy」、「test」、「filter」、「role」、「keyword」) です。" - -#: ../../rst/cli/ansible-galaxy.rst:7 -msgid "ansible-galaxy" -msgstr "ansible-galaxy" - -#: ../../rst/cli/ansible-galaxy.rst:10 -msgid ":strong:`Perform various Role and Collection related operations.`" -msgstr ":strong:`ロールおよびコレクションに関する様々な操作を実行します。`" - -#: ../../rst/cli/ansible-galaxy.rst:33 -msgid "Command to manage Ansible roles and collections." -msgstr "Ansible のロールとコレクションを管理するコマンド。" - -#: ../../rst/cli/ansible-galaxy.rst:35 -msgid "None of the CLI tools are designed to run concurrently with themselves. Use an external scheduler and/or locking to ensure there are no clashing operations." -msgstr "CLI ツールは、そのツール自体と同時に実行するようには設計されていません。外部スケジューラーやロックを使用して、操作が競合しないようにします。" - -#: ../../rst/cli/ansible-galaxy.rst:73 -msgid "collection" -msgstr "コレクション" - -#: ../../rst/cli/ansible-galaxy.rst:75 -msgid "Perform the action on an Ansible Galaxy collection. Must be combined with a further action like init/install as listed below." -msgstr "Ansible Galaxy コレクションでアクションを実行します。以下で示すように、init/install などの追加アクションと組み合わせる必要があります。" - -#: ../../rst/cli/ansible-galaxy.rst:87 -msgid "collection download" -msgstr "collection download" - -#: ../../rst/cli/ansible-galaxy.rst:97 ../../rst/cli/ansible-galaxy.rst:284 -msgid "Clear the existing server response cache." -msgstr "既存のサーバーの応答キャッシュを消去します。" - -#: ../../rst/cli/ansible-galaxy.rst:101 ../../rst/cli/ansible-galaxy.rst:304 -msgid "Do not use the server response cache." -msgstr "サーバーの応答キャッシュを使用しないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:105 ../../rst/cli/ansible-galaxy.rst:312 -msgid "Include pre-release versions. Semantic versioning pre-releases are ignored by default" -msgstr "リリース前のバージョンを含めます。セマンティックバージョニングのプレリリースはデフォルトで無視されます。" - -#: ../../rst/cli/ansible-galaxy.rst:109 ../../rst/cli/ansible-galaxy.rst:163 -#: ../../rst/cli/ansible-galaxy.rst:206 ../../rst/cli/ansible-galaxy.rst:251 -#: ../../rst/cli/ansible-galaxy.rst:324 ../../rst/cli/ansible-galaxy.rst:385 -#: ../../rst/cli/ansible-galaxy.rst:442 ../../rst/cli/ansible-galaxy.rst:515 -#: ../../rst/cli/ansible-galaxy.rst:556 ../../rst/cli/ansible-galaxy.rst:593 -#: ../../rst/cli/ansible-galaxy.rst:626 ../../rst/cli/ansible-galaxy.rst:675 -#: ../../rst/cli/ansible-galaxy.rst:724 ../../rst/cli/ansible-galaxy.rst:765 -#: ../../rst/cli/ansible-galaxy.rst:806 ../../rst/cli/ansible-galaxy.rst:847 -msgid "The time to wait for operations against the galaxy server, defaults to 60s." -msgstr "galaxy サーバーに対する操作を待機する時間。デフォルトは 60s です。" - -#: ../../rst/cli/ansible-galaxy.rst:113 ../../rst/cli/ansible-galaxy.rst:167 -#: ../../rst/cli/ansible-galaxy.rst:210 ../../rst/cli/ansible-galaxy.rst:255 -#: ../../rst/cli/ansible-galaxy.rst:328 ../../rst/cli/ansible-galaxy.rst:389 -#: ../../rst/cli/ansible-galaxy.rst:446 ../../rst/cli/ansible-galaxy.rst:519 -#: ../../rst/cli/ansible-galaxy.rst:560 ../../rst/cli/ansible-galaxy.rst:597 -#: ../../rst/cli/ansible-galaxy.rst:630 ../../rst/cli/ansible-galaxy.rst:679 -#: ../../rst/cli/ansible-galaxy.rst:728 ../../rst/cli/ansible-galaxy.rst:769 -#: ../../rst/cli/ansible-galaxy.rst:810 ../../rst/cli/ansible-galaxy.rst:851 -msgid "The Ansible Galaxy API key which can be found at https://galaxy.ansible.com/me/preferences." -msgstr "https://galaxy.ansible.com/me/preferences で見つかる Ansible Galaxy API キー。" - -#: ../../rst/cli/ansible-galaxy.rst:117 ../../rst/cli/ansible-galaxy.rst:171 -#: ../../rst/cli/ansible-galaxy.rst:214 ../../rst/cli/ansible-galaxy.rst:259 -#: ../../rst/cli/ansible-galaxy.rst:336 ../../rst/cli/ansible-galaxy.rst:393 -#: ../../rst/cli/ansible-galaxy.rst:450 ../../rst/cli/ansible-galaxy.rst:527 -#: ../../rst/cli/ansible-galaxy.rst:564 ../../rst/cli/ansible-galaxy.rst:601 -#: ../../rst/cli/ansible-galaxy.rst:634 ../../rst/cli/ansible-galaxy.rst:683 -#: ../../rst/cli/ansible-galaxy.rst:732 ../../rst/cli/ansible-galaxy.rst:773 -#: ../../rst/cli/ansible-galaxy.rst:814 ../../rst/cli/ansible-galaxy.rst:855 -msgid "Ignore SSL certificate validation errors." -msgstr "SSL 証明書の検証エラーを無視します。" - -#: ../../rst/cli/ansible-galaxy.rst:121 -msgid "Don't download collection(s) listed as dependencies." -msgstr "依存関係としてリストされているコレクションはダウンロードしないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:125 -msgid "The directory to download the collections to." -msgstr "コレクションをダウンロードするディレクトリー。" - -#: ../../rst/cli/ansible-galaxy.rst:129 -msgid "A file containing a list of collections to be downloaded." -msgstr "ダウンロードするコレクションの一覧を含むファイル。" - -#: ../../rst/cli/ansible-galaxy.rst:133 ../../rst/cli/ansible-galaxy.rst:179 -#: ../../rst/cli/ansible-galaxy.rst:222 ../../rst/cli/ansible-galaxy.rst:263 -#: ../../rst/cli/ansible-galaxy.rst:360 ../../rst/cli/ansible-galaxy.rst:401 -#: ../../rst/cli/ansible-galaxy.rst:466 ../../rst/cli/ansible-galaxy.rst:535 -#: ../../rst/cli/ansible-galaxy.rst:572 ../../rst/cli/ansible-galaxy.rst:605 -#: ../../rst/cli/ansible-galaxy.rst:642 ../../rst/cli/ansible-galaxy.rst:687 -#: ../../rst/cli/ansible-galaxy.rst:736 ../../rst/cli/ansible-galaxy.rst:781 -#: ../../rst/cli/ansible-galaxy.rst:822 ../../rst/cli/ansible-galaxy.rst:883 -msgid "The Galaxy API server URL" -msgstr "Galaxy API サーバー URL" - -#: ../../rst/cli/ansible-galaxy.rst:144 -msgid "collection init" -msgstr "collection init" - -#: ../../rst/cli/ansible-galaxy.rst:146 ../../rst/cli/ansible-galaxy.rst:494 -msgid "Creates the skeleton framework of a role or collection that complies with the Galaxy metadata format. Requires a role or collection name. The collection name must be in the format ``.``." -msgstr "Galaxy メタデータ形式に準拠するロールまたはコレクションのスケルトンフレームワークを作成します。ロールまたはコレクション名が必要です。コレクション名は ``.`` の形式にする必要があります。" - -#: ../../rst/cli/ansible-galaxy.rst:155 -msgid "The path to a collection skeleton that the new collection should be based upon." -msgstr "新しいコレクションの基となるコレクションスケルトンへのパス。" - -#: ../../rst/cli/ansible-galaxy.rst:159 -msgid "The path in which the skeleton collection will be created. The default is the current working directory." -msgstr "スケルトンコレクションが作成されるパス。デフォルトは現在の作業ディレクトリーです。" - -#: ../../rst/cli/ansible-galaxy.rst:175 ../../rst/cli/ansible-galaxy.rst:218 -#: ../../rst/cli/ansible-galaxy.rst:340 ../../rst/cli/ansible-galaxy.rst:531 -#: ../../rst/cli/ansible-galaxy.rst:859 -msgid "Force overwriting an existing role or collection" -msgstr "既存のロールまたはコレクションの上書きを強制します。" - -#: ../../rst/cli/ansible-galaxy.rst:190 -msgid "collection build" -msgstr "collection build" - -#: ../../rst/cli/ansible-galaxy.rst:192 -msgid "Build an Ansible Galaxy collection artifact that can be stored in a central repository like Ansible Galaxy. By default, this command builds from the current working directory. You can optionally pass in the collection input path (where the ``galaxy.yml`` file is)." -msgstr "Ansible Galaxy などの中央リポジトリーに格納できる Ansible Galaxy コレクションアーティファクトを構築します。デフォルトでは、このコマンドは現在の作業ディレクトリーから構築されます。必要に応じて、コレクション入力パスを渡すことができます (``galaxy.yml`` ファイルの場所です)。" - -#: ../../rst/cli/ansible-galaxy.rst:202 -msgid "The path in which the collection is built to. The default is the current working directory." -msgstr "コレクションが構築されるパス。デフォルトは現在の作業ディレクトリーです。" - -#: ../../rst/cli/ansible-galaxy.rst:233 -msgid "collection publish" -msgstr "collection publish" - -#: ../../rst/cli/ansible-galaxy.rst:235 -msgid "Publish a collection into Ansible Galaxy. Requires the path to the collection tarball to publish." -msgstr "コレクションを Ansible Galaxy に公開します。公開するには、コレクション tarball へのパスが必要になります。" - -#: ../../rst/cli/ansible-galaxy.rst:243 -msgid "The time to wait for the collection import process to finish." -msgstr "コレクションのインポートプロセスが完了するのを待つ時間。" - -#: ../../rst/cli/ansible-galaxy.rst:247 -msgid "Don't wait for import validation results." -msgstr "インポートの検証結果を待ちません。" - -#: ../../rst/cli/ansible-galaxy.rst:274 -msgid "collection install" -msgstr "collection install" - -#: ../../rst/cli/ansible-galaxy.rst:288 -msgid "Disable GPG signature verification when installing collections from a Galaxy server" -msgstr "Galaxy サーバーからコレクションをインストールする際に GPG 署名の検証を無効にします。" - -#: ../../rst/cli/ansible-galaxy.rst:292 -msgid "Force overwriting an existing collection and its dependencies." -msgstr "既存のコレクションおよびその依存関係を強制的に上書きします。" - -#: ../../rst/cli/ansible-galaxy.rst:296 ../../rst/cli/ansible-galaxy.rst:422 -msgid "A status code to ignore during signature verification (for example, NO_PUBKEY). Provide this option multiple times to ignore a list of status codes. Descriptions for the choices can be seen at L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes)." -msgstr "署名の検証中に無視するステータスコード (例: NO_PUBKEY)。このオプションを複数回指定して、ステータスコードの一覧を無視します。選択肢の説明は L (https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) で確認できます。" - -#: ../../rst/cli/ansible-galaxy.rst:300 ../../rst/cli/ansible-galaxy.rst:426 -msgid "The keyring used during signature verification" -msgstr "署名の検証中に使用されるキーリング" - -#: ../../rst/cli/ansible-galaxy.rst:308 -msgid "Install collection artifacts (tarballs) without contacting any distribution servers. This does not apply to collections in remote Git repositories or URLs to remote tarballs." -msgstr "配信サーバーに問い合わせずにコレクションアーティファクト (tarball) をインストールします。これは、リモート Git リポジトリー内のコレクションや、リモートの tarball への URL には適用されません。" - -#: ../../rst/cli/ansible-galaxy.rst:316 -msgid "The number of signatures that must successfully verify the collection. This should be a positive integer or -1 to signify that all signatures must be used to verify the collection. Prepend the value with + to fail if no valid signatures are found for the collection (e.g. +all)." -msgstr "コレクションを正常に検証する必要のある署名の数。この値が整数または -1 の場合、すべての署名をコレクションの検証に使用する必要があることを示しています。コレクションに有効な署名が見つからない場合に失敗するには、値の先頭に + を追加します (例: +all）。" - -#: ../../rst/cli/ansible-galaxy.rst:320 -msgid "An additional signature source to verify the authenticity of the MANIFEST.json before installing the collection from a Galaxy server. Use in conjunction with a positional collection name (mutually exclusive with --requirements-file)." -msgstr "Galaxy サーバーからコレクションをインストールする前に、MANIFEST.json の信頼性を検証する追加の署名ソース。位置コレクション名と併用します (--requirements-file とは相互に排他的)。" - -#: ../../rst/cli/ansible-galaxy.rst:332 -msgid "Upgrade installed collection artifacts. This will also update dependencies unless --no-deps is provided" -msgstr "インストールされたコレクションアーティファクトをアップグレードします。--no-deps が提供されている場合を除き依存関係も更新されます。" - -#: ../../rst/cli/ansible-galaxy.rst:344 -msgid "Ignore errors during installation and continue with the next specified collection. This will not ignore dependency conflict errors." -msgstr "インストール時にエラーを無視し、次の指定されたコレクションで続行します。依存関係の競合エラーは無視しません。" - -#: ../../rst/cli/ansible-galaxy.rst:348 -msgid "Don't download collections listed as dependencies." -msgstr "依存関係として一覧表示されているコレクションはダウンロードしないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:352 -msgid "The path to the directory containing your collections." -msgstr "コレクションを含むディレクトリーへのパス。" - -#: ../../rst/cli/ansible-galaxy.rst:356 -msgid "A file containing a list of collections to be installed." -msgstr "インストールするコレクションの一覧を含むファイル。" - -#: ../../rst/cli/ansible-galaxy.rst:371 -msgid "collection list" -msgstr "collection list" - -#: ../../rst/cli/ansible-galaxy.rst:373 ../../rst/cli/ansible-galaxy.rst:618 -msgid "List installed collections or roles" -msgstr "インストール済みのコレクションまたはロールを一覧表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:381 -msgid "Format to display the list of collections in." -msgstr "コレクションの一覧を表示する形式。" - -#: ../../rst/cli/ansible-galaxy.rst:397 ../../rst/cli/ansible-galaxy.rst:458 -msgid "One or more directories to search for collections in addition to the default COLLECTIONS_PATHS. Separate multiple paths with ':'." -msgstr "デフォルトの COLLECTIONS_PATHS に加えて、コレクションを検索する 1 つ以上のディレクトリー。複数のパスは、「:」で区切ります。" - -#: ../../rst/cli/ansible-galaxy.rst:412 -msgid "collection verify" -msgstr "collection verify" - -#: ../../rst/cli/ansible-galaxy.rst:430 -msgid "Validate collection integrity locally without contacting server for canonical manifest hash." -msgstr "通常のマニフェストハッシュのためにサーバーに問い合わせることなく、コレクションの整合性をローカルで検証します。" - -#: ../../rst/cli/ansible-galaxy.rst:434 -msgid "The number of signatures that must successfully verify the collection. This should be a positive integer or all to signify that all signatures must be used to verify the collection. Prepend the value with + to fail if no valid signatures are found for the collection (e.g. +all)." -msgstr "コレクションを正常に検証する必要のある署名の数。この値が整数または all の場合、すべての署名をコレクションの検証に使用する必要があることを示しています。コレクションに有効な署名が見つからない場合に失敗するには、値の先頭に + を追加します (例: +all）。" - -#: ../../rst/cli/ansible-galaxy.rst:438 -msgid "An additional signature source to verify the authenticity of the MANIFEST.json before using it to verify the rest of the contents of a collection from a Galaxy server. Use in conjunction with a positional collection name (mutually exclusive with --requirements-file)." -msgstr "Galaxy サーバーからのコレクションの残りのコンテンツを検証するために使用する前に、MANIFEST.json の信頼性を検証する追加の署名ソース。位置コレクション名と併用します (--requirements-file とは相互に排他的)。" - -#: ../../rst/cli/ansible-galaxy.rst:454 -msgid "Ignore errors during verification and continue with the next specified collection." -msgstr "検証時のエラーを無視し、次の指定されたコレクションで続行します。" - -#: ../../rst/cli/ansible-galaxy.rst:462 -msgid "A file containing a list of collections to be verified." -msgstr "検証するコレクションの一覧を含むファイル。" - -#: ../../rst/cli/ansible-galaxy.rst:478 -msgid "role" -msgstr "ロール" - -#: ../../rst/cli/ansible-galaxy.rst:480 -msgid "Perform the action on an Ansible Galaxy role. Must be combined with a further action like delete/install/init as listed below." -msgstr "Ansible Galaxy ロールで操作を実行します。以下のように delete/install/init などのアクションと組み合わせる必要があります。" - -#: ../../rst/cli/ansible-galaxy.rst:492 -msgid "role init" -msgstr "role init" - -#: ../../rst/cli/ansible-galaxy.rst:503 -msgid "The path in which the skeleton role will be created. The default is the current working directory." -msgstr "スケルトンロールが作成されるパス。デフォルトは現在の作業ディレクトリーです。" - -#: ../../rst/cli/ansible-galaxy.rst:507 ../../rst/cli/ansible-galaxy.rst:802 -msgid "Don't query the galaxy API when creating roles" -msgstr "ロールの作成時に galaxy API にクエリーを実行しないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:511 -msgid "The path to a role skeleton that the new role should be based upon." -msgstr "新しいロールの基となるロールスケルトンへのパス。" - -#: ../../rst/cli/ansible-galaxy.rst:523 -msgid "Initialize using an alternate role type. Valid types include: 'container', 'apb' and 'network'." -msgstr "別のロールタイプを使用して初期化します。有効なタイプには、「container」、「apb」、および「network」が含まれます。" - -#: ../../rst/cli/ansible-galaxy.rst:546 -msgid "role remove" -msgstr "role remove" - -#: ../../rst/cli/ansible-galaxy.rst:548 -msgid "removes the list of roles passed as arguments from the local system." -msgstr "ローカルシステムから引数として渡されたロールの一覧を削除します。" - -#: ../../rst/cli/ansible-galaxy.rst:568 ../../rst/cli/ansible-galaxy.rst:638 -#: ../../rst/cli/ansible-galaxy.rst:777 ../../rst/cli/ansible-galaxy.rst:818 -#: ../../rst/cli/ansible-galaxy.rst:875 -msgid "The path to the directory containing your roles. The default is the first writable one configured via DEFAULT_ROLES_PATH: {{ ANSIBLE_HOME ~ \"/roles:/usr/share/ansible/roles:/etc/ansible/roles\" }}" -msgstr "ロールを含むディレクトリーへのパスです。デフォルトは DEFAULT_ROLES_PATH: {{ ANSIBLE_HOME ~ \"/roles:/usr/share/ansible/roles:/etc/ansible/roles\" }} で設定される最初の書き込み可能なファイルです。" - -#: ../../rst/cli/ansible-galaxy.rst:583 -msgid "role delete" -msgstr "role delete" - -#: ../../rst/cli/ansible-galaxy.rst:585 -msgid "Delete a role from Ansible Galaxy." -msgstr "Ansible Galaxy からロールを削除します。" - -#: ../../rst/cli/ansible-galaxy.rst:616 -msgid "role list" -msgstr "role list" - -#: ../../rst/cli/ansible-galaxy.rst:653 -msgid "role search" -msgstr "role search" - -#: ../../rst/cli/ansible-galaxy.rst:655 -msgid "searches for roles on the Ansible Galaxy server" -msgstr "Ansible Galaxy サーバーでロールを検索します。" - -#: ../../rst/cli/ansible-galaxy.rst:663 -msgid "GitHub username" -msgstr "GitHub ユーザー名" - -#: ../../rst/cli/ansible-galaxy.rst:667 -msgid "list of galaxy tags to filter by" -msgstr "フィルタリングする galaxy タグの一覧を表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:671 -msgid "list of OS platforms to filter by" -msgstr "フィルタリングする OS プラットフォームの一覧を表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:698 -msgid "role import" -msgstr "role import" - -#: ../../rst/cli/ansible-galaxy.rst:700 -msgid "used to import a role into Ansible Galaxy" -msgstr "Ansible Galaxy にロールをインポートするのに使用します。" - -#: ../../rst/cli/ansible-galaxy.rst:708 -msgid "The name of a branch to import. Defaults to the repository's default branch (usually master)" -msgstr "インポートするブランチの名前。デフォルトではリポジトリーのデフォルトブランチ (通常は master) に設定されます。" - -#: ../../rst/cli/ansible-galaxy.rst:712 -msgid "Don't wait for import results." -msgstr "インポートの結果を待ちません。" - -#: ../../rst/cli/ansible-galaxy.rst:716 -msgid "The name the role should have, if different than the repo name" -msgstr "ロールに付与すべき名前 (リポジトリー名とは異なる場合)" - -#: ../../rst/cli/ansible-galaxy.rst:720 -msgid "Check the status of the most recent import request for given github_user/github_repo." -msgstr "指定した github_user/github_repo の、最新のインポート要求ステータスを確認します。" - -#: ../../rst/cli/ansible-galaxy.rst:747 -msgid "role setup" -msgstr "role setup" - -#: ../../rst/cli/ansible-galaxy.rst:749 -msgid "Setup an integration from Github or Travis for Ansible Galaxy roles" -msgstr "Ansible Galaxy ロールの Github または Travis からの統合を設定します。" - -#: ../../rst/cli/ansible-galaxy.rst:757 -msgid "List all of your integrations." -msgstr "すべての統合の一覧を表示します。" - -#: ../../rst/cli/ansible-galaxy.rst:761 -msgid "Remove the integration matching the provided ID value. Use --list to see ID values." -msgstr "指定の ID 値に一致するインテグレーションを削除します。ID の値を表示するには --list を使用します。" - -#: ../../rst/cli/ansible-galaxy.rst:792 -msgid "role info" -msgstr "role info" - -#: ../../rst/cli/ansible-galaxy.rst:794 -msgid "prints out detailed information about an installed role as well as info available from the galaxy API." -msgstr "インストールされているロールに関する詳細情報と、galaxy API で利用可能な情報を出力します。" - -#: ../../rst/cli/ansible-galaxy.rst:833 -msgid "role install" -msgstr "role install" - -#: ../../rst/cli/ansible-galaxy.rst:843 -msgid "Force overwriting an existing role and its dependencies." -msgstr "既存のロールとその依存関係を強制的に上書きします。" - -#: ../../rst/cli/ansible-galaxy.rst:863 -msgid "Use tar instead of the scm archive option when packaging the role." -msgstr "ロールをパッケージ化する際に、scm アーカイブオプションの代わりに tar を使用します。" - -#: ../../rst/cli/ansible-galaxy.rst:867 -msgid "Ignore errors and continue with the next specified role." -msgstr "エラーを無視して、次に指定したロールで続行します。" - -#: ../../rst/cli/ansible-galaxy.rst:871 -msgid "Don't download roles listed as dependencies." -msgstr "依存関係としてリストされているロールはダウンロードしないでください。" - -#: ../../rst/cli/ansible-galaxy.rst:879 -msgid "A file containing a list of roles to be installed." -msgstr "インストールするロールの一覧を含むファイル。" - -#: ../../rst/cli/ansible-inventory.rst:7 -msgid "ansible-inventory" -msgstr "ansible-inventory" - -#: ../../rst/cli/ansible-inventory.rst:10 -msgid ":strong:`None`" -msgstr ":strong:`None`" - -#: ../../rst/cli/ansible-inventory.rst:37 -msgid "used to display or dump the configured inventory as Ansible sees it" -msgstr "Ansible が認識しているように、設定したインベントリーを表示またはダンプするために使用します。" - -#: ../../rst/cli/ansible-inventory.rst:53 -msgid "When doing an --list, represent in a way that is optimized for export,not as an accurate representation of how Ansible has processed it" -msgstr "--list を実行する場合は、Ansible が処理する方法を正確に示すのではなく、エクスポート用に最適化される方法を示します。" - -#: ../../rst/cli/ansible-inventory.rst:58 -msgid "create inventory graph, if supplying pattern it must be a valid group name" -msgstr "インベントリーグラフを作成します (パターンを指定している場合は、有効なグループ名である必要があります)。" - -#: ../../rst/cli/ansible-inventory.rst:63 -msgid "Output specific host info, works as inventory script" -msgstr "特定のホスト情報を出力します (インベントリースクリプトとして機能します)。" - -#: ../../rst/cli/ansible-inventory.rst:68 -msgid "Output all hosts info, works as inventory script" -msgstr "全ホスト情報出力します (インベントリースクリプトとして機能します)。" - -#: ../../rst/cli/ansible-inventory.rst:73 -#: ../../rst/cli/ansible-inventory.rst:128 -msgid "==SUPPRESS==" -msgstr "==SUPPRESS==" - -#: ../../rst/cli/ansible-inventory.rst:78 -msgid "When doing --list, send the inventory to a file instead of to the screen" -msgstr "--list を実行する場合は、画面の代わりにインベントリーをファイルに送信します。" - -#: ../../rst/cli/ansible-inventory.rst:88 -msgid "Use TOML format instead of default JSON, ignored for --graph" -msgstr "デフォルトの JSON の代わりに TOML 形式を使用します (--graph では無視されます)。" - -#: ../../rst/cli/ansible-inventory.rst:93 -msgid "Add vars to graph display, ignored unless used with --graph" -msgstr "グラフ表示に変数を追加します。--graph と併用しない限り無視されます。" - -#: ../../rst/cli/ansible-inventory.rst:138 -msgid "Use YAML format instead of default JSON, ignored for --graph" -msgstr "デフォルトの JSON の代わりに YAML 形式を使用します。--graph は無視されます。" - -#: ../../rst/cli/ansible-playbook.rst:7 -msgid "ansible-playbook" -msgstr "ansible-playbook" - -#: ../../rst/cli/ansible-playbook.rst:10 -msgid ":strong:`Runs Ansible playbooks, executing the defined tasks on the targeted hosts.`" -msgstr ":strong:`ターゲットのホストで定義したタスクを実行して Ansible Playbook を実行します。`" - -#: ../../rst/cli/ansible-playbook.rst:42 -msgid "the tool to run *Ansible playbooks*, which are a configuration and multinode deployment system. See the project home page (https://docs.ansible.com) for more information." -msgstr "設定およびマルチノードのデプロイメントシステムである *Ansible Playbook* を実行するツール。詳細はプロジェクトのホームページ (https://docs.ansible.com) を参照してください。" - -#: ../../rst/cli/ansible-playbook.rst:79 -msgid "clear the fact cache for every host in inventory" -msgstr "インベントリー内のすべてのホストのファクトキャッシュを消去します。" - -#: ../../rst/cli/ansible-playbook.rst:84 -msgid "run handlers even if a task fails" -msgstr "タスクが失敗してもハンドラーを実行します。" - -#: ../../rst/cli/ansible-playbook.rst:94 -msgid "list all available tags" -msgstr "利用可能なタグをすべて表示します。" - -#: ../../rst/cli/ansible-playbook.rst:99 -msgid "list all tasks that would be executed" -msgstr "実行するタスクをすべて表示します。" - -#: ../../rst/cli/ansible-playbook.rst:119 ../../rst/cli/ansible-pull.rst:128 -msgid "only run plays and tasks whose tags do not match these values" -msgstr "タグがこれらの値と一致しないプレイとタスクのみを実行します。" - -#: ../../rst/cli/ansible-playbook.rst:134 -msgid "start the playbook at the task matching this name" -msgstr "この名前に一致するタスクで Playbook を開始します。" - -#: ../../rst/cli/ansible-playbook.rst:229 ../../rst/cli/ansible-pull.rst:248 -msgid "only run plays and tasks tagged with these values" -msgstr "それらの値でタグ付けされたプレイとタスクのみを実行します。" - -#: ../../rst/cli/ansible-pull.rst:7 -msgid "ansible-pull" -msgstr "ansible-pull" - -#: ../../rst/cli/ansible-pull.rst:10 -msgid ":strong:`pulls playbooks from a VCS repo and executes them for the local host`" -msgstr ":strong:`VCS リポジトリーから Playbooks を取得し、ローカルホストで実行します。`" - -#: ../../rst/cli/ansible-pull.rst:41 -msgid "Used to pull a remote copy of ansible on each managed node, each set to run via cron and update playbook source via a source repository. This inverts the default *push* architecture of ansible into a *pull* architecture, which has near-limitless scaling potential." -msgstr "各管理対象ノードで ansible のリモートコピーを取得するのに使用されます。各セットは cron を介して実行され、ソースリポジトリーを介して Playbook ソースを更新します。これにより、ansible のデフォルトの *push* アーキテクチャーが *pull* アーキテクチャーに反転します。これには、スケーリングの可能性がほぼ無限あります。" - -#: ../../rst/cli/ansible-pull.rst:46 -msgid "None of the CLI tools are designed to run concurrently with themselves, you should use an external scheduler and/or locking to ensure there are no clashing operations." -msgstr "どの CLI ツールも同時に実行するようには設計されていません。外部スケジューラーやロックを使用して、操作が競合しないようにする必要があります。" - -#: ../../rst/cli/ansible-pull.rst:49 -msgid "The setup playbook can be tuned to change the cron frequency, logging locations, and parameters to ansible-pull. This is useful both for extreme scale-out as well as periodic remediation. Usage of the 'fetch' module to retrieve logs from ansible-pull runs would be an excellent way to gather and analyze remote logs from ansible-pull." -msgstr "セットアップ Playbook は、cron 頻度、ロギングの場所、およびパラメーターを ansible-pull に変更します。これは、急なスケールアウトと定期的な修復にも便利です。ansible-pull からログを取得するために「fetch」モジュールを使用することは、ansible-pull からログを収集し、分析するための優れた方法です。" - -#: ../../rst/cli/ansible-pull.rst:63 -msgid "adds the hostkey for the repo url if not already added" -msgstr "リポジトリー URL のホストキーが追加されていない場合はホストキーを追加します。" - -#: ../../rst/cli/ansible-pull.rst:83 -msgid "modified files in the working repository will be discarded" -msgstr "作業リポジトリー内の変更されたファイルは破棄されます。" - -#: ../../rst/cli/ansible-pull.rst:98 -msgid "Do a full clone, instead of a shallow one." -msgstr "簡易クローンではなく、完全なクローンを実行します。" - -#: ../../rst/cli/ansible-pull.rst:113 -msgid "purge checkout after playbook run" -msgstr "Playbook の実行後にチェックアウトをパージします。" - -#: ../../rst/cli/ansible-pull.rst:143 -msgid "submodules will track the latest changes. This is equivalent to specifying the --remote flag to git submodule update" -msgstr "サブモジュールでは最新の変更を追跡します。これは、--remote フラグを git サブモジュール更新に指定するのと同じです。" - -#: ../../rst/cli/ansible-pull.rst:158 -msgid "verify GPG signature of checked out commit, if it fails abort running the playbook. This needs the corresponding VCS module to support such an operation" -msgstr "チェックアウトしたコミットの GPG 署名を確認します。Playbook の実行を中断できない場合に、このような操作をサポートするには、対応する VCS モジュールが必要になります。" - -#: ../../rst/cli/ansible-pull.rst:168 -msgid "branch/tag/commit to checkout. Defaults to behavior of repository module." -msgstr "チェックアウトするブランチ、タグ、またはコミット。デフォルトは、リポジトリーモジュールの動作です。" - -#: ../../rst/cli/ansible-pull.rst:188 -msgid "URL of the playbook repository" -msgstr "Playbook リポジトリーの URL" - -#: ../../rst/cli/ansible-pull.rst:198 -msgid "absolute path of repository checkout directory (relative paths are not supported)" -msgstr "リポジトリーチェックアウトディレクトリーの絶対パス (相対パスはサポートされません)" - -#: ../../rst/cli/ansible-pull.rst:208 -msgid "run the playbook even if the repository could not be updated" -msgstr "リポジトリーを更新できなかった場合でも、Playbook を実行します。" - -#: ../../rst/cli/ansible-pull.rst:233 -msgid "Repository module name, which ansible will use to check out the repo. Choices are ('git', 'subversion', 'hg', 'bzr'). Default is git." -msgstr "Ansible がリポジトリーをチェックアウトするのに使用するリポジトリーモジュール名 (「git」、「subversion」、「hg」、「bzr」)。デフォルトは git です。" - -#: ../../rst/cli/ansible-pull.rst:238 -msgid "only run the playbook if the repository has been updated" -msgstr "リポジトリーが更新されている場合にのみ Playbook を実行します。" - -#: ../../rst/cli/ansible-pull.rst:243 -msgid "sleep for random interval (between 0 and n number of seconds) before starting. This is a useful way to disperse git requests" -msgstr "開始前のランダムな間隔 (0 ～ n 秒間) をスリープ状態にします。これは、git 要求を分散させるための便利な方法です。" - -#: ../../rst/cli/ansible-vault.rst:7 -msgid "ansible-vault" -msgstr "ansible-vault" - -#: ../../rst/cli/ansible-vault.rst:10 -msgid ":strong:`encryption/decryption utility for Ansible data files`" -msgstr ":strong:`Ansible データファイルの暗号化/複合ユーティリティー`" - -#: ../../rst/cli/ansible-vault.rst:33 -msgid "can encrypt any structured data file used by Ansible. This can include *group_vars/* or *host_vars/* inventory variables, variables loaded by *include_vars* or *vars_files*, or variable files passed on the ansible-playbook command line with *-e @file.yml* or *-e @file.json*. Role variables and defaults are also included!" -msgstr "Ansible が使用する構造化データファイルをすべて暗号化できます。これには、インベントリー変数 *group_vars/* または *host_vars/*、*include_vars* または *vars_files* で読み込まれる変数、*-e @file.yml* または *-e @file.json* を使用して ansible-playbook コマンドラインで渡される変数ファイルが含まれます。ロールの変数およびデフォルトも含まれます。" - -#: ../../rst/cli/ansible-vault.rst:39 -msgid "Because Ansible tasks, handlers, and other objects are data, these can also be encrypted with vault. If you'd like to not expose what variables you are using, you can keep an individual task file entirely encrypted." -msgstr "Ansible タスク、ハンドラー、およびその他のオブジェクトはデータであるため、Vault で暗号化することもできます。使用している変数を公開しない場合は、個別のタスクファイルを完全に暗号化できます。" - -#: ../../rst/cli/ansible-vault.rst:77 -msgid "create" -msgstr "create" - -#: ../../rst/cli/ansible-vault.rst:79 -msgid "create and open a file in an editor that will be encrypted with the provided vault secret when closed" -msgstr "閉じたときに提供される Vault シークレットで暗号化されるファイルを作成してエディターで開きます" - -#: ../../rst/cli/ansible-vault.rst:91 ../../rst/cli/ansible-vault.rst:159 -#: ../../rst/cli/ansible-vault.rst:223 ../../rst/cli/ansible-vault.rst:261 -#: ../../rst/cli/ansible-vault.rst:315 -msgid "the vault id used to encrypt (required if more than one vault-id is provided)" -msgstr "暗号化に使用する Vault ID (複数の vault-id が指定されている場合に必要)" - -#: ../../rst/cli/ansible-vault.rst:111 -msgid "decrypt" -msgstr "decrypt" - -#: ../../rst/cli/ansible-vault.rst:113 -msgid "decrypt the supplied file using the provided vault secret" -msgstr "提供された Vault シークレットを使用して提供されたファイルを復号します。" - -#: ../../rst/cli/ansible-vault.rst:125 ../../rst/cli/ansible-vault.rst:227 -#: ../../rst/cli/ansible-vault.rst:265 -msgid "output file name for encrypt or decrypt; use - for stdout" -msgstr "暗号化用または復号用の出力ファイル名。標準出力 (stdout) に - を使用します。" - -#: ../../rst/cli/ansible-vault.rst:145 -msgid "edit" -msgstr "編集" - -#: ../../rst/cli/ansible-vault.rst:147 -msgid "open and decrypt an existing vaulted file in an editor, that will be encrypted again when closed" -msgstr "エディターで既存の Vault ファイルを開き、復号します。これは、閉じると再度暗号化されます。" - -#: ../../rst/cli/ansible-vault.rst:181 -msgid "open, decrypt and view an existing vaulted file using a pager using the supplied vault secret" -msgstr "提供された Vault シークレットを使用するページャーを使用して、既存の Vault ファイルを開き、復号し、表示します。" - -#: ../../rst/cli/ansible-vault.rst:209 -msgid "encrypt" -msgstr "encrypt" - -#: ../../rst/cli/ansible-vault.rst:211 -msgid "encrypt the supplied file using the provided vault secret" -msgstr "提供される Vault シークレットを使用して提供されたファイルを暗号化します。" - -#: ../../rst/cli/ansible-vault.rst:247 -msgid "encrypt_string" -msgstr "encrypt_string" - -#: ../../rst/cli/ansible-vault.rst:249 -msgid "encrypt the supplied string using the provided vault secret" -msgstr "提供された Vault シークレットを使用して提供された文字列を暗号化します。" - -#: ../../rst/cli/ansible-vault.rst:269 -msgid "Do not hide input when prompted for the string to encrypt" -msgstr "文字列の暗号化を要求したときに入力を非表示にしません。" - -#: ../../rst/cli/ansible-vault.rst:273 -msgid "Specify the variable name for stdin" -msgstr "stdin の変数名を指定します。" - -#: ../../rst/cli/ansible-vault.rst:285 -msgid "Specify the variable name" -msgstr "変数名を指定します。" - -#: ../../rst/cli/ansible-vault.rst:289 -msgid "Prompt for the string to encrypt" -msgstr "暗号化する文字列を入力します。" - -#: ../../rst/cli/ansible-vault.rst:301 -msgid "rekey" -msgstr "rekey" - -#: ../../rst/cli/ansible-vault.rst:303 -msgid "re-encrypt a vaulted file with a new secret, the previous secret is required" -msgstr "新規シークレットと共に Vault ファイルを再暗号化します。以前のシークレットが必要です。" - -#: ../../rst/cli/ansible-vault.rst:319 -msgid "the new vault identity to use for rekey" -msgstr "rekey に使用する新しい vault アイデンティティー" - -#: ../../rst/cli/ansible-vault.rst:323 -msgid "new vault password file for rekey" -msgstr "rekey の新しい Vault パスワードファイル" - -#~ msgid "a REPL that allows for running ad-hoc tasks against a chosen inventory (based on dominis' ansible-shell)." -#~ msgstr "" - -#~ msgid "module arguments" -#~ msgstr "モジュール引数" - -#~ msgid "verbose mode (-vvv for more, -vvvv to enable connection debugging)" -#~ msgstr "詳細モード (-vvv の場合はより詳細になる。-vvvv の場合は接続のデバッグを有効にする)" - -#~ msgid "list all current configs reading lib/constants.py and shows env and config file setting names" -#~ msgstr "lib/constants.py を読み取る現在の設定の一覧を表示し、env および config ファイルの設定名を表示します。" - -#~ msgid "directory to checkout repository to" -#~ msgstr "リポジトリーをチェックアウトするディレクトリー" - -#~ msgid "command to manage Ansible roles in shared repositories, the default of which is Ansible Galaxy *https://galaxy.ansible.com*." -#~ msgstr "共有リポジトリーの Ansible ロールを管理するコマンド (デフォルトは Ansible Galaxy *https://galaxy.ansible.com* です)。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/collections.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/collections.po deleted file mode 100644 index 1165075de6e..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/collections.po +++ /dev/null @@ -1,26 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2021-03-01 12:38+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/collections/all_plugins.rst:6 -msgid "Plugin indexes" -msgstr "プラグインインデックス" - -#: ../../rst/collections/all_plugins.rst:4 -msgid "Indexes of all modules and plugins" -msgstr "すべてのモジュールおよびプラグインのインデックス" - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/collections_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/collections_guide.po deleted file mode 100644 index 7065afab130..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/collections_guide.po +++ /dev/null @@ -1,711 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/collections_guide/collections_downloading.rst:4 -msgid "Downloading collections" -msgstr "コレクションのダウンロード" - -#: ../../rst/collections_guide/collections_downloading.rst:6 -msgid "To download a collection and its dependencies for an offline install, run ``ansible-galaxy collection download``. This downloads the collections specified and their dependencies to the specified folder and creates a ``requirements.yml`` file which can be used to install those collections on a host without access to a Galaxy server. All the collections are downloaded by default to the ``./collections`` folder." -msgstr "オフラインインストール用のコレクションとその依存関係をダウンロードするには、``ansible-galaxy collection download`` を実行します。これにより、指定されたコレクションとその依存関係を指定のディレクトリーにダウンロードして、Galaxy サーバーにアクセスせずに、ホストにこれらのコレクションをインストールするのに使用できる ``requirements.yml`` ファイルを作成します。すべてのコレクションは、デフォルトで ``./collections`` ディレクトリーにダウンロードされます。" - -#: ../../rst/collections_guide/collections_downloading.rst:11 -msgid "Just like the ``install`` command, the collections are sourced based on the :ref:`configured galaxy server config `. Even if a collection to download was specified by a URL or path to a tarball, the collection will be redownloaded from the configured Galaxy server." -msgstr "``install`` コマンドと同様、コレクションは :ref:`configured galaxy server config ` に基づいて取得されます。ダウンロードするコレクションが URL や tarball へのパスで指定されていた場合でも、設定された Galaxy サーバーからコレクションが再ダウンロードされます。" - -#: ../../rst/collections_guide/collections_downloading.rst:15 -msgid "Collections can be specified as one or multiple collections or with a ``requirements.yml`` file just like ``ansible-galaxy collection install``." -msgstr "コレクションは、1 つまたは複数のコレクションとして、または ``ansible-galaxy collection install`` のように ``requirements.yml`` ファイルで指定できます。" - -#: ../../rst/collections_guide/collections_downloading.rst:18 -msgid "To download a single collection and its dependencies:" -msgstr "1 つのコレクションとその依存関係をダウンロードするには、以下を行います。" - -#: ../../rst/collections_guide/collections_downloading.rst:24 -msgid "To download a single collection at a specific version:" -msgstr "特定のバージョンで単一のコレクションをダウンロードするには、以下を実行します。" - -#: ../../rst/collections_guide/collections_downloading.rst:30 -msgid "To download multiple collections either specify multiple collections as command line arguments as shown above or use a requirements file in the format documented with :ref:`collection_requirements_file`." -msgstr "複数のコレクションをダウンロードするには、上記のように複数のコレクションをコマンドライン引数として指定するか、:ref:`collection_requirements_file` に記載されている形式で要件ファイルを使用します。" - -#: ../../rst/collections_guide/collections_downloading.rst:37 -msgid "You can also download a source collection directory. The collection is built with the mandatory ``galaxy.yml`` file." -msgstr "ソースコレクションディレクトリーをダウンロードすることもできます。コレクションは必須の ``galaxy.yml`` ファイルでビルドされます。" - -#: ../../rst/collections_guide/collections_downloading.rst:45 -msgid "You can download multiple source collections from a single namespace by providing the path to the namespace." -msgstr "名前空間へのパスを指定すると、単一の名前空間から複数のソースコレクションをダウンロードできます。" - -#: ../../rst/collections_guide/collections_downloading.rst:61 -msgid "All the collections are downloaded by default to the ``./collections`` folder but you can use ``-p`` or ``--download-path`` to specify another path:" -msgstr "コレクションはすべて、デフォルトで ``./collections`` ディレクトリーにダウンロードされますが、``-p`` または ``--download-path`` を使用して別のパスを指定することもできます。" - -#: ../../rst/collections_guide/collections_downloading.rst:68 -msgid "Once you have downloaded the collections, the folder contains the collections specified, their dependencies, and a ``requirements.yml`` file. You can use this folder as is with ``ansible-galaxy collection install`` to install the collections on a host without access to a Galaxy server." -msgstr "コレクションをダウンロードした後、ディレクトリーには指定されたコレクション、その依存関係、および ``requirements.yml`` ファイルが含まれます。このディレクトリーは、``ansible-galaxy collection install`` と同じように、Galaxy サーバーにアクセスせずにホストにコレクションをインストールできます。" - -#: ../../rst/collections_guide/collections_index.rst:4 -msgid "Collections index" -msgstr "コレクションのインデックス" - -#: ../../rst/collections_guide/collections_index.rst:6 -msgid "You can find an index of collections at :ref:`list_of_collections`." -msgstr "コレクションのインデックスは :ref:`list_of_collections` にあります。" - -#: ../../rst/collections_guide/collections_installing.rst:4 -msgid "Installing collections" -msgstr "コレクションのインストール" - -#: ../../rst/collections_guide/collections_installing.rst:8 -msgid "If you install a collection manually as described in this paragraph, the collection will not be upgraded automatically when you upgrade the ``ansible`` package or ``ansible-core``." -msgstr "この段落で説明されているように、コレクションを手動でインストールした場合には、``ansible`` パッケージまたは ``ansible-core`` をアップグレードしたときに、コレクションが自動的にアップグレードされません。" - -#: ../../rst/collections_guide/collections_installing.rst:11 -msgid "Installing collections with ``ansible-galaxy``" -msgstr "``ansible-galaxy`` でコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections.txt:3 -msgid "By default, ``ansible-galaxy collection install`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). You do not need any further configuration." -msgstr "デフォルトでは、``ansible-galaxy collection install`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。追加設定は必要ありません。" - -#: ../../rst/shared_snippets/installing_collections.txt:7 -msgid "See :ref:`Configuring the ansible-galaxy client ` if you are using any other Galaxy server, such as Red Hat Automation Hub." -msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 `」を参照してください。" - -#: ../../rst/shared_snippets/installing_collections.txt:9 -msgid "To install a collection hosted in Galaxy:" -msgstr "Galaxy でホストされるコレクションをインストールするには、以下を実行します。" - -#: ../../rst/shared_snippets/installing_collections.txt:15 -msgid "To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option:" -msgstr "コレクションを Galaxy サーバーから利用可能な最新バージョンにアップグレードするには、``--upgrade`` オプションを使用します。" - -#: ../../rst/shared_snippets/installing_collections.txt:21 -msgid "You can also directly use the tarball from your build:" -msgstr "ビルドから tarball を直接使用することもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:27 -msgid "You can build and install a collection from a local source directory. The ``ansible-galaxy`` utility builds the collection using the ``MANIFEST.json`` or ``galaxy.yml`` metadata in the directory." -msgstr "ローカルソースディレクトリーからコレクションを構築してインストールできます。``ansible-galaxy`` ユーティリティーは、ディレクトリー内の ``MANIFEST.json`` または ``galaxy.yml`` メタデータを使用してコレクションを構築します。" - -#: ../../rst/shared_snippets/installing_collections.txt:34 -msgid "You can also install multiple collections in a namespace directory." -msgstr "名前空間ディレクトリーに複数のコレクションをインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:51 -msgid "The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the parent directory is already in a folder called ``ansible_collections``." -msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したものに、パス ``ansible_collections`` を自動的に追加します。" - -#: ../../rst/shared_snippets/installing_collections.txt:55 -msgid "When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``" -msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は、:ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。" - -#: ../../rst/shared_snippets/installing_collections.txt:59 -msgid "You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure." -msgstr "また、``collections/ansible_collections/`` ディレクトリー構造の下で、コレクションを現在の Playbook の横に維持することもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:71 -msgid "See :ref:`collection_structure` for details on the collection directory structure." -msgstr "コレクションディレクトリー構造の詳細は、「:ref:`collection_structure`」を参照してください。" - -#: ../../rst/collections_guide/collections_installing.rst:18 -msgid "Installing collections with signature verification" -msgstr "署名の検証によるコレクションのインストール" - -#: ../../rst/collections_guide/collections_installing.rst:20 -msgid "If a collection has been signed by a :term:`distribution server`, the server will provide ASCII armored, detached signatures to verify the authenticity of the ``MANIFEST.json`` before using it to verify the collection's contents. This option is not available on all distribution servers. See :ref:`distributing_collections` for a table listing which servers support collection signing." -msgstr "コレクションが :term:`distribution server` で署名された場合には、サーバーは ASCII 形式の分離署名を提供し、``MANIFEST.json`` の信頼性を確認してから、この署名を使用してコレクションのコンテンツを検証します。このオプションはすべての配信サーバーで利用できるわけではありません。コレクション署名をサポートするサーバーをリストする表については、:ref:`distributing_collections` を参照してください。" - -#: ../../rst/collections_guide/collections_installing.rst:22 -msgid "To use signature verification for signed collections:" -msgstr "署名付きコレクションに署名の検証を使用するには、以下を実行します。" - -#: ../../rst/collections_guide/collections_installing.rst:24 -msgid ":ref:`Configured a GnuPG keyring ` for ``ansible-galaxy``, or provide the path to the keyring with the ``--keyring`` option when you install the signed collection." -msgstr "``ansible-galaxy`` の場合は :ref:`Configured a GnuPG keyring ` を、それ以外の場合は、署名ずいのコレクションをインストールするときに ``--keyring`` オプションを使用してキーリングへのパスを指定します。" - -#: ../../rst/collections_guide/collections_installing.rst:27 -msgid "Import the public key from the distribution server into that keyring." -msgstr "配信サーバーからキーリングに公開鍵をインポートします。" - -#: ../../rst/collections_guide/collections_installing.rst:34 -msgid "Verify the signature when you install the collection." -msgstr "コレクションをインストールするときに署名を確認します。" - -#: ../../rst/collections_guide/collections_installing.rst:40 -msgid "The ``--keyring`` option is not necessary if you have :ref:`configured a GnuPG keyring `." -msgstr ":ref:`configured a GnuPG keyring ` がある場合は、``--keyring`` オプションは必要ありません。" - -#: ../../rst/collections_guide/collections_installing.rst:42 -msgid "Optionally, verify the signature at any point after installation to prove the collection has not been tampered with. See :ref:`verify_signed_collections` for details." -msgstr "必要に応じて、インストール後に署名を確認して、コレクションが改ざんされていないことを証明します。詳細は、:ref:`verify_signed_collections` を参照してください。" - -#: ../../rst/collections_guide/collections_installing.rst:45 -msgid "You can also include signatures in addition to those provided by the distribution server. Use the ``--signature`` option to verify the collection's ``MANIFEST.json`` with these additional signatures. Supplemental signatures should be provided as URIs." -msgstr "配信サーバーが追加した署名以外にも署名を追加できます。``--signature`` オプションを使用して、これらの追加の署名を使用してコレクションの ``MANIFEST.json`` を検証します。補足の署名は、URI として指定します。" - -#: ../../rst/collections_guide/collections_installing.rst:51 -msgid "GnuPG verification only occurs for collections installed from a distribution server. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files." -msgstr "GnuPG 検証は、配信サーバーからインストールされたコレクションでのみ発生します。ユーザーが提供した署名は、git リポジトリー、ソースディレクトリー、または URL/tar.gzファイルへのパスからインストールされたコレクションの検証には使用されません。" - -#: ../../rst/collections_guide/collections_installing.rst:53 -msgid "You can also include additional signatures in the collection ``requirements.yml`` file under the ``signatures`` key." -msgstr "``signatures`` キーのコレクション ``requirements.yml`` ファイルに追加の署名を含めることもできます。" - -#: ../../rst/collections_guide/collections_installing.rst:65 -msgid "See :ref:`collection requirements file ` for details on how to install collections with this file." -msgstr "このファイルでコレクションをインストールする方法は、:ref:`collection requirements file ` を参照してください。" - -#: ../../rst/collections_guide/collections_installing.rst:67 -msgid "By default, verification is considered successful if a minimum of 1 signature successfully verifies the collection. The number of required signatures can be configured with ``--required-valid-signature-count`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. All signatures can be required by setting the option to ``all``. To fail signature verification if no valid signatures are found, prepend the value with ``+``, such as ``+all`` or ``+1``." -msgstr "デフォルトでは、1 つ以上の署名がコレクションを正常に検証した場合に、検証が成功したとみなされます。必要な署名の数は、``--required-valid-signature-count`` または :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` で設定できます。オプションを ``all`` に設定して、すべての署名を要求できます。有効な署名が見つからない場合に、署名の検証に失敗するには、``+all`` や ``+1`` のように値の前に ``+`` を追加します。" - -#: ../../rst/collections_guide/collections_installing.rst:75 -msgid "Certain GnuPG errors can be ignored with ``--ignore-signature-status-code`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` should be a list, and ``--ignore-signature-status-code`` can be provided multiple times to ignore multiple additional error status codes." -msgstr "特定の GnuPG エラーは ``--ignore-signature-status-code`` または :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` により無視できます。:ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` は一覧である必要があり、``--ignore-signature-status-code`` を複数回指定して複数の追加エラーステータスコードを無視することができます。" - -#: ../../rst/collections_guide/collections_installing.rst:77 -msgid "This example requires any signatures provided by the distribution server to verify the collection except if they fail due to NO_PUBKEY:" -msgstr "NO_PUBKEY が原因で失敗しない限り、この例では、コレクションを検証するために配信サーバーが提供する署名が必要です。" - -#: ../../rst/collections_guide/collections_installing.rst:85 -msgid "If verification fails for the example above, only errors other than NO_PUBKEY will be displayed." -msgstr "上記の例で検証に失敗すると、NO_PUBKEY 以外のエラーのみが表示されます。" - -#: ../../rst/collections_guide/collections_installing.rst:87 -msgid "If verification is unsuccessful, the collection will not be installed. GnuPG signature verification can be disabled with ``--disable-gpg-verify`` or by configuring :ref:`GALAXY_DISABLE_GPG_VERIFY`." -msgstr "検証に失敗した場合は、コレクションはインストールされません。GnuPG の署名検証は ``--disable-gpg-verify`` で、あるいは :ref:`GALAXY_DISABLE_GPG_VERIFY` を設定して無効にすることができます。" - -#: ../../rst/collections_guide/collections_installing.rst:93 -msgid "Installing an older version of a collection" -msgstr "古いバージョンのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_older_collection.txt:2 -msgid "You can only have one version of a collection installed at a time. By default ``ansible-galaxy`` installs the latest available version. If you want to install a specific version, you can add a version range identifier. For example, to install the 1.0.0-beta.1 version of the collection:" -msgstr "一度にインストールするコレクションのバージョンは 1 つだけです。デフォルトでは、``ansible-galaxy`` により利用可能な最新バージョンがインストールされます。特定のバージョンをインストールする場合は、バージョン範囲識別子を追加できます。たとえば、コレクションの 1.0.0-beta.1 バージョンをインストールするには、以下を実行します。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:8 -msgid "You can specify multiple range identifiers separated by ``,``. Use single quotes so the shell passes the entire command, including ``>``, ``!``, and other operators, along. For example, to install the most recent version that is greater than or equal to 1.0.0 and less than 2.0.0:" -msgstr "``,`` で区切って複数の範囲識別子を指定できます。シェルが、``>``、``!``、およびその他の演算子を含むコマンド全体を渡すように、一重引用符を使用します。たとえば、1.0.0 以上 2.0.0 未満の最新バージョンをインストールするには、次を実行します。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:14 -msgid "Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers:" -msgstr "Ansible は、指定する範囲識別子を満たす最新バージョンを常にインストールします。以下の範囲識別子を使用できます。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:16 -msgid "``*``: The most recent version. This is the default." -msgstr "``*``: 最新バージョンです。これがデフォルトです。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:17 -msgid "``!=``: Not equal to the version specified." -msgstr "``!=``: 指定されたバージョンと同等ではありません。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:18 -msgid "``==``: Exactly the version specified." -msgstr "``==``: 指定されたバージョンそのものになります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:19 -msgid "``>=``: Greater than or equal to the version specified." -msgstr "``>=``: 指定されたバージョン以上になります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:20 -msgid "``>``: Greater than the version specified." -msgstr "``>``: 指定されたバージョンよりも大きくなります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:21 -msgid "``<=``: Less than or equal to the version specified." -msgstr "``<=``: 指定されたバージョン以下になります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:22 -msgid "``<``: Less than the version specified." -msgstr "``<``: 指定されたバージョンよりも小さくなります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:25 -msgid "By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly." -msgstr "デフォルトでは、``ansible-galaxy`` はリリース前のバージョンを無視します。リリース前のバージョンをインストールするには、``==`` 範囲識別子を使用して明示的に要求する必要があります。" - -#: ../../rst/collections_guide/collections_installing.rst:100 -msgid "Install multiple collections with a requirements file" -msgstr "要件ファイルを使用した複数のコレクションのインストール" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:2 -msgid "You can set up a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:" -msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールできます。このファイルは、以下の形式の YAML ファイルです。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:16 -msgid "You can specify the following keys for each collection entry:" -msgstr "各コレクションエントリーに以下のキーを指定できます。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:18 -msgid "``name``" -msgstr "``name``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:19 -msgid "``version``" -msgstr "``version``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:20 -msgid "``signatures``" -msgstr "``signatures``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:21 -msgid "``source``" -msgstr "``source``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:22 -msgid "``type``" -msgstr "``type``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:24 -msgid "The ``version`` key uses the same range identifier format documented in :ref:`collections_older_version`." -msgstr "``version`` キーは、:ref:`collections_older_version` に記載されているものと同じ範囲識別子形式を使用します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:26 -msgid "The ``signatures`` key accepts a list of signature sources that are used to supplement those found on the Galaxy server during collection installation and ``ansible-galaxy collection verify``. Signature sources should be URIs that contain the detached signature. The ``--keyring`` CLI option must be provided if signatures are specified." -msgstr "``signatures`` キーは、コレクションのインストール時および``ansible-galaxy collection verify``時に Galaxy サーバーで見つけられたものを補足するために使用される署名ソースの一覧を受け入れます。署名ソースは、デタッチされた署名が含まれる URI である必要があります。署名が指定されている場合は、``--keyring`` CLI オプションを指定する必要があります。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:28 -msgid "Signatures are only used to verify collections on Galaxy servers. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files." -msgstr "署名は、Galaxy サーバーのコレクションを検証するためにのみ使用されます。ユーザーが提供した署名は、git リポジトリー、ソースディレクトリー、または URL/tar.gzファイルへのパスからインストールされたコレクションの検証には使用されません。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:40 -msgid "The ``type`` key can be set to ``file``, ``galaxy``, ``git``, ``url``, ``dir``, or ``subdirs``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection." -msgstr "``type`` キーは ``file``、``galaxy``、``git``、``url``、``dir``、または ``subdirs`` に設定できます。``type`` を省略すると、``name`` キーを使用してコレクションのソースを暗黙的に決定します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:42 -msgid "When you install a collection with ``type: git``, the ``version`` key can refer to a branch or to a `git commit-ish `_ object (commit or tag). For example:" -msgstr "``type: git`` でコレクションをインストールする場合、``version`` キーはブランチまたは `git commit-ish `_ オブジェクト（コミットまたはタグ）を参照できます。以下に例を示します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:51 -msgid "You can also add roles to a ``requirements.yml`` file, under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases." -msgstr "``roles``キーの下にある``requirements.yml``ファイルにロールを追加することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:68 -msgid "To install both roles and collections at the same time with one command, run the following:" -msgstr "1 つのコマンドで、ロールとコレクションを同時にインストールするには、以下のコマンドを実行します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:74 -msgid "Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively." -msgstr "``ansible-galaxy collection install -r`` または ``ansible-galaxy role install -r`` を実行すると、それぞれコレクションまたはロールがインストールされます。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:77 -msgid "Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would." -msgstr "カスタムコレクションまたはロールインストールパスを指定する場合、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。" - -#: ../../rst/collections_guide/collections_installing.rst:107 -msgid "Downloading a collection for offline use" -msgstr "オフラインで使用するコレクションのダウンロード" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:3 -msgid "To download the collection tarball from Galaxy for offline use:" -msgstr "オフラインで使用するために、コレクション tarball を Galaxy からダウンロードするには、以下を行います。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:5 -msgid "Navigate to the collection page." -msgstr "コレクションページに移動します。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:6 -msgid "Click on :guilabel:`Download tarball`." -msgstr ":guilabel:`Download tarball` をクリックします。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:8 -msgid "You may also need to manually download any dependent collections." -msgstr "また、依存するコレクションを手動でダウンロードする必要がある場合があります。" - -#: ../../rst/collections_guide/collections_installing.rst:112 -msgid "Installing a collection from source files" -msgstr "ソースファイルからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_file.rst:1 -msgid "Ansible can also install from a source directory in several ways:" -msgstr "Ansible は、複数の方法でソースディレクトリーからインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_file.rst:14 -msgid "Ansible can also install a collection collected with ``ansible-galaxy collection build`` or downloaded from Galaxy for offline use by specifying the output file directly:" -msgstr "出力ファイルを直接指定して、Ansible は``ansible-galaxy collection build`` で収集したコレクションまたは Galaxy からダウンロードしたコレクションをオフライン用にインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_file.rst:24 -msgid "Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file." -msgstr "相対パスは、現在の作業ディレクトリー（``ansible-galaxy install -r`` を呼び出しているディレクトリー）から計算されます。これは、``requirements.yml`` ファイルからの相対パスではありません。" - -#: ../../rst/collections_guide/collections_installing.rst:117 -msgid "Installing a collection from a git repository" -msgstr "git リポジトリーからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 -msgid "You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet." -msgstr "コレクションは、Galaxy または Automation Hub の代わりに git リポジトリーからインストールできます。開発者は、git リポジトリーからインストールし、tarball を作成してコレクションを公開する前にコレクションを確認できます。ユーザーとして git リポジトリーからインストールすることで、Galaxy または Automation Hub にないコレクションまたはバージョンを使用できます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:3 -msgid "The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection." -msgstr "リポジトリーには ``galaxy.yml`` または ``MANIFEST.json`` ファイルが含まれている必要があります。このファイルは、コレクションのバージョン番号、namespace などのメタデータを提供します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:6 -msgid "Installing a collection from a git repository at the command line" -msgstr "コマンドガイドで git リポジトリーからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:8 -msgid "To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). You can specify a branch, commit, or tag using the comma-separated `git commit-ish `_ syntax." -msgstr "git リポジトリーからコレクションをインストールするには、コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーの URI を使用します。ユーザー``git``でSSH認証を使用していない限り、プレフィックス``git+``を使用します(例: ``git@github.com:ansible-collections/ansible.windows.git``)。コンマ区切りの `git コミットのような `_ 構文を使用して、ブランチ、コミット、またはタグを指定できます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:10 -msgid "For example:" -msgstr "例:" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:25 -msgid "Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere." -msgstr "認証情報を git URI に埋め込むことは安全ではありません。安全な認証オプションを使用して、認証情報がログに公開されないようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 -msgid "Use `SSH `_ authentication" -msgstr "`SSH `_ 認証を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:28 -msgid "Use `netrc `_ authentication" -msgstr "`netrc `_ 認証を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:29 -msgid "Use `http.extraHeader `_ in your git configuration" -msgstr "お使いの git 設定で `http.extraHeader `_ を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:30 -msgid "Use `url..pushInsteadOf `_ in your git configuration" -msgstr "お使いの git 設定で `url..pushInsteadOf `_ を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:33 -msgid "Specifying the collection location within the git repository" -msgstr "git リポジトリー内でのコレクションの場所の指定" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:35 -msgid "When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files:" -msgstr "git リポジトリーからコレクションをインストールする場合、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルを使用してコレクションを構築します。デフォルトでは、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルの 2 つのパスを検索します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:37 -msgid "The top level of the repository." -msgstr "リポジトリーのトップレベル。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 -msgid "Each directory in the repository path (one level deep)." -msgstr "リポジトリーパス内の各ディレクトリー（1 レベルの深さ）" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:40 -msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection." -msgstr "``galaxy.yml`` または ``MANIFEST.json`` ファイルがリポジトリーのトップレベルにある場合、Ansible はそのファイル内のコレクションメタデータを使用して個別のコレクションをインストールします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:51 -msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default:" -msgstr "リポジトリーパス内の 1 つ以上のディレクトリーに ``galaxy.yml`` または ``MANIFEST.json`` ファイルが存在する場合は、Ansible はメタデータファイルを持つ各ディレクトリーをコレクションとしてインストールします。たとえば、Ansible は、デフォルトで、このリポジトリー構造から collection1 と collection2 の両方をインストールします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:69 -msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections:" -msgstr "リポジトリ構造が異なる場合、またはコレクションのサブセットのみをインストールする場合は、URI の末尾（オプションのコンマ区切りバージョンの前）にフラグメントを追加して、メタデータファイルの場所を示すことができます。パスは、メタデータファイル自体ではなく、ディレクトリである必要があります。たとえば、2つのコレクションを持つサンプルリポジトリからcollection2のみをインストールするには、次のようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:75 -msgid "In some repositories, the main directory corresponds to the namespace:" -msgstr "リポジトリーによっては、メインのディレクトリーは名前空間に対応します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:97 -msgid "You can install all collections in this repository, or install one collection from a specific commit:" -msgstr "このリポジトリーのすべてのコレクションをインストールするか、特定のコミットから 1 つのコレクションをインストールできます。" - -#: ../../rst/collections_guide/collections_installing.rst:124 -msgid "Configuring the ``ansible-galaxy`` client" -msgstr "``ansible-galaxy`` クライアントの設定" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:3 -msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`)." -msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:5 -msgid "You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as a custom Galaxy server):" -msgstr "以下のオプションを使用して、他のサーバー (カスタムの Galaxy サーバーなど) を使用するように ``ansible-galaxy collection`` を設定できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:7 -msgid "Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`." -msgstr ":ref:`ansible_configuration_settings_locations` の :ref:`galaxy_server_list` 設定オプションにサーバーリストを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:8 -msgid "Use the ``--server`` command line argument to limit to an individual server." -msgstr "``--server`` コマンドライン引数を使用して、個々のサーバーに制限します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:10 -msgid "To configure a Galaxy server list in ``ansible.cfg``:" -msgstr "``ansible.cfg`` で Galaxy サーバー一覧を設定するには、以下を行います。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:13 -msgid "Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names." -msgstr "``server_list`` セクションの ``[galaxy]`` オプションを 1 つ以上のサーバー名に追加します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:14 -msgid "Create a new section for each server name." -msgstr "各サーバー名に新しいセクションを作成します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:15 -msgid "Set the ``url`` option for each server name." -msgstr "各サーバー名に ``url`` オプションを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:16 -msgid "Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`." -msgstr "必要に応じて、各サーバー名の API トークンを設定します。https://galaxy.ansible.com/me/preferences に移動し、guilabel:`Show API key` をクリックします。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:19 -msgid "The ``url`` option for each server name must end with a forward slash ``/``. If you do not set the API token in your Galaxy server list, use the ``--api-key`` argument to pass in the token to the ``ansible-galaxy collection publish`` command." -msgstr "各サーバー名の ``url`` オプションは、スラッシュ ``/`` で終了する必要があります。Galaxy サーバー一覧の API トークンを設定しない場合は、``--api-key`` 引数を使用してトークンを ``ansible-galaxy collection publish`` コマンドに渡します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:22 -msgid "The following example shows how to configure multiple servers:" -msgstr "以下の例は、複数のサーバーを設定する方法を示しています。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:49 -msgid "You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the ``--server`` argument." -msgstr "``--server`` コマンドライン引数を使用して ``server_list`` で明示的な Galaxy サーバーを選択し、この引数の値はサーバー名と一致する必要があります。サーバー一覧にないサーバーを使用する場合は、そのサーバーにアクセスする URL に値を設定します (サーバーリスト内のすべてのサーバーは無視されます)。また、事前定義されたサーバーのいずれかに ``--api-key`` 引数を使用することはできません。サーバーの一覧を定義していない場合、または ``--server`` に URL を指定した場合限り、``api_key`` 引数を使用できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:53 -msgid "**Galaxy server list configuration options**" -msgstr "**Galaxy サーバー一覧設定オプション**" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:55 -msgid "The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section ``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then define the following keys:" -msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義されます。``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:61 -msgid "``url``: The URL of the Galaxy instance to connect to. Required." -msgstr "``url``: 接続する Galaxy インスタンスの URL。必須。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:62 -msgid "``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``." -msgstr "``token``: Galaxy インスタンスに対する認証に使用する API トークンキー。``username`` と相互に排他的です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:63 -msgid "``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``." -msgstr "``username``: Galaxy インスタンスに対する Basic 認証に使用するユーザー名。``token`` と相互に排他的です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:64 -msgid "``password``: The password to use, in conjunction with ``username``, for basic authentication." -msgstr "``password``: Basic 認証に使用するパスワード。``username`` と併用します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:65 -msgid "``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, galaxyNG). Mutually exclusive with ``username``. Requires ``token``." -msgstr "``auth_url``: SSO 認証 (例: galaxyNG) を使用する場合は Keycloak サーバー「token_endpoint」の URL です。``username`` と相互に排他的です。``token`` が必要です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:66 -msgid "``validate_certs``: Whether or not to verify TLS certificates for the Galaxy server. This defaults to True unless the ``--ignore-certs`` option is provided or ``GALAXY_IGNORE_CERTS`` is configured to True." -msgstr "``validate_certs``: Galaxy サーバーの TLS 証明書を検証するかどうか。これは、``--ignore-certs`` オプションが提供されるか、``GALAXY_IGNORE_CERTS`` が True に設定されている場合を除き、デフォルトで True に設定されます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:67 -msgid "``client_id``: The Keycloak token's client_id to use for authentication. Requires ``auth_url`` and ``token``. The default ``client_id`` is cloud-services to work with Red Hat SSO." -msgstr "``client_id``: 認証に使用する Keycloak トークンの client_id。``auth_url`` および ``token`` が必要です。デフォルトの ``client_id`` は、Red Hat SSO と連携するクラウドサービスです。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:69 -msgid "As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for ``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``." -msgstr "これらのサーバーオプションを ``ansible.cfg`` ファイルで定義するだけでなく、それらを環境変数として定義することもできます。環境変数は ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` の形式です。``{{ id }}`` はサーバー識別子の大文字形式であり、``{{ key }}`` は定義するキーです。たとえば、``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token`` を設定することで、``release_galaxy`` に ``token`` を定義することができます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:74 -msgid "For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the ``server_list``, unless you pass in an explicit server with the ``--server`` argument." -msgstr "Galaxy サーバー 1 つだけを使用する操作 (例: ``publish`` コマンド、``info`` コマンド、または ``install`` コマンド) の場合、``ansible-galaxy collection`` コマンドは、``--server`` 引数を使用して明示的なサーバーに渡しない限り、``server_list`` の最初のエントリーを使用します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:78 -msgid "``ansible-galaxy`` can seek out dependencies on other configured Galaxy instances to support the use case where a collection can depend on a collection from another Galaxy instance." -msgstr "``ansible-galaxy`` は、設定済みの他の Galaxy インスタンスで依存関係を検索して、コレクションが別の Galaxy インスタンスからのコレクションに依存する可能性があるようなユースケースをサポートできます。" - -#: ../../rst/collections_guide/collections_listing.rst:4 -msgid "Listing collections" -msgstr "コレクション一覧の表示" - -#: ../../rst/collections_guide/collections_listing.rst:6 -msgid "To list installed collections, run ``ansible-galaxy collection list``. This shows all of the installed collections found in the configured collections search paths. It will also show collections under development which contain a galaxy.yml file instead of a MANIFEST.json. The path where the collections are located are displayed as well as version information. If no version information is available, a ``*`` is displayed for the version number." -msgstr "インストールされたコレクションを一覧表示するには、``ansible-galaxy collection list`` を実行します。これは、設定されたコレクションの検索パスにあるインストールされたコレクションをすべて表示します。これは、MANIFEST.json ではなく galaxy.yml ファイルが含まれる開発中のコレクションも表示します。コレクションが配置されているパスとバージョン情報が表示されます。バージョン情報がない場合は、``*`` がバージョン番号に表示されます。" - -#: ../../rst/collections_guide/collections_listing.rst:25 -msgid "Run with ``-vvv`` to display more detailed information. You may see additional collections here that were added as dependencies of your installed collections. Only use collections in your playbooks that you have directly installed." -msgstr "``-vvv`` を指定して、詳細情報を表示します。ここでは、インストールされたコレクションの依存関係として追加された別のコレクションが表示される場合があります。直接インストールした Playbook のコレクションだけを使用してください。" - -#: ../../rst/collections_guide/collections_listing.rst:28 -msgid "To list a specific collection, pass a valid fully qualified collection name (FQCN) to the command ``ansible-galaxy collection list``. All instances of the collection will be listed." -msgstr "特定のコレクションを一覧表示するには、有効な完全修飾コレクション名 (FQCN) を ``ansible-galaxy collection list`` コマンドに渡します。コレクションのインスタンス一覧が表示されます。" - -#: ../../rst/collections_guide/collections_listing.rst:44 -msgid "To search other paths for collections, use the ``-p`` option. Specify multiple search paths by separating them with a ``:``. The list of paths specified on the command line will be added to the beginning of the configured collections search paths." -msgstr "他のパスのコレクションを検索するには、``-p`` オプションを使用します。複数の検索パスを指定する場合は、``:`` で区切って指定します。コマンドラインで指定されたパスのリストは、設定されたコレクションの検索パスの先頭に追加されます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:5 -msgid "Using collections in a playbook" -msgstr "Playbook でのコレクションの使用" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:7 -msgid "Once installed, you can reference a collection content by its fully qualified collection name (FQCN):" -msgstr "インストールが完了すると、完全修飾コレクション名 (FQCN) でコレクションコンテンツを参照できます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:16 -msgid "This works for roles or any type of plugin distributed within the collection:" -msgstr "これは、コレクションで配布されるロールまたはすべてのタイプのプラグインで機能します。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:32 -msgid "Simplifying module names with the ``collections`` keyword" -msgstr "``collections`` キーワードを使用したモジュール名の簡素化" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:34 -msgid "The ``collections`` keyword lets you define a list of collections that your role or playbook should search for unqualified module and action names. So you can use the ``collections`` keyword, then simply refer to modules and action plugins by their short-form names throughout that role or playbook." -msgstr "``collections`` キーワードを使用すると、ロールまたは Playbook が非修飾モジュールおよびアクション名を検索する必要のあるコレクションの一覧を定義できます。つまり、``collections`` キーワードを使用すると、そのロールまたは Playbook 全体で、モジュールおよびアクションプラグインを短縮名で参照できます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:37 -msgid "If your playbook uses both the ``collections`` keyword and one or more roles, the roles do not inherit the collections set by the playbook. This is one of the reasons we recommend you always use FQCN. See below for roles details." -msgstr "Playbook で ``collections`` キーワードと 1 つ以上のロールの両方を使用している場合、ロールは Playbook で設定されたコレクションを継承しません。これが、常に FQCN を使用することが推奨される理由の 1 つです。ロールの詳細については、以下を参照してください。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:40 -msgid "Using ``collections`` in roles" -msgstr "ロールでの ``collections`` の使用" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:42 -msgid "Within a role, you can control which collections Ansible searches for the tasks inside the role using the ``collections`` keyword in the role's ``meta/main.yml``. Ansible will use the collections list defined inside the role even if the playbook that calls the role defines different collections in a separate ``collections`` keyword entry. Roles defined inside a collection always implicitly search their own collection first, so you don't need to use the ``collections`` keyword to access modules, actions, or other roles contained in the same collection." -msgstr "ロール内で、Ansible がロールの ``meta/main.yml`` の ``collections`` キーワードを使用して、ロール内のタスクを検索するコレクションを制御できます。Ansible は、ロールを呼び出す Playbook が別の ``collections`` キーワードエントリーで異なるコレクションを定義する場合でも、ロール内に定義されたコレクションリストを使用します。コレクション内で定義されたロールは、常に暗黙的に自身のコレクションを最初に検索するため、同じコレクションに含まれるモジュール、アクション、または他のロールにアクセスするために ``collections`` キーワードを使用する必要はありません。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:53 -msgid "Using ``collections`` in playbooks" -msgstr "Playbook での ``collections`` の使用" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:55 -msgid "In a playbook, you can control the collections Ansible searches for modules and action plugins to execute. However, any roles you call in your playbook define their own collections search order; they do not inherit the calling playbook's settings. This is true even if the role does not define its own ``collections`` keyword." -msgstr "Playbook では、Ansible が実行するモジュールやアクションプラグインを検索するコレクションを制御することができます。ただし、Playbook で呼び出したロールは、独自のコレクション検索順序を定義し、呼び出した Playbook の設定を継承しません。これは、ロールが独自の ``collections`` キーワードを定義していない場合でも同様です。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:73 -msgid "The ``collections`` keyword merely creates an ordered 'search path' for non-namespaced plugin and role references. It does not install content or otherwise change Ansible's behavior around the loading of plugins or roles. Note that an FQCN is still required for non-action or module plugins (for example, lookups, filters, tests)." -msgstr "``collections`` キーワードは、名前空間以外のプラグインおよびロール参照に対して、順序付けされた「検索パス」を作成します。コンテンツのインストールや、プラグインやロールの読み込みに関する Ansible の動作は変更されません。非アクションやモジュールプラグイン (ルックアップ、フィルター、テストなど) が必要なことに注意してください。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:75 -msgid "When using the ``collections`` keyword, it is not necessary to add in ``ansible.builtin`` as part of the search list. When left omitted, the following content is available by default:" -msgstr "``collections`` キーワードを使用する場合は、検索リストの一部として ``ansible.builtin`` に追加する必要はありません。省略したままにすると、以下のコンテンツがデフォルトで利用できます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:77 -msgid "Standard ansible modules and plugins available through ``ansible-base``/``ansible-core``" -msgstr "``ansible-base``/``ansible-core`` で利用できる標準の Ansible モジュールおよびプラグイン" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:79 -msgid "Support for older 3rd party plugin paths" -msgstr "古いサードパーティープラグインパスのサポート" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:81 -msgid "In general, it is preferable to use a module or plugin's FQCN over the ``collections`` keyword and the short name for all content in ``ansible-core``" -msgstr "一般に、``ansible-core``のすべてのコンテンツに関して、``collections``のキーワードや短い名前よりも、モジュールやプラグインの FQCN を使用することが推奨されます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:84 -msgid "Using a playbook from a collection" -msgstr "コレクションからの Playbook の使用" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:88 -msgid "You can also distribute playbooks in your collection and invoke them using the same semantics you use for plugins:" -msgstr "コレクションに Playbook を分散し、プラグインに使用するのと同じセマンティクスを使用して Playbook を呼び出すこともできます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:94 -msgid "From inside a playbook:" -msgstr "Playbook 内から、以下を実行します。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:101 -msgid "A few recommendations when creating such playbooks, ``hosts:`` should be generic or at least have a variable input." -msgstr "このような Playbook を作成する際のいくつかの推奨事項として、``hosts:`` は一般的なものにするか、少なくとも変数入力にする必要があります。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:112 -msgid "This will have an implied entry in the ``collections:`` keyword of ``my_namespace.my_collection`` just as with roles." -msgstr "これは、ロールと同様に、``my_namespace.my_collection`` の ``collections:`` キーワードに暗黙的なエントリーを持ちます。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:115 -msgid "Playbook names, like other collection resources, have a restricted set of valid characters. Names can contain only lowercase alphanumeric characters, plus _ and must start with an alpha character. The dash ``-`` character is not valid for playbook names in collections. Playbooks whose names contain invalid characters are not addressable: this is a limitation of the Python importer that is used to load collection resources." -msgstr "他のコレクションリソースなどの Playbook 名では、有効な文字のセットが制限されています。名前には、小文字の英数字と _ のみを含めることができ、アルファベット記号で開始する必要があります。ダッシュ ``-`` は、コレクション内の Playbook 名には有効ではありません。名前に無効な文字が含まれるPlaybookにアドレスを指定することはできません。これは、コレクションリソースの読み込みに使用される Python インポーターの制限です。" - -#: ../../rst/collections_guide/collections_using_playbooks.rst:119 -msgid "Playbooks in collections do not support 'adjacent' plugins, all plugins must be in the collection specific directories." -msgstr "コレクション内の Playbook は「隣接する」プラグインをサポートしません。すべてのプラグインはコレクション固有のディレクトリーにある必要があります。" - -#: ../../rst/collections_guide/collections_verifying.rst:4 -msgid "Verifying collections" -msgstr "コレクションの検証" - -#: ../../rst/collections_guide/collections_verifying.rst:7 -msgid "Verifying collections with ``ansible-galaxy``" -msgstr "``ansible-galaxy`` でコレクションを検証" - -#: ../../rst/collections_guide/collections_verifying.rst:9 -msgid "Once installed, you can verify that the content of the installed collection matches the content of the collection on the server. This feature expects that the collection is installed in one of the configured collection paths and that the collection exists on one of the configured galaxy servers." -msgstr "インストールすると、インストールしたコレクションの内容が、サーバー上のコレクションの内容と一致することを確認できます。この機能は、設定されたコレクションパスのいずれかにコレクションがインストールされ、設定された galaxy サーバーのいずれかにコレクションが存在することを想定します。" - -#: ../../rst/collections_guide/collections_verifying.rst:15 -msgid "The output of the ``ansible-galaxy collection verify`` command is quiet if it is successful. If a collection has been modified, the altered files are listed under the collection name." -msgstr "``ansible-galaxy collection verify`` コマンドの出力は、成功すると何も表示されません。コレクションを変更すると、変更したファイルがコレクション名の下に表示されます。" - -#: ../../rst/collections_guide/collections_verifying.rst:25 -msgid "You can use the ``-vvv`` flag to display additional information, such as the version and path of the installed collection, the URL of the remote collection used for validation, and successful verification output." -msgstr "``-vvv`` フラグを使用すると、インストールされたコレクションのバージョンとパス、検証に使用されるリモートコレクションの URL、正常な確認出力などの追加情報を表示できます。" - -#: ../../rst/collections_guide/collections_verifying.rst:36 -msgid "If you have a pre-release or non-latest version of a collection installed you should include the specific version to verify. If the version is omitted, the installed collection is verified against the latest version available on the server." -msgstr "プレリリースまたは最新でないバージョンのコレクションをインストールしている場合は、検証する特定のバージョンを含める必要があります。バージョンが省略された場合、インストールされたコレクションは、サーバーで利用可能な最新バージョンと比較して検証されます。" - -#: ../../rst/collections_guide/collections_verifying.rst:42 -msgid "In addition to the ``namespace.collection_name:version`` format, you can provide the collections to verify in a ``requirements.yml`` file. Dependencies listed in ``requirements.yml`` are not included in the verify process and should be verified separately." -msgstr "``namespace.collection_name:version`` 形式に加えて、``requirements.yml`` ファイルで検証するコレクションを提供することができます。``requirements.yml`` に記載されている依存関係は、検証プロセスに含まれないため、別途検証する必要があります。" - -#: ../../rst/collections_guide/collections_verifying.rst:48 -msgid "Verifying against ``tar.gz`` files is not supported. If your ``requirements.yml`` contains paths to tar files or URLs for installation, you can use the ``--ignore-errors`` flag to ensure that all collections using the ``namespace.name`` format in the file are processed." -msgstr "``tar.gz`` ファイルに対する検証はサポートされていません。``requirements.yml`` にインストール用の tar ファイルや URL へのパスが含まれている場合は、``--ignore-errors`` フラグを使用して、ファイル内で ``namespace.name`` 形式を使用しているすべてのコレクションが処理されるようにすることができます。" - -#: ../../rst/collections_guide/collections_verifying.rst:53 -msgid "Verifying signed collections" -msgstr "署名付きコレクションの確認" - -#: ../../rst/collections_guide/collections_verifying.rst:55 -msgid "If a collection has been signed by a :term:`distribution server`, the server will provide ASCII armored, detached signatures to verify the authenticity of the MANIFEST.json before using it to verify the collection's contents. This option is not available on all distribution servers. See :ref:`distributing_collections` for a table listing which servers support collection signing. See :ref:`installing_signed_collections` for how to verify a signed collection when you install it." -msgstr "コレクションが :term:`distribution server` で署名された場合には、サーバーは ASCII 形式の分離署名を提供し、MANIFEST.json の信頼性を確認してから、この署名を使用してコレクションのコンテンツを検証します。このオプションはすべての配信サーバーで利用できるわけではありません。コレクション署名をサポートするサーバーをリストする表については、:ref:`distributing_collections` を、インストール時に署名済みのコレクションを検証する方法は、:ref:`installing_signed_collections` を参照してください。" - -#: ../../rst/collections_guide/collections_verifying.rst:57 -msgid "To verify a signed installed collection:" -msgstr "インストール済み署名コレクションを確認するには、以下を実行します。" - -#: ../../rst/collections_guide/collections_verifying.rst:64 -msgid "Use the ``--signature`` option to verify collection name(s) provided on the CLI with an additional signature. This option can be used multiple times to provide multiple signatures." -msgstr "``--signature`` オプションを使用して、追加の署名と共に CLI で提供されるコレクション名を検証します。このオプションを複数回使用して、複数の署名を提供することができます。" - -#: ../../rst/collections_guide/collections_verifying.rst:70 -msgid "Optionally, you can verify a collection signature with a ``requirements.yml`` file." -msgstr "オプションで、``requirements.yml`` ファイルを使用してコレクション署名を検証できます。" - -#: ../../rst/collections_guide/collections_verifying.rst:76 -msgid "When a collection is installed from a distribution server, the signatures provided by the server to verify the collection's authenticity are saved alongside the installed collections. This data is used to verify the internal consistency of the collection without querying the distribution server again when the ``--offline`` option is provided." -msgstr "コレクションが配信サーバーからインストールされる場合、コレクションの信憑性を検証するためにサーバーが提供する署名は、インストールされたコレクションとともに保存されます。``--offline`` オプションが指定されている場合に、このデータを使用して、再度配信サーバーへのクエリーを行わずにコレクションの内部整合性を検証します。" - -#: ../../rst/collections_guide/index.rst:6 -msgid "Using Ansible collections" -msgstr "Ansible コレクションの使用" - -#: ../../rst/collections_guide/index.rst:10 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/collections_guide/index.rst:12 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/collections_guide/index.rst:14 -msgid "Welcome to the Ansible guide for working with collections." -msgstr "Ansible でのコレクション使用ガイドへようこそ。" - -#: ../../rst/collections_guide/index.rst:16 -msgid "Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through a distribution server, such as Ansible Galaxy, or a Pulp 3 Galaxy server." -msgstr "コレクションは、Playbook、ロール、モジュール、プラグインを含む Ansible コンテンツのディストリビューション形式です。Ansible Galaxy または Pulp 3 Galaxy などの配信サーバーでコレクションをインストールして使用できます。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/command_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/command_guide.po deleted file mode 100644 index 58ce627ca1e..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/command_guide.po +++ /dev/null @@ -1,311 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/command_guide/cheatsheet.rst:5 -msgid "Ansible CLI cheatsheet" -msgstr "Ansible CLI のチートシート" - -#: ../../rst/command_guide/cheatsheet.rst:7 -msgid "This page shows one or more examples of each Ansible command line utility with some common flags added and a link to the full documentation for the command. This page offers a quick reminder of some common use cases only - it may be out of date or incomplete or both. For canonical documentation, follow the links to the CLI pages." -msgstr "このページには、一般的なフラグが追加された各 Ansible コマンドラインユーティリティーの 1 つ以上の例と、コマンドの完全なドキュメントへのリンクが表示されます。このページでは、いくつかの一般的なユースケースのクイックリマインダーだけを提供します。このページの情報は、古かったり、不完全だったり、あるいはその両方である可能性があります。正規のドキュメントについては、CLI ページへのリンクに従ってください。" - -#: ../../rst/command_guide/cheatsheet.rst:15 -msgid "ansible-playbook" -msgstr "ansible-playbook" - -#: ../../rst/command_guide/cheatsheet.rst:30 -msgid "Loads ``my_playbook.yml`` from the current working directory and:" -msgstr "現在の作業ディレクトリーから``my_playbook.yml``を読み込みます。ここで、" - -#: ../../rst/command_guide/cheatsheet.rst:22 -msgid "``-i`` - uses ``my_inventory_file`` in the path provided for :ref:`inventory ` to match the :ref:`pattern `." -msgstr "``-i`` - :ref:`インベントリー ` に指定されるパスの``my_inventory_file`` を使用して、:ref:`パターン ` を照合します。" - -#: ../../rst/command_guide/cheatsheet.rst:23 -msgid "``-u`` - connects :ref:`over SSH ` as ``my_connection_user``." -msgstr "``-u`` - ``my_connection_user`` として :ref:`SSH 経由で ` 接続します。" - -#: ../../rst/command_guide/cheatsheet.rst:24 -msgid "``-k`` - asks for password which is then provided to SSH authentication." -msgstr "``-k`` : パスワードを求め、このパスワードを SSH 認証に渡します。" - -#: ../../rst/command_guide/cheatsheet.rst:25 -msgid "``-f`` - allocates 3 :ref:`forks `." -msgstr "``-f`` - 3 つの:ref:`フォーク ` を割り当てます。" - -#: ../../rst/command_guide/cheatsheet.rst:26 -msgid "``-T`` - sets a 30-second timeout." -msgstr "``-T`` - 30 秒のタイムアウトを設定します。" - -#: ../../rst/command_guide/cheatsheet.rst:27 -msgid "``-t`` - runs only tasks marked with the :ref:`tag ` ``my_tag``." -msgstr "``-t`` - :ref:`タグ ` ``my_tag`` でマークされたタスクのみを実行します。" - -#: ../../rst/command_guide/cheatsheet.rst:28 -msgid "``-m`` - loads :ref:`local modules ` from ``/path/to/my/modules``." -msgstr "``-m`` - ``/path/to/my/modules``から:ref:`ローカルモジュール ` を読み込みます。" - -#: ../../rst/command_guide/cheatsheet.rst:29 -msgid "``-b`` - executes with elevated privileges (uses :ref:`become `)." -msgstr "``-b`` - 権限が昇格された状態で実行します（:ref:`become `を使用）。" - -#: ../../rst/command_guide/cheatsheet.rst:30 -msgid "``-K`` - prompts the user for the become password." -msgstr "``-K`` - ユーザーに対し、become パスワードを要求します。" - -#: ../../rst/command_guide/cheatsheet.rst:32 -msgid "See :ref:`ansible-playbook` for detailed documentation." -msgstr "詳細なドキュメントは、「:ref:`ansible-playbook`」を参照してください。" - -#: ../../rst/command_guide/command_line_tools.rst:4 -msgid "Working with command line tools" -msgstr "コマンドラインツールの使用" - -#: ../../rst/command_guide/command_line_tools.rst:6 -msgid "Most users are familiar with `ansible` and `ansible-playbook`, but those are not the only utilities Ansible provides. Below is a complete list of Ansible utilities. Each page contains a description of the utility and a listing of supported parameters." -msgstr "ほとんどのユーザーは、`ansible` および `ansible-playbook` に精通していますが、これらは、Ansible が提供する唯一のユーティリティーではありません。以下は、Ansible ユーティリティーの完全なリストです。各ページには、ユーティリティーの説明と、サポートされるパラメーター一覧が含まれています。" - -#: ../../rst/command_guide/command_line_tools.rst:10 -msgid "You should not run most Ansible CLI tools in parallel against the same targets." -msgstr "ほとんどの Ansible CLI ツールを同じターゲットに対して並行して実行しないでください。" - -#: ../../rst/command_guide/index.rst:5 -msgid "Using Ansible command line tools" -msgstr "Ansible コマンドラインツールの使用" - -#: ../../rst/command_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/command_guide/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/command_guide/index.rst:13 -msgid "Welcome to the guide for using Ansible command line tools. Ansible provides ad hoc commands and several utilities for performing various operations and automation tasks." -msgstr "Ansible コマンドラインツールの使用ガイドへようこそ。Ansible には、アドホックコマンドと、さまざまな操作および自動化タスクを実行するユーティリティーが同梱されています。" - -#: ../../rst/command_guide/intro_adhoc.rst:5 -msgid "Introduction to ad hoc commands" -msgstr "アドホックコマンドの概要" - -#: ../../rst/command_guide/intro_adhoc.rst:7 -msgid "An Ansible ad hoc command uses the `/usr/bin/ansible` command-line tool to automate a single task on one or more managed nodes. ad hoc commands are quick and easy, but they are not reusable. So why learn about ad hoc commands? ad hoc commands demonstrate the simplicity and power of Ansible. The concepts you learn here will port over directly to the playbook language. Before reading and executing these examples, please read :ref:`intro_inventory`." -msgstr "Ansible アドホックコマンドは、`/usr/bin/ansible` コマンドラインツールを使用して、1 つまたは複数の管理ノード上の単一タスクを自動化します。アドホックコマンドは素早く簡単に実行できますが、再利用はできません。では、なぜ最初にアドホックコマンドを学ぶのかというと、アドホックコマンドは Ansible の簡易さと性能を実証するものだからです。ここで学んだ概念は、そのまま Playbook 言語に移植されます。これらの例を読んで実行する前に、「:ref:`intro_inventory`」を参照してください。" - -#: ../../rst/command_guide/intro_adhoc.rst:18 -msgid "Why use ad hoc commands?" -msgstr "アドホックコマンドを使用する理由" - -#: ../../rst/command_guide/intro_adhoc.rst:20 -msgid "ad hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad hoc command looks like this:" -msgstr "アドホックコマンドは、めったに繰り返さないタスクに最適です。たとえば、クリスマス休暇中に研究室のすべてのマシンの電源を切りたい場合は、Playbook を作成せず、Ansible で 1 行の簡単なコマンドを実行できます。アドホックコマンドは次のようなものです。" - -#: ../../rst/command_guide/intro_adhoc.rst:26 -msgid "The ``-a`` option accepts options either through the ``key=value`` syntax or a JSON string starting with ``{`` and ending with ``}`` for more complex option structure. You can learn more about :ref:`patterns` and :ref:`modules` on other pages." -msgstr "``-a`` オプションは、``key=value`` 構文または、``{`` で開始して ``}`` で終わる Json 文字列 (複雑なオプション構造向け) のいずれかを使用できます。他のページで :ref:`patterns` および :ref:`modules` について確認できます。" - -#: ../../rst/command_guide/intro_adhoc.rst:30 -msgid "Use cases for ad hoc tasks" -msgstr "アドホックタスクのユースケース" - -#: ../../rst/command_guide/intro_adhoc.rst:32 -msgid "ad hoc tasks can be used to reboot servers, copy files, manage packages and users, and much more. You can use any Ansible module in an ad hoc task. ad hoc tasks, like playbooks, use a declarative model, calculating and executing the actions required to reach a specified final state. They achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state." -msgstr "アドホックタスクは、サーバーの再起動、ファイルのコピー、パッケージやユーザーの管理など、さまざまな用途に使用できます。Ansible モジュールはアドホックタスクで使用できます。アドホックタスクは、Playbook と同様に、宣言型モデルを使用し、指定された最終状態に到達するために必要なアクションを計算して実行します。アドホックタスクは、開始前に現在の状態をチェックし、現在の状態が指定された最終状態と異なる場合を除いて何もしないことで、一種の冪等性を実現しています。" - -#: ../../rst/command_guide/intro_adhoc.rst:37 -msgid "Rebooting servers" -msgstr "サーバーの再起動" - -#: ../../rst/command_guide/intro_adhoc.rst:39 -msgid "The default module for the ``ansible`` command-line utility is the :ref:`ansible.builtin.command module`. You can use an ad hoc task to call the command module and reboot all web servers in Atlanta, 10 at a time. Before Ansible can do this, you must have all servers in Atlanta listed in a group called [atlanta] in your inventory, and you must have working SSH credentials for each machine in that group. To reboot all the servers in the [atlanta] group:" -msgstr "``ansible`` コマンドラインユーティリティーのデフォルトモジュールは、:ref:`ansible.builtin.command モジュール` です。アドホックタスクを使用してコマンドモジュールを呼び出し、Atlanta のすべての Web サーバを一度に 10 台ずつ再起動することができます。Ansible がこれを行う前に、インベントリー内の [atlanta] というグループに Atlanta にあるすべてのサーバーが記載されている必要があり、そのグループ内の各マシンの SSH 認証情報が有効でなければなりません。[atlanta] グループのすべてのサーバーを再起動するには、次のようにします。" - -#: ../../rst/command_guide/intro_adhoc.rst:45 -msgid "By default Ansible uses only 5 simultaneous processes. If you have more hosts than the value set for the fork count, Ansible will talk to them, but it will take a little longer. To reboot the [atlanta] servers with 10 parallel forks:" -msgstr "デフォルトでは、Ansible は 5 つの同時プロセスのみを使用します。フォーク数に設定された値よりも多くのホストがある場合、Ansible はそれらのホストと対話しますが、少し時間がかかります。10 個の並列フォークで [atlanta] サーバーを再起動する場合は、以下のようにします。" - -#: ../../rst/command_guide/intro_adhoc.rst:51 -msgid "/usr/bin/ansible will default to running from your user account. To connect as a different user:" -msgstr "usr/bin/ansible はデフォルトで自身のユーザーアカウントから実行されます。別のユーザーとして接続するには、以下を行います。" - -#: ../../rst/command_guide/intro_adhoc.rst:57 -msgid "Rebooting probably requires privilege escalation. You can connect to the server as ``username`` and run the command as the ``root`` user by using the :ref:`become ` keyword:" -msgstr "再起動には、おそらく権限昇格が必要です。``username`` としてサーバーに接続し、:ref:`become ` キーワードを使用して ``root`` ユーザーとしてコマンドを実行できます。" - -#: ../../rst/command_guide/intro_adhoc.rst:63 -msgid "If you add ``--ask-become-pass`` or ``-K``, Ansible prompts you for the password to use for privilege escalation (sudo/su/pfexec/doas/etc)." -msgstr "``--ask-become-pass`` または ``-K`` を追加します。Ansible により、権限昇格に使用するパスワード (sudo/su/pfexec/doas など) の入力が求められます。" - -#: ../../rst/command_guide/intro_adhoc.rst:66 -msgid "The :ref:`command module ` does not support extended shell syntax like piping and redirects (although shell variables will always work). If your command requires shell-specific syntax, use the `shell` module instead. Read more about the differences on the :ref:`working_with_modules` page." -msgstr ":ref:`command モジュール ` は、piping や redirects のような拡張シェル構文をサポートしていません (ただし、シェル変数は常に動作します)。シェル特有の構文を必要とするコマンドの場合は、代わりに `shell` モジュールを使用してください。その違いについては「:ref:`working_with_modules`」のページをご覧ください。" - -#: ../../rst/command_guide/intro_adhoc.rst:71 -msgid "So far all our examples have used the default 'command' module. To use a different module, pass ``-m`` for module name. For example, to use the :ref:`ansible.builtin.shell module `:" -msgstr "この例では、デフォルトの「command」モジュールを使用しています。別のモジュールを使用するには、モジュール名に ``-m`` を渡します。たとえば、:ref:`ansible.builtin.shell モジュール ` を使用します。" - -#: ../../rst/command_guide/intro_adhoc.rst:77 -msgid "When running any command with the Ansible *ad hoc* CLI (as opposed to :ref:`Playbooks `), pay particular attention to shell quoting rules, so the local shell retains the variable and passes it to Ansible. For example, using double rather than single quotes in the above example would evaluate the variable on the box you were on." -msgstr "(:ref:`Playbooks ` とは異なり) Ansible の *アドホック* CLI を使用してコマンドを実行する場合は、ローカルシェルが変数を保持して Ansible に渡すように、シェルの引用規則に特に注意してください。たとえば、上記の例で一重引用符ではなく二重引用符を使用すると、指定しているそのボックスの変数が評価されます。" - -#: ../../rst/command_guide/intro_adhoc.rst:86 -msgid "Managing files" -msgstr "ファイルの管理" - -#: ../../rst/command_guide/intro_adhoc.rst:88 -msgid "An ad hoc task can harness the power of Ansible and SCP to transfer many files to multiple machines in parallel. To transfer a file directly to all servers in the [atlanta] group:" -msgstr "アドホックタスクでは、Ansible と SCP の力を利用して、多数のファイルを複数のマシンに並行して転送することができます。[atlanta] グループのすべてのサーバーに直接ファイルを転送するには、次のようにします。" - -#: ../../rst/command_guide/intro_adhoc.rst:94 -msgid "If you plan to repeat a task like this, use the :ref:`ansible.builtin.template` module in a playbook." -msgstr "このようなタスクを繰り返す場合は、Playbook で :ref:`ansible.builtin.template` モジュールを使用します。" - -#: ../../rst/command_guide/intro_adhoc.rst:96 -msgid "The :ref:`ansible.builtin.file` module allows changing ownership and permissions on files. These same options can be passed directly to the ``copy`` module as well:" -msgstr ":ref:`ansible.builtin.file` モジュールにより、ファイルの所有権およびパーミッションを変更できます。同じオプションを ``copy`` モジュールに直接渡すことができます。" - -#: ../../rst/command_guide/intro_adhoc.rst:104 -msgid "The ``file`` module can also create directories, similar to ``mkdir -p``:" -msgstr "``file`` モジュールは、``mkdir -p`` と同様、ディレクトリーも作成できます。" - -#: ../../rst/command_guide/intro_adhoc.rst:110 -msgid "As well as delete directories (recursively) and delete files:" -msgstr "ディレクトリーを (再帰的に) 削除し、ファイルを削除します。" - -#: ../../rst/command_guide/intro_adhoc.rst:119 -msgid "Managing packages" -msgstr "パッケージの管理" - -#: ../../rst/command_guide/intro_adhoc.rst:121 -msgid "You might also use an ad hoc task to install, update, or remove packages on managed nodes using a package management module such as ``yum``. Package management modules support common functions to install, remove, and generally manage packages. Some specific functions for a package manager might not be present in the Ansible module since they are not part of general package management." -msgstr "また、アドホックタスクを使用して、``yum`` などのパッケージ管理モジュールを使用して、管理対象ノードにパッケージをインストール、更新、または削除することもできます。パッケージ管理モジュールは、パッケージのインストール、削除、および一般的な管理を行う一般的な機能をサポートします。パッケージマネージャーの特定の機能によっては、一般的なパッケージ管理に含まれていないので、Ansible モジュールには存在しない可能性があります。" - -#: ../../rst/command_guide/intro_adhoc.rst:123 -msgid "To ensure a package is installed without updating it:" -msgstr "パッケージを更新せずにインストールできるようにするには、次のコマンドを実行します。" - -#: ../../rst/command_guide/intro_adhoc.rst:129 -msgid "To ensure a specific version of a package is installed:" -msgstr "パッケージの特定バージョンがインストールされていることを確認するには、次のコマンドを実行します。" - -#: ../../rst/command_guide/intro_adhoc.rst:135 -msgid "To ensure a package is at the latest version:" -msgstr "パッケージが最新バージョンであることを確認するには、次のコマンドを実行します。" - -#: ../../rst/command_guide/intro_adhoc.rst:141 -msgid "To ensure a package is not installed:" -msgstr "パッケージがインストールされていないことを確認するには、次のコマンドを実行します。" - -#: ../../rst/command_guide/intro_adhoc.rst:147 -msgid "Ansible has modules for managing packages under many platforms. If there is no module for your package manager, you can install packages using the command module or create a module for your package manager." -msgstr "Ansible には、多くのプラットフォームでパッケージを管理するためのモジュールが用意されています。お使いのパッケージマネージャー用のモジュールがない場合は、コマンドモジュールを使用してパッケージをインストールするか、パッケージマネージャー用のモジュールを作成してください。" - -#: ../../rst/command_guide/intro_adhoc.rst:152 -msgid "Managing users and groups" -msgstr "ユーザーおよびグループの管理" - -#: ../../rst/command_guide/intro_adhoc.rst:154 -msgid "You can create, manage, and remove user accounts on your managed nodes with ad hoc tasks:" -msgstr "アドホックタスクを使用すると、管理ノードでユーザーアカウントを作成、管理、および削除できます。" - -#: ../../rst/command_guide/intro_adhoc.rst:162 -msgid "See the :ref:`ansible.builtin.user ` module documentation for details on all of the available options, including how to manipulate groups and group membership." -msgstr "グループやグループメンバーシップの操作方法など、利用可能なすべてのオプションの詳細は、:ref:`ansible.builtin.user ` モジュールのドキュメントを参照してください。" - -#: ../../rst/command_guide/intro_adhoc.rst:168 -msgid "Managing services" -msgstr "サービスの管理" - -#: ../../rst/command_guide/intro_adhoc.rst:170 -msgid "Ensure a service is started on all webservers:" -msgstr "サービスがすべての Web サーバーで起動していることを確認します。" - -#: ../../rst/command_guide/intro_adhoc.rst:176 -msgid "Alternatively, restart a service on all webservers:" -msgstr "または、すべての Web サーバーでサービスを再起動します。" - -#: ../../rst/command_guide/intro_adhoc.rst:182 -msgid "Ensure a service is stopped:" -msgstr "サービスが停止していることを確認します。" - -#: ../../rst/command_guide/intro_adhoc.rst:191 -msgid "Gathering facts" -msgstr "ファクトの収集" - -#: ../../rst/command_guide/intro_adhoc.rst:193 -msgid "Facts represent discovered variables about a system. You can use facts to implement conditional execution of tasks but also just to get ad hoc information about your systems. To see all facts:" -msgstr "ファクトは、検出されたシステムに関する変数を表します。ファクトを使用して、タスクの条件付き実行を実装することもできますが、システムに関するアドホック情報を取得することもできます。すべてのファクトを表示するには、以下を実行します。" - -#: ../../rst/command_guide/intro_adhoc.rst:199 -msgid "You can also filter this output to display only certain facts, see the :ref:`ansible.builtin.setup ` module documentation for details." -msgstr "この出力をフィルターで絞り込んで、特定のファクトのみを表示することもできます。詳細は :ref:`ansible.builtin.setup ` モジュールのドキュメントを参照してください。" - -#: ../../rst/command_guide/intro_adhoc.rst:202 -msgid "Patterns and ad-hoc commands" -msgstr "パターンおよびアドホックコマンド" - -#: ../../rst/command_guide/intro_adhoc.rst:204 -msgid "See the :ref:`patterns ` documentation for details on all of the available options, including how to limit using patterns in ad-hoc commands." -msgstr "アドホックコマンドでパターンの使用を制限する方法など、利用可能なすべてのオプションの詳細は、:ref:`patterns ` のドキュメントを参照してください。" - -#: ../../rst/command_guide/intro_adhoc.rst:207 -msgid "Now that you understand the basic elements of Ansible execution, you are ready to learn to automate repetitive tasks using :ref:`Ansible Playbooks `." -msgstr "これで、Ansible を実行する基本要素を理解し、:ref:`Ansible Playbook ` を使用して反復タスクを自動化する方法を学ぶ準備が整いました。" - -#: ../../rst/command_guide/intro_adhoc.rst:211 -msgid ":ref:`intro_configuration`" -msgstr ":ref:`intro_configuration`" - -#: ../../rst/command_guide/intro_adhoc.rst:212 -msgid "All about the Ansible config file" -msgstr "Ansible 設定ファイルの詳細" - -#: ../../rst/command_guide/intro_adhoc.rst:213 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/command_guide/intro_adhoc.rst:214 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/command_guide/intro_adhoc.rst:215 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/command_guide/intro_adhoc.rst:216 -msgid "Using Ansible for configuration management & deployment" -msgstr "設定管理およびデプロイメントに Ansible の使用" - -#: ../../rst/command_guide/intro_adhoc.rst:217 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/command_guide/intro_adhoc.rst:218 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/command_guide/intro_adhoc.rst:219 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/command_guide/intro_adhoc.rst:220 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/community.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/community.po deleted file mode 100644 index f634ad2b06e..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/community.po +++ /dev/null @@ -1,6755 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/community/advanced_index.rst:5 -msgid "Advanced Contributor Guide" -msgstr "詳細なコントリビューターガイド" - -#: ../../rst/community/advanced_index.rst:7 -msgid "This guide focuses on contributors who are committers, GitHub admins, or release managers." -msgstr "本書は、コミット担当者、GitHub 管理者、またはリリースマネージャーであるコントリビューターを対象としています。" - -#: ../../rst/community/code_of_conduct.rst:5 -msgid "Community Code of Conduct" -msgstr "コミュニティーの行動規範" - -#: ../../rst/community/code_of_conduct.rst:7 -#: ../../rst/community/github_admins.rst:7 -#: ../../rst/community/release_managers.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/community/code_of_conduct.rst:9 -msgid "Every community can be strengthened by a diverse variety of viewpoints, insights, opinions, skillsets, and skill levels. However, with diversity comes the potential for disagreement and miscommunication. The purpose of this Code of Conduct is to ensure that disagreements and differences of opinion are conducted respectfully and on their own merits, without personal attacks or other behavior that might create an unsafe or unwelcoming environment." -msgstr "すべてのコミュニティーは、多様な視点、洞察力、意見、スキルセット、スキルレベルの多様性によって強化されます。しかし、多様性には、意見の相違や誤解が生じる可能性があります。この行動規範の目的は、意見の不一致や相違が、個人的な攻撃やその他の不安定な環境や歓迎されない環境を作り出すような行動をせずに、敬意を持って、各自の利点に基づいて行われるようにすることです。" - -#: ../../rst/community/code_of_conduct.rst:16 -msgid "These policies are not designed to be a comprehensive set of Things You Cannot Do. We ask that you treat your fellow community members with respect and courtesy, and in general, Don't Be A Jerk. This Code of Conduct is meant to be followed in spirit as much as in letter and is not exhaustive." -msgstr "これらの方針は、「やってはいけないこと」を網羅したものではありません。コミュニティーメンバーに敬意と礼儀をもって接し、不快な行動はしないことをお願いしています。この行動規範は、心構えをできる限り示すことを目的としており、すべてを網羅しているわけではありません。" - -#: ../../rst/community/code_of_conduct.rst:21 -msgid "All Ansible events and participants therein are governed by this Code of Conduct and anti-harassment policy. We expect organizers to enforce these guidelines throughout all events, and we expect attendees, speakers, sponsors, and volunteers to help ensure a safe environment for our whole community. Specifically, this Code of Conduct covers participation in all Ansible-related forums and mailing lists, code and documentation contributions, public chat (Matrix, IRC), private correspondence, and public meetings." -msgstr "Ansible イベントとその参加者はすべて、この行動規範とハラスメント防止ポリシーに従う必要があります。主催者は、常にこのガイドラインに沿ってイベントを開催することが期待されます。また、参加者、講演者、スポンサー、およびボランティアの皆様には、コミュニティー全体の安全な環境を確保するためにご協力いただくことが期待されます。具体的には、この行動規範は、Ansible 関連のフォーラムやメーリングリストへの参加、コードやドキュメントへの貢献、公開チャット (Matrix、IRC) への参加、プライベートなやり取り、公開会議への参加が対象となります。" - -#: ../../rst/community/code_of_conduct.rst:28 -msgid "Ansible community members are..." -msgstr "Ansible コミュニティーのメンバーには、以下が期待されます。" - -#: ../../rst/community/code_of_conduct.rst:30 -msgid "**Considerate**" -msgstr "**思いやりをもつ**" - -#: ../../rst/community/code_of_conduct.rst:32 -msgid "Contributions of every kind have far-ranging consequences. Just as your work depends on the work of others, decisions you make surrounding your contributions to the Ansible community will affect your fellow community members. You are strongly encouraged to take those consequences into account while making decisions." -msgstr "あらゆる種類の貢献が、広範囲に影響します。自分の仕事が他の人の仕事に依存しているのと同じように、Ansible コミュニティーへの貢献についてあなたが下した決定は、コミュニティーメンバーに影響します。意思決定を行う際には、このような結果を考慮に入れることが強く推奨されます。" - -#: ../../rst/community/code_of_conduct.rst:37 -msgid "**Patient**" -msgstr "**寛大になる**" - -#: ../../rst/community/code_of_conduct.rst:39 -msgid "Asynchronous communication can come with its own frustrations, even in the most responsive of communities. Please remember that our community is largely built on volunteered time, and that questions, contributions, and requests for support may take some time to receive a response. Repeated \"bumps\" or \"reminders\" in rapid succession are not good displays of patience. Additionally, it is considered poor manners to ping a specific person with general questions. Pose your question to the community as a whole, and wait patiently for a response." -msgstr "非同期のコミュニケーションは、どんなに反応の良いコミュニティーであっても、ある程度はフラストレーションが溜まってしまうことがあります。コミュニティーは主にボランティアの時間で成り立っていることを覚えておいてください。質問、貢献、サポートのリクエストには返事が返ってくるまでに時間がかかることがあります。何度も「スレッド作成 (bump)」や「リマインダー」を繰り返すのは、忍耐力を示す優れた方法ではありません。さらに、一般的な質問を特定の人にするのはマナー違反です。コミュニティー全体に向けて質問し、辛抱強く返事を待ちましょう。" - -#: ../../rst/community/code_of_conduct.rst:47 -msgid "**Respectful**" -msgstr "**相手を尊重する**" - -#: ../../rst/community/code_of_conduct.rst:49 -msgid "Every community inevitably has disagreements, but remember that it is possible to disagree respectfully and courteously. Disagreements are never an excuse for rudeness, hostility, threatening behavior, abuse (verbal or physical), or personal attacks." -msgstr "どのようなコミュニティーでも意見の相違は避けられませんが、異議を唱えるときは敬意を持って礼儀正しく行う必要があることを覚えておいてください。意見の相違は、失礼、敵意、脅迫、(言葉によるまたは身体的な) 虐待、または個人的な攻撃の言い訳にはなりません。" - -#: ../../rst/community/code_of_conduct.rst:53 -msgid "**Kind**" -msgstr "**親切にする**" - -#: ../../rst/community/code_of_conduct.rst:55 -msgid "Everyone should feel welcome in the Ansible community, regardless of their background. Please be courteous, respectful and polite to fellow community members. Do not make or post offensive comments related to skill level, gender, gender identity or expression, sexual orientation, disability, physical appearance, body size, race, or religion. Sexualized images or imagery, real or implied violence, intimidation, oppression, stalking, sustained disruption of activities, publishing the personal information of others without explicit permission to do so, unwanted physical contact, and unwelcome sexual attention are all strictly prohibited. Additionally, you are encouraged not to make assumptions about the background or identity of your fellow community members." -msgstr "Ansible コミュニティーでは、各自の経歴に関係なく誰もが歓迎されていると感じるようにならなければなりません。コミュニティーメンバーに対しては、礼儀正しく、敬意を払って接してください。スキルレベル、性別、性自認、性表現、性的指向、障害、容姿、体格、人種、宗教に関する攻撃的なコメントをしたり、投稿したりしないでください。性的画像、明示的または暗示的な暴力、脅迫、抑圧、ストーカー行為、継続的な活動妨害、明示的な許可なく個人情報の公開、望まれない身体的接触、歓迎されない性的注目は、すべて固く禁じられています。さらに、コミュニティーメンバーの経歴や身元を推測しないようにしてください。" - -#: ../../rst/community/code_of_conduct.rst:65 -msgid "**Inquisitive**" -msgstr "**探求心を持つ**" - -#: ../../rst/community/code_of_conduct.rst:67 -msgid "The only stupid question is the one that does not get asked. We encourage our users to ask early and ask often. Rather than asking whether you can ask a question (the answer is always yes!), instead, simply ask your question. You are encouraged to provide as many specifics as possible. Code snippets in the form of Gists or other paste site links are almost always needed in order to get the most helpful answers. Refrain from pasting multiple lines of code directly into the chat channels - instead use gist.github.com or another paste site to provide code snippets." -msgstr "取るに足らない質問とは、質問されない質問だけです。コミュニティーメンバーは、早めに、そして頻繁に質問することが推奨されます。質問ができるかどうかを尋ねるのではなく (その答えは常にイエスとなるため)、質問したい内容を尋ねてください。できるだけ具体的な情報を提供することが推奨されます。最も有益な回答を得るには、Gist などのサイトへ抜粋したコードを貼り付け、そのリンクを示してください。つまり、チャットチャンネルに、複数行のコードを直接貼り付けず、代わりに gist.github.com などのサイトに該当のコードを貼り付けて、そのサイトへのリンクを示してください。" - -#: ../../rst/community/code_of_conduct.rst:75 -msgid "**Helpful**" -msgstr "**助けになること**" - -#: ../../rst/community/code_of_conduct.rst:77 -msgid "The Ansible community is committed to being a welcoming environment for all users, regardless of skill level. We were all beginners once upon a time, and our community cannot grow without an environment where new users feel safe and comfortable asking questions. It can become frustrating to answer the same questions repeatedly; however, community members are expected to remain courteous and helpful to all users equally, regardless of skill or knowledge level. Avoid providing responses that prioritize snideness and snark over useful information. At the same time, everyone is expected to read the provided documentation thoroughly. We are happy to answer questions, provide strategic guidance, and suggest effective workflows, but we are not here to do your job for you." -msgstr "Ansible コミュニティーは、スキルレベルに関係なく、誰にとっても歓迎されていると感じる環境であることをお約束します。すべての人は皆、最初は初心者でした。新しいユーザーが安心して質問できる環境でなければコミュニティーは成長しません。同じ質問に何度も答えることにもどかしさを感じることもありますが、スキルや知識のレベルに関係なく、すべてのユーザーに対して平等に礼儀正しく、親切に対応することが求められます。有益な情報よりも、中傷や悪口を優先するような回答は避けてください。同時に、全てのメンバーが、提供された文書を十分に読むことが期待されています。コミュニティーメンバーは、質問に答えたり、戦略的なガイダンスを提供したり、効果的なワークフローを提案したりすることは喜んで行いますが、質問者の代わりに作業をするために存在しているわけではありません。" - -#: ../../rst/community/code_of_conduct.rst:88 -msgid "Anti-harassment policy" -msgstr "ハラスメント防止ポリシー" - -#: ../../rst/community/code_of_conduct.rst:90 -msgid "Harassment includes (but is not limited to) all of the following behaviors:" -msgstr "ハラスメントには、次のすべての行為が含まれます (ただし、これらに限定されません)。" - -#: ../../rst/community/code_of_conduct.rst:92 -msgid "Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion" -msgstr "性別 (性表現や性自認を含む)、年齢、性的指向、障害、容姿、体格、人種、および宗教に関する侮辱的なコメント" - -#: ../../rst/community/code_of_conduct.rst:93 -msgid "Derogatory terminology including words commonly known to be slurs" -msgstr "一般的に中傷として知られている単語を含む軽蔑的な用語" - -#: ../../rst/community/code_of_conduct.rst:94 -msgid "Posting sexualized images or imagery in public spaces" -msgstr "性的な画像または比喩を公共スペースに投稿すること" - -#: ../../rst/community/code_of_conduct.rst:95 -msgid "Deliberate intimidation" -msgstr "意図的な脅迫" - -#: ../../rst/community/code_of_conduct.rst:96 -msgid "Stalking" -msgstr "ストーキング" - -#: ../../rst/community/code_of_conduct.rst:97 -msgid "Posting others' personal information without explicit permission" -msgstr "明示的な許可なく他人の個人情報を掲載する行為" - -#: ../../rst/community/code_of_conduct.rst:98 -msgid "Sustained disruption of talks or other events" -msgstr "会話やその他のイベントの継続的な妨害" - -#: ../../rst/community/code_of_conduct.rst:99 -msgid "Inappropriate physical contact" -msgstr "不適切な身体的接触" - -#: ../../rst/community/code_of_conduct.rst:100 -msgid "Unwelcome sexual attention" -msgstr "歓迎されない性的注目" - -#: ../../rst/community/code_of_conduct.rst:102 -msgid "Participants asked to stop any harassing behavior are expected to comply immediately. Sponsors are also subject to the anti-harassment policy. In particular, sponsors should not use sexualized images, activities, or other material. Meetup organizing staff and other volunteer organizers should not use sexualized attire or otherwise create a sexualized environment at community events." -msgstr "ハラスメント行為を止めるように求められた参加者は、直ちにこれに応じることが求められます。スポンサーも、ハラスメント防止ポリシーの対象となります。特に、スポンサーは性的な画像、活動、その他の素材を使用してはなりません。また、Meetup の主催者やボランティアスタッフは、コミュニティーイベントで性的な恰好をしたり、性的な環境を作らないようにする必要があります。" - -#: ../../rst/community/code_of_conduct.rst:108 -msgid "In addition to the behaviors outlined above, continuing to behave a certain way after you have been asked to stop also constitutes harassment, even if that behavior is not specifically outlined in this policy. It is considerate and respectful to stop doing something after you have been asked to stop, and all community members are expected to comply with such requests immediately." -msgstr "上記の行動に加えて、ここで明記されていなくても、やめるように言われた後にそのような行動を続けることも、ハラスメントに該当します。やめるように言われた後に何かをやめることは、思いやりと敬意を表す行動であり、コミュニティーの全メンバーは、そのような要求に直ちに従うことが求められます。" - -#: ../../rst/community/code_of_conduct.rst:115 -msgid "Policy violations" -msgstr "ポリシー違反" - -#: ../../rst/community/code_of_conduct.rst:117 -msgid "Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting `codeofconduct@ansible.com `_, to anyone with administrative power in community chat (Admins or Moderators on Matrix, ops on IRC), or to the local organizers of an event. Meetup organizers are encouraged to prominently display points of contact for reporting unacceptable behavior at local events." -msgstr "虐待、嫌がらせ、その他の容認できない行為があった場合は、`codeofconduct@ansible.com `_ や、コミュニティーのチャットで管理権限を持つ者(MatrixのAdminsやModerators、IRCのops)、各地のイベント主催者に連絡してください。Meetup の主催者は、各地のイベントで容認されない行動を報告する連絡先を目立つところに表示することが推奨されます。" - -#: ../../rst/community/code_of_conduct.rst:122 -msgid "If a participant engages in harassing behavior, the meetup organizers may take any action they deem appropriate. These actions may include but are not limited to warning the offender, expelling the offender from the event, and barring the offender from future community events." -msgstr "Meetup 主催者は、参加者が嫌がらせ行為を行った場合、適切と思われる措置を取ることができます。このような措置には、加害者への警告、イベントからの退出を求めること、今後のコミュニティーイベントへの参加禁止などが含まれますが、これらに限定されません。" - -#: ../../rst/community/code_of_conduct.rst:127 -msgid "Organizers will be happy to help participants contact security or local law enforcement, provide escorts to an alternate location, or otherwise assist those experiencing harassment to feel safe for the duration of the meetup. We value the safety and well-being of our community members and want everyone to feel welcome at our events, both online and offline." -msgstr "主催者は、ハラスメントを経験した人が Meetup の間安心して過ごせるように、参加者が警備員や地元の警察に連絡したり、別の場所に案内したりなど支援します。コミュニティーは、コミュニティーメンバーの安全と幸福を大切にし、オンラインとオフラインの両方で開催されるイベントですべての人が歓迎されていると感じてほしいと願っています。" - -#: ../../rst/community/code_of_conduct.rst:133 -msgid "We expect all participants, organizers, speakers, and attendees to follow these policies at all of our event venues and event-related social events." -msgstr "すべての参加者、主催者、講演者、参加者は、コミュニティーのイベント会場およびイベント関連のソーシャルイベントにおいて、これらのポリシーに従うことを期待しています。" - -#: ../../rst/community/code_of_conduct.rst:136 -msgid "The Ansible Community Code of Conduct is licensed under the Creative Commons Attribution-Share Alike 3.0 license. Our Code of Conduct was adapted from Codes of Conduct of other open source projects, including:" -msgstr "Ansible コミュニティー行動規範は、Creative Commons Attribution-Share Alike 3.0 ライセンスの認可を受けています。私たちの行動規範は、以下のような他のオープンソースプロジェクトの行動規範を参考にしています。" - -#: ../../rst/community/code_of_conduct.rst:140 -msgid "Contributor Covenant" -msgstr "Contributor Covenant" - -#: ../../rst/community/code_of_conduct.rst:141 -msgid "Elastic" -msgstr "Elastic" - -#: ../../rst/community/code_of_conduct.rst:142 -msgid "The Fedora Project" -msgstr "The Fedora Project" - -#: ../../rst/community/code_of_conduct.rst:143 -msgid "OpenStack" -msgstr "OpenStack" - -#: ../../rst/community/code_of_conduct.rst:144 -msgid "Puppet Labs" -msgstr "Puppet Labs" - -#: ../../rst/community/code_of_conduct.rst:145 -msgid "Ubuntu" -msgstr "Ubuntu" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:4 -msgid "Understanding integration tests" -msgstr "統合テストについて" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:8 -msgid "Some collections do not have integration tests." -msgstr "一部のコレクションには統合テストがありません。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:10 -msgid "Integration tests are functional tests of modules and plugins. With integration tests, we check if a module or plugin satisfies its functional requirements. Simply put, we check that features work as expected and users get the outcome described in the module or plugin documentation." -msgstr "統合テストは、モジュールおよびプラグインの機能テストです。統合テストでは、モジュールまたはプラグインが機能要件を満たしているかどうかを確認します。簡単に言うと、機能が期待どおりに動作し、ユーザーがモジュールまたはプラグインのドキュメントに記載されている結果を得ているかどうかを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:13 -msgid "There are :ref:`two kinds of integration tests ` used in collections:" -msgstr "コレクションには :ref:`two kinds of integration tests ` が使用されます。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:15 -msgid "integration tests that use Ansible roles" -msgstr "Ansible ロールを使用する統合テスト。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:16 -msgid "integration tests that use ``runme.sh``." -msgstr "``runme.sh`` を使用する統合テスト。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:18 -msgid "This section focuses on integration tests that use Ansible roles." -msgstr "本セクションでは、Ansible ロールを使用する統合テストに重点を置いています。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:20 -msgid "Integration tests check modules with playbooks that invoke those modules. The tests pass standalone parameters and their combinations, check what the module or plugin reports with the :ref:`assert ` module, and the actual state of the system after each task." -msgstr "統合テストは、モジュールを呼び出す Playbook を使ってモジュールを確認します。テストは、スタンドアロンパラメーターとその組み合わせを渡し、:ref:`assert ` モジュールでモジュールまたはプラグインが報告する内容と、各タスクの後のシステムの実際の状態を確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:23 -msgid "Integration test example" -msgstr "統合テストの例" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:25 -msgid "Let's say we want to test the ``postgresql_user`` module invoked with the ``name`` parameter. We expect that the module will both create a user based on the provided value of the ``name`` parameter and will report that the system state has changed. We cannot rely on only what the module reports. To be sure that the user has been created, we query our database with another module to see if the user exists." -msgstr "``name`` パラメーターで呼び出された ``postgresql_user`` モジュールをテストするとします。モジュールが提供された ``name`` パラメーターの値に基づいてユーザーを作成し、システム状態が変更されたことを報告することを想定します。モジュールが報告する内容だけを信頼することはできません。ユーザーが作成されたことを確認するために、別のモジュールでデータベースにクエリーを実行し、ユーザーが存在するかどうかを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:51 -msgid "Details about integration tests" -msgstr "統合テストの詳細" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:53 -msgid "The basic entity of an Ansible integration test is a ``target``. The target is an :ref:`Ansible role ` stored in the ``tests/integration/targets`` directory of the collection repository. The target role contains everything that is needed to test a module." -msgstr "Ansible 統合テストの基本的なエンティティーは ``target`` です。ターゲットは、コレクションリポジトリーの ``tests/integration/targets`` ディレクトリーに保存される :ref:`Ansible role ` です。ターゲットロールには、モジュールのテストに必要なすべてのものが含まれます。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:55 -msgid "The names of targets contain the module or plugin name that they test. Target names that start with ``setup_`` are usually executed as dependencies before module and plugin targets start execution. See :ref:`collection_creating_integration_tests` for details." -msgstr "ターゲットの名前には、テストするモジュールまたはプラグイン名が含まれます。``setup_`` で始まるターゲット名は、通常、モジュールおよびプラグインターゲットの実行を開始する前に依存関係として実行されます。詳細は、「 :ref:`collection_creating_integration_tests` 」を参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:57 -msgid "To run integration tests, we use the ``ansible-test`` utility that is included in the ``ansible-core`` and ``ansible`` packages. See :ref:`collection_run_integration_tests` for details. After you finish your integration tests, see to :ref:`collection_quickstart` to learn how to submit a pull request." -msgstr "統合テストを実行するには、``ansible-core`` および ``ansible`` パッケージに含まれる ``ansible-test`` ユーティリティーを使用します。詳細は、:ref:`collection_run_integration_tests` を参照してください。統合テストが完了したら、:ref:`collection_quickstart` を参照し、プルリクエストを送信する方法を確認してください。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:62 -msgid "Preparing for integration tests for collections" -msgstr "コレクション用の統合テストの準備" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:64 -msgid "To prepare for developing integration tests:" -msgstr "統合テストの開発を準備するには、以下を行います。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:66 -msgid ":ref:`Set up your local environment `." -msgstr ":ref:`ローカル環境をセットアップします `。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:68 -msgid "Determine if integration tests already exist." -msgstr "統合テストがすでに存在しているかどうかを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:75 -msgid "If a collection already has integration tests, they are stored in ``tests/integration/targets/*`` subdirectories of the collection repository." -msgstr "コレクションにすでに統合テストがある場合、それらはコレクションリポジトリーの ``tests/integration/targets/*`` サブディレクトリーに保存されています。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:77 -msgid "If you use ``bash`` and the ``argcomplete`` package is installed with ``pip`` on your system, you can also get a full target list." -msgstr "``bash`` を使用し、``argcomplete`` パッケージが ``pip`` と共にシステムにインストールされている場合は、完全なターゲット一覧を取得することもできます。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:83 -msgid "Alternately, you can check if the ``tests/integration/targets`` directory contains a corresponding directory with the same name as the module. For example, the tests for the ``postgresql_user`` module of the ``community.postgresql`` collection are stored in the ``tests/integration/targets/postgresql_user`` directory of the collection repository. If there is no corresponding target there, then that module does not have integration tests. In this case, consider adding integration tests for the module. See :ref:`collection_creating_integration_tests` for details." -msgstr "または、``tests/integration/targets`` ディレクトリーに、モジュールと同じ名前の対応するディレクトリーが含まれているかどうかを確認することもできます。たとえば、``community.postgresql`` コレクションの ``postgresql_user`` モジュールのテストは、コレクションリポジトリーの ``tests/integration/targets/postgresql_user`` ディレクトリーに保存されます。対応するターゲットがそこにない場合は、そのモジュールには統合テストがありません。この場合は、そのモジュールに統合テストを追加することを検討してください。詳細は、:ref:`collection_creating_integration_tests` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:89 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:139 -msgid "Recommendations on coverage" -msgstr "カバレージに関する推奨事項" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:92 -msgid "Bugfixes" -msgstr "Bugfixes" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:94 -msgid "Before fixing code, create a test case in an :ref:`appropriate test target` that reproduces the bug provided by the issue reporter and described in the ``Steps to Reproduce`` issue section. :ref:`Run ` the tests." -msgstr "コードを修正する前に、:ref:`appropriate test target` でテストケースを作成します。これは、issue レポーターが提供するバグを再現し、``再現の手順`` issue セクションで説明されています。テストを :ref:`Run ` します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:96 -msgid "If you failed to reproduce the bug, ask the reporter to provide additional information. The issue may be related to environment settings. Sometimes specific environment issues cannot be reproduced in integration tests, in that case, manual testing by issue reporter or other interested users is required." -msgstr "バグの再現に失敗した場合は、追加情報を提供するようにレポーターに頼んでください。この問題は環境設定に関連している場合があります。特定の環境の issue は統合テストで再現できない場合もありますが、その場合は、issue レポーターまたは他の関心のあるユーザーによる手動テストが必要です。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:99 -msgid "Refactoring code" -msgstr "コードのリファクタリング" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:101 -msgid "When refactoring code, always check that related options are covered in a :ref:`corresponding test target`. Do not assume if the test target exists, everything is covered." -msgstr "コードをリファクタリングする場合は、関連オプションが :ref:`対応するテスト target` でカバーされていることを確認してください。テスト対象が存在すれば、すべてがカバーされているとは想定しないでください。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:106 -msgid "Covering modules / new features" -msgstr "モジュールおよび新機能のカバー" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:108 -msgid "When covering a module, cover all its options separately and their meaningful combinations. Every possible use of the module should be tested against:" -msgstr "モジュールをカバーするときは、そのすべてのオプションとそれらの意味のある組み合わせを個別にカバーしてください。考えられるすべてのモジュールの使用は、以下に対してテストする必要があります。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:110 -msgid "Idempotency - Does rerunning a task report no changes?" -msgstr "べき等 - タスクを再実行しても変更は報告されませんか?" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:111 -msgid "Check-mode - Does dry-running a task behave the same as a real run? Does it not make any changes?" -msgstr "チェックモード - タスクのドライランは実際の実行と同じように動作しますか? 変更はありませんか?" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:112 -msgid "Return values - Does the module return values consistently under different conditions?" -msgstr "戻り値 - モジュールはさまざまな条件下で一貫して値を返しますか?" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:114 -msgid "Each test action has to be tested at least the following times:" -msgstr "各テストアクションは、少なくとも以下の回数テストする必要があります。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:116 -msgid "Perform an action in check-mode if supported. This should indicate a change." -msgstr "サポートされている場合は、チェックモードでアクションを実行します。これにより、変更が示されるはずです。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:117 -msgid "Check with another module that the changes have ``not`` been actually made." -msgstr "別のモジュールで変更が実際に行われ ``not`` ことを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:118 -msgid "Perform the action for real. This should indicate a change." -msgstr "実際にアクションを実行します。これにより、変更が示されます。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:119 -msgid "Check with another module that the changes have been actually made." -msgstr "別のモジュールで変更が実際に行われていることを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:120 -msgid "Perform the action again in check-mode. This should indicate ``no`` change." -msgstr "チェックモードでアクションを再度実行します。これにより、``no`` の変更が示されるはずです。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:121 -msgid "Perform the action again for real. This should indicate ``no`` change." -msgstr "再度、アクションを実際に実行します。これにより、``no`` 変更が示されます。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:123 -msgid "To check a task:" -msgstr "タスクを確認するには、以下を実行します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:125 -msgid "Register the outcome of the task as a variable, for example, ``register: result``. Using the :ref:`assert ` module, check:" -msgstr "タスクの結果を変数として登録します（例: ``register: result``）。:ref:`assert ` モジュールを使用して、以下を確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:127 -msgid "If ``- result is changed`` or not." -msgstr "``- 結果が変更された`` かどうか。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:128 -msgid "Expected return values." -msgstr "想定される戻り値。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:130 -msgid "If the module changes the system state, check the actual system state using at least one other module. For example, if the module changes a file, we can check that the file has been changed by checking its checksum with the :ref:`stat ` module before and after the test tasks." -msgstr "モジュールがシステム状態を変更した場合は、少なくとも 1 つの他のモジュールを使用して実際のシステム状態を確認します。たとえば、モジュールがファイルを変更した場合は、テストタスクの前後に :ref:`stat ` モジュールでチェックサムをチェックし、ファイルが変更されたことを確認できます。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:131 -msgid "Run the same task with ``check_mode: true`` if check-mode is supported by the module. Check with other modules that the actual system state has not been changed." -msgstr "check-mode がモジュールでサポートされている場合は、``check_mode: true`` で同じタスクを実行します。実際のシステム状態が変更されていないことを他のモジュールで確認してください。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:132 -msgid "Cover cases when the module must fail. Use the ``ignore_errors: true`` option and check the returned message with the ``assert`` module." -msgstr "モジュールが失敗しなければならないケースをカバーします。``ignore_errors: true`` オプションを使用して、``assert`` モジュールで返されたメッセージを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:134 -msgid "Example:" -msgstr "例:" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:149 -msgid "Here is a summary:" -msgstr "以下は要約です。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:151 -msgid "Cover options and their sensible combinations." -msgstr "オプションとその適切な組み合わせをカバーします。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:152 -msgid "Check returned values." -msgstr "戻り値を確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:153 -msgid "Cover check-mode if supported." -msgstr "サポートされている場合は check-mode をカバーします。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:154 -msgid "Check a system state using other modules." -msgstr "他のモジュールを使用してシステムの状態を確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_about.rst:155 -msgid "Check when a module must fail and error messages." -msgstr "モジュールに障害が発生するタイミングとエラーメッセージを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:4 -msgid "Creating new integration tests" -msgstr "新しい統合テストの作成" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:6 -msgid "This section covers the following cases:" -msgstr "このセクションでは、以下をカバーします。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:8 -msgid "There are no integration tests for a collection or group of modules in a collection at all." -msgstr "コレクションやコレクション内のモジュールのグループに対する統合テストはいっさいありません。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:9 -msgid "You are adding a new module and you want to include integration tests." -msgstr "新しいモジュールを追加していて、統合テストを含めたい場合。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:10 -msgid "You want to add integration tests for a module that already exists without integration tests." -msgstr "統合テストのないすでに存在するモジュールに、統合テストを追加したい場合。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:12 -msgid "In other words, there are currently no tests for a module regardless of whether the module exists or not." -msgstr "つまり、モジュールが存在するかどうかに関わらず、モジュールのテストは現在ありません。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:14 -msgid "If the module already has tests, see :ref:`collection_updating_integration_tests`." -msgstr "モジュールにすでにテストがある場合は、:ref:`collection_updating_integration_tests` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:17 -msgid "Simplified example" -msgstr "簡素化された例" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:19 -msgid "Here is a simplified abstract example." -msgstr "以下は、簡略化された抽象例になります。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:21 -msgid "Let's say we are going to add integration tests to a new module in the ``community.abstract`` collection which interacts with some service." -msgstr "一部のサービスと対話する ``community.abstract`` コレクションの新しいモジュールに統合テストを追加するとします。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:23 -msgid "We :ref:`checked` and determined that there are no integration tests at all." -msgstr ":ref:`確認し`、統合テストはまったくないと判断しました。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:25 -msgid "We should basically do the following:" -msgstr "基本的には、以下を実施する必要があります。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:27 -msgid "Install and run the service with a ``setup`` target." -msgstr "``setup`` ターゲットでサービスをインストールし、実行します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:28 -msgid "Create a test target." -msgstr "テストターゲットを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:29 -msgid "Add integration tests for the module." -msgstr "モジュールの統合テストを追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:30 -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:84 -msgid ":ref:`Run the tests`." -msgstr ":ref:`Run the tests`。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:31 -msgid "Fix the code and tests as needed, run the tests again, and repeat the cycle until they pass." -msgstr "必要に応じてコードとテストを修正して、テストを再度実行し、合格するまでサイクルを繰り返します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:35 -msgid "You can reuse the ``setup`` target when implementing other targets that also use the same service." -msgstr "同じサービスを使用する他のターゲットを実装する場合に、``setup`` ターゲットを再利用できます。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:37 -msgid "Clone the collection to the ``~/ansible_collections/community.abstract`` directory on your local machine." -msgstr "コレクションをローカルマシンの ``~/ansible_collections/community.abstract`` ディレクトリーにクローンします。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:39 -msgid "From the ``~/ansible_collections/community.abstract`` directory, create directories for the ``setup`` target:" -msgstr "``~/ansible_collections/community.abstract`` ディレクトリーから、``setup`` ターゲットのディレクトリーを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:45 -msgid "Write all the tasks needed to prepare the environment, install, and run the service." -msgstr "環境を準備し、サービスをインストールして実行するために必要なすべてのタスクを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:47 -msgid "For simplicity, let's imagine that the service is available in the native distribution repositories and no sophisticated environment configuration is required." -msgstr "簡単にするために、サービスがネイティブ配布リポジトリーで利用可能であり、高度な環境設定が必要ないことを想像してみましょう。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:49 -msgid "Add the following tasks to the ``tests/integration/targets/setup_abstract_service/tasks/main.yml`` file to install and run the service:" -msgstr "以下のタスクを ``tests/integration/targets/setup_abstract_service/tasks/main.yml`` ファイルに追加して、サービスをインストールして実行します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:62 -msgid "This is a very simplified example." -msgstr "これは非常に単純化された例です。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:64 -msgid "Add the target for the module you are testing." -msgstr "テストしているモジュールのターゲットを追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:66 -msgid "Let's say the module is called ``abstract_service_info``. Create the following directory structure in the target:" -msgstr "モジュールが ``abstract_service_info`` と呼ばれるとします。ターゲットに以下のディレクトリー構造を作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:73 -msgid "Add all of the needed subdirectories. For example, if you are going to use defaults and files, add the ``defaults`` and ``files`` directories, and so on. The approach is the same as when you are creating a role." -msgstr "必要なサブディレクトリーをすべて追加します。たとえば、デフォルトとファイルを使用する場合は、``defaults`` ディレクトリーと ``files`` ディレクトリーなどを追加します。このアプローチは、ロールを作成するときと同じです。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:75 -msgid "To make the ``setup_abstract_service`` target run before the module's target, add the following lines to the ``tests/integration/targets/abstract_service_info/meta/main.yml`` file." -msgstr "モジュールのターゲットの前に ``setup_abstract_service`` ターゲットを実行するには、以下の行を ``tests/integration/targets/abstract_service_info/meta/main.yml`` ファイルに追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:82 -msgid "Start with writing a single stand-alone task to check that your module can interact with the service." -msgstr "単一のスタンドアロンタスクの作成から始めて、モジュールがサービスと対話できることを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:84 -msgid "We assume that the ``abstract_service_info`` module fetches some information from the ``abstract_service`` and that it has two connection parameters." -msgstr "``abstract_service_info`` モジュールは ``abstract_service`` から一部の情報を取得し、2 つの接続パラメーターがあることを前提としています。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:86 -msgid "Among other fields, it returns a field called ``version`` containing a service version." -msgstr "その他のフィールドの中から、サービスバージョンを含む ``version`` というフィールドが返されます。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:88 -msgid "Add the following to ``tests/integration/targets/abstract_service_info/tasks/main.yml``:" -msgstr "以下を ``tests/integration/targets/abstract_service_info/tasks/main.yml`` に追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:103 -msgid ":ref:`Run the tests` with the ``-vvv`` argument." -msgstr "``-vvv`` 引数の使用して :ref:`テストを実行します`。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:105 -msgid "If there are any issues with connectivity (for example, the service is not accepting connections) or with the code, the play will fail." -msgstr "接続に問題がある (たとえば、サービスが接続を許可しないなど) 場合や、コードに問題がある場合には、プレイは失敗します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:107 -msgid "Examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes." -msgstr "出力を調べて、障害が発生したステップを確認します。理由を調べて修正し、再実行してください。テストに合格するまでこのサイクルを繰り返します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:109 -msgid "If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage` section for details." -msgstr "テストに合格した場合は、追加のテストを作成します。詳細は、:ref:`カバレージに関する推奨事項` セクションを参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:112 -msgid "``community.postgresql`` example" -msgstr "``community.postgresql`` 例" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:114 -msgid "Here is a real example of writing integration tests from scratch for the ``community.postgresql.postgresql_info`` module." -msgstr "以下は、``community.postgresql.postgresql_info`` モジュール用に、統合テストをゼロから作成するための実際の例です。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:116 -msgid "For the sake of simplicity, we will create very basic tests which we will run using the Ubuntu 20.04 test container." -msgstr "簡単にするために、Ubuntu 20.04 テストコンテナーを使用して実行する非常に基本的なテストを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:118 -msgid "We use ``Linux`` as a work environment and have ``git`` and ``docker`` installed and running." -msgstr "作業環境として ``Linux`` を使用し、``git`` および ``docker`` がインストールされ、実行されています。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:120 -msgid "We also installed ``ansible-core``." -msgstr "``ansible-core`` もインストールされています。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:122 -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:22 -#: ../../rst/community/create_pr_quick_start.rst:23 -msgid "Create the following directories in your home directory:" -msgstr "以下のディレクトリーをホームディレクトリーに作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:128 -msgid "Fork the `collection repository `_ through the GitHub web interface." -msgstr "GitHub Web インターフェいスを介して `コレクションのリポジトリー `_ をフォークします。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:130 -#: ../../rst/community/create_pr_quick_start.rst:39 -msgid "Clone the forked repository from your profile to the created path:" -msgstr "プロファイルから作成されたパスに、フォークされたリポジトリーのクローンを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:136 -#: ../../rst/community/create_pr_quick_start.rst:45 -msgid "If you prefer to use the SSH protocol:" -msgstr "SSH プロトコルを使用する場合は以下を行います。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:142 -msgid "Go to the cloned repository:" -msgstr "クローンを作成したリポジトリーに移動します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:148 -msgid "Be sure you are in the default branch:" -msgstr "デフォルトのブランチにいることを確認します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:154 -msgid "Checkout a test branch:" -msgstr "テストブランチをチェックアウトします。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:160 -msgid "Since we already have tests for the ``postgresql_info`` module, we will run the following command:" -msgstr "``postgresql_info`` モジュールのテストがすでにあるため、以下のコマンドを実行します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:166 -msgid "With all of the targets now removed, the current state is as if we do not have any integration tests for the ``community.postgresql`` collection at all. We can now start writing integration tests from scratch." -msgstr "すべてのターゲットが削除されたため、現在の状態は ``community.postgresql`` コレクションの統合テストがまったくない場合と同様になります。統合テストをゼロから作成できるようになりました。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:168 -msgid "We will start with creating a ``setup`` target that will install all required packages and will launch PostgreSQL. Create the following directories:" -msgstr "まず、必要なすべてのパッケージをインストールし、PostgreSQL を起動する ``setup`` ターゲットの作成から開始します。以下のディレクトリーを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:174 -msgid "Create the ``tests/integration/targets/setup_postgresql_db/tasks/main.yml`` file and add the following tasks to it:" -msgstr "``tests/integration/targets/setup_postgresql_db/tasks/main.yml`` ファイルを作成し、以下のタスクを追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:196 -msgid "That is enough for our very basic example." -msgstr "ごく基本的な例ではこれで十分です。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:198 -msgid "Then, create the following directories for the ``postgresql_info`` target:" -msgstr "続いて、``postgresql_info`` ターゲットに以下のディレクトリーを作成します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:204 -msgid "To make the ``setup_postgresql_db`` target run before the ``postgresql_info`` target as a dependency, create the ``tests/integration/targets/postgresql_info/meta/main.yml`` file and add the following code to it:" -msgstr "``setup_postgresql_db`` ターゲットを依存関係として ``postgresql_info`` ターゲットの前に実行するには、``tests/integration/targets/postgresql_info/meta/main.yml`` ファイルを作成し、以下のコードを追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:211 -msgid "Now we are ready to add our first test task for the ``postgresql_info`` module. Create the ``tests/integration/targets/postgresql_info/tasks/main.yml`` file and add the following code to it:" -msgstr "これで、``postgresql_info`` モジュールの最初のテストタスクを追加する準備が整いました。``tests/integration/targets/postgresql_info/tasks/main.yml`` ファイルを作成し、以下のコードを追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:230 -msgid "In the first task, we run the ``postgresql_info`` module to fetch information from the database we installed and launched with the ``setup_postgresql_db`` target. We are saving the values returned by the module into the ``result`` variable." -msgstr "最初のタスクで、``postgresql_info`` モジュールを実行して、``setup_postgresql_db`` ターゲットでインストールして起動したデータベースから情報を取得します。モジュールにより返された値を ``result`` 変数に保存します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:232 -msgid "In the second task, we check the ``result`` variable, which is what the first task returned, with the ``assert`` module. We expect that, among other things, the result has the version and reports that the system state has not been changed." -msgstr "2 つ目のタスクでは、``assert`` モジュールで最初のタスクが返した ``result`` 変数を確認します。特に、結果にはバージョンが含まれ、システム状態が変更されていないことが報告されるものと想定しています。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:234 -msgid "Run the tests in the Ubuntu 20.04 docker container:" -msgstr "Ubuntu 20.04 docker コンテナーでテストを実行します。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:240 -msgid "The tests should pass. If we look at the output, we should see something like the following:" -msgstr "テストは合格するはずです。出力を見ると、次のようになっているはずです。" - -#: ../../rst/community/collection_contributors/collection_integration_add.rst:250 -msgid "If your tests fail when you are working on your project, examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage` section for details." -msgstr "プロジェクトで作業中にテストに失敗した場合は、出力を調べて、障害が発生したステップを確認します。理由を調べて修正し、再実行してください。テストに合格するまでこのサイクルを繰り返します。テストに合格したら、さらにテストを作成してください。詳細は、:ref:`Recommendations on coverage` セクションを参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:4 -msgid "Running integration tests" -msgstr "統合テストの実行" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:6 -msgid "In the following examples, we will use ``Docker`` to run integration tests locally. Ensure you :ref:`collection_prepare_environment` first." -msgstr "以下の例では、``Docker`` を使用して、ローカルで統合テストを実行します。最初に :ref:`collection_prepare_environment` を確認してください。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:8 -msgid "We assume that you are in the ``~/ansible_collections/NAMESPACE/COLLECTION`` directory." -msgstr "``~/ansible_collections/NAMESPACE/COLLECTION`` ディレクトリーにいることを前提とします。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:10 -msgid "After you change the tests, you can run them with the following command:" -msgstr "テストを変更した後、以下のコマンドで実行できます。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:16 -msgid "The ``target_name`` is a test role directory containing the tests. For example, if the test files you changed are stored in the ``tests/integration/targets/postgresql_info/`` directory and you want to use the ``fedora34`` container image, then the command will be:" -msgstr "``target_name`` は、テストを含むテストロールディレクトリーです。たとえば、変更したテストファイルが ``tests/integration/targets/postgresql_info/`` ディレクトリーに保存され、``fedora34`` コンテナーイメージを使用する場合、コマンドは以下のようになります。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:22 -#: ../../rst/community/create_pr_quick_start.rst:130 -#: ../../rst/community/create_pr_quick_start.rst:191 -msgid "You can use the ``-vv`` or ``-vvv`` argument if you need more detailed output." -msgstr "より詳細な出力が必要な場合は、``-vv`` 引数または ``-vvv`` 引数を使用できます。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:24 -msgid "In the examples above, the ``fedora34`` test image will be automatically downloaded and used to create and run a test container." -msgstr "上記の例では、``fedora34`` テストイメージが自動的にダウンロードされ、テストコンテナーの作成および実行に使用されます。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:26 -msgid "See the :ref:`list of supported container images `." -msgstr ":ref:`サポート対象のコンテナーイメージの一覧` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:28 -msgid "In some cases, for example, for platform-independent tests, the ``default`` test image is required. Use the ``--docker default`` or just ``--docker`` option without specifying a distribution in this case." -msgstr "場合によっては、たとえば、プラットフォームに依存しないテストでは、``default`` テストイメージが必要になります。今回の場合は、ディストリビューションを指定せずに、``--docker default`` オプションまたは単に ``--docker`` オプションを使用してください。" - -#: ../../rst/community/collection_contributors/collection_integration_running.rst:32 -msgid "If you have any difficulties with writing or running integration tests or you are not sure if the case can be covered, submit your pull request without the tests. Other contributors can help you with them later if needed." -msgstr "統合テストの作成や実行に問題がある場合や、ケースに対応しているかどうかわからない場合は、テストなしでプル要求を送信してください。他のコントリビューターが、必要に応じて後でサポートすることができます。" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:6 -msgid "Adding integration tests to a collection" -msgstr "コレクションへの統合テストの追加" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:8 -msgid "This section describes the steps to add integration tests to a collection and how to run them locally using the ``ansible-test`` command." -msgstr "本セクションでは、コレクションに統合テストを追加するステップと、``ansible-test`` コマンドを使用してローカルで実行する方法を説明します。" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:21 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:149 -msgid ":ref:`testing_units_modules`" -msgstr ":ref:`testing_units_modules`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:22 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:150 -msgid "Unit testing Ansible modules" -msgstr "Ansible モジュールのユニットテスト" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:23 -msgid "`pytest `_" -msgstr "`pytest `_" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:24 -msgid "Pytest framework documentation" -msgstr "pytest フレームワークのドキュメント" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:25 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:151 -msgid ":ref:`developing_testing`" -msgstr ":ref:`developing_testing`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:26 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:152 -msgid "Ansible Testing Guide" -msgstr "Ansible テストガイド" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:27 -msgid ":ref:`collection_unit_tests`" -msgstr ":ref:`collection_unit_tests`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:28 -msgid "Unit testing for collections" -msgstr "コレクションのユニットテスト" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:29 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:155 -msgid ":ref:`testing_integration`" -msgstr ":ref:`testing_integration`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:30 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:156 -msgid "Integration tests guide" -msgstr "統合テストガイド" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:31 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:157 -msgid ":ref:`testing_collections`" -msgstr ":ref:`testing_collections`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:32 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:158 -msgid "Testing collections" -msgstr "コレクションのテスト" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:33 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:159 -msgid ":ref:`testing_resource_modules`" -msgstr ":ref:`testing_resource_modules`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:34 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:160 -msgid "Resource module integration tests" -msgstr "リソースモジュール統合テスト" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:35 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:161 -msgid ":ref:`collection_pr_test`" -msgstr ":ref:`collection_pr_test`" - -#: ../../rst/community/collection_contributors/collection_integration_tests.rst:36 -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:162 -msgid "How to test a pull request locally" -msgstr "プル要求をローカルでテストする方法" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:4 -msgid "Adding to an existing integration test" -msgstr "既存の統合テストへの追加" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:6 -msgid "The test tasks are stored in the ``tests/integration/targets//tasks`` directory." -msgstr "テストタスクは ``tests/integration/targets//tasks`` ディレクトリーに保存されています。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:8 -msgid "The ``main.yml`` file holds test tasks and includes other test files. Look for a suitable test file to integrate your tests or create and include or import a separate test file. You can use one of the existing test files as a draft." -msgstr "``main.yml`` ファイルは、テストタスクを保持し、他のテストファイルを含みます。テストの統合に適切なテストファイルを探すか、別のテストファイルを作成し、追加またはインポートします。既存のテストファイルの 1 つをドラフトとして使用することができます。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:13 -msgid "When fixing a bug" -msgstr "バグを修正する場合" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:15 -msgid "When fixing a bug:" -msgstr "バグを修正する場合:" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:17 -msgid ":ref:`Determine if integration tests for the module exist`. If they do not, see :ref:`collection_creating_integration_tests` section." -msgstr ":ref:`モジュールの統合テストが存在するかどうかを判別します`. 存在しない場合は、:ref:`collection_creating_integration_tests` セクションを参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:18 -msgid "Add a task that reproduces the bug to an appropriate file within the ``tests/integration/targets//tasks`` directory." -msgstr "``tests/integration/targets//tasks`` ディレクトリー内の適切なファイルに、バグを再現するタスクを追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:19 -msgid ":ref:`Run the tests`. The newly added task should fail." -msgstr ":ref:`テストを実行します`。新しく追加されたタスクは失敗するはずです。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:20 -msgid "If they do not fail, re-check if your environment or test task satisfies the conditions described in the ``Steps to Reproduce`` section of the issue." -msgstr "失敗しない場合は、お使いの環境またはテストタスクが問題の ``Steps to Reproduce`` セクションで説明されている条件を満たしているかどうかを再確認してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:21 -msgid "If you reproduce the bug and tests fail, change the code." -msgstr "バグを再現してテストが失敗した場合は、コードを変更してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:22 -msgid ":ref:`Run the tests` again." -msgstr "再度 :ref:`テストを実行します`。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:23 -msgid "If they fail, repeat steps 5-6 until the tests pass." -msgstr "失敗する場合は、テストに合格するまでステップ 5-6 を繰り返します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:25 -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:88 -msgid "Here is an example." -msgstr "以下は例です。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:27 -msgid "Let's say someone reported an issue in the ``community.postgresql`` collection that when users pass a name containing underscores to the ``postgresql_user`` module, the module fails." -msgstr "``community.postgresql`` コレクションで、ユーザーがアンダースコアを含む名前を ``postgresql_user`` モジュールに渡すとモジュールが失敗するという issue が報告されたとします。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:29 -msgid "We cloned the collection repository to the ``~/ansible_collections/community/postgresql`` directory and :ref:`prepared our environment `. From the collection's root directory, we run ``ansible-test integration --list-targets`` and it shows a target called ``postgresql_user``. It means that we already have tests for the module." -msgstr "コレクションリポジトリーを ``~/ansible_collections/community/postgresql`` ディレクトリーにクローンし、:ref:`環境を準備しました `。コレクションの root ディレクトリーから、``ansible-test integration --list-targets`` を実行すると、``postgresql_user`` というターゲットが表示されます。これは、モジュールのテストがすでにあることを意味します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:31 -msgid "We start with reproducing the bug." -msgstr "バグの再現から始めます。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:33 -msgid "First, we look into the ``tests/integration/targets/postgresql_user/tasks/main.yml`` file. In this particular case, the file imports other files from the ``tasks`` directory. The ``postgresql_user_general.yml`` looks like an appropriate one to add our tests." -msgstr "まず、``tests/integration/targets/postgresql_user/tasks/main.yml`` ファイルを見てみましょう。この特定の例では、ファイルは ``tasks`` ディレクトリーから他のファイルをインポートします。``postgresql_user_general.yml`` は、テストを追加するのに適したファイルのようです。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:41 -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:104 -msgid "We will add the following code to the file." -msgstr "以下のコードをファイルに追加します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:66 -msgid "When we :ref:`run the tests` with ``postgresql_user`` as a test target, this task must fail." -msgstr "テストターゲットとして ``postgresql_user`` で :ref:`テストを実行` した場合、このタスクは失敗しなければなりません。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:68 -msgid "Now that we have our failing test; we will fix the bug and run the same tests again. Once the tests pass, we will consider the bug fixed and will submit a pull request." -msgstr "これで、失敗したテストができました。バグを修正し、同じテストを再度実行します。テストに合格すると、バグが修正されたと見なし、プルリクエストを送信します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:71 -msgid "When adding a new feature" -msgstr "新機能を追加する場合" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:75 -msgid "The process described in this section also applies when you want to add integration tests to a feature that already exists, but is missing integration tests." -msgstr "このセクションで説明するプロセスは、既存の機能に統合テストを追加したいが、統合テストがない場合にも適用されます。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:77 -msgid "If you have not already implemented the new feature, you can start by writing the integration tests for it. They will not work as the code does not yet exist, but they can help you improve your implementation design before you start writing any code." -msgstr "新しい機能をまだ実装していない場合は、それ用の統合テストを作成することから開始することができます。コードがまだ存在していないため、これらは機能しませんが、コードを書き始める前に、実装設計を改善する上で役立ちます。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:79 -msgid "When adding new features, the process of adding tests consists of the following steps:" -msgstr "新しい機能を追加する場合、テストの追加プロセスは以下の手順で構成されます。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:81 -msgid ":ref:`Determine if integration tests for the module exists`. If they do not, see :ref:`collection_creating_integration_tests`." -msgstr ":ref:`モジュールの統合テストが存在するかどうかを判別します`。存在しない場合は、:ref:`collection_creating_integration_tests` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:82 -msgid "Find an appropriate file for your tests within the ``tests/integration/targets//tasks`` directory." -msgstr "``tests/integration/targets//tasks`` ディレクトリー内でテスト用の適切なファイルを検索します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:83 -msgid "Cover your feature with tests. Refer to the :ref:`Recommendations on coverage` section for details." -msgstr "テストで機能をカバーします。詳細は、:ref:`カバレージに関する推奨事項` セクションを参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:85 -msgid "If they fail, see the test output for details. Fix your code or tests and run the tests again." -msgstr "失敗した場合は、テスト出力で詳細を確認してください。コードまたはテストを修正して、テストを再実行してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:86 -msgid "Repeat steps 4-5 until the tests pass." -msgstr "テストに合格するまで、ステップ 4-5 を繰り返します。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:90 -msgid "Let's say we decided to add a new option called ``add_attribute`` to the ``postgresql_user`` module of the ``community.postgresql`` collection." -msgstr "``add_attribute`` と呼ばれる新しいオプションを ``community.postgresql`` コレクションの ``postgresql_user`` モジュールに追加することを決定したとしましょう。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:92 -msgid "The option is boolean. If set to ``yes``, it adds an additional attribute to a database user." -msgstr "このオプションはブール値です。``yes`` に設定されている場合、追加の属性がデータベースユーザーに追加されます。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:94 -msgid "We cloned the collection repository to the ``~/ansible_collections/community/postgresql`` directory and :ref:`prepared our environment`. From the collection's root directory, we run ``ansible-test integration --list-targets`` and it shows a target called ``postgresql_user``. Therefore, we already have some tests for the module." -msgstr "コレクションリポジトリーを ``~/ansible_collections/community/postgresql`` ディレクトリーにクローンし、:ref:`環境を準備しました`。コレクションの root ディレクトリーから、``ansible-test integration --list-targets`` を実行すると、``postgresql_user`` というターゲットを表示されます。したがって、モジュールのテストはすでにいくつかあります。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:96 -msgid "First, we look at the ``tests/integration/targets//tasks/main.yml`` file. In this particular case, the file imports other files from the ``tasks`` directory. The ``postgresql_user_general.yml`` file looks like an appropriate one to add our tests." -msgstr "まず、``tests/integration/targets//tasks/main.yml`` ファイルを見てみましょう。この特定の例では、ファイルは ``tasks`` ディレクトリーから他のファイルをインポートします。``postgresql_user_general.yml`` ファイルは、テストを追加するのに適したファイルのようです。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:150 -msgid "Then we :ref:`run the tests` with ``postgresql_user`` passed as a test target." -msgstr "次に、テストターゲットとして渡された ``postgresql_user`` で :ref:`テストを実行します`。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:152 -msgid "In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: yes`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage` for details." -msgstr "実際には、上記のタスクと ``check_mode: yes`` オプションで実行する同じタスクを交互に実行し、チェックモードでもこのオプションが期待通りに動作することを確認します。。詳細は、:ref:`カバレージに関する推奨事項` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_integration_updating.rst:154 -msgid "If we expect a task to fail, we use the ``ignore_errors: true`` option and check that the task actually failed and returned the message we expect:" -msgstr "タスクが失敗することが予想される場合は、``ignore_errors: true`` オプションを使用して、タスクが実際に失敗し、予想されるメッセージを返すことを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:4 -msgid "Releasing collections with release branches" -msgstr "リリースブランチでのコレクションのリリース" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:6 -msgid "Collections MUST follow the `semantic versioning `_ rules. See :ref:`releasing_collections` for high-level details." -msgstr "コレクションは、`セマンティックバージョニング `_ ルールに従う必要があります。概要については、:ref:`releasing_collections` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:13 -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:13 -msgid "Release planning and announcement" -msgstr "リリース計画および発表" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:15 -msgid "Announce your intention to release the collection in a corresponding pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. Repeat the announcement in any other dedicated channels if they exist." -msgstr "コレクションの対応する固定リリース issue/コミュニティーピンボードおよび ``#ansible-community`` `Matrix/IRC channel `_ で、コレクションをリリースする意向をアナウンスします。存在する場合は、他のすべての専用チャネルでアナウンスを繰り返します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:17 -msgid "Ensure all the other repository maintainers are informed about the time of the following release." -msgstr "他のすべてのリポジトリーメンテナーに、以下のリリースの時期が通知されていることを確認してください。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:21 -msgid "Releasing major collection versions" -msgstr "メジャーコレクションバージョンのリリース" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:23 -msgid "The new version is assumed to be ``X.0.0``." -msgstr "新規バージョンは ``X.0.0`` であると想定されます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:25 -msgid "Make sure that ``galaxy.yml`` contains the correct version number ``X.0.0``. If that is not the case, create a PR to update it. This will make sanity tests fail for all deprecations that have to be removed in ``X.0.0``, so this is potentially a lot of work and should have been done weeks before the major release." -msgstr "``galaxy.yml`` には、正しいバージョン番号 ``X.0.0`` が含まれるようにしてください。正しくない場合には、PR を作成して更新してください。これにより、``X.0.0`` で削除する必要のある非推奨アイテムすべてにおいて、サニティーテストで Fail となります。そのため、作業量が多くなる可能性があり、メジャーリリースの数週間前に実行する必要があります。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:27 -msgid "Check the collection for deprecations that are planned for removal in the major release that were not reported by the sanity tests. Use past changelogs or run ``grep -r `X.0.0` plugins/`` in the repository." -msgstr "サニティーテストでレポートされず、またメジャーリリースで削除が予定されている、非推奨アイテムのコレクションを確認します。過去の変更ログを使用するか、レポジトリーで `grep -r `X.0.0` plugins/` を実行します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:29 -msgid "If you are going to release the ``community.general`` and ``community.network`` collections, create a new ``backport-X`` label in the corresponding repositories. Copy the styles and descriptions from the corresponding existing labels." -msgstr "``community.general`` および ``community.network`` コレクションをリリースする場合は、対応するリポジトリーに新しい ``backport-X`` ラベルを作成します。対応する既存ラベルからスタイルおよび説明をコピーします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:31 -msgid "Ensure you are in a default branch in your local fork. These examples use ``main``." -msgstr "ローカルフォークのデフォルトのブランチにいることを確認してください。これらの例では、``main`` を使用します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:39 -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:32 -msgid "Update your local fork:" -msgstr "ローカルのフォークを更新します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:47 -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:22 -msgid "Creating the release branch" -msgstr "リリースブランチの作成" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:49 -msgid "Create a branch ``stable-X``. Replace ``X`` with a correct number and push it to the **upstream** repository, NOT to the ``origin``.:" -msgstr "ブランチ ``stable-X`` を作成します。``X`` を正しい番号に置き換え、``origin`` ではなく **upstream** リポジトリーにプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:57 -msgid "Create and checkout to another branch from the ``main`` branch:" -msgstr "``main`` ブランチから別のブランチを作成し、チェックアウトします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:64 -msgid "Update the version in ``galaxy.yml`` in the branch to the next **expected** version, for example, ``X.1.0``." -msgstr "ブランチの ``galaxy.yml`` のバージョンを、次に **想定される** バージョンに更新します (例: ``X.1.0``)。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:68 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:166 -msgid "Creating the changelogs" -msgstr "changelog の作成" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:70 -msgid "Replace ``changelogs/changelog.yml`` with:" -msgstr "``changelogs/changelog.yml`` を以下に置き換えます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:78 -msgid "Remove all changelog fragments from ``changelogs/fragments/``. Removing the changelog fragments ensures that every major release has a changelog describing changes since the last major release." -msgstr "すべての changelog フラグメントを ``changelogs/fragments/`` から削除します。changelog フラグメントを削除すると、すべてのメジャーリリースに、最後のメジャーリリース以降の変更を説明する changelog が確実に含まれます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:80 -msgid "Add and commit all the changes made. Push the branch to the ``origin`` repository." -msgstr "加えられた変更をすべて追加し、コミットします。ブランチを ``origin`` リポジトリーにプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:82 -msgid "Create a pull request in the collection repository. If CI tests pass, merge the pull request since the ``main`` branch is expecting changes for the next minor/major versions" -msgstr "コレクションリポジトリーにプル要求を作成します。CI テストに合格した場合は、``main`` ブランチが次のマイナー/メジャーバージョンの変更を想定しているので、プル要求をマージします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:84 -msgid "Switch to the ``stable-X`` branch." -msgstr "``stable-X`` ブランチに切り替えます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:86 -msgid "In the ``stable-X`` branch, verify that ``galaxy.yml`` contains the correct version number ``X.0.0``." -msgstr "``stable-X`` ブランチで、``galaxy.yml`` に正しいバージョン番号 ``X.0.0`` が含まれていることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:88 -msgid "In the ``stable-X`` branch, ensure that ``changelogs/changelog.yml`` contains a correct ancestor's version:" -msgstr "``stable-X``ブランチで、``changelogs/changelog.yml`` に正しい祖先のバージョンが含まれていることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:96 -msgid "In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.0.0.yml`` with the content:" -msgstr "``stable-X`` ブランチに、コンテンツを含む changelog フラグメント ``changelogs/fragments/X.0.0.yml`` を追加します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:106 -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:60 -#: ../../rst/community/documentation_contributions.rst:157 -#: ../../rst/community/documentation_contributions.rst:210 -msgid "For example:" -msgstr "例:" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:113 -msgid "In the ``stable-X`` branch, generate the changelogs:" -msgstr "``stable-X`` ブランチで、changelog を生成します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:120 -msgid "In the ``stable-X`` branch, verify that the ``CHANGELOG.rst`` looks as expected." -msgstr "``stable-X`` ブランチで、``CHANGELOG.rst`` が想定通りに表示されることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:122 -msgid "In the ``stable-X`` branch, update ``README.md`` so that the changelog link points to ``/tree/stable-X/`` and no longer to ``/tree/main/``, and change badges respectively, for example, in case of AZP, add ``?branchName=stable-X`` to the AZP CI badge (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI?branchName=stable-X)." -msgstr "``stable-X`` ブランチで、changelog リンクが ``/tree/main/`` ではなく ``/tree/stable-X/`` をポイントするように ``README.md`` を更新し、それぞれバッジを変更します。たとえば、AZP の場合は、AZP CI バッジに ``?branchName=stable-X`` を追加します (https://dev.azure.com/ansible/community.xxx/_apis/build/status/CI?branchName=stable-X)。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:124 -msgid "In the ``stable-X`` branch, add, commit, and push changes to ``README.md``, ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the ``origin``." -msgstr "``stable-X`` ブランチで、``README.md``、``CHANGELOG.rst``、および ``changelogs/changelog.yaml`` に変更を追加、コミット、およびプッシュし、削除/アーカイブされた可能性のあるフラグメントは ``origin`` ではなく、**アップストリーム** リポジトリーに追加、コミット、およびプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:128 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:193 -msgid "Publishing the collection" -msgstr "コレクションの公開" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:130 -msgid "In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.0.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_." -msgstr "``stable-X`` ブランチで、コレクションバージョン ``X.0.0`` で最後のコミットにアノテーション付きタグを追加します。このタグを ``upstream`` リポジトリーにプッシュすると、Zuul がコレクションを `Ansible Galaxy `_ で公開します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:139 -msgid "If the collection uses `Zuul `_ for publishing its releases, wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download." -msgstr "コレクションの `Zuul `_ を使用してそのリリースを更新する場合に、新しいバージョンがコレクションの `Ansible Galaxy `_ ページに公開されるのを待ちます。ダウンロード可能な tarball のリストに表示されます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:141 -msgid "If the release tarball did not appear within several hours after pushing the tag, try to re-tag the release commit and push the tag again. In the ``stable-X`` branch being at the release commit:" -msgstr "タグをプッシュしてから数時間以内にリリース tarball が表示されなかった場合は、リリースコミットに再度タグを付けて、もう一度タグをプッシュしてみてください。リリースコミットのある ``stable-X`` ブランチで以下を実行します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:151 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:206 -msgid "Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``." -msgstr "新規タグの GitHub リリースを追加します。タイトルは、バージョンおよびコンテンツになります (たとえば、``すべての変更については https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst を参照してください``)。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:153 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:208 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:292 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:339 -msgid "Announce the release through the `Bullhorn Newsletter `_." -msgstr "`Bullhorn ニュースレター `_ でリリースを公開します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:155 -msgid "Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/Libera.Chat IRC channel `_." -msgstr "コレクションの固定されたリリースの issue/コミュニティーピンボードと ``#ansible-community`` `Matrix/Libera.Chat IRC channel `_ でリリースを発表します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:157 -msgid "In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, ``X.1.0``. Add, commit and push to the **upstream** repository." -msgstr "``stable-X`` ブランチで、``galaxy.yml`` のバージョンを次の **想定** バージョンに更新します (例: ``X.1.0``)。**アップストリーム** リポジトリーに追加、コミット、およびプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:161 -msgid "Releasing minor collection versions" -msgstr "マイナーコレクションバージョンのリリース" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:163 -msgid "The new version is assumed to be ``X.Y.0``. All changes that should go into it are expected to be previously backported from the default branch to the ``stable-X`` branch." -msgstr "新規バージョンは ``X.Y.0`` であることを前提としています。新規バージョンに入れられるべきすべての変更は、以前にデフォルトブランチから ``stable-X`` ブランチへバックポートされていることが予想されます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:168 -msgid "In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.0``. If not, update it." -msgstr "``stable-X`` ブランチで、``galaxy.yml`` に正しいバージョン番号 ``X.Y.0`` が含まれていることを確認します。含まれていない場合は、更新します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:170 -msgid "In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.0.yml`` with content:" -msgstr "``stable-X`` ブランチに、コンテンツを含む changelog フラグメント ``changelogs/fragments/X.Y.0.yml`` を追加します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:180 -msgid "In the ``stable-X`` branch, run:" -msgstr "``stable-X`` ブランチで以下を実行します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:187 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:319 -msgid "In the ``stable-X`` branch, verify that ``CHANGELOG.rst`` looks as expected." -msgstr "``stable-X`` ブランチで、``CHANGELOG.rst`` が想定通りに表示されることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:189 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:321 -msgid "In the ``stable-X`` branch, add, commit, and push changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the **upstream** repository, NOT to the origin." -msgstr "``stable-X`` ブランチで、``CHANGELOG.rst`` および ``changelogs/changelog.yaml`` に変更を追加、コミット、およびプッシュし、削除/アーカイブされた可能性のあるフラグメントは、元のリポジトリーではなく、**アップストリーム** リポジトリーに追加、コミット、およびプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:195 -msgid "In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.0``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_." -msgstr "``stable-X`` ブランチで、コレクションバージョン ``X.Y.0`` で最後のコミットにアノテーション付きタグを追加します。このタグを ``upstream`` リポジトリーにプッシュすると、Zuul がコレクションを `Ansible Galaxy `_ で公開します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:204 -msgid "Wait until the new version is published on the collection's `Ansible Galaxy `_ page. The published version will appear in a list of tarballs available to download." -msgstr "コレクションの `Ansible Galaxy `_ ページで新しいバージョンが公開されるまで待ちます。公開バージョンは、ダウンロード可能な tarball のリストに表示されます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:210 -msgid "Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_. Additionally, you can announce it using GitHub's Releases system." -msgstr "コレクションの固定されたリリースの issue/コミュニティーピンボードと ``#ansible-community`` `Matrix/IRC channel `_ でリリースを発表します。さらに、GitHub のリリースシステムを使用して、発表することができます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:212 -msgid "In the ``stable-X`` branch, update the version in ``galaxy.yml`` to the next **expected** version, for example, if you have released ``X.1.0``, the next expected version could be ``X.2.0``. Add, commit and push to the **upstream** repository." -msgstr "``stable-X`` ブランチで、``galaxy.yml`` のバージョンを次の **想定** バージョンに更新します。たとえば、``X.1.0`` をリリースしている場合は、次の想定されるバージョンは ``X.2.0`` である可能性があります。**アップストリーム** リポジトリーに追加、コミット、およびプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:214 -msgid "Checkout to the ``main`` branch." -msgstr "``main`` ブランチにチェックアウトします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:216 -msgid "In the ``main`` branch:" -msgstr "``main`` ブランチで以下を行います。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:218 -msgid "If more minor versions are released before the next major version, update the version in ``galaxy.yml`` to ``X.(Y+1).0`` as well. Create a dedicated pull request and merge." -msgstr "次のメジャーバージョンの前にさらにマイナーバージョンがリリースされる場合は、``galaxy.yml`` のバージョンを ``X.(Y+1).0`` にも更新します。専用のプルリクエストを作成してマージします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:220 -msgid "If the next version will be a new major version, create a pull request where you update the version in ``galaxy.yml`` to ``(X+1).0.0``. Note that the sanity tests will most likely fail since there will be deprecations with removal scheduled for ``(X+1).0.0``, which are flagged by the tests." -msgstr "次のバージョンが新しいメジャーバージョンになる場合は、``galaxy.yml`` のバージョンを ``(X+1).0.0`` に更新するプルリクエストを作成します。テストによってフラグが付けられている ``(X+1).0.0`` の削除が予定されている非推奨事項があるため、健全性テストは失敗する可能性が高いことに注意してください。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:222 -msgid "For every such deprecation, decide:" -msgstr "このようなすべての非推奨について、以下を決定します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:224 -msgid "Whether to remove them now. For example you remove the complete ``modules/plugins`` or you remove redirects." -msgstr "今すぐこれらを削除するかどうか。たとえば、完全な ``modules/plugins`` を削除するか、リダイレクトを削除するか。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:225 -msgid "Whether to add ignore entries to the corresponding ``tests/sanity/ignore-*.txt`` file and create issues, for example for removed features in ``modules/plugins``." -msgstr "ignore エントリーを対応する ``tests/sanity/ignore-*.txt`` ファイルに追加し、``modules/plugins`` で削除された機能などの issue を作成するかどうか。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:227 -msgid "Once the CI tests pass, merge the pull request. Make sure that this pull request is merged not too much later after the release for ``version_added`` sanity tests not to expect the wrong version for the new feature pull request." -msgstr "CI テストに合格したら、プルリクエストをマージします。このプルリクエストは、新機能のプルリクエストに対して間違ったバージョンを期待しないように、``version_added`` サニティーテスト用のリリース後あまり時間が経たないうちにマージされることを確認してください。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:232 -msgid "It makes sense to already do some removals in the days before the release. These removals must happen in the main branch and must not be backported." -msgstr "リリース前の数日間にすでにいくつかの削除を行うことは理にかなっています。これらの削除はメインブランチで行われる必要があり、バックポートされてはなりません。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:236 -msgid "Releasing patch versions" -msgstr "パッチバージョンのリリース" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:238 -msgid "The new version is assumed to be ``X.Y.Z``, and the previous patch version is assumed to be ``X.Y.z`` with ``z < Z``. ``z`` is frequently``0`` since patch releases are uncommon." -msgstr "新しいバージョンは ``X.Y.Z`` で、以前のパッチバージョンは ``z < Z`` のある ``X.Y.z`` であることを前提としています。パッチリリースが一般的ではいことから、``z`` は、多くの場合 ``0`` です。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:241 -msgid "Releasing when more minor versions are expected" -msgstr "追加のマイナーバージョンが予想される場合のリリース" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:243 -msgid "Checkout the ``X.Y.z`` tag." -msgstr "``X.Y.z`` タグをチェックアウトします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:245 -msgid "Update ``galaxy.yml`` so that the version is ``X.Y.Z``. Add and commit." -msgstr "バージョンが ``X.Y.Z`` になるように ``galaxy.yml`` を更新します。追加してコミットします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:247 -msgid "Cherry-pick all changes from ``stable-X`` that were added after ``X.Y.z`` and should go into ``X.Y.Z``." -msgstr "``X.Y.z`` の後に追加され、``X.Y.Z`` に移動する必要がある ``stable-X`` からの変更をすべて入念に選びます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:249 -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:51 -msgid "Add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content:" -msgstr "以下の内容を含む changelog フラグメント ``changelogs/fragments/X.Y.Z.yml`` を追加します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:258 -msgid "Add to git and commit." -msgstr "git および commit に追加します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:260 -msgid "Generate the changelogs." -msgstr "changelog を生成します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:266 -msgid "Verify that ``CHANGELOG.rst`` looks as expected." -msgstr "``CHANGELOG.rst`` が想定どおりに表示されることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:268 -msgid "Add and commit changes to ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments." -msgstr "``CHANGELOG.rst`` および ``changelogs/changelog.yaml``、そして削除/アーカイブされた可能性のあるフラグメントに、変更を追加およびコミットします。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:270 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:323 -msgid "**Publishing the collection**" -msgstr "**コレクションの公開**" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:273 -msgid "Add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_." -msgstr "コレクションバージョン ``X.Y.Z`` で、最後のコミットにアノテーション付きタグを追加します。このタグを ``upstream`` リポジトリーにプッシュすると、Zuul がコレクションを `Ansible Galaxy `_ で公開します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:282 -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:335 -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:107 -msgid "Wait until the new version is published on the collection's `Ansible Galaxy `_ page. It will appear in a list of tarballs available to download." -msgstr "コレクションの `Ansible Galaxy `_ ページで新しいバージョンが公開されるまで待ちます。これは、ダウンロード可能な tarball のリストに表示されます。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:284 -msgid "Add a GitHub release for the new tag. The title should be the version and content, such as - ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``." -msgstr "新規タグの GitHub リリースを追加します。タイトルは、バージョンおよびコンテンツになります (たとえば、``すべての変更については https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst を参照してください``)。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:288 -msgid "The data for this release is only contained in a tag, and not in a branch, in particular not in ``stable-X``. This is deliberate, since the next minor release ``X.(Y+1).0`` already contains the changes for ``X.Y.Z`` as well, since these were cherry-picked from ``stable-X``." -msgstr "このリリースのデータはタグにのみ含まれ、ブランチには含まれません (特に ``stable-X`` には含まれません)。次のマイナーリリース ``X.(Y+1).0`` には ``X.Y.Z`` の変更もすでに含まれているため (これらは ``stable-X`` から入念に選ばれているため)、これは意図的なものになります。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:294 -msgid "Announce the release in the pinned release issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `." -msgstr "コレクションの固定されたリリースの issue/コミュニティーピンボードと ``#ansible-community`` `Matrix/IRC channel ` でリリースを発表します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:298 -msgid "Releasing when no more minor versions are expected" -msgstr "さらなるマイナーバージョンがないことが予想される場合のリリース" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:300 -msgid "In the ``stable-X`` branch, make sure that ``galaxy.yml`` contains the correct version number ``X.Y.Z``. If not, update it!" -msgstr "``stable-X`` ブランチで、``galaxy.yml`` に正しいバージョン番号 ``X.Y.Z`` が含まれていることを確認します。含まれていない場合は、更新します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:302 -msgid "In the ``stable-X`` branch, add a changelog fragment ``changelogs/fragments/X.Y.Z.yml`` with content:" -msgstr "``stable-X`` ブランチに、コンテンツを含む changelog フラグメント ``changelogs/fragments/X.Y.Z.yml`` を追加します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:312 -msgid "Generate the changelogs in the ``stable-X`` branch." -msgstr "``stable-X`` ブランチに changelog を生成します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:326 -msgid "In the ``stable-X`` branch, add an annotated tag to the last commit with the collection version ``X.Y.Z``. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_." -msgstr "``stable-X`` ブランチで、コレクションバージョン ``X.Y.Z`` で最後のコミットにアノテーション付きタグを追加します。このタグを ``upstream`` リポジトリーにプッシュすると、Zuul がコレクションを `Ansible Galaxy `_ で公開します。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:337 -msgid "Add a GitHub release for the new tag. Title should be the version and content, such as: ``See https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst for all changes``." -msgstr "新規タグの GitHub リリースを追加します。タイトルは、バージョンおよびコンテンツになります (たとえば、``すべての変更については https://github.com/ansible-collections/community.xxx/blob/stable-X/CHANGELOG.rst を参照してください``)。" - -#: ../../rst/community/collection_contributors/collection_release_with_branches.rst:341 -msgid "Announce the release in the pinned issue/community pinboard of the collection and in the ``#ansible-community`` `Matrix/IRC channel `_." -msgstr "コレクションの固定されたリリースの issue/コミュニティーピンボードと ``#ansible-community`` `Matrix/IRC channel `_ でリリースを発表します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:5 -msgid "Releasing collections without release branches" -msgstr "リリースブランチを使用しないコレクションのリリース" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:7 -msgid "Since no release branches are used, this section does not distinguish between releasing a major, minor, or patch version." -msgstr "リリースブランチを使用しないため、本セクションでは、メジャー、マイナー、またはパッチバージョンのリリースを区別しません。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:15 -msgid "Examine the collection to determine if there are merged changes to release." -msgstr "コレクションを調べて、リリースする変更がマージされているかどうかを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:17 -msgid "According to the changes made, choose an appropriate release version number. Keep in mind that the collections must follow the `semantic versioning `_ rules. See :ref:`collection_versioning_and_deprecation` for details." -msgstr "加えられた変更に応じて、適切なリリースバージョン番号を選択します。コレクションは `semantic versioning `_ ルールに以下に従う必要があることに注意してください。詳細は、:ref:`collection_versioning_and_deprecation` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:19 -msgid "Announce your intention to release the collection in a corresponding pinned release issue or community pinboard of the collection and in the ``community`` :ref:`Matrix/IRC channel `." -msgstr "コレクションの対応する固定リリース issue またはコミュニティーピンボードおよび ``community`` :ref:`Matrix/IRC channel ` で、コレクションをリリースする意向をアナウンスします。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:24 -msgid "Ensure you are in a default branch in your local fork. We use ``main`` in the following examples." -msgstr "ローカルフォークのデフォルトブランチにいることを確認します。以下の例では ``main`` を使用します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:39 -msgid "Checkout a new release branch from the default branch:" -msgstr "デフォルトのブランチから新しいリリースブランチをチェックアウトします。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:45 -msgid "Ensure the ``galaxy.yml`` contains the correct release version number." -msgstr "``galaxy.yml`` に正しいリリースバージョン番号が含まれていることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:49 -msgid "Generating the changelog" -msgstr "Changelog の生成" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:70 -msgid "If the content was recently moved from another collection (for example, migrating a module from one collection to another), ensure you have all related changelog fragments in the ``changelogs/fragments`` directory. If not, copy them previously." -msgstr "コンテンツが最近別のコレクションから移動された場合 (たとえば、モジュールをあるコレクションから別のコレクションに移行する場合)、関連するすべての changelog フラグメントが ``changelogs/fragments``ディレクトリーにあることを確認してください。ない場合は、事前にコピーしてください。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:72 -msgid "Run ``antsibull-changelog release --reload-plugins`` . This package should previously be installed with ``pip install antsibull-changelog``." -msgstr "``antsibull-changelog release --reload-plugins`` を実行します。このパッケージは以前に ``pip install antsibull-changelog`` でインストールされているはずです。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:74 -msgid "Verify that the ``CHANGELOG.rst`` looks as expected." -msgstr "``CHANGELOG.rst`` が想定どおりに表示されることを確認します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:76 -msgid "Commit and push changes to the ``CHANGELOG.rst`` and ``changelogs/changelog.yaml``, and potentially deleted/archived fragments to the ``origin`` repository's ``release_branch``." -msgstr "``CHANGELOG.rst`` および ``changelogs/changelog.yaml`` に変更をコミットしてプッシュします。そして削除/アーカイブされた可能性のあるフラグメントを ``origin`` リポジトリーの ``release_branch`` にコミットしてプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:84 -msgid "Create a pull request in the collection repository. If CI tests pass, merge it." -msgstr "コレクションリポジトリーにプル要求を作成します。CI テストに合格した場合は、マージします。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:86 -msgid "Checkout the default branch and pull the changes:" -msgstr "デフォルトのブランチをチェックアウトし、変更をプルします。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:95 -msgid "Publish the collection" -msgstr "コレクションを公開します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:97 -msgid "Add an annotated tag to the release commit with the collection version. Pushing this tag to the ``upstream`` repository will make Zuul publish the collection on `Ansible Galaxy `_." -msgstr "コレクションバージョンで、リリースコミットにアノテーション付きタグを追加します。このタグを ``upstream`` リポジトリーにプッシュすると、Zuul がコレクションを `Ansible Galaxy `_ で公開します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:109 -msgid "Update the version in the ``galaxy.yml`` file to the next **expected** version. Add, commit, and push to the ``upstream``'s default branch." -msgstr "``galaxy.yml`` ファイルのバージョンを、次の **想定される** バージョンに更新します。``upstream`` のデフォルトブランチに追加、コミット、およびプッシュします。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:111 -msgid "Add a GitHub release for the new tag. Title should be the version and content ``See https://github.com/ansible-collections/community.xxx/blob/main/CHANGELOG.rst for all changes``." -msgstr "新規タグの GitHub リリースを追加します。タイトルは、バージョンおよびコンテンツになります (たとえば、``すべての変更については https://github.com/ansible-collections/community.xxx/blob/main/CHANGELOG.rst を参照してください``)。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:113 -msgid "Announce the release through the `Bullhorn Newsletter issue `_." -msgstr "`Bullhorn ニュースレター issue `_ でリリースを公開します。" - -#: ../../rst/community/collection_contributors/collection_release_without_branches.rst:115 -msgid "Announce the release in the pinned release issue/community pinboard of the collection mentioned in step 3 and in the ``community`` :ref:`Matrix/IRC channel `." -msgstr "ステップ 3 で説明したコレクションの固定されたリリースの issue/コミュニティーピンボードおよび ``コミュニティー`` :ref:`Matrix/IRC channel ` でリリースを発表します。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:6 -msgid "Releasing collections" -msgstr "コレクションのリリース" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:8 -msgid "Collection maintainers release all supported stable versions of the collections regularly, provided that there have been enough changes merged to release." -msgstr "コレクションのメンテナーは、リリースする上で十分な変更がマージされている場合、サポートされているすべての安定したバージョンのコレクションを定期的にリリースします。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:16 -msgid "Preparing to release a collection" -msgstr "コレクションのリリースの準備" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:19 -msgid "The collections under the `ansible-collections organization `_ follow `semantic versioning `_ when releasing. See :ref:`collection_versioning_and_deprecation` for details." -msgstr "`ansible-collections organization `_ の下にあるコレクションは、リリース時に `セマンティックバージョニング `_ に従います。詳細は、:ref:`collection_versioning_and_deprecation` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:21 -msgid "To prepare for a release, a collection must have:" -msgstr "リリースの準備をするには、コレクションに以下のものが必要です。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:23 -msgid "A publicly available policy of releasing, versioning, and deprecation. This can be, for example, written in its README or in a dedicated pinned issue." -msgstr "リリース、バージョン管理、および非推奨の公開されているポリシー。これは、たとえば、README または専用の固定された問題に書き込むことができます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:24 -msgid "A pinned issue when its release managers inform the community about planned or completed releases. This can be combined with the release policy issue mentioned above." -msgstr "リリースマネージャーが、計画されたリリースまたは完了したリリースについてコミュニティーに通知するときに固定された問題。これは、上記のリリースポリシーの問題と組み合わせることができます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:25 -msgid "A :ref:`changelog `." -msgstr ":ref:`changelog `." - -#: ../../rst/community/collection_contributors/collection_releasing.rst:26 -msgid "Releases of the collection tagged in the collection's repository." -msgstr "コレクションのリポジトリーでタグ付けされたコレクションのリリース。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:27 -msgid "CI pipelines up and running. This can be implemented by using GitHub Actions, Azure Pipelines, Zuul." -msgstr "CI パイプラインが稼働しています。これは、GitHub Actions、Azure Pipelines、Zuul を使用して実装できます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:28 -msgid "All CI tests running against a commit that releases the collection. If they do not pass, the collection MUST NOT be released." -msgstr "コレクションをリリースするコミットに対して実行されるすべての CI テスト。テストに合格しない場合は、コレクションをリリースできません。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:30 -msgid "See :ref:`including_collection_ansible` if you plan on adding a new collection to the Ansible package." -msgstr "Ansible パッケージに新しいコレクションを追加する予定がある場合は、:ref:`including_collection_ansible` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:34 -msgid "Your collection must pass ``ansible-test sanity`` tests. See :ref:`testing_collections` for details." -msgstr "コレクションは ``ansible-test sanity`` テストに合格する必要があります。詳細は、:ref:`testing_collections` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:40 -msgid "Collection versioning and deprecation" -msgstr "コレクションのバージョン管理および非推奨" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:44 -msgid "Collections MUST adhere to `semantic versioning `_." -msgstr "コレクションは、`セマンティックバージョニング `_ に準拠する必要があります。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:46 -msgid "To preserve backward compatibility for users, every Ansible minor version series (5.1.x, 5.2.x, and so on) will keep the major version of a collection constant. For example, if Ansible 5.0.0 includes ``community.general`` 4.0.2, then each Ansible 5.X.x release will include the latest ``community.general`` 4.y.z release available at build time. Ansible 5.x.x will **never** include a ``community.general`` 5.y.x release, even if it is available. Major collection version changes will be included in the next Ansible major release (6.0.0 in this case). Ensure that the current major release of your collection included in 6.0.0 receives at least bugfixes as long as new Ansible 6.X.X releases are produced." -msgstr "ユーザーの後方互換性を維持するには、すべての Ansible マイナーバージョンシリーズ (5.1.x、5.2.x など)は、コレクションのメジャーバージョンを一定に保ちます。たとえば、Ansible 5.0.0 に ``community.general`` 4.0.2 が含まれる場合は、各 Ansible 5.X.x リリースにはビルド時に利用可能な最新の ``community.general`` 4.y.z リリースが含まれます。Ansible 5.x.x には、利用可能な場合でも ``community.general`` 5.y.x リリースが含まれることは **決して** ありません。メジャーコレクションバージョンの変更は、次の Ansible メジャーリリース (この場合は 6.0.0) に含まれます。6.0.0 に含まれるコレクションの現在のメジャーリリースでは、新しい Ansible 6.X.X リリースが作成される限りは、少なくともバグ修正を受け取るようにしてください。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:49 -msgid "Since new minor releases are included, you can include new features, modules and plugins. You must make sure that you do not break backwards compatibility. See `semantic versioning `_. for more details. This means in particular:" -msgstr "新しいマイナーリリースが含まれるため、新機能、モジュール、およびプラグインを含めることができます。後方互換性を壊さないようにする必要があります。詳細は、`セマンティックバージョニング `_ を参照してください。これは特に次のことを意味します。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:51 -msgid "You can fix bugs in **patch** releases but not add new features or deprecate things." -msgstr "**パッチ** リリースでバグを修正できますが、新機能を追加したり、非推奨にすることはできません。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:52 -msgid "You can add new features and deprecate things in **minor** releases, but not remove things or change behavior of existing features." -msgstr "**マイナー** リリースで、新しい機能を追加したり、非推奨にしたりすることはできますが、削除したり、既存の機能の動作を変更したりすることはできません。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:53 -msgid "You can only remove things or make breaking changes in **major** releases." -msgstr "**メジャー** リリースでは、削除したり、重大な変更を加えたりすることのみができます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:55 -msgid "Ensure that if a deprecation is added in a collection version that is included in 5.x.y, the removal itself will only happen in a collection version included in 7.0.0 or later. Ensure that the policy of releasing, versioning, and deprecation is announced to contributors and users in some way. For an example of how to do this, see `the announcement in community.general `_. You could also do this in the collection README file." -msgstr "5.x.y に含まれているコレクションバージョンに非推奨が追加されている場合、削除自体は 7.0.0 以降に含まれているコレクションバージョンでのみ行われることを確認してください。リリース、バージョン管理、および非推奨のポリシーが何らかの方法でコントリビューターとユーザーにアナウンスされていることを確認してください。これを行う方法の例については、`the announcement in community.general `_ を参照してください。コレクションの README ファイルでこれを行うこともできます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:61 -msgid "Collection changelogs" -msgstr "コレクションの changelog" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:63 -msgid "Collections MUST include a changelog. To give a consistent feel for changelogs across collections and ensure changelogs exist for collections included in the ``ansible`` package, we suggest you use `antsibull-changelog `_ to maintain and generate this." -msgstr "コレクションには changelog を含める必要があります。コレクション間で changelog の一貫性を保ち、``ansible`` パッケージに含まれるコレクションに changelog が存在することを確認するには、`antsibull-changelog `_ を使用して、これを維持および生成することが推奨されます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:65 -msgid "Before releasing, verify the following for your changelogs:" -msgstr "リリース前に、以下について changelog を確認します。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:67 -msgid "All merged pull requests since the last release, except ones related to documentation and new modules/plugins, have :ref:`changelog fragments `." -msgstr "ドキュメントと新しいモジュール/プラグインに関連するものを除いて、前回のリリース以降にマージされたすべてのプルリクエストには :ref:`changelog フラグメント ` があります。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:68 -msgid "New module and plugin pull requests, except jinja2 test and filter plugins, do **not** need a changelog fragment, they are auto-detected by the changelog generator by their ``version_added`` value." -msgstr "jinja2 テストおよびフィルタープラグインを除き、新しいモジュールおよびプラグインのプル要求には、changelog フラグメントは **必要ありません**。これらは、``version_added`` の値により、changelog ジェネレーターによって自動検出されます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:69 -msgid "All the fragments follow the :ref:`changelog entry format `." -msgstr "すべてのフラグメントは、:ref:`changelog エントリー形式 ` に従います。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:72 -msgid "Options for releasing a collection" -msgstr "コレクションを解放するオプション" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:74 -msgid "There are several approaches on how to release a collection. If you are not aware of which approach to use, ask in the ``#ansible-community`` IRC channel or the ``community`` Matrix channel." -msgstr "コレクションのリリース方法にはいくつかのアプローチがあります。どのアプローチを使用するかわからない場合は、``#ansible-community`` IRC チャンネルまたは ``コミュニティー`` Matrix チャンネルで質問してください。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:76 -msgid "This section assumes that publishing the collection is done with `Zuul `_ and that `antsibull-changelog `_ is used for the changelog." -msgstr "このセクションでは、コレクションの公開が `Zuul `_ で行われ、`antsibull-changelog `_ が changelog に使用されることを前提としています。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:79 -msgid "Releasing without release branches" -msgstr "リリースブランチなしでのリリース" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:81 -msgid "Use releasing without release branches when:" -msgstr "以下の場合は、リリースブランチなしでのリリースを使用します。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:83 -msgid "There are no prior major releases of the collection." -msgstr "コレクションの先行メジャーリリースはありません。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:84 -msgid "There are no breaking changes introduced since the ``1.0.0`` release of the collection." -msgstr "コレクションの ``1.0.0`` リリース以降、重大な変更は導入されていません。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:86 -msgid "See :ref:`collection_release_without_branches` for details." -msgstr "詳細は、:ref:`collection_release_without_branches` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:88 -msgid "When there is a need to introduce breaking changes, you can switch to the next approach." -msgstr "重大な変更を導入する必要がある場合は、次のアプローチに切り替えることができます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:91 -msgid "Hybrid approach" -msgstr "ハイブリッドアプローチ" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:93 -msgid "In this approach, releases for the current major version are made from the ``main`` branch, while new releases for older major versions are made from release branches for these versions." -msgstr "このアプローチでは、現在のメジャーバージョンのリリースは ``main`` ブランチから行われ、以前のメジャーバージョン向けの新しいリリースは、これらのバージョンのリリースブランチから行われます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:96 -msgid "Releasing with release branches" -msgstr "リリースブランチでのリリース" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:98 -msgid "Use releasing with release branches when breaking changes have been introduced. This approach is usually only used by the large community collections, ``community.general`` and ``community.network``." -msgstr "重大な変更が導入される場合は、リリースブランチでリリースを使用します。通常、このアプローチは大規模なコミュニティーコレクションである ``community.general`` および ``community.network`` でのみ使用されます。" - -#: ../../rst/community/collection_contributors/collection_releasing.rst:100 -msgid "See :ref:`collection_release_with_branches` for details." -msgstr "詳細は、:ref:`collection_release_with_branches` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:4 -msgid "Review checklist for collection PRs" -msgstr "コレクション PR チェックリストの確認" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:6 -msgid "Use this section as a checklist reminder of items to review when you review a collection PR." -msgstr "このセクションは、コレクション PR を確認する際の確認項目チェックリストとして使用してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:9 -msgid "Reviewing bug reports" -msgstr "バグレポートの確認" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:11 -msgid "When users report bugs, verify the behavior reported. Remember always to be kind with your feedback." -msgstr "ユーザーがバグを報告したら、報告された動作を確認してください。フィードバックは丁寧に行ってください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:13 -msgid "Did the user make a mistake in the code they put in the Steps to Reproduce issue section? We often see user errors reported as bugs." -msgstr "issue セクションを再現するためのステップで、ユーザーが入力したコードに間違いはありませんか。ユーザーがエラーをバグとして報告することも多くあります。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:14 -msgid "Did the user assume an unexpected behavior? Ensure that the related documentation is clear. If not, the issue is useful to help us improve documentation." -msgstr "ユーザーは予期しない動作を想定していましたか。関連ドキュメントが明確であることを確認してください。明確ではない場合、ドキュメントの改善に役立てることができます。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:15 -msgid "Is there a minimal reproducer? If not, ask the reporter to reduce the complexity to help pinpoint the issue." -msgstr "リプロデューサーは最小限ですか。そうでない場合、報告者に issue を特定するために単純化するよう依頼してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:16 -msgid "Is the issue a consequence of a misconfigured environment?" -msgstr "この問題は、誤った環境設定の結果なのでしょうか?" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:17 -msgid "If it seems to be a real bug, does the behaviour still exist in the most recent release or the development branch?" -msgstr "実際のバグと思われる場合、最新のリリースまたは開発ブランチでも同様の動作が見られますか。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:18 -msgid "Reproduce the bug, or if you do not have a suitable infrastructure, ask other contributors to reproduce the bug." -msgstr "バグを再現するか、適切なインフラストラクチャーがない場合は他のコントリビューターにバグの再現を依頼してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:22 -msgid "Reviewing suggested changes" -msgstr "推奨される変更の確認" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:24 -msgid "When reviewing PRs, verify that the suggested changes do not:" -msgstr "PR を確認するときは、提案された変更が次のことを行っていないことを確認してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:26 -msgid "Unnecessarily break backward compatibility." -msgstr "後方互換性を不用意に損なう。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:27 -msgid "Bring more harm than value." -msgstr "価値よりも害が大きい。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:28 -msgid "Introduce non-idempotent solutions." -msgstr "べき等ではないソリューションを導入する。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:29 -msgid "Duplicate already existing features (inside or outside the collection)." -msgstr "既存の機能 (コレクション内外) を複製する。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:30 -msgid "Violate the :ref:`Ansible development conventions `." -msgstr ":ref:`Ansible development conventions ` に違反する。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:33 -msgid "Other standards to check for in a PR include:" -msgstr "PR で確認するその他の基準は次のとおりです。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:35 -msgid "A pull request MUST NOT contain a mix of bug fixes and new features that are not tightly related. If yes, ask the author to split the pull request into separate PRs." -msgstr "プル要求に、密接に関連しないバグ修正と新機能の組み合わせを含めてはなりません。含まれる場合、作成者にプル要求を別の PR に分割するように依頼してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:36 -msgid "If the pull request is not a documentation fix, it must include a :ref:`changelog fragment `. Check the format carefully as follows:" -msgstr "プル要求がドキュメント修正ではない場合、:ref:`changelog fragment ` を含める必要があります。以下のとおり、形式を慎重に確認してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:38 -msgid "New modules and plugins (that are not jinja2 filter and test plugins) do not need changelog fragments." -msgstr "新しいモジュールおよびプラグイン (jinja2 フィルターおよび test プラグインではない) には changelog フラグメントは必要ありません。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:39 -msgid "For jinja2 filter and test plugins, check out the `special syntax for changelog fragments `_." -msgstr "jinja2 フィルターおよびテストプラグインの場合は、`special syntax for changelog fragments `_ を確認してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:40 -msgid "The changelog content contains useful information for end users of the collection." -msgstr "changelog コンテンツには、コレクションのエンドユーザーに役立つ情報が含まれています。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:42 -msgid "If new files are added with the pull request, they follow the `licensing rules `_." -msgstr "プル要求で新しいファイルが追加された場合、`licensing rules `_ に従います。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:43 -msgid "The changes follow the :ref:`Ansible documentation standards ` and the :ref:`style_guide`." -msgstr "変更は、:ref:`Ansible documentation standards ` および :ref:`style_guide` に従います。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:44 -msgid "The changes follow the :ref:`Development conventions `." -msgstr "変更は、:ref:`Development conventions ` に従います。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:45 -msgid "If a new plugin is added, it is one of the `allowed plugin types `_." -msgstr "新しいプラグインが追加されると、`allowed plugin types `_ の 1 つになります。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:46 -msgid "Documentation, examples, and return sections use FQCNs for the ``M(..)`` :ref:`format macros ` when referring to modules." -msgstr "ドキュメント、例、および戻り値のセクションは、モジュールを参照する際に ``M(..)`` :ref:`format macros ` の FQCN を使用します。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:47 -msgid "Modules and plugins from ansible-core use ``ansible.builtin.`` as an FQCN prefix when mentioned." -msgstr "言及されている場合、ansible-core のモジュールおよびプラグインは ``ansible.builtin.`` を FQCN プレフィックスとして使用します。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:48 -msgid "When a new option, module, plugin, or return value is added, the corresponding documentation or return sections use ``version_added:`` containing the *collection* version in which they will be first released." -msgstr "新しいオプション、モジュール、プラグイン、または戻り値が追加されると、対応するドキュメントまたは戻り値のセクションでは、最初にリリースされる *collection* バージョンを含む ``version_added:`` が使用されます。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:50 -msgid "This is typically the next minor release, sometimes the next major release. For example: if 2.7.5 is the current release, the next minor release will be 2.8.0, and the next major release will be 3.0.0)." -msgstr "通常、これは次のマイナーリリースですが、次のメジャーリリースになる場合もあります。たとえば、現在のリリースが 2.7.5 の場合、次のマイナーリリースは 2.8.0、次のメジャーリリースは 3.0.0 になります。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:52 -msgid "FQCNs are used for ``extends_documentation_fragment:``, unless the author is referring to doc_fragments from ansible-core." -msgstr "作成者が ansible-core の doc_fragments を参照している場合を除き、FQCN は ``extends_documentation_fragment:`` に使用されます。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:53 -msgid "New features have corresponding examples in the :ref:`examples_block`." -msgstr "新機能には、:ref:`examples_block` に対応する例があります。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:54 -msgid "Return values are documented in the :ref:`return_block`." -msgstr "戻り値は :ref:`return_block` に記載されています。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:58 -msgid "Review tests in the PR" -msgstr "PR のテストの確認" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:59 -msgid "Review the following if tests are applicable and possible to implement for the changes included in the PR:" -msgstr "PR に含まれる変更に対してテストが適用可能および実装可能な場合、以下を確認します。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:62 -msgid "Where applicable, the pull request has :ref:`testing_integration` and :ref:`testing_units`." -msgstr "該当する場合、プル要求に :ref:`testing_integration` および :ref:`testing_units` が含まれています。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:63 -msgid "All changes are covered. For example, a bug case or a new option separately and in sensible combinations with other options." -msgstr "すべての変更に対応しています。たとえば、バグケースや新しいオプションは分離され、他のオプションと適切に組み合わされています。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:64 -msgid "Integration tests cover ``check_mode`` if supported." -msgstr "サポート対象の場合、統合テストは ``check_mode`` に対応しています。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:65 -msgid "Integration tests check the actual state of the system, not only what the module reports. For example, if the module actually changes a file, check that the file was changed by using the ``ansible.builtin.stat`` module.." -msgstr "統合テストは、モジュールが報告する内容だけでなく、システムの実際の状態をチェックします。たとえば、モジュールが実際にファイルを変更した場合、``ansible.builtin.stat`` モジュールを使用してファイルが変更されたことを確認します。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:66 -msgid "Integration tests check return values, if applicable." -msgstr "該当する場合、統合テストは戻り値を確認します。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:70 -msgid "Review for merge commits and breaking changes" -msgstr "マージコミットと互換性を損なう変更点の確認" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:72 -msgid "The pull request does not contain merge commits. See the GitHub warnings at the bottom of the pull request. If merge commits are present, ask the author to rebase the pull request branch." -msgstr "プル要求にはマージコミットが含まれません。プル要求の下部にある GitHub の警告を参照してください。マージコミットが存在する場合は、作成者にプル要求ブランチをリベースするよう依頼してください。" - -#: ../../rst/community/collection_contributors/collection_reviewing.rst:73 -msgid "If the pull request contains breaking changes, ask the author and the collection maintainers if it really is needed, and if there is a way not to introduce breaking changes. If breaking changes are present, they MUST only appear in the next major release and MUST NOT appear in a minor or patch release. The only exception is breaking changes caused by security fixes that are absolutely necessary to fix the security issue." -msgstr "プル要求に互換性を損なう変更点が含まれている場合は、作成者やコレクションメンテナーに本当に必要な変更か、互換性を損なう変更を導入せずにすむ方法はないか確認してください。互換性を損なう変更が存在する場合は、必ず次のメジャーリリースにのみ記載し、マイナーリリースまたはパッチリリースには記載しないでください。セキュリティー問題の修正に絶対的に必要なセキュリティー修正が原因の場合のみ例外とします。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:5 -msgid "How to test a collection PR" -msgstr "コレクション PR をテストする方法" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:7 -msgid "Reviewers and issue authors can verify a PR fixes the reported bug by testing the PR locally." -msgstr "レビュー担当者および issue 作成者は、PR をローカルでテストすることで、報告されたバグを PR が修正したことを確認できます。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:15 -#: ../../rst/community/create_pr_quick_start.rst:12 -msgid "Prepare your environment" -msgstr "環境の準備" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:17 -msgid "We assume that you use Linux as a work environment (you can use a virtual machine as well) and have ``git`` installed." -msgstr "Linux を作業環境として使用 (仮想マシンを使用することも可能) し、``git`` がインストールされていることを前提とします。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:20 -msgid ":ref:`Install Ansible ` or ansible-core." -msgstr ":ref:`Ansible ` または ansible-core のインストール。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:28 -msgid "For example, if the collection is ``community.general``:" -msgstr "たとえば、コレクションが ``community.general`` の場合、以下のようになります。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:34 -msgid "If the collection is ``ansible.posix``:" -msgstr "コレクションが ``ansible.posix`` の場合:" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:41 -msgid "Clone the forked repository from the author profile to the created path:" -msgstr "作成者プロファイルから作成されたパスに、フォークされたリポジトリーのクローンを作成します。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:47 -msgid "Go to the cloned repository." -msgstr "クローンしたリポジトリーに移動します。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:53 -msgid "Checkout the PR branch (it can be retrieved from the PR's page):" -msgstr "PR ブランチをチェックアウトします（PR のページから取得できます）。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:61 -msgid "Test the Pull Request" -msgstr "プル要求のテスト" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:63 -msgid "Include `~/ansible_collections` in `COLLECTIONS_PATHS`. See :ref:`COLLECTIONS_PATHS` for details." -msgstr "`~/ansible_collections` を `COLLECTIONS_PATHS` に含めます。詳細は、:ref:`COLLECTIONS_PATHS` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:65 -msgid "Run your playbook using the PR branch and verify the PR fixed the bug." -msgstr "PR ブランチを使用して Playbook を実行し、PR がバグを修正したことを確認します。" - -#: ../../rst/community/collection_contributors/collection_test_pr_locally.rst:67 -msgid "Give feedback on the pull request or the linked issue(s)." -msgstr "プル要求またはリンクされた issue に関するフィードバックを提供します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:6 -msgid "Add unit tests to a collection" -msgstr "コレクションへのユニットテストの追加" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:8 -msgid "This section describes all of the steps needed to add unit tests to a collection and how to run them locally using the ``ansible-test`` command." -msgstr "本セクションでは、コレクションにユニットテストを追加するために必要なすべての手順と、``ansible-test`` コマンドを使用してローカルで実行する方法について説明します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:10 -msgid "See :ref:`testing_units_modules` for more details." -msgstr "詳細は、:ref:`testing_units_modules` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:16 -msgid "Understanding the purpose of unit tests" -msgstr "ユニットテストの目的を理解する" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:18 -msgid "Unit tests ensure that a section of code (known as a ``unit``) meets its design requirements and behaves as intended. Some collections do not have unit tests but it does not mean they are not needed." -msgstr "ユニットテストは、(``unit``として知られる) コードのセクションが設計要件を満たし、意図したとおりに動作することを確認します。一部のコレクションにはユニットテストはありませんが、それらが不要であることを意味するわけではありません。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:21 -msgid "A ``unit`` is a function or method of a class used in a module or plugin. Unit tests verify that a function with a certain input returns the expected output." -msgstr "``unit`` は、モジュールまたはプラグインで使用されるクラスの関数またはメソッドです。ユニットテストは、特定の入力を持つ関数が予想される出力を返すことを確認します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:23 -msgid "Unit tests should also verify when a function raises or handles exceptions." -msgstr "ユニットテストは、関数が例外を発生させるか、例外を処理するときにも確認する必要があります。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:25 -msgid "Ansible uses `pytest `_ as a testing framework." -msgstr "Ansible は、`pytest `_ をテストフレームワークとして使用します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:27 -msgid "See :ref:`testing_units_modules` for complete details." -msgstr "詳細は、:ref:`testing_units_modules` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:29 -msgid "Inclusion in the Ansible package `requires integration and/or unit tests `_ You should have tests for your collection as well as for individual modules and plugins to make your code more reliable To learn how to get started with integration tests, see :ref:`collection_integration_tests`." -msgstr "Ansible パッケージのインクルージョンには `統合テストやユニットテストが必要です `_。コードの信頼性を高めるために、コレクションだけでなく、個々のモジュールとプラグインのテストも必要です。統合テストの開始方法については、:ref:`collection_integration_tests` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:32 -msgid "See :ref:`collection_prepare_local` to prepare your environment." -msgstr "環境を準備するには、:ref:`collection_prepare_local` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:37 -msgid "Determine if unit tests exist" -msgstr "ユニットテストが存在するかどうかを判別する" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:39 -msgid "Ansible collection unit tests are located in the ``tests/units`` directory." -msgstr "Ansible コレクションのユニットテストは、``tests/units`` ディレクトリーにあります。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:41 -msgid "The structure of the unit tests matches the structure of the code base, so the tests can reside in the ``tests/units/plugins/modules/`` and ``tests/units/plugins/module_utils`` directories. There can be sub-directories, if modules are organized by module groups." -msgstr "ユニットテストの構造はコードベースの構造と一致しているため、テストは ``tests/units/plugins/modules/`` および ``tests/units/plugins/module_utils`` ディレクトリーに置くことができます。モジュールがモジュールグループ別に整理されている場合は、サブディレクトリーが存在する可能性があります。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:43 -msgid "If you are adding unit tests for ``my_module`` for example, check to see if the tests already exist in the collection source tree with the path ``tests/units/plugins/modules/test_my_module.py``." -msgstr "たとえば、``my_module`` のユニットテストを追加する場合は、パス ``tests/units/plugins/modules/test_my_module.py`` でテストがコレクションソースツリーにすでに存在しているかどうかを確認します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:46 -msgid "Example of unit tests" -msgstr "ユニットテストの例" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:48 -msgid "Let's assume that the following function is in ``my_module`` :" -msgstr "以下の関数が ``my_module`` にあると仮定します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:65 -msgid "Unit tests for this function should, at a minimum, check the following:" -msgstr "この関数のユニットテストでは、少なくとも以下のことを確認する必要があります。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:67 -msgid "If the function gets a ``Decimal`` argument, it returns a corresponding ``float`` value." -msgstr "関数が ``Decimal`` 引数を取得すると、対応する ``float`` 値を返します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:68 -msgid "If the function gets a ``timedelta`` argument, it returns a corresponding ``str`` value." -msgstr "関数が ``timedelta`` 引数を取得すると、対応する ``str`` 値を返します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:69 -msgid "If the function gets ``42`` as an argument, it raises a ``ValueError``." -msgstr "関数が ``42`` を引数として取得すると、``ValueError`` が発生します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:70 -msgid "If the function gets an argument of any other type, it does nothing and returns the same value." -msgstr "この関数が他のタイプの引数を取得する場合は、何もせずに同じ値を返します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:72 -msgid "To write these unit tests in collection is called ``community.mycollection``:" -msgstr "コレクションにこれらのユニットテストを書き込むことは、``community.mycollection`` と呼ばれます。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:74 -msgid "If you already have your local environment :ref:`prepared `, go to the collection root directory." -msgstr "ローカル環境がすでに :ref:`準備されている ` 場合は、コレクションの root ディレクトリーに移動します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:80 -msgid "Create a test file for ``my_module``. If the path does not exist, create it." -msgstr "``my_module`` のテストファイルを作成します。パスが存在しない場合は作成します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:86 -msgid "Add the following code to the file:" -msgstr "以下のコードをファイルに追加します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:127 -msgid "See :ref:`testing_units_modules` for examples on how to mock ``AnsibleModule`` objects, monkeypatch methods (``module.fail_json``, ``module.exit_json``), emulate API responses, and more." -msgstr "``AnsibleModule`` オブジェクトのモック方法、monkeypatch メソッド (``module.fail_json``、``module.exit_json``)、API 応答のエミュレートなどの例については、:ref:`testing_units_modules` を参照してください。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:129 -msgid "Run the tests using docker:" -msgstr "docker を使用してテストを実行します。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:141 -msgid "Use the following tips to organize your code and test coverage:" -msgstr "以下のヒントを使用して、コードを整理してカバレッジをテストします。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:143 -msgid "Make your functions simple. Small functions that do one thing with no or minimal side effects are easier to test." -msgstr "関数をシンプルにします。副作用がないか最小限の 1 つのことを実行する小さな関数は、テストが簡単です。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:144 -msgid "Test all possible behaviors of a function including exception related ones such as raising, catching and handling exceptions." -msgstr "例外の発生、キャッチ、処理などの例外関連の動作を含む、関数のすべての可能な動作をテストします。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:145 -msgid "When a function invokes the ``module.fail_json`` method, passed messages should also be checked." -msgstr "関数が ``module.fail_json`` メソッドを呼び出すとき、渡されたメッセージも確認する必要があります。" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:153 -msgid ":ref:`collection_integration_tests`" -msgstr ":ref:`collection_integration_tests`" - -#: ../../rst/community/collection_contributors/collection_unit_tests.rst:154 -msgid "Integration testing for collections" -msgstr "コレクションの統合テスト" - -#: ../../rst/community/collection_contributors/test_index.rst:5 -msgid "Testing Collection Contributions" -msgstr "コレクションの貢献度のテスト" - -#: ../../rst/community/collection_contributors/test_index.rst:7 -msgid "This section focuses on the different tests a contributor should run on their collection PR." -msgstr "本セクションでは、コントリビューターがコレクション PR で実行する必要があるさまざまなテストに重点を置いています。" - -#: ../../rst/community/collection_development_process.rst:5 -msgid "The Ansible Collections Development Cycle" -msgstr "Ansible コレクションの開発サイクル" - -#: ../../rst/community/collection_development_process.rst:7 -msgid "Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. These repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections." -msgstr "Ansible 開発者 (コミュニティーのコントリビューターを含む) は、多くの異なるリポジトリーで新機能を追加し、バグを修正し、コードを更新します。これらのリポジトリーには、特定のデータベースへのユーザーの追加や、特定のネットワークデバイスの設定など、Ansible による特定のタスクの実行を可能にするプラグインやモジュールが含まれています。これらのリポジトリーには、コレクション用のソースコードが含まれています。" - -#: ../../rst/community/collection_development_process.rst:9 -msgid "Development on collections occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``." -msgstr "コレクションの開発は、マクロレベルとミクロレベルで行われます。各コレクションには独自のマクロ開発サイクルがあります。コレクション開発サイクルの詳細は、:ref:`contributing_maintained_collections` を参照してください。プル要求のミクロレベルのライフサイクルは、コレクションと ``ansible-core`` に似ています。" - -#: ../../rst/community/collection_development_process.rst:16 -msgid "Macro development: roadmaps, releases, and projects" -msgstr "マクロ開発: ロードマップ、リリース、およびプロジェクト" - -#: ../../rst/community/collection_development_process.rst:18 -msgid "If you want to follow the conversation about what features will be added to the Ansible package for upcoming releases and what bugs are being fixed, you can watch these resources:" -msgstr "今後のリリースで Ansible パッケージに追加される機能と修正されるバグについてのやりとりを見逃さないようにするには、以下のリソースをフォローしてください。" - -#: ../../rst/community/collection_development_process.rst:20 -#: ../../rst/community/development_process.rst:21 -msgid "the :ref:`roadmaps`" -msgstr ":ref:`ロードマップ`" - -#: ../../rst/community/collection_development_process.rst:21 -#: ../../rst/community/development_process.rst:22 -msgid "the :ref:`Ansible Release Schedule `" -msgstr ":ref:`Ansible リリーススケジュール `" - -#: ../../rst/community/collection_development_process.rst:22 -msgid "the `Ansible Community Working Group `_ ." -msgstr "`Ansible コミュニティーのワーキンググループ `_" - -#: ../../rst/community/collection_development_process.rst:25 -#: ../../rst/community/development_process.rst:34 -msgid "Micro development: the lifecycle of a PR" -msgstr "マイクロ開発: PR のライフサイクル" - -#: ../../rst/community/collection_development_process.rst:27 -msgid "If you want to contribute a feature or fix a bug in a collection, you must open a **pull request** (\"PR\" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection. Each collection has its own contributor guidelines so please check there for specific details." -msgstr "コレクションの機能追加またはバグ修正を行う場合は、**プルリクエスト** (略して \"PR\") を作成する必要があります。GitHubでは、`プルリクエストプロセスの仕組み ` 全般に関するすばらしい概要を提供しています。プルリクエストの最終目標は、マージされ、コレクションの一部になることです。各コレクションには独自のコントリビューターガイドラインがありますので、具体的な詳細についてはそちらをご確認ください。" - -#: ../../rst/community/collection_development_process.rst:29 -msgid "Here's an overview of the PR lifecycle:" -msgstr "PR ライフサイクルの概要を以下に示します。" - -#: ../../rst/community/collection_development_process.rst:31 -msgid ":ref:`Contributor opens a PR `" -msgstr ":ref:`コントリビューターが PR を作成します `" - -#: ../../rst/community/collection_development_process.rst:32 -msgid "CI runs the test suite" -msgstr "CI はテストスイートを実行します" - -#: ../../rst/community/collection_development_process.rst:33 -#: ../../rst/community/development_process.rst:44 -msgid "Developers, maintainers, community review the PR" -msgstr "開発者、メンテナー、コミュニティーが PR をレビューします" - -#: ../../rst/community/collection_development_process.rst:34 -#: ../../rst/community/development_process.rst:45 -msgid "Contributor addresses any feedback from reviewers" -msgstr "コントリビューターは、レビュー担当者からのフィードバックに対処します" - -#: ../../rst/community/collection_development_process.rst:35 -#: ../../rst/community/development_process.rst:46 -msgid "Developers, maintainers, community re-review" -msgstr "開発者、メンテナー、コミュニティーが再レビューします" - -#: ../../rst/community/collection_development_process.rst:36 -#: ../../rst/community/development_process.rst:47 -msgid "PR merged or closed" -msgstr "PR をマージまたはクローズします" - -#: ../../rst/community/collection_development_process.rst:40 -#: ../../rst/community/development_process.rst:140 -msgid "Making your PR merge-worthy" -msgstr "PR をマージに値するものにします" - -#: ../../rst/community/collection_development_process.rst:42 -msgid "We do not merge every PR. See :ref:`collection_quickstart` for tips to make your PR useful, attractive, and merge-worthy." -msgstr "すべての PR をマージするわけではありません。ここでは、PR を有益かつ魅力的で、マージする価値のあるものにするためのヒントについては、:ref:`collection_quickstart` を参照してください。" - -#: ../../rst/community/collection_development_process.rst:47 -#: ../../rst/community/development_process.rst:147 -msgid "Creating changelog fragments" -msgstr "changelog フラグメントの作成" - -#: ../../rst/community/collection_development_process.rst:49 -msgid "Most changelogs should emphasize the impact of the change on the end user of the feature or collection, unless the change impacts developers directly. Consider what the user needs to know about this change and write the changelog to convey that detail." -msgstr "ほとんどの変更履歴は、その変更が開発者に直接影響を及ぼす場合を除き、その機能やコレクションの変更がエンドユーザーに与える影響を強調すべきです。ユーザーがこの変更について何を知る必要があるのかを考え、その詳細を伝えるために変更履歴を書きます。" - -#: ../../rst/community/collection_development_process.rst:51 -msgid "Changelogs help users and developers keep up with changes to Ansible collections. Many collections build changelogs for each release from fragments. For collections that use this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug." -msgstr "changelog は、ユーザーと開発者が Ansible コレクションへの変更に対応する上で役に立ちます。多くのコレクションは、リリースごとにフラグメントから changelog を作成します。このモデルを使用するコレクションの場合は、機能を変更したり、バグを修正したりするすべてのプル要求に changelog フラグメントを **追加する必要** があります。" - -#: ../../rst/community/collection_development_process.rst:53 -#: ../../rst/community/development_process.rst:151 -msgid "You do not need a changelog fragment for PRs that:" -msgstr "次のような PR には changelog フラグメントは必要ありません。" - -#: ../../rst/community/collection_development_process.rst:55 -#: ../../rst/community/development_process.rst:153 -msgid "add new modules and plugins, because Ansible tooling does that automatically;" -msgstr "Ansible ツールは自動的に実行されるため、新しいモジュールおよびプラグインを追加します。" - -#: ../../rst/community/collection_development_process.rst:56 -#: ../../rst/community/development_process.rst:154 -msgid "contain only documentation changes." -msgstr "ドキュメントの変更のみが含まれます。" - -#: ../../rst/community/collection_development_process.rst:59 -#: ../../rst/community/development_process.rst:157 -msgid "Some collections require a changelog fragment for every pull request. They use the ``trivial:`` section for entries mentioned above that will be skipped when building a release changelog." -msgstr "一部のコレクションでは、プル要求ごとに changelog フラグメントが必要です。上記のエントリーについて ``trivial:`` セクションを使用します。これは、リリースの変更ログの構築時にスキップされます。" - -#: ../../rst/community/collection_development_process.rst:62 -#: ../../rst/community/development_process.rst:160 -msgid "More precisely:" -msgstr "具体的には、以下のようになります。" - -#: ../../rst/community/collection_development_process.rst:64 -#: ../../rst/community/development_process.rst:162 -msgid "Every bugfix PR must have a changelog fragment. The only exception are fixes to a change that has not yet been included in a release." -msgstr "すべてのバグ修正プル要求には changelog フラグメントが必要です。唯一の例外は、リリースに含まれていない変更の修正です。" - -#: ../../rst/community/collection_development_process.rst:65 -#: ../../rst/community/development_process.rst:163 -msgid "Every feature PR must have a changelog fragment." -msgstr "すべての機能のプル要求には changelog フラグメントが必要です。" - -#: ../../rst/community/collection_development_process.rst:66 -#: ../../rst/community/development_process.rst:164 -msgid "New modules and plugins (including jinja2 filter and test plugins) must have ``version_added`` entries set correctly in their documentation, and do not need a changelog fragment. The tooling detects new modules and plugins by their ``version_added`` values and announces them in the next release's changelog automatically." -msgstr "(jinja2 フィルターと test プラグインなど) 新しいモジュールおよびプラグインには、ドキュメントに ``version_added`` エントリーを正しく設定する必要があり、changelog フラグメントは必要ありません。ツールは、新しいモジュールおよびプラグインをその ``version_added`` 値によって検出し、次のリリースの changelog で自動的に通知します。" - -#: ../../rst/community/collection_development_process.rst:68 -#: ../../rst/community/development_process.rst:166 -msgid "We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR." -msgstr "マイナーリリースとメジャーリリースの両方に、短い概要を示した changelog を作成します。バグ修正をバックポートする場合には、バックポートの PR に changelog フラグメントを追加してください。" - -#: ../../rst/community/collection_development_process.rst:73 -#: ../../rst/community/development_process.rst:171 -msgid "Creating a changelog fragment" -msgstr "changelog フラグメントの作成" - -#: ../../rst/community/collection_development_process.rst:75 -#: ../../rst/community/development_process.rst:173 -msgid "A basic changelog fragment is a ``.yaml`` or ``.yml`` file placed in the ``changelogs/fragments/`` directory. Each file contains a yaml dict with keys like ``bugfixes`` or ``major_changes`` followed by a list of changelog entries of bugfixes or features. Each changelog entry is rst embedded inside of the yaml file which means that certain constructs would need to be escaped so they can be interpreted by rst and not by yaml (or escaped for both yaml and rst if you prefer). Each PR **must** use a new fragment file rather than adding to an existing one, so we can trace the change back to the PR that introduced it." -msgstr "基本的な changelog フラグメントは ``changelogs/fragments/`` ディレクトリーにある ``.yaml`` または ``.yml`` ファイルです。それぞれのファイルには、``bugfixes``、``major_changes`` などのキーを持つ yaml ディクショナリーが含まれており、その後にバグ修正または機能の changelog エントリーの一覧が続きます。それぞれの changelog エントリーは yaml ファイルに組み込まれている rst です。つまり、特定の構成は、yaml ではなく rst で解釈できるようにエスケープする必要があります (yaml と rst の両方にエスケープされていることが望ましい場合は、両方エスケープします)。各プル要求は、既存のものに追加するのではなく、新しいフラグメントファイルを **使用する必要** があります。これにより、変更を加えたプル要求までさかのぼって、変更を追跡することができます。" - -#: ../../rst/community/collection_development_process.rst:77 -msgid "PRs which add a new module or plugin do not necessarily need a changelog fragment. See :ref:`community_changelogs`. Also see :ref:`changelogs_how_to_format` for the precise format changelog fragments should have." -msgstr "新しいモジュールまたはプラグインを追加するプル要求は必ずしも changelog フラグメントを必要としません。:ref:`community_changelogs` を参照してください。また、changelog フラグメントに必要な正確な形式については、:ref:`changelogs_how_to_format` を参照してください。" - -#: ../../rst/community/collection_development_process.rst:79 -#: ../../rst/community/development_process.rst:177 -msgid "To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory of the corresponding repository. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml`` or ``.yml``. For example: ``40696-user-backup-shadow-file.yaml``" -msgstr "changelog エントリーを作成するには、対応するリポジトリーの ``changelogs/fragments/`` ディレクトリーに一意の名前を持つ新しいファイルを作成します。ファイル名には、PR 番号と変更の説明を含める必要があります。ファイル拡張子 ``.yaml`` または ``.yml`` で終了する必要があります (例: ``40696-user-backup-shadow-file.yaml``)。" - -#: ../../rst/community/collection_development_process.rst:81 -#: ../../rst/community/development_process.rst:179 -msgid "A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our `release note tool `_. Here are the valid sections and a description of each:" -msgstr "1 つの changelog フラグメントには複数のセクションが含まれる場合がありますが、ほとんどの場合はセクションが 1 つしか含まれていません。最上位キー (bugfixes、major_changes など) は、`リリースノートツール `_ の `設定ファイル `__ で定義されています。有効なセクションとその説明を以下に示します。" - -#: ../../rst/community/collection_development_process.rst:90 -#: ../../rst/community/development_process.rst:188 -msgid "**breaking_changes**" -msgstr "**breaking_changes**" - -#: ../../rst/community/collection_development_process.rst:84 -#: ../../rst/community/development_process.rst:182 -msgid "MUST include changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Breaking changes means the user MUST make a change when they update. Breaking changes MUST only happen in a major release of the collection. Write in present tense and clearly describe the new behavior that the end user must now follow. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "既存の Playbook またはロールを破損させる変更を含める必要があります。これには、ユーザーにタスクの更新を強制する既存の動作の変更がすべて含まれます。互換性を失わせる変更とは、ユーザーが更新時に変更を行う必要があることを意味します。互換性を失わせる変更は、コレクションのメジャーリリースでのみ実行する必要があります。現在形で書き、エンドユーザーが従わなければならなくなった新しい動作について明確に記述してください。changelog と :ref:`移植ガイド ` の両方に表示されています。" - -#: ../../rst/community/collection_development_process.rst:98 -#: ../../rst/community/development_process.rst:196 -msgid "**major_changes**" -msgstr "**major_changes**" - -#: ../../rst/community/collection_development_process.rst:93 -#: ../../rst/community/development_process.rst:191 -msgid "Major changes to ansible-core or a collection. SHOULD NOT include individual module or plugin changes. MUST include non-breaking changes that impact all or most of a collection (for example, updates to support a new SDK version across the collection). Major changes mean the user can CHOOSE to make a change when they update but do not have to. Could be used to announce an important upcoming EOL or breaking change in a future release. (ideally 6 months in advance, if known. See `this example `_). Write in present tense and describe what is new. Optionally, include a 'Previously...\" sentence to help the user identify where old behavior should now change. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "ansible-core またはコレクションへの主な変更点。個別のモジュールやプラグインの変更を含めないでください。コレクションすべてまたは大半に影響する中断なしの変更 (たとえば、コレクション全体で新しい SDK バージョンをサポートする更新など) を含める必要があります。主な変更点は、ユーザーが更新時に変更を行うことを選択できることを意味しますが、必ずしも変更する必要はありません。重要な今後の EOL または将来のリリースでの重大な変更を発表するために使用することができます (わかっている場合は、理想的には 6 カ月前。`こちらの例 `_ を参照)。現在形で書き、新機能について説明してください。オプションで、「以前の....」という文を含めて、古い動作を変更する必要がある場所をユーザーが特定できるようにします。changelog と :ref:`移植ガイド ` の両方に表示されています。" - -#: ../../rst/community/collection_development_process.rst:107 -#: ../../rst/community/development_process.rst:205 -msgid "**minor_changes**" -msgstr "**minor_changes**" - -#: ../../rst/community/collection_development_process.rst:101 -msgid "Minor changes to ansible-core, modules, or plugins. This includes new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding new values to choices[]. Minor changes are enhancements, not bug fixes. Write in present tense." -msgstr "ansible-core、モジュール、またはプラグインへのマイナーな変更。これには、モジュールに追加された新しいパラメーターや、choices[] に新しい値を追加するなど、既存のパラメーターに対する中断のない動作の変更が含まれます。マイナーな変更は機能拡張であり、バグ修正ではありません。現在形で書いてください。" - -#: ../../rst/community/collection_development_process.rst:116 -#: ../../rst/community/development_process.rst:214 -msgid "**deprecated_features**" -msgstr "**deprecated_features**" - -#: ../../rst/community/collection_development_process.rst:110 -msgid "Features that have been deprecated and are scheduled for removal in a future release. Write in past tense. Include an alternative, where available, for the feature being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "非推奨となり、今後のリリースで削除される予定の機能。過去形で書いてください。可能な場合は、非推奨となった機能の代替機能を追加してください。changelog と :ref:`移植ガイド ` の両方に表示されています。" - -#: ../../rst/community/collection_development_process.rst:125 -#: ../../rst/community/development_process.rst:223 -msgid "**removed_features**" -msgstr "**removed_features**" - -#: ../../rst/community/collection_development_process.rst:119 -msgid "Features that were previously deprecated and are now removed. Write in past tense. Include an alternative, where available, for the feature being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "以前に非推奨となり、現在は削除された機能。過去形で書いてください。可能な場合は、非推奨となった機能の代替機能を追加してください。changelog と :ref:`移植ガイド ` の両方に表示されています。" - -#: ../../rst/community/collection_development_process.rst:134 -#: ../../rst/community/development_process.rst:232 -msgid "**security_fixes**" -msgstr "**security_fixes**" - -#: ../../rst/community/collection_development_process.rst:128 -msgid "Fixes that address CVEs or resolve security concerns. MUST use security_fixes for any CVEs. Write in present tense. Include links to CVE information." -msgstr "CVE に対処するか、セキュリティー上の懸念を解決する修正。CVE には security_fixes を使用する必要があります。現在形で書いてください。CVE 情報へのリンクを含めます。" - -#: ../../rst/community/collection_development_process.rst:143 -#: ../../rst/community/development_process.rst:241 -msgid "**bugfixes**" -msgstr "**bugfixes**" - -#: ../../rst/community/collection_development_process.rst:137 -msgid "Fixes that resolve issues. SHOULD NOT be used for minor enhancements (use ``minor_change`` instead). Write in past tense to describe the problem and present tense to describe the fix." -msgstr "issue を解決するための修正です。マイナーな機能強化には使用しないでください (代わりに ``minor_change`` を使用)。問題の説明は過去形で、修正の説明は現在形で書いてください。" - -#: ../../rst/community/collection_development_process.rst:152 -#: ../../rst/community/development_process.rst:250 -msgid "**known_issues**" -msgstr "**known_issues**" - -#: ../../rst/community/collection_development_process.rst:146 -msgid "Known issues that are currently not fixed or will not be fixed. Write in present tense to describe the problem and in imperative tense to describe any available workaround." -msgstr "現在修正されていない、または修正される予定のない既知の問題。問題の説明は現在形で、利用可能な回避策の説明は命令形で書いてください。" - -#: ../../rst/community/collection_development_process.rst:162 -msgid "**trivial**" -msgstr "**trivial**" - -#: ../../rst/community/collection_development_process.rst:155 -msgid "Changes where a formal release changelog entry isn't required. ``trivial`` changelog fragments are excluded from the published changelog output and may be used for changes such as housekeeping, documentation and test only changes. You can use ``trivial`` for collections that require a changelog fragment for each pull request." -msgstr "正式なリリースの変更ログのエントリーが不要な変更。``trivial`` の変更ログのフラグメントは、公開される変更ログの出力から除外され、ハウスキーピング、ドキュメント、テストのみの変更などの変更に使用される場合があります。プルリクエストごとに変更ログのフラグメントが必要なコレクションに ``trivial`` を使用できます。" - -#: ../../rst/community/collection_development_process.rst:164 -#: ../../rst/community/development_process.rst:252 -msgid "Each changelog entry must contain a link to its issue between parentheses at the end. If there is no corresponding issue, the entry must contain a link to the PR itself." -msgstr "各 changelog エントリーには、最後に括弧内に、その issue へのリンクが含まれていなければなりません。対応する issue がない場合は、エントリーにプル要求自体へのリンクが含まれている必要があります。" - -#: ../../rst/community/collection_development_process.rst:166 -msgid "Most changelog entries are ``bugfixes`` or ``minor_changes``." -msgstr "ほとんどの changelog エントリーは、``bugfixes`` または ``minor_changes`` です。" - -#: ../../rst/community/collection_development_process.rst:170 -#: ../../rst/community/development_process.rst:261 -msgid "Changelog fragment entry format" -msgstr "changelog フラグメントのエントリー形式" - -#: ../../rst/community/collection_development_process.rst:172 -#: ../../rst/community/development_process.rst:263 -msgid "When writing a changelog entry, use the following format:" -msgstr "changelog エントリーを作成する場合は、以下の形式を使用します。" - -#: ../../rst/community/collection_development_process.rst:178 -#: ../../rst/community/development_process.rst:269 -msgid "The scope is usually a module or plugin name or group of modules or plugins, for example, ``lookup plugins``. While module names can (and should) be mentioned directly (``foo_module``), plugin names should always be followed by the type (``foo inventory plugin``)." -msgstr "範囲は通常、モジュールまたはプラグインの名前、またはモジュールまたはプラグインのグループです (例: ``lookup plugins``)。モジュール名は直接言及することができます (そして言及する必要があります) (``foo_module``) が、プラグイン名の後には常にタイプを追加する必要があります (``foo inventory plugin``)。" - -#: ../../rst/community/collection_development_process.rst:180 -#: ../../rst/community/development_process.rst:271 -msgid "For changes that are not really scoped (for example, which affect a whole collection), use the following format:" -msgstr "スコープ指定ロールがない変更 (コレクション全体に影響するなど) については、以下の形式を使用します。" - -#: ../../rst/community/collection_development_process.rst:187 -#: ../../rst/community/development_process.rst:278 -msgid "Here are some examples:" -msgstr "以下に例を示します。" - -#: ../../rst/community/collection_development_process.rst:207 -msgid "You can find more example changelog fragments in the `changelog directory `_ for the community.general development branch." -msgstr "changelog フラグメントのさらなる例は、community.general 開発ブランチの `changelog ディレクトリー `_ にあります。" - -#: ../../rst/community/collection_development_process.rst:209 -#: ../../rst/community/development_process.rst:300 -msgid "After you have written the changelog fragment for your PR, commit the file and include it with the pull request." -msgstr "プル要求用に changelog フラグメントを作成したら、ファイルをコミットし、プル要求に追加します。" - -#: ../../rst/community/collection_development_process.rst:213 -msgid "Changelog fragment entry format for new jinja2 plugins, roles, and playbooks" -msgstr "新しい jinja2 プラグイン、ロール、および Playbook の変更ログ フラグメントエントリーの形式" - -#: ../../rst/community/collection_development_process.rst:215 -msgid "While new modules and plugins that are not jinja2 filter or test plugins are mentioned automatically in the generated changelog, jinja2 filter and test plugins, roles, and playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed:" -msgstr "生成された changelog には、jinja2 フィルターまたはテストプラグインではない新しいモジュールとプラグインが自動的に記載されますが、jinja2 フィルターとテストプラグイン、ロール、および Playbook は記載されません。それらが確実に言及されるようにするには、特定の形式の changelog フラグメントが必要です。" - -#: ../../rst/community/committer_guidelines.rst:5 -msgid "Committers Guidelines" -msgstr "コミット担当者のガイドライン" - -#: ../../rst/community/committer_guidelines.rst:7 -msgid "These are the guidelines for people with commit privileges on the repositories in the ansible and ansible-collections GitHub organizations." -msgstr "これは、ansible および ansible-collections GitHub 組織のリポジトリーでコミット権限を持つユーザーを対象とするガイドラインです。" - -#: ../../rst/community/committer_guidelines.rst:9 -msgid "Committers of `Ansible-core `_ are necessarily Red Hat employees acting as members of the Ansible Core team. Committers of `Ansible collections `_ are members of the community or Ansible Engineering. Please read the guidelines before you commit." -msgstr "`Ansible-core `_ のコミット権限を持つのは、Ansible Core チームのメンバーである Red Hat 従業員である必要があります。`Ansible コレクション `_ のコミット権限を持つユーザーは、コミュニティーまたは Ansible Engineering のメンバーです。コミットする前にガイドラインを確認してください。" - -#: ../../rst/community/committer_guidelines.rst:11 -msgid "These guidelines apply to everyone. At the same time, this is NOT a process document. So just use good judgment. You have been given commit access because we trust your judgment." -msgstr "これらのガイドラインはすべてのユーザーに適用されます。同時に、これはプロセスのドキュメントではありません。したがって、適切な判断が求められます。コミットアクセス権が与えられているのは、そのユーザーの判断を信頼しているからです。" - -#: ../../rst/community/committer_guidelines.rst:13 -msgid "That said, use the trust wisely." -msgstr "そのため、その信頼については慎重に行動してください。" - -#: ../../rst/community/committer_guidelines.rst:15 -msgid "If you abuse the trust and break components and builds, and so on, the trust level falls and you may be asked not to commit or you may lose your commit privileges." -msgstr "信頼を悪用してコンポーネントやビルドを壊すなどすると、信頼レベルが下がった場合は、コミットしないように求められるか、コミット権限を失う可能性があります。" - -#: ../../rst/community/committer_guidelines.rst:18 -msgid "Features, high-level design, and roadmap of ansible-core" -msgstr "ansible-core の機能、ハイレベルの設計、およびロードマップ" - -#: ../../rst/community/committer_guidelines.rst:20 -msgid "As a core team member, you are an integral part of the team that develops the :ref:`roadmap `. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, and so on, for various releases. Red Hat, the company, and the Ansible team must get these changes completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it affects a lot of other parts within Ansible." -msgstr "コミット担当者は、コアチームメンバーとして、:ref:`ロードマップ ` を作成するチームに不可欠です。積極的に関与し、希望する機能や修正をプッシュしてください。また、Red Hat は企業として、様々なリリースに対して、特定の機能、修正、API などにコミットすることを念頭に置いてください。企業である Red Hat、および Ansible チームは、このようなコミットされた機能 (など) を完成させ、スケジュール通りにリリースしなければなりません。ユーザー、コミュニティー、顧客への義務が最優先されなければなりません。これらの義務があるため、自分で開発したい機能が Ansible 内の他の多くの部分に影響を与える場合は、その機能がリリースに含まれない可能性があります。" - -#: ../../rst/community/committer_guidelines.rst:22 -msgid "Any other new features and changes to high level design should go through the proposal process (TBD), to ensure the community and core team have had a chance to review the idea and approve it. The core team has sole responsibility for merging new features based on proposals to `Ansible-core `_." -msgstr "その他の新機能や高レベル設計の変更は、コミュニティーおよび Core チームがアイデアを確認して承認する機会を確実にもてるように、提案プロセス (TBD) を経る必要があります。`Ansible-core `_ への提案に基づいて新しい機能をマージする責任は Core チームにあります。" - -#: ../../rst/community/committer_guidelines.rst:26 -msgid "Features, high-level design, and roadmap of Ansible collections" -msgstr "Ansible コレクションの特長、高レベルの設計、およびロードマップ" - -#: ../../rst/community/committer_guidelines.rst:28 -msgid "Collections maintainers define features, high-level design, and roadmap of the collections themselves and are responsible for merging new features to `Ansible collections `_ based on proposals discussed with their communities." -msgstr "コレクションメンテナーは、コレクション自体の機能、高レベルの設計、およびロードマップを定義し、コミュニティーで説明した提案に基づいて、`Ansible コレクション `_ に新機能をマージします。" - -#: ../../rst/community/committer_guidelines.rst:31 -msgid "Our workflow on GitHub" -msgstr "GitHub でのワークフロー" - -#: ../../rst/community/committer_guidelines.rst:33 -msgid "As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you are aware of the following workflow steps:" -msgstr "コミット担当者として、以下をすでに理解しているかもしれませんが、ここでのワークフローは多くのチームポリシーを形成しています。以下のワークフローの手順を理解しておいてください。" - -#: ../../rst/community/committer_guidelines.rst:35 -msgid "Fork the repository upon which you want to do some work to your own personal repository" -msgstr "作業したいリポジトリーを自身のリポジトリーにフォークします。" - -#: ../../rst/community/committer_guidelines.rst:36 -msgid "Work on the specific branch upon which you need to commit" -msgstr "コミットする必要がある特定のブランチでの作業" - -#: ../../rst/community/committer_guidelines.rst:37 -msgid "Create a pull request back to the upstream repository and tag the people you would like to review; assign someone as the primary \"owner\" of your pull request" -msgstr "アップストリームリポジトリーへのプル要求を作成し、レビューするユーザーをタグ付けます。1 人のユーザーをプル要求の主要な「所有者」として割り当てます" - -#: ../../rst/community/committer_guidelines.rst:38 -msgid "Adjust code as necessary based on the comments provided" -msgstr "提供されたコメントに基づいて、必要に応じてコードを調整します。" - -#: ../../rst/community/committer_guidelines.rst:39 -msgid "Ask someone from the repository committers to do a final review and merge" -msgstr "最終のレビューとマージを行うよう、リポジトリーのコミット担当者のいずれかに依頼します。" - -#: ../../rst/community/committer_guidelines.rst:42 -msgid "Addendum to workflow for committers:" -msgstr "コミット担当者のワークフローへの補足" - -#: ../../rst/community/committer_guidelines.rst:44 -msgid "The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules by making direct commits or merging their own pull requests. This section is a set of guidelines. If you are changing a comma in documentation, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work." -msgstr "Core チームは、これが時に困難なプロセスであることを認識しています。時には、チームが直接コミットしたり、自身のプル要求をマージしたりしてルールを破ってしまうこともあります。ここではガイドラインを示します。ドキュメントでコンマを変更する場合や、ごく些細な変更であれば、各自の裁量で行ってください。これも信頼関係の問題です。大きな変更にはプロセスが重要ですが、ちょっとしたことや迅速に何かを行う場合は、最善の判断を下し、チームの人々に自分の仕事を認識してもらうようにしましょう。" - -#: ../../rst/community/committer_guidelines.rst:47 -msgid "Roles on Core" -msgstr "Core におけるロール" - -#: ../../rst/community/committer_guidelines.rst:48 -msgid "Core committers: Fine to do pull requests for most things, but we should have a timebox. Hanging pull requests may merge on the judgement of these developers." -msgstr "Core のコミット担当者: ほとんどの場合は、プル要求を実行しても問題ありませんが、タイムボックスが必要です。解決されていないプル要求が存在すると、開発者の判断でマージされます。" - -#: ../../rst/community/committer_guidelines.rst:49 -msgid ":ref:`Module maintainers `: Module maintainers own specific modules and have indirect commit access through the current module pull request mechanisms." -msgstr ":ref:`モジュールメンテナー `: モジュールメンテナーは特定のモジュールを所有しており、現在のモジュールのプル要求メカニズムを通じて間接的にコミットにアクセスできます。" - -#: ../../rst/community/committer_guidelines.rst:50 -msgid ":ref:`Collection maintainers `: Collection maintainers own specific collections and have commit access to them. Each collection can set its own rules for contributions." -msgstr ":ref:`コレクションメンテナー `: コレクションメンテナーは特定のコレクションと、そのコレクションへのコミットアクセスを所有します。各コレクションは、貢献に関する独自のルールを設定できます。" - -#: ../../rst/community/committer_guidelines.rst:55 -msgid "General rules" -msgstr "一般的なルール" - -#: ../../rst/community/committer_guidelines.rst:56 -msgid "Individuals with direct commit access are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement." -msgstr "直接コミットアクセスを持つユーザーには、さまざまなことを実行できる権限が与えられています。おそらく、ここに記載している以上のことが可能になります。ここに示すことは、ルールというよりは、一般的な *ガイドライン* として扱い、この権限を持つユーザーは最善の判断を下すことが期待されています。" - -#: ../../rst/community/committer_guidelines.rst:58 -msgid "Do NOT" -msgstr "してはいけないこと" - -#: ../../rst/community/committer_guidelines.rst:60 -msgid "Commit directly." -msgstr "直接コミットする。" - -#: ../../rst/community/committer_guidelines.rst:61 -msgid "Merge your own pull requests. Someone else should have a chance to review and approve the pull request merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes." -msgstr "自身のプル要求をマージする。他の誰かがプル要求のマージを確認して承認する機会を持つべきです。Core のコミット担当者であれば、ごくわずかな変更であれば、各自の裁量で行うことができます。" - -#: ../../rst/community/committer_guidelines.rst:62 -msgid "Forget about alternate environments. Consider the alternatives--yes, people have bad environments, but they are the ones who need us the most." -msgstr "代替環境のことを考えない。代替案を検討してください。ユーザーの中には環境が良くない人もいますが、私たちを最も必要としているのはそのようなユーザーです。" - -#: ../../rst/community/committer_guidelines.rst:63 -msgid "Drag your community team members down. Discuss the technical merits of any pull requests you review. Avoid negativity and personal comments. For more guidance on being a good community member, read our :ref:`code_of_conduct`." -msgstr "コミュニティーチームメンバーの足を引っ張る。レビューするプル要求の技術的なメリットについて話し合います。否定したり、個人的なコメントをすることは避けてください。優れたコミュニティーメンバーになるための詳細なガイダンスについては、「:ref:`code_of_conduct`」を参照してください。" - -#: ../../rst/community/committer_guidelines.rst:64 -msgid "Forget about the maintenance burden. High-maintenance features may not be worth adding." -msgstr "メンテナンスの負担を考えない。メンテナンスの負担が大きすぎる場合は、その機能を追加する価値がないかもしれません。" - -#: ../../rst/community/committer_guidelines.rst:65 -msgid "Break playbooks. Always keep backwards compatibility in mind." -msgstr "Playbook を壊す。常に下位互換性を念頭に置いてください。" - -#: ../../rst/community/committer_guidelines.rst:66 -msgid "Forget to keep it simple. Complexity breeds all kinds of problems." -msgstr "シンプルにすることを考えない。複雑なものは、あらゆる種類の問題を生み出します。" - -#: ../../rst/community/committer_guidelines.rst:68 -msgid "Do" -msgstr "すべきこと" - -#: ../../rst/community/committer_guidelines.rst:70 -msgid "Squash, avoid merges whenever possible, use GitHub's squash commits or cherry pick if needed (bisect thanks you)." -msgstr "squash を使用し、マージはできる限り使用せず、必要に応じて GitHub の Squash コミットを使用するか、入念に選ぶ (cherry-pick)。" - -#: ../../rst/community/committer_guidelines.rst:71 -msgid "Be active. Committers who have no activity on the project (through merges, triage, commits, and so on) will have their permissions suspended." -msgstr "活発に行動する。(マージ、トリアージ、コミットなどを通じて) プロジェクトで活動をしていないコミット担当者は、そのパーミッションが停止します。" - -#: ../../rst/community/committer_guidelines.rst:72 -msgid "Consider backwards compatibility (goes back to \"do not break existing playbooks\")." -msgstr "下位互換性を検討する (既存の Playbook を壊さない)。" - -#: ../../rst/community/committer_guidelines.rst:73 -msgid "Write :ref:`tests` and be sure that other's pull requests you are reviewing are covered well. Pull requests with tests are looked at with more priority than pull requests without tests that should have them included. While not all changes require tests, be sure to add them for new features, bug fixes, and functionality changes." -msgstr ":ref:`テスト` を作成し、確認している他のプル要求が十分に対応されていることを確認してください。テストを含むプル要求は、テストを含まないプル要求よりも優先して検討されます。すべての変更にテストが必要なわけではありませんが、新機能、バグ修正、および機能変更には必ずテストを追加してください。" - -#: ../../rst/community/committer_guidelines.rst:74 -msgid "Discuss with other committers, specially when you are unsure of something." -msgstr "特に不明な点がある場合は、他のコミット担当者と話し合う。" - -#: ../../rst/community/committer_guidelines.rst:75 -msgid "Document! If your pull request is a new feature or a change to behavior, make sure you have updated all associated documentation or have notified the right people to do so. It also helps to add the version of ``ansible-core`` or ``collection`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on)." -msgstr "文書化する。プル要求が新機能や動作の変更であれば、関連するすべてのドキュメントを更新したか、適切なユーザーに通知したかを確認してください。また、本ドキュメントと互換性がある ``ansible-core`` または ``コレクション`` のバージョンを追加するのに便利です (たとえば、安定版と開発版のドキュメントとの混同を避けるため、後方互換性のためなど)。" - -#: ../../rst/community/committer_guidelines.rst:76 -msgid "Consider scope, sometimes a fix can be generalized." -msgstr "スコープを検討する。時には修正を一般化できる場合があります。" - -#: ../../rst/community/committer_guidelines.rst:77 -msgid "Keep it simple, then things are maintainable, debuggable, and intelligible." -msgstr "保守やデバッグが可能で、分かりやすいものになるように、簡潔さを試みる。" - -#: ../../rst/community/committer_guidelines.rst:79 -msgid "Committers are expected to continue to follow the same community and contribution guidelines followed by the rest of the Ansible community." -msgstr "コミット担当者は、Ansible コミュニティーの他のメンバーが従う同じコミュニティーおよび貢献ガイドラインに引き続き従うことが求められます。" - -#: ../../rst/community/communication.rst:5 -msgid "Communicating with the Ansible community" -msgstr "Ansible コミュニティーとのコミュニケーション" - -#: ../../rst/community/communication.rst:11 -msgid "Code of Conduct" -msgstr "行動規範" - -#: ../../rst/community/communication.rst:13 -msgid "All communication and interactions in the Ansible Community are governed by our :ref:`code_of_conduct`. Please read and understand it!" -msgstr "Ansibleコミュニティでのすべてのコミュニケーションとやり取りは、:ref:`code_of_conduct`により管理されます。読んで理解してください。" - -#: ../../rst/community/communication.rst:16 -msgid "Asking questions over email" -msgstr "メールで質問する" - -#: ../../rst/community/communication.rst:18 -msgid "If you want to keep up with Ansible news, need help, or have a question, you can use one of the Ansible mailing lists. Each list covers a particular topic. Read the descriptions here to find the best list for your question." -msgstr "最新のAnsibleのニュースを把握する、助けが必要、または質問がある場合は、Ansibleメーリングリストの1つを使用できます。各リストは特定のトピックをカバーしています。こちらの説明を読んで、質問に最適なリストを見つけてください。" - -#: ../../rst/community/communication.rst:20 -msgid "Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear." -msgstr "メーリングリストへの最初の投稿は (スパムを減らすため) 調整されます。そのため、最初の投稿が表示されるまで最大 1 日ほどかかります。" - -#: ../../rst/community/communication.rst:22 -msgid "`Ansible Announce list `_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series. Worth subscribing to!" -msgstr "`Ansible アナウンスリスト `_ は、Ansible の新規リリースに関する情報を共有する読み取り専用リストです。Ansible の公式カンファレンスシリーズである AnsibleFest に関するアナウンスなど、不定期に開催されるイベント情報を共有しているため、ぜひサブスクライブしてください。" - -#: ../../rst/community/communication.rst:23 -msgid "`Ansible AWX List `_ is for `Ansible AWX `_" -msgstr "`Ansible AWX リスト `_ は、`Ansible AWX `_ 用です。" - -#: ../../rst/community/communication.rst:24 -msgid "`Ansible Development List `_ is for questions about developing Ansible modules (mostly in Python), fixing bugs in the Ansible core code, asking about prospective feature design, or discussions about extending Ansible or features in progress." -msgstr "`Ansible Development リスト `_は、Ansibleモジュールの開発（主にPython）、Ansibleコアコードのバグの修正、将来の機能設計についての質問、またはAnsibleの機能拡張または進行中の機能ついての議論用です。" - -#: ../../rst/community/communication.rst:25 -msgid "`Ansible Outreach List `_ help with promoting Ansible and `Ansible Meetups `_" -msgstr "`Ansible Outreach List `_ は、Ansible および `Ansible Meetups `_ のプロモーションを支援します。" - -#: ../../rst/community/communication.rst:26 -msgid "`Ansible Project List `_ is for sharing Ansible tips, answering questions about playbooks and roles, and general user discussion." -msgstr "`Ansible Project リスト `_ は、Ansible のヒントを共有したり、Playbookやロールに関する質問に答えたり、一般的なユーザーディスカッションを行うためのものです。" - -#: ../../rst/community/communication.rst:27 -msgid "`Molecule Discussions `_ is designed to aid with the development and testing of Ansible roles with Molecule." -msgstr "`Molecule Discussions `_ は、Molecule を使用した Ansible ロールの開発とテストを支援するためのものです。" - -#: ../../rst/community/communication.rst:29 -msgid "The Ansible mailing lists are hosted on Google, but you do not need a Google account to subscribe. To subscribe to a group from a non-Google account, send an email to the subscription address requesting the subscription. For example: ``ansible-devel+subscribe@googlegroups.com``." -msgstr "AnsibleメーリングリストはGoogleでホストされていますが、サブスクライブするためにGoogleアカウントは必要ありません。 Google 以外のアカウントからグループをサブスクライブするには、サブスクリプションを依頼するメールをサブスクリプションのアドレス (例: ``ansible-devel+subscribe@googlegroups.com``) に送信します。" - -#: ../../rst/community/communication.rst:34 -msgid "Real-time chat" -msgstr "リアルタイムチャット" - -#: ../../rst/community/communication.rst:36 -msgid "For real-time interactions, conversations in the Ansible community happen over two chat protocols: Matrix and IRC. We maintain a bridge between Matrix and IRC, so you can choose whichever protocol you prefer. All channels exist in both places. Join a channel any time to ask questions, participate in a Working Group meeting, or just say hello." -msgstr "リアルタイムの対話の場合、Ansibleコミュニティでの会話は、MatrixとIRCの2つのチャットプロトコルを介して行われます。 MatrixとIRCの間のブリッジを維持しているため、お好みのプロトコルを選択できます。すべてのチャンネルは両方の場所に存在します。いつでもチャンネルに参加して、質問したり、ワーキンググループの会議に参加したり、挨拶したりできます。" - -#: ../../rst/community/communication.rst:39 -msgid "Ansible community on Matrix" -msgstr "Matrix上のAnsibleコミュニティ" - -#: ../../rst/community/communication.rst:41 -msgid "To join the community using Matrix, you need two things:" -msgstr "Matrixを使用してコミュニティに参加するには、次の2つが必要です。" - -#: ../../rst/community/communication.rst:43 -msgid "a Matrix account (from `Matrix.org `_ or any other Matrix homeserver)" -msgstr "マトリックスアカウント（`Matrix.org `_またはその他のMatrixホームサーバーから）" - -#: ../../rst/community/communication.rst:44 -msgid "a `Matrix client `_ (we recommend `Element Webchat `_)" -msgstr "`Matrix client `_ (`Element Webchat `_を推奨します)" - -#: ../../rst/community/communication.rst:46 -msgid "The Ansible community maintains its own Matrix homeserver at ``ansible.im``, however public registration is currently unavailable." -msgstr "Ansibleコミュニティは、``ansible.im``で独自のMatrixホームサーバーを維持しています。ただし、現在、公開登録は利用できません。" - -#: ../../rst/community/communication.rst:48 -msgid "Matrix chat supports:" -msgstr "Matrixチャットは以下をサポートします：" - -#: ../../rst/community/communication.rst:50 -msgid "persistence (when you log on, you see all messages since you last logged off)" -msgstr "永続性（ログオンすると、最後にログオフしてからのすべてのメッセージが表示されます）" - -#: ../../rst/community/communication.rst:51 -msgid "edits (Lets you fix typos and so on. **NOTE** Each edit you make on Matrix re-sends the message to IRC. Please try to avoid multiple edits!)" -msgstr "編集 (タイプミスなどを修正できます。**注記** Matrix で編集を行うたびに、メッセージが IRC に再送信されます。何度も編集しないようにしてください!)" - -#: ../../rst/community/communication.rst:52 -msgid "replies to individual users" -msgstr "個々のユーザーへの返信" - -#: ../../rst/community/communication.rst:53 -msgid "reactions/emojis" -msgstr "反応/絵文字" - -#: ../../rst/community/communication.rst:54 -msgid "bridging to IRC" -msgstr "IRCへのブリッジ" - -#: ../../rst/community/communication.rst:55 -msgid "no line limits" -msgstr "行制限なし" - -#: ../../rst/community/communication.rst:56 -msgid "images" -msgstr "images" - -#: ../../rst/community/communication.rst:58 -msgid "The room links in the :ref:`general_channels` or in the :ref:`working_group_list` list will take you directly to the relevant rooms." -msgstr ":ref:`general_channels`または:ref:`working_group_list` リストのルームリンクから関連するルームに直接移動できます。" - -#: ../../rst/community/communication.rst:60 -msgid "If there is no appropriate room for your community, please create it." -msgstr "コミュニティーに適切なルームがない場合は、作成してください。" - -#: ../../rst/community/communication.rst:62 -msgid "For more information, see the community-hosted `Matrix FAQ `_." -msgstr "詳細は、コミュニティーがホストする `Matrix FAQ `_ を参照してください。" - -#: ../../rst/community/communication.rst:65 -msgid "Ansible community on IRC" -msgstr "IRCのAnsibleコミュニティ" - -#: ../../rst/community/communication.rst:67 -msgid "The Ansible community maintains several IRC channels on `irc.libera.chat `_. To join the community using IRC, you need one thing:" -msgstr "Ansibleコミュニティは、`irc.libera.chat `_にいくつかのIRCチャンネルを維持しています。IRCを使用してコミュニティに参加するには、次の1つが必要です。" - -#: ../../rst/community/communication.rst:69 -msgid "an IRC client" -msgstr "IRCクライアント" - -#: ../../rst/community/communication.rst:71 -msgid "IRC chat supports:" -msgstr "IRCチャットは以下をサポートします：" - -#: ../../rst/community/communication.rst:73 -msgid "no persistence (you only see messages when you are logged on unless you add a bouncer)" -msgstr "永続性なし（バウンサーを追加しない限り、ログオンしたときのメッセージしか表示されません）" - -#: ../../rst/community/communication.rst:74 -msgid "simple text interface" -msgstr "シンプルなテキストインターフェース" - -#: ../../rst/community/communication.rst:75 -msgid "bridging from Matrix" -msgstr "Matrixからのブリッジ" - -#: ../../rst/community/communication.rst:77 -msgid "Our IRC channels may require you to register your IRC nickname. If you receive an error when you connect or when posting a message, see `libera.chat's Nickname Registration guide `_ for instructions. To find all ``ansible`` specific channels on the libera.chat network, use the following command in your IRC client:" -msgstr "この IRC チャンネルでは、IRCのニックネームの登録が必要になる場合があります。接続時またはメッセージの投稿時にエラーが発生する場合は、「`libera.chat's Nickname Registration ガイド `_」を参照してください。libera.chatネットワークの``ansible``固有のチャネルをすべてを見つけるには、IRCクライアントで次のコマンドを使用します。" - -#: ../../rst/community/communication.rst:83 -msgid "as described in the `libera.chat docs `_." -msgstr "`libera.chat ドキュメント `_ に記載のとおり。" - -#: ../../rst/community/communication.rst:85 -msgid "Our channels record history on the Matrix side. The channel history can be viewed in a browser - all channels will report an appropriate link to ``chat.ansible.im`` in their Chanserv entrymsg upon joining the room. Alternatively, a URL of the form ``https://chat.ansible.im/#/room/# {IRC channel name}:libera.chat`` will also work, for example - for the #ansible-docs channel it would be `https://app.element.io/#/room/#ansible-docs:libera.chat`." -msgstr "チャンネルは Matrix 側で履歴を記録します。チャンネル履歴はブラウザーで表示できます。全チャンネルでは、Chanserv entrymsg に ``chat.ansible.im`` への適切なリンクが表示されます。または、#ansible-docs チャンネルの場合は ``https://chat.ansible.im/#/room/# {IRC channel name}:libera.chat``、#ansible-docs チャンネルの場合は `https://app.element.io/#/room/#ansible-docs:libera.chat` が使用できます。" - -#: ../../rst/community/communication.rst:90 -msgid "General channels" -msgstr "一般的なチャンネル" - -#: ../../rst/community/communication.rst:92 -msgid "The clickable links will take you directly to the relevant Matrix room in your browser; room/channel information is also given for use in other clients:" -msgstr "クリック可能なリンクをクリックすると、ブラウザで関連するMatrixルームに直接移動します。チャットルーム/チャンネル情報は、他のクライアントで使用するためにも提供されます。" - -#: ../../rst/community/communication.rst:94 -msgid "`Community social room and posting news for the Bullhorn newsletter `_ - ``Matrix: #social:ansible.com | IRC: #ansible-social``" -msgstr "`Community social room and posting news for the Bullhorn newsletter `_ - ``Matrix: #social:ansible.com | IRC: #ansible-social``" - -#: ../../rst/community/communication.rst:95 -msgid "`General usage and support questions `_ - ``Matrix: #users:ansible.com | IRC: #ansible``" -msgstr "`General usage and support questions `_ - ``Matrix: #users:ansible.com | IRC: #ansible``" - -#: ../../rst/community/communication.rst:96 -msgid "`Discussions on developer topics and code related to features or bugs `_ - ``Matrix: #devel:ansible.com | IRC: #ansible-devel``" -msgstr "`Discussions on developer topics and code related to features or bugs `_ - ``Matrix: #devel:ansible.com | IRC: #ansible-devel``" - -#: ../../rst/community/communication.rst:97 -msgid "`Discussions on community and collections related topics `_ - ``Matrix: #community:ansible.com | IRC: #ansible-community``" -msgstr "`Discussions on community and collections related topics `_ - ``Matrix: #community:ansible.com | IRC: #ansible-community``" - -#: ../../rst/community/communication.rst:99 -msgid "`For public community meetings `_ - ``Matrix: #meeting:ansible.im | IRC: #ansible-meeting``" -msgstr "`For public community meetings `_ - ``Matrix: #meeting:ansible.im | IRC: #ansible-meeting``" - -#: ../../rst/community/communication.rst:99 -msgid "We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page `_" -msgstr "通常は、上記のメーリングリストで告知されます。`meeting schedule and agenda page `_ を参照してください。" - -#: ../../rst/community/communication.rst:104 -msgid "Working groups" -msgstr "ワーキンググループ" - -#: ../../rst/community/communication.rst:106 -msgid "Many of our community `Working Groups `_ meet in chat. If you want to get involved in a working group, join the Matrix room or IRC channel where it meets or comment on the agenda." -msgstr "Ansible コミュニティーの `Working Groups `_ の多くが、チャットで活動しています。ワーキンググループに参加したい場合は、そのワーキンググループが活動しているMatrixのチャットルームまたはIRCチャンネルに参加したり、議題にコメントしたりしてください。" - -#: ../../rst/community/communication.rst:108 -msgid "`AAP Configuration as Code `_ - Matrix: `#aap_config_as_code:ansible.com `_" -msgstr "`AAP Configuration as Code `_ - マトリックス: `#aap_config_as_code:ansible.com `_" - -#: ../../rst/community/communication.rst:109 -msgid "`Amazon (AWS) Working Group `_ - Matrix: `#aws:ansible.com `_ | IRC: ``#ansible-aws``" -msgstr "`Amazon (AWS) Working Group `_ - Matrix: `#aws:ansible.com `_ | IRC: ``#ansible-aws``" - -#: ../../rst/community/communication.rst:110 -msgid "`AWX Working Group `_ - Matrix: `#awx:ansible.com `_ | IRC: ``#ansible-awx``" -msgstr "`AWX Working Group `_ - Matrix: `#awx:ansible.com `_ | IRC: ``#ansible-awx``" - -#: ../../rst/community/communication.rst:111 -msgid "`Azure Working Group `_ - Matrix: `#azure:ansible.com `_ | IRC: ``#ansible-azure``" -msgstr "`Azure Working Group `_ - Matrix: `#azure:ansible.com `_ | IRC: ``#ansible-azure``" - -#: ../../rst/community/communication.rst:112 -msgid "`Community Working Group `_ (including Meetups) - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community``" -msgstr "`Community Working Group `_ (Meetups を含む) - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community``" - -#: ../../rst/community/communication.rst:113 -msgid "`Container Working Group `_ - Matrix: `#container:ansible.com `_ | IRC: ``#ansible-container``" -msgstr "`Container Working Group `_ - Matrix: `#container:ansible.com `_ | IRC: ``#ansible-container``" - -#: ../../rst/community/communication.rst:114 -msgid "`Contributor Experience Working Group `_ - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community``" -msgstr "`Contributor Experience Working Group `_ - Matrix: `#community:ansible.com `_ | IRC: ``#ansible-community``" - -#: ../../rst/community/communication.rst:115 -msgid "`DigitalOcean Working Group `_ - Matrix: `#digitalocean:ansible.im `_ | IRC: ``#ansible-digitalocean``" -msgstr "`DigitalOcean Working Group `_ - Matrix: `#digitalocean:ansible.im `_ | IRC: ``#ansible-digitalocean``" - -#: ../../rst/community/communication.rst:116 -msgid "`Diversity Working Group `_ - Matrix: `#diversity:ansible.com `_ | IRC: ``#ansible-diversity``" -msgstr "`Diversity Working Group `_ - Matrix: `#diversity:ansible.com `_ | IRC: ``#ansible-diversity``" - -#: ../../rst/community/communication.rst:117 -msgid "`Docker Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel``" -msgstr "`Docker Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel``" - -#: ../../rst/community/communication.rst:118 -msgid "`Documentation Working Group `_ - Matrix: `#docs:ansible.com `_ | IRC: ``#ansible-docs``" -msgstr "`Documentation Working Group `_ - Matrix: `#docs:ansible.com `_ | IRC: ``#ansible-docs``" - -#: ../../rst/community/communication.rst:119 -msgid "`Galaxy Working Group `_ - Matrix: `#galaxy:ansible.com `_ | IRC: ``#ansible-galaxy``" -msgstr "`Galaxy Working Group `_ - Matrix: `#galaxy:ansible.com `_ | IRC: ``#ansible-galaxy``" - -#: ../../rst/community/communication.rst:120 -msgid "`JBoss Working Group `_ - Matrix: `#jboss:ansible.com `_ | IRC: ``#ansible-jboss``" -msgstr "`JBoss Working Group `_ - Matrix: `#jboss:ansible.com `_ | IRC: ``#ansible-jboss``" - -#: ../../rst/community/communication.rst:121 -msgid "`Kubernetes Working Group `_ - Matrix: `#kubernetes:ansible.com `_ | IRC: ``#ansible-kubernetes``" -msgstr "`Kubernetes Working Group `_ - Matrix: `#kubernetes:ansible.com `_ | IRC: ``#ansible-kubernetes``" - -#: ../../rst/community/communication.rst:122 -msgid "`Linode Working Group `_ - Matrix: `#linode:ansible.com `_ | IRC: ``#ansible-linode``" -msgstr "`Linode Working Group `_ - Matrix: `#linode:ansible.com `_ | IRC: ``#ansible-linode``" - -#: ../../rst/community/communication.rst:123 -msgid "`Molecule Working Group `_ (`testing platform for Ansible playbooks and roles `_) - Matrix: `#molecule:ansible.im `_ | IRC: ``#ansible-molecule``" -msgstr "`Molecule Working Group `_ (`testing platform for Ansible playbooks and roles `_) - Matrix: `#molecule:ansible.im `_ | IRC: ``#ansible-molecule``" - -#: ../../rst/community/communication.rst:124 -msgid "`MySQL Working Group `_ - Matrix: `#mysql:ansible.com `_" -msgstr "`MySQL Working Group `_ - マトリックス: `#mysql:ansible.com `_" - -#: ../../rst/community/communication.rst:125 -msgid "`Network Working Group `_ - Matrix: `#network:ansible.com `_ | IRC: ``#ansible-network``" -msgstr "`Network Working Group `_ - Matrix: `#network:ansible.com `_ | IRC: ``#ansible-network``" - -#: ../../rst/community/communication.rst:126 -msgid "`PostgreSQL Working Group `_ - Matrix: `#postgresql:ansible.com `_" -msgstr "`PostgreSQL Working Group `_ - Matrix: `#postgresql:ansible.com `_" - -#: ../../rst/community/communication.rst:127 -msgid "`Remote Management Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel``" -msgstr "`Remote Management Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel``" - -#: ../../rst/community/communication.rst:128 -msgid "`Security Automation Working Group `_ - Matrix: `#security-automation:ansible.com `_ | IRC: ``#ansible-security``" -msgstr "`Security Automation Working Group `_ - マトリックス: `#security-automation:ansible.com `_ | IRC: ``#ansible-security``" - -#: ../../rst/community/communication.rst:129 -msgid "`Storage Working Group `_ - Matrix: `#storage:ansible.com `_ | IRC: ``#ansible-storage``" -msgstr "`Storage Working Group `_ - マトリックス: `#storage:ansible.com `_ | IRC: ``#ansible-storage``" - -#: ../../rst/community/communication.rst:130 -msgid "`Testing Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel``" -msgstr "`Testing Working Group `_ - Matrix: `#devel:ansible.com `_ | IRC: ``#ansible-devel``" - -#: ../../rst/community/communication.rst:131 -msgid "`VMware Working Group `_ - Matrix: `#vmware:ansible.com `_ | IRC: ``#ansible-vmware``" -msgstr "`VMware Working Group `_ - Matrix: `#vmware:ansible.com `_ | IRC: ``#ansible-vmware``" - -#: ../../rst/community/communication.rst:132 -msgid "`Windows Working Group `_ - Matrix: `#windows:ansible.com `_ | IRC: ``#ansible-windows``" -msgstr "`Windows Working Group `_ - Matrix: `#windows:ansible.com `_ | IRC: ``#ansible-windows``" - -#: ../../rst/community/communication.rst:133 -msgid "`Ansible developer tools Group `_ - Matrix: `#devtools:ansible.com `_ | IRC: ``#ansible-devtools``" -msgstr "`Ansible developer tools Group `_ - Matrix: `#devtools:ansible.com `_ | IRC: ``#ansible-devtools``" - -#: ../../rst/community/communication.rst:135 -msgid "Want to `form a new Working Group `_?" -msgstr "`新しいワーキンググループ `を形成_しますか?" - -#: ../../rst/community/communication.rst:138 -msgid "Regional and Language-specific channels" -msgstr "地域および言語固有のチャンネル" - -#: ../../rst/community/communication.rst:140 -msgid "Comunidad Ansible en español - Matrix: `#espanol:ansible.im `_ | IRC: ``#ansible-es``" -msgstr "スペイン語のAnsibleコミュニティー - Matrix: `#espanol:ansible.im `_ | IRC: ``#ansible-es``" - -#: ../../rst/community/communication.rst:141 -msgid "Communauté française d'Ansible - Matrix: `#francais:ansible.im `_ | IRC: ``#ansible-fr``" -msgstr "フランス語のAnsibleコミュニティー - Matrix: `#francais:ansible.im `_ | IRC: ``#ansible-fr``" - -#: ../../rst/community/communication.rst:142 -msgid "Communauté suisse d'Ansible - Matrix: `#suisse:ansible.im `_ | IRC: ``#ansible-zh``" -msgstr "スイスのAnsibleコミュニティー - Matrix: `#suisse:ansible.im `_ | IRC: ``#ansible-zh``" - -#: ../../rst/community/communication.rst:143 -msgid "European Ansible Community - Matrix: `#europe:ansible.im `_ | IRC: ``#ansible-eu``" -msgstr "ヨーロッパのAnsibleコミュニティー - Matrix: `#europe:ansible.im `_ | IRC: ``#ansible-eu``" - -#: ../../rst/community/communication.rst:146 -msgid "Meetings on chat" -msgstr "チャットでの会議" - -#: ../../rst/community/communication.rst:148 -msgid "The Ansible community holds regular meetings on various topics on Matrix/IRC, and anyone who is interested is invited to participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page `_." -msgstr "Ansible コミュニティーは、Matrix/IRCでさまざまなトピックに関する定期的なミーティングを開いており、興味のある人は誰でも参加することができます。Ansible ミーティングの詳細は、`meeting schedule and agenda page `_ を参照してください。" - -#: ../../rst/community/communication.rst:151 -msgid "Ansible Community Topics" -msgstr "Ansible コミュニティーのトピック" - -#: ../../rst/community/communication.rst:153 -msgid "The `Ansible Community Steering Committee `_ uses the `community-topics repository `_ to asynchronously discuss with the Community and vote on Community topics in corresponding issues." -msgstr "`Ansible Community Steering Committee `_ は、`community-topics repository `_ を使用して、対応する issue のコミュニティーのトピックについて、コミュニティーで非同期に話し合い、投票します。" - -#: ../../rst/community/communication.rst:155 -msgid "Create a new issue in the `repository `_ if you want to discuss an idea that impacts any of the following:" -msgstr "以下のいずれかに影響を与えるアイデアについて話し合いたい場合は、`リポジトリー `_ で新しい issue を作成します。" - -#: ../../rst/community/communication.rst:157 -#: ../../rst/community/steering/community_steering_committee.rst:75 -msgid "Ansible Community" -msgstr "Ansible コミュニティー" - -#: ../../rst/community/communication.rst:158 -msgid "Community collection best practices and `requirements `_" -msgstr "コミュニティーコレクションのベストプラクティスと `要件 `_" - -#: ../../rst/community/communication.rst:159 -msgid "`Community collection inclusion policy `_" -msgstr "`Community collection inclusion policy `_" - -#: ../../rst/community/communication.rst:160 -msgid "`The Community governance `_" -msgstr "`The Community governance `_" - -#: ../../rst/community/communication.rst:161 -msgid "Other proposals of importance that need the Committee or overall Ansible community attention" -msgstr "Committee または Ansible コミュニティー全体の注意を必要とするその他の重要な提案" - -#: ../../rst/community/communication.rst:164 -msgid "Ansible Automation Platform support questions" -msgstr "Ansible Automation Platform サポートに関する質問" - -#: ../../rst/community/communication.rst:166 -msgid "Red Hat Ansible `Automation Platform `_ is a subscription that contains support, certified content, and tooling for Ansible including content management, a controller, UI and REST API." -msgstr "Red Hat Ansible `Automation Platform `_ は、コンテンツ管理、コントローラー、UI および REST API などの Ansible のサポート、認定コンテンツ、およびツールが含まれるサブスクリプションです。" - -#: ../../rst/community/communication.rst:168 -msgid "If you have a question about Ansible Automation Platform, visit `Red Hat support `_ rather than using a chat channel or the general project mailing list." -msgstr "Ansible Automation Platform に関するご質問は、チャットチャンネルまたは一般的なプロジェクトメーリングリストではなく、`Red Hat サポート `_ にお問い合わせください。" - -#: ../../rst/community/communication.rst:171 -msgid "The Bullhorn" -msgstr "The Bullhorn" - -#: ../../rst/community/communication.rst:173 -msgid "**The Bullhorn** is our newsletter for the Ansible contributor community. Please `subscribe `_ to receive it." -msgstr "**The Bullhorn** は、Ansible コントリビューターコミュニティー向けのニュースレターです。ニュースレターを受信するには、`サブスクライブ `_ してください。" - -#: ../../rst/community/communication.rst:175 -msgid "If you have any content you would like to share, please `contribute/suggest it `_ for upcoming releases." -msgstr "共有したいコンテンツがある場合は、今後のリリース用に `提供/提案 `_ してください。" - -#: ../../rst/community/communication.rst:177 -msgid "If you have any questions, please reach out to us at ``the-bullhorn@redhat.com``." -msgstr "ご不明な点がございましたら、``the-bullhorn@redhat.com`` までお問い合わせください。" - -#: ../../rst/community/communication.rst:179 -msgid "Read past issues on the official Bullhorn's `wiki page `_." -msgstr "過去の issue については、Bullhorn の公式の `wiki ページ `_ をお読みください。" - -#: ../../rst/community/contributing_maintained_collections.rst:6 -msgid "Contributing to Ansible-maintained Collections" -msgstr "Ansible 管理コレクションへの参加" - -#: ../../rst/community/contributing_maintained_collections.rst:8 -msgid "The Ansible team welcomes community contributions to the collections maintained by Red Hat Ansible Engineering. This section describes how you can open issues and create PRs with the required testing before your PR can be merged." -msgstr "Ansible チームは、Red Hat Ansible Engineering が管理するコレクションへのコミュニティーの貢献を歓迎します。このセクションでは、PR をマージする前に、問題を作成し、必要なテストで PR を作成する方法を説明します。" - -#: ../../rst/community/contributing_maintained_collections.rst:14 -msgid "Ansible-maintained collections" -msgstr "Ansible で管理されているコレクション" - -#: ../../rst/community/contributing_maintained_collections.rst:16 -msgid "The following table shows:" -msgstr "次の表に示します。" - -#: ../../rst/community/contributing_maintained_collections.rst:18 -msgid "**Ansible-maintained collection** - Click the link to the collection on Galaxy, then click the ``repo`` button in Galaxy to find the GitHub repository for this collection." -msgstr "**Ansible で管理されているコレクション** - Galaxy のコレクションへのリンクをクリックしてから、Galaxy の ``repo`` ボタンをクリックして、このコレクションの GitHub リポジトリーを検索します。" - -#: ../../rst/community/contributing_maintained_collections.rst:19 -msgid "**Related community collection** - Collection that holds community-created content (modules, roles, and so on) that may also be of interest to a user of the Ansible-maintained collection. You can, for example, add new modules to the community collection as a technical preview before the content is moved to the Ansible-maintained collection." -msgstr "**関連するコミュニティーコレクション** - コミュニティーで作成されたコンテンツ (モジュール、ロールなど) を保持するコレクションで、Ansible で管理されているコレクションのユーザーも関心を持つ可能性があります。たとえば、コンテンツが Ansible で管理されているコレクションに移動する前に、テクニカルプレビューとしてコミュニティーコレクションに新しいモジュールを追加できます。" - -#: ../../rst/community/contributing_maintained_collections.rst:20 -msgid "**Sponsor** - Working group that manages the collections. You can join the meetings to discuss important proposed changes and enhancements to the collections." -msgstr "**スポンサー**: コレクションを管理する作業グループ。ミーティングに参加して、コレクションに対する重要な変更および機能強化を検討することができます。" - -#: ../../rst/community/contributing_maintained_collections.rst:21 -msgid "**Test requirements** - Testing required for any new or changed content for the Ansible-maintained collection." -msgstr "**テスト要件**: Ansible が管理するコレクションの新しいコンテンツまたは変更されたコンテンツについてテスト。" - -#: ../../rst/community/contributing_maintained_collections.rst:22 -msgid "**Developer details** - Describes whether the Ansible-maintained collection accepts direct community issues and PRs for existing collection content, as well as more specific developer guidelines based on the collection type." -msgstr "**開発者の詳細**: Ansible が直接コミュニティーの問題と、既存のコレクションコンテンツの PR と、コレクションタイプに基づいてより具体的な開発者ガイドラインを受け入れるかどうかを説明します。" - -#: ../../rst/community/contributing_maintained_collections.rst:258 -msgid "\\* A ✓ under **Open to PRs** means the collection welcomes GitHub issues and PRs for any changes to existing collection content (plugins, roles, and so on)." -msgstr "\\* **Open to PRs** の下にある ✓ は、コレクションが GitHub の問題と既存のコレクションコンテンツ (プラグイン、ロールなど) への変更に対する PR を歓迎することを意味します。" - -#: ../../rst/community/contributing_maintained_collections.rst:260 -msgid "\\*\\* Integration tests are required and unit tests are welcomed but not required for the AWS collections. An exception to this is made in cases where integration tests are logistically not feasible due to external requirements. An example of this is AWS Direct Connect, as this service can not be functionally tested without the establishment of network peering connections. Unit tests are therefore required for modules that interact with AWS Direct Connect. Exceptions to ``amazon.aws`` must be approved by Red Hat, and exceptions to ``community.aws`` must be approved by the AWS community." -msgstr "\\*\\* 統合テストは必須であり、ユニットテストは歓迎されますが、AWS コレクションには必須ではありません。これに対する例外は、外部要件により統合テストが永続的に実行できない場合に生じます。この例として、AWS Direct Connect があります。これは、ネットワークピアリング接続を確立しないと、このサービスを機能的にテストできないためです。したがって、AWS Direct Connect と相互作用するモジュールにはユニットテストが必要です。``amazon.aws`` への例外は Red Hat によって承認され、``community.aws`` への例外は AWS コミュニティーによって承認される必要があります。" - -#: ../../rst/community/contributing_maintained_collections.rst:262 -msgid "\\*\\*\\* ``ansible.netcommon`` contains all foundational components for enabling many network and security :ref:`platform ` collections. It contains all connection and filter plugins required, and installs as a dependency when you install the platform collection." -msgstr "\\*\\*\\* ``ansible.netcommon`` には、多くのネットワークおよびセキュリティーの :ref:`プラットフォーム ` コレクションを有効にするための基本コンポーネントが含まれています。これには必要なすべての接続およびフィルタープラグインが含まれ、プラットフォームコレクションのインストール時に依存関係としてインストールされます。" - -#: ../../rst/community/contributing_maintained_collections.rst:264 -msgid "\\*\\*\\*\\* Unit tests for Windows PowerShell modules are an exception to testing, but unit tests are valid and required for the remainder of the collection, including Ansible-side plugins." -msgstr "\\*\\*\\*\\* Windows PowerShell モジュールのユニットテストは、テストの例外ですが、ユニットテストは、Ansible 側のプラグインを含め、コレクションの残りの部分に有効かつ必要になります。" - -#: ../../rst/community/contributing_maintained_collections.rst:270 -msgid "Deciding where your contribution belongs" -msgstr "貢献が所属する場所の決定" - -#: ../../rst/community/contributing_maintained_collections.rst:272 -msgid "We welcome contributions to Ansible-maintained collections. Because these collections are part of a downstream supported Red Hat product, the criteria for contribution, testing, and release may be higher than other community collections. The related community collections (such as ``community.general`` and ``community.network``) have less-stringent requirements and are a great place for new functionality that may become part of the Ansible-maintained collection in a future release." -msgstr "Ansible で管理されているコレクションへの貢献を歓迎します。これらのコレクションは、ダウンストリームでサポートされている Red Hat 製品の一部であるため、貢献、テスト、およびリリースの基準は、他のコミュニティーコレクションよりも高い場合があります。関連するコミュニティーコレクション (``community.general`` および ``community.network`` など) の要件はそれほど厳しくなく、将来のリリースで Ansible が管理するコレクションの一部になる可能性がある新しい機能に最適な場所です。" - -#: ../../rst/community/contributing_maintained_collections.rst:274 -msgid "The following scenarios use the ``arista.eos`` to help explain when to contribute to the Ansible-maintained collection, and when to propose your change or idea to the related community collection:" -msgstr "以下のシナリオでは、``arista.eos`` を使用して Ansible が管理しているコレクションに貢献するタイミングや、関連するコミュニティーコレクションに変更や考えを提案するタイミングを説明しています。" - -#: ../../rst/community/contributing_maintained_collections.rst:277 -msgid "You want to fix a problem in the ``arista.eos`` Ansible-maintained collection. Create the PR directly in the `arista.eos collection GitHub repository `_. Apply all the :ref:`merge requirements `." -msgstr "Ansible が管理する ``arista.eos`` コレクションの問題を修正します。PR を `arista.eos コレクションの GitHub リポジトリー `_ に直接作成します。:ref:`マージ要件 ` をすべて適用します。" - -#: ../../rst/community/contributing_maintained_collections.rst:279 -msgid "You want to add a new Ansible module for Arista. Your options are one of the following:" -msgstr "Arista の新しい Ansible モジュールを追加します。オプションは以下のいずれかになります。" - -#: ../../rst/community/contributing_maintained_collections.rst:281 -msgid "Propose a new module in the ``arista.eos`` collection (requires approval from Arista and Red Hat)." -msgstr "``arista.eos`` コレクションで新しいモジュールを実装します (Arista と Red Hat の承認が必要です)。" - -#: ../../rst/community/contributing_maintained_collections.rst:282 -msgid "Propose a new collection in the ``arista`` namespace (requires approval from Arista and Red Hat)." -msgstr "``arista`` 名前空間で新しいコレクションを提案します (Arista および Red Hat の承認が必要です)。" - -#: ../../rst/community/contributing_maintained_collections.rst:283 -msgid "Propose a new module in the ``community.network`` collection (requires network community approval)." -msgstr "``community.network`` コレクションで新しいモジュールを実装します (ネットワークコミュニティーの承認が必要です)。" - -#: ../../rst/community/contributing_maintained_collections.rst:284 -msgid "Place your new module in a collection in your own namespace (no approvals required)." -msgstr "新しいモジュールを独自の名前空間のコレクションに置きます (承認は必要ありません)。" - -#: ../../rst/community/contributing_maintained_collections.rst:287 -msgid "Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the ``arista`` namespace, where inclusion and maintenance criteria are much higher." -msgstr "ほとんどの新しいコンテンツは、最初に関連するコミュニティーのコレクションか、独自のコレクションのいずれかに入れ、コミュニティー内で十分に確立されてから、インクルージョンとメンテナンスの基準がはるかに高い ``arista`` 名前空間に追加することを提案する必要があります。" - -#: ../../rst/community/contributing_maintained_collections.rst:293 -msgid "Requirements to merge your PR" -msgstr "PR のマージ要件" - -#: ../../rst/community/contributing_maintained_collections.rst:295 -msgid "Your PR must meet the following requirements before it can merge into an Ansible-maintained collection:" -msgstr "Ansible が管理するコレクションにマージする前に、PR が以下の要件を満たす必要があります。" - -#: ../../rst/community/contributing_maintained_collections.rst:298 -msgid "The PR is in the intended scope of the collection. Communicate with the appropriate Ansible sponsor listed in the :ref:`Ansible-maintained collection table ` for help." -msgstr "PR はコレクションの範囲にあり、支援を得るために :ref:`Ansible 管理コレクションの表 ` に一覧表示されている適切な Ansible スポンサーに連絡します。" - -#: ../../rst/community/contributing_maintained_collections.rst:299 -msgid "For network and security domains, the PR follows the :ref:`resource module development principles `." -msgstr "ネットワークおよびセキュリティードメインの場合、プル要求は :ref:`リソースモジュール開発の原則 ` に従います。" - -#: ../../rst/community/contributing_maintained_collections.rst:300 -msgid "Passes :ref:`sanity tests and tox `." -msgstr ":ref:`sanity tests and tox ` を渡します。" - -#: ../../rst/community/contributing_maintained_collections.rst:301 -msgid "Passes unit, and integration tests, as listed in the :ref:`Ansible-maintained collection table ` and described in :ref:`testing_resource_modules`." -msgstr ":ref:`Ansible 管理コレクションの表 ` に一覧表示されているとおりに、ユニットテストおよび統合テストを渡します (:ref:`testing_resource_modules` を参照)。" - -#: ../../rst/community/contributing_maintained_collections.rst:302 -msgid "Follows Ansible guidelines. See :ref:`developing_modules` and :ref:`developing_collections`." -msgstr "Ansible ガイドラインに準拠します。「:ref:`developing_modules`」および「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/community/contributing_maintained_collections.rst:303 -msgid "Addresses all review comments." -msgstr "すべてのレビューコメントに対応します。" - -#: ../../rst/community/contributing_maintained_collections.rst:304 -msgid "Includes an appropriate :ref:`changelog `." -msgstr "これには、適切な :ref:`changelog ` が含まれます。" - -#: ../../rst/community/contributions.rst:5 -msgid "ansible-core Contributors Guide" -msgstr "ansible-core コントリビューターガイド" - -#: ../../rst/community/contributions.rst:16 -#: ../../rst/community/contributions_collections.rst:23 -msgid "If you have a specific Ansible interest or expertise (for example, VMware, Linode, and so on, consider joining a :ref:`working group `." -msgstr "Ansible に特定の関心や専門知識 (例: VMware、Linode など) がある方は、:ref:`ワークンググループ ` に参加することをご検討ください。" - -#: ../../rst/community/contributions.rst:19 -msgid "Working with the Ansible repo" -msgstr "Ansible リポジトリーの使用" - -#: ../../rst/community/contributions.rst:21 -msgid "I want to make my first code changes to a collection or to ``ansible-core``. How do I :ref:`set up my Python development environment `?" -msgstr "コレクションまたは ``ansible-core`` に初めてコード変更をします。:ref:`Python 開発環境をセットアップ ` するにはどうしたら良いですか。" - -#: ../../rst/community/contributions.rst:22 -msgid "I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts?" -msgstr "開発者としてもっと効率的に作業したいです。Ansible 開発をサポートする :ref:`エディター、Linter などのツール ` はどうやって見つければ良いですか。" - -#: ../../rst/community/contributions.rst:23 -msgid "I want my code to meet Ansible's guidelines. Where can I find guidance on :ref:`coding in Ansible `?" -msgstr "自分のコードを Ansible のガイドラインに沿ったものにしたいです。:ref:`Ansible でのコーディング ` に関するガイダンスはどこにありますか。" - -#: ../../rst/community/contributions.rst:24 -msgid "I would like to connect Ansible to a new API or other resource. How do I :ref:`create a collection `?" -msgstr "Ansible を新しい API やその他のリソースに接続したいです。:ref:`関連モジュールのグループに貢献 ` するにはどうすれば良いですか。" - -#: ../../rst/community/contributions.rst:25 -msgid "My pull request is marked ``needs_rebase``. How do I :ref:`rebase my PR `?" -msgstr "プル要求に ``needs_rebase`` というマークが付いています。:ref:`自分のプル要求をリベース ` するにはどうすれば良いですか。" - -#: ../../rst/community/contributions.rst:26 -msgid "I am using an older version of Ansible and want a bug fixed in my version that has already been fixed on the ``devel`` branch. How do I :ref:`backport a bugfix PR `?" -msgstr "Ansible の古いバージョンを使用していますが、``devel`` ブランチですでに修正されているバグを、私の使用しているバージョンで修正してほしいです。:ref:`バグ修正のプル要求 ` をバックポートするにはどうすれば良いですか。" - -#: ../../rst/community/contributions.rst:27 -msgid "I have an open pull request with a failing test. How do I learn about Ansible's :ref:`testing (CI) process `?" -msgstr "オープンになっているプル要求でテストに失敗しているものがあります。Ansible の :ref:`テスト (CI) プロセス ` について学ぶにはどうすれば良いですか。" - -#: ../../rst/community/contributions.rst:28 -msgid "I am ready to step up as a collection maintainer. What are the :ref:`guidelines for maintainers `?" -msgstr "コレクションメンテナーになりたいです。:ref:`メンテナー向けガイドライン ` を教えてください。" - -#: ../../rst/community/contributions.rst:29 -msgid "A module in a collection I maintain is obsolete. How do I :ref:`deprecate a module `?" -msgstr "私が保守しているモジュールが古くなりました。:ref:`モジュールを非推奨 ` にするにはどうすれば良いですか。" - -#: ../../rst/community/contributions_collections.rst:5 -msgid "Ansible Collections Contributor Guide" -msgstr "Ansible コレクションのコントリビューターガイド" - -#: ../../rst/community/contributions_collections.rst:26 -msgid "Working with the Ansible collection repositories" -msgstr "Ansible コレクションのリポジトリーの使用" - -#: ../../rst/community/contributions_collections.rst:28 -msgid "How can I find :ref:`editors, linters, and other tools ` that will support my Ansible development efforts?" -msgstr "Ansible 開発作業をサポートする :ref:`エディター、リンター、その他のツール ` を見つけるにはどうすれば良いですか。" - -#: ../../rst/community/contributions_collections.rst:29 -msgid "Where can I find guidance on :ref:`coding in Ansible `?" -msgstr ":ref:`Ansible におけるコーディング ` に関するガイダンスはどこにありますか。" - -#: ../../rst/community/contributions_collections.rst:30 -msgid "How do I :ref:`create a collection `?" -msgstr ":ref:`コレクションを作成 ` するにはどうすれば良いですか。" - -#: ../../rst/community/contributions_collections.rst:31 -msgid "How do I :ref:`rebase my PR `?" -msgstr ":ref:`PR をリベース ` するにはどうすれば良いですか。" - -#: ../../rst/community/contributions_collections.rst:32 -msgid "How do I learn about Ansible's :ref:`testing (CI) process `?" -msgstr "Ansible の :ref:`(CI) プロセスのテスト ` について知るにはどうすれば良いですか。" - -#: ../../rst/community/contributions_collections.rst:33 -msgid "How do I :ref:`deprecate a module `?" -msgstr ":ref:`モジュールを非推奨 ` にするにはどうすれば良いですか。" - -#: ../../rst/community/contributions_collections.rst:34 -msgid "See `Collection developer tutorials `_ for a quick introduction on how to develop and test your collection contributions." -msgstr "コレクションコントリビューターの開発とテストの概要は、`Collection developer tutorials `_ を参照してください。" - -#: ../../rst/community/contributor_license_agreement.rst:5 -msgid "Contributors License Agreement" -msgstr "貢献者のライセンス契約" - -#: ../../rst/community/contributor_license_agreement.rst:7 -msgid "By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project." -msgstr "By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project." - -#: ../../rst/community/contributor_path.rst:3 -msgid "Contributor path" -msgstr "コントリビューターパス" - -#: ../../rst/community/contributor_path.rst:5 -msgid "This section describes the contributor's journey from the beginning to becoming a leader who helps shape the future of Ansible. You can use this path as a roadmap for your long-term participation." -msgstr "このセクションでは、コントリビューターが Ansible の未来を形成するリーダーになるまでの道のりを最初から説明します。このパスは、参加者の長期的ロードマップとして使用できます。" - -#: ../../rst/community/contributor_path.rst:7 -msgid "Any contribution to the project, even a small one, is very welcome and valuable. Any contribution counts, whether it's feedback on an issue, a pull request, a topic or documentation change, or a coding contribution. When you contribute regularly, your proficiency and judgment in the related area increase and, along with this, the importance of your presence in the project." -msgstr "プロジェクトへの貢献は、それが小さいものであっても非常に有益です。issue に対するフィードバック、プル要求、ドキュメントの変更、コーディングなどのいずれかにかかわらず、あらゆるコントリビューションが有用です。定期的に貢献することで、関連する分野の習熟度と判断力が向上し、プロジェクトにおける存在の重要性も高まります。" - -#: ../../rst/community/contributor_path.rst:15 -msgid "Determine your area of interest" -msgstr "興味のある分野を決定する" - -#: ../../rst/community/contributor_path.rst:17 -msgid "First, determine areas that are interesting to you. Consider your current experience and what you'd like to gain. For example, if you use a specific collection, have a look there. See :ref:`how_can_i_help` for more ideas on how to help." -msgstr "まず、興味のある分野を決定します。現在の経験と、何を得たいかを考慮してください。たとえば、特定のコレクションを使用する場合は、それを検討してみてください。:ref:`how_can_i_help` も参照してください。" - -#: ../../rst/community/contributor_path.rst:20 -msgid "Find the corresponding project" -msgstr "対応するプロジェクトを探す" - -#: ../../rst/community/contributor_path.rst:22 -msgid "These are multiple community projects in the Ansible ecosystem you could contribute to:" -msgstr "以下は、貢献先となる一部の Ansible エコシステムのコミュニティープロジェクトです。" - -#: ../../rst/community/contributor_path.rst:24 -msgid "`Ansible Core `_" -msgstr "`Ansible Core `_" - -#: ../../rst/community/contributor_path.rst:25 -msgid "`Collections `_" -msgstr "`Collections `_" - -#: ../../rst/community/contributor_path.rst:26 -msgid "`AWX `_" -msgstr "`AWX `_" - -#: ../../rst/community/contributor_path.rst:27 -msgid "`Galaxy `_" -msgstr "`Galaxy `_" - -#: ../../rst/community/contributor_path.rst:28 -msgid "`ansible-lint `_" -msgstr "`ansible-lint `_" - -#: ../../rst/community/contributor_path.rst:29 -msgid "`Molecule `_" -msgstr "`Molecule `_" - -#: ../../rst/community/contributor_path.rst:32 -msgid "Learn" -msgstr "詳細情報" - -#: ../../rst/community/contributor_path.rst:34 -msgid "The required skillset depends on the area of interest and the project you'll be working on. Remember that the best way to learn is by doing." -msgstr "必要なスキルセットは、対象の分野と作業しているプロジェクトによって異なります。学ぶための最良の方法は行うことであることを忘れないでください。" - -#: ../../rst/community/contributor_path.rst:37 -msgid "Specific knowledge for code developers" -msgstr "コード開発者に必要な知識" - -#: ../../rst/community/contributor_path.rst:39 -msgid "Code development requires the most technical knowledge. Let's sort out what an Ansible developer should learn." -msgstr "コード開発には、最も技術的な知識が必要です。Ansible 開発者が学ぶ必要のある内容を分類してみましょう。" - -#: ../../rst/community/contributor_path.rst:42 -msgid "You should understand at least the *basics* of the following tools:" -msgstr "少なくとも以下のツールの *基本* を理解する必要があります。" - -#: ../../rst/community/contributor_path.rst:44 -msgid "`Python programming language `_" -msgstr "`Python programming language `_" - -#: ../../rst/community/contributor_path.rst:45 -msgid "`Git `_" -msgstr "`Git `_" - -#: ../../rst/community/contributor_path.rst:46 -msgid "`GitHub collaborative development model through forks and pull requests `_" -msgstr "`GitHub collaborative development model through forks and pull requests `_" - -#: ../../rst/community/contributor_path.rst:48 -msgid "You can learn these tools more in-depth when working on your first contributions." -msgstr "最初の貢献時に、これらのツールの詳細を学習できます。" - -#: ../../rst/community/contributor_path.rst:51 -msgid "Each Ansible project has its own set of contributor guidelines. Familiarize yourself with these as you prepare your first contributions." -msgstr "各 Ansible プロジェクトには、独自のコントリビューターガイドラインが一式あります。最初の貢献を準備する際に、これらのガイドを把握してください。" - -#: ../../rst/community/contributor_path.rst:53 -msgid ":ref:`Ansible Core development `." -msgstr ":ref:`Ansible Core development `。" - -#: ../../rst/community/contributor_path.rst:54 -msgid ":ref:`Ansible collection development ` and the collection-level contributor guidelines in the collection repository." -msgstr "コレクションリポジトリー内の、:ref:`Ansible collection development ` およびコレクションレベルのコントリビューターガイドライン。" - -#: ../../rst/community/contributor_path.rst:58 -msgid "Making your first contribution" -msgstr "初めて貢献する" - -#: ../../rst/community/contributor_path.rst:60 -msgid "You can find some ideas on how you can contribute in :ref:`how_can_i_help`." -msgstr "どのように貢献できるかについては、:ref:`how_can_i_help` にいくつかのアイデアが掲載されています。" - -#: ../../rst/community/contributor_path.rst:62 -msgid "If you are interested in contributing to collections, take a look at :ref:`collection contributions` and the `collection repository `_'s ``README`` and ``CONTRIBUTING`` files. To make your first experience as smooth as possible, read the repository documentation carefully, then ask the repository maintainers for guidance if you have any questions." -msgstr "コレクションへの貢献に関心がある場合は、:ref:`collection contributions` と`collection repository `_ の``README`` と``CONTRIBUTING`` ファイルを参照してください。最初の貢献をできるだけスムーズに進めるために、リポジトリーのドキュメントを慎重に読み、質問がある場合は、リポジトリーメンテナーに助言を求めてください。" - -#: ../../rst/community/contributor_path.rst:64 -msgid "Take a look at GitHub issues labeled with the ``easyfix`` and ``good_first_issue`` labels for:" -msgstr "``easyfix``と``good_first_issue`` でラベル付けされた GitHub の問題を見てください。" - -#: ../../rst/community/contributor_path.rst:66 -#, python-format -msgid "`Ansible collections repositories `_" -msgstr "`Ansible collections repositories `_" - -#: ../../rst/community/contributor_path.rst:67 -#: ../../rst/community/how_can_I_help.rst:67 -#, python-format -msgid "`All other Ansible projects `_" -msgstr "`All other Ansible projects `_" - -#: ../../rst/community/contributor_path.rst:69 -msgid "Issues labeled with the ``docs`` label in `Ansible collections `_ and `other `_ Ansible projects can be also good to start with." -msgstr "`Ansible collections `_ と`other `_ Ansible プロジェクトで、``docs`` のラベルが付いた問題から始めることもできます。" - -#: ../../rst/community/contributor_path.rst:71 -#: ../../rst/community/how_can_I_help.rst:69 -msgid "When you choose an issue to work on, add a comment directly on the GitHub issue to say you are looking at it and let others know to avoid conflicting work. You can also ask for help in a comment if you need it." -msgstr "作業する問題を選択する場合は、GitHub の問題に直接コメントを追加して、その問題を見ていることを伝え、競合する作業を避けるために他の人に知らせてください。必要に応じて、コメントでサポートを求めることもできます。" - -#: ../../rst/community/contributor_path.rst:75 -msgid "Continue to contribute" -msgstr "継続的に貢献する" - -#: ../../rst/community/contributor_path.rst:77 -msgid "We don't expect everybody to know everything. Start small, think big. When you contribute regularly, your proficiency and judgment in the related area will improve quickly and, along with this, the importance of your presence in the project." -msgstr "誰もがすべてを知っているとは限りません。小さく始めて、大きく考えてください。定期的に貢献すると、関連分野での習熟度と判断力が急速に向上し、それに伴い、プロジェクトでの存在の重要性も高まります。" - -#: ../../rst/community/contributor_path.rst:79 -msgid "See :ref:`communication` for ways to communicate and engage with the Ansible community, including working group meetings, accessing the Bullhorn news bulletin, and upcoming contributor summits." -msgstr "ワーキンググループのミーティング、Bullhorn ニュース速報へのアクセス、今後のコントリビューターサミットなど、Ansible コミュニティーとのコミュニケーションおよび三角方法については、:ref:`communication` を参照してください。" - -#: ../../rst/community/contributor_path.rst:83 -msgid "Teach others" -msgstr "他の人に教える" - -#: ../../rst/community/contributor_path.rst:85 -msgid "Share your experience with other contributors through :ref:`improving documentation`, answering questions from other contributors and users on :ref:`Matrix/Libera.Chat IRC`, giving advice on issues and pull requests, and discussing `Community Topics `_." -msgstr ":ref:`improving documentation` を通じて他のコントリビューターと経験を共有したり、:ref:`Matrix/Libera.Chat IRC` で他のコントリビューターやユーザーからの質問に答えたりできます。また、issue やプル要求に対して助言したり、`Community Topics `_ について議論したりもできます。" - -#: ../../rst/community/contributor_path.rst:88 -#: ../../rst/community/how_can_I_help.rst:75 -msgid "Become a collection maintainer" -msgstr "コレクションメンテナーになる" - -#: ../../rst/community/contributor_path.rst:90 -msgid "If you are a code contributor to a collection, you can get extended permissions in the repository and become a maintainer. A collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and showed themselves as a specialist in the related area. See :ref:`maintainers` for details." -msgstr "コレクションのコードコントリビューターである場合、リポジトリーで拡張パーミッションを取得してメンテナーになることができます。コレクションメンテナーはコミュニティーに信頼されるコントリビューターで、プロジェクトに大きく、定期的な貢献を行い、該当分野の専門家としての地位を示します。詳細は :ref:`maintainers` を参照してください。" - -#: ../../rst/community/contributor_path.rst:92 -msgid "For some collections that use the `collection bot `_, such as `community.general `_ and `community.network `_, you can have different levels of access and permissions." -msgstr "`community.general `_ や `community.network `_ などの `collection bot `_ を使用する一部のコレクションでは、異なるレベルのアクセスおよびパーミッションを設定できます。" - -#: ../../rst/community/contributor_path.rst:94 -msgid ":ref:`module_maintainers` - The stage prior to becoming a collection maintainer. The file is usually a module or plugin. File maintainers have indirect commit rights." -msgstr ":ref:`module_maintainers` - コレクションメンテナーになる前のステージ。通常、ファイルはモジュールまたはプラグインです。ファイルメンテナーには間接的なコミット権限があります。" - -#: ../../rst/community/contributor_path.rst:95 -msgid "supershipit permissions - Similar to being a file maintainer but the scope where a maintainer has the indirect commit is the whole repository." -msgstr "Supershipit パーミッション - ファイルメンテナーに似ていますが、メンテナーの持つ間接コミットの範囲はリポジトリー全体に及びます。" - -#: ../../rst/community/contributor_path.rst:96 -msgid "``triage`` - Access to the repository that allows contributors to manage issues and pull requests." -msgstr "``triage`` - コントリビューターによる issue およびプル要求の管理を可能にするリポジトリーへのアクセス。" - -#: ../../rst/community/contributor_path.rst:97 -msgid "``write`` access to the repository also known as ``commit``. In other words, become a committer. This access level allows contributors to merge pull requests to the development branch as well as perform all the other activities listed in the :ref:`maintainers`." -msgstr "``commit`` とも呼ばれるリポジトリーへの ``write`` アクセス。つまり、コミッターになります。コントリビューターはこのアクセスレベルで、開発ブランチにプル要求をマージでき、:ref:`maintainers` に記載されている他のすべてのアクティビティーも実行できます。" - -#: ../../rst/community/contributor_path.rst:99 -msgid "For information about permission levels, see the `GitHub official documentation `_." -msgstr "パーミッションレベルの詳細は、`GitHub official documentation `_ を参照してください。" - -#: ../../rst/community/contributor_path.rst:102 -msgid "Become a steering committee member" -msgstr "Steering Committee メンバーになる" - -#: ../../rst/community/contributor_path.rst:106 -msgid "You do NOT have to be a programmer to become a steering committee member." -msgstr "プログラマーでなくても、Steering Committee メンバーになれます。" - -#: ../../rst/community/contributor_path.rst:108 -msgid "The :ref:`Steering Committee ` member status reflects the highest level of trust which allows contributors to lead the project by making very important `decisions `_ for the Ansible project. The Committee members are the community leaders who shape the project's future and the future of automation in the IT world in general." -msgstr ":ref:`Steering Committee ` メンバーのステータスは、最高の信頼レベルを反映しています。これにより、コントリビューターは Ansible プロジェクトにとって非常に重要な `decisions `_ を作成してプロジェクトを牽引できます。Committee メンバーはコミュニティーのリーダーであり、プロジェクトの未来と IT 全般における自動化の未来を形成します。" - -#: ../../rst/community/contributor_path.rst:110 -msgid "To reach the status, as the current Committee members did before getting it, along with the things mentioned in this document, you should:" -msgstr "このステータスに達するには、現在の Cimmittee メンバーがメンバーになる前に行ったように、このドキュメントに記載した内容の他にも以下を行う必要があります。" - -#: ../../rst/community/contributor_path.rst:112 -msgid "Subscribe to, comment on, and vote on the `Community Topics `_." -msgstr "`Community Topics `_ でサブスクライブ、コメント、評価を行います。" - -#: ../../rst/community/contributor_path.rst:113 -msgid "Propose your topics." -msgstr "トピックを提案します。" - -#: ../../rst/community/contributor_path.rst:114 -msgid "If time permits, join the `Community meetings `_. Note this is **NOT** a requirement." -msgstr "時間があれば、`Community meetings `_ に参加します。これは必須では **ありません**。" - -#: ../../rst/community/create_pr_quick_start.rst:5 -msgid "Creating your first collection pull request" -msgstr "最初のコレクションのプルリクエストの作成" - -#: ../../rst/community/create_pr_quick_start.rst:7 -msgid "This section describes all steps needed to create your first patch and submit a pull request on a collection." -msgstr "本セクションでは、最初のパッチを作成し、コレクションにプルリクエストを送信するために必要なすべての手順について説明します。" - -#: ../../rst/community/create_pr_quick_start.rst:16 -msgid "These steps assume a Linux work environment with ``git`` installed." -msgstr "以下の手順は、``git`` がインストールされている Linux の作業環境を想定しています。" - -#: ../../rst/community/create_pr_quick_start.rst:19 -msgid "Install and start ``docker`` or ``podman``. This ensures tests run properly isolated and in the same environment as in CI." -msgstr "``docker`` または ``podman`` をインストールして起動します。これにより、CI と同じ環境で、正しく分離してテストが実行されるようにします。" - -#: ../../rst/community/create_pr_quick_start.rst:21 -msgid ":ref:`Install Ansible or ansible-core `. You need the ``ansible-test`` utility which is provided by either of these packages." -msgstr ":ref:`Ansible または ansible-core のインストール `. これらのパッケージのいずれかによって提供される ``ansible-test`` ユーティリティーが必要です。" - -#: ../../rst/community/create_pr_quick_start.rst:30 -msgid "For example, if the collection is ``community.mysql``, it would be:" -msgstr "たとえば、コレクションが ``community.mysql`` の場合、以下のようになります。" - -#: ../../rst/community/create_pr_quick_start.rst:37 -msgid "Fork the collection repository through the GitHub web interface." -msgstr "GitHub Web インターフェースを介してコレクションリポジトリーをフォークします。" - -#: ../../rst/community/create_pr_quick_start.rst:51 -msgid "Go to your new cloned repository." -msgstr "新しくクローンを作成したリポジトリーに移動します。" - -#: ../../rst/community/create_pr_quick_start.rst:57 -msgid "Ensure you are in the default branch (it is usually ``main``):" -msgstr "デフォルトのブランチにいることを確認します (通常は ``main``)。" - -#: ../../rst/community/create_pr_quick_start.rst:63 -msgid "Show remotes. There should be the ``origin`` repository only:" -msgstr "リモートを表示します。``origin`` リポジトリーのみが存在するはずです。" - -#: ../../rst/community/create_pr_quick_start.rst:69 -msgid "Add the ``upstream`` repository:" -msgstr "``upstream`` リポジトリーを追加します。" - -#: ../../rst/community/create_pr_quick_start.rst:75 -msgid "This is the repository where you forked from." -msgstr "これは、フォーク元となったリポジトリーです。" - -#: ../../rst/community/create_pr_quick_start.rst:77 -msgid "Update your local default branch. Assuming that it is ``main``:" -msgstr "ローカルのデフォルトブランチを更新します。``main`` であると想定します。" - -#: ../../rst/community/create_pr_quick_start.rst:84 -msgid "Create a branch for your changes:" -msgstr "変更用のブランチを作成します。" - -#: ../../rst/community/create_pr_quick_start.rst:91 -msgid "Change the code" -msgstr "コードの変更" - -#: ../../rst/community/create_pr_quick_start.rst:95 -msgid "Do NOT mix several bug fixes or features that are not tightly related in one pull request. Use separate pull requests for different changes." -msgstr "1 つのプルリクエストに密接に関連していない複数のバグ修正または機能を混在させないでください。変更ごとに個別のプルリクエストを使用します。" - -#: ../../rst/community/create_pr_quick_start.rst:97 -msgid "You should start with writing integration and unit tests if applicable. These can verify the bug exists (prior to your code fix) and verify your code fixed that bug once the tests pass." -msgstr "該当する場合は、統合テストとユニットテストの作成から開始する必要があります。これらは、(コードの修正前に) バグが存在することを確認し、テストに合格するとコードがそのバグを修正したことを確認できます。" - -#: ../../rst/community/create_pr_quick_start.rst:101 -msgid "If there are any difficulties with writing or running the tests or you are not sure if the case can be covered, you can skip this step. Other contributors can help you with tests later if needed." -msgstr "テストの作成や実行に問題がある場合や、そのケースがカバーできるかどうかわからない場合は、この手順を省略できます。必要に応じて、他のコントリビューターが後でテストをサポートすることができます。" - -#: ../../rst/community/create_pr_quick_start.rst:105 -msgid "Some collections do not have integration tests. In this case, unit tests are required." -msgstr "一部のコレクションには統合テストがありません。この場合、ユニットテストが必要です。" - -#: ../../rst/community/create_pr_quick_start.rst:107 -msgid "All integration tests are stored in ``tests/integration/targets`` subdirectories. Go to the subdirectory containing the name of the module you are going to change. For example, if you are fixing the ``mysql_user`` module in the ``community.mysql`` collection, its tests are in ``tests/integration/targets/test_mysql_user/tasks``." -msgstr "すべての統合テストは ``tests/integration/targets`` サブディレクトリーに保存されます。変更するモジュールの名前が含まれるサブディレクトリーに移動します。たとえば、``community.mysql`` コレクションで ``mysql_user`` モジュールを修正する場合は、テストは ``tests/integration/targets/test_mysql_user/tasks`` にあります。" - -#: ../../rst/community/create_pr_quick_start.rst:112 -msgid "The ``main.yml`` file holds test tasks and includes other test files. Look for a suitable test file to integrate your tests or create and include a dedicated test file. You can use one of the existing test files as a draft." -msgstr "``main.yml`` ファイルは、テストタスクを保持し、他のテストファイルを含みます。テストの統合に適切なテストファイルを探すか、専用のテストファイルを作成して追加します。既存のテストファイルの 1 つをドラフトとして使用することができます。" - -#: ../../rst/community/create_pr_quick_start.rst:116 -msgid "When fixing a bug, write a task that reproduces the bug from the issue." -msgstr "バグを修正する際に、問題からバグを再現するタスクを作成します。" - -#: ../../rst/community/create_pr_quick_start.rst:118 -msgid "Put the reported case in the tests, then run integration tests with the following command:" -msgstr "報告されたケースをテストに入れてから、以下のコマンドで統合テストを実行します。" - -#: ../../rst/community/create_pr_quick_start.rst:124 -msgid "For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is as follows:" -msgstr "たとえば、変更したテストファイルが ``tests/integration/targets/test_mysql_user/`` に保存されている場合、コマンドは以下のようになります。" - -#: ../../rst/community/create_pr_quick_start.rst:132 -msgid "In the examples above, the default test image is automatically downloaded and used to create and run a test container. Use the default test image for platform-independent integration tests such as those for cloud modules." -msgstr "上記の例では、デフォルトのテストイメージが自動的にダウンロードされ、テストコンテナーの作成と実行に使用されます。クラウドモジュールなどに向けたプラットフォームに依存しない統合テストには、デフォルトのテストイメージを使用します。" - -#: ../../rst/community/create_pr_quick_start.rst:135 -msgid "If you need to run the tests against a specific distribution, see the :ref:`list of supported container images `. For example:" -msgstr "特定のディストリビューションに対してテストを実行する必要がある場合は、:ref:`サポート対象のコンテナーイメージの一覧 ` を参照してください。以下に例を示します。" - -#: ../../rst/community/create_pr_quick_start.rst:143 -msgid "If you are not sure whether you should use the default image for testing or a specific one, skip the entire step - the community can help you later. You can also try to use the collection repository's CI to figure out which containers are used." -msgstr "テストにデフォルトのイメージを使用するか、特定のイメージを使用するかわからない場合は、手順全体をスキップしてください。後でコミュニティーでサポートします。コレクションリポジトリーの CI を使用して、使用されているコンテナーを特定することもできます。" - -#: ../../rst/community/create_pr_quick_start.rst:145 -msgid "If the tests ran successfully, there are usually two possible outcomes:" -msgstr "テストが正常に実行された場合、通常は以下の 2 つの結果が考えられます。" - -#: ../../rst/community/create_pr_quick_start.rst:147 -msgid "If the bug has not appeared and the tests have passed successfully, ask the reporter to provide more details. It may not be a bug or can relate to a particular software version used or specifics of the reporter's local environment configuration." -msgstr "バグが発生しておらず、テストが合格した場合は、レポーターにさらなる詳細を提供するよう依頼してください。バグではない可能性、または使用されている特定のソフトウェアバージョンまたはレポーターのローカル環境設定の詳細に関連している可能性があります。" - -#: ../../rst/community/create_pr_quick_start.rst:148 -msgid "The bug has appeared and the tests have failed as expected showing the reported symptoms." -msgstr "バグが発生し、テストは予想どおりに失敗し、報告された症状が示されました。" - -#: ../../rst/community/create_pr_quick_start.rst:151 -msgid "Fix the bug" -msgstr "バグを修正する" - -#: ../../rst/community/create_pr_quick_start.rst:153 -msgid "See :ref:`module_contribution` for some general guidelines about Ansible module development that may help you craft a good code fix for the bug." -msgstr "バグに対して適切なコード修正を作成するのに役立つ Ansible モジュール開発に関する一般的なガイドラインの一部については、:ref:`module_contribution` を参照してください。" - -#: ../../rst/community/create_pr_quick_start.rst:156 -msgid "Test your changes" -msgstr "変更をテストする" - -#: ../../rst/community/create_pr_quick_start.rst:158 -msgid "Install ``flake8`` (``pip install flake8``, or install the corresponding package on your operating system)." -msgstr "``flake8`` をインストールします (``pip install flake8``、またはオペレーティングシステムに対応するパッケージをインストールします)。" - -#: ../../rst/community/create_pr_quick_start.rst:160 -msgid "Run ``flake8`` against a changed file:" -msgstr "変更されたファイルに対して ``flake8`` を実行します。" - -#: ../../rst/community/create_pr_quick_start.rst:167 -msgid "This shows unused imports, which are not shown by sanity tests, as well as other common issues. Optionally, you can use the ``--max-line-length=160`` command-line argument." -msgstr "これは、健全性テストによって表示されない未使用のインポートと、その他の一般的な issue を示しています。オプションで、``--max-line-length=160`` コマンドライン引数を使用できます。" - -#: ../../rst/community/create_pr_quick_start.rst:170 -msgid "Run sanity tests:" -msgstr "健全性テストの実行:" - -#: ../../rst/community/create_pr_quick_start.rst:176 -msgid "If they failed, look at the output carefully - it is informative and helps to identify a problem line quickly. Sanity failings usually relate to incorrect code and documentation formatting." -msgstr "テストが失敗した場合は、出力を注意深く確認してください。出力は有益であり、問題のある行をすばやく特定する上で役立ちます。健全性テストの失敗は通常、誤ったコードとドキュメントのフォーマットに関連しています。" - -#: ../../rst/community/create_pr_quick_start.rst:179 -msgid "Run integration tests:" -msgstr "統合テストの実行" - -#: ../../rst/community/create_pr_quick_start.rst:185 -msgid "For example, if the test files you changed are stored in ``tests/integration/targets/test_mysql_user/``, the command is:" -msgstr "たとえば、変更したテストファイルが ``tests/integration/targets/test_mysql_user/`` に保存されている場合、コマンドは以下のようになります。" - -#: ../../rst/community/create_pr_quick_start.rst:194 -msgid "There are two possible outcomes:" -msgstr "考えられる結果は 2 つあります。" - -#: ../../rst/community/create_pr_quick_start.rst:196 -msgid "They have failed. Look at the output of the command. Fix the problem in the code and run again. Repeat the cycle until the tests pass." -msgstr "テストに失敗しました。コマンドの出力で確認してみてください。コード内の問題箇所を修正し、再度実行します。テストに合格するまでこのサイクルを繰り返します。" - -#: ../../rst/community/create_pr_quick_start.rst:197 -msgid "They have passed. Remember they failed originally? Our congratulations! You have fixed the bug." -msgstr "テストに合格しました。最初は失敗だったことを覚えていますか? おめでとうございます! バグが修正されました。" - -#: ../../rst/community/create_pr_quick_start.rst:199 -msgid "In addition to the integration tests, you can also cover your changes with unit tests. This is often required when integration tests are not applicable to the collection." -msgstr "統合テストの他に、ユニットテストで変更に対応することもできます。これは、統合テストがコレクションに適用できない場合に必要になることがよくあります。" - -#: ../../rst/community/create_pr_quick_start.rst:201 -msgid "We use `pytest `_ as a testing framework." -msgstr "`pytest `_ をテストフレームワークとして使用します。" - -#: ../../rst/community/create_pr_quick_start.rst:203 -msgid "Files with unit tests are stored in the ``tests/unit/plugins/`` directory. If you want to run unit tests, say, for ``tests/unit/plugins/test_myclass.py``, the command is:" -msgstr "ユニットテストを含むファイルは、``tests/unit/plugins/`` ディレクトリーに保存されます。ユニットテストを実行する場合 (``tests/unit/plugins/test_myclass.py`` の場合)、コマンドは以下のようになります。" - -#: ../../rst/community/create_pr_quick_start.rst:209 -msgid "If you want to run all unit tests available in the collection, run:" -msgstr "コレクションで利用可能なユニットテストをすべて実行する場合は、以下を実行します。" - -#: ../../rst/community/create_pr_quick_start.rst:216 -msgid "Submit a pull request" -msgstr "プルリクエストを送信する" - -#: ../../rst/community/create_pr_quick_start.rst:218 -msgid "Commit your changes with an informative but short commit message:" -msgstr "有益であるが短いコミットメッセージで、変更をコミットします。" - -#: ../../rst/community/create_pr_quick_start.rst:225 -msgid "Push the branch to ``origin`` (your fork):" -msgstr "ブランチを ``origin`` (ご利用のフォーク) にプッシュします。" - -#: ../../rst/community/create_pr_quick_start.rst:231 -msgid "In a browser, navigate to the ``upstream`` repository (http://github.com/ansible-collections/COLLECTION_REPO)." -msgstr "ブラウザーで、``upstream`` リポジトリー (http://github.com/ansible-collections/COLLECTION_REPO) に移動します。" - -#: ../../rst/community/create_pr_quick_start.rst:233 -msgid "Click the :guilabel:`Pull requests` tab." -msgstr ":guilabel:`Pull requests` タブをクリックします。" - -#: ../../rst/community/create_pr_quick_start.rst:235 -msgid "GitHub is tracking your fork, so it should see the new branch in it and automatically offer to create a pull request. Sometimes GitHub does not do it, and you should click the :guilabel:`New pull request` button yourself. Then choose :guilabel:`compare across forks` under the :guilabel:`Compare changes` title." -msgstr "GitHub はフォークを追跡しているため、フォーク内に新しいブランチが表示され、プルリクエストの作成が自動的に提案されます。GitHub が提案しない場合もあるので、その場合はご自身で `New pull request` ボタンを押してください。続いて、guilabel:`Compare changes` タイトルの下にある `compare across forks` を選択します。" - -#: ../../rst/community/create_pr_quick_start.rst:237 -msgid "Choose your repository and the new branch you pushed in the right drop-down list. Confirm." -msgstr "リポジトリーとプッシュした新しいブランチを右側のドロップダウンリストから選択します。確認します。" - -#: ../../rst/community/create_pr_quick_start.rst:239 -msgid "Fill out the pull request template with all information you want to mention." -msgstr "プルリクエストテンプレートに、言及したいすべての情報を記入します。" - -#: ../../rst/community/create_pr_quick_start.rst:241 -msgid "Put ``Fixes + link to the issue`` in the pull request's description." -msgstr "プル要求の説明に ``修正 + issue へのリンク`` を追加します。" - -#: ../../rst/community/create_pr_quick_start.rst:243 -msgid "Put ``[WIP] + short description`` in the pull request's title. Mention the name of the module/plugin you are modifying at the beginning of the description." -msgstr "プル要求のタイトルに ``[WIP] + 短い説明`` を追加します。説明の最初に、変更するモジュール/プラグインの名前を記載します。" - -#: ../../rst/community/create_pr_quick_start.rst:245 -msgid "Click :guilabel:`Create pull request`." -msgstr ":guilabel:`Create pull request` をクリックします。" - -#: ../../rst/community/create_pr_quick_start.rst:247 -msgid "Add a :ref:`changelog fragment ` to the ``changelogs/fragments`` directory. It will be published in release notes, so users will know about the fix." -msgstr ":ref:`changelog フラグメント ` を ``changelogs/fragments`` ディレクトリーに追加します。これはリリースノートで公開されるため、ユーザーは修正について知ることができます。" - -#: ../../rst/community/create_pr_quick_start.rst:249 -msgid "Run the sanity test for the fragment:" -msgstr "フラグメントの健全性テストを実行します。" - -#: ../../rst/community/create_pr_quick_start.rst:256 -msgid "If the tests passed, commit and push the changes:" -msgstr "テストに合格した場合は、変更をコミットおよびプッシュします。" - -#: ../../rst/community/create_pr_quick_start.rst:264 -msgid "Verify the CI tests pass that run automatically on Red Hat infrastructure after every commit." -msgstr "コミットするたびに、Red Hat インフラストラクチャーで自動的に実行される CI テストに合格することを確認します。" - -#: ../../rst/community/create_pr_quick_start.rst:266 -msgid "You will see the CI status at the bottom of your pull request. If they are green and you think that you do not want to add more commits before someone should take a closer look at it, remove ``[WIP]`` from the title. Mention the issue reporter in a comment and let contributors know that the pull request is \"Ready for review\"." -msgstr "プル要求の下部に CI ステータスが表示されます。それらが緑色で、コミットをさらに追加する前に、誰かに詳しく見てもらいたいと思う場合は、タイトルから ``[WIP]`` を削除します。コメントに issue レポーターを記載し、プルリクエストが \"Ready for review\" であることをコントリビューターに知らせます。" - -#: ../../rst/community/create_pr_quick_start.rst:268 -msgid "Wait for reviews. You can also ask for a review in the ``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel `." -msgstr "レビューを待ちます。``#ansible-community`` :ref:`Matrix/Libera.Chat IRC channel ` でもレビューを依頼することができます。" - -#: ../../rst/community/create_pr_quick_start.rst:270 -msgid "If the pull request looks good to the community, committers will merge it." -msgstr "プル要求がコミュニティーにとって良さそうな場合は、コミット担当者はそれをマージします。" - -#: ../../rst/community/create_pr_quick_start.rst:272 -msgid "For more in-depth details on this process, see the :ref:`Ansible developer guide `." -msgstr "このプロセスの詳細は、:ref:`Ansible 開発者ガイド ` を参照してください。" - -#: ../../rst/community/development_process.rst:5 -msgid "The Ansible Development Cycle" -msgstr "Ansible 開発ライフサイクル" - -#: ../../rst/community/development_process.rst:7 -msgid "Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository `_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections." -msgstr "Ansible 開発者 (コミュニティーの貢献者を含む) は、多くの異なるリポジトリーで新機能を追加し、バグを修正し、コードを更新します。`ansible/ansible リポジトリー `_には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能および関数のコードが含まれています。このコードは、``ansible-core`` と呼ばれています。他のリポジトリーには、Ansible が特定のタスク (特定のデータベースへのユーザーの追加や特定のネットワークデバイスの設定など) を実行できるようにするプラグインおよびモジュールが含まれています。これらのリポジトリーには、コレクションのソースコードが含まれています。" - -#: ../../rst/community/development_process.rst:9 -msgid "Development on ``ansible-core`` occurs on two levels. At the macro level, the ``ansible-core`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle." -msgstr "``ansible-core`` の 開発は 2 つのレベルで行われます。マクロレベルでは、``ansible-core`` 開発者とメンテナーがリリースの計画を立て、ロードマップおよびプロジェクトを使用して進捗を追跡します。ミクロレベルでは、各プル要求には独自のライフサイクルがあります。" - -#: ../../rst/community/development_process.rst:11 -msgid "Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``." -msgstr "コレクションに関する開発は、マクロレベルおよびミクロレベルでも発生します。各コレクションには独自のマクロ開発サイクルがあります。コレクション開発サイクルの詳細は、:ref:`contributing_maintained_collections` を参照してください。プル要求のマイクロレベルのライフサイクルは、コレクションと ``ansible-core`` で似ています。" - -#: ../../rst/community/development_process.rst:17 -msgid "Macro development: ``ansible-core`` roadmaps, releases, and projects" -msgstr "マクロ開発: ``ansible-core`` のロードマップ、リリース、およびプロジェクト" - -#: ../../rst/community/development_process.rst:19 -msgid "If you want to follow the conversation about what features will be added to ``ansible-core`` for upcoming releases and what bugs are being fixed, you can watch these resources:" -msgstr "今後のリリースに向けて ``ansible-core`` にどのような機能が追加されるのか、どのようなバグが修正されるのかについてのやりとりを見逃さないようにする場合は、これらのリソースをフォローしてください。" - -#: ../../rst/community/development_process.rst:23 -msgid "the :ref:`ansible-core project branches and tags `" -msgstr ":ref:`ansible-core project branches and tags `" - -#: ../../rst/community/development_process.rst:24 -msgid "various GitHub `projects `_ - for example:" -msgstr "さまざまな GitHub `プロジェクト `_ - 以下に例を示します。" - -#: ../../rst/community/development_process.rst:26 -msgid "the `2.15 release project `_" -msgstr "`2.15 release project `_" - -#: ../../rst/community/development_process.rst:27 -msgid "the `core documentation project `_" -msgstr "`core documentation project `_" - -#: ../../rst/community/development_process.rst:36 -msgid "If you want to contribute a feature or fix a bug in ``ansible-core`` or in a collection, you must open a **pull request** (\"PR\" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-core``. Here's an overview of the PR lifecycle:" -msgstr "``ansible-core`` またはコレクションの機能追加またはバグ修正を行う場合は、**プルリクエスト** (略して \"PR\") を作成する必要があります。GitHubでは、`プルリクエストプロセスの仕組み `_ 全般に関するすばらしい概要を提供しています。プルリクエストの最終目標は、マージされ、コレクションまたは ``ansible-core`` の一部になることです。プルリクエストライフサイクルの概要は、以下のようになります。" - -#: ../../rst/community/development_process.rst:39 -msgid "Contributor opens a PR (always against the ``devel`` branch)" -msgstr "コントリビューターが PR を開きます (常に ``devel`` ブランチに対して)。" - -#: ../../rst/community/development_process.rst:40 -msgid "Ansibot reviews the PR" -msgstr "Ansibot が PR をレビューします。" - -#: ../../rst/community/development_process.rst:41 -msgid "Ansibot assigns labels" -msgstr "Ansibot がラベルを割り当てます。" - -#: ../../rst/community/development_process.rst:42 -msgid "Ansibot pings maintainers" -msgstr "Ansibot がメンテナーに連絡 (ping) します。" - -#: ../../rst/community/development_process.rst:43 -msgid "Azure Pipelines runs the test suite" -msgstr "Azure Pipelines がテストスイートを実行します。" - -#: ../../rst/community/development_process.rst:48 -msgid "PR :ref:`backported ` to one or more ``stable-X.Y`` branches (optional, bugfixes only)" -msgstr "1 つ以上の ``stable-X.Y`` ブランチに対して PR :ref:`backported ` を実行します (任意、バグ修正のみ)。" - -#: ../../rst/community/development_process.rst:51 -msgid "Automated PR review: ansibullbot" -msgstr "自動プル要求確認: ansibullbot" - -#: ../../rst/community/development_process.rst:53 -msgid "Because Ansible receives many pull requests, and because we love automating things, we have automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short." -msgstr "Ansible は多くのプル要求を受け取るため、またこのコミュニティーは自動化に興味があるため、Ansibullbot (略して Ansibot) と呼ばれるツールを使ってプル要求を確認してマージするプロセスのいくつかのステップを自動化しました。" - -#: ../../rst/community/development_process.rst:55 -msgid "`Ansibullbot `_ serves many functions:" -msgstr "`Ansibullbot `_ は多くの機能を提供します。" - -#: ../../rst/community/development_process.rst:57 -msgid "Responds quickly to PR submitters to thank them for submitting their PR" -msgstr "プル要求の提出者に迅速に対応し、プル要求提出のお礼を伝えます。" - -#: ../../rst/community/development_process.rst:58 -msgid "Identifies the community maintainer responsible for reviewing PRs for any files affected" -msgstr "影響を受けるファイルのプル要求のレビューを担当するコミュニティーメンテナーを特定します。" - -#: ../../rst/community/development_process.rst:59 -msgid "Tracks the current status of PRs" -msgstr "プル要求の現在のステータスを追跡します。" - -#: ../../rst/community/development_process.rst:60 -msgid "Pings responsible parties to remind them of any PR actions for which they may be responsible" -msgstr "責任のあるユーザーに連絡 (ping) して、プル要求に対して責任を負う可能性のあるすべての行為を喚起します。" - -#: ../../rst/community/development_process.rst:61 -msgid "Provides maintainers with the ability to move PRs through the workflow" -msgstr "メンテナーに、ワークフロー全体でプル要求を動かす権限を追加します。" - -#: ../../rst/community/development_process.rst:62 -msgid "Identifies PRs abandoned by their submitters so that we can close them" -msgstr "提出者が放棄したプル要求を特定してクローズします。" - -#: ../../rst/community/development_process.rst:63 -msgid "Identifies modules abandoned by their maintainers so that we can find new maintainers" -msgstr "メンテナーが中断したモジュールを特定し、新しいメンテナーを見つけられるようにします。" - -#: ../../rst/community/development_process.rst:66 -msgid "Ansibot workflow" -msgstr "Ansibot ワークフロー" - -#: ../../rst/community/development_process.rst:68 -msgid "Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:" -msgstr "Ansibullbot は継続的に実行されます。通常、提出した問題やプル要求の内容は、30 分もあれば確認できるようになります。Ansibullbot は、リポジトリー内のすべての未解決のプル要求を調べて、以下のワークフローに従って状態を強制します。" - -#: ../../rst/community/development_process.rst:70 -msgid "If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to \"reboot\" this process.)" -msgstr "プル要求にワークフローラベルがない場合は、**new** と見なされます。プル要求に含まれるファイルが特定され、ボットがそのファイルのメンテナーに通知を送り、プル要求を確認する方法が指示されます (注記: 時々、プル要求からラベルを削除して、このプロセスを「再起動」することがあります)。" - -#: ../../rst/community/development_process.rst:71 -msgid "If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state." -msgstr "モジュールのメンテナーが ``$team_ansible`` でない場合は、プル要求が **community_review** 状態になります。" - -#: ../../rst/community/development_process.rst:72 -msgid "If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while)." -msgstr "モジュールのメンテナーが ``$team_ansible`` の場合、プル要求は **core_review** 状態になります (そして、おそらくしばらくそのままになります)。" - -#: ../../rst/community/development_process.rst:73 -msgid "If the pull request is in **community_review** and has received comments from the maintainer:" -msgstr "プル要求が **community_review** にあり、メンテナーからコメントを受け取った場合は、以下のようになります。" - -#: ../../rst/community/development_process.rst:75 -msgid "If the maintainer says ``shipit``, the pull request is labeled **shipit**, whereupon the Core team assesses it for final merge." -msgstr "メンテナーが ``shipit`` と判断すると、プル要求に **shipit** というラベルが付けられ、Core チームが最終的なマージのためにそれを評価します。" - -#: ../../rst/community/development_process.rst:76 -msgid "If the maintainer says ``needs_info``, the pull request is labeled **needs_info** and the submitter is asked for more info." -msgstr "メンテナーが ``needs_info`` と判断すると、プル要求に **needs_info** というラベルが付けられ、提出したユーザーには詳細情報の提供が求められます。" - -#: ../../rst/community/development_process.rst:77 -msgid "If the maintainer says **needs_revision**, the pull request is labeled **needs_revision** and the submitter is asked to fix some things." -msgstr "メンテナーが **needs_revision** と判断すると、プル要求に **needs_revision** というラベルが付けられ、提出したユーザーは一部修正を求められます。" - -#: ../../rst/community/development_process.rst:79 -msgid "If the submitter says ``ready_for_review``, the pull request is put back into **community_review** or **core_review** and the maintainer is notified that the pull request is ready to be reviewed again." -msgstr "提出したユーザーが ``ready_for_review`` と判断すると、そのプル要求は **community_review** または **core_review** に戻され、プル要求の再レビューの準備ができたことがメンテナーに通知されます。" - -#: ../../rst/community/development_process.rst:80 -msgid "If the pull request is labeled **needs_revision** or **needs_info** and the submitter has not responded lately:" -msgstr "プル要求に **needs_revision** または **needs_info** というラベルが付けられ、提出したユーザーが応答しない場合は、以下のようになります。" - -#: ../../rst/community/development_process.rst:82 -msgid "The submitter is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending action**, and the issue or pull request will be closed two weeks after that." -msgstr "提出したユーザーは 2 週間後に丁寧な通知を受け取り、さらに 2 週間後に再度連絡が入り、**pending action** (保留中) というラベルが付けられ、その 2 週間後に問題またはプル要求がクローズになります。" - -#: ../../rst/community/development_process.rst:83 -msgid "If the submitter responds at all, the clock is reset." -msgstr "提出したユーザーが応答すると、タイマーがリセットされます。" - -#: ../../rst/community/development_process.rst:84 -msgid "If the pull request is labeled **community_review** and the reviewer has not responded lately:" -msgstr "プル要求に **community_review** というラベルが付けられ、レビュー担当者が応答しない場合は、以下のようになります。" - -#: ../../rst/community/development_process.rst:86 -msgid "The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer." -msgstr "レビューアーは 2 週間後に丁寧な通知を受け取り、さらに 2 週間後に再度通知があり、**pending_action** と表示されます。その後、``$team_ansible`` に再アサインされたり、**core_review** というラベルが付きます。もしくは、プル要求の提出者がメンテナーとしてステップアップするように求められることがよくあります。" - -#: ../../rst/community/development_process.rst:87 -msgid "If Azure Pipelines tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why." -msgstr "Azure Pipelines テストが失敗したり、コードをマージできないと、プル要求は自動的に **needs_revision** に置かれ、その理由を説明するメッセージが提出したユーザーに送られます。" - -#: ../../rst/community/development_process.rst:89 -msgid "There are corner cases and frequent refinements, but this is the workflow in general." -msgstr "めったに発生しない場合や、頻繁に改良される場合がありますが、これは一般的なワークフローです。" - -#: ../../rst/community/development_process.rst:92 -msgid "PR labels" -msgstr "プル要求のラベル" - -#: ../../rst/community/development_process.rst:94 -msgid "There are two types of PR Labels generally: **workflow** labels and **information** labels." -msgstr "一般的に、プル要求には、**ワークフロー** ラベルおよび **情報** ラベルの 2 つのタイプがあります。" - -#: ../../rst/community/development_process.rst:97 -msgid "Workflow labels" -msgstr "ワークフローラベル" - -#: ../../rst/community/development_process.rst:99 -msgid "**community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community." -msgstr "**community_review**: Ansible コミュニティーのメンテナーが確認するのを現在待っているモジュールのプル要求。" - -#: ../../rst/community/development_process.rst:100 -msgid "**core_review**: Pull requests for modules that are currently awaiting review by their maintainers on the Ansible Core team." -msgstr "**core_review**: 現在 Ansible Core チームのメンテナーによる確認を待っているモジュールのプル要求。" - -#: ../../rst/community/development_process.rst:101 -msgid "**needs_info**: Waiting on info from the submitter." -msgstr "**needs_info**: 提出したユーザーからの情報を待っています。" - -#: ../../rst/community/development_process.rst:102 -msgid "**needs_rebase**: Waiting on the submitter to rebase." -msgstr "**needs_rebase**: 提出したユーザーがリベースを行うのを待っています。" - -#: ../../rst/community/development_process.rst:103 -msgid "**needs_revision**: Waiting on the submitter to make changes." -msgstr "**needs_revision**: 提出したユーザーが変更を行うのを待っています。" - -#: ../../rst/community/development_process.rst:104 -msgid "**shipit**: Waiting for final review by the core team for potential merge." -msgstr "**shipit**: マージの可能性があるかどうか、Core チームによる最終レビューを待っています。" - -#: ../../rst/community/development_process.rst:107 -msgid "Information labels" -msgstr "情報ラベル" - -#: ../../rst/community/development_process.rst:109 -msgid "**backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``." -msgstr "**backport**: PR が devel 以外のブランチに対して要求されると自動的に適用されます。ボットは、すぐにラベルバックポートと ``core_review`` を割り当てます。" - -#: ../../rst/community/development_process.rst:110 -msgid "**bugfix_pull_request**: applied by the bot based on the templatized description of the PR." -msgstr "**bugfix_pull_request**: プル要求のテンプレート化された説明に基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:111 -msgid "**cloud**: applied by the bot based on the paths of the modified files." -msgstr "**cloud**: 変更されたファイルのパスに基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:112 -msgid "**docs_pull_request**: applied by the bot based on the templatized description of the PR." -msgstr "**docs_pull_request**: プル要求のテンプレート化された説明に基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:113 -msgid "**easyfix**: applied manually, inconsistently used but sometimes useful." -msgstr "**easyfix**: 手動で適用され、その使用は一貫性はありまあせんが、場合によっては役に立ちます。" - -#: ../../rst/community/development_process.rst:114 -msgid "**feature_pull_request**: applied by the bot based on the templatized description of the PR." -msgstr "**feature_pull_request**: プル要求のテンプレート化された説明に基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:115 -msgid "**networking**: applied by the bot based on the paths of the modified files." -msgstr "**networking**: 変更されたファイルのパスに基づいてボットが適用します。" - -#: ../../rst/community/development_process.rst:116 -msgid "**owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**." -msgstr "**owner_pr**: 大半が非推奨になりました。以前はワークフローでしたが、現在は情報提供です。元々、メンテナーから提出されたプル要求は、このラベルに基づいて自動的に **shipit** に送られていました。提出したユーザーがメンテナーでもある場合、他のメンテナーに通知しても、(提出したユーザーを含む) メンテナーの一人に **shipit** を提供するように要求するようになりました。" - -#: ../../rst/community/development_process.rst:117 -msgid "**pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on)." -msgstr "**pending_action**: ボットにより、変化のないプル要求に適用されます。コミュニティーチームが 2、３ 週間ごとにレビューし、適切なアクション (終了、新しいメンテナーの募集など) を考えます。" - -#: ../../rst/community/development_process.rst:121 -msgid "Special Labels" -msgstr "特殊なラベル" - -#: ../../rst/community/development_process.rst:123 -msgid "**new_plugin**: this is for new modules or plugins that are not yet in Ansible." -msgstr "**new_plugin**: これは Ansible にない新しいモジュールやプラグインのためのものです。" - -#: ../../rst/community/development_process.rst:125 -msgid "**Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process." -msgstr "**注記：** `new_plugin` は完全に別のプロセスを起動しますが、率直に言って現在はあまりうまく機能していません。このプロセスを改善するために最善を尽くしています。" - -#: ../../rst/community/development_process.rst:128 -msgid "Human PR review" -msgstr "ユーザーによるプル要求のレビュー" - -#: ../../rst/community/development_process.rst:130 -msgid "After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies." -msgstr "Ansibot がプル要求をレビューしてラベルを適用したら、ユーザーがプル要求をレビューする準備が整います。いずれのプル要求でも、それをレビューする可能性が高いのは、プル要求が変更するモジュールのメンテナーです。" - -#: ../../rst/community/development_process.rst:132 -msgid "Each module has at least one assigned :ref:`maintainer `, listed in the `BOTMETA.yml `_ file." -msgstr "各モジュールには、:ref:`メンテナー ` が少なくとも 1 人が割り当てられており、`BOTMETA.yml ` ファイルにその一覧があります。" - -#: ../../rst/community/development_process.rst:134 -msgid "The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``." -msgstr "メンテナーの仕事は、そのモジュールに影響を与えるプル要求をレビューして、マージ (``shipit``) すべきか修正 (``needs_revision``) すべきかを判断することです。すべてのモジュールには少なくともコミュニティーのメンテナーが 1 人必要です。モジュールにコミュニティーメンテナーが割り当てられていないと、そのメンテナーは ``$team_ansible`` として表示されます。" - -#: ../../rst/community/development_process.rst:136 -msgid "Once a human applies the ``shipit`` label, the :ref:`committers ` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable." -msgstr "ユーザーが ``shipit`` ラベルを適用すると、:ref:`コミット担当者 ` は、プル要求がマージする準備ができているかどうかを判断します。``shipit`` ラベルを取得したすべてのプル要求が実際にマージ可能な状態になるわけではありませんが、レビュー担当者が優秀で、コミュニティーのガイドラインが優れていればいるほど、**shipit** に到達したプル要求がマージされる可能性が高くなります。" - -#: ../../rst/community/development_process.rst:142 -msgid "We do not merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy." -msgstr "すべてのプル要求をマージするわけではありません。ここでは、プル要求を有益で魅力的で、マージする価値のあるものにするためのヒントをいくつかご紹介します。" - -#: ../../rst/community/development_process.rst:149 -msgid "Changelogs help users and developers keep up with changes to ansible-core and Ansible collections. Ansible and many collections build changelogs for each release from fragments. For ansible-core and collections using this model, you **must** add a changelog fragment to any PR that changes functionality or fixes a bug." -msgstr "変更ログは、ユーザーおよび開発者が ansible-core および Ansible コレクションへの変更情報を確認するのに役に立ちます。Ansible と多くのコレクションは、フラグメントからリリースごとに変更ログを作成します。このモデルを使用する ansible-core およびコレクションの場合は、機能を変更したり、バグを修正したりするすべてのプル要求に changelog フラグメントを追加する必要があります。" - -#: ../../rst/community/development_process.rst:175 -msgid "PRs which add a new module or plugin do not necessarily need a changelog fragment. See the previous section :ref:`community_changelogs`. Also see the next section :ref:`changelogs_how_to_format` for the precise format changelog fragments should have." -msgstr "新しいモジュールまたはプラグインを追加するプル要求は必ずしも changelog フラグメントを必要としません。前のセクション「:ref:`community_changelogs`」を参照してください。また、changelog フラグメントの正確な形式は、「:ref:`changelogs_how_to_format`」を参照してください。" - -#: ../../rst/community/development_process.rst:199 -msgid "Minor changes to ansible-core, modules, or plugins. This includes new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding additional values to choices[]. Minor changes are enhancements, not bug fixes. Write in present tense." -msgstr "ansible-core、モジュール、またはプラグインへのマイナーな変更。これには、モジュールに追加された新しいパラメーターや、choices[] に値を追加するなど、既存のパラメーターに対する中断のない動作の変更が含まれます。マイナーな変更は機能拡張であり、バグ修正ではありません。現在形で書いてください。" - -#: ../../rst/community/development_process.rst:208 -msgid "Features that have been deprecated and are scheduled for removal in a future release. Use past tense and include an alternative, where available for what is being deprecated.. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "非推奨となり、今後のリリースで削除される予定の機能です。過去形を使用して、非推奨となったものの代替として利用できるものを追加します。changelog と :ref:`移植ガイド ` の両方に表示されています。" - -#: ../../rst/community/development_process.rst:217 -msgid "Features that were previously deprecated and are now removed. Use past tense and include an alternative, where available for what is being deprecated. Displayed in both the changelogs and the :ref:`Porting Guides `." -msgstr "以前非推奨となり、現在は削除されている機能です。過去形を使用して、非推奨となったものの代替として利用できるものを追加します。changelog と :ref:`移植ガイド ` の両方に表示されています。" - -#: ../../rst/community/development_process.rst:226 -msgid "Fixes that address CVEs or resolve security concerns. MUST use security_fixes for any CVEs. Use present tense. Include links to CVE information." -msgstr "CVE に対処するか、セキュリティー上の懸念を解決する修正。CVE には security_fixes を使用する必要があります。現在形を使用します。CVE 情報へのリンクを含めます。" - -#: ../../rst/community/development_process.rst:235 -msgid "Fixes that resolve issues. SHOULD not be used for minor enhancements (use ``minor_change`` instead). Use past tense to describe the problem and present tense to describe the fix." -msgstr "問題を解決するための修正です。マイナーな機能強化には使用しないでください (代わりに ``minor_change`` を使用)。過去形を使用して問題を説明し、現在形を使用して修正を説明します。" - -#: ../../rst/community/development_process.rst:244 -msgid "Known issues that are currently not fixed or will not be fixed. Use present tense and where available, use imperative tense for a workaround." -msgstr "現在修正されていない、または修正される予定のない既知の問題。現在形を使用し、可能な場合は、回避策には命令形を使用します。" - -#: ../../rst/community/development_process.rst:254 -msgid "Most changelog entries are ``bugfixes`` or ``minor_changes``. The changelog tool also supports ``trivial``, which are not listed in the actual changelog output but are used by collections repositories that require a changelog fragment for each PR." -msgstr "ほとんどの changelog エントリーは ``bugfixes`` または ``minor_changes`` です。changelog ツールは、``trivial`` もサポートします。これは、実際の changelog 出力には記載されていませんが、各プル要求の changelog フラグメントを必要とするコレクションリポジトリーで使用されます。" - -#: ../../rst/community/development_process.rst:298 -msgid "You can find more example changelog fragments in the `changelog directory `_ for the 2.12 release." -msgstr "changelog フラグメントの例は、2.12 リリースの `changelog ディレクトリー `_ にもあります。" - -#: ../../rst/community/development_process.rst:305 -msgid "Changelog fragment entry format for new playbooks" -msgstr "新規 Playbook の changelog フラグメントのエントリー形式" - -#: ../../rst/community/development_process.rst:307 -msgid "While new modules, plugins, and roles are mentioned automatically in the generated changelog, playbooks are not. To make sure they are mentioned, a changelog fragment in a specific format is needed:" -msgstr "生成された Changelog には自動的に新しいモジュール、プラグイン、ロールが記録されますが、Playbook はされません。これらが含まれるようにするには、特定の形式の changelog フラグメントが必要です。" - -#: ../../rst/community/development_process.rst:323 -msgid "Backporting merged PRs in ``ansible-core``" -msgstr "``ansible-core`` にマージされたプル要求のバックポート" - -#: ../../rst/community/development_process.rst:325 -msgid "All ``ansible-core`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch." -msgstr "``ansible-core`` のプル要求はすべて、最初に ``devel`` ブランチにマージする必要があります。プル要求を受け入れて、``devel`` ブランチにマージした後、以下の手順でプル要求を作成して、変更を以前の安定したブランチにバックポートします。" - -#: ../../rst/community/development_process.rst:327 -msgid "We do **not** backport features." -msgstr "機能のバックポートは **行いません**。" - -#: ../../rst/community/development_process.rst:331 -msgid "These instructions assume that:" -msgstr "これらの手順は、以下を前提としています。" - -#: ../../rst/community/development_process.rst:333 -msgid "``stable-2.14`` is the targeted release branch for the backport" -msgstr "``stable-2.14`` は、バックポートのターゲットリリースブランチです。" - -#: ../../rst/community/development_process.rst:334 -msgid "``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly." -msgstr "``https://github.com/ansible/ansible.git`` は、``upstream`` という名前の ``git remote`` として設定されます。``upstream`` という名前の ``git remote`` を使用しない場合は、適切に手順を調整します。" - -#: ../../rst/community/development_process.rst:335 -msgid "``https://github.com//ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly." -msgstr "``https://github.com//ansible.git`` は、``origin`` という名前の ``git remote`` として設定されます。``origin`` という名前の ``git remote`` を使用しない場合は、適切に手順を調整します。" - -#: ../../rst/community/development_process.rst:337 -msgid "Prepare your devel, stable, and feature branches:" -msgstr "devel、stable、および feature のブランチを準備します。" - -#: ../../rst/community/development_process.rst:344 -msgid "Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:" -msgstr "devel ブランチから関連するコミットの SHA を自身の feature ブランチに選別して、必要に応じてマージの競合を処理します。" - -#: ../../rst/community/development_process.rst:350 -msgid "Add a :ref:`changelog fragment ` for the change, and commit it." -msgstr "変更には :ref:`changelog フラグメント ` を追加し、コミットします。" - -#: ../../rst/community/development_process.rst:352 -msgid "Push your feature branch to your fork on GitHub:" -msgstr "feature ブランチを GitHub のフォークにプッシュします。" - -#: ../../rst/community/development_process.rst:358 -msgid "Submit the pull request for ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.14`` branch" -msgstr "``stable-2.14`` ブランチに、``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` のプルリクエストを送信します。" - -#: ../../rst/community/development_process.rst:360 -msgid "The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green." -msgstr "次のマイナーリリースまでにバックポートのプル要求をマージするかどうかはリリースマネージャーが判断します。フォローアップの必要はありません。自動テスト (CI) に問題が発生していないことを確認するだけです。" - -#: ../../rst/community/development_process.rst:364 -msgid "The branch name ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches." -msgstr "ブランチ名 ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` は任意ですが、ブランチの目的がわかるようにします。このブランチ名の形式は必須ではありませんが、特に複数の安定したブランチに対して複数のバックポートプルリクエストを作成する場合に役立ちます。" - -#: ../../rst/community/development_process.rst:368 -msgid "If you prefer, you can use CPython's cherry-picker tool (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits from devel to stable branches in Ansible. Take a look at the `cherry-picker documentation `_ for details on installing, configuring, and using it." -msgstr "必要に応じて、CPython の cherry-picker ツール (``pip install --user 'cherry-picker >= 1.3.2'``) を使用して、Ansible の devel から安定したブランチへのコミットをバックポートすることができます。インストール、設定、および使用方法の詳細は、「`cherry-picker のドキュメント `_」を参照してください。" - -#: ../../rst/community/documentation_contributions.rst:5 -msgid "Contributing to the Ansible Documentation" -msgstr "Ansible ドキュメントへの貢献" - -#: ../../rst/community/documentation_contributions.rst:7 -msgid "Ansible has a lot of documentation and a small team of writers. Community support helps us keep up with new features, fixes, and changes." -msgstr "Ansible ではドキュメントが多数提供されていますが、ドキュメントを作成するチームは小規模です。新機能、修正、および変更の情報を常に最新に保つには、コミュニティーによるサポートが重要です。" - -#: ../../rst/community/documentation_contributions.rst:9 -msgid "Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText `_ (rST). Some collection-level documentation is written in a subset of `Markdown `_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option." -msgstr "ドキュメントへの改善は、Ansible プロジェクトへの最初の貢献として適しています。本ガイドの大部分は YAML (モジュールドキュメント) または `reStructuredText `_ (rST) で記述されているため、貢献者がプログラマーである必要はありません。コレクションレベルのドキュメントの一部は、`マークダウン `_ のサブセットに記述されています。Ansible を使用している場合は、Playbook ですでに YAML を使用しています。そして、rST および Markdown はほとんどがテキストです。``Edit on GitHub`` オプションを使用すれば、git の経験も必要ではありません。" - -#: ../../rst/community/documentation_contributions.rst:11 -msgid "If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation:" -msgstr "このドキュメントの Web サイトで、タ誤字や不備のある例、欠落しているトピック、またはその他のエラーや省略を見つけたらご連絡ください。Ansible ドキュメントをサポートする方法は次のとおりです。" - -#: ../../rst/community/documentation_contributions.rst:17 -msgid "Editing docs directly on GitHub" -msgstr "GitHub でドキュメントを直接編集" - -#: ../../rst/community/documentation_contributions.rst:19 -msgid "For typos and other quick fixes, you can edit most of the documentation right from the site. Look at the top right corner of this page. That ``Edit on GitHub`` link is available on all the guide pages in the documentation. If you have a GitHub account, you can submit a quick and easy pull request this way." -msgstr "入力ミスやその他の簡単な修正は、サイトから直接ドキュメントを編集できます。このページの右上を見てください。``Edit on GitHub`` リンクは、ドキュメント内のすべてのページで利用できます。GitHub アカウントがある場合は、この方法で迅速かつ簡単なプル要求を送信できます。" - -#: ../../rst/community/documentation_contributions.rst:23 -msgid "The source files for individual collection plugins exist in their respective repositories. Follow the link to the collection on Galaxy to find where the repository is located and any guidelines on how to contribute to that collection." -msgstr "個別のコレクションプラグインのソースファイルがそれぞれのリポジトリーに存在します。Galaxy 上のコレクションへのリンクに従い、リポジトリーの場所と、そのコレクションへの貢献方法を確認してください。" - -#: ../../rst/community/documentation_contributions.rst:25 -msgid "To submit a documentation PR from docs.ansible.com with ``Edit on GitHub``:" -msgstr "``Edit on GitHub`` で docs.ansible.com からドキュメント PR を送信するには、以下を行います。" - -#: ../../rst/community/documentation_contributions.rst:27 -msgid "Click on ``Edit on GitHub``." -msgstr "``Edit on GitHub`` をクリックします。" - -#: ../../rst/community/documentation_contributions.rst:28 -msgid "If you don't already have a fork of the ansible repo on your GitHub account, you'll be prompted to create one." -msgstr "GitHub アカウントで ansible リポジトリーのフォークを所有していない場合は、作成するように促されます。" - -#: ../../rst/community/documentation_contributions.rst:29 -msgid "Fix the typo, update the example, or make whatever other change you have in mind." -msgstr "タイプミスを修正したり、例文を更新したり、その他の変更を加えたりします。" - -#: ../../rst/community/documentation_contributions.rst:30 -msgid "Enter a commit message in the first rectangle under the heading ``Propose file change`` at the bottom of the GitHub page. The more specific, the better. For example, \"fixes typo in my_module description\". You can put more detail in the second rectangle if you like. Leave the ``+label: docsite_pr`` there." -msgstr "GitHub ページの一番下にある ``Propose file change`` という見出しの下にある最初の四角い部分にコミットメッセージを入力します。より具体的な方が望ましいです。たとえば「fixes typo in my_module description (my_module の説明にあるタイポを修正)」といった具合です。2 つの目の四角い部分に詳細を記入することもできます。ここで、``+label: docsite_pr`` はそのままにしておきます。" - -#: ../../rst/community/documentation_contributions.rst:31 -msgid "Submit the suggested change by clicking on the green \"Propose file change\" button. GitHub will handle branching and committing for you, and open a page with the heading \"Comparing Changes\"." -msgstr "緑色の「Propose file change」ボタンをクリックして、提案する変更を送信します。GitHub がブランチを作成してコミットを行い、「Comparing Changes」という見出しのページが開きます。" - -#: ../../rst/community/documentation_contributions.rst:32 -msgid "Click on ``Create pull request`` to open the PR template." -msgstr "``Create pull request`` をクリックして PR テンプレートを開きます。" - -#: ../../rst/community/documentation_contributions.rst:33 -msgid "Fill out the PR template, including as much detail as appropriate for your change. You can change the title of your PR if you like (by default it's the same as your commit message). In the ``Issue Type`` section, delete all lines except the ``Docs Pull Request`` line." -msgstr "PR テンプレートには、変更に適した詳細などを記入します。PR のタイトルは、必要に応じて変更できます (デフォルトでは、コミットメッセージと同じタイトルになっています)。``Issue Type`` セクションで、``Docs Pull Request`` 行を除くすべての行を削除します。" - -#: ../../rst/community/documentation_contributions.rst:34 -msgid "Submit your change by clicking on ``Create pull request`` button." -msgstr "``Create pull request`` ボタンをクリックして、変更内容を送信します。" - -#: ../../rst/community/documentation_contributions.rst:35 -msgid "Be patient while Ansibot, our automated script, adds labels, pings the docs maintainers, and kicks off a CI testing run." -msgstr "Ansibot という名前の自動スクリプトがラベルを追加し、ドキュメントのメンテナーに通知を送り、CI テストが開始されるのをお待ちください。" - -#: ../../rst/community/documentation_contributions.rst:36 -msgid "Keep an eye on your PR - the docs team may ask you for changes." -msgstr "送信した PR に注意を払い続けてください。ドキュメントチームから変更を依頼される場合があります。" - -#: ../../rst/community/documentation_contributions.rst:39 -msgid "Reviewing or solving open issues" -msgstr "未解決の問題の確認または解決" - -#: ../../rst/community/documentation_contributions.rst:41 -msgid "Review or solve open documentation issues for:" -msgstr "次の未解決のドキュメントの問題を確認または解決します。" - -#: ../../rst/community/documentation_contributions.rst:43 -msgid "`Ansible projects `_" -msgstr "`Ansible projects `_" - -#: ../../rst/community/documentation_contributions.rst:44 -msgid "`Ansible collections `_" -msgstr "`Ansible collections `_" - -#: ../../rst/community/documentation_contributions.rst:47 -msgid "Reviewing open PRs" -msgstr "Open となっている PR の確認" - -#: ../../rst/community/documentation_contributions.rst:49 -msgid "Review open documentation pull requests for:" -msgstr "以下の Open となっているドキュメントプルリクエストを確認します。" - -#: ../../rst/community/documentation_contributions.rst:51 -msgid "Ansible `projects `_" -msgstr "Ansible `projects `_" - -#: ../../rst/community/documentation_contributions.rst:52 -msgid "Ansible `collections `_" -msgstr "Ansible `collections `_" - -#: ../../rst/community/documentation_contributions.rst:54 -msgid "To add a helpful review, please:" -msgstr "役立つレビューを追加するには、次の手順に従ってください。" - -#: ../../rst/community/documentation_contributions.rst:56 -msgid "Test the change if applicable." -msgstr "該当する場合は、変更をテストします。" - -#: ../../rst/community/documentation_contributions.rst:57 -msgid "Think if it can be made better (including wording, structure, fixing typos and so on)." -msgstr "改善できるかどうかを考えてください (文言、構造、タイプミスの修正などを含む)。" - -#: ../../rst/community/documentation_contributions.rst:58 -msgid "Suggest improvements." -msgstr "改善内容を提案します。" - -#: ../../rst/community/documentation_contributions.rst:59 -msgid "Approve the change with the ``looks good to me`` comment." -msgstr "``looks good to me`` コメントで変更を承認します。" - -#: ../../rst/community/documentation_contributions.rst:62 -msgid "Opening a new issue and/or PR" -msgstr "新しい問題または PR を開く" - -#: ../../rst/community/documentation_contributions.rst:64 -msgid "If the problem you have noticed is too complex to fix with the ``Edit on GitHub`` option, and no open issue or PR already documents the problem, please open an issue and/or a PR on the correct underlying repo - ``ansible/ansible`` for most pages that are not plugin or module documentation. If the documentation page has no ``Edit on GitHub`` option, check if the page is for a module within a collection. If so, follow the link to the collection on Galaxy and select the ``repo`` button in the upper right corner to find the source repository for that collection and module. The Collection README file should contain information on how to contribute to that collection, or report issues." -msgstr "気づいた問題が複雑すぎて ``Edit on GitHub`` オプションでは修正できず、その問題が報告されていなかったり、プル要求が作成されていない場合は、正しい基盤のリポジトリーで問題またはプル要求を作成してください (プラグインやモジュールのドキュメント以外のほとんどのページについては、``ansible/ansible`` で問題またはプル要求を作成してください)。ドキュメントページに ``Edit on GitHub`` オプションがない場合は、そのページがコレクション内のモジュール用であるかどうかを確認します。その場合は、Galaxy のコレクションへのリンクに従い、右上隅の ``repo`` ボタンを選択して、そのコレクションとモジュールのソースリポジトリーを見つけてください。コレクション README ファイルには、そのコレクションへの貢献方法、または問題を報告する方法に関する情報が含まれているはずです。" - -#: ../../rst/community/documentation_contributions.rst:66 -msgid "A great documentation GitHub issue or PR includes:" -msgstr "GitHub の問題や PR には、以下のような内容を追加してください。" - -#: ../../rst/community/documentation_contributions.rst:68 -msgid "a specific title" -msgstr "特定のタイトル" - -#: ../../rst/community/documentation_contributions.rst:69 -msgid "a detailed description of the problem (even for a PR - it's hard to evaluate a suggested change unless we know what problem it's meant to solve)" -msgstr "問題の詳細な説明 (何が問題なのか分からないと変更案の評価が困難になるため、プル要求の場合でも同様)" - -#: ../../rst/community/documentation_contributions.rst:70 -msgid "links to other information (related issues/PRs, external documentation, pages on docs.ansible.com, and so on)" -msgstr "その他の情報 (関連する問題やプル要求、外部ドキュメント、docs.ansible.com のページなど) へのリンク" - -#: ../../rst/community/documentation_contributions.rst:74 -msgid "Verifying your documentation PR" -msgstr "ドキュメントプル要求の確認" - -#: ../../rst/community/documentation_contributions.rst:76 -msgid "If you make multiple changes to the documentation on ``ansible/ansible``, or add more than a line to it, before you open a pull request, please:" -msgstr "``ansible/ansible`` のドキュメントに複数の変更を加えたり、複数の行を追加したりする場合は、プル要求を開始する前に、以下を行います。" - -#: ../../rst/community/documentation_contributions.rst:78 -msgid "Check that your text follows our :ref:`style_guide`." -msgstr "記述した内容が、:ref:`style_guide` に従っていることを確認してください。" - -#: ../../rst/community/documentation_contributions.rst:79 -msgid "Test your changes for rST errors." -msgstr "変更した内容が rST のエラーになっていないかテストしてください。" - -#: ../../rst/community/documentation_contributions.rst:80 -msgid "Build the page, and preferably the entire documentation site, locally." -msgstr "ページ、できればドキュメントサイト全体をローカルでビルドします。" - -#: ../../rst/community/documentation_contributions.rst:84 -msgid "The following sections apply to documentation sourced from the ``ansible/ansible`` repo and does not apply to documentation from an individual collection. See the collection README file for details on how to contribute to that collection." -msgstr "以下のセクションは、``ansible/ansible`` リポジトリーから取得したドキュメントに適用され、個別のコレクションからのドキュメントには適用されません。そのコレクションへの貢献方法は、コレクションの README ファイルを参照してください。" - -#: ../../rst/community/documentation_contributions.rst:87 -msgid "Setting up your environment to build documentation locally" -msgstr "ローカルにドキュメントをビルドするための環境設定" - -#: ../../rst/community/documentation_contributions.rst:89 -msgid "To build documentation locally, ensure you have a working :ref:`development environment `." -msgstr "ローカルにドキュメントをビルドするには、:ref:`development environment ` が有効であることを確認します。" - -#: ../../rst/community/documentation_contributions.rst:91 -msgid "To work with documentation on your local machine, you need to have python-3.9 or greater and install the `Ansible dependencies`_ and `documentation dependencies`_, which are listed in two files to make installation easier:" -msgstr "ローカルマシンでドキュメントを使用するには、python-3.9 以降を使用して、`Ansible dependencies`_ および `documentation dependencies`_ をインストールする必要があります。これらは、インストールを容易にするために、2 つのファイルに記載されています。" - -#: ../../rst/community/documentation_contributions.rst:101 -msgid "The :file:`docs/docsite/requirements.txt` file allows a wide range of versions and may install new releases of required packages. New releases of these packages may cause problems with the Ansible docs build. If you want to install tested versions of these dependencies, use :file:`test/sanity/code-smell/docs-build.requirements.txt` instead, which matches the dependencies used by CI:" -msgstr ":file:`docs/docsite/requirements.txt` ファイルにより、幅広いバージョンを使用でき、必要なパッケージの新しいリリースをインストールできます。これらのパッケージの新規リリースをインストールすると、Ansible ドキュメントのビルドで問題が発生する可能性があります。これらの依存関係のテスト済みバージョンをインストールする場合は、代わりに CI で使用される依存関係と一致する :file:`test/sanity/code-smell/docs-build.requirements.txt` を使用します。" - -#: ../../rst/community/documentation_contributions.rst:110 -msgid "You can drop ``--user`` if you have set up a virtual environment (venv/virtenv)." -msgstr "仮想環境 (venv/virtenv) を設定している場合は、``--user`` を削除することができます。" - -#: ../../rst/community/documentation_contributions.rst:114 -msgid "You may need to install these general pre-requisites separately on some systems: - ``gcc`` - ``libyaml`` - ``make`` - ``pyparsing`` - ``six`` On macOS with Xcode, you may need to install ``six`` and ``pyparsing`` with ``--ignore-installed`` to get versions that work with ``sphinx``." -msgstr "これらの一般的な前提条件を、一部のシステムに個別にインストールしないといけない場合があります ( - ``gcc`` - ``libyaml`` - ``make`` - ``pyparsing`` - ``six``) Xcode を使用する macOS では、``--ignore-installed`` で ``six`` および ``pyparsing`` を使用して、``sphinx`` と連携するバージョンを取得します。" - -#: ../../rst/community/documentation_contributions.rst:124 -msgid "After checking out ``ansible/ansible``, make sure the ``docs/docsite/rst`` directory has strict enough permissions. It should only be writable by the owner's account. If your default ``umask`` is not 022, you can use ``chmod go-w docs/docsite/rst`` to set the permissions correctly in your new branch. Optionally, you can set your ``umask`` to 022 to make all newly created files on your system (including those created by ``git clone``) have the correct permissions." -msgstr "``ansible/ansible`` をチェックアウトしたら、``docs/docsite/rst`` ディレクトリーに十分なパーミッションが付与されていることを確認します。所有者のアカウントのみが書き込み可能でなければなりません。デフォルトの ``umask`` が 022 ではない場合は、``chmod go-w docs/docsite/rst`` を使用して新規ブランチにパーミッションを正しく設定することができます。必要に応じて、``umask`` を 022 に設定して、システムで新に作成されるすべてのファイル (``git clone`` が作成したファイルを含む) に正しいパーミッションを設定することができます。" - -#: ../../rst/community/documentation_contributions.rst:129 -msgid "Testing the documentation locally" -msgstr "ドキュメントのローカルでのテスト" - -#: ../../rst/community/documentation_contributions.rst:131 -msgid "To test an individual file for rST errors:" -msgstr "rST エラーに対して個別のファイルをテストするには、以下を行います。" - -#: ../../rst/community/documentation_contributions.rst:138 -msgid "Building the documentation locally" -msgstr "ローカルでのドキュメントのビルド" - -#: ../../rst/community/documentation_contributions.rst:140 -msgid "Building the documentation is the best way to check for errors and review your changes. Once `rstcheck` runs with no errors, navigate to ``ansible/docs/docsite`` and then build the page(s) you want to review." -msgstr "ドキュメントのビルドは、エラーと変更を確認するのに最適な方法です。エラーなしで `rstcheck` を実行したら、``ansible/docs/docsite`` に移動し、確認するページをビルドします。" - -#: ../../rst/community/documentation_contributions.rst:144 -msgid "If building on macOS with Python 3.8 or later, you must use Sphinx >= 2.2.2. See `#6803 `_ for details." -msgstr "Python 3.8以降を使用してmacOSでビルドする場合は、Sphinx> = 2.2.2を使用する必要があります。詳細は、`#6803 `_を参照してください。" - -#: ../../rst/community/documentation_contributions.rst:149 -msgid "Building a single rST page" -msgstr "単一の rST ページのビルド" - -#: ../../rst/community/documentation_contributions.rst:151 -msgid "To build a single rST file with the make utility:" -msgstr "make ユーティリティーで単一の RST ファイルをビルドするには、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:163 -msgid "This process compiles all the links but provides minimal log output. If you're writing a new page or want more detailed log output, refer to the instructions on :ref:`build_with_sphinx-build`" -msgstr "このプロセスはすべてのリンクをコンパイルしますが、ログ出力は最小限になります。新しいページを作成する場合や、より詳細なログ出力が必要な場合は、「:ref:`build_with_sphinx-build`」の手順を参照してください。" - -#: ../../rst/community/documentation_contributions.rst:167 -msgid "``make htmlsingle`` adds ``rst/`` to the beginning of the path you provide in ``rst=``, so you can't type the filename with autocomplete. Here are the error messages you will see if you get this wrong:" -msgstr "``make htmlsingle`` は、``rst=`` で提供されるパスの先頭に ``rst/`` を追加するため、自動補完でファイル名を入力することができません。これが間違っている場合は、以下のようなエラーメッセージが表示されます。" - -#: ../../rst/community/documentation_contributions.rst:169 -msgid "If you run ``make htmlsingle`` from the ``docs/docsite/rst/`` directory: ``make: *** No rule to make target `htmlsingle'. Stop.``" -msgstr "``docs/docsite/rst/`` ディレクトリーから ``make htmlsingle`` を実行した場合は、``make: *** No rule to make target `htmlsingle'. Stop.`` メッセージが表示されます。" - -#: ../../rst/community/documentation_contributions.rst:170 -msgid "If you run ``make htmlsingle`` from the ``docs/docsite/`` directory with the full path to your rST document: ``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']``." -msgstr "rST ドキュメントへの完全パスを使用して ``docs/docsite/`` ディレクトリーから ``make htmlsingle`` を実行した場合は、``sphinx-build: error: cannot find files ['rst/rst/community/documentation_contributions.rst']`` メッセージが表示されます。" - -#: ../../rst/community/documentation_contributions.rst:174 -msgid "Building all the rST pages" -msgstr "すべての rST ページのビルド" - -#: ../../rst/community/documentation_contributions.rst:176 -msgid "To build all the rST files without any module documentation:" -msgstr "モジュールのドキュメント以外のすべての rST ファイルをビルドするには、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:183 -msgid "Building module docs and rST pages" -msgstr "モジュールドキュメントと rST ページのビルド" - -#: ../../rst/community/documentation_contributions.rst:185 -msgid "To build documentation for a few modules included in ``ansible/ansible`` plus all the rST files, use a comma-separated list:" -msgstr "``ansible/ansible`` に含まれるいくつかのモジュールとすべての rST ファイルを使用してドキュメントをビルドするには、コンマ区切りリストを使用します。" - -#: ../../rst/community/documentation_contributions.rst:191 -msgid "To build all the module documentation plus all the rST files:" -msgstr "すべてのモジュールドキュメントとすべての rST ファイルをビルドするには、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:200 -msgid "Building rST files with ``sphinx-build``" -msgstr "``sphinx-build`` で rST ファイルのビルド" - -#: ../../rst/community/documentation_contributions.rst:202 -msgid "Advanced users can build one or more rST files with the sphinx utility directly. ``sphinx-build`` returns misleading ``undefined label`` warnings if you only build a single page, because it does not create internal links. However, ``sphinx-build`` returns more extensive syntax feedback, including warnings about indentation errors and ``x-string without end-string`` warnings. This can be useful, especially if you're creating a new page from scratch. To build a page or pages with ``sphinx-build``:" -msgstr "上級ユーザーは、sphinx ユーティリティーを直接使用して 1 つ以上の rST ファイルをビルドすることができます。``sphinx-build`` は、内部リンクが作成されないため、1 ページのみをビルドする場合は、誤解を招く ``undefined label`` 警告を返します。ただし、``sphinx-build`` は、インデントエラーや ``x-string without end-string`` 警告など、より広範な構文のフィードバックを返します。これは特に、ゼロから新しいページを作成している場合に役に立ちます。``sphinx-build`` でページをビルドするには、以下のようにします。" - -#: ../../rst/community/documentation_contributions.rst:208 -msgid "You can specify filenames, or ``–a`` for all files, or omit both to compile only new/changed files." -msgstr "ファイル名を指定することもできますし、すべてのファイルに ``–a`` を指定することもできます。もしくは、両方を省略して新しいまたは変更されたファイルだけをコンパイルすることもできます。" - -#: ../../rst/community/documentation_contributions.rst:217 -msgid "Running the final tests" -msgstr "最終テストの実行" - -#: ../../rst/community/documentation_contributions.rst:219 -msgid "When you submit a documentation pull request, automated tests are run. Those same tests can be run locally. To do so, navigate to the repository's top directory and run:" -msgstr "ドキュメントのプル要求を送信すると、自動テストが実行します。同じテストをローカルで実行できます。これを行うには、リポジトリーの最上位ディレクトリーに移動し、以下を実行します。" - -#: ../../rst/community/documentation_contributions.rst:227 -msgid "Unfortunately, leftover rST-files from previous document-generating can occasionally confuse these tests. It is therefore safest to run them on a clean copy of the repository, which is the purpose of ``make clean``. If you type these three lines one at a time and manually check the success of each, you do not need the ``&&``." -msgstr "ただし、以前ドキュメントを生成した時の rST ファイルが残っていると、このテストを混乱させることがあります。そのため、リポジトリーのクリーンコピー上で実行するのが最も安全です。これが、``make clean`` の目的でもあります。この 3 つの行を一度に 1 行ずつ入力して、各行が成功したことを手動で確認する場合、``&&`` は必要ありません。" - -#: ../../rst/community/documentation_contributions.rst:230 -msgid "Joining the documentation working group" -msgstr "ドキュメントワーキンググループへの参加" - -#: ../../rst/community/documentation_contributions.rst:232 -msgid "The Documentation Working Group (DaWGs) meets weekly on Tuesdays in the Docs chat (using `Matrix `_ or using IRC at `irc.libera.chat `_). For more information, including links to our agenda and a calendar invite, please visit the `working group page in the community repo `_." -msgstr "ドキュメントワーキンググループ (DaWGs)は、Docs チャットで、毎週火曜日に集まっています(`Matrix `_または`irc.libera.chat `_のIRCを使用)。議題へのリンクや、カレンダーの招待状などの詳細は、「`working group page in the community repo `_」をご覧ください。" - -#: ../../rst/community/documentation_contributions.rst:235 -msgid ":ref:`More about testing module documentation `" -msgstr ":ref:`More about testing module documentation `" - -#: ../../rst/community/documentation_contributions.rst:237 -msgid ":ref:`More about documenting modules `" -msgstr ":ref:`モジュールのドキュメント化の詳細 `" - -#: ../../rst/community/getting_started.rst:5 -msgid "Getting started" -msgstr "はじめに" - -#: ../../rst/community/getting_started.rst:7 -msgid "Welcome and thank you for getting more involved with the Ansible community. Here are some ways you can get started." -msgstr "ようこそ。Ansible コミュニティーに参加していただきありがとうございます。以下のような方法で、コミュニティーでの活動を開始することができます。" - -#: ../../rst/community/getting_started.rst:20 -msgid "Other ways to get involved" -msgstr "その他の参加方法" - -#: ../../rst/community/getting_started.rst:22 -msgid "Here are some other ways to connect with the Ansible community:" -msgstr "以下は、Ansible コミュニティーへのその他の参加方法になります。" - -#: ../../rst/community/getting_started.rst:24 -msgid "Find an `Ansible Meetup near me `_" -msgstr "`近くの Ansible Meetup `_ を検索します。" - -#: ../../rst/community/getting_started.rst:25 -msgid "communication" -msgstr "コミュニケーション" - -#: ../../rst/community/getting_started.rst:26 -msgid "Learn more about Ansible:" -msgstr "Ansible の詳細情報:" - -#: ../../rst/community/getting_started.rst:28 -msgid "`Read books `_." -msgstr "`Read books `_。" - -#: ../../rst/community/getting_started.rst:29 -#: ../../rst/community/how_can_I_help.rst:23 -msgid "`Get certified `_." -msgstr "`Get certified `_。" - -#: ../../rst/community/getting_started.rst:30 -msgid "`Attend events `_." -msgstr "`Attend events `_。" - -#: ../../rst/community/getting_started.rst:31 -msgid "`Review getting started guides `_." -msgstr "`Review getting started guides `_。" - -#: ../../rst/community/getting_started.rst:32 -msgid "`Watch videos `_ - includes Ansible Automates, AnsibleFest & webinar recordings." -msgstr "`ビデオを観る `_ (Ansible Automates、AnsibleFest、ウェビナーの録画など)。" - -#: ../../rst/community/getting_started.rst:33 -msgid "See where `new releases are announced `_" -msgstr "`新しいリリースが発表される `_ 場所を確認してください。" - -#: ../../rst/community/github_admins.rst:5 -msgid "GitHub Admins" -msgstr "GitHub 管理者" - -#: ../../rst/community/github_admins.rst:9 -msgid "GitHub Admins have more permissions on GitHub than normal contributors or even committers. There are a few responsibilities that come with that increased power." -msgstr "GitHub 管理者には、通常の貢献者や、コミットするユーザーよりも多くの権限が付与されています。このように権限の増加に伴い、いくつかの責任が発生します" - -#: ../../rst/community/github_admins.rst:14 -msgid "Adding and removing committers" -msgstr "コミットを行うユーザーの追加および削除" - -#: ../../rst/community/github_admins.rst:16 -msgid "The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke contributors' ability to commit on their own. GitHub Admins are the people who have the power to actually manage the GitHub permissions." -msgstr "Ansible チームは、誰が Ansible に積極的に貢献しているかを定期的に確認して、貢献者のコミット権限を許可したり取り消したりします。GitHub 管理者は、GitHub パーミッションを実際に管理する権限を持つユーザーです。" - -#: ../../rst/community/github_admins.rst:22 -msgid "Changing branch permissions for releases" -msgstr "リリースのブランチパーミッションの変更" - -#: ../../rst/community/github_admins.rst:24 -msgid "When we make releases we make people go through a :ref:`release_managers` to push commits to that branch. The GitHub admins are responsible for setting the branch so only the Release Manager can commit to the branch when the release process reaches that stage and later opening the branch once the release has been made. The Release manager will let the GitHub Admin know when this needs to be done." -msgstr "リリースを行う場合は、:ref:`release_managers` に沿って、そのブランチへのコミットをプッシュします。GitHub 管理者には、リリースプロセスがその段階に達したときにリリースマネージャーだけがブランチにコミットできるようにブランチを設定し、リリースが完了した後にブランチを開く責任があります。この設定が必要になると、リリースマネージャーが GitHub 管理者に知らせます。" - -#: ../../rst/community/github_admins.rst:30 -msgid "The `GitHub Admin Process Docs `_ for instructions on how to change branch permissions." -msgstr "ブランチパーミッションを変更する方法は、「`GitHub Admin Process Docs `_」を参照してください。" - -#: ../../rst/community/how_can_I_help.rst:5 -msgid "How can I help?" -msgstr "貢献方法" - -#: ../../rst/community/how_can_I_help.rst:10 -msgid "Thanks for being interested in helping the Ansible project!" -msgstr "Ansible プロジェクトを支援することに関心をお寄せいただきありがとうございます。" - -#: ../../rst/community/how_can_I_help.rst:12 -msgid "There are many ways to help the Ansible project...but first, please read and understand the :ref:`code_of_conduct`." -msgstr "Ansible プロジェクトを支援する方法は多数ありますが、まずは「:ref:`code_of_conduct`」を読んで理解してください。" - -#: ../../rst/community/how_can_I_help.rst:15 -msgid "Become a power user" -msgstr "パワーユーザーになる。" - -#: ../../rst/community/how_can_I_help.rst:17 -msgid "A great way to help the Ansible project is to become a power user:" -msgstr "Ansible プロジェクトを支援する優れた方法は、上級ユーザーになることです。" - -#: ../../rst/community/how_can_I_help.rst:19 -msgid "Use Ansible everywhere you can" -msgstr "可能な限りどこでも Ansible を使用する。" - -#: ../../rst/community/how_can_I_help.rst:20 -msgid "Take tutorials and classes" -msgstr "チュートリアルやクラスを受講する。" - -#: ../../rst/community/how_can_I_help.rst:21 -msgid "Read the :ref:`official documentation `" -msgstr ":ref:`公式ドキュメント ` を読む。" - -#: ../../rst/community/how_can_I_help.rst:22 -msgid "Study some of the `many excellent books `_ about Ansible" -msgstr "Ansible に関する `多くの優れた書籍 `_ の中からいくつか選んで勉強する。" - -#: ../../rst/community/how_can_I_help.rst:25 -msgid "When you become a power user, your ability and opportunities to help the Ansible project in other ways will multiply quickly." -msgstr "パワーユーザーになると、Ansible プロジェクトを他の方法で支援する能力と機会が急速に増えます。" - -#: ../../rst/community/how_can_I_help.rst:28 -msgid "Ask and answer questions online" -msgstr "オンラインで質問し、質問に回答" - -#: ../../rst/community/how_can_I_help.rst:30 -msgid "There are many forums online where Ansible users ask and answer questions. Reach out and communicate with your fellow Ansible users." -msgstr "オンラインには、Ansible ユーザーが質問をしたり、質問に答えたりするフォーラムが多数あります。他の Ansible ユーザーに連絡してコミュニケーションを行いましょう。" - -#: ../../rst/community/how_can_I_help.rst:32 -msgid "You can find the official :ref:`Ansible communication channels `." -msgstr "公式の :ref:`Ansible コミュニケーションチャンネル ` があります。" - -#: ../../rst/community/how_can_I_help.rst:35 -msgid "Review, fix, and maintain the documentation" -msgstr "ドキュメントの確認、修正、および維持" - -#: ../../rst/community/how_can_I_help.rst:37 -msgid "Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find outdated examples. We offer easy ways to :ref:`report and/or fix documentation errors `." -msgstr "Ansible ドキュメントに誤字が含まれる場合があります。ドキュメントを最新の状態に保つように努めていますが、古い例が見つかる場合もあります。:ref:`ドキュメントエラーを報告または修正する ` 簡単な方法を提供しています。" - -#: ../../rst/community/how_can_I_help.rst:42 -msgid "Participate in your local meetup" -msgstr "各地の Meetup に参加" - -#: ../../rst/community/how_can_I_help.rst:44 -msgid "There are Ansible meetups `all over the world `_. Join your local meetup. Attend regularly. Ask good questions. Volunteer to give a presentation about how you use Ansible." -msgstr "Ansible の Meetup は `世界中 `_ で開催されています。お住いの地域で開催される Meetup に参加してください。定期的に参加してください。質問をしてください。Ansible の使用方法に関するプレゼンテーションを自発的に行ってください。" - -#: ../../rst/community/how_can_I_help.rst:46 -msgid "If there is no meetup near you, we are happy to help you `start one `_." -msgstr "お近くで Meetup が開催されない場合は、`新たに開催する `_ ことをお手伝いします。" - -#: ../../rst/community/how_can_I_help.rst:49 -msgid "File and verify issues" -msgstr "問題の報告および確認" - -#: ../../rst/community/how_can_I_help.rst:51 -msgid "All software has bugs, and Ansible is no exception. When you find a bug, you can help tremendously by telling us about it:" -msgstr "すべてのソフトウェアにはバグがあり、Ansible も例外ではありません。バグを見つけた場合は、知らせていただけると非常に助かります。" - -#: ../../rst/community/how_can_I_help.rst:53 -msgid "Filing :ref:`issues for ansible-core `." -msgstr ":ref:`issues for ansible-core ` を報告する。" - -#: ../../rst/community/how_can_I_help.rst:54 -msgid "Filing :ref:`issues for collections `." -msgstr ":ref:`issues for collections ` を報告する。" - -#: ../../rst/community/how_can_I_help.rst:57 -msgid "If the bug you found already exists in an issue, you can help by verifying the behavior of the reported bug with a comment in that issue, or by reporting any additional information." -msgstr "報告しようとしているバグがすでに報告されている場合は、報告されているバグの動作をその問題のコメントで検証したり、追加情報を報告したりすることが助けになります。" - -#: ../../rst/community/how_can_I_help.rst:60 -msgid "Review and submit pull requests" -msgstr "プル要求の確認および提出" - -#: ../../rst/community/how_can_I_help.rst:62 -msgid "As you become more familiar with how Ansible works, you may be able to fix issues or develop new features yourself. If you think you have a fix for a bug in Ansible, or if you have a new feature that you would like to share with millions of Ansible users, read all about the :ref:`development process ` to learn how to get your code accepted into Ansible." -msgstr "Ansible の機能について理解が深まると、問題を修正したり、新しい機能を自分で開発したりできるようになります。Ansible で見つかったバグの解決策を見つけた場合や、自身が作成した新機能を何百万人もの Ansible ユーザーと共有したい場合は、:ref:`development process ` をよく読んで、作成したコードを Ansible に受け入れてもらう方法を学んでください。" - -#: ../../rst/community/how_can_I_help.rst:64 -msgid "You can also get started with solving GitHub issues labeled with the ``easyfix`` and ``good_first_issue`` labels for:" -msgstr "``easyfix`` と ``good_first_issue`` のラベルが付いた GitHub の問題の解決を開始することもできます。" - -#: ../../rst/community/how_can_I_help.rst:66 -#, python-format -msgid "`Ansible collections `_" -msgstr "`Ansible collections `_" - -#: ../../rst/community/how_can_I_help.rst:72 -msgid "Another good way to help is to review pull requests that other Ansible users have submitted. Ansible core keeps a full list of `open pull requests by file `_, so if a particular module or plugin interests you, you can easily keep track of all the relevant new pull requests and provide testing or feedback. Alternatively, you can review the pull requests for any collections that interest you. Click :guilabel:`Issue tracker` on the collection documentation page to find the issues and PRs for that collection." -msgstr "もう 1 つの優れた方法は、他の Ansible ユーザーが送信したプル要求を確認することです。Ansible コアは `open pull requests by file `_ の完全なリストを保持しているため、興味を持った特定のモジュールまたはプラグインに関連する新規新規プル要求を簡単に追跡して、テストやフィードバックを提供できます。または、興味のあるコレクションのプル要求を確認することもできます。コレクションのドキュメントページで :guilabel:`Issue tracker` をクリックすると、そのコレクションの issue とプル要求を見つけることができます。" - -#: ../../rst/community/how_can_I_help.rst:77 -msgid "Once you have learned about the development process and have contributed code to a collection, we encourage you to become a maintainer of that collection. There are hundreds of modules in dozens of Ansible collections, and the vast majority of them are written and maintained entirely by members of the Ansible community." -msgstr "開発プロセスについて学習し、コードをコレクションに提供したら、そのコレクションのメンテナーになるよう推奨されます。Ansible には数百ものモジュールがあり、その大部分は Ansible コミュニティーのメンバーによって完全に記述され、維持されています。" - -#: ../../rst/community/how_can_I_help.rst:79 -msgid "See :ref:`collection maintainer guidelines ` to learn more about the responsibilities of being an Ansible collection maintainer." -msgstr "Ansible コレクションメンテナーとしての責任について、詳細は :ref:`collection maintainer guidelines ` を参照してください。" - -#: ../../rst/community/how_can_I_help.rst:84 -msgid "Join a working group" -msgstr "ワーキンググループへの参加" - -#: ../../rst/community/how_can_I_help.rst:86 -msgid "Working groups are a way for Ansible community members to self-organize around particular topics of interest. We have working groups around various topics. To join or create a working group, please read the :ref:`Ansible Working Groups`." -msgstr "ワーキンググループは、Ansible コミュニティーのメンバーが関心のある特定のトピックについて自己編成する方法です。さまざまなトピックに関するワーキンググループがあります。ワーキンググループに参加するか、「:ref:`Ansible ワーキンググループ`」を参照してください。" - -#: ../../rst/community/how_can_I_help.rst:90 -msgid "Teach Ansible to others" -msgstr "Ansible を紹介する" - -#: ../../rst/community/how_can_I_help.rst:92 -msgid "We are working on a standardized `Ansible workshop `_ that can provide a good hands-on introduction to Ansible usage and concepts." -msgstr "現在、Ansible の使用方法や概念をしっかりとハンズオンで紹介できる標準化された `Ansible ワークショップ `_ に取り組んでいます。" - -#: ../../rst/community/how_can_I_help.rst:95 -msgid "Social media" -msgstr "ソーシャルメディア" - -#: ../../rst/community/how_can_I_help.rst:97 -msgid "If you like Ansible and just want to spread the good word, feel free to share on your social media platform of choice, and let us know by using ``@ansible`` or ``#ansible``. We'll be looking for you." -msgstr "Ansible が好きで、Ansible の良さを広めたい方は、お好きなソーシャルメディアプラットフォームで気軽にシェアしてください。コミュニティーメンバーが気が付くように、``@ansible`` または ``#ansible`` を使用することが推奨されます。" - -#: ../../rst/community/index.rst:5 -msgid "Ansible Community Guide" -msgstr "Ansible コミュニティーガイド" - -#: ../../rst/community/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/community/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/community/index.rst:13 -msgid "Welcome to the Ansible Community Guide!" -msgstr "Ansible コミュニティーガイドにようこそ!" - -#: ../../rst/community/index.rst:15 -msgid "The purpose of this guide is to teach you everything you need to know about being a contributing member of the Ansible community. All types of contributions are welcome and necessary for Ansible's continued success." -msgstr "本ガイドの目的は、Ansible コミュニティーに貢献する際に必要な知識をすべて説明することです。あらゆる種類の貢献が、Ansible の継続的な成功に必要なものであり、歓迎されます。" - -#: ../../rst/community/maintainers.rst:5 -msgid "Guidelines for collection maintainers" -msgstr "コレクションメンテナーのガイドライン" - -#: ../../rst/community/maintainers.rst:7 -msgid "Thank you for being a community collection maintainer. This guide offers an overview of your responsibilities as a maintainer along with resources for additional information. The Ansible community hopes that you will find that maintaining a collection is as rewarding for you as having the collection content is for the wider community." -msgstr "Ansible のコミュニティーコレクションのメンテナーになっていただきありがとうございます。本ガイドでは、メンテナーの責任の概要、追加情報のリソースを紹介します。Ansible コミュニティーは、コレクションのコンテンツを持つことがより広いコミュニティーにとって有益であるのと同様に、コレクションを維持することが皆様にとっても有益であると感じていただけることを願っています。" - -#: ../../rst/community/maintainers.rst:16 -msgid "In addition to the information here, module maintainers should be familiar with:" -msgstr "以下の情報に加えて、モジュールメンテナーは以下について理解しておく必要があります。" - -#: ../../rst/community/maintainers.rst:18 -msgid ":ref:`General Ansible community development practices `" -msgstr ":ref:`Ansible コミュニティー開発に関する一般的なプラクティス `" - -#: ../../rst/community/maintainers.rst:19 -msgid "Documentation on :ref:`module development `" -msgstr ":ref:`module development ` に関するドキュメント" - -#: ../../rst/community/maintainers_guidelines.rst:4 -msgid "Maintainer responsibilities" -msgstr "メンテナーの役割" - -#: ../../rst/community/maintainers_guidelines.rst:10 -msgid "An Ansible collection maintainer is a contributor trusted by the community who makes significant and regular contributions to the project and who has shown themselves as a specialist in the related area. Collection maintainers have :ref:`extended permissions` in the collection scope." -msgstr "Ansible コレクションのメンテナーは、プロジェクトに重要かつ定期的な貢献をし、関連分野のスペシャリストとしての地位を示している、コミュニティーから信頼されているコントリビューターです。コレクションのメンテナーは、コレクションスコープ内に :ref:`extended permissions` があります。" - -#: ../../rst/community/maintainers_guidelines.rst:13 -msgid "Ansible collection maintainers provide feedback, responses, or actions on pull requests or issues to the collection(s) they maintain in a reasonably timely manner. They can also update the contributor guidelines for that collection, in collaboration with the Ansible community team and the other maintainers of that collection." -msgstr "Ansible コレクションのメンテナーは、プル要求または issue に対するフィードバック、応答、またはアクションを、合理的な時間内に維持するコレクションに提供します。また、Ansible コミュニティーチームやそのコレクションの他のメンテナーと協力して、そのコレクションのコントリビューターガイドラインを更新することもできます。" - -#: ../../rst/community/maintainers_guidelines.rst:15 -msgid "In general, collection maintainers:" -msgstr "一般的に、コレクションのメンテナーは以下を行います。" - -#: ../../rst/community/maintainers_guidelines.rst:17 -msgid "Act in accordance with the :ref:`code_of_conduct`." -msgstr ":ref:`code_of_conduct` に従って動作します。" - -#: ../../rst/community/maintainers_guidelines.rst:18 -msgid "Subscribe to the collection repository they maintain (click :guilabel:`Watch > All activity` in GitHub)." -msgstr "維持しているコレクションリポジトリーにサブスクライブします (GitHub の :guilabel:`Watch > All activity` をクリック)。" - -#: ../../rst/community/maintainers_guidelines.rst:19 -msgid "Keep README, development guidelines, and other general collections :ref:`maintainer_documentation` relevant." -msgstr "README、開発ガイドライン、およびその他の一般的なコレクション :ref:`maintainer_documentation` を維持します。" - -#: ../../rst/community/maintainers_guidelines.rst:20 -msgid "Review and commit changes made by other contributors." -msgstr "他のコントリビューターによる変更を確認し、コミットします。" - -#: ../../rst/community/maintainers_guidelines.rst:21 -msgid ":ref:`Backport ` changes to stable branches." -msgstr ":ref:`バックポート ` は安定したブランチに変更します。" - -#: ../../rst/community/maintainers_guidelines.rst:22 -msgid "Address or assign issues to appropriate contributors." -msgstr "issue に対処するか、適切なコントリビューターに割り当てます。" - -#: ../../rst/community/maintainers_guidelines.rst:23 -msgid ":ref:`Release collections `." -msgstr ":ref:`Release collections `。" - -#: ../../rst/community/maintainers_guidelines.rst:24 -msgid "Ensure that collections adhere to the `Collection Requirements `_," -msgstr "コレクションが `コレクションの要件 `_ に準拠することを確認します。" - -#: ../../rst/community/maintainers_guidelines.rst:25 -msgid "Track changes announced in `News for collection contributors and maintainers `_ and update a collection in accordance with these changes." -msgstr "`コレクションのコントリビューターとメンテナー向けのニュース `_ で発表された変更を追跡し、これらの変更に従ってコレクションを更新します。" - -#: ../../rst/community/maintainers_guidelines.rst:26 -msgid "Subscribe and submit news to the `Bullhorn newsletter `_." -msgstr "`Bullhorn ニュースレター `_ をサブスクライブし、話題を提供してください。" - -#: ../../rst/community/maintainers_guidelines.rst:27 -msgid ":ref:`Build a healthy community ` to increase the number of active contributors and maintainers around collections." -msgstr "コレクションに関するアクティブなコントリビューターおよびメンテナーの数を増やすために、:ref:`健全なコミュニティーを築きます `。" - -#: ../../rst/community/maintainers_guidelines.rst:28 -msgid "Revise these guidelines to improve the maintainer experience for yourself and others." -msgstr "これらのガイドラインを改訂し、自分自身や他の人のメンテナーエクスペリエンスを向上させます。" - -#: ../../rst/community/maintainers_guidelines.rst:30 -msgid "Multiple maintainers can divide responsibilities among each other." -msgstr "メンテナーが複数いれば、互いに責任を分担することができます。" - -#: ../../rst/community/maintainers_guidelines.rst:33 -msgid "How to become a maintainer" -msgstr "メンテナーになる方法" - -#: ../../rst/community/maintainers_guidelines.rst:35 -msgid "A person interested in becoming a maintainer and satisfying the :ref:`requirements` may either self-nominate or be nominated by another maintainer." -msgstr "メンテナーになることに関心があり、:ref:`requirements` を満たしている場合は、自己推薦するか、別のメンテナーに推薦してもらうことができます。" - -#: ../../rst/community/maintainers_guidelines.rst:37 -msgid "To nominate a candidate, create a GitHub issue in the relevant collection repository. If there is no response, the repository is not actively maintained, or the current maintainers do not have permissions to add the candidate, please create the issue in the `ansible/community `_ repository." -msgstr "候補者を指名するには、関連するコレクションリポジトリーに GitHub issue を作成します。応答がない場合は、リポジトリーがアクティブに維持されていないか、または現在のメンテナーに候補者を追加する権限がないと思われるので、`ansible/community `_ リポジトリーで issue を作成してください。" - -#: ../../rst/community/maintainers_guidelines.rst:40 -msgid "Communicating as a collection maintainer" -msgstr "コレクションメンテナとしてのコミュニケーション" - -#: ../../rst/community/maintainers_guidelines.rst:42 -msgid "Maintainers MUST subscribe to the `\"Changes impacting collection contributors and maintainers\" GitHub repo `_ and the `Bullhorn newsletter `_. If you have something important to announce through the newsletter (for example, recent releases), see the `Bullhorn's wiki page `_ to learn how." -msgstr "メンテナーは `\"Changes impacting collection contributors and maintainers\" GitHub repo `_ と `Bullhorn newsletter `_ をサブスクライブする必要があります。ニュースレターで発表する重要な情報 (最近のリリースなど) がある場合は、`Bullhorn's wiki page `_ を参照して、発表方法を確認してください。" - -#: ../../rst/community/maintainers_guidelines.rst:45 -msgid "Collection contributors and maintainers should also communicate through:" -msgstr "コレクションのコントリビューターおよびメンテナーも、以下を通じてコミュニケーションを図る必要があります。" - -#: ../../rst/community/maintainers_guidelines.rst:47 -msgid ":ref:`communication_irc` appropriate to their collection, or if none exists, the general community and developer chat channels" -msgstr "コレクションに適している :ref:`communication_irc`、または何も存在しない場合は、一般的なコミュニティーと開発者のチャットチャネル" - -#: ../../rst/community/maintainers_guidelines.rst:48 -msgid "Mailing lists such as `ansible-announce `_ and `ansible-devel `_" -msgstr "`ansible-announce `_ や `ansible-devel `_ などのメーリングリスト" - -#: ../../rst/community/maintainers_guidelines.rst:49 -msgid "Collection project boards, issues, and GitHub discussions in corresponding repositories" -msgstr "対応するリポジトリーでのコレクションのプロジェクトボード、issue、および GitHub ディスカッション" - -#: ../../rst/community/maintainers_guidelines.rst:50 -msgid "Quarterly Contributor Summits." -msgstr "四半期ごとのコントリビューターサミット。" - -#: ../../rst/community/maintainers_guidelines.rst:51 -msgid "Ansiblefest and local meetups." -msgstr "AnsibleFest およびローカルの Meetup" - -#: ../../rst/community/maintainers_guidelines.rst:53 -msgid "See :ref:`communication` for more details on these communication channels." -msgstr "これらの通信チャンネルの詳細は、:ref:`communication` を参照してください。" - -#: ../../rst/community/maintainers_guidelines.rst:58 -msgid "Establishing working group communication" -msgstr "ワーキンググループのコミュニケーションの確立" - -#: ../../rst/community/maintainers_guidelines.rst:60 -msgid "Working groups depend on efficient, real-time communication. Project maintainers can use the following techniques to establish communication for working groups:" -msgstr "ワーキンググループは、効率的なリアルタイムのコミュニケーションに依存しています。プロジェクト管理者は、次の手法を使用してワーキンググループのコミュニケーションを確立できます。" - -#: ../../rst/community/maintainers_guidelines.rst:63 -msgid "Find an existing :ref:`working_group_list` that is similar to your project and join the conversation." -msgstr "ご自身のプロジェクトに似た既存の :ref:`working_group_list` を検索して、会話に参加します。" - -#: ../../rst/community/maintainers_guidelines.rst:64 -msgid "`Request `_ a new working group for your project." -msgstr "プロジェクトに対して新しいワーキンググループを `リクエスト `_ します。" - -#: ../../rst/community/maintainers_guidelines.rst:65 -msgid "`Create `_ a public chat for your working group or `ask `_ the community team." -msgstr "作業グループの公開チャットまたは`ask `_ コミュニティーチームを `作成 `_ します。" - -#: ../../rst/community/maintainers_guidelines.rst:66 -msgid "Provide working group details and links to chat rooms in the contributor section of your project ``README.md``." -msgstr "プロジェクト ``README.md`` のコントリビューターセクションでワーキンググループの詳細とチャットルームへのリンクを提供します。" - -#: ../../rst/community/maintainers_guidelines.rst:67 -msgid "Encourage contributors to join the chats and add themselves to the working group." -msgstr "コントリビューターに対してチャットへの参加や、ワーキンググループへの参加を推奨します。" - -#: ../../rst/community/maintainers_guidelines.rst:69 -msgid "See the :ref:`Communication guide ` to learn more about real-time chat." -msgstr "リアルタムのチャットに関する情報は、:ref:`Communication guide ` を参照してください。" - -#: ../../rst/community/maintainers_guidelines.rst:72 -msgid "Community Topics" -msgstr "コミュニティートピック" - -#: ../../rst/community/maintainers_guidelines.rst:74 -msgid "The Community and the `Steering Committee `_ asynchronously discuss and vote on the `Community Topics `_ which impact the whole project or its parts including collections and packaging." -msgstr "コミュニティーと `Steering Committee `_ は、プロジェクト全体またはコレクションやパッケージングを含む部分に影響を与える `Community Topics `_ について、非同期的に議論し、投票します。" - -#: ../../rst/community/maintainers_guidelines.rst:76 -msgid "Share your opinion and vote on the topics to help the community make the best decisions." -msgstr "コミュニティーが最適な意思決定を行うことができるように、意見を共有し、トピックに投票してください。" - -#: ../../rst/community/maintainers_guidelines.rst:81 -msgid "Contributor Summits" -msgstr "コントリビューターサミット" - -#: ../../rst/community/maintainers_guidelines.rst:83 -msgid "The quarterly Ansible Contributor Summit is a global event that provides our contributors a great opportunity to meet each other, communicate, share ideas, and see that there are other real people behind the messages on Matrix or Libera Chat IRC, or GitHub. This gives a sense of community. Watch the `Bullhorn newsletter `_ for information when the next contributor summit, invite contributors you know, and take part in the event together." -msgstr "四半期ごとに開催される Ansible コントリビューターサミットは、コントリビューター同士が出会い、コミュニケーションを取り、アイデアを共有し、Matrix や Libera.Chat IRC または GitHub のメッセージの背後に他の実在する人物がいることを確認する絶好の機会を提供するグローバルイベントです。これでコミュニティーの感覚を得ることができます。次のコントリビューターサミットの開催情報を `Bullhorn newsletter `_ で確認し、知り合いのコントリビューターを招待して、共にイベントに参加してください。" - -#: ../../rst/community/maintainers_guidelines.rst:86 -msgid "Weekly community Matrix/IRC meetings" -msgstr "毎週のコミュニティーマトリックス/IRC ミーティング" - -#: ../../rst/community/maintainers_guidelines.rst:88 -msgid "The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` `Libera.Chat IRC `_ channel or in the bridged `#community:ansible.com `_ room on `Matrix `_ to discuss important project questions. Join us! Here is our `schedule `_." -msgstr "コミュニティーと Steering Committee は、`Matrix `_ に含まれる ``#ansible-community`` `Libera.Chat IRC ` チャネルまたはブリッジされた `#community:ansible.com ` ルームで毎週ミーティングを行い、プロジェクト関連の重要な質問について話し合いますので、参加してください。こちらが `スケジュール `_ です。" - -#: ../../rst/community/maintainers_guidelines.rst:91 -msgid "Expanding the collection community" -msgstr "コレクションコミュニティーの拡大" - -#: ../../rst/community/maintainers_guidelines.rst:95 -msgid "If you discover good ways to expand a community or make it more robust, edit this section with your ideas to share with other collection maintainers." -msgstr "コミュニティーを拡大したり、コミュニティーをより堅牢にするための良い方法を見つけた場合は、他のコレクションメンテナーと共有するために、アイデアを追加してこのセクションを編集してください。" - -#: ../../rst/community/maintainers_guidelines.rst:97 -msgid "Here are some ways you can expand the community around your collection:" -msgstr "コレクションを中心にコミュニティーを拡大する方法は以下のとおりです。" - -#: ../../rst/community/maintainers_guidelines.rst:99 -msgid "Give :ref:`newcomers a positive first experience `." -msgstr ":ref:`新参者の最初のエクスペリエンスがポジティブなもの ` になるようにします。" - -#: ../../rst/community/maintainers_guidelines.rst:100 -msgid "Invite contributors to join :ref:`real-time chats ` related to your project." -msgstr "コントリビューターに対して、ご自身のプロジェクトに関連する :ref:`real-time chats ` への参加を募ります。" - -#: ../../rst/community/maintainers_guidelines.rst:101 -msgid "Have :ref:`good documentation ` with guidelines for new contributors." -msgstr "新しいコントリビューターのためのガイドラインのある :ref:`優れたドキュメント ` を用意します。" - -#: ../../rst/community/maintainers_guidelines.rst:102 -msgid "Make people feel welcome personally and individually." -msgstr "一人ひとりが個人的に歓迎されていると感じるようにします。" - -#: ../../rst/community/maintainers_guidelines.rst:103 -msgid "Use labels to show easy fixes and leave non-critical easy fixes to newcomers and offer to mentor them." -msgstr "ラベルを使用して簡単な修正を示し、重要ではない簡単な修正を新参者に任せて、彼らを指導することを提案します。" - -#: ../../rst/community/maintainers_guidelines.rst:104 -msgid "Be responsive in issues, PRs and other communication." -msgstr "issue、プル要求、その他のコミュニケーションにすぐに対応します。" - -#: ../../rst/community/maintainers_guidelines.rst:105 -msgid "Conduct PR days regularly." -msgstr "定期的に PR の日を実施してください。" - -#: ../../rst/community/maintainers_guidelines.rst:106 -msgid "Maintain a zero-tolerance policy towards behavior violating the :ref:`code_of_conduct`." -msgstr ":ref:`code_of_conduct` に違反する動作に対してゼロトレランスポリシーを維持します。" - -#: ../../rst/community/maintainers_guidelines.rst:107 -msgid "Put information about how people can register code of conduct violations in your ``README`` and ``CONTRIBUTING`` files." -msgstr "``README`` および ``CONTRIBUTING`` ファイルに、行動規範違反を登録する方法についての情報を追加します。" - -#: ../../rst/community/maintainers_guidelines.rst:108 -msgid "Include quick ways contributors can help and other documentation in your ``README``." -msgstr "コントリビューターが支援できる簡単な方法や、その他のドキュメントを ``README`` に記載してください。" - -#: ../../rst/community/maintainers_guidelines.rst:109 -msgid "Add and keep updated the ``CONTRIBUTORS`` and ``MAINTAINERS`` files." -msgstr "``CONTRIBUTORS`` ファイルおよび ``MAINTAINERS`` ファイルを追加し、最新の状態にしておきます。" - -#: ../../rst/community/maintainers_guidelines.rst:110 -msgid "Create a pinned issue to announce that the collection welcomes new maintainers and contributors." -msgstr "固定された問題を作成し、コレクションが新しいメンテナーとコントリビューターを歓迎していることを発表します。" - -#: ../../rst/community/maintainers_guidelines.rst:111 -msgid "Look for new maintainers among active contributors." -msgstr "アクティブなコントリビューターの中から、新しいメンテナーを探します。" - -#: ../../rst/community/maintainers_guidelines.rst:112 -msgid "Announce that your collection welcomes new maintainers." -msgstr "コレクションが新しいメンテナーを歓迎していることを発表します。" - -#: ../../rst/community/maintainers_guidelines.rst:113 -msgid "Take part and congratulate new maintainers in Contributor Summits." -msgstr "コントリビューターサミットに参加し、新しいメンテナーを祝福します。" - -#: ../../rst/community/maintainers_guidelines.rst:119 -msgid "Encouraging new contributors" -msgstr "新しいコントリビューターを奨励する" - -#: ../../rst/community/maintainers_guidelines.rst:121 -msgid "Easy-fix items are the best way to attract and mentor new contributors. You should triage incoming issues to mark them with labels such as ``easyfix``, ``waiting_on_contributor``, and ``docs``. where appropriate. Do not fix these trivial non-critical bugs yourself. Instead, mentor a person who wants to contribute." -msgstr "簡単な修正項目は、新しいコントリビューターを引き付けて指導するための最良の方法です。入ってくる issue をトリアージして、必要に応じて ``easyfix``、``waiting_on_contributor``、および ``docs`` などのラベルでマークする必要があります。これらの重要ではない些細なバグを自分で修正しないでください。代わりに、貢献したい人に指導してください。" - -#: ../../rst/community/maintainers_guidelines.rst:123 -msgid "For some easy-fix issues, you could ask the issue reporter whether they want to fix the issue themselves providing the link to a quick start guide for creating PRs." -msgstr "簡単に修正できる問題については、PR を作成するためのクイックスタートガイドへのリンクを提供して、issue を自分で修正するかどうかを issue レポーターに尋ねることができます。" - -#: ../../rst/community/maintainers_guidelines.rst:125 -msgid "Conduct pull request days regularly. You could plan PR days, for example, on the last Friday of every month when you and other maintainers go through all open issues and pull requests focusing on old ones, asking people if you can help, and so on. If there are pull requests that look abandoned (for example, there is no response on your help offers since the previous PR day), announce that anyone else interested can complete the pull request." -msgstr "プルリクエストデーを定期的に実施してください。たとえば、毎月の最終金曜日に PR デーを計画し、あなたと他のメンテナーがすべての未解決の issue や古い issue に焦点を当てたプルリクエストに目を通し、手伝えるかどうかを人々に尋ねる、などといったことが考えられます。もし放置されているようなプルリクエストがあれば (たとえば、前回のPR デー以降、あなたがヘルプに対して反応がない場合など)、興味のある人なら誰でもそのプルリクエストを完了できるようにアナウンスしてください。" - -#: ../../rst/community/maintainers_guidelines.rst:127 -msgid "Promote active contributors satisfying :ref:`requirements` to maintainers. Revise contributors' activity regularly." -msgstr ":ref:`requirements` を満たすアクティブなコントリビューターをメンテナーに昇進させます。コントリビューターの活動を定期的に見直します。" - -#: ../../rst/community/maintainers_guidelines.rst:129 -msgid "If your collection found new maintainers, announce that fact in the `Bullhorn newsletter `_ and during the next Contributor Summit congratulating and thanking them for the work done. You can mention all the people promoted since the previous summit. Remember to invite the other maintainers to the Summit in advance." -msgstr "コレクションが新しいメンテナーを見つけた場合は、`Bullhorn ニュースレター `_ および次回のコントリビューターサミットでそのことをアナウンスし、貢献してくれたことを祝福し、感謝します。前回のサミット以降に昇進したすべての人に言及することができます。事前に他のメンテナーをサミットに招待することを忘れないでください" - -#: ../../rst/community/maintainers_guidelines.rst:131 -msgid "Some other general guidelines to encourage contributors:" -msgstr "コントリビューターを奨励するための他の一般的なガイドラインを以下に示します。" - -#: ../../rst/community/maintainers_guidelines.rst:133 -msgid "Welcome the author and thank them for the issue or pull request." -msgstr "作成者を歓迎し、issue またはプル要求に謝意を示します。" - -#: ../../rst/community/maintainers_guidelines.rst:134 -msgid "If there is a non-crucial easy-fix bug reported, politely ask the author to fix it themselves providing a link to :ref:`collection_quickstart`." -msgstr "重要ではない簡単に修正できるバグが報告された場合は、作成者に自分で修正するように丁寧に依頼し、:ref:`collection_quickstart` のリンクを提供します。" - -#: ../../rst/community/maintainers_guidelines.rst:135 -msgid "When suggesting changes, try to use questions, not statements." -msgstr "変更を提案する場合は、意見ではなく質問で対応するようにします。" - -#: ../../rst/community/maintainers_guidelines.rst:136 -msgid "When suggesting mandatory changes, do it as politely as possible providing documentation references." -msgstr "必須の変更を提案する場合は、参照ドキュメントを提示しつつ、可能な限り丁寧に行います。" - -#: ../../rst/community/maintainers_guidelines.rst:137 -msgid "If your suggestion is optional or a matter of personal preference, please say it explicitly." -msgstr "任意の提案や、個人の好みによる提案は、その旨を明確に示します。" - -#: ../../rst/community/maintainers_guidelines.rst:138 -msgid "When asking for adding tests or for complex code refactoring, say that the author is welcome to ask for clarifications and help if they need it." -msgstr "追加テストや複雑なコードリファクタリングを求める場合は、作成者がさらに明確な説明や助力を提供できるこに言及します。" - -#: ../../rst/community/maintainers_guidelines.rst:139 -msgid "If somebody suggests a good idea, mention it or put a thumbs up." -msgstr "誰かが良いアイデアを提案していれば、メンションまたはサムズアップを行います。" - -#: ../../rst/community/maintainers_guidelines.rst:140 -msgid "After merging, thank the author and reviewers for their time and effort." -msgstr "マージした後、時間と手間をかけて対応した作成者とレビュー担当者に謝意を示します。" - -#: ../../rst/community/maintainers_guidelines.rst:142 -msgid "See the :ref:`review_checklist` for a list of items to check before you merge a PR." -msgstr "PR をマージする前に確認する項目一覧は、:ref:`review_checklist` を参照してください。" - -#: ../../rst/community/maintainers_guidelines.rst:147 -msgid "Maintaining good collection documentation" -msgstr "優れたコレクションドキュメントの維持" - -#: ../../rst/community/maintainers_guidelines.rst:149 -msgid "Maintainers look after the collection documentation to ensure it matches the :ref:`style_guide`. This includes keeping the following documents accurate and updated regularly:" -msgstr "メンテナーは、コレクションのドキュメントを管理して、:ref:`style_guide` と一致することを確認します。これには、以下のドキュメントを正確に維持し、定期的に更新することが含まれます。" - -#: ../../rst/community/maintainers_guidelines.rst:151 -msgid "Collection module and plugin documentation that adheres to the :ref:`Ansible documentation format `." -msgstr ":ref:`Ansible documentation format ` に準拠するコレクションモジュールとプラグインドキュメント。" - -#: ../../rst/community/maintainers_guidelines.rst:152 -msgid "Collection user guides that follow the :ref:`Collection documentation format `." -msgstr ":ref:`Collection のドキュメント形式 ` に従うコレクションユーザーガイド。" - -#: ../../rst/community/maintainers_guidelines.rst:153 -msgid "Repository files that includes at least a ``README`` and ``CONTRIBUTING`` file." -msgstr "少なくとも ``README`` および ``CONTRIBUTING`` ファイルが含まれるリポジトリーファイル。" - -#: ../../rst/community/maintainers_guidelines.rst:155 -msgid "A good ``README`` includes a description of the collection, a link to the :ref:`code_of_conduct`, and details on how to contribute or a pointer to the ``CONTRIBUTING`` file. If your collection is a part of Ansible (is shipped with Ansible package), highlight that fact at the top of the collection's ``README``." -msgstr "適切な ``README`` には、コレクションの説明、:ref:`code_of_conduct` へのリンク、および貢献する方法の詳細または ``CONTRIBUTING`` ファイルへのポインターが含まれています。コレクションが Ansible の一部 (Ansible パッケージに同梱) である場合は、その事実をコレクションの ``README`` の上部で強調表示します。" - -#: ../../rst/community/maintainers_guidelines.rst:157 -msgid "The ``CONTRIBUTING`` file includes all the details or links to the details on how a new or continuing contributor can contribute to this collection. The ``CONTRIBUTING`` file should include:" -msgstr "``CONTRIBUTING`` ファイルには、新規または継続的なコントリビューターが、このコレクションに貢献する方法に関するすべての詳細または詳細へのリンクが含まれています。``CONTRIBUTING`` ファイルには以下が含まれている必要があります。" - -#: ../../rst/community/maintainers_guidelines.rst:159 -msgid "Information or links to new contributor guidelines, such as a quick start on opening PRs." -msgstr "PR を作成するためのクイックスタートなど、新しいコントリビューターガイドラインの情報またはリンク先。" - -#: ../../rst/community/maintainers_guidelines.rst:160 -msgid "Information or links to contributor requirements, such as unit and integration test requirements." -msgstr "ユニットおよび統合テストの要件など、コントリビューターの要件の情報またはリンク先。" - -#: ../../rst/community/maintainers_guidelines.rst:162 -msgid "You can optionally include a ``CONTRIBUTORS`` and ``MAINTAINERS`` file to list the collection contributors and maintainers." -msgstr "オプションで、``CONTRIBUTORS`` および ``MAINTAINERS`` ファイルを追加して、コレクションのコントリビューターおよびメンテナーを一覧表示できます。" - -#: ../../rst/community/maintainers_workflow.rst:5 -msgid "Backporting and Ansible inclusion" -msgstr "バックポートと Ansible インクルージョン" - -#: ../../rst/community/maintainers_workflow.rst:7 -msgid "Each collection community can set its own rules and workflow for managing pull requests, bug reports, documentation issues, and feature requests, as well as adding and replacing maintainers. Maintainers review and merge pull requests following the:" -msgstr "各コレクションコミュニティーは、プル要求、バグレポート、ドキュメント issue、および機能リクエストを管理する独自のルールおよびワークフローを設定できます。また、メンテナーの追加および交代も可能です。メンテナーは、以下に従って、プルリクエストを確認してマージします。" - -#: ../../rst/community/maintainers_workflow.rst:9 -msgid ":ref:`code_of_conduct`" -msgstr ":ref:`code_of_conduct`" - -#: ../../rst/community/maintainers_workflow.rst:10 -msgid ":ref:`maintainer_requirements`" -msgstr ":ref:`maintainer_requirements`" - -#: ../../rst/community/maintainers_workflow.rst:11 -msgid ":ref:`Committer guidelines `" -msgstr ":ref:`Committer guidelines `" - -#: ../../rst/community/maintainers_workflow.rst:12 -msgid ":ref:`PR review checklist`" -msgstr ":ref:`PR review checklist`" - -#: ../../rst/community/maintainers_workflow.rst:14 -msgid "There can be two kinds of maintainers: :ref:`collection_maintainers` and :ref:`module_maintainers`." -msgstr "メンテナーには、:ref:`collection_maintainers` と :ref:`module_maintainers` の 2 種類があります。" - -#: ../../rst/community/maintainers_workflow.rst:19 -msgid "Collection maintainers" -msgstr "コレクションメンテナー" - -#: ../../rst/community/maintainers_workflow.rst:21 -msgid "Collection-scope maintainers are contributors who have the ``write`` or higher access level in a collection. They have commit rights and can merge pull requests, among other permissions." -msgstr "コレクションスコープのメンテナーは、コレクションの ``write`` 以上のアクセスレベルを持つコントリビューターです。彼らにはコミット権限があり、他の権限の中でもプルリクエストをマージできます。" - -#: ../../rst/community/maintainers_workflow.rst:23 -msgid "When a collection maintainer considers a contribution to a file significant enough (for example, fixing a complex bug, adding a feature, providing regular reviews, and so on), they can invite the author to become a module maintainer." -msgstr "コレクションメンテナーがファイルへの貢献が十分に重要であると判断した場合 (たとえば、複雑なバグの修正、機能の追加、定期的なレビューの提供など)、作者をモジュールメンテナーにすることができます。" - -#: ../../rst/community/maintainers_workflow.rst:31 -msgid "Module maintainers" -msgstr "モジュールメンテナー" - -#: ../../rst/community/maintainers_workflow.rst:33 -msgid "Module-scope maintainers exist in collections that have the `collection bot `_, for example, `community.general `_ and `community.network `_." -msgstr "モジュールスコープのメンテナーは、`collection bot `_ のあるコレクションに存在します (例: `community.general `_ および `community.network `_)。" - -#: ../../rst/community/maintainers_workflow.rst:37 -msgid "Being a module maintainer is the stage prior to becoming a collection maintainer. Module maintainers are contributors who are listed in ``.github/BOTMETA.yml``. The scope can be any file (for example, a module or plugin), directory, or repository. Because in most cases the scope is a module or group of modules, we call these contributors module maintainers. The collection bot notifies module maintainers when issues/pull requests related to files they maintain are created." -msgstr "モジュールメンテナーになることは、コレクションメンテナーになる前の段階になります。モジュールメンテナーは、``.github/BOTMETA.yml`` にリストされているコントリビューターです。スコープは、任意のファイル (たとえば、モジュールまたはプラグイン)、ディレクトリー、またはリポジトリーにすることができます。ほとんどの場合、スコープはモジュールまたはモジュールのグループであるため、これらのコントリビューターをモジュールメンテナーと呼びます。コレクションボットは、モジュールメンテナーが維持するファイルに関連する issue/プルリクエストが作成されると、モジュールメンテナーに通知します。" - -#: ../../rst/community/maintainers_workflow.rst:39 -msgid "Module maintainers have indirect commit rights implemented through the `collection bot `_. When two module maintainers comment with the keywords ``shipit``, ``LGTM``, or ``+1`` on a pull request which changes a module they maintain, the collection bot merges the pull request automatically." -msgstr "モジュールメンテナーには、`collection bot `_ を介して実装された間接的なコミット権限があります。2 つのモジュールのメンテナーが、管理するモジュールを変更するプル要求で、キーワード ``shipit``、``LGTM``、または ``+1`` でコメントすると、コレクションボットはプル要求を自動的にマージします。" - -#: ../../rst/community/maintainers_workflow.rst:43 -msgid "For more information about the collection bot and its interface, see to the `Collection bot overview `_." -msgstr "コレクションボットおよびそのインターフェイスの詳細は、`Collection bot の概要 `_ を参照してください。" - -#: ../../rst/community/maintainers_workflow.rst:48 -msgid "Releasing a collection" -msgstr "コレクションのリリース" - -#: ../../rst/community/maintainers_workflow.rst:50 -msgid "Collection maintainers are responsible for releasing new versions of a collection. Generally, releasing a collection consists of:" -msgstr "コレクションのメンテナーは、コレクションの新しいバージョンをリリースする責任があります。通常、コレクションのリリースは、以下で構成されます。" - -#: ../../rst/community/maintainers_workflow.rst:52 -msgid "Planning and announcement." -msgstr "計画および発表。" - -#: ../../rst/community/maintainers_workflow.rst:53 -msgid "Generating a changelog." -msgstr "changelog の生成" - -#: ../../rst/community/maintainers_workflow.rst:54 -msgid "Creating a release git tag and pushing it." -msgstr "リリース git タグの作成とプッシュ。" - -#: ../../rst/community/maintainers_workflow.rst:55 -msgid "Automatically publishing the release tarball on `Ansible Galaxy `_ through the `Zuul dashboard `_." -msgstr "`Zuul dashboard `_ を使用して、`Ansible Galaxy `_ にリリース tarball を自動公開します。" - -#: ../../rst/community/maintainers_workflow.rst:56 -msgid "Final announcement." -msgstr "最終発表。" - -#: ../../rst/community/maintainers_workflow.rst:57 -msgid "Optionally, `file a request to include a new collection into the Ansible package `_." -msgstr "オプションで、`Ansible パッケージに新しいコレクションを追加するためにリクエストします `_。" - -#: ../../rst/community/maintainers_workflow.rst:59 -msgid "See :ref:`releasing_collections` for details." -msgstr "詳しくは、:ref:`releasing_collections` を参照してください。" - -#: ../../rst/community/maintainers_workflow.rst:64 -msgid "Backporting" -msgstr "バックポート" - -#: ../../rst/community/maintainers_workflow.rst:66 -msgid "Collection maintainers backport merged pull requests to stable branches following the `semantic versioning `_ and release policies of the collections." -msgstr "コレクションメンテナーは、コレクションの `セマンティックバージョニング `_ およびリリースポリシーに従って、安定したブランチにマージされたプル要求をバックポートします。" - -#: ../../rst/community/maintainers_workflow.rst:69 -msgid "The manual backport process is similar to the :ref:`ansible-core backporting guidelines `." -msgstr "手動バックポートプロセスは :ref:`ansible-core のバックポートガイドライン ` に似ています。" - -#: ../../rst/community/maintainers_workflow.rst:71 -msgid "For convenience, backporting can be implemented automatically using GitHub bots (for example, with the `Patchback app `_) and labeling as it is done in `community.general `_ and `community.network `_." -msgstr "便宜上、バックポートは GitHub ボットを使用して自動的に実装できます (例: `Patchback app `_ を使用)。また、`community.general `_ および `community.network `_ で行われるようにラベル付けできます。" - -#: ../../rst/community/maintainers_workflow.rst:77 -msgid "Including a collection in Ansible" -msgstr "Ansible へのコレクションの追加" - -#: ../../rst/community/maintainers_workflow.rst:79 -msgid "If a collection is not included in Ansible (not shipped with Ansible package), maintainers can submit the collection for inclusion by creating a discussion under the `ansible-collections/ansible-inclusion repository `_. For more information, see the `repository's README `_, and the `Ansible community package collections requirements `." -msgstr "コレクションが Ansible に含まれていない (Ansible パッケージに同梱されていない) 場合、メンテナーは、`ansible-collections/ansible-inclusion repository `_ の下にディスカッションを作成して、インクルージョンのコレクションを送信できます。詳細は、`repository's README `_ および `Ansible community package collections requirements ` を参照してください。" - -#: ../../rst/community/maintainers_workflow.rst:82 -msgid "Stepping down as a collection maintainer" -msgstr "コレクションのメンテナーを辞任する" - -#: ../../rst/community/maintainers_workflow.rst:84 -msgid "Times change, and so may your ability to continue as a collection maintainer. We ask that you do not step down silently." -msgstr "時は変わり、コレクションのメンテナーとして続行する能力も変わります。辞任する際は一言お知らせください。" - -#: ../../rst/community/maintainers_workflow.rst:86 -msgid "If you feel you don't have time to maintain your collection anymore, you should:" -msgstr "コレクションを維持する時間がなくなったと感じる場合は、以下を行う必要があります。" - -#: ../../rst/community/maintainers_workflow.rst:88 -msgid "Inform other maintainers about it." -msgstr "この件を他のメンテナーに通知します。" - -#: ../../rst/community/maintainers_workflow.rst:89 -msgid "If the collection is under the ``ansible-collections`` organization, also inform relevant :ref:`communication_irc`, the ``community`` chat channels on IRC or matrix, or by email ``ansible-community@redhat.com``." -msgstr "コレクションが ``ansible-collections`` 組織の下にある場合は、関連する :ref:`communication_irc`、IRC またはマトリックスの ``community`` チャットチャンネル、またはメール ``ansible-community@redhat.com`` にも通知します。" - -#: ../../rst/community/maintainers_workflow.rst:90 -msgid "Look at active contributors in the collection to find new maintainers among them. Discuss the potential candidates with other maintainers or with the community team." -msgstr "コレクション内のアクティブなコントリビューターを確認して、その中から新しいメンテナーを見つけてください。潜在的な候補者について、他のメンテナーまたはコミュニティーチームと話し合います。" - -#: ../../rst/community/maintainers_workflow.rst:91 -msgid "If you failed to find a replacement, create a pinned issue in the collection, announcing that the collection needs new maintainers." -msgstr "代わりの人が見つからない場合は、コレクションで固定された issue を作成し、コレクションに新しいメンテナーが必要であることをアナウンスします。" - -#: ../../rst/community/maintainers_workflow.rst:92 -msgid "Make the same announcement through the `Bullhorn newsletter `_." -msgstr "`Bullhorn ニュースレター `_ で、同じ発表を行います。" - -#: ../../rst/community/maintainers_workflow.rst:93 -msgid "Please be around to discuss potential candidates found by other maintainers or by the community team." -msgstr "他のメンテナーやコミュニティチームが見つけた候補者について議論する場としてご利用ください。" - -#: ../../rst/community/maintainers_workflow.rst:95 -msgid "Remember, this is a community, so you can come back at any time in the future." -msgstr "ここはコミュニティーなので、今後いつでも戻ってこられることを覚えておいてください。" - -#: ../../rst/community/other_tools_and_programs.rst:5 -msgid "Other Tools and Programs" -msgstr "その他のツールおよびプログラム" - -#: ../../rst/community/other_tools_and_programs.rst:10 -msgid "The Ansible community uses a range of tools for working with the Ansible project. This is a list of some of the most popular of these tools." -msgstr "Ansible コミュニティーは、Ansible プロジェクトで作業するためにさまざまなツールを使用します。ここでは、これらのツールの中でも特に人気のあるものをいくつか紹介します。" - -#: ../../rst/community/other_tools_and_programs.rst:12 -msgid "If you know of any other tools that should be added, this list can be updated by clicking \"Edit on GitHub\" on the top right of this page." -msgstr "他にも追加すべきツールがあれば、このページの右上にある「Edit on GitHub」をクリックすると、この一覧を更新できます。" - -#: ../../rst/community/other_tools_and_programs.rst:16 -msgid "Popular editors" -msgstr "人気のあるエディター" - -#: ../../rst/community/other_tools_and_programs.rst:19 -msgid "Atom" -msgstr "Atom" - -#: ../../rst/community/other_tools_and_programs.rst:21 -msgid "An open-source, free GUI text editor created and maintained by GitHub. You can keep track of git project changes, commit from the GUI, and see what branch you are on. You can customize the themes for different colors and install syntax highlighting packages for different languages. You can install Atom on Linux, macOS and Windows. Useful Atom plugins include:" -msgstr "GitHub で作成および保守されるオープンソースの無料 GUI テキストエディター。git プロジェクトの変更を追跡したり、GUI からコミットしたり、自分がどのブランチにいるかを確認できます。テーマをカスタマイズして色を変えたり、言語ごとに構文強調表示パッケージをインストールしたりできます。Atom は、Linux、macOS、および Windows にインストールできます。便利な Atom プラグインには以下が含まれます。" - -#: ../../rst/community/other_tools_and_programs.rst:24 -msgid "`language-yaml `_ - YAML highlighting for Atom (built-in)." -msgstr "`language-yaml `_ - Atom での YAML の強調表示 (組み込み)。" - -#: ../../rst/community/other_tools_and_programs.rst:25 -msgid "`linter-js-yaml `_ - parses your YAML files in Atom through js-yaml." -msgstr "`linter-js-yaml `_ - js-yaml を介して Atom で YAML ファイルを解析。" - -#: ../../rst/community/other_tools_and_programs.rst:29 -msgid "Emacs" -msgstr "Emacs" - -#: ../../rst/community/other_tools_and_programs.rst:31 -msgid "A free, open-source text editor and IDE that supports auto-indentation, syntax highlighting and built in terminal shell(among other things)." -msgstr "無料でオープンソースのテキストエディターと IDE。オートインデント、構文強調表示、端末シェルでのビルドなどをサポートします。" - -#: ../../rst/community/other_tools_and_programs.rst:33 -msgid "`yaml-mode `_ - YAML highlighting and syntax checking." -msgstr "`yaml-mode `_ - YAML の強調表示と構文のチェック。" - -#: ../../rst/community/other_tools_and_programs.rst:34 -msgid "`jinja2-mode `_ - Jinja2 highlighting and syntax checking." -msgstr "`jinja2-mode `_ - Jinja2 の強調表示と構文の確認。" - -#: ../../rst/community/other_tools_and_programs.rst:35 -msgid "`magit-mode `_ - Git porcelain within Emacs." -msgstr "`magit-mode `_ - Emacs 内での git porcelain (磁器)。" - -#: ../../rst/community/other_tools_and_programs.rst:36 -msgid "`lsp-mode `_ - Ansible syntax highlighting, auto-completion and diagnostics." -msgstr "`lsp-mode `_ - Ansible 構文の強調表示、自動補完、および診断。" - -#: ../../rst/community/other_tools_and_programs.rst:40 -msgid "PyCharm" -msgstr "PyCharm" - -#: ../../rst/community/other_tools_and_programs.rst:42 -msgid "A full IDE (integrated development environment) for Python software development. It ships with everything you need to write python scripts and complete software, including support for YAML syntax highlighting. It's a little overkill for writing roles/playbooks, but it can be a very useful tool if you write modules and submit code for Ansible. Can be used to debug the Ansible engine." -msgstr "Python ソフトウェア開発向けの完全な IDE (統合開発環境)。これには、YAML 構文強調表示のサポートを含む、Python スクリプトを記述するのに必要なすべてのものと完全なソフトウェアが同梱されています。ロール/Playbook の作成には少し時間がかかりますが、モジュールを作成し、Ansible 用のコードを送信する場合は、非常に便利なツールになります。Ansible エンジンのデバッグに使用できます。" - -#: ../../rst/community/other_tools_and_programs.rst:46 -msgid "Sublime" -msgstr "Sublime" - -#: ../../rst/community/other_tools_and_programs.rst:48 -msgid "A closed-source, subscription GUI text editor. You can customize the GUI with themes and install packages for language highlighting and other refinements. You can install Sublime on Linux, macOS and Windows. Useful Sublime plugins include:" -msgstr "クローズドソースのサブスクリプション GUI テキストエディター。テーマを使用して GUI をカスタマイズしたり、言語の強調表示やその他の改良のためのパッケージをインストールしたりすることができます。Sublime は Linux、macOS、Windows にインストールできます。便利な Sublime プラグインには以下のものがあります。" - -#: ../../rst/community/other_tools_and_programs.rst:50 -msgid "`GitGutter `_ - shows information about files in a git repository." -msgstr "`GitGutter `_ - git リポジトリー内のファイルに関する情報を表示します。" - -#: ../../rst/community/other_tools_and_programs.rst:51 -msgid "`SideBarEnhancements `_ - provides enhancements to the operations on Sidebar of Files and Folders." -msgstr "`SideBarEnhancements `_ - ファイルおよびディレクトリーのサイドバーに対する操作の強化を提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:52 -msgid "`Sublime Linter `_ - a code-linting framework for Sublime Text 3." -msgstr "`Sublime Linter `_ - Sublime Text 3 のコードの文法チェックフレームワークです。" - -#: ../../rst/community/other_tools_and_programs.rst:53 -msgid "`Pretty YAML `_ - prettifies YAML for Sublime Text 2 and 3." -msgstr "`Pretty YAML `_ - Sublime Text 2 および 3 の YAML を事前設定します。" - -#: ../../rst/community/other_tools_and_programs.rst:54 -msgid "`Yamllint `_ - a Sublime wrapper around yamllint." -msgstr "`Yamllint `_ - yamllint に関する Sublime ラッパーです。" - -#: ../../rst/community/other_tools_and_programs.rst:58 -msgid "Visual studio code" -msgstr "Visual Studio コード" - -#: ../../rst/community/other_tools_and_programs.rst:60 -msgid "An open-source, free GUI text editor created and maintained by Microsoft. Useful Visual Studio Code plugins include:" -msgstr "Microsoft が作成および管理するオープンソースの無料 GUI テキストエディター。便利な Visual Studio Code プラグインには以下が含まれます。" - -#: ../../rst/community/other_tools_and_programs.rst:62 -msgid "`Ansible extension by Red Hat `_ - provides autocompletion, syntax highlighting, hover, diagnostics, goto support, and command to run ansible-playbook and ansible-navigator tool for both local and execution-environment setups." -msgstr "`Ansible extension by Red Hat `_ - 自動補完、構文強調表示、ホバー、診断、goto サポート、およびコマンドを提供し、ローカル環境と実行環境設定の両方のセットアップで、ansible-playbook と ansible-navigator ツールを実行します。" - -#: ../../rst/community/other_tools_and_programs.rst:63 -msgid "`YAML Support by Red Hat `_ - provides YAML support through yaml-language-server with built-in Kubernetes and Kedge syntax support." -msgstr "`YAML Support by Red Hat `_ - Kubernetes と Kedge の構文サポートを組み込んだ yaml-language-server を通じて YAML サポートを提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:66 -msgid "vim" -msgstr "vim" - -#: ../../rst/community/other_tools_and_programs.rst:68 -msgid "An open-source, free command-line text editor. Useful vim plugins include:" -msgstr "オープンソースの無料コマンドラインテキストエディター。便利な vim プラグインには以下が含まれます。" - -#: ../../rst/community/other_tools_and_programs.rst:70 -msgid "`Ansible vim `_ - vim syntax plugin for Ansible 2.x, it supports YAML playbooks, Jinja2 templates, and Ansible's hosts files." -msgstr "`Ansible vim `_ - Ansible 2.x の vim 構文プラグイン。YAML Playbook、Jinja2 テンプレート、および Ansible ホストファイルをサポートします。" - -#: ../../rst/community/other_tools_and_programs.rst:71 -msgid "`Ansible vim and neovim plugin `_ - vim plugin (lsp client) for Ansible, it supports autocompletion, syntax highlighting, hover, diagnostics, and goto support." -msgstr "`Ansible vim and neovim plugin `_ - Ansible 用の vim プラグイン (lsp クライアント)。自動補完、構文強調表示、ホバー、診断、および goto サポートをサポートします。" - -#: ../../rst/community/other_tools_and_programs.rst:74 -msgid "JetBrains" -msgstr "JetBrains" - -#: ../../rst/community/other_tools_and_programs.rst:76 -msgid "An open-source Community edition and closed-source Enterprise edition, integrated development environments based on IntelliJ's framework including IDEA, AppCode, CLion, GoLand, PhpStorm, PyCharm and others. Useful JetBrains platform plugins include:" -msgstr "オープンソースのコミュニティーエディションとクローズドソースのエンタープライズエディション、IntelliJ のフレームワークに基づく統合開発環境 (IDEA、AppCode、CLion、GoLand、PhpStorm、PyCharm などを含む)。便利な JetBrains プラットフォームプラグインは次のとおりです。" - -#: ../../rst/community/other_tools_and_programs.rst:78 -msgid "`Ansible `_ - general Ansible plugin provides auto-completion, role name suggestion and other handy features for working with playbooks and roles." -msgstr "`Ansible `_ - 一般的な Ansible プラグインは、オートコンプリート、ロール名の提案、および Playbook およびロールを操作するためのその他の便利な機能を提供します。" - -#: ../../rst/community/other_tools_and_programs.rst:80 -msgid "`Ansible Vault Editor `_ - Ansible Vault Editor with auto encryption/decryption." -msgstr "`Ansible Vault Editor `_ - 自動暗号化/復号機能を使用した Ansible Vault エディター" - -#: ../../rst/community/other_tools_and_programs.rst:84 -msgid "Development tools" -msgstr "開発ツール" - -#: ../../rst/community/other_tools_and_programs.rst:87 -msgid "Finding related issues and PRs" -msgstr "関連する問題およびプル要求の検索" - -#: ../../rst/community/other_tools_and_programs.rst:89 -msgid "There are various ways to find existing issues and pull requests (PRs)" -msgstr "既存の問題およびプル要求を特定する方法は複数あります。" - -#: ../../rst/community/other_tools_and_programs.rst:91 -msgid "`PR by File `_ - shows a current list of all open pull requests by individual file. An essential tool for Ansible module maintainers." -msgstr "`ファイル別のプル要求 `_ - 個別ファイルによるオープンのプル要求の現在の一覧を表示します。Ansible モジュールのメンテナーにとって不可欠なツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:92 -msgid "`jctanner's Ansible Tools `_ - miscellaneous collection of useful helper scripts for Ansible development." -msgstr "`jctanner の Ansible ツール `_ - Ansible 開発に役立つヘルパースクリプトのさまざまなコレクション。" - -#: ../../rst/community/other_tools_and_programs.rst:98 -msgid "Tools for validating playbooks" -msgstr "Playbook を検証するためのツール" - -#: ../../rst/community/other_tools_and_programs.rst:100 -msgid "`Ansible Lint `_ - a highly configurable linter for Ansible playbooks." -msgstr "`Ansible Lint `_ - Ansible Playbook の高度な設定可能な文法チェックプログラムです。" - -#: ../../rst/community/other_tools_and_programs.rst:101 -msgid "`Ansible Review `_ - an extension of Ansible Lint designed for code review." -msgstr "`Ansible Review `_ - コードレビュー用に設計された Ansible Lint の拡張機能です。" - -#: ../../rst/community/other_tools_and_programs.rst:102 -msgid "`Molecule `_ - a testing framework for Ansible plays and roles." -msgstr "`Molecule `_ - は、Anbile による Ansible のプレイおよびロールのテストフレームワークです。" - -#: ../../rst/community/other_tools_and_programs.rst:103 -msgid "`yamllint `__ - a command-line utility to check syntax validity including key repetition and indentation issues." -msgstr "`yamllint `__ - キーの繰り返しやインデントの問題など、構文の有効性を確認するコマンドラインユーティリティーです。" - -#: ../../rst/community/other_tools_and_programs.rst:108 -msgid "Other tools" -msgstr "その他のツール" - -#: ../../rst/community/other_tools_and_programs.rst:110 -msgid "`Ansible cmdb `_ - takes the output of Ansible's fact gathering and converts it into a static HTML overview page containing system configuration information." -msgstr "`Ansible cmdb `_ - Ansible のファクト収集の出力を受け取り、システム設定情報が含まれる静的 HTML 概要ページに変換します。" - -#: ../../rst/community/other_tools_and_programs.rst:111 -msgid "`Ansible Inventory Grapher `_ - visually displays inventory inheritance hierarchies and at what level a variable is defined in inventory." -msgstr "`Ansible Inventory Grapher `_ - インベントリーの継承階層と、変数がインベントリーで定義されているレベルを視覚的に表示します。" - -#: ../../rst/community/other_tools_and_programs.rst:112 -msgid "`Ansible Language Server `_ - a server that implements `language server protocol `_ for Ansible." -msgstr "`Ansible Language Server `_ - Ansible 用の `language server protocol `_ を実装するサーバー。" - -#: ../../rst/community/other_tools_and_programs.rst:113 -msgid "`Ansible Playbook Grapher `_ - a command line tool to create a graph representing your Ansible playbook tasks and roles." -msgstr "`Ansible Playbook Grapher `_ - Ansible Playbook のタスクおよびロールを表すグラフを作成するコマンドラインツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:114 -msgid "`Ansible Shell `_ - an interactive shell for Ansible with built-in tab completion for all the modules." -msgstr "`Ansible Shell `_ - すべてのモジュールのタブ補完が組み込まれている Ansible 用のインタラクティブシェルです。" - -#: ../../rst/community/other_tools_and_programs.rst:115 -msgid "`Ansible Silo `_ - a self-contained Ansible environment by Docker." -msgstr "`Ansible Silo `_ - Docker による自己完結型の Ansible 環境です。" - -#: ../../rst/community/other_tools_and_programs.rst:116 -msgid "`Ansigenome `_ - a command line tool designed to help you manage your Ansible roles." -msgstr "`Ansigenome `_ - Ansible ロールの管理に役立つように設計されたコマンドラインツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:117 -msgid "`ARA `_ - ARA Records Ansible playbooks and makes them easier to understand and troubleshoot with a reporting API, UI and CLI." -msgstr "`ARA `_ - ARAはAnsibleプレイブックを記録し、レポートAPI、UI、CLIを使用して理解とトラブルシューティングを容易にします。" - -#: ../../rst/community/other_tools_and_programs.rst:118 -msgid "`Awesome Ansible `_ - a collaboratively curated list of awesome Ansible resources." -msgstr "`Awesome Ansible `_ - Awesome Ansible リソースの共同キュレーションの一覧です。" - -#: ../../rst/community/other_tools_and_programs.rst:119 -msgid "`AWX `_ - provides a web-based user interface, REST API, and task engine built on top of Ansible. Red Hat Ansible Automation Platform includes code from AWX." -msgstr "`AWX `_ - Ansible 上に構築された Web ベースのユーザーインターフェース、REST API、およびタスクエンジンを提供します。Red Hat Ansible Automation Platform には、AWX のコードが含まれています。" - -#: ../../rst/community/other_tools_and_programs.rst:120 -msgid "`Mitogen for Ansible `_ - uses the `Mitogen `_ library to execute Ansible playbooks in a more efficient way (decreases the execution time)." -msgstr "`Mitogen for Ansible `_ - `Mitogen `_ ライブラリーを使用して、より効率的な方法で Ansible Playbook を実行します (実行時間を短縮します)。" - -#: ../../rst/community/other_tools_and_programs.rst:121 -msgid "`nanvault `_ - a standalone tool to encrypt and decrypt files in the Ansible Vault format, featuring UNIX-style composability." -msgstr "`nanvault `_ - UNIX 形式の構成機能を備えた Ansible Vault 形式ファイルの暗号化および復号を行うスタンドアロンツールです。" - -#: ../../rst/community/other_tools_and_programs.rst:122 -msgid "`OpsTools-ansible `_ - uses Ansible to configure an environment that provides the support of `OpsTools `_, namely centralized logging and analysis, availability monitoring, and performance monitoring." -msgstr "`OpsTools-ansible `_ - Ansible を使用して `OpsTools `_ のサポートを提供する環境 (中央型ロギングと分析、可用性監視、パフォーマンスの監視など) を設定します。" - -#: ../../rst/community/other_tools_and_programs.rst:123 -msgid "`TD4A `_ - a template designer for automation. TD4A is a visual design aid for building and testing jinja2 templates. It will combine data in yaml format with a jinja2 template and render the output." -msgstr "`TD4A `_ - 自動化のテンプレートデザイナー。TD4A は、jinja2 テンプレートの構築とテストを行うための視覚的な設計支援ツールです。これは、yaml 形式のデータを jinja2 テンプレートと組み合わせ、出力をレンダリングします。" - -#: ../../rst/community/other_tools_and_programs.rst:124 -msgid "`PHP-Ansible `_ - an object oriented Ansible wrapper for PHP." -msgstr "`PHP-Ansible `_: PHP のオブジェクト指向の Ansible ラッパー。" - -#: ../../rst/community/release_managers.rst:5 -msgid "Release Manager Guidelines" -msgstr "リリースマネージャーのガイドライン" - -#: ../../rst/community/release_managers.rst:9 -msgid "The release manager's purpose is to ensure a smooth release. To achieve that goal, they need to coordinate between:" -msgstr "リリースマネージャーの目的は、スムーズなリリースを確保することです。この目的を達成するには、以下について調整する必要があります。" - -#: ../../rst/community/release_managers.rst:12 -msgid "Developers with commit privileges on the `Ansible GitHub repository `_" -msgstr "`Ansible GitHub リポジトリー `_ でコミット権限を持つ開発者" - -#: ../../rst/community/release_managers.rst:13 -msgid "Contributors without commit privileges" -msgstr "コミット権限のない貢献者" - -#: ../../rst/community/release_managers.rst:14 -msgid "The community" -msgstr "コミュニティー" - -#: ../../rst/community/release_managers.rst:15 -msgid "Ansible documentation team" -msgstr "Ansible ドキュメントチーム" - -#: ../../rst/community/release_managers.rst:18 -msgid "Pre-releases: what and why" -msgstr "プレリリース: 何を/なぜ" - -#: ../../rst/community/release_managers.rst:20 -msgid "Pre-releases exist to draw testers. They give people who don't feel comfortable running from source control a means to get an early version of the code to test and give us feedback. To ensure we get good feedback about a release, we need to make sure all major changes in a release are put into a pre-release. Testers must be given time to test those changes before the final release. Ideally we want there to be sufficient time between pre-releases for people to install and test one version for a span of time. Then they can spend more time using the new code than installing the latest version." -msgstr "プレリリース版はテスターを集めるために存在します。プレリリースは、ソース管理からの実行に不安を感じているユーザーに、初期バージョンのコードを手に入れてテストをしたり、フィードバックを行う手段を提供します。リリースに関する適切なフィードバックを確実に得るには、リリースに対する主要な変更がすべてプレリリースに組み込まれているようにする必要があります。テスターには、最終リリースの前にこれらの変更をテストする時間が与えられる必要があります。プレリリースとプレリリースの間に、1 つのバージョンをインストールしてテストするのに十分な時間を確保するのが理想的です。そうすれば、最新バージョンをインストールするよりも、新しいコードを使用することに多くの時間を費やすことができます。" - -#: ../../rst/community/release_managers.rst:28 -msgid "The right length of time for a tester is probably around two weeks. However, for our three-to-four month development cycle to work, we compress this down to one week; any less runs the risk of people spending more time installing the code instead of running it. However, if there's a time crunch (with a release date that cannot slip), it is better to release with new changes than to hold back those changes to give people time to test between. People cannot test what is not released, so we have to get those tarballs out there even if people feel they have to install more frequently." -msgstr "テスターにとって適切な期間は、おそら 2 週間程度です。ただし、3 ~ 4か月の開発サイクルを機能させるために、この期間を 1 週間に短縮しています。これより短くなると、コードを実行する代わりにコードのインストールに多くの時間を費やしてしまう可能性があります。ただし、時間的な制約がある場合は (リリース日がずれないようにするには)、ユーザーにテストする時間を与えるために変更を保留するよりも、新しい変更を加えてリリースする方が良いでしょう。リリースされていないものはテストできないため、たとえより頻繁にインストールしなければならないと思われる場合でも、その tarball は公開すべきです。" - -#: ../../rst/community/release_managers.rst:37 -msgid "Beta releases" -msgstr "ベータリリース" - -#: ../../rst/community/release_managers.rst:39 -msgid "In a beta release, we know there are still bugs. We will continue to accept fixes for these. Although we review these fixes, sometimes they can be invasive or potentially destabilize other areas of the code." -msgstr "ベータリリースでは、バグが存在していることが認識されています。これらの修正は今後も受け入れていきます。これらの修正は確認されますが、場合によっては侵襲的であったり、コードの他の領域を不安定にする可能性があります。" - -#: ../../rst/community/release_managers.rst:43 -msgid "During the beta, we will no longer accept feature submissions." -msgstr "ベータ版では、機能の提出は受け付けなくなります。" - -#: ../../rst/community/release_managers.rst:47 -msgid "Release candidates" -msgstr "リリースの候補 (Release Candidate)" - -#: ../../rst/community/release_managers.rst:49 -msgid "In a release candidate, we've fixed all known blockers. Any remaining bugfixes are ones that we are willing to leave out of the release. At this point we need user testing to determine if there are any other blocker bugs lurking." -msgstr "リリース候補では、既知のすべてのブロッカーを修正しました。残っているバグ修正は、リリースから除外しても構わないと考えています。この時点で、他にもブロッカーバグが潜んでいないかどうかを判断するために、ユーザーテストを行う必要があります。" - -#: ../../rst/community/release_managers.rst:53 -msgid "Blocker bugs generally are those that cause significant problems for users. Regressions are more likely to be considered blockers because they will break present users' usage of Ansible." -msgstr "ブロッカーバグとは、一般的にユーザーに重大な問題を引き起こすバグのことです。リグレッションは、現在のユーザーの Ansible の使用方法に支障をきたすため、ブロッカーと見なされる可能性が高くなります。" - -#: ../../rst/community/release_managers.rst:56 -msgid "The Release Manager will cherry-pick fixes for new release blockers. The release manager will also choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor release. By themselves, non-blocker bugs will not trigger a new release; they will only make it into the next major release if blocker bugs require that a new release be made." -msgstr "リリースマネージャーは、新しいリリースのブロッカーの修正を選択します。また、リリースマネージャーは、コードの孤立した部分のバグ修正を受け入れるか、次のマイナーリリースまで受け入れを延ばすを選択します。単独では、ブロッカー以外のバグは新しいリリースのトリガーにはなりません。ブロッカーのバグにより新しいリリースを作成する必要がある場合にのみ、次のメジャーリリースになります。" - -#: ../../rst/community/release_managers.rst:61 -msgid "The last RC should be as close to the final as possible. The following things may be changed:" -msgstr "最後のプル要求は可能な限り最終版に近いものとなるはずです。以下の点が変更される可能性があります。" - -#: ../../rst/community/release_managers.rst:63 -msgid "Version numbers are changed automatically and will differ as the pre-release tags are removed from the versions." -msgstr "バージョン番号が自動的に変更され、プレリリースのタグが削除されるとバージョンが異なります。" - -#: ../../rst/community/release_managers.rst:65 -msgid "Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime. However, the release manager may still reject them as they have the potential to cause breakage that will be visible during the release process." -msgstr "テストおよび :file:`docs/docsite/` はランタイムを破損しないため、本当に必要であれば変更しても構いません。ただし、リリースプロセス時に目に見える破損を引き起こす可能性がある場合は、リリースマネージャーが拒否する可能性があります。" - -#: ../../rst/community/release_managers.rst:69 -msgid "We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If there are extenuating circumstances, the Release Manager is responsible for notifying groups which would want to test the code." -msgstr "特別な事情がない限り、(:file:`bin/`、:file:`lib/ansible/`、および :file:`setup.py` の) コードは同じでなければなりません。特別な事情がある場合は、リリースマネージャーに、コードをテストしたいグループに通知する責任があります。" - -#: ../../rst/community/release_managers.rst:76 -msgid "Ansible release process" -msgstr "Ansible リリースプロセス" - -#: ../../rst/community/release_managers.rst:78 -msgid "The release process is kept in a `separate document `_ so that it can be easily updated during a release. If you need access to edit this, please ask one of the current release managers to add you." -msgstr "リリースプロセスは、リリース中に簡単に更新できるように、`別のドキュメント `_ に保存されています。これを編集するためのアクセス権が必要な場合は、現在のリリースマネージャーに追加を依頼してください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:6 -msgid "Reporting bugs and requesting features" -msgstr "バグの報告および機能の要求" - -#: ../../rst/community/reporting_bugs_and_features.rst:14 -#: ../../rst/community/reporting_collections.rst:11 -msgid "Reporting a bug" -msgstr "バグの報告" - -#: ../../rst/community/reporting_bugs_and_features.rst:17 -#: ../../rst/community/reporting_collections.rst:14 -msgid "Security bugs" -msgstr "セキュリティーバグ" - -#: ../../rst/community/reporting_bugs_and_features.rst:19 -msgid "Ansible practices responsible disclosure. To report security-related bugs, send an email to `security@ansible.com `_ for an immediate response. Do not submit a ticket or post to any public groups." -msgstr "Ansible は責任のある開示を実践しています。セキュリティー関連のバグを報告する場合は、`security@ansible.com `_ にメールで報告し、迅速な対応を受けてください。チケットの送信や公開グループへの投稿はしないでください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:22 -msgid "Bugs in ansible-core" -msgstr "ansible-core のバグ" - -#: ../../rst/community/reporting_bugs_and_features.rst:24 -msgid "Before reporting a bug, search in GitHub for `already reported issues `_ and `open pull requests `_ to see if someone has already addressed your issue. Unsure if you found a bug? Report the behavior on the :ref:`mailing list or community chat first `." -msgstr "バグを報告する前に、GitHub で `すでにレポートされている issue `_ と `プルリクエストの作成 `_ を検索し、問題がすでに対応されているかどうかを確認します。バグが見つかった場合は、見つけたものがバグかどうか確信がない場合は、:ref:`最初にメーリングリストまたはコミュニティーチャットで ` 動作を報告してください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:26 -msgid "Also, use the mailing list or chat to discuss whether the problem is in ``ansible-core`` or a collection, and for \"how do I do this\" type questions." -msgstr "また、問題が ``ansible-core`` にあるのか、コレクションなのかについて、そして「How do I do this」タイプの質問について、メーリングリストまたはチャットを使用して話し合ってください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:28 -msgid "You need a free GitHub account to `report bugs `_ that affect:" -msgstr "以下に影響を与える `バグをレポートする `_ には、無料の GitHub アカウントが必要です。" - -#: ../../rst/community/reporting_bugs_and_features.rst:30 -msgid "multiple plugins" -msgstr "複数のプラグイン" - -#: ../../rst/community/reporting_bugs_and_features.rst:31 -msgid "a plugin that remained in the ansible/ansible repo" -msgstr "ansible/ansible リポジトリーに残っているプラグイン" - -#: ../../rst/community/reporting_bugs_and_features.rst:32 -msgid "the overall functioning of Ansible" -msgstr "Ansible の全体的な機能" - -#: ../../rst/community/reporting_bugs_and_features.rst:35 -msgid "How to write a good bug report" -msgstr "適切なバグレポートの作成方法" - -#: ../../rst/community/reporting_bugs_and_features.rst:37 -msgid "If you find a bug, open an issue using the `issue template `_." -msgstr "バグが見つかった場合は、`issue テンプレート `_ を使用して issue を作成します。" - -#: ../../rst/community/reporting_bugs_and_features.rst:39 -msgid "Fill out the issue template as completely and as accurately as possible. Include:" -msgstr "issue テンプレートをできるだけ完全かつ正確に記入します。以下を含めます。" - -#: ../../rst/community/reporting_bugs_and_features.rst:41 -msgid "your Ansible version" -msgstr "お使いの Ansible バージョン" - -#: ../../rst/community/reporting_bugs_and_features.rst:42 -msgid "the expected behavior and what you've tried, including the exact commands you were using or tasks you are running." -msgstr "予想される動作と試したこと (使用していた正確なコマンドや実行しているタスクを含む)" - -#: ../../rst/community/reporting_bugs_and_features.rst:43 -msgid "the current behavior and why you think it is a bug" -msgstr "現在の動作と、これがバグであると考える理由" - -#: ../../rst/community/reporting_bugs_and_features.rst:44 -msgid "the steps to reproduce the bug" -msgstr "バグを再現する手順" - -#: ../../rst/community/reporting_bugs_and_features.rst:45 -msgid "a minimal reproducible example and comments describing examples" -msgstr "最小限の再現可能な例と例について説明するコメント" - -#: ../../rst/community/reporting_bugs_and_features.rst:46 -msgid "any relevant configurations and the components you used" -msgstr "関連する設定と使用したコンポーネント" - -#: ../../rst/community/reporting_bugs_and_features.rst:47 -msgid "any relevant output plus ``ansible -vvvv`` (debugging) output" -msgstr "関連する出力と ``ansible -vvvv`` (デバッグ) の出力" - -#: ../../rst/community/reporting_bugs_and_features.rst:48 -msgid "add the output of ``ansible-test-env --show`` when filing bug reports involving ``ansible-test``." -msgstr "``ansible-test-env --show`` に関連するバグレポートを作成する際に、``ansible-test`` の出力を追加します。" - -#: ../../rst/community/reporting_bugs_and_features.rst:50 -msgid "When sharing YAML in playbooks, ensure that you preserve formatting using `code blocks `_. For multiple-file content, use gist.github.com, more durable than Pastebin content." -msgstr "Playbook で YAML を共有する際に、`code blocks `_ を使用して、フォーマットを保持するようにしてください。複数のファイルコンテンツの場合は、gist.github.com を使用します。これは pastebin コンテンツよりも永続性があります。" - -#: ../../rst/community/reporting_bugs_and_features.rst:55 -#: ../../rst/community/reporting_collections.rst:31 -msgid "Requesting a feature" -msgstr "機能要求" - -#: ../../rst/community/reporting_bugs_and_features.rst:57 -msgid "Before you request a feature, check what is :ref:`planned for future Ansible Releases `. Check `existing pull requests tagged with feature `_." -msgstr "機能を要求する前に、:ref:`今後の Ansible リリースの予定 ` を確認してください。`機能がタグ付けされている既存のプルリクエスト `_ を確認してください。" - -#: ../../rst/community/reporting_bugs_and_features.rst:59 -msgid "To get your feature into Ansible, :ref:`submit a pull request `, either against ansible-core or a collection. See also :ref:`ansible_collection_merge_requirements`. For ``ansible-core``, you can also open an issue in `ansible/ansible `_ or in a corresponding collection repository (To find the correct issue tracker, refer to :ref:`Bugs in collections` )." -msgstr "機能を Ansible に組み込むには、ansible-core またはコレクションに対して :ref:`プルリクエストを送信 ` します。:ref:`ansible_collection_merge_requirements` も参照してください。``ansible-core`` の場合は、`ansible/ansible `_ または対応するコレクションリポジトリーで issue を作成することもできます (正しい issue トラッカーを見つけるには、:ref:`コレクションのバグ` を参照してください)。" - -#: ../../rst/community/reporting_collections.rst:5 -msgid "Requesting changes to a collection" -msgstr "コレクションへの変更の要求" - -#: ../../rst/community/reporting_collections.rst:16 -msgid "Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com `_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response." -msgstr "Ansible は責任のある開示を実践しています。これがセキュリティー関連のバグである場合は、任意のパブリックグループにチケットを作成または投稿するのではなく、`security@ansible.com `_ にメールで報告してください。迅速に対応されます。" - -#: ../../rst/community/reporting_collections.rst:20 -msgid "Bugs in collections" -msgstr "コレクションのバグ" - -#: ../../rst/community/reporting_collections.rst:22 -msgid "Many bugs only affect a single module or plugin. If you find a bug that affects a module or plugin hosted in a collection, file the bug in the repository of the :ref:`collection `:" -msgstr "多くのバグは、単一のモジュールまたはプラグインにのみ影響します。コレクションでホストされるモジュールまたはプラグインに影響するバグを見つけた場合は、:ref:`コレクション ` のリポジトリーにバグを報告してください。" - -#: ../../rst/community/reporting_collections.rst:24 -msgid "Find the collection on `Galaxy `_." -msgstr "`Galaxy ` のコレクションを見つけます。" - -#: ../../rst/community/reporting_collections.rst:25 -msgid "Click on the Issue Tracker link for that collection." -msgstr "そのコレクションの Issue Tracker リンクをクリックします。" - -#: ../../rst/community/reporting_collections.rst:26 -msgid "Follow the contributor guidelines or instructions in the collection repo." -msgstr "貢献者向けガイドラインまたはコレクションリポジトリーの指示に従ってください。" - -#: ../../rst/community/reporting_collections.rst:28 -msgid "If you are not sure whether a bug is in ansible-core or in a collection, you can report the behavior on the :ref:`mailing list or community chat channel first `." -msgstr "バグが ansible-core またはコレクションのどちらにあるかわからない場合は、:ref:`mailing list or community chat channel first ` に動作を報告できます。" - -#: ../../rst/community/reporting_collections.rst:33 -msgid "Before you request a feature, check what is :ref:`planned for future Ansible Releases `. The best way to get a feature into an Ansible collection is to :ref:`submit a pull request `, either against ansible-core or against a collection. See also the :ref:`ansible_collection_merge_requirements`." -msgstr "機能をリクエストする前に、:ref:`planned for future Ansible Releases ` を確認してください。Ansible コレクションに機能を取り組むための最良の方法は、ansible-core またはコレクションのいずれかに対して :ref:`submit a pull request ` することです。:ref:`ansible_collection_merge_requirements` も参照してください。" - -#: ../../rst/community/reporting_collections.rst:36 -msgid "You can also submit a feature request by opening an issue in the collection repository." -msgstr "コレクションリポジトリーで issue を作成し、機能リクエストを送信することもできます。" - -#: ../../rst/community/steering/community_steering_committee.rst:5 -msgid "Steering Committee mission and responsibilities" -msgstr "Steering Committee のミッションおよび責任" - -#: ../../rst/community/steering/community_steering_committee.rst:7 -msgid "The Steering Committee mission is to provide continuity, guidance, and suggestions to the Ansible community to ensure the delivery and high quality of the Ansible package. In addition, the committee helps decide the technical direction of the Ansible project. It is responsible for approving new proposals and policies in the community, package, and community collections world, new community collection-inclusion requests, and other technical aspects regarding inclusion and packaging. The Committee should reflect the scope and breadth of the Ansible community." -msgstr "Steering Committee のミッションは、Ansible コミュニティーに継続性、ガイダンス、提案を提供し、Ansible パッケージの配信と高品質を確保することです。Committee は、Ansible プロジェクトの技術的な方向性の決定を支援し、コミュニティー、パッケージ、コミュニティーコレクションの世界における新しい提案やポリシー、新しいコミュニティーコレクションのインクルージョン要求、インクルージョンとパッケージ化に関する他の技術面の承認に責任を負っています。Committee は、Ansible コミュニティーの範囲と幅を反映する必要があります。" - -#: ../../rst/community/steering/community_steering_committee.rst:11 -msgid "Steering Committee responsibilities" -msgstr "Steering Committee の責任" - -#: ../../rst/community/steering/community_steering_committee.rst:13 -msgid "The Committee:" -msgstr "Committee:" - -#: ../../rst/community/steering/community_steering_committee.rst:15 -msgid "Designs policies and procedures for the community collections world." -msgstr "コミュニティーコレクションの世界のポリシーと手順を設計する。" - -#: ../../rst/community/steering/community_steering_committee.rst:16 -msgid "Votes on approval changes to established policies and procedures." -msgstr "確立されたポリシーと手順に対する承認変更への投票。" - -#: ../../rst/community/steering/community_steering_committee.rst:17 -msgid "Reviews community collections for compliance with the policies." -msgstr "ポリシーに準拠するためにコミュニティーコレクションを確認する。" - -#: ../../rst/community/steering/community_steering_committee.rst:18 -msgid "Helps create and define roadmaps for our deliverables such as the ``ansible`` package, major community collections, and documentation." -msgstr "``ansible`` パッケージ、主要なコミュニティーコレクション、ドキュメントなどの成果物のロードマップの作成と定義をサポートする。" - -#: ../../rst/community/steering/community_steering_committee.rst:19 -msgid "Reviews community collections submitted for inclusion in the Ansible package and decides whether to include them or not." -msgstr "Ansible パッケージのインクルージョン用に送信されたコミュニティーコレクションを確認し、それらを含めるかどうかを決定します。" - -#: ../../rst/community/steering/community_steering_committee.rst:20 -#: ../../rst/community/steering/steering_committee_membership.rst:21 -msgid "Review other proposals of importance that need the Committee's attention and provide feedback." -msgstr "Committee の注意が必要な重要なその他の提案を確認し、フィードバックを提供する。" - -#: ../../rst/community/steering/community_steering_committee.rst:25 -msgid "Current Steering Committee members" -msgstr "現在の Steering Committee メンバー" - -#: ../../rst/community/steering/community_steering_committee.rst:27 -msgid "The following table lists the current Steering Committee members. See :ref:`steering_past_members` for a list of past members." -msgstr "以下は、現在の Steering Committee メンバーの一覧を示した表です。過去のメンバーの一覧については、:ref:`steering_past_members` を参照してください。" - -#: ../../rst/community/steering/community_steering_committee.rst:31 -msgid "Current Steering committee members" -msgstr "現在の Steering Committee メンバー" - -#: ../../rst/community/steering/community_steering_committee.rst:34 -#: ../../rst/community/steering/steering_committee_past_members.rst:13 -#: ../../rst/community/steering/steering_committee_past_members.rst:28 -msgid "Name" -msgstr "名前" - -#: ../../rst/community/steering/community_steering_committee.rst:34 -#: ../../rst/community/steering/steering_committee_past_members.rst:13 -#: ../../rst/community/steering/steering_committee_past_members.rst:28 -msgid "GitHub" -msgstr "GitHub" - -#: ../../rst/community/steering/community_steering_committee.rst:34 -msgid "Start year" -msgstr "開始年" - -#: ../../rst/community/steering/community_steering_committee.rst:36 -msgid "Alexei Znamensky" -msgstr "Alexei Znamensky" - -#: ../../rst/community/steering/community_steering_committee.rst:36 -msgid "russoz" -msgstr "russoz" - -#: ../../rst/community/steering/community_steering_committee.rst:36 -#: ../../rst/community/steering/community_steering_committee.rst:44 -#: ../../rst/community/steering/community_steering_committee.rst:54 -#: ../../rst/community/steering/community_steering_committee.rst:56 -#: ../../rst/community/steering/community_steering_committee.rst:58 -msgid "2022" -msgstr "2022" - -#: ../../rst/community/steering/community_steering_committee.rst:38 -msgid "Alicia Cozine" -msgstr "Alicia Cozine" - -#: ../../rst/community/steering/community_steering_committee.rst:38 -msgid "acozine" -msgstr "acozine" - -#: ../../rst/community/steering/community_steering_committee.rst:38 -#: ../../rst/community/steering/community_steering_committee.rst:40 -#: ../../rst/community/steering/community_steering_committee.rst:42 -#: ../../rst/community/steering/community_steering_committee.rst:46 -#: ../../rst/community/steering/community_steering_committee.rst:48 -#: ../../rst/community/steering/community_steering_committee.rst:50 -#: ../../rst/community/steering/community_steering_committee.rst:52 -#: ../../rst/community/steering/community_steering_committee.rst:60 -#: ../../rst/community/steering/steering_committee_past_members.rst:19 -msgid "2021" -msgstr "2021" - -#: ../../rst/community/steering/community_steering_committee.rst:40 -msgid "Andrew Klychkov" -msgstr "Andrew Klychkov" - -#: ../../rst/community/steering/community_steering_committee.rst:40 -msgid "Andersson007" -msgstr "Andersson007" - -#: ../../rst/community/steering/community_steering_committee.rst:42 -msgid "Brad Thornton" -msgstr "Brad Thornton" - -#: ../../rst/community/steering/community_steering_committee.rst:42 -msgid "cidrblock" -msgstr "cidrblock" - -#: ../../rst/community/steering/community_steering_committee.rst:44 -msgid "Brian Scholer" -msgstr "Brian Scholer" - -#: ../../rst/community/steering/community_steering_committee.rst:44 -msgid "briantist" -msgstr "briantist" - -#: ../../rst/community/steering/community_steering_committee.rst:46 -msgid "Dylan Silva" -msgstr "Dylan Silva" - -#: ../../rst/community/steering/community_steering_committee.rst:46 -msgid "thaumos" -msgstr "thaumos" - -#: ../../rst/community/steering/community_steering_committee.rst:48 -msgid "Felix Fontein" -msgstr "Felix Fontein" - -#: ../../rst/community/steering/community_steering_committee.rst:48 -msgid "felixfontein" -msgstr "felixfontein" - -#: ../../rst/community/steering/community_steering_committee.rst:50 -msgid "James Cassell" -msgstr "James Cassell" - -#: ../../rst/community/steering/community_steering_committee.rst:50 -msgid "jamescassell" -msgstr "jamescassell" - -#: ../../rst/community/steering/community_steering_committee.rst:52 -msgid "John Barker" -msgstr "John Barker" - -#: ../../rst/community/steering/community_steering_committee.rst:52 -msgid "gundalow" -msgstr "gundalow" - -#: ../../rst/community/steering/community_steering_committee.rst:54 -msgid "Mario Lenz" -msgstr "Mario Lenz" - -#: ../../rst/community/steering/community_steering_committee.rst:54 -msgid "mariolenz" -msgstr "mariolenz" - -#: ../../rst/community/steering/community_steering_committee.rst:56 -msgid "Markus Bergholz" -msgstr "Markus Bergholz" - -#: ../../rst/community/steering/community_steering_committee.rst:56 -msgid "markuman" -msgstr "markuman" - -#: ../../rst/community/steering/community_steering_committee.rst:58 -msgid "Maxwell G" -msgstr "Maxwell G" - -#: ../../rst/community/steering/community_steering_committee.rst:58 -msgid "gotmax23" -msgstr "gotmax23" - -#: ../../rst/community/steering/community_steering_committee.rst:60 -msgid "Sorin Sbarnea" -msgstr "Sorin Sbarnea" - -#: ../../rst/community/steering/community_steering_committee.rst:60 -msgid "ssbarnea" -msgstr "ssbarnea" - -#: ../../rst/community/steering/community_steering_committee.rst:64 -msgid "John Barker (`gundalow `_) has been elected by the Committee as its :ref:`chairperson`." -msgstr "John Barker (`gundalow `_) は、Committee により :ref:`チェアパーソン` として選出されています。" - -#: ../../rst/community/steering/community_steering_committee.rst:66 -msgid "Committee members are selected based on their active contribution to the Ansible Project and its community. See :ref:`community_steering_guidelines` to learn details." -msgstr "Committee のメンバーは、Ansible プロジェクトとそのコミュニティーへのアクティブな貢献に基づいて選出されます。詳細は、:ref:`community_steering_guidelines` を参照してください。" - -#: ../../rst/community/steering/community_steering_committee.rst:69 -msgid "Creating new policy proposals & inclusion requests" -msgstr "新しいポリシーのプロポーザルとインクルージョンリクエストの作成" - -#: ../../rst/community/steering/community_steering_committee.rst:71 -msgid "The Committee uses the `community-topics repository `_ to asynchronously discuss with the Community and vote on Community topics in corresponding issues." -msgstr "Committee は `community-topics repository `_ を使用して、コミュニティーと非同期で議論し、対応する issue のコミュニティーのトピックについて投票します。" - -#: ../../rst/community/steering/community_steering_committee.rst:73 -msgid "You can create a new issue in the `community-topics repository `_ as a discussion topic if you want to discuss an idea that impacts any of the following:" -msgstr "以下のいずれかに影響を与えるアイデアについて話し合いたい場合は、ディスカッションのトピックとして、`community-topics repository `_ に新しい issue を作成することができます。" - -#: ../../rst/community/steering/community_steering_committee.rst:76 -msgid "Community collection best practices and requirements" -msgstr "コミュニティーコレクションのベストプラクティスおよび要件" - -#: ../../rst/community/steering/community_steering_committee.rst:77 -msgid "Community collection inclusion policy" -msgstr "コミュニティーコレクションのインクルージョンポリシー" - -#: ../../rst/community/steering/community_steering_committee.rst:78 -msgid "The Community governance" -msgstr "コミュニティーガバナンス" - -#: ../../rst/community/steering/community_steering_committee.rst:79 -msgid "Other proposals of importance that need the Committee's or overall Ansible community attention" -msgstr "Committee または Ansible コミュニティー全体の注意を必要とするその他の重要な提案" - -#: ../../rst/community/steering/community_steering_committee.rst:82 -msgid "To request changes to the inclusion policy and collection requirements:" -msgstr "インクルージョンポリシーおよびコレクション要件の変更をリクエストするには、以下を実行します。" - -#: ../../rst/community/steering/community_steering_committee.rst:84 -msgid "Submit a new pull request to the `ansible-collections/overview `_ repository." -msgstr "`ansible-collections/overview `_ リポジトリーに新しいプルリクエストを送信します。" - -#: ../../rst/community/steering/community_steering_committee.rst:86 -msgid "Create a corresponding issue containing the rationale behind these changes in the `community-topics repository `_ repository." -msgstr "これらの変更の背後にある理論的根拠を含む対応する issue を `community-topics repository `_ リポジトリーに作成します。" - -#: ../../rst/community/steering/community_steering_committee.rst:88 -msgid "To submit new collections for inclusion into the Ansible package:" -msgstr "Ansible パッケージのインクルージョン用の新しいコレクションを送信するには、以下を行います。" - -#: ../../rst/community/steering/community_steering_committee.rst:90 -msgid "Submit the new collection inclusion requests through a new discussion in the `ansible-inclusion `_ repository." -msgstr "`ansible-inclusion `_ リポジトリーの新しいディスカッションを通じて、新しいコレクションのインクルージョンリクエストを送信します。" - -#: ../../rst/community/steering/community_steering_committee.rst:92 -msgid "Depending on a topic you want to discuss with the Community and the Committee, as you prepare your proposal, please consider the requirements established by:" -msgstr "コミュニティーおよび Committee と話し合いたいトピックに応じて、提案を準備する際に、以下によって確立された要件を考慮してください。" - -#: ../../rst/community/steering/community_steering_committee.rst:94 -msgid ":ref:`code_of_conduct`." -msgstr ":ref:`code_of_conduct`。" - -#: ../../rst/community/steering/community_steering_committee.rst:95 -msgid "`Ansible Collection Requirements `_." -msgstr "`Ansible Collection Requirements `_。" - -#: ../../rst/community/steering/community_steering_committee.rst:96 -msgid "`Ansible Collection Inclusion Checklist `_." -msgstr "`Ansible Collection Inclusion Checklist `_。" - -#: ../../rst/community/steering/community_steering_committee.rst:99 -msgid "Community topics workflow" -msgstr "コミュニティーのトピックワークフロー" - -#: ../../rst/community/steering/community_steering_committee.rst:101 -msgid "The Committee uses the `Community-topics workflow `_ to asynchronously discuss and vote on the `community-topics `_." -msgstr "Committee は `Community-topics workflow `_ を使用して、`community-topics `_ について非同期的に議論し、投票します。" - -#: ../../rst/community/steering/community_steering_committee.rst:103 -msgid "The quorum, the minimum number of Committee members who must vote on a topic in order for a decision to be officially made, is half of the whole number of the Committee members. If the quorum number contains a fractional part, it is rounded up to the next whole number. For example, if there are thirteen members currently in the committee, the quorum will be seven." -msgstr "正式に決定を下すためにトピックに投票しなければならない Committee メンバーの最小数であるクォーラムは、Committee メンバーの総数の半分です。クォーラム番号に小数部分が含まれている場合は、次の整数に切り上げられます。たとえば、現在 Committee に 13 人のメンバーがいる場合、クォーラムは 7 人になります。" - -#: ../../rst/community/steering/community_steering_committee.rst:105 -msgid "Votes must always have \"no change\" as an option." -msgstr "投票には、オプションとして常に \"no change\" が必要です。" - -#: ../../rst/community/steering/community_steering_committee.rst:107 -msgid "In case of equal numbers of votes for and against a topic, the chairperson's vote will break the tie. For example, if there are six votes for and six votes against a topic, and the chairperson's vote is among those six which are for the topic, the final decision will be positive. If the chairperson has not voted yet, other members ask them to vote." -msgstr "トピックに対する賛成票と反対票が同数の場合は、チェアパーソンの票により同数ではなくなります。たとえば、トピックに賛成 6 票、反対 6 票があり、チェアパーソンの票が賛成 6 票の中にある場合は、最終決定は賛成となります。チェアパーソンがまだ投票していない場合は、他のメンバーが投票を依頼します。" - -#: ../../rst/community/steering/community_steering_committee.rst:109 -msgid "For votes with more than two options, one choice must have at least half of the votes. If two choices happen to both have half of the votes, the chairperson's vote will break the tie. If no choice has at least half of the votes, the vote choices have to be adjusted so that a majority can be found for a choice in a new vote." -msgstr "3 つ以上のオプションがある投票の場合、1 つの選択肢に少なくとも半分の票が必要です。2 つの選択肢の両方に半分の票がある場合、チェアパーソンの票により同数票ではなくなります。半分以上の票がある選択肢がない場合は、新しい投票で、1 つの選択肢が過半数となるように、投票の選択肢を調整する必要があります。" - -#: ../../rst/community/steering/community_steering_committee.rst:112 -msgid "Community topics triage" -msgstr "コミュニティートピックのトリアージ" - -#: ../../rst/community/steering/community_steering_committee.rst:114 -msgid "The Committee conducts a triage of `community topics `_ periodically (every three to six months)." -msgstr "委員会は定期的に `community topics `_ のトリアージ (3 年から 6 カ月まで) を実施します。" - -#: ../../rst/community/steering/community_steering_committee.rst:116 -msgid "The triage goals are:" -msgstr "トリアージの目標は次のとおりです。" - -#: ../../rst/community/steering/community_steering_committee.rst:118 -msgid "Sparking interest for forgotten topics." -msgstr "アクセスのないトピックに対する関心を集める" - -#: ../../rst/community/steering/community_steering_committee.rst:119 -msgid "Identifying and closing irrelevant topics, for example, when the reason of the topic does not exist anymore or the topic is out of the Committee responsibilities scope." -msgstr "トピックの存在意義がなくなった場合や、トピックの内容が委員会の責任範囲外となった場合など、関連のないトピックを特定して終了する" - -#: ../../rst/community/steering/community_steering_committee.rst:120 -msgid "Identifying and closing topics that the Community are not interested in discussing. As indicators, it can be absence of comments or no activity in comments, at least, for the last six months." -msgstr "コミュニティーが議論しないトピックを特定して終了する。過去 6ヶ月間コメントがない場合や、コメント内で活動がない場合などを目安とします。" - -#: ../../rst/community/steering/community_steering_committee.rst:121 -msgid "Identifying and closing topics that were solved and implemented but not closed (in this case, such a topic can be closed on the spot with a comment that it has been implemented)." -msgstr "解決済み、実装済みであるにも拘らず終了されていないトピックを特定して終了する (このような場合には、実装済みとコメントをつけて、トピックをその場で終了できるものとする)。" - -#: ../../rst/community/steering/community_steering_committee.rst:122 -msgid "Identifying topics that have been in pending state for a long time, for example, when it is waiting for actions from someone for several months or when the topics were solved but not implemented." -msgstr "数ヶ月間誰かのアクションを待っている場合や、トピックが解決されているが、実装されていない場合など、長期間、保留状態のトピックを特定する。" - -#: ../../rst/community/steering/community_steering_committee.rst:124 -msgid "A person starting the triage:" -msgstr "トリアージを開始した人:" - -#: ../../rst/community/steering/community_steering_committee.rst:126 -msgid "Identifies the topics mentioned above." -msgstr "上記のトピックを特定する。" - -#: ../../rst/community/steering/community_steering_committee.rst:127 -msgid "Creates a special triage topic containing an enumerated list of the topics-candidates for closing." -msgstr "クローズするトピック候補の列挙リストを含む、特別なトリアージトピックを作成する。" - -#: ../../rst/community/steering/community_steering_committee.rst:128 -msgid "Establishes a vote date considering a number of topics, their complexity and comment-history size giving the Community sufficient time to go through and discuss them." -msgstr "トピックの数、複雑さ、コメント履歴のサイズを考慮して投票日を設定し、コミュニティーが検討して議論するのに十分な時間を設定する。" - -#: ../../rst/community/steering/community_steering_committee.rst:129 -msgid "The Community and the Committee vote on each topic-candidate listed in the triage topic whether to close it or keep it open." -msgstr "コミュニティーおよび委員会がトリアージトピックに含まれるトピック候補ごとに、終了するか、オープンのままにするかの投票を行う。" - -#: ../../rst/community/steering/community_steering_committee.rst:132 -msgid "Collection inclusion requests workflow" -msgstr "コレクションのインクルージョンリクエストのワークフロー" - -#: ../../rst/community/steering/community_steering_committee.rst:134 -msgid "When reviewing community collection `inclusion requests `_, the Committee members check if a collection adheres to the `Community collection requirements `_." -msgstr "コミュニティーコレクションの `インクルージョンリクエスト `_ を確認する場合、Committee メンバーはコレクションが `コミュニティーのコレクション要件 `_ に準拠しているかどうかを確認します。" - -#: ../../rst/community/steering/community_steering_committee.rst:136 -msgid "A Committee member who conducts the inclusion review copies the `Ansible community collection checklist `_ into a corresponding `discussion `_." -msgstr "インクルージョンのレビューを実行する Committee メンバーは、`Ansible コミュニティーのコレクションチェックリスト `_ を対応する `ディスカッション `_ にコピーします。" - -#: ../../rst/community/steering/community_steering_committee.rst:138 -msgid "In the course of the review, the Committee member marks items as completed or leaves a comment saying whether the reviewer expects an issue to be addressed or whether it is optional (for example, it could be **MUST FIX:** or **SHOULD FIX:** under an item)." -msgstr "レビューの過程で、Committee のメンバーは項目に完了のマークを付けるか、レビュー担当者が issue の解決を期待しているかどうか、またはオプションであるかどうかをコメントで残します (たとえば、項目の下で **MUST FIX:** または **SHOULD FIX:** となります)。" - -#: ../../rst/community/steering/community_steering_committee.rst:140 -msgid "For a collection to be included in the Ansible community package, the collection:" -msgstr "Ansible コミュニティーパッケージに含めるコレクションには以下が適用されます。" - -#: ../../rst/community/steering/community_steering_committee.rst:142 -msgid "MUST be reviewed and approved by at least two persons, where at least one person is a Steering Committee member." -msgstr "2 人以上のユーザーがレビューして承認する必要があります。そのうちの少なくとも 1 人は Steering Committee メンバーです。" - -#: ../../rst/community/steering/community_steering_committee.rst:143 -msgid "For a Non-Steering Committee review to be counted for inclusion, it MUST be checked and approved by *another* Steering Committee member." -msgstr "Steering Committee 以外のレビューが含まれると認められるためには、*別の* Steering Committee メンバーによって確認および承認される必要があります。" - -#: ../../rst/community/steering/community_steering_committee.rst:144 -msgid "Reviewers must not be involved significantly in development of the collection. They must declare any potential conflict of interest (for example, being friends/relatives/coworkers of the maintainers/authors, being users of the collection, or having contributed to that collection recently or in the past)." -msgstr "レビュー担当者は、コレクションの開発に大きく関係してはいけません。レビュー担当者は、あらゆる潜在的な利害の対立を宣言する必要があります (たとえば、メンテナー/作成者の友人、親戚、同僚である場合、コレクションのユーザーである場合、最近または過去にそのコレクションに貢献したことがある場合など)。" - -#: ../../rst/community/steering/community_steering_committee.rst:146 -msgid "After the collection gets two or more Committee member approvals, a Committee member creates a `community topic `_ linked to the corresponding inclusion request. The issue's description says that the collection has been approved by two or more Committee members and establishes a date (a week by default) when the inclusion decision will be considered made. This time period can be used to raise concerns." -msgstr "コレクションが 2 人以上の Committee メンバーの承認を取得したら、1 人の Committee メンバーが、対応するインクルージョンリクエストにリンクされた `コミュニティートピック `_ を作成します。issue の説明には、コレクションが 2 人以上の Committee メンバーによって承認され、インクルージョンの決定が行われると見なされる日付 (デフォルトでは 1 週間) が設定されています。この期間は、懸念を提起するために使用できます。" - -#: ../../rst/community/steering/community_steering_committee.rst:148 -msgid "If no objections are raised up to the established date, the inclusion request is considered successfully resolved. In this case, a Committee member:" -msgstr "設定された日付まで異議が提起されなかった場合、インクルージョンリクエストは正常に解決されたと見なされます。この場合、Committee のメンバーは以下を行います。" - -#: ../../rst/community/steering/community_steering_committee.rst:150 -msgid "Declares the decision in the topic and in the inclusion request." -msgstr "トピックおよびインクルージョンリクエストで決定を宣言します。" - -#: ../../rst/community/steering/community_steering_committee.rst:151 -msgid "Moves the request to the ``Resolved reviews`` category." -msgstr "リクエストを ``Resolved reviews`` カテゴリーに移動します。" - -#: ../../rst/community/steering/community_steering_committee.rst:152 -msgid "Adds the collection to the ``ansible.in`` file in a corresponding directory of the `ansible-build-data repository `_." -msgstr "`ansible-build-data repository `_ の対応するディレクトリーの ``ansible.in`` ファイルにコレクションを追加します。" - -#: ../../rst/community/steering/community_steering_committee.rst:153 -msgid "Announces the inclusion through the `Bullhorn newsletter `_." -msgstr "`Bullhorn ニュースレター `_ からインクルージョンについて発表します。" - -#: ../../rst/community/steering/community_steering_committee.rst:154 -msgid "Closes the topic." -msgstr "トピックを終了します。" - -#: ../../rst/community/steering/community_steering_committee.rst:157 -msgid "Community Working Group meetings" -msgstr "コミュニティーワーキンググループのミーティング" - -#: ../../rst/community/steering/community_steering_committee.rst:159 -msgid "See the Community Working Group meeting `schedule `_. Meeting summaries are posted in the `Community Working Group Meeting Agenda `_ issue." -msgstr "コミュニティーワーキンググループのミーティングの `スケジュール `_.を確認してください。ミーティングのサマリーは、`コミュニティーのワーキンググループのミーティングアジェンダ `_ issue に投稿されます。" - -#: ../../rst/community/steering/community_steering_committee.rst:163 -msgid "Participation in the Community Working Group meetings is optional for Committee members. Decisions on community topics are made asynchronously in the `community-topics `_ repository." -msgstr "Committee メンバーが、コミュニティーワーキンググループのミーティングに参加することは任意となっています。コミュニティーのトピックに関する決定は、`community-topics `_ リポジトリーで非同期的に行われます。" - -#: ../../rst/community/steering/community_steering_committee.rst:165 -msgid "The meeting minutes can be found at the `fedora meetbot site `_ and the same is posted to `Ansible Devel Mailing List `_ after every meeting." -msgstr "ミーティングの議事録は、`fedora meetbot サイト `_ で確認できます。また、この議事録は、ミーティング終了後は毎回 `Ansible Devel メーリングリスト `_ に投稿されています。" - -#: ../../rst/community/steering/steering_committee_membership.rst:4 -msgid "Steering Committee membership guidelines" -msgstr "Steering Committee メンバーシップのガイドライン" - -#: ../../rst/community/steering/steering_committee_membership.rst:6 -msgid "This document describes the expectations and policies related to membership in the :ref:`Ansible Community Steering Committee ` (hereinafter the Committee)." -msgstr "このドキュメントでは、:ref:`Ansible Community Steering Committee ` (以下、Committee) のメンバーシップに関連する期待およびポリシーについて説明しています。" - -#: ../../rst/community/steering/steering_committee_membership.rst:8 -msgid "Topics:" -msgstr "トピック:" - -#: ../../rst/community/steering/steering_committee_membership.rst:13 -msgid "Expectations of a Steering Committee member" -msgstr "Steering Committee メンバーへの期待" - -#: ../../rst/community/steering/steering_committee_membership.rst:16 -msgid "As a Committee member, you agree to:" -msgstr "Committee メンバーとして、以下に同意するものとします。" - -#: ../../rst/community/steering/steering_committee_membership.rst:18 -msgid "Abide by the :ref:`code_of_conduct` in all your interactions with the Community." -msgstr "コミュニティーとのやりとりのすべてにおいて :ref:`code_of_conduct` を遵守する。" - -#: ../../rst/community/steering/steering_committee_membership.rst:19 -msgid "Be a Community ambassador by representing its needs within the Committee and throughout the decision making process." -msgstr "Committee 内および意思決定プロセス全体を通じて、コミュニティーのニーズを代表することにより、コミュニティーアンバサダーになる。" - -#: ../../rst/community/steering/steering_committee_membership.rst:20 -msgid "Asynchronously participate in discussions and voting on the `Community Topics `_." -msgstr "`コミュニティートピック `_ に関する議論と投票に非同期的に参加する。" - -#: ../../rst/community/steering/steering_committee_membership.rst:22 -msgid "Act for the sake of the Community by not promoting corporate or individual agenda during the decision making process." -msgstr "意思決定プロセスにおいて、企業や個人のアジェンダを推し進めることなく、コミュニティーのために行動する。" - -#: ../../rst/community/steering/steering_committee_membership.rst:23 -msgid "Engage with the Community in a professional and positive manner, encourage community members to express their opinion." -msgstr "プロフェッショナルかつポジティブな態度でコミュニティーと関わり、コミュニティーメンバーが意見を表明するように奨励する" - -#: ../../rst/community/steering/steering_committee_membership.rst:28 -msgid "Joining the Steering Committee" -msgstr "Steering Committee への参加" - -#: ../../rst/community/steering/steering_committee_membership.rst:31 -msgid "Eligibility" -msgstr "参加資格" - -#: ../../rst/community/steering/steering_committee_membership.rst:33 -msgid "A person is eligible to become a Committee member if they have:" -msgstr "以下に該当する場合は、Committee メンバーになる資格があります。" - -#: ../../rst/community/steering/steering_committee_membership.rst:35 -msgid "A wide knowledge of Ansible and/or its related projects." -msgstr "Ansible や関連プロジェクトの幅広い知識がある。" - -#: ../../rst/community/steering/steering_committee_membership.rst:36 -msgid "Active contributions to Ansible and/or related projects in any form described in the :ref:`collections_contributions`." -msgstr ":ref:`collections_contributions` で説明されている任意の形式での、Ansible や関連プロジェクトへのアクティブな貢献。" - -#: ../../rst/community/steering/steering_committee_membership.rst:37 -msgid "A consent to follow the :ref:`steering_expectations`." -msgstr ":ref:`steering_expectations` に従うことに同意する。" - -#: ../../rst/community/steering/steering_committee_membership.rst:40 -msgid "Process" -msgstr "Process" - -#: ../../rst/community/steering/steering_committee_membership.rst:42 -msgid "The process to join the Steering Committee consists of the following steps:" -msgstr "Steering Committee に参加するプロセスは、以下の手順で構成されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:44 -msgid "Any community member may nominate someone or themselves for Committee membership by contacting one of the :ref:`current Committee members `) or by sending an email to ``ansible-community@redhat.com``." -msgstr "すべてのコミュニティーメンバーは、:ref:`現在の Committee メンバー ` のいずれかに連絡するか、メールを ``ansible-community@redhat.com`` に送信することで、Committee メンバーシップに誰か、または自分自身を推薦することができます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:45 -msgid "A Committee member who receives the nomination must inform the Committee about it by forwarding the full message." -msgstr "推薦を受け取った Committee メンバーは、メッセージ全体を転送し、推薦について Committee に通知する必要があります。" - -#: ../../rst/community/steering/steering_committee_membership.rst:46 -msgid "The vote is conducted by email. Nominees must receive a majority of votes from the present Committee members to be added to the Committee." -msgstr "投票はメールで行われます。候補者が Committee に参加するには、現在の Committee メンバーの過半数の票を得る必要があります。" - -#: ../../rst/community/steering/steering_committee_membership.rst:47 -msgid "Provided that the vote result is positive, it is announced via the `Bullhorn `_ newsletter and the new member is added to the :ref:`Committee member list `." -msgstr "投票結果が肯定的である場合、`Bullhorn `_ ニュースレターで発表され、新しいメンバーは :ref:`Committee メンバーリスト ` に追加されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:50 -msgid "Leaving the Steering Committee" -msgstr "Steering Committee を退会する" - -#: ../../rst/community/steering/steering_committee_membership.rst:52 -msgid "Steering Committee members can resign voluntarily or be removed by the rest of the Steering Committee under certain circumstances. See the details below." -msgstr "Steering Committee メンバーは、自発的に辞任するか、特定の状況下で他のメンバーによって解任されることがあります。詳細は以下をご覧ください。" - -#: ../../rst/community/steering/steering_committee_membership.rst:59 -msgid "Voluntarily leaving the Steering Committee" -msgstr "自発的に Steering Committee を辞任する" - -#: ../../rst/community/steering/steering_committee_membership.rst:61 -msgid "A Committee member can voluntarily leave the Committee. In this case, they notify the other members, create an issue in the `Community Topics `_ repository announcing the resignation, and after that they are no longer considered Committee members." -msgstr "Committee メンバーは、自発的に Committee を辞任することができます。この場合、他のメンバーに通知し、辞任を知らせる issue を `Community トピック `_ リポジトリーに作成します。これにより、Committee のメンバーとは見なされなくなります。" - -#: ../../rst/community/steering/steering_committee_membership.rst:64 -msgid "Committee members who resign and later change their mind can rejoin the Committee by following the :ref:`Process for joining the Steering Committee`." -msgstr "Committee メンバーを辞任した後に心変わりした場合は、:ref:`Steering Committee に参加するためのプロセス` に従って Committee に再度参加することができます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:68 -msgid "Involuntarily leaving the Steering Committee" -msgstr "Steering Committee からの解任" - -#: ../../rst/community/steering/steering_committee_membership.rst:70 -msgid "A Committee member will be removed from the Committee if they:" -msgstr "以下の場合、Committee メンバーは解任されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:72 -msgid "Do not participate in asynchronous discussions and voting on the `Community Topics `_ for more than 3 months in a row." -msgstr "`コミュニティートピック `_ に関する非同期による議論および投票に連続して3 カ月以上参加していない。" - -#: ../../rst/community/steering/steering_committee_membership.rst:73 -msgid "Participate unreasonably irregularly (for example, once a month for several months). Unreasonably is defined by other Committee members considering circumstances in each particular case." -msgstr "不当に不規則な参加 (例: 数カ月間にわたって 1 カ月に 1 回)。不当にとは、他の Committee メンバーが個々の事情を考慮して定義します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:74 -msgid "Violate the :ref:`code_of_conduct`." -msgstr ":ref:`code_of_conduct` に違反している。" - -#: ../../rst/community/steering/steering_committee_membership.rst:79 -msgid "Absence or irregular participation in discussing topics and votes" -msgstr "トピックや投票の議論への不参加または不規則な参加" - -#: ../../rst/community/steering/steering_committee_membership.rst:81 -msgid "In case of absence or irregular participation, the involuntarily removal process consists of the following steps:" -msgstr "不参加または不規則な参加の場合、非自発的な削除プロセスが次の手順で実施されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:83 -msgid "Another Committee member (hereinafter the initiator) contacts the person by email asking if they are still interested in fulfilling their Committee member's duties." -msgstr "別の Committee メンバー (以下、イニシエーター) は、該当者にメールで連絡し、Committee メンバーの職務を遂行することにまだ関心があるかどうかを尋ねます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:84 -msgid "If they respond that they are not interested, the initiator asks the person to step down on their own following the :ref:`Voluntarily leaving process`." -msgstr "関心がないと答えた場合、イニシエーターは該当者に対して、:ref:`自発的辞任プロセス` に則って辞任するように依頼します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:85 -msgid "If there has been no response or stepping down issue created by the person within a reasonable time, the initiator notifies other Committee members about the situation." -msgstr "合理的な時間内に返答がなかったり、issue の作成者からの取り下げがない場合は、イニシエーターは Committee の他のメンバーにこの状況について通知します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:86 -msgid "In case of agreement among the Committee about the need for removal, the initiator provides a draft of a corresponding topic's description to the Committee via email for discussion and approval." -msgstr "削除の必要性について Committee 間で合意した場合、イニシエーターは、議論と承認のために、対応するトピックの説明のドラフトをメールで Committee に提供します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:88 -msgid "The topic's title is ``Steering Committee member audit.``. It must not contain the person's name or other identifying information." -msgstr "トピックのタイトルは ``Steering Committee メンバーの監査`` です。これには、個人の名前やその他の個人を特定する情報を含めることはできません。" - -#: ../../rst/community/steering/steering_committee_membership.rst:90 -msgid "The description must not contain or imply any forms of condemnation." -msgstr "説明文には、いかなる形の非難も含まれてはならず、また、示唆するものであってはなりません。" - -#: ../../rst/community/steering/steering_committee_membership.rst:92 -msgid "It must mention that the person has been inactive for an unknown reason for the last N months and that, in accordance with the Steering Committee policies, their place should be freed for another person who can continue their great job." -msgstr "説明文では、該当者が過去 N か月間、明確な理由なしに活動を停止しているため、Steering Committee の方針に従って、該当者のポジションをすばらしい仕事を続けることができる別の人のために解放されるべきである点に言及しなければなりません。" - -#: ../../rst/community/steering/steering_committee_membership.rst:94 -msgid "The description must mention person's achievements and thanks for their time and effort they spent serving for the Community, Committee, and the Project, and a hope that one day they will come back." -msgstr "この説明文には、該当者の業績のほか、コミュニティー、Committee、およびプロジェクトのために費やした時間と尽力への感謝、そしていつか戻ってくることを願う内容を記載する必要があります。" - -#: ../../rst/community/steering/steering_committee_membership.rst:96 -msgid "The initiator creates the topic in the `Community Topics `_ repository containing the description and the title from the draft." -msgstr "イニシエーターは、ドラフトからの説明とタイトルを含む `コミュニティートピック `_ リポジトリーにトピックを作成します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:97 -msgid "The Committee members vote on the topic." -msgstr "Committee メンバーがトピックに投票します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:100 -msgid "Ansible Community Code of Conduct violations" -msgstr "Ansible のコミュニティー行動規範違反" - -#: ../../rst/community/steering/steering_committee_membership.rst:102 -msgid "In case of the `Ansible Community Code of Conduct `_ violations, the process is the same as above except steps 1-2. Instead:" -msgstr "`Ansible コミュニティーの行動規範 `_ 違反の場合のプロセスは、手順 1-2 を除き、上記と同じになります。" - -#: ../../rst/community/steering/steering_committee_membership.rst:104 -msgid "The initiator reports the case to the Committee via email." -msgstr "イニシエーターは、メールでケースを Committee に報告します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:106 -msgid "The Committee discusses the case internally, evaluates its severity, and possible solutions." -msgstr "Committee は、ケースについて内部で話し合い、重大度と考えられる解決策を評価します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:108 -msgid "If the Committee concludes that the violation is not severe, it develops a proposal to the person on how the situation can be corrected and further interactions with the Community improved." -msgstr "違反が重大でないと判断された場合、Committee は、状況を修正し、コミュニティーとのさらなる相互作用を改善する方法に関するプロポーザルを該当者に対して作成します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:110 -msgid "A Committee representative reaches out to the person with the proposal." -msgstr "Committee の代表者は、該当者に連絡し、プロポーザルを提供します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:112 -msgid "The removal process starts if:" -msgstr "以下の場合は、削除プロセスが開始されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:114 -msgid "The Committee decided that the severity of the violation excludes a possibility of further membership." -msgstr "重大な違反であるため、Committee が、今後のメンバーシップの可能性を排除すると判断した場合。" - -#: ../../rst/community/steering/steering_committee_membership.rst:116 -msgid "The person does not respond to the proposal." -msgstr "該当者がプロポーザルに返答しない場合。" - -#: ../../rst/community/steering/steering_committee_membership.rst:118 -msgid "The person explicitly rejects the proposal." -msgstr "該当者がプロポーザルを明示的に拒否した場合。" - -#: ../../rst/community/steering/steering_committee_membership.rst:120 -msgid "In case of starting the removal process, the topic's description in the reason's part changes correspondingly." -msgstr "削除プロセスを開始する場合、理由の部分のトピックの説明はそれに応じて変更されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:125 -msgid "Chairperson" -msgstr "チェアパーソン" - -#: ../../rst/community/steering/steering_committee_membership.rst:127 -msgid "The chairperson election will happen once a year around the time of Ansible Fest. If the current chairperson has to step down early, the election happens immediately." -msgstr "チェアパーソンの選出は、Ansible Fest の時期に年に 1 回行われます。現在のチェアパーソンが早期に辞任しなければならない場合は、ただちに選出されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:130 -msgid "The process of the election consist of the following steps:" -msgstr "選出のプロセスは、以下の手順で構成されます。" - -#: ../../rst/community/steering/steering_committee_membership.rst:132 -msgid "Members interested in being the chairperson will inform a person responsible for arranging the election about that." -msgstr "チェアパーソンへの就任に関心のあるメンバーは、選出準備の責任者にその旨を通知します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:134 -msgid "Conduct anonymous voting somewhere." -msgstr "いずれかの場所で、匿名による投票を行います。" - -#: ../../rst/community/steering/steering_committee_membership.rst:135 -msgid "Internally and publicly announce the elected candidate." -msgstr "選出された候補者を内外に発表します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:137 -msgid "The chairperson has the following powers unlike regular members:" -msgstr "チェアパーソンは、通常のメンバーとは異なり、以下の権限を有します。" - -#: ../../rst/community/steering/steering_committee_membership.rst:139 -msgid "The chairperson's vote breaks ties to resolve deadlocks when equal numbers of steering committee members vote for and against a `community topic `_." -msgstr "`コミュニティートピック `_ に対して、Steering Committee の賛否が同数の場合、チェアパーソンがどちらかに票を投じることで、デッドロックが解消されます。" - -#: ../../rst/community/steering/steering_committee_past_members.rst:4 -#: ../../rst/community/steering/steering_committee_past_members.rst:10 -msgid "Steering Committee past members" -msgstr "Steering Committee の過去のメンバー" - -#: ../../rst/community/steering/steering_committee_past_members.rst:6 -msgid "The Ansible Community is very grateful to these amazing **nonreplaceable** people for their great service to the Community and the project!" -msgstr "Ansible コミュニティーは、コミュニティーおよびプロジェクトに対して優れたサービスを提供してくださった、これらのすばらしい **かけがえのない** 人々に非常に感謝しています!" - -#: ../../rst/community/steering/steering_committee_past_members.rst:13 -#: ../../rst/community/steering/steering_committee_past_members.rst:28 -msgid "Years of service" -msgstr "貢献年数" - -#: ../../rst/community/steering/steering_committee_past_members.rst:15 -msgid "Jill Rouleau" -msgstr "Jill Rouleau" - -#: ../../rst/community/steering/steering_committee_past_members.rst:15 -msgid "jillr" -msgstr "jillr" - -#: ../../rst/community/steering/steering_committee_past_members.rst:15 -#: ../../rst/community/steering/steering_committee_past_members.rst:17 -#: ../../rst/community/steering/steering_committee_past_members.rst:30 -msgid "2021-2022" -msgstr "2021-2022" - -#: ../../rst/community/steering/steering_committee_past_members.rst:17 -#: ../../rst/community/steering/steering_committee_past_members.rst:30 -msgid "Tadej Borovšak" -msgstr "Tadej Borovšak" - -#: ../../rst/community/steering/steering_committee_past_members.rst:17 -#: ../../rst/community/steering/steering_committee_past_members.rst:30 -msgid "tadeboro" -msgstr "tadeboro" - -#: ../../rst/community/steering/steering_committee_past_members.rst:19 -msgid "Toshio Kuratomi" -msgstr "Toshio Kuratomi" - -#: ../../rst/community/steering/steering_committee_past_members.rst:19 -msgid "abadger" -msgstr "abadger" - -#: ../../rst/community/steering/steering_committee_past_members.rst:23 -msgid "We'd also like to thank our past chairpersons for their contributions to Ansible." -msgstr "また、Ansible に貢献してくださった過去のチェアパーソンにも感謝の意を表します。" - -#: ../../rst/community/steering/steering_committee_past_members.rst:25 -msgid "Steering Committee past chairpersons" -msgstr "Steering Committee の過去のチェアパーソン" - -#: ../../rst/community/steering/steering_index.rst:5 -msgid "Ansible Community Steering Committee" -msgstr "Ansible コミュニティーの Steering Committee" - -#: ../../rst/community/steering/steering_index.rst:7 -msgid "This section focuses on the guidelines and membership of the Ansible Community Steering Committee." -msgstr "本セクションでは、Ansible コミュニティーの Steering Committee のガイドラインおよびメンバーシップに焦点を当てています。" - -#~ msgid "These are the guidelines for people with commit privileges on the Ansible GitHub repository. Committers are essentially acting as members of the Ansible Core team, although not necessarily as employees of Ansible and Red Hat. Please read the guidelines before you commit." -#~ msgstr "このページは、Ansible GitHub リポジトリー上でコミット権限を持つユーザーのためのガイドラインです。コミット担当者は、基本的に Ansible Core チームのメンバーとして活動していますが、Ansible および Red Hat の従業員であるとは限りません。コミットする前にこのガイドラインをお読みください。" - -#~ msgid "Don't" -#~ msgstr "してはいけないこと" - -#~ msgid "Drag your community team members down. Always discuss the technical merits, but you should never address the person's limitations (you can later go for beers and call them idiots, but not in IRC/GitHub/and so on)." -#~ msgstr "コミュニティーチームのメンバーの足を引っ張る。技術的なメリットについては常に議論するべきですが、一個人の限界については決して言及すべきではありません (IRC、GitHub などでは特に注意してください)。" - -#~ msgid "Forget about the maintenance burden. Some things are really cool to have, but they might not be worth shoehorning in if the maintenance burden is too great." -#~ msgstr "メンテナンスの負担を考えない。その機能が本当に優れていても、メンテナンスの負担が大きすぎる場合は、組み込む価値がないかもしれません。" - -#~ msgid "People" -#~ msgstr "ユーザー" - -#~ msgid "Individuals who've been asked to become a part of this group have generally been contributing in significant ways to the Ansible community for some time. Should they agree, they are requested to add their names and GitHub IDs to this file, in the section below, through a pull request. Doing so indicates that these individuals agree to act in the ways that their fellow committers trust that they will act." -#~ msgstr "このグループの一員になることを尋ねられるユーザーは、通常、しばらくの間 Ansible コミュニティーに重要な貢献をしてきたユーザーです。同意したユーザーは、以下のセクションにあるこのファイルに名前と GitHub ID をプル要求で追加してください。この操作は、その他のコミット担当者に信頼してもらえる行動をとることに同意していることを示します。" - -#~ msgid "GitHub ID" -#~ msgstr "GitHub ID" - -#~ msgid "IRC Nick" -#~ msgstr "IRC ニック" - -#~ msgid "Other" -#~ msgstr "その他" - -#~ msgid "James Cammarata" -#~ msgstr "James Cammarata" - -#~ msgid "jimi-c" -#~ msgstr "jimi-c" - -#~ msgid "jimi" -#~ msgstr "jimi" - -#~ msgid "Brian Coca" -#~ msgstr "Brian Coca" - -#~ msgid "bcoca" -#~ msgstr "bcoca" - -#~ msgid "Matt Davis" -#~ msgstr "Matt Davis" - -#~ msgid "nitzmahone" -#~ msgstr "nitzmahone" - -#~ msgid "abadger1999" -#~ msgstr "abadger1999" - -#~ msgid "Jason McKerr" -#~ msgstr "Jason McKerr" - -#~ msgid "mckerrj" -#~ msgstr "mckerrj" - -#~ msgid "newtMcKerr" -#~ msgstr "newtMcKerr" - -#~ msgid "Robyn Bergeron" -#~ msgstr "Robyn Bergeron" - -#~ msgid "robynbergeron" -#~ msgstr "robynbergeron" - -#~ msgid "rbergeron" -#~ msgstr "rbergeron" - -#~ msgid "Greg DeKoenigsberg" -#~ msgstr "Greg DeKoenigsberg" - -#~ msgid "gregdek" -#~ msgstr "gregdek" - -#~ msgid "Monty Taylor" -#~ msgstr "Monty Taylor" - -#~ msgid "emonty" -#~ msgstr "emonty" - -#~ msgid "mordred" -#~ msgstr "mordred" - -#~ msgid "Matt Martz" -#~ msgstr "Matt Martz" - -#~ msgid "sivel" -#~ msgstr "sivel" - -#~ msgid "Nate Case" -#~ msgstr "Nate Case" - -#~ msgid "qalthos" -#~ msgstr "qalthos" - -#~ msgid "Qalthos" -#~ msgstr "Qalthos" - -#~ msgid "James Tanner" -#~ msgstr "James Tanner" - -#~ msgid "jctanner" -#~ msgstr "jctanner" - -#~ msgid "jtanner" -#~ msgstr "jtanner" - -#~ msgid "Peter Sprygada" -#~ msgstr "Peter Sprygada" - -#~ msgid "privateip" -#~ msgstr "privateip" - -#~ msgid "Abhijit Menon-Sen" -#~ msgstr "Abhijit Menon-Sen" - -#~ msgid "amenonsen" -#~ msgstr "amenonsen" - -#~ msgid "crab" -#~ msgstr "crab" - -#~ msgid "Michael Scherer" -#~ msgstr "Michael Scherer" - -#~ msgid "mscherer" -#~ msgstr "mscherer" - -#~ msgid "misc" -#~ msgstr "misc" - -#~ msgid "René Moser" -#~ msgstr "René Moser" - -#~ msgid "resmo" -#~ msgstr "resmo" - -#~ msgid "David Shrewsbury" -#~ msgstr "David Shrewsbury" - -#~ msgid "Shrews" -#~ msgstr "Shrews" - -#~ msgid "Sandra Wills" -#~ msgstr "Sandra Wills" - -#~ msgid "docschick" -#~ msgstr "docschick" - -#~ msgid "Graham Mainwaring" -#~ msgstr "Graham Mainwaring" - -#~ msgid "ghjm" -#~ msgstr "ghjm" - -#~ msgid "Chris Houseknecht" -#~ msgstr "Chris Houseknecht" - -#~ msgid "chouseknecht" -#~ msgstr "chouseknecht" - -#~ msgid "Trond Hindenes" -#~ msgstr "Trond Hindenes" - -#~ msgid "trondhindenes" -#~ msgstr "trondhindenes" - -#~ msgid "Jon Hawkesworth" -#~ msgstr "Jon Hawkesworth" - -#~ msgid "jhawkesworth" -#~ msgstr "jhawkesworth" - -#~ msgid "Will Thames" -#~ msgstr "Will Thames" - -#~ msgid "willthames" -#~ msgstr "willthames" - -#~ msgid "Adrian Likins" -#~ msgstr "Adrian Likins" - -#~ msgid "alikins" -#~ msgstr "alikins" - -#~ msgid "Dag Wieers" -#~ msgstr "Dag Wieers" - -#~ msgid "dagwieers" -#~ msgstr "dagwieers" - -#~ msgid "dag@wieers.com" -#~ msgstr "dag@wieers.com" - -#~ msgid "Tim Rupp" -#~ msgstr "Tim Rupp" - -#~ msgid "caphrim007" -#~ msgstr "caphrim007" - -#~ msgid "Sloane Hertel" -#~ msgstr "Sloane Hertel" - -#~ msgid "s-hertel" -#~ msgstr "s-hertel" - -#~ msgid "shertel" -#~ msgstr "shertel" - -#~ msgid "Sam Doran" -#~ msgstr "Sam Doran" - -#~ msgid "samdoran" -#~ msgstr "samdoran" - -#~ msgid "Matt Clay" -#~ msgstr "Matt Clay" - -#~ msgid "mattclay" -#~ msgstr "mattclay" - -#~ msgid "Martin Krizek" -#~ msgstr "Martin Krizek" - -#~ msgid "mkrizek" -#~ msgstr "mkrizek" - -#~ msgid "Ganesh Nalawade" -#~ msgstr "Ganesh Nalawade" - -#~ msgid "ganeshrn" -#~ msgstr "ganeshrn" - -#~ msgid "Trishna Guha" -#~ msgstr "Trishna Guha" - -#~ msgid "trishnaguha" -#~ msgstr "trishnaguha" - -#~ msgid "trishnag" -#~ msgstr "trishnag" - -#~ msgid "Andrew Gaffney" -#~ msgstr "Andrew Gaffney" - -#~ msgid "agaffney" -#~ msgstr "agaffney" - -#~ msgid "Jordan Borean" -#~ msgstr "Jordan Borean" - -#~ msgid "jborean93" -#~ msgstr "jborean93" - -#~ msgid "Abhijeet Kasurde" -#~ msgstr "Abhijeet Kasurde" - -#~ msgid "Akasurde" -#~ msgstr "Akasurde" - -#~ msgid "akasurde" -#~ msgstr "akasurde" - -#~ msgid "Adam Miller" -#~ msgstr "Adam Miller" - -#~ msgid "maxamillion" -#~ msgstr "maxamillion" - -#~ msgid "Sviatoslav Sydorenko" -#~ msgstr "Sviatoslav Sydorenko" - -#~ msgid "webknjaz" -#~ msgstr "webknjaz" - -#~ msgid "Sandra McCann" -#~ msgstr "Sandra McCann" - -#~ msgid "samccann" -#~ msgstr "samccann" - -#~ msgid "felix@fontein.de" -#~ msgstr "felix@fontein.de" - -#~ msgid "Mailing list information" -#~ msgstr "メーリングリストの情報" - -#~ msgid "`Ansible Container List `_ is for users and developers of the Ansible Container project." -#~ msgstr "`Ansible Container List `_ は、Ansible Container プロジェクトのユーザーおよび開発者向けです。" - -#~ msgid "IRC channels" -#~ msgstr "IRC チャネル" - -#~ msgid "Ansible has several IRC channels on `Freenode `_." -#~ msgstr "Ansible には、`Freenode `_ に複数の IRC チャンネルがあります。" - -#~ msgid "Our IRC channels may require you to register your nickname. If you receive an error when you connect, see `Freenode's Nickname Registration guide `_ for instructions." -#~ msgstr "この IRC チャネルでは、ニックネームの登録が必要になる場合があります。接続時にエラーが発生する場合は、「`Freenode's Nickname Registration guide `_」を参照してください。" - -#~ msgid "To find all ``ansible`` specific channels on a freenode network, use the following command in your IRC client::" -#~ msgstr "freenode ネットワークですべての ``ansible`` 固有のチャンネルを見つけるには、IRC クライアントで以下のコマンドを使用します。" - -#~ msgid "``#ansible`` - For general use questions and support." -#~ msgstr "``#ansible`` - 一般的な使い方の質問やサポートに使用。" - -#~ msgid "``#ansible-devel`` - For discussions on developer topics and code related to features or bugs." -#~ msgstr "``#ansible-devel`` - 開発者のトピックや機能やバグに関連するコードについて議論する場。" - -#~ msgid "`Ansible Lockdown Working Group `_ | `gh/ansible/ansible-lockdown `_ - ``#ansible-lockdown``- Security playbooks/roles" -#~ msgstr "`Ansible Lockdown Working Group `_ | `gh/ansible/ansible-lockdown `_ - ``#ansible-lockdown``- セキュリティー Playbook およびロール" - -#~ msgid "`AWX Working Group `_ - ``#ansible-awx`` - Upstream for Ansible Tower" -#~ msgstr "`AWX Working Group `_ - ``#ansible-awx`` - Ansible Tower のアップストリーム" - -#~ msgid "`Contributor Experience Working Group `_ - ``#ansible-community``" -#~ msgstr "`Contributor Experience Working Group `_ - ``#ansible-community``" - -#~ msgid "`Lightbulb Training `_ - ``#ansible-lightbulb`` - Ansible training" -#~ msgstr "`Lightbulb Training `_ - ``#ansible-lightbulb`` - Ansible トレーニング" - -#~ msgid "`Molecule Working Group `_ | `molecule.io `_ - ``#ansible-molecule`` - testing platform for Ansible playbooks and roles" -#~ msgstr "`Molecule Working Group `_ | `molecule.io `_ - ``#ansible-molecule`` - Ansible Playbook およびロール用テストプラットフォーム" - -#~ msgid "``#ansible-es`` - Channel for Spanish speaking Ansible community." -#~ msgstr "``#ansible-es`` - スペイン語の Ansible コミュニティー向けチャンネル。" - -#~ msgid "``#ansible-eu`` - Channel for the European Ansible Community." -#~ msgstr "``#ansible-eu`` - ヨーロッパの Ansible コミュニティー向けのチャンネル。" - -#~ msgid "``#ansible-fr`` - Channel for French speaking Ansible community." -#~ msgstr "``#ansible-fr`` - フランス語の Ansible コミュニティー向けのチャンネル。" - -#~ msgid "``#ansiblezh`` - Channel for Zurich/Swiss Ansible community." -#~ msgstr "``#ansiblezh`` - チューリッヒ/スイスの Ansible コミュニティー向けのチャンネル。" - -#~ msgid "IRC meetings" -#~ msgstr "IRC ミーティング" - -#~ msgid "Red Hat Ansible `Tower `_ is a UI, Server, and REST endpoint for Ansible. The Red Hat Ansible Automation subscription contains support for Ansible, Ansible Tower, Ansible Automation for Networking, and more." -#~ msgstr "Red Hat Ansible `Tower `_ は、Ansible の UI、サーバー、および REST エンドポイントです。Red Hat Ansible Automation サブスクリプションには、Ansible、Ansible Tower、Ansible Automation for Networking などのサポートが含まれます。" - -#~ msgid "`Subscribe `_ to receive it." -#~ msgstr "これを受け取るには、`サブスクライブ `_ します。" - -#~ msgid "Community Information & Contributing" -#~ msgstr "コミュニティーの情報および貢献" - -#~ msgid "This page is deprecated. Please see the updated :ref:`Ansible Community Guide `." -#~ msgstr "このページは非推奨になりました。更新された「:ref:`Ansible コミュニティーガイド `」を確認してください。" - -#~ msgid "Development on ``ansible-base`` occurs on two levels. At the macro level, the ``ansible-base`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle." -#~ msgstr "``ansible-base`` 開発サイクルは 2 つのレベルで行われます。マクロレベルでは、``ansible-base`` 開発者とメンテナーがリリースを計画を立て、ロードマップおよびプロジェクトを使用して進捗を追跡します。ミクロレベルでは、各プル要求には独自のライフサイクルがあります。" - -#~ msgid "Contributor opens a PR" -#~ msgstr "プル要求を開きます。" - -#~ msgid "Changelogs" -#~ msgstr "Changelog" - -#~ msgid "Changelogs help users and developers keep up with changes to Ansible. Ansible builds a changelog for each release from fragments. You **must** add a changelog fragment to any PR that changes functionality or fixes a bug in ansible-base. You do not have to add a changelog fragment for PRs that add new modules and plugins, because our tooling does that for you automatically." -#~ msgstr "changelog は、ユーザーや開発者が Ansible の変更情報を確認するのに役に立ちます。Ansible では、リリースごとにフラグメントから changelog を作成します。ansible-base の機能を変更したりバグを修正するプル要求には、changelog のフラグメントを追加する **必要があります**。プル要求が、新しいモジュールやプラグインを追加する場合は、ツールで自動的に行われるため、changelog のフラグメントを追加する必要はありません。" - -#~ msgid "Changes that break existing playbooks or roles. This includes any change to existing behavior that forces users to update tasks. Displayed in both the changelogs and the :ref:`Porting Guides `." -#~ msgstr "既存の Playbook またはロールを破損する変更。これには、ユーザーにタスクの更新を強制する既存の動作の変更が含まれます。changelog と :ref:`移植ガイド ` の両方に記載されます。" - -#~ msgid "Major changes to Ansible itself. Generally does not include module or plugin changes. Displayed in both the changelogs and the :ref:`Porting Guides `." -#~ msgstr "Ansible 自体への大規模な変更。通常、モジュールやプラグインの変更は含まれません。changelog と :ref:`移植ガイド ` の両方に記載されます。" - -#~ msgid "Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters." -#~ msgstr "Ansible、モジュール、またはプラグインへの小規模な変更。これには、新機能、モジュールに追加された新しいパラメーター、または既存のパラメーターに対する動作の変更が含まれます。" - -#~ msgid "Fixes that resolve issues." -#~ msgstr "問題を解決するための修正。" - -#~ msgid "Most changelog entries will be ``bugfixes`` or ``minor_changes``. When writing a changelog entry that pertains to a particular module, start the entry with ``- [module name] -`` and the following sentence with a lowercase letter." -#~ msgstr "ほとんどの changelog エントリーは ``bugfixes`` または ``minor_changes`` になります。特定のモジュールに関連する changelog エントリーを作成する場合は、そのエントリーを ``- [module name] -`` で始め、続く文章は小文字で表します。" - -#~ msgid "The choice to use ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` as the name for the feature branch is somewhat arbitrary, but conveys meaning about the purpose of that branch. It is not required to use this format, but it can be helpful, especially when making multiple backport PRs for multiple stable branches." -#~ msgstr "feature ブランチの名前に ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` を使用する選択は任意ですが、そのブランチの目的を伝えています。この形式を使うことは必須ではありませんが、特に複数の安定したブランチに対して、複数のバックポートのプル要求を作成する場合に役立ちます。" - -#~ msgid "To work with documentation on your local machine, you need to have python-3.5 or greater and the following packages installed:" -#~ msgstr "ローカルマシンでドキュメントを扱うには、python-3.5 以降と、以下のパッケージがインストールされている必要があります。" - -#~ msgid "gcc" -#~ msgstr "gcc" - -#~ msgid "jinja2" -#~ msgstr "jinja2" - -#~ msgid "libyaml" -#~ msgstr "libyaml" - -#~ msgid "Pygments >= 2.4.0" -#~ msgstr "Pygments 2.4.0 以降" - -#~ msgid "pyparsing" -#~ msgstr "pyparsing" - -#~ msgid "PyYAML" -#~ msgstr "PyYAML" - -#~ msgid "rstcheck" -#~ msgstr "rstcheck" - -#~ msgid "six" -#~ msgstr "six" - -#~ msgid "sphinx" -#~ msgstr "sphinx" - -#~ msgid "sphinx-notfound-page" -#~ msgstr "sphinx-notfound-page" - -#~ msgid "straight.plugin" -#~ msgstr "straight.plugin" - -#~ msgid "These required packages are listed in two :file:`requirements.txt` files to make installation easier:" -#~ msgstr "これらの必要なパッケージは、インストールを容易にするために、2 つの :file:`requirements.txt` ファイルに一覧表示されています。" - -#~ msgid "On macOS with Xcode, you may need to install ``six`` and ``pyparsing`` with ``--ignore-installed`` to get versions that work with ``sphinx``." -#~ msgstr "Xcode を使用する macOS では、``--ignore-installed`` を使用して ``six`` および ``pyparsing`` をインストールして、``sphinx``. に対応するバージョンを取得しないといけない場合があります。" - -#~ msgid "To learn more about the responsibilities of being an Ansible module maintainer, please read our :ref:`collection maintainer guidelines `." -#~ msgstr "Ansible モジュールメンテナーにおける責任の詳細は、「:ref:`モジュールのメンテナーガイドライン `」を参照してください。" - -#~ msgid "Guidelines for specific types of contributors" -#~ msgstr "貢献者向け各ガイドライン" - -#~ msgid "This page outlines the most common situations and questions that bring readers to this section. If you prefer a :ref:`traditional table of contents `, you can find one at the bottom of the page." -#~ msgstr "このページでは、本セクションにたどり着いたユーザーにとって最も一般的な状況や質問の概要を説明します。:ref:`従来の目次形式 ` をご希望のユーザー向けに、ページの一番下に目次が用意されています。" - -#~ msgid "I am new to the community. Where can I find the Ansible :ref:`code_of_conduct`?" -#~ msgstr "このコミュニティーに参加して間もないです。Ansible の :ref:`code_of_conduct` はどこで確認できますか。" - -#~ msgid "I would like to know what I am agreeing to when I contribute to Ansible. Does Ansible have a :ref:`contributor_license_agreement`?" -#~ msgstr "Ansible に貢献する際に何に同意しているのか知りたいのです。Ansible には :ref:`contributor_license_agreement` がありますか。" - -#~ msgid "I would like to contribute but I am not sure how. Are there :ref:`easy ways to contribute `?" -#~ msgstr "貢献したいのですが、方法がわかりません。:ref:`簡単に貢献する方法 ` はありますか。" - -#~ msgid "I have a question. Which :ref:`Ansible email lists and IRC channels ` will help me find answers?" -#~ msgstr "質問があります。:ref:`Ansible のメーリングリストや IRC チャンネル ` で答えを見つけるにはどうすればいいですか。" - -#~ msgid "I want to use the current release. How do I know which :ref:`releases are current `?" -#~ msgstr "最新のリリースを使用したいです。:ref:`どのリリースが最新のリリース ` かを知るにはどうすれば良いですか。" - -#~ msgid "Going deeper" -#~ msgstr "使い慣れてきた頃" - -#~ msgid "I think Ansible is broken. How do I :ref:`report a bug `?" -#~ msgstr "Ansible が破損しているように見えます。:ref:`バグを報告 ` するにはどうすれば良いですか。" - -#~ msgid "I need functionality that Ansible does not offer. How do I :ref:`request a feature `?" -#~ msgstr "Ansible が提供していない機能が必要です。:ref:`機能を要求 ` するにはどうすれば良いですか。" - -#~ msgid "How do I :ref:`contribute to an Ansible-maintained collection `?" -#~ msgstr ":ref:`Ansible が管理するコレクションに貢献 ` するにはどうすれば良いですか。" - -#~ msgid "I am waiting for a particular feature. How do I see what is :ref:`planned for future Ansible Releases `?" -#~ msgstr "特定の機能が必要です。:ref:`Ansible の将来のリリースで予定されている ` ものを確認するにはどうすれば良いですか。" - -#~ msgid "I would like to participate in conversations about features and fixes. How do I review GitHub issues and pull requests?" -#~ msgstr "機能や修正に関する議論に参加したいです。GitHub の問題やプル要求を確認するにはどうすれば良いですか。" - -#~ msgid "I found a typo or another problem on docs.ansible.com. How can I :ref:`improve the documentation `?" -#~ msgstr "docs.ansible.com でタイポなどの誤りを見つけました。:ref:`ドキュメントを改善 ` するにはどうすれば良いですか。" - -#~ msgid "Is there a :ref:`mailing list ` I can sign up for to stay informed about Ansible?" -#~ msgstr "サインアップして Ansible に関する通知を受けることができる :ref:`メーリングリスト ` はありますか。" - -#~ msgid "I want to learn more about Ansible roadmaps, releases, and projects. How do I find information on :ref:`the development cycle `?" -#~ msgstr "Ansible のロードマップ、リリース、およびプロジェクトについて詳しく知りたいです。:ref:`開発サイクル ` に関する情報はどこにありますか。" - -#~ msgid "Traditional Table of Contents" -#~ msgstr "従来の目次" - -#~ msgid "If you prefer to read the entire Community Guide, here is a list of the pages in order:" -#~ msgstr "コミュニティーガイド全体をお読みになりたい方は、こちらのページを順番にご覧ください。" - -#~ msgid "When you contribute a module to a collection included in the ``ansible`` package, you become a maintainer for that module once it has been merged. Maintainership empowers you with the authority to accept, reject, or request revisions to pull requests on your module -- but as they say, \"with great power comes great responsibility.\"" -#~ msgstr "``ansible`` パッケージに含まれるコレクションにモジュールを提供し、それがマージされると、そのモジュールのメンテナーになります。メンテナーになると、主に、モジュールへのプル要求を許可、拒否、またはリクエストする権限を持つことになりますが、「権限が大きくなると責任も大きくなる」とも言えます。" - -#~ msgid "Resources" -#~ msgstr "リソース" - -#~ msgid "Please see :ref:`communication` for ways to contact the broader Ansible community. For maintainers, following the `ansible-devel `_ mailing list is a great way to participate in conversations about coding, get assistance when you need it, and influence the overall direction, quality, and goals of Ansible and the collections. If you are not on this relatively low-volume list, please join us here: https://groups.google.com/forum/#!forum/ansible-devel" -#~ msgstr "幅広い Ansible コミュニティーに連絡する方法は、:ref:`communication` を参照してください。`ansible-devel `_ メーリングリストに参加することは、メンテナーにとって、コーディングに関する対話に参加し、必要に応じて支援を受け、Ansible およびコレクションの全体的な方向、品質、および目的に影響を与えるための優れた方法です。このリストに載っていない場合はhttps://groups.google.com/forum/#!forum/ansible-devel に参加してください。" - -#~ msgid "Pull requests, issues, and workflow" -#~ msgstr "プル要求、問題、およびワークフロー" - -#~ msgid "`Ansible Syntax Highlighting Extension `_ - YAML & Jinja2 support." -#~ msgstr "`Ansible Syntax Highlighting Extension `_ - YAML および Jinja2 サポート。" - -#~ msgid "`Visual Studio Code extension for Ansible `_ - provides autocompletion, syntax highlighting." -#~ msgstr "`Visual Studio Code extension for Ansible `_ - オートコンプリート、構文強調表示を提供します。" - -#~ msgid "`ARA `_ - records Ansible playbook runs and makes the recorded data available and intuitive for users and systems by integrating with Ansible as a callback plugin." -#~ msgstr "`ARA `_ - Ansible Playbook の実行を記録し、コールバックプラグインとして Ansible と統合することにより、記録されたデータをユーザーおよびシステムが利用できる直感的なものにします。" - -#~ msgid "Ansible Tower team" -#~ msgstr "Ansible Tower チーム" - -#~ msgid "If you find a bug that affects multiple plugins, a plugin that remained in the ansible/ansible repo, or the overall functioning of Ansible, report it to `github.com/ansible/ansible/issues `_. You need a free GitHub account. Before reporting a bug, use the bug/issue search to see if the issue has already been reported. If you are not sure if something is a bug yet, you can report the behavior on the :ref:`mailing list or IRC first `." -#~ msgstr "複数のプラグイン、ansible/ansible リポジトリーに残っているプラグイン、または Ansible の全体的な機能に影響を与えるバグは、`github.com/ansible/ansible/issues `_ に報告します。無料の GitHub アカウントが必要になります。バグを報告する前に、バグ/問題検索を使用して、その問題がすでに報告されているかどうかを確認します。バグかどうか分からない場合は、:ref:`最初にメーリングリストまたは IRC ` に動作を報告できます。" - -#~ msgid "Do not open issues for \"how do I do this\" type questions. These are great topics for IRC or the mailing list, where things are likely to be more of a discussion." -#~ msgstr "「How do I do this (どうすればいいのか)」というタイプの質問で、問題を作成しないでください。このタイプの問題は、物事がより多くの議論になる可能性が高い IRC またはメーリングリストにとって素晴らしいトピックです。" - -#~ msgid "If you find a bug, open the issue yourself to ensure we have a record of it. Do not rely on someone else in the community to file the bug report for you. We have created an issue template, which saves time and helps us help everyone with their issues more quickly. Please fill it out as completely and as accurately as possible:" -#~ msgstr "バグを見つけた場合は、自分で問題を作成して、記録されたことを確認してください。コミュニティーの他の誰かがバグレポートを提出するのを待たないでください。問題テンプレートを作成しました。これにより、時間を節約し、すべての人がその問題をより迅速に解決できるようになります。できるだけ完全かつ正確に記入してください。" - -#~ msgid "Include any relevant configuration" -#~ msgstr "関連する設定の記載" - -#~ msgid "Include the exact commands or tasks you are running" -#~ msgstr "実行する正確なコマンドまたはタスクの記載" - -#~ msgid "Describe the behavior you expected" -#~ msgstr "期待される動作の説明" - -#~ msgid "Provide steps to reproduce the bug * Use minimal well-reduced and well-commented examples, not your entire production playbook * When sharing YAML in playbooks, preserve the formatting by using `code blocks `_." -#~ msgstr "バグを再現するための手順の記載 * 実稼働で使用する Playbook 全体ではなく、必要な最小限の部分だけを取り出し、詳細な説明を記載 * Playbook で YAML を共有する場合は、`コードブロック `_ を使用してフォーマットを整理します。" - -#~ msgid "Document the behavior you got" -#~ msgstr "発生した動作の記述" - -#~ msgid "Include output where possible" -#~ msgstr "可能な場合は出力結果の記載" - -#~ msgid "For multiple-file content, use gist.github.com, which is more durable than pastebin content" -#~ msgstr "コンテンツが複数ファイルの場合は、gist.github.com を使用します。これは pastebin コンテンツよりも永続的です。" - -#~ msgid "Triage Process" -#~ msgstr "トリアージプロセス" - -#~ msgid "The issue and PR triage processes are driven by the `Ansibot `_. Whenever an issue or PR is filed, the Ansibot examines the issue to ensure that all relevant data is present, and handles the routing of the issue as it works its way to eventual completion." -#~ msgstr "問題およびプル要求のトリアージープロセスは `Ansibot `_ によって実行されます。問題やプル要求が報告されるたびに、Ansibot は問題を調べ、すべての関連データが存在することを確認し、最終的な完成に向けて問題のルーティングを処理します。" - -#~ msgid "For details on how Ansibot manages the triage process, please consult the `Ansibot Issue Guide `_." -#~ msgstr "Ansibot によるトリアージプロセスの管理方法に関する詳細は、「`Ansibot 問題ガイド `_」を参照してください。" - -#~ msgid "If you are going to release the ``community.general`` and ``community.network`` collections, create new ``backport-X`` and ``needs_backport_to_stable_X`` labels in the corresponding repositories. Copy the styles and descriptions from the corresponding existing labels." -#~ msgstr "``community.general`` および ``community.network`` コレクションをリリースする場合は、対応するリポジトリーに新しい ``backport-X`` および ``needs_backport_to_stable_X`` ラベルを作成します。対応する既存ラベルからスタイルおよび説明をコピーします。" - -#~ msgid "Most changelog entries are ``bugfixes`` or ``minor_changes``. You can also use ``trivial`` for any collection that requires a changelog fragment for each pull request. ``trivial`` changelog fragments are excluded from the changelog output." -#~ msgstr "ほとんどの changelog エントリーは、``bugfixes`` または ``minor_changes`` です。プル要求ごとに changelog フラグメントを必要とするコレクションに ``trivial`` を使用することもできます。``trivial`` changelog フラグメントは changelog 出力から除外されます。" - -#~ msgid "`Ansible Lockdown List `_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks." -#~ msgstr "`Ansible Lockdown リスト `_ は、DISA STIG オートメーションや CIS ベンチマークなど、Ansible Lockdown プロジェクトに関連するものを対象としています。" - -#~ msgid "edits (so you can fix your typos)" -#~ msgstr "編集（タイプミスを修正できます）" - -#~ msgid "`Ansible Lockdown Working Group `_ (`Security playbooks/roles `_) - Matrix: `#lockdown:ansible.com `_ | IRC: ``#ansible-lockdown``" -#~ msgstr "`Ansible Lockdown Working Group `_ (`Security playbooks/roles `_) - Matrix: `#lockdown:ansible.com `_ | IRC: ``#ansible-lockdown``" - -#~ msgid "You can also look for GitHub issues labeled with the ``easyfix``, ``good_first_issue``, and ``docs`` labels. Add a comment on the GitHub issue to say you are looking at it and to ask for help if you need it." -#~ msgstr "``easyfix``、``good_first_issue``、``docs`` でラベル付けされた GitHub issue を見つけることもできます。GitHub issue に閲覧したことを示すコメントを追加し、必要に応じて助言を依頼してください。" - -#~ msgid "You can use the ``-vv`` or ``-vvv`` argument, if you need more detailed output." -#~ msgstr "より詳細な出力が必要な場合は、``-vv`` 引数または ``-vvv`` 引数を使用できます。" - -#~ msgid "You can also contribute by reviewing open documentation `issues `_ and `PRs `_. To add a helpful review, please:" -#~ msgstr "開いているドキュメントの `問題 (issue) `_ および `プル要求 `_ を確認することで貢献することもできます。役に立つレビューを追加するには、以下を参照してください。" - -#~ msgid "Include a comment - \"looks good to me\" only helps if we know why." -#~ msgstr "「looks good to me (私には良さそうに見える)」というコメントは、他の人にもその理由が明らかな場合にのみ使用してください。" - -#~ msgid "For issues, reproduce the problem." -#~ msgstr "問題については、問題を再現します。" - -#~ msgid "For PRs, test the change." -#~ msgstr "プル要求については、変更をテストします。" - -#~ msgid "The Community and the Steering Committee come together at weekly meetings in the ``#ansible-community`` :ref:`Matrix/Libera.Chat ` channel to discuss important project-scale questions. See the `schedule `_ and join." -#~ msgstr "コミュニティーと Steering Committee は、``#ansible-community`` :ref:`Matrix/Libera.Chat ` チャンネルで毎週ミーティングを行い、プロジェクト規模の重要な質問について話し合います。`schedule `_ を参照して参加してください。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po deleted file mode 100644 index b6abc3e5874..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po +++ /dev/null @@ -1,16418 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/dev_guide/ansible_index.rst:5 ../../rst/dev_guide/core_index.rst:5 -msgid "Developer Guide" -msgstr "開発者ガイド" - -#: ../../rst/dev_guide/ansible_index.rst:9 ../../rst/dev_guide/core_index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/dev_guide/ansible_index.rst:11 -#: ../../rst/dev_guide/core_index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/dev_guide/ansible_index.rst:13 -#: ../../rst/dev_guide/core_index.rst:13 -msgid "Welcome to the Ansible Developer Guide!" -msgstr "Ansible 開発者ガイドにようこそ!" - -#: ../../rst/dev_guide/ansible_index.rst:15 -#: ../../rst/dev_guide/core_index.rst:15 -msgid "**Who should use this guide?**" -msgstr "**本ガイドの対象者**" - -#: ../../rst/dev_guide/ansible_index.rst:17 -#: ../../rst/dev_guide/core_index.rst:17 -msgid "If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We've included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository." -msgstr "カスタムモジュールまたはプラグインのローカルでの使用、モジュールまたはプラグインの作成、既存のモジュールへの機能の追加、テスト範囲の拡張を行って Ansible を拡張する場合は、このガイドをご利用になれます。モジュールのテストおよびドキュメント化に関する方法についての開発者向けの詳細情報、および主な Ansible リポジトリーに受け入れられるモジュールまたはプラグインを取得するための前提条件が記載されています。" - -#: ../../rst/dev_guide/ansible_index.rst:19 -#: ../../rst/dev_guide/core_index.rst:19 -msgid "Find the task that best describes what you want to do:" -msgstr "以下の中から、お客様のニーズに最も適したタスクを選んでください。" - -#: ../../rst/dev_guide/ansible_index.rst:21 -#: ../../rst/dev_guide/core_index.rst:21 -msgid "I'm looking for a way to address a use case:" -msgstr "ユースケースに対応する方法を探している。" - -#: ../../rst/dev_guide/ansible_index.rst:23 -#: ../../rst/dev_guide/core_index.rst:23 -msgid "I want to :ref:`add a custom plugin or module locally `." -msgstr ":ref:`カスタムプラグインまたはモジュールをローカルに追加 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:24 -#: ../../rst/dev_guide/core_index.rst:24 -msgid "I want to figure out if :ref:`developing a module is the right approach ` for my use case." -msgstr "選択したユースケースでは、:ref:`モジュールの開発が適切なアプローチである ` かどうかを確認したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:25 -#: ../../rst/dev_guide/core_index.rst:25 -msgid "I want to :ref:`develop a collection `." -msgstr ":ref:`コレクションを開発 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:26 -#: ../../rst/dev_guide/core_index.rst:26 -msgid "I want to :ref:`contribute to an Ansible-maintained collection `." -msgstr ":ref:`Ansible が管理するコレクションに貢献 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:27 -#: ../../rst/dev_guide/core_index.rst:27 -msgid "I want to :ref:`contribute to a community-maintained collection `." -msgstr ":ref:`コミュニティーが管理するコレクションに貢献 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:28 -#: ../../rst/dev_guide/core_index.rst:28 -msgid "I want to :ref:`migrate a role to a collection `." -msgstr ":ref:`ロールをコレクションに移行 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:30 -#: ../../rst/dev_guide/core_index.rst:30 -msgid "I've read the info above, and I'm sure I want to develop a module:" -msgstr "上記の情報を読んで、モジュールを開発したい。" - -#: ../../rst/dev_guide/ansible_index.rst:32 -#: ../../rst/dev_guide/core_index.rst:32 -msgid "What do I need to know before I start coding?" -msgstr "コーディングを始める前に何を知っておくべきでしょうか。" - -#: ../../rst/dev_guide/ansible_index.rst:33 -#: ../../rst/dev_guide/core_index.rst:33 -msgid "I want to :ref:`set up my Python development environment `." -msgstr ":ref:`Python 開発環境をセットアップ ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:34 -#: ../../rst/dev_guide/core_index.rst:34 -msgid "I want to :ref:`get started writing a module `." -msgstr ":ref:`モジュールの記述を開始 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:39 -#: ../../rst/dev_guide/core_index.rst:36 -msgid "I want to write a specific kind of module:" -msgstr "特定のモジュールを作成したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:36 -#: ../../rst/dev_guide/core_index.rst:36 -msgid "a :ref:`network module `" -msgstr ":ref:`ネットワークモジュール `" - -#: ../../rst/dev_guide/ansible_index.rst:37 -#: ../../rst/dev_guide/core_index.rst:37 -msgid "a :ref:`Windows module `." -msgstr ":ref:`Windows モジュール `" - -#: ../../rst/dev_guide/ansible_index.rst:38 -msgid "an :ref:`Amazon module `." -msgstr ":ref:`Amazon module `." - -#: ../../rst/dev_guide/ansible_index.rst:39 -msgid "an :ref:`oVirt/RHV module `." -msgstr ":ref:`oVirt/RHV module `" - -#: ../../rst/dev_guide/ansible_index.rst:40 -msgid "a :ref:`VMware module `." -msgstr ":ref:`VMware module `" - -#: ../../rst/dev_guide/ansible_index.rst:41 -#: ../../rst/dev_guide/core_index.rst:38 -msgid "I want to :ref:`write a series of related modules ` that integrate Ansible with a new product (for example, a database, cloud provider, network platform, and so on)." -msgstr "Ansible を新規製品 (例: データベース、クラウドプロバイダー、ネットワークプラットフォーム) と統合する :ref:`一連の関連モジュールを記述 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:43 -#: ../../rst/dev_guide/core_index.rst:40 -msgid "I want to refine my code:" -msgstr "コードを改良したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:45 -#: ../../rst/dev_guide/core_index.rst:42 -msgid "I want to :ref:`debug my module code `." -msgstr ":ref:`モジュールコードをデバッグ ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:46 -#: ../../rst/dev_guide/core_index.rst:43 -msgid "I want to :ref:`add tests `." -msgstr ":ref:`テストを追加 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:47 -#: ../../rst/dev_guide/core_index.rst:44 -msgid "I want to :ref:`document my module `." -msgstr ":ref:`モジュールをドキュメント化 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:48 -#: ../../rst/dev_guide/core_index.rst:45 -msgid "I want to :ref:`document my set of modules for a network platform `." -msgstr ":ref:`ネットワークプラットフォームのモジュールセットを文書化 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:49 -#: ../../rst/dev_guide/core_index.rst:46 -msgid "I want to follow :ref:`conventions and tips for clean, usable module code `." -msgstr ":ref:`クリーンで使いやすいモジュールコードのための規則とヒント ` を適用したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:50 -#: ../../rst/dev_guide/core_index.rst:47 -msgid "I want to :ref:`make sure my code runs on Python 2 and Python 3 `." -msgstr ":ref:`作成したコードが Python 2 および Python 3 で実行する ` ようにしたいです。" - -#: ../../rst/dev_guide/ansible_index.rst:52 -#: ../../rst/dev_guide/core_index.rst:49 -msgid "I want to work on other development projects:" -msgstr "他の開発プロジェクトで作業したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:54 -#: ../../rst/dev_guide/core_index.rst:51 -msgid "I want to :ref:`write a plugin `." -msgstr ":ref:`プラグインを記述 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:55 -#: ../../rst/dev_guide/core_index.rst:52 -msgid "I want to :ref:`connect Ansible to a new source of inventory `." -msgstr ":ref:`Ansible を新しいインベントリーソースに接続 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:56 -#: ../../rst/dev_guide/core_index.rst:53 -msgid "I want to :ref:`deprecate an outdated module `." -msgstr ":ref:`古いモジュールを非推奨 ` にしたいです。" - -#: ../../rst/dev_guide/ansible_index.rst:58 -#: ../../rst/dev_guide/core_index.rst:55 -msgid "I want to contribute back to the Ansible project:" -msgstr "Ansible プロジェクトに貢献したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:60 -#: ../../rst/dev_guide/core_index.rst:57 -msgid "I want to :ref:`understand how to contribute to Ansible `." -msgstr ":ref:`Ansible への貢献方法を理解 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:61 -#: ../../rst/dev_guide/core_index.rst:58 -msgid "I want to :ref:`contribute my module or plugin `." -msgstr ":ref:`モジュールまたはプラグインに貢献 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:62 -#: ../../rst/dev_guide/core_index.rst:59 -msgid "I want to :ref:`understand the license agreement ` for contributions to Ansible." -msgstr "Ansible に参加するための :ref:`使用許諾契約を理解 ` したいです。" - -#: ../../rst/dev_guide/ansible_index.rst:64 -#: ../../rst/dev_guide/core_index.rst:61 -msgid "If you prefer to read the entire guide, here's a list of the pages in order." -msgstr "本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:5 -msgid "Collection Galaxy metadata structure" -msgstr "コレクション Galaxy メタデータ構造" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:7 -msgid "A key component of an Ansible collection is the ``galaxy.yml`` file placed in the root directory of a collection. This file contains the metadata of the collection that is used to generate a collection artifact." -msgstr "Ansible コレクションの主なコンポーネントは、コレクションのルートディレクトリーに置いてある ``galaxy.yml`` ファイルです。このファイルには、コレクションアーティファクトの生成に使用されるコレクションのメタデータが含まれます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:11 -msgid "Structure" -msgstr "構造" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:13 -msgid "The ``galaxy.yml`` file must contain the following keys in valid YAML:" -msgstr "``galaxy.yml`` ファイルの有効な YAML に以下のキーが含まれている必要があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:22 -msgid "Key" -msgstr "キー" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:23 -msgid "Comment" -msgstr "コメント" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:27 -msgid "namespace |br|" -msgstr "namespace |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:31 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:55 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:77 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:99 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:143 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:175 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:229 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:243 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:257 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:271 -msgid "string |_|" -msgstr "文字列 |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:35 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:59 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:81 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:103 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:125 -msgid "/ |_|" -msgstr "/ |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:39 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:63 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:85 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:107 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:129 -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required" -msgstr "必須" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:41 -msgid "The namespace of the collection." -msgstr "コレクションの名前空間。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:43 -msgid "This can be a company/brand/organization or product namespace under which all content lives." -msgstr "これには、企業/ブランド/組織、またはすべてのコンテンツが置かれる製品の名前空間を指定できます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:45 -msgid "May only contain alphanumeric lowercase characters and underscores. Namespaces cannot start with underscores or numbers and cannot contain consecutive underscores." -msgstr "英数字 (小文字) とアンダースコアのみを使用できます。名前空間はアンダースコアや数字で開始できず、連続したアンダースコアを含めることはできません。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:51 -msgid "name |br|" -msgstr "name |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:65 -msgid "The name of the collection." -msgstr "コレクションの名前。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:67 -msgid "Has the same character restrictions as \\ :literal:`namespace`\\ ." -msgstr "\\ :literal:`namespace`\\ と同じ文字制限があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:73 -msgid "version |br|" -msgstr "version |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:87 -msgid "The version of the collection." -msgstr "コレクションのバージョン。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:89 -msgid "Must be compatible with semantic versioning." -msgstr "セマンティックバージョニングと互換性がある必要があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:95 -msgid "readme |br|" -msgstr "readme |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:109 -msgid "The path to the Markdown (.md) readme file." -msgstr "マークダウン (.md) readme ファイルへのパス。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:111 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:181 -msgid "This path is relative to the root of the collection." -msgstr "このパスは、コレクションのルートに相対します。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:117 -msgid "authors |br|" -msgstr "authors |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:121 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:157 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:193 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:285 -msgid "list |_|" -msgstr "リスト |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:131 -msgid "A list of the collection's content authors." -msgstr "コレクションのコンテンツ作成者の一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:133 -msgid "Can be just the name or in the format 'Full Name (url) @nicks:irc/im.site#channel'." -msgstr "名前または形式には、「氏名 (url) @nicks:irc/im.site#channel」の形式しか指定できません。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:139 -msgid "description |br|" -msgstr "description |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:147 -msgid "A short summary description of the collection." -msgstr "コレクションの簡単な説明。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:153 -msgid "license |br|" -msgstr "license |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:161 -msgid "Either a single license or a list of licenses for content inside of a collection." -msgstr "コレクション内の 1 つのライセンスまたはコンテンツのライセンスの一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:163 -msgid "Ansible Galaxy currently only accepts \\ `SPDX `__\\ licenses" -msgstr "現在 Ansible Galaxy は \\ `SPDX `__\\ ライセンスのみ受け付けます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:165 -msgid "This key is mutually exclusive with \\ :literal:`license\\_file`\\ ." -msgstr "このキーは、\\ :literal:`license\\_file`\\ と相互に排他的です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:171 -msgid "license_file |br|" -msgstr "license_file |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:179 -msgid "The path to the license file for the collection." -msgstr "コレクションのライセンスファイルへのパス。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:183 -msgid "This key is mutually exclusive with \\ :literal:`license`\\ ." -msgstr "このキーは、\\ :literal:`license`\\ と相互に排他的です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:189 -msgid "tags |br|" -msgstr "tags |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:197 -msgid "A list of tags you want to associate with the collection for indexing/searching." -msgstr "インデックス化/検索のコレクションに関連付けるタグの一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:199 -msgid "A tag name has the same character requirements as \\ :literal:`namespace`\\ and \\ :literal:`name`\\ ." -msgstr "タグ名には、\\ :literal:`namespace`\\ および \\ :literal:`name`\\ と同じ文字要件があります。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:205 -msgid "dependencies |br|" -msgstr "dependencies |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:209 -msgid "dictionary |_|" -msgstr "ディクショナリー |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:213 -msgid "Collections that this collection requires to be installed for it to be usable." -msgstr "利用できるように、このコレクションをインストールする必要があるコレクション。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:215 -msgid "The key of the dict is the collection label \\ :literal:`namespace.name`\\ ." -msgstr "ディクショナリーのキーはコレクションラベル \\ :literal:`namespace.name`\\ です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:217 -msgid "The value is a version range \\ `specifiers `__\\ ." -msgstr "この値は、\\ `specifiers `__\\ のバージョン範囲です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:219 -msgid "Multiple version range specifiers can be set and are separated by \\ :literal:`,`\\ ." -msgstr "複数のバージョン範囲指定子を設定でき、\\ :literal:`,`\\ で区切ることができます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:225 -msgid "repository |br|" -msgstr "repository |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:233 -msgid "The URL of the originating SCM repository." -msgstr "元の SCM リポジトリーの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:239 -msgid "documentation |br|" -msgstr "documentation |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:247 -msgid "The URL to any online docs." -msgstr "オンラインドキュメントへの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:253 -msgid "homepage |br|" -msgstr "homepage |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:261 -msgid "The URL to the homepage of the collection/project." -msgstr "コレクション/プロジェクトのホームページへの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:267 -msgid "issues |br|" -msgstr "issues |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:275 -msgid "The URL to the collection issue tracker." -msgstr "コレクションの問題トラッカーへの URL。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:281 -msgid "build_ignore |br|" -msgstr "build_ignore |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:290 -msgid "|br| version_added: 2.10" -msgstr "|br| version_added: 2.10" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:292 -#: ../../rst/dev_guide/collections_galaxy_meta.rst:318 -msgid "|_|" -msgstr "|_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:293 -msgid "A list of file glob-like patterns used to filter any files or directories that should not be included in the build artifact." -msgstr "ビルドアーティファクトに含まれないファイルやディレクトリーをフィルタリングするのに使用されるファイルグロブのようなパターンの一覧。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:295 -msgid "A pattern is matched from the relative path of the file or directory of the collection directory." -msgstr "パターンは、コレクションディレクトリーのファイルまたはディレクトリーの相対パスから照合されます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:297 -msgid "This uses \\ :literal:`fnmatch`\\ to match the files or directories." -msgstr "ここでは、\\ :literal:`fnmatch`\\ を使用してファイルまたはディレクトリーを照合します。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:299 -msgid "Some directories and files like \\ :literal:`galaxy.yml`\\ , \\ :literal:`\\*.pyc`\\ , \\ :literal:`\\*.retry`\\ , and \\ :literal:`.git`\\ are always filtered." -msgstr "\\ :literal:`galaxy.yml`\\、\\ :literal:`\\*.pyc`\\、\\ :literal:`\\*.retry`\\、\\ :literal:`.git`\\ など一部のディレクトリーやファイルは常にフィルタリングされます。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:301 -msgid "Mutually exclusive with \\ :literal:`manifest`\\" -msgstr "\\ :literal:`manifest`\\ と併用できません。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:307 -msgid "manifest |br|" -msgstr "manifest |br|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:311 -msgid "sentinel |_|" -msgstr "sentinel |_|" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:316 -msgid "|br| version_added: 2.14" -msgstr "|br| version_added: 2.14" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:319 -msgid "A dict controlling use of manifest directives used in building the collection artifact." -msgstr "コレクションアーティファクトの構築に使用されるマニフェストディレクティブの使用を制御する辞書。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:321 -msgid "The key \\ :literal:`directives`\\ is a list of MANIFEST.in style \\ `directives `__\\" -msgstr "キー \\ :literal:`directives`\\ は MANIFEST.in style \\ `directives `__\\ のリストです。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:323 -msgid "The key \\ :literal:`omit\\_default\\_directives`\\ is a boolean that controls whether the default directives are used" -msgstr "キー \\ :literal:`omit\\_default\\_directives`\\ は、デフォルトのディレクティブを使用するかどうかを制御するブール値です。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:325 -msgid "Mutually exclusive with \\ :literal:`build\\_ignore`\\" -msgstr "\\ :literal:`build\\_ignore`\\ と併用できません。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:330 -msgid "Examples" -msgstr "例" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:355 -msgid ":ref:`developing_collections`" -msgstr ":ref:`developing_collections`" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:356 -msgid "Develop or modify a collection." -msgstr "コレクションを開発するか、または変更します。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:357 -#: ../../rst/dev_guide/developing_api.rst:40 -#: ../../rst/dev_guide/developing_inventory.rst:505 -#: ../../rst/dev_guide/developing_plugins.rst:548 -#: ../../rst/dev_guide/sidecar.rst:95 -#: ../../rst/dev_guide/testing_units_modules.rst:571 -msgid ":ref:`developing_modules_general`" -msgstr ":ref:`developing_modules_general`" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:358 -#: ../../rst/dev_guide/developing_plugins.rst:549 -#: ../../rst/dev_guide/sidecar.rst:96 -msgid "Learn about how to write Ansible modules" -msgstr "Ansible モジュールの作成方法について" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:359 -#: ../../rst/dev_guide/developing_collections.rst:40 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:75 -#: ../../rst/dev_guide/developing_collections_contributing.rst:58 -#: ../../rst/dev_guide/developing_collections_creating.rst:54 -#: ../../rst/dev_guide/developing_collections_distributing.rst:399 -#: ../../rst/dev_guide/developing_collections_migrating.rst:129 -#: ../../rst/dev_guide/developing_collections_shared.rst:87 -msgid ":ref:`collections`" -msgstr ":ref:`collections`" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:360 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:76 -#: ../../rst/dev_guide/developing_collections_contributing.rst:59 -#: ../../rst/dev_guide/developing_collections_creating.rst:55 -#: ../../rst/dev_guide/developing_collections_distributing.rst:400 -#: ../../rst/dev_guide/developing_collections_migrating.rst:130 -#: ../../rst/dev_guide/developing_collections_shared.rst:88 -msgid "Learn how to install and use collections." -msgstr "コレクションのインストール方法および使用方法はこちらを参照してください。" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:361 -#: ../../rst/dev_guide/developing_collections.rst:46 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:79 -#: ../../rst/dev_guide/developing_collections_contributing.rst:62 -#: ../../rst/dev_guide/developing_collections_creating.rst:58 -#: ../../rst/dev_guide/developing_collections_distributing.rst:403 -#: ../../rst/dev_guide/developing_collections_migrating.rst:133 -#: ../../rst/dev_guide/developing_collections_shared.rst:91 -#: ../../rst/dev_guide/developing_collections_structure.rst:290 -#: ../../rst/dev_guide/developing_collections_testing.rst:96 -#: ../../rst/dev_guide/developing_core.rst:19 -#: ../../rst/dev_guide/developing_modules.rst:48 -#: ../../rst/dev_guide/developing_plugins.rst:550 -#: ../../rst/dev_guide/sidecar.rst:97 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:362 -#: ../../rst/dev_guide/developing_collections.rst:47 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:80 -#: ../../rst/dev_guide/developing_collections_contributing.rst:63 -#: ../../rst/dev_guide/developing_collections_creating.rst:59 -#: ../../rst/dev_guide/developing_collections_distributing.rst:404 -#: ../../rst/dev_guide/developing_collections_migrating.rst:134 -#: ../../rst/dev_guide/developing_collections_shared.rst:92 -#: ../../rst/dev_guide/developing_collections_structure.rst:291 -#: ../../rst/dev_guide/developing_collections_testing.rst:97 -#: ../../rst/dev_guide/developing_core.rst:20 -#: ../../rst/dev_guide/developing_plugins.rst:551 -#: ../../rst/dev_guide/sidecar.rst:98 -msgid "The development mailing list" -msgstr "開発メーリングリスト" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:363 -msgid "`irc.libera.chat `_" -msgstr "`irc.libera.chat `_" - -#: ../../rst/dev_guide/collections_galaxy_meta.rst:364 -msgid "#ansible IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible)" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:5 -msgid "``ansible-core`` project branches and tags" -msgstr "``ansible-core`` プロジェクトのブランチとタグ" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:8 -msgid "``devel`` branch" -msgstr "``devel`` ブランチ" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:10 -msgid "All new development on the next version of ``ansible-core`` occurs exclusively in the ``devel`` branch, and all bugfixes to prior releases must first be merged to devel before being backported to one or more stable branches for inclusion in servicing releases. Around the Beta 1 milestone, a new ``stable-X.Y`` branch is cut from ``devel``, which is then updated to host development of the ``X.Y+1`` release. External automated testing of Ansible content from ``devel`` is not generally recommended." -msgstr "次のバージョンの ``ansible-core`` における新しい開発はすべて、``devel`` ブランチでのみ行われ、以前のリリースに対するすべてのバグ修正はまず devel にマージしてから、サービスリリースに含めるために 1 つ以上の安定したブランチにバックポートされる必要があります。ベータ 1 マイルストーンでは、新しい ``stable-X.Y`` ブランチは ``devel`` からカットされ、その後 ``X.Y+1`` リリースのホスト開発に更新されます。``devel`` からの Ansible コンテンツの外部自動テストは、一般的には推奨されません。" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:17 -msgid "``stable-X.Y`` branches" -msgstr "``stable-X.Y`` ブランチ" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:19 -msgid "All ``ansible-core`` ``X.Y.Z`` releases are created from a corresponding ``stable-X.Y`` branch. A release's stable branch is typically cut from ``devel`` around ``X.Y.0 beta 1`` (when the release is feature complete). All further bugfixes (no enhancements!) must be made against ``devel`` and backported to applicable stable branches." -msgstr "``ansible-core`` ``X.Y.Z`` リリースはすべて、対応する ``stable-X.Y`` ブランチから作成されます。リリースの安定したブランチは通常、``X.Y.0 beta 1`` の周りの ``devel`` から取り除かれます (リリースの機能完了時に)。追加のバグ修正 (機能拡張なし) は、``devel`` に対して作成し、該当する安定したブランチにバックポートする必要があります。" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:24 -msgid "``vX.Y.Z`` tags" -msgstr "``vX.Y.Z`` tags" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:26 -msgid "Each ``ansible-core vX.Y.Z`` release is tagged from the release commit in the corresponding ``stable-X.Y`` branch, allowing access to the exact source used to create the release. As of ``ansible-core`` 2.13, the auto-generated GitHub tarball of the tag contents is considered the official canonical release artifact." -msgstr "各 ``ansible-core vX.Y.Z`` リリースは、対応する ``stable-X.Y`` ブランチのリリースコミットからタグ付けされ、リリースの作成に使用された正確なソースへのアクセスが可能になります。``ansible-core`` 2.13 の時点で、タグコンテンツの自動生成された GitHub tarball は公式の正規リリースアーティファクトとみなされます。" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:34 -msgid "``milestone`` branch" -msgstr "``milestone`` branch" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:36 -msgid "A ``milestone`` branch is a slow-moving stream of the ``devel`` branch, intended for external testing of ``ansible-core`` features under active development. As described in the :ref:`ansible_core_roadmaps` for a given release, development is typically split into three phases of decreasing duration, with larger and more invasive changes targeted to be merged to ``devel`` in earlier phases. The ``milestone`` branch is updated to the contents of ``devel`` at the end of each development phase. This allows testing of semi-stable unreleased features on a predictable schedule without the exposure to the potential instability of the daily commit \"fire hose\" from ``devel``. When a release reaches the Beta 1 milestone, the ``milestone`` branch will be updated to the first ``devel`` commit after the version number has been increased. Further testing of the same release should be done from the new ``stable-X.Y`` branch that was created. If a severe issue that significantly affects community testing or stability is discovered in the ``milestone`` branch, the branch contents may require unscheduled adjustment, but not in a way that prevents fast-forward updates (for example, ``milestone``-only commits will not be created or cherry-picked from ``devel``)." -msgstr "``milestone`` ブランチは、動きの遅い ``devel`` ブランチのストリームで、アクティブな開発における ``ansible-core`` 機能の外部テストを目的としています。指定されたリリースの :ref:`ansible_core_roadmaps` で説明されているように、開発は通常、期間が短い 3 つのフェーズに分割され、早期のフェーズで大きく侵襲的な変化を ``devel`` にマージすることを目標とします。``milestone`` ブランチは、各開発フェーズの終了時に ``devel`` の内容に更新されます。これにより、``devel`` からの毎日のコミットである「fire hose」にさらされることなく、予測可能なスケジュールで、半安定的な未リリースの機能をテストできます。リリースが Beta 1 マイルストーンに到達すると、``milestone`` ブランチはバージョン番号を増やしたあとで最初の ``devel`` コミットに更新されます。同じリリースをさらにテストする場合は、作成した新しい ``stable-X.Y`` ブランチから行う必要があります。コミュニティーのテストや安定性に大きく影響する重大な問題が ``milestone`` ブランチで検出された場合、ブランチの内容には予定外の調整が必要になることもありますが、Fast Forward Upgrade を妨げることはありません (たとえば、``milestone``のみのコミットは作成されたり、``devel`` から選択されることはありません)。" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:48 -msgid "The following example is for illustrative purposes only. See the :ref:`ansible_core_roadmaps` for accurate dates. For example, the ``milestone`` branch in 2.13 ``ansible-core`` roadmap updated as follows:" -msgstr "以下は説明のための例です。正確な日付は、:ref:`ansible_core_roadmaps` を参照してください。たとえば、2.13 ``ansible-core`` ロードマップの ``milestone`` は以下のように更新されます。" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:50 -msgid "27-Sep-2021: 2.13 Development Phase 1 begins; ``milestone`` contents are updated to 2.12.0b1 with version number set to ``2.13.0.dev0``. Automated content testing that includes version-specific ignore files (e.g., ``ignore-2.12.txt``) should copy them for the current version (e.g., ``ignore-2.13.txt``) before this point to ensure that automated sanity testing against the ``milestone`` branch will continue to pass." -msgstr "2021 年 9 月 27 日: 2.13 開発フェーズ 1 が始まり、``milestone`` の内容は 2.12.0b1 に更新され、バージョン番号は ``2.13.0.dev0`` に設定されました。バージョン固有の無視ファイルを含む自動コンテンツテスト (例:``ignore-2.12.txt``) は、この時点より前にそれを現在のバージョン用にコピーする必要があります (例:``ignore-2.13.txt``)。そうすることで、``milestone`` ブランチに対する自動健全性テストに引き続き通過します。" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:54 -msgid "13-Dec-2021: 2.13 Development Phase 2 begins; ``milestone`` contents are updated to the final commit from Development Phase 1" -msgstr "2021 年 12 月 13 日: 2.13 開発フェーズ 2 が始まります。``milestone`` の内容は開発フェーズ 1 からの最終コミットに更新されます" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:55 -msgid "14-Feb-2022: 2.13 Development Phase 3 begins; ``milestone`` contents are updated to the final commit from Development Phase 2" -msgstr "2022 年 2 月 14 日: 2.13 開発フェーズ 3 が始まります。``milestone`` の内容は開発フェーズ 2 からの最終コミットに更新されます" - -#: ../../rst/dev_guide/core_branches_and_tags.rst:56 -msgid "11-Apr-2022: ``stable-2.13`` branch created with results from Development Phase 3 and freeze. ``2.13.0b1`` is released from ``stable-2.13``. Automated content testing should continue 2.13 series testing against the new branch. The ``devel`` version number is updated to ``2.14.0.dev0``, and ``milestone`` is updated to that point." -msgstr "2022 年 4 月 11 日: 開発フェーズ 3 の結果で作成された ``stable-2.13`` ブランチとフリーズ。``2.13.0b1`` が ``stable-2.13`` からリリースされます。自動コンテンツテストは、新しいブランチに対して 2.13 シリーズのテストを継続する必要があります。``devel`` バージョン番号が ``2.14.0.dev0`` に更新され、その時点まで ``milestone`` が更新されます。" - -#: ../../rst/dev_guide/debugging.rst:5 -msgid "Debugging modules" -msgstr "モジュールのデバッグ" - -#: ../../rst/dev_guide/debugging.rst:13 -msgid "Detailed debugging steps" -msgstr "詳細なデバッグ手順" - -#: ../../rst/dev_guide/debugging.rst:15 -msgid "Ansible modules are put together as a zip file consisting of the module file and the various Python module boilerplate inside of a wrapper script. To see what is actually happening in the module, you need to extract the file from the wrapper. The wrapper script provides helper methods that let you do that." -msgstr "Ansible モジュールは、モジュールファイルとラッパースクリプト内のさまざまな Python モジュールの boilerplate で構成される zip ファイルとしてまとめて置かれます。モジュールで実際に何が発生しているかを確認するには、ラッパーからファイルを抽出する必要があります。ラッパースクリプトは、これを可能にするヘルパーメソッドを提供します。" - -#: ../../rst/dev_guide/debugging.rst:17 -msgid "The following steps use ``localhost`` as the target host, but you can use the same steps to debug against remote hosts as well. For a simpler approach to debugging without using the temporary files, see :ref:`simple debugging `." -msgstr "以下の手順では、ターゲットホストに ``localhost`` を使用していますが、同じ手順を使用してリモートホストに対してデバッグすることもできます。一時ファイルを使用せずにデバッグを行う簡単な方法は、「:ref:`簡単なデバッグ `」を参照してください。" - -#: ../../rst/dev_guide/debugging.rst:20 -msgid "Set :envvar:`ANSIBLE_KEEP_REMOTE_FILES` to ``1`` on the control host so Ansible will keep the remote module files instead of deleting them after the module finishes executing. Use the ``-vvv`` option to make Ansible more verbose. This will display the file name of the temporary module file." -msgstr "コントロールホストで :envvar:`ANSIBLE_KEEP_REMOTE_FILES` を ``1`` に設定します。これにより、Ansible はモジュール実行後も削除せずにリモートモジュールファイルを維持します。``-vvv`` オプションを使用すると、Ansible の詳細が表示されます。一時モジュールファイルのファイル名が表示されます。" - -#: ../../rst/dev_guide/debugging.rst:40 -msgid "Navigate to the temporary directory from the previous step. If the previous command was run against a remote host, connect to that host first before trying to navigate to the temporary directory." -msgstr "前の手順から一時ディレクトリーに移動します。前のコマンドがリモートホストに対して実行した場合は、最初にそのホストに接続します。一時ディレクトリーに移動する前に、そのホストに接続します。" - -#: ../../rst/dev_guide/debugging.rst:47 -msgid "Run the wrapper's ``explode`` command to turn the string into some Python files that you can work with." -msgstr "ラッパーの ``explode`` コマンドを実行して、文字列を使用可能な Python ファイルに変換します。" - -#: ../../rst/dev_guide/debugging.rst:55 -msgid "If you want to examine the wrapper file you can. It will show a small Python script with a large base64 encoded string. The string contains the module to execute." -msgstr "ラッパーファイルを調べたい場合は、小さい Python スクリプトに、大きな base64 でエンコードされた文字列が記載されます。文字列には、実行するモジュールが含まれます。" - -#: ../../rst/dev_guide/debugging.rst:57 -msgid "When you look into the temporary directory you'll see a structure like this:" -msgstr "一時ディレクトリーを確認すると、以下のような構造が表示されます。" - -#: ../../rst/dev_guide/debugging.rst:80 -msgid "``AnsiballZ_ping.py`` is the Python script with the module code stored in a base64 encoded string. It contains various helper functions for executing the module." -msgstr "``AnsiballZ_ping.py`` base64 でエンコードされた文字列に保存されたモジュールコードを含む Python スクリプトで、モジュールを実行するためのさまざまなヘルパー関数が含まれます。" - -#: ../../rst/dev_guide/debugging.rst:82 -msgid "``ping.py`` is the code for the module itself. You can modify this code to see what effect it would have on your module, or for debugging purposes." -msgstr "``ping.py`` は、モジュール自体のコードです。このコードを変更して、モジュールまたはデバッグの目的を確認することができます。" - -#: ../../rst/dev_guide/debugging.rst:84 -msgid "The ``args`` file contains a JSON string. The string is a dictionary containing the module arguments and other variables that Ansible passes into the module to change its behavior. Modify this file to change the parameters passed to the module." -msgstr "``args`` ファイルには JSON 文字列が含まれています。この文字列は、モジュール引数および、Ansible がモジュールに渡すその他の変数を含むディクショナリーで、動作を変更します。このファイルを変更して、モジュールに渡されるパラメーターを変更します。" - -#: ../../rst/dev_guide/debugging.rst:86 -msgid "The ``ansible`` directory contains the module code in ``modules`` as well as code from :mod:`ansible.module_utils` that is used by the module. Ansible includes files for any :mod:`ansible.module_utils` imports in the module but not any files from any other module. If your module uses :mod:`ansible.module_utils.url` Ansible will include it for you. But if your module includes `requests `_, then you'll have to make sure that the Python `requests library `_ is installed on the system before running the module." -msgstr "``ansible`` ディレクトリーには、``modules`` のモジュールコードと、モジュールに使用される :mod:`ansible.module_utils` のコードが含まれています。Ansible には、モジュール内の :mod:`ansible.module_utils` インポートのファイルが含まれますが、他のモジュールからのファイルは含まれません。モジュールで :mod:`ansible.module_utils.url` が使用される場合は、Ansible にそれが含まれます。ただし、モジュールに `requests `_ が含まれる場合は、モジュールを実行する前に Python `requests library `_ がシステムにインストールされていることを確認する必要があります。" - -#: ../../rst/dev_guide/debugging.rst:88 -msgid "You can modify files in this directory if you suspect that the module is having a problem in some of this boilerplate code rather than in the module code you have written." -msgstr "作成したモジュールコードではなく、モジュールのこの boilerplate コードの一部に問題があると思われる場合は、このディレクトリーのファイルを変更できます。" - -#: ../../rst/dev_guide/debugging.rst:90 -msgid "Once you edit the code or arguments in the exploded tree, use the ``execute`` subcommand to run it:" -msgstr "展開されたツリーのコードまたは引数を編集したら、``execute`` サブコマンドを使用してこれを実行します。" - -#: ../../rst/dev_guide/debugging.rst:97 -msgid "This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works by using the ``ansible`` or ``ansible-playbook``." -msgstr "このサブコマンドは、``sys.path`` の最初の項目として ``debug_dir`` に絶対パスを挿入し、``args`` ファイルの引数を使用してスクリプトを呼び出します。問題を把握するまで、このようにモジュールの実行を継続できます。次に、変更を実際のモジュールファイルにコピーし、実際のモジュールが ``ansible`` または ``ansible-playbook`` で動作することをテストすることができます。" - -#: ../../rst/dev_guide/debugging.rst:103 -msgid "Simple debugging" -msgstr "簡単なデバッグ" - -#: ../../rst/dev_guide/debugging.rst:105 -msgid "The easiest way to run a debugger in a module, either local or remote, is to use `epdb `_. Add ``import epdb; epdb.serve()`` in the module code on the control node at the desired break point. To connect to the debugger, run ``epdb.connect()``. See the `epdb documentation `_ for how to specify the ``host`` and ``port``. If connecting to a remote node, make sure to use a port that is allowed by any firewall between the control node and the remote node." -msgstr "モジュール (ローカルまたはリモートのいずれか) でデバッガーを実行する最も簡単な方法は、`epdb `_ を使用します。任意のブレークポイントで、コントロールノードのモジュールコードに ``import epdb; epdb.serve()`` を追加します。デバッガーに接続するには、``epdb.connect()`` を実行します。``host`` および ``port`` を指定する方法は、`epdb ドキュメント `_ を参照してください。リモートノードに接続する場合は、コントロールノードとリモートノードとの間のファイアウォールが許可されているポートを使用するようにしてください。" - -#: ../../rst/dev_guide/debugging.rst:107 -msgid "This technique should work with any remote debugger, but we do not guarantee any particular remote debugging tool will work." -msgstr "この手法はリモートデバッガーと動作しますが、特定のリモートデバッグツールが機能する保証はありません。" - -#: ../../rst/dev_guide/debugging.rst:109 -msgid "The `q `_ library is another very useful debugging tool." -msgstr "`q `_ ライブラリーは、もう 1 つの便利なデバッグツールです。" - -#: ../../rst/dev_guide/debugging.rst:111 -msgid "Since ``print()`` statements do not work inside modules, raising an exception is a good approach if you just want to see some specific data. Put ``raise Exception(some_value)`` somewhere in the module and run it normally. Ansible will handle this exception, pass the message back to the control node, and display it." -msgstr "``print()`` ステートメントはモジュール内では機能しないため、特定のデータを確認する場合は例外を発生させます。モジュール内のどこかに ``raise Exception(some_value)`` を置き、通常どおり実行します。Ansible はこの例外を処理し、メッセージをコントロールノードに渡し、表示します。" - -#: ../../rst/dev_guide/developing_api.rst:5 -msgid "Python API" -msgstr "Python API" - -#: ../../rst/dev_guide/developing_api.rst:7 -#: ../../rst/dev_guide/developing_inventory.rst:17 -#: ../../rst/dev_guide/developing_modules_best_practices.rst:9 -#: ../../rst/dev_guide/testing_httptester.rst:7 -#: ../../rst/dev_guide/testing_integration.rst:9 -#: ../../rst/dev_guide/testing_sanity.rst:9 -#: ../../rst/dev_guide/testing_units.rst:14 -#: ../../rst/dev_guide/testing_units_modules.rst:11 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/dev_guide/developing_api.rst:9 -msgid "This API is intended for internal Ansible use. Ansible may make changes to this API at any time that could break backward compatibility with older versions of the API. Because of this, external use is not supported by Ansible. If you want to use Python API only for executing playbooks or modules, consider `ansible-runner `_ first." -msgstr "この API は、内部 Ansible の使用を目的としています。Ansible は、古いバージョンの API との後方互換性を妨げる可能性がある時点でこの API に変更を加えることができるため、Ansible では外部の使用はサポートされません。Playbook またはモジュールの実行のみに Python API を使用する場合は、まず `ansible-runner `_ を考慮してください。" - -#: ../../rst/dev_guide/developing_api.rst:11 -msgid "There are several ways to use Ansible from an API perspective. You can use the Ansible Python API to control nodes, you can extend Ansible to respond to various Python events, you can write plugins, and you can plug in inventory data from external data sources. This document gives a basic overview and examples of the Ansible execution and playbook API." -msgstr "API パースペクティブから Ansible を使用する方法は複数あります。Ansible Python API を使用してノードを制御し、Ansible を拡張してさまざまな Python イベントに応答でき、プラグインを作成したり、外部データソースからのインベントリーデータへのプラグインを行うことができます。本書では、Ansible の実行および Playbook API の基本的な概要と例を紹介します。" - -#: ../../rst/dev_guide/developing_api.rst:16 -msgid "If you would like to use Ansible programmatically from a language other than Python, trigger events asynchronously, or have access control and logging demands, please see the `AWX project `_." -msgstr "Python 以外の言語で Ansible を使用して、イベントを非同期的にトリガーするか、アクセス制御およびログ要求をする場合は、「`AWX プロジェクト `_」を参照してください。" - -#: ../../rst/dev_guide/developing_api.rst:19 -msgid "Because Ansible relies on forking processes, this API is not thread safe." -msgstr "Ansible はプロセスのフォークに依存しているため、この API はスレッドセーフではありません。" - -#: ../../rst/dev_guide/developing_api.rst:24 -msgid "Python API example" -msgstr "Python API の例" - -#: ../../rst/dev_guide/developing_api.rst:26 -msgid "This example is a simple demonstration that shows how to minimally run a couple of tasks:" -msgstr "この例は、いくつかのタスクを最小限に実行する方法を示す簡単なデモです。" - -#: ../../rst/dev_guide/developing_api.rst:31 -msgid "Ansible emits warnings and errors through the display object, which prints directly to stdout, stderr and the Ansible log." -msgstr "Ansible は、表示オブジェクトを介して警告とエラーを出力します。標準出力 (stdout)、標準エラー (stderr)、Ansible ログに直接出力します。" - -#: ../../rst/dev_guide/developing_api.rst:33 -msgid "The source code for the ``ansible`` command line tools (``lib/ansible/cli/``) is `available on GitHub `_." -msgstr "``ansible`` コマンドラインツールのソースコード (``lib/ansible/cli/``) は `GitHub で利用 `_ できます。" - -#: ../../rst/dev_guide/developing_api.rst:38 -#: ../../rst/dev_guide/developing_plugins.rst:546 -#: ../../rst/dev_guide/sidecar.rst:93 -msgid ":ref:`developing_inventory`" -msgstr ":ref:`developing_inventory`" - -#: ../../rst/dev_guide/developing_api.rst:39 -msgid "Developing dynamic inventory integrations" -msgstr "動的インベントリー統合の開発" - -#: ../../rst/dev_guide/developing_api.rst:41 -msgid "Getting started on developing a module" -msgstr "モジュール開発を始める" - -#: ../../rst/dev_guide/developing_api.rst:42 -#: ../../rst/dev_guide/developing_core.rst:17 -#: ../../rst/dev_guide/developing_inventory.rst:507 -msgid ":ref:`developing_plugins`" -msgstr ":ref:`developing_plugins`" - -#: ../../rst/dev_guide/developing_api.rst:43 -#: ../../rst/dev_guide/developing_inventory.rst:508 -msgid "How to develop plugins" -msgstr "プラグインの開発方法" - -#: ../../rst/dev_guide/developing_api.rst:44 -#: ../../rst/dev_guide/developing_inventory.rst:511 -#: ../../rst/dev_guide/testing_units_modules.rst:579 -msgid "`Development Mailing List `_" -msgstr "`Development Mailing List `_" - -#: ../../rst/dev_guide/developing_api.rst:45 -#: ../../rst/dev_guide/developing_inventory.rst:512 -#: ../../rst/dev_guide/testing_units_modules.rst:580 -msgid "Mailing list for development topics" -msgstr "開発トピックのメーリングリスト" - -#: ../../rst/dev_guide/developing_api.rst:46 -#: ../../rst/dev_guide/developing_collections.rst:48 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:81 -#: ../../rst/dev_guide/developing_collections_contributing.rst:64 -#: ../../rst/dev_guide/developing_collections_creating.rst:60 -#: ../../rst/dev_guide/developing_collections_distributing.rst:405 -#: ../../rst/dev_guide/developing_collections_migrating.rst:135 -#: ../../rst/dev_guide/developing_collections_shared.rst:93 -#: ../../rst/dev_guide/developing_collections_structure.rst:292 -#: ../../rst/dev_guide/developing_collections_testing.rst:98 -#: ../../rst/dev_guide/developing_inventory.rst:513 -#: ../../rst/dev_guide/developing_modules.rst:50 -#: ../../rst/dev_guide/developing_plugins.rst:552 -#: ../../rst/dev_guide/sidecar.rst:99 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/dev_guide/developing_api.rst:47 -#: ../../rst/dev_guide/developing_collections.rst:49 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:82 -#: ../../rst/dev_guide/developing_collections_contributing.rst:65 -#: ../../rst/dev_guide/developing_collections_creating.rst:61 -#: ../../rst/dev_guide/developing_collections_distributing.rst:406 -#: ../../rst/dev_guide/developing_collections_migrating.rst:136 -#: ../../rst/dev_guide/developing_collections_shared.rst:94 -#: ../../rst/dev_guide/developing_collections_structure.rst:293 -#: ../../rst/dev_guide/developing_collections_testing.rst:99 -#: ../../rst/dev_guide/developing_inventory.rst:514 -#: ../../rst/dev_guide/developing_modules.rst:51 -#: ../../rst/dev_guide/developing_plugins.rst:553 -#: ../../rst/dev_guide/sidecar.rst:100 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/dev_guide/developing_collections.rst:11 -msgid "Developing new collections" -msgstr "新規コレクションの開発" - -#: ../../rst/dev_guide/developing_collections.rst:21 -msgid "Working with existing collections" -msgstr "既存コレクションの使用" - -#: ../../rst/dev_guide/developing_collections.rst:29 -msgid "Collections references" -msgstr "コレクションの参照" - -#: ../../rst/dev_guide/developing_collections.rst:5 -msgid "Developing collections" -msgstr "コレクションの開発" - -#: ../../rst/dev_guide/developing_collections.rst:7 -msgid "Collections are a distribution format for Ansible content. You can package and distribute playbooks, roles, modules, and plugins using collections. A typical collection addresses a set of related use cases. For example, the ``cisco.ios`` collection automates management of Cisco IOS devices." -msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して Playbook、ロール、モジュール、およびプラグインをパッケージ化および分散できます。一般的なコレクションでは、関連する一連のユースケースに対応します。たとえば、``cisco.ios`` コレクションは Cisco IOS デバイスの管理を自動化します。" - -#: ../../rst/dev_guide/developing_collections.rst:9 -msgid "You can create a collection and publish it to `Ansible Galaxy `_ or to a private Automation Hub instance. You can publish certified collections to the Red Hat Automation Hub, part of the Red Hat Ansible Automation Platform." -msgstr "コレクションを作成して、`Ansible Galaxy `_ またはプライベート Automation Hub インスタンスに公開できます。Red Hat Ansible Automation Platform の一部である認定コレクションを Red Hat Automation Hub に公開できます。" - -#: ../../rst/dev_guide/developing_collections.rst:36 -msgid "For instructions on developing modules, see :ref:`developing_modules_general`." -msgstr "モジュール開発の手順は、「:ref:`developing_modules_general`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections.rst:41 -msgid "Learn how to install and use collections in playbooks and roles" -msgstr "Playbook およびロールでコレクションをインストールして使用する方法を説明します。" - -#: ../../rst/dev_guide/developing_collections.rst:42 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:77 -#: ../../rst/dev_guide/developing_collections_contributing.rst:60 -#: ../../rst/dev_guide/developing_collections_migrating.rst:131 -#: ../../rst/dev_guide/developing_collections_shared.rst:89 -#: ../../rst/dev_guide/developing_collections_structure.rst:288 -#: ../../rst/dev_guide/developing_collections_testing.rst:94 -msgid ":ref:`contributing_maintained_collections`" -msgstr ":ref:`contributing_maintained_collections`" - -#: ../../rst/dev_guide/developing_collections.rst:43 -#: ../../rst/dev_guide/developing_collections_changelogs.rst:78 -#: ../../rst/dev_guide/developing_collections_contributing.rst:61 -#: ../../rst/dev_guide/developing_collections_migrating.rst:132 -#: ../../rst/dev_guide/developing_collections_shared.rst:90 -#: ../../rst/dev_guide/developing_collections_structure.rst:289 -#: ../../rst/dev_guide/developing_collections_testing.rst:95 -msgid "Guidelines for contributing to selected collections" -msgstr "選択したコレクションに貢献するガイドライン" - -#: ../../rst/dev_guide/developing_collections.rst:44 -msgid "`Ansible Collections Overview and FAQ `_" -msgstr "`Ansible Collections Overview and FAQ `_" - -#: ../../rst/dev_guide/developing_collections.rst:45 -msgid "Current development status of community collections and FAQ" -msgstr "コミュニティーコレクションおよび FAQ の現在の開発ステータス" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:5 -msgid "Generating changelogs and porting guide entries in a collection" -msgstr "コレクションで変更ログおよび移植ガイドエントリーの生成" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:7 -msgid "You can create and share changelog and porting guide entries for your collection. If your collection is part of the Ansible Community package, we recommend that you use the `antsibull-changelog `_ tool to generate Ansible-compatible changelogs. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release." -msgstr "コレクションの変更ログおよび移植ガイドを作成して共有できます。コレクションが Ansible Community パッケージの一部である場合は、`antsibull-changelog `_ ツールを使用して Ansible 互換の変更ログを生成することが推奨されます。Ansible の変更ログでは、このツールを使用して、このツールの出力を使用して、Ansible リリースに含まれるすべてのコレクションを、このリリースに対して 1 つの変更ログにまとめることが推奨されます。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:11 -msgid "Ansible here refers to the Ansible 2.10 or later release that includes a curated set of collections." -msgstr "Ansible は、指定したコレクションセットを含む Ansible 2.10 以降のリリースを参照します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:18 -msgid "Understanding antsibull-changelog" -msgstr "antsibull-changelog について" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:20 -msgid "The ``antsibull-changelog`` tool allows you to create and update changelogs for Ansible collections that are compatible with the combined Ansible changelogs. This is an update to the changelog generator used in prior Ansible releases. The tool adds three new changelog fragment categories: ``breaking_changes``, ``security_fixes`` and ``trivial``. The tool also generates the ``changelog.yaml`` file that Ansible uses to create the combined ``CHANGELOG.rst`` file and Porting Guide for the release." -msgstr "``antsibull-changelog`` ツールを使用すると、組み合わせた Ansible の変更ログと互換性のある Ansible コレクションに対して変更ログを作成し、更新できます。これは、Ansible リリース以前で使用される変更ログジェネレーターに対する更新です。このツールは、``breaking_changes``、``security_fixes``、および ``trivial`` の 3 つの新しい変更ログフラグメントカテゴリーを追加します。このツールは、Ansible がリリースを組み合わせた ``CHANGELOG.rst`` ファイルと移植ガイドを作成するために使用する ``changelog.yaml`` ファイルも生成します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:22 -msgid "See :ref:`changelogs_how_to` and the `antsibull-changelog documentation `_ for complete details." -msgstr "詳細は、「:ref:`changelogs_how_to`」および `antsibull-changelog ドキュメント `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:26 -msgid "The collection maintainers set the changelog policy for their collections. See the individual collection contributing guidelines for complete details." -msgstr "コレクションのメンテナーは、コレクションに変更ログポリシーを設定します。詳細は、個々のコレクションの貢献ガイドラインを参照してください。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:29 -msgid "Generating changelogs" -msgstr "変更ログの生成" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:31 -msgid "To initialize changelog generation:" -msgstr "変更ログの生成を初期化するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:33 -msgid "Install ``antsibull-changelog``: :code:`pip install antsibull-changelog`." -msgstr "``antsibull-changelog`` をインストールします (:code:`pip install antsibull-changelog`)。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:34 -msgid "Initialize changelogs for your repository: :code:`antsibull-changelog init `." -msgstr "リポジトリーの変更ログを初期化します (:code:`antsibull-changelog init `)。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:35 -msgid "Optionally, edit the ``changelogs/config.yaml`` file to customize the location of the generated changelog ``.rst`` file or other options. See `Bootstrapping changelogs for collections `_ for details." -msgstr "必要に応じて、``changelogs/config.yaml`` ファイルを編集して、生成された変更ログの ``.rst`` ファイルまたはその他のオプションをカスタマイズします。詳細は、「`コレクションの変更ログのブートストラップ `_」を参照してください。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:37 -msgid "To generate changelogs from the changelog fragments you created:" -msgstr "作成した変更ログフラグメントから変更ログを生成するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:39 -msgid "Optionally, validate your changelog fragments: :code:`antsibull-changelog lint`." -msgstr "必要に応じて、変更ログフラグメントを検証します (:code:`antsibull-changelog lint`) 。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:40 -msgid "Generate the changelog for your release: :code:`antsibull-changelog release [--version version_number]`." -msgstr "リリースの変更ログ (:code:`antsibull-changelog release [--version version_number]`) を生成します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:44 -msgid "Add the ``--reload-plugins`` option if you ran the ``antsibull-changelog release`` command previously and the version of the collection has not changed. ``antsibull-changelog`` caches the information on all plugins and does not update its cache until the collection version changes." -msgstr "以前に ``antsibull-changelog release`` コマンドを実行し、コレクションのバージョンが変更されていない場合は、``--reload-plugins`` オプションを追加します。``antsibull-changelog`` はすべてのプラグインに関する情報をキャッシュし、コレクションバージョンが変更されるまでキャッシュを更新しません。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:47 -msgid "Porting Guide entries from changelog fragments" -msgstr "変更ログフラグメントの移植ガイドのエントリー" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:49 -msgid "The Ansible changelog generator automatically adds several changelog fragment categories to the Ansible Porting Guide:" -msgstr "Ansible 変更ログジェネレーターは、複数の変更ログフラグメントカテゴリーを Ansible 移植ガイドに自動的に追加します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:51 -msgid "``major_changes``" -msgstr "``major_changes``" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:52 -msgid "``breaking_changes``" -msgstr "``breaking_changes``" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:53 -msgid "``deprecated_features``" -msgstr "``deprecated_features``" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:54 -msgid "``removed_features``" -msgstr "``removed_features``" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:57 -msgid "Including collection changelogs into Ansible" -msgstr "Ansible へのコレクション changelog の追加" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:59 -msgid "If your collection is part of Ansible, use one of the following three options to include your changelog into the Ansible release changelog:" -msgstr "コレクションが Ansible の一部である場合は、以下の 3 つのオプションのいずれかを使用して、作成した changelog を、Ansible リリースの changelog に追加します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:61 -msgid "Use the ``antsibull-changelog`` tool." -msgstr "``antsibull-changelog`` ツールの使用" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:63 -msgid "If are not using this tool, include the properly formatted ``changelog.yaml`` file into your collection. See the `changelog.yaml format `_ for details." -msgstr "このツールを使用していない場合は、適切に形式化された ``changelog.yaml`` ファイルをコレクションに追加します。詳細は、「`changelog.yaml 形式 `_」を参照してください。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:65 -msgid "Add a link to own changelogs or release notes in any format by opening an issue at https://github.com/ansible-community/ansible-build-data/ with the HTML link to that information." -msgstr "この情報への HTML リンクで問題を https://github.com/ansible-community/ansible-build-data/ で開いて、任意の形式で独自の変更ログまたはリリースノートへのリンクを追加します。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:69 -msgid "For the first two options, Ansible pulls the changelog details from Galaxy so your changelogs must be included in the collection version on Galaxy that is included in the upcoming Ansible release." -msgstr "最初の 2 つのオプションの場合、Ansible は変更ログの詳細を Galaxy からプルし、変更ログを今後の Ansible リリースに含まれる Galaxy のコレクションバージョンに追加する必要があります。" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:73 -msgid ":ref:`collection_changelogs`" -msgstr ":ref:`collection_changelogs`" - -#: ../../rst/dev_guide/developing_collections_changelogs.rst:74 -msgid "Learn how to create good changelog fragments." -msgstr "適切な Changelog フラグメントの作成方法はこちらを参照してください。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:5 -msgid "Contributing to collections" -msgstr "コレクションへの貢献" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:7 -msgid "If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``). You should first check the collection repository to see if it has specific contribution guidelines. These are typically listed in the README.md or CONTRIBUTING.md files within the repository." -msgstr "既存のコレクションに機能を追加するには、バグを修正するために使用するコレクションを変更したり、コレクションのモジュールの動作を変更して、そのコレクションの git リポジトリーのクローンを作成し、ブランチに変更を加えます。コレクションへの変更を、Ansible (``source hacking/env-setup``) のローカルチェックアウトと組み合わせることができます。まず、コレクションリポジトリーを確認して、特定の貢献ガイドラインが含まれているかどうかを確認します。通常、それらはリポジトリーの README.md ファイルまたは CONTRIBUTING.md ファイルに一覧表示されます。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:11 -msgid "Contributing to a collection: community.general" -msgstr "コレクションへの貢献: community.general" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:13 -msgid "These instructions apply to collections hosted in the `ansible_collections GitHub organization `_. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it." -msgstr "これらの手順は、`ansible_collections GitHub organization `_ にホストされるコレクションに適用されます。特に GitHub でホストされていないコレクションについては、これに貢献する情報について、コレクションの ``README.md`` を確認してください。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:15 -msgid "This example uses the `community.general collection `_. To contribute to other collections in the same GitHub org, replace the folder names ``community`` and ``general`` with the namespace and collection name of a different collection." -msgstr "この例では、`community.general コレクション `_ を使用しています。同じ GitHub Org の他のコレクションに貢献するために、フォルダー名 ``community`` および ``general`` を、別のコレクションの名前空間およびコレクション名に置き換えます。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:18 -#: ../../rst/dev_guide/testing_integration.rst:59 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:20 -msgid "Include ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS`" -msgstr ":ref:`COLLECTIONS_PATHS` に ``~/dev/ansible/collections/`` を含めます" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:21 -msgid "If that path mentions multiple directories, make sure that no other directory earlier in the search path contains a copy of ``community.general``." -msgstr "そのパスで複数のディレクトリーに言及されている場合は、検索パスの前のその他のディレクトリーに ``community.general`` のコピーが含まれないようにします。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:24 -msgid "Creating a PR" -msgstr "PR の作成" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:28 -msgid "Create the directory ``~/dev/ansible/collections/ansible_collections/community``:" -msgstr "``~/dev/ansible/collections/ansible_collections/community`` ディレクトリーを作成します。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:34 -msgid "Clone `the community.general Git repository `_ or a fork of it into the directory ``general``:" -msgstr "`community.general Git レポジトリー `_ のクローンを作成するか、それを ``general`` ディレクトリーにフォークします。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:41 -msgid "If you clone from a fork, add the original repository as a remote ``upstream``:" -msgstr "フォークのクローンを作成したら、元のリポジトリーをリモートの ``upstream`` として追加します。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:48 -msgid "Create a branch and commit your changes on the branch." -msgstr "ブランチを作成し、ブランチで変更をコミットします。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:50 -msgid "Remember to add tests for your changes, see :ref:`testing_collections`." -msgstr "変更にテストを追加するのを忘れないようにしてください。:ref:`testing_collections` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:52 -msgid "Push your changes to your fork of the collection and create a Pull Request." -msgstr "変更をコレクションのフォークにプッシュし、プル要求を作成します。" - -#: ../../rst/dev_guide/developing_collections_contributing.rst:54 -msgid "You can test your changes by using this checkout of ``community.general`` in playbooks and roles with whichever version of Ansible you have installed locally, including a local checkout of ``ansible/ansible``'s ``devel`` branch." -msgstr "これで、``ansible/ansible`` の ``devel`` ブランチのローカルチェックアウトを含め、ローカルにインストールしたどのバージョンの Ansible でも、Playbook やロールで ``community.general`` のチェックアウトを使用して変更をテストできます。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:5 -msgid "Creating collections" -msgstr "コレクションの作成" - -#: ../../rst/dev_guide/developing_collections_creating.rst:7 -msgid "To create a collection:" -msgstr "コレクションを作成するには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:9 -msgid "Create a :ref:`collection skeleton` with the ``collection init`` command." -msgstr "``collection init`` コマンドで :ref:`コレクションスケルトン` を作成します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:10 -msgid "Add modules and other content to the collection." -msgstr "モジュールおよびその他のコンテンツをコレクションに追加します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:11 -msgid "Build the collection into a collection artifact with :ref:`ansible-galaxy collection build`." -msgstr ":ref:`ansible-galaxy collection build` を使用してコレクションをコレクションアーティファクトにビルドします。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:12 -msgid "Publish the collection artifact to Galaxy with :ref:`ansible-galaxy collection publish`." -msgstr ":ref:`ansible-galaxy collection publish` で構築したコレクションアーティファクトを Galaxy に公開します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:14 -msgid "A user can then install your collection on their systems." -msgstr "これにより、ユーザーが、そのコレクションをシステムにインストールできるようになります。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:23 -msgid "Creating a collection skeleton" -msgstr "コレクションスケルトンの作成" - -#: ../../rst/dev_guide/developing_collections_creating.rst:25 -msgid "To start a new collection, run the following command in your collections directory:" -msgstr "新しいコレクションを開始するには、コレクションディレクトリーで以下のコマンドを実行します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:33 -msgid "Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces `_ on the Galaxy docsite for those requirements." -msgstr "名前空間とコレクション名はいずれも、同じ厳密な要件セットを使用します。これらの要件については、Galaxy ドキュメントスイートの「`Galaxy 名前空間 `_」で確認してください。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:35 -msgid "It will create the structure ``[my_namespace]/[my_collection]/[collection skeleton]``." -msgstr "``[my_namespace]/[my_collection]/[collection skeleton]`` の構造を作成します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:37 -msgid "If Git is used for version control, the corresponding repository should be initialized in the collection directory." -msgstr "Git をバージョン管理に使用する場合は、対応するリポジトリーをコレクションディレクトリーで初期化する必要があります。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:39 -msgid "Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections `_ GitHub Org to get a better idea of what you can place inside a collection." -msgstr "スケルトンが存在すると、コレクション内の内容でディレクトリーを設定できます。`ansible-collections `_ の GitHub Org で、コレクションに配置できる内容を十分に理解することができます。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:41 -msgid "Reference: the ``ansible-galaxy collection`` command" -msgstr "参照: ``ansible-galaxy collection`` コマンド" - -#: ../../rst/dev_guide/developing_collections_creating.rst:43 -msgid "Currently the ``ansible-galaxy collection`` command implements the following sub commands:" -msgstr "現在、``ansible-galaxy collection`` コマンドは以下のサブコマンドを実装します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:45 -msgid "``init``: Create a basic collection skeleton based on the default template included with Ansible or your own template." -msgstr "``init``: Ansible に含まれるデフォルトテンプレートまたは独自のテンプレートに基づいて、基本的なコレクションのスケルトンを作成します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:46 -msgid "``build``: Create a collection artifact that can be uploaded to Galaxy or your own repository." -msgstr "``build``: Galaxy または独自のリポジトリーにアップロードできるコレクションアーティファクトを作成します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:47 -msgid "``publish``: Publish a built collection artifact to Galaxy." -msgstr "``publish``: 構築したコレクションアーティファクトを Galaxy に公開します。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:48 -msgid "``install``: Install one or more collections." -msgstr "``install``: 1 つ以上のコレクションをインストールします。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:50 -msgid "To learn more about the ``ansible-galaxy`` command-line tool, see the :ref:`ansible-galaxy` man page." -msgstr "``ansible-galaxy`` コマンドラインツールの詳細は、:ref:`ansible-galaxy` の man ページを参照してください。" - -#: ../../rst/dev_guide/developing_collections_creating.rst:56 -msgid ":ref:`collection_structure`" -msgstr ":ref:`collection_structure`" - -#: ../../rst/dev_guide/developing_collections_creating.rst:57 -msgid "Directories and files included in the collection skeleton" -msgstr "コレクションスケルトンに含まれるディレクトリーおよびファイル" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:5 -msgid "Distributing collections" -msgstr "コレクションの配布" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:7 -msgid "A collection is a distribution format for Ansible content. A typical collection contains modules and other plugins that address a set of related use cases. For example, a collection might automate administering a particular database. A collection can also contain roles and playbooks." -msgstr "コレクションとは、Ansible コンテンツのディストリビューション形式です。典型的なコレクションには、一連の関連するユースケースに対応するモジュールやその他のプラグインが含まれています。例えば、特定のデータベースの管理を自動化するコレクションなどがあります。コレクションには、ロールやPlaybookを含めることもできます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:9 -msgid "To distribute your collection and allow others to use it, you can publish your collection on one or more :term:`distribution server`. Distribution servers include:" -msgstr "コレクションを配信して他の人が使用できるようにするには、1つまたは複数の :term:`distribution server` でコレクションを公開することができます。配信サーバーには次のようなものがあります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:12 -msgid "Distribution server" -msgstr "配信サーバー" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:12 -msgid "Collections accepted" -msgstr "受け入れ可能なコレクション" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:14 -msgid "Ansible Galaxy" -msgstr "Ansible Galaxy" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:14 -msgid "All collections" -msgstr "全コレクション" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:15 -msgid ":term:`Pulp 3 Galaxy`" -msgstr ":term:`Pulp 3 Galaxy`" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:15 -msgid "All collections, supports signed collections" -msgstr "すべてのコレクション、署名付きコレクションのサポート" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:16 -msgid "Red Hat Automation Hub" -msgstr "Red Hat Automation Hub" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:16 -msgid "Only collections certified by Red Hat, supports signed collections" -msgstr "Red Hat 認定のコレクションのみが署名済みコレクションをサポート。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:17 -msgid "Privately hosted Automation Hub" -msgstr "プライベートにホストされるオートメーションハブ" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:17 -msgid "Collections authorized by the owners" -msgstr "オーナーが許可したコレクション" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:20 -msgid "Distributing collections involves four major steps:" -msgstr "コレクションを配信するには、大きく分けて4つのステップがあります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:22 -#: ../../rst/dev_guide/developing_collections_distributing.rst:34 -msgid "Initial configuration of your distribution server or servers" -msgstr "配信サーバーの初期設定" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:23 -#: ../../rst/dev_guide/developing_collections_distributing.rst:124 -msgid "Building your collection tarball" -msgstr "コレクション tarball のビルド" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:24 -#: ../../rst/dev_guide/developing_collections_distributing.rst:291 -msgid "Preparing to publish your collection" -msgstr "コレクション公開の準備" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:25 -#: ../../rst/dev_guide/developing_collections_distributing.rst:358 -msgid "Publishing your collection" -msgstr "コレクションの公開" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:36 -msgid "Configure a connection to one or more distribution servers so you can publish collections there. You only need to configure each distribution server once. You must repeat the other steps (building your collection tarball, preparing to publish, and publishing your collection) every time you publish a new collection or a new version of an existing collection." -msgstr "1つまたは複数の配信サーバーへの接続を設定し、そこでコレクションを公開できるようにします。各配信サーバーの設定は、1回だけ行う必要があります。その他の手順（コレクションのtarballのビルド、公開の準備、コレクションの公開）は、新しいコレクションまたは既存のコレクションの新しいバージョンを公開するたびに繰り返す必要があります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:38 -msgid "Create a namespace on each distribution server you want to use." -msgstr "使用する各配信サーバーの名前空間を作成します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:39 -msgid "Get an API token for each distribution server you want to use." -msgstr "使用する配信サーバーごとに API トークンを取得します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:40 -msgid "Specify the API token for each distribution server you want to use." -msgstr "使用する配信サーバーごとに API トークンを指定します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:45 -msgid "Creating a namespace" -msgstr "名前空間の作成" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:47 -msgid "You must upload your collection into a namespace on each distribution server. If you have a login for Ansible Galaxy, your Ansible Galaxy username is usually also an Ansible Galaxy namespace." -msgstr "コレクションを各配信サーバーの名前空間にアップロードする必要があります。Ansible Galaxyにログインアカウントがある場合、Ansible Galaxyのユーザー名は通常、Ansible Galaxyの名前空間でもあります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:51 -msgid "Namespaces on Ansible Galaxy cannot include hyphens. If you have a login for Ansible Galaxy that includes a hyphen, your Galaxy username is not also a Galaxy namespace. For example, ``awesome-user`` is a valid username for Ansible Galaxy, but it is not a valid namespace." -msgstr "Ansible Galaxyの名前空間には、ハイフンを含めることができません。ハイフンを含むAnsible Galaxyのログインアカウントがある場合、Galaxyのユーザー名はGalaxyの名前空間ではありません。たとえば、``awesome-user`` は、Ansible Galaxy の有効なユーザー名ですが、有効な名前空間ではありません。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:53 -msgid "You can create additional namespaces on Ansible Galaxy if you choose. For Red Hat Automation Hub and private Automation Hub you must create a namespace before you can upload your collection. To create a namespace:" -msgstr "必要に応じて、Ansible Galaxy で追加の名前空間を作成できます。Red Hat Automation Hub およびプライベートのオートメーションハブの場合、コレクションをアップロードする前に名前空間を作成する必要があります。名前空間を作成するには、以下の手順を実施します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:55 -msgid "To create a namespace on Galaxy, see `Galaxy namespaces `_ on the Galaxy docsite for details." -msgstr "Galaxy で名前空間を作成するには、Galaxy ドキュメントサイトで「`Galaxy namespaces `_」を参照して詳細を確認してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:56 -msgid "To create a namespace on Red Hat Automation Hub, see the `Ansible Certified Content FAQ `_." -msgstr "Red Hat Automation Hub で名前空間を作成するには、`Ansible Certified Content FAQ `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:58 -msgid "Specify the namespace in the :file:`galaxy.yml` file for each collection. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`." -msgstr "コレクションごとに :file:`galaxy.yml` ファイルで名前空間を指定します。:file:`galaxy.yml` ファイルの詳細については、:ref:`collections_galaxy_meta` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:63 -msgid "Getting your API token" -msgstr "API トークンの取得" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:65 -msgid "An API token authenticates your connection to each distribution server. You need a separate API token for each distribution server. Use the correct API token to connect to each distribution server securely and protect your content." -msgstr "APIトークンは、各配信サーバーに対してコレクションを認証します。APIトークンは、各配信サーバーごとに必要となります。正しいAPIトークンを使用して、各配信サーバーに安全に接続し、コンテンツを保護してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:67 -msgid "To get your API token:" -msgstr "API トークンを取得するには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:69 -msgid "To get an API token for Galaxy, go to the `Galaxy profile preferences `_ page and click :guilabel:`API Key`." -msgstr "GalaxyのAPIトークンを取得するには、`Galaxy profile preferences `_ ページに移動し、:guilabel:`API Key` をクリックします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:70 -msgid "To get an API token for Automation Hub, go to `the token page `_ and click :guilabel:`Load token`." -msgstr "Automation HubのAPIトークンを取得するには、`the token page `_ に移動し、:guilabel:`Load token` をクリックします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:75 -msgid "Specifying your API token and distribution server" -msgstr "APIトークンと配信サーバーの指定" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:77 -msgid "Each time you publish a collection, you must specify the API token and the distribution server to create a secure connection. You have two options for specifying the token and distribution server:" -msgstr "コレクションを公開するたびに、APIトークンと配信サーバーを指定して、安全な接続を行う必要があります。トークンと配信サーバーの指定には2つのオプションがあります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:79 -msgid "You can configure the token in configuration, as part of a ``galaxy_server_list`` entry in your :file:`ansible.cfg` file. Using configuration is the most secure option." -msgstr "トークンの設定は、コンフィギュレーションで、 :file:`ansible.cfg` ファイルの``galaxy_server_list`` エントリの一部として行うことができます。コンフィギュレーションを使用することは、最も安全なオプションです。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:80 -msgid "You can pass the token at the command line as an argument to the ``ansible-galaxy`` command. If you pass the token at the command line, you can specify the server at the command line, by using the default setting, or by setting the server in configuration. Passing the token at the command line is insecure, because typing secrets at the command line may expose them to other users on the system." -msgstr "トークンは、``ansible-galaxy`` コマンドの引数として、コマンドラインで渡すことができます。コマンドラインでトークンを渡す場合、デフォルト設定を使用して、またはコンフィグレーションでサーバーを設定して、コマンドラインでサーバーを指定することができます。コマンドラインでトークンを渡すことは安全ではありません。なぜなら、コマンドラインでシークレットを入力すると、システムの他のユーザーにシークレットが漏れる可能性があるからです。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:85 -msgid "Specifying the token and distribution server in configuration" -msgstr "コンフィギュレーションでのトークンと配信サーバーの指定" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:87 -msgid "By default, Ansible Galaxy is configured as the only distribution server. You can add other distribution servers and specify your API token or tokens in configuration by editing the ``galaxy_server_list`` section of your :file:`ansible.cfg` file. This is the most secure way to manage authentication for distribution servers. Specify a URL and token for each server. For example:" -msgstr "デフォルトでは、Ansible Galaxyが唯一の配信サーバーとして設定されています。:file:`ansible.cfg` ファイルの``galaxy_server_list`` セクションを編集することで、他の配信サーバーを追加し、API トークンをコンフィグレーションで指定することができます。これは、配信サーバーの認証を管理する最も安全な方法です。各サーバーのURLとトークンを指定します。例えば、以下のようになります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:98 -msgid "You cannot use ``apt-key`` with any servers defined in your :ref:`galaxy_server_list `. See :ref:`galaxy_server_config` for complete details." -msgstr "``apt-key`` は、:ref:`galaxy_server_list ` で定義されているサーバーと一緒に使用することはできません。詳細は:ref:`galaxy_server_config` をご覧ください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:103 -msgid "Specifying the token at the command line" -msgstr "コマンドラインでのトークンの指定" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:105 -msgid "You can specify the API token at the command line using the ``--token`` argument of the :ref:`ansible-galaxy` command. There are three ways to specify the distribution server when passing the token at the command line:" -msgstr "APIトークンをコマンドラインで指定するには、:ref:`ansible-galaxy` コマンドの``--token`` 引数を使用します。コマンドラインでトークンを渡す際の配信サーバーの指定方法は3とおりあります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:107 -msgid "using the ``--server`` argument of the :ref:`ansible-galaxy` command" -msgstr ":ref:`ansible-galaxy` コマンドの``--server`` 引数の使用" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:108 -msgid "relying on the default (https://galaxy.ansible.com)" -msgstr "デフォルトへの依存 (https://galaxy.ansible.com)" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:109 -msgid "setting a server in configuration by creating a :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file" -msgstr ":file:`ansible.cfg` ファイルへの :ref:`GALAXY_SERVER` 設定の作成によるコンフィギュレーションでのサーバーの設定" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:111 -#: ../../rst/dev_guide/style_guide/index.rst:224 -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:10 -msgid "For example:" -msgstr "例:" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:119 -msgid "Using the ``--token`` argument is insecure. Passing secrets at the command line may expose them to others on the system." -msgstr "``--token`` 引数の使用は安全ではありません。コマンドラインでシークレットを渡すと、システムの他のユーザーにシークレットが漏れる可能性があります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:126 -msgid "After configuring one or more distribution servers, build a collection tarball. The collection tarball is the published artifact, the object that you upload and other users download to install your collection. To build a collection tarball:" -msgstr "1つまたは複数の配信サーバーを設定した後、コレクションのtarballをビルドします。コレクションのtarballは、公開されたアーティファクトであり、お客様がアップロードし、他のユーザーがコレクションをインストールするためにダウンロードするオブジェクトです。コレクションのtarballをビルドするには、以下の手順で行います。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:128 -msgid "Review the version number in your :file:`galaxy.yml` file. Each time you publish your collection, it must have a new version number. You cannot make changes to existing versions of your collection on a distribution server. If you try to upload the same collection version more than once, the distribution server returns the error ``Code: conflict.collection_exists``. Collections follow semantic versioning rules. For more information on versions, see :ref:`collection_versions`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`." -msgstr ":file:`galaxy.yml` ファイルのバージョン番号を確認してください。コレクションを公開するたびに、新しいバージョン番号が必要になります。配信サーバー上のコレクションの既存バージョンを変更することはできません。同じコレクションのバージョンを複数回アップロードしようとすると、配信サーバーはエラー``Code: conflict.collection_exists`` を返します。コレクションは、セマンティックバージョニングルールに従います。バージョンの詳細については、:ref:`collection_versions` を参照してください。:file:`galaxy.yml` ファイルの詳細については、:ref:`collections_galaxy_meta` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:129 -msgid "Run ``ansible-galaxy collection build`` from inside the top-level directory of the collection. For example:" -msgstr "コレクションの最上位ディレクトリの中から``ansible-galaxy collection build`` を実行します。例えば、以下のようになります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:135 -msgid "This command builds a tarball of the collection in the current directory, which you can upload to your selected distribution server:" -msgstr "このコマンドにより、現在のディレクトリーにコレクションの tarball がビルドされます。これを希望する配信サーバーにアップロードできます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:146 -msgid "To reduce the size of collections, certain files and folders are excluded from the collection tarball by default. See :ref:`ignoring_files_and_folders_collections` if your collection directory contains other files you want to exclude." -msgstr "コレクションのサイズを小さくするために、デフォルトではコレクションのtarballから特定のファイルやフォルダが除外されています。コレクションディレクトリに除外したい他のファイルがある場合は、:ref:`ignoring_files_and_folders_collections` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:147 -msgid "The current Galaxy maximum tarball size is 2 MB." -msgstr "現在の Galaxy の tarball の最大サイズは 2 MB です。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:149 -msgid "You can upload your tarball to one or more distribution servers. You can also distribute your collection locally by copying the tarball to install your collection directly on target systems." -msgstr "tarballは、1つまたは複数の配信サーバーにアップロードすることができます。また、コレクションをローカルに配布するには、tarballをコピーしてターゲットシステムにコレクションを直接インストールします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:155 -msgid "Ignoring files and folders" -msgstr "ファイルやフォルダーを無視する" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:157 -msgid "You can exclude files from your collection with either :ref:`build_ignore ` or :ref:`manifest_directives`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`." -msgstr ":ref:`build_ignore ` または :ref:`manifest_directives` のいずれかを使用してコレクションからファイルを除外できます。:file:`galaxy.yml` ファイルの詳細は、 :ref:`collections_galaxy_meta` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:163 -msgid "Include all, with explicit ignores" -msgstr "明示的に無視してすべてを含める" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:165 -msgid "By default the build step includes all the files in the collection directory in the tarball except for the following:" -msgstr "デフォルトでは、ビルドステップでは、tarball内のコレクションディレクトリにある、以下を除くすべてのファイルが含まれます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:167 -msgid "``galaxy.yml``" -msgstr "``galaxy.yml``" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:168 -msgid "``*.pyc``" -msgstr "``*.pyc``" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:169 -msgid "``*.retry``" -msgstr "``*.retry``" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:170 -msgid "``tests/output``" -msgstr "``tests/output``" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:171 -msgid "previously built tarballs in the root directory" -msgstr "ルートディレクトリーに以前にビルドされたtarball" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:172 -msgid "various version control directories such as ``.git/``" -msgstr "``.git/`` などのさまざまなバージョン管理ディレクトリー" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:174 -msgid "To exclude other files and folders from your collection tarball, set a list of file glob-like patterns in the ``build_ignore`` key in the collection's ``galaxy.yml`` file. These patterns use the following special characters for wildcard matching:" -msgstr "コレクションのtarballから他のファイルおよびディレクトリーを除外するには、コレクションの ``galaxy.yml`` ファイルの ``build_ignore`` キーに、ファイルグロブのようなパターンの一覧を設定します。これらのパターンはワイルドカードの一致に以下の特殊文字を使用します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:176 -msgid "``*``: Matches everything" -msgstr "``*``: すべてに一致します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:177 -msgid "``?``: Matches any single character" -msgstr "``?``: 任意の単一文字に一致します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:178 -msgid "``[seq]``: Matches any character in sequence" -msgstr "``[seq]``:任意の連続した文字に一致します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:179 -msgid "``[!seq]``:Matches any character not in sequence" -msgstr "``[!seq]``:連続していない任意の文字に一致します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:181 -msgid "For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well any ``.tar.gz`` archives, set the following in your ``galaxy.yml`` file:" -msgstr "たとえば、``playbooks`` ディレクトリー内の :file:`sensitive` ディレクトリーや ``.tar.gz`` アーカイブを除外する場合は、``galaxy.yml`` ファイルに以下を設定します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:190 -msgid "The ``build_ignore`` feature is only supported with ``ansible-galaxy collection build`` in Ansible 2.10 or newer." -msgstr "``build_ignore`` 機能は、Ansible 2.10 以降の``ansible-galaxy collection build`` でのみサポートされています。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:196 -msgid "Manifest Directives" -msgstr "マニフェストディレクティブ" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:200 -msgid "The :file:`galaxy.yml` file supports manifest directives that are historically used in Python packaging, as described in `MANIFEST.in commands `_." -msgstr ":file:`galaxy.yml` ファイルは、`MANIFEST.in commands `_ で説明されているように、Python パッケージでこれまで使用されていたマニフェストディレクティブをサポートします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:203 -msgid "The use of ``manifest`` requires installing the optional ``distlib`` Python dependency." -msgstr "``manifest`` を使用するには、オプションの ``distlib`` Python 依存関係をインストールする必要があります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:206 -msgid "The ``manifest`` feature is only supported with ``ansible-galaxy collection build`` in ``ansible-core`` 2.14 or newer, and is mutually exclusive with ``build_ignore``." -msgstr "``manifest`` 機能は、``ansible-core`` 2.14 以降の ``ansible-galaxy collection build`` でのみサポートされ、``build_ignore`` と合わせて使用できません。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:208 -msgid "For example, to exclude the :file:`sensitive` folder within the ``playbooks`` folder as well as any ``.tar.gz`` archives, set the following in your :file:`galaxy.yml` file:" -msgstr "たとえば、``playbooks`` ディレクトリー内の :file:`sensitive` ディレクトリーや ``.tar.gz`` アーカイブを除外する場合は、:file:`galaxy.yml` ファイルに以下を設定します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:217 -msgid "By default, the ``MANIFEST.in`` style directives would exclude all files by default, but there are default directives in place. Those default directives are described below. To see the directives in use during build, pass ``-vvv`` with the ``ansible-galaxy collection build`` command." -msgstr "デフォルトでは、``MANIFEST.in`` スタイルのディレクティブはデフォルトですべてのファイルを除外しますが、デフォルトのディレクティブが配置されています。これらのデフォルトのディレクティブについて以下で説明します。ビルド時に使用するディレクティブを表示するには、``ansible-galaxy collection build`` コマンドで ``-vvv`` を指定します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:251 -msgid "``--*.tar.gz`` is expanded with the actual ``namespace`` and ``name``." -msgstr "``--*.tar.gz`` は、実際の ``namespace`` および ``name`` で展開されます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:253 -msgid "The ``manifest.directives`` supplied in :file:`galaxy.yml` are inserted after the default includes and before the default excludes." -msgstr ":file:`galaxy.yml` で指定される ``manifest.directives`` は、デフォルトの includes およびデフォルトの excludes の前に挿入されます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:255 -msgid "To enable the use of manifest directives without supplying your own, insert either ``manifest: {}`` or ``manifest: null`` in the :file:`galaxy.yml` file and remove any use of ``build_ignore``." -msgstr "独自のディレクティブを指定せずにマニフェストディレクティブを使用できるようにするには、：file:`galaxy.yml` ファイルに ``manifest: {}`` または ``manifest: null`` を挿入し、使用されている ``build_ignore`` を削除します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:257 -msgid "If the default manifest directives do not meet your needs, you can set ``manifest.omit_default_directives`` to a value of ``true`` in :file:`galaxy.yml`. You then must specify a full compliment of manifest directives in :file:`galaxy.yml`. The defaults documented above are a good starting point." -msgstr "デフォルトのマニフェストディレクティブが要件に合わない場合には、:file:`galaxy.yml` で ``manifest.omit_default_directives`` の値を ``true`` に指定できます。次に :file:`galaxy.yml` で完全に補完したマニフェストディレクティブを指定する必要があります。出発点として、上記に記載されているようにデフォルトを使用することが適切です。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:259 -msgid "Below is an example where the default directives are not included." -msgstr "以下は、デフォルトのディレクティブが含まれていない例です。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:276 -msgid "Signing a collection" -msgstr "コレクションの署名" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:278 -msgid "You can include a GnuPG signature with your collection on a :term:`Pulp 3 Galaxy` server. See `Enabling collection signing `_ for details." -msgstr ":term:`Pulp 3 Galaxy` のご使用のコレクションに GnuPG署名を追加できます。詳細は、`Enabling collection signing `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:280 -msgid "You can manually generate detached signatures for a collection using the ``gpg`` CLI using the following step. This step assume you have generated a GPG private key, but do not cover this process." -msgstr "以下の手順の ``gpg`` CLI を使用してコレクションのデタッチされた署名を手動で生成できます。この手順では GPG 秘密鍵を生成していることを前提としていますが、このプロセスについては説明しません。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:293 -msgid "Each time you publish your collection, you must create a :ref:`new version ` on the distribution server. After you publish a version of a collection, you cannot delete or modify that version. To avoid unnecessary extra versions, check your collection for bugs, typos, and other issues locally before publishing:" -msgstr "コレクションを公開するたびに、配信サーバーに:ref:`new version ` を作成する必要があります。コレクションのあるバージョンを公開した後は、そのバージョンを削除したり変更したりすることはできません。不要な追加バージョンを避けるために、コレクションを公開する前にローカルでバグやタイプミスなどの問題をチェックしてください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:295 -msgid "Install the collection locally." -msgstr "コレクションをローカルにインストールします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:296 -msgid "Review the locally installed collection before publishing a new version." -msgstr "新しいバージョンを公開する前に、ローカルにインストールされているコレクションを確認してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:299 -msgid "Installing your collection locally" -msgstr "コレクションのローカルインストール" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:301 -msgid "You have two options for installing your collection locally:" -msgstr "コレクションをローカルにインストールするには、2つの方法があります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:303 -msgid "Install your collection locally from the tarball." -msgstr "コレクションをtarballからローカルにインストールする。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:304 -msgid "Install your collection locally from your git repository." -msgstr "gitリポジトリからコレクションをローカルにインストールする。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:307 -msgid "Installing your collection locally from the tarball" -msgstr "tarballからのコレクションのローカルインストール" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:309 -msgid "To install your collection locally from the tarball, run ``ansible-galaxy collection install`` and specify the collection tarball. You can optionally specify a location using the ``-p`` flag. For example:" -msgstr "コレクションをtarballからローカルにインストールするには、``ansible-galaxy collection install`` を実行し、コレクションのtarballを指定します。オプションで``-p`` フラグを使って場所を指定することもできます。例えば、以下のようになります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:315 -msgid "Install the tarball into a directory configured in :ref:`COLLECTIONS_PATHS` so Ansible can easily find and load the collection. If you do not specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`." -msgstr "Ansibleがコレクションを簡単に見つけてロードできるように、:ref:`COLLECTIONS_PATHS` で設定したディレクトリにtarballをインストールします。パスの値を指定しない場合、``ansible-galaxy collection install`` は、:ref:`COLLECTIONS_PATHS` で定義された最初のパスにコレクションをインストールします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:320 -msgid "Installing your collection locally from a git repository" -msgstr "git リポジトリーからのコレクションのローカルインストール" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:322 -msgid "To install your collection locally from a git repository, specify the repository and the branch you want to install:" -msgstr "コレクションをgitリポジトリからローカルにインストールするには、インストールしたいリポジトリとブランチを指定します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 -msgid "You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet." -msgstr "コレクションは、Galaxy または Automation Hub の代わりに git リポジトリーからインストールできます。開発者は、git リポジトリーからインストールし、tarball を作成してコレクションを公開する前にコレクションを確認できます。ユーザーとして git リポジトリーからインストールすることで、Galaxy または Automation Hub にないコレクションまたはバージョンを使用できます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:3 -msgid "The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection." -msgstr "リポジトリーには ``galaxy.yml`` または ``MANIFEST.json`` ファイルが含まれている必要があります。このファイルは、コレクションのバージョン番号、namespace などのメタデータを提供します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:6 -msgid "Installing a collection from a git repository at the command line" -msgstr "コマンドガイドで git リポジトリーからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:8 -msgid "To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). You can specify a branch, commit, or tag using the comma-separated `git commit-ish `_ syntax." -msgstr "git リポジトリーからコレクションをインストールするには、コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーの URI を使用します。ユーザー``git``でSSH認証を使用していない限り、プレフィックス``git+``を使用します(例: ``git@github.com:ansible-collections/ansible.windows.git``)。コンマ区切りの `git コミットのような `_ 構文を使用して、ブランチ、コミット、またはタグを指定できます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:25 -msgid "Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere." -msgstr "認証情報を git URI に埋め込むことは安全ではありません。安全な認証オプションを使用して、認証情報がログに公開されないようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 -msgid "Use `SSH `_ authentication" -msgstr "`SSH `_ 認証を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:28 -msgid "Use `netrc `_ authentication" -msgstr "`netrc `_ 認証を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:29 -msgid "Use `http.extraHeader `_ in your git configuration" -msgstr "お使いの git 設定で `http.extraHeader `_ を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:30 -msgid "Use `url..pushInsteadOf `_ in your git configuration" -msgstr "お使いの git 設定で `url..pushInsteadOf `_ を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:33 -msgid "Specifying the collection location within the git repository" -msgstr "git リポジトリー内でのコレクションの場所の指定" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:35 -msgid "When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files:" -msgstr "git リポジトリーからコレクションをインストールする場合、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルを使用してコレクションを構築します。デフォルトでは、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルの 2 つのパスを検索します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:37 -msgid "The top level of the repository." -msgstr "リポジトリーのトップレベル。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 -msgid "Each directory in the repository path (one level deep)." -msgstr "リポジトリーパス内の各ディレクトリー（1 レベルの深さ）" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:40 -msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection." -msgstr "``galaxy.yml`` または ``MANIFEST.json`` ファイルがリポジトリーのトップレベルにある場合、Ansible はそのファイル内のコレクションメタデータを使用して個別のコレクションをインストールします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:51 -msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default:" -msgstr "リポジトリーパス内の 1 つ以上のディレクトリーに ``galaxy.yml`` または ``MANIFEST.json`` ファイルが存在する場合は、Ansible はメタデータファイルを持つ各ディレクトリーをコレクションとしてインストールします。たとえば、Ansible は、デフォルトで、このリポジトリー構造から collection1 と collection2 の両方をインストールします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:69 -msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections:" -msgstr "リポジトリ構造が異なる場合、またはコレクションのサブセットのみをインストールする場合は、URI の末尾（オプションのコンマ区切りバージョンの前）にフラグメントを追加して、メタデータファイルの場所を示すことができます。パスは、メタデータファイル自体ではなく、ディレクトリである必要があります。たとえば、2つのコレクションを持つサンプルリポジトリからcollection2のみをインストールするには、次のようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:75 -msgid "In some repositories, the main directory corresponds to the namespace:" -msgstr "リポジトリーによっては、メインのディレクトリーは名前空間に対応します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:97 -msgid "You can install all collections in this repository, or install one collection from a specific commit:" -msgstr "このリポジトリーのすべてのコレクションをインストールするか、特定のコミットから 1 つのコレクションをインストールできます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:331 -msgid "Reviewing your collection" -msgstr "コレクションの確認" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:333 -msgid "Review the collection:" -msgstr "コレクションを確認します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:335 -msgid "Run a playbook that uses the modules and plugins in your collection. Verify that new features and functionality work as expected. For examples and more details see :ref:`Using collections `." -msgstr "コレクションのモジュールやプラグインを使用するPlaybookを実行します。新しい機能が期待通りに動作するかどうかを検証します。例や詳細については、:ref:`Using collections ` をご覧ください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:336 -msgid "Check the documentation for typos." -msgstr "ドキュメントに誤字脱字がないか確認します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:337 -msgid "Check that the version number of your tarball is higher than the latest published version on the distribution server or servers." -msgstr "tarballのバージョン番号が、配信サーバーで公開されている最新のバージョンよりも高いことを確認してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:338 -msgid "If you find any issues, fix them and rebuild the collection tarball." -msgstr "問題が見つかった場合は、それを修正してコレクションのtarballを再ビルドします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:343 -msgid "Understanding collection versioning" -msgstr "コレクションのバージョニングについて" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:345 -msgid "The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) is the version displayed everywhere in Galaxy and Automation Hub. Users can still download older versions." -msgstr "コレクションを変更する唯一の方法は、新しいバージョンをリリースすることです。(最大バージョン番号による) コレクションの最新バージョンは、Galaxy およびAutomation Hubのあらゆる場所に表示されるバージョンになります。ユーザーは、古いバージョンを引き続きダウンロードできます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:347 -msgid "Follow semantic versioning when setting the version for your collection. In summary:" -msgstr "コレクションのバージョンを設定する際は、セマンティックバージョニングに従ってください。要約すると、以下のとおりです。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:349 -msgid "Increment the major version number, ``x`` of ``x.y.z``, for an incompatible API change." -msgstr "互換性のない API 変更の場合:メジャーバージョンのバージョン番号 (例: ``x.y.z`` の ``x``) を増やします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:350 -msgid "Increment the minor version number, ``y`` of ``x.y.z``, for new functionality in a backwards compatible manner (for example new modules/plugins, parameters, return values)." -msgstr "下位互換性のある新機能（例えば、新しいモジュール/プラグイン、パラメータ、戻り値など）の場合:マイナーバージョン番号（``x.y.z`` の``y``）を増やします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:351 -msgid "Increment the patch version number, ``z`` of ``x.y.z``, for backwards compatible bug fixes." -msgstr "後方互換性のあるバグ修正の場合:パッチのバージョン番号（``x.y.z`` の``z``）を増やします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:353 -msgid "Read the official `Semantic Versioning `_ documentation for details and examples." -msgstr "詳細や例については、`Semantic Versioning `_の公式ドキュメントをお読みください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:360 -msgid "The last step in distributing your collection is publishing the tarball to Ansible Galaxy, Red Hat Automation Hub, or a privately hosted Automation Hub instance. You can publish your collection in two ways:" -msgstr "コレクションを配布する最後のステップは、Ansible Galaxy、Red Hat Automation Hub、またはプライベートにホストされているオートメーションハブインスタンスに tarball を公開することです。コレクションの公開には2つの方法があります。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:362 -msgid "from the command line using the ``ansible-galaxy collection publish`` command" -msgstr "コマンドラインから（``ansible-galaxy collection publish`` コマンドの使用）" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:363 -msgid "from the website of the distribution server (Galaxy, Automation Hub) itself" -msgstr "配信サーバー（Galaxy、Automation Hub）自体のWebサイトから" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:369 -msgid "Publishing a collection from the command line" -msgstr "コマンドラインからのコレクションの公開" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:371 -msgid "To upload the collection tarball from the command line using ``ansible-galaxy``:" -msgstr "``ansible-galaxy`` を使って、コマンドラインからコレクションの tarball をアップロードするには、以下のコマンドを実行します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:379 -msgid "This ansible-galaxy command assumes you have retrieved and stored your API token in configuration. See :ref:`galaxy_specify_token` for details." -msgstr "このansible-galaxyコマンドは、APIトークンを取得してコンフィグレーションに保存していることを前提としています。詳細は:ref:`galaxy_specify_token` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:381 -msgid "The ``ansible-galaxy collection publish`` command triggers an import process, just as if you uploaded the collection through the Galaxy website. The command waits until the import process completes before reporting the status back. If you want to continue without waiting for the import result, use the ``--no-wait`` argument and manually look at the import progress in your `My Imports `_ page." -msgstr "``ansible-galaxy collection publish`` コマンドは、Galaxy の Web サイトでコレクションをアップロードしているのと同様に、インポートプロセスを発生させます。コマンドは、ステータスを報告する前にインポートプロセスが完了するまで待ちます。インポート結果を待たずに続行する場合は、``--no-wait`` 引数を使用して、`My Imports `_ ページで手動でインポートの進行状況を確認します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:386 -msgid "Publishing a collection from the website" -msgstr "Web サイトからのコレクションの公開" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:388 -msgid "To publish your collection directly on the Galaxy website:" -msgstr "コレクションを Galaxy の Web サイトに直接公開するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:390 -msgid "Go to the `My Content `_ page, and click the **Add Content** button on one of your namespaces." -msgstr "`My Content `_ ページに移動し、名前空間のいずれかの **コンテンツを追加** ボタンをクリックします。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:391 -msgid "From the **Add Content** dialogue, click **Upload New Collection**, and select the collection archive file from your local filesystem." -msgstr "**コンテンツの追加** ダイアログから、**新規コレクションのアップロード** をクリックして、ローカルファイルシステムからコレクションのアーカイブファイルを選択します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:393 -msgid "When you upload a collection, Ansible always uploads the tarball to the namespace specified in the collection metadata in the ``galaxy.yml`` file, no matter which namespace you select on the website. If you are not an owner of the namespace specified in your collection metadata, the upload request fails." -msgstr "コレクションをアップロードする際、Web サイトで選択した名前空間に関係なく、Ansibleは``galaxy.yml`` ファイルのコレクションメタデータで指定された名前空間にtarballをアップロードします。コレクションメタデータで指定された名前空間の所有者でない場合、アップロードリクエストは失敗します。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:395 -msgid "After Galaxy uploads and accepts a collection, the website shows you the **My Imports** page. This page shows import process information. You can review any errors or warnings about your upload there." -msgstr "Galaxyがコレクションをアップロードして受理すると、Web サイトでは**My Imports**ページが表示されます。このページには、インポートプロセス情報が表示されます。ここでは、アップロードに関するエラーや警告を確認することができます。" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:401 -msgid ":ref:`collections_galaxy_meta`" -msgstr ":ref:`collections_galaxy_meta`" - -#: ../../rst/dev_guide/developing_collections_distributing.rst:402 -msgid "Table of fields used in the :file:`galaxy.yml` file" -msgstr ":file:`galaxy.yml` ファイルで使用されるフィールドの表" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:5 -msgid "Documenting collections" -msgstr "コレクションの文書化" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:8 -msgid "Documenting modules and plugins" -msgstr "ドキュメントのモジュールおよびプラグイン" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:10 -msgid "Documenting modules is thoroughly documented in :ref:`module_documenting`. Plugins can be documented the same way as modules, that is with ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN`` blocks." -msgstr "モジュールの文書化については、:ref:`module_documenting` で詳しく説明しています。プラグインはモジュールと同じように記載されています (``DOCUMENTATION``、``EXAMPLES`` および ``RETURN`` のブロック)。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:13 -msgid "Documenting roles" -msgstr "ロールの文書化" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:15 -msgid "To document a role, you have to add a role argument spec by creating a file ``meta/argument_specs.yml`` in your role. See :ref:`role_argument_spec` for details. As an example, you can look at `the argument specs file `_ of the :ref:`sensu.sensu_go.install role ` on GitHub." -msgstr "ロールを文書化するには、ロールに ``meta/argument_specs.yml`` ファイルを作成してロールの引数仕様を追加する必要があります。詳細は :ref:`role_argument_spec` を参照してください。例として、GitHub で :ref:`sensu.sensu_go.install role ` の `the argument specs file `_ を確認できます。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:20 -msgid "Build a docsite with antsibull-docs" -msgstr "antsibull-docs を使用したドキュメントサイトの構築" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:22 -msgid "You can use `antsibull-docs `_ to build a Sphinx-based docsite for your collection:" -msgstr "`antsibull-docs `_ を使用して、コレクションの Sphinx ベースのドキュメントサイトを構築できます。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:24 -msgid "Create your collection and make sure you can use it with ansible-core by adding it to your :ref:`COLLECTIONS_PATHS`." -msgstr "コレクションを作成して、:ref:`COLLECTIONS_PATHS` に追加し、ansible-core で使用できます。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:25 -msgid "Create a directory ``dest`` and run ``antsibull-docs sphinx-init --use-current --dest-dir dest namespace.name``, where ``namespace.name`` is the name of your collection." -msgstr "ディレクトリー ``dest`` を作成し、``antsibull-docs sphinx-init --use-current --dest-dir dest namespace.name`` を実行します。ここで、``namespace.name`` はコレクションの名前に置き換えます。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:26 -msgid "Go into ``dest`` and run ``pip install -r requirements.txt``. You might want to create a venv and activate it first to avoid installing this globally." -msgstr "``dest`` にアクセスし、``pip install -r requirements.txt`` を実行します。これをグローバルにインストールしないように、最初に venv を作成し、アクティベートすることもできます。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:27 -msgid "Then run ``./build.sh``." -msgstr "次に、``./build.sh`` を実行します。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:28 -msgid "Open ``build/html/index.html`` in a browser of your choice." -msgstr "任意のブラウザーで ``build/html/index.html`` を開きます。" - -#: ../../rst/dev_guide/developing_collections_documenting.rst:30 -msgid "If you want to add additional documentation to your collection next to the plugin, module, and role documentation, see :ref:`collections_doc_dir`." -msgstr "プラグイン、モジュール、およびロールのドキュメントの横にあるコレクションにドキュメントを追加する場合は、:ref:`collections_doc_dir` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:5 -msgid "Migrating Ansible content to a different collection" -msgstr "Ansible コンテンツのコレクションへの移行" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:7 -msgid "When you move content from one collection to another, for example to extract a set of related modules out of ``community.general`` to create a more focused collection, you must make sure the transition is easy for users to follow." -msgstr "あるコレクションから別のコレクションにコンテンツを移動する場合 (たとえば、関連するモジュールセットを ``community.general`` から抽出して、より重点的に集中化したコレクションを作成するには)、ユーザーが簡単に移行できるようにする必要があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:14 -msgid "Migrating content" -msgstr "コンテンツの移行" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:16 -msgid "Before you start migrating content from one collection to another, look at `Ansible Collection Checklist `_." -msgstr "あるコレクションから別のコレクションにコンテンツの移行を開始する前に、`Ansible コレクションチェックリスト `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:18 -msgid "To migrate content from one collection to another, if the collections are parts of `Ansible distribution `_:" -msgstr "コレクションが `Ansible ディストリビューション `_ の一部である場合、コレクションを別のコレクションに移行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:20 -msgid "Copy content from the source (old) collection to the target (new) collection." -msgstr "ソース (以前の) コレクションからターゲット (新しい) コレクションにコンテンツをコピーします。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:21 -msgid "Deprecate the module/plugin with ``removal_version`` scheduled for the next major version in ``meta/runtime.yml`` of the old collection. The deprecation must be released after the copied content has been included in a release of the new collection." -msgstr "古いコレクションの ``meta/runtime.yml`` の次のメジャーバージョンに予定されている ``removal_version`` でモジュール/プラグインが非推奨になりました。コピーされたコンテンツが新しいコレクションのリリースにあった後に、非推奨がリリースする必要があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:22 -msgid "When the next major release of the old collection is prepared:" -msgstr "古いコレクションの次のメジャーリリースが準備されている場合は、以下のようになります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:24 -msgid "remove the module/plugin from the old collection" -msgstr "古いコレクションからモジュール/プラグインを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:25 -msgid "remove the symlink stored in ``plugin/modules`` directory if appropriate (mainly when removing from ``community.general`` and ``community.network``)" -msgstr "必要に応じて、``plugin/modules`` ディレクトリーに保存されたシンボリックリンクを削除します (主に ``community.general`` および ``community.network``から削除する場合)。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:26 -msgid "remove related unit and integration tests" -msgstr "関連するユニットテストおよび統合テストを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:27 -msgid "remove specific module utils" -msgstr "特定のモジュールユーティリティーを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:28 -msgid "remove specific documentation fragments if there are any in the old collection" -msgstr "古いコレクションにある場合は、特定のドキュメントフラグメントを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:29 -msgid "add a changelog fragment containing entries for ``removed_features`` and ``breaking_changes``; you can see an example of a changelog fragment in this `pull request `_" -msgstr "``removed_features`` および ``breaking_changes`` のエントリーを含む変更ログフラグメントを追加します。この `プル要求 `_ で変更ログフラグメントの例を確認できます。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:30 -msgid "change ``meta/runtime.yml`` in the old collection:" -msgstr "古いコレクションの ``meta/runtime.yml`` を変更します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:32 -msgid "add ``redirect`` to the corresponding module/plugin's entry" -msgstr "対応するモジュール/プラグインのエントリーに ``redirect`` を追加します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:33 -msgid "in particular, add ``redirect`` for the removed module utils and documentation fragments if applicable" -msgstr "特に、削除されたモジュールユーティリティーおよびドキュメントフラグメント (該当する場合) に ``redirect`` を追加します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:34 -msgid "remove ``removal_version`` from there" -msgstr "そこから ``removal_version`` を削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:35 -msgid "remove related entries from ``tests/sanity/ignore.txt`` files if exist" -msgstr "``tests/sanity/ignore.txt`` ファイルから関連エントリーが存在する場合は削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:36 -msgid "remove changelog fragments for removed content that are not yet part of the changelog (in other words, do not modify `changelogs/changelog.yaml` and do not delete files mentioned in it)" -msgstr "変更ログの一部ではない削除されたコンテンツの変更ログフラグメントを削除します (つまり、`changelogs/changelog.yaml` を変更せず、そのファイルに記述されているファイルを削除しないでください)。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:37 -msgid "remove requirements that are no longer required in ``tests/unit/requirements.txt``, ``tests/requirements.yml`` and ``galaxy.yml``" -msgstr "``tests/unit/requirements.txt``、``tests/requirements.yml``、および ``galaxy.yml`` ではなくなった要件を削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:39 -msgid "To implement these changes, you need to create at least three PRs:" -msgstr "以下の変更を実装するには、少なくとも 3 つの PR を作成する必要があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:41 -msgid "Create a PR against the new collection to copy the content." -msgstr "新しいコレクションに対して PR を作成し、コンテンツをコピーします。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:42 -msgid "Deprecate the module/plugin in the old collection." -msgstr "古いコレクションのモジュール/プラグインが非推奨になります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:43 -msgid "Later create a PR against the old collection to remove the content according to the schedule." -msgstr "後に、古いコレクションに対して PR を作成し、スケジュールに応じてコンテンツを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:47 -msgid "Adding the content to the new collection" -msgstr "新しいコレクションへのコンテンツの追加" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:49 -msgid "Create a PR in the new collection to:" -msgstr "新しいコレクションで PR を作成し、以下を行います。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:51 -msgid "Copy ALL the related files from the old collection." -msgstr "古いコレクションから関連ファイルをすべてコピーします。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:52 -msgid "If it is an action plugin, include the corresponding module with documentation." -msgstr "アクションプラグインの場合は、対応するモジュールとドキュメントを含めます。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:53 -msgid "If it is a module, check if it has a corresponding action plugin that should move with it." -msgstr "モジュールの場合は、対応するアクションプラグインがあり、一緒に移動する必要があるかどうかを確認します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:54 -msgid "Check ``meta/`` for relevant updates to ``runtime.yml`` if it exists." -msgstr "``meta/`` で、``runtime.yml`` に対する関連更新が存在する場合は、それを確認します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:55 -msgid "Carefully check the moved ``tests/integration`` and ``tests/units`` and update for FQCN." -msgstr "移動した ``tests/integration`` および ``tests/units`` を注意して確認し、FQCN を更新してください。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:56 -msgid "Review ``tests/sanity/ignore-*.txt`` entries in the old collection." -msgstr "古いコレクションの ``tests/sanity/ignore-*.txt`` エントリーを確認します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:57 -msgid "Update ``meta/runtime.yml`` in the old collection." -msgstr "古いコレクションの ``meta/runtime.yml`` を更新します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:61 -msgid "Removing the content from the old collection" -msgstr "古いコレクションからのコンテンツの削除" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:63 -msgid "Create a PR against the source collection repository to remove the modules, module_utils, plugins, and docs_fragments related to this migration:" -msgstr "ソースコレクションリポジトリーに対して PR を作成し、この移行に関連するモジュール、モジュールユーティリティー、プラグイン、およびドキュメントフラグメントを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:65 -msgid "If you are removing an action plugin, remove the corresponding module that contains the documentation." -msgstr "アクションプラグインを削除する場合は、ドキュメントが含まれる対応するモジュールを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:66 -msgid "If you are removing a module, remove any corresponding action plugin that should stay with it." -msgstr "モジュールを削除する場合は、モジュールに対応するアクションプラグインを削除してください。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:67 -msgid "Remove any entries about removed plugins from ``meta/runtime.yml``. Ensure they are added into the new repo." -msgstr "削除されたプラグインに関するエントリーを ``meta/runtime.yml`` から削除します。それらが新しいリポジトリーに追加されるようにしてください。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:68 -msgid "Remove sanity ignore lines from ``tests/sanity/ignore\\*.txt``" -msgstr "``tests/sanity/ignore\\*.txt`` から、sanity ignore (健常性の無視) の行を削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:69 -msgid "Remove associated integration tests from ``tests/integrations/targets/`` and unit tests from ``tests/units/plugins/``." -msgstr "関連する統合テストを ``tests/units/plugins/`` から削除し、``tests/integrations/targets/`` およびユニットテストから削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:70 -msgid "if you are removing from content from ``community.general`` or ``community.network``, remove entries from ``.github/BOTMETA.yml``." -msgstr "``community.general`` または ``community.network`` からコンテンツを削除すると、``.github/BOTMETA.yml`` からエントリーを削除します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:71 -msgid "Carefully review ``meta/runtime.yml`` for any entries you may need to remove or update, in particular deprecated entries." -msgstr "特定の非推奨のエントリーで削除または更新が必要になる可能性のあるエントリーについては、``meta/runtime.yml`` を慎重に確認してください。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:72 -msgid "Update ``meta/runtime.yml`` to contain redirects for EVERY PLUGIN, pointing to the new collection name." -msgstr "``meta/runtime.yml`` を更新して、新しいコレクション名を示す EVERY PLUGIN のリダイレクトを追加します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:76 -msgid "Maintainers for the old collection have to make sure that the PR is merged in a way that it does not break user experience and semantic versioning:" -msgstr "古いコレクションのメンテナーは、PR がユーザーエクスペリエンスとセマンティックバージョニングを壊さない方法でマージされるようにする必要があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:78 -msgid "A new version containing the merged PR must not be released before the collection the content has been moved to has been released again, with that content contained in it. Otherwise the redirects cannot work and users relying on that content will experience breakage." -msgstr "マージされた PR を含む新しいバージョンは、コンテンツが移動されたコレクションが再びリリースされる前にリリースされてはならず、そのコンテンツが含まれています。そうしないと、リダイレクトが機能せず、そのコンテンツに依存している場合は破損が発生する可能性があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:79 -msgid "Once 1.0.0 of the collection from which the content has been removed has been released, such PRs can only be merged for a new **major** version (in other words, 2.0.0, 3.0.0, and so on)." -msgstr "コンテンツが削除されたコレクションで 1.0.0 がリリースされると、この PR は新しい **メジャー** バージョン (つまり 2.0.0、3.0.0 など) のみをマージできます。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:83 -msgid "Updating BOTMETA.yml" -msgstr "BOTMETA.yml の更新" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:85 -msgid "The ``BOTMETA.yml``, for example in `community.general collection repository `_, is the source of truth for:" -msgstr "``BOTMETA.yml`` (たとえば `community.general collection repository `_) は、以下の信頼できるソースです。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:87 -msgid "ansibullbot" -msgstr "ansibullbot" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:89 -msgid "If the old and/or new collection has ``ansibullbot``, its ``BOTMETA.yml`` must be updated correspondingly." -msgstr "古いコレクションまたは新しいコレクションで ``ansibullbot`` がある場合は、それに応じて ``BOTMETA.yml`` を更新する必要があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:91 -msgid "Ansibulbot will know how to redirect existing issues and PRs to the new repo. The build process for docs.ansible.com will know where to find the module docs." -msgstr "Ansibulbot は、既存の問題と PR を新しいリポジトリーにリダイレクトする方法を認識します。docs.ansible.com のビルドプロセスは、モジュール文書の検索場所を認識します。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:110 -msgid "`Example PR `_" -msgstr "`Example PR `_" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:112 -msgid "The ``migrated_to:`` key must be added explicitly for every *file*. You cannot add ``migrated_to`` at the directory level. This is to allow module and plugin webdocs to be redirected to the new collection docs." -msgstr "``migrated_to:`` キーは、*ファイル* ごとに明示的に追加する必要があります。ディレクトリーレベルで ``migrated_to`` を追加することはできません。モジュールとプラグインの Web ドキュメントを新しいコレクションにリダイレクトすることです。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:113 -msgid "``migrated_to:`` MUST be added for every:" -msgstr "以下のすべてに ``migrated_to:`` を追加する必要があります。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:115 -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "module" -msgstr "モジュール" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:116 -msgid "plugin" -msgstr "プラグイン" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:117 -#: ../../rst/dev_guide/developing_collections_structure.rst:104 -msgid "module_utils" -msgstr "モジュールユーティリティー" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:118 -msgid "contrib/inventory script" -msgstr "contrib/inventory スクリプト" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:120 -msgid "You do NOT need to add ``migrated_to`` for:" -msgstr "以下に ``migrated_to`` を追加する必要はありません。" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:122 -msgid "Unit tests" -msgstr "ユニットテスト" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:123 -#: ../../rst/dev_guide/testing_integration.rst:7 -msgid "Integration tests" -msgstr "統合テスト" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:124 -msgid "ReStructured Text docs (anything under ``docs/docsite/rst/``)" -msgstr "再構築されたテキストドキュメント (``docs/docsite/rst/`` の下すべて)" - -#: ../../rst/dev_guide/developing_collections_migrating.rst:125 -msgid "Files that never existed in ``ansible/ansible:devel``" -msgstr "``ansible/ansible:devel`` に存在しないファイル" - -#: ../../rst/dev_guide/developing_collections_shared.rst:5 -msgid "Using shared resources in collections" -msgstr "コレクションで共有リソースの使用" - -#: ../../rst/dev_guide/developing_collections_shared.rst:7 -msgid "Although developing Ansible modules contained in collections is similar to developing standalone Ansible modules, you use shared resources like documentation fragments and module utilities differently in collections. You can use documentation fragments within and across collections. You can use optional module utilities to support multiple versions of ansible-core in your collection. Collections can also depend on other collections." -msgstr "コレクションに含まれる Ansible モジュールの開発はスタンドアロンの Ansible モジュールの開発に似ていますが、コレクションではドキュメントフラグメントやモジュールユーティリティーなどの共有リソースを異なる方法で使用します。コレクション内およびコレクション間でドキュメントフラグメントを使用できます。任意のモジュールユーティリティーを使用して、コレクション内の複数のバージョンの ansible-core をサポートできます。コレクションが他のコレクションに依存することもあります。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:16 -msgid "Using documentation fragments in collections" -msgstr "コレクションでのドキュメントフラグメントの使用" - -#: ../../rst/dev_guide/developing_collections_shared.rst:18 -msgid "To include documentation fragments in your collection:" -msgstr "コレクションにドキュメントフラグメントを含めるには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:20 -msgid "Create the documentation fragment: ``plugins/doc_fragments/fragment_name``." -msgstr "ドキュメントフラグメントを作成します (``plugins/doc_fragments/fragment_name``)。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:22 -msgid "Refer to the documentation fragment with its FQCN." -msgstr "FQCN を含むドキュメントフラグメントを参照してください。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:32 -msgid ":ref:`module_docs_fragments` covers the basics for documentation fragments. The `kubernetes.core `_ collection includes a complete example." -msgstr ":ref:`module_docs_fragments` は、ドキュメントフラグメントの基本を説明します。`kubernetes.core `_ コレクションには完全な例が含まれています。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:34 -msgid "If you use FQCN, you can use documentation fragments from one collection in another collection." -msgstr "FQCN を使用する場合は、別のコレクションで 1 つのコレクションからドキュメントフラグメントを使用できます。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:39 -msgid "Leveraging optional module utilities in collections" -msgstr "コレクションでの任意のモジュールユーティリティーの活用" - -#: ../../rst/dev_guide/developing_collections_shared.rst:41 -msgid "Optional module utilities let you adopt the latest features from the most recent ansible-core release in your collection-based modules without breaking your collection on older Ansible versions. With optional module utilities, you can use the latest features when running against the latest versions, while still providing fallback behaviors when running against older versions." -msgstr "任意のモジュールユーティリティーを使用すると、古い Ansible バージョンのコレクションを壊すことなく、collection-base モジュールで最新の ansible-core リリースの最新機能を採用できます。任意のモジュールユーティリティーを使用すると、最新バージョンに対して実行する場合に最新の機能を利用でき、古いバージョンに対して実行する場合でもフォールバック動作を提供できます。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:43 -msgid "This implementation, widely used in Python programming, wraps optional imports in conditionals or defensive `try/except` blocks, and implements fallback behaviors for missing imports. Ansible's module payload builder supports these patterns by treating any module_utils import nested in a block (e.g., `if`, `try`) as optional. If the requested import cannot be found during the payload build, it is simply omitted from the target payload and assumed that the importing code will handle its absence at runtime. Missing top-level imports of module_utils packages (imports that are not wrapped in a block statement of any kind) will fail the module payload build, and will not execute on the target." -msgstr "この実装は Python プログラミングで広く使用され、条件または限定された `try/except` ブロックで任意のインポートをラップし、不足しているインポートのフォールバック動作を実装します。Ansible のモジュールペイロードビルダーは、ブロックでネストされた module_utils インポート (例: `if`、`try`) をオプションとして扱うことにより、これらのパターンをサポートします。ペイロードビルド時に要求されたインポートが見つからなかった場合、これはターゲットペイロードから省略され、インポートコードがランタイム時に処理されないことが仮定されます。module_utils パッケージのトップレベルのインポート (あらゆる種類のブロックステートメントでラップされていないインポート) はモジュールペイロードビルドに失敗し、ターゲットでは実行されません。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:45 -msgid "For example, the `ansible.module_utils.common.respawn` package is only available in Ansible 2.11 and higher. The following module code would fail during the payload build on Ansible 2.10 or earlier (as the requested Python module does not exist, and is not wrapped in a block to signal to the payload builder that it can be omitted from the module payload):" -msgstr "たとえば、`ansible.module_utils.common.respawn` パッケージは Ansible 2.11 以降でしか利用することができません。以下のモジュールコードは Ansible 2.10 以前でのペイロードビルド中に失敗します (要求された Python モジュールが存在せず、モジュールペイロードから省略できることをペイロードビルダーに通知するブロックにラップされていないため)。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:51 -msgid "By wrapping the import statement in a ``try`` block, the payload builder will omit the Python module if it cannot be located, and assume that the Ansible module will handle it at runtime:" -msgstr "``try`` ブロックで import ステートメントをラップすることで、ペイロードビルダーは、Python モジュールが見つからないと Python モジュールを省略し、Ansible モジュールがランタイム時に処理することを想定します。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:66 -msgid "The optional import behavior also applies to module_utils imported from collections." -msgstr "任意のインポート動作は、コレクションからインポートされたモジュールユーティリティーにも適用されます。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:71 -msgid "Listing collection dependencies" -msgstr "コレクションの依存関係の一覧表示" - -#: ../../rst/dev_guide/developing_collections_shared.rst:73 -msgid "We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. Use the :file:`meta/runtime.yml` file to set the ansible-core version that your collection depends on. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`." -msgstr "コレクションはスタンドアロンの独立したユニットとして動作し、ansible-coreにのみ依存することをお勧めします。しかし、コレクションが他のコレクションの機能に依存しなければならない場合は、コレクションの :file:`galaxy.yml` ファイルの``dependencies`` セクションに、他のコレクションをリストアップしてください。コレクションが依存する ansible-core バージョンを設定するには、:file:`meta/runtime.yml` ファイルを使用します。:file:`galaxy.yml` ファイルの詳細については、:ref:`collections_galaxy_meta` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:75 -msgid "You can use git repositories for collection dependencies during local development and testing. For example:" -msgstr "ローカルでの開発やテストの際に、コレクションの依存関係用にgitリポジトリを使用することができます。以下に例を示します。" - -#: ../../rst/dev_guide/developing_collections_shared.rst:83 -msgid "Do not use git repositories as dependencies for published collections. Dependencies for published collections must be other published collections." -msgstr "公開されたコレクションの依存関係として git リポジトリーを使用しないでください。公開されたコレクションの依存関係は、他の公開されたコレクションでなければなりません。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:5 -msgid "Collection structure" -msgstr "コレクション構造" - -#: ../../rst/dev_guide/developing_collections_structure.rst:7 -msgid "A collection is a simple data structure. None of the directories are required unless you have specific content that belongs in one of them. A collection does require a ``galaxy.yml`` file at the root level of the collection. This file contains all of the metadata that Galaxy and other tools need in order to package, build and publish the collection." -msgstr "コレクションは簡単なデータ構造です。それらの中の 1 つに属する特定のコンテンツがない限り、ディレクトリーは必要ありません。コレクションのルートレベルで ``galaxy.yml`` ファイルが必要になります。このファイルには、Galaxy やその他のツールがコレクションをパッケージ化、ビルド、公開するのに必要なメタデータがすべて含まれます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:14 -msgid "Collection directories and files" -msgstr "コレクションディレクトリーおよびファイル" - -#: ../../rst/dev_guide/developing_collections_structure.rst:16 -msgid "A collection can contain these directories and files:" -msgstr "コレクションには、これらのディレクトリーおよびファイルを含めることができます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:43 -msgid "Ansible only accepts ``.md`` extensions for the :file:`README` file and any files in the :file:`/docs` folder." -msgstr "Ansible は、:file:`README` ファイルおよび :file:`/docs` フォルダー内のすべてのファイルの ``.md`` 拡張子のみを受け入れます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:44 -msgid "See the `ansible-collections `_ GitHub Org for examples of collection structure." -msgstr "コレクション構造の例は、`ansible-collections `_ GitHub Org を参照してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:45 -msgid "Not all directories are currently in use. Those are placeholders for future features." -msgstr "現在、すべてのディレクトリーが使用されているわけではありません。これらは、将来の機能のプレースホルダーです。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:50 -msgid "galaxy.yml" -msgstr "galaxy.yml" - -#: ../../rst/dev_guide/developing_collections_structure.rst:52 -msgid "A collection must have a ``galaxy.yml`` file that contains the necessary information to build a collection artifact. See :ref:`collections_galaxy_meta` for details." -msgstr "コレクションには、コレクションアーティファクトを構築するために必要な情報が含まれる ``galaxy.yml`` ファイルが必要です。詳細は、「:ref:`collections_galaxy_meta`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:57 -msgid "docs directory" -msgstr "docs ディレクトリー" - -#: ../../rst/dev_guide/developing_collections_structure.rst:59 -msgid "Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on." -msgstr "``docs`` フォルダを使用して、コレクションが提供するロールとプラグインの使用方法、ロールの要件などを説明します。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:61 -msgid "For certified collections, Automation Hub displays documents written in markdown in the main ``docs`` directory with no subdirectories. This will not display on https://docs.ansible.com." -msgstr "認定されたコレクションでは、Automation Hubは、サブディレクトリを持たないメインの``docs`` ディレクトリにマークダウンで書かれたドキュメントを表示します。これは、https://docs.ansible.com.には表示されません。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:63 -msgid "For community collections included in the Ansible PyPI package, docs.ansible.com displays documents written in reStructuredText (.rst) in a docsite/rst/ subdirectory. Define the structure of your extra documentation in ``docs/docsite/extra-docs.yml``:" -msgstr "AnsibleのPyPIパッケージに含まれるコミュニティコレクションの場合、docs.ansible.comはreStructuredText（.rst）で書かれたドキュメントをdocsite/rst/サブディレクトリに表示します。``docs/docsite/extra-docs.yml`` で追加ドキュメントの構造を定義します。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:73 -msgid "The index page of the documentation for your collection displays the title you define in ``docs/docsite/extra-docs.yml`` with a link to your extra documentation. For an example, see the `community.docker collection repo `_ and the `community.docker collection documentation `_." -msgstr "コレクションのドキュメントのインデックスページには、``docs/docsite/extra-docs.yml`` で定義したタイトルと、追加ドキュメントへのリンクが表示されます。例としては、`community.docker collection repo `_ と`community.docker collection documentation `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:75 -msgid "You can add extra links to your collection index page and plugin pages with the ``docs/docsite/links.yml`` file. This populates the links under `Description and Communications `_ headings as well as links at the end of the individual plugin pages. See the `collection_template links.yml file `_ for a complete description of the structure and use of this file to create links." -msgstr "コレクションインデックスページおよびプラグインページに、``docs/docsite/links.yml`` ファイルを使用してリンクを追加できます。この方法で、`Description and Communications `_ の見出しの下と、個別のプラグインページの最後にリンクが追加されます。構造の詳細な説明と、ファイルを使用したリンクの作成方法については、`collection_template links.yml file `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:78 -msgid "Plugin and module documentation" -msgstr "プラグインとモジュールのドキュメント" - -#: ../../rst/dev_guide/developing_collections_structure.rst:80 -msgid "Keep the specific documentation for plugins and modules embedded as Python docstrings. Use ``ansible-doc`` to view documentation for plugins inside a collection:" -msgstr "Python ドキュメント文字列として埋め込まれたプラグインおよびモジュールに関する特定のドキュメントを保持します。コレクション内のプラグインのドキュメントを表示するには``ansible-doc`` を使用してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:86 -msgid "The ``ansible-doc`` command requires the fully qualified collection name (FQCN) to display specific plugin documentation. In this example, ``my_namespace`` is the Galaxy namespace and ``my_collection`` is the collection name within that namespace." -msgstr "特定のプラグインのドキュメントを表示するには、``ansible-doc`` コマンドに完全修飾コレクション名 (FQCN) が必要です。この例では、``my_namespace`` は Galaxy 名前空間となり、``my_collection`` はその名前空間内のコレクション名となります。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:88 -msgid "The Galaxy namespace of an Ansible collection is defined in the ``galaxy.yml`` file. It can be different from the GitHub organization or repository name." -msgstr "Ansible コレクションの Galaxy 名前空間は ``galaxy.yml`` ファイルで定義されます。GitHub の組織またはリポジトリー名とは異なる場合があります。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:93 -msgid "plugins directory" -msgstr "plugins ディレクトリー" - -#: ../../rst/dev_guide/developing_collections_structure.rst:95 -msgid "Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by most plugins by using their FQCN. This is a way to distribute modules, lookups, filters, and so on without having to import a role in every play." -msgstr "「プラグインタイプごと」の特有サブディレクトリーをここに追加します。これには、その FQCN を使用して、モジュールでだけでなくほとんどのプラグインで使用できる ``module_utils`` が含まれます。これは、すべてのプレイでロールをインポートすることなくモジュール、検索、フィルターなどを分散する方法です。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:97 -msgid "Vars plugins in collections are not loaded automatically, and always require being explicitly enabled by using their fully qualified collection name. See :ref:`enable_vars` for details." -msgstr "コレクションの vars プラグインは自動的に読み込まれず、完全修飾コレクション名を使用して常に明示的に有効にする必要があります。詳細は、:ref:`enable_vars` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:99 -msgid "Cache plugins in collections may be used for fact caching, but are not supported for inventory plugins." -msgstr "コレクションのキャッシュプラグインは、ファクトキャッシュに使用できますが、inventory プラグインではサポートされていません。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:106 -msgid "When coding with ``module_utils`` in a collection, the Python ``import`` statement needs to take into account the FQCN along with the ``ansible_collections`` convention. The resulting Python import will look like ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}``" -msgstr "コレクションで ``module_utils`` を使用してコーディングする場合、Python の ``import`` ステートメントは ``ansible_collections`` 規則とともに FQCN を考慮する必要があります。作成される Python インポートは ``from ansible_collections.{namespace}.{collection}.plugins.module_utils.{util} import {something}`` のようになります。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:108 -msgid "The following example snippets show a Python and PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``community``, the collection is ``test_collection``. In the Python example the ``module_util`` in question is called ``qradar`` such that the FQCN is ``community.test_collection.plugins.module_utils.qradar``:" -msgstr "以下のスニペットの例は、デフォルトの Ansible ``module_utils`` と、コレクションの両方を使用する Python および PowerShell モジュールを示しています。この例では、名前空間は ``community`` で、コレクションは ``test_collection`` です。Python の例では、問題の ``module_util`` は ``qradar`` と呼ばれ、FQCN が ``community.test_collection.plugins.module_utils.qradar`` となっています。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:138 -msgid "Note that importing something from an ``__init__.py`` file requires using the file name:" -msgstr "``__init__.py`` ファイルから何かをインポートする場合は、ファイル名を使用する必要があることに注意してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:144 -msgid "In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FQCN is ``community.test_collection.plugins.module_utils.hyperv``:" -msgstr "PowerShell の例では、問題の ``module_util`` は ``hyperv`` と呼ばれ、FQCN が ``community.test_collection.plugins.module_utils.hyperv`` となっています。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:166 -msgid "roles directory" -msgstr "roles ディレクトリー" - -#: ../../rst/dev_guide/developing_collections_structure.rst:168 -msgid "Collection roles are mostly the same as existing roles, but with a couple of limitations:" -msgstr "コレクションロールは既存ロールとほぼ同じですが、いくつか制限があります。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:170 -msgid "Role names are now limited to contain only lowercase alphanumeric characters, plus ``_`` and start with an alpha character." -msgstr "ロール名は、小文字の英数字と ``_`` のみを含み、英字で開始するように制限されます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:171 -msgid "Roles in a collection cannot contain plugins any more. Plugins must live in the collection ``plugins`` directory tree. Each plugin is accessible to all roles in the collection." -msgstr "コレクション内のロールにはプラグインを含めることができません。プラグインはコレクションの ``plugins`` ディレクトリーツリーで持続する必要があります。各プラグインはコレクション内のすべてのロールからアクセスできます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:173 -msgid "The directory name of the role is used as the role name. Therefore, the directory name must comply with the above role name rules. The collection import into Galaxy will fail if a role name does not comply with these rules." -msgstr "ロールのディレクトリー名はロール名として使用されます。そのため、ディレクトリー名は上記のロール名ルールに従う必要があります。Galaxy へのコレクションのインポートは、ロール名がこれらのルールに準拠していないと失敗します。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:175 -msgid "You can migrate 'traditional roles' into a collection but they must follow the rules above. You may need to rename roles if they don't conform. You will have to move or link any role-based plugins to the collection specific directories." -msgstr "「従来のロール」をコレクションに移行できますが、上記のルールに従う必要があります。遵守していない場合は、ロールの名前を変更しなければならない場合もあります。ロールベースのプラグインをコレクション固有のディレクトリーに移動するか、リンクする必要があります。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:179 -msgid "For roles imported into Galaxy directly from a GitHub repository, setting the ``role_name`` value in the role's metadata overrides the role name used by Galaxy. For collections, that value is ignored. When importing a collection, Galaxy uses the role directory as the name of the role and ignores the ``role_name`` metadata value." -msgstr "ロールが GitHub リポジトリーから Galaxy に直接インポートされた場合は、ロールのメタデータに ``role_name`` 値を設定すると、Galaxy が使用するロール名が上書きされます。コレクションの場合、この値は無視されます。コレクションをインポートすると、Galaxy はロールディレクトリーをロール名として使用し、``role_name`` メタデータの値を無視します。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:182 -msgid "playbooks directory" -msgstr "playbooks ディレクトリー" - -#: ../../rst/dev_guide/developing_collections_structure.rst:184 -msgid "In prior releases, you could reference playbooks in this directory using the full path to the playbook file from the command line. In ansible-core 2.11 and later, you can use the FQCN, ``namespace.collection.playbook`` (with or without extension), to reference the playbooks from the command line or from ``import_playbook``. This will keep the playbook in 'collection context', as if you had added ``collections: [ namespace.collection ]`` to it." -msgstr "以前のリリースでは、コマンドラインからPlaybookファイルのフルパスを使用して、このディレクトリのPlaybookを参照することができました。ansible-core 2.11以降では、FQCNである``namespace.collection.playbook`` （拡張子あり、なし）を使って、コマンドラインまたは``import_playbook`` からPlaybookを参照することができます。これにより、あたかも``collections: [ namespace.collection ]`` を追加したかのように、Playbookが「コレクションコンテキスト」に保たれます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:188 -msgid "You can have most of the subdirectories you would expect, such ``files/``, ``vars/`` or ``templates/`` but no ``roles/`` since those are handled already in the collection." -msgstr "``files/`` 、``vars/`` 、``templates/`` など、期待されるほとんどのサブディレクトリを持つことができますが、``roles/`` はコレクションですでに扱われているため、持つことはできません。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:190 -msgid "Also, playbooks within a collection follow the same guidelines as any playbooks except for these few adjustments:" -msgstr "また、コレクション内の Playbook は、次のいくつかの調整を除いて、他の Playbook と同じガイドラインに従います。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:192 -msgid "Directory: It must be in the ``playbooks/`` directory." -msgstr "ディレクトリー: ``playbooks/`` ディレクトリーになければなりません。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:193 -msgid "Hosts: The host should be defined as a variable so the users of a playbook do not mistakenly run the plays against their entire inventory (if the host is set to all). For example - ``hosts: '{{target|default(\"all\")}}'``." -msgstr "ホスト: Playbook のユーザーがインベントリー全体 (ホストがすべてに設定されている場合) に対して誤ってプレイを実行することを防止するため、ホストは変数として定義する必要があります。例: -``hosts: '{{target|default(\"all\")}}'``。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:195 -msgid "To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``docs/`` folder or ``README`` file." -msgstr "ユーザーは、``ansible-playbook --e 'targets=webservers'`` や ``ansible-playbook --limit webservers`` などのコマンドを使用してプレイを実行できるようになりました。いずれの方法でも、コレクション所有者は Playbook と、``docs/`` フォルダーまたは ``README`` ファイルでの使用方法を文書化する必要があります。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:200 -msgid "tests directory" -msgstr "tests ディレクトリー" - -#: ../../rst/dev_guide/developing_collections_structure.rst:202 -msgid "Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, by using the `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind." -msgstr "Ansible Collection は、Ansible 自体と同じように、Ansible バージョン 2.9.0 以降に同梱される `ansible-test` ユーティリティーを使用してテストされます。Ansible Collection は Ansible 自体と同じツールを使用してテストされるため、`ansible-test` を介して、テスト用のすべての Ansible 開発者向けドキュメントは、覚えておくべき 1 つの重要な概念を使用してコレクションテストを作成するために適用できます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:204 -msgid "See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``." -msgstr "``ansible-test`` でコレクションをテストする方法は、「:ref:`testing_collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:206 -msgid "When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code through a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you." -msgstr ":ref:`developing_testing` のドキュメントを読む際、Ansible 開発者の典型的な git clone を使用して、ソースコードからの Ansible の実行に適用されるコンテンツがあります。しかし、Ansible Collection の作者が Ansible をソースからではなく、安定したリリースから実行することは必ずしも一般的ではなく、Collection を作成するためには、Ansible をソースから実行する必要はありません。そのため、`ansible-test` バイナリーパス、コマンド補完、または環境変数の扱いに関する参照については、:ref:`developing_testing` ドキュメントで提示されます。Ansible Collection Testing ではこれが必要ありません。`ansible-test` を含む Ansible の安定したリリースをインストールするには、これらをセットアップすることが予想されるためです。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:211 -msgid "meta directory and runtime.yml" -msgstr "meta ディレクトリーと runtime.yml" - -#: ../../rst/dev_guide/developing_collections_structure.rst:213 -msgid "A collection can store some additional metadata in a ``runtime.yml`` file in the collection's ``meta`` directory. The ``runtime.yml`` file supports the top level keys:" -msgstr "コレクションは、コレクションの ``meta`` ディレクトリーの ``runtime.yml`` ファイルに追加のメタデータを保存できます。``runtime.yml`` ファイルは、最上位のキーをサポートします。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:215 -msgid "*requires_ansible*:" -msgstr "*requires_ansible*:" - -#: ../../rst/dev_guide/developing_collections_structure.rst:217 -msgid "The version of Ansible Core (ansible-core) required to use the collection. Multiple versions can be separated with a comma." -msgstr "コレクションを使用するために必要な Ansible Core (ansible-core)のバージョン。複数のバージョンはコンマで区切ることができます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:223 -msgid "although the version is a `PEP440 Version Specifier `_ under the hood, Ansible deviates from PEP440 behavior by truncating prerelease segments from the Ansible version. This means that Ansible 2.11.0b1 is compatible with something that ``requires_ansible: \">=2.11\"``." -msgstr "バージョンは `PEP440 バージョン指定子 `_ ですが、内部では、Ansible はプレリリースセグメントを Ansible バージョンから切り捨てることにより、PEP440 の動作から逸脱しています。これは、Ansible2.11.0b1 が ``requires_ansible: \">=2.11\"`` であるものと互換性があることを意味します。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:225 -msgid "*plugin_routing*:" -msgstr "*plugin_routing*:" - -#: ../../rst/dev_guide/developing_collections_structure.rst:227 -msgid "Content in a collection that Ansible needs to load from another location or that has been deprecated/removed. The top level keys of ``plugin_routing`` are types of plugins, with individual plugin names as subkeys. To define a new location for a plugin, set the ``redirect`` field to another name. To deprecate a plugin, use the ``deprecation`` field to provide a custom warning message and the removal version or date. If the plugin has been renamed or moved to a new location, the ``redirect`` field should also be provided. If a plugin is being removed entirely, ``tombstone`` can be used for the fatal error message and removal version or date." -msgstr "Ansible が別の場所から読み込む必要があるコレクション内のコンテンツ、もしくは非推奨となったか削除されるコレクションのコンテンツ。``plugin_routing`` の最上位のキーはプラグインのタイプで、個々のプラグイン名をサブキーとして使用します。プラグインの新しい場所を定義するには、``redirect`` フィールドを別の名前に設定します。プラグインを非推奨にするには、``deprecation`` フィールドを使用してカスタム警告メッセージと削除バージョンまたは日付を指定します。プラグインの名前が変更するか新しい場所に移動する場合は、``redirect`` フィールドも入力する必要があります。プラグインが完全に削除される場合、``tombstone`` は致命的なエラーメッセージ、および削除バージョンまたは日付に使用できます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:256 -msgid "*import_redirection*" -msgstr "*import_redirection*" - -#: ../../rst/dev_guide/developing_collections_structure.rst:258 -msgid "A mapping of names for Python import statements and their redirected locations." -msgstr "Python インポートステートメントの名前とそのリダイレクトされた場所のマッピング。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:266 -msgid "*action_groups*" -msgstr "*action_groups*" - -#: ../../rst/dev_guide/developing_collections_structure.rst:268 -msgid "A mapping of groups and the list of action plugin and module names they contain. They may also have a special 'metadata' dictionary in the list, which can be used to include actions from other groups." -msgstr "グループと、それに含まれるアクションプラグインおよびモジュール名のリストのマッピングです。また、リストの中に特別な「メタデータ」ディクショナリーを持っている場合もあり、これを使って他のグループのアクションを含めることができます。" - -#: ../../rst/dev_guide/developing_collections_structure.rst:286 -msgid ":ref:`distributing_collections`" -msgstr ":ref:`distributing_collections`" - -#: ../../rst/dev_guide/developing_collections_structure.rst:287 -msgid "Learn how to package and publish your collection" -msgstr "コレクションをパッケージ化し、公開する方法を説明します。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:5 -msgid "Testing collections" -msgstr "コレクションのテスト" - -#: ../../rst/dev_guide/developing_collections_testing.rst:7 -msgid "Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core." -msgstr "コレクションのテストにより、コードが適切に機能し、Ansible エコシステムの他の部分との統合性が向上します。コレクションでは、Ansible コードの健全性テストを渡します。また、コレクションのコードに対応するユニットテストと、コレクションと ansible-core との間の対話に対応する統合テストを追加する必要があります。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:14 -msgid "Testing tools" -msgstr "テストツール" - -#: ../../rst/dev_guide/developing_collections_testing.rst:16 -msgid "The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing` and provided by both the ``ansible`` and ``ansible-core`` packages." -msgstr "コレクションをテストする主なツールは、:ref:`developing_testing` で説明されている Ansible のテストツール ``ansible-test`` です。これは、``ansible`` パッケージと ``ansible-core`` パッケージの両方で提供されます。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:18 -msgid "You can run several sanity tests, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting." -msgstr "また、複数の健全性チェックを実行したり、``ansible-test`` を使用してプラグイン用にユニットテストや統合テストを実行できます。コレクションをテストする場合に、使用する ansible-core バージョンに対してテストすることができます。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:20 -msgid "You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Azure Pipelines both in the ansible/ansible GitHub repository and in the large community collections such as `community.general `_ and `community.network `_. The examples below demonstrate running tests in Docker containers." -msgstr "常に、コレクションのルートディレクトリーから、``ansible-test`` を実行する必要があります。特別な要件をインストールせずに Docker コンテナーの ``ansible-test`` を実行できます。Ansible チームは、ansible/ansible GitHub リポジトリーと、`community.general `_ や `community.network `_ ような大規模なコミュニティーコレクションの両方の Azure Pipeline で、このアプローチを使用します。以下の例では、Docker コンテナーでテストの実行方法を示しています。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:23 -msgid "Sanity tests" -msgstr "健全性テスト" - -#: ../../rst/dev_guide/developing_collections_testing.rst:25 -msgid "To run all sanity tests:" -msgstr "すべての健全性テストを実行する場合:" - -#: ../../rst/dev_guide/developing_collections_testing.rst:31 -msgid "See :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests ` for details on the sanity tests and how to fix identified issues." -msgstr "詳細は、:ref:`testing_sanity` を参照してください。健全性テストの詳細と、特定された問題を修正する方法は、:ref:`full list of sanity tests ` を参照してください。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:34 -msgid "Adding unit tests" -msgstr "ユニットテストの追加" - -#: ../../rst/dev_guide/developing_collections_testing.rst:36 -msgid "You must place unit tests in the appropriate ``tests/unit/plugins/`` directory. For example, you would place tests for ``plugins/module_utils/foo/bar.py`` in ``tests/unit/plugins/module_utils/foo/test_bar.py`` or ``tests/unit/plugins/module_utils/foo/bar/test_bar.py``. For examples, see the `unit tests in community.general `_." -msgstr "ユニットテストを適切な ``tests/unit/plugins/`` ディレクトリーに置く必要があります。たとえば、``tests/unit/plugins/module_utils/foo/test_bar.py`` または ``tests/unit/plugins/module_utils/foo/bar/test_bar.py`` の ``plugins/module_utils/foo/bar.py`` にテストを置きます。たとえば、`unit tests in community.general `_ を参照してください。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:38 -msgid "To run all unit tests for all supported Python versions:" -msgstr "サポートされるすべての Python バージョンに対して、すべてのユニットテストを実行するには、以下のコマンドを実行します。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:44 -msgid "To run all unit tests only for a specific Python version:" -msgstr "特定の Python バージョンに対してのみ、ユニットテストをすべて実行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:50 -msgid "To run only a specific unit test:" -msgstr "特定のユニットテストのみを実行するには、以下を実行します。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:56 -msgid "You can specify Python requirements in the ``tests/unit/requirements.txt`` file. See :ref:`testing_units` for more information, especially on fixture files." -msgstr "``tests/unit/requirements.txt`` ファイルで Python 要件を指定できます。詳細 (特にフィクスチャーファイルの詳細) は、「:ref:`testing_units`」を参照してください。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:61 -msgid "Adding integration tests" -msgstr "統合テストの追加" - -#: ../../rst/dev_guide/developing_collections_testing.rst:63 -msgid "You must place integration tests in the appropriate ``tests/integration/targets/`` directory. For module integration tests, you can use the module name alone. For example, you would place integration tests for ``plugins/modules/foo.py`` in a directory called ``tests/integration/targets/foo/``. For non-module plugin integration tests, you must add the plugin type to the directory name. For example, you would place integration tests for ``plugins/connections/bar.py`` in a directory called ``tests/integration/targets/connection_bar/``. For lookup plugins, the directory must be called ``lookup_foo``, for inventory plugins, ``inventory_foo``, and so on." -msgstr "統合テストは、適切な ``tests/integration/targets/`` ディレクトリーに置く必要があります。モジュールの統合テストでは、モジュール名だけを使用することができます。たとえば、``plugins/modules/foo.py`` の統合テストを ``tests/integration/targets/foo/`` というディレクトリーに置くことになります。モジュール以外のプラグインの統合テストでは、ディレクトリー名にプラグインタイプを追加する必要があります。たとえば、``plugins/connections/bar.py`` の統合テストは、``tests/integration/targets/connection_bar/`` というディレクトリーに置くことになります。たとえば、ルックアッププラグインの場合、ディレクトリー名は ``lookup_foo`` となり、インベントリプラグインの場合は、``inventory_foo`` となります。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:65 -msgid "You can write two different kinds of integration tests:" -msgstr "2 種類の統合テストを作成できます。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:67 -msgid "Ansible role tests run with ``ansible-playbook`` and validate various aspects of the module. They can depend on other integration tests (usually named ``prepare_bar`` or ``setup_bar``, which prepare a service or install a requirement named ``bar`` in order to test module ``foo``) to set-up required resources, such as installing required libraries or setting up server services." -msgstr "Ansible ロールテストは、``ansible-playbook`` で実行され、モジュールのさまざまな側面を検証します。これらのテストは、他の統合テスト (通常 ``prepare_bar`` または ``setup_bar`` と呼ばれ、モジュール ``foo`` をテストするためにサービスを準備したり、``bar`` という要件をインストールしたりする) に依存して、必要なライブラリーのインストールやサーバーサービスの設定など、必要なリソースを設定することができます。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:68 -msgid "``runme.sh`` tests run directly as scripts. They can set up inventory files, and execute ``ansible-playbook`` or ``ansible-inventory`` with various settings." -msgstr "``runme.sh`` テストは、直接スクリプトとして実行されます。インベントリーファイルを設定し、さまざまな設定で ``ansible-playbook`` または ``ansible-inventory`` を実行できます。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:70 -msgid "For examples, see the `integration tests in community.general `_. See also :ref:`testing_integration` for more details." -msgstr "例については、`integration tests in community.general `_ を参照してください。詳細は、:ref:`testing_integration` も参照してください。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:72 -msgid "Since integration tests can install requirements, and set-up, start and stop services, we recommended running them in docker containers or otherwise restricted environments whenever possible. By default, ``ansible-test`` supports Docker images for several operating systems. See the `list of supported docker images `_ for all options. Use the ``default`` image mainly for platform-independent integration tests, such as those for cloud modules. The following examples use the ``fedora35`` image." -msgstr "統合テストは、要件のインストールや、サービスの設定、開始、および停止を行うことができるため、可能な限り、Docker コンテナーや、制限された環境で実行することが推奨されます。デフォルトでは、``ansible-test`` は複数のオペレーティングシステムの Docker イメージをサポートします。すべてのオプションは `list of supported docker images `_ を参照してください。クラウドモジュール用などのプラットフォームに依存しない統合テストには、主に ``default`` イメージを使用します。以下の例では、``fedora35`` イメージが使用されています。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:74 -msgid "To execute all integration tests for a collection:" -msgstr "コレクションに対して統合テストをすべて実行するには、次を実行します。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:80 -msgid "If you want more detailed output, run the command with ``-vvv`` instead of ``-v``. Alternatively, specify ``--retry-on-error`` to automatically re-run failed tests with higher verbosity levels." -msgstr "より詳細な出力が必要な場合は、``-v`` ではなく、``-vvv`` でコマンドを実行します。もしくは、``--retry-on-error`` を指定して、失敗したテストを、詳細レベルをあげて自動的に再実行します。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:82 -msgid "To execute only the integration tests in a specific directory:" -msgstr "特定のディレクトリーで統合テストのみを実行するには、以下を行います。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:88 -msgid "You can specify multiple target names. Each target name is the name of a directory in ``tests/integration/targets/``." -msgstr "複数のターゲット名を指定できます。ターゲット名は ``tests/integration/targets/`` のディレクトリーの名前になります。" - -#: ../../rst/dev_guide/developing_collections_testing.rst:92 -msgid ":ref:`developing_testing`" -msgstr ":ref:`developing_testing`" - -#: ../../rst/dev_guide/developing_collections_testing.rst:93 -msgid "More resources on testing Ansible" -msgstr "Ansible のテストに関するその他のリソース" - -#: ../../rst/dev_guide/developing_core.rst:3 -msgid "Developing ``ansible-core``" -msgstr "``ansible-core`` の開発" - -#: ../../rst/dev_guide/developing_core.rst:5 -msgid "Although ``ansible-core`` (the code hosted in the `ansible/ansible repository `_ on GitHub) includes a few plugins that can be swapped out by the playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-core`` work together." -msgstr "``ansible-core`` (GitHub の `ansible/ansible repository `_ でホストされるコード) には、Playbook ディレクティブまたは設定を介してスワップできるプラグインが含まれていますが、モジュール化されないコードが多くあります。また、このドキュメントは、``ansible-core`` の一部が連携する方法に関する洞察を与えてくれます。" - -#: ../../rst/dev_guide/developing_core.rst:15 -#: ../../rst/dev_guide/developing_inventory.rst:503 -#: ../../rst/dev_guide/developing_plugins.rst:544 -#: ../../rst/dev_guide/sidecar.rst:91 -msgid ":ref:`developing_api`" -msgstr ":ref:`developing_api`" - -#: ../../rst/dev_guide/developing_core.rst:16 -#: ../../rst/dev_guide/developing_plugins.rst:545 -#: ../../rst/dev_guide/sidecar.rst:92 -msgid "Learn about the Python API for task execution" -msgstr "タスク実行用の Python API について" - -#: ../../rst/dev_guide/developing_core.rst:18 -msgid "Learn about developing plugins" -msgstr "プラグインの開発について" - -#: ../../rst/dev_guide/developing_core.rst:21 -#: ../../rst/dev_guide/style_guide/index.rst:339 -msgid "`irc.libera.chat `_" -msgstr "`irc.libera.chat `_" - -#: ../../rst/dev_guide/developing_core.rst:22 -msgid "#ansible-devel IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-devel)" - -#: ../../rst/dev_guide/developing_inventory.rst:5 -msgid "Developing dynamic inventory" -msgstr "動的インベントリーの開発" - -#: ../../rst/dev_guide/developing_inventory.rst:7 -msgid "Ansible can pull inventory information from dynamic sources, including cloud sources, by using the supplied :ref:`inventory plugins `. For details about how to pull inventory information, see :ref:`dynamic_inventory`. If the source you want is not currently covered by existing plugins, you can create your own inventory plugin as with any other plugin type." -msgstr "Ansible は、指定された :ref:`インベントリープラグイン ` を使用して、クラウドソースを含む動的ソースからインベントリー情報をプルすることができます。インベントリー情報のプル方法の詳細は、「:ref:`dynamic_inventory`」を参照してください。現在、既存のプラグインで対象としていないソースについては、他のプラグインタイプで独自のインベントリープラグインを作成できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:9 -msgid "In previous versions, you had to create a script or program that could output JSON in the correct format when invoked with the proper arguments. You can still use and write inventory scripts, as we ensured backwards compatibility through the :ref:`script inventory plugin ` and there is no restriction on the programming language used. If you choose to write a script, however, you will need to implement some features yourself such as caching, configuration management, dynamic variable and group composition, and so on. If you use :ref:`inventory plugins ` instead, you can use the Ansible codebase and add these common features automatically." -msgstr "以前のバージョンでは、適切な引数で呼び出されたときに正しい形式で JSON を出力できるスクリプトやプログラムを作成する必要がありました。:ref:`script inventory plugin ` を通じて後方互換性を確保しており、使用するプログラミング言語にも制限がないため、インベントリースクリプトを引き続き使用したり書いたりすることができます。ただし、スクリプトを書く場合は、キャッシュ、設定管理、動的な変数、グループの構成など、いくつかの機能を自分で実装する必要があります。代わりに :ref:`inventory plugins ` を使用すれば、Ansible のコードベースを使用し、これらの共通機能を自動的に追加することができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:22 -msgid "Inventory sources" -msgstr "インベントリーソース" - -#: ../../rst/dev_guide/developing_inventory.rst:24 -msgid "Inventory sources are the input strings that inventory plugins work with. An inventory source can be a path to a file or to a script, or it can be raw data that the plugin can interpret." -msgstr "インベントリーソースは、インベントリープラグインが機能する入力文字列です。インベントリーソースはファイルまたはスクリプトへのパスにするか、プラグインが解釈できる生のデータになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:27 -msgid "The table below shows some examples of inventory plugins and the source types that you can pass to them with ``-i`` on the command line." -msgstr "以下の表は、コマンドラインで ``-i`` を使用して、インベントリープラグインの例と、プラグインに渡すことができるソースタイプを示しています。" - -#: ../../rst/dev_guide/developing_inventory.rst:30 -msgid "Plugin" -msgstr "プラグイン" - -#: ../../rst/dev_guide/developing_inventory.rst:30 -msgid "Source" -msgstr "ソース" - -#: ../../rst/dev_guide/developing_inventory.rst:32 -msgid ":ref:`host list `" -msgstr ":ref:`host list `" - -#: ../../rst/dev_guide/developing_inventory.rst:32 -msgid "A comma-separated list of hosts" -msgstr "ホストのコンマ区切りリスト" - -#: ../../rst/dev_guide/developing_inventory.rst:34 -msgid ":ref:`yaml `" -msgstr ":ref:`yaml `" - -#: ../../rst/dev_guide/developing_inventory.rst:34 -msgid "Path to a YAML format data file" -msgstr "YAML 形式のデータファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:36 -msgid ":ref:`constructed `" -msgstr ":ref:`constructed `" - -#: ../../rst/dev_guide/developing_inventory.rst:36 -#: ../../rst/dev_guide/developing_inventory.rst:40 -msgid "Path to a YAML configuration file" -msgstr "YAML 設定ファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:38 -msgid ":ref:`ini `" -msgstr ":ref:`ini `" - -#: ../../rst/dev_guide/developing_inventory.rst:38 -msgid "Path to an INI formatted data file" -msgstr "INI 形式のデータファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:40 -msgid ":ref:`virtualbox `" -msgstr ":ref:`virtualbox `" - -#: ../../rst/dev_guide/developing_inventory.rst:42 -msgid ":ref:`script plugin `" -msgstr ":ref:`script plugin `" - -#: ../../rst/dev_guide/developing_inventory.rst:42 -msgid "Path to an executable that outputs JSON" -msgstr "JSON を出力する実行可能ファイルへのパス" - -#: ../../rst/dev_guide/developing_inventory.rst:49 -#: ../../rst/dev_guide/developing_plugins.rst:338 -msgid "Inventory plugins" -msgstr "inventory プラグイン" - -#: ../../rst/dev_guide/developing_inventory.rst:51 -msgid "Like most plugin types (except modules), inventory plugins must be developed in Python. They execute on the controller and should therefore adhere to the :ref:`control_node_requirements`." -msgstr "ほとんどのプラグインタイプ (モジュールを除く) と同様に、それらは Python で開発されなければなりません。コントローラー上で実行するため、「:ref:`control_node_requirements`」と同じ要件に一致させなければなりません。" - -#: ../../rst/dev_guide/developing_inventory.rst:53 -msgid "Most of the documentation in :ref:`developing_plugins` also applies here. You should read that document first for a general understanding and then come back to this document for specifics on inventory plugins." -msgstr ":ref:`developing_plugins` に関するドキュメントの多くはここでも適用されています。一般的な理解のために最初にこのドキュメントを読んでから、本ガイドで inventory プラグインの詳細を参照してください。" - -#: ../../rst/dev_guide/developing_inventory.rst:55 -msgid "Normally, inventory plugins are executed at the start of a run, and before the playbooks, plays, or roles are loaded. However, you can use the ``meta: refresh_inventory`` task to clear the current inventory and execute the inventory plugins again, and this task will generate a new inventory." -msgstr "通常、インベントリープラグインは実行の開始時、および Playbook、プレイ、またはロールが読み込まれる前に実行します。ただし、``meta: refresh_inventory`` タスクを使用して現在のインベントリーを消去してインベントリープラグインを再実行することもできます。また、このタスクは新しいインベントリーを生成します。" - -#: ../../rst/dev_guide/developing_inventory.rst:58 -msgid "If you use the persistent cache, inventory plugins can also use the configured cache plugin to store and retrieve data. Caching inventory avoids making repeated and costly external calls." -msgstr "永続キャッシュを使用する場合、inventory プラグインは設定済みの cache プラグインを使用してデータを保存および取得し、コストがかかり、繰り返しかかる外部呼び出しを回避することもできます。" - -#: ../../rst/dev_guide/developing_inventory.rst:63 -msgid "Developing an inventory plugin" -msgstr "inventory プラグインの開発" - -#: ../../rst/dev_guide/developing_inventory.rst:65 -msgid "The first thing you want to do is use the base class:" -msgstr "最初に行うのは、ベースクラスを使用することです。" - -#: ../../rst/dev_guide/developing_inventory.rst:75 -msgid "If the inventory plugin is in a collection, the NAME should be in the 'namespace.collection_name.myplugin' format. The base class has a couple of methods that each plugin should implement and a few helpers for parsing the inventory source and updating the inventory." -msgstr "inventory プラグインがコレクションにある場合、NAME は「namespace.collection_name.myplugin」形式である必要があります。このベースクラスは、各プラグインが実装する必要のあるいくつかのメソッドと、インベントリーソースを解析してインベントリーを更新するためのヘルパーがいくつかあります。" - -#: ../../rst/dev_guide/developing_inventory.rst:77 -msgid "After you have the basic plugin working, you can incorporate other features by adding more base classes:" -msgstr "基本的なプラグインが動作するようになったら、より多くの基本クラスを追加することで他の機能を組み込むことができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:87 -msgid "For the bulk of the work in a plugin, we mostly want to deal with 2 methods ``verify_file`` and ``parse``." -msgstr "プラグインでの作業の大部分では、主に 2 つのメソッド (``verify_file`` と ``parse``) を扱います。" - -#: ../../rst/dev_guide/developing_inventory.rst:92 -msgid "verify_file method" -msgstr "verify_file メソッド" - -#: ../../rst/dev_guide/developing_inventory.rst:94 -msgid "Ansible uses this method to quickly determine if the inventory source is usable by the plugin. The determination does not need to be 100% accurate, as there might be an overlap in what plugins can handle and by default Ansible will try the enabled plugins as per their sequence." -msgstr "Ansible はこのメソッドを使用して、インベントリソースがプラグインで使用可能かどうかを迅速に判断します。この判定は 100％ 正確である必要はありません。なぜなら、プラグインが処理できる内容には重複があり、デフォルトでは Ansible は有効なプラグインを順番に試していくからです。" - -#: ../../rst/dev_guide/developing_inventory.rst:107 -msgid "In the above example, from the :ref:`virtualbox inventory plugin `, we screen for specific file name patterns to avoid attempting to consume any valid YAML file. You can add any type of condition here, but the most common one is 'extension matching'. If you implement extension matching for YAML configuration files, the path suffix . should be accepted. All valid extensions should be documented in the plugin description." -msgstr "上記の例では、:ref:`virtualbox inventory プラグイン ` からは、有効な YAML ファイルの使用を試みないように、特定のファイル名パターンを切り分けます。ここに任意のタイプの条件を追加できますが、最も一般的なものは「拡張子の一致」です。YAML 設定ファイルに一致する拡張子を実装する場合は、パスサフィックス . が許可される必要があります。有効なすべての拡張機能は、プラグインの説明に記載されています。" - -#: ../../rst/dev_guide/developing_inventory.rst:109 -msgid "The following is another example that does not use a 'file' but the inventory source string itself, from the :ref:`host list ` plugin:" -msgstr "以下は、「ファイル」を使用せず、:ref:`host list ` プラグインからインベントリソース文字列自体を使用する別の例です。" - -#: ../../rst/dev_guide/developing_inventory.rst:124 -msgid "This method is just to expedite the inventory process and avoid unnecessary parsing of sources that are easy to filter out before causing a parse error." -msgstr "この方法は、inventory プロセスを迅速化し、解析エラーの原因になる前に簡単に除外できるソースの不要な解析を回避するためのものです。" - -#: ../../rst/dev_guide/developing_inventory.rst:129 -msgid "parse method" -msgstr "解析メソッド" - -#: ../../rst/dev_guide/developing_inventory.rst:131 -msgid "This method does the bulk of the work in the plugin. It takes the following parameters:" -msgstr "この方法は、プラグインの作業の大部分を行います。このメソッドは、以下のパラメーターを取ります。" - -#: ../../rst/dev_guide/developing_inventory.rst:134 -msgid "inventory: inventory object with existing data and the methods to add hosts/groups/variables to inventory" -msgstr "inventory: 既存のデータと、ホスト/グループ/変数をインベントリーに追加するメソッドがある inventory オブジェクト。" - -#: ../../rst/dev_guide/developing_inventory.rst:135 -msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto load JSON/YAML and decrypt vaulted data, and cache read files." -msgstr "loader: Ansible の DataLoader です。DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号化、および読み取りファイルのキャッシュを行うことができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:136 -msgid "path: string with inventory source (this is usually a path, but is not required)" -msgstr "path: インベントリーソースを持つ文字列 (通常、これはパスですが、必須ではありません)。" - -#: ../../rst/dev_guide/developing_inventory.rst:137 -msgid "cache: indicates whether the plugin should use or avoid caches (cache plugin and/or loader)" -msgstr "cache: プラグインがキャッシュを使用するかどうかを示します (キャッシュプラグインまたはローダー、もしくはその両方)。" - -#: ../../rst/dev_guide/developing_inventory.rst:140 -msgid "The base class does some minimal assignment for reuse in other methods." -msgstr "ベースクラスは他のメソッドで再利用するための割り当てを最小限に抑えます。" - -#: ../../rst/dev_guide/developing_inventory.rst:150 -msgid "It is up to the plugin now to parse the provided inventory source and translate it into Ansible inventory. To facilitate this, the example below uses a few helper functions:" -msgstr "提供されたインベントリーソースを解析し、それを Ansible インベントリーに変換するのは、プラグイン次第です。これを容易にするために、以下の例ではいくつかのヘルパー関数を使用しています。" - -#: ../../rst/dev_guide/developing_inventory.rst:187 -msgid "The specifics will vary depending on API and structure returned. Remember that if you get an inventory source error or any other issue, you should ``raise AnsibleParserError`` to let Ansible know that the source was invalid or the process failed." -msgstr "この状況は、API および構造の戻り値によって異なります。インベントリーソースエラーや他の問題を取得する場合は、``AnsibleParserError を発生`` させ、ソースが無効であるか、プロセスが失敗したことを Ansible に通知する必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:189 -msgid "For examples on how to implement an inventory plugin, see the source code here: `lib/ansible/plugins/inventory `_." -msgstr "インベントリープラグインの実装方法の例は、ソースコード (`lib/ansible/plugins/inventory `_) を参照してください。" - -#: ../../rst/dev_guide/developing_inventory.rst:195 -msgid "inventory object" -msgstr "インベントリーオブジェクト" - -#: ../../rst/dev_guide/developing_inventory.rst:197 -msgid "The ``inventory`` object passed to ``parse`` has helpful methods for populating inventory." -msgstr "``parse`` に渡された ``inventory`` オブジェクトには、インベントリーに入力するための便利な方法があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:199 -msgid "``add_group`` adds a group to inventory if it doesn't already exist. It takes the group name as the only positional argument." -msgstr "``add_group`` は、まだ存在しない場合にグループをインベントリーに追加します。唯一の位置引数としてグループ名を取ります。" - -#: ../../rst/dev_guide/developing_inventory.rst:201 -msgid "``add_child`` adds a group or host that exists in inventory to a parent group in inventory. It takes two positional arguments, the name of the parent group and the name of the child group or host." -msgstr "``add_child`` は、インベントリーに存在するグループまたはホストをインベントリーの親グループに追加します。2 つの位置引数 (親グループの名前と子グループまたはホストの名前) を取ります。" - -#: ../../rst/dev_guide/developing_inventory.rst:203 -msgid "``add_host`` adds a host to inventory if it doesn't already exist, optionally to a specific group. It takes the host name as the first argument and accepts two optional keyword arguments, ``group`` and ``port``. ``group`` is the name of a group in inventory, and ``port`` is an integer." -msgstr "``add_host`` は、まだ存在しない場合にホストをインベントリー (オプションで特定のグループ) に追加します。最初の引数としてホスト名を取り、オプションで 2 つのキーワード引数 (``group``と``port``) を受け入れます。``group`` はインベントリー内のグループの名前、``port`` は整数です。" - -#: ../../rst/dev_guide/developing_inventory.rst:205 -msgid "``set_variable`` adds a variable to a group or host in inventory. It takes three positional arguments: the name of the group or host, the name of the variable, and the value of the variable." -msgstr "``set_variable`` は、インベントリー内のグループまたはホストに変数を追加します。3 つの位置引数 (グループまたはホストの名前、変数の名前、変数の値) を取ります。" - -#: ../../rst/dev_guide/developing_inventory.rst:207 -msgid "To create groups and variables using Jinja2 expressions, see the section on implementing ``constructed`` features below." -msgstr "Jinja2 式を使用してグループと変数を作成する場合は、後述の ``constructed`` 機能の実装に関するセクションを参照してください。" - -#: ../../rst/dev_guide/developing_inventory.rst:209 -msgid "To see other inventory object methods, see the source code here: `lib/ansible/inventory/data.py `_." -msgstr "他のインベントリーオブジェクトメソッドを確認するには、`lib/ansible/inventory/data.py `_ でソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_inventory.rst:215 -msgid "inventory cache" -msgstr "インベントリーキャッシュ" - -#: ../../rst/dev_guide/developing_inventory.rst:217 -msgid "To cache the inventory, extend the inventory plugin documentation with the inventory_cache documentation fragment and use the Cacheable base class." -msgstr "インベントリーをキャッシュするには、インベントリープラグインのドキュメントを inventory_cache ドキュメントフラグメントで拡張し、cacheable 基本クラスを使用します。" - -#: ../../rst/dev_guide/developing_inventory.rst:230 -msgid "Next, load the cache plugin specified by the user to read from and update the cache. If your inventory plugin uses YAML-based configuration files and the ``_read_config_data`` method, the cache plugin is loaded within that method. If your inventory plugin does not use ``_read_config_data``, you must load the cache explicitly with ``load_cache_plugin``." -msgstr "次に、ユーザーが指定したキャッシュプラグインを読み込み、キャッシュの読み取りと更新を行います。インベントリープラグインが YAML ベースの構成ファイルを使用していて、``_read_config_data`` メソッドの場合、キャッシュプラグインはそのメソッド内に読み込まれます。インベントリープラグインが ``_read_config_data`` を使用しない場合は、``load_cache_plugin`` を使用してキャッシュを明示的に読み込む必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:241 -msgid "Before using the cache plugin, you must retrieve a unique cache key by using the ``get_cache_key`` method. This task needs to be done by all inventory modules using the cache, so that you don't use/overwrite other parts of the cache." -msgstr "キャッシュプラグインを使用する前に、``get_cache_key`` メソッドを使用して一意のキャッシュキーを取得する必要があります。このタスクは、キャッシュを使用するすべてのインベントリーモジュールで実行する必要があります。これにより、キャッシュの他の部分を使用/上書きしないようになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:251 -msgid "Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as by the ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching." -msgstr "これでキャッシュを有効にし、正しいプラグインを読み込み、一意のキャッシュキーを取得したことで、``parse`` メソッドの ``cache`` パラメーターを使用して、キャッシュとインベントリーの間でデータのフローを設定できるようになりました。この値は、インベントリーマネージャーから取得され、インベントリーを更新するか (例: ``--flush-cache``、メタタスク ``refresh_inventory`` など) を示します。キャッシュは、更新時にインベントリーを入力するために使用すべきではありませんが、キャッシュを有効にした場合は、キャッシュを新しいインベントリーで更新する必要があります。ディクショナリーのような ``self._cache`` を使用できます。以下のパターンを使用すると、インベントリーをキャッシュとともに動作させることができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:286 -msgid "After the ``parse`` method is complete, the contents of ``self._cache`` is used to set the cache plugin if the contents of the cache have changed." -msgstr "``parse`` メソッドが完了すると、``self._cache`` の内容は、キャッシュの内容が変更された場合にキャッシュプラグインを設定するために使用されます。" - -#: ../../rst/dev_guide/developing_inventory.rst:291 -msgid "You have three other cache methods available:" -msgstr "利用可能な 3 つのキャッシュメソッド:" - -#: ../../rst/dev_guide/developing_inventory.rst:289 -msgid "``set_cache_plugin`` forces the cache plugin to be set with the contents of ``self._cache``, before the ``parse`` method completes" -msgstr "``set_cache_plugin`` は、``parse`` メソッドの完了前に、キャッシュプラグインを ``self._cache`` の内容で強制的に設定します。" - -#: ../../rst/dev_guide/developing_inventory.rst:290 -msgid "``update_cache_if_changed`` sets the cache plugin only if ``self._cache`` has been modified, before the ``parse`` method completes" -msgstr "``update_cache_if_changed`` は、``parse`` メソッドが完了する前に ``self._cache`` が変更された場合のみキャッシュプラグインを設定します。" - -#: ../../rst/dev_guide/developing_inventory.rst:291 -msgid "``clear_cache`` flushes the cache, ultimately by calling the cache plugin's ``flush()`` method, whose implementation is dependent upon the particular cache plugin in use. Note that if the user is using the same cache backend for facts and inventory, both will get flushed. To avoid this, the user can specify a distinct cache backend in their inventory plugin configuration." -msgstr "``clear_cache`` キャッシュをフラッシュし、キャッシュプラグインの ``flush()`` メソッドを呼び出すことで、これらの実装は使用中の特定のキャッシュプラグインに依存します。ファクトとインベントリーで同じキャッシュバックエンドを使用している場合は、両方のキャッシュバックエンドをフラッシュします。これを回避するために、インベントリープラグイン設定で個別のキャッシュバックエンドを指定できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:294 -msgid "constructed features" -msgstr "constructed 機能" - -#: ../../rst/dev_guide/developing_inventory.rst:296 -msgid "Inventory plugins can create host variables and groups from Jinja2 expressions and variables by using features from the ``constructed`` inventory plugin. To do this, use the ``Constructable`` base class and extend the inventory plugin's documentation with the ``constructed`` documentation fragment." -msgstr "インベントリープラグインは、``constructed`` インベントリープラグインの機能を使用して、Jinja2 式および変数からホスト変数およびグループを作成できます。これを行うには、``Constructable`` ベースクラスを使用し、``constructed`` ドキュメントフラグメントでドキュメントを拡張することができます。" - -#: ../../rst/dev_guide/developing_inventory.rst:309 -msgid "There are three main options in the ``constructed`` documentation fragment:" -msgstr "``constructed`` ドキュメントフラグメントには、主に 3 つのオプションがあります。" - -#: ../../rst/dev_guide/developing_inventory.rst:311 -msgid "``compose`` creates variables using Jinja2 expressions. This is implemented by calling the ``_set_composite_vars`` method. ``keyed_groups`` creates groups of hosts based on variable values. This is implemented by calling the ``_add_host_to_keyed_groups`` method. ``groups`` creates groups based on Jinja2 conditionals. This is implemented by calling the ``_add_host_to_composed_groups`` method." -msgstr "``compose`` は、Jinja2 式を使用して変数を作成します。これは、``_set_composite_vars`` メソッドを呼び出すことで実装されます。``keyed_groups`` は、変数値に基づいてホストのグループを作成します。これは、``_add_host_to_keyed_groups`` メソッドを呼び出すことで実装されます。``groups`` は、Jinja2 条件に基づいてグループを作成します。これは、``_add_host_to_composed_groups`` メソッドを呼び出すことで実装されます。" - -#: ../../rst/dev_guide/developing_inventory.rst:315 -msgid "Each method should be called for every host added to inventory. Three positional arguments are required: the constructed option, a dictionary of variables, and a host name. Calling the method ``_set_composite_vars`` first will allow ``keyed_groups`` and ``groups`` to use the composed variables." -msgstr "各メソッドは、インベントリーに追加されたホストごとに呼び出す必要があります。 3 つの位置引数 (構築済みオプション、変数のディクショナリー、ホスト名) が必要です。最初に ``_set_composite_vars`` メソッドを呼び出すと、``keyed_groups`` と ``groups`` は構築済み変数を使用できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:317 -msgid "By default, undefined variables are ignored. This is permitted by default for ``compose`` so you can make the variable definitions depend on variables that will be populated later in a play from other sources. For groups, it allows using variables that are not always present without having to use the ``default`` filter. To support configuring undefined variables to be an error, pass the constructed option ``strict`` to each of the methods as a keyword argument." -msgstr "デフォルトでは、未定義の変数は無視されます。``compose`` ではデフォルトで許可されているため、後で他のソースからプレイで入力される変数に依存する変数定義を作成できます。グループの場合、``default`` フィルターを使用しなくても、常に存在するとは限らない変数を使用できます。未定義の変数をエラーにする設定をサポートするには、構築されたオプション ``strict`` をキーワード引数として各メソッドに渡します。" - -#: ../../rst/dev_guide/developing_inventory.rst:319 -msgid "``keyed_groups`` and ``groups`` use any variables already associated with the host (for example, from an earlier inventory source). ``_add_host_to_keyed_groups`` and ``add_host_to_composed_groups`` can turn this off by passing the keyword argument ``fetch_hostvars``." -msgstr "``keyed_groups`` と``groups`` は、すでにホストに関連付けられている変数を使用します (たとえば、以前のインベントリーソースから)。``_add_host_to_keyed_groups`` と ``add_host_to_composed_groups`` は、キーワード引数 ``fetch_hostvars`` を渡すことでこれをオフにできます。" - -#: ../../rst/dev_guide/developing_inventory.rst:321 -msgid "Here is an example using all three methods:" -msgstr "以下は、3 つの方法すべてを使用した例です。" - -#: ../../rst/dev_guide/developing_inventory.rst:340 -msgid "By default, group names created with ``_add_host_to_composed_groups()`` and ``_add_host_to_keyed_groups()`` are valid Python identifiers. Invalid characters are replaced with an underscore ``_``. A plugin can change the sanitization used for the constructed features by setting ``self._sanitize_group_name`` to a new function. The core engine also does sanitization, so if the custom function is less strict it should be used in conjunction with the configuration setting ``TRANSFORM_INVALID_GROUP_CHARS``." -msgstr "デフォルトでは、``_add_host_to_composed_groups()`` および ``_add_host_to_keyed_groups()`` で作成されたグループ名は有効な Python 識別子です。無効な文字はアンダースコア ``_`` に置き換えられます。プラグインは、``self._sanitize_group_name`` を新しい機能に設定することで、constructed 機能に使用されるサニタイゼーションを変更できます。コアエンジンもサニタイゼーションを実行するため、カスタム機能がそれほど厳密でない場合は、構成設定 ``TRANSFORM_INVALID_GROUP_CHARS`` と組み合わせて使用する必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:362 -msgid "Common format for inventory sources" -msgstr "インベントリーソースの共通形式" - -#: ../../rst/dev_guide/developing_inventory.rst:364 -msgid "To simplify development, most plugins use a standard YAML-based configuration file as the inventory source. The file has only one required field ``plugin``, which should contain the name of the plugin that is expected to consume the file. Depending on other common features used, you might need other fields, and you can add custom options in each plugin as required. For example, if you use the integrated caching, ``cache_plugin``, ``cache_timeout`` and other cache-related fields could be present." -msgstr "開発を簡単にするために、ほとんどのプラグインはインベントリーソースとして標準的な YAML ベースの設定ファイルを使用しています。このファイルには、必須フィールドが 1 つしかありません (``plugin``)。このフィールドには、このファイルを使用することが期待されるプラグインの名前を入れる必要があります。使用する他の共通機能によっては、他のフィールドが必要になる場合があり、必要に応じて各プラグインにカスタムオプションを追加することができます。たとえば、統合キャッシングを使用する場合は、``cache_plugin``、``cache_timeout`` などのキャッシュ関連のフィールドが存在する可能性があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:371 -msgid "The 'auto' plugin" -msgstr "「auto」プラグイン" - -#: ../../rst/dev_guide/developing_inventory.rst:373 -msgid "From Ansible 2.5 onwards, we include the :ref:`auto inventory plugin ` and enable it by default. If the ``plugin`` field in your standard configuration file matches the name of your inventory plugin, the ``auto`` inventory plugin will load your plugin. The 'auto' plugin makes it easier to use your plugin without having to update configurations." -msgstr "Ansible 2.5 以降では、:ref:`auto inventory plugin ` を追加し、これをデフォルトで有効化します。標準設定ファイルの ``plugin`` フィールドがインベントリープラグインの名前と一致する場合、``auto`` インベントリープラグインはプラグインを読み込みます。「auto」プラグインは、設定を更新せずにプラグインを簡単に使用できます。" - -#: ../../rst/dev_guide/developing_inventory.rst:380 -msgid "Inventory scripts" -msgstr "インベントリースクリプト" - -#: ../../rst/dev_guide/developing_inventory.rst:382 -msgid "Even though we now have inventory plugins, we still support inventory scripts, not only for backwards compatibility but also to allow users to use other programming languages." -msgstr "inventory プラグインはそのままですが、後方互換性だけでなく、ユーザーが他のプログラミング言語を使用できるように、引き続きインベントリースクリプトをサポートします。" - -#: ../../rst/dev_guide/developing_inventory.rst:388 -msgid "Inventory script conventions" -msgstr "インベントリースクリプトの規則" - -#: ../../rst/dev_guide/developing_inventory.rst:390 -msgid "Inventory scripts must accept the ``--list`` and ``--host `` arguments. Although other arguments are allowed, Ansible will not use them. Such arguments might still be useful for executing the scripts directly." -msgstr "インベントリースクリプトでは、引数 ``--list`` および ``--host `` を使用する必要があります。他の引数は設定できますが、Ansible はそれらを使用しません。このような引数は、スクリプトを直接実行するのに役立つ場合があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:393 -msgid "When the script is called with the single argument ``--list``, the script must output to stdout a JSON object that contains all the groups to be managed. Each group's value should be either an object containing a list of each host, any child groups, and potential group variables, or simply a list of hosts:" -msgstr "スクリプトが単一の引数 ``--list`` で呼び出されると、スクリプトは、標準出力に、管理するすべてのグループが含まれる JSON オブジェクトを出力する必要があります。各グループの値は、各ホスト、子グループ、および潜在的なグループ変数の一覧を含むオブジェクト、または簡単にホストの一覧にする必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:416 -msgid "If any of the elements of a group are empty, they may be omitted from the output." -msgstr "グループのいずれかの要素が空の場合は、出力から省略される可能性があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:418 -msgid "When called with the argument ``--host `` (where is a host from above), the script must print a JSON object, either empty or containing variables to make them available to templates and playbooks. For example:" -msgstr "引数 ``--host `` で呼び出される場合 ( は上記のホスト) で呼び出されると、スクリプトは、空か、変数を含む JSON オブジェクトを出力して、テンプレートと Playbook で利用可能にする必要があります。以下に例を示します。" - -#: ../../rst/dev_guide/developing_inventory.rst:427 -msgid "Printing variables is optional. If the script does not print variables, it should print an empty JSON object." -msgstr "変数の出力は任意です。スクリプトが変数を出力しない場合は、空の JSON オブジェクトを出力する必要があります。" - -#: ../../rst/dev_guide/developing_inventory.rst:432 -msgid "Tuning the external inventory script" -msgstr "外部インベントリースクリプトのチューニング" - -#: ../../rst/dev_guide/developing_inventory.rst:436 -msgid "The stock inventory script system mentioned above works for all versions of Ansible, but calling ``--host`` for every host can be rather inefficient, especially if it involves API calls to a remote subsystem." -msgstr "上記のストックのインベントリースクリプトシステムは、すべてのバージョンの Ansible に対して動作しますが、特にリモートサブシステムへの API 呼び出しが必要になる場合は、すべてのホストに対して ``--host`` を呼び出すこともできます。" - -#: ../../rst/dev_guide/developing_inventory.rst:438 -msgid "To avoid this inefficiency, if the inventory script returns a top-level element called \"_meta\", it is possible to return all the host variables in a single script execution. When this meta element contains a value for \"hostvars\", the inventory script will not be invoked with ``--host`` for each host. This behavior results in a significant performance increase for large numbers of hosts." -msgstr "これを回避するには、インベントリースクリプトが「_meta」という最上位の要素を返す場合には、単一スクリプトの実行ですべてのホスト変数を返すことができます。このメタ要素に「hostvars」の値が含まれていると、インベントリースクリプトは各ホストに対して ``--host`` で呼び出されません。この動作は、多数のホストのパフォーマンスを大幅に向上します。" - -#: ../../rst/dev_guide/developing_inventory.rst:440 -msgid "The data to be added to the top-level JSON object looks like this:" -msgstr "レベルの JSON オブジェクトに追加するデータは次のようになります。" - -#: ../../rst/dev_guide/developing_inventory.rst:461 -msgid "To satisfy the requirements of using ``_meta``, to prevent ansible from calling your inventory with ``--host`` you must at least populate ``_meta`` with an empty ``hostvars`` object. For example:" -msgstr "Ansible が ``--host`` でインベントリーを呼び出すのを防ぐために ``_meta`` を使用する要件を満たすには、少なくとも空の ``hostvars`` オブジェクトで ``_meta`` を埋めなければなりません。以下に例を示します。" - -#: ../../rst/dev_guide/developing_inventory.rst:479 -msgid "If you intend to replace an existing static inventory file with an inventory script, it must return a JSON object which contains an 'all' group that includes every host in the inventory as a member and every group in the inventory as a child. It should also include an 'ungrouped' group which contains all hosts which are not members of any other group. A skeleton example of this JSON object is:" -msgstr "既存の静的インベントリーファイルをインベントリースクリプトに置き換える場合は、インベントリー内のすべてのホストをメンバーとして、インベントリー内のすべてのグループを子として含む「すべて」のグループを含む JSON オブジェクトを返す必要があります。また、他のグループのメンバーではないすべてのホストを含む「グループ化されていない」グループも含める必要があります。この JSON オブジェクトのスケルトンの例は次のとおりです。" - -#: ../../rst/dev_guide/developing_inventory.rst:499 -msgid "An easy way to see how this should look is using :ref:`ansible-inventory`, which also supports ``--list`` and ``--host`` parameters like an inventory script would." -msgstr "これがどのように見えるかを確認する簡単な方法は、:ref:`ansible-inventory` を使用することです。これにより、インベントリースクリプトのように ``--list`` パラメーターおよび ``--host`` パラメーターがサポートされます。" - -#: ../../rst/dev_guide/developing_inventory.rst:504 -msgid "Python API to Playbooks and Ad Hoc Task Execution" -msgstr "Playbook およびアドホックタスク実行のための Python API" - -#: ../../rst/dev_guide/developing_inventory.rst:506 -msgid "Get started with developing a module" -msgstr "モジュールの開発を始める" - -#: ../../rst/dev_guide/developing_inventory.rst:509 -msgid "`AWX `_" -msgstr "`AWX `_" - -#: ../../rst/dev_guide/developing_inventory.rst:510 -msgid "REST API endpoint and GUI for Ansible, syncs with dynamic inventory" -msgstr "Ansible の REST API エンドポイントおよび GUI (動的インベントリーと同期)" - -#: ../../rst/dev_guide/developing_locally.rst:6 -msgid "Adding modules and plugins locally" -msgstr "モジュールおよびプラグインをローカルで追加" - -#: ../../rst/dev_guide/developing_locally.rst:8 -msgid "You can extend Ansible by adding custom modules or plugins. You can create them from scratch or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share plugins and modules by including them in a collection, then publishing the collection on Ansible Galaxy." -msgstr "カスタムモジュールやプラグインを追加してAnsibleを拡張することができます。カスタムモジュールやプラグインは、ゼロから作成することも、既存のものをコピーしてローカルで使用することもできます。ローカルのモジュールやプラグインは、Ansibleコントロールノードに保存して、チームや組織で共有することができます。また、プラグインやモジュールをコレクションに含め、そのコレクションをAnsible Galaxyで公開することでも共有できます。" - -#: ../../rst/dev_guide/developing_locally.rst:10 -msgid "If you are using a local module or plugin but Ansible cannot find it, this page is all you need." -msgstr "ローカルモジュールやプラグインを使用しているが、Ansibleがそれを見つけられない場合、このページですべて解決します。" - -#: ../../rst/dev_guide/developing_locally.rst:12 -msgid "If you want to create a plugin or a module, see :ref:`developing_plugins`, :ref:`developing_modules_general` and :ref:`developing_collections`." -msgstr "プラグインやモジュールを作成したい場合は、:ref:`developing_plugins`、:ref:`developing_modules_general`、:ref:`developing_collections` を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:14 -msgid "Extending Ansible with local modules and plugins offers shortcuts such as:" -msgstr "ローカルのモジュールおよびプラグインで Ansible を拡張すると、以下のようなショートカットが利用できるようになります。" - -#: ../../rst/dev_guide/developing_locally.rst:16 -msgid "You can copy other people's modules and plugins." -msgstr "他のユーザーのモジュールおよびプラグインをコピーできます。" - -#: ../../rst/dev_guide/developing_locally.rst:17 -msgid "When writing a new module, you can choose any programming language you like." -msgstr "新しいモジュールを作成する場合は、任意のプログラミング言語を選択できます。" - -#: ../../rst/dev_guide/developing_locally.rst:18 -msgid "You do not have to clone any repositories." -msgstr "リポジトリーのクローンを作成する必要はありません。" - -#: ../../rst/dev_guide/developing_locally.rst:19 -msgid "You do not have to open a pull request." -msgstr "プル要求を開く必要はありません。" - -#: ../../rst/dev_guide/developing_locally.rst:20 -msgid "You do not have to add tests (though we recommend that you do!)." -msgstr "テストを追加する必要はありません (ただし、この操作を推奨しています)。" - -#: ../../rst/dev_guide/developing_locally.rst:28 -msgid "Modules and plugins: what is the difference?" -msgstr "モジュールおよびプラグイン: 相違点" - -#: ../../rst/dev_guide/developing_locally.rst:29 -msgid "If you are looking to add functionality to Ansible, you might wonder whether you need a module or a plugin. Here is a quick overview to help you understand what you need:" -msgstr "Ansible に機能を追加する場合は、モジュールまたはプラグインのどちらが必要か疑問に思う場合があります。以下に、必要なものを理解するのに役立つ概要を示します。" - -#: ../../rst/dev_guide/developing_locally.rst:31 -msgid ":ref:`Plugins ` extend Ansible's core functionality. Most plugin types execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible: transforming data, logging output, connecting to inventory, and more." -msgstr ":ref:`Plugins ` は、Ansible のコア機能を拡張します。ほとんどのプラグインタイプは、``/usr/bin/ansible`` プロセス内のコントロールノードで実行します。プラグインは、Ansible のコア機能のオプションおよび拡張機能 (データの変換、ログ出力、インベントリーへの接続など) を提供します。" - -#: ../../rst/dev_guide/developing_locally.rst:32 -msgid "Modules are a type of plugin that execute automation tasks on a 'target' (usually a remote system). Modules work as standalone scripts that Ansible executes in their own process outside of the controller. Modules interface with Ansible mostly via JSON, accepting arguments and returning information by printing a JSON string to stdout before exiting. Unlike the other plugins (which must be written in Python), modules can be written in any language; although Ansible provides modules in Python and Powershell only." -msgstr "モジュールは、'target' (通常はリモートシステム) で自動化タスクを実行するプラグインの一種です。モジュールは、Ansible がコントローラー外の独自のプロセスで実行するスタンドアロンスクリプトとして機能します。モジュールは主に JSON を介して Ansible とやり取りし、終了する前に JSON 文字列を stdout に出力して引数を受け取り、情報を返します。他の (Python で書かれる必要がある) プラグインとは異なり、モジュールは任意の言語で書くことができます。ただし、Ansible は Python と Powershell でのみモジュールを提供します。" - -#: ../../rst/dev_guide/developing_locally.rst:37 -msgid "Adding modules and plugins in collections" -msgstr "コレクションでのモジュールとプラグインの追加" - -#: ../../rst/dev_guide/developing_locally.rst:39 -msgid "You can add modules and plugins by :ref:`creating a collection `. With a collection, you can use custom modules and plugins in any playbook or role. You can share your collection easily at any time through Ansible Galaxy." -msgstr "モジュールやプラグインは、:ref:`creating a collection ` で追加できます。コレクションがあれば、任意のPlaybookやロールでカスタムモジュールやプラグインを使用することができます。コレクションは、Ansible Galaxyを使っていつでも簡単に共有することができます。" - -#: ../../rst/dev_guide/developing_locally.rst:41 -msgid "The rest of this page describes other methods of using local, standalone modules or plugins." -msgstr "このページの残りの部分では、ローカルのスタンドアロンのモジュールやプラグインを使用する他の方法について説明します。" - -#: ../../rst/dev_guide/developing_locally.rst:46 -msgid "Adding a module or plugin outside of a collection" -msgstr "コレクション外のモジュールやプラグインの追加" - -#: ../../rst/dev_guide/developing_locally.rst:48 -msgid "You can configure Ansible to load standalone local modules or plugins in specific locations and make them available to all playbooks and roles (using configured paths). Alternatively, you can make a non-collection local module or plugin available only to certain playbooks or roles (via adjacent paths)." -msgstr "Ansible を設定して、スタンドアロンのローカルモジュールまたはプラグインを特定の場所にロードし、それらを (設定済みのパスを使用して) すべての Playbook およびロールで利用可能にできます。または、コレクションではないローカルモジュールまたはプラグインを (隣接するパスを介して) 特定の Playbook またはロールのみで利用可能にすることもできます。" - -#: ../../rst/dev_guide/developing_locally.rst:51 -msgid "Adding standalone local modules for all playbooks and roles" -msgstr "すべてのPlaybookとロールに対するスタンドアロンのローカルモジュールの追加" - -#: ../../rst/dev_guide/developing_locally.rst:53 -msgid "To load standalone local modules automatically and make them available to all playbooks and roles, use the :ref:`DEFAULT_MODULE_PATH` configuration setting or the ``ANSIBLE_LIBRARY`` environment variable. The configuration setting and environment variable take a colon-separated list, similar to ``$PATH``. You have two options:" -msgstr "スタンドアロンのローカルモジュールを自動的に読み込み、すべてのPlaybookとロールで利用できるようにするには、:ref:`DEFAULT_MODULE_PATH` の構成設定または``ANSIBLE_LIBRARY`` の環境変数を使用します。``$PATH`` と同様に、構成設定や環境変数はコロンで区切られたリストを受け取ります。2つのオプションがあります。" - -#: ../../rst/dev_guide/developing_locally.rst:55 -msgid "Add your standalone local module to one of the default configured locations. See the :ref:`DEFAULT_MODULE_PATH` configuration setting for details. Default locations may change without notice." -msgstr "スタンドアロンのローカルモジュールを、デフォルトで設定されている場所の一つに追加します。詳しくは、:ref:`DEFAULT_MODULE_PATH` の構成設定をご覧ください。デフォルトのロケーションは予告なく変更されることがあります。" - -#: ../../rst/dev_guide/developing_locally.rst:58 -msgid "Add the location of your standalone local module to an environment variable or configuration:" -msgstr "スタンドアロンのローカルモジュールの場所を、環境変数や設定に追加します。" - -#: ../../rst/dev_guide/developing_locally.rst:57 -msgid "the ``ANSIBLE_LIBRARY`` environment variable" -msgstr "``ANSIBLE_LIBRARY`` 環境変数" - -#: ../../rst/dev_guide/developing_locally.rst:58 -msgid "the :ref:`DEFAULT_MODULE_PATH` configuration setting" -msgstr ":ref:`DEFAULT_MODULE_PATH` 構成設定" - -#: ../../rst/dev_guide/developing_locally.rst:60 -msgid "To view your current configuration settings for modules:" -msgstr "モジュールの現在の構成設定を表示するには：" - -#: ../../rst/dev_guide/developing_locally.rst:66 -msgid "After you save your module file in one of these locations, Ansible loads it and you can use it in any local task, playbook, or role." -msgstr "モジュールファイルをこのいずれかの場所に保存すると、Ansible はそのファイルを読み込み、ローカルのタスク、Playbook、またはロールで使用できます。" - -#: ../../rst/dev_guide/developing_locally.rst:68 -msgid "To confirm that ``my_local_module`` is available:" -msgstr "``my_local_module`` が利用可能であることを確認するには：" - -#: ../../rst/dev_guide/developing_locally.rst:70 -msgid "type ``ansible localhost -m my_local_module`` to see the output for that module, or" -msgstr "``ansible localhost -m my_local_module`` と入力すると、そのモジュールの出力が表示されます。あるいは、" - -#: ../../rst/dev_guide/developing_locally.rst:71 -msgid "type ``ansible-doc -t module my_local_module`` to see the documentation for that module" -msgstr "``ansible-doc -t module my_local_module`` と入力すると、そのモジュールのドキュメントが表示されます。" - -#: ../../rst/dev_guide/developing_locally.rst:73 -#: ../../rst/dev_guide/developing_locally.rst:86 -msgid "This applies to all plugin types but requires specific configuration and/or adjacent directories for each plugin type, see below." -msgstr "これはすべてのプラグインタイプに適用されますが、プラグインタイプごとに特定の設や隣接ディレクトリーが必要です。以下を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:76 -msgid "The ``ansible-doc`` command can parse module documentation from modules written in Python or an adjacent YAML file. If you have a module written in a programming language other than Python, you should write the documentation in a Python or YAML file adjacent to the module file. :ref:`adjacent_yaml_doc`" -msgstr "``ansible-doc`` コマンドは、Python または隣接 YAML ファイルで記述されたモジュールからモジュールドキュメントを解析できます。Python 以外のプログラミング言語で記述されたモジュールがある場合は、モジュールファイルに隣接する Python または YAML ファイルにドキュメントを記述する必要があります。:ref:`adjacent_yaml_doc`" - -#: ../../rst/dev_guide/developing_locally.rst:79 -msgid "Adding standalone local modules for selected playbooks or a single role" -msgstr "選択したプレイブックや単一のロールへのスタンドアロンのローカルモジュールの追加" - -#: ../../rst/dev_guide/developing_locally.rst:81 -msgid "Ansible automatically loads all executable files from certain directories adjacent to your playbook or role as modules. Standalone modules in these locations are available only to the specific playbook, playbooks, or role in the parent directory." -msgstr "Ansibleは、Playbookやロールに隣接する特定のディレクトリにあるすべての実行可能ファイルをモジュールとして自動的に読み込みます。これらの場所にあるスタンドアロンのモジュールは、親ディレクトリにある特定のPlaybookまたはロールでのみ利用できます。" - -#: ../../rst/dev_guide/developing_locally.rst:83 -msgid "To use a standalone module only in a selected playbook or playbooks, store the module in a subdirectory called ``library`` in the directory that contains the playbook or playbooks." -msgstr "スタンドアロンモジュールを特定のプレイブックでのみ使用するには、Playbookを含むディレクトリ内の``library`` というサブディレクトリにモジュールを保存します。" - -#: ../../rst/dev_guide/developing_locally.rst:84 -msgid "To use a standalone module only in a single role, store the module in a subdirectory called ``library`` within that role." -msgstr "スタンドアロンモジュールを単一のロールでのみ使用するには、そのロール内の``library`` というサブディレクトリにモジュールを保存します。" - -#: ../../rst/dev_guide/developing_locally.rst:90 -msgid "Roles contained in collections cannot contain any modules or other plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new modules, we recommend distributing them in :ref:`collections `, not in roles." -msgstr "コレクションに含まれるロールは、モジュールや他のプラグインを含むことができません。コレクション内のすべてのプラグインは、コレクションの``plugins`` ディレクトリツリーに格納されている必要があります。そのツリー内のすべてのプラグインは、コレクション内のすべてのロールからアクセス可能です。新しいモジュールを開発している場合は、ロールではなく、:ref:`collections ` で配布することをお勧めします。" - -#: ../../rst/dev_guide/developing_locally.rst:96 -msgid "Adding a non-module plugin locally outside of a collection" -msgstr "モジュール以外のプラグインのコレクション外でのローカルでの追加" - -#: ../../rst/dev_guide/developing_locally.rst:98 -msgid "You can configure Ansible to load standalone local plugins in a specified location or locations and make them available to all playbooks and roles. Alternatively, you can make a standalone local plugin available only to specific playbooks or roles." -msgstr "指定した場所のスタンドアロンのローカルプラグインを読みこむようにAnsibleを設定し、すべてのPlaybookやロールで利用できるようにすることができます。また、スタンドアロンのローカルプラグインを特定のPlaybookやロールでのみ利用できるようにすることもできます。" - -#: ../../rst/dev_guide/developing_locally.rst:102 -msgid "Although modules are plugins, the naming patterns for directory names and environment variables that apply to other plugin types do not apply to modules. See :ref:`local_modules`." -msgstr "モジュールはプラグインですが、他のプラグインタイプに適用されるディレクトリ名や環境変数のネーミングパターンは、モジュールには適用されません。:ref:`local_modules` をご覧ください。" - -#: ../../rst/dev_guide/developing_locally.rst:105 -msgid "Adding local non-module plugins for all playbooks and roles" -msgstr "すべてのPlaybookとロールへのローカルのモジュール以外のプラグインの追加" - -#: ../../rst/dev_guide/developing_locally.rst:107 -msgid "To load standalone local plugins automatically and make them available to all playbooks and roles, use the configuration setting or environment variable for the type of plugin you are adding. These configuration settings and environment variables take a colon-separated list, similar to ``$PATH``. You have two options:" -msgstr "スタンドアロンのローカルプラグインを自動的に読み込み、すべてのPlaybookとロールで利用できるようにするには、追加するプラグインのタイプの構成設定または環境変数を使用します。``$PATH`` と同様に、これらの構成設定や環境変数はコロンで区切られたリストを受け取ります。2つのオプションがあります。" - -#: ../../rst/dev_guide/developing_locally.rst:109 -msgid "Add your local plugin to one of the default configured locations. See :ref:`configuration settings ` for details on the correct configuration setting for the plugin type. Default locations may change without notice." -msgstr "ローカルプラグインを、デフォルトで設定されている場所の1つに追加します。プラグインタイプの正しい構成設定の詳細については、:ref:`configuration settings ` をご覧ください。デフォルトのロケーションは予告なく変更されることがあります。" - -#: ../../rst/dev_guide/developing_locally.rst:112 -msgid "Add the location of your local plugin to an environment variable or configuration:" -msgstr "ローカルプラグインの場所を、環境変数や設定に追加します。" - -#: ../../rst/dev_guide/developing_locally.rst:111 -msgid "the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable - for example, ``$ANSIBLE_INVENTORY_PLUGINS`` or ``$ANSIBLE_VARS_PLUGINS``" -msgstr "関連する``ANSIBLE_plugin_type_PLUGINS`` 環境変数 - 例えば、``$ANSIBLE_INVENTORY_PLUGINS`` または ``$ANSIBLE_VARS_PLUGINS``" - -#: ../../rst/dev_guide/developing_locally.rst:112 -msgid "the relevant ``plugin_type_PATH`` configuration setting, most of which begin with ``DEFAULT_`` - for example, ``DEFAULT_CALLBACK_PLUGIN_PATH`` or ``DEFAULT_FILTER_PLUGIN_PATH`` or ``BECOME_PLUGIN_PATH``" -msgstr "関連する``plugin_type_PATH`` 構成設定（ほとんどが``DEFAULT_`` で始まる）- 例えば``DEFAULT_CALLBACK_PLUGIN_PATH`` や``DEFAULT_FILTER_PLUGIN_PATH`` や ``BECOME_PLUGIN_PATH``" - -#: ../../rst/dev_guide/developing_locally.rst:114 -msgid "To view your current configuration settings for non-module plugins:" -msgstr "モジュール以外のプラグインの現在の構成設定を表示するには：" - -#: ../../rst/dev_guide/developing_locally.rst:120 -msgid "After your plugin file is added to one of these locations, Ansible loads it and you can use it in any local module, task, playbook, or role. For more information on environment variables and configuration settings, see :ref:`ansible_configuration_settings`." -msgstr "プラグインファイルがこれらの場所のいずれかに追加されると、Ansible はそのファイルをロードし、任意のローカルモジュール、タスク、Playbook、ロールで使用できるようになります。環境変数および構成設定の詳細については、:ref:`ansible_configuration_settings` を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:122 -msgid "To confirm that ``plugins/plugin_type/my_local_plugin`` is available:" -msgstr "``plugins/plugin_type/my_local_plugin`` が利用可能であることを確認するには：" - -#: ../../rst/dev_guide/developing_locally.rst:124 -msgid "type ``ansible-doc -t my_local_lookup_plugin`` to see the documentation for that plugin - for example, ``ansible-doc -t lookup my_local_lookup_plugin``" -msgstr "``ansible-doc -t my_local_lookup_plugin`` と入力すると、そのプラグインのドキュメントが表示されます （例：``ansible-doc -t lookup my_local_lookup_plugin``）。" - -#: ../../rst/dev_guide/developing_locally.rst:126 -msgid "The ``ansible-doc`` command works for most plugin types, but not for action, filter, or test plugins. See :ref:`ansible-doc` for more details." -msgstr "``ansible-doc`` コマンドは、ほとんどの種類のプラグインで動作しますが、アクション、フィルター、テストプラグインでは動作しません。詳しくは:ref:`ansible-doc` をご覧ください。" - -#: ../../rst/dev_guide/developing_locally.rst:129 -msgid "Adding standalone local plugins for selected playbooks or a single role" -msgstr "選択したプレイブックや単一のロールへのスタンドアロンのローカルプラグインの追加" - -#: ../../rst/dev_guide/developing_locally.rst:131 -msgid "Ansible automatically loads all plugins from certain directories adjacent to your playbook or role, loading each type of plugin separately from a directory named for the type of plugin. Standalone plugins in these locations are available only to the specific playbook, playbooks, or role in the parent directory." -msgstr "Ansibleは、Playbookやロールに隣接する特定のディレクトリにあるすべてのプラグインを自動的に読み込みます。各タイプのプラグインは、プラグインのタイプの名前が付いたディレクトリーから個別に読み込まれます。これらの場所にあるスタンドアロンのプラグインは、親ディレクトリにある特定のPlaybookまたはロールでのみ利用できます。" - -#: ../../rst/dev_guide/developing_locally.rst:133 -msgid "To use a standalone plugin only in a selected playbook or playbooks, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`." -msgstr "選択した Playbookでのみスタンドアロンのプラグインを使用するには、そのPlaybook を含むディレクトリーの正しい ``plugin_type``のサブディレクトリー (例: ``callback_plugins`` または ``inventory_plugins``) にプラグインを保存します。これらのディレクトリーは、``_plugins``の接尾辞を使用する必要があります。プラグインタイプの完全なリストは、:ref:`working_with_plugins`を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:134 -msgid "To use a standalone plugin only in a single role, store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed. These directories must use the ``_plugins`` suffix. For a full list of plugin types, see :ref:`working_with_plugins`." -msgstr "単一のロールでのみスタンドアロンのプラグインを使用するには、そのロール内の正しい ``plugin_type`` のサブディレクトリー （例：``cache_plugins`` または ``strategy_plugins``) にプラグインを保存します。ロールの一部として提供された場合は、ロールが実行されるとすぐにプラグインが利用可能になります。これらのディレクトリーは、``_plugins``の接尾辞を使用する必要があります。プラグインタイプの完全なリストは、:ref:`working_with_plugins`を参照してください。" - -#: ../../rst/dev_guide/developing_locally.rst:138 -msgid "Roles contained in collections cannot contain any plugins. All plugins in a collection must live in the collection ``plugins`` directory tree. All plugins in that tree are accessible to all roles in the collection. If you are developing new plugins, we recommend distributing them in :ref:`collections `, not in roles." -msgstr "コレクションに含まれるロールは、プラグインを含むことができません。コレクション内のすべてのプラグインは、コレクションの``plugins`` ディレクトリツリーに格納されている必要があります。そのツリー内のすべてのプラグインは、コレクション内のすべてのロールからアクセス可能です。新しいプラグインを開発している場合は、ロールではなく、:ref:`collections ` で配布することをお勧めします。" - -#: ../../rst/dev_guide/developing_locally.rst:143 -msgid "Using ``ansible.legacy`` to access custom versions of an ``ansible.builtin`` module" -msgstr "``ansible.legacy`` を使用した ``ansible.builtin`` モジュールのカスタムバージョンへのアクセス" - -#: ../../rst/dev_guide/developing_locally.rst:145 -msgid "If you need to override one of the ``ansible.builtin`` modules and are using FQCN, you need to use ``ansible.legacy`` as part of the fully-qualified collection name (FQCN). For example, if you had your own ``copy`` module, you would access it as ``ansible.legacy.copy``. See :ref:`using_ansible_legacy` for details on how to use custom modules with roles within a collection." -msgstr "``ansible.builtin`` モジュールのいずれかをオーバーライドする必要があり、FQCN を使用している場合は、完全修飾コレクション名 (FQCN) の一部として ``ansible.legacy`` を使用する必要があります。たとえば、独自の ``copy`` モジュールがある場合は、``ansible.legacy.copy`` としてアクセスします。コレクション内のロールでカスタムモジュールを使用する方法は、:ref:`using_ansible_legacy` を参照してください。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:5 -msgid "Using and developing module utilities" -msgstr "モジュールユーティリティーの使用および開発" - -#: ../../rst/dev_guide/developing_module_utilities.rst:7 -msgid "Ansible provides a number of module utilities, or snippets of shared code, that provide helper functions you can use when developing your own modules. The ``basic.py`` module utility provides the main entry point for accessing the Ansible library, and all Python Ansible modules must import something from ``ansible.module_utils``. A common option is to import ``AnsibleModule``:" -msgstr "Ansible は、独自のモジュール開発時に使用できるヘルパー関数を提供する多くのモジュールユーティリティー、または共有コードのスニペットを提供します。``basic.py`` モジュールユーティリティーは、Ansible ライブラリーにアクセスするためのメインのエントリーポイントを提供します。また、すべての Python Ansible モジュールは ``ansible.module_utils`` からインポートする必要があります。一般的なオプションでは、``AnsibleModule`` をインポートするのが一般的です。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:17 -msgid "The ``ansible.module_utils`` namespace is not a plain Python package: it is constructed dynamically for each task invocation, by extracting imports and resolving those matching the namespace against a :ref:`search path ` derived from the active configuration." -msgstr "``ansible.module_utils`` 名前空間は単純な Python パッケージではありません。これは、インポートを抽出し、アクティブな設定から派生する :ref:`検索パス ` に対して一致する名前空間を解決することで、各タスク呼び出し用に動的に構築されます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:22 -msgid "To reduce the maintenance burden in a collection or in local modules, you can extract duplicated code into one or more module utilities and import them into your modules. For example, if you have your own custom modules that import a ``my_shared_code`` library, you can place that into a ``./module_utils/my_shared_code.py`` file like this:" -msgstr "コレクションまたはローカルモジュールのメンテナンス負荷を軽減するには、重複コードを 1 つ以上のモジュールユーティリティーに抽出してモジュールにインポートすることができます。たとえば、``my_shared_code`` ライブラリーをインポートする独自のカスタムモジュールがある場合は、これを、以下のように ``./module_utils/my_shared_code.py`` ファイルに配置できます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:29 -msgid "When you run ``ansible-playbook``, Ansible will merge any files in your local ``module_utils`` directories into the ``ansible.module_utils`` namespace in the order defined by the :ref:`Ansible search path `." -msgstr "``ansible-playbook`` を実行すると、Ansible は :ref:`Ansible 検索パス ` で定義されている順序でローカルの ``module_utils`` ディレクトリーのファイルを ``ansible.module_utils`` 名前空間にマージします。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:32 -msgid "Naming and finding module utilities" -msgstr "モジュールユーティリティーの命名および検索" - -#: ../../rst/dev_guide/developing_module_utilities.rst:34 -msgid "You can generally tell what a module utility does from its name and/or its location. Generic utilities (shared code used by many different kinds of modules) live in the main ansible/ansible codebase, in the ``common`` subdirectory or in the root directory of ``lib/ansible/module_utils``. Utilities used by a particular set of modules generally live in the same collection as those modules. For example:" -msgstr "通常、モジュールユーティリティーが名前やその場所から動作するようにできます。汎用ユーティリティー (さまざまな種類のモジュールで使用される共有コード) は、メインの ansible/ansible コードベースにあります。``common`` サブディレクトリー、または ``lib/ansible/module_utils`` のルートディレクトリーにあります。特定のモジュールセットで使用されるユーティリティーは、通常、それらのモジュールと同じコレクションに存在します。以下に例を示します。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:36 -msgid "``lib/ansible/module_utils/urls.py`` contains shared code for parsing URLs" -msgstr "``lib/ansible/module_utils/urls.py`` は、URL を解析するための共有コードが含まれています。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:37 -msgid "``openstack.cloud.plugins.module_utils.openstack.py`` contains utilities for modules that work with OpenStack instances" -msgstr "``openstack.cloud.plugins.module_utils.openstack.py`` には、OpenStack インスタンスと連携するモジュールのユーティリティーが含まれます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:38 -msgid "``ansible.netcommon.plugins.module_utils.network.common.config.py`` contains utility functions for use by networking modules" -msgstr "``ansible.netcommon.plugins.module_utils.network.common.config.py`` は、ネットワークモジュールによって使用される設定ユーティリティーの機能が含まれます。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:40 -msgid "Following this pattern with your own module utilities makes everything easy to find and use." -msgstr "このパターンを独自のモジュールユーティリティーで行うと、あらゆるものを見つけ、使用することが容易になります。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:45 -msgid "Standard module utilities" -msgstr "標準のモジュールユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:47 -msgid "Ansible ships with an extensive library of ``module_utils`` files. You can find the module utility source code in the ``lib/ansible/module_utils`` directory under your main Ansible path. We describe the most widely used utilities below. For more details on any specific module utility, please see the `source code for module_utils `_." -msgstr "Ansible には、``module_utils`` ファイルの広範なライブラリーが含まれています。モジュールユーティリティーのソースコードは、メインの Ansible パス下の ``lib/ansible/module_utils`` ディレクトリーにあります。また、以下で最も広く使用されているユーティリティーが含まれています。特定のモジュールユーティリティーの詳細は、「`モジュールユーティリティーのソースコード `_」を参照してください。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:2 -msgid "**LICENSING REQUIREMENTS** Ansible enforces the following licensing requirements:" -msgstr "**ライセンス要件** Ansible は、以下のライセンス要件を強制します。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:7 -msgid "Utilities (files in ``lib/ansible/module_utils/``) may have one of two licenses:" -msgstr "ユーティリティー (``lib/ansible/module_utils/`` 内のファイル) には、2 つあるライセンスのいずれかが存在する可能性があります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:5 -msgid "A file in ``module_utils`` used **only** for a specific vendor's hardware, provider, or service may be licensed under GPLv3+. Adding a new file under ``module_utils`` with GPLv3+ needs to be approved by the core team." -msgstr "特定のベンダーのハードウェア、プロバイダー、またはサービスに **のみ** ``module_utils`` を使用するファイルは、GPLv3 以降でライセンスを取得している可能性があります。GPLv3 以降を持つ ``module_utils`` に新しいファイルを追加するには、コアチームによる承認が必要になります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:7 -msgid "All other ``module_utils`` must be licensed under BSD, so GPL-licensed third-party and Galaxy modules can use them." -msgstr "他のすべての ``module_utils`` は、GPL のライセンスが付与されたサードパーティーと Galaxy モジュールが使用できるように、BSD でライセンスが付与されている必要があります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:8 -msgid "If there's doubt about the appropriate license for a file in ``module_utils``, the Ansible Core Team will decide during an Ansible Core Community Meeting." -msgstr "``module_utils`` のファイルに適切なライセンスについて疑問がある場合は、Ansible Core Team が Ansible Core Community Meeting で決定します。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:9 -msgid "All other files shipped with Ansible, including all modules, must be licensed under the GPL license (GPLv3 or later)." -msgstr "すべてのモジュールを含む Ansible に同梱される他のすべてのファイルは、GPL ライセンス (GPLv3 以降) でライセンスを取得する必要があります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:10 -msgid "Existing license requirements still apply to content in ansible/ansible (ansible-core)." -msgstr "既存のライセンス要件は、引き続き ansible/ansible のコンテンツ (ansible-core) に適用されます。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:11 -msgid "Content that was previously in ansible/ansible or a collection and has moved to a new collection must retain the license it had in its prior repository." -msgstr "コンテンツが過去に ansible/ansible またはコレクションにあり、新しいコレクションに移動した場合は、以前のリポジトリーのライセンスを保持する必要があります。" - -#: ../../rst/dev_guide/shared_snippets/licensing.txt:12 -msgid "Copyright entries by previous committers must also be kept in any moved files." -msgstr "以前のコミット担当者による著作権エントリーも、移動したファイルに保持する必要があります。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:51 -msgid "``api.py`` - Supports generic API modules" -msgstr "``api.py`` - 汎用 API モジュールのサポート" - -#: ../../rst/dev_guide/developing_module_utilities.rst:52 -msgid "``basic.py`` - General definitions and helper utilities for Ansible modules" -msgstr "``basic.py`` - Ansible モジュールの一般的な定義およびヘルパーユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:53 -msgid "``common/dict_transformations.py`` - Helper functions for dictionary transformations" -msgstr "``common/dict_transformations.py`` - ディクショナリー変換のヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:54 -msgid "``common/file.py`` - Helper functions for working with files" -msgstr "``common/file.py`` - ファイルを操作するヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:55 -msgid "``common/text/`` - Helper functions for converting and formatting text" -msgstr "``common/text/`` - テキストの変換およびフォーマットを行うためのヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:56 -msgid "``common/parameters.py`` - Helper functions for dealing with module parameters" -msgstr "``common/parameters.py`` - モジュールパラメーターを処理するヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:57 -msgid "``common/sys_info.py`` - Functions for getting distribution and platform information" -msgstr "``common/sys_info.py`` - ディストリビューションおよびプラットフォーム情報を取得する機能" - -#: ../../rst/dev_guide/developing_module_utilities.rst:58 -msgid "``common/validation.py`` - Helper functions for validating module parameters against a module argument spec" -msgstr "``common/validation.py`` - モジュール引数仕様に対してモジュールパラメーターを検証するためのヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:59 -msgid "``facts/`` - Directory of utilities for modules that return facts. See `PR 23012 `_ for more information" -msgstr "``facts/`` - ファクトを返すモジュールのユーティリティーのディレクトリー。詳細は、`PR 23012 `_ を参照してください。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:60 -msgid "``json_utils.py`` - Utilities for filtering unrelated output around module JSON output, like leading and trailing lines" -msgstr "``json_utils.py`` - 先頭行や末尾行など、モジュール JSON 出力に関する関連のない出力をフィルターを設定するユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:61 -msgid "``powershell/`` - Directory of definitions and helper functions for Windows PowerShell modules" -msgstr "``powershell/`` - Windows PowerShell モジュールの定義およびヘルパー関数のディレクトリー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:62 -msgid "``pycompat24.py`` - Exception workaround for Python 2.4" -msgstr "``pycompat24.py`` - Python 2.4 の例外回避策" - -#: ../../rst/dev_guide/developing_module_utilities.rst:63 -msgid "``service.py`` - Utilities to enable modules to work with Linux services (placeholder, not in use)" -msgstr "``service.py`` - モジュールが Linux サービスと連携できるようにするユーティリティー (未使用のプレースホルダー)" - -#: ../../rst/dev_guide/developing_module_utilities.rst:64 -msgid "``six/__init__.py`` - Bundled copy of the `Six Python library `_ to aid in writing code compatible with both Python 2 and Python 3" -msgstr "``six/__init__.py`` - Python 2 と Python 3 の両方と互換性のあるコードを書き込む際に助けとなる `Six Python ライブラリー `_ のバンドルコピー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:65 -msgid "``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates" -msgstr "``splitter.py`` - Jinja2 テンプレートを使用する文字列分割および操作ユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:66 -msgid "``urls.py`` - Utilities for working with http and https requests" -msgstr "``urls.py`` - http および https リクエストを操作するユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:68 -msgid "Several commonly-used utilities migrated to collections in Ansible 2.10, including:" -msgstr "一般的に使用されるいくつかのユーティリティーは、Ansible 2.10 では以下のようなコレクションに移行されています。" - -#: ../../rst/dev_guide/developing_module_utilities.rst:70 -msgid "``ismount.py`` migrated to ``ansible.posix.plugins.module_utils.mount.py`` - Single helper function that fixes os.path.ismount" -msgstr "``ansible.posix.plugins.module_utils.mount.py`` に移行した ``ismount.py`` - os.path.ismount を修正する単一のヘルパー関数" - -#: ../../rst/dev_guide/developing_module_utilities.rst:71 -msgid "``known_hosts.py`` migrated to ``community.general.plugins.module_utils.known_hosts.py`` - utilities for working with known_hosts file" -msgstr "``community.general.plugins.module_utils.known_hosts.py`` に移行した ``known_hosts.py`` - known_hosts ファイルで作業するためのユーティリティー" - -#: ../../rst/dev_guide/developing_module_utilities.rst:73 -msgid "For a list of migrated content with destination collections, see the `runtime.yml file `_." -msgstr "宛先コレクションで移行されたコンテンツの一覧は、`runtime.yml file ` を参照してください。" - -#: ../../rst/dev_guide/developing_modules.rst:6 -msgid "Should you develop a module?" -msgstr "モジュール開発の必要性" - -#: ../../rst/dev_guide/developing_modules.rst:8 -msgid "Developing Ansible modules is easy, but often it is not necessary. Before you start writing a new module, ask:" -msgstr "Ansible モジュールの開発は容易ですが、通常は不要です。新しいモジュールを書き始める前に、以下を確認してください。" - -#: ../../rst/dev_guide/developing_modules.rst:10 -msgid "Does a similar module already exist?" -msgstr "同様のモジュールが存在しているか。" - -#: ../../rst/dev_guide/developing_modules.rst:12 -msgid "An existing module may cover the functionality you want. Ansible collections include thousands of modules. Search our :ref:`list of included collections ` or `Ansible Galaxy `_ to see if an existing module does what you need." -msgstr "既存のモジュールは必要な機能に対応できます。Ansible コレクションには、数千のモジュールが含まれています。:ref:`同梱されるコレクションの一覧 ` または `Ansible Galaxy `_ を検索すると、既存のモジュールが必要なモジュールかどうかが分かります。" - -#: ../../rst/dev_guide/developing_modules.rst:14 -msgid "Should you use or develop an action plugin instead of a module?" -msgstr "モジュールの代わりにアクションプラグインを使用するか、または開発する必要があるか。" - -#: ../../rst/dev_guide/developing_modules.rst:16 -msgid "An action plugin may be the best way to get the functionality you want. Action plugins run on the control node instead of on the managed node, and their functionality is available to all modules. For more information about developing plugins, read the :ref:`developing plugins page `." -msgstr "アクションプラグインは、必要な機能を取得する最善の方法となるでしょう。アクションプラグインは、管理ノードではなくコントロールノードで実行され、その機能はすべてのモジュールで利用できます。プラグインの開発に関する詳細は、「:ref:`プラグインの開発ページ`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules.rst:18 -msgid "Should you use a role instead of a module?" -msgstr "モジュールの代わりにロールを使用する必要があるか。" - -#: ../../rst/dev_guide/developing_modules.rst:20 -msgid "A combination of existing modules may cover the functionality you want. You can write a role for this type of use case. Check out the :ref:`roles documentation`." -msgstr "既存のモジュールの組み合わせによって、希望の機能に対応できる可能性があります。このタイプのユースケースにロールを作成することができます。「:ref:`ロールのドキュメント`」を確認してください。" - -#: ../../rst/dev_guide/developing_modules.rst:22 -msgid "Should you create a collection instead of a single module?" -msgstr "1 つのモジュールの代わりにコレクションを作成する必要があるか。" - -#: ../../rst/dev_guide/developing_modules.rst:24 -msgid "The functionality you want may be too large for a single module. If you want to connect Ansible to a new cloud provider, database, or network platform, you may need to :ref:`develop a new collection`." -msgstr "1 つのモジュールでは、この機能が大きすぎる可能性があります。Ansible を新しいクラウドプロバイダー、データベース、またはネットワークプラットフォームに接続する場合は、:ref:`新しいコレクションの開発` が必要になる場合があります。" - -#: ../../rst/dev_guide/developing_modules.rst:26 -msgid "Each module should have a concise and well defined functionality. Basically, follow the UNIX philosophy of doing one thing well." -msgstr "各モジュールには、簡潔で十分に機能が定義されている必要があります。基本的には、1 つのことを十分に行うという UNIX の哲学に従ってください。" - -#: ../../rst/dev_guide/developing_modules.rst:28 -msgid "A module should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module parameter cannot be documented, that's a sign that the module would be rejected." -msgstr "モジュールは、使用する API またはツールの基礎となるすべてのオプションを把握する必要がありません。たとえば、必要なモジュールパラメーターの有効な値を文書化できない場合、それはモジュールが拒否されることを示しています。" - -#: ../../rst/dev_guide/developing_modules.rst:30 -msgid "Modules should typically encompass much of the logic for interacting with a resource. A lightweight wrapper around an API that does not contain much logic would likely cause users to offload too much logic into a playbook, and for this reason the module would be rejected. Instead try creating multiple modules for interacting with smaller individual pieces of the API." -msgstr "モジュールは、通常、リソースと対話するロジックの多くを網羅する必要があります。ロジックをあまり含まない API の軽量ラッパーを使用すると、ユーザーがあまりにも多くのロジックを Playbook にオフロードする原因となる可能性があるため、モジュールが拒否されます。代わりに、API の小さな個々の部分と対話するための複数のモジュールを作成してみてください。" - -#: ../../rst/dev_guide/developing_modules.rst:32 -msgid "If your use case isn't covered by an existing module, an action plugin, or a role, and you don't need to create multiple modules, then you're ready to start developing a new module. Choose from the topics below for next steps:" -msgstr "ユースケースが、既存のモジュール、アクションプラグイン、またはロールでは対応されておらず、複数のモジュールを作成する必要がない場合は、新しいモジュールの開発を開始する準備ができています。次のステップは、以下のトピックから選択します。" - -#: ../../rst/dev_guide/developing_modules.rst:34 -msgid "I want to :ref:`get started on a new module `." -msgstr ":ref:`新しいモジュールを使用開始` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:35 -msgid "I want to review :ref:`tips and conventions for developing good modules `." -msgstr ":ref:`良質なモジュールを開発するためのヒントおよび規約 ` を確認します。" - -#: ../../rst/dev_guide/developing_modules.rst:36 -msgid "I want to :ref:`write a Windows module `." -msgstr ":ref:`Windows モジュールを作成 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:37 -msgid "I want :ref:`an overview of Ansible's architecture `." -msgstr ":ref:`Ansible のアーキテクチャーの概要 ` が必要です。" - -#: ../../rst/dev_guide/developing_modules.rst:38 -msgid "I want to :ref:`document my module `." -msgstr ":ref:`作成したモジュールをドキュメント化 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:39 -msgid "I want to :ref:`contribute my module to an existing Ansible collection `." -msgstr ":ref:`自分のモジュールで既存の Ansible コレクションに貢献 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:40 -msgid "I want to :ref:`add unit and integration tests to my module `." -msgstr ":ref:`作成したモジュールにユニットテストおよび統合テストを追加 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:41 -msgid "I want to :ref:`add Python 3 support to my module `." -msgstr ":ref:`作成したモジュールに Python 3 サポートを追加 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:42 -msgid "I want to :ref:`write multiple modules `." -msgstr ":ref:`複数モジュールを作成 ` したいです。" - -#: ../../rst/dev_guide/developing_modules.rst:46 -#: ../../rst/dev_guide/developing_plugins.rst:542 -#: ../../rst/dev_guide/sidecar.rst:89 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/dev_guide/developing_modules.rst:47 -#: ../../rst/dev_guide/developing_plugins.rst:543 -#: ../../rst/dev_guide/sidecar.rst:90 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/dev_guide/developing_modules.rst:49 -msgid "Development mailing list" -msgstr "開発メーリングリスト" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:6 -msgid "Conventions, tips, and pitfalls" -msgstr "規則、ヒント、および落とし穴" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:11 -msgid "As you design and develop modules, follow these basic conventions and tips for clean, usable code:" -msgstr "モジュールの設計および開発を行う際に、以下の基本的な規則およびヒントに従って、読みやすく使用可能なコードを作成します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:14 -msgid "Scoping your module(s)" -msgstr "モジュールのスコープ設定" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:16 -msgid "Especially if you want to contribute your module(s) to an existing Ansible Collection, make sure each module includes enough logic and functionality, but not too much. If these guidelines seem confusing, consider :ref:`whether you really need to write a module ` at all." -msgstr "特に、既存の Ansible Collection にモジュールを提供する場合は、各モジュールに十分なロジックと機能が含まれていることを確認してください。ただし、多すぎないようにしてください。これらのガイドラインが紛らわしいと思われる場合は、:ref:`モジュールの記述が本当に必要かどうか ` を検討してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:18 -msgid "Each module should have a concise and well-defined functionality. Basically, follow the UNIX philosophy of doing one thing well." -msgstr "各モジュールには、簡潔で十分に機能が定義されている必要があります。基本的には、1 つのことを十分に行うという UNIX の哲学に従ってください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:19 -msgid "Do not add ``get``, ``list`` or ``info`` state options to an existing module - create a new ``_info`` or ``_facts`` module." -msgstr "既存のモジュールに、``get``、``list``、または ``info`` の状態のオプションを追加しないでください。新しい ``_info`` モジュールまたは ``_facts`` モジュールを作成します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:20 -msgid "Modules should not require that a user know all the underlying options of an API/tool to be used. For instance, if the legal values for a required module option cannot be documented, the module does not belong in Ansible Core." -msgstr "モジュールでは、使用する API またはツールの基礎となるオプションをすべてユーザーが把握する必要がありません。たとえば、必要なモジュールオプションの有効な値を文書化できない場合、そのモジュールは Ansible Core に属しません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:21 -msgid "Modules should encompass much of the logic for interacting with a resource. A lightweight wrapper around a complex API forces users to offload too much logic into their playbooks. If you want to connect Ansible to a complex API, :ref:`create multiple modules ` that interact with smaller individual pieces of the API." -msgstr "モジュールは、リソースと対話するためのロジックを多数組み込む必要があります。複雑な API に関連した軽量ラッパーにより、ユーザーは Playbook に非常に多くのロジックをオフロードします。Ansible を複雑な API に接続する場合は、API のより小さい個々の部分と対話する :ref:`複数のモジュールを作成 ` します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:22 -msgid "Avoid creating a module that does the work of other modules; this leads to code duplication and divergence, and makes things less uniform, unpredictable and harder to maintain. Modules should be the building blocks. If you are asking 'how can I have a module execute other modules' ... you want to write a role." -msgstr "他のモジュールの作業を行うモジュールを作成しないようにしてください。これにより、コードの重複と差異が発生し、一貫性が保たれず、予測ができなくなり、維持が難しくなります。モジュールはビルディングブロックでなければなりません。「どのようにしてモジュールに他のモジュールを実行させることができるのか」という質問が浮かんでくる場合は、それがロールを作成する理由になります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:25 -msgid "Designing module interfaces" -msgstr "モジュールインターフェースの設計" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:27 -msgid "If your module is addressing an object, the option for that object should be called ``name`` whenever possible, or accept ``name`` as an alias." -msgstr "モジュールがオブジェクトに対処している場合は、可能な限りそのオブジェクトのオプションを ``name`` とするか、またはエイリアスとして ``name`` を受け入れます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:28 -msgid "Modules accepting boolean status should accept ``yes``, ``no``, ``true``, ``false``, or anything else a user may likely throw at them. The AnsibleModule common code supports this with ``type='bool'``." -msgstr "ブール値ステータスを許可するモジュールは、``yes``、``no``、``true``、``false``、もしくはユーザーに出力される可能性があるものはなんでも受け入れる必要がります。AnsibleModule の一般的なコードは、``type='bool'`` でこれをサポートします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:29 -msgid "Avoid ``action``/``command``, they are imperative and not declarative, there are other ways to express the same thing." -msgstr "``action``/``command`` は使用しないでください。これは命令型であり、宣言的ではありませんが、同じ方法を表示する方法は他にもあります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:32 -msgid "General guidelines & tips" -msgstr "一般的なガイドラインおよびヒント" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:34 -msgid "Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-core``." -msgstr "各モジュールは 1 つのファイルにまとめて自己完結させる必要があり、``ansible-core`` で自動転送できるようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:35 -msgid "Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-core`` from importing your module." -msgstr "モジュール名は、単語の区切り文字として、ハイフンやスペースの代わりにアンダースコアを使用する必要があります。ハイフンやスペースを使用すると、``ansible-core`` がモジュールをインポートできなくなります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:36 -msgid "Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls." -msgstr "モジュールを開発する際には必ず ``hacking/test-module.py`` スクリプトを使用してください。よくある落とし穴について警告してくれます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:37 -msgid "If you have a local module that returns information specific to your installations, a good name for this module is ``site_info``." -msgstr "インストールに固有の情報を返すローカルモジュールがある場合、このモジュールの適切な名前は ``site_info`` となります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:38 -msgid "Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails." -msgstr "依存関係をなくするか、または最小限に抑えます。モジュールに依存関係がある場合は、モジュールファイルの冒頭で文書化し、依存関係のインポートに失敗した場合は JSON エラーメッセージを発生させます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:39 -msgid "Don't write to files directly; use a temporary file and then use the ``atomic_move`` function from ``ansible.module_utils.basic`` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept." -msgstr "ファイルに直接書き込まないようにします。一時ファイルを使用してから、``ansible.module_utils.basic`` の ``atomic_move`` 関数を使用して、更新された一時ファイルを所定の場所に移動させます。これにより、データの破損を防ぎ、ファイルの正しいコンテキストが保持されるようになります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:40 -msgid "Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server, AWX, or the Red Hat Ansible Automation Platform); do not try to build it into modules." -msgstr "キャッシュを作成しないでください。Ansible は中央のサーバーや権限を持たないように設計されているため、さまざまなパーミッション、オプション、場所を指定して実行しないことを保証することはできません。中央の権限が必要な場合は、それを Ansible の上に置いてください (例: bastion/cm/ci server、AWX、または Red Hat Ansible Automation Platform を使用)。それをモジュールには組み込まないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:41 -msgid "If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional." -msgstr "RPM でモジュールをパッケージ化する場合は、コントロールマシンに ``/usr/share/ansible`` のモジュールをインストールします。RPM でのモジュールのパッケージ化は任意です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:44 -msgid "Functions and Methods" -msgstr "関数およびメソッド" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:46 -msgid "Each function should be concise and should describe a meaningful amount of work." -msgstr "各関数は簡潔にし、意味のある作業量を記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:47 -msgid "\"Don't repeat yourself\" is generally a good philosophy." -msgstr "「Don't repeat yourself (繰り返さないこと)」は、通常、適している哲学です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:48 -msgid "Function names should use underscores: ``my_function_name``." -msgstr "関数名はアンダースコアを使用する必要があります (``my_function_name``)。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:49 -msgid "The name of each function should describe what the function does." -msgstr "各関数の名前には、関数の機能を記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:50 -msgid "Each function should have a docstring." -msgstr "各関数にはドキュメント文字列 (docstring) が必要です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:51 -msgid "If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times." -msgstr "コードの入れ子を多用しすぎている場合、それは通常、ループ本体が関数であることから利益が得られる可能性のある兆候です。既存のコードの一部は、時としてこのような例としては最適ではありません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:54 -msgid "Python tips" -msgstr "Python のヒント" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:56 -msgid "Include a ``main`` function that wraps the normal execution." -msgstr "通常の実行をラップする ``main`` 関数を含めます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:57 -msgid "Call your ``main`` function from a conditional so you can import it into unit tests - for example:" -msgstr "条件から ``main`` 機能を呼び出して、ユニットテストにインポートします。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:67 -msgid "Importing and using shared code" -msgstr "共有コードのインポートおよび使用" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:69 -msgid "Use shared code whenever possible - don't reinvent the wheel. Ansible offers the ``AnsibleModule`` common Python code, plus :ref:`utilities ` for many common use cases and patterns. You can also create documentation fragments for docs that apply to multiple modules." -msgstr "可能な限り共有コードを使用する - wheel を再実装しないでください。Ansible は ``AnsibleModule`` の一般的な Python コードと、多くの一般的なユースケースおよびパターンに使用する :ref:`ユーティリティー ` を提供します。また、複数のモジュールに適用されるドキュメントフラグメントを作成することもできます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:70 -msgid "Import ``ansible.module_utils`` code in the same place as you import other libraries." -msgstr "他のライブラリーをインポートする場所と同じ場所に ``ansible.module_utils`` コードをインポートします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:71 -msgid "Do NOT use wildcards (*) for importing other python modules; instead, list the function(s) you are importing (for example, ``from some.other_python_module.basic import otherFunction``)." -msgstr "他の python モジュールのインポートにはワイルドカード (*) を使用しないでください。代わりに、インポートする関数を一覧表示してください (例: ``from some.other_python_module.basic import otherFunction``。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:72 -msgid "Import custom packages in ``try``/``except``, capture any import errors, and handle them with ``fail_json()`` in ``main()``. For example:" -msgstr "``try``/``except`` でカスタムパッケージをインポートし、インポートエラーを捕捉し、``main()`` の ``fail_json()`` で処理します。以下は例となります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:89 -msgid "Then in ``main()``, just after the argspec, do" -msgstr "次に ``main()`` で、argspec の直後に以下を実行します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:98 -msgid "And document the dependency in the ``requirements`` section of your module's :ref:`documentation_block`." -msgstr "また、依存関係をモジュールの :ref:`documentation_block` の ``requirements`` セクションで記述します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:103 -msgid "Handling module failures" -msgstr "モジュール障害の処理" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:105 -msgid "When your module fails, help users understand what went wrong. If you are using the ``AnsibleModule`` common Python code, the ``failed`` element will be included for you automatically when you call ``fail_json``. For polite module failure behavior:" -msgstr "モジュールが失敗すると、ユーザーは問題を理解するのに役立ちます。一般的な Python コード ``AnsibleModule`` を使用している場合は、``fail_json`` の呼び出し時に自動的に ``failed`` 要素が含まれます。polite モジュールの失敗動作には、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:107 -msgid "Include a key of ``failed`` along with a string explanation in ``msg``. If you don't do this, Ansible will use standard return codes: 0=success and non-zero=failure." -msgstr "``msg`` の文字列の説明と共に ``failed`` のキーが含まれるようにします。これを行わないと、Ansible は標準の戻りコード 0=success および non-zero=failure を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:108 -msgid "Don't raise a traceback (stacktrace). Ansible can deal with stacktraces and automatically converts anything unparsable into a failed result, but raising a stacktrace on module failure is not user-friendly." -msgstr "トレースバック (スタックトレース) は発生させません。Ansible はスタックトレースを扱うことができ、解析できないものは自動的に失敗した結果に変換しますが、モジュールの失敗時にスタックトレースを発生させるのはユーザーフレンドリーではありません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:109 -msgid "Do not use ``sys.exit()``. Use ``fail_json()`` from the module object." -msgstr "``sys.exit()`` は使用しないでください。モジュールオブジェクトの ``fail_json()`` を使用してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:112 -msgid "Handling exceptions (bugs) gracefully" -msgstr "例外 (バグ) を正常に処理" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:114 -msgid "Validate upfront--fail fast and return useful and clear error messages." -msgstr "前もって検証します。早めに失敗し、有用で明確なエラーメッセージを返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:115 -msgid "Use defensive programming--use a simple design for your module, handle errors gracefully, and avoid direct stacktraces." -msgstr "防御的なプログラミングを使用します。モジュールにはシンプルなデザインを使用し、エラーを適切に処理し、直接のスタックトレースを回避します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:116 -msgid "Fail predictably--if we must fail, do it in a way that is the most expected. Either mimic the underlying tool or the general way the system works." -msgstr "予測可能な方法で失敗させます。失敗がどうしても避けられない場合は、最も期待される方法で失敗します。基礎となるツール、またはシステムの一般的な動作方法を模倣します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:117 -msgid "Give out a useful message on what you were doing and add exception messages to that." -msgstr "実行内容に関する有用なメッセージを表示して、それに例外メッセージを追加します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:118 -msgid "Avoid catchall exceptions, they are not very useful unless the underlying API gives very good error messages pertaining the attempted action." -msgstr "キャッチオール例外は使用しないでください。基になる API が試行されたアクションに関して非常に優れたエラーメッセージがない限り、これらの例外はほとんど役に立ちません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:123 -msgid "Creating correct and informative module output" -msgstr "正確で有益なモジュール出力を作成" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:125 -msgid "Modules must output valid JSON only. Follow these guidelines for creating correct, useful module output:" -msgstr "モジュールは有効な JSON のみを出力しなければなりません。正確で有用なモジュール出力を作成するには、以下のガイドラインに従ってください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:127 -msgid "Make your top-level return type a hash (dictionary)." -msgstr "最上位レベルの戻り値の型をハッシュ (ディレクトリー) にします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:128 -msgid "Nest complex return values within the top-level hash." -msgstr "複雑な戻り値をトップレベルのハッシュ内に入れ子にします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:129 -msgid "Incorporate any lists or simple scalar values within the top-level return hash." -msgstr "最上位レベルの戻り値ハッシュ内にリストや単純なスカラー値を組み込みます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:130 -msgid "Do not send module output to standard error, because the system will merge standard out with standard error and prevent the JSON from parsing." -msgstr "モジュールの出力を標準エラーに送らないでください。システムが標準エラーと標準出力をマージし、JSON の解析を妨げるためです。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:131 -msgid "Capture standard error and return it as a variable in the JSON on standard out. This is how the command module is implemented." -msgstr "標準エラーを取得し、標準出力の JSON で変数として返します。これは、コマンドモジュールの実装方法です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:132 -msgid "Never do ``print(\"some status message\")`` in a module, because it will not produce valid JSON output." -msgstr "有効な JSON 出力が生成されないため、モジュールで ``print(\"some status message\")`` を実行しないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:133 -msgid "Always return useful data, even when there is no change." -msgstr "変更がない場合でも、有用なデータを常に返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:134 -msgid "Be consistent about returns (some modules are too random), unless it is detrimental to the state/action." -msgstr "状態/アクションに有害でない限り、戻り値は一貫したものにしてください (モジュールによっては非常に乱雑なものもあります)。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:135 -msgid "Make returns reusable--most of the time you don't want to read it, but you do want to process it and re-purpose it." -msgstr "戻り値は再利用可能なものにします。ほとんどの場合は読むことはありませんが、処理して再利用できるものにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:136 -msgid "Return diff if in diff mode. This is not required for all modules, as it won't make sense for certain ones, but please include it when applicable." -msgstr "diff モードの場合は diff を返します。これは、特定のモジュールでは意味をなさないため、すべてのモジュールに必要なわけではありませんが、該当する場合には使用してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:137 -msgid "Enable your return values to be serialized as JSON with Python's standard `JSON encoder and decoder `_ library. Basic python types (strings, int, dicts, lists, and so on) are serializable." -msgstr "Python の標準の `JSON エンコーダーおよびデコーダー `_ ライブラリーで、戻り値を JSON としてシリアライズできるようにします。基本的な python タイプ (文字列、int、ディクショナリー、リストなど) はシリアライズ可能です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:138 -msgid "Do not return an object using exit_json(). Instead, convert the fields you need from the object into the fields of a dictionary and return the dictionary." -msgstr "exit_json() を使用してオブジェクトを返さないでください。代わりに、オブジェクトの必要なフィールドをディクショナリーのフィールドに変換して返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:139 -msgid "Results from many hosts will be aggregated at once, so your module should return only relevant output. Returning the entire contents of a log file is generally bad form." -msgstr "多数のホストからの結果が一度に集約されるため、モジュールは関連する出力だけを返すべきです。ログファイルの内容全体を返すのは、一般的には悪い形式です。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:141 -msgid "If a module returns stderr or otherwise fails to produce valid JSON, the actual output will still be shown in Ansible, but the command will not succeed." -msgstr "モジュールが stderr を返すか、有効な JSON の生成に失敗した場合でも、実際の出力は Ansible に表示されますが、コマンドは成功しません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:146 -msgid "Following Ansible conventions" -msgstr "Ansible の規則に準拠" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:148 -msgid "Ansible conventions offer a predictable user interface across all modules, playbooks, and roles. To follow Ansible conventions in your module development:" -msgstr "Ansible の規則は、すべてのモジュール、Playbook、ロールに渡って予測可能なユーザーインターフェースを提供します。モジュール開発において Ansible の規則に従うには、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:150 -msgid "Use consistent names across modules (yes, we have many legacy deviations - don't make the problem worse!)." -msgstr "モジュール間で一貫性のある名前を使用します (レガシーとの相違が多数あるため、問題を悪化させないようにしましょう)。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:151 -msgid "Use consistent options (arguments) within your module(s)." -msgstr "モジュール内で一貫したオプション (引数) を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:152 -msgid "Do not use 'message' or 'syslog_facility' as an option name, because this is used internally by Ansible." -msgstr "これは Ansible によって内部で使用されるため、オプション名には「message」または「syslog_facility」を使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:153 -msgid "Normalize options with other modules - if Ansible and the API your module connects to use different names for the same option, add aliases to your options so the user can choose which names to use in tasks and playbooks." -msgstr "他のモジュールでオプションを正規化します。Ansible と、モジュールが接続する API が同じオプションに異なる名前を使用している場合は、オプションにエイリアスを追加して、ユーザーがタスクおよび Playbook で使用する名前を選択できるようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:154 -msgid "Return facts from ``*_facts`` modules in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them." -msgstr "他のモジュールがそれらにアクセスできるように、:ref:`結果ディクショナリー` の ``ansible_facts`` フィールドの ``*_facts`` モジュールからファクトを返します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:155 -msgid "Implement ``check_mode`` in all ``*_info`` and ``*_facts`` modules. Playbooks which conditionalize based on fact information will only conditionalize correctly in ``check_mode`` if the facts are returned in ``check_mode``. Usually you can add ``supports_check_mode=True`` when instantiating ``AnsibleModule``." -msgstr "すべての ``*_info`` および ``*_facts`` モジュールに ``check_mode`` を実装します。ファクト情報をもとに条件付けされる Playbook は、ファクトが ``check_mode`` で返される場合にのみ ``check_mode`` で条件化されます。 通常は、``AnsibleModule`` をインスタンス化する時に ``supports_check_mode=True`` を追加することができます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:156 -msgid "Use module-specific environment variables. For example, if you use the helpers in ``module_utils.api`` for basic authentication with ``module_utils.urls.fetch_url()`` and you fall back on environment variables for default values, use a module-specific environment variable like :code:`API__USERNAME` to avoid conflicts between modules." -msgstr "モジュール固有の環境変数を使用します。たとえば、``module_utils.urls.fetch_url()`` での基本的な認証に ``module_utils.api`` のヘルパーを使用し、デフォルト値を環境変数に依存している場合は、モジュール間の競合を回避するために :code:`API__USERNAME` のようなモジュール固有の環境変数を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:157 -msgid "Keep module options simple and focused - if you're loading a lot of choices/states on an existing option, consider adding a new, simple option instead." -msgstr "モジュールのオプションはシンプルで焦点を絞ったものにします。既存のオプションに多くの選択肢や状態を読み込んでいる場合は、代わりに新しいシンプルなオプションを追加することを検討してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:158 -msgid "Keep options small when possible. Passing a large data structure to an option might save us a few tasks, but it adds a complex requirement that we cannot easily validate before passing on to the module." -msgstr "可能な場合はオプションのサイズを小さくします。大きなデータ構造をオプションに渡すと、いくつかの作業が省けるかもしれませんが、モジュールに渡す前に簡単に検証できない複雑な要件が追加されてしまいます。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:159 -msgid "If you want to pass complex data to an option, write an expert module that allows this, along with several smaller modules that provide a more 'atomic' operation against the underlying APIs and services. Complex operations require complex data. Let the user choose whether to reflect that complexity in tasks and plays or in vars files." -msgstr "複雑なデータをオプションに渡したいのであれば、それを可能にするエキスパートモジュールと、基礎となる API やサービスに対してより「アトミックな」操作を提供するいくつかの小さなモジュールを作成します。複雑な操作には複雑なデータが必要です。その複雑さをタスクやプレイに反映させるか、vars ファイルに反映させるかをユーザが選択できるようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:160 -msgid "Implement declarative operations (not CRUD) so the user can ignore existing state and focus on final state. For example, use ``started/stopped``, ``present/absent``." -msgstr "ユーザーが既存の状態を無視して最終的な状態に集中できるように、(CRUDではなく) 宣言的な操作を実装します。たとえば、``started/stopped``、``present/absent`` を使用します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:161 -msgid "Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it." -msgstr "最終状態が一貫したもの (別名、冪等性) になるようにします。同じシステムに対してモジュールを連続して 2 回実行すると 2 つの異なる状態になってしまう場合は、最終的な状態が一貫しているかどうかを再設計または書き換えてみてください。できない場合は、動作とその理由を記載してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:162 -msgid "Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options." -msgstr "通常は他のオプションで返されるキーに NA/None が使用されている場合でも、標準の Ansible の戻り値構造内で一貫性のある戻り値を提供します。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:166 -msgid "Module Security" -msgstr "モジュールのセキュリティー" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:168 -msgid "Avoid passing user input from the shell." -msgstr "シェルからユーザー入力を渡さないようにします。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:169 -msgid "Always check return codes." -msgstr "常に戻りコードを確認してください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:170 -msgid "You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``." -msgstr "``subprocess``、``Popen``、または ``os.system`` ではなく、常に ``module.run_command`` を使用する必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:171 -msgid "Avoid using the shell unless absolutely necessary." -msgstr "絶対に必要な場合を除き、シェルは使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:172 -msgid "If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``." -msgstr "シェルを使用する必要がある場合は、``use_unsafe_shell=True`` を ``module.run_command`` に渡す必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:173 -msgid "If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``." -msgstr "モジュールの変数が ``use_unsafe_shell=True`` を使用してユーザー入力から送られる場合は、``pipes.quote(x)`` でラップする必要があります。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:174 -msgid "When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https." -msgstr "URL を取得する際には、``ansible.module_utils.urls`` から ``fetch_url`` または ``open_url`` を使用してください。``urllib2`` を使用しないでください。TLS 証明書をネイティブで検証しないため、https では安全ではありません。" - -#: ../../rst/dev_guide/developing_modules_best_practices.rst:175 -msgid "Sensitive values marked with ``no_log=True`` will automatically have that value stripped from module return values. If your module could return these sensitive values as part of a dictionary key name, you should call the ``ansible.module_utils.basic.sanitize_keys()`` function to strip the values from the keys. See the ``uri`` module for an example." -msgstr "``no_log=True`` のマークが付いた機密値は自動的に、モジュールの戻り値から取り除かれます。モジュールがこれらの機密値をディクショナリーキー名の一部として返すことができる場合は、``ansible.module_utils.basic.sanitize_keys()`` 関数を呼び出してキーから値を取り除く必要があります。たとえば、``uri`` モジュールを参照してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:6 -msgid "Contributing your module to an existing Ansible collection" -msgstr "既存の Ansible コレクションへのモジュールの貢献" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:8 -msgid "If you want to contribute a module to an existing collection, you must meet the community's objective and subjective requirements. Please read the details below, and also review our :ref:`tips for module development `." -msgstr "既存のコレクションにモジュールを提供する場合は、コミュニティーの目的の要件と主体的な要件を満たす必要があります。以下の詳細を読み、「:ref:`モジュール開発のヒント `」も確認してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:10 -msgid "Modules accepted into certain collections are included in every Ansible release on PyPI. However, contributing to one of these collections is not the only way to distribute a module - you can :ref:`create your own collection `, embed modules in roles on Galaxy or simply share copies of your module code for :ref:`local use `." -msgstr "特定のコレクションで許可されるモジュールは、PyPI のすべての Ansible リリースに含まれます。ただし、これらのコレクションのいずれかに貢献することが、モジュールを配布する唯一の方法ではありません。:ref:`独自のコレクションの作成 ` は、Galaxy のロールにモジュールコードのコピーを埋め込んだり、:ref:`ローカルでの使用 ` 用にモジュールコードのコピーを共有することもできます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:13 -msgid "Contributing modules: objective requirements" -msgstr "モジュールの貢献: 目的要件" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:15 -msgid "To contribute a module to most Ansible collections, you must:" -msgstr "モジュールをほとんどの Ansible コレクションに提供するには、以下を行う必要があります。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:17 -msgid "write your module in either Python or Powershell for Windows" -msgstr "Windows 用の Python または Powershell のいずれかでモジュールを書き込みます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:18 -msgid "use the ``AnsibleModule`` common code" -msgstr "``AnsibleModule`` 共通コードを使用します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:19 -msgid "support Python 2.6 and Python 3.5 - if your module cannot support Python 2.6, explain the required minimum Python version and rationale in the requirements section in ``DOCUMENTATION``" -msgstr "Python 2.6 および Python 3.5 をサポートします。モジュールが Python 2.6 をサポートできない場合は、``DOCUMENTATION`` の要件セクションで、最低限必要な Python バージョンと根拠を説明します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:20 -msgid "use proper :ref:`Python 3 syntax `" -msgstr "適切な :ref:`Python 3 構文 ` を使用します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:21 -msgid "follow `PEP 8 `_ Python style conventions - see :ref:`testing_pep8` for more information" -msgstr "`PEP 8 `_ Python スタイルの規則に従います。詳細は「:ref:`testing_pep8`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:22 -msgid "license your module under the GPL license (GPLv3 or later)" -msgstr "GPL ライセンス (GPLv3 以降) でモジュールにライセンスを付与します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:23 -msgid "understand the :ref:`license agreement `, which applies to all contributions" -msgstr "すべての貢献に適用される :ref:`ライセンス合意 ` を理解します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:24 -msgid "conform to Ansible's :ref:`formatting and documentation ` standards" -msgstr "Ansible の :ref:`フォーマットおよびドキュメント ` の標準規格に準拠しています。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:25 -msgid "include comprehensive :ref:`tests ` for your module" -msgstr "モジュールに包括的な :ref:`テスト ` を含めます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:26 -msgid "minimize module dependencies" -msgstr "モジュール依存関係を最小限に抑えます。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:27 -msgid "support :ref:`check_mode ` if possible" -msgstr "可能な場合は :ref:`check_mode ` をサポートします。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:28 -msgid "ensure your code is readable" -msgstr "コードが読み取り可能であることを確認します。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:29 -msgid "if a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed." -msgstr "モジュールの名前が ``_facts`` なのは、``ansible_facts`` を返すことが主な目的だからです。これは、``_facts`` でこれを行わないモジュールに名前を付けないでください。ネットワークインターフェースやその設定や、オペレーティングシステムやインストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:30 -msgid "Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine." -msgstr "一般情報をクエリー/返送するモジュールは (``ansible_facts`` ではなく) ``_info`` という名前にする必要があります。一般情報とは、ホスト固有ではない情報、たとえば、オンライン/クラウドサービスに関する情報 (同じホストから同じオンラインサービスの異なるアカウントにアクセスできます)、または、マシンからアクセス可能な仮想マシンおよびコンテナーに関する情報になります。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:32 -msgid "Additional requirements may apply for certain collections. Review the individual collection repositories for more information." -msgstr "追加の要件は、特定のコレクションに適用される可能性があります。詳細は、個別のコレクションリポジトリーを参照してください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:34 -msgid "Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out by using the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) or the `Ansible development mailing list `_." -msgstr "PR/提案を送信する前に、お使いのモジュールがこれらの要件を満たしていることを確認してください。ご不明な点がございましたら、``#ansible-devel``チャットチャンネル (ansible.im で Matrix を使用、もしくは `irc.libera.chat `_ で IRC を使用) または `Ansible development mailing list `_ を使用してお問い合わせください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:37 -msgid "Contributing to Ansible: subjective requirements" -msgstr "Ansible への貢献: 主観的な要件" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:39 -msgid "If your module meets these objective requirements, collection maintainers will review your code to see if they think it's clear, concise, secure, and maintainable. They will consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, with no exact standards for acceptance. For the best chance of getting your module accepted, follow our :ref:`tips for module development `." -msgstr "モジュールがこれらの目的の要件を満たす場合は、コレクションのメンテナーが、明確、簡潔、安全であり、維持が可能であると考えるコードを確認します。モジュールが優れたユーザーエクスペリエンスを提供し、有用なエラーメッセージ、有益なデフォルトなどを提供するかどうかを考慮します。このプロセスは主観的で、正確な標準はありません。モジュールが受け入れられる可能性を最大限に高めるには、「:ref:`モジュール開発のヒント `」に従ってください。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:42 -msgid "Other checklists" -msgstr "その他のチェックリスト" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:44 -msgid ":ref:`Tips for module development `." -msgstr ":ref:`Tips for module development `。" - -#: ../../rst/dev_guide/developing_modules_checklist.rst:45 -msgid ":ref:`Windows development checklist `." -msgstr ":ref:`Windows development checklist `。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:6 -msgid "Module format and documentation" -msgstr "モジュールの形式およびドキュメント" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:8 -msgid "If you want to contribute your module to most Ansible collections, you must write your module in Python and follow the standard format described below. (Unless you're writing a Windows module, in which case the :ref:`Windows guidelines ` apply.) In addition to following this format, you should review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request." -msgstr "モジュールをほとんどの Ansible コレクションに貢献する場合は、Python でモジュールを作成して、その標準形式に従う必要があります。(Windows モジュールを作成したことがない場合。この場合は、:ref:`Windows ガイドライン ` が適用されます)。この形式に従うことに加え、プル要求を作成する前に、:ref:`提出のチェックリスト `、:ref:`プログラムのヒント `、:ref:`Python 2 および Python 3 互換性の維持のストラテジー ` と、:ref:`テスト ` に関する情報をお読みください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:10 -msgid "Every Ansible module written in Python must begin with seven standard sections in a particular order, followed by the code. The sections in order are:" -msgstr "Python で書かれたすべての Ansible モジュールは、特定の順序で 7 つの標準セクションから始まり、その後にコードが続きます。セクションの順番は以下のとおりです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:16 -msgid "Why don't the imports go first?" -msgstr "最初にインポートが行われないのはなぜですか。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:18 -msgid "Keen Python programmers may notice that contrary to PEP 8's advice we don't put ``imports`` at the top of the file. This is because the ``DOCUMENTATION`` through ``RETURN`` sections are not used by the module code itself; they are essentially extra docstrings for the file. The imports are placed after these special variables for the same reason as PEP 8 puts the imports after the introductory comments and docstrings. This keeps the active parts of the code together and the pieces which are purely informational apart. The decision to exclude E402 is based on readability (which is what PEP 8 is about). Documentation strings in a module are much more similar to module level docstrings, than code, and are never utilized by the module itself. Placing the imports below this documentation and closer to the code, consolidates and groups all related code in a congruent manner to improve readability, debugging and understanding." -msgstr "熱心な Python プログラマーは、PEP 8 のアドバイスに反して、ファイルの冒頭に ``imports`` を置いていないことに気づくかもしれません。これは、``RETURN`` までの ``DOCUMENTATION`` セクションはモジュールコード自体で使用されておらず、基本的にファイルに追加のドキュメント文字列を使用するためです。インポートは、PEP 8 と同じ理由でこれらの特別な変数の後に置かれ、紹介のコメントとドキュメント文字列の後にインポートを追加します。これにより、コードの活動的な部分が一緒になり、純粋に情報を提供する部分が分離されます。E402 を除外する意思決定は (PEP 8 の目的である) 可読性に基づいています。モジュール内のドキュメント文字列は、コードよりも、モジュールレベルのドキュメント文字列によく似ており、モジュール自体が利用することはありません。インポートを、このドキュメントの下の、よりコードに近いところに置くことで、関連するすべてのコードを統合してグループ化し、可読性、デバッグ、理解を向上させます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:20 -msgid "**Copy old modules with care!**" -msgstr "**古いモジュールは注意してコピーしてください。**" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:22 -msgid "Some older Ansible modules have ``imports`` at the bottom of the file, ``Copyright`` notices with the full GPL prefix, and/or ``DOCUMENTATION`` fields in the wrong order. These are legacy files that need updating - do not copy them into new modules. Over time we are updating and correcting older modules. Please follow the guidelines on this page!" -msgstr "一部の古い Ansible モジュールでは、ファイルの下部に ``imports`` があるため、``Copyright`` は完全な GPL プレフィックス、または ``DOCUMENTATION`` フィールドを間違った順序で持つことに注意してください。これらは更新が必要なレガシーファイルです。新しいモジュールにコピーしないでください。時間の経過とともに、古いモジュールを更新および修正しています。このページにはガイドラインに従うようにしてください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:24 -msgid "For non-Python modules you still create a ``.py`` file for documentation purposes. Starting at ansible-core 2.14 you can instead choose to create a ``.yml`` file that has the same data structure, but in pure YAML. With YAML files, the examples below are easy to use by removing Python quoting and substituting ``=`` for ``:``, for example ``DOCUMENTATION = r''' ... '''` ` to ``DOCUMENTATION: ...`` and removing closing quotes. :ref:`adjacent_yaml_doc`" -msgstr "非 Python モジュールの場合、引き続きドキュメント用に ``.py`` ファイルを作成します。ansible-core 2.14 以降では、同じデータ構造を持つ ``.yml`` ファイルを替わりに作成できますが、これは純粋な YAML です。YAML ファイルの場合、Python の引用符を削除して ``:`` を ``=`` に置き換えることで、以下の例が使いやすくなります (例: ``DOCUMENTATION = r''' ... '''` ` to ``DOCUMENTATION: ...`` and removing closing quotes. :ref:`adjacent_yaml_doc`)" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:31 -msgid "Python shebang & UTF-8 coding" -msgstr "Python シバンおよび UTF-8 コーディング" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:33 -msgid "Begin your Ansible module with ``#!/usr/bin/python`` - this \"shebang\" allows ``ansible_python_interpreter`` to work. Follow the shebang immediately with ``# -*- coding: utf-8 -*-`` to clarify that the file is UTF-8 encoded." -msgstr "``#!/usr/bin/python`` で Ansible モジュールを開始します (この「シバン」では ``ansible_python_interpreter`` が機能します)。ファイルが UTF-8 でエンコードされていることを明確にするために、シバンの直後に ``# -*- coding: utf-8 -*-`` を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:35 -msgid "Using ``#!/usr/bin/env``, makes ``env`` the interpreter and bypasses ``ansible__interpreter`` logic." -msgstr "``#!/usr/bin/env`` を使用すると、``env`` がインタープリターとなり ``ansible__interpreter`` 論理をバイパスします。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:36 -msgid "If you develop the module using a different scripting language, adjust the interpreter accordingly (``#!/usr/bin/``) so ``ansible__interpreter`` can work for that specific language." -msgstr "別のスクリプト言語を使用してモジュールを開発する場合は、インタープリターを適宜調整し (``#!/usr/bin/``)、その言語で ``ansible__interpreter`` が機能するようにします。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:37 -msgid "Binary modules do not require a shebang or an interpreter." -msgstr "バイナリーモジュールに shebang やインタープリターは必要ありません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:42 -msgid "Copyright and license" -msgstr "著作権およびライセンス" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:44 -msgid "After the shebang and UTF-8 coding, add a `copyright line `_ with the original copyright holder and a license declaration. The license declaration should be ONLY one line, not the full GPL prefix.:" -msgstr "シバンおよび UTF-8 コーディングの後に、元の著作権所有者およびライセンス宣言を含む `copyright line `_ を追加します。ライセンス宣言は、完全な GPL プレフィックスではなく、1 行のみにする必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:54 -msgid "Additions to the module (for instance, rewrites) are not permitted to add additional copyright lines other than the default copyright statement if missing:" -msgstr "モジュールを追加するときに、以下が欠けている場合に、デフォルトの著作権ステートメント以外に、著作権の行を追加できません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:60 -msgid "Any legal review will include the source control history, so an exhaustive copyright header is not necessary. Please do not include a copyright year. If the existing copyright statement includes a year, do not edit the existing copyright year. Any existing copyright header should not be modified without permission from the copyright author." -msgstr "法的レビューにはソース管理履歴が含まれるため、完全な著作権ヘッダーは必要ありません。著作権の年は含めないでください。既存の著作権ステートメントに年が含まれている場合は、既存の著作権の年を編集しないでください。既存の著作権ヘッダーは、著作権者の許可なしに変更しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:66 -msgid "ANSIBLE_METADATA block" -msgstr "ANSIBLE_METADATA ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:68 -msgid "Since we moved to collections we have deprecated the METADATA functionality, it is no longer required for modules, but it will not break anything if present." -msgstr "コレクションに移行しても METADATA 機能は非推奨になり、モジュールには必要なくなりましたが、存在しても何も破損しません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:74 -msgid "DOCUMENTATION block" -msgstr "DOCUMENTATION ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:76 -msgid "After the shebang, the UTF-8 coding, the copyright line, and the license section comes the ``DOCUMENTATION`` block. Ansible's online module documentation is generated from the ``DOCUMENTATION`` blocks in each module's source code. The ``DOCUMENTATION`` block must be valid YAML. You may find it easier to start writing your ``DOCUMENTATION`` string in an :ref:`editor with YAML syntax highlighting ` before you include it in your Python file. You can start by copying our `example documentation string `_ into your module file and modifying it. If you run into syntax issues in your YAML, you can validate it on the `YAML Lint `_ website." -msgstr "shebang、UTF-8 コーディング、著作権行、ライセンスセクションの後には、``DOCUMENTATION`` ブロックがあります。Ansible のオンラインモジュールドキュメントは、各モジュールのソースコード内の ``DOCUMENTATION`` ブロックから生成されます。``DOCUMENTATION`` ブロックは有効な YAML でなければなりません。Python ファイルに含める前に、``DOCUMENTATION`` の文字列を :ref:`YAML 構文の強調表示を使用したエディター ` に書き始めた方が簡単だと思うかもしれません。提供している `サンプルのドキュメントの文字列 `_ を自身のモジュールファイルにコピーして、それを修正することから始めることができます。YAML の構文に問題がある場合は、`YAML Lint `_ の Web サイトで検証することができます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:84 -msgid "Module documentation should briefly and accurately define what each module and option does, and how it works with others in the underlying system. Documentation should be written for broad audience--readable both by experts and non-experts." -msgstr "モジュールのドキュメントでは、各モジュールとオプションの動作について簡単かつ正確に定義し、基礎となるシステムで他のモジュールとどのように連携するかを説明します。ドキュメントは、専門家と非専門家の両方が読むことができるように、幅広い読者に向けて作成する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:79 -msgid "Descriptions should always start with a capital letter and end with a full stop. Consistency always helps." -msgstr "説明は常に大文字で始め、完全に終了する必要があります。一貫性は常に役立ちます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:80 -msgid "Verify that arguments in doc and module spec dict are identical." -msgstr "ドキュメントの引数と、モジュール仕様のディクショナリーが同じであることを確認します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:81 -msgid "For password / secret arguments ``no_log=True`` should be set." -msgstr "パスワード/シークレット引数 ``no_log=True`` を設定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:82 -msgid "For arguments that seem to contain sensitive information but **do not** contain secrets, such as \"password_length\", set ``no_log=False`` to disable the warning message." -msgstr "機密情報が含まれているように見えても「password_length」などのシークレットが **含まれていない** ように表示される引数には、``no_log=False`` を設定して警告メッセージを無効にします。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:83 -#: ../../rst/dev_guide/developing_modules_documenting.rst:152 -msgid "If an option is only sometimes required, describe the conditions. For example, \"Required when I(state=present).\"" -msgstr "オプションのみが必要な場合は、条件を記述してください。たとえば、「Required when I(state=present)」です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:84 -msgid "If your module allows ``check_mode``, reflect this fact in the documentation." -msgstr "モジュールで ``check_mode`` が許可されている場合は、これをドキュメントに反映させます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:86 -msgid "To create clear, concise, consistent, and useful documentation, follow the :ref:`style guide `." -msgstr "明確かつ簡潔で一貫性があり、便利なドキュメントは :ref:`スタイルガイド ` に従います。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:88 -msgid "Each documentation field is described below. Before committing your module documentation, please test it at the command line and as HTML:" -msgstr "各ドキュメントフィールドの説明は次のとおりです。モジュールのドキュメントをコミットする前に、コマンドラインおよび HTML でテストしてください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:90 -msgid "As long as your module file is :ref:`available locally `, you can use ``ansible-doc -t module my_module_name`` to view your module documentation at the command line. Any parsing errors will be obvious - you can view details by adding ``-vvv`` to the command." -msgstr "モジュールファイルが :ref:`ローカルで利用可能 ` な場合に限り、``ansible-doc -t module my_module_name`` を使用して、コマンドラインでモジュールのドキュメントを表示します。構文解析エラーは明確になります。コマンドに ``-vvv`` を追加すると、詳細を表示できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:91 -msgid "You should also :ref:`test the HTML output ` of your module documentation." -msgstr "モジュールのドキュメントにおける :ref:`HTML 出力のテスト ` も必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:95 -msgid "Documentation fields" -msgstr "ドキュメントフィールド" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:97 -msgid "All fields in the ``DOCUMENTATION`` block are lower-case. All fields are required unless specified otherwise:" -msgstr "``DOCUMENTATION`` ブロックのフィールドはすべて小文字になります。特に指定がない場合は、すべてのフィールドが必要になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:101 -msgid "The name of the module." -msgstr "モジュールの名前。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:102 -msgid "Must be the same as the filename, without the ``.py`` extension." -msgstr "ファイル名と同じ (``.py`` 拡張子なし) である必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "short_description" -msgstr "short_description" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:106 -msgid "A short description which is displayed on the :ref:`list_of_collections` page and ``ansible-doc -l``." -msgstr ":ref:`list_of_collections` ページと ``ansible-doc -l`` に表示される簡単な説明です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:107 -msgid "The ``short_description`` is displayed by ``ansible-doc -l`` without any category grouping, so it needs enough detail to explain the module's purpose without the context of the directory structure in which it lives." -msgstr "``short_description`` は、カテゴリーをグループ化せずに、``ansible-doc -l`` によって表示されます。そのため、モジュールが存在するディレクトリー構造のコンテキストなしでモジュールの目的を説明するのに十分な詳細が必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:109 -msgid "Unlike ``description:``, ``short_description`` should not have a trailing period/full stop." -msgstr "``description:`` とは異なり、``short_description`` のピリオド (文末) は設定しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "description" -msgstr "description" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:113 -msgid "A detailed description (generally two or more sentences)." -msgstr "詳細な説明 (通常は 2 文以上)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:114 -msgid "Must be written in full sentences, in other words, with capital letters and periods/full stops." -msgstr "文章の形、つまり冒頭の大文字やピリオド (文末) などを使用して記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:115 -msgid "Shouldn't mention the module name." -msgstr "モジュール名について言及すべきではありません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:116 -msgid "Make use of multiple entries rather than using one long paragraph." -msgstr "1 つの長い段落にせず、複数の文章に分けます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:117 -msgid "Don't quote complete values unless it is required by YAML." -msgstr "YAML で必要な場合を除き、完全な値を引用符で囲まないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "version_added" -msgstr "version_added" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:121 -msgid "The version of Ansible when the module was added." -msgstr "モジュールが追加された Ansible のバージョン。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:122 -msgid "This is a string, and not a float, for example, ``version_added: '2.1'``." -msgstr "これは浮動小数点ではなく文字列です (例: ``version_added: '2.1'``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:123 -msgid "In collections, this must be the collection version the module was added to, not the Ansible version. For example, ``version_added: 1.0.0``." -msgstr "コレクションでは、これは Ansible バージョンではなく、モジュールが追加されたコレクションバージョンでなければなりません (例: ``version_added: 1.0.0``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "author" -msgstr "author" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:127 -msgid "Name of the module author in the form ``First Last (@GitHubID)``." -msgstr "``First Last (@GitHubID)`` 形式のモジュール作成者の名前。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:128 -msgid "Use a multi-line list if there is more than one author." -msgstr "作成者が複数になる場合は、複数行のリストを使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:129 -msgid "Don't use quotes as it should not be required by YAML." -msgstr "YAML では必要ないため、引用符は使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "deprecated" -msgstr "deprecated" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:133 -msgid "Marks modules that will be removed in future releases. See also :ref:`module_lifecycle`." -msgstr "将来のリリースで削除されるモジュールにマークを付けします。「:ref:`module_lifecycle`」も併せて参照してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "options" -msgstr "options" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:137 -msgid "Options are often called `parameters` or `arguments`. Because the documentation field is called `options`, we will use that term." -msgstr "オプションは、多くの場合、`パラメーター` または `引数` と呼ばれます。ドキュメントフィールドは `オプション` を呼ばれるため、ここではその用語を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:138 -msgid "If the module has no options (for example, it's a ``_facts`` module), all you need is one line: ``options: {}``." -msgstr "モジュールにオプションがない (例: ``_facts`` モジュール) 場合、必要なのは 1 行 (``options: {}``) だけです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:139 -msgid "If your module has options (in other words, accepts arguments), each option should be documented thoroughly. For each module option, include:" -msgstr "モジュールにオプションがある (つまり引数を受け入れる) 場合、各オプションは詳細に文書化される必要があります。各モジュールオプションについて、以下を記載します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "option-name" -msgstr "option-name" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:143 -msgid "Declarative operation (not CRUD), to focus on the final state, for example `online:`, rather than `is_online:`." -msgstr "(CRUD ではなく) 宣言操作は、「`is_online:`」ではなく、「`online:`」などの最終状態に焦点をあてます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:144 -msgid "The name of the option should be consistent with the rest of the module, as well as other modules in the same category." -msgstr "オプションの名前は、そのモジュールの残りの部分、および同じカテゴリーの他のモジュールと一貫性を持たせる必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:145 -msgid "When in doubt, look for other modules to find option names that are used for the same purpose, we like to offer consistency to our users." -msgstr "不明な場合は、他のモジュールを探して、同じ目的で使用されているオプション名を見つけてください。ユーザーに一貫性を提供できるようにしています。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:149 -msgid "Detailed explanation of what this option does. It should be written in full sentences." -msgstr "このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:150 -msgid "The first entry is a description of the option itself; subsequent entries detail its use, dependencies, or format of possible values." -msgstr "最初のエントリーは、オプションそのものの説明です。後続のエントリーは、その使用、依存関係、または使用できる値の形式の詳細を説明します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:151 -msgid "Should not list the possible values (that's what ``choices:`` is for, though it should explain what the values do if they aren't obvious)." -msgstr "可能な値を列挙しないでください (``choices:`` はそのためにあります。値が明らかでない場合は、その値が何を示すのかを説明してください)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:153 -msgid "Mutually exclusive options must be documented as the final sentence on each of the options." -msgstr "相互に排他的なオプションは、各オプションの最後の文で文書化する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:157 -msgid "Only needed if ``true``." -msgstr "``true`` の場合にのみ必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:158 -msgid "If missing, we assume the option is not required." -msgstr "見つからない場合は、オプションが不要であると仮定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "default" -msgstr "default" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:162 -msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)." -msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:163 -msgid "Ensure that the default value in the docs matches the default value in the code." -msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:164 -msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions." -msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:165 -msgid "If the option is a boolean value, you can use any of the boolean values recognized by Ansible: (such as true/false or yes/no). Choose the one that reads better in the context of the option." -msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "choices" -msgstr "choices" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:170 -msgid "List of option values." -msgstr "オプション値のリスト。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:171 -msgid "Should be absent if empty." -msgstr "空欄の場合は指定なしになります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "type" -msgstr "タイプ" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:175 -msgid "Specifies the data type that option accepts, must match the ``argspec``." -msgstr "オプションで使用できるデータ型を指定します。``argspec`` と一致させる必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:176 -msgid "If an argument is ``type='bool'``, this field should be set to ``type: bool`` and no ``choices`` should be specified." -msgstr "引数が ``type='bool'`` の場合、このフィールドは ``type: bool`` に設定されます。``choices`` は指定しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:177 -msgid "If an argument is ``type='list'``, ``elements`` should be specified." -msgstr "引数が ``type='list'`` の場合は、``elements`` を指定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "elements" -msgstr "elements" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:181 -msgid "Specifies the data type for list elements in case ``type='list'``." -msgstr "``type='list'`` の場合に、リスト要素のデータ型を指定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "aliases" -msgstr "aliases" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:184 -msgid "List of optional name aliases." -msgstr "任意の名前エイリアスのリスト。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:185 -msgid "Generally not needed." -msgstr "一般的には必要ありません。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:189 -msgid "Only needed if this option was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field." -msgstr "このオプションが Ansible の初回リリース後に拡張されている場合にのみ必要です。つまり、これは最上位レベルの `version_added` フィールドよりも大きくなります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:190 -msgid "This is a string, and not a float, for example, ``version_added: '2.3'``." -msgstr "これは浮動小数点ではなく文字列です (例: ``version_added: '2.3'``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:191 -msgid "In collections, this must be the collection version the option was added to, not the Ansible version. For example, ``version_added: 1.0.0``." -msgstr "コレクションでは、これは Ansible バージョンではなく、オプションが追加されたコレクションバージョンでなければなりません (例: ``version_added: 1.0.0``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "suboptions" -msgstr "suboptions" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:195 -msgid "If this option takes a dict or list of dicts, you can define the structure here." -msgstr "このオプションがディクショナリーまたはディクショナリーのリストを取る場合は、ここで構造を定義できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:196 -msgid "See :ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`, :ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`, and :ref:`ansible_collections.openstack.cloud.baremetal_node_action_module` for examples." -msgstr "例は、「:ref:`ansible_collections.azure.azcollection.azure_rm_securitygroup_module`」、「:ref:`ansible_collections.azure.azcollection.azure_rm_azurefirewall_module`」、および「:ref:`ansible_collections.openstack.cloud.baremetal_node_action_module`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "requirements" -msgstr "requirements" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:200 -msgid "List of requirements (if applicable)." -msgstr "要件のリスト (該当する場合)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:201 -msgid "Include minimum versions." -msgstr "最小バージョンを指定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "seealso" -msgstr "seealso" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:205 -msgid "A list of references to other modules, documentation or Internet resources" -msgstr "その他のモジュール、ドキュメント、またはインターネットリソースへの参照の一覧。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:206 -msgid "In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-core``." -msgstr "Ansible 2.10 以降では、モジュールへの参照が ``ansible-core`` のモジュールに FQCN または ``ansible.builtin`` を使用する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:207 -msgid "A reference can be one of the following formats:" -msgstr "参照には、以下の形式のいずれかを使用できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:235 -msgid "If you use ``ref:`` to link to an anchor that is not associated with a title, you must add a title to the ref for the link to work correctly." -msgstr "``ref:`` を使用してタイトルと関連付けられていないアンカーにリンクする場合は、リンクが正しく機能するように ref にタイトルを追加する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:236 -msgid "You can link to non-module plugins with ``ref:`` using the rST anchor, but plugin and module anchors are never associated with a title, so you must supply a title when you link to them. For example ``ref: namespace.collection.plugin_name lookup plugin ``." -msgstr "rST アンカーを使用して ``ref:`` でモジュール以外のプラグインにリンクできますが、プラグインおよびモジュールアンカーはタイトルと関連付けられないため、リンクする際にタイトルを指定する必要があります。たとえば、``ref: namespace.collection.plugin_name lookup plugin `` となります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "notes" -msgstr "notes" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:241 -msgid "Details of any important information that doesn't fit in one of the above sections." -msgstr "上記のセクションのいずれかに該当しない重要な情報の詳細です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:242 -msgid "For example, whether ``check_mode`` is or is not supported." -msgstr "たとえば、``check_mode`` がサポートされるかどうかなどです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:247 -msgid "Linking and other format macros within module documentation" -msgstr "モジュールドキュメント内のリンクおよびその他の形式マクロ" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:249 -msgid "You can link from your module documentation to other module docs, other resources on docs.ansible.com, and resources elsewhere on the internet with the help of some pre-defined macros. The correct formats for these macros are:" -msgstr "モジュールドキュメントから他のモジュールドキュメント、docs.ansible.com の他のリソース、一部の事前設定マクロでインターネット上の他のリソースにリンクできます。これらのマクロの正しい形式は次のとおりです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:251 -msgid "``L()`` for links with a heading. For example: ``See L(Ansible Automation Platform,https://www.ansible.com/products/automation-platform).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation." -msgstr "``L()`` 見出しへのリンク。たとえば、``See L(Ansible Automation Platform,https://www.ansible.com/products/automation-platform).`` となります。Ansible 2.10 以降、Ansible ドキュメントとコレクションのドキュメントの相対リンクには ``L()`` を使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:252 -msgid "``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/automation-platform) for an overview.``" -msgstr "URL の場合は ``U()``。たとえば、``See U(https://www.ansible.com/products/automation-platform) for an overview.`` となります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:253 -msgid "``R()`` for cross-references with a heading (added in Ansible 2.10). For example: ``See R(Cisco IOS Platform Guide,ios_platform_options)``. Use the RST anchor for the cross-reference. See :ref:`adding_anchors_rst` for details." -msgstr "(Ansible 2.10 に含まれる) 見出しと相互参照用 ``R()`` (例: ``See R(Cisco IOS Platform Guide,ios_platform_options)``)。クロス参照に RST アンカーを使用します。詳細は、:ref:`adding_anchors_rst` を参照してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:254 -msgid "``M()`` for module names. For example: ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)``." -msgstr "``M()`` モジュール名。たとえば ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)`` になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:256 -msgid "There are also some macros which do not create links but we use them to display certain types of content in a uniform way:" -msgstr "リンクを作成しないものの、そのマクロを使用して、特定のタイプのコンテンツを統一して表示します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:259 -msgid "``I()`` for option names. For example: ``Required if I(state=present).`` This is italicized in the documentation." -msgstr "オプション名の場合は ``I()``。たとえば ``Required if I(state=present).`` です。これは、ドキュメントではイタリック体で示されています。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:261 -msgid "``C()`` for files, option values, and inline code. For example: ``If not set the environment variable C(ACME_PASSWORD) will be used.`` or ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.`` This displays with a mono-space font in the documentation." -msgstr "ファイル、オプション値、およびインラインコードの場合は ``C()`` (例 ``If not set the environment variable C(ACME_PASSWORD) will be used.`` または ``Use C(var | foo.bar.my_filter) to transform C(var) into the required format.``)。これは、ドキュメントでは Monospace フォントと表示されます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:262 -msgid "``B()`` currently has no standardized usage. It is displayed in boldface in the documentation." -msgstr "現時点で、``B()`` の標準化された使用方法はありません。このドキュメントでは太字で表示されます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:263 -msgid "``HORIZONTALLINE`` is used sparingly as a separator in long descriptions. It becomes a horizontal rule (the ``
    `` html tag) in the documentation." -msgstr "``HORIZONTALLINE`` は、長い説明では、区切り文字として慎重に使用されており、ドキュメント内の水平ルール (``
    `` html タグ) になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:267 -msgid "For links between modules and documentation within a collection, you can use any of the options above. For links outside of your collection, use ``R()`` if available. Otherwise, use ``U()`` or ``L()`` with full URLs (not relative links). For modules, use ``M()`` with the FQCN or ``ansible.builtin`` as shown in the example. If you are creating your own documentation site, you will need to use the `intersphinx extension `_ to convert ``R()`` and ``M()`` to the correct links." -msgstr "コレクション内のモジュールとドキュメント間のリンクについては、上記のオプションのいずれかを使用することができます。コレクション外のリンクについては、利用可能な場合は ``R()`` を使用します。利用できない場合は、(相対リンクではなく) 完全な URL で ``U()`` または ``L()`` を使用します。モジュールの場合は、例のように、FQCN または ``ansible.builtin`` で ``M()`` を使用します。独自のドキュメントサイトを作成する場合は、`intersphinx 表現 `_ を使用して ``R()`` および ``M()`` を正しいリンクに変換する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:270 -msgid "To refer to a group of modules in a collection, use ``R()``. When a collection is not the right granularity, use ``C(..)``:" -msgstr "コレクション内のモジュールのグループを参照するには、``R()`` を使用します。コレクションが適切な粒度ではない場合は、``C(..)`` を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:272 -msgid "``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.``" -msgstr "``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.``" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:273 -msgid "``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``" -msgstr "``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:277 -msgid "Because it stands out better, use ``seealso`` for general references over the use of notes or adding links to the description." -msgstr "``seealso`` の方が目立つため、一般的な参照にはノートの使用や説明へのリンクよりも、``seealso`` を使用することが推奨されます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:282 -msgid "Documentation fragments" -msgstr "ドキュメントフラグメント" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:284 -msgid "If you are writing multiple related modules, they may share common documentation, such as authentication details, file mode settings, ``notes:`` or ``seealso:`` entries. Rather than duplicate that information in each module's ``DOCUMENTATION`` block, you can save it once as a doc_fragment plugin and use it in each module's documentation. In Ansible, shared documentation fragments are contained in a ``ModuleDocFragment`` class in `lib/ansible/plugins/doc_fragments/ `_ or the equivalent directory in a collection. To include a documentation fragment, add ``extends_documentation_fragment: FRAGMENT_NAME`` in your module documentation. Use the fully qualified collection name for the FRAGMENT_NAME (for example, ``kubernetes.core.k8s_auth_options``)." -msgstr "複数の関連モジュールを記述している場合は、認証の詳細やファイルモードの設定、``notes:`` や ``seealso:`` のエントリーなど、共通のドキュメントを共有していることがあります。そのような情報を各モジュールの ``DOCUMENTATION`` ブロックに複製するのではなく、doc_fragment プラグインとして一度保存し、各モジュールのドキュメントで使用することができます。Ansible では、共有ドキュメントフラグメントは、`lib/ansible/plugins/doc_fragments/ `_ の ``ModuleDocFragment`` クラス、またはコレクションの同等のディレクトリーに含まれています。ドキュメントフラグメントを含めるには、モジュールのドキュメントに ``extends_documentation_fragment: FRAGMENT_NAME`` を追加します。FRAGMENT_NAME には、完全修飾されたコレクション名を使用します (例: ``kubernetes.core.k8s_auth_options``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:286 -msgid "Modules should only use items from a doc fragment if the module will implement all of the interface documented there in a manner that behaves the same as the existing modules which import that fragment. The goal is that items imported from the doc fragment will behave identically when used in another module that imports the doc fragment." -msgstr "モジュールがドキュメントフラグメントのアイテムを使用するのは、そのフラグメントをインポートする既存のモジュールと同じように動作して、ドキュメント化されたすべてのインターフェースをモジュールが実装する場合のみです。目標は、ドキュメントフラグメントからインポートされたアイテムが、ドキュメントフラグメントをインポートする別のモジュールで使用された場合と同じように動作することです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:288 -msgid "By default, only the ``DOCUMENTATION`` property from a doc fragment is inserted into the module documentation. It is possible to define additional properties in the doc fragment in order to import only certain parts of a doc fragment or mix and match as appropriate. If a property is defined in both the doc fragment and the module, the module value overrides the doc fragment." -msgstr "デフォルトでは、ドキュメントフラグメントの ``DOCUMENTATION`` プロパティーがモジュールのドキュメントに挿入されます。ドキュメントフラグメントの特定の部分のみをインポートするため、または必要に応じて組み合わせて一致させるために、ドキュメントフラグメントに追加のプロパティーを定義することができます。プロパティーがドキュメントフラグメントとモジュールの両方で定義されている場合、モジュール値はドキュメントフラグメントを上書きします。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:290 -msgid "Here is an example doc fragment named ``example_fragment.py``:" -msgstr "以下は、``example_fragment.py`` という名前のドキュメントフラグメントの例です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:308 -msgid "To insert the contents of ``OTHER`` in a module:" -msgstr "``OTHER`` の内容をモジュールに挿入するには、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:314 -msgid "Or use both :" -msgstr "または、以下の両方を使用してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:327 -msgid "Since Ansible 2.8, you can have user-supplied doc_fragments by using a ``doc_fragments`` directory adjacent to play or role, just like any other plugin." -msgstr "Ansible 2.8 以降、その他のプラグインと同様に、プレイやロールに隣接する ``doc_fragments`` ディレクトリーを使用することで、ユーザーが提供するドキュメントフラグメントを設定できます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:329 -msgid "For example, all AWS modules should include:" -msgstr "たとえば、すべての AWS モジュールには以下を含める必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:337 -msgid ":ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection." -msgstr "「:ref:`docfragments_collections`」では、コレクションにドキュメントのフラグメントを組み込む方法を説明します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:342 -msgid "EXAMPLES block" -msgstr "EXAMPLES ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:344 -msgid "After the shebang, the UTF-8 coding, the copyright line, the license section, and the ``DOCUMENTATION`` block comes the ``EXAMPLES`` block. Here you show users how your module works with real-world examples in multi-line plain-text YAML format. The best examples are ready for the user to copy and paste into a playbook. Review and update your examples with every change to your module." -msgstr "シバンの後、UTF-8 コーディング、著作権表示、ライセンスセクション、および ``DOCUMENTATION`` ブロックの後に ``EXAMPLES`` ブロックが続きます。ここでは、モジュールが実際の例で複数行のプレーンテキスト YAML 形式でどのように機能するかをユーザーに示します。最良の例は、ユーザーがコピーして Playbook に貼り付ける準備ができています。モジュールに変更を加えるたびに、例を確認して更新してください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:346 -msgid "Per playbook best practices, each example should include a ``name:`` line:" -msgstr "Playbook のベストプラクティスに基づき、各例には ``name:`` 行が必要です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:357 -msgid "The ``name:`` line should be capitalized and not include a trailing dot." -msgstr "``name:`` 行は大文字にし、末尾のドットは含めないでください。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:359 -msgid "Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-core``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``." -msgstr "上記の例のように、モジュール名の一部として完全修飾コレクション名 (FQCN) を使用します。``ansible-core`` のモジュールの場合は、``ansible.builtin.`` 識別子 (たとえば ``ansible.builtin.debug``) を使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:361 -msgid "If your examples use boolean options, use yes/no values. Since the documentation generates boolean values as yes/no, having the examples use these values as well makes the module documentation more consistent." -msgstr "サンプルでブール値オプションを使用する場合は、yes/no の値を使用します。ドキュメントによりブール値が yes/no として生成されるため、このサンプルではこれらの値が使用されており、モジュールドキュメントの一貫性が保たれます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:363 -msgid "If your module returns facts that are often needed, an example of how to use them can be helpful." -msgstr "モジュールが必要なファクトを返すと、その使用方法の例が便利です。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:368 -msgid "RETURN block" -msgstr "RETURN ブロック" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:370 -msgid "After the shebang, the UTF-8 coding, the copyright line, the license section, ``DOCUMENTATION`` and ``EXAMPLES`` blocks comes the ``RETURN`` block. This section documents the information the module returns for use by other modules." -msgstr "シバン、UTF-8コーディング、著作権表示、ライセンスセクション、``DOCUMENTATION`` ブロックおよび ``EXAMPLES`` ブロックの後に、``RETURN`` ブロックが続きます。このセクションでは、モジュールが他のモジュールで使用するために返す情報を説明します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:372 -msgid "If your module doesn't return anything (apart from the standard returns), this section of your module should read: ``RETURN = r''' # '''`` Otherwise, for each value returned, provide the following fields. All fields are required unless specified otherwise." -msgstr "モジュールが何も返さない場合は (標準の戻り値とは異なり)、モジュールのこのセクションは ``RETURN = r''' # '''`` を読み取る必要があります。それ以外の場合は、返された各値に以下のフィールドを指定します。特に指定がない場合はすべてのフィールドが必要になります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "return name" -msgstr "return name" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:376 -msgid "Name of the returned field." -msgstr "返されるフィールドの名前。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:379 -msgid "Detailed description of what this value represents. Capitalized and with trailing dot." -msgstr "この値が表す内容の詳細な説明。大文字で、末尾のドットを使用します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "returned" -msgstr "returned" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:381 -msgid "When this value is returned, such as ``always``, ``changed`` or ``success``. This is a string and can contain any human-readable content." -msgstr "``always``、``changed``、``success`` などのこの値が返されると、これは文字列となり、人間が判読できるコンテンツを含めることができます。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:383 -msgid "Data type." -msgstr "データ型。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:385 -msgid "If ``type='list'``, specifies the data type of the list's elements." -msgstr "``type='list'`` の場合は、リストの要素のデータタイプを指定します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "sample" -msgstr "sample" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:387 -msgid "One or more examples." -msgstr "1 つ以上の例。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:389 -msgid "Only needed if this return was extended after initial Ansible release, in other words, this is greater than the top level `version_added` field. This is a string, and not a float, for example, ``version_added: '2.3'``." -msgstr "これは、最初の Ansible リリースの後にこの返された場合にのみ必要です。つまり、これは最上位レベルの `version_added` フィールドよりも大きくなります。これは浮動小数点ではなく、文字列です (例: ``version_added: '2.3'``)。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst -msgid "contains" -msgstr "contains" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:392 -msgid "Optional. To describe nested return values, set ``type: dict``, or ``type: list``/``elements: dict``, or if you really have to, ``type: complex``, and repeat the elements above for each sub-field." -msgstr "任意です。ネストされた戻り値を記述するには、``type: dict`` または ``type: list``/``elements: dict`` を設定するか、本当に必要であれば ``type: complex`` を設定し、各サブフィールドに対して上記の要素を繰り返します。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:394 -msgid "Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field:" -msgstr "以下の例は、``RETURN`` セクションを 3 つの単純なフィールドと、複雑なネストされたフィールドを持つ 2 つのセクションです。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:444 -msgid "Python imports" -msgstr "Python のインポート" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:446 -msgid "After the shebang, the UTF-8 coding, the copyright line, the license, and the sections for ``DOCUMENTATION``, ``EXAMPLES``, and ``RETURN``, you can finally add the python imports. All modules must use Python imports in the form:" -msgstr "シバンの後には、UTF-8 コード行、著作権行、ライセンス、および ``DOCUMENTATION``、``EXAMPLES``、および ``RETURN`` のセクションが最後に python インポートを追加できます。すべてのモジュールは、この形式の Python インポートを使用する必要があります。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:452 -msgid "The use of \"wildcard\" imports such as ``from module_utils.basic import *`` is no longer allowed." -msgstr "``from module_utils.basic import *`` などの「ワイルドカード」インポートの使用は許可されなくなりました。" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:457 -msgid "Testing module documentation" -msgstr "モジュールドキュメンテーションのテスト" - -#: ../../rst/dev_guide/developing_modules_documenting.rst:459 -msgid "To test Ansible documentation locally please :ref:`follow instruction`. To test documentation in collections, please see :ref:`build_collection_docsite`." -msgstr "Ansible ドキュメントをローカルでテストする方法は、:ref:`の指示に従います。`また、コレクションのドキュメントをテストする場合は、:ref:`build_collection_docsite` を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:6 -msgid "Developing modules" -msgstr "モジュールの開発" - -#: ../../rst/dev_guide/developing_modules_general.rst:8 -msgid "A module is a reusable, standalone script that Ansible runs on your behalf, either locally or remotely. Modules interact with your local machine, an API, or a remote system to perform specific tasks like changing a database password or spinning up a cloud instance. Each module can be used by the Ansible API, or by the :command:`ansible` or :command:`ansible-playbook` programs. A module provides a defined interface, accepts arguments, and returns information to Ansible by printing a JSON string to stdout before exiting." -msgstr "モジュールは、Ansible がローカルまたはリモートのいずれかで実行する再利用可能なスタンドアロンスクリプトです。モジュールは、ローカルマシン、API、またはリモートシステムと対話し、データベースパスワードの変更やクラウドインスタンスの起動などの特定のタスクを実行します。各モジュールは、Ansible API または :command:`ansible` または :command:`ansible-playbook` プログラムで使用できます。モジュールは定義されたインターフェースを提供し、引数を受け入れ、終了前に JSON 文字列を stdout に出力して Ansible に情報を返します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:10 -msgid "If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module. When you write a module for local use, you can choose any programming language and follow your own rules. Use this topic to learn how to create an Ansible module in Python. After you create a module, you must add it locally to the appropriate directory so that Ansible can find and execute it. For details about adding a module locally, see :ref:`developing_locally`." -msgstr "コレクションにある数千の Ansible モジュールで利用できない機能が必要な場合は、独自のカスタムモジュールを簡単に作成できます。ローカルで使用するためのモジュールを作成する場合は、任意のプログラミング言語を選択して、独自のルールに従うようにすることができます。本トピックを使用して、Python で Ansible モジュールを作成する方法を説明します。モジュールを作成したら、Ansible が検出および実行できるように、これを適切なディレクトリーにローカルに追加する必要があります。ローカルでモジュールを追加する方法は、「:ref:`developing_locally`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:12 -msgid "If you are developing a module in a :ref:`collection `, see those documents instead." -msgstr ":ref:`collection ` でモジュールを開発する場合は、代わりにそれらのドキュメントを参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:20 -msgid "Preparing an environment for developing Ansible modules" -msgstr "Ansible モジュール開発用の環境の準備" - -#: ../../rst/dev_guide/developing_modules_general.rst:22 -msgid "You just need ``ansible-core`` installed to test the module. Modules can be written in any language, but most of the following guide is assuming you are using Python. Modules for inclusion in Ansible itself must be Python or Powershell." -msgstr "モジュールをテストするために必要なのは ``ansible-core`` のインストールのみです。モジュールはどの言語でも記述できますが、以下のガイドのほとんどは Python の使用を前提としています。Ansible 自体に含めるモジュールは Python または Powershell である必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:26 -msgid "One advantage of using Python or Powershell for your custom modules is being able to use the ``module_utils`` common code that does a lot of the heavy lifting for argument processing, logging and response writing, among other things." -msgstr "カスタムモジュールに Python または Powershell を使用する利点の 1 つは、引数処理、ロギング、応答の書き込みなど多くの面倒な処理が可能な ``module_utils`` の一般的なコードを使用できることです。" - -#: ../../rst/dev_guide/developing_modules_general.rst:30 -msgid "Creating a module" -msgstr "モジュールの作成" - -#: ../../rst/dev_guide/developing_modules_general.rst:32 -msgid "It is highly recommended that you use a ``venv`` or ``virtualenv`` for Python development." -msgstr "Python の開発には、``venv`` または ``virtualenv`` を使用することを強く推奨します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:34 -msgid "To create a module:" -msgstr "モジュールを作成するには、以下を行います。" - -#: ../../rst/dev_guide/developing_modules_general.rst:36 -msgid "Create a ``library`` directory in your workspace, your test play should live in the same directory." -msgstr "ワークスペースに ``library`` ディレクトリーを作成します。テストプレイは同じディレクトリーに置く必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:37 -msgid "Create your new module file: ``$ touch library/my_test.py``. Or just open/create it with your editor of choice." -msgstr "新しいモジュールファイル (``$ touch library/my_test.py``) を作成します。または、選択したエディターでそれを開くか、作成します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:38 -msgid "Paste the content below into your new module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code." -msgstr "以下の内容を新しいモジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント `、:ref:`モジュールオプションを宣言する単純な引数仕様 `、およびいくつかのサンプルコードが含まれます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:39 -msgid "Modify and extend the code to do what you want your new module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code." -msgstr "新しいモジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント `」ページおよび「:ref:`Python 3 互換性 `」ページを参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:45 -msgid "Creating an info or a facts module" -msgstr "情報またはファクトモジュールの作成" - -#: ../../rst/dev_guide/developing_modules_general.rst:47 -msgid "Ansible gathers information about the target machines using facts modules, and gathers information on other objects or files using info modules. If you find yourself trying to add ``state: info`` or ``state: list`` to an existing module, that is often a sign that a new dedicated ``_facts`` or ``_info`` module is needed." -msgstr "Ansible は、ファクトモジュールを使用してターゲットマシンに関する情報を収集し、info モジュールを使用して他のオブジェクトやファイルに関する情報を収集します。既存のモジュールに ``state: info`` または ``state: list`` を追加しようとする際は、多くの場合、これが新規の専用 ``_facts`` モジュールまたは ``_info`` モジュールが必要になるという署名になります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:50 -msgid "In Ansible 2.8 and onwards, we have two type of information modules, they are ``*_info`` and ``*_facts``." -msgstr "Ansible 2.8 以降では、2 種類の情報モジュール (``*_info`` および ``*_facts``) があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:52 -msgid "If a module is named ``_facts``, it should be because its main purpose is returning ``ansible_facts``. Do not name modules that do not do this with ``_facts``. Only use ``ansible_facts`` for information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed." -msgstr "モジュールの名前が ``_facts`` なのは、``ansible_facts`` を返すことが主な目的だからです。これは、``_facts`` でこれを行わないモジュールに名前を付けないでください。ネットワークインターフェースやその設定や、オペレーティングシステムやインストールされているプログラムなど、ホストマシンに固有の情報には ``ansible_facts`` のみを使用してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:55 -msgid "Modules that query/return general information (and not ``ansible_facts``) should be named ``_info``. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine, or information on individual files or programs." -msgstr "(``ansible_facts`` ではなく) 一般情報をクエリーまたは返すモジュールの名前は、``_info`` にする必要があります。オンライン/クラウドサービスに関する情報などの一般的な情報は、ホスト以外の固有の情報 (同じホストから同じオンラインサービスの異なるアカウントにアクセスできる)、マシンからアクセス可能な仮想マシンおよびコンテナーに関する情報、または個々のファイルまたはプログラムに関する情報です。" - -#: ../../rst/dev_guide/developing_modules_general.rst:58 -msgid "Info and facts modules, are just like any other Ansible Module, with a few minor requirements:" -msgstr "info モジュールおよび facts モジュールには、他の Ansible モジュールと同様に、さほど重要ではない要件があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:60 -msgid "They MUST be named ``_info`` or ``_facts``, where is singular." -msgstr "名前は ``_info`` または ``_facts`` です。 は単数になります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:61 -msgid "Info ``*_info`` modules MUST return in the form of the :ref:`result dictionary` so other modules can access them." -msgstr "info の ``*_info`` モジュールは、他のモジュールがアクセスできるように :ref:`結果ディレクトリー` の形式で返す必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:62 -msgid "Fact ``*_facts`` modules MUST return in the ``ansible_facts`` field of the :ref:`result dictionary` so other modules can access them." -msgstr "fact の ``*_facts`` モジュールは、他のモジュールがそれらにアクセスできるように :ref:`結果ディレクトリー` の ``ansible_facts`` フィールドに返す必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:63 -msgid "They MUST support :ref:`check_mode `." -msgstr ":ref:`check_mode ` をサポートする必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:64 -msgid "They MUST NOT make any changes to the system." -msgstr "システムに変更を加えないでください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:65 -msgid "They MUST document the :ref:`return fields` and :ref:`examples`." -msgstr ":ref:`return fields` および :ref:`examples` を文書化する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:67 -msgid "The rest is just like creating a normal module." -msgstr "残りは通常のモジュールを作成するのと同じです。" - -#: ../../rst/dev_guide/developing_modules_general.rst:70 -msgid "Verifying your module code" -msgstr "モジュールコードの確認" - -#: ../../rst/dev_guide/developing_modules_general.rst:72 -msgid "After you modify the sample code above to do what you want, you can try out your module. Our :ref:`debugging tips ` will help if you run into bugs as you verify your module code." -msgstr "上記のサンプルコードを修正したら、モジュールを試すことができます。:ref:`デバッグのヒント ` は、モジュールコードを検証する際にバグが発生した場合に役立ちます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:77 -msgid "Verifying your module code locally" -msgstr "モジュールコードのローカルでの確認" - -#: ../../rst/dev_guide/developing_modules_general.rst:79 -msgid "The simplest way is to use ``ansible`` adhoc command:" -msgstr "最も簡単な方法は、``ansible`` アドホックコマンドを使用することです。" - -#: ../../rst/dev_guide/developing_modules_general.rst:85 -msgid "If your module does not need to target a remote host, you can quickly and easily exercise your code locally like this:" -msgstr "モジュールがリモートホストを対象にする必要がない場合は、以下のようにコードをローカルで簡単に使用できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:91 -msgid "If for any reason (pdb, using print(), faster iteration, etc) you want to avoid going through Ansible, another way is to create an arguments file, a basic JSON config file that passes parameters to your module so that you can run it. Name the arguments file ``/tmp/args.json`` and add the following content:" -msgstr "何らかの理由で (pdb、print()、より高速な反復など) Ansible の使用を回避したい場合は、モジュールに引数ファイル (パラメーターを渡す基本的な JSON 設定ファイル) を作成して実行できるようにします。この引数ファイルには ``/tmp/args.json`` という名前を付け、以下の内容を追加します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:104 -msgid "Then the module can be tested locally and directly. This skips the packing steps and uses module_utils files directly:" -msgstr "モジュールはローカルで直接テストできるようになります。これにより、パッキングの手順が省略され、module_utils ファイルを直接使用できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:110 -msgid "It should return output like this:" -msgstr "この場合、以下のような出力が返されます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:119 -msgid "Verifying your module code in a playbook" -msgstr "Playbook でのモジュールコードの確認" - -#: ../../rst/dev_guide/developing_modules_general.rst:121 -msgid "You can easily run a full test by including it in a playbook, as long as the ``library`` directory is in the same directory as the play:" -msgstr "``library`` ディレクトリーがプレイと同じディレクトリーにある限り、Playbook に追加して完全なテストを簡単に実行できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:123 -msgid "Create a playbook in any directory: ``$ touch testmod.yml``" -msgstr "任意のディレクトリーに Playbook を作成します (``$ touch testmod.yml``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:124 -#: ../../rst/dev_guide/developing_modules_general_windows.rst:566 -msgid "Add the following to the new playbook file:" -msgstr "以下を新しい Playbook ファイルに追加します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:140 -msgid "Run the playbook and analyze the output: ``$ ansible-playbook ./testmod.yml``" -msgstr "Playbook を実行し、出力を分析します (``$ ansible-playbook ./testmod.yml``)。" - -#: ../../rst/dev_guide/developing_modules_general.rst:143 -msgid "Testing your newly-created module" -msgstr "新たに作成したモジュールのテスト" - -#: ../../rst/dev_guide/developing_modules_general.rst:145 -msgid "The following two examples will get you started with testing your module code. Please review our :ref:`testing ` section for more detailed information, including instructions for :ref:`testing module documentation `, adding :ref:`integration tests `, and more." -msgstr "以下の 2 つの例は、モジュールコードのテストを開始します。:ref:`モジュールのテストのドキュメント ` の手順、:ref:`統合テスト ` の追加などの詳細な情報は、:ref:`テスト ` のセクションを参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:149 -msgid "If contributing to Ansible, every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_." -msgstr "Ansible に貢献する場合、テストを Ansible CI インフラストラクチャーで実行できなくても、新しいモジュールとプラグインには統合テストが必要です。この場合、テストは `aliases file `_ の ``unsupported`` エイリアスでマーク付けする必要があります。" - -#: ../../rst/dev_guide/developing_modules_general.rst:153 -msgid "Performing sanity tests" -msgstr "健全性テストの実行" - -#: ../../rst/dev_guide/developing_modules_general.rst:155 -msgid "You can run through Ansible's sanity checks in a container:" -msgstr "Ansible の健全性チェックをコンテナーで実行できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:157 -msgid "``$ ansible-test sanity -v --docker --python 3.10 MODULE_NAME``" -msgstr "``$ ansible-test sanity -v --docker --python 3.10 MODULE_NAME``" - -#: ../../rst/dev_guide/developing_modules_general.rst:160 -msgid "Note that this example requires Docker to be installed and running. If you'd rather not use a container for this, you can choose to use ``--venv`` instead of ``--docker``." -msgstr "この例では、Docker をインストールして実行する必要があります。コンテナーを使用しない場合は、``--docker`` の代わりに ``--venv`` を使用できます。" - -#: ../../rst/dev_guide/developing_modules_general.rst:164 -msgid "Contributing back to Ansible" -msgstr "Ansible への貢献" - -#: ../../rst/dev_guide/developing_modules_general.rst:166 -msgid "If you would like to contribute to ``ansible-core`` by adding a new feature or fixing a bug, `create a fork `_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target." -msgstr "新しい機能を追加したりバグを修正したりして、``ansible-core`` に貢献する場合は、ansible/ansible リポジトリーの `フォークの作成 `_ し、開始点として ``devel`` ブランチを使用して新機能ブランチに対して開発します。適切な作業コードも変更がある場合は、機能ブランチをソースとして、および Ansible devel ブランチをターゲットとして選択し、Ansible リポジトリーにプル要求を送信します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:168 -msgid "If you want to contribute a module to an :ref:`Ansible collection `, review our :ref:`submission checklist `, :ref:`programming tips `, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility `, as well as information about :ref:`testing ` before you open a pull request." -msgstr "モジュールを :ref:`Ansible コレクション ` に提供する場合は、「:ref:`提出のチェックアウト `」、「:ref:`プログラムのヒント `」、ならびに「:ref:`Python 2 および Python 3 の互換性を維持するストラテジー `」を確認してください。プル要求を作成する前に、:ref:`テスト ` に関する情報も併せて参照してください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:170 -msgid "The :ref:`Community Guide ` covers how to open a pull request and what happens next." -msgstr "『:ref:`コミュニティーガイド `』では、プル要求を開く方法と、次に実行することを説明します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:174 -msgid "Communication and development support" -msgstr "通信および開発のサポート" - -#: ../../rst/dev_guide/developing_modules_general.rst:176 -msgid "Join the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) for discussions surrounding Ansible development." -msgstr "``#ansible-devel`` チャットチャンネル（ansible.imでMatrixを使用、または`irc.libera.chat `でIRCを使用）に参加して、Ansible の開発に関する議論を行います。" - -#: ../../rst/dev_guide/developing_modules_general.rst:178 -msgid "For questions and discussions pertaining to using the Ansible product, join the ``#ansible`` channel." -msgstr "Ansible 製品の使用に関する質問および貢献については、``#ansible`` チャンネルに参加します。" - -#: ../../rst/dev_guide/developing_modules_general.rst:180 -msgid "To find other topic-specific chat channels, look at :ref:`Community Guide, Communicating `." -msgstr "他のトピック固有のチャットチャンネルを探すには、:ref:`Community Guide, Communicating ` をご覧ください。" - -#: ../../rst/dev_guide/developing_modules_general.rst:183 -msgid "Credit" -msgstr "謝辞" - -#: ../../rst/dev_guide/developing_modules_general.rst:185 -msgid "Thank you to Thomas Stringer (`@trstringer `_) for contributing source material for this topic." -msgstr "このトピックの元となる資料を提供していただいた Thomas Stringer (`@trstringer `_) 氏に感謝の意を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:5 -msgid "Windows module development walkthrough" -msgstr "Windows モジュール開発ウォークスルー" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:7 -msgid "In this section, we will walk through developing, testing, and debugging an Ansible Windows module." -msgstr "本セクションでは、Ansible Windows モジュールの開発、テスト、およびデバッグの開発手順 (ウォークスルー) を説明します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:10 -msgid "Because Windows modules are written in Powershell and need to be run on a Windows host, this guide differs from the usual development walkthrough guide." -msgstr "Windows モジュールは Powershell で書かれており、Windows ホスト上で実行する必要があるため、このガイドは通常の開発ウォークスルーガイドとは異なります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:13 -msgid "What's covered in this section:" -msgstr "本項で取り上げられている内容:" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:20 -msgid "Windows environment setup" -msgstr "Windows 環境の設定" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:22 -msgid "Unlike Python module development which can be run on the host that runs Ansible, Windows modules need to be written and tested for Windows hosts. While evaluation editions of Windows can be downloaded from Microsoft, these images are usually not ready to be used by Ansible without further modification. The easiest way to set up a Windows host so that it is ready to by used by Ansible is to set up a virtual machine using Vagrant. Vagrant can be used to download existing OS images called *boxes* that are then deployed to a hypervisor like VirtualBox. These boxes can either be created and stored offline or they can be downloaded from a central repository called Vagrant Cloud." -msgstr "Ansible を実行するホストで実行できる Python モジュール開発とは異なり、Windows ホスト用に Windows モジュールを作成およびテストする必要があります。Windows の評価エディションを Microsoft からダウンロードできますが、通常はこれらのイメージを追加の変更なしで Ansible で使用することはできません。Ansible で使用する準備が整うように Windows ホストを設定する最も簡単な方法は、Vagrant を使用して仮想マシンを設定することにあります。Vagrant を使用すると、*ボックス* と呼ばれる既存の OS イメージをダウンロードし、VirtualBox のようなハイパーバイザーにデプロイされます。これらのボックスは、オフラインで作成および保存するか、Vagrant Cloud と呼ばれる中央リポジトリーからダウンロードできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:33 -#, python-format -msgid "This guide will use the Vagrant boxes created by the `packer-windoze `_ repository which have also been uploaded to `Vagrant Cloud `_. To find out more info on how these images are created, please go to the GitHub repo and look at the ``README`` file." -msgstr "本ガイドでは、`packer-windoze `_ リポジトリーにより作成された Vagrant ボックスを使用します。これは、`Vagrant Cloud `_ にアップロードされました。これらの画像がどのように作成されるかについての詳細は、GitHub リポジトリーで ``README`` ファイルを確認してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:38 -msgid "Before you can get started, the following programs must be installed (please consult the Vagrant and VirtualBox documentation for installation instructions):" -msgstr "作業を開始する前に、以下のプログラムをインストールする必要があります (インストール方法は Vagrant および VirtualBox のドキュメントを参照してください)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:41 -msgid "Vagrant" -msgstr "Vagrant" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:42 -msgid "VirtualBox" -msgstr "VirtualBox" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:45 -msgid "Create a Windows server in a VM" -msgstr "仮想マシンで Windows サーバーを作成" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:47 -msgid "To create a single Windows Server 2016 instance, run the following:" -msgstr "1 つの Windows Server 2016 インスタンスを作成するには、次のコマンドを実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:54 -msgid "This will download the Vagrant box from Vagrant Cloud and add it to the local boxes on your host and then start up that instance in VirtualBox. When starting for the first time, the Windows VM will run through the sysprep process and then create a HTTP and HTTPS WinRM listener automatically. Vagrant will finish its process once the listeners are online, after which the VM can be used by Ansible." -msgstr "これにより、Vagrant Cloud から Vagrant ボックスをダウンロードし、ホストのローカルボックスに追加して、VirtualBox でそのインスタンスを起動します。初めて起動すると、Windows 仮想マシンが sysprep プロセスを介して実行し、HTTP および HTTPS WinRM リスナーを自動的に作成します。Vagrant は、リスナーがオンラインになるとプロセスを終了します。その後、Ansible で仮想マシンを使用できるようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:61 -msgid "Create an Ansible inventory" -msgstr "Ansible インベントリーの作成" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:63 -msgid "The following Ansible inventory file can be used to connect to the newly created Windows VM:" -msgstr "以下の Ansible インベントリーファイルを使用して、新しく作成した Windows 仮想マシンに接続できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:79 -msgid "The port ``55986`` is automatically forwarded by Vagrant to the Windows host that was created, if this conflicts with an existing local port then Vagrant will automatically use another one at random and display show that in the output." -msgstr "ポート ``55986`` は、Vagrant によって作成された Windows ホストに自動的に転送されます。これが既存のローカルポートと競合する場合、Vagrant は自動的に別のポートをランダムに使用し、出力にそれを表示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:84 -msgid "The OS that is created is based on the image set. The following images can be used:" -msgstr "作成される OS はイメージセットに基づいています。次のイメージを使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:87 -msgid "`jborean93/WindowsServer2012 `_" -msgstr "`jborean93/WindowsServer2012 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:88 -msgid "`jborean93/WindowsServer2012R2 `_" -msgstr "`jborean93/WindowsServer2012R2 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:89 -msgid "`jborean93/WindowsServer2016 `_" -msgstr "`jborean93/WindowsServer2016 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:90 -msgid "`jborean93/WindowsServer2019 `_" -msgstr "`jborean93/WindowsServer2019 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:91 -msgid "`jborean93/WindowsServer2022 `_" -msgstr "`jborean93/WindowsServer2022 `_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:93 -msgid "When the host is online, it can accessible by RDP on ``127.0.0.1:3389`` but the port may differ depending if there was a conflict. To get rid of the host, run ``vagrant destroy --force`` and Vagrant will automatically remove the VM and any other files associated with that VM." -msgstr "ホストがオンラインになったら、``127.0.0.1:3389`` で RDP からアクセスできますが、競合があったかどうかによってポートが異なる場合があります。ホストを取り除くには、``vagrant destroy --force`` を実行すると、Vagrant が、仮想マシンとその仮想マシンに関連付けられたその他のファイルを自動的に削除します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:98 -msgid "While this is useful when testing modules on a single Windows instance, these host won't work without modification with domain based modules. The Vagrantfile at `ansible-windows `_ can be used to create a test domain environment to be used in Ansible. This repo contains three files which are used by both Ansible and Vagrant to create multiple Windows hosts in a domain environment. These files are:" -msgstr "これは、単一の Windows インスタンスでモジュールをテストする際に役立ちますが、これらのホストはドメインベースのモジュールで変更せずに動作しません。`ansible-windows `_ の Vagrant を使用して、Ansible で使用するテストドメイン環境を作成できます。このリポジトリーには、Ansible と Vagrant で使用されている 3 つのファイルが含まれ、ドメイン環境で複数の Windows ホストを作成するのに使用できます。このファイルは、以下のようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:105 -msgid "``Vagrantfile``: The Vagrant file that reads the inventory setup of ``inventory.yml`` and provisions the hosts that are required" -msgstr "``Vagrantfile`` - ``inventory.yml`` のインベントリー設定を読み込んで、必要なホストをプロビジョニングする Vagrant ファイルです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:106 -msgid "``inventory.yml``: Contains the hosts that are required and other connection information such as IP addresses and forwarded ports" -msgstr "``inventory.yml`` - 必要なホストと、IP アドレスや転送ポートなどの他の接続情報が含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:107 -msgid "``main.yml``: Ansible playbook called by Vagrant to provision the domain controller and join the child hosts to the domain" -msgstr "``main.yml`` - Vagrant に呼び出された Ansible Playbook は、ドメインコントローラーをプロビジョニングし、子ホストをドメインに参加させます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:109 -msgid "By default, these files will create the following environment:" -msgstr "デフォルトでは、これらのファイルは以下の環境を作成します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:111 -msgid "A single domain controller running on Windows Server 2016" -msgstr "Windows Server 2016 で実行しているドメインコントローラー 1 つ" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:112 -msgid "Five child hosts for each major Windows Server version joined to that domain" -msgstr "ドメインに参加している各 Windows Server のメジャーバージョンの子ホスト 5 台" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:113 -msgid "A domain with the DNS name ``domain.local``" -msgstr "DNS 名 ``domain.local`` を持つドメイン" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:114 -msgid "A local administrator account on each host with the username ``vagrant`` and password ``vagrant``" -msgstr "各ホストのローカル管理者アカウント (ユーザー名 ``vagrant`` およびパスワード ``vagrant``)" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:115 -msgid "A domain admin account ``vagrant-domain@domain.local`` with the password ``VagrantPass1``" -msgstr "パスワード ``VagrantPass1`` を含むドメイン管理者アカウント ``vagrant-domain@domain.local``" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:117 -msgid "The domain name and accounts can be modified by changing the variables ``domain_*`` in the ``inventory.yml`` file if it is required. The inventory file can also be modified to provision more or less servers by changing the hosts that are defined under the ``domain_children`` key. The host variable ``ansible_host`` is the private IP that will be assigned to the VirtualBox host only network adapter while ``vagrant_box`` is the box that will be used to create the VM." -msgstr "ドメイン名およびアカウントを変更するには、必要な場合に ``inventory.yml`` ファイルの変数 ``domain_*`` を変更することで変更できます。インベントリーファイルは、``domain_children`` キーで定義されるホストを変更して、より少ないサーバーをプロビジョニングするように変更することもできます。ホスト変数 ``ansible_host`` は、VirtualBox ホストに割り当てられるプライベート IP で、ネットワークアダプターのみに割り当てられますが、``vagrant_box`` は仮想マシンの作成に使用するボックスです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:126 -msgid "Provisioning the environment" -msgstr "環境のプロビジョニング" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:128 -msgid "To provision the environment as is, run the following:" -msgstr "環境をそのままプロビジョニングするには、次を実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:136 -msgid "Vagrant provisions each host sequentially so this can take some time to complete. If any errors occur during the Ansible phase of setting up the domain, run ``vagrant provision`` to rerun just that step." -msgstr "Vagrant は各ホストを順番にプロビジョニングするため、完了するまでに時間がかかる場合があります。ドメイン設定の Ansible フェーズ中にエラーが発生した場合は、``vagrant provision`` を実行してそのステップだけを再実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:140 -msgid "Unlike setting up a single Windows instance with Vagrant, these hosts can also be accessed using the IP address directly as well as through the forwarded ports. It is easier to access it over the host only network adapter as the normal protocol ports are used, for example RDP is still over ``3389``. In cases where the host cannot be resolved using the host only network IP, the following protocols can be access over ``127.0.0.1`` using these forwarded ports:" -msgstr "Vagrant で単一の Windows インスタンスをセットアップするのとは異なり、これらのホストは、転送されたポートを介してだけでなく、IP アドレスを使用して直接アクセスすることもできます。ホストのみのネットワークアダプターを使用してアクセスする方が、通常のプロトコルのポートが使用されるため簡単です。たとえば、RDP はまだ ``3389`` でで使用されます。ホストのみのネットワーク IP を使用してホストを解決できない場合、以下のプロトコルは、これらの転送されたポートを使用して ``127.0.0.1`` を介してアクセスできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:147 -msgid "``RDP``: 295xx" -msgstr "``RDP``: 295xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:148 -msgid "``SSH``: 296xx" -msgstr "``SSH``: 296xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:149 -msgid "``WinRM HTTP``: 297xx" -msgstr "``WinRM HTTP``: 297xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:150 -msgid "``WinRM HTTPS``: 298xx" -msgstr "``WinRM HTTPS``: 298xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:151 -msgid "``SMB``: 299xx" -msgstr "``SMB``: 299xx" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:153 -msgid "Replace ``xx`` with the entry number in the inventory file where the domain controller started with ``00`` and is incremented from there. For example, in the default ``inventory.yml`` file, WinRM over HTTPS for ``SERVER2012R2`` is forwarded over port ``29804`` as it's the fourth entry in ``domain_children``." -msgstr "``xx`` を、ドメインコントローラーが ``00`` から開始したインベントリーファイルのエントリー番号に置換えます。値がインクリメントされていきます。たとえば、デフォルトでは、``domain_children`` の 4 番目のエントリーであるため、``inventory.yml`` ファイル (WinRM over HTTPS for ``SERVER2012R2``) がポート ``29804`` 経由で転送されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:159 -msgid "Windows new module development" -msgstr "Windows 新しいモジュール開発" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:161 -msgid "When creating a new module there are a few things to keep in mind:" -msgstr "新しいモジュールを作成する際には、以下の点に留意してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:163 -msgid "Module code is in Powershell (.ps1) files while the documentation is contained in Python (.py) files of the same name" -msgstr "モジュールのコードは Powershell (.ps1) ファイルにあり、ドキュメントは同じ名前の Python (.py) ファイルに含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:164 -msgid "Avoid using ``Write-Host/Debug/Verbose/Error`` in the module and add what needs to be returned to the ``$module.Result`` variable" -msgstr "モジュールでは ``Write-Host/Debug/Verbose/Error`` を使用せず、``$module.Result`` 変数に返す必要のあるものを追加します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:165 -msgid "To fail a module, call ``$module.FailJson(\"failure message here\")``, an Exception or ErrorRecord can be set to the second argument for a more descriptive error message" -msgstr "モジュールを失敗させるには、``$module.FailJson(\"failure message here\")`` を呼び出して、Exception または ErrorRecord を 2 番目の引数に設定して、より詳細なエラーメッセージを表示できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:166 -msgid "You can pass in the exception or ErrorRecord as a second argument to ``FailJson(\"failure\", $_)`` to get a more detailed output" -msgstr "例外または ErrorRecord を 2 つ目の引数として ``FailJson(\"failure\", $_)`` に渡すと、より詳細な出力を取得できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:167 -msgid "Most new modules require check mode and integration tests before they are merged into the main Ansible codebase" -msgstr "ほとんどの新規モジュールには、主要な Ansible コードベースにマージする前にチェックモードと統合テストが必要です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:168 -msgid "Avoid using try/catch statements over a large code block, rather use them for individual calls so the error message can be more descriptive" -msgstr "大規模なコードブロックで try/catch 文を使用しないようにし、個別の呼び出しに使用することで、エラーメッセージがより分かりやすくなるようにします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:169 -msgid "Try and catch specific exceptions when using try/catch statements" -msgstr "try/catch 文の使用時に特定の例外を試して捕え (キャッチし) ます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:170 -msgid "Avoid using PSCustomObjects unless necessary" -msgstr "必要な場合を除き PSCustomObject は使用しないでください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:171 -msgid "Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run through Ansible" -msgstr "重複する作業を行わないように、``./lib/ansible/module_utils/powershell/`` にある共通の関数を探して、そこにあるコードを使用してください。これらの関数は ``#Requires -Module *`` という行を追加することでインポートすることができます。* はインポートするファイル名で、Ansible を介して実行する場合に、Windows ターゲットに送信されたモジュールコードが自動的に含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:172 -msgid "As well as PowerShell module utils, C# module utils are stored in ``./lib/ansible/module_utils/csharp/`` and are automatically imported in a module execution if the line ``#AnsibleRequires -CSharpUtil *`` is present" -msgstr "PowerShell モジュールユーティリティーの他に、C# モジュールユーティリティーが ``./lib/ansible/module_utils/csharp/`` に本され、``#AnsibleRequires -CSharpUtil *`` 行が存在する場合に、モジュール実行に自動的にインポートされます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:173 -msgid "C# and PowerShell module utils achieve the same goal but C# allows a developer to implement low level tasks, such as calling the Win32 API, and can be faster in some cases" -msgstr "C# と PowerShell モジュールのユーティリティーは同じ目標を達成しますが、C# を使用すると、開発者は Win32 API の呼び出しなどの低レベルのタスクを実装でき、場合によってはより高速になります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:174 -msgid "Ensure the code runs under Powershell v3 and higher on Windows Server 2012 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly" -msgstr "このコードが Windows Server 2012 以降の Powershell v3 以降で動作することを確認してください。最小バージョンより新しい Powershell または OS が必要な場合は、ドキュメントにこの内容が明確に反映されていることを確認してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:175 -msgid "Ansible runs modules under strictmode version 2.0. Be sure to test with that enabled by putting ``Set-StrictMode -Version 2.0`` at the top of your dev script" -msgstr "Ansible は、strictmode バージョン 2.0 でモジュールを実行します。必ず、開発スクリプトの冒頭に ``Set-StrictMode -Version 2.0`` と記述して、この機能を有効にしてテストしてください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:176 -msgid "Favor native Powershell cmdlets over executable calls if possible" -msgstr "可能であれば、実行可能な呼び出しよりも、ネイティブの Powershell コマンドレットを優先してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:177 -msgid "Use the full cmdlet name instead of aliases, for example ``Remove-Item`` over ``rm``" -msgstr "エイリアスの代わりに完全なコマンドレット名を使用してください (例: ``rm`` ではなく ``Remove-Item`` を使用)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:178 -msgid "Use named parameters with cmdlets, for example ``Remove-Item -Path C:\\temp`` over ``Remove-Item C:\\temp``" -msgstr "コマンドレットで名前付きパラメーターを使用します (例： ``Remove-Item C:\\temp`` ではなく ``Remove-Item -Path C:\\temp`` を使用)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:180 -msgid "A very basic Powershell module `win_environment `_ incorporates best practices for Powershell modules. It demonstrates how to implement check-mode and diff-support, and also shows a warning to the user when a specific condition is met." -msgstr "非常に基本的な Powershell モジュール `win_environment `_ が、Powershell モジュールのベストプラクティスを組み込んでいます。これは、check-mode および diff-support を実装する方法を示し、特定の条件が満たされるとユーザーに警告を表示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:182 -msgid "A slightly more advanced module is `win_uri `_ which additionally shows how to use different parameter types (bool, str, int, list, dict, path) and a selection of choices for parameters, how to fail a module and how to handle exceptions." -msgstr "もう少し高度なモジュールとしては `win_uri `_ がありますが、ここで、さまざまなパラメーター型 (bool、str、int、list、dict、path) の使用方法やパラメーターの選択方法、モジュールを失敗させる方法、例外の処理方法などを紹介しています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:184 -msgid "As part of the new ``AnsibleModule`` wrapper, the input parameters are defined and validated based on an argument spec. The following options can be set at the root level of the argument spec:" -msgstr "新しい ``AnsibleModule`` ラッパーの一部として、入力パラメーターは引数の仕様に基づいて定義および検証されます。以下のオプションは、引数仕様のルートレベルで設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:187 -msgid "``mutually_exclusive``: A list of lists, where the inner list contains module options that cannot be set together" -msgstr "``mutually_exclusive``: リストのリストで、内側のリストには一緒に設定できないモジュールオプションが含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:188 -msgid "``no_log``: Stops the module from emitting any logs to the Windows Event log" -msgstr "``no_log``: モジュールが Windows イベントログにログを出力しないようにします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:189 -msgid "``options``: A dictionary where the key is the module option and the value is the spec for that option" -msgstr "``options``: キーがモジュールオプションで、値がそのオプションの仕様となるディクショナリーです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:190 -msgid "``required_by``: A dictionary where the option(s) specified by the value must be set if the option specified by the key is also set" -msgstr "``required_by``: キーで指定されたオプションが設定されている場合に、値で指定されたオプションも設定しなければならないディクショナリーです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:194 -msgid "``required_if``: A list of lists where the inner list contains 3 or 4 elements;" -msgstr "``required_if``: 内部リストに 3 つまたは 4 つの要素が含まれるリストの一覧" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:192 -msgid "The first element is the module option to check the value against" -msgstr "最初の要素は、値を確認するモジュールオプションです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:193 -msgid "The second element is the value of the option specified by the first element, if matched then the required if check is run" -msgstr "2 つ目の要素は、1 つ目の要素によって指定されるオプションの値です。一致すると必須の if チェックが実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:194 -msgid "The third element is a list of required module options when the above is matched" -msgstr "3 つ目の要素は、上記が一致した場合に必要なモジュールオプションのリストです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:195 -msgid "An optional fourth element is a boolean that states whether all module options in the third elements are required (default: ``$false``) or only one (``$true``)" -msgstr "4 番目の要素 (任意) は、3 番目の要素のモジュールオプションがすべて必要なのか (デフォルト: ``$false``)、1 つだけが必要なのか (``$true``) を示すブール値です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:196 -msgid "``required_one_of``: A list of lists, where the inner list contains module options where at least one must be set" -msgstr "``required_one_of``: 少なくとも 1 つは設定しなければならないモジュールオプションが含まれているリストが記載されるリストです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:197 -msgid "``required_together``: A list of lists, where the inner list contains module options that must be set together" -msgstr "``required_together``: 一緒に設定しなければならないモジュールオプションが含まれているリストが記載されるリストです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:198 -msgid "``supports_check_mode``: Whether the module supports check mode, by default this is ``$false``" -msgstr "``supports_check_mode``: モジュールがチェックモードに対応しているかどうか (デフォルトは ``$false``) を指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:200 -msgid "The actual input options for a module are set within the ``options`` value as a dictionary. The keys of this dictionary are the module option names while the values are the spec of that module option. Each spec can have the following options set:" -msgstr "モジュールの実際の入力オプションは、ディクショナリーとなる ``options`` 値に設定されています。このディクショナリーのキーはモジュールオプション名であり、値はそのモジュールオプションの仕様です。各仕様には、次のオプションを設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:204 -msgid "``aliases``: A list of aliases for the module option" -msgstr "``aliases``: モジュールオプションのエイリアス一覧" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:205 -msgid "``choices``: A list of valid values for the module option, if ``type=list`` then each list value is validated against the choices and not the list itself" -msgstr "``choices``: モジュールオプションの有効な値のリストです。``type=list`` の場合は、各リストの値が選択したものに対して検証され、リスト自体は検証されません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:206 -msgid "``default``: The default value for the module option if not set" -msgstr "``default``: モジュールオプションのデフォルト値 (設定されていない場合) です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:207 -msgid "``deprecated_aliases``: A list of hashtables that define aliases that are deprecated and the versions they will be removed in. Each entry must contain the keys ``name`` and ``collection_name`` with either ``version`` or ``date``" -msgstr "``deprecated_aliases``: 非推奨となるエイリアスと、そのエイリアスが削除されるバージョンを定義するハッシュテーブルの一覧。各エントリーには、``version`` または ``date`` がある ``name`` キーと ``collection_name`` が含まれている必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:208 -msgid "``elements``: When ``type=list``, this sets the type of each list value, the values are the same as ``type``" -msgstr "``elements``: ``type=list`` の場合は、各リスト値のタイプが設定され、値は ``type`` と同じになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:209 -msgid "``no_log``: Will sanitise the input value before being returned in the ``module_invocation`` return value" -msgstr "``no_log``: ``module_invocation`` の戻り値で返される前に入力値をサニタイズします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:210 -msgid "``removed_in_version``: States when a deprecated module option is to be removed, a warning is displayed to the end user if set" -msgstr "``removed_in_version``: 非推奨のモジュールオプションがいつ削除されるかを示します。これが設定されている場合は、エンドユーザーに警告が表示されます" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:211 -msgid "``removed_at_date``: States the date (YYYY-MM-DD) when a deprecated module option will be removed, a warning is displayed to the end user if set" -msgstr "``removed_at_date``: 非推奨のモジュールオプションが削除される日付 (YYYY-MM-DD) を示します。これが設定されている場合は、エンドユーザーに警告が表示されます" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:212 -msgid "``removed_from_collection``: States from which collection the deprecated module option will be removed; must be specified if one of ``removed_in_version`` and ``removed_at_date`` is specified" -msgstr "``removed_from_collection``: 非推奨のモジュールオプションを削除するコレクションの状態。``removed_in_version`` および ``removed_at_date`` のいずれかが指定されている場合は指定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:213 -msgid "``required``: Will fail when the module option is not set" -msgstr "``required``: モジュールオプションが設定されていない場合は失敗します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:224 -msgid "``type``: The type of the module option, if not set then it defaults to ``str``. The valid types are;" -msgstr "``type``: モジュールオプションのタイプです。設定されていない場合は、デフォルトで ``str`` に設定されます。有効なタイプは以下のとおりです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:215 -msgid "``bool``: A boolean value" -msgstr "``bool``: ブール値" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:216 -msgid "``dict``: A dictionary value, if the input is a JSON or key=value string then it is converted to dictionary" -msgstr "``dict``: ディクショナリーの値。入力が JSON または key=value 文字列の場合は、ディクショナリーに変換されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:217 -msgid "``float``: A float or `Single `_ value" -msgstr "``float``: 浮動小数点または `Single `_ の値" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:218 -msgid "``int``: An Int32 value" -msgstr "``int``: Int32 値" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:219 -msgid "``json``: A string where the value is converted to a JSON string if the input is a dictionary" -msgstr "``json``: 入力がディクショナリーである場合に値が JSON 文字列に変換される文字列" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:220 -msgid "``list``: A list of values, ``elements=`` can convert the individual list value types if set. If ``elements=dict`` then ``options`` is defined, the values will be validated against the argument spec. When the input is a string then the string is split by ``,`` and any whitespace is trimmed" -msgstr "``list``: 値の一覧 (``elements=``) が設定されている場合は、個々のリスト値タイプを変換できます。``elements=dict`` の場合は、``options`` が定義され、値は引数の仕様に対して検証されます。入力が文字列である場合、文字列は ``,`` で分割され、空白文字はすべてトリミングされます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:221 -msgid "``path``: A string where values likes ``%TEMP%`` are expanded based on environment values. If the input value starts with ``\\\\?\\`` then no expansion is run" -msgstr "``path``: ``%TEMP%`` などの値が環境値に基づいて展開される文字列です。入力値が ``\\\\?\\`` で始まると、展開は実行されません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:222 -msgid "``raw``: No conversions occur on the value passed in by Ansible" -msgstr "``raw``: Ansible によって渡される値で変換が行われません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:223 -msgid "``sid``: Will convert Windows security identifier values or Windows account names to a `SecurityIdentifier `_ value" -msgstr "``sid``: Windows セキュリティー識別子の値または Windows アカウント名を `SecurityIdentifier `_ 値に変換します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:224 -msgid "``str``: The value is converted to a string" -msgstr "``str``: この値は文字列に変換されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:226 -msgid "When ``type=dict``, or ``type=list`` and ``elements=dict``, the following keys can also be set for that module option:" -msgstr "``type=dict`` または ``type=list`` および ``elements=dict`` の場合は、そのモジュールオプションに以下のキーを設定することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:228 -msgid "``apply_defaults``: The value is based on the ``options`` spec defaults for that key if ``True`` and null if ``False``. Only valid when the module option is not defined by the user and ``type=dict``." -msgstr "``apply_defaults``: この値は、``True`` の場合はそのキーの ``options`` 仕様のデフォルトになり、``False`` の場合は null です。モジュールオプションがユーザーによって定義されておらず、``type=dict`` の場合に限り有効です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:229 -msgid "``mutually_exclusive``: Same as the root level ``mutually_exclusive`` but validated against the values in the sub dict" -msgstr "``mutually_exclusive``: ルートレベルの ``mutually_exclusive`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:230 -msgid "``options``: Same as the root level ``options`` but contains the valid options for the sub option" -msgstr "``options``: ルートレベルの ``options`` と同じですが、サブオプションの有効なオプションが含まれています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:231 -msgid "``required_if``: Same as the root level ``required_if`` but validated against the values in the sub dict" -msgstr "``required_if``: ルートレベルの ``required_if`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:232 -msgid "``required_by``: Same as the root level ``required_by`` but validated against the values in the sub dict" -msgstr "``required_by``: ルートレベルの ``required_by`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:233 -msgid "``required_together``: Same as the root level ``required_together`` but validated against the values in the sub dict" -msgstr "``required_together``: ルートレベルの ``required_together`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:234 -msgid "``required_one_of``: Same as the root level ``required_one_of`` but validated against the values in the sub dict" -msgstr "``required_one_of``: ルートレベルの ``required_one_of`` と同じですが、サブディクショナリーの値に対して検証されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:236 -msgid "A module type can also be a delegate function that converts the value to whatever is required by the module option. For example the following snippet shows how to create a custom type that creates a ``UInt64`` value:" -msgstr "モジュール型は、値をモジュールオプションで必要とされるものに変換するデリゲート関数にすることもできます。次のスニペットの例は、``UInt64`` 値を作成するカスタム型を作成する方法を示しています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:246 -msgid "When in doubt, look at some of the other core modules and see how things have been implemented there." -msgstr "不明な場合は、他のコアモジュールを見て、そこにどのように実装されているかを見てみましょう。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:249 -msgid "Sometimes there are multiple ways that Windows offers to complete a task; this is the order to favor when writing modules:" -msgstr "Windows がタスクを完了させるために、複数の方法が提示されることがあります。モジュールを書くときに好ましい順序は以下のようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:252 -msgid "Native Powershell cmdlets like ``Remove-Item -Path C:\\temp -Recurse``" -msgstr "``Remove-Item -Path C:\\temp -Recurse`` などのネイティブの Powershell コマンドレッド" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:253 -msgid ".NET classes like ``[System.IO.Path]::GetRandomFileName()``" -msgstr "``[System.IO.Path]::GetRandomFileName()`` などの .NET クラス" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:254 -msgid "WMI objects through the ``New-CimInstance`` cmdlet" -msgstr "``New-CimInstance`` コマンドレッド経由の WMI オブジェクト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:255 -msgid "COM objects through ``New-Object -ComObject`` cmdlet" -msgstr "``New-Object -ComObject`` コマンドレッド経由の COM オブジェクト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:256 -msgid "Calls to native executables like ``Secedit.exe``" -msgstr "``Secedit.exe`` など、ネイティブ実行可能ファイルへの呼び出し" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:258 -msgid "PowerShell modules support a small subset of the ``#Requires`` options built into PowerShell as well as some Ansible-specific requirements specified by ``#AnsibleRequires``. These statements can be placed at any point in the script, but are most commonly near the top. They are used to make it easier to state the requirements of the module without writing any of the checks. Each ``requires`` statement must be on its own line, but there can be multiple requires statements in one script." -msgstr "PowerShell モジュールは、PowerShell に組み込まれている ``#Requires`` オプションの小さなサブセットと、``#AnsibleRequires`` で指定されている Ansible 固有の要件をサポートしています。これらのステートメントは、スクリプトの任意の位置に配置できますが、最も一般的なのは先頭付近です。これらのステートメントは、チェック項目を記述することなく、モジュールの要件を簡単に記述するために使用されます。``requires`` ステートメントはそれぞれ 1 行に書かなければなりませんが、1 つのスクリプトに複数の requires ステートメントを記述することができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:266 -msgid "These are the checks that can be used within Ansible modules:" -msgstr "以下のチェックは、Ansible モジュール内で使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:268 -msgid "``#Requires -Module Ansible.ModuleUtils.``: Added in Ansible 2.4, specifies a module_util to load in for the module execution." -msgstr "``#Requires -Module Ansible.ModuleUtils.``: Ansible 2.4 で追加され、モジュール実行のために読み込むモジュールユーティリティーを指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:269 -msgid "``#Requires -Version x.y``: Added in Ansible 2.5, specifies the version of PowerShell that is required by the module. The module will fail if this requirement is not met." -msgstr "``#Requires -Version x.y``: Ansible 2.5 で追加され、モジュールが必要とする PowerShell バージョンを指定します。この要件を満たしていない場合は失敗します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:270 -msgid "``#AnsibleRequires -PowerShell ``: Added in Ansible 2.8, like ``#Requires -Module``, this specifies a module_util to load in for module execution." -msgstr "``#AnsibleRequires -PowerShell ``: Ansible 2.8 で追加されました。``#Requires -Module`` のように、Ansible 2.8 で追加され、モジュール実行のために読み込むモジュールユーティリティーを指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:271 -msgid "``#AnsibleRequires -CSharpUtil ``: Added in Ansible 2.8, specifies a C# module_util to load in for the module execution." -msgstr "``#AnsibleRequires -CSharpUtil ``: Ansible 2.8 で追加され、モジュール実行のために読み込む C# モジュールユーティリティーを指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:272 -msgid "``#AnsibleRequires -OSVersion x.y``: Added in Ansible 2.5, specifies the OS build version that is required by the module and will fail if this requirement is not met. The actual OS version is derived from ``[Environment]::OSVersion.Version``." -msgstr "``#AnsibleRequires -OSVersion x.y``: Ansible 2.5 で追加され、モジュールが必要とする OS ビルドバージョンを指定します。この要件を満たしていない場合は失敗します。実際の OS バージョンは ``[Environment]::OSVersion.Version`` から由来します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:273 -msgid "``#AnsibleRequires -Become``: Added in Ansible 2.5, forces the exec runner to run the module with ``become``, which is primarily used to bypass WinRM restrictions. If ``ansible_become_user`` is not specified then the ``SYSTEM`` account is used instead." -msgstr "``#AnsibleRequires -Become``: Ansible 2.5 で追加され、exec ランナーが ``become`` でモジュールを強制的に実行します。これは主に WinRM の制限を回避するために使用されます。``ansible_become_user`` が指定されていない場合は、代わりに ``SYSTEM`` アカウントが使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:275 -msgid "The ``#AnsibleRequires -PowerShell`` and ``#AnsibleRequires -CSharpUtil`` support further features such as:" -msgstr "``#AnsibleRequires -PowerShell`` および ``#AnsibleRequires -CSharpUtil`` は、以下のような追加機能をサポートします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:278 -msgid "Importing a util contained in a collection (added in Ansible 2.9)" -msgstr "コレクションに含まれるユーティリティーのインポート (Ansible 2.9 で追加)" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:279 -msgid "Importing a util by relative names (added in Ansible 2.10)" -msgstr "相対名によるユーティリティーのインポート (Ansible 2.10 で追加)" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:280 -msgid "Specifying the util is optional by adding `-Optional` to the import declaration (added in Ansible 2.12)." -msgstr "オプションで、インポート宣言に `-Optional` を追加してユーティリティーを指定できます (Ansible 2.12 で追加)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:283 -msgid "See the below examples for more details:" -msgstr "詳細については、以下の例を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:313 -msgid "For optional require statements, it is up to the module code to then verify whether the util has been imported before trying to use it. This can be done by checking if a function or type provided by the util exists or not." -msgstr "オプションの require ステートメントでは、モジュールコードにより、ユーティリティーを使用する前にインポート済みであることを確認するかどうかが決定されます。これは、ユーティリティーによって提供された機能またはタイプが存在するか確認することで実行できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:317 -msgid "While both ``#Requires -Module`` and ``#AnsibleRequires -PowerShell`` can be used to load a PowerShell module it is recommended to use ``#AnsibleRequires``. This is because ``#AnsibleRequires`` supports collection module utils, imports by relative util names, and optional util imports." -msgstr "PowerShell は ``#Requires -Module`` と ``#AnsibleRequires -PowerShell`` の両方を使用してロードできますが、``#AnsibleRequires`` の使用が推奨されます。これは、``#AnsibleRequires`` はコレクションモジュールユーティリティー、相対ユーティリティー名によるインポート、および任意のユーティリティーのインポートをサポートするためです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:322 -msgid "C# module utils can reference other C# utils by adding the line ``using Ansible.;`` to the top of the script with all the other using statements." -msgstr "C# モジュールユーティリティーは、すべてのステートメントを使用し、スクリプトの冒頭に ``using Ansible.;`` 行を追加することで、他の C# ユーティリティーを参照できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:328 -msgid "Windows module utilities" -msgstr "Windows モジュールユーティリティー" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:330 -msgid "Like Python modules, PowerShell modules also provide a number of module utilities that provide helper functions within PowerShell. These module_utils can be imported by adding the following line to a PowerShell module:" -msgstr "Python モジュールと同様に、PowerShell モジュールは、PowerShell でヘルパー関数を提供する多くのモジュールユーティリティーを提供します。これらのモジュールユーティリティーは、以下の行を PowerShell モジュールに追加してインポートできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:338 -msgid "This will import the module_util at ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` and enable calling all of its functions. As of Ansible 2.8, Windows module utils can also be written in C# and stored at ``lib/ansible/module_utils/csharp``. These module_utils can be imported by adding the following line to a PowerShell module:" -msgstr "これにより、モジュールユーティリティーが ``./lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1`` でインポートされ、すべての関数の呼び出しが可能になります。Ansible 2.8 と同様に、Windows モジュールユーティリティーは C# でも記述でき、``lib/ansible/module_utils/csharp`` に保存されます。これらのモジュールユーティリティーは、PowerShell モジュールに以下の行を追加することでインポートできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:348 -msgid "This will import the module_util at ``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` and automatically load the types in the executing process. C# module utils can reference each other and be loaded together by adding the following line to the using statements at the top of the util:" -msgstr "これにより、``./lib/ansible/module_utils/csharp/Ansible.Basic.cs`` でモジュールユーティリティーがインポートされ、実行中のプロセスでタイプが自動的に読み込まれます。C# モジュールユーティリティーは相互に参照でき、次の行を、ユーティリティーの上部にある using ステートメントに追加して読み込むことができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:357 -msgid "There are special comments that can be set in a C# file for controlling the compilation parameters. The following comments can be added to the script;" -msgstr "コンパイルパラメーターを制御するために C# ファイルに設定できる特別なコメントがあります。以下のコメントをスクリプトに追加できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:360 -msgid "``//AssemblyReference -Name [-CLR [Core|Framework]]``: The assembly DLL to reference during compilation, the optional ``-CLR`` flag can also be used to state whether to reference when running under .NET Core, Framework, or both (if omitted)" -msgstr "``//AssemblyReference -Name [-CLR [Core|Framework]]``: コンパイル中に参照するアセンブリー DLL です。任意の ``-CLR`` フラグを使用して、.NET Core、Framework、またはその両方 (省略されている場合) で実行するときに参照するかどうかを表示することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:361 -msgid "``//NoWarn -Name [-CLR [Core|Framework]]``: A compiler warning ID to ignore when compiling the code, the optional ``-CLR`` works the same as above. A list of warnings can be found at `Compiler errors `_" -msgstr "``//NoWarn -Name [-CLR [Core|Framework]]``: コードをコンパイルするときに無視するコンパイラ警告 ID で、任意の ``-CLR`` が上記と同じように機能します。警告のリストは、`コンパイラーエラー `_ で見つけることができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:363 -msgid "As well as this, the following pre-processor symbols are defined;" -msgstr "この他に、以下のプリプロセッサーシンボルも定義されています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:365 -msgid "``CORECLR``: This symbol is present when PowerShell is running through .NET Core" -msgstr "``CORECLR``: このシンボルは、PowerShell が .NET Core を介して実行している場合に表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:366 -msgid "``WINDOWS``: This symbol is present when PowerShell is running on Windows" -msgstr "``WINDOWS``: このシンボルは、PowerShell が Windows で実行している場合に表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:367 -msgid "``UNIX``: This symbol is present when PowerShell is running on Unix" -msgstr "``UNIX``: このシンボルは、PowerShell が Unix で実行している場合に表示されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:369 -msgid "A combination of these flags help to make a module util interoperable on both .NET Framework and .NET Core, here is an example of them in action:" -msgstr "これフラグの組み合わせは、.NET Framework と .NET Core の両方でモジュールユーティリティーを相互運用可能にするのに役立ちます。以下に、実際の動作例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:390 -msgid "The following is a list of module_utils that are packaged with Ansible and a general description of what they do:" -msgstr "以下に Ansible と一緒にパッケージ化されているモジュールユーティリティーのリストと、それらの機能の一般的な説明です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:393 -msgid "ArgvParser: Utility used to convert a list of arguments to an escaped string compliant with the Windows argument parsing rules." -msgstr "ArgvParser: 引数のリストを Windows の引数解析ルールに準拠しているエスケープされた文字列に変換するのに使用されるユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:394 -msgid "CamelConversion: Utility used to convert camelCase strings/lists/dicts to snake_case." -msgstr "CamelConversion: camelCase strings/lists/dicts を snake_case に変換するのに使用されるユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:395 -msgid "CommandUtil: Utility used to execute a Windows process and return the stdout/stderr and rc as separate objects." -msgstr "CommandUtil: Windows プロセスを実行し、stdout/stderr と rc を異なるオブジェクトとして返すために使用されるユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:396 -msgid "FileUtil: Utility that expands on the ``Get-ChildItem`` and ``Test-Path`` to work with special files like ``C:\\pagefile.sys``." -msgstr "FileUtil: ``C:\\pagefile.sys`` のような特殊なファイルを扱うために ``Get-ChildItem`` および ``Test-Path`` を拡張するユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:397 -msgid "Legacy: General definitions and helper utilities for Ansible module." -msgstr "Legacy: Ansible モジュールの一般的な定義およびヘルパーユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:398 -msgid "LinkUtil: Utility to create, remove, and get information about symbolic links, junction points and hard inks." -msgstr "LinkUtil: シンボリックリンク、分岐点、ハードインクに関する情報を作成、削除、および取得するユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:399 -msgid "SID: Utilities used to convert a user or group to a Windows SID and vice versa." -msgstr "SID: ユーザーやグループを Windows SID に変換したり、Windows SID をユーザーやグループに変換するのに使用するユーティリティー。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:401 -msgid "For more details on any specific module utility and their requirements, please see the `Ansible module utilities source code `_." -msgstr "特定のモジュールユーティリティーとその要件に関する詳細は、`Ansible モジュールユーティリティーのソースコード `_ を参照してください。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:404 -msgid "PowerShell module utilities can be stored outside of the standard Ansible distribution for use with custom modules. Custom module_utils are placed in a folder called ``module_utils`` located in the root folder of the playbook or role directory." -msgstr "PowerShell モジュールユーティリティーは、カスタムモジュールで使用する標準の Ansible ディストリビューション外に保存できます。カスタムのモジュールユーティリティーは、Playbook またはロールディレクトリーのルートディレクトリーにある ``module_utils`` と呼ばれるディレクトリーに配置されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:409 -msgid "C# module utilities can also be stored outside of the standard Ansible distribution for use with custom modules. Like PowerShell utils, these are stored in a folder called ``module_utils`` and the filename must end in the extension ``.cs``, start with ``Ansible.`` and be named after the namespace defined in the util." -msgstr "C# モジュールユーティリティーは、カスタムモジュールで使用するための標準の Ansible ディストリビューション外にも保存できます。PowerShellutils と同様、``module_utils`` ディレクトリーに格納され、ファイル名は拡張子 ``.cs`` で終わり、``Ansible.`` で始まる、ユーティリティーで定義された名前空間の後に名前を指定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:413 -msgid "The below example is a role structure that contains two PowerShell custom module_utils called ``Ansible.ModuleUtils.ModuleUtil1``, ``Ansible.ModuleUtils.ModuleUtil2``, and a C# util containing the namespace ``Ansible.CustomUtil``:" -msgstr "次の例は、呼び出された 2 つの PowerShell のカスタム module_utils (``Ansible.ModuleUtils.ModuleUtil1``、``Ansible.ModuleUtils.ModuleUtil2``、および名前空間 ``Ansible.CustomUtil`` を含む C# ユーティリティー) を含むロール構造です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:430 -msgid "Each PowerShell module_util must contain at least one function that has been exported with ``Export-ModuleMember`` at the end of the file. For example" -msgstr "PowerShell の各モジュールユーティリティーには、ファイルの終わりに ``Export-ModuleMember`` でエクスポートされた関数が少なくとも 1 つ含まれている必要があります。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:439 -msgid "Exposing shared module options" -msgstr "共有モジュールオプションの公開" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:441 -msgid "PowerShell module utils can easily expose common module options that a module can use when building its argument spec. This allows common features to be stored and maintained in one location and have those features used by multiple modules with minimal effort. Any new features or bugfixes added to one of these utils are then automatically used by the various modules that call that util." -msgstr "PowerShell モジュールユーティリティーは、引数仕様を構築する際にモジュールが使用できる共通のモジュールオプションを簡単に公開できます。これにより、共通の機能は 1 つの場所に保存および維持でき、最小限の作業で複数のモジュールによって使用される機能を利用できます。これらのユーティリティーのいずれかに追加された新機能またはバグ修正は、そのユーティリティーのいずれかを呼び出すさまざまなモジュールによって自動的に使用されます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:446 -msgid "An example of this would be to have a module util that handles authentication and communication against an API This util can be used by multiple modules to expose a common set of module options like the API endpoint, username, password, timeout, cert validation, and so on without having to add those options to each module spec." -msgstr "この例としては、API に対する認証と通信を処理するモジュールユーティリティーがあります。このユーティリティーは、API エンドポイント、ユーザー名、パスワード、タイムアウト、認定検証などの共通のモジュールオプションセットを公開するため、各モジュール仕様にそれらのオプションを追加しなくても、複数のモジュールによって使用できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:450 -msgid "The standard convention for a module util that has a shared argument spec would have" -msgstr "共有引数仕様を持つモジュールユーティリティーの標準規則は次のようになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:453 -msgid "A ``Get-Spec`` function that outputs the common spec for a module" -msgstr "モジュールの共通の仕様を出力する ``Get-Spec`` 関数" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:453 -msgid "It is highly recommended to make this function name be unique to the module to avoid any conflicts with other utils that can be loaded" -msgstr "読み込みできる他のユーティリティーとの競合を避けるために、この関数名をモジュールに固有のものに強く推奨します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:454 -msgid "The format of the output spec is a Hashtable in the same format as the ``$spec`` used for normal modules" -msgstr "出力仕様の形式は、通常のモジュールに使用される ``$spec`` と同じ形式のハッシュテーブルです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:455 -msgid "A function that takes in an ``AnsibleModule`` object called under the ``-Module`` parameter which it can use to get the shared options" -msgstr "``-Module`` パラメーター下で呼び出された ``AnsibleModule`` オブジェクトを取り入れた関数。これを使用して共有オプションを取得できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:457 -msgid "Because these options can be shared across various module it is highly recommended to keep the module option names and aliases in the shared spec as specific as they can be. For example do not have a util option called ``password``, rather you should prefix it with a unique name like ``acme_password``." -msgstr "これらのオプションは各種モジュール間で共有できるため、モジュールオプション名とエイリアスを、可能な限り具体的な仕様に維持することが高く推奨されます。たとえば、``password`` ユーティリティーオプションがありません。たとえば、``acme_password`` などの一意の名前でプレフィックスを付けるべきではありません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:462 -msgid "Failure to have a unique option name or alias can prevent the util being used by module that also use those names or aliases for its own options." -msgstr "一意のオプション名またはエイリアスがないと、モジュールがユーティリティーを使用できなくなり、モジュールがそれらの名前またはエイリアスを独自のオプションに使用する可能性があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:465 -msgid "The following is an example module util called ``ServiceAuth.psm1`` in a collection that implements a common way for modules to authentication with a service." -msgstr "以下は、コレクションで ``ServiceAuth.psm1`` モジュールユーティリティーの例になります。このモジュールは、サービスを使用した認証に共通の方法を実装します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:521 -msgid "For a module to take advantage of this common argument spec it can be set out like" -msgstr "モジュールがこの共通の引数仕様を利用できるようにするには、以下のように設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:548 -msgid "Options defined in the module spec will always have precedence over a util spec. Any list values under the same key in a util spec will be appended to the module spec for that same key. Dictionary values will add any keys that are missing from the module spec and merge any values that are lists or dictionaries. This is similar to how the doc fragment plugins work when extending module documentation." -msgstr "モジュール仕様に定義されているオプションは常にユーティリティー仕様よりも優先されます。ユーティリティー仕様の同じキー下のリスト値は、同じキーのモジュール仕様に追加されます。ディクショナリーの値は、モジュール仕様に不足している鍵を追加し、リストまたはディクショナリーである値をマージします。これは、モジュールドキュメントを拡張するときにドキュメントフラグメントプラグインがどのように機能するかと似ています。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:553 -msgid "To document these shared util options for a module, create a doc fragment plugin that documents the options implemented by the module util and extend the module docs for every module that implements the util to include that fragment in its docs." -msgstr "モジュールのこれらの共有ユーティリティーオプションを文書化するには、モジュールユーティリティーにより実装されたオプションを文書化するドキュメントフラグメントプラグインを作成し、ユーティリティーを実装するすべてのモジュールのモジュールドキュメントを拡張して、そのフラグメントをドキュメントに含めます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:559 -msgid "Windows playbook module testing" -msgstr "Windows Playbook モジュールのテスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:561 -msgid "You can test a module with an Ansible playbook. For example:" -msgstr "以下のように、Ansible Playbook でモジュールをテストできます。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:563 -msgid "Create a playbook in any directory ``touch testmodule.yml``." -msgstr "任意のディレクトリーに Playbook を作成します (``touch testmodule.yml``)。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:564 -msgid "Create an inventory file in the same directory ``touch hosts``." -msgstr "同じディレクトリー ``touch hosts`` にインベントリーファイルを作成します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:565 -msgid "Populate the inventory file with the variables required to connect to a Windows host(s)." -msgstr "Windows ホストへの接続に必要な変数を指定してインベントリーファイルを設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:578 -msgid "Run the playbook ``ansible-playbook -i hosts testmodule.yml``" -msgstr "Playbook ``ansible-playbook -i hosts testmodule.yml`` を実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:580 -msgid "This can be useful for seeing how Ansible runs with the new module end to end. Other possible ways to test the module are shown below." -msgstr "これは、Ansible が新しいモジュールでエンドツーエンドでどのように実行されるかを確認するのに役立ちます。モジュールをテストする他の可能な方法を以下に示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:586 -msgid "Windows debugging" -msgstr "Windows のデバッグ" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:588 -msgid "Debugging a module currently can only be done on a Windows host. This can be useful when developing a new module or implementing bug fixes. These are some steps that need to be followed to set this up:" -msgstr "現在、モジュールのデバッグは Windows ホストでのみ実行できます。これは、新しいモジュールを開発したり、バグ修正を実装したりするときに役立ちます。これを設定するには、次の手順に従う必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:592 -msgid "Copy the module script to the Windows server" -msgstr "モジュールスクリプトを Windows サーバーにコピーします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:593 -msgid "Copy the folders ``./lib/ansible/module_utils/powershell`` and ``./lib/ansible/module_utils/csharp`` to the same directory as the script above" -msgstr "``./lib/ansible/module_utils/powershell`` ディレクトリーと ``./lib/ansible/module_utils/csharp`` ディレクトリーを上記のスクリプトと同じディレクトリーにコピーします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:594 -msgid "Add an extra ``#`` to the start of any ``#Requires -Module`` lines in the module code, this is only required for any lines starting with ``#Requires -Module``" -msgstr "モジュールコードにあるすべての ``#Requires -Module`` 行の先頭に ``#`` を追加してください。これは、``#Requires -Module`` で始まる行にのみ必要です。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:595 -msgid "Add the following to the start of the module script that was copied to the server:" -msgstr "以下を、サーバーにコピーされたモジュールスクリプトの先頭に追加します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:627 -msgid "You can add more args to ``$complex_args`` as required by the module or define the module options through a JSON file with the structure:" -msgstr "モジュールに必要な場合は ``$complex_args`` にさらに引数を追加したり、その構造を持つ JSON ファイルでモジュールオプションを定義することもできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:641 -msgid "There are multiple IDEs that can be used to debug a Powershell script, two of the most popular ones are" -msgstr "Powershell スクリプトのデバッグに使用できる IDE が複数あり、以下の 2 つが最も一般的なものになります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:644 -msgid "`Powershell ISE`_" -msgstr "`Powershell ISE`_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:645 -msgid "`Visual Studio Code`_" -msgstr "`Visual Studio Code`_" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:650 -msgid "To be able to view the arguments as passed by Ansible to the module follow these steps." -msgstr "Ansible がモジュールに渡した引数を表示するには、次の手順に従います。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:653 -msgid "Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server." -msgstr "Ansible コマンドの前に :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` を付けて、Ansible が exec ファイルをサーバ上に保持するように指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:654 -msgid "Log onto the Windows server using the same user account that Ansible used to execute the module." -msgstr "Ansible がモジュールの実行に使用したのと同じユーザーアカウントを使用して Windows サーバーにログインします。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:655 -msgid "Navigate to ``%TEMP%\\..``. It should contain a folder starting with ``ansible-tmp-``." -msgstr "``%TEMP%\\..`` に移動します。これには、``ansible-tmp-`` で始まるディレクトリーが含まれるはずです。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:656 -msgid "Inside this folder, open the PowerShell script for the module." -msgstr "このディレクトリー内で、モジュールの PowerShell スクリプトを開きます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:657 -msgid "In this script is a raw JSON script under ``$json_raw`` which contains the module arguments under ``module_args``. These args can be assigned manually to the ``$complex_args`` variable that is defined on your debug script or put in the ``args.json`` file." -msgstr "このスクリプトは、``$json_raw`` にある生の JSON スクリプトで、``module_args`` の下にモジュール引数が含まれています。これらの引数は、デバッグスクリプトで定義される ``$complex_args`` 変数に手動で割り当てたり、``args.json`` ファイルに置いたりできます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:661 -msgid "Windows unit testing" -msgstr "Windows ユニットテスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:663 -msgid "Currently there is no mechanism to run unit tests for Powershell modules under Ansible CI." -msgstr "現在、Ansible CI で Powershell モジュールのユニットテストを実行するメカニズムはありません。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:667 -msgid "Windows integration testing" -msgstr "Windows 統合テスト" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:669 -msgid "Integration tests for Ansible modules are typically written as Ansible roles. These test roles are located in ``./test/integration/targets``. You must first set up your testing environment, and configure a test inventory for Ansible to connect to." -msgstr "Ansible モジュールの統合テストは通常 Ansible ロールとして記述されます。これらのテストロールは ``./test/integration/targets`` にあります。まず、テスト環境を設定して、Ansible が接続できるようにテストインベントリーを設定する必要があります。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:673 -msgid "In this example we will set up a test inventory to connect to two hosts and run the integration tests for win_stat:" -msgstr "この例では、2 つのホストに接続し、win_stat の統合テストを実行するためのテストインベントリーを設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:676 -msgid "Run the command ``source ./hacking/env-setup`` to prepare environment." -msgstr "環境を準備するには、``source ./hacking/env-setup`` コマンドを実行します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:677 -msgid "Create a copy of ``./test/integration/inventory.winrm.template`` and name it ``inventory.winrm``." -msgstr "``./test/integration/inventory.winrm.template`` のコピーを作成し、``inventory.winrm`` という名前を指定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:678 -msgid "Fill in entries under ``[windows]`` and set the required variables that are needed to connect to the host." -msgstr "``[windows]`` の下にエントリーを入力し、ホストへの接続に必要な変数を設定します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:679 -msgid ":ref:`Install the required Python modules ` to support WinRM and a configured authentication method." -msgstr "WinRM と、設定された認証方法をサポートするのに :ref:`必要な Python モジュールをインストール ` します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:680 -msgid "To execute the integration tests, run ``ansible-test windows-integration win_stat``; you can replace ``win_stat`` with the role you want to test." -msgstr "統合テストを実行するには、``ansible-test windows-integration win_stat`` を実行します。``win_stat`` は、テストするロールに置き換えることができます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:682 -msgid "This will execute all the tests currently defined for that role. You can set the verbosity level using the ``-v`` argument just as you would with ansible-playbook." -msgstr "これにより、そのロールに対して現在定義されているすべてのテストが実行されます。ansible-playbook の場合と同じように、``-v`` 引数を使用して詳細レベルを設定できます。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:686 -msgid "When developing tests for a new module, it is recommended to test a scenario once in check mode and twice not in check mode. This ensures that check mode does not make any changes but reports a change, as well as that the second run is idempotent and does not report changes. For example:" -msgstr "新しいモジュールのテストを開発するときは、シナリオをチェックモードで 1 回、チェックモード以外で 2 回テストすることが推奨されます。これにより、チェックモードでは変更は行われず、変更が報告されます。また、2 回目の実行は冪等であり、変更は報告されません。以下に例を示します。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:739 -msgid "Windows communication and development support" -msgstr "Windows の通信および開発サポート" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:741 -msgid "Join the ``#ansible-devel`` or ``#ansible-windows`` chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) for discussions about Ansible development for Windows." -msgstr "``#ansible-devel`` または``#ansible-windows``チャットチャンネル（ansible.imでMatrixを使用、または`irc.libera.chat `でIRCを使用）に参加して、Windows向けのAnsible 開発に関する議論を行います。" - -#: ../../rst/dev_guide/developing_modules_general_windows.rst:743 -msgid "For questions and discussions pertaining to using the Ansible product, use the ``#ansible`` channel." -msgstr "Ansible 製品の使用に関する質問および貢献については、``#ansible`` チャンネルを使用します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:5 -msgid "Creating a new collection" -msgstr "新規コレクションの作成" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:7 -msgid "Starting with Ansible 2.10, related modules should be developed in a collection. The Ansible core team and community compiled these module development tips and tricks to help companies developing Ansible modules for their products and users developing Ansible modules for third-party products. See :ref:`developing_collections` for a more detailed description of the collections format and additional development guidelines." -msgstr "Ansible 2.10 以降、関連するモジュールをコレクションで開発する必要があります。Ansible コアチームおよびコミュニティーは、これらのモジュール開発のヒントとコツをまとめて、自社製品用の Ansible モジュールを開発している企業や、サードパーティー製品用の Ansible モジュールを開発しているユーザーを支援します。コレクションの形式と追加の開発ガイドラインの詳細は、「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:15 -msgid "Before you start coding" -msgstr "コーディングを開始する前に" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:17 -msgid "This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-core and provide a seamless user experience." -msgstr "この前提条件のリストは、ansible-core で適切に機能し、シームレスなユーザーエクスペリエンスを提供する高品質のモジュールを確実に開発できるように設計されています。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:19 -msgid "Read though all the pages linked off :ref:`developing_modules_general`; paying particular focus to the :ref:`developing_modules_checklist`." -msgstr "「:ref:`developing_modules_general`」からリンクされているすべてのページを読みます。特に、「:ref:`developing_modules_checklist`」に注意してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:20 -msgid "We encourage PEP 8 compliance. See :ref:`testing_pep8` for more information." -msgstr "PEP 8 コンプライアンスが推奨されます。詳細は「:ref:`testing_pep8`」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:21 -msgid "We encourage supporting :ref:`Python 2.6+ and Python 3.5+ `." -msgstr ":ref:`Python 2.6 以降および Python 3.5 以降 ` をサポートすることが推奨されます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:22 -msgid "Look at Ansible Galaxy and review the naming conventions in your functional area (such as cloud, networking, databases)." -msgstr "Ansible Galaxy を確認し、機能エリア (クラウド、ネットワーク、データベースなど) で命名規則を確認します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:23 -msgid "With great power comes great responsibility: Ansible collection maintainers have a duty to help keep content up to date and release collections they are responsible for regularly. As with all successful community projects, collection maintainers should keep a watchful eye for reported issues and contributions." -msgstr "大きな力には大きな責任が伴います。Ansible コレクションのメンテナーには、コンテンツを最新の状態に保ち、定期的に責任のあるコレクションをリリースするのを支援する義務があります。成功しているすべてのコミュニティープロジェクトと同様に、コレクションのメンテナーは、報告された問題や貢献に注意を払う必要があります。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:24 -msgid "We strongly recommend unit and/or integration tests. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :ref:`developing_testing` and the `Testing Working Group `_." -msgstr "ユニットテストや統合テストが強く推奨されます。ユニットテストは、外部リソース (クラウドやネットワークデバイスなど) が必要な場合に特に役に立ちます。詳細については、「:ref:`developing_testing`」および「`Testing Working Group `_」を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:28 -msgid "Naming conventions" -msgstr "命名規則" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:30 -msgid "Fully Qualified Collection Names (FQCNs) for plugins and modules include three elements:" -msgstr "プラグインおよびモジュール用の完全修飾コレクション名 (FQCN) には 3 つの要素があります。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:32 -msgid "the Galaxy namespace, which generally represents the company or group" -msgstr "Galaxy 名前空間。通常、会社またはグループを表します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:33 -msgid "the collection name, which generally represents the product or OS" -msgstr "コレクション名。通常は製品または OS を表します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:37 -msgid "the plugin or module name" -msgstr "プラグインまたはモジュール名" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:35 -msgid "always in lower case" -msgstr "常に小文字" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:36 -msgid "words separated with an underscore (``_``) character" -msgstr "単語はアンダースコア (``_``) 文字で区切られます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:37 -msgid "singular, rather than plural, for example, ``command`` not ``commands``" -msgstr "複数形ではなく、単数形 (例: ``commands`` ではなく ``command``)" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:39 -msgid "For example, ``community.mongodb.mongodb_linux`` or ``cisco.meraki.meraki_device``." -msgstr "たとえば、``community.mongodb.mongodb_linux`` または ``cisco.meraki.meraki_device`` です。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:41 -msgid "It is convenient if the organization and repository names on GitHub (or elsewhere) match your namespace and collection names on Ansible Galaxy, but it is not required. The plugin names you select, however, are always the same in your code repository and in your collection artifact on Galaxy." -msgstr "GitHub (または別の場所) の組織とリポジトリー名が Ansible Galaxy の名前空間とコレクション名と一致する場合に便利ですが、必須ではありません。ただし、選択したプラグイン名は、コードリポジトリーと Galaxy のコレクションアーティファクトで常に同じです。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:44 -msgid "Speak to us" -msgstr "お問い合わせ" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:46 -msgid "Circulating your ideas before coding helps you adopt good practices and avoid common mistakes. After reading the \"Before you start coding\" section you should have a reasonable idea of the structure of your modules. Write a list of your proposed plugin and/or module names, with a short description of what each one does. Circulate that list on IRC or a mailing list so the Ansible community can review your ideas for consistency and familiarity. Names and functionality that are consistent, predictable, and familiar make your collection easier to use." -msgstr "コーディングの前にアイデアを出し合うことで、良い習慣を取り入れ、よくある間違いを避けることができます。「コーディングを始める前に」のセクションを読んだ後、モジュールの構造について妥当なアイデアがあるはずです。提案するプラグインやモジュールの名前のリストを書き、それぞれが何をするのかを簡単に説明してください。そのリストを、IRC やメーリングリストで共有して、Ansible コミュニティーが一貫性や親しみやすさの観点からアイデアを検討できるようにします。一貫性があり、予測可能で、親しみやすい名前や機能は、コレクションをより使いやすくします。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:51 -msgid "Where to get support" -msgstr "サポートを受ける場所" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:53 -msgid "Ansible has a thriving and knowledgeable community of module developers that is a great resource for getting your questions answered." -msgstr "Ansible には、活発で知識が豊富なモジュール開発者のコミュニティーがあり、質問に答えるための素晴らしいリソースとなっています。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:55 -msgid "In the :ref:`ansible_community_guide` you can find how to:" -msgstr ":ref:`ansible_community_guide` で、以下の方法を見つけることができます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:57 -msgid "Subscribe to the Mailing Lists - We suggest \"Ansible Development List\" and \"Ansible Announce list\"" -msgstr "メーリングリストをサブスクライブすること。「Ansible Development List」および「Ansible Announce list」をお勧めします。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:58 -msgid "``#ansible-devel`` - We have found that communicating on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) works best for developers so we can have an interactive dialogue." -msgstr "``#ansible-devel`` - ``#ansible-devel``のチャットチャンネル（ansible.im でMatrixを使用、または`irc.libera.chat `でIRCを使用）での対話が開発者に最適なものであることが分かっています。したがって、インタラクティブな会話を行うことができます。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:59 -msgid "Working group and other chat channel meetings - Join the various weekly meetings `meeting schedule and agenda page `_" -msgstr "ワーキンググループおよびその他のチャットチャンネルミーティング - さまざまな週間ミーティング (`meeting schedule and agenda page `_) に参加してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:62 -msgid "Required files" -msgstr "必須ファイル" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:64 -msgid "Your collection should include the following files to be usable:" -msgstr "コレクションには、使用可能な以下のファイルが含まれているはずです。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:66 -msgid "an ``__init__.py`` file - An empty file to initialize namespace and allow Python to import the files. *Required*" -msgstr "``__init__.py`` ファイル - 名前空間を初期化し、Python がファイルをインポートできるようにする空のファイル。*必須*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:67 -msgid "at least one plugin, for example, ``/plugins/modules/$your_first_module.py``. *Required*" -msgstr "少なくとも 1 つのプラグイン (例: ``/plugins/modules/$your_first_module.py``)。*必須*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:68 -msgid "if needed, one or more ``/plugins/doc_fragments/$topic.py`` files - Code documentation, such as details regarding common arguments. *Optional*" -msgstr "必要な場合は、1 つ以上の ``/plugins/doc_fragments/$topic.py`` ファイル - 一般的な引数の詳細などのコードのドキュメント。*任意*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:69 -msgid "if needed, one or more ``/plugins/module_utils/$topic.py`` files - Code shared between more than one module, such as common arguments. *Optional*" -msgstr "必要な場合は、1 つ以上の ``/plugins/module_utils/$topic.py`` ファイル - 一般的な引数などの、複数のモジュール間で共有されるコード。*任意*" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:71 -msgid "When you have these files ready, review the :ref:`developing_modules_checklist` again. If you are creating a new collection, you are responsible for all procedures related to your repository, including setting rules for contributions, finding reviewers, and testing and maintaining the code in your collection." -msgstr "これらのファイルの準備が整ったら、:ref:`developing_modules_checklist` を再度確認します。新しいコレクションを作成する場合は、貢献のルール設定、レビュー担当者の見つけ方、コレクションにおけるコードのテストおよび保守など、リポジトリーに関連するすべての手順を担当します。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:73 -msgid "If you need help or advice, consider joining the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). For more information, see :ref:`developing_in_groups_support` and :ref:`communication`." -msgstr "ヘルプやアドバイスが必要な場合は、``#ansible-devel`` チャットチャンネルへの参加をご検討ください（ansible.imでMatrixの使用または`irc.libera.chat `_でIRCを使用）。詳細については、:ref:`developing_in_groups_support` と:ref:`communication` を参照してください。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:76 -msgid "New to git or GitHub" -msgstr "git または GitHub をはじめて使用する場合" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:78 -msgid "We realize this may be your first use of Git or GitHub. The following guides may be of use:" -msgstr "ここでは、Git または GitHub を初めて使用するユーザーを対象としています。次のガイドが参考になるかもしれません。" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:80 -msgid "`How to create a fork of ansible/ansible `_" -msgstr "`How to create a fork of ansible/ansible `_" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:81 -msgid "`How to sync (update) your fork `_" -msgstr "`How to sync (update) your fork `_" - -#: ../../rst/dev_guide/developing_modules_in_groups.rst:82 -msgid "`How to create a Pull Request (PR) `_" -msgstr "`How to create a Pull Request (PR) `_" - -#: ../../rst/dev_guide/developing_plugins.rst:6 -msgid "Developing plugins" -msgstr "プラグインの開発" - -#: ../../rst/dev_guide/developing_plugins.rst:11 -msgid "Plugins augment Ansible's core functionality with logic and features that are accessible to all modules. Ansible collections include a number of handy plugins, and you can easily write your own. All plugins must:" -msgstr "プラグインは、すべてのモジュールがアクセスできるロジックおよび機能を使用して Ansible のコア機能を拡張します。Ansible コレクションには多くの便利なプラグインが含まれており、独自のプラグインを簡単に作成できます。すべてのプラグインでは、以下を行う必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:13 -msgid "be written in Python" -msgstr "Python で書かれている。" - -#: ../../rst/dev_guide/developing_plugins.rst:14 -msgid "raise errors" -msgstr "エラーを発生させる。" - -#: ../../rst/dev_guide/developing_plugins.rst:15 -msgid "return strings in unicode" -msgstr "Unicode で文字列を返す。" - -#: ../../rst/dev_guide/developing_plugins.rst:16 -msgid "conform to Ansible's configuration and documentation standards" -msgstr "Ansible の設定およびドキュメントの標準仕様に準拠する。" - -#: ../../rst/dev_guide/developing_plugins.rst:18 -msgid "Once you've reviewed these general guidelines, you can skip to the particular type of plugin you want to develop." -msgstr "これらの一般的なガイドラインを確認したら、開発する特定のタイプのプラグインに進んでください。" - -#: ../../rst/dev_guide/developing_plugins.rst:21 -msgid "Writing plugins in Python" -msgstr "Python でのプラグインの作成" - -#: ../../rst/dev_guide/developing_plugins.rst:23 -msgid "You must write your plugin in Python so it can be loaded by the ``PluginLoader`` and returned as a Python object that any module can use. Since your plugin will execute on the controller, you must write it in a :ref:`compatible version of Python `." -msgstr "``PluginLoader`` により読み込まれ、モジュールが使用できる Python オブジェクトとして返すには、Python でプラグインを作成する必要があります。プラグインはコントローラーで実行するため、:ref:`互換性のある Python バージョン ` で作成する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:26 -msgid "Raising errors" -msgstr "エラーの発生" - -#: ../../rst/dev_guide/developing_plugins.rst:28 -msgid "You should return errors encountered during plugin execution by raising ``AnsibleError()`` or a similar class with a message describing the error. When wrapping other exceptions into error messages, you should always use the ``to_native`` Ansible function to ensure proper string compatibility across Python versions:" -msgstr "プラグインの実行中に発生したエラーは、``AnsibleError()`` またはエラーを記述したメッセージのある同様のクラスを発生させて返す必要があります。他の例外をエラーメッセージにラップする場合は、Python のバージョン間で適切な文字列の互換性を確保するために、常に Ansible 関数の ``to_native`` を使用する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:39 -msgid "Since Ansible evaluates variables only when they are needed, filter and test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary." -msgstr "Ansibleは必要なときにのみ変数を評価するので、未定義の変数が必要なときにのみ致命的な問題を起こすように、フィルターやテストプラグインは、例外``jinja2.exceptions.UndefinedError`` と``AnsibleUndefinedVariable`` を伝播させる必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:41 -msgid "Check the different `AnsibleError objects `_ and see which one applies best to your situation. Check the section on the specific plugin type you're developing for type-specific error handling details." -msgstr "さまざまな`AnsibleError objects `_ をチェックして、どれが自分の状況に最も適しているかを確認してください。開発している特定のプライグインタイプに固有のエラー処理の詳細については、そのタイプのセクションを確認してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:45 -msgid "String encoding" -msgstr "文字列エンコーディング" - -#: ../../rst/dev_guide/developing_plugins.rst:47 -msgid "You must convert any strings returned by your plugin into Python's unicode type. Converting to unicode ensures that these strings can run through Jinja2. To convert strings:" -msgstr "プラグインによって返される文字列は、Python の Unicode タイプに変換する必要があります。Unicode に変換すると、これらの文字列が Jinja2 を介して実行できるようになります。文字列を変換するには、次を実行します。" - -#: ../../rst/dev_guide/developing_plugins.rst:55 -msgid "Plugin configuration & documentation standards" -msgstr "プラグインの設定およびドキュメントの標準仕様" - -#: ../../rst/dev_guide/developing_plugins.rst:57 -msgid "To define configurable options for your plugin, describe them in the ``DOCUMENTATION`` section of the python file. Callback and connection plugins have declared configuration requirements this way since Ansible version 2.4; most plugin types now do the same. This approach ensures that the documentation of your plugin's options will always be correct and up-to-date. To add a configurable option to your plugin, define it in this format:" -msgstr "プラグインの設定可能なオプションを定義するには、python ファイルの ``DOCUMENTATION`` セクションに記述します。コールバックおよび connection プラグインは、Ansible バージョン 2.4 以降、この方法で設定要件を宣言します。現在、ほとんどのプラグインタイプが同じように動作するようになりました。この方法により、プラグインのオプションのドキュメントが常に正確で最新の状態になります。設定可能なオプションをプラグインに追加するには、以下の形式で定義します。" - -#: ../../rst/dev_guide/developing_plugins.rst:78 -msgid "To access the configuration settings in your plugin, use ``self.get_option()``. For the plugin types (such as 'become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', and 'vars') that support embedded documentation, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call." -msgstr "プラグインの構成設定にアクセスするには、``self.get_option()``を使用します。組み込まれたドキュメントをサポートするプラグインタイプ(例：'become'、'cache'、'callback'、'cliconf'、'connection'、'httpapi'、'inventory'、'lookup'、'netconf'、'shell'、および'vars')については、コントローラーが設定を事前に設定します。明示的に設定を設定する必要がある場合は、``self.set_options()`` の呼び出しを使用してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:80 -msgid "Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information." -msgstr "設定ソースは、Ansibleの値の優先順位ルールに従います。同じカテゴリからの値が複数ある場合、最後に定義された値が優先されます。たとえば、上記の設定ブロックでは、``name_of_ansible_var`` と``name_of_second_var`` の両方が定義されている場合、``option_name`` オプションの値は``name_of_second_var`` の値になります。詳細は:ref:`general_precedence_rules` を参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:82 -msgid "Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either through a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use." -msgstr "埋め込みドキュメントをサポートするプラグイン (リストは :ref:`ansible-doc` を参照) は、適切に構築されたドキュメント文字列を含める必要があります。プラグインから継承する場合は、ドキュメントフラグメントを介して、またはコピーとして、必要なオプションを記述する必要があります。正しいドキュメントに関する詳細は、「:ref:`module_documenting`」を参照してください。ローカルで使用するプラグインを開発している場合でも、完全なドキュメントを作成することが推奨されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:86 -msgid "In ansible-core 2.14 we added support for documenting filter and test plugins. You have two options for providing documentation:" -msgstr "ansible-core 2.14 では、フィルターおよびテストプラグインのドキュメント化をサポートするようになりました。ドキュメントの提供には、次の 2 つのオプションがあります。" - -#: ../../rst/dev_guide/developing_plugins.rst:85 -msgid "Define a Python file that includes inline documentation for each plugin." -msgstr "各プラグインのインラインドキュメントを含む Python ファイルを定義します。" - -#: ../../rst/dev_guide/developing_plugins.rst:86 -msgid "Define a Python file for multiple plugins and create adjacent documentation files in YAML format." -msgstr "複数のプラグイン用の Python ファイルを定義し、隣接するドキュメントファイルを YAML 形式で作成します。" - -#: ../../rst/dev_guide/developing_plugins.rst:89 -msgid "Developing particular plugin types" -msgstr "特定のプラグインタイプの開発" - -#: ../../rst/dev_guide/developing_plugins.rst:94 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:24 -msgid "Action plugins" -msgstr "action プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:96 -msgid "Action plugins let you integrate local processing and local data with module functionality." -msgstr "action プラグインを使用すると、ローカル処理とローカルデータをモジュール機能に統合できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:98 -msgid "To create an action plugin, create a new class with the Base(ActionBase) class as the parent:" -msgstr "action プラグインを作成するには、Base(ActionBase) クラスを親として新しいクラスを作成します。" - -#: ../../rst/dev_guide/developing_plugins.rst:107 -msgid "From there, execute the module using the ``_execute_module`` method to call the original module. After successful execution of the module, you can modify the module return data." -msgstr "そこから、``_execute_module`` メソッドを使用してモジュールを実行して、元のモジュールを呼び出します。モジュールの実行に成功すると、モジュールの戻り値データを変更できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:117 -msgid "For example, if you wanted to check the time difference between your Ansible controller and your target machine(s), you could write an action plugin to check the local time and compare it to the return data from Ansible's ``setup`` module:" -msgstr "たとえば、Ansible コントローラーとターゲットマシン間の時間差を確認する場合は、action プラグインを作成してローカルタイムを確認し、それを Ansible の ``setup`` モジュールから返されるデータと比較できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:154 -msgid "This code checks the time on the controller, captures the date and time for the remote machine using the ``setup`` module, and calculates the difference between the captured time and the local time, returning the time delta in days, seconds and microseconds." -msgstr "このコードはコントローラーの時間を確認し、``setup`` モジュールを使用してリモートマシンの日時を取得し、取得した時間とローカル時間の差異を算出し、その時間差を日数、秒、およびマイクロ秒で返します。" - -#: ../../rst/dev_guide/developing_plugins.rst:157 -msgid "For practical examples of action plugins, see the source code for the `action plugins included with Ansible Core `_" -msgstr "action プラグインの実際の例は、`Ansible Core に同梱される action プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:163 -msgid "Cache plugins" -msgstr "Cache プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:165 -msgid "Cache plugins store gathered facts and data retrieved by inventory plugins." -msgstr "dache プラグインは、inventory プラグインによって取得されるファクトおよびデータを格納します。" - -#: ../../rst/dev_guide/developing_plugins.rst:167 -msgid "Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option()``. If you import a cache plugin directly in the code base, you can only access options by the ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin." -msgstr "``self.set_options()`` および ``self.get_option()`` を使用できる cache_loader を使用する cache プラグインをインポートします。コードベースで cache プラグインを直接インポートする場合は、``ansible.constants`` からのみオプションにアクセスでき、inventory プラグインによって使用される cache プラグインの機能が壊れます。" - -#: ../../rst/dev_guide/developing_plugins.rst:175 -msgid "There are two base classes for cache plugins, ``BaseCacheModule`` for database-backed caches, and ``BaseCacheFileModule`` for file-backed caches." -msgstr "cache プラグインには、2 つのベースクラス (データベースベースのバックアップ用のキャッシュの場合は ``BaseCacheModule``、ファイルのバックアップ用のキャッシュの場合は ``BaseCacheFileModule``) があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:177 -msgid "To create a cache plugin, start by creating a new ``CacheModule`` class with the appropriate base class. If you're creating a plugin using an ``__init__`` method you should initialize the base class with any provided args and kwargs to be compatible with inventory plugin cache options. The base class calls ``self.set_options(direct=kwargs)``. After the base class ``__init__`` method is called ``self.get_option()`` should be used to access cache options." -msgstr "キャッシュプラグインを作成するには、適切なベースクラスで新しい ``CacheModule`` クラスを作成して開始します。``__init__`` メソッドを使用してプラグインを作成する場合は、指定された arg および kwarg でベースクラスを初期化し、インベントリープラグインキャッシュオプションと互換性がある必要があります。ベースクラスは ``self.set_options(direct=kwargs)`` を呼び出します。ベースクラス ``__init__`` メソッドが呼び出されると、``self.get_option()`` を使用して、キャッシュオプションにアクセスする必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:179 -msgid "New cache plugins should take the options ``_uri``, ``_prefix``, and ``_timeout`` to be consistent with existing cache plugins." -msgstr "新しい cache プラグインは、既存の cache プラグインとの整合性を保つために、``_uri`` オプション、``_prefix`` オプション、および ``_timeout`` オプションを使用する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:192 -msgid "If you use the ``BaseCacheModule``, you must implement the methods ``get``, ``contains``, ``keys``, ``set``, ``delete``, ``flush``, and ``copy``. The ``contains`` method should return a boolean that indicates if the key exists and has not expired. Unlike file-based caches, the ``get`` method does not raise a KeyError if the cache has expired." -msgstr "``BaseCacheModule`` を使用する場合は、メソッド ``get``、``contains``、``keys``、``set``、``delete``、``flush``、および ``copy`` を実装する必要があります。``contains`` メソッドは、キーが存在し、有効期限が切れていないことを示すブール値を返すはずです。ファイルベースのキャッシュとは異なり、キャッシュの有効期限が切れると、``get`` メソッドによって KeyError は発生しません。" - -#: ../../rst/dev_guide/developing_plugins.rst:194 -msgid "If you use the ``BaseFileCacheModule``, you must implement ``_load`` and ``_dump`` methods that will be called from the base class methods ``get`` and ``set``." -msgstr "``BaseFileCacheModule`` を使用する場合は、ベースクラスメソッド ``get`` および ``set`` から呼び出される ``_load`` メソッドおよび ``_dump`` メソッドを実装する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:196 -msgid "If your cache plugin stores JSON, use ``AnsibleJSONEncoder`` in the ``_dump`` or ``set`` method and ``AnsibleJSONDecoder`` in the ``_load`` or ``get`` method." -msgstr "キャッシュプラグインに JSON が保存されている場合は、``_dump`` メソッドまたは ``set`` メソッドの ``AnsibleJSONEncoder`` と、``_load`` メソッドまたは``get`` メソッドの ``AnsibleJSONDecoder`` を使用します。" - -#: ../../rst/dev_guide/developing_plugins.rst:198 -msgid "For example cache plugins, see the source code for the `cache plugins included with Ansible Core `_." -msgstr "cache プラグインの例は、`Ansible Core に同梱される cache プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:203 -msgid "Callback plugins" -msgstr "callback プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:205 -msgid "Callback plugins add new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs." -msgstr "callback プラグインは、イベントに応答する際に新しい動作を Ansible に追加します。デフォルトでは、callback プラグインは、コマンドラインプログラムの実行時に表示されるほとんどの出力を制御します。" - -#: ../../rst/dev_guide/developing_plugins.rst:207 -msgid "To create a callback plugin, create a new class with the Base(Callbacks) class as the parent:" -msgstr "callback プラグインを作成するには、Base(Callbacks) クラスを親として使用して新規クラスを作成します。" - -#: ../../rst/dev_guide/developing_plugins.rst:216 -msgid "From there, override the specific methods from the CallbackBase that you want to provide a callback for. For plugins intended for use with Ansible version 2.0 and later, you should only override methods that start with ``v2``. For a complete list of methods that you can override, please see ``__init__.py`` in the `lib/ansible/plugins/callback `_ directory." -msgstr "そこから、コールバックを提供する CallbackBase から特定のメソッドを上書きします。Ansible バージョン 2.0 以降で使用するプラグインでは、``v2`` で始まる方法のみを上書きしてください。上書きできるメソッドの完全なリストは、`lib/ansible/plugins/callback `_ ディレクトリーの ``__init__.py`` を参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:221 -msgid "The following is a modified example of how Ansible's timer plugin is implemented, but with an extra option so you can see how configuration works in Ansible version 2.4 and later:" -msgstr "以下は、Ansible の timer プラグインの実装方法の変更例です。ただし、追加のオプションを使用すると、Ansible バージョン 2.4 以降で構成がどのように機能するかを確認できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:290 -msgid "Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are required for properly functioning plugins for Ansible version 2.0 and later. ``CALLBACK_TYPE`` is mostly needed to distinguish 'stdout' plugins from the rest, since you can only load one plugin that writes to stdout." -msgstr "``CALLBACK_VERSION`` および ``CALLBACK_NAME`` の定義は、Ansible バージョン 2.0 以降のプラグインが正しく機能するために必要であることに注意してください。``CALLBACK_TYPE`` は、標準出力 (stdout) に書き込むプラグインを 1 つだけ読み込むことができるため、ほとんどの「stdout」プラグインをその他のものと区別するために必要です。" - -#: ../../rst/dev_guide/developing_plugins.rst:292 -msgid "For example callback plugins, see the source code for the `callback plugins included with Ansible Core `_" -msgstr "callback プラグインの例は、`Ansible Core に同梱される callback プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:294 -msgid "New in ansible-core 2.11, callback plugins are notified (by the ``v2_playbook_on_task_start``) of :ref:`meta` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks." -msgstr "ansible-core 2.11 の新機能として、:ref:`meta` タスクのコールバックプラグインが (``v2_playbook_on_task_start`` を介して) 通知されます。デフォルトでは、プレイに追加する明示的な ``meta`` タスクのみが、コールバックに送信されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:296 -msgid "There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user." -msgstr "実行のさまざまな時点で、内部的および暗黙的に生成されるタスクもいくつかあります。callback プラグインは、``self.wants_implicit_tasks = True`` を設定することにより、これらの暗黙的なタスクを受け取ることをオプトインできます。コールバックフックによって受信した ``Task`` オブジェクトには、``.implicit`` 属性があります。これを参照して、``Task`` が Ansible 内から、またはユーザーによって明示的に発信されたかどうかを決めるために参照します。" - -#: ../../rst/dev_guide/developing_plugins.rst:301 -msgid "Connection plugins" -msgstr "connection プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:303 -msgid "Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. The most commonly used connection plugins are the ``paramiko`` SSH, native ssh (just called ``ssh``), and ``local`` connection types. All of these can be used in playbooks and with ``/usr/bin/ansible`` to connect to remote machines." -msgstr "connection プラグインにより、Ansible はターゲットホストに接続してそのホストにあるタスクを実行できるようにします。Ansible には多くの connection プラグインが同梱されていますが、一度に使用できるのは 1 つのみとなります。最も一般的に使用される connection プラグインは、``paramiko`` SSH、ネイティブ ssh (単に ``ssh`` と呼ばれる)、および ``local`` 接続タイプです。これらはすべて Playbook で使用され、``/usr/bin/ansible`` を使用してリモートマシンに接続します。" - -#: ../../rst/dev_guide/developing_plugins.rst:305 -msgid "Ansible version 2.1 introduced the ``smart`` connection plugin. The ``smart`` connection type allows Ansible to automatically select either the ``paramiko`` or ``openssh`` connection plugin based on system capabilities, or the ``ssh`` connection plugin if OpenSSH supports ControlPersist." -msgstr "Ansible バージョン 2.1 では、``smart`` connection プラグインが導入されます。``smart`` 接続タイプにより、Ansible は、システム機能に基づいて、``paramiko`` または ``openssh`` connection プラグインのいずれかを自動的に選択できますが、OpenSSH が ControlPersist に対応している場合は connetion プラグイン ``ssh`` を選択します。" - -#: ../../rst/dev_guide/developing_plugins.rst:307 -msgid "To create a new connection plugin (for example, to support SNMP, Message bus, or other transports), copy the format of one of the existing connection plugins and drop it into ``connection`` directory on your :ref:`local plugin path `." -msgstr "新しい connetion プラグイン (SNMP、メッセージバス、またはその他のトランスポートをサポートする場合など) を作成するには、既存の connetion プラグインのいずれかの形式をコピーして、:ref:`ローカルプラグインパス ` にある ``connection`` ディレクトリーに置きます。" - -#: ../../rst/dev_guide/developing_plugins.rst:309 -msgid "Connection plugins can support common options (such as the ``--timeout`` flag) by defining an entry in the documentation for the attribute name (in this case ``timeout``). If the common option has a non-null default, the plugin should define the same default since a different default would be ignored." -msgstr "connection プラグインは、属性名 (ここでは ``timeout``) のドキュメントでエントリーを定義することで、一般的なオプション (``--timeout`` フラグなど) をサポートします。一般的なオプションには null 以外のデフォルトがある場合、別のデフォルトは無視されるため、プラグインは同じデフォルトを定義する必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:311 -msgid "For example connection plugins, see the source code for the `connection plugins included with Ansible Core `_." -msgstr "選択プラグインの例は、`Ansible Core に同梱される接続プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:316 -msgid "Filter plugins" -msgstr "filter プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:318 -msgid "Filter plugins manipulate data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the filter plugins shipped with Ansible reside in a ``core.py``." -msgstr "filter プラグインはデータを操作します。これらは Jinja2 の機能であり、``template`` モジュールが使用する Jinja2 テンプレートで利用できます。すべてのプラグインと同様に、プラグインは簡単に拡張できますが、プラグインごとにファイルを作成する代わりに、ファイルごとに複数のプラグインを作成できます。Ansible に同梱されているフィルタープラグインのほとんどは、``core.py`` にあります。" - -#: ../../rst/dev_guide/developing_plugins.rst:320 -msgid "Filter plugins do not use the standard configuration system described above, but since ansible-core 2.14 can use it as plain documentation." -msgstr "フィルタープラグインは、上記の標準設定システムを使用しませんが、ansible-core 2.14 以降では単純なドキュメントとして使用できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:322 -msgid "Since Ansible evaluates variables only when they are needed, filter plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary." -msgstr "Ansibleは必要なときにのみ変数を評価するので、未定義の変数が必要なときにのみ致命的な問題を起こすように、フィルタープラグインは、例外``jinja2.exceptions.UndefinedError`` と``AnsibleUndefinedVariable`` を伝播させる必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:333 -msgid "For example filter plugins, see the source code for the `filter plugins included with Ansible Core `_." -msgstr "filter プラグインの例は、`Ansible Core に同梱される filter プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:340 -msgid "Inventory plugins parse inventory sources and form an in-memory representation of the inventory. Inventory plugins were added in Ansible version 2.4." -msgstr "inventory プラグインはインベントリーソースを解析し、インベントリーのインメモリー表示を形成します。inventory プラグインは Ansible バージョン 2.4 で追加されました。" - -#: ../../rst/dev_guide/developing_plugins.rst:342 -msgid "You can see the details for inventory plugins in the :ref:`developing_inventory` page." -msgstr "inventory プラグインの詳細は、:ref:`developing_inventory` ページを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:347 -msgid "Lookup plugins" -msgstr "lookup プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:349 -msgid "Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented through lookup plugins --- and to return values into a variable or parameter." -msgstr "lookup プラグインは、外部データストアからデータをプルします。lookup プラグインは Playbook 内でループするため (``with_fileglob`` や ``with_items`` などの Playbook 言語の構造は lookup プラグインを介して実装されています)、また変数やパラメーターに値を返すために使用することができます。" - -#: ../../rst/dev_guide/developing_plugins.rst:351 -msgid "Lookup plugins are expected to return lists, even if just a single element." -msgstr "lookup プラグインは、単一の要素のみであってもリストを返すことが想定されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:353 -msgid "Ansible includes many :ref:`filters ` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin." -msgstr "Ansible には、lookup プラグインが返すデータを操作するために使用できる :ref:`filters ` が多数含まれています。lookup プラグイン内でフィルタリングを行うことが理にかなっている場合もあれば、Playbook でフィルタリングできる結果を返す方がよい場合もあります。lookup プラグイン内で実行する適切なフィルタリングレベルを決定するときは、データがどのように参照されるかに留意してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:355 -msgid "Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable:" -msgstr "以下は簡単な lookup プラグインの実装です。この lookup は、テキストファイルの内容を変数として返します。" - -#: ../../rst/dev_guide/developing_plugins.rst:432 -msgid "The following is an example of how this lookup is called:" -msgstr "以下は、このルックアップがどのように呼び出されるかの例になります。" - -#: ../../rst/dev_guide/developing_plugins.rst:447 -msgid "For example lookup plugins, see the source code for the `lookup plugins included with Ansible Core `_." -msgstr "lookup プラグインの例は、`Ansible Core に同梱される lookup プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:449 -msgid "For more usage examples of lookup plugins, see :ref:`Using Lookups`." -msgstr "lookup プラグインのその他の使用例については、「:ref:`検索の使用`」を参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:454 -msgid "Test plugins" -msgstr "test プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:456 -msgid "Test plugins verify data. They are a feature of Jinja2 and are also available in Jinja2 templates used by the ``template`` module. As with all plugins, they can be easily extended, but instead of having a file for each one you can have several per file. Most of the test plugins shipped with Ansible reside in a ``core.py``. These are specially useful in conjunction with some filter plugins like ``map`` and ``select``; they are also available for conditional directives like ``when:``." -msgstr "テストプラグインはデータを検証します。これは Jinja2 の機能で、``template`` モジュールが使用する Jinja2 テンプレートでも利用できます。他のすべてのプラグインと同様、このプラグインは簡単に拡張できますが、プラグインごとにファイルを作成する代わりに、ファイルごとに複数のプラグインを作成できます。Ansible に同梱されているテストプラグインのほとんどは、``core.py`` に格納されています。これらのプラグインは、``map`` や ``select`` などの filter プラグインと組み合わせて使うと特に便利です。また、``when:`` などの条件付きディレクティブにも利用できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:458 -msgid "Test plugins do not use the standard configuration system described above. Since ansible-core 2.14 test plugins can use plain documentation." -msgstr "テストプラグインは、上記の標準設定システムを使用しません。ansible-core 2.14 以降において、テストプラグインは単純なドキュメントを使用できます。" - -#: ../../rst/dev_guide/developing_plugins.rst:460 -msgid "Since Ansible evaluates variables only when they are needed, test plugins should propagate the exceptions ``jinja2.exceptions.UndefinedError`` and ``AnsibleUndefinedVariable`` to ensure undefined variables are only fatal when necessary." -msgstr "Ansibleは必要なときにのみ変数を評価するので、未定義の変数が必要なときにのみ致命的な問題を起こすように、テストプラグインは、例外``jinja2.exceptions.UndefinedError`` と``AnsibleUndefinedVariable`` を伝播させる必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:471 -msgid "For example test plugins, see the source code for the `test plugins included with Ansible Core `_." -msgstr "test プラグインの例は、`Ansible Core に同梱される test プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:476 -msgid "Vars plugins" -msgstr "vars プラグイン" - -#: ../../rst/dev_guide/developing_plugins.rst:478 -msgid "Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins." -msgstr "vars プラグインは、インベントリーソース、Playbook、またはコマンドラインに組み込まれていない Ansible の実行に、変数データを追加します。「host_vars」や「group_vars」のような Playbook の構成要素は、vars プラグインを使用します。" - -#: ../../rst/dev_guide/developing_plugins.rst:480 -msgid "Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are supported by collections starting with Ansible 2.10." -msgstr "vars プラグインは Ansible 2.0 に部分的に実装され、Ansible 2.4 以降では、完全実装になるように書き直されました。vars プラグインはAnsible 2.10以降コレクションのサポート対象となります。" - -#: ../../rst/dev_guide/developing_plugins.rst:482 -msgid "Older plugins used a ``run`` method as their main body/work:" -msgstr "古いプラグインでは、``run`` メソッドを主要な本文/作業として使用していました。" - -#: ../../rst/dev_guide/developing_plugins.rst:490 -msgid "Ansible 2.0 did not pass passwords to older plugins, so vaults were unavailable. Most of the work now happens in the ``get_vars`` method which is called from the VariableManager when needed." -msgstr "Ansible 2.0 は古いプラグインにパスワードを渡さなかったため、vault は利用できませんでした。ほとんどの作業は、必要に応じて VariableManager から呼び出される ``get_vars`` メソッドで実行されるようになりました。" - -#: ../../rst/dev_guide/developing_plugins.rst:498 -msgid "The parameters are:" -msgstr "パラメーターは以下のとおりです。" - -#: ../../rst/dev_guide/developing_plugins.rst:500 -msgid "loader: Ansible's DataLoader. The DataLoader can read files, auto-load JSON/YAML and decrypt vaulted data, and cache read files." -msgstr "loader: Ansible の DataLoader。DataLoader は、ファイルの読み取り、JSON/YAML の自動読み込み、vault を使用したデータの復号、および読み取りファイルのキャッシュを行うことができます。" - -#: ../../rst/dev_guide/developing_plugins.rst:501 -msgid "path: this is 'directory data' for every inventory source and the current play's playbook directory, so they can search for data in reference to them. ``get_vars`` will be called at least once per available path." -msgstr "path: これはすべてのインベントリーソースと現在のプレイの Playbook ディレクトリーの「ディレクトリーデータ」であるため、それを参照するデータを検索することができます。``get_vars`` は、利用可能なパスごとに最低 1 回呼び出されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:502 -msgid "entities: these are host or group names that are pertinent to the variables needed. The plugin will get called once for hosts and again for groups." -msgstr "entities: 必要な変数に関連付けられるホスト名またはグループ名です。プラグインはホストに対して 1 回呼び出され、グループに対して再度呼び出されます。" - -#: ../../rst/dev_guide/developing_plugins.rst:504 -msgid "This ``get_vars`` method just needs to return a dictionary structure with the variables." -msgstr "この ``get_vars`` メソッドは変数を含むディクショナリー構造を返す必要があります。" - -#: ../../rst/dev_guide/developing_plugins.rst:506 -msgid "Since Ansible version 2.4, vars plugins only execute as needed when preparing to execute a task. This avoids the costly 'always execute' behavior that occurred during inventory construction in older versions of Ansible. Since Ansible version 2.10, vars plugin execution can be toggled by the user to run when preparing to execute a task or after importing an inventory source." -msgstr "Ansible バージョン 2.4 以降、タスク実行の準備時に必要に応じて vars プラグインのみを実行します。これにより、古いバージョンの Ansible のインベントリー構築中に発生した、費用のかかる「常に実行」動作が回避されます。Ansible バージョン 2.10 以降、vars プラグインの実行は、タスクの実行準備時またはインベントリーソースのインポート後に実行するようにユーザーが切り替えることができます。" - -#: ../../rst/dev_guide/developing_plugins.rst:508 -msgid "The user must explicitly enable vars plugins that reside in a collection. See :ref:`enable_vars` for details." -msgstr "ユーザーは、コレクションにある vars プラグインを明示的に有効にする必要があります。詳細は、:ref:`enable_vars` を参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:510 -msgid "Legacy vars plugins are always loaded and run by default. You can prevent them from automatically running by setting ``REQUIRES_ENABLED`` to True." -msgstr "レガシー vars プラグインは常に読み込まれ、実行されます。``REQUIRES_ENABLED`` を True に設定すると、自動的に実行しないようにできます。" - -#: ../../rst/dev_guide/developing_plugins.rst:517 -msgid "Include the ``vars_plugin_staging`` documentation fragment to allow users to determine when vars plugins run." -msgstr "``vars_plugin_staging`` ドキュメントフラグメントを追加して、ユーザーが when vars プラグインの実行を判別できるようにします。" - -#: ../../rst/dev_guide/developing_plugins.rst:537 -msgid "For example vars plugins, see the source code for the `vars plugins included with Ansible Core `_." -msgstr "vars プラグインの例は、`Ansible Core に含まれる vars プラグイン `_ のソースコードを参照してください。" - -#: ../../rst/dev_guide/developing_plugins.rst:547 -#: ../../rst/dev_guide/sidecar.rst:94 -msgid "Learn about how to develop dynamic inventory sources" -msgstr "動的インベントリーソースの開発方法について" - -#: ../../rst/dev_guide/developing_plugins.rst:554 -msgid ":ref:`adjacent_yaml_doc`" -msgstr ":ref:`adjacent_yaml_doc`" - -#: ../../rst/dev_guide/developing_plugins.rst:555 -msgid "Alternate YAML files as documentation" -msgstr "ドキュメントとしての代替 YAML ファイル" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:6 -msgid "Ansible module architecture" -msgstr "Ansible モジュールのアーキテクチャー" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:8 -msgid "If you are working on the ``ansible-core`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section." -msgstr "``ansible-core`` コードを使用している場合、Ansible モジュールの作成、またはアクションプラグインの開発では、Ansible のプログラムフローがどのように実行されるかを理解しないといけない場合があります。Playbook で Ansible モジュールを使用しているだけの場合は、このセクションをスキップできます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:16 -msgid "Types of modules" -msgstr "モジュールの種類" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:18 -msgid "Ansible supports several different types of modules in its code base. Some of these are for backwards compatibility and others are to enable flexibility." -msgstr "Ansible は、コードベースでいくつかの異なるタイプのモジュールをサポートしています。下位互換性のためのものもあり、柔軟性を可能にするものもあります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:26 -msgid "Action plugins look like modules to anyone writing a playbook. Usage documentation for most action plugins lives inside a module of the same name. Some action plugins do all the work, with the module providing only documentation. Some action plugins execute modules. The ``normal`` action plugin executes modules that don't have special action plugins. Action plugins always execute on the controller." -msgstr "action プラグインは、Playbook を作成する人にとってはモジュールのように見えます。ほとんどの action プラグインの使用方法に関するドキュメントは、同じ名前のモジュール内にあります。action プラグインの中には、すべての作業を行なうものもありますが、このモジュールはドキュメントのみを提供します。一部の action プラグインはモジュールを実行します。action プラグイン ``normal`` は、特別な action プラグインを持たないモジュールを実行します。action プラグインは常にコントローラーで実行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:28 -msgid "Some action plugins do all their work on the controller. For example, the :ref:`debug ` action plugin (which prints text for the user to see) and the :ref:`assert ` action plugin (which tests whether values in a playbook satisfy certain criteria) execute entirely on the controller." -msgstr "action プラグインによってコントローラーですべての作業が機能します。たとえば、action プラグイン :ref:`debug ` (ユーザーに表示できるようにテキストを出力する) および action プラグイン :ref:`assert ` (Playbook の値が特定の基準を満たすかどうかのテスト) など、コントローラー上で完全に実行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:33 -msgid "Most action plugins set up some values on the controller, then invoke an actual module on the managed node that does something with these values. For example, the :ref:`template ` action plugin takes values from the user to construct a file in a temporary location on the controller using variables from the playbook environment. It then transfers the temporary file to a temporary file on the remote system. After that, it invokes the :ref:`copy module ` which operates on the remote system to move the file into its final location, sets file permissions, and so on." -msgstr "ほとんどのアクションプラグインは、コントローラーにいくつかの値を設定した後、管理ノードで実際のモジュールを呼び出して、これらの値を使用して何かを行います。たとえば、action プラグイン :ref:`template ` は、ユーザーから値を受け取り、Playbook 環境からの変数を使用して、コントローラーの一時的な場所にファイルを作成します。その後、その一時ファイルを、リモートシステムの一時ファイルに転送します。その後、リモートシステム上で動作する :ref:`copy モジュール ` を起動して、ファイルを最終的な場所に移動させ、ファイルのパーミッションを設定するなどの作業を行います。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:44 -msgid "New-style modules" -msgstr "新スタイルのモジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:46 -msgid "All of the modules that ship with Ansible fall into this category. While you can write modules in any language, all official modules (shipped with Ansible) use either Python or PowerShell." -msgstr "Ansible に同梱されるモジュールはすべてこのカテゴリーに分類されます。モジュールは任意の言語で記述できますが、(Ansible に同梱されている) 正式なモジュールはすべて Python または PowerShell を使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:48 -msgid "New-style modules have the arguments to the module embedded inside of them in some manner. Old-style modules must copy a separate file over to the managed node, which is less efficient as it requires two over-the-wire connections instead of only one." -msgstr "新しいスタイルのモジュールには、なんらかの方法で実装されているモジュールに引数があります。古いスタイルのモジュールは、管理ノードに個別のファイルを管理ノードにコピーする必要があります。これは、1 つの接続ではなく、ネットワーク上の接続が 2 つ必要であるため、効率が悪くなります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:56 -msgid "Python" -msgstr "Python" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:58 -msgid "New-style Python modules use the :ref:`Ansiballz` framework for constructing modules. These modules use imports from :code:`ansible.module_utils` to pull in boilerplate module code, such as argument parsing, formatting of return values as :term:`JSON`, and various file operations." -msgstr "新しいスタイルの Python モジュールは、モジュールの構築に :ref:`Ansiballz` フレームワークを使用します。これらのモジュールは、:code:`ansible.module_utils` からインポートを使用し、引数の解析、:term:`JSON` などのさまざまなファイル操作の戻り値のフォーマットなど、boilerplate モジュールコードとして取得します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:63 -msgid "In Ansible, up to version 2.0.x, the official Python modules used the :ref:`module_replacer` framework. For module authors, :ref:`Ansiballz` is largely a superset of :ref:`module_replacer` functionality, so you usually do not need to understand the differences between them." -msgstr "バージョン 2.0.x までの Ansible では、公式の Python モジュールが :ref:`module_replacer`を使用していました。:ref:`Ansiballz` は、:ref:`module_replacer` 機能の上位セットであるため、通常はモジュール作成者がこれらの違いを理解する必要はありません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:71 -msgid "PowerShell" -msgstr "PowerShell" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:73 -msgid "New-style PowerShell modules use the :ref:`module_replacer` framework for constructing modules. These modules get a library of PowerShell code embedded in them before being sent to the managed node." -msgstr "新しいスタイルの PowerShell モジュールは、モジュールの構築に :ref:`module_replacer` を使用します。これらのモジュールは、管理ノードに送信される前にそれらに組み込まれている PowerShell コードのライブラリーを取得します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:80 -msgid "JSONARGS modules" -msgstr "JSONARGS モジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:82 -msgid "These modules are scripts that include the string ``<>`` in their body. This string is replaced with the JSON-formatted argument string. These modules typically set a variable to that value like this:" -msgstr "これらのモジュールは、本文に文字列 ``<>`` が含まれるスクリプトです。この文字列は JSON 形式の引数文字列に置き換えられます。これらのモジュールは、通常、変数を以下のような値に設定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:90 -msgid "Which is expanded as:" -msgstr "これは以下のように展開されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:96 -msgid "Ansible outputs a :term:`JSON` string with bare quotes. Double quotes are used to quote string values, double quotes inside of string values are backslash escaped, and single quotes may appear unescaped inside of a string value. To use JSONARGS, your scripting language must have a way to handle this type of string. The example uses Python's triple quoted strings to do this. Other scripting languages may have a similar quote character that won't be confused by any quotes in the JSON or it may allow you to define your own start-of-quote and end-of-quote characters. If the language doesn't give you any of these then you'll need to write a :ref:`non-native JSON module ` or :ref:`Old-style module ` instead." -msgstr "Ansible は、:term:`JSON` の文字列を引用符なしで出力します。文字列値の引用には二重引用符が使用され、文字列値の中の二重引用符はバックスラッシュでエスケープされ、文字列値の中の一重引用符はエスケープされずに表示されることがあります。JSONARGS を使用するには、スクリプト言語がこの種の文字列を処理する方法を備えている必要があります。この例では、Python の三重引用符文字列を使用しています。他のスクリプト言語では、JSON 内の引用符と混同されないような同様の引用符文字が用意されていたり、独自の引用開始文字や引用終了文字を定義できたりする場合があります。お使いの言語がこれを提供していない場合は、代わりに :ref:`非ネイティブ JSON モジュール ` または :ref:`古いスタイルのモジュール ` を記述する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:108 -msgid "These modules typically parse the contents of ``json_arguments`` using a JSON library and then use them as native variables throughout the code." -msgstr "これらのモジュールは通常、JSON ライブラリーを使用して ``json_arguments`` のコンテンツを解析し、次にコード全体でネイティブ変数として使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:114 -msgid "Non-native want JSON modules" -msgstr "ネイティブ以外の JSON モジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:116 -msgid "If a module has the string ``WANT_JSON`` in it anywhere, Ansible treats it as a non-native module that accepts a filename as its only command-line parameter. The filename is for a temporary file containing a :term:`JSON` string containing the module's parameters. The module needs to open the file, read and parse the parameters, operate on the data, and print its return data as a JSON encoded dictionary to stdout before exiting." -msgstr "モジュールに文字列 ``WANT_JSON`` があると、Ansible は、ファイル名をコマンドラインパラメーターとしてのみ許可する非ネイティブモジュールとして扱います。ファイル名は、モジュールのパラメーターを含む :term:`JSON` 文字列を含む一時的なファイル向けです。モジュールはファイルを開き、パラメーターを読み取りおよび解析し、データで操作し、終了する前にその戻り値を JSON エンコードディレクトリーとして stdout に出力する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:123 -msgid "These types of modules are self-contained entities. As of Ansible 2.1, Ansible only modifies them to change a shebang line if present." -msgstr "これらのモジュールタイプは自己完結型エンティティーです。Ansible 2.1 以降、Ansible では、存在する場合にのみ、シバン行を変更するようにそれらを変更します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:126 -msgid "Examples of Non-native modules written in ruby are in the `Ansible for Rubyists `_ repository." -msgstr "Ruby で書かれた非ネイティブモジュールの例は、`Ansible for Rubyists `_ リポジトリーにあります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:132 -msgid "Binary modules" -msgstr "バイナリーモジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:134 -msgid "From Ansible 2.2 onwards, modules may also be small binary programs. Ansible doesn't perform any magic to make these portable to different systems so they may be specific to the system on which they were compiled or require other binary runtime dependencies. Despite these drawbacks, you may have to compile a custom module against a specific binary library if that's the only way to get access to certain resources." -msgstr "Ansible 2.2 以降、モジュールは小規模のバイナリープログラムでもあります。Ansible は、これらを異なるシステムに移植できるようにする機能がないため、コンパイルされたシステムに固有のものであったり、他のバイナリーランタイムに依存したものが必要であったりします。このような欠点はありますが、特定のリソースにアクセスするための唯一の方法であれば、特定のバイナリーライブラリーに対するカスタムモジュールのコンパイルが必要になる場合があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:141 -msgid "Binary modules take their arguments and return data to Ansible in the same way as :ref:`want JSON modules `." -msgstr "バイナリモジュールは、引数を取り、:ref:`want JSON モジュール ` と同じ方法でデータを Ansible に返します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:144 -msgid "One example of a `binary module `_ written in go." -msgstr "Go で記述された ` バイナリーモジュール `_ の一例" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:151 -msgid "Old-style modules" -msgstr "古いスタイルのモジュール" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:153 -msgid "Old-style modules are similar to :ref:`want JSON modules `, except that the file that they take contains ``key=value`` pairs for their parameters instead of :term:`JSON`. Ansible decides that a module is old-style when it doesn't have any of the markers that would show that it is one of the other types." -msgstr "古いスタイルのモジュールは、:ref:`want JSON モジュール ` と似ていますが、使用するファイルが :term:`JSON` ではなく ``key=value`` のペアをパラメータに含んでいる点が異なります。Ansible は、モジュールに他のタイプの 1 つであることを示すマーカーがないと、そのモジュールが古いスタイルであると判断します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:162 -msgid "How modules are executed" -msgstr "モジュールの実行方法" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:164 -msgid "When a user uses :program:`ansible` or :program:`ansible-playbook`, they specify a task to execute. The task is usually the name of a module along with several parameters to be passed to the module. Ansible takes these values and processes them in various ways before they are finally executed on the remote machine." -msgstr ":program:`ansible` または :program:`ansible-playbook` を使用する場合は、実行するタスクを指定します。タスクは通常、モジュールに渡す複数のパラメーターを持つモジュールの名前です。Ansible はこれらの値を取得し、さまざまな方法で処理してから、最終的にリモートマシンで実行されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:173 -msgid "Executor/task_executor" -msgstr "Executor/task_executor" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:175 -msgid "The TaskExecutor receives the module name and parameters that were parsed from the :term:`playbook ` (or from the command-line in the case of :command:`/usr/bin/ansible`). It uses the name to decide whether it's looking at a module or an :ref:`Action Plugin `. If it's a module, it loads the :ref:`Normal Action Plugin ` and passes the name, variables, and other information about the task and play to that Action Plugin for further processing." -msgstr "TaskExecutor は、:term:`playbook ` (:command:`/usr/bin/ansible` の場合はコマンドライン) から解析されたモジュール名とパラメーターを受け取ります。これは、モジュールを見て、または :ref:`Action Plugin ` を見ているかを判断するために名前を使用します。モジュールの場合は、:ref:`Normal Action Plugin ` を読み込み、タスクとプレイに関する名前、変数、およびその他の情報をそのアクションプラグインに渡して、さらに処理します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:186 -msgid "The ``normal`` action plugin" -msgstr "action プラグイン ``normal``" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:188 -msgid "The ``normal`` action plugin executes the module on the remote host. It is the primary coordinator of much of the work to actually execute the module on the managed machine." -msgstr "action プラグイン ``normal`` は、リモートホストでモジュールを実行します。管理マシンでモジュールを実際に実行する多くの作業に対する主要な調整役です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:192 -msgid "It loads the appropriate connection plugin for the task, which then transfers or executes as needed to create a connection to that host." -msgstr "タスクに適切な connection プラグインを読み込み、そのホストへの接続を作成するために必要に応じて転送や実行を行います。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:194 -msgid "It adds any internal Ansible properties to the module's parameters (for instance, the ones that pass along ``no_log`` to the module)." -msgstr "モジュールのパラメーターに、Ansible の内部プロパティーを追加します (たとえば ``no_log`` をモジュールに渡すものなど)。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:196 -msgid "It works with other plugins (connection, shell, become, other action plugins) to create any temporary files on the remote machine and cleans up afterwards." -msgstr "これは、他のプラグイン (connection、shell、become、その他の action プラグイン) と連携して、リモートマシンに一時ファイルを作成し、後で削除します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:199 -msgid "It pushes the module and module parameters to the remote host, although the :ref:`module_common ` code described in the next section decides which format those will take." -msgstr "これに、モジュールおよびモジュールパラメーターがリモートホストにプッシュされますが、次のセクションで説明する :ref:`module_common ` コードが、どの形式を取るのか決定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:203 -msgid "It handles any special cases regarding modules (for instance, async execution, or complications around Windows modules that must have the same names as Python modules, so that internal calling of modules from other Action Plugins work.)" -msgstr "モジュールに関する特殊なケースを処理します (たとえば、非同期実行や、Python モジュールと同じ名前を持たなければならない Windows モジュールの複雑さなど。これにより、他の action プラグインからのモジュールの内部呼び出しが機能します)。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:206 -msgid "Much of this functionality comes from the `BaseAction` class, which lives in :file:`plugins/action/__init__.py`. It uses the ``Connection`` and ``Shell`` objects to do its work." -msgstr "この機能の多くは、`BaseAction` クラス (:file:`plugins/action/__init__.py` にある) から取得されます。これは、``Connection`` オブジェクトおよび ``Shell`` オブジェクトを使用して作業を行います。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:211 -msgid "When :term:`tasks ` are run with the ``async:`` parameter, Ansible uses the ``async`` Action Plugin instead of the ``normal`` Action Plugin to invoke it. That program flow is currently not documented. Read the source for information on how that works." -msgstr ":term:`タスク ` を ``async:`` パラメーターで実行している場合、Ansible は、action プラグイン ``normal`` の代わりに ``async`` を使用してそれを呼び出します。そのプログラムフローは現在文書化されていません。それがどのように機能するかについては、ソースをお読みください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:219 -msgid "Executor/module_common.py" -msgstr "Executor/module_common.py" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:221 -msgid "Code in :file:`executor/module_common.py` assembles the module to be shipped to the managed node. The module is first read in, then examined to determine its type:" -msgstr ":file:`executor/module_common.py` のコードは、管理ノードに同梱するモジュールをアセンブルします。まず、モジュールが最初に読み込まれ、その後はそのタイプを判断します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:225 -msgid ":ref:`PowerShell ` and :ref:`JSON-args modules ` are passed through :ref:`Module Replacer `." -msgstr ":ref:`PowerShell ` および :ref:`JSON-args モジュール ` は、:ref:`Module Replacer ` 経由で渡されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:226 -msgid "New-style :ref:`Python modules ` are assembled by :ref:`Ansiballz`." -msgstr "新しいスタイルの :ref:`Python モジュール ` は :ref:`Ansiballz` によりアセンブルされます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:227 -msgid ":ref:`Non-native-want-JSON `, :ref:`Binary modules `, and :ref:`Old-Style modules ` aren't touched by either of these and pass through unchanged." -msgstr ":ref:`Non-native-want-JSON `、:ref:`バイナリーモジュール `、および :ref:`古いスタイルのモジュール ` は、これらのどちらにも触れられず、変更されずにそのまま通過します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:229 -msgid "After the assembling step, one final modification is made to all modules that have a shebang line. Ansible checks whether the interpreter in the shebang line has a specific path configured via an ``ansible_$X_interpreter`` inventory variable. If it does, Ansible substitutes that path for the interpreter path given in the module. After this, Ansible returns the complete module data and the module type to the :ref:`Normal Action ` which continues execution of the module." -msgstr "アセンブル手順後、シバン行を持つすべてのモジュールに最終変更が行われます。Ansible は、シバン行内のインタープリターに ``ansible_$X_interpreter`` インベントリー変数を介して特定のパスが設定されているかどうかを確認します。パスがある場合、Ansible は、そのパスを、そのモジュールに指定されているインタープリターパスに置き換えます。その後、Ansible は完全なモジュールデータを返し、モジュールタイプを :ref:`normal action ` に返し、モジュールの実行を続行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:239 -msgid "Assembler frameworks" -msgstr "アセンブラーフレームワーク" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:241 -msgid "Ansible supports two assembler frameworks: Ansiballz and the older Module Replacer." -msgstr "Ansible は、2 つのアセンブラフレームワーク (Ansiballz と古い Module Replacer) をサポートしています。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:246 -msgid "Module Replacer framework" -msgstr "Module Replacer フレームワーク" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:248 -msgid "The Module Replacer framework is the original framework implementing new-style modules, and is still used for PowerShell modules. It is essentially a preprocessor (like the C Preprocessor for those familiar with that programming language). It does straight substitutions of specific substring patterns in the module file. There are two types of substitutions:" -msgstr "モジュール置換フレームワークは、新しいスタイルモジュールを実装し、引き続き PowerShell モジュール向けに使用されています。基本的には、(そのプログラミング言語に精通している C プロセッサーなど) です。モジュールファイル内の特定の従属文字列パターンを直接置換します。置換には 2 つのタイプがあります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:254 -msgid "Replacements that only happen in the module file. These are public replacement strings that modules can utilize to get helpful boilerplate or access to arguments." -msgstr "モジュールファイルでのみ実行する置換。モジュールは、便利な boilerplate や引数へのアクセスに使用できるパブリックの置換文字列です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:258 -msgid ":code:`from ansible.module_utils.MOD_LIB_NAME import *` is replaced with the contents of the :file:`ansible/module_utils/MOD_LIB_NAME.py` These should only be used with :ref:`new-style Python modules `." -msgstr ":code:`from ansible.module_utils.MOD_LIB_NAME import *` は、:file:`ansible/module_utils/MOD_LIB_NAME.py` の内容に置き換えます。これらは、:ref:`新しいスタイルの Python モジュール ` と併用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:261 -msgid ":code:`#<>` is equivalent to :code:`from ansible.module_utils.basic import *` and should also only apply to new-style Python modules." -msgstr ":code:`#<>` は、:code:`from ansible.module_utils.basic import *` と同等で、新しいスタイルの Python モジュールのみに適用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:264 -msgid ":code:`# POWERSHELL_COMMON` substitutes the contents of :file:`ansible/module_utils/powershell.ps1`. It should only be used with :ref:`new-style Powershell modules `." -msgstr ":code:`# POWERSHELL_COMMON` は、:file:`ansible/module_utils/powershell.ps1` の内容を置き換えます。これは、:ref:`新しいスタイルの Powershell モジュール ` と併用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:268 -msgid "Replacements that are used by ``ansible.module_utils`` code. These are internal replacement patterns. They may be used internally, in the above public replacements, but shouldn't be used directly by modules." -msgstr "``ansible.module_utils`` コードにより使用される代替品。これらは内部交換パターンです。これらは、上記のパブリック置換で内部的に使用できますが、モジュールで直接使用しないでください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:270 -msgid ":code:`\"<>\"` is substituted with the Ansible version. In :ref:`new-style Python modules ` under the :ref:`Ansiballz` framework the proper way is to instead instantiate an `AnsibleModule` and then access the version from :attr:``AnsibleModule.ansible_version``." -msgstr ":code:`\"<>\"` は、Ansible バージョンに置き換えられます。:ref:`Ansiballz` フレームワークの下の :ref:`新しいスタイルの Python モジュール ` で適切な方法は、代わりに `AnsibleModule` をインスタンス化し、:attr:``AnsibleModule.ansible_version`` からバージョンにアクセスすることです。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:275 -msgid ":code:`\"<>\"` is substituted with a string which is the Python ``repr`` of the :term:`JSON` encoded module parameters. Using ``repr`` on the JSON string makes it safe to embed in a Python file. In new-style Python modules under the Ansiballz framework this is better accessed by instantiating an `AnsibleModule` and then using :attr:`AnsibleModule.params`." -msgstr ":code:`\"<>\"` は、:term:`JSON` でエンコードされたモジュールパラメーターの Python ``repr`` の文字列に置き換えます。JSON 文字列で ``repr`` を使用すると、Python ファイルに安全に埋め込むことができます。Ansiballz フレームワークの新しいスタイル Python モジュールでは、`AnsibleModule` をインスタンス化してから :attr:`AnsibleModule.params` を使用することで、これはより適切にアクセスされます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:281 -msgid ":code:`<>` substitutes a string which is a comma-separated list of file systems which have a file system dependent security context in SELinux. In new-style Python modules, if you really need this you should instantiate an `AnsibleModule` and then use :attr:`AnsibleModule._selinux_special_fs`. The variable has also changed from a comma-separated string of file system names to an actual python list of file system names." -msgstr ":code:`<>` は、SELinux にファイルシステムに依存するセキュリティーコンテキストがあるファイルシステムのコンマ区切りの一覧である文字列を置き換えます。新しいスタイルの Python モジュールで `AnsibleModule` をインスタンス化してから、:attr:`AnsibleModule._selinux_special_fs` を使用してください。また、この変数は、ファイルシステム名のコンマ区切りの文字列から、ファイルシステム名の実際の python のリストに変更されています。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:288 -msgid ":code:`<>` substitutes the module parameters as a JSON string. Care must be taken to properly quote the string as JSON data may contain quotes. This pattern is not substituted in new-style Python modules as they can get the module parameters another way." -msgstr ":code:`<>` はモジュールパラメーターを JSON 文字列として置き換えます。JSON データには引用符が含まれている可能性があるため、文字列を適切に引用符で囲むように注意する必要があります。このパターンは、モジュールパラネーターを別の方法で取得できるため、新しいスタイルの Python モジュールでは置き換えられません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:293 -msgid "The string :code:`syslog.LOG_USER` is replaced wherever it occurs with the ``syslog_facility`` which was named in :file:`ansible.cfg` or any ``ansible_syslog_facility`` inventory variable that applies to this host. In new-style Python modules this has changed slightly. If you really need to access it, you should instantiate an `AnsibleModule` and then use :attr:`AnsibleModule._syslog_facility` to access it. It is no longer the actual syslog facility and is now the name of the syslog facility. See the :ref:`documentation on internal arguments ` for details." -msgstr "文字列 :code:`syslog.LOG_USER` は、:file:`ansible.cfg` またはこのホストに適用される ``ansible_syslog_facility`` インベントリー変数で囲まれている ``syslog_facility`` に置き換えられます。新しいスタイルの Python モジュールでは、これは若干変更になりました。本当にアクセスする必要がある場合は、`AnsibleModule` をインスタンス化し、その後 :attr:`AnsibleModule._syslog_facility` を使用してアクセスする必要があります。これは実際の syslog 機能ではなく、syslog 機能の名前になります。詳細は、「:ref:`内部引数のドキュメント `」を参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:306 -msgid "Ansiballz framework" -msgstr "Ansiballz フレームワーク" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:308 -msgid "The Ansiballz framework was adopted in Ansible 2.1 and is used for all new-style Python modules. Unlike the Module Replacer, Ansiballz uses real Python imports of things in :file:`ansible/module_utils` instead of merely preprocessing the module. It does this by constructing a zipfile -- which includes the module file, files in :file:`ansible/module_utils` that are imported by the module, and some boilerplate to pass in the module's parameters. The zipfile is then Base64 encoded and wrapped in a small Python script which decodes the Base64 encoding and places the zipfile into a temp directory on the managed node. It then extracts just the Ansible module script from the zip file and places that in the temporary directory as well. Then it sets the PYTHONPATH to find Python modules inside of the zip file and imports the Ansible module as the special name, ``__main__``. Importing it as ``__main__`` causes Python to think that it is executing a script rather than simply importing a module. This lets Ansible run both the wrapper script and the module code in a single copy of Python on the remote machine." -msgstr "Ansiblez フレームワークは Ansible 2.1 で採用され、すべての新しいスタイルの Python モジュールに使用されます。Module Replacer とは異なり、Ansiballz は、単にモジュールを前処理するだけではなく、:file:`ansible/module_utils` に含まれるものを実際に Python でインポートします。これを行うには、zipfile を構築します。これには、モジュールファイル、モジュールがインポートする :file:`ansible/module_utils` のファイル、およびモジュールのパラメーターを渡す boilerplate が含まれます。その後、zipfile は Base64 でエンコードされ、小さな Python スクリプトでラップされます。このスクリプトは Base64 エンコードをデコードし、zipfile を管理対象ノードの一時ディレクトリーに配置します。その後、zip ファイルから Ansible モジュールスクリプトのみを抽出し、一時ディレクトリーに配置します。その後、PYTHONPATH を設定して、zip ファイルから Python モジュールを検索し、Ansible モジュールを特殊な名前 ``__main__`` としてインポートします。``__main__`` としてインポートすると、Python は単にモジュールをインポートするのではなく、スクリプトを実行していると見なすようになります。これにより、Ansible は、ラッパースクリプトとモジュールコードの両方を、リモートマシンの Python の単一コピーで実行できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:322 -msgid "Ansible wraps the zipfile in the Python script for two reasons:" -msgstr "Ansible が Python スクリプトで zip ファイルをラップするには、以下の 2 つの理由があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:324 -msgid "for compatibility with Python 2.6 which has a less functional version of Python's ``-m`` command-line switch." -msgstr "Python の ``-m`` コマンドラインスイッチの機能が少ない Python 2.6 との互換性のため。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:327 -msgid "so that pipelining will function properly. Pipelining needs to pipe the Python module into the Python interpreter on the remote node. Python understands scripts on stdin but does not understand zip files." -msgstr "パイプ処理が適切に機能します。Pipelining は Python モジュールをリモートノード上の Python インタープリターにパイプする必要があります。Python は stdin のスクリプトを理解しますが、zip ファイルを理解しません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:331 -msgid "Prior to Ansible 2.7, the module was executed by a second Python interpreter instead of being executed inside of the same process. This change was made once Python-2.4 support was dropped to speed up module execution." -msgstr "Ansible 2.7 より前のバージョンでは、同じプロセス内で実行されるのではなく 2 つ目の Python インタープリター経由で実行されていました。この変更は、モジュールの実行を高速化するために、Python-2.4 のサポートが打ち切られた時点で行われました。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:335 -msgid "In Ansiballz, any imports of Python modules from the :py:mod:`ansible.module_utils` package trigger inclusion of that Python file into the zipfile. Instances of :code:`#<>` in the module are turned into :code:`from ansible.module_utils.basic import *` and :file:`ansible/module-utils/basic.py` is then included in the zipfile. Files that are included from :file:`module_utils` are themselves scanned for imports of other Python modules from :file:`module_utils` to be included in the zipfile as well." -msgstr "Ansiballzでは、:py:mod:`ansible.module_utils` パッケージからの Python モジュールのインポートにより、その Python ファイルが zip ファイルに追加されます。モジュール内の :code:`#<>` のインスタンスは :code:`from ansible.module_utils.basic import *` に変換され、その後 :file:`ansible/module-utils/basic.py` が zip ファイルに追加されます。:file:`module_utils` から追加されるファイルは、それ自体が :file:`module_utils` からの他の Python モジュールのインポートをスキャンし、同じように zip ファイルに追加します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:348 -msgid "Passing args" -msgstr "引数を渡す" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:350 -msgid "Arguments are passed differently by the two frameworks:" -msgstr "以下の 2 つのフレームワークでは、引数の渡し方が異なります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:352 -msgid "In :ref:`module_replacer`, module arguments are turned into a JSON-ified string and substituted into the combined module file." -msgstr ":ref:`module_replacer` では、モジュールの引数は JSON 化された文字列に変換され、結合されたモジュールファイルに置き換えられます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:353 -msgid "In :ref:`Ansiballz`, the JSON-ified string is part of the script which wraps the zipfile. Just before the wrapper script imports the Ansible module as ``__main__``, it monkey-patches the private, ``_ANSIBLE_ARGS`` variable in ``basic.py`` with the variable values. When a :class:`ansible.module_utils.basic.AnsibleModule` is instantiated, it parses this string and places the args into :attr:`AnsibleModule.params` where it can be accessed by the module's other code." -msgstr ":ref:`Ansiballz` では、JSON 化された文字列は、zip ファイルをラップするスクリプトの一部です。ラッパースクリプトが Ansible モジュールを ``__main__`` としてインポートする直前に、``basic.py`` のプライベート変数 ``_ANSIBLE_ARGS`` を変数値でモンキーパッチしています。:class:`ansible.module_utils.basic.AnsibleModule` がインスタンス化されると、この文字列を解析し、引数を :attr:`AnsibleModule.params` に配置し、モジュールの他のコードがアクセスできる場所に置きます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:356 -msgid "If you are writing modules, remember that the way we pass arguments is an internal implementation detail: it has changed in the past and will change again as soon as changes to the common module_utils code allow Ansible modules to forgo using :class:`ansible.module_utils.basic.AnsibleModule`. Do not rely on the internal global ``_ANSIBLE_ARGS`` variable." -msgstr "モジュールを作成している場合は、引数を渡す方法は内部実装の詳細であることに注意してください。これは過去に変更されており、共通のモジュールユーティリティーコードを変更すると、Ansible モジュールが :class:`ansible.module_utils.basic.AnsibleModule` の使用をやめるとすぐに再び変更されます。内部グローバル変数 ``_ANSIBLE_ARGS`` に依存しないでください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:359 -msgid "Very dynamic custom modules which need to parse arguments before they instantiate an ``AnsibleModule`` may use ``_load_params`` to retrieve those parameters. Although ``_load_params`` may change in breaking ways if necessary to support changes in the code, it is likely to be more stable than either the way we pass parameters or the internal global variable." -msgstr "``AnsibleModule`` をインスタンス化する前に引数を解析する必要のある非常に動的なカスタムモジュールは、``_load_params`` を使用してこれらのパラメーターを取得する場合があります。コードの変更をサポートする必要がある場合は、``_load_params`` が破壊的な方法で変更する可能性がありますが、パラメーターまたは内部グローバル変数を渡す方法よりも安定している可能性があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:365 -msgid "Prior to Ansible 2.7, the Ansible module was invoked in a second Python interpreter and the arguments were then passed to the script over the script's stdin." -msgstr "Ansible 2.7 より前のバージョンでは、Ansible モジュールは 2 番目の Python インタープリターで呼び出され、引数はスクリプトの標準入力 (stdin) を介してスクリプトに渡されていました。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:372 -msgid "Internal arguments" -msgstr "内部引数" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:374 -msgid "Both :ref:`module_replacer` and :ref:`Ansiballz` send additional arguments to the Ansible module beyond those which the user specified in the playbook. These additional arguments are internal parameters that help implement global Ansible features. Modules often do not need to know about these explicitly because the features are implemented in :py:mod:`ansible.module_utils.basic`. However, certain features need support from modules and some knowledge of the internal arguments is useful." -msgstr ":ref:`module_replacer` および :ref:`Ansiballz` の両方は、Playbook で指定したユーザー以外に追加の引数を Ansible モジュールに送信します。これらの追加の引数は、Ansible のグローバル機能の実装に役立つ内部パラメーターです。これらの機能は、:py:mod:`ansible.module_utils.basic` に実装されているため、モジュールが明示的に理解する必要がないことがしばしばあります。ただし、特定の機能はモジュールからのサポートが必要であり、内部引数に関する知識は有用です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:381 -msgid "The internal arguments in this section are global. If you need to add a local internal argument to a custom module, create an action plugin for that specific module. See ``_original_basename`` in the `copy action plugin `_ for an example." -msgstr "このセクションに記載されている内部引数はグローバルです。カスタムモジュールにローカルの内部引数を追加する必要がある場合は、その特定のモジュールに action プラグインを作成してください。その例として、`copy action plugin `_ の ``_original_basename`` を参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:385 -msgid "_ansible_no_log" -msgstr "_ansible_no_log" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:387 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:398 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:406 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:480 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:493 -msgid "Type: ``bool``" -msgstr "タイプ: ``bool``" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:389 -msgid "Set to ``True`` whenever an argument in a task or play specifies ``no_log``. Any module that calls the :py:meth:`AnsibleModule.log` function handles this action automatically. If you have a module that implements its own logging then you need to check the value of ``_ansible_no_log``. To access ``_ansible_no_log`` in a module, instantiate the ``AnsibleModule`` utility and then check the value of :attr:`AnsibleModule.no_log`." -msgstr "タスクまたはプレイの引数が ``no_log`` を指定した場合は ``True`` に設定します。:py:meth:`AnsibleModule.log` 関数を呼び出すモジュールは、このアクションを自動的に処理します。独自のロギングを実装するモジュールがある場合は、``_ansible_no_log`` の値を確認する必要があります。モジュール内の ``_ansible_no_log`` にアクセスするには、``AnsibleModule`` ユーティリティーをインスタンス化してから :attr:`AnsibleModule.no_log` の値を確認します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:392 -msgid "``no_log`` specified in a module's ``argument_spec`` is handled by a different mechanism." -msgstr "モジュールの ``argument_spec`` で指定された ``no_log`` は、別のメカニズムで処理されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:396 -msgid "_ansible_debug" -msgstr "_ansible_debug" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:400 -msgid "Operates verbose logging and logging of external commands that a module executes. If the module uses the :py:meth:`AnsibleModule.debug` function rather than the :py:meth:`AnsibleModule.log` function then the messages are only logged if you set the ``_ansible_debug`` argument to ``True``. To access ``_ansible_debug`` in a module, instantiate the ``AnsibleModule`` utility and access :attr:`AnsibleModule._debug`. For more details, see :ref:`DEFAULT_DEBUG`." -msgstr "詳細ロギングと、モジュールが実行する外部コマンドのロギングを操作します。モジュールが、:py:meth:`AnsibleModule.log` 関数ではなく :py:meth:`AnsibleModule.debug` 関数を使用する場合、``_ansible_debug`` 引数を ``True`` に設定しなければメッセージはログに記録されません。モジュールの ``_ansible_debug`` にアクセスするには、``AnsibleModule`` ユーティリティーをインスタンス化し、:attr:`AnsibleModule._debug` にアクセスします。詳細は :ref:`DEFAULT_DEBUG` を参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:404 -msgid "_ansible_diff" -msgstr "_ansible_diff" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:408 -msgid "With this parameter you can configure your module to show a unified diff of changes that will be applied to the templated files. To access ``_ansible_diff`` in a module, instantiate the ``AnsibleModule`` utility and access :attr:`AnsibleModule._diff`. You can also access this parameter using the ``diff`` keyword in your playbook, or the relevant environment variable. For more details, see :ref:`playbook_keywords` and the :ref:`DIFF_ALWAYS` configuration option." -msgstr "このパラメーターを使用すると、テンプレート化されたファイルに適用される変更の統合差分を表示するようにモジュールを設定できます。モジュールの ``_ansible_diff`` にアクセスするには、``AnsibleModule`` ユーティリティーをインスタンス化し、:attr:`AnsibleModule._diff` にアクセスします。このパラメーターには、Playbook の ``diff`` キーワードを使用するか、関連する環境変数を使用してもアクセスできます。詳細は、:ref:`playbook_keywords` および :ref:`DIFF_ALWAYS` 設定オプションを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:412 -msgid "_ansible_verbosity" -msgstr "_ansible_verbosity" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:414 -msgid "Type: ``int``" -msgstr "タイプ: ``int``" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:416 -msgid "You can use this argument to control the level (0 for none) of verbosity in logging." -msgstr "この引数を使用して、ロギングの詳細レベル (なしの場合は 0) を制御できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:420 -msgid "_ansible_selinux_special_fs" -msgstr "_ansible_selinux_special_fs" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:422 -msgid "Type: ``list`` Elements: ``strings``" -msgstr "タイプ: ``list`` 要素: ``strings``" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:425 -msgid "This argument provides modules with the names of file systems which should have a special SELinux context. They are used by the ``AnsibleModule`` methods which operate on files (changing attributes, moving, and copying)." -msgstr "この引数は、特別な SELinux コンテキストを持つ必要があるファイルシステムの名前をモジュールに提供します。それらは、ファイルで操作する ``AnsibleModule`` メソッド (属性の変更、移動、およびコピー) で使用されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:427 -msgid "Most modules can use the built-in ``AnsibleModule`` methods to manipulate files. To access in a module that needs to know about these special context file systems, instantiate ``AnsibleModule`` and examine the list in :attr:`AnsibleModule._selinux_special_fs`." -msgstr "ほとんどのモジュールは、ビルトイン ``AnsibleModule`` メソッドを使用してファイルを操作できます。これらの特別なコンテキストファイルシステムについて知る必要があるモジュールにアクセスするには、``AnsibleModule`` をインスタンス化し、:attr:`AnsibleModule._selinux_special_fs` でリストを調べます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:429 -msgid "This argument replaces :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` from :ref:`module_replacer`. In the module replacer framework the argument was formatted as a comma-separated string of file system names. Under the Ansiballz framework it is a list. You can access ``_ansible_selinux_special_fs`` using the corresponding environment variable. For more details, see the :ref:`DEFAULT_SELINUX_SPECIAL_FS` configuration option." -msgstr "この引数は、:ref:`module_replacer` から :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` を置き換えます。モジュール置換フレームワークでは、引数はファイルシステム名のコンマ区切り文字列としてフォーマットされていました。リストは Ansiballz フレームワークの下にあります。対応する環境変数を使用すると、``_ansible_selinux_special_fs`` にアクセスできます。詳細は、:ref:`DEFAULT_SELINUX_SPECIAL_FS` 設定オプションを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:435 -msgid "_ansible_syslog_facility" -msgstr "_ansible_syslog_facility" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:437 -msgid "This argument controls which syslog facility the module logs to. Most modules should just use the :meth:`AnsibleModule.log` function which will then make use of this. If a module has to use this on its own, it should instantiate the ``AnsibleModule`` method and then retrieve the name of the syslog facility from :attr:`AnsibleModule._syslog_facility`. The Ansiballz code is less elegant than the :ref:`module_replacer` code:" -msgstr "この引数は、どの syslog 機能にログを記録するかを制御します。ほとんどのモジュールは、これを使用する :meth:`AnsibleModule.log` 関数を使用する必要があります。モジュールがこれを独自に使用する必要がある場合は、``AnsibleModule`` メソッドをインスタンス化してから、:attr:`AnsibleModule._syslog_facility` から syslog ファシリティーの名前を取得します。Ansiballz コードは、:ref:`module_replacer`コードほど的確ではありません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:451 -msgid "For more details, see the :ref:`DEFAULT_SYSLOG_FACILITY` configuration option." -msgstr "詳細は、:ref:`DEFAULT_SYSLOG_FACILITY` 設定オプションを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:457 -msgid "_ansible_version" -msgstr "_ansible_version" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:459 -msgid "This argument passes the version of Ansible to the module. To access it, a module should instantiate the ``AnsibleModule`` method and then retrieve the version from :attr:`AnsibleModule.ansible_version`. This replaces :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from :ref:`module_replacer`." -msgstr "この因数は、Ansible のバージョンをモジュールに渡します。これにアクセスする場合、モジュールは ``AnsibleModule`` メソッドをインスタンス化してから、:attr:`AnsibleModule.ansible_version` でバージョンを取得する必要があります。これは:ref:`module_replacer` の :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` を置き換えます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:465 -msgid "_ansible_module_name" -msgstr "_ansible_module_name" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:467 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:501 -msgid "Type: ``str``" -msgstr "タイプ: ``str``" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:469 -msgid "This argument passes the information to modules about their name. For more details see, the configuration option :ref:`DEFAULT_MODULE_NAME`." -msgstr "この引数は、名前に関する情報をモジュールに渡します。詳細は、設定オプション :ref:`DEFAULT_MODULE_NAME` を参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:473 -msgid "_ansible_string_conversion_action" -msgstr "_ansible_string_conversion_action" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:474 -msgid "This argument provides instructions about what modules should do after the values of the user-specified module parameters are converted to strings. For more details, see the :ref:`STRING_CONVERSION_ACTION` configuration option." -msgstr "この引数は、ユーザーが指定したモジュールパラメーターの値が文字列に変換された後に、モジュールが何をすべきかについての指示を提供します。詳細は、:ref:`STRING_CONVERSION_ACTION` 設定オプションを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:478 -msgid "_ansible_keep_remote_files" -msgstr "_ansible_keep_remote_files" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:482 -msgid "This argument provides instructions that modules must be ready if they need to keep the remote files. For more details, see the :ref:`DEFAULT_KEEP_REMOTE_FILES` configuration option." -msgstr "この引数は、モジュールがリモートファイルを保持する必要がある場合に、モジュールを準備するための指示を提供します。詳細は :ref:`DEFAULT_KEEP_REMOTE_FILES` 設定オプションを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:486 -msgid "_ansible_socket" -msgstr "_ansible_socket" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:487 -msgid "This argument provides modules with a socket for persistent connections. The argument is created using the :ref:`PERSISTENT_CONTROL_PATH_DIR` configuration option." -msgstr "この因数は、永続的な接続のためのソケットをモジュールに提供します。この引数は、:ref:`PERSISTENT_CONTROL_PATH_DIR` 設定オプションを使用して作成されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:491 -msgid "_ansible_shell_executable" -msgstr "_ansible_shell_executable" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:495 -msgid "This argument ensures that modules use the designated shell executable. For more details, see the :ref:`ansible_shell_executable` remote host environment parameter." -msgstr "この引数は、モジュールが指定されたシェル実行可能ファイルを使用することを保証します。詳細は、:ref:`ansible_shell_executable` リモートホスト環境パラメーターを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:499 -msgid "_ansible_tmpdir" -msgstr "_ansible_tmpdir" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:503 -msgid "This argument provides instructions to modules that all commands must use the designated temporary directory, if created. The action plugin designs this temporary directory." -msgstr "この引数は、作成された場合にすべてのコマンドが指定された一時ディレクトリーを使用する必要があるモジュールへの指示を提供します。アクションプラグインは、この一時ディレクトリーを設計します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:505 -msgid "Modules can access this parameter by using the public ``tmpdir`` property. The ``tmpdir`` property will create a temporary directory if the action plugin did not set the parameter." -msgstr "モジュールは、パブリック ``tmpdir`` プロパティーを使用してこのパラメーターにアクセスできます。アクションプラグインがこのパラメーターを設定しなかった場合、``tmpdir`` プロパティーは一時ディレクトリーを作成します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:507 -msgid "The directory name is generated randomly, and the the root of the directory is determined by one of these:" -msgstr "ディレクトリー名はランダムに生成され、ディレクトリーのルートは次のいずれかによって決定されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:509 -msgid ":ref:`DEFAULT_LOCAL_TMP`" -msgstr ":ref:`DEFAULT_LOCAL_TMP`" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:510 -msgid "`remote_tmp `_" -msgstr "`remote_tmp `_" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:511 -msgid "`system_tmpdirs `_" -msgstr "`system_tmpdirs `_" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:513 -msgid "As a result, using the ``ansible.cfg`` configuration file to activate or customize this setting will not guarantee that you control the full value." -msgstr "そのため、``ansible.cfg`` 設定ファイルを使用してこの設定をアクティブ化またはカスタマイズしても、完全な値を制御できるとは限りません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:517 -msgid "_ansible_remote_tmp" -msgstr "_ansible_remote_tmp" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:519 -msgid "The module's ``tmpdir`` property creates a randomized directory name in this directory if the action plugin did not set ``_ansible_tmpdir``. For more details, see the `remote_tmp `_ parameter of the shell plugin." -msgstr "アクションプラグインが ``_ansible_tmpdir`` を設定しなかった場合、モジュールの ``tmpdir`` プロパティーは、このディレクトリー内でランダム化されたディレクトリー名を作成します。詳細は `remote_tmp `_ シェルプラグインのパラメーターを参照してください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:525 -msgid "Module return values & Unsafe strings" -msgstr "モジュール戻り値と安全でない文字列" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:527 -msgid "At the end of a module's execution, it formats the data that it wants to return as a JSON string and prints the string to its stdout. The normal action plugin receives the JSON string, parses it into a Python dictionary, and returns it to the executor." -msgstr "モジュールの実行の最後に、返したいデータを JSON 文字列として形式化し、その文字列を標準出力 (stdout) に出力します。通常の action プラグインは JSON 文字列を受け取り、Python ディクショナリーに解析してエクゼキューターに返します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:529 -msgid "If Ansible templated every string return value, it would be vulnerable to an attack from users with access to managed nodes. If an unscrupulous user disguised malicious code as Ansible return value strings, and if those strings were then templated on the controller, Ansible could execute arbitrary code. To prevent this scenario, Ansible marks all strings inside returned data as ``Unsafe``, emitting any Jinja2 templates in the strings verbatim, not expanded by Jinja2." -msgstr "Ansible がすべての文字列の戻り値をテンプレート化すると、管理ノードにアクセスできるユーザーからの攻撃に対して脆弱になります。悪意のあるユーザーが悪意のあるコードを Ansible の戻り値の文字列として偽装し、そのような文字列がコントローラー上でテンプレート化されると、Ansible が任意のコードを実行する可能性があります。このシナリオを防ぐために、Ansible は戻り値のデータ内のすべての文字列を ``Unsafe`` と表示し、文字列内の Jinja2 テンプレートを Jinja2 で展開せずにそのままエミットします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:531 -msgid "Strings returned by invoking a module through ``ActionPlugin._execute_module()`` are automatically marked as ``Unsafe`` by the normal action plugin. If another action plugin retrieves information from a module through some other means, it must mark its return data as ``Unsafe`` on its own." -msgstr "``ActionPlugin._execute_module()`` を介してモジュールを呼び出して返された文字列には、通常の action プラグインによって自動的に ``Unsafe`` というマークが付きます。別の action プラグインが他の方法でモジュールから情報を取得した場合は、その action プラグイン自身がその戻り値に ``Unsafe`` と表示する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:533 -msgid "In case a poorly-coded action plugin fails to mark its results as \"Unsafe,\" Ansible audits the results again when they are returned to the executor, marking all strings as ``Unsafe``. The normal action plugin protects itself and any other code that it calls with the result data as a parameter. The check inside the executor protects the output of all other action plugins, ensuring that subsequent tasks run by Ansible will not template anything from those results either." -msgstr "不適切にコーディングされた action プラグインが結果を「Unsafe」と表示しなかった場合、Ansible はエグゼキューターに返される際に結果を再度監査し、すべての文字列を ``Unsafe`` と表示します。通常の action プラグインは、自身と、結果データをパラメーターとして呼び出すその他のコードを保護します。エクゼキュータ内のチェックは、他のすべての action プラグインの出力を保護し、Ansible が実行する後続のタスクがこれらの結果から何かをテンプレート化することがないようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:539 -msgid "Special considerations" -msgstr "特別な考慮事項" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:544 -msgid "Pipelining" -msgstr "パイプライン" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:546 -msgid "Ansible can transfer a module to a remote machine in one of two ways:" -msgstr "Ansible は、以下のいずれかの方法で、モジュールをリモートマシンに転送できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:548 -msgid "it can write out the module to a temporary file on the remote host and then use a second connection to the remote host to execute it with the interpreter that the module needs" -msgstr "これは、リモートホストの一時ファイルにモジュールを書き込むことができ、次にリモートホストへの 2 番目の接続を使用して、モジュールが必要とするインタープリターでこれを実行します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:551 -msgid "or it can use what's known as pipelining to execute the module by piping it into the remote interpreter's stdin." -msgstr "または、パイプラインと呼ばれるものを使用して、モジュールをリモートインタープリターの stdin にパイプすることでモジュールを実行できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:554 -msgid "Pipelining only works with modules written in Python at this time because Ansible only knows that Python supports this mode of operation. Supporting pipelining means that whatever format the module payload takes before being sent over the wire must be executable by Python through stdin." -msgstr "パイプライン処理は、現時点では Python で記述されたモジュールでのみ機能します。これは、Python がこの操作モードをサポートしていることのみを Ansible が認識しているためです。パイプライン化をサポートするということは、モジュールペイロードがネットワーク経由で送信される前に取る形式が何であれ、Python が stdin を介して実行可能でなければならないことを意味します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:562 -msgid "Why pass args over stdin?" -msgstr "標準入力 (stdin) で引数を渡す理由" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:564 -msgid "Passing arguments through stdin was chosen for the following reasons:" -msgstr "以下の理由により、標準入力で引数を渡すことが選択されました。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:566 -msgid "When combined with :ref:`ANSIBLE_PIPELINING`, this keeps the module's arguments from temporarily being saved onto disk on the remote machine. This makes it harder (but not impossible) for a malicious user on the remote machine to steal any sensitive information that may be present in the arguments." -msgstr ":ref:`ANSIBLE_PIPELINING` と組み合わせると、モジュールの引数をリモートマシン上のディスクに一時的に保存したままにします。これにより、リモートマシン上の悪意のあるユーザーが引数に存在する可能性のある機密情報を盗むのが困難になります (不可能ではありません)。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:570 -msgid "Command line arguments would be insecure as most systems allow unprivileged users to read the full commandline of a process." -msgstr "ほとんどのシステムでは、権限のないユーザーがプロセスのコマンドライン全体を読むことを許可されているため、コマンドライン引数は安全ではありません。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:572 -msgid "Environment variables are usually more secure than the commandline but some systems limit the total size of the environment. This could lead to truncation of the parameters if we hit that limit." -msgstr "環境変数は通常コマンドラインより安全ですが、環境の合計サイズを制限するシステムもあります。これにより、パラメーターが上限に達すると、パラメーターが切り捨てられる可能性があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:580 -msgid "AnsibleModule" -msgstr "AnsibleModule" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:585 -msgid "Argument spec" -msgstr "引数の仕様" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:587 -msgid "The ``argument_spec`` provided to ``AnsibleModule`` defines the supported arguments for a module, as well as their type, defaults and more." -msgstr "``AnsibleModule`` に提供される ``argument_spec`` は、モジュールでサポートされる引数、その型、デフォルトなどを定義します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:589 -msgid "Example ``argument_spec``:" -msgstr "``argument_spec`` の例:" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:605 -msgid "This section will discuss the behavioral attributes for arguments:" -msgstr "本セクションでは、引数の動作属性を説明します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:609 -msgid "``type`` allows you to define the type of the value accepted for the argument. The default value for ``type`` is ``str``. Possible values are:" -msgstr "``type`` では、引数に受け入れられる値の型を定義できます。``type`` のデフォルト値は ``str`` です。可能な値は次のとおりです。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:611 -msgid "str" -msgstr "str" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:612 -msgid "list" -msgstr "list" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:613 -msgid "dict" -msgstr "dict" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:614 -msgid "bool" -msgstr "bool" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:615 -msgid "int" -msgstr "int" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:616 -msgid "float" -msgstr "float" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:617 -msgid "path" -msgstr "path" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:618 -msgid "raw" -msgstr "raw" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:619 -msgid "jsonarg" -msgstr "jsonarg" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:620 -#: ../../rst/dev_guide/style_guide/index.rst:152 -msgid "json" -msgstr "json" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:621 -msgid "bytes" -msgstr "bytes" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:622 -msgid "bits" -msgstr "bits" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:624 -msgid "The ``raw`` type, performs no type validation or type casting, and maintains the type of the passed value." -msgstr "``raw`` 型で、型の検証や型キャストを行わず、渡された値の型を保持します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:628 -msgid "``elements`` works in combination with ``type`` when ``type='list'``. ``elements`` can then be defined as ``elements='int'`` or any other type, indicating that each element of the specified list should be of that type." -msgstr "``elements`` は、``type='list'`` の時に ``type`` と組み合わせて動作します。``elements`` は ``elements='int'`` などの型で定義することができ、指定されたリストの各要素がその型であることを示します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:632 -msgid "The ``default`` option allows sets a default value for the argument for the scenario when the argument is not provided to the module. When not specified, the default value is ``None``." -msgstr "``default`` オプションは、引数がモジュールに提供されていない場合のシナリオの引数のデフォルト値を設定します。指定しない場合、デフォルト値は ``None`` です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "fallback" -msgstr "fallback" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:636 -msgid "``fallback`` accepts a ``tuple`` where the first argument is a callable (function) that will be used to perform the lookup, based on the second argument. The second argument is a list of values to be accepted by the callable." -msgstr "``fallback`` は、第 1 引数に、第 2 引数に基づいて検索を実行するのに使用する callable (関数) の ``tuple`` を受け入れます。2 つ目の引数は、callable オブジェクトによって受け入れられる値のリストです。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:638 -msgid "The most common callable used is ``env_fallback`` which will allow an argument to optionally use an environment variable when the argument is not supplied." -msgstr "最も一般的に使用されている callable は ``env_fallback`` で、これは引数が設定されていない場合に任意で環境変数を使用できるようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:640 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:679 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:693 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:793 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:810 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:824 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:851 -#: ../../rst/dev_guide/developing_program_flow_modules.rst:868 -#: ../../rst/dev_guide/testing.rst:206 -#: ../../rst/dev_guide/testing_units_modules.rst:90 -#: ../../rst/dev_guide/testing_units_modules.rst:109 -msgid "Example:" -msgstr "例:" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:648 -msgid "``choices`` accepts a list of choices that the argument will accept. The types of ``choices`` should match the ``type``." -msgstr "``choices`` は、引数が受け入れる選択肢のリストを受け入れます。``choices`` の型は、``type`` と一致している必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:652 -msgid "``required`` accepts a boolean, either ``True`` or ``False`` that indicates that the argument is required. When not specified, ``required`` defaults to ``False``. This should not be used in combination with ``default``." -msgstr "``required`` ブール値 (``True`` または ``False`` のいずれか) も受け入れます。これは、引数が必要であることを示しています。指定しない場合、``required`` のデフォルトは ``False`` になります。これは、``default`` と組み合わせて使用しないでください。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "no_log" -msgstr "no_log" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:656 -msgid "``no_log`` accepts a boolean, either ``True`` or ``False``, that indicates explicitly whether or not the argument value should be masked in logs and output." -msgstr "``no_log`` には、引数の値がログや出力でマスクされるべきかどうかを明示的に示すブール値 (``True`` または ``False``) を使用できます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:659 -msgid "In the absence of ``no_log``, if the parameter name appears to indicate that the argument value is a password or passphrase (such as \"admin_password\"), a warning will be shown and the value will be masked in logs but **not** output. To disable the warning and masking for parameters that do not contain sensitive information, set ``no_log`` to ``False``." -msgstr "``no_log`` がない場合は、パラメーター名が、引数の値がパスワードやパスフレーズであることを示しているように見える場合 (「admin_password」など)、警告が表示され、値はログでマスクされますが、**出力されません**。機密情報を含まないパラメーターの警告とマスキングを無効にするには、``no_log`` を ``False`` に設定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:663 -msgid "``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name``" -msgstr "``aliases`` では、引数の代替引数名のリストが使用できます。たとえば、引数は ``name`` ですが、モジュールが ``aliases=['pkg']`` を受け付けて、``pkg`` を ``name`` と互換性を持たせるようにしています。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:667 -msgid "``options`` implements the ability to create a sub-argument_spec, where the sub options of the top level argument are also validated using the attributes discussed in this section. The example at the top of this section demonstrates use of ``options``. ``type`` or ``elements`` should be ``dict`` is this case." -msgstr "``options`` は、上位レベルの引数のサブオプションもこのセクションで説明した属性を使用して検証される sub-argument_spec を作成する機能を実装しています。このセクションの冒頭にある例は、``options`` の使用を示しています。ここでは、``type`` または ``elements`` は ``dict`` である必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "apply_defaults" -msgstr "apply_defaults" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:671 -msgid "``apply_defaults`` works alongside ``options`` and allows the ``default`` of the sub-options to be applied even when the top-level argument is not supplied." -msgstr "``apply_defaults`` は、``options`` と並んで動作し、上位レベルの引数が指定されていない場合でもサブオプションの ``デフォルト`` を適用できるようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:673 -msgid "In the example of the ``argument_spec`` at the top of this section, it would allow ``module.params['top_level']['second_level']`` to be defined, even if the user does not provide ``top_level`` when calling the module." -msgstr "このセクションの冒頭にある ``argument_spec`` の例では、ユーザーがモジュールを呼び出すときに ``top_level`` を指定しなかった場合でも、``module.params['top_level']['second_level']`` を定義できるようにします。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "removed_in_version" -msgstr "removed_in_version" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:677 -msgid "``removed_in_version`` indicates which version of ansible-core or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``." -msgstr "``removed_in_version`` は、非推奨の引数が削除される ansible-core またはコレクションのバージョンを示します。``removed_at_date`` で相互に排他となり、``removed_from_collection`` で使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "removed_at_date" -msgstr "removed_at_date" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:691 -msgid "``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-core release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``." -msgstr "``removed_at_date`` は、非推奨の引数が、この日付以降のマイナーな ansible-core リリースまたはメジャーコレクションリリースで削除されることを示します。``removed_in_version`` と相互に排他的であり、``removed_from_collection`` と一緒に使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "removed_from_collection" -msgstr "removed_from_collection" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:705 -msgid "Specifies which collection (or ansible-core) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``." -msgstr "この非推奨の引数を非推奨にするコレクション (または ansible-core) を指定します。ansible-core には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``removed_in_version`` または ``removed_at_date`` と共に使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "deprecated_aliases" -msgstr "deprecated_aliases" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:709 -msgid "Deprecates aliases of this argument. Must contain a list or tuple of dictionaries having some the following keys:" -msgstr "この引数のエイリアスを非推奨にします。以下のキーを持つディクショナリーのリストまたはタプルが含まれます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "name" -msgstr "名前" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:713 -msgid "The name of the alias to deprecate. (Required.)" -msgstr "非推奨にするエイリアスの名前 (必須)" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst -msgid "version" -msgstr "version" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:717 -msgid "The version of ansible-core or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified." -msgstr "ansible-core、またはこのエイリアスは削除されるコレクションのバージョン。``version`` または ``date`` のいずれかを指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "date" -msgstr "date" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:721 -msgid "The a date after which a minor release of ansible-core or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified." -msgstr "ansible-core のマイナーリリースまたはメジャーコレクションリリースにこのエイリアスが含まれなくなった日付。``version`` または ``date`` のいずれかを指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "collection_name" -msgstr "collection_name" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:725 -msgid "Specifies which collection (or ansible-core) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``." -msgstr "この非推奨のエイリアスを非推奨にするコレクション (または ansible-core) を指定します。ansible-core には ``ansible.builtin``、またはコレクションの名前 (``foo.bar`` の形式) を指定します。``version`` または ``date`` と共に使用する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:727 -msgid "Examples:" -msgstr "例:" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "mutually_exclusive" -msgstr "mutually_exclusive" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:751 -msgid "If ``options`` is specified, ``mutually_exclusive`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``mutually_exclusive`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_together" -msgstr "required_together" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:755 -msgid "If ``options`` is specified, ``required_together`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_together`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_one_of" -msgstr "required_one_of" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:759 -msgid "If ``options`` is specified, ``required_one_of`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_one_of`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_if" -msgstr "required_if" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:763 -msgid "If ``options`` is specified, ``required_if`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_if`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst -msgid "required_by" -msgstr "required_by" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:767 -msgid "If ``options`` is specified, ``required_by`` refers to the sub-options described in ``options`` and behaves as in :ref:`argument_spec_dependencies`." -msgstr "``options`` を指定すると、``required_by`` は ``options`` で説明されているサブオプションを参照し、:ref:`argument_spec_dependencies` のように動作します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:773 -msgid "Dependencies between module options" -msgstr "モジュールオプションの依存関係" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:775 -msgid "The following are optional arguments for ``AnsibleModule()``:" -msgstr "以下は、``AnsibleModule()`` の任意の引数です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:791 -msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are mutually exclusive. If more than one options of a list are specified together, Ansible will fail the module with an error." -msgstr "文字列シーケンスのシーケンス (リストまたはタプル) です。文字列のシーケンスは相互排他的なオプション名のリストです。リストの複数のオプションを指定すると、Ansible はエラーを出してモジュールに失敗します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:802 -msgid "In this example, the options ``path`` and ``content`` must not specified at the same time. Also the options ``repository_url`` and ``repository_filename`` must not be specified at the same time. But specifying ``path`` and ``repository_url`` is accepted." -msgstr "この例では、``path`` オプションと ``content`` オプションは同時に指定しないでください。``repository_url`` オプションと ``repository_filename`` オプションを同時に指定することはできません。ただし、``path`` および ``repository_url`` を指定することはできます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:804 -msgid "To ensure that precisely one of two (or more) options is specified, combine ``mutually_exclusive`` with ``required_one_of``." -msgstr "正確に 2 つのオプション (または複数の) オプションのいずれかを指定するようにするには、``mutually_exclusive`` と ``required_one_of`` を組み合わせます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:808 -msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names which are must be specified together. If at least one of these options are specified, the other ones from the same sequence must all be present." -msgstr "文字列のシーケンスのシーケンス (リストまたはタプル) である必要があります。文字列のすべてのシーケンスは、一緒に指定する必要があるオプション名のリストです。これらのオプションが少なくとも 1 つ指定されている場合は、同じシーケンスの他のオプションがすべて存在している必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:818 -msgid "In this example, if one of the options ``file_path`` or ``file_hash`` is specified, Ansible will fail the module with an error if the other one is not specified." -msgstr "この例では、``file_path`` または ``file_hash`` のいずれかのオプションを指定し、他のオプションが指定していないと、Ansible はエラーを出してモジュールに失敗します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:822 -msgid "Must be a sequence (list or tuple) of sequences of strings. Every sequence of strings is a list of option names from which at least one must be specified. If none one of these options are specified, Ansible will fail module execution." -msgstr "文字列のシーケンスのシーケンス (リストまたはタプル) である必要があります。文字列のすべてのシーケンスは、少なくとも 1 つを指定する必要があるオプション名のリストです。これらのオプションがいずれも指定されていない場合、Ansible はモジュールの実行に失敗します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:832 -msgid "In this example, at least one of ``path`` and ``content`` must be specified. If none are specified, execution will fail. Specifying both is explicitly allowed; to prevent this, combine ``required_one_of`` with ``mutually_exclusive``." -msgstr "この例では、``path`` および ``content`` のいずれかを指定する必要があります。指定しないと、実行が失敗します。両方の値を指定すると、明示的に許可されます。これを回避するには、``required_one_of`` と ``mutually_exclusive`` を組み合わせます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:836 -msgid "Must be a sequence of sequences. Every inner sequence describes one conditional dependency. Every sequence must have three or four values. The first two values are the option's name and the option's value which describes the condition. The further elements of the sequence are only needed if the option of that name has precisely this value." -msgstr "一連のシーケンスのシーケンスである必要があります。すべての内部シーケンスでは、条件の依存関係を 1 つ説明します。すべてのシーケンスには、値が 3 つまたは 4 つ必要です。最初の 2 つの値は、オプション名と、その条件を説明するオプションの値です。シーケンスの追加要素は、その名前のオプションが正確にこの値を持っている場合にのみ必要です。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:838 -msgid "If you want that all options in a list of option names are specified if the condition is met, use one of the following forms:" -msgstr "条件が満たされた場合にオプション名のリスト内のオプションをすべて指定する場合は、次のいずれかの形式を使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:845 -msgid "If you want that at least one option of a list of option names is specified if the condition is met, use the following form:" -msgstr "条件が満たされた場合にオプション名の一覧のオプションを 1 つ以上指定する場合は、以下の形式を使用します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:860 -msgid "In this example, if the user specifies ``state=present``, at least one of the options ``path`` and ``content`` must be supplied (or both). To make sure that precisely one can be specified, combine ``required_if`` with ``mutually_exclusive``." -msgstr "この例では、ユーザーが ``state=present`` を指定している場合は、``path`` と ``content`` のいずれか (または両方) のオプションを指定する必要があります。必ず指定するようにするには、``required_if`` と ``mutually_exclusive`` を組み合わせます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:862 -msgid "On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` and so on, both ``force_reason`` and ``force_code`` must be specified." -msgstr "一方、``force`` (ブール値パラメーター) が ``true``、``yes`` などに設定されている場合は、``force_reason`` と ``force_code`` の両方を指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:866 -msgid "Must be a dictionary mapping option names to sequences of option names. If the option name in a dictionary key is specified, the option names it maps to must all also be specified. Note that instead of a sequence of option names, you can also specify one single option name." -msgstr "オプション名のシーケンスへのディクショナリーマッピングオプション名である必要があります。ディクショナリーキーでオプション名を指定すると、そのオプション名をすべて指定する必要があります。オプション名のシーケンスの代わりに、オプションの名前を 1 つ指定することもできます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:877 -msgid "In the example, if ``force`` is specified, ``force_reason`` must also be specified. Also, if ``path`` is specified, then three three options ``mode``, ``owner`` and ``group`` also must be specified." -msgstr "この例では、``force`` が指定されている場合は、``force_reason`` も指定する必要があります。また、``path`` が指定されている場合は、3 つのオプション ``mode``、``owner``、および ``group`` も指定する必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:880 -msgid "Declaring check mode support" -msgstr "チェックモードのサポートの宣言" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:882 -msgid "To declare that a module supports check mode, supply ``supports_check_mode=True`` to the ``AnsibleModule()`` call:" -msgstr "モジュールが確認モードをサポートすることを宣言するには、``AnsibleModule()`` 呼び出しに ``supports_check_mode=True`` を指定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:888 -msgid "The module can determine whether it is called in check mode by checking the boolean value ``module.check_mode``. If it evaluates to ``True``, the module must take care not to do any modification." -msgstr "モジュールは、ブール値 ``module.check_mode`` を確認することで、チェックモードで呼び出されるかどうかを判断できます。``True`` に評価する場合、モジュールは変更を行わないようにする必要があります。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:890 -msgid "If ``supports_check_mode=False`` is specified, which is the default value, the module will exit in check mode with ``skipped=True`` and message ``remote module () does not support check mode``." -msgstr "``supports_check_mode=False`` が指定されている場合 (デフォルト値)、モジュールはチェックモードで ``skipped=True`` および ``remote module () does not support check mode`` メッセージで終了します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:893 -msgid "Adding file options" -msgstr "ファイルオプションの追加" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:895 -msgid "To declare that a module should add support for all common file options, supply ``add_file_common_args=True`` to the ``AnsibleModule()`` call:" -msgstr "モジュールがすべての共通ファイルオプションのサポートを追加することを宣言するには、``add_file_common_args=True`` を ``AnsibleModule()`` 呼び出しに指定します。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:901 -msgid "You can find `a list of all file options here `_. It is recommended that you make your ``DOCUMENTATION`` extend the doc fragment ``ansible.builtin.files`` (see :ref:`module_docs_fragments`) in this case, to make sure that all these fields are correctly documented." -msgstr "`ここで、ファイルオプションの一覧 `_ を確認できます。今回は、``DOCUMENTATION`` がドキュメントフラグメント ``ansible.builtin.files`` (:ref:`module_docs_fragments` を参照) を拡張し、これらのフィールドがすべて正しく文書化されていることを確認することが推奨されます。" - -#: ../../rst/dev_guide/developing_program_flow_modules.rst:903 -msgid "The helper functions ``module.load_file_common_arguments()`` and ``module.set_fs_attributes_if_different()`` can be used to handle these arguments for you:" -msgstr "ヘルパー関数 ``module.load_file_common_arguments()`` および ``module.set_fs_attributes_if_different()`` を使用して、以下の引数を扱うことができます。" - -#: ../../rst/dev_guide/developing_python_3.rst:5 -msgid "Ansible and Python 3" -msgstr "Ansible および Python 3" - -#: ../../rst/dev_guide/developing_python_3.rst:7 -msgid "The ``ansible-core`` code runs Python 3 (for specific versions check :ref:`Control Node Requirements ` Contributors to ``ansible-core`` and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible." -msgstr "``ansible-core`` コードは Python3 を実行します (特定のバージョンについては:ref:`Control Node Requirements ` を確認してください)。``ansible-core`` および Ansible コレクションへのコントリビューターは、残りの Ansible と同じバージョンの Python で実行されるコードを記述できるように、このドキュメントに記載されているヒントを把握しておく必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:14 -msgid "We do have some considerations depending on the types of Ansible code:" -msgstr "Ansible コードのタイプによっては、いくつかの考慮事項があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:16 -msgid "controller-side code - code that runs on the machine where you invoke :command:`/usr/bin/ansible`, only needs to support the controller's Python versions." -msgstr "コントローラー側のコード - :command:`/usr/bin/ansible` を呼び出すマシンで実行されるコード。コントローラーの Python バージョンのみをサポートする必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:17 -msgid "modules - the code which Ansible transmits to and invokes on the managed machine. Modules need to support the 'managed node' Python versions, with some exceptions." -msgstr "モジュール - Ansible が管理対象マシンに送信して呼び出すコード。一部の例外を除き、モジュールは「管理対象ノード」の Python バージョンをサポートする必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:18 -msgid "shared ``module_utils`` code - the common code that is used by modules to perform tasks and sometimes used by controller-side code as well. Shared ``module_utils`` code needs to support the same range of Python as the modules." -msgstr "共有されている ``module_utils`` コード - タスクを実行するためにモジュールが使用する一般的なコードで、コントローラー側のコードで使用されることもあります。共有されている ``module_utils`` コードは、モジュールと同じ範囲の Python をサポートする必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:20 -msgid "However, the three types of code do not use the same string strategy. If you're developing a module or some ``module_utils`` code, be sure to read the section on string strategy carefully." -msgstr "ただし、この 3 種類のコードで同じ文字列ストラテジーが使用されているわけではありません。モジュールまたはいくつかの ``module_utils`` コードを開発している場合は、文字列ストラテジーのセクションを注意してお読みください。" - -#: ../../rst/dev_guide/developing_python_3.rst:26 -msgid "Minimum version of Python 3.x and Python 2.x" -msgstr "Python 3.x および Python 2.x の最小バージョン" - -#: ../../rst/dev_guide/developing_python_3.rst:28 -msgid "See :ref:`Control Node Requirements ` and :ref:`Managed Node Requirements ` for the specific versions supported." -msgstr "サポート対象のバージョンは、:ref:`Control Node Requirements ` および :ref:`Managed Node Requirements ` を参照してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:31 -msgid "Your custom modules can support any version of Python (or other languages) you want, but the above are the requirements for the code contributed to the Ansible project." -msgstr "カスタムモジュールは、任意のバージョンの Python (またはその他の言語) をサポートできますが、上記は Ansible プロジェクトに提供されるコードの要件です。" - -#: ../../rst/dev_guide/developing_python_3.rst:34 -msgid "Developing Ansible code that supports Python 2 and Python 3" -msgstr "Python 2 および Python 3 をサポートする Ansible コードの開発" - -#: ../../rst/dev_guide/developing_python_3.rst:36 -msgid "The best place to start learning about writing code that supports both Python 2 and Python 3 is `Lennart Regebro's book: Porting to Python 3 `_. The book describes several strategies for porting to Python 3. The one we're using is `to support Python 2 and Python 3 from a single code base `_" -msgstr "Python 2 と Python 3 の両方をサポートするコードの記述について学び始めるのに最適なのは、`Lennart Regebro の著書: Porting to Python 3 `_ です。本書では、Python 3 に移植するためのいくつかのストラテジーが説明されています。Ansible で使用しているのは、`単一のコードベースから Python 2 および Python 3 をサポートするため `_ です。" - -#: ../../rst/dev_guide/developing_python_3.rst:43 -msgid "Understanding strings in Python 2 and Python 3" -msgstr "Python 2 および Python 3 の文字列を理解" - -#: ../../rst/dev_guide/developing_python_3.rst:45 -msgid "Python 2 and Python 3 handle strings differently, so when you write code that supports Python 3 you must decide what string model to use. Strings can be an array of bytes (like in C) or they can be an array of text. Text is what we think of as letters, digits, numbers, other printable symbols, and a small number of unprintable \"symbols\" (control codes)." -msgstr "Python 2 と Python 3 では文字列の扱いが異なるため、Python 3 をサポートするコードを作成するときは、どのような文字列モデルを使用するかを決める必要があります。文字列は (C 言語のように) バイトの配列にすることもできますし、テキストの配列にすることもできます。ここでの「テキスト」とは、文字、数字 (digit または number)、その他の印刷可能な記号、および少数の印刷不可能な「記号」(制御コード) になります。" - -#: ../../rst/dev_guide/developing_python_3.rst:51 -msgid "In Python 2, the two types for these (:class:`str ` for bytes and :func:`unicode ` for text) are often used interchangeably. When dealing only with ASCII characters, the strings can be combined, compared, and converted from one type to another automatically. When non-ASCII characters are introduced, Python 2 starts throwing exceptions due to not knowing what encoding the non-ASCII characters should be in." -msgstr "Python 2 では、これらの 2 つのタイプ (バイト単位の場合は :class:`str `、テキストの場合は :func:`unicode `) が、しばしば同じ意味で使用されます。ASCII 文字のみを処理する場合は、文字列を組み合わせて比較し、あるタイプから別のタイプに自動的に変換できます。非 ASCII 文字が導入されると、Python 2 は、非 ASCII 文字がどのエンコーディングに含まれるべきかわからないために例外を出力し始めます。" - -#: ../../rst/dev_guide/developing_python_3.rst:58 -msgid "Python 3 changes this behavior by making the separation between bytes (:class:`bytes `) and text (:class:`str `) more strict. Python 3 will throw an exception when trying to combine and compare the two types. The programmer has to explicitly convert from one type to the other to mix values from each." -msgstr "Python 3 は、バイト (:class:`bytes `) とテキスト (:class:`str `) を分離することでこの動作を変更します。Python 3 は 2 つのタイプの結合と比較を試みる際に例外を出力させます。プログラマーは、ある型から別の型に変換し、混在させる必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:63 -msgid "In Python 3 it's immediately apparent to the programmer when code is mixing the byte and text types inappropriately, whereas in Python 2, code that mixes those types may work until a user causes an exception by entering non-ASCII input. Python 3 forces programmers to proactively define a strategy for working with strings in their program so that they don't mix text and byte strings unintentionally." -msgstr "Python 3 では、プログラマーは、コードがバイト型とテキスト型を不適切に混合していることがすぐに分かりますが、Python 2 では、ユーザーが非 ASCII 入力を入力して例外が発生するまでは、これらの型を混合しているコードが動作するかもしれません。Python 3 では、プログラマーが意図せずにテキスト文字列とバイト文字列を混在させないように、プログラムの中で文字列を扱うためのストラテジーを積極的に定義することを強制しています。" - -#: ../../rst/dev_guide/developing_python_3.rst:69 -msgid "Ansible uses different strategies for working with strings in controller-side code, in :ref: `modules `, and in :ref:`module_utils ` code." -msgstr "Ansible は、:ref:`modules ` コードおよび :ref:`module_utils ` コードのコントローラー側のコードで文字列を操作するためにさまざまなストラテジーを使用します。" - -#: ../../rst/dev_guide/developing_python_3.rst:75 -msgid "Controller string strategy: the Unicode Sandwich" -msgstr "コントローラー文字列ストラテジー: Unicode Sandwich" - -#: ../../rst/dev_guide/developing_python_3.rst:77 -msgid "Until recently ``ansible-core`` supported Python 2.x and followed this strategy, known as the Unicode Sandwich (named after Python 2's :func:`unicode ` text type). For Unicode Sandwich we know that at the border of our code and the outside world (for example, file and network IO, environment variables, and some library calls) we are going to receive bytes. We need to transform these bytes into text and use that throughout the internal portions of our code. When we have to send those strings back out to the outside world we first convert the text back into bytes. To visualize this, imagine a 'sandwich' consisting of a top and bottom layer of bytes, a layer of conversion between, and all text type in the center." -msgstr "最近まで、``ansible-core`` は Python 2.x をサポートし、Unicode Sandwich (Python 2 の :func:`unicode ` テキストタイプに由来する名前) と呼ばれるストラテジーを使用していました。Unicode Sandwich の場合は、コードと外部の境界 (ファイルやネットワークの IO、環境変数、ライブラリーの呼び出しなど) でバイトを受信することがわかります。これらのバイトをテキストに変換し、コードの内部全体でこれを使用する必要があります。これらの文字列を外部に返す必要がある場合は、最初にテキストをバイトに変換します。これは、上下にバイトの層、その間に変換の層、その中央にあるすべてのテキストタイプからなる「サンドイッチ」を想像してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:87 -msgid "For compatibility reasons you will see a bunch of custom functions we developed (``to_text``/``to_bytes``/``to_native``) and while Python 2 is not a concern anymore we will continue to use them as they apply for other cases that make dealing with unicode problematic." -msgstr "互換性の理由から、多くのカスタム関数(``to_text``/``to_bytes``/``to_native``) が開発されました。Python 2 に関する懸念はなくなったため、Unicode の処理が問題になるような別のケースに適用されるため、今後も引き続きこれを使用します。" - -#: ../../rst/dev_guide/developing_python_3.rst:91 -msgid "While we will not be using it most of it anymore, the documentation below is still useful for those developing modules that still need to support both Python 2 and 3 simultaneously." -msgstr "ほとんど使用しなくなりますが、以下のドキュメントは Python 2 と 3 の両方を同時にサポートする必要があるモジュールを開発している場合に役立ちます。" - -#: ../../rst/dev_guide/developing_python_3.rst:95 -msgid "Unicode Sandwich common borders: places to convert bytes to text in controller code" -msgstr "Unicode Sandwich の共通の境界: コントローラーコードのテキストにバイトを変換する場所" - -#: ../../rst/dev_guide/developing_python_3.rst:97 -msgid "This is a partial list of places where we have to convert to and from bytes when using the Unicode Sandwich string strategy. It's not exhaustive but it gives you an idea of where to watch for problems." -msgstr "これは、Unicode Sandwich 文字列ストラテジーの使用時に、バイトへ、またはバイトから変換する場所の部分的なリストです。網羅的ではありませんが、問題を監視する場所がわかります。" - -#: ../../rst/dev_guide/developing_python_3.rst:102 -msgid "Reading and writing to files" -msgstr "ファイルの読み取りおよび書き込み" - -#: ../../rst/dev_guide/developing_python_3.rst:104 -msgid "In Python 2, reading from files yields bytes. In Python 3, it can yield text. To make code that's portable to both we don't make use of Python 3's ability to yield text but instead do the conversion explicitly ourselves. For example:" -msgstr "Python 2 では、ファイルから読み取るとバイトが生成されます。Python 3 では、テキストを生成できます。両方に移植可能なコードを作成するために、Python 3 のテキスト生成機能を利用せず、代わりに自身で明示的に変換を行います。以下に例を示します。" - -#: ../../rst/dev_guide/developing_python_3.rst:122 -msgid "Much of Ansible assumes that all encoded text is UTF-8. At some point, if there is demand for other encodings we may change that, but for now it is safe to assume that bytes are UTF-8." -msgstr "Ansible の多くは、エンコードされたテキストがすべて UTF-8 であることを前提としています。将来変更することがあるかもしれませんが、現時点では、バイトが UTF-8 であると考えて問題ありません。" - -#: ../../rst/dev_guide/developing_python_3.rst:126 -msgid "Writing to files is the opposite process:" -msgstr "ファイルへの書き込みは、その逆の処理です。" - -#: ../../rst/dev_guide/developing_python_3.rst:135 -msgid "Note that we don't have to catch :exc:`UnicodeError` here because we're transforming to UTF-8 and all text strings in Python can be transformed back to UTF-8." -msgstr "UTF-8 に変換していて、Python のテスト文字列がすべて UTF-8 に戻されるため、ここで :exc:`UnicodeError` を取得する必要がないことに注意してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:140 -msgid "Filesystem interaction" -msgstr "ファイルシステムの相互作用" - -#: ../../rst/dev_guide/developing_python_3.rst:142 -msgid "Dealing with filenames often involves dropping back to bytes because on UNIX-like systems filenames are bytes. On Python 2, if we pass a text string to these functions, the text string will be converted to a byte string inside of the function and a traceback will occur if non-ASCII characters are present. In Python 3, a traceback will only occur if the text string can't be decoded in the current locale, but it's still good to be explicit and have code which works on both versions:" -msgstr "UNIX 系システムではファイル名はバイトであるため、ファイル名を扱う際にはしばしばバイトに戻すことになります。Python 2 では、これらの関数にテキスト文字列を渡すと、テキスト文字列は関数内でバイト文字列に変換され、非 ASCII 文字が存在する場合にはトレースバックが発生します。Python 3 では、トレースバックはテキスト文字列が現在のロケールでデコードできない場合にのみ発生しますが、明示的に両方のバージョンで動作するコードを用意しておくことが推奨されます。" - -#: ../../rst/dev_guide/developing_python_3.rst:163 -msgid "When you are only manipulating a filename as a string without talking to the filesystem (or a C library which talks to the filesystem) you can often get away without converting to bytes:" -msgstr "ファイルシステム (またはファイルシステムと通信する C ライブラリー) と通信せずにファイル名を文字列として操作するだけの場合は、バイトに変換する必要がないことがよくあります。" - -#: ../../rst/dev_guide/developing_python_3.rst:174 -msgid "On the other hand, if the code needs to manipulate the filename and also talk to the filesystem, it can be more convenient to transform to bytes right away and manipulate in bytes." -msgstr "一方、コードがファイル名を操作し、ファイルシステムとやりとりする場合は、すぐにバイトバイトに変換して題と単位で操作する方が便利です。" - -#: ../../rst/dev_guide/developing_python_3.rst:178 -msgid "Make sure all variables passed to a function are the same type. If you're working with something like :func:`python3:os.path.join` which takes multiple strings and uses them in combination, you need to make sure that all the types are the same (either all bytes or all text). Mixing bytes and text will cause tracebacks." -msgstr "関数に渡されるすべての変数が同じタイプであることを確認します。:func:`python3:os.path.join` のように、複数の文字列を取得し、これらの変数を組み合わせて使用する場合は、すべてのタイプが同じ (すべてのバイトまたはすべてのテキストのいずれか) になるようにする必要があります。バイトとテキストを混在させると、トレースバックが発生します。" - -#: ../../rst/dev_guide/developing_python_3.rst:185 -msgid "Interacting with other programs" -msgstr "他のプログラムとの相互作用" - -#: ../../rst/dev_guide/developing_python_3.rst:187 -msgid "Interacting with other programs goes through the operating system and C libraries and operates on things that the UNIX kernel defines. These interfaces are all byte-oriented so the Python interface is byte oriented as well. On both Python 2 and Python 3, byte strings should be given to Python's subprocess library and byte strings should be expected back from it." -msgstr "他のプログラムとの対話は、オペレーティングシステムと C ライブラリーを経由して、UNIX カーネルが定義するものを操作します。これらのインターフェースはすべてバイト指向であるため、Python インターフェースもバイト指向です。Python 2 と Python3 の両方で、バイト文字列は Python のサブプロセスライブラリーに渡され、バイト文字列はそこから返されることが期待されます。" - -#: ../../rst/dev_guide/developing_python_3.rst:193 -msgid "One of the main places in Ansible's controller code that we interact with other programs is the connection plugins' ``exec_command`` methods. These methods transform any text strings they receive in the command (and arguments to the command) to execute into bytes and return stdout and stderr as byte strings Higher level functions (like action plugins' ``_low_level_execute_command``) transform the output into text strings." -msgstr "Ansible のコントローラーコードで他のプログラムとやり取りする主な場所の 1 つは、connection プラグインの ``exec_command`` メソッドです。これらのメソッドは、コマンドで受け取ったテキスト文字列 (およびコマンドへの引数) をバイトに変換し、stdout と stderr をバイト文字列として返します。(アクションプラグインの ``_low_level_execute_command`` のように) 高レベルの関数出力をテキスト文字列に変換します。" - -#: ../../rst/dev_guide/developing_python_3.rst:203 -msgid "Module string strategy: Native String" -msgstr "モジュール文字列ストラテジー: ネイティブ文字列" - -#: ../../rst/dev_guide/developing_python_3.rst:205 -msgid "In modules we use a strategy known as Native Strings. This makes things easier on the community members who maintain so many of Ansible's modules, by not breaking backwards compatibility by mandating that all strings inside of modules are text and converting between text and bytes at the borders." -msgstr "モジュールでは、ネイティブ文字列と呼ばれるストラテジーを採用しています。これにより、Ansible の多くのモジュールを保守しているコミュニティーメンバーは、モジュール内のすべての文字列がテキストであることを義務付けたり、境界でテキストとバイトの間を変換したりすることで、後方互換性を壊さないようにしています。" - -#: ../../rst/dev_guide/developing_python_3.rst:211 -msgid "Native strings refer to the type that Python uses when you specify a bare string literal:" -msgstr "ネイティブ文字列は、裸の文字列リテラルを指定するときに Python が使用するタイプを参照します。" - -#: ../../rst/dev_guide/developing_python_3.rst:218 -msgid "In Python 2, these are byte strings. In Python 3 these are text strings. Modules should be coded to expect bytes on Python 2 and text on Python 3." -msgstr "Python 2 では、これらはバイト文字列です。Python 3 では、これらはテキスト文字列です。Python 2 ではバイト、および Python 3 ではテキストを期待するようにコード化されている必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:224 -msgid "Module_utils string strategy: hybrid" -msgstr "Module_utils 文字列ストラテジー: ハイブリッド" - -#: ../../rst/dev_guide/developing_python_3.rst:226 -msgid "In ``module_utils`` code we use a hybrid string strategy. Although Ansible's ``module_utils`` code is largely like module code, some pieces of it are used by the controller as well. So it needs to be compatible with modules and with the controller's assumptions, particularly the string strategy. The module_utils code attempts to accept native strings as input to its functions and emit native strings as their output." -msgstr "``module_utils`` コードでは、ハイブリッドな文字列ストラテジーを採用します。Ansible の ``module_utils`` コードは、大部分がモジュールコードのようなものですが、その一部はコントローラーでも使用されます。そのため、モジュールやコントローラの前提条件との互換性、特に文字列ストラテジーとの互換性が必要になります。module_utils コードは、その関数への入力としてネイティブ文字列を受け入れ、その出力としてネイティブ文字列を出力しようとします。" - -#: ../../rst/dev_guide/developing_python_3.rst:233 -msgid "In ``module_utils`` code:" -msgstr "``module_utils`` コードの場合:" - -#: ../../rst/dev_guide/developing_python_3.rst:235 -msgid "Functions **must** accept string parameters as either text strings or byte strings." -msgstr "関数は、文字列パラメーターをテキスト文字列またはバイト文字列のいずれかで使用できるようにする **必要があります**。" - -#: ../../rst/dev_guide/developing_python_3.rst:236 -msgid "Functions may return either the same type of string as they were given or the native string type for the Python version they are run on." -msgstr "関数は、提供された文字列と同じタイプの文字列を返すか、実行している Python のバージョンに合わせたネイティブの文字列型を返すことができます。" - -#: ../../rst/dev_guide/developing_python_3.rst:237 -msgid "Functions that return strings **must** document whether they return strings of the same type as they were given or native strings." -msgstr "文字列を返す関数は、指定の文字列と同じ型の文字列を返すのか、ネイティブの文字列を返すのかを文書化する **必要があります**。" - -#: ../../rst/dev_guide/developing_python_3.rst:239 -msgid "Module-utils functions are therefore often very defensive in nature. They convert their string parameters into text (using ``ansible.module_utils.common.text.converters.to_text``) at the beginning of the function, do their work, and then convert the return values into the native string type (using ``ansible.module_utils.common.text.converters.to_native``) or back to the string type that their parameters received." -msgstr "したがって、module_utils 関数は、本質的に非常に防御的であることがよくあります。この関数は、関数の先頭で (``ansible.module_utils.common.text.converters.to_text`` を使用して) 文字列パラメーターをテキストに変換し、作業を行い、(``ansible.module_utils.common.text.converters.to_native`` を使用して) 戻り値をネイティブの文字列型に変換します。または、パラメーターが受け取った文字列型に戻ります。" - -#: ../../rst/dev_guide/developing_python_3.rst:246 -msgid "Tips, tricks, and idioms for Python 2/Python 3 compatibility" -msgstr "Python 2/Python 3 互換のためのヒント、トリック、およびイディオム" - -#: ../../rst/dev_guide/developing_python_3.rst:249 -msgid "Use forward-compatibility boilerplate" -msgstr "前方互換性のある boilerplate の使用" - -#: ../../rst/dev_guide/developing_python_3.rst:251 -msgid "Use the following boilerplate code at the top of all python files to make certain constructs act the same way on Python 2 and Python 3:" -msgstr "Python 2 と Python 3 で特定の構成要素が同じように動作するようにするために、すべての python ファイルの先頭に以下の boilerplate コードを使用してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:260 -msgid "``__metaclass__ = type`` makes all classes defined in the file into new-style classes without explicitly inheriting from :class:`object `." -msgstr "``__metaclass__ = type`` は、ファイルで定義されているすべてのクラスを :class:`object ` から明示的に継承することなく、新しいスタイルのクラスにします。" - -#: ../../rst/dev_guide/developing_python_3.rst:263 -msgid "The ``__future__`` imports do the following:" -msgstr "``__future__`` のインポートは以下を行います。" - -#: ../../rst/dev_guide/developing_python_3.rst -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:16 -msgid "absolute_import" -msgstr "absolute_import" - -#: ../../rst/dev_guide/developing_python_3.rst:265 -msgid "Makes imports look in :data:`sys.path ` for the modules being imported, skipping the directory in which the module doing the importing lives. If the code wants to use the directory in which the module doing the importing, there's a new dot notation to do so." -msgstr "インポートは、インポートされるモジュールの :data:`sys.path ` を検索し、インポートを行うモジュールが存在するディレクトリーをスキップします。インポートを行うモジュールが存在するディレクトリーをコードが使用したい場合は、新しいドット表記があります。" - -#: ../../rst/dev_guide/developing_python_3.rst -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:31 -msgid "division" -msgstr "division" - -#: ../../rst/dev_guide/developing_python_3.rst:269 -msgid "Makes division of integers always return a float. If you need to find the quotient use ``x // y`` instead of ``x / y``." -msgstr "整数の除算が常に浮動小数点を返すようになります。商を見つける必要がある場合は、``x / y`` の代わりに ``x // y`` を使用してください。" - -#: ../../rst/dev_guide/developing_python_3.rst -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:43 -msgid "print_function" -msgstr "print_function" - -#: ../../rst/dev_guide/developing_python_3.rst:271 -msgid "Changes :func:`print ` from a keyword into a function." -msgstr "キーワードから関数への :func:`print ` の変更" - -#: ../../rst/dev_guide/developing_python_3.rst:274 -msgid "`PEP 0328: Absolute Imports `_" -msgstr "`PEP 0328: Absolute Imports `_" - -#: ../../rst/dev_guide/developing_python_3.rst:275 -msgid "`PEP 0238: Division `_" -msgstr "`PEP 0238: Division `_" - -#: ../../rst/dev_guide/developing_python_3.rst:276 -msgid "`PEP 3105: Print function `_" -msgstr "`PEP 3105: Print function `_" - -#: ../../rst/dev_guide/developing_python_3.rst:279 -msgid "Prefix byte strings with ``b_``" -msgstr "バイト文字列のプレフィックス: ``b_``" - -#: ../../rst/dev_guide/developing_python_3.rst:281 -msgid "Since mixing text and bytes types leads to tracebacks we want to be clear about what variables hold text and what variables hold bytes. We do this by prefixing any variable holding bytes with ``b_``. For instance:" -msgstr "テキスト型とバイト型が混在するとトレースバックが発生するため、どの変数がテキストを保持していて、どの変数がバイトを保持しているかを明確にします。これは、バイトを保持する変数には、``b_`` をプレフィックスとして使用します。以下に例を示します。" - -#: ../../rst/dev_guide/developing_python_3.rst:292 -msgid "We do not prefix the text strings instead because we only operate on byte strings at the borders, so there are fewer variables that need bytes than text." -msgstr "代わりに、ボーダーのバイト文字列でのみ動作するためテキスト文字列はプレフィックスとして付けられません。したがって、テキスト文字列の前にバイト値が必要な変数が少なくなります。" - -#: ../../rst/dev_guide/developing_python_3.rst:297 -msgid "Import Ansible's bundled Python ``six`` library" -msgstr "Ansible のバンドルされた Python ``six`` ライブラリーをインポート" - -#: ../../rst/dev_guide/developing_python_3.rst:299 -msgid "The third-party Python `six `_ library exists to help projects create code that runs on both Python 2 and Python 3. Ansible includes a version of the library in module_utils so that other modules can use it without requiring that it is installed on the remote system. To make use of it, import it like this:" -msgstr "サードパーティーの Python `six `_ ライブラリーは、プロジェクトが Python 2 および Python 3 の両方で実行するコードを作成するのに役立ちます。Ansible には、module_utils にライブラリーのバージョンが含まれ、他のモジュールがリモートシステムにインストールされなくても使用可能となるようになっています。これを使用して、以下のようにインポートしてください。" - -#: ../../rst/dev_guide/developing_python_3.rst:309 -msgid "Ansible can also use a system copy of six" -msgstr "Ansible は、six のシステムコピーを使用することもできます。" - -#: ../../rst/dev_guide/developing_python_3.rst:311 -msgid "Ansible will use a system copy of six if the system copy is a later version than the one Ansible bundles." -msgstr "Ansible は、システムコピーが、Ansible がバンドルしているものよりも後のバージョンのものであれば、six のシステムコピーを使用します。" - -#: ../../rst/dev_guide/developing_python_3.rst:315 -msgid "Handle exceptions with ``as``" -msgstr "``as`` で例外を処理します。" - -#: ../../rst/dev_guide/developing_python_3.rst:317 -msgid "In order for code to function on Python 2.6+ and Python 3, use the new exception-catching syntax which uses the ``as`` keyword:" -msgstr "Python 2.6 以降および Python 3 でコードが機能するには、``as`` キーワードを使用する新しい例外キャッチ構文を使用してください。" - -#: ../../rst/dev_guide/developing_python_3.rst:327 -msgid "Do **not** use the following syntax as it will fail on every version of Python 3:" -msgstr "以下の構文は、Python 3 のすべてのバージョンで失敗するため、**使用しないでください**。" - -#: ../../rst/dev_guide/developing_python_3.rst:338 -msgid "Update octal numbers" -msgstr "8 進数の更新" - -#: ../../rst/dev_guide/developing_python_3.rst:340 -msgid "In Python 2.x, octal literals could be specified as ``0755``. In Python 3, octals must be specified as ``0o755``." -msgstr "Python 2.x では、8 進数リテラルは ``0755`` と指定できました。Python 3 では、8 進数は ``0o755`` と指定しなければなりません。" - -#: ../../rst/dev_guide/developing_python_3.rst:344 -msgid "String formatting for controller code" -msgstr "コントローラーコードの文字列形式" - -#: ../../rst/dev_guide/developing_python_3.rst:347 -msgid "Use ``str.format()`` for Python 2.6 compatibility" -msgstr "Python 2.6 の互換性のために ``str.format()`` の使用" - -#: ../../rst/dev_guide/developing_python_3.rst:349 -msgid "Starting in Python 2.6, strings gained a method called ``format()`` to put strings together. However, one commonly used feature of ``format()`` wasn't added until Python 2.7, so you need to remember not to use it in Ansible code:" -msgstr "Python 2.6 以降、文字列には、文字列をまとめる ``format()`` という名前のメソッドが追加されました。ただし、``format()`` に一般的に使用される機能の 1 つは Python 2.7 まで追加されなかったため、Ansible コードで使用しないように注意する必要があります。" - -#: ../../rst/dev_guide/developing_python_3.rst:361 -msgid "Both of the format strings above map positional arguments of the ``format()`` method into the string. However, the first version doesn't work in Python 2.6. Always remember to put numbers into the placeholders so the code is compatible with Python 2.6." -msgstr "上記の両方の形式文字列では、``format()`` メソッドの位置引数を文字列にマッピングしますが、最初のバージョンは Python 2.6 では動作しません。常に数字をプレースホルダーに置き、コードが Python 2.6 と互換性を持つようにします。" - -#: ../../rst/dev_guide/developing_python_3.rst:367 -msgid "Python documentation on format strings:" -msgstr "フォーマット文字列に関するPythonのドキュメント：" - -#: ../../rst/dev_guide/developing_python_3.rst:369 -msgid "`format strings in 2.6 `_" -msgstr "`format strings in 2.6 `_" - -#: ../../rst/dev_guide/developing_python_3.rst:370 -msgid "`format strings in 3.x `_" -msgstr "`format strings in 3.x `_" - -#: ../../rst/dev_guide/developing_python_3.rst:373 -msgid "Use percent format with byte strings" -msgstr "バイト文字列でのパーセント書式の使用" - -#: ../../rst/dev_guide/developing_python_3.rst:375 -msgid "In Python 3.x, byte strings do not have a ``format()`` method. However, it does have support for the older, percent-formatting." -msgstr "Python 3.x では、バイト文字列に ``format()`` メソッドがありませんが、以前のパーセント形式をサポートします。" - -#: ../../rst/dev_guide/developing_python_3.rst:382 -msgid "Percent formatting added in Python 3.5" -msgstr "Python 3.5 に追加されたパーセント書式" - -#: ../../rst/dev_guide/developing_python_3.rst:384 -msgid "Percent formatting of byte strings was added back into Python 3 in 3.5. This isn't a problem for us because Python 3.5 is our minimum version. However, if you happen to be testing Ansible code with Python 3.4 or earlier, you will find that the byte string formatting here won't work. Upgrade to Python 3.5 to test." -msgstr "Python 3 では、Python 3.5 に、バイト文字列のパーセント書式が追加されました。Python 3.5 は最小バージョンであるため、これは問題ではありません。ただし、Python 3.4 以前のバージョンで Ansible のコードをテストしている場合は、ここでのバイト文字列の書式設定が適切に処理されないことがあります。その場合は、Python 3.5 にアップグレードしてテストしてください。" - -#: ../../rst/dev_guide/developing_python_3.rst:391 -msgid "Python documentation on `percent formatting `_" -msgstr "`percent formatting `_ に関する Python ドキュメント" - -#: ../../rst/dev_guide/developing_rebasing.rst:5 -msgid "Rebasing a pull request" -msgstr "プル要求のリベース" - -#: ../../rst/dev_guide/developing_rebasing.rst:7 -msgid "You may find that your pull request (PR) is out-of-date and needs to be rebased. This can happen for several reasons:" -msgstr "プル要求 (PR) が古いため、リベースが必要になる場合があります。これにはいくつかの理由が考えられます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:9 -msgid "Files modified in your PR are in conflict with changes which have already been merged." -msgstr "発行する PR で変更されたファイルは、すでにマージされている変更と競合しています。" - -#: ../../rst/dev_guide/developing_rebasing.rst:10 -msgid "Your PR is old enough that significant changes to automated test infrastructure have occurred." -msgstr "発行する PR は、自動化されたテストインフラストラクチャーに大幅な変更が加えられるほど古いものです。" - -#: ../../rst/dev_guide/developing_rebasing.rst:12 -msgid "Rebasing the branch used to create your PR will resolve both of these issues." -msgstr "PR を作成するのに使用するブランチを再設定すると、この両方の問題が解決されます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:15 -msgid "Configuring your remotes" -msgstr "リモートの設定" - -#: ../../rst/dev_guide/developing_rebasing.rst:17 -msgid "Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork:" -msgstr "PR をリベースする前に、適切なリモートが設定されていることを確認する必要があります。この手順は、コレクションリポジトリーを含む GitHub のすべてのリポジトリーに適用されます。他のプラットフォーム (bitbucket や gitlab) でも同様の原則とコマンドが適用されますが、構文が異なる場合があります。ここでは、ansible/ansible のリポジトリーを例に挙げています。他のリポジトリーでは、ブランチ名が異なる場合があります。通常の方法でフォークをクローンしたと仮定すると、``origin`` のリモートは操作したユーザーのフォークを指すことになります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:25 -msgid "However, you also need to add a remote which points to the upstream repository:" -msgstr "ただし、アップストリームのリポジトリーを参照するリモートを追加する必要もあります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:31 -msgid "Which should leave you with the following remotes:" -msgstr "次のリモートを残す必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:41 -msgid "Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote:" -msgstr "ブランチのステータスを確認すると、``origin`` のリモートのフォークが最新の状態であることを理解できます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:51 -msgid "Rebasing your branch" -msgstr "ブランチのリベース" - -#: ../../rst/dev_guide/developing_rebasing.rst:53 -msgid "Once you have an ``upstream`` remote configured, you can rebase the branch for your PR:" -msgstr "``upstream`` のリモートを設定したら、PR のブランチをリベースできます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:59 -msgid "This will replay the changes in your branch on top of the changes made in the upstream ``devel`` branch. If there are merge conflicts, you will be prompted to resolve those before you can continue." -msgstr "これにより、アップストリームの ``devel`` ブランチで変更したブランチに変更が再生されます。マージの競合が発生した場合は、続行する前に解決するように求められます。" - -#: ../../rst/dev_guide/developing_rebasing.rst:62 -msgid "After you rebase, the status of your branch changes:" -msgstr "リベース後に、ブランチのステータスが変更になります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:73 -msgid "Don't worry, this is normal after a rebase. You should ignore the ``git status`` instructions to use ``git pull``. We'll cover what to do next in the following section." -msgstr "リベースの後、これは通常通りとなります。``git pull`` を使用する ``git status`` 命令は無視する必要があります。次のセクションでは、次に何をするかについて説明します。" - -#: ../../rst/dev_guide/developing_rebasing.rst:76 -msgid "Updating your pull request" -msgstr "プル要求の更新" - -#: ../../rst/dev_guide/developing_rebasing.rst:78 -msgid "Now that you've rebased your branch, you need to push your changes to GitHub to update your PR." -msgstr "ブランチをリベースしたら、変更を GitHub にプッシュして、PR を更新する必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:80 -msgid "Since rebasing re-writes git history, you will need to use a force push:" -msgstr "リベースは、git 履歴を再書き込みするため、強制的にプッシュする必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:86 -msgid "Your PR on GitHub has now been updated. This will automatically trigger testing of your changes. You should check in on the status of your PR after tests have completed to see if further changes are required." -msgstr "GitHub の PR が更新されました。これにより、変更のテストが自動的に発生します。テスト完了後に PR のステータスを確認し、さらなる変更が必要であるかどうかを確認する必要があります。" - -#: ../../rst/dev_guide/developing_rebasing.rst:90 -msgid "Getting help rebasing" -msgstr "リベースのヘルプ" - -#: ../../rst/dev_guide/developing_rebasing.rst:92 -msgid "For help with rebasing your PR, or other development related questions, join us on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)." -msgstr "PR またはその他の開発関連の質問を再設定する際には、チャットチャンネル #ansible-devel に参加します（ansible.imでMatrixを使用、または`irc.libera.chat `でIRCを使用）。" - -#: ../../rst/dev_guide/developing_rebasing.rst:96 -msgid ":ref:`community_development_process`" -msgstr ":ref:`community_development_process`" - -#: ../../rst/dev_guide/developing_rebasing.rst:97 -msgid "Information on roadmaps, opening PRs, Ansibullbot, and more" -msgstr "ロードマップ、オープン PRS、Ansibullbot などに関する情報" - -#: ../../rst/dev_guide/migrating_roles.rst:6 -msgid "Migrating Roles to Roles in Collections on Galaxy" -msgstr "ロールの、Galaxy のコレクション内のロールへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:8 -msgid "You can migrate any existing standalone role into a collection and host the collection on Galaxy. With Ansible collections, you can distribute many roles in a single cohesive unit of re-usable automation. Inside a collection, you can share custom plugins across all roles in the collection instead of duplicating them in each role's :file:`library/`` directory." -msgstr "既存のスタンドアロンロールをコレクションに移行し、コレクションを Galaxy 上でホストすることができます。Ansible コレクションを使用すると、再利用可能な自動化の 1 つのまとまったユニットで多くのロールを配布できます。コレクションの中では、カスタムプラグインを各ロールの :file:`library/`` ディレクトリーに複製するのではなく、コレクション内のすべてのロールで共有することができます。" - -#: ../../rst/dev_guide/migrating_roles.rst:10 -msgid "You must migrate roles to collections if you want to distribute them as certified Ansible content." -msgstr "ロールを認定済みの Ansible コンテンツとして配布する場合は、ロールをコレクションに移行する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:14 -msgid "If you want to import your collection to Galaxy, you need a `Galaxy namespace `_." -msgstr "コレクションを Galaxy にインポートする場合は、`Galaxy 名前空間 `_ が必要です。" - -#: ../../rst/dev_guide/migrating_roles.rst:16 -msgid "See :ref:`developing_collections` for details on collections." -msgstr "コレクションの詳細は、「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:24 -msgid "Comparing standalone roles to collection roles" -msgstr "スタンドアロンロールとコレクションロールの比較" - -#: ../../rst/dev_guide/migrating_roles.rst:26 -msgid ":ref:`Standalone roles ` have the following directory structure:" -msgstr ":ref:`Standalone roles ` に、以下のディレクトリー構造があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:45 -msgid "The highlighted directories above will change when you migrate to a collection-based role. The collection directory structure includes a :file:`roles/` directory:" -msgstr "上記の強調表示されたディレクトリーは、コレクションベースのロールへの移行時に変化します。コレクションディレクトリー構造には、:file:`roles/` ディレクトリーが含まれます。" - -#: ../../rst/dev_guide/migrating_roles.rst:70 -msgid "You will need to use the Fully Qualified Collection Name (FQCN) to use the roles and plugins when you migrate your role into a collection. The FQCN is the combination of the collection ``namespace``, collection ``name``, and the content item you are referring to." -msgstr "ロールをコレクションに移行するときにロールおよびプラグインを使用するために、完全修飾コレクション名 (FQCN) を使用する必要があります。FQCN は、コレクション ``namespace``、コレクション ``name``、および参照するコンテンツアイテムの組み合わせになります。" - -#: ../../rst/dev_guide/migrating_roles.rst:72 -msgid "So for example, in the above collection, the FQCN to access ``role1`` would be:" -msgstr "たとえば、上記のコレクションでは、``role1`` にアクセスする FQCN は以下のようになります。" - -#: ../../rst/dev_guide/migrating_roles.rst:79 -msgid "A collection can contain one or more roles in the :file:`roles/` directory and these are almost identical to standalone roles, except you need to move plugins out of the individual roles, and use the :abbr:`FQCN (Fully Qualified Collection Name)` in some places, as detailed in the next section." -msgstr "コレクションには、:file:`roles/` ディレクトリーに 1 つまたは複数のロールを含めることができ、これらのロールはスタンドアロンロールとほぼ同じです。ただし、個別のロールからプラグインを外に移動し、一部では :abbr:`FQCN (Fully Qualified Collection Name)` を使用します。これは、次のセクションで詳細に説明します。" - -#: ../../rst/dev_guide/migrating_roles.rst:83 -msgid "In standalone roles, some of the plugin directories referenced their plugin types in the plural sense; this is not the case in collections." -msgstr "スタンドアロンロールでは、プラグインディレクトリーの一部が複数の意味でプラグインタイプを参照していました。コレクションではこのようになりません。" - -#: ../../rst/dev_guide/migrating_roles.rst:88 -msgid "Migrating a role to a collection" -msgstr "ロールのコレクションへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:90 -msgid "To migrate from a standalone role that contains no plugins to a collection role:" -msgstr "プラグインが含まれないスタンドアロンロールからコレクションロールに移行するには、以下を行います。" - -#: ../../rst/dev_guide/migrating_roles.rst:92 -msgid "Create a local :file:`ansible_collections` directory and ``cd`` to this new directory." -msgstr "ローカルの :file:`ansible_collections` ディレクトリーを作成し、この新しいディレクトリーに ``cd`` を作成します。" - -#: ../../rst/dev_guide/migrating_roles.rst:94 -#: ../../rst/dev_guide/migrating_roles.rst:122 -msgid "Create a collection. If you want to import this collection to Ansible Galaxy, you need a `Galaxy namespace `_." -msgstr "コレクションを作成します。このコレクションを Ansible Galaxy にインポートする場合は、`Galaxy 名前空間 `_ が必要です。" - -#: ../../rst/dev_guide/migrating_roles.rst:100 -#: ../../rst/dev_guide/migrating_roles.rst:128 -msgid "This creates the collection directory structure." -msgstr "これにより、コレクションディレクトリー構造が作成されます。" - -#: ../../rst/dev_guide/migrating_roles.rst:102 -#: ../../rst/dev_guide/migrating_roles.rst:130 -msgid "Copy the standalone role directory into the :file:`roles/` subdirectory of the collection. Roles in collections cannot have hyphens in the role name. Rename any such roles to use underscores instead." -msgstr "スタンドアロンのロールディレクトリーをコレクションの :file:`roles/` サブディレクトリーにコピーします。コレクション内のロールにはロール名にハイフンを設定できません。このようなロールは名前を変更し、代わりにアンダースコアを使用するようにします。" - -#: ../../rst/dev_guide/migrating_roles.rst:109 -#: ../../rst/dev_guide/migrating_roles.rst:146 -msgid "Update ``galaxy.yml`` to include any role dependencies." -msgstr "``galaxy.yml`` を更新して、ロールの依存関係を追加します。" - -#: ../../rst/dev_guide/migrating_roles.rst:111 -#: ../../rst/dev_guide/migrating_roles.rst:148 -msgid "Update the collection README.md file to add links to any role README.md files." -msgstr "コレクション README.md ファイルを更新して、ロールの README.md ファイルへのリンクを追加します。" - -#: ../../rst/dev_guide/migrating_roles.rst:116 -msgid "Migrating a role that contains plugins to a collection" -msgstr "プラグインが含まれるロールからコレクションへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:118 -msgid "To migrate from a standalone role that has plugins to a collection role:" -msgstr "プラグインが含まれないスタンドアロンロールからコレクションロールに移行するには、以下を行います。" - -#: ../../rst/dev_guide/migrating_roles.rst:120 -msgid "Create a local :file:`ansible_collections directory` and ``cd`` to this new directory." -msgstr "ローカルの :file:`ansible_collections directory` および ``cd`` をこの新しいディレクトリーに作成します。" - -#: ../../rst/dev_guide/migrating_roles.rst:138 -msgid "Move any modules to the :file:`plugins/modules/` directory." -msgstr "モジュールを :file:`plugins/modules/` ディレクトリーに移動します。" - -#: ../../rst/dev_guide/migrating_roles.rst:144 -msgid "Move any other plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. See :ref:`migrating_plugins_collection` for additional steps that may be required." -msgstr "その他のプラグインを適切な :file:`plugins/PLUGINTYPE/` ディレクトリーに移動します。必要となる可能性のある追加手順については、「:ref:`migrating_plugins_collection`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:150 -msgid "Change any references to the role to use the :abbr:`FQCN (Fully Qualified Collection Name)`." -msgstr ":abbr:`FQCN (Fully Qualified Collection Name)` を使用するように、ロールへの参照を変更します。" - -#: ../../rst/dev_guide/migrating_roles.rst:163 -msgid "You can alternately use the ``collections`` keyword to simplify this:" -msgstr "別の方法では、``collections`` キーワードを使用してこれを単純化することもできます。" - -#: ../../rst/dev_guide/migrating_roles.rst:181 -msgid "Migrating other role plugins to a collection" -msgstr "他のロールプラグインからコレクションへの移行" - -#: ../../rst/dev_guide/migrating_roles.rst:183 -msgid "To migrate other role plugins to a collection:" -msgstr "その他のロールプラグインをコレクションに移行するには、以下を実行します。" - -#: ../../rst/dev_guide/migrating_roles.rst:186 -msgid "Move each nonmodule plugins to the appropriate :file:`plugins/PLUGINTYPE/` directory. The :file:`mynamespace/mycollection/plugins/README.md` file explains the types of plugins that the collection can contain within optionally created subdirectories." -msgstr "モジュール以外の各プラグインを適切な :file:`plugins/PLUGINTYPE/` ディレクトリーに移動します。:file:`mynamespace/mycollection/plugins/README.md` ファイルは、任意で作成されたサブディレクトリー内にコレクションが含めることができるプラグインのタイプを説明します。" - -#: ../../rst/dev_guide/migrating_roles.rst:192 -msgid "Update documentation to use the FQCN. Plugins that use ``doc_fragments`` need to use FQCN (for example, ``mydocfrag`` becomes ``mynamespace.mycollection.mydocfrag``)." -msgstr "FQCN を使用するようにドキュメントを更新します。``doc_fragments`` を使用するプラグインは、FQCN を使用する必要があります (たとえば、``mydocfrag`` は ``mynamespace.mycollection.mydocfrag`` になります)。" - -#: ../../rst/dev_guide/migrating_roles.rst:194 -msgid "Update relative imports work in collections to start with a period. For example, :file:`./filename` and :file:`../asdfu/filestuff` works but :file:`filename` in same directory must be updated to :file:`./filename`." -msgstr "コレクション内の相対インポート作業を更新し、ピリオドで開始します。たとえば、:file:`./filename` および :file:`../asdfu/filestuff` は有効ですが、同じディレクトリー内の :file:`filename` を :file:`./filename` に更新する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:197 -msgid "If you have a custom ``module_utils`` or import from ``__init__.py``, you must also:" -msgstr "カスタムの ``module_utils`` がある、または ``__init__.py`` からインポートする場合は、以下も必要になります。" - -#: ../../rst/dev_guide/migrating_roles.rst:199 -msgid "Change the Python namespace for custom ``module_utils`` to use the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. See :ref:`update_module_utils_role`." -msgstr "カスタム ``module_utils`` の Python 名前空間が、``ansible_collections`` 規則と共に :abbr:`FQCN (Fully Qualified Collection Name)` を使用するように変更します。「:ref:`update_module_utils_role`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:201 -msgid "Change how you import from ``__init__.py``. See :ref:`update_init_role`." -msgstr "``__init__.py`` からインポートする方法を変更します。「:ref:`update_init_role`」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:207 -msgid "Updating ``module_utils``" -msgstr "``module_utils`` の更新" - -#: ../../rst/dev_guide/migrating_roles.rst:209 -msgid "If any of your custom modules use a custom module utility, once you migrate to a collection you cannot address the module utility in the top level ``ansible.module_utils`` Python namespace. Ansible does not merge content from collections into the Ansible internal Python namespace. Update any Python import statements that refer to custom module utilities when you migrate your custom content to collections. See :ref:`module_utils in collections ` for more details." -msgstr "カスタムモジュールのいずれかがカスタムモジュールユーティリティーを使用している場合は、コレクションに移行すると、上位レベルの ``ansible.module_utils`` Python 名前空間でモジュールユーティリティーを扱うことができません。Ansible は、コレクションのコンテンツを Ansible 内部の Python 名前空間にマージしません。カスタムコンテンツをコレクションに移行する際は、カスタムモジュールユーティリティーを参照している Python の import 文を更新してください。詳細は、「:ref:`コレクションの module_utils `」を参照してください。" - -#: ../../rst/dev_guide/migrating_roles.rst:211 -msgid "When coding with ``module_utils`` in a collection, the Python import statement needs to take into account the :abbr:`FQCN (Fully Qualified Collection Name)` along with the ``ansible_collections`` convention. The resulting Python import looks similar to the following example:" -msgstr "コレクションで ``module_utils`` を使用してコーディングする場合、Python の import ステートメントは ``ansible_collections`` 規則とともに :abbr:`FQCN (Fully Qualified Collection Name)` を考慮する必要があります。作成される Python インポートは以下のようになります。" - -#: ../../rst/dev_guide/migrating_roles.rst:219 -msgid "You need to follow the same rules in changing paths and using namespaced names for subclassed plugins." -msgstr "パスの変更と同じルールに従い、サブクラスのプラグインに名前空間を使用した名前を使用する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:221 -msgid "The following example code snippets show a Python and a PowerShell module using both default Ansible ``module_utils`` and those provided by a collection. In this example the namespace is ``ansible_example`` and the collection is ``community``." -msgstr "以下のスニペットの例は、デフォルトの Ansible ``module_utils`` と、コレクションの両方を使用する Python および PowerShell モジュールを示しています。この例では、名前空間は ``ansible_example`` で、コレクションは ``community`` です。" - -#: ../../rst/dev_guide/migrating_roles.rst:223 -msgid "In the Python example the ``module_utils`` is ``helper`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.helper``:" -msgstr "Python の例では、``module_utils`` が ``helper`` で、:abbr:`FQCN (Fully Qualified Collection Name)` は ``ansible_example.community.plugins.module_utils.helper`` です。" - -#: ../../rst/dev_guide/migrating_roles.rst:249 -msgid "In the PowerShell example the ``module_utils`` is ``hyperv`` and the :abbr:`FQCN (Fully Qualified Collection Name)` is ``ansible_example.community.plugins.module_utils.hyperv``:" -msgstr "PowerShell の例では、``module_utils`` が ``hyperv`` で、:abbr:`FQCN (Fully Qualified Collection Name)` は ``ansible_example.community.plugins.module_utils.hyperv`` です。" - -#: ../../rst/dev_guide/migrating_roles.rst:271 -msgid "Importing from __init__.py" -msgstr "__init__.py からのインポート" - -#: ../../rst/dev_guide/migrating_roles.rst:273 -msgid "Because of the way that the CPython interpreter does imports, combined with the way the Ansible plugin loader works, if your custom embedded module or plugin requires importing something from an :file:`__init__.py` file, that also becomes part of your collection. You can either originate the content inside a standalone role or use the file name in the Python import statement. The following example is an :file:`__init__.py` file that is part of a callback plugin found inside a collection named ``ansible_example.community``." -msgstr "CPython インタープリターがインポートを行う方法と、Ansible プラグインローダーが動作する方法を組み合わせることで、カスタムの組み込みモジュールやプラグインが :file:`__init__.py` ファイルから何かをインポートする必要がある場合は、それもコレクションの一部になります。コンテンツをスタンドアロンのロールの内部で生成するか、Python の import 文でファイル名を使用することができます。次の例は、``ansible_example.community`` という名前のコレクションの中にある callback プラグインの一部である :file:`__init__.py` ファイルです。" - -#: ../../rst/dev_guide/migrating_roles.rst:281 -msgid "Example: Migrating a standalone role with plugins to a collection" -msgstr "例: プラグインを持つスタンドアロンロールをコレクションに移行" - -#: ../../rst/dev_guide/migrating_roles.rst:283 -msgid "In this example we have a standalone role called ``my-standalone-role.webapp`` to emulate a standalone role that contains dashes in the name (which is not valid in collections). This standalone role contains a custom module in the ``library/`` directory called ``manage_webserver``." -msgstr "この例では、``my-standalone-role.webapp`` という名前のスタンドアロンのロールがあり、名前にダッシュが含まれるスタンドアロンのロールをエミュレートします (コレクションで有効なものではありません)。このスタンドアロンロールには、``manage_webserver`` と呼ばれる ``library/`` ディレクトリーのカスタムモジュールが含まれます。" - -#: ../../rst/dev_guide/migrating_roles.rst:298 -msgid "Create a new collection, for example, ``acme.webserver``:" -msgstr "新規コレクションを作成します (``acme.webserver`` など)。" - -#: ../../rst/dev_guide/migrating_roles.rst:311 -msgid "Create the ``webapp`` role inside the collection and copy all contents from the standalone role:" -msgstr "コレクション内に ``webapp`` ロールを作成し、standalone ロールからすべてのコンテンツをコピーします。" - -#: ../../rst/dev_guide/migrating_roles.rst:318 -msgid "Move the ``manage_webserver`` module to its new home in ``acme/webserver/plugins/modules/``:" -msgstr "``manage_webserver`` モジュールを ``acme/webserver/plugins/modules/`` 内の新しいホームに移動します。" - -#: ../../rst/dev_guide/migrating_roles.rst:326 -msgid "This example changed the original source file ``manage_webserver.py`` to the destination file ``manage.py``. This is optional but the :abbr:`FQCN (Fully Qualified Collection Name)` provides the ``webserver`` context as ``acme.webserver.manage``." -msgstr "この例では、元のソースファイル ``manage_webserver.py`` を宛先ファイル ``manage.py`` に変更しました。これは任意ですが、:abbr:`FQCN (Fully Qualified Collection Name)` は、``acme.webserver.manage`` として ``webserver`` のコンテキストを提供します。" - -#: ../../rst/dev_guide/migrating_roles.rst:328 -msgid "Change ``manage_webserver`` to ``acme.webserver.manage`` in :file:`tasks/` files in the role ( for example, ``my-standalone-role.webapp/tasks/main.yml``) and any use of the original module name." -msgstr "ロール内の :file:`tasks/` ファイルで ``manage_webserver`` を ``acme.webserver.manage`` に変更 (``my-standalone-role.webapp/tasks/main.yml`` など) し、元のモジュール名を使用します。" - -#: ../../rst/dev_guide/migrating_roles.rst:332 -msgid "This name change is only required if you changed the original module name, but illustrates content referenced by :abbr:`FQCN (Fully Qualified Collection Name)` can offer context and in turn can make module and plugin names shorter. If you anticipate using these modules independent of the role, keep the original naming conventions. Users can add the :ref:`collections keyword ` in their playbooks. Typically roles are an abstraction layer and users won't use components of the role independently." -msgstr "この名前の変更は、元のモジュール名を変更した場合にのみ必要ですが、:abbr:`FQCN (Fully Qualified Collection Name)` で参照されるコンテンツを例示することで、コンテキストを提供し、ひいてはモジュールやプラグインの名前を短くすることができます。これらのモジュールをロールとは関係なく使用することを想定している場合は、元の命名規則を維持してください。ユーザーは、Playbook に :ref:`コレクションのキーワード ` を追加することができます。通常、ロールは抽象レイヤーであり、ユーザーはロールのコンポーネントを個別に使用することはありません。" - -#: ../../rst/dev_guide/migrating_roles.rst:336 -msgid "Example: Supporting standalone roles and migrated collection roles in a downstream RPM" -msgstr "例: ダウンストリーム RPM でのスタンドアロンロールと移行されたコレクションロールのサポート" - -#: ../../rst/dev_guide/migrating_roles.rst:338 -msgid "A standalone role can co-exist with its collection role counterpart (for example, as part of a support lifecycle of a product). This should only be done for a transition period, but these two can exist in downstream in packages such as RPMs. For example, the RHEL system roles could coexist with an `example of a RHEL system roles collection `_ and provide existing backwards compatibility with the downstream RPM." -msgstr "スタンドアロンのロールは、対応するコレクションロールと共存することができます (例: 製品のサポートライフサイクルの一部として)。これは移行期間のみ行うべきですが、これら 2 つは RPM などのパッケージでダウンストリームに存在することができます。たとえば、RHEL のシステムロールは `example of a RHEL system roles collection `_ と共存し、ダウンストリーム RPM との既存の後方互換性を提供することができます。" - -#: ../../rst/dev_guide/migrating_roles.rst:340 -msgid "This section walks through an example creating this coexistence in a downstream RPM and requires Ansible 2.9.0 or later." -msgstr "本セクションでは、ダウンストリーム RPM でこの共存を作成し、Ansible 2.9.0 以降が必要になります。" - -#: ../../rst/dev_guide/migrating_roles.rst:342 -msgid "To deliver a role as both a standalone role and a collection role:" -msgstr "スタンドアロンロールとコレクションロールの両方としてロールを提供するには、以下を実行します。" - -#: ../../rst/dev_guide/migrating_roles.rst:344 -msgid "Place the collection in :file:`/usr/share/ansible/collections/ansible_collections/`." -msgstr "コレクションを :file:`/usr/share/ansible/collections/ansible_collections/` に置きます。" - -#: ../../rst/dev_guide/migrating_roles.rst:345 -msgid "Copy the contents of the role inside the collection into a directory named after the standalone role and place the standalone role in :file:`/usr/share/ansible/roles/`." -msgstr "コレクション内のロールの内容をスタンドアロンロールにちなんで名付けられたディレクトリーにコピーし、スタンドアロンロールを :file:`/usr/share/ansible/roles/` に置きます。" - -#: ../../rst/dev_guide/migrating_roles.rst:347 -msgid "All previously bundled modules and plugins used in the standalone role are now referenced by :abbr:`FQCN (Fully Qualified Collection Name)` so even though they are no longer embedded, they can be found from the collection contents.This is an example of how the content inside the collection is a unique entity and does not have to be bound to a role or otherwise. You could alternately create two separate collections: one for the modules and plugins and another for the standalone role to migrate to. The role must use the modules and plugins as :abbr:`FQCN (Fully Qualified Collection Name)`." -msgstr "スタンドアロンロールで使用されていた、以前にバンドルされていたモジュールやプラグインは、すべて :abbr:`FQCN (Fully Qualified Collection Name)` で参照されるようになりました。そのため、それらはもはや埋め込まれていないにもかかわらず、コレクションのコンテンツから見つけることができます。これは、コレクション内のコンテンツが固有のエンティティーであり、ロールなどに縛られる必要がないことを示す例です。別の方法として、2 つの独立したコレクションを作成することもできます。1 つはモジュールとプラグイン用、もう 1 つは移行先のスタンドアロンロール用です。ロールは、モジュールとプラグインを :abbr:`FQCN (Fully Qualified Collection Name)` として使用する必要があります。" - -#: ../../rst/dev_guide/migrating_roles.rst:349 -msgid "The following is an example RPM spec file that accomplishes this using this example content:" -msgstr "以下は、このサンプルの内容を使用してこれを実現する RPM 仕様ファイルの例です。" - -#: ../../rst/dev_guide/migrating_roles.rst:414 -msgid "Using ``ansible.legacy`` to access local custom modules from collections-based roles" -msgstr "``ansible.legacy`` を使用したコレクションベースのロールからローカルのカスタムモジュールへのアクセス" - -#: ../../rst/dev_guide/migrating_roles.rst:416 -msgid "Some roles within a collection use :ref:`local custom modules ` that are not part of the collection itself. If there is a conflict between the custom module short name and the collection module name, you need to specify which module your tasks call. You can update the tasks to change ``local_module_name`` to ``ansible.legacy.local_module_name`` to ensure you are using the custom module." -msgstr "コレクション内の一部のロールは、コレクション自体の一部ではない :ref:`local custom modules ` を使用します。カスタムモジュールの短縮名とコレクションモジュール名の間に競合がある場合は、タスクが呼び出すモジュールを指定する必要があります。タスクを更新し、``local_module_name`` を ``ansible.legacy.local_module_name`` に変更して、カスタムモジュールを使用していることを確認してください。" - -#: ../../rst/dev_guide/module_lifecycle.rst:5 -msgid "The lifecycle of an Ansible module or plugin" -msgstr "Ansible モジュールまたはプラグインのライフサイクル" - -#: ../../rst/dev_guide/module_lifecycle.rst:7 -msgid "Modules and plugins in the main Ansible repository have a defined life cycle, from the first introduction to final removal. The module and plugin lifecycle is tied to the `Ansible release cycle `. A module or plugin may move through these four stages:" -msgstr "メインの Ansible リポジトリーのモジュールおよびプラグインには、最初の導入から最後の削除までライフサイクルが定義されます。モジュールおよびプラグインのライフサイクルは、`Ansible リリースサイクル ` に紐づけられ、モジュールまたはプラグインは、次の 4 つの段階を通過する可能性があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:10 -msgid "When a module or plugin is first accepted into Ansible, we consider it in tech preview and will mark it as such in the documentation." -msgstr "モジュールまたはプラグインが最初に Ansible に受け入れられると、テクノロジープレビューでそれが考慮され、そのようにマークされます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:12 -msgid "If a module or plugin matures, the 'preview' mark in the documentation is removed. Backward compatibility for these modules and plugins is maintained but not guaranteed, which means their parameters should be maintained with stable meanings." -msgstr "モジュールまたはプラグインが成熟すると、ドキュメントの「preview」マークが削除されます。これらのモジュールおよびプラグインの後方互換性は維持されますが保証されません。これは、これらのパラメーターが安定した意味で維持されるべきことを意味します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:14 -msgid "If a module's or plugin's target API changes radically, or if someone creates a better implementation of its functionality, we may mark it deprecated. Modules and plugins that are deprecated are still available but they are reaching the end of their life cycle. We retain deprecated modules and plugins for 4 release cycles with deprecation warnings to help users update playbooks and roles that use them." -msgstr "モジュールまたはプラグインのターゲット API が大幅に変更された場合、または誰かがその機能に対してより良い実装を作成した場合は、非推奨と表示することがあります。非推奨のモジュールまたはプラグインは引き続き利用できますが、ライフサイクルの終わりに近づいています。非推奨のモジュールまたはプラグインは 4 つのリリースサイクルの間保持され、ユーザーはそれを使用する Playbook とロールを更新できるように非推奨の警告が表示されます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:16 -msgid "When a module or plugin has been deprecated for four release cycles, it is removed and replaced with a tombstone entry in the routing configuration. Modules and plugins that are removed are no longer shipped with Ansible. The tombstone entry helps users find alternative modules and plugins." -msgstr "4 つのリリースサイクルでモジュールまたはプラグインは非推奨となり、ルーティング設定の tombstone エントリーに置き換えられます。削除されたモジュールおよびプラグインは Ansible に同梱されなくなります。tombstone エントリーは、別のモジュールおよびプラグインを見つけることができます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:18 -msgid "For modules and plugins in collections, the lifecycle is similar. Since ansible-base 2.10, it is no longer possible to mark modules as 'preview' or 'stable'." -msgstr "コレクションにあるモジュールおよびプラグインでは、ライフサイクルが類似しています。ansible-base 2.10 では、モジュールを「preview」または「stable」のマークを付けることができなくなります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:23 -msgid "Deprecating modules and plugins in the Ansible main repository" -msgstr "Ansible メインリポジトリーでのモジュールおよびプラグインの非推奨化" - -#: ../../rst/dev_guide/module_lifecycle.rst:25 -msgid "To deprecate a module in ansible-core, you must:" -msgstr "ansible-core でモジュールを非推奨にするには、以下を行う必要があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:27 -msgid "Rename the file so it starts with an ``_``, for example, rename ``old_cloud.py`` to ``_old_cloud.py``. This keeps the module available and marks it as deprecated on the module index pages." -msgstr "ファイルの名前を ``_`` で始まるように変更します。たとえば、``old_cloud.py`` の名前を ``_old_cloud.py`` に変更します。これにより、モジュールが利用可能のままとなり、モジュールインデックスページで非推奨としてマークされます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:28 -msgid "Mention the deprecation in the relevant changelog (by creating a changelog fragment with a section ``deprecated_features``)." -msgstr "(``deprecated_features`` セクションを使用して changelog フラグメントを作成することで) 関連する変更ログで非推奨となったことを説明します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:29 -msgid "Reference the deprecation in the relevant ``porting_guide_core_x.y.rst``." -msgstr "関連する ``porting_guide_core_x.y.rst`` で非推奨化を参照します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:30 -msgid "Add ``deprecated:`` to the documentation with the following sub-values:" -msgstr "次のサブ値を使用して、``deprecated:`` をドキュメントに追加します。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "removed_in" -msgstr "removed_in" - -#: ../../rst/dev_guide/module_lifecycle.rst:32 -#: ../../rst/dev_guide/module_lifecycle.rst:63 -msgid "A ``string``, such as ``\"2.10\"``; the version of Ansible where the module will be replaced with a docs-only module stub. Usually current release +4. Mutually exclusive with :removed_by_date:." -msgstr "``\"2.10\"`` などの ``string`` (モジュールがドキュメントのみのモジュールスタブに置き換えられる Ansible のバージョン)。通常、現在のリリース +4 になります。:removed_by_date: と相互に排他的です。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "remove_by_date" -msgstr "remove_by_date" - -#: ../../rst/dev_guide/module_lifecycle.rst:33 -#: ../../rst/dev_guide/module_lifecycle.rst:64 -msgid "(Added in ansible-base 2.10). An ISO 8601 formatted date when the module will be removed. Usually 2 years from the date the module is deprecated. Mutually exclusive with :removed_in:." -msgstr "(ansible-base 2.10 に追加されます)。モジュールの削除時に ISO 8601 形式の日付。通常は、モジュールが非推奨になってから 2 年間となります。このモジュールでは、:removed_in: と相互排他的になります。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "why" -msgstr "理由" - -#: ../../rst/dev_guide/module_lifecycle.rst:34 -#: ../../rst/dev_guide/module_lifecycle.rst:65 -msgid "Optional string that used to detail why this has been removed." -msgstr "これが削除された理由の詳細に使用される任意の文字列です。" - -#: ../../rst/dev_guide/module_lifecycle.rst -msgid "alternative" -msgstr "代替方法" - -#: ../../rst/dev_guide/module_lifecycle.rst:35 -#: ../../rst/dev_guide/module_lifecycle.rst:66 -msgid "Inform users they should do instead, for example, ``Use M(whatmoduletouseinstead) instead.``." -msgstr "ユーザーが代わりにすべきことを通知します (例: ``Use M(whatmoduletouseinstead) instead.``)。" - -#: ../../rst/dev_guide/module_lifecycle.rst:37 -msgid "For an example of documenting deprecation, see this `PR that deprecates multiple modules `_. Some of the elements in the PR might now be out of date." -msgstr "ドキュメントの非推奨の例は、「`複数のモジュールを非推奨にする PR `_」を参照してください。PR の一部の要素が最新でない可能性があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:41 -msgid "Deprecating modules and plugins in a collection" -msgstr "コレクションでのモジュールおよびプラグインの非推奨化" - -#: ../../rst/dev_guide/module_lifecycle.rst:43 -msgid "To deprecate a module in a collection, you must:" -msgstr "コレクションでモジュールを非推奨にするには、以下を行う必要があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:45 -msgid "Add a ``deprecation`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to deprecate the module ``old_cloud``, add:" -msgstr "``meta/runtime.yml`` の ``plugin_routing`` に ``deprecation`` エントリーを追加します。たとえば、モジュール ``old_cloud`` を非推奨にするには、以下を追加します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:56 -msgid "For other plugin types, you have to replace ``modules:`` with ``:``, for example ``lookup:`` for lookup plugins." -msgstr "他のプラグインタイプの場合、``modules:`` を ``:`` に置き換える必要があります (検索プラグインの場合は ``lookup:`` など)。" - -#: ../../rst/dev_guide/module_lifecycle.rst:58 -msgid "Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date after which the module will be removed in a new major version of the collection." -msgstr "``removal_version`` の代わりに、コレクションの新しいメジャーバージョンでモジュールが削除されるまでの ISO 8601 形式の日付を入れた ``removal_date`` を使用することもできます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:60 -msgid "Mention the deprecation in the relevant changelog. If the collection uses ``antsibull-changelog``, create a changelog fragment with a section ``deprecated_features``." -msgstr "関連する変更ログで非推奨になったことを説明します (コレクションが ``antsibull-changelog`` を使用する場合は、セクション ``deprecated_features`` を指定して changelog フラグメントを作成します)。" - -#: ../../rst/dev_guide/module_lifecycle.rst:61 -msgid "Add ``deprecated:`` to the documentation of the module or plugin with the following sub-values:" -msgstr "以下のサブ値を含むモジュールまたはプラグインのドキュメントに ``deprecated:`` を追加します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:69 -msgid "Changing a module or plugin name in the Ansible main repository" -msgstr "Ansible メインリポジトリーのモジュールまたはプラグイン名の変更" - -#: ../../rst/dev_guide/module_lifecycle.rst:71 -msgid "You can also rename a module and keep a deprecated alias to the old name by using a symlink that starts with _. This example allows the ``stat`` module to be called with ``fileinfo``, making the following examples equivalent:" -msgstr "_ で始まるシンボリックリンクを使用して、モジュールの名前を変更し、非推奨のエイリアスを古い名前に保つこともできます。この例では、``stat`` モジュールを ``fileinfo`` で呼び出すことができるため、次の例は同等になります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:81 -msgid "Renaming a module or plugin in a collection, or redirecting a module or plugin to another collection" -msgstr "コレクションでのモジュールまたはプラグインの名前変更、またはモジュールまたはプラグインを別のコレクションにリダイレクト" - -#: ../../rst/dev_guide/module_lifecycle.rst:83 -msgid "To rename a module or plugin in a collection, or to redirect a module or plugin to another collection, you need to add a ``redirect`` entry to ``plugin_routing`` in ``meta/runtime.yml``. For example, to redirect the module ``old_cloud`` to ``foo.bar.new_cloud``, add:" -msgstr "コレクションでモジュールまたはプラグインの名前を変更するか、モジュールまたはプラグインを別のコレクションにリダイレクトするには、``redirect`` エントリーを、``meta/runtime.yml`` の ``plugin_routing`` に追加する必要があります。たとえば、モジュール ``old_cloud`` を ``foo.bar.new_cloud`` にリダイレクトする場合は、以下を追加します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:92 -msgid "If you want to deprecate the old name, add a ``deprecation:`` entry (see above):" -msgstr "古い名前を非推奨にするには、``deprecation:`` エントリーを追加します (上記を参照)。" - -#: ../../rst/dev_guide/module_lifecycle.rst:104 -msgid "You need to use the Fully Qualified Collection Name (FQCN) of the new module/plugin name, even if it is located in the same collection as the redirect. By using a FQCN from another collection, you redirect the module/plugin to that collection." -msgstr "新規モジュール/プラグイン名の完全修飾コレクション名 (FQCN) を使用する必要があります。これは、リダイレクトと同じコレクションにある場合でも、別のコレクションから FQCN を使用し、モジュール/プラグインをそのコレクションにリダイレクトします。" - -#: ../../rst/dev_guide/module_lifecycle.rst:106 -msgid "If you need to support Ansible 2.9, please note that Ansible 2.9 does not know about ``meta/runtime.yml``. With Ansible 2.9 you can still rename plugins and modules inside one collection by using symbolic links. Note that ansible-base 2.10, ansible-core 2.11, and newer will prefer ``meta/runtime.yml`` entries over symbolic links." -msgstr "Ansible 2.9 をサポートする必要がある場合、Ansible 2.9 は ``meta/runtime.yml`` を認識しない点に注意してください。Ansible 2.9 では、シンボリックリンクを使用して、1 つのコレクション内のプラグインとモジュールの名前を変更できます。ansible-base 2.10、ansible-core 2.11 以降はシンボリックリンクよりも ``meta/runtime.yml`` エントリーを使用することが推奨されます。" - -#: ../../rst/dev_guide/module_lifecycle.rst:110 -msgid "Tombstoning a module or plugin in a collection" -msgstr "コレクションでモジュールまたはプラグインを破棄" - -#: ../../rst/dev_guide/module_lifecycle.rst:112 -msgid "To remove a deprecated module or plugin from a collection, you need to tombstone it:" -msgstr "コレクションから非推奨のモジュールまたはプラグインを削除するには、それを破棄する必要があります。" - -#: ../../rst/dev_guide/module_lifecycle.rst:114 -msgid "Remove the module or plugin file with related files like tests, documentation references, and documentation." -msgstr "テスト、ドキュメント参照、ドキュメントなど、関連ファイルでモジュールまたはプラグインファイルを削除します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:115 -msgid "Add a tombstone entry in ``meta/runtime.yml``. For example, to tombstone the module ``old_cloud``, add:" -msgstr "``meta/runtime.yml`` に tombstone エントリーを追加します。たとえば、モジュール ``old_cloud`` を廃棄するには、以下を追加します。" - -#: ../../rst/dev_guide/module_lifecycle.rst:126 -msgid "Instead of ``removal_version``, you can also use ``removal_date`` with an ISO 8601 formatted date. The date should be the date of the next major release." -msgstr "``removal_version`` の代わりに、ISO 8601 形式の日付を入れた ``removal_date`` を使用することもできます。この日付は、次のメジャーリリースの日付である必要があります。" - -#: ../../rst/dev_guide/overview_architecture.rst:3 -msgid "Ansible architecture" -msgstr "Ansible アーキテクチャー" - -#: ../../rst/dev_guide/overview_architecture.rst:5 -msgid "Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs." -msgstr "Ansible は、クラウドプロビジョニング、設定管理、アプリケーションのデプロイメント、サービス内オーケストレーション、およびその他の IT のニーズを自動化する非常にシンプルな IT 自動化エンジンです。" - -#: ../../rst/dev_guide/overview_architecture.rst:7 -msgid "Being designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time." -msgstr "Ansible は、リリースされたその日から多層デプロイメント用に設計されており、システムを 1 つずつ管理する代わりに、すべてのシステムがどのように相互に関連しているかを記述することで、IT インフラストラクチャーをモデル化します。" - -#: ../../rst/dev_guide/overview_architecture.rst:9 -msgid "It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English." -msgstr "エージェントを使用せず、カスタムセキュリティーインフラストラクチャーを追加しないため、簡単にデプロイメントできます。最も重要なことは、非常に単純な言語 (YAML を Ansible Playbook の形式で使用) を使用しているため、分かりやすい英語に近づける方法で自動化ジョブを記述できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:11 -msgid "In this section, we'll give you a really quick overview of how Ansible works so you can see how the pieces fit together." -msgstr "本セクションでは、Ansible の動作の概要を簡単に説明します。これにより各ピースがどのように組み合わされているかを確認できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:17 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/dev_guide/overview_architecture.rst:19 -msgid "Ansible works by connecting to your nodes and pushing out scripts called \"Ansible modules\" to them. Most modules accept parameters that describe the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required." -msgstr "Ansible は、ノードに接続し、「Ansible モジュール」と呼ばれるスクリプトをノードにプッシュすることで機能します。ほとんどのモジュールは、システムの希望の状態を記述するパラメーターを受け入れます。その後、Ansible はこれらのモジュールを (デフォルトでは SSH 上で) 実行して、終了すると削除されます。モジュールのライブラリーはどのマシンにも配置でき、サーバー、デーモン、またはデータベースは必要ありません。" - -#: ../../rst/dev_guide/overview_architecture.rst:22 -msgid "You can :ref:`write your own modules `, though you should first consider :ref:`whether you should `. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content. You may write specialized modules in any language that can return JSON (Ruby, Python, bash, and so on)." -msgstr ":ref:`独自のモジュールを記述 ` ができますが、最初に :ref:`記述すべきかどうか ` を検討する必要があります。通常、任意のターミナルプログラム、テキストエディター、およびおそらくバージョン管理システムを使用して、コンテンツへの変更を追跡します。JSON を返すことができる任意の言語 (Ruby、Python、bash など) で特殊なモジュールを作成できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:25 -msgid "Module utilities" -msgstr "モジュールユーティリティー" - -#: ../../rst/dev_guide/overview_architecture.rst:27 -msgid "When multiple modules use the same code, Ansible stores those functions as module utilities to minimize duplication and maintenance. For example, the code that parses URLs is ``lib/ansible/module_utils/url.py``. You can :ref:`write your own module utilities ` as well. Module utilities may only be written in Python or in PowerShell." -msgstr "複数のモジュールが同じコードを使用する場合は、Ansible がこの機能をモジュールユーティリティーとして保存し、重複とメンテナンスを最小限に抑えます。たとえば、URL を解析するコードは ``lib/ansible/module_utils/url.py`` となります。:ref:`独自のモジュールユーティリティーを記述 ` をすることもできます。モジュールユーティリティーは、Python または PowerShell でのみ記述できます。" - -#: ../../rst/dev_guide/overview_architecture.rst:30 -msgid "Plugins" -msgstr "プラグイン" - -#: ../../rst/dev_guide/overview_architecture.rst:32 -msgid ":ref:`Plugins ` augment Ansible's core functionality. While modules execute on the target system in separate processes (usually that means on a remote system), plugins execute on the control node within the ``/usr/bin/ansible`` process. Plugins offer options and extensions for the core features of Ansible - transforming data, logging output, connecting to inventory, and more. Ansible ships with a number of handy plugins, and you can easily :ref:`write your own `. For example, you can write an :ref:`inventory plugin ` to connect to any datasource that returns JSON. Plugins must be written in Python." -msgstr ":ref:`Plugins ` は、Ansible のコア機能を拡張するものです。モジュールがターゲットシステムの別のプロセス (通常はリモートシステム上) で実行されるのに対し、プラグインは、``/usr/bin/ansible`` プロセス内のコントロールノードで実行されます。プラグインは、データの変換、出力のロギング、インベントリーへの接続など、Ansible のコア機能のオプションや拡張機能を提供します。Ansible には便利なプラグインが多数同梱されており、簡単に :ref:`自作 ` できます。たとえば、JSON を返すあらゆるデータソースに接続するための :ref:`inventory プラグイン ` を記述することができます。プラグインは Python で記述されている必要があります。" - -#: ../../rst/dev_guide/overview_architecture.rst:35 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/dev_guide/overview_architecture.rst:37 -msgid "By default, Ansible represents the machines it manages in a file (INI, YAML, and so on) that puts all of your managed machines in groups of your own choosing." -msgstr "デフォルトでは、Ansible は、自身が選択したグループにすべての管理マシンを配置するファイル (INI、YAML など) で管理するマシンを表します。" - -#: ../../rst/dev_guide/overview_architecture.rst:39 -msgid "To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues." -msgstr "新しいマシンを追加する場合、追加の SSL 署名サーバーはないため、不明瞭な NTP または DNS の問題が原因で特定のマシンがリンクされなかった理由を判断するのに苦労することはありません。" - -#: ../../rst/dev_guide/overview_architecture.rst:41 -msgid "If there's another source of truth in your infrastructure, Ansible can also connect to that. Ansible can draw inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more." -msgstr "インフラストラクチャーに信頼できる別のソースがある場合は、Ansible もこれに接続できます。Ansible は、EC2、Rackspace、OpenStack などのソースからインベントリー、グループ、および変数情報を取り出すことができます。" - -#: ../../rst/dev_guide/overview_architecture.rst:43 -msgid "Here's what a plain text inventory file looks like:" -msgstr "プレーンテキストのインベントリーファイルは次のようになります。" - -#: ../../rst/dev_guide/overview_architecture.rst:56 -msgid "Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called 'group_vars/' or 'host_vars/') or directly in the inventory file." -msgstr "インベントリーホストの一覧が作成されると、単純なテキストファイル形式で (「group_vars/」または「host_vars/」という名前のサブディレクトリー内、またはインベントリーファイルに直接) 割り当てることができます。" - -#: ../../rst/dev_guide/overview_architecture.rst:58 -msgid "Or, as already mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack." -msgstr "または、上述のように、動的インベントリーを使用して、EC2、Rackspace、OpenStack のようなデータソースからインベントリーをプルすることもできます。" - -#: ../../rst/dev_guide/overview_architecture.rst:61 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/dev_guide/overview_architecture.rst:63 -msgid "Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible starts to get most interesting." -msgstr "Playbook は、インフラストラクチャートポロジーの複数のスライスを細かく調整 (オーケストレーション) することができ、同時に取り組むマシンの数を非常に細かく制御することができます。ここからが、Ansible で最も魅力的な点になります。" - -#: ../../rst/dev_guide/overview_architecture.rst:65 -msgid "Ansible's approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features." -msgstr "Ansible のオーケストレーションへのアプローチは、細かく調整された簡素化の 1 つです。通常、自動化コードは今後何年にも渡って完全に理解できるものであり、特別な構文や機能について覚えておくべきことはほとんどないためです。" - -#: ../../rst/dev_guide/overview_architecture.rst:67 -msgid "Here's what a simple playbook looks like:" -msgstr "以下は単純な Playbook の例です。" - -#: ../../rst/dev_guide/overview_architecture.rst:86 -msgid "The Ansible search path" -msgstr "Ansible 検索パス" - -#: ../../rst/dev_guide/overview_architecture.rst:88 -msgid "Modules, module utilities, plugins, playbooks, and roles can live in multiple locations. If you write your own code to extend Ansible's core features, you may have multiple files with similar or the same names in different locations on your Ansible control node. The search path determines which of these files Ansible will discover and use on any given playbook run." -msgstr "モジュール、モジュールユーティリティー、プラグイン、Playbook、およびロールは複数の場所に置くことができます。Ansible のコア機能を拡張するために独自のコードを作成する場合は、Ansible コントロールノードの異なる場所に同じ名前または類似する名前を持つファイルが複数存在する場合があります。検索パスにより、Ansible が特定の Playbook の実行で検出して使用するこれらのファイルが決まります。" - -#: ../../rst/dev_guide/overview_architecture.rst:91 -msgid "Ansible's search path grows incrementally over a run. As Ansible finds each playbook and role included in a given run, it appends any directories related to that playbook or role to the search path. Those directories remain in scope for the duration of the run, even after the playbook or role has finished executing. Ansible loads modules, module utilities, and plugins in this order:" -msgstr "Ansible の検索パスは、実行中に徐々に大きくなります。Ansible は、特定の実行に含まれる各 Playbook とロールを見つけると、その Playbook またはロールに関連するディレクトリーを検索パスに追加します。これらのディレクトリーは、Playbook またはロールの実行が終了した後でも、実行中はスコープ内に留まります。Ansible は、モジュール、モジュールユーティリティー、およびプラグインを次の順序で読み込みます。" - -#: ../../rst/dev_guide/overview_architecture.rst:97 -msgid "Directories adjacent to a playbook specified on the command line. If you run Ansible with ``ansible-playbook /path/to/play.yml``, Ansible appends these directories if they exist:" -msgstr "コマンドラインで指定した Playbook に隣接するディレクトリー。``ansible-playbook /path/to/play.yml`` で Ansible を実行し、そのディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。" - -#: ../../rst/dev_guide/overview_architecture.rst:105 -msgid "Directories adjacent to a playbook that is statically imported by a playbook specified on the command line. If ``play.yml`` includes ``- import_playbook: /path/to/subdir/play1.yml``, Ansible appends these directories if they exist:" -msgstr "コマンドラインで指定された Playbook によって静的にインポートされる Playbook に隣接するディレクトリー。``play.yml`` に ``- import_playbook: /path/to/subdir/play1.yml`` が含まれていて、これらのディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。" - -#: ../../rst/dev_guide/overview_architecture.rst:115 -msgid "Subdirectories of a role directory referenced by a playbook. If ``play.yml`` runs ``myrole``, Ansible appends these directories if they exist:" -msgstr "Playbook によって参照されるロールディレクトリーのサブディレクトリー。``play.yml`` が ``myrole`` を実行し、次のディレクトリーが存在する場合は、Ansible がそのディレクトリーを追加します。" - -#: ../../rst/dev_guide/overview_architecture.rst:124 -msgid "Directories specified as default paths in ``ansible.cfg`` or by the related environment variables, including the paths for the various plugin types. See :ref:`ansible_configuration_settings` for more information. Sample ``ansible.cfg`` fields:" -msgstr "``ansible.cfg`` のデフォルトパスとして、またはさまざまなプラグインタイプのパスなど、関連する環境変数により指定されたディレクトリー。詳細は、「:ref:`ansible_configuration_settings`」を参照してください。サンプルの ``ansible.cfg`` フィールドは以下のようになります。" - -#: ../../rst/dev_guide/overview_architecture.rst:135 -msgid "Sample environment variables:" -msgstr "以下は、環境変数の例となります。" - -#: ../../rst/dev_guide/overview_architecture.rst:144 -msgid "The standard directories that ship as part of the Ansible distribution." -msgstr "Ansible ディストリビューションに同梱される標準ディレクトリー。" - -#: ../../rst/dev_guide/overview_architecture.rst:148 -msgid "Modules, module utilities, and plugins in user-specified directories will override the standard versions. This includes some files with generic names. For example, if you have a file named ``basic.py`` in a user-specified directory, it will override the standard ``ansible.module_utils.basic``." -msgstr "ユーザーが指定したディレクトリーにあるモジュール、モジュールユーティリティー、およびプラグインは標準バージョンを上書きします。これには、一般的な名前のファイルも含まれます。たとえば、ユーザー指定のディレクトリーに ``basic.py`` という名前のファイルがある場合は、標準の ``ansible.module_utils.basic`` を上書きします。" - -#: ../../rst/dev_guide/overview_architecture.rst:153 -msgid "If you have more than one module, module utility, or plugin with the same name in different user-specified directories, the order of commands at the command line and the order of includes and roles in each play will affect which one is found and used on that particular play." -msgstr "同じ名前のモジュール、モジュールユーティリティー、またはプラグインが複数のユーザー指定ディレクトリーにある場合、コマンドラインでのコマンドの順序や、各プレイでのインクルードとロールの順序は、その特定のプレイでどのモジュールが見つかり、使用されるかによって異なります。" - -#: ../../rst/dev_guide/sidecar.rst:5 -msgid "Adjacent YAML documentation files" -msgstr "隣接 YAML ドキュメントファイル" - -#: ../../rst/dev_guide/sidecar.rst:11 -msgid "YAML documentation for plugins" -msgstr "プラグインの YAML ドキュメント" - -#: ../../rst/dev_guide/sidecar.rst:12 -msgid "For most Ansible plugins, the documentation is in the same file as the code. This approach does not work for cases when:" -msgstr "ほとんどの Ansible プラグインでは、ドキュメントはコードと同じファイルにあります。このアプローチは、次の場合には機能しません。" - -#: ../../rst/dev_guide/sidecar.rst:14 -msgid "Multiple plugins are defined in the same file, such as tests and filters." -msgstr "テストやフィルターなど、複数のプラグインが同じファイルで定義されている場合。" - -#: ../../rst/dev_guide/sidecar.rst:15 -msgid "Plugins are written in a language other than Python (modules)." -msgstr "プラグインが Python 以外の言語 (モジュール) で記述されている場合。" - -#: ../../rst/dev_guide/sidecar.rst:17 -msgid "These cases require plugins to provide documentation in an adjacent ``.py`` file. As of ansible-core 2.14, you can provide documentation as adjacent YAML files instead. The format of a YAML documentation file is nearly identical to its Python equivalent, except it is pure YAML." -msgstr "このような場合、隣接する ``.py`` ファイルでドキュメントを提供するプラグインが必要です。ansible-core 2.14 以降では、代わりに隣接 YAML ファイルとしてドキュメントを提供できます。YAML ドキュメントファイルの形式は、純粋な YAML であることを除いて Python の該当ファイルとほぼ同じです。" - -#: ../../rst/dev_guide/sidecar.rst:22 -msgid "YAML format" -msgstr "YAML 形式" - -#: ../../rst/dev_guide/sidecar.rst:23 -msgid "In Python each section is a variable ``DOCUMENTATION = r\"\"\" ... \"\"\"`` while in YAML it is a mapping key ``DOCUMENTATION: ...``." -msgstr "Python では、各セクションは変数 ``DOCUMENTATION = r\"\"\" ... \"\"\"`` ですが、YAML ではマッピングキー ``DOCUMENTATION: ...`` です。" - -#: ../../rst/dev_guide/sidecar.rst:25 -msgid "Here is a longer example that shows documentation as embedded in a Python file:" -msgstr "これは、ドキュメントが Python ファイルに埋め込まれていることを示す長い例です。" - -#: ../../rst/dev_guide/sidecar.rst:53 -msgid "This example shows the same documentation in YAML format:" -msgstr "次の例は、同じドキュメントを YAML 形式で示しています。" - -#: ../../rst/dev_guide/sidecar.rst:78 -msgid "As the examples above show, Python variables already contain YAML. The main change to use YAML documentation is to simply move the YAML out of such variables." -msgstr "上記の例が示すように、Python 変数にはすでに YAML が含まれています。YAML ドキュメントを使用するための主な変更点として、そのような変数から YAML を移動させます。" - -#: ../../rst/dev_guide/sidecar.rst:80 -msgid "Any adjacent YAML documentation files must be in the same directory as the plugin or module that they document. This means the documentation is available in any directory that contains the plugins or modules." -msgstr "隣接 YAML ドキュメントファイルは、ドキュメント化するプラグインまたはモジュールと同じディレクトリーにある必要があります。これは、プラグインまたはモジュールを含む任意のディレクトリーでドキュメントを利用できることを意味します。" - -#: ../../rst/dev_guide/sidecar.rst:84 -msgid "Supported plugin types" -msgstr "サポート対象のプラグインタイプ" - -#: ../../rst/dev_guide/sidecar.rst:85 -msgid "YAML documentation is mainly intended for filters, tests and modules. While it is possible to use with other plugin types, Ansible always recommends having documentation in the same file as the code for most cases." -msgstr "YAML ドキュメントは、主にフィルター、テスト、モジュールを対象としています。他のプラグインタイプで使用できますが、Ansible では可能な限りコードと同じファイルにドキュメントを含めることが推奨されます。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:4 -msgid "Basic rules" -msgstr "基本ルール" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:9 -msgid "Use standard American English" -msgstr "標準的なアメリカ英語を使用する" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:10 -msgid "Ansible uses Standard American English. Watch for common words that are spelled differently in American English (color vs colour, organize vs organise, and so on)." -msgstr "Ansible は標準的なアメリカ英語を使用します。アメリカ英語では綴りが異なる一般的な単語に注意してください (color と colour、organize と organise など)。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:13 -msgid "Write for a global audience" -msgstr "世界中の読者に向けて書く" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:14 -msgid "Everything you say should be understandable by people of different backgrounds and cultures. Avoid idioms and regionalism and maintain a neutral tone that cannot be misinterpreted. Avoid attempts at humor." -msgstr "記載する内容は、生い立ちや文化が違っても理解できるものでなければなりません。イディオムや地域主義は使用せず、誤って解釈されない中立的な表現を使用します。ユーモアな表現は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:17 -msgid "Follow naming conventions" -msgstr "命名規則に従う" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:18 -msgid "Always follow naming conventions and trademarks." -msgstr "命名規則と商標には常に従ってください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:23 -msgid "Use clear sentence structure" -msgstr "明確な文構造を使用する" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:24 -msgid "Clear sentence structure means:" -msgstr "明確な文法構造とは、以下のようになります。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:26 -msgid "Start with the important information first." -msgstr "重要な情報を最初に示します。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:27 -msgid "Avoid padding/adding extra words that make the sentence harder to understand." -msgstr "文章の理解が難しくなるような単語は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:28 -msgid "Keep it short - Longer sentences are harder to understand." -msgstr "文章は短くします。文章が長くなればなるほど、理解が難しくなります。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:30 -msgid "Some examples of improving sentences:" -msgstr "たとえば、以下のように改善できます。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:33 -#: ../../rst/dev_guide/style_guide/basic_rules.rst:39 -msgid "Bad:" -msgstr "問題がある文章:" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:33 -msgid "The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety." -msgstr "The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety. (崖の端近くを歩き回ると、下に落ちる危険があります。安全を維持するために安全な距離を保つことをお勧めします。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:36 -#: ../../rst/dev_guide/style_guide/basic_rules.rst:42 -msgid "Better:" -msgstr "改善例:" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:36 -msgid "Danger! Stay away from the cliff." -msgstr "Danger! Stay away from the cliff. (危険です。崖から離れてください。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:39 -msgid "Furthermore, large volumes of water are also required for the process of extraction." -msgstr "Furthermore, large volumes of water are also required for the process of extraction. (また、抜歯のプロセスには、水が大量に必要になります。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:42 -msgid "Extraction also requires large volumes of water." -msgstr "Extraction also requires large volumes of water. (抜歯には、大量の水が必要です。)" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:45 -msgid "Avoid verbosity" -msgstr "冗長を避ける" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:46 -msgid "Write short, succinct sentences. Avoid terms like:" -msgstr "短く簡潔な文章を書きます。以下のような用語は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:48 -msgid "\"...as has been said before,\"" -msgstr "「...as has been said before」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:49 -msgid "\"..each and every,\"" -msgstr "「...each and every」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:50 -msgid "\"...point in time,\"" -msgstr "「...point in time」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:51 -msgid "\"...in order to,\"" -msgstr "「...in order to」" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:54 -msgid "Highlight menu items and commands" -msgstr "メニュー項目およびコマンドを強調表示する" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:55 -msgid "When documenting menus or commands, it helps to **bold** what is important." -msgstr "メニューまたはコマンドを文書化する場合は、重要な内容を **太字** にすると役立ちます。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:57 -msgid "For menu procedures, bold the menu names, button names, and so on to help the user find them on the GUI:" -msgstr "メニュー手順では、メニュー名、ボタン名などを太字にして、GUI でその文字を見つけられるようにします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:59 -msgid "On the **File** menu, click **Open**." -msgstr "**ファイル** メニューで、**開く** をクリックします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:60 -msgid "Type a name in the **User Name** field." -msgstr "**ユーザー名** フィールドに名前を入力します。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:61 -msgid "In the **Open** dialog box, click **Save**." -msgstr "**開く** ダイアログボックスで、**保存** をクリックします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:62 -msgid "On the toolbar, click the **Open File** icon." -msgstr "ツールバーで、**ファイルを開く** アイコンをクリックします。" - -#: ../../rst/dev_guide/style_guide/basic_rules.rst:64 -msgid "For code or command snippets, use the RST `code-block directive `_:" -msgstr "code または command スニペットの場合は、RST の `code-block directive `_ を使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:3 -msgid "Grammar and Punctuation" -msgstr "文法および句読点" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:6 -msgid "Common Styles and Usage, and Common Mistakes" -msgstr "一般的なスタイルおよび使用方法、ならびに一般的な間違い" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:9 -#: ../../rst/dev_guide/testing/sanity/ignores.rst:50 -msgid "Ansible" -msgstr "Ansible" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:10 -msgid "Write \"Ansible.\" Not \"Ansible, Inc.\" or \"AnsibleWorks The only exceptions to this rule are when we're writing legal or financial statements." -msgstr "「Ansible, Inc.」または「AnsibleWorks」とせず、「Ansible」と記述してください。このルールの唯一の例外は、法的文書または財務諸表を作成する場合です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:12 -msgid "Never use the logotype by itself in body text. Always keep the same font you are using the rest of the sentence." -msgstr "ロゴマークは、本文で使用しないでください。その他の文章で使用しているフォントを常に使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:14 -msgid "A company is singular in the US. In other words, Ansible is an \"it,\" not a \"they.\"" -msgstr "米国では、会社は単数形で使用します。つまり、Ansible は、「they」ではなく「it」になります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:18 -msgid "Capitalization" -msgstr "大文字" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:19 -msgid "If it's not a real product, service, or department at Ansible, don't capitalize it. Not even if it seems important. Capitalize only the first letter of the first word in headlines." -msgstr "Ansible の実際の製品、サービス、または部門ではない場合は、大文字にしないでください。見出しの最初の単語の最初の文字だけを大文字にします。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:22 -msgid "Colon" -msgstr "コロン" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:23 -msgid "A colon is generally used before a list or series: - The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill." -msgstr "通常、コロンは、リストまたは一連の要素の前に使用されます。- The Triangle Area consists of three cities: Raleigh, Durham, and Chapel Hill." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:26 -msgid "But not if the list is a complement or object of an element in the sentence: - Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail." -msgstr "ただし、リストが、文内の要素の補語または目的語の場合は、以下のようにします。Before going on vacation, be sure to (1) set the alarm, (2) cancel the newspaper, and (3) ask a neighbor to collect your mail." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:29 -msgid "Use a colon after \"as follows\" and \"the following\" if the related list comes immediately after: wedge The steps for changing directories are as follows:" -msgstr "直後に関連するリストを追加する場合は、「as follows」および「the following」(次のとおり) の後にコロンを使用します。The steps for changing directories are as follows:" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:32 -msgid "Open a terminal." -msgstr "Open a terminal." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:33 -msgid "Type cd..." -msgstr "Type cd..." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:35 -msgid "Use a colon to introduce a bullet list (or dash, or icon/symbol of your choice):" -msgstr "コロンを使用して、箇条書きリスト (ダッシュ、アイコンまたは記号を使用) を追加します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:37 -msgid "In the Properties dialog box, you'll find the following entries:" -msgstr "In the Properties dialog box, you'll find the following entries:" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:39 -msgid "Connection name" -msgstr "Connection name" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:40 -msgid "Count" -msgstr "Count" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:41 -msgid "Cost per item" -msgstr "Cost per item" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:45 -msgid "Commas" -msgstr "コンマ" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:46 -msgid "Use serial commas, the comma before the \"and\" in a series of three or more items:" -msgstr "3 つ以上の項目が続く場合は、「and」の前にコンマを使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:48 -msgid "\"Item 1, item 2, and item 3.\"" -msgstr "Item 1, item 2, and item 3." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:51 -msgid "It's easier to read that way and helps avoid confusion. The primary exception to this you will see is in PR, where it is traditional not to use serial commas because it is often the style of journalists." -msgstr "これにより読みやすくなり、混乱を避けることができます。これに対する主な例外は PR です。PR では、多くの場合ジャーナリスト向けのスタイルにより、このようなコンマは使用しません。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:53 -msgid "Commas are always important, considering the vast difference in meanings of the following two statements." -msgstr "次の 2 つの文章の意味が大きく異なることを考えると、コンマは常に重要です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:55 -msgid "Let's eat, Grandma" -msgstr "Let's eat, Grandma" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:56 -msgid "Let's eat Grandma." -msgstr "Let's eat Grandma." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:58 -msgid "Correct punctuation could save Grandma's life." -msgstr "正しい句読点により、おばあさんの命を救うことができます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:60 -msgid "If that does not convince you, maybe this will:" -msgstr "もしくは、以下の例をご覧ください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:66 -msgid "Contractions" -msgstr "縮約" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:67 -msgid "Do not use contractions in Ansible documents." -msgstr "Ansible ドキュメントでは、縮約は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:70 -msgid "Em dashes" -msgstr "エムダッシュ (－)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:71 -msgid "When possible, use em-dashes with no space on either side. When full em-dashes aren't available, use double-dashes with no spaces on either side--like this." -msgstr "可能な場合は、両側にスペースを入れずにエムダッシュ (－) を使用します。エムダッシュ (－) が利用できない場合は、両側に空白を入れずに二重ダッシュを使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:73 -msgid "A pair of em dashes can be used in place of commas to enhance readability. Note, however, that dashes are always more emphatic than commas." -msgstr "読みやすくするために、コンマの代わりにエムダッシュをペアにして使用できます。ただし、ダッシュはコンマよりも常に強調されることに注意してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:75 -msgid "A pair of em dashes can replace a pair of parentheses. Dashes are considered less formal than parentheses; they are also more intrusive. If you want to draw attention to the parenthetical content, use dashes. If you want to include the parenthetical content more subtly, use parentheses." -msgstr "エムダッシュのペアは、括弧のペアの代わりに使用することもできます。ダッシュは括弧よりも形式的ではないと見なされ、押しつけがましく感じることもあります。括弧内のコンテンツに注意を引きたい場合は、ダッシュを使用します。括弧内のコンテンツにあまり注意を引きたくない場合は、括弧を使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:78 -msgid "When dashes are used in place of parentheses, surrounding punctuation should be omitted. Compare the following examples." -msgstr "括弧の代わりにダッシュを使用する場合は、前後の句読点を省略してください。次の例を比較してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:87 -msgid "When used in place of parentheses at the end of a sentence, only a single dash is used." -msgstr "文末に括弧の代わりに使用する場合は、ダッシュを 1 つだけ使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:97 -msgid "Exclamation points (!)" -msgstr "感嘆符 (!)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:98 -msgid "Do not use them at the end of sentences. An exclamation point can be used when referring to a command, such as the bang (!) command." -msgstr "文末には使用しないでください。感嘆符は、bang (!) などのコマンドを参照する場合に使用できます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:101 -msgid "Gender References" -msgstr "性別の参照" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:102 -msgid "Do not use gender-specific pronouns in documentation. It is far less awkward to read a sentence that uses \"they\" and \"their\" rather than \"he/she\" and \"his/hers.\"" -msgstr "ドキュメンテーションでは、性別固有の代名詞は使用しないでください。「he/she」や「his/hers」ではなく「they」および「their」を使用する方が適切です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:104 -msgid "It is fine to use \"you\" when giving instructions and \"the user,\" \"new users,\" and so on. in more general explanations." -msgstr "指示を示す場合は「you」と使用し、より一般的な説明では「the user」、「new users」などを使用すると良いでしょう。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:106 -msgid "Never use \"one\" in place of \"you\" when writing technical documentation. Using \"one\" is far too formal." -msgstr "テクニカルドキュメントを作成する際は、「you」 の意味で「one」を使用しないでください。「one」を使用すると堅苦しくなります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:108 -msgid "Never use \"we\" when writing. \"We\" aren't doing anything on the user side. Ansible's products are doing the work as requested by the user." -msgstr "書き込み時に「we」は使用しないでください。「we」は、ユーザー側では何も実行しません。Ansible の製品は、ユーザーの要求に応じて作業を行います。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:112 -msgid "Hyphen" -msgstr "ハイフン" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:113 -msgid "The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary." -msgstr "このハイフンの主な機能は、特定の複合用語の特徴です。目的が満たされない限り、ハイフンは使用しないでください。複合形容詞が間違って解釈されない場合、または多くの心理学用語と同じ様に、その意味が確立されている場合、ハイフンは必要ありません。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:115 -msgid "Use hyphens to avoid ambiguity or confusion:" -msgstr "ハイフンは、あいまいさや混乱を回避するために使用します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:135 -msgid "In professionally printed material (particularly books, magazines, and newspapers), the hyphen is used to divide words between the end of one line and the beginning of the next. This allows for an evenly aligned right margin without highly variable (and distracting) word spacing." -msgstr "適切な編集が必要な出版物 (特に本、雑誌、新聞) では、単語が行をまたがる場合にハイフンを使用します。これにより、単語の間隔が大きく変わる (そして気が散る) ことなく、右マージンを均等に揃えることができます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:139 -msgid "Lists" -msgstr "リスト" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:140 -msgid "Keep the structure of bulleted lists equivalent and consistent. If one bullet is a verb phrase, they should all be verb phrases. If one is a complete sentence, they should all be complete sentences, and so on." -msgstr "箇条書きの構造を同等かつ一貫性のあるものに保ちます。たとえば、1 つの箇条書きが動詞句である場は、すべての箇条書きが動詞句である必要があります。1 つが完全な文である場合、すべての項目が完全な文である必要があります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:142 -msgid "Capitalize the first word of each bullet. Unless it is obvious that it is just a list of items, such as a list of items like: * computer * monitor * keyboard * mouse" -msgstr "箇条書きでは、それぞれ最初の単語を大文字にします。次のような項目のリストなど、単に項目のリストであることが明らかである場合は除きます (* computer * monitor * keyboard * mouse)。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:148 -msgid "When the bulleted list appears within the context of other copy, (unless it's a straight list like the previous example) add periods, even if the bullets are sentence fragments. Part of the reason behind this is that each bullet is said to complete the original sentence." -msgstr "箇条書きが他の文章に含まれる場合は、(上の例のような単純なリストでない限り) 箇条書きが完全な文になっていなくてもピリオドを追加します。これは、各箇条書きが元の文を完了すると言われているためです。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:150 -msgid "In some cases where the bullets are appearing independently, such as in a poster or a homepage promotion, they do not need periods." -msgstr "箇条書きがポスターやホームページのプロモーションなどのように独立して示される場合、ピリオドは必要ありません。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:152 -msgid "When giving instructional steps, use numbered lists instead of bulleted lists." -msgstr "手順を説明するときは、箇条書きの代わりに番号付きリストを使用してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:156 -msgid "Months and States" -msgstr "月および州" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:157 -msgid "Abbreviate months and states according to AP. Months are only abbreviated if they are used in conjunction with a day. Example: \"The President visited in January 1999.\" or \"The President visited Jan. 12.\"" -msgstr "AP に従って、月と州の名前を省略します。月は、日付と組み合わせて使用される場合に限り省略されます。たとえば、「The President visited in January 1999.」または「The President visited Jan. 12.」です。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:159 -msgid "Months: Jan., Feb., March, April, May, June, July, Aug., Sept., Nov., Dec." -msgstr "月: Jan.、Feb.、March、April、May、June、July、Aug.、Sept.、Nov.、Dec." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:161 -msgid "States: Ala., Ariz., Ark., Calif., Colo., Conn., Del., Fla., Ga., Ill., Ind., Kan., Ky., La., Md., Mass., Mich., Minn., Miss., Mo., Mont., Neb., Nev., NH, NJ, NM, NY, NC, ND, Okla., Ore., Pa., RI, SC, SD, Tenn., Vt., Va., Wash., W.Va., Wis., Wyo." -msgstr "州: Ala.、Ariz.、Ark.、Calif.、Colo.、Conn.、Del.、Fla.、Ga.、Ill.、Ind.、Kan.、Ky.、La.、Md.、Mass.、Mich.、Minn.、Miss.、Mo.、Mont.、Neb.、Nev.、NH、NJ、NM、NY、NC、ND、Okla.、Ore.、Pa.、RI、SC、SD、Tenn.、Vt.、Va.、Wash.、W.Va.、Wis.、Wyo." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:164 -msgid "Numbers" -msgstr "数字" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:165 -msgid "Numbers between one and nine are written out. 10 and above are numerals. The exception to this is writing \"4 million\" or \"4 GB.\" It's also acceptable to use numerals in tables and charts." -msgstr "1 から 9 までの数字が使用されます。10 以上の値は数字を使用します。「4 million」または「4 GB」などは例外となります。また、表やチャートでは数値を使用することもできます。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:168 -msgid "Phone Numbers" -msgstr "電話番号" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:170 -msgid "Phone number style: 1 (919) 555-0123 x002 and 1 888-GOTTEXT" -msgstr "電話番号の形式: 1 (919) 555-0123 x002 および 1 888-GOTTEXT" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:174 -msgid "Quotations (Using Quotation Marks and Writing Quotes)" -msgstr "引用 (引用符の使用と引用の記述)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:175 -msgid "\"Place the punctuation inside the quotes,\" the editor said." -msgstr "\"Place the punctuation inside the quotes,\" the editor said. (「句読点を引用符の中に入れてください」と編集者は言いました)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:177 -msgid "Except in rare instances, use only \"said\" or \"says\" because anything else just gets in the way of the quote itself, and also tends to editorialize." -msgstr "ほとんどの場合は、「said」または「says」だけを使用してください。それ以外は、引用の邪魔になり、編集される傾向があるためです。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:180 -msgid "Place the name first right after the quote:" -msgstr "引用の直後に名前を追加します。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:180 -msgid "\"I like to write first-person because I like to become the character I'm writing,\" Wally Lamb said." -msgstr "\"I like to write first-person because I like to become the character I'm writing,\" Wally Lamb said. (「私は自分が書いているキャラクターになりたいので、一人称を書くのが好きです」と Wally Lamb は言いました)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:184 -msgid "Not:" -msgstr "以下のようにはしないでください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:183 -msgid "\"I like to write first-person because I like to become the character I'm writing,\" said Wally Lamb." -msgstr "\"I like to write first-person because I like to become the character I'm writing,\" said Wally Lamb." - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:187 -msgid "Semicolon" -msgstr "セミコロン" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:188 -msgid "Use a semicolon to separate items in a series if the items contain commas:" -msgstr "項目にコンマが含まれている場合は、セミコロンを使用して項目を区切ります。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:190 -msgid "Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner." -msgstr "Everyday I have coffee, toast, and fruit for breakfast; a salad for lunch; and a peanut butter sandwich, cookies, ice cream, and chocolate cake for dinner. (私は毎日、朝食にコーヒー、トースト、およびフルーツを食べます。ランチはサラダを食べ、ディナーには、ピーナッツバターのサンドイッチ、クッキー、アイスクリーム、およびチョコレートケーキを食べます)" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:192 -msgid "Use a semicolon before a conjunctive adverb (however, therefore, otherwise, namely, for example, and so on): - I think; therefore, I am." -msgstr "接続詞副詞 (however、therefore、otherwise、namely、for example など) の前にセミコロンを使用します。「I think; therefore, I am.」のようにします。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:196 -msgid "Spacing after sentences" -msgstr "文の後のスペース" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:197 -msgid "Use only a single space after a sentence." -msgstr "文の後には、シングルスペースのみを使用してください。" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:200 -msgid "Time" -msgstr "時間" - -#: ../../rst/dev_guide/style_guide/grammar_punctuation.rst:201 -msgid "Time of day is written as \"4 p.m.\"" -msgstr "時刻は「4 p.m」とします。" - -#: ../../rst/dev_guide/style_guide/index.rst:5 -msgid "Ansible documentation style guide" -msgstr "Ansible ドキュメントのスタイルガイド" - -#: ../../rst/dev_guide/style_guide/index.rst:7 -msgid "Welcome to the Ansible style guide! To create clear, concise, consistent, useful materials on docs.ansible.com, follow these guidelines:" -msgstr "Ansible スタイルガイドにようこそ! docs.ansible.com に、明確および簡潔で、一貫性のある有用なドキュメントを作成するために、以下のガイドラインが指定されています。" - -#: ../../rst/dev_guide/style_guide/index.rst:14 -msgid "Linguistic guidelines" -msgstr "言語のガイドライン" - -#: ../../rst/dev_guide/style_guide/index.rst:16 -msgid "We want the Ansible documentation to be:" -msgstr "Ansible ドキュメントでは、以下を目標にしています。" - -#: ../../rst/dev_guide/style_guide/index.rst:18 -msgid "clear" -msgstr "明確な" - -#: ../../rst/dev_guide/style_guide/index.rst:19 -msgid "direct" -msgstr "直接的な" - -#: ../../rst/dev_guide/style_guide/index.rst:20 -msgid "conversational" -msgstr "会話的な" - -#: ../../rst/dev_guide/style_guide/index.rst:21 -msgid "easy to translate" -msgstr "解釈が容易な" - -#: ../../rst/dev_guide/style_guide/index.rst:23 -msgid "We want reading the docs to feel like having an experienced, friendly colleague explain how Ansible works." -msgstr "Ansible が提供するドキュメントは、経験豊富で友好的な同僚に Ansible の仕組みを説明してもらっていると感じられるようなものにすることを目標にしています。" - -#: ../../rst/dev_guide/style_guide/index.rst:27 -msgid "Stylistic cheat-sheet" -msgstr "文体の早見表" - -#: ../../rst/dev_guide/style_guide/index.rst:29 -msgid "This cheat-sheet illustrates a few rules that help achieve the \"Ansible tone\":" -msgstr "以下の早見表は、「Ansibleのトーン」を実現するのに役立つルールを示しています。" - -#: ../../rst/dev_guide/style_guide/index.rst:32 -msgid "Rule" -msgstr "**ルール**" - -#: ../../rst/dev_guide/style_guide/index.rst:32 -msgid "Good example" -msgstr "適切な例" - -#: ../../rst/dev_guide/style_guide/index.rst:32 -msgid "Bad example" -msgstr "不適切な例" - -#: ../../rst/dev_guide/style_guide/index.rst:34 -msgid "Use active voice" -msgstr "能動態を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:34 -msgid "You can run a task by" -msgstr "You can run a task by (以下を使用してタスクを実行できます)" - -#: ../../rst/dev_guide/style_guide/index.rst:34 -msgid "A task can be run by" -msgstr "A task can be run by (タスクは、以下のように実行できます)" - -#: ../../rst/dev_guide/style_guide/index.rst:36 -msgid "Use the present tense" -msgstr "現在形の使用" - -#: ../../rst/dev_guide/style_guide/index.rst:36 -msgid "This command creates a" -msgstr "This command creates a (このコマンドにより...が作成されます。)" - -#: ../../rst/dev_guide/style_guide/index.rst:36 -msgid "This command will create a" -msgstr "This command will create a (このコマンドにより...が作成されます)" - -#: ../../rst/dev_guide/style_guide/index.rst:38 -msgid "Address the reader" -msgstr "読者に話すように書きます。" - -#: ../../rst/dev_guide/style_guide/index.rst:38 -msgid "As you expand your inventory" -msgstr "As you expand your inventory (インベントリーを展開します)" - -#: ../../rst/dev_guide/style_guide/index.rst:38 -msgid "When the number of managed nodes grows" -msgstr "When the number of managed nodes grows (管理ノードの数が増える場合)" - -#: ../../rst/dev_guide/style_guide/index.rst:40 -msgid "Use standard English" -msgstr "標準英語の使用" - -#: ../../rst/dev_guide/style_guide/index.rst:40 -msgid "Return to this page" -msgstr "Return to this page (このページに戻る)" - -#: ../../rst/dev_guide/style_guide/index.rst:40 -msgid "Hop back to this page" -msgstr "Hop back to this page (このページに戻る)" - -#: ../../rst/dev_guide/style_guide/index.rst:42 -msgid "Use American English" -msgstr "アメリカ英語の使用" - -#: ../../rst/dev_guide/style_guide/index.rst:42 -msgid "The color of the output" -msgstr "The color of the output (出力の色)" - -#: ../../rst/dev_guide/style_guide/index.rst:42 -msgid "The colour of the output" -msgstr "The colour of the output (出力の色)" - -#: ../../rst/dev_guide/style_guide/index.rst:46 -msgid "Header case" -msgstr "ヘッダーの書式" - -#: ../../rst/dev_guide/style_guide/index.rst:48 -msgid "Headers should be written in sentence case. For example, this section's title is ``Header case``, not ``Header Case`` or ``HEADER CASE``." -msgstr "ヘッダーは文で使用される書式で記述する必要があります。たとえば、このセクションのタイトルは、``Header Case`` や ``HEADER CASE`` ではなく、``Header case`` と記述します。" - -#: ../../rst/dev_guide/style_guide/index.rst:53 -msgid "Avoid using Latin phrases" -msgstr "ラテン語のフレーズを使用しない" - -#: ../../rst/dev_guide/style_guide/index.rst:55 -msgid "Latin words and phrases like ``e.g.`` or ``etc.`` are easily understood by English speakers. They may be harder to understand for others and are also tricky for automated translation." -msgstr "``e.g.``、``etc.`` のようなラテン語やフレーズは、英語話者であれば簡単に理解できます。ただし、その他の人にとっては理解が難しい場合もあり、自動翻訳の際にも注意が必要になります。" - -#: ../../rst/dev_guide/style_guide/index.rst:59 -msgid "Use the following English terms in place of Latin terms or abbreviations:" -msgstr "したがって、ラテン語の用語または略語の代わりに、英語の用語を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:62 -msgid "Latin" -msgstr "ラテン語" - -#: ../../rst/dev_guide/style_guide/index.rst:62 -msgid "English" -msgstr "英語" - -#: ../../rst/dev_guide/style_guide/index.rst:64 -msgid "i.e" -msgstr "i.e (言い換えると)" - -#: ../../rst/dev_guide/style_guide/index.rst:64 -msgid "in other words" -msgstr "in other words (言い換えると)" - -#: ../../rst/dev_guide/style_guide/index.rst:66 -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:89 -msgid "e.g." -msgstr "e.g. (たとえば)" - -#: ../../rst/dev_guide/style_guide/index.rst:66 -msgid "for example" -msgstr "for example (たとえば)" - -#: ../../rst/dev_guide/style_guide/index.rst:68 -msgid "etc" -msgstr "etc (など)" - -#: ../../rst/dev_guide/style_guide/index.rst:68 -msgid "and so on" -msgstr "and so on (など)" - -#: ../../rst/dev_guide/style_guide/index.rst:70 -msgid "via" -msgstr "via (により)" - -#: ../../rst/dev_guide/style_guide/index.rst:70 -msgid "by/ through" -msgstr "by/ through (により)" - -#: ../../rst/dev_guide/style_guide/index.rst:72 -msgid "vs./versus" -msgstr "vs./versus (対)" - -#: ../../rst/dev_guide/style_guide/index.rst:72 -msgid "rather than/against" -msgstr "rather than/against (対)" - -#: ../../rst/dev_guide/style_guide/index.rst:77 -msgid "reStructuredText guidelines" -msgstr "reStructuredText のガイドライン" - -#: ../../rst/dev_guide/style_guide/index.rst:79 -msgid "The Ansible documentation is written in reStructuredText and processed by Sphinx. We follow these technical or mechanical guidelines on all rST pages:" -msgstr "Ansible ドキュメントは reStructuredText で記述され、Sphinx によって処理されます。すべての rST ページに対して、以下の技術的または機械的なガイドラインが指定されています。" - -#: ../../rst/dev_guide/style_guide/index.rst:85 -msgid "Header notation" -msgstr "ヘッダーの表記法" - -#: ../../rst/dev_guide/style_guide/index.rst:87 -msgid "`Section headers in reStructuredText `_ can use a variety of notations. Sphinx will 'learn on the fly' when creating a hierarchy of headers. To make our documents easy to read and to edit, we follow a standard set of header notations. We use:" -msgstr "`Section headers in reStructuredText `_ は、さまざまな表記を使用できます。Sphinx は、ヘッダーの階層を作成するときに「オンザフライで学習」します。ドキュメントを読みやすく、編集できるようにするために、標準のヘッダー表記法に従います。以下を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:93 -msgid "``###`` with overline, for parts:" -msgstr "上線付き (各部分の場合): ``###``" - -#: ../../rst/dev_guide/style_guide/index.rst:101 -msgid "``***`` with overline, for chapters:" -msgstr "上線付き (章の場合): ``***``" - -#: ../../rst/dev_guide/style_guide/index.rst:109 -msgid "``===`` for sections:" -msgstr "セクションの場合: ``===``" - -#: ../../rst/dev_guide/style_guide/index.rst:116 -msgid "``---`` for subsections:" -msgstr "サブセクションの場合: ``---``" - -#: ../../rst/dev_guide/style_guide/index.rst:123 -msgid "``^^^`` for sub-subsections:" -msgstr "サブサブセクションの場合: ``^^^``" - -#: ../../rst/dev_guide/style_guide/index.rst:130 -msgid "``\"\"\"`` for paragraphs:" -msgstr "パラグラフの場合: ``\"\"\"``" - -#: ../../rst/dev_guide/style_guide/index.rst:139 -msgid "Syntax highlighting - Pygments" -msgstr "構文の強調表示 - Pygment" - -#: ../../rst/dev_guide/style_guide/index.rst:141 -msgid "The Ansible documentation supports a range of `Pygments lexers `_ for `syntax highlighting `_ to make our code examples look good. Each code-block must be correctly indented and surrounded by blank lines." -msgstr "Ansible ドキュメントは、コード例の見栄えを良くするため、`構文の強調表示 `_ の `Pygments lexers `_ の範囲をサポートします。コードブロックは適切にインデントされ、空の行で囲む必要があります。" - -#: ../../rst/dev_guide/style_guide/index.rst:144 -msgid "The Ansible documentation allows the following values:" -msgstr "Ansible ドキュメントでは、以下の値を使用できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:146 -msgid "none (no highlighting)" -msgstr "なし (強調表示なし)" - -#: ../../rst/dev_guide/style_guide/index.rst:147 -msgid "ansible-output (a custom lexer for Ansible output)" -msgstr "ansible-output (Ansible 出力用のカスタム lexer)" - -#: ../../rst/dev_guide/style_guide/index.rst:148 -msgid "bash" -msgstr "bash" - -#: ../../rst/dev_guide/style_guide/index.rst:149 -msgid "console" -msgstr "console" - -#: ../../rst/dev_guide/style_guide/index.rst:150 -msgid "csharp" -msgstr "csharp" - -#: ../../rst/dev_guide/style_guide/index.rst:151 -msgid "ini" -msgstr "ini" - -#: ../../rst/dev_guide/style_guide/index.rst:153 -msgid "powershell" -msgstr "powershell" - -#: ../../rst/dev_guide/style_guide/index.rst:154 -msgid "python" -msgstr "python" - -#: ../../rst/dev_guide/style_guide/index.rst:155 -msgid "rst" -msgstr "rst" - -#: ../../rst/dev_guide/style_guide/index.rst:156 -msgid "sh" -msgstr "sh" - -#: ../../rst/dev_guide/style_guide/index.rst:157 -msgid "shell" -msgstr "shell" - -#: ../../rst/dev_guide/style_guide/index.rst:158 -msgid "shell-session" -msgstr "shell-session" - -#: ../../rst/dev_guide/style_guide/index.rst:159 -msgid "text" -msgstr "text" - -#: ../../rst/dev_guide/style_guide/index.rst:160 -msgid "yaml" -msgstr "yaml" - -#: ../../rst/dev_guide/style_guide/index.rst:161 -msgid "yaml+jinja" -msgstr "yaml+jinja" - -#: ../../rst/dev_guide/style_guide/index.rst:163 -msgid "For example, you can highlight Python code using following syntax:" -msgstr "たとえば、以下の構文を使用して Python コードを強調表示できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:175 -msgid "Internal navigation" -msgstr "内部ナビゲーション" - -#: ../../rst/dev_guide/style_guide/index.rst:177 -msgid "`Anchors (also called labels) and links `_ work together to help users find related content. Local tables of contents also help users navigate quickly to the information they need. All internal links should use the ``:ref:`` syntax. Every page should have at least one anchor to support internal ``:ref:`` links. Long pages, or pages with multiple levels of headers, can also include a local TOC." -msgstr "`アンカー (ラベルとも呼ばれます) およびリンク ` は、関連コンテンツを見つけやすくするために、あるローカルテーブルも必要な情報に移動するのに役立ちます。すべての内部リンクで ``:ref:`` 構文を使用する必要があります。また、各ページには内部 ``:ref:`` リンクに対応するアンカーが 1 つ以上必要になります。長いページまたは複数のヘッダーレベルを持つページにも、ローカルの TOC を使用できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:186 -msgid "Avoid raw URLs. RST and sphinx allow ::code:`https://my.example.com`, but this is unhelpful for those using screen readers. ``:ref:`` links automatically pick up the header from the anchor, but for external links, always use the ::code:`link title `_` format." -msgstr "未処理の URL は使用しないでください。RST と sphinx では ::code:`https://my.example.com` が許可されますが、これはスクリーンリーダーを使用するユーザーにとっては役に立ちません。``:ref:`` リンクはアンカーからヘッダーを自動的に選択しますが、外部リンクの場合は常に ::code:`link title `_` 形式を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:191 -msgid "Adding anchors" -msgstr "アンカーの追加" - -#: ../../rst/dev_guide/style_guide/index.rst:193 -msgid "Include at least one anchor on every page" -msgstr "すべてのページに少なくとも 1 つのアンカーを含める。" - -#: ../../rst/dev_guide/style_guide/index.rst:194 -msgid "Place the main anchor above the main header" -msgstr "メインヘッダーの上にメインアンカーを配置する。" - -#: ../../rst/dev_guide/style_guide/index.rst:195 -msgid "If the file has a unique title, use that for the main page anchor:" -msgstr "このファイルに一意のタイトルがある場合は、メインページのアンカーに使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:201 -msgid "You may also add anchors elsewhere on the page" -msgstr "ページにアンカーを追加することもできます。" - -#: ../../rst/dev_guide/style_guide/index.rst:204 -msgid "Adding internal links" -msgstr "内部リンクの追加" - -#: ../../rst/dev_guide/style_guide/index.rst:206 -msgid "All internal links must use ``:ref:`` syntax. These links both point to the anchor defined above:" -msgstr "すべての内部リンクには ``:ref:`` 構文を使用する必要があります。これらのリンクは共に、上で定義したアンカーを指定します。" - -#: ../../rst/dev_guide/style_guide/index.rst:213 -msgid "The second example adds custom text for the link." -msgstr "2 つ目の例は、リンクのカスタムテキストを追加します。" - -#: ../../rst/dev_guide/style_guide/index.rst:216 -msgid "Adding links to modules and plugins" -msgstr "モジュールおよびプラグインへのリンクの追加" - -#: ../../rst/dev_guide/style_guide/index.rst:218 -msgid "Ansible 2.10 and later require the extended Fully Qualified Collection Name (FQCN) as part of the links:" -msgstr "Ansible 2.10 以降は、リンクの一部として、拡張された完全修飾コレクション名 (FQCN) が必要です。" - -#: ../../rst/dev_guide/style_guide/index.rst:230 -msgid "displays as :ref:`ansible.builtin.first_found lookup plugin `." -msgstr ":ref:`ansible.builtin.first_found lookup plugin ` として表示します。" - -#: ../../rst/dev_guide/style_guide/index.rst:232 -msgid "Modules require different suffixes from other plugins:" -msgstr "モジュールには、他のプラグインとは異なるサフィックスが必要です。" - -#: ../../rst/dev_guide/style_guide/index.rst:234 -msgid "Module links use this extended FQCN module name with ``_module`` for the anchor." -msgstr "モジュールリンクでは、この広範な FQCN モジュール名に、アンカーに ``_module`` を使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:235 -msgid "Plugin links use this extended FQCN plugin name with the plugin type (``_connection`` for example)." -msgstr "プラグインのリンクは、この広範な FQCN プラグイン名をプラグインタイプ (``_connection`` など) で使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:244 -msgid "``ansible.builtin`` is the FQCN for modules included in ``ansible.base``. Documentation links are the only place you prepend ``ansible_collections`` to the FQCN. This is used by the documentation build scripts to correctly fetch documentation from collections on Ansible Galaxy." -msgstr "``ansible.builtin`` は、``ansible.base`` に含まれているモジュールの FQCN です。ドキュメントのリンクは、``ansible_collections`` を FQCN の前に付ける唯一の場所です。これは、Ansible Galaxy のコレクションからドキュメントを適切に取得するために、ドキュメントビルドスクリプトにより使用されます。" - -#: ../../rst/dev_guide/style_guide/index.rst:249 -msgid "Adding local TOCs" -msgstr "ページ内 (ローカル) 目次の追加" - -#: ../../rst/dev_guide/style_guide/index.rst:251 -msgid "The page you're reading includes a `local TOC `_. If you include a local TOC:" -msgstr "このページには `ローカル TOC `_ が含まれます。ローカルの TOC を追加する場合は、以下のようになります。" - -#: ../../rst/dev_guide/style_guide/index.rst:254 -msgid "place it below, not above, the main heading and (optionally) introductory text" -msgstr "目次の下に、主要な見出しと (任意で) 紹介文を追加します。目次の上には追加しないでください。" - -#: ../../rst/dev_guide/style_guide/index.rst:255 -msgid "use the ``:local:`` directive so the page's main header is not included" -msgstr "そのページの主要なヘッダーが含まれないように ``:local:`` ディレクティブを使用します。" - -#: ../../rst/dev_guide/style_guide/index.rst:256 -msgid "do not include a title" -msgstr "タイトルは除外します。" - -#: ../../rst/dev_guide/style_guide/index.rst:258 -msgid "The syntax is:" -msgstr "構文は以下のようになります。" - -#: ../../rst/dev_guide/style_guide/index.rst:266 -msgid "Accessibility guidelines" -msgstr "アクセシビリティのガイドライン" - -#: ../../rst/dev_guide/style_guide/index.rst:268 -msgid "Ansible documentation has a goal to be more accessible. Use the following guidelines to help us reach this goal." -msgstr "Ansible ドキュメントには、アクセスしやすくするという目標があります。次のガイドラインを使用することで、この目標を達成できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:278 -msgid "Images and alternative text" -msgstr "イメージおよび代替テキスト" - -#: ../../rst/dev_guide/style_guide/index.rst:271 -msgid "Ensure all icons, images, diagrams, and non text elements have a meaningful alternative-text description. Do not include screen captures of CLI output. Use ``code-block`` instead." -msgstr "すべてのアイコン、イメージ、ダイアグラム、および非テキスト要素に意味のある代替テキストの説明があることを確認してください。CLI 出力のスクリーンキャプチャーは含めないでください。代わりに ``code-block`` を使用してください。" - -#: ../../rst/dev_guide/style_guide/index.rst:281 -msgid "Links and hypertext" -msgstr "リンクとハイパーテキスト" - -#: ../../rst/dev_guide/style_guide/index.rst:281 -msgid "URLs and cross-reference links have descriptive text that conveys information about the content of the linked target. See :ref:`style_links` for how to format links." -msgstr "URL と相互参照リンクには、リンク先のターゲットの内容に関する情報を伝える説明テキストがあります。リンクの形式については、:ref:`style_links` を参照してください。" - -#: ../../rst/dev_guide/style_guide/index.rst:299 -msgid "Tables" -msgstr "Tables" - -#: ../../rst/dev_guide/style_guide/index.rst:284 -msgid "Tables have a simple, logical reading order from left to right, and top to bottom. Tables include a header row and avoid empty or blank table cells. Label tables with a descriptive title." -msgstr "テーブルには、論理的な読み取り順序があり、左から右、上から下に読み取ります。テーブルにはヘッダー行が含まれ、空のテーブルセルや空白のテーブルセルを回避します。テーブルには説明的なタイトルをラベル付けします。" - -#: ../../rst/dev_guide/style_guide/index.rst:305 -msgid "Colors and other visual information" -msgstr "色やその他の視覚情報" - -#: ../../rst/dev_guide/style_guide/index.rst:302 -msgid "Avoid instructions that rely solely on sensory characteristics. For example, do not use ``Click the square, blue button to continue.``" -msgstr "感覚特性のみに依存する命令は回避します。たとえば、``Click the square, blue button to continue.`` は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/index.rst:303 -msgid "Convey information by methods and not by color alone." -msgstr "色だけではなく、メソッドにより情報を伝えます。" - -#: ../../rst/dev_guide/style_guide/index.rst:304 -msgid "Ensure there is sufficient contrast between foreground and background text or graphical elements in images and diagrams." -msgstr "イメージや図の全景と背景のテキストやグラフィック要素の間に、十分なコントラストがあることを確認します。" - -#: ../../rst/dev_guide/style_guide/index.rst:305 -msgid "Instructions for navigating through an interface make sense without directional indicators such as left, right, above, and below." -msgstr "インターフェイス上を移動する順序は、左、右、上、下などの方向インジケーターがなくても理解できます。" - -#: ../../rst/dev_guide/style_guide/index.rst:308 -msgid "Accessibility resources" -msgstr "アクセシビリティーリソース" - -#: ../../rst/dev_guide/style_guide/index.rst:310 -msgid "Use the following resources to help test your documentation changes:" -msgstr "以下のリソースを使用して、ドキュメントの変更をテストします。" - -#: ../../rst/dev_guide/style_guide/index.rst:312 -msgid "`axe DevTools browser extension `_ - Highlights accessibility issues on a website page." -msgstr "`axe DevTools browser extension `_ - Web サイトのページ上でアクセシビリティーの問題を強調表示します。" - -#: ../../rst/dev_guide/style_guide/index.rst:313 -msgid "`WAVE browser extension `_ from WebAIM - another accessibility tester." -msgstr "WebAIM からの `WAVE browser extension `_ - 別のアクセシビリティーテスター。" - -#: ../../rst/dev_guide/style_guide/index.rst:314 -msgid "`Orca screen reader `_ - Common tool used by people with vision impairments." -msgstr "`Orca screen reader `_ - 視覚障害を持つユーザーが使用する一般的なツール。" - -#: ../../rst/dev_guide/style_guide/index.rst:315 -msgid "`color filter `_ - For color-blind testing." -msgstr "`color filter `_ - 色覚検査用。" - -#: ../../rst/dev_guide/style_guide/index.rst:318 -msgid "More resources" -msgstr "参考資料" - -#: ../../rst/dev_guide/style_guide/index.rst:320 -msgid "These pages offer more help with grammatical, stylistic, and technical rules for documentation." -msgstr "以下のページでは、ドキュメントに関する文法、スタイル、および技術的なルールを紹介しています。" - -#: ../../rst/dev_guide/style_guide/index.rst:335 -msgid ":ref:`community_documentation_contributions`" -msgstr ":ref:`community_documentation_contributions`" - -#: ../../rst/dev_guide/style_guide/index.rst:336 -msgid "How to contribute to the Ansible documentation" -msgstr "Ansible ドキュメントへの貢献方法" - -#: ../../rst/dev_guide/style_guide/index.rst:337 -msgid ":ref:`testing_documentation_locally`" -msgstr ":ref:`testing_documentation_locally`" - -#: ../../rst/dev_guide/style_guide/index.rst:338 -msgid "How to build the Ansible documentation" -msgstr "Ansible ドキュメントのビルド方法" - -#: ../../rst/dev_guide/style_guide/index.rst:340 -msgid "#ansible-docs IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-docs)" - -#: ../../rst/dev_guide/style_guide/resources.rst:2 -msgid "Resources" -msgstr "リソース" - -#: ../../rst/dev_guide/style_guide/resources.rst:3 -msgid "Follow the style of the :ref:`Ansible Documentation`" -msgstr ":ref:`Ansible ドキュメント` のスタイルに従ってください。" - -#: ../../rst/dev_guide/style_guide/resources.rst:4 -msgid "Ask for advice on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)" -msgstr "``#ansible-devel`` チャットチャンネルでアドバイスを求めてください（ansible.imでMatrixを使用、または`irc.libera.chat `_でIRCを使用）。" - -#: ../../rst/dev_guide/style_guide/resources.rst:5 -msgid "Review these online style guides:" -msgstr "オンラインで利用できるスタイルガイドを参照してください。" - -#: ../../rst/dev_guide/style_guide/resources.rst:7 -msgid "`AP Stylebook `_" -msgstr "`AP Stylebook `_" - -#: ../../rst/dev_guide/style_guide/resources.rst:8 -msgid "`Chicago Manual of Style `_" -msgstr "`Chicago Manual of Style `_" - -#: ../../rst/dev_guide/style_guide/resources.rst:9 -msgid "`Strunk and White's Elements of Style `_" -msgstr "`Strunk and White's Elements of Style `_" - -#: ../../rst/dev_guide/style_guide/resources.rst:10 -msgid "`Google developer documentation style guide `_" -msgstr "`Google developer documentation style guide `_" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:5 -msgid "Writing documentation so search can find it" -msgstr "検索用のドキュメントの作成" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:7 -msgid "One of the keys to writing good documentation is to make it findable. Readers use a combination of internal site search and external search engines such as Google or duckduckgo." -msgstr "優れたドキュメントを作成するための鍵の 1 つは、ドキュメントを見つけやすくすることです。読者は、サイト内検索や、Google、duckduckgo などの外部検索エンジンを組み合わせて使用します。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:9 -msgid "To ensure Ansible documentation is findable, you should:" -msgstr "Ansible ドキュメントが見つかるようにするには、以下を行う必要があります。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:11 -msgid "Use headings that clearly reflect what you are documenting." -msgstr "ドキュメントの内容を明確に反映させる見出しを使用します。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:12 -msgid "Use numbered lists for procedures or high-level steps where possible." -msgstr "可能な場合は、番号付きの一覧または手順の概要手順に使用します。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:13 -msgid "Avoid linking to github blobs where possible." -msgstr "可能な限り、github ブログにはリンクしないでください。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:17 -msgid "Using clear headings in documentation" -msgstr "ドキュメントで明確な見出しの使用" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:19 -msgid "We all use simple English when we want to find something. For example, the title of this page could have been any one of the following:" -msgstr "何かを探すときは、簡単な英語を使います。たとえば、このページのタイトルは次のいずれかになります。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:21 -msgid "Search optimization" -msgstr "Search optimization (検索の最適化)" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:22 -msgid "Findable documentation" -msgstr "Findable documentation (検索可能なドキュメント)" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:23 -msgid "Writing for findability" -msgstr "Writing for findability (見やすくするための記述)" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:25 -msgid "What we are really trying to describe is - how do I write documentation so search engines can find my content? That simple phrase is what drove the title of this section. When you are creating your headings for documentation, spend some time to think about what you would type in a search box to find it, or more importantly, how someone less familiar with Ansible would try to find that information. Your heading should be the answer to that question." -msgstr "ここで説明しようとしているのは、「検索エンジンがコンテンツを見つけられるようにするドキュメントの書き方」です。その単純なフレーズが、このセクションのタイトルになりました。ドキュメントの見出しを作成するときは、検索ボックスに何を入力して検索するのか、さらに重要なことに、Ansible にあまり詳しくないユーザーがその情報をどのように見つけようとするかを考える時間を設けてください。見出しは、その質問に対する答えであるべきです。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:27 -msgid "One word of caution - you do want to limit the size of your headings. A full heading such as `How do I write documentation so search engines can find my content?` is too long. Search engines would truncate anything over 50 - 60 characters. Long headings would also wrap on smaller devices such as a smart phone." -msgstr "注記 - 見出しのサイズを制限する場合は、`How do I write documentation so search engines can find my content?` などの見出しにすると長すぎます。検索エンジンは 50 ~ 60 文字を超えるものは切り捨てます。長い見出しも、スマートフォンなどの小規模なデバイスでは折り返されます。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:30 -msgid "Using numbered lists for `zero position` snippets" -msgstr "`zero position` スニペットの番号付きのリストの使用" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:32 -msgid "Google can optimize the search results by adding a `feature snippet `_ at the top of the search results. This snippet provides a small window into the documentation on that first search result that adds more detail than the rest of the search results, and can occasionally answer the reader's questions right there, or at least verify that the linked page is what the reader is looking for." -msgstr "Google は、検索結果の上部に `機能スニペット `_ を追加して検索結果を最適化できます。このスニペットは、最初の検索結果に関するドキュメントに小さなウィンドウを提供し、残りの検索結果よりも詳細を追加し、時には読者の質問にその場で答えたり、少なくともリンク先のページが読者の探しているものであることを確認することができます。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:34 -msgid "Google returns the feature snippet in the form of numbered steps. Where possible, you should add a numbered list near the top of your documentation page, where appropriate. The steps can be the exact procedure a reader would follow, or could be a high level introduction to the documentation topic, such as the numbered list at the top of this page." -msgstr "Google は番号付きの手順の機能スニペットを返します。可能であれば、必要に応じて、ドキュメントページの上部付近に番号付きリストを追加する必要があります。手順は、読者が従う正確な手順にすることも、このページの上部にある番号付きリストなど、ドキュメントトピックの概要を説明することもできます。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:37 -msgid "Problems with github blobs on search results" -msgstr "検索結果に関する github ブロブの問題" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:39 -msgid "Search engines do not typically return github blobs in search results, at least not in higher ranked positions. While it is possible and sometimes necessary to link to github blobs from documentation, the better approach would be to copy that information into an .rst page in Ansible documentation." -msgstr "検索エンジンは通常、少なくとも上位の位置では、検索結果に github ブロブを返しません。ドキュメントから github ブロブにリンクすることは可能であり、場合によっては必要ですが、より良いアプローチは、その情報を Ansible ドキュメントの .rst ページにコピーすることです。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:42 -msgid "Other search hints" -msgstr "他の検索ヒント" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:44 -msgid "While it may not be possible to adapt your documentation to all search optimizations, keep the following in mind as you write your documentation:" -msgstr "すべての検索最適化にドキュメントを調整することができない場合もありますが、ドキュメントを作成する場合は、以下の点に留意してください。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:46 -msgid "**Search engines don't parse beyond the `#` in an html page.** So for example, all the subheadings on this page are appended to the main page URL. As such, when I search for 'Using number lists for zero position snippets', the search result would be a link to the top of this page, not a link directly to the subheading I searched for. Using :ref:`local TOCs ` helps alleviate this problem as the reader can scan for the header at top of the page and click to the section they are looking for. For critical documentation, consider creating a new page that can be a direct search result page." -msgstr "**検索エンジンは、html ページ内の `#` 以降は解析しません。** そのため、たとえば、このページのすべての小見出しは、メインページの URL に付加されています。そのため、「Using number lists for zero position snippets」と検索すると、検索結果はこのページの冒頭へのリンクになり、検索した小見出しへの直接のリンクにはなりません。:ref:`ローカル TOC ` を使用すると、読者がページに上部のヘッダーに目を通して、探しているセクションをクリックできるため、この問題を軽減することができます。重要な文書については、検索結果のページに直接アクセスできるように新しいページを作成することを検討してください。" - -#: ../../rst/dev_guide/style_guide/search_hints.rst:48 -msgid "**Make your first few sentences clearly describe your page topic.** Search engines return not just the URL, but a short description of the information at the URL. For Ansible documentation, we do not have description metadata embedded on each page. Instead, the search engines return the first couple of sentences (140 characters) on the page. That makes your first sentence or two very important to the reader who is searching for something in Ansible." -msgstr "**最初の 2、3 文でページのトピックを明確に説明してください。** 検索エンジンは URL だけでなく、その URL にある情報の簡単な説明も返します。Ansible ドキュメントの場合は、各ページに説明メタデータが埋め込まれていません。その代わり、検索エンジンはページの最初の 2、3 文 (140 文字) を返します。そのため、Ansibleで何かを検索している読者にとって、最初の 1〜2 文が非常に重要になります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:2 -msgid "Spelling - Word Usage - Common Words and Phrases to Use and Avoid" -msgstr "スペル、単語の使用、および使用または回避する一般的な単語とフレーズ" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:5 -msgid "Acronyms" -msgstr "略語" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:7 -msgid "Always uppercase. An acronym is a word formed from the initial letters of a name, such as ROM for Read-only memory, SaaS for Software as a Service, or by combining initial letters or part of a series of words, such as LILO for LInux LOader." -msgstr "常に大文字です。頭字語とは、ROM (Read-Only Memory) や SaaS (Software as a Service) のように名前の頭文字から形成された単語や、LILO (LInux LOader) のように一連の単語の頭文字や一部を組み合わせて形成された単語のことです。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:11 -msgid "Spell out the acronym before using it in alone text, such as \"The Embedded DevKit (EDK)...\"" -msgstr "略語は、単独で使用する前に、「The Embedded devkit (EDK)...」のように文字を略さずに書いて使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:14 -msgid "Applications" -msgstr "アプリケーション" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:15 -msgid "When used as a proper name, use the capitalization of the product, such as GNUPro or Source-Navigator. When used as a command, use lowercase as appropriate, such as \"To start GCC, type ``gcc``.\"" -msgstr "固有名詞として使用する場合は、GNUPro または Source-Navigator のように製品の大文字を使用します。コマンドとして使用する場合は、\"To start GCC, type ``gcc``\" のように、適切な小文字を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:19 -msgid "\"vi\" is always lowercase." -msgstr "「vi」は常に小文字です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:22 -msgid "As" -msgstr "As" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:23 -msgid "This is often used to mean \"because\", but has other connotations, for example, parallel or simultaneous actions. If you mean \"because\", say \"because\"." -msgstr "原因を示す場合によく使用されますが、並列または同時の操作など、他の意味もあります。「原因」を意味する場合は、「because」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:26 -msgid "Asks for" -msgstr "Asks for" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:27 -msgid "Use \"requests\" instead." -msgstr "代わりに「requests」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:30 -msgid "Assure/Ensure/Insure" -msgstr "Assure/Ensure/Insure" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:31 -msgid "Assure implies a sort of mental comfort. As in \"I assured my husband that I would eventually bring home beer.\"" -msgstr "「assure」は、一種の精神的な安心さを意味します。たとえば、「I assured my husband that I would eventually bring home beer. (私は夫に最終的に家のビールを持ってくることを約束しました)」のように使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:33 -msgid "Ensure means \"to make sure.\"" -msgstr "「ensure」は、「確実に」を意味します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:35 -msgid "Insure relates to monetary insurance." -msgstr "「insure」は、金銭的な保険に関係があります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:39 -msgid "Back up" -msgstr "Back up" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:40 -msgid "This is a verb. You \"back up\" files; you do not \"backup\" files." -msgstr "これは動詞です。ファイルを「バックアップ」するときは、「backup」ではなく、「back up」と記載します (You back up files)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:43 -msgid "Backup" -msgstr "Backup" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:44 -msgid "This is a noun. You create \"backup\" files; you do not create \"back up\" files." -msgstr "これは名詞です。「バックアップ」ファイルを作成するときは、「back up」ではなく、「backup」と記載します (You create backup files)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:47 -msgid "Backward" -msgstr "Backward" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:48 -msgid "Correct. Avoid using backwards unless you are stating that something has \"backwards compatibility.\"" -msgstr "適切です。「backwards compatibility」(後方互換性) 以外の説明に、「backward」という単語を使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:51 -msgid "Backwards compatibility" -msgstr "Backwards compatibility" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:52 -msgid "Correct as is." -msgstr "そのまま使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:55 -msgid "By way of" -msgstr "By way of" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:56 -msgid "Use \"using\" instead." -msgstr "代わりに「using」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:59 -msgid "Can/May" -msgstr "Can/May" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:60 -msgid "Use \"can\" to describe actions or conditions that are possible. Use \"may\" only to describe situations where permission is being given. If either \"can,\" \"could,\" or \"may\" apply, use \"can\" because it's less tentative." -msgstr "「can」は、可能な操作や条件を説明するのに使用します。許可が必要な状況を説明するには、「may」を使用します。「can」、「could」、または「may」のいずれかが当てはまる場合は、「can」を使用します (暫定的な意味合いが少ないため)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:63 -msgid "CD or cd" -msgstr "CD または cd" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:64 -msgid "When referring to a compact disk, use CD, such as \"Insert the CD into the CD-ROM drive.\" When referring to the change directory command, use cd." -msgstr "コンパクトディスクを参照する場合は、CD を使用します。たとえば、「Insert the CD into the CD-ROM drive.」(CD を CD-ROM ドライブに挿入します。) とします。ディレクトリーを変更する change directory コマンドを示す場合は、cd を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:67 -msgid "CD-ROM" -msgstr "CD-ROM" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:68 -msgid "Correct. Do not use \"cdrom,\" \"CD-Rom,\" \"CDROM,\" \"cd-rom\" or any other variation. When referring to the drive, use CD-ROM drive, such as \"Insert the CD into the CD-ROM drive.\" The plural is \"CD-ROMs.\"" -msgstr "「cdrom」、「CD-Rom」、「CDROM」、「cd-rom」などの表記は使用しないでください。ドライブを参照する場合は、「Insert the CD into the CD-ROM drive (CD-ROM ドライブなど)」のように「CD-ROM drive」を使用します。複数形は「CD-ROMs」となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:72 -msgid "Command line" -msgstr "Command line" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:73 -msgid "Correct. Do not use \"command-line\" or \"commandline\" as a noun. If used as an adjective, \"command-line\" is appropriate, for example \"command-line arguments\"." -msgstr "適切です。「command-line」または「commandline」を名詞として使用しないでください。形容詞として使用する場合は、「command-line arguments」のように、「command-line」が適切です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:75 -msgid "Use \"command line\" to describes where to place options for a command, but not where to type the command. Use \"shell prompt\" instead to describe where to type commands. The line on the display screen where a command is expected. Generally, the command line is the line that contains the most recently displayed command prompt." -msgstr "「コマンドライン」を使用して、コマンドのオプションを追加する場所を記述しますが、コマンドを入力する場所は記述しません。コマンドを入力する場所を説明する場合は、代わりに「shell prompt」を使用します。コマンドが期待される画面上の行となります。通常、コマンドラインは、最後に表示されるコマンドプロンプトを含む行となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:79 -msgid "Daylight saving time (DST)" -msgstr "Daylight saving time (DST)" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:81 -msgid "Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled \"Daylight Savings\", with an \"s\" at the end. Other common variations are \"Summer Time\"and \"Daylight-Saving Time\". (https://www.timeanddate.com/time/dst/daylight-savings-time.html)" -msgstr "適切です。「daylight savings time」は使用しないでください。「Daylight Saving Time (DST)」は、「Daylight Savings」のように、最後に s が付いている場合がありますが、これは間違いです。その他の一般的な表記法には、「Summer Time」および「Daylight-Saving Time」があります (https://www.timeanddate.com/time/dst/daylight-savings-time.html)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:85 -msgid "Download" -msgstr "Download" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:86 -msgid "Correct. Do not use \"down load\" or \"down-load.\"" -msgstr "適切です。「down load」または「down-load」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:90 -msgid "Spell it out: \"For example.\"" -msgstr "省略せずに「For example」とします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:93 -msgid "Failover" -msgstr "Failover" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:94 -msgid "When used as a noun, a failover is a backup operation that automatically switches to a standby database, server or network if the primary system fails or is temporarily shut down for servicing. Failover is an important fault tolerance function of mission-critical systems that rely on constant accessibility. Failover automatically and transparently to the user redirects requests from the failed or down system to the backup system that mimics the operations of the primary system." -msgstr "名詞として使用される場合、フェイルオーバーとは、プライマリーシステムに障害が発生したり、サービスのために一時的に停止した場合に、自動的にスタンバイデータベース、サーバー、またはネットワークに切り替えるバックアップ操作のことです。フェイルオーバーは、常にアクセス可能であることが求められるミッションクリティカルなシステムの重要なフォールトトレランス機能となります。フェイルオーバーは、自動的かつユーザーに透過的に、障害や停止したシステムからのリクエストを、プライマリーシステムの操作を模倣したバックアップシステムにリダイレクトします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:97 -msgid "Fail over" -msgstr "Fail over" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:98 -msgid "When used as a verb, fail over is two words since there can be different tenses such as failed over." -msgstr "動詞として使用する場合は、時制を変えられるように (failed over など)、2 つの単語にします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:101 -msgid "Fewer" -msgstr "Fewer" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:102 -msgid "Fewer is used with plural nouns. Think things you could count. Time, money, distance, and weight are often listed as exceptions to the traditional \"can you count it\" rule, often thought of a singular amounts (the work will take less than 5 hours, for example)." -msgstr "fewer は、複数形の名詞で使用します。数を数えることができるものに使用します。時間、お金、距離、および重量は、従来の「数えることができるか」ルールの例外として挙げられることが多く、通常は 1 つの量と見なされます。たとえば、「the work will take less than 5 hours」(作業にかかる時間は 5 時間未満です)。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:105 -msgid "File name" -msgstr "File name" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:106 -msgid "Correct. Do not use \"filename.\"" -msgstr "適切です。「filename」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:109 -msgid "File system" -msgstr "File system" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:110 -msgid "Correct. Do not use \"filesystem.\" The system that an operating system or program uses to organize and keep track of files. For example, a hierarchical file system is one that uses directories to organize files into a tree structure. Although the operating system provides its own file management system, you can buy separate file management systems. These systems interact smoothly with the operating system but provide more features, such as improved backup procedures and stricter file protection." -msgstr "適切です。「filesystem」は使用しないでください。オペレーティングシステムまたはプログラムがファイルを整理し、追跡するために使用するシステムです。たとえば、階層ファイルシステムは、ディレクトリーを使用してファイルをツリー構造に編成するものです。オペレーティングシステムは独自のファイル管理システムを提供していますが、別のファイル管理システムを使用することもできます。このようなシステムはオペレーティングシステムとスムーズに対話しますが、バックアップ手順の改善やファイル保護の強化など、より多くの機能を提供します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:113 -msgid "For instance" -msgstr "For instance" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:114 -msgid "For example,\" instead." -msgstr "代わりに「For example」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:117 -msgid "For further/additional/whatever information" -msgstr "For further/additional/whatever information" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:118 -msgid "Use \"For more information\"" -msgstr "「For more information」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:121 -msgid "For this reason" -msgstr "For this reason" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:122 -msgid "Use \"therefore\"." -msgstr "「therefore」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:125 -msgid "Forward" -msgstr "Forward" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:126 -msgid "Correct. Avoid using \"forwards.\"" -msgstr "適切です。「forwards」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:129 -msgid "Gigabyte (GB)" -msgstr "Gigabyte (GB)" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:130 -msgid "2 to the 30th power (1,073,741,824) bytes. One gigabyte is equal to 1,024 megabytes. Gigabyte is often abbreviated as G or GB." -msgstr "2 の 30乗 (1,073,741,824) バイト。1 ギガバイトは 1,024 メガバイトに相当します。ギガバイトは、G または GB と略されることがよくあります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:133 -msgid "Got" -msgstr "Got" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:134 -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:208 -msgid "Avoid. Use \"must\" instead." -msgstr "使用しないようにしてください。代わりに \"must\" を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:137 -msgid "High-availability" -msgstr "High-availability" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:138 -msgid "Correct. Do not use \"high availability.\"" -msgstr "適切です。「hight availability」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:141 -msgid "Highly available" -msgstr "Highly available" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:142 -msgid "Correct. Do not use highly-available.\"" -msgstr "適切です。高可用性は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:145 -msgid "Hostname" -msgstr "Hostname" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:146 -msgid "Correct. Do not use host name." -msgstr "適切です。ホスト名は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:149 -msgid "i.e." -msgstr "i.e." - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:150 -msgid "Spell it out: \"That is.\"" -msgstr "「That is」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:153 -msgid "Installer" -msgstr "Installer" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:154 -msgid "Avoid. Use \"installation program\" instead." -msgstr "使用しないでください。代わりに「installation program」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:157 -msgid "It's and its" -msgstr "It's および its" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:158 -msgid "\"It's\" is a contraction for \"it is;\" use \"it is\" instead of \"it's.\" Use \"its\" as a possessive pronoun (for example, \"the store is known for its low prices\")." -msgstr "「It's」は「it is」の短縮形です。「it's」ではなく「it is」を使用します。所有代名詞は「its」と使用します。たとえば「the store is known for its low prices」(この店は低価格で知られています) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:161 -msgid "Less" -msgstr "Less" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:162 -msgid "Less is used with singular nouns. For example \"View less details\" wouldn't be correct but \"View less detail\" works. Use fewer when you have plural nouns (things you can count)." -msgstr "Less は単数名詞で使用されます。たとえば、「View less details」は間違っていますが、「View less detail」は適切です。複数名詞 (数えられる物) には、「fewer」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:165 -msgid "Linux" -msgstr "Linux" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:166 -msgid "Correct. Do not use \"LINUX\" or \"linux\" unless referring to a command, such as \"To start Linux, type linux.\" Linux is a registered trademark of Linus Torvalds." -msgstr "適切です。コマンドを参照している場合 (たとえば「To start Linux, type linux」(Linux を起動する場合は、linux と入力します)) を除き、「LINUX」または「linux」を使用しないでください。Linux は、Linus Torvalds の登録商標です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:169 -msgid "Login" -msgstr "ログイン" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:170 -msgid "A noun used to refer to the login prompt, such as \"At the login prompt, enter your username.\"" -msgstr "ログインプロンプトを示すために使用している名詞です。たとえば、「At the login prompt, enter your username.」(ログインプロンプトでユーザー名を入力してください。) とします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:173 -msgid "Log in" -msgstr "Log in" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:174 -msgid "A verb used to refer to the act of logging in. Do not use \"login,\" \"loggin,\" \"logon,\" and other variants. For example, \"When starting your computer, you are requested to log in...\"" -msgstr "ログインの動作を参照するために使用される動詞です。「login」、「loggin」、「loggin」などの形は使用しないでください。たとえば、「When starting your computer, you are requested to log in...」(コンピューターを起動すると、ログインを要求されます...) と表示されます。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:177 -msgid "Log on" -msgstr "Log on" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:178 -msgid "To make a computer system or network recognize you so that you can begin a computer session. Most personal computers have no log-on procedure -- you just turn the machine on and begin working. For larger systems and networks, however, you usually need to enter a username and password before the computer system will allow you to execute programs." -msgstr "コンピューターセッションを開始できるように、コンピューターシステムまたはネットワークにユーザーを認識させることです。ほとんどのコンピューターにはログオン手順がありません。マシンの電源を入れれば動くためです。ただし、大規模システムやネットワークの場合には、通常、コンピュータシステムでプログラムを実行する前に、ユーザー名とパスワードを入力する必要があります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:181 -msgid "Lots of" -msgstr "Lots of" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:182 -msgid "Use \"Several\" or something equivalent instead." -msgstr "代わりに「several」などの単語を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:185 -msgid "Make sure" -msgstr "Make sure" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:186 -msgid "This means \"be careful to remember, attend to, or find out something.\" For example, \"...make sure that the rhedk group is listed in the output.\" Try to use verify or ensure instead." -msgstr "これは、「何かを覚えたり、注意したり、見つけたりするように注意する」という意味です。たとえば、「...make sure that the rhedk group is listed in the output.」(rhedk グループが出力の一覧に含まれていることを確認してください) となります。代わりに verify や ensure を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:190 -msgid "Manual/man page" -msgstr "Manual/man page" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:191 -msgid "Correct. Two words. Do not use \"manpage\"" -msgstr "適切です。2 つの単語になります。「manpage」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:194 -msgid "MB" -msgstr "MB" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:195 -msgid "When spelled MB, short for megabyte (1,000,000 or 1,048,576 bytes, depending on the context)." -msgstr "MB は、メガバイト (状況に応じて 1,000,000 バイトまたは 1,048,576 バイト) の略語です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:196 -msgid "When spelled Mb, short for megabit." -msgstr "Mb は、メガビットの略語です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:199 -msgid "MBps" -msgstr "MBps" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:200 -msgid "Short for megabytes per second, a measure of data transfer speed. Mass storage devices are generally measured in MBps." -msgstr "1 秒あたりのメガバイトの略語で、データ転送速度の測定単位です。通常、大容量ストレージデバイスは、MBps で表されます。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:203 -msgid "MySQL" -msgstr "MySQL" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:204 -msgid "Common open source database server and client package. Do not use \"MYSQL\" or \"mySQL.\"" -msgstr "一般的なオープンソースデータベースサーバーおよびクライアントパッケージです。「MYSQL」または「mySQL」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:207 -msgid "Need to" -msgstr "Need to" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:211 -msgid "Read-only" -msgstr "Read-only" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:212 -msgid "Correct. Use when referring to the access permissions of files or directories." -msgstr "適切です。ファイルまたはディレクトリーのアクセスパーミッションを参照する場合に使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:215 -msgid "Real time/real-time" -msgstr "Real time/real-time" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:216 -msgid "Depends. If used as a noun, it is the actual time during which something takes place. For example, \"The computer may partly analyze the data in real time (as it comes in) -- R. H. March.\" If used as an adjective, \"real-time\" is appropriate. For example, \"XEmacs is a self-documenting, customizable, extensible, real-time display editor.\"" -msgstr "状況によって異なります。名詞として使用する場合は、それは何かが行われる実際の時間になります。たとえば、「The computer may partly analyze the data in real time (as it comes in) -- R. H. March」(コンピューターはデータをリアルタイムで部分的に分析する場合があります。(R. H.マーチ)) となります。形容詞として使用する場合は、「real-time」が適切です。たとえば、「XEmacs is a self-documenting, customizable, extensible, real-time display editor.」(XEmacs は、自己文書化を行う、カスタマイズ可能で、拡張可能な、リアルタイムディスプレイエディターです) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:219 -msgid "Refer to" -msgstr "Refer to" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:220 -msgid "Use to indicate a reference (within a manual or website) or a cross-reference (to another manual or documentation source)." -msgstr "参照 (マニュアルまたは Web サイト内) または相互参照 (別のマニュアルまたはドキュメントソース) を示すために使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:223 -msgid "See" -msgstr "See" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:224 -msgid "Don't use. Use \"Refer to\" instead." -msgstr "使用しないでください。代わりに「Refer to」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:227 -msgid "Since" -msgstr "Since" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:228 -msgid "This is often used to mean \"because\", but \"since\" has connotations of time, so be careful. If you mean \"because\", say \"because\"." -msgstr "この単語は「原因」を意味するためによく使用されますが、「since」には時間の意味合いがあるため、注意してください。「原因」を意味する場合は、「because」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:231 -msgid "Tells" -msgstr "Tells" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:232 -msgid "Use \"Instructs\" instead." -msgstr "代わりに「instructs」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:235 -msgid "That/which" -msgstr "That/which" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:236 -msgid "\"That\" introduces a restrictive clause-a clause that must be there for the sentence to make sense. A restrictive clause often defines the noun or phrase preceding it. \"Which\" introduces a non-restrictive, parenthetical clause-a clause that could be omitted without affecting the meaning of the sentence. For example: The car was travelling at a speed that would endanger lives. The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk. Use \"who\" or \"whom,\" rather than \"that\" or \"which,\" when referring to a person." -msgstr "「That」は、制限的関係詞節を導入します。これは、文が意味をなすために必要な節です。制限的関係詞節は、多くの場合、その前にある名詞または句を定義します。「Which」は、非制限の、括弧で囲まれた節を導入します。つまり、文の意味に影響を与えずに省略することができる節です。たとえば、「The car was travelling at a speed that would endanger lives.」(人命を危険にさらす速度で車が走行していました。) と、「The car, which was traveling at a speed that would endanger lives, swerved onto the sidewalk.」(人命を危険にさらす速度で走行していた車が歩道にのり上げました) です。人を指す場合は、「that」または「which」ではなく「who」または「whom」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:239 -msgid "Then/than" -msgstr "Then/than" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:240 -msgid "\"Then\" refers to a time in the past or the next step in a sequence. \"Than\" is used for comparisons." -msgstr "「then」は、ひと続きのものの中から、シーケンスの過去のステップまたは次のステップの時間を指します。比較には「than」が使用されます。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:245 -msgid "Third-party" -msgstr "Third-party" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:246 -msgid "Correct. Do not use \"third party\"." -msgstr "適切です。「third party」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:249 -msgid "Troubleshoot" -msgstr "Troubleshoot" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:250 -msgid "Correct. Do not use \"trouble shoot\" or \"trouble-shoot.\" To isolate the source of a problem and fix it. In the case of computer systems, the term troubleshoot is usually used when the problem is suspected to be hardware -related. If the problem is known to be in software, the term debug is more commonly used." -msgstr "適切です。「trouble shoot」または「trouble-shoot」は使用しないでください。問題の原因を特定して修正するためのものです。コンピューターシステムの場合は、通常、問題がハードウェアに関連するものと考えられる場合に使用されます。問題がソフトウェアにあることが分かっている場合に、より一般的に使用されるのは「debug」です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:253 -msgid "UK" -msgstr "UK" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:254 -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:266 -msgid "Correct as is, no periods." -msgstr "このとおりに使用します。ピリオドは付けません。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:257 -msgid "UNIX®" -msgstr "UNIX®" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:258 -msgid "Correct. Do not use \"Unix\" or \"unix.\" UNIX® is a registered trademark of The Open Group." -msgstr "適切です。「Unix」または「unix」は使用しないでください。UNIX® は、The Open Group の登録商標です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:261 -msgid "Unset" -msgstr "Unset" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:262 -msgid "Don't use. Use Clear." -msgstr "使用しないでください。「Clear」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:265 -msgid "US" -msgstr "US" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:269 -msgid "User" -msgstr "ユーザー" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:270 -msgid "When referring to the reader, use \"you\" instead of \"user.\" For example, \"The user must...\" is incorrect. Use \"You must...\" instead. If referring to more than one user, calling the collection \"users\" is acceptable, such as \"Other users may wish to access your database.\"" -msgstr "読み手を示す場合は、「user」ではなく「you」を使用します。たとえば、「The user must...」は正しくありません。代わりに「You must...」を使用してください。複数のユーザーを示す場合は、「users」を使用できます。たとえば、「Other users may to access your database.」(その他のユーザーがデータベースにアクセスすることを望む可能性があります) です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:273 -msgid "Username" -msgstr "ユーザー名" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:274 -msgid "Correct. Do not use \"user name.\"" -msgstr "適切です。「user name」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:277 -msgid "View" -msgstr "View" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:278 -msgid "When using as a reference (\"View the documentation available online.\"), do not use View. Use \"Refer to\" instead." -msgstr "参照として使用する場合、たとえば「View the documentation available online.」(オンラインで使用可能なドキュメントを参照してください) とする場合は、「view」を使用しないでください。代わりに「refer to」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:281 -msgid "Within" -msgstr "Within" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:282 -msgid "Don't use to refer to a file that exists in a directory. Use \"In\"." -msgstr "ディレクトリーにあるファイルを参照する場合は使用しないでください。「In」を使用してください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:285 -msgid "World Wide Web" -msgstr "World Wide Web" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:286 -msgid "Correct. Capitalize each word. Abbreviate as \"WWW\" or \"Web.\"" -msgstr "適切です。各単語を大文字にします。省略形は「WWW」または「Web」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:289 -msgid "Webpage" -msgstr "Webpage" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:290 -msgid "Correct. Do not use \"web page\" or \"Web page.\"" -msgstr "適切です。「web page」または「Web page」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:293 -msgid "Web server" -msgstr "Web server" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:294 -msgid "Correct. Do not use \"webserver\". For example, \"The Apache HTTP Server is the default Web server...\"" -msgstr "適切です。「webserver」は使用しないでください。たとえば、「The Apache HTTP Server is the default Web server...」(Apache HTTP サーバーはデフォルトの Web サーバー...) です。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:297 -msgid "Website" -msgstr "Web サイト" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:298 -msgid "Correct. Do not use \"web site\" or \"Web site.\" For example, \"The Ansible website contains ...\"" -msgstr "適切です。「web site」または「Web site」は使用しないでください。たとえば、「The Ansible website contains ...」(Ansible web サイトに...含まれます) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:301 -msgid "Who/whom" -msgstr "Who/whom" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:302 -msgid "Use the pronoun \"who\" as a subject. Use the pronoun \"whom\" as a direct object, an indirect object, or the object of a preposition. For example: Who owns this? To whom does this belong?" -msgstr "主語には、代名詞「who」を使用します。直接目的語、間接目的語、または前置詞の目的語には、代名詞の目的格「whom」を使用します。たとえば、「Who owns this?」(これは誰が所有していますか?) や、「To whom does this belong?」(これは誰のものですか?) となります。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:305 -msgid "Will" -msgstr "Will" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:306 -msgid "Do not use future tense unless it is absolutely necessary. For instance, do not use the sentence, \"The next section will describe the process in more detail.\" Instead, use the sentence, \"The next section describes the process in more detail.\"" -msgstr "絶対に必要な場合を除いて、未来時制は使用しないでください。たとえば、「The next section will describe the process in more detail.」(次のセクションでプロセスを詳しく説明します) ではなく、「The next section describes the process in more detail.」とします。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:309 -msgid "Wish" -msgstr "Wish" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:310 -msgid "Use \"need\" instead of \"desire\" and \"wish.\" Use \"want\" when the reader's actions are optional (that is, they may not \"need\" something but may still \"want\" something)." -msgstr "「desire」および「wish」の代わりに「need」を使用します。読者の操作が任意の場合 (つまり、何かを「必要」とはしないかもしれないけど、それでも何かを「望んでいる」可能性がある場合) は「want」を使用します。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:313 -msgid "x86" -msgstr "x86" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:314 -msgid "Correct. Do not capitalize the \"x.\"" -msgstr "適切です。「x」は大文字にしないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:317 -msgid "x86_64" -msgstr "x86_64" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:318 -msgid "Do not use. Do not use \"Hammer\". Always use \"AMD64 and Intel® EM64T\" when referring to this architecture." -msgstr "「Hammer」を使用しないでください。このアーキテクチャーを参照する場合は必ず「AMD64 and Intel® EM64T」としてください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:321 -msgid "You" -msgstr "You" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:322 -msgid "Correct. Do not use \"I,\" \"he,\" or \"she.\"" -msgstr "適切です。「I」、「he」、「she」は使用しないでください。" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:325 -msgid "You may" -msgstr "You may" - -#: ../../rst/dev_guide/style_guide/spelling_word_choice.rst:326 -msgid "Try to avoid using this. For example, \"you may\" can be eliminated from this sentence \"You may double-click on the desktop...\"" -msgstr "この表現は使用しないようにしてください。たとえば、「You may double-click on the desktop...」(あなたはデスクトップ上でダブルクリックすることができます...) という意味の文からは「you may」を省くことができます。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:3 -msgid "Trademark Usage" -msgstr "商標の使用方法" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:4 -msgid "Why is it important to use the TM, SM, and ® for our registered marks?" -msgstr "登録商標に TM、SM、および ® を使用することが重要な理由" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:6 -msgid "Before a trademark is registered with the United States Patent and Trademark Office it is appropriate to use the TM or SM symbol depending whether the product is for goods or services. It is important to use the TM or SM as it is notification to the public that Ansible claims rights to the mark even though it has not yet been registered." -msgstr "商標が米国特許商標局に登録される前に、TM または SM のどちらの記号を使用するのが適切かは、製品が商品用かサービス用かによって異なります。Ansible がそのマークに対する権利を主張していることを公に通知するために、商標が登録される前から TM または SM を使用することが重要です。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:8 -msgid "Once the trademark is registered, it is appropriate to use the symbol in place of the TM or SM. The symbol designation must be used in conjunction with the trademark if Ansible is to fully protect its rights. If we don't protect these marks, we run the risk of losing them in the way of Aspirin or Trampoline or Escalator." -msgstr "商標が登録されたら、TM または SM の代わりにシンボルを使用することが適切です。Ansible がその権利を完全に保護する場合は、シンボルと商標を組み合わせて使用する必要があります。これらのマークを保護しないと、アスピリン、トランポリン、エスカレーターなどのように、権利を失う場合があります。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:11 -msgid "General Rules:" -msgstr "一般的なルール:" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:13 -msgid "Trademarks should be used on 1st references on a page or within a section." -msgstr "商標は、ページ内またはセクション内で最初に参照する際に使用する必要があります。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:15 -msgid "Use Red Hat® Ansible® Automation Platform or Ansible®, on first reference when referring to products." -msgstr "製品を示す最初の参照では、Red Hat® Ansible® Automation Platform or Ansible® または Ansible® を使用します。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:17 -msgid "Use \"Ansible\" alone as the company name, as in \"Ansible announced quarterly results,\" which is not marked." -msgstr "「Ansible」を会社名として使用する場合は、「Ansible announced quarterly results」(Ansible 四半期決算発表) のように、マークを付けずに使用します。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:19 -msgid "Also add the trademark disclaimer. * When using Ansible trademarks in the body of written text, you should use the following credit line in a prominent place, usually a footnote." -msgstr "商標の免責事項も追加します。* 文章の本文に Ansible 商標を使用する場合は、目立つ場所、通常は脚注に次のような行を追加する必要があります。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:22 -msgid "For Registered Trademarks: - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries." -msgstr "登録商標の場合 - [Name of Trademark] is a registered trademark of Red Hat, Inc. in the United States and other countries." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:25 -msgid "For Unregistered Trademarks (TMs/SMs): - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." -msgstr "非登録商標の場合 (TM/SM): - [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:28 -msgid "For registered and unregistered trademarks: - [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." -msgstr "登録商標および未登録商標の場合: [Name of Trademark] is a registered trademark and [Name of Trademark] is a trademark of Red Hat, Inc. in the United States and other countries." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:32 -msgid "Guidelines for the proper use of trademarks:" -msgstr "商標を適切な使用するためのガイドライン:" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:34 -msgid "Always distinguish trademarks from surround text with at least initial capital letters or in all capital letters." -msgstr "商標を、周囲のテキストと区別するために、少なくとも頭文字を大文字にするか、すべての文字を大文字にします。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:36 -msgid "Always use proper trademark form and spelling." -msgstr "常に適切な商標の形式とスペルを使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:38 -msgid "Never use a trademark as a noun. Always use a trademark as an adjective modifying the noun." -msgstr "商標は、動詞として使用しないでください。商標は、常に名詞を修飾する形容詞として使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:40 -msgid "Correct: Red Hat® Ansible® Automation Platform system performance is incredible." -msgstr "正しい使用方法: 「Red Hat® Ansible® Automation Platform system performance is incredible. (Red Hat® Ansible® Automation Platform システムのパフォーマンスは驚異的です)」" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:43 -msgid "Incorrect: Ansible's performance is incredible." -msgstr "誤った使用方法: 「Ansible's performance is incredible. (Ansible のパフォーマンスは脅威的です)」" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:46 -msgid "Never use a trademark as a verb. Trademarks are products or services, never actions." -msgstr "商標は、動詞として使用しないでください。商標は製品またはサービスであり、動作ではありません。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:48 -msgid "Correct: \"Orchestrate your entire network using Red Hat® Ansible® Automation Platform.\"" -msgstr "正しい使用方法: 「Orchestrate your entire network using Red Hat® Ansible® Automation Platform. (Red Hat® Ansible® Automation Platform を使用してネットワーク全体を調整します)」" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:51 -msgid "Incorrect: \"Ansible your entire network.\"" -msgstr "誤った使用方法: Ansible your entire network." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:54 -msgid "Never modify a trademark to a plural form. Instead, change the generic word from the singular to the plural." -msgstr "商標を複数形に変更しないでください。代わりに、一般的な単語を単数形から複数形に変更します。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:56 -msgid "Correct: \"Corporate demand for Red Hat® Ansible® Automation Platform software is surging.\"" -msgstr "正しい使用方法: 「Corporate demand for Red Hat® Ansible® Automation Platform software is surging. (Red Hat® Ansible® Automation Platform ソフトウェアに対する企業の需要が急増しています)」" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:59 -msgid "Incorrect: \"Corporate demand for Ansible is surging.\"" -msgstr "誤った使用方法: Corporate demand for Ansible is surging." - -#: ../../rst/dev_guide/style_guide/trademarks.rst:62 -msgid "Never modify a trademark from its possessive form, or make a trademark possessive. Always use it in the form it has been registered." -msgstr "商標を所有格から変更したり、商標を所有格にしたりしないでください。必ず登録した形を使用してください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:64 -msgid "Never translate a trademark into another language." -msgstr "商標を別の言語に翻訳しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:66 -msgid "Never use trademarks to coin new words or names." -msgstr "商標を使用して新しい単語や名前を作成しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:68 -msgid "Never use trademarks to create a play on words." -msgstr "商標を使用して言葉遊びを作成しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:70 -msgid "Never alter a trademark in any way including through unapproved fonts or visual identifiers." -msgstr "未承認のフォントや視覚的な識別子など、いかなる方法でも商標を変更しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:72 -msgid "Never abbreviate or use any Ansible trademarks as an acronym." -msgstr "Ansible の商標を省略したり、頭文字だけ使用しないでください。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:75 -msgid "The importance of Ansible trademarks" -msgstr "Ansible 商標の重要性" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:77 -msgid "The Ansible trademark and the \"A\" logo in a shaded circle are our most valuable assets. The value of these trademarks encompass the Ansible Brand. Effective trademark use is more than just a name, it defines the level of quality the customer will receive and it ties a product or service to a corporate image. A trademark may serve as the basis for many of our everyday decisions and choices. The Ansible Brand is about how we treat customers and each other. In order to continue to build a stronger more valuable Brand we must use it in a clear and consistent manner." -msgstr "Ansible の商標と、斜線で囲まれた「A」のロゴは、当社の最も価値のある資産です。これらの商標の価値は、Ansible ブランドを包括するものです。効果的な商標の使用は、単なる名前ではなく、お客様が受け取る品質レベルを定義し、製品やサービスを企業イメージに結びつけるものです。商標は、私たちの日常的な意思決定や選択の多くの基礎となるものです。Ansible ブランドは、私たちがお客様と互いにどのように接するかということです。より強力で価値のあるブランドを構築し続けるためには、明確で一貫した方法で使用しなければなりません。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:79 -msgid "The mark consists of the letter \"A\" in a shaded circle. As of 5/11/15, this was a pending trademark (registration in process)." -msgstr "このマークは、影付きの円で囲まれた文字「A」で構成されています。2015 年 5 月 11 日の時点で、この商標は係属中 (登録手続き中) でした。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:82 -msgid "Common Ansible Trademarks" -msgstr "一般的な Ansible の商標" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:83 -msgid "Ansible®" -msgstr "Ansible®" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:86 -msgid "Other Common Trademarks and Resource Sites:" -msgstr "その他の一般的な商標およびリソースのサイト:" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:87 -msgid "Linux is a registered trademark of Linus Torvalds." -msgstr "Linux は、Linus Torvalds の登録商標です。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:88 -msgid "UNIX® is a registered trademark of The Open Group." -msgstr "UNIX® は、The Open Group の登録商標です。" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:89 -msgid "Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx" -msgstr "Microsoft, Windows, Vista, XP, and NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:90 -msgid "Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html" -msgstr "Apple, Mac, Mac OS, Macintosh, Pages and TrueType are either registered trademarks or trademarks of Apple Computer, Inc. in the United States and/or other countries. https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:91 -msgid "Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html" -msgstr "Adobe, Acrobat, GoLive, InDesign, Illustrator, PostScript , PhotoShop and the OpenType logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. https://www.adobe.com/legal/permissions/trademarks.html" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:92 -msgid "Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html" -msgstr "Macromedia and Macromedia Flash are trademarks of Macromedia, Inc. https://www.adobe.com/legal/permissions/trademarks.html" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:93 -msgid "IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml" -msgstr "IBM is a registered trademark of International Business Machines Corporation. https://www.ibm.com/legal/us/en/copytrade.shtml" - -#: ../../rst/dev_guide/style_guide/trademarks.rst:94 -msgid "Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html" -msgstr "Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, Intel Core, Intel Inside, Intel Inside logo, Itanium, Itanium Inside, Pentium, Pentium Inside,VTune, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. https://www.intel.com/content/www/us/en/legal/trademarks.html" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:3 -msgid "Voice Style" -msgstr "態のスタイル" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:4 -msgid "The essence of the Ansible writing style is short sentences that flow naturally together. Mix up sentence structures. Vary sentence subjects. Address the reader directly. Ask a question. And when the reader adjusts to the pace of shorter sentences, write a longer one." -msgstr "Ansible ライティングスタイルの特長は、自然に一緒に流れる短い文です。文法構造は混在させます。文の主題を変化させます。読者に直接話しかけます。質問します。読者が短い文章のペースに順応したら、長い文章を書いてください。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:6 -msgid "Write how real people speak..." -msgstr "実際のユーザーが話すように記述します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:7 -msgid "...but try to avoid slang and colloquialisms that might not translate well into other languages." -msgstr "ただし、他言語に適切に翻訳できない可能性のある俗語や口語表現は避けるようにしてください。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:8 -msgid "Say big things with small words." -msgstr "小さなことばで大きなことを説明します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:9 -msgid "Be direct. Tell the reader exactly what you want them to do." -msgstr "直接的な表現を使用してください。読み手が実行する必要がある内容を正確に指示します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:10 -msgid "Be honest." -msgstr "誠実に表現します。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:11 -msgid "Short sentences show confidence." -msgstr "短い文章は自信を示しています。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:12 -msgid "Grammar rules are meant to be bent, but only if the reader knows you are doing this." -msgstr "文法規則は、それは読者が何を説明しているかを理解している場合に限り組み込まれることが意図されています。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:13 -msgid "Choose words with fewer syllables for faster reading and better understanding." -msgstr "読みやすく、理解を深めるために、音節が少ない単語を選んでください。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:14 -msgid "Think of copy as one-on-one conversations rather than as a speech. It's more difficult to ignore someone who is speaking to you directly." -msgstr "コピーは、聴衆に対するスピーチではなく、1 対 1 の対話と考えてください。直接話しかけている人を無視するのはより困難です。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:15 -msgid "When possible, start task-oriented sentences (those that direct a user to do something) with action words. For example: Find software... Contact support... Install the media.... and so forth." -msgstr "可能な場合は、タスク指向の文章 (ユーザーによる作業を指示する項目) は、動作を示す用語で開始します。たとえば、「Find software...」、「Contact support...」、「Install the media...」などです。" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:18 -msgid "Active Voice" -msgstr "能動態" - -#: ../../rst/dev_guide/style_guide/voice_style.rst:19 -msgid "Use the active voice (\"Start Linuxconf by typing...\") rather than passive (\"Linuxconf can be started by typing...\") whenever possible. Active voice makes for more lively, interesting reading. Also avoid future tense (or using the term \"will\") whenever possible For example, future tense (\"The screen will display...\") does not read as well as an active voice (\"The screen displays\"). Remember, the users you are writing for most often refer to the documentation while they are using the system, not after or in advance of using the system." -msgstr "可能な限り、受動態 (「Linuxconf can be started by typing...」) ではなく、能動態 (「Start Linuxconf by typing...」) を使用してください。能動態の方がより生き生きとした、注意を引き付ける文章になります。また、未来形 (または「will」の使用) は可能な限り使用しないでください。たとえば、未来形 (「The screen will display...」) と能動態 (「The screen displays」) では、ニュアンスが異なります。読者は、システムの使用前または使用後ではなく、システムの使用中にドキュメントを参照することがほとんどであることに注意してください。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:4 -msgid "Why Use a Style Guide?" -msgstr "スタイルガイドを使用する理由" - -#: ../../rst/dev_guide/style_guide/why_use.rst:6 -msgid "Style guides are important because they ensure consistency in the content, look, and feel of a book or a website." -msgstr "スタイルガイドは、ドキュメントまたは Web サイトのコンテンツおよびルックアンドフィールの一貫性を確保するために重要です。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:8 -msgid "Remember, a style guide is only useful if it is used, updated, and enforced. Style Guides are useful for engineering-related documentation, sales and marketing materials, support docs, community contributions, and more." -msgstr "スタイルガイドは、使用、更新、および実施される場合にのみ役立つことに注意してください。スタイルガイドは、エンジニアリング関連のドキュメント、営業およびマーケティング用資料、サポートドキュメント、コミュニティーへの貢献などに役立ちます。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:10 -msgid "As changes are made to the overall Ansible site design, be sure to update this style guide with those changes. Or, should other resources listed below have major revisions, consider including company information here for ease of reference." -msgstr "Ansible サイトのデザイン全体に変更が加えられた場合は、その変更に合わせて本スタイルガイドも更新してください。または、以下に記載されているその他の資料に大幅な改訂がある場合は、参照しやすいようにここに会社情報を含めることを検討してください。" - -#: ../../rst/dev_guide/style_guide/why_use.rst:12 -msgid "This style guide incorporates current Ansible resources and information so that overall site and documentation consistency can be met." -msgstr "このスタイルガイドには、現在の Ansible リソースと情報が組み込まれているため、サイトとドキュメント全体の一貫性を保つことができます。" - -#: ../../rst/dev_guide/testing.rst:5 -msgid "Testing Ansible" -msgstr "Ansible のテスト" - -#: ../../rst/dev_guide/testing.rst:12 -msgid "Why test your Ansible contributions?" -msgstr "Ansible への貢献をテストする理由" - -#: ../../rst/dev_guide/testing.rst:14 -msgid "If you're a developer, one of the most valuable things you can do is to look at GitHub issues and help fix bugs, since bug-fixing is almost always prioritized over feature development. Even for non-developers, helping to test pull requests for bug fixes and features is still immensely valuable." -msgstr "開発者にとって、最も価値のあることの 1 つが、GitHub の問題を確認し、バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。開発者ではなくても、バグの修正や機能のプル要求のテストを手伝うことは非常に価値のあることです。" - -#: ../../rst/dev_guide/testing.rst:16 -msgid "Ansible users who understand how to write playbooks and roles should be able to test their work. GitHub pull requests will automatically run a variety of tests (for example, Azure Pipelines) that show bugs in action. However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged." -msgstr "Ansible ユーザーは、Playbook とロールの作成方法を理解していれば、自身が作成した作業をテストできるはずです。GitHub プル要求は、バグの動作を示すさまざまなテスト (Azure Pipeline など) を自動的に実行します。ただし、貢献者は、自動化された GitHub チェック以外でも自身の作業をテストし、その証拠を PR で示すと、その作業がレビューされてマージされる可能性が高くなります。" - -#: ../../rst/dev_guide/testing.rst:18 -msgid "Read on to learn how Ansible is tested, how to test your contributions locally, and how to extend testing capabilities." -msgstr "Ansible のテスト方法、貢献をローカルでテストする方法、およびテスト機能を拡張する方法を説明します。" - -#: ../../rst/dev_guide/testing.rst:20 -msgid "If you want to learn about testing collections, read :ref:`testing_collections`" -msgstr "コレクションのテストを確認する場合は、「:ref:`testing_collections`」を参照してください。" - -#: ../../rst/dev_guide/testing.rst:25 -msgid "Types of tests" -msgstr "テストの種類" - -#: ../../rst/dev_guide/testing.rst:27 -msgid "At a high level we have the following classifications of tests:" -msgstr "テストは、大きく分けて以下のように分類されます。" - -#: ../../rst/dev_guide/testing.rst -msgid "sanity" -msgstr "健全性" - -#: ../../rst/dev_guide/testing.rst:30 -msgid ":ref:`testing_sanity`" -msgstr ":ref:`testing_sanity`" - -#: ../../rst/dev_guide/testing.rst:31 -msgid "Sanity tests are made up of scripts and tools used to perform static code analysis." -msgstr "健全性テストは、静的コード分析の実行に使用されるスクリプトおよびツールで構成されています。" - -#: ../../rst/dev_guide/testing.rst:32 -msgid "The primary purpose of these tests is to enforce Ansible coding standards and requirements." -msgstr "これらのテストの主な目的は、Ansible コーディングの仕様および要件を適用することです。" - -#: ../../rst/dev_guide/testing.rst -msgid "integration" -msgstr "統合" - -#: ../../rst/dev_guide/testing.rst:34 -msgid ":ref:`testing_integration`" -msgstr ":ref:`testing_integration`" - -#: ../../rst/dev_guide/testing.rst:35 -msgid "Functional tests of modules and Ansible core functionality." -msgstr "モジュールおよび Ansible コア機能の機能テスト" - -#: ../../rst/dev_guide/testing.rst -msgid "units" -msgstr "ユニット" - -#: ../../rst/dev_guide/testing.rst:37 -#: ../../rst/dev_guide/testing_units_modules.rst:567 -msgid ":ref:`testing_units`" -msgstr ":ref:`testing_units`" - -#: ../../rst/dev_guide/testing.rst:38 -msgid "Tests directly against individual parts of the code base." -msgstr "コードベースの個々の部分に対して直接テストを行います。" - -#: ../../rst/dev_guide/testing.rst:42 -msgid "Testing within GitHub & Azure Pipelines" -msgstr "GitHub および Azure Pipeline でのテスト" - -#: ../../rst/dev_guide/testing.rst:46 -msgid "Organization" -msgstr "組織" - -#: ../../rst/dev_guide/testing.rst:48 -msgid "When Pull Requests (PRs) are created they are tested using Azure Pipelines, a Continuous Integration (CI) tool. Results are shown at the end of every PR." -msgstr "プル要求 (PR: Pull Requests) が作成されると、継続的統合 (CI) ツールである Azure Pipeline を使用してテストが行われます。結果はすべての PR の最後に表示されます。" - -#: ../../rst/dev_guide/testing.rst:50 -msgid "When Azure Pipelines detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example:" -msgstr "Azure Pipeline がエラーを検出し、それが PR で変更されたファイルにリンクされると、関連する行が GitHub のコメントとして追加されます。たとえば、以下のようになります。" - -#: ../../rst/dev_guide/testing.rst:61 -msgid "From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Azure Pipelines, for example:" -msgstr "上記の例から、``--test pep8`` および ``--test validate-modules`` が問題を特定したことが分かります。指定されたコマンドを使用すると、同じテストをローカルで実行して、変更を GitHub にプッシュして Azure Pipeline を待つことなく、すべての問題を修正したことを確認できます。次に例を示します。" - -#: ../../rst/dev_guide/testing.rst:63 -msgid "If you haven't already got Ansible available, use the local checkout by running:" -msgstr "Ansible がまだ利用できるようになっていない場合は、ローカルでチェックアウトを実行してください。" - -#: ../../rst/dev_guide/testing.rst:69 -msgid "Then run the tests detailed in the GitHub comment:" -msgstr "次に、GitHub コメントで説明するテストを実行します。" - -#: ../../rst/dev_guide/testing.rst:76 -msgid "If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the \"Details\" button under the \"checks have failed\" message at the end of the PR." -msgstr "GitHub のコメントに何が失敗したかが書かれていない場合は、PR の末尾にある「checks have failed」というメッセージの下にある「Details」ボタンをクリックして結果を確認することができます。" - -#: ../../rst/dev_guide/testing.rst:79 -msgid "Rerunning a failing CI job" -msgstr "失敗した CI ジョブの再実行" - -#: ../../rst/dev_guide/testing.rst:81 -msgid "Occasionally you may find your PR fails due to a reason unrelated to your change. This could happen for several reasons, including:" -msgstr "時折、変更とは関係のない理由で PR が失敗することがあります。これには、以下のような理由が考えられます。" - -#: ../../rst/dev_guide/testing.rst:83 -msgid "a temporary issue accessing an external resource, such as a yum or git repo" -msgstr "yum や git リポジトリーなどの外部リソースにアクセスする際に一時的に問題が発生した場合。" - -#: ../../rst/dev_guide/testing.rst:84 -msgid "a timeout creating a virtual machine to run the tests on" -msgstr "テストを実行するための仮想マシンを作成するタイムアウト。" - -#: ../../rst/dev_guide/testing.rst:86 -msgid "If either of these issues appear to be the case, you can rerun the Azure Pipelines test by:" -msgstr "これらの問題のいずれかがケースとして表示される場合は、以下を実行して Azure Pipelines テストを再実行できます。" - -#: ../../rst/dev_guide/testing.rst:88 -msgid "adding a comment with ``/rebuild`` (full rebuild) or ``/rebuild_failed`` (rebuild only failed CI nodes) to the PR" -msgstr "``/rebuild`` (完全な再構築) または ``/rebuild_failed`` (構築に失敗した CI ノードのみの再構築) でのコメントを追加する" - -#: ../../rst/dev_guide/testing.rst:89 -msgid "closing and re-opening the PR (full rebuild)" -msgstr "PR を閉じて再度開く (完全な再構築)" - -#: ../../rst/dev_guide/testing.rst:90 -msgid "making another change to the PR and pushing to GitHub" -msgstr "PR に何らかの変更を加えて GitHub にプッシュする" - -#: ../../rst/dev_guide/testing.rst:92 -msgid "If the issue persists, please contact us in the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)." -msgstr "それでも問題が解決しない場合は、``#ansible-devel`` チャットチャンネルでお問い合わせください（ansible.imでMatrixを使用、または`irc.libera.chat `_でIRCを使用）。" - -#: ../../rst/dev_guide/testing.rst:96 -msgid "How to test a PR" -msgstr "PR をテストする方法" - -#: ../../rst/dev_guide/testing.rst:98 -msgid "Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well." -msgstr "理想的には、コードが機能することを証明するテストを追加することが推奨されます。特に、ユーザーがさまざまなプラットフォームにアクセスできない場合、または API や Web サービスを使用している場合は、これが必ずしも可能ではなく、テストも必ずしも包括的ではありません。このような場合は、シミュレーションされたインターフェースに対して実行される自動化よりも、実際の機器を使用したライブテストの方が有益となります。いずれにせよ、最初の段階でも常に手動でテストする必要があります。" - -#: ../../rst/dev_guide/testing.rst:100 -msgid "Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works." -msgstr "Ansible の動作を熟知していれば、Ansible のテストを手伝うことは非常に簡単です。" - -#: ../../rst/dev_guide/testing.rst:103 -msgid "Setup: Checking out a Pull Request" -msgstr "設定: プル要求のチェックアウト" - -#: ../../rst/dev_guide/testing.rst:105 -msgid "You can do this by:" -msgstr "これは、以下の方法で実行できます。" - -#: ../../rst/dev_guide/testing.rst:107 -msgid "checking out Ansible" -msgstr "Ansible のチェックアウト" - -#: ../../rst/dev_guide/testing.rst:108 -msgid "fetching the proposed changes into a test branch" -msgstr "提案された変更をテストブランチに取得" - -#: ../../rst/dev_guide/testing.rst:109 -msgid "testing" -msgstr "テスト" - -#: ../../rst/dev_guide/testing.rst:110 -msgid "commenting on that particular issue on GitHub" -msgstr "GitHub に特定の問題についてのコメント" - -#: ../../rst/dev_guide/testing.rst:112 -msgid "Here's how:" -msgstr "以下に、実行する方法を説明します。" - -#: ../../rst/dev_guide/testing.rst:115 -msgid "Testing source code from GitHub pull requests sent to us does have some inherent risk, as the source code sent may have mistakes or malicious code that could have a negative impact on your system. We recommend doing all testing on a virtual machine, whether a cloud instance, or locally. Some users like Vagrant or Docker for this, but they are optional. It is also useful to have virtual machines of different Linux or other flavors, since some features (for example, package managers such as apt or yum) are specific to those OS versions." -msgstr "GitHub のプル要求から送られてきたソースコードをテストすることにはリスクが伴います。送られてきたソースコードには、間違いや悪意のあるコードが含まれていて、システムに影響を及ぼす可能性があるからです。すべてのテストは、仮想マシン上で行うことが推奨されます。クラウドインスタンスでもローカルでもかまいません。このために Vagrant や Docker を好むユーザーもいますが、これらは任意です。また、いくつかの機能 (たとえば、apt や yum などのパッケージマネージャー) は、それらの OS バージョンに固有のものであるため、異なる Linux やその他のフレーバーの仮想マシンを用意しておくと便利です。" - -#: ../../rst/dev_guide/testing.rst:122 -msgid "Create a fresh area to work:" -msgstr "作業用に新しい領域を作成します。" - -#: ../../rst/dev_guide/testing.rst:129 -msgid "Next, find the pull request you'd like to test and make note of its number. It will look something like this:" -msgstr "次に、テストするプル要求を見つけて、その番号を書き留めます。次のようになります。" - -#: ../../rst/dev_guide/testing.rst:135 -msgid "Only test ``ansible:devel``" -msgstr "``ansible:devel`` のみをテストします。" - -#: ../../rst/dev_guide/testing.rst:137 -msgid "It is important that the PR request target be ``ansible:devel``, as we do not accept pull requests into any other branch. Dot releases are cherry-picked manually by Ansible staff." -msgstr "他のブランチへのプル要求は使用できないため、PR 要求のターゲットは ``ansible:devel`` にすることが重要です。ドットリリースは、Ansible のスタッフが入念に選択しています。" - -#: ../../rst/dev_guide/testing.rst:139 -msgid "Use the pull request number when you fetch the proposed changes and create your branch for testing:" -msgstr "提案された変更を取得し、テスト用にブランチを作成するときにプル要求番号を使用します。" - -#: ../../rst/dev_guide/testing.rst:146 -msgid "The first command fetches the proposed changes from the pull request and creates a new branch named ``testing_PRXXXX``, where the XXXX is the actual number associated with the pull request (for example, 65381). The second command checks out the newly created branch." -msgstr "1 つ目のコマンドはプル要求から提案された変更を取得し、``testing_PRXXXX`` という名前の新規ブランチを作成します。XXXX はプル要求に関連する実際の番号 (例: 65381) です。2 つ目のコマンドは、新たに作成されたブランチをチェックアウトします。" - -#: ../../rst/dev_guide/testing.rst:149 -msgid "If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor." -msgstr "GitHub ユーザーインターフェースで、プル要求が正常にマージされないと示された場合は、マージの競合を解決しなければならないため、git およびコーディングにあまり精通していない場合は、続行しないことが推奨されます。これは、元のプル要求の投稿者の責任です。" - -#: ../../rst/dev_guide/testing.rst:152 -msgid "Some users do not create feature branches, which can cause problems when they have multiple, unrelated commits in their version of ``devel``. If the source looks like ``someuser:devel``, make sure there is only one commit listed on the pull request." -msgstr "一部のユーザーは機能ブランチを作成しないため、``devel`` のバージョンに関連性のないコミットが複数ある場合に、問題が発生する可能性があります。ソースが ``someuser:devel`` のように表示される場合は、プル要求に記載されているコミットが 1 つだけであることを確認してください。" - -#: ../../rst/dev_guide/testing.rst:154 -msgid "The Ansible source includes a script that allows you to use Ansible directly from source without requiring a full installation that is frequently used by developers on Ansible." -msgstr "Ansible のソースには、Ansible の開発者が頻繁に使用するフルインストールを必要とせず、ソースから直接 Ansible を使用するようにするスクリプトが含まれています。" - -#: ../../rst/dev_guide/testing.rst:157 -msgid "Simply source it (to use the Linux/Unix terminology) to begin using it immediately:" -msgstr "ソースを作成するだけ (Linux/Unix の用語を使用するために) で、すぐに使い始めることができます。" - -#: ../../rst/dev_guide/testing.rst:163 -msgid "This script modifies the ``PYTHONPATH`` environment variables (along with a few other things), which will be temporarily set as long as your shell session is open." -msgstr "このスクリプトは、``PYTHONPATH`` 環境変数を変更します (他にもいくつかあります)。これは、シェルセッションが開いている間は一時的に設定されます。" - -#: ../../rst/dev_guide/testing.rst:167 -msgid "Testing the Pull Request" -msgstr "プル要求のテスト" - -#: ../../rst/dev_guide/testing.rst:169 -msgid "At this point, you should be ready to begin testing!" -msgstr "この時点でテストを開始する準備が整いました。" - -#: ../../rst/dev_guide/testing.rst:171 -msgid "Some ideas of what to test are:" -msgstr "何をテストするかのアイデアをいくつか挙げてみましょう。" - -#: ../../rst/dev_guide/testing.rst:173 -msgid "Create a test Playbook with the examples in and check if they function correctly" -msgstr "例題を含むテスト Playbook を作成し、それらが正しく機能するかどうかを確認します。" - -#: ../../rst/dev_guide/testing.rst:174 -msgid "Test to see if any Python backtraces returned (that's a bug)" -msgstr "Python のバックトレースが返されているかどうかをテストします (これはバグです)。" - -#: ../../rst/dev_guide/testing.rst:175 -msgid "Test on different operating systems, or against different library versions" -msgstr "異なるオペレーティングシステムで、または異なるバージョンのライブラリーに対してテストを行います。" - -#: ../../rst/dev_guide/testing.rst:178 -msgid "Run sanity tests" -msgstr "健全性テストの実行" - -#: ../../rst/dev_guide/testing.rst:184 -msgid "More information: :ref:`testing_sanity`" -msgstr "詳細情報: :ref:`testing_sanity`" - -#: ../../rst/dev_guide/testing.rst:187 -msgid "Run unit tests" -msgstr "ユニットテストの実行" - -#: ../../rst/dev_guide/testing.rst:193 -msgid "More information: :ref:`testing_units`" -msgstr "詳細情報: :ref:`testing_units`" - -#: ../../rst/dev_guide/testing.rst:196 -msgid "Run integration tests" -msgstr "統合テストの実行" - -#: ../../rst/dev_guide/testing.rst:202 -msgid "More information: :ref:`testing_integration`" -msgstr "詳細情報: :ref:`testing_integration`" - -#: ../../rst/dev_guide/testing.rst:204 -msgid "Any potential issues should be added as comments on the pull request (and it's acceptable to comment if the feature works as well), remembering to include the output of ``ansible --version``" -msgstr "潜在的な問題があれば、プル要求にコメントを追加する必要があります (機能が正常に動作する場合もコメントしてもかまいません)。忘れずに ``ansible --version`` の出力を転載してください。" - -#: ../../rst/dev_guide/testing.rst:212 -msgid "If the PR does not resolve the issue, or if you see any failures from the unit/integration tests, just include that output instead:" -msgstr "PR が問題を解決しない場合や、ユニット/統合テストでエラーが発生した場合は、代わりにその出力を転載してください。" - -#: ../../rst/dev_guide/testing.rst -msgid "This change causes errors for me." -msgstr "この変更により、エラーが発生します。" - -#: ../../rst/dev_guide/testing.rst -msgid "When I ran this Ubuntu 16.04 it failed with the following:" -msgstr "When I ran this Ubuntu 16.04 it failed with the following:" - -#: ../../rst/dev_guide/testing.rst -msgid "\\```" -msgstr "\\```" - -#: ../../rst/dev_guide/testing.rst -msgid "some output" -msgstr "some output" - -#: ../../rst/dev_guide/testing.rst -msgid "StackTrace" -msgstr "StackTrace" - -#: ../../rst/dev_guide/testing.rst -msgid "some other output" -msgstr "some other output" - -#: ../../rst/dev_guide/testing.rst:225 -msgid "Code Coverage Online" -msgstr "オンラインのコードカバレージ" - -#: ../../rst/dev_guide/testing.rst:227 -msgid "`The online code coverage reports `_ are a good way to identify areas for testing improvement in Ansible. By following red colors you can drill down through the reports to find files which have no tests at all. Adding both integration and unit tests which show clearly how code should work, verify important Ansible functions and increase testing coverage in areas where there is none is a valuable way to help improve Ansible." -msgstr "`オンラインコードカバレージレポート `_ は、Ansible でテストが向上する領域を特定するのが適切な方法です。赤い色に従うことで、レポートを掘り下げて、テストがまったくないファイルを見つけることができます。コードがどのように機能するかを明確に示す統合テストとユニットテストの両方を追加し、重要な Ansible 関数を検証し、存在しない領域でテスト範囲を拡大することは、Ansible の改善に役立つ貴重な方法です。" - -#: ../../rst/dev_guide/testing.rst:234 -msgid "The code coverage reports only cover the ``devel`` branch of Ansible where new feature development takes place. Pull requests and new code will be missing from the codecov.io coverage reports so local reporting is needed. Most ``ansible-test`` commands allow you to collect code coverage, this is particularly useful to indicate where to extend testing. See :ref:`testing_running_locally` for more information." -msgstr "コードカバレッジレポートは、新しい機能開発が行われる Ansible の ``devel`` ブランチのみを対象とします。プル要求および新規コードは codecov.io のカバレッジレポートに含まれないため、ローカルレポートが必要になるようです。ほとんどの ``ansible-test`` コマンドでは、コードカバレッジを収集できます。これは、テストを拡張する場所を示すのに特に役に立ちます。詳細は、「:ref:`testing_running_locally`」を参照してください。" - -#: ../../rst/dev_guide/testing.rst:242 -msgid "Want to know more about testing?" -msgstr "テストに関する詳細情報" - -#: ../../rst/dev_guide/testing.rst:244 -msgid "If you'd like to know more about the plans for improving testing Ansible then why not join the `Testing Working Group `_." -msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`Testing Working Group `_ にご参加ください。" - -#: ../../rst/dev_guide/testing/sanity/action-plugin-docs.rst:2 -msgid "action-plugin-docs" -msgstr "action-plugin-docs" - -#: ../../rst/dev_guide/testing/sanity/action-plugin-docs.rst:4 -msgid "Each action plugin should have a matching module of the same name to provide documentation." -msgstr "各アクションプラグインには、ドキュメントを提供するモジュールと同じ名前のモジュールが必要です。" - -#: ../../rst/dev_guide/testing/sanity/ansible-doc.rst:2 -msgid "ansible-doc" -msgstr "ansible-doc" - -#: ../../rst/dev_guide/testing/sanity/ansible-doc.rst:4 -msgid "Verifies that ``ansible-doc`` can parse module documentation on all supported Python versions." -msgstr "``ansible-doc`` が、サポートされているすべての Python バージョンでモジュールドキュメントを解析できることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/ansible-requirements.rst:2 -msgid "ansible-requirements" -msgstr "ansible-requirements" - -#: ../../rst/dev_guide/testing/sanity/ansible-requirements.rst:4 -msgid "``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` must be an identical copy of ``requirements.txt`` found in the project's root." -msgstr "``test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt`` は、プロジェクトのルートにある ``requirements.txt`` と同じコピーである必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst:2 -msgid "ansible-test-future-boilerplate" -msgstr "ansible-test-future-boilerplate" - -#: ../../rst/dev_guide/testing/sanity/ansible-test-future-boilerplate.rst:4 -msgid "The ``_internal`` code for ``ansible-test`` requires the following ``__future__`` import:" -msgstr "``ansible-test`` の``_internal`` コードには、以下の``__future__`` のインポートが必要です。" - -#: ../../rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst:4 -msgid "ansible-var-precedence-check" -msgstr "ansible-var-precedence-check" - -#: ../../rst/dev_guide/testing/sanity/ansible-var-precedence-check.rst:6 -msgid "Check the order of precedence for Ansible variables against :ref:`ansible_variable_precedence`." -msgstr "「:ref:`ansible_variable_precedence`」で、Ansible 変数の優先順位の順序を確認します。" - -#: ../../rst/dev_guide/testing/sanity/azure-requirements.rst:4 -msgid "azure-requirements" -msgstr "azure-requirements" - -#: ../../rst/dev_guide/testing/sanity/azure-requirements.rst:6 -msgid "Update the Azure integration test requirements file when changes are made to the Azure packaging requirements file:" -msgstr "Azure パッケージ化の要件ファイルに変更が加えられたら、Azure 統合テスト要件ファイルを更新します。" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:2 -msgid "bin-symlinks" -msgstr "bin-symlinks" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:4 -msgid "The ``bin/`` directory in Ansible must contain only symbolic links to executable files. These files must reside in the ``lib/ansible/`` or ``test/lib/ansible_test/`` directories." -msgstr "Ansible の ``bin/`` ディレクトリーには、実行ファイルへのシンボリックリンクのみが含まれている必要があります。これらのファイルは、``lib/ansible/`` ディレクトリーまたは ``test/lib/ansible_test/`` ディレクトリーに置かれている必要があります。" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:7 -msgid "This is required to allow ``ansible-test`` to work with containers and remote hosts when running from an installed version of Ansible." -msgstr "これは、インストール済みバージョンの Ansible から実行する際に、``ansible-test`` がコンテナーおよびリモートホストで動作できるようにするために必要です。" - -#: ../../rst/dev_guide/testing/sanity/bin-symlinks.rst:9 -msgid "Symlinks for each entry point in ``bin/`` must also be present in ``test/lib/ansible_test/_util/target/injector/``. Each symlink should point to the ``python.py`` script in the same directory. This facilitates running with the correct Python interpreter and enabling code coverage." -msgstr "``bin/`` の各エントリーポイントのシンボリックリンクも ``test/lib/ansible_test/_util/target/injector/`` に存在する必要があります。それぞれのシンボリックリンクは同じディレクトリー内の ``python.py`` スクリプトを指定する必要があります。これにより、正しい Python インタープリターでの実行とコードのカバレッジの有効化が容易になります。" - -#: ../../rst/dev_guide/testing/sanity/boilerplate.rst:4 -msgid "boilerplate" -msgstr "boilerplate" - -#: ../../rst/dev_guide/testing/sanity/boilerplate.rst:6 -msgid "Most Python files should include the following boilerplate:" -msgstr "ほとんどの Python ファイルには以下の boilerplate が必要です。" - -#: ../../rst/dev_guide/testing/sanity/botmeta.rst:2 -msgid "botmeta" -msgstr "botmeta" - -#: ../../rst/dev_guide/testing/sanity/botmeta.rst:4 -msgid "Verifies that ``./github/BOTMETA.yml`` is valid." -msgstr "``./github/BOTMETA.yml`` が有効であることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:2 -msgid "changelog" -msgstr "changelog" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:4 -msgid "Basic linting of changelog fragments with `antsibull-changelog lint `_." -msgstr "`antsibull-changelog lint `_ を使用した changelog フラグメントの基本的な文法チェックです。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:6 -msgid "One or more of the following sections are required:" -msgstr "以下のセクションが 1 つ以上必要です。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:8 -msgid "major_changes" -msgstr "major_changes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:9 -msgid "minor_changes" -msgstr "minor_changes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:10 -msgid "breaking_changes" -msgstr "breaking_changes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:11 -msgid "deprecated_features" -msgstr "deprecated_features" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:12 -msgid "removed_features" -msgstr "removed_features" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:13 -msgid "security_fixes" -msgstr "security_fixes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:14 -msgid "bugfixes" -msgstr "bugfixes" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:15 -msgid "known_issues" -msgstr "known_issues" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:17 -msgid "New modules and plugins must not be included in changelog fragments." -msgstr "新しいモジュールおよびプラグインは、changelog フラグメントに含めることができません。" - -#: ../../rst/dev_guide/testing/sanity/changelog.rst:19 -msgid "See :ref:`collection_changelogs` for details." -msgstr "詳しくは、:ref:`collection_changelogs` を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:4 -msgid "compile" -msgstr "コンパイル" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:6 -msgid "All Python source files must successfully compile using all supported Python versions." -msgstr "すべての Python ソースファイルは、サポートされているすべての Python バージョンを使用して正常にコンパイルする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:10 -msgid "The list of supported Python versions is dependent on the version of ``ansible-core`` that you are using. Make sure you consult the version of the documentation which matches your ``ansible-core`` version." -msgstr "サポートされている Python バージョンのリストは、使用している ``ansible-core`` のバージョンにより異なります。使用している ``ansible-core`` バージョンと一致するバージョンのドキュメントを参照してください。" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:13 -msgid "Controller code, including plugins in Ansible Collections, must support the following Python versions:" -msgstr "Ansible コレクションのプラグインを含め、コントローラーコードは次の Python バージョンをサポートする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:15 -msgid "3.11" -msgstr "3.11" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:16 -msgid "3.10" -msgstr "3.10" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:17 -msgid "3.9" -msgstr "3.9" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:19 -msgid "Code which runs on targets (``modules`` and ``module_utils``) must support all controller supported Python versions, as well as the additional Python versions supported only on targets:" -msgstr "ターゲット上で実行されるコード (``modules`` と ``module_utils``) は、コントローラーでサポートされているすべての Python バージョンと、ターゲットでのみサポートされている追加の Python バージョンをサポートする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:22 -msgid "3.8" -msgstr "3.8" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:23 -msgid "3.7" -msgstr "3.7" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:24 -msgid "3.6" -msgstr "3.6" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:25 -msgid "3.5" -msgstr "3.5" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:26 -msgid "2.7" -msgstr "2.7" - -#: ../../rst/dev_guide/testing/sanity/compile.rst:30 -msgid "Ansible Collections can be `configured `_ to support a subset of the target-only Python versions." -msgstr "Ansible コレクションは、`configured `_ ターゲットのみの Python バージョンのサブセットをサポートします。" - -#: ../../rst/dev_guide/testing/sanity/configure-remoting-ps1.rst:2 -msgid "configure-remoting-ps1" -msgstr "configure-remoting-ps1" - -#: ../../rst/dev_guide/testing/sanity/configure-remoting-ps1.rst:4 -msgid "The file ``examples/scripts/ConfigureRemotingForAnsible.ps1`` is required and must be a regular file. It is used by external automated processes and cannot be moved, renamed or replaced with a symbolic link." -msgstr "``examples/scripts/ConfigureRemotingForAnsible.ps1`` ファイルは必須であり、通常のファイルである必要があります。これは外部の自動化プロセスによって使用され、移動したり、名前を変更したり、シンボリックリンクに置き換えたりすることはできません。" - -#: ../../rst/dev_guide/testing/sanity/deprecated-config.rst:4 -msgid "deprecated-config" -msgstr "非推奨の設定" - -#: ../../rst/dev_guide/testing/sanity/deprecated-config.rst:6 -msgid "``DOCUMENTATION`` config is scheduled for removal" -msgstr "``DOCUMENTATION`` 設定は削除される予定です。" - -#: ../../rst/dev_guide/testing/sanity/docs-build.rst:2 -msgid "docs-build" -msgstr "docs-build" - -#: ../../rst/dev_guide/testing/sanity/docs-build.rst:4 -msgid "Verifies that ``make singlehtmldocs`` in ``docs/docsite/`` completes without errors." -msgstr "``docs/docsite/`` の ``make singlehtmldocs`` が完了し、エラーがないことを確認します。" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:2 -msgid "empty-init" -msgstr "empty-init" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:4 -msgid "The ``__init__.py`` files under the following directories must be empty. For some of these (modules and tests), ``__init__.py`` files with code won't be used. For others (module_utils), we want the possibility of using Python namespaces which an empty ``__init__.py`` will allow for." -msgstr "以下のディレクトリーにある ``__init__.py`` ファイルは空である必要があります。これらのディレクトリーの一部 (モジュールおよびテスト) では、コードを持つ ``__init__.py`` ファイルは使用されません。その他 (モジュールユーティリティー) の場合は、空の ``__init__.py`` を許可する Python 名前空間を使用することも可能です。" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:8 -#: ../../rst/dev_guide/testing/sanity/mypy.rst:11 -msgid "``lib/ansible/modules/``" -msgstr "``lib/ansible/modules/``" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:9 -#: ../../rst/dev_guide/testing/sanity/mypy.rst:12 -msgid "``lib/ansible/module_utils/``" -msgstr "``lib/ansible/module_utils/``" - -#: ../../rst/dev_guide/testing/sanity/empty-init.rst:10 -msgid "``test/units/``" -msgstr "``test/units/``" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:2 -msgid "future-import-boilerplate" -msgstr "future-import-boilerplate" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:4 -msgid "Most Python files should include the following boilerplate at the top of the file, right after the comment header:" -msgstr "ほとんどの Python ファイルには、ファイルの上部、コメントヘッダーの直後に次の boilerplate を含める必要があります。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:11 -msgid "This uses Python 3 semantics for absolute versus relative imports, division, and print. By doing this, we can write code which is portable between Python 2 and Python 3 by following the Python 3 semantics." -msgstr "ここでは、絶対的インポートと相対的インポート、除算、および出力に Python 3 セマンティクスを使用します。Python 3 セマンティクスに従って、Python 2 と Python 3 の間で移植可能なコードを作成できます。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:18 -msgid "When Python 2 encounters an import of a name in a file like ``import copy`` it attempts to load ``copy.py`` from the same directory as the file is in. This can cause problems if there is a python file of that name in the directory and also a python module in ``sys.path`` with that same name. In that case, Python 2 would load the one in the same directory and there would be no way to load the one on ``sys.path``. Python 3 fixes this by making imports absolute by default. ``import copy`` will find ``copy.py`` from ``sys.path``. If you want to import ``copy.py`` from the same directory, the code needs to be changed to perform a relative import: ``from . import copy``." -msgstr "Python 2 は、``import copy`` のようなファイル名の「import」に遭遇すると、そのファイルがあるディレクトリーから ``copy.py`` を読み込もうとします。これは、そのディレクトリーにその名前の python ファイルがあり、``sys.path`` にも同じ名前の python モジュールがある場合に問題が発生します。この場合、Python 2 は同じディレクトリーにあるものを読み込み、``sys.path`` にあるものを読み込む方法がありません。Python 3 は、デフォルトでインポートを行うようにすることでこの問題を解決しました。``import copy`` は、``sys.path`` から ``copy.py`` を見つけます。同じディレクトリーから ``copy.py`` をインポートする場合は、相対インポートを行うようにコードを変更する必要があります (``from . import copy``)。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:28 -msgid "`Absolute and relative imports `_" -msgstr "`Absolute and relative imports `_" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:33 -msgid "In Python 2, the division operator (``/``) returns integer values when used with integers. If there was a remainder, this part would be left off (aka, `floor division`). In Python 3, the division operator (``/``) always returns a floating point number. Code that needs to calculate the integer portion of the quotient needs to switch to using the floor division operator (`//`) instead." -msgstr "Python 2 では、除算演算子 (``/``) は、整数と共に使用すると整数値を返します。残りの部分がある場合、この部分はオフ (別名 `切り捨て除算`) のままにします。Python 3 では、除算演算子 (``/``) は常に浮動小数点数を返します。引用符で整数を計算する必要のあるコードは、代わりに切り捨て除算演算子 (`//`) の使用に切り替える必要があります。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:40 -msgid "`Changing the division operator `_" -msgstr "`Changing the division operator `_" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:45 -msgid "In Python 2, :func:`python:print` is a keyword. In Python 3, :func:`python3:print` is a function with different parameters. Using this ``__future__`` allows using the Python 3 print semantics everywhere." -msgstr "Python 2 では、:func:`python:print` はキーワードです。Python 3 では、 :func:`python3:print` は異なるパラメーターを持つ機能です。この ``__future__`` を使用すると、あらゆる場所に Python 3 出力セマンティクスを使用できます。" - -#: ../../rst/dev_guide/testing/sanity/future-import-boilerplate.rst:50 -msgid "`Make print a function `_" -msgstr "`Make print a function `_" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:2 -msgid "ignores" -msgstr "ignore" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:4 -msgid "Sanity tests for individual files can be skipped, and specific errors can be ignored." -msgstr "個々のファイルで健全性テストをスキップしたり、特定のエラーを無視したりできます。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:7 -msgid "When to Ignore Errors" -msgstr "エラーを無視するタイミング" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:9 -msgid "Sanity tests are designed to improve code quality and identify common issues with content. When issues are identified during development, those issues should be corrected." -msgstr "健全性テストは、コードの品質を改善し、コンテンツに関する典型的な問題を特定するように設計されています。開発中に問題を特定する際に、問題を修正する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:12 -msgid "As development of Ansible continues, sanity tests are expanded to detect issues that previous releases could not. To allow time for existing content to be updated to pass newer tests, ignore entries can be added. New content should not use ignores for existing sanity tests." -msgstr "Ansible の開発が続くにつれて、健全性テストが拡張され、以前のリリースでは検出できなかった問題が検出されます。既存のコンテンツを更新して新しいテストに合格するための時間を確保するために、ignore エントリーを追加できます。新しいコンテンツでは、既存の健全性テストで ignore を使用しないでください。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:16 -msgid "When code is fixed to resolve sanity test errors, any relevant ignores must also be removed. If the ignores are not removed, this will be reported as an unnecessary ignore error. This is intended to prevent future regressions due to the same error recurring after being fixed." -msgstr "コードが修正されて健全性テストエラーを解決する場合には、関連する ignore も削除する必要があります。ignore が削除されないと、不要な ignore エラーが報告されます。これは、修正後に同じエラーが繰り返し発生するため、今後のリグレッションを防ぐことを目的としています。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:21 -msgid "When to Skip Tests" -msgstr "テストをスキップするタイミング" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:23 -msgid "Although rare, there are reasons for skipping a sanity test instead of ignoring the errors it reports." -msgstr "頻繁には起こりませんが、報告されたエラーを無視する代わりに、健全性テストを行わない (スキップする) 場合があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:25 -msgid "If a sanity test results in a traceback when processing content, that error cannot be ignored. If this occurs, open a new `bug report `_ for the issue so it can be fixed. If the traceback occurs due to an issue with the content, that issue should be fixed. If the content is correct, the test will need to be skipped until the bug in the sanity test is fixed." -msgstr "健全性テストにより、コンテンツの処理時にトレースバックが発生すると、そのエラーは無視できません。このような場合には、新しい `バグレポート `_ を作成し、問題を修正してください。コンテンツに問題があるためにトレースバックが発生した場合は、その問題を修正する必要があります。コンテンツが正しい場合は、健全性テストのバグが修正されるまで、テストをスキップする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:30 -msgid "Caution should be used when skipping sanity tests instead of ignoring them. Since the test is skipped entirely, resolution of the issue will not be automatically detected. This will prevent prevent regression detection from working once the issue has been resolved. For this reason it is a good idea to periodically review skipped entries manually to verify they are required." -msgstr "健全性テストを無視するのではなくスキップする場合は注意が必要です。テストは完全にスキップされるため、問題の解決が自動的に検出されません。これにより、問題が解決すると回帰検出が機能しなくなります。このため、スキップしたエントリーを定期的に手動で確認して、そのエントリーが必要かどうかを確認することが推奨されます。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:36 -msgid "Ignore File Location" -msgstr "ignore ファイルの場所" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:38 -msgid "The location of the ignore file depends on the type of content being tested." -msgstr "ignore ファイルの場所は、テストするコンテンツの種類によって異なります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:41 -msgid "Ansible Collections" -msgstr "Ansible Collections" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:43 -msgid "Since sanity tests change between Ansible releases, a separate ignore file is needed for each Ansible major release." -msgstr "健全性テストは Ansible リリース間で異なるため、Ansible メジャーリリースごとに個別の ignore ファイルが必要です。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:45 -msgid "The filename is ``tests/sanity/ignore-X.Y.txt`` where ``X.Y`` is the Ansible release being used to test the collection." -msgstr "ファイル名は ``tests/sanity/ignore-X.Y.txt`` です。``X.Y`` は、コレクションをテストするために使用される Ansible リリースです。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:47 -msgid "Maintaining a separate file for each Ansible release allows a collection to pass tests for multiple versions of Ansible." -msgstr "Ansible リリースごとに個別のファイルを維持すると、コレクションが Ansible の複数のバージョンのテストに合格できるようになります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:52 -msgid "When testing Ansible, all ignores are placed in the ``test/sanity/ignore.txt`` file." -msgstr "Ansible をテストする際、すべての ignore は ``test/sanity/ignore.txt`` ファイルに置かれます。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:54 -msgid "Only a single file is needed because ``ansible-test`` is developed and released as a part of Ansible itself." -msgstr "``ansible-test`` が作成され、Ansible 自体の一部としてリリースされるため、単一のファイルのみが必要になります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:57 -msgid "Ignore File Format" -msgstr "ignore ファイル形式" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:59 -msgid "The ignore file contains one entry per line. Each line consists of two columns, separated by a single space. Comments may be added at the end of an entry, started with a hash (``#``) character, which can be proceeded by zero or more spaces. Blank and comment only lines are not allowed." -msgstr "ignore ファイルでは、1 行に 1 つのエントリーが含まれます。各行は、1 つのスペースで区切られた 2 つの列で構成されます。コメントはエントリーの末尾に追加できます。先頭にハッシュ (``#``) 文字を付けて、ゼロ以上の空白を追加できます。空白とコメントのみの行は使用できません。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:64 -msgid "The first column specifies the file path that the entry applies to. File paths must be relative to the root of the content being tested. This is either the Ansible source or an Ansible collection. File paths cannot contain a space or the hash (``#``) character." -msgstr "最初の列は、エントリーが適用されるファイルパスを指定します。ファイルパスは、テストするコンテンツのルートに対して相対的である必要があります。これは Ansible ソースまたは Ansible コレクションのいずれかです。ファイルパスにスペースまたはハッシュ (``#``) 文字を含めることはできません。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:69 -msgid "The second column specifies the sanity test that the entry applies to. This will be the name of the sanity test. If the sanity test is specific to a version of Python, the name will include a dash (``-``) and the relevant Python version. If the named test uses error codes then the error code to ignore must be appended to the name of the test, separated by a colon (``:``)." -msgstr "2 列目は、エントリーが適用される健全性テストを指定します。これが健全性テストの名前になります。Python のバージョンに固有の健全性テストを使用する場合は、名前にダッシュ (``-``) と関連する Python バージョンが含まれます。名前付きテストがエラーコードを使用する場合は、無視するエラーコードをコロン (``:``) で区切ってテストの名前に追加する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:74 -msgid "Below are some example ignore entries for an Ansible collection:" -msgstr "以下は、Ansible コレクションの ignore エントリーの例です。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:82 -msgid "It is also possible to skip a sanity test for a specific file. This is done by adding ``!skip`` after the sanity test name in the second column. When this is done, no error code is included, even if the sanity test uses error codes." -msgstr "特定ファイルの健全性テストをスキップすることもできます。これは、2 番目のコラムの健全性テスト名の後に ``!skip`` を追加することで行います。これを行うと、健全性テストでエラーコードを使用しても、エラーコードは含まれません。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:86 -msgid "Below are some example skip entries for an Ansible collection:" -msgstr "以下は、Ansible コレクションの skip エントリーの例です。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:93 -#: ../../rst/dev_guide/testing_sanity.rst:56 -msgid "See the full list of :ref:`sanity tests `, which details the various tests and details how to fix identified issues." -msgstr "各種テストや特定された問題を解決する方法の詳細は、「:ref:`健全性テスト `」の一覧を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:96 -msgid "Ignore File Errors" -msgstr "ignore ファイルエラー" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:98 -msgid "There are various errors that can be reported for the ignore file itself:" -msgstr "ignore ファイル自体について報告できるさまざまなエラーがあります。" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:100 -msgid "syntax errors parsing the ignore file" -msgstr "ignore ファイルを解析する構文エラー" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:101 -msgid "references a file path that does not exist" -msgstr "存在しないファイルパスを参照" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:102 -msgid "references to a sanity test that does not exist" -msgstr "存在しない健全性テストへの参照" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:103 -msgid "ignoring an error that does not occur" -msgstr "発生しないエラーを無視" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:104 -msgid "ignoring a file which is skipped" -msgstr "スキップされたファイルを無視" - -#: ../../rst/dev_guide/testing/sanity/ignores.rst:105 -msgid "duplicate entries" -msgstr "重複エントリー" - -#: ../../rst/dev_guide/testing/sanity/import.rst:2 -msgid "import" -msgstr "import" - -#: ../../rst/dev_guide/testing/sanity/import.rst:4 -msgid "Ansible :ref:`allows unchecked imports` of some libraries from specific directories. Importing any other Python library requires :ref:`handling import errors`. This enables support for sanity tests such as :ref:`testing_validate-modules` and provides better error messages to the user." -msgstr "Ansible では、特定のディレクトリーからの一部ライブラリーの :ref:`allows unchecked imports` が可能です。他の Python ライブラリーをインポートするには、:ref:`handling import errors` が必要です。そのため、:ref:`testing_validate-modules` などの健全性テストへのサポートが可能になり、より適切なエラーメッセージをユーザーに提供できます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:11 -msgid "Handling import errors" -msgstr "インポートエラーの処理" - -#: ../../rst/dev_guide/testing/sanity/import.rst:14 -msgid "In modules" -msgstr "モジュールの場合" - -#: ../../rst/dev_guide/testing/sanity/import.rst:16 -#: ../../rst/dev_guide/testing/sanity/import.rst:51 -msgid "Instead of using ``import another_library``:" -msgstr "``import another_library`` の代わりとして:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:35 -msgid "The ``missing_required_lib`` import above will be used below." -msgstr "上記の ``missing_required_lib`` インポートは以下で使用されます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:37 -msgid "Then in the module code:" -msgstr "モジュールコードの場合:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:49 -msgid "In plugins" -msgstr "プラグインの場合" - -#: ../../rst/dev_guide/testing/sanity/import.rst:62 -msgid "Then in the plugin code, for example in ``__init__`` of the plugin:" -msgstr "プラグインコード (例: プラグインの ``__init__``) の場合:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:70 -msgid "When used as base classes" -msgstr "ベースクラスとして使用する場合" - -#: ../../rst/dev_guide/testing/sanity/import.rst:74 -msgid "This solution builds on the previous two examples. Make sure to pick the appropriate one before continuing with this solution." -msgstr "このソリューションは、前の 2 つの例に基づいています。このソリューションを続行する前に、必ず適切なものを選択してください。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:77 -msgid "Sometimes an import is used in a base class, for example:" -msgstr "インポートは基本クラスで使用されることがあります。以下はその例です。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:86 -msgid "One option is make the entire class definition conditional:" -msgstr "オプションの 1 つとして、クラス定義全体を条件付きにできます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:94 -msgid "Another option is to define a substitute base class by modifying the exception handler:" -msgstr "もう 1 つのオプションとして、例外ハンドラーを変更して代替のベースクラスを定義できます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:108 -msgid "Allowed unchecked imports" -msgstr "未確認インポートの許可" - -#: ../../rst/dev_guide/testing/sanity/import.rst:110 -msgid "Ansible allows the following unchecked imports from these specific directories:" -msgstr "Ansible では、これらの特定のディレクトリーから次の未確認インポートを許可します。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:112 -msgid "ansible-core:" -msgstr "ansible-core:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:114 -msgid "For ``lib/ansible/modules/`` and ``lib/ansible/module_utils/``, unchecked imports are only allowed from the Python standard library;" -msgstr "``lib/ansible/modules/`` および ``lib/ansible/module_utils/`` の場合、未確認インポートは Python 標準ライブラリーでのみ利用可能です。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:115 -msgid "For ``lib/ansible/plugins/``, unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself;" -msgstr "``lib/ansible/plugins/`` では、未確認インポートは、Python 標準ライブラリー、ansible-core のパブリック依存関係、および ansible-core 自体からのみ許可されます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:117 -msgid "collections:" -msgstr "コレクション:" - -#: ../../rst/dev_guide/testing/sanity/import.rst:119 -msgid "For ``plugins/modules/`` and ``plugins/module_utils/``, unchecked imports are only allowed from the Python standard library;" -msgstr "``plugins/modules/`` および ``plugins/module_utils/`` の場合、未確認インポートは Python 標準ライブラリーでのみ利用可能です。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:120 -msgid "For other directories in ``plugins/`` (see `the community collection requirements `_ for a list), unchecked imports are only allowed from the Python standard library, from public dependencies of ansible-core, and from ansible-core itself." -msgstr "``plugins/`` のその他のディレクトリー (一覧は「`the community collection requirements `_」を参照) では、未確認インポートは Python 標準ライブラリー、ansible-core のパブリック依存関係、および ansible-core 自体からのみ許可されます。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:122 -msgid "Public dependencies of ansible-core are:" -msgstr "ansible-core のパブリック依存関係は次のとおりです。" - -#: ../../rst/dev_guide/testing/sanity/import.rst:124 -msgid "Jinja2" -msgstr "Jinja2" - -#: ../../rst/dev_guide/testing/sanity/import.rst:125 -msgid "PyYAML" -msgstr "PyYAML" - -#: ../../rst/dev_guide/testing/sanity/import.rst:126 -msgid "MarkupSafe (as a dependency of Jinja2)" -msgstr "MarkupSafe (Jinja2 の依存関係として)" - -#: ../../rst/dev_guide/testing/sanity/index.rst:4 -#: ../../rst/dev_guide/testing_sanity.rst:7 -msgid "Sanity Tests" -msgstr "健全性テスト" - -#: ../../rst/dev_guide/testing/sanity/index.rst:6 -msgid "The following sanity tests are available as ``--test`` options for ``ansible-test sanity``. This list is also available using ``ansible-test sanity --list-tests --allow-disabled``." -msgstr "以下の健全性テストは、``ansible-test sanity`` の ``--test`` オプションとして利用できます。この一覧は、``ansible-test sanity --list-tests --allow-disabled`` を使用しても利用できます。" - -#: ../../rst/dev_guide/testing/sanity/index.rst:9 -msgid "For information on how to run these tests, see :ref:`sanity testing guide `." -msgstr "これらのテストの実行方法は、「:ref:`健全性テストガイド `」を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:2 -msgid "integration-aliases" -msgstr "integration-aliases" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:4 -msgid "Integration tests are executed by ``ansible-test`` and reside in directories under ``test/integration/targets/``. Each test MUST have an ``aliases`` file to control test execution." -msgstr "統合テストは ``ansible-test`` によって実行し、``test/integration/targets/`` 配下のディレクトリーに置かれます。各テストには、テストの実行を制御する ``aliases`` ファイルが必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:7 -msgid "Aliases are explained in the following sections. Each alias must be on a separate line in an ``aliases`` file." -msgstr "エイリアスは、以下のセクションで説明します。各エイリアスは、``aliases`` ファイルの別の行に指定する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:10 -msgid "Groups" -msgstr "グループ" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:12 -msgid "Tests must be configured to run in exactly one group. This is done by adding the appropriate group to the ``aliases`` file." -msgstr "テストは 1 つのグループで実行するように設定する必要があります。これは、適切なグループを ``aliases`` ファイルに追加することで行われます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:14 -msgid "The following are examples of some of the available groups:" -msgstr "利用可能な一部のグループの例を以下に示します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:16 -msgid "``shippable/posix/group1``" -msgstr "``shippable/posix/group1``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:17 -msgid "``shippable/windows/group2``" -msgstr "``shippable/windows/group2``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:18 -msgid "``shippable/azure/group3``" -msgstr "``shippable/azure/group3``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:19 -msgid "``shippable/aws/group1``" -msgstr "``shippable/aws/group1``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:20 -msgid "``shippable/cloud/group1``" -msgstr "``shippable/cloud/group1``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:22 -msgid "Groups are used to balance tests across multiple CI jobs to minimize test run time. They also improve efficiency by keeping tests with similar requirements running together." -msgstr "グループは、複数の CI ジョブ間でテストのバランスを取り、テストのランタイムを最小限にするために使用します。同様の要件が一緒に実行されるテストを維持することで、効率性も向上します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:25 -msgid "When selecting a group for a new test, use the same group as existing tests similar to the one being added. If more than one group is available, select one randomly." -msgstr "新規テスト用にグループを選択する場合は、追加する既存のテストと同様のグループを使用します。複数のグループが利用可能な場合は、ランダムに 1 つのグループを選択します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:29 -#: ../../rst/dev_guide/testing_running_locally.rst:15 -msgid "Setup" -msgstr "設定" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:31 -msgid "Aliases can be used to execute setup targets before running tests:" -msgstr "エイリアスは、テストを実行する前に設定ターゲットを実行するのに使用できます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:33 -msgid "``setup/once/TARGET`` - Run the target ``TARGET`` before the first target that requires it." -msgstr "``setup/once/TARGET`` - それが必要な最初のターゲットの前に、ターゲット ``TARGET`` を実行します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:34 -msgid "``setup/always/TARGET`` - Run the target ``TARGET`` before each target that requires it." -msgstr "``setup/always/TARGET`` - 必要な各ターゲットの前にターゲット ``TARGET`` を実行します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:37 -msgid "Requirements" -msgstr "要件" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:39 -msgid "Aliases can be used to express some test requirements:" -msgstr "エイリアスを使用すると、一部のテスト要件を表現することができます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:41 -msgid "``needs/privileged`` - Requires ``--docker-privileged`` when running tests with ``--docker``." -msgstr "``needs/privileged`` - ``--docker`` でテストを実行する場合は、``--docker-privileged`` が必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:42 -msgid "``needs/root`` - Requires running tests as ``root`` or with ``--docker``." -msgstr "``needs/root`` - ``root`` または ``--docker`` でテストを実行する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:43 -msgid "``needs/ssh`` - Requires SSH connections to localhost (or the test container with ``--docker``) without a password." -msgstr "``needs/ssh`` - パスワードなしで localhost (または ``--docker`` を使用したテストコンテナー) への SSH 接続を必要とします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:44 -msgid "``needs/httptester`` - Requires use of the http-test-container to run tests." -msgstr "``needs/httptester`` - テストを実行するには、http-test-container を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:47 -msgid "Dependencies" -msgstr "依存関係" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:49 -msgid "Some test dependencies are automatically discovered:" -msgstr "一部のテスト依存関係は自動的に検出されます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:51 -msgid "Ansible role dependencies defined in ``meta/main.yml`` files." -msgstr "``meta/main.yml`` ファイルで定義される Ansible ロールの依存関係。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:52 -msgid "Setup targets defined with ``setup/*`` aliases." -msgstr "``setup/*`` エイリアスで定義されたターゲットのセットアップ。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:53 -msgid "Symbolic links from one target to a file in another target." -msgstr "あるターゲットから別のターゲットのファイルへのシンボリックリンク。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:55 -msgid "Aliases can be used to declare dependencies that are not handled automatically:" -msgstr "エイリアスを使用すると、自動的に処理されない依存関係を宣言できます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:57 -msgid "``needs/target/TARGET`` - Requires use of the test target ``TARGET``." -msgstr "``needs/target/TARGET`` - テストターゲット ``TARGET`` を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:58 -msgid "``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the git root." -msgstr "``needs/file/PATH`` - git ルートと関連するファイル ``PATH`` を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:61 -msgid "Skipping" -msgstr "スキップ" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:63 -msgid "Aliases can be used to skip platforms using one of the following:" -msgstr "エイリアスを使用すると、以下のいずれかを使用してプラットフォームをスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:65 -msgid "``skip/freebsd`` - Skip tests on FreeBSD." -msgstr "``skip/freebsd`` - FreeBSD のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:66 -msgid "``skip/osx`` - Skip tests on macOS." -msgstr "``skip/osx`` - macOS でのテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:67 -msgid "``skip/rhel`` - Skip tests on RHEL." -msgstr "``skip/rhel`` - RHEL でのテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:68 -msgid "``skip/docker`` - Skip tests when running in a Docker container." -msgstr "``skip/docker`` - Docker コンテナーで実行する場合はテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:70 -msgid "Platform versions, as specified using the ``--remote`` option with ``/`` removed, can also be skipped:" -msgstr "``--remote`` オプションで ``/`` を削除して指定したプラットフォームバージョンもスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:72 -msgid "``skip/freebsd11.1`` - Skip tests on FreeBSD 11.1." -msgstr "``skip/freebsd11.1`` - FreeBSD 11.1 のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:73 -msgid "``skip/rhel7.6`` - Skip tests on RHEL 7.6." -msgstr "``skip/rhel7.6`` - RHEL 7.6 でのテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:75 -msgid "Windows versions, as specified using the ``--windows`` option can also be skipped:" -msgstr "``--windows`` オプションを使用して指定する Windows バージョンもスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:77 -msgid "``skip/windows/2012`` - Skip tests on Windows Server 2012." -msgstr "``skip/windows/2012`` - Windows Server 2012 のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:78 -msgid "``skip/windows/2012-R2`` - Skip tests on Windows Server 2012 R2." -msgstr "``skip/windows/2012-R2`` - Windows Server 2012 R2 のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:80 -msgid "Aliases can be used to skip Python major versions using one of the following:" -msgstr "エイリアスを使用すると、以下のいずれかを使用して Python のメジャーバージョンをスキップできます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:82 -msgid "``skip/python2`` - Skip tests on Python 2.x." -msgstr "``skip/python2`` - Python 2.x のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:83 -msgid "``skip/python3`` - Skip tests on Python 3.x." -msgstr "``skip/python3`` - Python 3.x のテストをスキップします。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:85 -msgid "For more fine grained skipping, use conditionals in integration test playbooks, such as:" -msgstr "より詳細なスキップを行うには、統合テストの Playbook で条件を使用します。以下に例を示します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:93 -msgid "Miscellaneous" -msgstr "その他" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:95 -msgid "There are several other aliases available as well:" -msgstr "その他にも利用できるエイリアスがいくつかあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:97 -msgid "``destructive`` - Requires ``--allow-destructive`` to run without ``--docker`` or ``--remote``." -msgstr "``destructive`` - ``--docker`` または ``--remote`` なしで ``--allow-destructive`` を実行する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:98 -msgid "``hidden`` - Target is ignored. Usable as a dependency. Automatic for ``setup_`` and ``prepare_`` prefixed targets." -msgstr "``hidden`` - ターゲットは無視されます。依存関係として使用できます。プレフィックス ``setup_`` および ``prepare_`` が付けられたターゲットに対する自動化。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:99 -msgid "``retry/never`` - Target is excluded from retries enabled by the ``--retry-on-error`` option." -msgstr "``retry/never`` - ターゲットは、``--retry-on-error`` オプションによって有効化された再試行から除外されます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:102 -msgid "Unstable" -msgstr "Unstable" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:104 -msgid "Tests which fail sometimes should be marked with the ``unstable`` alias until the instability has been fixed. These tests will continue to run for pull requests which modify the test or the module under test." -msgstr "時々失敗するテストは、不安定性が修正されるまで、``unstable`` エイリアスでマークする必要があります。これらのテストは、テストまたはテスト対象のモジュールを変更するプル要求に対して引き続き実行します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:107 -msgid "This avoids unnecessary test failures for other pull requests, as well as tests on merge runs and nightly CI jobs." -msgstr "これにより、他のプル要求に対する不要なテストの失敗や、マージの実行および毎夜の CI ジョブのテストも回避されます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:109 -msgid "There are two ways to run unstable tests manually:" -msgstr "不安定なテストを手動で実行する方法は 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:111 -msgid "Use the ``--allow-unstable`` option for ``ansible-test``" -msgstr "``ansible-test`` には ``--allow-unstable`` オプションを使用します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:112 -msgid "Prefix the test name with ``unstable/`` when passing it to ``ansible-test``." -msgstr "それを ``ansible-test`` に渡す場合は、テスト名の前にプレフィックス ``unstable/`` を付けます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:114 -msgid "Tests will be marked as unstable by a member of the Ansible Core Team. GitHub issues_ will be created to track each unstable test." -msgstr "テストは、Ansible Core Team のメンバーによって Unstable と表示されます。GitHub 問題_ が作成され、不安定な各テストを追跡します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:118 -msgid "Disabled" -msgstr "無効化" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:120 -msgid "Tests which always fail should be marked with the ``disabled`` alias until they can be fixed." -msgstr "常に失敗するテストでは、修正されるまで、``disabled`` なエイリアスでマークされる必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:122 -msgid "Disabled tests are automatically skipped." -msgstr "無効にされたテストは自動的にスキップされます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:124 -msgid "There are two ways to run disabled tests manually:" -msgstr "無効にされたテストを手動で実行する方法は 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:126 -msgid "Use the ``--allow-disabled`` option for ``ansible-test``" -msgstr "``ansible-test`` には ``--allow-disabled`` オプションを使用します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:127 -msgid "Prefix the test name with ``disabled/`` when passing it to ``ansible-test``." -msgstr "それを ``ansible-test`` に渡す場合は、テスト名の前にプレフィックス ``disabled/`` を付けます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:129 -msgid "Tests will be marked as disabled by a member of the Ansible Core Team. GitHub issues_ will be created to track each disabled test." -msgstr "テストは、Ansible Core Team のメンバーによって無効とマークされます。GitHub 問題_ が作成され、無効にされた各テストを追跡します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:133 -msgid "Unsupported" -msgstr "Unsupported" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:135 -msgid "Tests which cannot be run in CI should be marked with the ``unsupported`` alias. Most tests can be supported through the use of simulators and/or cloud plugins." -msgstr "CI で実行できないテストには、``unsupported`` エイリアスのマークを付ける必要があります。ほとんどのテストはシミュレーターやクラウドプラグインを使用することでサポートされます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:138 -msgid "However, if that is not possible then marking a test as unsupported will prevent it from running in CI." -msgstr "ただし、テストが使用できない場合は、テストを unsupported と表示すると、CI でテストを実行できなくなります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:140 -msgid "There are two ways to run unsupported tests manually:" -msgstr "サポート対象外のテストを手動で実行する方法は 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:142 -msgid "Use the ``--allow-unsupported`` option for ``ansible-test``" -msgstr "``ansible-test`` には ``--allow-unsupported`` オプションを使用します。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:143 -msgid "Prefix the test name with ``unsupported/`` when passing it to ``ansible-test``." -msgstr "それを ``ansible-test`` に渡す場合は、テスト名の前にプレフィックス ``unsupported/`` を付けます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:145 -msgid "Tests will be marked as unsupported by the contributor of the test." -msgstr "テストは、テストの貢献者によって unsupported とマークされます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:148 -msgid "Cloud" -msgstr "クラウド" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:150 -msgid "Tests for cloud services and other modules that require access to external APIs usually require special support for testing in CI." -msgstr "通常、外部 API へのアクセスを必要とするクラウドサービスおよびその他のモジュールのテストには、CI でのテストに特別なサポートが必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:152 -msgid "These require an additional alias to indicate the required test plugin." -msgstr "これらには、必要なテストプラグインを指定するために追加のエイリアスが必要です。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:154 -msgid "Some of the available aliases are:" -msgstr "利用可能なエイリアスには、以下のものがあります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:156 -msgid "``cloud/aws``" -msgstr "``cloud/aws``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:157 -msgid "``cloud/azure``" -msgstr "``cloud/azure``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:158 -msgid "``cloud/cs``" -msgstr "``cloud/cs``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:159 -msgid "``cloud/digitalocean``" -msgstr "``cloud/digitalocean``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:160 -msgid "``cloud/foreman``" -msgstr "``cloud/foreman``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:161 -msgid "``cloud/openshift``" -msgstr "``cloud/openshift``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:162 -msgid "``cloud/tower``" -msgstr "``cloud/tower``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:163 -msgid "``cloud/vcenter``" -msgstr "``cloud/vcenter``" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:166 -msgid "Untested" -msgstr "未テスト" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:168 -msgid "Every module and plugin should have integration tests, even if the tests cannot be run in CI." -msgstr "テストを CI で実行できない場合でも、すべてのモジュールおよびプラグインに統合テストが含まれる必要があります。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:171 -msgid "Issues" -msgstr "問題" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:173 -msgid "Tests that are marked as unstable_ or disabled_ will have an issue created to track the status of the test. Each issue will be assigned to one of the following projects:" -msgstr "unstable_ または disabled_ としてマークされているテストには、テストのステータスを追跡する問題が作成されます。それぞれの問題は以下のプロジェクトのいずれかに割り当てられます。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:176 -msgid "`AWS `_" -msgstr "`AWS `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:177 -msgid "`Azure `_" -msgstr "`Azure `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:178 -msgid "`Windows `_" -msgstr "`Windows `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:179 -msgid "`General `_" -msgstr "`General `_" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:182 -msgid "Questions" -msgstr "ご質問はございますか。" - -#: ../../rst/dev_guide/testing/sanity/integration-aliases.rst:184 -msgid "For questions about integration tests reach out to @mattclay or @gundalow on GitHub or the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)." -msgstr "統合テストに関する質問は、GitHub で @mattclay もしくは @gundalow、または``#ansible-devel``チャットチャンネル（ansible.imでMatrixを使用、または`irc.libera.chat `_でIRCを使用）にお問い合わせください。" - -#: ../../rst/dev_guide/testing/sanity/line-endings.rst:2 -msgid "line-endings" -msgstr "行末" - -#: ../../rst/dev_guide/testing/sanity/line-endings.rst:4 -msgid "All files must use ``\\n`` for line endings instead of ``\\r\\n``." -msgstr "すべてのファイルは、``\\r\\n" -"`` ではなく、行末に ``\\n" -"`` を使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:2 -msgid "metaclass-boilerplate" -msgstr "metaclass-boilerplate" - -#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:4 -msgid "Most Python files should include the following boilerplate at the top of the file, right after the comment header and ``from __future__ import``:" -msgstr "ほとんどの Python ファイルには、ファイルの上部、コメントヘッダーのおよび ``from __future__ import`` の直後に次の boilerplate を含める必要があります。" - -#: ../../rst/dev_guide/testing/sanity/metaclass-boilerplate.rst:12 -msgid "Python 2 has \"new-style classes\" and \"old-style classes\" whereas Python 3 only has new-style classes. Adding the ``__metaclass__ = type`` boilerplate makes every class defined in that file into a new-style class as well." -msgstr "Python 2 には「新スタイルのクラス」および「旧スタイルのクラス」が使用されますが、Python 3 には新スタイルのクラスのみが使用されます。また、``__metaclass__ = type`` boilerplate を追加すると、そのファイルで定義されているすべてのクラスが新しいスタイルのクラスになります。" - -#: ../../rst/dev_guide/testing/sanity/mypy.rst:2 -msgid "mypy" -msgstr "mypy" - -#: ../../rst/dev_guide/testing/sanity/mypy.rst:4 -msgid "The ``mypy`` static type checker is used to check the following code against each Python version supported by the controller:" -msgstr "``mypy`` 静的タイプチェッカーは、コントローラーがサポートする各 Python バージョンに対して以下のコードを確認するために使用されます。" - -#: ../../rst/dev_guide/testing/sanity/mypy.rst:6 -msgid "``lib/ansible/``" -msgstr "``lib/ansible/``" - -#: ../../rst/dev_guide/testing/sanity/mypy.rst:7 -msgid "``test/lib/ansible_test/_internal/``" -msgstr "``test/lib/ansible_test/_internal/``" - -#: ../../rst/dev_guide/testing/sanity/mypy.rst:9 -msgid "Additionally, the following code is checked against Python versions supported only on managed nodes:" -msgstr "また、以下のコードは、管理対象ノードでのみサポートされる Python バージョンに対して確認されます。" - -#: ../../rst/dev_guide/testing/sanity/mypy.rst:14 -msgid "See `the mypy documentation `_" -msgstr "「`the mypy documentation `_」を参照してください。" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:2 -msgid "no-assert" -msgstr "assert は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:4 -msgid "Do not use ``assert`` in production Ansible python code. When running Python with optimizations, Python will remove ``assert`` statements, potentially allowing for unexpected behavior throughout the Ansible code base." -msgstr "実稼働環境の Ansible Python コードで ``assert`` を使用しないでください。最適化で Python を実行すると、Python は ``assert`` ステートメントを削除すると、Ansible のコードベース全体で予期しない動作が可能になります。" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:8 -msgid "Instead of using ``assert`` you should utilize simple ``if`` statements, that result in raising an exception. There is a new exception called ``AnsibleAssertionError`` that inherits from ``AnsibleError`` and ``AssertionError``. When possible, utilize a more specific exception than ``AnsibleAssertionError``." -msgstr "``assert`` を使用する代わりに、簡単な ``if`` ステートメントを利用する必要があります。その結果、例外が発生します。``AnsibleError`` および ``AssertionError`` から継承する ``AnsibleAssertionError`` と呼ばれる新しい例外があります。可能であれば、``AnsibleAssertionError`` より具体的な例外を利用してください。" - -#: ../../rst/dev_guide/testing/sanity/no-assert.rst:14 -msgid "Modules will not have access to ``AnsibleAssertionError`` and should instead raise ``AssertionError``, a more specific exception, or just use ``module.fail_json`` at the failure point." -msgstr "モジュールは ``AnsibleAssertionError`` にアクセスできないため、代わりに ``AssertionError`` を高くすることはできません。あるいは、障害段階で ``module.fail_json`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:2 -msgid "no-basestring" -msgstr "basestring は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:4 -msgid "Do not use ``isinstance(s, basestring)`` as basestring has been removed in Python3. You can import ``string_types``, ``binary_type``, or ``text_type`` from ``ansible.module_utils.six`` and then use ``isinstance(s, string_types)`` or ``isinstance(s, (binary_type, text_type))`` instead." -msgstr "Python3 では ``isinstance(s, basestring)`` をベース文字列から削除しないでください。``string_types``、``binary_type``、または ``text_type`` を ``ansible.module_utils.six`` からインポートしてから、代わりに ``isinstance(s, string_types)`` または ``isinstance(s, (binary_type, text_type))`` を使用できます。" - -#: ../../rst/dev_guide/testing/sanity/no-basestring.rst:9 -msgid "If this is part of code to convert a string to a particular type, ``ansible.module_utils.common.text.converters`` contains several functions that may be even better for you: ``to_text``, ``to_bytes``, and ``to_native``." -msgstr "これが文字列を特定の型に変換するコードの一部である場合、``ansible.module_utils.common.text.converters`` には、より良い関数がいくつか含まれています (``to_text``、``to_bytes``、および ``to_native``)。" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iteritems.rst:2 -msgid "no-dict-iteritems" -msgstr "dict-iteritems は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iteritems.rst:4 -msgid "The ``dict.iteritems`` method has been removed in Python 3. There are two recommended alternatives:" -msgstr "この ``dict.iteritems`` メソッドは、Python 3 で削除されました。推奨される代替手段が 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iterkeys.rst:2 -msgid "no-dict-iterkeys" -msgstr "dict-iterkeys は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-dict-iterkeys.rst:4 -msgid "The ``dict.iterkeys`` method has been removed in Python 3. Use the following instead:" -msgstr "この ``dict.iterkeys`` メソッドは、Python 3 で削除されました。代わりに、以下を使用します。" - -#: ../../rst/dev_guide/testing/sanity/no-dict-itervalues.rst:2 -msgid "no-dict-itervalues" -msgstr "dict-itervalues は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-dict-itervalues.rst:4 -msgid "The ``dict.itervalues`` method has been removed in Python 3. There are two recommended alternatives:" -msgstr "この ``dict.itervalues`` メソッドは、Python 3 で削除されました。推奨される代替手段が 2 つあります。" - -#: ../../rst/dev_guide/testing/sanity/no-get-exception.rst:2 -msgid "no-get-exception" -msgstr "get-exception は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-get-exception.rst:4 -msgid "We created a function, ``ansible.module_utils.pycompat24.get_exception`` to help retrieve exceptions in a manner compatible with Python 2.4 through Python 3.6. We no longer support Python 2.4 and Python 2.5 so this is extraneous and we want to deprecate the function. Porting code should look something like this:" -msgstr "Python 2.4 ～ Python 3.6 と互換性がある方法で例外を取得するのに役立つ関数 ``ansible.module_utils.pycompat24.get_exception`` を作成しました。Python 2.4 および Python 2.5 はサポートされなくなったため、これは外部のものであり、この関数を廃止する必要があります。移植コードは、以下のようになります。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:2 -msgid "no-illegal-filenames" -msgstr "不正なファイル名は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:4 -msgid "Files and directories should not contain illegal characters or names so that Ansible can be checked out on any Operating System." -msgstr "ファイルとディレクトリーには、Ansible をどのオペレーティングシステムでもチェックアウトできるように、不正な文字や名前は使用しないでください。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:8 -msgid "Illegal Characters" -msgstr "不正な文字" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:10 -msgid "The following characters are not allowed to be used in any part of the file or directory name;" -msgstr "以下の文字は、ファイルまたはディレクトリーの名前には使用できません。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:13 -msgid "``<``" -msgstr "``<``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:14 -msgid "``>``" -msgstr "``>``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:15 -msgid "``:``" -msgstr "``:``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:16 -msgid "``\"``" -msgstr "``\"``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:17 -msgid "``/``" -msgstr "``/``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:18 -msgid "``\\``" -msgstr "``\\``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:19 -msgid "``|``" -msgstr "``|``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:20 -msgid "``?``" -msgstr "``?``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:21 -msgid "``*``" -msgstr "``*``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:22 -msgid "Any characters whose integer representations are in the range from 0 through to 31 like ``\\n``" -msgstr "整数表示が 0 から 31 までの文字 (例: ``\\n" -"``)" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:24 -msgid "The following characters are not allowed to be used as the last character of a file or directory;" -msgstr "次の文字は、ファイルまたはディレクトリーの最後の文字には使用できません。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:27 -msgid "``.``" -msgstr "``.``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:28 -msgid "``\" \"`` (just the space character)" -msgstr "``\" \"`` (空白文字のみ)" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:31 -msgid "Illegal Names" -msgstr "不正な名前" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:33 -msgid "The following names are not allowed to be used as the name of a file or directory excluding the extension;" -msgstr "以下の名前は、拡張子を除いてファイルまたはディレクトリーの名前として使用することはできません。" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:36 -msgid "``CON``" -msgstr "``CON``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:37 -msgid "``PRN``" -msgstr "``PRN``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:38 -msgid "``AUX``" -msgstr "``AUX``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:39 -msgid "``NUL``" -msgstr "``NUL``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:40 -msgid "``COM1``" -msgstr "``COM1``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:41 -msgid "``COM2``" -msgstr "``COM2``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:42 -msgid "``COM3``" -msgstr "``COM3``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:43 -msgid "``COM4``" -msgstr "``COM4``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:44 -msgid "``COM5``" -msgstr "``COM5``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:45 -msgid "``COM6``" -msgstr "``COM6``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:46 -msgid "``COM7``" -msgstr "``COM7``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:47 -msgid "``COM8``" -msgstr "``COM8``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:48 -msgid "``COM9``" -msgstr "``COM9``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:49 -msgid "``LPT1``" -msgstr "``LPT1``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:50 -msgid "``LPT2``" -msgstr "``LPT2``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:51 -msgid "``LPT3``" -msgstr "``LPT3``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:52 -msgid "``LPT4``" -msgstr "``LPT4``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:53 -msgid "``LPT5``" -msgstr "``LPT5``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:54 -msgid "``LPT6``" -msgstr "``LPT6``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:55 -msgid "``LPT7``" -msgstr "``LPT7``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:56 -msgid "``LPT8``" -msgstr "``LPT8``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:57 -msgid "``LPT9``" -msgstr "``LPT9``" - -#: ../../rst/dev_guide/testing/sanity/no-illegal-filenames.rst:59 -msgid "For example, the file ``folder/COM1``, ``folder/COM1.txt`` are illegal but ``folder/COM1-file`` or ``folder/COM1-file.txt`` is allowed." -msgstr "たとえば、``folder/COM1`` ファイルまたは ``folder/COM1.txt`` ファイルは許可されませんが、``folder/COM1-file`` ファイルまたは ``folder/COM1-file.txt`` ファイルは許可されます。" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:2 -msgid "no-main-display" -msgstr "main-display は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:4 -msgid "As of Ansible 2.8, ``Display`` should no longer be imported from ``__main__``." -msgstr "Ansible 2.8 以降、``Display`` は ``__main__`` からインポートしないようにしてください。" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:6 -msgid "``Display`` is now a singleton and should be utilized like the following:" -msgstr "``Display`` はシングルトンで、以下のように使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-main-display.rst:13 -msgid "There is no longer a need to attempt ``from __main__ import display`` inside a ``try/except`` block." -msgstr "``try/except`` ブロック内で ``from __main__ import display`` を試行する必要がなくなりました。" - -#: ../../rst/dev_guide/testing/sanity/no-smart-quotes.rst:2 -msgid "no-smart-quotes" -msgstr "スマート引用符は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-smart-quotes.rst:4 -msgid "Smart quotes (``”“‘’``) should not be used. Use plain ascii quotes (``\"'``) instead." -msgstr "スマート引用符 (``”“‘’``) は使用しないでください。代わりに、標準の ascii 引用符 (``\"'``) を使用します。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:4 -msgid "no-tests-as-filters" -msgstr "テストをフィルターとして使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:6 -msgid "Using Ansible provided Jinja2 tests as filters will be removed in Ansible 2.9." -msgstr "Ansible が提供する Jinja2 テストをフィルターとして使用することは、Ansible 2.9 で削除されます。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:8 -msgid "Prior to Ansible 2.5, Jinja2 tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while Jinja2 tests are referenced as ``variable is test_name``." -msgstr "Ansible 2.5 以前は、Ansible に含まれる Jinja2 テストは、ほとんどがフィルターとして使用されていました。使用方法の大きな違いは、フィルターは ``variable | filter_name`` として参照されるのに対し、Jinja2 テストは ``variable is test_name`` として参照されることです。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:10 -msgid "Jinja2 tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in Jinja2. This change is to help differentiate the concepts for a better understanding of Jinja2, and where each can be appropriately used." -msgstr "Jinja2 テストは比較のために使用され、フィルターはデータ操作のために使用され、Jinja2 でそれぞれ用途が異なります。この変更は、Jinja2 の理解を深めるために概念を区別し、それぞれを適切に使用できるようにするためのものです。" - -#: ../../rst/dev_guide/testing/sanity/no-tests-as-filters.rst:12 -msgid "As of Ansible 2.5 using an Ansible provided Jinja2 test with filter syntax will display a deprecation error." -msgstr "Ansible 2.5 以降では、Ansible が提供する Jinja2 テストをフィルター構文で使用すると、非推奨エラーが表示されます。" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:4 -msgid "no-underscore-variable" -msgstr "no-underscore-variable" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:6 -msgid "In the future, Ansible may use the identifier ``_`` to internationalize its message strings. To be ready for that, we need to make sure that there are no conflicting identifiers defined in the code base." -msgstr "今後、Ansible は、識別子 ``_`` を使用して、メッセージ文字列を国際化することができます。そのためには、コードベースで定義されている識別子が競合しないようにする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:10 -msgid "In common practice, ``_`` is frequently used as a dummy variable (a variable to receive a value from a function where the value is useless and never used). In Ansible, we're using the identifier ``dummy`` for this purpose instead." -msgstr "一般的な慣行では、``_`` は、ダミー変数 (値が役に立たず、使用されない関数から値を受け取る変数) として頻繁に使用されます。Ansibleでは、代わりにこの目的のために識別子 ``dummy`` を使用しています。" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:14 -msgid "Example of unfixed code:" -msgstr "未修正コードの例:" - -#: ../../rst/dev_guide/testing/sanity/no-underscore-variable.rst:23 -msgid "Example of fixed code:" -msgstr "修正したコードの例:" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:2 -msgid "no-unicode_literals" -msgstr "no-unicode_literals" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:4 -msgid "The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern. The problems with it are:" -msgstr ":code:`from __future__ import unicode_literals` の使用はアンチパターンと見なされます。その問題は次のとおりです。" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:7 -msgid "It makes it so one can't jump into the middle of a file and know whether a bare literal string is a byte string or text string. The programmer has to first check the top of the file to see if the import is there." -msgstr "これにより、ファイルの途中にジャンプして、裸のリテラル文字列がバイト文字列なのかテキスト文字列なのかを知ることができなくなります。プログラマーは、最初にファイルの先頭をチェックして、インポートが存在するかどうかを確認する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:10 -msgid "It removes the ability to define native strings (a string which should be a byte string on python2 and a text string on python3) by a string literal." -msgstr "これにより、文字列リテラルを介してネイティブ文字列 (python2 ではバイト文字列、python3 ではテキスト文字列である必要がある文字列) を定義する機能が削除されます。" - -#: ../../rst/dev_guide/testing/sanity/no-unicode-literals.rst:12 -msgid "It makes for more context switching. A programmer could be reading one file which has `unicode_literals` and know that bare string literals are text strings but then switch to another file (perhaps tracing program execution into a third party library) and have to switch their understanding of what bare string literals are." -msgstr "そのため、コンテキストの切り替えが多くなります。プログラマーは、`unicode_literals` を含むあるファイルを読み込んでいて、裸の文字列リテラルがテキスト文字列であることを理解ｓていますが、その後、別のファイル (おそらくサードパーティーのライブラリーへのプログラム実行の追跡) に替えて、裸の文字列リテラルが何であるかの理解に切り替えなければなりません。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:2 -msgid "no-unwanted-files" -msgstr "不要なファイルは使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:4 -msgid "Specific file types are allowed in certain directories:" -msgstr "特定のファイルタイプは、特定のディレクトリーで許可されます。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:6 -msgid "``lib`` - All content must reside in the ``lib/ansible`` directory." -msgstr "``lib`` - すべてのコンテンツは ``lib/ansible`` ディレクトリーに置く必要があります。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:8 -msgid "``lib/ansible`` - Only source code with one of the following extensions is allowed:" -msgstr "``lib/ansible`` - 以下の拡張機能のいずれかを持つソースコードのみが許可されます。" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:10 -msgid "``*.cs`` - C#" -msgstr "``*.cs`` - C#" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:11 -msgid "``*.ps1`` - PowerShell" -msgstr "``*.ps1`` - PowerShell" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:12 -msgid "``*.psm1`` - PowerShell" -msgstr "``*.psm1`` - PowerShell" - -#: ../../rst/dev_guide/testing/sanity/no-unwanted-files.rst:13 -msgid "``*.py`` - Python" -msgstr "``*.py`` - Python" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:4 -msgid "no-wildcard-import" -msgstr "ワイルドカードの import は使用しない" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:6 -msgid "Using :code:`import *` is a bad habit which pollutes your namespace, hinders debugging, and interferes with static analysis of code. For those reasons, we do want to limit the use of :code:`import *` in the ansible code. Change our code to import the specific names that you need instead." -msgstr ":code:`import *` を使用することは、名前空間を汚染し、デバッグを妨げ、コードの静的分析を妨げる悪い習慣です。これらの理由から、Ansible コードで :code:`import *` の使用を制限します。代わりに、必要な特定の名前をインポートするようにコードを変更してください。" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:11 -msgid "Examples of unfixed code:" -msgstr "未修正コードの例:" - -#: ../../rst/dev_guide/testing/sanity/no-wildcard-import.rst:22 -msgid "Examples of fixed code:" -msgstr "修正されたコードの例:" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:2 -msgid "obsolete-files" -msgstr "陳腐化したファイル" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:4 -msgid "Directories in the Ansible source tree are sometimes made obsolete. Files should not exist in these directories. The new location (if any) is dependent on which directory has been made obsolete." -msgstr "Ansible ソースツリー内のディレクトリーは廃止されることがあります。ファイルは、このディレクトリーに存在すべきではありません。新しい場所が存在する場合は、どのディレクトリーが廃止されたかに依存しています。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:8 -msgid "Below are some of the obsolete directories and their new locations:" -msgstr "古いディレクトリーとその新しい場所を以下に示します。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:10 -msgid "All of ``test/runner/`` is now under ``test/lib/ansible_test/`` instead. The organization of files in the new directory has changed." -msgstr "すべての ``test/runner/`` は、現在、代わりに ``test/lib/ansible_test/`` にあります。新しいディレクトリーのファイルの編成が変更になりました。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:11 -msgid "Most subdirectories of ``test/sanity/`` (with some exceptions) are now under ``test/lib/ansible_test/_util/controller/sanity/`` instead." -msgstr "``test/sanity/``のサブディレクトリーのほとんどは (例外あり) 、代わりに ``test/lib/ansible_test/_util/controller/sanity/`` の下にあります。" - -#: ../../rst/dev_guide/testing/sanity/obsolete-files.rst:13 -msgid "This error occurs most frequently for open pull requests which add or modify files in directories which are now obsolete. Make sure the branch you are working from is current so that changes can be made in the correct location." -msgstr "このエラーは、現在古くなったディレクトリーのファイルを追加または変更するオープンなプル要求に対して最も頻繁に発生します。正しい場所で変更できるように、作業しているブランチが現在の状態であることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/package-data.rst:2 -msgid "package-data" -msgstr "package-data" - -#: ../../rst/dev_guide/testing/sanity/package-data.rst:4 -msgid "Verifies that the combination of ``MANIFEST.in`` and ``package_data`` from ``setup.py`` properly installs data files from within ``lib/ansible``" -msgstr "``setup.py`` から ``MANIFEST.in`` と ``package_data`` を組み合わせて、``lib/ansible`` 内からデータファイルが適切にインストールされていることを確認します。" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:4 -msgid "pep8" -msgstr "pep8" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:6 -msgid "Python static analysis for PEP 8 style guideline compliance." -msgstr "PEP 8 スタイルのガイドラインコンプライアンスに対する Python 静的分析です。" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:8 -msgid "`PEP 8`_ style guidelines are enforced by `pycodestyle`_ on all python files in the repository by default." -msgstr "`PEP 8`_ スタイルのガイドラインは、デフォルトでリポジトリーにあるすべての python ファイルで `pycodestyle`_ によって強制されます。" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:11 -msgid "Running locally" -msgstr "ローカルでの実行" - -#: ../../rst/dev_guide/testing/sanity/pep8.rst:13 -msgid "The `PEP 8`_ check can be run locally as follows:" -msgstr "`PEP 8`_ チェックは、次のようにローカルで実行できます。" - -#: ../../rst/dev_guide/testing/sanity/pslint.rst:2 -msgid "pslint" -msgstr "pslint" - -#: ../../rst/dev_guide/testing/sanity/pslint.rst:4 -msgid "PowerShell static analysis for common programming errors using `PSScriptAnalyzer `_." -msgstr "`PSScriptAnalyzer `_ を使用した一般的なプログラミングエラーに関する PowerShell の静的な分析です。" - -#: ../../rst/dev_guide/testing/sanity/pylint.rst:2 -msgid "pylint" -msgstr "pylint" - -#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:6 -#: ../../rst/dev_guide/testing/sanity/pylint.rst:4 -msgid "Python static analysis for common programming errors." -msgstr "一般的なプログラミングエラーに対する Python の静的分析です。" - -#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:4 -msgid "pylint-ansible-test" -msgstr "pylint-ansible-test" - -#: ../../rst/dev_guide/testing/sanity/pylint-ansible-test.rst:8 -msgid "A more strict set of rules applied to ``ansible-test``." -msgstr "``ansible-test`` に適用されるより厳密なルールセット" - -#: ../../rst/dev_guide/testing/sanity/release-names.rst:2 -msgid "Release names" -msgstr "リリース名" - -#: ../../rst/dev_guide/testing/sanity/release-names.rst:4 -msgid "Verifies that the most recent release name has been added to ``./github/RELEASE_NAMES.yml``" -msgstr "最新のリリース名が ``./github/RELEASE_NAMES.yml`` に追加されたことを確認します。" - -#: ../../rst/dev_guide/testing/sanity/replace-urlopen.rst:2 -msgid "replace-urlopen" -msgstr "replace-urlopen" - -#: ../../rst/dev_guide/testing/sanity/replace-urlopen.rst:4 -msgid "Use ``open_url`` from ``module_utils`` instead of ``urlopen``." -msgstr "``urlopen`` の代わりに ``module_utils`` から ``open_url`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/required-and-default-attributes.rst:2 -msgid "required-and-default-attributes" -msgstr "required-and-default-attributes" - -#: ../../rst/dev_guide/testing/sanity/required-and-default-attributes.rst:4 -msgid "Use only one of ``default`` or ``required`` with ``FieldAttribute``." -msgstr "``default`` または ``required`` の 1 つのみを ``FieldAttribute`` で使用します。" - -#: ../../rst/dev_guide/testing/sanity/rstcheck.rst:2 -msgid "rstcheck" -msgstr "rstcheck" - -#: ../../rst/dev_guide/testing/sanity/rstcheck.rst:4 -msgid "Check reStructuredText files for syntax and formatting issues." -msgstr "構文およびフォーマットに関する問題は、eStructuredTex ファイルを確認してください。" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:2 -msgid "runtime-metadata.yml" -msgstr "runtime-metadata.yml" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:4 -msgid "Validates the schema for:" -msgstr "スキーマを検証します。" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:6 -msgid "ansible-core's ``lib/ansible/config/ansible_builtin_runtime.yml``" -msgstr "ansible-core の ``lib/ansible/config/ansible_builtin_runtime.yml``" - -#: ../../rst/dev_guide/testing/sanity/runtime-metadata.rst:7 -msgid "collection's ``meta/runtime.yml``" -msgstr "コレクションの ``meta/runtime.yml``" - -#: ../../rst/dev_guide/testing/sanity/sanity-docs.rst:2 -msgid "sanity-docs" -msgstr "sanity-docs" - -#: ../../rst/dev_guide/testing/sanity/sanity-docs.rst:4 -msgid "Documentation for each ``ansible-test sanity`` test is required." -msgstr "各 ``ansible-test sanity`` テスト用のドキュメントが必要です。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:2 -msgid "shebang" -msgstr "shebang" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:4 -msgid "Most executable files should only use one of the following shebangs:" -msgstr "実行ファイルのほとんどは、以下のいずれかの shebang のみを使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:6 -msgid "``#!/bin/sh``" -msgstr "``#!/bin/sh``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:7 -msgid "``#!/bin/bash``" -msgstr "``#!/bin/bash``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:8 -msgid "``#!/usr/bin/make``" -msgstr "``#!/usr/bin/make``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:9 -msgid "``#!/usr/bin/env python``" -msgstr "``#!/usr/bin/env python``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:10 -msgid "``#!/usr/bin/env bash``" -msgstr "``#!/usr/bin/env bash``" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:12 -msgid "NOTE: For ``#!/bin/bash``, any of the options ``eux`` may also be used, such as ``#!/bin/bash -eux``." -msgstr "注記: ``#!/bin/bash`` の場合は、いずれのオプションの ``eux`` も使用できます (``#!/bin/bash -eux`` など)。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:14 -msgid "This does not apply to Ansible modules, which should not be executable and must always use ``#!/usr/bin/python``." -msgstr "これは Ansible モジュールには適用されません。これは実行可能ではなく、``#!/usr/bin/python`` を常に使用する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/shebang.rst:16 -msgid "Some exceptions are permitted. Ask if you have questions." -msgstr "一部の例外が許可されます。ご質問がある場合はお問い合わせください。" - -#: ../../rst/dev_guide/testing/sanity/shellcheck.rst:2 -msgid "shellcheck" -msgstr "shellcheck" - -#: ../../rst/dev_guide/testing/sanity/shellcheck.rst:4 -msgid "Static code analysis for shell scripts using the excellent `shellcheck `_ tool." -msgstr "優れた `shellcheck `_ ツールを使用してシェルスクリプトの静的コード分析。" - -#: ../../rst/dev_guide/testing/sanity/symlinks.rst:2 -msgid "symlinks" -msgstr "symlinks" - -#: ../../rst/dev_guide/testing/sanity/symlinks.rst:4 -msgid "Symbolic links are only permitted for files that exist to ensure proper tarball generation during a release." -msgstr "シンボリックリンクは、リリース中に適切な tarball 生成を保証するファイルにのみ許可されます。" - -#: ../../rst/dev_guide/testing/sanity/symlinks.rst:6 -msgid "If other types of symlinks are needed for tests they must be created as part of the test." -msgstr "テストに他のシンボリックリンクが必要な場合は、テストの一部として作成する必要があります。" - -#: ../../rst/dev_guide/testing/sanity/test-constraints.rst:2 -msgid "test-constraints" -msgstr "test-constraints" - -#: ../../rst/dev_guide/testing/sanity/test-constraints.rst:4 -msgid "Constraints for test requirements should be in ``test/lib/ansible_test/_data/requirements/constraints.txt``." -msgstr "テスト要件の制約は ``test/lib/ansible_test/_data/requirements/constraints.txt`` に保存されている必要があります。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:4 -msgid "update-bundled" -msgstr "update-bundled" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:6 -msgid "Check whether any of our known bundled code needs to be updated for a new upstream release." -msgstr "既知のバンドルされたコードが新しいアップストリームリリース用に更新する必要があるかどうかを確認します。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:8 -msgid "This test can error in the following ways:" -msgstr "このテストは以下の方法でエラーが発生する可能性があります。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:10 -msgid "The bundled code is out of date with regard to the latest release on pypi. Update the code to the new version and update the version in _BUNDLED_METADATA to solve this." -msgstr "バンドルされたコードは pypi の最新リリースに関して古くなっています。コードを新しいバージョンに更新し、_BUNDLED_METADATA でバージョンを更新してこれを解決します。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:13 -msgid "The code is lacking a _BUNDLED_METADATA variable. This typically happens when a bundled version is updated and we forget to add a _BUNDLED_METADATA variable to the updated file. Once that is added, this error should go away." -msgstr "このコードには _BUNDLED_METADATA 変数がありません。これは通常、バンドルバージョンが更新され、更新されたファイルに _BUNDLED_METADATA 変数を追加し忘れた場合に発生します。それが追加されると、このエラーはなくなるはずです。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:17 -msgid "A file has a _BUNDLED_METADATA variable but the file isn't specified in :file:`test/sanity/code-smell/update-bundled.py`. This typically happens when a new bundled library is added. Add the file to the `get_bundled_libs()` function in the `update-bundled.py` test script to solve this error." -msgstr "ファイルには、_BUNDLED_METADATA 変数がありますが、そのファイルは :file:`test/sanity/code-smell/update-bundled.py` で指定されていません。これは通常、新しいバンドルライブラリーが追加されたときに発生します。このエラーを解決するために、`update-bundled.py` テストスクリプトの `get_bundled_libs()` 関数にファイルを追加します。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:22 -msgid "_BUNDLED_METADATA has the following fields:" -msgstr "_BUNDLED_METADATA には以下のフィールドがあります。" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst -msgid "pypi_name" -msgstr "pypi_name" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:24 -msgid "Name of the bundled package on pypi" -msgstr "pypi でバンドルされたパッケージの名前" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:26 -msgid "Version of the package that we are including here" -msgstr "ここに含めるパッケージのバージョン" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst -msgid "version_constraints" -msgstr "version_constraints" - -#: ../../rst/dev_guide/testing/sanity/update-bundled.rst:28 -msgid "Optional PEP440 specifier for the version range that we are bundling. Currently, the only valid use of this is to follow a version that is compatible with the Python stdlib when newer versions of the pypi package implement a new API." -msgstr "バンドルするバージョン範囲の任意の PEP440 指定子。現在、これの唯一の有効な使用法は、新しいバージョンの pypi パッケージが新しい API を実装するときに、Python stdlib と互換性のあるバージョンに従うことです。" - -#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:2 -msgid "use-argspec-type-path" -msgstr "use-argspec-type-path" - -#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:4 -msgid "The AnsibleModule argument_spec knows of several types beyond the standard python types. One of these is ``path``. When used, type ``path`` ensures that an argument is a string and expands any shell variables and tilde characters." -msgstr "AnsibleModule の argument_spec は、標準の python タイプ以外の複数のタイプを認識します。これらのいずれかが ``path`` になります。使用すると、``path`` と入力して、引数が文字列で、シェル変数とチルダ文字を拡張するようにします。" - -#: ../../rst/dev_guide/testing/sanity/use-argspec-type-path.rst:8 -msgid "This test looks for use of :func:`os.path.expanduser ` in modules. When found, it tells the user to replace it with ``type='path'`` in the module's argument_spec or list it as a false positive in the test." -msgstr "このテストでは、モジュールで :func:`os.path.expanduser ` の使用を探します。見つかった場合は、モジュールの argument_spec で ``type='path'`` に置き換えるか、テストで誤検出として一覧に挙げられます。" - -#: ../../rst/dev_guide/testing/sanity/use-compat-six.rst:2 -msgid "use-compat-six" -msgstr "use-compat-six" - -#: ../../rst/dev_guide/testing/sanity/use-compat-six.rst:4 -msgid "Use ``six`` from ``module_utils`` instead of ``six``." -msgstr "``six`` の代わりに ``module_utils`` から ``six`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:4 -#: ../../rst/dev_guide/testing_validate-modules.rst:5 -msgid "validate-modules" -msgstr "validate-modules" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:6 -msgid "Analyze modules for common issues in code and documentation." -msgstr "コードおよびドキュメントの一般的な問題についてモジュールを分析します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:12 -msgid "Usage" -msgstr "使用法" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:21 -msgid "Help" -msgstr "ヘルプ" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:23 -msgid "Type ``ansible-test sanity validate-modules -h`` to display help for using this sanity test." -msgstr "``ansible-test sanity validate-modules -h`` を入力すると、この健全性テストを使用するためのヘルプが表示されます。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:28 -msgid "Extending validate-modules" -msgstr "validate-modules の拡張" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:30 -msgid "The ``validate-modules`` tool has a `schema.py `_ that is used to validate the YAML blocks, such as ``DOCUMENTATION`` and ``RETURNS``." -msgstr "``validate-modules`` ツールには、``DOCUMENTATION``、``RETURNS`` などの YAML ブロックの検証に使用される `schema.py `_ があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:34 -msgid "Codes" -msgstr "コード" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:37 -msgid "**Error Code**" -msgstr "**エラーコード**" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:37 -msgid "**Type**" -msgstr "**タイプ**" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:37 -msgid "**Level**" -msgstr "**レベル**" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:37 -msgid "**Sample Message**" -msgstr "**開始メッセージ**" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:39 -msgid "ansible-deprecated-module" -msgstr "ansible-deprecated-module" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:39 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:40 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:41 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:43 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:44 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:45 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:46 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:47 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:48 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:49 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:50 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:51 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:52 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:53 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:54 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:55 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:56 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:59 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:62 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:63 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:64 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:65 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:66 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:67 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:68 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:69 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:70 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:72 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:73 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:75 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:76 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:77 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:78 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:79 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:84 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:85 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:86 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:87 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:88 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:92 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:94 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:95 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:96 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:97 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:98 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:99 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:100 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:103 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:107 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:108 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:109 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:112 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:114 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:120 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:121 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:122 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:123 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:124 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:125 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:126 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:127 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:128 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:129 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:130 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:131 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:132 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:133 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:134 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:135 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:136 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:137 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:138 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:139 -msgid "Documentation" -msgstr "ドキュメント" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:39 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:40 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:41 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:42 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:43 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:44 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:45 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:46 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:47 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:48 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:49 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:50 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:51 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:52 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:53 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:54 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:55 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:56 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:57 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:58 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:59 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:61 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:62 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:63 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:64 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:65 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:66 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:67 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:68 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:69 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:70 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:71 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:72 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:73 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:74 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:75 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:77 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:78 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:79 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:81 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:82 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:83 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:84 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:86 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:87 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:88 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:89 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:90 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:91 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:92 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:93 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:94 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:95 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:96 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:97 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:98 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:99 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:100 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:101 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:102 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:103 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:104 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:105 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:106 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:107 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:108 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:109 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:110 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:112 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:113 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:115 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:116 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:117 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:118 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:119 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:120 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:121 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:122 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:123 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:124 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:125 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:126 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:127 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:128 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:129 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:130 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:131 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:132 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:133 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:134 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:135 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:136 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:137 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:138 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:139 -msgid "Error" -msgstr "エラー" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:39 -msgid "A module is deprecated and supposed to be removed in the current or an earlier Ansible version" -msgstr "モジュールは非推奨となり、現行またはそれ以前の Ansible バージョンで削除される予定です。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:40 -msgid "collection-deprecated-module" -msgstr "collection-deprecated-module" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:40 -msgid "A module is deprecated and supposed to be removed in the current or an earlier collection version" -msgstr "モジュールは非推奨となり、現行またはそれ以前のバージョンのコレクションで削除される予定です。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:41 -msgid "ansible-deprecated-version" -msgstr "ansible-deprecated-version" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:41 -msgid "A feature is deprecated and supposed to be removed in the current or an earlier Ansible version" -msgstr "機能は非推奨となり、現行またはそれ以前の Ansible バージョンで削除される予定です。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:42 -msgid "ansible-module-not-initialized" -msgstr "ansible-module-not-initialized" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:42 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:82 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:83 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:106 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:113 -msgid "Syntax" -msgstr "構文" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:42 -msgid "Execution of the module did not result in initialization of AnsibleModule" -msgstr "モジュールを実行しても、AnsibleModule は初期化されなかった。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:43 -msgid "collection-deprecated-version" -msgstr "collection-deprecated-version" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:43 -msgid "A feature is deprecated and supposed to be removed in the current or an earlier collection version" -msgstr "機能は非推奨となり、現行またはそれ以前のバージョンのコレクションで削除される予定です。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:44 -msgid "deprecated-date" -msgstr "deprecated-date" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:44 -msgid "A date before today appears as ``removed_at_date`` or in ``deprecated_aliases``" -msgstr "今日より前の日付は、``removed_at_date`` ように表示されるか、``deprecated_aliases`` に表示されます。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:45 -msgid "deprecation-mismatch" -msgstr "deprecation-mismatch" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:45 -msgid "Module marked as deprecated or removed in at least one of the filename, its metadata, or in DOCUMENTATION (setting DOCUMENTATION.deprecated for deprecation or removing all Documentation for removed) but not in all three places." -msgstr "ファイル名、そのメタデータ、または DOCUMENTATION の少なくとも 1 つ (全箇所ではない) で非推奨または削除済みとしてマークされたモジュール (非推奨の場合は DOCUMENTATION.deprecated を設定し、削除の場合はすべてのドキュメントを削除する) します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:46 -msgid "doc-choices-do-not-match-spec" -msgstr "doc-choices-do-not-match-spec" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:46 -msgid "Value for \"choices\" from the argument_spec does not match the documentation" -msgstr "argument_spec の「choices」の値がドキュメントと一致しない。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:47 -msgid "doc-choices-incompatible-type" -msgstr "doc-choices-incompatible-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:47 -msgid "Choices value from the documentation is not compatible with type defined in the argument_spec" -msgstr "ドキュメンテーションの選択値は、argument_spec で定義されたタイプと互換性がありません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:48 -msgid "doc-default-does-not-match-spec" -msgstr "doc-default-does-not-match-spec" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:48 -msgid "Value for \"default\" from the argument_spec does not match the documentation" -msgstr "argument_spec の「default」の値がドキュメントと一致しない。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:49 -msgid "doc-default-incompatible-type" -msgstr "doc-default-incompatible-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:49 -msgid "Default value from the documentation is not compatible with type defined in the argument_spec" -msgstr "ドキュメンテーションのデフォルト値は、argument_spec で定義されたタイプと互換性がありません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:50 -msgid "doc-elements-invalid" -msgstr "doc-elements-invalid" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:50 -msgid "Documentation specifies elements for argument, when \"type\" is not ``list``." -msgstr "ドキュメントでは、「type」が ``list`` ではない場合に、引数の要素を指定します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:51 -msgid "doc-elements-mismatch" -msgstr "doc-elements-mismatch" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:51 -msgid "Argument_spec defines elements different than documentation does" -msgstr "argument_spec はドキュメントとは異なるタイプを定義します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:52 -msgid "doc-missing-type" -msgstr "doc-missing-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:52 -msgid "Documentation doesn't specify a type but argument in ``argument_spec`` use default type (``str``)" -msgstr "ドキュメントではタイプをしていませんが、``argument_spec`` の引数がデフォルト型 (``str``) を使用しています。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:53 -msgid "doc-required-mismatch" -msgstr "doc-required-mismatch" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:53 -msgid "argument in argument_spec is required but documentation says it is not, or vice versa" -msgstr "arguments_spec の引数は必須ですが、ドキュメントには必須ではない (または arguments_spec の引数は必須ではありませんが、ドキュメントには必須) と記載されています。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:54 -msgid "doc-type-does-not-match-spec" -msgstr "doc-type-does-not-match-spec" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:54 -msgid "Argument_spec defines type different than documentation does" -msgstr "argument_spec がドキュメントとは異なるタイプを定義します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:55 -msgid "documentation-error" -msgstr "documentation-error" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:55 -msgid "Unknown ``DOCUMENTATION`` error" -msgstr "不明な ``DOCUMENTATION`` エラー" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:56 -msgid "documentation-syntax-error" -msgstr "documentation-syntax-error" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:56 -msgid "Invalid ``DOCUMENTATION`` schema" -msgstr "無効な ``DOCUMENTATION`` スキーマ" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:57 -msgid "illegal-future-imports" -msgstr "illegal-future-imports" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:57 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:58 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:61 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:80 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:81 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:89 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:90 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:91 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:111 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:115 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:116 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:117 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:118 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:119 -msgid "Imports" -msgstr "インポート" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:57 -msgid "Only the following ``from __future__`` imports are allowed: ``absolute_import``, ``division``, and ``print_function``." -msgstr "``absolute_import``、``division``、および ``print_function`` の ``from __future__`` インポートのみが許可されます。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:58 -msgid "import-before-documentation" -msgstr "import-before-documentation" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:58 -msgid "Import found before documentation variables. All imports must appear below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``" -msgstr "ドキュメント変数の前にインポートが見つかりました。すべてのインポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` の下に表示される必要があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:59 -msgid "import-error" -msgstr "import-error" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:59 -msgid "``Exception`` attempting to import module for ``argument_spec`` introspection" -msgstr "``Exception`` が、``argument_spec`` イントロスペクションのモジュールのインポートを試行中" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:60 -msgid "import-placement" -msgstr "import-placement" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:60 -msgid "Locations" -msgstr "場所" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:60 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:76 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:80 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:85 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:111 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:114 -msgid "Warning" -msgstr "警告" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:60 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:61 -msgid "Imports should be directly below ``DOCUMENTATION``/``EXAMPLES``/``RETURN``" -msgstr "インポートは、``DOCUMENTATION``/``EXAMPLES``/``RETURN`` のすぐ後に配置しなければなりません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:61 -msgid "imports-improper-location" -msgstr "imports-improper-location" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:62 -msgid "incompatible-choices" -msgstr "incompatible-choices" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:62 -msgid "Choices value from the argument_spec is not compatible with type defined in the argument_spec" -msgstr "argument_spec の選択値は、argument_spec で定義されたタイプと互換性がありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:63 -msgid "incompatible-default-type" -msgstr "incompatible-default-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:63 -msgid "Default value from the argument_spec is not compatible with type defined in the argument_spec" -msgstr "argument_spec のデフォルト値は、argument_spec で定義されたタイプと互換性がありません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:64 -msgid "invalid-argument-name" -msgstr "invalid-argument-name" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:64 -msgid "Argument in argument_spec must not be one of 'message', 'syslog_facility' as it is used internally by Ansible Core Engine" -msgstr "argument_spec の引数は、Ansible Core Engine によって内部で使用されるため、「message」、「syslog_facility」のいずれかにすることはできません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:65 -msgid "invalid-argument-spec" -msgstr "invalid-argument-spec" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:65 -msgid "Argument in argument_spec must be a dictionary/hash when used" -msgstr "argument_spec の引数を使用する場合は、ディクショナリーまたはハッシュである必要があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:66 -msgid "invalid-argument-spec-options" -msgstr "invalid-argument-spec-options" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:66 -msgid "Suboptions in argument_spec are invalid" -msgstr "argument_spec のサブオプションは無効です。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:67 -msgid "invalid-documentation" -msgstr "invalid-documentation" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:67 -msgid "``DOCUMENTATION`` is not valid YAML" -msgstr "``DOCUMENTATION`` は、有効な YAML ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:68 -msgid "invalid-documentation-markup" -msgstr "invalid-documentation-markup" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:68 -msgid "``DOCUMENTATION`` or ``RETURN`` contains invalid markup" -msgstr "``DOCUMENTATION`` または、``RETURN`` に無効なマークアップが含まれています" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:69 -msgid "invalid-documentation-options" -msgstr "invalid-documentation-options" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:69 -msgid "``DOCUMENTATION.options`` must be a dictionary/hash when used" -msgstr "``DOCUMENTATION.options`` を使用する場合は、ディクショナリー/ハッシュでなければなりません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:70 -msgid "invalid-examples" -msgstr "invalid-examples" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:70 -msgid "``EXAMPLES`` is not valid YAML" -msgstr "``EXAMPLES`` は、有効な YAML ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:71 -msgid "invalid-extension" -msgstr "invalid-extension" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:71 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:74 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:110 -msgid "Naming" -msgstr "命名規則" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:71 -msgid "Official Ansible modules must have a ``.py`` extension for python modules or a ``.ps1`` for powershell modules" -msgstr "公式の Ansible モジュールでは、python モジュールの拡張子は ``.py`` で、powershell モジュールの拡張子は ``.ps1`` にする必要があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:72 -msgid "invalid-module-schema" -msgstr "invalid-module-schema" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:72 -msgid "``AnsibleModule`` schema validation error" -msgstr "``AnsibleModule`` スキーマ検証エラー" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:73 -msgid "invalid-removal-version" -msgstr "invalid-removal-version" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:73 -msgid "The version at which a feature is supposed to be removed cannot be parsed (for collections, it must be a `semantic version `_)" -msgstr "機能が削除されることになっているバージョンは解析できません (コレクションの場合、`semantic version ` である必要があります)。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:74 -msgid "invalid-requires-extension" -msgstr "invalid-requires-extension" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:74 -msgid "Module ``#AnsibleRequires -CSharpUtil`` should not end in .cs, Module ``#Requires`` should not end in .psm1" -msgstr "モジュール ``#AnsibleRequires -CSharpUtil`` の末尾を .cs にしないでください。モジュール ``#Requires`` の末尾を .psm1 にしないでください。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:75 -msgid "missing-doc-fragment" -msgstr "missing-doc-fragment" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:75 -msgid "``DOCUMENTATION`` fragment missing" -msgstr "``DOCUMENTATION`` フラグメントがありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:76 -msgid "missing-existing-doc-fragment" -msgstr "missing-existing-doc-fragment" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:76 -msgid "Pre-existing ``DOCUMENTATION`` fragment missing" -msgstr "既存の ``DOCUMENTATION`` フラグメントがありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:77 -msgid "missing-documentation" -msgstr "missing-documentation" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:77 -msgid "No ``DOCUMENTATION`` provided" -msgstr "``DOCUMENTATION`` が提供されていません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:78 -msgid "missing-examples" -msgstr "missing-examples" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:78 -msgid "No ``EXAMPLES`` provided" -msgstr "``EXAMPLES`` が提供されていません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:79 -msgid "missing-gplv3-license" -msgstr "missing-gplv3-license" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:79 -msgid "GPLv3 license header not found" -msgstr "GPLv3 ライセンスヘッダーが見つかりませんでした" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:80 -msgid "missing-module-utils-basic-import" -msgstr "missing-module-utils-basic-import" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:80 -msgid "Did not find ``ansible.module_utils.basic`` import" -msgstr "``ansible.module_utils.basic`` インポートが見つかりませんでした" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:81 -msgid "missing-module-utils-import-csharp-requirements" -msgstr "missing-module-utils-import-csharp-requirements" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:81 -msgid "No ``Ansible.ModuleUtils`` or C# Ansible util requirements/imports found" -msgstr "``Ansible.ModuleUtils`` または C# Ansible ユーティリティーの 要件/インポートがあります" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:82 -msgid "missing-powershell-interpreter" -msgstr "missing-powershell-interpreter" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:82 -msgid "Interpreter line is not ``#!powershell``" -msgstr "インタープリター行は ``#!powershell`` ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:83 -msgid "missing-python-interpreter" -msgstr "missing-python-interpreter" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:83 -msgid "Interpreter line is not ``#!/usr/bin/python``" -msgstr "インタープリター行は ``#!/usr/bin/python`` ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:84 -msgid "missing-return" -msgstr "missing-return" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:84 -msgid "No ``RETURN`` documentation provided" -msgstr "``RETURN`` のドキュメントは提供されていません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:85 -msgid "missing-return-legacy" -msgstr "missing-return-legacy" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:85 -msgid "No ``RETURN`` documentation provided for legacy module" -msgstr "レガシーモジュールには ``RETURN`` のドキュメントがありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:86 -msgid "missing-suboption-docs" -msgstr "missing-suboption-docs" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:86 -msgid "Argument in argument_spec has sub-options but documentation does not define sub-options" -msgstr "argument_spec の引数にはサブオプションョンがありますが、ドキュメントではサブオプションが定義されていません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:87 -msgid "module-incorrect-version-added" -msgstr "module-incorrect-version-added" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:87 -msgid "Module level ``version_added`` is incorrect" -msgstr "モジュールレベル ``version_added`` は正しくありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:88 -msgid "module-invalid-version-added" -msgstr "module-invalid-version-added" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:88 -msgid "Module level ``version_added`` is not a valid version number" -msgstr "モジュールレベルの ``version_added`` は、有効なバージョン番号ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:89 -msgid "module-utils-specific-import" -msgstr "module-utils-specific-import" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:89 -msgid "``module_utils`` imports should import specific components, not ``*``" -msgstr "``module_utils`` は、``*`` ではなく、特定のコンポーネントをインポートする必要があります" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:90 -msgid "multiple-utils-per-requires" -msgstr "multiple-utils-per-requires" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:90 -msgid "``Ansible.ModuleUtils`` requirements do not support multiple modules per statement" -msgstr "``Ansible.ModuleUtils`` 要件は、ステートメントごとに複数のモジュールをサポートしません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:91 -msgid "multiple-csharp-utils-per-requires" -msgstr "multiple-csharp-utils-per-requires" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:91 -msgid "Ansible C# util requirements do not support multiple utils per statement" -msgstr "C# ユーティリティー要件は、ステートメントごとに複数のモジュールをサポートしません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:92 -msgid "no-default-for-required-parameter" -msgstr "no-default-for-required-parameter" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:92 -msgid "Option is marked as required but specifies a default. Arguments with a default should not be marked as required" -msgstr "オプションは必須と識別されますが、デフォルトの引数を指定します。デフォルトの引数は必須と識別しないでください。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:93 -msgid "no-log-needed" -msgstr "no-log-needed" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:93 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:101 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:102 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:104 -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:105 -msgid "Parameters" -msgstr "パラメーター" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:93 -msgid "Option name suggests that the option contains a secret value, while ``no_log`` is not specified for this option in the argument spec. If this is a false positive, explicitly set ``no_log=False``" -msgstr "オプション名は、オプションにシークレット値が含まれていることを示唆していますが、引数仕様ではこのオプションに対して ``no_log`` が指定されていません。このオプションが誤検出の場合は明示的に ``no_log=False`` に設定します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:94 -msgid "nonexistent-parameter-documented" -msgstr "nonexistent-parameter-documented" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:94 -msgid "Argument is listed in DOCUMENTATION.options, but not accepted by the module" -msgstr "引数は DOCUMENTATION.options に一覧表示されますが、モジュールでは受け入れられません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:95 -msgid "option-incorrect-version-added" -msgstr "option-incorrect-version-added" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:95 -msgid "``version_added`` for new option is incorrect" -msgstr "新しいオプションの ``version_added`` は正しくありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:96 -msgid "option-invalid-version-added" -msgstr "option-invalid-version-added" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:96 -msgid "``version_added`` for option is not a valid version number" -msgstr "``version_added`` オプションが有効なバージョン番号ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:97 -msgid "parameter-invalid" -msgstr "parameter-invalid" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:97 -msgid "Argument in argument_spec is not a valid python identifier" -msgstr "argument_spec の引数は有効な python 識別子ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:98 -msgid "parameter-invalid-elements" -msgstr "parameter-invalid-elements" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:98 -msgid "Value for \"elements\" is valid only when value of \"type\" is ``list``" -msgstr "「elements」の値は、「type」の値が ``list`` である場合に限り有効です" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:99 -msgid "implied-parameter-type-mismatch" -msgstr "implied-parameter-type-mismatch" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:99 -msgid "Argument_spec implies ``type=\"str\"`` but documentation defines it as different data type" -msgstr "argument_spec には ``type=\"str\"`` の意が含まれますが、ドキュメントでは、別のデータ型として指定されています" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:100 -msgid "parameter-type-not-in-doc" -msgstr "parameter-type-not-in-doc" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:100 -msgid "Type value is defined in ``argument_spec`` but documentation doesn't specify a type" -msgstr "タイプ値は ``argument_spec`` で定義されていますが、ドキュメントはタイプを指定していません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:101 -msgid "parameter-alias-repeated" -msgstr "parameter-alias-repeated" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:101 -msgid "argument in argument_spec has at least one alias specified multiple times in aliases" -msgstr "argument_spec の引数には、エイリアスに複数回指定されたエイリアスが 1 つ以上含まれます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:102 -msgid "parameter-alias-self" -msgstr "parameter-alias-self" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:102 -msgid "argument in argument_spec is specified as its own alias" -msgstr "argument_spec の引数は、独自のエイリアスとして指定されます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:103 -msgid "parameter-documented-multiple-times" -msgstr "parameter-documented-multiple-times" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:103 -msgid "argument in argument_spec with aliases is documented multiple times" -msgstr "エイリアスを持つ argument_spec の引数が複数回文書化されています" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:104 -msgid "parameter-list-no-elements" -msgstr "parameter-list-no-elements" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:104 -msgid "argument in argument_spec \"type\" is specified as ``list`` without defining \"elements\"" -msgstr "argument_spec「type」の引数は、「要素」を定義せずに ``list`` のように指定されます。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:105 -msgid "parameter-state-invalid-choice" -msgstr "parameter-state-invalid-choice" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:105 -msgid "Argument ``state`` includes ``get``, ``list`` or ``info`` as a choice. Functionality should be in an ``_info`` or (if further conditions apply) ``_facts`` module." -msgstr "引数 ``state`` には、``get``、``list``、または ``info`` が含まれています。機能性は ``_info`` または (追加の条件が適用される場合は) ``_facts`` モジュールである必要があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:106 -msgid "python-syntax-error" -msgstr "python-syntax-error" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:106 -msgid "Python ``SyntaxError`` while parsing module" -msgstr "モジュールの解析中の Python ``SyntaxError``" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:107 -msgid "removal-version-must-be-major" -msgstr "removal-version-must-be-major" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:107 -msgid "According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be removed are major versions (x.0.0)" -msgstr "セマンティックバージョニング仕様 (https://semver.org/) によると、機能の削除が許可されているバージョンはメジャーバージョン (x.0.0) のみです。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:108 -msgid "return-syntax-error" -msgstr "return-syntax-error" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:108 -msgid "``RETURN`` is not valid YAML, ``RETURN`` fragments missing or invalid" -msgstr "``RETURN`` は、有効な YAML ではありません。``RETURN`` フラグメントが見つからないか、無効です。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:109 -msgid "return-invalid-version-added" -msgstr "return-invalid-version-added" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:109 -msgid "``version_added`` for return value is not a valid version number" -msgstr "戻り値の ``version_added`` は、有効なバージョン番号ではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:110 -msgid "subdirectory-missing-init" -msgstr "subdirectory-missing-init" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:110 -msgid "Ansible module subdirectories must contain an ``__init__.py``" -msgstr "Ansible モジュールのサブディレクトリーには ``__init__.py`` が含まれている必要があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:111 -msgid "try-except-missing-has" -msgstr "try-except-missing-has" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:111 -msgid "Try/Except ``HAS_`` expression missing" -msgstr "try/Except ``HAS_`` 式がない" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:112 -msgid "undocumented-parameter" -msgstr "undocumented-parameter" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:112 -msgid "Argument is listed in the argument_spec, but not documented in the module" -msgstr "引数が argument_spec に記載されていますが、このモジュールでは文書化されていません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:113 -msgid "unidiomatic-typecheck" -msgstr "unidiomatic-typecheck" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:113 -msgid "Type comparison using ``type()`` found. Use ``isinstance()`` instead" -msgstr "``type()`` を使用したタイプ比較。代わりに ``isinstance()`` を使用してください。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:114 -msgid "unknown-doc-fragment" -msgstr "unknown-doc-fragment" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:114 -msgid "Unknown pre-existing ``DOCUMENTATION`` error" -msgstr "不明な既存の ``DOCUMENTATION`` エラー" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:115 -msgid "use-boto3" -msgstr "use-boto3" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:115 -msgid "``boto`` import found, new modules should use ``boto3``" -msgstr "``boto`` インポートが見つかりました。代わりに ``boto3`` を使用してください" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:116 -msgid "use-fail-json-not-sys-exit" -msgstr "use-fail-json-not-sys-exit" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:116 -msgid "``sys.exit()`` call found. Should be ``exit_json``/``fail_json``" -msgstr "``sys.exit()`` 呼び出しが見つかりました。``exit_json``/``fail_json`` でなければなりません。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:117 -msgid "use-module-utils-urls" -msgstr "use-module-utils-urls" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:117 -msgid "``requests`` import found, should use ``ansible.module_utils.urls`` instead" -msgstr "``requests`` インポートしています。代わりに ``ansible.module_utils.urls`` を使用してください" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:118 -msgid "use-run-command-not-os-call" -msgstr "use-run-command-not-os-call" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:118 -msgid "``os.call`` used instead of ``module.run_command``" -msgstr "``module.run_command`` の代わりに、``os.call`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:119 -msgid "use-run-command-not-popen" -msgstr "use-run-command-not-popen" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:119 -msgid "``subprocess.Popen`` used instead of ``module.run_command``" -msgstr "``module.run_command`` の代わりに、``subprocess.Popen`` を使用します。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:120 -msgid "use-short-gplv3-license" -msgstr "use-short-gplv3-license" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:120 -msgid "GPLv3 license header should be the :ref:`short form ` for new modules" -msgstr "GPLv3 ライセンスヘッダーは、新しいモジュールの :ref:`短縮形 ` である必要があります" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:121 -msgid "mutually_exclusive-type" -msgstr "mutually_exclusive-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:121 -msgid "mutually_exclusive entry contains non-string value" -msgstr "mutually_exclusive エントリーには文字列以外の値が含まれます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:122 -msgid "mutually_exclusive-collision" -msgstr "mutually_exclusive-collision" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:122 -msgid "mutually_exclusive entry has repeated terms" -msgstr "mutually_exclusive エントリーが繰り返し使用されます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:123 -msgid "mutually_exclusive-unknown" -msgstr "mutually_exclusive-unknown" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:123 -msgid "mutually_exclusive entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "mutually_exclusive エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:124 -msgid "required_one_of-type" -msgstr "required_one_of-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:124 -msgid "required_one_of entry contains non-string value" -msgstr "required_one_of エントリーには文字列以外の値が含まれます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:125 -msgid "required_one_of-collision" -msgstr "required_one_of-collision" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:125 -msgid "required_one_of entry has repeated terms" -msgstr "required_one_of エントリーが繰り返し使用されます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:126 -msgid "required_one_of-unknown" -msgstr "required_one_of-unknown" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:126 -msgid "required_one_of entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_one_of エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:127 -msgid "required_together-type" -msgstr "required_together-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:127 -msgid "required_together entry contains non-string value" -msgstr "required_together エントリーには文字列以外の値が含まれます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:128 -msgid "required_together-collision" -msgstr "required_together-collision" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:128 -msgid "required_together entry has repeated terms" -msgstr "required_together エントリーが繰り返し使用されます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:129 -msgid "required_together-unknown" -msgstr "required_together-unknown" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:129 -msgid "required_together entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_together エントリーには、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:130 -msgid "required_if-is_one_of-type" -msgstr "required_if-is_one_of-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:130 -msgid "required_if entry has a fourth value which is not a bool" -msgstr "required_if エントリーには bool ではない 4 つ目の値がある" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:131 -msgid "required_if-requirements-type" -msgstr "required_if-requirements-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:131 -msgid "required_if entry has a third value (requirements) which is not a list or tuple" -msgstr "required_if エントリーには、リストまたはタプルではない 3 つの値 (必須) があります。" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:132 -msgid "required_if-requirements-collision" -msgstr "required_if-requirements-collision" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:132 -msgid "required_if entry has repeated terms in requirements" -msgstr "required_if エントリーが繰り返し使用されます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:133 -msgid "required_if-requirements-unknown" -msgstr "required_if-requirements-unknown" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:133 -msgid "required_if entry's requirements contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_if エントリーの要件には、argument_spec に表示されないオプションが含まれています (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:134 -msgid "required_if-unknown-key" -msgstr "required_if-unknown-key" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:134 -msgid "required_if entry's key does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_if エントリーのキーが argument_spec に表示されません (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:135 -msgid "required_if-key-in-requirements" -msgstr "required_if-key-in-requirements" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:135 -msgid "required_if entry contains its key in requirements list/tuple" -msgstr "required_if エントリーには要件リスト/タプルのキーが含まれます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:136 -msgid "required_if-value-type" -msgstr "required_if-value-type" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:136 -msgid "required_if entry's value is not of the type specified for its key" -msgstr "required_if エントリーの値は、キーに指定されたタイプではありません" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:137 -msgid "required_by-collision" -msgstr "required_by-collision" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:137 -msgid "required_by entry has repeated terms" -msgstr "required_by エントリーが繰り返し使用されます" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:138 -msgid "required_by-unknown" -msgstr "required_by-unknown" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:138 -msgid "required_by entry contains option which does not appear in argument_spec (potentially an alias of an option?)" -msgstr "required_by エントリーには、argument_spec に表示されないオプションが含まれます (オプションのエイリアスである可能性がありますか?)" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:139 -msgid "version-added-must-be-major-or-minor" -msgstr "version-added-must-be-major-or-minor" - -#: ../../rst/dev_guide/testing/sanity/validate-modules.rst:139 -msgid "According to the semantic versioning specification (https://semver.org/), the only versions in which features are allowed to be added are major and minor versions (x.y.0)" -msgstr "セマンティックバージョニング仕様 (https://semver.org/) によると、機能の追加が許可されているバージョンはメジャーバージョンおよびマイナーバージョン (x.y.0) のみです" - -#: ../../rst/dev_guide/testing/sanity/yamllint.rst:2 -msgid "yamllint" -msgstr "yamllint" - -#: ../../rst/dev_guide/testing/sanity/yamllint.rst:4 -msgid "Check YAML files for syntax and formatting issues." -msgstr "YAML ファイルにおける構文およびフォーマットの問題を確認します。" - -#: ../../rst/dev_guide/testing_compile.rst:6 -msgid "Compile Tests" -msgstr "コンパイルテスト" - -#: ../../rst/dev_guide/testing_compile.rst:8 -msgid "This page has moved to :ref:`testing_compile`." -msgstr "このページは :ref:`testing_compile` に移動しました。" - -#: ../../rst/dev_guide/testing_documentation.rst:8 -msgid "Testing plugin documentation" -msgstr "プラグインドキュメントのテスト" - -#: ../../rst/dev_guide/testing_documentation.rst:10 -msgid "A quick test while developing is to use ``ansible-doc -t `` to see if it renders, you might need to add ``-M /path/to/module`` if the module is not somewhere Ansible expects to find it." -msgstr "開発中の簡単なテストとして、``ansible-doc -t `` を使用してレンダリングされるかどうかを確認できます。Ansible が期待する場所にモジュールがない場合、``-M /path/to/module`` を追加する必要があることもあります。" - -#: ../../rst/dev_guide/testing_documentation.rst:12 -msgid "Before you submit a plugin for inclusion in Ansible, you must test your documentation for correct HTML rendering and for modules to ensure that the argspec matches the documentation in your Python file. The community pages offer more information on :ref:`testing reStructuredText documentation `." -msgstr "Ansible に組み込むプラグインを送信する前に、正しい HTML レンダリングとモジュールについてドキュメントをテストし、argspec が Python ファイルのドキュメントと一致することを確認する必要があります。詳細は、コミュニティーページの :ref:`testing reStructuredText documentation ` を参照してください。" - -#: ../../rst/dev_guide/testing_documentation.rst:15 -msgid "For example, to check the HTML output of your module documentation:" -msgstr "たとえば、モジュールドキュメントの HTML 出力を確認するには、次のコマンドを実行します。" - -#: ../../rst/dev_guide/testing_documentation.rst:17 -msgid "Ensure working :ref:`development environment `." -msgstr ":ref:`開発環境 ` が稼働していることを確認します。" - -#: ../../rst/dev_guide/testing_documentation.rst:18 -#: ../../rst/dev_guide/testing_documentation.rst:32 -msgid "Install required Python packages (drop '--user' in venv/virtualenv):" -msgstr "必要な Python パッケージをインストールします (venv/virtualenv に「--user」をドロップします)。" - -#: ../../rst/dev_guide/testing_documentation.rst:25 -msgid "Ensure your module is in the correct directory: ``lib/ansible/modules/mymodule.py`` or in a configured path." -msgstr "モジュールが正しいディレクトリー (``lib/ansible/modules/mymodule.py``)、または設定されたパスにあることを確認します。" - -#: ../../rst/dev_guide/testing_documentation.rst:26 -msgid "Build HTML from your module documentation: ``MODULES=mymodule make webdocs``." -msgstr "モジュールドキュメント ``MODULES=mymodule make webdocs`` から HTML を構築します。" - -#: ../../rst/dev_guide/testing_documentation.rst:27 -msgid "To build the HTML documentation for multiple modules, use a comma-separated list of module names: ``MODULES=mymodule,mymodule2 make webdocs``." -msgstr "複数のモジュールの HTML ドキュメントを作成するには、モジュール名のコンマ区切りリストを使用します (``MODULES=mymodule,mymodule2 make webdocs``)。" - -#: ../../rst/dev_guide/testing_documentation.rst:28 -msgid "View the HTML page at ``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html``." -msgstr "``file:///path/to/docs/docsite/_build/html/modules/mymodule_module.html`` で HTML ページを表示します。" - -#: ../../rst/dev_guide/testing_documentation.rst:30 -msgid "To ensure that your module documentation matches your ``argument_spec``:" -msgstr "モジュールのドキュメントが ``argument_spec`` と適合するようにするには、以下を行います。" - -#: ../../rst/dev_guide/testing_documentation.rst:38 -msgid "run the ``validate-modules`` test:" -msgstr "``validate-modules`` テストを実行します。" - -#: ../../rst/dev_guide/testing_documentation.rst:44 -msgid "For other plugin types the steps are similar, just adjusting names and paths to the specific type." -msgstr "他のプラグインタイプの場合も手順は同じですが、名前とパスのタイプのみ適宜調整する必要があります。" - -#: ../../rst/dev_guide/testing_httptester.rst:5 -msgid "httptester" -msgstr "httptester" - -#: ../../rst/dev_guide/testing_httptester.rst:10 -msgid "Overview" -msgstr "概要" - -#: ../../rst/dev_guide/testing_httptester.rst:12 -msgid "``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as git or package repos) which, if temporarily unavailable, would cause tests to fail." -msgstr "``httptester`` は、:ref:`testing_integration` で必要な特定のリソースをホストするのに使用される docker コンテナーです。これにより、(git やパッケージリポジトリーなどの) 外部リソースを必要とする CI テストが回避され、一時的に利用できなくなるとテストが失敗します。" - -#: ../../rst/dev_guide/testing_httptester.rst:14 -msgid "HTTP Testing endpoint which provides the following capabilities:" -msgstr "以下の機能を提供する HTTP テストエンドポイントです。" - -#: ../../rst/dev_guide/testing_httptester.rst:16 -msgid "httpbin" -msgstr "httpbin" - -#: ../../rst/dev_guide/testing_httptester.rst:17 -msgid "nginx" -msgstr "nginx" - -#: ../../rst/dev_guide/testing_httptester.rst:18 -msgid "SSL" -msgstr "SSL" - -#: ../../rst/dev_guide/testing_httptester.rst:19 -msgid "SNI" -msgstr "SNI" - -#: ../../rst/dev_guide/testing_httptester.rst:20 -msgid "Negotiate Authentication" -msgstr "認証のネゴシエート" - -#: ../../rst/dev_guide/testing_httptester.rst:23 -msgid "Source files can be found in the `http-test-container `_ repository." -msgstr "ソースファイルは `http-test-container `_ リポジトリーにあります。" - -#: ../../rst/dev_guide/testing_httptester.rst:26 -msgid "Extending httptester" -msgstr "httptester の拡張" - -#: ../../rst/dev_guide/testing_httptester.rst:28 -msgid "If you have sometime to improve ``httptester`` please add a comment on the `Testing Working Group Agenda `_ to avoid duplicated effort." -msgstr "``httptester`` を改善するタイミングがある場合は、重複作業を回避するために、`Testing Working Group Agenda `_ にコメントを追加してください。" - -#: ../../rst/dev_guide/testing_integration.rst:11 -msgid "The Ansible integration Test system." -msgstr "Ansible 統合テストシステム。" - -#: ../../rst/dev_guide/testing_integration.rst:13 -msgid "Tests for playbooks, by playbooks." -msgstr "Playbook による Playbook のテスト" - -#: ../../rst/dev_guide/testing_integration.rst:15 -msgid "Some tests may require credentials. Credentials may be specified with `credentials.yml`." -msgstr "テストによっては認証情報が必要になる場合があります。認証情報は `credentials.yml` で指定できます。" - -#: ../../rst/dev_guide/testing_integration.rst:17 -msgid "Some tests may require root." -msgstr "テストによっては root が必要になる場合があります。" - -#: ../../rst/dev_guide/testing_integration.rst:20 -msgid "Every new module and plugin should have integration tests, even if the tests cannot be run on Ansible CI infrastructure. In this case, the tests should be marked with the ``unsupported`` alias in `aliases file `_." -msgstr "テストを Ansible CI インフラストラクチャーで実行できない場合でも、新しいモジュールとプラグインには統合テストが必要です。この場合、テストは `aliases ファイル `_ の ``unsupported`` エイリアスでマーク付けする必要があります。" - -#: ../../rst/dev_guide/testing_integration.rst:24 -msgid "Quick Start" -msgstr "クイックスタート" - -#: ../../rst/dev_guide/testing_integration.rst:26 -msgid "It is highly recommended that you install and activate the ``argcomplete`` python package. It provides tab completion in ``bash`` for the ``ansible-test`` test runner." -msgstr "python パッケージ ``argcomplete`` をインストールし、アクティベートすることが強く推奨されます。これにより、テストランナー ``ansible-test`` に ``bash`` のタブ補完が提供されます。" - -#: ../../rst/dev_guide/testing_integration.rst:30 -msgid "Configuration" -msgstr "Configuration (構成)" - -#: ../../rst/dev_guide/testing_integration.rst:33 -msgid "ansible-test command" -msgstr "ansible-test コマンド" - -#: ../../rst/dev_guide/testing_integration.rst:35 -msgid "The example below assumes ``bin/`` is in your ``$PATH``. An easy way to achieve that is to initialize your environment with the ``env-setup`` command:" -msgstr "以下の例では、``bin/`` が ``$PATH`` であることを前提としています。これは、``env-setup`` コマンドで環境を初期化する簡単な方法になります。" - -#: ../../rst/dev_guide/testing_integration.rst:43 -msgid "You can also call ``ansible-test`` with the full path:" -msgstr "完全パスで ``ansible-test`` を呼び出すこともできます。" - -#: ../../rst/dev_guide/testing_integration.rst:50 -msgid "integration_config.yml" -msgstr "integration_config.yml" - -#: ../../rst/dev_guide/testing_integration.rst:52 -msgid "Making your own version of ``integration_config.yml`` can allow for setting some tunable parameters to help run the tests better in your environment. Some tests (for example, cloud tests) will only run when access credentials are provided. For more information about supported credentials, refer to the various ``cloud-config-*.template`` files in the ``test/integration/`` directory." -msgstr "自身で作成した ``integration_config.yml`` があると、一部の調整可能なパラメーターを設定して、環境により適切にテストを実行できます。一部のテスト (クラウドテストなど) は、アクセス認証情報が提供されている場合にのみ実行されます。サポート対象の認証情報の詳細は、``test/integration/`` ディレクトリーでさまざまな ``cloud-config-*.template`` ファイルを参照してください。" - -#: ../../rst/dev_guide/testing_integration.rst:61 -msgid "Some tests assume things like hg, svn, and git are installed, and in path. Some tests (such as those for Amazon Web Services) need separate definitions, which will be covered later in this document." -msgstr "一部のテストでは、hg、svn、git などがインストールされ、パスにあることを前提としています。一部のテスト (Amazon Web Services のテストなど) には個別の定義が必要です。これについては、このドキュメントの後半で説明します。" - -#: ../../rst/dev_guide/testing_integration.rst:65 -msgid "(Complete list pending)" -msgstr "(完全はリストは後日追加されます)" - -#: ../../rst/dev_guide/testing_integration.rst:68 -msgid "Non-destructive Tests" -msgstr "非破壊テスト" - -#: ../../rst/dev_guide/testing_integration.rst:70 -msgid "These tests will modify files in subdirectories, but will not do things that install or remove packages or things outside of those test subdirectories. They will also not reconfigure or bounce system services." -msgstr "これらのテストはサブディレクトリー内のファイルを修正しますが、パッケージやテストのサブディレクトリー以外にあるものをインストールしたり削除したりするようなことはしません。また、システムサービスの再設定やバウンスも行いません。" - -#: ../../rst/dev_guide/testing_integration.rst:73 -msgid "Running integration tests within containers" -msgstr "コンテナー内での統合テストの実行" - -#: ../../rst/dev_guide/testing_integration.rst:75 -msgid "To protect your system from any potential changes caused by integration tests, and to ensure a sensible set of dependencies are available we recommend that you always run integration tests with the ``--docker`` option, for example ``--docker ubuntu2004``. See the `list of supported container images `_ for options (the ``default`` image is used for sanity and unit tests, as well as for platform independent integration tests such as those for cloud modules)." -msgstr "統合テストによる潜在的な変更からシステムを守り、適切な依存関係セットが利用可能になるようにするには、常に ``--docker`` オプションをつけて統合テストを実行することが推奨されます (``--docker ubuntu2004`` など)。オプションについては、`list of supported container images `_を参照してください (``default`` イメージは、健全性テストとユニットテスト、およびクラウドモジュールなどのプラットフォームに依存しない統合テストに使用されます)。" - -#: ../../rst/dev_guide/testing_integration.rst:77 -msgid "Run as follows for all POSIX platform tests executed by our CI system in a Fedora 34 container:" -msgstr "Fedora 34 コンテナーで CI システムによって実行されるすべての POSIX プラットフォームテストに対して次のように実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:83 -msgid "You can target a specific tests as well, such as for individual modules:" -msgstr "個々のモジュールなど、特定のテストを対象とすることもできます。" - -#: ../../rst/dev_guide/testing_integration.rst:89 -msgid "You can use the ``-v`` option to make the output more verbose:" -msgstr "``-v`` オプションを使用すると、出力をさらに詳細にすることができます。" - -#: ../../rst/dev_guide/testing_integration.rst:95 -msgid "Use the following command to list all the available targets:" -msgstr "利用可能なターゲットの一覧を表示するには、以下のコマンドを実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:101 -msgid "Bash users" -msgstr "Bash ユーザー" - -#: ../../rst/dev_guide/testing_integration.rst:103 -msgid "If you use ``bash`` with ``argcomplete``, obtain a full list by doing: ``ansible-test integration ``" -msgstr "``bash`` を ``argcomplete`` とともに使用する場合は、``ansible-test integration `` を実行して完全な一覧を取得します。" - -#: ../../rst/dev_guide/testing_integration.rst:106 -msgid "Destructive Tests" -msgstr "破壊テスト" - -#: ../../rst/dev_guide/testing_integration.rst:108 -msgid "These tests are allowed to install and remove some trivial packages. You will likely want to devote these to a virtual environment, such as Docker. They won't reformat your filesystem:" -msgstr "これらのテストでは、いくつかの簡単なパッケージをインストールおよび削除できます。これらを Docker などの仮想環境専用にすることが推奨されます。これらは、ファイルシステムを再フォーマットしません。" - -#: ../../rst/dev_guide/testing_integration.rst:116 -msgid "Windows Tests" -msgstr "Windows テスト" - -#: ../../rst/dev_guide/testing_integration.rst:118 -msgid "These tests exercise the ``winrm`` connection plugin and Windows modules. You'll need to define an inventory with a remote Windows Server to use for testing, and enable PowerShell Remoting to continue." -msgstr "これらのテストは、``winrm`` connection プラグインと Windows モジュールに従います。テストに使用するリモート Windows Server を持つインベントリーを定義し、PowerShell Remoting を継続できるようにする必要があります。" - -#: ../../rst/dev_guide/testing_integration.rst:122 -msgid "Running these tests may result in changes to your Windows host, so don't run them against a production/critical Windows environment." -msgstr "これらのテストを実行すると、Windows ホストが変更になる可能性があるため、実稼働環境や重要な Windows 環境では実行しないでください。" - -#: ../../rst/dev_guide/testing_integration.rst:125 -msgid "Enable PowerShell Remoting (run on the Windows host by a Remote Desktop):" -msgstr "PowerShell Remoting を有効にします (リモートデスクトップを介して Windows ホストで実行します)。" - -#: ../../rst/dev_guide/testing_integration.rst:131 -msgid "Define Windows inventory:" -msgstr "Windows インベントリーを定義します。" - -#: ../../rst/dev_guide/testing_integration.rst:138 -msgid "Run the Windows tests executed by our CI system:" -msgstr "CI システムで実行する Windows テストを実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:145 -msgid "Tests in containers" -msgstr "コンテナーでのテスト" - -#: ../../rst/dev_guide/testing_integration.rst:147 -msgid "If you have a Linux system with Docker or Podman installed, running integration tests using the same containers used by the Ansible continuous integration (CI) system is recommended." -msgstr "DockerまたはPodman がインストールされた Linux システムをお持ちの場合は、Ansible の継続的統合 (CI) システムで使用されているものと同じコンテナーを使用して統合テストを実行することが推奨されます。" - -#: ../../rst/dev_guide/testing_integration.rst:150 -#: ../../rst/dev_guide/testing_running_locally.rst:279 -msgid "Podman" -msgstr "Podman" - -#: ../../rst/dev_guide/testing_integration.rst:152 -msgid "By default, Podman will only be used if the Docker CLI is not installed. If you have Docker installed but want to use Podman, you can change this behavior by setting the environment variable ``ANSIBLE_TEST_PREFER_PODMAN``." -msgstr "デフォルトで、Podman は Docker CLI がインストールされていない場合にのみ使用されます。Docker がインストールされていて Podman を使用する必要がある場合は、環境変数 ``ANSIBLE_TEST_PREFER_PODMAN`` を設定してこの動作を変更できます。" - -#: ../../rst/dev_guide/testing_integration.rst:155 -msgid "Docker on non-Linux" -msgstr "Linux 以外の Docker" - -#: ../../rst/dev_guide/testing_integration.rst:157 -msgid "Using Docker Engine to run Docker on a non-Linux host (such as macOS) is not recommended. Some tests may fail, depending on the image used for testing. Using the ``--docker-privileged`` option when running ``integration`` (not ``network-integration`` or ``windows-integration``) may resolve the issue." -msgstr "Docker Engine を使用して (macOS などの) Linux 以外のホストで Docker を実行することは推奨されません。テストに使用されるイメージによっては、一部のテストが失敗する可能性があります。(``network-integration`` または ``windows-integration``ではなく) ``integration`` の実行時に ``--docker-privileged`` オプションを使用すると問題が解決する可能性があります。" - -#: ../../rst/dev_guide/testing_integration.rst:162 -msgid "Running Integration Tests" -msgstr "統合テストの実行" - -#: ../../rst/dev_guide/testing_integration.rst:164 -msgid "To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container:" -msgstr "Ubuntu 18.04 コンテナー内の POSIX プラットフォームに CI 統合テストターゲットすべてを実行するには、次のコマンドを実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:170 -msgid "You can also run specific tests or select a different Linux distribution. For example, to run tests for the ``ping`` module on a Ubuntu 18.04 container:" -msgstr "特定のテストを実行することも、別の Linux ディストリビューションを選択することもできます。たとえば、Ubuntu 18.04 コンテナーで ``ping`` モジュールのテストを実行するには、次を実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:180 -msgid "Container Images" -msgstr "コンテナーイメージ" - -#: ../../rst/dev_guide/testing_integration.rst:182 -msgid "Container images are updated regularly. To see the current list of container images:" -msgstr "コンテナーイメージは定期的に更新されます。現在のコンテナーイメージ一覧を表示するには、以下を実行します。" - -#: ../../rst/dev_guide/testing_integration.rst:188 -msgid "The list is under the **target docker images and supported python version** heading." -msgstr "この一覧は、**target docker images and supported python version** の見出しの下にあります。" - -#: ../../rst/dev_guide/testing_integration.rst:191 -msgid "Other configuration for Cloud Tests" -msgstr "クラウドテストのその他の設定" - -#: ../../rst/dev_guide/testing_integration.rst:193 -msgid "In order to run some tests, you must provide access credentials in a file named ``cloud-config-aws.yml`` or ``cloud-config-cs.ini`` in the test/integration directory. Corresponding .template files are available for for syntax help. The newer AWS tests now use the file test/integration/cloud-config-aws.yml" -msgstr "test/integration ディレクトリーにある ``cloud-config-aws.yml`` または ``cloud-config-cs.ini`` という名前のファイルにあるアクセス認証情報を指定する必要があります。構文ヘルプでは、対応する .template ファイルを利用できます。新しい AWS テストでは、test/integration/cloud-config-aws.yml ファイルが使用されるようになりました。" - -#: ../../rst/dev_guide/testing_integration.rst:199 -msgid "IAM policies for AWS" -msgstr "AWS の IAM ポリシー" - -#: ../../rst/dev_guide/testing_integration.rst:201 -msgid "Ansible needs fairly wide ranging powers to run the tests in an AWS account. This rights can be provided to a dedicated user. These need to be configured before running the test." -msgstr "Ansible は、AWS アカウントでテストを実行するために非常に幅広い権限が必要になります。この権限は専用のユーザーに提供できます。これらの権限は、テストを実行する前に設定する必要があります。" - -#: ../../rst/dev_guide/testing_integration.rst:204 -msgid "testing-policies" -msgstr "testing-policies" - -#: ../../rst/dev_guide/testing_integration.rst:206 -msgid "The GitHub repository `mattclay/aws-terminator `_ contains two sets of policies used for all existing AWS module integratoin tests. The `hacking/aws_config/setup_iam.yml` playbook can be used to setup two groups:" -msgstr "GitHub リポジトリー `mattclay/aws-terminator `_ には、既存の AWS モジュールの統合テストに使用するポリシーのセットが 2 つ含まれます。Playbook `hacking/aws_config/setup_iam.yml` を使用すると、2 つのグループを設定できます。" - -#: ../../rst/dev_guide/testing_integration.rst:210 -msgid "`ansible-integration-ci` will have the policies applied necessary to run any integration tests not marked as `unsupported` and are designed to mirror those used by Ansible's CI." -msgstr "`ansible-integration-ci` は、統合テストの実行に必要となるポリシーを適用すると共に、`unsupported` と識別されず、Ansible の CI で使用されるミラーリング用に設計されています。" - -#: ../../rst/dev_guide/testing_integration.rst:213 -msgid "`ansible-integration-unsupported` will have the additional policies applied necessary to run the integration tests marked as `unsupported` including tests for managing IAM roles, users and groups." -msgstr "`ansible-integration-unsupported` は、IAM ロール、ユーザー、およびグループを管理するためのテストを含む `unsupported` とマークされた統合テストの実行に必要な追加のポリシーが適用されます。" - -#: ../../rst/dev_guide/testing_integration.rst:217 -msgid "Once the groups have been created, you'll need to create a user and make the user a member of these groups. The policies are designed to minimize the rights of that user. Please note that while this policy does limit the user to one region, this does not fully restrict the user (primarily due to the limitations of the Amazon ARN notation). The user will still have wide privileges for viewing account definitions, and will also able to manage some resources that are not related to testing (for example, AWS lambdas with different names). Tests should not be run in a primary production account in any case." -msgstr "グループが作成されたら、ユーザーを作成して、そのユーザーをこれらのグループのメンバーにする必要があります。ポリシーは、そのユーザーの権利を最小限にするためのものです。このポリシーでは、ユーザーを 1 つの地域に限定していますが、これはユーザーを完全には制限していないことに注意してください (主に Amazon ARN 表記の制限によるものです)。このユーザーは、アカウント定義を閲覧するための広い権限を持っており、テストに関係のないいくつかのリソース (たとえば、異なる名前の AWS ラムダ) を管理することもできます。どのような場合でも、テストを実稼働環境用のプライマリーアカウントで実行すべきではありません。" - -#: ../../rst/dev_guide/testing_integration.rst:225 -msgid "Other Definitions required" -msgstr "その他に必要な定義" - -#: ../../rst/dev_guide/testing_integration.rst:227 -msgid "Apart from installing the policy and giving it to the user identity running the tests, a lambda role `ansible_integration_tests` has to be created which has lambda basic execution privileges." -msgstr "ポリシーをインストールして、テストを実行しているユーザ ID にそれを付与することとは別に、ラムダロール `ansible_integration_tests` を作成する必要があります。これは、ラムダの基本的な実行権限を持ちます。" - -#: ../../rst/dev_guide/testing_integration.rst:233 -msgid "Network Tests" -msgstr "ネットワークテスト" - -#: ../../rst/dev_guide/testing_integration.rst:235 -msgid "For guidance on writing network test see :ref:`testing_resource_modules`." -msgstr "ネットワークテストの書き込みに関する情報は、「:ref:`testing_resource_modules`」を参照してください。" - -#: ../../rst/dev_guide/testing_integration.rst:239 -msgid "Where to find out more" -msgstr "その他の詳細情報" - -#: ../../rst/dev_guide/testing_integration.rst:241 -msgid "If you'd like to know more about the plans for improving testing Ansible, join the `Testing Working Group `_." -msgstr "Ansible テストを改善する詳細な計画を確認したい場合は、`Testing Working Group `_ にご参加ください。" - -#: ../../rst/dev_guide/testing_pep8.rst:6 -msgid "PEP 8" -msgstr "PEP 8" - -#: ../../rst/dev_guide/testing_pep8.rst:8 -msgid "This page has moved to :ref:`testing_pep8`." -msgstr "このページは :ref:`testing_pep8` に移動しました。" - -#: ../../rst/dev_guide/testing_running_locally.rst:7 -msgid "Testing Ansible and Collections" -msgstr "Ansible とコレクションのテスト" - -#: ../../rst/dev_guide/testing_running_locally.rst:9 -msgid "This document describes how to run tests using ``ansible-test``." -msgstr "このドキュメントでは、``ansible-test`` を使用してテストを実行する方法について説明します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:17 -msgid "Before running ``ansible-test``, set up your environment for :ref:`testing_an_ansible_collection` or :ref:`testing_ansible_core`, depending on which scenario applies to you." -msgstr "``ansible-test`` を実行する前に、該当するシナリオに応じて :ref:`testing_an_ansible_collection` または :ref:`testing_ansible_core` の環境を設定します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:22 -msgid "If you use ``git`` for version control, make sure the files you are working with are not ignored by ``git``. If they are, ``ansible-test`` will ignore them as well." -msgstr "萬ジョン管理に ``git`` を使用する場合、``git`` が作業中のファイルを無視しないことを確認してください。無視する場合、``ansible-test`` も同様に無視します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:28 -msgid "Testing an Ansible Collection" -msgstr "Ansible コレクションのテスト" - -#: ../../rst/dev_guide/testing_running_locally.rst:30 -msgid "If you are testing an Ansible Collection, you need a copy of the collection, preferably a git clone. For example, to work with the ``community.windows`` collection, follow these steps:" -msgstr "Ansible コレクションをテストする場合は、コレクションの複製 (できれば git クローン) が必要です。たとえば ``community.windows`` コレクションで作業する場合、次の手順に従います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:33 -msgid "Clone the collection you want to test into a valid collection root:" -msgstr "テストするコレクションを有効なコレクションルートに複製します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:41 -msgid "The path must end with ``/ansible_collections/{collection_namespace}/{collection_name}`` where ``{collection_namespace}`` is the namespace of the collection and ``{collection_name}`` is the collection name." -msgstr "パスは ``/ansible_collections/{collection_namespace}/{collection_name}`` で終わるものとします。この場合の ``{collection_namespace}`` はコレクションの名前空間、``{collection_name}`` はコレクション名です。" - -#: ../../rst/dev_guide/testing_running_locally.rst:44 -msgid "Clone any collections on which the collection depends:" -msgstr "コレクションが依存するコレクションを複製します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:52 -msgid "If your collection has any dependencies on other collections, they must be in the same collection root, since ``ansible-test`` will not use your configured collection roots (or other Ansible configuration)." -msgstr "``ansible-test`` では設定されたコレクションルート (または他の Ansible 設定) は使用されないため、コレクションが他のコレクションに依存している場合、それらは同じコレクションルートにある必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:57 -msgid "See the collection's ``galaxy.yml`` for a list of possible dependencies." -msgstr "可能性のある依存関係のリストは、コレクションの ``galaxy.yml`` で確認できます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:59 -msgid "Switch to the directory where the collection to test resides:" -msgstr "テストするコレクションが存在するディレクトリーに切り替えます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:68 -msgid "Testing ``ansible-core``" -msgstr "``ansible-core`` のテスト" - -#: ../../rst/dev_guide/testing_running_locally.rst:70 -msgid "If you are testing ``ansible-core`` itself, you need a copy of the ``ansible-core`` source code, preferably a git clone. Having an installed copy of ``ansible-core`` is not sufficient or required. For example, to work with the ``ansible-core`` source cloned from GitHub, follow these steps:" -msgstr "``ansible-core`` をテストしている場合、``ansible-core`` のソースコードのコピー (できれば git クローン) が必要です。``ansible-core`` のコピーがインストールされているだけでは不十分な場合があり、それが必須ではない場合もあります。たとえば、GitHub から複製された ``ansible-core``ソースを処理する場合、次の手順に従います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:74 -msgid "Clone the ``ansible-core`` repository:" -msgstr "``ansible-core`` リポジトリーのクローンを作成します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:80 -msgid "Switch to the directory where the ``ansible-core`` source resides:" -msgstr "``ansible-core`` ソースがあるディレクトリーに切り替えます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:86 -msgid "Add ``ansible-core`` programs to your ``PATH``:" -msgstr "``PATH`` に ``ansible-core`` プログラムを追加します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:94 -msgid "You can skip this step if you only need to run ``ansible-test``, and not other ``ansible-core`` programs. In that case, simply run ``bin/ansible-test`` from the root of the ``ansible-core`` source." -msgstr "実行する必要があるのが ``ansible-test`` のみで、その他の ``ansible-core`` プログラムは必要なければ、この手順は省略できます。その場合、``ansible-core`` ソースのルートから ``bin/ansible-test`` を実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:99 -msgid "If you have an installed version of ``ansible-core`` and are trying to run ``ansible-test`` from your ``PATH``, make sure the program found by your shell is the one from the ``ansible-core`` source:" -msgstr "``ansible-core`` のインストール済みバージョンがあり、自分の ``PATH`` から ``ansible-test`` の実行を試みている場合、シェルによって検出されたプログラムが ``ansible-core`` ソースからのものと一致することを確認してください。" - -#: ../../rst/dev_guide/testing_running_locally.rst:107 -msgid "Commands" -msgstr "コマンド" - -#: ../../rst/dev_guide/testing_running_locally.rst:109 -msgid "The most commonly used test commands are:" -msgstr "最も一般的に使用されるテストコマンドは次のとおりです。" - -#: ../../rst/dev_guide/testing_running_locally.rst:111 -msgid "``ansible-test sanity`` - Run sanity tests (mostly linters and static analysis)." -msgstr "``ansible-test sanity`` - 健全性テスト (主にリンターと静的解析) を実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:112 -msgid "``ansible-test integration`` - Run integration tests." -msgstr "``ansible-test integration`` - 統合テストを実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:113 -msgid "``ansible-test units`` - Run unit tests." -msgstr "``ansible-test units`` - ユニットテストを実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:115 -msgid "Run ``ansible-test --help`` to see a complete list of available commands." -msgstr "``ansible-test --help`` を実行して、使用可能なコマンドの完全なリストを表示します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:119 -msgid "For detailed help on a specific command, add the ``--help`` option after the command." -msgstr "特定コマンドの詳しいヘルプについては、コマンドの後に ``--help`` オプションを追加します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:122 -msgid "Environments" -msgstr "環境" - -#: ../../rst/dev_guide/testing_running_locally.rst:124 -msgid "Most ``ansible-test`` commands support running in one or more isolated test environments to simplify testing." -msgstr "ほとんどの ``ansible-test`` コマンドは、テストを簡単にするために、1 つ以上の分離テスト環境での実行をサポートします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:127 -msgid "Containers" -msgstr "コンテナー" - -#: ../../rst/dev_guide/testing_running_locally.rst:129 -msgid "Containers are recommended for running sanity, unit and integration tests, since they provide consistent environments. Unit tests will be run with network isolation, which avoids unintentional dependencies on network resources." -msgstr "コンテナーは一貫した環境を提供するため、健全性テスト、ユニットテスト、統合テストの実行に推奨されます。ユニットテストは、ネットワークリソースへの意図しない依存を回避するため、ネットワークを分離して実行されます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:132 -msgid "The ``--docker`` option runs tests in a container using either Docker or Podman." -msgstr "``--docker`` オプションは、Docker または Podman を使用してコンテナーでテストを実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:136 -msgid "If both Docker and Podman are installed, Docker will be used. To override this, set the environment variable ``ANSIBLE_TEST_PREFER_PODMAN`` to any non-empty value." -msgstr "Docker と Podman の両方がインストールされている場合は、Docker が使用されます。これをオーバーライドするには、環境変数 ``ANSIBLE_TEST_PREFER_PODMAN`` を空でない任意の値に設定します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:140 -msgid "Choosing a container" -msgstr "コンテナーの選択" - -#: ../../rst/dev_guide/testing_running_locally.rst:142 -msgid "Without an additional argument, the ``--docker`` option uses the ``default`` container. To use another container, specify it immediately after the ``--docker`` option." -msgstr "追加の引数がなければ、``--docker`` オプションは ``default`` コンテナーを使用します。別のコンテナーを使用するには、``--docker`` オプションのすぐ後に指定します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:147 -msgid "The ``default`` container is recommended for all sanity and unit tests." -msgstr "``default`` コンテナーは、すべての健全性テストとユニットテストに推奨されます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:149 -msgid "To see the list of supported containers, use the ``--help`` option with the ``ansible-test`` command you want to use." -msgstr "サポート対象コンテナーのリストを表示するには、使用する ``ansible-test`` コマンドで ``--help`` オプションを使用します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:153 -msgid "The list of available containers is dependent on the ``ansible-test`` command you are using." -msgstr "利用可能なコンテナーのリストは、使用している ``ansible-test`` コマンドにより異なります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:155 -msgid "You can also specify your own container. When doing so, you will need to indicate the Python version in the container with the ``--python`` option." -msgstr "独自のコンテナーを指定することもできます。その場合は、``--python`` オプションでコンテナー内の Python バージョンを示す必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:159 -msgid "Custom containers" -msgstr "カスタムコンテナー" - -#: ../../rst/dev_guide/testing_running_locally.rst:161 -msgid "When building custom containers, keep in mind the following requirements:" -msgstr "カスタムコンテナーを構築する際には、次の要件に注意してください。" - -#: ../../rst/dev_guide/testing_running_locally.rst:163 -msgid "The ``USER`` should be ``root``." -msgstr "``USER`` は ``root`` にする必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:164 -msgid "Use an ``init`` process, such as ``systemd``." -msgstr "``systemd`` などの ``init`` プロセスを使用します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:165 -msgid "Include ``sshd`` and accept connections on the default port of ``22``." -msgstr "``sshd`` を含め、``22`` のデフォルトポートで接続を許可します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:166 -msgid "Include a POSIX compatible ``sh`` shell which can be found on ``PATH``." -msgstr "``PATH`` で見つけることができる POSIX 五感 ``sh`` シェルを含めます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:167 -msgid "Include a ``sleep`` utility which runs as a subprocess." -msgstr "サブプロセスとして実行される ``sleep`` ユーティリティーを含めます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:168 -msgid "Include a supported version of Python." -msgstr "サポート対象の Python バージョンを含めます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:169 -msgid "Avoid using the ``VOLUME`` statement." -msgstr "``VOLUME`` statement の使用は避けてください。" - -#: ../../rst/dev_guide/testing_running_locally.rst:172 -msgid "Docker and SELinux" -msgstr "Docker と SELinux" - -#: ../../rst/dev_guide/testing_running_locally.rst:174 -msgid "Using Docker on a host with SELinux may require setting the system in permissive mode. Consider using Podman instead." -msgstr "SELinux を使用するホストで Docker を使用するには、システムを permissive モードに設定する必要がある場合があります。代わりに Podman の使用を検討してください。" - -#: ../../rst/dev_guide/testing_running_locally.rst:178 -msgid "Docker Desktop with WSL2" -msgstr "Docker Desktop と WSL2" - -#: ../../rst/dev_guide/testing_running_locally.rst:180 -msgid "These instructions explain how to use ``ansible-test`` with WSL2 and Docker Desktop *without* ``systemd`` support." -msgstr "これらの指示は、``systemd`` サポート*なし*で、``ansible-test`` で WSL2 と Docker Desktop を使用する方法について説明しています。" - -#: ../../rst/dev_guide/testing_running_locally.rst:184 -msgid "If your WSL2 environment includes ``systemd`` support, these steps are not required." -msgstr "WSL2 環境に ``systemd`` サポートが含まれている場合、これらの手順は必要ありません。" - -#: ../../rst/dev_guide/testing_running_locally.rst:189 -msgid "Configuration requirements" -msgstr "設定要件" - -#: ../../rst/dev_guide/testing_running_locally.rst:191 -msgid "Open Docker Desktop and go to the **Settings** screen." -msgstr "Docker Desktop を開き、**Settings** 画面に移動します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:192 -msgid "On the the **General** tab:" -msgstr "**General** タブで、以下を行います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:194 -msgid "Uncheck the **Start Docker Desktop when you log in** checkbox." -msgstr "**Start Docker Desktop when you log in** チェックボックスをオフにします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:195 -msgid "Check the **Use the WSL 2 based engine** checkbox." -msgstr "**Use the WSL 2 based engine** チェックボックスをオンにします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:197 -msgid "On the **Resources** tab under the **WSL Integration** section:" -msgstr "**WSL Integration** セクションの **Resources** タブで、以下を行います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:199 -msgid "Enable distros you want to use under the **Enable integration with additional distros** section." -msgstr "**Enable integration with additional distros**セクションで、使用する distros を有効にします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:201 -msgid "Click **Apply and restart** if changes were made." -msgstr "変更した場合は **Apply and restart** をクリックします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:206 -msgid "Setup instructions" -msgstr "設定手順" - -#: ../../rst/dev_guide/testing_running_locally.rst:210 -msgid "If all WSL instances have been stopped, these changes will need to be re-applied." -msgstr "すべての WSL インスタンスが停止している場合は、これらの変更を再度適用する必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:212 -msgid "Verify Docker Desktop is properly configured (see :ref:`configuration_requirements`)." -msgstr "Docker Desktop が適切に設定されていることを確認します (:ref:`configuration_requirements` 参照)。" - -#: ../../rst/dev_guide/testing_running_locally.rst:213 -msgid "Quit Docker Desktop if it is running:" -msgstr "実行中の場合は Docker Desktop を終了します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:215 -msgid "Right click the **Docker Desktop** taskbar icon." -msgstr "**Docker Desktop** タスクバーアイコンを右クリックします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:216 -msgid "Click the **Quit Docker Desktop** option." -msgstr "**Quit Docker Desktop** オプションをクリックします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:218 -msgid "Stop any running WSL instances with the command:" -msgstr "次のコマンドを使用して、実行中の WSL インスタンスを停止します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:224 -msgid "Verify all WSL instances have stopped with the command:" -msgstr "次のコマンドを使用して、すべての WSL インスタンスが停止したことを確認します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:230 -msgid "Start a WSL instance and perform the following steps as ``root``:" -msgstr "WSL インスタンスを開始し、``root`` として次の手順を実行します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:232 -msgid "Verify the ``systemd`` subsystem is not registered:" -msgstr "``systemd`` サブシステムが登録されていないことを検証します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:234 -msgid "Check for the ``systemd`` cgroup hierarchy with the following command:" -msgstr "次のコマンドを使用して、``systemd`` cgroup 階層を確認します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:240 -msgid "If any matches are found, re-check the :ref:`configuration_requirements` and follow the :ref:`setup_instructions` again." -msgstr "一致するものが見つかった場合は、:ref:`configuration_requirements` を再確認し、再度 :ref:`setup_instructions` に従います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:243 -msgid "Mount the ``systemd`` cgroup hierarchy with the following commands:" -msgstr "次のコマンドを使用して、``systemd`` cgroup 階層をマウントします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:250 -msgid "Start Docker Desktop." -msgstr "Docker Desktop を起動します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:252 -msgid "You should now be able to use ``ansible-test`` with the ``--docker`` option." -msgstr "これで、``--docker`` オプションで ``ansible-test`` を使用できるようになりました。" - -#: ../../rst/dev_guide/testing_running_locally.rst:257 -msgid "Linux cgroup configuration" -msgstr "Linux cgroup 設定" - -#: ../../rst/dev_guide/testing_running_locally.rst:261 -msgid "These changes will need to be re-applied each time the container host is booted." -msgstr "これらの変更は、コンテナーホストを起動するたびに再適用する必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:263 -msgid "For certain container hosts and container combinations, additional setup on the container host may be required. In these situations ``ansible-test`` will report an error and provide additional instructions to run as ``root``:" -msgstr "特定のコンテナーホストとコンテナーの組み合わせでは、コンテナーホストで追加のセットアップが必要になる場合があります。そのような状況では、``ansible-test`` がエラーを報告し、``root`` として実行するように追加の指示を出します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:271 -msgid "If you are using rootless Podman, an additional command must be run, also as ``root``. Make sure to substitute your user and group for ``{user}`` and ``{group}`` respectively:" -msgstr "rootless Podman を使用している場合は、同様に ``root`` として追加のコマンドを実行する必要があります。必ずユーザーとグループを、それぞれ ``{user}`` と ``{group}`` に置き換えてください。" - -#: ../../rst/dev_guide/testing_running_locally.rst:281 -msgid "When using Podman, you may need to stop existing Podman processes after following the :ref:`linux_cgroup_configuration` instructions. Otherwise Podman may be unable to see the new mount point." -msgstr "Podman を使用する場合、:ref:`linux_cgroup_configuration` の手順を実行した後に既存の Podman プロセスを停止する必要があることがあります。そうしなければ、Podman が新しいマウントポイントを認識できない可能性があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:284 -msgid "You can check to see if Podman is running by looking for ``podman`` and ``catatonit`` processes." -msgstr "Podman が実行されているかどうかを確認するには、``podman`` と ``catatonit`` のプロセスを確認します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:287 -msgid "Remote virtual machines" -msgstr "リモート仮想マシン" - -#: ../../rst/dev_guide/testing_running_locally.rst:289 -msgid "Remote virtual machines are recommended for running integration tests not suitable for execution in containers." -msgstr "コンテナーでの実行に適していない統合テストの実行には、リモート仮想マシンをお勧めします。" - -#: ../../rst/dev_guide/testing_running_locally.rst:291 -msgid "The ``--remote`` option runs tests in a cloud hosted ephemeral virtual machine." -msgstr "``--remote`` オプションを使用すると、クラウドでホストされた一時的な仮想マシンでテストが実行されます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:295 -msgid "An API key is required to use this feature, unless running under an approved Azure Pipelines organization." -msgstr "承認された Azure Pipelines 組織下で実行されている場合を除き、この機能を使用するには API キーが必要です。" - -#: ../../rst/dev_guide/testing_running_locally.rst:297 -msgid "To see the list of supported systems, use the ``--help`` option with the ``ansible-test`` command you want to use." -msgstr "サポート対象システムのリストを表示するには、使用する ``ansible-test`` コマンドで ``--help`` オプションを使用します。" - -#: ../../rst/dev_guide/testing_running_locally.rst:301 -msgid "The list of available systems is dependent on the ``ansible-test`` command you are using." -msgstr "利用可能なシステムのリストは、使用している ``ansible-test`` コマンドにより異なります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:304 -msgid "Python virtual environments" -msgstr "Python 仮想環境" - -#: ../../rst/dev_guide/testing_running_locally.rst:306 -msgid "Python virtual environments provide a simple way to achieve isolation from the system and user Python environments. They are recommended for unit and integration tests when the ``--docker`` and ``--remote`` options cannot be used." -msgstr "Python 仮想環境を使用すると、システムおよびユーザーの Python 環境からの分離を簡単に実現できます。これは、``--docker`` および ``--remote`` オプションが使用できない場合のユニットテストと統合テストに推奨されます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:309 -msgid "The ``--venv`` option runs tests in a virtual environment managed by ``ansible-test``. Requirements are automatically installed before tests are run." -msgstr "``--venv`` オプションは、``ansible-test`` によって管理される仮想環境でテストを実行します。テストが実行される前に、要件が自動的にインストールされます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:313 -msgid "Composite environment arguments" -msgstr "複合環境引数" - -#: ../../rst/dev_guide/testing_running_locally.rst:315 -msgid "The environment arguments covered in this document are sufficient for most use cases. However, some scenarios may require the additional flexibility offered by composite environment arguments." -msgstr "このドキュメントで説明されている環境引数は、ほとんどのユースケースで十分です。ただし、一部のシナリオでは、複合環境引数によって提供される追加の柔軟性が必要になる場合があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:318 -msgid "The ``--controller`` and ``--target`` options are alternatives to the ``--docker``, ``--remote`` and ``--venv`` options." -msgstr "``--controller`` および ``--target`` オプションは、``--docker``、``--remote``、``--venv`` オプションの代わりです。" - -#: ../../rst/dev_guide/testing_running_locally.rst:322 -msgid "When using the ``shell`` command, the ``--target`` option is replaced by three platform specific options." -msgstr "``shell`` コマンドを使用する場合、``--target`` オプションは、3 つのプラットフォーム固有オプションに置き換えられます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:324 -msgid "Add the ``--help`` option to your ``ansible-test`` command to learn more about the composite environment arguments." -msgstr "使用している ``ansible-test`` コマンドに ``--help`` オプションを追加すると、複合環境引数の詳細を確認できます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:327 -msgid "Additional Requirements" -msgstr "追加要件" - -#: ../../rst/dev_guide/testing_running_locally.rst:329 -msgid "Some ``ansible-test`` commands have additional requirements. You can use the ``--requirements`` option to automatically install them." -msgstr "いくつかの ``ansible-test`` コマンドには、追加の要件があります。``--requirements`` オプションを使用して、それらの追加要件を自動的にインストールできます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:334 -msgid "When using a test environment managed by ``ansible-test`` the ``--requirements`` option is usually unnecessary." -msgstr "``ansible-test`` が管理するテスト環境を利用する場合、通常は ``--requirements`` オプションは必要ありません。" - -#: ../../rst/dev_guide/testing_running_locally.rst:337 -msgid "Environment variables" -msgstr "環境変数" - -#: ../../rst/dev_guide/testing_running_locally.rst:339 -msgid "When using environment variables to manipulate tests there some limitations to keep in mind. Environment variables are:" -msgstr "環境変数を使用してテストを操作する際には、以下の制限事項に留意してください。環境変数は以下のようになります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:341 -msgid "Not propagated from the host to the test environment when using the ``--docker`` or ``--remote`` options." -msgstr "``--docker`` オプションまたは ``--remote`` オプションを使用する場合は、ホストからテスト環境に伝播されません。" - -#: ../../rst/dev_guide/testing_running_locally.rst:342 -msgid "Not exposed to the test environment unless enabled in ``test/lib/ansible_test/_internal/util.py`` in the ``common_environment`` function." -msgstr "``common_environment`` 関数の ``test/lib/ansible_test/_internal/util.py`` で有効にされていない限り、テスト環境には公開されません。" - -#: ../../rst/dev_guide/testing_running_locally.rst:344 -msgid "Example: ``ANSIBLE_KEEP_REMOTE_FILES=1`` can be set when running ``ansible-test integration --venv``. However, using the ``--docker`` option would require running ``ansible-test shell`` to gain access to the Docker environment. Once at the shell prompt, the environment variable could be set and the tests executed. This is useful for debugging tests inside a container by following the :ref:`debugging_modules` instructions." -msgstr "例: ``ansible-test integration --venv`` の実行時に ``ANSIBLE_KEEP_REMOTE_FILES=1`` を設定できますが、``--docker`` オプションを使用すると、``ansible-test shell`` を実行し、Docker 環境へのアクセスが必要になります。シェルプロンプトでは、環境変数を設定してテストを行う可能性があります。これは、:ref:`debugging_modules` の指示に従って、コンテナー内でテストをデバッグする上で役立ちます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:350 -msgid "Interactive shell" -msgstr "インタラクティブシェル" - -#: ../../rst/dev_guide/testing_running_locally.rst:352 -msgid "Use the ``ansible-test shell`` command to get an interactive shell in the same environment used to run tests. Examples:" -msgstr "``ansible-test shell`` コマンドを使用して、テストを実行するのに使用する同じ環境でインタラクティブシェルを取得します。以下は例になります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:354 -msgid "``ansible-test shell --docker`` - Open a shell in the default docker container." -msgstr "``ansible-test shell --docker`` - デフォルトの docker コンテナーでシェルを開きます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:355 -msgid "``ansible-test shell --venv --python 3.10`` - Open a shell in a Python 3.10 virtual environment." -msgstr "``ansible-test shell --venv --python 3.10`` - Python 3.10 仮想環境でシェルを開きます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:358 -msgid "Code coverage" -msgstr "コードの対象範囲" - -#: ../../rst/dev_guide/testing_running_locally.rst:360 -msgid "Code coverage reports make it easy to identify untested code for which more tests should be written. Online reports are available but only cover the ``devel`` branch (see :ref:`developing_testing`). For new code local reports are needed." -msgstr "コードの対象範囲レポートは、より多くのテストが記述されるべき未テストのコードを簡単に識別することができます。オンラインレポートが利用できますが、``devel`` ブランチのみを扱います (:ref:`developing_testing` を参照)。新規コードのローカルレポートが必要な場合は、以下を行います。" - -#: ../../rst/dev_guide/testing_running_locally.rst:364 -msgid "Add the ``--coverage`` option to any test command to collect code coverage data. If you aren't using the ``--venv`` or ``--docker`` options which create an isolated python environment then you may have to use the ``--requirements`` option to ensure that the correct version of the coverage module is installed:" -msgstr "コードカバレッジデータを収集するテストコマンドに ``--coverage`` オプションを追加します。分離した python 環境を作成する ``--venv`` オプションまたは ``--docker`` オプションを使用していない場合は、``--requirements`` オプションを使用してカバレッジモジュールの正しいバージョンがインストールされていることを確認する必要があります。" - -#: ../../rst/dev_guide/testing_running_locally.rst:376 -#: ../../rst/dev_guide/testing_units.rst:197 -msgid "Reports can be generated in several different formats:" -msgstr "Report は、複数の形式で生成できます。" - -#: ../../rst/dev_guide/testing_running_locally.rst:378 -#: ../../rst/dev_guide/testing_units.rst:199 -msgid "``ansible-test coverage report`` - Console report." -msgstr "``ansible-test coverage report`` - コンソールレポート。" - -#: ../../rst/dev_guide/testing_running_locally.rst:379 -#: ../../rst/dev_guide/testing_units.rst:200 -msgid "``ansible-test coverage html`` - HTML report." -msgstr "``ansible-test coverage html`` - HTML レポート。" - -#: ../../rst/dev_guide/testing_running_locally.rst:380 -#: ../../rst/dev_guide/testing_units.rst:201 -msgid "``ansible-test coverage xml`` - XML report." -msgstr "``ansible-test coverage xml`` - XML レポート。" - -#: ../../rst/dev_guide/testing_running_locally.rst:382 -msgid "To clear data between test runs, use the ``ansible-test coverage erase`` command." -msgstr "テストの実行間でデータをクリアするには、``ansible-test coverage erase`` コマンドを使用します。" - -#: ../../rst/dev_guide/testing_sanity.rst:11 -msgid "Sanity tests are made up of scripts and tools used to perform static code analysis. The primary purpose of these tests is to enforce Ansible coding standards and requirements." -msgstr "健全性テストは、静的コード分析の実行に使用されるスクリプトおよびツールで構成されています。これらのテストの主な目的は、Ansible コーディングの仕様および要件を適用することです。" - -#: ../../rst/dev_guide/testing_sanity.rst:14 -msgid "Tests are run with ``ansible-test sanity``. All available tests are run unless the ``--test`` option is used." -msgstr "テストは、``ansible-test sanity`` で実行します。``--test`` オプションを使用しない限り、利用可能なテストはすべて実行します。" - -#: ../../rst/dev_guide/testing_sanity.rst:19 -msgid "How to run" -msgstr "実行方法" - -#: ../../rst/dev_guide/testing_sanity.rst:22 -msgid "To run sanity tests using docker, always use the default docker image by passing the ``--docker`` or ``--docker default`` argument." -msgstr "docker を使用して健常性テストを実行するには、常に ``--docker`` 引数または ``--docker default`` 引数を渡すことでデフォルトの docker イメージを常に使用します。" - -#: ../../rst/dev_guide/testing_sanity.rst:26 -msgid "When using docker and the ``--base-branch`` argument, also use the ``--keep-git`` argument to avoid git related errors." -msgstr "docker および ``--base-branch`` 引数を使用する場合は、git 関連のエラーを回避するために ``--keep-git`` 引数も使用します。" - -#: ../../rst/dev_guide/testing_sanity.rst:52 -#: ../../rst/dev_guide/testing_units.rst:17 -msgid "Available Tests" -msgstr "利用可能なテスト" - -#: ../../rst/dev_guide/testing_sanity.rst:54 -msgid "Tests can be listed with ``ansible-test sanity --list-tests``." -msgstr "テストは ``ansible-test sanity --list-tests`` で一覧表示できます。" - -#: ../../rst/dev_guide/testing_units.rst:7 -msgid "Unit Tests" -msgstr "ユニットテスト" - -#: ../../rst/dev_guide/testing_units.rst:9 -msgid "Unit tests are small isolated tests that target a specific library or module. Unit tests in Ansible are currently the only way of driving tests from python within Ansible's continuous integration process. This means that in some circumstances the tests may be a bit wider than just units." -msgstr "ユニットテストは、特定のライブラリーまたはモジュールを対象とする小規模の分離テストです。現在、Ansible のユニットテストは、Ansible の継続的統合プロセスの中で、python からテストを実行する唯一の方法です。つまり、状況によっては、テストにはユニット以外のものも含まれる場合があることを意味します。" - -#: ../../rst/dev_guide/testing_units.rst:19 -msgid "Unit tests can be found in `test/units `_. Notice that the directory structure of the tests matches that of ``lib/ansible/``." -msgstr "ユニットテストは `test/units `_ にあります。テストのディレクトリー構造が ``lib/ansible/`` と一致することに注意してください。" - -#: ../../rst/dev_guide/testing_units.rst:24 -msgid "Running Tests" -msgstr "テストの実行" - -#: ../../rst/dev_guide/testing_units.rst:27 -msgid "To run unit tests using docker, always use the default docker image by passing the ``--docker`` or ``--docker default`` argument." -msgstr "docker を使用してユニットテストを実行するには、``--docker`` 引数または ``--docker default`` 引数を渡すことで常にデフォルトの docker イメージを使用します。" - -#: ../../rst/dev_guide/testing_units.rst:30 -msgid "The Ansible unit tests can be run across the whole code base by doing:" -msgstr "Ansible のユニットテストは、以下の操作を実行してコードベース全体で実行できます。" - -#: ../../rst/dev_guide/testing_units.rst:38 -msgid "Against a single file by doing:" -msgstr "1 つのファイルに対して以下を行います。" - -#: ../../rst/dev_guide/testing_units.rst:44 -msgid "Or against a specific Python version by doing:" -msgstr "または、特定の Python バージョンに対して以下を実行します。" - -#: ../../rst/dev_guide/testing_units.rst:50 -msgid "If you are running unit tests against things other than modules, such as module utilities, specify the whole file path:" -msgstr "モジュールユーティリティーなどのモジュール以外のものに対してユニットテストを実行している場合は、ファイルパス全体を指定します。" - -#: ../../rst/dev_guide/testing_units.rst:56 -msgid "For advanced usage see the online help:" -msgstr "高度な使用方法は、オンラインヘルプを参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:62 -msgid "You can also run tests in Ansible's continuous integration system by opening a pull request. This will automatically determine which tests to run based on the changes made in your pull request." -msgstr "プル要求を開いて、Ansible の継続的統合システムでテストを実行することもできます。これにより、プル要求で実行された変更に基づいて、実行されるテストが自動的に決定されます。" - -#: ../../rst/dev_guide/testing_units.rst:68 -msgid "Installing dependencies" -msgstr "依存関係のインストール" - -#: ../../rst/dev_guide/testing_units.rst:70 -msgid "If you are running ``ansible-test`` with the ``--docker`` or ``--venv`` option you do not need to install dependencies manually." -msgstr "``--docker`` オプションまたは ``--venv`` オプションを指定して ``ansible-test`` を実行している場合は、依存関係を手動でインストールする必要はありません。" - -#: ../../rst/dev_guide/testing_units.rst:72 -msgid "Otherwise you can install dependencies using the ``--requirements`` option, which will install all the required dependencies needed for unit tests. For example:" -msgstr "それ以外の場合は、``--requirements`` オプションを使用して依存関係をインストールし、ユニットテストに必要な依存関係をすべてインストールします。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units.rst:80 -msgid "The list of unit test requirements can be found at `test/units/requirements.txt `_." -msgstr "ユニットテストの要件一覧は、`test/units/requirements.txt `_ を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:83 -msgid "This does not include the list of unit test requirements for ``ansible-test`` itself, which can be found at `test/lib/ansible_test/_data/requirements/units.txt `_." -msgstr "これには、``ansible-test`` のユニットテスト要件のリストは含まれていません。それは、`test/lib/ansible_test/_data/requirements/units.txt `_ で見つけることができます。" - -#: ../../rst/dev_guide/testing_units.rst:87 -msgid "See also the `constraints `_ applicable to all test commands." -msgstr "すべてのコマンドに適用可能な「`制約 `_」も参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:93 -msgid "Extending unit tests" -msgstr "ユニットテストの拡張" - -#: ../../rst/dev_guide/testing_units.rst:96 -msgid "What a unit test isn't" -msgstr "ユニットテスト以外のもの" - -#: ../../rst/dev_guide/testing_units.rst:98 -msgid "If you start writing a test that requires external services then you may be writing an integration test, rather than a unit test." -msgstr "外部サービスを必要とするテストを書き始めると、ユニットテストではなく統合テストを書くことができます。" - -#: ../../rst/dev_guide/testing_units.rst:103 -msgid "Structuring Unit Tests" -msgstr "ユニットテストの構造" - -#: ../../rst/dev_guide/testing_units.rst:105 -msgid "Ansible drives unit tests through `pytest `_. This means that tests can either be written a simple functions which are included in any file name like ``test_.py`` or as classes." -msgstr "Ansible は、`pytest `_ でユニットテストを行います。これは、テストは、``test_.py`` のファイル名またはクラスとして含まれる単純な関数を記述できることを意味します。" - -#: ../../rst/dev_guide/testing_units.rst:109 -msgid "Here is an example of a function:" -msgstr "以下は、関数の例です。" - -#: ../../rst/dev_guide/testing_units.rst:121 -msgid "Here is an example of a class:" -msgstr "以下はクラスの例です。" - -#: ../../rst/dev_guide/testing_units.rst:143 -msgid "Both methods work fine in most circumstances; the function-based interface is simpler and quicker and so that's probably where you should start when you are just trying to add a few basic tests for a module. The class-based test allows more tidy set up and tear down of pre-requisites, so if you have many test cases for your module you may want to refactor to use that." -msgstr "どちらの方法も、ほとんどの状況で正常に機能します。関数ベースのインターフェースの方がシンプルで速いため、モジュールにいくつかの基本的なテストを追加しようとしている場合は、ここから始めることが推奨されます。クラスベースのテストでは、前提条件の設定や分解をより整然と行うことができるため、モジュールに多くのテストケースがある場合は、それを使用するようにリファクタリングすることが推奨されます。" - -#: ../../rst/dev_guide/testing_units.rst:149 -msgid "Assertions using the simple ``assert`` function inside the tests will give full information on the cause of the failure with a trace-back of functions called during the assertion. This means that plain asserts are recommended over other external assertion libraries." -msgstr "テスト内の簡単な ``assert`` 関数を使用するアサーションにより、アサーション中に呼び出される関数のトレースバックで障害に関する完全な情報が表示されます。これは、他の外部アサーションライブラリーよりも、プレーンアサートが推奨されることを意味します。" - -#: ../../rst/dev_guide/testing_units.rst:154 -msgid "A number of the unit test suites include functions that are shared between several modules, especially in the networking arena. In these cases a file is created in the same directory, which is then included directly." -msgstr "多くのユニットテストスイートには、特にネットワークの分野では、複数のモジュールで共有される関数が含まれています。この場合は、同じディレクトリーにファイルが作成されます。このファイルは、直接含まれます。" - -#: ../../rst/dev_guide/testing_units.rst:160 -msgid "Module test case common code" -msgstr "モジュールテストケースの共通コード" - -#: ../../rst/dev_guide/testing_units.rst:162 -msgid "Keep common code as specific as possible within the `test/units/` directory structure. Don't import common unit test code from directories outside the current or parent directories." -msgstr "`test/units/` ディレクトリー構造内で可能な限り具体的に共通コードを維持します。現在のディレクトリーまたは親ディレクトリー以外のディレクトリーから共通のユニットテストコードをインポートしないでください。" - -#: ../../rst/dev_guide/testing_units.rst:165 -msgid "Don't import other unit tests from a unit test. Any common code should be in dedicated files that aren't themselves tests." -msgstr "ユニットテストから他のユニットテストをインポートしないでください。共通のコードは、テスト自体ではない専用のファイルに含める必要があります。" - -#: ../../rst/dev_guide/testing_units.rst:170 -msgid "Fixtures files" -msgstr "Fixtures ファイル" - -#: ../../rst/dev_guide/testing_units.rst:172 -msgid "To mock out fetching results from devices, or provide other complex data structures that come from external libraries, you can use ``fixtures`` to read in pre-generated data." -msgstr "デバイスからの結果の取得を模倣したり、外部ライブラリーから取得した他の複雑なデータ構造を提供するために、``fixtures`` を使用して事前に生成されたデータを読み込むことができます。" - -#: ../../rst/dev_guide/testing_units.rst:175 -msgid "You can check how `fixtures `_ are used in `cpuinfo fact tests `_" -msgstr "`cpuinfo ファクトテスト `_ で、`fixtures `_ が使用される方法を確認することができます。" - -#: ../../rst/dev_guide/testing_units.rst:178 -msgid "If you are simulating APIs you may find that Python placebo is useful. See :ref:`testing_units_modules` for more information." -msgstr "API のシミュレーションをしているのであれば、Python のプラシーボが役に立つかもしれません。詳細は、「:ref:`testing_units_modules`」を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:183 -msgid "Code Coverage For New or Updated Unit Tests" -msgstr "新規ユニットテストまたは更新されたユニットテスト用のコード対応" - -#: ../../rst/dev_guide/testing_units.rst:184 -msgid "New code will be missing from the codecov.io coverage reports (see :ref:`developing_testing`), so local reporting is needed. Most ``ansible-test`` commands allow you to collect code coverage; this is particularly useful when to indicate where to extend testing." -msgstr "codecov.io カバレッジレポートから新しいコードが欠落し (:ref:`developing_testing`を参照)、ローカルレポートが必要です。ほとんどの ``ansible-test`` コマンドを使用すると、コードカバレッジを収集できます。これは、テストを拡張する場所を示すときに特に役立ちます。" - -#: ../../rst/dev_guide/testing_units.rst:188 -msgid "To collect coverage data add the ``--coverage`` argument to your ``ansible-test`` command line:" -msgstr "カバレージデータを収集するには、``--coverage`` 引数を ``ansible-test`` コマンドラインに追加します。" - -#: ../../rst/dev_guide/testing_units.rst:195 -msgid "Results will be written to ``test/results/reports/coverage/index.html``" -msgstr "結果は ``test/results/reports/coverage/index.html`` に書き込まれます。" - -#: ../../rst/dev_guide/testing_units.rst:203 -msgid "To clear data between test runs, use the ``ansible-test coverage erase`` command. See :ref:`testing_running_locally` for more information about generating coverage reports." -msgstr "テスト実行間のデータを消去するには、``ansible-test coverage erase`` コマンドを使用します。カバレッジレポートの生成の詳細は、「:ref:`testing_running_locally`」を参照してください。" - -#: ../../rst/dev_guide/testing_units.rst:210 -msgid ":ref:`testing_units_modules`" -msgstr ":ref:`testing_units_modules`" - -#: ../../rst/dev_guide/testing_units.rst:211 -msgid "Special considerations for unit testing modules" -msgstr "ユニットテストモジュールに関する特別な考慮事項" - -#: ../../rst/dev_guide/testing_units.rst:212 -#: ../../rst/dev_guide/testing_units_modules.rst:569 -msgid ":ref:`testing_running_locally`" -msgstr ":ref:`testing_running_locally`" - -#: ../../rst/dev_guide/testing_units.rst:213 -#: ../../rst/dev_guide/testing_units_modules.rst:570 -msgid "Running tests locally including gathering and reporting coverage data" -msgstr "カバレージデータの収集とレポートを含む、ローカルでのテストの実行" - -#: ../../rst/dev_guide/testing_units.rst:214 -#: ../../rst/dev_guide/testing_units_modules.rst:573 -msgid "`Python 3 documentation - 26.4. unittest — Unit testing framework `_" -msgstr "`Python 3 documentation - 26.4. unittest — Unit testing framework `_" - -#: ../../rst/dev_guide/testing_units.rst:215 -#: ../../rst/dev_guide/testing_units_modules.rst:574 -msgid "The documentation of the unittest framework in python 3" -msgstr "Python 3 におけるユニットテストフレームワークのドキュメント" - -#: ../../rst/dev_guide/testing_units.rst:216 -#: ../../rst/dev_guide/testing_units_modules.rst:575 -msgid "`Python 2 documentation - 25.3. unittest — Unit testing framework `_" -msgstr "`Python 2 documentation - 25.3. unittest — Unit testing framework `_" - -#: ../../rst/dev_guide/testing_units.rst:217 -#: ../../rst/dev_guide/testing_units_modules.rst:576 -msgid "The documentation of the earliest supported unittest framework - from Python 2.6" -msgstr "サポートされている初期のユニットテストフレームワークのドキュメント (Python 2.6)" - -#: ../../rst/dev_guide/testing_units.rst:218 -#: ../../rst/dev_guide/testing_units_modules.rst:577 -msgid "`pytest: helps you write better programs `_" -msgstr "`pytest: helps you write better programs `_" - -#: ../../rst/dev_guide/testing_units.rst:219 -#: ../../rst/dev_guide/testing_units_modules.rst:578 -msgid "The documentation of pytest - the framework actually used to run Ansible unit tests" -msgstr "pytest のドキュメント - Ansible ユニットテストの実行に実際に使用されているフレームワーク" - -#: ../../rst/dev_guide/testing_units_modules.rst:7 -msgid "Unit Testing Ansible Modules" -msgstr "Ansible モジュールのユニットテスト" - -#: ../../rst/dev_guide/testing_units_modules.rst:14 -msgid "Introduction" -msgstr "はじめに" - -#: ../../rst/dev_guide/testing_units_modules.rst:16 -msgid "This document explains why, how and when you should use unit tests for Ansible modules. The document doesn't apply to other parts of Ansible for which the recommendations are normally closer to the Python standard. There is basic documentation for Ansible unit tests in the developer guide :ref:`testing_units`. This document should be readable for a new Ansible module author. If you find it incomplete or confusing, please open a bug or ask for help on the #ansible-devel chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)." -msgstr "このドキュメントでは、Ansible モジュールにユニットテストを使用する理由、方法、タイミングを説明します。このドキュメントは、通常 Python の標準に近い推奨事項を持つ Ansible の他の部分には適用されません。Ansible のユニットテストに関する基本的なドキュメントは、開発者ガイドの「:ref:`testing_units`」にあります。このドキュメントは、新しい Ansible モジュールの作成者にとって読みやすいものでなければなりません。不完全だったり、分かりにくかったりした場合は、バグを報告したり、#ansible-develチャットチャンネル で助けを求めたりしてください（ansible.imでMatrixを使用、または`irc.libera.chat `_でIRCを使用）。" - -#: ../../rst/dev_guide/testing_units_modules.rst:24 -msgid "What Are Unit Tests?" -msgstr "ユニットテストとは" - -#: ../../rst/dev_guide/testing_units_modules.rst:26 -msgid "Ansible includes a set of unit tests in the :file:`test/units` directory. These tests primarily cover the internals but can also cover Ansible modules. The structure of the unit tests matches the structure of the code base, so the tests that reside in the :file:`test/units/modules/` directory are organized by module groups." -msgstr "Ansible には、:file:`test/units` ディレクトリーにユニットテストのセットが含まれています。これらのテストは、主に内部に対応していますが、Ansible モジュールにも対応します。ユニットテストの構造はコードベースのベースの構造に一致し、:file:`test/units/modules/` ディレクトリーに含まれるテストはモジュールグループごとに編成されます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:31 -msgid "Integration tests can be used for most modules, but there are situations where cases cannot be verified using integration tests. This means that Ansible unit test cases may extend beyond testing only minimal units and in some cases will include some level of functional testing." -msgstr "統合テストはほとんどのモジュールで使用できますが、統合テストではケースを検証できない場合もあります。つまり、Ansible ユニットテストケースは、最小限のユニットのみのテストにとどまらず、場合によっては、ある程度の機能テストが含まれることもあります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:38 -msgid "Why Use Unit Tests?" -msgstr "ユニットテストを使用する理由" - -#: ../../rst/dev_guide/testing_units_modules.rst:40 -msgid "Ansible unit tests have advantages and disadvantages. It is important to understand these. Advantages include:" -msgstr "Ansible ユニットテストには長所と短所があり、その点を理解することは重要です。以下が挙げられます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:43 -msgid "Most unit tests are much faster than most Ansible integration tests. The complete suite of unit tests can be run regularly by a developer on their local system." -msgstr "ほとんどのユニットテストは、ほとんどの Ansible 統合テストよりもはるかに高速です。ユニットテストの完全なスイートは、ローカルシステムで開発者が定期的に実行できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:45 -msgid "Unit tests can be run by developers who don't have access to the system which the module is designed to work on, allowing a level of verification that changes to core functions haven't broken module expectations." -msgstr "ユニットテストは、モジュールが動作するように設計されているシステムにアクセスできない開発者が実行することができ、コア機能への変更がモジュールの期待どおりであることをある程度検証できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:48 -msgid "Unit tests can easily substitute system functions allowing testing of software that would be impractical. For example, the ``sleep()`` function can be replaced and we check that a ten minute sleep was called without actually waiting ten minutes." -msgstr "ユニットテストは、システム関数を簡単に置換でき、実現するソフトウェアのテストを簡単に指定することができます。たとえば、``sleep()`` 関数を置き換えることができ、実際に 10 分待たずに 10 分のスリープが呼び出されたことを確認します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:51 -msgid "Unit tests are run on different Python versions. This allows us to ensure that the code behaves in the same way on different Python versions." -msgstr "ユニットテストは、Python の各バージョンで実行されます。これにより、コードが異なる Python のバージョンでも同じように動作することを確認できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:54 -msgid "There are also some potential disadvantages of unit tests. Unit tests don't normally directly test actual useful valuable features of software, instead just internal implementation" -msgstr "ユニットテストには、いくつかの潜在的な欠点もあります。通常、実際に便利で価値のある機能を直接テストせず、代わりに内部実装をテストします。" - -#: ../../rst/dev_guide/testing_units_modules.rst:58 -msgid "Unit tests that test the internal, non-visible features of software may make refactoring difficult if those internal features have to change (see also naming in How below)" -msgstr "ソフトウェア内部にある、目に見えない機能をテストするユニットテストは、それらの内部機能を変更する必要がある場合、リファクタリングを困難にする可能性があります (以下の「方法」の命名も参照)。" - -#: ../../rst/dev_guide/testing_units_modules.rst:61 -msgid "Even if the internal feature is working correctly it is possible that there will be a problem between the internal code tested and the actual result delivered to the user" -msgstr "内部機能が正しく機能している場合でも、テストされた内部コードとユーザーに配信される実際の結果との間に問題が発生する可能性があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:64 -msgid "Normally the Ansible integration tests (which are written in Ansible YAML) provide better testing for most module functionality. If those tests already test a feature and perform well there may be little point in providing a unit test covering the same area as well." -msgstr "通常、(Ansible YAML で記述される) Ansible 統合テストは、ほとんどのモジュール機能に対してより良いテストを提供します。これらのテストがすでに機能をテストしていて、うまく機能している場合は、同じ領域をカバーするユニットテストを提供する意味はほとんどないかもしれません。" - -#: ../../rst/dev_guide/testing_units_modules.rst:69 -msgid "When To Use Unit Tests" -msgstr "ユニットテストを使用するタイミング" - -#: ../../rst/dev_guide/testing_units_modules.rst:71 -msgid "There are a number of situations where unit tests are a better choice than integration tests. For example, testing things which are impossible, slow or very difficult to test with integration tests, such as:" -msgstr "統合テストよりもユニットテストの方が適している状況は数多くあります。たとえば、次のような統合テストでテストすることが不可能で、遅い、または非常に難しいものをテストします。" - -#: ../../rst/dev_guide/testing_units_modules.rst:75 -msgid "Forcing rare / strange / random situations that can't be forced, such as specific network failures and exceptions" -msgstr "特定のネットワーク障害や例外のような、強制することができない稀な、奇妙な、およびランダムな状況を強制。" - -#: ../../rst/dev_guide/testing_units_modules.rst:77 -msgid "Extensive testing of slow configuration APIs" -msgstr "遅い設定 API の広範なテスト" - -#: ../../rst/dev_guide/testing_units_modules.rst:78 -msgid "Situations where the integration tests cannot be run as part of the main Ansible continuous integration running in Azure Pipelines." -msgstr "Azure Pipeline で実行されているメインの Ansible 継続的統合の一部として、統合テストを実行できない状況。" - -#: ../../rst/dev_guide/testing_units_modules.rst:84 -msgid "Providing quick feedback" -msgstr "迅速なフィードバックの提供" - -#: ../../rst/dev_guide/testing_units_modules.rst:87 -msgid "A single step of the rds_instance test cases can take up to 20 minutes (the time to create an RDS instance in Amazon). The entire test run can last for well over an hour. All 16 of the unit tests complete execution in less than 2 seconds." -msgstr "rds_instance のテストケースの 1 つのステップには、最大 20 分 (Amazonで RDS インスタンスを作成する時間) かかる場合があります。テストの実行は、全体で 1 時間以上かかることもあります。16 個のユニットテストは、すべて 2 秒以内に実行を完了します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:92 -msgid "The time saving provided by being able to run the code in a unit test makes it worth creating a unit test when bug fixing a module, even if those tests do not often identify problems later. As a basic goal, every module should have at least one unit test which will give quick feedback in easy cases without having to wait for the integration tests to complete." -msgstr "ユニットテストでコードを実行できることによって提供される時間の節約により、モジュールのバグ修正時にユニットテストを作成する価値があります。これらのテストで後で問題が特定されることはあまりありません。基本的な目標として、すべてのモジュールには少なくとも 1 つのユニットテストが必要です。これにより、統合テストが完了するのを待たずに、簡単なケースで迅速なフィードバックが得られます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:99 -msgid "Ensuring correct use of external interfaces" -msgstr "外部インターフェースを正しく使用すること" - -#: ../../rst/dev_guide/testing_units_modules.rst:101 -msgid "Unit tests can check the way in which external services are run to ensure that they match specifications or are as efficient as possible *even when the final output will not be changed*." -msgstr "ユニットテストは、*最終的な出力が変更されない場合でも*、外部サービスの実行方法が仕様に合致しているか、あるいは可能な限り効率的であるかを確認できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:105 -msgid "Package managers are often far more efficient when installing multiple packages at once rather than each package separately. The final result is the same: the packages are all installed, so the efficiency is difficult to verify through integration tests. By providing a mock package manager and verifying that it is called once, we can build a valuable test for module efficiency." -msgstr "パッケージマネージャーは、各パッケージを個別にインストールするよりも、複数のパッケージを一度にインストールする方がはるかに効率的であることがよくあります。最終結果は同じです。すべてのパッケージがインストールされるため、統合テストで効率を検証することは困難です。模擬パッケージマネージャを提供し、それが一度に呼ばれることを検証するため、モジュール効率について貴重なテストを構築できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:111 -msgid "Another related use is in the situation where an API has versions which behave differently. A programmer working on a new version may change the module to work with the new API version and unintentionally break the old version. A test case which checks that the call happens properly for the old version can help avoid the problem. In this situation it is very important to include version numbering in the test case name (see `Naming unit tests`_ below)." -msgstr "別の関連する使用法は、API の動作が異なるバージョンがある状況です。新しいバージョンで作業しているプログラマーは、新しい API バージョンで動作するようにモジュールを変更し、意図せずに古いバージョンを壊してしまう可能性があります。古いバージョンで呼び出しが適切に行われることを確認するテストケースは、問題を回避するのに役立ちます。この状況では、テストケース名にバージョン番号を含めることが非常に重要です (以下 `Naming unit tests`_ を参照)。" - -#: ../../rst/dev_guide/testing_units_modules.rst:119 -msgid "Providing specific design tests" -msgstr "特定の設計テストの提供" - -#: ../../rst/dev_guide/testing_units_modules.rst:121 -msgid "By building a requirement for a particular part of the code and then coding to that requirement, unit tests _can_ sometimes improve the code and help future developers understand that code." -msgstr "コードの特定の部分に対する要件を構築し、その要件に合わせてコーディングすることで、ユニットテストは、時にはコードを改善し、将来の開発者がそのコードを理解する助けとなります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:125 -msgid "Unit tests that test internal implementation details of code, on the other hand, almost always do more harm than good. Testing that your packages to install are stored in a list would slow down and confuse a future developer who might need to change that list into a dictionary for efficiency. This problem can be reduced somewhat with clear test naming so that the future developer immediately knows to delete the test case, but it is often better to simply leave out the test case altogether and test for a real valuable feature of the code, such as installing all of the packages supplied as arguments to the module." -msgstr "一方、コードの内部実装の詳細をテストするユニットテストは、ほとんどの場合、益よりも害をもたらします。インストールするパッケージがリストに格納されているかどうかをテストすると、遅くなり、効率化のためにリストをディクショナリーに変更しないといけない将来の開発者を混乱させます。この問題は、将来の開発者がすぐにテストケースを削除することがわかるように、明確なテスト名をつけることで多少軽減できますが、単にテストケースを完全に除外して、モジュールの引数として与えられたすべてのパッケージをインストールするなど、コードの本当の価値ある機能をテストする方が良い場合が多いです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:135 -msgid "How to unit test Ansible modules" -msgstr "Ansible モジュールをユニットテストする方法" - -#: ../../rst/dev_guide/testing_units_modules.rst:137 -msgid "There are a number of techniques for unit testing modules. Beware that most modules without unit tests are structured in a way that makes testing quite difficult and can lead to very complicated tests which need more work than the code. Effectively using unit tests may lead you to restructure your code. This is often a good thing and leads to better code overall. Good restructuring can make your code clearer and easier to understand." -msgstr "ユニットテストモジュールにはいくつかの手法があります。ユニットテストのないほとんどのモジュールでは、テストが非常に困難になり、コードよりも多くの作業が必要な、非常に複雑なテストにつながる可能性があることに注意してください。ユニットテストを効果的に使用するには、コードを再構築する可能性があります。これは多くの場合良いことであり、全体的に優れたコードにつながります。適切な再構築により、コードがより明確になり、理解しやすくなります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:145 -msgid "Naming unit tests" -msgstr "ユニットテストの命名" - -#: ../../rst/dev_guide/testing_units_modules.rst:147 -msgid "Unit tests should have logical names. If a developer working on the module being tested breaks the test case, it should be easy to figure what the unit test covers from the name. If a unit test is designed to verify compatibility with a specific software or API version then include the version in the name of the unit test." -msgstr "ユニットテストは論理名を付ける必要があります。テスト対象のモジュールで作業している開発者がテストケースを壊してしまった場合に、ユニットテストが何を対象としているのかが名前から簡単に分かるようにする必要があります。ユニットテストが特定のソフトウェアや API のバージョンとの互換性を検証するように設計されている場合は、ユニットテストの名前にそのバージョンを追加してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:152 -msgid "As an example, ``test_v2_state_present_should_call_create_server_with_name()`` would be a good name, ``test_create_server()`` would not be." -msgstr "たとえば、``test_v2_state_present_should_call_create_server_with_name()`` が適切な名前で、``test_create_server()`` は適切ではありません。" - -#: ../../rst/dev_guide/testing_units_modules.rst:157 -msgid "Use of Mocks" -msgstr "モックの使用" - -#: ../../rst/dev_guide/testing_units_modules.rst:159 -msgid "Mock objects (from https://docs.python.org/3/library/unittest.mock.html) can be very useful in building unit tests for special / difficult cases, but they can also lead to complex and confusing coding situations. One good use for mocks would be in simulating an API. As for 'six', the 'mock' python package is bundled with Ansible (use ``import units.compat.mock``)." -msgstr "(https://docs.python.org/3/library/unittest.mock.html_ からの) モックオブジェクトは、特殊なケースや困難なケースのユニットテストを構築するのに非常に便利ですが、複雑で理解しづらいコーディングになってしまうこともあります。モックの使用方法として適切なものの 1 つに、API のシミュレートがあります。Python パッケージの「six」、「mock」は、Ansible にバンドルされています (``import units.compat.mock`` を使用)。" - -#: ../../rst/dev_guide/testing_units_modules.rst:166 -msgid "Ensuring failure cases are visible with mock objects" -msgstr "モックオブジェクトで障害ケースを確実に可視化" - -#: ../../rst/dev_guide/testing_units_modules.rst:168 -msgid "Functions like :meth:`module.fail_json` are normally expected to terminate execution. When you run with a mock module object this doesn't happen since the mock always returns another mock from a function call. You can set up the mock to raise an exception as shown above, or you can assert that these functions have not been called in each test. For example:" -msgstr ":meth:`module.fail_json` などの関数は、通常、実行を終了することが期待されます。モックモジュールオブジェクトを使用して実行すると、モックは常に関数呼び出しから別のモックを返すため、このようなことは起こりません。上記のように例外を発生させるようにモックを設定することもできますし、各テストでこれらの関数が呼び出されていないことをアサートすることもできます。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:179 -msgid "This applies not only to calling the main module but almost any other function in a module which gets the module object." -msgstr "これは、メインモジュールを呼び出す場合だけでなく、モジュールオブジェクトを取得するモジュール内の他のほとんどの関数を呼び出す場合にも適用されます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:184 -msgid "Mocking of the actual module" -msgstr "実際のモジュールのモック化" - -#: ../../rst/dev_guide/testing_units_modules.rst:186 -msgid "The setup of an actual module is quite complex (see `Passing Arguments`_ below) and often isn't needed for most functions which use a module. Instead you can use a mock object as the module and create any module attributes needed by the function you are testing. If you do this, beware that the module exit functions need special handling as mentioned above, either by throwing an exception or ensuring that they haven't been called. For example:" -msgstr "実際のモジュールの設定は非常に複雑で (以下の `引数の渡し方`_ を参照)、モジュールを使用するほとんどの機能には必要ありません。モックオブジェクトをモジュールとして使用する代わりに、テストする関数で必要なモジュール属性を作成できます。この場合、モジュールの終了関数は、上述のように、例外を発生させるか、呼び出されていないことを確認するなど、特別な処理が必要になることに注意してください。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:207 -msgid "API definition with unit test cases" -msgstr "ユニットテストケースでの API 定義" - -#: ../../rst/dev_guide/testing_units_modules.rst:209 -msgid "API interaction is usually best tested with the function tests defined in Ansible's integration testing section, which run against the actual API. There are several cases where the unit tests are likely to work better." -msgstr "API の対話は通常、実際の API に対して実行する Ansible の統合テストセクションで定義された関数テストでテストを行うのが最適です。ユニットテストが適切に機能する可能性があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:214 -msgid "Defining a module against an API specification" -msgstr "API の仕様に対してモジュールを定義" - -#: ../../rst/dev_guide/testing_units_modules.rst:216 -msgid "This case is especially important for modules interacting with web services, which provide an API that Ansible uses but which are beyond the control of the user." -msgstr "このケースは、Ansible が使用する API を提供しているが、ユーザーの制御が及ばない Web サービスと対話するモジュールにとって特に重要になります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:219 -msgid "By writing a custom emulation of the calls that return data from the API, we can ensure that only the features which are clearly defined in the specification of the API are present in the message. This means that we can check that we use the correct parameters and nothing else." -msgstr "API からデータを返す呼び出しのカスタムエミュレーションを書くことで、API の仕様で明確に定義されている機能のみがメッセージに含まれていることを確認できます。つまり、正しいパラメーターを使用しているかどうかを確認し、それ以外は何も使用していないことを確認することができます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:225 -msgid "*Example: in rds_instance unit tests a simple instance state is defined*:" -msgstr "*例: rds_instance ユニットテストでは、単純なインスタンスの状態が定義されています*。" - -#: ../../rst/dev_guide/testing_units_modules.rst:235 -msgid "This is then used to create a list of states:" -msgstr "次に、これを使用して状態のリストを作成します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:252 -msgid "These states are then used as returns from a mock object to ensure that the ``await`` function waits through all of the states that would mean the RDS instance has not yet completed configuration:" -msgstr "これらの状態は、モックオブジェクトからの戻り値として使用され、``await`` 関数は、RDS インスタンスがまだ設定を完了しないことを意味するすべての状態を待機します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:262 -msgid "By doing this we check that the ``await`` function will keep waiting through potentially unusual that it would be impossible to reliably trigger through the integration tests but which happen unpredictably in reality." -msgstr "これを実行することで、統合テストでは確実に誘発させることができないにもかかわらず、現実には予測できないような、潜在的に異常なことが起こる可能性がある場合に ``await`` 関数が待機し続けるかどうかを確認します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:267 -msgid "Defining a module to work against multiple API versions" -msgstr "複数の API バージョンに対して動作するモジュールの定義" - -#: ../../rst/dev_guide/testing_units_modules.rst:269 -msgid "This case is especially important for modules interacting with many different versions of software; for example, package installation modules that might be expected to work with many different operating system versions." -msgstr "このケースは、多くの異なるバージョンのソフトウェアと対話するモジュールにとって特に重要です。たとえば、さまざまなオペレーティングシステムのバージョンと動作することが想定されるパッケージインストールモジュールなどです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:273 -msgid "By using previously stored data from various versions of an API we can ensure that the code is tested against the actual data which will be sent from that version of the system even when the version is very obscure and unlikely to be available during testing." -msgstr "さまざまなバージョンの API から、以前に保存されたデータを使用することで、バージョンが非常に曖昧でテスト中に利用できそうにない場合でも、そのバージョンのシステムから送信される実際のデータに対してコードがテストできるようになります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:278 -msgid "Ansible special cases for unit testing" -msgstr "Ansible ユニットテストの特殊なケース" - -#: ../../rst/dev_guide/testing_units_modules.rst:280 -msgid "There are a number of special cases for unit testing the environment of an Ansible module. The most common are documented below, and suggestions for others can be found by looking at the source code of the existing unit tests or asking on the Ansible chat channel or mailing lists. For more information on joining chat channels and subscribing to mailing lists, see :ref:`communication`." -msgstr "Ansible モジュールの環境に対してユニットテストを行うための特別なケースがいくつかあります。最も一般的なものを以下に示します。他の人への提案は、既存のユニットテストのソースコードを確認するか、Ansible チャットチャンネルまたはメーリングリストで質問することで見つけることができます。チャットチャンネルへの参加およびメーリングリストのサブスクライブの詳細については、:ref:`communication`を参照してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:286 -msgid "Module argument processing" -msgstr "モジュール引数処理" - -#: ../../rst/dev_guide/testing_units_modules.rst:288 -msgid "There are two problems with running the main function of a module:" -msgstr "モジュールの主な関数の実行には、以下の 2 つの問題があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:290 -msgid "Since the module is supposed to accept arguments on ``STDIN`` it is a bit difficult to set up the arguments correctly so that the module will get them as parameters." -msgstr "モジュールは ``STDIN`` で引数を受け入れる必要があるため、引数を正しく設定してモジュールがパラメーターとして受け取るようにするのは少し難しくなります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:292 -msgid "All modules should finish by calling either the :meth:`module.fail_json` or :meth:`module.exit_json`, but these won't work correctly in a testing environment." -msgstr "すべてのモジュールは、:meth:`module.fail_json` または :meth:`module.exit_json` を呼び出して終了する必要がありますが、テスト環境では正常に動作しません。" - -#: ../../rst/dev_guide/testing_units_modules.rst:296 -msgid "Passing Arguments" -msgstr "引数の渡し方" - -#: ../../rst/dev_guide/testing_units_modules.rst:301 -msgid "To pass arguments to a module correctly, use the ``set_module_args`` method which accepts a dictionary as its parameter. Module creation and argument processing is handled through the :class:`AnsibleModule` object in the basic section of the utilities. Normally this accepts input on ``STDIN``, which is not convenient for unit testing. When the special variable is set it will be treated as if the input came on ``STDIN`` to the module. Simply call that function before setting up your module:" -msgstr "モジュールに正しく引数を渡すには、ディクショナリーをパラメーターとして受け付ける ``set_module_args`` メソッドを使用します。モジュールの作成と引数の処理は、ユーティリティーの基本セクションにある :class:`AnsibleModule` オブジェクトによって処理されます。通常は ``STDIN`` で入力を受け付けますが、これはユニットテストには不便です。特殊変数が設定されると、あたかも入力が ``STDIN`` でモジュールに来たかのように扱われます。モジュールをセットアップする前にこの関数を呼び出すだけです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:321 -msgid "Handling exit correctly" -msgstr "終了を適切に処理" - -#: ../../rst/dev_guide/testing_units_modules.rst:326 -msgid "The :meth:`module.exit_json` function won't work properly in a testing environment since it writes error information to ``STDOUT`` upon exit, where it is difficult to examine. This can be mitigated by replacing it (and :meth:`module.fail_json`) with a function that raises an exception:" -msgstr ":meth:`module.exit_json` 関数は、終了時にエラー情報を ``STDOUT`` に書き込むため、テスト環境で適切に動作しません。これは検証が困難です。これは、この関数 (および :meth:`module.fail_json`) を、例外を発生させる関数に置き換えることで軽減できます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:338 -msgid "Now you can ensure that the first function called is the one you expected simply by testing for the correct exception:" -msgstr "これで、正しい例外をテストするだけで、最初に呼び出された関数が期待したものであることを確認できるようになりました。" - -#: ../../rst/dev_guide/testing_units_modules.rst:353 -msgid "The same technique can be used to replace :meth:`module.fail_json` (which is used for failure returns from modules) and for the ``aws_module.fail_json_aws()`` (used in modules for Amazon Web Services)." -msgstr "同じテクニックを使用して、:meth:`module.fail_json` (モジュールから返る障害に使用) および ``aws_module.fail_json_aws()`` (Amazon Web Services のモジュールに使用) に置き換えることができます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:358 -msgid "Running the main function" -msgstr "主な関数の実行" - -#: ../../rst/dev_guide/testing_units_modules.rst:360 -msgid "If you do want to run the actual main function of a module you must import the module, set the arguments as above, set up the appropriate exit exception and then run the module:" -msgstr "モジュールにおける主な実関数を実行する場合は、モジュールをインポートし、上記のように引数を設定し、適切な終了例外を設定してからモジュールを実行する必要があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:380 -msgid "Handling calls to external executables" -msgstr "外部実行ファイルへの呼び出しの処理" - -#: ../../rst/dev_guide/testing_units_modules.rst:382 -msgid "Module must use :meth:`AnsibleModule.run_command` in order to execute an external command. This method needs to be mocked:" -msgstr "モジュールは、外部コマンドを実行するのに :meth:`AnsibleModule.run_command` を使用する必要があります。このメソッドをモックする必要があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:385 -msgid "Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`):" -msgstr "以下は、:meth:`AnsibleModule.run_command` (:file:`test/units/modules/packaging/os/test_rhn_register.py` から取得) の簡単なモックです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:401 -msgid "A Complete Example" -msgstr "完全な例" - -#: ../../rst/dev_guide/testing_units_modules.rst:403 -msgid "The following example is a complete skeleton that reuses the mocks explained above and adds a new mock for :meth:`Ansible.get_bin_path`:" -msgstr "次の例は、上記で説明したモックを再利用し、:meth:`Ansible.get_bin_path` の新しいモックを追加する完全なスケルトンです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:491 -msgid "Restructuring modules to enable testing module set up and other processes" -msgstr "モジュールのセットアップやその他のプロセスのテストを可能にするモジュールの再構築" - -#: ../../rst/dev_guide/testing_units_modules.rst:493 -msgid "Often modules have a ``main()`` function which sets up the module and then performs other actions. This can make it difficult to check argument processing. This can be made easier by moving module configuration and initialization into a separate function. For example:" -msgstr "多くの場合、モジュールをセットアップし、他のアクションを実行する ``main()`` 関数があります。これにより、引数処理を確認するのが困難になる可能性があります。モジュールの設定と初期化を別の関数に移すことで簡単にできます。以下に例を示します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:525 -msgid "This now makes it possible to run tests against the module initiation function:" -msgstr "これにより、モジュールの開始関数に対してテストを実行できるようになりました。" - -#: ../../rst/dev_guide/testing_units_modules.rst:539 -msgid "See also ``test/units/module_utils/aws/test_rds.py``" -msgstr "「``test/units/module_utils/aws/test_rds.py``」も参照してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:541 -msgid "Note that the ``argument_spec`` dictionary is visible in a module variable. This has advantages, both in allowing explicit testing of the arguments and in allowing the easy creation of module objects for testing." -msgstr "``argument_spec`` ディクショナリーはモジュール変数に表示されます。これには、引数の明示的なテストを許可し、テスト用にモジュールオブジェクトの作成を簡単に行えるようにする利点があります。" - -#: ../../rst/dev_guide/testing_units_modules.rst:545 -msgid "The same restructuring technique can be valuable for testing other functionality, such as the part of the module which queries the object that the module configures." -msgstr "この再構築の手法は、モジュールが設定したオブジェクトを問い合わせるモジュールの部分など、その他の機能をテストする場合にも役に立ちます。" - -#: ../../rst/dev_guide/testing_units_modules.rst:548 -msgid "Traps for maintaining Python 2 compatibility" -msgstr "Python 2 の互換性を維持するためのトラップ" - -#: ../../rst/dev_guide/testing_units_modules.rst:550 -msgid "If you use the ``mock`` library from the Python 2.6 standard library, a number of the assert functions are missing but will return as if successful. This means that test cases should take great care *not* use functions marked as _new_ in the Python 3 documentation, since the tests will likely always succeed even if the code is broken when run on older versions of Python." -msgstr "Python 2.6 標準ライブラリーの ``mock`` ライブラリーを使用している場合は、多くの assert 関数が欠落していますが、成功したかのように返されます。これは、テストケースが、Python 3 のドキュメントで _new_ となっている関数を使用しないよう、細心の注意を払うべきであることを意味します。なぜなら、古いバージョンの Python で実行されたコードが壊れていても、テストは常に成功するからです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:555 -msgid "A helpful development approach to this should be to ensure that all of the tests have been run under Python 2.6 and that each assertion in the test cases has been checked to work by breaking the code in Ansible to trigger that failure." -msgstr "これに役立つ開発アプローチは、すべてのテストが Python 2.6 で実行されていることと、テストケース内の各アサーションが Ansible でコードを壊してその失敗を誘発することで動作することが確認されているという点を確認することです。" - -#: ../../rst/dev_guide/testing_units_modules.rst:559 -msgid "Maintain Python 2.6 compatibility" -msgstr "Python 2.6 互換性の維持" - -#: ../../rst/dev_guide/testing_units_modules.rst:561 -msgid "Please remember that modules need to maintain compatibility with Python 2.6 so the unittests for modules should also be compatible with Python 2.6." -msgstr "モジュールは Python 2.6 との互換性を維持する必要があるため、モジュールのユニットテストも、Python 2.6 との互換性を維持する必要があることに注意してください。" - -#: ../../rst/dev_guide/testing_units_modules.rst:568 -msgid "Ansible unit tests documentation" -msgstr "Ansible ユニットテストドキュメント" - -#: ../../rst/dev_guide/testing_units_modules.rst:572 -msgid "Get started developing a module" -msgstr "モジュール開発を始める" - -#: ../../rst/dev_guide/testing_units_modules.rst:581 -msgid "`Testing Your Code (from The Hitchhiker's Guide to Python!) `_" -msgstr "`Testing Your Code (from The Hitchhiker's Guide to Python!) `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:582 -msgid "General advice on testing Python code" -msgstr "Python コードのテストに関する一般的なアドバイス" - -#: ../../rst/dev_guide/testing_units_modules.rst:584 -msgid "`Uncle Bob's many videos on YouTube `_" -msgstr "`Uncle Bob's many videos on YouTube `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:584 -msgid "Unit testing is a part of the of various philosophies of software development, including Extreme Programming (XP), Clean Coding. Uncle Bob talks through how to benefit from this" -msgstr "ユニットテストは、Extreme Programming (XP)、クリーンコーディングを含むソフトウェア開発のさまざまな哲学の一部です。Uncle Bob は、どのようにしてこの恩恵を受けることができるのかを説明します。" - -#: ../../rst/dev_guide/testing_units_modules.rst:586 -msgid "`\"Why Most Unit Testing is Waste\" `_" -msgstr "`\"Why Most Unit Testing is Waste\" `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:587 -msgid "An article warning against the costs of unit testing" -msgstr "ユニットテストの大半が無駄である理由" - -#: ../../rst/dev_guide/testing_units_modules.rst:588 -msgid "`'A Response to \"Why Most Unit Testing is Waste\"' `_" -msgstr "`'A Response to \"Why Most Unit Testing is Waste\"' `_" - -#: ../../rst/dev_guide/testing_units_modules.rst:589 -msgid "An response pointing to how to maintain the value of unit tests" -msgstr "ユニットテストの価値を維持する方法を指摘した回答" - -#: ../../rst/dev_guide/testing_validate-modules.rst:7 -msgid "This page has moved to :ref:`testing_validate-modules`." -msgstr "このページは :ref:`testing_validate-modules` に移動しました。" - -#~ msgid "All Python imports in ``lib/ansible/modules/`` and ``lib/ansible/module_utils/`` which are not from the Python standard library must be imported in a try/except ImportError block." -#~ msgstr "" - -#~ msgid "`irc.freenode.net `_" -#~ msgstr "`irc.freenode.net `_" - -#~ msgid "Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. You can publish and use collections through `Ansible Galaxy `_." -#~ msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して、Playbook、ロール、モジュール、プラグインをパッケージ化および配布できます。`Ansible Galaxy `_ を介してコレクションを公開および使用できます。" - -#~ msgid "For details on how to *use* collections see :ref:`collections`." -#~ msgstr "*use* コレクションの使用方法は、「:ref:`collections`」を参照してください。" - -#~ msgid "For the current development status of Collections and FAQ see `Ansible Collections Overview and FAQ `_." -#~ msgstr "コレクションおよび FAQ の現在の開発ステータスは、「`Ansible Collections Overview and FAQ `_」を参照してください。" - -#~ msgid "Put general documentation for the collection here. Keep the specific documentation for plugins and modules embedded as Python docstrings. Use the ``docs`` folder to describe how to use the roles and plugins the collection provides, role requirements, and so on. Use markdown and do not add subfolders." -#~ msgstr "ここでコレクションに関する一般的なドキュメントを追加します。Python ドキュメント文字列として埋め込まれたプラグインおよびモジュールに関する特定のドキュメントを保持します。``docs`` フォルダーを使用して、ロール、コレクションが提供するロール、ロール要件などを説明します。マークダウンを使用し、サブフォルダーを追加しないでください。" - -#~ msgid "TBD." -#~ msgstr "現在準備中です。" - -#~ msgid "To start a new collection:" -#~ msgstr "新規コレクションを開始するには、以下を使用します。" - -#~ msgid "Create a collection skeleton with the ``collection init`` command. See :ref:`creating_collections_skeleton` above." -#~ msgstr "``collection init`` コマンドでコレクションスケルトンを作成します。上記の「:ref:`creating_collections_skeleton`」を参照してください。" - -#~ msgid "Certain files and folders are excluded when building the collection artifact. See :ref:`ignoring_files_and_folders_collections` to exclude other files you would not want to distribute." -#~ msgstr "コレクションアーティファクトのビルド時に、特定のファイルおよびフォルダーは除外されます。配布したくない他のファイルを除外するには、「:ref:`ignoring_files_and_folders_collections`」を参照してください。" - -#~ msgid "If you used the now-deprecated ``Mazer`` tool for any of your collections, delete any and all files it added to your :file:`releases/` directory before you build your collection with ``ansible-galaxy``." -#~ msgstr "今回の非推奨となった ``Mazer`` ツールをコレクションに使用した場合は、``ansible-galaxy`` でコレクションをビルドする前に、:file:`releases/` ディレクトリーに追加したすべてのファイルを削除します。" - -#~ msgid "This tarball is mainly intended to upload to Galaxy as a distribution method, but you can use it directly to install the collection on target systems." -#~ msgstr "この tarball は、配布方法として主に Galaxy にアップロードすることを目的としていますが、ターゲットシステムにコレクションをインストールするために直接使用することもできます。" - -#~ msgid "You can try your collection locally by installing it from the tarball. The following will enable an adjacent playbook to access the collection:" -#~ msgstr "コレクションを tarball からインストールすることで、コレクションをローカルで試すことができます。以下では、隣接用の Playbook がコレクションにアクセスできるようになります。" - -#~ msgid "You should use one of the values configured in :ref:`COLLECTIONS_PATHS` for your path. This is also where Ansible itself will expect to find collections when attempting to use them. If you don't specify a path value, ``ansible-galaxy collection install`` installs the collection in the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``." -#~ msgstr "パスのために、:ref:`COLLECTIONS_PATHS` で構成された値の 1 つを使用する必要があります。これは、Ansible 自体がコレクションを使用しようとしたときにコレクションを見つけることを期待する場所でもあります。パス値を指定しない場合は、:ref:`COLLECTIONS_PATHS` で定義された最初のパスにコレクションをインストールします。これは、デフォルトは、``~/.ansible/collections`` となります。" - -#~ msgid "If you want to use a collection directly out of a checked out git repository, see :ref:`hacking_collections`." -#~ msgstr "確認された git リポジトリーから直接コレクションを使用する場合は、「:ref:`hacking_collections`」を参照してください。" - -#~ msgid "Next, try using the local collection inside a playbook. For examples and more details see :ref:`Using collections `" -#~ msgstr "次に、Playbook 内でローカルコレクションの使用を試行します。例および詳細は、「:ref:`コレクションの使用 `」を参照してください。" - -#~ msgid "You can also test a version of your collection in development by installing it from a git repository." -#~ msgstr "また、Git リポジトリーからインストールすることで、開発でコレクションのバージョンをテストすることもできます。" - -#~ msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ version (for example, a commit or tag)." -#~ msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish `_ バージョン (コミットまたはタグなど) をサポートする必要があります。" - -#~ msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." -#~ msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" - -#~ msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name." -#~ msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。" - -#~ msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts." -#~ msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。" - -#~ msgid "Default repository search locations" -#~ msgstr "デフォルトのリポジトリー検索の場所" - -#~ msgid "There are two paths searched in a repository for collections by default." -#~ msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。" - -#~ msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection." -#~ msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。" - -#~ msgid "Specifying the location to search for collections" -#~ msgstr "コレクションを検索する場所の指定" - -#~ msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)." -#~ msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。" - -#~ msgid "You can publish collections to Galaxy using the ``ansible-galaxy collection publish`` command or the Galaxy UI itself. You need a namespace on Galaxy to upload your collection. See `Galaxy namespaces `_ on the Galaxy docsite for details." -#~ msgstr "``ansible-galaxy collection publish`` コマンドまたは Galaxy UI 自体を使用して、コレクションを Galaxy に公開することができます。コレクションをアップロードするには、Galaxy に名前空間が必要です。詳細は、Galaxy のドキュメントスイートの「`Galaxy 名前空間 `_」を参照してください。" - -#~ msgid "Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before you upload it." -#~ msgstr "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべての情報が適切であることを確認します。" - -#~ msgid "To upload your collection to Galaxy, you must first obtain an API token (``--token`` in the ``ansible-galaxy`` CLI command or ``token`` in the :file:`ansible.cfg` file under the ``galaxy_server`` section). The API token is a secret token used to protect your content." -#~ msgstr "コレクションを Galaxy にアップロードするには、まず API トークンを取得する必要があります (``ansible-galaxy`` CLI コマンドの ``--token``、または ``galaxy_server`` セクションの下の :file:`ansible.cfg` ファイルの ``token``) は、コンテンツを保護するために使用されるシークレットトークン。" - -#~ msgid "Storing or using your API token" -#~ msgstr "API トークンの保存または使用" - -#~ msgid "Once you have retrieved your API token, you can store or use the token for collections in two ways:" -#~ msgstr "API トークンを取得したら、2 つの方法でコレクションにトークンを保存または使用することができます。" - -#~ msgid "Pass the token to the ``ansible-galaxy`` command using the ``--token``." -#~ msgstr "``--token`` を使用して、トークンを ``ansible-galaxy`` コマンドに渡します。" - -#~ msgid "Specify the token within a Galaxy server list in your :file:`ansible.cfg` file." -#~ msgstr ":file:`ansible.cfg` ファイルの Galaxy サーバーリスト内のトークンを指定します。" - -#~ msgid "Using the ``token`` argument" -#~ msgstr "``token`` 引数の使用" - -#~ msgid "You can use the ``--token`` argument with the ``ansible-galaxy`` command (in conjunction with the ``--server`` argument or :ref:`GALAXY_SERVER` setting in your :file:`ansible.cfg` file). You cannot use ``apt-key`` with any servers defined in your :ref:`Galaxy server list `." -#~ msgstr "``--token`` 引数は、``ansible-galaxy`` コマンド (:file:`ansible.cfg` ファイルの ``--server`` 引数または :ref:`GALAXY_SERVER` 設定とともに) で使用できます。:ref:`Galaxy サーバー一覧 ` で定義されているサーバーでは、``apt-key`` を使用することはできません。" - -#~ msgid "Specify the token within a Galaxy server list" -#~ msgstr "Galaxy サーバー一覧内でトークンの指定" - -#~ msgid "With this option, you configure one or more servers for Galaxy in your :file:`ansible.cfg` file under the ``galaxy_server_list`` section. For each server, you also configure the token." -#~ msgstr "このオプションを使用して、``galaxy_server_list`` セクションの下にある :file:`ansible.cfg` で Galaxy 用に 1 つ以上のサーバーを構成します。サーバーごとに、トークンも構成します。" - -#~ msgid "See :ref:`galaxy_server_config` for complete details." -#~ msgstr "詳細は、「:ref:`galaxy_server_config`」を参照してください。" - -#~ msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). If you are only publishing your collection to Ansible Galaxy, you do not need any further configuration. If you are using Red Hat Automation Hub or any other Galaxy server, see :ref:`Configuring the ansible-galaxy client `." -#~ msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の下の :file:`ansible.cfg` ファイルに記載されるように)。`galaxy_server` コレクションのみを Ansible Galaxy に公開している場合は、追加設定は必要ありません。Red Hat Automation Hub またはその他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 `」を参照してください。" - -#~ msgid "When uploading collections it doesn't matter which namespace you select. The collection will be uploaded to the namespace specified in the collection metadata in the ``galaxy.yml`` file. If you're not an owner of the namespace, the upload request will fail." -#~ msgstr "コレクションをアップロードする際に、選択した名前空間は重要ではありません。コレクションは ``galaxy.yml`` ファイルのコレクションメタデータに指定された名前空間にアップロードされます。名前空間の所有者がない場合、アップロード要求は失敗します。" - -#~ msgid "Once Galaxy uploads and accepts a collection, you will be redirected to the **My Imports** page, which displays output from the import process, including any errors or warnings about the metadata and content contained in the collection." -#~ msgstr "Galaxy がコレクションをアップロードして受け入れると、**My Imports** ページにリダイレクトされます。このページには、コレクションに含まれるメタデータやコンテンツに関するエラーや警告など、インポート処理の出力が表示されます。" - -#~ msgid "Collection versions" -#~ msgstr "コレクションのバージョン" - -#~ msgid "Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before uploading. The only way to change a collection is to release a new version. The latest version of a collection (by highest version number) will be the version displayed everywhere in Galaxy; however, users will still be able to download older versions." -#~ msgstr "コレクションのバージョンをアップロードしたら、そのバージョンを削除または変更することはできません。アップロードする前に、すべてが正常に見えることを確認してください。コレクションを変更する唯一の方法は、新しいバージョンをリリースすることです。(最大バージョン番号による) コレクションの最新バージョンは、Galaxy のあらゆる場所に表示されるバージョンになります。ただし、ユーザーは引き続き古いバージョンをダウンロードできます。" - -#~ msgid "BOTMETA.yml" -#~ msgstr "BOTMETA.yml" - -#~ msgid "We assume that you have included ``~/dev/ansible/collections/`` in :ref:`COLLECTIONS_PATHS`, and if that path mentions multiple directories, that you made sure that no other directory earlier in the search path contains a copy of ``community.general``. Create the directory ``~/dev/ansible/collections/ansible_collections/community``, and in it clone `the community.general Git repository `_ or a fork of it into the folder ``general``::" -#~ msgstr ":ref:`COLLECTIONS_PATHS` に ``~/dev/ansible/collections/`` が含まれており、そのパスで複数のディレクトリーに言及されている場合は、検索パスの他のディレクトリーに ``community.general`` のコピーが含まれないようにします。``~/dev/ansible/collections/ansible_collections/community`` ディレクトリーを作成して、その中に `the community.general Git repository `_ のクローンを作成するか、フォルダー ``general`` にそのディレクトリーのフォークを作成します。" - -#~ msgid "For collections hosted in the ``ansible_collections`` GitHub org, create a branch and commit your changes on the branch. When you are done (remember to add tests, see :ref:`testing_collections`), push your changes to your fork of the collection and create a Pull Request. For other collections, especially for collections not hosted on GitHub, check the ``README.md`` of the collection for information on contributing to it." -#~ msgstr "``ansible_collections`` GitHub の団体でホストされるコレクションの場合は、ブランチを作成し、ブランチで変更をコミットします。これが完了したら、(テストを追加する方法は、:ref:`testing_collections` を参照してください)。コレクションのフォークに変更をプッシュし、プル要求を作成します。他のコレクション (特に GitHub がホストされていないコレクション) については、コレクションの ``README.md`` でこれに貢献する情報を確認してください。" - -#~ msgid "We recommend that you use the `antsibull-changelog `_ tool to generate Ansible-compatible changelogs for your collection. The Ansible changelog uses the output of this tool to collate all the collections included in an Ansible release into one combined changelog for the release." -#~ msgstr "`antsibull-changelog `_ ツールを使用してコレクションに Ansible 互換の changelog を生成することが推奨されます。Ansibleの changelog は、このツールの出力を利用して、Ansible のリリースに含まれるすべてのコレクションを、そのリリースの 1 つの統合されたチェンジログに照合します。" - -#~ msgid "Porting Guide entries" -#~ msgstr "移植ガイドエントリー" - -#~ msgid "The following changelog fragment categories are consumed by the Ansible changelog generator into the Ansible Porting Guide:" -#~ msgstr "以下の changelog フラグメントカテゴリーは、Ansible changelog ジェネレーターが Ansible 移植ガイドに使用されます。" - -#~ msgid "Understand the collections metadata structure." -#~ msgstr "コレクションのメタデータ構造を理解します。" - -#~ msgid "When the script is called with the single argument ``--list``, the script must output to stdout a JSON-encoded hash or dictionary that contains all the groups to be managed. Each group's value should be either a hash or dictionary containing a list of each host, any child groups, and potential group variables, or simply a list of hosts::" -#~ msgstr "スクリプトが単一の引数 ``--list`` で呼び出されると、スクリプトは、標準出力に、管理するすべてのグループが含まれる JSON でエンコードされたハッシュまたはディクショナリーを出力する必要があります。各グループの値は、各ホスト、子グループ、および潜在的なグループ変数の一覧を含むハッシュまたはディクショナリーにする必要があります。" - -#~ msgid "When called with the argument ``--host `` (where is a host from above), the script must print either an empty JSON hash/dictionary, or a hash/dictionary of variables to make them available to templates and playbooks. For example::" -#~ msgstr "引数 ``--host `` ( は上述のホスト) で呼び出されると、スクリプトは空の JSON ハッシュ/ディクショナリーか、テンプレートや Playbook で利用できるようにするための変数のハッシュ/ディクショナリーを出力しなければなりません。たとえば、以下のようになります。" - -#~ msgid "`Ansible Tower `_" -#~ msgstr "`Ansible Tower `_" - -#~ msgid "The easiest, quickest, and the most popular way to extend Ansible is to use a local module or a plugin. You can create them or copy existing ones for local use. You can store a local module or plugin on your Ansible control node and share it with your team or organization. You can also share a local plugin or module by including it in a collection or embedding it in a role, then publishing the collection or role on Ansible Galaxy. If you are using roles on Ansible Galaxy, then you are already using local modules and plugins without realizing it." -#~ msgstr "Ansible を拡張する最も簡単な方法は、ローカルモジュールまたはプラグインを使用することです。ローカルで使用するためにこれらを作成するか、既存のものをコピーすることができます。Ansible コントロールノードにローカルモジュールまたはプラグインを保存し、チームまたは組織と共有することができます。また、ローカルプラグインまたはモジュールをコレクションに含めるか、ロールに埋め込むことで、Ansible Galaxy にコレクションまたはロールを公開することもできます。Ansible Galaxy でロールを使用している場合は、認識せずにローカルモジュールとプラグインをすでに使用していることになります。" - -#~ msgid "If you are using an existing module or plugin but Ansible can't find it, this page is all you need. However, if you want to create a plugin or a module, go to :ref:`developing_plugins` and :ref:`developing_modules_general` topics and then return to this page to know how to add it locally." -#~ msgstr "既存のモジュールまたはプラグインを使用しているにもかかわらず、Ansible で見つからない場合、このページのみが必要となります。プラグインまたはモジュールを作成する場合は、:ref:`developing_plugins` および :ref:`developing_modules_general` トピックに移動してから、このページに戻り、ローカルで追加する方法を説明します。" - -#~ msgid "To save a local module or plugin such that Ansible can find and use it, add the module or plugin in the appropriate directory (the directories are specified in later parts of this topic)." -#~ msgstr "Ansible が検出して使用するようにローカルモジュールまたはプラグインを保存するには、適切なディレクトリーにモジュールまたはプラグインを追加します (ディレクトリーは、本トピックの後半で指定されています)。" - -#~ msgid "Adding a module locally" -#~ msgstr "モジュールをローカルで追加" - -#~ msgid "Ansible automatically loads all executable files found in certain directories as modules." -#~ msgstr "Ansible は、特定のディレクトリーにある実行可能ファイルをすべてモジュールとして自動的に読み込みます。" - -#~ msgid "For local modules, use the name of the file as the module name: for example, if the module file is ``~/.ansible/plugins/modules/local_users.py``, use ``local_users`` as the module name." -#~ msgstr "ローカルモジュールの場合は、ファイル名をモジュール名として使用します。たとえば、モジュールファイルが ``~/.ansible/plugins/modules/local_users.py`` の場合は、モジュール名として ``local_users`` を使用します。" - -#~ msgid "To load your local modules automatically and make them available to all playbooks and roles, add them in any of these locations:" -#~ msgstr "ローカルモジュールを自動的に読み込み、すべての Playbook およびロールで使用できるようにするには、それらを以下のいずれかの場所に追加します。" - -#~ msgid "any directory added to the ``ANSIBLE_LIBRARY`` environment variable (``$ANSIBLE_LIBRARY`` takes a colon-separated list like ``$PATH``)" -#~ msgstr "``ANSIBLE_LIBRARY`` 環境変数に追加されたディレクトリー (``$ANSIBLE_LIBRARY`` は ``$PATH``のようにコロンで区切った一覧)" - -#~ msgid "``~/.ansible/plugins/modules/``" -#~ msgstr "``~/.ansible/plugins/modules/``" - -#~ msgid "``/usr/share/ansible/plugins/modules/``" -#~ msgstr "``/usr/share/ansible/plugins/modules/``" - -#~ msgid "or" -#~ msgstr "または" - -#~ msgid "You can limit the availability of your local module. If you want to use a local module only with selected playbooks or only with a single role, load it in one of the following locations:" -#~ msgstr "ローカルモジュールの可用性を制限することができます。選択した Playbook でのみローカルモジュールを使用する場合、または単一のロールでのみローカルモジュールを使用する場合は、以下のいずれかの場所にロードします。" - -#~ msgid "Adding a plugin locally" -#~ msgstr "プラグインをローカルで追加" - -#~ msgid "Ansible loads plugins automatically too, and loads each type of plugin separately from a directory named for the type of plugin. Here's the full list of plugin directory names:" -#~ msgstr "Ansible はプラグインも自動的にロードし、プラグインのタイプに対して名前が付けられたディレクトリーとは別に、各タイプのプラグインを読み込みます。プラグインディレクトリー名の全一覧を以下に示します。" - -#~ msgid "cache_plugins" -#~ msgstr "cache_plugins" - -#~ msgid "callback_plugins" -#~ msgstr "callback_plugins" - -#~ msgid "connection_plugins" -#~ msgstr "connection_plugins" - -#~ msgid "filter_plugins*" -#~ msgstr "filter_plugins*" - -#~ msgid "inventory_plugins" -#~ msgstr "inventory_plugins" - -#~ msgid "lookup_plugins" -#~ msgstr "lookup_plugins" - -#~ msgid "shell_plugins" -#~ msgstr "shell_plugins" - -#~ msgid "strategy_plugins" -#~ msgstr "strategy_plugins" - -#~ msgid "test_plugins*" -#~ msgstr "test_plugins*" - -#~ msgid "vars_plugins" -#~ msgstr "vars_plugins" - -#~ msgid "After you add the plugins and verify that they are available for use, you can see the documentation for all the plugins except for the ones marked with an asterisk (*) above." -#~ msgstr "プラグインを追加して、それらが使用できることを確認すると、上記のアスタリスク (*) のマークが付いたものを除き、すべてのプラグインのドキュメントを表示できます。" - -#~ msgid "To load your local plugins automatically, add them in any of these locations:" -#~ msgstr "ローカルプラグインを自動的に読み込むには、以下のいずれかの場所に追加します。" - -#~ msgid "any directory added to the relevant ``ANSIBLE_plugin_type_PLUGINS`` environment variable (these variables, such as ``$ANSIBLE_INVENTORY_PLUGINS`` and ``$ANSIBLE_VARS_PLUGINS`` take colon-separated lists like ``$PATH``)" -#~ msgstr "関連する ``ANSIBLE_plugin_type_PLUGINS`` 環境変数に追加されたディレクトリー (``$ANSIBLE_INVENTORY_PLUGINS``、``$ANSIBLE_VARS_PLUGINS`` など) は、``$PATH`` のようにコロンで区切った一覧を取ります。" - -#~ msgid "the directory named for the correct ``plugin_type`` within ``~/.ansible/plugins/`` - for example, ``~/.ansible/plugins/callback``" -#~ msgstr "``~/.ansible/plugins/`` 内の正しい ``plugin_type`` という名前のディレクトリー (例: ``~/.ansible/plugins/callback``)" - -#~ msgid "the directory named for the correct ``plugin_type`` within ``/usr/share/ansible/plugins/`` - for example, ``/usr/share/ansible/plugins/action``" -#~ msgstr "``/usr/share/ansible/plugins/`` 内の正しい ``plugin_type`` という名前のディレクトリー (例: ``/usr/share/ansible/plugins/action``)" - -#~ msgid "type ``ansible-doc -t my_custom_lookup_plugin``. For example, ``ansible-doc -t lookup my_custom_lookup_plugin``. You should see the documentation for that plugin. This works for all plugin types except the ones marked with ``*`` in the list above - see :ref:`ansible-doc` for more details." -#~ msgstr "``ansible-doc -t my_custom_lookup_plugin`` を入力します (例: ``ansible-doc -t lookup my_custom_lookup_plugin``)。そのプラグインに関するドキュメントを確認してください。これは上記のリストで ``*`` のマークが付いたもの以外のすべてのプラグインタイプで機能します。詳細は「:ref:`ansible-doc`」を参照してください。" - -#~ msgid "You can limit the availability of your local plugin. If you want to use a local plugin only with selected playbooks or only with a single role, load it in one of the following locations:" -#~ msgstr "ローカルプラグインの可用性を制限することができます。選択した Playbook でのみローカルプラグインを使用する場合、または単一のロールでのみローカルプラグインを使用する場合は、以下のいずれかの場所に読み込みます。" - -#~ msgid "In a selected playbook or playbooks: Store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``callback_plugins`` or ``inventory_plugins``) in the directory that contains the playbooks." -#~ msgstr "選択した Playbook: そのPlaybook を含むディレクトリーに、正しい ``plugin_type`` (例: ``callback_plugins`` または ``inventory_plugins``) のサブディレクトリーにプラグインを保存します。" - -#~ msgid "In a single role: Store the plugin in a subdirectory for the correct ``plugin_type`` (for example, ``cache_plugins`` or ``strategy_plugins``) within that role. When shipped as part of a role, the plugin is available as soon as the role is executed." -#~ msgstr "単一のロール: そのロール内で、正しい ``plugin_type`` （例： ``cache_plugins`` または ``strategy_plugins``) のサブディレクトリーにプラグインを保存します。ロールの一部として提供されると、ロールが実行されるとすぐにプラグインが利用可能になります。" - -#~ msgid "Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow the :ref:`Amazon development checklist `." -#~ msgstr "該当する場合は、モジュールのファミリーに適用される追加のガイドラインに従います。たとえば、AWS モジュールは :ref:`Amazon development checklist ` に従う必要があります。" - -#~ msgid "Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via `Ansible's IRC chat channel `_ or the `Ansible development mailing list `_." -#~ msgstr "PR/提案を送信する前に、お使いのモジュールがこれらの要件を満たしていることを確認してください。ご質問がある場合は、`Ansible の IRC チャットチャンネル `_ または `Ansible 開発メーリングリスト `_ までお問い合わせください。" - -#~ msgid ":ref:`Amazon development checklist `." -#~ msgstr ":ref:`Amazon 開発チェックリスト `" - -#~ msgid "Major additions to the module (for instance, rewrites) may add additional copyright lines. Any legal review will include the source control history, so an exhaustive copyright header is not necessary. Please do not edit the existing copyright year. This simplifies project administration and is unlikely to cause any interesting legal issues. When adding a second copyright line for a significant feature or rewrite, add the newer line above the older one:" -#~ msgstr "モジュールへの主要な追加 (たとえば、書き換え) は、により、著作権行が追加される場合があります。法的な審査にはソース管理履歴が含まれるため、網羅的な著作権ヘッダーは必要ありません。既存の著作権年は編集しないでください。これは、プロジェクトの管理を単純化するものであり、興味深い法的問題を引き起こす可能性はほとんどありません。重要な機能や書き換えのために 2 行目の著作権行を追加する場合は、古い行の上に新しい行を追加します。" - -#~ msgid "``L()`` for links with a heading. For example: ``See L(Ansible Tower,https://www.ansible.com/products/tower).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation." -#~ msgstr "``L()`` 見出しへのリンク。たとえば、``See L(Ansible Tower,https://www.ansible.com/products/tower).`` となります。Ansible 2.10 以降、Ansible ドキュメントとコレクションのドキュメントの相対リンクには ``L()`` を使用しないでください。" - -#~ msgid "Installing prerequisites via apt (Ubuntu)" -#~ msgstr "apt (Ubuntu) を使用した前提条件のインストール" - -#~ msgid "Due to dependencies (for example ansible -> paramiko -> pynacl -> libffi):" -#~ msgstr "依存関係のため (例: ansible -> paramiko -> pynacl -> libffi)。" - -#~ msgid "Creating a development environment (platform-agnostic steps)" -#~ msgstr "開発環境の作成 (プラットフォームに依存しない手順)" - -#~ msgid "Clone the Ansible repository: ``$ git clone https://github.com/ansible/ansible.git``" -#~ msgstr "Ansible リポジトリーのクローンを作成します (``$ git clone https://github.com/ansible/ansible.git``)。" - -#~ msgid "Change directory into the repository root dir: ``$ cd ansible``" -#~ msgstr "ディレクトリーをリポジトリーの root ディレクトリーに変更します (``$ cd ansible``)。" - -#~ msgid "Create a virtual environment: ``$ python3 -m venv venv`` (or for Python 2 ``$ virtualenv venv``. Note, this requires you to install the virtualenv package: ``$ pip install virtualenv``)" -#~ msgstr "仮想環境を作成します (``$ python3 -m venv venv``) (Python 2 の場合は ``$ virtualenv venv`` です。これには、virtualenv パッケージ ``$ pip install virtualenv`` をインストールする必要があります。" - -#~ msgid "Activate the virtual environment: ``$ . venv/bin/activate``" -#~ msgstr "仮想環境をアクティベートします (``$ . venv/bin/activate``)。" - -#~ msgid "Install development requirements: ``$ pip install -r requirements.txt``" -#~ msgstr "開発要件をインストールします (``$ pip install -r requirements.txt``)。" - -#~ msgid "Run the environment setup script for each new dev shell process: ``$ . hacking/env-setup``" -#~ msgstr "新規 dev シェルプロセスごとに環境設定スクリプトを実行します (``$ . hacking/env-setup``)。" - -#~ msgid "After the initial setup above, every time you are ready to start developing Ansible you should be able to just run the following from the root of the Ansible repo: ``$ . venv/bin/activate && . hacking/env-setup``" -#~ msgstr "上記の初期設定後、Ansible の開発準備ができるたびに、Ansible リポジトリーのルートから ``$ . venv/bin/activate && . hacking/env-setup`` を実行できるはずです。" - -#~ msgid "To create an info module:" -#~ msgstr "info モジュールを作成するには、次を実行します。" - -#~ msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing module using collection, ``$ cd plugins/modules/`` inside your collection development tree." -#~ msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。コレクションを使用してモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。" - -#~ msgid "Create your new module file: ``$ touch my_test_info.py``." -#~ msgstr "新しいモジュールファイルを作成します (``$ touch my_test_info.py``)。" - -#~ msgid "Paste the content below into your new info module file. It includes the :ref:`required Ansible format and documentation `, a simple :ref:`argument spec for declaring the module options `, and some example code." -#~ msgstr "以下の内容を新しい情報モジュールファイルに貼り付けます。これには、:ref:`必須の Ansible 形式およびドキュメント `、:ref:`モジュールオプションを宣言する単純な引数仕様 `、およびサンプルコードが含まれます。" - -#~ msgid "Modify and extend the code to do what you want your new info module to do. See the :ref:`programming tips ` and :ref:`Python 3 compatibility ` pages for pointers on writing clean and concise module code." -#~ msgstr "新しい情報モジュールが実行することを行えるようにコードを変更し、拡張します。余計なものが入っていないモジュールコードや、簡潔なモジュールコードの作成に関するヒントは、「:ref:`プログラミングのヒント `」ページおよび「:ref:`Python 3 互換性 `」ページを参照してください。" - -#~ msgid "Navigate to the correct directory for your new module: ``$ cd lib/ansible/modules/``. If you are developing a module in a :ref:`collection `, ``$ cd plugins/modules/`` inside your collection development tree." -#~ msgstr "新しいモジュールの正しいディレクトリーに移動します (``$ cd lib/ansible/modules/``)。:ref:`コレクション ` でモジュールを開発する場合は、コレクション開発ツリー内で ``$ cd plugins/modules/`` を実行します。" - -#~ msgid "If you are using a virtual environment (which is highly recommended for development) activate it: ``$ . venv/bin/activate``" -#~ msgstr "(開発に非常に推奨されている) 仮想環境を使用している場合は、アクティベートします (``$ . venv/bin/activate``)。" - -#~ msgid "Set up the environment for development: ``$ . hacking/env-setup``" -#~ msgstr "開発用の環境を設定します (``$ . hacking/env-setup``)。" - -#~ msgid "Run your test module locally and directly: ``$ python -m ansible.modules.my_test /tmp/args.json``" -#~ msgstr "テストモジュールをローカルで直接実行します (``$ python -m ansible.modules.my_test /tmp/args.json``)。" - -#~ msgid "The next step in verifying your new module is to consume it with an Ansible playbook." -#~ msgstr "新規モジュールを検証する次のステップは、Ansible Playbook で使用します。" - -#~ msgid "You can add unit tests for your module in ``./test/units/modules``. You must first set up your testing environment. In this example, we're using Python 3.5." -#~ msgstr "モジュールのユニットテストは ``./test/units/modules`` で追加できます。まずテスト環境を設定する必要があります。この例では、Python 3.5 を使用しています。" - -#~ msgid "Install the requirements (outside of your virtual environment): ``$ pip3 install -r ./test/lib/ansible_test/_data/requirements/units.txt``" -#~ msgstr "(仮想環境外に) 要件をインストールします (``$ pip3 install -r ./test/lib/ansible_test/_data/requirements/units.txt``)。" - -#~ msgid "Run ``. hacking/env-setup``" -#~ msgstr "``. hacking/env-setup`` を実行します。" - -#~ msgid "To run all tests do the following: ``$ ansible-test units --python 3.5``. If you are using a CI environment, these tests will run automatically." -#~ msgstr "すべてのテストを実行するには、``$ ansible-test units --python 3.5`` で CI 環境を使用している場合は、これらのテストが自動的に実行されます。" - -#~ msgid "Ansible uses pytest for unit testing." -#~ msgstr "Ansible はユニットテストに pytest を使用します。" - -#~ msgid "To run pytest against a single test module, you can run the following command. Ensure that you are providing the correct path of the test module:" -#~ msgstr "単一のテストモジュールに対して pytest を実行するには、以下のコマンドを実行します。テストモジュールの正しいパスを提供していることを確認してください。" - -#~ msgid "``$ pytest -r a --cov=. --cov-report=html --fulltrace --color yes test/units/modules/.../test/my_test.py``" -#~ msgstr "``$ pytest -r a --cov=. --cov-report=html --fulltrace --color yes test/units/modules/.../test/my_test.py``" - -#~ msgid "Join the IRC channel ``#ansible-devel`` on freenode for discussions surrounding Ansible development." -#~ msgstr "Ansible 開発に取り組むため、freenode の IRC チャンネル ``#ansible-devel`` に参加します。" - -#~ msgid "`jborean93/WindowsServer2008-x86 `_" -#~ msgstr "`jborean93/WindowsServer2008-x86 `_" - -#~ msgid "`jborean93/WindowsServer2008-x64 `_" -#~ msgstr "`jborean93/WindowsServer2008-x64 `_" - -#~ msgid "`jborean93/WindowsServer2008R2 `_" -#~ msgstr "`jborean93/WindowsServer2008R2 `_" - -#~ msgid "While an SSH server is available on all Windows hosts but Server 2008 (non R2), it is not a support connection for Ansible managing Windows hosts and should not be used with Ansible." -#~ msgstr "SSH サーバーはすべての Windows ホストで利用できますが、Server 2008 (R2 以外) は、Ansible による Windows ホストの管理接続ではなく、Ansible では使用できません。" - -#~ msgid "Join the IRC channel ``#ansible-devel`` or ``#ansible-windows`` on freenode for discussions about Ansible development for Windows." -#~ msgstr "freenode の IRC チャネル ``#ansible-devel`` または ``#ansible-windows`` に参加し、Windows 用 の Ansible 開発に関する議論を行うこと。" - -#~ msgid "``#ansible-devel`` - We have found that IRC ``#ansible-devel`` on FreeNode's IRC network works best for developers so we can have an interactive dialogue." -#~ msgstr "``#ansible-devel`` - FreeNode の IRC ネットワーク ``#ansible-devel`` では、インタラクティブな対話を行うことができるため、モジュール開発者に最適なものであることが分かっています。" - -#~ msgid "If you need help or advice, consider join the ``#ansible-devel`` IRC channel (see how in the \"Where to get support\")." -#~ msgstr "さらにヘルプまたはアドバイスが必要な場合は、IRC チャンネル ``#ansible-devel`` に参加することを検討してください (「サポートを得る方法」を参照してください)。" - -#~ msgid "Lookup plugins are very flexible, allowing you to retrieve and return any type of data. When writing lookup plugins, always return data of a consistent type that can be easily consumed in a playbook. Avoid parameters that change the returned data type. If there is a need to return a single value sometimes and a complex dictionary other times, write two different lookup plugins." -#~ msgstr "Lookup プラグインは非常に柔軟性があるため、あらゆるタイプのデータを取得し、返すことができます。Lookup プラグインを記述する際には、Playbook で簡単に使用できる一貫性のあるタイプのデータを常に返します。返されたデータ型を変更するパラメーターは使用しないでください。単一の値を返さなければならないときもあれば、複雑なディクショナリーを返さなければない場合もあります。この場合は、Lookup プラグインを 2 つ記述してください。" - -#~ msgid "You can create vars plugins that are not enabled by default using the class variable ``REQUIRES_ENABLED``. If your vars plugin resides in a collection, it cannot be enabled by default. You must use ``REQUIRES_ENABLED`` in all collections-based vars plugins. To require users to enable your plugin, set the class variable ``REQUIRES_ENABLED``:" -#~ msgstr "クラス変数 ``REQUIRES_ENABLED`` を使用して、デフォルトで有効になっていない vars プラグインを作成できます。vars プラグインがコレクションに存在する場合は、デフォルトで有効にはできません。すべてのコレクションベースの vars プラグインで ``REQUIRES_ENABLED`` を使用する必要があります。ユーザーがプラグインを有効にするには、クラス変数 ``REQUIRES_ENABLED`` を設定します。" - -#~ msgid "``removed_in_version`` indicates which version of ansible-base or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``." -#~ msgstr "``removed_in_version`` は、非推奨の引数が削除される ansible-base またはコレクションのバージョンを示します。``removed_at_date`` で相互排他され、``removed_from_collection`` で使用する必要があります。" - -#~ msgid "``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-base release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``." -#~ msgstr "``removed_at_date`` は、非推奨の引数が、この日付以降のマイナーな ansible-base リリースまたはメジャーコレクションリリースで削除されることを示します。``removed_in_version`` と相互に排他的であり、``removed_from_collection`` と一緒に使用する必要があります。" - -#~ msgid "The ``ansible-base`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide variety of machines. Contributors to ansible-base and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible." -#~ msgstr "Ansible が各種マシンを管理できるようにするため、``ansible-base`` コードは Python 2 と Python 3 の両方で実行されます。Ansible ベースと Ansible Collections では、Ansible の残りの部分と同じバージョンの Python で実行されるコードを記述できる必要があります。" - -#~ msgid "To ensure that your code runs on Python 3 as well as on Python 2, learn the tips and tricks and idioms described here. Most of these considerations apply to all three types of Ansible code:" -#~ msgstr "Python 2 および Python 2 でコードが実行されるようにするには、ここで説明するヒントとコツ、およびイディオムを確認してください。これらの考慮事項は、これら 3 種類の Ansible コードのすべてに適用されます。" - -#~ 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." -#~ msgstr "コントローラーでは、Python 3.5 以降、および Python 2.7 以降をサポートしています。モジュール側では、Python 3.5 以降、Python 2.6 以降をサポートします。" - -#~ msgid "Python 3.5 was chosen as a minimum because it is the earliest Python 3 version adopted as the default Python by a Long Term Support (LTS) Linux distribution (in this case, Ubuntu-16.04). Previous LTS Linux distributions shipped with a Python 2 version which users can rely upon instead of the Python 3 version." -#~ msgstr "Python 3.5 は、長期サポート (LTS: Long Term Support) の Linux ディストリビューション (この場合は Ubuntu-16.04) でデフォルトの Python として採用されている最も古い Python 3 のバージョンであるため、最小バージョンとして採用されました。以前の LTS Linux ディストリビューションでは、Python 3 バージョンの代わりに、ユーザーが代わりに使用できる Python 2 バージョンが同梱されていました。" - -#~ msgid "For Python 2, the default is for modules to run on at least Python 2.6. This allows users with older distributions that are stuck on Python 2.6 to manage their machines. Modules are allowed to drop support for Python 2.6 when one of their dependent libraries requires a higher version of Python. This is not an invitation to add unnecessary dependent libraries in order to force your module to be usable only with a newer version of Python; instead it is an acknowledgment that some libraries (for instance, boto3 and docker-py) will only function with a newer version of Python." -#~ msgstr "Python 2 では、モジュールは少なくとも Python 2.6 で動作することがデフォルトとなっています。これにより、Python 2.6 に固執する古いディストリビューションのユーザーが自分のマシンを管理できるようになります。モジュールは、依存するライブラリーの 1 つがより高いバージョンの Python を必要とする場合は、Python 2.6 のサポートを終了することができます。これは、自作したモジュールをより新しいバージョンの Python でしか使えないようにするために、不要な依存ライブラリーを追加することを勧めるものではありません。代わりに、いくつかのライブラリー (例えば、boto3 や docker-py) はより新しいバージョンの Python でしか機能しないことを認めています。" - -#~ msgid "Python 2.4 Module-side Support:" -#~ msgstr "Python 2.4 モジュールでのサポート:" - -#~ msgid "Support for Python 2.4 and Python 2.5 was dropped in Ansible-2.4. RHEL-5 (and its rebuilds like CentOS-5) were supported until April of 2017. Ansible-2.3 was released in April of 2017 and was the last Ansible release to support Python 2.4 on the module-side." -#~ msgstr "Python 2.4 および Python 2.5 のサポートは Ansible-2.4 から削除されました。RHEL-5 (および CentOS-5) は 2017 年 4 月までサポートされます。Ansible-2.3 は 2017 年 4 月にリリースされ、モジュールサイドの Python 2.4 をサポートする最後の Ansible リリースでした。" - -#~ msgid "Testing modules on Python 3" -#~ msgstr "Python 3 でのモジュールのテスト" - -#~ msgid "Ansible modules are slightly harder to code to support Python 3 than normal code from other projects. A lot of mocking has to go into unit testing an Ansible module, so it's harder to test that your changes have fixed everything or to to make sure that later commits haven't regressed the Python 3 support. Review our :ref:`testing ` pages for more information." -#~ msgstr "Ansible モジュールは、その他のプロジェクトの通常のコードよりも Python 3 をサポートするようにコーディングするのが若干難しくなります。多くのモックは、Ansible モジュールのユニットテストに入る必要があるため、変更によってすべてが修正されたことをテストするか、後のコミットが Python 3 をサポートしないようにする方が困難になります。詳細は、:ref:`テスト ` ページを参照してください。" - -#~ msgid "an :ref:`Amazon module `." -#~ msgstr ":ref:`Amazon モジュール `" - -#~ msgid "a :ref:`VMware module `." -#~ msgstr ":ref:`VMware モジュール `" - -#~ msgid "If a module matures, we will remove the 'preview' mark in the documentation. We support (though we cannot guarantee) backwards compatibility for these modules, which means their parameters should be maintained with stable meanings." -#~ msgstr "モジュールが成熟すると、ドキュメントの「プレビュー」マークが削除されます。これらのモジュールに対する後方互換性はサポートします (が保証はしません)。つまり、パラメーターは安定した方法で維持する必要があります。" - -#~ msgid "When a module has been deprecated for four release cycles, we remove the code and mark the stub file removed. Modules that are removed are no longer shipped with Ansible. The stub file helps users find alternative modules." -#~ msgstr "4 つのリリースサイクルでモジュールが非推奨になったら、コードを削除し、stab ファイルに removed と表示します。削除されたモジュールは、Ansible に同梱されなくなります。stab ファイルは、ユーザーが代替モジュールを見つけるのに役立ちます。" - -#~ msgid "Deprecating modules" -#~ msgstr "モジュールの非推奨化" - -#~ msgid "Mention the deprecation in the relevant ``CHANGELOG``." -#~ msgstr "関連する ``CHANGELOG`` の非推奨に言及してください。" - -#~ msgid "note: with the advent of collections and ``routing.yml`` we might soon require another entry in this file to mark the deprecation." -#~ msgstr "注記: コレクションおよび ``routing.yml`` では、非推奨となったマークにこのファイル内の別のエントリーがすぐに必要になることがあります。" - -#~ msgid "Changing a module name" -#~ msgstr "モジュール名の変更" - -#~ msgid "The Ansible AWS collection (on `Galaxy `_, source code `repository `_) is maintained by the Ansible AWS Working Group. For further information see the `AWS working group community page `_. If you are planning to contribute AWS modules to Ansible then getting in touch with the working group is a good way to start, especially because a similar module may already be under development." -#~ msgstr "Ansible AWS コレクション (`Galaxy `_ では、ソースコード `レポジトリー `_) は、Ansible AWS のワーキンググループ維持されます。詳細は `AWS ワーキンググループのコミュニティーページ `_ を参照してください。AWS モジュールを Ansible に提供することを計画している場合は、特に同様のモジュールがすでに開発中である可能性があるため、ワーキンググループに連絡することから始めることを推奨します。" - -#~ msgid "Maintaining existing modules" -#~ msgstr "既存のモジュールのメンテナンス" - -#~ msgid "Fixing bugs" -#~ msgstr "バグの修正" - -#~ msgid "Bug fixes to code that relies on boto will still be accepted. When possible, the code should be ported to use boto3." -#~ msgstr "boto に依存するコードに対するバグ修正は引き続き承認されます。可能であれば、このコードは、boto3 を使用するように移植する必要があります。" - -#~ msgid "Adding new features" -#~ msgstr "新しい機能の追加" - -#~ msgid "Try to keep backward compatibility with relatively recent versions of boto3. That means that if you want to implement some functionality that uses a new feature of boto3, it should only fail if that feature actually needs to be run, with a message stating the missing feature and minimum required version of boto3." -#~ msgstr "比較的最近のバージョンの boto3 との下位互換性を保つようにしてください。つまり、boto3 の新機能を使用する一部の機能を実装する場合は、その機能を実際に実行する必要がある場合にのみ失敗し、欠落している機能と最低限必要な boto3 のバージョンを示すメッセージが表示されます。" - -#~ msgid "Use feature testing (for example, ``hasattr('boto3.module', 'shiny_new_method')``) to check whether boto3 supports a feature rather than version checking. For example, from the ``ec2`` module:" -#~ msgstr "機能テスト (例: ``hasattr('boto3.module', 'shiny_new_method')``) を使用して、boto3 がバージョンチェックではなく機能をサポートしているかどうかを確認します。たとえば、``ec2`` モジュールからです。" - -#~ msgid "Migrating to boto3" -#~ msgstr "boto3 への移行" - -#~ msgid "Prior to Ansible 2.0, modules were written in either boto3 or boto. We are still porting some modules to boto3. Modules that still require boto should be ported to use boto3 rather than using both libraries (boto and boto3). We would like to remove the boto dependency from all modules." -#~ msgstr "Ansible 2.0 より前、モジュールは boto3 または boto のいずれかで記述されていました。まだ、いくつかのモジュールを boto3 に移植しています。それでもbotoが必要なモジュールは、両方のライブラリー (boto と boto3) を使用するのではなく、boto3 を使用するように移植する必要があります。すべてのモジュールから boto 依存関係を削除したいと考えています。" - -#~ msgid "Porting code to AnsibleAWSModule" -#~ msgstr "AnsibleAWSModule へのコードの移植" - -#~ msgid "Some old AWS modules use the generic ``AnsibleModule`` as a base rather than the more efficient ``AnsibleAWSModule``. To port an old module to ``AnsibleAWSModule``, change:" -#~ msgstr "一部の古い AWS モジュールは、より効率的な ``AnsibleAWSModule`` ではなく、汎用の ``AnsibleModule`` をベースとして使用します。古いモジュールを ``AnsibleAWSModule`` に移植するには、以下を変更します。" - -#~ msgid "to:" -#~ msgstr "以下のように変更します。" - -#~ msgid "Few other changes are required. AnsibleAWSModule does not inherit methods from AnsibleModule by default, but most useful methods are included. If you do find an issue, please raise a bug report." -#~ msgstr "その他の変更が必要になります。AnsibleAWSModule はデフォルトで AnsibleModule のメソッドを継承しませんが、最も便利なメソッドが含まれています。問題を発見した場合は、バグレポートを提出してください。" - -#~ msgid "When porting, keep in mind that AnsibleAWSModule also will add the default ec2 argument spec by default. In pre-port modules, you should see common arguments specified with:" -#~ msgstr "ポート時には、AnsibleAWSModule はデフォルトでデフォルトの ec2 引数仕様も追加します。事前ポートモジュールでは、以下で指定された一般的な引数が表示されるはずです。" - -#~ msgid "These can be replaced with:" -#~ msgstr "これは、次のものと置き換えることができます。" - -#~ msgid "Creating new AWS modules" -#~ msgstr "新規 AWS モジュールの作成" - -#~ msgid "Use boto3 and AnsibleAWSModule" -#~ msgstr "boto3 および AnsibleAWSModule の使用" - -#~ msgid "All new AWS modules must use boto3 and ``AnsibleAWSModule``." -#~ msgstr "すべての新規 AWS モジュールは boto3 および ``AnsibleAWSModule`` を使用する必要があります。" - -#~ msgid "``AnsibleAWSModule`` greatly simplifies exception handling and library management, reducing the amount of boilerplate code. If you cannot use ``AnsibleAWSModule`` as a base, you must document the reason and request an exception to this rule." -#~ msgstr "``AnsibleAWSModule`` は、例外処理とライブラリー管理を大幅に簡素化し、ボイラープレートコードの量を削減します。``AnsibleAWSModule`` をベースとして使えない場合は、理由を文書化し、このルールの例外を要求する必要があります。" - -#~ msgid "Naming your module" -#~ msgstr "モジュールの名前付け" - -#~ msgid "Base the name of the module on the part of AWS that you actually use. (A good rule of thumb is to take whatever module you use with boto as a starting point). Don't further abbreviate names - if something is a well known abbreviation of a major component of AWS (for example, VPC or ELB), that's fine, but don't create new ones independently." -#~ msgstr "実際に使用する AWS の一部であるモジュール名をベースにします (経験則として、boto で使用するモジュールを開始点として使用することが推奨されます)。名前をさらに省略しないでください。AWS の主要コンポーネント (VPC や ELB など) のよく知られた省略形である場合は問題ありませんが、新しい名前を個別に作成しないでください。" - -#~ msgid "Unless the name of your service is quite unique, please consider using ``aws_`` as a prefix. For example ``aws_lambda``." -#~ msgstr "サービスの名前が非常に一意でない限り、``aws_`` を接頭辞として使用することを検討してください。たとえば、``aws_lambda`` となります。" - -#~ msgid "Importing botocore and boto3" -#~ msgstr "botocore および boto3 のインポート" - -#~ msgid "The ``ansible.module_utils.ec2`` module and ``ansible.module_utils.core.aws`` modules both automatically import boto3 and botocore. If boto3 is missing from the system then the variable ``HAS_BOTO3`` will be set to false. Normally, this means that modules don't need to import boto3 directly. There is no need to check ``HAS_BOTO3`` when using AnsibleAWSModule as the module does that check:" -#~ msgstr "``ansible.module_utils.ec2`` モジュールと ``ansible.module_utils.core.aws`` モジュールは、boto3 と botocore を自動的にインポートします。 システムに boto3 がない場合は、変数 ``HAS_BOTO3`` が false に設定されます。通常、これは、boto3 を直接インポートする必要はありません。モジュールの確認が行われる際に AnsibleAWSModule を使用する場合は、``HAS_BOTO3`` を確認する必要はありません。" - -#~ msgid "or:" -#~ msgstr "または" - -#~ msgid "Supporting Module Defaults" -#~ msgstr "モジュールのデフォルトのサポート" - -#~ msgid "The existing AWS modules support using :ref:`module_defaults ` for common authentication parameters. To do the same for your new module, add an entry for it in ``lib/ansible/config/module_defaults.yml``. These entries take the form of:" -#~ msgstr "既存の AWS モジュールは、共通の認証パラメーターに :ref:`module_defaults ` を使用したサポートです。新しいモジュールに同じモジュールを行うには、``lib/ansible/config/module_defaults.yml`` でエントリーを追加します。これらのエントリーは以下の形式になります。" - -#~ msgid "Connecting to AWS" -#~ msgstr "AWS への接続" - -#~ msgid "AnsibleAWSModule provides the ``resource`` and ``client`` helper methods for obtaining boto3 connections. These handle some of the more esoteric connection options, such as security tokens and boto profiles." -#~ msgstr "AnsibleAWSModule は、boto3 接続を取得するためのヘルパーメソッド ``resource`` および ``client`` を提供します。これらは、セキュリティートークンや boto プロファイルなど、より難解な接続オプションのいくつかを処理します。" - -#~ msgid "If using the basic AnsibleModule then you should use ``get_aws_connection_info`` and then ``boto3_conn`` to connect to AWS as these handle the same range of connection options." -#~ msgstr "接続オプションと同じ範囲を処理するため、基本的な AnsibleModule を使用する場合は、``get_aws_connection_info`` を使用してから ``boto3_conn`` を使用して AWS に接続する必要があります。" - -#~ msgid "These helpers also for missing profiles or a region not set when it needs to be, so you don't have to." -#~ msgstr "これらのヘルパーは、欠落しているプロファイルや、必要なときに設定されていない領域にも使用できるため、必須ではありません。" - -#~ msgid "An example of connecting to ec2 is shown below. Note that unlike boto there is no ``NoAuthHandlerFound`` exception handling like in boto. Instead, an ``AuthFailure`` exception will be thrown when you use the connection. To ensure that authorization, parameter validation and permissions errors are all caught, you should catch ``ClientError`` and ``BotoCoreError`` exceptions with every boto3 connection call. See exception handling:" -#~ msgstr "ec2 への接続例は以下のようになります。boto とは異なり、boto には、``NoAuthHandlerFound`` の例外処理がないことに注意してください。代わりに、接続の使用時に ``AuthFailure`` 例外がスローされます。承認、パラメーター検証およびパーミッションエラーがすべてキャッチされるようにするには、すべての boto3 接続呼び出しで ``ClientError`` および ``BotoCoreError`` の例外をキャッチする必要があります。「例外処理」を参照してください。" - -#~ msgid "or for the higher level ec2 resource:" -#~ msgstr "また、より高いレベルの ec2 リソースの場合は、次のようになります。" - -#~ msgid "An example of the older style connection used for modules based on AnsibleModule rather than AnsibleAWSModule:" -#~ msgstr "AnsibleAWSModule ではなく AnsibleModule に基づくモジュールに使用される旧式の接続例は次のとおりです。" - -#~ msgid "Common Documentation Fragments for Connection Parameters" -#~ msgstr "接続パラメーターに関する断片化された汎用ドキュメント" - -#~ msgid "There are two :ref:`common documentation fragments ` that should be included into almost all AWS modules:" -#~ msgstr "ほとんどすべての AWS モジュールに含まれる :ref:`断片化された汎用ドキュメント ` は 2 つあります。" - -#~ msgid "``aws`` - contains the common boto connection parameters" -#~ msgstr "``aws`` - 共通の boto 接続パラメーターが含まれます。" - -#~ msgid "``ec2`` - contains the common region parameter required for many AWS modules" -#~ msgstr "``ec2`` - 数多くの AWS モジュールに必要な共通の region パラメーターが含まれます。" - -#~ msgid "These fragments should be used rather than re-documenting these properties to ensure consistency and that the more esoteric connection options are documented. For example:" -#~ msgstr "一貫性を確保し、より難解な接続オプションを文書化するには、このようなプロパティーを再文書化するのではなく、このような断片化されたドキュメントを使用する必要があります。たとえば、以下のようになります。" - -#~ msgid "Handling exceptions" -#~ msgstr "例外の処理" - -#~ msgid "You should wrap any boto3 or botocore call in a try block. If an exception is thrown, then there are a number of possibilities for handling it." -#~ msgstr "try ブロックで boto3 または botocore 呼び出しをラップする必要があります。例外がスローされると、処理の可能性が多数あります。" - -#~ msgid "Catch the general ``ClientError`` or look for a specific error code with" -#~ msgstr "汎用的な ``ClientError`` を取得するか、次のような特定のエラーコードを探します" - -#~ msgid "``is_boto3_error_code``." -#~ msgstr "``is_boto3_error_code``." - -#~ msgid "Use ``aws_module.fail_json_aws()`` to report the module failure in a standard way" -#~ msgstr "``aws_module.fail_json_aws()`` を使用して、標準的な方法でモジュール障害を報告します。" - -#~ msgid "Retry using AWSRetry" -#~ msgstr "AWSRetry を使用して再試行します。" - -#~ msgid "Use ``fail_json()`` to report the failure without using ``ansible.module_utils.aws.core``" -#~ msgstr "``fail_json()`` を使用して、``ansible.module_utils.aws.core`` を使用せずに障害を報告します。" - -#~ msgid "Do something custom in the case where you know how to handle the exception" -#~ msgstr "例外の処理方法が分かっている場合は、何らかのカスタマイズ作業を行います。" - -#~ msgid "For more information on botocore exception handling see the `botocore error documentation `_." -#~ msgstr "botocore 例外処理の詳細は、`botocore エラードキュメント `_ を参照してください。" - -#~ msgid "Using is_boto3_error_code" -#~ msgstr "is_boto3_error_code の使用" - -#~ msgid "To use ``ansible.module_utils.aws.core.is_boto3_error_code`` to catch a single AWS error code, call it in place of ``ClientError`` in your except clauses. In this case, *only* the ``InvalidGroup.NotFound`` error code will be caught here, and any other error will be raised for handling elsewhere in the program." -#~ msgstr "``ansible.module_utils.aws.core.is_boto3_error_code`` を使用して単一の AWS エラーコードを取得するには、except 句で ``ClientError`` の代わりに呼び出しを行います。この場合、``InvalidGroup.NotFound`` エラーコードをここに検出し、その他のエラーでプログラム内の別の場所を処理する際に発生します。" - -#~ msgid "Using fail_json_aws()" -#~ msgstr "fail_json_aws() の使用" - -#~ msgid "In the AnsibleAWSModule there is a special method, ``module.fail_json_aws()`` for nice reporting of exceptions. Call this on your exception and it will report the error together with a traceback for use in Ansible verbose mode." -#~ msgstr "AnsibleAWSModule には、例外レポートに優れた方法 ``module.fail_json_aws()`` があります。例外上でこの呼び出しを行い、Ansible の冗長モードで使用するためにトレースバックと共にエラーを報告します。" - -#~ msgid "You should use the AnsibleAWSModule for all new modules, unless not possible. If adding significant amounts of exception handling to existing modules, we recommend migrating the module to use AnsibleAWSModule (there are very few changes required to do this)" -#~ msgstr "不可能でない限り、すべての新しいモジュールに AnsibleAWSModule を使用する必要があります。既存のモジュールに大量の例外処理を追加する場合は、AnsibleAWSModule を使用するようにモジュールを移行することが推奨されます (これを行うために必要な変更はほとんどありません)。" - -#~ msgid "Note that it should normally be acceptable to catch all normal exceptions here, however if you expect anything other than botocore exceptions you should test everything works as expected." -#~ msgstr "通常、ここですべての通常の例外を捕えても問題がないことに注意してください。ただし、botocore 以外の例外が予想される場合は、すべてが期待どおりに機能するかどうかをテストする必要があります。" - -#~ msgid "If you need to perform an action based on the error boto3 returned, use the error code." -#~ msgstr "返された boto3 エラーに基づいてアクションを実行する必要がある場合は、このエラーコードを使用します。" - -#~ msgid "using fail_json() and avoiding ansible.module_utils.aws.core" -#~ msgstr "fail_json() and avoiding ansible.module_utils.aws.core の使用" - -#~ msgid "Boto3 provides lots of useful information when an exception is thrown so pass this to the user along with the message." -#~ msgstr "Boto3 は、例外が発生したときに多くの有用な情報を提供するため、メッセージと共にこれをユーザーに渡します。" - -#~ msgid "Note: we use `str(e)` rather than `e.message` as the latter doesn't work with python3" -#~ msgstr "注記: 後者は python3 では機能しないため、`e.message` の代わりに `str(e)` を使用します。" - -#~ msgid "API throttling (rate limiting) and pagination" -#~ msgstr "API スロットリング (レート制限) とページネーション" - -#~ msgid "For methods that return a lot of results, boto3 often provides `paginators `_. If the method you're calling has ``NextToken`` or ``Marker`` parameters, you should probably check whether a paginator exists (the top of each boto3 service reference page has a link to Paginators, if the service has any). To use paginators, obtain a paginator object, call ``paginator.paginate`` with the appropriate arguments and then call ``build_full_result``." -#~ msgstr "大量の結果を返すメソッドの場合、boto3 はしばしば `paginators `_ を提供します。呼び出しているメソッドに ``NextToken`` パラメーターまたは ``Marker`` パラメーターがある場合は、Paginator が存在するかどうかを確認する必要があります (各 boto3 サービスに paginator がある場合は、参照ページ上部に Paginator へのリンクがあります)。paginator を使用するには、paginator オブジェクトを取得し、適切な引数を指定して ``paginator.paginate`` を呼び出してから、``build_full_result`` を呼び出します。" - -#~ msgid "Any time that you are calling the AWS API a lot, you may experience API throttling, and there is an ``AWSRetry`` decorator that can be used to ensure backoff. Because exception handling could interfere with the retry working properly (as AWSRetry needs to catch throttling exceptions to work correctly), you'd need to provide a backoff function and then put exception handling around the backoff function." -#~ msgstr "AWS API を大量に呼び出しているのはいつでも、API スロットリングが発生する可能性があり、バックオフ機能を提供するために使用できる ``AWSRetry`` デコレーターがあります。例外処理は再試行が正しく機能するのを妨げる可能性があるため (AWSRetry が正しく機能するためにスロットリング例外を取得する必要があるため)、バックオフ関数を提供してから、バックオフ関数の周りに例外処理を配置する必要があります。" - -#~ msgid "You can use ``exponential_backoff`` or ``jittered_backoff`` strategies - see the cloud ``module_utils`` ()/lib/ansible/module_utils/cloud.py) and `AWS Architecture blog `_ for more details." -#~ msgstr "``exponential_backoff`` または ``jittered_backoff`` ストラテジーを使用できます。詳細は、クラウド ``module_utils`` ()/lib/ansible/module_utils/cloud.py) および `AWS アーキテクチャーのブログ `_ を参照してください。" - -#~ msgid "The combination of these two approaches is then:" -#~ msgstr "これら 2 つのアプローチの組み合わせは次のとおりです。" - -#~ msgid "If the underlying ``describe_some_resources`` API call throws a ``ResourceNotFound`` exception, ``AWSRetry`` takes this as a cue to retry until it's not thrown (this is so that when creating a resource, we can just retry until it exists)." -#~ msgstr "基礎となる ``describe_some_resources`` API 呼び出しで ``ResourceNotFound`` 例外を出力すると、``AWSRetry`` はこれが出力されなくなるまで再試行する合図としてこれを受け取ります (これは、リソースを作成するときに、リソースが存在するまで再試行できるようにするためです)。" - -#~ msgid "To handle authorization failures or parameter validation errors in ``describe_some_resource_with_backoff``, where we just want to return ``None`` if the resource doesn't exist and not retry, we need:" -#~ msgstr "リソースが存在しない場合、およびリソースが再試行されていない場合のみ ``None`` を返す ``describe_some_resource_with_backoff`` で承認の失敗またはパラメーター検証エラーを処理するには、以下が必要になります。" - -#~ msgid "To make use of AWSRetry easier, it can now be wrapped around a client returned by ``AnsibleAWSModule``. any call from a client. To add retries to a client, create a client:" -#~ msgstr "AWSRetry を使いやすくするために、``AnsibleAWSModule`` (クライアントからの呼び出し) によって返されたクライアントをラップできるようになりました。クライアントに再試行を追加するには、クライアントを作成します。" - -#~ msgid "Any calls from that client can be made to use the decorator passed at call-time using the `aws_retry` argument. By default, no retries are used." -#~ msgstr "そのクライアントからの呼び出しはすべて、`aws_retry` 引数を使用して呼び出し時に渡されたデコレーターを使用して行うことができます。デフォルトでは、再試行は使用されません。" - -#~ msgid "The call will be retried the specified number of times, so the calling functions don't need to be wrapped in the backoff decorator." -#~ msgstr "呼び出しは指定された回数だけ再試行されるため、呼び出し元の関数をバックオフデコレーターでラップする必要はありません。" - -#~ msgid "You can also use customization for ``retries``, ``delay`` and ``max_delay`` parameters used by ``AWSRetry.jittered_backoff`` API using module params. You can take a look at the `cloudformation ` module for example." -#~ msgstr "また、モジュールパラメーターを使用して、``AWSRetry.jittered_backoff`` API が使用する ``retries`` パラメーター、``delay`` パラメーター、および ``max_delay`` パラメーターのカスタマイズを使用することもできます。たとえば、`cloudformation ` モジュールを参照してください。" - -#~ msgid "To make all Amazon modules uniform, prefix the module param with ``backoff_``, so ``retries`` becomes ``backoff_retries``" -#~ msgstr "すべての Amazon モジュールを均一にするには、モジュールパラメーターの前に ``backoff_`` を付けます。これにより、``retries`` は ``backoff_retries`` になります。" - -#~ msgid "and likewise with ``backoff_delay`` and ``backoff_max_delay``." -#~ msgstr "``backoff_delay`` と ``backoff_max_delay`` も同様です。" - -#~ msgid "Returning Values" -#~ msgstr "戻り値" - -#~ msgid "When you make a call using boto3, you will probably get back some useful information that you should return in the module. As well as information related to the call itself, you will also have some response metadata. It is OK to return this to the user as well as they may find it useful." -#~ msgstr "boto3 を使用して呼び出しを行うと、モジュールで返す必要がある便利な情報を入手できます。また、呼び出し自体に関連する情報や応答メタデータもあります。これをユーザーに返すことは問題ありませんが、ユーザーはそれが役立つと思うかもしれません。" - -#~ msgid "Boto3 returns all values CamelCased. Ansible follows Python standards for variable names and uses snake_case. There is a helper function in module_utils/ec2.py called `camel_dict_to_snake_dict` that allows you to easily convert the boto3 response to snake_case." -#~ msgstr "boto3 は、キャメルケース化したすべての値を返します。Ansible は変数名の Python 標準に従い、snake_case を使用します。`camel_dict_to_snake_dict` という名前の module_utils/ec2.py にヘルパー関数があり、boto3 を簡単に snake_case に変換できます。" - -#~ msgid "You should use this helper function and avoid changing the names of values returned by Boto3. E.g. if boto3 returns a value called 'SecretAccessKey' do not change it to 'AccessKey'." -#~ msgstr "このヘルパー関数を使用し、Boto3 が返す値の名前を変更しないでください。たとえば、boto3 が「SecretAccessKey」値を返す場合は、これを「AccessKey」に変更しないでください。" - -#~ msgid "Dealing with IAM JSON policy" -#~ msgstr "IAM JSON ポリシーの処理" - -#~ msgid "If your module accepts IAM JSON policies then set the type to 'json' in the module spec. For example:" -#~ msgstr "モジュールが IAM JSON ポリシーを受け入れる場合は、モジュール仕様でタイプを「json」に設定します。たとえば、以下のようになります。" - -#~ msgid "Note that AWS is unlikely to return the policy in the same order that is was submitted. Therefore, use the `compare_policies` helper function which handles this variance." -#~ msgstr "AWS が、送信された順序でポリシーを返すことはほとんどありません。したがって、この差異を処理する `compare_policies` ヘルパー関数を使用します。" - -#~ msgid "`compare_policies` takes two dictionaries, recursively sorts and makes them hashable for comparison and returns True if they are different." -#~ msgstr "`compare_policies` は、2 つのディクショナリーを取得し、再帰的にソートし、比較のためにハッシュを可能にし、異なる場合は True を返します。" - -#~ msgid "Dealing with tags" -#~ msgstr "タグの処理" - -#~ msgid "AWS has a concept of resource tags. Usually the boto3 API has separate calls for tagging and untagging a resource. For example, the ec2 API has a create_tags and delete_tags call." -#~ msgstr "AWS にはリソースタグの概念があります。通常、boto3 API には、リソースのタグ付けとタグ付け解除のための呼び出しがあります。たとえば、ec2 API には create_tags および delete_tags の呼び出しがあります。" - -#~ msgid "It is common practice in Ansible AWS modules to have a `purge_tags` parameter that defaults to true." -#~ msgstr "これは、デフォルトが true の `purge_tags` パラメーターがある Ansible AWS モジュールでは一般的な方法です。" - -#~ msgid "The `purge_tags` parameter means that existing tags will be deleted if they are not specified by the Ansible task." -#~ msgstr "`purge_tags` パラメーターは、既存のタグが Ansible タスクで指定されていない場合に削除されることを示しています。" - -#~ msgid "There is a helper function `compare_aws_tags` to ease dealing with tags. It can compare two dicts and return the tags to set and the tags to delete. See the Helper function section below for more detail." -#~ msgstr "タグの扱いを容易にするためヘルパー機能 `compare_aws_tags` があります。2 つのディクショナリーを比較し、設定するタグと削除するタグを返すことができます。詳細については、以下のヘルパー関数のセクションを参照してください。" - -#~ msgid "Helper functions" -#~ msgstr "helper 関数" - -#~ msgid "Along with the connection functions in Ansible ec2.py module_utils, there are some other useful functions detailed below." -#~ msgstr "Ansible ec2.py module_utils の接続関数に加えて、以下に説明するいくつかの便利な関数があります。" - -#~ msgid "camel_dict_to_snake_dict" -#~ msgstr "camel_dict_to_snake_dict" - -#~ msgid "boto3 returns results in a dict. The keys of the dict are in CamelCase format. In keeping with Ansible format, this function will convert the keys to snake_case." -#~ msgstr "boto3 はディクショナリーの結果を返します。ディクショナリーのキーは CamelCase 形式になります。Ansible 形式を維持すると、この機能はキーを snake_case に変換します。" - -#~ msgid "``camel_dict_to_snake_dict`` takes an optional parameter called ``ignore_list`` which is a list of keys not to convert (this is usually useful for the ``tags`` dict, whose child keys should remain with case preserved)" -#~ msgstr "``camel_dict_to_snake_dict`` は、``ignore_list`` 呼ばれる任意のパラメーターを取ります。これは、変換しないキーの一覧です。これは通常、``tags`` ディクショナリーに役に立ちます。この子キーは大文字と小文字を区別して保持する必要があります。" - -#~ msgid "Another optional parameter is ``reversible``. By default, ``HTTPEndpoint`` is converted to ``http_endpoint``, which would then be converted by ``snake_dict_to_camel_dict`` to ``HttpEndpoint``. Passing ``reversible=True`` converts HTTPEndpoint to ``h_t_t_p_endpoint`` which converts back to ``HTTPEndpoint``." -#~ msgstr "その他の任意のパラメーターは ``reversible`` です。デフォルトでは、``HTTPEndpoint`` は ``http_endpoint`` に変換されます。これは、``snake_dict_to_camel_dict`` によって ``HttpEndpoint`` に変換されます。``reversible=True`` を渡すと、HTTPEndpoint が ``h_t_t_p_endpoint`` に変換され、``HTTPEndpoint`` に変換され直されます。" - -#~ msgid "snake_dict_to_camel_dict" -#~ msgstr "snake_dict_to_camel_dict" - -#~ msgid "`snake_dict_to_camel_dict` converts snake cased keys to camel case. By default, because it was first introduced for ECS purposes, this converts to dromedaryCase. An optional parameter called `capitalize_first`, which defaults to `False`, can be used to convert to CamelCase." -#~ msgstr "`snake_dict_to_camel_dict` は、スネークケースのキーをキャメルケースに変換します。デフォルトでは、ECS の目的で最初に導入されたため、これは dromedaryCase に変換されます。`capitalize_first` と呼ばれる任意のパラメーターは、`False` にデフォルトされ、CamelCase への変換に使用できます。" - -#~ msgid "ansible_dict_to_boto3_filter_list" -#~ msgstr "ansible_dict_to_boto3_filter_list" - -#~ msgid "Converts a an Ansible list of filters to a boto3 friendly list of dicts. This is useful for any boto3 `_facts` modules." -#~ msgstr "フィルターの Ansible リストを、ディクショナリーの boto3 フレンドリーリストに変換します。これは、boto3 の `_facts` モジュールに役立ちます。" - -#~ msgid "boto_exception" -#~ msgstr "boto_exception" - -#~ msgid "Pass an exception returned from boto or boto3, and this function will consistently get the message from the exception." -#~ msgstr "boto または boto3 から返された例外を渡します。この関数は、例外からメッセージを一貫して取得します。" - -#~ msgid "Deprecated: use `AnsibleAWSModule`'s `fail_json_aws` instead." -#~ msgstr "非推奨: 代わりに `AnsibleAWSModule` の `fail_json_aws` を使用してください。" - -#~ msgid "boto3_tag_list_to_ansible_dict" -#~ msgstr "boto3_tag_list_to_ansible_dict" - -#~ msgid "Converts a boto3 tag list to an Ansible dict. Boto3 returns tags as a list of dicts containing keys called 'Key' and 'Value' by default. This key names can be overridden when calling the function. For example, if you have already camel_cased your list of tags you may want to pass lowercase key names instead, in other words, 'key' and 'value'." -#~ msgstr "boto3 タグリストを Ansible ディクショナリーに変換します。Boto3 は、「Key」および「Value」という名前のキーがデフォルトで含まれる ディクショナリーのリストとしてタグを返します。このキーは、関数を呼び出す際に上書きできます。たとえば、タグのリストをすでにキャメルケース化している場合は、代わりに小文字のキー名、つまり「key」と「value」を渡すことができます。" - -#~ msgid "This function converts the list in to a single dict where the dict key is the tag key and the dict value is the tag value." -#~ msgstr "この関数は、リストを単一のディクショナリーに変換します。dict キーはタグキーで、dict 値はタグの値です。" - -#~ msgid "ansible_dict_to_boto3_tag_list" -#~ msgstr "ansible_dict_to_boto3_tag_list" - -#~ msgid "Opposite of above. Converts an Ansible dict to a boto3 tag list of dicts. You can again override the key names used if 'Key' and 'Value' is not suitable." -#~ msgstr "上記の逆で、Ansible ディクショナリーをディクショナリーの boto3 タグ一覧に変換します。「Key」と「Value」が適していないときに使用されるキー名を再度上書きすることもできます。" - -#~ msgid "get_ec2_security_group_ids_from_names" -#~ msgstr "get_ec2_security_group_ids_from_names" - -#~ msgid "Pass this function a list of security group names or combination of security group names and IDs and this function will return a list of IDs. You should also pass the VPC ID if known because security group names are not necessarily unique across VPCs." -#~ msgstr "この関数にセキュリティーグループ名のリスト、またはセキュリティーグループ名とIDの組み合わせを渡すと、この関数は ID のリストを返します。セキュリティーグループ名は VPC 間で必ずしも一意であるとは限らないため、既知の場合は VPCID も渡す必要があります。" - -#~ msgid "compare_policies" -#~ msgstr "compare_policies" - -#~ msgid "Pass two dicts of policies to check if there are any meaningful differences and returns true if there are. This recursively sorts the dicts and makes them hashable before comparison." -#~ msgstr "ポリシーの 2 つのディクショナリーを渡して、意味のある差異があるかどうかを確認し、ある場合は true を返します。これにより、ディクショナリーが再帰的にソートされ、比較前にハッシュ可能になります。" - -#~ msgid "This method should be used any time policies are being compared so that a change in order doesn't result in unnecessary changes." -#~ msgstr "この方法は、順序を変更しても不要な変更が発生しないように、ポリシーを比較するときに必ず使用する必要があります。" - -#~ msgid "compare_aws_tags" -#~ msgstr "compare_aws_tags" - -#~ msgid "Pass two dicts of tags and an optional purge parameter and this function will return a dict containing key pairs you need to modify and a list of tag key names that you need to remove. Purge is True by default. If purge is False then any existing tags will not be modified." -#~ msgstr "タグの 2 つのディクショナリーと任意の purge パラメーターを渡します。この関数はディクショナリーを返します。これには、変更するキーペアと、削除する必要のあるタグキー名の一覧が含まれています。パージは、デフォルトで True です。パージが False の場合は、既存のタグが変更されません。" - -#~ msgid "This function is useful when using boto3 'add_tags' and 'remove_tags' functions. Be sure to use the other helper function `boto3_tag_list_to_ansible_dict` to get an appropriate tag dict before calling this function. Since the AWS APIs are not uniform (for example, EC2 is different from Lambda) this will work without modification for some (Lambda) and others may need modification before using these values (such as EC2, with requires the tags to unset to be in the form `[{'Key': key1}, {'Key': key2}]`)." -#~ msgstr "この関数は、boto3 の「add_tags」関数および「remove_tags」関数を使用する場合に役に立ちます。この関数を呼び出す前に、必ず他のヘルパー関数 `boto3_tag_list_to_ansible_dict` を使用して、適切なタグのディクショナリーを取得してください。AWS の API は統一されていないため (たとえば、EC2 と Lambda は異なる)、一部 (Lambda) では修正なしで動作しますが、他ではこれらの値を使用する前に修正が必要な場合があります(EC2 では、設定解除するタグを `[{'Key': key1}, {'Key': key2}]` の形式にする必要があるなど)。" - -#~ msgid "Integration Tests for AWS Modules" -#~ msgstr "AWS モジュールの統合テスト" - -#~ msgid "All new AWS modules should include integration tests to ensure that any changes in AWS APIs that affect the module are detected. At a minimum this should cover the key API calls and check the documented return values are present in the module result." -#~ msgstr "すべての新規 AWS モジュールには、モジュールに影響する AWS API の変更が検出されるように、統合テストを含める必要があります。最小値はキー API 呼び出しに対応し、文書化された戻り値がモジュールの結果に存在するようにする必要があります。" - -#~ msgid "For general information on running the integration tests see the :ref:`Integration Tests page of the Module Development Guide `, especially the section on configuration for cloud tests." -#~ msgstr "統合テストの実行に関する一般的な情報は、:ref:`モジュール開発ガイドの統合テストページ ` ページ (特に、クラウドテスト設定のセクション) を参照してください。" - -#~ msgid "The integration tests for your module should be added in `test/integration/targets/MODULE_NAME`." -#~ msgstr "モジュールの統合テストは、`test/integration/targets/MODULE_NAME` に追加する必要があります。" - -#~ msgid "You must also have a aliases file in `test/integration/targets/MODULE_NAME/aliases`. This file serves two purposes. First indicates it's in an AWS test causing the test framework to make AWS credentials available during the test run. Second putting the test in a test group causing it to be run in the continuous integration build." -#~ msgstr "また、`test/integration/targets/MODULE_NAME/aliases` にはエイリアスファイルが必要です。このファイルには 2 つの目的があります。最初に、それが AWS テストにあり、テストフレームワークがテスト実行中に AWS 認証情報を利用できるようにしていることを示します。次に、テストをテストグループに入れて、継続的インテグレーションビルドで実行します。" - -#~ msgid "Tests for new modules should be added to the same group as existing AWS tests. In general just copy an existing aliases file such as the `aws_s3 tests aliases file `_." -#~ msgstr "新規モジュールのテストは、既存の AWS テストと同じグループに追加する必要があります。一般に、`aws_s3 テストエイリアスファイル `_ のような既存のエイリアスファイルをコピーするだけです。" - -#~ msgid "AWS Credentials for Integration Tests" -#~ msgstr "統合テストの AWS 認証情報" - -#~ msgid "The testing framework handles running the test with appropriate AWS credentials, these are made available to your test in the following variables:" -#~ msgstr "テストフレームワークは、適切な AWS 認証情報を使用したテストの実行を処理します。この認証情報は、次の変数で、テストに利用できます。" - -#~ msgid "`aws_region`" -#~ msgstr "`aws_region`" - -#~ msgid "`aws_access_key`" -#~ msgstr "`aws_access_key`" - -#~ msgid "`aws_secret_key`" -#~ msgstr "`aws_secret_key`" - -#~ msgid "`security_token`" -#~ msgstr "`security_token`" - -#~ msgid "So all invocations of AWS modules in the test should set these parameters. To avoid duplicating these for every call, it's preferable to use :ref:`module_defaults `. For example:" -#~ msgstr "したがって、テストで AWS モジュールを呼び出す場合はすべて、これらのパラメーターを設定する必要があります。呼び出しごとにこれらが重複しないようにするには、:ref:`module_defaults ` を使用することが推奨されます。以下に例を示します。" - -#~ msgid "AWS Permissions for Integration Tests" -#~ msgstr "統合テスト用の AWS パーミッション" - -#~ msgid "As explained in the :ref:`Integration Test guide ` there are defined IAM policies in `mattclay/aws-terminator `_ that contain the necessary permissions to run the AWS integration test." -#~ msgstr ":ref:`Integration Test guide ` で説明されているように、AWS 統合テストを実行するために必要な権限が含まれる `mattclay/aws-terminator `_ で定義された IAM ポリシーがあります。" - -#~ msgid "If your module interacts with a new service or otherwise requires new permissions, tests will fail when you submit a pull request and the `Ansibullbot `_ will tag your PR as needing revision. We do not automatically grant additional permissions to the roles used by the continuous integration builds. You will need to raise a Pull Request against `mattclay/aws-terminator `_ to add them." -#~ msgstr "モジュールが新しいサービスとやり取りする場合、または別の方法で新しいパーミッションが必要な場合は、プル要求を送信すると、テストは失敗します。`Ansibullbot `_ は、PR に修正が必要なタグを付けます。継続的インテグレーションビルドで使用されるロールに追加のパーミッションを自動的に付与することはありません。それを追加するには、`mattclay/aws-terminator `_ に対してプル要求を発行する必要があります、それらを追加します。" - -#~ msgid "If your PR has test failures, check carefully to be certain the failure is only due to the missing permissions. If you've ruled out other sources of failure, add a comment with the `ready_for_review` tag and explain that it's due to missing permissions." -#~ msgstr "PR にテストの失敗がある場合は、失敗の原因がパーミッションの欠落のみであることをしっかりと確認してください。他の失敗の原因を除外した場合は、`ready_for_review` タグを使用してコメントを追加して、権限がないことが原因であることを説明します。" - -#~ msgid "Your pull request cannot be merged until the tests are passing. If your pull request is failing due to missing permissions, you must collect the minimum IAM permissions required to run the tests." -#~ msgstr "テストに合格するまでプル要求がマージできません。パーミッションがないためにプル要求が失敗すると、テストの実行に必要な最低限の IAM パーミッションを収集する必要があります。" - -#~ msgid "There are two ways to figure out which IAM permissions you need for your PR to pass:" -#~ msgstr "PR に合格するために必要な IAM パーミッションを確認する場合は、以下の 2 つの方法があります。" - -#~ msgid "Start with the most permissive IAM policy, run the tests to collect information about which resources your tests actually use, then construct a policy based on that output. This approach only works on modules that use `AnsibleAWSModule`." -#~ msgstr "最も許容度の高い IAM ポリシーから始めて、テストを実行し、テストが実際に使用するリソースに関する情報を収集し、その出力に基づいてポリシーを構築します。このアプローチは、`AnsibleAWSModule` を使用するモジュールでのみ機能します。" - -#~ msgid "Start with the least permissive IAM policy, run the tests to discover a failure, add permissions for the resource that addresses that failure, then repeat. If your module uses `AnsibleModule` instead of `AnsibleAWSModule`, you must use this approach." -#~ msgstr "最も許容度の低い IAM ポリシーから開始し、テストを実行して障害を検出し、その障害に対処するリソースのパーミッションを追加してから、繰り返します。モジュールが使用する場合は、`AnsibleAWSModule` の代わりに `AnsibleModule` を使用する場合は、このアプローチを使用する必要があります。" - -#~ msgid "To start with the most permissive IAM policy:" -#~ msgstr "最も許容度の高い IAM ポリシーを使用するには、以下を実行します。" - -#~ msgid "`Create an IAM policy `_ that allows all actions (set ``Action`` and ``Resource`` to ``*```)." -#~ msgstr "すべてのアクションを許可する `IAM ポリシーを作成 `_ します (``Action`` および ``Resource`` を ``*``' に設定)。" - -#~ msgid "Run your tests locally with this policy. On AnsibleAWSModule-based modules, the ``debug_botocore_endpoint_logs`` option is automatically set to ``yes``, so you should see a list of AWS ACTIONS after the PLAY RECAP showing all the permissions used. If your tests use a boto/AnsibleModule module, you must start with the least permissive policy (see below)." -#~ msgstr "このポリシーを使用して、ローカルでテストを実行します。AnsibleAWSModule ベースのモジュールでは、``debug_botocore_endpoint_logs`` オプションが自動的に ``yes`` に設定されます。したがって、PLAY RECAP の後に、使用されているすべてのパーミッションを示す AWSACTIONS のリストが表示されます。テストで boto/AnsibleModule モジュールを使用する場合は、最も許容度の低いポリシーから開始する必要があります (以下を参照)。" - -#~ msgid "Modify your policy to allow only the actions your tests use. Restrict account, region, and prefix where possible. Wait a few minutes for your policy to update." -#~ msgstr "テストで使用するアクションのみを許可するようにポリシーを変更します。可能な場合は、アカウント、地域、プレフィックスを制限してください。ポリシーが更新されるまで数分待ちます。" - -#~ msgid "Run the tests again with a user or role that allows only the new policy." -#~ msgstr "新規ポリシーのみを許可するユーザーまたはロールでテストを再実行します。" - -#~ msgid "If the tests fail, troubleshoot (see tips below), modify the policy, run the tests again, and repeat the process until the tests pass with a restrictive policy." -#~ msgstr "テストに失敗し、トラブルシューティング (以下のヒントを参照) を行い、ポリシーを変更し、テストを再実行し、制限的なポリシーでテストに合格するまでプロセスを繰り返します。" - -#~ msgid "Open a pull request proposing the minimum required policy to the `CI policies `_." -#~ msgstr "`CI policies `_ に対して最低限必要なポリシーを提案するプル要求を開きます。" - -#~ msgid "To start from the least permissive IAM policy:" -#~ msgstr "最も許容度の低い IAM ポリシーから開始するには、以下を実行します。" - -#~ msgid "Run the integration tests locally with no IAM permissions." -#~ msgstr "IAM パーミッションを持たないローカルの統合テストを実行します。" - -#~ msgid "Examine the error when the tests reach a failure." -#~ msgstr "テストが失敗した場合はエラーを確認します。" - -#~ msgid "If the error message indicates the action used in the request, add the action to your policy." -#~ msgstr "エラーメッセージがリクエストで使用されるアクションを示す場合は、アクションをポリシーに追加します。" - -#~ msgid "If the error message does not indicate the action used in the request:" -#~ msgstr "エラーメッセージがリクエストで使用されるアクションを示していない場合は、以下を行います。" - -#~ msgid "Usually the action is a CamelCase version of the method name - for example, for an ec2 client the method `describe_security_groups` correlates to the action `ec2:DescribeSecurityGroups`." -#~ msgstr "通常、アクションはメソッド名の CamelCase バージョンです。たとえば、ec2 クライアントの場合、`describe_security_groups` メソッドはアクション `ec2:DescribeSecurityGroups` に相関します。" - -#~ msgid "Refer to the documentation to identify the action." -#~ msgstr "アクションを特定するには、ドキュメントを参照してください。" - -#~ msgid "If the error message indicates the resource ARN used in the request, limit the action to that resource." -#~ msgstr "エラーメッセージが要求で使用されるリソース ARN を示す場合は、アクションをそのリソースに制限します。" - -#~ msgid "If the error message does not indicate the resource ARN used:" -#~ msgstr "エラーメッセージに、使用されたリソース ARN が示されない場合は、以下を行います。" - -#~ msgid "Determine if the action can be restricted to a resource by examining the documentation." -#~ msgstr "ドキュメントを参照して、アクションをリソースに制限できるかどうかを判断します。" - -#~ msgid "If the action can be restricted, use the documentation to construct the ARN and add it to the policy." -#~ msgstr "アクションが制限されている場合は、ドキュメントを使用して ARN を構築し、ポリシーに追加します。" - -#~ msgid "Add the action or resource that caused the failure to `an IAM policy `_. Wait a few minutes for your policy to update." -#~ msgstr "`IAM ポリシー `_ の失敗の原因となったアクションまたはリソースを追加します。ポリシーが更新まで数分待ちます。" - -#~ msgid "Run the tests again with this policy attached to your user or role." -#~ msgstr "ユーザーまたはロールにこのポリシーを割り当てテストを再実行します。" - -#~ msgid "If the tests still fail at the same place with the same error you will need to troubleshoot (see tips below). If the first test passes, repeat steps 2 and 3 for the next error. Repeat the process until the tests pass with a restrictive policy." -#~ msgstr "それでも同じ場所で同じエラーでテストが失敗する場合はは、トラブルシューティングを行う必要があります (以下のヒントを参照)。最初のテストに合格した場合は、次のエラーに対して手順 2 と 3 を繰り返します。制限付きポリシーでテストに合格するまで、このプロセスを繰り返します。" - -#~ msgid "Troubleshooting IAM policies" -#~ msgstr "IAM ポリシーのトラブルシューティング" - -#~ msgid "When you make changes to a policy, wait a few minutes for the policy to update before re-running the tests." -#~ msgstr "ポリシーに変更を加えたら、ポリシーが更新されるまで数分待ってからテストを再実行します。" - -#~ msgid "Use the `policy simulator `_ to verify that each action (limited by resource when applicable) in your policy is allowed." -#~ msgstr "`ポリシーシミュレーター `_ を使用して、ポリシー内の (該当する場合はリソースによって制限されている) が許可されていることを確認します。" - -#~ msgid "If you're restricting actions to certain resources, replace resources temporarily with `*`. If the tests pass with wildcard resources, there is a problem with the resource definition in your policy." -#~ msgstr "特定のリソースにアクションを制限する場合は、リソースを一時的に `*` に置き換えます。ワイルドカードリソースでテストに合格した場合は、ポリシーのリソース定義に問題があります。" - -#~ msgid "If the initial troubleshooting above doesn't provide any more insight, AWS may be using additional undisclosed resources and actions." -#~ msgstr "上記の最初のトラブルシューティングでより多くの洞察が得られない場合、AWS は追加の未公開のリソースおよびアクションを使用している可能性があります。" - -#~ msgid "Examine the AWS FullAccess policy for the service for clues." -#~ msgstr "手がかりについては、サービスの AWS FullAccess ポリシーを調べます。" - -#~ msgid "Re-read the AWS documentation, especially the list of `Actions, Resources and Condition Keys `_ for the various AWS services." -#~ msgstr "各種の AWS サービスの `Actions, Resources and Condition Keys `_ の一覧など、AWS ドキュメントを再度読みます。" - -#~ msgid "Look at the `cloudonaut `_ documentation as a troubleshooting cross-reference." -#~ msgstr "トラブルシューティングの相互参照として `cloudonaut `_ ドキュメントをご覧ください。" - -#~ msgid "Use a search engine." -#~ msgstr "検索エンジンを使用します。" - -#~ msgid "Ask in the Ansible IRC channel #ansible-aws (on freenode IRC)." -#~ msgstr "Freenode IRC の Ansible IRC チャンネル #ansible-aws に問い合わせます。" - -#~ msgid "Unsupported Integration tests" -#~ msgstr "サポートされないインテグレーションのテスト" - -#~ msgid "There are a limited number of reasons why it may not be practical to run integration tests for a module within CI. Where these apply you should add the keyword `unsupported` to the aliases file in `test/integration/targets/MODULE_NAME/aliases`." -#~ msgstr "CI 内のモジュールの統合テストを実行する場合には、いくつかの理由が限定されている理由があります。これらの理由については、キーワード `unsupported` を `test/integration/targets/MODULE_NAME/aliases` のエイリアスファイルに追加する必要があります。" - -#~ msgid "Some cases where tests should be marked as unsupported: 1) The tests take longer than 10 or 15 minutes to complete 2) The tests create expensive resources 3) The tests create inline policies 4) The tests require the existence of external resources 5) The tests manage Account level security policies such as the password policy or AWS Organizations." -#~ msgstr "テストがサポート対象外としてマークされる必要がある場合があります。1) テストが完了するまで 10 分または 15 分以上かかります。2) テストにより、高価なリソースが作成されます。3) テストにより、インラインポリシーが作成されます。4) テストに外部リソースの存在が必要になります。5) テストは、パスワードポリシーや AWS 組織などのアカウントレベルのセキュリティポリシーを管理します。" - -#~ msgid "Where one of these reasons apply you should open a pull request proposing the minimum required policy to the `unsupported test policies `_." -#~ msgstr "上記の理由の 1 つは、`サポートされないテストポリシー `_ に対して最低限必要なポリシーを提案するプル要求を開きます。" - -#~ msgid "Unsupported integration tests will not be automatically run by CI. However, the necessary policies should be available so that the tests can be manually run by someone performing a PR review or writing a patch." -#~ msgstr "サポート対象外の統合テストは CI によって自動的に実行されませんが、必要なポリシーを利用すると、PR レビューまたはパッチの作成を実行してテストを手動で実行できるようにする必要があります。" - -#~ msgid "The set of modules for interacting with oVirt/RHV are currently part of the community.general collection (on `Galaxy `_, source code `repository `_). This document serves as developer coding guidelines for creating oVirt/RHV modules." -#~ msgstr "oVirt/RHV との対話に使用するモジュールセットは、現在 community.general コレクション (`Galaxy `_ ではソースコード `repository `_) に含まれます。このドキュメントは、oVirt/RHV モジュールを作成するための開発者コーディングのガイドラインとして機能します。" - -#~ msgid "All modules should start with an ``ovirt_`` prefix." -#~ msgstr "すべてのモジュールは、``ovirt_`` 接頭辞で開始する必要があります。" - -#~ msgid "All modules should be named after the resource it manages in singular form." -#~ msgstr "すべてのモジュールは、管理するリソースにちなんで単数形で名前を付ける必要があります。" - -#~ msgid "All modules that gather information should have a ``_info`` suffix." -#~ msgstr "情報を収集するすべてのモジュールには、``_info`` 構文があります。" - -#~ msgid "Interface" -#~ msgstr "インターフェース" - -#~ msgid "Every module should return the ID of the resource it manages." -#~ msgstr "すべてのモジュールは、管理するリソースの ID を返す必要があります。" - -#~ msgid "Every module should return the dictionary of the resource it manages." -#~ msgstr "すべてのモジュールは、管理するリソースのディレクトリーを返す必要があります。" - -#~ msgid "Never change the name of the parameter, as we guarantee backward compatibility. Use aliases instead." -#~ msgstr "後方互換性を保証するため、パラメーターの名前は変更しないでください。代わりにエイリアスを使用してください。" - -#~ msgid "If a parameter can't achieve idempotency for any reason, please document it." -#~ msgstr "パラメーターが何らかの理由で冪等性を実現できない場合は、それを文書化してください。" - -#~ msgid "Interoperability" -#~ msgstr "相互運用性" - -#~ msgid "All modules should work against all minor versions of version 4 of the API. Version 3 of the API is not supported." -#~ msgstr "すべてのモジュールは API のバージョン 4 のすべてのマイナーバージョンに対して動作します。API のバージョン 3 はサポート対象外です。" - -#~ msgid "Libraries" -#~ msgstr "ライブラリー" - -#~ msgid "All modules should use ``ovirt_full_argument_spec`` or ``ovirt_info_full_argument_spec`` to pick up the standard input (such as auth and ``fetch_nested``)." -#~ msgstr "すべてのモジュールは ``ovirt_full_argument_spec`` または ``ovirt_info_full_argument_spec`` を使用して、標準入力 (認証、``fetch_nested`` など) にする必要があります。" - -#~ msgid "All modules should use ``extends_documentation_fragment``: ovirt to go along with ``ovirt_full_argument_spec``." -#~ msgstr "すべてのモジュールは、``ovirt_full_argument_spec`` に従うために ``extends_documentation_fragment``: ovirt を使用する必要があります。" - -#~ msgid "All info modules should use ``extends_documentation_fragment``: ``ovirt_info`` to go along with ``ovirt_info_full_argument_spec``." -#~ msgstr "すべての info モジュールは、``ovirt_info_full_argument_spec`` に従うために ``extends_documentation_fragment``: ``ovirt_info`` を使用する必要があります。" - -#~ msgid "Functions that are common to all modules should be implemented in the ``module_utils/ovirt.py`` file, so they can be reused." -#~ msgstr "すべてのモジュールに共通する関数は、``module_utils/ovirt.py`` ファイルに実装されているため、再利用できます。" - -#~ msgid "Python SDK version 4 must be used." -#~ msgstr "Python SDK バージョン 4 を使用する必要があります。" - -#~ msgid "New module development" -#~ msgstr "新しいモジュール開発" - -#~ msgid "Please read :ref:`developing_modules`, first to know what common properties, functions and features every module must have." -#~ msgstr "「:ref:`developing_modules`」をお読みください。最初に、すべてのモジュールに必要な共通のプロパティー、関数、および機能を確認します。" - -#~ msgid "In order to achieve idempotency of oVirt entity attributes, a helper class was created. The first thing you need to do is to extend this class and override a few methods:" -#~ msgstr "oVirt エンティティー属性のべき等性を実現するには、ヘルパークラスが作成されました。まず、このクラスを拡張し、いくつかのメソッドを上書きする必要があります。" - -#~ msgid "The code above handle the check if the entity should be updated, so we don't update the entity if not needed and also it construct the needed entity of the SDK." -#~ msgstr "上記のコードは、エンティティーを更新すべきかどうかのチェックを処理するため、必要でない場合はエンティティーを更新せず、SDK に必要なエンティティーを構築します。" - -#~ msgid "If your module must support action handling (for example, virtual machine start) you must ensure that you handle the states of the virtual machine correctly, and document the behavior of the module:" -#~ msgstr "モジュールがアクション処理 (例: 仮想マシンの開始) をサポートする必要がある場合は、仮想マシンの状態を正しく処理し、モジュールの動作を文書化する必要があります。" - -#~ msgid "As you can see from the preceding example, the ``action`` method accepts the ``action_condition`` and ``wait_condition``, which are methods which accept the virtual machine object as a parameter, so you can check whether the virtual machine is in a proper state before the action. The rest of the parameters are for the ``start`` action. You may also handle pre- or post- action tasks by defining ``pre_action`` and ``post_action`` parameters." -#~ msgstr "前述の例で分かるように、``action`` メソッドは ``action_condition`` および ``wait_condition`` (仮想マシンオブジェクトをパラメーターとして許可するメソッド) を受け入れます。そのため、仮想マシンがアクションの前に適切な状態にあるかどうかを確認できます。残りのパラメーターは ``start`` アクション用です。``pre_action`` パラメーターおよび ``post_action`` パラメーターを定義して、事前または後続のアクションのタスクを処理することもできます。" - -#~ msgid "Testing" -#~ msgstr "テスト" - -#~ msgid "Integration testing is currently done in oVirt's CI system `on Jenkins `__ and `on GitHub `__." -#~ msgstr "統合テストは、現在、__ と `GitHub `__ の oVirt's CI システム で行われています。" - -#~ msgid "Please consider using these integration tests if you create a new module or add a new feature to an existing module." -#~ msgstr "新しいモジュールを作成する場合、または既存のモジュールに新しい機能を追加する場合は、これらの統合テストの使用を検討してください。" - -#~ msgid "The Ansible VMware collection (on `Galaxy `_, source code `repository `_) is maintained by the VMware Working Group. For more information see the `team community page `_." -#~ msgstr "詳細は、Ansible VMware コレクション (`Galaxy `_ で、ソースコード `repository `_) は VMware ワーキンググループにより維持されます。詳細は `team community page `_ を参照してください。" - -#~ msgid "Testing with govcsim" -#~ msgstr "govcsim を使用したテスト" - -#~ msgid "Most of the existing modules are covered by functional tests. The tests are located `here `_." -#~ msgstr "既存のモジュールのほとんどは、機能テストで対応しています。テストは、`ここ `_ に置かれます。" - -#~ msgid "By default, the tests run against a vCenter API simulator called `govcsim `_. ``ansible-test`` will automatically pull a `govcsim container `_ and use it to set-up the test environment." -#~ msgstr "デフォルトでは、テストは、`govcsim `_ という名前の vCenter API シミュレーターに対して実行されます。``ansible-test`` は、`govcsim コンテナー `_ を自動的にプルし、これを使用してテスト環境を設定します。" - -#~ msgid "You can trigger the test of a module manually with the ``ansible-test`` command. For example, to trigger ``vcenter_folder`` tests:" -#~ msgstr "``ansible-test`` コマンドを使用して、モジュールのテストを手動でトリガーできます。たとえば、``vcenter_folder`` テストを開始するには、以下を行います。" - -#~ msgid "``govcsim`` is handy because it is much faster than a regular test environment. However, ``govcsim`` does not support all the ESXi or vCenter features." -#~ msgstr "``govcsim`` は、通常のテスト環境よりもはるかに高速ですが、``govcsim`` は ESXi 機能または vCenter 機能をすべてサポートしません。" - -#~ msgid "Do not confuse ``govcsim`` with ``vcsim``. ``vcsim`` is an older and outdated version of vCenter simulator, whereas ``govcsim`` is new and written in Go language." -#~ msgstr "``govcsim`` と ``vcsim`` を混同しないでください。``vcsim`` は、古いバージョンの vCenterシミュレーターですが、``govcsim`` は新しく、Go 言語で書かれています" - -#~ msgid "Testing with your own infrastructure" -#~ msgstr "独自のインフラストラクチャーでのテスト" - -#~ msgid "You can also target a regular VMware environment. This paragraph explains step by step how you can run the test-suite yourself." -#~ msgstr "通常の VMware 環境を対象とすることもできます。この段落では、テストスイートを自分で実行する方法について順を追って説明します。" - -#~ msgid "2 ESXi hosts (6.5 or 6.7)" -#~ msgstr "2 台の ESXi ホスト (6.5 または 6.7)" - -#~ msgid "with 2 NIC, the second ones should be available for the test" -#~ msgstr "2 つの NIC (テスト用に 2 番目の NIC が利用可能)" - -#~ msgid "a VCSA host" -#~ msgstr "VCSA ホスト" - -#~ msgid "a NFS server" -#~ msgstr "NFS サーバー" - -#~ msgid "Python dependencies:" -#~ msgstr "Python の依存関係:" - -#~ msgid "`pyvmomi `_" -#~ msgstr "`pyvmomi `_" - -#~ msgid "`requests `_" -#~ msgstr "`requests `_" - -#~ msgid "If you want to deploy your test environment in a hypervisor, both `VMware or Libvirt `_ works well." -#~ msgstr "ハイパーバイザーにテスト環境をデプロイする場合は、`VMware または Libvirt ` の両方が正常に機能します。" - -#~ msgid "NFS server configuration" -#~ msgstr "NFS サーバーの設定" - -#~ msgid "Your NFS server must expose the following directory structure:" -#~ msgstr "NFS サーバーでは、以下のディレクトリー構造を公開する必要があります。" - -#~ msgid "On a Linux system, you can expose the directory over NFS with the following export file:" -#~ msgstr "Linux システムでは、次のエクスポートファイルを使用して、NFS 経由でディレクトリーを公開できます。" - -#~ msgid "With this configuration all the new files will be owned by the user with the UID and GID 1000/1000. Adjust the configuration to match your user's UID/GID." -#~ msgstr "この設定では、UID 1000 および GID 1000 のユーザーが、新しいファイルをすべて所有します。ユーザーの UID および GID に合わせて設定を調整してください。" - -#~ msgid "The service can be enabled with:" -#~ msgstr "このサービスは以下で有効にできます。" - -#~ msgid "Configure your installation" -#~ msgstr "インストールの設定" - -#~ msgid "Prepare a configuration file that describes your set-up. The file should be called :file:`test/integration/cloud-config-vcenter.ini` and based on :file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template`. For instance, if you have deployed your lab with `vmware-on-libvirt `_:" -#~ msgstr "セットアップを説明する構成ファイルを準備します。このファイルは :file:`test/integration/cloud-config-vcenter.ini` という名前し、:file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template` をベースにする必要があります。たとえば、`vmware-on-libvirt `_ でラボをデプロイした場合は以下のようになります。" - -#~ msgid "Using an HTTP proxy" -#~ msgstr "HTTP プロキシーの使用" - -#~ msgid "Hosting test infrastructure behind an HTTP proxy is supported. You can specify the location of the proxy server with the two extra keys:" -#~ msgstr "HTTP プロキシーの背後にあるホスティングテストインフラストラクチャーがサポートされています。次の 2 つの追加キーを使用して、プロキシーサーバーの場所を指定できます。" - -#~ msgid "In addition, you may need to adjust the variables of the following `var files `_ to match the configuration of your lab. If you use vmware-on-libvirt to prepare your lab, you do not have anything to change." -#~ msgstr "さらに、ラボの構成に一致させるために、次の `var ファイル `_ の変数を調整しないといけない場合があります。vmware-on-libvirt を使用してラボを準備する場合は、変更することができません。" - -#~ msgid "Run the test-suite" -#~ msgstr "テストスイートの実行" - -#~ msgid "Once your configuration is ready, you can trigger a run with the following command:" -#~ msgstr "設定の準備ができたら、以下のコマンドで実行をトリガーできます。" - -#~ msgid "``vmware_host_firewall_manager`` is the name of the module to test." -#~ msgstr "``vmware_host_firewall_manager`` は、テストするモジュールの名前です。" - -#~ msgid "``vmware_guest`` is much larger than any other test role and is rather slow. You can enable or disable some of its test playbooks in `main.yml `_." -#~ msgstr "``vmware_guest`` は、他のテストロールよりもはるかに大きく、速度もかなり遅くなります。`main.yml `_ でテスト Playbook の一部を有効または無効にできます。" - -#~ msgid "Unit-test" -#~ msgstr "ユニットテスト" - -#~ msgid "The VMware modules have limited unit-test coverage. You can run the test suite with the following commands:" -#~ msgstr "VMware モジュールには、unit-test の範囲が限定されています。以下のコマンドを実行してテストスイートを実行できます。" - -#~ msgid "Code style and best practice" -#~ msgstr "コードスタイルおよびベストプラクティス" - -#~ msgid "datacenter argument with ESXi" -#~ msgstr "ESXi での datacenter 引数" - -#~ msgid "The ``datacenter`` parameter should not use ``ha-datacenter`` by default. This is because the user may not realize that Ansible silently targets the wrong data center." -#~ msgstr "``datacenter`` パラメーターはデフォルトで ``ha-datacenter`` を使用しないでください。これは、Ansible が間違ったデータセンターをサイレントにターゲットにしていることにユーザーが気付かない可能性があるためです。" - -#~ msgid "esxi_hostname should not be mandatory" -#~ msgstr "esxi_hostname は必須ではない" - -#~ msgid "Depending upon the functionality provided by ESXi or vCenter, some modules can seamlessly work with both. In this case, ``esxi_hostname`` parameter should be optional." -#~ msgstr "ESXi または vCenter が提供する機能に応じて、一部のモジュールは両方でシームレスに動作します。この場合、``esxi_hostname`` パラメーターは任意である必要があります。" - -#~ msgid "Example should use the fully qualified collection name (FQCN)" -#~ msgstr "例では、完全修飾コレクション名 (FQCN) を使用する必要があります" - -#~ msgid "Use FQCN for examples within module documentation. For instance, you should use ``community.vmware.vmware_guest`` instead of just ``vmware_guest``." -#~ msgstr "モジュールドキュメントの例としては、FQCN を使用してください。たとえば、``vmware_guest`` ではなく ``community.vmware.vmware_guest`` を使用する必要があります。" - -#~ msgid "This way, the examples do not depend on the ``collections`` directive of the playbook." -#~ msgstr "この方法では、Playbook の ``collections`` ディレクティブに依存しません。" - -#~ msgid "Functional tests" -#~ msgstr "機能テスト" - -#~ msgid "Writing new tests" -#~ msgstr "新規テストの作成" - -#~ msgid "If you are writing a new collection of integration tests, there are a few VMware-specific things to note beyond the standard Ansible :ref:`integration testing` process." -#~ msgstr "統合テストの新しいコレクションを作成している場合は、標準の Ansible の :ref:`統合テスト` プロセス以外に注意すべき VMware 固有の事項がいくつかあります。" - -#~ msgid "The test-suite uses a set of common, pre-defined vars located `in prepare_vmware_tests `_ role. The resources defined there are automatically created by importing that role at the start of your test:" -#~ msgstr "テストスイートは、`prepare_vmware_tests `_ ロールにある一般的な事前定義済みの変数のセットを使用します。ここに定義されたリソースは、テストの開始時にそのロールをインポートして自動的に作成されます。" - -#~ msgid "This will give you a ready to use cluster, datacenter, datastores, folder, switch, dvswitch, ESXi hosts, and VMs." -#~ msgstr "これにより、クラスター、データセンター、データストア、ディレクトリー、スイッチ、dvSwitch、ESXi ホスト、および仮想マシンを使用する準備が整います。" - -#~ msgid "No need to create too much resources" -#~ msgstr "リソースを過剰に作成する必要なし" - -#~ msgid "Most of the time, it's not necessary to use ``with_items`` to create multiple resources. By avoiding it, you speed up the test execution and you simplify the clean up afterwards." -#~ msgstr "多くの場合、``with_items`` を使用して複数のリソースの作成を行う必要はありません。回避することで、テストの実行を迅速化して、後でクリーンアップを単純化できます。" - -#~ msgid "VM names should be predictable" -#~ msgstr "仮想マシン名は、名前で内容が予測できるものにする" - -#~ msgid "If you need to create a new VM during your test, you can use ``test_vm1``, ``test_vm2`` or ``test_vm3``. This way it will be automatically clean up for you." -#~ msgstr "テスト中に新しい仮想マシンを作成する必要がある場合は、``test_vm1``、``test_vm2``、または ``test_vm3`` を使用できます。このように、自動的にクリーンアップされます。" - -#~ msgid "Avoid the common boiler plate code in your test playbook" -#~ msgstr "テスト Playbook で一般的なボイラールのコードを回避" - -#~ msgid "From Ansible 2.10, the test suite uses `modules_defaults`. This module allow us to preinitialize the following default keys of the VMware modules:" -#~ msgstr "Ansible 2.10 以降では、テストスイートは `modules_defaults` を使用します。このモジュールにより、以下の VMware モジュールのデフォルトキーを事前に初期化できます。" - -#~ msgid "hostname" -#~ msgstr "hostname" - -#~ msgid "username" -#~ msgstr "username" - -#~ msgid "password" -#~ msgstr "password" - -#~ msgid "validate_certs" -#~ msgstr "validate_certs" - -#~ msgid "For example, the following block:" -#~ msgstr "たとえば、以下のブロックの場合:" - -#~ msgid "should be simplified to just:" -#~ msgstr "以下を単純化する必要があります。" - -#~ msgid "Typographic convention" -#~ msgstr "表記規則" - -#~ msgid "Nomenclature" -#~ msgstr "命名法" - -#~ msgid "VMware, not VMWare or vmware" -#~ msgstr "VMware (VMWare または vmware ではありません)" - -#~ msgid "ESXi, not esxi or ESXI" -#~ msgstr "ESXi (esxi または ESXI ではありません)" - -#~ msgid "vCenter, not vcenter or VCenter" -#~ msgstr "vCenter (vcenter または VCenter ではありません)" - -#~ msgid "We also refer to vcsim's Go implementation with ``govcsim``. This to avoid any confusion with the outdated implementation." -#~ msgstr "また、``govcsim`` を使用した vcsim の Go 実装も参照します。これは、古い実装との混乱を回避するためのものです。" - -#~ msgid "The Ansible VMware REST collection (on `Galaxy `_, source code `repository `_) is maintained by Red Hat and the community." -#~ msgstr "Ansible VMware REST コレクション (`Galaxy `_ ではソースコード `repository `_) は、Red Hat とコミュニティーにより維持されます。" - -#~ msgid "The modules of the vmware_rest collection are autogenerated by another tool called `vmware_rest_code_generator `." -#~ msgstr "vmware_rest コレクションのモジュールは、`vmware_rest_code_generator ` と呼ばれる別のツールにより自動生成されます。" - -#~ msgid "If you would like to contribute a change, we would appreciate if you:" -#~ msgstr "変更に貢献したい場合は、以下をご用意ください。" - -#~ msgid "submit a Github Pull Request (PR) against the vmware_rest_code_generator project" -#~ msgstr "vmware_rest_code_generator プロジェクトに対して Github Pull Request (PR) を送信します。" - -#~ msgid "but also ensure the generated modules are compliant with our quality criteria." -#~ msgstr "ただし、生成されたモジュールが品質基準に準拠していることを確認します。" - -#~ msgid "You will need:" -#~ msgstr "以下が必要になります。" - -#~ msgid "Python 3.6 or greater" -#~ msgstr "Python 3.6 以降" - -#~ msgid "the `tox ` command" -#~ msgstr "`tox ` コマンド" - -#~ msgid "vmware_rest_code_generator" -#~ msgstr "vmware_rest_code_generator" - -#~ msgid "Your contribution should follow the coding style of `Black `. To run the code formatter, just run:" -#~ msgstr "貢献は、`Black ` のコーディングスタイルに従う必要があります。コードフォーマッターを実行するには、以下を実行します。" - -#~ msgid "To regenerate the vmware_rest collection, you can use the following commands:" -#~ msgstr "vmware_rest コレクションを再生成するには、以下のコマンドを使用できます。" - -#~ msgid "If you also want to update the EXAMPLE section of the modules, run:" -#~ msgstr "モジュールの EXAMPLE セクションも更新する場合は、以下を実行します。" - -#~ msgid "Testing with ansible-test" -#~ msgstr "ansible-test を使用したテスト" - -#~ msgid "All the modules are covered by a functional test. The tests are located in the :file:`tests/integration/targets/`." -#~ msgstr "すべてのモジュールは、機能テストで対応しています。テストは、:file:`tests/integration/targets/` に置かれます。" - -#~ msgid "To run the tests, you will need a vcenter instance and an ESXi." -#~ msgstr "テストを実行するには、vcenter インスタンスと ESXi が必要です。" - -#~ msgid "black code formatter" -#~ msgstr "ブラックコードフォーマッター" - -#~ msgid "We follow the coding style of `Black `. You can run the code formatter with the following command." -#~ msgstr "`Black ` のコーディングスタイルに準拠しています。以下のコマンドでコードフォーマッターを実行できます。" - -#~ msgid "sanity tests" -#~ msgstr "健全性テスト" - -#~ msgid "Here we use Python 3.8, the minimal version is 3.6." -#~ msgstr "ここでは Python 3.8 を使用します。最小バージョンは 3.6 です。" - -#~ msgid "These tests should be run against your test environment." -#~ msgstr "これらのテストは、テスト環境に対して実行する必要があります。" - -#~ msgid "..warning:: The test suite will delete all the existing DC from your test environment." -#~ msgstr "..警告:: テストスイートは、テスト環境から既存の DC をすべて削除します。" - -#~ msgid "First, prepare a configuration file, we call it :file:`/tmp/inventory-vmware_rest` in this example:" -#~ msgstr "まず設定ファイルを準備し、この例では :file:`/tmp/inventory-vmware_rest` とします。" - -#~ msgid "To run the tests, use the following command. You may want to adjust the Python version." -#~ msgstr "テストを実行するには、以下のコマンドを使用して Python バージョンを調整できます。" - -#~ msgid "Ask for advice on IRC, on the ``#ansible-devel`` Freenode channel" -#~ msgstr "Freenode チャンネル ``#ansible-devel`` の IRC で質問してください。" - -#~ msgid "Ansible Tower®" -#~ msgstr "Ansible Tower®" - -#~ msgid "If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs. We almost always prioritize bug fixing over feature development." -#~ msgstr "開発者にとって、最も価値のあることの 1 つが、GitHub の問題を確認し、バグ修正を手伝うことです。バグ修正は、ほとんど常に、機能開発よりも優先されるためです。" - -#~ msgid "Even for non developers, helping to test pull requests for bug fixes and features is still immensely valuable. Ansible users who understand writing playbooks and roles should be able to add integration tests and so GitHub pull requests with integration tests that show bugs in action will also be a great way to help." -#~ msgstr "開発者ではなくても、バグの修正や機能のプル要求のテストを手伝うことは非常に価値のあることです。Ansible ユーザーが Playbook やロールの書き方を熟知していれば統合テストを追加できるため、バグが実際に動かしている様子を示す統合テストが付いた GitHub プル要求も、大きな助けになるでしょう。" - -#~ msgid "If the issue persists, please contact us in ``#ansible-devel`` on Freenode IRC." -#~ msgstr "問題が解決しない場合は、Freenode IRC の ``#ansible-devel`` にお問い合わせください。" - -#~ msgid "``skip/windows/2008`` - Skip tests on Windows Server 2008." -#~ msgstr "``skip/windows/2008`` - Windows Server 2008 のテストを省略します。" - -#~ msgid "For questions about integration tests reach out to @mattclay or @gundalow on GitHub or ``#ansible-devel`` on IRC." -#~ msgstr "インテグレーションテストに関する質問は、GitHub で @mattclay または @gundalow、または IRC で ``#ansible-devel`` にお問い合わせください。" - -#~ msgid "Avoiding pulling new Docker images" -#~ msgstr "新規 Docker イメージのプルの回避" - -#~ msgid "Use the ``--docker-no-pull`` option to avoid pulling the latest container image. This is required when using custom local images that are not available for download." -#~ msgstr "最新のコンテナーイメージをプルしないようにするには、``--docker-no-pull`` オプションを使用します。これは、ダウンロードに利用できないカスタムのローカルイメージを使用する場合に必要です。" - -#~ msgid "Python 2" -#~ msgstr "Python 2" - -#~ msgid "Most container images are for testing with Python 2:" -#~ msgstr "ほとんどのコンテナーイメージは、Python 2 でテストするためのものです。" - -#~ msgid "centos6" -#~ msgstr "centos6" - -#~ msgid "centos7" -#~ msgstr "centos7" - -#~ msgid "fedora28" -#~ msgstr "fedora28" - -#~ msgid "opensuse15py2" -#~ msgstr "opensuse15py2" - -#~ msgid "ubuntu1404" -#~ msgstr "ubuntu1404" - -#~ msgid "ubuntu1604" -#~ msgstr "ubuntu1604" - -#~ msgid "Python 3" -#~ msgstr "Python 3" - -#~ msgid "To test with Python 3 use the following images:" -#~ msgstr "Python 3 でテストするには、以下のイメージを使用します。" - -#~ msgid "centos8" -#~ msgstr "centos8" - -#~ msgid "fedora32" -#~ msgstr "fedora32" - -#~ msgid "opensuse15" -#~ msgstr "opensuse15" - -#~ msgid "ubuntu1804" -#~ msgstr "ubuntu1804" - -#~ msgid "last-line-main-call" -#~ msgstr "last-line-main-call" - -#~ msgid "Call to ``main()`` not the last line (or ``removed_module()`` in the case of deprecated & docs only modules)" -#~ msgstr "最終行以外の ``main()`` の呼出し (または、非推奨およびドキュメントのみのモジュールでは ``removed_module()``)。" - -#~ msgid "missing-if-name-main" -#~ msgstr "missing-if-name-main" - -#~ msgid "Next to last line is not ``if __name__ == \"__main__\":``" -#~ msgstr "最後の行の隣になるものは、``if __name__ == \"__main__\":`` ではない" - -#~ msgid "missing-main-call" -#~ msgstr "missing-main-call" - -#~ msgid "Did not find a call to ``main()`` (or ``removed_module()`` in the case of deprecated & docs only modules)" -#~ msgstr "``main()`` への呼出しが見つからなかった (非推奨またはドキュメントのみのモジュールの場合は ``removed_module()``)。" - -#~ msgid "missing-python-doc" -#~ msgstr "missing-python-doc" - -#~ msgid "an :ref:`OpenStack module `." -#~ msgstr ":ref:`OpenStack モジュール `" - -#~ msgid "an :ref:`oVirt/RHV module `." -#~ msgstr ":ref:`oVirt/RHV モジュール `" - -#~ msgid "When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code via a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you." -#~ msgstr ":ref:`developing_testing` のドキュメントを読む際、Ansible 開発者の典型的な git clone を使用して、ソースコードから Ansible を実行するコンテンツがあります。ただし、Ansible Collection の作成者がソースから Ansible を実行することは常に一般的ではなく、安定したリリースからではなく、コレクションを作成するには、ソースから Ansible を実行する必要はありません。そのため、`ansible-test` バイナリーパス、コマンド補完、または環境変数については、:ref:`developing_testing` ドキュメントで提示されます。Ansible Collection Testing ではこれが必要ありません。`ansible-test` を含む Ansible の安定したリリースをインストールするには、これらをセットアップすることが予想されるためです。" - -#~ msgid "Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the general compile and sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core." -#~ msgstr "コレクションのテストにより、コードが適切に機能し、Ansible エコシステムの他の部分との統合性が向上します。コレクションでは、Ansible コードの一般的なコンパイルおよび健全性テストを渡します。また、コレクションのコードに対応するユニットテストと、コレクションと ansible-core との間の対話に対応する統合テストを追加する必要があります。" - -#~ msgid "Compile and sanity tests" -#~ msgstr "コンパイルと健全性テスト" - -#~ msgid "Although ``ansible-core`` (the code hosted in the `ansible/ansible repository `_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-core`` work together." -#~ msgstr "``ansible-core`` (GitHub の `ansible/ansible リポジトリー `_ でホストされるコード) には、Playbook ディレクティブまたは設定を介してスワップできるプラグインが含まれていますが、モジュール化されないコードが多くあります。また、``ansible-core`` の一部が連携する方法に関するドキュメントです。" - -#~ msgid "The three main options from the ``constructed`` documentation fragment are ``compose``, ``keyed_groups``, and ``groups``. See the ``constructed`` inventory plugin for examples on using these. ``compose`` is a dictionary of variable names and Jinja2 expressions. Once a host is added to inventory and any initial variables have been set, call the method ``_set_composite_vars`` to add composed host variables. If this is done before adding ``keyed_groups`` and ``groups``, the group generation will be able to use the composed variables." -#~ msgstr "``constructed`` ドキュメントフラグの 3 つの主要なオプションは、``compose``、``keyed_groups``、および ``groups`` です。これらの使用例は、``constructed`` インベントリープラグインを参照してください。``compose`` は、変数名および Jinja2 式のディクショナリーです。ホストがインベントリーに追加され、初期変数が設定されると、``_set_composite_vars`` メソッドを呼び出して構成されたホスト変数を追加します。``keyed_groups`` および ``groups`` を追加する前にこれを行うと、グループの生成は構成された変数を使用できます。" - -#~ msgid "Modules are reusable, standalone scripts that can be used by the Ansible API, the :command:`ansible` command, or the :command:`ansible-playbook` command. Modules provide a defined interface. Each module accepts arguments and returns information to Ansible by printing a JSON string to stdout before exiting. Modules execute on the target system (usually that means on a remote system) in separate processes. Modules are technically plugins, but for historical reasons we do not usually talk about \"module plugins\"." -#~ msgstr "モジュールは、Ansible API、:command:`ansible` コマンド、または :command:`ansible-playbook` コマンドで使用できる再利用可能なスタンドアロンスクリプトです。モジュールは、定義されたインターフェースを提供します。各モジュールは引数を受け入れ、終了する前に JSON 文字列を stdout に出力して Ansible に情報を返します。モジュールは、別のプロセスでターゲットシステム (通常はリモートシステム上) で実行されます。モジュールは技術的にはプラグインですが、過去の経緯から、通常「モジュールプラグイン」とは呼びません。" - -#~ msgid "Currently, the ``ansible-doc`` command can parse module documentation only from modules written in Python. If you have a module written in a programming language other than Python, please write the documentation in a Python file adjacent to the module file." -#~ msgstr "現在、``ansible-doc`` コマンドは、Python で記述されたモジュールからのみモジュールドキュメントを解析できます。Python 以外のプログラミング言語で記述されたモジュールがある場合は、モジュールファイルの横の Python ファイルにドキュメントを作成してください。" - -#~ msgid "Developing Cisco ACI modules" -#~ msgstr "Cisco ACI モジュールの開発" - -#~ msgid "This is a brief walk-through of how to create new Cisco ACI modules for Ansible." -#~ msgstr "Ansible 向けに新しい Cisco ACI モジュールを作成する方法に関する簡単なウォークスルーです。" - -#~ msgid "For more information about Cisco ACI, look at the :ref:`Cisco ACI user guide `." -#~ msgstr "Cisco ACI の詳細は、「:ref:`Cisco ACI ユーザーガイド `」を参照してください。" - -#~ msgid "The `cisco.aci collection `_ already includes a large number of Cisco ACI modules, however the ACI object model is huge and covering all possible functionality would easily cover more than 1500 individual modules." -#~ msgstr "`cisco.aci collection `_ にはすでに多数の Cisco ACI モジュールが含まれていますが、ACI オブジェクトモデルは大きく、すべての機能に対応するため、1500 以上のモジュールを簡単に対応できます。" - -#~ msgid "If you need specific functionality, you have 2 options:" -#~ msgstr "特定の機能が必要な場合は、2 つのオプションがあります。" - -#~ msgid "Learn the ACI object model and use the low-level APIC REST API using the :ref:`aci_rest ` module" -#~ msgstr "ACI オブジェクトモデルを学習し、「:ref:`aci_rest `」モジュールを使用して低レベルの APIC REST API を使用します。" - -#~ msgid "Write your own dedicated modules, which is actually quite easy" -#~ msgstr "独自の専用モジュールを作成することは、実際には非常に簡単です。" - -#~ msgid "`Ansible ACI collection `_" -#~ msgstr "`Ansible ACI collection `_" - -#~ msgid "Github repository of the ansible ACI collection" -#~ msgstr "Ansible ACI コレクションの GitHub リポジトリー" - -#~ msgid ":ref:`hacking_collections`" -#~ msgstr ":ref:`collections`" - -#~ msgid "Information on how to contribute to collections." -#~ msgstr "コレクションへの貢献方法に関する情報。" - -#~ msgid "`ACI Fundamentals: ACI Policy Model `_" -#~ msgstr "`ACI Fundamentals: ACI Policy Model `_" - -#~ msgid "A good introduction to the ACI object model." -#~ msgstr "ACI オブジェクトモデルの優れた概要" - -#~ msgid "`APIC Management Information Model reference `_" -#~ msgstr "`APIC Management Information Model reference `_" - -#~ msgid "Complete reference of the APIC object model." -#~ msgstr "APIC オブジェクトモデルの完全なリファレンス" - -#~ msgid "`APIC REST API Configuration Guide `_" -#~ msgstr "`APIC REST API Configuration Guide `_" - -#~ msgid "Detailed guide on how the APIC REST API is designed and used, incl. many examples." -#~ msgstr "APIC REST API を設計および使用する方法についての詳細ガイド。多数の例があります。" - -#~ msgid "So let's look at how a typical ACI module is built up." -#~ msgstr "それでは、典型的な ACI モジュールがどのように構築されるかを見てみましょう。" - -#~ msgid "ACI module structure" -#~ msgstr "ACI モジュール構造" - -#~ msgid "Importing objects from Python libraries" -#~ msgstr "Python ライブラリーからのオブジェクトのインポート" - -#~ msgid "The following imports are standard across ACI modules:" -#~ msgstr "以下のインポートは、ACI モジュール全体で標準のものです。" - -#~ msgid "Defining the argument spec" -#~ msgstr "引数仕様の定義" - -#~ msgid "The first line adds the standard connection parameters to the module. After that, the next section will update the ``argument_spec`` dictionary with module-specific parameters. The module-specific parameters should include:" -#~ msgstr "最初の行は、標準の接続パラメーターをモジュールに追加します。その後、以下のセクションはモジュール固有のパラメーターで ``argument_spec`` ディクショナリーを更新します。モジュール固有のパラメーターには以下が含まれます。" - -#~ msgid "the object_id (usually the name)" -#~ msgstr "object_id (通常は名前)" - -#~ msgid "the configurable properties of the object" -#~ msgstr "オブジェクトの設定可能なプロパティー" - -#~ msgid "the parent object IDs (all parents up to the root)" -#~ msgstr "親オブジェクト ID (ルートまでのすべての親)" - -#~ msgid "only child classes that are a 1-to-1 relationship (1-to-many/many-to-many require their own module to properly manage)" -#~ msgstr "1 対 1 の関係である子クラスのみ (1 対多/多対多では、独自のモジュールを適切に管理する必要があります)" - -#~ msgid "the state" -#~ msgstr "状態" - -#~ msgid "``state: absent`` to ensure object does not exist" -#~ msgstr "``state: absent``: オブジェクトが存在しないことを確認する" - -#~ msgid "``state: present`` to ensure the object and configs exist; this is also the default" -#~ msgstr "``state: present``: オブジェクトと設定が存在することを確認する (デフォルト)" - -#~ msgid "``state: query`` to retrieve information about objects in the class" -#~ msgstr "``state: query``: クラスのオブジェクトに関する情報を取得する" - -#~ msgid "Do not provide default values for configuration arguments. Default values could cause unintended changes to the object." -#~ msgstr "設定引数のデフォルト値を指定しないでください。デフォルト値により、オブジェクトへの意図しない変更が生じる可能性があります。" - -#~ msgid "Using the AnsibleModule object" -#~ msgstr "AnsibleModule オブジェクトの使用" - -#~ msgid "The following section creates an AnsibleModule instance. The module should support check-mode, so we pass the ``argument_spec`` and ``supports_check_mode`` arguments. Since these modules support querying the APIC for all objects of the module's class, the object/parent IDs should only be required if ``state: absent`` or ``state: present``." -#~ msgstr "次のセクションでは、AnsibleModule インスタンスを作成します。モジュールはチェックモードをサポートする必要があるため、``argument_spec`` 引数および ``supports_check_mode`` 引数を渡します。これらのモジュールは、モジュールのクラスのすべてのオブジェクトに対する APIC のクエリーをサポートするため、オブジェクト/親 ID は、``state: absent`` または ``state: present`` の場合に限り必要になります。" - -#~ msgid "Mapping variable definition" -#~ msgstr "マッピング変数定義" - -#~ msgid "Once the AnsibleModule object has been initiated, the necessary parameter values should be extracted from ``params`` and any data validation should be done. Usually the only params that need to be extracted are those related to the ACI object configuration and its child configuration. If you have integer objects that you would like to validate, then the validation should be done here, and the ``ACIModule.payload()`` method will handle the string conversion." -#~ msgstr "AnsibleModule オブジェクトが開始されたら、必要なパラメーターの値を ``params`` から抽出し、データの検証を行う必要があります。通常、抽出する必要がある唯一のパラメーターが ACI オブジェクトの設定およびその子設定に関連するパラメーターのみとなります。検証する整数オブジェクトがある場合は、検証を行う必要があります。データ検証はここで行う必要があり、``ACIModule.payload()`` メソッドは変換文字列を処理する必要があります。" - -#~ msgid "Using the ACIModule object" -#~ msgstr "ACIModule オブジェクトの使用" - -#~ msgid "The ACIModule class handles most of the logic for the ACI modules. The ACIModule extends functionality to the AnsibleModule object, so the module instance must be passed into the class instantiation." -#~ msgstr "ACIModule クラスは、ACI モジュールのロジックの大部分を処理します。ACIModule は機能を AnsibleModule オブジェクトに拡張するため、モジュールインスタンスをクラスのインスタンス化に渡す必要があります。" - -#~ msgid "The ACIModule has six main methods that are used by the modules:" -#~ msgstr "ACIModule には、モジュールによって使用される 6 つの主なメソッドがあります。" - -#~ msgid "construct_url" -#~ msgstr "construct_url" - -#~ msgid "get_existing" -#~ msgstr "get_existing" - -#~ msgid "payload" -#~ msgstr "payload" - -#~ msgid "get_diff" -#~ msgstr "get_diff" - -#~ msgid "post_config" -#~ msgstr "post_config" - -#~ msgid "delete_config" -#~ msgstr "delete_config" - -#~ msgid "The first two methods are used regardless of what value is passed to the ``state`` parameter." -#~ msgstr "最初の 2 つのメソッドは、``state`` パラメーターに渡される値に関係なく使用されます。" - -#~ msgid "Constructing URLs" -#~ msgstr "URL の構築" - -#~ msgid "The ``construct_url()`` method is used to dynamically build the appropriate URL to interact with the object, and the appropriate filter string that should be appended to the URL to filter the results." -#~ msgstr "``construct_url()`` メソッドは、オブジェクトと対話するために適切な URL と、URL に追加して結果にフィルターを設定する適切なフィルター文字列を動的に構築するのに使用されます。" - -#~ msgid "When the ``state`` is not ``query``, the URL is the base URL to access the APIC plus the distinguished name to access the object. The filter string will restrict the returned data to just the configuration data." -#~ msgstr "``state`` が ``query`` でない場合、URL は APIC にアクセスするベース URL と、オブジェクトにアクセスするための識別名です。フィルター文字列は返されたデータを設定データにのみ制限します。" - -#~ msgid "When ``state`` is ``query``, the URL and filter string used depends on what parameters are passed to the object. This method handles the complexity so that it is easier to add new modules and so that all modules are consistent in what type of data is returned." -#~ msgstr "``state`` が ``query`` される場合、使用される URL およびフィルター文字列は、オブジェクトに渡されるパラメーターによって異なります。この方法は複雑性を処理するため、新しいモジュールの追加が容易になります。また、すべてのモジュールがどのタイプのデータを返すかに一貫性を持たせるようにします。" - -#~ msgid "Our design goal is to take all ID parameters that have values, and return the most specific data possible. If you do not supply any ID parameters to the task, then all objects of the class will be returned. If your task does consist of ID parameters sed, then the data for the specific object is returned. If a partial set of ID parameters are passed, then the module will use the IDs that are passed to build the URL and filter strings appropriately." -#~ msgstr "この設計の目的は、値があるすべての ID パラメーターを取り、最も具体的なデータを返すことです。ID パラメーターをタスクに指定しないと、クラスのすべてのオブジェクトが返されます。タスクが ID パラメーター sed で構成されている場合は、特定のオブジェクトのデータが返されます。ID パラメーターの一部が渡されると、モジュールは URL およびフィルター文字列を適切にビルドするために渡された ID を使用します。" - -#~ msgid "The ``construct_url()`` method takes 2 required arguments:" -#~ msgstr "``construct_url()`` メソッドは、必要な引数を 2 つ取ります。" - -#~ msgid "**self** - passed automatically with the class instance" -#~ msgstr "**self** - クラスインスタンスで自動的に渡されます。" - -#~ msgid "**root_class** - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -#~ msgstr "**root_class**: ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#~ msgid "**aci_class**: The name of the class used by the APIC, for example ``fvTenant``" -#~ msgstr "**aci_class**: APIC が使用するクラス名 (例: ``fvTenant``)" - -#~ msgid "**aci_rn**: The relative name of the object, for example ``tn-ACME``" -#~ msgstr "**aci_rn**: オブジェクトの相対名 (例: ``tn-ACME``)" - -#~ msgid "**target_filter**: A dictionary with key-value pairs that make up the query string for selecting a subset of entries, for example ``{'name': 'ACME'}``" -#~ msgstr "**target_filter**: エントリーのサブセットを選択するクエリー文字列を構成するキーと値のペアを持つディクショナリー (例: ``{'name': 'ACME'}``)" - -#~ msgid "**module_object**: The particular object for this class, for example ``ACME``" -#~ msgstr "**module_object**: このクラスの特定のオブジェクト (例: ``ACME``)" - -#~ msgid "Some modules, like ``aci_tenant``, are the root class and so they would not need to pass any additional arguments to the method." -#~ msgstr "``aci_tenant`` などの一部のモジュールは root クラスであるため、メソッドに追加の引数を渡す必要はありません。" - -#~ msgid "The ``construct_url()`` method takes 4 optional arguments, the first three imitate the root class as described above, but are for child objects:" -#~ msgstr "``construct_url()`` メソッドは、4 つの任意の引数を取ります。最初の 3 つの引数が上記のように root クラスを模倣しますが、これは子オブジェクト用です。" - -#~ msgid "subclass_1 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -#~ msgstr "subclass_1 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#~ msgid "Example: Application Profile Class (AP)" -#~ msgstr "例: Application Profile Class (AP)" - -#~ msgid "subclass_2 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -#~ msgstr "subclass_2 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#~ msgid "Example: End Point Group (EPG)" -#~ msgstr "例: エンドポイントグループ (EPG)" - -#~ msgid "subclass_3 - A dictionary consisting of ``aci_class``, ``aci_rn``, ``target_filter``, and ``module_object`` keys" -#~ msgstr "subclass_3 - ``aci_class`` キー、``aci_rn`` キー、``target_filter`` キー、および ``module_object`` キーで構成されるディクショナリー" - -#~ msgid "Example: Binding a Contract to an EPG" -#~ msgstr "例: EPG への契約のバインド" - -#~ msgid "child_classes - The list of APIC names for the child classes supported by the modules." -#~ msgstr "child_classes - モジュールがサポートする子クラスの APIC 名のリスト" - -#~ msgid "This is a list, even if it is a list of one" -#~ msgstr "1 つのリストであっても、これはリストです。" - -#~ msgid "These are the unfriendly names used by the APIC" -#~ msgstr "これらは、APIC が使用する分かりにくい名前です。" - -#~ msgid "These are used to limit the returned child_classes when possible" -#~ msgstr "可能な場合は、返された child_classes を制限するのに使用されます。" - -#~ msgid "Example: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``" -#~ msgstr "例: ``child_classes=['fvRsBDSubnetToProfile', 'fvRsNdPfxPol']``" - -#~ msgid "Sometimes the APIC will require special characters ([, ], and -) or will use object metadata in the name (\"vlanns\" for VLAN pools); the module should handle adding special characters or joining of multiple parameters in order to keep expected inputs simple." -#~ msgstr "APIC は、特殊文字 ([, ]、および -) を要求したり、名前にオブジェクトのメタデータ (「VLAN」プールの場合は「vlanns」) を使用したりすることがあります。モジュールは、予想される入力の単純さに保つために、特殊文字の追加または複数のパラメーターの結合を処理する必要があります。" - -#~ msgid "Getting the existing configuration" -#~ msgstr "既存設定の取得" - -#~ msgid "Once the URL and filter string have been built, the module is ready to retrieve the existing configuration for the object:" -#~ msgstr "URL およびフィルター文字列が構築されると、モジュールはオブジェクトの既存の設定を取得できるようになります。" - -#~ msgid "``state: present`` retrieves the configuration to use as a comparison against what was entered in the task. All values that are different than the existing values will be updated." -#~ msgstr "``state: present`` は、タスクに入力した値と比較として使用する設定を取得します。既存の値とは異なる値はすべて更新されます。" - -#~ msgid "``state: absent`` uses the existing configuration to see if the item exists and needs to be deleted." -#~ msgstr "``state: absent`` は、既存の設定を使用して項目が存在し、削除する必要があるかどうかを確認します。" - -#~ msgid "``state: query`` uses this to perform the query for the task and report back the existing data." -#~ msgstr "``state: query`` は、これを使用してタスクのクエリーを実行し、既存のデータを報告します。" - -#~ msgid "When state is present" -#~ msgstr "state が present の場合" - -#~ msgid "When ``state: present``, the module needs to perform a diff against the existing configuration and the task entries. If any value needs to be updated, then the module will make a POST request with only the items that need to be updated. Some modules have children that are in a 1-to-1 relationship with another object; for these cases, the module can be used to manage the child objects." -#~ msgstr "``state: present`` の場合、モジュールは既存の設定とタスクエントリーに対して diff を実行する必要があります。値を更新する必要がある場合、モジュールは更新が必要なアイテムのみが含まれる POST 要求を行います。モジュールによっては、別のオブジェクトと 1 対 1 の関係にある子があります。これらの場合、モジュールは子オブジェクトを管理するために使用できます。" - -#~ msgid "Building the ACI payload" -#~ msgstr "ACI ペイロードの構築" - -#~ msgid "The ``aci.payload()`` method is used to build a dictionary of the proposed object configuration. All parameters that were not provided a value in the task will be removed from the dictionary (both for the object and its children). Any parameter that does have a value will be converted to a string and added to the final dictionary object that will be used for comparison against the existing configuration." -#~ msgstr "``aci.payload()`` メソッドは、提案されたオブジェクト設定のディクショナリー構築に使用されます。タスクで値が提供されていないパラメーターはすべてディクショナリー (オブジェクトとその子の両方) から削除されます。値のあるパラメーターは文字列に変換され、既存の設定との比較に使用される最終ディクショナリーオブジェクトに追加されます。" - -#~ msgid "The ``aci.payload()`` method takes two required arguments and 1 optional argument, depending on if the module manages child objects." -#~ msgstr "``aci.payload()`` メソッドは、モジュールが子オブジェクトを管理するかどうかに応じて、2 つの必須引数と、1 つの任意の引数を取ります。" - -#~ msgid "``aci_class`` is the APIC name for the object's class, for example ``aci_class='fvBD'``" -#~ msgstr "``aci_class`` は、オブジェクトのクラスの APIC 名です。たとえば、``aci_class='fvBD'`` になります。" - -#~ msgid "``class_config`` is the appropriate dictionary to be used as the payload for the POST request" -#~ msgstr "``class_config`` は POST 要求のペイロードとして使用する適切なディクショナリーです。" - -#~ msgid "The keys should match the names used by the APIC." -#~ msgstr "キーは APIC で使用される名前と一致する必要があります。" - -#~ msgid "The values should be the corresponding value in ``module.params``; these are the variables defined above" -#~ msgstr "``module.params`` の対応する値でなければなりません。これらは上で定義される変数です" - -#~ msgid "``child_configs`` is optional, and is a list of child config dictionaries." -#~ msgstr "``child_configs`` は任意であり、子設定のディクショナリーの一覧です。" - -#~ msgid "The child configs include the full child object dictionary, not just the attributes configuration portion." -#~ msgstr "子設定には、属性設定部分だけでなく、完全な子オブジェクトディクショナリーが含まれます。" - -#~ msgid "The configuration portion is built the same way as the object." -#~ msgstr "設定部分は、オブジェクトと同じ方法で構築されます。" - -#~ msgid "Performing the request" -#~ msgstr "要求の実行" - -#~ msgid "The ``get_diff()`` method is used to perform the diff, and takes only one required argument, ``aci_class``. Example: ``aci.get_diff(aci_class='fvBD')``" -#~ msgstr "``get_diff()`` メソッドは diff を実行し、必要な引数 ``aci_class`` を 1 つだけ取ります。たとえば ``aci.get_diff(aci_class='fvBD')`` です。" - -#~ msgid "The ``post_config()`` method is used to make the POST request to the APIC if needed. This method doesn't take any arguments and handles check mode. Example: ``aci.post_config()``" -#~ msgstr "``post_config()`` メソッドは、必要に応じて APIC への POST 要求を行うために使用されます。このメソッドは引数を受け付けず、チェックモードを処理します。以下に例を示します。たとえば、``aci.post_config()`` になります。" - -#~ msgid "Example code" -#~ msgstr "サンプルコード" - -#~ msgid "When state is absent" -#~ msgstr "state が absent の場合" - -#~ msgid "If the task sets the state to absent, then the ``delete_config()`` method is all that is needed. This method does not take any arguments, and handles check mode." -#~ msgstr "タスクが state を absent に設定すると、``delete_config()`` メソッドのみが必要になります。このメソッドは引数を取らず、チェックモードを処理します。" - -#~ msgid "To have the module exit, call the ACIModule method ``exit_json()``. This method automatically takes care of returning the common return values for you." -#~ msgstr "モジュールを終了するには、ACIModule メソッド ``exit_json()`` を呼び出します。このメソッドは、一般的な戻り値を返すことを自動的に行います。" - -#~ msgid "Testing ACI library functions" -#~ msgstr "ACI ライブラリー関数のテスト" - -#~ msgid "You can test your ``construct_url()`` and ``payload()`` arguments without accessing APIC hardware by using the following python script:" -#~ msgstr "以下の python スクリプトを使用して、APIC ハードウェアにアクセスせずに ``construct_url()`` 引数および ``payload()`` 引数をテストすることができます。" - -#~ msgid "This will result in:" -#~ msgstr "これにより、以下が生成されます。" - -#~ msgid "Testing for sanity checks" -#~ msgstr "健全性チェックのテスト" - -#~ msgid "For legacy versions of ansible, you can run from your fork something like:" -#~ msgstr "Ansible のレガシーバージョンでは、次のようなフォークから実行できます。" - -#~ msgid "Meanwhile, the ACI modules have moved into a collection. Please refer to the links below, which provide detailed guidance how to setup your environment and test the collection." -#~ msgstr "ACI モジュールはコレクションに移動しました。以下のリンクを参照してください。環境を設定してコレクションをテストする方法の詳細なガイダンスが記載されています。" - -#~ msgid "Information how to setup your environment to contribute to collections" -#~ msgstr "環境を設定してコレクションに貢献する方法" - -#~ msgid "Information on how to build sanity tests." -#~ msgstr "健全性テストを構築する方法に関する情報" - -#~ msgid "You can run this:" -#~ msgstr "以下を実行できます。" - -#~ msgid "You may need to add ``--python 2.7`` or ``--python 3.6`` in order to use the correct python version for performing tests." -#~ msgstr "テストの実行に適切な python バージョンを使用するには、``--python 2.7`` または ``--python 3.6`` を追加しないといけない場合があります。" - -#~ msgid "You may want to edit the used inventory at *test/integration/inventory.networking* and add something like:" -#~ msgstr "*test/integration/inventory.networking* で使用されたインベントリーを編集し、以下のように追加することもできます。" - -#~ msgid "Information on how to build integration tests." -#~ msgstr "統合テストの構築方法に関する情報。" - -#~ msgid "Testing for test coverage" -#~ msgstr "テストカバレージのテスト" - -#~ msgid "Add the following to the new playbook file::" -#~ msgstr "以下を新しい Playbook ファイルに追加します。" - -#~ msgid "At present, the Ansiballz Framework cannot determine whether an import should be included if it is a relative import. Always use an absolute import that has :py:mod:`ansible.module_utils` in it to allow Ansiballz to determine that the file should be included." -#~ msgstr "現状、Aweraiballz Framework は、相対インポートの場合にインポートを含める必要があるかどうかを判別できません。常に、その中に :py:mod:`ansible.module_utils` がある絶対インポートを使用して、このファイルを同梱する必要があると判断することができます。" - -#~ msgid "Boolean. Set to True whenever a parameter in a task or play specifies ``no_log``. Any module that calls :py:meth:`AnsibleModule.log` handles this automatically. If a module implements its own logging then it needs to check this value. To access in a module, instantiate an ``AnsibleModule`` and then check the value of :attr:`AnsibleModule.no_log`." -#~ msgstr "ブール値。タスクまたはプレイのパラメーターを ``no_log`` に指定した場合は常に True に設定します。:py:meth:`AnsibleModule.log` を呼び出すモジュールが自動的にこれを処理します。モジュールがその独自のロギングを実装した場合は、この値を確認する必要があります。モジュールにアクセスするには、``AnsibleModule`` をインスタンス化して、:attr:`AnsibleModule.no_log` の値を確認します。" - -#~ msgid "Boolean. Turns more verbose logging on or off and turns on logging of external commands that the module executes. If a module uses :py:meth:`AnsibleModule.debug` rather than :py:meth:`AnsibleModule.log` then the messages are only logged if ``_ansible_debug`` is set to ``True``. To set, add ``debug: True`` to :file:`ansible.cfg` or set the environment variable :envvar:`ANSIBLE_DEBUG`. To access in a module, instantiate an ``AnsibleModule`` and access :attr:`AnsibleModule._debug`." -#~ msgstr "ブール値。詳細なロギングをオンまたはオフにし、モジュールが実行する外部コマンドのロギングを有効にします。モジュールが :py:meth:`AnsibleModule.log` ではなく :py:meth:`AnsibleModule.debug` を使用する場合は、``_ansible_debug`` が ``True`` に設定されている場合にのみメッセージがログに記録されます。設定するには、``debug: True`` を :file:`ansible.cfg` に追加するか、環境変数 :envvar:`ANSIBLE_DEBUG` を設定します。モジュールにアクセスするには、``AnsibleModule`` をインスタンス化し、:attr:`AnsibleModule._debug` にアクセスします。" - -#~ msgid "Boolean. If a module supports it, tells the module to show a unified diff of changes to be made to templated files. To set, pass the ``--diff`` command line option. To access in a module, instantiate an `AnsibleModule` and access :attr:`AnsibleModule._diff`." -#~ msgstr "ブール値。モジュールがサポートする場合は、モジュールに対し、テンプレート化されたファイルに加えられた変更の差異を統合するようにモジュールに指示します。設定するには、``--diff`` コマンドラインオプションを渡します。モジュールにアクセスするには、`AnsibleModule` をインスタンス化して、:attr:`AnsibleModule._diff` にアクセスしてください。" - -#~ msgid "Unused. This value could be used for finer grained control over logging." -#~ msgstr "未使用。この値は、ログをより細かく制御するために使用できます。" - -#~ msgid "List. Names of filesystems which should have a special SELinux context. They are used by the `AnsibleModule` methods which operate on files (changing attributes, moving, and copying). To set, add a comma separated string of filesystem names in :file:`ansible.cfg`:" -#~ msgstr "一覧。特別な SELinux コンテキストを持つ必要があるファイルシステムの名前。名前はファイル (属性の変更、移動、コピー) で操作する `AnsibleModule` メソッドによって使用されます。設定するには、:file:`ansible.cfg` に、ファイル名のコンマ区切りの文字列を追加します。" - -#~ msgid "This replaces :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` from :ref:`module_replacer`. In module replacer it was a comma separated string of filesystem names. Under Ansiballz it's an actual list." -#~ msgstr "これにより、:ref:`module_replacer` の :attr:`ansible.module_utils.basic.SELINUX_SPECIAL_FS` を置き換えます。モジュール置換は、ファイル名のコンマ区切りの文字列でした。Ansiballz は、実際のリストになります。" - -#~ msgid "This parameter controls which syslog facility Ansible module logs to. To set, change the ``syslog_facility`` value in :file:`ansible.cfg`. Most modules should just use :meth:`AnsibleModule.log` which will then make use of this. If a module has to use this on its own, it should instantiate an `AnsibleModule` and then retrieve the name of the syslog facility from :attr:`AnsibleModule._syslog_facility`. The Ansiballz code is less hacky than the old :ref:`module_replacer` code:" -#~ msgstr "このパラメーターは、Ansible モジュールがどの syslog 機能にログを記録するかを制御します。設定するには、:file:`ansible.cfg` の ``syslog_facility`` の値を変更します。多くのモジュールは、これを利用する :meth:`AnsibleModule.log` のみを使用する必要があります。モジュールが独自にこれを使用する必要がある場合は、`AnsibleModule` をインスタンス化して、:attr:`AnsibleModule._syslog_facility` から syslog 機能の名前を取得する必要があります。Ansiballz コードは古い :ref:`module_replacer` コードよりもハッキングされません。" - -#~ msgid "This parameter passes the version of Ansible that runs the module. To access it, a module should instantiate an `AnsibleModule` and then retrieve it from :attr:`AnsibleModule.ansible_version`. This replaces :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` from :ref:`module_replacer`." -#~ msgstr "このパラメーターは、モジュールを実行する Ansible のバージョンを渡します。これにアクセスするために、モジュールは `AnsibleModule` をインスタンス化し、:attr:`AnsibleModule.ansible_version` から取得する必要があります。これは、:ref:`module_replacer` の :attr:`ansible.module_utils.basic.ANSIBLE_VERSION` を置き換えます。" - -#~ msgid "Guidelines for Ansible Amazon AWS module development" -#~ msgstr "Ansible Amazon AWS モジュール開発のガイドライン" - -#~ msgid "This guide has moved to :ref:`ansible_collections.amazon.aws.docsite.dev_guide_intro`." -#~ msgstr "このガイドは :ref:`ansible_collections.amazon.aws.docsite.dev_guide_intro` に移動しました。" - -#~ msgid "OpenStack Ansible Modules" -#~ msgstr "OpenStack Ansible モジュール" - -#~ msgid "Please see the `OpenStack guidelines `_, for further information." -#~ msgstr "詳細は、`OpenStack ガイドライン `_ を参照してください。" - -#~ msgid "oVirt Ansible Modules" -#~ msgstr "oVirt Ansible モジュール" - -#~ msgid "Guidelines for VMware module development" -#~ msgstr "VMware モジュール開発のガイドライン" - -#~ msgid "This guide has moved to :ref:`ansible_collections.community.vmware.docsite.vmware_ansible_devguide`." -#~ msgstr "このガイドは :ref:`ansible_collections.community.vmware.docsite.vmware_ansible_devguide` に移動しました。" - -#~ msgid "Guidelines for VMware REST module development" -#~ msgstr "VMware REST モジュール開発のガイドライン" - -#~ msgid "This guide has moved to :ref:`ansible_collections.vmware.vmware_rest.docsite.vmware_rest_devguide`." -#~ msgstr "このガイドは :ref:`ansible_collections.vmware.vmware_rest.docsite.vmware_rest_devguide` に移動しました。" - -#~ msgid "Test python code against a variety of Python versions." -#~ msgstr "さまざまな Python バージョンに対して python コードをテストします。" - -#~ msgid "Example::" -#~ msgstr "例:" - -#~ msgid "See :ref:`testing_compile` for more information." -#~ msgstr "詳細は、「:ref:`testing_compile`」を参照してください。" - -#~ msgid "Ansible allows unchecked imports of some libraries from specific directories, listed at the bottom of this section. Import all other Python libraries in a try/except ImportError block to support sanity tests such as ``validate-modules`` and to allow Ansible to give better error messages to the user. To import a library in a try/except ImportError block:" -#~ msgstr "Ansible では、このセクションの下部に記載されている特定のディレクトリーから、いくつかのライブラリーを確認せずにインポートすることができます。``validate-modules`` などの健全性テストをサポートし、Ansible がユーザーに適切なエラーメッセージを表示できるようにするため、try/except ImportError ブロックで他のすべての Python ライブラリーをインポートします。try/except ImportError ブロックでライブラリをインポートするには、次を行います。" - -#~ msgid "See :ref:`testing_pep8` for more information." -#~ msgstr "詳細は、「:ref:`testing_pep8`」を参照してください。" - -#~ msgid "Compile tests check source files for valid syntax on all supported python versions:" -#~ msgstr "コンパイルテストでは、サポートされているすべての python バージョンで、ソースファイルの構文が有効かどうかを確認します。" - -#~ msgid "2.4 (Ansible 2.3 only)" -#~ msgstr "2.4 (Ansible 2.3 のみ)" - -#~ msgid "2.6" -#~ msgstr "2.6" - -#~ msgid "NOTE: In Ansible 2.4 and earlier the compile test was provided by a dedicated sub-command ``ansible-test compile`` instead of a sanity test using ``ansible-test sanity --test compile``." -#~ msgstr "注記: Ansible 2.4 以前では、``ansible-test sanity --test compile`` を使用する健全性テストの代わりに、コンパイルテストが専用のサブコマンド ``ansible-test compile`` によって提供されていました。" - -#~ msgid "Running compile tests locally" -#~ msgstr "ローカルでのコンパイルテストの実行" - -#~ msgid "Compile tests can be run across the whole code base by doing:" -#~ msgstr "コンパイルテストを実行するには、次のように、コードベース全体でテストを実行できます。" - -#~ msgid "For advanced usage see the help:" -#~ msgstr "高度な使用方法は、ヘルプを参照してください。" - -#~ msgid "``ansible-test`` has a number of dependencies , for ``compile`` tests we suggest running the tests with ``--local``, which is the default" -#~ msgstr "``ansible-test`` にはいくつかの依存関係があります。``compile`` テストでは、デフォルトである ``--local`` を使用してテストを実行することが推奨されます。" - -#~ msgid "The dependencies can be installed using the ``--requirements`` argument. For example:" -#~ msgstr "依存関係は、``--requirements`` 引数を使用してインストールできます。以下に例を示します。" - -#~ msgid "The full list of requirements can be found at `test/lib/ansible_test/_data/requirements `_. Requirements files are named after their respective commands. See also the `constraints `_ applicable to all commands." -#~ msgstr "要件の一覧は `test/lib/ansible_test/_data/requirements `_ に記載されています。要件ファイルには、各コマンドにちなんで名前が付けられています。全コマンドに適用される `制約 `_ も参照してください。" - -#~ msgid "Extending compile tests" -#~ msgstr "コンパイルテストの拡張" - -#~ msgid "If you believe changes are needed to the compile tests please add a comment on the `Testing Working Group Agenda `_ so it can be discussed." -#~ msgstr "コンパイルテストに変更が必要な場合は、`Testing Working Group Agenda `_ にコメントを追加してください。その内容について話し合うことができます。" - -#~ msgid "Legacy Cloud Tests" -#~ msgstr "レガシーのクラウドテスト" - -#~ msgid "Some of the cloud tests run as normal integration tests, and others run as legacy tests; see the :ref:`testing_integration_legacy` page for more information." -#~ msgstr "一部のクラウドテストは通常の統合テストとして実行し、その他はレガシーテストとして実行します。詳細は、「:ref:`testing_integration_legacy`」のドキュメントを参照してください。" - -#~ msgid "Testing using the Legacy Integration system" -#~ msgstr "レガシー統合システムを使用したテスト" - -#~ msgid "This page details how to run the integration tests that haven't been ported to the new ``ansible-test`` framework." -#~ msgstr "このページでは、新しい ``ansible-test`` フレームワークに移植されていない統合テストの実行方法を説明します。" - -#~ msgid "The following areas are still tested using the legacy ``make tests`` command:" -#~ msgstr "以下のエリアは、レガシーの ``make tests`` コマンドを使用してテストされます。" - -#~ msgid "amazon (some)" -#~ msgstr "amazon (一部)" - -#~ msgid "azure" -#~ msgstr "azure" - -#~ msgid "cloudflare" -#~ msgstr "cloudflare" - -#~ msgid "cloudscale" -#~ msgstr "cloudscale" - -#~ msgid "cloudstack" -#~ msgstr "cloudstack" - -#~ msgid "consul" -#~ msgstr "consul" - -#~ msgid "exoscale" -#~ msgstr "exoscale" - -#~ msgid "gce" -#~ msgstr "gce" - -#~ msgid "jenkins" -#~ msgstr "jenkins" - -#~ msgid "rackspace" -#~ msgstr "rackspace" - -#~ msgid "Over time the above list will be reduced as tests are ported to the ``ansible-test`` framework." -#~ msgstr "テストが ``ansible-test`` フレームワークに移植されると、上記のリストは徐々に少なくなっていきます。" - -#~ msgid "Running Cloud Tests" -#~ msgstr "クラウドテストの実行" - -#~ msgid "Cloud tests exercise capabilities of cloud modules (for example, ec2_key). These are not 'tests run in the cloud' so much as tests that use the cloud modules and are organized by cloud provider." -#~ msgstr "クラウドテストは、クラウドモジュール (ec2_key など) の機能を実行します。これらは、「クラウドで実行されるテスト」ではなく、クラウドモジュールを使用し、クラウドプロバイダーによって編成されたテストです。" - -#~ msgid "Some AWS tests may use environment variables. It is recommended to either unset any AWS environment variables( such as ``AWS_DEFAULT_PROFILE``, ``AWS_SECRET_ACCESS_KEY``, and so on) or be sure that the environment variables match the credentials provided in ``credentials.yml`` to ensure the tests run with consistency to their full capability on the expected account. See `AWS CLI docs `_ for information on creating a profile." -#~ msgstr "AWS テストによっては、環境変数を使用するものもあります。AWS 環境変数 (``AWS_DEFAULT_PROFILE``、``AWS_SECRET_ACCESS_KEY`` など) の設定を解除するか、環境変数が ``credentials.yml`` で提供される認証情報と一致することを確認して、予想されるアカウントの完全な機能に一貫性のあるテストが実行されるようにすることが推奨されます。プロファイルの作成に関する情報は、`AWS CLI ドキュメント `_ を参照してください。" - -#~ msgid "Subsets of tests may be run by ``#commenting`` out unnecessary roles in the appropriate playbook, such as ``test/integration/amazon.yml``." -#~ msgstr "テストのサブセットは、適切な Playbook の 不要なロールを ``#commenting`` でコメントアウトすることで実行できます (例: ``test/integration/amazon.yml``)。" - -#~ msgid "In order to run cloud tests, you must provide access credentials in a file named ``credentials.yml``. A sample credentials file named ``credentials.template`` is available for syntax help." -#~ msgstr "クラウドテストを実行するには、``credentials.yml`` という名前のファイルでアクセス認証情報を指定する必要があります。構文ヘルプには、``credentials.template`` と名前の付いたサンプル認証情報ファイルを利用できます。" - -#~ msgid "Provide cloud credentials:" -#~ msgstr "クラウド認証を提供します。" - -#~ msgid "In order to run some tests, you must provide access credentials in a file named ``credentials.yml``. A sample credentials file named ``credentials.template`` is available for syntax help." -#~ msgstr "いくつかのテストを実行するには、``credentials.yml`` という名前のファイルでアクセス認証情報を指定する必要があります。構文ヘルプには、``credentials.template`` と名前の付いたサンプル認証情報ファイルを利用できます。" - -#~ msgid "In order to run the tests in an AWS account ansible needs fairly wide ranging powers which can be provided to a dedicated user or temporary credentials using a specific policy configured in the AWS account." -#~ msgstr "AWS アカウントでテストを実行するには、Ansible に、AWS アカウントで設定された特定のポリシーを使用して、専用のユーザや一時的な認証情報に提供できる、かなり広範囲の権限が必要となります。" - -#~ msgid "testing-iam-policy.json.j2" -#~ msgstr "testing-iam-policy.json.j2" - -#~ msgid "The testing-iam-policy.json.j2 file contains a policy which can be given to the user running the tests to give close to minimum rights required to run the tests. Please note that this does not fully restrict the user; The user has wide privileges for viewing account definitions and is also able to manage some resources that are not related to testing (for example, AWS lambdas with different names) primarily due to the limitations of the Amazon ARN notation. At the very least the policy limits the user to one region, however tests should not be run in a primary production account in any case." -#~ msgstr "testing-iam-policy.json.j2 ファイルには、テストを実行するユーザーに付与するポリシーが含まれており、テストの実行に必要な最低限の権限に近いものを付与することができます。なお、これは完全な制限ではないため注意してください。このユーザーは、アカウント定義を閲覧する幅広い権限を持ち、主に Amazon ARN 表記の制限により、テストに関係のない一部のリソース (たとえば、異なる名前の AWS ラムダ) を管理することもできます。少なくとも、このポリシーではユーザーを 1 つのリージョンに限定していますが、いかなる場合でも、テストは実稼働環境のプライマリーアカウントで実行すべきではありません。" - -#~ msgid "The tests are invoked via a ``Makefile``." -#~ msgstr "テストは ``Makefile`` 経由で呼び出されます。" - -#~ msgid "If you haven't already got Ansible available use the local checkout by doing:" -#~ msgstr "Ansible がまだ利用可能でない場合は、以下の方法でローカルチェックアウトを使用します。" - -#~ msgid "Run the tests by doing:" -#~ msgstr "以下を実行してテストを実行します。" - -#~ msgid "Possible cost of running cloud tests" -#~ msgstr "クラウドテストにかかる可能性のあるコスト" - -#~ msgid "Running cloud integration tests will create and destroy cloud resources. Running these tests may result in additional fees associated with your cloud account. Care is taken to ensure that created resources are removed. However, it is advisable to inspect your AWS console to ensure no unexpected resources are running." -#~ msgstr "クラウド統合テストを実行すると、クラウドリソースが作成および破棄されます。このようなテストを実行すると、クラウドアカウントに関連する追加料金が発生する可能性があります。作成されたリソースが確実に削除されるように注意が払われます。ただし、AWS コンソールを調べて、予期しないリソースが実行していないことを確認することが推奨されます。" - -#~ msgid "Run tests locally using ``ansible-test``" -#~ msgstr "``ansible-test`` を使用してテストをローカルで実行します。" - -#~ msgid "Extend" -#~ msgstr "拡張" - -#~ msgid "There are no special requirements for running ``ansible-test`` on Python 2.7 or later. The ``argparse`` package is required for Python 2.6. The requirements for each ``ansible-test`` command are covered later." -#~ msgstr "Python 2.7 以降には、``ansible-test`` を実行するための特別な要件がありません。Python 2.6 には ``argparse`` パッケージが必要です。各 ``ansible-test`` コマンドの要件は、後で説明します。" - -#~ msgid "Remote" -#~ msgstr "リモート" - -#~ msgid "Recommended for integration tests." -#~ msgstr "統合テストへ推奨事項" - -#~ msgid "See the `list of supported platforms and versions `_ for additional details." -#~ msgstr "詳細は、「`サポート対象のプラットフォームおよびバージョンの一覧 `_」を参照してください。" - -#~ msgid "Python program to help test or validate Ansible modules." -#~ msgstr "Ansible モジュールのテストまたは検証に役立つ Python プログラム。" - -#~ msgid "``validate-modules`` is one of the ``ansible-test`` Sanity Tests, see :ref:`testing_sanity` for more information." -#~ msgstr "``validate-modules`` は、健全性テスト ``ansible-test`` のいずれかです。詳細は、「:ref:`testing_sanity`」を参照してください。" - -#~ msgid "Originally developed by Matt Martz (@sivel)" -#~ msgstr "本プログラムは、元々 Matt Martz (@sivel) 氏により開発されました。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po deleted file mode 100644 index 246e8494ff5..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po +++ /dev/null @@ -1,1088 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2019 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/galaxy/dev_guide.rst:5 -msgid "Galaxy Developer Guide" -msgstr "Galaxy 開発者ガイド" - -#: ../../rst/galaxy/dev_guide.rst:7 -msgid "You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formatted in pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections `. You can create roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. Taking this a step further, you can create collections which provide a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins." -msgstr "Galaxy でコレクションとロールをホストして、Ansible コミュニティーと共有できます。Galaxy コンテンツは、事前にパッケージ化された作業単位 (:ref:`ロール`、Galaxy 3.2 の新機能、:ref:`コレクション ` など) でフォーマットされます。インフラストラクチャーのプロビジョニング、アプリケーションのデプロイメント、および日常的に行うすべてのタスクのロールを作成できます。これをさらに一歩進めて、複数の Playbook、ロール、モジュール、およびプラグインを含む可能性のある自動化の包括的なパッケージを提供するコレクションを作成できます。" - -#: ../../rst/galaxy/dev_guide.rst:17 -msgid "Creating collections for Galaxy" -msgstr "Galaxy のコレクションの作成" - -#: ../../rst/galaxy/dev_guide.rst:19 -msgid "Collections are a distribution format for Ansible content. You can use collections to package and distribute playbooks, roles, modules, and plugins. You can publish and use collections through `Ansible Galaxy `_." -msgstr "コレクションは、Ansible コンテンツのディストリビューション形式です。コレクションを使用して、Playbook、ロール、モジュール、およびプラグインをパッケージ化および配布できます。`Ansible Galaxy `_ を介してコレクションを公開および使用できます。" - -#: ../../rst/galaxy/dev_guide.rst:22 -msgid "See :ref:`developing_collections` for details on how to create collections." -msgstr "コレクションの作成方法は「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/galaxy/dev_guide.rst:28 -msgid "Creating roles for Galaxy" -msgstr "Galaxy のロールの作成" - -#: ../../rst/galaxy/dev_guide.rst:30 -msgid "Use the ``init`` command to initialize the base structure of a new role, saving time on creating the various directories and main.yml files a role requires" -msgstr "``init`` コマンドを使用して新規ロールの基本構造を初期化し、ロールに必要なさまざまなディレクトリーおよび main.yml ファイルを作成する際の時間を短縮します。" - -#: ../../rst/galaxy/dev_guide.rst:36 -msgid "The above will create the following directory structure in the current working directory:" -msgstr "上記により、現在の作業ディレクトリーに以下のディレクトリー構造が作成されます。" - -#: ../../rst/galaxy/dev_guide.rst:57 -msgid "If you want to create a repository for the role, the repository root should be `role_name`." -msgstr "ロールのリポジトリーを作成する場合、リポジトリーのルートは `role_name` である必要があります。" - -#: ../../rst/galaxy/dev_guide.rst:60 -msgid "Force" -msgstr "Force" - -#: ../../rst/galaxy/dev_guide.rst:62 -msgid "If a directory matching the name of the role already exists in the current working directory, the init command will result in an error. To ignore the error use the ``--force`` option. Force will create the above subdirectories and files, replacing anything that matches." -msgstr "現在の作業ディレクトリーにすでにロール名に一致するディレクトリーが存在する場合は、init コマンドによりエラーが発生します。エラーを無視するには、``--force`` オプションを使用します。強制的に、上記のサブディレクトリーとファイルを作成し、一致するものをすべて置き換えます。" - -#: ../../rst/galaxy/dev_guide.rst:66 -msgid "Container enabled" -msgstr "有効なコンテナー" - -#: ../../rst/galaxy/dev_guide.rst:68 -msgid "If you are creating a Container Enabled role, pass ``--type container`` to ``ansible-galaxy init``. This will create the same directory structure as above, but populate it with default files appropriate for a Container Enabled role. For instance, the README.md has a slightly different structure, the *.travis.yml* file tests the role using `Ansible Container `_, and the meta directory includes a *container.yml* file." -msgstr "Container Enabled ロールを作成する場合は、``--type container`` を ``ansible-galaxy init`` に渡します。これにより、上記のものと同じディレクトリー構造が作成されますが、これを Container Enabled ロールに適したデフォルトファイルで追加します。たとえば、README.md には若干異なる構造があり、*.travis.yml* ファイルでは、`Ansible Container `_ を使用してロールをテストします。また、メタディレクトリーには *container.yml* ファイルが含まれます。" - -#: ../../rst/galaxy/dev_guide.rst:73 -msgid "Using a custom role skeleton" -msgstr "カスタムロールのスケルトンの使用" - -#: ../../rst/galaxy/dev_guide.rst:75 -msgid "A custom role skeleton directory can be supplied as follows:" -msgstr "カスタムロールのスケルトンディレクトリーは、以下のように指定できます。" - -#: ../../rst/galaxy/dev_guide.rst:81 -msgid "When a skeleton is provided, init will:" -msgstr "スケルトンを指定すると init は以下のことを行います。" - -#: ../../rst/galaxy/dev_guide.rst:83 -msgid "copy all files and directories from the skeleton to the new role" -msgstr "すべてのファイルおよびディレクトリーをスケルトンから新しいロールにコピーします。" - -#: ../../rst/galaxy/dev_guide.rst:84 -msgid "any .j2 files found outside of a templates folder will be rendered as templates. The only useful variable at the moment is role_name" -msgstr "テンプレートディレクトリーの外部で見つかったすべての .j2 ファイルはテンプレートとしてレンダリングされます。現在便利な変数は role_name です" - -#: ../../rst/galaxy/dev_guide.rst:85 -msgid "The .git folder and any .git_keep files will not be copied" -msgstr ".git ディレクトリーおよび .git_keep ファイルはコピーされません。" - -#: ../../rst/galaxy/dev_guide.rst:87 -msgid "Alternatively, the role_skeleton and ignoring of files can be configured via ansible.cfg" -msgstr "または、role_skeleton とファイルの無視は、ansible.cfgで設定できます" - -#: ../../rst/galaxy/dev_guide.rst:96 -msgid "Authenticate with Galaxy" -msgstr "Galaxy での認証" - -#: ../../rst/galaxy/dev_guide.rst:98 -msgid "Using the ``import``, ``delete`` and ``setup`` commands to manage your roles on the Galaxy website requires authentication in the form of an API key, you must create an account on the Galaxy website." -msgstr "Galaxy Web サイトでロールを管理する ``import`` および ``delete``、``setup`` コマンドを使用するには、API キーの形式での認証が必要です。Galaxy Web サイトでアカウントを作成する必要があります。" - -#: ../../rst/galaxy/dev_guide.rst:100 -msgid "Log in to the Galaxy website and open the `Preferences `_ view." -msgstr "Galaxy の Web サイトにログインし、`Preferences ` _ ビューを開きます。" - -#: ../../rst/galaxy/dev_guide.rst:101 -msgid "Select **Show API key** and then copy it." -msgstr "**Show API key** を選択してコピーします。" - -#: ../../rst/galaxy/dev_guide.rst:103 -msgid "Save your token in the path set in the :ref:`GALAXY_TOKEN_PATH`." -msgstr ":ref:`GALAXY_TOKEN_PATH` で設定したパスにトークンを保存します。" - -#: ../../rst/galaxy/dev_guide.rst:107 -msgid "Import a role" -msgstr "ロールのインポート" - -#: ../../rst/galaxy/dev_guide.rst:109 -msgid "The ``import`` command requires that you first authenticate using the ``login`` command. Once authenticated you can import any GitHub repository that you own or have been granted access." -msgstr "``import`` コマンドでは、最初に ``login`` コマンドを使用して認証する必要があります。認証されると、所有またはアクセスが付与された GitHub リポジトリーをすべてインポートできます。" - -#: ../../rst/galaxy/dev_guide.rst:111 -msgid "Use the following to import to role:" -msgstr "以下を使用してロールにインポートします。" - -#: ../../rst/galaxy/dev_guide.rst:117 -msgid "By default the command will wait for Galaxy to complete the import process, displaying the results as the import progresses:" -msgstr "デフォルトでは、コマンドは Galaxy がインポートプロセスを完了するまで待機し、インポートが進行するにつれて結果を表示します。" - -#: ../../rst/galaxy/dev_guide.rst:135 -msgid "Branch" -msgstr "ブランチ" - -#: ../../rst/galaxy/dev_guide.rst:137 -msgid "Use the ``--branch`` option to import a specific branch. If not specified, the default branch for the repo will be used." -msgstr "特定のブランチをインポートするには、``--branch`` オプションを使用します。指定しない場合は、リポジトリーのデフォルトブランチが使用されます。" - -#: ../../rst/galaxy/dev_guide.rst:140 -msgid "Role name" -msgstr "ロール名" - -#: ../../rst/galaxy/dev_guide.rst:142 -msgid "By default the name given to the role will be derived from the GitHub repository name. However, you can use the ``--role-name`` option to override this and set the name." -msgstr "デフォルトでは、ロールに指定された名前は GitHub リポジトリー名から派生しますが、``--role-name`` オプションを使用してこれを上書きして名前を設定できます。" - -#: ../../rst/galaxy/dev_guide.rst:145 -msgid "No wait" -msgstr "待機なし" - -#: ../../rst/galaxy/dev_guide.rst:147 -msgid "If the ``--no-wait`` option is present, the command will not wait for results. Results of the most recent import for any of your roles is available on the Galaxy web site by visiting *My Imports*." -msgstr "``--no-wait`` オプションが存在する場合は、結果を待ちません。すべてのロールに対する最新のインポートの結果は、*My Imports* に移動して Galaxy Web サイトで利用できるようになります。" - -#: ../../rst/galaxy/dev_guide.rst:150 -msgid "Delete a role" -msgstr "ロールの削除" - -#: ../../rst/galaxy/dev_guide.rst:152 -msgid "The ``delete`` command requires that you first authenticate using the ``login`` command. Once authenticated you can remove a role from the Galaxy web site. You are only allowed to remove roles where you have access to the repository in GitHub." -msgstr "``delete`` コマンドでは、最初に ``login`` コマンドを使用して認証する必要があります。認証されると、Galaxy Web サイトからロールを削除できます。GitHub のリポジトリーにアクセスできるロールのみを削除することができます。" - -#: ../../rst/galaxy/dev_guide.rst:154 -msgid "Use the following to delete a role:" -msgstr "ロールを削除するには、以下を使用します。" - -#: ../../rst/galaxy/dev_guide.rst:160 -msgid "This only removes the role from Galaxy. It does not remove or alter the actual GitHub repository." -msgstr "これにより、Galaxy からロールのみが削除されます。実際の GitHub リポジトリーを削除したり、変更したりしません。" - -#: ../../rst/galaxy/dev_guide.rst:164 -msgid "Travis integrations" -msgstr "Travis 統合" - -#: ../../rst/galaxy/dev_guide.rst:166 -msgid "You can create an integration or connection between a role in Galaxy and `Travis `_. Once the connection is established, a build in Travis will automatically trigger an import in Galaxy, updating the search index with the latest information about the role." -msgstr "Galaxy と `Travis `_ のロール間の統合またはコネクションを作成できます。コネクションが確立されると、Travis のビルドが自動的に Galaxy でインポートを発生させ、ロールに関する最新情報で検索インデックスを更新します。" - -#: ../../rst/galaxy/dev_guide.rst:169 -msgid "You create the integration using the ``setup`` command, but before an integration can be created, you must first authenticate using the ``login`` command; you will also need an account in Travis, and your Travis token. Once you're ready, use the following command to create the integration:" -msgstr "``setup`` コマンドを使用して統合を作成しますが、統合を作成する前に、最初に ``login`` コマンドを使用して認証する必要があります。Travis および Travis トークンにもアカウントが必要になります。準備が整ったら、以下のコマンドを使用して統合を作成します。" - -#: ../../rst/galaxy/dev_guide.rst:176 -msgid "The setup command requires your Travis token, however the token is not stored in Galaxy. It is used along with the GitHub username and repo to create a hash as described in `the Travis documentation `_. The hash is stored in Galaxy and used to verify notifications received from Travis." -msgstr "setup コマンドには Travis トークンが必要ですが、トークンは Galaxy に保存されていません。これは、`the Travis documentation `_ で説明されているように、GitHub ユーザー名およびリポジトリーとともに使用されます。ハッシュは Galaxy に格納され、Travis から受信した通知の検証に使用されます。" - -#: ../../rst/galaxy/dev_guide.rst:179 -msgid "The setup command enables Galaxy to respond to notifications. To configure Travis to run a build on your repository and send a notification, follow the `Travis getting started guide `_." -msgstr "setup コマンドを使用すると、Galaxy が通知に応答します。Travis がリポジトリーでビルドを実行し、通知を送信するように設定するには、`Travis getting started guide `_ に従います。" - -#: ../../rst/galaxy/dev_guide.rst:182 -msgid "To instruct Travis to notify Galaxy when a build completes, add the following to your .travis.yml file:" -msgstr "ビルドの完了時に Galaxy に通知するように Travis に指示するには、.travis.yml ファイルに以下を追加します。" - -#: ../../rst/galaxy/dev_guide.rst:191 -msgid "List Travis integrations" -msgstr "Travis 統合の一覧表示" - -#: ../../rst/galaxy/dev_guide.rst:193 -msgid "Use the ``--list`` option to display your Travis integrations:" -msgstr "``--list`` オプションを使用して、Travis 統合を表示します。" - -#: ../../rst/galaxy/dev_guide.rst:207 -msgid "Remove Travis integrations" -msgstr "Travis 統合の削除" - -#: ../../rst/galaxy/dev_guide.rst:209 -msgid "Use the ``--remove`` option to disable and remove a Travis integration:" -msgstr "``--remove`` オプションを使用して、Travis 統合を無効化および削除します。" - -#: ../../rst/galaxy/dev_guide.rst:215 -msgid "Provide the ID of the integration to be disabled. You can find the ID by using the ``--list`` option." -msgstr "無効にする統合の ID を指定します。``--list`` オプションを使用して ID を検索できます。" - -#: ../../rst/galaxy/dev_guide.rst:219 ../../rst/galaxy/user_guide.rst:491 -msgid ":ref:`collections`" -msgstr ":ref:`collections`" - -#: ../../rst/galaxy/dev_guide.rst:220 ../../rst/galaxy/user_guide.rst:492 -msgid "Shareable collections of modules, playbooks and roles" -msgstr "モジュール、Playbook、およびロールの共有可能なコレクション" - -#: ../../rst/galaxy/dev_guide.rst:221 ../../rst/galaxy/user_guide.rst:493 -msgid ":ref:`playbooks_reuse_roles`" -msgstr ":ref:`playbooks_reuse_roles`" - -#: ../../rst/galaxy/dev_guide.rst:222 -msgid "All about ansible roles" -msgstr "Ansible ロールに関するすべて" - -#: ../../rst/galaxy/dev_guide.rst:223 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/galaxy/dev_guide.rst:224 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/galaxy/dev_guide.rst:225 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/galaxy/dev_guide.rst:226 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/galaxy/user_guide.rst:6 -msgid "Galaxy User Guide" -msgstr "Galaxy ユーザーガイド" - -#: ../../rst/galaxy/user_guide.rst:8 -msgid ":dfn:`Ansible Galaxy` refers to the `Galaxy `_ website, a free site for finding, downloading, and sharing community developed roles." -msgstr ":dfn:`Ansible Galaxy` は `Galaxy `_ の Web サイトを参照します。これは、コミュニティーが開発したロールを検索し、ダウンロードし、共有するための無料サイトです。" - -#: ../../rst/galaxy/user_guide.rst:10 -msgid "Use Galaxy to jump-start your automation project with great content from the Ansible community. Galaxy provides pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections ` You can find roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. The collection format provides a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins." -msgstr "Galaxy を使用して、Ansible コミュニティーの優れたコンテンツで自動化プロジェクトを活性化させます。Galaxy は、事前にパッケージ化された作業単位 (:ref:`ロール `、Galaxy 3.2 の新機能、:ref:`コレクション ` など) でフォーマットされます。インフラストラクチャーのプロビジョニング、アプリケーションのデプロイメント、および日常的に行うすべてのタスクのロールを検索できます。コレクション形式は、複数の Playbook、ロール、モジュール、プラグインを含む可能性のある自動化の包括的なパッケージを提供します。" - -#: ../../rst/galaxy/user_guide.rst:19 -msgid "Finding collections on Galaxy" -msgstr "Galaxy でコレクションの検索" - -#: ../../rst/galaxy/user_guide.rst:21 -msgid "To find collections on Galaxy:" -msgstr "Galaxy でコレクションを検索するには、以下を行います。" - -#: ../../rst/galaxy/user_guide.rst:23 -msgid "Click the :guilabel:`Search` icon in the left-hand navigation." -msgstr "左側のナビゲーションにある :guilabel:`Search` アイコンをクリックします。" - -#: ../../rst/galaxy/user_guide.rst:24 -msgid "Set the filter to *collection*." -msgstr "フィルターを *collection* に設定します。" - -#: ../../rst/galaxy/user_guide.rst:25 -msgid "Set other filters and press :guilabel:`enter`." -msgstr "他のフィルターを設定し、:guilabel:`enter` を押します。" - -#: ../../rst/galaxy/user_guide.rst:27 -msgid "Galaxy presents a list of collections that match your search criteria." -msgstr "Galaxy は、検索条件に一致するコレクションのリストを表示します。" - -#: ../../rst/galaxy/user_guide.rst:33 -msgid "Installing collections" -msgstr "コレクションのインストール" - -#: ../../rst/galaxy/user_guide.rst:37 -msgid "Installing a collection from Galaxy" -msgstr "Galaxy からコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections.txt:3 -msgid "By default, ``ansible-galaxy collection install`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). You do not need any further configuration." -msgstr "デフォルトでは、``ansible-galaxy collection install`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。追加設定は必要ありません。" - -#: ../../rst/shared_snippets/installing_collections.txt:7 -msgid "See :ref:`Configuring the ansible-galaxy client ` if you are using any other Galaxy server, such as Red Hat Automation Hub." -msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 `」を参照してください。" - -#: ../../rst/shared_snippets/installing_collections.txt:9 -msgid "To install a collection hosted in Galaxy:" -msgstr "Galaxy でホストされるコレクションをインストールするには、以下を実行します。" - -#: ../../rst/shared_snippets/installing_collections.txt:15 -msgid "To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option:" -msgstr "コレクションを Galaxy サーバーから利用可能な最新バージョンにアップグレードするには、``--upgrade`` オプションを使用します。" - -#: ../../rst/shared_snippets/installing_collections.txt:21 -msgid "You can also directly use the tarball from your build:" -msgstr "ビルドから tarball を直接使用することもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:27 -msgid "You can build and install a collection from a local source directory. The ``ansible-galaxy`` utility builds the collection using the ``MANIFEST.json`` or ``galaxy.yml`` metadata in the directory." -msgstr "ローカルソースディレクトリーからコレクションを構築してインストールできます。``ansible-galaxy`` ユーティリティーは、ディレクトリー内の ``MANIFEST.json`` または ``galaxy.yml`` メタデータを使用してコレクションを構築します。" - -#: ../../rst/shared_snippets/installing_collections.txt:34 -msgid "You can also install multiple collections in a namespace directory." -msgstr "名前空間ディレクトリーに複数のコレクションをインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:51 -msgid "The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the parent directory is already in a folder called ``ansible_collections``." -msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したものに、パス ``ansible_collections`` を自動的に追加します。" - -#: ../../rst/shared_snippets/installing_collections.txt:55 -msgid "When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``" -msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は、:ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。" - -#: ../../rst/shared_snippets/installing_collections.txt:59 -msgid "You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure." -msgstr "また、``collections/ansible_collections/`` ディレクトリー構造の下で、コレクションを現在の Playbook の横に維持することもできます。" - -#: ../../rst/shared_snippets/installing_collections.txt:71 -msgid "See :ref:`collection_structure` for details on the collection directory structure." -msgstr "コレクションディレクトリー構造の詳細は、「:ref:`collection_structure`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:44 -msgid "Downloading a collection from Automation Hub" -msgstr "Automation Hub からのコレクションのダウンロード" - -#: ../../rst/galaxy/user_guide.rst:46 -msgid "You can download collections from Automation Hub at the command line. Automation Hub content is available to subscribers only, so you must download an API token and configure your local environment to provide it before you can you download collections. To download a collection from Automation Hub with the ``ansible-galaxy`` command:" -msgstr "コマンドラインで Automation Hub からコレクションをダウンロードできます。Automation Hub コンテンツは、サブスクライバーのみで利用できるため、コレクションをダウンロードする前に API トークンをダウンロードし、ローカル環境を設定して提供する必要があります。``ansible-galaxy`` コマンドを使用して Automation Hub からコレクションをダウンロードするには、以下を実行します。" - -#: ../../rst/galaxy/user_guide.rst:48 -msgid "Get your Automation Hub API token. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click :guilabel:`Load token` from the version dropdown to copy your API token." -msgstr "Automation Hub API トークンを取得します。https://cloud.redhat.com/ansible/automation-hub/token/ に移動し、バージョンドロップダウンの :guilabel:`Load token` をクリックして API トークンをコピーします。" - -#: ../../rst/galaxy/user_guide.rst:49 -msgid "Configure Red Hat Automation Hub server in the ``server_list`` option under the ``[galaxy]`` section in your :file:`ansible.cfg` file." -msgstr ":file:`ansible.cfg` ファイルの ``[galaxy]`` セクションで、``server_list`` オプションで Red Hat Automation Hub サーバーを設定します。" - -#: ../../rst/galaxy/user_guide.rst:61 -msgid "Download the collection hosted in Automation Hub." -msgstr "Automation Hub でホストされるコレクションをダウンロードします。" - -#: ../../rst/galaxy/user_guide.rst:68 -msgid "`Getting started with Automation Hub `_" -msgstr "`Getting started with Automation Hub `_" - -#: ../../rst/galaxy/user_guide.rst:69 -msgid "An introduction to Automation Hub" -msgstr "Automation Hub の概要" - -#: ../../rst/galaxy/user_guide.rst:72 -msgid "Installing an older version of a collection" -msgstr "古いバージョンのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_older_collection.txt:2 -msgid "You can only have one version of a collection installed at a time. By default ``ansible-galaxy`` installs the latest available version. If you want to install a specific version, you can add a version range identifier. For example, to install the 1.0.0-beta.1 version of the collection:" -msgstr "一度にインストールするコレクションのバージョンは 1 つだけです。デフォルトでは、``ansible-galaxy`` により利用可能な最新バージョンがインストールされます。特定のバージョンをインストールする場合は、バージョン範囲識別子を追加できます。たとえば、コレクションの 1.0.0-beta.1 バージョンをインストールするには、以下を実行します。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:8 -msgid "You can specify multiple range identifiers separated by ``,``. Use single quotes so the shell passes the entire command, including ``>``, ``!``, and other operators, along. For example, to install the most recent version that is greater than or equal to 1.0.0 and less than 2.0.0:" -msgstr "``,`` で区切って複数の範囲識別子を指定できます。シェルが、``>``、``!``、およびその他の演算子を含むコマンド全体を渡すように、一重引用符を使用します。たとえば、1.0.0 以上 2.0.0 未満の最新バージョンをインストールするには、次を実行します。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:14 -msgid "Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers:" -msgstr "Ansible は、指定する範囲識別子を満たす最新バージョンを常にインストールします。以下の範囲識別子を使用できます。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:16 -msgid "``*``: The most recent version. This is the default." -msgstr "``*``: 最新バージョンです。これがデフォルトです。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:17 -msgid "``!=``: Not equal to the version specified." -msgstr "``!=``: 指定されたバージョンと同等ではありません。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:18 -msgid "``==``: Exactly the version specified." -msgstr "``==``: 指定されたバージョンそのものになります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:19 -msgid "``>=``: Greater than or equal to the version specified." -msgstr "``>=``: 指定されたバージョン以上になります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:20 -msgid "``>``: Greater than the version specified." -msgstr "``>``: 指定されたバージョンよりも大きくなります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:21 -msgid "``<=``: Less than or equal to the version specified." -msgstr "``<=``: 指定されたバージョン以下になります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:22 -msgid "``<``: Less than the version specified." -msgstr "``<``: 指定されたバージョンよりも小さくなります。" - -#: ../../rst/shared_snippets/installing_older_collection.txt:25 -msgid "By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly." -msgstr "デフォルトでは、``ansible-galaxy`` はリリース前のバージョンを無視します。リリース前のバージョンをインストールするには、``==`` 範囲識別子を使用して明示的に要求する必要があります。" - -#: ../../rst/galaxy/user_guide.rst:77 -msgid "Install multiple collections with a requirements file" -msgstr "要件ファイルを使用した複数のコレクションのインストール" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:2 -msgid "You can set up a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:" -msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールできます。このファイルは、以下の形式の YAML ファイルです。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:16 -msgid "You can specify the following keys for each collection entry:" -msgstr "各コレクションエントリーに以下のキーを指定できます。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:18 -msgid "``name``" -msgstr "``name``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:19 -msgid "``version``" -msgstr "``version``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:20 -msgid "``signatures``" -msgstr "``signatures``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:21 -msgid "``source``" -msgstr "``source``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:22 -msgid "``type``" -msgstr "``type``" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:24 -msgid "The ``version`` key uses the same range identifier format documented in :ref:`collections_older_version`." -msgstr "``version`` キーは、:ref:`collections_older_version` に記載されているものと同じ範囲識別子形式を使用します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:26 -msgid "The ``signatures`` key accepts a list of signature sources that are used to supplement those found on the Galaxy server during collection installation and ``ansible-galaxy collection verify``. Signature sources should be URIs that contain the detached signature. The ``--keyring`` CLI option must be provided if signatures are specified." -msgstr "``signatures`` キーは、コレクションのインストール時および``ansible-galaxy collection verify``時に Galaxy サーバーで見つけられたものを補足するために使用される署名ソースの一覧を受け入れます。署名ソースは、デタッチされた署名が含まれる URI である必要があります。署名が指定されている場合は、``--keyring`` CLI オプションを指定する必要があります。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:28 -msgid "Signatures are only used to verify collections on Galaxy servers. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files." -msgstr "署名は、Galaxy サーバーのコレクションを検証するためにのみ使用されます。ユーザーが提供した署名は、git リポジトリー、ソースディレクトリー、または URL/tar.gzファイルへのパスからインストールされたコレクションの検証には使用されません。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:40 -msgid "The ``type`` key can be set to ``file``, ``galaxy``, ``git``, ``url``, ``dir``, or ``subdirs``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection." -msgstr "``type`` キーは ``file``、``galaxy``、``git``、``url``、``dir``、または ``subdirs`` に設定できます。``type`` を省略すると、``name`` キーを使用してコレクションのソースを暗黙的に決定します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:42 -msgid "When you install a collection with ``type: git``, the ``version`` key can refer to a branch or to a `git commit-ish `_ object (commit or tag). For example:" -msgstr "``type: git`` でコレクションをインストールする場合、``version`` キーはブランチまたは `git commit-ish `_ オブジェクト（コミットまたはタグ）を参照できます。以下に例を示します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:51 -msgid "You can also add roles to a ``requirements.yml`` file, under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases." -msgstr "``roles``キーの下にある``requirements.yml``ファイルにロールを追加することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:68 -msgid "To install both roles and collections at the same time with one command, run the following:" -msgstr "1 つのコマンドで、ロールとコレクションを同時にインストールするには、以下のコマンドを実行します。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:74 -msgid "Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively." -msgstr "``ansible-galaxy collection install -r`` または ``ansible-galaxy role install -r`` を実行すると、それぞれコレクションまたはロールがインストールされます。" - -#: ../../rst/shared_snippets/installing_multiple_collections.txt:77 -msgid "Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would." -msgstr "カスタムコレクションまたはロールインストールパスを指定する場合、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。" - -#: ../../rst/galaxy/user_guide.rst:82 -msgid "Downloading a collection for offline use" -msgstr "オフラインで使用するコレクションのダウンロード" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:3 -msgid "To download the collection tarball from Galaxy for offline use:" -msgstr "オフラインで使用するために、コレクション tarball を Galaxy からダウンロードするには、以下を行います。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:5 -msgid "Navigate to the collection page." -msgstr "コレクションページに移動します。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:6 -msgid "Click on :guilabel:`Download tarball`." -msgstr ":guilabel:`Download tarball` をクリックします。" - -#: ../../rst/shared_snippets/download_tarball_collections.txt:8 -msgid "You may also need to manually download any dependent collections." -msgstr "また、依存するコレクションを手動でダウンロードする必要がある場合があります。" - -#: ../../rst/galaxy/user_guide.rst:87 -msgid "Installing a collection from source files" -msgstr "ソースファイルからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_file.rst:1 -msgid "Ansible can also install from a source directory in several ways:" -msgstr "Ansible は、複数の方法でソースディレクトリーからインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_file.rst:14 -msgid "Ansible can also install a collection collected with ``ansible-galaxy collection build`` or downloaded from Galaxy for offline use by specifying the output file directly:" -msgstr "出力ファイルを直接指定して、Ansible は``ansible-galaxy collection build`` で収集したコレクションまたは Galaxy からダウンロードしたコレクションをオフライン用にインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_file.rst:24 -msgid "Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file." -msgstr "相対パスは、現在の作業ディレクトリー（``ansible-galaxy install -r`` を呼び出しているディレクトリー）から計算されます。これは、``requirements.yml`` ファイルからの相対パスではありません。" - -#: ../../rst/galaxy/user_guide.rst:92 -msgid "Installing a collection from a git repository" -msgstr "git リポジトリーからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 -msgid "You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet." -msgstr "コレクションは、Galaxy または Automation Hub の代わりに git リポジトリーからインストールできます。開発者は、git リポジトリーからインストールし、tarball を作成してコレクションを公開する前にコレクションを確認できます。ユーザーとして git リポジトリーからインストールすることで、Galaxy または Automation Hub にないコレクションまたはバージョンを使用できます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:3 -msgid "The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection." -msgstr "リポジトリーには ``galaxy.yml`` または ``MANIFEST.json`` ファイルが含まれている必要があります。このファイルは、コレクションのバージョン番号、namespace などのメタデータを提供します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:6 -msgid "Installing a collection from a git repository at the command line" -msgstr "コマンドガイドで git リポジトリーからのコレクションのインストール" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:8 -msgid "To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). You can specify a branch, commit, or tag using the comma-separated `git commit-ish `_ syntax." -msgstr "git リポジトリーからコレクションをインストールするには、コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーの URI を使用します。ユーザー``git``でSSH認証を使用していない限り、プレフィックス``git+``を使用します(例: ``git@github.com:ansible-collections/ansible.windows.git``)。コンマ区切りの `git コミットのような `_ 構文を使用して、ブランチ、コミット、またはタグを指定できます。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:10 -msgid "For example:" -msgstr "例:" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:25 -msgid "Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere." -msgstr "認証情報を git URI に埋め込むことは安全ではありません。安全な認証オプションを使用して、認証情報がログに公開されないようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 -msgid "Use `SSH `_ authentication" -msgstr "`SSH `_ 認証を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:28 -msgid "Use `netrc `_ authentication" -msgstr "`netrc `_ 認証を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:29 -msgid "Use `http.extraHeader `_ in your git configuration" -msgstr "お使いの git 設定で `http.extraHeader `_ を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:30 -msgid "Use `url..pushInsteadOf `_ in your git configuration" -msgstr "お使いの git 設定で `url..pushInsteadOf `_ を使用する" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:33 -msgid "Specifying the collection location within the git repository" -msgstr "git リポジトリー内でのコレクションの場所の指定" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:35 -msgid "When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files:" -msgstr "git リポジトリーからコレクションをインストールする場合、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルを使用してコレクションを構築します。デフォルトでは、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルの 2 つのパスを検索します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:37 -msgid "The top level of the repository." -msgstr "リポジトリーのトップレベル。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 -msgid "Each directory in the repository path (one level deep)." -msgstr "リポジトリーパス内の各ディレクトリー（1 レベルの深さ）" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:40 -msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection." -msgstr "``galaxy.yml`` または ``MANIFEST.json`` ファイルがリポジトリーのトップレベルにある場合、Ansible はそのファイル内のコレクションメタデータを使用して個別のコレクションをインストールします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:51 -msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default:" -msgstr "リポジトリーパス内の 1 つ以上のディレクトリーに ``galaxy.yml`` または ``MANIFEST.json`` ファイルが存在する場合は、Ansible はメタデータファイルを持つ各ディレクトリーをコレクションとしてインストールします。たとえば、Ansible は、デフォルトで、このリポジトリー構造から collection1 と collection2 の両方をインストールします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:69 -msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections:" -msgstr "リポジトリ構造が異なる場合、またはコレクションのサブセットのみをインストールする場合は、URI の末尾（オプションのコンマ区切りバージョンの前）にフラグメントを追加して、メタデータファイルの場所を示すことができます。パスは、メタデータファイル自体ではなく、ディレクトリである必要があります。たとえば、2つのコレクションを持つサンプルリポジトリからcollection2のみをインストールするには、次のようにします。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:75 -msgid "In some repositories, the main directory corresponds to the namespace:" -msgstr "リポジトリーによっては、メインのディレクトリーは名前空間に対応します。" - -#: ../../rst/shared_snippets/installing_collections_git_repo.txt:97 -msgid "You can install all collections in this repository, or install one collection from a specific commit:" -msgstr "このリポジトリーのすべてのコレクションをインストールするか、特定のコミットから 1 つのコレクションをインストールできます。" - -#: ../../rst/galaxy/user_guide.rst:97 -msgid "Listing installed collections" -msgstr "インストール済みコレクションの一覧表示" - -#: ../../rst/galaxy/user_guide.rst:99 -msgid "To list installed collections, run ``ansible-galaxy collection list``. See :ref:`collections_listing` for more details." -msgstr "インストール済みのコレクションを一覧表示するには、``ansible-galaxy collection list`` を実行します。詳細は、「:ref:`collections_listing`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:103 -msgid "Configuring the ``ansible-galaxy`` client" -msgstr "``ansible-galaxy`` クライアントの設定" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:3 -msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`)." -msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:5 -msgid "You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as a custom Galaxy server):" -msgstr "以下のオプションを使用して、他のサーバー (カスタムの Galaxy サーバーなど) を使用するように ``ansible-galaxy collection`` を設定できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:7 -msgid "Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`." -msgstr ":ref:`ansible_configuration_settings_locations` の :ref:`galaxy_server_list` 設定オプションにサーバーリストを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:8 -msgid "Use the ``--server`` command line argument to limit to an individual server." -msgstr "``--server`` コマンドライン引数を使用して、個々のサーバーに制限します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:10 -msgid "To configure a Galaxy server list in ``ansible.cfg``:" -msgstr "``ansible.cfg`` で Galaxy サーバー一覧を設定するには、以下を行います。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:13 -msgid "Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names." -msgstr "``server_list`` セクションの ``[galaxy]`` オプションを 1 つ以上のサーバー名に追加します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:14 -msgid "Create a new section for each server name." -msgstr "各サーバー名に新しいセクションを作成します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:15 -msgid "Set the ``url`` option for each server name." -msgstr "各サーバー名に ``url`` オプションを設定します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:16 -msgid "Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`." -msgstr "必要に応じて、各サーバー名の API トークンを設定します。https://galaxy.ansible.com/me/preferences に移動し、guilabel:`Show API key` をクリックします。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:19 -msgid "The ``url`` option for each server name must end with a forward slash ``/``. If you do not set the API token in your Galaxy server list, use the ``--api-key`` argument to pass in the token to the ``ansible-galaxy collection publish`` command." -msgstr "各サーバー名の ``url`` オプションは、スラッシュ ``/`` で終了する必要があります。Galaxy サーバー一覧の API トークンを設定しない場合は、``--api-key`` 引数を使用してトークンを ``ansible-galaxy collection publish`` コマンドに渡します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:22 -msgid "The following example shows how to configure multiple servers:" -msgstr "以下の例は、複数のサーバーを設定する方法を示しています。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:49 -msgid "You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the ``--server`` argument." -msgstr "``--server`` コマンドライン引数を使用して ``server_list`` で明示的な Galaxy サーバーを選択し、この引数の値はサーバー名と一致する必要があります。サーバー一覧にないサーバーを使用する場合は、そのサーバーにアクセスする URL に値を設定します (サーバーリスト内のすべてのサーバーは無視されます)。また、事前定義されたサーバーのいずれかに ``--api-key`` 引数を使用することはできません。サーバーの一覧を定義していない場合、または ``--server`` に URL を指定した場合限り、``api_key`` 引数を使用できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:53 -msgid "**Galaxy server list configuration options**" -msgstr "**Galaxy サーバー一覧設定オプション**" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:55 -msgid "The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section ``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then define the following keys:" -msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義されます。``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:61 -msgid "``url``: The URL of the Galaxy instance to connect to. Required." -msgstr "``url``: 接続する Galaxy インスタンスの URL。必須。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:62 -msgid "``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``." -msgstr "``token``: Galaxy インスタンスに対する認証に使用する API トークンキー。``username`` と相互に排他的です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:63 -msgid "``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``." -msgstr "``username``: Galaxy インスタンスに対する Basic 認証に使用するユーザー名。``token`` と相互に排他的です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:64 -msgid "``password``: The password to use, in conjunction with ``username``, for basic authentication." -msgstr "``password``: Basic 認証に使用するパスワード。``username`` と併用します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:65 -msgid "``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, galaxyNG). Mutually exclusive with ``username``. Requires ``token``." -msgstr "``auth_url``: SSO 認証 (例: galaxyNG) を使用する場合は Keycloak サーバー「token_endpoint」の URL です。``username`` と相互に排他的です。``token`` が必要です。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:66 -msgid "``validate_certs``: Whether or not to verify TLS certificates for the Galaxy server. This defaults to True unless the ``--ignore-certs`` option is provided or ``GALAXY_IGNORE_CERTS`` is configured to True." -msgstr "``validate_certs``: Galaxy サーバーの TLS 証明書を検証するかどうか。これは、``--ignore-certs`` オプションが提供されるか、``GALAXY_IGNORE_CERTS`` が True に設定されている場合を除き、デフォルトで True に設定されます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:67 -msgid "``client_id``: The Keycloak token's client_id to use for authentication. Requires ``auth_url`` and ``token``. The default ``client_id`` is cloud-services to work with Red Hat SSO." -msgstr "``client_id``: 認証に使用する Keycloak トークンの client_id。``auth_url`` および ``token`` が必要です。デフォルトの ``client_id`` は、Red Hat SSO と連携するクラウドサービスです。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:69 -msgid "As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for ``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``." -msgstr "これらのサーバーオプションを ``ansible.cfg`` ファイルで定義するだけでなく、それらを環境変数として定義することもできます。環境変数は ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` の形式です。``{{ id }}`` はサーバー識別子の大文字形式であり、``{{ key }}`` は定義するキーです。たとえば、``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token`` を設定することで、``release_galaxy`` に ``token`` を定義することができます。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:74 -msgid "For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the ``server_list``, unless you pass in an explicit server with the ``--server`` argument." -msgstr "Galaxy サーバー 1 つだけを使用する操作 (例: ``publish`` コマンド、``info`` コマンド、または ``install`` コマンド) の場合、``ansible-galaxy collection`` コマンドは、``--server`` 引数を使用して明示的なサーバーに渡しない限り、``server_list`` の最初のエントリーを使用します。" - -#: ../../rst/shared_snippets/galaxy_server_list.txt:78 -msgid "``ansible-galaxy`` can seek out dependencies on other configured Galaxy instances to support the use case where a collection can depend on a collection from another Galaxy instance." -msgstr "``ansible-galaxy`` は、設定済みの他の Galaxy インスタンスで依存関係を検索して、コレクションが別の Galaxy インスタンスからのコレクションに依存する可能性があるようなユースケースをサポートできます。" - -#: ../../rst/galaxy/user_guide.rst:110 -msgid "Finding roles on Galaxy" -msgstr "Galaxy でのロールの検索" - -#: ../../rst/galaxy/user_guide.rst:112 -msgid "Search the Galaxy database by tags, platforms, author and multiple keywords. For example:" -msgstr "Galaxy データベースは、タグ、プラットフォーム、作成者、および複数のキーワードで検索します。以下は例になります。" - -#: ../../rst/galaxy/user_guide.rst:118 -msgid "The search command will return a list of the first 1000 results matching your search:" -msgstr "search コマンドは、検索に一致する最初の 1000 個の結果を一覧で返します。" - -#: ../../rst/galaxy/user_guide.rst:131 -msgid "Get more information about a role" -msgstr "ロールに関する詳細情報の取得" - -#: ../../rst/galaxy/user_guide.rst:133 -msgid "Use the ``info`` command to view more detail about a specific role:" -msgstr "``info`` コマンドを使用して、特定のロールに関する詳細を表示します。" - -#: ../../rst/galaxy/user_guide.rst:139 -msgid "This returns everything found in Galaxy for the role:" -msgstr "これは、ロールの Galaxy にあるすべてのものを返します。" - -#: ../../rst/galaxy/user_guide.rst:176 -msgid "Installing roles from Galaxy" -msgstr "Galaxy からのロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:178 -msgid "The ``ansible-galaxy`` command comes bundled with Ansible, and you can use it to install roles from Galaxy or directly from a git based SCM. You can also use it to create a new role, remove roles, or perform tasks on the Galaxy website." -msgstr "``ansible-galaxy`` コマンドは Ansible とバンドルされ、Galaxy から、または git ベースの SCM から直接ロールをインストールするために使用できます。また、新しいロールの作成、ロールの削除、または Galaxy の Web サイトでタスクを実行することもできます。" - -#: ../../rst/galaxy/user_guide.rst:181 -msgid "The command line tool by default communicates with the Galaxy website API using the server address *https://galaxy.ansible.com*. If you run your own internal Galaxy server and want to use it instead of the default one, pass the ``--server`` option following the address of this galaxy server. You can set permanently this option by setting the Galaxy server value in your ``ansible.cfg`` file to use it . For information on setting the value in *ansible.cfg* see :ref:`galaxy_server`." -msgstr "コマンドラインツールは、デフォルトでサーバーアドレス *https://galaxy.ansible.com* を使用して Galaxy Web サイト API と通信します。独自の内部 Galaxy サーバーを実行していて、デフォルトのサーバーの代わりにそれを使用したい場合は、この galaxy サーバーのアドレスの後に ``--server`` オプションを渡します。``ansible.cfg`` ファイルに Galaxy サーバーの値を設定することにより、このオプションを永続的に設定できます。*ansible.cfg* での値の設定については、「:ref:`galaxy_server`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:187 -msgid "Installing roles" -msgstr "ロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:189 -msgid "Use the ``ansible-galaxy`` command to download roles from the `Galaxy website `_" -msgstr "``ansible-galaxy`` コマンドを使用して、`Galaxy website `_ からロールをダウンロードします。" - -#: ../../rst/galaxy/user_guide.rst:196 -msgid "Setting where to install roles" -msgstr "ロールをインストールする場所の設定" - -#: ../../rst/galaxy/user_guide.rst:198 -msgid "By default, Ansible downloads roles to the first writable directory in the default list of paths ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``. This installs roles in the home directory of the user running ``ansible-galaxy``." -msgstr "デフォルトでは、Ansible はパスのデフォルトリスト ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles`` にある最初に書き込み可能なディレクトリーにロールをダウンロードします。これは、``ansible-galaxy`` を実行するユーザーのホームディレクトリーにロールをインストールします。" - -#: ../../rst/galaxy/user_guide.rst:200 -msgid "You can override this with one of the following options:" -msgstr "これは、以下のオプションのいずれかで上書きできます。" - -#: ../../rst/galaxy/user_guide.rst:202 -msgid "Set the environment variable :envvar:`ANSIBLE_ROLES_PATH` in your session." -msgstr "セッションで環境変数 :envvar:`ANSIBLE_ROLES_PATH` を設定します。" - -#: ../../rst/galaxy/user_guide.rst:203 -msgid "Use the ``--roles-path`` option for the ``ansible-galaxy`` command." -msgstr "``--roles-path`` コマンドに ``ansible-galaxy`` オプションを使用します。" - -#: ../../rst/galaxy/user_guide.rst:204 -msgid "Define ``roles_path`` in an ``ansible.cfg`` file." -msgstr "``ansible.cfg`` ファイルで ``roles_path`` を定義します。" - -#: ../../rst/galaxy/user_guide.rst:206 -msgid "The following provides an example of using ``--roles-path`` to install the role into the current working directory:" -msgstr "以下は、``--roles-path`` を使用して現在の作業ディレクトリーにロールをインストールする例を示しています。" - -#: ../../rst/galaxy/user_guide.rst:214 -msgid ":ref:`intro_configuration`" -msgstr ":ref:`intro_configuration`" - -#: ../../rst/galaxy/user_guide.rst:215 -msgid "All about configuration files" -msgstr "設定ファイルに関するすべて" - -#: ../../rst/galaxy/user_guide.rst:218 -msgid "Installing a specific version of a role" -msgstr "ロールの特定バージョンのインストール" - -#: ../../rst/galaxy/user_guide.rst:220 -msgid "When the Galaxy server imports a role, it imports any git tags matching the `Semantic Version `_ format as versions. In turn, you can download a specific version of a role by specifying one of the imported tags." -msgstr "Galaxy サーバーがロールをインポートすると、`Semantic Version `_ 形式に一致する git タグがバージョンとしてインポートされます。次に、インポートされたタグのいずれかを指定して、ロールの特定バージョンをダウンロードできます。" - -#: ../../rst/galaxy/user_guide.rst:223 -msgid "To see the available versions for a role:" -msgstr "ロールで利用可能なバージョンを表示するには、以下を行います。" - -#: ../../rst/galaxy/user_guide.rst:225 -msgid "Locate the role on the Galaxy search page." -msgstr "Galaxy 検索ページでロールを見つけます。" - -#: ../../rst/galaxy/user_guide.rst:226 -msgid "Click on the name to view more details, including the available versions." -msgstr "利用可能なバージョンなど、名前をクリックして詳細情報を表示します。" - -#: ../../rst/galaxy/user_guide.rst:228 -msgid "You can also navigate directly to the role using the //. For example, to view the role geerlingguy.apache, go to ``_." -msgstr "// を使用してロールに直接移動することもできます。たとえば、geerlingguy.apache ロールを表示するには、``_ に移動します。" - -#: ../../rst/galaxy/user_guide.rst:230 -msgid "To install a specific version of a role from Galaxy, append a comma and the value of a GitHub release tag. For example:" -msgstr "Galaxy から特定のバージョンのロールをインストールするには、コンマと GitHub リリースタグの値を追加します。以下に例を示します。" - -#: ../../rst/galaxy/user_guide.rst:236 -msgid "It is also possible to point directly to the git repository and specify a branch name or commit hash as the version. For example, the following will install a specific commit:" -msgstr "git リポジトリーを直接参照して、バージョンとしてブランチ名またはコミットハッシュを指定することもできます。たとえば、以下は特定のコミットをインストールします。" - -#: ../../rst/galaxy/user_guide.rst:244 -msgid "Installing multiple roles from a file" -msgstr "ファイルからの複数ロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:246 -msgid "You can install multiple roles by including the roles in a :file:`requirements.yml` file. The format of the file is YAML, and the file extension must be either *.yml* or *.yaml*." -msgstr ":file:`requirements.yml` ファイルにロールを追加して、複数のロールをインストールできます。ファイルのフォーマットは YAML で、ファイル拡張子は *.yml* または *.yaml* のいずれかでなければなりません。" - -#: ../../rst/galaxy/user_guide.rst:249 -msgid "Use the following command to install roles included in :file:`requirements.yml:`" -msgstr "以下のコマンドを使用して、:file:`requirements.yml:` に含まれるロールをインストールします。" - -#: ../../rst/galaxy/user_guide.rst:255 -msgid "Again, the extension is important. If the *.yml* extension is left off, the ``ansible-galaxy`` CLI assumes the file is in an older, now deprecated, \"basic\" format." -msgstr "拡張子は重要です。*.yml* 拡張子がオフのままの場合、``ansible-galaxy`` CLI は、ファイルが古いものと見なし、「basic」フォーマットが非推奨であると想定します。" - -#: ../../rst/galaxy/user_guide.rst:258 -msgid "Each role in the file will have one or more of the following attributes:" -msgstr "このファイルの各ロールには、以下の属性が 1 つ以上あります。" - -#: ../../rst/galaxy/user_guide.rst:261 -msgid "src" -msgstr "src" - -#: ../../rst/galaxy/user_guide.rst:261 -msgid "The source of the role. Use the format *namespace.role_name*, if downloading from Galaxy; otherwise, provide a URL pointing to a repository within a git based SCM. See the examples below. This is a required attribute." -msgstr "ロールのソース。Galaxy からダウンロードする場合は、*namespace.role_name* の形式を使用します。それ以外の場合は、git ベースの SCM 内のリポジトリーを参照する URL を提供します。以下を参照してください。これは必須属性です。" - -#: ../../rst/galaxy/user_guide.rst:263 -msgid "scm" -msgstr "scm" - -#: ../../rst/galaxy/user_guide.rst:264 -msgid "Specify the SCM. As of this writing only *git* or *hg* are allowed. See the examples below. Defaults to *git*." -msgstr "SCM を指定します。本書の作成時点では、*git* または *hg* への書き込みのみが許可されます。以下の例を参照してください。デフォルトは *git* です。" - -#: ../../rst/galaxy/user_guide.rst:265 -msgid "version:" -msgstr "version:" - -#: ../../rst/galaxy/user_guide.rst:266 -msgid "The version of the role to download. Provide a release tag value, commit hash, or branch name. Defaults to the branch set as a default in the repository, otherwise defaults to the *master*." -msgstr "ダウンロードするロールのバージョン。リリースタグの値、コミットハッシュ、またはブランチ名を指定します。デフォルトではリポジトリーのデフォルトとして設定されたブランチに設定されます。それ以外の場合は、デフォルトで *master* に設定されます。" - -#: ../../rst/galaxy/user_guide.rst:269 -msgid "name:" -msgstr "name:" - -#: ../../rst/galaxy/user_guide.rst:268 -msgid "Download the role to a specific name. Defaults to the Galaxy name when downloading from Galaxy, otherwise it defaults to the name of the repository." -msgstr "ロールを特定の名前にダウンロードします。デフォルトでは Galaxy からダウンロードするときに Galaxy 名に設定されます。指定しない場合は、リポジトリーの名前に設定されます。" - -#: ../../rst/galaxy/user_guide.rst:271 -msgid "Use the following example as a guide for specifying roles in *requirements.yml*:" -msgstr "以下の例を、*requirements.yml* でロールを指定するためのガイドとして使用してください。" - -#: ../../rst/galaxy/user_guide.rst:320 -msgid "Embedding credentials into a SCM URL is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." -msgstr "認証情報を SCM URL に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" - -#: ../../rst/galaxy/user_guide.rst:323 -msgid "Installing roles and collections from the same requirements.yml file" -msgstr "同じ requirements.yml ファイルからのロールおよびコレクションのインストール" - -#: ../../rst/galaxy/user_guide.rst:325 -msgid "You can install roles and collections from the same requirements files" -msgstr "同じ要件ファイルからロールおよびコレクションをインストールできます。" - -#: ../../rst/galaxy/user_guide.rst:342 -msgid "Installing multiple roles from multiple files" -msgstr "複数のファイルからの複数ロールのインストール" - -#: ../../rst/galaxy/user_guide.rst:344 -msgid "For large projects, the ``include`` directive in a :file:`requirements.yml` file provides the ability to split a large file into multiple smaller files." -msgstr "大規模なプロジェクトの場合、:file:`requirements.yml` ファイルの ``include`` ディレクティブにより、大きなファイルを複数の小さなファイルに分割することができます。" - -#: ../../rst/galaxy/user_guide.rst:346 -msgid "For example, a project may have a :file:`requirements.yml` file, and a :file:`webserver.yml` file." -msgstr "たとえば、プロジェクトには :file:`requirements.yml` ファイルと :file:`webserver.yml` ファイルが含まれる場合があります。" - -#: ../../rst/galaxy/user_guide.rst:348 -msgid "Below are the contents of the :file:`webserver.yml` file:" -msgstr ":file:`webserver.yml` ファイルの内容を以下に示します。" - -#: ../../rst/galaxy/user_guide.rst:359 -msgid "The following shows the contents of the :file:`requirements.yml` file that now includes the :file:`webserver.yml` file:" -msgstr ":file:`requirements.yml` ファイルが含まれる :file:`webserver.yml` ファイルの内容を以下に示します。" - -#: ../../rst/galaxy/user_guide.rst:367 -msgid "To install all the roles from both files, pass the root file, in this case :file:`requirements.yml` on the command line, as follows:" -msgstr "両方のファイルからすべてのロールをインストールするには、以下のように root ファイルを渡します。この例では、以下のように、コマンドラインで :file:`requirements.yml` を指定します。" - -#: ../../rst/galaxy/user_guide.rst:377 -msgid "Dependencies" -msgstr "依存関係" - -#: ../../rst/galaxy/user_guide.rst:379 -msgid "Roles can also be dependent on other roles, and when you install a role that has dependencies, those dependencies will automatically be installed to the ``roles_path``." -msgstr "また、ロールは他のロールに依存し、依存関係のあるロールをインストールすると、それらの依存関係が自動的に ``roles_path`` にインストールされます。" - -#: ../../rst/galaxy/user_guide.rst:381 -msgid "There are two ways to define the dependencies of a role:" -msgstr "ロールの依存関係を定義する方法は 2 つあります。" - -#: ../../rst/galaxy/user_guide.rst:383 -msgid "using ``meta/requirements.yml``" -msgstr "``meta/requirements.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:384 -msgid "using ``meta/main.yml``" -msgstr "``meta/main.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:387 -msgid "Using ``meta/requirements.yml``" -msgstr "``meta/requirements.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:391 -msgid "You can create the file ``meta/requirements.yml`` and define dependencies in the same format used for :file:`requirements.yml` described in the `Installing multiple roles from a file`_ section." -msgstr "``meta/requirements.yml`` ファイルを作成し、「`ファイルから複数のロールのインストール`_」セクションで説明されている :file:`requirements.yml` に使用されるのと同じ形式で依存関係を定義できます。" - -#: ../../rst/galaxy/user_guide.rst:393 -msgid "From there, you can import or include the specified roles in your tasks." -msgstr "そこから、指定のロールをタスクにインポートしたり、追加できます。" - -#: ../../rst/galaxy/user_guide.rst:396 -msgid "Using ``meta/main.yml``" -msgstr "``meta/main.yml`` の使用" - -#: ../../rst/galaxy/user_guide.rst:398 -msgid "Alternatively, you can specify role dependencies in the ``meta/main.yml`` file by providing a list of roles under the ``dependencies`` section. If the source of a role is Galaxy, you can simply specify the role in the format ``namespace.role_name``. You can also use the more complex format in :file:`requirements.yml`, allowing you to provide ``src``, ``scm``, ``version``, and ``name``." -msgstr "または、``dependencies`` セクションの下にロールの一覧を指定して、``meta/main.yml`` ファイルにロールの依存関係を指定できます。ロールのソースが Galaxy の場合には、``namespace.role_name`` 形式でロールを指定するだけです。さらに複雑な形式を :file:`requirements.yml` で使用することもできます。``src``、``scm``、``version``、および ``name`` を指定することもできます。" - -#: ../../rst/galaxy/user_guide.rst:401 -msgid "Dependencies installed that way, depending on other factors described below, will also be executed **before** this role is executed during play execution. To better understand how dependencies are handled during play execution, see :ref:`playbooks_reuse_roles`." -msgstr "そのようにインストールされた依存関係は、以下で説明する他の要因に応じて、プレイの実行中にこのロールが実行される **前** にも実行されます。再生の実行中に依存関係がどのように処理されるかをよりよく理解するには、「:ref:`playbooks_reuse_roles`」を参照してください。" - -#: ../../rst/galaxy/user_guide.rst:404 -msgid "The following shows an example ``meta/main.yml`` file with dependent roles:" -msgstr "依存するロールが指定された ``meta/main.yml`` ファイルの例を以下に示します。" - -#: ../../rst/galaxy/user_guide.rst:437 -msgid "Tags are inherited *down* the dependency chain. In order for tags to be applied to a role and all its dependencies, the tag should be applied to the role, not to all the tasks within a role." -msgstr "タグは、依存関係チェーン *下* に継承されます。タグをロールに適用してすべての依存関係に適用するには、タグをロール内の全タスクに適用するのではなく、ロールに適用する必要があります。" - -#: ../../rst/galaxy/user_guide.rst:439 -msgid "Roles listed as dependencies are subject to conditionals and tag filtering, and may not execute fully depending on what tags and conditionals are applied." -msgstr "依存関係として一覧表示されているロールは、条件とタグフィルタリングの対象であり、適用されるタグと条件によっては完全に実行されない場合があります。" - -#: ../../rst/galaxy/user_guide.rst:442 -msgid "If the source of a role is Galaxy, specify the role in the format *namespace.role_name*:" -msgstr "ロールのソースが Galaxy の場合は、ロールを *namespace.role_name* 形式で指定します。" - -#: ../../rst/galaxy/user_guide.rst:451 -msgid "Alternately, you can specify the role dependencies in the complex form used in :file:`requirements.yml` as follows:" -msgstr "または、以下のように :file:`requirements.yml` で使用される複雑な形式でロールの依存関係を指定することもできます。" - -#: ../../rst/galaxy/user_guide.rst:463 -msgid "Galaxy expects all role dependencies to exist in Galaxy, and therefore dependencies to be specified in the ``namespace.role_name`` format. If you import a role with a dependency where the ``src`` value is a URL, the import process will fail." -msgstr "Galaxy では、すべてのロールの依存関係が Galaxy に存在することが想定されるため、``namespace.role_name`` 形式で依存関係を指定します。``src`` の値が URL である依存関係でロールをインポートすると、インポートプロセスは失敗します。" - -#: ../../rst/galaxy/user_guide.rst:467 -msgid "List installed roles" -msgstr "インストール済みロールの一覧表示" - -#: ../../rst/galaxy/user_guide.rst:469 -msgid "Use ``list`` to show the name and version of each role installed in the *roles_path*." -msgstr "``list`` を使用して、*roles_path* にインストールされている各ロールの名前およびバージョンを表示します。" - -#: ../../rst/galaxy/user_guide.rst:481 -msgid "Remove an installed role" -msgstr "インストールされたロールの削除" - -#: ../../rst/galaxy/user_guide.rst:483 -msgid "Use ``remove`` to delete a role from *roles_path*:" -msgstr "``remove`` を使用して、*roles_path* からロールを削除します。" - -#: ../../rst/galaxy/user_guide.rst:494 -msgid "Reusable tasks, handlers, and other files in a known directory structure" -msgstr "既知のディレクトリー構造の再利用可能なタスク、ハンドラー、およびその他のファイル" - -#: ../../rst/galaxy/user_guide.rst:495 -msgid ":ref:`command_line_tools`" -msgstr ":ref:`command_line_tools`" - -#: ../../rst/galaxy/user_guide.rst:496 -msgid "Perform other related operations" -msgstr "カタログ関連の操作を実行します。" - -#~ msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ version (for example, a commit or tag)." -#~ msgstr "" - -#~ msgid "The first is the ``galaxy.yml`` file in the top level of the repository path. If the ``galaxy.yml`` file exists it's used as the collection metadata and the individual collection will be installed." -#~ msgstr "" - -#~ msgid "The second is a ``galaxy.yml`` file in each directory in the repository path (one level deep). In this scenario, each directory with a ``galaxy.yml`` is installed as a collection." -#~ msgstr "" - -#~ msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for ``galaxy.yml`` file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file)." -#~ msgstr "" - -#~ msgid "You can install roles and collections from the same requirements files, with some caveats." -#~ msgstr "" - -#~ msgid "While both roles and collections can be specified in one requirements file, they need to be installed separately. The ``ansible-galaxy role install -r requirements.yml`` will only install roles and ``ansible-galaxy collection install -r requirements.yml -p ./`` will only install collections." -#~ msgstr "" - -#~ msgid "`.. versionadded:: 2.10`" -#~ msgstr "" - -#~ msgid "`irc.freenode.net `_" -#~ msgstr "`irc.freenode.net `_" - -#~ msgid "The supported keys for collection requirement entries are ``name``, ``version``, ``source``, and ``type``." -#~ msgstr "コレクション要件エントリーでサポートされるキーは ``name``、``version``、``source``、および ``type`` です。" - -#~ msgid "The ``version`` key can take in the same range identifier format documented above. If you're installing a collection from a git repository instead of a built collection artifact, the ``version`` key refers to a `git commit-ish `_." -#~ msgstr "``version`` キーは、上記の範囲識別子の形式を取ることができます。ビルドコレクションアーティファクトではなく git リポジトリーからコレクションをインストールする場合は、``version`` キーは `git commit-ish `_ を参照します。" - -#~ msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish `_ version (for example, a commit or tag)." -#~ msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish `_ バージョン (コミットまたはタグなど) をサポートする必要があります。" - -#~ msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH `_, `netrc `_ or `http.extraHeader `_/`url..pushInsteadOf `_ in Git config to prevent your creds from being exposed in logs." -#~ msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH `_、`netrc `_、または `http.extraHeader `_/`url..pushInsteadOf `_ で、クレジットがログに公開されないようにします。" - -#~ msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name." -#~ msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。" - -#~ msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts." -#~ msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。" - -#~ msgid "Default repository search locations" -#~ msgstr "デフォルトのリポジトリー検索の場所" - -#~ msgid "There are two paths searched in a repository for collections by default." -#~ msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。" - -#~ msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection." -#~ msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。" - -#~ msgid "Specifying the location to search for collections" -#~ msgstr "コレクションを検索する場所の指定" - -#~ msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)." -#~ msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。" - -#~ msgid "For Automation Hub, you additionally need to:" -#~ msgstr "Automation Hub の場合には、さらに以下の操作が必要です。" - -#~ msgid "Set the ``auth_url`` option for each server name." -#~ msgstr "各サーバー名に ``auth_url`` オプションを設定します。" - -#~ msgid "Set the API token for each server name. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click ::guilabel:`Get API token` from the version dropdown to copy your API token." -#~ msgstr "各サーバー名の API トークンを設定します。https://cloud.redhat.com/ansible/automation-hub/token/ に、バージョンドロップダウンリストから ::guilabel:`Get API token` をクリックして API トークンをコピーします。" - -#~ msgid "Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent collection. The install process will not search for a collection requirement in a different Galaxy instance." -#~ msgstr "コレクションが見つかると、その要件は親コレクションと同じ Galaxy インスタンス内でのみ検索されます。インストールプロセスでは、別の Galaxy インスタンスでコレクション要件を検索しません。" - -#~ msgid "The ``login`` command requires using your GitHub credentials. You can use your username and password, or you can create a `personal access token `_. If you choose to create a token, grant minimal access to the token, as it is used just to verify identify." -#~ msgstr "``login`` コマンドには、GitHub 認証情報を使用する必要があります。ユーザー名とパスワードを使用するか、`personal access token `_ を作成することができます。トークンの作成を選択した場合は、識別を確認するためにのみ使用されます。" - -#~ msgid "The following shows authenticating with the Galaxy website using a GitHub username and password:" -#~ msgstr "以下は、GitHub のユーザー名とパスワードを使用した Galaxy Web サイトでの認証を示しています。" - -#~ msgid "When you choose to use your username and password, your password is not sent to Galaxy. It is used to authenticates with GitHub and create a personal access token. It then sends the token to Galaxy, which in turn verifies that your identity and returns a Galaxy access token. After authentication completes the GitHub token is destroyed." -#~ msgstr "ユーザー名とパスワードの使用を選択すると、パスワードは Galaxy に送信されません。これは GitHub で認証され、個人アクセストークンを作成するために使用されます。次にトークンを Galaxy に送信し、その ID を検証し、Galaxy アクセストークンを返します。認証が完了すると、GitHub トークンが破棄されます。" - -#~ msgid "If you do not want to use your GitHub password, or if you have two-factor authentication enabled with GitHub, use the ``--github-token`` option to pass a personal access token that you create." -#~ msgstr "GitHub パスワードを使用しない場合や、GitHub で 2 段階認証を有効にしている場合は、``--github-token`` オプションを使用して、作成する個人用アクセストークンを渡します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/getting_started.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/getting_started.po deleted file mode 100644 index 6675e2fdbb6..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/getting_started.po +++ /dev/null @@ -1,485 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/getting_started/basic_concepts.rst:5 -msgid "Ansible concepts" -msgstr "Ansible の概念" - -#: ../../rst/getting_started/basic_concepts.rst:7 -msgid "These concepts are common to all uses of Ansible. You should understand them before using Ansible or reading the documentation." -msgstr "これらの概念は、Ansible のすべての用途に共通しています。Ansible を使用する前に、またはドキュメントを読む前に理解しておく必要があります。" - -#: ../../rst/getting_started/index.rst:13 -#: ../../rst/shared_snippets/basic_concepts.txt:2 -msgid "Control node" -msgstr "コントロールノード" - -#: ../../rst/shared_snippets/basic_concepts.txt:3 -msgid "The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others). You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible. Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features." -msgstr "Ansible CLI ツールを実行するマシン (``ansible-playbook``、``ansible``、``ansible-vault``、その他)。ソフトウェア要件を満たす任意のコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、サーバーはすべて Ansible を実行できます。複数のコントロールノードが可能ですが、Ansible 自体はそれらの間で調整されません。この機能については ``AAP`` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:9 -msgid "Managed nodes" -msgstr "管理ノード" - -#: ../../rst/shared_snippets/basic_concepts.txt:10 -msgid "Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible. Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup." -msgstr "ホストとも呼ばれ、Ansible で管理することを目的としたターゲットデバイス (サーバー、ネットワークアプライアンス、または任意のコンピューター) です。通常 Ansible は管理ノードにインストールされません。``ansible-pull`` を使用している場合は除きますが、それは稀なケースであり、推奨される設定ではありません。" - -#: ../../rst/getting_started/index.rst:20 -#: ../../rst/shared_snippets/basic_concepts.txt:15 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/shared_snippets/basic_concepts.txt:16 -msgid "A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address. It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment. To learn more about inventory, see :ref:`the Working with Inventory` section. Sometimes an inventory source file is also referred to as a 'hostfile'." -msgstr "1 つ以上の「インベントリーソース」で提供される管理ノードの一覧。インベントリーは、IP アドレスなどの各ノードに固有の情報を指定できます。また、プレイおよび一括変数割り当てでノードの選択を可能にするグループの割り当てにも使用されます。インベントリーの詳細は、:ref:`the Working with Inventory` セクションを参照してください。インベントリーソースファイルは「hostfile」と呼ばれる場合もあります。" - -#: ../../rst/shared_snippets/basic_concepts.txt:22 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/shared_snippets/basic_concepts.txt:23 -msgid "They contain Plays (which are the basic unit of Ansible execution). This is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`." -msgstr "プレイ (Ansible 実行の基本単位) が含まれています。これは「実行の概念」であり、``ansible-playbook`` が動作するファイルの記述方法でもあります。Playbook は YAML で書かれており、簡単に読み書き、共有、理解できます。Playbook の詳細については、:ref:`about_playbooks` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:27 -msgid "Plays" -msgstr "プレイ" - -#: ../../rst/shared_snippets/basic_concepts.txt:28 -msgid "The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks. The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly. It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them." -msgstr "Ansible 実行のメインコンテキストであるこの Playbook オブジェクトは、管理ノード (ホスト) をタスクにマップします。プレイには、変数、ロール、およびタスクの順序付きリストが含まれており、繰り返し実行できます。これは基本的に、マップされたホストとタスクの暗黙的なループで設定され、それらを反復処理する方法を定義します。" - -#: ../../rst/shared_snippets/basic_concepts.txt:33 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/shared_snippets/basic_concepts.txt:34 -msgid "A limited distribution of reusable Ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play. To use any Role resource, the Role itself must be imported into the Play." -msgstr "プレイ内で使用するための再利用可能な Ansible コンテンツ (タスク、ハンドラー、変数、プラグイン、テンプレート、およびファイル) の限定ディストリビューション。ロールリソースを使用するには、ロール自体をプレイにインポートする必要があります。" - -#: ../../rst/shared_snippets/basic_concepts.txt:38 -msgid "Tasks" -msgstr "タスク" - -#: ../../rst/shared_snippets/basic_concepts.txt:39 -msgid "The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file). You can execute a single task once with an ad hoc command using ``ansible`` or ``ansible-console`` (both create a virtual Play)." -msgstr "管理ホストに適用される「アクション」の定義。タスクは、常に直接または間接的にプレイに含まれている必要があります (ロール、またはインポート/インクルードされたタスクリストファイル)。アドホックコマンド ``ansible`` または ``ansible-console`` (どちらも仮想プレイを作成) を使用して、1 つのタスクを 1 回実行できます。" - -#: ../../rst/shared_snippets/basic_concepts.txt:43 -msgid "Handlers" -msgstr "Handler (ハンドラー)" - -#: ../../rst/shared_snippets/basic_concepts.txt:44 -msgid "A special form of a Task, that only executes when notified by a previous task which resulted in a 'changed' status." -msgstr "特別な形式のタスク。前のタスクから通知されたときにのみ実行され、'changed' ステータスになります。" - -#: ../../rst/shared_snippets/basic_concepts.txt:48 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/shared_snippets/basic_concepts.txt:49 -msgid "The code or binaries that Ansible copies to and executes on each managed node (when needed) to accomplish the action defined in each Task. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`." -msgstr "Ansible が、各タスクで定義されたアクションを実行するために、各管理ノードで (必要に応じて) コピーおよび実行するコードまたはバイナリー。各モジュールは、特定タイプのデータベースのユーザーを管理したり、特定タイプのネットワークデバイスの VLAN インターフェースを管理するなど、特定の用途に使用されます。タスクで 1 つのモジュールを起動したり、Playbook で複数のモジュールを起動したりすることができます。Ansible モジュールはコレクションとしてまとめられています。Ansible に含まれるコレクションの数は、:ref:`list_of_collections` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:56 -msgid "Plugins" -msgstr "プラグイン" - -#: ../../rst/shared_snippets/basic_concepts.txt:57 -msgid "Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins), manipulate data (filter plugins) and even control what is displayed in the console (callback plugins). See :ref:`working_with_plugins` for details." -msgstr "Ansible のコア機能を拡張するコードの一部であり、管理ノードへの接続方法 (接続プラグイン)、データの操作 (フィルタープラグイン)、さらにはコンソールに表示される内容 (コールバックプラグイン) を制御できます。詳細は :ref:`working_with_plugins` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:63 -msgid "Collections" -msgstr "コレクション" - -#: ../../rst/shared_snippets/basic_concepts.txt:64 -msgid "A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy `_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other." -msgstr "コレクションは、Playbook、ロール、モジュール、プラグインなどの Ansible コンテンツのディストリビューション形式です。`Ansible Galaxy `_ でコレクションをインストールして使用することができます。コレクションの詳細は、:ref:`collections` を参照してください。コレクションリソースは、互いに依存せず、個別に使用できます。" - -#: ../../rst/shared_snippets/basic_concepts.txt:68 -msgid "AAP" -msgstr "AAP" - -#: ../../rst/shared_snippets/basic_concepts.txt:69 -msgid "Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on." -msgstr "Ansible Automation Platform の略です。これは、エンタープライズレベルの機能が含まれ、Ansible エコシステムの多くツール (ansible-core、awx、galaxyNG など) を統合する製品です。" - -#: ../../rst/getting_started/get_started_inventory.rst:5 -msgid "Building an inventory" -msgstr "インベントリーのビルド" - -#: ../../rst/getting_started/get_started_inventory.rst:7 -msgid "Inventories organize managed nodes in centralized files that provide Ansible with system information and network locations. Using an inventory file, Ansible can manage a large number of hosts with a single command. Inventories also help you use Ansible more efficiently by reducing the number of command-line options you need to specify. For example, inventories usually contain the SSH user so you do not need to include the ``-u`` flag when running Ansible commands." -msgstr "インベントリーは、Ansible にシステム情報やネットワークの場所を提供する一元化されたファイルに管理対象ノードを整理します。インベントリーファイルを使用すると、Ansible は 1 つのコマンドで多数のホストを管理できます。インベントリーを使用すると、指定する必要のあるコマンドラインオプションの数が減少するため、Ansible をより効率的に使用できます。たとえば、通常インベントリーには SSH ユーザーが含まれるため、Ansible コマンドの実行時に ``-u`` フラグを含める必要はありません。" - -#: ../../rst/getting_started/get_started_inventory.rst:12 -msgid "In the previous section, you added managed nodes directly to the ``/etc/ansible/hosts`` file. Now let's create an inventory file that you can add to source control for flexibility, reuse, and for sharing with other users." -msgstr "前のセクションでは、管理対象ノードを ``/etc/ansible/hosts`` ファイルに直接追加しました。次は、柔軟性の向上、再利用、他のユーザーとの共有を可能にするため、ソース管理に追加できるインベントリーファイルを作成します。" - -#: ../../rst/getting_started/get_started_inventory.rst:16 -msgid "Inventory files can be in ``INI`` or ``YAML`` format. For demonstration purposes, this section uses ``YAML`` format only." -msgstr "インベントリーファイルは ``INI`` または ``YAML`` 形式を使用できます。デモンストレーションとして、ここでは ``YAML`` 形式のみを使用します。" - -#: ../../rst/getting_started/get_started_inventory.rst:19 -#: ../../rst/getting_started/get_started_playbook.rst:25 -msgid "Complete the following steps:" -msgstr "以下の手順を実行します。" - -#: ../../rst/getting_started/get_started_inventory.rst:21 -#: ../../rst/getting_started/get_started_playbook.rst:27 -msgid "Open a terminal window on your control node." -msgstr "コントロールノードでターミナルウィンドウを開きます。" - -#: ../../rst/getting_started/get_started_inventory.rst:22 -msgid "Create a new inventory file named ``inventory.yaml`` in any directory and open it for editing." -msgstr "任意のディレクトリーに ``inventory.yaml`` という名前の新しいインベントリーファイルを作成し、そのファイルを開いて編集します。" - -#: ../../rst/getting_started/get_started_inventory.rst:23 -msgid "Add a new group for your hosts then specify the IP address or fully qualified domain name (FQDN) of each managed node with the ``ansible_host`` field. The following example adds the IP addresses of three virtual machines in KVM:" -msgstr "ホストの新規グループを追加してから、``ansible_host`` フィールドで各管理対象ノードの IP アドレスまたは完全修飾ドメイン名( FQDN) を指定します。以下の例では、KVM に 3 つの仮想マシンの IP アドレスを追加します。" - -#: ../../rst/getting_started/get_started_inventory.rst:29 -msgid "Verify your inventory. If you created your inventory in a directory other than your home directory, specify the full path with the ``-i`` option." -msgstr "インベントリーを検証します。ホームディレクトリー以外のディレクトリーにインベントリーを作成した場合は、``-i`` オプションで完全パスを指定します。" - -#: ../../rst/getting_started/get_started_inventory.rst:36 -msgid "Ping the managed nodes in your inventory. In this example, the group name is ``virtualmachines`` which you can specify with the ``ansible`` command instead of ``all``." -msgstr "インベントリーの管理ノードに ping します。この例では、グループ名は ``virtualmachines`` で、``all`` ではなく ``ansible`` コマンドで指定できます。" - -#: ../../rst/getting_started/get_started_inventory.rst:46 -msgid "Congratulations! You have successfully built an inventory." -msgstr "おめでとうございます。インベントリーのビルドに成功しました。" - -#: ../../rst/getting_started/get_started_inventory.rst:49 -msgid "Tips for building inventories" -msgstr "インベントリーのビルドに関するヒント" - -#: ../../rst/getting_started/get_started_inventory.rst:51 -msgid "Ensure that group names are meaningful and unique. Group names are also case sensitive." -msgstr "グループ名が意味を持ち、一意であることを確認します。グループ名でも大文字と小文字が区別されます。" - -#: ../../rst/getting_started/get_started_inventory.rst:52 -msgid "Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in group names." -msgstr "グループ名で、スペース、ハイフン、先行する数字 (``19th_floor``ではなく ``floor_19`` を使用) は使用しないでください。" - -#: ../../rst/getting_started/get_started_inventory.rst:53 -msgid "Group hosts in your inventory logically according to their **What**, **Where**, and **When**." -msgstr "**What**、**Where**、および **When** に従って、インベントリー内のホストを論理的にグループ化します。" - -#: ../../rst/getting_started/get_started_inventory.rst:55 -msgid "What" -msgstr "確認対象" - -#: ../../rst/getting_started/get_started_inventory.rst:56 -msgid "Group hosts according to the topology, for example: db, web, leaf, spine." -msgstr "トポロジーに従ってホストを分類します (例: db、web、leaf、spine)。" - -#: ../../rst/getting_started/get_started_inventory.rst:57 -msgid "Where" -msgstr "Where" - -#: ../../rst/getting_started/get_started_inventory.rst:58 -msgid "Group hosts by geographic location, for example: datacenter, region, floor, building." -msgstr "地理的な場所でホストを分類します (例: datacenter、region、floor、build)。" - -#: ../../rst/getting_started/get_started_inventory.rst:60 -msgid "When" -msgstr "When" - -#: ../../rst/getting_started/get_started_inventory.rst:60 -msgid "Group hosts by stage, for example: development, test, staging, production." -msgstr "ステージごとにホストを分類します (例: development、test、staging、production)。" - -#: ../../rst/getting_started/get_started_inventory.rst:63 -msgid "Use metagroups" -msgstr "メタグループの使用" - -#: ../../rst/getting_started/get_started_inventory.rst:65 -msgid "Create a metagroup that organizes multiple groups in your inventory with the following syntax:" -msgstr "以下の構文を使用して、インベントリー内に複数のグループを整理するメタグループを作成します。" - -#: ../../rst/getting_started/get_started_inventory.rst:72 -msgid "The following inventory illustrates a basic structure for a data center. This example inventory contains a ``network`` metagroup that includes all network devices and a ``datacenter`` metagroup that includes the ``network`` group and all webservers." -msgstr "以下のインベントリーは、データセンターの基本構造を示しています。このインベントリーの例には、すべてのネットワークデバイスを含む ``network`` メタグループと、``network`` グループとすべての Web サーバー含む ``datacenter`` メタグループが含まれます。" - -#: ../../rst/getting_started/get_started_inventory.rst:79 -msgid "Create variables" -msgstr "変数の作成" - -#: ../../rst/getting_started/get_started_inventory.rst:81 -msgid "Variables set values for managed nodes, such as the IP address, FQDN, operating system, and SSH user, so you do not need to pass them when running Ansible commands." -msgstr "変数は、IP アドレス、FQDN、オペレーティングシステム、SSH ユーザーなどの管理対象ノードの値を設定するため、Ansible コマンドの実行時に渡す必要はありません。" - -#: ../../rst/getting_started/get_started_inventory.rst:83 -msgid "Variables can apply to specific hosts." -msgstr "変数は特定のホストに適用できます。" - -#: ../../rst/getting_started/get_started_inventory.rst:88 -msgid "Variables can also apply to all hosts in a group." -msgstr "変数は、グループ内のすべてのホストにも適用できます。" - -#: ../../rst/getting_started/get_started_inventory.rst:93 -msgid "Now that you know how to build an inventory, continue by :ref:`learning how to create a playbook`." -msgstr "インベントリーのビルド方法を把握したので、:ref:`learning how to create a playbook` に進みます。" - -#: ../../rst/getting_started/get_started_inventory.rst:97 -msgid ":ref:`intro_inventory`" -msgstr ":ref:`intro_inventory`" - -#: ../../rst/getting_started/get_started_inventory.rst:98 -msgid "Learn more about inventories in ``YAML`` or ``INI`` format." -msgstr "インベントリーの詳細は、``YAML`` または ``INI`` 形式で確認します。" - -#: ../../rst/getting_started/get_started_inventory.rst:99 -msgid ":ref:`variables_in_inventory`" -msgstr ":ref:`variables_in_inventory`" - -#: ../../rst/getting_started/get_started_inventory.rst:100 -msgid "Find out more about inventory variables and their syntax." -msgstr "インベントリー変数とその構文について詳細を確認します。" - -#: ../../rst/getting_started/get_started_inventory.rst:101 -msgid ":ref:`vault`" -msgstr ":ref:`vault`" - -#: ../../rst/getting_started/get_started_inventory.rst:102 -msgid "Find out how to encrypt sensitive content in your inventory such as passwords and keys." -msgstr "パスワードやキーなど、インベントリー内の機密コンテンツを暗号化する方法を確認します。" - -#: ../../rst/getting_started/get_started_playbook.rst:5 -msgid "Creating a playbook" -msgstr "Playbook の作成" - -#: ../../rst/getting_started/get_started_playbook.rst:7 -msgid "Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure managed nodes." -msgstr "Playbook は、Ansible が管理ノードのデプロイおよび設定に使用する、``YAML`` 形式の自動 Blueprint です。" - -#: ../../rst/getting_started/get_started_playbook.rst:10 -msgid "Playbook" -msgstr "Playbook" - -#: ../../rst/getting_started/get_started_playbook.rst:10 -msgid "A list of plays that define the order in which Ansible performs operations, from top to bottom, to achieve an overall goal." -msgstr "全体的な目標を達成するために、Ansible が上から下に操作を実行する順序を定義するプレイのリスト。" - -#: ../../rst/getting_started/get_started_playbook.rst:13 -msgid "Play" -msgstr "プレイ" - -#: ../../rst/getting_started/get_started_playbook.rst:13 -msgid "An ordered list of tasks that maps to managed nodes in an inventory." -msgstr "インベントリーの管理対象ノードにマップするタスクの順序付きリスト。" - -#: ../../rst/getting_started/get_started_playbook.rst:16 -msgid "Task" -msgstr "タスク" - -#: ../../rst/getting_started/get_started_playbook.rst:16 -msgid "A list of one or more modules that defines the operations that Ansible performs." -msgstr "Ansible が実行する操作を定義する 1 つ以上のモジュールの一覧。" - -#: ../../rst/getting_started/get_started_playbook.rst:20 -msgid "Module" -msgstr "モジュール" - -#: ../../rst/getting_started/get_started_playbook.rst:19 -msgid "A unit of code or binary that Ansible runs on managed nodes. Ansible modules are grouped in collections with a :term:`Fully Qualified Collection Name (FQCN)` for each module." -msgstr "Ansible が管理対象ノードで実行するコードまたはバイナリーの単位。Ansible モジュールは、各モジュールの :term:`Fully Qualified Collection Name (FQCN)` でコレクションにグループ化されます。" - -#: ../../rst/getting_started/get_started_playbook.rst:22 -msgid "In the previous section, you used the ``ansible`` command to ping hosts in your inventory. Now let's create a playbook that pings your hosts and also prints a \"Hello world\" message." -msgstr "前のセクションでは、``ansible`` コマンドを使用してインベントリー内のホストに ping を送信しました。次に、ホストに ping し、「Hello world」というメッセージも出力する Playbook を作成してみましょう。" - -#: ../../rst/getting_started/get_started_playbook.rst:28 -msgid "Create a new playbook file named ``playbook.yaml`` in any directory and open it for editing." -msgstr "任意のディレクトリーに ``playbook.yaml`` という名前の新しい Playbook ファイルを作成し、そのファイルを開いて編集します。" - -#: ../../rst/getting_started/get_started_playbook.rst:29 -msgid "Add the following content to ``playbook.yaml``:" -msgstr "``playbook.yaml`` に以下の内容を追加します。" - -#: ../../rst/getting_started/get_started_playbook.rst:34 -msgid "Run your playbook." -msgstr "Playbook を実行します。" - -#: ../../rst/getting_started/get_started_playbook.rst:40 -msgid "Ansible returns the following output:" -msgstr "Ansible は次の出力を返します。" - -#: ../../rst/getting_started/get_started_playbook.rst:45 -msgid "In this output you can see:" -msgstr "この出力で、以下を確認できます。" - -#: ../../rst/getting_started/get_started_playbook.rst:47 -msgid "The names that you give the play and each task. You should always use descriptive names that make it easy to verify and troubleshoot playbooks." -msgstr "プレイと各タスクを指定する名前。Playbook の検証とトラブルシューティングを容易にする説明的な名前を常に使用する必要があります。" - -#: ../../rst/getting_started/get_started_playbook.rst:50 -msgid "The ``Gather Facts`` task runs implicitly. By default Ansible gathers information about your inventory that it can use in the playbook." -msgstr "``Gather Facts`` タスクは暗黙的に実行されます。デフォルトでは、Ansible は Playbook で使用できるインベントリーに関する情報を収集します。" - -#: ../../rst/getting_started/get_started_playbook.rst:53 -msgid "The status of each task. Each task has a status of ``ok`` which means it ran successfully." -msgstr "各タスクのステータス。各タスクのステータスは ``ok`` で、正常に実行されたことを意味します。" - -#: ../../rst/getting_started/get_started_playbook.rst:56 -msgid "The play recap that summarizes results of all tasks in the playbook per host. In this example, there are three tasks so ``ok=3`` indicates that each task ran successfully." -msgstr "ホストごとに Playbook のすべてのタスクの結果をまとめたプレイの要約。この例では、3 つのタスクがあり、``ok=3`` は各タスクが正常に実行されたことを示しています。" - -#: ../../rst/getting_started/get_started_playbook.rst:59 -msgid "Congratulations! You have just created your first Ansible playbook." -msgstr "おめでとうございます。最初の Ansible Playbook を作成しました。" - -#: ../../rst/getting_started/get_started_playbook.rst:63 -msgid ":ref:`playbooks_intro`" -msgstr ":ref:`playbooks_intro`" - -#: ../../rst/getting_started/get_started_playbook.rst:64 -msgid "Start building playbooks for real world scenarios." -msgstr "実際のシナリオ用の Playbook のビルドを開始します。" - -#: ../../rst/getting_started/get_started_playbook.rst:65 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/getting_started/get_started_playbook.rst:66 -msgid "Go into more detail with Ansible playbooks." -msgstr "Ansible Playbook について詳しく説明します。" - -#: ../../rst/getting_started/get_started_playbook.rst:67 -msgid ":ref:`playbooks_best_practices`" -msgstr ":ref:`playbooks_best_practices`" - -#: ../../rst/getting_started/get_started_playbook.rst:68 -msgid "Get tips and tricks for using playbooks." -msgstr "Playbook の使用に関するヒント。" - -#: ../../rst/getting_started/get_started_playbook.rst:69 -msgid ":ref:`vars_and_facts`" -msgstr ":ref:`vars_and_facts`" - -#: ../../rst/getting_started/get_started_playbook.rst:70 -msgid "Learn more about the ``gather_facts`` keyword in playbooks." -msgstr "Playbook の ``gather_facts`` キーワードの詳細を確認できます。" - -#: ../../rst/getting_started/index.rst:5 -msgid "Getting started with Ansible" -msgstr "MySQL のスタートガイド" - -#: ../../rst/getting_started/index.rst:7 -msgid "Ansible automates the management of remote systems and controls their desired state. A basic Ansible environment has three main components:" -msgstr "Ansible はリモートシステムの管理を自動化し、必要な状態を制御します。基本的な Ansible 環境には、以下の 3 つの主要コンポーネントがあります。" - -#: ../../rst/getting_started/index.rst:12 -msgid "A system on which Ansible is installed. You run Ansible commands such as ``ansible`` or ``ansible-inventory`` on a control node." -msgstr "Ansible がインストールされているシステム。コントロールノードで ``ansible`` や ``ansible-inventory`` などの Ansible コマンドを実行します。" - -#: ../../rst/getting_started/index.rst:16 -msgid "Managed node" -msgstr "管理対象ノード" - -#: ../../rst/getting_started/index.rst:16 -msgid "A remote system, or host, that Ansible controls." -msgstr "Ansible が制御するリモートシステムまたはホスト。" - -#: ../../rst/getting_started/index.rst:19 -msgid "A list of managed nodes that are logically organized. You create an inventory on the control node to describe host deployments to Ansible." -msgstr "論理的に編成される管理対象ノードの一覧。コントロールノードにインベントリーを作成し、Ansible にホストのデプロイメントを記述します。" - -msgid "Basic components of an Ansible environment include a control node, an inventory of managed nodes, and a module copied to each managed node." -msgstr "Ansible 環境の基本コンポーネントには、コントロールノード、管理対象ノードのインベントリー、および各管理対象ノードにコピーされたモジュールが含まれます。" - -#: ../../rst/getting_started/index.rst:28 -msgid "Ready to start using Ansible? Complete the following steps to get up and running:" -msgstr "Ansible の使用を開始する準備ができましたか。それでは、以下の手順を実行して起動しましょう。" - -#: ../../rst/getting_started/index.rst:31 -msgid "Install Ansible. Visit the :ref:`installation guide` for complete details." -msgstr "Ansible をインストールします。詳細は、:ref:`installation guide` を参照してください。" - -#: ../../rst/getting_started/index.rst:37 -msgid "Create an inventory by adding the IP address or fully qualified domain name (FQDN) of one or more remote systems to ``/etc/ansible/hosts``. The following example adds the IP addresses of three virtual machines in KVM:" -msgstr "1 つ以上のリモートシステムの IP アドレスまたは完全修飾ドメイン名 (FQDN) を ``/etc/ansible/hosts`` に追加してインベントリーを作成します。以下の例では、KVM に 3 つの仮想マシンの IP アドレスを追加します。" - -#: ../../rst/getting_started/index.rst:47 -msgid "Verify the hosts in your inventory." -msgstr "インベントリー内のホストを確認します。" - -#: ../../rst/getting_started/index.rst:60 -msgid "Set up SSH connections so Ansible can connect to the managed nodes." -msgstr "Ansible が管理対象ノードに接続できるように SSH 接続を設定します。" - -#: ../../rst/getting_started/index.rst:62 -msgid "Add your public SSH key to the ``authorized_keys`` file on each remote system." -msgstr "公開 SSH キーを各リモートシステムの ``authorized_keys`` ファイルに追加します。" - -#: ../../rst/getting_started/index.rst:63 -msgid "Test the SSH connections, for example:" -msgstr "SSH 接続をテストします。以下はその例です。" - -#: ../../rst/getting_started/index.rst:69 -msgid "If the username on the control node is different on the host, you need to pass the ``-u`` option with the ``ansible`` command." -msgstr "コントロールノードのユーザー名がホストで異なる場合は、``ansible`` コマンドで ``-u`` オプションを指定する必要があります。" - -#: ../../rst/getting_started/index.rst:71 -msgid "Ping the managed nodes." -msgstr "管理対象ノードを ping します。" - -#: ../../rst/getting_started/index.rst:80 -msgid "Congratulations! You are now using Ansible. Continue by :ref:`learning how to build an inventory`." -msgstr "おめでとうございます。これで Ansible を使用している状態になりました。:ref:`learning how to build an inventory` に進んでください。" - -#: ../../rst/getting_started/index.rst:85 -msgid "`Ansible Demos `_" -msgstr "`Ansible Demos `_" - -#: ../../rst/getting_started/index.rst:86 -msgid "Demonstrations of different Ansible usecases" -msgstr "各種 Ansible のユースケースのデモ" - -#: ../../rst/getting_started/index.rst:87 -msgid "`Ansible Labs `_" -msgstr "`Ansible Labs `_" - -#: ../../rst/getting_started/index.rst:88 -msgid "Labs to provide further knowledge on different topics" -msgstr "さまざまなトピックでの詳細な知識を提供するラボ" - -#: ../../rst/getting_started/index.rst:89 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/getting_started/index.rst:90 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/getting_started/index.rst:91 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/getting_started/index.rst:92 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#~ msgid "`RHEL Labs `_" -#~ msgstr "`RHEL Labs `_" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/index.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/index.po deleted file mode 100644 index 9a14282476c..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/index.po +++ /dev/null @@ -1,164 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../rst/ansible_index.rst:27 ../../rst/core_index.rst:34 -msgid "Ansible getting started" -msgstr "Ansible スタートガイド" - -#: ../../rst/2.10_index.rst:23 ../../rst/ansible_index.rst:33 -#: ../../rst/core_index.rst:40 -msgid "Installation, Upgrade & Configuration" -msgstr "インストール、アップグレード、および設定" - -#: ../../rst/core_index.rst:47 -msgid "Using Ansible Core" -msgstr "Ansible Core の使用" - -#: ../../rst/core_index.rst:60 -msgid "Contributing to Ansible Core" -msgstr "Ansible Core への貢献" - -#: ../../rst/2.10_index.rst:42 ../../rst/ansible_index.rst:63 -#: ../../rst/core_index.rst:69 -msgid "Extending Ansible" -msgstr "Ansible の拡張" - -#: ../../rst/2.10_index.rst:65 ../../rst/ansible_index.rst:86 -#: ../../rst/core_index.rst:75 -msgid "Ansible Galaxy" -msgstr "Ansible Galaxy" - -#: ../../rst/2.10_index.rst:73 ../../rst/ansible_index.rst:94 -#: ../../rst/core_index.rst:82 -msgid "Reference & Appendices" -msgstr "参照および付録" - -#: ../../rst/2.10_index.rst:102 ../../rst/ansible_index.rst:119 -#: ../../rst/core_index.rst:106 -msgid "Roadmaps" -msgstr "ロードマップ" - -#: ../../rst/core_index.rst:8 -msgid "Ansible Core Documentation" -msgstr "Ansible Core ドキュメント" - -#: ../../rst/core_index.rst:11 -msgid "About ansible-core" -msgstr "ansible-core の概要" - -#: ../../rst/2.10_index.rst:9 ../../rst/ansible_index.rst:11 -#: ../../rst/core_index.rst:13 -msgid "Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates." -msgstr "Ansible は IT 自動化ツールです。このツールを使用すると、システムの構成、ソフトウェアの展開、より高度な IT タスク (継続的なデプロイメント、ダウンタイムなしのローリング更新など) のオーケストレーションが可能になります。" - -#: ../../rst/core_index.rst:15 -msgid "Ansible core, or ``ansible-core`` is the main building block and architecture for Ansible, and includes:" -msgstr "Ansible コアまたは ``ansible-core`` は Ansible の主要なビルディングブロックおよびアーキテクチャーであり、以下が含まれます。" - -#: ../../rst/core_index.rst:17 -msgid "CLI tools such as ``ansible-playbook``, ``ansible-doc``. and others for driving and interacting with automation." -msgstr "自動化で動作や対話を行う ``ansible-playbook``、``ansible-doc`` などの CLI ツール" - -#: ../../rst/core_index.rst:18 -msgid "The Ansible language that uses YAML to create a set of rules for developing Ansible Playbooks and includes functions such as conditionals, blocks, includes, loops, and other Ansible imperatives." -msgstr "YAML を使用して Ansible Playbook を開発するための一連のルールを作成し、conditional、block、include、include、その他の Ansible 命令などの関数を追加する Ansible 言語" - -#: ../../rst/core_index.rst:19 -msgid "An architectural framework that allows extensions through Ansible collections." -msgstr "Ansible コレクションで拡張機能を可能にするアーキテクチャーフレームワーク" - -#: ../../rst/2.10_index.rst:11 ../../rst/ansible_index.rst:13 -#: ../../rst/core_index.rst:21 -msgid "Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program." -msgstr "Ansible の主な目標は、簡単で使いやすいことです。また、セキュリティーおよび信頼性に重点を置いており、最小限の可動部品、トランスポート用の OpenSSH の使用 (代替として他のトランスポートとプルモードを使用)、およびプログラムに精通していない人でも監査を可能にする言語も備えています。" - -#: ../../rst/2.10_index.rst:13 ../../rst/ansible_index.rst:15 -#: ../../rst/core_index.rst:23 -msgid "We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances." -msgstr "簡素化はあらゆる規模の環境に関連しており、開発者、システム管理者、リリースエンジニア、IT マネージャーなど、あらゆるタイプのビジーユーザー向けに設計されています。Ansible は、わずかなインスタンスしかない小規模のセットアップから、インスタンスが数千にもなるエンタープライズ環境まで、すべての環境を管理するのに適しています。" - -#: ../../rst/2.10_index.rst:15 ../../rst/ansible_index.rst:17 -#: ../../rst/core_index.rst:25 -msgid "You can learn more at `AnsibleFest `_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with." -msgstr "詳細は、`AnsibleFest `_ (Red Hat が開催する、Ansible のすべての貢献者、ユーザー、および顧客のための毎年恒例のイベント) で学ぶことができます。AnsibleFest は、他の人とつながり、新しいスキルを学び、自動化に興味のある人達と知り合うためのイベントです。" - -#: ../../rst/2.10_index.rst:17 ../../rst/core_index.rst:27 -msgid "Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems." -msgstr "Ansible は、エージェントを使用せずにマシンを管理します。リモートデーモンをアップグレードする方法や、デーモンがアンインストールされているためにシステムを管理できないという問題はありません。OpenSSH は、相互評価が最も行われるオープンソースコンポーネントの 1 つであるため、セキュリティーの危険性は大幅に軽減されます。Ansible は分散化されており、既存の OS 認証情報を使用して、リモートマシンへのアクセスを制御します。必要に応じて、Ansible は、Kerberos、LDAP、およびその他の集中認証管理システムに簡単に接続できます。" - -#: ../../rst/core_index.rst:29 -msgid "This documentation covers the version of ``ansible-core`` noted in the upper left corner of this page. We maintain multiple versions of ``ansible-core`` and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added." -msgstr "本ドキュメントは、本ページの左上に示されている ``ansible-core`` のバージョンについて説明します。Red Hat は、複数のバージョンの ``ansible-core`` とドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、その機能が追加された Ansible のバージョンが記載されています。" - -#: ../../rst/core_index.rst:32 -msgid "``ansible-core`` releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly." -msgstr "``ansible-core`` は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。バージョン 2.10 以降のコレクションで提供されるモジュールとプラグインは、貢献者によりはるかに迅速に開発および変更されます。" - -#: ../../rst/2.10_index.rst:30 ../../rst/ansible_index.rst:40 -msgid "Using Ansible" -msgstr "Ansible の使用" - -#: ../../rst/2.10_index.rst:36 ../../rst/ansible_index.rst:53 -msgid "Contributing to Ansible" -msgstr "Ansible への貢献" - -#: ../../rst/2.10_index.rst:48 ../../rst/ansible_index.rst:69 -msgid "Common Ansible Scenarios" -msgstr "Ansible の一般的なシナリオ" - -#: ../../rst/2.10_index.rst:57 ../../rst/ansible_index.rst:78 -msgid "Network Automation" -msgstr "ネットワークの自動化" - -#: ../../rst/2.10_index.rst:4 ../../rst/ansible_index.rst:6 -msgid "Ansible Documentation" -msgstr "Ansible ドキュメント" - -#: ../../rst/2.10_index.rst:7 ../../rst/ansible_index.rst:9 -msgid "About Ansible" -msgstr "Ansible の概要" - -#: ../../rst/ansible_index.rst:19 -msgid "Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. Also, security exposure is greatly reduced because Ansible uses OpenSSH — the open source connectivity tool for remote login with the SSH (Secure Shell) protocol." -msgstr "Ansible は、エージェントなしの方法でマシンを管理します。デーモンがアンインストールされているため、リモートデーモンのアップグレード方法に関する疑問や、システムを管理できないなどの問題は発生しません。また、Ansible は SSH (Secure Shell) プロトコルでのリモートログインに、オープンソース接続ツールである OpenSSH を使用するため、セキュリティー脆弱性が大幅に削減されます。" - -#: ../../rst/ansible_index.rst:21 -msgid "Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. And if needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems." -msgstr "Ansible は分散化されており、既存の OS クレデンシャルに依存してリモートマシンへのアクセスを制御します。必要に応じて、Ansible は Kerberos、LDAP、およびその他の集中型認証管理システムに簡単に接続できます。" - -#: ../../rst/ansible_index.rst:23 -msgid "This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and the Ansible documentation, so please be sure you are using the documentation version that covers the version of Ansible you are using. For recent features, we note the version of Ansible where the feature was added." -msgstr "このドキュメントは、このページの左上に示されている Ansible のバージョンについて説明します。Red Hat は、複数のバージョンの Ansible と Ansible ドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、その機能が追加された Ansible のバージョンが記載されています。" - -#: ../../rst/ansible_index.rst:25 -msgid "Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins hosted in collections since version 2.10 much more quickly." -msgstr "Ansible は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。バージョン 2.10 以降のコレクションで提供されるモジュールとプラグインは、貢献者によりはるかに迅速に開発および変更されます。" - -#: ../../rst/2.10_index.rst:98 -msgid "Release Notes" -msgstr "リリースノート" - -#: ../../rst/2.10_index.rst:19 -msgid "This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added." -msgstr "本ドキュメントは、本ページの左上に示されている Ansible のバージョンについて説明します。Red Hat は、複数のバージョンの Ansible とドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、その機能が追加された Ansible のバージョンが記載されています。" - -#: ../../rst/2.10_index.rst:21 -msgid "Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly." -msgstr "Ansible は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。バージョン 2.10 以降のコレクションで提供されるモジュールとプラグインは、貢献者によりはるかに迅速に開発および変更されます。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/installation_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/installation_guide.po deleted file mode 100644 index 022119dfc0e..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/installation_guide.po +++ /dev/null @@ -1,830 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/installation_guide/index.rst:3 -msgid "Installation Guide" -msgstr "インストールガイド" - -#: ../../rst/installation_guide/index.rst:5 -msgid "Welcome to the Ansible Installation Guide!" -msgstr "本ガイドは Ansible インストールガイドです。" - -#: ../../rst/installation_guide/installation_distros.rst:4 -msgid "Installing Ansible on specific operating systems" -msgstr "特定のオペレーティングシステムへの Ansible のインストール" - -#: ../../rst/installation_guide/installation_distros.rst:6 -msgid "The ``ansible`` package can always be :ref:`installed from PyPI using pip ` on most systems but it is also packaged and maintained by the community for a variety of Linux distributions." -msgstr "ほとんどのシステムで ``ansible`` パッケージは常に :ref:`installed from PyPI using pip ` できますが、コミュニティーによってさまざまな Linux ディストリビューション用にパッケージ化および維持されます。" - -#: ../../rst/installation_guide/installation_distros.rst:8 -msgid "The following instructions will guide you through installing the ``ansible`` package with your preferred distribution's package manager." -msgstr "次の手順は、ご希望のディストリビューションのパッケージマネージャーを使用して ``ansible`` パッケージをインストールする方法について説明しています。" - -#: ../../rst/installation_guide/installation_distros.rst:14 -msgid "Installing Ansible on Fedora or CentOS" -msgstr "Fedora または CentOS への Ansible のインストール" - -#: ../../rst/installation_guide/installation_distros.rst:16 -msgid "On Fedora:" -msgstr "Fedora の場合:" - -#: ../../rst/installation_guide/installation_distros.rst:22 -msgid "On CentOS:" -msgstr "CentOS の場合:" - -#: ../../rst/installation_guide/installation_distros.rst:29 -msgid "RPMs for currently supported versions of CentOS are also available from `EPEL `_." -msgstr "現在サポートされている CentOS バージョンの RPM は、`EPEL `_ からも利用できます。" - -#: ../../rst/installation_guide/installation_distros.rst:35 -msgid "Installing Ansible on Ubuntu" -msgstr "Ubuntu への Ansible のインストール" - -#: ../../rst/installation_guide/installation_distros.rst:37 -msgid "Ubuntu builds are available `in a PPA here `_." -msgstr "Ubuntu ビルドは `PPA `_ で利用できます。" - -#: ../../rst/installation_guide/installation_distros.rst:39 -msgid "To configure the PPA on your system and install Ansible run these commands:" -msgstr "使用しているシステム上で PPA を設定して Ansible をインストールするには、次のコマンドを実行します。" - -#: ../../rst/installation_guide/installation_distros.rst:48 -msgid "On older Ubuntu distributions, \"software-properties-common\" is called \"python-software-properties\". You may want to use ``apt-get`` rather than ``apt`` in older versions. Also, be aware that only newer distributions (that is, 18.04, 18.10, and later) have a ``-u`` or ``--update`` flag. Adjust your script as needed." -msgstr "以前の Ubuntu ディストリビューションでは、「software-properties-common」は「python-software-properties」と呼ばれているため、過去のバージョンでは ``apt`` ではなく ``apt-get`` を使用するほうが適している場合があります。また、``-u`` フラグまたは ``--update`` フラグを使用できるのは新しいディストリビューション (18.04、18.10 以降) に限定されることに注意し、必要に応じてスクリプトを調整してください。" - -#: ../../rst/installation_guide/installation_distros.rst:54 -msgid "Installing Ansible on Debian" -msgstr "Ansible の Debian へのインストール" - -#: ../../rst/installation_guide/installation_distros.rst:56 -msgid "Debian users can use the same source as the Ubuntu PPA (using the following table)." -msgstr "Debian ユーザーは Ubuntu PPA と同じソースを使用できます (以下の表を使用)。" - -#: ../../rst/installation_guide/installation_distros.rst:61 -msgid "Debian" -msgstr "Debian" - -#: ../../rst/installation_guide/installation_distros.rst:63 -msgid "Ubuntu" -msgstr "Ubuntu" - -#: ../../rst/installation_guide/installation_distros.rst:64 -msgid "Debian 11 (Bullseye)" -msgstr "Debian 11 (Bullseye)" - -#: ../../rst/installation_guide/installation_distros.rst:65 -#: ../../rst/installation_guide/installation_distros.rst:68 -msgid "->" -msgstr "->" - -#: ../../rst/installation_guide/installation_distros.rst:66 -msgid "Ubuntu 20.04 (Focal)" -msgstr "Ubuntu 20.04 (Focal)" - -#: ../../rst/installation_guide/installation_distros.rst:67 -msgid "Debian 10 (Buster)" -msgstr "Debian 10 (Buster)" - -#: ../../rst/installation_guide/installation_distros.rst:69 -msgid "Ubuntu 18.04 (Bionic)" -msgstr "Ubuntu 18.04 (Bionic)" - -#: ../../rst/installation_guide/installation_distros.rst:74 -msgid "Ansible releases are only built for Ubuntu 18.04 (Bionic) or later releases." -msgstr "Ansible リリースは、Ubuntu 18.04 (Bionic) 以降のリリース用にビルドされています。" - -#: ../../rst/installation_guide/installation_distros.rst:76 -msgid "Add the following line to ``/etc/apt/sources.list`` or ``/etc/apt/sources.list.d/ansible.list``:" -msgstr "以下の行を ``/etc/apt/sources.list`` または ``/etc/apt/sources.list.d/ansible.list`` に追加します。" - -#: ../../rst/installation_guide/installation_distros.rst:82 -msgid "Example for Debian 11 (Bullseye)" -msgstr "Debian 11 の例 (Bullseye)" - -#: ../../rst/installation_guide/installation_distros.rst:88 -msgid "Then run these commands:" -msgstr "次に、以下のコマンドを実行します。" - -#: ../../rst/installation_guide/installation_distros.rst:101 -msgid "Installing Ansible on Windows" -msgstr "Ansible の Windows へのインストール" - -#: ../../rst/installation_guide/installation_distros.rst:103 -msgid "You cannot use a Windows system for the Ansible control node. See :ref:`windows_faq_ansible`" -msgstr "Ansible コントロールノードに Windows システムは使用できません。:ref:`windows_faq_ansible` を参照してください。" - -#: ../../rst/installation_guide/installation_distros.rst:107 -msgid "`Installing Ansible on Arch Linux `_" -msgstr "`Installing Ansible on Arch Linux `_" - -#: ../../rst/installation_guide/installation_distros.rst:108 -msgid "Distro-specific installation on Arch Linux" -msgstr "Arch Linux へのディストリビューション固有のインストール" - -#: ../../rst/installation_guide/installation_distros.rst:109 -msgid "`Installing Ansible on Clear Linux `_" -msgstr "`Installing Ansible on Clear Linux `_" - -#: ../../rst/installation_guide/installation_distros.rst:110 -msgid "Distro-specific installation on Clear Linux" -msgstr "Clear Linux へのディストリビューション固有のインストール" - -#: ../../rst/installation_guide/intro_configuration.rst:5 -msgid "Configuring Ansible" -msgstr "Ansible の設定" - -#: ../../rst/installation_guide/intro_configuration.rst:8 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/installation_guide/intro_configuration.rst:10 -msgid "This topic describes how to control Ansible settings." -msgstr "ここでは、Ansible の設定を制御する方法を説明します。" - -#: ../../rst/installation_guide/intro_configuration.rst:16 -msgid "Configuration file" -msgstr "設定ファイル" - -#: ../../rst/installation_guide/intro_configuration.rst:18 -msgid "Certain settings in Ansible are adjustable via a configuration file (ansible.cfg). The stock configuration should be sufficient for most users, but there may be reasons you would want to change them. Paths where configuration file is searched are listed in :ref:`reference documentation`." -msgstr "Ansible の一部の設定は、設定ファイル (ansible.cfg) で調整できます。ほとんどの場合には stock 設定で十分ですが、変更した方が適している場合もあります。設定ファイルの検索先のパスは「:ref:`参照ドキュメント`」に一覧表示されます。" - -#: ../../rst/installation_guide/intro_configuration.rst:25 -msgid "Getting the latest configuration" -msgstr "最新設定の取得" - -#: ../../rst/installation_guide/intro_configuration.rst:27 -msgid "If installing Ansible from a package manager, the latest ``ansible.cfg`` file should be present in ``/etc/ansible``, possibly as a ``.rpmnew`` file (or other) as appropriate in the case of updates." -msgstr "パッケージマネージャーから Ansible をインストールした場合は、最新の ``ansible.cfg`` ファイルが ``/etc/ansible`` に存在しているはずです。更新では、``.rpmnew`` ファイル (またはその他のファイル) が適切な場合もあります。" - -#: ../../rst/installation_guide/intro_configuration.rst:30 -msgid "If you installed Ansible from pip or from source, you may want to create this file in order to override default settings in Ansible." -msgstr "Ansible を pip またはソースからインストールした場合は、このファイルを作成して Ansible のデフォルト設定をオーバーライドすることもできます。" - -#: ../../rst/installation_guide/intro_configuration.rst:33 -msgid "An `example file is available on GitHub `_." -msgstr "サンプルファイルは `GitHub `_ から入手できます。" - -#: ../../rst/installation_guide/intro_configuration.rst:35 -msgid "For more details and a full listing of available configurations go to :ref:`configuration_settings`. Starting with Ansible version 2.4, you can use the :ref:`ansible-config` command line utility to list your available options and inspect the current values." -msgstr "詳細と利用可能な設定の完全一覧は「:ref:`configuration_settings`」にあります。Ansible バージョン 2.4 以降では、:ref:`ansible-config` コマンドラインユーティリティーを使用して利用可能なオプションの一覧を表示し、現在の値を確認できます。" - -#: ../../rst/installation_guide/intro_configuration.rst:37 -msgid "For in-depth details, see :ref:`ansible_configuration_settings`." -msgstr "詳細は、「:ref:`ansible_configuration_settings`」参照してください。" - -#: ../../rst/installation_guide/intro_configuration.rst:42 -msgid "Environmental configuration" -msgstr "環境設定" - -#: ../../rst/installation_guide/intro_configuration.rst:44 -msgid "Ansible also allows configuration of settings using environment variables. If these environment variables are set, they will override any setting loaded from the configuration file." -msgstr "Ansible では、環境変数を使用した設定も可能です。これらの環境変数が設定されている場合は、設定ファイルから読み込まれた設定はすべて上書きされます。" - -#: ../../rst/installation_guide/intro_configuration.rst:47 -msgid "You can get a full listing of available environment variables from :ref:`ansible_configuration_settings`." -msgstr "「:ref:`ansible_configuration_settings`」は、利用可能な環境変数の詳細な一覧を確認できます。" - -#: ../../rst/installation_guide/intro_configuration.rst:53 -msgid "Command line options" -msgstr "コマンドラインオプション" - -#: ../../rst/installation_guide/intro_configuration.rst:55 -msgid "Not all configuration options are present in the command line, just the ones deemed most useful or common. Settings in the command line will override those passed through the configuration file and the environment." -msgstr "すべての設定オプションがコマンドラインに表示されるわけではなく、最も有用オプションと一般的なオプションのみが表示されます。コマンドラインの設定は、設定ファイルと環境を介して渡された設定を上書きされます。" - -#: ../../rst/installation_guide/intro_configuration.rst:58 -msgid "The full list of options available is in :ref:`ansible-playbook` and :ref:`ansible`." -msgstr "利用可能なオプションの詳細な一覧は「:ref:`ansible-playbook`」および「:ref:`ansible`」にあります。" - -#: ../../rst/installation_guide/intro_installation.rst:6 -#: ../../rst/installation_guide/intro_installation.rst:110 -msgid "Installing Ansible" -msgstr "Ansible のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:8 -msgid "Ansible is an agentless automation tool that you install on a single host (referred to as the control node). From the control node, Ansible can manage an entire fleet of machines and other devices (referred to as managed nodes) remotely with SSH, Powershell remoting, and numerous other transports, all from a simple command-line interface with no databases or daemons required." -msgstr "Ansible は、単一のホスト (コントロールノードと呼ばれる) にインストールするエージェントレス自動化ツールです。Ansible は、コントロールノードから、SSH、Powershell リモート処理、およびその他多数のトランスポートを使用して、マシンやその他のデバイス (管理対象ノードと呼ばれる) のフリート全体をリモートで管理できます。これらはすべて、データベースやデーモンを必要としないシンプルなコマンドラインインターフェイスから実行できます。" - -#: ../../rst/installation_guide/intro_installation.rst:16 -msgid "Control node requirements" -msgstr "コントロールノードの要件" - -#: ../../rst/installation_guide/intro_installation.rst:18 -msgid "For your *control* node (the machine that runs Ansible), you can use nearly any UNIX-like machine with Python 3.9 or newer installed. This includes Red Hat, Debian, Ubuntu, macOS, BSDs, and Windows under a `Windows Subsystem for Linux (WSL) distribution `_. Windows without WSL is not natively supported as a control node; see `Matt Davis' blog post `_ for more information." -msgstr "*コントロール* ノード (Ansible を実行するマシン) には、Python 3.9 以降がインストールされている UNIX のようなマシンをほぼすべて使用できます。これには、`Windows Subsystem for Linux (WSL) distribution `_ に該当する Red Hat、Debian、Ubuntu、macOS、BSD、および Windows が含まれます。WSL のない Windows は、コントロールノードとしてネイティブにサポートされていません。詳細は `Matt Davis' blog post `_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:23 -msgid "Managed node requirements" -msgstr "管理ノードの要件" - -#: ../../rst/installation_guide/intro_installation.rst:25 -msgid "The *managed* node (the machine that Ansible is managing) does not require Ansible to be installed, but requires Python 2.7, or Python 3.5 - 3.11 to run Ansible library code. The managed node also needs a user account that can SSH to the node with an interactive POSIX shell." -msgstr "*管理対象* ノード (Ansible が管理するマシン) は、Ansible のインストールは必要ありませんが、Ansible のライブラリーコードを実行するために Python 2.7、または Python 3.5〜3.11 が必要です。また、管理対象ノードには、対話型 POSIX シェルでノードに SSH 接続できるユーザーアカウントが必要です。" - -#: ../../rst/installation_guide/intro_installation.rst:30 -msgid "Network modules are an exception and do not require Python on the managed device. See :ref:`network_modules`." -msgstr "ネットワークモジュールは例外で、管理デバイスに Python は必要ありません。:ref:`network_modules` を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:35 -msgid "Node requirement summary" -msgstr "ノード要件の概要" - -#: ../../rst/installation_guide/intro_installation.rst:37 -msgid "The table below lists the current and historical versions of Python required on control and managed nodes." -msgstr "以下の表は、制御および管理ノードに必要な Python の現在のバージョンと過去のバージョンを示しています。" - -#: ../../rst/installation_guide/intro_installation.rst:43 -msgid "ansible-core Version" -msgstr "ansible-core バージョン" - -#: ../../rst/installation_guide/intro_installation.rst:44 -msgid "Control node Python" -msgstr "コントロールノード Python" - -#: ../../rst/installation_guide/intro_installation.rst:45 -msgid "Managed node Python" -msgstr "管理対象ノード Python" - -#: ../../rst/installation_guide/intro_installation.rst:46 -msgid "2.11" -msgstr "2.11" - -#: ../../rst/installation_guide/intro_installation.rst:47 -msgid "Python 2.7, Python 3.5 - 3.9 `[†]`_" -msgstr "Python 2.7, Python 3.5 - 3.9 `[†]`_" - -#: ../../rst/installation_guide/intro_installation.rst:48 -msgid "Python 2.6 - 2.7, Python 3.5 - 3.9" -msgstr "Python 2.6 - 2.7, Python 3.5 - 3.9" - -#: ../../rst/installation_guide/intro_installation.rst:49 -msgid "2.12" -msgstr "2.12" - -#: ../../rst/installation_guide/intro_installation.rst:50 -#: ../../rst/installation_guide/intro_installation.rst:53 -msgid "Python 3.8 - 3.10" -msgstr "Python 3.8 - 3.10" - -#: ../../rst/installation_guide/intro_installation.rst:51 -msgid "Python 2.6 - 2.7, Python 3.5 - 3.10" -msgstr "Python 2.6 - 2.7, Python 3.5 - 3.10" - -#: ../../rst/installation_guide/intro_installation.rst:52 -msgid "2.13" -msgstr "2.13" - -#: ../../rst/installation_guide/intro_installation.rst:54 -msgid "Python 2.7, Python 3.5 - 3.10" -msgstr "Python 2.7, Python 3.5 - 3.10" - -#: ../../rst/installation_guide/intro_installation.rst:55 -msgid "2.14" -msgstr "2.14" - -#: ../../rst/installation_guide/intro_installation.rst:56 -msgid "Python 3.9 - 3.11" -msgstr "Python 3.9 - 3.11" - -#: ../../rst/installation_guide/intro_installation.rst:57 -msgid "Python 2.7, Python 3.5 - 3.11" -msgstr "Python 2.7, Python 3.5 - 3.11" - -#: ../../rst/installation_guide/intro_installation.rst:59 -msgid "_`[†]`: Has a soft requirement of Python 3.8 as not packaged for older versions" -msgstr "_`[†]`: 古いバージョンにはパッケージ化されていないため、Python 3.8 のソフト要件があります。" - -#: ../../rst/installation_guide/intro_installation.rst:66 -msgid "Selecting an Ansible package and version to install" -msgstr "インストールする Ansible パッケージおよびバージョンの選択" - -#: ../../rst/installation_guide/intro_installation.rst:68 -msgid "Ansible's community packages are distributed in two ways: a minimalist language and runtime package called ``ansible-core``, and a much larger \"batteries included\" package called ``ansible``, which adds a community-curated selection of :ref:`Ansible Collections ` for automating a wide variety of devices. Choose the package that fits your needs; The following instructions use ``ansible``, but you can substitute ``ansible-core`` if you prefer to start with a more minimal package and separately install only the Ansible Collections you require. The ``ansible`` or ``ansible-core`` packages may be available in your operating systems package manager, and you are free to install these packages with your preferred method. These installation instructions only cover the officially supported means of installing the python package with ``pip``." -msgstr "Ansible のコミュニティーパッケージは、``ansible-core`` と呼ばれる最小言語およびランタイムパッケージと、``ansible`` と呼ばれる大きな「バッテリー付き」パッケージの 2 つの方法で配布されています。これには、幅広いデバイスの自動化のためにコミュニティーが厳選した :ref:`Ansible Collections ` が追加されています。ニーズに合わせてパッケージを選択してください。以下の手順では ``ansible`` を使用していますが、最小限のパッケージで開始して必要な Ansible コレクションのみ個別にインストールする場合は ``ansible-core`` を使用できます。``ansible`` パッケージまたは ``ansible-core`` パッケージは、お使いのオペレーティングシステムパッケージマネージャーで使用できる場合があります。お好みの方法でパッケージをインストールしてください。これらのインストール手順は、``pip`` を使用して Python パッケージをインストールする、正式なサポート対象の方法に限定されています。" - -#: ../../rst/installation_guide/intro_installation.rst:71 -msgid "Installing and upgrading Ansible" -msgstr "Ansible のインストールとアップグレード" - -#: ../../rst/installation_guide/intro_installation.rst:74 -msgid "Locating Python" -msgstr "Python の検索" - -#: ../../rst/installation_guide/intro_installation.rst:76 -msgid "Locate and remember the path to the Python interpreter you wish to use to run Ansible. The following instructions refer to this Python as ``python3``. For example, if you've determined that you want the Python at ``/usr/bin/python3.9`` to be the one that you'll install Ansible under, specify that instead of ``python3``." -msgstr "Ansible の実行に使用する Python インタープリターへのパスを見つけて覚えておいてください。以下の手順は、この Python を ``python3`` として参照します。たとえば、``/usr/bin/python3.9`` の Python に Ansible をインストールする場合は、``python3`` の代わりにその Python を指定します。" - -#: ../../rst/installation_guide/intro_installation.rst:79 -msgid "Ensuring ``pip`` is available" -msgstr "``pip`` が利用可能か確認しています" - -#: ../../rst/installation_guide/intro_installation.rst:81 -msgid "To verify whether ``pip`` is already installed for your preferred Python:" -msgstr "目的の Python 用に ``pip`` がすでにインストールされているか確認するには、以下を実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:87 -msgid "If all is well, you should see something like the following:" -msgstr "すべてが正常な場合は、以下のように表示されます。" - -#: ../../rst/installation_guide/intro_installation.rst:94 -msgid "If so, ``pip`` is available, and you can move on to the :ref:`next step `." -msgstr "その場合は ``pip`` が利用可能です。:ref:`next step ` に進んでください。" - -#: ../../rst/installation_guide/intro_installation.rst:96 -msgid "If you see an error like ``No module named pip``, you'll need to install ``pip`` under your chosen Python interpreter before proceeding. This may mean installing an additional OS package (for example, ``python3-pip``), or installing the latest ``pip`` directly from the Python Packaging Authority by running the following:" -msgstr "``No module named pip`` のようなエラーが表示された場合は、続行する前に、選択した Python インタープリターに ``pip`` をインストールする必要があります。そうなると、追加の OS パッケージ (例: ``python3-pip``) をインストールするか、以下を実行して Python Packaging Authority から直接最新の ``pip`` をインストールすることになります。" - -#: ../../rst/installation_guide/intro_installation.rst:103 -msgid "You may need to perform some additional configuration before you are able to run Ansible. See the Python documentation on `installing to the user site`_ for more information." -msgstr "Ansible を実行する前に追加の設定が必要になる場合があります。詳細は、Python ドキュメント「`ユーザーサイトへのインストール`_」を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:112 -msgid "Use ``pip`` in your selected Python environment to install the Ansible package of your choice for the current user:" -msgstr "選択した Python 環境で ``pip`` を使用し、現在のユーザー用に選択した Ansible パッケージをインストールします。" - -#: ../../rst/installation_guide/intro_installation.rst:118 -msgid "Alternately, you can install a specific version of ``ansible-core`` in this Python environment:" -msgstr "または、この Python 環境に特定のバージョンの ``ansible-core`` をインストールすることもできます。" - -#: ../../rst/installation_guide/intro_installation.rst:127 -msgid "Upgrading Ansible" -msgstr "Ansible のアップグレード" - -#: ../../rst/installation_guide/intro_installation.rst:129 -msgid "To upgrade an existing Ansible installation in this Python environment to the latest released version, simply add ``--upgrade`` to the command above:" -msgstr "この Python 環境の既存の Ansible インストールを最新のリリースバージョンにアップグレードするには、上記のコマンドに ``--upgrade`` を追加します。" - -#: ../../rst/installation_guide/intro_installation.rst:136 -msgid "Confirming your installation" -msgstr "インストールの確認" - -#: ../../rst/installation_guide/intro_installation.rst:138 -msgid "You can test that Ansible is installed correctly by checking the version:" -msgstr "バージョンを確認して、Ansible が正しくインストールされたことをテストできます。" - -#: ../../rst/installation_guide/intro_installation.rst:144 -msgid "The version displayed by this command is for the associated ``ansible-core`` package that has been installed." -msgstr "このコマンドで表示されるバージョンは、関連するインストール済みの ``ansible-core`` パッケージです。" - -#: ../../rst/installation_guide/intro_installation.rst:146 -msgid "To check the version of the ``ansible`` package that has been installed:" -msgstr "インストールされている ``ansible`` パッケージのバージョンを確認するには、以下を実行します。" - -#: ../../rst/installation_guide/intro_installation.rst:155 -msgid "Installing for development" -msgstr "開発用のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:157 -msgid "If you are testing new features, fixing bugs, or otherwise working with the development team on changes to the core code, you can install and run the source from GitHub." -msgstr "新機能のテスト、バグの修正、またはコアコードへの変更に対して開発チームでの作業を行う場合は、GitHub からソースをインストールして実行できます。て実行できます。" - -#: ../../rst/installation_guide/intro_installation.rst:161 -msgid "You should only install and run the ``devel`` branch if you are modifying ``ansible-core`` or trying out features under development. This is a rapidly changing source of code and can become unstable at any point." -msgstr "開発時に ``ansible-core`` を変更し、機能を試す場合は、``devel`` ブランチのみをインストールし、実行してください。このソースコードは急速に変化するため、いつでも不安定になる可能性があります。" - -#: ../../rst/installation_guide/intro_installation.rst:163 -msgid "For more information on getting involved in the Ansible project, see the :ref:`ansible_community_guide`. For more information on creating Ansible modules and Collections, see the :ref:`developer_guide`." -msgstr "Ansible プロジェクトへの貢献の詳細は、「:ref:`ansible_community_guide`」を参照してください。Ansible モジュールおよびコレクションの作成方法は、「:ref:`developer_guide`」を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:168 -msgid "Installing ``devel`` from GitHub with ``pip``" -msgstr "``pip`` を使用した GitHub からの ``devel`` のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:170 -msgid "You can install the ``devel`` branch of ``ansible-core`` directly from GitHub with ``pip``:" -msgstr "``pip`` を使用して、``ansible-core`` の ``devel`` ブランチを直接 GitHub からインストールできます。" - -#: ../../rst/installation_guide/intro_installation.rst:176 -msgid "You can replace ``devel`` in the URL mentioned above, with any other branch or tag on GitHub to install older versions of Ansible, tagged alpha or beta versions, and release candidates." -msgstr "上記の URL の ``devel`` を、他のブランチまたは GitHub のタグに置き換えて、古いバージョンの Ansible、タグ付けされた alpha または beta バージョン、およびリリース候補をインストールします。" - -#: ../../rst/installation_guide/intro_installation.rst:181 -msgid "Running the ``devel`` branch from a clone" -msgstr "クローンからの ``devel`` ブランチの実行" - -#: ../../rst/installation_guide/intro_installation.rst:183 -msgid "``ansible-core`` is easy to run from source. You do not need ``root`` permissions to use it and there is no software to actually install. No daemons or database setup are required." -msgstr "``ansible-core`` ソースからの実行は簡単です。``root`` パーミッションは必要ありません。実際にインストールするソフトウェアはありません。デーモンやデータベース設定は必要ありません。" - -#: ../../rst/installation_guide/intro_installation.rst:185 -msgid "Clone the ``ansible-core`` repository" -msgstr "``ansible-core`` リポジトリーのクローンを作成します" - -#: ../../rst/installation_guide/intro_installation.rst:192 -msgid "Setup the Ansible environment" -msgstr "Ansible 環境を設定します" - -#: ../../rst/installation_guide/intro_installation.rst:194 -msgid "Using Bash" -msgstr "Bash の使用" - -#: ../../rst/installation_guide/intro_installation.rst:200 -msgid "Using Fish" -msgstr "Fish の使用" - -#: ../../rst/installation_guide/intro_installation.rst:206 -msgid "To suppress spurious warnings/errors, use ``-q``" -msgstr "誤った警告やエラーが表示されないようにするには、``-q`` を使用します" - -#: ../../rst/installation_guide/intro_installation.rst:212 -msgid "Install Python dependencies" -msgstr "Python の依存関係をインストールします" - -#: ../../rst/installation_guide/intro_installation.rst:218 -msgid "Update the ``devel`` branch of ``ansible-core`` on your local machine" -msgstr "ローカルマシンで ``ansible-core`` の ``devel`` ブランチを更新します" - -#: ../../rst/installation_guide/intro_installation.rst:220 -msgid "Use pull-with-rebase so any local changes are replayed." -msgstr "pull-with-rebase を使用してローカルの変更がリプレイされるようにします。" - -#: ../../rst/installation_guide/intro_installation.rst:229 -msgid "Adding Ansible command shell completion" -msgstr "Ansible コマンドシェル補完の追加" - -#: ../../rst/installation_guide/intro_installation.rst:231 -msgid "You can add shell completion of the Ansible command line utilities by installing an optional dependency called ``argcomplete``. ``argcomplete`` supports bash, and has limited support for zsh and tcsh." -msgstr "``argcomplete`` と呼ばれる任意の依存関係をインストールして、Ansible コマンドラインユーティリティーのシェル補完を追加できます。``argcomplete`` は bash をサポートし、制限付きで zsh および tcsh のサポートをサポートします。" - -#: ../../rst/installation_guide/intro_installation.rst:233 -msgid "For more information about installation and configuration, see the `argcomplete documentation `_." -msgstr "インストールと設定の詳細は、`argcomplete ドキュメント `_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:236 -msgid "Installing ``argcomplete``" -msgstr "``argcomplete`` のインストール" - -#: ../../rst/installation_guide/intro_installation.rst:243 -msgid "Configuring ``argcomplete``" -msgstr "``argcomplete`` の設定" - -#: ../../rst/installation_guide/intro_installation.rst:245 -msgid "There are 2 ways to configure ``argcomplete`` to allow shell completion of the Ansible command line utilities: globally or per command." -msgstr "Ansible コマンドラインユーティリティーのシェル補完を可能にする ``argcomplete`` の設定方法は、2 通りあります。" - -#: ../../rst/installation_guide/intro_installation.rst:248 -msgid "Global configuration" -msgstr "グローバル設定" - -#: ../../rst/installation_guide/intro_installation.rst:250 -msgid "Global completion requires bash 4.2." -msgstr "グローバル補完には bash 4.2 が必要です。" - -#: ../../rst/installation_guide/intro_installation.rst:256 -msgid "This will write a bash completion file to a user location. Use ``--dest`` to change the location or ``sudo`` to set up the completion globally." -msgstr "これにより、bash 補完ファイルがユーザーのロケーションに書き込まれます。ロケーションを変更するには ``--dest`` を使用し、補完の設定は ``sudo`` を使用します。" - -#: ../../rst/installation_guide/intro_installation.rst:259 -msgid "Per command configuration" -msgstr "コマンドごとの設定" - -#: ../../rst/installation_guide/intro_installation.rst:261 -msgid "If you do not have bash 4.2, you must register each script independently." -msgstr "bash 4.2 がない場合は、各スクリプトを個別に登録する必要があります。" - -#: ../../rst/installation_guide/intro_installation.rst:275 -msgid "You should place the above commands into your shells profile file such as ``~/.profile`` or ``~/.bash_profile``." -msgstr "上記のコマンドを、``~/.profile``、``~/.bash_profile`` などのシェルプロファイルファイルに置く必要があります。" - -#: ../../rst/installation_guide/intro_installation.rst:278 -msgid "Using ``argcomplete`` with zsh or tcsh" -msgstr "zsh または tcsh で ``argcomplete`` を使用" - -#: ../../rst/installation_guide/intro_installation.rst:280 -msgid "See the `argcomplete documentation `_." -msgstr "`argcomplete ドキュメント `_ を参照してください。" - -#: ../../rst/installation_guide/intro_installation.rst:285 -msgid ":ref:`intro_adhoc`" -msgstr ":ref:`intro_adhoc`" - -#: ../../rst/installation_guide/intro_installation.rst:286 -msgid "Examples of basic commands" -msgstr "基本コマンドの例" - -#: ../../rst/installation_guide/intro_installation.rst:287 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/installation_guide/intro_installation.rst:288 -msgid "Learning ansible's configuration management language" -msgstr "Ansible の設定管理言語の概要" - -#: ../../rst/installation_guide/intro_installation.rst:289 -msgid ":ref:`installation_faqs`" -msgstr ":ref:`installation_faqs`" - -#: ../../rst/installation_guide/intro_installation.rst:290 -msgid "Ansible Installation related to FAQs" -msgstr "FAQ に関連する Ansible インストール" - -#: ../../rst/installation_guide/intro_installation.rst:291 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/installation_guide/intro_installation.rst:292 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/installation_guide/intro_installation.rst:293 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/installation_guide/intro_installation.rst:294 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#~ msgid "This page describes how to install Ansible on different platforms. Ansible is an agentless automation tool that by default manages machines over the SSH protocol. Once installed, Ansible does not add a database, and there will be no daemons to start or keep running. You only need to install it on one machine (which could easily be a laptop) and it can manage an entire fleet of remote machines from that central point. When Ansible manages remote machines, it does not leave software installed or running on them, so there's no real question about how to upgrade Ansible when moving to a new version." -#~ msgstr "ここでは、さまざまなプラットフォームに Ansible をインストールする方法を説明します。Ansible は、デフォルトで SSH プロトコルを介してマシンを管理するエージェントレス自動化ツールです。インストールしても、Ansible はデータベースを追加せず、起動または稼働し続けるデーモンもありません。Ansible を 1 台のマシン (ラップトップでも可) にインストールするだけで、そのマシンからリモートマシン全体を一元管理できます。Ansible がリモートマシンを管理する場合は、ソフトウェアをマシンにインストールしたまま、あるいは実行したままにすることがないため、新しいバージョンに移行する際に Ansible のアップグレードが問題になることはありません。" - -#~ msgid "Prerequisites" -#~ msgstr "要件" - -#~ msgid "You install Ansible on a control node, which then uses SSH (by default) to communicate with your managed nodes (those end devices you want to automate)." -#~ msgstr "Ansible をコントロールノードにインストールし、SSH (デフォルト) を使用して管理ノード (自動化するエンドデバイス) と通信します。" - -#~ msgid "Currently Ansible can be run from any machine with Python 2 (version 2.7) or Python 3 (versions 3.5 and higher) installed. Ansible 2.11 will make Python 3.8 a soft dependency for the control node, but will function with the aforementioned requirements. Ansible 2.12 will require Python 3.8 or newer to function on the control node. Starting with Ansible 2.11, the project will only be packaged for Python 3.8 and newer. This includes Red Hat, Debian, CentOS, macOS, any of the BSDs, and so on. Windows is not supported for the control node, read more about this in `Matt Davis's blog post `_." -#~ msgstr "現在、Ansible は、Python 2 (バージョン 2.7) または Python 3 (バージョン 3.5 以降) がインストールされていればどのマシンからでも実行できます。Ansible 2.11 は、Python 3.8 をコントロールノードのソフト依存関係にしますが、前述の要件で機能します。Ansible 2.12 のコントロールノードで機能するには、Python 3.8 以降が必要です。Ansible 2.11 以降では、このプロジェクトは Python 3.8 以降に対してのみパッケージ化されます。これには、Red Hat、Debian、CentOS、MacOS をはじめ、各種 BSD などが含まれます。コントロールノードでは、Windows のサポートはありません。詳細は、`Matt Davis's blog post `_ を参照してください。" - -#~ msgid "When choosing a control node, bear in mind that any management system benefits from being run near the machines being managed. If you are running Ansible in a cloud, consider running it from a machine inside that cloud. In most cases this will work better than on the open Internet." -#~ msgstr "コントロールノードを選択するときは、管理対象のマシンの近くで実行することに利点があることを念頭に置いてください。Ansible をクラウドで実行している場合は、そのクラウド内のマシンから実行することを検討してください。ほとんどの場合は、オープンなインターネット上で実行するよりも、同じクラウド内から実行するほうが適切です。" - -#~ msgid "macOS by default is configured for a small number of file handles, so if you want to use 15 or more forks you'll need to raise the ulimit with ``sudo launchctl limit maxfiles unlimited``. This command can also fix any \"Too many open files\" error." -#~ msgstr "MacOS はデフォルトで、少数のファイルハンドル向けに設定されているため、15 個以上のフォークを使用する場合は、``sudo launchctl limit maxfiles unlimited`` を使用して ulimit を増やす必要があります。このコマンドは、「Too many open files」エラーを修正することもできます。" - -#~ msgid "Ansible 2.11 will make Python 3.8 a soft dependency for the control node, but will function with the aforementioned requirements. Ansible 2.12 will require Python 3.8 or newer to function on the control node. Starting with Ansible 2.11, the project will only be packaged for Python 3.8 and newer." -#~ msgstr "Ansible 2.11 は、Python 3.8 をコントロールノードのソフト依存関係にしますが、前述の要件で機能します。Ansible 2.12 では、コントロールノードで機能するために Python3.8 以降が必要です。Ansible 2.11 以降、プロジェクトは Python 3.8 以降でのみパッケージ化されます。" - -#~ msgid "Please note that some modules and plugins have additional requirements. For modules these need to be satisfied on the 'target' machine (the managed node) and should be listed in the module specific docs." -#~ msgstr "モジュールやプラグインには追加の要件があることに注意してください。モジュールについては、「ターゲット」マシン (管理対象ノード) でこの追加要件を満たす必要があります。これについては各モジュールのドキュメントに記載されています。" - -#~ msgid "On the managed nodes, you need a way to communicate, which is normally SSH. By default this uses SFTP. If that's not available, you can switch to SCP in :ref:`ansible.cfg `. You also need Python 2 (version 2.6 or later) or Python 3 (version 3.5 or later)." -#~ msgstr "管理ノードでは通信手段が必要です。通常は SSH が使用されます。デフォルトでは SFTP が使用されます。SFTP を使用できない場合は、:ref:`ansible.cfg ` で SCP に切り替えることができます。Python 2 (バージョン 2.6 以降) または Python 3 (バージョン 3.5 以降) も 必要になります。" - -#~ msgid "If you have SELinux enabled on remote nodes, you will also want to install libselinux-python on them before using any copy/file/template related functions in Ansible. You can use the :ref:`yum module` or :ref:`dnf module` in Ansible to install this package on remote systems that do not have it." -#~ msgstr "リモートノードで SELinux を有効にしている場合は、Ansible でコピー/ファイル/テンプレート関連の機能を使用する前に、libselinux-python をインストールすることもできます。リモートシステムにこのパッケージがインストールされていない場合は、Ansible で :ref:`yum モジュール` または :ref:`dnf モジュール` を使用してインストールできます。" - -#~ msgid "By default, before the first Python module in a playbook runs on a host, Ansible attempts to discover a suitable Python interpreter on that host. You can override the discovery behavior by setting the :ref:`ansible_python_interpreter` inventory variable to a specific interpreter, and in other ways. See :ref:`interpreter_discovery` for details." -#~ msgstr "デフォルトでは、Playbook の最初の Python モジュールがホストで実行される前に、Ansible はそのホストで適切な Python インタープリターを検出しようとします。検出動作は、:ref:`ansible_python_interpreter` インベントリー変数を特定のインタープリターに設定でき、その他の方法で無効にできます。詳細は、「:ref:`interpreter_discovery`」を参照してください。" - -#~ msgid "Ansible's :ref:`raw module`, and the :ref:`script module`, do not depend on a client side install of Python to run. Technically, you can use Ansible to install a compatible version of Python using the :ref:`raw module`, which then allows you to use everything else. For example, if you need to bootstrap Python 2 onto a RHEL-based system, you can install it as follows:" -#~ msgstr "Ansible の :ref:`raw モジュール` および :ref:`script モジュール` は、実行する Python のクライアント側インストールに依存しません。技術的には、Ansible を使用して :ref:`raw モジュール` を使用して互換性のあるバージョンの Python をインストールできます。これ以外のものをすべて使用できます。たとえば、Python 2 を RHEL ベースのシステムにブートストラップする必要がある場合は、以下のようにインストールできます。" - -#~ msgid "Which Ansible version to install is based on your particular needs. You can choose any of the following ways to install Ansible:" -#~ msgstr "インストールする Ansible バージョンは、特定のニーズに基づいて決定します。Ansible をインストールするには、以下のいずれかの方法を選択できます。" - -#~ msgid "Install the latest release with your OS package manager (for Red Hat Enterprise Linux (TM), CentOS, Fedora, Debian, or Ubuntu)." -#~ msgstr "OS パッケージマネージャー (Red Hat Enterprise Linux (TM)、CentOS、Fedora、Debian、または Ubuntu の場合) を使用して最新リリースをインストールします。" - -#~ msgid "Install with ``pip`` (the Python package manager)." -#~ msgstr "``pip`` (Python パッケージマネージャー) でインストールします。" - -#~ msgid "Install ``ansible-base`` from source to access the development (``devel``) version to develop or test the latest features." -#~ msgstr "ソースから ``ansible-base`` インストールして開発 (``devel``) バージョンにアクセスし、最新の機能を開発またはテストします。" - -#~ msgid "You should only run ``ansible-base`` from ``devel`` if you are modifying ``ansible-base``, or trying out features under development. This is a rapidly changing source of code and can become unstable at any point." -#~ msgstr "``devel`` から ``ansible-base`` を実行するのは、``ansible-base`` を変更する場合や、開発時に機能を試す場合にしてください。これはコードのソースが素早く変更し、いつでも不安定になる可能性があります。" - -#~ msgid "Ansible creates new releases two to three times a year. Due to this short release cycle, minor bugs will generally be fixed in the next release rather than maintaining backports on the stable branch. Major bugs will still have maintenance releases when needed, though these are infrequent." -#~ msgstr "Ansible のリリースは、年に 2 ~ 3 回作成されます。リリースサイクルがこのように短いため、マイナーなバグは通常、安定したブランチでバックポートを維持するのではなく、次のリリースで修正されます。メジャーバグについては、必要なときにメンテナンスリリースが行われますが、このようなことはあまり頻繁には起こりません。" - -#~ msgid "Installing Ansible on RHEL, CentOS, or Fedora" -#~ msgstr "RHEL、CentOS、または Fedora への Ansible のインストール" - -#~ msgid "On RHEL:" -#~ msgstr "RHEL の場合:" - -#~ msgid "RPMs for RHEL 7 and RHEL 8 are available from the `Ansible Engine repository `_." -#~ msgstr "RHEL 7 および RHEL 8 の RPM は、`Ansible Engine リポジトリー `_ から入手できます。" - -#~ msgid "To enable the Ansible Engine repository for RHEL 8, run the following command:" -#~ msgstr "RHEL 8 用の Ansible Engine リポジトリーを有効にするには、以下のコマンドを実行します。" - -#~ msgid "To enable the Ansible Engine repository for RHEL 7, run the following command:" -#~ msgstr "RHEL 7 用の Ansible Engine リポジトリーを有効にするには、以下のコマンドを実行します。" - -#~ msgid "Since Ansible 2.10 for RHEL is not available at this time, continue to use Ansible 2.9." -#~ msgstr "現在、RHEL では Ansible 2.10 が利用できないため、引き続き Ansible 2.9 を使用してください。" - -#~ msgid "Ansible can manage older operating systems that contain Python 2.6 or higher." -#~ msgstr "Ansible は、Python 2.6 以降が含まれる古いオペレーティングシステムを管理できます。" - -#~ msgid "Debian/Ubuntu packages can also be built from the source checkout, run:" -#~ msgstr "Debian/Ubuntu パッケージは、ソースチェックアウトから構築することもできます。以下を実行します。" - -#~ msgid "You may also wish to run from source to get the development branch, which is covered below." -#~ msgstr "ソースから実行して開発ブランチを取得することも可能です。この点については以下で説明します。" - -#~ msgid "This method has been verified with the Trusty sources in Debian Jessie and Stretch but may not be supported in earlier versions. You may want to use ``apt-get`` instead of ``apt`` in older versions." -#~ msgstr "このメソッドは、Debian Jessie および Stretch の Trusty ソースで検証されていますが、以前のバージョンではサポートされない場合があります。以前のバージョンでは、``apt`` の代わりに ``apt-get`` を使用できます。" - -#~ msgid "Installing Ansible on Gentoo with portage" -#~ msgstr "portage を使用した Gentoo への Ansible のインストール" - -#~ msgid "To install the newest version, you may need to unmask the Ansible package prior to emerging:" -#~ msgstr "最新バージョンをインストールするには、インストールする前に Ansible パッケージのマスク解除が必要になる場合があります。" - -#~ msgid "Installing Ansible on FreeBSD" -#~ msgstr "FreeBSD への Ansible のインストール" - -#~ msgid "Though Ansible works with both Python 2 and 3 versions, FreeBSD has different packages for each Python version. So to install you can use:" -#~ msgstr "Ansible は Python 2 および 3 の両バージョンで動作しますが、FreeBSD パッケージは各 Python バージョンで異なります。したがって、インストールには、以下を使用できます。" - -#~ msgid "or:" -#~ msgstr "または" - -#~ msgid "You may also wish to install from ports, run:" -#~ msgstr "ポートからインストールすることもできます。以下を実行します。" - -#~ msgid "You can also choose a specific version, for example ``ansible25``." -#~ msgstr "特定のバージョン (例: ``ansible25``) を選択することもできます。" - -#~ msgid "Older versions of FreeBSD worked with something like this (substitute for your choice of package manager):" -#~ msgstr "以前のバージョンの FreeBSD は、以下のようなもので動作します (パッケージマネージャーの代わりです)。" - -#~ msgid "Installing Ansible on macOS" -#~ msgstr "MacOS への Ansible のインストール" - -#~ msgid "The preferred way to install Ansible on a Mac is with ``pip``." -#~ msgstr "Mac に Ansible をインストールするには ``pip`` を使用することが推奨されます。" - -#~ msgid "The instructions can be found in :ref:`from_pip`. If you are running macOS version 10.12 or older, then you should upgrade to the latest ``pip`` to connect to the Python Package Index securely. It should be noted that pip must be run as a module on macOS, and the linked ``pip`` instructions will show you how to do that." -#~ msgstr "手順は「:ref:`from_pip`」を参照してください。MacOS バージョン 10.12 以前を実行している場合に、Python Package Index に安全に接続するには最新の ``pip`` にアップグレードする必要があります。pip は、MacOS でモジュールとして実行する必要があり、リンクされている ``pip`` の手順にその実行方法が示されることに注意してください。" - -#~ msgid "If you have Ansible 2.9 or older installed, you need to use ``pip uninstall ansible`` first to remove older versions of Ansible before re-installing it." -#~ msgstr "Ansible 2.9 以前のバージョンをインストールしている場合は、先に ``pip uninstall ansible`` を使用して古いバージョンの Ansible を削除してから再インストールする必要があります。" - -#~ msgid "If you are installing on macOS Mavericks (10.9), you may encounter some noise from your compiler. A workaround is to do the following::" -#~ msgstr "MacOS Mavericks (10.9) にインストールする場合は、コンパイラーから何らかの問題が発生する可能性があります。回避策として、以下を行います。" - -#~ msgid "Ansible is available for Solaris as `SysV package from OpenCSW `_." -#~ msgstr "Solaris では、`SysV package from OpenCSW `_ として Ansible を利用できます。" - -#~ msgid "Installing Ansible on Arch Linux" -#~ msgstr "Arch Linux への Ansible のインストール" - -#~ msgid "Ansible is available in the Community repository::" -#~ msgstr "Ansible は、コミュニティーリポジトリーから入手できます::" - -#~ msgid "The AUR has a PKGBUILD for pulling directly from GitHub called `ansible-git `_." -#~ msgstr "AUR には、(`ansible-git `_ と呼ばれている) GitHub から直接プルするための PKGBUILD があります。" - -#~ msgid "Also see the `Ansible `_ page on the ArchWiki." -#~ msgstr "ArchWiki の「`Ansible `_」ページを参照してください。" - -#~ msgid "Installing Ansible on Slackware Linux" -#~ msgstr "Slackware Linux への Ansible のインストール" - -#~ msgid "Ansible build script is available in the `SlackBuilds.org `_ repository. Can be built and installed using `sbopkg `_." -#~ msgstr "Ansible ビルドスクリプトは `SlackBuilds.org `_ リポジトリーから利用できます。`sbopkg `_ を使用してビルドおよびインストールできます。" - -#~ msgid "Create queue with Ansible and all dependencies::" -#~ msgstr "Ansible およびすべての依存関係を含むキューを作成します::" - -#~ msgid "Build and install packages from a created queuefile (answer Q for question if sbopkg should use queue or package)::" -#~ msgstr "作成した queuefile からパッケージを構築してインストールします (sbopkg がキューまたはパッケージを使用する必要がある場合の問題への回答 Q)::" - -#~ msgid "Installing Ansible on Clear Linux" -#~ msgstr "Clear Linux への Ansible のインストール" - -#~ msgid "Ansible and its dependencies are available as part of the sysadmin host management bundle::" -#~ msgstr "Ansible およびその依存関係は、sysadmin ホスト管理バンドルの一部として利用できます::" - -#~ msgid "Update of the software will be managed by the swupd tool::" -#~ msgstr "ソフトウェアの更新は、swupd ツールにより管理されます::" - -#~ msgid "Installing Ansible with ``pip``" -#~ msgstr "``pip`` を使用した Ansible のインストール" - -#~ msgid "Ansible can be installed with ``pip``, the Python package manager. If ``pip`` isn't already available on your system of Python, run the following commands to install it::" -#~ msgstr "Python パッケージマネージャーである ``pip`` で Ansible をインストールできます。``pip`` が Python のシステムで利用できない場合は、以下のコマンドを実行してインストールします。" - -#~ msgid "Then install Ansible [1]_::" -#~ msgstr "次に Ansible [1]_ をインストールします::" - -#~ msgid "In order to use the ``paramiko`` connection plugin or modules that require ``paramiko``, install the required module [2]_::" -#~ msgstr "``paramiko`` を必要とする ``paramiko`` 接続プラグインまたはモジュールを使用するには、必要なモジュール [2]_ をインストールします。" - -#~ msgid "If you wish to install Ansible globally, run the following commands::" -#~ msgstr "Ansible をグローバルにインストールする場合は、以下のコマンドを実行します::" - -#~ msgid "Running ``pip`` with ``sudo`` will make global changes to the system. Since ``pip`` does not coordinate with system package managers, it could make changes to your system that leaves it in an inconsistent or non-functioning state. This is particularly true for macOS. Installing with ``--user`` is recommended unless you understand fully the implications of modifying global files on the system." -#~ msgstr "``sudo`` で ``pip`` を実行すると、システムにグローバルの変更が行われます。``pip`` はシステムパッケージマネージャーと連携しないため、システムに変更が加えられ、システムが一貫性のない状態または機能しない状態になる可能性があります。これは特に MacOS に当てはまります。システム上のグローバルファイルを変更した場合の影響を完全に理解していない限り、``--user`` でインストールすることが推奨されます。" - -#~ msgid "Older versions of ``pip`` default to http://pypi.python.org/simple, which no longer works. Please make sure you have the latest version of ``pip`` before installing Ansible. If you have an older version of ``pip`` installed, you can upgrade by following `pip's upgrade instructions `_ ." -#~ msgstr "古いバージョンの ``pip`` は、http://pypi.python.org/simple がデフォルトとなります。これは有効ではなくなりました。Ansible をインストールする前に、``pip`` の最新バージョンをお持ちであることを確認してください。古いバージョンの ``pip`` がインストールされている場合は、`pip のアップグレード手順 `_ でアップグレードできます。" - -#~ msgid "Upgrading Ansible from version 2.9 and older to version 2.10 or later" -#~ msgstr "Ansible のバージョン 2.9 以前から 2.10 以降へのアップグレード" - -#~ msgid "Starting in version 2.10, Ansible is made of two packages. You need to first uninstall the old Ansible version (2.9 or earlier) before upgrading. If you do not uninstall the older version of Ansible, you will see the following message, and no change will be performed:" -#~ msgstr "バージョン 2.10 以降では、Ansible は 2 つのパッケージで構成されています。最初にアップグレードの前に、古い Ansible バージョン (2.9 以前) をアンインストールする必要があります。古いバージョンの Ansible をアンインストールしない場合は、以下のメッセージが表示され、変更が実行されません。" - -#~ msgid "As explained by the message, to upgrade you must first remove the version of Ansible installed and then install it to the latest version." -#~ msgstr "メッセージで説明されているように、アップグレードするには、最初にインストールした Ansible のバージョンを削除してから、最新バージョンにインストールする必要があります。" - -#~ msgid "Installing the development version of ``ansible-base``" -#~ msgstr "開発バージョンの ``ansible-base`` のインストール" - -#~ msgid "In Ansible 2.10 and later, The `ansible/ansible repository `_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``." -#~ msgstr "Ansible 2.10 以降では、`ansible/ansible リポジトリー `_ には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能や関数のコードが含まれています。このコードは ``ansible-base`` としても知られています。" - -#~ msgid "See :ref:`from_source` for instructions on how to run ``ansible-base`` directly from source, without the requirement of installation." -#~ msgstr "インストールの必要がなく、ソースから ``ansible-base`` を直接実行する方法については、「:ref:`from_source`」を参照してください。" - -#~ msgid "Ansible can also be installed inside a new or existing ``virtualenv``::" -#~ msgstr "Ansible は、新規または既存の ``virtualenv`` 内にもインストールできます::" - -#~ msgid "Running ``ansible-base`` from source (devel)" -#~ msgstr "ソース (devel) から ``ansible-base`` の実行" - -#~ msgid "If you want to use Ansible Tower as the control node, do not use a source installation of Ansible. Please use an OS package manager (like ``apt`` or ``yum``) or ``pip`` to install a stable version." -#~ msgstr "Ansible Tower をコントロールノードとして使用する場合は、Ansible のソースインストールは使用せず、OS パッケージマネージャー (``apt`` や ``yum`` など) を使用するか、``pip`` を使用して安定したバージョンをインストールしてください。" - -#~ msgid "Once ``git`` has cloned the ``ansible-base`` repository, setup the Ansible environment:" -#~ msgstr "``git`` が ``ansible-base`` リポジトリーのクローンを作成したら、Ansible 環境を設定します。" - -#~ msgid "If you don't have ``pip`` installed in your version of Python, install it::" -#~ msgstr "お使いのバージョンの Python に ``pip`` がインストールされていない場合は、インストールします::" - -#~ msgid "Ansible also uses the following Python modules that need to be installed [1]_:" -#~ msgstr "Ansible は、以下の Python モジュールも使用し、このモジュールもインストールする必要があります [1]_。" - -#~ msgid "Once running the env-setup script you'll be running from checkout and the default inventory file will be ``/etc/ansible/hosts``. You can optionally specify an inventory file (see :ref:`inventory`) other than ``/etc/ansible/hosts``:" -#~ msgstr "env-setup スクリプトを実行すると、チェックアウトから実行が行われ、デフォルトのインベントリーファイルが ``/etc/ansible/hosts`` になります。必要に応じて、``/etc/ansible/hosts`` 以外のインベントリーファイル (「:ref:`inventory`」を参照) を指定できます。" - -#~ msgid "You can read more about the inventory file at :ref:`inventory`." -#~ msgstr "インベントリーファイルの詳細は、:ref:`inventory`を参照してください。" - -#~ msgid "Now let's test things with a ping command:" -#~ msgstr "では、ping コマンドを使ってテストしていきましょう。" - -#~ msgid "You can also use \"sudo make install\"." -#~ msgstr "「sudo make install」も使用できます。" - -#~ msgid "Finding tarballs of tagged releases" -#~ msgstr "タグ付けされたリリースの tarball の場所" - -#~ msgid "Packaging Ansible or wanting to build a local package yourself, but don't want to do a git checkout? Tarballs of releases are available from ``pypi`` as https://pypi.python.org/packages/source/a/ansible/ansible-{{VERSION}}.tar.gz. You can make VERSION a variable in your package managing system that you update in one place whenever you package a new version. Alternately, you can download https://pypi.python.org/project/ansible to get the latest stable release." -#~ msgstr "git チェックアウトせずに、Ansible をパッケージ化したり、ローカルパッケージをご自身で構築する場合があります。リリースの tarball は、``pypi`` で https://pypi.python.org/packages/source/a/ansible/ansible-{{VERSION}}.tar.gz から入手できます。VERSION は、新しいバージョンをパッケージ化するたびに 1 カ所で更新するパッケージ管理システムの変数にすることができます。また、最新の安定版リリースを入手するには、https://pypi.python.org/project/ansible をダウンロードします。" - -#~ msgid "If you are creating your own Ansible package, you must also download or package ``ansible-base`` as part of your Ansible package. You can download it as https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{{VERSION}}.tar.gz." -#~ msgstr "独自の Ansible パッケージを作成する場合は、Ansible パッケージの一部として ``ansible-base`` をダウンロードまたはパッケージ化する必要があります。これは、https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{{VERSION}}.tar.gz としてダウンロードすることができます。" - -#~ msgid "These releases are also tagged in the `git repository `_ with the release version." -#~ msgstr "これらのリリースは、`git リポジトリー `_ でもリリースバージョンでタグ付けされます。" - -#~ msgid "As of Ansible 2.9, shell completion of the Ansible command line utilities is available and provided through an optional dependency called ``argcomplete``. ``argcomplete`` supports bash, and has limited support for zsh and tcsh." -#~ msgstr "Ansible 2.9 の時点では、Ansible コマンドラインユーティリティーのシェル補完を利用できます。これは、``argcomplete`` というオプションの依存関係を使用して提供されます。``argcomplete`` は bash をサポートし、また制限付きで zsh および tcsh もサポートします。" - -#~ msgid "You can install ``python-argcomplete`` from EPEL on Red Hat Enterprise based distributions, and or from the standard OS repositories for many other distributions." -#~ msgstr "``python-argcomplete`` は、Red Hat Enterprise ベースのディストリビューションでは EPEL からインストールでき、その他の多くのディストリビューションでは標準 OS リポジトリーで入手できます。" - -#~ msgid "Installing ``argcomplete`` on RHEL, CentOS, or Fedora" -#~ msgstr "RHEL、CentOS、または Fedora への ``argcomplete`` のインストール" - -#~ msgid "On RHEL and CentOS:" -#~ msgstr "RHEL および CentOS の場合:" - -#~ msgid "Installing ``argcomplete`` with ``apt``" -#~ msgstr "``apt`` を使用した ``argcomplete`` のインストール" - -#~ msgid "Globally" -#~ msgstr "グローバル" - -#~ msgid "Per command" -#~ msgstr "コマンド単位" - -#~ msgid "``ansible-base`` on GitHub" -#~ msgstr "GitHub の ``ansible-base``" - -#~ msgid "You may also wish to follow the `GitHub project `_ if you have a GitHub account. This is also where we keep the issue tracker for sharing bugs and feature ideas." -#~ msgstr "GitHub アカウントがある場合は、`GitHub project `_ をフォローすることが推奨されます。これは、バグや機能に関するアイディアを共有するための問題追跡システムを維持する場所でもあります。" - -#~ msgid "`irc.freenode.net `_" -#~ msgstr "`irc.freenode.net `_" - -#~ msgid "If you have issues with the \"pycrypto\" package install on macOS, then you may need to try ``CC=clang sudo -E pip install pycrypto``." -#~ msgstr "MacOS への「pycrypto」パッケージのインストールに問題がある場合は、``CC=clang sudo -E pip install pycrypto`` の試行が必要になる場合があります。" - -#~ msgid "``paramiko`` was included in Ansible's ``requirements.txt`` prior to 2.8." -#~ msgstr "``paramiko`` は、2.8 以前の Ansible の ``requirements.txt`` に同梱されています。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory.po deleted file mode 100644 index 460e557d48b..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory.po +++ /dev/null @@ -1,59 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-11-03 09:23+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/inventory/implicit_localhost.rst:6 -msgid "Implicit 'localhost'" -msgstr "暗黙的な「localhost」" - -#: ../../rst/inventory/implicit_localhost.rst:8 -msgid "When you try to reference a ``localhost`` and you don't have it defined in inventory, Ansible will create an implicit one for you.:" -msgstr "``localhost`` を参照しようとしたにもかかわらず、インベントリーにその localhost が定義されていない場合は、Ansible により暗黙的 localhost が作成されます。:" - -#: ../../rst/inventory/implicit_localhost.rst:18 -msgid "In a case like this (or ``local_action``) when Ansible needs to contact a 'localhost' but you did not supply one, we create one for you. This host is defined with specific connection variables equivalent to this in an inventory:" -msgstr "上記のような場合 (または ``local_action``) で、Ansible が「localhost」に問い合わせをする必要があるにもかかわらず、localhost を作成していない場合には、Ansible で localhost が作成されます。このホストは、インベントリーにあるものと同等の特定の接続変数で定義されます:" - -#: ../../rst/inventory/implicit_localhost.rst:30 -msgid "This ensures that the proper connection and Python are used to execute your tasks locally. You can override the built-in implicit version by creating a ``localhost`` host entry in your inventory. At that point, all implicit behaviors are ignored; the ``localhost`` in inventory is treated just like any other host. Group and host vars will apply, including connection vars, which includes the ``ansible_python_interpreter`` setting. This will also affect ``delegate_to: localhost`` and ``local_action``, the latter being an alias to the former." -msgstr "この設定により、適切な接続と Python がローカルでタスクを実行するのに使用されるようにます。インベントリーに ``localhost`` ホストエントリーを作成すると、組み込みの暗黙的ホストのバージョンを上書きできます。この時点で、暗黙的な動作はすべて無視され、インベントリー内の ``localhost`` は他のホストと同じように処理されます。グループおよびホストの変数 (接続変数を含む) が適用されます。これには、``ansible_python_interpreter`` 設定が含まれます。グループおよびホスト変数の設定は、``delegate_to: localhost`` および ``local_action`` にも適用され、``local_action`` は ``delegate_to: localhost`` のエイリアスとなります。" - -#: ../../rst/inventory/implicit_localhost.rst:35 -msgid "This host is not targetable via any group, however it will use vars from ``host_vars`` and from the 'all' group." -msgstr "このホストをターゲットにできるグループはありませんが、``host_vars`` と「all」グループの変数を使用します。" - -#: ../../rst/inventory/implicit_localhost.rst:36 -msgid "Implicit localhost does not appear in the ``hostvars`` magic variable unless demanded, such as by ``\"{{ hostvars['localhost'] }}\"``." -msgstr "``\"{{ hostvars['localhost'] }}\"`` などの要求がない限り、暗黙的な localhost は ``hostvars`` マジック変数には表示されません。" - -#: ../../rst/inventory/implicit_localhost.rst:37 -msgid "The ``inventory_file`` and ``inventory_dir`` magic variables are not available for the implicit localhost as they are dependent on **each inventory host**." -msgstr "マジック変数 ``inventory_file`` および ``inventory_dir`` は、**各インベントリーホスト** に依存しているため、暗黙的な localhost では利用できません。" - -#: ../../rst/inventory/implicit_localhost.rst:38 -msgid "This implicit host also gets triggered by using ``127.0.0.1`` or ``::1`` as they are the IPv4 and IPv6 representations of 'localhost'." -msgstr "この暗黙的ホストは、「localhost」の IPv4 および IPv6 の表現であるため、``127.0.0.1`` または ``::1`` を使用しても発生しません。" - -#: ../../rst/inventory/implicit_localhost.rst:39 -msgid "Even though there are many ways to create it, there will only ever be ONE implicit localhost, using the name first used to create it." -msgstr "それを作成する方法は多数ありますが、暗黙的な localhost は 1 つだけ存在することになります。最初に作成したときに使用した名前が使用されます。" - -#: ../../rst/inventory/implicit_localhost.rst:40 -msgid "Having ``connection: local`` does NOT trigger an implicit localhost, you are just changing the connection for the ``inventory_hostname``." -msgstr "``connection: local`` があっても暗黙的な localhost が作成されない場合は、``inventory_hostname`` の接続を変更します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory_guide.po deleted file mode 100644 index 6507816f84c..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/inventory_guide.po +++ /dev/null @@ -1,1424 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/inventory_guide/connection_details.rst:5 -msgid "Connection methods and details" -msgstr "接続方法および詳細" - -#: ../../rst/inventory_guide/connection_details.rst:7 -msgid "This section shows you how to expand and refine the connection methods Ansible uses for your inventory." -msgstr "このセクションでは、Ansible がインベントリーに使用する接続方法を拡張および改良する方法を示します。" - -#: ../../rst/inventory_guide/connection_details.rst:10 -msgid "ControlPersist and paramiko" -msgstr "ControlPersist および paramiko" - -#: ../../rst/inventory_guide/connection_details.rst:12 -msgid "By default, Ansible uses native OpenSSH, because it supports ControlPersist (a performance feature), Kerberos, and options in ``~/.ssh/config`` such as Jump Host setup. If your control machine uses an older version of OpenSSH that does not support ControlPersist, Ansible will fallback to a Python implementation of OpenSSH called 'paramiko'." -msgstr "デフォルトでは、Ansible はネイティブの OpenSSH を使用します。これは、ControlPersist (パフォーマンス機能)、Kerberos、および Jump Host 設定などの ``~/.ssh/config`` のオプションをサポートしているためです。コントロールマシンが ControlPersist をサポートしていない古いバージョンの OpenSSH を使用している場合、Ansible は「paramiko」と呼ばれる Python による OpenSSH の実装にフォールバックします。" - -#: ../../rst/inventory_guide/connection_details.rst:17 -msgid "Setting a remote user" -msgstr "リモートユーザーの設定" - -#: ../../rst/inventory_guide/connection_details.rst:19 -msgid "By default, Ansible connects to all remote devices with the user name you are using on the control node. If that user name does not exist on a remote device, you can set a different user name for the connection. If you just need to do some tasks as a different user, look at :ref:`become`. You can set the connection user in a playbook:" -msgstr "デフォルトでは、Ansible はすべてのリモートデバイスに、コントロールノードで使用しているユーザー名で接続します。リモートデバイスにそのユーザー名が存在しない場合は、接続に別のユーザー名を設定することができます。別のユーザーとしていくつかのタスクを実行するだけの場合は、「:ref:`become`」を参照してください。Playbookで接続ユーザーを設定することができます。" - -#: ../../rst/inventory_guide/connection_details.rst:32 -msgid "as a host variable in inventory:" -msgstr "インベントリーのホスト変数では、以下のようになります。" - -#: ../../rst/inventory_guide/connection_details.rst:39 -msgid "or as a group variable in inventory:" -msgstr "また、インベントリーのグローバル変数では、以下のようになります。" - -#: ../../rst/inventory_guide/connection_details.rst:52 -msgid ":ref:`ssh_connection`" -msgstr ":ref:`ssh_connection`" - -#: ../../rst/inventory_guide/connection_details.rst:53 -msgid "Details on the ``remote_user`` keyword and ``ansible_user`` variable." -msgstr "``remote_user`` キーワードおよび ``ansible_user`` 変数の詳細。" - -#: ../../rst/inventory_guide/connection_details.rst:54 -msgid ":ref:`general_precedence_rules`" -msgstr ":ref:`general_precedence_rules`" - -#: ../../rst/inventory_guide/connection_details.rst:55 -msgid "Details on Ansible precedence rules." -msgstr "Ansible の優先度ルールの詳細。" - -#: ../../rst/inventory_guide/connection_details.rst:58 -msgid "Setting up SSH keys" -msgstr "SSH キーの設定" - -#: ../../rst/inventory_guide/connection_details.rst:60 -msgid "By default, Ansible assumes you are using SSH keys to connect to remote machines. SSH keys are encouraged, but you can use password authentication if needed with the ``--ask-pass`` option. If you need to provide a password for :ref:`privilege escalation ` (sudo, pbrun, and so on), use ``--ask-become-pass``." -msgstr "デフォルトでは、Ansible は SSH 鍵を使用してリモートマシンに接続することを想定しています。SSH キーが推奨されますが、必要に応じて ``--ask-pass`` オプションを使用してパスワード認証を使用できます。:ref:`privilege escalation ` (sudo、pbrun など) のパスワードを提供する必要がある場合は、``--ask-become-pass`` を使用します。" - -#: ../../rst/inventory_guide/shared_snippets/SSH_password_prompt.txt:2 -msgid "Ansible does not expose a channel to allow communication between the user and the ssh process to accept a password manually to decrypt an ssh key when using the ssh connection plugin (which is the default). The use of ``ssh-agent`` is highly recommended." -msgstr "Ansible は、ssh connection プラグインを使用している場合 (これがデフォルトです)は、ユーザーと ssh プロセスの間の通信を可能にするチャンネルを公開しておらず、ssh 鍵を復号するためのパスワードを手動で受け入れることができません。``ssh-agent`` を使用することが強く推奨されます。" - -#: ../../rst/inventory_guide/connection_details.rst:64 -msgid "To set up SSH agent to avoid retyping passwords, you can do:" -msgstr "パスワードを再入力しないように SSH エージェントをセットアップするには、次のようにします。" - -#: ../../rst/inventory_guide/connection_details.rst:71 -msgid "Depending on your setup, you may wish to use Ansible's ``--private-key`` command line option to specify a pem file instead. You can also add the private key file:" -msgstr "セットアップによっては、代わりに Ansible の ``--private-key`` コマンドラインオプションを使用して pem ファイルを指定することもできます。秘密鍵ファイルを追加することもできます。" - -#: ../../rst/inventory_guide/connection_details.rst:78 -msgid "Another way to add private key files without using ssh-agent is using ``ansible_ssh_private_key_file`` in an inventory file as explained here: :ref:`intro_inventory`." -msgstr "ssh-agent を使用せずに秘密鍵ファイルを追加する別の方法は、「:ref:`intro_inventory`」で説明するように、インベントリーファイルで ``ansible_ssh_private_key_file`` を使用することです。" - -#: ../../rst/inventory_guide/connection_details.rst:81 -msgid "Running against localhost" -msgstr "ローカルホストに対して実行" - -#: ../../rst/inventory_guide/connection_details.rst:83 -msgid "You can run commands against the control node by using \"localhost\" or \"127.0.0.1\" for the server name:" -msgstr "サーバー名に「localhost」または「127.0.0.1」を使用して、コントロールノードにコマンドを実行できます。" - -#: ../../rst/inventory_guide/connection_details.rst:89 -msgid "You can specify localhost explicitly by adding this to your inventory file:" -msgstr "これをインベントリーファイルに追加して、localhost を明示的に指定できます。" - -#: ../../rst/inventory_guide/connection_details.rst:98 -msgid "Managing host key checking" -msgstr "ホスト鍵の確認の管理" - -#: ../../rst/inventory_guide/connection_details.rst:100 -msgid "Ansible enables host key checking by default. Checking host keys guards against server spoofing and man-in-the-middle attacks, but it does require some maintenance." -msgstr "Ansible は、デフォルトでホスト鍵の確認を有効にします。ホスト鍵を確認すると、サーバーのなりすましや中間者攻撃から保護されますが、メンテナンスが必要です。" - -#: ../../rst/inventory_guide/connection_details.rst:102 -msgid "If a host is reinstalled and has a different key in 'known_hosts', this will result in an error message until corrected. If a new host is not in 'known_hosts' your control node may prompt for confirmation of the key, which results in an interactive experience if using Ansible, from say, cron. You might not want this." -msgstr "ホストが再インストールされ、「known_hosts」に異なるキーがある場合は、修正されるまでエラーメッセージが表示されます。新しいホストが「known_hosts」にない場合、コントロールノードはキーの確認を求めるかもしれませんが、これは Ansible を cron などから使用している場合は、インタラクティブな操作になります。このように動作しないようにしたい場合があります。" - -#: ../../rst/inventory_guide/connection_details.rst:104 -msgid "If you understand the implications and wish to disable this behavior, you can do so by editing ``/etc/ansible/ansible.cfg`` or ``~/.ansible.cfg``:" -msgstr "この動作を無効にした場合の影響を理解し、無効にする場合は、``/etc/ansible/ansible.cfg`` または ``~/.ansible.cfg`` 編集します。" - -#: ../../rst/inventory_guide/connection_details.rst:111 -msgid "Alternatively this can be set by the :envvar:`ANSIBLE_HOST_KEY_CHECKING` environment variable:" -msgstr "また、これは、:envvar:`ANSIBLE_HOST_KEY_CHECKING` 環境変数により設定できます。" - -#: ../../rst/inventory_guide/connection_details.rst:117 -msgid "Also note that host key checking in paramiko mode is reasonably slow, therefore switching to 'ssh' is also recommended when using this feature." -msgstr "また、paramiko モードでのホストキーチェックはかなり遅いため、この機能を使用する場合は「ssh」に切り替えることも推奨されます。" - -#: ../../rst/inventory_guide/connection_details.rst:120 -msgid "Other connection methods" -msgstr "その他の接続方法" - -#: ../../rst/inventory_guide/connection_details.rst:122 -msgid "Ansible can use a variety of connection methods beyond SSH. You can select any connection plugin, including managing things locally and managing chroot, lxc, and jail containers. A mode called 'ansible-pull' can also invert the system and have systems 'phone home' via scheduled git checkouts to pull configuration directives from a central repository." -msgstr "Ansible では、SSH 以外にもさまざまな接続方法を利用することができます。ローカルでの管理、chroot コンテナー、lxc コンテナー、および jail コンテナーの管理など、任意の connection プラグインを選択できます。「ansible-pull」と呼ばれるモードでは、システムを反転させて、スケジュールされた git チェックアウトを介してシステムを「phone home」させ、中央のリポジトリーから設定ディレクティブを引き出すこともできます。" - -#: ../../rst/inventory_guide/index.rst:5 -msgid "Building Ansible inventories" -msgstr "Ansible インベントリーの構築" - -#: ../../rst/inventory_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/inventory_guide/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/inventory_guide/index.rst:13 -msgid "Welcome to the guide to building Ansible inventories. An inventory is a list of managed nodes, or hosts, that Ansible deploys and configures. This guide introduces you to inventories and covers the following topics:" -msgstr "Ansible インベントリーの構築ガイドへようこそ。インベントリーは、Ansible がデプロイおよび設定する管理対象ノードまたはホストのリストです。このガイドでは、インベントリーだけでなく、次のトピックについても説明します。" - -#: ../../rst/inventory_guide/index.rst:17 -msgid "Creating inventories to track list of servers and devices that you want to automate." -msgstr "インベントリーを作成して、自動化するサーバーおよびデバイスの一覧を追跡する。" - -#: ../../rst/inventory_guide/index.rst:18 -msgid "Using dynamic inventories to track cloud services with servers and devices that are constantly starting and stopping." -msgstr "動的インベントリーを使用して、常に起動と停止を行うサーバーおよびデバイスが含まれるクラウドサービスを追跡する。" - -#: ../../rst/inventory_guide/index.rst:19 -msgid "Using patterns to automate specific sub-sets of an inventory." -msgstr "パターンを使用して、インベントリーの特定のサブセットを自動化する。" - -#: ../../rst/inventory_guide/index.rst:20 -msgid "Expanding and refining the connection methods Ansible uses for your inventory." -msgstr "Ansible がインベントリーに使用する接続方法を拡張して調整する。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:6 -msgid "Working with dynamic inventory" -msgstr "動的インベントリーの使用" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:11 -msgid "If your Ansible inventory fluctuates over time, with hosts spinning up and shutting down in response to business demands, the static inventory solutions described in :ref:`inventory` will not serve your needs. You may need to track hosts from multiple sources: cloud providers, LDAP, `Cobbler `_, and/or enterprise CMDB systems." -msgstr "Ansible のインベントリーが、ビジネス上の要求に応じてホストの回転や停止など、時間とともに変動する場合は、「:ref:`inventory`」で説明している静的なインベントリーソリューションではニーズに応えられません。クラウドプロバイダー、LDAP、`Cobbler `_、エンタープライズ CMDB システムなど、複数のソースからのホストの追跡が必要になる場合があります。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:14 -msgid "Ansible integrates all of these options through a dynamic external inventory system. Ansible supports two ways to connect with external inventory: :ref:`inventory_plugins` and `inventory scripts`." -msgstr "Ansible は、動的な外部インベントリーシステムを通じて、これらのオプションをすべて統合します。Ansible は、外部インベントリーに接続する 2 つの方法 (:ref:`inventory_plugins` および `inventory scripts`) をサポートしています。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:17 -msgid "Inventory plugins take advantage of the most recent updates to the Ansible core code. We recommend plugins over scripts for dynamic inventory. You can :ref:`write your own plugin ` to connect to additional dynamic inventory sources." -msgstr "インベントリープラグインは、Ansible コアコードの最新の更新を利用しています。動的インベントリーには、スクリプトよりもプラグインが推奨されます。:ref:`独自のプラグインを記述 ` して、追加の動的インベントリーソースに接続することができます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:21 -msgid "You can still use inventory scripts if you choose. When we implemented inventory plugins, we ensured backwards compatibility through the script inventory plugin. The examples below illustrate how to use inventory scripts." -msgstr "また、インベントリースクリプトを使用することもできます。インベントリープラグインを実装する際に、スクリプトインベントリープラグインによる後方互換性を確保しました。以下の例では、インベントリースクリプトの使用方法を説明しています。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:25 -msgid "If you prefer a GUI for handling dynamic inventory, the inventory database on AWX or :ref:`ansible_platform` syncs with all your dynamic inventory sources, provides web and REST access to the results, and offers a graphical inventory editor. With a database record of all of your hosts, you can correlate past event history and see which hosts have had failures on their last playbook runs." -msgstr "動的インベントリーを GUI で操作したい場合は、AWX または :ref:`ansible_platform` のインベントリーデータベースがすべての動的インベントリーソースと同期し、その結果に Web および REST アクセスを提供し、グラフィカルインベントリーエディターを提供します。すべてのホストのデータベースレコードを使用して、過去のイベント履歴を関連付け、最後の Playbook の実行でどのホストに障害が発生したかを確認できます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:31 -msgid "Inventory script example: Cobbler" -msgstr "インベントリースクリプトの例: Cobbler" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:33 -msgid "Ansible integrates seamlessly with `Cobbler `_, a Linux installation server originally written by Michael DeHaan and now led by James Cammarata, who works for Ansible." -msgstr "Ansible は、Linux インストールサーバー `Cobbler `_ (最初に Michael DeHaan 氏が作成し、現在は Ansible に所属する James Cammarata が率いています) とシームレスに統合されます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:35 -msgid "While primarily used to kickoff OS installations and manage DHCP and DNS, Cobbler has a generic layer that can represent data for multiple configuration management systems (even at the same time) and serve as a 'lightweight CMDB'." -msgstr "Cobbler は主に OS のインストールを開始し、DHCP と DNS を管理するために使用されますが、複数の構成管理システムのデータを (同時にでも) 表現し、「軽量CMDB」として機能する汎用レイヤーがあります。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:38 -msgid "To tie your Ansible inventory to Cobbler, copy `this script `_ to ``/etc/ansible`` and ``chmod +x`` the file. Run ``cobblerd`` any time you use Ansible and use the ``-i`` command line option (for example, ``-i /etc/ansible/cobbler.py``) to communicate with Cobbler using Cobbler's XMLRPC API." -msgstr "Ansible インベントリーを Cobbler に関連付けるには、`このスクリプト `_ を ``/etc/ansible`` にコピーして、コピーしたファイルに ``chmod +x`` を付与します。Ansible を使用して ``cobblerd`` を実行し、``-i`` コマンドラインオプション (例: ``-i /etc/ansible/cobbler.py``) を付けて、Cobbler の XMLRPC API 使用して Cobbler と通信します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:40 -msgid "Add a ``cobbler.ini`` file in ``/etc/ansible`` so Ansible knows where the Cobbler server is and some cache improvements can be used. For example:" -msgstr "Ansible が Cobbler サーバーの場所とキャッシュの改良に使用できるものを認識できるように、``/etc/ansible`` に ``cobbler.ini`` ファイルを追加します。以下に例を示します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:63 -msgid "First test the script by running ``/etc/ansible/cobbler.py`` directly. You should see some JSON data output, but it may not have anything in it just yet." -msgstr "まず ``/etc/ansible/cobbler.py`` を直接実行してスクリプトをテストします。JSON データ出力が表示されますが、まだ何も含まれていない場合もあります。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:65 -msgid "Let's explore what this does. In Cobbler, assume a scenario somewhat like the following:" -msgstr "これで何ができるのか見てみましょう。Cobbler で、次のようなシナリオを想定します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:74 -msgid "In the example above, the system 'foo.example.com' is addressable by ansible directly, but is also addressable when using the group names 'webserver' or 'atlanta'. Since Ansible uses SSH, it contacts system foo over 'foo.example.com', only, never just 'foo'. Similarly, if you tried \"ansible foo\", it would not find the system... but \"ansible 'foo*'\" would do, because the system DNS name starts with 'foo'." -msgstr "上の例では、システム「foo.example.com」は、ansible が直接アドレスを指定できるだけでなく、グループ名「webserver」や「atlanta」を使用してもアドレスを指定できます。Ansible は SSH を使用しているため、「foo.example.com」を経由してシステム foo に接続しますが、決して「foo」だけではありません。同様に、「ansible foo」と入力しても、システムを見つけることはできませんが、「ansible 'foo'*」と入力すると、システムの DNS 名が 'foo' で始まるため、システムを見つけることができます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:76 -msgid "The script provides more than host and group info. In addition, as a bonus, when the 'setup' module is run (which happens automatically when using playbooks), the variables 'a', 'b', and 'c' will all be auto-populated in the templates:" -msgstr "このスクリプトは、ホストとグループの情報以外にもさまざまな情報を提供します。さらに、(Playbook を使用する際に自動的に実行される)「setup」モジュールを実行すると、変数「a」、「b」、および「c」はすべてテンプレートに自動入力されるようになります。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:83 -msgid "Which could be executed just like this:" -msgstr "これは以下のように実行できます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:91 -msgid "The name 'webserver' came from Cobbler, as did the variables for the config file. You can still pass in your own variables like normal in Ansible, but variables from the external inventory script will override any that have the same name." -msgstr "「webserver」という名前は、設定ファイルの変数と同様に、Cobbler から来ています。Ansible では通常のように独自の変数を渡すことができますが、外部のインベントリースクリプトからの変数は、同じ名前のものを上書きします。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:96 -msgid "So, with the template above (``motd.j2``), this results in the following data being written to ``/etc/motd`` for system 'foo':" -msgstr "そのため、上記のテンプレート (``motd.j2``) を使用すると、以下のデータがシステム「foo」用に ``/etc/motd`` に書き込まれます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:102 -msgid "And on system 'bar' (bar.example.com):" -msgstr "システム「bar」(bar.example.com) は、以下のようになります。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:108 -msgid "And technically, though there is no major good reason to do it, this also works:" -msgstr "技術的には、これを行う大きな正当な理由はありませんが、これも機能します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:114 -msgid "So, in other words, you can use those variables in arguments/actions as well." -msgstr "つまり、引数やアクションでこの変数を使用することもできます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:119 -msgid "Inventory script example: OpenStack" -msgstr "インベントリースクリプトの例: OpenStack" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:121 -msgid "If you use an OpenStack-based cloud, instead of manually maintaining your own inventory file, you can use the ``openstack_inventory.py`` dynamic inventory to pull information about your compute instances directly from OpenStack." -msgstr "独自のインベントリーファイルを手動で管理する代わりに、OpenStack ベースのクラウドを使用する場合は、動的インベントリー ``openstack_inventory.py`` を使用して、OpenStack から直接 Compute インスタンスに関する情報を取得できます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:123 -msgid "You can download the latest version of the OpenStack inventory script `here `_." -msgstr "最新バージョンの OpenStack インベントリースクリプトは、`こちら `_ からダウンロードできます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:125 -msgid "You can use the inventory script explicitly (by passing the `-i openstack_inventory.py` argument to Ansible) or implicitly (by placing the script at `/etc/ansible/hosts`)." -msgstr "(`-i openstack_inventory.py` 引数を Ansible に渡すことで) インベントリースクリプトを明示的に使用するか、(スクリプトを `/etc/ansible/hosts` において) 暗黙的に使用できます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:128 -msgid "Explicit use of OpenStack inventory script" -msgstr "OpenStack インベントリースクリプトの明示的な使用" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:130 -msgid "Download the latest version of the OpenStack dynamic inventory script and make it executable." -msgstr "最新バージョンの OpenStack の動的インベントリースクリプトをダウンロードし、実行可能にします。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:138 -msgid "Do not name it `openstack.py`. This name will conflict with imports from openstacksdk." -msgstr "`openstack.py` という名前はつけないでください。この名前は、openstacksdk からのインポートと競合します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:140 -msgid "Source an OpenStack RC file:" -msgstr "OpenStack RC ファイルを読み込みます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:148 -msgid "An OpenStack RC file contains the environment variables required by the client tools to establish a connection with the cloud provider, such as the authentication URL, user name, password and region name. For more information on how to download, create or source an OpenStack RC file, please refer to `Set environment variables using the OpenStack RC file `_." -msgstr "OpenStack RC ファイルには、認証 URL、ユーザー名、パスワード、リージョン名など、クラウドプロバイダーとの接続を確立するためにクライアントツールで必要な環境変数が含まれています。OpenStack RC ファイルのダウンロード、作成、またはソースに関する詳細は、「`Set environment variables using the OpenStack RC file `_」を参照してください。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:150 -msgid "You can confirm the file has been successfully sourced by running a simple command, such as `nova list` and ensuring it returns no errors." -msgstr "`nova list` などの単純なコマンドを実行してエラーを返さないようにすることで、ファイルが正常に読み込まれたことを確認できます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:154 -msgid "The OpenStack command line clients are required to run the `nova list` command. For more information on how to install them, please refer to `Install the OpenStack command-line clients `_." -msgstr "`nova list` コマンドを実行するには、OpenStack コマンドラインクライアントが必要です。インストール方法の詳細は、「`Install the OpenStack command-line clients `_」を参照してください。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:156 -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:189 -msgid "You can test the OpenStack dynamic inventory script manually to confirm it is working as expected:" -msgstr "OpenStack 動的インベントリースクリプトを手動でテストして、想定どおりに機能していることを確認します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:162 -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:195 -msgid "After a few moments you should see some JSON output with information about your compute instances." -msgstr "しばらくすると、Compute インスタンスに関する情報が含まれる JSON 出力が表示されます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:164 -msgid "Once you confirm the dynamic inventory script is working as expected, you can tell Ansible to use the `openstack_inventory.py` script as an inventory file, as illustrated below:" -msgstr "動的インベントリースクリプトが想定どおりに機能していることを確認したら、以下のように Ansible が `openstack_inventory.py` スクリプトをインベントリーファイルとして使用するように指定します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:171 -msgid "Implicit use of OpenStack inventory script" -msgstr "OpenStack インベントリースクリプトの暗黙的な使用" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:173 -msgid "Download the latest version of the OpenStack dynamic inventory script, make it executable and copy it to `/etc/ansible/hosts`:" -msgstr "最新バージョンの OpenStack 動的インベントリースクリプトをダウンロードし、実行可能にし、これを `/etc/ansible/hosts` にコピーします。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:181 -msgid "Download the sample configuration file, modify it to suit your needs and copy it to `/etc/ansible/openstack.yml`:" -msgstr "サンプル設定ファイルをダウンロードし、必要に応じて変更し、これを `/etc/ansible/openstack.yml` にコピーします。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:198 -msgid "Refreshing the cache" -msgstr "キャッシュの更新" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:200 -msgid "Note that the OpenStack dynamic inventory script will cache results to avoid repeated API calls. To explicitly clear the cache, you can run the openstack_inventory.py (or hosts) script with the ``--refresh`` parameter:" -msgstr "OpenStack 動的インベントリースクリプトは、API 呼び出しが繰り返し行われるのを防ぐために、結果をキャッシュすることに注意してください。キャッシュを明示的に消去するには、``--refresh`` パラメーターを使用して openstack_inventory.py (または hosts) スクリプトを実行します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:209 -msgid "Other inventory scripts" -msgstr "その他のインベントリースクリプト" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:211 -msgid "In Ansible 2.10 and later, inventory scripts moved to their associated collections. Many are now in the `ansible-community/contrib-scripts repository `_. We recommend you use :ref:`inventory_plugins` instead." -msgstr "Ansible 2.10 以降では、インベントリースクリプトは関連するコレクションに移動しました。現在、多くのスクリプトは `ansible-community/contrib-scripts repository `_ にあります。代わりに :ref:`inventory_plugins` を使用することが推奨されます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:216 -msgid "Using inventory directories and multiple inventory sources" -msgstr "インベントリーディレクトリーおよび複数のインベントリーソースの使用" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:218 -msgid "If the location given to ``-i`` in Ansible is a directory (or as so configured in ``ansible.cfg``), Ansible can use multiple inventory sources at the same time. When doing so, it is possible to mix both dynamic and statically managed inventory sources in the same ansible run. Instant hybrid cloud!" -msgstr "Ansible で ``-i`` に指定される場所がディレクトリーの場合 (または ``ansible.cfg`` でそのように設定されている場合)、Ansible は複数のインベントリーソースを同時に使用できます。これを実行する場合は、同じ Ansible 実行で動的および静的に管理されているインベントリーソースを混在させることができます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:222 -msgid "In an inventory directory, executable files are treated as dynamic inventory sources and most other files as static sources. Files which end with any of the following are ignored:" -msgstr "インベントリーディレクトリでは、実行ファイルは動的インベントリーソースとして、その他のほとんどのファイルは静的ソースとして扱われます。以下のいずれかで終わるファイルは無視されます。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:228 -msgid "You can replace this list with your own selection by configuring an ``inventory_ignore_extensions`` list in ``ansible.cfg``, or setting the :envvar:`ANSIBLE_INVENTORY_IGNORE` environment variable. The value in either case must be a comma-separated list of patterns, as shown above." -msgstr "この一覧は、``ansible.cfg`` で ``inventory_ignore_extensions`` 一覧を設定するか、:envvar:`ANSIBLE_INVENTORY_IGNORE` 環境変数を設定して独自の選択に置き換えることができます。いずれの値も、上記のようにパターンのコンマ区切りの一覧である必要があります。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:230 -msgid "Any ``group_vars`` and ``host_vars`` subdirectories in an inventory directory are interpreted as expected, making inventory directories a powerful way to organize different sets of configurations. See :ref:`using_multiple_inventory_sources` for more information." -msgstr "インベントリーディレクトリーの ``group_vars`` サブディレクトリーおよび ``host_vars`` サブディレクトリーは想定どおりに解釈されるため、インベントリーディレクトリーはさまざまな構成セットを整理するための強力な方法になります。詳細は、「:ref:`using_multiple_inventory_sources`」を参照してください。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:235 -msgid "Static groups of dynamic groups" -msgstr "動的グループの静的グループ" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:237 -msgid "When defining groups of groups in the static inventory file, the child groups must also be defined in the static inventory file, otherwise ansible returns an error. If you want to define a static group of dynamic child groups, define the dynamic groups as empty in the static inventory file. For example:" -msgstr "静的インベントリーファイルでグループのグループを定義する場合は、子グループも静的インベントリーファイルで定義されていなければ、Ansible はエラーを返します。動的な子グループの静的グループを定義する場合は、静的インベントリーファイルで動的グループを空に定義してください。以下に例を示します。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:255 -msgid ":ref:`intro_inventory`" -msgstr ":ref:`intro_inventory`" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:256 -msgid "All about static inventory files" -msgstr "静的インベントリーファイルの詳細" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:257 -#: ../../rst/inventory_guide/intro_inventory.rst:838 -#: ../../rst/inventory_guide/intro_patterns.rst:250 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:258 -#: ../../rst/inventory_guide/intro_inventory.rst:839 -#: ../../rst/inventory_guide/intro_patterns.rst:251 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:259 -#: ../../rst/inventory_guide/intro_inventory.rst:840 -#: ../../rst/inventory_guide/intro_patterns.rst:252 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/inventory_guide/intro_dynamic_inventory.rst:260 -#: ../../rst/inventory_guide/intro_inventory.rst:841 -#: ../../rst/inventory_guide/intro_patterns.rst:253 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/inventory_guide/intro_inventory.rst:6 -msgid "How to build your inventory" -msgstr "インベントリーの構築方法" - -#: ../../rst/inventory_guide/intro_inventory.rst:8 -msgid "Ansible automates tasks on managed nodes or \"hosts\" in your infrastructure, using a list or group of lists known as inventory. You can pass host names at the command line, but most Ansible users create inventory files. Your inventory defines the managed nodes you automate, with groups so you can run automation tasks on multiple hosts at the same time. Once your inventory is defined, you use :ref:`patterns ` to select the hosts or groups you want Ansible to run against." -msgstr "Ansible は、インベントリーと呼ばれるリストまたはリストのグループを使用して、インフラストラクチャー内の管理対象ノードまたはホストでのタスクを自動化します。コマンドラインでホスト名を渡すことができますが、ほとんどの Ansible ユーザーはインベントリーファイルを作成します。インベントリーは、自動化する管理対象ノードをグループで定義するため、複数のホストで同時に自動化タスクを実行できます。インベントリーが定義されたら、:ref:`patterns ` を使用して、Ansible を実行するホストまたはグループを選択します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:11 -msgid "The simplest inventory is a single file with a list of hosts and groups. The default location for this file is ``/etc/ansible/hosts``. You can specify a different inventory file at the command line using the ``-i `` option or in configuration using ``inventory``." -msgstr "最も単純なインベントリーは、ホストとグループの一覧が含まれる単一ファイルです。このファイルのデフォルトの場所は ``/etc/ansible/hosts`` です。``-i `` オプションを使用するか、``inventory`` を使用して設定で別のインベントリーファイルを指定できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:14 -msgid "Ansible :ref:`inventory_plugins` support a range of formats and sources to make your inventory flexible and customizable. As your inventory expands, you may need more than a single file to organize your hosts and groups. Here are three options beyond the ``/etc/ansible/hosts`` file: - You can create a directory with multiple inventory files. See :ref:`inventory_directory`. These can use different formats (YAML, ini, and so on). - You can pull inventory dynamically. For example, you can use a dynamic inventory plugin to list resources in one or more cloud providers. See :ref:`intro_dynamic_inventory`. - You can use multiple sources for inventory, including both dynamic inventory and static files. See :ref:`using_multiple_inventory_sources`." -msgstr "Ansible :ref:`inventory_plugins` は、インベントリーを柔軟かつカスタマイズ可能なものにするためのさまざまな形式およびソースをサポートします。インベントリーが拡張されたら、ホストとグループを整理するために、1 つ以上のファイルが必要になる場合があります。 ``/etc/ansible/hosts`` ファイル以外に 3 つのオプションがあります。- 複数のインベントリーファイルを含むディレクトリーを作成できます。:ref:`inventory_directory` を参照してください。これらは別の形式 (YAML、ini など) を使用できます。インベントリーは動的にプルできます。たとえば、動的インベントリープラグインを使用して、1 つ以上のクラウドプロバイダーのリソースを一覧表示できます。:ref:`intro_dynamic_inventory` を参照してください。 - 動的インベントリーと静的ファイルの両方を含む、インベントリーの複数ソースを使用できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:25 -msgid "Inventory basics: formats, hosts, and groups" -msgstr "インベントリーの基本: 形式、ホスト、およびグループ" - -#: ../../rst/inventory_guide/intro_inventory.rst:27 -msgid "You can create your inventory file in one of many formats, depending on the inventory plugins you have. The most common formats are INI and YAML. A basic INI ``/etc/ansible/hosts`` might look like this:" -msgstr "インベントリーファイルは、所有するインベントリープラグインに応じて、多数ある形式の中から 1 つ選択して作成できます。最も一般的な形式は INI および YAML です。基本的な INI ``/etc/ansible/hosts`` は以下のようになります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:43 -msgid "The headings in brackets are group names, which are used in classifying hosts and deciding what hosts you are controlling at what times and for what purpose. Group names should follow the same guidelines as :ref:`valid_variable_names`." -msgstr "括弧内の見出しはグループ名で、ホストを分類し、どの時点で、どのような目的で、どのホストを制御するかを決定するのに使用されます。グループ名は、:ref:`valid_variable_names` と同じガイドラインに従ってください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:47 -msgid "Here's that same basic inventory file in YAML format:" -msgstr "以下は、同じ基本的なインベントリーファイルの YAML 形式です。" - -#: ../../rst/inventory_guide/intro_inventory.rst:68 -msgid "Default groups" -msgstr "デフォルトのグループ" - -#: ../../rst/inventory_guide/intro_inventory.rst:70 -msgid "Even if you do not define any groups in your inventory file, Ansible creates two default groups: ``all`` and ``ungrouped``. The ``all`` group contains every host. The ``ungrouped`` group contains all hosts that don't have another group aside from ``all``. Every host will always belong to at least 2 groups (``all`` and ``ungrouped`` or ``all`` and some other group). For example, in the basic inventory above, the host ``mail.example.com`` belongs to the ``all`` group and the ``ungrouped`` group; the host ``two.example.com`` belongs to the ``all`` group and the ``dbservers`` group. Though ``all`` and ``ungrouped`` are always present, they can be implicit and not appear in group listings like ``group_names``." -msgstr "インベントリーファイルでグループを何も指定しない場合でも、Ansible は ``all`` と ``ungrouped`` のデフォルトのグループを作成します。``all`` グループには全ホストが含まれます。``ungrouped`` グループには、``all`` 以外の別のグループを持たないホストすべてが含まれます。全ホストは常に最低でも 2 つのグループ (``all`` および ``ungrouped`` または ``all`` と他のグループ) に所属します。たとえば、上記の基本的なインベントリーでは、``mail.example.com`` ホストは ``all`` グループと ``ungrouped`` グループに所属し、``two.example.com`` ホストは ``all`` グループと ``dbservers`` グループに所属します。``all`` と ``ungrouped`` は常に存在しますが、暗黙的な場合もあり、``group_names`` などのグループリストに表示されない場合があります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:77 -msgid "Hosts in multiple groups" -msgstr "複数グループ内のホスト" - -#: ../../rst/inventory_guide/intro_inventory.rst:79 -msgid "You can (and probably will) put each host in more than one group. For example a production webserver in a datacenter in Atlanta might be included in groups called ``[prod]`` and ``[atlanta]`` and ``[webservers]``. You can create groups that track:" -msgstr "各ホストを複数のグループに配置できます。たとえば、Atlanta のデータセンターの実稼働 Web サーバーは、``[prod]``、``[atlanta]`` および ``[webservers]`` と呼ばれるグループに追加できます。以下を追跡するグループを作成できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:81 -msgid "What - An application, stack or microservice (for example, database servers, web servers, and so on)." -msgstr "なにを - アプリケーション、スタック、またはマイクロサービス (たとえば、データベースサーバー、Web サーバーなど)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:82 -msgid "Where - A datacenter or region, to talk to local DNS, storage, and so on (for example, east, west)." -msgstr "どこで - データセンターまたはリージョンで、ローカルの DNS やストレージなどと通信します (例: east、west)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:83 -msgid "When - The development stage, to avoid testing on production resources (for example, prod, test)." -msgstr "いつ - 開発段階で、実稼働リソースでのテストを回避するため (例: prod、test)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:85 -msgid "Extending the previous YAML inventory to include what, when, and where would look like this:" -msgstr "以前の YAML インベントリーを拡張して、上述の「いつ、どこで、なにを」が含まれるようにします。" - -#: ../../rst/inventory_guide/intro_inventory.rst:121 -msgid "You can see that ``one.example.com`` exists in the ``dbservers``, ``east``, and ``prod`` groups." -msgstr "``one.example.com`` が ``dbservers``、``east``、および ``prod`` グループに存在することを確認できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:126 -msgid "Grouping groups: parent/child group relationships" -msgstr "グループの分類: 親子グループの関係" - -#: ../../rst/inventory_guide/intro_inventory.rst:128 -msgid "You can create parent/child relationships among groups. Parent groups are also known as nested groups or groups of groups. For example, if all your production hosts are already in groups such as ``atlanta_prod`` and ``denver_prod``, you can create a ``production`` group that includes those smaller groups. This approach reduces maintenance because you can add or remove hosts from the parent group by editing the child groups." -msgstr "グループ間で親/子関係を作成できます。親グループは、ネストされたグループまたはグループのグループとも呼ばれます。たとえば、すべての実稼働ホストが ``atlanta_prod`` や ``denver_prod`` などのグループにすでにある場合は、これらの小規模なグループを含む ``production`` グループを作成できます。この方法では、子グループを編集して親グループからホストを追加または削除できるため、メンテナンスが軽減されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:130 -msgid "To create parent/child relationships for groups:" -msgstr "グループの親子関係を作成するには以下を実行します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:132 -msgid "in INI format, use the ``:children`` suffix" -msgstr "INI 形式の場合は、``:children`` 接尾辞を使用します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:133 -msgid "in YAML format, use the ``children:`` entry" -msgstr "YAML 形式の場合は、``children:``エントリーを使用します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:135 -msgid "Here is the same inventory as shown above, simplified with parent groups for the ``prod`` and ``test`` groups. The two inventory files give you the same results:" -msgstr "``prod`` および ``test`` グループの親グループを使用して簡素化された上記と同じインベントリーを示します。2 つのインベントリーファイルでは、同じ結果が得られます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:168 -msgid "Child groups have a couple of properties to note:" -msgstr "子グループには、注意すべき以下のプロパティーがあります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:170 -msgid "Any host that is member of a child group is automatically a member of the parent group." -msgstr "子グループのメンバーであるホストは、自動的に親グループのメンバーになります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:171 -msgid "Groups can have multiple parents and children, but not circular relationships." -msgstr "グループに複数の親と子を追加することはできますが、循環関係は設定できません。" - -#: ../../rst/inventory_guide/intro_inventory.rst:172 -msgid "Hosts can also be in multiple groups, but there will only be **one** instance of a host at runtime. Ansible merges the data from the multiple groups." -msgstr "ホストは複数のグループに属することもできますが、ホストのインスタンスは **1 つ** だけであり、Ansible は複数のグループからのデータをマージします。" - -#: ../../rst/inventory_guide/intro_inventory.rst:175 -msgid "Adding ranges of hosts" -msgstr "ホスト範囲の追加" - -#: ../../rst/inventory_guide/intro_inventory.rst:177 -msgid "If you have a lot of hosts with a similar pattern, you can add them as a range rather than listing each hostname separately:" -msgstr "同様のパターンを持つホストが多数ある場合は、各ホスト名を個別に表示するのではなく、ホストを範囲として追加できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:179 -#: ../../rst/inventory_guide/intro_inventory.rst:197 -#: ../../rst/inventory_guide/intro_inventory.rst:298 -#: ../../rst/inventory_guide/intro_inventory.rst:344 -#: ../../rst/inventory_guide/intro_inventory.rst:384 -#: ../../rst/inventory_guide/intro_inventory.rst:417 -msgid "In INI:" -msgstr "INI の場合は、以下のようになります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:186 -#: ../../rst/inventory_guide/intro_inventory.rst:204 -#: ../../rst/inventory_guide/intro_inventory.rst:306 -#: ../../rst/inventory_guide/intro_inventory.rst:350 -#: ../../rst/inventory_guide/intro_inventory.rst:396 -#: ../../rst/inventory_guide/intro_inventory.rst:445 -msgid "In YAML:" -msgstr "YAML の場合は、以下のようになります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:195 -msgid "You can specify a stride (increments between sequence numbers) when defining a numeric range of hosts:" -msgstr "ホストの数値範囲を定義する際に、stride (シーケンス番号間の増分) を指定することができます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:213 -msgid "The example above would make the subdomains www01, www03, www05, ..., www49 match, but not www00, www02, www50 and so on, because the stride (increment) is 2 units each step." -msgstr "上記の例では、stride (増分) はステップごとに 2 ユニットであるため、サブドメイン www01、www03、www05、..、www49 は一致しますが、www00、www02、www50 などは一致しません。" - -#: ../../rst/inventory_guide/intro_inventory.rst:215 -msgid "For numeric patterns, leading zeros can be included or removed, as desired. Ranges are inclusive. You can also define alphabetic ranges:" -msgstr "数値のパターンでは、必要に応じて先頭にゼロを含めるか、または削除できます。範囲は包含的範囲も定義できます。また、アルファベットの範囲も定義できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:225 -msgid "Passing multiple inventory sources" -msgstr "複数のインベントリーソースの指定" - -#: ../../rst/inventory_guide/intro_inventory.rst:227 -msgid "You can target multiple inventory sources (directories, dynamic inventory scripts or files supported by inventory plugins) at the same time by giving multiple inventory parameters from the command line or by configuring :envvar:`ANSIBLE_INVENTORY`. This can be useful when you want to target normally separate environments, like staging and production, at the same time for a specific action." -msgstr "コマンドラインから複数のインベントリーパラメーターを指定するか、:envvar:`ANSIBLE_INVENTORY` を設定することで、複数のインベントリーリソース (ディレクトリー、動的インベントリースクリプト、またはインベントリープラグインによりサポートされるファイル) を同時に対象に指定できます。これは、ステージ環境や実稼働環境など、通常は異なる環境を同時に対象に指定にして特定のアクションを実行したい場合に便利です。" - -#: ../../rst/inventory_guide/intro_inventory.rst:232 -msgid "To target two inventory sources from the command line:" -msgstr "コマンドラインから 2 つのソイベントリーソースを対象とするには以下を実行します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:241 -msgid "Organizing inventory in a directory" -msgstr "ディレクトリー内のインベントリーの整理" - -#: ../../rst/inventory_guide/intro_inventory.rst:243 -msgid "You can consolidate multiple inventory sources in a single directory. The simplest version of this is a directory with multiple files instead of a single inventory file. A single file gets difficult to maintain when it gets too long. If you have multiple teams and multiple automation projects, having one inventory file per team or project lets everyone easily find the hosts and groups that matter to them." -msgstr "複数のインベントリーソースを 1 つのディレクトリーに統合できます。これの最も単純なバージョンは、単一のインベントリーファイルではなく、複数のファイルを含むディレクトリーです。1 つのファイルが長くなりすぎると、管理が難しくなります。複数のチームと複数の自動化プロジェクトがある場合、チームまたはプロジェクトごとに 1 つのインベントリーファイルを使用すると、誰でも重要なホストとグループを簡単に見つけることができます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:245 -msgid "You can also combine multiple inventory source types in an inventory directory. This can be useful for combining static and dynamic hosts and managing them as one inventory. The following inventory directory combines an inventory plugin source, a dynamic inventory script, and a file with static hosts:" -msgstr "また、複数のインベントリーソースやソースタイプを 1 つのディレクトリー下にインベントリーを統合できます。これは、静的ホストと動的ホストを組み合わせて、1 つのインベントリーとして管理するのに便利です。次のインベントリーディレクトリーは、インベントリープラグインソース、動的インベントリースクリプト、および静的ホストのファイルを組み合わせたものです。" - -#: ../../rst/inventory_guide/intro_inventory.rst:257 -msgid "You can target this inventory directory as follows:" -msgstr "このインベントリーディレクトリーは、次のように簡単に対象に設定できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:263 -msgid "You can also configure the inventory directory in your ``ansible.cfg`` file. See :ref:`intro_configuration` for more details." -msgstr "``ansible.cfg`` ファイルで inventory ディレクトリーを設定することもできます。詳細は、:ref:`intro_configuration` を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:266 -msgid "Managing inventory load order" -msgstr "インベントリーの読み込み順序の管理" - -#: ../../rst/inventory_guide/intro_inventory.rst:268 -msgid "Ansible loads inventory sources in ASCII order according to the filenames. If you define parent groups in one file or directory and child groups in other files or directories, the files that define the child groups must be loaded first. If the parent groups are loaded first, you will see the error ``Unable to parse /path/to/source_of_parent_groups as an inventory source``." -msgstr "Ansible は、ファイル名に従って、インベントリーソースを ASCII 順に読み込みます。親グループを他のファイルまたはディレクトリーの 1 つまたはディレクトリーで定義し、子グループを定義するファイルを先に読み込む必要があります。親グループが最初に読み込まれると、``Unable to parse /path/to/source_of_parent_groups as an inventory source`` というエラーが表示されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:270 -msgid "For example, if you have a file called ``groups-of-groups`` that defines a ``production`` group with child groups defined in a file called ``on-prem``, Ansible cannot parse the ``production`` group. To avoid this problem, you can control the load order by adding prefixes to the files:" -msgstr "たとえば、``on-prem`` というファイルで定義された子グループを持つ ``production`` グループを定義する ``groups-of-groups`` というファイルがある場合、Ansible は ``production`` グループを解析できません。この問題を回避するには、ファイルに接頭辞を追加して、読み込み順序を制御できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:280 -msgid "You can find examples of how to organize your inventories and group your hosts in :ref:`inventory_setup_examples`." -msgstr "インベントリーを整理し、ホストをグループ化する方法は、:ref:`inventory_setup_examples` を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:285 -msgid "Adding variables to inventory" -msgstr "インベントリーへの変数の追加" - -#: ../../rst/inventory_guide/intro_inventory.rst:287 -msgid "You can store variable values that relate to a specific host or group in inventory. To start with, you may add variables directly to the hosts and groups in your main inventory file." -msgstr "インベントリーの特定のホストまたはグループに関連する変数値を保存することができます。まずは、メインのインベントリーファイルのホストおよびグループに変数を直接追加できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:289 -msgid "We document adding variables in the main inventory file for simplicity. However, storing variables in separate host and group variable files is a more robust approach to describing your system policy. Setting variables in the main inventory file is only a shorthand. See :ref:`splitting_out_vars` for guidelines on storing variable values in individual files in the 'host_vars' directory. See :ref:`splitting_out_vars` for details." -msgstr "簡略化の目的で、メインのインベントリーファイルに変数を追加する方法について説明します。ただし、変数を別々のホスト変数ファイルとグループ変数ファイルに格納する方が、より確実にシステムポリシーを記述できます。メインのインベントリーファイルに変数を設定することは、省略形に過ぎません。'host_vars' ディレクトリーの個別ファイルに変数を保存するガイドラインは、:ref:`splitting_out_vars` を参照してください。詳細は、:ref:`splitting_out_vars` を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:294 -msgid "Assigning a variable to one machine: host variables" -msgstr "あるマシンへの変数の割り当て: ホスト変数" - -#: ../../rst/inventory_guide/intro_inventory.rst:296 -msgid "You can easily assign a variable to a single host, then use it later in playbooks. You can do this directly in your inventory file." -msgstr "1 台のホストに変数を簡単に割り当てると、後で Playbook で使用できます。インベントリーファイルで直接これを実行できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:319 -msgid "Unique values like non-standard SSH ports work well as host variables. You can add them to your Ansible inventory by adding the port number after the hostname with a colon:" -msgstr "非標準の SSH ポートのような一意な値は、ホスト変数としてうまく機能します。ホスト名の後にコロンを付けてポート番号を追加することで、Ansible インベントリーに追加することができます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:325 -msgid "Connection variables also work well as host variables:" -msgstr "接続変数もホスト変数として機能します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:335 -msgid "If you list non-standard SSH ports in your SSH config file, the ``openssh`` connection will find and use them, but the ``paramiko`` connection will not." -msgstr "SSH 設定ファイル内に非標準の SSH ポートの一覧を表示した場合、``openssh`` 接続はそのポートを見つけて使用しますが、``paramiko`` 接続は行われません。" - -#: ../../rst/inventory_guide/intro_inventory.rst:340 -msgid "Inventory aliases" -msgstr "インベントリーエイリアス" - -#: ../../rst/inventory_guide/intro_inventory.rst:342 -msgid "You can also define aliases in your inventory using host variables:" -msgstr "ホスト変数を使用してインベントリーでエイリアスを定義することもできます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:360 -msgid "In this example, running Ansible against the host alias \"jumper\" will connect to 192.0.2.50 on port 5555. See :ref:`behavioral inventory parameters ` to further customize the connection to hosts." -msgstr "この例では、ホストの別名「jumper」に対して Ansible を実行すると、ポート 5555 の 192.0.2.50 に接続されます。ホストへの接続をさらにカスタマイズするには、「:ref:`behavioral inventory parameters `」を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:363 -msgid "Defining variables in INI format" -msgstr "INI 形式での変数の定義" - -#: ../../rst/inventory_guide/intro_inventory.rst:365 -msgid "Values passed in the INI format using the ``key=value`` syntax are interpreted differently depending on where they are declared:" -msgstr "``key=value`` 構文を使用して INI 形式で渡される値が解釈される方法は、宣言される場所に応じて異なります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:367 -msgid "When declared inline with the host, INI values are interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple ``key=value`` parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator. Values that contain whitespace can be quoted (single or double). See the `Python shlex parsing rules`_ for details." -msgstr "ホストのインラインで宣言すると、INI 値は Pythonの リテラル構造 (文字列、数値、タプル、リスト、ディクショナリー、ブール値、なし) として解釈されます。ホストの行は、1 行につき複数の ``key=value`` パラメーターを受け付けます。そのため、スペースが区切り文字ではなく値の一部であることを示す方法が必要です。スペースが含まれる値を引用符(一重または二重)で囲むことができます。詳細は、 `Python shlex 解析ルール`_を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:369 -msgid "When declared in a ``:vars`` section, INI values are interpreted as strings. For example ``var=FALSE`` would create a string equal to 'FALSE'. Unlike host lines, ``:vars`` sections accept only a single entry per line, so everything after the ``=`` must be the value for the entry." -msgstr "``:vars`` セクションで宣言すると、INI の値は文字列として解釈されます。たとえば、``var=FALSE`` は FALSE と等しい文字列を作成します。ホスト行とは異なり、``:vars`` セクションは行ごとに 1 つのエントリーのみを許可するため、``=`` の後に続くすべてのものがエントリーの値である必要があります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:371 -msgid "If a variable value set in an INI inventory must be a certain type (for example, a string or a boolean value), always specify the type with a filter in your task. Do not rely on types set in INI inventories when consuming variables." -msgstr "INI インベントリーに設定されている変数の値が特定の型 (文字列やブール値など) でなければならない場合は、必ずタスクのフィルターで型を指定してください。変数を使用する際に、INI インベントリーに設定されている型に頼らないでください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:373 -msgid "Consider using YAML format for inventory sources to avoid confusion on the actual type of a variable. The YAML inventory plugin processes variable values consistently and correctly." -msgstr "変数の実際のタイプに関する混乱を回避するために、インベントリーソースに YAML 形式を使用することを検討してください。YAML インベントリープラグインは変数の値を一貫して、正しく処理します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:380 -msgid "Assigning a variable to many machines: group variables" -msgstr "多くのマシンへの変数の割り当て: グループ変数" - -#: ../../rst/inventory_guide/intro_inventory.rst:382 -msgid "If all hosts in a group share a variable value, you can apply that variable to an entire group at once." -msgstr "グループ内のすべてのホストが変数の値を共有している場合は、その変数をグループ全体に一度に適用することができます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:408 -msgid "Group variables are a convenient way to apply variables to multiple hosts at once. Before executing, however, Ansible always flattens variables, including inventory variables, to the host level. If a host is a member of multiple groups, Ansible reads variable values from all of those groups. If you assign different values to the same variable in different groups, Ansible chooses which value to use based on internal :ref:`rules for merging `." -msgstr "グループ変数は、複数のホストに一度に変数を適用する便利な方法です。しかし、Ansible は実行前に、インベントリー変数を含む変数を常にホストレベルにフラット化します。ホストが複数のグループに属している場合、Ansible はそれらのグループのすべてから変数の値を読み取ります。異なるグループで同じ変数に異なる値を割り当てた場合、Ansible は内部 :ref:`マージのルール ` に基づいてどの値を使用するかを選択します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:413 -msgid "Inheriting variable values: group variables for groups of groups" -msgstr "変数値の継承: グループのグループ用グループ変数" - -#: ../../rst/inventory_guide/intro_inventory.rst:415 -msgid "You can apply variables to parent groups (nested groups or groups of groups) as well as to child groups. The syntax is the same: ``:vars`` for INI format and ``vars:`` for YAML format:" -msgstr "子グループだけでなく、親グループ (ネストされたグループまたはグループのグループ) にも変数を適用できます。構文は同じです (INI 形式は ``:vars``、YAML 形式は ``vars:``)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:472 -msgid "A child group's variables will have higher precedence (override) a parent group's variables." -msgstr "子グループの変数は、親グループの変数よりも優先度が高くなります (オーバライド)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:477 -msgid "Organizing host and group variables" -msgstr "ホスト変数とグループ変数の整理" - -#: ../../rst/inventory_guide/intro_inventory.rst:479 -msgid "Although you can store variables in the main inventory file, storing separate host and group variables files may help you organize your variable values more easily. You can also use lists and hash data in host and group variables files, which you cannot do in your main inventory file." -msgstr "変数はメインインベントリーファイルに保存できますが、ホスト変数ファイルとグループ変数ファイルを別々に保存すると、変数値をより簡単に整理できる場合があります。ホスト変数ファイルとグループ変数ファイルでリストとハッシュデータを使用することもできますが、これはメインのインベントリーファイルでは使用できません。" - -#: ../../rst/inventory_guide/intro_inventory.rst:481 -msgid "Host and group variable files must use YAML syntax. Valid file extensions include '.yml', '.yaml', '.json', or no file extension. See :ref:`yaml_syntax` if you are new to YAML." -msgstr "ホストおよびグループ変数ファイルは、YAML 構文を使用する必要があります。有効なファイル拡張子には、.yml、.yaml、.json が含まれるか、ファイル拡張子がありません。YAML を使用したことがない場合には、:ref:`yaml_syntax` を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:483 -msgid "Ansible loads host and group variable files by searching paths relative to the inventory file or the playbook file. If your inventory file at ``/etc/ansible/hosts`` contains a host named 'foosball' that belongs to two groups, 'raleigh' and 'webservers', that host will use variables in YAML files at the following locations:" -msgstr "Ansible は、インベントリーファイルまたは Playbook ファイルからの相対パスを検索して、ホストおよびグループ変数ファイルを読み込みます。``/etc/ansible/hosts`` のインベントリーファイルに「foosball」という名前のホストがあり、それが「raleigh」と「webservers」という 2 つのグループに所属している場合、そのホストは以下の場所にある YAML ファイルの変数を使用します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:491 -msgid "For example, if you group hosts in your inventory by datacenter, and each datacenter uses its own NTP server and database server, you can create a file called ``/etc/ansible/group_vars/raleigh`` to store the variables for the ``raleigh`` group:" -msgstr "たとえば、インベントリー内のホストをデータセンターごとにまとめ、各データセンターが独自の NTP サーバーおよびデータベースサーバーを使用する場合は、``/etc/ansible/group_vars/raleigh`` という名前のファイルを作成して、``raleigh`` グループの変数を保存できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:499 -msgid "You can also create *directories* named after your groups or hosts. Ansible will read all the files in these directories in lexicographical order. An example with the 'raleigh' group:" -msgstr "また、グループまたはホストの名前が付けられた *ディレクトリー* も作成できます。Ansible は、これらのディレクトリーに含まれるすべてのファイルをディクショナリーの順に読み込みます。例では、「raleigh」グループを使用しています。" - -#: ../../rst/inventory_guide/intro_inventory.rst:506 -msgid "All hosts in the 'raleigh' group will have the variables defined in these files available to them. This can be very useful to keep your variables organized when a single file gets too big, or when you want to use :ref:`Ansible Vault` on some group variables." -msgstr "「raleigh」グループのすべてのホストは、これらのファイルで定義された変数を利用できるようになります。これは、1 つのファイルが大きくなりすぎたときに、変数を整理しておくのに非常に便利です。また、いくつかのグループ変数に :ref:`Ansible Vault` を使用したい場合にも便利です。" - -#: ../../rst/inventory_guide/intro_inventory.rst:510 -msgid "For ``ansible-playbook`` you can also add ``group_vars/`` and ``host_vars/`` directories to your playbook directory. Other Ansible commands (for example, ``ansible``, ``ansible-console``, and so on) will only look for ``group_vars/`` and ``host_vars/`` in the inventory directory. If you want other commands to load group and host variables from a playbook directory, you must provide the ``--playbook-dir`` option on the command line. If you load inventory files from both the playbook directory and the inventory directory, variables in the playbook directory will override variables set in the inventory directory." -msgstr "``ansible-playbook`` に関して、ディレクトリー ``group_vars/``および ``host_vars/`` を Playbook ディレクトリーに追加することもできます。他の Ansible コマンド (たとえば、``ansible``、``ansible-console`` など) は、インベントリーディレクトリー内の ``group_vars/`` と ``host_vars/`` のみを探します。他のコマンドで Playbook ディレクトリーからグループ変数やホスト変数を読み込む場合は、コマンドラインで ``--playbook-dir`` オプションを指定する必要があります。Playbook ディレクトリーと inventory ディレクトリーの両方からインベントリーファイルを読み込んだ場合、Playbook ディレクトリーの変数はインベントリーディレクトリーで設定された変数よりも優先されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:513 -msgid "Keeping your inventory file and variables in a git repo (or other version control) is an excellent way to track changes to your inventory and host variables." -msgstr "git リポジトリー (または他のバージョン管理) でインベントリーファイルおよび変数を維持することは、インベントリーおよびホスト変数への変更を追跡する優れた方法です。" - -#: ../../rst/inventory_guide/intro_inventory.rst:519 -msgid "How variables are merged" -msgstr "変数をマージする方法" - -#: ../../rst/inventory_guide/intro_inventory.rst:521 -msgid "By default variables are merged/flattened to the specific host before a play is run. This keeps Ansible focused on the Host and Task, so groups don't really survive outside of inventory and host matching. By default, Ansible overwrites variables including the ones defined for a group and/or host (see :ref:`DEFAULT_HASH_BEHAVIOUR`). The order/precedence is (from lowest to highest):" -msgstr "デフォルトでは、プレイが実行される前に、変数が特定のホストにマージ/フラット化されます。これにより、Ansible はホストとタスクに焦点を当てているため、グループはインベントリーとホストの一致以外では実際には存続しません。デフォルトでは、Ansible はグループやホストに定義されたものを含む変数を上書きします (「:ref:`DEFAULT_HASH_BEHAVIOUR`」を参照)。その順序/優先順位は (低いものから高いものへ) となっています。" - -#: ../../rst/inventory_guide/intro_inventory.rst:523 -msgid "all group (because it is the 'parent' of all other groups)" -msgstr "すべてのグループ (他のすべてのグループの「親」であるため)" - -#: ../../rst/inventory_guide/intro_inventory.rst:524 -msgid "parent group" -msgstr "親グループ" - -#: ../../rst/inventory_guide/intro_inventory.rst:525 -msgid "child group" -msgstr "子グループ" - -#: ../../rst/inventory_guide/intro_inventory.rst:526 -msgid "host" -msgstr "host" - -#: ../../rst/inventory_guide/intro_inventory.rst:528 -msgid "By default Ansible merges groups at the same parent/child level in ASCII order, and variables from the last group loaded overwrite variables from the previous groups. For example, an a_group will be merged with b_group and b_group vars that match will overwrite the ones in a_group." -msgstr "デフォルトでは、Ansible は同じ親子レベルのグループを ASCII 順にマージし、最後に読み込まれたグループの変数がそれ以前のグループからの変数を上書きします。たとえば、a_group は b_group にマージされ、一致する b_group の変数が a_group の変数を上書きします。" - -#: ../../rst/inventory_guide/intro_inventory.rst:530 -msgid "You can change this behavior by setting the group variable ``ansible_group_priority`` to change the merge order for groups of the same level (after the parent/child order is resolved). The larger the number, the later it will be merged, giving it higher priority. This variable defaults to ``1`` if not set. For example:" -msgstr "この動作を変更するには、グループ変数 ``ansible_group_priority`` を設定して、同じレベルのグループのマージ順序を変更することができます (親子の順序が解決された後)。数字が大きいほど後にマージされ、優先順位が高くなります。この変数が設定されていない場合のデフォルトは ``1`` です。たとえば、以下のようになります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:542 -msgid "In this example, if both groups have the same priority, the result would normally have been ``testvar == b``, but since we are giving the ``a_group`` a higher priority the result will be ``testvar == a``." -msgstr "この例では、両方のグループの優先順位が同じ場合、結果は通常 ``testvar == b`` になりますが、``a_group`` の優先度が高いため、結果は ``testvar == a`` になります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:544 -msgid "``ansible_group_priority`` can only be set in the inventory source and not in group_vars/, as the variable is used in the loading of group_vars." -msgstr "``ansible_group_priority`` は、group_vars の読み込みでこの変数が使用されるため、インベントリーソースでのみ設定でき、group_vars/ では設定できません。" - -#: ../../rst/inventory_guide/intro_inventory.rst:547 -msgid "Managing inventory variable load order" -msgstr "インベントリー変数の読み込み順序の管理" - -#: ../../rst/inventory_guide/intro_inventory.rst:549 -msgid "When using multiple inventory sources, keep in mind that any variable conflicts are resolved according to the rules described in :ref:`how_we_merge` and :ref:`ansible_variable_precedence`. You can control the merging order of variables in inventory sources to get the variable value you need." -msgstr "複数のインベントリーソースを使用する場合は、variable および :ref:`how_we_merge` と :ref:`ansible_variable_precedence` で説明されているルールに従って変数の競合が解決されることに注意してください。インベントリーソースで変数のマージ順序を制御し、必要な変数の値を取得できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:552 -msgid "When you pass multiple inventory sources at the command line, Ansible merges variables in the order you pass those parameters. If ``[all:vars]`` in staging inventory defines ``myvar = 1`` and production inventory defines ``myvar = 2``, then:" -msgstr "コマンドラインで複数のインベントリーソースを渡すと、Ansible はそれらのパラメーターを渡す順序で変数をマージします。ステージングインベントリーの ``[all:vars]`` が ``myvar = 1`` を定義し、実稼働インベントリーが ``myvar = 2`` を定義している場合には、" - -#: ../../rst/inventory_guide/intro_inventory.rst:554 -msgid "Pass ``-i staging -i production`` to run the playbook with ``myvar = 2``." -msgstr "* ``-i staging -i production`` を渡して ``myvar = 2`` を指定して Playbook を実行します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:555 -msgid "Pass ``-i production -i staging`` to run the playbook with ``myvar = 1``." -msgstr "* ``-i production -i staging`` を渡して ``myvar = 1`` を指定して Playbook を実行します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:557 -msgid "When you put multiple inventory sources in a directory, Ansible merges them in ASCII order according to the filenames. You can control the load order by adding prefixes to the files:" -msgstr "ディレクトリーに複数のインベントリーソースを配置すると、Ansible はファイル名に従って ASCII 順でマージします。ファイルに接頭辞を追加することで、読み込み順序を制御できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:568 -msgid "If ``01-openstack.yml`` defines ``myvar = 1`` for the group ``all``, ``02-dynamic-inventory.py`` defines ``myvar = 2``, and ``03-static-inventory`` defines ``myvar = 3``, the playbook will be run with ``myvar = 3``." -msgstr "``01-openstack.yml`` がグループ ``all`` に対して ``myvar = 1`` を定義し、``02-dynamic-inventory.py`` が ``myvar = 2`` を定義し、``03-static-inventory`` が ``myvar = 3`` を定義した場合は、Playbook が ``myvar = 3`` で実行します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:571 -msgid "For more details on inventory plugins and dynamic inventory scripts see :ref:`inventory_plugins` and :ref:`intro_dynamic_inventory`." -msgstr "インベントリープラグインおよび動的インベントリースクリプトの詳細は、「:ref:`inventory_plugins`」および「:ref:`intro_dynamic_inventory`」を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:576 -msgid "Connecting to hosts: behavioral inventory parameters" -msgstr "ホストへの接続: 動作用インベントリーパラメーター" - -#: ../../rst/inventory_guide/intro_inventory.rst:578 -msgid "As described above, setting the following variables control how Ansible interacts with remote hosts." -msgstr "上記のように、以下の変数を設定して、Ansible がリモートホストと対話する方法を制御します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:580 -msgid "Host connection:" -msgstr "ホスト接続:" - -#: ../../rst/inventory_guide/intro_inventory.rst:585 -msgid "ansible_connection" -msgstr "ansible_connection" - -#: ../../rst/inventory_guide/intro_inventory.rst:585 -msgid "Connection type to the host. This can be the name of any of ansible's connection plugins. SSH protocol types are ``smart``, ``ssh`` or ``paramiko``. The default is smart. Non-SSH based types are described in the next section." -msgstr "ホストへの接続タイプ。これは、Ansible の connection プラグインの名前です。SSH プロトコルタイプは ``smart``、``ssh``、または ``paramiko`` です。デフォルトは smart です。SSH ベース以外のタイプは次のセクションで説明します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:587 -msgid "General for all connections:" -msgstr "すべての接続に対する一般的な設定:" - -#: ../../rst/inventory_guide/intro_inventory.rst:589 -#: ../../rst/inventory_guide/intro_inventory.rst:692 -msgid "ansible_host" -msgstr "ansible_host" - -#: ../../rst/inventory_guide/intro_inventory.rst:590 -msgid "The name of the host to connect to, if different from the alias you wish to give to it." -msgstr "接続するホストの名前 (割り当てたいエイリアスと異なる場合)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:591 -msgid "ansible_port" -msgstr "ansible_port" - -#: ../../rst/inventory_guide/intro_inventory.rst:592 -msgid "The connection port number, if not the default (22 for ssh)" -msgstr "デフォルトではない場合 (ssh の場合は 22) は、接続ポート番号。" - -#: ../../rst/inventory_guide/intro_inventory.rst:593 -#: ../../rst/inventory_guide/intro_inventory.rst:694 -msgid "ansible_user" -msgstr "ansible_user" - -#: ../../rst/inventory_guide/intro_inventory.rst:594 -msgid "The user name to use when connecting to the host" -msgstr "ホストに接続する際に使用するユーザー名。" - -#: ../../rst/inventory_guide/intro_inventory.rst:597 -msgid "ansible_password" -msgstr "ansible_password" - -#: ../../rst/inventory_guide/intro_inventory.rst:596 -msgid "The password to use to authenticate to the host (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`)" -msgstr "ホストへの認証に使用するパスワード (この変数を平文で保存しないでください。常に Valut を使用してください。「:ref:`tip_for_variables_and_vaults`」を参照)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:599 -msgid "Specific to the SSH connection:" -msgstr "SSH 接続に固有:" - -#: ../../rst/inventory_guide/intro_inventory.rst:601 -msgid "ansible_ssh_private_key_file" -msgstr "ansible_ssh_private_key_file" - -#: ../../rst/inventory_guide/intro_inventory.rst:602 -msgid "Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent." -msgstr "ssh が使用する秘密鍵ファイル。複数の鍵を使用し、SSH エージェントを使用したくない場合に便利です。" - -#: ../../rst/inventory_guide/intro_inventory.rst:605 -msgid "ansible_ssh_common_args" -msgstr "ansible_ssh_common_args" - -#: ../../rst/inventory_guide/intro_inventory.rst:604 -msgid "This setting is always appended to the default command line for :command:`sftp`, :command:`scp`, and :command:`ssh`. Useful to configure a ``ProxyCommand`` for a certain host (or group)." -msgstr "この設定は、常に :command:`sftp`、:command:`scp`、および :command:`ssh` のデフォルトのコマンドラインに追加されます。特定のホスト (またはグループ) に ``ProxyCommand`` を設定してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:607 -msgid "ansible_sftp_extra_args" -msgstr "ansible_sftp_extra_args" - -#: ../../rst/inventory_guide/intro_inventory.rst:608 -msgid "This setting is always appended to the default :command:`sftp` command line." -msgstr "この設定は、デフォルトの :command:`sftp` コマンドラインに常に付加されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:609 -msgid "ansible_scp_extra_args" -msgstr "ansible_scp_extra_args" - -#: ../../rst/inventory_guide/intro_inventory.rst:610 -msgid "This setting is always appended to the default :command:`scp` command line." -msgstr "この設定は、デフォルトの :command:`scp` コマンドラインに常に付加されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:611 -msgid "ansible_ssh_extra_args" -msgstr "ansible_ssh_extra_args" - -#: ../../rst/inventory_guide/intro_inventory.rst:612 -msgid "This setting is always appended to the default :command:`ssh` command line." -msgstr "この設定は、デフォルトの :command:`ssh` コマンドラインに常に付加されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:613 -msgid "ansible_ssh_pipelining" -msgstr "ansible_ssh_pipelining" - -#: ../../rst/inventory_guide/intro_inventory.rst:614 -msgid "Determines whether or not to use SSH pipelining. This can override the ``pipelining`` setting in :file:`ansible.cfg`." -msgstr "SSH パイプラインを使用するかどうかを決定します。これは :file:`ansible.cfg` の ``pipelining`` の設定を上書きすることができます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:617 -msgid "ansible_ssh_executable (added in version 2.2)" -msgstr "ansible_ssh_executable (バージョン 2.2 で追加)" - -#: ../../rst/inventory_guide/intro_inventory.rst:616 -msgid "This setting overrides the default behavior to use the system :command:`ssh`. This can override the ``ssh_executable`` setting in :file:`ansible.cfg`." -msgstr "この設定により、システムの :command:`ssh` を使用するようにデフォルトの動作が上書きされます。これにより、:file:`ansible.cfg` の ``ssh_executable`` 設定を上書きできます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:619 -msgid "Privilege escalation (see :ref:`Ansible Privilege Escalation` for further details):" -msgstr "権限の昇格 (詳細は「:ref:`Ansible 権限昇格`」を参照):" - -#: ../../rst/inventory_guide/intro_inventory.rst:621 -#: ../../rst/inventory_guide/intro_inventory.rst:696 -msgid "ansible_become" -msgstr "ansible_become" - -#: ../../rst/inventory_guide/intro_inventory.rst:622 -msgid "Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation" -msgstr "``ansible_sudo`` または ``ansible_su`` と同等です。これにより、権限昇格を強制できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:623 -msgid "ansible_become_method" -msgstr "ansible_become_method" - -#: ../../rst/inventory_guide/intro_inventory.rst:624 -msgid "Allows to set privilege escalation method" -msgstr "権限昇格メソッドの設定を許可します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:625 -msgid "ansible_become_user" -msgstr "ansible_become_user" - -#: ../../rst/inventory_guide/intro_inventory.rst:626 -msgid "Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation" -msgstr "``ansible_sudo_user`` または ``ansible_su_user`` と同等で、権限昇格により become を行うユーザーを設定できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:627 -msgid "ansible_become_password" -msgstr "ansible_become_password" - -#: ../../rst/inventory_guide/intro_inventory.rst:628 -msgid "Equivalent to ``ansible_sudo_password`` or ``ansible_su_password``, allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`)" -msgstr "``ansible_sudo_password`` または ``ansible_su_password`` と同等で、特権昇格パスワードを設定できます (この変数を平文で保存せず、常に vault を使用してください。「:ref:`tip_for_variables_and_vaults`」を参照してください)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:629 -msgid "ansible_become_exe" -msgstr "ansible_become_exe" - -#: ../../rst/inventory_guide/intro_inventory.rst:630 -msgid "Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected" -msgstr "``ansible_sudo_exe`` または ``ansible_su_exe`` と同等で、選択した昇格メソッドの実行ファイルを設定できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:632 -msgid "ansible_become_flags" -msgstr "ansible_become_flags" - -#: ../../rst/inventory_guide/intro_inventory.rst:632 -msgid "Equivalent to ``ansible_sudo_flags`` or ``ansible_su_flags``, allows you to set the flags passed to the selected escalation method. This can be also set globally in :file:`ansible.cfg` in the ``sudo_flags`` option" -msgstr "``ansible_sudo_flags`` または ``ansible_su_flags`` と同等で、選択された昇格方法に渡されるフラグを設定することができます。これは ``sudo_flags`` オプションの :file:`ansible.cfg` でもグローバルに設定できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:634 -msgid "Remote host environment parameters:" -msgstr "リモートホスト環境パラメーター:" - -#: ../../rst/inventory_guide/intro_inventory.rst:642 -msgid "ansible_shell_type" -msgstr "ansible_shell_type" - -#: ../../rst/inventory_guide/intro_inventory.rst:639 -msgid "The shell type of the target system. You should not use this setting unless you have set the :ref:`ansible_shell_executable` to a non-Bourne (sh) compatible shell. By default commands are formatted using ``sh``-style syntax. Setting this to ``csh`` or ``fish`` will cause commands executed on target systems to follow those shell's syntax instead." -msgstr "ターゲットシステムのシェルタイプ。:ref:`ansible_shell_executable` を Bourne (sh) 以外の互換シェルに設定しない限り、この設定は使用しないでください。デフォルトでは、コマンドは ``sh`` スタイルの構文を使用してフォーマットされます。これを ``csh`` または ``fish`` に設定すると、ターゲットシステムで実行するコマンドがシェルの構文に従います。" - -#: ../../rst/inventory_guide/intro_inventory.rst:651 -msgid "ansible_python_interpreter" -msgstr "ansible_python_interpreter" - -#: ../../rst/inventory_guide/intro_inventory.rst:647 -msgid "The target host python path. This is useful for systems with more than one Python or not located at :command:`/usr/bin/python` such as \\*BSD, or where :command:`/usr/bin/python` is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's path to be set right and also assumes the :program:`python` executable is named python, where the executable might be named something like :program:`python2.6`." -msgstr "ターゲットホストの Python パス。これは、複数の Python があるシステム、\\*BSD などの :command:`/usr/bin/python` にないシステム、:command:`/usr/bin/python` が 2.X シリーズの Python 以外のシステムに役立ちます。リモートユーザーのパスを正しく設定する必要があり、:program:`python` 実行ファイルの名前が python であると想定するため、:command:`/usr/bin/env` メカニズムは使用しません。実行ファイルの名前は :program:`python2.6` のようになります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:655 -msgid "ansible_*_interpreter" -msgstr "ansible_*_interpreter" - -#: ../../rst/inventory_guide/intro_inventory.rst:654 -msgid "Works for anything such as ruby or perl and works just like :ref:`ansible_python_interpreter`. This replaces shebang of modules which will run on that host." -msgstr "ruby や perl などのあらゆるもので動作し、:ref:`ansible_python_interpreter` のように機能します。これは、そのホストで実行されるモジュールのシバンに代わるものです。" - -#: ../../rst/inventory_guide/intro_inventory.rst:666 -msgid "ansible_shell_executable" -msgstr "ansible_shell_executable" - -#: ../../rst/inventory_guide/intro_inventory.rst:662 -msgid "This sets the shell the ansible controller will use on the target machine, overrides ``executable`` in :file:`ansible.cfg` which defaults to :command:`/bin/sh`. You should really only change it if is not possible to use :command:`/bin/sh` (in other words, if :command:`/bin/sh` is not installed on the target machine or cannot be run from sudo.)." -msgstr "これにより、Ansible コントローラーがターゲットマシンで使用するシェルを設定し、:file:`ansible.cfg` の ``executable`` を上書きします。デフォルトは :command:`/bin/sh` です。:command:`/bin/sh` を使用できない場合にのみ変更する必要があります (つまり、:command:`/bin/sh` がターゲットマシンにインストールされていない場合、または sudo から実行できない場合)。" - -#: ../../rst/inventory_guide/intro_inventory.rst:668 -msgid "Examples from an Ansible-INI host file:" -msgstr "Ansible-INI ホストファイルの例:" - -#: ../../rst/inventory_guide/intro_inventory.rst:678 -msgid "Non-SSH connection types" -msgstr "SSH 以外の接続タイプ" - -#: ../../rst/inventory_guide/intro_inventory.rst:680 -msgid "As stated in the previous section, Ansible executes playbooks over SSH but it is not limited to this connection type. With the host specific parameter ``ansible_connection=``, the connection type can be changed. The following non-SSH based connectors are available:" -msgstr "前のセクションで説明したように、Ansible は SSH で Playbook を実行しますが、この接続タイプは制限されていません。ホスト固有のパラメーター ``ansible_connection=`` では、接続タイプを変更できます。次の SSH 以外のコネクターを利用できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:684 -msgid "**local**" -msgstr "**local**" - -#: ../../rst/inventory_guide/intro_inventory.rst:686 -msgid "This connector can be used to deploy the playbook to the control machine itself." -msgstr "このコネクターは、Playbook をコントロールマシン自体にデプロイするために使用できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:688 -msgid "**docker**" -msgstr "**docker**" - -#: ../../rst/inventory_guide/intro_inventory.rst:690 -msgid "This connector deploys the playbook directly into Docker containers using the local Docker client. The following parameters are processed by this connector:" -msgstr "このコネクターは、ローカルの Docker クライアントを使用して Playbook を直接 Docker コンテナーにデプロイします。以下のパラメーターはこのコネクターによって処理されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:693 -msgid "The name of the Docker container to connect to." -msgstr "接続先の Docker コンテナーの名前。" - -#: ../../rst/inventory_guide/intro_inventory.rst:695 -msgid "The user name to operate within the container. The user must exist inside the container." -msgstr "コンテナー内で操作するためのユーザ名。ユーザーはコンテナー内に存在している必要があります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:697 -msgid "If set to ``true`` the ``become_user`` will be used to operate within the container." -msgstr "``true`` に設定すると、``become_user`` はコンテナー内で動作するために使用されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:699 -msgid "ansible_docker_extra_args" -msgstr "ansible_docker_extra_args" - -#: ../../rst/inventory_guide/intro_inventory.rst:699 -msgid "Could be a string with any additional arguments understood by Docker, which are not command specific. This parameter is mainly used to configure a remote Docker daemon to use." -msgstr "Docker が認識する追加の引数を持つ文字列を指定できますが、これはコマンド固有ではありません。このパラメーターは主に、使用するリモート Docker デーモンを設定するために使用されます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:701 -msgid "Here is an example of how to instantly deploy to created containers:" -msgstr "以下は、作成されたコンテナーに即時にデプロイする例を示しています。" - -#: ../../rst/inventory_guide/intro_inventory.rst:725 -msgid "For a full list with available plugins and examples, see :ref:`connection_plugin_list`." -msgstr "利用可能なプラグインとサンプルの一覧は、「:ref:`connection_plugin_list`」を参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:727 -msgid "If you're reading the docs from the beginning, this may be the first example you've seen of an Ansible playbook. This is not an inventory file. Playbooks will be covered in great detail later in the docs." -msgstr "ドキュメントを最初から読んでいる場合、これは Ansible Playbook を初めて確認した例です。これはインベントリーファイルではありません。Playbook は、ドキュメントで後ほど詳細に説明しています。" - -#: ../../rst/inventory_guide/intro_inventory.rst:733 -msgid "Inventory setup examples" -msgstr "インベントリーの設定例" - -#: ../../rst/inventory_guide/intro_inventory.rst:735 -msgid "See also :ref:`sample_setup`, which shows inventory along with playbooks and other Ansible artifacts." -msgstr "Playbook およびその他の Ansible アーティファクトとともにインベントリーを表示する「:ref:`sample_setup`」も参照してください。" - -#: ../../rst/inventory_guide/intro_inventory.rst:740 -msgid "Example: One inventory per environment" -msgstr "例: 各環境に 1 つのインベントリー" - -#: ../../rst/inventory_guide/intro_inventory.rst:742 -msgid "If you need to manage multiple environments it's sometimes prudent to have only hosts of a single environment defined per inventory. This way, it is harder to, for instance, accidentally change the state of nodes inside the \"test\" environment when you actually wanted to update some \"staging\" servers." -msgstr "複数の環境を管理する必要がある場合、インベントリーごとに 1 つの環境のホストのみを定義することが賢明な場合があります。こうすることで、たとえば、実際には「ステージング」サーバーを更新したいのに、誤って「テスト」環境内のノードの状態を変更してしまうことが起こりにくくなります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:748 -msgid "For the example mentioned above you could have an :file:`inventory_test` file:" -msgstr "前述の例では、:file:`inventory_test` というファイルがあります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:762 -msgid "That file only includes hosts that are part of the \"test\" environment. Define the \"staging\" machines in another file called :file:`inventory_staging`:" -msgstr "このファイルには、「テスト」環境に含まれるホストのみが含まれます。:file:`inventory_staging` と呼ばれる別のファイルの「ステージング」マシンを定義します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:777 -msgid "To apply a playbook called :file:`site.yml` to all the app servers in the test environment, use the following command:" -msgstr "`site.yml` という名前の Playbook をテスト環境のすべてのアプリケーションサーバーに適用するには、次のコマンドを使用します。" - -#: ../../rst/inventory_guide/intro_inventory.rst:788 -msgid "Example: Group by function" -msgstr "例: 機能別にグループ化" - -#: ../../rst/inventory_guide/intro_inventory.rst:790 -msgid "In the previous section you already saw an example for using groups in order to cluster hosts that have the same function. This allows you, for instance, to define firewall rules inside a playbook or role affecting only database servers:" -msgstr "前セクションでは、同じ機能を持つホストをクラスター化するために、グループを使用する例をすでに提示しています。これにより、データベースサーバーだけに影響する Playbook またはロール内でファイアウォールルールを定義できます。" - -#: ../../rst/inventory_guide/intro_inventory.rst:808 -msgid "Example: Group by location" -msgstr "例: 場所別にグループ化" - -#: ../../rst/inventory_guide/intro_inventory.rst:810 -msgid "Other tasks might be focused on where a certain host is located. Let's say that ``db01.test.example.com`` and ``app01.test.example.com`` are located in DC1 while ``db02.test.example.com`` is in DC2:" -msgstr "また、特定のホストがどこにあるかに焦点を当てたタスクもあります。たとえば、``db01.test.example.com`` と ``app01.test.example.com`` が DC1 にあり、``db02.test.example.com`` が DC2 にあるとします。" - -#: ../../rst/inventory_guide/intro_inventory.rst:823 -msgid "In practice, you might even end up mixing all these setups as you might need to, on one day, update all nodes in a specific data center while, on another day, update all the application servers no matter their location." -msgstr "実際には、たとえば特定のデータセンター内のすべてのノードを更新する日と、置かれている場所に関係なくすべてのアプリケーションサーバーを更新する日が必要になるため、これらすべての設定を組み合わせて使用することがあります。" - -#: ../../rst/inventory_guide/intro_inventory.rst:830 -msgid ":ref:`inventory_plugins`" -msgstr ":ref:`inventory_plugins`" - -#: ../../rst/inventory_guide/intro_inventory.rst:831 -msgid "Pulling inventory from dynamic or static sources" -msgstr "動的ソースまたは静的ソースからのインベントリーのプル" - -#: ../../rst/inventory_guide/intro_inventory.rst:832 -msgid ":ref:`intro_dynamic_inventory`" -msgstr ":ref:`intro_dynamic_inventory`" - -#: ../../rst/inventory_guide/intro_inventory.rst:833 -msgid "Pulling inventory from dynamic sources, such as cloud providers" -msgstr "クラウドプロバイダーなどの動的ソースからのインベントリーのプル" - -#: ../../rst/inventory_guide/intro_inventory.rst:834 -#: ../../rst/inventory_guide/intro_patterns.rst:246 -msgid ":ref:`intro_adhoc`" -msgstr ":ref:`intro_adhoc`" - -#: ../../rst/inventory_guide/intro_inventory.rst:835 -#: ../../rst/inventory_guide/intro_patterns.rst:247 -msgid "Examples of basic commands" -msgstr "基本コマンドの例" - -#: ../../rst/inventory_guide/intro_inventory.rst:836 -#: ../../rst/inventory_guide/intro_patterns.rst:248 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/inventory_guide/intro_inventory.rst:837 -msgid "Learning Ansible's configuration, deployment, and orchestration language." -msgstr "Ansible の設定、デプロイメント、およびオーケストレーション言語について" - -#: ../../rst/inventory_guide/intro_patterns.rst:4 -msgid "Patterns: targeting hosts and groups" -msgstr "パターン: ホストおよびグループを対象とする" - -#: ../../rst/inventory_guide/intro_patterns.rst:6 -msgid "When you execute Ansible through an ad hoc command or by running a playbook, you must choose which managed nodes or groups you want to execute against. Patterns let you run commands and playbooks against specific hosts and/or groups in your inventory. An Ansible pattern can refer to a single host, an IP address, an inventory group, a set of groups, or all hosts in your inventory. Patterns are highly flexible - you can exclude or require subsets of hosts, use wildcards or regular expressions, and more. Ansible executes on all inventory hosts included in the pattern." -msgstr "アドホックコマンドまたは Playbook から Ansible を実行する場合は、実行する管理ノードまたはグループを選択する必要があります。パターンにより、インベントリー内の特定のホストやグループに対してコマンドと Playbook を実行できます。Ansible パターンは、1 台のホスト、IP アドレス、インベントリーグループ、グループセット、またはインベントリー内のすべてのホストを参照できます。パターンは柔軟性が高く、ホストのサブセットを除外または要求したり、ワイルドカードや正規表現を使用したりできます。Ansible は、パターンに含まれるすべてのインベントリーホストで実行します。" - -#: ../../rst/inventory_guide/intro_patterns.rst:16 -msgid "Using patterns" -msgstr "パターンの使用" - -#: ../../rst/inventory_guide/intro_patterns.rst:18 -msgid "You use a pattern almost any time you execute an ad hoc command or a playbook. The pattern is the only element of an :ref:`ad hoc command` that has no flag. It is usually the second element:" -msgstr "アドホックコマンドまたは Playbook を実行する際は、ほぼ常にパターンを使用します。パターンは、フラグのない :ref:`アドホックコマンド` の唯一の要素です。通常は 2 番目の要素になります。" - -#: ../../rst/inventory_guide/intro_patterns.rst:24 -#: ../../rst/inventory_guide/intro_patterns.rst:37 -msgid "For example:" -msgstr "例:" - -#: ../../rst/inventory_guide/intro_patterns.rst:30 -msgid "In a playbook the pattern is the content of the ``hosts:`` line for each play:" -msgstr "Playbook では、パターンは各プレイの ``hosts:`` 行の内容になります。" - -#: ../../rst/inventory_guide/intro_patterns.rst:44 -msgid "Since you often want to run a command or playbook against multiple hosts at once, patterns often refer to inventory groups. Both the ad hoc command and the playbook above will execute against all machines in the ``webservers`` group." -msgstr "多くの場合は、コマンドまたは Playbook を複数のホストに対して一度に実行するため、パターンは多くの場合インベントリーグループを参照します。アドホックコマンドと上記の Playbook は、``webservers`` グループのすべてのマシンに対して実行されます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:49 -msgid "Common patterns" -msgstr "一般的なパターン" - -#: ../../rst/inventory_guide/intro_patterns.rst:51 -msgid "This table lists common patterns for targeting inventory hosts and groups." -msgstr "以下の表は、インベントリーホストおよびグループを対象に設定する一般的なパターンを示しています。" - -#: ../../rst/inventory_guide/intro_patterns.rst:57 -msgid "Description" -msgstr "説明" - -#: ../../rst/inventory_guide/intro_patterns.rst:57 -msgid "Pattern(s)" -msgstr "パターン" - -#: ../../rst/inventory_guide/intro_patterns.rst:57 -msgid "Targets" -msgstr "ターゲット" - -#: ../../rst/inventory_guide/intro_patterns.rst:59 -msgid "All hosts" -msgstr "すべてのホスト" - -#: ../../rst/inventory_guide/intro_patterns.rst:59 -msgid "all (or \\*)" -msgstr "all (または \\*)" - -#: ../../rst/inventory_guide/intro_patterns.rst:61 -msgid "One host" -msgstr "1 台のホスト" - -#: ../../rst/inventory_guide/intro_patterns.rst:61 -msgid "host1" -msgstr "host1" - -#: ../../rst/inventory_guide/intro_patterns.rst:63 -msgid "Multiple hosts" -msgstr "複数のホスト" - -#: ../../rst/inventory_guide/intro_patterns.rst:63 -msgid "host1:host2 (or host1,host2)" -msgstr "host1:host2 (または host1,host2)" - -#: ../../rst/inventory_guide/intro_patterns.rst:65 -msgid "One group" -msgstr "1 つのグループ" - -#: ../../rst/inventory_guide/intro_patterns.rst:65 -msgid "webservers" -msgstr "webservers" - -#: ../../rst/inventory_guide/intro_patterns.rst:67 -msgid "Multiple groups" -msgstr "複数グループ" - -#: ../../rst/inventory_guide/intro_patterns.rst:67 -msgid "webservers:dbservers" -msgstr "webservers:dbservers" - -#: ../../rst/inventory_guide/intro_patterns.rst:67 -msgid "all hosts in webservers plus all hosts in dbservers" -msgstr "webservers 上のすべてのホストと、dbservers 上のすべてのホスト" - -#: ../../rst/inventory_guide/intro_patterns.rst:69 -msgid "Excluding groups" -msgstr "グループの除外" - -#: ../../rst/inventory_guide/intro_patterns.rst:69 -msgid "webservers:!atlanta" -msgstr "webservers:!atlanta" - -#: ../../rst/inventory_guide/intro_patterns.rst:69 -msgid "all hosts in webservers except those in atlanta" -msgstr "atlanta 上のホストを除く webservers のすべてのホスト" - -#: ../../rst/inventory_guide/intro_patterns.rst:71 -msgid "Intersection of groups" -msgstr "グループの交差部分" - -#: ../../rst/inventory_guide/intro_patterns.rst:71 -msgid "webservers:&staging" -msgstr "webservers:&staging" - -#: ../../rst/inventory_guide/intro_patterns.rst:71 -msgid "any hosts in webservers that are also in staging" -msgstr "ステージ状態にある webservers のすべてのホスト" - -#: ../../rst/inventory_guide/intro_patterns.rst:74 -msgid "You can use either a comma (``,``) or a colon (``:``) to separate a list of hosts. The comma is preferred when dealing with ranges and IPv6 addresses." -msgstr "ホストのリストを分離するには、コンマ (``,``) またはコロン (``:``) のいずれかを使用できます。コンマは、範囲および IPv6 アドレスを処理する場合に推奨されます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:76 -msgid "Once you know the basic patterns, you can combine them. This example:" -msgstr "基本的なパターンを把握したら、それを組み合わせることができます。以下に例を示します。" - -#: ../../rst/inventory_guide/intro_patterns.rst:82 -msgid "targets all machines in the groups 'webservers' and 'dbservers' that are also in the group 'staging', except any machines in the group 'phoenix'." -msgstr "「phoenix」グループのマシンを除き、「staging」グループにある「webservers」グループおよび「dbservers」グループにあるすべてのマシンを対象とします。" - -#: ../../rst/inventory_guide/intro_patterns.rst:85 -msgid "You can use wildcard patterns with FQDNs or IP addresses, as long as the hosts are named in your inventory by FQDN or IP address:" -msgstr "ホストがインベントリーで FQDN または IP アドレスにより名前が付けられている限り、FQDN または IP アドレスでワイルドカードパターンを使用できます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:93 -msgid "You can mix wildcard patterns and groups at the same time:" -msgstr "ワイルドカードパターンおよびグループを同時に組み合わせることができます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:100 -msgid "Limitations of patterns" -msgstr "パターンの制限" - -#: ../../rst/inventory_guide/intro_patterns.rst:102 -msgid "Patterns depend on inventory. If a host or group is not listed in your inventory, you cannot use a pattern to target it. If your pattern includes an IP address or hostname that does not appear in your inventory, you will see an error like this:" -msgstr "パターンはインベントリーによって異なります。ホストまたはグループがインベントリーに記載されていない場合は、ターゲットにパターンを使用することはできません。インベントリーに表示されない IP アドレスまたはホスト名がパターンに含まれている場合は、以下のようなエラーが表示されます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:109 -msgid "Your pattern must match your inventory syntax. If you define a host as an :ref:`alias`:" -msgstr "お使いのパターンはインベントリー構文に一致する必要があります。ホストを :ref:`エイリアス` として定義する場合は、以下を指定します。" - -#: ../../rst/inventory_guide/intro_patterns.rst:119 -msgid "you must use the alias in your pattern. In the example above, you must use ``host1`` in your pattern. If you use the IP address, you will once again get the error:" -msgstr "パターンでエイリアスを使用する必要があります。上記の例では、パターンで ``host1`` を使用する必要があります。IP アドレスを使用する場合は、エラーが再度表示されます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:126 -msgid "Pattern processing order" -msgstr "パターン処理の順序" - -#: ../../rst/inventory_guide/intro_patterns.rst:128 -msgid "The processing is a bit special and happens in the following order:" -msgstr "処理は少し特殊で、以下の順序で行われます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:130 -msgid "``:`` and ``,``" -msgstr "``:`` および ``,``" - -#: ../../rst/inventory_guide/intro_patterns.rst:131 -msgid "``&``" -msgstr "``&``" - -#: ../../rst/inventory_guide/intro_patterns.rst:132 -msgid "``!``" -msgstr "``!``" - -#: ../../rst/inventory_guide/intro_patterns.rst:134 -msgid "This positioning only accounts for processing order inside each operation: ``a:b:&c:!d:!e == &c:a:!d:b:!e == !d:a:!e:&c:b``" -msgstr "この配置は、``a:b:&c:!d:!e == &c:a:!d:b:!e == !d:a:!e:&c:b`` などのように、各操作内の処理順序のみを考慮しています。" - -#: ../../rst/inventory_guide/intro_patterns.rst:137 -msgid "All of these result in the following:" -msgstr "これらすべては、以下のようになります。" - -#: ../../rst/inventory_guide/intro_patterns.rst:139 -msgid "Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(d, e)." -msgstr "Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(d, e)." - -#: ../../rst/inventory_guide/intro_patterns.rst:141 -msgid "Now ``a:b:!e:!d:&c`` is a slight change as the ``!e`` gets processed before the ``!d``, though this doesn't make much of a difference:" -msgstr "``!e`` が ``!d`` より前に処理されるようになり、``a:b:!e:!d:&c`` は少し変化しましたが、これは特に大きな違いはありません。" - -#: ../../rst/inventory_guide/intro_patterns.rst:143 -msgid "Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(e, d)." -msgstr "Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(e, d)." - -#: ../../rst/inventory_guide/intro_patterns.rst:146 -msgid "Advanced pattern options" -msgstr "詳細なパターンオプション" - -#: ../../rst/inventory_guide/intro_patterns.rst:148 -msgid "The common patterns described above will meet most of your needs, but Ansible offers several other ways to define the hosts and groups you want to target." -msgstr "上記の一般的なパターンはほとんどのニーズに対応しますが、Ansible では、対象とするホストおよびグループを定義する他の方法もいくつか提供します。" - -#: ../../rst/inventory_guide/intro_patterns.rst:151 -msgid "Using variables in patterns" -msgstr "パターンにおける変数の使用" - -#: ../../rst/inventory_guide/intro_patterns.rst:153 -msgid "You can use variables to enable passing group specifiers via the ``-e`` argument to ansible-playbook:" -msgstr "変数を使うと、ansible-playbook の ``-e`` 引数でグループ指定子を渡せるようになります。" - -#: ../../rst/inventory_guide/intro_patterns.rst:160 -msgid "Using group position in patterns" -msgstr "パターンにおけるグループの位置の使用" - -#: ../../rst/inventory_guide/intro_patterns.rst:162 -msgid "You can define a host or subset of hosts by its position in a group. For example, given the following group:" -msgstr "グループ内の位置によって、ホストやホストのサブセットを定義することができます。たとえば、次のようなグループが指定された場合です。" - -#: ../../rst/inventory_guide/intro_patterns.rst:171 -msgid "you can use subscripts to select individual hosts or ranges within the webservers group:" -msgstr "subscripts を使用して、webservers グループ内のホストまたは範囲を個別に選択できます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:183 -msgid "Using regexes in patterns" -msgstr "パターンで正規表現の使用" - -#: ../../rst/inventory_guide/intro_patterns.rst:185 -msgid "You can specify a pattern as a regular expression by starting the pattern with ``~``:" -msgstr "パターンを正規表現として指定するには、``~`` でパターンを開始します。" - -#: ../../rst/inventory_guide/intro_patterns.rst:192 -msgid "Patterns and ad-hoc commands" -msgstr "パターンおよびアドホックコマンド" - -#: ../../rst/inventory_guide/intro_patterns.rst:194 -msgid "You can change the behavior of the patterns defined in ad-hoc commands using command-line options. You can also limit the hosts you target on a particular run with the ``--limit`` flag." -msgstr "コマンドラインオプションを使用して、アドホックコマンドで定義されたパターンの動作を変更できます。また、``--limit`` フラグを使用して、特定の実行で対象とするホストを制限することもできます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:197 -msgid "Limit to one host" -msgstr "1 台のホストに制限する" - -#: ../../rst/inventory_guide/intro_patterns.rst:203 -msgid "Limit to multiple hosts" -msgstr "複数のホストに制限する" - -#: ../../rst/inventory_guide/intro_patterns.rst:209 -msgid "Negated limit. Note that single quotes MUST be used to prevent bash interpolation." -msgstr "否定的な制限。bash の補間を防ぐために、一重引用符を使用する必要があります。" - -#: ../../rst/inventory_guide/intro_patterns.rst:215 -msgid "Limit to host group" -msgstr "ホストグループに制限する" - -#: ../../rst/inventory_guide/intro_patterns.rst:222 -msgid "Patterns and ansible-playbook flags" -msgstr "パターンおよび ansible-playbook フラグ" - -#: ../../rst/inventory_guide/intro_patterns.rst:224 -msgid "You can change the behavior of the patterns defined in playbooks using command-line options. For example, you can run a playbook that defines ``hosts: all`` on a single host by specifying ``-i 127.0.0.2,`` (note the trailing comma). This works even if the host you target is not defined in your inventory, but this method will NOT read your inventory for variables tied to this host and any variables required by the playbook will need to be specified manually at the command line. You can also limit the hosts you target on a particular run with the ``--limit`` flag, which will reference your inventory:" -msgstr "コマンドラインオプションを使用して Playbook で定義したパターンの動作を変更できます。たとえば、``-i 127.0.0.2,`` (末尾のコンマ) を指定して、単一のホストで ``hosts: all`` を定義する Playbook を実行することができます。これは、対象とするホストがインベントリーに定義されていない場合でも有効です。ただし、この手法ではこのホストに結び付けられた変数のインベントリーが読み取られず、Playbookが必要とするすべての変数をコマンドラインで手動で指定する必要があります。また、``--limit`` フラグを使用して、特定の実行で対象とするホストを制限することもできます。これにより、インベントリーが参照されます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:230 -msgid "Finally, you can use ``--limit`` to read the list of hosts from a file by prefixing the file name with ``@``:" -msgstr "最後に ``--limit`` を使用して、ファイル名の前に ``@`` を付けることで、ファイルからホストのリストを読み込むことができます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:236 -msgid "If :ref:`RETRY_FILES_ENABLED` is set to ``True``, a ``.retry`` file will be created after the ``ansible-playbook`` run containing a list of failed hosts from all plays. This file is overwritten each time ``ansible-playbook`` finishes running." -msgstr ":ref:`RETRY_FILES_ENABLED` が ``True`` に設定されている場合は、``ansible-playbook`` の実行後に、すべてのプレイで失敗したホストのリストを含む ``.retry`` ファイルが作成されます。このファイルは、``ansible-playbook`` の実行が終了するたびに上書きされます。" - -#: ../../rst/inventory_guide/intro_patterns.rst:242 -msgid "To apply your knowledge of patterns with Ansible commands and playbooks, read :ref:`intro_adhoc` and :ref:`playbooks_intro`." -msgstr "Ansible コマンドおよび Playbook でパターンに関する知識を活用するには、「:ref:`intro_adhoc`」および「:ref:`playbooks_intro`」を参照してください。" - -#: ../../rst/inventory_guide/intro_patterns.rst:249 -msgid "Learning the Ansible configuration management language" -msgstr "Ansible の設定管理言語について" - -#~ msgid "In Ansible 2.10 and later, inventory scripts moved to their associated collections. Many are now in the `community.general scripts/inventory directory `_. We recommend you use :ref:`inventory_plugins` instead." -#~ msgstr "Ansible 2.10 以降では、インベントリースクリプトは関連するコレクションに移動しました。現在、多くのスクリプトは `community.general scripts/inventory directory `_ にあります。代わりに :ref:`inventory_plugins` を使用することが推奨されます。" - -#~ msgid "To create parent/child relationships for groups: * in INI format, use the ``:children`` suffix * in YAML format, use the ``children:`` entry" -#~ msgstr "グループの親/子の関係を作成するには、 * INI 形式の場合には ``:children`` の接尾辞を、 * YAML 形式の場合は ``children:`` エントリーを使用します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/module_plugin_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/module_plugin_guide.po deleted file mode 100644 index 4d1495b65e4..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/module_plugin_guide.po +++ /dev/null @@ -1,289 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../rst/module_plugin_guide/index.rst:5 -msgid "Using Ansible modules and plugins" -msgstr "Ansible モジュールおよびプラグインの使用" - -#: ../../rst/module_plugin_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/module_plugin_guide/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/module_plugin_guide/index.rst:13 -msgid "Welcome to the Ansible guide for working with modules, plugins, and collections." -msgstr "モジュール、プラグイン、およびコレクションの Ansible 操作ガイドへようこそ。" - -#: ../../rst/module_plugin_guide/index.rst:15 -msgid "Ansible modules are units of code that can control system resources or execute system commands. Ansible provides a module library that you can execute directly on remote hosts or through playbooks. You can also write custom modules." -msgstr "Ansible モジュールは、システムリソースを制御したり、システムコマンドを実行したりできるコードの単位です。Ansible は、リモートホストまたは Playbook から直接実行できるモジュールライブラリーを提供します。カスタムモジュールを作成することもできます。" - -#: ../../rst/module_plugin_guide/index.rst:19 -msgid "Similar to modules are plugins, which are pieces of code that extend core Ansible functionality. Ansible uses a plugin architecture to enable a rich, flexible, and expandable feature set. Ansible ships with several plugins and lets you easily use your own plugins." -msgstr "モジュールに似ているのは、Ansible のコア機能を拡張するコードに含まれるプラグインです。Ansible は、プラグインアーキテクチャーを使用して、豊富で柔軟で拡張可能な機能セットを有効にします。Ansible にはいくつかのプラグインが同梱されており、独自のプラグインを簡単に使用できます。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:4 -msgid "Introduction to modules" -msgstr "モジュールの概要" - -#: ../../rst/module_plugin_guide/modules_intro.rst:6 -msgid "Modules (also referred to as \"task plugins\" or \"library plugins\") are discrete units of code that can be used from the command line or in a playbook task. Ansible executes each module, usually on the remote managed node, and collects return values. In Ansible 2.10 and later, most modules are hosted in collections." -msgstr "モジュール (「タスクプラグイン」または「ライブラリープラグイン」とも呼ばれる) は、コマンドラインまたは Playbook タスクで使用可能なコードの個別単位です。Ansible は、各モジュールを実行し、通常のリモート管理ノードで実行し、戻り値を収集します。Ansible 2.10 以降では、ほとんどのモジュールはコレクションでホストされます。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:8 -msgid "You can execute modules from the command line." -msgstr "コマンドラインからモジュールを実行できます。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:16 -msgid "Each module supports taking arguments. Nearly all modules take ``key=value`` arguments, space delimited. Some modules take no arguments, and the command/shell modules simply take the string of the command you want to run." -msgstr "各モジュールは、引数を取ることをサポートしています。ほぼすべてのモジュールは、スペースで区切られた ``key=value`` の引数を取ります。一部のモジュールは引数を取らず、コマンド/シェルモジュールは単に実行したいコマンドの文字列を取ります。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:18 -msgid "From playbooks, Ansible modules are executed in a very similar way." -msgstr "Playbook から、Ansible モジュールは同じような方法で実行されます。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:25 -msgid "Another way to pass arguments to a module is using YAML syntax, also called 'complex args'." -msgstr "もしくは、「complex args」とも呼ばれる YAML 構文を使用して、モジュールに引数を渡します。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:34 -msgid "All modules return JSON format data. This means modules can be written in any programming language. Modules should be idempotent, and should avoid making any changes if they detect that the current state matches the desired final state. When used in an Ansible playbook, modules can trigger 'change events' in the form of notifying :ref:`handlers ` to run additional tasks." -msgstr "すべてのモジュールは JSON 形式のデータを返します。これは、どのプログラミング言語でもモジュールを作成できます。モジュールは冪等であり、現在の状態が必要な最終状態と一致することを検知すると、変更は回避する必要があります。Ansible Playbook で使用すると、モジュールは :ref:`handlers ` に通知する形式で「変更イベント」をトリガーして追加のタスクを実行できます。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:36 -msgid "You can access the documentation for each module from the command line with the ansible-doc tool." -msgstr "各モジュールのドキュメントは、ansible-doc ツールを使用してコマンドラインからアクセスできます。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:42 -msgid "For a list of all available modules, see the :ref:`Collection docs `, or run the following at a command prompt." -msgstr "利用可能なモジュールの一覧は、「:ref:`Collection docs `」を参照してください。または、コマンドプロンプトで次のコマンドを実行します。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:51 -#: ../../rst/module_plugin_guide/modules_support.rst:63 -msgid ":ref:`intro_adhoc`" -msgstr ":ref:`intro_adhoc`" - -#: ../../rst/module_plugin_guide/modules_intro.rst:52 -#: ../../rst/module_plugin_guide/modules_support.rst:64 -msgid "Examples of using modules in /usr/bin/ansible" -msgstr "/usr/bin/ansible におけるモジュールの使用例" - -#: ../../rst/module_plugin_guide/modules_intro.rst:53 -#: ../../rst/module_plugin_guide/modules_support.rst:65 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/module_plugin_guide/modules_intro.rst:54 -#: ../../rst/module_plugin_guide/modules_support.rst:66 -msgid "Examples of using modules with /usr/bin/ansible-playbook" -msgstr "/usr/bin/ansible-playbook でモジュールを使用する例" - -#: ../../rst/module_plugin_guide/modules_intro.rst:55 -msgid ":ref:`developing_modules`" -msgstr ":ref:`developing_modules`" - -#: ../../rst/module_plugin_guide/modules_intro.rst:56 -msgid "How to write your own modules" -msgstr "独自のモジュールの作成方法" - -#: ../../rst/module_plugin_guide/modules_intro.rst:57 -msgid ":ref:`developing_api`" -msgstr ":ref:`developing_api`" - -#: ../../rst/module_plugin_guide/modules_intro.rst:58 -msgid "Examples of using modules with the Python API" -msgstr "Python API でモジュールを使用する例" - -#: ../../rst/module_plugin_guide/modules_intro.rst:59 -#: ../../rst/module_plugin_guide/modules_support.rst:67 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/module_plugin_guide/modules_intro.rst:60 -#: ../../rst/module_plugin_guide/modules_support.rst:68 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/module_plugin_guide/modules_intro.rst:61 -#: ../../rst/module_plugin_guide/modules_support.rst:69 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/module_plugin_guide/modules_intro.rst:62 -#: ../../rst/module_plugin_guide/modules_support.rst:70 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/module_plugin_guide/modules_plugins_index.rst:4 -msgid "Modules and plugins index" -msgstr "モジュールおよびプラグインのインデックス" - -#: ../../rst/module_plugin_guide/modules_plugins_index.rst:6 -msgid "You can find an index of modules and plugins at :ref:`all_modules_and_plugins`." -msgstr "モジュールおよびプラグインのインデックスは :ref:`all_modules_and_plugins` にあります。" - -#: ../../rst/module_plugin_guide/modules_support.rst:5 -msgid "Module maintenance and support" -msgstr "モジュールメンテナンスとサポート" - -#: ../../rst/module_plugin_guide/modules_support.rst:7 -msgid "If you are using a module and you discover a bug, you may want to know where to report that bug, who is responsible for fixing it, and how you can track changes to the module. If you are a Red Hat subscriber, you may want to know whether you can get support for the issue you are facing." -msgstr "モジュールを使用し、バグを発見した場合は、そのバグの報告場所、修正を行う担当者、およびモジュールへの変更を追跡する方法を把握することが推奨されます。Red Hat のサブスクリプションをお持ちの場合は、アクセスする問題のサポートを取得できるかどうかを認識できます。" - -#: ../../rst/module_plugin_guide/modules_support.rst:9 -msgid "Starting in Ansible 2.10, most modules live in collections. The distribution method for each collection reflects the maintenance and support for the modules in that collection." -msgstr "Ansible 2.10 以降、ほとんどのモジュールはコレクションに存在します。各コレクションのディストリビューション方法は、そのコレクションのモジュールに対するメンテナンスとサポートを反映しています。" - -#: ../../rst/module_plugin_guide/modules_support.rst:15 -msgid "Maintenance" -msgstr "メンテナンス" - -#: ../../rst/module_plugin_guide/modules_support.rst:21 -msgid "Collection" -msgstr "コレクション" - -#: ../../rst/module_plugin_guide/modules_support.rst:21 -msgid "Code location" -msgstr "コードの場所" - -#: ../../rst/module_plugin_guide/modules_support.rst:21 -msgid "Maintained by" -msgstr "メンテナンス担当" - -#: ../../rst/module_plugin_guide/modules_support.rst:23 -msgid "ansible.builtin" -msgstr "ansible.builtin" - -#: ../../rst/module_plugin_guide/modules_support.rst:23 -msgid "`ansible/ansible repo`_ on GitHub" -msgstr "GitHub の `ansible/ansible repo`_" - -#: ../../rst/module_plugin_guide/modules_support.rst:23 -msgid "core team" -msgstr "core チーム" - -#: ../../rst/module_plugin_guide/modules_support.rst:25 -msgid "distributed on Galaxy" -msgstr "Galaxy への配布" - -#: ../../rst/module_plugin_guide/modules_support.rst:25 -#: ../../rst/module_plugin_guide/modules_support.rst:27 -msgid "various; follow ``repo`` link" -msgstr "さまざま。``repo`` リンクに従ってください。" - -#: ../../rst/module_plugin_guide/modules_support.rst:25 -msgid "community or partners" -msgstr "コミュニティーまたはパートナー" - -#: ../../rst/module_plugin_guide/modules_support.rst:27 -msgid "distributed on Automation Hub" -msgstr "Automation Hub への配布" - -#: ../../rst/module_plugin_guide/modules_support.rst:27 -msgid "content team or partners" -msgstr "コンテンツチームまたはパートナー" - -#: ../../rst/module_plugin_guide/modules_support.rst:33 -msgid "Issue Reporting" -msgstr "問題の報告" - -#: ../../rst/module_plugin_guide/modules_support.rst:35 -msgid "If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-core``:" -msgstr "Ansible メインリポジトリー (``ansible-core`` とも知られている) のプラグインに影響するバグを見つけた場合は、以下を行います。" - -#: ../../rst/module_plugin_guide/modules_support.rst:37 -msgid "Confirm that you are running the latest stable version of Ansible or the devel branch." -msgstr "Ansible の最新の安定版または devel ブランチを実行していることを確認します。" - -#: ../../rst/module_plugin_guide/modules_support.rst:38 -msgid "Look at the `issue tracker in the Ansible repo `_ to see if an issue has already been filed." -msgstr "`Ansible リポジトリーの問題トラッカー `_ を確認して、問題がすでに報告されているかどうかを確認します。" - -#: ../../rst/module_plugin_guide/modules_support.rst:39 -#: ../../rst/module_plugin_guide/modules_support.rst:46 -msgid "Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered." -msgstr "問題が存在しない場合は、問題を作成してください。発見した動作について、できる限り詳細に記述してください。" - -#: ../../rst/module_plugin_guide/modules_support.rst:41 -msgid "If you find a bug that affects a plugin in a Galaxy collection:" -msgstr "Galaxy コレクションでプラグインに影響を与えるバグを見つけた場合は、以下を行います。" - -#: ../../rst/module_plugin_guide/modules_support.rst:43 -msgid "Find the collection on Galaxy." -msgstr "Galaxy のコレクションを見つけます。" - -#: ../../rst/module_plugin_guide/modules_support.rst:44 -msgid "Find the issue tracker for the collection." -msgstr "コレクションの問題トラッカーの検索" - -#: ../../rst/module_plugin_guide/modules_support.rst:45 -msgid "Look there to see if an issue has already been filed." -msgstr "問題がすでに報告されているかどうかを確認します。" - -#: ../../rst/module_plugin_guide/modules_support.rst:48 -msgid "Some partner collections may be hosted in private repositories." -msgstr "一部のパートナーコレクションは、プライベートリポジトリーでホストされる場合があります。" - -#: ../../rst/module_plugin_guide/modules_support.rst:50 -msgid "If you are not sure whether the behavior you see is a bug, if you have questions, if you want to discuss development-oriented topics, or if you just want to get in touch, use one of our Google mailing lists or chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) to :ref:`communicate with Ansiblers `." -msgstr "ご覧になった動作がバグなのかどうかわからない場合、質問がある場合、開発関連のトピックについて議論したい場合、または単に連絡を取りたい場合は、Google メーリングリストまたはチャットチャンネル (ansible.im の Matrix または `irc.libera.chat `_ の IRC を使用) のいずれかを使用して :ref:`Ansible のメンバーにご連絡ください ` ください。" - -#: ../../rst/module_plugin_guide/modules_support.rst:52 -msgid "If you find a bug that affects a module in an Automation Hub collection:" -msgstr "Automation Hub コレクションでモジュールに影響するバグを見つけた場合は、以下を行います。" - -#: ../../rst/module_plugin_guide/modules_support.rst:54 -msgid "If the collection offers an Issue Tracker link on Automation Hub, click there and open an issue on the collection repository. If it does not, follow the standard process for reporting issues on the `Red Hat Customer Portal `_. You must have a subscription to the Red Hat Ansible Automation Platform to create an issue on the portal." -msgstr "コレクションで Automation Hub 上の Issue Tracker リンクが提供されている場合、そこをクリックして、コレクションのリポジトリーに問題を作成します。指定していない場合は、`Red Hat カスタマーポータル `_ で問題を報告するための標準的なプロセスに従ってください。ポータルで問題を作成するには、Red Hat Ansible Automation Platform のサブスクリプションが必要です。" - -#: ../../rst/module_plugin_guide/modules_support.rst:57 -msgid "Support" -msgstr "サポート" - -#: ../../rst/module_plugin_guide/modules_support.rst:59 -msgid "All plugins that remain in ``ansible-core`` and all collections hosted in Automation Hub are supported by Red Hat. No other plugins or collections are supported by Red Hat. If you have a subscription to the Red Hat Ansible Automation Platform, you can find more information and resources on the `Red Hat Customer Portal. `_" -msgstr "``ansible-core`` にあるすべてのプラグインと、Automation Hub でホストされるすべてのプラグインは Red Hat によってサポートされます。その他のプラグインまたはコレクションは Red Hat ではサポートされません。Red Hat Ansible Automation Platform にサブスクリプションがある場合は、`Red Hat カスタマーポータル `_ に関する詳細情報とリソースを確認できます。" - -#: ../../rst/module_plugin_guide/plugin_filtering_config.rst:4 -msgid "Rejecting modules" -msgstr "モジュールの拒否" - -#: ../../rst/module_plugin_guide/plugin_filtering_config.rst:6 -msgid "If you want to avoid using certain modules, you can add them to a reject list to prevent Ansible from loading them. To reject plugins, create a yaml configuration file. The default location for this file is :file:`/etc/ansible/plugin_filters.yml`. You can select a different path for the reject list using the :ref:`PLUGIN_FILTERS_CFG` setting in the ``defaults`` section of your ansible.cfg. Here is an example reject list:" -msgstr "特定のモジュールの使用を回避したい場合は、そのモジュールを拒否リストに追加して、Ansible がそのモジュールを読み込まないようにすることができます。プラグインを拒否するには、yaml 設定ファイルを作成します。このファイルのデフォルトの場所は :file:`/etc/ansible/plugin_filters.yml` です。ansible.cfg の ``defaults`` セクションにある :ref:`PLUGIN_FILTERS_CFG` の設定を使用して、拒否リストの別のパスを選択できます。以下に拒否リストの例を示します。" - -#: ../../rst/module_plugin_guide/plugin_filtering_config.rst:18 -msgid "The file contains two fields:" -msgstr "このファイルには、2 つのフィールドが含まれています。" - -#: ../../rst/module_plugin_guide/plugin_filtering_config.rst:20 -msgid "A file version so that you can update the format while keeping backwards compatibility in the future. The present version should be the string, ``\"1.0\"``" -msgstr "将来的に後方互換性を保ちながら形式を更新できるようにするファイルのバージョン。現在のバージョンは ``\"1.0\"`` 文字列とします。" - -#: ../../rst/module_plugin_guide/plugin_filtering_config.rst:22 -msgid "A list of modules to reject. Ansible will not load any module in this list when it searches for a module to invoke for a task." -msgstr "拒否するモジュールのリスト。Ansible は、モジュールを検索してタスクを呼び出すときに、このリストのモジュールを読み込みません。" - -#: ../../rst/module_plugin_guide/plugin_filtering_config.rst:26 -msgid "The ``stat`` module is required for Ansible to run. Do not add this module to your reject list." -msgstr "Ansible を実行するには、``stat`` モジュールが必要です。このモジュールを拒否リストに追加しないでください。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/network.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/network.po deleted file mode 100644 index 24f72d1067d..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/network.po +++ /dev/null @@ -1,5820 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2019 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:7 -msgid "Developing network plugins" -msgstr "ネットワークプラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:9 -msgid "You can extend the existing network modules with custom plugins in your collection." -msgstr "コレクションのカスタムプラグインを使用して、既存のネットワークモジュールを拡張できます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:15 -msgid "Network connection plugins" -msgstr "ネットワークの connection プラグイン" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:16 -msgid "Each network connection plugin has a set of its own plugins which provide a specification of the connection for a particular set of devices. The specific plugin used is selected at runtime based on the value of the ``ansible_network_os`` variable assigned to the host. This variable should be set to the same value as the name of the plugin to be loaded. Thus, ``ansible_network_os=nxos`` will try to load a plugin in a file named ``nxos.py``, so it is important to name the plugin in a way that will be sensible to users." -msgstr "各ネットワークの connection プラグインには、独自のプラグインセットがあります。これは、特定のデバイスセットの接続の仕様を提供します。使用される特定のプラグインは、ホストに割り当てられた ``ansible_network_os`` 変数の値に基づいてランタイム時に選択されます。この変数は、読み込むプラグインの名前と同じ値に設定する必要があります。そのため、``ansible_network_os=nxos`` は、``nxos.py`` という名前のファイルにプラグインを読み込もうとするため、ユーザーが適切な方法でプラグインに名前を付けることが重要です。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:23 -msgid "Public methods of these plugins may be called from a module or module_utils with the connection proxy object just as other connection methods can. The following is a very simple example of using such a call in a module_utils file so it may be shared with other modules." -msgstr "これらのプラグインのパブリックメソッドは、他の接続方法と同様に、接続のプロキシーオブジェクトを使用して、モジュールまたは module_utils から接続で呼び出すことができます。以下は、その他のモジュールと共有できるように、module_utils ファイルでこのような呼び出しを使用する非常に簡単な例です。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:45 -msgid "Developing httpapi plugins" -msgstr "httpapi プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:47 -msgid ":ref:`httpapi plugins ` serve as adapters for various HTTP(S) APIs for use with the ``httpapi`` connection plugin. They should implement a minimal set of convenience methods tailored to the API you are attempting to use." -msgstr ":ref:`httpapi プラグイン ` は、``httpapi`` connection プラグインで使用するさまざまな HTTP(S) API のアダプターとして機能します。このプラグインは、使用しようとしている API に適した最小限の便利なメソッドを実装する必要があります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:49 -msgid "Specifically, there are a few methods that the ``httpapi`` connection plugin expects to exist." -msgstr "具体的には、``httpapi`` connection プラグインが存在することが必要なメソッドがいくつかあります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:52 -msgid "Making requests" -msgstr "要求の作成" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:54 -msgid "The ``httpapi`` connection plugin has a ``send()`` method, but an httpapi plugin needs a ``send_request(self, data, **message_kwargs)`` method as a higher-level wrapper to ``send()``. This method should prepare requests by adding fixed values like common headers or URL root paths. This method may do more complex work such as turning data into formatted payloads, or determining which path or method to request. It may then also unpack responses to be more easily consumed by the caller." -msgstr "``httpapi`` connection プラグインには ``send()`` メソッドがありますが、httpapi プラグインには、``send()`` への高レベルラッパーとして ``send_request(self, data, **message_kwargs)`` メソッドが必要です。このメソッドは、共通ヘッダーや URL ルートパスなどの固定値を追加することで要求を準備する必要があります。このメソッドは、フォーマットされたペイロードへのデータの切り替えや、リクエスト用のパスやメソッドの特定など、より複雑な作業を行うことがあります。その後、呼び出し元によって簡単に消費される応答が展開される可能性があります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:74 -msgid "Authenticating" -msgstr "認証" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:76 -msgid "By default, all requests will authenticate with HTTP Basic authentication. If a request can return some kind of token to stand in place of HTTP Basic, the ``update_auth(self, response, response_text)`` method should be implemented to inspect responses for such tokens. If the token is meant to be included with the headers of each request, it is sufficient to return a dictionary which will be merged with the computed headers for each request. The default implementation of this method does exactly this for cookies. If the token is used in another way, say in a query string, you should instead save that token to an instance variable, where the ``send_request()`` method (above) can add it to each request" -msgstr "デフォルトでは、すべての要求は HTTP Basic 認証で認証されます。要求が HTTP Basic の代わりにある種のトークンを返す場合は、``update_auth(self, response, response_text)`` メソッドを実装して、このようなトークンの応答を検査する必要があります。トークンが各要求のヘッダーに含まれるように設計されている場合は、各要求に対して計算されたヘッダーとマージするディクショナリーを返すだけで十分です。このメソッドのデフォルト実装は Cookie に対して行われる方法で行われます。トークンが別の方法 (クエリー文字列など) で使用される場合は、そのトークンをインスタンス変数に保存して、``send_request()`` メソッド (上記) により各要求に追加できるようにします。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:87 -msgid "If instead an explicit login endpoint needs to be requested to receive an authentication token, the ``login(self, username, password)`` method can be implemented to call that endpoint. If implemented, this method will be called once before requesting any other resources of the server. By default, it will also be attempted once when a HTTP 401 is returned from a request." -msgstr "代わりに明示的なログインエンドポイントを要求して認証トークンを受け取る必要がある場合は、``login(self, username, password)`` メソッドを実装して、そのエンドポイントを呼び出すことができます。このメソッドを実装すると、サーバーの他のリソースを要求する前にこのメソッドが一度呼び出されます。デフォルトでは、要求から HTTP 401 が返されるとこれが一度試行されます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:105 -msgid "Similarly, ``logout(self)`` can be implemented to call an endpoint to invalidate and/or release the current token, if such an endpoint exists. This will be automatically called when the connection is closed (and, by extension, when reset)." -msgstr "同様に、``logout(self)`` を実装してエンドポイントを呼び出し、そのエンドポイントが存在する場合は現在のトークンを無効化または解放できます。これは、接続を閉じると自動的に呼び出されます (また、リセット時には拡張により呼び出されます)。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:117 -msgid "Error handling" -msgstr "エラー処理" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:119 -msgid "The ``handle_httperror(self, exception)`` method can deal with status codes returned by the server. The return value indicates how the plugin will continue with the request:" -msgstr "``handle_httperror(self, exception)`` メソッドは、サーバーによって返されるステータスコードを処理できます。戻り値は、プラグインがどのようにリクエストを続けるかを示します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:121 -msgid "A value of ``true`` means that the request can be retried. This my be used to indicate a transient error, or one that has been resolved. For example, the default implementation will try to call ``login()`` when presented with a 401, and return ``true`` if successful." -msgstr "``true`` の値は、要求を再試行できることを意味します。これは、一時的なエラーや解決されたエラーを示すために使用できます。たとえば、デフォルトの実装では、401 が示されると ``login()`` の呼び出しが試行され、成功した場合は ``true`` が返されます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:123 -msgid "A value of ``false`` means that the plugin is unable to recover from this response. The status code will be raised as an exception to the calling module." -msgstr "``false`` の値は、プラグインがこの応答から復元できないことを意味します。ステータスコードは、呼び出したモジュールに例外としてあげられます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:125 -msgid "Any other value will be taken as a nonfatal response from the request. This may be useful if the server returns error messages in the body of the response. Returning the original exception is usually sufficient in this case, as HTTPError objects have the same interface as a successful response." -msgstr "その他の値は、要求からの致命的でない応答として取られます。これは、サーバーが応答のボディーでエラーメッセージを返す場合に便利です。HTTPError オブジェクトは正常な応答と同じインターフェースを持つため、通常は元の例外を返します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:127 -msgid "For example httpapi plugins, see the `source code for the httpapi plugins `_ included with Ansible Core." -msgstr "httpapi プラグインの例は、Ansible Core に含まれる `httpapi プラグインのソースコード `_ を参照してください。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:132 -msgid "Developing NETCONF plugins" -msgstr "NETCONF プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:134 -msgid "The :ref:`netconf ` connection plugin provides a connection to remote devices over the ``SSH NETCONF`` subsystem. Network devices typically use this connection plugin to send and receive ``RPC`` calls over ``NETCONF``." -msgstr ":ref:`netconf ` connection プラグインは、``SSH NETCONF`` サブシステム経由でリモートデバイスへの接続を提供します。ネットワークデバイスは通常、この connection プラグインを使用して、``NETCONF`` で ``RPC`` 呼び出しを送受信します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:136 -msgid "The ``netconf`` connection plugin uses the ``ncclient`` Python library under the hood to initiate a NETCONF session with a NETCONF-enabled remote network device. ``ncclient`` also executes NETCONF RPC requests and receives responses. You must install the ``ncclient`` on the local Ansible controller." -msgstr "``netconf`` connection プラグインは、Python ライブラリー ``ncclient`` を使用して、NETCONF が有効なリモートネットワークデバイスで NETCONF セッションを開始します。また、``ncclient`` は NETCONF RPC 要求を実行し、応答を受け取ります。ローカルの Ansible コントローラーに ``ncclient`` をインストールする必要があります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:138 -msgid "To use the ``netconf`` connection plugin for network devices that support standard NETCONF (:RFC:`6241`) operations such as ``get``, ``get-config``, ``edit-config``, set ``ansible_network_os=default``. You can use :ref:`netconf_get `, :ref:`netconf_config ` and :ref:`netconf_rpc ` modules to talk to a NETCONF enabled remote host." -msgstr "``get``、``get-config``、``edit-config`` などの標準 NETCONF (:RFC:`6241`) 操作に対応するネットワークデバイスの ``netconf`` connection プラグインを使用するには、``ansible_network_os=default`` を設定します。:ref:`netconf_get ` モジュール、:ref:`netconf_config ` モジュール、および :ref:`netconf_rpc ` モジュールを使用して、NETCONF が有効なリモートホストと通信できます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:141 -msgid "As a contributor and user, you should be able to use all the methods under the ``NetconfBase`` class if your device supports standard NETCONF. You can contribute a new plugin if the device you are working with has a vendor specific NETCONF RPC. To support a vendor specific NETCONF RPC, add the implementation in the network OS specific NETCONF plugin." -msgstr "デバイスが標準の NETCONF に対応している場合は、貢献者およびユーザーとして、``NetconfBase`` クラスのすべてのメソッドを使用できるようにする必要があります。作業しているデバイスにベンダー固有の NETCONF RPC がある場合は、新しいプラグインを提供できます。ベンダー固有の NETCONF RPC に対応するには、ネットワーク OS 固有の NETCONF プラグインに実装を追加します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:144 -msgid "For Junos for example:" -msgstr "たとえば、Junios の場合は以下のようになります。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:146 -msgid "See the vendor-specific Junos RPC methods implemented in ``plugins/netconf/junos.py``." -msgstr "``plugins/netconf/junos.py`` に実装されるベンダー固有の Junos RPC メソッドを参照してください。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:147 -msgid "Set the value of ``ansible_network_os`` to the name of the netconf plugin file, that is ``junos`` in this case." -msgstr "``ansible_network_os`` の値を netconf プラグインファイルの名前 (ここでは ``junos``) に設定します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:152 -msgid "Developing network_cli plugins" -msgstr "network_cli プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:154 -msgid "The :ref:`network_cli ` connection type uses ``paramiko_ssh`` under the hood which creates a pseudo terminal to send commands and receive responses. ``network_cli`` loads two platform specific plugins based on the value of ``ansible_network_os``:" -msgstr "接続タイプ :ref:`network_cli ` は、コマンドを送信して応答を受け取るための疑似端末を作成するフード (hood) の下で、``paramiko_ssh`` を使用します。``network_cli`` は、``ansible_network_os`` の値に基づいて 2 つのプラットフォーム固有のプラグインを読み込みます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:157 -msgid "Terminal plugin (for example ``plugins/terminal/ios.py``) - Controls the parameters related to terminal, such as setting terminal length and width, page disabling and privilege escalation. Also defines regex to identify the command prompt and error prompts." -msgstr "端末のプラグイン (例: ``plugins/terminal/ios.py``) - 端末の長さや幅の設定、ページの無効化、権限の昇格など、端末に関連するパラメーターを制御します。また、正規表現を定義して、コマンドプロンプトおよびエラープロンプトを特定します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:159 -msgid ":ref:`cliconf_plugins` (for example, :ref:`ios cliconf `) - Provides an abstraction layer for low level send and receive operations. For example, the ``edit_config()`` method ensures that the prompt is in ``config`` mode before executing configuration commands." -msgstr ":ref:`cliconf_plugins` (例: :ref:`ios cliconf `) - 低レベルの送受信操作の抽象化レイヤーを提供します。たとえば、``edit_config()`` メソッドは、設定コマンドを実行する前にプロンプトが ``config`` モードになるようにします。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:161 -msgid "To contribute a new network operating system to work with the ``network_cli`` connection, implement the ``cliconf`` and ``terminal`` plugins for that network OS." -msgstr "新しいネットワークオペレーティングシステムが ``network_cli`` 接続と連携するようにするには、そのネットワーク OS の ``cliconf`` プラグインおよび ``terminal`` プラグインを実装します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:163 -msgid "The plugins can reside in:" -msgstr "このプラグインは以下の場所に置くことができます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:165 -msgid "Adjacent to playbook in folders" -msgstr "ディレクトリー内で Playbook に隣接" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:172 -#: ../../rst/shared_snippets/basic_concepts.txt:33 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:179 -#: ../../rst/shared_snippets/basic_concepts.txt:63 -msgid "Collections" -msgstr "コレクション" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:186 -msgid "The user can also set the :ref:`DEFAULT_CLICONF_PLUGIN_PATH` to configure the ``cliconf`` plugin path." -msgstr "``cliconf`` プラグインパスを設定するために、ユーザーは :ref:`DEFAULT_CLICONF_PLUGIN_PATH` を設定することもできます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:188 -msgid "After adding the ``cliconf`` and ``terminal`` plugins in the expected locations, users can:" -msgstr "予想される場所に ``cliconf`` プラグインおよび ``terminal`` プラグインを追加したら、ユーザーは以下を行うことができます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:190 -msgid "Use the :ref:`cli_command ` to run an arbitrary command on the network device." -msgstr ":ref:`cli_command ` を使用して、ネットワークデバイス上で任意のコマンドを実行します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:191 -msgid "Use the :ref:`cli_config ` to implement configuration changes on the remote hosts without platform-specific modules." -msgstr ":ref:`cli_config ` を使用して、プラットフォーム固有のモジュールを使用しないリモートホストに設定変更を実装する。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:197 -msgid "Developing cli_parser plugins in a collection" -msgstr "コレクションでの cli_parser プラグインの開発" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:199 -msgid "You can use ``cli_parse`` as an entry point for a cli_parser plugin in your own collection." -msgstr "``cli_parse`` は、独自のコレクションで cli_parser プラグインのエントリーポイントとして使用できます。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:202 -msgid "The following sample shows the start of a custom cli_parser plugin:" -msgstr "以下の例は、カスタム cli_parser プラグインの開始を示しています。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:245 -msgid "The following task uses this custom cli_parser plugin:" -msgstr "以下のタスクでは、このカスタム cli_parser プラグインを使用します。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:255 -msgid "To develop a custom plugin: - Each cli_parser plugin requires a ``CliParser`` class. - Each cli_parser plugin requires a ``parse`` function. - Always return a dictionary with ``errors`` or ``parsed``. - Place the custom cli_parser in plugins/cli_parsers directory of the collection. - See the `current cli_parsers `_ for examples to follow." -msgstr "カスタムプラグインを開発するには: - 各 cli_parser プラグインには ``CliParser`` クラスが必要です。- 各 cli_parser プラグインには ``parse`` 関数が必要です。- 常に ``errors`` または ``parsed`` でディクショナリーを返します。コレクションの plugins/cli_parsers ディレクトリーにカスタムの cli_parser を置きます。例は `現在の cli_parsers ` を参照してください。" - -#: ../../rst/network/dev_guide/developing_plugins_network.rst:265 -msgid ":ref:`cli_parsing`" -msgstr ":ref:`cli_parsing`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:6 -msgid "Developing network resource modules" -msgstr "ネットワークリソースモジュールの開発" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:13 -msgid "Understanding network and security resource modules" -msgstr "ネットワークおよびセキュリティーのリソースモジュールの概要" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:15 -msgid "Network and security devices separate configuration into sections (such as interfaces, VLANs, and so on) that apply to a network or security service. Ansible resource modules take advantage of this to allow users to configure subsections or resources within the device configuration. Resource modules provide a consistent experience across different network and security devices. For example, a network resource module may only update the configuration for a specific portion of the network interfaces, VLANs, ACLs, and so on for a network device. The resource module:" -msgstr "ネットワークデバイスおよびセキュリティーデバイスは、その設定を、ネットワークサービスまたはセキュリティーサービスに適用されるセクション (インターフェース、VLAN など) に分割します。Ansible リソースモジュールはこれを利用して、ユーザーがデバイス設定でサブセクションやリソースを設定できるようにします。リソースモジュールは、異なるネットワークおよびセキュリティーデバイス全体で一貫したエクスペリエンスを提供します。たとえば、ネットワークリソースモジュールは、ネットワークインターフェース、VLAN、ACL などの特定の部分に対して設定を更新することができます。リソースモジュールは、以下を行います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:17 -msgid "Fetches a piece of the configuration (fact gathering), for example, the interfaces configuration." -msgstr "インターフェース設定など、設定の一部 (ファクト収集) を取得します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:18 -msgid "Converts the returned configuration into key-value pairs." -msgstr "返された設定をキーと値のペアに変換します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:19 -msgid "Places those key-value pairs into an internal independent structured data format." -msgstr "これらのキーと値のペアを内部に依存しない構造化データ形式に置きます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:21 -msgid "Now that the configuration data is normalized, the user can update and modify the data and then use the resource module to send the configuration data back to the device. This results in a full round-trip configuration update without the need for manual parsing, data manipulation, and data model management." -msgstr "設定データが正規化され、ユーザーはデータを更新して変更し、リソースモジュールを使用して設定データをデバイスに戻すことができます。これにより、手動の解析、データ操作、およびデータモデル管理を必要とせずに、完全なラウンドトリップ設定の更新が可能になります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:23 -msgid "The resource module has two top-level keys - ``config`` and ``state``:" -msgstr "リソースモジュールには、``config`` と ``state`` の 2 つのトップレベルキーがあります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:25 -msgid "``config`` defines the resource configuration data model as key-value pairs. The type of the ``config`` option can be ``dict`` or ``list of dict`` based on the resource managed. That is, if the device has a single global configuration, it should be a ``dict`` (for example, a global LLDP configuration). If the device has multiple instances of configuration, it should be of type ``list`` with each element in the list of type ``dict`` (for example, interfaces configuration)." -msgstr "``config`` は、リソース設定のデータモデルをキーと値のペアとして定義します。``config`` オプションのタイプは、管理されるリソースに基づいて ``dict`` または ``list of dict`` になります。つまり、デバイスにグローバル設定が 1 つある場合には、``dict`` でなければなりません (例: グローバル LLDP 設定)。デバイスに複数の設定インスタンスがある場合は、タイプが ``list`` となり、リストの各要素はタイプが ``dict`` である必要があります (例: インターフェース設定)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:28 -msgid "``state`` defines the action the resource module takes on the end device." -msgstr "``state`` リソースモジュールがエンドデバイスで使用するアクションを定義します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:30 -msgid "The ``state`` for a new resource module should support the following values (as applicable for the devices that support them):" -msgstr "新しいリソースモジュールの ``state`` は、以下の値をサポートする必要があります (サポートするデバイスに該当する場合)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:33 -#: ../../rst/network/user_guide/network_resource_modules.rst:19 -msgid "merged" -msgstr "merged" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:33 -#: ../../rst/network/user_guide/network_resource_modules.rst:19 -msgid "Ansible merges the on-device configuration with the provided configuration in the task." -msgstr "Ansible は、デバイス上の設定をタスクに指定した設定と統合します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:36 -#: ../../rst/network/user_guide/network_resource_modules.rst:22 -msgid "replaced" -msgstr "replaced" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:36 -#: ../../rst/network/user_guide/network_resource_modules.rst:22 -msgid "Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task." -msgstr "Ansible が、デバイス上の設定のサブセクションを、タスクに指定した設定のサブセクションに置き換えます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:39 -#: ../../rst/network/user_guide/network_resource_modules.rst:25 -msgid "overridden" -msgstr "overridden" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:39 -#: ../../rst/network/user_guide/network_resource_modules.rst:25 -msgid "Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration)." -msgstr "Ansible は、リソースのデバイスの設定を、タスクで提供された設定を使用して上書きします。この状態では、デバイスへのアクセスが削除される可能性があるため、注意が必要です (たとえば、管理インターフェイスの設定を上書きするなど)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:42 -#: ../../rst/network/user_guide/network_resource_modules.rst:28 -msgid "deleted" -msgstr "deleted" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:42 -#: ../../rst/network/user_guide/network_resource_modules.rst:28 -msgid "Ansible deletes the on-device configuration subsection and restores any default settings." -msgstr "Ansible は、デバイス上の設定サブセクションを削除して、デフォルト設定を復元します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:45 -#: ../../rst/network/user_guide/network_resource_modules.rst:31 -msgid "gathered" -msgstr "gathered" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:45 -#: ../../rst/network/user_guide/network_resource_modules.rst:31 -msgid "Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result." -msgstr "Ansible は、ネットワークデバイスから収集したリソースの詳細を表示し、結果の ``gathered`` キーを使用してアクセスします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:48 -#: ../../rst/network/user_guide/network_resource_modules.rst:34 -msgid "rendered" -msgstr "rendered" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:48 -#: ../../rst/network/user_guide/network_resource_modules.rst:34 -msgid "Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline." -msgstr "Ansible は、デバイスネイティブの形式でタスク内の提供された設定をレンダリングします (例: Cisco IOS CLI)。Ansible は、結果内の ``rendered`` キーでレンダリングされた設定を返します。この状態はネットワークデバイスと通信せず、オフラインで使用できる点に注意してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:52 -#: ../../rst/network/user_guide/network_resource_modules.rst:37 -msgid "parsed" -msgstr "parsed" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:51 -msgid "Ansible parses the configuration from the ``running_configuration`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline." -msgstr "Ansible は、``running_configuration`` オプションから、その結果内の ``parsed`` キーの Ansible 構造化データに設定を解析します。この設定は、ネットワークデバイスから設定が収集されないため、この状態をオフラインで使用できる点に注意してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:54 -msgid "Modules in Ansible-maintained collections must support these state values. If you develop a module with only \"present\" and \"absent\" for state, you may submit it to a community collection." -msgstr "Ansible が管理しているコレクションのモジュールは、これらの状態値をサポートする必要があります。状態が「present」および「absent」のモジュールを開発した場合は、コミュニティーコレクションに提出することができます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:58 -msgid "The states ``rendered``, ``gathered``, and ``parsed`` do not perform any change on the device." -msgstr "状態 ``rendered``、``gathered``、および ``parsed`` はデバイス上で変更を行いません。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:62 -msgid "`Deep Dive on VLANs Resource Modules for Network Automation `_" -msgstr "`Deep Dive on VLANs Resource Modules for Network Automation `_" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:63 -msgid "Walkthrough of how state values are implemented for VLANs." -msgstr "VLAN への状態値の実装方法のウォールスルー" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:67 -msgid "Developing network and security resource modules" -msgstr "ネットワークおよびセキュリティーのリソースモジュールの開発" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:69 -msgid "The Ansible Engineering team ensures the module design and code pattern within Ansible-maintained collections is uniform across resources and across platforms to give a vendor-independent feel and deliver good quality code. We recommend you use the `resource module builder `_ to develop a resource module." -msgstr "Ansible Engineering チームは、Ansible が管理しているコレクション内のモジュール設計およびコードパターンがリソースやプラットフォーム全体で統一され、ベンダーに依存せず、適切な品質コードを提供します。`resource module builder `_ を使用してリソースモジュールを開発することが推奨されます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:72 -msgid "The highlevel process for developing a resource module is:" -msgstr "リソースモジュール開発の主なプロセスは次のとおりです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:74 -msgid "Create and share a resource model design in the `resource module models repository `_ as a PR for review." -msgstr "レビュー用にプル要求として、`リソースモジュールモデルリポジトリー `_ でリソースモデルの設計を作成し、共有します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:75 -msgid "Download the latest version of the `resource module builder `_." -msgstr "最新バージョンの `リソースモジュールビルダー `_ をダウンロードします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:76 -msgid "Run the ``resource module builder`` to create a collection scaffold from your approved resource model." -msgstr "``リソースモジュールビルダー`` を実行して、承認されたリソースモデルからコレクションのスキャフォールディングを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:77 -msgid "Write the code to implement your resource module." -msgstr "コードを作成し、リソースモジュールを実装します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:78 -msgid "Develop integration and unit tests to verify your resource module." -msgstr "統合テストおよびユニットテストを開発して、リソースモジュールを確認します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:79 -msgid "Create a PR to the appropriate collection that you want to add your new resource module to. See :ref:`contributing_maintained_collections` for details on determining the correct collection for your module." -msgstr "新しいリソースモジュールを追加する適切なコレクションにプル要求を作成します。モジュールの正しいコレクションを判断する方法は「:ref:`contributing_maintained_collections`」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:83 -msgid "Understanding the model and resource module builder" -msgstr "モデルおよびリソースモジュールビルダーの理解" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:85 -msgid "The resource module builder is an Ansible Playbook that helps developers scaffold and maintain an Ansible resource module. It uses a model as the single source of truth for the module. This model is a ``yaml`` file that is used for the module DOCUMENTATION section and the argument spec." -msgstr "リソースモジュールビルダーは、開発者が Ansible リソースモジュールをスキャフォールディングし、維持できるようにする Ansible Playbook です。このモデルは、モジュールの信頼できる唯一のソースとして使用します。このモデルは、モジュールの DOCUMENTATION セクションおよび引数仕様に使用される ``yaml`` ファイルです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:87 -msgid "The resource module builder has the following capabilities:" -msgstr "リソースモジュールビルダーには以下の機能があります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:89 -msgid "Uses a defined model to scaffold a resource module directory layout and initial class files." -msgstr "定義されたモデルを使用して、リソースモジュールディレクトリーのレイアウトと初期クラスファイルをスキャフォールディングします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:90 -msgid "Scaffolds either an Ansible role or a collection." -msgstr "Ansible ロールまたはコレクションのいずれかをスキャフォールディングします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:91 -msgid "Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring." -msgstr "その後、リソースモジュールビルダーを使用すると、モジュールの arspec と、モジュールの docstring を含むファイルのみが置き換えられます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:92 -msgid "Allows you to store complex examples along side the model in the same directory." -msgstr "複雑なサンプルモデルと同じディレクトリーに保存できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:93 -msgid "Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed." -msgstr "モジュールの信頼できるソースとしてこのモデルを維持し、必要に応じてリソースモジュールビルダーを使用してソースファイルを更新します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:94 -msgid "Generates working sample modules for both ``_`` and ``_facts``." -msgstr "``_`` および ``_facts`` の両方に作業サンプルモジュールを生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:97 -msgid "Accessing the resource module builder" -msgstr "リソースモジュールビルダーへのアクセス" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:99 -msgid "To access the resource module builder:" -msgstr "リソースモジュールビルダーにアクセスするには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:101 -msgid "clone the github repository:" -msgstr "github リポジトリーのクローンを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:107 -msgid "Install the requirements:" -msgstr "要件をインストールします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:114 -msgid "Creating a model" -msgstr "モデルの作成" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:116 -msgid "You must create a model for your new resource. The model is the single source of truth for both the argspec and docstring, keeping them in sync. Once your model is approved, you can use the resource module builder to generate three items based on the model:" -msgstr "新しいリソースのモデルを作成する必要があります。モデルは、argspec と docstring の両方に対する信頼できる唯一のソースとなります。モデルが承認されると、リソースモジュールビルダーを使用して、このモデルに基づいて 3 つのアイテムを生成できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:118 -msgid "The scaffold for a new module" -msgstr "新しいモジュールのスキャフォールディング" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:119 -msgid "The argspec for the new module" -msgstr "新しいモジュールの argspec" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:120 -msgid "The docstring for the new module" -msgstr "新しいモジュールの docstring" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:122 -msgid "For any subsequent changes to the functionality, update the model first and use the resource module builder to update the module argspec and docstring." -msgstr "その後、機能に対する変更を行う場合は、最初にモデルを更新し、リソースモジュールビルダーを使用してモジュールの argspec および docstring を更新します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:124 -msgid "For example, the resource model builder includes the ``myos_interfaces.yml`` sample in the :file:`models` directory, as seen below:" -msgstr "たとえば、リソースモデルビルダーには、以下のように :file:`models` ディレクトリーに ``myos_interfaces.yml`` サンプルが含まれます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:196 -msgid "Notice that you should include examples for each of the states that the resource supports. The resource module builder also includes these in the sample model." -msgstr "リソースがサポートする各状態の例を含める必要があることに注意してください。リソースモジュールビルダーには、サンプルモデルにもこれらが含まれます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:198 -msgid "Share this model as a PR for review at `resource module models repository `_. You can also see more model examples at that location." -msgstr "このモデルは、`リソースモジュールモデルのリポジトリー `_ で確認するための PR として共有します。この場所でさらにモデルのサンプルを表示することもできます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:202 -msgid "Creating a collection scaffold from a resource model" -msgstr "リソースモデルからのコレクションのスキャフォールディングの作成" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:204 -msgid "To use the resource module builder to create a collection scaffold from your approved resource model:" -msgstr "リソースモジュールビルダーを使用して、認証されたリソースモデルからコレクションのスキャフォールディングを作成するには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:215 -msgid "Where the parameters are as follows:" -msgstr "パラメーターは以下のようになります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:217 -msgid "``rm_dest``: The directory where the resource module builder places the files and directories for the resource module and facts modules." -msgstr "``rm_dest``: リソースモジュールビルダーが、リソースモジュールおよびファクトモジュールのファイルおよびディレクトリーを置くディレクトリー。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:218 -msgid "``structure``: The directory layout type (role or collection)" -msgstr "``structure``: ディレクトリーレイアウトの種類 (ロールまたはコレクション)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:220 -msgid "``role``: Generate a role directory layout." -msgstr "``role``: ロールディレクトリーレイアウトを生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:221 -msgid "``collection``: Generate a collection directory layout." -msgstr "``collection``: コレクションディレクトリーのレイアウトを生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:223 -msgid "``collection_org``: The organization of the collection, required when `structure=collection`." -msgstr "``collection_org``: `structure=collection` の場合にコレクションの組織が必要です。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:224 -msgid "``collection_name``: The name of the collection, required when `structure=collection`." -msgstr "``collection_name``: `structure=collection` の場合に必要となるコレクションの名前です。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:225 -msgid "``model``: The path to the model file." -msgstr "``model``: モデルファイルへのパス。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:227 -msgid "To use the resource module builder to create a role scaffold:" -msgstr "リソースモジュールビルダーを使用してロールのスキャフォールディングを作成するには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:237 -msgid "Examples" -msgstr "例" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:240 -msgid "Collection directory layout" -msgstr "コレクションディレクトリーのレイアウト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:242 -msgid "This example shows the directory layout for the following:" -msgstr "この例では、以下のようなディレクトリーレイアウトを示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:244 -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:306 -msgid "``network_os``: myos" -msgstr "``network_os``: myos" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:245 -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:307 -msgid "``resource``: interfaces" -msgstr "``resource``: interfaces" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:302 -msgid "Role directory layout" -msgstr "ロールディレクトリーのレイアウト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:304 -msgid "This example displays the role directory layout for the following:" -msgstr "この例では、以下のロールのディレクトリーレイアウトを表示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:358 -msgid "Using the collection" -msgstr "コレクションの使用" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:360 -msgid "This example shows how to use the generated collection in a playbook:" -msgstr "以下の例は、生成されたコレクションを Playbook で使用する方法を示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:378 -msgid "Using the role" -msgstr "ロールの使用" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:380 -msgid "This example shows how to use the generated role in a playbook:" -msgstr "以下の例は、生成されたロールを Playbook で使用する方法を示しています。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:402 -msgid "Resource module structure and workflow" -msgstr "リソースモジュール構造およびワークフロー" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:404 -msgid "The resource module structure includes the following components:" -msgstr "リソースモジュール構造には、以下のコンポーネントが含まれます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:413 -msgid "Module" -msgstr "モジュール" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:407 -msgid "``library/_.py``." -msgstr "``library/_.py``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:408 -msgid "Imports the ``module_utils`` resource package and calls ``execute_module`` API:" -msgstr "``module_utils`` リソースパッケージをインポートし、``execute_module`` API を呼び出します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:417 -msgid "Module argspec" -msgstr "モジュールの argspec" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:416 -msgid "``module_utils//argspec//``." -msgstr "``module_utils//argspec//``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:417 -msgid "Argspec for the resource." -msgstr "リソースの argspec" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:423 -msgid "Facts" -msgstr "ファクト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:420 -msgid "``module_utils//facts//``." -msgstr "``module_utils//facts//``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:421 -msgid "Populate facts for the resource." -msgstr "リソースのファクトを入力します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:422 -msgid "Entry in ``module_utils//facts/facts.py`` for ``get_facts`` API to keep ``_facts`` module and facts gathered for the resource module in sync for every subset." -msgstr "すべてのサブセットに対して同期するリソースモジュール用に収集された ``_facts`` モジュールおよびファクトを保持する ``get_facts`` API の ``module_utils//facts/facts.py`` エントリー。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:423 -msgid "Entry of Resource subset in FACTS_RESOURCE_SUBSETS list in ``module_utils//facts/facts.py`` to make facts collection work." -msgstr "``module_utils//facts/facts.py`` の FACTS_RESOURCE_SUBSETS 一覧でリソースサブセットのエントリー。ファクトコレクションを機能させます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:430 -msgid "Module package in module_utils" -msgstr "module_utils のモジュールパッケージ" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:426 -msgid "``module_utils////``." -msgstr "``module_utils////``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:427 -msgid "Implement ``execute_module`` API that loads the configuration to device and generates the result with ``changed``, ``commands``, ``before`` and ``after`` keys." -msgstr "設定を読み込む ``execute_module`` API を実装し、``changed`` キー、``commands`` キー、``before`` キー、および ``after`` キーで結果を生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:428 -msgid "Call ``get_facts`` API that returns the ```` configuration facts or return the difference if the device has onbox diff support." -msgstr "```` 設定のファクトを返す ``get_facts`` API を呼び出すか、デバイスに onbox diff サポートがある場合はその相違点を返します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:429 -msgid "Compare facts gathered and given key-values if diff is not supported." -msgstr "diff がサポートされていない場合は、収集されるファクトと、指定されるキー/値を比較します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:430 -msgid "Generate final configuration." -msgstr "最後の設定を生成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:434 -msgid "Utils" -msgstr "ユーティリティー" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:433 -msgid "``module_utils//utils``." -msgstr "``module_utils//utils``。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:434 -msgid "Utilities for the ```` platform." -msgstr "```` プラットフォームのユーティリティー。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:439 -msgid "Running ``ansible-test sanity`` and ``tox`` on resource modules" -msgstr "リソースモジュールでの ``ansible-test sanity`` および ``tox`` の実行" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:441 -msgid "You should run ``ansible-test sanity`` and ``tox -elinters`` from the collection root directory before pushing your PR to an Ansible-maintained collection. The CI runs both and will fail if these tests fail. See :ref:`developing_testing` for details on ``ansible-test sanity``." -msgstr "プル要求を Ansible で管理されたコレクションにプッシュする前に、コレクションルートディレクトリーから ``ansible-test sanity`` および ``tox -elinters`` を実行する必要があります。CI はその両方を実行し、このテストに失敗すると失敗します。``ansible-test sanity`` の詳細は、「:ref:`developing_testing`」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:443 -msgid "To install the necessary packages:" -msgstr "必要なパッケージをインストールするには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:445 -msgid "Ensure you have a valid Ansible development environment configured. See :ref:`environment_setup` for details." -msgstr "有効な Ansible 開発環境が設定されていることを確認してください。詳細は :ref:`environment_setup` を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:446 -msgid "Run ``pip install -r requirements.txt`` from the collection root directory." -msgstr "コレクションの root ディレクトリーから ``pip install -r requirements.txt`` を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:449 -msgid "Running ``tox -elinters``:" -msgstr "``tox -elinters`` の実行:" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:451 -msgid "Reads :file:`tox.ini` from the collection root directory and installs required dependencies (such as ``black`` and ``flake8``)." -msgstr "コレクションルートディレクトリーから :file:`tox.ini` を読み込み、必要な依存関係 (例: ``black``、``flake8``) をインストールします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:452 -msgid "Runs these with preconfigured options (such as line-length and ignores.)" -msgstr "事前設定されたオプション (line-length や ignore など) を指定して、これらのコマンドを実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:453 -msgid "Runs ``black`` in check mode to show which files will be formatted without actually formatting them." -msgstr "``black`` をチェックモードで実行し、実際にフォーマットされることなくどのファイルをフォーマットするかを表示します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:456 -msgid "Testing resource modules" -msgstr "リソースモジュールのテスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:458 -msgid "The tests rely on a role generated by the resource module builder. After changes to the resource module builder, the role should be regenerated and the tests modified and run as needed. To generate the role after changes:" -msgstr "テストは、リソースモジュールビルダーが生成したロールに依存します。リソースモジュールビルダーへの変更後に、ロールを再生成し、必要に応じてテストが変更され、実行される必要があります。変更後にロールを生成するには、以下を行います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:472 -msgid "Resource module integration tests" -msgstr "リソースモジュール統合テスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:474 -msgid "High-level integration test requirements for new resource modules are as follows:" -msgstr "新しいリソースモジュールのハイレベル統合テスト要件は次のとおりです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:476 -msgid "Write a test case for every state." -msgstr "すべての状態についてテストケースを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:477 -msgid "Write additional test cases to test the behavior of the module when an empty ``config.yaml`` is given." -msgstr "空の ``config.yaml`` が指定されている場合にモジュールの動作をテストするために、追加のテストケースを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:478 -msgid "Add a round trip test case. This involves a ``merge`` operation, followed by ``gather_facts``, a ``merge`` update with additional configuration, and then reverting back to the base configuration using the previously gathered facts with the ``state`` set to ``overridden``." -msgstr "ラウンドトリップテストケースを追加します。これには ``merge`` の操作が含まれ、続いて ``gather_facts`` 、``merge`` が追加の構成で更新され、その後、``state`` が ``overridden`` に設定された状態で、以前に収集したファクトを使用して基本構成に戻ります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:479 -msgid "Wherever applicable, assertions should check after and before ``dicts`` against a hard coded Source of Truth." -msgstr "該当する場合、アサーションは、ハードコードされた信頼できる唯一のソースに対して ``dicts`` の前後で確認する必要があります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:483 -msgid "We use Zuul as the CI to run the integration test." -msgstr "Zuul を CI として使用し、統合テストを実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:485 -msgid "To view the report, click :guilabel:`Details` on the CI comment in the PR" -msgstr "レポートを表示するには、プル要求の CI コメントにある :guilabel:`Details` をクリックします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:486 -msgid "To view a failure report, click :guilabel:`ansible/check` and select the failed test." -msgstr "障害レポートを表示するには、:guilabel:`ansible/check` をクリックし、失敗したテストを選択します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:487 -msgid "To view logs while the test is running, check for your PR number in the `Zuul status board `_." -msgstr "テストの実行中にログを表示するには、`Zuul status board `_ で プル要求番号を確認します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:488 -msgid "To fix static test failure locally, run the :command:`tox -e black` **inside the root folder of collection**." -msgstr "静的テストの失敗をローカルで修正するには、:command:`tox -e black` を、**コレクションのルートディレクトリー内** で実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:490 -msgid "To view The Ansible run logs and debug test failures:" -msgstr "Ansible の実行ログおよびデバッグテストの失敗を表示するには、以下を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:492 -msgid "Click the failed job to get the summary, and click :guilabel:`Logs` for the log." -msgstr "失敗したジョブをクリックしてサマリーを取得し、ログの :guilabel:`Logs` をクリックします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:493 -msgid "Click :guilabel:`console` and scroll down to find the failed test." -msgstr ":guilabel:`console` をクリックし、スクロールダウンして失敗したテストを見つけます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:494 -msgid "Click :guilabel:`>` next to the failed test for complete details." -msgstr "詳細は、失敗したテストの横にある :guilabel:`>` をクリックします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:498 -msgid "Integration test structure" -msgstr "統合テスト構造" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:500 -msgid "Each test case should generally follow this pattern:" -msgstr "通常、各テストケースは、以下のパターンに従います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:502 -msgid "setup —> test —> assert —> test again (for idempotency) —> assert —> tear down (if needed) -> done. This keeps test playbooks from becoming monolithic and difficult to troubleshoot." -msgstr "設定 —> テスト —> アサート —> 再テスト (冪等性) —> アサート —> 分解 (必要な場合) -> 完了。これにより、テスト Playbook がモノリシックになり、トラブルシューティングが困難になります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:503 -msgid "Include a name for each task that is not an assertion. You can add names to assertions as well, but it is easier to identify the broken task within a failed test if you add a name for each task." -msgstr "アサーションではない各タスクの名前を含めます。名前をアサーションに追加できますが、各タスクの名前を追加すると、失敗したテスト内では、破損したタスクを特定するのが容易になります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:504 -msgid "Files containing test cases must end in ``.yaml``" -msgstr "テストケースを含むファイルは ``.yaml`` で終了する必要があります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:507 -msgid "Implementation" -msgstr "実装" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:509 -msgid "For platforms that support ``connection: local`` *and* ``connection: network_cli`` use the following guidance:" -msgstr "``connection: local`` *および* ``connection: network_cli`` をサポートするプラットフォームについては、以下のガイダンスを使用します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:511 -msgid "Name the :file:`targets/` directories after the module name." -msgstr "モジュール名の後に :file:`targets/` ディレクトリーに名前を付けます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:512 -msgid "The :file:`main.yaml` file should just reference the transport." -msgstr ":file:`main.yaml` ファイルは、トランスポートを参照するだけです。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:514 -msgid "The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos `_ collection:" -msgstr "以下の例では、`vyos.vyos `_ コレクションの ``vyos.vyos.vyos_l3_interfaces`` モジュールの統合テストを行います。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:516 -msgid "``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml``" -msgstr "``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml``" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:525 -msgid "``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml``" -msgstr "``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml``" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:559 -msgid "``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml``" -msgstr "``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml``" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:627 -msgid "Detecting test resources at runtime" -msgstr "ランタイム時のテストリソースの検出" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:629 -msgid "Your tests should detect resources (such as interfaces) at runtime rather than hard-coding them into the test. This allows the test to run on a variety of systems." -msgstr "テストは、(インターフェースなどの) リソースをテストにハードコーディングするのではなく、ランタイム時にリソースを検出する必要があります。これにより、テストはさまざまなシステムで実行できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:631 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:209 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:268 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:304 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:333 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:364 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:413 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:623 -#: ../../rst/network/user_guide/network_working_with_command_output.rst:29 -msgid "For example:" -msgstr "例:" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:655 -msgid "See the complete test example of this at https://github.com/ansible-collections/cisco.nxos/blob/main/tests/integration/targets/prepare_nxos_tests/tasks/main.yml." -msgstr "https://github.com/ansible-collections/cisco.nxos/blob/main/tests/integration/targets/prepare_nxos_tests/tasks/main.yml. で、このテストの完全例を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:659 -msgid "Running network integration tests" -msgstr "ネットワーク統合テストの実行" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:661 -msgid "Ansible uses Zuul to run an integration test suite on every PR, including new tests introduced by that PR. To find and fix problems in network modules, run the network integration test locally before you submit a PR." -msgstr "Ansible は Zuul を使用して、すべてのプル要求で、プル要求によって導入された新規テストを含む統合テストスイートを実行します。ネットワークモジュールで問題を特定して修正するには、プル要求を送信する前にネットワーク統合テストをローカルで実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:664 -msgid "First, create an inventory file that points to your test machines. The inventory group should match the platform name (for example, ``eos``, ``ios``):" -msgstr "まず、テストマシンを参照するインベントリーファイルを作成します。インベントリーグループは、プラットフォーム名と一致する必要があります (例: ``eos``、``ios``)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:673 -msgid "To run these network integration tests, use ``ansible-test network-integration --inventory ``:" -msgstr "これらのネットワーク統合テストを実行するには、``ansible-test network-integration --inventory `` を使用します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:682 -msgid "To run all network tests for a particular platform:" -msgstr "特定のプラットフォームでネットワークテストをすべて実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:688 -msgid "This example will run against all ``vyos`` modules. Note that ``vyos_.*`` is a regex match, not a bash wildcard - include the `.` if you modify this example." -msgstr "この例は、すべての ``vyos`` モジュールに対して実行します。``vyos_.*`` は、bash ワイルドカードではなく、正規表現一致であることに注意してください。この例を修正する場合は `.` を含むようにしてください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:690 -msgid "To run integration tests for a specific module:" -msgstr "特定のモジュールに対して統合テストを実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:696 -msgid "To run a single test case on a specific module:" -msgstr "特定のモジュールでテストケースを 1 つ実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:703 -msgid "To run integration tests for a specific transport:" -msgstr "特定のトランスポートで統合テストを実行するには、次を実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:713 -msgid "See `test/integration/targets/nxos_bgp/tasks/main.yaml `_ for how this is implemented in the tests." -msgstr "テストに実装される方法は、「`test/integration/targets/nxos_bgp/tasks/main.yaml `_」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:715 -msgid "For more options:" -msgstr "その他のオプション:" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:721 -msgid "If you need additional help or feedback, reach out in the ``#ansible-network`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)." -msgstr "追加のサポートやフィードバックが必要な場合は、``#ansible-network`` チャットチャンネルから問い合わせしてください（ansible.im の表または `irc.libera.chat `_ の IRC を使用）。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:724 -msgid "Unit test requirements" -msgstr "ユニットテストの要件" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:726 -msgid "High-level unit test requirements that new resource modules should follow:" -msgstr "新しいリソースモジュールが従う高レベルのユニットテスト要件は以下のようになります。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:728 -msgid "Write test cases for all the states with all possible combinations of config values." -msgstr "設定値の組み合わせ可能なすべての状態についてテストケースを作成します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:729 -msgid "Write test cases to test the error conditions ( negative scenarios)." -msgstr "テストケースを作成し、エラー条件 (負のシナリオ) をテストします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:730 -msgid "Check the value of ``changed`` and ``commands`` keys in every test case." -msgstr "すべてのテストケースで ``changed`` キーおよび ``commands`` キーの値を確認します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:732 -msgid "We run all unit test cases on our Zuul test suite, on the latest python version supported by our CI setup." -msgstr "CI 設定でサポートされる最新の python バージョンで、Zuul テストスイートですべてのユニットテストケースを実行します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:734 -msgid "Use the :ref:`same procedure ` as the integration tests to view Zuul unit tests reports and logs." -msgstr ":ref:`同じ手順 ` を統合テストとして使用し、Zuul ユニットテストのレポートおよびログを表示します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:736 -msgid "See :ref:`unit module testing ` for general unit test details." -msgstr "一般的なユニットテストの詳細は、「:ref:`ユニットモジュールのテスト `」を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:742 -msgid "Example: Unit testing Ansible network resource modules" -msgstr "例: Ansible ネットワークリソースモジュールのユニットテスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:745 -msgid "This section walks through an example of how to develop unit tests for Ansible resource modules." -msgstr "本セクションでは、Ansible リソースモジュールのユニットテストを開発する方法の例を説明します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:748 -msgid "See :ref:`testing_units` and :ref:`testing_units_modules` for general documentation on Ansible unit tests for modules. Please read those pages first to understand unit tests and why and when you should use them." -msgstr "モジュール向けの Ansible ユニットテストの一般的なドキュメントは、「:ref:`testing_units`」および「:ref:`testing_units_modules`」を参照してください。ユニットテスト、および使用する理由およびその方法を理解するには、まずこれらのページをお読みください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:753 -msgid "Using mock objects to unit test Ansible network resource modules" -msgstr "モック (模擬) オブジェクトを使用した Ansible ネットワークリソースモジュールのユニットテスト" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:756 -msgid "`Mock objects `_ can be very useful in building unit tests for special or difficult cases, but they can also lead to complex and confusing coding situations. One good use for mocks would be to simulate an API. The ``mock`` Python package is bundled with Ansible (use ``import units.compat.mock``)." -msgstr "`モックオブジェクト `_ は、特殊なケースや難しいケースのユニットテストを構築するのに非常に便利ですが、複雑で理解しづらいコーディングになってしまうこともあります。モックの使用方法として適切なものの 1 つに、API のシミュレートがあります。``mock`` Python パッケージは、Ansible にバンドルされています (``import units.compat.mock`` を使用)。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:762 -msgid "You can mock the device connection and output from the device as follows:" -msgstr "以下のように、デバイスの接続とデバイスからの出力を模倣できます。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:796 -msgid "The facts file of the module now includes a new method, ``get_device_data``. Call ``get_device_data`` here to emulate the device output." -msgstr "モジュールのファクトファイルに新しいメソッド ``get_device_data`` が追加されました。ここで ``get_device_data`` を呼び出して、デバイスの出力をエミュレートします。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:800 -msgid "Mocking device data" -msgstr "デバイスデータの模倣" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:802 -msgid "To mock fetching results from devices or provide other complex data structures that come from external libraries, you can use ``fixtures`` to read in pre-generated data. The text files for this pre-generated data live in ``test/units/modules/network/PLATFORM/fixtures/``. See for example the `eos_l2_interfaces.cfg file `_." -msgstr "デバイスからの結果の取得や、外部ライブラリーからの複雑なデータ構造の提供を模倣するために、``fixtures`` を使用して事前に生成されたデータを読み込むことができます。この事前に生成されたデータのテキストファイルは、``test/units/modules/network/PLATFORM/fixtures/`` にあります。たとえば、`eos_l2_interfaces.cfg file `_ の例を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:805 -msgid "Load data using the ``load_fixture`` method and set this data as the return value of the ``get_device_data`` method in the facts file:" -msgstr "``load_fixture`` メソッドを使用してデータを読み込み、このデータをファクトファイルの ``get_device_data`` メソッドの戻り値として設定します。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:815 -msgid "See the unit test file `test_eos_l2_interfaces `_ for a practical example." -msgstr "実用的な例は、ユニットテストファイル `test_eos_l2_interfaces `_ を参照してください。" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:821 -msgid ":ref:`testing_units`" -msgstr ":ref:`testing_units`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:822 -msgid "Deep dive into developing unit tests for Ansible modules" -msgstr "Ansible モジュールのユニットテスト開発を深く掘り下げて調査" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:823 -msgid ":ref:`testing_running_locally`" -msgstr ":ref:`testing_running_locally`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:824 -msgid "Running tests locally including gathering and reporting coverage data" -msgstr "カバレージデータの収集とレポートを含む、ローカルでのテストの実行" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:825 -msgid ":ref:`developing_modules_general`" -msgstr ":ref:`developing_modules_general`" - -#: ../../rst/network/dev_guide/developing_resource_modules_network.rst:826 -msgid "Get started developing a module" -msgstr "モジュール開発を始める" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:6 -msgid "Documenting new network platforms" -msgstr "新しいネットワークプラットフォームのドキュメント化" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:11 -msgid "When you create network modules for a new platform, or modify the connections provided by an existing network platform (such as ``network_cli`` and ``httpapi``), you also need to update the :ref:`settings_by_platform` table and add or modify the Platform Options file for your platform." -msgstr "新しいプラットフォーム用のネットワークモジュールを作成する場合や、既存のネットワークプラットフォーム (``network_cli``、``httpapi`` など) が提供する接続を変更する場合は、:ref:`settings_by_platform` テーブルを更新して、プラットフォームの Platform Options ファイルを追加または変更することも必要です。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:13 -msgid "You should already have documented each module as described in :ref:`developing_modules_documenting`." -msgstr "各モジュールは、「:ref:`developing_modules_documenting`」で説明されているように、すでに文書化されている必要があります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:16 -msgid "Modifying the platform options table" -msgstr "プラットフォームオプションテーブルの変更" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:18 -msgid "The :ref:`settings_by_platform` table is a convenient summary of the connections options provided by each network platform that has modules in Ansible. Add a row for your platform to this table, in alphabetical order. For example:" -msgstr ":ref:`settings_by_platform` テーブルは、Ansible にモジュールがある各ネットワークプラットフォームが提供する接続オプションの便利な概要です。お使いのプラットフォームの行をアルファベット順に追加します。以下に例を示します。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:25 -msgid "Ensure that the table stays formatted correctly. That is:" -msgstr "テーブルの形式が正しく表示されていることを確認します。つまり、以下のようになります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:27 -msgid "Each row is inserted in alphabetical order." -msgstr "各行はアルファベット順に挿入されます。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:28 -msgid "The cell division ``|`` markers line up with the ``+`` markers." -msgstr "セル分割マーカー ``|`` と ``+`` マーカーの位置は同じになります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:29 -msgid "The check marks appear only for the connection types provided by the network modules." -msgstr "このチェックマークは、ネットワークモジュールが提供する接続タイプに限り表示されます。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:34 -msgid "Adding a platform-specific options section" -msgstr "プラットフォーム固有のオプションセクションの追加" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:36 -msgid "The platform- specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules. Name your new file ``platform_.rst`` (for example, ``platform_myos.rst``). The platform name should match the module prefix. See `platform_eos.rst `_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section." -msgstr "プラットフォーム固有のセクションは、ネットワークプラットフォームモジュールのユーザーに関する詳細情報を提供する個別の ``.rst`` ファイルです。新しいファイル ``platform_.rst`` に名前を付けます (例: ``platform_myos.rst``)。プラットフォーム名はモジュール接頭辞と一致させる必要があります。プラットフォーム固有のオプションセクションに指定する必要のある詳細例は、「`platform_eos.rst `_」および「:ref:`eos_platform_options`」を参照してください。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:38 -msgid "Your platform-specific section should include the following:" -msgstr "プラットフォーム固有のセクションには、以下のセクションが含まれている必要があります。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:40 -msgid "**Connections available table** - a deeper dive into each connection type, including details on credentials, indirect access, connections settings, and enable mode." -msgstr "**接続可能なテーブル** - 認証情報、間接アクセス、接続設定、有効化モードの詳細など、各接続タイプの詳細。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:41 -msgid "**How to use each connection type** - with working examples of each connection type." -msgstr "**各接続タイプの使用方法** - 各接続タイプの作業例を含む。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:43 -msgid "If your network platform supports SSH connections, also include the following at the bottom of your ``.rst`` file:" -msgstr "ネットワークプラットフォームが SSH 接続に対応している場合は、``.rst`` ファイルの下部に以下も追加します。" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:50 -msgid "Adding your new file to the table of contents" -msgstr "新規ファイルのコンテンツを表へ追加" - -#: ../../rst/network/dev_guide/documenting_modules_network.rst:52 -msgid "As a final step, add your new file in alphabetical order in the ``platform_index.rst`` file. You should then build the documentation to verify your additions. See :ref:`community_documentation_contributions` for more details." -msgstr "最終ステップとして、``platform_index.rst`` ファイルの新しいファイルをアルファベット順に追加します。次に、ドキュメントをビルドして、追加した内容を確認する必要があります。詳細は「:ref:`community_documentation_contributions`」を参照してください。" - -#: ../../rst/network/dev_guide/index.rst:5 -msgid "Network Developer Guide" -msgstr "ネットワーク開発者ガイド" - -#: ../../rst/network/dev_guide/index.rst:7 -msgid "Welcome to the Developer Guide for Ansible Network Automation!" -msgstr "ネットワークを自動化する開発者向けガイドへようこそ" - -#: ../../rst/network/dev_guide/index.rst:9 -#: ../../rst/network/getting_started/index.rst:15 -#: ../../rst/network/user_guide/index.rst:9 -msgid "**Who should use this guide?**" -msgstr "**本ガイドの対象者**" - -#: ../../rst/network/dev_guide/index.rst:11 -msgid "If you want to extend Ansible for Network Automation by creating a module or plugin, this guide is for you. This guide is specific to networking. You should already be familiar with how to create, test, and document modules and plugins, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. See the :ref:`developer_guide` for details. Before you proceed, please read:" -msgstr "ネットワーク自動化のために、モジュールやプラグインを作成して Ansible を拡張する場合は、本ガイドをお勧めします。このガイドは、ネットワークに特化しています。モジュールやプラグインの作成、テスト、文書化の方法や、作成したモジュールやプラグインを Ansible のメインリポジトリーに受け入れてもらうための前提条件については、すでにご存知のことと思います。詳細は、「:ref:`developer_guide`」を参照してください。先に進む前に、以下をお読みください。" - -#: ../../rst/network/dev_guide/index.rst:13 -msgid "How to :ref:`add a custom plugin or module locally `." -msgstr ":ref:`カスタムプラグインまたはモジュールをローカルに追加する ` 方法" - -#: ../../rst/network/dev_guide/index.rst:14 -msgid "How to figure out if :ref:`developing a module is the right approach ` for my use case." -msgstr "個別のユースケースで :ref:`モジュールを開発することが正しいアプローチ ` かどうかを判断する方法。" - -#: ../../rst/network/dev_guide/index.rst:15 -msgid "How to :ref:`set up my Python development environment `." -msgstr ":ref:`Python 開発環境を設定する ` 方法" - -#: ../../rst/network/dev_guide/index.rst:16 -msgid "How to :ref:`get started writing a module `." -msgstr ":ref:`モジュール作成を開始する ` 方法" - -#: ../../rst/network/dev_guide/index.rst:19 -msgid "Find the network developer task that best describes what you want to do:" -msgstr "お客様が必要なことを最も適切に説明しているネットワーク開発者タスクを選択してください。" - -#: ../../rst/network/dev_guide/index.rst:21 -msgid "I want to :ref:`develop a network resource module `." -msgstr ":ref:`ネットワークリソースモジュールを開発 ` したいです。" - -#: ../../rst/network/dev_guide/index.rst:22 -msgid "I want to :ref:`develop a network connection plugin `." -msgstr ":ref:`ネットワーク接続プラグインを開発 ` したいです。" - -#: ../../rst/network/dev_guide/index.rst:23 -msgid "I want to :ref:`document my set of modules for a network platform `." -msgstr ":ref:`ネットワークプラットフォームのモジュールセットを文書化 ` したいです。" - -#: ../../rst/network/dev_guide/index.rst:25 -msgid "If you prefer to read the entire guide, here's a list of the pages in order." -msgstr "本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。" - -#: ../../rst/network/getting_started/basic_concepts.rst:3 -msgid "Basic Concepts" -msgstr "基本的な概念" - -#: ../../rst/network/getting_started/basic_concepts.rst:5 -msgid "These concepts are common to all uses of Ansible, including network automation. You need to understand them to use Ansible for network automation. This basic introduction provides the background you need to follow the examples in this guide." -msgstr "この概念は、ネットワーク自動化を含む Ansible のすべての用途に共通しています。ネットワーク自動化のためにAnsibleを使用するには、これらを理解する必要があります。この基本的な紹介は、本ガイドの例を理解するのに必要な背景を説明します。" - -#: ../../rst/shared_snippets/basic_concepts.txt:2 -msgid "Control node" -msgstr "コントロールノード" - -#: ../../rst/shared_snippets/basic_concepts.txt:3 -msgid "The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others). You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible. Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features." -msgstr "Ansible CLI ツールを実行するマシン (``ansible-playbook``、``ansible``、``ansible-vault``、その他)。ソフトウェア要件を満たす任意のコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、サーバーはすべて Ansible を実行できます。複数のコントロールノードが可能ですが、Ansible 自体はそれらの間で調整されません。この機能については ``AAP`` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:9 -msgid "Managed nodes" -msgstr "管理ノード" - -#: ../../rst/shared_snippets/basic_concepts.txt:10 -msgid "Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible. Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup." -msgstr "ホストとも呼ばれ、Ansible で管理することを目的としたターゲットデバイス (サーバー、ネットワークアプライアンス、または任意のコンピューター) です。通常 Ansible は管理ノードにインストールされません。``ansible-pull`` を使用している場合は除きますが、それは稀なケースであり、推奨される設定ではありません。" - -#: ../../rst/shared_snippets/basic_concepts.txt:15 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/shared_snippets/basic_concepts.txt:16 -msgid "A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address. It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment. To learn more about inventory, see :ref:`the Working with Inventory` section. Sometimes an inventory source file is also referred to as a 'hostfile'." -msgstr "1 つ以上の「インベントリーソース」で提供される管理ノードの一覧。インベントリーは、IP アドレスなどの各ノードに固有の情報を指定できます。また、プレイおよび一括変数割り当てでノードの選択を可能にするグループの割り当てにも使用されます。インベントリーの詳細は、:ref:`the Working with Inventory` セクションを参照してください。インベントリーソースファイルは「hostfile」と呼ばれる場合もあります。" - -#: ../../rst/shared_snippets/basic_concepts.txt:22 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/shared_snippets/basic_concepts.txt:23 -msgid "They contain Plays (which are the basic unit of Ansible execution). This is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`." -msgstr "プレイ (Ansible 実行の基本単位) が含まれています。これは「実行の概念」であり、``ansible-playbook`` が動作するファイルの記述方法でもあります。Playbook は YAML で書かれており、簡単に読み書き、共有、理解できます。Playbook の詳細については、:ref:`about_playbooks` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:27 -msgid "Plays" -msgstr "プレイ" - -#: ../../rst/shared_snippets/basic_concepts.txt:28 -msgid "The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks. The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly. It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them." -msgstr "Ansible 実行のメインコンテキストであるこの Playbook オブジェクトは、管理ノード (ホスト) をタスクにマップします。プレイには、変数、ロール、およびタスクの順序付きリストが含まれており、繰り返し実行できます。これは基本的に、マップされたホストとタスクの暗黙的なループで設定され、それらを反復処理する方法を定義します。" - -#: ../../rst/shared_snippets/basic_concepts.txt:34 -msgid "A limited distribution of reusable Ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play. To use any Role resource, the Role itself must be imported into the Play." -msgstr "プレイ内で使用するための再利用可能な Ansible コンテンツ (タスク、ハンドラー、変数、プラグイン、テンプレート、およびファイル) の限定ディストリビューション。ロールリソースを使用するには、ロール自体をプレイにインポートする必要があります。" - -#: ../../rst/shared_snippets/basic_concepts.txt:38 -msgid "Tasks" -msgstr "タスク" - -#: ../../rst/shared_snippets/basic_concepts.txt:39 -msgid "The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file). You can execute a single task once with an ad hoc command using ``ansible`` or ``ansible-console`` (both create a virtual Play)." -msgstr "管理ホストに適用される「アクション」の定義。タスクは、常に直接または間接的にプレイに含まれている必要があります (ロール、またはインポート/インクルードされたタスクリストファイル)。アドホックコマンド ``ansible`` または ``ansible-console`` (どちらも仮想プレイを作成) を使用して、1 つのタスクを 1 回実行できます。" - -#: ../../rst/shared_snippets/basic_concepts.txt:43 -msgid "Handlers" -msgstr "Handler (ハンドラー)" - -#: ../../rst/shared_snippets/basic_concepts.txt:44 -msgid "A special form of a Task, that only executes when notified by a previous task which resulted in a 'changed' status." -msgstr "特別な形式のタスク。前のタスクから通知されたときにのみ実行され、'changed' ステータスになります。" - -#: ../../rst/shared_snippets/basic_concepts.txt:48 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/shared_snippets/basic_concepts.txt:49 -msgid "The code or binaries that Ansible copies to and executes on each managed node (when needed) to accomplish the action defined in each Task. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`." -msgstr "Ansible が、各タスクで定義されたアクションを実行するために、各管理ノードで (必要に応じて) コピーおよび実行するコードまたはバイナリー。各モジュールは、特定タイプのデータベースのユーザーを管理したり、特定タイプのネットワークデバイスの VLAN インターフェースを管理するなど、特定の用途に使用されます。タスクで 1 つのモジュールを起動したり、Playbook で複数のモジュールを起動したりすることができます。Ansible モジュールはコレクションとしてまとめられています。Ansible に含まれるコレクションの数は、:ref:`list_of_collections` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:56 -msgid "Plugins" -msgstr "プラグイン" - -#: ../../rst/shared_snippets/basic_concepts.txt:57 -msgid "Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins), manipulate data (filter plugins) and even control what is displayed in the console (callback plugins). See :ref:`working_with_plugins` for details." -msgstr "Ansible のコア機能を拡張するコードの一部であり、管理ノードへの接続方法 (接続プラグイン)、データの操作 (フィルタープラグイン)、さらにはコンソールに表示される内容 (コールバックプラグイン) を制御できます。詳細は :ref:`working_with_plugins` を参照してください。" - -#: ../../rst/shared_snippets/basic_concepts.txt:64 -msgid "A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy `_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other." -msgstr "コレクションは、Playbook、ロール、モジュール、プラグインなどの Ansible コンテンツのディストリビューション形式です。`Ansible Galaxy `_ でコレクションをインストールして使用することができます。コレクションの詳細は、:ref:`collections` を参照してください。コレクションリソースは、互いに依存せず、個別に使用できます。" - -#: ../../rst/shared_snippets/basic_concepts.txt:68 -msgid "AAP" -msgstr "AAP" - -#: ../../rst/shared_snippets/basic_concepts.txt:69 -msgid "Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on." -msgstr "Ansible Automation Platform の略です。これは、エンタープライズレベルの機能が含まれ、Ansible エコシステムの多くツール (ansible-core、awx、galaxyNG など) を統合する製品です。" - -#: ../../rst/network/getting_started/first_inventory.rst:3 -msgid "Build Your Inventory" -msgstr "インベントリーの構築" - -#: ../../rst/network/getting_started/first_inventory.rst:5 -msgid "Running a playbook without an inventory requires several command-line flags. Also, running a playbook against a single device is not a huge efficiency gain over making the same change manually. The next step to harnessing the full power of Ansible is to use an inventory file to organize your managed nodes into groups with information like the ``ansible_network_os`` and the SSH user. A fully-featured inventory file can serve as the source of truth for your network. Using an inventory file, a single playbook can maintain hundreds of network devices with a single command. This page shows you how to build an inventory file, step by step." -msgstr "インベントリーを使用せずに Playbook を実行するには、いくつかのコマンドラインフラグが必要です。また、単一のデバイスに対して Playbook を実行しても、同じ変更を手動で行うのに比べて効率が大きく向上するわけではありません。Ansible を最大限に活用するための次のステップは、インベントリーファイルを使用して、管理対象のノードを ``ansible_network_os`` や SSH ユーザーなどの情報を持つグループに整理することです。完全な機能を備えたインベントリーファイルは、ネットワークの唯一の信頼できるソースとなります。インベントリーファイルを使用すると、1 つの Playbook で数百のネットワークデバイスを 1 つのコマンドで管理できます。このページでは、インベントリーファイルを作成する方法を順を追って説明します。" - -#: ../../rst/network/getting_started/first_inventory.rst:11 -msgid "Basic inventory" -msgstr "基本的なインベントリー" - -#: ../../rst/network/getting_started/first_inventory.rst:13 -msgid "First, group your inventory logically. Best practice is to group servers and network devices by their What (application, stack or microservice), Where (datacenter or region), and When (development stage):" -msgstr "まず、インベントリーを論理的にグループ化します。ベストプラクティスは、サーバーおよびネットワークデバイスを、種類 (アプリケーション、スタック、またはマイクロサービス)、場所 (データセンタまたは地域)、および時期 (開発段階) でグループ化することです。" - -#: ../../rst/network/getting_started/first_inventory.rst:15 -msgid "**What**: db, web, leaf, spine" -msgstr "**種類**: db、web、leaf、spine" - -#: ../../rst/network/getting_started/first_inventory.rst:16 -msgid "**Where**: east, west, floor_19, building_A" -msgstr "**場所**: east、west、floor_19、building_A" - -#: ../../rst/network/getting_started/first_inventory.rst:17 -msgid "**When**: dev, test, staging, prod" -msgstr "**時期**: dev、test、staging、prod" - -#: ../../rst/network/getting_started/first_inventory.rst:19 -msgid "Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in your group names. Group names are case sensitive." -msgstr "グループ名にスペースまたはハイフンを使用しないでください。またグループ名は数値で始めないでください (``19th_floor``ではなく ``floor_19`` を使用)。グループ名は大文字と小文字を区別します。" - -#: ../../rst/network/getting_started/first_inventory.rst:21 -msgid "This tiny example data center illustrates a basic group structure. You can group groups using the syntax ``[metagroupname:children]`` and listing groups as members of the metagroup. Here, the group ``network`` includes all leafs and all spines; the group ``datacenter`` includes all network devices plus all webservers." -msgstr "この小さなデータセンターの例では、基本的なグループ構造を説明します。グループをグループ化するには、``[metagroupname:children]`` という構文を使い、グループをメタグループのメンバーとしてリストアップします。ここでは、``network`` というグループには、すべての leaf (リーフ) とすべての spine (スパイン) が含まれ、``datacenter`` というグループには、すべてのネットワークデバイスとすべての Web サーバーが含まれています。" - -#: ../../rst/network/getting_started/first_inventory.rst:60 -msgid "You can also create this same inventory in INI format." -msgstr "同じインベントリーを INI 形式で作成することもできます。" - -#: ../../rst/network/getting_started/first_inventory.rst:86 -msgid "Add variables to the inventory" -msgstr "インベントリーへの変数の追加" - -#: ../../rst/network/getting_started/first_inventory.rst:88 -msgid "Next, you can set values for many of the variables you needed in your first Ansible command in the inventory, so you can skip them in the ``ansible-playbook`` command. In this example, the inventory includes each network device's IP, OS, and SSH user. If your network devices are only accessible by IP, you must add the IP to the inventory file. If you access your network devices using hostnames, the IP is not necessary." -msgstr "次に、最初の Ansible コマンドで必要であった多くの変数の値をインベントリーに設定することで、``ansible-playbook`` コマンドでスキップできるようになります。この例では、インベントリーに各ネットワークデバイスの IP、OS、SSH ユーザーが含まれています。ネットワークデバイスに IP でしかアクセスできない場合は、インベントリーファイルに IP を追加する必要があります。ホスト名を使用してネットワークデバイスにアクセスする場合は、IP が必要ありません。" - -#: ../../rst/network/getting_started/first_inventory.rst:137 -msgid "Group variables within inventory" -msgstr "インベントリー内のグループ変数" - -#: ../../rst/network/getting_started/first_inventory.rst:139 -msgid "When devices in a group share the same variable values, such as OS or SSH user, you can reduce duplication and simplify maintenance by consolidating these into group variables:" -msgstr "グループ内のデバイスが、OS や SSH ユーザーなど、同じ変数値を共有している場合は、この値をグループ変数に統合することで、重複を減らし、メンテナンスを簡素化できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:185 -msgid "Variable syntax" -msgstr "変数の構文" - -#: ../../rst/network/getting_started/first_inventory.rst:187 -msgid "The syntax for variable values is different in inventory, in playbooks, and in the ``group_vars`` files, which are covered below. Even though playbook and ``group_vars`` files are both written in YAML, you use variables differently in each." -msgstr "変数の値の構文は、インベントリー、Playbook、および ``group_vars`` ファイルで異なりますが、以下で説明します。Playbook と ``group_vars`` ファイルはどちらも YAML で記述されていますが、変数は YAML でそれぞれ異なります。" - -#: ../../rst/network/getting_started/first_inventory.rst:189 -msgid "In an ini-style inventory file you **must** use the syntax ``key=value`` for variable values: ``ansible_network_os=vyos.vyos.vyos``." -msgstr "ini 形式のインベントリーファイルで、変数値 ``ansible_network_os=vyos.vyos.vyos`` に構文 ``key=value`` を使用する **必要があります**。" - -#: ../../rst/network/getting_started/first_inventory.rst:190 -msgid "In any file with the ``.yml`` or ``.yaml`` extension, including playbooks and ``group_vars`` files, you **must** use YAML syntax: ``key: value``." -msgstr "Playbook および ``group_vars`` ファイルを含む ``.yml`` 拡張子または ``.yaml`` 拡張子を持つファイルでは、YAML 構文 ``key: value`` を使用する**必要があります**。" - -#: ../../rst/network/getting_started/first_inventory.rst:192 -msgid "In ``group_vars`` files, use the full ``key`` name: ``ansible_network_os: vyos.vyos.vyos``." -msgstr "``group_vars`` ファイルで、完全な ``key`` 名 (``ansible_network_os: vyos.vyos.vyos``) を使用します。" - -#: ../../rst/network/getting_started/first_inventory.rst:193 -msgid "In playbooks, use the short-form ``key`` name, which drops the ``ansible`` prefix: ``network_os: vyos.vyos.vyos``." -msgstr "Playbook では、``ansible`` の接頭辞を取り除いた短い形式の``key`` の名前を使用します (``network_os: vyos.vyos.vyos``)。" - -#: ../../rst/network/getting_started/first_inventory.rst:197 -msgid "Group inventory by platform" -msgstr "プラットフォームによるインベントリーのグループ化" - -#: ../../rst/network/getting_started/first_inventory.rst:199 -msgid "As your inventory grows, you may want to group devices by platform. This allows you to specify platform-specific variables easily for all devices on that platform:" -msgstr "インベントリーが大きくなるにつれ、プラットフォームでデバイスをグループ化できます。これにより、そのプラットフォームのすべてのデバイスに対してプラットフォーム固有の変数を簡単に指定できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:242 -msgid "With this setup, you can run ``first_playbook.yml`` with only two flags:" -msgstr "この設定では、以下の 2 つのフラグを指定して ``first_playbook.yml`` を実行できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:248 -msgid "With the ``-k`` flag, you provide the SSH password(s) at the prompt. Alternatively, you can store SSH and other secrets and passwords securely in your group_vars files with ``ansible-vault``. See :ref:`network_vault` for details." -msgstr "``-k`` フラグを使用して、プロンプトで SSH パスワードを指定します。これで、``ansible-vault`` で SSH と、その他のシークレットおよびパスワードを group_vars ファイルに安全に保存できます。詳細は「:ref:`network_vault`」を参照してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:251 -msgid "Verifying the inventory" -msgstr "インベントリーの確認" - -#: ../../rst/network/getting_started/first_inventory.rst:253 -msgid "You can use the :ref:`ansible-inventory` CLI command to display the inventory as Ansible sees it." -msgstr "CLI コマンド :ref:`ansible-inventory` を使用すると、Ansible が確認できるようにインベントリーを表示できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:336 -msgid "Protecting sensitive variables with ``ansible-vault``" -msgstr "``ansible-vault`` による機密変数の保護" - -#: ../../rst/network/getting_started/first_inventory.rst:338 -msgid "The ``ansible-vault`` command provides encryption for files and/or individual variables like passwords. This tutorial will show you how to encrypt a single SSH password. You can use the commands below to encrypt other sensitive information, such as database passwords, privilege-escalation passwords and more." -msgstr "``ansible-vault`` コマンドは、ファイルや、パスワードなどの個々の変数の暗号化を行います。このチュートリアルでは、1 つの SSH パスワードを暗号化する方法を紹介します。以下のコマンドを使用すると、データベースのパスワードや権限昇格のためのパスワードなど、その他の機密情報を暗号化することができます。" - -#: ../../rst/network/getting_started/first_inventory.rst:340 -msgid "First you must create a password for ansible-vault itself. It is used as the encryption key, and with this you can encrypt dozens of different passwords across your Ansible project. You can access all those secrets (encrypted values) with a single password (the ansible-vault password) when you run your playbooks. Here's a simple example." -msgstr "まず、ansible-vault 自体のパスワードを作成する必要があります。これは暗号化キーとして使用され、Ansible プロジェクト全体で何十もの異なるパスワードを暗号化することができます。Playbook を実行するときに、1 つのパスワード (ansible-vault パスワード) でこの全シークレット (暗号化された値) にアクセスできます。以下に簡単な例を示します。" - -#: ../../rst/network/getting_started/first_inventory.rst:342 -msgid "Create a file and write your password for ansible-vault to it:" -msgstr "ファイルを作成して、ansible-vault のパスワードを書き込みます。" - -#: ../../rst/network/getting_started/first_inventory.rst:348 -msgid "Create the encrypted ssh password for your VyOS network devices, pulling your ansible-vault password from the file you just created:" -msgstr "VyOS ネットワークデバイス用に暗号化された ssh パスワードを作成し、作成したファイルから ansible-vault パスワードをプルします。" - -#: ../../rst/network/getting_started/first_inventory.rst:354 -msgid "If you prefer to type your ansible-vault password rather than store it in a file, you can request a prompt:" -msgstr "ファイルに保存せずに ansible-vault パスワードを入力する必要がある場合は、プロンプトを要求できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:360 -msgid "and type in the vault password for ``my_user``." -msgstr "また、``my_user`` に vault パスワードに入力します。" - -#: ../../rst/network/getting_started/first_inventory.rst:362 -msgid "The :option:`--vault-id ` flag allows different vault passwords for different users or different levels of access. The output includes the user name ``my_user`` from your ``ansible-vault`` command and uses the YAML syntax ``key: value``:" -msgstr "option:`--vault-id ` フラグを使用すると、ユーザーまたはアクセスレベルごとに異なる Vault パスワードを使用できます。出力には、``ansible-vault`` コマンドのユーザー名 ``my_user`` が含まれ、YAML 構文 ``key: value`` が使用されます。" - -#: ../../rst/network/getting_started/first_inventory.rst:375 -msgid "This is an example using an extract from a YAML inventory, as the INI format does not support inline vaults:" -msgstr "INI 形式はインラインの vault に対応していないため、以下は YAML インベントリーから抽出を使用する例です。" - -#: ../../rst/network/getting_started/first_inventory.rst:396 -msgid "To use an inline vaulted variables with an INI inventory you need to store it in a 'vars' file in YAML format, it can reside in host_vars/ or group_vars/ to be automatically picked up or referenced from a play through ``vars_files`` or ``include_vars``." -msgstr "インラインの Vault 変数を INI インベントリーで使用するには、これを YAML 形式で「vars」ファイルに保存する必要があります。これは host_vars/ または group_vars/ に置かれ、``vars_files`` または ``include_vars`` でプレイから自動的に取得または参照されます。" - -#: ../../rst/network/getting_started/first_inventory.rst:399 -msgid "To run a playbook with this setup, drop the ``-k`` flag and add a flag for your ``vault-id``:" -msgstr "この設定で Playbook を実行するには、``-k`` フラグを削除し、``vault-id`` のフラグを追加します。" - -#: ../../rst/network/getting_started/first_inventory.rst:405 -msgid "Or with a prompt instead of the vault password file:" -msgstr "または、vault パスワードファイルの代わりにプロンプトを使用します。" - -#: ../../rst/network/getting_started/first_inventory.rst:411 -msgid "To see the original value, you can use the debug module. Please note if your YAML file defines the `ansible_connection` variable (as we used in our example), it will take effect when you execute the command below. To prevent this, please make a copy of the file without the ansible_connection variable." -msgstr "元の値を確認するには、デバッグモジュールを使用できます。(この例で使用したように) YAML ファイルで `ansible_connection` 変数が定義されているかどうかに注意してください。以下のコマンドを実行すると有効になります。これを防ぐには、ansible_connection 変数を使用せずにファイルのコピーを作成してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:427 -msgid "Vault content can only be decrypted with the password that was used to encrypt it. If you want to stop using one password and move to a new one, you can update and re-encrypt existing vault content with ``ansible-vault rekey myfile``, then provide the old password and the new password. Copies of vault content still encrypted with the old password can still be decrypted with old password." -msgstr "Vault のコンテンツは、暗号化に使用されたパスワードでのみ復号できます。1 つのパスワードの使用を停止して新しいパスワードに移動する場合は、``ansible-vault rekey myfile`` を使用して、既存の Valut コンテンツを更新して再暗号化でき、次に古いパスワードと新しいパスワードを入力します。古いパスワードで暗号化されたままの Vault コンテンツのコピーは、古いパスワードで復号できます。" - -#: ../../rst/network/getting_started/first_inventory.rst:429 -msgid "For more details on building inventory files, see :ref:`the introduction to inventory`; for more details on ansible-vault, see :ref:`the full Ansible Vault documentation`." -msgstr "インベントリーファイルの構築の詳細は、「:ref:`インベントリーの概要`」を参照してください。ansible-vault の詳細は、:ref:`Ansible Vault の完全ドキュメント` を参照してください。" - -#: ../../rst/network/getting_started/first_inventory.rst:431 -msgid "Now that you understand the basics of commands, playbooks, and inventory, it's time to explore some more complex Ansible Network examples." -msgstr "コマンド、Playbook、およびインベントリーの基本を理解したら、より複雑な Ansible Network の例をいくつか説明します。" - -#: ../../rst/network/getting_started/first_playbook.rst:6 -msgid "Run Your First Command and Playbook" -msgstr "最初のコマンドおよび Playbook の実行" - -#: ../../rst/network/getting_started/first_playbook.rst:8 -msgid "Put the concepts you learned to work with this quick tutorial. Install Ansible, execute a network configuration command manually, execute the same command with Ansible, then create a playbook so you can execute the command any time on multiple network devices." -msgstr "このクイックチュートリアルでは、これまで学んだ概念を実際に使ってみましょう。Ansible をインストールし、ネットワーク設定コマンドを手動で実行し、Ansible で同じコマンドを実行してから Playbook を作成するため、複数のネットワークデバイスでいつでもコマンドを実行できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:14 -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:13 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/network/getting_started/first_playbook.rst:16 -msgid "Before you work through this tutorial you need:" -msgstr "このチュートリアルを実行する前に、以下が必要になります。" - -#: ../../rst/network/getting_started/first_playbook.rst:18 -msgid "Ansible 2.10 (or higher) installed" -msgstr "Ansible 2.10 (以降) がインストールされている" - -#: ../../rst/network/getting_started/first_playbook.rst:19 -msgid "One or more network devices that are compatible with Ansible" -msgstr "Ansible と互換性のある 1 つ以上ネットワークデバイス" - -#: ../../rst/network/getting_started/first_playbook.rst:20 -msgid "Basic Linux command line knowledge" -msgstr "基本的な Linux コマンドラインの知識" - -#: ../../rst/network/getting_started/first_playbook.rst:21 -msgid "Basic knowledge of network switch & router configuration" -msgstr "ネットワークスイッチおよびルーター設定に関する基本知識" - -#: ../../rst/network/getting_started/first_playbook.rst:24 -msgid "Install Ansible" -msgstr "Ansible のインストール" - -#: ../../rst/network/getting_started/first_playbook.rst:26 -msgid "Install Ansible using your preferred method. See :ref:`installation_guide`. Then return to this tutorial." -msgstr "好みの方法で Ansible をインストールします。「:ref:`installation_guide`」を参照してください。その後、このチュートリアルに戻ります。" - -#: ../../rst/network/getting_started/first_playbook.rst:28 -msgid "Confirm the version of Ansible (must be >= 2.10):" -msgstr "Ansible のバージョンを確認します (2.10 以下である必要があります)。" - -#: ../../rst/network/getting_started/first_playbook.rst:36 -msgid "Establish a manual connection to a managed node" -msgstr "管理ノードへの手動接続の確立" - -#: ../../rst/network/getting_started/first_playbook.rst:38 -msgid "To confirm your credentials, connect to a network device manually and retrieve its configuration. Replace the sample user and device name with your real credentials. For example, for a VyOS router:" -msgstr "認証情報を確認するには、手動でネットワークデバイスに接続し、その設定を取得します。サンプルユーザー名とデバイス名を実際の認証情報に置き換えます。たとえば、VyOS ルーターの場合は以下のようになります。" - -#: ../../rst/network/getting_started/first_playbook.rst:46 -msgid "This manual connection also establishes the authenticity of the network device, adding its RSA key fingerprint to your list of known hosts. (If you have connected to the device before, you have already established its authenticity.)" -msgstr "この手動接続により、ネットワークデバイスの信頼性も確立され、既知のホストの一覧に RSA 鍵フィンガープリントが追加されます (以前にデバイスを接続したことがある場合は、その信頼性がすでに確立されています)。" - -#: ../../rst/network/getting_started/first_playbook.rst:50 -msgid "Run your first network Ansible command" -msgstr "最初のネットワーク Ansible コマンドの実行" - -#: ../../rst/network/getting_started/first_playbook.rst:52 -msgid "Instead of manually connecting and running a command on the network device, you can retrieve its configuration with a single, stripped-down Ansible command:" -msgstr "ネットワークデバイスでコマンドを手動で接続して実行する代わりに、1 つの削除済み Ansible コマンドで設定を取得できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:65 -msgid "The flags in this command set seven values:" -msgstr "このコマンドのフラグは、7 つの値を設定します。" - -#: ../../rst/network/getting_started/first_playbook.rst:59 -msgid "the host group(s) to which the command should apply (in this case, all)" -msgstr "コマンドを適用するホストグループ (この場合は all)" - -#: ../../rst/network/getting_started/first_playbook.rst:60 -msgid "the inventory (-i, the device or devices to target - without the trailing comma -i points to an inventory file)" -msgstr "インベントリー (-i、ターゲットに設定するデバイス (最後のコンマがない -i はインベントリーファイルの指定がありません))" - -#: ../../rst/network/getting_started/first_playbook.rst:61 -msgid "the connection method (-c, the method for connecting and executing ansible)" -msgstr "接続方法 (-c、ansible の接続方法および実行方法)" - -#: ../../rst/network/getting_started/first_playbook.rst:62 -msgid "the user (-u, the username for the SSH connection)" -msgstr "ユーザー (-u、SSH 接続のユーザー名)" - -#: ../../rst/network/getting_started/first_playbook.rst:63 -msgid "the SSH connection method (-k, please prompt for the password)" -msgstr "SSH 接続の方法 (-k、パスワードのプロンプト有り)" - -#: ../../rst/network/getting_started/first_playbook.rst:64 -msgid "the module (-m, the Ansible module to run, using the fully qualified collection name (FQCN))" -msgstr "モジュール (-m、完全修飾コレクション名 (FQCN) を使用した、実行する Ansible モジュール)" - -#: ../../rst/network/getting_started/first_playbook.rst:65 -msgid "an extra variable ( -e, in this case, setting the network OS value)" -msgstr "追加変数 (-e、この場合はネットワーク OS 値の設定)" - -#: ../../rst/network/getting_started/first_playbook.rst:67 -msgid "NOTE: If you use ``ssh-agent`` with ssh keys, Ansible loads them automatically. You can omit ``-k`` flag." -msgstr "注記: ssh 鍵で ``ssh-agent`` を使用すると、Ansible により自動的に読み込まれます。``-k`` フラグは省略できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:71 -msgid "If you are running Ansible in a virtual environment, you will also need to add the variable ``ansible_python_interpreter=/path/to/venv/bin/python``" -msgstr "仮想環境で Ansible を実行している場合は、変数 ``ansible_python_interpreter=/path/to/venv/bin/python`` を追加する必要もあります。" - -#: ../../rst/network/getting_started/first_playbook.rst:75 -msgid "Create and run your first network Ansible Playbook" -msgstr "最初のネットワークの Ansible Playbook の作成および実行" - -#: ../../rst/network/getting_started/first_playbook.rst:77 -msgid "If you want to run this command every day, you can save it in a playbook and run it with ``ansible-playbook`` instead of ``ansible``. The playbook can store a lot of the parameters you provided with flags at the command line, leaving less to type at the command line. You need two files for this - a playbook and an inventory file." -msgstr "このコマンドを毎日実行する場合は、Playbook に保存し、``ansible`` の代わりに ``ansible-playbook`` を使用して実行できます。Playbook には、コマンドラインでフラグを使用して指定した多くのパラメーターを保存できるため、コマンドラインで入力するパラメータが少なくなります。これを行うためには、Playbook およびインベントリーファイルの 2 つのファイルが必要です。" - -#: ../../rst/network/getting_started/first_playbook.rst:79 -msgid "Download :download:`first_playbook.yml `, which looks like this:" -msgstr ":download:`first_playbook.yml ` をダウンロードします。これは、以下のようになります。" - -#: ../../rst/network/getting_started/first_playbook.rst:84 -msgid "The playbook sets three of the seven values from the command line above: the group (``hosts: all``), the connection method (``connection: ansible.netcommon.network_cli``) and the module (in each task). With those values set in the playbook, you can omit them on the command line. The playbook also adds a second task to show the config output. When a module runs in a playbook, the output is held in memory for use by future tasks instead of written to the console. The debug task here lets you see the results in your shell." -msgstr "Playbook では、上記のコマンドラインの 7 つの値のうちの 3 つ、つまりグループ (``hosts: all``)、接続方法 (``connection: ansible.netcommon.network_cli``)、モジュール (各タスク内) が設定されます。これらの値を Playbook で設定すると、コマンドラインで省略できます。この Playbook には、設定出力を表示する 2 番目のタスクも追加されています。モジュールが Playbook で実行すると、出力はコンソールに書き込まれるのではなく、将来のタスクで使用するためにメモリーに保持されます。ここでデバッグタスクを実行すると、シェルで結果を確認できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:86 -msgid "Run the playbook with the command:" -msgstr "以下のコマンドを使用して Playbook を実行します。" - -#: ../../rst/network/getting_started/first_playbook.rst:92 -msgid "The playbook contains one play with two tasks, and should generate output like this:" -msgstr "Playbook には、2 つのタスクを持つプレイが 1 つ含まれており、次のような出力が生成されます。" - -#: ../../rst/network/getting_started/first_playbook.rst:111 -msgid "Now that you can retrieve the device config, try updating it with Ansible. Download :download:`first_playbook_ext.yml `, which is an extended version of the first playbook:" -msgstr "デバイス設定を取得できたので、Ansible で更新してみましょう。最初の Playbook の拡張バージョンである :download:`first_playbook_ext.yml ` をダウンロードします。" - -#: ../../rst/network/getting_started/first_playbook.rst:116 -msgid "The extended first playbook has five tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config:" -msgstr "拡張された最初の Playbook には、1 つのプレイに 5 つのタスクがあります。上記のコマンドと同じコマンドを使用して実行すると、出力には、Ansible が設定に加えた変更が表示されます。" - -#: ../../rst/network/getting_started/first_playbook.rst:158 -msgid "Gathering facts from network devices" -msgstr "ネットワークデバイスからのファクトの収集" - -#: ../../rst/network/getting_started/first_playbook.rst:160 -msgid "The ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device." -msgstr "``gather_facts`` キーワードは、標準化された鍵と値のペアでネットワークデバイスのファクトの収集に対応します。これらのネットワークファクトを、ネットワークデバイスを管理する追加のタスクに指定できます。" - -#: ../../rst/network/getting_started/first_playbook.rst:162 -msgid "You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`arista.eos.eos_facts `) to return just a subset of the device configuration, as shown below." -msgstr "また、新しい ``gather_network_resources`` パラメーターを、ネットワークの ``*_facts`` モジュール (:ref:`arista.eos.eos_facts ` など) とともに使用すると、以下のようにデバイス設定のサブセットのみを返すことができます。" - -#: ../../rst/network/getting_started/first_playbook.rst:173 -msgid "The playbook returns the following interface facts:" -msgstr "Playbook は以下のインターフェースのファクトを返します。" - -#: ../../rst/network/getting_started/first_playbook.rst:210 -msgid "Note that this returns a subset of what is returned by just setting ``gather_subset: interfaces``." -msgstr "これは、``gather_subset: interfaces`` の設定で返される内容のサブセットを返すことに注意してください。" - -#: ../../rst/network/getting_started/first_playbook.rst:212 -msgid "You can store these facts and use them directly in another task, such as with the :ref:`eos_interfaces ` resource module." -msgstr "これらのファクトを保存し、:ref:`eos_interfaces ` リソースモジュールなどの別のタスクで直接使用できます。" - -#: ../../rst/network/getting_started/index.rst:23 -msgid "Getting Started Guide" -msgstr "入門ガイド" - -#: ../../rst/network/getting_started/index.rst:5 -msgid "Network Getting Started" -msgstr "ネットワークスタートガイド" - -#: ../../rst/network/getting_started/index.rst:7 -msgid "Ansible collections support a wide range of vendors, device types, and actions, so you can manage your entire network with a single automation tool. With Ansible, you can:" -msgstr "Ansible コレクションは広範なベンダー、デバイスタイプ、アクションに対応しているため、1 つの自動化ツールでネットワーク全体を管理できます。Ansible では、以下を行うことができます。" - -#: ../../rst/network/getting_started/index.rst:9 -msgid "Automate repetitive tasks to speed routine network changes and free up your time for more strategic work" -msgstr "反復タスクを自動化して、ルーチンネットワークの変更を迅速化し、その時間をより戦略的な作業に割り当てます。" - -#: ../../rst/network/getting_started/index.rst:10 -msgid "Leverage the same simple, powerful, and agentless automation tool for network tasks that operations and development use" -msgstr "操作と開発で使用するネットワークタスクの両方に、同一の簡単で強力なエージェントレスの自動化ツールを使用します。" - -#: ../../rst/network/getting_started/index.rst:11 -msgid "Separate the data model (in a playbook or role) from the execution layer (through Ansible modules) to manage heterogeneous network devices" -msgstr "異機種環境にあるネットワークデバイスを管理するため、(Ansible モジュールにより) 実行レイヤーから (Playbook またはロールの) データモデルを分離します。" - -#: ../../rst/network/getting_started/index.rst:12 -msgid "Benefit from community and vendor-generated sample playbooks and roles to help accelerate network automation projects" -msgstr "ネットワーク自動化プロジェクトを加速化するコミュニティーおよびベンダーが生成したサンプルの Playbook およびロールを活用します。" - -#: ../../rst/network/getting_started/index.rst:13 -msgid "Communicate securely with network hardware over SSH or HTTPS" -msgstr "SSH または HTTPS を介してネットワークハードウェアとセキュアに通信します。" - -#: ../../rst/network/getting_started/index.rst:17 -msgid "This guide is intended for network engineers using Ansible for the first time. If you understand networks but have never used Ansible, work through the guide from start to finish." -msgstr "このガイドは、Ansible を初めて使用するネットワークエンジニアを対象としています。ネットワークを理解していて、Ansible を使用したことがない場合は、ガイドを最初から最後まで実践してください。" - -#: ../../rst/network/getting_started/index.rst:19 -msgid "This guide is also useful for experienced Ansible users automating network tasks for the first time. You can use Ansible commands, playbooks and modules to configure hubs, switches, routers, bridges and other network devices. But network modules are different from Linux/Unix and Windows modules, and you must understand some network-specific concepts to succeed. If you understand Ansible but have never automated a network task, start with the second section." -msgstr "このガイドは、ネットワークタスクを初めて自動化する経験豊富な Ansible ユーザーにも役立ちます。Ansible コマンド、Playbook、モジュールを使用して、ハブ、スイッチ、ルーター、ブリッジ、その他のネットワークデバイスを構成できます。ただし、ネットワークモジュールは Linux/Unix および Windows のモジュールとは異なり、成功するにはネットワーク固有の概念を理解する必要があります。Ansible を理解していても、ネットワークタスクを自動化したことがない場合は、2 番目のセクションから始めてください。" - -#: ../../rst/network/getting_started/index.rst:21 -msgid "This guide introduces basic Ansible concepts and guides you through your first Ansible commands, playbooks and inventory entries." -msgstr "本ガイドでは、基本的な Ansible の概念を紹介し、Ansible コマンド、Playbook、およびインベントリーエントリーを説明します。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:3 -msgid "Beyond the basics" -msgstr "中級編" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:5 -msgid "This page introduces some concepts that help you manage your Ansible workflow with directory structure and source control. Like the Basic Concepts at the beginning of this guide, these intermediate concepts are common to all uses of Ansible." -msgstr "このページでは、ディレクトリー構造とソース管理を使用した Ansible ワークフローの管理に役立つ概念を紹介します。このガイドの最初の基本概念と同様に、これらの中間概念は Ansible のすべての使用に共通です。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:12 -msgid "A typical Ansible filetree" -msgstr "一般的な Ansible ファイルツリー" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:14 -msgid "Ansible expects to find certain files in certain places. As you expand your inventory and create and run more network playbooks, keep your files organized in your working Ansible project directory like this:" -msgstr "Ansible では、特定の場所にある特定のファイルを見つけることを想定しています。インベントリーを拡張し、ネットワークの Playbook を作成して実行する場合は、ファイルを以下のように作業用の Ansible プロジェクトディレクトリーに整理した状態にします。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:33 -msgid "The ``backup`` directory and the files in it get created when you run modules like ``vyos_config`` with the ``backup: yes`` parameter." -msgstr "``backup`` ディレクトリーと、そのディレクトリーのファイルは、``backup: yes`` パラメーターを使用した ``vyos_config`` のモジュールを実行する際に作成されます。" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:37 -msgid "Tracking changes to inventory and playbooks: source control with git" -msgstr "インベントリーおよび Playbook への変更の追跡: git でのソース制御" - -#: ../../rst/network/getting_started/intermediate_concepts.rst:39 -msgid "As you expand your inventory, roles and playbooks, you should place your Ansible projects under source control. We recommend ``git`` for source control. ``git`` provides an audit trail, letting you track changes, roll back mistakes, view history and share the workload of managing, maintaining and expanding your Ansible ecosystem. There are plenty of tutorials and guides to using ``git`` available." -msgstr "インベントリー、ロール、および Playbook を拡張するときは、Ansible プロジェクトをソース管理下に置く必要があります。ソース管理には ``git`` をお勧めします。``git`` には監査証跡が用意されており、変更の追跡、失敗のロールバック、履歴の表示、Ansible エコシステムの管理、維持、拡張のワークロードの共有が可能になります。``git`` を使用するためのチュートリアルとガイドが多数用意されています。" - -#: ../../rst/network/getting_started/network_connection_options.rst:5 -msgid "Working with network connection options" -msgstr "ネットワーク接続オプションの使用" - -#: ../../rst/network/getting_started/network_connection_options.rst:7 -msgid "Network modules can support multiple connection protocols, such as ``ansible.netcommon.network_cli``, ``ansible.netcommon.netconf``, and ``ansible.netcommon.httpapi``. These connections include some common options you can set to control how the connection to your network device behaves." -msgstr "ネットワークモジュールは、``ansible.netcommon.network_cli``、``ansible.netcommon.netconf``、``ansible.netcommon.httpapi`` などの複数の接続プロトコルをサポートできます。これらの接続には、ネットワークデバイスへの接続の動作を制御するために設定できる一般的なオプションがあります。" - -#: ../../rst/network/getting_started/network_connection_options.rst:9 -msgid "Common options are:" -msgstr "一般的なオプションは以下のとおりです。" - -#: ../../rst/network/getting_started/network_connection_options.rst:11 -msgid "``become`` and ``become_method`` as described in :ref:`privilege_escalation`." -msgstr "「:ref:`privilege_escalation`」に記載される通りに ``become`` および ``become_method``" - -#: ../../rst/network/getting_started/network_connection_options.rst:12 -msgid "``network_os`` - set to match your network platform you are communicating with. See the :ref:`platform-specific ` pages." -msgstr "``network_os`` - 通信しているネットワークプラットフォームと一致するように設定されます。「:ref:`platform-specific `」ページを参照してください。" - -#: ../../rst/network/getting_started/network_connection_options.rst:13 -msgid "``remote_user`` as described in :ref:`connection_set_user`." -msgstr "「:ref:`connection_set_user`」に記載される通りに ``remote_user``" - -#: ../../rst/network/getting_started/network_connection_options.rst:14 -msgid "Timeout options - ``persistent_command_timeout``, ``persistent_connect_timeout``, and ``timeout``." -msgstr "タイムアウトオプション: ``persistent_command_timeout``、``persistent_connect_timeout``、および ``timeout``" - -#: ../../rst/network/getting_started/network_connection_options.rst:19 -msgid "Setting timeout options" -msgstr "タイムアウトオプションの設定" - -#: ../../rst/network/getting_started/network_connection_options.rst:21 -msgid "When communicating with a remote device, you have control over how long Ansible maintains the connection to that device, as well as how long Ansible waits for a command to complete on that device. Each of these options can be set as variables in your playbook files, environment variables, or settings in your :ref:`ansible.cfg file `." -msgstr "リモートデバイスと通信する場合は、Ansible がそのデバイスへの接続を維持する時間、およびそのデバイスでコマンドが完了するまで Ansible が待機する時間を制御できます。各オプションは、Playbook ファイルの変数、環境変数、または :ref:`ansible.cfg ファイル ` の設定として設定できます。" - -#: ../../rst/network/getting_started/network_connection_options.rst:23 -msgid "For example, the three options for controlling the connection timeout are as follows." -msgstr "たとえば、接続タイムアウトを制御する 3 つのオプションは次のとおりです。" - -#: ../../rst/network/getting_started/network_connection_options.rst:25 -msgid "Using vars (per task):" -msgstr "vars (タスクごと) の使用:" - -#: ../../rst/network/getting_started/network_connection_options.rst:35 -msgid "Using the environment variable:" -msgstr "環境変数の使用:" - -#: ../../rst/network/getting_started/network_connection_options.rst:41 -msgid "Using the global configuration (in :file:`ansible.cfg`)" -msgstr "グローバル設定の使用 (:file:`ansible.cfg`) の使用" - -#: ../../rst/network/getting_started/network_connection_options.rst:48 -msgid "See :ref:`ansible_variable_precedence` for details on the relative precedence of each of these variables. See the individual connection type to understand each option." -msgstr "これらの各変数の相対優先度は、「:ref:`ansible_variable_precedence`」を参照してください。各オプションについては、個別の接続タイプを参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:3 -msgid "How Network Automation is Different" -msgstr "ネットワーク自動化の相違点" - -#: ../../rst/network/getting_started/network_differences.rst:5 -msgid "Network automation uses the basic Ansible concepts, but there are important differences in how the network modules work. This introduction prepares you to understand the exercises in this guide." -msgstr "ネットワーク自動化は、基本的な Ansible の概念を利用しますが、ネットワークモジュールの動作には重要な相違点があります。本ガイドの演習を始める前に、このイントロダクションをお読みください。" - -#: ../../rst/network/getting_started/network_differences.rst:11 -msgid "Execution on the control node" -msgstr "コントロールノードでの実行" - -#: ../../rst/network/getting_started/network_differences.rst:13 -msgid "Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs." -msgstr "ほとんどの Ansible モジュールとは異なり、ネットワークモジュールは管理ノードで実行されません。ユーザーから見ると、ネットワークモジュールは他のモジュールと同様に機能します。アドホックコマンド、Playbook およびロールを使用します。しかし、その裏では、ネットワークモジュールは他 (Linux/Unix および Windows) のモジュールとは異なる方法を使用します。Ansible は Python で記述され、実行されます。大部分のネットワークデバイスは Python を実行できないため、Ansible ネットワークモジュールは Ansible コントロールノードで実行されます (``ansible`` または ``ansible-playbook`` が実行される場所です)。" - -#: ../../rst/network/getting_started/network_differences.rst:15 -msgid "Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory." -msgstr "ネットワークモジュールも、``backup`` オプションを提供するモジュールのバックアップファイルの宛先としてコントロールノードを使用します。Linux/Unix モジュールでは、管理ノードに設定ファイルがすでに存在する場合に、デフォルトでは、新しい変更したファイルと同じディレクトリーにバックアップファイルが書き込まれます。ネットワーク設定はファイルに書き込まれないため、ネットワークモジュールは管理ノード上の構成ファイルを更新しません。ネットワークモジュールは、通常は Playbook のルートディレクトリーの下の `backup` ディレクトリーにあるコントロールノードにバックアップファイルを書き込みます。" - -#: ../../rst/network/getting_started/network_differences.rst:18 -msgid "Multiple communication protocols" -msgstr "複数の通信プロトコル" - -#: ../../rst/network/getting_started/network_differences.rst:20 -msgid "Because network modules execute on the control node instead of on the managed nodes, they can support multiple communication protocols. The communication protocol (XML over SSH, CLI over SSH, API over HTTPS) selected for each network module depends on the platform and the purpose of the module. Some network modules support only one protocol; some offer a choice. The most common protocol is CLI over SSH. You set the communication protocol with the ``ansible_connection`` variable:" -msgstr "ネットワークモジュールは管理ノードではなくコントロールノードで実行されるため、複数の通信プロトコルをサポートできます。各ネットワークモジュールに選択される通信プロトコル (SSH での XML、SSH での CLI、HTTPS での API) は、プラットフォームと、モジュールの目的によって異なります。プロトコルを 1 つしかサポートしていないネットワークモジュールもあります。複数のプロトコルをサポートするプロトコルもあります。最も一般的なプロトコルは CLI over SSH です。``ansible_connection`` 変数を使用して通信プロトコルを設定します。" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "Value of ansible_connection" -msgstr "ansible_connection の値" - -#: ../../rst/network/getting_started/network_differences.rst:1 -#: ../../rst/network/user_guide/platform_ce.rst:23 -#: ../../rst/network/user_guide/platform_cnos.rst:21 -#: ../../rst/network/user_guide/platform_dellos10.rst:21 -#: ../../rst/network/user_guide/platform_dellos6.rst:21 -#: ../../rst/network/user_guide/platform_dellos9.rst:21 -#: ../../rst/network/user_guide/platform_enos.rst:21 -#: ../../rst/network/user_guide/platform_eos.rst:21 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:21 -#: ../../rst/network/user_guide/platform_exos.rst:22 -#: ../../rst/network/user_guide/platform_frr.rst:21 -#: ../../rst/network/user_guide/platform_icx.rst:21 -#: ../../rst/network/user_guide/platform_ios.rst:21 -#: ../../rst/network/user_guide/platform_iosxr.rst:25 -#: ../../rst/network/user_guide/platform_ironware.rst:21 -#: ../../rst/network/user_guide/platform_junos.rst:24 -#: ../../rst/network/user_guide/platform_meraki.rst:21 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:23 -#: ../../rst/network/user_guide/platform_netvisor.rst:22 -#: ../../rst/network/user_guide/platform_nos.rst:22 -#: ../../rst/network/user_guide/platform_nxos.rst:21 -#: ../../rst/network/user_guide/platform_routeros.rst:22 -#: ../../rst/network/user_guide/platform_slxos.rst:22 -#: ../../rst/network/user_guide/platform_voss.rst:22 -#: ../../rst/network/user_guide/platform_vyos.rst:21 -#: ../../rst/network/user_guide/platform_weos4.rst:22 -msgid "Protocol" -msgstr "プロトコル" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "Requires" -msgstr "必須" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "Persistent?" -msgstr "永続的?" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "ansible.netcommon.network_cli" -msgstr "ansible.netcommon.network_cli" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "CLI over SSH" -msgstr "SSH での CLI" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "network_os setting" -msgstr "network_os の設定" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "yes" -msgstr "はい" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "ansible.netcommon.netconf" -msgstr "ansible.netcommon.netconf" - -#: ../../rst/network/getting_started/network_differences.rst:1 -#: ../../rst/network/user_guide/platform_ce.rst:23 -#: ../../rst/network/user_guide/platform_iosxr.rst:25 -#: ../../rst/network/user_guide/platform_junos.rst:24 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:23 -msgid "XML over SSH" -msgstr "SSH での XML" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "ansible.netcommon.httpapi" -msgstr "ansible.netcommon.httpapi" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "API over HTTP/HTTPS" -msgstr "HTTP/HTTPS での API" - -#: ../../rst/network/getting_started/network_differences.rst:1 -#: ../../rst/network/user_guide/platform_index.rst:61 -msgid "local" -msgstr "ローカル" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "depends on provider" -msgstr "プロバイダーによって異なる" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "provider setting" -msgstr "プロバイダー設定" - -#: ../../rst/network/getting_started/network_differences.rst:1 -msgid "no" -msgstr "いいえ" - -#: ../../rst/network/getting_started/network_differences.rst:32 -msgid "``ansible.netcommon.httpapi`` deprecates ``eos_eapi`` and ``nxos_nxapi``. See :ref:`httpapi_plugins` for details and an example." -msgstr "``ansible.netcommon.httpapi`` は、``eos_eapi`` および ``nxos_nxapi`` を非推奨とします。詳細と例は「:ref:`httpapi_plugins`」参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:34 -msgid "The ``ansible_connection: local`` has been deprecated. Please use one of the persistent connection types listed above instead. With persistent connections, you can define the hosts and credentials only once, rather than in every task. You also need to set the ``network_os`` variable for the specific network platform you are communicating with. For more details on using each connection type on various platforms, see the :ref:`platform-specific ` pages." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに、上記の永続的接続タイプのいずれかを使用してください。永続的接続では、すべてのタスクに対してではなく、ホストと認証情報を 1 回だけ定義できます。また、通信する特定のネットワークプラットフォームの ``network_os`` 変数も設定する必要があります。さまざまなプラットフォームでの各接続タイプの使用の詳細は、「:ref:`platform-specific `」を参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:38 -msgid "Collections organized by network platform" -msgstr "ネットワークプラットフォーム別に整理されたコレクション" - -#: ../../rst/network/getting_started/network_differences.rst:40 -msgid "A network platform is a set of network devices with a common operating system that can be managed by an Ansible collection, for example:" -msgstr "ネットワークプラットフォームは、Ansible コレクションで管理できる共通のオペレーティングシステムを備えたネットワークデバイスセットです。以下に例を示します。" - -#: ../../rst/network/getting_started/network_differences.rst:42 -msgid "Arista: `arista.eos `_" -msgstr "Arista: `arista.eos `_" - -#: ../../rst/network/getting_started/network_differences.rst:43 -msgid "Cisco: `cisco.ios `_, `cisco.iosxr `_, `cisco.nxos `_" -msgstr "Cisco: `cisco.ios `_、`cisco.iosxr `_、`cisco.nxos `_" - -#: ../../rst/network/getting_started/network_differences.rst:44 -msgid "Juniper: `junipernetworks.junos `_" -msgstr "Juniper: `junipernetworks.junos `_" - -#: ../../rst/network/getting_started/network_differences.rst:45 -msgid "VyOS `vyos.vyos `_" -msgstr "VyOS `vyos.vyos `_" - -#: ../../rst/network/getting_started/network_differences.rst:47 -msgid "All modules within a network platform share certain requirements. Some network platforms have specific differences - see the :ref:`platform-specific ` documentation for details." -msgstr "ネットワークプラットフォーム内のすべてのモジュールは特定の要件を共有します。ネットワークプラットフォームによっては、特定の相違点があります。詳細は、:ref:`platform-specific ` ドキュメントを参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:52 -msgid "Privilege Escalation: ``enable`` mode, ``become``, and ``authorize``" -msgstr "特権エスカレーション: ``enable`` モード、``become``、および ``authorize``" - -#: ../../rst/network/getting_started/network_differences.rst:54 -msgid "Several network platforms support privilege escalation, where certain tasks must be done by a privileged user. On network devices this is called the ``enable`` mode (the equivalent of ``sudo`` in \\*nix administration). Ansible network modules offer privilege escalation for those network devices that support it. For details of which platforms support ``enable`` mode, with examples of how to use it, see the :ref:`platform-specific ` documentation." -msgstr "一部のネットワークプラットフォームでは特権エスカレーションがサポートされており、特権を持つユーザーが特定のタスクを実行する必要があります。ネットワークデバイスでは、これを ``enable`` モードと呼びます (\\*nix 管理における ``sudo`` と同等)。Ansible ネットワークモジュールは、それをサポートするネットワークデバイスに特権エスカレーションを提供します。``enable`` モードをサポートプラットフォームとその使用例については、:ref:`platform-specific ` ドキュメントを参照してください。" - -#: ../../rst/network/getting_started/network_differences.rst:57 -msgid "Using ``become`` for privilege escalation" -msgstr "権限昇格に ``become`` を使用" - -#: ../../rst/network/getting_started/network_differences.rst:59 -msgid "Use the top-level Ansible parameter ``become: yes`` with ``become_method: enable`` to run a task, play, or playbook with escalated privileges on any network platform that supports privilege escalation. You must use either ``connection: network_cli`` or ``connection: httpapi`` with ``become: yes`` with ``become_method: enable``. If you are using ``network_cli`` to connect Ansible to your network devices, a ``group_vars`` file would look like:" -msgstr "特権昇格をサポートする任意のネットワークプラットフォームで、昇格された特権を使用してタスク、プレイ、または Playbook を実行するには、``become_method: enable`` の Ansible 最上位パラメーター ``become: yes`` を使用します。``connection: network_cli`` または ``connection: httpapi`` を、``become: yes`` と ``become_method: enable`` とともに使用する必要があります。``network_cli`` を使用して Ansible をネットワークデバイスに接続している場合、``group_vars`` ファイルは次のようになります。" - -#: ../../rst/network/getting_started/network_differences.rst:68 -msgid "For more information, see :ref:`Become and Networks`" -msgstr "詳細情報は、「:ref:`Become およびネットワーク`」を参照してください。" - -#: ../../rst/network/getting_started/network_resources.rst:6 -msgid "Resources and next steps" -msgstr "リソースと次のステップ" - -#: ../../rst/network/getting_started/network_resources.rst:12 -msgid "Documents" -msgstr "ドキュメント" - -#: ../../rst/network/getting_started/network_resources.rst:14 -msgid "Read more about Ansible for Network Automation:" -msgstr "ネットワーク自動化での Ansible の詳細は、次を参照してください。" - -#: ../../rst/network/getting_started/network_resources.rst:16 -msgid ":ref:`Network Platform Options `" -msgstr ":ref:`Network Platform Options `" - -#: ../../rst/network/getting_started/network_resources.rst:17 -msgid "Network Automation on the `Ansible website `_" -msgstr "`Ansible Web サイト `_ 上のネットワーク自動化" - -#: ../../rst/network/getting_started/network_resources.rst:18 -msgid "Ansible Network `Blog posts `_" -msgstr "Ansible ネットワークの `ブログ投稿 `_" - -#: ../../rst/network/getting_started/network_resources.rst:21 -msgid "Events (on video and in person)" -msgstr "イベント (ビデオおよび個人)" - -#: ../../rst/network/getting_started/network_resources.rst:23 -msgid "All sessions at Ansible events are recorded and include many Network-related topics (use Filter by Category to view only Network topics). You can also join us for future events in your area. See:" -msgstr "Ansible イベントにおけるセッションはすべて録画されており、ネットワーク関連のトピックが多数含まれています (「Filter by Category」を使用して、ネットワークトピックのみを表示します)。また、お住まいの地域で今後開催されるイベントにもご参加いただけます。以下を参照してください。" - -#: ../../rst/network/getting_started/network_resources.rst:25 -msgid "`Recorded AnsibleFests `_" -msgstr "`Recorded AnsibleFests `_" - -#: ../../rst/network/getting_started/network_resources.rst:26 -msgid "`Recorded AnsibleAutomates `_" -msgstr "`Recorded AnsibleAutomates `_" - -#: ../../rst/network/getting_started/network_resources.rst:27 -msgid "`Upcoming Ansible Events `_ page." -msgstr "`今後の Ansible イベント `_ ページ。" - -#: ../../rst/network/getting_started/network_resources.rst:30 -msgid "GitHub repos" -msgstr "GitHub リポジトリー" - -#: ../../rst/network/getting_started/network_resources.rst:32 -msgid "Ansible hosts module code, examples, demonstrations, and other content on GitHub. Anyone with a GitHub account is able to create Pull Requests (PRs) or issues on these repos:" -msgstr "Ansible では、モジュールのコード、サンプル、デモンストレーション、その他のコンテンツを GitHub で公開しています。GitHub のアカウントをお持ちの方は、これらのリポジトリーにプル要求 (PR) や問題を作成することができます。" - -#: ../../rst/network/getting_started/network_resources.rst:34 -msgid "`Network-Automation `_ is an open community for all things network automation. Have an idea, some playbooks, or roles to share? Email ansible-network@redhat.com and we will add you as a contributor to the repository." -msgstr "`Network-Automation `_ は、ネットワーク自動化に関するあらゆることを扱うオープンコミュニティーです。アイディア、Playbook、またはロールを共有しませんか。ansible-network@redhat.com にメールでお問い合わせいただければ、リポジトリーに貢献者として追加されます。" - -#: ../../rst/network/getting_started/network_resources.rst:36 -msgid "`Ansible collections `_ is the main repository for Ansible-maintained and community collections, including collections for network devices." -msgstr "`Ansible コレクション `_ は、Ansible が管理しているコレクションおよびコミュニティーコレクションの主なリポジトリーです。これにはネットワークデバイスのコレクションが含まれます。" - -#: ../../rst/network/getting_started/network_resources.rst:41 -msgid "Chat channels" -msgstr "チャットチャネル" - -#: ../../rst/network/getting_started/network_resources.rst:43 -msgid "Got questions? Chat with us on:" -msgstr "質問がありますか？以下からチャットをご利用ください：" - -#: ../../rst/network/getting_started/network_resources.rst:45 -msgid "the ``#ansible-network`` channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)" -msgstr "``#ansible-network`` チャットチャンネル（ansible.im の表を使用するか、`irc.libera.chat `_ で IRC を使用）" - -#: ../../rst/network/getting_started/network_resources.rst:47 -msgid "`Ansible Network Slack `_ - Network & Security Automation Slack community. Check out the #devel channel for discussions on module and plugin development." -msgstr "`Ansible Network Slack `_ - ネットワークおよびセキュリティー自動化の Slack コミュニティー。モジュールおよびプラグインの開発に関する内容は、#devel チャンネルを確認してください。" - -#: ../../rst/network/getting_started/network_roles.rst:6 -msgid "Use Ansible network roles" -msgstr "Ansible ネットワークロールの使用" - -#: ../../rst/network/getting_started/network_roles.rst:8 -msgid "Roles are sets of Ansible defaults, files, tasks, templates, variables, and other Ansible components that work together. As you saw on :ref:`first_network_playbook`, moving from a command to a playbook makes it easy to run multiple tasks and repeat the same tasks in the same order. Moving from a playbook to a role makes it even easier to reuse and share your ordered tasks. You can look at :ref:`Ansible Galaxy `, which lets you share your roles and use others' roles, either directly or as inspiration." -msgstr "ロールは、Ansible のデフォルト、ファイル、タスク、テンプレート、変数、およびその他の Ansible コンポーネントのセットで、連携して動作します。:ref:`first_network_playbook` でこれまで見てきたように、コマンドから Playbook に移動すると、複数のタスクを簡単に実行し、同じタスクを同じ順序で繰り返すことができます。Playbook からロールに移動すると、注文したタスクの再利用と共有がさらに簡単になります。:ref:`Ansible Galaxy ` では、自分のロールを共有したり、他の人のロールを直接またはインスピレーションとして使用したりできます。" - -#: ../../rst/network/getting_started/network_roles.rst:14 -msgid "Understanding roles" -msgstr "ロールについて" - -#: ../../rst/network/getting_started/network_roles.rst:16 -msgid "So what exactly is a role, and why should you care? Ansible roles are basically playbooks broken up into a known file structure. Moving to roles from a playbook makes sharing, reading, and updating your Ansible workflow easier. Users can write their own roles. So for example, you don't have to write your own DNS playbook. Instead, you specify a DNS server and a role to configure it for you." -msgstr "では、ロールとは正確には何なのか、そしてなぜそれが必要なのでしょうか。Ansible ロールは基本的に、既知のファイル構造に分割された Playbook です。Playbook からロールに移動することで、Ansible ワークフローの共有、読み取り、および更新が簡単になります。ユーザーは独自のロールを作成できます。たとえば、独自の DNS Playbook を作成する必要はありません。代わりに、DNS サーバーと、DNS サーバーを構成するロールを指定します。" - -#: ../../rst/network/getting_started/network_roles.rst:18 -msgid "To simplify your workflow even further, the Ansible Network team has written a series of roles for common network use cases. Using these roles means you don't have to reinvent the wheel. Instead of writing and maintaining your own ``create_vlan`` playbooks or roles, you can concentrate on designing, codifying and maintaining the parser templates that describe your network topologies and inventory, and let Ansible's network roles do the work. See the `network-related roles `_ on Ansible Galaxy." -msgstr "ワークフローをさらに単純化するために、Ansible Network チームは一般的なネットワークのユースケースのための一連のロールを作成しました。これらのロールを使用すると、車輪を再発明する必要がなくなります。独自の ``create_vlan`` Playbook やロールを作成して管理する代わりに、Ansible のネットワークロールにその作業を任せることで、ネットワークトポロジーやインベントリーを記述するパーサーテンプレートの設計、コード化、および管理に集中することができます。Ansible Galaxyの「`ネットワーク関連のロール `_」を見てください。" - -#: ../../rst/network/getting_started/network_roles.rst:21 -msgid "A sample DNS playbook" -msgstr "DNS Playbook のサンプル" - -#: ../../rst/network/getting_started/network_roles.rst:23 -msgid "To demonstrate the concept of what a role is, the example ``playbook.yml`` below is a single YAML file containing a two-task playbook. This Ansible Playbook configures the hostname on a Cisco IOS XE device, then it configures the DNS (domain name system) servers." -msgstr "ロールの概念を説明するために、下記の例 ``playbook.yml`` は 2 つのタスクの Playbook を含む 1 つの YAML ファイルです。この Ansible Playbook は、Cisco IOS XE デバイスでホスト名を設定してから、DNS (ドメインネームシステム) サーバーを設定します。" - -#: ../../rst/network/getting_started/network_roles.rst:44 -msgid "If you run this playbook using the ``ansible-playbook`` command, you'll see the output below. This example used ``-l`` option to limit the playbook to only executing on the **rtr1** node." -msgstr "``ansible-playbook`` コマンドを使用してこの Playbook を実行する場合は、以下の出力が表示されます。この例では、``-l`` オプションを使用して Playbook を **rtr1** ノード上でのみ実行するように制限しています。" - -#: ../../rst/network/getting_started/network_roles.rst:62 -msgid "This playbook configured the hostname and DNS servers. You can verify that configuration on the Cisco IOS XE **rtr1** router:" -msgstr "この Playbook はホスト名および DNS サーバーを設定し、Cisco IOS XE **rtr1** ルーターの設定を確認できます。" - -#: ../../rst/network/getting_started/network_roles.rst:71 -msgid "Convert the playbook into a role" -msgstr "Playbook のロールへの変換" - -#: ../../rst/network/getting_started/network_roles.rst:73 -msgid "The next step is to convert this playbook into a reusable role. You can create the directory structure manually, or you can use ``ansible-galaxy init`` to create the standard framework for a role." -msgstr "次の手順では、この Playbook を再利用可能なロールに変換します。ディレクトリー構造を手動で作成するか、``ansible-galaxy init`` を使用してロールの標準フレームワークを作成できます。" - -#: ../../rst/network/getting_started/network_roles.rst:98 -msgid "This first demonstration uses only the **tasks** and **vars** directories. The directory structure would look as follows:" -msgstr "この最初のデモンストレーションは **tasks** ディレクトリーおよび **vars** ディレクトリーのみを使用します。ディレクトリー構造は以下のようになります。" - -#: ../../rst/network/getting_started/network_roles.rst:109 -msgid "Next, move the content of the ``vars`` and ``tasks`` sections from the original Ansible Playbook into the role. First, move the two tasks into the ``tasks/main.yml`` file:" -msgstr "次に、元の Ansible Playbook から ``vars`` セクションおよび ``tasks`` セクションの内容をロールに移動します。まず、2 つのタスクを ``tasks/main.yml`` ファイルに移動します。" - -#: ../../rst/network/getting_started/network_roles.rst:123 -msgid "Next, move the variables into the ``vars/main.yml`` file:" -msgstr "次に、変数を ``vars/main.yml`` ファイルに移動します。" - -#: ../../rst/network/getting_started/network_roles.rst:131 -msgid "Finally, modify the original Ansible Playbook to remove the ``tasks`` and ``vars`` sections and add the keyword ``roles`` with the name of the role, in this case ``system-demo``. You'll have this playbook:" -msgstr "最後に、元の Ansible Playbook を変更して ``tasks`` セクションおよび ``vars`` セクションを削除し、ロールの名前 (ここでは ``system-demo``) でキーワード ``roles`` を追加します。これで、Playbook が完成します。" - -#: ../../rst/network/getting_started/network_roles.rst:144 -msgid "To summarize, this demonstration now has a total of three directories and three YAML files. There is the ``system-demo`` folder, which represents the role. This ``system-demo`` contains two folders, ``tasks`` and ``vars``. There is a ``main.yml`` is each respective folder. The ``vars/main.yml`` contains the variables from ``playbook.yml``. The ``tasks/main.yml`` contains the tasks from ``playbook.yml``. The ``playbook.yml`` file has been modified to call the role rather than specifying vars and tasks directly. Here is a tree of the current working directory:" -msgstr "要約すると、このデモには合計 3 つのディレクトリーと 3 つの YAML ファイルがあります。ロールを表す ``system-demo`` ディレクトリーがあります。この ``system-demo`` には、``tasks`` および ``vars`` の 2 つのディレクトリーが含まれています。各ディレクトリーに ``main.yml`` があります。``vars/main.yml`` には、``playbook.yml`` の変数が含まれます。``tasks/main.yml`` には、``playbook.yml`` のタスクが含まれます。``playbook.yml`` ファイルは、変数とタスクを直接指定するのではなく、ロールを呼び出すように変更されています。現在の作業ディレクトリーのツリーを次に示します。" - -#: ../../rst/network/getting_started/network_roles.rst:157 -msgid "Running the playbook results in identical behavior with slightly different output:" -msgstr "Playbook を実行すると、同じ動作で、出力が若干異なります。" - -#: ../../rst/network/getting_started/network_roles.rst:174 -msgid "As seen above each task is now prepended with the role name, in this case ``system-demo``. When running a playbook that contains several roles, this will help pinpoint where a task is being called from. This playbook returned ``ok`` instead of ``changed`` because it has identical behavior for the single file playbook we started from." -msgstr "上記のように、各タスクの先頭にロール名が付加されます (``system-demo`` の場合)。複数のロールを含む Playbook を実行する場合、タスクの呼び出し元を特定するのに役立ちます。このPlaybook は、``changed`` ではなく ``ok`` を返しますが、これは、開始した単一ファイルの Playbook と同じ動作をするためです。" - -#: ../../rst/network/getting_started/network_roles.rst:176 -msgid "As before, the playbook will generate the following configuration on a Cisco IOS-XE router:" -msgstr "前述のように、Playbook は Cisco IOS-XE ルーターで以下の設定を生成します。" - -#: ../../rst/network/getting_started/network_roles.rst:185 -msgid "This is why Ansible roles can be simply thought of as deconstructed playbooks. They are simple, effective and reusable. Now another user can simply include the ``system-demo`` role instead of having to create a custom \"hard coded\" playbook." -msgstr "このため、Ansible ロールは、簡単に言えば、分解された Playbook と考えることができます。ロールは、シンプルで、効果的で、再利用可能です。これで、別のユーザーがカスタムの「ハードコーディングされた」Playbook を作成する代わりに、``system-demo`` ロールを含めるだけで十分となります。" - -#: ../../rst/network/getting_started/network_roles.rst:188 -msgid "Variable precedence" -msgstr "変数の優先順位" - -#: ../../rst/network/getting_started/network_roles.rst:190 -msgid "What if you want to change the DNS servers? You aren't expected to change the ``vars/main.yml`` within the role structure. Ansible has many places where you can specify variables for a given play. See :ref:`playbooks_variables` for details on variables and precedence. There are actually 21 places to put variables. While this list can seem overwhelming at first glance, the vast majority of use cases only involve knowing the spot for variables of least precedence and how to pass variables with most precedence. See :ref:`ansible_variable_precedence` for more guidance on where you should put variables." -msgstr "DNS サーバーを変更する場合はどうすればよいですか。ロール構造内の ``vars/main.yml`` を変更する必要はありません。Ansible には、特定のプレイの変数を指定できる場所が多数あります。変数と優先順位の詳細は、「:ref:`playbooks_variables`」を参照してください。変数を置く場所は実際には 21 箇所あります。これは一見圧倒されるような数ですが、大半のユースケースでは、優先順位が最も低い変数の場所と、最も優先順位の高い変数を渡す方法を知るだけですみます。変数をどこに置くべきかは、「:ref:`ansible_variable_precedence`」を参照してください。" - -#: ../../rst/network/getting_started/network_roles.rst:193 -msgid "Lowest precedence" -msgstr "最も低い優先順位" - -#: ../../rst/network/getting_started/network_roles.rst:195 -msgid "The lowest precedence is the ``defaults`` directory within a role. This means all the other 20 locations you could potentially specify the variable will all take higher precedence than ``defaults``, no matter what. To immediately give the vars from the ``system-demo`` role the least precedence, rename the ``vars`` directory to ``defaults``." -msgstr "最も低い優先順位は、ロール内の ``defaults`` ディレクトリーです。つまり、変数を指定できる可能性のある他の 20 箇所はすべて、``defaults`` より優先されます。``system-demo`` ロールの変数の優先順位を直ちに最も低くするには、``vars`` ディレクトリーの名前を ``defaults`` に変更します。" - -#: ../../rst/network/getting_started/network_roles.rst:207 -msgid "Add a new ``vars`` section to the playbook to override the default behavior (where the variable ``dns`` is set to 8.8.8.8 and 8.8.4.4). For this demonstration, set ``dns`` to 1.1.1.1, so ``playbook.yml`` becomes:" -msgstr "デフォルトの動作を上書きするために、Playbook に新しい ``vars`` セクションを追加します (ここでは、``dns`` 変数が 8.8.8.8 および 8.8.4.4 に設定されています)。このデモでは、``dns`` を 1.1.1.1 に設定するため、``playbook.yml`` は次のようになります。" - -#: ../../rst/network/getting_started/network_roles.rst:221 -msgid "Run this updated playbook on **rtr2**:" -msgstr "更新した Playbook を **rtr2** で実行します。" - -#: ../../rst/network/getting_started/network_roles.rst:227 -msgid "The configuration on the **rtr2** Cisco router will look as follows:" -msgstr "**rtr2** Cisco ルーターの設定は以下のようになります。" - -#: ../../rst/network/getting_started/network_roles.rst:234 -msgid "The variable configured in the playbook now has precedence over the ``defaults`` directory. In fact, any other spot you configure variables would win over the values in the ``defaults`` directory." -msgstr "Playbook に設定した変数は、``defaults`` ディレクトリーよりも優先されます。実際には、変数に設定したその他のスポットは、``defaults`` ディレクトリーの値よりも優先されます。" - -#: ../../rst/network/getting_started/network_roles.rst:237 -msgid "Highest precedence" -msgstr "最も高い優先順位" - -#: ../../rst/network/getting_started/network_roles.rst:239 -msgid "Specifying variables in the ``defaults`` directory within a role will always take the lowest precedence, while specifying ``vars`` as extra vars with the ``-e`` or ``--extra-vars=`` will always take the highest precedence, no matter what. Re-running the playbook with the ``-e`` option overrides both the ``defaults`` directory (8.8.4.4 and 8.8.8.8) as well as the newly created ``vars`` within the playbook that contains the 1.1.1.1 dns server." -msgstr "ロール内の ``defaults`` ディレクトリーに変数を指定すると、常に優先順位が最も低くなりますが、``-e`` または ``--extra-vars=`` を使用して追加変数として ``vars`` を指定すると、優先順位が最も高くなります。``-e`` オプションを指定して Playbook を再実行すると、``defaults`` ディレクトリー (8.8.4.4 および 8.8.8.8) だけでなく、1.1.1.1 dns サーバーを含む Playbook 内に新しく作成された ``vars`` も上書きされます。" - -#: ../../rst/network/getting_started/network_roles.rst:245 -msgid "The result on the Cisco IOS XE router will only contain the highest precedence setting of 192.168.1.1:" -msgstr "Cisco IOS XE ルーターの結果には、優先順位の最も高い 192.168.1.1 設定のみが含まれます。" - -#: ../../rst/network/getting_started/network_roles.rst:252 -msgid "How is this useful? Why should you care? Extra vars are commonly used by network operators to override defaults. A powerful example of this is with the Job Template Survey feature on AWX or the :ref:`ansible_platform`. It is possible through the web UI to prompt a network operator to fill out parameters with a Web form. This can be really simple for non-technical playbook writers to execute a playbook using their Web browser." -msgstr "これはどのように役立つのでしょうか。なぜ気にする必要があるのでしょうか。ネットワークオペレーターは通常、追加の変数を使用してデフォルトを上書きします。これに関する適切な例は、AWX の Job Template Suvey 機能または :ref:`ansible_platform` です。Web UI を使用して、ネットワークオペレーターに Web フォームでパラメーターの入力を求めることができます。これは、技術に詳しくない Playbook 作成者が Web ブラウザーを使用して Playbook を実行する場合に非常に簡単です。" - -#: ../../rst/network/getting_started/network_roles.rst:256 -msgid "Update an installed role" -msgstr "インストールされたロールの更新" - -#: ../../rst/network/getting_started/network_roles.rst:258 -msgid "The Ansible Galaxy page for a role lists all available versions. To update a locally installed role to a new or different version, use the ``ansible-galaxy install`` command with the version and ``--force`` option. You may also need to manually update any dependent roles to support this version. See the role **Read Me** tab in Galaxy for dependent role minimum version requirements." -msgstr "ロールの Ansible Galaxy ページには、使用可能なすべてのバージョンが一覧表示されます。ローカルにインストールされたロールを新しいバージョンまたは別のバージョンに更新するには、``ansible-galaxy install`` コマンドにバージョンおよび ``--force`` オプションを指定して使用します。また、このバージョンをサポートするために、依存ロールを手動で更新しないといけない場合もあります。依存ロールの最小バージョン要件については、Galaxy のロールの「Read Me」タブを参照してください。" - -#: ../../rst/network/getting_started/network_roles.rst:266 -msgid "`Ansible Galaxy documentation `_" -msgstr "`Ansible Galaxy documentation `_" - -#: ../../rst/network/getting_started/network_roles.rst:267 -msgid "Ansible Galaxy user guide" -msgstr "Ansible Galaxy ユーザーガイド" - -#: ../../rst/network/index.rst:7 -msgid "Ansible for Network Automation" -msgstr "ネットワークの自動化における Ansible" - -#: ../../rst/network/index.rst:9 -msgid "Ansible Network modules extend the benefits of simple, powerful, agentless automation to network administrators and teams. Ansible Network modules can configure your network stack, test and validate existing network state, and discover and correct network configuration drift." -msgstr "Ansible Network モジュールは、シンプルで強力なエージェントレス自動化の利点をネットワーク管理者とチームに拡張します。Ansible Network モジュールは、ネットワークスタックを構成し、既存のネットワーク状態をテストおよび検証し、ネットワーク構成のドリフトを検出して修正できます。" - -#: ../../rst/network/index.rst:11 -msgid "If you're new to Ansible, or new to using Ansible for network management, start with :ref:`network_getting_started`. If you are already familiar with network automation with Ansible, see :ref:`network_advanced`." -msgstr "Ansible を初めて使用する場合や、ネットワーク管理に Ansible を初めて使用する場合は、:ref:`network_getting_started` から開始します。Ansible とのネットワーク自動化に精通している場合は、「:ref:`network_advanced`」を参照してください。" - -#: ../../rst/network/index.rst:13 -msgid "For documentation on using a particular network module, consult the :ref:`list of all network modules`. Network modules for various hardware are supported by different teams including the hardware vendors themselves, volunteers from the Ansible community, and the Ansible Network Team." -msgstr "特定のネットワークモジュールの使用に関するドキュメントについては、「:ref:`ネットワークモジュールの一覧`」を参照してください。さまざまなハードウェアのネットワークモジュールが、ハードウェアベンダー自体、Ansible コミュニティーのボランティア、Ansible ネットワークチームなど、さまざまなチームにサポートされています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:5 -msgid "Parsing semi-structured text with Ansible" -msgstr "Ansible を使用した半構造化テキストの解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:7 -msgid "The :ref:`cli_parse ` module parses semi-structured data such as network configurations into structured data to allow programmatic use of the data from that device. You can pull information from a network device and update a CMDB in one playbook. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on." -msgstr ":ref:`cli_parse ` モジュールは、ネットワーク構成などの半構造化データを構造化データに解析して、そのデバイスからのデータをプログラムで使用できるようにします。ネットワークデバイスから情報を取得し、1 つの Playbook で CMDB を更新できます。ユースケースには、自動トラブルシューティング、動的ドキュメントの作成、IPAM (IPアドレス管理) ツールの更新などがあります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:15 -msgid "Understanding the CLI parser" -msgstr "CLI パーサーについて" - -#: ../../rst/network/user_guide/cli_parsing.rst:17 -msgid "The `ansible.utils `_ collection version 1.0.0 or later includes the :ref:`cli_parse ` module that can run CLI commands and parse the semi-structured text output. You can use the ``cli_parse`` module on a device, host, or platform that only supports a command-line interface and the commands issued return semi-structured text. The ``cli_parse`` module can either run a CLI command on a device and return a parsed result or can simply parse any text document. The ``cli_parse`` module includes cli_parser plugins to interface with a variety of parsing engines." -msgstr "`ansible.utils `_ コレクションバージョン 1.0.0 以降には、CLI コマンドを実行し、半構造化テキスト出力を解析できる :ref:`cli_parse ` モジュールが含まれています。コマンドラインインタフェースのみをサポートするデバイス、ホスト、またはプラットフォームで ``cli_parse`` モジュールを使用でき、実行したコマンドは半構造化テキストを返します。``cli_parse`` モジュールは、デバイス上で CLI コマンドを実行して解析結果を返すことも、単純にテキストドキュメントを解析することもできます。``cli_parse`` モジュールには、さまざまな解析エンジンとのインタフェースとなる cli_parser プラグインが含まれています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:20 -msgid "Why parse the text?" -msgstr "テキストを解析する理由" - -#: ../../rst/network/user_guide/cli_parsing.rst:22 -msgid "Parsing semi-structured data such as network configurations into structured data allows programmatic use of the data from that device. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. You may prefer to do this with Ansible natively to take advantage of native Ansible constructs such as:" -msgstr "ネットワーク構成などの半構造化データを構造化データに解析すると、そのデバイスのデータをプログラムで使用できます。ユースケースには、自動トラブルシューティング、動的ドキュメントの作成、IPAM (IPアドレス管理) ツールの更新などがあります。このような作業は、Ansible でネイティブに行う方が、以下のような Ansible のネイティブな構成を活用できるかもしれません。" - -#: ../../rst/network/user_guide/cli_parsing.rst:24 -msgid "The ``when`` clause to conditionally run other tasks or roles" -msgstr "他のタスクまたはロールを条件的に実行する ``when`` 句" - -#: ../../rst/network/user_guide/cli_parsing.rst:25 -msgid "The ``assert`` module to check configuration and operational state compliance" -msgstr "設定と運用状態コンプライアンスを確認するための ``assert`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:26 -msgid "The ``template`` module to generate reports about configuration and operational state information" -msgstr "設定および運用の状態情報に関するレポートを生成する ``template`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:27 -msgid "Templates and ``command`` or ``config`` modules to generate host, device, or platform commands or configuration" -msgstr "ホスト、デバイス、またはプラットフォームコマンドまたは設定を生成するテンプレートおよび ``command`` モジュールまたは ``config`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:28 -msgid "The current platform ``facts`` modules to supplement native facts information" -msgstr "ネイティブファクト情報を補足する現在のプラットフォームの ``facts`` モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:30 -msgid "By parsing semi-structured text into Ansible native data structures, you can take full advantage of Ansible's network modules and plugins." -msgstr "半構造化テキストを Ansible のネイティブデータ構造に解析することで、Ansible のネットワークモジュールおよびプラグインを完全に活用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:34 -msgid "When not to parse the text" -msgstr "テキストを解析しない場合" - -#: ../../rst/network/user_guide/cli_parsing.rst:36 -msgid "You should not parse semi-structured text when:" -msgstr "以下の場合は、半構造化されたテキストを解析しないでください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:38 -msgid "The device, host, or platform has a RESTAPI and returns JSON." -msgstr "デバイス、ホスト、またはプラットフォームには RESTAPI があり、JSON を返します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:39 -msgid "Existing Ansible facts modules already return the desired data." -msgstr "既存の Ansible ファクトモジュールは、すでに必要なデータを返しています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:40 -msgid "Ansible network resource modules exist for configuration management of the device and resource." -msgstr "デバイスおよびリソースの設定管理には、Ansible ネットワークリソースモジュールがあります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:43 -msgid "Parsing the CLI" -msgstr "CLI の解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:45 -msgid "The ``cli_parse`` module includes the following cli_parsing plugins:" -msgstr "``cli_parse`` モジュールには、以下の cli_parsing プラグインが含まれます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:47 -msgid "``native``" -msgstr "``native``" - -#: ../../rst/network/user_guide/cli_parsing.rst:48 -msgid "The native parsing engine built into Ansible and requires no addition python libraries" -msgstr "Ansible に組み込まれたネイティブの解析エンジンで、Python ライブラリーを追加する必要はありません。" - -#: ../../rst/network/user_guide/cli_parsing.rst:49 -msgid "``xml``" -msgstr "``xml``" - -#: ../../rst/network/user_guide/cli_parsing.rst:50 -msgid "Convert XML to an Ansible native data structure" -msgstr "XML の Ansible ネイティブデータ構造への変換" - -#: ../../rst/network/user_guide/cli_parsing.rst:51 -msgid "``textfsm``" -msgstr "``textfsm``" - -#: ../../rst/network/user_guide/cli_parsing.rst:52 -msgid "A python module which implements a template based state machine for parsing semi-formatted text" -msgstr "半フォーマット化テキストを解析するためにテンプレートベースの状態マシンを実装する Python モジュール" - -#: ../../rst/network/user_guide/cli_parsing.rst:53 -msgid "``ntc_templates``" -msgstr "``ntc_templates``" - -#: ../../rst/network/user_guide/cli_parsing.rst:54 -msgid "Predefined ``textfsm`` templates packages supporting a variety of platforms and commands" -msgstr "さまざまなプラットフォームおよびコマンドをサポートする事前定義された ``textfsm`` テンプレートパッケージ" - -#: ../../rst/network/user_guide/cli_parsing.rst:55 -msgid "``ttp``" -msgstr "``ttp``" - -#: ../../rst/network/user_guide/cli_parsing.rst:56 -msgid "A library for semi-structured text parsing using templates, with added capabilities to simplify the process" -msgstr "処理を簡略化する機能が追加されている、テンプレートを利用した半構造化テキストの解析用ライブラリー" - -#: ../../rst/network/user_guide/cli_parsing.rst:57 -msgid "``pyats``" -msgstr "``pyats``" - -#: ../../rst/network/user_guide/cli_parsing.rst:58 -msgid "Uses the parsers included with the Cisco Test Automation & Validation Solution" -msgstr "Cisco Test Automation & Validation Solution に含まれるパーサーを使用します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:59 -msgid "``jc``" -msgstr "``jc``" - -#: ../../rst/network/user_guide/cli_parsing.rst:60 -msgid "A python module that converts the output of dozens of popular Linux/UNIX/macOS/Windows commands and file types to python dictionaries or lists of dictionaries. Note: this filter plugin can be found in the ``community.general`` collection." -msgstr "多数の一般的な Linux/UNIX/macOS/Windows コマンドとファイルタイプの出力を python ディクショナリーまたはディクショナリーの一覧に変換する Python モジュール。このフィルタープラグインは ``community.general`` コレクションにあります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:62 -msgid "``json``" -msgstr "``json``" - -#: ../../rst/network/user_guide/cli_parsing.rst:62 -msgid "Converts JSON output at the CLI to an Ansible native data structure" -msgstr "CLI での JSON 出力を Ansible ネイティブデータ構造に変換" - -#: ../../rst/network/user_guide/cli_parsing.rst:64 -#: ../../rst/network/user_guide/cli_parsing.rst:614 -msgid "Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task." -msgstr "Ansible には、XML を Ansible のネイティブデータ構造に変換できる多数のプラグインが含まれていますが、``cli_parse`` モジュールは XML を返すデバイスでコマンドを実行し、変換されたデータを 1 つのタスクで返します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:66 -msgid "Because ``cli_parse`` uses a plugin based architecture, it can use additional parsing engines from any Ansible collection." -msgstr "``cli_parse`` はプラグインベースのアーキテクチャーを使用するため、任意の Ansible コレクションから追加の解析エンジンを使用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:70 -msgid "The ``ansible.netcommon.native`` and ``ansible.utils.json`` parsing engines are fully supported with a Red Hat Ansible Automation Platform subscription. Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates``, pyATS, ``textfsm``, ``xmltodict``, public APIs as documented." -msgstr "解析エンジン ``ansible.netcommon.native`` および ``ansible.utils.json`` は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。Red Hat Ansible Automation Platform サブスクリプションのサポートは、ドキュメントに記載されているように、``ntc_templates``、pyATS、``textfsm``、``xmltodict``、パブリック APIの使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:73 -msgid "Parsing with the native parsing engine" -msgstr "ネイティブ解析エンジンを使用した解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:75 -msgid "The native parsing engine is included with the ``cli_parse`` module. It uses data captured using regular expressions to populate the parsed data structure. The native parsing engine requires a YAML template file to parse the command output." -msgstr "ネイティブ解析エンジンは ``cli_parse`` モジュールに含まれています。正規表現を使用して取得されたデータを使用して、解析されたデータ構造を生成します。ネイティブ解析エンジンでは、コマンド出力を解析するために YAML テンプレートファイルが必要です。" - -#: ../../rst/network/user_guide/cli_parsing.rst:78 -msgid "Networking example" -msgstr "ネットワークの例" - -#: ../../rst/network/user_guide/cli_parsing.rst:80 -msgid "This example uses the output of a network device command and applies a native template to produce an output in Ansible structured data format." -msgstr "この例では、ネットワークデバイスコマンドの出力を使用し、ネイティブテンプレートを適用して Ansible 構造のデータ形式で出力を生成します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:82 -msgid "The ``show interface`` command output from the network device looks as follows:" -msgstr "ネットワークデバイスからの ``show interface`` コマンドの出力は以下のようになります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:106 -msgid "Create the native template to match this output and store it as ``templates/nxos_show_interface.yaml``:" -msgstr "この出力に一致するネイティブテンプレートを作成し、これを ``templates/nxos_show_interface.yaml`` として保存します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:136 -msgid "This native parser template is structured as a list of parsers, each containing the following key-value pairs:" -msgstr "このネイティブパーサーテンプレートはパーサーのリストとして構成され、それぞれに以下のキーと値のペアが含まれます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:138 -msgid "``example`` - An example line of the text line to be parsed" -msgstr "``example`` - 解析対象となるテキスト行の一例" - -#: ../../rst/network/user_guide/cli_parsing.rst:139 -msgid "``getval`` - A regular expression using named capture groups to store the extracted data" -msgstr "``getval`` - 展開したデータを保存するために名前付きキャプチャーグループを使用した正規表現" - -#: ../../rst/network/user_guide/cli_parsing.rst:140 -msgid "``result`` - A data tree, populated as a template, from the parsed data" -msgstr "``result`` - 解析されたデータからテンプレートとして生成されたデータツリー" - -#: ../../rst/network/user_guide/cli_parsing.rst:141 -msgid "``shared`` - (optional) The shared key makes the parsed values available to the rest of the parser entries until matched again." -msgstr "``shared`` - (任意) 共有キーは、再一致するまで、残りのパーサーエントリーに解析された値を利用できるようにします。" - -#: ../../rst/network/user_guide/cli_parsing.rst:143 -msgid "The following example task uses ``cli_parse`` with the native parser and the example template above to parse the ``show interface`` command from a Cisco NXOS device:" -msgstr "以下のタスク例では、ネイティブパーサーで ``cli_parse`` と上記のテンプレートのサンプルを使用して、Cisco NXOS デバイスからの ``show interface`` コマンドを解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:154 -#: ../../rst/network/user_guide/cli_parsing.rst:302 -#: ../../rst/network/user_guide/cli_parsing.rst:328 -#: ../../rst/network/user_guide/cli_parsing.rst:388 -#: ../../rst/network/user_guide/cli_parsing.rst:497 -msgid "Taking a deeper dive into this task:" -msgstr "このタスクをより深く掘り下げます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:156 -msgid "The ``command`` option provides the command you want to run on the device or host. Alternately, you can provide text from a previous command with the ``text`` option instead." -msgstr "``command`` オプションは、デバイスまたはホストで実行するコマンドを提供します。代わりに、``text`` オプションを指定して、前のコマンドのテキストを指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:157 -msgid "The ``parser`` option provides information specific to the parser engine." -msgstr "``parser`` オプションは、パーサーエンジンに固有の情報を提供します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:158 -msgid "The ``name`` suboption provides the fully qualified collection name (FQCN) of the parsing engine (``ansible.netcommon.native``)." -msgstr "``name`` サブオプションは、解析エンジン (``ansible.netcommon.native``) の完全修飾コレクション名 (FQCN) を提供します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:159 -msgid "The ``cli_parse`` module, by default, looks for the template in the templates directory as ``{{ short_os }}_{{ command }}.yaml``." -msgstr "デフォルトでは、``cli_parse`` モジュールは、templates ディレクトリーで ``{{ short_os }}_{{ command }}.yaml`` と指定してテンプレートを検索します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:161 -msgid "The ``short_os`` in the template filename is derived from either the host ``ansible_network_os`` or ``ansible_distribution``." -msgstr "テンプレートファイル名の ``short_os`` は、ホストの ``ansible_network_os`` または ``ansible_distribution`` から派生します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:162 -msgid "Spaces in the network or host command are replace with ``_`` in the ``command`` portion of the template filename. In this example, the ``show interfaces`` network CLI command becomes ``show_interfaces`` in the filename." -msgstr "network または host コマンドのスペースは、テンプレートファイル名の ``command`` 部分にある ``_`` に置き換えます。この例では、``show interfaces`` network CLI コマンドはファイル名の ``show_interfaces`` になります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:166 -msgid "``ansible.netcommon.native`` parsing engine is fully supported with a Red Hat Ansible Automation Platform subscription." -msgstr "``ansible.netcommon.native`` エンジンの解析は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:168 -msgid "Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the device based on the now-structured data returned from ``cli_parse``:" -msgstr "このタスクの最後で、``set_fact`` オプションは、``interfaces`` から返された現在構造化されているデータに基づいて、デバイスに以下の ``cli_parse`` ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:186 -msgid "Linux example" -msgstr "Linux の例" - -#: ../../rst/network/user_guide/cli_parsing.rst:188 -msgid "You can also use the native parser to run commands and parse output from Linux hosts." -msgstr "ネイティブパーサーを使用してコマンドを実行し、Linux ホストからの出力を解析することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:190 -msgid "The output of a sample Linux command (``ip addr show``) looks as follows:" -msgstr "Linux コマンドの出力例 (``ip addr show``) は以下のようになります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:205 -msgid "Create the native template to match this output and store it as ``templates/fedora_ip_addr_show.yaml``:" -msgstr "この出力に一致するネイティブテンプレートを作成し、これを ``templates/fedora_ip_addr_show.yaml`` として保存します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:243 -msgid "The ``shared`` key in the parser template allows the interface name to be used in subsequent parser entries. The use of examples and free-spacing mode with the regular expressions makes the template easier to read." -msgstr "パーサーテンプレートの ``shared`` キーを使用すると、インターフェース名を後続のパーサーエントリーで使用できます。正規表現で例とフリースペースモードを使用すると、テンプレートが読みやすくなります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:245 -msgid "The following example task uses ``cli_parse`` with the native parser and the example template above to parse the Linux output:" -msgstr "以下のタスク例では、ネイティブパーサーのある ``cli_parse`` と、上記のサンプルテンプレートを使用して Linux の出力を解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:256 -msgid "This task assumes you previously gathered facts to determine the ``ansible_distribution`` needed to locate the template. Alternately, you could provide the path in the ``parser/template_path`` option." -msgstr "このタスクでは、以前にファクトを収集してテンプレートを見つけるのに必要な ``ansible_distribution`` を決定することを仮定しています。あるいは、``parser/template_path`` オプションでパスを指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:259 -msgid "Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the host, based on the now-structured data returned from ``cli_parse``:" -msgstr "このタスクの最後で、``set_fact`` オプションは、``interfaces`` から返された現在構造化されているデータに基づいて、ホストに以下の ``cli_parse`` ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:287 -msgid "Parsing JSON" -msgstr "JSON の解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:289 -msgid "Although Ansible will natively convert serialized JSON to Ansible native data when recognized, you can also use the ``cli_parse`` module for this conversion." -msgstr "Ansible は、認識時にシリアライズされた JSON を Ansible ネイティブデータに変換しますが、この変換に ``cli_parse`` モジュールを使用することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:291 -#: ../../rst/network/user_guide/cli_parsing.rst:317 -#: ../../rst/network/user_guide/cli_parsing.rst:376 -msgid "Example task:" -msgstr "タスクの例:" - -#: ../../rst/network/user_guide/cli_parsing.rst:304 -msgid "The ``show interface | json`` command is issued on the device." -msgstr "``show interface | json`` コマンドはデバイスで発行されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:305 -msgid "The output is set as the ``interfaces`` fact for the device." -msgstr "この出力は、デバイスの ``interfaces`` ファクトとして設定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:306 -msgid "JSON support is provided primarily for playbook consistency." -msgstr "JSON のサポートは、主に Playbook の一貫性のために提供されています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:310 -msgid "The use of ``ansible.netcommon.json`` is fully supported with a Red Hat Ansible Automation Platform subscription" -msgstr "``ansible.netcommon.json`` の使用は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:313 -msgid "Parsing with ntc_templates" -msgstr "ntc_templates での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:315 -msgid "The ``ntc_templates`` python library includes pre-defined ``textfsm`` templates for parsing a variety of network device commands output." -msgstr "``ntc_templates`` python ライブラリーには、さまざまなネットワークデバイスコマンドの出力を解析する事前定義済みの ``textfsm`` テンプレートが含まれています。" - -#: ../../rst/network/user_guide/cli_parsing.rst:330 -msgid "The ``ansible_network_os`` of the device is converted to the ntc_template format ``cisco_nxos``. Alternately, you can provide the ``os`` with the ``parser/os`` option instead." -msgstr "デバイスの ``ansible_network_os`` は ntc_template 形式 ``cisco_nxos`` に変換されますが、代わりに ``parser/os`` オプションで ``os`` を指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:331 -msgid "The ``cisco_nxos_show_interface.textfsm`` template, included with the ``ntc_templates`` package, parses the output." -msgstr "``cisco_nxos_show_interface.textfsm`` パッケージに含まれる ``ntc_templates`` テンプレートは、出力を解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:332 -msgid "See `the ntc_templates README `_ for additional information about the ``ntc_templates`` python library." -msgstr "``ntc_templates`` python ライブラリーに関する追加情報は、`ntc_templates の「README」 `_ を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:336 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates`` public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``ntc_templates`` パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:339 -msgid "This task and and the predefined template sets the following fact as the ``interfaces`` fact for the host:" -msgstr "このタスクおよび事前定義されたテンプレートは、以下のファクトをホストの ``interfaces`` ファクトとして設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:372 -msgid "Parsing with pyATS" -msgstr "pyATS での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:374 -msgid "``pyATS`` is part of the Cisco Test Automation & Validation Solution. It includes many predefined parsers for a number of network platforms and commands. You can use the predefined parsers that are part of the ``pyATS`` package with the ``cli_parse`` module." -msgstr "``pyATS`` は、Cisco Test Automation & Validation Solution の一部です。これには、多数のネットワークプラットフォームおよびコマンド用の定義済みパーサーが多数含まれています。``cli_parse`` モジュールでは、``pyATS`` パッケージに同梱される定義済みパーサーを使用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:390 -msgid "The ``cli_parse`` modules converts the ``ansible_network_os`` automatically (in this example, ``ansible_network_os`` set to ``cisco.nxos.nxos``, converts to ``nxos`` for pyATS. Alternately, you can set the OS with the ``parser/os`` option instead." -msgstr "``cli_parse`` モジュールは、自動的に ``ansible_network_os`` を変換します (この例では、``ansible_network_os`` は ``cisco.nxos.nxos`` に設定されていますが、pyATS の場合は ``nxos`` に変換されます。代わりに、``parser/os`` オプションを使用して OS を設定することもできます)。" - -#: ../../rst/network/user_guide/cli_parsing.rst:391 -#, python-format -msgid "Using a combination of the command and OS, the pyATS selects the following parser: https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface." -msgstr "コマンドと OS の組み合わせを使用して、pyATS がパーサー (https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface) を選択します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:392 -msgid "The ``cli_parse`` module sets ``cisco.ios.ios`` to ``iosxe`` for pyATS. You can override this with the ``parser/os`` option." -msgstr "``cli_parse`` モジュールは、pyATS に対して ``cisco.ios.ios`` を ``iosxe`` に設定します。``parser/os`` オプションでこれを上書きできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:393 -msgid "``cli_parse`` only uses the predefined parsers in pyATS. See the `pyATS documentation `_ and the full list of `pyATS included parsers `_." -msgstr "``cli_parse`` は pyATS の定義済みパーサーのみを使用します。`pyATS ドキュメント `_ と、`pyATS が含まれるパーサー `_ の完全なリストを参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:397 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the pyATS public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションサポートは、文書化されている pyATS パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:400 -#: ../../rst/network/user_guide/cli_parsing.rst:508 -msgid "This task sets the following fact as the ``interfaces`` fact for the host:" -msgstr "このタスクは、ホストの ``interfaces`` ファクトとして以下のファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:438 -msgid "Parsing with textfsm" -msgstr "textfsm で解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:440 -msgid "``textfsm`` is a Python module which implements a template-based state machine for parsing semi-formatted text." -msgstr "``textfsm`` は、半フォーマットのテキストを解析するためにテンプレートベースの状態マシンを実装する Python モジュールです。" - -#: ../../rst/network/user_guide/cli_parsing.rst:442 -msgid "The following sample ``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm``" -msgstr "以下のサンプル ``textfsm`` テンプレートは、``templates/nxos_show_interface.textfsm`` の形式で保存されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:486 -msgid "The following task uses the example template for ``textfsm`` with the ``cli_parse`` module." -msgstr "以下のタスクでは、``textfsm`` モジュールで ``cli_parse`` のサンプルテンプレートを使用します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:499 -msgid "The ``ansible_network_os`` for the device (``cisco.nxos.nxos``) is converted to ``nxos``. Alternately you can provide the OS in the ``parser/os`` option instead." -msgstr "デバイスの ``ansible_network_os`` (``cisco.nxos.nxos``) は ``nxos`` に変換されます。代わりに ``parser/os`` オプションに OS を指定することもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:500 -msgid "The textfsm template name defaulted to ``templates/nxos_show_interface.textfsm`` using a combination of the OS and command run. Alternately you can override the generated template path with the ``parser/template_path`` option." -msgstr "textfsm のテンプレート名は、OS とコマンドランの組み合わせにより、デフォルトで``templates/nxos_show_interface.textfsm`` となっています。また、``parser/template_path`` オプションで、生成されたテンプレートのパスを上書きすることもできます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:501 -msgid "See the `textfsm README `_ for details." -msgstr "詳細は、`textfsm README `_ を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:502 -msgid "``textfsm`` was previously made available as a filter plugin. Ansible users should transition to the ``cli_parse`` module." -msgstr "``textfsm`` は、以前はフィルタープラグインとして利用できました。Ansible ユーザーは、``cli_parse`` モジュールに移行する必要があります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:506 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the ``textfsm`` public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``textfsm`` パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:539 -msgid "Parsing with TTP" -msgstr "TTP での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:541 -msgid "TTP is a Python library for semi-structured text parsing using templates. TTP uses a jinja-like syntax to limit the need for regular expressions. Users familiar with jinja templating may find the TTP template syntax familiar." -msgstr "TTP は、テンプレートを使用した半構造化テキスト解析用の Python ライブラリーです。TTP は、正規表現の必要性を制限するために、jinja に似た構文を使用します。jinja のテンプレート化に精通しているユーザーは、TTP テンプレートの構文に親しみを感じるかもしれません。" - -#: ../../rst/network/user_guide/cli_parsing.rst:543 -msgid "The following is an example TTP template stored as ``templates/nxos_show_interface.ttp``:" -msgstr "以下は、``templates/nxos_show_interface.ttp`` として保存された TTP テンプレートの例です。" - -#: ../../rst/network/user_guide/cli_parsing.rst:550 -msgid "The following task uses this template to parse the ``show interface`` command output:" -msgstr "以下のタスクでは、このテンプレートを使用して ``show interface`` コマンドの出力を解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:561 -msgid "Taking a deeper dive in this task:" -msgstr "このタスクをより深く掘り下げます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:563 -msgid "The default template path ``templates/nxos_show_interface.ttp`` was generated using the ``ansible_network_os`` for the host and ``command`` provided." -msgstr "デフォルトのテンプレートパス ``templates/nxos_show_interface.ttp`` は、ホストの ``ansible_network_os`` と、指定した ``command`` を使用して生成されました。" - -#: ../../rst/network/user_guide/cli_parsing.rst:564 -msgid "TTP supports several additional variables that will be passed to the parser. These include:" -msgstr "TTP は、パーサーに渡される追加変数をサポートします。これには以下が含まれます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:566 -msgid "``parser/vars/ttp_init`` - Additional parameter passed when the parser is initialized." -msgstr "``parser/vars/ttp_init`` - パーサーの初期化時に渡される追加のパラメーター。" - -#: ../../rst/network/user_guide/cli_parsing.rst:567 -msgid "``parser/vars/ttp_results`` - Additional parameters used to influence the parser output." -msgstr "``parser/vars/ttp_results`` - パーサーの出力に影響を与えるために使用される追加のパラメーター。" - -#: ../../rst/network/user_guide/cli_parsing.rst:568 -msgid "``parser/vars/ttp_vars`` - Additional variables made available in the template." -msgstr "``parser/vars/ttp_vars`` - テンプレートで利用可能な追加の変数" - -#: ../../rst/network/user_guide/cli_parsing.rst:570 -msgid "See the `TTP documentation `_ for details." -msgstr "詳細は、`TTP documentation `_ を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:573 -msgid "The task sets the follow fact as the ``interfaces`` fact for the host:" -msgstr "このタスクは、ホストの ``interfaces`` ファクトとして follow ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:589 -msgid "Parsing with JC" -msgstr "JC での解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:591 -msgid "JC is a python library that converts the output of dozens of common Linux/UNIX/macOS/Windows command-line tools and file types to python dictionaries or lists of dictionaries for easier parsing. JC is available as a filter plugin in the ``community.general`` collection." -msgstr "JC は、多数の一般的な Linux/UNIX/macOS/Windows コマンドラインツールおよびファイルタイプの出力を python ディクショナリーまたはディクショナリーの一覧に変換する python ライブラリーです。JC は、``community.general`` コレクションのフィルタープラグインとして利用できます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:593 -msgid "The following is an example using JC to parse the output of the ``dig`` command:" -msgstr "以下は、JC を使用して ``dig`` コマンドの出力を解析した例です。" - -#: ../../rst/network/user_guide/cli_parsing.rst:607 -msgid "The JC project and documentation can be found `here `_." -msgstr "JC プロジェクトおよびドキュメントは `here `_ にあります。" - -#: ../../rst/network/user_guide/cli_parsing.rst:608 -msgid "See this `blog entry `_ for more information." -msgstr "詳細は、`ブログ記事 ` を参照してください。" - -#: ../../rst/network/user_guide/cli_parsing.rst:612 -msgid "Converting XML" -msgstr "XML の変換" - -#: ../../rst/network/user_guide/cli_parsing.rst:616 -msgid "This example task runs the ``show interface`` command and parses the output as XML:" -msgstr "このサンプルタスクでは、``show interface`` コマンドを実行し、出力を XML として解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:629 -msgid "Red Hat Ansible Automation Platform subscription support is limited to the use of the ``xmltodict`` public APIs as documented." -msgstr "Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``xmltodict`` パブリック API の使用に限定されます。" - -#: ../../rst/network/user_guide/cli_parsing.rst:631 -msgid "This task sets the ``interfaces`` fact for the host based on this returned output:" -msgstr "このタスクは、返された出力に基づいてホストの ``interfaces`` ファクトを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:654 -msgid "Advanced use cases" -msgstr "高度なユースケース" - -#: ../../rst/network/user_guide/cli_parsing.rst:656 -msgid "The ``cli_parse`` module supports several features to support more complex uses cases." -msgstr "``cli_parse`` モジュールは、より複雑なユースケースをサポートする複数の機能をサポートします。" - -#: ../../rst/network/user_guide/cli_parsing.rst:659 -msgid "Provide a full template path" -msgstr "完全なテンプレートパスを提供" - -#: ../../rst/network/user_guide/cli_parsing.rst:661 -msgid "Use the ``template_path`` option to override the default template path in the task:" -msgstr "``template_path`` オプションを使用して、タスクのデフォルトのテンプレートパスを上書きします。" - -#: ../../rst/network/user_guide/cli_parsing.rst:674 -msgid "Provide command to parser different than the command run" -msgstr "コマンド実行以外のパーサーを行うコマンドを指定" - -#: ../../rst/network/user_guide/cli_parsing.rst:676 -msgid "Use the ``command`` suboption for the ``parser`` to configure the command the parser expects if it is different from the command ``cli_parse`` runs:" -msgstr "``parser`` の ``command`` サブオプションを使用して、``cli_parse`` コマンドの実行とは異なる場合にパーサーが想定するコマンドを設定します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:688 -msgid "Provide a custom OS value" -msgstr "カスタム OS 値を指定" - -#: ../../rst/network/user_guide/cli_parsing.rst:690 -msgid "Use the ``os`` suboption to the parser to directly set the OS instead of using ``ansible_network_os`` or ``ansible_distribution`` to generate the template path or with the specified parser engine:" -msgstr "テンプレートパスを生成する ``ansible_network_os`` や ``ansible_distribution``、または指定したパーサーエンジンを使用する代わりに、OS を直接設定するパーサーに ``os`` サブオプションを使用します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:710 -msgid "Parse existing text" -msgstr "既存テキストの解析" - -#: ../../rst/network/user_guide/cli_parsing.rst:712 -msgid "Use the ``text`` option instead of ``command`` to parse text collected earlier in the playbook." -msgstr "``command`` の代わりに ``text`` オプションを使用して、Playbook で以前に収集したテキストを解析します。" - -#: ../../rst/network/user_guide/cli_parsing.rst:744 -msgid ":ref:`develop_cli_parse_plugins`" -msgstr ":ref:`develop_cli_parse_plugins`" - -#: ../../rst/network/user_guide/faq.rst:5 -msgid "Ansible Network FAQ" -msgstr "Ansible Network FAQ" - -#: ../../rst/network/user_guide/faq.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/network/user_guide/faq.rst:12 -msgid "How can I improve performance for network playbooks?" -msgstr "ネットワークの Playbook のパフォーマンスを改善するにはどうすればよいですか" - -#: ../../rst/network/user_guide/faq.rst:17 -msgid "Consider ``strategy: free`` if you are running on multiple hosts" -msgstr "複数のホストで実行している場合は ``strategy: free`` について検討してください。" - -#: ../../rst/network/user_guide/faq.rst:19 -msgid "The ``strategy`` plugin tells Ansible how to order multiple tasks on multiple hosts. :ref:`Strategy` is set at the playbook level." -msgstr "``strategy`` プラグインは、Ansible に対して複数のホストで複数のタスクを順序付ける方法を示します。:ref:`Strategy` は Playbook レベルで設定されます。" - -#: ../../rst/network/user_guide/faq.rst:21 -msgid "The default strategy is ``linear``. With strategy set to ``linear``, Ansible waits until the current task has run on all hosts before starting the next task on any host. Ansible may have forks free, but will not use them until all hosts have completed the current task. If each task in your playbook must succeed on all hosts before you run the next task, use the ``linear`` strategy." -msgstr "デフォルトのストラテジーは ``linear`` です。ストラテジーを ``linear`` に設定すると、Ansible は、現在のタスクがすべてのホストで実行されるまで待機してから、任意のホストで次のタスクを開始します。Ansible はフォークを解放しているかもしれませんが、全てのホストが現在のタスクを完了するまでフォークを使用しません。次のタスクを実行する前に、Playbook の各タスクがすべてのホストで成功する必要がある場合は、``linear`` ストラテジーを使用します。" - -#: ../../rst/network/user_guide/faq.rst:23 -msgid "Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance." -msgstr "この ``free`` ストラテジーを使用すると、Ansible は、利用可能なフォークを使用して各ホストのタスクをできるだけ速く実行します。あるホストで前のタスクの実行が完了していない場合でも、Ansible は他のホストで後のタスクを実行します。この ``free`` ストラテジーでは、使用可能なフォークをより効率的に使用します。各タスクで Playbook が停滞し、1 つのホストの処理速度が遅い場合は、``strategy: free`` を使用して全体的なパフォーマンスを向上させることを検討してください。" - -#: ../../rst/network/user_guide/faq.rst:28 -msgid "Execute ``show running`` only if you absolutely must" -msgstr "絶対的に必要とされる場合にのみ ``show running`` を実行" - -#: ../../rst/network/user_guide/faq.rst:30 -msgid "The ``show running`` command is the most resource-intensive command to execute on a network device, because of the way queries are handled by the network OS. Using the command in your Ansible playbook will slow performance significantly, especially on large devices; repeating it will multiply the performance hit. If you have a playbook that checks the running config, then executes changes, then checks the running config again, you should expect that playbook to be very slow." -msgstr "この ``show running`` コマンドは、ネットワーク OS によるクエリーの処理方法のため、ネットワークデバイスで実行する最もリソースを消費するコマンドです。Ansible Playbook でこのコマンドを使用すると、特に大規模なデバイスではパフォーマンスが大幅に低下します。繰り返し実行すると、パフォーマンスへの影響が大きくなります。実行設定を確認してから変更を実行し、再び実行設定を確認する Playbook がある場合は、Playbook が非常に遅くなることが予想されます。" - -#: ../../rst/network/user_guide/faq.rst:35 -msgid "Use ``ProxyCommand`` only if you absolutely must" -msgstr "絶対的に必要とされる場合のみ ``ProxyCommand`` を使用" - -#: ../../rst/network/user_guide/faq.rst:37 -msgid "Network modules support the use of a :ref:`proxy or jump host` with the ``ProxyCommand`` parameter. However, when you use a jump host, Ansible must open a new SSH connection for every task, even if you are using a persistent connection type (``network_cli`` or ``netconf``). To maximize the performance benefits of the persistent connection types introduced in version 2.5, avoid using jump hosts whenever possible." -msgstr "ネットワークモジュールは、``ProxyCommand`` パラメーターで :ref:`プロキシーまたはジャンプホスト` の使用がサポートされています。ただし、ジャンプホストを使用する場合は、永続的な接続タイプ (``network_cli`` または ``netconf``) を使用している場合でも、タスクごとに新しい SSH 接続を開く必要があります。バージョン 2.5 で導入された永続接続タイプのパフォーマンス上の利点を最大限に活用するには、可能な限りジャンプホストを使用しないでください。" - -#: ../../rst/network/user_guide/faq.rst:42 -msgid "Set ``--forks`` to match your needs" -msgstr "必要に応じて ``--forks`` を設定" - -#: ../../rst/network/user_guide/faq.rst:44 -msgid "Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound." -msgstr "Ansible はタスクを実行するたびに、独自のプロセスをフォークします。``--forks`` パラメーターは、同時実行タスクの数を定義します。デフォルト設定 (``--forks=5``) のままで、10 台のホストで Playbook を実行していると、そのうち 5 台のホストは、フォークが使用可能になるまで待機する必要があります。もちろん、フォークの数が増えれば増えるほど、Ansible はより多くのメモリーと処理能力を使うことになります。ネットワークタスクの大半はコントロールホストで実行されるため、ラップトップでは、CPU またはメモリーがすぐに枯渇することになります。" - -#: ../../rst/network/user_guide/faq.rst:49 -msgid "Why is my output sometimes replaced with ``********``?" -msgstr "出力が ``********`` に置き換えられることがあるのはなぜですか" - -#: ../../rst/network/user_guide/faq.rst:51 -msgid "Ansible replaces any string marked ``no_log``, including passwords, with ``********`` in Ansible output. This is done by design, to protect your sensitive data. Most users are happy to have their passwords redacted. However, Ansible replaces every string that matches your password with ``********``. If you use a common word for your password, this can be a problem. For example, if you choose ``Admin`` as your password, Ansible will replace every instance of the word ``Admin`` with ``********`` in your output. This may make your output harder to read. To avoid this problem, select a secure password that will not occur elsewhere in your Ansible output." -msgstr "Ansible は、Ansible 出力で、パスワードを含む ``no_log`` と印された文字列を ``********`` に置き換えます。これは、機密データを保護するために設計されています。ほとんどのユーザーは、自身のパスワードが伏字になることを希望します。ただし、Ansible はパスワードに一致するすべての文字列を ``********`` に置き換えます。パスワードに一般的な単語を使用すると、問題が発生する可能性があります。たとえば、``Admin`` をパスワードとした場合、``Admin`` は出力内にあるその単語のすべてのインスタンスを ``********`` に置き換えます。これにより、出力が読みにくくなる場合があります。この問題を回避するには、他の Ansible 出力場所では使用されない安全なパスワードを選択してください。" - -#: ../../rst/network/user_guide/faq.rst:56 -msgid "Why do the ``*_config`` modules always return ``changed=true`` with abbreviated commands?" -msgstr "省略されたコマンドで ``*_config`` モジュールが常に ``changed=true`` を返すのはなぜですか" - -#: ../../rst/network/user_guide/faq.rst:58 -msgid "When you issue commands directly on a network device, you can use abbreviated commands. For example, ``int g1/0/11`` and ``interface GigabitEthernet1/0/11`` do the same thing; ``shut`` and ``shutdown`` do the same thing. Ansible Network ``*_command`` modules work with abbreviations, because they run commands through the network OS." -msgstr "ネットワークデバイスで直接コマンドを実行する場合は、省略されたコマンドを使用できます。たとえば、``int g1/0/11`` と ``interface GigabitEthernet1/0/11`` は、同じ動作になります。``shut`` と ``shutdown`` も同じ動作になります。Ansible Network の ``*_command`` モジュールは、ネットワーク OS を介してコマンドを実行するため、省略形で動作します。" - -#: ../../rst/network/user_guide/faq.rst:60 -msgid "When committing configuration, however, the network OS converts abbreviations into long-form commands. Whether you use ``shut`` or ``shutdown`` on ``GigabitEthernet1/0/11``, the result in the configuration is the same: ``shutdown``." -msgstr "ただし、設定をコミットすると、ネットワーク OS は省略形を長い形式のコマンドに変換します。``GigabitEthernet1/0/11`` で ``shut`` または ``shutdown`` を使用した場合の設定は同じで、``shutdown`` となります。" - -#: ../../rst/network/user_guide/faq.rst:62 -msgid "Ansible Network ``*_config`` modules compare the text of the commands you specify in ``lines`` to the text in the configuration. If you use ``shut`` in the ``lines`` section of your task, and the configuration reads ``shutdown``, the module returns ``changed=true`` even though the configuration is already correct. Your task will update the configuration every time it runs." -msgstr "Ansible Network の ``*_config`` モジュールは、``lines`` で指定したコマンドのテキストを設定のテキストと比較します。タスクの ``lines`` セクションで ``shut`` を使用し、設定が ``shutdown`` を読み込む場合は、設定が正しいにもかかわらず、モジュールが ``changed=true`` を返します。タスクを実行するたびに設定が更新されます。" - -#: ../../rst/network/user_guide/faq.rst:64 -msgid "To avoid this problem, use long-form commands with the ``*_config`` modules:" -msgstr "この問題を回避するには、``*_config`` モジュールで長い形式のコマンドを使用します。" - -#: ../../rst/network/user_guide/index.rst:15 -msgid "Advanced Topics" -msgstr "高度なトピック" - -#: ../../rst/network/user_guide/index.rst:5 -msgid "Network Advanced Topics" -msgstr "ネットワークの高度なトピック" - -#: ../../rst/network/user_guide/index.rst:7 -msgid "Once you have mastered the basics of network automation with Ansible, as presented in :ref:`network_getting_started`, use this guide understand platform-specific details, optimization, and troubleshooting tips for Ansible for network automation." -msgstr ":ref:`network_getting_started` に記載されているように、Ansible を使用したネットワーク自動化の基本を習得したら、本ガイドを参照して、ネットワーク自動化に関する Ansible のプラットフォーム固有の詳細、最適化、およびトラブルシューティングのヒントを理解します。" - -#: ../../rst/network/user_guide/index.rst:11 -msgid "This guide is intended for network engineers using Ansible for automation. It covers advanced topics. If you understand networks and Ansible, this guide is for you. You may read through the entire guide if you choose, or use the links below to find the specific information you need." -msgstr "このガイドは、自動化に Ansible を使用するネットワークエンジニアを対象とした高度なトピックを説明します。ネットワークと Ansible を理解しているユーザーを対象としています。必要に応じてガイド全体を読むか、次のリンクを使用して必要な特定情報を選択してください。" - -#: ../../rst/network/user_guide/index.rst:13 -msgid "If you're new to Ansible, or new to using Ansible for network automation, start with the :ref:`network_getting_started`." -msgstr "Ansible を初めて使用する場合や、ネットワーク管理に Ansible を初めて使用する場合は、最初に「:ref:`network_getting_started`」をお読みください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:5 -msgid "Ansible Network Examples" -msgstr "Ansible ネットワークの例" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:7 -msgid "This document describes some examples of using Ansible to manage your network infrastructure." -msgstr "本ガイドでは、Ansible を使用してネットワークインフラストラクチャーを管理する例を説明します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:15 -msgid "This example requires the following:" -msgstr "この例では、以下が必要です。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:17 -msgid "**Ansible 2.10** (or higher) installed. See :ref:`intro_installation_guide` for more information." -msgstr "**Ansible 2.10** (またはそれ以上) がインストールされている。詳細は「:ref:`intro_installation_guide`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:18 -msgid "One or more network devices that are compatible with Ansible." -msgstr "Ansible と互換性がある 1 つ以上ネットワークデバイス。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:19 -msgid "Basic understanding of YAML :ref:`yaml_syntax`." -msgstr "YAML :ref:`yaml_syntax` の基本知識" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:20 -msgid "Basic understanding of Jinja2 templates. See :ref:`playbooks_templating` for more information." -msgstr "Jinja2 テンプレートの基本的な理解。詳細は「:ref:`playbooks_templating`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:21 -msgid "Basic Linux command line use." -msgstr "基本的な Linux コマンドラインの使用。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:22 -msgid "Basic knowledge of network switch & router configurations." -msgstr "ネットワークスイッチおよびルーター設定に関する基本知識。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:26 -msgid "Groups and variables in an inventory file" -msgstr "インベントリーファイルのグループおよび変数" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:28 -msgid "An ``inventory`` file is a YAML or INI-like configuration file that defines the mapping of hosts into groups." -msgstr "``inventory`` ファイルは、ホストからグループへのマッピングを定義する YAML または INI のような設定ファイルです。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:30 -msgid "In our example, the inventory file defines the groups ``eos``, ``ios``, ``vyos`` and a \"group of groups\" called ``switches``. Further details about subgroups and inventory files can be found in the :ref:`Ansible inventory Group documentation `." -msgstr "この例では、インベントリーファイルは ``eos``、``ios``、および ``vyos`` と、``switches`` と呼ばれる「グループのグループ」を定義します。サブグループとインベントリーファイルの詳細は「:ref:`Ansible inventory Group documentation `」にあります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:32 -msgid "Because Ansible is a flexible tool, there are a number of ways to specify connection information and credentials. We recommend using the ``[my_group:vars]`` capability in your inventory file." -msgstr "Ansible は柔軟なツールであるため、接続情報および認証情報を指定する方法は複数あります。インベントリーファイルで ``[my_group:vars]`` 機能を使用することが推奨されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:81 -msgid "If you use ssh-agent, you do not need the ``ansible_password`` lines. If you use ssh keys, but not ssh-agent, and you have multiple keys, specify the key to use for each connection in the ``[group:vars]`` section with ``ansible_ssh_private_key_file=/path/to/correct/key``. For more information on ``ansible_ssh_`` options see :ref:`behavioral_parameters`." -msgstr "ssh-agent を使用する場合、``ansible_password`` 行は必要ありません。ssh-agent でなく ssh キーを使用し、鍵が複数ある場合は、``ansible_ssh_private_key_file=/path/to/correct/key`` の ``[group:vars]`` セクションで、各接続に使用するキーを指定します。``ansible_ssh_`` オプションの詳細は、「:ref:`behavioral_parameters`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:85 -msgid "Never store passwords in plain text." -msgstr "プレーンテキストにパスワードを保存しないでください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:88 -msgid "Ansible vault for password encryption" -msgstr "パスワード暗号化用の Ansible Vault" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:90 -msgid "The \"Vault\" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information." -msgstr "Ansible の「Vault」機能を使用すると、パスワードやキーなどの機密データを、Playbook やロールのプレーンテキストとしてではなく、暗号化されたファイルに保存することができます。この Vault ファイルは、ソース制御に配布または配置することができます。詳細は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:92 -msgid "Here's what it would look like if you specified your SSH passwords (encrypted with Ansible Vault) among your variables:" -msgstr "変数内に SSH パスワード (Ansible Vault で暗号化) を指定すると、以下のようになります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:108 -msgid "Common inventory variables" -msgstr "共通のインベントリー変数" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:110 -msgid "The following variables are common for all platforms in the inventory, though they can be overwritten for a particular inventory group or host." -msgstr "以下の変数はインベントリー内のすべてのプラットフォームに共通ですが、特定のインベントリーグループまたはホストについて上書きできます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_connection" -msgstr "ansible_connection" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:114 -msgid "Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to an appropriate network connection option, such as``ansible.netcommon.network_cli``, so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices." -msgstr "Ansible は ansible-connection 設定を使用してリモートデバイスへの接続方法を決定します。Ansible ネットワークを使用する場合は、適切なネットワーク接続オプション (``ansible.netcommon.network_cli`` など) に設定して、Ansible が実行環境が制限されたネットワークデバイスとしてリモートノードを扱うようにします。この設定がないと、Ansible は ssh を使用してリモートに接続し、Python スクリプトをネットワークデバイスで実行しようとしますが、Python は一般的にネットワークデバイスで使用できないため失敗します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_network_os" -msgstr "ansible_network_os" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:116 -msgid "Informs Ansible which Network platform this hosts corresponds to. This is required when using the ``ansible.netcommon.*`` connection options." -msgstr "このホストに対応するネットワークプラットフォームを Ansible に通知します。これは、``ansible.netcommon.*`` 接続オプションを使用する場合に必要です。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_user" -msgstr "ansible_user" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:117 -msgid "The user to connect to the remote device (switch) as. Without this the user that is running ``ansible-playbook`` would be used. Specifies which user on the network device the connection" -msgstr "リモートデバイス (スイッチ) に接続するユーザーです。これがないと、このユーザーが ``ansible-playbook`` を実行しているユーザーに使用されます。ネットワークデバイス上のどのユーザーに接続するかを指定します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_password" -msgstr "ansible_password" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:120 -msgid "The corresponding password for ``ansible_user`` to log in as. If not specified SSH key will be used." -msgstr "``ansible_user`` でログインするためのパスワードです。指定しない場合は、SSH キーが使用されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_become" -msgstr "ansible_become" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:122 -msgid "If enable mode (privilege mode) should be used, see the next section." -msgstr "Enable モード (特権モード) を使用する場合は、次のセクションを参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst -msgid "ansible_become_method" -msgstr "ansible_become_method" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:124 -msgid "Which type of `become` should be used, for ``network_cli`` the only valid choice is ``enable``." -msgstr "どのタイプ `become` を使用すべきか。``network_cli`` では、有効な選択は ``enable`` のみです。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:127 -msgid "Privilege escalation" -msgstr "権限昇格" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:129 -msgid "Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: ansible.netcommon.network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here:" -msgstr "Arista EOS や Cisco IOS などの特定のネットワークプラットフォームには、異なる特権モードの概念があります。ユーザーを含むシステム状態を変更するような特定のネットワークモジュールは、高特権状態でのみ動作します。Ansible は、``connection: ansible.netcommon.network_cli`` の使用時に、``become`` をサポートします。これにより、権限を必要とする特定のタスクに対して権限を設定できます。次に示すように、``become: yes`` および ``become_method: enable`` を追加すると、タスクを実行する前に特権モードに入るように Ansible に通知します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:139 -msgid "For more information, see the :ref:`using become with network modules` guide." -msgstr "詳細は「:ref:`ネットワークモジュールで become の使用`」ガイドを参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:143 -msgid "Jump hosts" -msgstr "ジャンプホスト" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:145 -msgid "If the Ansible Controller does not have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command ` guide for details on how to achieve this." -msgstr "Ansible Controller がリモートデバイスへの直接ルートがなく、ジャンプホストを使用する必要がある場合は、これを実現する方法について、「:ref:`Ansible ネットワークプロキシーコマンド `」ガイドを参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:148 -msgid "Example 1: collecting facts and creating backup files with a playbook" -msgstr "例 1: Playbook でファクトを収集し、バックアップファイルの作成" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:150 -msgid "Ansible facts modules gather system information 'facts' that are available to the rest of your playbook." -msgstr "Ansible ファクトモジュールは、他の Playbook で利用可能なシステム情報の「ファクト」を収集します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:152 -msgid "Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`arista.eos.eos_facts `, :ref:`cisco.ios.ios_facts ` and :ref:`vyos.vyos.vyos_facts ` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file." -msgstr "Ansible ネットワークには、ネットワーク固有のファクトモジュールがいくつか付属しています。この例では、``_facts`` モジュール (:ref:`arista.eos.eos_facts `、:ref:`cisco.ios.ios_facts `、および :ref:`vyos.vyos.vyos_facts `) を使用し、リモートネットワーキングデバイスに接続します。認証情報はモジュール引数とともに明示的に渡されないため、Ansible はインベントリーファイルからのユーザー名とパスワードを使用します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:154 -msgid "Ansible's \"Network Fact modules\" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`arista.eos.eos_facts ` and :ref:`vyos.vyos.vyos_facts `. We can use the facts, such as ``ansible_net_version`` late on in the \"Display some facts\" task." -msgstr "Ansibleの「ネットワークファクトモジュール」はシステムから情報を収集し、``ansible_net_`` の接頭辞が付いたファクトに結果を格納します。これらのモジュールによって収集されるデータは、モジュールドキュメントの `Return Values` セクション (この場合は :ref:`arista.eos.eos_facts ` および :ref:`vyos.vyos.vyos_facts `) に記載されています。``ansible_net_version`` などのファクトは、「Display some facts (一部のファクトを表示する)」タスクの後半で使用できます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:156 -msgid "To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`." -msgstr "正しいモード (``*_facts``) を呼び出すようにするには、インベントリーファイルに定義されたグループに基づいてタスクが条件付きで実行されます。Ansible Playbook での条件付き使用の詳細は、「:ref:`the_when_statement`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:158 -msgid "In this example, we will create an inventory file containing some network switches, then run a playbook to connect to the network devices and return some information about them." -msgstr "この例では、一部のネットワークスイッチを含むインベントリーファイルを作成してから、Playbook を実行してネットワークデバイスに接続し、その情報を返します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:161 -msgid "Step 1: Creating the inventory" -msgstr "ステップ 1: インベントリーの作成" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:163 -msgid "First, create a file called ``inventory``, containing:" -msgstr "まず、以下を含む ``inventory`` という名前のファイルを作成します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:183 -msgid "Step 2: Creating the playbook" -msgstr "ステップ 2: Playbook の作成" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:185 -msgid "Next, create a playbook file called ``facts-demo.yml`` containing the following:" -msgstr "次に、以下を含む ``facts-demo.yml`` という名前の Playbook ファイルを作成します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:285 -msgid "Step 3: Running the playbook" -msgstr "ステップ 3: Playbook の実行" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:287 -msgid "To run the playbook, run the following from a console prompt:" -msgstr "Playbook を実行するには、コンソールプロンプトから以下を実行します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:293 -msgid "This should return output similar to the following:" -msgstr "このコマンドを実行すると、以下のような出力が返されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:303 -msgid "Step 4: Examining the playbook results" -msgstr "手順 4: Playbook の結果の検証" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:305 -msgid "Next, look at the contents of the file we created containing the switch facts:" -msgstr "次に、スイッチファクトを含む作成したファイルの内容を確認します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:311 -msgid "You can also look at the backup files:" -msgstr "バックアップファイルを確認することもできます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:318 -msgid "If `ansible-playbook` fails, please follow the debug steps in :ref:`network_debug_troubleshooting`." -msgstr "`ansible-playbook` が失敗する場合は、:ref:`network_debug_troubleshooting` のデバッグ手順に従ってください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:324 -msgid "Example 2: simplifying playbooks with platform-independent modules" -msgstr "例 2: プラットフォームに依存しないモジュールを使用した Playbook の単純化" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:326 -msgid "(This example originally appeared in the `Deep Dive on cli_command for Network Automation `_ blog post by Sean Cavanaugh -`@IPvSean `_)." -msgstr "(この例は、元々、Sean Cavanaugh (`@IPvSean `_) 氏が投稿したブログ「`Deep Dive on cli_command for Network Automation `_」で紹介されました。)" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:328 -msgid "If you have two or more network platforms in your environment, you can use the platform-independent modules to simplify your playbooks. You can use platform-independent modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks." -msgstr "環境内に複数のネットワークプラットフォームがある場合は、プラットフォームに依存しないモジュールを使用して、Playbook を簡素化できます。``arista.eos.eos_config``、``cisco.ios.ios_config``、``junipernetworks.junos.junos_config`` などのプラットフォーム固有のモジュールの代わりに、``ansible.netcommon.cli_command``、``ansible.netcommon.cli_config`` などのプラットフォームに依存しないモジュールを使用できます。これにより、Playbook に必要なタスクおよび条件の数が減ります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:331 -msgid "Platform-independent modules require the :ref:`ansible.netcommon.network_cli ` connection plugin." -msgstr "プラットフォームに依存しないモジュールには、:ref:`ansible.netcommon.network_cli ` connection プラグインが必要です。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:335 -msgid "Sample playbook with platform-specific modules" -msgstr "プラットフォーム固有のモジュールを含む Playbook のサンプル" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:337 -msgid "This example assumes three platforms, Arista EOS, Cisco NXOS, and Juniper JunOS. Without the platform-independent modules, a sample playbook might contain the following three tasks with platform-specific commands:" -msgstr "この例では、Arista EOS、Cisco NXOS、Juniper JunOS の 3 つのプラットフォームを想定しています。プラットフォームに依存しないモジュールを使用しないと、サンプル Playbook にはプラットフォーム固有のコマンドと共に、以下の 3 つのタスクが含まれる場合があります。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:358 -msgid "Simplified playbook with ``cli_command`` platform-independent module" -msgstr "``cli_command`` プラットフォームに依存しないモジュールを使用した Playbook の簡素化" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:360 -msgid "You can replace these platform-specific modules with the platform-independent ``ansible.netcommon.cli_command`` module as follows:" -msgstr "これらのプラットフォーム固有のモジュールは、以下のようにプラットフォームに依存しない ``ansible.netcommon.cli_command`` モジュールに置き換えることができます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:407 -msgid "If you use groups and group_vars by platform type, this playbook can be further simplified to :" -msgstr "プラットフォームタイプ別にグループおよび group_vars を使用する場合は、この Playbook をさらに簡単にできます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:423 -msgid "You can see a full example of this using group_vars and also a configuration backup example at `Platform-independent examples `_." -msgstr "group_vars の完全例と設定バックアップの例は、`Platform-independent examples `_ で確認できます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:426 -msgid "Using multiple prompts with the ``ansible.netcommon.cli_command``" -msgstr "``ansible.netcommon.cli_command`` を含む複数のプロンプトの使用" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:428 -msgid "The ``ansible.netcommon.cli_command`` also supports multiple prompts." -msgstr "``ansible.netcommon.cli_command`` は、複数のプロンプトもサポートします。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:449 -msgid "See the :ref:`ansible.netcommon.cli_command ` for full documentation on this command." -msgstr "このコマンドに関するドキュメントは、「:ref:`ansible.netcommon.cli_command `」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:453 -msgid "Implementation Notes" -msgstr "実装に関する注意点" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:457 -msgid "Demo variables" -msgstr "デモ変数" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:459 -msgid "Although these tasks are not needed to write data to disk, they are used in this example to demonstrate some methods of accessing facts about the given devices or a named host." -msgstr "これらのタスクは、ディスクにデータを書き込む必要はありませんが、この例では、特定のデバイスまたは名前付きホストのファクトにアクセスする方法を実証するために使用されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:461 -msgid "Ansible ``hostvars`` allows you to access variables from a named host. Without this we would return the details for the current host, rather than the named host." -msgstr "Ansible ``hostvars`` を使用すると、名前付きホストから変数にアクセスすることができます。これを使用しないと、名前付きホストではなく、現在のホストの詳細が返されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:463 -msgid "For more information, see :ref:`magic_variables_and_hostvars`." -msgstr "詳細情報は、「:ref:`magic_variables_and_hostvars`」を参照してください。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:466 -msgid "Get running configuration" -msgstr "実行中の設定の取得" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:468 -msgid "The :ref:`arista.eos.eos_config ` and :ref:`vyos.vyos.vyos_config ` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created." -msgstr ":ref:`arista.eos.eos_config ` モジュールおよび :ref:`vyos.vyos.vyos_config ` モジュールには、設定されている場合は、変更が行われる前にリモートデバイスから現在の ``running-config`` のフルバックアップを作成する ``backup:`` オプションがあります。バックアップファイルは、Playbook のルートディレクトリー内の ``backup`` ディレクトリーに書き込まれます。このディレクトリーが存在しない場合は作成されます。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:470 -msgid "To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in ``backup_path``." -msgstr "バックアップファイルを別の場所に移動する方法を実証するために、結果を登録し、ファイルを ``backup_path`` に保存されているパスに移動します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:472 -msgid "Note that when using variables from tasks in this way we use double quotes (``\"``) and double curly-brackets (``{{...}}`` to tell Ansible that this is a variable." -msgstr "この方法でタスクの変数を使用する場合は、Ansible にこれが変数であることを伝えるために、二重引用符 (``\"``) と二重中括弧 (``{{...}}``) を使用します。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:475 -msgid "Troubleshooting" -msgstr "トラブルシューティング" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:477 -msgid "If you receive an connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`." -msgstr "接続エラーを受け取った場合は、インベントリーと Playbook で誤字または欠落している行がないか再確認してください。問題が解決しない場合は、:ref:`network_debug_troubleshooting` のデバッグ手順に従います。" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:481 -msgid ":ref:`network_guide`" -msgstr ":ref:`network_guide`" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:482 -msgid ":ref:`intro_inventory`" -msgstr ":ref:`intro_inventory`" - -#: ../../rst/network/user_guide/network_best_practices_2.5.rst:483 -msgid ":ref:`Keeping vaulted variables visible `" -msgstr ":ref:`Keeping vaulted variables visible `" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:5 -msgid "Network Debug and Troubleshooting Guide" -msgstr "ネットワークデバッグおよびトラブルシューティングガイド" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:7 -msgid "This section discusses how to debug and troubleshoot network modules in Ansible." -msgstr "本セクションでは、Ansible でネットワークモジュールをデバッグし、トラブルシューティングを行う方法を説明します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:14 -msgid "How to troubleshoot" -msgstr "トラブルシューティングの方法" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:16 -msgid "Ansible network automation errors generally fall into one of the following categories:" -msgstr "Ansible ネットワーク自動化エラーは通常、以下のカテゴリーのいずれかに分類されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst -msgid "Authentication issues" -msgstr "認証の問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:19 -msgid "Not correctly specifying credentials" -msgstr "認証情報を正しく指定できない" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:20 -msgid "Remote device (network switch/router) not falling back to other other authentication methods" -msgstr "リモートデバイス (ネットワークスイッチ/ルーター) が他の認証方法にフォールバックしない" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:21 -msgid "SSH key issues" -msgstr "SSH キーの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:447 -msgid "Timeout issues" -msgstr "タイムアウトの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:23 -msgid "Can occur when trying to pull a large amount of data" -msgstr "大量のデータを取得しようとすると発生することがある" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:24 -msgid "May actually be masking a authentication issue" -msgstr "認証の問題を実際にマスクする可能性がある" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:612 -msgid "Playbook issues" -msgstr "Playbook の問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:26 -msgid "Use of ``delegate_to``, instead of ``ProxyCommand``. See :ref:`network proxy guide ` for more information." -msgstr "``ProxyCommand`` の代わりに ``delegate_to`` を使用します。詳細は、「:ref:`ネットワークプロキシーガイド `」を参照してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:28 -msgid "``unable to open shell``" -msgstr "``unable to open shell``" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:30 -msgid "The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. See the \"Authentication and connection issues\" section in this document for more information." -msgstr "``unable to open shell`` メッセージは、``ansible-connection`` デーモンがリモートネットワークデバイスと正常に通信できなかったことを示します。これは通常、認証の問題があることを意味します。詳細については、このドキュメントの「認証と接続の問題」を参照してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:37 -msgid "Enabling Networking logging and how to read the logfile" -msgstr "ネットワークロギングの有効化とログファイルの読み取り方法" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:39 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:100 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:160 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:205 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:262 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:300 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:327 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:434 -msgid "**Platforms:** Any" -msgstr "**プラットフォーム:** 任意" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:41 -msgid "Ansible includes logging to help diagnose and troubleshoot issues regarding Ansible Networking modules." -msgstr "Ansible には、Ansible ネットワークモジュールに関する問題の診断とトラブルシューティングに役立つロギングが含まれます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:43 -msgid "Because logging is very verbose, it is disabled by default. It can be enabled with the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ``ansible-playbook``." -msgstr "ロギングは非常に詳細なため、デフォルトでは無効になっています。これは、ansible-controller の :envvar:`ANSIBLE_LOG_PATH` オプションおよび :envvar:`ANSIBLE_DEBUG` オプションで有効にできます。これは、``ansible-playbook`` を実行しているマシンです。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:45 -msgid "Before running ``ansible-playbook``, run the following commands to enable logging:" -msgstr "``ansible-playbook`` を実行する前に、以下のコマンドを実行してロギングを有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:57 -msgid "After Ansible has finished running you can inspect the log file which has been created on the ansible-controller:" -msgstr "Ansible の実行が完了したら、ansible-controller で作成されたログファイルを確認できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:75 -msgid "From the log notice:" -msgstr "このログ通知は、以下のようになります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:77 -msgid "``p=28990`` Is the PID (Process ID) of the ``ansible-connection`` process" -msgstr "``p=28990`` ``ansible-connection`` プロセスの PID (プロセス ID) です。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:78 -msgid "``u=fred`` Is the user `running` ansible, not the remote-user you are attempting to connect as" -msgstr "``u=fred`` ansible を `実行` しているユーザーです (接続しようとしているリモートユーザーではありません)。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:79 -msgid "``creating new control socket for host veos01:22 as user admin`` host:port as user" -msgstr "``ホスト veos01:22 の新しいコントロールソケットをユーザー管理者`` ユーザーとして host:port" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:80 -msgid "``control socket path is`` location on disk where the persistent connection socket is created" -msgstr "``control socket path is`` 永続接続ソケットが作成されるディスクの場所" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:81 -msgid "``using connection plugin network_cli`` Informs you that persistent connection is being used" -msgstr "``using connection plugin network_cli`` 永続接続が使用されていることが通知されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:82 -msgid "``connection established to veos01 in 0:00:22.580626`` Time taken to obtain a shell on the remote device" -msgstr "``connection established to veos01 in 0:00:22.580626`` リモートデバイスでシェルの取得にかかった時間" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:85 -msgid "Port None ``creating new control socket for host veos01:None``" -msgstr "ポートなし ``ホスト veos01:22 の新しいコントロールソケットをユーザー管理者``" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:87 -msgid "If the log reports the port as ``None`` this means that the default port is being used. A future Ansible release will improve this message so that the port is always logged." -msgstr "ログでポートが ``None`` として報告される場合は、デフォルトのポートが使用されていることを意味します。今後の Ansible リリースでは、ポートが常にログに記録されるようにこのメッセージが改善されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:90 -msgid "Because the log files are verbose, you can use grep to look for specific information. For example, once you have identified the ``pid`` from the ``creating new control socket for host`` line you can search for other connection log entries:" -msgstr "ログファイルは冗長であるため、grep を使用して特定の情報を検索できます。たとえば、``creating new control socket for host`` 行から ``pid`` を特定したら、他の接続ログエントリーを検索できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:98 -msgid "Enabling Networking device interaction logging" -msgstr "ネットワークデバイスの対話ロギングの有効化" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:102 -msgid "Ansible includes logging of device interaction in the log file to help diagnose and troubleshoot issues regarding Ansible Networking modules. The messages are logged in the file pointed to by the ``log_path`` configuration option in the Ansible configuration file or by setting the :envvar:`ANSIBLE_LOG_PATH`." -msgstr "Ansible には、Ansible ネットワークモジュールに関する問題の診断およびトラブルシューティングに役立つ、ログファイル内のデバイスの対話のログが含まれています。このメッセージは、Ansible 設定ファイルの ``log_path`` 設定オプションで指定されているファイルに記録されるか、:envvar:`ANSIBLE_LOG_PATH` を設定すると記録されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:107 -msgid "The device interaction messages consist of command executed on the target device and the returned response. Since this log data can contain sensitive information including passwords in plain text it is disabled by default. Additionally, in order to prevent accidental leakage of data, a warning will be shown on every task with this setting enabled, specifying which host has it enabled and where the data is being logged." -msgstr "デバイスインタラクションメッセージは、ターゲットデバイス上で実行されたコマンドと返された応答で構成されます。このログデータには、パスワードなどの機密情報がプレーンテキストの形式で含まれる可能性があるため、デフォルトでは無効になっています。また、誤ってデータが漏洩しないように、この設定が有効になっているすべてのタスクに警告が表示され、有効になっているホストとデータが記録される場所が指定されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:112 -msgid "Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing a special variable to the task." -msgstr "このオプションを有効にした場合のセキュリティーへの影響を完全に理解してください。デバイス対話ロギングは、設定ファイルでグローバルに設定するか、環境を設定して有効にするか、または特殊な変数をタスクに渡すことでタスクごとに有効にすることができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:114 -msgid "Before running ``ansible-playbook`` run the following commands to enable logging:" -msgstr "``ansible-playbook`` を実行する前に、以下のコマンドを実行してロギングを有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:122 -msgid "Enable device interaction logging for a given task" -msgstr "特定のタスクのデバイス対話ログを有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:134 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:768 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:835 -msgid "To make this a global setting, add the following to your ``ansible.cfg`` file:" -msgstr "この設定をグローバルにするには、以下の設定を ``ansible.cfg`` ファイルに追加します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:141 -msgid "or enable the environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`:" -msgstr "または、環境変数 `ANSIBLE_PERSISTENT_LOG_MESSAGES` を有効にします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:148 -msgid "If the task is failing on connection initialization itself, you should enable this option globally. If an individual task is failing intermittently this option can be enabled for that task itself to find the root cause." -msgstr "タスク自体が接続の初期化に失敗している場合は、このオプションをグローバルに有効にする必要があります。個々のタスクが断続的に失敗する場合は、そのタスク自体に対してこのオプションを有効にして、根本原因を見つけることができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:151 -msgid "After Ansible has finished running you can inspect the log file which has been created on the ansible-controller" -msgstr "Ansible の実行が完了したら、ansible-controller で作成されたログファイルを確認できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:153 -msgid "Be sure to fully understand the security implications of enabling this option as it can log sensitive information in log file thus creating security vulnerability." -msgstr "このオプションを有効にすると、ログファイルに機密情報が記録され、セキュリティ上の脆弱性が生じる可能性があるため、セキュリティー上の影響を十分に理解してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:158 -msgid "Isolating an error" -msgstr "エラーの分離" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:162 -msgid "As with any effort to troubleshoot it's important to simplify the test case as much as possible." -msgstr "トラブルシューティングにおけるあらゆる作業と同様に、テストケースをできるだけ簡略化することが重要です。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:164 -msgid "For Ansible this can be done by ensuring you are only running against one remote device:" -msgstr "Ansible の場合は、1 つのリモートデバイスに対してのみ実行するようにすることでこれを行うことができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:166 -msgid "Using ``ansible-playbook --limit switch1.example.net...``" -msgstr "``ansible-playbook --limit switch1.example.net...`` の使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:167 -msgid "Using an ad hoc ``ansible`` command" -msgstr "``ansible`` アドホックコマンドの使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:169 -msgid "`ad hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device:" -msgstr "`ad hoc` は、オーケストレーション言語 ``/usr/bin/ansible-playbook`` ではなく、``/usr/bin/ansible`` を使用して簡単なコマンドを実行するために Ansible を実行することを指します。この場合は、リモートデバイスで 1 つのコマンドの実行を試みることで、接続を確認できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:175 -msgid "In the above example, we:" -msgstr "上記の例では、以下を行います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:177 -msgid "connect to ``switch1.example.net`` specified in the inventory file ``inventory``" -msgstr "インベントリーファイル ``inventory`` に指定された ``switch1.example.net`` に接続します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:178 -msgid "use the module ``arista.eos.eos_command``" -msgstr "``arista.eos.eos_command`` モジュールの使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:179 -msgid "run the command ``?``" -msgstr "``?`` コマンドの実行" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:180 -msgid "connect using the username ``admin``" -msgstr "ユーザー名 ``admin`` を使用して接続" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:181 -msgid "inform the ``ansible`` command to prompt for the SSH password by specifying ``-k``" -msgstr "``-k`` を指定して SSH パスワードを要求するように、``ansible`` コマンドに通知" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:183 -msgid "If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter." -msgstr "SSH キーが正しく設定されている場合は、``-k`` パラメーターを指定する必要はありません。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:185 -msgid "If the connection still fails you can combine it with the enable_network_logging parameter. For example:" -msgstr "それでも接続が失敗した場合は、これを enable_network_logging パラメーターと組み合わせることができます。以下に例を示します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:196 -msgid "Then review the log file and find the relevant error message in the rest of this document." -msgstr "次に、ログファイルを確認し、このドキュメントの残りの部分で、関連するエラーメッセージを見つけます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:203 -msgid "Troubleshooting socket path issues" -msgstr "ソケットパスの問題のトラブルシューティング" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:207 -msgid "The ``Socket path does not exist or cannot be found`` and ``Unable to connect to socket`` messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist." -msgstr "``Socket path does not exist or cannot be found`` メッセージおよび ``Unable to connect to socket``メッセージは、リモートネットワークデバイスとの通信に使用されるソケットが利用できないか、存在しないことを示しています。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:222 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:247 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:384 -msgid "or" -msgstr "または" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:235 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:289 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:315 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:341 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:375 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:427 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:458 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:484 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:510 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:523 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:551 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:635 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:807 -msgid "Suggestions to resolve:" -msgstr "解決するためのヒント:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:237 -msgid "Verify that you have write access to the socket path described in the error message." -msgstr "エラーメッセージに記載されているソケットパスへの書き込み権限があることを確認します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:239 -msgid "Follow the steps detailed in :ref:`enable network logging `." -msgstr "「:ref:`ネットワークロギングの有効化 `」記載される手順に従ってください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:241 -msgid "If the identified error message from the log file is:" -msgstr "ログファイルから特定されたエラーメッセージが以下の場合は、" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:253 -msgid "Follow the steps detailed in :ref:`timeout issues `" -msgstr "「:ref:`タイムアウトの問題 `」に記載の手順に従ってください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:259 -msgid "Category \"Unable to open shell\"" -msgstr "Category \"Unable to open shell\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:264 -msgid "The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a \"catch all\" message, meaning you need to enable :ref:`logging ` to find the underlying issues." -msgstr "``unable to open shell`` メッセージは、``ansible-connection`` デーモンがリモートネットワークデバイスと正常に通信できなかったことを示します。これは通常、認証の問題があることを意味します。これは「catch all (全て取得する)」メッセージです。つまり、:ref:`logging ` を有効にして、根本的な問題を検出する必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:276 -msgid "or:" -msgstr "または" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:291 -msgid "Follow the steps detailed in enable_network_logging_." -msgstr "enable_network_logging_ に記載の手順に従います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:293 -msgid "Once you've identified the error message from the log file, the specific solution can be found in the rest of this document." -msgstr "ログファイルからエラーメッセージが特定できたら、特定の解決方法は、本ガイドのその他のセクションを参照してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:298 -msgid "Error: \"[Errno -2] Name or service not known\"" -msgstr "Error: \"[Errno -2] Name or service not known\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:302 -msgid "Indicates that the remote host you are trying to connect to can not be reached" -msgstr "接続しようとしているリモートホストに到達できないことを示します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:317 -msgid "If you are using the ``provider:`` options ensure that its suboption ``host:`` is set correctly." -msgstr "``provider:`` オプションを使用している場合は、サブオプション ``host:`` が正しく設定されていることを確認します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:318 -msgid "If you are not using ``provider:`` nor top-level arguments ensure your inventory file is correct." -msgstr "``provider:`` またはトップレベルの引数を使用しない場合には、インベントリーファイルが正しいことを確認してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:325 -msgid "Error: \"Authentication failed\"" -msgstr "Error: \"Authentication failed\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:329 -msgid "Occurs if the credentials (username, passwords, or ssh keys) passed to ``ansible-connection`` (through ``ansible`` or ``ansible-playbook``) can not be used to connect to the remote device." -msgstr "(``ansible`` または ``ansible-playbook`` を使用して) ``ansible-connection`` に渡される認証情報 (ユーザー名、パスワード、または ssh キー) を使用してリモートデバイスに接続できない場合に発生します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:343 -msgid "If you are specifying credentials through ``password:`` (either directly or through ``provider:``) or the environment variable `ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable \"look for keys\". This can be done like this:" -msgstr "(直接または ``provider:`` を使用して) ``password:`` で認証情報を指定する場合や、環境変数 `ANSIBLE_NET_PASSWORD` を指定する場合は、``paramiko`` (Ansible が使用する Python SSH ライブラリー) が ssh キーを使用している可能性があるため、指定する認証情報が無効になります。これを確認するには、「look for keys」を無効にします。これは次のように行います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:349 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:466 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:493 -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:562 -msgid "To make this a permanent change, add the following to your ``ansible.cfg`` file:" -msgstr "これを永続的に行うには、以下を ``ansible.cfg`` ファイルに追加します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:358 -msgid "Error: \"connecting to host returned an error\" or \"Bad address\"" -msgstr "Error: \"connecting to host returned an error\" or \"Bad address\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:360 -msgid "This may occur if the SSH fingerprint hasn't been added to Paramiko's (the Python SSH library) know hosts file." -msgstr "これは、SSH フィンガープリントが Paramiko の既知のホストファイル (Python SSH ライブラリー) に追加されていない場合に発生する可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:362 -msgid "When using persistent connections with Paramiko, the connection runs in a background process. If the host doesn't already have a valid SSH key, by default Ansible will prompt to add the host key. This will cause connections running in background processes to fail." -msgstr "Paramiko で永続的な接続を使用する場合、接続はバックグラウンドプロセスで実行します。ホストが有効な SSH キーを持っていない場合、Ansible はデフォルトでホストキーを追加するようプロンプトを出します。これにより、バックグラウンドプロセスで実行中の接続が失敗します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:377 -msgid "Use ``ssh-keyscan`` to pre-populate the known_hosts. You need to ensure the keys are correct." -msgstr "``ssh-keyscan`` を使用して known_hosts を事前に設定します。キーが正しいことを確認してください。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:386 -msgid "You can tell Ansible to automatically accept the keys" -msgstr "鍵を自動的に受け入れるように Ansible に設定できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:388 -msgid "Environment variable method:" -msgstr "環境変数メソッド:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:395 -msgid "``ansible.cfg`` method:" -msgstr "``ansible.cfg`` メソッド:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:397 -msgid "ansible.cfg" -msgstr "ansible.cfg" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:411 -msgid "Error: \"No authentication methods available\"" -msgstr "Error: \"No authentication methods available\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:429 -msgid "No password or SSH key supplied" -msgstr "パスワードまたは SSH キーが指定されていない" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:432 -msgid "Clearing Out Persistent Connections" -msgstr "永続的な接続を解除" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:436 -msgid "In Ansible 2.3, persistent connection sockets are stored in ``~/.ansible/pc`` for all network devices. When an Ansible playbook runs, the persistent socket connection is displayed when verbose output is specified." -msgstr "Ansible 2.3 では、すべてのネットワークデバイスの永続的な接続ソケットが ``~/.ansible/pc`` に保存されます。Ansible Playbook が実行すると、詳細な出力が指定されている場合に永続的なソケット接続が表示されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:438 -msgid "`` socket_path: /home/fred/.ansible/pc/f64ddfa760``" -msgstr "`` socket_path: /home/fred/.ansible/pc/f64ddfa760``" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:440 -msgid "To clear out a persistent connection before it times out (the default timeout is 30 seconds of inactivity), simple delete the socket file." -msgstr "タイムアウトする前に永続的な接続 (デフォルトのタイムアウトが 30 秒の非アクティブタイムアウト) を削除するには、ソケットファイルを簡単な削除します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:450 -msgid "Persistent connection idle timeout" -msgstr "永続的な接続アイドルタイムアウト" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:452 -msgid "By default, ``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` is set to 30 (seconds). You may see the following error if this value is too low:" -msgstr "デフォルトでは、``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` は 30 (秒) に設定されます。この値が低すぎると、以下のエラーが表示される可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:460 -msgid "Increase value of persistent connection idle timeout:" -msgstr "永続的な接続アイドルタイムアウトの値を大きくします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:474 -msgid "Command timeout" -msgstr "コマンドタイムアウト" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:476 -msgid "By default, ``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` is set to 30 (seconds). Prior versions of Ansible had this value set to 10 seconds by default. You may see the following error if this value is too low:" -msgstr "デフォルトでは、``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` は 30 (秒) に設定されます。Ansible の以前のバージョンでは、デフォルトでこの値を 10 秒に設定されています。この値が低すぎると、以下のエラーが発生する可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:486 -msgid "Option 1 (Global command timeout setting): Increase value of command timeout in configuration file or by setting environment variable." -msgstr "オプション 1 (グローバルコマンドのタイムアウト設定): 設定ファイル、または環境変数を設定してコマンドタイムアウトの値を増やします。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:500 -msgid "Option 2 (Per task command timeout setting): Increase command timeout per task basis. All network modules support a timeout value that can be set on a per task basis. The timeout value controls the amount of time in seconds before the task will fail if the command has not returned." -msgstr "オプション 2 (タスクごとのコマンドのタイムアウト設定): タスクごとにコマンドタイムアウトを増やします。すべてのネットワークモジュールは、タスクごとに設定できるタイムアウト値をサポートしています。タイムアウト値は、コマンドが返されなかった場合にタスクが失敗するまでの時間を秒単位で制御します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:506 -msgid "For local connection type:" -msgstr "ローカル接続タイプの場合:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:512 -msgid "Some modules support a ``timeout`` option, which is different to the ``timeout`` keyword for tasks." -msgstr "一部のモジュールは、``timeout`` オプションをサポートします。このオプションは、タスクの ``timeout`` キーワードとは異なります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:525 -msgid "If the module does not support the ``timeout`` option directly, most networking connection plugins can enable similar functionality with the ``ansible_command_timeout`` variable." -msgstr "モジュールが ``timeout`` オプションを直接使用する場合には、ほとんどのネットワーク接続プラグインで、``ansible_command_timeout`` 変数を使用して同様の機能を有効化できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:535 -msgid "Some operations take longer than the default 30 seconds to complete. One good example is saving the current running config on IOS devices to startup config. In this case, changing the timeout value from the default 30 seconds to 60 seconds will prevent the task from failing before the command completes successfully." -msgstr "一部の操作は、完了までにデフォルトの 30 秒より長くかかります。たとえば、IOS デバイス上の現在の実行設定をスタートアップ設定に保存します。この場合は、タイムアウト値をデフォルトの 30 秒から 60 秒に変更すると、コマンドが正常に完了する前にタスクが失敗するのを防ぐことができます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:542 -msgid "Persistent connection retry timeout" -msgstr "永続的な接続の再試行タイムアウト" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:544 -msgid "By default, ``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` is set to 15 (seconds). You may see the following error if this value is too low:" -msgstr "デフォルトでは、``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` は 15 (秒) に設定されます。この値が低すぎると、以下のエラーが表示される可能性があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:553 -msgid "Increase the value of the persistent connection idle timeout. Note: This value should be greater than the SSH timeout value (the timeout value under the defaults section in the configuration file) and less than the value of the persistent connection idle timeout (connect_timeout)." -msgstr "持続的接続アイドルタイムアウトの値を増やします。注意: この値は、SSH タイムアウト値 (設定ファイルのデフォルトセクションの下のタイムアウト値) より大きく、永続的接続アイドルタイムアウト値 (connect_timeout) より小さくする必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:571 -msgid "Timeout issue due to platform specific login menu with ``network_cli`` connection type" -msgstr "``network_cli`` 接続タイプを持つプラットフォーム固有のログインメニューによるタイムアウトの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:573 -msgid "In Ansible 2.9 and later, the network_cli connection plugin configuration options are added to handle the platform specific login menu. These options can be set as group/host or tasks variables." -msgstr "Ansible 2.9 以降では、プラットフォーム固有のログインメニューを処理するために network_cli connection プラグイン設定オプションが追加されました。これらのオプションは、グループ/ホストまたはタスク変数として設定できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:577 -msgid "Example: Handle single login menu prompts with host variables" -msgstr "例: ホスト変数を使用した 1 つのログインメニュープロンプトを処理します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:588 -msgid "Example: Handle remote host multiple login menu prompts with host variables" -msgstr "例: ホスト変数を使用したリモートホストの複数のログインメニュープロンプトを処理します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:602 -msgid "To handle multiple login menu prompts:" -msgstr "複数のログインメニュープロンプトを処理するには、以下を行います。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:604 -msgid "The values of ``ansible_terminal_initial_prompt`` and ``ansible_terminal_initial_answer`` should be a list." -msgstr "``ansible_terminal_initial_prompt`` および ``ansible_terminal_initial_answer`` の値は一覧形式である必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:605 -msgid "The prompt sequence should match the answer sequence." -msgstr "プロンプトシーケンスは、応答シーケンスに一致する必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:606 -msgid "The value of ``ansible_terminal_initial_prompt_checkall`` should be set to ``True``." -msgstr "``ansible_terminal_initial_prompt_checkall`` の値は ``True`` に設定する必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:608 -msgid "If all the prompts in sequence are not received from remote host at the time connection initialization it will result in a timeout." -msgstr "接続の初期化時に、リモートホストからシーケンス内のすべてのプロンプトを受け取らないと、タイムアウトが生じます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:614 -msgid "This section details issues are caused by issues with the Playbook itself." -msgstr "本セクションでは、Playbook 自体の問題が原因で発生する問題を詳しく説明します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:617 -msgid "Error: \"Unable to enter configuration mode\"" -msgstr "Error: \"Unable to enter configuration mode\"" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:619 -msgid "**Platforms:** Arista EOS and Cisco IOS" -msgstr "**プラットフォーム:** Arista EOS および Cisco IOS" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:621 -msgid "This occurs when you attempt to run a task that requires privileged mode in a user mode shell." -msgstr "これは、ユーザーモードシェルで特権モードを必要とするタスクを実行しようとすると発生します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:637 -msgid "Use ``connection: ansible.netcommon.network_cli`` and ``become: yes``" -msgstr "``connection: ansible.netcommon.network_cli`` および ``become: yes`` の使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:641 -msgid "Proxy Issues" -msgstr "プロキシーの問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:646 -msgid "delegate_to vs ProxyCommand" -msgstr "delegate_to 対 ProxyCommand" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:648 -msgid "In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` transport, network modules support the use of ``ProxyCommand``." -msgstr "bastion または中間ジャンプホストを使用して ``cli`` トランスポートでネットワークデバイスに接続するために、ネットワークモジュールは ``ProxyCommand`` の使用に対応します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:651 -msgid "To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory file to specify the proxy host." -msgstr "``ProxyCommand`` を使用するには、Ansible インベントリーファイルでプロキシー設定を設定して、プロキシーホストを指定します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:664 -msgid "With the configuration above, simply build and run the playbook as normal with no additional changes necessary. The network module will now connect to the network device by first connecting to the host specified in ``ansible_ssh_common_args``, which is ``bastion01`` in the above example." -msgstr "上記の設定では、追加の変更を必要とせずに、通常どおり Playbook をビルドして実行します。ネットワークモジュールは、最初に ``ansible_ssh_common_args`` で指定したホスト (上記の例は ``bastion01``) に接続して、ネットワークデバイスに接続します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:669 -msgid "You can also set the proxy target for all hosts by using environment variables." -msgstr "環境変数を使用して、すべてのホストのプロキシーターゲットを設定することもできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:676 -msgid "Using bastion/jump host with netconf connection" -msgstr "netconf 接続での bastion/ジャンプホストの使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:679 -msgid "Enabling jump host setting" -msgstr "ジャンプホスト設定の有効化" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:685 -msgid "Bastion/jump host with netconf connection can be enabled by:" -msgstr "netconf 接続を持つ bastion/ジャンプホストは、以下で有効にできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:683 -msgid "Setting Ansible variable ``ansible_netconf_ssh_config`` either to ``True`` or custom ssh config file path" -msgstr "Ansible 変数 ``ansible_netconf_ssh_config`` を ``True`` またはカスタムの ssh 設定ファイルパスに設定" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:684 -msgid "Setting environment variable ``ANSIBLE_NETCONF_SSH_CONFIG`` to ``True`` or custom ssh config file path" -msgstr "環境変数 ``ANSIBLE_NETCONF_SSH_CONFIG`` を ``True`` またはカスタムの ssh 設定ファイルパスに設定" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:685 -msgid "Setting ``ssh_config = 1`` or ``ssh_config = `` under ``netconf_connection`` section" -msgstr "``ssh_config = 1`` セクションの下に ``ssh_config = `` または ``netconf_connection`` の設定" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:687 -msgid "If the configuration variable is set to 1 the proxycommand and other ssh variables are read from default ssh config file (~/.ssh/config)." -msgstr "設定変数が 1 に設定されている場合、proxycommand およびその他の ssh 変数はデフォルトの ssh 設定ファイル (~/.ssh/config) から読み込まれます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:690 -msgid "If the configuration variable is set to file path the proxycommand and other ssh variables are read from the given custom ssh file path" -msgstr "設定変数がファイルパスに設定されていると、proxycommand およびその他の ssh 変数は指定のカスタム ssh ファイルパスから読み込まれます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:694 -msgid "Example ssh config file (~/.ssh/config)" -msgstr "ssh 設定ファイルの例 (~/.ssh/config)" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:721 -msgid "Example Ansible inventory file" -msgstr "Ansible インベントリーファイルの例" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:735 -msgid "Using ``ProxyCommand`` with passwords through variables" -msgstr "変数を介したパスワードでの ``ProxyCommand`` の使用" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:737 -msgid "By design, SSH doesn't support providing passwords through environment variables. This is done to prevent secrets from leaking out, for example in ``ps`` output." -msgstr "設計上、SSH は環境変数経由でのパスワードの提供をサポートしません。これは、``ps`` の出力などに、シークレットがリークすることを防ぐためです。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:740 -msgid "We recommend using SSH Keys, and if needed an ssh-agent, rather than passwords, where ever possible." -msgstr "SSH 鍵を使用することを推奨します。必要に応じて、可能な場合は、パスワードではなく ssh-agent を使用することが推奨されます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:743 -msgid "Miscellaneous Issues" -msgstr "その他の問題" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:747 -msgid "Intermittent failure while using ``ansible.netcommon.network_cli`` connection type" -msgstr "``ansible.netcommon.network_cli`` 接続タイプの使用中に断続的な失敗" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:749 -msgid "If the command prompt received in response is not matched correctly within the ``ansible.netcommon.network_cli`` connection plugin the task might fail intermittently with truncated response or with the error message ``operation requires privilege escalation``. Starting in 2.7.1 a new buffer read timer is added to ensure prompts are matched properly and a complete response is send in output. The timer default value is 0.2 seconds and can be adjusted on a per task basis or can be set globally in seconds." -msgstr "応答で受け取ったコマンドプロンプトが ``ansible.netcommon.network_cli`` connection プラグイン内で正しく一致しないと、タスクが断続的に失敗し、応答が切り捨てられるか、エラーメッセージ ``operation requires privilege escalation`` が表示されることがあります。2.7.1 以降、プロンプトが正しく一致し、完全な応答が出力に送信されるように、新しいバッファ読み取りタイマーが追加されました。タイマーのデフォルト値は 0.2 秒で、タスクごとに調整することも、秒単位でグローバルに設定することもできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:756 -msgid "Example Per task timer setting" -msgstr "タスクタイマーごとの設定例" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:775 -msgid "This timer delay per command executed on remote host can be disabled by setting the value to zero." -msgstr "リモートホストで実行されるコマンド別のこのタイマー遅延は、値をゼロに設定すると無効にできます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:779 -msgid "Task failure due to mismatched error regex within command response using ``ansible.netcommon.network_cli`` connection type" -msgstr "``ansible.netcommon.network_cli`` 接続タイプを使用したコマンド応答内のエラー正規表現の不一致によるタスクの失敗" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:781 -msgid "In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration options are added to handle the stdout and stderr regex to identify if the command execution response consist of a normal response or an error response. These options can be set group/host variables or as tasks variables." -msgstr "Ansible 2.9 以降では、``ansible.netcommon.network_cli`` connection プラグイン設定オプションが追加され、標準出力と標準エラーの正規表現を処理して、コマンド実行応答が通常の応答かエラー応答かを識別します。これらのオプションは、グループ/ホスト変数またはタスク変数として設定できます。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:786 -msgid "Example: For mismatched error response" -msgstr "例: 不一致のエラー応答の場合" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:796 -msgid "Playbook run output:" -msgstr "Playbook 実行の出力:" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:809 -msgid "Modify the error regex for individual task." -msgstr "個々のタスクのエラー正規表現を変更します。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:822 -msgid "The terminal plugin regex options ``ansible_terminal_stderr_re`` and ``ansible_terminal_stdout_re`` have ``pattern`` and ``flags`` as keys. The value of the ``flags`` key should be a value that is accepted by the ``re.compile`` python method." -msgstr "端末プラグインの正規表現オプション ``ansible_terminal_stderr_re`` および ``ansible_terminal_stdout_re`` は、``pattern`` と ``flags`` をキーとします。``flags`` キーの値は、``re.compile`` python メソッドで許可される値である必要があります。" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:828 -msgid "Intermittent failure while using ``ansible.netcommon.network_cli`` connection type due to slower network or remote target host" -msgstr "低速ネットワークまたはリモートターゲットホストによる ``ansible.netcommon.network_cli`` 接続タイプの使用時の断続的な失敗" - -#: ../../rst/network/user_guide/network_debug_troubleshooting.rst:830 -msgid "In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration option is added to control the number of attempts to connect to a remote host. The default number of attempts is three. After every retry attempt the delay between retries is increased by power of 2 in seconds until either the maximum attempts are exhausted or either the ``persistent_command_timeout`` or ``persistent_connect_timeout`` timers are triggered." -msgstr "Ansible 2.9 以降では、リモートホストへの接続の試行回数を制御するために、``ansible.netcommon.network_cli`` connection プラグイン設定オプションが追加されました。デフォルトの試行回数は 3 回です。再試行のたびに、最大試行回数がなくなるか、``persistent_command_timeout`` または ``persistent_connect_timeout`` タイマーのいずれかが発生するまで、再試行間の遅延は 2 の累乗 (秒) ずつ増加します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:5 -msgid "Network Resource Modules" -msgstr "ネットワークリソースモジュール" - -#: ../../rst/network/user_guide/network_resource_modules.rst:7 -msgid "Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices." -msgstr "Ansible ネットワークリソースモジュールは、さまざまなネットワークデバイスの管理方法を簡素化し、標準化します。ネットワークデバイスは、ネットワークサービスに適用されるセクション (インターフェースや VLAN など) に設定を分割します。Ansible ネットワークリソースモジュールはこれを利用して、ネットワークデバイス設定内でサブセクションや *リソース* を設定することができます。ネットワークリソースモジュールは、異なるネットワークデバイス間で一貫したエクスペリエンスを提供します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:14 -msgid "Network resource module states" -msgstr "ネットワークリソースモジュールの状態" - -#: ../../rst/network/user_guide/network_resource_modules.rst:16 -msgid "You use the network resource modules by assigning a state to what you want the module to do. The resource modules support the following states:" -msgstr "モジュールの動作に状態を割り当てて、ネットワークリソースモジュールを使用します。リソースモジュールは以下の状態をサポートします。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:37 -msgid "Ansible parses the configuration from the ``running_config`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline." -msgstr "Ansible は、``running_config`` オプションから、その結果内の ``parsed`` キーの Ansible 構造化データに設定を解析します。この設定は、ネットワークデバイスから設定が収集されないため、この状態をオフラインで使用できる点に注意してください。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:40 -msgid "Using network resource modules" -msgstr "ネットワークリソースモジュールの使用" - -#: ../../rst/network/user_guide/network_resource_modules.rst:42 -msgid "This example configures the L3 interface resource on a Cisco IOS device, based on different state settings." -msgstr "この例では、異なる状態設定に基づいて、Cisco IOS デバイスで L3 インターフェースリソースを設定します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:51 -msgid "The following table shows an example of how an initial resource configuration changes with this task for different states." -msgstr "以下の表は、このタスクで初期リソースの設定が異なる状態で変化する例を示しています。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:54 -msgid "Resource starting configuration" -msgstr "リソース起動の設定" - -#: ../../rst/network/user_guide/network_resource_modules.rst:54 -msgid "task-provided configuration (YAML)" -msgstr "タスク提供設定 (YAML)" - -#: ../../rst/network/user_guide/network_resource_modules.rst:54 -msgid "Final resource configuration on device" -msgstr "デバイスの最終的なリソース設定" - -#: ../../rst/network/user_guide/network_resource_modules.rst:61 -msgid "*merged*" -msgstr "*マージ*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:69 -msgid "*replaced*" -msgstr "*置き換え済*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:73 -msgid "*overridden*" -msgstr "*上書き済*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:73 -msgid "Incorrect use case. This would remove all interfaces from the device" -msgstr "誤ったユースケース。これにより、デバイスからすべてのインターフェースが削除されます。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:75 -msgid "(including the mgmt interface) except" -msgstr "(mgmt インターフェースを含む) 以下を除く" - -#: ../../rst/network/user_guide/network_resource_modules.rst:76 -msgid "the configured loopback100" -msgstr "設定されている loopback100" - -#: ../../rst/network/user_guide/network_resource_modules.rst:81 -msgid "*deleted*" -msgstr "*削除済*" - -#: ../../rst/network/user_guide/network_resource_modules.rst:85 -msgid "Network resource modules return the following details:" -msgstr "ネットワークリソースモジュールは、以下の詳細を返します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:87 -msgid "The *before* state - the existing resource configuration before the task was executed." -msgstr "*before* 状態 - タスクの実行前の既存リソース設定。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:88 -msgid "The *after* state - the new resource configuration that exists on the network device after the task was executed." -msgstr "*after* 状態 - タスク実行後にネットワークデバイスに存在する新しいリソース設定。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:89 -msgid "Commands - any commands configured on the device." -msgstr "コマンド - このデバイスに設定されるすべてのコマンド。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:122 -msgid "Example: Verifying the network device configuration has not changed" -msgstr "例: ネットワークデバイス設定が変更されていないことを確認" - -#: ../../rst/network/user_guide/network_resource_modules.rst:124 -msgid "The following playbook uses the :ref:`arista.eos.eos_l3_interfaces ` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`arista.eos.eos_facts ` directly to the ``arista.eos.eos_l3_interfaces`` module." -msgstr "以下の Playbook は、:ref:`arista.eos.eos_l3_interfaces ` モジュールを使用してネットワークデバイス設定のサブセット (レイヤー 3 インターフェースのみ) を収集し、情報が正確であり、変更されていないことを確認します。この Playbook は、:ref:`arista.eos.eos_facts ` の結果を直接 ``arista.eos.eos_l3_interfaces`` モジュールに渡します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:148 -msgid "Example: Acquiring and updating VLANs on a network device" -msgstr "例: ネットワークデバイスの VLAN の調整および更新" - -#: ../../rst/network/user_guide/network_resource_modules.rst:150 -msgid "This example shows how you can use resource modules to:" -msgstr "以下の例は、リソースモジュールを使用して以下を行う方法を示しています。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:152 -msgid "Retrieve the current configuration on a network device." -msgstr "ネットワークデバイスの現在の設定を取得します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:153 -msgid "Save that configuration locally." -msgstr "その設定をローカルに保存します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:154 -msgid "Update that configuration and apply it to the network device." -msgstr "その設定を更新して、ネットワークデバイスに適用します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:156 -msgid "This example uses the ``cisco.ios.ios_vlans`` resource module to retrieve and update the VLANs on an IOS device." -msgstr "この例では、``cisco.ios.ios_vlans`` リソースモジュールを使用して、IOS デバイスの VLAN を取得および更新します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:158 -msgid "Retrieve the current IOS VLAN configuration:" -msgstr "現在の IOS VLAN 設定を取得します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:170 -msgid "Store the VLAN configuration locally:" -msgstr "VLAN 設定をローカルに保存します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:179 -msgid "Modify the stored file to update the VLAN configuration locally." -msgstr "保存したファイルを変更して、VLAN 設定をローカルに更新します。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:181 -msgid "Merge the updated VLAN configuration with the existing configuration on the device:" -msgstr "更新された VLAN 設定を、デバイス上の既存の設定とマージします。" - -#: ../../rst/network/user_guide/network_resource_modules.rst:193 -msgid "`Network Features in Ansible 2.9 `_" -msgstr "`Network Features in Ansible 2.9 `_" - -#: ../../rst/network/user_guide/network_resource_modules.rst:194 -msgid "A introductory blog post on network resource modules." -msgstr "ネットワークリソースモジュールに関する入門ブログの投稿" - -#: ../../rst/network/user_guide/network_resource_modules.rst:195 -msgid "`Deep Dive into Network Resource Modules `_" -msgstr "`Deep Dive into Network Resource Modules `_" - -#: ../../rst/network/user_guide/network_resource_modules.rst:196 -msgid "A deeper dive presentation into network resource modules." -msgstr "ネットワークリソースモジュールの詳細な説明" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:5 -msgid "Working with command output and prompts in network modules" -msgstr "ネットワークモジュールのコマンド出力およびプロンプトの使用" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:11 -msgid "Conditionals in networking modules" -msgstr "ネットワークモジュールの条件" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:13 -msgid "Ansible allows you to use conditionals to control the flow of your playbooks. Ansible networking command modules use the following unique conditional statements." -msgstr "Ansible では、条件を使用して Playbook のフローを制御できます。Ansible ネットワークコマンドモジュールは、以下の固有の条件分岐文を使用します。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:15 -msgid "``eq`` - Equal" -msgstr "``eq`` - 等しい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:16 -msgid "``neq`` - Not equal" -msgstr "``neq`` - 等しくない" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:17 -msgid "``gt`` - Greater than" -msgstr "``gt`` - より大きい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:18 -msgid "``ge`` - Greater than or equal" -msgstr "``ge`` - より大きいか等しい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:19 -msgid "``lt`` - Less than" -msgstr "``lt`` - より小さい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:20 -msgid "``le`` - Less than or equal" -msgstr "``le`` - より小さいか等しい" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:21 -msgid "``contains`` - Object contains specified item" -msgstr "``contains`` - オブジェクトに指定された項目が含まれる" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:24 -msgid "Conditional statements evaluate the results from the commands that are executed remotely on the device. Once the task executes the command set, the ``wait_for`` argument can be used to evaluate the results before returning control to the Ansible playbook." -msgstr "条件文は、デバイス上でリモートに実行されるコマンドの結果を評価します。タスクがコマンドセットを実行すると、Ansible Playbook に制御を戻す前に、``wait_for`` 引数を使用して結果を評価できます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:41 -msgid "In the above example task, the command :code:`show interface Ethernet4 | json` is executed on the remote device and the results are evaluated. If the path :code:`(result[0].interfaces.Ethernet4.interfaceStatus)` is not equal to \"connected\", then the command is retried. This process continues until either the condition is satisfied or the number of retries has expired (by default, this is 10 retries at 1 second intervals)." -msgstr "上記のタスク例では、リモートデバイスで command :code:`show interface Ethernet4 | json` が実行され、結果が評価されます。path :code:`(result[0].interfaces.Ethernet4.interfaceStatus)`が「connected」になっていなければ、コマンドは再試行されます。この処理は、条件が満たされるか、再試行回数が期限切れになる (デフォルトでは、1 秒間隔で 10 回の再試行) まで継続されます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:49 -msgid "The commands module can also evaluate more than one set of command results in an interface. For instance:" -msgstr "また、commands モジュールは、1 つのインターフェースで複数のコマンド結果を評価することもできます。たとえば、以下のようになります。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:64 -msgid "In the above example, two commands are executed on the remote device, and the results are evaluated. By specifying the result index value (0 or 1), the correct result output is checked against the conditional." -msgstr "上記の例では、2 つのコマンドがリモートデバイスで実行され、結果が評価されます。結果のインデックス値 (0 または 1) を指定することで、条件に対して正しい結果出力が確認されます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:69 -msgid "The ``wait_for`` argument must always start with result and then the command index in ``[]``, where ``0`` is the first command in the commands list, ``1`` is the second command, ``2`` is the third and so on." -msgstr "``wait_for`` 引数は、必ず結果で、次に ``[]`` のコマンドインデックスが必要です。``0`` はコマンドリストの最初のコマンド、``1`` は 2 番目のコマンド、``2`` は 3 番目のコマンドなどになります。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:75 -msgid "Handling prompts in network modules" -msgstr "ネットワークモジュールのプロンプトの処理" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:77 -msgid "Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`cisco.ios.ios_command ` and :ref:`cisco.nxos.nxos_command ` can handle this with a ``prompt`` parameter." -msgstr "ネットワークデバイスは、デバイスの変更を実行する前にプロンプトの回答が必要になる場合があります。:ref:`cisco.ios.ios_command ` および :ref:`cisco.nxos.nxos_command ` などの個別ネットワークモジュールは ``prompt`` パラメーターでこれを処理できます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:81 -msgid "``prompt`` is a Python regex. If you add special characters such as ``?`` in the ``prompt`` value, the prompt won't match and you will get a timeout. To avoid this, ensure that the ``prompt`` value is a Python regex that matches the actual device prompt. Any special characters must be handled correctly in the ``prompt`` regex." -msgstr "``prompt`` は Python の正規表現です。``prompt`` 値に ``?`` などの特殊文字を追加すると、プロンプトが一致せず、タイムアウトが発生します。これを回避するには、``prompt`` 値が実際のデバイスプロンプトと一致する Python 正規表現であることを確認します。特殊文字は、``prompt`` 正規表現で正しく処理する必要があります。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:83 -msgid "You can also use the :ref:`ansible.netcommon.cli_command ` to handle multiple prompts." -msgstr ":ref:`ansible.netcommon.cli_command ` を使用して、複数のプロンプトを処理することもできます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:101 -msgid "You must list the prompt and the answers in the same order (that is, prompt[0] is answered by answer[0])." -msgstr "プロンプトと回答を同じ順序で一覧表示する必要があります (つまり、prompt[0] には answer[0] で応答します)。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:103 -msgid "In the above example, ``check_all: True`` ensures that the task gives the matching answer to each prompt. Without that setting, a task with multiple prompts would give the first answer to every prompt." -msgstr "上記の例では、``check_all: True`` により、タスクが各プロンプトに一致する応答を返すようにします。この設定がないと、複数のプロンプトがあるタスクでは、すべてのプロンプトに対して最初の応答が表示されます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:105 -msgid "In the following example, the second answer would be ignored and ``y`` would be the answer given to both prompts. That is, this task only works because both answers are identical. Also notice again that ``prompt`` must be a Python regex, which is why the ``?`` is escaped in the first prompt." -msgstr "次の例では、2 番目の回答は無視され、両方のプロンプトに ``y`` が入力されます。つまり、このタスクが機能するのは、両方の答えが同じだからです。また、``prompt`` は Python の正規表現でなければならないことにも注意してください。このため、``?`` は最初のプロンプトでエスケープされます。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:123 -msgid "`Rebooting network devices with Ansible `_" -msgstr "`Rebooting network devices with Ansible `_" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:123 -msgid "Examples using ``wait_for``, ``wait_for_connection``, and ``prompt`` for network devices." -msgstr "ネットワークデバイス用に ``wait_for``、``wait_for_connection``、および ``prompt`` を使用する例。" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:125 -msgid "`Deep dive on cli_command `_" -msgstr "`Deep dive on cli_command `_" - -#: ../../rst/network/user_guide/network_working_with_command_output.rst:126 -msgid "Detailed overview of how to use the ``cli_command``." -msgstr "``cli_command`` の使用方法に関する詳細な概要" - -#: ../../rst/network/user_guide/platform_ce.rst:5 -msgid "CloudEngine OS Platform Options" -msgstr "CloudEngine OS プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_ce.rst:7 -msgid "CloudEngine CE OS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "CloudEngine CE OS は `community.network `_ コレクションの一部で、複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能し、どのように使用されるかを詳細に説明します。" - -#: ../../rst/network/user_guide/platform_ce.rst:13 -#: ../../rst/network/user_guide/platform_cnos.rst:13 -#: ../../rst/network/user_guide/platform_dellos10.rst:13 -#: ../../rst/network/user_guide/platform_dellos6.rst:13 -#: ../../rst/network/user_guide/platform_dellos9.rst:13 -#: ../../rst/network/user_guide/platform_enos.rst:13 -#: ../../rst/network/user_guide/platform_eos.rst:13 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:13 -#: ../../rst/network/user_guide/platform_exos.rst:13 -#: ../../rst/network/user_guide/platform_frr.rst:13 -#: ../../rst/network/user_guide/platform_icx.rst:13 -#: ../../rst/network/user_guide/platform_ios.rst:13 -#: ../../rst/network/user_guide/platform_iosxr.rst:13 -#: ../../rst/network/user_guide/platform_ironware.rst:13 -#: ../../rst/network/user_guide/platform_junos.rst:13 -#: ../../rst/network/user_guide/platform_meraki.rst:13 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:13 -#: ../../rst/network/user_guide/platform_netvisor.rst:14 -#: ../../rst/network/user_guide/platform_nos.rst:14 -#: ../../rst/network/user_guide/platform_nxos.rst:13 -#: ../../rst/network/user_guide/platform_routeros.rst:14 -#: ../../rst/network/user_guide/platform_slxos.rst:14 -#: ../../rst/network/user_guide/platform_voss.rst:14 -#: ../../rst/network/user_guide/platform_vyos.rst:13 -#: ../../rst/network/user_guide/platform_weos4.rst:14 -msgid "Connections available" -msgstr "利用可能な接続" - -#: ../../rst/network/user_guide/platform_ce.rst:19 -#: ../../rst/network/user_guide/platform_cnos.rst:19 -#: ../../rst/network/user_guide/platform_dellos10.rst:19 -#: ../../rst/network/user_guide/platform_dellos6.rst:19 -#: ../../rst/network/user_guide/platform_dellos9.rst:19 -#: ../../rst/network/user_guide/platform_enos.rst:19 -#: ../../rst/network/user_guide/platform_eos.rst:19 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:19 -#: ../../rst/network/user_guide/platform_exos.rst:20 -#: ../../rst/network/user_guide/platform_frr.rst:19 -#: ../../rst/network/user_guide/platform_icx.rst:19 -#: ../../rst/network/user_guide/platform_ios.rst:19 -#: ../../rst/network/user_guide/platform_iosxr.rst:19 -#: ../../rst/network/user_guide/platform_ironware.rst:19 -#: ../../rst/network/user_guide/platform_junos.rst:19 -#: ../../rst/network/user_guide/platform_netvisor.rst:20 -#: ../../rst/network/user_guide/platform_nos.rst:20 -#: ../../rst/network/user_guide/platform_nxos.rst:19 -#: ../../rst/network/user_guide/platform_routeros.rst:20 -#: ../../rst/network/user_guide/platform_slxos.rst:20 -#: ../../rst/network/user_guide/platform_voss.rst:20 -#: ../../rst/network/user_guide/platform_vyos.rst:19 -#: ../../rst/network/user_guide/platform_weos4.rst:20 -msgid "CLI" -msgstr "CLI" - -#: ../../rst/network/user_guide/platform_ce.rst:19 -#: ../../rst/network/user_guide/platform_iosxr.rst:19 -#: ../../rst/network/user_guide/platform_junos.rst:19 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:18 -msgid "NETCONF" -msgstr "NETCONF" - -#: ../../rst/network/user_guide/platform_ce.rst:23 -#: ../../rst/network/user_guide/platform_cnos.rst:21 -#: ../../rst/network/user_guide/platform_dellos10.rst:21 -#: ../../rst/network/user_guide/platform_dellos6.rst:21 -#: ../../rst/network/user_guide/platform_dellos9.rst:21 -#: ../../rst/network/user_guide/platform_enos.rst:21 -#: ../../rst/network/user_guide/platform_eos.rst:21 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:21 -#: ../../rst/network/user_guide/platform_exos.rst:22 -#: ../../rst/network/user_guide/platform_frr.rst:21 -#: ../../rst/network/user_guide/platform_icx.rst:21 -#: ../../rst/network/user_guide/platform_ios.rst:21 -#: ../../rst/network/user_guide/platform_iosxr.rst:25 -#: ../../rst/network/user_guide/platform_ironware.rst:21 -#: ../../rst/network/user_guide/platform_junos.rst:24 -#: ../../rst/network/user_guide/platform_netvisor.rst:22 -#: ../../rst/network/user_guide/platform_nos.rst:22 -#: ../../rst/network/user_guide/platform_nxos.rst:21 -#: ../../rst/network/user_guide/platform_routeros.rst:22 -#: ../../rst/network/user_guide/platform_slxos.rst:22 -#: ../../rst/network/user_guide/platform_voss.rst:22 -#: ../../rst/network/user_guide/platform_vyos.rst:21 -#: ../../rst/network/user_guide/platform_weos4.rst:22 -msgid "SSH" -msgstr "SSH" - -#: ../../rst/network/user_guide/platform_ce.rst:25 -#: ../../rst/network/user_guide/platform_cnos.rst:23 -#: ../../rst/network/user_guide/platform_dellos10.rst:23 -#: ../../rst/network/user_guide/platform_dellos6.rst:23 -#: ../../rst/network/user_guide/platform_dellos9.rst:23 -#: ../../rst/network/user_guide/platform_enos.rst:23 -#: ../../rst/network/user_guide/platform_eos.rst:23 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:23 -#: ../../rst/network/user_guide/platform_exos.rst:24 -#: ../../rst/network/user_guide/platform_frr.rst:23 -#: ../../rst/network/user_guide/platform_icx.rst:23 -#: ../../rst/network/user_guide/platform_ios.rst:23 -#: ../../rst/network/user_guide/platform_iosxr.rst:27 -#: ../../rst/network/user_guide/platform_ironware.rst:23 -#: ../../rst/network/user_guide/platform_junos.rst:26 -#: ../../rst/network/user_guide/platform_meraki.rst:23 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:25 -#: ../../rst/network/user_guide/platform_netvisor.rst:24 -#: ../../rst/network/user_guide/platform_nos.rst:24 -#: ../../rst/network/user_guide/platform_nxos.rst:23 -#: ../../rst/network/user_guide/platform_routeros.rst:24 -#: ../../rst/network/user_guide/platform_slxos.rst:24 -#: ../../rst/network/user_guide/platform_voss.rst:24 -#: ../../rst/network/user_guide/platform_vyos.rst:23 -#: ../../rst/network/user_guide/platform_weos4.rst:24 -msgid "Credentials" -msgstr "認証情報" - -#: ../../rst/network/user_guide/platform_ce.rst:25 -#: ../../rst/network/user_guide/platform_cnos.rst:23 -#: ../../rst/network/user_guide/platform_dellos10.rst:23 -#: ../../rst/network/user_guide/platform_dellos6.rst:23 -#: ../../rst/network/user_guide/platform_dellos9.rst:23 -#: ../../rst/network/user_guide/platform_enos.rst:23 -#: ../../rst/network/user_guide/platform_eos.rst:23 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:23 -#: ../../rst/network/user_guide/platform_exos.rst:24 -#: ../../rst/network/user_guide/platform_frr.rst:23 -#: ../../rst/network/user_guide/platform_icx.rst:23 -#: ../../rst/network/user_guide/platform_ios.rst:23 -#: ../../rst/network/user_guide/platform_iosxr.rst:27 -#: ../../rst/network/user_guide/platform_ironware.rst:23 -#: ../../rst/network/user_guide/platform_junos.rst:26 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:25 -#: ../../rst/network/user_guide/platform_netvisor.rst:24 -#: ../../rst/network/user_guide/platform_nos.rst:24 -#: ../../rst/network/user_guide/platform_nxos.rst:23 -#: ../../rst/network/user_guide/platform_routeros.rst:24 -#: ../../rst/network/user_guide/platform_slxos.rst:24 -#: ../../rst/network/user_guide/platform_voss.rst:24 -#: ../../rst/network/user_guide/platform_vyos.rst:23 -#: ../../rst/network/user_guide/platform_weos4.rst:24 -msgid "uses SSH keys / SSH-agent if present" -msgstr "SSH キー/SSH-agent が存在する場合は使用します" - -#: ../../rst/network/user_guide/platform_ce.rst:27 -#: ../../rst/network/user_guide/platform_cnos.rst:25 -#: ../../rst/network/user_guide/platform_dellos10.rst:25 -#: ../../rst/network/user_guide/platform_dellos6.rst:25 -#: ../../rst/network/user_guide/platform_dellos9.rst:25 -#: ../../rst/network/user_guide/platform_enos.rst:25 -#: ../../rst/network/user_guide/platform_eos.rst:25 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:25 -#: ../../rst/network/user_guide/platform_exos.rst:26 -#: ../../rst/network/user_guide/platform_frr.rst:25 -#: ../../rst/network/user_guide/platform_icx.rst:25 -#: ../../rst/network/user_guide/platform_ios.rst:25 -#: ../../rst/network/user_guide/platform_iosxr.rst:29 -#: ../../rst/network/user_guide/platform_ironware.rst:25 -#: ../../rst/network/user_guide/platform_junos.rst:28 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:27 -#: ../../rst/network/user_guide/platform_netvisor.rst:26 -#: ../../rst/network/user_guide/platform_nos.rst:26 -#: ../../rst/network/user_guide/platform_nxos.rst:25 -#: ../../rst/network/user_guide/platform_routeros.rst:26 -#: ../../rst/network/user_guide/platform_slxos.rst:26 -#: ../../rst/network/user_guide/platform_voss.rst:26 -#: ../../rst/network/user_guide/platform_vyos.rst:25 -#: ../../rst/network/user_guide/platform_weos4.rst:26 -msgid "accepts ``-u myuser -k`` if using password" -msgstr "パスワードを使用する場合に ``-u myuser -k`` を受け入れます。" - -#: ../../rst/network/user_guide/platform_ce.rst:29 -#: ../../rst/network/user_guide/platform_cnos.rst:27 -#: ../../rst/network/user_guide/platform_dellos10.rst:27 -#: ../../rst/network/user_guide/platform_dellos6.rst:27 -#: ../../rst/network/user_guide/platform_dellos9.rst:27 -#: ../../rst/network/user_guide/platform_enos.rst:27 -#: ../../rst/network/user_guide/platform_eos.rst:27 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:27 -#: ../../rst/network/user_guide/platform_exos.rst:28 -#: ../../rst/network/user_guide/platform_frr.rst:27 -#: ../../rst/network/user_guide/platform_icx.rst:27 -#: ../../rst/network/user_guide/platform_ios.rst:27 -#: ../../rst/network/user_guide/platform_iosxr.rst:31 -#: ../../rst/network/user_guide/platform_ironware.rst:27 -#: ../../rst/network/user_guide/platform_junos.rst:30 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:29 -#: ../../rst/network/user_guide/platform_netvisor.rst:28 -#: ../../rst/network/user_guide/platform_nos.rst:28 -#: ../../rst/network/user_guide/platform_nxos.rst:27 -#: ../../rst/network/user_guide/platform_routeros.rst:28 -#: ../../rst/network/user_guide/platform_slxos.rst:28 -#: ../../rst/network/user_guide/platform_voss.rst:28 -#: ../../rst/network/user_guide/platform_vyos.rst:27 -#: ../../rst/network/user_guide/platform_weos4.rst:28 -msgid "Indirect Access" -msgstr "間接アクセス" - -#: ../../rst/network/user_guide/platform_ce.rst:29 -msgid "via a bastion (jump host)" -msgstr "bastion (ジャンプホスト) を使用" - -#: ../../rst/network/user_guide/platform_ce.rst:31 -#: ../../rst/network/user_guide/platform_cnos.rst:29 -#: ../../rst/network/user_guide/platform_dellos10.rst:29 -#: ../../rst/network/user_guide/platform_dellos6.rst:29 -#: ../../rst/network/user_guide/platform_dellos9.rst:29 -#: ../../rst/network/user_guide/platform_enos.rst:29 -#: ../../rst/network/user_guide/platform_eos.rst:29 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:29 -#: ../../rst/network/user_guide/platform_exos.rst:30 -#: ../../rst/network/user_guide/platform_frr.rst:29 -#: ../../rst/network/user_guide/platform_icx.rst:29 -#: ../../rst/network/user_guide/platform_ios.rst:29 -#: ../../rst/network/user_guide/platform_iosxr.rst:33 -#: ../../rst/network/user_guide/platform_ironware.rst:29 -#: ../../rst/network/user_guide/platform_junos.rst:32 -#: ../../rst/network/user_guide/platform_meraki.rst:25 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:31 -#: ../../rst/network/user_guide/platform_netvisor.rst:30 -#: ../../rst/network/user_guide/platform_nos.rst:30 -#: ../../rst/network/user_guide/platform_nxos.rst:29 -#: ../../rst/network/user_guide/platform_routeros.rst:30 -#: ../../rst/network/user_guide/platform_slxos.rst:30 -#: ../../rst/network/user_guide/platform_voss.rst:30 -#: ../../rst/network/user_guide/platform_vyos.rst:29 -#: ../../rst/network/user_guide/platform_weos4.rst:30 -msgid "Connection Settings" -msgstr "接続設定" - -#: ../../rst/network/user_guide/platform_ce.rst:32 -#: ../../rst/network/user_guide/platform_exos.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:30 -msgid "``ansible_connection:``" -msgstr "``ansible_connection:``" - -#: ../../rst/network/user_guide/platform_ce.rst:32 -#: ../../rst/network/user_guide/platform_exos.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:30 -msgid "``ansible.netcommon.network_cli``" -msgstr "``ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_ce.rst:32 -#: ../../rst/network/user_guide/platform_iosxr.rst:34 -msgid "``ansible.netcommon.netconf``" -msgstr "``ansible.netcommon.netconf``" - -#: ../../rst/network/user_guide/platform_ce.rst:34 -#: ../../rst/network/user_guide/platform_cnos.rst:31 -#: ../../rst/network/user_guide/platform_dellos10.rst:31 -#: ../../rst/network/user_guide/platform_dellos6.rst:31 -#: ../../rst/network/user_guide/platform_dellos9.rst:31 -#: ../../rst/network/user_guide/platform_enos.rst:31 -#: ../../rst/network/user_guide/platform_eos.rst:33 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:31 -#: ../../rst/network/user_guide/platform_exos.rst:33 -#: ../../rst/network/user_guide/platform_frr.rst:31 -#: ../../rst/network/user_guide/platform_icx.rst:31 -#: ../../rst/network/user_guide/platform_ios.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:36 -#: ../../rst/network/user_guide/platform_ironware.rst:31 -#: ../../rst/network/user_guide/platform_junos.rst:35 -#: ../../rst/network/user_guide/platform_netvisor.rst:32 -#: ../../rst/network/user_guide/platform_nos.rst:32 -#: ../../rst/network/user_guide/platform_nxos.rst:32 -#: ../../rst/network/user_guide/platform_routeros.rst:32 -#: ../../rst/network/user_guide/platform_slxos.rst:32 -#: ../../rst/network/user_guide/platform_voss.rst:32 -#: ../../rst/network/user_guide/platform_vyos.rst:31 -#: ../../rst/network/user_guide/platform_weos4.rst:32 -msgid "|enable_mode|" -msgstr "|enable_mode|" - -#: ../../rst/network/user_guide/platform_ce.rst:34 -msgid "not supported by ce OS" -msgstr "ce OS ではサポートなし" - -#: ../../rst/network/user_guide/platform_ce.rst:36 -#: ../../rst/network/user_guide/platform_cnos.rst:35 -#: ../../rst/network/user_guide/platform_dellos10.rst:35 -#: ../../rst/network/user_guide/platform_dellos6.rst:35 -#: ../../rst/network/user_guide/platform_dellos9.rst:35 -#: ../../rst/network/user_guide/platform_enos.rst:35 -#: ../../rst/network/user_guide/platform_eos.rst:39 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:33 -#: ../../rst/network/user_guide/platform_exos.rst:35 -#: ../../rst/network/user_guide/platform_frr.rst:33 -#: ../../rst/network/user_guide/platform_icx.rst:34 -#: ../../rst/network/user_guide/platform_ios.rst:34 -#: ../../rst/network/user_guide/platform_iosxr.rst:38 -#: ../../rst/network/user_guide/platform_ironware.rst:35 -#: ../../rst/network/user_guide/platform_junos.rst:37 -#: ../../rst/network/user_guide/platform_meraki.rst:27 -#: ../../rst/network/user_guide/platform_netvisor.rst:34 -#: ../../rst/network/user_guide/platform_nos.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:36 -#: ../../rst/network/user_guide/platform_routeros.rst:34 -#: ../../rst/network/user_guide/platform_slxos.rst:34 -#: ../../rst/network/user_guide/platform_voss.rst:35 -#: ../../rst/network/user_guide/platform_vyos.rst:33 -#: ../../rst/network/user_guide/platform_weos4.rst:34 -msgid "Returned Data Format" -msgstr "返されるデータ形式" - -#: ../../rst/network/user_guide/platform_ce.rst:36 -#: ../../rst/network/user_guide/platform_iosxr.rst:38 -#: ../../rst/network/user_guide/platform_vyos.rst:33 -msgid "Refer to individual module documentation" -msgstr "各モジュールのドキュメンテーションを参照してください。" - -#: ../../rst/network/user_guide/platform_ce.rst:41 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` or ``ansible_connection=ansible.netcommon.network_cli`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.netconf`` または ``ansible_connection=ansible.netcommon.network_cli`` を使用してください。" - -#: ../../rst/network/user_guide/platform_ce.rst:44 -#: ../../rst/network/user_guide/platform_cnos.rst:43 -#: ../../rst/network/user_guide/platform_dellos10.rst:44 -#: ../../rst/network/user_guide/platform_dellos6.rst:43 -#: ../../rst/network/user_guide/platform_dellos9.rst:43 -#: ../../rst/network/user_guide/platform_enos.rst:45 -#: ../../rst/network/user_guide/platform_eos.rst:48 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:41 -#: ../../rst/network/user_guide/platform_exos.rst:43 -#: ../../rst/network/user_guide/platform_frr.rst:40 -#: ../../rst/network/user_guide/platform_icx.rst:41 -#: ../../rst/network/user_guide/platform_ios.rst:43 -#: ../../rst/network/user_guide/platform_iosxr.rst:47 -#: ../../rst/network/user_guide/platform_ironware.rst:44 -#: ../../rst/network/user_guide/platform_junos.rst:48 -#: ../../rst/network/user_guide/platform_netvisor.rst:42 -#: ../../rst/network/user_guide/platform_nos.rst:42 -#: ../../rst/network/user_guide/platform_nxos.rst:45 -#: ../../rst/network/user_guide/platform_routeros.rst:43 -#: ../../rst/network/user_guide/platform_slxos.rst:43 -#: ../../rst/network/user_guide/platform_voss.rst:44 -#: ../../rst/network/user_guide/platform_vyos.rst:42 -#: ../../rst/network/user_guide/platform_weos4.rst:42 -msgid "Using CLI in Ansible" -msgstr "Ansible での CLI の使用" - -#: ../../rst/network/user_guide/platform_ce.rst:47 -msgid "Example CLI inventory ``[ce:vars]``" -msgstr "CLI インベントリーの例 ``[ce:vars]``" - -#: ../../rst/network/user_guide/platform_ce.rst:59 -#: ../../rst/network/user_guide/platform_cnos.rst:60 -#: ../../rst/network/user_guide/platform_dellos10.rst:61 -#: ../../rst/network/user_guide/platform_dellos6.rst:60 -#: ../../rst/network/user_guide/platform_dellos9.rst:60 -#: ../../rst/network/user_guide/platform_enos.rst:62 -#: ../../rst/network/user_guide/platform_eos.rst:65 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:55 -#: ../../rst/network/user_guide/platform_exos.rst:57 -#: ../../rst/network/user_guide/platform_frr.rst:54 -#: ../../rst/network/user_guide/platform_icx.rst:58 -#: ../../rst/network/user_guide/platform_ios.rst:60 -#: ../../rst/network/user_guide/platform_iosxr.rst:62 -#: ../../rst/network/user_guide/platform_ironware.rst:61 -#: ../../rst/network/user_guide/platform_junos.rst:63 -#: ../../rst/network/user_guide/platform_netvisor.rst:56 -#: ../../rst/network/user_guide/platform_nos.rst:56 -#: ../../rst/network/user_guide/platform_nxos.rst:62 -#: ../../rst/network/user_guide/platform_routeros.rst:60 -#: ../../rst/network/user_guide/platform_slxos.rst:57 -#: ../../rst/network/user_guide/platform_voss.rst:60 -#: ../../rst/network/user_guide/platform_vyos.rst:56 -#: ../../rst/network/user_guide/platform_weos4.rst:56 -msgid "If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration." -msgstr "SSH キー (ssh-agent を含む) を使用している場合は、``ansible_password`` 設定を削除できます。" - -#: ../../rst/network/user_guide/platform_ce.rst:60 -#: ../../rst/network/user_guide/platform_cnos.rst:61 -#: ../../rst/network/user_guide/platform_dellos10.rst:62 -#: ../../rst/network/user_guide/platform_dellos6.rst:61 -#: ../../rst/network/user_guide/platform_dellos9.rst:61 -#: ../../rst/network/user_guide/platform_enos.rst:63 -#: ../../rst/network/user_guide/platform_eos.rst:66 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:56 -#: ../../rst/network/user_guide/platform_exos.rst:58 -#: ../../rst/network/user_guide/platform_frr.rst:55 -#: ../../rst/network/user_guide/platform_icx.rst:59 -#: ../../rst/network/user_guide/platform_ios.rst:61 -#: ../../rst/network/user_guide/platform_iosxr.rst:63 -#: ../../rst/network/user_guide/platform_ironware.rst:62 -#: ../../rst/network/user_guide/platform_junos.rst:64 -#: ../../rst/network/user_guide/platform_netvisor.rst:57 -#: ../../rst/network/user_guide/platform_nos.rst:57 -#: ../../rst/network/user_guide/platform_nxos.rst:63 -#: ../../rst/network/user_guide/platform_routeros.rst:61 -#: ../../rst/network/user_guide/platform_slxos.rst:58 -#: ../../rst/network/user_guide/platform_voss.rst:61 -#: ../../rst/network/user_guide/platform_vyos.rst:57 -#: ../../rst/network/user_guide/platform_weos4.rst:57 -msgid "If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration." -msgstr "(bastion/ジャンプホストを経由せず) ホストに直接アクセスしている場合は、``ansible_ssh_common_args`` 設定を削除できます。" - -#: ../../rst/network/user_guide/platform_ce.rst:61 -msgid "If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords via environment variables." -msgstr "bastion/ジャンプホストを介してホストにアクセスする場合は、``ProxyCommand`` ディレクティブに SSH パスワードを含めることができません。シークレットが漏洩するのを防ぐために (例: ``ps`` 出力)、SSH は環境変数によるパスワードの提供をサポートしません。" - -#: ../../rst/network/user_guide/platform_ce.rst:64 -#: ../../rst/network/user_guide/platform_cnos.rst:65 -#: ../../rst/network/user_guide/platform_dellos10.rst:66 -#: ../../rst/network/user_guide/platform_dellos6.rst:65 -#: ../../rst/network/user_guide/platform_dellos9.rst:65 -#: ../../rst/network/user_guide/platform_enos.rst:67 -#: ../../rst/network/user_guide/platform_eos.rst:70 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:60 -#: ../../rst/network/user_guide/platform_exos.rst:62 -#: ../../rst/network/user_guide/platform_frr.rst:59 -#: ../../rst/network/user_guide/platform_icx.rst:63 -#: ../../rst/network/user_guide/platform_ios.rst:65 -#: ../../rst/network/user_guide/platform_iosxr.rst:67 -#: ../../rst/network/user_guide/platform_ironware.rst:66 -#: ../../rst/network/user_guide/platform_junos.rst:68 -#: ../../rst/network/user_guide/platform_netvisor.rst:61 -#: ../../rst/network/user_guide/platform_nos.rst:61 -#: ../../rst/network/user_guide/platform_nxos.rst:67 -#: ../../rst/network/user_guide/platform_routeros.rst:66 -#: ../../rst/network/user_guide/platform_slxos.rst:62 -#: ../../rst/network/user_guide/platform_voss.rst:65 -#: ../../rst/network/user_guide/platform_vyos.rst:61 -#: ../../rst/network/user_guide/platform_weos4.rst:61 -msgid "Example CLI task" -msgstr "CLI タスクの例" - -#: ../../rst/network/user_guide/platform_ce.rst:75 -#: ../../rst/network/user_guide/platform_iosxr.rst:78 -#: ../../rst/network/user_guide/platform_junos.rst:79 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:38 -msgid "Using NETCONF in Ansible" -msgstr "Ansible での NETCONF の使用" - -#: ../../rst/network/user_guide/platform_ce.rst:78 -#: ../../rst/network/user_guide/platform_iosxr.rst:81 -#: ../../rst/network/user_guide/platform_junos.rst:82 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:41 -msgid "Enabling NETCONF" -msgstr "NETCONF の有効化" - -#: ../../rst/network/user_guide/platform_ce.rst:80 -#: ../../rst/network/user_guide/platform_iosxr.rst:83 -#: ../../rst/network/user_guide/platform_junos.rst:84 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:43 -msgid "Before you can use NETCONF to connect to a switch, you must:" -msgstr "NETCONF を使用してスイッチに接続する前に、以下を行う必要があります。" - -#: ../../rst/network/user_guide/platform_ce.rst:82 -#: ../../rst/network/user_guide/platform_iosxr.rst:85 -#: ../../rst/network/user_guide/platform_junos.rst:86 -msgid "install the ``ncclient`` python package on your control node(s) with ``pip install ncclient``" -msgstr "``pip install ncclient`` を使用して、``ncclient`` python パッケージをコントロールノードにインストールします。" - -#: ../../rst/network/user_guide/platform_ce.rst:83 -msgid "enable NETCONF on the CloudEngine OS device(s)" -msgstr "CloudEngine OS デバイスでの NETCONF の有効化" - -#: ../../rst/network/user_guide/platform_ce.rst:85 -msgid "To enable NETCONF on a new switch using Ansible, use the ``community.network.ce_config`` module with the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansibleを使用する新しいスイッチで NETCONF を有効にするには、CLI 接続でモジュールを ``community.network.ce_config`` 使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_ce.rst:96 -#: ../../rst/network/user_guide/platform_iosxr.rst:97 -#: ../../rst/network/user_guide/platform_junos.rst:98 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:58 -msgid "Once NETCONF is enabled, change your variables to use the NETCONF connection." -msgstr "NETCONF を有効にしたら、変数を変更して NETCONF 接続を使用します。" - -#: ../../rst/network/user_guide/platform_ce.rst:99 -msgid "Example NETCONF inventory ``[ce:vars]``" -msgstr "NETCONF インベントリーの例 ``[ce:vars]``" - -#: ../../rst/network/user_guide/platform_ce.rst:112 -#: ../../rst/network/user_guide/platform_iosxr.rst:113 -#: ../../rst/network/user_guide/platform_junos.rst:114 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:73 -msgid "Example NETCONF task" -msgstr "NETCONF タスクの例" - -#: ../../rst/network/user_guide/platform_ce.rst:124 -msgid "Notes" -msgstr "備考" - -#: ../../rst/network/user_guide/platform_ce.rst:127 -msgid "Modules that work with ``ansible.netcommon.network_cli``" -msgstr "``ansible.netcommon.network_cli`` と連携するモジュール" - -#: ../../rst/network/user_guide/platform_ce.rst:157 -msgid "Modules that work with ``ansible.netcommon.netconf``" -msgstr "``ansible.netcommon.netconf`` と連携するモジュール" - -#: ../../rst/network/user_guide/shared_snippets/SSH_warning.txt:2 -msgid "Never store passwords in plain text. We recommend using SSH keys to authenticate SSH connections. Ansible supports ssh-agent to manage your SSH keys. If you must use passwords to authenticate SSH connections, we recommend encrypting them with :ref:`Ansible Vault `." -msgstr "パスワードをプレーンテキストで保存しないでください。SSH キーを使用して SSH 接続を認証することが推奨されます。Ansible は SSH キーを管理するための ssh-agent をサポートしています。SSH 接続の認証にパスワードを使用する必要がある場合は、:ref:`Ansible Vault ` で暗号化することが推奨されます。" - -#: ../../rst/network/user_guide/platform_ce.rst:213 -#: ../../rst/network/user_guide/platform_cnos.rst:78 -#: ../../rst/network/user_guide/platform_dellos10.rst:80 -#: ../../rst/network/user_guide/platform_dellos6.rst:79 -#: ../../rst/network/user_guide/platform_dellos9.rst:79 -#: ../../rst/network/user_guide/platform_enos.rst:80 -#: ../../rst/network/user_guide/platform_eos.rst:140 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:73 -#: ../../rst/network/user_guide/platform_exos.rst:108 -#: ../../rst/network/user_guide/platform_frr.rst:73 -#: ../../rst/network/user_guide/platform_icx.rst:77 -#: ../../rst/network/user_guide/platform_ios.rst:79 -#: ../../rst/network/user_guide/platform_iosxr.rst:130 -#: ../../rst/network/user_guide/platform_ironware.rst:80 -#: ../../rst/network/user_guide/platform_junos.rst:129 -#: ../../rst/network/user_guide/platform_meraki.rst:44 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:133 -#: ../../rst/network/user_guide/platform_netvisor.rst:78 -#: ../../rst/network/user_guide/platform_nos.rst:76 -#: ../../rst/network/user_guide/platform_nxos.rst:166 -#: ../../rst/network/user_guide/platform_routeros.rst:80 -#: ../../rst/network/user_guide/platform_slxos.rst:77 -#: ../../rst/network/user_guide/platform_voss.rst:78 -#: ../../rst/network/user_guide/platform_vyos.rst:74 -#: ../../rst/network/user_guide/platform_weos4.rst:88 -msgid ":ref:`timeout_options`" -msgstr ":ref:`timeout_options`" - -#: ../../rst/network/user_guide/platform_cnos.rst:5 -msgid "CNOS Platform Options" -msgstr "CNOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_cnos.rst:7 -msgid "CNOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on CNOS in Ansible." -msgstr "CNOS は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の CNOS で Enable Mode を有効にする方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_cnos.rst:27 -#: ../../rst/network/user_guide/platform_enos.rst:27 -#: ../../rst/network/user_guide/platform_eos.rst:27 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:27 -#: ../../rst/network/user_guide/platform_exos.rst:28 -#: ../../rst/network/user_guide/platform_frr.rst:27 -#: ../../rst/network/user_guide/platform_icx.rst:27 -#: ../../rst/network/user_guide/platform_ios.rst:27 -#: ../../rst/network/user_guide/platform_iosxr.rst:31 -#: ../../rst/network/user_guide/platform_ironware.rst:27 -#: ../../rst/network/user_guide/platform_junos.rst:30 -#: ../../rst/network/user_guide/platform_netvisor.rst:28 -#: ../../rst/network/user_guide/platform_nos.rst:28 -#: ../../rst/network/user_guide/platform_nxos.rst:27 -#: ../../rst/network/user_guide/platform_routeros.rst:28 -#: ../../rst/network/user_guide/platform_slxos.rst:28 -#: ../../rst/network/user_guide/platform_voss.rst:28 -#: ../../rst/network/user_guide/platform_vyos.rst:27 -#: ../../rst/network/user_guide/platform_weos4.rst:28 -msgid "by a bastion (jump host)" -msgstr "bastion (ジャンプホスト) を使用" - -#: ../../rst/network/user_guide/platform_cnos.rst:29 -#: ../../rst/network/user_guide/platform_dellos10.rst:29 -#: ../../rst/network/user_guide/platform_dellos6.rst:29 -#: ../../rst/network/user_guide/platform_dellos9.rst:29 -#: ../../rst/network/user_guide/platform_enos.rst:29 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:29 -#: ../../rst/network/user_guide/platform_frr.rst:29 -#: ../../rst/network/user_guide/platform_icx.rst:29 -#: ../../rst/network/user_guide/platform_ios.rst:29 -#: ../../rst/network/user_guide/platform_ironware.rst:29 -#: ../../rst/network/user_guide/platform_netvisor.rst:30 -#: ../../rst/network/user_guide/platform_slxos.rst:30 -#: ../../rst/network/user_guide/platform_voss.rst:30 -#: ../../rst/network/user_guide/platform_vyos.rst:29 -msgid "``ansible_connection: ansible.netcommon.network_cli``" -msgstr "``ansible_connection: ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_cnos.rst:31 -#: ../../rst/network/user_guide/platform_dellos10.rst:31 -#: ../../rst/network/user_guide/platform_dellos6.rst:31 -#: ../../rst/network/user_guide/platform_dellos9.rst:31 -#: ../../rst/network/user_guide/platform_enos.rst:31 -#: ../../rst/network/user_guide/platform_icx.rst:31 -#: ../../rst/network/user_guide/platform_ios.rst:31 -#: ../../rst/network/user_guide/platform_ironware.rst:31 -#: ../../rst/network/user_guide/platform_nxos.rst:32 -msgid "supported: use ``ansible_become: yes`` with ``ansible_become_method: enable`` and ``ansible_become_password:``" -msgstr "サポート対象: ``ansible_become: yes`` を、``ansible_become_method: enable`` および ``ansible_become_password:`` と併用します。" - -#: ../../rst/network/user_guide/platform_cnos.rst:35 -#: ../../rst/network/user_guide/platform_dellos10.rst:35 -#: ../../rst/network/user_guide/platform_dellos6.rst:35 -#: ../../rst/network/user_guide/platform_dellos9.rst:35 -#: ../../rst/network/user_guide/platform_enos.rst:35 -#: ../../rst/network/user_guide/platform_eos.rst:39 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:33 -#: ../../rst/network/user_guide/platform_exos.rst:35 -#: ../../rst/network/user_guide/platform_frr.rst:33 -#: ../../rst/network/user_guide/platform_icx.rst:34 -#: ../../rst/network/user_guide/platform_ios.rst:34 -#: ../../rst/network/user_guide/platform_ironware.rst:35 -#: ../../rst/network/user_guide/platform_junos.rst:37 -#: ../../rst/network/user_guide/platform_netvisor.rst:34 -#: ../../rst/network/user_guide/platform_nos.rst:34 -#: ../../rst/network/user_guide/platform_nxos.rst:36 -#: ../../rst/network/user_guide/platform_routeros.rst:34 -#: ../../rst/network/user_guide/platform_slxos.rst:34 -#: ../../rst/network/user_guide/platform_voss.rst:35 -#: ../../rst/network/user_guide/platform_weos4.rst:34 -msgid "``stdout[0].``" -msgstr "``stdout[0].``" - -#: ../../rst/network/user_guide/platform_cnos.rst:40 -#: ../../rst/network/user_guide/platform_dellos10.rst:40 -#: ../../rst/network/user_guide/platform_dellos6.rst:40 -#: ../../rst/network/user_guide/platform_dellos9.rst:40 -#: ../../rst/network/user_guide/platform_enos.rst:42 -#: ../../rst/network/user_guide/platform_ios.rst:40 -#: ../../rst/network/user_guide/platform_ironware.rst:41 -#: ../../rst/network/user_guide/platform_vyos.rst:39 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` を使用してください。" - -#: ../../rst/network/user_guide/platform_cnos.rst:46 -msgid "Example CLI ``group_vars/cnos.yml``" -msgstr "CLI の例 ``group_vars/cnos.yml``" - -#: ../../rst/network/user_guide/platform_cnos.rst:62 -#: ../../rst/network/user_guide/platform_dellos10.rst:63 -#: ../../rst/network/user_guide/platform_dellos6.rst:62 -#: ../../rst/network/user_guide/platform_dellos9.rst:62 -#: ../../rst/network/user_guide/platform_enos.rst:64 -#: ../../rst/network/user_guide/platform_eos.rst:67 -#: ../../rst/network/user_guide/platform_eric_eccli.rst:57 -#: ../../rst/network/user_guide/platform_exos.rst:59 -#: ../../rst/network/user_guide/platform_frr.rst:56 -#: ../../rst/network/user_guide/platform_icx.rst:60 -#: ../../rst/network/user_guide/platform_ios.rst:62 -#: ../../rst/network/user_guide/platform_iosxr.rst:64 -#: ../../rst/network/user_guide/platform_ironware.rst:63 -#: ../../rst/network/user_guide/platform_junos.rst:65 -#: ../../rst/network/user_guide/platform_netvisor.rst:58 -#: ../../rst/network/user_guide/platform_nos.rst:58 -#: ../../rst/network/user_guide/platform_nxos.rst:64 -#: ../../rst/network/user_guide/platform_routeros.rst:62 -#: ../../rst/network/user_guide/platform_slxos.rst:59 -#: ../../rst/network/user_guide/platform_voss.rst:62 -#: ../../rst/network/user_guide/platform_vyos.rst:58 -#: ../../rst/network/user_guide/platform_weos4.rst:58 -msgid "If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables." -msgstr "bastion/ジャンプ ホストを介してホストにアクセスする場合は、``ProxyCommand`` ディレクティブに SSH パスワードを含めることができません。シークレットが (``ps`` 出力などに) 漏洩するのを防ぐために、SSH は環境変数によるパスワードの提供をサポートしません。" - -#: ../../rst/network/user_guide/platform_dellos10.rst:5 -msgid "Dell OS10 Platform Options" -msgstr "Dell OS10 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_dellos10.rst:7 -msgid "The `dellemc.os10 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS10 in Ansible." -msgstr "`dellemc.os10 `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS10 で Enable Mode を使用する方法に関する詳細が記載されています。" - -#: ../../rst/network/user_guide/platform_dellos10.rst:27 -#: ../../rst/network/user_guide/platform_dellos6.rst:27 -#: ../../rst/network/user_guide/platform_dellos9.rst:27 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:29 -msgid "through a bastion (jump host)" -msgstr "bastion (ジャンプホスト) を使用" - -#: ../../rst/network/user_guide/platform_dellos10.rst:47 -msgid "Example CLI ``group_vars/dellos10.yml``" -msgstr "CLI の例 ``group_vars/dellos10.yml``" - -#: ../../rst/network/user_guide/platform_dellos6.rst:5 -msgid "Dell OS6 Platform Options" -msgstr "Dell OS6 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_dellos6.rst:7 -msgid "The `dellemc.os6 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS6 in Ansible." -msgstr "`dellemc.os6 `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS6 で Enable Mode の使用方法に関する詳細が記載されています。" - -#: ../../rst/network/user_guide/platform_dellos6.rst:46 -msgid "Example CLI ``group_vars/dellos6.yml``" -msgstr "CLI の例 ``group_vars/dellos6.yml``" - -#: ../../rst/network/user_guide/platform_dellos9.rst:5 -msgid "Dell OS9 Platform Options" -msgstr "Dell OS9 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_dellos9.rst:7 -msgid "The `dellemc.os9 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS9 in Ansible." -msgstr "`dellemc.os9 `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS9 で Enable Mode の使用方法に関する詳細が記載されています。" - -#: ../../rst/network/user_guide/platform_dellos9.rst:46 -msgid "Example CLI ``group_vars/dellos9.yml``" -msgstr "CLI の例 ``group_vars/dellos9.yml``" - -#: ../../rst/network/user_guide/platform_enos.rst:5 -msgid "ENOS Platform Options" -msgstr "ENOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_enos.rst:7 -msgid "ENOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ENOS in Ansible." -msgstr "ENOS は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の ENOS で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_enos.rst:48 -msgid "Example CLI ``group_vars/enos.yml``" -msgstr "CLI の例 ``group_vars/enos.yml``" - -#: ../../rst/network/user_guide/platform_eos.rst:5 -msgid "EOS Platform Options" -msgstr "EOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_eos.rst:7 -msgid "The `Arista EOS `_ collection supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Arista EOS `_ コレクションは複数の接続をサポートします。このページでは、各接続がどのように Ansible でどのように機能するかと、その使用方法を説明します。" - -#: ../../rst/network/user_guide/platform_eos.rst:19 -msgid "eAPI" -msgstr "eAPI" - -#: ../../rst/network/user_guide/platform_eos.rst:21 -#: ../../rst/network/user_guide/platform_exos.rst:22 -#: ../../rst/network/user_guide/platform_meraki.rst:21 -#: ../../rst/network/user_guide/platform_nxos.rst:21 -msgid "HTTP(S)" -msgstr "HTTP(S)" - -#: ../../rst/network/user_guide/platform_eos.rst:23 -#: ../../rst/network/user_guide/platform_exos.rst:24 -#: ../../rst/network/user_guide/platform_nxos.rst:23 -msgid "uses HTTPS certificates if present" -msgstr "HTTPS 証明書が存在する場合は使用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:27 -#: ../../rst/network/user_guide/platform_exos.rst:28 -msgid "through a web proxy" -msgstr "Web プロキシー経由" - -#: ../../rst/network/user_guide/platform_eos.rst:29 -msgid "``ansible_connection:`` ``ansible.netcommon.network_cli``" -msgstr "``ansible_connection:`` ``ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_eos.rst:29 -msgid "``ansible_connection:`` ``ansible.netcommon.httpapi``" -msgstr "``ansible_connection:`` ``ansible.netcommon.httpapi``" - -#: ../../rst/network/user_guide/platform_eos.rst:33 -msgid "supported: |br|" -msgstr "サポート対象: |br|" - -#: ../../rst/network/user_guide/platform_eos.rst:35 -msgid "use ``ansible_become: yes`` with ``ansible_become_method: enable``" -msgstr "``ansible_become: yes`` を ``ansible_become_method: enable`` と併用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:35 -msgid "``httpapi`` uses ``ansible_become: yes`` with ``ansible_become_method: enable``" -msgstr "``httpapi`` は、``ansible_become: yes`` を ``ansible_become_method: enable`` と併用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:39 -#: ../../rst/network/user_guide/platform_exos.rst:35 -#: ../../rst/network/user_guide/platform_nxos.rst:36 -msgid "``stdout[0].messages[0].``" -msgstr "``stdout[0].messages[0].``" - -#: ../../rst/network/user_guide/platform_eos.rst:45 -#: ../../rst/network/user_guide/platform_nxos.rst:42 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.httpapi`` を使用してください。" - -#: ../../rst/network/user_guide/platform_eos.rst:51 -msgid "Example CLI ``group_vars/eos.yml``" -msgstr "CLI の例 ``group_vars/eos.yml``" - -#: ../../rst/network/user_guide/platform_eos.rst:83 -msgid "Using eAPI in Ansible" -msgstr "Ansible での eAPI の使用" - -#: ../../rst/network/user_guide/platform_eos.rst:86 -msgid "Enabling eAPI" -msgstr "EAPI の有効化" - -#: ../../rst/network/user_guide/platform_eos.rst:88 -msgid "Before you can use eAPI to connect to a switch, you must enable eAPI. To enable eAPI on a new switch with Ansible, use the ``arista.eos.eos_eapi`` module through the CLI connection. Set up ``group_vars/eos.yml`` just like in the CLI example above, then run a playbook task like this:" -msgstr "eAPI を使用してスイッチに接続する前に、eAPI を有効にする必要があります。Ansible を使用する新しいスイッチで eAPI を有効にするには、CLI 接続を介して ``arista.eos.eos_eapi`` モジュールを使用します。上記の CLI の例のように ``group_vars/eos.yml`` を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_eos.rst:100 -msgid "You can find more options for enabling HTTP/HTTPS connections in the :ref:`arista.eos.eos_eapi ` module documentation." -msgstr "HTTP/HTTPS 接続を有効にするオプションの詳細は、:ref:`arista.eos.eos_eapi ` モジュールのドキュメントを参照してください。" - -#: ../../rst/network/user_guide/platform_eos.rst:102 -msgid "Once eAPI is enabled, change your ``group_vars/eos.yml`` to use the eAPI connection." -msgstr "eAPI を有効にしたら、``group_vars/eos.yml`` を変更して eAPI 接続を使用します。" - -#: ../../rst/network/user_guide/platform_eos.rst:105 -msgid "Example eAPI ``group_vars/eos.yml``" -msgstr "eAPI の例 ``group_vars/eos.yml``" - -#: ../../rst/network/user_guide/platform_eos.rst:118 -#: ../../rst/network/user_guide/platform_exos.rst:88 -#: ../../rst/network/user_guide/platform_nxos.rst:111 -msgid "If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration." -msgstr "(Web プロキシーを経由せず) ホストに直接アクセスしている場合は、``proxy_env`` 設定を削除できます。" - -#: ../../rst/network/user_guide/platform_eos.rst:119 -#: ../../rst/network/user_guide/platform_exos.rst:89 -#: ../../rst/network/user_guide/platform_nxos.rst:112 -msgid "If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``." -msgstr "``https`` を使用して Web プロキシー経由でホストにアクセスする場合は、``http_proxy`` を ``https_proxy`` に変更します。" - -#: ../../rst/network/user_guide/platform_eos.rst:123 -msgid "Example eAPI task" -msgstr "eAPI タスクの例" - -#: ../../rst/network/user_guide/platform_eos.rst:134 -msgid "In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module in the task." -msgstr "この例では、``group_vars`` で定義された ``proxy_env`` 変数が、タスクで使用されるモジュールの ``environment`` オプションに渡されます。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:5 -msgid "ERIC_ECCLI Platform Options" -msgstr "ERIC_ECCLI プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:7 -msgid "Extreme ERIC_ECCLI is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on ERIC_ECCLI in Ansible." -msgstr "Extreme ERIC_ECCLI は `community.network `_ コレクションの一部で、現在は CLI 接続のみに対応しています。このページでは、Ansible の ERIC_ECCLI で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:31 -msgid "not supported by ERIC_ECCLI" -msgstr "ERIC_ECCLI ではサポートされません。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:38 -msgid "ERIC_ECCLI does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "ERIC_ECCLI は、``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_eric_eccli.rst:44 -msgid "Example CLI ``group_vars/eric_eccli.yml``" -msgstr "CLI の例 ``group_vars/eric_eccli.yml``" - -#: ../../rst/network/user_guide/platform_exos.rst:5 -msgid "EXOS Platform Options" -msgstr "EXOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_exos.rst:7 -msgid "Extreme EXOS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "Extreme EXOS は `community.network `_ コレクションの一部で、複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能し、どのように使用されるかを詳細に説明します。" - -#: ../../rst/network/user_guide/platform_exos.rst:20 -msgid "EXOS-API" -msgstr "EXOS-API" - -#: ../../rst/network/user_guide/platform_exos.rst:31 -#: ../../rst/network/user_guide/platform_nxos.rst:30 -msgid "``ansible.netcommon.httpapi``" -msgstr "``ansible.netcommon.httpapi``" - -#: ../../rst/network/user_guide/platform_exos.rst:33 -msgid "not supported by EXOS" -msgstr "EXOS ではサポートされません" - -#: ../../rst/network/user_guide/platform_exos.rst:40 -msgid "EXOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi``." -msgstr "EXOS は、``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.httpapi`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_exos.rst:46 -msgid "Example CLI ``group_vars/exos.yml``" -msgstr "CLI の例 ``group_vars/exos.yml``" - -#: ../../rst/network/user_guide/platform_exos.rst:74 -msgid "Using EXOS-API in Ansible" -msgstr "Ansible での EXOS-API の使用" - -#: ../../rst/network/user_guide/platform_exos.rst:77 -msgid "Example EXOS-API ``group_vars/exos.yml``" -msgstr "EXOS-API の例 ``group_vars/exos.yml``" - -#: ../../rst/network/user_guide/platform_exos.rst:93 -msgid "Example EXOS-API task" -msgstr "EXOS-API タスクの例" - -#: ../../rst/network/user_guide/platform_exos.rst:102 -#: ../../rst/network/user_guide/platform_nxos.rst:127 -msgid "In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task." -msgstr "この例では、``proxy_env`` で定義された ``group_vars`` 変数は、タスクで使用されるモジュールの ``environment`` オプションに渡されます。" - -#: ../../rst/network/user_guide/platform_frr.rst:5 -msgid "FRR Platform Options" -msgstr "FRR プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_frr.rst:7 -msgid "The `FRR `_ collection supports the ``ansible.netcommon.network_cli`` connection. This section provides details on how to use this connection for Free Range Routing (FRR)." -msgstr "`FRR `_ コレクションは、``ansible.netcommon.network_cli`` 接続をサポートします。本セクションでは、この接続を Free Range Routing (FRR) に使用する方法を説明します。" - -#: ../../rst/network/user_guide/platform_frr.rst:31 -#: ../../rst/network/user_guide/platform_iosxr.rst:36 -#: ../../rst/network/user_guide/platform_vyos.rst:31 -msgid "not supported" -msgstr "サポート対象外" - -#: ../../rst/network/user_guide/platform_frr.rst:43 -msgid "Example CLI ``group_vars/frr.yml``" -msgstr "CLI の例 ``group_vars/frr.yml``" - -#: ../../rst/network/user_guide/platform_frr.rst:53 -msgid "The ``ansible_user`` should be a part of the ``frrvty`` group and should have the default shell set to ``/bin/vtysh``." -msgstr "``ansible_user`` は ``frrvty`` グループに含まれるはずです。デフォルトのシェルは ``/bin/vtysh`` に設定する必要があります。" - -#: ../../rst/network/user_guide/platform_icx.rst:5 -msgid "ICX Platform Options" -msgstr "ICX プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_icx.rst:7 -msgid "ICX is part of the `community.network `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ICX in Ansible." -msgstr "ICX は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の ICX で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_icx.rst:44 -msgid "Example CLI ``group_vars/icx.yml``" -msgstr "CLI の例 ``group_vars/icx.yml``" - -#: ../../rst/network/user_guide/platform_index.rst:5 -#: ../../rst/network/user_guide/platform_index.rst:9 -msgid "Platform Options" -msgstr "プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_index.rst:7 -msgid "Some Ansible Network platforms support multiple connection types, privilege escalation (``enable`` mode), or other options. The pages in this section offer standardized guides to understanding available options on each network platform. We welcome contributions from community-maintained platforms to this section." -msgstr "一部の Ansible Network プラットフォームは、複数の接続タイプ、権限エスカレーション (``enable`` モード) 、またはその他のオプションをサポートしています。本セクションのページでは、各ネットワークプラットフォームで利用可能なオプションを理解する標準ガイドが紹介されています。コミュニティーが管理するプラットフォームから、このセクションへの貢献を歓迎いたします。" - -#: ../../rst/network/user_guide/platform_index.rst:42 -msgid "Settings by Platform" -msgstr "プラットフォーム別の設定" - -#: ../../rst/network/user_guide/platform_index.rst:59 -msgid "``ansible_connection:`` settings available" -msgstr "``ansible_connection:`` 設定が利用可能" - -#: ../../rst/network/user_guide/platform_index.rst:61 -msgid "Network OS" -msgstr "ネットワーク OS" - -#: ../../rst/network/user_guide/platform_index.rst:61 -msgid "``ansible_network_os:``" -msgstr "``ansible_network_os:``" - -#: ../../rst/network/user_guide/platform_index.rst:61 -msgid "network_cli" -msgstr "network_cli" - -#: ../../rst/network/user_guide/platform_index.rst:61 -msgid "netconf" -msgstr "netconf" - -#: ../../rst/network/user_guide/platform_index.rst:61 -msgid "httpapi" -msgstr "httpapi" - -#: ../../rst/network/user_guide/platform_index.rst:63 -msgid "`Arista EOS`_ `[†]`_" -msgstr "`Arista EOS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:63 -msgid "``arista.eos.eos``" -msgstr "``arista.eos.eos``" - -#: ../../rst/network/user_guide/platform_index.rst:63 -#: ../../rst/network/user_guide/platform_index.rst:64 -#: ../../rst/network/user_guide/platform_index.rst:65 -#: ../../rst/network/user_guide/platform_index.rst:66 -#: ../../rst/network/user_guide/platform_index.rst:67 -#: ../../rst/network/user_guide/platform_index.rst:68 -#: ../../rst/network/user_guide/platform_index.rst:69 -#: ../../rst/network/user_guide/platform_index.rst:70 -#: ../../rst/network/user_guide/platform_index.rst:71 -#: ../../rst/network/user_guide/platform_index.rst:72 -#: ../../rst/network/user_guide/platform_index.rst:73 -#: ../../rst/network/user_guide/platform_index.rst:74 -#: ../../rst/network/user_guide/platform_index.rst:75 -#: ../../rst/network/user_guide/platform_index.rst:76 -#: ../../rst/network/user_guide/platform_index.rst:77 -#: ../../rst/network/user_guide/platform_index.rst:78 -#: ../../rst/network/user_guide/platform_index.rst:79 -#: ../../rst/network/user_guide/platform_index.rst:80 -#: ../../rst/network/user_guide/platform_index.rst:81 -#: ../../rst/network/user_guide/platform_index.rst:82 -#: ../../rst/network/user_guide/platform_index.rst:83 -#: ../../rst/network/user_guide/platform_index.rst:84 -#: ../../rst/network/user_guide/platform_index.rst:85 -#: ../../rst/network/user_guide/platform_index.rst:86 -#: ../../rst/network/user_guide/platform_index.rst:87 -#: ../../rst/network/user_guide/platform_index.rst:88 -#: ../../rst/network/user_guide/platform_index.rst:89 -#: ../../rst/network/user_guide/platform_index.rst:90 -#: ../../rst/network/user_guide/platform_index.rst:91 -msgid "✓" -msgstr "✓" - -#: ../../rst/network/user_guide/platform_index.rst:64 -msgid "`Ciena SAOS6`_" -msgstr "`Ciena SAOS6`_" - -#: ../../rst/network/user_guide/platform_index.rst:64 -msgid "``ciena.saos6.saos6``" -msgstr "``ciena.saos6.saos6``" - -#: ../../rst/network/user_guide/platform_index.rst:65 -msgid "`Cisco ASA`_ `[†]`_" -msgstr "`Cisco ASA`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:65 -msgid "``cisco.asa.asa``" -msgstr "``cisco.asa.asa``" - -#: ../../rst/network/user_guide/platform_index.rst:66 -msgid "`Cisco IOS`_ `[†]`_" -msgstr "`Cisco IOS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:66 -msgid "``cisco.ios.ios``" -msgstr "``cisco.ios.ios``" - -#: ../../rst/network/user_guide/platform_index.rst:67 -msgid "`Cisco IOS XR`_ `[†]`_" -msgstr "`Cisco IOS XR`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:67 -msgid "``cisco.iosxr.iosxr``" -msgstr "``cisco.iosxr.iosxr``" - -#: ../../rst/network/user_guide/platform_index.rst:68 -msgid "`Cisco NX-OS`_ `[†]`_" -msgstr "`Cisco NX-OS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:68 -msgid "``cisco.nxos.nxos``" -msgstr "``cisco.nxos.nxos``" - -#: ../../rst/network/user_guide/platform_index.rst:69 -msgid "`Cloudengine OS`_" -msgstr "`Cloudengine OS`_" - -#: ../../rst/network/user_guide/platform_index.rst:69 -msgid "``community.network.ce``" -msgstr "``community.network.ce``" - -#: ../../rst/network/user_guide/platform_index.rst:70 -msgid "`Dell OS6`_" -msgstr "`Dell OS6`_" - -#: ../../rst/network/user_guide/platform_index.rst:70 -msgid "``dellemc.os6.os6``" -msgstr "``dellemc.os6.os6``" - -#: ../../rst/network/user_guide/platform_index.rst:71 -msgid "`Dell OS9`_" -msgstr "`Dell OS9`_" - -#: ../../rst/network/user_guide/platform_index.rst:71 -msgid "``dellemc.os9.os9``" -msgstr "``dellemc.os9.os9``" - -#: ../../rst/network/user_guide/platform_index.rst:72 -msgid "`Dell OS10`_" -msgstr "`Dell OS10`_" - -#: ../../rst/network/user_guide/platform_index.rst:72 -msgid "``dellemc.os10.os10``" -msgstr "``dellemc.os10.os10``" - -#: ../../rst/network/user_guide/platform_index.rst:73 -msgid "`Ericsson ECCLI`_" -msgstr "`Ericsson ECCLI`_" - -#: ../../rst/network/user_guide/platform_index.rst:73 -msgid "``community.network.eric_eccli``" -msgstr "``community.network.eric_eccli``" - -#: ../../rst/network/user_guide/platform_index.rst:74 -msgid "`Extreme EXOS`_" -msgstr "`Extreme EXOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:74 -msgid "``community.network.exos``" -msgstr "``community.network.exos``" - -#: ../../rst/network/user_guide/platform_index.rst:75 -msgid "`Extreme IronWare`_" -msgstr "`Extreme IronWare`_" - -#: ../../rst/network/user_guide/platform_index.rst:75 -msgid "``community.network.ironware``" -msgstr "``community.network.ironware``" - -#: ../../rst/network/user_guide/platform_index.rst:76 -msgid "`Extreme NOS`_" -msgstr "`Extreme NOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:76 -msgid "``community.network.nos``" -msgstr "``community.network.nos``" - -#: ../../rst/network/user_guide/platform_index.rst:77 -msgid "`Extreme SLX-OS`_" -msgstr "`Extreme SLX-OS`_" - -#: ../../rst/network/user_guide/platform_index.rst:77 -msgid "``community.network.slxos``" -msgstr "``community.network.slxos``" - -#: ../../rst/network/user_guide/platform_index.rst:78 -msgid "`Extreme VOSS`_" -msgstr "`Extreme VOSS`_" - -#: ../../rst/network/user_guide/platform_index.rst:78 -msgid "``community.network.voss``" -msgstr "``community.network.voss``" - -#: ../../rst/network/user_guide/platform_index.rst:79 -msgid "`F5 BIG-IP`_" -msgstr "`F5 BIG-IP`_" - -#: ../../rst/network/user_guide/platform_index.rst:80 -msgid "`F5 BIG-IQ`_" -msgstr "`F5 BIG-IQ`_" - -#: ../../rst/network/user_guide/platform_index.rst:81 -msgid "`Junos OS`_ `[†]`_" -msgstr "`Junos OS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:81 -msgid "``junipernetworks.junos.junos``" -msgstr "``junipernetworks.junos.junos``" - -#: ../../rst/network/user_guide/platform_index.rst:82 -msgid "`Lenovo CNOS`_" -msgstr "`Lenovo CNOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:82 -msgid "``community.network.cnos``" -msgstr "``community.network.cnos``" - -#: ../../rst/network/user_guide/platform_index.rst:83 -msgid "`Lenovo ENOS`_" -msgstr "`Lenovo ENOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:83 -msgid "``community.network.enos``" -msgstr "``community.network.enos``" - -#: ../../rst/network/user_guide/platform_index.rst:84 -msgid "`Meraki`_" -msgstr "`Meraki`_" - -#: ../../rst/network/user_guide/platform_index.rst:85 -msgid "`MikroTik RouterOS`_" -msgstr "`MikroTik RouterOS`_" - -#: ../../rst/network/user_guide/platform_index.rst:85 -msgid "``community.network.routeros``" -msgstr "``community.network.routeros``" - -#: ../../rst/network/user_guide/platform_index.rst:86 -msgid "`Nokia SR OS`_" -msgstr "`Nokia SR OS`_" - -#: ../../rst/network/user_guide/platform_index.rst:87 -msgid "`Pluribus Netvisor`_" -msgstr "`Pluribus Netvisor`_" - -#: ../../rst/network/user_guide/platform_index.rst:87 -msgid "``community.network.netvisor``" -msgstr "``community.network.netvisor``" - -#: ../../rst/network/user_guide/platform_index.rst:88 -msgid "`Ruckus ICX`_" -msgstr "`Ruckus ICX`_" - -#: ../../rst/network/user_guide/platform_index.rst:88 -msgid "``community.network.icx``" -msgstr "``community.network.icx``" - -#: ../../rst/network/user_guide/platform_index.rst:89 -msgid "`VyOS`_ `[†]`_" -msgstr "`VyOS`_ `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:89 -msgid "``vyos.vyos.vyos``" -msgstr "``vyos.vyos.vyos``" - -#: ../../rst/network/user_guide/platform_index.rst:90 -msgid "`Westermo WeOS 4`_" -msgstr "`Westermo WeOS 4`_" - -#: ../../rst/network/user_guide/platform_index.rst:90 -msgid "``community.network.weos4``" -msgstr "``community.network.weos4``" - -#: ../../rst/network/user_guide/platform_index.rst:91 -msgid "OS that supports Netconf `[†]`_" -msgstr "Netconf に対応する OS `[†]`_" - -#: ../../rst/network/user_guide/platform_index.rst:91 -msgid "````" -msgstr "````" - -#: ../../rst/network/user_guide/platform_index.rst:124 -msgid "**[†]** Maintained by Ansible Network Team" -msgstr "**[†]** Ansible Network Team が管理" - -#: ../../rst/network/user_guide/platform_ios.rst:5 -msgid "IOS Platform Options" -msgstr "IOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_ios.rst:7 -msgid "The `Cisco IOS `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IOS in Ansible." -msgstr "`Cisco IOS `_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の IOS で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_ios.rst:46 -msgid "Example CLI ``group_vars/ios.yml``" -msgstr "CLI の例 ``group_vars/ios.yml``" - -#: ../../rst/network/user_guide/platform_iosxr.rst:5 -msgid "IOS-XR Platform Options" -msgstr "IOS-XR プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_iosxr.rst:7 -msgid "The `Cisco IOS-XR collection `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Cisco IOS-XR collection `_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:21 -msgid "only for modules ``iosxr_banner``, ``iosxr_interface``, ``iosxr_logging``, ``iosxr_system``, ``iosxr_user``" -msgstr "モジュールの ``iosxr_banner``、``iosxr_interface``、``iosxr_logging``、``iosxr_system``、``iosxr_user`` のみ" - -#: ../../rst/network/user_guide/platform_iosxr.rst:44 -#: ../../rst/network/user_guide/platform_junos.rst:45 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.netconf`` を使用してください。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:50 -msgid "Example CLI inventory ``[iosxr:vars]``" -msgstr "CLI インベントリーの例 ``[iosxr:vars]``" - -#: ../../rst/network/user_guide/platform_iosxr.rst:86 -msgid "enable NETCONF on the Cisco IOS-XR device(s)" -msgstr "Cisco IOS-XR デバイスで NETCONF を有効にします。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:88 -msgid "To enable NETCONF on a new switch via Ansible, use the ``cisco.iosxr.iosxr_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続を介して ``cisco.iosxr.iosxr_netconf`` モジュールを使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_iosxr.rst:100 -msgid "Example NETCONF inventory ``[iosxr:vars]``" -msgstr "NETCONF インベントリーの例 ``[iosxr:vars]``" - -#: ../../rst/network/user_guide/platform_ironware.rst:5 -msgid "IronWare Platform Options" -msgstr "IronWare プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_ironware.rst:7 -msgid "IronWare is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IronWare in Ansible." -msgstr "IronWare は、`community.network `_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の IronWare で Enable Mode を有効にする方法を説明します。" - -#: ../../rst/network/user_guide/platform_ironware.rst:47 -msgid "Example CLI ``group_vars/mlx.yml``" -msgstr "CLI の例 ``group_vars/mlx.yml``" - -#: ../../rst/network/user_guide/platform_junos.rst:5 -msgid "Junos OS Platform Options" -msgstr "Junos OS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_junos.rst:7 -msgid "The `Juniper Junos OS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Juniper Junos OS `_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_junos.rst:21 -msgid "``junos_netconf`` & ``junos_command`` modules only" -msgstr "``junos_netconf`` モジュールおよび ``junos_command`` モジュールのみ" - -#: ../../rst/network/user_guide/platform_junos.rst:21 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:20 -msgid "all modules except ``junos_netconf``, which enables NETCONF" -msgstr "NETCONF を有効にする ``junos_netconf`` 以外のすべてのモジュール" - -#: ../../rst/network/user_guide/platform_junos.rst:32 -msgid "``ansible_connection: ``ansible.netcommon.network_cli``" -msgstr "``ansible_connection: ``ansible.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_junos.rst:32 -msgid "``ansible_connection: ``ansible.netcommon.netconf``" -msgstr "``ansible_connection: ``ansible.netcommon.netconf``" - -#: ../../rst/network/user_guide/platform_junos.rst:35 -msgid "not supported by Junos OS" -msgstr "Junos OS ではサポートされません" - -#: ../../rst/network/user_guide/platform_junos.rst:37 -msgid "json: ``result[0]['software-information'][0]['host-name'][0]['data'] foo lo0``" -msgstr "json: ``result[0]['software-information'][0]['host-name'][0]['data'] foo lo0``" - -#: ../../rst/network/user_guide/platform_junos.rst:38 -msgid "text: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0``" -msgstr "テキスト: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0``" - -#: ../../rst/network/user_guide/platform_junos.rst:39 -msgid "xml: ``result[1].rpc-reply.interface-information[0].physical-interface[0].name[0].data foo lo0``" -msgstr "xml: ``result[1].rpc-reply.interface-information[0].physical-interface[0].name[0].data foo lo0``" - -#: ../../rst/network/user_guide/platform_junos.rst:51 -msgid "Example CLI inventory ``[junos:vars]``" -msgstr "CLI インベントリーの例 ``[junos:vars]``" - -#: ../../rst/network/user_guide/platform_junos.rst:87 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:46 -msgid "enable NETCONF on the Junos OS device(s)" -msgstr "Junos OS デバイスの netconf を有効にします。" - -#: ../../rst/network/user_guide/platform_junos.rst:89 -msgid "To enable NETCONF on a new switch through Ansible, use the ``junipernetworks.junos.junos_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続を介して ``junipernetworks.junos.junos_netconf`` モジュールを使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_junos.rst:101 -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:61 -msgid "Example NETCONF inventory ``[junos:vars]``" -msgstr "NETCONF インベントリーの例 ``[junos:vars]``" - -#: ../../rst/network/user_guide/platform_meraki.rst:5 -msgid "Meraki Platform Options" -msgstr "Meraki プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_meraki.rst:7 -msgid "The `cisco.meraki `_ collection only supports the ``local`` connection type at this time." -msgstr "`cisco.meraki `_ コレクションは、現時点では ``local`` 接続タイプのみをサポートします。" - -#: ../../rst/network/user_guide/platform_meraki.rst:19 -msgid "Dashboard API" -msgstr "ダッシュボード API" - -#: ../../rst/network/user_guide/platform_meraki.rst:23 -msgid "uses API key from Dashboard" -msgstr "Dashboard からの API キーの使用" - -#: ../../rst/network/user_guide/platform_meraki.rst:25 -msgid "``ansible_connection: localhost``" -msgstr "``ansible_connection: localhost``" - -#: ../../rst/network/user_guide/platform_meraki.rst:27 -msgid "``data.``" -msgstr "``data.``" - -#: ../../rst/network/user_guide/platform_meraki.rst:32 -msgid "Example Meraki task" -msgstr "Meraki タスクの例" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:5 -msgid "Netconf enabled Platform Options" -msgstr "Netconf が有効なプラットフォームオプション" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:7 -msgid "This page offers details on how the netconf connection works in Ansible and how to use it." -msgstr "このページには、netconf 接続が Ansible でどのように機能するか、およびその詳細な使用方法が記載されています。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:31 -msgid "``ansible_connection: ansible.netcommon.netconf``" -msgstr "``ansible_connection: ansible.netcommon.netconf``" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:35 -msgid "The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` instead." -msgstr "``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.netconf`` を使用してください。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:45 -msgid "install the ``ncclient`` Python package on your control node(s) with ``pip install ncclient``" -msgstr "``pip install ncclient`` を使用して、``ncclient`` Python パッケージをコントロールノードにインストールします。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:48 -msgid "To enable NETCONF on a new switch through Ansible, use the platform specific module through the CLI connection or set it manually. For example set up your platform-level variables just like in the CLI example above, then run a playbook task like this:" -msgstr "Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続経由でプラットフォーム固有のモジュールを使用するか、手動で設定します。たとえば、上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:83 -msgid "Example NETCONF task with configurable variables" -msgstr "設定可能な変数を含む NETCONF タスクの例" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:94 -msgid "Note: For netconf connection plugin configurable variables see :ref:`ansible.netcommon.netconf `." -msgstr "注意: netconf connection プラグインの設定可能な変数は、「:ref:`ansible.netcommon.netconf `」を参照してください。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:97 -msgid "Bastion/Jumphost configuration" -msgstr "Bastion/ジャンプホストの設定" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:98 -msgid "To use a jump host to connect to a NETCONF enabled device you must set the ``ANSIBLE_NETCONF_SSH_CONFIG`` environment variable." -msgstr "ジャンプホストを使用して NETCONF 対応のデバイスに接続するには、``ANSIBLE_NETCONF_SSH_CONFIG`` 環境変数を設定する必要があります。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:102 -msgid "``ANSIBLE_NETCONF_SSH_CONFIG`` can be set to either:" -msgstr "``ANSIBLE_NETCONF_SSH_CONFIG`` を、次のいずれかに設定できます。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:101 -msgid "1 or TRUE (to trigger the use of the default SSH config file ~/.ssh/config)" -msgstr "1 または TRUE (デフォルトの SSH 設定ファイル ~/.ssh/config の使用を開始するため)。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:102 -msgid "The absolute path to a custom SSH config file." -msgstr "カスタムの SSH 設定ファイルへの絶対パス。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:104 -msgid "The SSH config file should look something like:" -msgstr "SSH 設定ファイルは以下のようになります。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:112 -msgid "Authentication for the jump host must use key based authentication." -msgstr "ジャンプホストの認証は、鍵ベースの認証を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:114 -msgid "You can either specify the private key used in the SSH config file:" -msgstr "SSH 設定ファイルで使用する秘密鍵のいずれかを指定できます。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:120 -msgid "Or you can use an ssh-agent." -msgstr "または、ssh-agent を使用できます。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:123 -msgid "ansible_network_os auto-detection" -msgstr "ansible_network_os 自動検出" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:125 -msgid "If ``ansible_network_os`` is not specified for a host, then Ansible will attempt to automatically detect what ``network_os`` plugin to use." -msgstr "ホストに ``ansible_network_os`` が指定されていない場合、Ansible は、使用する ``network_os`` プラグインを自動的に検出しようとします。" - -#: ../../rst/network/user_guide/platform_netconf_enabled.rst:127 -msgid "``ansible_network_os`` auto-detection can also be triggered by using ``auto`` as the ``ansible_network_os``. (Note: Previously ``default`` was used instead of ``auto``)." -msgstr "``ansible_network_os`` 自動検出は、``auto`` を ``ansible_network_os`` として使用することで発生させることもできます (注意: 以前は ``default`` の代わりに ``auto``が使用されていました)。" - -#: ../../rst/network/user_guide/platform_netvisor.rst:5 -msgid "Pluribus NETVISOR Platform Options" -msgstr "Pluribus NETVISOR プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_netvisor.rst:7 -msgid "Pluribus NETVISOR Ansible is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on NETVISOR in Ansible." -msgstr "Pluribus NETVISOR Ansible は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の NETVISOR で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_netvisor.rst:32 -msgid "not supported by NETVISOR" -msgstr "NETVISOR ではサポートされません" - -#: ../../rst/network/user_guide/platform_netvisor.rst:39 -msgid "Pluribus NETVISOR does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "Pluribus NETVISOR は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_netvisor.rst:45 -msgid "Example CLI ``group_vars/netvisor.yml``" -msgstr "CLI の例 ``group_vars/netvisor.yml``" - -#: ../../rst/network/user_guide/platform_nos.rst:5 -msgid "NOS Platform Options" -msgstr "NOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_nos.rst:7 -msgid "Extreme NOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on NOS in Ansible." -msgstr "Extreme NOS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の NOS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_nos.rst:30 -#: ../../rst/network/user_guide/platform_weos4.rst:30 -msgid "``ansible_connection: community.netcommon.network_cli``" -msgstr "``ansible_connection: community.netcommon.network_cli``" - -#: ../../rst/network/user_guide/platform_nos.rst:32 -msgid "not supported by NOS" -msgstr "NOS ではサポートされません" - -#: ../../rst/network/user_guide/platform_nos.rst:39 -msgid "NOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "NOS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_nos.rst:45 -msgid "Example CLI ``group_vars/nos.yml``" -msgstr "CLI の例 ``group_vars/nos.yml``" - -#: ../../rst/network/user_guide/platform_nxos.rst:5 -msgid "NXOS Platform Options" -msgstr "NXOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_nxos.rst:7 -msgid "The `Cisco NXOS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it." -msgstr "`Cisco NXOS `_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_nxos.rst:19 -msgid "NX-API" -msgstr "NX-API" - -#: ../../rst/network/user_guide/platform_nxos.rst:27 -msgid "by a web proxy" -msgstr "Web プロキシー経由" - -#: ../../rst/network/user_guide/platform_nxos.rst:32 -msgid "not supported by NX-API" -msgstr "NX-API ではサポートされません" - -#: ../../rst/network/user_guide/platform_nxos.rst:48 -msgid "Example CLI ``group_vars/nxos.yml``" -msgstr "CLI の例 ``group_vars/nxos.yml``" - -#: ../../rst/network/user_guide/platform_nxos.rst:80 -msgid "Using NX-API in Ansible" -msgstr "Ansible での NX-API の使用" - -#: ../../rst/network/user_guide/platform_nxos.rst:83 -msgid "Enabling NX-API" -msgstr "NX-API の有効化" - -#: ../../rst/network/user_guide/platform_nxos.rst:85 -msgid "Before you can use NX-API to connect to a switch, you must enable NX-API. To enable NX-API on a new switch through Ansible, use the ``nxos_nxapi`` module through the CLI connection. Set up group_vars/nxos.yml just like in the CLI example above, then run a playbook task like this:" -msgstr "NX-API を使用してスイッチに接続する前に、NX-API を有効にする必要があります。Ansible を介して新しいスイッチで NX-API を有効にするには、CLI 接続を介して ``nxos_nxapi`` モジュールを使用します。前述の CLI の例と同様に group_vars/nxos.yml を設定し、次のように Playbook タスクを実行します。" - -#: ../../rst/network/user_guide/platform_nxos.rst:95 -msgid "To find out more about the options for enabling HTTP/HTTPS and local http see the :ref:`nxos_nxapi ` module documentation." -msgstr "HTTP/HTTPS およびローカル http を有効にするオプションの詳細は、:ref:`nxos_nxapi ` モジュールのドキュメントを参照してください。" - -#: ../../rst/network/user_guide/platform_nxos.rst:97 -msgid "Once NX-API is enabled, change your ``group_vars/nxos.yml`` to use the NX-API connection." -msgstr "NX-API を有効にしたら、NX-API 接続を使用するように ``group_vars/nxos.yml`` を変更します。" - -#: ../../rst/network/user_guide/platform_nxos.rst:100 -msgid "Example NX-API ``group_vars/nxos.yml``" -msgstr "NX-API の例 ``group_vars/nxos.yml``" - -#: ../../rst/network/user_guide/platform_nxos.rst:116 -msgid "Example NX-API task" -msgstr "NX-API タスクの例" - -#: ../../rst/network/user_guide/platform_nxos.rst:132 -msgid "Cisco Nexus platform support matrix" -msgstr "Cisco Nexus プラットフォームのサポートマトリックス" - -#: ../../rst/network/user_guide/platform_nxos.rst:134 -msgid "The following platforms and software versions have been certified by Cisco to work with this version of Ansible." -msgstr "以下のプラットフォームおよびソフトウェアのバージョンは、Cisco が本バージョンの Ansible で機能することが認定されています。" - -#: ../../rst/network/user_guide/platform_nxos.rst:136 -msgid "Platform / Software Minimum Requirements" -msgstr "プラットフォーム/ソフトウェア最小要件" - -#: ../../rst/network/user_guide/platform_nxos.rst:140 -msgid "Supported Platforms" -msgstr "サポート対象のプラットフォーム" - -#: ../../rst/network/user_guide/platform_nxos.rst:140 -msgid "Minimum NX-OS Version" -msgstr "最小 NX-OS バージョン" - -#: ../../rst/network/user_guide/platform_nxos.rst:142 -msgid "Cisco Nexus N3k" -msgstr "Cisco Nexus N3k" - -#: ../../rst/network/user_guide/platform_nxos.rst:142 -#: ../../rst/network/user_guide/platform_nxos.rst:143 -msgid "7.0(3)I2(5) and later" -msgstr "7.0(3)I2(5) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:143 -msgid "Cisco Nexus N9k" -msgstr "Cisco Nexus N9k" - -#: ../../rst/network/user_guide/platform_nxos.rst:144 -msgid "Cisco Nexus N5k" -msgstr "Cisco Nexus N5k" - -#: ../../rst/network/user_guide/platform_nxos.rst:144 -#: ../../rst/network/user_guide/platform_nxos.rst:145 -msgid "7.3(0)N1(1) and later" -msgstr "7.3(0)N1(1) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:145 -msgid "Cisco Nexus N6k" -msgstr "Cisco Nexus N6k" - -#: ../../rst/network/user_guide/platform_nxos.rst:146 -msgid "Cisco Nexus N7k" -msgstr "Cisco Nexus N7k" - -#: ../../rst/network/user_guide/platform_nxos.rst:146 -msgid "7.3(0)D1(1) and later" -msgstr "7.3(0)D1(1) 以降" - -#: ../../rst/network/user_guide/platform_nxos.rst:147 -msgid "Cisco Nexus MDS" -msgstr "Cisco Nexus MDS" - -#: ../../rst/network/user_guide/platform_nxos.rst:147 -msgid "8.4(1) and later (Please see individual module documentation for compatibility)" -msgstr "8.4(1)以降（互換性については、個別のモジュールドキュメントを確認してください）" - -#: ../../rst/network/user_guide/platform_nxos.rst:150 -msgid "Platform Models" -msgstr "プラットフォームモデル" - -#: ../../rst/network/user_guide/platform_nxos.rst:154 -msgid "Platform" -msgstr "プラットフォーム" - -#: ../../rst/network/user_guide/platform_nxos.rst:154 -msgid "Description" -msgstr "説明" - -#: ../../rst/network/user_guide/platform_nxos.rst:156 -msgid "N3k" -msgstr "N3k" - -#: ../../rst/network/user_guide/platform_nxos.rst:156 -msgid "Support includes N30xx, N31xx and N35xx models" -msgstr "サポートには、N30xx モデル、N31xx モデル、および N35xx モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:157 -msgid "N5k" -msgstr "N5k" - -#: ../../rst/network/user_guide/platform_nxos.rst:157 -msgid "Support includes all N5xxx models" -msgstr "サポートには、N5xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:158 -msgid "N6k" -msgstr "N6k" - -#: ../../rst/network/user_guide/platform_nxos.rst:158 -msgid "Support includes all N6xxx models" -msgstr "サポートには、N6xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:159 -msgid "N7k" -msgstr "N7k" - -#: ../../rst/network/user_guide/platform_nxos.rst:159 -msgid "Support includes all N7xxx models" -msgstr "サポートには、N7xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:160 -msgid "N9k" -msgstr "N9k" - -#: ../../rst/network/user_guide/platform_nxos.rst:160 -msgid "Support includes all N9xxx models" -msgstr "サポートには、N9xxx の全モデルが含まれます。" - -#: ../../rst/network/user_guide/platform_nxos.rst:161 -msgid "MDS" -msgstr "MDS" - -#: ../../rst/network/user_guide/platform_nxos.rst:161 -msgid "Support includes all MDS 9xxx models" -msgstr "サポートには、MDS 9xxx モデルがすべて含まれます。" - -#: ../../rst/network/user_guide/platform_routeros.rst:5 -msgid "RouterOS Platform Options" -msgstr "RouterOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_routeros.rst:7 -msgid "RouterOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on RouterOS in Ansible." -msgstr "RouterOS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の RouterOS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_routeros.rst:30 -msgid "``ansible_connection: ansible.network.network_cli``" -msgstr "``ansible_connection: ansible.network.network_cli``" - -#: ../../rst/network/user_guide/platform_routeros.rst:32 -msgid "not supported by RouterOS" -msgstr "RouterOS ではサポートされません" - -#: ../../rst/network/user_guide/platform_routeros.rst:40 -msgid "RouterOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "RouterOS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_routeros.rst:46 -msgid "Example CLI ``group_vars/routeros.yml``" -msgstr "CLI の例 ``group_vars/routeros.yml``" - -#: ../../rst/network/user_guide/platform_routeros.rst:63 -msgid "If you are getting timeout errors you may want to add ``+cet1024w`` suffix to your username which will disable console colors, enable \"dumb\" mode, tell RouterOS not to try detecting terminal capabilities and set terminal width to 1024 columns. See article `Console login process `_ in MikroTik wiki for more information." -msgstr "タイムアウトエラーが発生した場合は、ユーザー名に ``+cet1024w`` 接頭辞を追加することでコンソールの色を無効にし、「dumb」モードを有効にし、端末機能を検出しないように RouterOS に指示し、端末の幅を 1024 カラムに設定することができます。詳細は、MikroTik Wikiの記事「`Console login process `_」を参照してください。" - -#: ../../rst/network/user_guide/platform_slxos.rst:5 -msgid "SLX-OS Platform Options" -msgstr "SLX-OS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_slxos.rst:7 -msgid "Extreme SLX-OS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on SLX-OS in Ansible." -msgstr "Extreme SLX-OS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の SLX-OS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_slxos.rst:32 -msgid "not supported by SLX-OS" -msgstr "SLX-OS ではサポートされません" - -#: ../../rst/network/user_guide/platform_slxos.rst:40 -msgid "SLX-OS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "SLX-OS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_slxos.rst:46 -msgid "Example CLI ``group_vars/slxos.yml``" -msgstr "CLI の例 ``group_vars/slxos.yml``" - -#: ../../rst/network/user_guide/platform_voss.rst:5 -msgid "VOSS Platform Options" -msgstr "VOSS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_voss.rst:7 -msgid "Extreme VOSS is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on VOSS in Ansible." -msgstr "Extreme VOSS は `community.network `_ コレクションの一部で、現在は CLI 接続のみをサポートしています。このページでは、Ansible の VOSS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。" - -#: ../../rst/network/user_guide/platform_voss.rst:32 -msgid "supported: use ``ansible_become: yes`` with ``ansible_become_method: enable``" -msgstr "サポート対象: ``ansible_become: yes`` を ``ansible_become_method: enable`` と併用してください。" - -#: ../../rst/network/user_guide/platform_voss.rst:41 -msgid "VOSS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "VOSS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_voss.rst:47 -msgid "Example CLI ``group_vars/voss.yml``" -msgstr "CLI の例 ``group_vars/voss.yml``" - -#: ../../rst/network/user_guide/platform_vyos.rst:5 -msgid "VyOS Platform Options" -msgstr "VyOS プラットフォームのオプション" - -#: ../../rst/network/user_guide/platform_vyos.rst:7 -msgid "The `VyOS `_ collection supports the ``ansible.netcommon.network_cli`` connection type. This page offers details on connection options to manage VyOS using Ansible." -msgstr "`VyOS `_ コレクションは、``ansible.netcommon.network_cli`` 接続タイプをサポートします。このページでは、Ansible を使用して VyOS を管理する接続オプションの詳細を提供します。" - -#: ../../rst/network/user_guide/platform_vyos.rst:45 -msgid "Example CLI ``group_vars/vyos.yml``" -msgstr "CLI の例 ``group_vars/vyos.yml``" - -#: ../../rst/network/user_guide/platform_weos4.rst:5 -msgid "WeOS 4 Platform Options" -msgstr "WeOS 4 プラットフォームオプション" - -#: ../../rst/network/user_guide/platform_weos4.rst:7 -msgid "Westermo WeOS 4 is part of the `community.network `_ collection and only supports CLI connections. This page offers details on how to use ``ansible.netcommon.network_cli`` on WeOS 4 in Ansible." -msgstr "Westermo WeOS 4 は `community.network `_ コレクションの一部で、CLI 接続のみをサポートします。このページでは、Ansible の WeOS 4 で ``ansible.netcommon.network_cli`` を使用する方法を説明します。" - -#: ../../rst/network/user_guide/platform_weos4.rst:32 -msgid "not supported by WeOS 4" -msgstr "WeOS 4 でサポート対象外" - -#: ../../rst/network/user_guide/platform_weos4.rst:39 -msgid "WeOS 4 does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``." -msgstr "WeOS 4 は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。" - -#: ../../rst/network/user_guide/platform_weos4.rst:45 -msgid "Example CLI ``group_vars/weos4.yml``" -msgstr "CLI の例 ``group_vars/weos4.yml``" - -#: ../../rst/network/user_guide/platform_weos4.rst:72 -msgid "Example Configuration task" -msgstr "設定タスクの例" - -#: ../../rst/network/user_guide/validate.rst:5 -msgid "Validate data against set criteria with Ansible" -msgstr "Ansible を使用したセット基準に対するデータの検証" - -#: ../../rst/network/user_guide/validate.rst:7 -msgid "The :ref:`validate ` module validates data against your predefined criteria using a validation engine. You can pull this data from a device or file, validate it against your defined criteria, and use the results to identify configuration or operational state drift and optionally take remedial action." -msgstr ":ref:`validate ` モジュールは、検証エンジンを使用して、事前定義の基準に対してデータを検証します。このデータをデバイスまたはファイルからプルし、定義した基準に対してデータを検証して、その結果を使用して設定または動作状態のドリフトを特定し、必要に応じて修正措置を取ることができます。" - -#: ../../rst/network/user_guide/validate.rst:14 -msgid "Understanding the validate plugin" -msgstr "validate プラグインについて" - -#: ../../rst/network/user_guide/validate.rst:16 -msgid "The `ansible.utils `_ collection includes the :ref:`validate ` module." -msgstr "`ansible.utils `_ コレクションには :ref:`validate ` モジュールが含まれます。" - -#: ../../rst/network/user_guide/validate.rst:18 -msgid "To validate data:" -msgstr "データを検証するには、以下を実行します。" - -#: ../../rst/network/user_guide/validate.rst:20 -msgid "Pull in structured data or convert your data to structured format with the :ref:`cli_parse ` module." -msgstr "構造化されたデータをプルするか、:ref:`cli_parse ` モジュールで構造化された形式に変換します。" - -#: ../../rst/network/user_guide/validate.rst:21 -msgid "Define the criteria to test that data against." -msgstr "そのデータをテストする基準を定義します。" - -#: ../../rst/network/user_guide/validate.rst:22 -msgid "Select a validation engine and test the data to see if it is valid based on the selected criteria and validation engine." -msgstr "検証エンジンを選択し、選択した基準と検証エンジンをもとにそのデータが有効かどうかをテストして確認します。" - -#: ../../rst/network/user_guide/validate.rst:24 -msgid "The structure of the data and the criteria depends on the validation engine you select. The examples here use the ``jsonschema`` validation engine provided in the `ansible.utils `_ collection.Red Hat Ansible Automation Platform subscription supports limited use if jsonschema public APIs as documented." -msgstr "データの構造と基準は、選択した検証エンジンによって異なります。この例では `ansible.utils `_ コレクションで提供される ``jsonschema`` 検証エンジンを使用します。Red Hat Ansible Automation Platform サブスクリプションは、記載のとおり jsonschema のパブリック API がサポートされる場合に使用を限定してサポートします。" - -#: ../../rst/network/user_guide/validate.rst:27 -msgid "Structuring the data" -msgstr "データの構造" - -#: ../../rst/network/user_guide/validate.rst:29 -msgid "You can pull previously structured data from a file, or use the :ref:`cli_parse ` module to structure your data." -msgstr "以前に構造化されたデータをファイルからプルするか、:ref:`cli_parse ` モジュールを使用してデータを構築します。" - -#: ../../rst/network/user_guide/validate.rst:31 -msgid "The following example fetches the operational state of some network (Cisco NXOS) interfaces and translates that state to structured data using the ``ansible.netcommon.pyats`` parser." -msgstr "以下の例では、一部のネットワーク(Cisco NXOS)インターフェースの運用状態を取得し、``ansible.netcommon.pyats`` パーサーを使用してその状態を構造化データに変換します。" - -#: ../../rst/network/user_guide/validate.rst:57 -msgid "This results in the following structured data." -msgstr "これにより、以下の構造化データが生成されます。" - -#: ../../rst/network/user_guide/validate.rst:83 -msgid "See :ref:`cli_parsing` for details on how to parse semi-structured data into structured data." -msgstr "半構造化データを構造化データに解析する方法は、「:ref:`cli_parsing`」を参照してください。" - -#: ../../rst/network/user_guide/validate.rst:86 -msgid "Defining the criteria to validate against" -msgstr "検証対象の基準の定義" - -#: ../../rst/network/user_guide/validate.rst:88 -msgid "This example uses the `jsonschema `_ validation engine to parse the JSON structured data we created in the prior section. the criteria defines the state we want the data to conform to. In this instance, we can validate against a desired admin state of ``up`` for all the interfaces." -msgstr "この例では、`jsonschema `_ 検証エンジンを使用して、前のセクションで作成した JSON 構造化データを解析します。基準では、データを適合させる状態を定義します。この例では、すべてのインターフェースに対して ``up`` の必要な管理状態をもとに検証できます。" - -#: ../../rst/network/user_guide/validate.rst:90 -msgid "The criteria for ``jsonschema`` in this example is as follows:" -msgstr "この例の ``jsonschema`` の基準は次のとおりです。" - -#: ../../rst/network/user_guide/validate.rst:111 -msgid "Validating the data" -msgstr "データの検証" - -#: ../../rst/network/user_guide/validate.rst:113 -msgid "Now that we have the structured data and the criteria, we can validate this data with the :ref:`validate ` module." -msgstr "これで構造化データと基準の準備ができたので、このデータを :ref:`validate ` モジュールで検証できます。" - -#: ../../rst/network/user_guide/validate.rst:115 -msgid "The following tasks check if the current state of the interfaces match the desired state defined in the criteria file." -msgstr "以下のタスクは、インターフェースの現在の状態が、基準ファイルで定義されている必要な状態と一致するかどうかを確認します。" - -#: ../../rst/network/user_guide/validate.rst:135 -msgid "In these tasks, we have:" -msgstr "今回のタスクでは、以下を行いました。" - -#: ../../rst/network/user_guide/validate.rst:137 -msgid "Set ``data`` to the structured JSON data from the :ref:`cli_parse ` module." -msgstr "``data`` を :ref:`cli_parse ` モジュールから構造化 JSON データに設定する。" - -#: ../../rst/network/user_guide/validate.rst:138 -msgid "Set ``criteria`` to the JSON criteria file we defined." -msgstr "``criteria`` を定義した JSON 条件ファイルに設定する。" - -#: ../../rst/network/user_guide/validate.rst:139 -msgid "Set the validate engine to ``jsonschema``." -msgstr "検証エンジンを ``jsonschema`` に設定する。" - -#: ../../rst/network/user_guide/validate.rst:143 -msgid "The value of the criteria option can be a list and should be in a format that is defined by the validation engine used. You need to install the `jsonschema `_ on the control node for this example." -msgstr "基準オプションの値には一覧を指定できるので、この値は、使用する検証エンジンで定義される形式である必要があります。今回の例のコントロールノードに、`jsonschema `_ をインストールする必要があります。" - -#: ../../rst/network/user_guide/validate.rst:145 -msgid "The tasks output a list of errors indicating interfaces that do not have admin value in ``up`` state." -msgstr "タスクでは、管理値が ``up`` の状態にないインターフェースを示すエラーの一覧が出力されます。" - -#: ../../rst/network/user_guide/validate.rst:164 -msgid "This shows Ethernet2/1 and Ethernet2/10 are not in the desired state based on the defined criteria. You can create a report or take further action to remediate this to bring the interfaces to the desired state based on the defined criteria." -msgstr "これにより、Ethernet2/1 および Ethernet2/10 は、定義された基準では希望の状態には到達していないことがわかります。レポートを作成するか、定義された基準に基づいてインターフェースを目的に状態にするための改善措置を取ることができます。" - -#~ msgid "The units of action in Ansible. You can execute a single task once with an ad-hoc command." -#~ msgstr "" - -#~ msgid "Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad-hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs." -#~ msgstr "" - -#~ msgid "Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task." -#~ msgstr "" - -#~ msgid "The following is an example TTP template stored as ``templates/nxos_show_interfaces.ttp``:" -#~ msgstr "" - -#~ msgid "Using an ad-hoc ``ansible`` command" -#~ msgstr "" - -#~ msgid "`ad-hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::" -#~ msgstr "" - -#~ msgid "Any machine with Ansible installed. You can run Ansible commands and playbooks by invoking the ``ansible`` or ``ansible-playbook`` command from any control node. You can use any computer that has a Python installation as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes." -#~ msgstr "Ansible がインストールされているマシン。任意のコントロールノードから ``ansible`` コマンドまたは ``ansible-playbook`` コマンドを呼び出すことで、Ansible コマンドおよび Playbook を実行できます。Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを持つことができます。" - -#~ msgid "The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called \"hosts\". Ansible is not installed on managed nodes." -#~ msgstr "Ansible で管理するネットワークデバイス (またはサーバー)。管理ノードは「ホスト」と呼ばれることもあります。Ansible は管理ノードにインストールされません。" - -#~ msgid "A list of managed nodes. An inventory file is also sometimes called a \"hostfile\". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :ref:`the Working with Inventory` section." -#~ msgstr "管理ノードの一覧。インベントリーファイルは「ホストファイル」と呼ばれることもあります。インベントリーは、各管理ノードに対して IP アドレスなどの情報を指定できます。インベントリーは管理ノードを整理でき、スケーリングが容易になるグループの作成やネスト化が可能です。インベントリーの詳細は「:ref:`インベントリーでの作業 `」セクションを参照してください。" - -#~ msgid "The units of action in Ansible. You can execute a single task once with an ad hoc command." -#~ msgstr "Ansible でのアクションの単位。アドホックコマンドを使用すると、単一のタスクを実行できます。" - -#~ msgid "Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`." -#~ msgstr "順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。Playbook の詳細は、「:ref:`about_playbooks`」を参照してください。" - -#~ msgid "IRC and Slack" -#~ msgstr "IRC および Slack" - -#~ msgid "Join us on:" -#~ msgstr "以下に参加してください。" - -#~ msgid "Freenode IRC - ``#ansible-network`` Freenode channel" -#~ msgstr "Freenode IRC - ``#ansible-network`` Freenode チャンネル" - -#~ msgid "Slack - ``_" -#~ msgstr "Slack - ``_" - -#~ msgid "If you have two or more network platforms in your environment, you can use the network agnostic modules to simplify your playbooks. You can use network agnostic modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks." -#~ msgstr "環境内に複数のネットワークプラットフォームがある場合は、ネットワークに依存しないモジュールを使用して、Playbook を簡素化できます。``arista.eos.eos_config``、``cisco.ios.ios_config``、``junipernetworks.junos.junos_config`` などのプラットフォーム固有のモジュールの代わりに、``ansible.netcommon.cli_command``、``ansible.netcommon.cli_config`` などのネットワークに依存しないモジュールを使用できます。これにより、Playbook に必要なタスクおよび条件の数が減ります。" - -#~ msgid "For example::" -#~ msgstr "例::" - -#~ msgid "8.4(1) and later" -#~ msgstr "8.4(1) 以降" - -#~ msgid "If you are specifying credentials via ``password:`` (either directly or via ``provider:``) or the environment variable `ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable \"look for keys\". This can be done like this:" -#~ msgstr "(直接または ``provider:`` を使用して) ``password:`` で認証情報を指定する場合や、環境変数 `ANSIBLE_NET_PASSWORD` を指定する場合は、``paramiko`` (Ansible が使用する Python SSH ライブラリー) が ssh キーを使用している可能性があるため、指定する認証情報が無効になります。これを確認するには、「look for keys」を無効にします。これは次のように行います。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/os_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/os_guide.po deleted file mode 100644 index ffe530e6ae8..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/os_guide.po +++ /dev/null @@ -1,2599 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/os_guide/index.rst:5 -msgid "Using Ansible on Windows and BSD" -msgstr "Ansible の Windows および BSD へのインストール" - -#: ../../rst/os_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/os_guide/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/os_guide/index.rst:13 -msgid "Welcome to the Ansible guide for Microsoft Windows and BSD. Because Windows is not a POSIX-compliant operating system, Ansible interacts with Windows hosts differently to Linux/Unix hosts. Likewise managing hosts that run BSD is different to managing other Unix-like host operating systems. Find out everything you need to know about using Ansible on Windows and with BSD hosts." -msgstr "Microsoft Windows および BSD の Ansible ガイドへようこそ。Windows は POSIX 準拠のオペレーティングシステムではないため、Ansible は Linux/Unix ホストとは異なる方法で Windows ホストと対話します。同様に、BSD を実行するホストの管理は、他の Unix ライクなホストオペレーティングシステムの管理とは異なります。Windows および BSD ホストで Ansible を使用する際に知っておくべきことをすべて確認してください。" - -#: ../../rst/os_guide/intro_bsd.rst:4 -msgid "Managing BSD hosts with Ansible" -msgstr "Ansible を使用した BSD ホストの管理" - -#: ../../rst/os_guide/intro_bsd.rst:6 -msgid "Managing BSD machines is different from managing other Unix-like machines. If you have managed nodes running BSD, review these topics." -msgstr "BSD マシンの管理は、他の Unix 系マシンの管理とは異なります。BSD を実行している管理ノードを使用している場合は、以下のトピックを確認してください。" - -#: ../../rst/os_guide/intro_bsd.rst:12 -msgid "Connecting to BSD nodes" -msgstr "BSD ノードへの接続" - -#: ../../rst/os_guide/intro_bsd.rst:14 -msgid "Ansible connects to managed nodes using OpenSSH by default. This works on BSD if you use SSH keys for authentication. However, if you use SSH passwords for authentication, Ansible relies on sshpass. Most versions of sshpass do not deal well with BSD login prompts, so when using SSH passwords against BSD machines, use ``paramiko`` to connect instead of OpenSSH. You can do this in ansible.cfg globally or you can set it as an inventory/group/host variable. For example:" -msgstr "Ansible はデフォルトで OpenSSH を使用して管理ノードに接続します。これは、認証に SSH 鍵を使用している場合は BSD で動作します。ただし、認証に SSH パスワードを使用する場合、Ansible は sshpass に依存します。sshpass のほとんどのバージョンは BSD のログインプロンプトに適切に対応できません。したがって、BSD マシンに対して SSH パスワードを使用する場合は、OpenSSH の代わりに ``paramiko`` を使用して接続してください。これは ansible.cfg でグローバルに行うこともできますし、inventory/group/host 変数として設定することもできます。以下に例を示します。" - -#: ../../rst/os_guide/intro_bsd.rst:25 -msgid "Bootstrapping BSD" -msgstr "BSD のブートストラップ" - -#: ../../rst/os_guide/intro_bsd.rst:27 -msgid "Ansible is agentless by default, however, it requires Python on managed nodes. Only the :ref:`raw ` module will operate without Python. Although this module can be used to bootstrap Ansible and install Python on BSD variants (see below), it is very limited and the use of Python is required to make full use of Ansible's features." -msgstr "Ansible はデフォルトでエージェントレスですが、管理ノードで Python が必要になります。:ref:`raw ` モジュールのみが Python なしで動作します。このモジュールを使用して Ansible をブートストラップして BSD バリアントに Python をインストールできます (下記参照) が、Python は非常に制限されており、Ansible の機能を完全に活用するには Python を使用する必要があります。" - -#: ../../rst/os_guide/intro_bsd.rst:29 -msgid "The following example installs Python which includes the json library required for full functionality of Ansible. On your control machine you can execute the following for most versions of FreeBSD:" -msgstr "次の例では、Ansible の完全な機能に必要な json ライブラリーを含む Python をインストールしています。コントロールマシンでは、ほとんどのバージョンの FreeBSD で次のように実行できます。" - -#: ../../rst/os_guide/intro_bsd.rst:36 -msgid "Or for OpenBSD:" -msgstr "OpenBSD の場合は、次のコマンドを使用します。" - -#: ../../rst/os_guide/intro_bsd.rst:42 -msgid "Once this is done you can now use other Ansible modules apart from the ``raw`` module." -msgstr "これが完了すると、``raw`` モジュール以外の他の Ansible モジュールを使用できるようになります。" - -#: ../../rst/os_guide/intro_bsd.rst:45 -msgid "This example demonstrated using pkg on FreeBSD and pkg_add on OpenBSD, however you should be able to substitute the appropriate package tool for your BSD; the package name may also differ. Refer to the package list or documentation of the BSD variant you are using for the exact Python package name you intend to install." -msgstr "この例では、FreeBSD では pkg を、OpenBSD では pkg_add を使用していますが、お使いの BSD に合わせて適切なパッケージツールを選択してください。また、パッケージ名も異なる場合があります。インストールする Python パッケージ名については、使用している BSD のパッケージリストやドキュメントを参照してください。" - -#: ../../rst/os_guide/intro_bsd.rst:50 -msgid "Setting the Python interpreter" -msgstr "Python インタープリターの設定" - -#: ../../rst/os_guide/intro_bsd.rst:52 -msgid "To support a variety of Unix-like operating systems and distributions, Ansible cannot always rely on the existing environment or ``env`` variables to locate the correct Python binary. By default, modules point at ``/usr/bin/python`` as this is the most common location. On BSD variants, this path may differ, so it is advised to inform Ansible of the binary's location. See :ref:`INTERPRETER_PYTHON`. For example, set ``ansible_python_interpreter`` inventory variable:" -msgstr "さまざまな Unix 系オペレーティングシステムやディストリビューションをサポートするために、Ansible は常に既存の環境変数や ``env`` 変数を頼りに正しい Python バイナリーを探すことはできません。デフォルトでは、モジュールは最も一般的な場所である ``/usr/bin/python`` を指します。BSD 系では、このパスが異なる場合があるので、バイナリーの場所を Ansible に知らせることが推奨されます。:ref:`INTERPRETER_PYTHON` を参照してください。たとえば、``ansible_python_interpreter`` インベントリー変数を設定します。" - -#: ../../rst/os_guide/intro_bsd.rst:63 -msgid "FreeBSD packages and ports" -msgstr "FreeBSD パッケージおよびポート" - -#: ../../rst/os_guide/intro_bsd.rst:65 -msgid "In FreeBSD, there is no guarantee that either ``/usr/local/bin/python`` executable file or a link to an executable file is installed by default. The best practice for a remote host, with respect to Ansible, is to install at least the Python version supported by Ansible, for example, ``lang/python38``, and both meta ports ``lang/python3`` and ``lang/python``. Quoting from */usr/ports/lang/python3/pkg-descr*:" -msgstr "FreeBSD では、``/usr/local/bin/python`` 実行可能ファイルまたは実行可能ファイルへのリンクのいずれかがデフォルトでインストールされる保証はありません。Ansible に関連してリモートホストのベストプラクティスは、少なくともAnsible がサポートする Python バージョン（例：``lang/python38`` および ``lang/python3`` と ``lang/python`` 両方のメタポート）をインストールすることです。*/usr/ports/lang/python3/pkg-descr* からの引用:" - -#: ../../rst/os_guide/intro_bsd.rst:73 -msgid "Quoting from */usr/ports/lang/python/pkg-descr*:" -msgstr "*/usr/ports/lang/python/pkg-descr* からの引用：" - -#: ../../rst/os_guide/intro_bsd.rst:81 -msgid "As a result, the following packages are installed:" -msgstr "これにより、以下のパッケージがインストールされます。" - -#: ../../rst/os_guide/intro_bsd.rst:90 -msgid "and the following executables and links" -msgstr "さらに、以下の実行ファイルとリンクがインストールされます。" - -#: ../../rst/os_guide/intro_bsd.rst:104 -msgid "INTERPRETER_PYTHON_FALLBACK" -msgstr "INTERPRETER_PYTHON_FALLBACK" - -#: ../../rst/os_guide/intro_bsd.rst:106 -msgid "Since version 2.8 Ansible provides a useful variable ``ansible_interpreter_python_fallback`` to specify a list of paths to search for Python. See :ref:`INTERPRETER_PYTHON_FALLBACK`. This list will be searched and the first item found will be used. For example, the configuration below would make the installation of the meta-ports in the previous section redundant, that is, if you don't install the Python meta ports the first two items in the list will be skipped and ``/usr/local/bin/python3.8`` will be discovered." -msgstr "バージョン 2.8 以降、Ansible には、Python を検索するパスの一覧を指定するための便利な変数 ``ansible_interpreter_python_fallback`` が用意されています。「:ref:`INTERPRETER_PYTHON_FALLBACK`」を参照してください。この一覧を検索し、見つかった最初の項目が使用されます。たとえば、以下の設定では、前のセクションのメタポートのインストールが冗長になります。つまり、Python メタポートをインストールしないと、リストの最初の 2 つの項目が省略され、``/usr/local/bin/python3.8`` が検出されます。" - -#: ../../rst/os_guide/intro_bsd.rst:113 -msgid "You can use this variable, prolonged by the lower versions of Python, and put it, for example, into the ``group_vars/all``. Then, override it for specific groups in ``group_vars/{group1, group2, ...}`` and for specific hosts in ``host_vars/{host1, host2, ...}`` if needed. See :ref:`ansible_variable_precedence`." -msgstr "Python の下位バージョンで延ばされているこの変数を使い、例えば``group_vars/all``に入れます。そして、必要に応じて``group_vars/{group1, group2, ...}``の特定グループに対して、また``host_vars/{host1, host2, ...}``の特定ホストに対して、オーバーライドします。:ref:`ansible_variable_precedence`を参照してください。" - -#: ../../rst/os_guide/intro_bsd.rst:117 -msgid "Debug the discovery of Python" -msgstr "Python の検出のデバッグ" - -#: ../../rst/os_guide/intro_bsd.rst:119 -msgid "For example, given the inventory" -msgstr "たとえば、以下のインベントリーを想定します。" - -#: ../../rst/os_guide/intro_bsd.rst:138 -msgid "The playbook below" -msgstr "以下のPlaybook により、" - -#: ../../rst/os_guide/intro_bsd.rst:159 -msgid "displays the details" -msgstr "詳細が表示されます。" - -#: ../../rst/os_guide/intro_bsd.rst:192 -msgid "You can see that the first item from the list ``ansible_interpreter_python_fallback`` was discovered at the FreeBSD remote host. The variable ``ansible_playbook_python`` keeps the path to Python at the Linux controller that ran the playbook." -msgstr "リストの最初のアイテム ``ansible_interpreter_python_fallback`` が FreeBSD リモートホストで検出されていることが分かります。変数 ``ansible_playbook_python`` は、Playbook を実行した Linux コントローラーで Python へのパスを保持します。" - -#: ../../rst/os_guide/intro_bsd.rst:194 -msgid "Regarding the warning, quoting from :ref:`INTERPRETER_PYTHON`" -msgstr "警告に関して、:ref:`INTERPRETER_PYTHON`からの引用" - -#: ../../rst/os_guide/intro_bsd.rst:203 -msgid "You can either ignore it or get rid of it by setting the variable ``ansible_python_interpreter=auto_silent`` because this is, actually, what you want by using ``/usr/local/bin/python`` (*\"interpreters installed later may change which one is used\"*). For example" -msgstr "変数 ``ansible_python_interpreter=auto_silent`` を設定することで、これを無視するか、または取り除くことができます。これは、実際に ``/usr/local/bin/python`` を使用して希望するものだからです（*「後でインストールされるインタープリターにより、使用されるものが変わる場合があります」*）。以下に例を示します。" - -#: ../../rst/os_guide/intro_bsd.rst:226 -msgid ":ref:`interpreter_discovery`" -msgstr ":ref:`interpreter_discovery`" - -#: ../../rst/os_guide/intro_bsd.rst:227 -msgid "`FreeBSD Wiki: Ports/DEFAULT_VERSIONS `_" -msgstr "`FreeBSD Wiki: Ports/DEFAULT_VERSIONS `_" - -#: ../../rst/os_guide/intro_bsd.rst:231 -msgid "Additional variables" -msgstr "追加の変数" - -#: ../../rst/os_guide/intro_bsd.rst:233 -msgid "If you use additional plugins beyond those bundled with Ansible, you can set similar variables for ``bash``, ``perl`` or ``ruby``, depending on how the plugin is written. For example:" -msgstr "Ansible でバンドルされているプラグイン以外のプラグインを使用する場合は、プラグインの記述方法に応じて ``bash``、``perl``、または ``ruby`` に同様の変数を設定できます。" - -#: ../../rst/os_guide/intro_bsd.rst:243 -msgid "Which modules are available?" -msgstr "利用可能なモジュール" - -#: ../../rst/os_guide/intro_bsd.rst:245 -msgid "The majority of the core Ansible modules are written for a combination of Unix-like machines and other generic services, so most should function well on the BSDs with the obvious exception of those that are aimed at Linux-only technologies (such as LVG)." -msgstr "Ansible のコアモジュールの大半は、Unix 系マシンと他の汎用サービスを組み合わせて記述されているため、Linux に限定したテクノロジー (LVG など) を対象とするものを除き、その大半が BSD 上で正常に機能します。" - -#: ../../rst/os_guide/intro_bsd.rst:248 -msgid "Using BSD as the control node" -msgstr "コントロールノードとしての BSD の使用" - -#: ../../rst/os_guide/intro_bsd.rst:250 -msgid "Using BSD as the control machine is as simple as installing the Ansible package for your BSD variant or by following the ``pip`` or 'from source' instructions." -msgstr "BSD をコントロールマシンとして使用することは、BSD バリアントの Ansible パッケージをインストールするか、``pip`` または「from source」の指示に従うのと同じくらい簡単です。" - -#: ../../rst/os_guide/intro_bsd.rst:255 -msgid "BSD facts" -msgstr "BSD ファクト" - -#: ../../rst/os_guide/intro_bsd.rst:257 -msgid "Ansible gathers facts from the BSDs in a similar manner to Linux machines, but since the data, names and structures can vary for network, disks and other devices, one should expect the output to be slightly different yet still familiar to a BSD administrator." -msgstr "Ansible は、Linux マシンと同様の方法で BSD からファクトを収集しますが、データ、名前、構造は、ネットワーク、ディスク、およびその他のデバイスにより異なる可能性があるため、BSD 管理者にとっては出力が多少異なるもののまだ馴染みがあることが期待できます。" - -#: ../../rst/os_guide/intro_bsd.rst:262 -msgid "BSD efforts and contributions" -msgstr "BSD の取り組みおよび貢献" - -#: ../../rst/os_guide/intro_bsd.rst:264 -msgid "BSD support is important to us at Ansible. Even though the majority of our contributors use and target Linux we have an active BSD community and strive to be as BSD-friendly as possible. Please feel free to report any issues or incompatibilities you discover with BSD; pull requests with an included fix are also welcome!" -msgstr "BSD サポートは Ansible にとって重要です。貢献者の大半は Linux を使用していますが、Ansible には活発な BSD コミュニティーがあり、可能な限り BSD フレンドリーであるように努めています。BSD に関する問題や非互換性を発見した場合は、遠慮なくご報告ください。" - -#: ../../rst/os_guide/intro_bsd.rst:269 -msgid ":ref:`intro_adhoc`" -msgstr ":ref:`intro_adhoc`" - -#: ../../rst/os_guide/intro_bsd.rst:270 -msgid "Examples of basic commands" -msgstr "基本コマンドの例" - -#: ../../rst/os_guide/intro_bsd.rst:271 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/os_guide/intro_bsd.rst:272 -msgid "Learning ansible's configuration management language" -msgstr "Ansible の設定管理言語の概要" - -#: ../../rst/os_guide/intro_bsd.rst:273 -msgid ":ref:`developing_modules`" -msgstr ":ref:`developing_modules`" - -#: ../../rst/os_guide/intro_bsd.rst:274 -msgid "How to write modules" -msgstr "モジュールの書き方" - -#: ../../rst/os_guide/intro_bsd.rst:275 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/os_guide/intro_bsd.rst:276 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/os_guide/intro_bsd.rst:277 ../../rst/os_guide/windows_dsc.rst:507 -#: ../../rst/os_guide/windows_faq.rst:256 -#: ../../rst/os_guide/windows_setup.rst:498 -#: ../../rst/os_guide/windows_usage.rst:518 -#: ../../rst/os_guide/windows_winrm.rst:1012 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/os_guide/intro_bsd.rst:278 ../../rst/os_guide/windows_dsc.rst:508 -#: ../../rst/os_guide/windows_faq.rst:257 -#: ../../rst/os_guide/windows_setup.rst:499 -#: ../../rst/os_guide/windows_usage.rst:519 -#: ../../rst/os_guide/windows_winrm.rst:1013 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/os_guide/windows_dsc.rst:4 -msgid "Desired State Configuration" -msgstr "Desired State Configuration" - -#: ../../rst/os_guide/windows_dsc.rst:7 ../../rst/os_guide/windows_usage.rst:11 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/os_guide/windows_dsc.rst:10 -msgid "What is Desired State Configuration?" -msgstr "Desired State Configuration とは" - -#: ../../rst/os_guide/windows_dsc.rst:11 -msgid "Desired State Configuration, or DSC, is a tool built into PowerShell that can be used to define a Windows host setup through code. The overall purpose of DSC is the same as Ansible, it is just executed in a different manner. Since Ansible 2.4, the ``win_dsc`` module has been added and can be used to take advantage of existing DSC resources when interacting with a Windows host." -msgstr "Desired State Configuration (DSC) は、PowerShell に組み込まれたツールで、コードによって Windows ホストのセットアップを定義するために使用することができます。DSC の全体的な目的は Ansible と同じですが、実行方法が異なるだけです。Ansible 2.4 からは、``win_dsc`` モジュールが追加され、Windows ホストとのやりとりの際に、既存の DSC リソースを活用することができます。" - -#: ../../rst/os_guide/windows_dsc.rst:17 -msgid "More details on DSC can be viewed at `DSC Overview `_." -msgstr "DSC の詳細は、`DSC Overview `_ を参照してください。" - -#: ../../rst/os_guide/windows_dsc.rst:20 -#: ../../rst/os_guide/windows_setup.rst:11 -msgid "Host Requirements" -msgstr "ホスト要件" - -#: ../../rst/os_guide/windows_dsc.rst:21 -msgid "To use the ``win_dsc`` module, a Windows host must have PowerShell v5.0 or newer installed. All supported hosts can be upgraded to PowerShell v5." -msgstr "``win_dsc`` モジュールを使用するには、Windows ホストに PowerShell v5.0 以降がインストールされている必要があります。サポート対象のホストはすべて、PowerShell v5.0 にアップグレードすることができます。" - -#: ../../rst/os_guide/windows_dsc.rst:24 -msgid "Once the PowerShell requirements have been met, using DSC is as simple as creating a task with the ``win_dsc`` module." -msgstr "PowerShell の要件を満たしていれば、DSC を使用することは、``win_dsc`` モジュールでタスクを作成するのと同じぐらい簡単です。" - -#: ../../rst/os_guide/windows_dsc.rst:28 -msgid "Why Use DSC?" -msgstr "DSC を使用する理由" - -#: ../../rst/os_guide/windows_dsc.rst:29 -msgid "DSC and Ansible modules have a common goal which is to define and ensure the state of a resource. Because of this, resources like the DSC `File resource `_ and Ansible ``win_file`` can be used to achieve the same result. Deciding which to use depends on the scenario." -msgstr "DSC と Ansible モジュールには、リソースの状態を定義して保証するという共通の目的があります。このため、DSC `ファイルリソース `_ や Ansible``win_file`` のようなリソースを使用して、同じ結果を得ることができます。どちらを使用するかは、シナリオによって異なります。" - -#: ../../rst/os_guide/windows_dsc.rst:35 -msgid "Reasons for using an Ansible module over a DSC resource:" -msgstr "DSC リソースで Ansible モジュールを使用する理由:" - -#: ../../rst/os_guide/windows_dsc.rst:37 -msgid "The host does not support PowerShell v5.0, or it cannot easily be upgraded" -msgstr "ホストが PowerShell v5.0 をサポートしていない、または簡単にアップグレードできない" - -#: ../../rst/os_guide/windows_dsc.rst:38 -msgid "The DSC resource does not offer a feature present in an Ansible module. For example, win_regedit can manage the ``REG_NONE`` property type, while the DSC ``Registry`` resource cannot" -msgstr "DSC リソースは、Ansible モジュールに存在する機能を提供しない。たとえば、win_regedit は ``REG_NONE`` のプロパティータイプを管理できますが、DSC の ``Registry`` リソースでは管理できません。" - -#: ../../rst/os_guide/windows_dsc.rst:41 -msgid "DSC resources have limited check mode support, while some Ansible modules have better checks" -msgstr "DSC のリソースはチェックモードのサポートが限られているが、Ansible モジュールの中にはより優れたチェック機能を持つものがある" - -#: ../../rst/os_guide/windows_dsc.rst:43 -msgid "DSC resources do not support diff mode, while some Ansible modules do" -msgstr "DSC リソースでは差分モードがサポートされないが、一部の Ansible モジュールではサポートされる" - -#: ../../rst/os_guide/windows_dsc.rst:44 -msgid "Custom resources require further installation steps to be run on the host beforehand, while Ansible modules are built-in to Ansible" -msgstr "カスタムリソースでは、事前にホスト上で追加のインストール手順を実行する必要があるが、Ansible モジュールは Ansible に組み込まれている" - -#: ../../rst/os_guide/windows_dsc.rst:46 -msgid "There are bugs in a DSC resource where an Ansible module works" -msgstr "Ansible モジュールが機能する DSC リソースにバグがある" - -#: ../../rst/os_guide/windows_dsc.rst:48 -msgid "Reasons for using a DSC resource over an Ansible module:" -msgstr "Ansible モジュールで DSC リソースを使用する理由:" - -#: ../../rst/os_guide/windows_dsc.rst:50 -msgid "The Ansible module does not support a feature present in a DSC resource" -msgstr "Ansible モジュールは、DSC リソースに存在する機能をサポートしていない" - -#: ../../rst/os_guide/windows_dsc.rst:51 -msgid "There is no Ansible module available" -msgstr "利用可能な Ansible モジュールがない" - -#: ../../rst/os_guide/windows_dsc.rst:52 -msgid "There are bugs in an existing Ansible module" -msgstr "既存の Ansible モジュールにバグがある" - -#: ../../rst/os_guide/windows_dsc.rst:54 -msgid "In the end, it doesn't matter whether the task is performed with DSC or an Ansible module; what matters is that the task is performed correctly and the playbooks are still readable. If you have more experience with DSC over Ansible and it does the job, just use DSC for that task." -msgstr "つまるところ、タスクが DSC で実行されるか Ansible モジュールで実行されるかは重要ではありません。重要なのは、タスクが正しく実行され、Playbook が読めることです。Ansible よりも DSC の方を使用した経験があり、それで必要なことができるのであれば、そのタスクには DSC を使用すると良いでしょう。" - -#: ../../rst/os_guide/windows_dsc.rst:60 -msgid "How to Use DSC?" -msgstr "DSC の使用方法" - -#: ../../rst/os_guide/windows_dsc.rst:61 -msgid "The ``win_dsc`` module takes in a free-form of options so that it changes according to the resource it is managing. A list of built-in resources can be found at `resources `_." -msgstr "``win_dsc`` モジュールは、管理しているリソースに応じて変化するように、フリーフォームのオプションを取り入れています。組み込まれているリソースのリストは、`resources `_ を参照してください。" - -#: ../../rst/os_guide/windows_dsc.rst:65 -msgid "Using the `Registry `_ resource as an example, this is the DSC definition as documented by Microsoft:" -msgstr "`Registry `_ リソースを例にとると、これは Microsoft が文書化したDSCの定義です。" - -#: ../../rst/os_guide/windows_dsc.rst:82 -msgid "When defining the task, ``resource_name`` must be set to the DSC resource being used - in this case, the ``resource_name`` should be set to ``Registry``. The ``module_version`` can refer to a specific version of the DSC resource installed; if left blank it will default to the latest version. The other options are parameters that are used to define the resource, such as ``Key`` and ``ValueName``. While the options in the task are not case sensitive, keeping the case as-is is recommended because it makes it easier to distinguish DSC resource options from Ansible's ``win_dsc`` options." -msgstr "タスクを定義する際には、使用する DSC リソースを ``resource_name`` に設定する必要があります。この場合、``resource_name`` は ``Registry`` に設定する必要があります。``module_version`` はインストールされている DSC リソースの特定のバージョンを参照することができますが、空白にするとデフォルトで最新バージョンになります。その他のオプションは ``Key`` や ``ValueName`` のようにリソースを定義するためのパラメーターになります。タスクのオプションは大文字小文字を区別しませんが、DSC リソースのオプションと Ansible の``win_dsc`` のオプションを区別しやすくするために、大文字小文字をそのままにしておくことが推奨されます。" - -#: ../../rst/os_guide/windows_dsc.rst:91 -msgid "This is what the Ansible task version of the above DSC Registry resource would look like:" -msgstr "上記の DSC レジストリーリソースの Ansible タスクバージョンは、以下のようになります。" - -#: ../../rst/os_guide/windows_dsc.rst:103 -msgid "Starting in Ansible 2.8, the ``win_dsc`` module automatically validates the input options from Ansible with the DSC definition. This means Ansible will fail if the option name is incorrect, a mandatory option is not set, or the value is not a valid choice. When running Ansible with a verbosity level of 3 or more (``-vvv``), the return value will contain the possible invocation options based on the ``resource_name`` specified. Here is an example of the invocation output for the above ``Registry`` task:" -msgstr "Ansible 2.8 より、``win_dsc`` モジュールは、Ansible からの入力オプションを DSC 定義で自動的に検証します。つまり、オプション名が間違っていたり、必須オプションが設定されていなかったり、値が有効な選択肢でなかったりすると、Ansible は失敗します。Ansible を冗長レベル 3 以上 (``-vvv``) で実行した場合、戻り値には、指定された ``resource_name`` に基づいて可能な呼び出しオプションが含まれます。以下は、上記の ``Registry`` タスクの呼び出し出力の例です。" - -#: ../../rst/os_guide/windows_dsc.rst:158 -msgid "The ``invocation.module_args`` key shows the actual values that were set as well as other possible values that were not set. Unfortunately, this will not show the default value for a DSC property, only what was set from the Ansible task. Any ``*_password`` option will be masked in the output for security reasons; if there are any other sensitive module options, set ``no_log: True`` on the task to stop all task output from being logged." -msgstr "``invocation.module_args`` キーは、設定された実際の値と、設定されなかった他の可能な値を表示します。DSC プロパティーのデフォルト値は表示されず、Ansible タスクで設定された値のみが表示されます。``*_password`` オプションは、セキュリティー上の理由から出力ではマスクされます。他に機密性の高いモジュールオプションがある場合は、タスクに ``no_log: True`` を設定して、すべてのタスク出力がログに記録されないようにしてください。" - -#: ../../rst/os_guide/windows_dsc.rst:167 -msgid "Property Types" -msgstr "プロパティータイプ" - -#: ../../rst/os_guide/windows_dsc.rst:168 -msgid "Each DSC resource property has a type that is associated with it. Ansible will try to convert the defined options to the correct type during execution. For simple types like ``[string]`` and ``[bool]``, this is a simple operation, but complex types like ``[PSCredential]`` or arrays (like ``[string[]]``) require certain rules." -msgstr "各 DSC リソースプロパティーには、それに関連付けられたタイプがあります。Ansible は、実行時に定義されたオプションを正しいタイプに変換しようとします。``[string]`` や ``[bool]`` のような単純なタイプでは、これは単純な操作ですが、``[PSCredential]`` や配列 (``[string[]]`` など) のような複雑なタイプでは、特定のルールが必要です。" - -#: ../../rst/os_guide/windows_dsc.rst:175 -msgid "PSCredential" -msgstr "PSCredential" - -#: ../../rst/os_guide/windows_dsc.rst:176 -msgid "A ``[PSCredential]`` object is used to store credentials in a secure way, but Ansible has no way to serialize this over JSON. To set a DSC PSCredential property, the definition of that parameter should have two entries that are suffixed with ``_username`` and ``_password`` for the username and password, respectively. For example:" -msgstr "``[PSCredential]`` オブジェクトは認証情報を安全な方法で保存するために使用されますが、Ansible にはこれを JSON でシリアル化する方法がありません。DSC PSCredential プロパティーを設定するには、そのパラメーターの定義に、ユーザ名とパスワードをそれぞれ ``_username`` と ``_password`` をサフィックスにした 2 つのエントリーを追加する必要があります。たとえば、以下のようになります。" - -#: ../../rst/os_guide/windows_dsc.rst:190 -msgid "On versions of Ansible older than 2.8, you should set ``no_log: true`` on the task definition in Ansible to ensure any credentials used are not stored in any log file or console output." -msgstr "2.8 より古いバージョンの Ansible では、Ansible のタスク定義に ``no_log: true`` を設定して、使用する認証情報がログファイルまたはコンソールの出力に保存されないようにする必要があります。" - -#: ../../rst/os_guide/windows_dsc.rst:194 -msgid "A ``[PSCredential]`` is defined with ``EmbeddedInstance(\"MSFT_Credential\")`` in a DSC resource MOF definition." -msgstr "``[PSCredential]`` は、DSC リソースの MOF 定義において``EmbeddedInstance(\"MSFT_Credential\")`` と共に定義されます。" - -#: ../../rst/os_guide/windows_dsc.rst:198 -msgid "CimInstance Type" -msgstr "CimInstance タイプ" - -#: ../../rst/os_guide/windows_dsc.rst:199 -msgid "A ``[CimInstance]`` object is used by DSC to store a dictionary object based on a custom class defined by that resource. Defining a value that takes in a ``[CimInstance]`` in YAML is the same as defining a dictionary in YAML. For example, to define a ``[CimInstance]`` value in Ansible:" -msgstr "``[CimInstance]`` オブジェクトは、DSC がそのリソースで定義されたカスタムクラスに基づいてディクショナリーオブジェクトを格納するために使用されます。``[CimInstance]`` を取り込む値を YAML で定義することは、YAML でディクショナリーを定義することと同じです。たとえば、Ansible で``[CimInstance]`` の値を定義する場合は、以下のようになります。" - -#: ../../rst/os_guide/windows_dsc.rst:213 -msgid "In the above example, the CIM instance is a representation of the class `MSFT_xWebAuthenticationInformation `_. This class accepts four boolean variables, ``Anonymous``, ``Basic``, ``Digest``, and ``Windows``. The keys to use in a ``[CimInstance]`` depend on the class it represents. Please read through the documentation of the resource to determine the keys that can be used and the types of each key value. The class definition is typically located in the ``.schema.mof``." -msgstr "上記の例では、CIM インスタンスは、クラス `MSFT_xWebAuthenticationInformation `_ の表現です。このクラスは、``Anonymous``、``Basic``、``Digest``、``Windows`` という 4 つのブール変数を受け入れます。``[CimInstance]`` で使用するキーは、それが表現するクラスによって異なります。使用できるキーと各キーの値のタイプについては、リソースのドキュメントを参照してください。クラスの定義は、通常、``.schema.mof`` にあります。" - -#: ../../rst/os_guide/windows_dsc.rst:222 -msgid "HashTable Type" -msgstr "HashTable タイプ" - -#: ../../rst/os_guide/windows_dsc.rst:223 -msgid "A ``[HashTable]`` object is also a dictionary but does not have a strict set of keys that can/need to be defined. Like a ``[CimInstance]``, define it as a normal dictionary value in YAML. A ``[HashTable]]`` is defined with ``EmbeddedInstance(\"MSFT_KeyValuePair\")`` in a DSC resource MOF definition." -msgstr "``[HashTable]`` オブジェクトもディクショナリーですが、定義できる/しなければならない厳密な鍵のセットがありません。``[CimInstance]`` のように、YAML で通常のディクショナリー値のように定義します。``[HashTable]]`` は、DSC リソースの MOF 定義において ``EmbeddedInstance(\"MSFT_KeyValuePair\")`` と共に定義されます。" - -#: ../../rst/os_guide/windows_dsc.rst:229 -msgid "Arrays" -msgstr "配列" - -#: ../../rst/os_guide/windows_dsc.rst:230 -msgid "Simple type arrays like ``[string[]]`` or ``[UInt32[]]`` are defined as a list or as a comma-separated string which is then cast to their type. Using a list is recommended because the values are not manually parsed by the ``win_dsc`` module before being passed to the DSC engine. For example, to define a simple type array in Ansible:" -msgstr "``[string[]]`` や ``[UInt32[]]`` のような単純なタイプの配列は、リストまたはコンマ区切りの文字列として定義され、それらがタイプにキャストされます。リストを使用すると、DSC エンジンに渡す前に ``win_dsc`` モジュールで値が手動で解析されないため、推奨されます。たとえば、Ansible で単純なタイプの配列を定義するには、次のようにします。" - -#: ../../rst/os_guide/windows_dsc.rst:251 -msgid "Complex type arrays like ``[CimInstance[]]`` (array of dicts), can be defined like this example:" -msgstr "``[CimInstance[]]`` (ディクショナリーの配列) のような複雑なタイプの配列は、次の例のように定義できます。" - -#: ../../rst/os_guide/windows_dsc.rst:269 -msgid "The above example is an array with two values of the class `MSFT_xWebBindingInformation `_. When defining a ``[CimInstance[]]``, be sure to read the resource documentation to find out what keys to use in the definition." -msgstr "上記の例は、`MSFT_xWebBindingInformation `_ クラスの 2 つの値のある配列です。``[CimInstance[]]`` を定義すると、リソースドキュメントを参照して、定義で使用するキーを確認してください。" - -#: ../../rst/os_guide/windows_dsc.rst:274 -msgid "DateTime" -msgstr "日時" - -#: ../../rst/os_guide/windows_dsc.rst:275 -msgid "A ``[DateTime]`` object is a DateTime string representing the date and time in the `ISO 8601 `_ date time format. The value for a ``[DateTime]`` field should be quoted in YAML to ensure the string is properly serialized to the Windows host. Here is an example of how to define a ``[DateTime]`` value in Ansible:" -msgstr "``[DateTime]`` オブジェクトは、`ISO 8601 `_ の日時フォーマットで日付と時間を表す DateTime 文字列です。``[DateTime]`` フィールドの値は、文字列が Windows ホストに適切にシリアライズされるように、YAML で引用する必要があります。以下は、Ansible で``[DateTime]`` の値を定義する方法の例です。" - -#: ../../rst/os_guide/windows_dsc.rst:292 -msgid "All the values above are equal to a UTC date time of February 22nd 2019 at 1:57pm with 31 seconds and 2311892 milliseconds." -msgstr "上記のすべての値は、UTCの 日付時刻が 2019 年 2 月 22 日午後 1 時 57 分 31 秒 2311892 ミリ秒であることと同じです。" - -#: ../../rst/os_guide/windows_dsc.rst:296 -msgid "Run As Another User" -msgstr "別のユーザーとして実行" - -#: ../../rst/os_guide/windows_dsc.rst:297 -msgid "By default, DSC runs each resource as the SYSTEM account and not the account that Ansible uses to run the module. This means that resources that are dynamically loaded based on a user profile, like the ``HKEY_CURRENT_USER`` registry hive, will be loaded under the ``SYSTEM`` profile. The parameter ``PsDscRunAsCredential`` is a parameter that can be set for every DSC resource, and force the DSC engine to run under a different account. As ``PsDscRunAsCredential`` has a type of ``PSCredential``, it is defined with the ``_username`` and ``_password`` suffix." -msgstr "デフォルトでは、DSC は各リソースを、Ansible がモジュールの実行に使用するアカウントではなく、SYSTEM アカウントとして実行します。つまり、``HKEY_CURRENT_USER`` のレジストリーハイブのように、ユーザープロファイルに基づいて動的に読み込まれるリソースは、``SYSTEM`` のプロファイルで読み込まれます。``PsDscRunAsCredential`` は、DSC エンジンが別のアカウントで実行されるように、すべての DSC リソースに設定することができるパラメーターです。``PsDscRunAsCredential`` はタイプが ``PSCredential`` なので、サフィックス ``_username`` と``_password`` で定義されています。" - -#: ../../rst/os_guide/windows_dsc.rst:306 -msgid "Using the Registry resource type as an example, this is how to define a task to access the ``HKEY_CURRENT_USER`` hive of the Ansible user:" -msgstr "レジストリーリソースタイプを例として使用し、Ansible ユーザーの ``HKEY_CURRENT_USER`` ハイブにアクセスするタスクを定義する方法を説明します。" - -#: ../../rst/os_guide/windows_dsc.rst:323 -msgid "Custom DSC Resources" -msgstr "カスタムの DSC リソース" - -#: ../../rst/os_guide/windows_dsc.rst:324 -msgid "DSC resources are not limited to the built-in options from Microsoft. Custom modules can be installed to manage other resources that are not usually available." -msgstr "DSC のリソースは、Microsoft の組み込みオプションに限定されません。カスタムモジュールをインストールすることで、通常では利用できない他のリソースを管理することができます。" - -#: ../../rst/os_guide/windows_dsc.rst:328 -msgid "Finding Custom DSC Resources" -msgstr "カスタムの DSC リソースの見つけ方" - -#: ../../rst/os_guide/windows_dsc.rst:329 -msgid "You can use the `PSGallery `_ to find custom resources, along with documentation on how to install them on a Windows host." -msgstr "`PSGallery `_ を使用すると、カスタムリソースと、それを Windows ホストにインストールする方法に関するドキュメントを見つけることができます。" - -#: ../../rst/os_guide/windows_dsc.rst:332 -msgid "The ``Find-DscResource`` cmdlet can also be used to find custom resources. For example:" -msgstr "``Find-DscResource`` コマンドレットを使用して、カスタムリソースを検索することもできます。以下に例を示します。" - -#: ../../rst/os_guide/windows_dsc.rst:342 -msgid "DSC resources developed by Microsoft that start with ``x`` means the resource is experimental and comes with no support." -msgstr "Microsoft が開発した DSC リソースで、``x`` で始まるものは、実験的なリソースであり、サポートがないことを意味しています。" - -#: ../../rst/os_guide/windows_dsc.rst:346 -msgid "Installing a Custom Resource" -msgstr "カスタムリソースのインストール" - -#: ../../rst/os_guide/windows_dsc.rst:347 -msgid "There are three ways that a DSC resource can be installed on a host:" -msgstr "DSC リソースをホストにインストールする方法は 3 つあります。" - -#: ../../rst/os_guide/windows_dsc.rst:349 -msgid "Manually with the ``Install-Module`` cmdlet" -msgstr "``Install-Module`` コマンドレットを手動で使用" - -#: ../../rst/os_guide/windows_dsc.rst:350 -msgid "Using the ``win_psmodule`` Ansible module" -msgstr "Ansibleモジュール ``win_psmodule`` を使用" - -#: ../../rst/os_guide/windows_dsc.rst:351 -msgid "Saving the module manually and copying it to another host" -msgstr "モジュールを手動で保存して別のホストにコピー" - -#: ../../rst/os_guide/windows_dsc.rst:353 -msgid "The following is an example of installing the ``xWebAdministration`` resources using ``win_psmodule``:" -msgstr "以下は、``win_psmodule`` を使用して ``xWebAdministration`` リソースをインストールする例です。" - -#: ../../rst/os_guide/windows_dsc.rst:363 -msgid "Once installed, the win_dsc module will be able to use the resource by referencing it with the ``resource_name`` option." -msgstr "インストールすると、win_dsc モジュールは、``resource_name`` オプションでリソースを参照することで、リソースを使用できるようになります。" - -#: ../../rst/os_guide/windows_dsc.rst:366 -msgid "The first two methods above only work when the host has access to the internet. When a host does not have internet access, the module must first be installed using the methods above on another host with internet access and then copied across. To save a module to a local filepath, the following PowerShell cmdlet can be run:" -msgstr "上記の最初の 2 つの方法は、ホストがインターネットにアクセスできる場合にのみ機能します。ホストがインターネットにアクセスできない場合は、まずインターネットにアクセスできる別のホスト上で上記の方法を使用してモジュールをインストールし、それをコピーする必要があります。モジュールをローカルのファイルパスに保存するには、次の PowerShell コマンドレットを実行します。" - -#: ../../rst/os_guide/windows_dsc.rst:376 -msgid "This will create a folder called ``xWebAdministration`` in ``C:\\temp``, which can be copied to any host. For PowerShell to see this offline resource, it must be copied to a directory set in the ``PSModulePath`` environment variable. In most cases, the path ``C:\\Program Files\\WindowsPowerShell\\Module`` is set through this variable, but the ``win_path`` module can be used to add different paths." -msgstr "これにより、``C:\\temp`` の中に``xWebAdministration`` フォルダーが作成され、このフィルダーはどのホストにもコピーできるようになります。PowerShell がこのオフラインリソースを見るためには、環境変数 ``PSModulePath`` で設定されたディレクトリーにコピーされている必要があります。ほとんどの場合は、この変数を通じてパス ``C:\\Program Files\\WindowsPowerShell\\Module`` が設定されますが、``win_path`` モジュールを使用して異なるパスを追加することができます。" - -#: ../../rst/os_guide/windows_dsc.rst:384 -msgid "Examples" -msgstr "例" - -#: ../../rst/os_guide/windows_dsc.rst:386 -msgid "Extract a zip file" -msgstr "zip ファイルの展開" - -#: ../../rst/os_guide/windows_dsc.rst:398 -msgid "Create a directory" -msgstr "ディレクトリーの作成" - -#: ../../rst/os_guide/windows_dsc.rst:421 -msgid "Interact with Azure" -msgstr "Azure の操作" - -#: ../../rst/os_guide/windows_dsc.rst:444 -msgid "Setup IIS Website" -msgstr "IIS Web サイトのセットアップ" - -#: ../../rst/os_guide/windows_dsc.rst:499 -#: ../../rst/os_guide/windows_usage.rst:510 -#: ../../rst/os_guide/windows_winrm.rst:1004 -msgid ":ref:`playbooks_intro`" -msgstr ":ref:`playbooks_intro`" - -#: ../../rst/os_guide/windows_dsc.rst:500 -#: ../../rst/os_guide/windows_faq.rst:251 -#: ../../rst/os_guide/windows_setup.rst:491 -#: ../../rst/os_guide/windows_usage.rst:511 -#: ../../rst/os_guide/windows_winrm.rst:1005 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/os_guide/windows_dsc.rst:501 -#: ../../rst/os_guide/windows_faq.rst:252 -#: ../../rst/os_guide/windows_setup.rst:492 -#: ../../rst/os_guide/windows_usage.rst:512 -#: ../../rst/os_guide/windows_winrm.rst:1006 -msgid ":ref:`playbooks_best_practices`" -msgstr ":ref:`playbooks_best_practices`" - -#: ../../rst/os_guide/windows_dsc.rst:502 -#: ../../rst/os_guide/windows_faq.rst:253 -#: ../../rst/os_guide/windows_setup.rst:493 -#: ../../rst/os_guide/windows_usage.rst:513 -#: ../../rst/os_guide/windows_winrm.rst:1007 -msgid "Tips and tricks for playbooks" -msgstr "Playbook のヒントと裏技" - -#: ../../rst/os_guide/windows_dsc.rst:503 -#: ../../rst/os_guide/windows_setup.rst:494 -#: ../../rst/os_guide/windows_usage.rst:514 -#: ../../rst/os_guide/windows_winrm.rst:1008 -msgid ":ref:`List of Windows Modules `" -msgstr ":ref:`List of Windows Modules `" - -#: ../../rst/os_guide/windows_dsc.rst:504 -#: ../../rst/os_guide/windows_setup.rst:495 -#: ../../rst/os_guide/windows_usage.rst:515 -#: ../../rst/os_guide/windows_winrm.rst:1009 -msgid "Windows specific module list, all implemented in PowerShell" -msgstr "Windows 固有のモジュールリスト (すべて PowerShell に実装)" - -#: ../../rst/os_guide/windows_dsc.rst:505 -#: ../../rst/os_guide/windows_faq.rst:254 -#: ../../rst/os_guide/windows_setup.rst:496 -#: ../../rst/os_guide/windows_usage.rst:516 -#: ../../rst/os_guide/windows_winrm.rst:1010 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/os_guide/windows_dsc.rst:506 -#: ../../rst/os_guide/windows_faq.rst:255 -#: ../../rst/os_guide/windows_setup.rst:497 -#: ../../rst/os_guide/windows_usage.rst:517 -#: ../../rst/os_guide/windows_winrm.rst:1011 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/os_guide/windows_faq.rst:4 -msgid "Windows Frequently Asked Questions" -msgstr "Windows に関するよくある質問 (FAQ)" - -#: ../../rst/os_guide/windows_faq.rst:6 -msgid "Here are some commonly asked questions in regards to Ansible and Windows and their answers." -msgstr "ここでは、Ansible および Windows に関するよくある質問とその回答を紹介します。" - -#: ../../rst/os_guide/windows_faq.rst:9 -msgid "This document covers questions about managing Microsoft Windows servers with Ansible. For questions about Ansible Core, please see the :ref:`general FAQ page `." -msgstr "本ガイドでは、Ansible を使用した Microsoft Windows サーバーの管理に関する質問について説明します。Ansible Core に関する質問は、「:ref:`一般的な FAQ ページ `」を参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:14 -msgid "Does Ansible work with Windows XP or Server 2003?" -msgstr "Ansible は、Windows XP または Server 2003 で動作しますか" - -#: ../../rst/os_guide/windows_faq.rst:15 -msgid "Ansible does not work with Windows XP or Server 2003 hosts. Ansible does work with these Windows operating system versions:" -msgstr "Ansible は、Windows XP または Server 2003 ホストでは動作しません。Ansible は、以下の Windows オペレーティングシステムバージョンで動作します。" - -#: ../../rst/os_guide/windows_faq.rst:17 -msgid "Windows Server 2008 :sup:`1`" -msgstr "Windows Server 2008 :sup:`1`" - -#: ../../rst/os_guide/windows_faq.rst:18 -msgid "Windows Server 2008 R2 :sup:`1`" -msgstr "Windows Server 2008 R2 :sup:`1`" - -#: ../../rst/os_guide/windows_faq.rst:19 -msgid "Windows Server 2012" -msgstr "Windows Server 2012" - -#: ../../rst/os_guide/windows_faq.rst:20 -msgid "Windows Server 2012 R2" -msgstr "Windows Server 2012 R2" - -#: ../../rst/os_guide/windows_faq.rst:21 -msgid "Windows Server 2016" -msgstr "Windows Server 2016" - -#: ../../rst/os_guide/windows_faq.rst:22 -msgid "Windows Server 2019" -msgstr "Windows Server 2019" - -#: ../../rst/os_guide/windows_faq.rst:23 -msgid "Windows 7 :sup:`1`" -msgstr "Windows 7 :sup:`1`" - -#: ../../rst/os_guide/windows_faq.rst:24 -msgid "Windows 8.1" -msgstr "Windows 8.1" - -#: ../../rst/os_guide/windows_faq.rst:25 -msgid "Windows 10" -msgstr "Windows 10" - -#: ../../rst/os_guide/windows_faq.rst:27 -msgid "1 - See the :ref:`Server 2008 FAQ ` entry for more details." -msgstr "1 - 詳細は、:ref:`Server 2008 FAQ ` を参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:29 -msgid "Ansible also has minimum PowerShell version requirements - please see :ref:`windows_setup` for the latest information." -msgstr "また、Ansible には PowerShell の最小バージョン要件があります。最新情報は「:ref:`windows_setup`」を参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:35 -msgid "Are Server 2008, 2008 R2 and Windows 7 supported?" -msgstr "Server 2008、2008 R2、Windows 7 に対応していますか" - -#: ../../rst/os_guide/windows_faq.rst:36 -msgid "Microsoft ended Extended Support for these versions of Windows on January 14th, 2020, and Ansible deprecated official support in the 2.10 release. No new feature development will occur targeting these operating systems, and automated testing has ceased. However, existing modules and features will likely continue to work, and simple pull requests to resolve issues with these Windows versions may be accepted." -msgstr "Microsoft は 2020 年 1 月 14 日にこれらのバージョンの Windows の Extended Support を終了し、Ansible は 2.10 のリリースで公式サポートを終了しました。これらのオペレーティングシステムを対象とした新機能の開発は今後行われず、自動テストも終了しています。しかし、既存のモジュールや機能は引き続き動作する可能性があり、これらの Windows バージョンに関する問題を解決するための簡単なプル要求は承認される可能性があります。" - -#: ../../rst/os_guide/windows_faq.rst:39 -msgid "Can I manage Windows Nano Server with Ansible?" -msgstr "Ansible で Windows Nano Server を管理できますか" - -#: ../../rst/os_guide/windows_faq.rst:40 -msgid "Ansible does not currently work with Windows Nano Server, since it does not have access to the full .NET Framework that is used by the majority of the modules and internal components." -msgstr "Ansible は現在、Windows Nano Server では動作しません。これは、大部分のモジュールや内部コンポーネントで使用されている完全な .NET フレームワークにアクセスできないためです。" - -#: ../../rst/os_guide/windows_faq.rst:47 -msgid "Can Ansible run on Windows?" -msgstr "Ansible は Windows で実行できますか" - -#: ../../rst/os_guide/windows_faq.rst:48 -msgid "No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL)." -msgstr "いいえ、Ansible は Windows ホストのみを管理できます。Ansible は Windows ホスト上ではネイティブに実行できませんが、Windows Subsystem for Linux (WSL) の下で実行できます。" - -#: ../../rst/os_guide/windows_faq.rst:51 -msgid "The Windows Subsystem for Linux is not supported by Ansible and should not be used for production systems." -msgstr "Windows Subsystem for Linux は Ansible ではサポートされていないため、実稼働システムには使用しないでください。" - -#: ../../rst/os_guide/windows_faq.rst:54 -msgid "To install Ansible on WSL, the following commands can be run in the bash terminal:" -msgstr "WSL に Ansible をインストールするには、bash ターミナルで以下のコマンドを実行します。" - -#: ../../rst/os_guide/windows_faq.rst:63 -msgid "To run Ansible from source instead of a release on the WSL, simply uninstall the pip installed version and then clone the git repo." -msgstr "WSL のリリースではなくソースから Ansible を実行するには、インストールした pip をアンインストールし、git リポジトリーのクローンを作成します。" - -#: ../../rst/os_guide/windows_faq.rst:75 -msgid "If you encounter timeout errors when running Ansible on the WSL, this may be due to an issue with ``sleep`` not returning correctly. The following workaround may resolve the issue:" -msgstr "WSL 上で Ansible を実行したときにタイムアウトエラーが発生する場合は、``sleep`` が正しく返されない問題が原因となっている可能性があります。以下の回避策により、この問題が解決される場合があります。" - -#: ../../rst/os_guide/windows_faq.rst:83 -msgid "Another option is to use WSL 2 if running Windows 10 later than build 2004." -msgstr "別のオプションとして、ビルド 2004 よりも Windows 10 以上を実行している場合は WSL 2 を使用します。" - -#: ../../rst/os_guide/windows_faq.rst:91 -msgid "Can I use SSH keys to authenticate to Windows hosts?" -msgstr "SSH キーを使用して Windows ホストへの認証を行うことはできますか" - -#: ../../rst/os_guide/windows_faq.rst:92 -msgid "You cannot use SSH keys with the WinRM or PSRP connection plugins. These connection plugins use X509 certificates for authentication instead of the SSH key pairs that SSH uses." -msgstr "WinRM または PSRP connection プラグインで SSH 鍵を使用することはできません。これらの connection プラグインは、認証に SSH が使用する SSH キーペアを使用する代わりに、X509 証明書を使用します。" - -#: ../../rst/os_guide/windows_faq.rst:96 -msgid "The way X509 certificates are generated and mapped to a user is different from the SSH implementation; consult the :ref:`windows_winrm` documentation for more information." -msgstr "X509 証明書が生成され、ユーザーにマッピングされる方法は、SSH の実装とは異なります。詳細は、:ref:`windows_winrm` のドキュメントを参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:100 -msgid "Ansible 2.8 has added an experimental option to use the SSH connection plugin, which uses SSH keys for authentication, for Windows servers. See :ref:`this question ` for more information." -msgstr "Ansible 2.8 には、認証に SSH 鍵を使用する SSH connection プラグインを Windows サーバーで使用する実験的なオプションが追加されました。詳細は「:ref:`this question `」を参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:107 -msgid "Why can I run a command locally that does not work under Ansible?" -msgstr "Ansible で機能しないコマンドをローカルで実行できるのはなぜですか" - -#: ../../rst/os_guide/windows_faq.rst:108 -msgid "Ansible executes commands through WinRM. These processes are different from running a command locally in these ways:" -msgstr "Ansible は、WinRM を介してコマンドを実行します。これらのプロセスは、以下の方法でローカルでコマンドを実行するのとは異なります。" - -#: ../../rst/os_guide/windows_faq.rst:111 -msgid "Unless using an authentication option like CredSSP or Kerberos with credential delegation, the WinRM process does not have the ability to delegate the user's credentials to a network resource, causing ``Access is Denied`` errors." -msgstr "CredSSP や Kerberos のような認証オプションを使用して、認証情報の委譲を行っていない限り、WinRM プロセスにはユーザーの認証情報をネットワークリソースに委譲する機能がなく、``Access is Denied`` エラーが発生します。" - -#: ../../rst/os_guide/windows_faq.rst:116 -msgid "All processes run under WinRM are in a non-interactive session. Applications that require an interactive session will not work." -msgstr "WinRM で実行されるすべてのプロセスは、非対話型セッションです。対話型セッションを必要とするアプリケーションは機能しません。" - -#: ../../rst/os_guide/windows_faq.rst:119 -msgid "When running through WinRM, Windows restricts access to internal Windows APIs like the Windows Update API and DPAPI, which some installers and programs rely on." -msgstr "WinRM を介して実行する場合、Windows は、一部のインストーラーやプログラムが依存している Windows Update API や DPAPI などの Windows 内部 API へのアクセスを制限します。" - -#: ../../rst/os_guide/windows_faq.rst:123 -msgid "Some ways to bypass these restrictions are to:" -msgstr "これらの制限を回避する方法は次のとおりです。" - -#: ../../rst/os_guide/windows_faq.rst:125 -msgid "Use ``become``, which runs a command as it would when run locally. This will bypass most WinRM restrictions, as Windows is unaware the process is running under WinRM when ``become`` is used. See the :ref:`become` documentation for more information." -msgstr "``become`` を使用すると、ローカルで実行するときと同じようにコマンドを実行できます。``become`` を使用すると、Windows はプロセスが WinRM の下で実行していることに気づかないため、ほとんどの WinRM の制限を回避することができます。詳細は、:ref:`become` のドキュメントを参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:130 -msgid "Use a scheduled task, which can be created with ``win_scheduled_task``. Like ``become``, it will bypass all WinRM restrictions, but it can only be used to run commands, not modules." -msgstr "``win_scheduled_task`` で作成できる、スケジュールされたタスクを使用します。``become`` と同様に、WinRM の制限をすべて回避できますが、モジュールではなくコマンドの実行にのみ使用できます。" - -#: ../../rst/os_guide/windows_faq.rst:134 -msgid "Use ``win_psexec`` to run a command on the host. PSExec does not use WinRM and so will bypass any of the restrictions." -msgstr "``win_psexec`` を使用してホストでコマンドを実行します。PSExec は WinRM を使用しないため、あらゆる制限を回避することができます。" - -#: ../../rst/os_guide/windows_faq.rst:137 -msgid "To access network resources without any of these workarounds, you can use CredSSP or Kerberos with credential delegation enabled." -msgstr "これらの回避策を取らずにネットワークリソースにアクセスするには、認証情報の委譲を有効にした CredSSP または Kerberos を使用することができます。" - -#: ../../rst/os_guide/windows_faq.rst:140 -msgid "See :ref:`become` more info on how to use become. The limitations section at :ref:`windows_winrm` has more details around WinRM limitations." -msgstr "become の使用方法に関する詳細は、「:ref:`become`」を参照してください。:ref:`windows_winrm` の制限のセクションには、WinRM 制限の詳細が記載されています。" - -#: ../../rst/os_guide/windows_faq.rst:144 -msgid "This program won't install on Windows with Ansible" -msgstr "このプログラムが、Ansible がインストールされている Windows にはインストールされません" - -#: ../../rst/os_guide/windows_faq.rst:145 -msgid "See :ref:`this question ` for more information about WinRM limitations." -msgstr "WinRMの制限の詳細は、「:ref:`こちらの質問 `」を参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:148 -msgid "What Windows modules are available?" -msgstr "どのような Windows モジュールが利用できますか" - -#: ../../rst/os_guide/windows_faq.rst:149 -msgid "Most of the Ansible modules in Ansible Core are written for a combination of Linux/Unix machines and arbitrary web services. These modules are written in Python and most of them do not work on Windows." -msgstr "Ansible Core の Ansible モジュールの多くは、Linux/Unix マシンと任意の Web サービスの組み合わせを想定して記述されます。これらのモジュールは Python で記述されており、そのほとんどが Windows では動作しません。" - -#: ../../rst/os_guide/windows_faq.rst:153 -msgid "Because of this, there are dedicated Windows modules that are written in PowerShell and are meant to be run on Windows hosts. A list of these modules can be found :ref:`here `." -msgstr "このため、PowerShell で記述されており、Windows ホストで実行することを目的としている専用の Windows モジュールがあります。これらのモジュールの一覧は、「:ref:`here `」にあります。" - -#: ../../rst/os_guide/windows_faq.rst:157 -msgid "In addition, the following Ansible Core modules/action-plugins work with Windows:" -msgstr "次の Ansible Core モジュールおよびアクションプラグインは、Windows で動作します。" - -#: ../../rst/os_guide/windows_faq.rst:159 -msgid "add_host" -msgstr "add_host" - -#: ../../rst/os_guide/windows_faq.rst:160 -msgid "assert" -msgstr "assert" - -#: ../../rst/os_guide/windows_faq.rst:161 -msgid "async_status" -msgstr "async_status" - -#: ../../rst/os_guide/windows_faq.rst:162 -msgid "debug" -msgstr "debug" - -#: ../../rst/os_guide/windows_faq.rst:163 -msgid "fail" -msgstr "fail" - -#: ../../rst/os_guide/windows_faq.rst:164 -msgid "fetch" -msgstr "fetch" - -#: ../../rst/os_guide/windows_faq.rst:165 -msgid "group_by" -msgstr "group_by" - -#: ../../rst/os_guide/windows_faq.rst:166 -msgid "include" -msgstr "include" - -#: ../../rst/os_guide/windows_faq.rst:167 -msgid "include_role" -msgstr "include_role" - -#: ../../rst/os_guide/windows_faq.rst:168 -msgid "include_vars" -msgstr "include_vars" - -#: ../../rst/os_guide/windows_faq.rst:169 -msgid "meta" -msgstr "meta" - -#: ../../rst/os_guide/windows_faq.rst:170 -msgid "pause" -msgstr "pause" - -#: ../../rst/os_guide/windows_faq.rst:171 -msgid "raw" -msgstr "raw" - -#: ../../rst/os_guide/windows_faq.rst:172 -msgid "script" -msgstr "script" - -#: ../../rst/os_guide/windows_faq.rst:173 -msgid "set_fact" -msgstr "set_fact" - -#: ../../rst/os_guide/windows_faq.rst:174 -msgid "set_stats" -msgstr "set_stats" - -#: ../../rst/os_guide/windows_faq.rst:175 -msgid "setup" -msgstr "setup" - -#: ../../rst/os_guide/windows_faq.rst:176 -msgid "slurp" -msgstr "slurp" - -#: ../../rst/os_guide/windows_faq.rst:177 -msgid "template (also: win_template)" -msgstr "template (win_template も同様)" - -#: ../../rst/os_guide/windows_faq.rst:178 -msgid "wait_for_connection" -msgstr "wait_for_connection" - -#: ../../rst/os_guide/windows_faq.rst:180 -msgid "Ansible Windows modules exist in the :ref:`plugins_in_ansible.windows`, :ref:`plugins_in_community.windows`, and :ref:`plugins_in_chocolatey.chocolatey` collections." -msgstr "Ansible Windows モジュールは、:ref:`plugins_in_ansible.windows`、:ref:`plugins_in_community.windows`、および :ref:`plugins_in_chocolatey.chocolatey` コレクションに存在します。" - -#: ../../rst/os_guide/windows_faq.rst:183 -msgid "Can I run Python modules on Windows hosts?" -msgstr "Windows ホストで Python モジュールを実行できますか" - -#: ../../rst/os_guide/windows_faq.rst:184 -msgid "No, the WinRM connection protocol is set to use PowerShell modules, so Python modules will not work. A way to bypass this issue to use ``delegate_to: localhost`` to run a Python module on the Ansible controller. This is useful if during a playbook, an external service needs to be contacted and there is no equivalent Windows module available." -msgstr "できません。WinRM 接続プロトコルは PowerShell モジュールを使用するように設定されているため、Python モジュールは動作しません。この問題を回避するには、``delegate_to: localhost`` を使用して Ansible コントローラー上で Python モジュールを実行する方法があります。これは、Playbook 中に外部サービスに接続する必要があり、同等の Windows モジュールがない場合に便利です。" - -#: ../../rst/os_guide/windows_faq.rst:193 -msgid "Can I connect to Windows hosts over SSH?" -msgstr "SSH 経由で Windows ホストに接続できますか" - -#: ../../rst/os_guide/windows_faq.rst:194 -msgid "Ansible 2.8 has added an experimental option to use the SSH connection plugin to manage Windows hosts. To connect to Windows hosts over SSH, you must install and configure the `Win32-OpenSSH `_ fork that is in development with Microsoft on the Windows host(s). While most of the basics should work with SSH, ``Win32-OpenSSH`` is rapidly changing, with new features added and bugs fixed in every release. It is highly recommend you `install `_ the latest release of ``Win32-OpenSSH`` from the GitHub Releases page when using it with Ansible on Windows hosts." -msgstr "Ansible 2.8 には、SSH connection プラグインを使用して Windows ホストを管理する実験的なオプションが追加されました。Windows ホストに SSH 接続するには、Microsoft と共同で開発中の `Win32-OpenSSH `_ フォークを Windows ホストにインストールして設定する必要があります。基本的な機能のほとんどは SSH で動作するはずですが、``Win32-OpenSSH`` はリリースごとに新機能が追加されたり、バグが修正されたりと、急速に変化しています。Windows ホストで Ansible を使用する際には、GitHub Releases ページから ``Win32-OpenSSH`` の最新リリースを `インストール `_ することが強く推奨されます。" - -#: ../../rst/os_guide/windows_faq.rst:203 -msgid "To use SSH as the connection to a Windows host, set the following variables in the inventory:" -msgstr "Windows ホストへの接続に SSH を使用するには、インベントリーに以下の変数を設定します。" - -#: ../../rst/os_guide/windows_faq.rst:214 -msgid "The value for ``ansible_shell_type`` should either be ``cmd`` or ``powershell``. Use ``cmd`` if the ``DefaultShell`` has not been configured on the SSH service and ``powershell`` if that has been set as the ``DefaultShell``." -msgstr "``ansible_shell_type`` の値は、``cmd`` または ``powershell`` のいずれかでなければなりません。SSH サービスで ``DefaultShell`` が設定されていない場合は ``cmd`` を使用して、``DefaultShell`` として設定されている場合は ``powershell`` を使用してください。" - -#: ../../rst/os_guide/windows_faq.rst:219 -msgid "Why is connecting to a Windows host through SSH failing?" -msgstr "SSH を介した Windows ホストへの接続に失敗するのはなぜですか?" - -#: ../../rst/os_guide/windows_faq.rst:220 -msgid "Unless you are using ``Win32-OpenSSH`` as described above, you must connect to Windows hosts using :ref:`windows_winrm`. If your Ansible output indicates that SSH was used, either you did not set the connection vars properly or the host is not inheriting them correctly." -msgstr "上記のように ``Win32-OpenSSH`` を使用している場合を除き、Windows ホストへの接続には :ref:`windows_winrm` を使用する必要があります。Ansible の出力で SSH が使用されたと表示された場合は、接続バーが正しく設定されていないか、ホストに正しく継承されていません。" - -#: ../../rst/os_guide/windows_faq.rst:224 -msgid "Make sure ``ansible_connection: winrm`` is set in the inventory for the Windows host(s)." -msgstr "Windows ホストのインベントリーに ``ansible_connection: winrm`` が設定されていることを確認してください。" - -#: ../../rst/os_guide/windows_faq.rst:228 -msgid "Why are my credentials being rejected?" -msgstr "認証情報が拒否されるのはなぜですか" - -#: ../../rst/os_guide/windows_faq.rst:229 -msgid "This can be due to a myriad of reasons unrelated to incorrect credentials." -msgstr "これは、誤った認証情報とは無関係の、多種多様なものが原因である可能性があります。" - -#: ../../rst/os_guide/windows_faq.rst:231 -msgid "See HTTP 401/Credentials Rejected at :ref:`windows_setup` for a more detailed guide of this could mean." -msgstr "この現象の詳細については、:ref:`windows_setup` の「HTTP 401/認証情報の拒否」を参照してください。" - -#: ../../rst/os_guide/windows_faq.rst:235 -msgid "Why am I getting an error SSL CERTIFICATE_VERIFY_FAILED?" -msgstr "SSL CERTIFICATE_VERIFY_FAILED エラーが発生するのはなぜですか" - -#: ../../rst/os_guide/windows_faq.rst:236 -msgid "When the Ansible controller is running on Python 2.7.9+ or an older version of Python that has backported SSLContext (like Python 2.7.5 on RHEL 7), the controller will attempt to validate the certificate WinRM is using for an HTTPS connection. If the certificate cannot be validated (such as in the case of a self signed cert), it will fail the verification process." -msgstr "Ansible コントローラーが Python 2.7.9 以降または SSLContext をバックポートした古いバージョンの Python (RHEL 7 の Python 2.7.5 など) で動作している場合、コントローラーは WinRM が HTTPS 接続に使用している証明書を検証しようとします。証明書を検証できない場合 (自己署名証明書の場合など) は、検証プロセスに失敗します。" - -#: ../../rst/os_guide/windows_faq.rst:242 -msgid "To ignore certificate validation, add ``ansible_winrm_server_cert_validation: ignore`` to inventory for the Windows host." -msgstr "証明書の検証を無視するには、Windows ホストのインベントリーに ``ansible_winrm_server_cert_validation: ignore`` を追加してください。" - -#: ../../rst/os_guide/windows_faq.rst:248 -msgid ":ref:`windows`" -msgstr ":ref:`windows`" - -#: ../../rst/os_guide/windows_faq.rst:249 -msgid "The Windows documentation index" -msgstr "Windows ドキュメントの目次" - -#: ../../rst/os_guide/windows_faq.rst:250 -#: ../../rst/os_guide/windows_setup.rst:490 -msgid ":ref:`about_playbooks`" -msgstr ":ref:`about_playbooks`" - -#: ../../rst/os_guide/windows_performance.rst:4 -msgid "Windows performance" -msgstr "Windows パフォーマンス" - -#: ../../rst/os_guide/windows_performance.rst:5 -msgid "This document offers some performance optimizations you might like to apply to your Windows hosts to speed them up specifically in the context of using Ansible with them, and generally." -msgstr "本書では、特に Ansible をそのホストで使用するような状況、および一般的に使用する状況で高速化するために、Windows ホストに適用するパフォーマンスの最適化をいくつか説明します。" - -#: ../../rst/os_guide/windows_performance.rst:10 -msgid "Optimize PowerShell performance to reduce Ansible task overhead" -msgstr "Ansible タスクのオーバーヘッドを軽減するための PowerShell のパフォーマンスの最適化" - -#: ../../rst/os_guide/windows_performance.rst:11 -msgid "To speed up the startup of PowerShell by around 10x, run the following PowerShell snippet in an Administrator session. Expect it to take tens of seconds." -msgstr "PowerShell の起動を約 10 倍高速化するには、Administrator セッションで以下の PowerShell スニペットを実行します。数十秒かかることが予想されます。" - -#: ../../rst/os_guide/windows_performance.rst:17 -msgid "If native images have already been created by the ngen task or service, you will observe no difference in performance (but this snippet will at that point execute faster than otherwise)." -msgstr "ネイティブイメージが ngen タスクやサービスによってすでに作成されている場合は、パフォーマンスに違いはありません (ただし、このスニペットはその時点で他の場合よりも高速に実行されます)。" - -#: ../../rst/os_guide/windows_performance.rst:42 -msgid "PowerShell is used by every Windows Ansible module. This optimization reduces the time PowerShell takes to start up, removing that overhead from every invocation." -msgstr "PowerShell はすべての Windows Ansible モジュールによって使用されます。この最適化により、PowerShell の起動時間を短縮し、呼び出しごとにそのオーバーヘッドを取り除きます。" - -#: ../../rst/os_guide/windows_performance.rst:45 -msgid "This snippet uses `the native image generator, ngen `_ to pre-emptively create native images for the assemblies that PowerShell relies on." -msgstr "このスニペットは `ネイティブイメージジェネレーター ngen `_ を使用して、PowerShell が依存しているアセンブリーのネイティブイメージを事前に作成します。" - -#: ../../rst/os_guide/windows_performance.rst:49 -msgid "Fix high-CPU-on-boot for VMs/cloud instances" -msgstr "仮想マシン/クラウドインスタンスの、システム起動時の高 CPU を修正" - -#: ../../rst/os_guide/windows_performance.rst:50 -msgid "If you are creating golden images to spawn instances from, you can avoid a disruptive high CPU task near startup through `processing the ngen queue `_ within your golden image creation, if you know the CPU types won't change between golden image build process and runtime." -msgstr "インスタンスを生成するためにゴールデンイメージを作成している場合は、ゴールデンイメージのビルドプロセスとランタイムの間で CPU タイプが変わらないことがわかっていれば、作成したゴールデンイメージ内で `processing the ngen queue `_ を介して、起動時に破壊的な CPU 使用率の高いタスクを回避することができます。" - -#: ../../rst/os_guide/windows_performance.rst:55 -msgid "Place the following near the end of your playbook, bearing in mind the factors that can cause native images to be invalidated (`see MSDN `_)." -msgstr "Playbook の最後付近に以下を置き、ネイティブイメージが無効になる可能性のある要素に注意してください (`MSDN `_ を参照)。" - -#: ../../rst/os_guide/windows_setup.rst:4 -msgid "Setting up a Windows Host" -msgstr "Windows ホストのセットアップ" - -#: ../../rst/os_guide/windows_setup.rst:5 -msgid "This document discusses the setup that is required before Ansible can communicate with a Microsoft Windows host." -msgstr "本書では、Ansible が Microsoft Windows ホストと通信する前に必要なセットアップを説明します。" - -#: ../../rst/os_guide/windows_setup.rst:12 -msgid "For Ansible to communicate to a Windows host and use Windows modules, the Windows host must meet these base requirements for connectivity:" -msgstr "Ansible が Windows ホストと通信し、Windows モジュールを使用するためには、Windows ホストが以下の接続性に関する基本要件を満たす必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:15 -msgid "With Ansible you can generally manage Windows versions under the current and extended support from Microsoft. You can also manage desktop OSs including Windows 8.1, and 10, and server OSs including Windows Server 2012, 2012 R2, 2016, 2019, and 2022." -msgstr "Ansible は、Microsoft の現行および拡張サポート下にある Windows バージョンを一般的に管理できます。また、Windows 8.1および 10 を含むデスクトップ OS、ならびに Windows Server 2012、2012 R2、2016、2019、および 2022 を含むサーバー OS を管理できます。" - -#: ../../rst/os_guide/windows_setup.rst:17 -msgid "You need to install PowerShell 3.0 or newer and at least .NET 4.0 on the Windows host." -msgstr "Windows ホストに PowerShell 3.0 以降と少なくとも .NET 4.0 がインストールされている必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:19 -msgid "You need to create and activate a WinRM listener. More details, see `WinRM Setup `_." -msgstr "WinRM リスナーを作成してアクティブにする必要があります。詳細は、`WinRM Setup `_ を参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:21 -msgid "Some Ansible modules have additional requirements, such as a newer OS or PowerShell version. Consult the module documentation page to determine whether a host meets those requirements." -msgstr "Ansible モジュールの中には、新しい OS や PowerShell のバージョンなど、追加の要件があるものもあります。ホストがこれらの要件を満たしているかどうかは、モジュールのドキュメントページを参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:24 -msgid "Upgrading PowerShell and .NET Framework" -msgstr "PowerShell および .NET Framework のアップグレード" - -#: ../../rst/os_guide/windows_setup.rst:25 -msgid "Ansible requires PowerShell version 3.0 and .NET Framework 4.0 or newer to function on older operating systems like Server 2008 and Windows 7. The base image does not meet this requirement. You can use the `Upgrade-PowerShell.ps1 `_ script to update these." -msgstr "Ansible が Server 2008 や Windows 7 などの古いオペレーティングシステムで機能するためには、PowerShell の バージョン3.0 と .NET Framework 4.0 以降が必要です。ベースイメージは、この要件を満たしていません。`Upgrade-PowerShell.ps1 `_ スクリプトを使用してこれらを更新することができます。" - -#: ../../rst/os_guide/windows_setup.rst:28 -msgid "This is an example of how to run this script from PowerShell:" -msgstr "このスクリプトを PowerShell から実行する例を以下に示します。" - -#: ../../rst/os_guide/windows_setup.rst:43 -msgid "In the script, the ``file`` value can be the PowerShell version 3.0, 4.0, or 5.1." -msgstr "このスクリプトでは、``file`` の値は PowerShell バージョン 3.0、4.0、または 5.1 に指定できます。" - -#: ../../rst/os_guide/windows_setup.rst:45 -msgid "Once completed, you need to run the following PowerShell commands:" -msgstr "完了したら、以下の PowerShell コマンドを実行する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:47 -msgid "As an optional but good security practice, you can set the execution policy back to the default." -msgstr "こちらは任意ですが、実行ポリシーをデフォルトに戻すことがセキュリティープラクティスとして適切です。" - -#: ../../rst/os_guide/windows_setup.rst:53 -msgid "Use the ``RemoteSigned`` value for Windows servers, or ``Restricted`` for Windows clients." -msgstr "Windows サーバーには ``RemoteSigned`` の値を使用し、Windows クライアントには ``Restricted`` を使用します。" - -#: ../../rst/os_guide/windows_setup.rst:55 -msgid "Remove the auto logon." -msgstr "自動ログオンを削除します。" - -#: ../../rst/os_guide/windows_setup.rst:64 -msgid "The script determines what programs you need to install (such as .NET Framework 4.5.2) and what PowerShell version needs to be present. If a reboot is needed and the ``username`` and ``password`` parameters are set, the script will automatically reboot the machine and then logon. If the ``username`` and ``password`` parameters are not set, the script will prompt the user to manually reboot and logon when required. When the user is next logged in, the script will continue where it left off and the process continues until no more actions are required." -msgstr "このスクリプトは、インストールが必要なプログラム (.NET Framework 4.5.2 など) や、必要な PowerShell バージョンを確認して動作します。再起動が必要で、``username`` パラメーターと ``password`` パラメーターが設定されている場合は、スクリプトが自動的に再起動し、再起動から復帰したときにログオンします。``username`` パラメーターおよび ``password`` パラメーターが設定されていない場合には、スクリプトは必要に応じてユーザーに手動で再起動とログオンを促します。ユーザーが次にログインすると、スクリプトは前回の続きを実行し、アクションが必要なくなるまで処理を続けます。" - -#: ../../rst/os_guide/windows_setup.rst:67 -msgid "If you run the script on Server 2008, then you need to install SP2. For Server 2008 R2 or Windows 7 you need SP1." -msgstr "Server 2008 でスクリプトを実行する場合は、SP2 をインストールする必要があります。Server 2008 R2 または Windows 7 の場合は SP1 が必要です。" - -#: ../../rst/os_guide/windows_setup.rst:69 -msgid "On Windows Server 2008 you can install only PowerShell 3.0. A newer version will result in the script failure." -msgstr "Windows Server 2008 では PowerShell 3.0 しかインストールできないため、それより新しいバージョンを指定するとスクリプトが失敗します。" - -#: ../../rst/os_guide/windows_setup.rst:71 -msgid "The ``username`` and ``password`` parameters are stored in plain text in the registry. Run the cleanup commands after the script finishes to ensure no credentials are stored on the host." -msgstr "``username`` と ``password`` のパラメーターは、レジストリーに平文で保存されます。スクリプトの終了後にクリーンアップコマンドを実行して、ホスト上に認証情報が保存されていないことを確認してください。" - -#: ../../rst/os_guide/windows_setup.rst:75 -msgid "WinRM Memory Hotfix" -msgstr "WinRM Memory Hotfix" - -#: ../../rst/os_guide/windows_setup.rst:76 -msgid "On PowerShell v3.0, there is a bug that limits the amount of memory available to the WinRM service. Use the `Install-WMF3Hotfix.ps1 `_ script to install a hotfix on affected hosts as part of the system bootstrapping or imaging process. Without this hotfix, Ansible fails to execute certain commands on the Windows host." -msgstr "PowerShell v3.0 で実行する場合は、WinRM サービスのバグにより、WinRM で使用できるメモリー量が制限されるという問題がありました。`Install-WMF3Hotfix.ps1 `_ というスクリプトを使用すると、システムのブートストラップまたはイメージプロセスの一部として、影響を受けるホストに hotfix をインストールできます。この hotfix がない場合には、Ansible では Windows ホスト上で特定のコマンドの実行に失敗します。" - -#: ../../rst/os_guide/windows_setup.rst:78 -msgid "To install the hotfix:" -msgstr "ホットフィックスをインストールします。" - -#: ../../rst/os_guide/windows_setup.rst:89 -msgid "For more details, refer to the `\"Out of memory\" error on a computer that has a customized MaxMemoryPerShellMB quota set and has WMF 3.0 installed `_ article." -msgstr "詳細は、`\"Out of memory\" error on a computer that has a customized MaxMemoryPerShellMB quota set and has WMF 3.0 installed `_ アーティクルを参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:92 -msgid "WinRM Setup" -msgstr "WinRM の設定" - -#: ../../rst/os_guide/windows_setup.rst:93 -msgid "You need to configure the WinRM service so that Ansible can connect to it. There are two main components of the WinRM service that governs how Ansible can interface with the Windows host: the ``listener`` and the ``service`` configuration settings." -msgstr "WinRM サービスを設定して Ansible が接続できるようにします。WinRM サービスには、構成設定 ``listener`` および ``service`` の 2 つの主要コンポーネントがあり、Ansible が Windows ホストとどのように連携するかを決定します。" - -#: ../../rst/os_guide/windows_setup.rst:96 -msgid "WinRM Listener" -msgstr "WinRM リスナー" - -#: ../../rst/os_guide/windows_setup.rst:97 -msgid "The WinRM services listen for requests on one or more ports. Each of these ports must have a listener created and configured." -msgstr "WinRM サービスは、1 つ以上のポートで要求をリッスンします。これらのポートごとにリスナーを作成し、設定する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:99 -msgid "To view the current listeners that are running on the WinRM service:" -msgstr "WinRM サービスで実行している現在のリスナーを表示します。" - -#: ../../rst/os_guide/windows_setup.rst:105 -#: ../../rst/os_guide/windows_setup.rst:200 -msgid "This will output something like:" -msgstr "これにより、以下のようなものが出力されます。" - -#: ../../rst/os_guide/windows_setup.rst:131 -msgid "In the example above there are two listeners activated. One is listening on port 5985 over HTTP and the other is listening on port 5986 over HTTPS. Some of the key options that are useful to understand are:" -msgstr "上の例では、2 つのリスナーが有効になっています。1 つは HTTP でポート 5985 をリッスンしており、もう 1 つは HTTPS でポート 5986 をリッスンしています。理解しておくと便利なオプションをいくつか紹介します。" - -#: ../../rst/os_guide/windows_setup.rst:133 -msgid "``Transport``: Whether the listener is run over HTTP or HTTPS. We recommend you use a listener over HTTPS because the data is encrypted without any further changes required." -msgstr "``Transport``: リスナーが HTTP または HTTPS のどちらで実行している場合でも、データはさらなる変更なしに暗号化されるため、HTTPS 経由でリスナーを使用することが推奨されます。" - -#: ../../rst/os_guide/windows_setup.rst:135 -msgid "``Port``: The port the listener runs on. By default it is ``5985`` for HTTP and ``5986`` for HTTPS. This port can be changed to whatever is required and corresponds to the host var ``ansible_port``." -msgstr "``Port``: リスナーが実行するポート。デフォルトは、HTTP の場合は ``5985``、HTTPS の場合は ``5986`` です。このポートは、必要なものにそれぞれ変更でき、ホスト変数 ``ansible_port`` に対応することができます。" - -#: ../../rst/os_guide/windows_setup.rst:137 -msgid "``URLPrefix``: The URL prefix to listen on. By default it is ``wsman``. If you change this option, you need to set the host var ``ansible_winrm_path`` to the same value." -msgstr "``URLPrefix``: リッスンする URL プレフィックス。デフォルトは ``wsman`` です。このオプションが変更された場合、ホスト変数 ``ansible_winrm_path`` は同じ値に設定する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:139 -msgid "``CertificateThumbprint``: If you use an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell:" -msgstr "``CertificateThumbprint``: HTTPS リスナーを使用する場合、これは接続に使用される Windows 証明書ストアの証明書のサムプリントです。証明書自体の詳細を取得するには、PowerShell で該当する証明書のサムプリントを指定して次のコマンドを実行します。" - -#: ../../rst/os_guide/windows_setup.rst:147 -msgid "Setup WinRM Listener" -msgstr "WinRM リスナーの設定" - -#: ../../rst/os_guide/windows_setup.rst:148 -msgid "There are three ways to set up a WinRM listener:" -msgstr "WinRM リスナーを設定するには、3 つの方法があります。" - -#: ../../rst/os_guide/windows_setup.rst:150 -msgid "Using ``winrm quickconfig`` for HTTP or ``winrm quickconfig -transport:https`` for HTTPS. This is the easiest option to use when running outside of a domain environment and a simple listener is required. Unlike the other options, this process also has the added benefit of opening up the firewall for the ports required and starts the WinRM service." -msgstr "HTTP には ``winrm quickconfig`` を、HTTPS には ``winrm quickconfig -transport:https`` を使用します。これは、ドメイン環境外で動作し、シンプルなリスナーが必要な場合に、最も簡単に使用できるオプションです。他のオプションとは異なり、このプロセスには、必要なポートのためにファイアウォールを開き、WinRM サービスを開始するという利点があります。" - -#: ../../rst/os_guide/windows_setup.rst:152 -msgid "Using Group Policy Objects (GPO). This is the best way to create a listener when the host is a member of a domain because the configuration is done automatically without any user input. For more information on group policy objects, see the `Group Policy Objects documentation `_." -msgstr "グループポリシーオブジェクト (GPO) の使用。設定は、ユーザーが入力せずに自動的に行われるため、この方法は、ホストがドメインのメンバーである場合にリスナーを作成するのに最適な方法です。グループポリシーオブジェクトの詳細は、`Group Policy Objects documentation `_ を参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:154 -msgid "Using PowerShell to create a listener with a specific configuration. This can be done by running the following PowerShell commands:" -msgstr "PowerShell を使用して、特定の設定でリスナーを作成します。これは、以下の PowerShell コマンドを実行することで可能になります。" - -#: ../../rst/os_guide/windows_setup.rst:168 -msgid "To see the other options with this PowerShell command, refer to the `New-WSManInstance `_ documentation." -msgstr "この PowerShell コマンドの他のオプションを確認するには、`New-WSManInstance `_ ドキュメントを参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:171 -msgid "When creating an HTTPS listener, you must create and store a certificate in the ``LocalMachine\\My`` certificate store." -msgstr "HTTPS リスナーを作成するときは、``LocalMachine\\My`` 証明書ストアに証明書を作成して保存する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:174 -msgid "Delete WinRM Listener" -msgstr "WinRM リスナーの削除" - -#: ../../rst/os_guide/windows_setup.rst:175 -msgid "To remove all WinRM listeners:" -msgstr "WinRM リスナーを削除するには、以下を実行します。" - -#: ../../rst/os_guide/windows_setup.rst:181 -msgid "To remove only those listeners that run over HTTPS:" -msgstr "HTTPS で実行されるリスナーのみを削除するには、以下を実行します。" - -#: ../../rst/os_guide/windows_setup.rst:187 -msgid "The ``Keys`` object is an array of strings, so it can contain different values. By default, it contains a key for ``Transport=`` and ``Address=`` which correspond to the values from the ``winrm enumerate winrm/config/Listeners`` command." -msgstr "``Keys`` オブジェクトは文字列の配列であるため、異なる値を含むことができます。デフォルトでは、 ``winrm enumerate winrm/config/Listeners`` コマンドからのの値に対応する ``Transport=`` および ``Address=`` のキーを含んでいます。" - -#: ../../rst/os_guide/windows_setup.rst:190 -msgid "WinRM Service Options" -msgstr "WinRM サービスオプション" - -#: ../../rst/os_guide/windows_setup.rst:191 -msgid "You can control the behavior of the WinRM service component, including authentication options and memory settings." -msgstr "認証オプションやメモリー設定など、WinRM サービスコンポーネントの動作を制御できます。" - -#: ../../rst/os_guide/windows_setup.rst:193 -msgid "To get an output of the current service configuration options, run the following command:" -msgstr "現在のサービス設定オプションの出力を得るには、次のコマンドを実行します。" - -#: ../../rst/os_guide/windows_setup.rst:238 -msgid "You do not need to change the majority of these options. However, some of the important ones to know about are:" -msgstr "これらのオプションの大部分を変更する必要はありませんが、知っておくべき重要なオプションは次のとおりです。" - -#: ../../rst/os_guide/windows_setup.rst:240 -msgid "``Service\\AllowUnencrypted`` - specifies whether WinRM will allow HTTP traffic without message encryption. Message level encryption is only possible when the ``ansible_winrm_transport`` variable is ``ntlm``, ``kerberos`` or ``credssp``. By default, this is ``false`` and you should only set it to ``true`` when debugging WinRM messages." -msgstr "``Service\\AllowUnencrypted``: メッセージを暗号化せずに HTTP トラフィックを WinRM で許可するかどうかを定義します。メッセージレベルの暗号化は、``ansible_winrm_transport`` 変数が ``ntlm``、``kerberos``、または ``credssp`` の場合にのみ可能です。デフォルトでは、これは ``false`` であり、WinRM メッセージをデバッグする場合に限り ``true`` に設定する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:242 -msgid "``Service\\Auth\\*`` - defines what authentication options you can use with the WinRM service. By default, ``Negotiate (NTLM)`` and ``Kerberos`` are enabled." -msgstr "``Service\\Auth\\*``: WinRM サービスで使用可能な認証オプションを定義します。デフォルトでは、``Negotiate (NTLM)`` および ``Kerberos`` が有効になります。" - -#: ../../rst/os_guide/windows_setup.rst:244 -msgid "``Service\\Auth\\CbtHardeningLevel`` - specifies whether channel binding tokens are not verified (None), verified but not required (Relaxed), or verified and required (Strict). CBT is only used when connecting with NT LAN Manager (NTLM) or Kerberos over HTTPS." -msgstr "``Service\\Auth\\CbtHardeningLevel``: チャンネルバインディングトークンを検証しない (None)、検証済みだが必要ない (Relaxed)、検証済みで必要 (Strict) のいずれかを指定します。CBT は、HTTPS の NT LAN Manager (NTLM) または Kerberos での接続時にのみ使用されます。" - -#: ../../rst/os_guide/windows_setup.rst:246 -msgid "``Service\\CertificateThumbprint`` - thumbprint of the certificate for encrypting the TLS channel used with CredSSP authentication. By default, this is empty. A self-signed certificate is generated when the WinRM service starts and is used in the TLS process." -msgstr "``Service\\CertificateThumbprint``: CredSSP 認証で使用される TLS チャンネルの暗号化に使用される証明書のサムプリントです。デフォルトでは、これは空です。自己署名証明書は、WinRM サービスの起動時に生成され、TLS プロセスで使用されます。" - -#: ../../rst/os_guide/windows_setup.rst:248 -msgid "``Winrs\\MaxShellRunTime`` - maximum time, in milliseconds, that a remote command is allowed to execute." -msgstr "``Winrs\\MaxShellRunTime``: リモートコマンドの実行を許可する最大時間をミリ秒単位で指定します。" - -#: ../../rst/os_guide/windows_setup.rst:250 -msgid "``Winrs\\MaxMemoryPerShellMB`` - maximum amount of memory allocated per shell, including its child processes." -msgstr "``Winrs\\MaxMemoryPerShellMB``: シェルの子プロセスなど、シェルごとに割り当てられるメモリーの最大量です。" - -#: ../../rst/os_guide/windows_setup.rst:252 -msgid "To modify a setting under the ``Service`` key in PowerShell, you need to provide a path to the option after ``winrm/config/Service``:" -msgstr "PowerShell の ``Service`` キーで設定を変更するには、``winrm/config/Service`` の後に オプションへのパスを指定する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:258 -msgid "For example, to change ``Service\\Auth\\CbtHardeningLevel``:" -msgstr "たとえば、``Service\\Auth\\CbtHardeningLevel`` を変更するには以下を行います。" - -#: ../../rst/os_guide/windows_setup.rst:264 -msgid "To modify a setting under the ``Winrs`` key in PowerShell, you need to provide a path to the option after ``winrm/config/Winrs``:" -msgstr "PowerShell の ``Winrs`` キーで設定を変更するには、``winrm/config/Winrs`` の後に オプションへのパスを指定する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:270 -msgid "For example, to change ``Winrs\\MaxShellRunTime``:" -msgstr "たとえば、``Winrs\\MaxShellRunTime`` を変更するには、以下を行います。" - -#: ../../rst/os_guide/windows_setup.rst:276 -msgid "If you run the command in a domain environment, some of these options are set by GPO and cannot be changed on the host itself. When you configured a key with GPO, it contains the text ``[Source=\"GPO\"]`` next to the value." -msgstr "ドメイン環境で動作している場合には、これらのオプションの一部は GPO によって設定され、ホスト自体では変更できません。GPO で設定されたキーには、値の横に ``[Source=\"GPO\"]`` というテキストが表示されます。" - -#: ../../rst/os_guide/windows_setup.rst:280 -msgid "Common WinRM Issues" -msgstr "一般的な WinRM の問題" - -#: ../../rst/os_guide/windows_setup.rst:281 -msgid "WinRM has a wide range of configuration options, which makes its configuration complex. As a result, errors that Ansible displays could in fact be problems with the host setup instead." -msgstr "WinRM にはさまざまな設定オプションがあり、その設定が複雑になるので、Ansible が表示するエラーは、実際にはホストの設定に問題がある可能性があります。" - -#: ../../rst/os_guide/windows_setup.rst:283 -msgid "To identify a host issue, run the following command from another Windows host to connect to the target Windows host." -msgstr "問題がホストの問題であるかどうかを判断する簡単な方法として、別の Windows ホストから次のコマンドを実行して、対象の Windows ホストに接続する方法があります。" - -#: ../../rst/os_guide/windows_setup.rst:285 -msgid "To test HTTP:" -msgstr "HTTP をテストするには、以下を実行します。" - -#: ../../rst/os_guide/windows_setup.rst:291 -msgid "To test HTTPS:" -msgstr "HTTPS をテストするには、以下を実行します。" - -#: ../../rst/os_guide/windows_setup.rst:297 -msgid "The command will fail if the certificate is not verifiable." -msgstr "証明書が検証できない場合、コマンドは失敗します。" - -#: ../../rst/os_guide/windows_setup.rst:299 -msgid "To test HTTPS ignoring certificate verification:" -msgstr "証明書の検証を無視する HTTPS をテストするには、以下を実行します。" - -#: ../../rst/os_guide/windows_setup.rst:310 -msgid "If any of the above commands fail, the issue is probably related to the WinRM setup." -msgstr "上記のコマンドのいずれかが失敗した場合には、問題は WinRM 設定に関連している可能性があります。" - -#: ../../rst/os_guide/windows_setup.rst:313 -msgid "HTTP 401/Credentials Rejected" -msgstr "HTTP 401/認証情報の拒否" - -#: ../../rst/os_guide/windows_setup.rst:314 -msgid "An HTTP 401 error indicates the authentication process failed during the initial connection. You can check the following to troubleshoot:" -msgstr "HTTP 401 エラーは、最初の接続時に認証プロセスが失敗したことを示します。以下の項目を確認して、トラブルシューティングできます。" - -#: ../../rst/os_guide/windows_setup.rst:317 -msgid "The credentials are correct and set properly in your inventory with the ``ansible_user`` and ``ansible_password`` variables." -msgstr "``ansible_user`` および ``ansible_password`` 変数を使用して、認証情報が正しく、インベントリーに適切に設定されている。" - -#: ../../rst/os_guide/windows_setup.rst:319 -msgid "The user is a member of the local Administrators group, or has been explicitly granted access. You can perform a connection test with the ``winrs`` command to rule this out." -msgstr "ユーザーがローカルの Administrators グループのメンバーであるか、明示的にアクセスを許可されている。これは、``winrs`` コマンドによる接続テストで除外できます。" - -#: ../../rst/os_guide/windows_setup.rst:321 -msgid "The authentication option set by the ``ansible_winrm_transport`` variable is enabled under ``Service\\Auth\\*``." -msgstr "``ansible_winrm_transport`` で設定した認証オプションが、``Service\\Auth\\*`` で有効になっている。" - -#: ../../rst/os_guide/windows_setup.rst:323 -msgid "If running over HTTP and not HTTPS, use ``ntlm``, ``kerberos`` or ``credssp`` with the ``ansible_winrm_message_encryption: auto`` custom inventory variable to enable message encryption. If you use another authentication option, or if it is not possible to upgrade the installed ``pywinrm`` package, you can set ``Service\\AllowUnencrypted`` to ``true``. This is recommended only for troubleshooting." -msgstr "HTTPS ではなく HTTP で実行する場合は、``ntlm``、``kerberos``、または ``credssp`` を使用してメッセージの暗号化を有効にします。別の認証オプションを使用する場合、またはインストールされた ``pywinrm`` パッケージをアップグレードできない場合には、``Service\\AllowUnencrypted`` を ``true`` に設定できます。これは、トラブルシューティングの目的でのみ推奨されます。" - -#: ../../rst/os_guide/windows_setup.rst:325 -msgid "The downstream packages ``pywinrm``, ``requests-ntlm``, ``requests-kerberos``, and/or ``requests-credssp`` are up to date using ``pip``." -msgstr "ダウンストリームパッケージである ``pywinrm``、``requests-ntlm``、``requests-kerberos``、または ``requests-credssp``、もしくはその組み合わせが ``pip`` を使用して最新の状態になっている。" - -#: ../../rst/os_guide/windows_setup.rst:327 -msgid "For Kerberos authentication, ensure that ``Service\\Auth\\CbtHardeningLevel`` is not set to ``Strict``." -msgstr "Kerberos 認証を使用する場合は、``Service\\Auth\\CbtHardeningLevel`` が ``Strict`` に設定されていないことを確認してください。" - -#: ../../rst/os_guide/windows_setup.rst:329 -msgid "For Basic or Certificate authentication, make sure that the user is a local account. Domain accounts do not work with Basic and Certificate authentication." -msgstr "Basic 認証や Certificate 認証を使用する場合は、ローカルアカウントであることを確認してください。ドメインアカウントは、Basic 認証や Certificate 認証では機能しません。" - -#: ../../rst/os_guide/windows_setup.rst:332 -msgid "HTTP 500 Error" -msgstr "HTTP 500 Error" - -#: ../../rst/os_guide/windows_setup.rst:333 -msgid "An HTTP 500 error indicates a problem with the WinRM service. You can check the following to troubleshoot:" -msgstr "HTTP 500 エラーは、WinRM サービスに問題があることを示します。以下を確認してトラブルシューティングを行うことができます。" - -#: ../../rst/os_guide/windows_setup.rst:335 -msgid "The number of your currently open shells has not exceeded either ``WinRsMaxShellsPerUser``. Alternatively, you did not exceed any of the other Winrs quotas." -msgstr "現在開いているシェルの数が ``WinRsMaxShellsPerUser`` を超えていないか、他の Winrs クォータを超えていません。" - -#: ../../rst/os_guide/windows_setup.rst:338 -msgid "Timeout Errors" -msgstr "タイムアウトエラー" - -#: ../../rst/os_guide/windows_setup.rst:339 -msgid "Sometimes Ansible is unable to reach the host. These instances usually indicate a problem with the network connection. You can check the following to troubleshoot:" -msgstr "Ansible がホストに到達できないことがあります。これらのインスタンスは通常、ネットワーク接続に問題があることを示します。以下を確認してトラブルシューティングを行うことができます。" - -#: ../../rst/os_guide/windows_setup.rst:341 -msgid "The firewall is not set to block the configured WinRM listener ports." -msgstr "ファイアウォールが、設定された WinRM リスナーポートをブロックするように設定されていない。" - -#: ../../rst/os_guide/windows_setup.rst:342 -msgid "A WinRM listener is enabled on the port and path set by the host vars." -msgstr "WinRM リスナーが、ホスト変数によって設定されたポートおよびパスで有効になっている。" - -#: ../../rst/os_guide/windows_setup.rst:343 -msgid "The ``winrm`` service is running on the Windows host and is configured for the automatic start." -msgstr "Windows ホスト上で ``winrm`` サービスが稼動しており、自動起動するように設定されている。" - -#: ../../rst/os_guide/windows_setup.rst:346 -msgid "Connection Refused Errors" -msgstr "接続拒否エラー" - -#: ../../rst/os_guide/windows_setup.rst:347 -msgid "When you communicate with the WinRM service on the host you can encounter some problems. Check the following to help the troubleshooting:" -msgstr "ホストの WinRM サービスと通信すると、いくつかの問題が発生する可能性があります。トラブルシューティングを行うには、以下を確認してください。" - -#: ../../rst/os_guide/windows_setup.rst:349 -msgid "The WinRM service is up and running on the host. Use the ``(Get-Service -Name winrm).Status`` command to get the status of the service." -msgstr "ホスト上で WinRM サービスが稼働している。``(Get-Service -Name winrm).Status`` コマンドを使用して、サービスのステータスを取得します。" - -#: ../../rst/os_guide/windows_setup.rst:350 -msgid "The host firewall is allowing traffic over the WinRM port. By default this is ``5985`` for HTTP and ``5986`` for HTTPS." -msgstr "ホスト側のファイアウォールが、WinRM ポートへのトラフィックを許可している。デフォルトでは、HTTP では ``5985``、HTTPS では ``5986`` となっています。" - -#: ../../rst/os_guide/windows_setup.rst:352 -msgid "Sometimes an installer may restart the WinRM or HTTP service and cause this error. The best way to deal with this is to use the ``win_psexec`` module from another Windows host." -msgstr "インストーラーが WinRM や HTTP サービスを再起動してしまい、このエラーが発生することがあります。これに対処する最良の方法は、別の Windows ホストから ``win_psexec`` モジュールを使用します。" - -#: ../../rst/os_guide/windows_setup.rst:355 -msgid "Failure to Load Builtin Modules" -msgstr "組み込みモジュールの読み込みに失敗" - -#: ../../rst/os_guide/windows_setup.rst:356 -msgid "Sometimes PowerShell fails with an error message similar to:" -msgstr "PowerShell が以下のようなエラーメッセージで失敗することがあります。" - -#: ../../rst/os_guide/windows_setup.rst:362 -msgid "In that case, there could be a problem when trying to access all the paths specified by the ``PSModulePath`` environment variable." -msgstr "この場合、``PSModulePath`` 環境変数が指定したすべてのパスにアクセスしようとすると問題が生じる可能性があります。" - -#: ../../rst/os_guide/windows_setup.rst:364 -msgid "A common cause of this issue is that ``PSModulePath`` contains a Universal Naming Convention (UNC) path to a file share. Additionally, the double hop/credential delegation issue causes that the Ansible process cannot access these folders. To work around this problem is to either:" -msgstr "この問題の一般的な原因は、``PSModulePath``ファイル共有への汎用命名規則 (UNC) パスが含まれています。さらに、ダブルホップ/認証情報の委任の問題により、Ansible プロセスがこれらのフォルダーにアクセスできなくなります。この問題を回避するには、次のいずれかを行います。" - -#: ../../rst/os_guide/windows_setup.rst:366 -msgid "Remove the UNC path from ``PSModulePath``." -msgstr "``PSModulePath`` から UNC パスを削除します。" - -#: ../../rst/os_guide/windows_setup.rst:368 -msgid "or" -msgstr "または" - -#: ../../rst/os_guide/windows_setup.rst:370 -msgid "Use an authentication option that supports credential delegation like ``credssp`` or ``kerberos``. You need to have the credential delegation enabled." -msgstr "``credssp`` や ``kerberos`` のような、認証情報の委譲をサポートする認証オプションを使用します。認証情報の委譲を有効にする必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:372 -msgid "See `KB4076842 `_ for more information on this problem." -msgstr "この問題の詳細は、「`KB4076842 `_」を参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:375 -msgid "Windows SSH Setup" -msgstr "Windows SSH の設定" - -#: ../../rst/os_guide/windows_setup.rst:376 -msgid "Ansible 2.8 has added an experimental SSH connection for Windows managed nodes." -msgstr "Ansible 2.8 では、Windows 管理ノードの実験的な SSH 接続が追加されました。" - -#: ../../rst/os_guide/windows_setup.rst:379 -msgid "Use this feature at your own risk! Using SSH with Windows is experimental. This implementation may make backwards incompatible changes in future releases. The server-side components can be unreliable depending on your installed version." -msgstr "この機能はご自身の責任でお使いください。Windows での SSH の使用は実験的なものであり、実装は機能リリースにおいて後方互換性のない変更を行う可能性があります。また、サーバー側のコンポーネントは、インストールされているバージョンによっては信頼性に欠けることがあります。" - -#: ../../rst/os_guide/windows_setup.rst:383 -msgid "Installing OpenSSH using Windows Settings" -msgstr "Windows 設定を使用した OpenSSH のインストール" - -#: ../../rst/os_guide/windows_setup.rst:384 -msgid "You can use OpenSSH to connect Window 10 clients to Windows Server 2019. OpenSSH Client is available to install on Windows 10 build 1809 and later. OpenSSH Server is available to install on Windows Server 2019 and later." -msgstr "OpenSSH は、WinkW 10 クライアントを Windows Server 2019 に接続するために使用できます。OpenSSH クライアントは Windows 10 ビルド 1809 以降にインストールできますが、OpenSSH Server は Windows Server 2019 以降に利用できます。" - -#: ../../rst/os_guide/windows_setup.rst:386 -msgid "For more information, refer to `Get started with OpenSSH for Windows `_." -msgstr "詳細は、`Get started with OpenSSH for Windows ` を参照してください。" - -#: ../../rst/os_guide/windows_setup.rst:389 -msgid "Installing Win32-OpenSSH" -msgstr "Win32-OpenSSH のインストール" - -#: ../../rst/os_guide/windows_setup.rst:390 -msgid "To install the `Win32-OpenSSH `_ service for use with Ansible, select one of these installation options:" -msgstr "Ansible で使用する `Win32-OpenSSH `_ サービスをインストールするには、以下のいずれかのインストールオプションを選択します。" - -#: ../../rst/os_guide/windows_setup.rst:393 -msgid "Manually install ``Win32-OpenSSH``, following the `install instructions `_ from Microsoft." -msgstr "Microsoft 社が提供する `install instructions `_ に従って、``Win32-OpenSSH`` を手動でインストールしてください。" - -#: ../../rst/os_guide/windows_setup.rst:395 -msgid "Use Chocolatey:" -msgstr "Chocolatey を使用します。" - -#: ../../rst/os_guide/windows_setup.rst:401 -msgid "Use the ``win_chocolatey`` Ansible module:" -msgstr "Ansibleモジュール ``win_chocolatey`` を使用します。" - -#: ../../rst/os_guide/windows_setup.rst:411 -msgid "Install an Ansible Galaxy role for example `jborean93.win_openssh `_:" -msgstr "`jborean93.win_openssh `_ などの Ansible Galaxy ロールをインストールします。" - -#: ../../rst/os_guide/windows_setup.rst:417 -msgid "Use the role in your playbook:" -msgstr "playbook のロールを使用します。" - -#: ../../rst/os_guide/windows_setup.rst:428 -msgid "``Win32-OpenSSH`` is still a beta product and is constantly being updated to include new features and bugfixes. If you use SSH as a connection option for Windows, we highly recommend you install the latest version." -msgstr "``Win32-OpenSSH`` は未だベータ版の製品であり、新機能やバグ修正を含めて常に更新されています。Windows で SSH 接続をご利用の方は、上記 3 つの方法から最新版をインストールすることを強く推奨します。" - -#: ../../rst/os_guide/windows_setup.rst:431 -msgid "Configuring the Win32-OpenSSH shell" -msgstr "Win32-OpenSSH シェルの設定" - -#: ../../rst/os_guide/windows_setup.rst:433 -msgid "By default ``Win32-OpenSSH`` uses ``cmd.exe`` as a shell." -msgstr "デフォルトでは、``Win32-OpenSSH`` はシェルとして ``cmd.exe`` を使用します。" - -#: ../../rst/os_guide/windows_setup.rst:435 -msgid "To configure a different shell, use an Ansible playbook with a task to define the registry setting:" -msgstr "別のシェルを設定するには、Ansible Playbook を使用して、レジストリー設定を定義します。" - -#: ../../rst/os_guide/windows_setup.rst:447 -msgid "To revert the settings back to the default shell:" -msgstr "設定をデフォルトのシェルに戻すには、以下を実行します。" - -#: ../../rst/os_guide/windows_setup.rst:458 -msgid "Win32-OpenSSH Authentication" -msgstr "Win32-OpenSSH 認証" - -#: ../../rst/os_guide/windows_setup.rst:459 -msgid "Win32-OpenSSH authentication with Windows is similar to SSH authentication on Unix/Linux hosts. You can use a plaintext password or SSH public key authentication." -msgstr "Windows での Win32-OpenSSH 認証は、Unix/Linux ホストの SSH 認証に似ています。プレーンテキストのパスワードまたは SSH 公開鍵認証を使用できます。" - -#: ../../rst/os_guide/windows_setup.rst:461 -msgid "For the key-based authentication:" -msgstr "鍵ベース認証の使用" - -#: ../../rst/os_guide/windows_setup.rst:463 -msgid "Add your public keys to an ``authorized_key`` file in the ``.ssh`` folder of the user's profile directory." -msgstr "ユーザーのプロファイルディレクトリーの ``.ssh`` フォルダーにある ``authorized_key`` ファイルに公開鍵を追加します。" - -#: ../../rst/os_guide/windows_setup.rst:465 -msgid "Configure the SSH service using the ``sshd_config`` file." -msgstr "``sshd_config`` ファイルを使用して SSH サービスを設定します。" - -#: ../../rst/os_guide/windows_setup.rst:467 -msgid "When using SSH key authentication with Ansible, the remote session will not have access to user credentials and will fail when attempting to access a network resource. This is also known as the double-hop or credential delegation issue. To work around this problem:" -msgstr "Ansible で SSH キー認証を使用する場合は、リモートセッションがユーザーの認証情報にアクセスできず、ネットワークリソースにアクセスしようとすると失敗することがあります。これは、ダブルホップや認証情報の委譲の問題としても知られています。この問題を回避するには以下を行います。" - -#: ../../rst/os_guide/windows_setup.rst:469 -msgid "Use plaintext password authentication by setting the ``ansible_password`` variable." -msgstr "``ansible_password`` 変数を設定して、プレーンテキストのパスワード認証を使用する。" - -#: ../../rst/os_guide/windows_setup.rst:470 -msgid "Use the ``become`` directive on the task with the credentials of the user that needs access to the remote resource." -msgstr "リモートリソースへのアクセスを必要とするユーザーの認証情報を使用して、タスクで ``become`` ディレクティブを使用する。" - -#: ../../rst/os_guide/windows_setup.rst:473 -msgid "Configuring Ansible for SSH on Windows" -msgstr "Windows で SSH 用に Ansible の設定" - -#: ../../rst/os_guide/windows_setup.rst:474 -msgid "To configure Ansible to use SSH for Windows hosts, you must set two connection variables:" -msgstr "Ansible が Windows ホストに SSH を使用するように設定するには、接続変数を 2 つ設定する必要があります。" - -#: ../../rst/os_guide/windows_setup.rst:476 -msgid "set ``ansible_connection`` to ``ssh``" -msgstr "``ansible_connection`` を ``ssh`` に設定します。" - -#: ../../rst/os_guide/windows_setup.rst:477 -msgid "set ``ansible_shell_type`` to ``cmd`` or ``powershell``" -msgstr "``ansible_shell_type`` を ``cmd`` または ``powershell`` に設定する" - -#: ../../rst/os_guide/windows_setup.rst:479 -msgid "The ``ansible_shell_type`` variable should reflect the ``DefaultShell`` configured on the Windows host. Set ``ansible_shell_type`` to ``cmd`` for the default shell. Alternatively, set ``ansible_shell_type`` to ``powershell`` if you changed ``DefaultShell`` to PowerShell." -msgstr "``ansible_shell_type`` 変数には、Windows ホストで設定されている``DefaultShell`` を反映させる必要があります。デフォルトシェルの場合は ``ansible_shell_type`` は ``cmd`` に設定します。または、``DefaultShell`` を PowerShell に変更した場合には ``ansible_shell_type`` を ``powershell`` に設定します。" - -#: ../../rst/os_guide/windows_setup.rst:482 -msgid "Known issues with SSH on Windows" -msgstr "Windows での SSH に関する既知の問題" - -#: ../../rst/os_guide/windows_setup.rst:483 -msgid "Using SSH with Windows is experimental. Currently existing issues are:" -msgstr "Windows での SSH の使用は実験的なものです。現在、既存の問題は次のとおりです。" - -#: ../../rst/os_guide/windows_setup.rst:485 -msgid "Win32-OpenSSH versions older than ``v7.9.0.0p1-Beta`` do not work when ``powershell`` is the shell type." -msgstr "``powershell`` がシェルタイプの場合は、``v7.9.0.0p1-Beta`` よりも古い Win32-OpenSSH バージョンは機能しません。" - -#: ../../rst/os_guide/windows_setup.rst:486 -msgid "While Secure Copy Protocol (SCP) should work, SSH File Transfer Protocol (SFTP) is the recommended mechanism to use when copying or fetching a file." -msgstr "Secure Copy Protocol (SCP) も有効ですが、SSH File Transfer Protocol (SFTP) は、ファイルのコピーまたは取得時に使用する、推奨のメカニズムです。" - -#: ../../rst/os_guide/windows_usage.rst:4 -msgid "Using Ansible and Windows" -msgstr "Ansible および Windows の使用" - -#: ../../rst/os_guide/windows_usage.rst:5 -msgid "When using Ansible to manage Windows, many of the syntax and rules that apply for Unix/Linux hosts also apply to Windows, but there are still some differences when it comes to components like path separators and OS-specific tasks. This document covers details specific to using Ansible for Windows." -msgstr "Ansible を使用して Windows を管理する場合は、Unix/Linux ホストに適用される構文やルールの多くが Windows にも適用されますが、パスセパレーターや OS 固有のタスクなどのコンポーネントに関しては、若干の違いがあります。このドキュメントでは、Ansible を Windows で使用する際の詳細情報を説明します。" - -#: ../../rst/os_guide/windows_usage.rst:14 -msgid "Use Cases" -msgstr "ユースケース" - -#: ../../rst/os_guide/windows_usage.rst:15 -msgid "Ansible can be used to orchestrate a multitude of tasks on Windows servers. Below are some examples and info about common tasks." -msgstr "Ansible は、Windows サーバーにある多数のタスクを調整するために使用できます。以下は、一般的なタスクに関する例と情報です。" - -#: ../../rst/os_guide/windows_usage.rst:19 -msgid "Installing Software" -msgstr "ソフトウェアのインストール" - -#: ../../rst/os_guide/windows_usage.rst:20 -msgid "There are three main ways that Ansible can be used to install software:" -msgstr "Ansible を使用してソフトウェアをインストールできる主な方法は 3 つあります。" - -#: ../../rst/os_guide/windows_usage.rst:22 -msgid "Using the ``win_chocolatey`` module. This sources the program data from the default public `Chocolatey `_ repository. Internal repositories can be used instead by setting the ``source`` option." -msgstr "``win_chocolatey`` モジュールを使用。このモジュールは、デフォルトのパブリックな `Chocolatey `_ リポジトリーからプログラムデータを調達します。``source`` オプションを設定することで、代わりに内部リポジトリーを使用することができます。" - -#: ../../rst/os_guide/windows_usage.rst:26 -msgid "Using the ``win_package`` module. This installs software using an MSI or .exe installer from a local/network path or URL." -msgstr "``win_package`` モジュールを使用します。これは、ローカル/ネットワークパスまたは URL から MSI または .exe インストーラーを使用してソフトウェアをインストールします。" - -#: ../../rst/os_guide/windows_usage.rst:29 -msgid "Using the ``win_command`` or ``win_shell`` module to run an installer manually." -msgstr "``win_command`` モジュールまたは ``win_shell`` モジュールを使用して手動でインストーラーを実行します。" - -#: ../../rst/os_guide/windows_usage.rst:31 -msgid "The ``win_chocolatey`` module is recommended since it has the most complete logic for checking to see if a package has already been installed and is up-to-date." -msgstr "``win_chocolatey`` モジュールは、パッケージがすでにインストールされていて最新かどうかを確認するための最も完全なロジックを備えているため、このモジュールを使用することが推奨されます。" - -#: ../../rst/os_guide/windows_usage.rst:33 -msgid "Below are some examples of using all three options to install 7-Zip:" -msgstr "以下は、3 つのすべてのオプションを使用して 7-Zip をインストールするいくつかの例です。" - -#: ../../rst/os_guide/windows_usage.rst:83 -msgid "Some installers like Microsoft Office or SQL Server require credential delegation or access to components restricted by WinRM. The best method to bypass these issues is to use ``become`` with the task. With ``become``, Ansible will run the installer as if it were run interactively on the host." -msgstr "Microsoft Office や SQL Server などの一部のインストーラーは、認証情報の委譲や WinRM で制限されたコンポーネントへのアクセスを必要とします。これらの問題を回避するための最良の方法は、タスクに ``become`` を使用することです。``become`` を使用すると、Ansible はあたかもホスト上で対話的に実行されているかのようにインストーラを実行します。" - -#: ../../rst/os_guide/windows_usage.rst:88 -msgid "Many installers do not properly pass back error information over WinRM. In these cases, if the install has been verified to work locally the recommended method is to use become." -msgstr "多くのインストーラーは、WinRM を介してエラー情報を適切に返しません。このような場合には、ローカルでの動作が確認されている場合には become を使用することが推奨されます。" - -#: ../../rst/os_guide/windows_usage.rst:90 -msgid "Some installers restart the WinRM or HTTP services, or cause them to become temporarily unavailable, making Ansible assume the system is unreachable." -msgstr "一部のインストーラーは、WinRM サービスまたは HTTP サービスを再起動したり、一時的に利用できなくなったりするため、システムが到達不能であると Ansible により想定されます。" - -#: ../../rst/os_guide/windows_usage.rst:93 -msgid "Installing Updates" -msgstr "更新のインストール" - -#: ../../rst/os_guide/windows_usage.rst:94 -msgid "The ``win_updates`` and ``win_hotfix`` modules can be used to install updates or hotfixes on a host. The module ``win_updates`` is used to install multiple updates by category, while ``win_hotfix`` can be used to install a single update or hotfix file that has been downloaded locally." -msgstr "``win_updates`` モジュールおよび ``win_hotfix`` モジュールを使用すると、ホストにアップデートや Hotfix をインストールできます。モジュール ``win_updates`` はカテゴリー別に複数のアップデートをインストールするために使用され、``win_hotfix`` はローカルにダウンロードした単一の更新または Hotfix ファイルをインストールするために使用されます。" - -#: ../../rst/os_guide/windows_usage.rst:99 -msgid "The ``win_hotfix`` module has a requirement that the DISM PowerShell cmdlets are present. These cmdlets were only added by default on Windows Server 2012 and newer and must be installed on older Windows hosts." -msgstr "``win_hotfix`` モジュールには、DISM PowerShell コマンドレットが存在するという要件があります。これらのコマンドレットは、Windows Server 2012 以降でのみデフォルトで追加されており、それ以前の Windows ホストではインストールする必要があります。" - -#: ../../rst/os_guide/windows_usage.rst:103 -msgid "The following example shows how ``win_updates`` can be used:" -msgstr "次の例は、``win_updates`` の使用方法を示しています。" - -#: ../../rst/os_guide/windows_usage.rst:119 -msgid "The following example show how ``win_hotfix`` can be used to install a single update or hotfix:" -msgstr "以下の例では、``win_hotfix`` を使用して単一のアップデートまたは Hotfix をインストールする方法を示しています。" - -#: ../../rst/os_guide/windows_usage.rst:141 -msgid "Set Up Users and Groups" -msgstr "ユーザーおよびグループの設定" - -#: ../../rst/os_guide/windows_usage.rst:142 -msgid "Ansible can be used to create Windows users and groups both locally and on a domain." -msgstr "Ansible を使用して、ローカルとドメインの両方で Windows ユーザーとグループを作成できます。" - -#: ../../rst/os_guide/windows_usage.rst:145 -msgid "Local" -msgstr "ローカル" - -#: ../../rst/os_guide/windows_usage.rst:146 -msgid "The modules ``win_user``, ``win_group`` and ``win_group_membership`` manage Windows users, groups and group memberships locally." -msgstr "``win_user`` モジュール、``win_group`` モジュール、および ``win_group_membership`` モジュールは、Windows のユーザー、グループ、およびグループのメンバーシップをローカルに管理します。" - -#: ../../rst/os_guide/windows_usage.rst:149 -msgid "The following is an example of creating local accounts and groups that can access a folder on the same host:" -msgstr "以下は、同じホストにあるディレクトリーにアクセスできるローカルアカウントおよびグループを作成する例を示します。" - -#: ../../rst/os_guide/windows_usage.rst:192 -msgid "Domain" -msgstr "ドメイン" - -#: ../../rst/os_guide/windows_usage.rst:193 -msgid "The modules ``win_domain_user`` and ``win_domain_group`` manages users and groups in a domain. The below is an example of ensuring a batch of domain users are created:" -msgstr "``win_domain_user`` モジュールおよび ``win_domain_group`` モジュールは、ドメインのユーザーおよびグループを管理します。以下は、ドメインユーザーのバッチを確実に作成する例です。" - -#: ../../rst/os_guide/windows_usage.rst:219 -msgid "Running Commands" -msgstr "コマンドの実行" - -#: ../../rst/os_guide/windows_usage.rst:220 -msgid "In cases where there is no appropriate module available for a task, a command or script can be run using the ``win_shell``, ``win_command``, ``raw``, and ``script`` modules." -msgstr "タスクに適したモジュールがない場合は、``win_shell`` モジュール、``win_command`` モジュール、``raw`` モジュール、および ``script`` モジュールを使用してコマンドやスクリプトを実行できます。" - -#: ../../rst/os_guide/windows_usage.rst:223 -msgid "The ``raw`` module simply executes a Powershell command remotely. Since ``raw`` has none of the wrappers that Ansible typically uses, ``become``, ``async`` and environment variables do not work." -msgstr "``raw`` モジュールは、Powershell コマンドをリモートで実行するだけです。``raw`` は、Ansible が通常使用するラッパーを一切使用していないため、``become``、``async``、および環境変数は動作しません。" - -#: ../../rst/os_guide/windows_usage.rst:227 -msgid "The ``script`` module executes a script from the Ansible controller on one or more Windows hosts. Like ``raw``, ``script`` currently does not support ``become``, ``async``, or environment variables." -msgstr "``script`` モジュールは、Ansible コントローラーからのスクリプトを 1 つまたは複数の Windows ホスト上で実行します。``raw`` と同様に、``script`` は現在、``become``、``async``、または環境変数をサポートしていません。" - -#: ../../rst/os_guide/windows_usage.rst:231 -msgid "The ``win_command`` module is used to execute a command which is either an executable or batch file, while the ``win_shell`` module is used to execute commands within a shell." -msgstr "``win_command`` モジュールは、実行ファイルまたはバッチファイルであるコマンドを実行するために使用され、``win_shell`` モジュールは、シェル内のコマンドを実行するために使用されます。" - -#: ../../rst/os_guide/windows_usage.rst:235 -msgid "Choosing Command or Shell" -msgstr "コマンドまたはシェルの選択" - -#: ../../rst/os_guide/windows_usage.rst:236 -msgid "The ``win_shell`` and ``win_command`` modules can both be used to execute a command or commands. The ``win_shell`` module is run within a shell-like process like ``PowerShell`` or ``cmd``, so it has access to shell operators like ``<``, ``>``, ``|``, ``;``, ``&&``, and ``||``. Multi-lined commands can also be run in ``win_shell``." -msgstr "``win_shell`` モジュールおよび ``win_command`` モジュールは、どちらもコマンドの実行に使用できます。``win_shell`` モジュールは ``PowerShell`` や ``cmd`` などのシェルのようななプロセス内で実行するため、``<``、``>``、``|``、``;``、``&&``、``||`` などのシェル演算子を使用できます。``win_shell`` では、複数行のコマンドも実行できます。" - -#: ../../rst/os_guide/windows_usage.rst:240 -msgid "The ``win_command`` module simply runs a process outside of a shell. It can still run a shell command like ``mkdir`` or ``New-Item`` by passing the shell commands to a shell executable like ``cmd.exe`` or ``PowerShell.exe``." -msgstr "``win_command`` モジュールは、シェルの外部でプロセスを実行するだけです。``cmd.exe`` や ``PowerShell.exe`` などのシェル実行ファイルに、``mkdir`` や ``New-Item`` などのシェルコマンドを渡してシェルコマンドを実行できます。" - -#: ../../rst/os_guide/windows_usage.rst:244 -msgid "Here are some examples of using ``win_command`` and ``win_shell``:" -msgstr "以下は、``win_command`` と ``win_shell`` を使用した例です。" - -#: ../../rst/os_guide/windows_usage.rst:272 -msgid "Some commands like ``mkdir``, ``del``, and ``copy`` only exist in the CMD shell. To run them with ``win_command`` they must be prefixed with ``cmd.exe /c``." -msgstr "``mkdir``、``del``、``copy`` などの一部のコマンドは、CMD シェルにのみ存在します。``win_command`` でそれらを実行するには、``cmd.exe /c`` プレフィックスを付ける必要があります。" - -#: ../../rst/os_guide/windows_usage.rst:277 -msgid "Argument Rules" -msgstr "引数のルール" - -#: ../../rst/os_guide/windows_usage.rst:278 -msgid "When running a command through ``win_command``, the standard Windows argument rules apply:" -msgstr "``win_command`` を通じてコマンドを実行する際には、Windows の標準的な引数ルールが適用されます。" - -#: ../../rst/os_guide/windows_usage.rst:281 -msgid "Each argument is delimited by a white space, which can either be a space or a tab." -msgstr "各引数は、空白またはタブのいずれかである空白で区切られます。" - -#: ../../rst/os_guide/windows_usage.rst:284 -msgid "An argument can be surrounded by double quotes ``\"``. Anything inside these quotes is interpreted as a single argument even if it contains whitespace." -msgstr "引数は二重引用符 ``\"`` で囲むことができます。これらの引用符の内側には、空白が含まれていても、1 つの引数として解釈されます。" - -#: ../../rst/os_guide/windows_usage.rst:287 -msgid "A double quote preceded by a backslash ``\\`` is interpreted as just a double quote ``\"`` and not as an argument delimiter." -msgstr "バックスラッシュ ``\\`` が前に付いた二重引用符は、引数区切り文字ではなく二重引用符 ``\"`` として解釈されます。" - -#: ../../rst/os_guide/windows_usage.rst:290 -msgid "Backslashes are interpreted literally unless it immediately precedes double quotes; for example ``\\`` == ``\\`` and ``\\\"`` == ``\"``" -msgstr "バックスラッシュは、二重引用符の直前にない限り、文字通りに解釈されます (例: ``\\`` ==``\\`` および ``\\\"`` == ``\"``)。" - -#: ../../rst/os_guide/windows_usage.rst:293 -msgid "If an even number of backslashes is followed by a double quote, one backslash is used in the argument for every pair, and the double quote is used as a string delimiter for the argument." -msgstr "偶数個のバックスラッシュの後に二重引用符が続く場合は、すべてのペアの引数で 1 つのバックスラッシュが使用され、二重引用符が引数の文字列区切り文字として使用されます。" - -#: ../../rst/os_guide/windows_usage.rst:297 -msgid "If an odd number of backslashes is followed by a double quote, one backslash is used in the argument for every pair, and the double quote is escaped and made a literal double quote in the argument." -msgstr "奇数個のバックスラッシュの後に二重引用符が続く場合、引数ではペアごとに 1 つのバックスラッシュが使用され、二重引用符はエスケープされて引数のリテラル二重引用符となります。" - -#: ../../rst/os_guide/windows_usage.rst:301 -msgid "With those rules in mind, here are some examples of quoting:" -msgstr "これらのルールを念頭に置いて、引用の例をいくつか示します。" - -#: ../../rst/os_guide/windows_usage.rst:326 -msgid "For more information, see `escaping arguments `_." -msgstr "詳細情報は、「`escaping arguments `_」を参照してください。" - -#: ../../rst/os_guide/windows_usage.rst:329 -msgid "Creating and Running a Scheduled Task" -msgstr "スケジュールされたタスクの作成および実行" - -#: ../../rst/os_guide/windows_usage.rst:330 -msgid "WinRM has some restrictions in place that cause errors when running certain commands. One way to bypass these restrictions is to run a command through a scheduled task. A scheduled task is a Windows component that provides the ability to run an executable on a schedule and under a different account." -msgstr "WinRM には、特定のコマンドを実行したときにエラーが発生するような制限が設けられています。これらの制限を回避する方法の 1 つとして、スケジュールされたタスクを使用してコマンドを実行する方法があります。スケジュールされたタスクとは、実行ファイルをスケジュールに沿って、別のアカウントで実行する機能を提供する Windows コンポーネントです。" - -#: ../../rst/os_guide/windows_usage.rst:335 -msgid "Ansible version 2.5 added modules that make it easier to work with scheduled tasks in Windows. The following is an example of running a script as a scheduled task that deletes itself after running:" -msgstr "Ansible バージョン 2.5 では、Windows でのスケジュールタスクの操作を容易にするモジュールが追加されました。以下は、実行後に自分自身を削除するスクリプトをスケジュールタスクとして実行する例です。" - -#: ../../rst/os_guide/windows_usage.rst:364 -msgid "The modules used in the above example were updated/added in Ansible version 2.5." -msgstr "上記の例で使用されているモジュールは、Ansible バージョン 2.5 で更新または追加されたものです。" - -#: ../../rst/os_guide/windows_usage.rst:368 -msgid "Path Formatting for Windows" -msgstr "Windows のパスのフォーマット" - -#: ../../rst/os_guide/windows_usage.rst:369 -msgid "Windows differs from a traditional POSIX operating system in many ways. One of the major changes is the shift from ``/`` as the path separator to ``\\``. This can cause major issues with how playbooks are written, since ``\\`` is often used as an escape character on POSIX systems." -msgstr "Windows は、従来の POSIX オペレーティングシステムとは多くの点で異なります。主な変更点のひとつは、パスの区切り文字が ``/`` から ``\\`` になったことです。POSIX システムでは、``\\`` がしばしばエスケープ文字として使用されるため、これは Playbook の記述方法に重大な問題を引き起こす可能性があります。" - -#: ../../rst/os_guide/windows_usage.rst:374 -msgid "Ansible allows two different styles of syntax; each deals with path separators for Windows differently:" -msgstr "Ansible では、2 つの異なるスタイルの構文を使用できます。それぞれ Windows のパスセパレーターの扱いが異なります。" - -#: ../../rst/os_guide/windows_usage.rst:377 -msgid "YAML Style" -msgstr "YAML スタイル" - -#: ../../rst/os_guide/windows_usage.rst:378 -msgid "When using the YAML syntax for tasks, the rules are well-defined by the YAML standard:" -msgstr "タスクに YAML 構文を使用する場合、そのルールは YAML 規格によって明確に定義されています。" - -#: ../../rst/os_guide/windows_usage.rst:381 -msgid "When using a normal string (without quotes), YAML will not consider the backslash an escape character." -msgstr "通常の文字列 (引用符なし) を使用する場合、YAML はバックスラッシュをエスケープ文字とはみなしません。" - -#: ../../rst/os_guide/windows_usage.rst:384 -msgid "When using single quotes ``'``, YAML will not consider the backslash an escape character." -msgstr "一重引用符 ``'`` を使用する場合、YAML はバックスラッシュをエスケープ文字とはみなしません。" - -#: ../../rst/os_guide/windows_usage.rst:387 -msgid "When using double quotes ``\"``, the backslash is considered an escape character and needs to escaped with another backslash." -msgstr "二重引用符 ``\"`` を使用する場合、バックスラッシュはエスケープ文字と見なされ、別のバックスラッシュでエスケープする必要があります。" - -#: ../../rst/os_guide/windows_usage.rst:390 -msgid "You should only quote strings when it is absolutely necessary or required by YAML, and then use single quotes." -msgstr "文字列を引用するのは、絶対に必要な場合や YAML で要求される場合のみとし、その場合は一重引用符を使用します。" - -#: ../../rst/os_guide/windows_usage.rst:393 -msgid "The YAML specification considers the following `escape sequences `_:" -msgstr "YAML 仕様は、以下の `エスケープシーケンス `_ を考慮します。" - -#: ../../rst/os_guide/windows_usage.rst:395 -msgid "``\\0``, ``\\\\``, ``\\\"``, ``\\_``, ``\\a``, ``\\b``, ``\\e``, ``\\f``, ``\\n``, ``\\r``, ``\\t``, ``\\v``, ``\\L``, ``\\N`` and ``\\P`` -- Single character escape" -msgstr "``\\0``、``\\\\``、``\\\"``、``\\_``、``\\a``、``\\b``、``\\e``、``\\f``、``\\n" -"``、``\\r``、``\\t``、``\\v``、``\\L``、``\\N``、および ``\\P`` -- 一文字のエスケープ" - -#: ../../rst/os_guide/windows_usage.rst:398 -msgid "````, ````, ````, ````, ```` -- Special characters" -msgstr "````、````、````、````、```` -- 特殊文字" - -#: ../../rst/os_guide/windows_usage.rst:401 -#: ../../rst/os_guide/windows_usage.rst:455 -msgid "``\\x..`` -- 2-digit hex escape" -msgstr "``\\x..`` -- 2 桁の 16 進エスケープ" - -#: ../../rst/os_guide/windows_usage.rst:403 -#: ../../rst/os_guide/windows_usage.rst:457 -msgid "``\\u....`` -- 4-digit hex escape" -msgstr "``\\u....`` -- 4 桁の 16 進エスケープ" - -#: ../../rst/os_guide/windows_usage.rst:405 -#: ../../rst/os_guide/windows_usage.rst:459 -msgid "``\\U........`` -- 8-digit hex escape" -msgstr "``\\U........`` -- 8 桁の 16 進エスケープ" - -#: ../../rst/os_guide/windows_usage.rst:407 -msgid "Here are some examples on how to write Windows paths:" -msgstr "Windows パスの記述方法の例を次に示します。" - -#: ../../rst/os_guide/windows_usage.rst:423 -msgid "This is an example which will fail:" -msgstr "これは失敗する例です。" - -#: ../../rst/os_guide/windows_usage.rst:430 -msgid "This example shows the use of single quotes when they are required:" -msgstr "この例は、必要な場合の一重引用符の使用を示しています。" - -#: ../../rst/os_guide/windows_usage.rst:441 -msgid "Legacy key=value Style" -msgstr "従来の key=value スタイル" - -#: ../../rst/os_guide/windows_usage.rst:442 -msgid "The legacy ``key=value`` syntax is used on the command line for ad hoc commands, or inside playbooks. The use of this style is discouraged within playbooks because backslash characters need to be escaped, making playbooks harder to read. The legacy syntax depends on the specific implementation in Ansible, and quoting (both single and double) does not have any effect on how it is parsed by Ansible." -msgstr "従来の ``key=value`` の構文は、コマンドラインでのアドホックなコマンドや Playbook 内で使用されます。バックスラッシュ文字をエスケープする必要があり、Playbook が読みづらくなるため、Playbook 内ではこのスタイルの使用は推奨されません。従来の構文は、Ansible の特定の実装に依存しており、引用符 (単一および二重) は、Ansible での解析方法には影響しません。" - -#: ../../rst/os_guide/windows_usage.rst:449 -msgid "The Ansible key=value parser parse_kv() considers the following escape sequences:" -msgstr "Ansible の key=value パーサー parse_kv() は、以下のエスケープシーケンスを考慮します。" - -#: ../../rst/os_guide/windows_usage.rst:452 -msgid "``\\``, ``'``, ``\"``, ``\\a``, ``\\b``, ``\\f``, ``\\n``, ``\\r``, ``\\t`` and ``\\v`` -- Single character escape" -msgstr "``\\``、``'``、``\"``、``\\a``、``\\b``、``\\f``、``\\n" -"``、``\\r``、``\\t``、および ``\\v`` -- 一文字のエスケープ" - -#: ../../rst/os_guide/windows_usage.rst:461 -msgid "``\\N{...}`` -- Unicode character by name" -msgstr "``\\N{...}`` -- 名前による Unicode 文字" - -#: ../../rst/os_guide/windows_usage.rst:463 -msgid "This means that the backslash is an escape character for some sequences, and it is usually safer to escape a backslash when in this form." -msgstr "これは、バックスラッシュがいくつかのシーケンスのエスケープ文字になっていることを意味しており、通常、この形式の場合はバックスラッシュをエスケープする方が安全です。" - -#: ../../rst/os_guide/windows_usage.rst:466 -msgid "Here are some examples of using Windows paths with the key=value style:" -msgstr "key=value スタイルで Windows パスを使用する例を次に示します。" - -#: ../../rst/os_guide/windows_usage.rst:488 -msgid "The failing examples don't fail outright but will substitute ``\\t`` with the ```` character resulting in ``tempdir`` being ``C:\\Windowsemp``." -msgstr "失敗した例では、完全に失敗するわけではありませんが、``\\t`` を ```` の文字で置き換えて、``tempdir`` を ``C:\\Windowsemp`` にします。" - -#: ../../rst/os_guide/windows_usage.rst:492 -msgid "Limitations" -msgstr "制限事項" - -#: ../../rst/os_guide/windows_usage.rst:493 -msgid "Some things you cannot do with Ansible and Windows are:" -msgstr "ここでは、Ansible および Windows でできないことを説明します。" - -#: ../../rst/os_guide/windows_usage.rst:495 -msgid "Upgrade PowerShell" -msgstr "PowerShell のアップグレード" - -#: ../../rst/os_guide/windows_usage.rst:497 -msgid "Interact with the WinRM listeners" -msgstr "WinRM リスナーとの対話" - -#: ../../rst/os_guide/windows_usage.rst:499 -msgid "Because WinRM is reliant on the services being online and running during normal operations, you cannot upgrade PowerShell or interact with WinRM listeners with Ansible. Both of these actions will cause the connection to fail. This can technically be avoided by using ``async`` or a scheduled task, but those methods are fragile if the process it runs breaks the underlying connection Ansible uses, and are best left to the bootstrapping process or before an image is created." -msgstr "WinRM は、通常の運用時にサービスがオンラインで稼働していることに依存しているため、PowerShell をアップグレードしたり、Ansible で WinRM リスナーと対話したりすることはできません。これらのアクションはいずれも、接続の失敗を引き起こします。これは、技術的には ``async`` やスケジュールされたタスクを使用することで回避できますが、これらの方法は、実行するプロセスによって Ansible が使用する基礎的な接続が壊れると脆弱になるため、ブートストラッププロセスやイメージが作成される前に任せるのが最適です。" - -#: ../../rst/os_guide/windows_usage.rst:503 -msgid "Developing Windows Modules" -msgstr "Windows モジュールの開発" - -#: ../../rst/os_guide/windows_usage.rst:504 -msgid "Because Ansible modules for Windows are written in PowerShell, the development guides for Windows modules differ substantially from those for standard standard modules. Please see :ref:`developing_modules_general_windows` for more information." -msgstr "Windows 用の Ansible モジュールは PowerShell で書かれているため、Windows モジュールの開発ガイドは標準規格のモジュールの開発ガイドとは大きく異なります。詳細は、「:ref:`developing_modules_general_windows`」を参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:4 -msgid "Windows Remote Management" -msgstr "Windows リモート管理" - -#: ../../rst/os_guide/windows_winrm.rst:5 -msgid "Unlike Linux/Unix hosts, which use SSH by default, Windows hosts are configured with WinRM. This topic covers how to configure and use WinRM with Ansible." -msgstr "デフォルトで SSH を使用する Linux/Unix ホストとは異なり、Windows ホストは WinRM で設定されています。このトピックでは、Ansible で WinRM を設定し、使用する方法を説明します。" - -#: ../../rst/os_guide/windows_winrm.rst:14 -msgid "What is WinRM?" -msgstr "WinRM とは" - -#: ../../rst/os_guide/windows_winrm.rst:16 -msgid "WinRM is a management protocol used by Windows to remotely communicate with another server. It is a SOAP-based protocol that communicates over HTTP/HTTPS, and is included in all recent Windows operating systems. Since Windows Server 2012, WinRM has been enabled by default, but in most cases extra configuration is required to use WinRM with Ansible." -msgstr "WinRM は、Windows が別のサーバーとリモートで通信する際に使用する管理プロトコルです。WinRM は、HTTP/HTTPS で通信する SOAP ベースのプロトコルで、最近のすべての Windows OS に搭載されています。Windows Server 2012 以降、WinRM はデフォルトで有効になっていますが、ほとんどの場合は、Ansible で WinRM を使用するには追加の設定が必要です。" - -#: ../../rst/os_guide/windows_winrm.rst:22 -msgid "Ansible uses the `pywinrm `_ package to communicate with Windows servers over WinRM. It is not installed by default with the Ansible package, but can be installed by running the following:" -msgstr "Ansible は `pywinrm `_ パッケージを使用して、WinRM を介して Windows サーバーと通信します。デフォルトでは Ansible パッケージとともにインストールされませんが、以下を実行することでインストールできます。" - -#: ../../rst/os_guide/windows_winrm.rst:30 -msgid "on distributions with multiple python versions, use pip2 or pip2.x, where x matches the python minor version Ansible is running under." -msgstr "複数の python バージョンがあるディストリビューションでは、pip2 または pip2.x を使用します。x は、Ansible を実行している python マイナーバージョンと一致します。" - -#: ../../rst/os_guide/windows_winrm.rst:34 -msgid "Using the ``winrm`` or ``psrp`` connection plugins in Ansible on MacOS in the latest releases typically fail. This is a known problem that occurs deep within the Python stack and cannot be changed by Ansible. The only workaround today is to set the environment variable ``no_proxy=*`` and avoid using Kerberos auth." -msgstr "最新リリースの MacOS 上の Ansible で、connection プラグイン ``winrm`` または ``psrp`` を使用すると、通常は失敗します。これは、Python スタックの奥深くで発生する既知の問題であり、Ansible では変更できません。現在の唯一の回避策は、環境変数 ``no_proxy=*`` を設定し、Kerberos 認証を使用しないようにしてください。" - -#: ../../rst/os_guide/windows_winrm.rst:44 -msgid "WinRM authentication options" -msgstr "WinRM 認証オプション" - -#: ../../rst/os_guide/windows_winrm.rst:46 -msgid "When connecting to a Windows host, there are several different options that can be used when authenticating with an account. The authentication type may be set on inventory hosts or groups with the ``ansible_winrm_transport`` variable." -msgstr "Windows ホストに接続する際、アカウントで認証する際に使用できるいくつかの異なるオプションがあります。認証タイプは、インベントリーのホストまたはグループに ``ansible_winrm_transport`` 変数で設定できます。" - -#: ../../rst/os_guide/windows_winrm.rst:50 -msgid "The following matrix is a high level overview of the options:" -msgstr "以下のマトリックスは、オプションの概要を示しています。" - -#: ../../rst/os_guide/windows_winrm.rst:53 -msgid "Option" -msgstr "オプション" - -#: ../../rst/os_guide/windows_winrm.rst:53 -msgid "Local Accounts" -msgstr "ローカルアカウント" - -#: ../../rst/os_guide/windows_winrm.rst:53 -msgid "Active Directory Accounts" -msgstr "Active Directory アカウント" - -#: ../../rst/os_guide/windows_winrm.rst:53 -msgid "Credential Delegation" -msgstr "認証情報の委譲" - -#: ../../rst/os_guide/windows_winrm.rst:53 -msgid "HTTP Encryption" -msgstr "HTTP 暗号化" - -#: ../../rst/os_guide/windows_winrm.rst:55 -#: ../../rst/os_guide/windows_winrm.rst:69 -msgid "Basic" -msgstr "基本" - -#: ../../rst/os_guide/windows_winrm.rst:55 -#: ../../rst/os_guide/windows_winrm.rst:57 -#: ../../rst/os_guide/windows_winrm.rst:59 -#: ../../rst/os_guide/windows_winrm.rst:61 -#: ../../rst/os_guide/windows_winrm.rst:63 -msgid "Yes" -msgstr "可" - -#: ../../rst/os_guide/windows_winrm.rst:55 -#: ../../rst/os_guide/windows_winrm.rst:57 -#: ../../rst/os_guide/windows_winrm.rst:59 -#: ../../rst/os_guide/windows_winrm.rst:61 -msgid "No" -msgstr "不可" - -#: ../../rst/os_guide/windows_winrm.rst:57 -#: ../../rst/os_guide/windows_winrm.rst:96 -msgid "Certificate" -msgstr "証明書" - -#: ../../rst/os_guide/windows_winrm.rst:59 -#: ../../rst/os_guide/windows_winrm.rst:302 -msgid "Kerberos" -msgstr "Kerberos" - -#: ../../rst/os_guide/windows_winrm.rst:61 -#: ../../rst/os_guide/windows_winrm.rst:272 -msgid "NTLM" -msgstr "NTLM" - -#: ../../rst/os_guide/windows_winrm.rst:63 -#: ../../rst/os_guide/windows_winrm.rst:517 -msgid "CredSSP" -msgstr "CredSSP" - -#: ../../rst/os_guide/windows_winrm.rst:71 -msgid "Basic authentication is one of the simplest authentication options to use, but is also the most insecure. This is because the username and password are simply base64 encoded, and if a secure channel is not in use (eg, HTTPS) then it can be decoded by anyone. Basic authentication can only be used for local accounts (not domain accounts)." -msgstr "Basic 認証は、最もシンプルな認証方法の 1 つですが、安全性が最も低くなります。これは、ユーザー名およびパスワードが単純に Base64 エンコードされているためで、安全なチャンネル (例: HTTPS) が使用されていない場合は、誰でも解読することができます。Basic 認証は、ローカルアカウントにのみ使用することができます (ドメインアカウントには使用できません)。" - -#: ../../rst/os_guide/windows_winrm.rst:76 -msgid "The following example shows host vars configured for basic authentication:" -msgstr "以下の例は、基本認証に設定されているホスト変数を示しています。" - -#: ../../rst/os_guide/windows_winrm.rst:85 -msgid "Basic authentication is not enabled by default on a Windows host but can be enabled by running the following in PowerShell:" -msgstr "Basic 認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" - -#: ../../rst/os_guide/windows_winrm.rst:98 -msgid "Certificate authentication uses certificates as keys similar to SSH key pairs, but the file format and key generation process is different." -msgstr "証明書認証は、SSH キーペアに似た鍵として証明書を使用しますが、ファイル形式と鍵の生成プロセスは異なります。" - -#: ../../rst/os_guide/windows_winrm.rst:101 -msgid "The following example shows host vars configured for certificate authentication:" -msgstr "以下の例では、証明書認証に設定されているホスト変数を示しています。" - -#: ../../rst/os_guide/windows_winrm.rst:110 -msgid "Certificate authentication is not enabled by default on a Windows host but can be enabled by running the following in PowerShell:" -msgstr "証明書認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" - -#: ../../rst/os_guide/windows_winrm.rst:117 -msgid "Encrypted private keys cannot be used as the urllib3 library that is used by Ansible for WinRM does not support this functionality." -msgstr "WinRM 向けに Ansible が使用する urllib3 ライブラリーがこの機能をサポートしていないため、暗号化された秘密鍵は使用できません。" - -#: ../../rst/os_guide/windows_winrm.rst:120 -msgid "Certificate authentication does not work with a TLS 1.3 connection." -msgstr "証明書認証は、TLS 1.3 接続では機能しません。" - -#: ../../rst/os_guide/windows_winrm.rst:122 -msgid ".._winrm_certificate_generate:" -msgstr ".._winrm_certificate_generate:" - -#: ../../rst/os_guide/windows_winrm.rst:125 -msgid "Generate a Certificate" -msgstr "証明書の生成" - -#: ../../rst/os_guide/windows_winrm.rst:127 -msgid "A certificate must be generated before it can be mapped to a local user. This can be done using one of the following methods:" -msgstr "証明書をローカルユーザーにマッピングする前に、証明書を生成する必要があります。これは、以下のいずれかの方法で行うことができます。" - -#: ../../rst/os_guide/windows_winrm.rst:130 -msgid "OpenSSL" -msgstr "OpenSSL" - -#: ../../rst/os_guide/windows_winrm.rst:131 -msgid "PowerShell, using the ``New-SelfSignedCertificate`` cmdlet" -msgstr "``New-SelfSignedCertificate`` コマンドレットを使用した PowerShell" - -#: ../../rst/os_guide/windows_winrm.rst:132 -msgid "Active Directory Certificate Services" -msgstr "Active Directory 証明書サービス" - -#: ../../rst/os_guide/windows_winrm.rst:134 -msgid "Active Directory Certificate Services is beyond of scope in this documentation but may be the best option to use when running in a domain environment. For more information, see the `Active Directory Certificate Services documentation `_." -msgstr "Active Directory Certificate Services は、このドキュメントでは対象外になりますが、ドメイン環境で実行する場合には、最適なオプションになるかもしれません。詳細は、`Active Directory Certificate Services のドキュメント `_ を参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:138 -msgid "Using the PowerShell cmdlet ``New-SelfSignedCertificate`` to generate a certificate for authentication only works when being generated from a Windows 10 or Windows Server 2012 R2 host or later. OpenSSL is still required to extract the private key from the PFX certificate to a PEM file for Ansible to use." -msgstr "PowerShell コマンドレット (``New-SelfSignedCertificate``) を使用して認証用の証明書を生成する場合は、Windows 10 または Windows Server 2012 R2 ホスト以降から生成された場合にのみ機能します。PFX 証明書から Ansible が使用する PEM ファイルに秘密鍵を抽出するには、OpenSSL が引き続き必要となります。" - -#: ../../rst/os_guide/windows_winrm.rst:144 -msgid "To generate a certificate with ``OpenSSL``:" -msgstr "``OpenSSL`` で証明書を生成するには、以下を実行します。" - -#: ../../rst/os_guide/windows_winrm.rst:164 -msgid "To generate a certificate with ``New-SelfSignedCertificate``:" -msgstr "``New-SelfSignedCertificate`` で証明書を生成するには、以下を実行します。" - -#: ../../rst/os_guide/windows_winrm.rst:192 -msgid "To convert the PFX file to a private key that pywinrm can use, run the following command with OpenSSL ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:``" -msgstr "PFX ファイルを pywinrm が使用できる秘密鍵に変換するには、OpenSSL で ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:`` コマンドを実行します。" - -#: ../../rst/os_guide/windows_winrm.rst:199 -msgid "Import a Certificate to the Certificate Store" -msgstr "証明書ストアへの証明書のインポート" - -#: ../../rst/os_guide/windows_winrm.rst:201 -msgid "Once a certificate has been generated, the issuing certificate needs to be imported into the ``Trusted Root Certificate Authorities`` of the ``LocalMachine`` store, and the client certificate public key must be present in the ``Trusted People`` folder of the ``LocalMachine`` store. For this example, both the issuing certificate and public key are the same." -msgstr "証明書が生成されたら、発行した証明書を ``LocalMachine`` ストアの ``Trusted Root Certificate Authorities`` にインポートし、クライアント証明書の公開鍵を ``LocalMachine`` ストアの ``Trusted People`` ディレクトリーに存在させる必要があります。この例では、発行した証明書と公開鍵の両方が同じものです。" - -#: ../../rst/os_guide/windows_winrm.rst:207 -msgid "Following example shows how to import the issuing certificate:" -msgstr "以下の例では、発行した証明書をインポートする方法を示します。" - -#: ../../rst/os_guide/windows_winrm.rst:221 -msgid "If using ADCS to generate the certificate, then the issuing certificate will already be imported and this step can be skipped." -msgstr "ADCS を使用して証明書を生成する場合は、発行する証明書がすでにインポートされているため、この手順は省略できます。" - -#: ../../rst/os_guide/windows_winrm.rst:224 -msgid "The code to import the client certificate public key is:" -msgstr "クライアント証明書の公開鍵をインポートするコードは以下のとおりです。" - -#: ../../rst/os_guide/windows_winrm.rst:241 -msgid "Mapping a Certificate to an Account" -msgstr "証明書のアカウントへのマッピング" - -#: ../../rst/os_guide/windows_winrm.rst:243 -msgid "Once the certificate has been imported, map it to the local user account:" -msgstr "証明書をインポートしたら、これをローカルユーザーアカウントにマッピングします。" - -#: ../../rst/os_guide/windows_winrm.rst:264 -msgid "Once this is complete, the hostvar ``ansible_winrm_cert_pem`` should be set to the path of the public key and the ``ansible_winrm_cert_key_pem`` variable should be set to the path of the private key." -msgstr "これが完了したら、ホスト変数 ``ansible_winrm_cert_pem`` に公開鍵のパスを設定し、変数``ansible_winrm_cert_key_pem`` に秘密鍵のパスを設定してください。" - -#: ../../rst/os_guide/windows_winrm.rst:274 -msgid "NTLM is an older authentication mechanism used by Microsoft that can support both local and domain accounts. NTLM is enabled by default on the WinRM service, so no setup is required before using it." -msgstr "NTLM は、Microsoft が使用している古い認証メカニズムで、ローカルアカウントとドメインアカウントの両方をサポートしています。NTLM は、WinRM サービスでデフォルトで有効になっているため、使用する前に設定する必要はありません。" - -#: ../../rst/os_guide/windows_winrm.rst:278 -msgid "NTLM is the easiest authentication protocol to use and is more secure than ``Basic`` authentication. If running in a domain environment, ``Kerberos`` should be used instead of NTLM." -msgstr "NTLM は最も簡単に使用できる認証プロトコルであり、``Basic`` 認証よりも安全です。ドメイン環境で稼働している場合は、NTLM の代わりに ``Kerberos`` を使用する必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:282 -msgid "Kerberos has several advantages over using NTLM:" -msgstr "Kerberos は NTLM の使用と比較して、以下のような利点があります。" - -#: ../../rst/os_guide/windows_winrm.rst:284 -msgid "NTLM is an older protocol and does not support newer encryption protocols." -msgstr "NTLM は古いプロトコルであり、新しい暗号化プロトコルをサポートしません。" - -#: ../../rst/os_guide/windows_winrm.rst:286 -msgid "NTLM is slower to authenticate because it requires more round trips to the host in the authentication stage." -msgstr "NTLM は、認証の段階でホストへのラウンドトリップが多くなるため、認証に時間がかかります。" - -#: ../../rst/os_guide/windows_winrm.rst:288 -msgid "Unlike Kerberos, NTLM does not allow credential delegation." -msgstr "Kerberos とは異なり、NTLM は認証情報の委譲を許可していません。" - -#: ../../rst/os_guide/windows_winrm.rst:290 -msgid "This example shows host variables configured to use NTLM authentication:" -msgstr "以下の例では、NTLM 認証を使用するように設定されているホスト変数を示しています。" - -#: ../../rst/os_guide/windows_winrm.rst:304 -msgid "Kerberos is the recommended authentication option to use when running in a domain environment. Kerberos supports features like credential delegation and message encryption over HTTP and is one of the more secure options that is available through WinRM." -msgstr "Kerberos は、ドメイン環境で実行する場合に使用する推奨の認証オプションです。Kerberos は、認証情報の委譲や HTTP でのメッセージ暗号化などの機能をサポートしており、WinRM で利用できるより安全なオプションの 1 つです。" - -#: ../../rst/os_guide/windows_winrm.rst:309 -msgid "Kerberos requires some additional setup work on the Ansible host before it can be used properly." -msgstr "Kerberos を正しく使用するには、Ansible ホスト上でいくつかの追加設定作業が必要です。" - -#: ../../rst/os_guide/windows_winrm.rst:312 -msgid "The following example shows host vars configured for Kerberos authentication:" -msgstr "以下の例は、Kerberos 認証に設定されたホスト変数を示しています。" - -#: ../../rst/os_guide/windows_winrm.rst:322 -msgid "As of Ansible version 2.3, the Kerberos ticket will be created based on ``ansible_user`` and ``ansible_password``. If running on an older version of Ansible or when ``ansible_winrm_kinit_mode`` is ``manual``, a Kerberos ticket must already be obtained. See below for more details." -msgstr "Ansible バージョン 2.3 以降では、``ansible_user`` と ``ansible_password`` に基づいて Kerberos チケットが作成されます。古いバージョンの Ansible で実行している場合や、``ansible_winrm_kinit_mode`` が ``manual`` の場合は、すでに Kerberos チケットを取得している必要があります。詳細は以下を参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:327 -msgid "There are some extra host variables that can be set:" -msgstr "設定可能な追加のホスト変数があります。" - -#: ../../rst/os_guide/windows_winrm.rst:340 -msgid "Installing the Kerberos Library" -msgstr "Kerberos ライブラリーのインストール" - -#: ../../rst/os_guide/windows_winrm.rst:342 -msgid "Some system dependencies that must be installed prior to using Kerberos. The script below lists the dependencies based on the distro:" -msgstr "Kerberos を使用する前にインストールする必要があるシステム依存関係があります。以下のスクリプトは、ディストリビューションに基づく依存関係を一覧表示します。" - -#: ../../rst/os_guide/windows_winrm.rst:371 -msgid "Once the dependencies have been installed, the ``python-kerberos`` wrapper can be install using ``pip``:" -msgstr "依存関係がインストールされたら、``pip`` を使用して ``python-kerberos`` ラッパーをインストールできます。" - -#: ../../rst/os_guide/windows_winrm.rst:380 -msgid "While Ansible has supported Kerberos auth through ``pywinrm`` for some time, optional features or more secure options may only be available in newer versions of the ``pywinrm`` and/or ``pykerberos`` libraries. It is recommended you upgrade each version to the latest available to resolve any warnings or errors. This can be done through tools like ``pip`` or a system package manager like ``dnf``, ``yum``, ``apt`` but the package names and versions available may differ between tools." -msgstr "Ansible はこれまで、``pywinrm`` を通じて Kerberos 認証をサポートしてきましたが、オプション機能やより安全なオプションは、``pywinrm`` ライブラリーまたは ``pykerberos`` ライブラリーの新しいバージョンでのみ利用できる場合があります。警告やエラーが発生した場合は、各バージョンを最新のものにアップグレードすることが推奨されます。この作業は、``pip`` のようなツールや、``dnf``、``yum``、``apt`` のようなシステムパッケージマネージャーで行うことができますが、パッケージ名や利用可能なバージョンはツールによって異なる場合があります。" - -#: ../../rst/os_guide/windows_winrm.rst:392 -msgid "Configuring Host Kerberos" -msgstr "ホスト Kerberos の設定" - -#: ../../rst/os_guide/windows_winrm.rst:394 -msgid "Once the dependencies have been installed, Kerberos needs to be configured so that it can communicate with a domain. This configuration is done through the ``/etc/krb5.conf`` file, which is installed with the packages in the script above." -msgstr "依存関係がインストールされたら、Kerberos がドメインと通信できるように設定する必要があります。この設定は、上のスクリプトでパッケージと一緒にインストールされた ``/etc/krb5.conf`` ファイルを通じて行われます。" - -#: ../../rst/os_guide/windows_winrm.rst:398 -msgid "To configure Kerberos, in the section that starts with:" -msgstr "Kerberos を設定するには、以下で始まるセクションで行います。" - -#: ../../rst/os_guide/windows_winrm.rst:404 -msgid "Add the full domain name and the fully qualified domain names of the primary and secondary Active Directory domain controllers. It should look something like this:" -msgstr "プライマリーおよびセカンダリーの Active Directory ドメインコントローラーの完全ドメイン名および完全修飾ドメイン名を追加します。以下のようになるはずです。" - -#: ../../rst/os_guide/windows_winrm.rst:416 -msgid "In the section that starts with:" -msgstr "以下で始まるセクションで、" - -#: ../../rst/os_guide/windows_winrm.rst:422 -msgid "Add a line like the following for each domain that Ansible needs access for:" -msgstr "Ansible がアクセスする必要のある各ドメインに以下のような行を追加します。" - -#: ../../rst/os_guide/windows_winrm.rst:429 -msgid "You can configure other settings in this file such as the default domain. See `krb5.conf `_ for more details." -msgstr "このファイルでは、デフォルトのドメインなど、その他の設定を行うことができます。詳細は `krb5.conf `_ を参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:436 -msgid "Automatic Kerberos Ticket Management" -msgstr "Kerberos チケットの自動管理" - -#: ../../rst/os_guide/windows_winrm.rst:438 -msgid "Ansible version 2.3 and later defaults to automatically managing Kerberos tickets when both ``ansible_user`` and ``ansible_password`` are specified for a host. In this process, a new ticket is created in a temporary credential cache for each host. This is done before each task executes to minimize the chance of ticket expiration. The temporary credential caches are deleted after each task completes and will not interfere with the default credential cache." -msgstr "Ansible バージョン 2.3 以降では、ホストに ``ansible_user`` および ``ansible_password`` の両方が指定された場合は、デフォルトで Kerberos チケットを自動的に管理します。このプロセスでは、各ホストの一時的な認証情報キャッシュに新しいチケットが作成されます。これは、チケットが失効する可能性を最小限にするために、各タスクが実行される前に行われます。一時的な認証情報キャッシュは、各タスクが完了すると削除され、デフォルトの認証情報キャッシュに干渉することはありません。" - -#: ../../rst/os_guide/windows_winrm.rst:445 -msgid "To disable automatic ticket management, set ``ansible_winrm_kinit_mode=manual`` through the inventory." -msgstr "チケットの自動管理を無効にするには、インベントリーから ``ansible_winrm_kinit_mode=manual`` を設定してください。" - -#: ../../rst/os_guide/windows_winrm.rst:448 -msgid "Automatic ticket management requires a standard ``kinit`` binary on the control host system path. To specify a different location or binary name, set the ``ansible_winrm_kinit_cmd`` hostvar to the fully qualified path to a MIT krbv5 ``kinit``-compatible binary." -msgstr "自動チケット管理には、制御ホストシステムのパスに標準の ``kinit`` バイナリーが必要です。別の場所やバイナリー名を指定するには、ホスト変数 ``ansible_winrm_kinit_cmd`` に MIT krbv5 ``kinit`` 互換バイナリーへの完全修飾パスを設定します。" - -#: ../../rst/os_guide/windows_winrm.rst:456 -msgid "Manual Kerberos Ticket Management" -msgstr "Kerberos チケットの手動管理" - -#: ../../rst/os_guide/windows_winrm.rst:458 -msgid "To manually manage Kerberos tickets, the ``kinit`` binary is used. To obtain a new ticket the following command is used:" -msgstr "Kerberos チケットを手動で管理するには、``kinit`` バイナリーを使用します。新しいチケットを取得するには、以下のコマンドを使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:465 -msgid "The domain must match the configured Kerberos realm exactly, and must be in upper case." -msgstr "ドメインは設定された Kerberos レルムに完全に一致し、大文字である必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:467 -msgid "To see what tickets (if any) have been acquired, use the following command:" -msgstr "取得したチケット (存在する場合) を確認するには、以下のコマンドを使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:473 -msgid "To destroy all the tickets that have been acquired, use the following command:" -msgstr "取得したすべてのチケットを破棄するには、以下のコマンドを使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:482 -msgid "Troubleshooting Kerberos" -msgstr "Kerberos のトラブルシューティング" - -#: ../../rst/os_guide/windows_winrm.rst:484 -msgid "Kerberos is reliant on a properly-configured environment to work. To troubleshoot Kerberos issues, ensure that:" -msgstr "Kerberos は、適切に構成された環境でなければ動作しません。Kerberos の問題をトラブルシューティングするには、以下を確認してください。" - -#: ../../rst/os_guide/windows_winrm.rst:487 -msgid "The hostname set for the Windows host is the FQDN and not an IP address. * If you connect using an IP address you will get the error message `Server not found in Kerberos database`. * To determine if you are connecting using an IP address or an FQDN run your playbook (or call the ``win_ping`` module) using the `-vvv` flag." -msgstr "Windows ホストに設定されたホスト名は FQDN であり、IP アドレスではありません。* IP アドレスを使用して接続する場合は、エラーメッセージ `Server not found in Kerberos database` が表示されます。* IP アドレスまたは FQDN を使用して接続している場合は、`-vvv` フラグを使用して Playbook を実行するか、``win_ping`` モジュールを呼び出します。" - -#: ../../rst/os_guide/windows_winrm.rst:491 -msgid "The forward and reverse DNS lookups are working properly in the domain. To test this, ping the windows host by name and then use the ip address returned with ``nslookup``. The same name should be returned when using ``nslookup`` on the IP address." -msgstr "このドメインでは、DNS の正引きと逆引きが正常に動作しています。これをテストするには、Windows ホストに名前で ping を打ち、``nslookup`` で返された IP アドレスを使用します。IP アドレスに ``nslookup`` を使用すると、同じ名前が返されるはずです。" - -#: ../../rst/os_guide/windows_winrm.rst:496 -msgid "The Ansible host's clock is synchronized with the domain controller. Kerberos is time sensitive, and a little clock drift can cause the ticket generation process to fail." -msgstr "Ansible ホストの時計はドメインコントローラーと同期します。Kerberos は時間に敏感で、わずかな時計のずれにより、チケット生成プロセスが失敗する可能性があります。" - -#: ../../rst/os_guide/windows_winrm.rst:500 -msgid "Ensure that the fully qualified domain name for the domain is configured in the ``krb5.conf`` file. To check this, run:" -msgstr "ドメインの完全修飾ドメイン名が、``krb5.conf`` ファイルに設定されていることを確認してください。これを確認するには、次を実行します。" - -#: ../../rst/os_guide/windows_winrm.rst:508 -msgid "If the domain name returned by ``klist`` is different from the one requested, an alias is being used. The ``krb5.conf`` file needs to be updated so that the fully qualified domain name is used and not an alias." -msgstr "``klist`` で返されたドメイン名が要求されたものと異なる場合は、エイリアスが使用されています。``krb5.conf`` ファイルを更新して、エイリアスではなく完全修飾ドメイン名を使用する必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:512 -msgid "If the default kerberos tooling has been replaced or modified (some IdM solutions may do this), this may cause issues when installing or upgrading the Python Kerberos library. As of the time of this writing, this library is called ``pykerberos`` and is known to work with both MIT and Heimdal Kerberos libraries. To resolve ``pykerberos`` installation issues, ensure the system dependencies for Kerberos have been met (see: `Installing the Kerberos Library`_), remove any custom Kerberos tooling paths from the PATH environment variable, and retry the installation of Python Kerberos library package." -msgstr "デフォルトの kerberos ツールが置き換えられたり変更したりした場合 (いくつかの IdM ソリューションではそうなっているかもしれません)、Python Kerberos ライブラリーをインストールしたりアップグレードしたりする際に問題が発生する可能性があります。本ガイドの作成時点で、このライブラリーは ``pykerberos`` と呼ばれ、MIT と Heimdal Kerberos ライブラリーの両方で動作することが知られています。``pykerberos`` のインストール問題を解決するには、Kerberos のシステム依存性が満たされていることを確認し (参照: `Installing the Kerberos Library`_)、PATH 環境変数からカスタムの Kerberos ツールパスを削除し、Python Kerberos ライブラリーパッケージのインストールを再試行してください。" - -#: ../../rst/os_guide/windows_winrm.rst:519 -msgid "CredSSP authentication is a newer authentication protocol that allows credential delegation. This is achieved by encrypting the username and password after authentication has succeeded and sending that to the server using the CredSSP protocol." -msgstr "CredSSP 認証は、認証情報の委譲を可能にする新しい認証プロトコルになります。これは、認証が成功した後のユーザー名とパスワードを暗号化し、それを CredSSP プロトコルを使用してサーバーに送信することで実現しています。" - -#: ../../rst/os_guide/windows_winrm.rst:524 -msgid "Because the username and password are sent to the server to be used for double hop authentication, ensure that the hosts that the Windows host communicates with are not compromised and are trusted." -msgstr "ユーザー名とパスワードをサーバーに送信してダブルホップ認証に使用するため、Windows ホストが通信するホストが漏洩しておらず、信頼できることを確認してください。" - -#: ../../rst/os_guide/windows_winrm.rst:528 -msgid "CredSSP can be used for both local and domain accounts and also supports message encryption over HTTP." -msgstr "CredSSP は、ローカルアカウントとドメインアカウントの両方に使用でき、HTTPでのメッセージ暗号化にも対応しています。" - -#: ../../rst/os_guide/windows_winrm.rst:531 -msgid "To use CredSSP authentication, the host vars are configured like so:" -msgstr "CredSSP 認証を使用するには、以下のようにホスト変数を設定します。" - -#: ../../rst/os_guide/windows_winrm.rst:540 -msgid "There are some extra host variables that can be set as shown below:" -msgstr "以下のように設定できる追加のホスト変数があります。" - -#: ../../rst/os_guide/windows_winrm.rst:546 -msgid "CredSSP authentication is not enabled by default on a Windows host, but can be enabled by running the following in PowerShell:" -msgstr "CredSSP 認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" - -#: ../../rst/os_guide/windows_winrm.rst:556 -msgid "Installing CredSSP Library" -msgstr "CredSSP ライブラリーのインストール" - -#: ../../rst/os_guide/windows_winrm.rst:558 -msgid "The ``requests-credssp`` wrapper can be installed using ``pip``:" -msgstr "``requests-credssp`` ラッパーは、``pip`` を使用してインストールできます。" - -#: ../../rst/os_guide/windows_winrm.rst:567 -msgid "CredSSP and TLS 1.2" -msgstr "CredSSP および TLS 1.2" - -#: ../../rst/os_guide/windows_winrm.rst:569 -msgid "By default the ``requests-credssp`` library is configured to authenticate over the TLS 1.2 protocol. TLS 1.2 is installed and enabled by default for Windows Server 2012 and Windows 8 and more recent releases." -msgstr "デフォルトでは、``requests-credssp`` ライブラリーは、TLS 1.2 プロトコルで認証するように設定されています。TLS 1.2 は、Windows Server 2012 および Windows 8 と、それ以降のリリースでは、デフォルトでインストールされ、有効になっています。" - -#: ../../rst/os_guide/windows_winrm.rst:573 -msgid "There are two ways that older hosts can be used with CredSSP:" -msgstr "古いホストを CredSSP で使用できる方法は 2 つあります。" - -#: ../../rst/os_guide/windows_winrm.rst:575 -msgid "Install and enable a hotfix to enable TLS 1.2 support (recommended for Server 2008 R2 and Windows 7)." -msgstr "TLS 1.2 のサポートを有効にする Hotfix をインストールして有効にしてください (Server 2008 R2 および Windows 7 で推奨)。" - -#: ../../rst/os_guide/windows_winrm.rst:578 -msgid "Set ``ansible_winrm_credssp_disable_tlsv1_2=True`` in the inventory to run over TLS 1.0. This is the only option when connecting to Windows Server 2008, which has no way of supporting TLS 1.2" -msgstr "インベントリーに ``ansible_winrm_credssp_disable_tlsv1_2=True`` を設定して、TLS 1.0 で実行するように設定します。これは、TLS 1.2 に対応していない Windows Server 2008 に接続する際の唯一の選択肢です。" - -#: ../../rst/os_guide/windows_winrm.rst:582 -msgid "See :ref:`winrm_tls12` for more information on how to enable TLS 1.2 on the Windows host." -msgstr "Windows ホストで TLS 1.2 を有効にする方法は、「:ref:`winrm_tls12`」を参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:588 -msgid "Set CredSSP Certificate" -msgstr "CredSSP 証明書の設定" - -#: ../../rst/os_guide/windows_winrm.rst:590 -msgid "CredSSP works by encrypting the credentials through the TLS protocol and uses a self-signed certificate by default. The ``CertificateThumbprint`` option under the WinRM service configuration can be used to specify the thumbprint of another certificate." -msgstr "CredSSP は、TLS プロトコルで認証情報を暗号化して動作し、デフォルトでは自己署名証明書を使用します。WinRM サービス構成の ``CertificateThumbprint`` オプションを使用して、別の証明書のサムプリントを指定することができます。" - -#: ../../rst/os_guide/windows_winrm.rst:593 -msgid "This certificate configuration is independent of the WinRM listener certificate. With CredSSP, message transport still occurs over the WinRM listener, but the TLS-encrypted messages inside the channel use the service-level certificate." -msgstr "この証明書構成は、WinRM リスナーの証明書とは独立しています。CredSSP では、メッセージトランスポートは引き続き WinRM リスナーを介して行われますが、チャンネル内の TLS 暗号化メッセージにはサービスレベル証明書が使用されます。" - -#: ../../rst/os_guide/windows_winrm.rst:597 -msgid "To explicitly set the certificate to use for CredSSP:" -msgstr "CredSSP に使用する証明書を明示的に設定するには、以下を実行します。" - -#: ../../rst/os_guide/windows_winrm.rst:611 -msgid "Non-Administrator Accounts" -msgstr "管理者以外のアカウント" - -#: ../../rst/os_guide/windows_winrm.rst:613 -msgid "WinRM is configured by default to only allow connections from accounts in the local ``Administrators`` group. This can be changed by running:" -msgstr "WinRM は、デフォルトで、ローカルの ``Administrators`` グループのアカウントからの接続のみを許可するように設定されています。これは、以下を実行して変更できます。" - -#: ../../rst/os_guide/windows_winrm.rst:620 -msgid "This will display an ACL editor, where new users or groups may be added. To run commands over WinRM, users and groups must have at least the ``Read`` and ``Execute`` permissions enabled." -msgstr "これにより、ACL エディターが表示され、新しいユーザーまたはグループを追加できます。WinRM でコマンドを実行するには、ユーザーおよびグループに少なくとも ``Read`` および ``Execute`` パーミッションが有効になっている必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:624 -msgid "While non-administrative accounts can be used with WinRM, most typical server administration tasks require some level of administrative access, so the utility is usually limited." -msgstr "WinRM では、管理者以外のアカウントを使用することもできますが、一般的なサーバー管理作業では、ある程度の管理者権限が必要となるため、実用性は限られてしまいます。" - -#: ../../rst/os_guide/windows_winrm.rst:630 -msgid "WinRM Encryption" -msgstr "WinRM 暗号化" - -#: ../../rst/os_guide/windows_winrm.rst:632 -msgid "By default WinRM will fail to work when running over an unencrypted channel. The WinRM protocol considers the channel to be encrypted if using TLS over HTTP (HTTPS) or using message level encryption. Using WinRM with TLS is the recommended option as it works with all authentication options, but requires a certificate to be created and used on the WinRM listener." -msgstr "デフォルトでは、WinRM は、暗号化されていないチャンネル上で実行すると、動作に失敗します。WinRM プロトコルは、TLS over HTTP (HTTPS) を使用している場合や、メッセージレベルの暗号化を使用している場合は、チャンネルが暗号化されているとみなします。WinRM を TLS で使用することは、すべての認証オプションで動作するため、推奨されるオプションですが、WinRM リスナーで証明書を作成して使用する必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:638 -msgid "If in a domain environment, ADCS can create a certificate for the host that is issued by the domain itself." -msgstr "ドメイン環境の場合、ADCS はドメイン自体が発行するホストの証明書を作成できます。" - -#: ../../rst/os_guide/windows_winrm.rst:641 -msgid "If using HTTPS is not an option, then HTTP can be used when the authentication option is ``NTLM``, ``Kerberos`` or ``CredSSP``. These protocols will encrypt the WinRM payload with their own encryption method before sending it to the server. The message-level encryption is not used when running over HTTPS because the encryption uses the more secure TLS protocol instead. If both transport and message encryption is required, set ``ansible_winrm_message_encryption=always`` in the host vars." -msgstr "HTTPS を使用することができない場合は、認証オプションが ``NTLM``、``Kerberos``、または ``CredSSP`` であれば、HTTP を使用することができます。これらのプロトコルは、WinRM ペイロードを独自の暗号化方式で暗号化してからサーバーに送信します。暗号化は、より安全な TLS プロトコルを代わりに使用するため、HTTPS で実行する場合に、メッセージレベルの暗号化は使用されません。トランスポートとメッセージの両方の暗号化が必要な場合は、ホスト変数に ``ansible_winrm_message_encryption=always`` を設定してください。" - -#: ../../rst/os_guide/windows_winrm.rst:649 -msgid "Message encryption over HTTP requires pywinrm>=0.3.0." -msgstr "HTTPでのメッセージ暗号化には 0.3.0 以上の pywinrm が必要です。" - -#: ../../rst/os_guide/windows_winrm.rst:651 -msgid "A last resort is to disable the encryption requirement on the Windows host. This should only be used for development and debugging purposes, as anything sent from Ansible can be viewed, manipulated and also the remote session can completely be taken over by anyone on the same network. To disable the encryption requirement:" -msgstr "最後の手段として、Windows ホストの暗号化要件を無効にすることができます。これは、Ansible から送信されたものはすべて閲覧、操作でき、また同じネットワーク上の誰もがリモートセッションを完全に乗っ取ることができるため、開発やデバッグの目的でのみ使用してください。暗号化を無効にするには、以下の手順に従います。" - -#: ../../rst/os_guide/windows_winrm.rst:661 -msgid "Do not disable the encryption check unless it is absolutely required. Doing so could allow sensitive information like credentials and files to be intercepted by others on the network." -msgstr "どうしても必要な場合を除き、暗号化チェックを無効にしないでください。暗号化チェックを無効にすると、認証情報やファイルなどの機密情報がネットワーク上の他の人に傍受される可能性があります。" - -#: ../../rst/os_guide/windows_winrm.rst:668 -msgid "Inventory Options" -msgstr "インベントリーオプション" - -#: ../../rst/os_guide/windows_winrm.rst:670 -msgid "Ansible's Windows support relies on a few standard variables to indicate the username, password, and connection type of the remote hosts. These variables are most easily set up in the inventory, but can be set on the ``host_vars``/ ``group_vars`` level." -msgstr "Ansible の Windows サポートは、リモートホストのユーザー名、パスワード、接続タイプを示すいくつかの標準変数に依存しています。これらの変数はインベントリーで最も簡単に設定できますが、``host_vars``/``group_vars`` レベルで設定することもできます。" - -#: ../../rst/os_guide/windows_winrm.rst:675 -msgid "When setting up the inventory, the following variables are required:" -msgstr "インベントリーを設定する際に、以下の変数が必要になります。" - -#: ../../rst/os_guide/windows_winrm.rst:690 -msgid "Using the variables above, Ansible will connect to the Windows host with Basic authentication through HTTPS. If ``ansible_user`` has a UPN value like ``username@MY.DOMAIN.COM`` then the authentication option will automatically attempt to use Kerberos unless ``ansible_winrm_transport`` has been set to something other than ``kerberos``." -msgstr "上記の変数を使用すると、Ansible は HTTPS を通じて Basic 認証で Windows ホストに接続します。``ansible_user`` に ``username@MY.DOMAIN.COM`` のような UPN 値がある場合は、``ansible_winrm_transport`` が ``kerberos`` 以外に設定されていない限り、認証オプションは自動的に Kerberos の使用を試みます。" - -#: ../../rst/os_guide/windows_winrm.rst:696 -msgid "The following custom inventory variables are also supported for additional configuration of WinRM connections:" -msgstr "以下のカスタムインベントリー変数も、WinRM 接続の追加設定のためにサポートされています。" - -#: ../../rst/os_guide/windows_winrm.rst:699 -msgid "``ansible_port``: The port WinRM will run over, HTTPS is ``5986`` which is the default while HTTP is ``5985``" -msgstr "``ansible_port``: WinRM が実行するポートです。HTTPS のデフォルトは ``5986`` で、HTTP のデフォルトは ``5985`` です。" - -#: ../../rst/os_guide/windows_winrm.rst:702 -msgid "``ansible_winrm_scheme``: Specify the connection scheme (``http`` or ``https``) to use for the WinRM connection. Ansible uses ``https`` by default unless ``ansible_port`` is ``5985``" -msgstr "``ansible_winrm_scheme``: WinRM 接続に使用する接続スキーム (``http`` または ``https``) を指定します。Ansible は、``ansible_port`` が ``5985`` に指定されていない限り、デフォルトで ``https`` を使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:706 -msgid "``ansible_winrm_path``: Specify an alternate path to the WinRM endpoint, Ansible uses ``/wsman`` by default" -msgstr "``ansible_winrm_path``: WinRMエンドポイントへの別のパスを指定します。Ansible はデフォルトで ``/wsman`` を使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:709 -msgid "``ansible_winrm_realm``: Specify the realm to use for Kerberos authentication. If ``ansible_user`` contains ``@``, Ansible will use the part of the username after ``@`` by default" -msgstr "``ansible_winrm_realm``: Kerberos 認証に使用するレルムを指定します。``ansible_user`` に ``@`` が含まれる場合、Ansible はデフォルトで ``@`` の後にユーザー名の一部を使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:713 -msgid "``ansible_winrm_transport``: Specify one or more authentication transport options as a comma-separated list. By default, Ansible will use ``kerberos, basic`` if the ``kerberos`` module is installed and a realm is defined, otherwise it will be ``plaintext``" -msgstr "``ansible_winrm_transport``: 1 つ以上の認証トランスポートオプションをコンマ区切りのリストで指定します。デフォルトでは、``kerberos`` モジュールがインストールされていてレルムが定義されている場合、Ansible は ``kerberos, basic`` を使用し、それ以外の場合は ``plaintext`` になります。" - -#: ../../rst/os_guide/windows_winrm.rst:718 -msgid "``ansible_winrm_server_cert_validation``: Specify the server certificate validation mode (``ignore`` or ``validate``). Ansible defaults to ``validate`` on Python 2.7.9 and higher, which will result in certificate validation errors against the Windows self-signed certificates. Unless verifiable certificates have been configured on the WinRM listeners, this should be set to ``ignore``" -msgstr "``ansible_winrm_server_cert_validation``: サーバー証明書の検証モード (``ignore`` または``validate``) を指定します。Ansible のデフォルトは、Python 2.7.9 以降では ``validate`` で、これは Windows の自己署名証明書に対して証明書の検証エラーが発生します。WinRM リスナーで検証可能な証明書が設定されていない場合は、この設定を ``ignore`` に設定する必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:725 -msgid "``ansible_winrm_operation_timeout_sec``: Increase the default timeout for WinRM operations, Ansible uses ``20`` by default" -msgstr "``ansible_winrm_operation_timeout_sec``: WinRM 操作のデフォルトタイムアウトを増やすと、Ansible はデフォルトで ``20`` を使用します。" - -#: ../../rst/os_guide/windows_winrm.rst:728 -msgid "``ansible_winrm_read_timeout_sec``: Increase the WinRM read timeout, Ansible uses ``30`` by default. Useful if there are intermittent network issues and read timeout errors keep occurring" -msgstr "``ansible_winrm_read_timeout_sec``: WinRM の読み取りタイムアウトを増やします。Ansible はデフォルトで ``30`` を使用します。ネットワークの問題が断続的に発生し、読み取りタイムアウトのエラーが発生し続ける場合に有効です。" - -#: ../../rst/os_guide/windows_winrm.rst:732 -msgid "``ansible_winrm_message_encryption``: Specify the message encryption operation (``auto``, ``always``, ``never``) to use, Ansible uses ``auto`` by default. ``auto`` means message encryption is only used when ``ansible_winrm_scheme`` is ``http`` and ``ansible_winrm_transport`` supports message encryption. ``always`` means message encryption will always be used and ``never`` means message encryption will never be used" -msgstr "``ansible_winrm_message_encryption``: 使用するメッセージ暗号化操作 (``auto``、``always``、``never``) を指定します。Ansible はデフォルトで ``auto`` を使用します。``auto`` は、``ansible_winrm_scheme`` が ``http`` で、``ansible_winrm_transport`` がメッセージ暗号化をサポートしている場合に限り、メッセージ暗号化が使用されることを意味します。``always`` は、メッセージ暗号化が常に使用されることを意味し、``never`` は、メッセージ暗号化が決して使用されないことを意味します。" - -#: ../../rst/os_guide/windows_winrm.rst:739 -msgid "``ansible_winrm_ca_trust_path``: Used to specify a different cacert container than the one used in the ``certifi`` module. See the HTTPS Certificate Validation section for more details." -msgstr "``ansible_winrm_ca_trust_path``: ``certifi`` モジュールで使用されているものとは異なる cacert コンテナーを指定するために使用します。詳細は、「HTTPS 証明書の検証」セクションを参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:743 -msgid "``ansible_winrm_send_cbt``: When using ``ntlm`` or ``kerberos`` over HTTPS, the authentication library will try to send channel binding tokens to mitigate against man in the middle attacks. This flag controls whether these bindings will be sent or not (default: ``yes``)." -msgstr "``ansible_winrm_send_cbt``: ``ntlm`` または ``kerberos`` を HTTPS で使用する場合、認証ライブラリーは、中間者攻撃を緩和するためにチャンネルバインディングトークンの送信を試みます。このフラグは、これらのバインディングを送信するかどうかを制御します (デフォルト: ``yes``)。" - -#: ../../rst/os_guide/windows_winrm.rst:748 -msgid "``ansible_winrm_*``: Any additional keyword arguments supported by ``winrm.Protocol`` may be provided in place of ``*``" -msgstr "``ansible_winrm_*``: ``winrm.Protocol`` でサポートされている任意の追加キーワード引数は、代わりに ``*`` で指定できます。" - -#: ../../rst/os_guide/windows_winrm.rst:751 -msgid "In addition, there are also specific variables that need to be set for each authentication option. See the section on authentication above for more information." -msgstr "さらに、各認証オプションで設定する必要がある特定の変数もあります。詳細は、上記の認証に関するセクションを参照してください。" - -#: ../../rst/os_guide/windows_winrm.rst:754 -msgid "Ansible 2.0 has deprecated the \"ssh\" from ``ansible_ssh_user``, ``ansible_ssh_pass``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_password``, ``ansible_host``, and ``ansible_port``. If using a version of Ansible prior to 2.0, the older style (``ansible_ssh_*``) should be used instead. The shorter variables are ignored, without warning, in older versions of Ansible." -msgstr "Ansible 2.0 では、``ansible_ssh_user``、``ansible_ssh_pass``、``ansible_ssh_host``、および ``ansible_ssh_port`` の「ssh」が非推奨となり、``ansible_user``、``ansible_password``、``ansible_host``、および ``ansible_port`` となりました。Ansible 2.0 より前のバージョンを使用している場合は、代わりに古いスタイル (``ansible_ssh_*``) を使用する必要があります。短い方の変数は、古いバージョンの Ansible では警告なしに無視されます。" - -#: ../../rst/os_guide/windows_winrm.rst:761 -msgid "``ansible_winrm_message_encryption`` is different from transport encryption done over TLS. The WinRM payload is still encrypted with TLS when run over HTTPS, even if ``ansible_winrm_message_encryption=never``." -msgstr "``ansible_winrm_message_encryption`` は、TLS 上で行われるトランスポート暗号化とは異なります。WinRM ペイロードは、``ansible_winrm_message_encryption=never`` であっても、HTTPS で実行された場合でも TLS で暗号化されます。" - -#: ../../rst/os_guide/windows_winrm.rst:768 -msgid "IPv6 Addresses" -msgstr "IPv6 アドレス" - -#: ../../rst/os_guide/windows_winrm.rst:770 -msgid "IPv6 addresses can be used instead of IPv4 addresses or hostnames. This option is normally set in an inventory. Ansible will attempt to parse the address using the `ipaddress `_ package and pass to pywinrm correctly." -msgstr "IPv4 アドレスやホスト名の代わりに、IPv6 アドレスを使用することができます。このオプションは通常、インベントリーで設定します。Ansible は、`ipaddress `_ パッケージを使用してアドレスの解析を試み、pywinrm に正しく渡します。" - -#: ../../rst/os_guide/windows_winrm.rst:775 -msgid "When defining a host using an IPv6 address, just add the IPv6 address as you would an IPv4 address or hostname:" -msgstr "IPv6 アドレスを使用してホストを定義する場合は、IPv4 アドレスやホスト名と同じように IPv6 アドレスを追加するだけです。" - -#: ../../rst/os_guide/windows_winrm.rst:789 -msgid "The ipaddress library is only included by default in Python 3.x. To use IPv6 addresses in Python 2.7, make sure to run ``pip install ipaddress`` which installs a backported package." -msgstr "ipaddress ライブラリーは Python 3.x にのみデフォルトで含まれています。Python 2.7 で IPv6 アドレスを使用するには、バックポートされたパッケージをインストールする ``pip install ipaddress`` を必ず実行してください。" - -#: ../../rst/os_guide/windows_winrm.rst:796 -msgid "HTTPS Certificate Validation" -msgstr "HTTPS 証明書の検証" - -#: ../../rst/os_guide/windows_winrm.rst:798 -msgid "As part of the TLS protocol, the certificate is validated to ensure the host matches the subject and the client trusts the issuer of the server certificate. When using a self-signed certificate or setting ``ansible_winrm_server_cert_validation: ignore`` these security mechanisms are bypassed. While self signed certificates will always need the ``ignore`` flag, certificates that have been issued from a certificate authority can still be validated." -msgstr "TLS プロトコルの一環として、証明書が検証され、ホストがサブジェクトと一致し、クライアントがサーバー証明書の発行者を信頼していることが確認されます。自己署名証明書を使用したり、``ansible_winrm_server_cert_validation: ignore`` を設定したりすると、これらのセキュリティーメカニズムが回避されます。自己署名証明書には常に ``ignore`` フラグが必要ですが、認証局から発行された証明書は検証されます。" - -#: ../../rst/os_guide/windows_winrm.rst:806 -msgid "One of the more common ways of setting up a HTTPS listener in a domain environment is to use Active Directory Certificate Service (AD CS). AD CS is used to generate signed certificates from a Certificate Signing Request (CSR). If the WinRM HTTPS listener is using a certificate that has been signed by another authority, like AD CS, then Ansible can be set up to trust that issuer as part of the TLS handshake." -msgstr "ドメイン環境で HTTPS リスナーをセットアップする一般的な方法の 1 つに、Active Directory Certificate Service (AD CS) を使用する方法があります。AD CS は、CSR (Certificate Signing Request) から署名付き証明書を生成するために使用されます。WinRM HTTPS リスナーが AD CS のような別の機関によって署名された証明書を使用している場合、Ansible は TLS ハンドシェイクの一部としてその発行者を信頼するように設定することができます。" - -#: ../../rst/os_guide/windows_winrm.rst:813 -msgid "To get Ansible to trust a Certificate Authority (CA) like AD CS, the issuer certificate of the CA can be exported as a PEM encoded certificate. This certificate can then be copied locally to the Ansible controller and used as a source of certificate validation, otherwise known as a CA chain." -msgstr "AD CS のような認証局 (CA) を Ansible に信頼させるには、CA の発行者証明書を PEM エンコード証明書としてエクスポートします。この証明書は、Ansible コントローラーのローカルにコピーして、証明書検証のソースとして使用することができます (CA チェーンとも呼ばれます)。" - -#: ../../rst/os_guide/windows_winrm.rst:818 -msgid "The CA chain can contain a single or multiple issuer certificates and each entry is contained on a new line. To then use the custom CA chain as part of the validation process, set ``ansible_winrm_ca_trust_path`` to the path of the file. If this variable is not set, the default CA chain is used instead which is located in the install path of the Python package `certifi `_." -msgstr "CA チェーンには、単一または複数の発行者証明書を含めることができ、各エントリーは新しい行に含まれます。認証プロセスの一部としてカスタム CA チェーンを使用するには、``ansible_winrm_ca_trust_path`` にファイルのパスを設定します。この変数が設定されていない場合は、Python パッケージ `certifi `_ のインストールパスにあるデフォルトの CAチ ェーンが使用されます。" - -#: ../../rst/os_guide/windows_winrm.rst:825 -msgid "Each HTTP call is done by the Python requests library which does not use the systems built-in certificate store as a trust authority. Certificate validation will fail if the server's certificate issuer is only added to the system's truststore." -msgstr "HTTP 呼び出しはそれぞれ、システムに組み込まれた証明書ストアを信頼機関として使用しない Python リクエストライブラリーによって行われます。サーバーの証明書発行者がシステムのトラストストアに追加されていない場合、証明書の検証は失敗します。" - -#: ../../rst/os_guide/windows_winrm.rst:833 -msgid "TLS 1.2 Support" -msgstr "TLS 1.2 のサポート" - -#: ../../rst/os_guide/windows_winrm.rst:835 -msgid "As WinRM runs over the HTTP protocol, using HTTPS means that the TLS protocol is used to encrypt the WinRM messages. TLS will automatically attempt to negotiate the best protocol and cipher suite that is available to both the client and the server. If a match cannot be found then Ansible will error out with a message similar to:" -msgstr "WinRM は HTTP プロトコル上で動作するため、HTTPS を使用するということは、WinRM メッセージの暗号化に TLS プロトコルが使用されることを意味します。TLS は、クライアントとサーバーの両方で利用可能な、最適なプロトコルと暗号スイートを自動的に取り決めようとします。一致するものが見つからない場合、Ansible は次のようなメッセージでエラーになります。" - -#: ../../rst/os_guide/windows_winrm.rst:845 -msgid "Commonly this is when the Windows host has not been configured to support TLS v1.2 but it could also mean the Ansible controller has an older OpenSSL version installed." -msgstr "これは、Windows ホストが TLS v1.2 をサポートするように設定されていない場合ですが、Ansible コントローラーに古い OpenSSL バージョンがインストールされていることも意味します。" - -#: ../../rst/os_guide/windows_winrm.rst:849 -msgid "Windows 8 and Windows Server 2012 come with TLS v1.2 installed and enabled by default but older hosts, like Server 2008 R2 and Windows 7, have to be enabled manually." -msgstr "Windows 8 および Windows Server 2012 には、デフォルトで TLS v1.2 がインストールされ、有効になっていますが、Server 2008 R2 や Windows 7 などの古いホストは手動で有効にする必要があります。" - -#: ../../rst/os_guide/windows_winrm.rst:853 -msgid "There is a bug with the TLS 1.2 patch for Server 2008 which will stop Ansible from connecting to the Windows host. This means that Server 2008 cannot be configured to use TLS 1.2. Server 2008 R2 and Windows 7 are not affected by this issue and can use TLS 1.2." -msgstr "Server 2008 の TLS 1.2 パッチにはバグがあり、Ansible の Windows ホストへの接続が停止してしまいます。これは、Server 2008 が TLS 1.2 を使用するように設定できないことを意味します。Server 2008 R2 とWindows 7 はこの問題の影響を受けず、TLS 1.2 を使用できます。" - -#: ../../rst/os_guide/windows_winrm.rst:858 -msgid "To verify what protocol the Windows host supports, you can run the following command on the Ansible controller:" -msgstr "Windows ホストが対応しているプロトコルを確認するには、Ansible コントローラーで以下のコマンドを実行します。" - -#: ../../rst/os_guide/windows_winrm.rst:865 -msgid "The output will contain information about the TLS session and the ``Protocol`` line will display the version that was negotiated:" -msgstr "出力には TLS セッションに関する情報が含まれ、``Protocol`` 行にはネゴシエートされたバージョンが表示されます。" - -#: ../../rst/os_guide/windows_winrm.rst:903 -msgid "If the host is returning ``TLSv1`` then it should be configured so that TLS v1.2 is enable. You can do this by running the following PowerShell script:" -msgstr "ホストが ``TLSv1`` を返す場合は、TLS v1.2 が有効になるように設定する必要があります。これは、次の PowerShell スクリプトを実行することで行うことができます。" - -#: ../../rst/os_guide/windows_winrm.rst:928 -msgid "The below Ansible tasks can also be used to enable TLS v1.2:" -msgstr "以下の Ansible タスクを使用して TLS v1.2 を有効にすることもできます。" - -#: ../../rst/os_guide/windows_winrm.rst:958 -msgid "There are other ways to configure the TLS protocols as well as the cipher suites that are offered by the Windows host. One tool that can give you a GUI to manage these settings is `IIS Crypto `_ from Nartac Software." -msgstr "TLS プロトコルや、Windows ホストが提供する暗号スイートを設定する方法は他にもあります。これらの設定を管理するための GUI を提供するツールとして、Nartac Software 社の `IIS Crypto `_ があります。" - -#: ../../rst/os_guide/windows_winrm.rst:966 -msgid "WinRM limitations" -msgstr "WinRM の制限" - -#: ../../rst/os_guide/windows_winrm.rst:967 -msgid "Due to the design of the WinRM protocol , there are a few limitations when using WinRM that can cause issues when creating playbooks for Ansible. These include:" -msgstr "WinRM プロトコルの設計上、WinRM を使用する際にはいくつかの制限があり、Ansible の Playbook を作成する際に問題となることがあります。これには次のようなものがあります。" - -#: ../../rst/os_guide/windows_winrm.rst:971 -msgid "Credentials are not delegated for most authentication types, which causes authentication errors when accessing network resources or installing certain programs." -msgstr "ほとんどの認証タイプで認証情報が委譲されていないため、ネットワークリソースへのアクセスや特定のプログラムのインストール時に認証エラーが発生することがありました。" - -#: ../../rst/os_guide/windows_winrm.rst:975 -msgid "Many calls to the Windows Update API are blocked when running over WinRM." -msgstr "WinRM 経由で実行すると、Windows Update API への多くの呼び出しがブロックされます。" - -#: ../../rst/os_guide/windows_winrm.rst:977 -msgid "Some programs fail to install with WinRM due to no credential delegation or because they access forbidden Windows API like WUA over WinRM." -msgstr "認証情報の委譲や、WUA over WinRM などの禁止されている Windows API へのアクセスにより、一部のプログラムは WinRM でインストールできない場合があります。" - -#: ../../rst/os_guide/windows_winrm.rst:980 -msgid "Commands under WinRM are done under a non-interactive session, which can prevent certain commands or executables from running." -msgstr "WinRM のコマンドは非対話型セッションで実行されるため、特定のコマンドや実行ファイルが実行できない場合があります。" - -#: ../../rst/os_guide/windows_winrm.rst:983 -msgid "You cannot run a process that interacts with ``DPAPI``, which is used by some installers (like Microsoft SQL Server)." -msgstr "一部のインストーラー (Microsoft SQL Server など) が使用する ``DPAPI`` と対話するプロセスを実行することはできません。" - -#: ../../rst/os_guide/windows_winrm.rst:986 -msgid "Some of these limitations can be mitigated by doing one of the following:" -msgstr "この制限の一部は、以下のいずれかを実行して軽減できます。" - -#: ../../rst/os_guide/windows_winrm.rst:988 -msgid "Set ``ansible_winrm_transport`` to ``credssp`` or ``kerberos`` (with ``ansible_winrm_kerberos_delegation=true``) to bypass the double hop issue and access network resources" -msgstr "ダブルホップ問題を回避してネットワークリソースにアクセスするために、``ansible_winrm_transport`` を ``credssp`` または ``kerberos`` (``ansible_winrm_kerberos_delegation=true`` を使用) に設定します。" - -#: ../../rst/os_guide/windows_winrm.rst:992 -msgid "Use ``become`` to bypass all WinRM restrictions and run a command as it would locally. Unlike using an authentication transport like ``credssp``, this will also remove the non-interactive restriction and API restrictions like WUA and DPAPI" -msgstr "``become`` を使用すると、すべての WinRM 制限を回避して、ローカルと同様にコマンドを実行できます。``credssp`` のような認証トランスポートを使用する場合とは異なり、非対話型の制限や、WUA や DPAPI などの API の制限も解除されます。" - -#: ../../rst/os_guide/windows_winrm.rst:997 -msgid "Use a scheduled task to run a command which can be created with the ``win_scheduled_task`` module. Like ``become``, this bypasses all WinRM restrictions but can only run a command and not modules." -msgstr "``win_scheduled_task`` モジュールで作成されるコマンドを実行するために、スケジュールされたタスクを使用します。``become`` と同様に、WinRM の制限をすべて回避しますが、実行できるのはコマンドのみで、モジュールは実行できません。" - -#~ msgid "A WinRM listener should be created and activated. More details for this can be found below." -#~ msgstr "WinRM リスナーを作成し、有効にする必要があります。詳細は以下を参照してください。" - -#~ msgid "Once completed, you will need to remove auto logon and set the execution policy back to the default (``Restricted `` for Windows clients, or ``RemoteSigned`` for Windows servers). You can do this with the following PowerShell commands:" -#~ msgstr "完了したら、自動ログオンを解除して、実行ポリシーをデフォルト (Windows クライアントの場合は ``Restricted ``、Windows サーバーの場合は ``RemoteSigned``) に戻す必要があります。これには以下の PowerShell コマンドが必要です。" - -#~ msgid "The script works by checking to see what programs need to be installed (such as .NET Framework 4.5.2) and what PowerShell version is required. If a reboot is required and the ``username`` and ``password`` parameters are set, the script will automatically reboot and logon when it comes back up from the reboot. The script will continue until no more actions are required and the PowerShell version matches the target version. If the ``username`` and ``password`` parameters are not set, the script will prompt the user to manually reboot and logon when required. When the user is next logged in, the script will continue where it left off and the process continues until no more actions are required." -#~ msgstr "このスクリプトは、インストールが必要なプログラム (.NET Framework 4.5.2 など) や、必要な PowerShell バージョンを確認して動作します。再起動が必要で、``username`` パラメーターと ``password`` パラメーターが設定されている場合は、スクリプトが自動的に再起動し、再起動から復帰したときにログオンします。スクリプトは、アクションが不要になり、PowerShell バージョンがターゲットのバージョンと一致するまで続行されます。``username`` パラメーターおよび ``password`` パラメーターが設定されていない場合、スクリプトは必要に応じてユーザーに手動で再起動とログオンを促します。ユーザーが次にログインすると、スクリプトは前回の続きを実行し、アクションが必要なくなるまで処理を続けます。" - -#~ msgid "If running on Server 2008, then SP2 must be installed. If running on Server 2008 R2 or Windows 7, then SP1 must be installed." -#~ msgstr "Server 2008 で実行する場合は、SP2 がインストールされている必要があります。Server 2008 R2 または Windows 7 で実行している場合は SP1 をインストールする必要があります。" - -#~ msgid "When running on PowerShell v3.0, there is a bug with the WinRM service that limits the amount of memory available to WinRM. Without this hotfix installed, Ansible will fail to execute certain commands on the Windows host. These hotfixes should be installed as part of the system bootstrapping or imaging process. The script `Install-WMF3Hotfix.ps1 `_ can be used to install the hotfix on affected hosts." -#~ msgstr "PowerShell v3.0 で実行する場合は、WinRM サービスのバグにより、WinRM で使用できるメモリー量が制限されるという問題がありました。この Hotfix をインストールしないと、Windows ホスト上で Ansible による特定のコマンドの実行に失敗します。これらの Hotfix は、システムのブートストラップまたはイメージングプロセスの一部としてインストールする必要があります。`Install-WMF3Hotfix.ps1 `_ というスクリプトを使用すると、影響を受けるホストに hotfix をインストールできます。" - -#~ msgid "The following PowerShell command will install the hotfix:" -#~ msgstr "以下の PowerShell コマンドは hotfix をインストールします。" - -#~ msgid "``CertificateThumbprint``: If running over an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell:" -#~ msgstr "``CertificateThumbprint``: HTTPS リスナーを介して実行する場合、これは接続に使用される Windows 証明書ストアの証明書のサムプリントです。証明書自体の詳細を取得するには、PowerShell で該当する証明書のサムプリントを指定して次のコマンドを実行します。" - -#~ msgid "When creating an HTTPS listener, an existing certificate needs to be created and stored in the ``LocalMachine\\My`` certificate store. Without a certificate being present in this store, most commands will fail." -#~ msgstr "HTTPS リスナーを作成する際には、既存の証明書を作成し、``LocalMachine\\My`` の証明書ストアに保存する必要があります。このストアに証明書が存在しないと、ほとんどのコマンドが失敗します。" - -#~ msgid "While many of these options should rarely be changed, a few can easily impact the operations over WinRM and are useful to understand. Some of the important options are:" -#~ msgstr "これらのオプションの多くはほとんど変更する必要はありませんが、いくつかのオプションは WinRM の操作に簡単に影響を与えるため、理解しておくと便利です。重要なオプションの一部を紹介します。" - -#~ msgid "``Service\\AllowUnencrypted``: This option defines whether WinRM will allow traffic that is run over HTTP without message encryption. Message level encryption is only possible when ``ansible_winrm_transport`` is ``ntlm``, ``kerberos`` or ``credssp``. By default this is ``false`` and should only be set to ``true`` when debugging WinRM messages." -#~ msgstr "``Service\\AllowUnencrypted``: このオプションは、メッセージを暗号化せずに HTTP で実行するトラフィックを WinRM で許可するかどうかを定義します。メッセージレベルの暗号化は、``ansible_winrm_transport`` が ``ntlm``、``kerberos``、または ``credssp`` の場合にのみ可能です。デフォルトでは、これは ``false`` であり、WinRM メッセージをデバッグする場合に限り ``true`` に設定する必要があります。" - -#~ msgid "To modify a setting under the ``Service`` key in PowerShell:" -#~ msgstr "PowerShell の ``Service`` キーで設定を変更するには、以下を実行します。" - -#~ msgid "To modify a setting under the ``Winrs`` key in PowerShell:" -#~ msgstr "PowerShell の ``Winrs`` キーで設定を変更するには、以下を実行します。" - -#~ msgid "If this fails, the issue is probably related to the WinRM setup. If it works, the issue may not be related to the WinRM setup; please continue reading for more troubleshooting suggestions." -#~ msgstr "失敗した場合は、WinRM の設定に問題があると思われます。成功した場合は、問題が WinRM の設定に関連していない可能性があるため、さらに詳しいトラブルシューティングの方法をご確認ください。" - -#~ msgid "If running over HTTP and not HTTPS, use ``ntlm``, ``kerberos`` or ``credssp`` with ``ansible_winrm_message_encryption: auto`` to enable message encryption. If using another authentication option or if the installed pywinrm version cannot be upgraded, the ``Service\\AllowUnencrypted`` can be set to ``true`` but this is only recommended for troubleshooting" -#~ msgstr "HTTPS ではなく HTTP で実行する場合は、``ntlm``、``kerberos``、または ``credssp`` と ``ansible_winrm_message_encryption: auto`` を使用してメッセージの暗号化を有効にしてください。他の認証オプションを使用している場合や、インストールされている pywinrm のバージョンをアップグレードできない場合は、``Service\\AllowUnencrypted`` を``true`` に設定できますが、これはトラブルシューティングのためにのみ推奨されます。" - -#~ msgid "These indicate an error has occurred with the WinRM service. Some things to check for include:" -#~ msgstr "これらは、WinRM サービスでエラーが発生したことを示しています。確認すべき点は以下の通りです。" - -#~ msgid "These usually indicate an error with the network connection where Ansible is unable to reach the host. Some things to check for include:" -#~ msgstr "これらは通常、Ansible がホストに到達できないネットワーク接続のエラーを示しています。チェック項目には以下が含まれます。" - -#~ msgid "These usually indicate an error when trying to communicate with the WinRM service on the host. Some things to check for:" -#~ msgstr "これらは通常、ホスト上の WinRM サービスと通信しようとする際にエラーを示します。いくつかのチェック項目があります。" - -#~ msgid "If powershell fails with an error message similar to ``The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded.`` then there could be a problem trying to access all the paths specified by the ``PSModulePath`` environment variable. A common cause of this issue is that the ``PSModulePath`` environment variable contains a UNC path to a file share and because of the double hop/credential delegation issue the Ansible process cannot access these folders. The way around this problems is to either:" -#~ msgstr "``The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded.`` のようなエラーメッセージで powershell が失敗する場合は、``PSModulePath`` 環境変数で指定されたすべてのパスにアクセスしようとすると問題が発生する可能性があります。この問題の一般的な原因は、``PSModulePath`` 環境変数にファイル共有への UNC パスが含まれており、ダブルホップ/認証情報の委譲問題のために Ansible プロセスがこれらのディレクトリーにアクセスできないことです。この問題を回避するには、以下の方法があります。" - -#~ msgid "Remove the UNC path from the ``PSModulePath`` environment variable, or" -#~ msgstr "``PSModulePath`` 環境変数から UNC パスを削除します。" - -#~ msgid "The first step to using SSH with Windows is to install the `Win32-OpenSSH `_ service on the Windows host. Microsoft offers a way to install ``Win32-OpenSSH`` through a Windows capability but currently the version that is installed through this process is too old to work with Ansible. To install ``Win32-OpenSSH`` for use with Ansible, select one of these installation options:" -#~ msgstr "Windows で SSH を利用するための最初のステップは、Windows ホストに `Win32-OpenSSH `_ サービスをインストールすることです。Microsoft 社では、Windows の機能を利用して ``Win32-OpenSSH`` をインストールする方法を提供していますが、現在、この方法でインストールされるバージョンは、Ansible で動作させるには古すぎます。Ansible で使用するために ``Win32-OpenSSH`` をインストールするには、以下のインストールオプションのいずれかを選択します。" - -#~ msgid "Install the `openssh `_ package using Chocolatey:" -#~ msgstr "Chocolatey を使用して `openssh `_ パッケージをインストールします。" - -#~ msgid "Use ``win_chocolatey`` to install the service" -#~ msgstr "``win_chocolatey`` を使用してサービスをインストールします。" - -#~ msgid "Win32-OpenSSH authentication with Windows is similar to SSH authentication on Unix/Linux hosts. You can use a plaintext password or SSH public key authentication, add public keys to an ``authorized_key`` file in the ``.ssh`` folder of the user's profile directory, and configure the service using the ``sshd_config`` file used by the SSH service as you would on a Unix/Linux host." -#~ msgstr "Windows での Win32-OpenSSH 認証は、Unix/Linux ホストでの SSH 認証に似ています。平文のパスワードまたは SSH 公開鍵認証を使用し、公開鍵をユーザーのプロファイルディレクトリーの ``.ssh`` ディレクトリーにある ``authorized_key`` ファイルに追加し、Unix/Linux ホストと同様に SSH サービスで使用される ``sshd_config`` ファイルを使用してサービスを設定することができます。" - -#~ msgid "The ``ansible_shell_type`` variable should reflect the ``DefaultShell`` configured on the Windows host. Set to ``cmd`` for the default shell or set to ``powershell`` if the ``DefaultShell`` has been changed to PowerShell." -#~ msgstr "``ansible_shell_type`` 変数には、Windows ホストで設定されている``DefaultShell`` を反映させる必要があります。デフォルトシェルの場合は ``cmd`` に、``DefaultShell`` が PowerShell に変更している場合は ``powershell`` に設定します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/playbook_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/playbook_guide.po deleted file mode 100644 index b28e552366b..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/playbook_guide.po +++ /dev/null @@ -1,7750 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:4 -msgid "Manipulating data" -msgstr "データの操作" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:6 -msgid "In many cases, you need to do some complex operation with your variables, while Ansible is not recommended as a data processing/manipulation tool, you can use the existing Jinja2 templating in conjunction with the many added Ansible filters, lookups and tests to do some very complex transformations." -msgstr "多くの場合あ、変数を使用して複雑な操作を行う必要がありますが、Ansible はデータ処理/操作ツールとしてはお勧めできませんが、既存の Jinja2 テンプレートと、追加された多くの Ansible フィルター、ルックアップ、テストを併用することで、非常に複雑な変換を行うことができます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:11 -msgid "Let's start with a quick definition of each type of plugin:" -msgstr "各プラグイン定義の概要:" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:9 -msgid "lookups: Mainly used to query 'external data', in Ansible these were the primary part of loops using the ``with_`` construct, but they can be used independently to return data for processing. They normally return a list due to their primary function in loops as mentioned previously. Used with the ``lookup`` or ``query`` Jinja2 operators." -msgstr "lookups: 主に「外部データ」を照会するために使用されます。Ansible では、``with_`` 構成を使用したループの主要部分でしたが、処理するデータを返すために独立して使用することもできます。前述のようにループでの主な機能であるため、通常はリストを返します。Jinja2 の演算子 ``lookup`` または ``query`` と一緒に使用します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:10 -msgid "filters: used to change/transform data, used with the ``|`` Jinja2 operator." -msgstr "filters: Jinja2 演算子 ``|`` で使用される、データの変更/変換に使用します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:11 -msgid "tests: used to validate data, used with the ``is`` Jinja2 operator." -msgstr "tests: Jinja2 演算子 ``is`` で使用されるデータの検証に使用されます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:19 -msgid "Loops and list comprehensions" -msgstr "ループおよびリストの競合" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:21 -msgid "Most programming languages have loops (``for``, ``while``, and so on) and list comprehensions to do transformations on lists including lists of objects. Jinja2 has a few filters that provide this functionality: ``map``, ``select``, ``reject``, ``selectattr``, ``rejectattr``." -msgstr "ほとんどのプログラミング言語にはループ (``for``、``while`` など) やリスト内包があり、オブジェクトのリストを含むリストの変換を行うことができます。Jinja2 には、このような機能を提供するフィルターがいくつかあります (``map``、``select``、``reject``、``selectattr``、``rejectattr``)。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:23 -msgid "map: this is a basic for loop that just allows you to change every item in a list, using the 'attribute' keyword you can do the transformation based on attributes of the list elements." -msgstr "map: これは基本的な for ループで、リストのすべての項目を変更することができます。「attribute」キーワードを使用すると、リスト要素の属性に基づいて変換を行うことができます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:24 -msgid "select/reject: this is a for loop with a condition, that allows you to create a subset of a list that matches (or not) based on the result of the condition." -msgstr "select/reject: これは、条件のあるループ用であり、条件の結果に基づいて一致する (または一致しない) リストのサブセットを作成できます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:25 -msgid "selectattr/rejectattr: very similar to the above but it uses a specific attribute of the list elements for the conditional statement." -msgstr "selectattr/rejectattr: 上記と非常に似ていますが、条件文に対して list 要素の特定の属性を使用します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:30 -msgid "Use a loop to create exponential backoff for retries/until." -msgstr "ループを使用して再試行/一時停止の指数関数的なバックオフを作成します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:44 -msgid "Extract keys from a dictionary matching elements from a list" -msgstr "リストから一致するディクショナリー要素からのキー抽出" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:46 -msgid "The Python equivalent code would be:" -msgstr "Python と同等のコードは以下のとおりです。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:55 -msgid "There are several ways to do it in Ansible, this is just one example:" -msgstr "Ansible で実行する方法はいくつかあります。以下は一例です。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:57 -msgid "Way to extract matching keys from a list of dictionaries" -msgstr "ディクショナリーのリストから一致するキーを抽出する方法" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:84 -msgid "Results of debug task, a list with the extracted keys" -msgstr "デバッグタスクの結果 (展開した鍵を含むリスト)" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:97 -msgid "Get the unique list of values of a variable that vary per host" -msgstr "ホストごとに異なる変数の値の一意のリストを取得" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:107 -msgid "Find mount point" -msgstr "マウントポイントの検索" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:109 -msgid "In this case, we want to find the mount point for a given path across our machines, since we already collect mount facts, we can use the following:" -msgstr "今回のケースでは、マシン間で指定されたパスのマウントポイントを検索したいのですが、すでにマウントファクトを収集しているため、次のように使用できます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:111 -msgid "Use selectattr to filter mounts into list I can then sort and select the last from" -msgstr "selectattr を使用してマウントにフィルターを設定してリストにし、ソートして最後のものを選択します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:128 -msgid "Omit elements from a list" -msgstr "リストからの要素を省略" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:130 -msgid "The special ``omit`` variable ONLY works with module options, but we can still use it in other ways as an identifier to tailor a list of elements:" -msgstr "特別な ``omit`` 変数は、モジュールオプションでのみ機能しますが、要素のリストを調整するための識別子として、他の方法でも使用することができます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:132 -msgid "Inline list filtering when feeding a module option" -msgstr "モジュールオプションのフィード時のインラインリストのフィルタリング" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:146 -msgid "Another way is to avoid adding elements to the list in the first place, so you can just use it directly:" -msgstr "もう 1 つの方法は、そもそもリストに要素を追加しないようにして、直接利用することです。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:148 -msgid "Using set_fact in a loop to increment a list conditionally" -msgstr "ループで set_fact を使用してリストを条件付きで増分する" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:166 -msgid "Combine values from same list of dicts" -msgstr "同じリストのディクショナリーの値を結合する" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:167 -msgid "Combining positive and negative filters from examples above, you can get a 'value when it exists' and a 'fallback' when it doesn't." -msgstr "上記の例から正のフィルターと負のフィルターを組み合わせると、「存在する場合の値」と存在しない場合の「フォールバック」を得ることができます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:169 -msgid "Use selectattr and rejectattr to get the ansible_host or inventory_hostname as needed" -msgstr "必要に応じて、selectattr および rejectattr を使用して ansible_host または inventory_hostname を取得" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:187 -msgid "Custom Fileglob Based on a Variable" -msgstr "変数に基づくカスタムファイルグロブ" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:189 -msgid "This example uses `Python argument list unpacking `_ to create a custom list of fileglobs based on a variable." -msgstr "この例では、`Python argument list unpacking `_ を使用して、変数に基づいてファイルグロブのカスタムリストを作成します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:191 -msgid "Using fileglob with a list based on a variable." -msgstr "変数に基づくリストでファイルグロブの使用" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:212 -msgid "Complex Type transformations" -msgstr "複雑なタイプ変換" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:214 -msgid "Jinja provides filters for simple data type transformations (``int``, ``bool``, and so on), but when you want to transform data structures things are not as easy. You can use loops and list comprehensions as shown above to help, also other filters and lookups can be chained and used to achieve more complex transformations." -msgstr "Jinja には単純なデータ型変換のためのフィルターが用意されていますが (``int``、``bool`` など)、データ構造を変換したい場合はそう簡単ではありません。上記のようにループやリスト内包を利用することもできますし、他のフィルターやルックアップを連鎖させて使用することで、より複雑な変換を行うことができます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:221 -msgid "Create dictionary from list" -msgstr "リストからディクショナリーを作成" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:223 -msgid "In most languages it is easy to create a dictionary (a.k.a. map/associative array/hash and so on) from a list of pairs, in Ansible there are a couple of ways to do it and the best one for you might depend on the source of your data." -msgstr "ほとんどの言語では、ペアのリストからディクショナリー (マップ、連想配列、ハッシュなど) を簡単に作成できますが、Ansible ではいくつかの方法があり、データのソースによって最適な方法が異なります。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:226 -msgid "These example produces ``{\"a\": \"b\", \"c\": \"d\"}``" -msgstr "これらの例では、``{\"a\": \"b\", \"c\": \"d\"}`` を生成します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:228 -msgid "Simple list to dict by assuming the list is [key, value , key, value, ...]" -msgstr "リストが [key, value , key, value, ...] であることを前提とする、ディクショナリーへの単純なリスト" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:236 -msgid "It is simpler when we have a list of pairs:" -msgstr "ペアのリストがある場合はより簡単にできる" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:243 -msgid "Both end up being the same thing, with ``slice(2)`` transforming ``single_list`` to a ``list_of_pairs`` generator." -msgstr "``slice(2)`` が ``single_list`` を ``list_of_pairs`` ジェネレーターに変換することで、両方とも同じ内容になります。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:247 -msgid "A bit more complex, using ``set_fact`` and a ``loop`` to create/update a dictionary with key value pairs from 2 lists:" -msgstr "``set_fact`` と ``loop`` を使用して、2 つのリストからキーと値のペアを持つ、もう少し複雑なディクショナリーを作成/更新します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:249 -msgid "Using set_fact to create a dictionary from a set of lists" -msgstr "set_fact を使用してリストのセットからのディクショナリーの作成" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:267 -msgid "This results in ``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}``." -msgstr "その結果、``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}`` になります。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:270 -msgid "You can even combine these simple examples with other filters and lookups to create a dictionary dynamically by matching patterns to variable names:" -msgstr "これらの簡単な例を他のフィルターやルックアップと組み合わせて、変数名にパターンを一致させて動的にディクショナリーを作成することもできます。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:272 -msgid "Using 'vars' to define dictionary from a set of lists without needing a task" -msgstr "「vars」を使用して、タスクを必要とせずにリストのセットからディクショナリーを定義" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:281 -msgid "A quick explanation, since there is a lot to unpack from these two lines:" -msgstr "以下の 2 つの行から展開するため、簡単な説明があります。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:283 -msgid "The ``varnames`` lookup returns a list of variables that match \"begin with ``xyz_``\"." -msgstr "``varnames`` ルックアップは、「begin with ``xyz_``」にマッチする変数の一覧を返します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:284 -msgid "Then feeding the list from the previous step into the ``vars`` lookup to get the list of values. The ``*`` is used to 'dereference the list' (a pythonism that works in Jinja), otherwise it would take the list as a single argument." -msgstr "そして、前のステップのリストを ``vars`` ルックアップに送り、値のリストを取得します。``*`` は「リストを参照解除する」ために使用されます (Jinja でも通用する python の手法です)。そうでなければ、リストを 1 つの引数として受け取ることになります。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:286 -msgid "Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...)." -msgstr "両方のリストは、``zip`` フィルターに渡され、それらをペアにして統一されたリスト (key, value, key2, value2, ...) にします。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:287 -msgid "The dict function then takes this 'list of pairs' to create the dictionary." -msgstr "その後、dict 関数はこの「ペアのリスト」を取得し、ディクショナリーを作成します。" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:290 -msgid "An example on how to use facts to find a host's data that meets condition X:" -msgstr "ファクトを使用して、条件 X を満たすホストのデータを検索する例:" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:298 -msgid "An example to show a host uptime in days/hours/minutes/seconds (assumes facts were gathered)." -msgstr "ホストのアップタイムを日数/時間/分/秒で表示する例（収集されるファクトを想定）" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:309 -#: ../../rst/playbook_guide/playbooks_variables.rst:521 -msgid ":ref:`playbooks_filters`" -msgstr ":ref:`playbooks_filters`" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:310 -msgid "Jinja2 filters included with Ansible" -msgstr "Ansible に含まれる Jinja2 フィルター" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:311 -msgid ":ref:`playbooks_tests`" -msgstr ":ref:`playbooks_tests`" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:312 -msgid "Jinja2 tests included with Ansible" -msgstr "Ansible に含まれる Jinja2 テスト" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:313 -msgid "`Jinja2 Docs `_" -msgstr "`Jinja2 Docs `_" - -#: ../../rst/playbook_guide/complex_data_manipulation.rst:314 -msgid "Jinja2 documentation, includes lists for core filters and tests" -msgstr "Jinja2 ドキュメント。コアフィルターおよびテストの一覧が含まれます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:3 -msgid "Playbook Example: Continuous Delivery and Rolling Upgrades" -msgstr "Playbook の例: 継続的デリバリーおよびローリングアップグレード" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:11 -msgid "What is continuous delivery?" -msgstr "継続的デリバリーとは" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:13 -msgid "Continuous delivery (CD) means frequently delivering updates to your software application." -msgstr "継続的デリバリー (CD) は、ソフトウェアアプリケーションに更新を頻繁に配信することを意味します。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:15 -msgid "The idea is that by updating more often, you do not have to wait for a specific timed period, and your organization gets better at the process of responding to change." -msgstr "更新の頻度を上げることで、特定の期間を待つ必要がなくなり、組織は変化に対応するプロセスを改善できるという考え方です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:18 -msgid "Some Ansible users are deploying updates to their end users on an hourly or even more frequent basis -- sometimes every time there is an approved code change. To achieve this, you need tools to be able to quickly apply those updates in a zero-downtime way." -msgstr "Ansible のユーザーの中には、エンドユーザーにアップデートを毎時またはそれ以上の頻度で配布している人がいます。承認されたコード変更があるたびに配布している場合もあります。そのためには、ダウンタイムなしで更新を迅速に適用できるツールが必要です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:21 -msgid "This document describes in detail how to achieve this goal, using one of Ansible's most complete example playbooks as a template: lamp_haproxy. This example uses a lot of Ansible features: roles, templates, and group variables, and it also comes with an orchestration playbook that can do zero-downtime rolling upgrades of the web application stack." -msgstr "本ガイドでは、Ansible の最も完成度の高いサンプル Playbook の 1 つである lamp_haproxy をテンプレートとして、この目標を達成する方法を詳細に説明します。この例では、ロール、テンプレート、グループ変数などの Ansible の機能が数多く使用されており、Web アプリケーションスタックのローリングアップグレードをダウンタイムなしで行うことができるオーケストレーション Playbook も付属しています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:28 -msgid "`Click here for the latest playbooks for this example `_." -msgstr "このサンプルに使用する Playbook を取得するには、`こちら `_ をクリックします。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:31 -msgid "The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers." -msgstr "Playbook は Apache、PHP、MySQL、Nagios、および HAProxy を CentOS ベースのサーバーセットにデプロイします。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:33 -msgid "We're not going to cover how to run these playbooks here. Read the included README in the github project along with the example for that information. Instead, we're going to take a close look at every part of the playbook and describe what it does." -msgstr "ここでは、これらの Playbook を実行する方法については説明しません。その情報については、github プロジェクトに含まれる README をサンプルと一緒に読んでください。その代わり、Playbook の各部分をよく見て、それが何をするのかを説明します。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:39 -msgid "Site deployment" -msgstr "サイトのデプロイメント" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:41 -msgid "Let's start with ``site.yml``. This is our site-wide deployment playbook. It can be used to initially deploy the site, as well as push updates to all of the servers:" -msgstr "まず、``site.yml`` から始めましょう。これは、サイト全体のデプロイメント Playbook です。この Playbook を使用して、サイトの初期デプロイメントと、すべてのサーバーへの更新のプッシュを行うことができます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:86 -msgid "If you're not familiar with terms like playbooks and plays, you should review :ref:`working_with_playbooks`." -msgstr "Playbook やプレイなどの用語に慣れていない場合は、:ref:`working_with_playbooks` を確認してください。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:88 -msgid "In this playbook we have 5 plays. The first one targets ``all`` hosts and applies the ``common`` role to all of the hosts. This is for site-wide things like yum repository configuration, firewall configuration, and anything else that needs to apply to all of the servers." -msgstr "この Playbook では 5 つのプレイを紹介します。最初の Playbook は ``all`` のホストを対象とし、``common`` のロールをすべてのホストに適用します。これは、yum リポジトリーの設定やファイアウォールの設定など、サイト全体ですべてのサーバーに適用する必要があるものを対象としています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:91 -msgid "The next four plays run against specific host groups and apply specific roles to those servers. Along with the roles for Nagios monitoring, the database, and the web application, we've implemented a ``base-apache`` role that installs and configures a basic Apache setup. This is used by both the sample web application and the Nagios hosts." -msgstr "次の 4 つのプレイは、特定のホストグループに対して実行し、それらのサーバーに特定のロールを適用します。Nagios 監視、データベース、Web アプリケーションのロールと一緒に、基本的な Apache セットアップをインストールして設定する ``base-apache`` ロールを実装しました。これは、サンプルの Web アプリケーションと Nagios ホストの両方で使用されます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:99 -msgid "Reusable content: roles" -msgstr "再利用可能なコンテンツ: ロール" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:101 -msgid "By now you should have a bit of understanding about roles and how they work in Ansible. Roles are a way to organize content: tasks, handlers, templates, and files, into reusable components." -msgstr "その結果、ロールおよび Ansible での動作についてある程度理解できるはずです。ロールは、タスク、ハンドラー、テンプレート、ファイルなどのコンテンツを再利用可能なコンポーネントに整理する方法です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:104 -msgid "This example has six roles: ``common``, ``base-apache``, ``db``, ``haproxy``, ``nagios``, and ``web``. How you organize your roles is up to you and your application, but most sites will have one or more common roles that are applied to all systems, and then a series of application-specific roles that install and configure particular parts of the site." -msgstr "この例では、``common``、``base-apache``、``db``、``haproxy``、``nagios``、および ``web`` の 6 つのロールがあります。ロールをどのように編成するかは、ニーズおよび使用するアプリケーション次第ですが、ほとんどのサイトでは、すべてのシステムに適用される 1 つまたは複数の共通ロールと、サイトの特定の部分をインストールおよび設定する一連のアプリケーション固有のロールがあります。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:108 -msgid "Roles can have variables and dependencies, and you can pass in parameters to roles to modify their behavior. You can read more about roles in the :ref:`playbooks_reuse_roles` section." -msgstr "ロールは変数と依存関係を持つことができ、パラメーターをロールに渡すことでその動作を変更できます。ロールについては、「:ref:`playbooks_reuse_roles`」セクションで詳しく説明しています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:114 -msgid "Configuration: group variables" -msgstr "設定: グループ変数" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:116 -msgid "Group variables are variables that are applied to groups of servers. They can be used in templates and in playbooks to customize behavior and to provide easily-changed settings and parameters. They are stored in a directory called ``group_vars`` in the same location as your inventory. Here is lamp_haproxy's ``group_vars/all`` file. As you might expect, these variables are applied to all of the machines in your inventory:" -msgstr "グループ変数は、サーバーのグループに適用される変数です。テンプレートや Playbook で使用することで、動作をカスタマイズしたり、簡単に変更できる設定やパラメーターを提供することができます。グループ変数は、インベントリーと同じ場所にある ``group_vars`` ディレクトリーに保存されます。以下は lamp_haproxy の ``group_vars/all`` ファイルです。ご想像のとおり、これらの変数はインベントリー内のすべてのマシンに適用されます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:127 -msgid "This is a YAML file, and you can create lists and dictionaries for more complex variable structures. In this case, we are just setting two variables, one for the port for the web server, and one for the NTP server that our machines should use for time synchronization." -msgstr "これは YAML ファイルですが、リストやディクショナリーを作成することで、より複雑な変数構造にすることができます。ここでは 2 つの変数を設定しています。1 つは Web サーバーのポート用、もう 1 つはマシンが時刻同期に使用する NTP サーバーのポート用です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:131 -msgid "Here's another group variables file. This is ``group_vars/dbservers`` which applies to the hosts in the ``dbservers`` group:" -msgstr "次は、別のグループ変数ファイルです。これは、``dbservers`` グループのホストに適用される ``group_vars/dbservers`` です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:142 -msgid "If you look in the example, there are group variables for the ``webservers`` group and the ``lbservers`` group, similarly." -msgstr "上記の例を参照すると、同様に ``webservers`` グループと ``lbservers`` グループのグループ変数も存在します。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:144 -msgid "These variables are used in a variety of places. You can use them in playbooks, like this, in ``roles/db/tasks/main.yml``:" -msgstr "これらの変数はさまざまな場所で使用され、``roles/db/tasks/main.yml`` のように Playbook でも使用できます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:161 -msgid "You can also use these variables in templates, like this, in ``roles/common/templates/ntp.conf.j2``:" -msgstr "これらの変数は、``roles/common/templates/ntp.conf.j2`` で、テンプレートで使用することもできます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:176 -msgid "You can see that the variable substitution syntax of {{ and }} is the same for both templates and variables. The syntax inside the curly braces is Jinja2, and you can do all sorts of operations and apply different filters to the data inside. In templates, you can also use for loops and if statements to handle more complex situations, like this, in ``roles/common/templates/iptables.j2``:" -msgstr "{{ および }} の変数置換構文は、テンプレートでも変数でも同じであることがわかります。中括弧の中の構文は Jinja2 のもので、中のデータに対してあらゆる種類の操作やさまざまなフィルターを適用することができます。テンプレートでは、for ループや if 文を使用して、以下のように、``roles/common/templates/iptables.j2`` でより複雑な状況を処理することもできます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:187 -msgid "This is testing to see if the inventory name of the machine we're currently operating on (``inventory_hostname``) exists in the inventory group ``dbservers``. If so, that machine will get an iptables ACCEPT line for port 3306." -msgstr "これは、現在操作しているマシンのインベントリー名 (``inventory_hostname``) が、インベントリーグループ ``dbservers`` に存在するかどうかをテストしています。存在する場合、そのマシンはポート 3306 に対して iptables の ACCEPT 行を取得します。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:190 -msgid "Here's another example, from the same template:" -msgstr "以下は、同じテンプレートの別の例です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:198 -msgid "This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts." -msgstr "これは、``monitoring`` というグループのすべてのホストをループし、現在のマシンの iptables 設定に、各監視ホストのデフォルトの IPv4 アドレスに ACCEPT 行を追加し、Nagios がそれらのホストを監視できるようにします。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:201 -msgid "You can learn a lot more about Jinja2 and its capabilities `here `_, and you can read more about Ansible variables in general in the :ref:`playbooks_variables` section." -msgstr "Jinja2 とその機能については `こちら `_ で、また Ansible の変数全般については :ref:`playbooks_variables` で詳しく説明しています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:207 -msgid "The rolling upgrade" -msgstr "ローリングアップグレード" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:209 -msgid "Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible's orchestration features come into play. While some applications use the term 'orchestration' to mean basic ordering or command-blasting, Ansible refers to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it." -msgstr "これで、Web サーバー、ロードバランサー、および監視機能を備えた完全なサイトが展開されました。これをどうやって更新しますか。ここで、Ansible のオーケストレーション機能が活躍します。アプリケーションの中には、「オーケストレーション」という言葉を、基本的な命令やコマンドブラストの意味で使用しているものもありますが、Ansible ではオーケストレーションを「オーケストラのようにマシンを指揮すること」と呼んでおり、そのためにかなり高度なエンジンを備えています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:213 -msgid "Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, called ``rolling_update.yml``." -msgstr "Ansible には、多層アプリケーションの操作を連携して行う機能があり、Web アプリケーションのダウンタイムなしのローリングアップグレードを簡単に編成 (オーケストレーション) することができます。これは、``rolling_update.yml`` という名前の別の Playbook に実装されています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:215 -msgid "Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this:" -msgstr "Playbook を確認すると、2 つのプレイで構成されていることがわかります。1 つ目のプレイはとてもシンプルで、次のようになります。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:222 -msgid "What's going on here, and why are there no tasks? You might know that Ansible gathers \"facts\" from the servers before operating upon them. These facts are useful for all sorts of things: networking information, OS/distribution versions, and so on. In our case, we need to know something about all of the monitoring servers in our environment before we perform the update, so this simple play forces a fact-gathering step on our monitoring servers. You will see this pattern sometimes, and it's a useful trick to know." -msgstr "どうなっているのでしょうか。なぜタスクが存在しないのでしょうか。Ansible は、サーバーを操作する前に、サーバーから「ファクト」を収集することはご存知かもしれません。これらのファクトは、ネットワーク情報、OS/ディストリビューションのバージョンなど、あらゆる種類のものに役立ちます。今回のケースでは、更新を実行する前に、環境内のすべての監視サーバーについて何かを知る必要があるため、この単純なプレイによって、監視サーバーのファクト収集ステップが強制的に実行されます。このパターンは時々見かけますが、知っておくと便利なワザです。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:224 -msgid "The next part is the update play. The first part looks like this:" -msgstr "次の部分は、更新プレイです。最初の部分は以下のようになっています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:232 -msgid "This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will parallelize these operations up to the default \"forks\" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time." -msgstr "これは通常のプレイ定義で、``webservers`` グループで動作します。``serial`` キーワードは、一度に操作するサーバーの数を Ansible に伝えます。このキーワードが指定されていない場合、Ansible は設定ファイルで指定されているデフォルトの「フォーク」制限まで、これらの操作を並列化します。しかし、ダウンタイムなしのローリングアップグレードでは、それほど多くのホストを一度に操作する必要はないでしょう。Web サーバーがほんの一握りしかない場合には、``serial`` を 1 に設定して、一度に 1 つのホストに対して行うのがよいでしょう。100 台ある場合は、``serial`` を 10 に設定して、一度に 10 台のホストを操作することもできます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:234 -msgid "Here is the next part of the update play:" -msgstr "以下は更新プレイの次の部分です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:253 -msgid "The ``serial`` keyword forces the play to be executed in 'batches'. Each batch counts as a full play with a subselection of hosts. This has some consequences on play behavior. For example, if all hosts in a batch fails, the play fails, which in turn fails the entire run. You should consider this when combining with ``max_fail_percentage``." -msgstr "``serial`` キーワードを使用すると、プレイが「バッチ」で実行されます。各バッチは、ホストのサブセレクションを使用した完全なプレイとしてカウントされます。これは、プレイの動作にいくつかの影響を与えます。たとえば、バッチ内のすべてのホストが失敗した場合、そのプレイは失敗し、その結果、全体の実行も失敗します。``max_fail_percentage`` と組み合わせる場合は、この点を考慮する必要があります。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:256 -msgid "The ``pre_tasks`` keyword just lets you list tasks to run before the roles are called. This will make more sense in a minute. If you look at the names of these tasks, you can see that we are disabling Nagios alerts and then removing the webserver that we are currently updating from the HAProxy load balancing pool." -msgstr "``pre_tasks`` キーワードでは、ロールが呼び出される前に実行するタスクをリストアップすることができます。これはすぐに意味をなします。これらのタスクの名前を見ると、Nagios のアラートを無効にして、現在更新中の Web サーバーを HAProxy 負荷分散プールから削除していることがわかります。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:258 -msgid "The ``delegate_to`` and ``loop`` arguments, used together, cause Ansible to loop over each monitoring server and load balancer, and perform that operation (delegate that operation) on the monitoring or load balancing server, \"on behalf\" of the webserver. In programming terms, the outer loop is the list of web servers, and the inner loop is the list of monitoring servers." -msgstr "``delegate_to`` 引数および ``loop`` 引数を一緒に使用すると、Ansible が各監視サーバーとロードバランサーをループし、Web サーバーに「代わって」監視サーバーまたは負荷分散サーバーでその操作を実行 (操作を委譲) することになります。プログラミング用語では、外部ループは Web サーバーのリスト、内部ループは監視サーバーのリストになります。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:260 -msgid "Note that the HAProxy step looks a little complicated. We're using HAProxy in this example because it's freely available, though if you have (for instance) an F5 or Netscaler in your infrastructure (or maybe you have an AWS Elastic IP setup?), you can use Ansible modules to communicate with them instead. You might also wish to use other monitoring modules instead of nagios, but this just shows the main goal of the 'pre tasks' section -- take the server out of monitoring, and take it out of rotation." -msgstr "HAProxy のステップは少し複雑に見えることに注意してください。この例では HAProxy を使用していますが、これは自由に利用できるからです。しかし、(たとえば) F5 や Netscaler がインフラストラクチャーにある場合 (あるいは AWS の Elastic IP を設定している場合) は、代わりに Ansible モジュールを使用してそれらと通信することができます。nagios の代わりに他の監視モジュールを使用することもできますが、これは「事前タスク」セクションの主な目的、つまり、サーバーを監視から外し、ローテーションから外すことを示しています。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:262 -msgid "The next step simply re-applies the proper roles to the web servers. This will cause any configuration management declarations in ``web`` and ``base-apache`` roles to be applied to the web servers, including an update of the web application code itself. We don't have to do it this way--we could instead just purely update the web application, but this is a good example of how roles can be used to reuse tasks:" -msgstr "次の手順では、適切なロールを Web サーバーに再適用するだけです。これにより、``web`` と ``base-apache`` のロールにおける構成管理宣言が Web サーバーに適用され、Web アプリケーションコード自体の更新も行われます。このようにしなくても、純粋に Web アプリケーションを更新するだけでもよいのですが、これはロールを使用してタスクを再利用する方法のよい例です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:271 -msgid "Finally, in the ``post_tasks`` section, we reverse the changes to the Nagios configuration and put the web server back in the load balancing pool:" -msgstr "最後に、``post_tasks`` セクションで、Nuppet 設定への変更を元に戻し、Web サーバーを負荷分散プールに戻します。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:289 -msgid "Again, if you were using a Netscaler or F5 or Elastic Load Balancer, you would just substitute in the appropriate modules instead." -msgstr "NetScaler、F5、または Elastic Load Balancer を使用する場合は、代わりに適切なモジュールに置き換えてください。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:294 -msgid "Managing other load balancers" -msgstr "その他のロードバランサーの管理" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:296 -msgid "In this example, we use the simple HAProxy load balancer to front-end the web servers. It's easy to configure and easy to manage. As we have mentioned, Ansible has support for a variety of other load balancers like Citrix NetScaler, F5 BigIP, Amazon Elastic Load Balancers, and more. See the :ref:`working_with_modules` documentation for more information." -msgstr "この例では、シンプルな HAProxy ロードバランサーを Web サーバーのフロントエンドに使用しています。設定が簡単で、管理も容易です。これまで述べてきたように、Ansible は Citrix NetScaler、F5 BigIP、Amazon Elastic Load Balancer など、他のさまざまなロードバランサーをサポートしています。詳細は、「:ref:`working_with_modules`」のドキュメントをご覧ください。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:298 -msgid "For other load balancers, you may need to send shell commands to them (like we do for HAProxy above), or call an API, if your load balancer exposes one. For the load balancers for which Ansible has modules, you may want to run them as a ``local_action`` if they contact an API. You can read more about local actions in the :ref:`playbooks_delegation` section. Should you develop anything interesting for some hardware where there is not a module, it might make for a good contribution!" -msgstr "その他のロードバランサーの場合は、シェルコマンドを送信するか (上記の HAProxy の場合と同様)、ロードバランサーが API を公開している場合は API を呼び出す必要があるかもしれません。Ansible にモジュールが用意されているロードバランサーについては、API を呼び出す場合には、``local_action`` として実行することもできます。ローカルアクションについては、:ref:`playbooks_delegation` セクションで詳しく説明しています。モジュールがないハードウェアで何か面白いものを開発したら、良い貢献になるかもしれません。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:303 -msgid "Continuous delivery end-to-end" -msgstr "継続的デリバリーのエンドツーエンド" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:305 -msgid "Now that you have an automated way to deploy updates to your application, how do you tie it all together? A lot of organizations use a continuous integration tool like `Jenkins `_ or `Atlassian Bamboo `_ to tie the development, test, release, and deploy steps together. You may also want to use a tool like `Gerrit `_ to add a code review step to commits to either the application code itself, or to your Ansible playbooks, or both." -msgstr "アプリケーションの更新を自動的にデプロイする方法が確立されましたが、これらをどのようにまとめたらよいでしょうか。多くの組織では、`Jenkins `_ や `Atlassian Bamboo `_ のような継続的統合ツールを使用して、開発、テスト、リリース、デプロイの各ステップを関連付けています。また、`Gerrit `_ のようなツールを使用して、アプリケーションコード自体か、Ansible Playbook のいずれか、または両方のコミットにコードレビューのステップを追加することもできます。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:307 -msgid "Depending on your environment, you might be deploying continuously to a test environment, running an integration test battery against that environment, and then deploying automatically into production. Or you could keep it simple and just use the rolling-update for on-demand deployment into test or production specifically. This is all up to you." -msgstr "環境によっては、テスト環境に継続的にデプロイし、その環境に対して統合テストバッテリーを実行してから、実稼働環境に自動的にデプロイする場合があります。または、シンプルに保ち、ローリングアップデートを使用して、特にテスト環境または実稼働環境にオンデマンドでデプロイすることもできます。これはすべてあなた次第です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:309 -msgid "For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using AWX, the ``tower-cli`` command or the built-in REST API. (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick)." -msgstr "継続的統合システムとの連携では、``ansible-playbook`` コマンドラインツール (AWX を使用している場合は、``tower-cli`` コマンドや組み込み REST API) を使用して簡単に Playbook の実行をトリガーすることができます (tower-cli コマンドの「joblaunch」は、REST API を介してリモートジョブを生成し、非常に洗練されています)。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:311 -msgid "This should give you a good idea of how to structure a multi-tier application with Ansible, and orchestrate operations upon that app, with the eventual goal of continuous delivery to your customers. You could extend the idea of the rolling upgrade to lots of different parts of the app; maybe add front-end web servers along with application servers, for instance, or replace the SQL database with something like MongoDB or Riak. Ansible gives you the capability to easily manage complicated environments and automate common operations." -msgstr "ここでは、Ansible を使用して多層アプリケーションを構築し、そのアプリケーションの操作を調整して、最終的に顧客に継続的に提供する方法を紹介しています。ローリングアップグレードの概念は、アプリケーションのさまざまな部分に広げることができます。たとえば、アプリケーションサーバーと一緒にフロントエンドの Web サーバーを追加したり、SQL データベースを MongoDB や Riak のようなものに置き換えたりすることができます。Ansible は、複雑な環境を簡単に管理し、一般的な操作を自動化する機能を提供します。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:315 -msgid "`lamp_haproxy example `_" -msgstr "`lamp_haproxy example `_" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:316 -msgid "The lamp_haproxy example discussed here." -msgstr "ここで説明した lamp_haproxy の例です。" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:317 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:540 -#: ../../rst/playbook_guide/playbooks_lookups.rst:28 -#: ../../rst/playbook_guide/playbooks_reuse.rst:211 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:596 -#: ../../rst/playbook_guide/playbooks_roles.rst:15 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:318 -#: ../../rst/playbook_guide/playbooks_async.rst:185 -#: ../../rst/playbook_guide/playbooks_blocks.rst:187 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:541 -#: ../../rst/playbook_guide/playbooks_debugger.rst:338 -#: ../../rst/playbook_guide/playbooks_delegation.rst:166 -#: ../../rst/playbook_guide/playbooks_environment.rst:149 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:269 -#: ../../rst/playbook_guide/playbooks_filters.rst:2189 -#: ../../rst/playbook_guide/playbooks_lookups.rst:29 -#: ../../rst/playbook_guide/playbooks_loops.rst:487 -#: ../../rst/playbook_guide/playbooks_prompts.rst:116 -#: ../../rst/playbook_guide/playbooks_startnstep.rst:44 -#: ../../rst/playbook_guide/playbooks_strategies.rst:246 -#: ../../rst/playbook_guide/playbooks_tags.rst:426 -#: ../../rst/playbook_guide/playbooks_templating.rst:26 -#: ../../rst/playbook_guide/playbooks_tests.rst:528 -#: ../../rst/playbook_guide/playbooks_variables.rst:518 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:319 -#: ../../rst/playbook_guide/playbooks_blocks.rst:188 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:542 -#: ../../rst/playbook_guide/playbooks_filters.rst:2196 -#: ../../rst/playbook_guide/playbooks_loops.rst:488 -#: ../../rst/playbook_guide/playbooks_strategies.rst:249 -#: ../../rst/playbook_guide/playbooks_tags.rst:427 -#: ../../rst/playbook_guide/playbooks_tests.rst:535 -#: ../../rst/playbook_guide/playbooks_variables.rst:525 -msgid ":ref:`playbooks_reuse_roles`" -msgstr ":ref:`playbooks_reuse_roles`" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:320 -msgid "An introduction to playbook roles" -msgstr "Playbook のロールの概要" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:321 -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:115 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:546 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:274 -#: ../../rst/playbook_guide/playbooks_filters.rst:2192 -#: ../../rst/playbook_guide/playbooks_lookups.rst:32 -#: ../../rst/playbook_guide/playbooks_loops.rst:494 -#: ../../rst/playbook_guide/playbooks_prompts.rst:119 -#: ../../rst/playbook_guide/playbooks_reuse.rst:213 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:600 -#: ../../rst/playbook_guide/playbooks_tests.rst:531 -msgid ":ref:`playbooks_variables`" -msgstr ":ref:`playbooks_variables`" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:322 -msgid "An introduction to Ansible variables" -msgstr "Ansible 変数の概要" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:323 -msgid "`Ansible.com: Continuous Delivery `_" -msgstr "`Ansible.com: Continuous Delivery `_" - -#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:324 -msgid "An introduction to Continuous Delivery with Ansible" -msgstr "Ansible を使用した継続的デリバリーの概要" - -#: ../../rst/playbook_guide/index.rst:5 -msgid "Using Ansible playbooks" -msgstr "Ansible Playbook の使用" - -#: ../../rst/playbook_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/playbook_guide/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/playbook_guide/index.rst:13 -msgid "Welcome to the Ansible playbooks guide. Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure nodes in an inventory. This guide introduces you to playbooks and then covers different use cases for tasks and plays, such as:" -msgstr "Ansible Playbook ガイドへようこそ。Playbook は、``YAML`` 形式の自動化ブループリントで、Ansible はインベントリーでのノードのデプロイおよび設定に使用します。本書では、Playbook を紹介して、以下のようなタスクやプレイのさまざまなユースケースについて説明します。" - -#: ../../rst/playbook_guide/index.rst:17 -msgid "Executing tasks with elevated privileges or as a different user." -msgstr "昇格された権限で、または別のユーザーとしてタスクを実行する" - -#: ../../rst/playbook_guide/index.rst:18 -msgid "Using loops to repeat tasks for items in a list." -msgstr "ループを使用して、リスト内の項目に対してタスクを繰り返す。" - -#: ../../rst/playbook_guide/index.rst:19 -msgid "Delegating playbooks to execute tasks on different machines." -msgstr "異なるマシンでタスクを実行する Playbook を委譲する。" - -#: ../../rst/playbook_guide/index.rst:20 -msgid "Running conditional tasks and evaluating conditions with playbook tests." -msgstr "条件タスクを実行して Playbook テストを使用して条件を評価する。" - -#: ../../rst/playbook_guide/index.rst:21 -msgid "Using blocks to group sets of tasks." -msgstr "ブロックを使用してタスクセットをグループ化する。" - -#: ../../rst/playbook_guide/index.rst:23 -msgid "You can also learn how to use Ansible playbooks more effectively by creating re-usable files and roles, including and importing playbooks, and running selected parts of a playbook with tags." -msgstr "また、Playbook を含む再利用可能なファイルおよびロールを作成し、タグを使用して Playbook の選択された部分を実行することで、Ansible Playbook をより効果的に使用する方法についても学ぶことができます。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:5 -msgid "Search paths in Ansible" -msgstr "Ansible でパスの検索" - -#: ../../rst/playbook_guide/playbook_pathing.rst:7 -msgid "You can control the paths Ansible searches to find resources on your control node (including configuration, modules, roles, ssh keys, and more) as well as resources on the remote nodes you are managing. Use absolute paths to tell Ansible where to find resources whenever you can. However, absolute paths are not always practical. This page covers how Ansible interprets relative search paths, along with ways to troubleshoot when Ansible cannot find the resource you need." -msgstr "Ansible がコントロールノード上のリソース (構成、モジュール、ロール、ssh キーなど) や、管理しているリモートノード上のリソースを検索する際のパスを制御できます。リソースを検索する場所を Ansible に伝えるには、可能な限り絶対パスを使用します。しかし、絶対パスは必ずしも実用的ではありません。このページでは、Ansible が相対検索パスをどのように解釈するか、また Ansible が必要なリソースを見つけられない場合のトラブルシューティングの方法について説明します。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:13 -msgid "Config paths" -msgstr "設定パス" - -#: ../../rst/playbook_guide/playbook_pathing.rst:15 -msgid "By default these should be relative to the config file, some are specifically relative to the current working directory or the playbook and should have this noted in their description. Things like ssh keys are left to use the current working directory because it mirrors how the underlying tools would use it." -msgstr "デフォルトでは、これらは設定ファイルからの相対的なものですが、中には特に現在の作業ディレクトリーや Playbook からの相対的なものもあるため、説明にその旨を記載してください。ssh キーのようなものは、基本的なツールが使用する方法を反映するため、現在の作業ディレクトリーを使用するようになっています。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:20 -msgid "Task paths" -msgstr "タスクパス" - -#: ../../rst/playbook_guide/playbook_pathing.rst:22 -msgid "Relative paths used in a task typically refer to remote files and directories on the managed nodes. However, paths passed to lookup plugins and some paths used in action plugins such as the \"src\" path for the :ref:`template ` and :ref:`copy ` modules refer to local files and directories on the control node." -msgstr "タスクで使用される相対パスは通常、管理ノードのリモートファイルおよびディレクトリーを参照します。ただし、lookup プラグインに渡されるパスや、:ref:`template ` モジュールおよび :ref:`copy ` モジュールの「src」パス等のアクションプラグインで使用される一部のパスは、コントロールノードのローカルファイルおよびディレクトリーを参照します。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:25 -msgid "Resolving local relative paths" -msgstr "ローカル相対パスの解決" - -#: ../../rst/playbook_guide/playbook_pathing.rst:27 -msgid "When you specify a relative path for a local file, Ansible will try to find that file first in the current task's role, then in other roles that included or depend on the current role, then relative to the file in which the task is defined, and finally relative to the current play. It will take the first matching file that it finds. This way, if multiple files with the same filename exist, Ansible will find the file that is closest to the current task and that is most likely to be file you wanted." -msgstr "ローカルファイルの相対パスを指定する場合、Ansible は現在のタスクのロールでまずそのファイルを見つけようとします。次に、現在のロールに含まれる、または依存する他のロールで、次にタスクが定義されているファイルに相対的に、最後に現在のプレイに相対的に見つけようとします。これにより、最初に見つかったマッチするファイルが使用されます。したがって、同じファイル名を持つ複数のファイルが存在する場合、Ansible は現在のタスクにもっとも近く、希望のファイルである可能性が高いファイルを検索します。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:29 -msgid "Specifically, Ansible tries to find the file" -msgstr "具体的には、Ansible は以下のようにファイルを検索しようとします" - -#: ../../rst/playbook_guide/playbook_pathing.rst:31 -msgid "In the current role." -msgstr "現在のロールで" - -#: ../../rst/playbook_guide/playbook_pathing.rst:33 -msgid "In its appropriate subdirectory—\"files\", \"vars\", \"templates\" or \"tasks\", depending on the kind of file Ansible is searching for." -msgstr "Ansible が検索するファイルの種類に応じて、適切なサブディレクトリー(「files」、「vars」、「templates」、または「tasks」)で" - -#: ../../rst/playbook_guide/playbook_pathing.rst:34 -msgid "Directly in its directory." -msgstr "そのディレクトリーに直接" - -#: ../../rst/playbook_guide/playbook_pathing.rst:36 -msgid "Like 1, in the parent role that called into this current role with `include_role`, `import_role`, or with a role dependency. If the parent role has its own parent role, Ansible will repeat this step with that role." -msgstr "1 と同様に、`include_role`、`import_role` またはロールの依存関係でこの現在のロールに呼び出される親ロールで。親ロールに独自の親ロールがある場合は、Ansible はそのロールでこの手順を繰り返します。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:37 -msgid "Like 1, in the current task file's directory." -msgstr "1 と同様に、現在のタスクファイルのディレクトリーで" - -#: ../../rst/playbook_guide/playbook_pathing.rst:38 -msgid "Like 1, in the current play file's directory." -msgstr "1 と同様に、現在の play ファイルのディレクトリーで" - -#: ../../rst/playbook_guide/playbook_pathing.rst:40 -msgid "Ansible does not search the current working directory. (The directory you're in when you execute Ansible.) Also, Ansible will only search within a role if you actually included it with an `include_role` or `import_role` task or a dependency. If you instead use `include`, `include_task` or `import_task` to include just the tasks from a specific file but not the full role, Ansible will not search that role in steps 1 and 2." -msgstr "Ansible は、現在の作業ディレクトリー(Ansibleを実行する時のディレクトリー)を検索しません。また、`include_role` または `import_role` タスクまたは依存関係で実際に含めた場合、Ansible はロール内のみ検索します。代わりに、`include`、`include_task`、または `import_task` を使用して、完全なロールではなく特定のファイルからのタスクだけを含める場合、Ansible はステップ1および2でそのロールを検索しません。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:42 -msgid "When you execute Ansible, the variable `ansible_search_path` will contain the paths searched, in the order they were searched in but without listing their subdirectories. If you run Ansible in verbosity level 5 by passing the `-vvvvv` argument, Ansible will report each directory as it searches, except when it searches for a tasks file." -msgstr "Ansible を実行すると、変数 `ansible_search_path` には、検索されたパスが検索された順に含まれますが、そのサブディレクトリーは一覧表示されません。`-vvvvv` 引数を渡して詳細レベル5でAnsible を実行すると、タスクファイルを検索した場合を除き、Ansible は検索した順に各ディレクトリーを報告します。" - -#: ../../rst/playbook_guide/playbook_pathing.rst:45 -msgid "The current working directory might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory." -msgstr "現在の作業ディレクトリは、接続プラグインと、アクションがローカルかリモートかによって異なる場合があります。リモートの場合、通常、ログインシェルがユーザーを配置するディレクトリになります。ローカルの場合は、ansibleを実行したディレクトリか、場合によってはPlaybokディレクトリになります。" - -#: ../../rst/playbook_guide/playbooks.rst:4 -msgid "Working with playbooks" -msgstr "Playbook の操作" - -#: ../../rst/playbook_guide/playbooks.rst:6 -msgid "Playbooks record and execute Ansible's configuration, deployment, and orchestration functions. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process." -msgstr "Playbook は、Ansible の設定、デプロイメント、オーケストレーション機能を記録して実行します。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。" - -#: ../../rst/playbook_guide/playbooks.rst:9 -msgid "If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material." -msgstr "Ansible モジュールがワークショップのツールである場合、Playbook は手順のマニュアルにあり、ホストのインベントリーは実際のマテリアルになります。" - -#: ../../rst/playbook_guide/playbooks.rst:11 -msgid "At a basic level, playbooks can be used to manage configurations of and deployments to remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way." -msgstr "基本的なレベルでは、Playbook を使用して、リモートマシンの設定およびリモートマシンへのデプロイメントを管理できます。より高度なレベルでは、ローリングアップデートに関連する複数層のロールアウトを分類し、他のホストにアクションを委譲して、監視サーバーやロードバランサーと対話できます。" - -#: ../../rst/playbook_guide/playbooks.rst:14 -msgid "Playbooks are designed to be human-readable and are developed in a basic text language. There are multiple ways to organize playbooks and the files they include, and we'll offer up some suggestions on that and making the most out of Ansible." -msgstr "Playbook は人間が判読可能で、基本的なテキスト言語で開発されるように設計されています。Playbook と、Playbook に含まれるファイルを整理する方法は複数あり、その方法と、Ansible を最大限に活用するための提案を行います。" - -#: ../../rst/playbook_guide/playbooks.rst:17 -msgid "You should look at `Example Playbooks `_ while reading along with the playbook documentation. These illustrate best practices as well as how to put many of the various concepts together." -msgstr "Playbook ドキュメントと一緒に、`Example Playbooks `_ を参照してください。ここでは、ベストプラクティスや、さまざまな概念をまとめて配置する方法を説明します。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:5 -msgid "Advanced playbook syntax" -msgstr "高度な Playbook の構文" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:7 -msgid "The advanced YAML syntax examples on this page give you more control over the data placed in YAML files used by Ansible. You can find additional information about Python-specific YAML in the official `PyYAML Documentation `_." -msgstr "このページの高度な YAML 構文の例では、Ansible が使用する YAML ファイルに配置されるデータをより細かく制御できます。Python 固有の YAML に関する追加情報は、公式の `PyYAML ドキュメント `_ でご覧いただけます。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:13 -msgid "Unsafe or raw strings" -msgstr "安全でない文字列または生の文字列" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:15 -#, python-format -msgid "When handling values returned by lookup plugins, Ansible uses a data type called ``unsafe`` to block templating. Marking data as unsafe prevents malicious users from abusing Jinja2 templates to execute arbitrary code on target machines. The Ansible implementation ensures that unsafe values are never templated. It is more comprehensive than escaping Jinja2 with ``{% raw %} ... {% endraw %}`` tags." -msgstr "lookup プラグインから返される値を処理する際、Ansible は ``unsafe`` というデータタイプを使用してテンプレートをブロックします。データを安全ではないとマークすることで、悪意のあるユーザーが Jinja2 のテンプレートを悪用してターゲットマシンで任意のコードを実行することを防ぎます。Ansible の実装では、安全でない値が決してテンプレート化されないようにしています。``{% raw %} ... {% endraw %}`` タグで Jinja2 をエスケープするよりも包括的です。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:17 -msgid "You can use the same ``unsafe`` data type in variables you define, to prevent templating errors and information disclosure. You can mark values supplied by :ref:`vars_prompts` as unsafe. You can also use ``unsafe`` in playbooks. The most common use cases include passwords that allow special characters like ``{`` or ``%``, and JSON arguments that look like templates but should not be templated. For example:" -msgstr "定義した変数に同じ ``unsafe`` データ型を使用すると、テンプレートエラーや情報の漏えいを防ぐことができます。:ref:`vars_prompts` により提供された値を安全でないものとしてマーク付けできます。Playbook で ``unsafe`` を使用することもできます。最も一般的なユースケースには、テンプレートのような ``{`` や ``%`` などの特殊文字を許可するパスワードが含まれていますが、テンプレート化すべきではありません。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:24 -msgid "In a playbook:" -msgstr "Playbook の場合は、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:35 -msgid "For complex variables such as hashes or arrays, use ``!unsafe`` on the individual elements:" -msgstr "ハッシュや配列などの複雑な変数の場合は、個々の要素で ``!unsafe`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:50 -msgid "YAML anchors and aliases: sharing variable values" -msgstr "YAML アンカーおよびエイリアス: 変数値の共有" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:52 -msgid "`YAML anchors and aliases `_ help you define, maintain, and use shared variable values in a flexible way. You define an anchor with ``&``, then refer to it using an alias, denoted with ``*``. Here's an example that sets three values with an anchor, uses two of those values with an alias, and overrides the third value:" -msgstr "`YAML アンカーおよびエイリアス `_ は、柔軟な方法で共有変数の値を定義、維持、および使用するのに役立ちます。``&`` でアンカーを定義し、``*`` で示すエイリアスを使用して参照します。ここでは、アンカーで 3 つの値を設定し、エイリアスでこれらの値を 2 つ使用し、3 番目の値を上書きする例を以下に示します。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:71 -msgid "Here, ``app1`` and ``app2`` share the values for ``opts`` and ``port`` using the anchor ``&jvm_opts`` and the alias ``*jvm_opts``. The value for ``path`` is merged by ``<<`` or `merge operator `_." -msgstr "ここで、``app1`` および ``app2`` は、アンカー ``&jvm_opts`` およびエイリアス ``*jvm_opts`` を使用して、``opts`` と ``port`` の値を共有します。``path`` の値は、``<<`` または `merge operator `_ によってマージされます。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:74 -msgid "Anchors and aliases also let you share complex sets of variable values, including nested variables. If you have one variable value that includes another variable value, you can define them separately:" -msgstr "アンカーおよびエイリアスを使用すると、入れ子になった変数など、複雑な変数値のセットを共有することもできます。ある変数値に別の変数値が含まれている場合は、その変数値を別々に定義することができます。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:82 -msgid "This is inefficient and, at scale, means more maintenance. To incorporate the version value in the name, you can use an anchor in ``app_version`` and an alias in ``custom_name``:" -msgstr "これは非効率的であり、大規模な場合には、より多くのメンテナンスが行われます。名前に version の値を組み込むには、``app_version`` にアンカーと、``custom_name`` のエイリアスを使用できます。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:93 -msgid "Now, you can re-use the value of ``app_version`` within the value of ``custom_name`` and use the output in a template:" -msgstr "これで、``custom_name`` の値の ``app_version`` の値を再利用し、テンプレートで出力を使用できます。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:111 -msgid "You've anchored the value of ``version`` with the ``&my_version`` anchor, and re-used it with the ``*my_version`` alias. Anchors and aliases let you access nested values inside dictionaries." -msgstr "``version`` の値を ``&my_version`` というアンカーで固定し、``*my_version`` というエイリアスで再利用しています。アンカーとエイリアスを使用することで、ディクショナリー内のネストした値にアクセスすることができます。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:116 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:547 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:275 -#: ../../rst/playbook_guide/playbooks_filters.rst:2193 -#: ../../rst/playbook_guide/playbooks_lookups.rst:33 -#: ../../rst/playbook_guide/playbooks_loops.rst:495 -#: ../../rst/playbook_guide/playbooks_prompts.rst:120 -#: ../../rst/playbook_guide/playbooks_tests.rst:532 -msgid "All about variables" -msgstr "変数の詳細" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:117 -msgid ":ref:`complex_data_manipulation`" -msgstr ":ref:`complex_data_manipulation`" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:118 -msgid "Doing complex data manipulation in Ansible" -msgstr "Ansible での複雑なデータ操作の実行" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:119 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:120 -#: ../../rst/playbook_guide/playbooks_async.rst:187 -#: ../../rst/playbook_guide/playbooks_blocks.rst:191 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:549 -#: ../../rst/playbook_guide/playbooks_debugger.rst:340 -#: ../../rst/playbook_guide/playbooks_delegation.rst:172 -#: ../../rst/playbook_guide/playbooks_environment.rst:151 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:277 -#: ../../rst/playbook_guide/playbooks_filters.rst:2201 -#: ../../rst/playbook_guide/playbooks_lookups.rst:37 -#: ../../rst/playbook_guide/playbooks_loops.rst:497 -#: ../../rst/playbook_guide/playbooks_prompts.rst:122 -#: ../../rst/playbook_guide/playbooks_strategies.rst:252 -#: ../../rst/playbook_guide/playbooks_tags.rst:430 -#: ../../rst/playbook_guide/playbooks_templating.rst:32 -#: ../../rst/playbook_guide/playbooks_tests.rst:540 -#: ../../rst/playbook_guide/playbooks_variables.rst:532 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:121 -#: ../../rst/playbook_guide/playbooks_async.rst:188 -#: ../../rst/playbook_guide/playbooks_blocks.rst:192 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:550 -#: ../../rst/playbook_guide/playbooks_debugger.rst:341 -#: ../../rst/playbook_guide/playbooks_delegation.rst:173 -#: ../../rst/playbook_guide/playbooks_environment.rst:152 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:278 -#: ../../rst/playbook_guide/playbooks_filters.rst:2202 -#: ../../rst/playbook_guide/playbooks_lookups.rst:38 -#: ../../rst/playbook_guide/playbooks_loops.rst:498 -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:775 -#: ../../rst/playbook_guide/playbooks_prompts.rst:123 -#: ../../rst/playbook_guide/playbooks_strategies.rst:253 -#: ../../rst/playbook_guide/playbooks_tags.rst:431 -#: ../../rst/playbook_guide/playbooks_templating.rst:33 -#: ../../rst/playbook_guide/playbooks_tests.rst:541 -#: ../../rst/playbook_guide/playbooks_variables.rst:533 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:122 -#: ../../rst/playbook_guide/playbooks_async.rst:189 -#: ../../rst/playbook_guide/playbooks_blocks.rst:193 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:551 -#: ../../rst/playbook_guide/playbooks_debugger.rst:342 -#: ../../rst/playbook_guide/playbooks_delegation.rst:174 -#: ../../rst/playbook_guide/playbooks_environment.rst:153 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:279 -#: ../../rst/playbook_guide/playbooks_filters.rst:2203 -#: ../../rst/playbook_guide/playbooks_lookups.rst:39 -#: ../../rst/playbook_guide/playbooks_loops.rst:499 -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:776 -#: ../../rst/playbook_guide/playbooks_prompts.rst:124 -#: ../../rst/playbook_guide/playbooks_strategies.rst:254 -#: ../../rst/playbook_guide/playbooks_tags.rst:432 -#: ../../rst/playbook_guide/playbooks_templating.rst:34 -#: ../../rst/playbook_guide/playbooks_tests.rst:542 -#: ../../rst/playbook_guide/playbooks_variables.rst:534 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/playbook_guide/playbooks_async.rst:4 -msgid "Asynchronous actions and polling" -msgstr "非同期アクションおよびポーリング" - -#: ../../rst/playbook_guide/playbooks_async.rst:6 -msgid "By default Ansible runs tasks synchronously, holding the connection to the remote node open until the action is completed. This means within a playbook, each task blocks the next task by default, meaning subsequent tasks will not run until the current task completes. This behavior can create challenges. For example, a task may take longer to complete than the SSH session allows for, causing a timeout. Or you may want a long-running process to execute in the background while you perform other tasks concurrently. Asynchronous mode lets you control how long-running tasks execute." -msgstr "デフォルトでは、Ansible はタスクを同期的に実行し、アクションが完了するまでリモートノードへの接続を維持します。つまり、Playbook 内では、デフォルトでは各タスクが次のタスクをブロックし、現在のタスクが完了するまで後続のタスクが実行されないことになります。この動作には課題があります。たとえば、あるタスクが SSH セッションの許容範囲を超えて完了するのに時間がかかり、タイムアウトが発生する場合があります。また、他のタスクを同時に実行している間、長時間実行するプロセスをバックグラウンドで実行したい場合もあります。非同期モードでは、長時間実行するタスクの実行方法を制御することができます。" - -#: ../../rst/playbook_guide/playbooks_async.rst:12 -msgid "Asynchronous ad hoc tasks" -msgstr "非同期アドホックタスク" - -#: ../../rst/playbook_guide/playbooks_async.rst:14 -msgid "You can execute long-running operations in the background with :ref:`ad hoc tasks `. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``):" -msgstr ":ref:`アドホックタスク ` を使用すると、バックグラウンドで長時間実行される操作を実行することができます。たとえば、``long_running_operation`` をバックグラウンドで非同期的に実行し、タイムアウト (``-B``) を 3600 秒に設定し、ポーリング (``-P``) を行わない場合は次のようになります。" - -#: ../../rst/playbook_guide/playbooks_async.rst:20 -msgid "To check on the job status later, use the ``async_status`` module, passing it the job ID that was returned when you ran the original job in the background:" -msgstr "後でジョブステータスを確認するには、``async_status`` モジュールを使用し、バックグラウンドで元のジョブの実行時に返されたジョブ ID を渡します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:26 -msgid "Ansible can also check on the status of your long-running job automatically with polling. In most cases, Ansible will keep the connection to your remote node open between polls. To run for 30 minutes and poll for status every 60 seconds:" -msgstr "Ansible は、ポーリングによって長時間実行するジョブの状態を自動的に確認することもできます。ほとんどの場合、Ansible はポーリングの間もリモートノードへの接続を維持します。30 分間実行し、60 秒ごとにステータスをポーリングするには次のようにします。" - -#: ../../rst/playbook_guide/playbooks_async.rst:32 -msgid "Poll mode is smart so all jobs will be started before polling begins on any machine. Be sure to use a high enough ``--forks`` value if you want to get all of your jobs started very quickly. After the time limit (in seconds) runs out (``-B``), the process on the remote nodes will be terminated." -msgstr "ポーリングモードは高性能であるため、どのマシンでもポーリングが開始する前にすべてのジョブが開始します。すべてのジョブを非常に迅速に開始したい場合は ``--forks`` を十分な高さにしてください。制限時間 (秒単位) がなくなると (``-B``)、リモートノードのプロセスは終了します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:34 -msgid "Asynchronous mode is best suited to long-running shell commands or software upgrades. Running the copy module asynchronously, for example, does not do a background file transfer." -msgstr "非同期モードは、長時間実行するシェルコマンドやソフトウェアのアップグレードに最適です。たとえば、copy モジュールを非同期で実行しても、バックグラウンドでのファイル転送は行われません。" - -#: ../../rst/playbook_guide/playbooks_async.rst:37 -msgid "Asynchronous playbook tasks" -msgstr "非同期 Playbook タスク" - -#: ../../rst/playbook_guide/playbooks_async.rst:39 -msgid ":ref:`Playbooks ` also support asynchronous mode and polling, with a simplified syntax. You can use asynchronous mode in playbooks to avoid connection timeouts or to avoid blocking subsequent tasks. The behavior of asynchronous mode in a playbook depends on the value of `poll`." -msgstr ":ref:`Playbook ` は、非同期モードとポーリングもサポートしており、構文も簡素化されています。非同期モードを Playbook で使用すると、接続のタイムアウトや、後続タスクのブロックを回避できます。Playbook での非同期モードの動作は、`poll` の値に依存します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:42 -msgid "Avoid connection timeouts: poll > 0" -msgstr "接続のタイムアウトの回避: poll > 0" - -#: ../../rst/playbook_guide/playbooks_async.rst:44 -msgid "If you want to set a longer timeout limit for a certain task in your playbook, use ``async`` with ``poll`` set to a positive value. Ansible will still block the next task in your playbook, waiting until the async task either completes, fails or times out. However, the task will only time out if it exceeds the timeout limit you set with the ``async`` parameter." -msgstr "Playbook 内の特定のタスクにより長いタイムアウト制限を設定する場合は、``async`` を使用し、``poll`` を正の値に設定します。Ansible は、Playbook 内に記載される次のタスクをブロックし、非同期タスクが完了するか、失敗するか、タイムアウトになるまで待機します。ただし、タスクがタイムアウトになるのは、``async`` パラメーターで設定したタイムアウト制限を超えた場合のみです。" - -#: ../../rst/playbook_guide/playbooks_async.rst:46 -msgid "To avoid timeouts on a task, specify its maximum runtime and how frequently you would like to poll for status:" -msgstr "タスクでタイムアウトを回避するには、最大ランタイムとステータスをポーリングする頻度を指定します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:63 -msgid "The default poll value is set by the :ref:`DEFAULT_POLL_INTERVAL` setting. There is no default for the async time limit. If you leave off the 'async' keyword, the task runs synchronously, which is Ansible's default." -msgstr "デフォルトのポール値は、:ref:`DEFAULT_POLL_INTERVAL` の設定で設定されます。非同期時間制限のデフォルトはありません。「async」キーワードを省略すると、タスクは同期的に実行されます。これが Ansible のデフォルトです。" - -#: ../../rst/playbook_guide/playbooks_async.rst:69 -msgid "As of Ansible 2.3, async does not support check mode and will fail the task when run in check mode. See :ref:`check_mode_dry` on how to skip a task in check mode." -msgstr "Ansible 2.3 の時点では、非同期はチェックモードをサポートしておらず、チェックモードで実行するとタスクが失敗します。チェックモードでタスクをスキップする方法は、「:ref:`check_mode_dry`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_async.rst:74 -msgid "When an async task completes with polling enabled, the temporary async job cache file (by default in ~/.ansible_async/) is automatically removed." -msgstr "ポーリングを有効にして非同期タスクが完了すると、一時的な非同期ジョブキャッシュファイル (デフォルトでは ~/.ansible_async/ にある) が自動的に削除されます。" - -#: ../../rst/playbook_guide/playbooks_async.rst:78 -msgid "Run tasks concurrently: poll = 0" -msgstr "タスクの同時実行: poll = 0" - -#: ../../rst/playbook_guide/playbooks_async.rst:80 -msgid "If you want to run multiple tasks in a playbook concurrently, use ``async`` with ``poll`` set to 0. When you set ``poll: 0``, Ansible starts the task and immediately moves on to the next task without waiting for a result. Each async task runs until it either completes, fails or times out (runs longer than its ``async`` value). The playbook run ends without checking back on async tasks." -msgstr "Playbook 内の複数のタスクを同時に実行する場合は、``async`` を使用し、``poll`` を 0 に設定します。``poll: 0`` を設定すると、Ansible はタスクを開始し、結果を待たずに直ちに次のタスクに移ります。各非同期タスクは、完了するか、失敗するか、タイムアウトにする (``async`` の値よりも長く実行される) まで実行されます。Playbook の実行は、非同期タスクを再度チェックせずに終了します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:82 -msgid "To run a playbook task asynchronously:" -msgstr "Playbook タスクを非同期的に実行するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:99 -msgid "Do not specify a poll value of 0 with operations that require exclusive locks (such as yum transactions) if you expect to run other commands later in the playbook against those same resources." -msgstr "排他的ロックを必要とする操作 (yum トランザクションなど) では、同じリソースに対して Playbook の後半で他のコマンドを実行することを想定して、poll 値に 0 を指定しないでください。" - -#: ../../rst/playbook_guide/playbooks_async.rst:102 -msgid "Using a higher value for ``--forks`` will result in kicking off asynchronous tasks even faster. This also increases the efficiency of polling." -msgstr "``--forks`` の値を増やすと、非同期タスクの開始が速くなります。これにより、ポーリングの効率が高まります。" - -#: ../../rst/playbook_guide/playbooks_async.rst:105 -msgid "When running with ``poll: 0``, Ansible will not automatically cleanup the async job cache file. You will need to manually clean this up with the :ref:`async_status ` module with ``mode: cleanup``." -msgstr "``poll: 0`` で実行すると、Ansible は非同期ジョブキャッシュファイルを自動的にクリーンアップしません。``mode: cleanup`` で :ref:`async_status ` モジュールを使用して手動でクリーンアップする必要があります。" - -#: ../../rst/playbook_guide/playbooks_async.rst:109 -msgid "If you need a synchronization point with an async task, you can register it to obtain its job ID and use the :ref:`async_status ` module to observe it in a later task. For example:" -msgstr "非同期タスクとの同期ポイントが必要な場合は、これを登録してジョブ ID を取得し、:ref:`async_status ` モジュールを使用して後続のタスクで確認することができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_async.rst:130 -msgid "If the value of ``async:`` is not high enough, this will cause the \"check on it later\" task to fail because the temporary status file that the ``async_status:`` is looking for will not have been written or no longer exist" -msgstr "``async:`` の値が十分に高くない場合は、``async_status:`` が探している一時的なステータスファイルが書き込まれていないか、存在しなくなったため、「後で確認する」タスクが失敗することになります。" - -#: ../../rst/playbook_guide/playbooks_async.rst:135 -msgid "Asynchronous playbook tasks always return changed. If the task is using a module that requires the user to annotate changes with ``changed_when``, ``creates``, and so on, then those should be added to the following ``async_status`` task." -msgstr "非同期 Playbook タスクは常に変更を返します。タスクが、ユーザーが ``changed_when`` および ``creates`` を使用して変更にアノテーションを付ける必要があるモジュールを使用している場合は、それらのタスクを以下の ``async_status`` タスクに追加する必要があります。" - -#: ../../rst/playbook_guide/playbooks_async.rst:139 -msgid "To run multiple asynchronous tasks while limiting the number of tasks running concurrently:" -msgstr "複数の非同期タスクを実行しながら、同時に実行するタスクの数を制限するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_async.rst:182 -#: ../../rst/playbook_guide/playbooks_delegation.rst:167 -msgid ":ref:`playbooks_strategies`" -msgstr ":ref:`playbooks_strategies`" - -#: ../../rst/playbook_guide/playbooks_async.rst:183 -msgid "Options for controlling playbook execution" -msgstr "Playbook の実行を制御するオプション" - -#: ../../rst/playbook_guide/playbooks_async.rst:184 -#: ../../rst/playbook_guide/playbooks_blocks.rst:186 -#: ../../rst/playbook_guide/playbooks_debugger.rst:337 -#: ../../rst/playbook_guide/playbooks_delegation.rst:165 -#: ../../rst/playbook_guide/playbooks_environment.rst:148 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:268 -#: ../../rst/playbook_guide/playbooks_prompts.rst:115 -#: ../../rst/playbook_guide/playbooks_startnstep.rst:43 -#: ../../rst/playbook_guide/playbooks_tags.rst:425 -#: ../../rst/playbook_guide/playbooks_templating.rst:25 -#: ../../rst/playbook_guide/playbooks_tests.rst:527 -msgid ":ref:`playbooks_intro`" -msgstr ":ref:`playbooks_intro`" - -#: ../../rst/playbook_guide/playbooks_async.rst:186 -#: ../../rst/playbook_guide/playbooks_blocks.rst:190 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:548 -#: ../../rst/playbook_guide/playbooks_debugger.rst:339 -#: ../../rst/playbook_guide/playbooks_delegation.rst:171 -#: ../../rst/playbook_guide/playbooks_environment.rst:150 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:276 -#: ../../rst/playbook_guide/playbooks_filters.rst:2200 -#: ../../rst/playbook_guide/playbooks_lookups.rst:36 -#: ../../rst/playbook_guide/playbooks_loops.rst:496 -#: ../../rst/playbook_guide/playbooks_prompts.rst:121 -#: ../../rst/playbook_guide/playbooks_strategies.rst:251 -#: ../../rst/playbook_guide/playbooks_tags.rst:429 -#: ../../rst/playbook_guide/playbooks_templating.rst:31 -#: ../../rst/playbook_guide/playbooks_tests.rst:539 -#: ../../rst/playbook_guide/playbooks_variables.rst:531 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:5 -msgid "Blocks" -msgstr "ブロック" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:7 -msgid "Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages." -msgstr "ブロックは、タスクの論理的なグループを作ります。また、ブロックにはタスクのエラーを処理する方法があり、多くのプログラミング言語の例外処理に似ています。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:13 -msgid "Grouping tasks with blocks" -msgstr "ブロックを使用したタスクのグループ化" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:15 -msgid "All tasks in a block inherit directives applied at the block level. Most of what you can apply to a single task (with the exception of loops) can be applied at the block level, so blocks make it much easier to set data or directives common to the tasks. The directive does not affect the block itself, it is only inherited by the tasks enclosed by a block. For example, a `when` statement is applied to the tasks within a block, not to the block itself." -msgstr "ブロック内のすべてのタスクは、ブロックレベルで適用されるディレクティブを継承します。単一のタスクに適用できるもの (ループを除く) のほとんどは、ブロックレベルで適用できるため、ブロックを使用すると、タスクに共通するデータやディレクティブを設定することが非常に簡単になります。ディレクティブはブロック自体には影響せず、ブロックで囲まれたタスクにのみ継承されます。たとえば、`when` 文は、ブロック自体にではなく、ブロック内のタスクに適用されます。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:17 -msgid "Block example with named tasks inside the block" -msgstr "内部に名前付きタスクを含むブロックの例" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:46 -msgid "In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: true`` ensures that Ansible continues to execute the playbook even if some of the tasks fail." -msgstr "上の例では、Ansible がブロック内の 3 つのタスクをそれぞれ実行する前に、「when」条件が評価されます。また、3 つのタスクはすべて、特権昇格ディレクティブを継承し、root ユーザーとして実行します。最後に、``ignore_errors: true`` は、一部のタスクが失敗しても、Ansible が Playbook の実行を継続することを保証します。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:48 -msgid "Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook." -msgstr "ブロックの名前は、Ansible 2.3 から利用できるようになりました。Playbook の実行時に実行されているタスクの可視性を高めるために、ブロック内やその他の場所で、すべてのタスクに名前を使用することが推奨されます。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:53 -msgid "Handling errors with blocks" -msgstr "ブロックを使用したエラーの処理" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:55 -msgid "You can control how Ansible responds to task errors using blocks with ``rescue`` and ``always`` sections." -msgstr "``rescue`` セクションおよび ``always`` セクションのブロックを使用して、Ansible がタスクエラーに対応する方法を制御できます。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:57 -msgid "Rescue blocks specify tasks to run when an earlier task in a block fails. This approach is similar to exception handling in many programming languages. Ansible only runs rescue blocks after a task returns a 'failed' state. Bad task definitions and unreachable hosts will not trigger the rescue block." -msgstr "レスキューブロックは、ブロック内の先行タスクが失敗したときに実行するタスクを指定します。このアプローチは、多くのプログラミング言語における例外処理に似ています。Ansible は、タスクが「失敗」状態を返した後にのみレスキューブロックを実行します。誤ったタスク定義や到達不可能なホストでは、レスキューブロックは実行しません。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:60 -msgid "Block error handling example" -msgstr "ブロックエラー処理例" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:82 -msgid "You can also add an ``always`` section to a block. Tasks in the ``always`` section run no matter what the task status of the previous block is." -msgstr "``always`` セクションをブロックに追加することもできます。前のブロックのタスクステータスに関係なく、``always`` セクションのタスクは実行します。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:85 -msgid "Block with always section" -msgstr "always セクションのあるブロック" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:106 -msgid "Together, these elements offer complex error handling." -msgstr "この要素をまとめると、複雑なエラー処理を行います。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:108 -msgid "Block with all sections" -msgstr "すべてのセクションのブロック" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:140 -msgid "The tasks in the ``block`` execute normally. If any tasks in the block return ``failed``, the ``rescue`` section executes tasks to recover from the error. The ``always`` section runs regardless of the results of the ``block`` and ``rescue`` sections." -msgstr "``block`` のタスクは正常に実行されます。ブロック内のいずれかのタスクが ``failed`` を返すと、``rescue`` セクションはエラーから回復するためのタスクを実行します。``always`` セクションは、``block`` セクションと ``rescue`` セクションの結果に関わらず実行されます。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:142 -msgid "If an error occurs in the block and the rescue task succeeds, Ansible reverts the failed status of the original task for the run and continues to run the play as if the original task had succeeded. The rescued task is considered successful, and does not trigger ``max_fail_percentage`` or ``any_errors_fatal`` configurations. However, Ansible still reports a failure in the playbook statistics." -msgstr "ブロック内でエラーが発生し、レスキュータスクが成功した場合、Ansible は実行中の元のタスクの失敗ステータスを元に戻し、元のタスクが成功したかのようにプレイの実行を継続します。レスキューとなったタスクは成功したとみなされ、``max_fail_percentage`` や ``any_errors_fatal`` の設定は発生しません。ただし、Ansible は Playbook の統計で失敗を報告します。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:144 -msgid "You can use blocks with ``flush_handlers`` in a rescue task to ensure that all handlers run even if an error occurs:" -msgstr "レスキュータスクにおいて ``flush_handlers`` でブロックを使用し、エラーが発生した場合でもすべてのハンドラーが実行されるようにします。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:146 -msgid "Block run handlers in error handling" -msgstr "エラー処理におけるブロック実行ハンドラー" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:172 -msgid "Ansible provides a couple of variables for tasks in the ``rescue`` portion of a block:" -msgstr "Ansible は、ブロックの ``rescue`` の部分にタスクの変数をいくつか提供します。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:175 -msgid "ansible_failed_task" -msgstr "ansible_failed_task" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:175 -msgid "The task that returned 'failed' and triggered the rescue. For example, to get the name use ``ansible_failed_task.name``." -msgstr "「失敗した」と返され、レスキューのきっかけとなったタスクです。たとえば、名前を取得するには ``ansible_failed_task.name`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:178 -msgid "ansible_failed_result" -msgstr "ansible_failed_result" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:178 -msgid "The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the ``register`` keyword." -msgstr "レスキューをトリガーした失敗したタスクの戻り値。これは、``register`` キーワードでこの変数を使用するのと同じです。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:182 -msgid "In ``ansible-core`` 2.14 or later, both variables are propagated from an inner block to an outer ``rescue`` portion of a block." -msgstr "``ansible-core`` 2.14 以降では、両方の変数が内部ブロックからブロックの外部の ``rescue`` 部分に伝播されます。" - -#: ../../rst/playbook_guide/playbooks_blocks.rst:189 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:543 -#: ../../rst/playbook_guide/playbooks_filters.rst:2197 -#: ../../rst/playbook_guide/playbooks_loops.rst:489 -#: ../../rst/playbook_guide/playbooks_strategies.rst:250 -#: ../../rst/playbook_guide/playbooks_tags.rst:428 -#: ../../rst/playbook_guide/playbooks_tests.rst:536 -#: ../../rst/playbook_guide/playbooks_variables.rst:526 -msgid "Playbook organization by roles" -msgstr "ロール別の Playbook の組織" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:5 -msgid "Validating tasks: check mode and diff mode" -msgstr "タスクの検証: チェックモードと差分モード" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:7 -msgid "Ansible provides two modes of execution that validate tasks: check mode and diff mode. These modes can be used separately or together. They are useful when you are creating or editing a playbook or role and you want to know what it will do. In check mode, Ansible runs without making any changes on remote systems. Modules that support check mode report the changes they would have made. Modules that do not support check mode report nothing and do nothing. In diff mode, Ansible provides before-and-after comparisons. Modules that support diff mode display detailed information. You can combine check mode and diff mode for detailed validation of your playbook or role." -msgstr "Ansible には、タスクを検証するために、チェックモードと差分モードという 2 つの実行モードが用意されています。これらのモードは、別々に使用することも、一緒に使用することもできます。これらのモードは、Playbook やロールを作成または編集する際に、その実行内容を知りたい場合に便利です。チェックモードでは、Ansible はリモートシステムに変更を加えずに実行します。チェックモードをサポートするモジュールは、自身が行った変更を報告します。チェックモードをサポートしていないモジュールは、何も報告せず、何も行いません。差分モードでは、Ansible は事前と事後の比較を行います。差分モードをサポートするモジュールは、詳細情報を表示します。チェックモードと差分モードを組み合わせて、Playbook やロールの詳細な検証を行うことができます。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:13 -msgid "Using check mode" -msgstr "チェックモードの使用" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:15 -msgid "Check mode is just a simulation. It will not generate output for tasks that use :ref:`conditionals based on registered variables ` (results of prior tasks). However, it is great for validating configuration management playbooks that run on one node at a time. To run a playbook in check mode:" -msgstr "チェックモードはあくまでもシミュレーションです。:ref:`conditionals based on registered variables ` (先行タスクの結果) を使用するタスクの出力は生成されません。しかし、一度に 1 つのノードで実行する構成管理の Playbook を検証するには最適です。Playbook をチェックモードで実行するには以下を行います。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:24 -msgid "Enforcing or preventing check mode on tasks" -msgstr "タスクでのチェックモードの強制または禁止" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:28 -msgid "If you want certain tasks to run in check mode always, or never, regardless of whether you run the playbook with or without ``--check``, you can add the ``check_mode`` option to those tasks:" -msgstr "Playbook を実行する際に ``--check`` を付けるかどうかに関わらず、特定のタスクを常にチェックモードで実行する場合は、それらのタスクに ``check_mode`` オプションを追加します。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:30 -msgid "To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: yes``." -msgstr "``--check`` を使用せずに Playbook が呼び出された場合でも、タスクを強制的にチェックモードで実行するには、``check_mode: yes`` を設定します。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:31 -msgid "To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: no``." -msgstr "Playbook が ``--check`` で呼び出された場合でも、タスクを強制的に通常モードで実行し、システムに変更を加えるには、``check_mode: no`` を設定します。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:33 -#: ../../rst/playbook_guide/playbooks_filters.rst:809 -#: ../../rst/playbook_guide/playbooks_tags.rst:285 -#: ../../rst/playbook_guide/playbooks_tags.rst:315 -msgid "For example:" -msgstr "例:" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:50 -msgid "Running single tasks with ``check_mode: yes`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes." -msgstr "``check_mode: yes`` を使用してシングルタスクを実行すると、Ansible モジュールをテストする際に便利です。モジュール自体をテストしたり、モジュールが変更を行う条件をテストしたりすることができます。これらのタスクに変数 (:ref:`playbooks_conditionals` を参照) を登録すると、潜在的な変更についてさらに詳しく知ることができます。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:52 -msgid "Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``." -msgstr "バージョン 2.2 以前では、``check_mode: no`` に相当するものだけが存在していました。その表記法は ``always_run: yes`` でした。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:55 -msgid "Skipping tasks or ignoring errors in check mode" -msgstr "タスクをスキップまたはチェックモードでエラーを無視する" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:59 -msgid "If you want to skip a task or ignore errors on a task when you run Ansible in check mode, you can use a boolean magic variable ``ansible_check_mode``, which is set to ``True`` when Ansible runs in check mode. For example:" -msgstr "Ansible をチェックモードで実行する際に、タスクをスキップしたり、タスクのエラーを無視したりする場合は、ブール型のマジック変数 ``ansible_check_mode`` を使用することができます。この変数は、Ansible をチェックモードで実行すると、``True`` に設定されます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:80 -msgid "Using diff mode" -msgstr "差分モードの使用" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:82 -msgid "The ``--diff`` option for ansible-playbook can be used alone or with ``--check``. When you run in diff mode, any module that supports diff mode reports the changes made or, if used with ``--check``, the changes that would have been made. Diff mode is most common in modules that manipulate files (for example, the template module) but other modules might also show 'before and after' information (for example, the user module)." -msgstr "ansible-playbook の ``--diff`` オプションは、単独でも ``--check`` と併用しても構いません。差分モードで実行すると、差分モードをサポートしているすべてのモジュールが、行われた変更を報告します (``--check`` と併用する場合は、行われたであろう変更を報告します)。差分モードは、ファイルを操作するモジュール (template モジュールなど) で最も一般的ですが、その他のモジュールでも「変更前と変更後」の情報を表示することがあります (user モジュールなど)。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:84 -msgid "Diff mode produces a large amount of output, so it is best used when checking a single host at a time. For example:" -msgstr "差分モードは大量の出力を生成するため、一度に 1 つのホストを確認するときに使うのが最適です。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:93 -msgid "Enforcing or preventing diff mode on tasks" -msgstr "タスクでの差分モードの強制または禁止" - -#: ../../rst/playbook_guide/playbooks_checkmode.rst:95 -msgid "Because the ``--diff`` option can reveal sensitive information, you can disable it for a task by specifying ``diff: no``. For example:" -msgstr "``--diff`` オプションは機密情報を表示する可能性があるため、``diff: no`` を指定してタスクに対してこれを無効にすることができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:5 -msgid "Conditionals" -msgstr "条件分岐 (Conditional)" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:7 -msgid "In a playbook, you may want to execute different tasks, or have different goals, depending on the value of a fact (data about the remote system), a variable, or the result of a previous task. You may want the value of some variables to depend on the value of other variables. Or you may want to create additional groups of hosts based on whether the hosts match other criteria. You can do all of these things with conditionals." -msgstr "Playbook では、ファクト (リモートシステムに関するデータ)、変数、または以前のタスクの結果の値に応じて、異なるタスクを実行したり、異なるゴールを設定したりすることができます。また、ある変数の値に応じて別の変数の値を変更したい場合もあります。また、ホストが他の基準に一致するかどうかに基づいて、ホストの追加グループを作成することもできます。これらのことはすべて、条件分岐で実現できます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:9 -msgid "Ansible uses Jinja2 :ref:`tests ` and :ref:`filters ` in conditionals. Ansible supports all the standard tests and filters, and adds some unique ones as well." -msgstr "Ansible は Jinja2 の :ref:`テスト ` および :ref:`フィルター ` を条件分岐で使用しています。Ansible は標準的なテストやフィルターをすべてサポートしており、独自のものもいくつか追加されています。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:13 -msgid "There are many options to control execution flow in Ansible. You can find more examples of supported conditionals at ``_." -msgstr "Ansible で実行フローを制御するオプションは多数あります。サポートされている条件分岐の例は、``_ で確認できます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:21 -msgid "Basic conditionals with ``when``" -msgstr "``when`` を使用する基本的な条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:23 -msgid "The simplest conditional statement applies to a single task. Create the task, then add a ``when`` statement that applies a test. The ``when`` clause is a raw Jinja2 expression without double curly braces (see :ref:`group_by_module`). When you run the task or playbook, Ansible evaluates the test for all hosts. On any host where the test passes (returns a value of True), Ansible runs that task. For example, if you are installing mysql on multiple machines, some of which have SELinux enabled, you might have a task to configure SELinux to allow mysql to run. You would only want that task to run on machines that have SELinux enabled:" -msgstr "最も簡単な条件文は、1 つのタスクに適用されるものです。タスクを作成し、テストを適用する ``when`` の文を追加します。``when`` 句は、二重中括弧のない生の Jinja2 式です (:ref:`group_by_module` 参照)。タスクや Playbook を実行すると、Ansible はすべてのホストに対してテストを評価します。テストにパスする (True の値を返す) ホストでは、Ansible はそのタスクを実行します。たとえば、複数のマシンに mysql をインストールし、そのうちのいくつかのマシンでは SELinux が有効になっている場合は、mysql の実行を許可するように SELinux を設定するタスクがあります。このタスクは、SELinux が有効になっているマシンでのみ実行されるようにします。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:37 -msgid "Conditionals based on ansible_facts" -msgstr "ansible_facts に基づく条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:39 -msgid "Often you want to execute or skip a task based on facts. Facts are attributes of individual hosts, including IP address, operating system, the status of a filesystem, and many more. With conditionals based on facts:" -msgstr "ファクトに基づいてタスクを実行したりスキップしたりしたい場合がよくあります。ファクトとは、IP アドレス、オペレーティングシステム、ファイルシステムの状態など、個々のホストの属性のことです。ファクトに基づく条件分岐で、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:41 -msgid "You can install a certain package only when the operating system is a particular version." -msgstr "特定のパッケージは、オペレーティングシステムが特定のバージョンの場合にのみインストールできます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:42 -msgid "You can skip configuring a firewall on hosts with internal IP addresses." -msgstr "内部 IP アドレスを持つホストでファイアウォールの設定を省略できます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:43 -msgid "You can perform cleanup tasks only when a filesystem is getting full." -msgstr "ファイルシステムが満杯になった場合にのみ、クリーンアップタスクを実行することができます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:45 -msgid "See :ref:`commonly_used_facts` for a list of facts that frequently appear in conditional statements. Not all facts exist for all hosts. For example, the 'lsb_major_release' fact used in an example below only exists when the lsb_release package is installed on the target host. To see what facts are available on your systems, add a debug task to your playbook:" -msgstr "条件文に頻繁に現れるファクトの一覧は、:ref:`commonly_used_facts` を参照してください。すべてのファクトがすべてのホストに存在するわけではありません。たとえば、以下の例で使用されている「lsb_major_release」ファクトは、ターゲットホストに lsb_release パッケージがインストールされている場合にのみ存在します。システム上で利用可能なファクトを確認するには、Playbook にデバッグタスクを追加します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:53 -msgid "Here is a sample conditional based on a fact:" -msgstr "以下は、ファクトに基づく条件分岐の例です。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:62 -msgid "If you have multiple conditions, you can group them with parentheses:" -msgstr "複数の条件がある場合は、括弧でグループ化できます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:72 -msgid "You can use `logical operators `_ to combine conditions. When you have multiple conditions that all need to be true (that is, a logical ``and``), you can specify them as a list:" -msgstr "`logical operators `_ を使用して条件を組み合わせることができます。すべてが True である必要がある複数の条件がある場合 (つまり、論理的な ``and``)、それらをリストとして指定することができます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:83 -msgid "If a fact or variable is a string, and you need to run a mathematical comparison on it, use a filter to ensure that Ansible reads the value as an integer:" -msgstr "ファクトまたは変数が文字列で、それに対して数学比較を実行する必要がある場合は、フィルターを使用して Ansible が値を整数として読み取るようにします。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:94 -msgid "Conditions based on registered variables" -msgstr "登録済みの変数に基づく条件" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:96 -msgid "Often in a playbook you want to execute or skip a task based on the outcome of an earlier task. For example, you might want to configure a service after it is upgraded by an earlier task. To create a conditional based on a registered variable:" -msgstr "Playbook では、以前のタスクの結果に基づいてタスクを実行またはスキップしたい場合がよくあります。たとえば、以前のタスクによってサービスがアップグレードされた後に、そのサービスを設定したい場合などです。登録された変数に基づいて条件分岐を作成するには、次のようにします。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:98 -msgid "Register the outcome of the earlier task as a variable." -msgstr "以前のタスクの結果を変数として登録します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:99 -msgid "Create a conditional test based on the registered variable." -msgstr "登録した変数に基づいて条件分岐テストを作成します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:101 -msgid "You create the name of the registered variable using the ``register`` keyword. A registered variable always contains the status of the task that created it as well as any output that task generated. You can use registered variables in templates and action lines as well as in conditional ``when`` statements. You can access the string contents of the registered variable using ``variable.stdout``. For example:" -msgstr "登録された変数の名前は、``register`` キーワードを使用して作成します。登録された変数には、そのキーワードを作成したタスクのステータスと、そのタスクが生成した出力が常に含まれています。登録された変数は、テンプレートやアクション行、および条件付きの ``when`` 文で使用できます。登録された変数の文字列内容にアクセスするには、``variable.stdout`` を使用します。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:118 -msgid "You can use registered results in the loop of a task if the variable is a list. If the variable is not a list, you can convert it into a list, with either ``stdout_lines`` or with ``variable.stdout.split()``. You can also split the lines by other fields:" -msgstr "登録された結果は、変数がリストの場合、タスクのループ内で使用できます。変数がリストでない場合は、``stdout_lines`` または ``variable.stdout.split()`` でリストに変換できます。また、他のフィールドで行を分割することもできます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:138 -msgid "The string content of a registered variable can be empty. If you want to run another task only on hosts where the stdout of your registered variable is empty, check the registered variable's string contents for emptiness:" -msgstr "登録された変数の文字列内容は空になることがあります。登録された変数の標準出力が空のホストでのみ別のタスクを実行したい場合は、登録された変数の文字列内容が空であるかどうかをチェックします。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:156 -msgid "Ansible always registers something in a registered variable for every host, even on hosts where a task fails or Ansible skips a task because a condition is not met. To run a follow-up task on these hosts, query the registered variable for ``is skipped`` (not for \"undefined\" or \"default\"). See :ref:`registered_variables` for more information. Here are sample conditionals based on the success or failure of a task. Remember to ignore errors if you want Ansible to continue executing on a host when a failure occurs:" -msgstr "タスクが失敗したホストや、条件が満たされずに Ansible がタスクをスキップしたホストであっても、Ansible は常にすべてのホストの登録変数に何かを登録します。これらのホストでフォローアップタスクを実行するには、登録済みの変数に ``is skipped`` を照会します (「undefined」や「default」ではありません)。詳細は、「:ref:`registered_variables`」を参照してください。以下は、タスクの成功または失敗に基づく条件分岐のサンプルです。失敗したときにホスト上で Ansible の実行を継続させたい場合は、エラーを無視することを忘れないでください。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:178 -msgid "Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid." -msgstr "古いバージョンの Ansible では、``success`` および ``fail`` が使用されていましたが、``succeeded`` および ``failed`` は正しい時制を使用します。このオプションはすべて有効になりました。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:182 -msgid "Conditionals based on variables" -msgstr "変数に基づく条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:184 -msgid "You can also create conditionals based on variables defined in the playbooks or inventory. Because conditionals require boolean input (a test must evaluate as True to trigger the condition), you must apply the ``| bool`` filter to non boolean variables, such as string variables with content like 'yes', 'on', '1', or 'true'. You can define variables like this:" -msgstr "また、Playbook やインベントリーで定義された変数に基づいて、条件分岐を作成することもできます。条件分岐にはブール値の入力が必要なため (条件を成立させるためには、テストが True と評価されなければなりません)、「yes」、「on」、「1」、「true」などの内容を持つ文字列変数など、ブール値以外の変数には、``| bool`` フィルターを適用する必要があります。変数は次のように定義できます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:192 -msgid "With the variables above, Ansible would run one of these tasks and skip the other:" -msgstr "上記の変数を使用すると、Ansible はこれらのタスクのいずれかを実行し、他のタスクを省略します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:205 -msgid "If a required variable has not been set, you can skip or fail using Jinja2's `defined` test. For example:" -msgstr "必要な変数が設定されていない場合は、省略するか、Jinja2 の `定義済み` テストを使用して失敗します。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:218 -msgid "This is especially useful in combination with the conditional import of vars files (see below). As the examples show, you do not need to use `{{ }}` to use variables inside conditionals, as these are already implied." -msgstr "これは、変数ファイルの条件分岐インポートとの組み合わせで特に有効です (以下参照)。これらの例が示すように、条件分岐の中で変数を使用するために `{{ }}` を使用する必要はありません。それらはすでに暗示されているためです。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:224 -msgid "Using conditionals in loops" -msgstr "ループでの条件分岐の使用" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:226 -msgid "If you combine a ``when`` statement with a :ref:`loop `, Ansible processes the condition separately for each item. This is by design, so you can execute the task on some items in the loop and skip it on other items. For example:" -msgstr "``when`` 文と :ref:`loop ` を組み合わせた場合、Ansible は各アイテムに対して個別に条件を処理します。これは意図的なもので、ループ内の一部のアイテムでタスクを実行し、他のアイテムではスキップすることができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:236 -msgid "If you need to skip the whole task when the loop variable is undefined, use the `|default` filter to provide an empty iterator. For example, when looping over a list:" -msgstr "ループ変数が未定義のときにタスク全体を省略する必要がある場合は、`|default` フィルターを使用して空のイテレーターを指定します。たとえば、リストをループする場合は、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:245 -msgid "You can do the same thing when looping over a dict:" -msgstr "同じことが、ディクショナリーをループするときにもできます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:257 -msgid "Loading custom facts" -msgstr "カスタムファクトの読み込み中" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:259 -msgid "You can provide your own facts, as described in :ref:`developing_modules`. To run them, just make a call to your own custom fact gathering module at the top of your list of tasks, and variables returned there will be accessible to future tasks:" -msgstr ":ref:`developing_modules` で説明しているように、独自のファクトを提供することができます。それらを実行するには、タスクリストの先頭にある独自のカスタムファクト収集モジュールを呼び出すだけで、そこから返された変数は将来のタスクにアクセスできるようになります。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:274 -msgid "Conditionals with re-use" -msgstr "再利用による条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:276 -msgid "You can use conditionals with re-usable tasks files, playbooks, or roles. Ansible executes these conditional statements differently for dynamic re-use (includes) and for static re-use (imports). See :ref:`playbooks_reuse` for more information on re-use in Ansible." -msgstr "条件分岐は、再利用可能なタスクファイル、Playbook、またはロールで使用できます。Ansible はこれらの条件文を、動的再利用 (インクルード) および静的再利用 (インポート) で異なる方法で実行します。Ansible での再利用の詳細は、「:ref:`playbooks_reuse`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:281 -msgid "Conditionals with imports" -msgstr "インポートのある条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:283 -msgid "When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, if you want to define and then display a variable that was not previously defined, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``:" -msgstr "インポートステートメントに条件分岐を追加すると、Ansible はインポートされたファイル内のすべてのタスクにその条件を適用します。この動作は、:ref:`tag_inheritance` と同等です。Ansible は、すべてのタスクに条件を適用し、各タスクを個別に評価します。たとえば、以前に定義されていない変数を定義して表示する場合に、``main.yml`` という Playbookと、``other_tasks.yml`` というタスクファイルがあるとします。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:303 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:360 -msgid "Ansible expands this at execution time to the equivalent of:" -msgstr "Ansible は、実行時にこれを以下に相当するものに拡張します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:319 -msgid "If ``x`` is initially defined, both tasks are skipped as intended. But if ``x`` is initially undefined, the debug task will be skipped since the conditional is evaluated for every imported task. The conditional will evaluate to ``true`` for the ``set_fact`` task, which will define the variable and cause the ``debug`` conditional to evaluate to ``false``." -msgstr "``x`` が最初に定義されている場合、両方のタスクが意図した通りにスキップされます。ただし、``x`` が最初に定義されていない場合は、インポートされたすべてのタスクに対して条件が評価されるため、デバッグタスクはスキップされます。この条件は ``set_fact`` に対して ``true`` と評価し、これにより変数が定義され、``debug`` の条件が ``false`` と評価されます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:321 -msgid "If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself." -msgstr "このような動作を望まない場合は、``include_*`` 文を使用して、その文自体にのみ条件を適用します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:332 -msgid "Now if ``x`` is initially undefined, the debug task will not be skipped because the conditional is evaluated at the time of the include and does not apply to the individual tasks." -msgstr "``x`` が最初に定義されていない場合には、include 時に条件が評価され、個別のタスクには適用されないため、デバッグタスクはスキップされません。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:334 -msgid "You can apply conditions to ``import_playbook`` as well as to the other ``import_*`` statements. When you use this approach, Ansible returns a 'skipped' message for every task on every host that does not match the criteria, creating repetitive output. In many cases the :ref:`group_by module ` can be a more streamlined way to accomplish the same objective; see :ref:`os_variance`." -msgstr "``import_playbook`` には、他の ``import_*`` 文と同様に条件を適用できます。この方法を使用すると、Ansible は基準に一致しないすべてのホスト上のすべてのタスクに対して「skipped」メッセージを返し、反復的な出力を作成します。多くの場合、:ref:`group_by モジュール ` は、同じ目的を達成するためのより合理的な方法となります。「:ref:`os_variance`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:339 -msgid "Conditionals with includes" -msgstr "includes を持つ条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:341 -msgid "When you use a conditional on an ``include_*`` statement, the condition is applied only to the include task itself and not to any other tasks within the included file(s). To contrast with the example used for conditionals on imports above, look at the same playbook and tasks file, but using an include instead of an import:" -msgstr "``include_*`` 文に条件分岐を使用すると、その条件はインクルードタスク自体にのみ適用され、インクルードファイル内の他のタスクには適用されません。上記のインポートに対する条件分岐の例と対比するために、同じ Playbook とタスクファイルを見てください。ただし、インポートの代わりにインクルードを使用しています。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:380 -msgid "By using ``include_tasks`` instead of ``import_tasks``, both tasks from ``other_tasks.yml`` will be executed as expected. For more information on the differences between ``include`` v ``import`` see :ref:`playbooks_reuse`." -msgstr "``import_tasks`` の代わりに ``include_tasks`` を使用すると、``other_tasks.yml`` からの両方のタスクが想定どおりに実行されます。``include`` と ``import`` の相違点は、「:ref:`playbooks_reuse`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:383 -msgid "Conditionals with roles" -msgstr "ロールを含む条件分岐" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:385 -msgid "There are three ways to apply conditions to roles:" -msgstr "状態をロールに適用する方法は 3 つあります。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:387 -msgid "Add the same condition or conditions to all tasks in the role by placing your ``when`` statement under the ``roles`` keyword. See the example in this section." -msgstr "``when`` 文を ``roles`` キーワードの下に置くことで、ロール内のすべてのタスクに同じ条件を追加します。このセクションの例を参照してください。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:388 -msgid "Add the same condition or conditions to all tasks in the role by placing your ``when`` statement on a static ``import_role`` in your playbook." -msgstr "Playbook の静的 ``import_role`` に ``when`` 文を配置して、ロール内のすべてのタスクに同じ条件を追加します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:389 -msgid "Add a condition or conditions to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role based on your ``when`` statement. To select or skip tasks within the role, you must have conditions set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the condition or conditions to the include. When you use this approach, Ansible applies the condition to the include itself plus any tasks in the role that also have that ``when`` statement." -msgstr "ロール自体の中の個々のタスクまたはブロックに条件を追加します。これは、``when`` 文に基づいてロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックに条件を設定し、Playbook で動的 ``include_role`` を使用し、条件をインクルードに追加する必要があります。この方法を使用すると、Ansible は条件をインクルード自体に加えて、``when`` の文を持つロール内のすべてのタスクに適用します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:391 -msgid "When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds the conditions you define to all the tasks in the role. For example:" -msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義した条件をロール内のすべてのタスクに追加します。たとえば、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:403 -msgid "Selecting variables, files, or templates based on facts" -msgstr "ファクトに基づいた変数、ファイル、またはテンプレートの選択" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:405 -msgid "Sometimes the facts about a host determine the values you want to use for certain variables or even the file or template you want to select for that host. For example, the names of packages are different on CentOS and on Debian. The configuration files for common services are also different on different OS flavors and versions. To load different variables file, templates, or other files based on a fact about the hosts:" -msgstr "ホストに関するファクトによって、特定の変数に使用する値や、そのホスト用に選択するファイルやテンプレートが決定することがあります。たとえば、パッケージの名前は CentOS と Debian では異なります。また、一般的なサービスの設定ファイルも、OS のフレーバーやバージョンごとに異なります。ホストに関するファクトに基づいて、異なる変数ファイルやテンプレートなどを読み込むには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:407 -msgid "name your vars files, templates, or files to match the Ansible fact that differentiates them" -msgstr "変数ファイル、テンプレート、またはファイルを区別する Ansible ファクトに合わせて名前を付ける" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:409 -msgid "select the correct vars file, template, or file for each host with a variable based on that Ansible fact" -msgstr "Ansible ファクトに基づいて変数を使用して、各ホストの正しい変数ファイル、テンプレート、またはファイルを選択します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:411 -msgid "Ansible separates variables from tasks, keeping your playbooks from turning into arbitrary code with nested conditionals. This approach results in more streamlined and auditable configuration rules because there are fewer decision points to track." -msgstr "Ansible は、変数とタスクを分離することで、Playbook がネストされた条件分岐による任意のコードにならないようにしています。このアプローチでは、追跡すべき決定ポイントが少なくなるため、より合理的で監査可能な設定ルールになります。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:414 -msgid "Selecting variables files based on facts" -msgstr "ファクトに基づく変数ファイルの選択" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:416 -msgid "You can create a playbook that works on multiple platforms and OS versions with a minimum of syntax by placing your variable values in vars files and conditionally importing them. If you want to install Apache on some CentOS and some Debian servers, create variables files with YAML keys and values. For example:" -msgstr "変数の値を vars ファイルに置き、条件付きでインポートすることで、最小限の構文で複数のプラットフォームや OS バージョンで動作する Playbook を作成することができます。一部の CentOS と一部の Debian サーバーに Apache をインストールする場合は、YAML のキーと値で変数ファイルを作成します。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:425 -msgid "Then import those variables files based on the facts you gather on the hosts in your playbook:" -msgstr "次に、Playbook のホストに収集するファクトに基づいて、これらの変数ファイルをインポートします。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:441 -msgid "Ansible gathers facts on the hosts in the webservers group, then interpolates the variable \"ansible_facts['os_family']\" into a list of filenames. If you have hosts with Red Hat operating systems (CentOS, for example), Ansible looks for 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. For Debian hosts, Ansible first looks for 'vars/Debian.yml', before falling back on 'vars/os_defaults.yml'. If no files in the list are found, Ansible raises an error." -msgstr "Ansible は webservers グループに属するホストのファクトを収集し、変数「ansible_facts['os_family']」をファイル名のリストに補間します。Red Hat オペレーティングシステムを搭載したホスト (CentOS など) がある場合、Ansible は「vars/RedHat.yml」を探します。このファイルが存在しない場合、Ansibleは「vars/os_defaults.yml」の読み込みを試みます。Debian ホストの場合、Ansible はまず「vars/Debian.yml」を探し、その後で「vars/os_defaults.yml」にフォールバックします。リスト内のファイルが見つからない場合は、Ansible がエラーを出力します。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:444 -msgid "Selecting files and templates based on facts" -msgstr "ファクトに基づくファイルとテンプレートの選択" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:446 -msgid "You can use the same approach when different OS flavors or versions require different configuration files or templates. Select the appropriate file or template based on the variables assigned to each host. This approach is often much cleaner than putting a lot of conditionals into a single template to cover multiple OS or package versions." -msgstr "OS のフレーバーやバージョンによって、設定ファイルやテンプレートが異なる場合も同様の方法で対応できます。各ホストに割り当てられた変数に基づいて、適切なファイルやテンプレートを選択します。この方法は、複数の OS やパッケージのバージョンに対応するために 1 つのテンプレートに多くの条件分岐を入れるよりも、はるかにすっきりすることが多いです。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:448 -msgid "For example, you can template out a configuration file that is very different between, say, CentOS and Debian:" -msgstr "例えば、CentOS と Debian の間で大きく異なる設定ファイルをテンプレート化することができます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:466 -msgid "Commonly-used facts" -msgstr "一般的に使用されるファクト" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:468 -msgid "The following Ansible facts are frequently used in conditionals." -msgstr "以下の Ansible ファクトは、条件分岐で頻繁に使用されます。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:473 -msgid "ansible_facts['distribution']" -msgstr "ansible_facts['distribution']" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:475 -#: ../../rst/playbook_guide/playbooks_conditionals.rst:515 -msgid "Possible values (sample, not complete list):" -msgstr "使用できる値 (完全リストではなく一部です):" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:506 -msgid "ansible_facts['distribution_major_version']" -msgstr "ansible_facts['distribution_major_version']" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:508 -msgid "The major version of the operating system. For example, the value is `16` for Ubuntu 16.04." -msgstr "オペレーティングシステムのメジャーバージョンです。たとえば、Ubuntu 16.04 の場合は `16` となります。" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:513 -msgid "ansible_facts['os_family']" -msgstr "ansible_facts['os_family']" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:544 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:270 -#: ../../rst/playbook_guide/playbooks_filters.rst:2198 -#: ../../rst/playbook_guide/playbooks_intro.rst:148 -#: ../../rst/playbook_guide/playbooks_loops.rst:490 -#: ../../rst/playbook_guide/playbooks_reuse.rst:219 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:598 -#: ../../rst/playbook_guide/playbooks_tests.rst:537 -#: ../../rst/playbook_guide/playbooks_variables.rst:527 -msgid ":ref:`tips_and_tricks`" -msgstr ":ref:`tips_and_tricks`" - -#: ../../rst/playbook_guide/playbooks_conditionals.rst:545 -#: ../../rst/playbook_guide/playbooks_error_handling.rst:271 -#: ../../rst/playbook_guide/playbooks_filters.rst:2199 -#: ../../rst/playbook_guide/playbooks_loops.rst:491 -#: ../../rst/playbook_guide/playbooks_reuse.rst:220 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:599 -#: ../../rst/playbook_guide/playbooks_templating.rst:28 -#: ../../rst/playbook_guide/playbooks_tests.rst:538 -#: ../../rst/playbook_guide/playbooks_variables.rst:528 -msgid "Tips and tricks for playbooks" -msgstr "Playbook のヒントと裏技" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:5 -msgid "Debugging tasks" -msgstr "タスクのデバッグ" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:7 -msgid "Ansible offers a task debugger so you can fix errors during execution instead of editing your playbook and running it again to see if your change worked. You have access to all of the features of the debugger in the context of the task. You can check or set the value of variables, update module arguments, and re-run the task with the new variables and arguments. The debugger lets you resolve the cause of the failure and continue with playbook execution." -msgstr "Ansible にはタスクデバッガーがあり、変更が成功したかどうかを確認するために Playbook を編集して再度実行するのではなく、実行中にエラーを修正することができます。タスクのコンテキスト内で、デバッガーのすべての機能にアクセスできます。変数の値をチェックしたり設定したり、モジュールの引数を更新したり、新しい変数や引数を使用してタスクを再実行したりできます。デバッガーは、失敗の原因を解決し、Playbook の実行を続行することができます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:13 -msgid "Enabling the debugger" -msgstr "デバッガーの有効化" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:15 -msgid "The debugger is not enabled by default. If you want to invoke the debugger during playbook execution, you must enable it first." -msgstr "デバッガーはデフォルトでは有効になっていません。Playbook の実行中にデバッガーを呼び出す場合は、最初に有効にする必要があります。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:17 -msgid "Use one of these three methods to enable the debugger:" -msgstr "以下の 3 つの方法のいずれかを使用してデバッガーを有効にします。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:19 -msgid "with the debugger keyword" -msgstr "デバッガーキーワードの使用" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:20 -msgid "in configuration or an environment variable, or" -msgstr "設定または環境変数で" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:21 -msgid "as a strategy" -msgstr "ストラテジーとして" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:24 -msgid "Enabling the debugger with the ``debugger`` keyword" -msgstr "``debugger`` キーワードでデバッガーを有効にする" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:28 -msgid "You can use the ``debugger`` keyword to enable (or disable) the debugger for a specific play, role, block, or task. This option is especially useful when developing or extending playbooks, plays, and roles. You can enable the debugger on new or updated tasks. If they fail, you can fix the errors efficiently. The ``debugger`` keyword accepts five values:" -msgstr "``debugger`` キーワードを使用すると、特定のプレイ、ロール、ブロック、またはタスクに対してデバッガーを有効 (または無効) にすることができます。このオプションは、Playbook、プレイ、およびロールを開発または拡張する際に特に役立ちます。新規または更新されたタスクでデバッガーを有効にすることができます。失敗しても、効率的にエラーを修正することができます。``debugger`` キーワードは 5 つの値を受け入れます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:34 -msgid "Value" -msgstr "値" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:34 -msgid "Result" -msgstr "結果" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:36 -msgid "always" -msgstr "always" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:36 -msgid "Always invoke the debugger, regardless of the outcome" -msgstr "結果に関係なく、常にデバッガーを呼び出します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:38 -msgid "never" -msgstr "never" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:38 -msgid "Never invoke the debugger, regardless of the outcome" -msgstr "結果に関係なく、デバッガーを呼び出しません。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:40 -msgid "on_failed" -msgstr "on_failed" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:40 -msgid "Only invoke the debugger if a task fails" -msgstr "タスクが失敗した場合に限りデバッガーを呼び出します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:42 -msgid "on_unreachable" -msgstr "on_unreachable" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:42 -msgid "Only invoke the debugger if a host is unreachable" -msgstr "ホストが到達できない場合に限りデバッガーを呼び出します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:44 -msgid "on_skipped" -msgstr "on_skipped" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:44 -msgid "Only invoke the debugger if the task is skipped" -msgstr "タスクがスキップされた場合に限りデバッガーを呼び出します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:48 -msgid "When you use the ``debugger`` keyword, the value you specify overrides any global configuration to enable or disable the debugger. If you define ``debugger`` at multiple levels, such as in a role and in a task, Ansible honors the most granular definition. The definition at the play or role level applies to all blocks and tasks within that play or role, unless they specify a different value. The definition at the block level overrides the definition at the play or role level, and applies to all tasks within that block, unless they specify a different value. The definition at the task level always applies to the task; it overrides the definitions at the block, play, or role level." -msgstr "``debugger`` キーワードを使用すると、指定した値が、デバッガ―を有効または無効にするグローバル構成よりも優先されます。``debugger`` をロールやタスクなどの複数のレベルで定義した場合、Ansible は最も詳細な定義を尊重します。プレイまたはロールのレベルでの定義は、異なる値を指定しない限り、そのプレイまたはロール内のすべてのブロックおよびタスクに適用されます。ブロックレベルの定義は、プレイまたはロールレベルの定義よりも優先され、異なる値が指定されていない限り、そのブロック内のすべてのタスクに適用されます。タスクレベルでの定義は、常にタスクに適用され、ブロック、プレイ、またはロールレベルでの定義よりも優先されます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:51 -msgid "Examples of using the ``debugger`` keyword" -msgstr "``debugger`` キーワードの使用例" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:53 -msgid "Example of setting the ``debugger`` keyword on a task:" -msgstr "タスクに ``debugger`` キーワードを設定する例:" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:61 -msgid "Example of setting the ``debugger`` keyword on a play:" -msgstr "プレイに ``debugger`` キーワードを設定する例:" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:73 -msgid "Example of setting the ``debugger`` keyword at multiple levels:" -msgstr "複数のレベルで ``debugger`` キーワードを設定する例:" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:85 -msgid "In this example, the debugger is set to ``never`` at the play level and to ``on_failed`` at the task level. If the task fails, Ansible invokes the debugger, because the definition on the task overrides the definition on its parent play." -msgstr "この例では、デバッガーは、プレイレベルでは ``never`` に、タスクレベルでは ``on_failed`` に設定されています。タスクが失敗した場合、タスクの定義が親プレイの定義を上書きするため、Ansible はデバッガーを起動します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:88 -msgid "Enabling the debugger in configuration or an environment variable" -msgstr "設定または環境変数でのデバッガーの有効化" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:92 -msgid "You can enable the task debugger globally with a setting in ansible.cfg or with an environment variable. The only options are ``True`` or ``False``. If you set the configuration option or environment variable to ``True``, Ansible runs the debugger on failed tasks by default." -msgstr "タスクデバッガーをグローバルに有効にするには、ansible.cfg 内の設定または環境変数を使用します。オプションは ``True`` または ``False`` のみです。設定オプションまたは環境変数を ``True`` に設定した場合、Ansible はデフォルトで失敗したタスクに対してデバッガーを実行します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:94 -msgid "To enable the task debugger from ansible.cfg, add this setting to the defaults section:" -msgstr "ansible.cfg からタスクデバッガーを有効にするには、以下の設定を defaults セクションに追加します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:101 -msgid "To enable the task debugger with an environment variable, pass the variable when you run your playbook:" -msgstr "環境変数でタスクデバッガーを有効にするには、Playbook の実行時に変数を渡します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:107 -msgid "When you enable the debugger globally, every failed task invokes the debugger, unless the role, play, block, or task explicitly disables the debugger. If you need more granular control over what conditions trigger the debugger, use the ``debugger`` keyword." -msgstr "グローバルにデバッガを有効にすると、ロール、プレイ、ブロック、またはタスクが明示的にデバッガ―を無効にしていない限り、失敗したタスクはすべてデバッガ―を起動します。どのような条件でデバッガーが起動するかをより詳細に制御する必要がある場合は、``debugger`` キーワードを使用します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:110 -msgid "Enabling the debugger as a strategy" -msgstr "ストラテジーとしてのデバッガーの有効化" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:112 -msgid "If you are running legacy playbooks or roles, you may see the debugger enabled as a :ref:`strategy `. You can do this at the play level, in ansible.cfg, or with the environment variable ``ANSIBLE_STRATEGY=debug``. For example:" -msgstr "レガシーの Playbook やロールを実行している場合は、:ref:`strategy ` としてデバッガーが有効になっていることがあります。この設定は、プレイレベル、ansible.cfg、または環境変数 ``ANSIBLE_STRATEGY=debug`` で行うことができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:121 -msgid "Or in ansible.cfg:" -msgstr "または ansible.cfg で以下を行います。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:130 -msgid "This backwards-compatible method, which matches Ansible versions before 2.5, may be removed in a future release." -msgstr "この後方互換性のある方法は、Ansible の 2.5 以前のバージョンに対応していますが、将来のリリースでは削除される可能性があります。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:133 -msgid "Resolving errors in the debugger" -msgstr "デバッガーでエラーの解決" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:135 -msgid "After Ansible invokes the debugger, you can use the seven :ref:`debugger commands ` to resolve the error that Ansible encountered. Consider this example playbook, which defines the ``var1`` variable but uses the undefined ``wrong_var`` variable in a task by mistake." -msgstr "Ansible がデバッガーを起動した後、7 つの :ref:`debugger コマンド ` を使用して、Ansibleが遭遇したエラーを解決することができます。この Playbook の例では ``var1`` 変数を定義していますが、未定義の ``wrong_var`` 変数を誤ってタスクで使用します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:148 -msgid "If you run this playbook, Ansible invokes the debugger when the task fails. From the debug prompt, you can change the module arguments or the variables and run the task again." -msgstr "この Playbook を実行すると、Ansible はタスクの失敗時にデバッガーを呼び出します。デバッグプロンプトから、モジュール引数または変数を変更して、タスクを再度実行できます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:183 -msgid "Changing the task arguments in the debugger to use ``var1`` instead of ``wrong_var`` makes the task run successfully." -msgstr "デバッガでタスクの引数 ``wrong_var`` の代わりに ``var1`` を使用するように変更すると、タスクが正常に実行されます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:188 -msgid "Available debug commands" -msgstr "利用可能なデバッグコマンド" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:190 -msgid "You can use these seven commands at the debug prompt:" -msgstr "これらの 7 つのコマンドは、デバッグプロンプトで使用できます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:196 -msgid "Command" -msgstr "コマンド" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:196 -msgid "Shortcut" -msgstr "ショートカット" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:196 -msgid "Action" -msgstr "アクション" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:198 -msgid "print" -msgstr "print" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:198 -msgid "p" -msgstr "p" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:198 -msgid "Print information about the task" -msgstr "タスクに関する情報を出力する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:200 -msgid "task.args[*key*] = *value*" -msgstr "task.args[*key*] = *value*" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:200 -#: ../../rst/playbook_guide/playbooks_debugger.rst:202 -msgid "no shortcut" -msgstr "ショートカットなし" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:200 -msgid "Update module arguments" -msgstr "モジュール引数を更新する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:202 -msgid "task_vars[*key*] = *value*" -msgstr "task_vars[*key*] = *value*" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:202 -msgid "Update task variables (you must ``update_task`` next)" -msgstr "タスク変数を更新する (次回 ``update_task`` する必要があります)" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:204 -msgid "update_task" -msgstr "update_task" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:204 -msgid "u" -msgstr "u" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:204 -msgid "Recreate a task with updated task variables" -msgstr "更新されたタスク変数でタスクを再作成する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:206 -msgid "redo" -msgstr "redo" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:206 -msgid "r" -msgstr "r" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:206 -msgid "Run the task again" -msgstr "タスクを再度実行する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:208 -msgid "continue" -msgstr "continue" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:208 -msgid "c" -msgstr "c" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:208 -msgid "Continue executing, starting with the next task" -msgstr "実行を継続する (次のタスクから開始)" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:210 -msgid "quit" -msgstr "quit" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:210 -msgid "q" -msgstr "q" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:210 -msgid "Quit the debugger" -msgstr "デバッガーを終了する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:214 -msgid "For more details, see the individual descriptions and examples below." -msgstr "詳細は、以下の個別の説明および例を参照してください。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:219 -msgid "Print command" -msgstr "コマンドを出力する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:221 -msgid "``print *task/task.args/task_vars/host/result*`` prints information about the task." -msgstr "``print *task/task.args/task_vars/host/result*`` は、タスクに関する情報を出力します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:248 -msgid "Update args command" -msgstr "args コマンドを更新する" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:250 -msgid "``task.args[*key*] = *value*`` updates a module argument. This sample playbook has an invalid package name." -msgstr "``task.args[*key*] = *value*`` モジュール引数を更新します。このサンプル Playbook には無効なパッケージ名があります。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:263 -msgid "When you run the playbook, the invalid package name triggers an error, and Ansible invokes the debugger. You can fix the package name by viewing, then updating the module argument." -msgstr "Playbook を実行すると、パッケージ名が無効であるためにエラーが発生し、Ansible がデバッガーを起動します。パッケージ名を修正するには、モジュールの引数を表示してから更新します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:274 -msgid "After you update the module argument, use ``redo`` to run the task again with the new args." -msgstr "モジュール引数を更新したら、``redo`` を使用して、新しい引数でタスクを再度実行します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:279 -msgid "Update vars command" -msgstr "vars コマンドの更新" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:281 -msgid "``task_vars[*key*] = *value*`` updates the ``task_vars``. You could fix the playbook above by viewing, then updating the task variables instead of the module args." -msgstr "``task_vars[*key*] = *value*`` は、``task_vars`` を更新します。モジュール引数ではなくタスク変数を表示してから更新して、上記の Playbook を修正できます。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:293 -msgid "After you update the task variables, you must use ``update_task`` to load the new variables before using ``redo`` to run the task again." -msgstr "タスク変数を更新したら、``redo`` を使用してタスクを再実行する前に、``update_task`` を使用して新しい変数を読み込む必要があります。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:296 -msgid "In 2.5 this was updated from ``vars`` to ``task_vars`` to avoid conflicts with the ``vars()`` python function." -msgstr "これは、python 関数 ``vars()`` と競合しないように、2.5 で ``vars`` から ``task_vars`` に更新されました。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:301 -msgid "Update task command" -msgstr "task コマンドの更新" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:305 -msgid "``u`` or ``update_task`` recreates the task from the original task data structure and templates with updated task variables. See the entry :ref:`update_vars_command` for an example of use." -msgstr "``u`` または ``update_task`` は、更新されたタスク変数を持つ元のタスクデータ構造とテンプレートからタスクを再作成します。使用例は、エントリー:ref:`update_vars_command` を参照してください。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:310 -msgid "Redo command" -msgstr "コマンドのやり直し" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:312 -msgid "``r`` or ``redo`` runs the task again." -msgstr "``r`` または ``redo`` はタスクを再実行します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:317 -msgid "Continue command" -msgstr "コマンドの続行" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:319 -msgid "``c`` or ``continue`` continues executing, starting with the next task." -msgstr "``c`` または ``continue`` は、次のタスクから開始して実行を継続します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:324 -msgid "Quit command" -msgstr "Quit コマンド" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:326 -msgid "``q`` or ``quit`` quits the debugger. The playbook execution is aborted." -msgstr "``q`` または ``quit`` はデバッガーを終了します。Playbook の実行は中止します。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:329 -msgid "How the debugger interacts with the free strategy" -msgstr "デバッガーがフリーストラテジーとどのように相互作用するか" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:331 -msgid "With the default ``linear`` strategy enabled, Ansible halts execution while the debugger is active, and runs the debugged task immediately after you enter the ``redo`` command. With the ``free`` strategy enabled, however, Ansible does not wait for all hosts, and may queue later tasks on one host before a task fails on another host. With the ``free`` strategy, Ansible does not queue or execute any tasks while the debugger is active. However, all queued tasks remain in the queue and run as soon as you exit the debugger. If you use ``redo`` to reschedule a task from the debugger, other queued tasks may execute before your rescheduled task. For more information about strategies, see :ref:`playbooks_strategies`." -msgstr "デフォルトの ``linear`` ストラテジーを有効にすると、Ansible はデバッガ―がアクティブな間は実行を停止し、``redo`` コマンドを入力した直後にデバッグされたタスクを実行します。しかし、``free`` ストラテジーを有効にすると、Ansible はすべてのホストを待たずに、別のホストでタスクが失敗する前に、あるホストで後のタスクをキューに入れることがあります。``free`` ストラテジーを使用すると、デバッガーがアクティブな間、Ansible は、タスクの照会や実行を行いません。ただし、キューに入れられたタスクはすべてキューに残り、デバッガーを終了するとすぐに実行されます。``redo`` を使用してデバッガーからタスクを再スケジュールすると、再スケジュールされたタスクの前にキューに入れられた他のタスクが実行する場合があります。ストラテジーの詳細については「:ref:`playbooks_strategies`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:335 -msgid ":ref:`playbooks_start_and_step`" -msgstr ":ref:`playbooks_start_and_step`" - -#: ../../rst/playbook_guide/playbooks_debugger.rst:336 -msgid "Running playbooks while debugging or testing" -msgstr "デバッグ時またはテスト時の Playbook の実行" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:4 -msgid "Controlling where tasks run: delegation and local actions" -msgstr "タスクの実行場所の制御: 委譲およびローカルアクション" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:6 -msgid "By default Ansible gathers facts and executes all tasks on the machines that match the ``hosts`` line of your playbook. This page shows you how to delegate tasks to a different machine or group, delegate facts to specific machines or groups, or run an entire playbook locally. Using these approaches, you can manage inter-related environments precisely and efficiently. For example, when updating your webservers, you might need to remove them from a load-balanced pool temporarily. You cannot perform this task on the webservers themselves. By delegating the task to localhost, you keep all the tasks within the same play." -msgstr "デフォルトでは、Ansible はファクトを収集し、Playbook の ``hosts`` 行に一致するマシン上ですべてのタスクを実行します。このページでは、タスクを別のマシンやグループに委譲したり、ファクトを特定のマシンやグループに委譲したり、Playbook 全体をローカルで実行する方法を紹介します。これらの方法を用いることで、相互に関連する環境を正確かつ効率的に管理することができます。たとえば、Web サーバーを更新する際に、負荷分散したプールから一時的に Web サーバーを削除しないといけない場合があります。このタスクは、Web サーバー自身では実行できません。このタスクを localhost に委譲することで、すべてのタスクを同じプレイに収めることができます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:12 -msgid "Tasks that cannot be delegated" -msgstr "委譲できないタスク" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:14 -msgid "Some tasks always execute on the controller. These tasks, including ``include``, ``add_host``, and ``debug``, cannot be delegated." -msgstr "一部のタスクは常にコントローラーで実行します。これらのタスクには、``include``、``add_host``、および ``debug`` を含むタスクを委譲できません。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:19 -msgid "Delegating tasks" -msgstr "タスクの委譲" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:21 -msgid "If you want to perform a task on one host with reference to other hosts, use the ``delegate_to`` keyword on a task. This is ideal for managing nodes in a load balanced pool or for controlling outage windows. You can use delegation with the :ref:`serial ` keyword to control the number of hosts executing at one time:" -msgstr "あるホストで他のホストを参照しながらタスクを実行したい場合は、タスクに ``delegate_to`` キーワードを使用します。これは、負荷分散されたプールのノードを管理したり、障害発生時のウィンドウを制御するのに最適です。:ref:`serial ` キーワードで委譲を使用すると、一度に実行するホストの数を制御することができます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:43 -msgid "The first and third tasks in this play run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: ``local_action``. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1:" -msgstr "ここでは、1 番目と 3 番目のタスクを 127.0.0.1 で実行していますが、これは Ansible を実行しているマシンです。また、タスクごとに使用できる簡略化された構文があります (``local_action``)。以下は、上記と同じ Playbook ですが、127.0.0.1 に委譲するための短縮構文を使用します。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:59 -msgid "You can use a local action to call 'rsync' to recursively copy files to the managed servers:" -msgstr "ローカルアクションを使用して「rsync」を呼び出し、管理対象のサーバーにファイルを再帰的にコピーすることができます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:70 -msgid "Note that you must have passphrase-less SSH keys or an ssh-agent configured for this to work, otherwise rsync asks for a passphrase." -msgstr "これが機能するためには、パスフレーズなしの SSH 鍵または ssh-agent が設定されていなければならないことに注意してください。そうでなければ、rsync はパスフレーズを要求します。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:72 -msgid "To specify more arguments, use the following syntax:" -msgstr "引数をさらに指定する必要がある場合は、以下の構文を使用できます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:89 -msgid "The `ansible_host` variable and other connection variables, if present, reflects information about the host a task is delegated to, not the inventory_hostname." -msgstr "`ansible_host` 変数と他の接続変数がある場合は、inventory_hostname ではなく、タスクが委譲されるホストに関する情報を反映します。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:93 -msgid "Although you can ``delegate_to`` a host that does not exist in inventory (by adding IP address, DNS name or whatever requirement the connection plugin has), doing so does not add the host to your inventory and might cause issues. Hosts delegated to in this way do not inherit variables from the \"all\" group', so variables like connection user and key are missing. If you must ``delegate_to`` a non-inventory host, use the :ref:`add host module `." -msgstr "（IP アドレス、DNS 名、または接続プラグインの要件を追加することにより）インベントリーに存在しないホストを ``delegate_to`` にすることができますが、これを行うと、インベントリーにホストを追加せず、問題が発生する可能性があります。このように委譲されたホストは「すべて」グループから変数を継承しないため、接続ユーザーとキーなどの変数がありません。インベントリーホスト以外をのホストを ``delegate_to`` にする必要がある場合は、:ref:`add host module ` を使用します。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:99 -msgid "Delegation and parallel execution" -msgstr "委譲と並列実行" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:100 -msgid "By default Ansible tasks are executed in parallel. Delegating a task does not change this and does not handle concurrency issues (multiple forks writing to the same file). Most commonly, users are affected by this when updating a single file on a single delegated to host for all hosts (using the ``copy``, ``template``, or ``lineinfile`` modules, for example). They will still operate in parallel forks (default 5) and overwrite each other." -msgstr "デフォルトでは、Ansible タスクは並行して実行されます。タスクを委譲してもこれは変更されず、同時実行の問題（複数のフォークが同じファイルに書き込む）は処理されません。最も一般的には、すべてのホストのホストに委任された単一のファイルを更新するときに、ユーザーはこれの影響を受けます（``copy``、``template``、 または``lineinfile`` モジュールなど）。それらは引き続き並列フォーク（デフォルトは 5）で動作し、相互に上書きします。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:103 -msgid "This can be handled in several ways:" -msgstr "これは複数の方法で処理できます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:112 -msgid "By using an intermediate play with `serial: 1` or using `throttle: 1` at task level, for more detail see :ref:`playbooks_strategies`" -msgstr "`serial: 1` で中間プレイを使用するか、タスクレベルで `throttle: 1` を使用します。詳細は、:ref:`playbooks_strategies`を参照してください。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:117 -msgid "Delegating facts" -msgstr "ファクトの委譲" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:119 -msgid "Delegating Ansible tasks is like delegating tasks in the real world - your groceries belong to you, even if someone else delivers them to your home. Similarly, any facts gathered by a delegated task are assigned by default to the `inventory_hostname` (the current host), not to the host which produced the facts (the delegated to host). To assign gathered facts to the delegated host instead of the current host, set ``delegate_facts`` to ``true``:" -msgstr "Ansible のタスクを委譲することは、現実世界でタスクを委譲することと同じです。たとえ他の誰かがあなたの家に食料品を届けたとしても、あなたの食料品はあなたのものです。同様に、委譲されたタスクによって収集されたファクトは、デフォルトでは、ファクトを生成したホスト (委譲されたホスト) ではなく、`inventory_hostname` (現在のホスト) に割り当てられます。集めたファクトを現在のホストではなく委譲されたホストに割り当てるには、``delegate_facts`` を ``true`` に設定します。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:133 -msgid "This task gathers facts for the machines in the dbservers group and assigns the facts to those machines, even though the play targets the app_servers group. This way you can lookup `hostvars['dbhost1']['ansible_default_ipv4']['address']` even though dbservers were not part of the play, or left out by using `--limit`." -msgstr "このタスクは、プレイが app_servers グループを対象としているにもかかわらず、dbservers グループのマシンのファクトを収集し、それらのマシンにファクトを割り当てます。このようにして、たとえ dbservers がプレイの一部でなくても、あるいは `--limit` を使用して除外されていても、`hostvars['dbhost1']['ansible_default_ipv4']['address']` を調べることができます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:138 -msgid "Local playbooks" -msgstr "ローカルの Playbook" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:140 -msgid "It may be useful to use a playbook locally on a remote host, rather than by connecting over SSH. This can be useful for assuring the configuration of a system by putting a playbook in a crontab. This may also be used to run a playbook inside an OS installer, such as an Anaconda kickstart." -msgstr "SSH で接続するのではなく、リモートホスト上でローカルに Playbook を使用することが便利な場合があります。これは、crontab に Playbook を置くことで、システムの構成を保証するのに役立ちます。また、Anaconda のキックスタートなど、OS インストーラー内で Playbook を実行する場合にも使用できます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:143 -msgid "To run an entire playbook locally, just set the ``hosts:`` line to ``hosts: 127.0.0.1`` and then run the playbook like so:" -msgstr "Playbook 全体をローカルで実行するには、``hosts:`` 行を ``hosts: 127.0.0.1`` に設定し、次のように Playbook を実行します。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:149 -msgid "Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook use the default remote connection type:" -msgstr "また、Playbook 内の他のプレイがデフォルトのリモート接続タイプを使用していても、1 つの Playbook のプレイでローカル接続を使用することもできます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:159 -msgid "If you set the connection to local and there is no ansible_python_interpreter set, modules will run under /usr/bin/python and not under {{ ansible_playbook_python }}. Be sure to set ansible_python_interpreter: \"{{ ansible_playbook_python }}\" in host_vars/localhost.yml, for example. You can avoid this issue by using ``local_action`` or ``delegate_to: localhost`` instead." -msgstr "接続先をローカルに設定し、ansible_python_interpreter が設定されていないと、モジュールは、{{ ansible_playbook_python }} ではなく /usr/bin/python で実行します。ansible_python_interpreter を必ず設定してください (host_vars/localhost.yml の「{{ ansible_playbook_python }}」など)。代わりに ``local_action`` または ``delegate_to: localhost`` を使用することで、この問題を回避できます。" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:168 -msgid "More ways to control how and where Ansible executes" -msgstr "Ansible の実行方法および場所を制御する方法" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:169 -msgid "`Ansible Examples on GitHub `_" -msgstr "`Ansible Examples on GitHub `_" - -#: ../../rst/playbook_guide/playbooks_delegation.rst:170 -msgid "Many examples of full-stack deployments" -msgstr "フルスタックデプロイメントの例が多数あります。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:4 -msgid "Setting the remote environment" -msgstr "リモート環境の設定" - -#: ../../rst/playbook_guide/playbooks_environment.rst:8 -msgid "You can use the ``environment`` keyword at the play, block, or task level to set an environment variable for an action on a remote host. With this keyword, you can enable using a proxy for a task that does http requests, set the required environment variables for language-specific version managers, and more." -msgstr "プレイ、ブロック、またはタスクのレベルで ``environment`` キーワードを使用して、リモートホスト上のアクションに環境変数を設定することができます。このキーワードを使用すると、http リクエストを行うタスクでプロキシーの使用を有効にしたり、言語固有のバージョンマネージャーに必要な環境変数を設定したりすることができます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:10 -msgid "When you set a value with ``environment:`` at the play or block level, it is available only to tasks within the play or block that are executed by the same user. The ``environment:`` keyword does not affect Ansible itself, Ansible configuration settings, the environment for other users, or the execution of other plugins like lookups and filters. Variables set with ``environment:`` do not automatically become Ansible facts, even when you set them at the play level. You must include an explicit ``gather_facts`` task in your playbook and set the ``environment`` keyword on that task to turn these values into Ansible facts." -msgstr "プレイまたはブロックレベルで ``environment:`` を使用して値を設定すると、同じユーザーによって実行されるプレイまたはブロック内のタスクでのみ使用できます。``environment:`` キーワードは、Ansible 自体、Ansible の構成設定、他のユーザーの環境、ルックアップやフィルターなどの他のプラグインの実行には影響しません。``environment:`` で設定した変数は、プレイレベルで設定しても、自動的に Ansible のファクトにはなりません。これらの値を Ansible のファクトにするには、Playbook に明示的な ``gather_facts`` タスクを含め、そのタスクに ``environment`` キーワードを設定する必要があります。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:16 -msgid "Setting the remote environment in a task" -msgstr "タスクへのリモート環境の設定" - -#: ../../rst/playbook_guide/playbooks_environment.rst:18 -msgid "You can set the environment directly at the task level." -msgstr "タスクレベルで環境を直接指定することもできます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:34 -msgid "You can re-use environment settings by defining them as variables in your play and accessing them in a task as you would access any stored Ansible variable." -msgstr "環境変数をプレイの変数として定義し、保存した Ansible 変数にアクセスするときにタスクからアクセスできることで、環境変数を再利用できます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:54 -msgid "You can store environment settings for re-use in multiple playbooks by defining them in a group_vars file." -msgstr "複数の Playbook に再使用する環境設定は、group_vars ファイルに定義することで保存できます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:67 -msgid "You can set the remote environment at the play level." -msgstr "プレイレベルでリモート環境を設定できます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:80 -msgid "These examples show proxy settings, but you can provide any number of settings this way." -msgstr "これらの例ではプロキシー設定を示していますが、この設定をいくつでも提供できます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:83 -msgid "Working with language-specific version managers" -msgstr "言語固有のバージョンマネージャーの使用" - -#: ../../rst/playbook_guide/playbooks_environment.rst:85 -msgid "Some language-specific version managers (such as rbenv and nvm) require you to set environment variables while these tools are in use. When using these tools manually, you usually source some environment variables from a script or from lines added to your shell configuration file. In Ansible, you can do this with the environment keyword at the play level." -msgstr "言語固有のバージョンマネージャー (rbenv や nvmなど) の中には、これらのツールを使用する際に環境変数を設定する必要があります。これらのツールを手動で使用する場合、通常はスクリプトやシェル構成ファイルに追加した行から環境変数を設定します。Ansible では、プレイレベルで環境キーワードを使用してこれを行うことができます。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:124 -msgid "The example above uses ``ansible_env`` as part of the PATH. Basing variables on ``ansible_env`` is risky. Ansible populates ``ansible_env`` values by gathering facts, so the value of the variables depends on the remote_user or become_user Ansible used when gathering those facts. If you change remote_user/become_user the values in ``ansible_env`` may not be the ones you expect." -msgstr "上の例では、``ansible_env`` を PATH の一部として使用しています。変数を ``ansible_env`` に基づかせるのはリスクがあります。Ansible はファクトを収集して ``ansible_env`` の値を生成するため、変数の値はファクトの収集時に Ansible が使用した remote_user や become_user に依存します。remote_user/become_user を変更した場合、``ansible_env`` の値は期待したものとは異なる可能性があります。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:127 -msgid "Environment variables are normally passed in clear text (shell plugin dependent) so they are not a recommended way of passing secrets to the module being executed." -msgstr "環境変数は、通常、(シェルプラグインに依存する) クリアテキストに渡されます。したがって、実行するモジュールにシークレットを渡す方法は推奨されません。" - -#: ../../rst/playbook_guide/playbooks_environment.rst:129 -msgid "You can also specify the environment at the task level." -msgstr "タスクレベルで環境を指定することもできます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:5 -msgid "Error handling in playbooks" -msgstr "Playbook でのエラー処理" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:7 -msgid "When Ansible receives a non-zero return code from a command or a failure from a module, by default it stops executing on that host and continues on other hosts. However, in some circumstances you may want different behavior. Sometimes a non-zero return code indicates success. Sometimes you want a failure on one host to stop execution on all hosts. Ansible provides tools and settings to handle these situations and help you get the behavior, output, and reporting you want." -msgstr "Ansible は、コマンドからゼロ以外の戻りコードを受け取った場合や、モジュールから失敗を受け取った場合、デフォルトでは、そのホストでの実行を停止し、他のホストで継続します。しかし、状況によっては異なる動作をさせたい場合があります。ゼロ以外の戻りコードが成功を示す場合もあります。あるホストで失敗したら、すべてのホストで実行を停止させたい場合もあります。Ansible には、このような状況に対応するためのツールや設定が用意されており、必要な動作、出力、レポートを得ることができます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:15 -msgid "Ignoring failed commands" -msgstr "失敗したコマンドの無視" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:17 -msgid "By default Ansible stops executing tasks on a host when a task fails on that host. You can use ``ignore_errors`` to continue on in spite of the failure." -msgstr "デフォルトでは、Ansible は、ホストでタスクが失敗すると、ホストでタスクの実行を停止します。``ignore_errors`` を使用すると、障害が発生しても続行されます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:25 -msgid "The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors." -msgstr "``ignore_errors`` ディレクティブは、タスクが実行可能で、「failed」という値を返す場合にのみ機能します。未定義の変数のエラー、接続の失敗、実行時の問題 (パッケージの欠落など)、構文エラーなどを Ansible に無視させるものではありません。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:30 -msgid "Ignoring unreachable host errors" -msgstr "到達不能なホストエラーを無視" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:34 -msgid "You can ignore a task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level:" -msgstr "``ignore_unreachable`` キーワードで、ホストインスタンスが「UNREACHABLE」であることによるタスクの失敗を無視することができます。Ansible はタスクのエラーを無視しますが、到達不可能なホストに対して今後のタスクを実行し続けます。たとえば、タスクレベルでは以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:45 -msgid "And at the playbook level:" -msgstr "また、Playbook レベルでは以下を行います。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:62 -msgid "Resetting unreachable hosts" -msgstr "到達できないホストのリセット" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:64 -msgid "If Ansible cannot connect to a host, it marks that host as 'UNREACHABLE' and removes it from the list of active hosts for the run. You can use `meta: clear_host_errors` to reactivate all hosts, so subsequent tasks can try to reach them again." -msgstr "Ansible はホストに接続できない場合、そのホストを「UNREACHABLE」とマークし、実行時にアクティブなホストのリストから削除します。`meta: clear_host_errors` を使用してすべてのホストを再有効化することで、後続のタスクが再びホストに到達しようとすることができます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:70 -msgid "Handlers and failure" -msgstr "ハンドラーおよび失敗" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:72 -msgid "Ansible runs :ref:`handlers ` at the end of each play. If a task notifies a handler but another task fails later in the play, by default the handler does *not* run on that host, which may leave the host in an unexpected state. For example, a task could update a configuration file and notify a handler to restart some service. If a task later in the same play fails, the configuration file might be changed but the service will not be restarted." -msgstr "Ansible は、各プレイの最後に :ref:`handlers ` を実行します。タスクがハンドラーに通知しても、プレイの後半で別のタスクが失敗すると、デフォルトではハンドラーはそのホスト上で **実行されず**、ホストが予期せぬ状態になる可能性があります。たとえば、タスクが設定ファイルを更新し、ハンドラーにサービスの再起動を通知したとします。同じプレイの後半でタスクが失敗した場合、設定ファイルは変更するかもしれませんが、サービスは再起動しません。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:79 -msgid "You can change this behavior with the ``--force-handlers`` command-line option, by including ``force_handlers: True`` in a play, or by adding ``force_handlers = True`` to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on all hosts, even hosts with failed tasks. (Note that certain errors could still prevent the handler from running, such as a host becoming unreachable.)" -msgstr "この動作は、``force_handlers: True`` をプレイに含めるか、``force_handlers = True`` を ansible.cfg に追加して、``--force-handlers`` コマンドラインオプションで変更できます。ハンドラーが強制的に実行すると、Ansible は通知されたすべてのハンドラーを、タスクが失敗したホストも含めてすべてのホストで実行します (ホストが到達不能になるなど、特定のエラーによってハンドラーの実行が妨げられる可能性があることに注意してください)。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:88 -msgid "Defining failure" -msgstr "障害の定義" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:90 -msgid "Ansible lets you define what \"failure\" means in each task using the ``failed_when`` conditional. As with all conditionals in Ansible, lists of multiple ``failed_when`` conditions are joined with an implicit ``and``, meaning the task only fails when *all* conditions are met. If you want to trigger a failure when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator." -msgstr "Ansible では、``failed_when`` 条件分岐を使用して、各タスクで「失敗」の意味を定義することができます。Ansible のすべての条件分岐と同様に、複数の ``failed_when`` 条件のリストは暗黙の ``and`` で結合されており、これは *すべての* 条件が満たされたときにのみタスクが失敗することを意味します。いずれかの条件が満たされたときに失敗をトリガーしたい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:92 -msgid "You may check for failure by searching for a word or phrase in the output of a command" -msgstr "コマンドの出力で単語またはフレーズを検索して、障害の有無を確認できます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:101 -msgid "or based on the return code" -msgstr "または、戻りコードに基いて確認できます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:110 -msgid "You can also combine multiple conditions for failure. This task will fail if both conditions are true:" -msgstr "複数の条件を組み合わせて失敗させることもできます。このタスクは、両方の条件が真であれば失敗します。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:121 -msgid "If you want the task to fail when only one condition is satisfied, change the ``failed_when`` definition to" -msgstr "条件が満たされたときにのみタスクが失敗する場合は、``failed_when`` 定義を以下のように変更します。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:127 -msgid "If you have too many conditions to fit neatly into one line, you can split it into a multi-line YAML value with ``>``." -msgstr "条件が多すぎて 1 行にうまく収まらない場合は、``>`` を使用して、これを複数行の YAML 値に分割できます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:142 -msgid "Defining \"changed\"" -msgstr "「変更済み」の定義" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:144 -msgid "Ansible lets you define when a particular task has \"changed\" a remote node using the ``changed_when`` conditional. This lets you determine, based on return codes or output, whether a change should be reported in Ansible statistics and whether a handler should be triggered or not. As with all conditionals in Ansible, lists of multiple ``changed_when`` conditions are joined with an implicit ``and``, meaning the task only reports a change when *all* conditions are met. If you want to report a change when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. For example:" -msgstr "Ansible では、``changed_when`` 条件式を使用して、特定のタスクがリモートノードを「変更」したときを定義することができます。これにより、戻りコードや出力に基づいて、変更を Ansible の統計で報告するかどうか、ハンドラーをトリガーするかどうかを決定することができます。Ansible のすべての条件式と同様に、複数の ``changed_when`` 条件のリストは暗黙の ``and`` で結合されており、タスクは *すべての* 条件が満たされたときにのみ変更を報告することを意味します。いずれかの条件が満たされたときに変更を報告したい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:159 -msgid "You can also combine multiple conditions to override \"changed\" result." -msgstr "複数の条件を組み合わせて「変更」の結果を上書きすることもできます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:173 -msgid "Just like ``when`` these two conditionals do not require templating delimiters (``{{ }}``) as they are implied." -msgstr "``when`` と同様に、これら 2 つの条件には、暗黙の了解として、テンプレート化の区切り文字(``{{ }}``)は必要ありません。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:175 -msgid "See :ref:`controlling_what_defines_failure` for more conditional syntax examples." -msgstr "その他の条件付き構文例については、「:ref:`controlling_what_defines_failure`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:178 -msgid "Ensuring success for command and shell" -msgstr "コマンドとシェルの成功の確認" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:180 -msgid "The :ref:`command ` and :ref:`shell ` modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this:" -msgstr ":ref:`command ` モジュールおよび :ref:`shell ` モジュールは戻りコードを処理するため、正常な終了コードがゼロではないコマンドがある場合は、以下を行うことができます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:190 -msgid "Aborting a play on all hosts" -msgstr "すべてのホストでプレイを中止" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:192 -msgid "Sometimes you want a failure on a single host, or failures on a certain percentage of hosts, to abort the entire play on all hosts. You can stop play execution after the first failure happens with ``any_errors_fatal``. For finer-grained control, you can use ``max_fail_percentage`` to abort the run after a given percentage of hosts has failed." -msgstr "時には、1 つのホストでの失敗や、ある割合のホストでの失敗により、すべてのホストでのプレイ全体を中止させたいことがあります。``any_errors_fatal`` を使用すると、最初の失敗が発生した後にプレイの実行を停止することができます。より細かく制御するには、``max_fail_percentage`` を使用して、特定の割合のホストで失敗した後に実行を中止することができます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:195 -msgid "Aborting on the first error: any_errors_fatal" -msgstr "最初のエラーで強制終了: any_errors_fatal" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:197 -msgid "If you set ``any_errors_fatal`` and a task returns an error, Ansible finishes the fatal task on all hosts in the current batch, then stops executing the play on all hosts. Subsequent tasks and plays are not executed. You can recover from fatal errors by adding a :ref:`rescue section ` to the block. You can set ``any_errors_fatal`` at the play or block level." -msgstr "``any_errors_fatal`` を設定し、タスクがエラーを返した場合、Ansible は現在のバッチ内のすべてのホストで致命的なタスクを終了し、すべてのホストでプレイの実行を停止します。後続のタスクやプレイは実行されません。致命的なエラーから回復するには、ブロックに :ref:`rescue section ` を追加します。``any_errors_fatal`` は、プレイまたはブロックレベルで設定できます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:212 -#, python-format -msgid "You can use this feature when all tasks must be 100% successful to continue playbook execution. For example, if you run a service on machines in multiple data centers with load balancers to pass traffic from users to the service, you want all load balancers to be disabled before you stop the service for maintenance. To ensure that any failure in the task that disables the load balancers will stop all other tasks:" -msgstr "この機能は、Playbook の実行を継続するために、すべてのタスクが 100％ 成功する必要がある場合に使用できます。たとえば、複数のデータセンターにあるマシンでサービスを実行し、ユーザーからのトラフィックをサービスに渡すためにロードバランサーを使用している場合は、メンテナンスのためにサービスを停止する前に、すべてのロードバランサーを無効にします。ロードバランサーを無効にするタスクに障害が発生しても、他のすべてのタスクを停止させるには、次のようにします。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:239 -msgid "In this example Ansible starts the software upgrade on the front ends only if all of the load balancers are successfully disabled." -msgstr "この例では、すべてのロードバランサーが正常に無効になっている場合にのみ、Ansible が、フロントエンドでソフトウェアのアップグレードを開始します。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:244 -msgid "Setting a maximum failure percentage" -msgstr "最大失敗率の設定" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:246 -msgid "By default, Ansible continues to execute tasks as long as there are hosts that have not yet failed. In some situations, such as when executing a rolling update, you may want to abort the play when a certain threshold of failures has been reached. To achieve this, you can set a maximum failure percentage on a play:" -msgstr "デフォルトでは、Ansible はまだ失敗していないホストがある限り、タスクを実行し続けます。ローリングアップデートを実行する場合など、ある一定の失敗率に達したときにプレイを中断したい場合があります。これを可能にするには、プレイの最大失敗率を設定することができます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:255 -msgid "The ``max_fail_percentage`` setting applies to each batch when you use it with :ref:`serial `. In the example above, if more than 3 of the 10 servers in the first (or any) batch of servers failed, the rest of the play would be aborted." -msgstr "``max_fail_percentage`` の設定は、:ref:`serial ` と一緒に使用すると、各バッチに適用されます。上の例では、最初の (あるいは任意の) バッチに含まれる 10 台のサーバーのうち 3 台以上が故障した場合、残りのプレイは中止されます。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:259 -msgid "The percentage set must be exceeded, not equaled. For example, if serial were set to 4 and you wanted the task to abort the play when 2 of the systems failed, set the max_fail_percentage at 49 rather than 50." -msgstr "設定されたパーセンテージは、同等ではなく、超えなければなりません。たとえば、serialが 4 に設定されていて、2 つのシステムが故障したときにプレイを中止するタスクにしたい場合は、max_fail_percentage を 50 ではなく 49 に設定します。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:262 -msgid "Controlling errors in blocks" -msgstr "ブロックのエラーを制御" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:264 -msgid "You can also use blocks to define responses to task errors. This approach is similar to exception handling in many programming languages. See :ref:`block_error_handling` for details and examples." -msgstr "ブロックを使用してタスクエラーへの応答を定義することもできます。この方法は、多くのプログラミング言語での例外処理に似ています。詳細と例は、「:ref:`block_error_handling`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:272 -#: ../../rst/playbook_guide/playbooks_filters.rst:2190 -#: ../../rst/playbook_guide/playbooks_lookups.rst:30 -#: ../../rst/playbook_guide/playbooks_loops.rst:492 -#: ../../rst/playbook_guide/playbooks_prompts.rst:117 -#: ../../rst/playbook_guide/playbooks_reuse.rst:215 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:602 -#: ../../rst/playbook_guide/playbooks_tests.rst:529 -#: ../../rst/playbook_guide/playbooks_variables.rst:519 -msgid ":ref:`playbooks_conditionals`" -msgstr ":ref:`playbooks_conditionals`" - -#: ../../rst/playbook_guide/playbooks_error_handling.rst:273 -#: ../../rst/playbook_guide/playbooks_filters.rst:2191 -#: ../../rst/playbook_guide/playbooks_lookups.rst:31 -#: ../../rst/playbook_guide/playbooks_loops.rst:493 -#: ../../rst/playbook_guide/playbooks_prompts.rst:118 -#: ../../rst/playbook_guide/playbooks_tests.rst:530 -#: ../../rst/playbook_guide/playbooks_variables.rst:520 -msgid "Conditional statements in playbooks" -msgstr "Playbook の条件分岐文" - -#: ../../rst/playbook_guide/playbooks_execution.rst:4 -msgid "Executing playbooks" -msgstr "Playbook の実行" - -#: ../../rst/playbook_guide/playbooks_execution.rst:6 -msgid "Ready to run your Ansible playbook?" -msgstr "Ansible Playbook を実行する準備はできましたか?" - -#: ../../rst/playbook_guide/playbooks_execution.rst:8 -msgid "Running complex playbooks requires some trial and error so learn about some of the abilities that Ansible gives you to ensure successful execution. You can validate your tasks with \"dry run\" playbooks, use the start-at-task and step mode options to efficiently troubleshoot playbooks. You can also use Ansible debugger to correct tasks during execution. Ansible also offers flexibility with asynchronous playbook execution and tags that let you run specific parts of your playbook." -msgstr "複雑な Playbook を実行するには試行錯誤が必要なので、実行を成功させるために Ansible が提供するいくつかの機能を確認してみてください。\"dry run\" Playbook でタスクを検証し、start-at-task および step モードオプションを使用して Playbook を効率的にトラブルシューティングできます。Ansible デバッガーを使用して、実行中にタスクを修正することもできます。Ansible は、Playbook の特定の部分を実行できる非同期 Playbook 実行やタグによる柔軟性も提供します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:5 -msgid "Using filters to manipulate data" -msgstr "フィルターを使用したデータの操作" - -#: ../../rst/playbook_guide/playbooks_filters.rst:7 -msgid "Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters ` in the official Jinja2 template documentation. You can also use :ref:`Python methods ` to transform data. You can :ref:`create custom Ansible filters as plugins `, though we generally welcome new filters into the ansible-core repo so everyone can use them." -msgstr "フィルターを使用すると、JSON データを YAML データに変換したり、URL を分割してホスト名を抽出したり、文字列の SHA1 ハッシュを取得したり、整数を加算または乗算したりなど、さまざまなことができます。ここで紹介している Ansible 固有のフィルターを使用してデータを操作することもできますし、Jinja2 に同梱されている標準的なフィルターを使用することもできます。Jinja2 の公式テンプレートドキュメントの :ref:`組み込みフィルター ` のリストを参照してださい。また、:ref:`Python メソッド ` を使用してデータを変換することもできます。:ref:`カスタム Ansible フィルターをプラグインとして作成 ` することもできますが、通常は、誰もが使用できるように新しいフィルターを ansible-core リポジトリーに追加することが歓迎されています。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:9 -msgid "Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally." -msgstr "テンプレート化はターゲットホスト上 **ではなく**、Ansible コントローラー上で行われるため、フィルターはコントローラ上で実行し、データはローカルに変換されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:15 -msgid "Handling undefined variables" -msgstr "未定義変数の処理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:17 -msgid "Filters can help you manage missing or undefined variables by providing defaults or making some variables optional. If you configure Ansible to ignore most undefined variables, you can mark some variables as requiring values with the ``mandatory`` filter." -msgstr "フィルターは、デフォルトを指定したり、一部の変数を任意にしたりすることで、欠落している変数や未定義の変数を管理するのに役立ちます。ほとんどの未定義の変数を無視するように Ansibl eを設定した場合は、``mandatory`` フィルターを使用して、いくつかの変数を必要な値としてマークすることができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:22 -msgid "Providing default values" -msgstr "デフォルト値の指定" - -#: ../../rst/playbook_guide/playbooks_filters.rst:24 -msgid "You can provide default values for variables directly in your templates using the Jinja2 'default' filter. This is often a better approach than failing if a variable is not defined:" -msgstr "Jinja2 の「default」フィルターを使用すれば、テンプレートの中で直接、変数のデフォルト値を指定することができます。変数が定義されていない場合に失敗するよりも優れたアプローチであることがよくあります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:30 -msgid "In the above example, if the variable 'some_variable' is not defined, Ansible uses the default value 5, rather than raising an \"undefined variable\" error and failing. If you are working within a role, you can also add a ``defaults/main.yml`` to define the default values for variables in your role." -msgstr "上記の例では、変数「some_variable」が定義されていない場合、Ansible は「undefined variable」エラーを発生させて失敗するのではなく、デフォルト値 5 を使用します。ロール内で作業している場合は、``defaults/main.yml`` を追加して、ロール内の変数のデフォルト値を定義することもできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:32 -msgid "Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure (in other words, :code:`{{ foo.bar.baz | default('DEFAULT') }}`) when you do not know if the intermediate values are defined." -msgstr "バージョン 2.8 から、Jinja で Undefined の値の属性にアクセスしようとすると、すぐにエラーが発生するのではなく、別の Undefined の値が返されます。これにより、中間値が定義されているかどうかわからない場合に、ネストされたデータ構造の中の値でデフォルトを簡単に使用することができるようになりました (つまり :code:`{{ foo.bar.baz | default('DEFAULT') }}`)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:35 -msgid "If you want to use the default value when variables evaluate to false or an empty string you have to set the second parameter to ``true``:" -msgstr "変数が false または空の文字列に評価されるときにデフォルト値を使用する場合は、2 番目のパラメーターを ``true`` に設定する必要があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:44 -msgid "Making variables optional" -msgstr "変数の任意設定" - -#: ../../rst/playbook_guide/playbooks_filters.rst:46 -msgid "By default Ansible requires values for all variables in a templated expression. However, you can make specific variables optional. For example, you might want to use a system default for some items and control the value for others. To make a variable optional, set the default value to the special variable ``omit``:" -msgstr "デフォルトでは、Ansible はテンプレート式のすべての変数に値を要求します。しかし、特定の変数を任意にすることができます。たとえば、一部の項目ではシステムのデフォルト値を使用し、他の項目では値を制御することができます。変数を任意にするには、特殊変数 ``omit`` にデフォルト値を設定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:61 -msgid "In this example, the default mode for the files ``/tmp/foo`` and ``/tmp/bar`` is determined by the umask of the system. Ansible does not send a value for ``mode``. Only the third file, ``/tmp/baz``, receives the `mode=0444` option." -msgstr "この例では、``/tmp/foo`` ファイルおよび ``/tmp/bar`` ファイルのデフォルトモードはシステムの umask により決定されます。Ansible は ``mode`` の値を送信しません。3 番目のファイルである ``/tmp/baz`` だけが `mode=0444` オプションを受け取ります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:63 -msgid "If you are \"chaining\" additional filters after the ``default(omit)`` filter, you should instead do something like this: ``\"{{ foo | default(None) | some_filter or omit }}\"``. In this example, the default ``None`` (Python null) value will cause the later filters to fail, which will trigger the ``or omit`` portion of the logic. Using ``omit`` in this manner is very specific to the later filters you are chaining though, so be prepared for some trial and error if you do this." -msgstr "``default(omit)`` フィルターの後に追加のフィルターを「連鎖」させる場合は、代わりに ``\"{{ foo | default(None) | some_filter or omit }}\"`` のようにしてください。この例では、デフォルトの ``None`` (Python null) の値により、後続のフィルターが失敗し、ロジックの ``or omit`` 部分が誘発されます。``omit`` をこのように使用することは、連鎖させる後続のフィルターに非常に依存するため、試行錯誤が必要になります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:69 -msgid "Defining mandatory values" -msgstr "必須値の定義" - -#: ../../rst/playbook_guide/playbooks_filters.rst:71 -msgid "If you configure Ansible to ignore undefined variables, you may want to define some values as mandatory. By default, Ansible fails if a variable in your playbook or command is undefined. You can configure Ansible to allow undefined variables by setting :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` to ``false``. In that case, you may want to require some variables to be defined. You can do this with:" -msgstr "未定義の変数を無視するように Ansible を設定する場合は、一部の値を必須として定義したい場合があります。デフォルトでは、Playbook またはコマンドの変数が未定義の場合、Ansible は失敗します。:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` を ``false`` に設定することで、未定義の変数を許可するように Ansible を設定することができます。その場合は、一部の変数の定義を必須にしたい場合があります。これには次の方法があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:77 -msgid "The variable value will be used as is, but the template evaluation will raise an error if it is undefined." -msgstr "変数の値はそのまま使用されますが、定義されていない場合は、テンプレートの評価でエラーが発生します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:79 -msgid "A convenient way of requiring a variable to be overridden is to give it an undefined value using the ``undef`` keyword. This can be useful in a role's defaults." -msgstr "変数の上書きを要求する便利な方法は、``undef`` キーワードを使用して未定義値を提供することです。これは、ロールのデフォルトで役に立ちます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:87 -msgid "Defining different values for true/false/null (ternary)" -msgstr "true/false/null (三項) に異なる値を定義する" - -#: ../../rst/playbook_guide/playbooks_filters.rst:89 -msgid "You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9):" -msgstr "テストを作成し、そのテストが true を返したときに使用する値と、false を返したときに使用する値を定義することができます (バージョン 1.9 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:95 -msgid "In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8):" -msgstr "さらに、true に使用する値を 1 つ定義し、false で 1 つの値、null で 3 番目の値を定義できます (バージョン 2.8 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:102 -msgid "Managing data types" -msgstr "データ型の管理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:104 -msgid "You might need to know, change, or set the data type on a variable. For example, a registered variable might contain a dictionary when your next task needs a list, or a user :ref:`prompt ` might return a string when your playbook needs a boolean value. Use the ``type_debug``, ``dict2items``, and ``items2dict`` filters to manage data types. You can also use the data type itself to cast a value as a specific data type." -msgstr "変数のデータ型の確認、変更、または設定を行う必要がある場合があります。たとえば、次のタスクでリストが必要なときに、登録済みの変数にディクショナリーが含まれていたり、Playbook でブール値が必要なときに、ユーザーの :ref:`prompt ` が文字列を返したりすることがあります。データタイプの管理には、``type_debug``、``dict2items``、および ``items2dict`` の各フィルターを使用します。また、データ型自体を使用して、値を特定のデータ型としてキャストすることもできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:107 -msgid "Discovering the data type" -msgstr "データ型の検出" - -#: ../../rst/playbook_guide/playbooks_filters.rst:111 -msgid "If you are unsure of the underlying Python type of a variable, you can use the ``type_debug`` filter to display it. This is useful in debugging when you need a particular type of variable:" -msgstr "変数の基礎となる Python の型がわからない場合は、``type_debug`` フィルターを使用して表示することができます。これはデバッグ時に特定の型の変数が必要になったときに便利です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:117 -msgid "You should note that, while this may seem like a useful filter for checking that you have the right type of data in a variable, you should often prefer :ref:`type tests `, which will allow you to test for specific data types." -msgstr "このフィルターは、変数のデータ型が正しいかどうかをチェックするのに便利なように思えますが、特定のデータ型をテストできる:ref:`type tests `の方が良い場合が多いことに注意してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:122 -msgid "Transforming dictionaries into lists" -msgstr "ディクショナリーのリストへの変換" - -#: ../../rst/playbook_guide/playbooks_filters.rst:127 -msgid "Use the ``dict2items`` filter to transform a dictionary into a list of items suitable for :ref:`looping `:" -msgstr "``dict2items`` フィルターを使用して、ディクショナリーを :ref:`looping ` に適した項目のリストに変換します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:133 -#: ../../rst/playbook_guide/playbooks_filters.rst:160 -msgid "Dictionary data (before applying the ``dict2items`` filter):" -msgstr "ディクショナリーデータ (``dict2items`` フィルターを適用する前):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:141 -#: ../../rst/playbook_guide/playbooks_filters.rst:168 -msgid "List data (after applying the ``dict2items`` filter):" -msgstr "データを一覧表示 (``dict2items`` フィルターを適用した後):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:152 -msgid "The ``dict2items`` filter is the reverse of the ``items2dict`` filter." -msgstr "``dict2items`` フィルターは、``items2dict`` フィルターの逆の効果があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:154 -msgid "If you want to configure the names of the keys, the ``dict2items`` filter accepts 2 keyword arguments. Pass the ``key_name`` and ``value_name`` arguments to configure the names of the keys in the list output:" -msgstr "キー名を設定する場合は、``dict2items`` フィルターは 2 つのキーワード引数を受け入れます。``key_name`` 引数および ``value_name`` 引数を渡すと、リスト出力のキーの名前を設定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:179 -msgid "Transforming lists into dictionaries" -msgstr "リストのディクショナリーへの変換" - -#: ../../rst/playbook_guide/playbooks_filters.rst:183 -msgid "Use the ``items2dict`` filter to transform a list into a dictionary, mapping the content into ``key: value`` pairs:" -msgstr "``items2dict`` フィルターを使用してリストをディクショナリーに変換し、コンテンツを ``key: value`` のペアにマッピングします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:189 -msgid "List data (before applying the ``items2dict`` filter):" -msgstr "リストデータ (``items2dict`` フィルターを適用する前):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:199 -msgid "Dictionary data (after applying the ``items2dict`` filter):" -msgstr "ディクショナリーデータ (``items2dict`` フィルターを適用した後):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:206 -msgid "The ``items2dict`` filter is the reverse of the ``dict2items`` filter." -msgstr "``items2dict`` フィルターは、``dict2items`` フィルターの逆の効果があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:208 -msgid "Not all lists use ``key`` to designate keys and ``value`` to designate values. For example:" -msgstr "すべてのリストで、キーの指定に ``key`` を使用し、値の指定に ``value`` を使用しているわけではありません。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:220 -msgid "In this example, you must pass the ``key_name`` and ``value_name`` arguments to configure the transformation. For example:" -msgstr "この例では、``key_name`` 引数と ``value_name`` 引数を渡すと、変換を設定する必要があります。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:226 -msgid "If you do not pass these arguments, or do not pass the correct values for your list, you will see ``KeyError: key`` or ``KeyError: my_typo``." -msgstr "これらの引数、またはリストに適した値を渡さない場合は、``KeyError: key`` または ``KeyError: my_typo`` が表示されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:229 -msgid "Forcing the data type" -msgstr "データ型を強制" - -#: ../../rst/playbook_guide/playbooks_filters.rst:231 -msgid "You can cast values as certain types. For example, if you expect the input \"True\" from a :ref:`vars_prompt ` and you want Ansible to recognize it as a boolean value instead of a string:" -msgstr "値を特定の型にキャストすることができます。たとえば、:ref:`vars_prompt ` から「True」という入力を期待していて、Ansible にそれを文字列ではなくブール値として認識させたい場合は、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:239 -msgid "If you want to perform a mathematical comparison on a fact and you want Ansible to recognize it as an integer instead of a string:" -msgstr "ファクトに対して数学的な比較を実行し、Ansible が文字列ではなく整数として認識する場合は、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:252 -msgid "Formatting data: YAML and JSON" -msgstr "データのフォーマット: YAML および JSON" - -#: ../../rst/playbook_guide/playbooks_filters.rst:254 -msgid "You can switch a data structure in a template from or to JSON or YAML format, with options for formatting, indenting, and loading data. The basic filters are occasionally useful for debugging:" -msgstr "テンプレート内のデータ構造を JSON 形式と YAML 形式との間で切り替えることができ、フォーマット化やインデント付け、データの読み込みなどのオプションも用意されています。基本的なフィルターは、時折、デバッグに役立ちます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:261 -msgid "For human readable output, you can use:" -msgstr "人が判読できる出力にするには、以下を使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:268 -msgid "You can change the indentation of either format:" -msgstr "いずれかの形式のインデントを変更できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:275 -msgid "The ``to_yaml`` and ``to_nice_yaml`` filters use the `PyYAML library`_ which has a default 80 symbol string length limit. That causes unexpected line break after 80th symbol (if there is a space after 80th symbol) To avoid such behavior and generate long lines, use the ``width`` option. You must use a hardcoded number to define the width, instead of a construction like ``float(\"inf\")``, because the filter does not support proxying Python functions. For example:" -msgstr "``to_yaml`` フィルターおよび ``to_nice_yaml`` フィルターは、デフォルトで 80 記号の文字列長制限を持つ `PyYAML library`_ を使用しています。このため、80 番目の記号の後に予期せぬ改行が発生します (80 番目のシンボルの後に空白がある場合)。このような動作を回避し、長い行を生成するには、``width`` オプションを使用します。フィルターは Python 関数のプロキシーをサポートしていないため、``float(\"inf\")`` のような構文ではなく、ハードコードされた数値を使用して幅を定義する必要があります。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:283 -msgid "The filter does support passing through other YAML parameters. For a full list, see the `PyYAML documentation`_ for ``dump()``." -msgstr "フィルターは他の YAML パラメーターのパススルーをサポートします。完全な一覧は、``dump()``の「`PyYAML ドキュメント`_」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:285 -msgid "If you are reading in some already formatted data:" -msgstr "すでにフォーマットされている一部のデータで読み取る場合:" - -#: ../../rst/playbook_guide/playbooks_filters.rst:292 -#: ../../rst/playbook_guide/playbooks_filters.rst:334 -msgid "for example:" -msgstr "以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:307 -msgid "Filter `to_json` and Unicode support" -msgstr "`to_json` と Unicode サポートをフィルタリング" - -#: ../../rst/playbook_guide/playbooks_filters.rst:309 -msgid "By default `to_json` and `to_nice_json` will convert data received to ASCII, so:" -msgstr "デフォルトでは、`to_json` および `to_nice_json` は、受診したデータを ASCII に変換するため、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:315 -msgid "will return:" -msgstr "以下が返されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:321 -msgid "To keep Unicode characters, pass the parameter `ensure_ascii=False` to the filter:" -msgstr "Unicode 文字を保持するには、パラメーター `ensure_ascii=False` をフィルターに渡します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:331 -msgid "To parse multi-document YAML strings, the ``from_yaml_all`` filter is provided. The ``from_yaml_all`` filter will return a generator of parsed YAML documents." -msgstr "複数ドキュメントの YAML 文字列を解析するために、``from_yaml_all`` フィルターが提供されます。``from_yaml_all`` フィルターは解析された YAML ドキュメントのジェネレーターを返します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:349 -msgid "Combining and selecting data" -msgstr "データの統合および選択" - -#: ../../rst/playbook_guide/playbooks_filters.rst:351 -msgid "You can combine data from multiple sources and types, and select values from large data structures, giving you precise control over complex data." -msgstr "複数のソースやタイプのデータを組み合わせたり、大規模なデータ構造から値を選択したりすることで、複雑なデータを正確に制御することができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:356 -msgid "Combining items from multiple lists: zip and zip_longest" -msgstr "複数のリストからの項目の組み合わせ: zip および zip_longest" - -#: ../../rst/playbook_guide/playbooks_filters.rst:360 -msgid "To get a list combining the elements of other lists use ``zip``:" -msgstr "他のリストの要素を組み合わせたリストを取得するには、``zip`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:376 -msgid "To always exhaust all lists use ``zip_longest``:" -msgstr "すべての一覧を常に使い切るには、``zip_longest`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:386 -msgid "Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``:" -msgstr "上記の ``items2dict`` フィルターの出力と同様に、これらのフィルターを使用して ``dict`` を作成できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:392 -msgid "List data (before applying the ``zip`` filter):" -msgstr "リストデータ (``zip`` フィルターを適用する前):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:403 -msgid "Dictionary data (after applying the ``zip`` filter):" -msgstr "ディクショナリーデータ (``zip`` フィルターを適用した後):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:411 -msgid "Combining objects and subelements" -msgstr "オブジェクトとサブ要素の統合" - -#: ../../rst/playbook_guide/playbooks_filters.rst:415 -msgid "The ``subelements`` filter produces a product of an object and the subelement values of that object, similar to the ``subelements`` lookup. This lets you specify individual subelements to use in a template. For example, this expression:" -msgstr "``subelements`` フィルターは、``subelements`` ルックアップと同様に、オブジェクトとそのオブジェクトのサブエレメントの値の積を生成します。これにより、テンプレートで使用する個々のサブエレメントを指定することができます。たとえば、以下のような式になります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:421 -msgid "Data before applying the ``subelements`` filter:" -msgstr "``subelements`` フィルターの適用前のデータ:" - -#: ../../rst/playbook_guide/playbooks_filters.rst:439 -msgid "Data after applying the ``subelements`` filter:" -msgstr "``subelements`` フィルターの適用後のデータ:" - -#: ../../rst/playbook_guide/playbooks_filters.rst:469 -msgid "You can use the transformed data with ``loop`` to iterate over the same subelement for multiple objects:" -msgstr "変換したデータを ``loop`` とともに使用して、複数のオブジェクトに対して同じサブ要素を繰り返すことができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:482 -msgid "Combining hashes/dictionaries" -msgstr "ハッシュ/ディクショナリーの統合" - -#: ../../rst/playbook_guide/playbooks_filters.rst:486 -msgid "The ``combine`` filter allows hashes to be merged. For example, the following would override keys in one hash:" -msgstr "``combine`` フィルターはハッシュをマージできます。たとえば、以下は 1 つのハッシュ内のキーをオーバーライドします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:492 -msgid "The resulting hash would be:" -msgstr "生成されるハッシュは、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:498 -msgid "The filter can also take multiple arguments to merge:" -msgstr "フィルターは複数の引数を使用してマージすることもできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:505 -msgid "In this case, keys in ``d`` would override those in ``c``, which would override those in ``b``, and so on." -msgstr "この場合、``d`` のキーは ``c`` のキーを上書きし、``b`` のキーも同様に上書きされます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:507 -msgid "The filter also accepts two optional parameters: ``recursive`` and ``list_merge``." -msgstr "フィルターは、``recursive`` および ``list_merge`` の 2 つの任意のパラメーターも使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:512 -msgid "recursive" -msgstr "再帰" - -#: ../../rst/playbook_guide/playbooks_filters.rst:510 -msgid "Is a boolean, default to ``False``. Should the ``combine`` recursively merge nested hashes. Note: It does **not** depend on the value of the ``hash_behaviour`` setting in ``ansible.cfg``." -msgstr "ブール値で、デフォルトは ``False`` です。``combine`` が入れ子になったハッシュを再帰的にマージするかどうかを指定します。注: ``ansible.cfg`` の ``hash_behaviour`` 設定の値には **依存しません** 。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:516 -msgid "list_merge" -msgstr "list_merge" - -#: ../../rst/playbook_guide/playbooks_filters.rst:515 -msgid "Is a string, its possible values are ``replace`` (default), ``keep``, ``append``, ``prepend``, ``append_rp`` or ``prepend_rp``. It modifies the behaviour of ``combine`` when the hashes to merge contain arrays/lists." -msgstr "使用できる値は ``replace`` (デフォルト)、``keep``、``append``、``prepend``、``append_rp``、または ``prepend_rp`` です。ハッシュに配列/リストをマージする際に ``combine`` の動作を変更します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:532 -msgid "If ``recursive=False`` (the default), nested hash aren't merged:" -msgstr "``recursive=False`` (デフォルト) の場合は、ネストされたハッシュがマージされません。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:538 -#: ../../rst/playbook_guide/playbooks_filters.rst:554 -#: ../../rst/playbook_guide/playbooks_filters.rst:580 -#: ../../rst/playbook_guide/playbooks_filters.rst:593 -#: ../../rst/playbook_guide/playbooks_filters.rst:606 -#: ../../rst/playbook_guide/playbooks_filters.rst:620 -#: ../../rst/playbook_guide/playbooks_filters.rst:649 -#: ../../rst/playbook_guide/playbooks_filters.rst:668 -#: ../../rst/playbook_guide/playbooks_filters.rst:714 -#: ../../rst/playbook_guide/playbooks_filters.rst:817 -msgid "This would result in:" -msgstr "これにより、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:548 -msgid "If ``recursive=True``, recurse into nested hash and merge their keys:" -msgstr "``recursive=True`` の場合は、ネストされたハッシュを再帰的に使用して、鍵をマージします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:565 -msgid "If ``list_merge='replace'`` (the default), arrays from the right hash will \"replace\" the ones in the left hash:" -msgstr "``list_merge='replace'`` (デフォルト) の場合、右ハッシュの配列は左ハッシュの配列を「置き換え」ます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:587 -msgid "If ``list_merge='keep'``, arrays from the left hash will be kept:" -msgstr "``list_merge='keep'`` の場合は、左のハッシュからの配列が保持されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:600 -msgid "If ``list_merge='append'``, arrays from the right hash will be appended to the ones in the left hash:" -msgstr "``list_merge='append'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列に追加されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:614 -msgid "If ``list_merge='prepend'``, arrays from the right hash will be prepended to the ones in the left hash:" -msgstr "``list_merge='prepend'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列の前に追加されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:628 -msgid "If ``list_merge='append_rp'``, arrays from the right hash will be appended to the ones in the left hash. Elements of arrays in the left hash that are also in the corresponding array of the right hash will be removed (\"rp\" stands for \"remove present\"). Duplicate elements that aren't in both hashes are kept:" -msgstr "``list_merge='append_rp'`` の場合は、右ハッシュの配列が、左ハッシュの配列に追加されます。左ハッシュの配列のうち、右ハッシュの対応する配列にもある要素は削除されます (「rp」は「remove present」の略)。両方のハッシュに存在しない重複した要素は保持されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:662 -msgid "If ``list_merge='prepend_rp'``, the behavior is similar to the one for ``append_rp``, but elements of arrays in the right hash are prepended:" -msgstr "``list_merge='prepend_rp'`` の場合、動作は ``append_rp`` のものと似ていますが、右のハッシュ内の配列の要素の前に追加されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:681 -msgid "``recursive`` and ``list_merge`` can be used together:" -msgstr "``recursive`` および ``list_merge`` は一緒に使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:739 -msgid "Selecting values from arrays or hashtables" -msgstr "配列またはハッシュテーブルからの値の選択" - -#: ../../rst/playbook_guide/playbooks_filters.rst:743 -msgid "The `extract` filter is used to map from a list of indices to a list of values from a container (hash or array):" -msgstr "`extract` フィルターは、インデックスのリストから、コンテナー (ハッシュまたは配列) の値のリストへのマッピングに使用されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:750 -msgid "The results of the above expressions would be:" -msgstr "上記の式の結果は、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:757 -msgid "The filter can take another argument:" -msgstr "フィルターは別の引数を取ることができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:763 -msgid "This takes the list of hosts in group 'x', looks them up in `hostvars`, and then looks up the `ec2_ip_address` of the result. The final result is a list of IP addresses for the hosts in group 'x'." -msgstr "これにより、グループ「x」のホスト一覧が `hostvars` で検索され、結果の `ec2_ip_address` を探します。最終結果は、グループ「x」のホストの IP アドレス一覧になります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:765 -msgid "The third argument to the filter can also be a list, for a recursive lookup inside the container:" -msgstr "フィルターの第 3 引数にはリストを指定することもでき、コンテナー内の再帰的なルックアップが可能です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:771 -msgid "This would return a list containing the value of `b['a']['x']['y']`." -msgstr "これにより、`b['a']['x']['y']` の値が含まれるリストが返されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:774 -msgid "Combining lists" -msgstr "リストの統合" - -#: ../../rst/playbook_guide/playbooks_filters.rst:776 -msgid "This set of filters returns a list of combined lists." -msgstr "このフィルターセットは、組み合わせたリストを返します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:780 -msgid "permutations" -msgstr "置換" - -#: ../../rst/playbook_guide/playbooks_filters.rst:781 -msgid "To get permutations of a list:" -msgstr "リストの置換を取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:794 -msgid "combinations" -msgstr "組み合わせ" - -#: ../../rst/playbook_guide/playbooks_filters.rst:795 -msgid "Combinations always require a set size:" -msgstr "組み合わせには常にセットサイズが必要です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:803 -msgid "Also see the :ref:`zip_filter`" -msgstr "また、「:ref:`zip_filter`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:806 -msgid "products" -msgstr "製品" - -#: ../../rst/playbook_guide/playbooks_filters.rst:807 -msgid "The product filter returns the `cartesian product `_ of the input iterables. This is roughly equivalent to nested for-loops in a generator expression." -msgstr "製品フィルターは、入力されたイテラブルの `cartesian product `_ を返します。これはジェネレータ式の入れ子になった for-loop とほぼ同じです。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:826 -msgid "Selecting JSON data: JSON queries" -msgstr "JSON データの選択: JSON クエリー" - -#: ../../rst/playbook_guide/playbooks_filters.rst:828 -msgid "To select a single element or a data subset from a complex data structure in JSON format (for example, Ansible facts), use the ``json_query`` filter. The ``json_query`` filter lets you query a complex JSON structure and iterate over it using a loop structure." -msgstr "JSON 形式の複雑なデータ構造 (Ansible ファクトなど) から単一の要素やデータサブセットを選択するには、``json_query`` フィルターを使用します。``json_query`` フィルターを使用すると、複雑な JSON 構造を照会し、ループ構造を使用して反復処理することができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:832 -#: ../../rst/playbook_guide/playbooks_filters.rst:991 -msgid "This filter has migrated to the `community.general `_ collection. Follow the installation instructions to install that collection." -msgstr "`community.general `_ フィルターはコレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:835 -msgid "You must manually install the **jmespath** dependency on the Ansible controller before using this filter. This filter is built upon **jmespath**, and you can use the same syntax. For examples, see `jmespath examples `_." -msgstr "このフィルターを使用する前に、Ansible コントローラーに **jmespath** 依存関係を手動でインストールする必要があります。このフィルターは **jmespath** をベースに作られており、同じ構文を使用することができます。例については、`jmespath examples `_ を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:837 -msgid "Consider this data structure:" -msgstr "このデータ構造を考えてみましょう。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:888 -msgid "To extract all clusters from this structure, you can use the following query:" -msgstr "この構造からすべてのクラスターを抽出するには、以下のクエリーを使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:897 -msgid "To extract all server names:" -msgstr "すべてのサーバー名を抽出するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:906 -msgid "To extract ports from cluster1:" -msgstr "cluster1 からポートを抽出するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:917 -msgid "You can use a variable to make the query more readable." -msgstr "変数を使用すると、クエリーの読み取りがより容易になります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:919 -msgid "To print out the ports from cluster1 in a comma separated string:" -msgstr "cluster1 のポートをコンマ区切りの文字列で表示するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:927 -msgid "In the example above, quoting literals using backticks avoids escaping quotes and maintains readability." -msgstr "上の例では、リテラルを backtick で引用することで、引用符のエスケープを避け、読みやすさを維持しています。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:929 -msgid "You can use YAML `single quote escaping `_:" -msgstr "YAML の `single quote escaping `_ を使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:938 -msgid "Escaping single quotes within single quotes in YAML is done by doubling the single quote." -msgstr "YAML の一重引用符内で一重引用符をエスケープする場合は、一重引用符を二重にします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:940 -msgid "To get a hash map with all ports and names of a cluster:" -msgstr "クラスターのすべてのポートおよび名前を持つハッシュマップを取得するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:951 -msgid "To extract ports from all clusters with name starting with 'server1':" -msgstr "「server1」で始まる名前の全クラスターからポートを抽出するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:961 -msgid "To extract ports from all clusters with name containing 'server1':" -msgstr "「server1」を含む名前の全クラスターからポートを抽出するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:971 -msgid "while using ``starts_with`` and ``contains``, you have to use `` to_json | from_json `` filter for correct parsing of data structure." -msgstr "``starts_with`` および ``contains`` を使用する場合は、データ構造を正しく解析するために ``to_json | from_json`` フィルターを使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:975 -msgid "Randomizing data" -msgstr "データのランダム化" - -#: ../../rst/playbook_guide/playbooks_filters.rst:977 -msgid "When you need a randomly generated value, use one of these filters." -msgstr "ランダムに生成された値が必要な場合は、これらのフィルターのいずれかを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:983 -msgid "Random MAC addresses" -msgstr "ランダムな MAC アドレス" - -#: ../../rst/playbook_guide/playbooks_filters.rst:987 -msgid "This filter can be used to generate a random MAC address from a string prefix." -msgstr "このフィルターは、文字列プレフィックスからランダムな MAC アドレスを生成するために使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:993 -msgid "To get a random MAC address from a string prefix starting with '52:54:00':" -msgstr "'52:54:00' で始まる文字列プレフィックスからランダムな MAC アドレスを取得するには、次のコマンドを実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1000 -msgid "Note that if anything is wrong with the prefix string, the filter will issue an error." -msgstr "プレフィックスの文字列で不具合が生じた場合は、フィルターによりエラーが生じることに注意してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1004 -msgid "As of Ansible version 2.9, you can also initialize the random number generator from a seed to create random-but-idempotent MAC addresses:" -msgstr "Ansible バージョン 2.9 以降では、シードから乱数ジェネレーターを初期化し、ランダムで冪等な MAC アドレスを作成することもできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1014 -msgid "Random items or numbers" -msgstr "ランダムな項目または数字" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1016 -msgid "The ``random`` filter in Ansible is an extension of the default Jinja2 random filter, and can be used to return a random item from a sequence of items or to generate a random number based on a range." -msgstr "Ansible の``random`` フィルターは、デフォルトの Jinja2 ランダムフィルターを拡張したもので、一連のアイテムからランダムな項目を返したり、範囲に基づいてランダムな数値を生成したりするのに使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1018 -msgid "To get a random item from a list:" -msgstr "リストからランダムなアイテムを取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1025 -msgid "To get a random number between 0 (inclusive) and a specified integer (exclusive):" -msgstr "0 (含む) から指定した整数 (除く) の間の乱数を取得するには、次のようにします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1032 -msgid "To get a random number from 0 to 100 but in steps of 10:" -msgstr "0 から 100 までの 10 のステップで乱数を取得するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1039 -msgid "To get a random number from 1 to 100 but in steps of 10:" -msgstr "1 から 100 までの 10 のステップで乱数を取得するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1048 -msgid "You can initialize the random number generator from a seed to create random-but-idempotent numbers:" -msgstr "シードから乱数ジェネレーターを初期化し、ランダムで冪等な数字を作成できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1055 -msgid "Shuffling a list" -msgstr "リストのシャッフル" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1057 -msgid "The ``shuffle`` filter randomizes an existing list, giving a different order every invocation." -msgstr "``shuffle`` フィルターは、既存のリストをランダム化し、呼び出しごとに異なる順序を提供します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1059 -msgid "To get a random list from an existing list:" -msgstr "既存のリストからランダムなリストを取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1068 -msgid "You can initialize the shuffle generator from a seed to generate a random-but-idempotent order:" -msgstr "シャッフルジェネレーターをシードから初期化して、ランダムで冪等な順序を生成することができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1075 -msgid "The shuffle filter returns a list whenever possible. If you use it with a non 'listable' item, the filter does nothing." -msgstr "シャッフルフィルターは可能な場合常にリストを返します。「リスト可能」ではない項目で使用すると、フィルターは何も行いません。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1081 -msgid "Managing list variables" -msgstr "リスト変数の管理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1083 -msgid "You can search for the minimum or maximum value in a list, or flatten a multi-level list." -msgstr "リストの最小値や最大値を検索したり、複数レベルのリストをフラットにすることができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1085 -msgid "To get the minimum value from list of numbers:" -msgstr "数値リストから最小値を取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1093 -msgid "To get the minimum value in a list of objects:" -msgstr "オブジェクトのリストで最小値を取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1099 -msgid "To get the maximum value from a list of numbers:" -msgstr "数値リストから最大値を取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1107 -msgid "To get the maximum value in a list of objects:" -msgstr "オブジェクトのリストで最大値を取得するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1115 -msgid "Flatten a list (same thing the `flatten` lookup does):" -msgstr "リストをフラット化します (`flatten` ルックアップと同等)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1122 -msgid "Flatten only the first level of a list (akin to the `items` lookup):" -msgstr "リストの最初のレベルのみをフラット化します (`items` ルックアップと同等)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1132 -msgid "Preserve nulls in a list, by default flatten removes them. :" -msgstr "リストに null を保持します。デフォルトでは、フラット化はこれらを削除します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1143 -msgid "Selecting from sets or lists (set theory)" -msgstr "セットまたはリストの中から選択 (理論の設定)" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1145 -msgid "You can select or combine items from sets or lists." -msgstr "セットまたはリストから項目を選択または組み合わせることができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1149 -msgid "To get a unique set from a list:" -msgstr "リストから一意のセットを取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1157 -msgid "To get a union of two lists:" -msgstr "2 つのリストを組み合わせて取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1166 -msgid "To get the intersection of 2 lists (unique list of all items in both):" -msgstr "2 つのリスト (両方の全項目の一意のリスト) で構成されるものを取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1175 -msgid "To get the difference of 2 lists (items in 1 that don't exist in 2):" -msgstr "2 つのリストの相違点を取得するには (2 に存在しない 1 の項目)、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1184 -msgid "To get the symmetric difference of 2 lists (items exclusive to each list):" -msgstr "2 つのリストの対称的な違いを取得する (各リストへの除外) には、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1196 -msgid "Calculating numbers (math)" -msgstr "数字の計算 (数学)" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1200 -msgid "You can calculate logs, powers, and roots of numbers with Ansible filters. Jinja2 provides other mathematical functions like abs() and round()." -msgstr "Ansible のフィルターを使用して、対数、累乗、おより根を計算することができます。また、Jinja2 には abs() や round() などの数学関数も用意されています。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1202 -msgid "Get the logarithm (default is e):" -msgstr "対数を取得します (デフォルトは e)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1209 -msgid "Get the base 10 logarithm:" -msgstr "底が 10 の対数を取得します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1216 -msgid "Give me the power of 2! (or 5):" -msgstr "2 の累乗 (または 5)を取得します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1223 -msgid "Square root, or the 5th:" -msgstr "平方根または 5 乗根を取得します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1235 -msgid "Managing network interactions" -msgstr "ネットワーク対話の管理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1237 -msgid "These filters help you with common network tasks." -msgstr "これらのフィルターは、一般的なネットワークタスクの使用に役立ちます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1241 -msgid "These filters have migrated to the `ansible.netcommon `_ collection. Follow the installation instructions to install that collection." -msgstr "これらのフィルターは `ansible.netcommon `_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1246 -msgid "IP address filters" -msgstr "IP アドレスフィルター" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1250 -msgid "To test if a string is a valid IP address:" -msgstr "文字列が有効な IP アドレスかどうかをテストするには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1256 -msgid "You can also require a specific IP protocol version:" -msgstr "さらに、特定の IP プロトコルバージョンが必要です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1263 -msgid "IP address filter can also be used to extract specific information from an IP address. For example, to get the IP address itself from a CIDR, you can use:" -msgstr "IP アドレスフィルターを使用して、IP アドレスから特定の情報を抽出することもできます。たとえば、CIDR から IP アドレス自体を取得するには、以下を使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1271 -msgid "More information about ``ipaddr`` filter and complete usage guide can be found in :ref:`playbooks_filters_ipaddr`." -msgstr "``ipaddr`` フィルターの詳細と完全な使用ガイドは、「:ref:`playbooks_filters_ipaddr`」にあります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1277 -msgid "Network CLI filters" -msgstr "ネットワーク CLI フィルター" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1281 -msgid "To convert the output of a network device CLI command into structured JSON output, use the ``parse_cli`` filter:" -msgstr "ネットワーク機器の CLI コマンドの出力を構造化された JSON 出力に変換するには、``parse_cli`` フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1288 -msgid "The ``parse_cli`` filter will load the spec file and pass the command output through it, returning JSON output. The YAML spec file defines how to parse the CLI output." -msgstr "``parse_cli`` フィルターは、spec ファイルを読み込み、コマンド出力を通して JSON 出力を返します。YAML の spec ファイルは、CLI 出力をどのように解析するかを定義します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1291 -msgid "The spec file should be valid formatted YAML. It defines how to parse the CLI output and return JSON data. Below is an example of a valid spec file that will parse the output from the ``show vlan`` command." -msgstr "spec ファイルは有効な形式の YAML でなければなりません。CLI の出力をどのように解析し、JSON データを返すかを定義します。以下は、``show vlan`` コマンドからの出力を解析する有効な spec ファイルの例です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1313 -#: ../../rst/playbook_guide/playbooks_filters.rst:1419 -msgid "The spec file above will return a JSON data structure that is a list of hashes with the parsed VLAN information." -msgstr "上記の spec ファイルは、解析された VLAN 情報を持つハッシュのリストである JSON データ構造を返します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1316 -msgid "The same command could be parsed into a hash by using the key and values directives. Here is an example of how to parse the output into a hash value using the same ``show vlan`` command." -msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan`` コマンドを使用して出力をハッシュ値に解析する例です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1339 -msgid "Another common use case for parsing CLI commands is to break a large command into blocks that can be parsed. This can be done using the ``start_block`` and ``end_block`` directives to break the command into blocks that can be parsed." -msgstr "CLI コマンドを解析するもう一つの一般的なユースケースは、大きなコマンドを解析可能なブロックに分割することです。これは、``start_block`` ディレクティブと ``end_block`` ディレクティブを使用して、コマンドを解析可能なブロックに分割することで行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1363 -msgid "The example above will parse the output of ``show interface`` into a list of hashes." -msgstr "上の例では、``show interface`` の出力を解析して、ハッシュのリストを作成します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1366 -msgid "The network filters also support parsing the output of a CLI command using the TextFSM library. To parse the CLI output with TextFSM use the following filter:" -msgstr "ネットワークフィルターは、TextFSM ライブラリーを使用して CLI コマンドの出力の解析もサポートします。TextFSM で CLI 出力を解析するには、以下のフィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1374 -msgid "Use of the TextFSM filter requires the TextFSM library to be installed." -msgstr "TextFSM フィルターを使用するには、TextFSM ライブラリーをインストールする必要があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1377 -msgid "Network XML filters" -msgstr "ネットワーク XML フィルター" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1381 -msgid "To convert the XML output of a network device command into structured JSON output, use the ``parse_xml`` filter:" -msgstr "ネットワークデバイスコマンドの XML 出力を構造化された JSON 出力に変換するには、``parse_xml`` フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1388 -msgid "The ``parse_xml`` filter will load the spec file and pass the command output through formatted as JSON." -msgstr "``parse_xml`` フィルターは、spec ファイルを読み込み、JSON としてフォーマットされたコマンド出力を渡します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1391 -msgid "The spec file should be valid formatted YAML. It defines how to parse the XML output and return JSON data." -msgstr "仕様ファイルは有効な YAML 形式である必要があります。XML 出力を解析し、JSON データを返す方法を定義します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1394 -msgid "Below is an example of a valid spec file that will parse the output from the ``show vlan | display xml`` command." -msgstr "以下は、``show vlan | display xml`` コマンドの出力を解析するための有効な spec ファイルの例です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1422 -msgid "The same command could be parsed into a hash by using the key and values directives. Here is an example of how to parse the output into a hash value using the same ``show vlan | display xml`` command." -msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan | display xml`` コマンドを使用して出力をハッシュ値に解析する例です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1450 -msgid "The value of ``top`` is the XPath relative to the XML root node. In the example XML output given below, the value of ``top`` is ``configuration/vlans/vlan``, which is an XPath expression relative to the root node (). ``configuration`` in the value of ``top`` is the outer most container node, and ``vlan`` is the inner-most container node." -msgstr "``top`` の値は、XML ルートノードに対する相対的な XPath です。以下の XML 出力例では、``top`` の値は ``configuration/vlans/vlan`` であり、これはルートノード () に対する相対的な XPath 式です。``top`` の値の ``configuration`` は最も外側のコンテナーノードであり、``vlan`` は最も内側のコンテナーノードです。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1456 -msgid "``items`` is a dictionary of key-value pairs that map user-defined names to XPath expressions that select elements. The Xpath expression is relative to the value of the XPath value contained in ``top``. For example, the ``vlan_id`` in the spec file is a user defined name and its value ``vlan-id`` is the relative to the value of XPath in ``top``" -msgstr "``items`` は、ユーザー定義の名前を、要素を選択する XPath 式にマッピングするキーと値のペアのディクショナリーです。Xpath 式は、``top`` に含まれる XPath 値の値に対する相対値です。たとえば、spec ファイルの ``vlan_id`` はユーザー定義の名前で、その値 ``vlan-id`` は、``top`` に含まれる XPath の値に対する相対値です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1461 -msgid "Attributes of XML tags can be extracted using XPath expressions. The value of ``state`` in the spec is an XPath expression used to get the attributes of the ``vlan`` tag in output XML.:" -msgstr "XML タグの属性は、XPath 式を用いて抽出することができます。仕様書の ``state`` の値は、出力された XML の ``vlan`` タグの属性を取得するために使用される XPath 式です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1479 -msgid "For more information on supported XPath expressions, see `XPath Support `_." -msgstr "サポートされる XPath 式の詳細は、「`XPath Support `_」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1482 -msgid "Network VLAN filters" -msgstr "ネットワーク VLAN フィルター" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1486 -msgid "Use the ``vlan_parser`` filter to transform an unsorted list of VLAN integers into a sorted string list of integers according to IOS-like VLAN list rules. This list has the following properties:" -msgstr "``vlan_parser`` フィルターを使用して、ソートされていない VLAN 整数のリストを、IOS のような VLAN リストのルールに従ってソートされた整数の文字列リストに変換します。このリストには以下のプロパティーがあります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1489 -msgid "Vlans are listed in ascending order." -msgstr "VLAN は昇順でリストされます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1490 -msgid "Three or more consecutive VLANs are listed with a dash." -msgstr "3 つ以上の連続した VLAN はダッシュ付きでリストされます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1491 -msgid "The first line of the list can be first_line_len characters long." -msgstr "リストの最初の行は、first_line_len 文字の長さになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1492 -msgid "Subsequent list lines can be other_line_len characters." -msgstr "後続のリスト行は、other_line_len 文字になります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1494 -msgid "To sort a VLAN list:" -msgstr "VLAN リストをソートするには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1500 -msgid "This example renders the following sorted list:" -msgstr "この例では、以下のソートリストを示しています。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1507 -msgid "Another example Jinja template:" -msgstr "Jinja テンプレートの他の例:" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1517 -msgid "This allows for dynamic generation of VLAN lists on a Cisco IOS tagged interface. You can store an exhaustive raw list of the exact VLANs required for an interface and then compare that to the parsed IOS output that would actually be generated for the configuration." -msgstr "これにより、Cisco IOS タグ付きインターフェース上の VLAN リストを動的に生成することができます。インターフェースに必要な正確な VLAN の網羅的な生のリストを保存し、それを設定のために実際に生成されるであろう解析された IOS 出力と比較することができます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1523 -msgid "Hashing and encrypting strings and passwords" -msgstr "文字列およびパスワードのハッシュ処理および暗号化" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1527 -msgid "To get the sha1 hash of a string:" -msgstr "文字列の sha1 ハッシュを取得するには、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1534 -msgid "To get the md5 hash of a string:" -msgstr "文字列の md5 ハッシュを取得するには、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1541 -msgid "Get a string checksum:" -msgstr "文字列のチェックサムを取得します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1548 -msgid "Other hashes (platform dependent):" -msgstr "その他のハッシュ (プラットフォームに依存):" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1554 -msgid "To get a sha512 password hash (random salt):" -msgstr "sha512 パスワードハッシュ (任意の salt) を取得するには、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1561 -msgid "To get a sha256 password hash with a specific salt:" -msgstr "特定の salt を持つ sha256 パスワードハッシュを取得するには、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1568 -msgid "An idempotent method to generate unique hashes per system is to use a salt that is consistent between runs:" -msgstr "システムごとに一意のハッシュを生成する冪等な方法は、実行間で一貫性のある salt を使用することです。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1575 -msgid "Hash types available depend on the control system running Ansible, 'hash' depends on `hashlib `_, password_hash depends on `passlib `_. The `crypt `_ is used as a fallback if ``passlib`` is not installed." -msgstr "利用可能なハッシュタイプは、Ansible を実行している制御システムに依存しており、「hash」は `hashlib `_ に、「password_hash」は `passlib `_ に依存しています。`crypt `_ は ``passlib`` がインストールされていない場合のフォールバックとして使用されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1579 -msgid "Some hash types allow providing a rounds parameter:" -msgstr "ハッシュタイプによっては、rounds パラメーターを指定できるものもあります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1586 -msgid "The filter `password_hash` produces different results depending on whether you installed `passlib` or not." -msgstr "フィルター `password_hash` は、`passlib` をインストールしたかどうかによって異なる結果を生成します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1588 -msgid "To ensure idempotency, specify `rounds` to be neither `crypt`'s nor `passlib`'s default, which is `5000` for `crypt` and a variable value (`535000` for sha256, `656000` for sha512) for `passlib`:" -msgstr "冪等性を確保するには、`rounds` を `crypt` または `passlib`のデフォルトにならないように指定します。これは、`crypt` の場合は `5000`、`passlib` の場合は変数値 (sha256 の場合は `535000`、sha512 の場合は`656000`) です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1595 -msgid "Hash type 'blowfish' (BCrypt) provides the facility to specify the version of the BCrypt algorithm." -msgstr "ハッシュタイプ 'blowfish' (BCrypt) は、BCrypt アルゴリズムのバージョンを指定する機能を提供します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1603 -msgid "The parameter is only available for `blowfish (BCrypt) `_. Other hash types will simply ignore this parameter. Valid values for this parameter are: ['2', '2a', '2y', '2b']" -msgstr "このパラメーターは、`blowfish (BCrypt) `_ でのみ利用できます。他のハッシュタイプは、このパラメーターを無視します。このパラメーターに対する有効な値は ['2', '2a', '2y', '2b'] です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1609 -msgid "You can also use the Ansible :ref:`vault ` filter to encrypt data:" -msgstr "Ansible の :ref:`vault ` フィルターを使用してデータを暗号化することもできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1624 -msgid "And then decrypt it using the unvault filter:" -msgstr "その後、unvault フィルターを使用して復号します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1641 -msgid "Manipulating text" -msgstr "テキストの操作" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1643 -msgid "Several filters work with text, including URLs, file names, and path names." -msgstr "いくつかのフィルターは、URL、ファイル名、パス名などのテキストを扱います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1648 -msgid "Adding comments to files" -msgstr "ファイルへのコメントの追加" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1650 -msgid "The ``comment`` filter lets you create comments in a file from text in a template, with a variety of comment styles. By default Ansible uses ``#`` to start a comment line and adds a blank comment line above and below your comment text. For example the following:" -msgstr "``comment`` フィルターを使用すると、テンプレート内のテキストから、さまざまなコメントスタイルでファイル内にコメントを作成することができます。Ansible のデフォルトでは、``#`` を使用してコメント行を開始し、コメントテキストの上下に空白のコメント行を追加します。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1656 -msgid "produces this output:" -msgstr "次の出力を生成します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1664 -msgid "Ansible offers styles for comments in C (``//...``), C block (``/*...*/``), Erlang (``%...``) and XML (````):" -msgstr "Ansibleでは、C (``//...``)、C ブロック (``/*...*/``)、Erlang (``%...``)、および XML (````) のコメント用スタイルを提供しています。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1674 -msgid "You can define a custom comment character. This filter:" -msgstr "カスタムのコメント文字を定義できます。このフィルターは、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1680 -msgid "produces:" -msgstr "生成:" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1688 -msgid "You can fully customize the comment style:" -msgstr "コメントスタイルを完全にカスタマイズすることもできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1694 -msgid "That creates the following output:" -msgstr "これにより、以下の出力が作成されます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1706 -msgid "The filter can also be applied to any Ansible variable. For example to make the output of the ``ansible_managed`` variable more readable, we can change the definition in the ``ansible.cfg`` file to this:" -msgstr "フィルターは、Ansible 変数にも適用することもできます。たとえば、``ansible_managed`` 変数の出力をより読みやすくするために、``ansible.cfg`` ファイルの定義を以下のように変更します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1720 -msgid "and then use the variable with the `comment` filter:" -msgstr "次に、`comment` フィルターで変数を使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1726 -msgid "which produces this output:" -msgstr "これは、次の出力を生成します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1740 -msgid "URLEncode Variables" -msgstr "URLEncode 変数" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1742 -msgid "The ``urlencode`` filter quotes data for use in a URL path or query using UTF-8:" -msgstr "``urlencode`` フィルターは、URL パスを使用、または UTF-8 を使用したクエリーで使用するデータを引用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1750 -msgid "Splitting URLs" -msgstr "URL の分割" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1754 -msgid "The ``urlsplit`` filter extracts the fragment, hostname, netloc, password, path, port, query, scheme, and username from an URL. With no arguments, returns a dictionary of all the fields:" -msgstr "``urlsplit`` フィルターは、URL からフラグメント、ホスト名、netloc、パスワード、パス、ポート、クエリー、スキーム、およびユーザー名を抽出します。引数がない場合は、すべてのフィールドのディクショナリーを返します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1800 -msgid "Searching strings with regular expressions" -msgstr "正規表現を使用した文字列の検索" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1802 -msgid "To search in a string or extract parts of a string with a regular expression, use the ``regex_search`` filter:" -msgstr "文字列の検索または正規表現で文字列の部分を抽出するには、``regex_search`` フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1822 -msgid "The ``regex_search`` filter returns an empty string if it cannot find a match:" -msgstr "``regex_search`` フィルターは、一致するものが見つからない場合に空の文字列を返します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1833 -msgid "The ``regex_search`` filter returns ``None`` when used in a Jinja expression (for example in conjunction with operators, other filters, and so on). See the two examples below." -msgstr "Jinja 式で使用されると、``regex_search`` フィルターは ``None`` を返します )たとえば演算子、他のフィルターなど)。以下の 2 例を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1842 -msgid "This is due to historic behavior and the custom re-implementation of some of the Jinja internals in Ansible. Enable the ``jinja2_native`` setting if you want the ``regex_search`` filter to always return ``None`` if it cannot find a match. See :ref:`jinja2_faqs` for details." -msgstr "これは、Ansible の Jinja 内部のいくつかの歴史的な動作とカスタムの再実装によるものです。一致するものがみつからない場合に ``regex_search`` フィルターが常に ``None`` を返すようにするには、``jinja2_native`` 設定を有効にします。詳細は :ref:`jinja2_faqs` を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1844 -msgid "To extract all occurrences of regex matches in a string, use the ``regex_findall`` filter:" -msgstr "文字列の中にある正規表現の一致のすべての出現箇所を抽出するには、``regex_findall`` フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1857 -msgid "To replace text in a string with regex, use the ``regex_replace`` filter:" -msgstr "文字列のテキストを正規表現に置き換えるには、``regex_replace`` フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1882 -msgid "If you want to match the whole string and you are using ``*`` make sure to always wraparound your regular expression with the start/end anchors. For example ``^(.*)$`` will always match only one result, while ``(.*)`` on some Python versions will match the whole string and an empty string at the end, which means it will make two replacements:" -msgstr "文字列全体に一致させたい場合に ``*`` を使用する場合は、必ず開始/終了アンカーで正規表現を折り返すようにしてください。たとえば、``^(.*)$`` は常に 1 つの結果のみに一致しますが、``(.*)`` はいくつかの Python バージョンでは文字列全体と最後に空の文字列に一致します。つまり 2 つの置換を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1905 -msgid "Prior to ansible 2.0, if ``regex_replace`` filter was used with variables inside YAML arguments (as opposed to simpler 'key=value' arguments), then you needed to escape backreferences (for example, ``\\\\1``) with 4 backslashes (``\\\\\\\\``) instead of 2 (``\\\\``)." -msgstr "ansible 2.0 より前のバージョンでは、(単純な「key=value」引数ではなく) ``regex_replace`` フィルターを YAML 引数内の変数に使用する場合は、後方参照 (たとえば ``\\\\1``) をバックスラッシュ 2 つ (``\\\\``) ではなく 4 つ (``\\\\\\\\``) でエスケープする必要がありました。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1909 -msgid "To escape special characters within a standard Python regex, use the ``regex_escape`` filter (using the default ``re_type='python'`` option):" -msgstr "標準の Python 正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを使用します (デフォルトの ``re_type='python'`` オプションを使用)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1918 -msgid "To escape special characters within a POSIX basic regex, use the ``regex_escape`` filter with the ``re_type='posix_basic'`` option:" -msgstr "POSIX 基本正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを ``re_type='posix_basic'`` オプションを付けて使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1927 -msgid "Managing file names and path names" -msgstr "ファイル名とパス名の管理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1929 -msgid "To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt':" -msgstr "「/etc/asdf/foo.txt」の「foo.txt」のように、ファイルパスの最後の名前を取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1935 -msgid "To get the last name of a windows style file path (new in version 2.0):" -msgstr "ウィンドウスタイルのファイルパスの最後の名前を取得するには、以下を指定します (バージョン 2.0 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1941 -msgid "To separate the windows drive letter from the rest of a file path (new in version 2.0):" -msgstr "Windows ドライブの文字を残りのファイルパスから分離するには、以下を指定します (バージョン 2.0 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1947 -msgid "To get only the windows drive letter:" -msgstr "Windows ドライブの文字のみを取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1953 -msgid "To get the rest of the path without the drive letter:" -msgstr "ドライブ文字なしで残りのパスを取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1959 -msgid "To get the directory from a path:" -msgstr "パスからディレクトリーを取得するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1965 -msgid "To get the directory from a windows path (new version 2.0):" -msgstr "Windows パスからディレクトリーを取得するには、以下を指定します (バージョン 2.0 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1971 -msgid "To expand a path containing a tilde (`~`) character (new in version 1.5):" -msgstr "チルド (`~`) 文字を含むパスを拡張するには、以下を指定します (バージョン 1.5 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1977 -msgid "To expand a path containing environment variables:" -msgstr "環境変数を含むパスを拡張するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1983 -msgid "`expandvars` expands local variables; using it on remote paths can lead to errors." -msgstr "`expandvars` は、ローカル変数を拡張します。リモートパスで使用するとエラーが発生する可能性があります。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1987 -msgid "To get the real path of a link (new in version 1.8):" -msgstr "リンクの実際のパスを取得するには、以下を指定します (バージョン 1.8 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1993 -msgid "To get the relative path of a link, from a start point (new in version 1.7):" -msgstr "リンクの相対パスを取得するには、開始点から以下を行います (バージョン 1.7 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:1999 -msgid "To get the root and extension of a path or file name (new in version 2.0):" -msgstr "パスまたはファイル名のルートおよび拡張を取得するには、以下を指定します (バージョン 2.0 の新機能)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2006 -msgid "The ``splitext`` filter always returns a pair of strings. The individual components can be accessed by using the ``first`` and ``last`` filters:" -msgstr "``splitext`` フィルターは、常に文字列のペアを返します。個々のコンポーネントは、``first`` フィルターおよび ``last`` フィルターを使用してアクセスできます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2016 -msgid "To join one or more path components:" -msgstr "1 つ以上のパスコンポーネントを結合するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2025 -msgid "Manipulating strings" -msgstr "文字列の操作" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2027 -msgid "To add quotes for shell usage:" -msgstr "シェルの使用に引用符を追加するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2034 -msgid "To concatenate a list into a string:" -msgstr "リストを文字列に連結するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2040 -msgid "To split a string into a list:" -msgstr "文字列をリストに分割するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2048 -msgid "To work with Base64 encoded strings:" -msgstr "Base64 でエンコードされた文字列を使用するには、以下を指定します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2055 -msgid "As of version 2.6, you can define the type of encoding to use, the default is ``utf-8``:" -msgstr "バージョン 2.6 以降では、使用するエンコーディングのタイプを定義できます。デフォルトは ``utf-8`` です。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2062 -msgid "The ``string`` filter is only required for Python 2 and ensures that text to encode is a unicode string. Without that filter before b64encode the wrong value will be encoded." -msgstr "``string`` フィルターは Python 2 でのみ必要です。エンコードするテキストがユニコード文字列であることを確認します。b64encode より前のフィルターを使用しないと、誤った値がエンコードされます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2064 -msgid "The return value of b64decode is a string. If you decrypt a binary blob using b64decode and then try to use it (for example by using :ref:`copy ` to write it to a file) you will mostly likely find that your binary has been corrupted. If you need to take a base64 encoded binary and write it to disk, it is best to use the system ``base64`` command with the :ref:`shell module `, piping in the encoded data using the ``stdin`` parameter. For example: ``shell: cmd=\"base64 --decode > myfile.bin\" stdin=\"{{ encoded }}\"``" -msgstr "b64decode の戻り値は文字列です。b64decode を使用してバイナリー BLOB を復号化して使用しようとすると (:ref:`copy ` を使用してファイルに書き込むなど)、ほとんどの場合、バイナリーが破損していることがわかります。base64 でエンコードされたバイナリーを取得してディスクに書き込む必要がある場合は、:ref:`shell module ` でシステムの ``base64`` コマンドを使用し、``stdin`` を使用してエンコードされたデータでのパイプ指定を行うのが最適です (例: ``shell: cmd=\"base64 --decode > myfile.bin\" stdin=\"{{ encoded }}\"``)。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2069 -msgid "Managing UUIDs" -msgstr "UUID の管理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2071 -msgid "To create a namespaced UUIDv5:" -msgstr "namespace を使用した UUIDv5 を作成するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2079 -msgid "To create a namespaced UUIDv5 using the default Ansible namespace '361E6D51-FAEC-444A-9079-341386DA8E2E':" -msgstr "デフォルトの Ansible 名前空間「361E6D51-FAEC-444A-9079-341386DA8E2E2E」を使用して名前空間を指定した UUIDv5 を作成するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2087 -msgid "To make use of one attribute from each item in a list of complex variables, use the :func:`Jinja2 map filter `:" -msgstr "複雑な変数のリストで、各項目から 1 つの属性を使用するには、:func:`Jinja2 map filter ` を使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2095 -msgid "Handling dates and times" -msgstr "日付と時刻の処理" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2097 -msgid "To get a date object from a string use the `to_datetime` filter:" -msgstr "文字列から日付オブジェクトを取得するには、`to_datetime` フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2111 -msgid "For a full list of format codes for working with python date format strings, see the `python datetime documentation `_." -msgstr "Python 日付形式の文字列を使用する形式コードの全一覧は、`python datetime documentation `_ を参照してください。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2115 -msgid "To format a date using a string (like with the shell date command), use the \"strftime\" filter:" -msgstr "文字列 (shell date コマンドの場合のように) を使用して日付をフォーマットするには、「strftime」フィルターを使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2137 -msgid "strftime takes an optional utc argument, defaulting to False, meaning times are in the local timezone:" -msgstr "strftime はオプションの utc 引数を取ります。デフォルトは False で、ローカルタイムゾーンの時間を使用します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2144 -msgid "To get all string possibilities, check https://docs.python.org/3/library/time.html#time.strftime" -msgstr "すべての文字列の可能性を取得するには、https://docs.python.org/3/library/time.html#time.strftime を確認します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2147 -msgid "Getting Kubernetes resource names" -msgstr "Kubernetes リソース名の取得" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2151 -msgid "These filters have migrated to the `kubernetes.core `_ collection. Follow the installation instructions to install that collection." -msgstr "これらのフィルターは `kubernetes.core `_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2153 -msgid "Use the \"k8s_config_resource_name\" filter to obtain the name of a Kubernetes ConfigMap or Secret, including its hash:" -msgstr "「k8s_config_resource_name」フィルターを使用して、Kubernetes ConfigMap または Secret の名前を、そのハッシュを含めて取得します。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2160 -msgid "This can then be used to reference hashes in Pod specifications:" -msgstr "これは、Pod 仕様のハッシュを参照するために使用できます。" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2188 -#: ../../rst/playbook_guide/playbooks_loops.rst:486 -#: ../../rst/playbook_guide/playbooks_strategies.rst:245 -#: ../../rst/playbook_guide/playbooks_variables.rst:517 -msgid ":ref:`about_playbooks`" -msgstr ":ref:`about_playbooks`" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2194 -#: ../../rst/playbook_guide/playbooks_lookups.rst:34 -#: ../../rst/playbook_guide/playbooks_reuse.rst:217 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:604 -#: ../../rst/playbook_guide/playbooks_tests.rst:533 -#: ../../rst/playbook_guide/playbooks_variables.rst:523 -msgid ":ref:`playbooks_loops`" -msgstr ":ref:`playbooks_loops`" - -#: ../../rst/playbook_guide/playbooks_filters.rst:2195 -#: ../../rst/playbook_guide/playbooks_lookups.rst:35 -#: ../../rst/playbook_guide/playbooks_tests.rst:534 -#: ../../rst/playbook_guide/playbooks_variables.rst:524 -msgid "Looping in playbooks" -msgstr "Playbook でのループ" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:4 -msgid "Handlers: running operations on change" -msgstr "ハンドラー: 変更時に実行する操作" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:6 -msgid "Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified." -msgstr "マシンに変更が加えられたときにのみ、タスクを実行したい場合があります。たとえば、タスクがサービスの設定を更新した場合はサービスを再起動し、設定が変更していない場合には再起動しないようにしたい場合があります。Ansible では、このようなユースケースに対応するためにハンドラーを使用しています。ハンドラーは、通知されたときにのみ実行するタスクです。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:12 -msgid "Handler example" -msgstr "ハンドラーの例" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:14 -msgid "This playbook, ``verify-apache.yml``, contains a single play with a handler." -msgstr "この Playbook ``verify-apache.yml`` には、ハンドラーを使用した 1 つのプレイが含まれます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:49 -msgid "In this example playbook, the Apache server is restarted by the handler after all tasks complete in the play." -msgstr "この Playbook の例では、プレイのすべてのタスクが完了した後、Apache サーバーはハンドラーによって再起動されます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:53 -#: ../../rst/playbook_guide/playbooks_reuse.rst:136 -msgid "Notifying handlers" -msgstr "ハンドラーの通知" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:55 -msgid "Tasks can instruct one or more handlers to execute using the ``notify`` keyword. The ``notify`` keyword can be applied to a task and accepts a list of handler names that are notified on a task change. Alternately, a string containing a single handler name can be supplied as well. The following example demonstrates how multiple handlers can be notified by a single task:" -msgstr "タスクは、``notify`` キーワードを使用して実行するハンドラーを 1 つまたは複数指示できます。``notify`` キーワードはタスクに適用され、タスクの変更時に通知されるハンドラー名の一覧を受け入れることができます。あるいは、1 つのハンドラー名が含まれる文字列を指定することもできます。以下の例は、1 つのタスクで複数のハンドラーに通知する方法を示しています。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:79 -msgid "In the above example the handlers are executed on task change in the following order: ``Restart memcached``, ``Restart apache``. Handlers are executed in the order they are defined in the ``handlers`` section, not in the order listed in the ``notify`` statement. Notifying the same handler multiple times will result in executing the handler only once regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts." -msgstr "上記の例では、ハンドラーはタスクの変更時に ``Restart memcached``、``Restart apache`` の順で実行されます。ハンドラーは、``notify`` ステートメントにリストされている順番ではなく、``handlers`` セクションで定義された順序で実行されます。同じハンドラーを複数回指定しても、通知するタスクの数に関係なくハンドラーは 1 回しか実行されません。たとえば、複数のタスクが設定ファイルを更新し、Apache を再起動するようにハンドラーに通知した場合、Ansible は不要な再起動を防ぐために Apache に 1 度だけバウンスします。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:83 -msgid "Naming handlers" -msgstr "ハンドラーの命名" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:85 -msgid "Handlers must be named in order for tasks to be able to notify them using the ``notify`` keyword." -msgstr "タスクが``notify`` キーワードを使用して通知できるように、ハンドラーに名前を付ける必要があります。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:87 -msgid "Alternately, handlers can utilize the ``listen`` keyword. Using this handler keyword, handlers can listen on topics that can group multiple handlers as follows:" -msgstr "あるいは、ハンドラーは ``listen`` キーワードを使用できます。このハンドラーキーワードを使用すると、ハンドラーは以下のように複数のハンドラーをグループ化できるトピックをリッスンできます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:109 -msgid "Notifying the ``restart web services`` topic results in executing all handlers listening to that topic regardless of how those handlers are named." -msgstr "``restart web services`` トピックに通知すると、ハンドラーの名前が何であるかに関わらず、そのトピックをリッスンするすべてのハンドラーが実行されます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:111 -msgid "This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy)." -msgstr "これにより、複数のハンドラーを簡単に発生させることができます。また、ハンドラーを名前から切り離すことで、Playbook やロール間でのハンドラーの共有が容易になります (特に Ansible Galaxy のような共有ソースからサードパーティーのロールを使用する場合)。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:113 -msgid "Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one defined is notified with ``notify``, effectively shadowing all of the previous handlers with the same name. Alternately handlers sharing the same name can all be notified and executed if they listen on the same topic by notifying that topic." -msgstr "各ハンドラーにはグローバルに一意な名前を付ける必要があります。複数のハンドラーが同じ名前で定義されている場合、最後に定義されたハンドラーのみが ``notify`` で通知され、実質的に同じ名前のそれまでのすべてのハンドラーは保護されます。あるいは、同じ名前を共有するハンドラーが同じトピックをリッスンする場合は、そのトピックに通知することですべてのハンドラーが通知され、実行されます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:115 -msgid "There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles." -msgstr "ハンドラーが定義されている場所に関係なく、ハンドラー（ハンドラー名およびリッスントピック）には 1 つのグローバルスコープがあります。これには、ロールで定義されたハンドラーも含まれます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:119 -msgid "Controlling when handlers run" -msgstr "ハンドラーの実行時の制御" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:121 -msgid "By default, handlers run after all the tasks in a particular play have been completed. Notified handlers are executed automatically after each of the following sections, in the following order: ``pre_tasks``, ``roles``/``tasks`` and ``post_tasks``. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts." -msgstr "デフォルトでは、ハンドラーは、特定のプレイのすべてのタスクが完了した後に実行されます。通知されたハンドラーは、``pre_tasks``、``roles``/``tasks``、および ``post_tasks``のセクションの順に自動的に実行されます。ハンドラーは、いくつのタスクが通知したかに関わらず、一度だけ実行するため、このアプローチは効率的です。たとえば、複数のタスクが設定ファイルを更新し、ハンドラーに Apache の再起動を通知した場合、Ansible は Apache に 1 回だけバウンスさせ、不要な再起動を回避します。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:123 -msgid "If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module `, which executes Ansible actions:" -msgstr "プレイの終了前にハンドラーを実行する必要がある場合は、Ansible アクションを実行する :ref:`meta module ` を使用して、タスクをフラッシュします。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:137 -msgid "The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play." -msgstr "``meta: flush_handlers`` タスクは、プレイのその時点で通知されたハンドラーを発生させます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:139 -msgid "Once handlers are executed, either automatically after each mentioned section or manually by the ``flush_handlers`` meta task, they can be notified and run again in later sections of the play." -msgstr "指定された各セクションの後に自動的に、または ``flush_handlers`` メタタスクで手動でハンドラーが実行されると、プレイの後のセクションで再度通知して実行することができます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:143 -msgid "Using variables with handlers" -msgstr "ハンドラーでの変数の使用" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:145 -msgid "You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this:" -msgstr "Ansible ハンドラーで変数を使用したい場合があります。たとえば、サービスの名前がディストリビューションによってわずかに異なる場合に、ターゲットマシンごとに再起動したサービスの正確な名前を出力するとします。ハンドラーの名前に変数を入れないでください。ハンドラー名は初期段階でテンプレート化されているため、Ansible では次のようなハンドラー名に利用できる値がない場合があります。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:153 -msgid "If the variable used in the handler name is not available, the entire play fails. Changing that variable mid-play **will not** result in newly created handler." -msgstr "ハンドラー名で使用される変数が利用できない場合は、プレイ全体が失敗します。変数 mid-play を変更すると、新しく作成されたハンドラーが **作成されません**。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:155 -msgid "Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this:" -msgstr "代わりに、ハンドラーのタスクパラメーターに変数を配置します。以下のように ``include_vars`` を使用して、値を読み込むことができます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:169 -msgid "While handler names can contain a template, ``listen`` topics cannot." -msgstr "ハンドラー名にはテンプレートを含めることができますが、``listen`` トピックにはテンプレートを含めることはできません。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:173 -msgid "Handlers in roles" -msgstr "ロールのハンドラー" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:175 -msgid "Handlers from roles are not just contained in their roles but rather inserted into global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``." -msgstr "ロールからのハンドラーはそのロール内に含まれるだけでなく、プレイからの他のすべてのハンドラーと共にグローバルスコープに挿入されます。したがって、ハンドラーは定義されたロール外で使用できます。また、ハンドラーの名前がロール外からのハンドラーと競合する可能性があることも意味します。同じ名前を持つロール外からのハンドラーではなく、ロールからのハンドラーが通知されるようにするには、``role_name : handler_name`` のフォームで名前を使用してハンドラーに通知します。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:177 -msgid "Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section, but before any ``tasks`` handlers." -msgstr "``roles``セクション内で通知されるハンドラーは、``tasks`` セクションの最後に、ただし ``tasks`` ハンドラーの前に自動的にフラッシュされます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:181 -msgid "Includes and imports in handlers" -msgstr "ハンドラーのインクルードおよびインポート" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:182 -msgid "Notifying a dynamic include such as ``include_task`` as a handler results in executing all tasks from within the include. It is not possible to notify a handler defined inside a dynamic include." -msgstr "ハンドラーとして ``include_task`` などの動的インクルードに通知すると、インクルード内からのすべてのタスクが実行されます。動的インクルード内で定義されたハンドラーに通知することはできません。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:184 -msgid "Having a static include such as ``import_task`` as a handler results in that handler being effectively rewritten by handlers from within that import before the play execution. A static include itself cannot be notified; the tasks from within that include, on the other hand, can be notified individually." -msgstr "ハンドラーとして ``import_task`` などの静的インクルードを指定すると、実質的にそのハンドラーはプレイの実行前にそのインポート内からのハンドラーにより書き換えられます。静インクルード自体には通知できず、一方、そのインクルード内からのタスクには個別に通知できます。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:188 -msgid "Meta tasks as handlers" -msgstr "ハンドラーとしてのメタタスク" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:190 -msgid "Since Ansible 2.14 :ref:`meta tasks ` are allowed to be used and notified as handlers. Note that however ``flush_handlers`` cannot be used as a handler to prevent unexpected behavior." -msgstr "Ansible 2.14 以降は、:ref:`meta tasks ` をハンドラーとして使用して、通知できます。ただし、``flush_handlers`` は、予期しない動作を回避するためにハンドラーとして使用できません。" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:194 -msgid "Limitations" -msgstr "制限事項" - -#: ../../rst/playbook_guide/playbooks_handlers.rst:196 -msgid "A handler cannot run ``import_role`` or ``include_role``." -msgstr "ハンドラーは ``import_role`` または ``include_role`` を実行できません。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:6 -msgid "Ansible playbooks" -msgstr "Ansible Playbook" - -#: ../../rst/playbook_guide/playbooks_intro.rst:8 -msgid "Ansible Playbooks offer a repeatable, re-usable, simple configuration management and multi-machine deployment system, one that is well suited to deploying complex applications. If you need to execute a task with Ansible more than once, write a playbook and put it under source control. Then you can use the playbook to push out new configuration or confirm the configuration of remote systems. The playbooks in the `ansible-examples repository `_ illustrate many useful techniques. You may want to look at these in another tab as you read the documentation." -msgstr "Ansible Playbook は、繰り返し使用可能で、再利用可能なシンプルな構成管理および複数マシンのデプロイメントシステムであり、複雑なアプリケーションのデプロイメントに適しています。Ansible で複数回タスクを実行する必要がある場合は、Playbook を作成してソースコントロール下に置きます。その後、Playbook を使用して、新しい設定をプッシュアウトしたり、リモートシステムの設定を確認したりすることができます。`ansible-examples リポジトリー `_ の Playbook には、多くの便利なテクニックが紹介されています。ドキュメントを読みながら、これらを別のタブで見てみるのもいいかもしれません。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:10 -msgid "Playbooks can:" -msgstr "Playbook は、以下のことができます。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:12 -msgid "declare configurations" -msgstr "宣言設定" - -#: ../../rst/playbook_guide/playbooks_intro.rst:13 -msgid "orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order" -msgstr "複数のマシンセットで、手動で順序付けされたプロセスの手順を定義された順序で編成します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:14 -msgid "launch tasks synchronously or :ref:`asynchronously `" -msgstr "タスクを同期または :ref:`非同期 ` で起動" - -#: ../../rst/playbook_guide/playbooks_intro.rst:22 -msgid "Playbook syntax" -msgstr "Playbook 構文" - -#: ../../rst/playbook_guide/playbooks_intro.rst:24 -msgid "Playbooks are expressed in YAML format with a minimum of syntax. If you are not familiar with YAML, look at our overview of :ref:`yaml_syntax` and consider installing an add-on for your text editor (see :ref:`other_tools_and_programs`) to help you write clean YAML syntax in your playbooks." -msgstr "Playbook は最小限の構文で YAML 形式で表現されます。YAML に慣れていない方は、:ref:`yaml_syntax` の概要を参照してください。また、Playbook にきれいな YAML 構文を書くために、テキストエディター用のアドオンのインストールを検討してください (「:ref:`other_tools_and_programs`」を参照)。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:26 -msgid "A playbook is composed of one or more 'plays' in an ordered list. The terms 'playbook' and 'play' are sports analogies. Each play executes part of the overall goal of the playbook, running one or more tasks. Each task calls an Ansible module." -msgstr "Playbook は、1 つまたは複数の「プレイ」を順番に並べたものです。「Playbook」と「プレイ」という言葉は、スポーツに例えられています。各プレイは、Playbook の全体的な目標の一部を実行し、1 つまたは複数のタスクを実行します。各タスクは、Ansible モジュールを呼び出します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:29 -msgid "Playbook execution" -msgstr "Playbook 実行" - -#: ../../rst/playbook_guide/playbooks_intro.rst:31 -msgid "A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple 'plays' can orchestrate multi-machine deployments, running one play on your webservers, then another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things:" -msgstr "Playbook は、上から下に向かって順番に実行されます。各プレイの中では、タスクも上から下の順に実行されます。複数の「プレイ」を持つ Playbook では、複数のマシンのデプロイメントを編成することができます。あるプレイを Web サーバーで実行した後、別のプレイをデータベースサーバーで実行し、さらに 3 つ目のプレイをネットワークインフラストラクチャーで実行するといった具合です。最低限、各プレイは 2 つのことを定義します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:33 -msgid "the managed nodes to target, using a :ref:`pattern `" -msgstr ":ref:`pattern ` を使用する管理ノードが対象である" - -#: ../../rst/playbook_guide/playbooks_intro.rst:34 -msgid "at least one task to execute" -msgstr "実行すべき 1 つ以上のタスク" - -#: ../../rst/playbook_guide/playbooks_intro.rst:38 -msgid "In Ansible 2.10 and later, we recommend you use the fully-qualified collection name in your playbooks to ensure the correct module is selected, because multiple collections can contain modules with the same name (for example, ``user``). See :ref:`collections_using_playbook`." -msgstr "Ansible 2.10 以降では、複数のコレクションに同じ名前のモジュールが含まれていることがあるため (例: ``user``)、正しいモジュールが選択されるように、Playbook で完全修飾コレクション名を使用することが推奨されます。「:ref:`collections_using_playbook`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:40 -msgid "In this example, the first play targets the web servers; the second play targets the database servers." -msgstr "この例では、第 1 のプレイは Web サーバーを対象とし、第 2 のプレイはデータベースサーバーを対象としています。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:73 -msgid "Your playbook can include more than just a hosts line and tasks. For example, the playbook above sets a ``remote_user`` for each play. This is the user account for the SSH connection. You can add other :ref:`playbook_keywords` at the playbook, play, or task level to influence how Ansible behaves. Playbook keywords can control the :ref:`connection plugin `, whether to use :ref:`privilege escalation `, how to handle errors, and more. To support a variety of environments, Ansible lets you set many of these parameters as command-line flags, in your Ansible configuration, or in your inventory. Learning the :ref:`precedence rules ` for these sources of data will help you as you expand your Ansible ecosystem." -msgstr "Playbook には、ホストラインとタスク以外の情報も含めることができます。たとえば、上記の Playbook では、各プレイに ``remote_user`` を設定しています。これは、SSH 接続用のユーザーアカウントです。Playbook、プレイ、またはタスクレベルで他の :ref:`playbook_keywords` を追加して、Ansible の動作に影響を与えることができます。Playbook のキーワードでは、:ref:`connection プラグイン ` で、:ref:`特権昇格 ` を使用するかどうか、エラーをどのように処理するかなどを制御できます。さまざまな環境に対応するため、Ansible では、これらのパラメーターの多くをコマンドラインフラグ、Ansible の構成、またはインベントリーで設定することができます。これらのデータソースの :ref:`優先順位のルール ` を学ぶことは、Ansible のエコシステムを拡張する際に役立ちます。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:78 -msgid "Task execution" -msgstr "タスクの実行" - -#: ../../rst/playbook_guide/playbooks_intro.rst:80 -msgid "By default, Ansible executes each task in order, one at a time, against all machines matched by the host pattern. Each task executes a module with specific arguments. When a task has executed on all target machines, Ansible moves on to the next task. You can use :ref:`strategies ` to change this default behavior. Within each play, Ansible applies the same task directives to all hosts. If a task fails on a host, Ansible takes that host out of the rotation for the rest of the playbook." -msgstr "デフォルトでは、Ansible は、ホストパターンに一致するすべてのマシンに対して、各タスクを 1 つずつ順番に実行します。各タスクは、特定の引数を持つモジュールを実行します。タスクがすべてのターゲットマシンで実行すると、Ansible は次のタスクに移ります。このデフォルトの動作を変更するには、:ref:`ストラテジー ` を使用します。各プレイの中で、Ansible は同じタスクディレクティブをすべてのホストに適用します。あるホストでタスクが失敗した場合、Ansible はそのホストを Playbook の残りの部分のローテーションから外します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:82 -msgid "When you run a playbook, Ansible returns information about connections, the ``name`` lines of all your plays and tasks, whether each task has succeeded or failed on each machine, and whether each task has made a change on each machine. At the bottom of the playbook execution, Ansible provides a summary of the nodes that were targeted and how they performed. General failures and fatal \"unreachable\" communication attempts are kept separate in the counts." -msgstr "Playbook を実行すると、Ansible は接続に関する情報、すべてのプレイとタスクの ``name`` 行、各タスクが各マシンで成功したか失敗したか、および各タスクが各マシンで変更を行ったかどうかを返します。Playbook の実行の最後に、Ansible は、対象となったノードとそのパフォーマンスの概要を表示します。一般的な失敗と致命的な「到達不能」の通信試行は、カウントの中で分けて表示されます。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:87 -msgid "Desired state and 'idempotency'" -msgstr "希望の状態および「冪等性」" - -#: ../../rst/playbook_guide/playbooks_intro.rst:89 -msgid "Most Ansible modules check whether the desired final state has already been achieved, and exit without performing any actions if that state has been achieved, so that repeating the task does not change the final state. Modules that behave this way are often called 'idempotent.' Whether you run a playbook once, or multiple times, the outcome should be the same. However, not all playbooks and not all modules behave this way. If you are unsure, test your playbooks in a sandbox environment before running them multiple times in production." -msgstr "ほとんどの Ansible モジュールは、目的の最終状態がすでに達成されているかどうかを確認し、その状態が達成されている場合は何も実行せずに終了するため、タスクを繰り返しても最終状態は変わりません。このような動作をするモジュールは、しばしば「冪等性」と呼ばれます。Playbook を 1 回だけ実行しても、複数回実行しても、結果は同じになるはずです。しかし、すべての Playbook やすべてのモジュールがこのように動作するわけではありません。不安な場合は、実稼働環境で Playbook を複数回実行する前に、サンドボックス環境で Playbook をテストしてください。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:94 -msgid "Running playbooks" -msgstr "Playbook の実行" - -#: ../../rst/playbook_guide/playbooks_intro.rst:96 -msgid "To run your playbook, use the :ref:`ansible-playbook` command." -msgstr "Playbook を実行するには、:ref:`ansible-playbook` コマンドを使用します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:102 -msgid "Use the ``--verbose`` flag when running your playbook to see detailed output from successful modules as well as unsuccessful ones." -msgstr "成功したモジュールと失敗したモジュールの詳細な出力を確認するには、Playbook の実行時に ``--verbose`` フラグを使用します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:107 -msgid "Ansible-Pull" -msgstr "ansible-pull" - -#: ../../rst/playbook_guide/playbooks_intro.rst:109 -msgid "Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead of pushing configuration out to them, you can." -msgstr "ノードに設定をプッシュするのではなく、Ansible のアーキテクチャーを逆にして、ノードが中央の場所にチェックインするようにしたい場合は、以下を行うことができます。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:112 -msgid "The ``ansible-pull`` is a small script that will checkout a repo of configuration instructions from git, and then run ``ansible-playbook`` against that content." -msgstr "``ansible-pull`` は小さなスクリプトで、git から設定方法をまとめたリポジトリーをチェックアウトし、その内容に対して ``ansible-playbook`` を実行します。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:115 -msgid "Assuming you load balance your checkout location, ``ansible-pull`` scales essentially infinitely." -msgstr "チェックアウトの場所を負荷分散する場合、``ansible-pull`` は基本的に無限にスケーリングを行います。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:117 -msgid "Run ``ansible-pull --help`` for details." -msgstr "詳細は、「``ansible-pull --help``」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:119 -msgid "There's also a `clever playbook `_ available to configure ``ansible-pull`` through a crontab from push mode." -msgstr "また、プッシュモードからの crontab で ``ansible-pull`` を設定する際に利用可能な `clever playbook `_ もあります。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:122 -msgid "Verifying playbooks" -msgstr "Playbook の検証" - -#: ../../rst/playbook_guide/playbooks_intro.rst:124 -msgid "You may want to verify your playbooks to catch syntax errors and other problems before you run them. The :ref:`ansible-playbook` command offers several options for verification, including ``--check``, ``--diff``, ``--list-hosts``, ``--list-tasks``, and ``--syntax-check``. The :ref:`validate-playbook-tools` describes other tools for validating and testing playbooks." -msgstr "Playbook を実行する前に、構文エラーやその他の問題を検出するために、Playbook を検証したい場合があります。:ref:`ansible-playbook` コマンドには、``--check``、``--diff``、``--list-hosts``、``--list-tasks``、``--syntax-check`` など、検証のためのオプションが用意されています。「:ref:`validate-playbook-tools`」では、Playbook の検証とテストのための他のツールについて説明しています。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:129 -msgid "ansible-lint" -msgstr "ansible-lint" - -#: ../../rst/playbook_guide/playbooks_intro.rst:131 -msgid "You can use `ansible-lint `_ for detailed, Ansible-specific feedback on your playbooks before you execute them. For example, if you run ``ansible-lint`` on the playbook called ``verify-apache.yml`` near the top of this page, you should get the following results:" -msgstr "`ansible-lint `_ を使用すると、Playbook を実行する前に、Playbook に対する Ansible 固有の詳細なフィードバックを得ることができます。たとえば、このページの上位にある ``verify-apache.yml`` という Playbook に対して ``ansible-lint`` を実行すると、以下のような結果が得られます。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:140 -msgid "The `ansible-lint default rules `_ page describes each error. For ``[403]``, the recommended fix is to change ``state: latest`` to ``state: present`` in the playbook." -msgstr "`ansible-lint デフォルトルール `_ ページには、各エラーについて説明しています。``[403]`` については、Playbook で ``state: latest`` を ``state: present`` に変更することが推奨されます。" - -#: ../../rst/playbook_guide/playbooks_intro.rst:144 -msgid "`ansible-lint `_" -msgstr "`ansible-lint `_" - -#: ../../rst/playbook_guide/playbooks_intro.rst:145 -msgid "Learn how to test Ansible Playbooks syntax" -msgstr "Ansible Playbook 構文のテスト方法について" - -#: ../../rst/playbook_guide/playbooks_intro.rst:146 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:594 -msgid ":ref:`yaml_syntax`" -msgstr ":ref:`yaml_syntax`" - -#: ../../rst/playbook_guide/playbooks_intro.rst:147 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:595 -msgid "Learn about YAML syntax" -msgstr "YAML 構文について" - -#: ../../rst/playbook_guide/playbooks_intro.rst:149 -msgid "Tips for managing playbooks in the real world" -msgstr "実際の Playbook の管理に関するさまざまなヒント" - -#: ../../rst/playbook_guide/playbooks_intro.rst:150 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:608 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/playbook_guide/playbooks_intro.rst:151 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:609 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/playbook_guide/playbooks_intro.rst:152 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:610 -msgid ":ref:`developing_modules`" -msgstr ":ref:`developing_modules`" - -#: ../../rst/playbook_guide/playbooks_intro.rst:153 -msgid "Learn to extend Ansible by writing your own modules" -msgstr "独自のモジュールを作成して Ansible を拡張する方法について" - -#: ../../rst/playbook_guide/playbooks_intro.rst:154 -msgid ":ref:`intro_patterns`" -msgstr ":ref:`intro_patterns`" - -#: ../../rst/playbook_guide/playbooks_intro.rst:155 -msgid "Learn about how to select hosts" -msgstr "ホストの選択方法について" - -#: ../../rst/playbook_guide/playbooks_intro.rst:156 -msgid "`GitHub examples directory `_" -msgstr "`GitHub examples directory `_" - -#: ../../rst/playbook_guide/playbooks_intro.rst:157 -msgid "Complete end-to-end playbook examples" -msgstr "完全なエンドツーエンド Playbook の例" - -#: ../../rst/playbook_guide/playbooks_intro.rst:158 -#: ../../rst/playbook_guide/playbooks_reuse.rst:225 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:614 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/playbook_guide/playbooks_intro.rst:159 -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:774 -#: ../../rst/playbook_guide/playbooks_reuse.rst:226 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:615 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/playbook_guide/playbooks_lookups.rst:5 -msgid "Lookups" -msgstr "ルックアップ (lookup)" - -#: ../../rst/playbook_guide/playbooks_lookups.rst:7 -msgid "Lookup plugins retrieve data from outside sources such as files, databases, key/value stores, APIs, and other services. Like all templating, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. Before Ansible 2.5, lookups were mostly used indirectly in ``with_`` constructs for looping. Starting with Ansible 2.5, lookups are used more explicitly as part of Jinja2 expressions fed into the ``loop`` keyword." -msgstr "lookup プラグインは、ファイル、データベース、キー/値ストア、API、その他のサービスなどの外部ソースからデータを取得します。すべてのテンプレート化と同様に、lookup は Ansible のコントロールマシン上で実行され、評価されます。Ansible では、lookup プラグインが返すデータを、標準のテンプレートシステムを使用して利用できるようにします。Ansible 2.5 以前、lookup はほとんどの場合、``with_`` のループのための構成で間接的に使用されていました。Ansible 2.5 以降、lookup は Jinja2 の式の一部として、より明示的に使用されるようになり、``loop`` キーワードに供給されるようになりました。" - -#: ../../rst/playbook_guide/playbooks_lookups.rst:12 -msgid "Using lookups in variables" -msgstr "変数での lookup の使用" - -#: ../../rst/playbook_guide/playbooks_lookups.rst:14 -msgid "You can populate variables using lookups. Ansible evaluates the value each time it is executed in a task (or template)." -msgstr "lookup を使用して変数を設定することができます。Ansible は、タスク (またはテンプレート) で実行されるたびに値を評価します。" - -#: ../../rst/playbook_guide/playbooks_lookups.rst:24 -msgid "For more details and a list of lookup plugins in ansible-core, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``." -msgstr "ansible-core の lookup プラグインの詳細と一覧は、「:ref:`plugins_lookup`」を参照してください。また、lookup プラグインはコレクションにも含まれています。コントロールマシンにインストールされている lookup プラグインのリストは、``ansible-doc -l -t lookup`` コマンドで確認できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:5 -msgid "Loops" -msgstr "ループ" - -#: ../../rst/playbook_guide/playbooks_loops.rst:7 -msgid "Ansible offers the ``loop``, ``with_``, and ``until`` keywords to execute a task multiple times. Examples of commonly-used loops include changing ownership on several files and/or directories with the :ref:`file module `, creating multiple users with the :ref:`user module `, and repeating a polling step until a certain result is reached." -msgstr "Ansible には、``loop``、``with_``、および ``until`` というキーワードがあり、1 つのタスクを複数回実行することができます。一般的に使用されるループの例としては、:ref:`file module ` で複数のファイルやディレクトリーの所有権を変更する、:ref:`user module ` で複数のユーザーを作成する、特定の結果が得られるまでポーリングステップを繰り返すなどがあります。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:11 -msgid "We added ``loop`` in Ansible 2.5. It is not yet a full replacement for ``with_``, but we recommend it for most use cases." -msgstr "Ansible 2.5 で ``loop`` を追加しました。``with_`` は完全に置き換えるものではありませんが、ほとんどのユースケースで推奨されています。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:12 -msgid "We have not deprecated the use of ``with_`` - that syntax will still be valid for the foreseeable future." -msgstr "``with_`` の使用は非推奨になっていません。この構文は、今後も有効です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:13 -msgid "We are looking to improve ``loop`` syntax - watch this page and the `changelog `_ for updates." -msgstr "``loop`` 構文を改善する場合は、このページと `changelog `_ で更新を確認します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:19 -msgid "Comparing ``loop`` and ``with_*``" -msgstr "``loop`` と ``with_*`` の比較" - -#: ../../rst/playbook_guide/playbooks_loops.rst:21 -msgid "The ``with_`` keywords rely on :ref:`lookup_plugins` - even ``items`` is a lookup." -msgstr "``with_`` キーワードは :ref:`lookup_plugins` に依存し、``items`` も lookup となります。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:22 -msgid "The ``loop`` keyword is equivalent to ``with_list``, and is the best choice for simple loops." -msgstr "``loop`` キーワードは ``with_list`` と同等であり、単純なループに最適です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:23 -msgid "The ``loop`` keyword will not accept a string as input, see :ref:`query_vs_lookup`." -msgstr "``loop`` キーワードは文字列を入力として受け付けません。「:ref:`query_vs_lookup`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:24 -msgid "Generally speaking, any use of ``with_*`` covered in :ref:`migrating_to_loop` can be updated to use ``loop``." -msgstr "通常、「:ref:`migrating_to_loop`」で対応している ``with_*`` を使用すると、``loop`` を使用するように更新できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:25 -msgid "Be careful when changing ``with_items`` to ``loop``, as ``with_items`` performed implicit single-level flattening. You may need to use ``flatten(1)`` with ``loop`` to match the exact outcome. For example, to get the same output as:" -msgstr "``with_items`` を ``loop`` に変更する際には、``with_items`` が暗黙の単一レベルのフラット化を行うため注意が必要です。正確な結果を得るためには、``flatten(1)`` と ``loop`` の併用が必要になる可能性があります。たとえば、次と同じ出力を得るには、" - -#: ../../rst/playbook_guide/playbooks_loops.rst:34 -msgid "you would need" -msgstr "以下が必要です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:40 -msgid "Any ``with_*`` statement that requires using ``lookup`` within a loop should not be converted to use the ``loop`` keyword. For example, instead of doing:" -msgstr "ループ内で ``lookup`` を使用する必要のある ``with_*`` 文は、``loop`` キーワードを使用するように変換しないでください。たとえば、代わりに、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:46 -msgid "it's cleaner to keep" -msgstr "保持する方が見た目がすっきりします。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:55 -msgid "Standard loops" -msgstr "標準ループ" - -#: ../../rst/playbook_guide/playbooks_loops.rst:58 -msgid "Iterating over a simple list" -msgstr "シンプルなリストでの反復" - -#: ../../rst/playbook_guide/playbooks_loops.rst:60 -msgid "Repeated tasks can be written as standard loops over a simple list of strings. You can define the list directly in the task." -msgstr "繰り返されるタスクは、文字列の単純なリストに対する標準的なループとして記述できます。このリストはタスクの中で直接定義できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:73 -msgid "You can define the list in a variables file, or in the 'vars' section of your play, then refer to the name of the list in the task." -msgstr "変数ファイルでリストを定義するか、プレイの「vars」セクションで、タスク内のリストの名前を参照します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:79 -msgid "Either of these examples would be the equivalent of" -msgstr "これらの例のいずれも、以下と同等です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:95 -msgid "You can pass a list directly to a parameter for some plugins. Most of the packaging modules, like :ref:`yum ` and :ref:`apt `, have this capability. When available, passing the list to a parameter is better than looping over the task. For example" -msgstr "いくつかのプラグインでは、パラメーターにリストを直接渡すことができます。:ref:`yum ` や :ref:`apt ` など、ほとんどのパッケージングモジュールにこの機能があります。利用できる場合は、リストをパラメーターに渡す方が、タスクをループさせるよりも良いでしょう。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:110 -msgid "Check the :ref:`module documentation ` to see if you can pass a list to any particular module's parameter(s)." -msgstr ":ref:`モジュールのドキュメント ` で、特定モジュールのパラメーターにリストを渡すことができるかどうかを確認します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:113 -msgid "Iterating over a list of hashes" -msgstr "ハッシュリストでの反復" - -#: ../../rst/playbook_guide/playbooks_loops.rst:115 -msgid "If you have a list of hashes, you can reference subkeys in a loop. For example:" -msgstr "ハッシュリストがある場合は、ループでサブキーを参照できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:128 -msgid "When combining :ref:`conditionals ` with a loop, the ``when:`` statement is processed separately for each item. See :ref:`the_when_statement` for examples." -msgstr ":ref:`conditionals ` とループを組み合わせると、``when:`` 文は各項目について個別に処理されます。例は「:ref:`the_when_statement`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:132 -msgid "Iterating over a dictionary" -msgstr "ディクショナリーでの反復" - -#: ../../rst/playbook_guide/playbooks_loops.rst:134 -msgid "To loop over a dict, use the :ref:`dict2items `:" -msgstr "ディクショナリーでループするには、:ref:`dict2items ` を使用します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:147 -msgid "Here, we are iterating over `tag_data` and printing the key and the value from it." -msgstr "ここでは、`tag_data` を繰り返し処理し、キーと値を出力します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:150 -msgid "Registering variables with a loop" -msgstr "ループによる変数の登録" - -#: ../../rst/playbook_guide/playbooks_loops.rst:152 -msgid "You can register the output of a loop as a variable. For example" -msgstr "ループの出力を変数として登録できます。たとえば、次のようになります。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:163 -msgid "When you use ``register`` with a loop, the data structure placed in the variable will contain a ``results`` attribute that is a list of all responses from the module. This differs from the data structure returned when using ``register`` without a loop." -msgstr "``register`` をループで使用すると、変数に配置されるデータ構造には、モジュールからのすべての応答のリストである ``results`` 属性が含まれます。これは、``register`` をループなしで使用したときに返されるデータ構造とは異なります。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:204 -msgid "Subsequent loops over the registered variable to inspect the results may look like" -msgstr "登録済みの変数で後続のループを実行して結果を検査すると、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:214 -msgid "During iteration, the result of the current item will be placed in the variable." -msgstr "反復時に、現在の項目の結果は変数に配置されます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:229 -msgid "Complex loops" -msgstr "複雑なループ" - -#: ../../rst/playbook_guide/playbooks_loops.rst:232 -msgid "Iterating over nested lists" -msgstr "入れ子のリストでの反復" - -#: ../../rst/playbook_guide/playbooks_loops.rst:234 -msgid "You can use Jinja2 expressions to iterate over complex lists. For example, a loop can combine nested lists." -msgstr "Jinja2 の式を使用して、複雑なリストを繰り返し処理することができます。たとえば、ループは入れ子になったリストを組み合わせることができます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:250 -msgid "Retrying a task until a condition is met" -msgstr "条件が満たされるまでタスクの再試行" - -#: ../../rst/playbook_guide/playbooks_loops.rst:254 -msgid "You can use the ``until`` keyword to retry a task until a certain condition is met. Here's an example:" -msgstr "``until`` キーワードを使用すると、ある条件が満たされるまでタスクを再試行することができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:265 -msgid "This task runs up to 5 times with a delay of 10 seconds between each attempt. If the result of any attempt has \"all systems go\" in its stdout, the task succeeds. The default value for \"retries\" is 3 and \"delay\" is 5." -msgstr "このタスクは、各試行の間に 10 秒の遅延を置いて最大 5 回実行される。試行の結果、標準出力に「all systems go」と表示されていれば、タスクは成功です。「retries (再試行)」のデフォルト値は 3、「delay (遅延)」は 5 です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:267 -msgid "To see the results of individual retries, run the play with ``-vv``." -msgstr "個別の再試行の結果を表示するには、``-vv`` でプレイを実行します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:269 -msgid "When you run a task with ``until`` and register the result as a variable, the registered variable will include a key called \"attempts\", which records the number of the retries for the task." -msgstr "``until`` を使用してタスクを実行し、結果を変数として登録する場合は、登録済み変数には「attempts」と呼ばれる鍵が含まれ、タスクの再試行回数を記録します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:271 -msgid "You must set the ``until`` parameter if you want a task to retry. If ``until`` is not defined, the value for the ``retries`` parameter is forced to 1." -msgstr "タスクが再試行するには、``until`` パラメーターを設定する必要があります。``until`` が定義されていない場合は、``retries`` パラメーターの値が 1 に強制されます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:274 -msgid "Looping over inventory" -msgstr "インベントリーのループ" - -#: ../../rst/playbook_guide/playbooks_loops.rst:276 -msgid "To loop over your inventory, or just a subset of it, you can use a regular ``loop`` with the ``ansible_play_batch`` or ``groups`` variables." -msgstr "インベントリーやその一部だけをループさせるには、通常の ``loop`` に ``ansible_play_batch`` 変数や ``groups`` 変数を加えたものを使用することができます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:290 -msgid "There is also a specific lookup plugin ``inventory_hostnames`` that can be used like this" -msgstr "また、以下のような特定の lookup プラグイン ``inventory_hostnames`` も使用できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:304 -msgid "More information on the patterns can be found in :ref:`intro_patterns`." -msgstr "パターンの詳細は、「:ref:`intro_patterns`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:309 -msgid "Ensuring list input for ``loop``: using ``query`` rather than ``lookup``" -msgstr "``loop`` のリスト入力の確保: ``lookup`` の代わりに ``query`` を使用" - -#: ../../rst/playbook_guide/playbooks_loops.rst:311 -msgid "The ``loop`` keyword requires a list as input, but the ``lookup`` keyword returns a string of comma-separated values by default. Ansible 2.5 introduced a new Jinja2 function named :ref:`query ` that always returns a list, offering a simpler interface and more predictable output from lookup plugins when using the ``loop`` keyword." -msgstr "``loop`` キーワードは入力としてリストを必要としますが、``lookup`` キーワードはデフォルトでコンマで区切られた値の文字列を返すようになっています。Ansible 2.5 では、:ref:`query ` という名前の新しい Jinja2 関数が導入され、常にリストを返すようになりました。これにより、インターフェースがシンプルになり、``loop`` キーワードを使用した場合の lookup プラグインの出力がより予測しやすくなりました。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:313 -msgid "You can force ``lookup`` to return a list to ``loop`` by using ``wantlist=True``, or you can use ``query`` instead." -msgstr "``wantlist=True`` を使用すれば、``lookup`` がリストを ``loop`` に返すように強制したり、代わりに ``query`` を使用することもできます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:315 -msgid "The following two examples do the same thing." -msgstr "以下の2つの例は、同じことをします。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:327 -msgid "Adding controls to loops" -msgstr "ループへのコントロールの追加" - -#: ../../rst/playbook_guide/playbooks_loops.rst:330 -msgid "The ``loop_control`` keyword lets you manage your loops in useful ways." -msgstr "``loop_control`` キーワードを使用すると、ループを便利な方法で管理できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:333 -msgid "Limiting loop output with ``label``" -msgstr "``label`` を使用したループ出力の制限" - -#: ../../rst/playbook_guide/playbooks_loops.rst:336 -msgid "When looping over complex data structures, the console output of your task can be enormous. To limit the displayed output, use the ``label`` directive with ``loop_control``." -msgstr "複雑なデータ構造をループしていると、タスクのコンソール出力が膨大になることがあります。表示される出力を制限するには、``label`` ディレクティブと ``loop_control`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:355 -msgid "The output of this task will display just the ``name`` field for each ``item`` instead of the entire contents of the multi-line ``{{ item }}`` variable." -msgstr "このタスクの出力には、複数行の ``{{ item }}`` 変数の内容全体ではなく、各 ``item`` の ``name`` フィールドのみが表示されます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:357 -msgid "This is for making console output more readable, not protecting sensitive data. If there is sensitive data in ``loop``, set ``no_log: yes`` on the task to prevent disclosure." -msgstr "これはコンソール出力を読みやすくするためのもので、機密データを保護するものではありません。``loop`` に機密データがある場合は、``no_log: yes`` をタスクに設定して漏洩を防ぎます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:360 -msgid "Pausing within a loop" -msgstr "ループ内での一時停止" - -#: ../../rst/playbook_guide/playbooks_loops.rst:363 -msgid "To control the time (in seconds) between the execution of each item in a task loop, use the ``pause`` directive with ``loop_control``." -msgstr "タスクループの各項目の実行間隔を (秒単位) で制御するには、``pause`` で ``loop_control`` ディレクティブを使用します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:379 -msgid "Tracking progress through a loop with ``index_var``" -msgstr "``index_var`` のあるループでの進捗の追跡" - -#: ../../rst/playbook_guide/playbooks_loops.rst:382 -msgid "To keep track of where you are in a loop, use the ``index_var`` directive with ``loop_control``. This directive specifies a variable name to contain the current loop index." -msgstr "ループ内のどこにいるかを把握するには、``loop_control`` とともに ``index_var`` ディレクティブを使用します。このディレクティブは、現在のループのインデックスを格納する変数名を指定します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:396 -msgid "`index_var` is 0 indexed." -msgstr "`index_var` は、0 インデックスです。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:399 -msgid "Defining inner and outer variable names with ``loop_var``" -msgstr "``loop_var`` を使用した内部変数名および外部変数名の定義" - -#: ../../rst/playbook_guide/playbooks_loops.rst:402 -msgid "You can nest two looping tasks using ``include_tasks``. However, by default Ansible sets the loop variable ``item`` for each loop. This means the inner, nested loop will overwrite the value of ``item`` from the outer loop. You can specify the name of the variable for each loop using ``loop_var`` with ``loop_control``." -msgstr "``include_tasks`` を使用すると、2 つのループタスクを入れ子にすることができます。ただし、Ansible のデフォルトでは、ループごとにループ変数 ``item`` が設定されます。これは、入れ子になった内側のループが、外側のループの ``item`` の値を上書きすることを意味します。``loop_var`` と ``loop_control`` を使用して、各ループの変数名を指定することができます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:425 -msgid "If Ansible detects that the current loop is using a variable which has already been defined, it will raise an error to fail the task." -msgstr "定義されている変数を現在のループが使用していることを Ansible が検出すると、タスクが失敗するためにエラーが発生します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:428 -msgid "Extended loop variables" -msgstr "拡張ループ変数" - -#: ../../rst/playbook_guide/playbooks_loops.rst:431 -msgid "As of Ansible 2.8 you can get extended loop information using the ``extended`` option to loop control. This option will expose the following information." -msgstr "Ansible 2.8 では、ループ制御に ``extended`` オプションを使用することで、拡張されたループ情報を得ることができます。このオプションは、以下の情報を公開します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:434 -msgid "Variable" -msgstr "変数" - -#: ../../rst/playbook_guide/playbooks_loops.rst:434 -#: ../../rst/playbook_guide/playbooks_variables.rst:110 -msgid "Description" -msgstr "説明" - -#: ../../rst/playbook_guide/playbooks_loops.rst:436 -msgid "``ansible_loop.allitems``" -msgstr "``ansible_loop.allitems``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:436 -msgid "The list of all items in the loop" -msgstr "ループ内のすべての項目のリスト" - -#: ../../rst/playbook_guide/playbooks_loops.rst:437 -msgid "``ansible_loop.index``" -msgstr "``ansible_loop.index``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:437 -msgid "The current iteration of the loop. (1 indexed)" -msgstr "ループの現在の反復 (1 インデックス化)" - -#: ../../rst/playbook_guide/playbooks_loops.rst:438 -msgid "``ansible_loop.index0``" -msgstr "``ansible_loop.index0``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:438 -msgid "The current iteration of the loop. (0 indexed)" -msgstr "ループの現在の反復 (0 インデックス化)" - -#: ../../rst/playbook_guide/playbooks_loops.rst:439 -msgid "``ansible_loop.revindex``" -msgstr "``ansible_loop.revindex``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:439 -msgid "The number of iterations from the end of the loop (1 indexed)" -msgstr "ループの最後からの反復回数 (1 インデックス化)" - -#: ../../rst/playbook_guide/playbooks_loops.rst:440 -msgid "``ansible_loop.revindex0``" -msgstr "``ansible_loop.revindex0``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:440 -msgid "The number of iterations from the end of the loop (0 indexed)" -msgstr "ループの最後からの反復回数 (0 インデックス化)" - -#: ../../rst/playbook_guide/playbooks_loops.rst:441 -msgid "``ansible_loop.first``" -msgstr "``ansible_loop.first``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:441 -msgid "``True`` if first iteration" -msgstr "最初の反復の場合は ``True``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:442 -msgid "``ansible_loop.last``" -msgstr "``ansible_loop.last``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:442 -msgid "``True`` if last iteration" -msgstr "最後の反復の場合は ``True``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:443 -msgid "``ansible_loop.length``" -msgstr "``ansible_loop.length``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:443 -msgid "The number of items in the loop" -msgstr "ループ内の項目数" - -#: ../../rst/playbook_guide/playbooks_loops.rst:444 -msgid "``ansible_loop.previtem``" -msgstr "``ansible_loop.previtem``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:444 -msgid "The item from the previous iteration of the loop. Undefined during the first iteration." -msgstr "ループの前の反復の項目。最初の反復では未定義です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:445 -msgid "``ansible_loop.nextitem``" -msgstr "``ansible_loop.nextitem``" - -#: ../../rst/playbook_guide/playbooks_loops.rst:445 -msgid "The item from the following iteration of the loop. Undefined during the last iteration." -msgstr "ループの次の反復の項目。最初の反復では未定義です。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:453 -msgid "When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase." -msgstr "``loop_control.extended`` を使用すると、制御ノードでより多くのメモリーが使用されます。これは、すべてのループの完全なループデータへの参照が含まれる ``ansible_loop.allitems`` の結果です。メインのAnsibleプロセス内のコールバックプラグインに表示するために結果をシリアル化すると、これらの参照が逆参照され、メモリー使用量が増加する可能性があります。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:457 -msgid "To disable the ``ansible_loop.allitems`` item, to reduce memory consumption, set ``loop_control.extended_allitems: no``." -msgstr "``ansible_loop.allitems`` 項目を無効にしてメモリー消費を減らすには、``loop_control.extended_allitems: no`` を設定します。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:466 -msgid "Accessing the name of your loop_var" -msgstr "loop_var の名前へのアクセス" - -#: ../../rst/playbook_guide/playbooks_loops.rst:469 -msgid "As of Ansible 2.8 you can get the name of the value provided to ``loop_control.loop_var`` using the ``ansible_loop_var`` variable" -msgstr "Ansible 2.8 では、``ansible_loop_var`` 変数を使用して ``loop_control.loop_var`` に提供された値の名前を取得できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:471 -msgid "For role authors, writing roles that allow loops, instead of dictating the required ``loop_var`` value, you can gather the value through the following" -msgstr "ロールの作成者は、必要な ``loop_var`` 値を指定する代わりに、ループを許可するロールを作成することで、次の方法で値を収集できます。" - -#: ../../rst/playbook_guide/playbooks_loops.rst:480 -msgid "Migrating from with_X to loop" -msgstr "with_X から loop への移行" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:1 -msgid "In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``." -msgstr "ほとんどの場合、ループは、``with_X`` スタイルのループではなく、``loop`` キーワードで最適に機能します。``loop`` 構文は通常、``query`` や ``lookup`` の複雑な使用ではなく、フィルターを使用して表現できます。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:3 -msgid "These examples show how to convert many common ``with_`` style loops to ``loop`` and filters." -msgstr "以下の例では、一般的な ``with_`` スタイルのループを ``loop`` およびフィルターに変換する方法を示しています。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:6 -msgid "with_list" -msgstr "with_list" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:8 -msgid "``with_list`` is directly replaced by ``loop``." -msgstr "``with_list`` は、直接 ``loop`` に置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:27 -msgid "with_items" -msgstr "with_items" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:29 -msgid "``with_items`` is replaced by ``loop`` and the ``flatten`` filter." -msgstr "``with_items`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:44 -msgid "with_indexed_items" -msgstr "with_indexed_items" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:46 -msgid "``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``." -msgstr "``with_indexed_items`` は、``loop``、``flatten`` フィルター、および ``loop_control.index_var`` に置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:63 -msgid "with_flattened" -msgstr "with_flattened" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:65 -msgid "``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter." -msgstr "``with_flattened`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:80 -msgid "with_together" -msgstr "with_together" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:82 -msgid "``with_together`` is replaced by ``loop`` and the ``zip`` filter." -msgstr "``with_together`` は、``loop`` フィルターおよび ``zip`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:98 -msgid "Another example with complex data" -msgstr "複雑なデータがある別の例" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:113 -msgid "with_dict" -msgstr "with_dict" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:115 -msgid "``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters." -msgstr "``with_dict`` は、``loop`` フィルターと、``dictsort`` フィルターまたは ``dict2items`` フィルターのいずれかのフィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:135 -msgid "with_sequence" -msgstr "with_sequence" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:137 -msgid "``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter." -msgstr "``with_sequence`` は、``loop`` 関数と ``range`` の関数、そして潜在的には ``format`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:151 -msgid "The range of the loop is exclusive of the end point." -msgstr "ループの範囲はエンドポイントを除きます。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:154 -msgid "with_subelements" -msgstr "with_subelements" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:156 -msgid "``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter." -msgstr "``with_subelements`` は、``loop`` フィルターおよび ``subelements`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:173 -msgid "with_nested/with_cartesian" -msgstr "with_nested/with_cartesian" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:175 -msgid "``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter." -msgstr "``with_nested`` と``with_cartesian`` は、ループと ``product`` のフィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:192 -msgid "with_random_choice" -msgstr "with_random_choice" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:194 -msgid "``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``." -msgstr "``with_random_choice`` は、``random`` フィルターを使用するだけで、``loop`` を必要とせずに置き換えることができます。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:4 -msgid "Module defaults" -msgstr "モジュールのデフォルト" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:6 -msgid "If you frequently call the same module with the same arguments, it can be useful to define default arguments for that particular module using the ``module_defaults`` keyword." -msgstr "同じ引数で同じモジュールを頻繁に呼び出す場合は、``module_defaults`` キーワードを使用して、その特定のモジュールのデフォルト引数を定義すると便利です。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:8 -msgid "Here is a basic example:" -msgstr "以下に基本的な例を示します。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:34 -msgid "The ``module_defaults`` keyword can be used at the play, block, and task level. Any module arguments explicitly specified in a task will override any established default for that module argument." -msgstr "``module_defaults`` キーワードは、プレイ、ブロック、およびタスクレベルで使用できます。タスクで明示的に指定されたモジュール引数は、そのモジュール引数に対して確立されたデフォルトを上書きします。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:46 -msgid "You can remove any previously established defaults for a module by specifying an empty dict." -msgstr "空のディクショナリーを指定することで、それまでに設定されたモジュールのデフォルトを削除することができます。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:58 -msgid "Any module defaults set at the play level (and block/task level when using ``include_role`` or ``import_role``) will apply to any roles used, which may cause unexpected behavior in the role." -msgstr "プレイレベルで設定されるモジュールのデフォルト (``include_role`` または ``import_role`` を使用する際のブロックまたはタスクのレベル) は、使用されるロールに適用されます。これにより、ロールで予期しない動作が発生する可能性があります。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:60 -msgid "Here are some more realistic use cases for this feature." -msgstr "この機能のより実用的なユースケースを以下に示します。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:62 -msgid "Interacting with an API that requires auth." -msgstr "認証をを必要とする API との対話:" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:85 -msgid "Setting a default AWS region for specific EC2-related modules." -msgstr "特定の EC2 関連のモジュールにデフォルトの AWS リージョンを設定します。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:103 -msgid "Module defaults groups" -msgstr "モジュールのデフォルトグループ" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:107 -msgid "Ansible 2.7 adds a preview-status feature to group together modules that share common sets of parameters. This makes it easier to author playbooks making heavy use of API-based modules such as cloud modules." -msgstr "Ansible 2.7 では、共通のパラメーターセットを持つモジュールをまとめて表示するプレビューステータス機能が追加されました。これにより、クラウドモジュールなどの API ベースのモジュールを多用する Playbook の作成が容易になります。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:110 -msgid "Group" -msgstr "グループ" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:110 -msgid "Purpose" -msgstr "目的" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:110 -msgid "Ansible Version" -msgstr "Ansible バージョン" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:112 -msgid "aws" -msgstr "aws" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:112 -msgid "Amazon Web Services" -msgstr "Amazon Web Services" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:112 -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:114 -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:116 -msgid "2.7" -msgstr "2.7" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:114 -msgid "azure" -msgstr "azure" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:114 -msgid "Azure" -msgstr "Azure" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:116 -msgid "gcp" -msgstr "gcp" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:116 -msgid "Google Cloud Platform" -msgstr "Google Cloud Platform" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:118 -msgid "k8s" -msgstr "k8s" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:118 -msgid "Kubernetes" -msgstr "Kubernetes" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:118 -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:120 -msgid "2.8" -msgstr "2.8" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:120 -msgid "os" -msgstr "os" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:120 -msgid "OpenStack" -msgstr "OpenStack" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:122 -msgid "acme" -msgstr "acme" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:122 -msgid "ACME" -msgstr "ACME" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:122 -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:124 -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:126 -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:128 -msgid "2.10" -msgstr "2.10" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:124 -msgid "docker*" -msgstr "docker*" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:124 -msgid "Docker" -msgstr "Docker" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:126 -msgid "ovirt" -msgstr "ovirt" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:126 -msgid "oVirt" -msgstr "oVirt" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:128 -msgid "vmware" -msgstr "vmware" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:128 -msgid "VMware" -msgstr "VMware" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:131 -msgid "The `docker_stack `_ module is not included in the ``docker`` defaults group." -msgstr "`docker_stack `_ モジュールは、``docker`` デフォルトグループには含まれません。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:133 -msgid "Use the groups with ``module_defaults`` by prefixing the group name with ``group/`` - for example ``group/aws``." -msgstr "グループ名の前に ``group/`` を追加して (例: ``group/aws``)、``module_defaults`` でグループを使用します。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:135 -msgid "In a playbook, you can set module defaults for whole groups of modules, such as setting a common AWS region." -msgstr "Playbook では、一般的な AWS リージョンの設定など、モジュールのグループ全体にモジュールのデフォルトを設定できます。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:155 -msgid "In ansible-core 2.12, collections can define their own groups in the ``meta/runtime.yml`` file. ``module_defaults`` does not take the ``collections`` keyword into account, so the fully qualified group name must be used for new groups in ``module_defaults``." -msgstr "ansible-core 2.12 では、コレクションは ``meta/runtime.yml`` ファイルで独自のグループを定義できます。``module_defaults`` は ``collections`` キーワードを考慮に入れないため、完全修飾グループ名を ``module_defaults`` の新規グループに使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_module_defaults.rst:157 -msgid "Here is an example ``runtime.yml`` file for a collection and a sample playbook using the group." -msgstr "以下は、グループを使用したコレクションおよびサンプル Playbook の ``runtime.yml`` ファイルの例です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:6 -msgid "Understanding privilege escalation: become" -msgstr "権限昇格の理解: become" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:8 -msgid "Ansible uses existing privilege escalation systems to execute tasks with root privileges or with another user's permissions. Because this feature allows you to 'become' another user, different from the user that logged into the machine (remote user), we call it ``become``. The ``become`` keyword uses existing privilege escalation tools like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, `runas`, `machinectl` and others." -msgstr "Ansible は既存の権限昇格システムを使用して、root 権限または別のユーザーのパーミッションでタスクを実行します。この機能を使用すると、このマシンにログインしたユーザー (リモートユーザー) とは別のユーザー「になる (become)」ことができるため、この機能は ``become`` と呼ばれています。``become`` キーワードは、`sudo`、`su`、`pfexec`、`doas`、`pbrun`、`dzdo`、`ksu`、`runas`、`machinectl` などの既存の特権昇格ツールを使用します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:14 -msgid "Using become" -msgstr "become の使用" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:16 -msgid "You can control the use of ``become`` with play or task directives, connection variables, or at the command line. If you set privilege escalation properties in multiple ways, review the :ref:`general precedence rules` to understand which settings will be used." -msgstr "play ディレクティブまたは task ディレクティブ、接続変数、またはコマンドラインでの ``become`` の使用を制御できます。複数の方法で権限昇格プロパティーを設定する場合は、:ref:`一般的な優先順位ルール` を確認し、使用する設定を確認します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:18 -msgid "A full list of all become plugins that are included in Ansible can be found in the :ref:`become_plugin_list`." -msgstr "Ansible に含まれる全 become プラグインの完全リストは、:ref:`become_plugin_list` にあります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:21 -msgid "Become directives" -msgstr "Become ディレクティブ" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:23 -msgid "You can set the directives that control ``become`` at the play or task level. You can override these by setting connection variables, which often differ from one host to another. These variables and directives are independent. For example, setting ``become_user`` does not set ``become``." -msgstr "プレイまたはタスクレベルで、``become`` を制御するディレクティブを設定できます。多くの場合は、ホストごとに異なる接続変数を設定することで、これらをオーバーライドできます。これらの変数とディレクティブは独立しています。たとえば、``become_user`` に設定しても ``become`` に設定されません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:26 -msgid "become" -msgstr "become" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:26 -msgid "set to ``yes`` to activate privilege escalation." -msgstr "権限昇格をアクティブにするには、``yes`` に設定します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:29 -msgid "become_user" -msgstr "become_user" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:29 -msgid "set to user with desired privileges — the user you `become`, NOT the user you login as. Does NOT imply ``become: yes``, to allow it to be set at host level. Default value is ``root``." -msgstr "希望する権限を持つユーザーに設定します。ログインしたユーザーではなく、`become` を行ったユーザーになります。ホストレベルで設定できるようにする ``become: yes`` を意味するものではありません。デフォルト値は ``root`` です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:32 -msgid "become_method" -msgstr "become_method" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:32 -msgid "(at play or task level) overrides the default method set in ansible.cfg, set to use any of the :ref:`become_plugins`." -msgstr "(play レベルまたは task レベルで)、ansible.cfg に設定されたデフォルトのメソッドをオーバーライドし、:ref:`become_plugins` を使用するよう設定します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:35 -msgid "become_flags" -msgstr "become_flags" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:35 -msgid "(at play or task level) permit the use of specific flags for the tasks or role. One common use is to change the user to nobody when the shell is set to nologin. Added in Ansible 2.2." -msgstr "(play レベルまたは task レベルで) タスクまたはロールに特定のフラグの使用を許可します。一般的な使い方としては、シェルが nologin に設定されているときに、ユーザーを nobody に変更するのが一般的な方法です。Ansible 2.2 で追加されました。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:37 -msgid "For example, to manage a system service (which requires ``root`` privileges) when connected as a non-``root`` user, you can use the default value of ``become_user`` (``root``):" -msgstr "たとえば、``root`` 以外のユーザーとして接続する際にシステムサービスを管理する (``root`` 権限が必要) には、``become_user`` (``root``) のデフォルト値を使用できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:47 -msgid "To run a command as the ``apache`` user:" -msgstr "``apache`` ユーザーとしてコマンドを実行するには、次を実行します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:56 -msgid "To do something as the ``nobody`` user when the shell is nologin:" -msgstr "シェルが nologin の場合に ``nobody`` ユーザーとして操作を行う場合は、次を実行します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:67 -msgid "To specify a password for sudo, run ``ansible-playbook`` with ``--ask-become-pass`` (``-K`` for short). If you run a playbook utilizing ``become`` and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with `CTRL-c`, then execute the playbook with ``-K`` and the appropriate password." -msgstr "sudo のパスワードを指定するには、``ansible-playbook`` を ``--ask-become-pass`` (略して ``-K``) と一緒に実行します。``become`` を使用して Playbook を実行し、Playbook がハングしているように見える場合は、ほとんどの場合、特権昇格のプロンプトで止まっています。`CTRL-c` で停止させてから、``-K`` と適切なパスワードで Playbook を実行してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:71 -msgid "Become connection variables" -msgstr "Become 接続変数" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:73 -msgid "You can define different ``become`` options for each managed node or group. You can define these variables in inventory or use them as normal variables." -msgstr "管理対象ノードまたはグループごとに異なる ``become`` オプションを定義できます。これらの変数はインベントリーで定義するか、通常の変数として使用できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:76 -msgid "ansible_become" -msgstr "ansible_become" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:76 -msgid "overrides the ``become`` directive, decides if privilege escalation is used or not." -msgstr "``become`` ディレクティブを上書きします。権限のエスカレーションが使用されるかどうかを指定します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:79 -msgid "ansible_become_method" -msgstr "ansible_become_method" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:79 -msgid "which privilege escalation method should be used" -msgstr "使用する権限昇格方法です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:82 -msgid "ansible_become_user" -msgstr "ansible_become_user" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:82 -msgid "set the user you become through privilege escalation; does not imply ``ansible_become: yes``" -msgstr "権限昇格で become を行うユーザーを設定します。``ansible_become: yes`` を意味するものではありません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:85 -msgid "ansible_become_password" -msgstr "ansible_become_password" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:85 -msgid "set the privilege escalation password. See :ref:`playbooks_vault` for details on how to avoid having secrets in plain text" -msgstr "権限昇格パスワードを設定します。平文での秘密の使用を回避する方法は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:88 -msgid "ansible_common_remote_group" -msgstr "ansible_common_remote_group" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:88 -msgid "determines if Ansible should try to ``chgrp`` its temporary files to a group if ``setfacl`` and ``chown`` both fail. See `Risks of becoming an unprivileged user`_ for more information. Added in version 2.10." -msgstr "``setfacl`` と ``chown`` の両方が失敗した場合に、Ansible が一時ファイルをグループに ``chgrp`` しようとするかどうかを決定します。詳細は「`非特権ユーザーになるリスク`_」を参照してください。バージョン 2.10 で追加されました。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:90 -msgid "For example, if you want to run all tasks as ``root`` on a server named ``webserver``, but you can only connect as the ``manager`` user, you could use an inventory entry like this:" -msgstr "たとえば、すべてのタスクを ``webserver`` という名前のサーバーで ``root`` として実行することを望み、``manager`` ユーザーとしてのみ接続できる場合は、以下のようなインベントリーエントリーを使用できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:97 -msgid "The variables defined above are generic for all become plugins but plugin specific ones can also be set instead. Please see the documentation for each plugin for a list of all options the plugin has and how they can be defined. A full list of become plugins in Ansible can be found at :ref:`become_plugins`." -msgstr "上記の変数はすべての become プラグインに汎用的なものですが、代わりにプラグイン固有の変数を設定することもできます。そのプラグインが持つすべてのオプションとその定義方法の一覧は、各プラグインのドキュメントを参照してください。Ansible における become プラグインの完全なリストは :ref:`become_plugins` を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:102 -msgid "Become command-line options" -msgstr "Become コマンドラインオプション" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:105 -msgid "ask for privilege escalation password; does not imply become will be used. Note that this password will be used for all hosts." -msgstr "権限昇格パスワードを要求します。これは。必ずしも become が使用されるとは限りません。このパスワードはすべてのホストで使用されることに注意してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:108 -msgid "run operations with become (no password implied)" -msgstr "become で操作を実行します (パスワードがないことを示しています)。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:111 -msgid "privilege escalation method to use (default=sudo), valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]" -msgstr "使用する特権昇格方法 (デフォルトは sudo)。有効な選択肢は、[ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ] となります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:115 -msgid "run operations as this user (default=root), does not imply --become/-b" -msgstr "このユーザー (デフォルトは root) として操作を実行します。--become/-b を意味するものではありません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:118 -msgid "Risks and limitations of become" -msgstr "become のリスクおよび制限" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:120 -msgid "Although privilege escalation is mostly intuitive, there are a few limitations on how it works. Users should be aware of these to avoid surprises." -msgstr "特権の昇格はほとんど直感的ですが、それがどのように機能するかについては、いくつかの制限があります。問題が発生しないように、これらの点に注意する必要があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:124 -msgid "Risks of becoming an unprivileged user" -msgstr "非特権ユーザーになる (become) リスク" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:126 -msgid "Ansible modules are executed on the remote machine by first substituting the parameters into the module file, then copying the file to the remote machine, and finally executing it there." -msgstr "Ansible モジュールは、まずモジュールファイルにパラメーターを代入し、次にそのファイルをリモートマシンにコピーし、最後にそこで実行することで、リモートマシン上で実行されます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:130 -msgid "Everything is fine if the module file is executed without using ``become``, when the ``become_user`` is root, or when the connection to the remote machine is made as root. In these cases Ansible creates the module file with permissions that only allow reading by the user and root, or only allow reading by the unprivileged user being switched to." -msgstr "モジュールファイルが ``become`` を使用せずに、``become_user`` が root の場合や、リモートマシンへの接続が root として行われる場合、すべてのことは問題ありません。このような場合、Ansible は、ユーザーおよび root による読み取りのみを許可するパーミッション、または切り替え先の非特権ユーザーの読み取りのみを許可するパーミッションを持つモジュールファイルを作成します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:136 -msgid "However, when both the connection user and the ``become_user`` are unprivileged, the module file is written as the user that Ansible connects as (the ``remote_user``), but the file needs to be readable by the user Ansible is set to ``become``. The details of how Ansible solves this can vary based on platform. However, on POSIX systems, Ansible solves this problem in the following way:" -msgstr "ただし、接続ユーザーと ``become_user`` の両方が特権を持たない場合、モジュールファイルは Ansible が接続するユーザー (``remote_user``) として記述されますが、Ansible が ``become`` に設定されているユーザーがファイルを読み取れる必要があります。Ansible がこれをプラットフォーム別に解決する方法の詳細は次のとおりですが、POSIX システムでは、Ansible がこの問題を解決します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:142 -msgid "First, if :command:`setfacl` is installed and available in the remote ``PATH``, and the temporary directory on the remote host is mounted with POSIX.1e filesystem ACL support, Ansible will use POSIX ACLs to share the module file with the second unprivileged user." -msgstr "まず、リモート ``PATH`` に :command:`setfacl` がインストールされ、利用可能な場合は、リモートホストの一時ディレクトリーが POSIX.1e ファイルシステム ACL サポートでマウントされている場合、Ansible は POSIX ACL を使用して 2 つの非特権ユーザーとモジュールファイルを共有します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:147 -msgid "Next, if POSIX ACLs are **not** available or :command:`setfacl` could not be run, Ansible will attempt to change ownership of the module file using :command:`chown` for systems which support doing so as an unprivileged user." -msgstr "次に、POSIX ACL が利用 **できない** か、:command:`setfacl` を実行できない場合、Ansible は、特権のないユーザーとして対応するシステムの :command:`chown` を使用してモジュールファイルの所有権を変更しようとします。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:151 -msgid "New in Ansible 2.11, at this point, Ansible will try :command:`chmod +a` which is a macOS-specific way of setting ACLs on files." -msgstr "Ansible 2.11 の新機能として、Ansible は、ファイルに ACL を設定する際に macOS 固有の方法で :command:`chmod +a` を試行します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:154 -msgid "New in Ansible 2.10, if all of the above fails, Ansible will then check the value of the configuration setting ``ansible_common_remote_group``. Many systems will allow a given user to change the group ownership of a file to a group the user is in. As a result, if the second unprivileged user (the ``become_user``) has a UNIX group in common with the user Ansible is connected as (the ``remote_user``), and if ``ansible_common_remote_group`` is defined to be that group, Ansible can try to change the group ownership of the module file to that group by using :command:`chgrp`, thereby likely making it readable to the ``become_user``." -msgstr "Ansible 2.10 の新機能で、上記のすべてが失敗すると、Ansible は構成設定 ``ansible_common_remote_group`` の値を確認します。多くのシステムでは、特定のユーザーが、ファイルのグループ所有権を、所属するグループに変更できます。その結果、2 番目の非特権ユーザー (``become_user``) に、Ansible が (``remote_user``として) 接続するユーザーに共通する UNIX グループがあり、``ansible_common_remote_group`` がそのグループとして定義されている場合は、 :command:`chgrp` を使用してモジュールファイルのグループ所有権をそのグループに変更しようとすることができます。したがって、``become_user`` が読みるようになる可能性があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:164 -msgid "At this point, if ``ansible_common_remote_group`` was defined and a :command:`chgrp` was attempted and returned successfully, Ansible assumes (but, importantly, does not check) that the new group ownership is enough and does not fall back further. That is, Ansible **does not check** that the ``become_user`` does in fact share a group with the ``remote_user``; so long as the command exits successfully, Ansible considers the result successful and does not proceed to check ``allow_world_readable_tmpfiles`` per below." -msgstr "この時点で、``ansible_common_remote_group`` が定義され、 :command:`chgrp` が試行されて正常に返された場合、Ansible は新しいグループの所有権で十分であると仮定し (ただし、重要なことですが、確認はしません)、それ以上はフォールバックしません。つまり、``become_user`` が実際に ``remote_user`` とグループを共有しているかどうかは **確認しません**。コマンドが正常に終了する限り、Ansible はその結果を成功とみなし、以下の ``allow_world_readable_tmpfiles`` のチェックには進みません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:172 -msgid "If ``ansible_common_remote_group`` is **not** set and the chown above it failed, or if ``ansible_common_remote_group`` *is* set but the :command:`chgrp` (or following group-permissions :command:`chmod`) returned a non-successful exit code, Ansible will lastly check the value of ``allow_world_readable_tmpfiles``. If this is set, Ansible will place the module file in a world-readable temporary directory, with world-readable permissions to allow the ``become_user`` (and incidentally any other user on the system) to read the contents of the file. **If any of the parameters passed to the module are sensitive in nature, and you do not trust the remote machines, then this is a potential security risk.**" -msgstr "``ansible_common_remote_group`` が **設定されておらず**、そこでの chown が失敗した場合、または ``ansible_common_remote_group`` *が* 設定されているが :command:`chgrp` (またはそれに続くグループパーミッションの :command:`chmod`) が成功しない終了コードを返した場合、Ansible は最後に ``allow_world_readable_tmpfiles`` の値を確認します。この値が設定されていると、Ansible はモジュールファイルを誰もが読める一時ディレクトリーに置き、``become_user`` (およびシステム上の他のユーザー) がファイルの内容を読めるように、誰もが読み取り可能なパーミッションを設定します。**モジュールに渡されるパラメーターに機密性があり、リモートマシンを信用していない場合、これは潜在的なセキュリティーリスクとなります。**" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:183 -msgid "Once the module is done executing, Ansible deletes the temporary file." -msgstr "モジュールの実行が完了すると、Ansible は一時ファイルを削除します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:185 -msgid "Several ways exist to avoid the above logic flow entirely:" -msgstr "上記のロジックフローを完全に回避する方法はいくつかあります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:187 -msgid "Use `pipelining`. When pipelining is enabled, Ansible does not save the module to a temporary file on the client. Instead it pipes the module to the remote python interpreter's stdin. Pipelining does not work for python modules involving file transfer (for example: :ref:`copy `, :ref:`fetch `, :ref:`template `), or for non-python modules." -msgstr "`pipelining` を使用します。パイプラインを有効にすると、Ansible はモジュールをクライアント上の一時ファイルに保存しません。代わりに、モジュールをリモートの python インタープリターの標準入力にパイプします。パイプラインは、ファイル転送を伴う python モジュール (例: :ref:`copy `、:ref:`fetch `、:ref:`template `) や、python 以外のモジュールでは機能しません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:193 -msgid "Avoid becoming an unprivileged user. Temporary files are protected by UNIX file permissions when you ``become`` root or do not use ``become``. In Ansible 2.1 and above, UNIX file permissions are also secure if you make the connection to the managed machine as root and then use ``become`` to access an unprivileged account." -msgstr "非特権ユーザーは使用しないでください。root に ``become`` した場合、または ``become`` を使用しない場合は、UNIX ファイルの権限で保護されます。Ansible 2.1 以降では、UNIX ファイルのパーミッションは、root として管理マシンに接続し、権限のないアカウントにアクセスするには、``become`` を使用しても保護されます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:199 -msgid "Although the Solaris ZFS filesystem has filesystem ACLs, the ACLs are not POSIX.1e filesystem acls (they are NFSv4 ACLs instead). Ansible cannot use these ACLs to manage its temp file permissions so you may have to resort to ``allow_world_readable_tmpfiles`` if the remote machines use ZFS." -msgstr "Solaris ZFS ファイルシステムにはファイルシステム ACL がありますが、ACL は POSIX.1e ファイルシステムの acl ではありません (正しくは NFSv4 ACL)。Ansible はこれらの ACL を使用してその一時ファイルのパーミッションを管理できないため、リモートマシンが ZFS を使用している場合は ``allow_world_readable_tmpfiles`` を再処理しないといけない場合があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:206 -msgid "Ansible makes it hard to unknowingly use ``become`` insecurely. Starting in Ansible 2.1, Ansible defaults to issuing an error if it cannot execute securely with ``become``. If you cannot use pipelining or POSIX ACLs, must connect as an unprivileged user, must use ``become`` to execute as a different unprivileged user, and decide that your managed nodes are secure enough for the modules you want to run there to be world readable, you can turn on ``allow_world_readable_tmpfiles`` in the :file:`ansible.cfg` file. Setting ``allow_world_readable_tmpfiles`` will change this from an error into a warning and allow the task to run as it did prior to 2.1." -msgstr "Ansible では、知らずに ``become`` を安全でない状態で使用することは困難です。Ansible 2.1 以降、Ansible は ``become`` で安全に実行できない場合は、デフォルトでエラーを発行するようになっています。パイプラインや POSIX ACL を使用できず、非特権ユーザーとして接続しなければならず、``become`` を使用して別の非特権ユーザーとして実行しなければならず、管理対象のノードが、そこで実行したいモジュールが誰でも読むことができる程度に安全であると判断した場合は、:file:`ansible.cfg` ファイルで ``allow_world_readable_tmpfiles`` を有効にすることができます。``allow_world_readable_tmpfiles`` を設定すると、これがエラーから警告に変わり、2.1 以前のようにタスクを実行できるようになります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:218 -msgid "Ansible 2.10 introduces the above-mentioned ``ansible_common_remote_group`` fallback. As mentioned above, if enabled, it is used when ``remote_user`` and ``become_user`` are both unprivileged users. Refer to the text above for details on when this fallback happens." -msgstr "Ansible 2.10 では、上記の ``ansible_common_remote_group`` フォールバックが導入されました。上記のように、有効になっていると、``remote_user`` と ``become_user`` の両方が非特権ユーザーである場合に使用されます。このフォールバックが発生するときの詳細は、上記のテキストを参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:223 -msgid "As mentioned above, if ``ansible_common_remote_group`` and ``allow_world_readable_tmpfiles`` are both enabled, it is unlikely that the world-readable fallback will ever trigger, and yet Ansible might still be unable to access the module file. This is because after the group ownership change is successful, Ansible does not fall back any further, and also does not do any check to ensure that the ``become_user`` is actually a member of the \"common group\". This is a design decision made by the fact that doing such a check would require another round-trip connection to the remote machine, which is a time-expensive operation. Ansible does, however, emit a warning in this case." -msgstr "上記のように、``ansible_common_remote_group`` と ``allow_world_readable_tmpfiles`` の両方が有効になると、誰でも読み取り可能なフォールバックがトリガーされず、Ansible がまだモジュールファイルにアクセスできない可能性があります。これは、グループの所有権変更が成功した後に、Ansible はこれ以上フォールバックせず、``become_user`` が実際には「共通グループ」のメンバーであることを確認するためのチェックが行われないためですこれは、このようなチェックを行うと、リモートマシンへの別のラウンドトリップ接続が必要になり、時間のかかる操作になってしまうことを考慮した設計上の決定です。しかし、Ansible はこの場合、警告を発します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:235 -msgid "Not supported by all connection plugins" -msgstr "すべての connection プラグインでサポートされない" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:237 -msgid "Privilege escalation methods must also be supported by the connection plugin used. Most connection plugins will warn if they do not support become. Some will just ignore it as they always run as root (jail, chroot, and so on)." -msgstr "特権昇格の方法は、使用する connection プラグインがサポートしている必要があります。ほとんどの connection プラグインは、become をサポートしていないと警告を表示します。一部の connection プラグインでは、常に root として実行されるため (jail、chroot など)、無視されます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:242 -msgid "Only one method may be enabled per host" -msgstr "ホストごとに有効にできる方法は 1 つだけ" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:244 -msgid "Methods cannot be chained. You cannot use ``sudo /bin/su -`` to become a user, you need to have privileges to run the command as that user in sudo or be able to su directly to it (the same for pbrun, pfexec or other supported methods)." -msgstr "メソッドを連鎖させることはできません。``sudo /bin/su -`` を使用してユーザーになる (become) ことはできません。そのユーザーとして sudo でコマンドを実行するか、直接 su できるような権限が必要です (pbrun、pfexec、その他のサポートされている方法も同様です)。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:249 -msgid "Privilege escalation must be general" -msgstr "特権昇格は一般的なものにすること" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:251 -msgid "You cannot limit privilege escalation permissions to certain commands. Ansible does not always use a specific command to do something but runs modules (code) from a temporary file name which changes every time. If you have '/sbin/service' or '/bin/chmod' as the allowed commands this will fail with ansible as those paths won't match with the temporary file that Ansible creates to run the module. If you have security rules that constrain your sudo/pbrun/doas environment to running specific command paths only, use Ansible from a special account that does not have this constraint, or use AWX or the :ref:`ansible_platform` to manage indirect access to SSH credentials." -msgstr "特権昇格の許可を特定のコマンドに限定することはできません。Ansible は常に特定のコマンドを使用して何かを行うわけではなく、毎回変更される一時ファイル名からモジュール (コード) を実行します。許可されるコマンドとして「/sbin/service」や「/bin/chmod」を指定した場合、これらのパスは Ansible がモジュールを実行するために作成する一時ファイルと一致しないため、Ansible では失敗します。sudo/pbrun/doas 環境で特定のコマンドパスしか実行できないようなセキュリティールールがある場合は、この制約を受けない特別なアカウントで Ansible を使用するか、AWX または :ref:`ansible_platform` を使用して SSH 認証情報への間接的なアクセスを管理してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:262 -msgid "May not access environment variables populated by pamd_systemd" -msgstr "pamd_systemd が設定する環境変数にアクセスできない場合" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:264 -msgid "For most Linux distributions using ``systemd`` as their init, the default methods used by ``become`` do not open a new \"session\", in the sense of systemd. Because the ``pam_systemd`` module will not fully initialize a new session, you might have surprises compared to a normal session opened through ssh: some environment variables set by ``pam_systemd``, most notably ``XDG_RUNTIME_DIR``, are not populated for the new user and instead inherited or just emptied." -msgstr "``systemd`` を init として使用しているほとんどの Linux ディストリビューションでは、``become`` が使用するデフォルトの方法では、systemd の意味での新しい「セッション」を開くことができません。``pam_systemd`` モジュールは新しいセッションを完全には初期化しないため、ssh で開いた通常のセッションと比べて驚くことがあるかもしれません。``pam_systemd`` によって設定されたいくつかの環境変数、特に ``XDG_RUNTIME_DIR`` は新しいユーザーには設定されず、代わりに継承されたり、単に空になったりします。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:272 -msgid "This might cause trouble when trying to invoke systemd commands that depend on ``XDG_RUNTIME_DIR`` to access the bus:" -msgstr "このため、バスへのアクセスを ``XDG_RUNTIME_DIR`` に依存する systemd コマンドを呼び出す際に問題が発生する可能性があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:282 -msgid "To force ``become`` to open a new systemd session that goes through ``pam_systemd``, you can use ``become_method: machinectl``." -msgstr "``become`` に、``pam_systemd`` を通して新しい systemd セッションを開くために、``become_method: machinectl`` を使用することができます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:285 -msgid "For more information, see `this systemd issue `_." -msgstr "詳細情報は、「`this systemd issue `_」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:289 -msgid "Resolving Temporary File Error Messsages" -msgstr "一時的なファイルエラーメッセージの解決" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:291 -msgid "Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user\"" -msgstr "非特権ユーザーになる場合に Ansible が作成する必要のある一時ファイルに権限を設定できませんでした" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:292 -msgid "This error can be resolved by installing the package that provides the ``setfacl`` command. (This is frequently the ``acl`` package but check your OS documentation.)" -msgstr "このエラーは、``setfacl`` コマンドを提供するパッケージをインストールすることで解決できます (多くの場合、これは``acl``パッケージ ですが、OS ドキュメントを確認してください)。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:297 -msgid "Become and network automation" -msgstr "become およびネットワーク自動化" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:299 -msgid "As of version 2.6, Ansible supports ``become`` for privilege escalation (entering ``enable`` mode or privileged EXEC mode) on all Ansible-maintained network platforms that support ``enable`` mode. Using ``become`` replaces the ``authorize`` and ``auth_pass`` options in a ``provider`` dictionary." -msgstr "バージョン 2.6 以降、Ansible は、``enable`` モードをサポートするすべての Ansible が保守するネットワークプラットフォームにおいて、特権昇格 (``enable`` モードまたは特権 EXEC モードへの移行) のために ``become`` をサポートしています。``become`` を使用すると、``provider`` ディクショナリーの ``authorize`` オプションおよび ``auth_pass`` のオプションが置き換えられます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:301 -msgid "You must set the connection type to either ``connection: ansible.netcommon.network_cli`` or ``connection: ansible.netcommon.httpapi`` to use ``become`` for privilege escalation on network devices. Check the :ref:`platform_options` documentation for details." -msgstr "ネットワークデバイスの特権昇格に ``become`` を使用するには、接続タイプを ``connection: ansible.netcommon.network_cli`` または ``connection: ansible.netcommon.httpapi`` のいずれかに設定する必要があります。詳細については、「:ref:`platform_options`」を確認してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:303 -msgid "You can use escalated privileges on only the specific tasks that need them, on an entire play, or on all plays. Adding ``become: yes`` and ``become_method: enable`` instructs Ansible to enter ``enable`` mode before executing the task, play, or playbook where those parameters are set." -msgstr "昇格した権限は、それを必要とする特定のタスクのみ、プレイ全体でのみ、またはすべてのプレイで使用することができます。``become: yes`` と ``become_method: enable`` を追加すると、これらのパラメーターが設定されているタスク、プレイ、または Playbook を実行する前に、``enable`` モードに入るよう Ansible に指示します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:305 -msgid "If you see this error message, the task that generated it requires ``enable`` mode to succeed:" -msgstr "このエラーメッセージが表示された場合に、エラーメッセージを生成したタスクを成功させるには、``enable`` モードが必要になります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:311 -msgid "To set ``enable`` mode for a specific task, add ``become`` at the task level:" -msgstr "特定のタスクに ``enable`` モードを設定するには、タスクレベルで ``become`` を追加します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:322 -msgid "To set enable mode for all tasks in a single play, add ``become`` at the play level:" -msgstr "1 つのプレイのすべてのタスクに enable モードを設定するには、プレイレベルに ``become`` を追加します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:336 -msgid "Setting enable mode for all tasks" -msgstr "すべてのタスクに enable モードの設定" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:338 -msgid "Often you wish for all tasks in all plays to run using privilege mode, that is best achieved by using ``group_vars``:" -msgstr "すべてのプレイのすべてのタスクを特権モードで実行させたいと思うことがよくありますが、そのような場合には、``group_vars`` を使用することが最適です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:340 -msgid "**group_vars/eos.yml**" -msgstr "**group_vars/eos.yml**" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:351 -msgid "Passwords for enable mode" -msgstr "enable モードのパスワード" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:353 -msgid "If you need a password to enter ``enable`` mode, you can specify it in one of two ways:" -msgstr "``enable`` モードに入るパスワードが必要な場合は、以下のいずれかの方法で指定できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:355 -msgid "providing the :option:`--ask-become-pass ` command line option" -msgstr ":option:`--ask-become-pass ` コマンドラインオプションの指定" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:356 -msgid "setting the ``ansible_become_password`` connection variable" -msgstr "``ansible_become_password`` 接続変数の設定" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:360 -msgid "As a reminder passwords should never be stored in plain text. For information on encrypting your passwords and other secrets with Ansible Vault, see :ref:`vault`." -msgstr "通知パスワードは平文で保存しないでください。Ansible Vault でパスワードやその他の秘密を暗号化する方法は、「:ref:`vault`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:363 -msgid "authorize and auth_pass" -msgstr "authorize および auth_pass" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:365 -msgid "Ansible still supports ``enable`` mode with ``connection: local`` for legacy network playbooks. To enter ``enable`` mode with ``connection: local``, use the module options ``authorize`` and ``auth_pass``:" -msgstr "Ansible では、従来のネットワークの Playbook について、``connection: local`` を使用した ``enable`` モードを引き続きサポートしています。``connection: local`` で ``enable`` モードに入るには、モジュールオプション ``authorize`` および ``auth_pass`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:380 -msgid "We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` documentation for details." -msgstr "ネットワークデバイスの ``enable`` モードに ``become`` を一貫して使用するように Playbook を更新することが推奨されます。``authorize`` および ``provider`` ディクショナリーの使用は、今後は推奨されません。詳細は、:ref:`platform_options` のドキュメントを参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:385 -msgid "Become and Windows" -msgstr "Become および Windows" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:387 -msgid "Since Ansible 2.3, ``become`` can be used on Windows hosts through the ``runas`` method. Become on Windows uses the same inventory setup and invocation arguments as ``become`` on a non-Windows host, so the setup and variable names are the same as what is defined in this document with the exception of ``become_user``. As there is no sensible default for ``become_user`` on Windows it is required when using ``become``. See :ref:`ansible.builtin.runas become plugin ` for details." -msgstr "Ansible 2.3 以降、``become`` は ``runas`` メソッドを通じて Windows ホストでも使用できるようになりました。Windows 上の Become は、非 Windows ホスト上の ``become`` と同じインベントリー設定と起動引数を使用するため、設定と変数名はこのドキュメントで定義されているものと同じになります (``become_user`` を除く)。Windows には妥当な ``become_user`` のデフォルトがないので、``become`` を使用時に必要です。詳細は、:ref:`ansible.builtin.runas become plugin ` を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:394 -msgid "While ``become`` can be used to assume the identity of another user, there are other uses for it with Windows hosts. One important use is to bypass some of the limitations that are imposed when running on WinRM, such as constrained network delegation or accessing forbidden system calls like the WUA API. You can use ``become`` with the same user as ``ansible_user`` to bypass these limitations and run commands that are not normally accessible in a WinRM session." -msgstr "``become`` は、別のユーザーの ID を装うために使用することができますが、Windows ホストではそれ以外にも使用方法があります。重要な用途の 1 つは、ネットワーク委譲の制約や、WUA API のような禁止されたシステムコールへのアクセスなど、WinRM 上で実行する際に課される制限の一部を回避することです。``become`` を ``ansible_user`` と同じユーザーで使用すると、これらの制限を回避して、WinRM セッションでは通常アクセスできないコマンドを実行することができます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:402 -msgid "On Windows you cannot connect with an underprivileged account and use become to elevate your rights. Become can only be used if your connection account is already an Administrator of the target host." -msgstr "Windows では、権限のないアカウントで接続できず、become を使用して権限を昇格することはできません。become は、接続アカウントがすでにターゲットホストの管理者である場合にのみ使用できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:407 -msgid "Administrative rights" -msgstr "管理者権限" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:409 -msgid "Many tasks in Windows require administrative privileges to complete. When using the ``runas`` become method, Ansible will attempt to run the module with the full privileges that are available to the become user. If it fails to elevate the user token, it will continue to use the limited token during execution." -msgstr "Windows の多くのタスクを完了するには、管理者権限が必要です。``runas`` の become メソッドを使用すると、Ansible は become ユーザーが使用できる全権限でモジュールの実行を試みます。ユーザートークンの昇格に失敗すると、実行中に制限されたトークンを引き続き使用します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:414 -msgid "A user must have the ``SeDebugPrivilege`` to run a become process with elevated privileges. This privilege is assigned to Administrators by default. If the debug privilege is not available, the become process will run with a limited set of privileges and groups." -msgstr "ユーザーは、昇格された権限で become プロセスを実行するには、``SeDebugPrivilege`` が必要です。この権限はデフォルトで管理者に割り当てられます。デバッグ権限が利用できない場合、become プロセスは、限られた一連の特権およびグループで実行されます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:419 -msgid "To determine the type of token that Ansible was able to get, run the following task:" -msgstr "Ansible が取得できたトークンの種類を確認するには、以下のタスクを実行します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:428 -msgid "The output will look something similar to the below:" -msgstr "出力は以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:516 -msgid "Under the ``label`` key, the ``account_name`` entry determines whether the user has Administrative rights. Here are the labels that can be returned and what they represent:" -msgstr "``label`` キーにおいて、``account_name`` エントリーは、ユーザーに管理権限があるかどうかを判断します。ここでは、返すことができるラベルと、そのラベルが表す内容を紹介します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:520 -msgid "``Medium``: Ansible failed to get an elevated token and ran under a limited token. Only a subset of the privileges assigned to user are available during the module execution and the user does not have administrative rights." -msgstr "``Medium``: Ansible が昇格したトークンの取得に失敗し、制限付きのトークンで実行されました。モジュールの実行中に、ユーザーに割り当てられた特権のサブセットのみが利用可能で、ユーザーは管理者権限を持っていません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:524 -msgid "``High``: An elevated token was used and all the privileges assigned to the user are available during the module execution." -msgstr "``High``: 昇格されたトークンが使用され、ユーザーに割り当てられたすべての特権は、モジュールの実行時に利用できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:527 -msgid "``System``: The ``NT AUTHORITY\\System`` account is used and has the highest level of privileges available." -msgstr "``System``: ``NT AUTHORITY\\System`` アカウントが使用され、利用可能な最高レベルの特権が付与されます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:530 -msgid "The output will also show the list of privileges that have been granted to the user. When the privilege value is ``disabled``, the privilege is assigned to the logon token but has not been enabled. In most scenarios these privileges are automatically enabled when required." -msgstr "出力には、ユーザーに付与される権限の一覧が表示されます。権限の値が ``disabled`` の場合、特権はログオントークンに割り当てられますが、有効になっていません。ほとんどのシナリオでは、これらの特権は必要に応じて自動的に有効になります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:535 -msgid "If running on a version of Ansible that is older than 2.5 or the normal ``runas`` escalation process fails, an elevated token can be retrieved by:" -msgstr "Ansible のバージョンが 2.5 よりも古い場合や、通常の ``runas`` のエスカレーションプロセスが失敗した場合は、昇格したトークンを以下の方法で取得できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:538 -msgid "Set the ``become_user`` to ``System`` which has full control over the operating system." -msgstr "``become_user`` を、オペレーティングシステムを完全にコントロールする ``System`` に設定します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:541 -msgid "Grant ``SeTcbPrivilege`` to the user Ansible connects with on WinRM. ``SeTcbPrivilege`` is a high-level privilege that grants full control over the operating system. No user is given this privilege by default, and care should be taken if you grant this privilege to a user or group. For more information on this privilege, please see `Act as part of the operating system `_. You can use the below task to set this privilege on a Windows host:" -msgstr "Ansible が WinRM で接続するユーザーに ``SeTcbPrivilege`` を付与します。``SeTcbPrivilege`` は、オペレーティングシステムに対する完全な制御を付与する高レベルの特権です。デフォルトでは、この特権は指定されていません。この特権をユーザーまたはグループに付与する場合は注意が必要です。この特権の詳細は、「`Act as part of the operating system `_」を参照してください。以下のタスクを使用して、Windows ホストでこの特権を設定できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:557 -msgid "Turn UAC off on the host and reboot before trying to become the user. UAC is a security protocol that is designed to run accounts with the ``least privilege`` principle. You can turn UAC off by running the following tasks:" -msgstr "そのユーザーになる (become) 前に、ホストで UAC をオフにし、再起動します。UAC は、``least privilege`` プリンシパルでアカウントを実行するように設計されたセキュリティープロトコルです。以下のタスクを実行して UAC をオフにすることができます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:577 -msgid "Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows security vulnerabilities and care should be given if these steps are taken." -msgstr "``SeTcbPrivilege`` を付与するか UAC をオフにすると、Windows のセキュリティー上の脆弱性を引き起こす可能性があるため、このような手順を実行する場合は注意が必要です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:581 -msgid "Local service accounts" -msgstr "ローカルサービスアカウント" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:583 -msgid "Prior to Ansible version 2.5, ``become`` only worked on Windows with a local or domain user account. Local service accounts like ``System`` or ``NetworkService`` could not be used as ``become_user`` in these older versions. This restriction has been lifted since the 2.5 release of Ansible. The three service accounts that can be set under ``become_user`` are:" -msgstr "Ansible バージョン 2.5 より前のバージョンでは、``become`` は、Windows でローカルまたはドメインのユーザーアカウントでのみ動作していました。``System`` や ``NetworkService`` などのローカルサービスアカウントは、これらの旧バージョンでは ``become_user`` として使用できません。この制限は、Ansible 2.5 のリリース以降は解除されました。``become_user`` に設定できる 3 つのサービスアカウントは以下のとおりです。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:589 -msgid "System" -msgstr "システム" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:590 -msgid "NetworkService" -msgstr "NetworkService" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:591 -msgid "LocalService" -msgstr "LocalService" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:593 -msgid "Because local service accounts do not have passwords, the ``ansible_become_password`` parameter is not required and is ignored if specified." -msgstr "ローカルサービスアカウントはパスワードを持たないため、``ansible_become_password`` パラメーターは必須ではなく、指定しても無視されます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:598 -msgid "Become without setting a password" -msgstr "パスワードを設定しない Become" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:600 -msgid "As of Ansible 2.8, ``become`` can be used to become a Windows local or domain account without requiring a password for that account. For this method to work, the following requirements must be met:" -msgstr "Ansible 2.8 では、Windows のローカルまたはドメインアカウントになるために、そのアカウントのパスワードがなくても ``become`` を使用することができます。この方法を行うには、以下の要件を満たす必要があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:604 -msgid "The connection user has the ``SeDebugPrivilege`` privilege assigned" -msgstr "接続ユーザーに ``SeDebugPrivilege`` 権限が割り当てられている" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:605 -msgid "The connection user is part of the ``BUILTIN\\Administrators`` group" -msgstr "接続ユーザーが ``BUILTIN\\Administrators`` グループに属している" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:606 -msgid "The ``become_user`` has either the ``SeBatchLogonRight`` or ``SeNetworkLogonRight`` user right" -msgstr "``become_user`` に、``SeBatchLogonRight`` または ``SeNetworkLogonRight`` のユーザー権限がある" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:608 -msgid "Using become without a password is achieved in one of two different methods:" -msgstr "パスワードなしの become は、次のいずれかの方法で使用できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:610 -msgid "Duplicating an existing logon session's token if the account is already logged on" -msgstr "アカウントがすでにログオンしている場合は、既存のログオンセッションのトークンを複製する" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:611 -msgid "Using S4U to generate a logon token that is valid on the remote host only" -msgstr "S4U を使用してリモートホストでのみ有効なログイントークンを生成する" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:613 -msgid "In the first scenario, the become process is spawned from another logon of that user account. This could be an existing RDP logon, console logon, but this is not guaranteed to occur all the time. This is similar to the ``Run only when user is logged on`` option for a Scheduled Task." -msgstr "最初のシナリオでは、そのユーザーアカウントの別のログオンから become プロセスを起動します。これは既存の RDP ログイン、コンソールログオンですが、これは常に発生するとは限りません。これは、スケジュール済みタスクの ``Run only when user is logged on`` オプションと類似しています。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:618 -msgid "In the case where another logon of the become account does not exist, S4U is used to create a new logon and run the module through that. This is similar to the ``Run whether user is logged on or not`` with the ``Do not store password`` option for a Scheduled Task. In this scenario, the become process will not be able to access any network resources like a normal WinRM process." -msgstr "become アカウントの別のログオンが存在しない場合は、S4U を使用して新しいログオンを作成し、それを介してモジュールを実行します。これは、スケジュール済みタスクの ``Do not store password`` オプションを持つ ``Run whether user is logged on or not`` と似ています。このシナリオでは、become プロセスは通常の WinRM プロセスなどのネットワークリソースにアクセスできません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:624 -msgid "To make a distinction between using become with no password and becoming an account that has no password make sure to keep ``ansible_become_password`` as undefined or set ``ansible_become_password:``." -msgstr "パスワードなしで become を使用することと、パスワードがないアカウントになる (become) ことを区別するには、``ansible_become_password`` を undefined にしておくか、``ansible_become_password:`` を設定してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:628 -msgid "Because there are no guarantees an existing token will exist for a user when Ansible runs, there's a high change the become process will only have access to local resources. Use become with a password if the task needs to access network resources" -msgstr "Ansible の実行時に既存のトークンがユーザーに存在するという保証がないため、become プロセスがローカルリソースにのみアクセスできます。タスクがネットワークリソースにアクセスする必要がある場合は、パスワードで become を使用します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:634 -msgid "Accounts without a password" -msgstr "パスワードのないアカウント" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:636 -msgid "As a general security best practice, you should avoid allowing accounts without passwords." -msgstr "セキュリティーに関する一般的なベストプラクティスとして、パスワードのないアカウントを許可しないでください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:638 -msgid "Ansible can be used to become a Windows account that does not have a password (like the ``Guest`` account). To become an account without a password, set up the variables like normal but set ``ansible_become_password: ''``." -msgstr "Ansible を使用して、パスワードがない Windows アカウントになります (``Guest`` アカウントなど)。パスワードのないアカウントになるには、通常どおり変数を設定しますが、``ansible_become_password: ''`` を設定します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:642 -msgid "Before become can work on an account like this, the local policy `Accounts: Limit local account use of blank passwords to console logon only `_ must be disabled. This can either be done through a Group Policy Object (GPO) or with this Ansible task:" -msgstr "このようなアカウントで become を有効にする前に、ローカルポリシー `Accounts: Limit local account use of blank passwords to console logon only `_ を無効にする必要があります。これは Group Policy Object (GPO) またはこの Ansible タスクで実行できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:657 -msgid "This is only for accounts that do not have a password. You still need to set the account's password under ``ansible_become_password`` if the become_user has a password." -msgstr "これは、パスワードがないアカウント専用です。become_user にパスワードがある場合は、``ansible_become_password`` でアカウントのパスワードを設定する必要があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:662 -msgid "Become flags for Windows" -msgstr "Windows での Become フラグ" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:664 -msgid "Ansible 2.5 added the ``become_flags`` parameter to the ``runas`` become method. This parameter can be set using the ``become_flags`` task directive or set in Ansible's configuration using ``ansible_become_flags``. The two valid values that are initially supported for this parameter are ``logon_type`` and ``logon_flags``." -msgstr "Ansible 2.5 では、``become_flags`` パラメーターを become メソッド ``runas`` に追加しました。このパラメーターは、``become_flags`` タスクディレクティブを使用するか、``ansible_become_flags`` を使用して Ansible の設定で設定できます。このパラメーターで最初にサポートされる 2 つの有効な値は ``logon_type`` と ``logon_flags`` です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:670 -msgid "These flags should only be set when becoming a normal user account, not a local service account like LocalSystem." -msgstr "これらのフラグは、LocalSystem などのローカルサービスアカウントではなく、通常のユーザーアカウントになる (become) 場合にのみ設定する必要があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:672 -msgid "The key ``logon_type`` sets the type of logon operation to perform. The value can be set to one of the following:" -msgstr "鍵 ``logon_type`` は、実行するログオン操作のタイプを設定します。値は以下のいずれかに設定できます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:675 -msgid "``interactive``: The default logon type. The process will be run under a context that is the same as when running a process locally. This bypasses all WinRM restrictions and is the recommended method to use." -msgstr "``interactive``: デフォルトのログオンタイプ。プロセスは、ローカルでプロセスを実行するときと同じコンテキストで実行されます。これにより、すべての WinRM 制限が回避され、推奨される方法です。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:679 -msgid "``batch``: Runs the process under a batch context that is similar to a scheduled task with a password set. This should bypass most WinRM restrictions and is useful if the ``become_user`` is not allowed to log on interactively." -msgstr "``batch``: パスワードセットを使用してスケジュールされたタスクに似たバッチコンテキストでプロセスを実行します。これにより、ほとんどの WinRM 制限を回避する必要があり、``become_user`` が対話的にログインできない場合に役立ちます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:684 -msgid "``new_credentials``: Runs under the same credentials as the calling user, but outbound connections are run under the context of the ``become_user`` and ``become_password``, similar to ``runas.exe /netonly``. The ``logon_flags`` flag should also be set to ``netcredentials_only``. Use this flag if the process needs to access a network resource (like an SMB share) using a different set of credentials." -msgstr "``new_credentials``: 呼び出し元ユーザーと同じ認証情報の下で実行されますが、発信側の接続は ``runas.exe /netonly`` と同様に ``become_user`` と ``become_password`` のコンテキストの下で実行されます。``logon_flags`` フラグは、``netcredentials_only`` にも設定する必要があります。このフラグは、プロセスが異なる認証情報セットを使用してネットワークリソース (SMB 共有など) にアクセスする必要がある場合に使用します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:691 -msgid "``network``: Runs the process under a network context without any cached credentials. This results in the same type of logon session as running a normal WinRM process without credential delegation, and operates under the same restrictions." -msgstr "``network``: キャッシュされた認証情報なしで、ネットワークコンテキストでプロセスを実行します。これにより、認証情報の委譲を使用せずに通常の WinRM プロセスを実行するのと同じ種類のログオンセッションが実行され、同じ制限で動作します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:696 -msgid "``network_cleartext``: Like the ``network`` logon type, but instead caches the credentials so it can access network resources. This is the same type of logon session as running a normal WinRM process with credential delegation." -msgstr "``network_cleartext``: ``network`` ログオンタイプなのですが、代わりに認証情報をキャッシュするため、ネットワークリソースにアクセスできます。これは、認証情報の委譲を使用して通常の WinRM プロセスを実行するのと同じタイプのログオンセッションです。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:700 -msgid "For more information, see `dwLogonType `_." -msgstr "詳細情報は、「`dwLogonType `_」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:703 -msgid "The ``logon_flags`` key specifies how Windows will log the user on when creating the new process. The value can be set to none or multiple of the following:" -msgstr "``logon_flags`` キーは、新規プロセスの作成時に Windows がユーザーをログに記録する方法を指定します。この値は、以下の複数の値に設定でき、値を設定しないこともできます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:706 -msgid "``with_profile``: The default logon flag set. The process will load the user's profile in the ``HKEY_USERS`` registry key to ``HKEY_CURRENT_USER``." -msgstr "``with_profile``: デフォルトのログオンフラグセット。このプロセスは、``HKEY_USERS`` レジストリーキーのユーザーのプロファイルを ``HKEY_CURRENT_USER`` に読み込みます。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:709 -msgid "``netcredentials_only``: The process will use the same token as the caller but will use the ``become_user`` and ``become_password`` when accessing a remote resource. This is useful in inter-domain scenarios where there is no trust relationship, and should be used with the ``new_credentials`` ``logon_type``." -msgstr "``netcredentials_only``: プロセスは呼び出し元と同じトークンを使用しますが、リモートリソースにアクセスする際には ``become_user`` と ``become_password`` を使用します。これは、信頼関係がないドメイン間シナリオで便利です。また、``new_credentials`` ``logon_type`` と共に使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:714 -msgid "By default ``logon_flags=with_profile`` is set, if the profile should not be loaded set ``logon_flags=`` or if the profile should be loaded with ``netcredentials_only``, set ``logon_flags=with_profile,netcredentials_only``." -msgstr "デフォルトでは ``logon_flags=with_profile`` が設定されていますが、プロファイルを読み込む必要がない場合は ``logon_flags=`` を設定するか、``netcredentials_only`` でプロファイルを読み込む必要がある場合は``logon_flags=with_profile,netcredentials_only`` を設定してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:718 -msgid "For more information, see `dwLogonFlags `_." -msgstr "詳細情報は、「`dwLogonFlags `_」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:720 -msgid "Here are some examples of how to use ``become_flags`` with Windows tasks:" -msgstr "Windows タスクで ``become_flags`` を使用する例を以下に示します。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:748 -msgid "Limitations of become on Windows" -msgstr "Windows における become 制限" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:750 -msgid "Running a task with ``async`` and ``become`` on Windows Server 2008, 2008 R2 and Windows 7 only works when using Ansible 2.7 or newer." -msgstr "Windows Server 2008、2008 R2、Windows 7 で ``async`` および ``become`` を使用してタスクを実行できるのは、Ansible 2.7 以降を使用している場合のみです。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:753 -msgid "By default, the become user logs on with an interactive session, so it must have the right to do so on the Windows host. If it does not inherit the ``SeAllowLogOnLocally`` privilege or inherits the ``SeDenyLogOnLocally`` privilege, the become process will fail. Either add the privilege or set the ``logon_type`` flag to change the logon type used." -msgstr "デフォルトでは、become ユーザーは対話型セッションでログオンするため、Windows ホストでこの権限を設定する必要があります。``SeAllowLogOnLocally`` 特権を継承しない場合、または ``SeDenyLogOnLocally`` 特権を継承する場合は become プロセスに失敗します。特権を追加するか、``logon_type`` フラグを設定して使用するログオンタイプを変更してください。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:759 -msgid "Prior to Ansible version 2.3, become only worked when ``ansible_winrm_transport`` was either ``basic`` or ``credssp``. This restriction has been lifted since the 2.4 release of Ansible for all hosts except Windows Server 2008 (non R2 version)." -msgstr "Ansible バージョン 2.3 よりも前のバージョンでは、``ansible_winrm_transport`` が ``basic`` または ``credssp`` のいずれかでのみ機能していました。この制限は、Windows Server 2008 (R2 バージョン以外) を除くすべてのホストで 2.4 リリース以降に取り込まれました。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:764 -msgid "The Secondary Logon service ``seclogon`` must be running to use ``ansible_become_method: runas``" -msgstr "``ansible_become_method: runas`` を使用するには、セカンダリーログオンサービス ``seclogon`` が実行している必要があります。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:766 -msgid "The connection user must already be an Administrator on the Windows host to use ``runas``. The target become user does not need to be an Administrator though." -msgstr "``runas`` を使用するには、接続ユーザーがすでに Windows ホストの管理者である必要があります。ターゲット become ユーザーは管理者である必要はありません。" - -#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:773 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:5 -msgid "Interactive input: prompts" -msgstr "インタラクティブな入力: prompt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:7 -msgid "If you want your playbook to prompt the user for certain input, add a 'vars_prompt' section. Prompting the user for variables lets you avoid recording sensitive data like passwords. In addition to security, prompts support flexibility. For example, if you use one playbook across multiple software releases, you could prompt for the particular release version." -msgstr "Playbook でユーザーに特定の入力を促したい場合は、「vars_prompt」セクションを追加します。ユーザーに変数の入力を促すことで、パスワードのような機密データの記録を回避することができます。セキュリティーのほかに、プロンプトは柔軟性をサポートします。たとえば、1 つの Playbook を複数のソフトウェアリリースで使用する場合は、特定のリリースバージョンの入力を促すことができます。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:12 -msgid "Here is a most basic example:" -msgstr "以下は最も基本的な例です。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:33 -msgid "The user input is hidden by default but it can be made visible by setting ``private: no``." -msgstr "ユーザー入力はデフォルトでは表示されませんが、``private: no`` を設定することで表示できます。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:36 -msgid "Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible AWX). See :ref:`passing_variables_on_the_command_line`." -msgstr "個別の ``vars_prompt`` 変数の入力を求めるプロンプトは、コマンドラインの ``--extra-vars`` オプションですでに定義されている変数や、非対話的なセッション (cron や Ansible AWX など) から実行する場合に省略されます。「:ref:`passing_variables_on_the_command_line`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:38 -msgid "If you have a variable that changes infrequently, you can provide a default value that can be overridden." -msgstr "まれに変更する変数がある場合は、上書きできるデフォルト値を指定できます。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:49 -msgid "Hashing values supplied by ``vars_prompt``" -msgstr "``vars_prompt`` により提供される値のハッシュ処理" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:51 -msgid "You can hash the entered value so you can use it, for instance, with the user module to define a password:" -msgstr "入力された値をハッシュ処理することができます。したがって、たとえばユーザーモジュールで使用してパスワードを定義できます。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:64 -msgid "If you have `Passlib `_ installed, you can use any crypt scheme the library supports:" -msgstr "`Passlib `_ をインストールしている場合は、ライブラリーがサポートする任意の crypt スキームを使用できます。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:66 -msgid "*des_crypt* - DES Crypt" -msgstr "*des_crypt* - DES Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:67 -msgid "*bsdi_crypt* - BSDi Crypt" -msgstr "*bsdi_crypt* - BSDi Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:68 -msgid "*bigcrypt* - BigCrypt" -msgstr "*bigcrypt* - BigCrypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:69 -msgid "*crypt16* - Crypt16" -msgstr "*crypt16* - Crypt16" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:70 -#: ../../rst/playbook_guide/playbooks_prompts.rst:93 -msgid "*md5_crypt* - MD5 Crypt" -msgstr "*md5_crypt* - MD5 Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:71 -#: ../../rst/playbook_guide/playbooks_prompts.rst:92 -msgid "*bcrypt* - BCrypt" -msgstr "*bcrypt* - BCrypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:72 -msgid "*sha1_crypt* - SHA-1 Crypt" -msgstr "*sha1_crypt* - SHA-1 Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:73 -msgid "*sun_md5_crypt* - Sun MD5 Crypt" -msgstr "*sun_md5_crypt* - Sun MD5 Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:74 -#: ../../rst/playbook_guide/playbooks_prompts.rst:94 -msgid "*sha256_crypt* - SHA-256 Crypt" -msgstr "*sha256_crypt* - SHA-256 Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:75 -#: ../../rst/playbook_guide/playbooks_prompts.rst:95 -msgid "*sha512_crypt* - SHA-512 Crypt" -msgstr "*sha512_crypt* - SHA-512 Crypt" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:76 -msgid "*apr_md5_crypt* - Apache's MD5-Crypt variant" -msgstr "*apr_md5_crypt* - Apache's MD5-Crypt variant" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:77 -msgid "*phpass* - PHPass' Portable Hash" -msgstr "*phpass* - PHPass' Portable Hash" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:78 -msgid "*pbkdf2_digest* - Generic PBKDF2 Hashes" -msgstr "*pbkdf2_digest* - Generic PBKDF2 Hashes" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:79 -msgid "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash" -msgstr "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:80 -msgid "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash" -msgstr "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:81 -msgid "*scram* - SCRAM Hash" -msgstr "*scram* - SCRAM Hash" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:82 -msgid "*bsd_nthash* - FreeBSD's MCF-compatible nthash encoding" -msgstr "*bsd_nthash* - FreeBSD's MCF 互換の nthash エンコーディング" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:84 -msgid "The only parameters accepted are 'salt' or 'salt_size'. You can use your own salt by defining 'salt', or have one generated automatically using 'salt_size'. By default Ansible generates a salt of size 8." -msgstr "使用できるパラメーターは「salt」または「salt_size」のみです。「salt」を定義して独自のソルトを使用することも、「salt_size」を使用して自動的に生成されるソルトを使用することもできます。デフォルトでは、Ansible はサイズ 8 の salt を生成します。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:90 -msgid "If you do not have Passlib installed, Ansible uses the `crypt `_ library as a fallback. Ansible supports at most four crypt schemes, depending on your platform at most the following crypt schemes are supported:" -msgstr "Passlib がインストールされていない場合、Ansible はフォールバックとして `crypt `_ ライブラリーを使用します。Ansible は最大で 4 つの暗号方式をサポートしていますが、プラットフォームによっては最大で以下の暗号方式をサポートしています。" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:101 -msgid "Allowing special characters in ``vars_prompt`` values" -msgstr "``vars_prompt`` 値での特殊文字の許可" - -#: ../../rst/playbook_guide/playbooks_prompts.rst:103 -msgid "Some special characters, such as ``{`` and ``%`` can create templating errors. If you need to accept special characters, use the ``unsafe`` option:" -msgstr "``{`` や ``%`` などの特殊文字は、テンプレートエラーの作成が可能です。特殊文字を受け入れる必要がある場合は、``unsafe`` オプションを使用します。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:5 -msgid "Python3 in templates" -msgstr "テンプレート内の Python3" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:7 -msgid "Ansible uses Jinja2 to take advantage of Python data types and standard functions in templates and variables. You can use these data types and standard functions to perform a rich set of operations on your data. However, if you use templates, you must be aware of differences between Python versions." -msgstr "Ansible は Jinja2 を使用して、テンプレートや変数に Python のデータ型や標準関数を活用しています。これらのデータ型や標準関数を利用することで、データに対して豊富な操作を行うことができます。ただし、テンプレートを使用する場合は、Python のバージョンによる違いに注意する必要があります。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:11 -msgid "These topics help you design templates that work on both Python2 and Python3. They might also help if you are upgrading from Python2 to Python3. Upgrading within Python2 or Python3 does not usually introduce changes that affect Jinja2 templates." -msgstr "これらのトピックは、Python2 と Python3 の両方で動作するテンプレートをデザインするのに役立ちます。また、Python2 から Python3 へのアップグレードの際にも役立つでしょう。Python2 や Python3 にアップグレードしても、通常は Jinja2 のテンプレートに影響を与えるような変更はありません。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:16 -msgid "Dictionary views" -msgstr "ディクショナリービュー" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:18 -msgid "In Python2, the :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` methods return a list. Jinja2 returns that to Ansible using a string representation that Ansible can turn back into a list." -msgstr "Python2 では、:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` メソッドはリストを返します。Jinja2 はこれを、Ansible がリストに戻すことができる文字列表現で Ansible に返します。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:22 -msgid "In Python3, those methods return a :ref:`dictionary view ` object. The string representation that Jinja2 returns for dictionary views cannot be parsed back into a list by Ansible. It is, however, easy to make this portable by using the :func:`list ` filter whenever using :meth:`dict.keys`, :meth:`dict.values`, or :meth:`dict.items`." -msgstr "Python3 では、これらのメソッドは :ref:`ディクショナリービュー ` オブジェクトを返します。Jinja2 がディクショナリービューに返す文字列表現は、Ansible ではリストに解析し直すことができません。しかし、:meth:`dict.keys`、:meth:`dict.values`、または :meth:`dict.items` を使用する際には必ず :func:`list ` フィルターを使用することで、簡単に移植することができます。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:45 -msgid "dict.iteritems()" -msgstr "dict.iteritems()" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:47 -msgid "Python2 dictionaries have :meth:`~dict.iterkeys`, :meth:`~dict.itervalues`, and :meth:`~dict.iteritems` methods." -msgstr "Python2 ディクショナリーには、:meth:`~dict.iterkeys` メソッド、:meth:`~dict.itervalues` メソッド、および :meth:`~dict.iteritems` メソッドがあります。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:49 -msgid "Python3 dictionaries do not have these methods. Use :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` to make your playbooks and templates compatible with both Python2 and Python3." -msgstr "Python3 ディクショナリーにはこれらのメソッドがありません。:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` を使用して、Playbook およびテンプレートを Python2 と Python3 の両方に対応させてください。" - -#: ../../rst/playbook_guide/playbooks_python_version.rst:66 -msgid "The :ref:`pb-py-compat-dict-views` entry for information on why the :func:`list filter ` is necessary here." -msgstr "ここで :func:`list filter ` が必要な理由は、:ref:`pb-py-compat-dict-views` エントリーを参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:5 -msgid "Re-using Ansible artifacts" -msgstr "Ansible アーティファクトの再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:7 -msgid "You can write a simple playbook in one very large file, and most users learn the one-file approach first. However, breaking your automation work up into smaller files is an excellent way to organize complex sets of tasks and reuse them. Smaller, more distributed artifacts let you re-use the same variables, tasks, and plays in multiple playbooks to address different use cases. You can use distributed artifacts across multiple parent playbooks or even multiple times within one playbook. For example, you might want to update your customer database as part of several different playbooks. If you put all the tasks related to updating your database in a tasks file or a role, you can re-use them in many playbooks while only maintaining them in one place." -msgstr "簡単な Playbook を非常に大きな 1 つのファイルに書くことができるため、ほとんどのユーザーはまず 1 つのファイルを使用した方法を学びます。しかし、自動化作業を小さなファイルに分割することは、複雑なタスクのセットを整理して再利用するための優れた方法です。小さく分散されたアーティファクトを使用して、同じ変数、タスク、プレイを複数の Playbook で再利用し、異なるユースケースに対応することができます。分散されたアーティファクトは、複数の親 Playbook にまたがって使用することも、1 つの Playbook 内で複数回使用することもできます。たとえば、複数の Playbook の一部として顧客データベースを更新する場合があります。データベースの更新に関連するすべてのタスクをタスクファイルにまとめておけば、それらを 1 カ所で管理するだけで、多くの Playbook で再利用することができます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:13 -msgid "Creating re-usable files and roles" -msgstr "再利用可能なファイルおよびロールの作成" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:15 -msgid "Ansible offers four distributed, re-usable artifacts: variables files, task files, playbooks, and roles." -msgstr "Ansible は、変数ファイル、タスクファイル、Playbook、およびロールの 4 つに分散した再利用可能なアーティファクトを提供します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:17 -msgid "A variables file contains only variables." -msgstr "変数ファイルには変数のみが含まれます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:18 -msgid "A task file contains only tasks." -msgstr "タスクファイルにはタスクのみが含まれます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:19 -msgid "A playbook contains at least one play, and may contain variables, tasks, and other content. You can re-use tightly focused playbooks, but you can only re-use them statically, not dynamically." -msgstr "Playbook には、少なくとも 1 つのプレイが含まれており、変数、タスク、その他のコンテンツを含むことができます。厳密に焦点を絞った Playbook は再利用できますが、動的にではなく静的にしか再利用できません。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:20 -msgid "A role contains a set of related tasks, variables, defaults, handlers, and even modules or other plugins in a defined file-tree. Unlike variables files, task files, or playbooks, roles can be easily uploaded and shared through Ansible Galaxy. See :ref:`playbooks_reuse_roles` for details about creating and using roles." -msgstr "ロールには、関連するタスク、変数、デフォルト、ハンドラー、さらにはモジュールや他のプラグインのセットが、定義されたファイルツリーに格納されています。変数ファイル、タスクファイル、Playbook とは異なり、ロールは Ansible Galaxy で簡単にアップロードして共有することができます。ロールの作成と使用の詳細については、「:ref:`playbooks_reuse_roles`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:25 -msgid "Re-using playbooks" -msgstr "Playbook の再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:27 -msgid "You can incorporate multiple playbooks into a main playbook. However, you can only use imports to re-use playbooks. For example:" -msgstr "複数の Playbook をメインの Playbook に組み込むことができますが、インポートのみを使用して Playbook を再使用できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:34 -msgid "Importing incorporates playbooks in other playbooks statically. Ansible runs the plays and tasks in each imported playbook in the order they are listed, just as if they had been defined directly in the main playbook." -msgstr "インポートでは、他の Playbook に静的に Playbook を組み込みます。Ansible は、インポートした各 Playbook 内のプレイやタスクを、メインの Playbook で直接定義した場合と同様に、リストに記載された順に実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:36 -msgid "You can select which playbook you want to import at runtime by defining your imported playbook filename with a variable, then passing the variable with either ``--extra-vars`` or the ``vars`` keyword. For example:" -msgstr "変数でインポートされた Playbook ファイルを定義し、``--extra-vars`` または ``vars`` キーワードで変数を渡すことで、ランタイム時にインポートする Playbook を選択できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:45 -msgid "If you run this playbook with ``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml``, Ansible imports both one_playbook.yml and other_playbook.yml." -msgstr "``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml`` を使用してこの Playbook を実行すると、Ansible は one_playbook.yml と other_playbook.yml の両方をインポートします。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:48 -msgid "When to turn a playbook into a role" -msgstr "Playbook をロールに変換するタイミング" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:50 -msgid "For some use cases, simple playbooks work well. However, starting at a certain level of complexity, roles work better than playbooks. A role lets you store your defaults, handlers, variables, and tasks in separate directories, instead of in a single long document. Roles are easy to share on Ansible Galaxy. For complex use cases, most users find roles easier to read, understand, and maintain than all-in-one playbooks." -msgstr "一部のユースケースでは、簡単な Playbook は適切に機能します。ただし、複雑さがあるレベルを超えると、ロールは Playbook よりも優れています。ロールを使用すると、デフォルト、ハンドラー、変数、タスクを、単一の長いドキュメントではなく、個別のディレクトリーに保存できます。ロールは、Ansible Galaxy で簡単に共有できます。複雑なユースケースでは、ほとんどのユーザーは、オールインワンの Playbook よりもロールの方が読んで理解して維持するのが簡単だと感じています。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:53 -msgid "Re-using files and roles" -msgstr "ファイルおよびロールの再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:55 -msgid "Ansible offers two ways to re-use files and roles in a playbook: dynamic and static." -msgstr "Ansible は、Playbook でファイルとロールを再利用する 2 つの方法 (動的および静的) を提供します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:57 -msgid "For dynamic re-use, add an ``include_*`` task in the tasks section of a play:" -msgstr "動的再利用には、プレイの tasks セクションに ``include_*`` タスクを追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:59 -msgid ":ref:`include_role `" -msgstr ":ref:`include_role `" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:60 -msgid ":ref:`include_tasks `" -msgstr ":ref:`include_tasks `" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:61 -msgid ":ref:`include_vars `" -msgstr ":ref:`include_vars `" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:63 -msgid "For static re-use, add an ``import_*`` task in the tasks section of a play:" -msgstr "静的な再利用の場合は、プレイの tasks セクションに ``import_*`` タスクを追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:65 -msgid ":ref:`import_role `" -msgstr ":ref:`import_role `" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:66 -msgid ":ref:`import_tasks `" -msgstr ":ref:`import_tasks `" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:68 -msgid "Task include and import statements can be used at arbitrary depth." -msgstr "タスクの include 文および import 文は任意の深さで使用できます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:70 -msgid "You can still use the bare :ref:`roles ` keyword at the play level to incorporate a role in a playbook statically. However, the bare :ref:`include ` keyword, once used for both task files and playbook-level includes, is now deprecated." -msgstr "プレイレベルで裸の :ref:`roles ` キーワードを使用して、ロールを静的に Playbook に組み込むことは可能です。しかし、かつてタスクファイルと Playbook レベルのインクルードの両方に使用されていた裸の :ref:`include ` キーワードは、現在では非推奨となっています。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:73 -msgid "Includes: dynamic re-use" -msgstr "インクルード: 動的再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:75 -msgid "Including roles, tasks, or variables adds them to a playbook dynamically. Ansible processes included files and roles as they come up in a playbook, so included tasks can be affected by the results of earlier tasks within the top-level playbook. Included roles and tasks are similar to handlers - they may or may not run, depending on the results of other tasks in the top-level playbook." -msgstr "ロール、タスク、または変数をインクルードすると、Playbook に動的に追加されます。Ansible は、Playbook に同梱されるインクルードファイルやロールを処理するため、インクルードタスクは、トップレベルの Playbook 内の以前のタスクの結果によって影響を受ける可能性があります。インクルードされるロールやタスクは、ハンドラーと同様、トップレベルの Playbook 内の他のタスクの結果に応じて、実行されたりされなかったりします。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:77 -msgid "The primary advantage of using ``include_*`` statements is looping. When a loop is used with an include, the included tasks or role will be executed once for each item in the loop." -msgstr "``include_*`` 文を使用する主な利点はループです。インクルードでループが使用されると、インクルードされたタスクまたはロールがループの各項目に対して 1 回実行されます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:79 -msgid "The filenames for included roles, tasks, and vars are templated before inclusion." -msgstr "含まれるロール、タスク、および変数のファイル名は、包含前にテンプレート化されます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:81 -msgid "You can pass variables into includes. See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence." -msgstr "変数をインクルードに渡すことができます。変数の継承と優先順位の詳細は、「:ref:`ansible_variable_precedence`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:84 -msgid "Imports: static re-use" -msgstr "インポート: 静的再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:86 -msgid "Importing roles, tasks, or playbooks adds them to a playbook statically. Ansible pre-processes imported files and roles before it runs any tasks in a playbook, so imported content is never affected by other tasks within the top-level playbook." -msgstr "ロール、タスク、または Playbook をインポートすると、それらが静的に Playbook に追加されます。Ansible は、インポートされたファイルやロールを Playbook 内のタスクを実行する前に前処理するため、インポートされたコンテンツがトップレベルの Playbook 内の他のタスクの影響を受けることはありません。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:88 -msgid "The filenames for imported roles and tasks support templating, but the variables must be available when Ansible is pre-processing the imports. This can be done with the ``vars`` keyword or by using ``--extra-vars``." -msgstr "インポートしたロールおよびタスクのファイル名はテンプレートをサポートしますが、Ansible がインポートの事前処理時に変数が利用できるようにする必要があります。これは、``vars`` キーワードまたは ``--extra-vars`` を使用して実行できます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:90 -msgid "You can pass variables to imports. You must pass variables if you want to run an imported file more than once in a playbook. For example:" -msgstr "インポートには変数を渡すことができます。インポートしたファイルを 1 つの Playbook で複数回実行する場合は、変数を渡す必要があります。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:107 -msgid "See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence." -msgstr "変数の継承および優先順位に関する詳細は、「:ref:`ansible_variable_precedence`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:112 -msgid "Comparing includes and imports: dynamic and static re-use" -msgstr "インクルードとインポートの比較: 動的再利用および静的再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:114 -msgid "Each approach to re-using distributed Ansible artifacts has advantages and limitations. You may choose dynamic re-use for some playbooks and static re-use for others. Although you can use both dynamic and static re-use in a single playbook, it is best to select one approach per playbook. Mixing static and dynamic re-use can introduce difficult-to-diagnose bugs into your playbooks. This table summarizes the main differences so you can choose the best approach for each playbook you create." -msgstr "分散した Ansible のアーティファクトを再利用する方法には、それぞれ利点と制限があります。一部の Playbook では動的再利用を行い、他の Playbook では静的再利用を行うことができます。1 つの Playbook で動的再利用と静的再利用の両方を使用することもできますが、Playbook ごとに 1 つのアプローチを選択するのが最善です。静的再利用と動的再利用を混在させると、診断が困難なバグが Playbook に発生する可能性があります。この表で主な違いをまとめています。作成する Playbook ごとに最適な方法を選択してください。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:120 -msgid "Include_*" -msgstr "Include_*" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:120 -msgid "Import_*" -msgstr "Import_*" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:122 -msgid "Type of re-use" -msgstr "再利用の種類" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:122 -msgid "Dynamic" -msgstr "動的" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:122 -msgid "Static" -msgstr "静的" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:124 -msgid "When processed" -msgstr "処理時" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:124 -msgid "At runtime, when encountered" -msgstr "ランタイム時に (発生した場合)" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:124 -msgid "Pre-processed during playbook parsing" -msgstr "Playbook の解析中に事前処理" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:126 -msgid "Task or play" -msgstr "タスクまたはプレイ" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:126 -msgid "All includes are tasks" -msgstr "インクルードはすべてタスク" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:126 -msgid "``import_playbook`` cannot be a task" -msgstr "``import_playbook`` タスクにすることはできない" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:128 -msgid "Task options" -msgstr "タスクオプション" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:128 -msgid "Apply only to include task itself" -msgstr "タスク自体を含める場合にのみ適用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:128 -msgid "Apply to all child tasks in import" -msgstr "インポート中のすべての子タスクに適用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:130 -msgid "Calling from loops" -msgstr "ループからの呼び出し" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:130 -msgid "Executed once for each loop item" -msgstr "各ループ項目に対して 1 回実行" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:130 -msgid "Cannot be used in a loop" -msgstr "ループでは使用できない" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:132 -msgid "Using ``--list-tags``" -msgstr "``--list-tags`` の使用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:132 -msgid "Tags within includes not listed" -msgstr "掲載されていないインクルード内のタグ" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:132 -msgid "All tags appear with ``--list-tags``" -msgstr "すべてのタグが ``--list-tags`` で表示" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:134 -msgid "Using ``--list-tasks``" -msgstr "``--list-tasks`` の使用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:134 -msgid "Tasks within includes not listed" -msgstr "リストにないインクルード内のタスク" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:134 -msgid "All tasks appear with ``--list-tasks``" -msgstr "すべてのタスクが ``--list-tasks`` で表示" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:136 -msgid "Cannot trigger handlers within includes" -msgstr "インクルード内でハンドラーをトリガーできない" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:136 -msgid "Can trigger individual imported handlers" -msgstr "インポートした個別のハンドラーをトリガーできる" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:138 -msgid "Using ``--start-at-task``" -msgstr "``--start-at-task`` の使用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:138 -msgid "Cannot start at tasks within includes" -msgstr "インクルード内のタスクで開始できない" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:138 -msgid "Can start at imported tasks" -msgstr "インポートされたタスクから始められる" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:140 -msgid "Using inventory variables" -msgstr "インベントリー変数の使用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:140 -msgid "Can ``include_*: {{ inventory_var }}``" -msgstr "``include_*: {{ inventory_var }}`` が使用できる" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:140 -msgid "Cannot ``import_*: {{ inventory_var }}``" -msgstr "``import_*: {{ inventory_var }}`` が使用できない" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:142 -msgid "With playbooks" -msgstr "Playbook の使用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:142 -msgid "No ``include_playbook``" -msgstr "``include_playbook`` なし" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:142 -msgid "Can import full playbooks" -msgstr "完全な Playbook をインポートできる" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:144 -msgid "With variables files" -msgstr "変数ファイルの使用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:144 -msgid "Can include variables files" -msgstr "変数ファイルを含めることができる" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:144 -msgid "Use ``vars_files:`` to import variables" -msgstr "``vars_files:`` を使用して変数をインポート" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:150 -msgid "There are also big differences in resource consumption and performance, imports are quite lean and fast, while includes require a lot of management and accounting." -msgstr "また、リソースの消費やパフォーマンスに大きな違いがあり、インポートは非常に柔軟で高速ですが、インクルードには多くの管理と会計が必要になります。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:154 -msgid "Re-using tasks as handlers" -msgstr "タスクをハンドラーとして再利用" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:156 -msgid "You can also use includes and imports in the :ref:`handlers` section of a playbook. For instance, if you want to define how to restart Apache, you only have to do that once for all of your playbooks. You might make a ``restarts.yml`` file that looks like:" -msgstr "Playbook の :ref:`handlers` セクションでインクルードおよびインポートを使用することもできます。たとえば、Apache の再起動方法を定義する場合は、すべての Playbook に対して一度だけ設定する必要があります。``restarts.yml`` ファイルを以下のように行うことができます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:171 -msgid "You can trigger handlers from either an import or an include, but the procedure is different for each method of re-use. If you include the file, you must notify the include itself, which triggers all the tasks in ``restarts.yml``. If you import the file, you must notify the individual task(s) within ``restarts.yml``. You can mix direct tasks and handlers with included or imported tasks and handlers." -msgstr "ハンドラーはインポートとインクルードのどちらからでも起動できますが、その手順は再利用の方法ごとに異なります。ファイルをインクルードする場合は、インクルード自体を通知する必要があり、これにより ``restarts.yml`` のすべてのタスクが発生します。ファイルをインポートする場合は、``restarts.yml`` 内の個々のタスクを通知する必要があります。直接的なタスクやハンドラーと、インクルードまたはインポートされたタスクやハンドラーを混在させることができます。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:174 -msgid "Triggering included (dynamic) handlers" -msgstr "インクルード (動的) ハンドラーのトリガー" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:176 -msgid "Includes are executed at run-time, so the name of the include exists during play execution, but the included tasks do not exist until the include itself is triggered. To use the ``Restart apache`` task with dynamic re-use, refer to the name of the include itself. This approach triggers all tasks in the included file as handlers. For example, with the task file shown above:" -msgstr "インクルードはランタイムに実行されるため、インクルードの名前はプレイの実行中に存在しますが、インクルードされたタスクはインクルード自体がトリガーされるまで存在しません。``Restart apache`` タスクを動的再利用で使用するには、インクルード自体の名前を参照します。この方法では、インクルードファイル内のすべてのタスクがハンドラーとしてトリガーされます。たとえば、上に示したタスクファイルでは、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:190 -msgid "Triggering imported (static) handlers" -msgstr "インポートされた (静的) ハンドラーのトリガー" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:192 -msgid "Imports are processed before the play begins, so the name of the import no longer exists during play execution, but the names of the individual imported tasks do exist. To use the ``Restart apache`` task with static re-use, refer to the name of each task or tasks within the imported file. For example, with the task file shown above:" -msgstr "インポートは再生開始前に処理されるため、インポートの名前は再生実行中には存在しませんが、インポートされた各タスクの名前は存在します。``Restart apache`` タスクを静的に再利用して使用するには、インポートされたファイル内の各タスクの名前を参照する必要があります。たとえば、上述のタスクファイルであれば、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:209 -msgid ":ref:`utilities_modules`" -msgstr ":ref:`utilities_modules`" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:210 -msgid "Documentation of the ``include*`` and ``import*`` modules discussed here." -msgstr "ここで説明する ``include*`` モジュールおよび ``import*`` モジュールに関するドキュメント" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:212 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:597 -#: ../../rst/playbook_guide/playbooks_roles.rst:16 -msgid "Review the basic Playbook language features" -msgstr "基本的な Playbook 言語機能の確認" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:214 -msgid "All about variables in playbooks" -msgstr "Playbook の変数の詳細のすべて" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:216 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:603 -msgid "Conditionals in playbooks" -msgstr "Playbook の条件" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:218 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:605 -msgid "Loops in playbooks" -msgstr "Playbook のループ" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:221 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:592 -#: ../../rst/playbook_guide/playbooks_roles.rst:13 -msgid ":ref:`ansible_galaxy`" -msgstr ":ref:`ansible_galaxy`" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:222 -#: ../../rst/playbook_guide/playbooks_roles.rst:14 -msgid "How to share roles on galaxy, role management" -msgstr "Galaxy (ロール管理) におけるロールの共有方法" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:223 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:612 -msgid "`GitHub Ansible examples `_" -msgstr "`GitHub Ansible examples `_" - -#: ../../rst/playbook_guide/playbooks_reuse.rst:224 -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:613 -msgid "Complete playbook files from the GitHub project source" -msgstr "Github プロジェクトソースの完全な Playbook ファイル" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:5 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:7 -msgid "Roles let you automatically load related vars, files, tasks, handlers, and other Ansible artifacts based on a known file structure. After you group your content in roles, you can easily reuse them and share them with other users." -msgstr "ロールを使用すると、既知のファイル構造に基づいて、関連の変数、ファイル、タスク、ハンドラー、およびその他の Ansible アーティファクトを自動的に読み込むことができます。ロール内のコンテンツをグループ化した後、簡単に再利用でき、他のユーザーと共有できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:13 -msgid "Role directory structure" -msgstr "ロールのディレクトリー構造" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:15 -msgid "An Ansible role has a defined directory structure with eight main standard directories. You must include at least one of these directories in each role. You can omit any directories the role does not use. For example:" -msgstr "Ansible ロールには、8 つの主要な標準ディレクトリーを持つ定義されたディレクトリー構造があります。各ロールには、ディレクトリーを少なくとも 1 つ含める必要があります。ロールが使用されないディレクトリーは除外できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:26 -msgid "By default Ansible will look in each directory within a role for a ``main.yml`` file for relevant content (also ``main.yaml`` and ``main``):" -msgstr "デフォルトでは、Ansible はロール内の各ディレクトリーで、関連するコンテンツ (``main.yaml`` および ``main``) について ``main.yml`` ファイルを検索します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:28 -msgid "``tasks/main.yml`` - the main list of tasks that the role executes." -msgstr "``tasks/main.yml`` - ロールが実行するタスクの主なリスト。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:29 -msgid "``handlers/main.yml`` - handlers, which may be used within or outside this role." -msgstr "``handlers/main.yml`` - このロール内外で使用できるハンドラー。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:30 -msgid "``library/my_module.py`` - modules, which may be used within this role (see :ref:`embedding_modules_and_plugins_in_roles` for more information)." -msgstr "``library/my_module.py`` - このロール内で使用できるモジュール (詳細は「:ref:`embedding_modules_and_plugins_in_roles`」を参照)。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:31 -msgid "``defaults/main.yml`` - default variables for the role (see :ref:`playbooks_variables` for more information). These variables have the lowest priority of any variables available, and can be easily overridden by any other variable, including inventory variables." -msgstr "``defaults/main.yml`` - ロールのデフォルト変数 (詳細は「:ref:`playbooks_variables`」を参照)。これらの変数には、利用可能な変数の中で一番低い優先順位があり、インベントリー変数など、他の変数で簡単に上書きできます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:32 -msgid "``vars/main.yml`` - other variables for the role (see :ref:`playbooks_variables` for more information)." -msgstr "``vars/main.yml`` - ロールの他の変数 (詳細は :ref:`playbooks_variables` を参照)。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:33 -msgid "``files/main.yml`` - files that the role deploys." -msgstr "``files/main.yml`` - ロールがデプロイするファイル。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:34 -msgid "``templates/main.yml`` - templates that the role deploys." -msgstr "``templates/main.yml`` - ロールがデプロイするテンプレート。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:35 -msgid "``meta/main.yml`` - metadata for the role, including role dependencies and optional Galaxy metadata such as platforms supported." -msgstr "``meta/main.yml`` - ロールの依存関係やサポートされているプラットフォームなどの任意の Galaxy メタデータを含む、ロールのメタデータ。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:37 -msgid "You can add other YAML files in some directories. For example, you can place platform-specific tasks in separate files and refer to them in the ``tasks/main.yml`` file:" -msgstr "他の YAML ファイルを一部のディレクトリーに追加できます。たとえば、プラットフォーム固有のタスクを別々のファイルに配置し、それらを ``tasks/main.yml`` ファイルで参照できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:62 -msgid "Roles may also include modules and other plugin types in a directory called ``library``. For more information, please refer to :ref:`embedding_modules_and_plugins_in_roles` below." -msgstr "ロールには、``library`` と呼ばれるディレクトリーにモジュールおよびその他のプラグインタイプが含まれる場合があります。詳細は、以下の「:ref:`embedding_modules_and_plugins_in_roles`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:67 -msgid "Storing and finding roles" -msgstr "ロールの保存および検索" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:69 -msgid "By default, Ansible looks for roles in the following locations:" -msgstr "デフォルトでは、Ansible は以下の場所でロールを検索します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:71 -msgid "in collections, if you are using them" -msgstr "コレクションでそれらを使用している場合" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:72 -msgid "in a directory called ``roles/``, relative to the playbook file" -msgstr "``roles/`` という名前のディレクトリー (Playbook ファイルへの相対パス) で" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:73 -msgid "in the configured :ref:`roles_path `. The default search path is ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``." -msgstr "設定された :ref:`roles_path ` では、デフォルトの検索パスは ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles`` です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:74 -msgid "in the directory where the playbook file is located" -msgstr "Playbook ファイルが配置されているディレクトリーで" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:76 -msgid "If you store your roles in a different location, set the :ref:`roles_path ` configuration option so Ansible can find your roles. Checking shared roles into a single location makes them easier to use in multiple playbooks. See :ref:`intro_configuration` for details about managing settings in ansible.cfg." -msgstr "ロールを別の場所に保存する場合は、Ansible がロールを見つけることができるように、:ref:`roles_path ` 設定オプションを設定します。共有ロールを 1 つの場所にチェックインすることで、複数の Playbook で簡単に使用できます。ansible.cfg の設定に関する詳細は、「:ref:`intro_configuration`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:78 -msgid "Alternatively, you can call a role with a fully qualified path:" -msgstr "または、完全修飾パスでロールを呼び出すことができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:88 -msgid "Using roles" -msgstr "ロールの使用" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:90 -msgid "You can use roles in three ways:" -msgstr "以下の 3 つの方法でロールを使用できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:92 -msgid "at the play level with the ``roles`` option: This is the classic way of using roles in a play." -msgstr "``roles`` オプションを使用してプレイレベルで: プレイでロールを使用する従来の方式です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:93 -msgid "at the tasks level with ``include_role``: You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``." -msgstr "``include_role`` を使用してタスクレベルで: ``include_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを動的に再利用できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:94 -msgid "at the tasks level with ``import_role``: You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``." -msgstr "``import_role`` を使用してタスクレベルで: ``import_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを静的に再利用できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:99 -msgid "Using roles at the play level" -msgstr "プレイレベルでのロールの使用" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:101 -msgid "The classic (original) way to use roles is with the ``roles`` option for a given play:" -msgstr "ロールを使用する従来の (元の) 方法は、特定のプレイの ``roles`` オプションを使用して行います。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:111 -msgid "When you use the ``roles`` option at the play level, for each role 'x':" -msgstr "プレイレベルで ``roles`` オプションを使用する場合は、各ロール「x」に対して以下のように設定します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:113 -msgid "If roles/x/tasks/main.yml exists, Ansible adds the tasks in that file to the play." -msgstr "roles/x/tasks/main.yml が存在する場合、Ansible はそのファイルのタスクをプレイに追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:114 -msgid "If roles/x/handlers/main.yml exists, Ansible adds the handlers in that file to the play." -msgstr "roles/x/handlers/main.yml が存在する場合、Ansible はそのファイルのハンドラーをプレイに追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:115 -msgid "If roles/x/vars/main.yml exists, Ansible adds the variables in that file to the play." -msgstr "roles/x/vars/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:116 -msgid "If roles/x/defaults/main.yml exists, Ansible adds the variables in that file to the play." -msgstr "roles/x/defaults/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:117 -msgid "If roles/x/meta/main.yml exists, Ansible adds any role dependencies in that file to the list of roles." -msgstr "roles/x/meta/main.yml が存在する場合、Ansible はそのファイル内のすべてのロールの依存関係をロールのリストに追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:118 -msgid "Any copy, script, template or include tasks (in the role) can reference files in roles/x/{files,templates,tasks}/ (dir depends on task) without having to path them relatively or absolutely." -msgstr "コピー、スクリプト、テンプレート、またはインクルードタスク (ロール内) は、相対パスや絶対パスを必要とせずに roles/x/{files,templates,tasks}/ (ディレクトリーはタスクに依存します) のファイルを参照できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:120 -msgid "When you use the ``roles`` option at the play level, Ansible treats the roles as static imports and processes them during playbook parsing. Ansible executes each play in this order:" -msgstr "プレイレベルで ``roles`` オプションを使用すると、Ansible はロールを静的インポートとして処理し、Playbook の解析時に処理します。Ansible は以下の順序でそれぞれのプレイを実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:122 -msgid "Any ``pre_tasks`` defined in the play." -msgstr "プレイに定義されているすべての ``pre_tasks``。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:123 -msgid "Any handlers triggered by pre_tasks." -msgstr "ハンドラーは、pre_tasks により誘発されます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:124 -msgid "Each role listed in ``roles:``, in the order listed. Any role dependencies defined in the role's ``meta/main.yml`` run first, subject to tag filtering and conditionals. See :ref:`role_dependencies` for more details." -msgstr "``roles:`` に一覧表示される順序で、各ロールがリストされます。ロールの ``meta/main.yml`` で定義されたロール依存関係は、タグのフィルタリングおよび条件に基づいて最初に実行されます。詳細は、「:ref:`role_dependencies`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:125 -msgid "Any ``tasks`` defined in the play." -msgstr "プレイに定義されているすべての ``tasks``。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:126 -msgid "Any handlers triggered by the roles or tasks." -msgstr "ロールやタスクによってトリガーされるすべてのハンドラー。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:127 -msgid "Any ``post_tasks`` defined in the play." -msgstr "プレイに定義されているすべての ``post_tasks``。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:128 -msgid "Any handlers triggered by post_tasks." -msgstr "ハンドラーは、post_tasks により誘発されます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:131 -msgid "If using tags with tasks in a role, be sure to also tag your pre_tasks, post_tasks, and role dependencies and pass those along as well, especially if the pre/post tasks and role dependencies are used for monitoring outage window control or load balancing. See :ref:`tags` for details on adding and using tags." -msgstr "ロール内のタスクにタグを使用する場合は、pre_tasks、post_tasks、およびロールの依存関係にもタグを付けて、それらも渡すようにしてください。特に、事前または事後のタスクおよびロールの依存関係が、停止時のウィンドウ制御や負荷分散の監視に使用されている場合は、そのようにしてください。タグの追加と使用の詳細は、「:ref:`tags`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:133 -msgid "You can pass other keywords to the ``roles`` option:" -msgstr "他のキーワードを ``roles`` オプションに渡すことができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:152 -msgid "When you add a tag to the ``role`` option, Ansible applies the tag to ALL tasks within the role." -msgstr "タグを ``role`` オプションに追加すると、Ansible はタグをロール内のすべてのタスクに適用します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:154 -msgid "When using ``vars:`` within the ``roles:`` section of a playbook, the variables are added to the play variables, making them available to all tasks within the play before and after the role. This behavior can be changed by :ref:`DEFAULT_PRIVATE_ROLE_VARS`." -msgstr "Playbook の ``roles:`` セクションで ``vars:`` を使用すると、変数がプレイ変数に追加され、ロールの前後にプレイ内のすべてのタスクで利用できるようになります。この動作は :ref:`DEFAULT_PRIVATE_ROLE_VARS` で変更できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:157 -msgid "Including roles: dynamic reuse" -msgstr "ロールの追加: 動的な再利用" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:159 -msgid "You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. While roles added in a ``roles`` section run before any other tasks in a play, included roles run in the order they are defined. If there are other tasks before an ``include_role`` task, the other tasks will run first." -msgstr "``include_role`` を使用すると、プレイの ``tasks`` セクション内の任意の場所でロールを動的に再利用することができます。``roles`` セクションで追加されたロールはプレイ内の他のタスクよりも先に実行されますが、含まれるロールは定義された順に実行されます。``include_role`` のタスクの前に他のタスクがある場合は、他のタスクが先に実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:161 -msgid "To include a role:" -msgstr "ロールを指定するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:180 -msgid "You can pass other keywords, including variables and tags, when including roles:" -msgstr "ロールを含める際には、変数やタグなど、他のキーワードを渡すことができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:196 -msgid "When you add a :ref:`tag ` to an ``include_role`` task, Ansible applies the tag `only` to the include itself. This means you can pass ``--tags`` to run only selected tasks from the role, if those tasks themselves have the same tag as the include statement. See :ref:`selective_reuse` for details." -msgstr "``include_role`` タスクに :ref:`tag ` を追加すると、Ansible はインクルード自体に `only` というタグを適用します。つまり、``--tags`` を渡して、ロールから選択されたタスクのみを実行することができます。ただし、それらのタスク自体が include 文と同じタグを持っている場合に限ります。詳細は、「:ref:`selective_reuse`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:198 -msgid "You can conditionally include a role:" -msgstr "ロールを条件付きで含めることができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:211 -msgid "Importing roles: static reuse" -msgstr "ロールのインポート: 静的再利用" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:213 -msgid "You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. The behavior is the same as using the ``roles`` keyword. For example:" -msgstr "``import_role`` を使用してプレイの ``tasks`` セクションの任意の場所に、ロールを静的に再利用できます。動作は、``roles`` キーワードの使用と同じです。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:232 -msgid "You can pass other keywords, including variables and tags, when importing roles:" -msgstr "ロールをインポートする際には、変数やタグなど、他のキーワードを渡すことができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:247 -msgid "When you add a tag to an ``import_role`` statement, Ansible applies the tag to `all` tasks within the role. See :ref:`tag_inheritance` for details." -msgstr "タグを ``import_role`` 文に追加すると、Ansible はタグをロール内の `all` タスクに適用します。詳細は、「:ref:`tag_inheritance`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:252 -msgid "Role argument validation" -msgstr "ロール引数を検証する" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:254 -msgid "Beginning with version 2.11, you may choose to enable role argument validation based on an argument specification. This specification is defined in the ``meta/argument_specs.yml`` file (or with the ``.yaml`` file extension). When this argument specification is defined, a new task is inserted at the beginning of role execution that will validate the parameters supplied for the role against the specification. If the parameters fail validation, the role will fail execution." -msgstr "バージョン 2.11 以降では、引数の仕様に基づいてロールの引数検証を有効にすることができます。この仕様は、``meta/argument_specs.yml`` ファイル (または ``.yaml`` ファイル拡張子) で定義されます。この引数仕様が定義されると、ロール実行の最初に新しいタスクが挿入され、仕様に対して、ロールに指定したパラメーターを検証します。パラメーターの検証に失敗した場合は、ロールの実行が失敗します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:262 -msgid "Ansible also supports role specifications defined in the role ``meta/main.yml`` file, as well. However, any role that defines the specs within this file will not work on versions below 2.11. For this reason, we recommend using the ``meta/argument_specs.yml`` file to maintain backward compatibility." -msgstr "Ansible は、ロールの ``meta/main.yml`` ファイルで定義されるロールの仕様もサポートしますが、このファイル内の仕様を定義するロールは 2.11 未満のバージョンでは動作しません。そのため、``meta/argument_specs.yml`` ファイルを使用して後方互換性を維持することが推奨されます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:268 -msgid "When role argument validation is used on a role that has defined :ref:`dependencies `, then validation on those dependencies will run before the dependent role, even if argument validation fails for the dependent role." -msgstr ":ref:`dependencies ` を定義しているロールにロールの引数検証が使用されている場合は、依存するロールの引数検証が失敗しても、それらの依存関係の検証は依存するロールの前に実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:273 -msgid "Specification format" -msgstr "仕様の形式" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:275 -msgid "The role argument specification must be defined in a top-level ``argument_specs`` block within the role ``meta/argument_specs.yml`` file. All fields are lower-case." -msgstr "ロール引数の指定は、ロール ``meta/argument_specs.yml`` ファイルの上位の ``argument_specs`` ブロックで定義する必要があります。すべてのフィールドは小文字になります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "entry-point-name" -msgstr "entry-point-name" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:280 -msgid "The name of the role entry point." -msgstr "ロールエントリーポイントの名前。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:281 -msgid "This should be ``main`` in the case of an unspecified entry point." -msgstr "これは、エントリーポイントが未指定の場合は ``main`` である必要があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:282 -msgid "This will be the base name of the tasks file to execute, with no ``.yml`` or ``.yaml`` file extension." -msgstr "これは、ファイル拡張子 ``.yml`` または ``.yaml`` のない、実行するタスクファイルのベース名です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "short_description" -msgstr "short_description" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:286 -msgid "A short, one-line description of the entry point." -msgstr "エントリーポイントの 1 行の短い説明。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:287 -msgid "The ``short_description`` is displayed by ``ansible-doc -t role -l``." -msgstr "``short_description`` は、``ansible-doc -t role -l`` に表示されます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "description" -msgstr "description" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:291 -msgid "A longer description that may contain multiple lines." -msgstr "複数の行が含まれる可能性のある長い説明。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "author" -msgstr "author" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:295 -msgid "Name of the entry point authors." -msgstr "エントリーポイント作成者の名前。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:296 -msgid "Use a multi-line list if there is more than one author." -msgstr "作成者が複数になる場合は、複数行のリストを使用します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "options" -msgstr "options" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:300 -msgid "Options are often called \"parameters\" or \"arguments\". This section defines those options." -msgstr "オプションは、しばしば「パラメーター」や「引数」と呼ばれます。このセクションでは、それらのオプションを定義します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:301 -msgid "For each role option (argument), you may include:" -msgstr "各ロールオプション (引数) に以下を含めることができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "option-name" -msgstr "option-name" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:305 -msgid "The name of the option/argument." -msgstr "オプション/引数の名前。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:309 -msgid "Detailed explanation of what this option does. It should be written in full sentences." -msgstr "このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "type" -msgstr "タイプ" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:313 -msgid "The data type of the option. See :ref:`Argument spec ` for allowed values for ``type``. Default is ``str``." -msgstr "オプションのデータタイプ。``type`` に設定可能な値については、:ref:`引数の仕様 ` を参照してください。デフォルトは ``str`` です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:314 -msgid "If an option is of type ``list``, ``elements`` should be specified." -msgstr "オプションが ``list`` タイプの場合は、``elements`` を指定する必要があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "required" -msgstr "必須" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:318 -msgid "Only needed if ``true``." -msgstr "``true`` の場合にのみ必要です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:319 -msgid "If missing, the option is not required." -msgstr "見つからない場合、そのオプションは必要ありません。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "default" -msgstr "default" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:323 -msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)." -msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:324 -msgid "Ensure that the default value in the docs matches the default value in the code. The actual default for the role variable will always come from ``defaults/main.yml``." -msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認します。ロール変数の実際のデフォルトは常に ``defaults/main.yml`` から取得されます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:326 -msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions." -msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:327 -msgid "If the option is a boolean value, you should use `true/false` if you want to be compatible with `ansible-lint`." -msgstr "オプションがブール値である場合、`ansible-lint` と互換性を持たせたい場合は、`true/false` を使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "choices" -msgstr "choices" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:331 -msgid "List of option values." -msgstr "オプション値のリスト。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:332 -msgid "Should be absent if empty." -msgstr "空欄の場合は指定なしになります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst -msgid "elements" -msgstr "elements" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:336 -msgid "Specifies the data type for list elements when type is ``list``." -msgstr "タイプが ``list`` の場合に、リスト要素のデータ型を指定します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:340 -msgid "If this option takes a dict or list of dicts, you can define the structure here." -msgstr "このオプションがディクショナリーまたはディクショナリーのリストを取る場合は、ここで構造を定義できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:343 -msgid "Sample specification" -msgstr "サンプル仕様" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:378 -msgid "Running a role multiple times in one play" -msgstr "1 つのプレイでロールを複数回実行する" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:380 -msgid "Ansible only executes each role once in a play, even if you define it multiple times, unless the parameters defined on the role are different for each definition. For example, Ansible only runs the role ``foo`` once in a play like this:" -msgstr "Ansible は、ロールに定義されているパラメーターが定義ごとに異なる場合を除き、各ロールを複数回定義してもプレイでは 1 回しか実行しません。たとえば、Ansible は次のようなプレイで ``foo`` というロールを 1 回だけ実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:391 -msgid "You have two options to force Ansible to run a role more than once." -msgstr "Ansible が複数のロールを強制的に実行するオプションは 2 つあります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:394 -msgid "Passing different parameters" -msgstr "異なるパラメーターを渡す" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:396 -msgid "If you pass different parameters in each role definition, Ansible runs the role more than once. Providing different variable values is not the same as passing different role parameters. You must use the ``roles`` keyword for this behavior, since ``import_role`` and ``include_role`` do not accept role parameters." -msgstr "各ロール定義で異なるパラメーターを渡すと、Ansible はそのロールを複数回実行します。異なる変数値を提供することは、異なるロールパラメーターを渡すこととは異なります。``import_role`` および ``include_role`` はロールパラメーターを受け入れないため、この動作には ``roles`` キーワードを使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:398 -msgid "This play runs the ``foo`` role twice:" -msgstr "このプレイでは、``foo`` ロールが 2 回実行されます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:408 -msgid "This syntax also runs the ``foo`` role twice;" -msgstr "この構文は、``foo`` ロールを 2 回実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:420 -msgid "In these examples, Ansible runs ``foo`` twice because each role definition has different parameters." -msgstr "これらの例では、各ロール定義のパラメーターが異なるため、Ansible は ``foo`` を 2 回実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:423 -msgid "Using ``allow_duplicates: true``" -msgstr "``allow_duplicates: true`` の使用" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:425 -msgid "Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role:" -msgstr "ロールの ``meta/main.yml`` ファイルに ``allow_duplicates: true`` を追加します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:440 -msgid "In this example, Ansible runs ``foo`` twice because we have explicitly enabled it to do so." -msgstr "この例では、Ansible が ``foo`` を2回実行していますが、これは明示的に実行できるようにしたためです。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:445 -msgid "Using role dependencies" -msgstr "ロール依存関係の使用" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:447 -msgid "Role dependencies let you automatically pull in other roles when using a role." -msgstr "ロールの依存関係により、ロールを使用する際に他のロールを自動的にプルできます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:449 -msgid "Role dependencies are prerequisites, not true dependencies. The roles do not have a parent/child relationship. Ansible loads all listed roles, runs the roles listed under ``dependencies`` first, then runs the role that lists them. The play object is the parent of all roles, including roles called by a ``dependencies`` list." -msgstr "ロールの依存関係は前提条件であり、真の依存関係ではありません。また、ロールは親子関係を持ちません。Ansible はリストアップされたすべてのロールを読み込み、``dependencies`` にリストアップされたロールを最初に実行し、次にそれらをリストアップしたロールを実行します。play オブジェクトは、``dependencies`` のリストで呼び出されるロールを含め、すべてのロールの親です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:451 -msgid "Role dependencies are stored in the ``meta/main.yml`` file within the role directory. This file should contain a list of roles and parameters to insert before the specified role. For example:" -msgstr "ロールの依存関係は、ロールディレクトリー内の ``meta/main.yml`` ファイルに保存されます。このファイルには、指定されたロールの前に挿入するロールとパラメーターの一覧を含める必要があります。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:469 -msgid "Ansible always executes roles listed in ``dependencies`` before the role that lists them. Ansible executes this pattern recursively when you use the ``roles`` keyword. For example, if you list role ``foo`` under ``roles:``, role ``foo`` lists role ``bar`` under ``dependencies`` in its meta/main.yml file, and role ``bar`` lists role ``baz`` under ``dependencies`` in its meta/main.yml, Ansible executes ``baz``, then ``bar``, then ``foo``." -msgstr "Ansible は、``dependencies`` に記載されているロールを、それを記載しているロールの前に常に実行します。``roles`` キーワードを使用すると、Ansible はこのパターンを再帰的に実行します。たとえば、ロール ``foo`` を ``roles:`` の下にリストし、ロール ``foo`` が meta/main.yml ファイルの ``dependencies`` の下にロール ``bar`` をリストし、ロール ``bar`` が meta/main.yml の ``dependencies`` の下にロール ``baz`` をリストしている場合、Ansibleは ``baz``、``bar``、``foo`` の順に実行します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:472 -msgid "Running role dependencies multiple times in one play" -msgstr "1 つのプレイでロールの依存関係を複数回実行する" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:474 -msgid "Ansible treats duplicate role dependencies like duplicate roles listed under ``roles:``: Ansible only executes role dependencies once, even if defined multiple times, unless the parameters, tags, or when clause defined on the role are different for each definition. If two roles in a play both list a third role as a dependency, Ansible only runs that role dependency once, unless you pass different parameters, tags, when clause, or use ``allow_duplicates: true`` in the role you want to run multiple times. See :ref:`Galaxy role dependencies ` for more details." -msgstr "Ansible は、``roles:`` に記載されている重複したロールのように、重複したロールの依存関係を扱います。Ansible は、ロールに定義されたパラメーター、タグ、または when 句が定義ごとに異なる場合を除き、複数回定義されていてもロールの依存関係を 1 回のみ実行します。プレイ内の 2 つのロールが両方とも依存関係として 3 番目のロールをリストしている場合、Ansible は、複数回実行するロールで異なるパラメーター、タグ、when 句を渡すか、``allow_duplicates: true`` を使用しない限り、そのロールの依存関係を 1 回のみ実行します。詳細は、「:ref:`Galaxy role dependencies `」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:478 -msgid "Role deduplication does not consult the invocation signature of parent roles. Additionally, when using ``vars:`` instead of role params, there is a side effect of changing variable scoping. Using ``vars:`` results in those variables being scoped at the play level. In the below example, using ``vars:`` would cause ``n`` to be defined as ``4`` through the entire play, including roles called before it." -msgstr "ロールの重複排除は、親ロールの呼び出し署名を参照しません。さらに、ロールパラメーターの代わりに ``vars:`` を使用する場合は、変数のスコープを変更するという副作用があります。``vars:`` を使用すると、それらの変数がプレイレベルで対象となります。以下の例では、``vars:`` を使用すると、それ以前に呼び出されたロールを含め、プレー全体を通して ``n`` が ``4`` として定義されることになります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:480 -msgid "In addition to the above, users should be aware that role de-duplication occurs before variable evaluation. This means that :term:`Lazy Evaluation` may make seemingly different role invocations equivalently the same, preventing the role from running more than once." -msgstr "上記に加えて、ユーザーは変数評価の前にロールの重複排除が行われることに注意する必要があります。つまり、:term:`Lazy Evaluation` は、一見異なるロールの呼び出しを等価にして、ロールが複数回実行されるのを防ぐことができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:483 -msgid "For example, a role named ``car`` depends on a role named ``wheel`` as follows:" -msgstr "たとえば、``car`` という名前のロールは、以下のように ``wheel`` という名前のロールに依存します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:498 -msgid "And the ``wheel`` role depends on two roles: ``tire`` and ``brake``. The ``meta/main.yml`` for wheel would then contain the following:" -msgstr "そして、``wheel`` のロールは、``tire`` と ``brake`` の 2 つのロールに依存します。このため、wheel 用の ``meta/main.yml`` は以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:507 -msgid "And the ``meta/main.yml`` for ``tire`` and ``brake`` would contain the following:" -msgstr "そして、「``tire``」および「``brake``」の「``meta/main.yml``」には、次のような内容が含まれています。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:514 -msgid "The resulting order of execution would be as follows:" -msgstr "その結果作成される実行順序は以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:527 -msgid "To use ``allow_duplicates: true`` with role dependencies, you must specify it for the role listed under ``dependencies``, not for the role that lists it. In the example above, ``allow_duplicates: true`` appears in the ``meta/main.yml`` of the ``tire`` and ``brake`` roles. The ``wheel`` role does not require ``allow_duplicates: true``, because each instance defined by ``car`` uses different parameter values." -msgstr "``allow_duplicates: true`` をロール依存で使用するには、それをリストしているロールではなく、``dependencies`` の下にリストされているロールに対して指定する必要があります。上記の例では、``allow_duplicates: true`` は、``tire`` ロールおよび ``brake`` ロールの ``meta/main.yml`` に表示されます。``wheel`` ロールは、``car`` で定義された各インスタンスが異なるパラメーター値を使用するため、``allow_duplicates: true`` を必要としません。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:530 -msgid "See :ref:`playbooks_variables` for details on how Ansible chooses among variable values defined in different places (variable inheritance and scope). Also deduplication happens ONLY at the play level, so multiple plays in the same playbook may rerun the roles." -msgstr "Ansible が、さまざまな場所（変数継承および範囲）で定義される変数の値から選択する方法は、「:ref:`playbooks_variables`」を参照してください。また、重複排除はプレイレベルでのみ行われるため、同じ Playbook の複数のプレイがロールを再実行する可能性があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:536 -msgid "Embedding modules and plugins in roles" -msgstr "ロールでのモジュールおよびプラグインの埋め込み" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:539 -msgid "This applies only to standalone roles. Roles in collections do not support plugin embedding; they must use the collection's ``plugins`` structure to distribute plugins." -msgstr "これはスタンドアロンのロールにのみ適用されます。コレクション内のロールはプラグインの埋め込みをサポートしていません。プラグインを配布するには、コレクションの ``plugins`` 構造を使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:541 -msgid "If you write a custom module (see :ref:`developing_modules`) or a plugin (see :ref:`developing_plugins`), you might wish to distribute it as part of a role. For example, if you write a module that helps configure your company's internal software, and you want other people in your organization to use this module, but you do not want to tell everyone how to configure their Ansible library path, you can include the module in your internal_config role." -msgstr "カスタムモジュール (「:ref:`developing_modules`」を参照) やプラグイン (「:ref:`developing_plugins`」を参照) を作成した場合は、ロールの一部として配布したい場合があります。たとえば、社内のソフトウェアを設定するためのモジュールを作成し、組織内の他の人にもこのモジュールを使用してほしいにも関わらず、Ansible のライブラリーパスを設定する方法を全員に開示したくない場合は、internal_config ロールにモジュールを含めることができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:543 -msgid "To add a module or a plugin to a role: Alongside the 'tasks' and 'handlers' structure of a role, add a directory named 'library' and then include the module directly inside the 'library' directory." -msgstr "モジュールやプラグインをロールに追加するには、ロールの「tasks」および「handlers」構造の横に、「library」という名前のディレクトリーを追加し、その「library」ディレクトリー内にモジュールを直接インクルードします。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:546 -msgid "Assuming you had this:" -msgstr "以下があるとします。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:556 -msgid "The module will be usable in the role itself, as well as any roles that are called *after* this role, as follows:" -msgstr "モジュールは、次のように、ロール自体、およびこのロールの *後に* 呼び出されるすべてのロールで使用できます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:567 -msgid "If necessary, you can also embed a module in a role to modify a module in Ansible's core distribution. For example, you can use the development version of a particular module before it is released in production releases by copying the module and embedding the copy in a role. Use this approach with caution, as API signatures may change in core components, and this workaround is not guaranteed to work." -msgstr "必要に応じて、ロールにモジュールを埋め込み、Ansible のコアディストリビューションのモジュールを変更することもできます。たとえば、モジュールをコピーし、そのコピーをロールに埋め込むことで、特定のモジュールの開発バージョンを実稼働リリースの前に使用することができます。コアコンポーネントでは API シグネチャーが変更する可能性があり、この回避策は動作が保証されていないため、この方法は慎重に使用してください。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:569 -msgid "The same mechanism can be used to embed and distribute plugins in a role, using the same schema. For example, for a filter plugin:" -msgstr "同じスキーマを使用して、ロールにプラグインを埋め込んだり配布したりすることもできます。たとえば、フィルタープラグインの場合は、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:579 -msgid "These filters can then be used in a Jinja template in any role called after 'my_custom_filter'." -msgstr "これらのフィルターは、Jinja のテンプレートで、「my_custom_filter」の後に呼ばれる任意のロールで使用することができます。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:582 -msgid "Sharing roles: Ansible Galaxy" -msgstr "ロールの共有: Ansible Galaxy" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:584 -msgid "`Ansible Galaxy `_ is a free site for finding, downloading, rating, and reviewing all kinds of community-developed Ansible roles and can be a great way to get a jumpstart on your automation projects." -msgstr "`Ansible Galaxy `_ は、コミュニティーで開発されたあらゆる種類の Ansible ロールを検索、ダウンロード、評価、およびレビューする無料サイトで、ここで自動化プロジェクトをすぐに開始するための優れた方法です。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:586 -msgid "The client ``ansible-galaxy`` is included in Ansible. The Galaxy client allows you to download roles from Ansible Galaxy and provides an excellent default framework for creating your own roles." -msgstr "クライアント ``ansible-galaxy`` は、Ansible に含まれています。Galaxy クライアントを使用すると、Ansible Galaxy からロールをダウンロードでき、独自のロールを作成する優れたデフォルトのフレームワークも提供します。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:588 -msgid "Read the `Ansible Galaxy documentation `_ page for more information. A page that refers back to this one frequently is the Galaxy Roles document which explains the required metadata your role needs for use in Galaxy ." -msgstr "詳細は、`Ansible Galaxy documentation `_ ページを参照してください。これを頻繁に参照するページは、Galaxy Role のドキュメントで、Galaxy で使用するためにロールが必要とするメタデータについて説明しています。" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:593 -msgid "How to create new roles, share roles on Galaxy, role management" -msgstr "新規ロールの作成、Galaxy でのロールの共有、およびロールの管理の方法" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:601 -msgid "Variables in playbooks" -msgstr "Playbook の変数" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:606 -msgid ":ref:`tags`" -msgstr ":ref:`tags`" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:607 -msgid "Using tags to select or skip roles/tasks in long playbooks" -msgstr "タグを使用した長い Playbook でロール/タスクの選択またはスキップ" - -#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:611 -msgid "Extending Ansible by writing your own modules" -msgstr "独自のモジュールを作成して Ansible を拡張" - -#: ../../rst/playbook_guide/playbooks_roles.rst:4 -msgid "Playbook Roles and Include Statements" -msgstr "Playbook ロールおよび Include 文" - -#: ../../rst/playbook_guide/playbooks_roles.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/playbook_guide/playbooks_roles.rst:9 -msgid "The documentation regarding roles and includes for playbooks have moved. Their new location is here: :ref:`playbooks_reuse`. Please update any links you may have made directly to this page." -msgstr "Playbook のロールおよびインクルードに関するドキュメントが移動しました。新しい場所は「:ref:`playbooks_reuse`」です。このページに直接作成したリンクを更新してください。" - -#: ../../rst/playbook_guide/playbooks_roles.rst:17 -msgid ":ref:`playbooks_reuse`" -msgstr ":ref:`playbooks_reuse`" - -#: ../../rst/playbook_guide/playbooks_roles.rst:18 -msgid "Creating reusable Playbooks." -msgstr "再利用可能な Playbook の作成" - -#: ../../rst/playbook_guide/playbooks_special_topics.rst:6 -msgid "Advanced playbooks features" -msgstr "Playbook の高度な機能" - -#: ../../rst/playbook_guide/playbooks_special_topics.rst:8 -msgid "This page is obsolete. Refer to the :ref:`main User Guide index page ` for links to all playbook-related topics. Please update any links you may have made directly to this page." -msgstr "このページは使用されなくなりました。Playbook に関連するすべてのトピックへのリンクは、:ref:`メインのユーザーガイドのインデックスページ ` を参照してください。このページに直接リンクを張っている場合は更新してください。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:5 -msgid "Executing playbooks for troubleshooting" -msgstr "トラブルシューティングのための Playbook の実行" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:7 -msgid "When you are testing new plays or debugging playbooks, you may need to run the same play multiple times. To make this more efficient, Ansible offers two alternative ways to execute a playbook: start-at-task and step mode." -msgstr "新しいプレイをテストしたり、Playbook をデバッグしたりする際に、同じプレイを複数回実行しないといけない場合があります。これを効率的に行うために、Ansible では Playbook の実行方法として、start-at-task モードと step モードの 2 種類を用意しています。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:12 -msgid "start-at-task" -msgstr "start-at-task" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:14 -msgid "To start executing your playbook at a particular task (usually the task that failed on the previous run), use the ``--start-at-task`` option." -msgstr "特定のタスク (通常は直前の実行で失敗したタスク) で Playbook の実行を開始するには、``--start-at-task`` オプションを使用します。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:20 -msgid "In this example, Ansible starts executing your playbook at a task named \"install packages\". This feature does not work with tasks inside dynamically re-used roles or tasks (``include_*``), see :ref:`dynamic_vs_static`." -msgstr "この例では、Ansible は「install packages」という名前のタスクで Playbook の実行を開始します。この機能は、動的に再利用されるロールやタスク内のタスク (``include_*``) では動作しません。「:ref:`dynamic_vs_static`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:25 -msgid "Step mode" -msgstr "step モード" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:27 -msgid "To execute a playbook interactively, use ``--step``." -msgstr "Playbook を対話的に実行するには、``--step`` を使用します。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:33 -msgid "With this option, Ansible stops on each task, and asks if it should execute that task. For example, if you have a task called \"configure ssh\", the playbook run will stop and ask." -msgstr "このオプションを使用すると、Ansible は各タスクで停止し、そのタスクを実行すべきかどうかを尋ねます。たとえば、「configure ssh」という名前のタスクがあった場合、Playbook の実行は停止し、次のように尋ねてきます。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:39 -msgid "Answer \"y\" to execute the task, answer \"n\" to skip the task, and answer \"c\" to exit step mode, executing all remaining tasks without asking." -msgstr "「y」と答えてタスクを実行し、「n」と答えてタスクをスキップし、「c」と応えて step モードを終了し、残りのタスクをすべて実行します。" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:45 -msgid ":ref:`playbook_debugger`" -msgstr ":ref:`playbook_debugger`" - -#: ../../rst/playbook_guide/playbooks_startnstep.rst:46 -msgid "Using the Ansible debugger" -msgstr "Ansible デバッガーの使用" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:4 -msgid "Controlling playbook execution: strategies and more" -msgstr "Playbook の実行の制御: strategy など" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:6 -msgid "By default, Ansible runs each task on all hosts affected by a play before starting the next task on any host, using 5 forks. If you want to change this default behavior, you can use a different strategy plugin, change the number of forks, or apply one of several keywords like ``serial``." -msgstr "デフォルトでは、Ansible はプレイの影響を受けるすべてのホストで各タスクを実行してから、任意のホストで次のタスクを開始し、5 つのフォークを使用します。このデフォルトの動作を変更する場合は、別のストラテジープラグインを使用するか、フォーク数を変更するか、``serial`` のようなキーワードのいずれかを適用することができます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:12 -msgid "Selecting a strategy" -msgstr "ストラテジーの選択" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:13 -msgid "The default behavior described above is the :ref:`linear strategy`. Ansible offers other strategies, including the :ref:`debug strategy` (see also :ref:`playbook_debugger`) and the :ref:`free strategy`, which allows each host to run until the end of the play as fast as it can:" -msgstr "上述のデフォルトの動作は :ref:`linear strategy` です。Ansible には、:ref:`debug strategy` (:ref:`playbook_debugger` も参照) や :ref:`free strategy` など、他のストラテジーも用意されています。フリーストラテジーでは、各ホストがプレイが終了するまでできるだけ速く実行することができます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:22 -msgid "You can select a different strategy for each play as shown above, or set your preferred strategy globally in ``ansible.cfg``, under the ``defaults`` stanza:" -msgstr "上記のように各プレイに異なるストラテジーを選択するか、``defaults`` stanza の ``ansible.cfg`` で優先されるストラテジーをグローバルに設定できます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:29 -msgid "All strategies are implemented as :ref:`strategy plugins`. Please review the documentation for each strategy plugin for details on how it works." -msgstr "すべてのストラテジーは :ref:`strategy プラグイン` として実装されます。その仕組みの詳細は、各 strategy プラグインのドキュメントを参照してください。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:32 -msgid "Setting the number of forks" -msgstr "フォークの数の設定" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:33 -msgid "If you have the processing power available and want to use more forks, you can set the number in ``ansible.cfg``:" -msgstr "利用可能な処理能力があり、さらに多くのフォークを使用する場合は、``ansible.cfg`` で数値を設定できます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:40 -msgid "or pass it on the command line: `ansible-playbook -f 30 my_playbook.yml`." -msgstr "または、コマンドラインで渡します (`ansible-playbook -f 30 my_playbook.yml`)。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:43 -msgid "Using keywords to control execution" -msgstr "キーワードを使用した実行の制御" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:45 -msgid "In addition to strategies, several :ref:`keywords` also affect play execution. You can set a number, a percentage, or a list of numbers of hosts you want to manage at a time with ``serial``. Ansible completes the play on the specified number or percentage of hosts before starting the next batch of hosts. You can restrict the number of workers allotted to a block or task with ``throttle``. You can control how Ansible selects the next host in a group to execute against with ``order``. You can run a task on a single host with ``run_once``. These keywords are not strategies. They are directives or options applied to a play, block, or task." -msgstr "ストラテジーだけでなく、いくつかの :ref:`キーワード` もプレイの実行に影響を与えます。``serial`` では、一度に管理したいホストの数、割合、またはリストを設定できます。Ansible は、指定した数または割合のホストでプレイを完了してから、次のホストのバッチを開始します。``throttle`` で、ブロックやタスクに割り当てられるワーカーの数を制限することができます。``order`` で、Ansible がグループ内の次のホストを選択して実行する方法を制御できます。``run_once`` を使用して、1 つのタスクを 1 つのホストで実行することができます。これらのキーワードはストラテジーではなく、プレイ、ブロック、またはタスクに適用されるディレクティブやオプションです。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:47 -msgid "Other keywords that affect play execution include ``ignore_errors``, ``ignore_unreachable``, and ``any_errors_fatal``. These options are documented in :ref:`playbooks_error_handling`." -msgstr "プレイの実行に影響する他のキーワードには、``ignore_errors``、``ignore_unreachable``、および ``any_errors_fatal`` が含まれます。これらのオプションは、「:ref:`playbooks_error_handling`」に記載されています。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:52 -msgid "Setting the batch size with ``serial``" -msgstr "``serial`` を使用してバッチサイズの設定" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:54 -msgid "By default, Ansible runs in parallel against all the hosts in the :ref:`pattern ` you set in the ``hosts:`` field of each play. If you want to manage only a few machines at a time, for example during a rolling update, you can define how many hosts Ansible should manage at a single time using the ``serial`` keyword:" -msgstr "デフォルトでは、Ansible は、各プレイの ``hosts:`` フィールドで設定した :ref:`pattern ` のすべてのホストに対して並行して実行します。ローリングアップデート中など、一度に数台のマシンのみを管理する場合は、``serial`` キーワードを使用して、Ansible が一度に管理するホストの数を定義できます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:71 -msgid "In the above example, if we had 6 hosts in the group 'webservers', Ansible would execute the play completely (both tasks) on 3 of the hosts before moving on to the next 3 hosts:" -msgstr "上の例では、「webservers」というグループに 6 台のホストがあった場合、Ansible はそのうちの 3 台のホストでプレイを完全に (両方のタスクを) 実行してから、次の 3 台のホストに移ります。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:109 -msgid "Setting the batch size with ``serial`` changes the scope of the Ansible failures to the batch size, not the entire host list. You can use :ref:`ignore_unreachable ` or :ref:`max_fail_percentage ` to modify this behavior." -msgstr "``serial`` を使用してバッチサイズを設定すると、ホストリスト全体ではなく、Ansible の失敗のスコープがバッチサイズに変更されます。この動作を変更するには、:ref:`ignore_unreachable ` または :ref:`max_fail_percentage ` を使用します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:111 -msgid "You can also specify a percentage with the ``serial`` keyword. Ansible applies the percentage to the total number of hosts in a play to determine the number of hosts per pass:" -msgstr "``serial`` キーワードでパーセンテージを指定することもできます。Ansible は、プレイ内のホストの合計数にパーセンテージを適用して、パスごとのホスト数を決定します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:120 -msgid "If the number of hosts does not divide equally into the number of passes, the final pass contains the remainder. In this example, if you had 20 hosts in the webservers group, the first batch would contain 6 hosts, the second batch would contain 6 hosts, the third batch would contain 6 hosts, and the last batch would contain 2 hosts." -msgstr "ホストの数がパスの数に等しく分配されない場合は、最後のパスには残りの数が含まれます。この例では、webservers グループに 20 台のホストがある場合、最初のバッチには 6 台のホストが、2 番目のバッチには 6 台のホストが、3 番目のバッチには 6 台のホストが、そして最後のバッチには 2 台のホストが含まれます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:122 -msgid "You can also specify batch sizes as a list. For example:" -msgstr "また、バッチサイズをリストとして指定することもできます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:134 -msgid "In the above example, the first batch would contain a single host, the next would contain 5 hosts, and (if there are any hosts left), every following batch would contain either 10 hosts or all the remaining hosts, if fewer than 10 hosts remained." -msgstr "上記の例では、最初のバッチには 1 台のホストが含まれ、次のバッチには 5 台のホストが含まれ、(ホストが残っていれば) その後のすべてのバッチには 10 台のホストが含まれるか、または 10 台未満のホストが残っていれば、残りのすべてのホストが含まれることになります。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:136 -msgid "You can list multiple batch sizes as percentages:" -msgstr "複数のバッチサイズをパーセンテージとして一覧表示できます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:148 -msgid "You can also mix and match the values:" -msgstr "値を混在させたり、一致させることもできます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:161 -msgid "No matter how small the percentage, the number of hosts per pass will always be 1 or greater." -msgstr "パーセンテージを小さくしても、各パスのホスト数は常に 1 以上になります。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:164 -msgid "Restricting execution with ``throttle``" -msgstr "``throttle`` で実行を制限" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:166 -msgid "The ``throttle`` keyword limits the number of workers for a particular task. It can be set at the block and task level. Use ``throttle`` to restrict tasks that may be CPU-intensive or interact with a rate-limiting API:" -msgstr "``throttle`` キーワードは、特定のタスクに対するワーカーの数を制限します。これは、ブロックおよびタスクのレベルで設定できます。``throttle`` を使用して、CPU に負荷がかかる可能性のあるタスクや、レート制限 API と相互作用するタスクを制限します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:174 -msgid "If you have already restricted the number of forks or the number of machines to execute against in parallel, you can reduce the number of workers with ``throttle``, but you cannot increase it. In other words, to have an effect, your ``throttle`` setting must be lower than your ``forks`` or ``serial`` setting if you are using them together." -msgstr "すでにフォークの数や並列実行するマシンの数を制限している場合は、``throttle`` でワーカーの数を減らすことはできますが、増やすことはできません。つまり、それを合わせて使用する場合に効果を得るためには、``throttle`` の設定が ``forks`` や ``serial`` の設定よりも低くなければなりません。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:177 -msgid "Ordering execution based on inventory" -msgstr "インベントリーに基づく実行の順序付け" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:179 -msgid "The ``order`` keyword controls the order in which hosts are run. Possible values for order are:" -msgstr "``order`` キーワードは、ホストが実行する順序を制御します。order に指定できる値は次のとおりです。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:181 -msgid "inventory:" -msgstr "inventory:" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:182 -msgid "(default) The order provided by the inventory for the selection requested (see note below)" -msgstr "（デフォルト）要求された選択に対してインベントリーによって提供される順序（以下の注記を参照）" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:183 -msgid "reverse_inventory:" -msgstr "reverse_inventory:" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:184 -msgid "The same as above, but reversing the returned list" -msgstr "上記と同じですが、返されたリストの再検証" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:185 -msgid "sorted:" -msgstr "sorted:" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:186 -msgid "Sorted alphabetically sorted by name" -msgstr "名前をアルファベット順で並べ替えます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:187 -msgid "reverse_sorted:" -msgstr "reverse_sorted:" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:188 -msgid "Sorted by name in reverse alphabetical order" -msgstr "アルファベットの逆順で名前がソートされます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:190 -msgid "shuffle:" -msgstr "shuffle:" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:190 -msgid "Randomly ordered on each run" -msgstr "実行ごとにランダムに順序付けられます。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:193 -msgid "the 'inventory' order does not equate to the order in which hosts/groups are defined in the inventory source file, but the 'order in which a selection is returned from the compiled inventory'. This is a backwards compatible option and while reproducible it is not normally predictable. Due to the nature of inventory, host patterns, limits, inventory plugins and the ability to allow multiple sources it is almost impossible to return such an order. For simple cases this might happen to match the file definition order, but that is not guaranteed." -msgstr "'インベントリー' の順序は、インベントリーソースファイル内でホスト/グループが定義する順序と同じではありませんが、'コンパイルされたインベントリーから選択が返される順序' と同じです。これは下位互換性のあるオプションであり、再現可能ですが、通常は予測できません。インベントリーの性質、ホストパターン、制限、インベントリープラグイン、および複数のソースを許可する機能により、そのような順序を返すことはほとんど不可能です。単純なケースでは、これはファイル定義の順序と一致する可能性がありますが、それは保証されていません。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:198 -msgid "Running on a single machine with ``run_once``" -msgstr "シングルマシンで、``run_once`` で動作します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:200 -msgid "If you want a task to run only on the first host in your batch of hosts, set ``run_once`` to true on that task:" -msgstr "ホストのバッチの最初のホストでタスクを実行する場合は、そのタスクで ``run_once`` を true に設定します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:216 -msgid "Ansible executes this task on the first host in the current batch and applies all results and facts to all the hosts in the same batch. This approach is similar to applying a conditional to a task such as:" -msgstr "Ansible は、現在のバッチの最初のホストでこのタスクを実行し、すべての結果とファクトを同じバッチのすべてのホストに適用します。この方法は、次のような条件をタスクに適用することに似ています。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:223 -msgid "However, with ``run_once``, the results are applied to all the hosts. To run the task on a specific host, instead of the first host in the batch, delegate the task:" -msgstr "ただし、``run_once`` では、結果はすべてのホストに適用されます。バッチの最初のホストではなく、特定のホストでタスクを実行するには、タスクを次のように委譲します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:231 -msgid "As always with :ref:`delegation `, the action will be executed on the delegated host, but the information is still that of the original host in the task." -msgstr ":ref:`委譲 ` の場合と同様、アクションは委譲されたホストで実行されますが、情報はタスクの元のホストの情報になります。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:234 -msgid "When used together with ``serial``, tasks marked as ``run_once`` will be run on one host in *each* serial batch. If the task must run only once regardless of ``serial`` mode, use :code:`when: inventory_hostname == ansible_play_hosts_all[0]` construct." -msgstr "``serial`` と併用すると、``run_once`` とマークされたタスクは、*各* シリアルバッチの中の 1 台のホストで実行します。タスクが ``serial`` モードに関係なく 1 回だけ実行する必要がある場合は、:code:`when: inventory_hostname == ansible_play_hosts_all[0]` コンストラクトを使用します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:238 -msgid "Any conditional (in other words, `when:`) will use the variables of the 'first host' to decide if the task runs or not, no other hosts will be tested." -msgstr "条件 (つまり `when:`) は、「first host」の変数を使用して、タスクが実行されるかどうかを判断し、他のホストはテストされません。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:241 -msgid "If you want to avoid the default behavior of setting the fact for all hosts, set ``delegate_facts: True`` for the specific task or block." -msgstr "すべてのホストにファクトを設定するデフォルトの動作を回避する場合は、特定のタスクまたはブロックに ``delegate_facts: True`` を設定します。" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:247 -msgid ":ref:`playbooks_delegation`" -msgstr ":ref:`playbooks_delegation`" - -#: ../../rst/playbook_guide/playbooks_strategies.rst:248 -msgid "Running tasks on or assigning facts to specific machines" -msgstr "特定マシンでのタスクの実行、または特定マシンへのファクトの割り当て" - -#: ../../rst/playbook_guide/playbooks_tags.rst:5 -msgid "Tags" -msgstr "タグ" - -#: ../../rst/playbook_guide/playbooks_tags.rst:7 -msgid "If you have a large playbook, it may be useful to run only specific parts of it instead of running the entire playbook. You can do this with Ansible tags. Using tags to execute or skip selected tasks is a two-step process:" -msgstr "大規模な Playbook を使用する場合は、Playbook 全体を実行するのではなく、特定の部分だけを実行すると便利な場合があります。これを実現するには、Ansible のタグを使用します。タグを使用して選択したタスクを実行またはスキップするには、2 つのステップがあります。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:9 -msgid "Add tags to your tasks, either individually or with tag inheritance from a block, play, role, or import." -msgstr "タスクにタグを追加するには、個別にタグを追加するか、ブロック、プレイ、ロール、またはインポートからタグを継承する必要があります。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:10 -msgid "Select or skip tags when you run your playbook." -msgstr "Playbook の実行時にタグを選択またはスキップします。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:16 -msgid "Adding tags with the tags keyword" -msgstr "tags キーワードを使用したタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:18 -msgid "You can add tags to a single task or include. You can also add tags to multiple tasks by defining them at the level of a block, play, role, or import. The keyword ``tags`` addresses all these use cases. The ``tags`` keyword always defines tags and adds them to tasks; it does not select or skip tasks for execution. You can only select or skip tasks based on tags at the command line when you run a playbook. See :ref:`using_tags` for more details." -msgstr "タグは、単一のタスクまたはインクルードに追加できます。また、ブロック、プレイ、ロール、またはインポートのレベルでタグを定義することで、複数のタスクにタグを追加することもできます。``tags`` キーワードは、これらすべてのユースケースに対応しています。``tags`` キーワードは、常にタグを定義してタスクに追加しますが、実行するタスクの選択やスキップは行いません。タグに基づいてタスクを選択またはスキップできるのは、Playbook の実行時にコマンドラインで行う場合のみです。詳細は、「:ref:`using_tags`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:21 -msgid "Adding tags to individual tasks" -msgstr "個別タスクへのタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:23 -msgid "At the simplest level, you can apply one or more tags to an individual task. You can add tags to tasks in playbooks, in task files, or within a role. Here is an example that tags two tasks with different tags:" -msgstr "最も簡単なレベルでは、個々のタスクに 1 つまたは複数のタグを適用できます。タグは、Playbook 内、タスクファイル内、またはロール内のタスクに追加できます。以下は、2 つのタスクに異なるタグを付ける例です。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:45 -msgid "You can apply the same tag to more than one individual task. This example tags several tasks with the same tag, \"ntp\":" -msgstr "同じタグを複数の個別タスクに適用できます。この例では、同じタグ「ntp」を使用して、複数のタスクにタグを付けることができます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:81 -msgid "If you ran these four tasks in a playbook with ``--tags ntp``, Ansible would run the three tasks tagged ``ntp`` and skip the one task that does not have that tag." -msgstr "``--tags ntp`` を使用して、この 4 つのタスクを Playbook で実行した場合、Ansible は ``ntp`` のタグが付いた 3 つのタスクを実行し、タグが付いていない 1 つのタスクをスキップします。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:86 -msgid "Adding tags to includes" -msgstr "インクルードするタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:88 -msgid "You can apply tags to dynamic includes in a playbook. As with tags on an individual task, tags on an ``include_*`` task apply only to the include itself, not to any tasks within the included file or role. If you add ``mytag`` to a dynamic include, then run that playbook with ``--tags mytag``, Ansible runs the include itself, runs any tasks within the included file or role tagged with ``mytag``, and skips any tasks within the included file or role without that tag. See :ref:`selective_reuse` for more details." -msgstr "タグは、Playbook 内の動的インクルードにタグを適用できます。個々のタスクのタグと同様に、``include_*`` タスクのタグは、インクルード自体にのみ適用され、インクルードされたファイルやロール内のタスクには適用されません。動的インクルードに ``mytag`` を追加し、その Playbook を ``--tags mytag`` で実行すると、Ansible はインクルード自体を実行し、``mytag`` でタグ付けされたインクルードファイルまたはロール内のタスクを実行し、そのタグのないインクルードファイルまたはロール内のタスクをスキップします。詳細は「:ref:`selective_reuse`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:90 -msgid "You add tags to includes the same way you add tags to any other task:" -msgstr "タグを追加して、他のタスクにタグを追加する方法と同じ方法でインクルードします。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:101 -msgid "You can add a tag only to the dynamic include of a role. In this example, the ``foo`` tag will `not` apply to tasks inside the ``bar`` role:" -msgstr "タグは、ロールの動的インクルードにのみ追加できます。この例では、``foo`` タグは ``bar`` ロール内のタスクに適用 `されません`。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:114 -msgid "With plays, blocks, the ``role`` keyword, and static imports, Ansible applies tag inheritance, adding the tags you define to every task inside the play, block, role, or imported file. However, tag inheritance does *not* apply to dynamic re-use with ``include_role`` and ``include_tasks``. With dynamic re-use (includes), the tags you define apply only to the include itself. If you need tag inheritance, use a static import. If you cannot use an import because the rest of your playbook uses includes, see :ref:`apply_keyword` for ways to work around this behavior." -msgstr "プレイ、ブロック、``role`` キーワード、および静的なインポートでは、Ansible はタグ継承を適用し、定義したタグをプレイ、ブロック、ロール、またはインポートしたファイル内のすべてのタスクに追加します。しかし、``include_role`` や ``include_tasks`` のような動的再利用では、タグの継承は *適用されません*。動的再利用 (インクルード) では、定義したタグはインクルード自体にのみ適用されます。タグの継承が必要な場合は、静的インポートを使用してください。Playbook の他の部分がインクルードを使用しているためにインポートを使用できない場合は、この動作を回避する方法について「:ref:`apply_keyword`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:119 -msgid "Tag inheritance: adding tags to multiple tasks" -msgstr "タグの継承: 複数のタスクへのタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:121 -msgid "If you want to apply the same tag or tags to multiple tasks without adding a ``tags`` line to every task, you can define the tags at the level of your play or block, or when you add a role or import a file. Ansible applies the tags down the dependency chain to all child tasks. With roles and imports, Ansible appends the tags set by the ``roles`` section or import to any tags set on individual tasks or blocks within the role or imported file. This is called tag inheritance. Tag inheritance is convenient, because you do not have to tag every task. However, the tags still apply to the tasks individually." -msgstr "すべてのタスクに ``tags`` 行を追加することなく、複数のタスクに同じタグを適用したい場合は、プレイやブロックのレベル、またはロールの追加やファイルのインポートの際にタグを定義することができます。Ansible は、依存関係の連鎖の下にあるタグをすべての子タスクに適用します。ロールやインポートの場合、Ansible は ``roles`` セクションやインポートで設定されたタグを、ロールやインポートしたファイル内の個々のタスクやブロックに設定されたタグに追加します。これを「タグの継承」と呼びます。タグの継承は、すべてのタスクにタグを付ける必要がないため便利です。ただし、タグはタスクに個別に適用されます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:124 -msgid "Adding tags to blocks" -msgstr "ブロックへのタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:126 -msgid "If you want to apply a tag to many, but not all, of the tasks in your play, use a :ref:`block ` and define the tags at that level. For example, we could edit the NTP example shown above to use a block:" -msgstr "プレイ中のタスクのすべてではなく、多くのタスクにタグを適用したい場合は、:ref:`ブロック ` を使用し、そのレベルでタグを定義します。たとえば、上で紹介した NTP の例を編集して、ブロックを使用することができます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:161 -msgid "Adding tags to plays" -msgstr "プレイへのタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:163 -msgid "If all the tasks in a play should get the same tag, you can add the tag at the level of the play. For example, if you had a play with only the NTP tasks, you could tag the entire play:" -msgstr "プレイの中のすべてのタスクに同じタグを付ける必要がある場合は、プレイのレベルでタグを追加することができます。たとえば、NTP タスクだけのプレイがあった場合は、プレイ全体にタグを付けることができます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:194 -msgid "Adding tags to roles" -msgstr "ロールへのタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:196 -msgid "There are three ways to add tags to roles:" -msgstr "ロールにタグを追加するには、3 つの方法があります。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:198 -msgid "Add the same tag or tags to all tasks in the role by setting tags under ``roles``. See examples in this section." -msgstr "``roles`` セクションにタグを設定して、ロールのすべてのタスクに同じタグを追加します。本セクションの例を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:199 -msgid "Add the same tag or tags to all tasks in the role by setting tags on a static ``import_role`` in your playbook. See examples in :ref:`tags_on_imports`." -msgstr "Playbook の静的 ``import_role`` にタグを設定して、ロール内のすべてのタスクに同じタグを追加します。「:ref:`tags_on_imports`」の例を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:200 -msgid "Add a tag or tags to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role. To select or skip tasks within the role, you must have tags set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the same tag or tags to the include. When you use this approach, and then run your playbook with ``--tags foo``, Ansible runs the include itself plus any tasks in the role that also have the tag ``foo``. See :ref:`tags_on_includes` for details." -msgstr "ロール自体の中の個々のタスクやブロックにタグを追加します。これは、ロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックにタグを設定し、Playbook で動的な ``include_role`` を使用して、同じタグをインクルードに追加する必要があります。この方法で ``--tags foo`` を付けて Playbook を実行すると、Ansible はインクルード自体に加えて、タグ ``foo`` を持つロール内のタスクを実行します。詳細は、「:ref:`tags_on_includes`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:202 -msgid "When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds any tags you define to all the tasks in the role. For example:" -msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義したタグをロール内のすべてのタスクに追加します。たとえば、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:212 -msgid "or:" -msgstr "または" - -#: ../../rst/playbook_guide/playbooks_tags.rst:229 -msgid "Adding tags to imports" -msgstr "インポートへのタグの追加" - -#: ../../rst/playbook_guide/playbooks_tags.rst:231 -msgid "You can also apply a tag or tags to all the tasks imported by the static ``import_role`` and ``import_tasks`` statements:" -msgstr "また、静的な ``import_role`` 文や ``import_tasks`` 文によりインポートされたすべてのタスクに、タグを適用することもできます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:252 -msgid "Tag inheritance for includes: blocks and the ``apply`` keyword" -msgstr "インクルードのタグ継承: ブロックおよび ``apply`` キーワード" - -#: ../../rst/playbook_guide/playbooks_tags.rst:254 -msgid "By default, Ansible does not apply :ref:`tag inheritance ` to dynamic re-use with ``include_role`` and ``include_tasks``. If you add tags to an include, they apply only to the include itself, not to any tasks in the included file or role. This allows you to execute selected tasks within a role or task file - see :ref:`selective_reuse` when you run your playbook." -msgstr "デフォルトでは、Ansible は :ref:`タグ継承 ` を適用せず、``include_role`` および ``include_tasks`` を使用した動的再利用を行います。タグをインクルードに追加すると、タグはインクルード自体にのみ適用され、インクルードしたファイルやロール内のタスクには適用されません。これにより、ロールやタスクファイル内の選択したタスクを実行することができます。Playbook を実行する際には、「:ref:`selective_reuse`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:256 -msgid "If you want tag inheritance, you probably want to use imports. However, using both includes and imports in a single playbook can lead to difficult-to-diagnose bugs. For this reason, if your playbook uses ``include_*`` to re-use roles or tasks, and you need tag inheritance on one include, Ansible offers two workarounds. You can use the ``apply`` keyword:" -msgstr "タグの継承が必要な場合は、おそらくインポートを使用したいと思うでしょう。ただし、1 つの Playbook でインクルードとインポートの両方を使用すると、診断が困難なバグが発生する可能性があります。このような理由から、Playbook で ``include_*`` を使用してロールやタスクを再利用している場合に、1 つのインクルードでタグの継承が必要な場合、Ansible には 2 つの回避策があります。``apply`` キーワードを使用することができます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:269 -msgid "Or you can use a block:" -msgstr "または、以下のブロックを使用できます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:281 -msgid "Special tags: always and never" -msgstr "特別なタグ: always および never" - -#: ../../rst/playbook_guide/playbooks_tags.rst:283 -msgid "Ansible reserves two tag names for special behavior: always and never. If you assign the ``always`` tag to a task or play, Ansible will always run that task or play, unless you specifically skip it (``--skip-tags always``)." -msgstr "Ansible は、特別な動作のために、always と never という 2 つのタグ名を予約しています。``always`` タグをタスクやプレイに割り当てると、Ansible は特にスキップしない限り、常にそのタスクやプレイを実行します (``--skip-tags always``)。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:303 -msgid "Fact gathering is tagged with 'always' by default. It is only skipped if you apply a tag and then use a different tag in ``--tags`` or the same tag in ``--skip-tags``." -msgstr "ファクト収集には、デフォルトで「always」というタグが付けられています。タグを適用した後、``--tags`` で別のタグを使用したり、``--skip-tags`` で同じタグを使用した場合に限りスキップされます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:308 -msgid "The role argument specification validation task is tagged with 'always' by default. This validation will be skipped if you use ``--skip-tags always``." -msgstr "ロールの引数の仕様検証タスクは、デフォルトで「always」でタグ付けされます。この検証は、``--skip-tags always`` を使用する場合に省略されます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:313 -msgid "If you assign the ``never`` tag to a task or play, Ansible will skip that task or play unless you specifically request it (``--tags never``)." -msgstr "``never`` タグをタスクまたはプレイに割り当てると、特に要求しない限り (``--tags never``)、Ansible はそのタスクまたはプレイをスキップします。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:325 -msgid "The rarely-used debug task in the example above only runs when you specifically request the ``debug`` or ``never`` tags." -msgstr "上記の例では、ほとんど使用されないデバッグタスクは、``debug`` タグまたは ``never`` タグを特別に要求した場合にのみ実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:330 -msgid "Selecting or skipping tags when you run a playbook" -msgstr "Playbook の実行時にタグの選択または省略" - -#: ../../rst/playbook_guide/playbooks_tags.rst:332 -msgid "Once you have added tags to your tasks, includes, blocks, plays, roles, and imports, you can selectively execute or skip tasks based on their tags when you run :ref:`ansible-playbook`. Ansible runs or skips all tasks with tags that match the tags you pass at the command line. If you have added a tag at the block or play level, with ``roles``, or with an import, that tag applies to every task within the block, play, role, or imported role or file. If you have a role with lots of tags and you want to call subsets of the role at different times, either :ref:`use it with dynamic includes `, or split the role into multiple roles." -msgstr "タスク、インクルード、ブロック、プレイ、ロール、およびインポートにタグを追加したら、:ref:`ansible-playbook` を実行する際に、タグに基づいてタスクを選択的に実行またはスキップすることができます。Ansible は、コマンドラインで指定したタグと一致するタグを持つすべてのタスクを実行またはスキップします。ブロックやプレイのレベルで、``roles`` またはインポートを使用してタグを追加した場合、そのタグはブロック、プレイ、ロール、もしくはインポートされたロールまたはファイル内のすべてのタスクに適用されます。多くのタグを持つロールがあり、ロールのサブセットを異なるタイミングで呼び出したい場合は、:ref:`動的インクルードで使用する ` か、ロールを複数のロールに分割してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:334 -msgid ":ref:`ansible-playbook` offers five tag-related command-line options:" -msgstr ":ref:`ansible-playbook` は、タグ関連のコマンドラインオプションを 5 つ提供します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:336 -msgid "``--tags all`` - run all tasks, ignore tags (default behavior)" -msgstr "``--tags all`` - すべてのタスクを実行し、タグを無視します (デフォルトの動作)。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:337 -msgid "``--tags [tag1, tag2]`` - run only tasks with either the tag ``tag1`` or the tag ``tag2``" -msgstr "``--tags [tag1, tag2]`` - ``tag1`` タグまたは ``tag2`` タグのいずれかでのみタスクを実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:338 -msgid "``--skip-tags [tag3, tag4]`` - run all tasks except those with either the tag ``tag3`` or the tag ``tag4``" -msgstr "``--skip-tags [tag3, tag4]`` - ``tag3`` タグまたは ``tag4`` タグのいずれかが指定されたタスク以外のすべてのタスクを実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:339 -msgid "``--tags tagged`` - run only tasks with at least one tag" -msgstr "``--tags tagged`` - 1 つ以上のタグでタスクのみを実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:340 -msgid "``--tags untagged`` - run only tasks with no tags" -msgstr "``--tags untagged`` - タグなしでタスクのみを実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:342 -msgid "For example, to run only tasks and blocks tagged ``configuration`` and ``packages`` in a very long playbook:" -msgstr "たとえば、非常に長い Playbook で、タスクと、``configuration`` および ``packages`` のタグが付けられたブロックのみを実行するには、以下のコマンドを実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:348 -msgid "To run all tasks except those tagged ``packages``:" -msgstr "``packages`` のタグが付いたタスク以外のすべてのタスクを実行するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:355 -msgid "Previewing the results of using tags" -msgstr "タグの使用結果のプレビュー" - -#: ../../rst/playbook_guide/playbooks_tags.rst:357 -msgid "When you run a role or playbook, you might not know or remember which tasks have which tags, or which tags exist at all. Ansible offers two command-line flags for :ref:`ansible-playbook` that help you manage tagged playbooks:" -msgstr "ロールや Playbook を実行する際、どのタスクがどのタグを持っているのか、あるいはどのタグが存在するのかを知らない、あるいは覚えていない場合があります。Ansible では、タグ付き Playbookの管理に役立つ :ref:`ansible-playbook` にコマンドラインフラグを 2 つ提供しています。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:359 -msgid "``--list-tags`` - generate a list of available tags" -msgstr "``--list-tags`` - 利用可能なタグのリストを生成します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:360 -msgid "``--list-tasks`` - when used with ``--tags tagname`` or ``--skip-tags tagname``, generate a preview of tagged tasks" -msgstr "``--list-tasks`` - ``--tags tagname`` または ``--skip-tags tagname`` と併用すると、タグ付けされたタスクのプレビューを生成します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:362 -msgid "For example, if you do not know whether the tag for configuration tasks is ``config`` or ``conf`` in a playbook, role, or tasks file, you can display all available tags without running any tasks:" -msgstr "たとえば、Playbook、ロール、またはタスクファイルの中で、設定タスクのタグが ``config`` か ``conf`` かがわからない場合は、タスクを実行せずに利用可能なタグをすべて表示することができます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:368 -msgid "If you do not know which tasks have the tags ``configuration`` and ``packages``, you can pass those tags and add ``--list-tasks``. Ansible lists the tasks but does not execute any of them." -msgstr "``configuration`` と ``packages`` のタグを持つタスクがわからない場合は、これらのタグを渡して ``--list-tasks`` を追加します。Ansible はタスクをリストアップしますが、実行はしません。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:374 -msgid "These command-line flags have one limitation: they cannot show tags or tasks within dynamically included files or roles. See :ref:`dynamic_vs_static` for more information on differences between static imports and dynamic includes." -msgstr "これらのコマンドラインフラグには、動的インクルードされたファイルやロール内のタグやタスクを表示することができないという制限があります。静的インポートと動的インクルードの違いについての詳細は、「:ref:`dynamic_vs_static`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:379 -msgid "Selectively running tagged tasks in re-usable files" -msgstr "再利用可能なファイルでタグ付けされたタスクを選択的に実行" - -#: ../../rst/playbook_guide/playbooks_tags.rst:381 -msgid "If you have a role or a tasks file with tags defined at the task or block level, you can selectively run or skip those tagged tasks in a playbook if you use a dynamic include instead of a static import. You must use the same tag on the included tasks and on the include statement itself. For example you might create a file with some tagged and some untagged tasks:" -msgstr "タスクやブロックのレベルでタグが定義されているロールやタスクファイルがある場合は、静的インポートの代わりに動的インクルードを使用すると、Playbook 内のタグ付きタスクを選択的に実行したりスキップしたりすることができます。インクルードされるタスクと include 文自体には、同じタグを使用する必要があります。たとえば、タグ付きのタスクとタグなしのタスクを含むファイルを作成する場合は、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:404 -msgid "And you might include the tasks file above in a playbook:" -msgstr "また、Playbook に上記のタスクファイルを含めることができます。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:416 -msgid "When you run the playbook with ``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"``, Ansible skips the task with no tags, runs the tagged individual task, and runs the two tasks in the block." -msgstr "``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"`` を使用して Playbook を実行すると、Ansible はタグのないタスクを省略し、タグ付けされた個別のタスクを実行し、ブロック内の 2 つのタスクを実行します。" - -#: ../../rst/playbook_guide/playbooks_tags.rst:419 -msgid "Configuring tags globally" -msgstr "タグのグローバル設定" - -#: ../../rst/playbook_guide/playbooks_tags.rst:421 -msgid "If you run or skip certain tags by default, you can use the :ref:`TAGS_RUN` and :ref:`TAGS_SKIP` options in Ansible configuration to set those defaults." -msgstr "デフォルトで特定のタグを実行するか、スキップする場合は、Ansible 設定で :ref:`TAGS_RUN` オプションおよび :ref:`TAGS_SKIP` オプションを使用してこれらのデフォルトを設定できます。" - -#: ../../rst/playbook_guide/playbooks_templating.rst:5 -msgid "Templating (Jinja2)" -msgstr "テンプレート作成 (Jinja2)" - -#: ../../rst/playbook_guide/playbooks_templating.rst:7 -msgid "Ansible uses Jinja2 templating to enable dynamic expressions and access to :ref:`variables ` and :ref:`facts `. You can use templating with the :ref:`template module `. For example, you can create a template for a configuration file, then deploy that configuration file to multiple environments and supply the correct data (IP address, hostname, version) for each environment. You can also use templating in playbooks directly, by templating task names and more. You can use all the :ref:`standard filters and tests ` included in Jinja2. Ansible includes additional specialized filters for selecting and transforming data, tests for evaluating template expressions, and :ref:`lookup_plugins` for retrieving data from external sources such as files, APIs, and databases for use in templating." -msgstr "Ansible は Jinja2 テンプレートを使用して動的な式を有効にし、:ref:`variables ` および :ref:`facts ` へのアクセスを有効にします。:ref:`template module ` でテンプレートを使用できます。たとえば、設定ファイルのテンプレートを作成してから、その設定ファイルを複数の環境にデプロイし、各環境に対して適切なデータ（IP アドレス、ホスト名、バージョン）を指定できます。 タスク名などをテンプレート化することで、Playbook でテンプレートを直接使用することもできます。Jinja2 に含まれるすべての :ref:`standard filters and tests ` を使用できます。Ansible には、データを選択および変換するための追加の特殊なフィルター、テンプレート式の評価のテスト、テンプレートで使用するファイル、API、データベースなどの外部ソースからデータを取得するための :ref:`lookup_plugins` が含まれています。" - -#: ../../rst/playbook_guide/playbooks_templating.rst:14 -msgid "All templating happens on the Ansible controller **before** the task is sent and executed on the target machine. This approach minimizes the package requirements on the target (jinja2 is only required on the controller). It also limits the amount of data Ansible passes to the target machine. Ansible parses templates on the controller and passes only the information needed for each task to the target machine, instead of passing all the data on the controller and parsing it on the target." -msgstr "テンプレート化はすべて、タスクが送信されターゲットマシンで実行する **前** に、Ansible のコントローラーで行われます。このアプローチにより、ターゲットでのパッケージ要件を最小限に抑えることができます (jinja2 はコントローラーでのみ必要です)。また、Ansible がターゲットマシンに渡すデータの量も制限されます。Ansible は、コントローラーですべてのデータを渡してターゲットで解析するのではなく、コントローラーでテンプレートを解析し、各タスクに必要な情報だけをターゲットマシンに渡します。" - -#: ../../rst/playbook_guide/playbooks_templating.rst:21 -msgid "Files and data used by the :ref:`template module ` must be utf-8 encoded." -msgstr ":ref:`template module ` で使用されるファイルおよびデータは utf-8 エンコードされている必要があります。" - -#: ../../rst/playbook_guide/playbooks_templating.rst:27 -msgid ":ref:`playbook_tips`" -msgstr ":ref:`playbook_tips`" - -#: ../../rst/playbook_guide/playbooks_templating.rst:29 -msgid "`Jinja2 Docs `_" -msgstr "`Jinja2 Docs `_" - -#: ../../rst/playbook_guide/playbooks_templating.rst:30 -msgid "Jinja2 documentation, includes the syntax and semantics of the templates" -msgstr "Jinja2 ドキュメント（テンプレートの構文およびセマンティクスを含む）" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:4 -msgid "The now function: get the current time" -msgstr "now 関数: 現在の時間を取得します。" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:8 -msgid "The ``now()`` Jinja2 function retrieves a Python datetime object or a string representation for the current time." -msgstr "Jinja2 関数 ``now()`` は、Python の datetime オブジェクトまたは現在の時間を表す文字列を取得します。" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:10 -msgid "The ``now()`` function supports 2 arguments:" -msgstr "``now()`` 関数は、2 つの引数をサポートします。" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:13 -msgid "utc" -msgstr "utc" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:13 -msgid "Specify ``True`` to get the current time in UTC. Defaults to ``False``." -msgstr "UTC で現在の時間を取得するには、``True`` を指定します。デフォルトは ``False`` です。" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:17 -msgid "fmt" -msgstr "fmt" - -#: ../../rst/playbook_guide/playbooks_templating_now.rst:16 -msgid "Accepts a `strftime `_ string that returns a formatted date time string." -msgstr "`strftime `_ の文字列を受け取り、形式化された日時文字列を返します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:5 -msgid "Tests" -msgstr "テスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:7 -msgid "`Tests `_ in Jinja are a way of evaluating template expressions and returning True or False. Jinja ships with many of these. See `builtin tests`_ in the official Jinja template documentation." -msgstr "Jinja の `Tests `_ は、テンプレート式を評価して、True または False を返します。Jinja にはこれらの多くが同梱されています。Jinja の公式テンプレートドキュメントの「`builtin tests`_」をご覧ください。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:9 -msgid "The main difference between tests and filters are that Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. Tests can also be used in list processing filters, like ``map()`` and ``select()`` to choose items in the list." -msgstr "テストとフィルターの主な違いは、Jinja のテストは比較に使用されるのに対し、フィルターはデータ操作に使用され、Jinja では用途が異なります。テストは、``map()`` や ``select()`` のように、リスト内の項目を選択するリスト処理フィルターにも使用できます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:11 -msgid "Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data." -msgstr "すべてのテンプレートと同様、テストは常に、ローカルデータをテストする際にタスクのターゲットでは **なく**、Ansible コントローラーで実行されます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:13 -msgid "In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own." -msgstr "このような Jinja2 テストに加えて、Ansible はより多くのものを提供しており、ユーザーは独自のテストを簡単に作成できます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:21 -msgid "Test syntax" -msgstr "テストの構文" - -#: ../../rst/playbook_guide/playbooks_tests.rst:23 -msgid "`Test syntax `_ varies from `filter syntax `_ (``variable | filter``). Historically Ansible has registered tests as both jinja tests and jinja filters, allowing for them to be referenced using filter syntax." -msgstr "`テストの構文 ` は、`フィルターの構文 `_ (``variable | filter``) と異なります。これまで Ansible は、テストを jinja テストと jinja フィルターの両方に登録し、filter 構文を使用して参照できるようにしてきました。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:25 -msgid "As of Ansible 2.5, using a jinja test as a filter will generate a deprecation warning. As of Ansible 2.9+ using jinja test syntax is required." -msgstr "Ansible 2.5 の時点では、jinja テストをフィルターとして使用すると非推奨に関する警告が生成されます。Ansible 2.9 以降では、jinja テスト構文を使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:27 -msgid "The syntax for using a jinja test is as follows" -msgstr "jinja テストを使用するための構文は、以下のとおりです。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:33 -msgid "Such as" -msgstr "例:" - -#: ../../rst/playbook_guide/playbooks_tests.rst:42 -msgid "Testing strings" -msgstr "文字列のテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:44 -msgid "To match strings against a substring or a regular expression, use the ``match``, ``search`` or ``regex`` tests" -msgstr "サブ文字列または正規表現に対して文字列と一致させるには、「``match``」、「``search``」、または「``regex``」を使用します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:68 -msgid "``match`` succeeds if it finds the pattern at the beginning of the string, while ``search`` succeeds if it finds the pattern anywhere within string. By default, ``regex`` works like ``search``, but ``regex`` can be configured to perform other tests as well, by passing the ``match_type`` keyword argument. In particular, ``match_type`` determines the ``re`` method that gets used to perform the search. The full list can be found in the relevant Python documentation `here `_." -msgstr "``match`` は、文字列の先頭でパターンを見つけた場合に成功し、``search`` は、文字列内の任意の場所でパターンを見つけた場合に成功します。デフォルトでは、``regex`` は ``search`` のように動作しますが、``regex`` は ``match_type`` キーワード引数を渡すことで、他のテストも実行するように構成することができます。特に、``match_type`` は、検索を実行する際に使用される ``re`` メソッドを決定します。完全なリストは、`こちら `_ にある関連 Python ドキュメントを参照してください。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:70 -msgid "All of the string tests also take optional ``ignorecase`` and ``multiline`` arguments. These correspond to ``re.I`` and ``re.M`` from Python's ``re`` library, respectively." -msgstr "すべての文字列テストは、任意の ``ignorecase`` 引数および ``multiline`` 引数を取ります。これらは、Python の ``re`` ライブラリーからそれぞれ ``re.I`` および ``re.M`` に対応します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:75 -msgid "Vault" -msgstr "Vault" - -#: ../../rst/playbook_guide/playbooks_tests.rst:79 -msgid "You can test whether a variable is an inline single vault encrypted value using the ``vault_encrypted`` test." -msgstr "変数がインラインの 1 つの vault で暗号化された値であるかどうかは、``vault_encrypted`` テストでテストできます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:99 -msgid "Testing truthiness" -msgstr "真偽の検証" - -#: ../../rst/playbook_guide/playbooks_tests.rst:103 -msgid "As of Ansible 2.10, you can now perform Python like truthy and falsy checks." -msgstr "Ansible 2.10 以降では、Python を真偽チェックのように実行できるようになりました。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:119 -msgid "Additionally, the ``truthy`` and ``falsy`` tests accept an optional parameter called ``convert_bool`` that will attempt to convert boolean indicators to actual booleans." -msgstr "また、``truthy`` テストおよび ``falsy`` テストは、ブール値インジケーターを実際のブール値に変換しようとする ``convert_bool`` と呼ばれる任意のパラメーターを受け入れます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:139 -msgid "Comparing versions" -msgstr "バージョンの比較" - -#: ../../rst/playbook_guide/playbooks_tests.rst:143 -msgid "In 2.5 ``version_compare`` was renamed to ``version``" -msgstr "2.5 では、``version_compare`` の名前が ``version`` に変更されました。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:145 -msgid "To compare a version number, such as checking if the ``ansible_facts['distribution_version']`` version is greater than or equal to '12.04', you can use the ``version`` test." -msgstr "``ansible_facts['distribution_version']`` のバージョンが「12.04」以上かどうかを確認するなど、バージョン番号を比較するには、``version`` テストを使用します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:148 -msgid "The ``version`` test can also be used to evaluate the ``ansible_facts['distribution_version']``" -msgstr "``version`` テストを使用して ``ansible_facts['distribution_version']`` を評価することもできます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:154 -msgid "If ``ansible_facts['distribution_version']`` is greater than or equal to 12.04, this test returns True, otherwise False." -msgstr "``ansible_facts['distribution_version']`` が 12.04 以上の場合は、このテストで True が返り、それ以外の場合は False が返ります。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:156 -msgid "The ``version`` test accepts the following operators" -msgstr "``version`` テストでは、以下の演算子を受け入れます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:162 -msgid "This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing as defined by ``ansible.module_utils.compat.version.StrictVersion`` should be used. The default is ``False`` (using ``ansible.module_utils.compat.version.LooseVersion``), ``True`` enables strict version parsing" -msgstr "このテストは、3 番目のパラメーター ``strict`` も受け入れます。これは、``ansible.module_utils.compat.version.StrictVersion`` で定義された厳格なバージョン解析機能を使用できます。デフォルトは ``False`` (``ansible.module_utils.compat.version.LooseVersion`` を使用) で、``True`` は、厳格なバージョン解析を有効にします。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:168 -msgid "As of Ansible 2.11 the ``version`` test accepts a ``version_type`` parameter which is mutually exclusive with ``strict``, and accepts the following values" -msgstr "Ansible 2.11 の時点で、``version`` テストは ``strict`` と相互に排他的な ``version_type`` パラメーターを受け入れ、以下の値を受け入れます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:175 -msgid "``loose``" -msgstr "``loose``" - -#: ../../rst/playbook_guide/playbooks_tests.rst:175 -msgid "This type corresponds to the Python ``distutils.version.LooseVersion`` class. All version formats are valid for this type. The rules for comparison are simple and predictable, but may not always give expected results." -msgstr "このタイプは Python ``distutils.version.LooseVersion`` クラスに対応します。すべてのバージョン形式はこのタイプで有効です。比較のルールはシンプルで予測可能ですが、常に想定される結果が提供されるとは限りません。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:178 -msgid "``strict``" -msgstr "``strict``" - -#: ../../rst/playbook_guide/playbooks_tests.rst:178 -msgid "This type corresponds to the Python ``distutils.version.StrictVersion`` class. A version number consists of two or three dot-separated numeric components, with an optional \"pre-release\" tag on the end. The pre-release tag consists of a single letter 'a' or 'b' followed by a number. If the numeric components of two version numbers are equal, then one with a pre-release tag will always be deemed earlier (lesser) than one without." -msgstr "このタイプは、Python ``distutils.version.StrictVersion`` クラスに対応します。バージョン番号は、2 つまたは 3 つのドットで区切られたコンポーネントで設定され、オプションで release タグが付きます。プレリリースタグは 1 文字 (a または b) とそれに続く数字で設定されます。2 つのバージョン番号の数値が等しく、プレリリースタグの付いたコンポーネントは常に 1 つ前の (1 つ小さい) とみなされます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:181 -msgid "``semver``/``semantic``" -msgstr "``semver``/``semantic``" - -#: ../../rst/playbook_guide/playbooks_tests.rst:181 -msgid "This type implements the `Semantic Version `_ scheme for version comparison." -msgstr "このタイプは、バージョン比較の `Semantic Version `_ スキームを実装します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:184 -msgid "``pep440``" -msgstr "``pep440``" - -#: ../../rst/playbook_guide/playbooks_tests.rst:184 -msgid "This type implements the Python `PEP-440 `_ versioning rules for version comparison. Added in version 2.14." -msgstr "このタイプは、バージョン比較の Python `PEP-440 `_ バージョン管理ルールを実装します。バージョン 2.14 で追加されました。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:186 -msgid "Using ``version_type`` to compare a semantic version would be achieved like the following" -msgstr "``version_type`` を使用してセマンティックバージョンを比較すると、以下のように実行されます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:192 -msgid "In Ansible 2.14, the ``pep440`` option for ``version_type`` was added, and the rules of this type are defined in `PEP-440 `_. The following example showcases how this type can differentiate pre-releases as being less than a general release." -msgstr "Ansible 2.14 では、``version_type`` の ``pep440`` オプションが追加され、このタイプのルールは `PEP-440 `_ で定義されています。以下の例では、このタイプのリリースを一般的なリリースよりも小さいものとして、区別できることが分かります。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:198 -msgid "When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the `FAQ `_" -msgstr "Playbook またはロールで ``version`` を使用する場合は、`FAQ `_ で説明されているように ``{{ }}`` を使用しないでください。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:213 -msgid "Set theory tests" -msgstr "セット理論テスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:217 -msgid "In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset``" -msgstr "2.5 では、``issubset`` および ``issuperset`` の名前が ``subset`` および ``superset`` に変更されました。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:219 -msgid "To see if a list includes or is included by another list, you can use 'subset' and 'superset'" -msgstr "リストに別のリストが含まれているか、またはリストが別のリストに含まれているかを確認するには、「subset」および「superset」を使用します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:238 -msgid "Testing if a list contains a value" -msgstr "リストに値が含まれるかどうかのテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:242 -msgid "Ansible includes a ``contains`` test which operates similarly, but in reverse of the Jinja2 provided ``in`` test. The ``contains`` test is designed to work with the ``select``, ``reject``, ``selectattr``, and ``rejectattr`` filters" -msgstr "Ansible には、Jinja2 が提供する ``in`` テストとは逆に、同様の動作をする ``contains`` テストが含まれています。``contains`` テストは、フィルターの ``select``、``reject``、``selectattr``、および ``rejectattr`` で動作するように設計されています。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:274 -msgid "Testing if a list value is True" -msgstr "リスト値が True の場合のテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:278 -msgid "You can use `any` and `all` to check if any or all elements in a list are true or not" -msgstr "`any` および `all` を使用して、リスト内の一部またはすべての要素が true かどうかを確認できます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:303 -msgid "Testing paths" -msgstr "パスのテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:305 -msgid "In 2.5 the following tests were renamed to remove the ``is_`` prefix" -msgstr "2.5 では、以下のテストの名前が変更になり、``is_`` プレフィックスが削除されました。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:307 -msgid "The following tests can provide information about a path on the controller" -msgstr "以下のテストは、コントローラー上のパスに関する情報を提供します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:350 -msgid "Testing size formats" -msgstr "サイズ形式のテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:352 -msgid "The ``human_readable`` and ``human_to_bytes`` functions let you test your playbooks to make sure you are using the right size format in your tasks, and that you provide Byte format to computers and human-readable format to people." -msgstr "``human_readable`` 関数および ``human_to_bytes`` 関数を使用すると、Playbook をテストして、タスクで適切なサイズの形式を使用しているかどうか、また、コンピューターにはバイト形式、およびユーザーには人間が判読可能な形式を提供しているかどうかを確認することができます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:357 -msgid "Human readable" -msgstr "人間が読み取り可能" - -#: ../../rst/playbook_guide/playbooks_tests.rst:359 -msgid "Asserts whether the given string is human readable or not." -msgstr "指定の文字列が人が判読できるかどうかをアサートします。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:361 -#: ../../rst/playbook_guide/playbooks_tests.rst:386 -msgid "For example" -msgstr "たとえば、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:375 -#: ../../rst/playbook_guide/playbooks_tests.rst:402 -msgid "This would result in" -msgstr "これにより、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:382 -msgid "Human to bytes" -msgstr "人間からバイト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:384 -msgid "Returns the given string in the Bytes format." -msgstr "指定した文字列をバイト形式で返します。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:412 -msgid "Testing task results" -msgstr "タスク結果のテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:414 -msgid "The following tasks are illustrative of the tests meant to check the status of tasks" -msgstr "以下のタスクは、タスクのステータスを確認するためのテストを示しています。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:445 -msgid "From 2.1, you can also use success, failure, change, and skip so that the grammar matches, for those who need to be strict about it." -msgstr "2.1 以降、文法を厳密にする必要がある場合に、success、failure、change、および skip を使用して、文法が一致するようにすることもできます。" - -#: ../../rst/playbook_guide/playbooks_tests.rst:450 -msgid "Type Tests" -msgstr "タイプテスト" - -#: ../../rst/playbook_guide/playbooks_tests.rst:452 -msgid "When looking to determine types, it may be tempting to use the ``type_debug`` filter and compare that to the string name of that type, however, you should instead use type test comparisons, such as:" -msgstr "タイプを決定する際には、``type_debug`` フィルターを使用して、そのタイプの文字列名と比較したくなるかもしれません。しかし、代わりに以下のようなタイプテストの比較を使用する必要があります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:5 -msgid "Using Variables" -msgstr "変数の使用" - -#: ../../rst/playbook_guide/playbooks_variables.rst:7 -msgid "Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple different systems with a single command. To represent the variations among those different systems, you can create variables with standard YAML syntax, including lists and dictionaries. You can define these variables in your playbooks, in your :ref:`inventory `, in re-usable :ref:`files ` or :ref:`roles `, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable." -msgstr "Ansible は変数を使用してシステム間の違いを管理します。Ansible では、1 つのコマンドで複数の異なるシステム上でタスクや Playbook を実行することができます。これらの異なるシステム間の差異を表現するために、リストやディクショナリーなどの標準的な YAML 構文で変数を作成できます。これらの変数は、Playbook、:ref:`インベントリー `、再利用可能な :ref:`ファイル `、または :ref:`ロール `、もしくはコマンドラインで定義できます。また、タスクの戻り値を新しい変数として登録することで、Playbook の実行中に変数を作成することもできます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:9 -msgid "After you create variables, either by defining them in a file, passing them at the command line, or registering the return value or values of a task as a new variable, you can use those variables in module arguments, in :ref:`conditional \"when\" statements `, in :ref:`templates `, and in :ref:`loops `. The `ansible-examples github repository `_ contains many examples of using variables in Ansible." -msgstr "ファイルで定義したり、コマンドラインで渡したり、タスクの戻り値を新しい変数として登録したりして変数を作成した後は、その変数をモジュールの引数、:ref:`条件分岐の「when」文 `、:ref:`テンプレート `、および :ref:`ループ ` で使用することができます。`ansible-examples github リポジトリー `_ には、Ansible での変数の使用例が多数掲載されています。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:11 -msgid "Once you understand the concepts and examples on this page, read about :ref:`Ansible facts `, which are variables you retrieve from remote systems." -msgstr "このページの概念と例を理解したら、リモートシステムから取得する変数である :ref:`Ansible ファクト ` を確認します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:19 -msgid "Creating valid variable names" -msgstr "有効な変数名の作成" - -#: ../../rst/playbook_guide/playbooks_variables.rst:21 -msgid "Not all strings are valid Ansible variable names. A variable name can only include letters, numbers, and underscores. `Python keywords`_ or :ref:`playbook keywords` are not valid variable names. A variable name cannot begin with a number." -msgstr "すべての文字列が有効な Ansible の変数名になるわけではありません。変数名には、文字、数字、アンダースコアのみを含めることができます。`Python キーワード`_ または :ref:`playbook キーワード` は有効な変数名ではありません。変数名は、数字で始めることはできません。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:23 -msgid "Variable names can begin with an underscore. In many programming languages, variables that begin with an underscore are private. This is not true in Ansible. Variables that begin with an underscore are treated exactly the same as any other variable. Do not rely on this convention for privacy or security." -msgstr "変数名はアンダースコアで始めることができます。多くのプログラミング言語では、アンダースコアで始まる変数はプライベートです。Ansible ではこれは当てはまりません。アンダースコアで始まる変数は、他の変数とまったく同じように扱われます。プライバシーやセキュリティーのために、この規約に依存しないでください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:25 -msgid "This table gives examples of valid and invalid variable names:" -msgstr "この表は、有効かつ無効な変数名の例を紹介します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:31 -msgid "Valid variable names" -msgstr "有効な変数名" - -#: ../../rst/playbook_guide/playbooks_variables.rst:31 -msgid "Not valid" -msgstr "有効ではない" - -#: ../../rst/playbook_guide/playbooks_variables.rst:33 -msgid "``foo``" -msgstr "``foo``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:33 -msgid "``*foo``, `Python keywords`_ such as ``async`` and ``lambda``" -msgstr "``*foo``、`Python キーワード`_ (``async``、``lambda`` など)" - -#: ../../rst/playbook_guide/playbooks_variables.rst:35 -msgid "``foo_env``" -msgstr "``foo_env``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:35 -msgid ":ref:`playbook keywords` such as ``environment``" -msgstr "``environment`` などの :ref:`playbook キーワード`" - -#: ../../rst/playbook_guide/playbooks_variables.rst:37 -msgid "``foo_port``" -msgstr "``foo_port``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:37 -msgid "``foo-port``, ``foo port``, ``foo.port``" -msgstr "``foo-port``、``foo port``、``foo.port``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:39 -msgid "``foo5``, ``_foo``" -msgstr "``foo5``、``_foo``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:39 -msgid "``5foo``, ``12``" -msgstr "``5foo``、``12``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:45 -msgid "Simple variables" -msgstr "単純な変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:47 -msgid "Simple variables combine a variable name with a single value. You can use this syntax (and the syntax for lists and dictionaries shown below) in a variety of places. For details about setting variables in inventory, in playbooks, in reusable files, in roles, or at the command line, see :ref:`setting_variables`." -msgstr "単純変数は、変数名と 1 つの値を組み合わせたものです。この構文 (および後述のリストやディレクトリーの構文) は、さまざまな場所で使用できます。インベントリー、Playbook、再利用可能なファイル、ロール、コマンドラインでの変数設定の詳細については、「:ref:`setting_variables`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:50 -msgid "Defining simple variables" -msgstr "簡単な変数の定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:52 -msgid "You can define a simple variable using standard YAML syntax. For example:" -msgstr "標準の YAML 構文を使用して単純な変数を定義できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:59 -msgid "Referencing simple variables" -msgstr "単純な変数の参照" - -#: ../../rst/playbook_guide/playbooks_variables.rst:61 -msgid "After you define a variable, use Jinja2 syntax to reference it. Jinja2 variables use double curly braces. For example, the expression ``My amp goes to {{ max_amp_value }}`` demonstrates the most basic form of variable substitution. You can use Jinja2 syntax in playbooks. For example:" -msgstr "変数を定義した後は、Jinja2 の構文を使用して変数を参照します。Jinja2 の変数には二重の中括弧が使用されます。たとえば、``My amp goes to {{ max_amp_value }}`` という式は、最も基本的な形の変数置換を示しています。Playbook では、Jinja2 構文を使用できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:69 -msgid "In this example, the variable defines the location of a file, which can vary from one system to another." -msgstr "この例では、変数がファイルの場所を定義していますが、これはシステムごとに異なる可能性があります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:73 -msgid "Ansible allows Jinja2 loops and conditionals in :ref:`templates ` but not in playbooks. You cannot create a loop of tasks. Ansible playbooks are pure machine-parseable YAML." -msgstr "Ansible では、:ref:`テンプレート ` で Jinja2 のループや条件分岐を使用できますが、Playbook では使用できません。タスクのループを作成することはできません。Ansible の Playbook は純粋に機械で解析可能な YAML です。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:78 -msgid "When to quote variables (a YAML gotcha)" -msgstr "変数を引用するタイミング (YAML に関する注意点)" - -#: ../../rst/playbook_guide/playbooks_variables.rst:80 -msgid "If you start a value with ``{{ foo }}``, you must quote the whole expression to create valid YAML syntax. If you do not quote the whole expression, the YAML parser cannot interpret the syntax - it might be a variable or it might be the start of a YAML dictionary. For guidance on writing YAML, see the :ref:`yaml_syntax` documentation." -msgstr "値を ``{{ foo }}`` で始めた場合、有効な YAML 構文を作成するためには式全体を引用しなければなりません。式全体を引用符で囲まないと、YAML パーサーはその構文を解釈できません。それは変数かもしれないし、YAML ディレクトリーの始まりかもしれません。YAML の記述方法については、「:ref:`yaml_syntax`」のドキュメントを参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:82 -msgid "If you use a variable without quotes like this:" -msgstr "引用符なしの変数を使用する場合は、以下のようになります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:90 -msgid "You will see: ``ERROR! Syntax Error while loading YAML.`` If you add quotes, Ansible works correctly:" -msgstr "``ERROR! Syntax Error while loading YAML.`` を参照してください。引用符を追加すると、Ansible が正常に機能します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:101 -msgid "Boolean variables" -msgstr "ブール値の変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:103 -msgid "Ansible accepts a broad range of values for boolean variables: ``true/false``, ``1/0``, ``yes/no``, ``True/False`` and so on. The matching of valid strings is case insensitive. While documentation examples focus on ``true/false`` to be compatible with ``ansible-lint`` default settings, you can use any of the following:" -msgstr "Ansible では、ブール変数 ``true/false``、``1/0``、``yes/no``、``True/False`` など、幅広い値を使用できます。有効な文字列の照合では、大文字と小文字を区別しません。ドキュメントのサンプルは、``true/false`` と ``ansible-lint`` のデフォルト設定との互換性を確保することに焦点を置いていますが、以下のいずれかを使用できます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:110 -msgid "Valid values" -msgstr "有効な値は以下のとおりです。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:112 -msgid "``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0``" -msgstr "``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:112 -msgid "Truthy values" -msgstr "真理値" - -#: ../../rst/playbook_guide/playbooks_variables.rst:114 -msgid "``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0``" -msgstr "``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:114 -msgid "Falsy values" -msgstr "偽値" - -#: ../../rst/playbook_guide/playbooks_variables.rst:121 -msgid "List variables" -msgstr "リスト変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:123 -msgid "A list variable combines a variable name with multiple values. The multiple values can be stored as an itemized list or in square brackets ``[]``, separated with commas." -msgstr "リスト変数は、変数名と複数の値を組み合わせたものです。複数の値は、項目別のリストとして、または角括弧 ``[]`` の中にコンマで区切って格納できます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:126 -msgid "Defining variables as lists" -msgstr "変数をリストとして定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:128 -msgid "You can define variables with multiple values using YAML lists. For example:" -msgstr "YAML リストを使用して、複数の値で変数を定義できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:138 -msgid "Referencing list variables" -msgstr "リスト変数の参照" - -#: ../../rst/playbook_guide/playbooks_variables.rst:140 -msgid "When you use variables defined as a list (also called an array), you can use individual, specific fields from that list. The first item in a list is item 0, the second item is item 1. For example:" -msgstr "リスト (配列とも呼ばれる) として定義された変数を使用する場合は、そのリストから個々の特定のフィールドを使用することができます。リストの最初の項目は項目 0、2 番目の項目は項目 1 です。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:146 -msgid "The value of this expression would be \"northeast\"." -msgstr "この式の値は「northeast」になります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:151 -msgid "Dictionary variables" -msgstr "ディクショナリー変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:153 -msgid "A dictionary stores the data in key-value pairs. Usually, dictionaries are used to store related data, such as the information contained in an ID or a user profile." -msgstr "ディクショナリーは、データをキーと値のペアに保存します。通常、ディクショナリーは ID またはユーザープロファイルに含まれる情報などの関連データを保存するために使用されます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:156 -msgid "Defining variables as key:value dictionaries" -msgstr "変数を key:value ディクショナリーとして定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:158 -msgid "You can define more complex variables using YAML dictionaries. A YAML dictionary maps keys to values. For example:" -msgstr "YAML ディクショナリーを使用してより複雑な変数を定義できます。YAML ディクショナリーはキーを値にマッピングします。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:167 -msgid "Referencing key:value dictionary variables" -msgstr "key:value ディクショナリー変数の参照" - -#: ../../rst/playbook_guide/playbooks_variables.rst:169 -msgid "When you use variables defined as a key:value dictionary (also called a hash), you can use individual, specific fields from that dictionary using either bracket notation or dot notation:" -msgstr "key:value ディクショナリー (ハッシュとも呼ばれます) として定義された変数を使用する場合は、括弧表記またはドット表記のいずれかを使用して、そのディクショナリーの個々の特定のフィールドを使用できます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:176 -msgid "Both of these examples reference the same value (\"one\"). Bracket notation always works. Dot notation can cause problems because some keys collide with attributes and methods of python dictionaries. Use bracket notation if you use keys which start and end with two underscores (which are reserved for special meanings in python) or are any of the known public attributes:" -msgstr "これらの例では、どちらも同じ値 (「one」) を参照しています。括弧表記は常に有効です。ドット表記では、一部のキーが python ディクショナリーの属性やメソッドと衝突するため、問題が生じます。2 つのアンダースコアで始まって終わるキー (python では特別な意味を持つものとして予約されています) や、既知の公開属性を使用する場合は、括弧表記を使用してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:178 -msgid "``add``, ``append``, ``as_integer_ratio``, ``bit_length``, ``capitalize``, ``center``, ``clear``, ``conjugate``, ``copy``, ``count``, ``decode``, ``denominator``, ``difference``, ``difference_update``, ``discard``, ``encode``, ``endswith``, ``expandtabs``, ``extend``, ``find``, ``format``, ``fromhex``, ``fromkeys``, ``get``, ``has_key``, ``hex``, ``imag``, ``index``, ``insert``, ``intersection``, ``intersection_update``, ``isalnum``, ``isalpha``, ``isdecimal``, ``isdigit``, ``isdisjoint``, ``is_integer``, ``islower``, ``isnumeric``, ``isspace``, ``issubset``, ``issuperset``, ``istitle``, ``isupper``, ``items``, ``iteritems``, ``iterkeys``, ``itervalues``, ``join``, ``keys``, ``ljust``, ``lower``, ``lstrip``, ``numerator``, ``partition``, ``pop``, ``popitem``, ``real``, ``remove``, ``replace``, ``reverse``, ``rfind``, ``rindex``, ``rjust``, ``rpartition``, ``rsplit``, ``rstrip``, ``setdefault``, ``sort``, ``split``, ``splitlines``, ``startswith``, ``strip``, ``swapcase``, ``symmetric_difference``, ``symmetric_difference_update``, ``title``, ``translate``, ``union``, ``update``, ``upper``, ``values``, ``viewitems``, ``viewkeys``, ``viewvalues``, ``zfill``." -msgstr "``add``、``append``、``as_integer_ratio``、``bit_length``、``capitalize``、``center``、``clear``、``conjugate``、``copy``、``count``、``decode``、``denominator``、``difference``、``difference_update``、``discard``、``encode``、``endswith``、``expandtabs``、``extend``、``find``、``format``、``fromhex``、``fromkeys``、``get``、``has_key``、``hex``、``imag``、``index``、``insert``、``intersection``、``intersection_update``、``isalnum``、``isalpha``、``isdecimal``、``isdigit``、``isdisjoint``、``is_integer``、``islower``、``isnumeric``、``isspace``、``issubset``、``issuperset``、``istitle``、``isupper``、``items``、``iteritems``、``iterkeys``、``itervalues``、``join``、``keys``、``ljust``、``lower``、``lstrip``、``numerator``、``partition``、``pop``、``popitem``、``real``、``remove``、``replace``、``reverse``、``rfind``、``rindex``、``rjust``、``rpartition``、``rsplit``、``rstrip``、``setdefault``、``sort``、``split``、``splitlines``、``startswith``、``strip``、``swapcase``、``symmetric_difference``、``symmetric_difference_update``、``title``、``translate``、``union``、``update``、``upper``、``values``、``viewitems``、``viewkeys``、``viewvalues``、``zfill``" - -#: ../../rst/playbook_guide/playbooks_variables.rst:183 -msgid "Registering variables" -msgstr "変数の登録" - -#: ../../rst/playbook_guide/playbooks_variables.rst:185 -msgid "You can create variables from the output of an Ansible task with the task keyword ``register``. You can use registered variables in any later tasks in your play. For example:" -msgstr "タスクキーワード ``register`` を使用して、Ansible タスクの出力から変数を作成することができます。登録した変数は、プレイ中の後続のタスクで使用することができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:202 -msgid "For more examples of using registered variables in conditions on later tasks, see :ref:`playbooks_conditionals`. Registered variables may be simple variables, list variables, dictionary variables, or complex nested data structures. The documentation for each module includes a ``RETURN`` section describing the return values for that module. To see the values for a particular task, run your playbook with ``-v``." -msgstr "登録された変数を後のタスクの条件で使用する例は、「:ref:`playbooks_conditionals`」を参照してください。登録した変数には、単純な変数、リスト変数、ディクショナリー変数、複雑にネストしたデータ構造などがあります。各モジュールのドキュメントには、そのモジュールの戻り値を説明した ``RETURN`` セクションがあります。特定のタスクの値を確認するには、``-v`` で Playbook を実行します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:204 -msgid "Registered variables are stored in memory. You cannot cache registered variables for use in future playbook runs. Registered variables are only valid on the host for the rest of the current playbook run, including subsequent plays within the same playbook run." -msgstr "登録された変数はメモリーに保存されます。登録された変数を今後のプレイで使用するためにキャッシュすることはできません。登録された変数は、現在の Playbook の残りが実行されている間、ホスト上でのみ有効です (同じ Playbook の実行中の後続のプレイを含む)。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:206 -msgid "Registered variables are host-level variables. When you register a variable in a task with a loop, the registered variable contains a value for each item in the loop. The data structure placed in the variable during the loop will contain a ``results`` attribute, that is a list of all responses from the module. For a more in-depth example of how this works, see the :ref:`playbooks_loops` section on using register with a loop." -msgstr "登録された変数は、ホストレベルの変数です。ループのあるタスクで変数を登録すると、登録された変数にはループ内の各項目の値が入ります。ループ中に変数に置かれたデータ構造には、``results`` 属性、つまりモジュールからの全応答のリストが含まれます。この動作の詳細な例については、ループで登録の使用に関する「:ref:`playbooks_loops`」セクションを参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:208 -msgid "If a task fails or is skipped, Ansible still registers a variable with a failure or skipped status, unless the task is skipped based on tags. See :ref:`tags` for information on adding and using tags." -msgstr "タスクが失敗またはスキップしても、タグに基づいてタスクがスキップされていない限り、Ansible は失敗またはスキップのステータスで変数を登録します。タグの追加および使用に関する情報は、「:ref:`tags`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:213 -msgid "Referencing nested variables" -msgstr "ネストされた変数の参照" - -#: ../../rst/playbook_guide/playbooks_variables.rst:215 -msgid "Many registered variables (and :ref:`facts `) are nested YAML or JSON data structures. You cannot access values from these nested data structures with the simple ``{{ foo }}`` syntax. You must use either bracket notation or dot notation. For example, to reference an IP address from your facts using the bracket notation:" -msgstr "多くの登録された変数 (および :ref:`ファクト `) は、ネストされた YAML または JSON データ構造です。これらのネストしたデータ構造の値には、単純な ``{{ foo }}`` の構文ではアクセスできません。括弧表記またはドット表記のいずれかを使用する必要があります。たとえば、括弧表記を使用してファクトから IP アドレスを参照するには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:221 -msgid "To reference an IP address from your facts using the dot notation:" -msgstr "ドット表記を使用してファクトから IP アドレスを参照するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:231 -msgid "Transforming variables with Jinja2 filters" -msgstr "Jinja2 フィルターを使用した変数の変換" - -#: ../../rst/playbook_guide/playbooks_variables.rst:233 -msgid "Jinja2 filters let you transform the value of a variable within a template expression. For example, the ``capitalize`` filter capitalizes any value passed to it; the ``to_yaml`` and ``to_json`` filters change the format of your variable values. Jinja2 includes many `built-in filters `_ and Ansible supplies many more filters. To find more examples of filters, see :ref:`playbooks_filters`." -msgstr "Jinja2 のフィルターは、テンプレート式内の変数の値を変換することができます。たとえば、``capitalize`` フィルターは、渡された値をすべて大文字にします。``to_yaml`` フィルターおよび ``to_json`` フィルターは、変数の値の形式を変更します。Jinja2 には多くの `built-in フィルター `_ があり、Ansible にはさらに多くのフィルターが用意されています。フィルターのその他の例については、「:ref:`playbooks_filters`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:238 -msgid "Where to set variables" -msgstr "変数を設定する場所" - -#: ../../rst/playbook_guide/playbooks_variables.rst:240 -msgid "You can define variables in a variety of places, such as in inventory, in playbooks, in reusable files, in roles, and at the command line. Ansible loads every possible variable it finds, then chooses the variable to apply based on :ref:`variable precedence rules `." -msgstr "変数は、インベントリー、Playbook、再利用可能ファイル、ロール、コマンドラインなど、さまざまな場所で定義することができます。Ansible は、検出可能なすべての変数を読み込み、:ref:`変数の優先順位ルール ` に基づいて適用する変数を選択します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:245 -msgid "Defining variables in inventory" -msgstr "インベントリーでの変数の定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:247 -msgid "You can define different variables for each individual host, or set shared variables for a group of hosts in your inventory. For example, if all machines in the ``[Boston]`` group use 'boston.ntp.example.com' as an NTP server, you can set a group variable. The :ref:`intro_inventory` page has details on setting :ref:`host variables ` and :ref:`group variables ` in inventory." -msgstr "個々のホストごとに異なる変数を定義したり、インベントリー内のホストグループに共有変数を設定することができます。たとえば、``[Boston]`` グループのすべてのマシンが NTP サーバーとして「boston.ntp.example.com」を使用する場合は、グループ変数を設定することができます。「:ref:`intro_inventory`」 ページには、インベントリーで :ref:`host 変数 ` および :ref:`group 変数 ` を設定するための詳細が記載されています。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:252 -msgid "Defining variables in a play" -msgstr "プレイでの変数の定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:254 -msgid "You can define variables directly in a playbook play:" -msgstr "変数は Playbook プレイで直接定義できます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:262 -msgid "When you define variables in a play, they are only visible to tasks executed in that play." -msgstr "プレイで変数を定義すると、そのプレイで実行しているタスクでのみ表示されます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:268 -msgid "Defining variables in included files and roles" -msgstr "インクルードファイルおよびロールでの変数の定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:270 -msgid "You can define variables in reusable variables files and/or in reusable roles. When you define variables in reusable variable files, the sensitive variables are separated from playbooks. This separation enables you to store your playbooks in a source control software and even share the playbooks, without the risk of exposing passwords or other sensitive and personal data. For information about creating reusable files and roles, see :ref:`playbooks_reuse`." -msgstr "変数は、再利用可能な変数ファイルや再利用可能なロールに定義することができます。再利用可能な変数ファイルに変数を定義すると、機密性の高い変数が Playbook から分離されます。この分離により、パスワードなどの機密情報や個人情報を流出させることなく、ソースコントロールソフトウェアに Playbook を保存したり、Playbook を共有したりすることができます。再利用可能なファイルやロールの作成は、「:ref:`playbooks_reuse`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:272 -msgid "This example shows how you can include variables defined in an external file:" -msgstr "この例は、外部ファイルで定義された変数を追加する方法を示しています。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:290 -msgid "The contents of each variables file is a simple YAML dictionary. For example:" -msgstr "各変数ファイルの内容は、単純な YAML ディクショナリーです。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:300 -msgid "You can keep per-host and per-group variables in similar files. To learn about organizing your variables, see :ref:`splitting_out_vars`." -msgstr "ホスト別およびグループ別の変数を同様のファイルに維持することができます。変数を整理する方法は、「:ref:`splitting_out_vars`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:305 -msgid "Defining variables at runtime" -msgstr "ランタイム時の変数の定義" - -#: ../../rst/playbook_guide/playbooks_variables.rst:307 -msgid "You can define variables when you run your playbook by passing variables at the command line using the ``--extra-vars`` (or ``-e``) argument. You can also request user input with a ``vars_prompt`` (see :ref:`playbooks_prompts`). When you pass variables at the command line, use a single quoted string, that contains one or more variables, in one of the formats below." -msgstr "Playbook の実行時に変数を定義するには、コマンドラインで ``--extra-vars`` (または ``-e``) 引数を使用して変数を渡します。また、``vars_prompt`` (:ref:`playbooks_prompts` 参照) でユーザーの入力を要求することもできます。コマンドラインで変数を渡すときは、以下のいずれかの形式で、1 つまたは複数の変数を含む一重引用符で囲まれた文字列を使用します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:310 -msgid "key=value format" -msgstr "key=value 形式" - -#: ../../rst/playbook_guide/playbooks_variables.rst:312 -msgid "Values passed in using the ``key=value`` syntax are interpreted as strings. Use the JSON format if you need to pass non-string values such as Booleans, integers, floats, lists, and so on." -msgstr "``key=value`` 構文を使用して渡される値は文字列として解釈されます。ブール値、整数、浮動小数点、リストなど、文字列以外の値を渡す必要がある場合は、JSON 形式を使用します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:319 -msgid "JSON string format" -msgstr "JSON 文字列の形式" - -#: ../../rst/playbook_guide/playbooks_variables.rst:326 -msgid "When passing variables with ``--extra-vars``, you must escape quotes and other special characters appropriately for both your markup (for example, JSON), and for your shell:" -msgstr "``--extra-vars`` で変数を渡す場合には、マークアップ (JSON など) とシェルの両方で、引用符やその他の特殊文字を適切にエスケープする必要があります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:336 -msgid "vars from a JSON or YAML file" -msgstr "JSON ファイルまたは YAML ファイルの変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:338 -msgid "If you have a lot of special characters, use a JSON or YAML file containing the variable definitions. Prepend both JSON and YAML filenames with `@`." -msgstr "特殊文字が多数ある場合は、変数定義を含む JSON ファイルまたは YAML ファイルを使用します。JSON および YAML ファイル名に `@` の接頭辞を付けます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:349 -msgid "Variable precedence: Where should I put a variable?" -msgstr "変数の優先順位: 変数をどこに置くべきか" - -#: ../../rst/playbook_guide/playbooks_variables.rst:351 -msgid "You can set multiple variables with the same name in many different places. When you do this, Ansible loads every possible variable it finds, then chooses the variable to apply based on variable precedence. In other words, the different variables will override each other in a certain order." -msgstr "同じ名前の複数の変数をさまざまな場所に設定することができます。これを行うと、Ansible は検出可能なすべての変数を読み込み、次に変数の優先順位に基づいて適用する変数を選択します。つまり、異なる変数が一定の順序で互いに上書きされます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:353 -msgid "Teams and projects that agree on guidelines for defining variables (where to define certain types of variables) usually avoid variable precedence concerns. We suggest that you define each variable in one place: figure out where to define a variable, and keep it simple. For examples, see :ref:`variable_examples`." -msgstr "変数の定義に関するガイドライン (特定のタイプの変数をどこで定義するか) に合意したチームやプロジェクトは、通常、変数の優先順位に関する懸念を回避することができます。各変数は、一箇所で定義することが推奨されます。どこで変数を定義するかを把握し、簡潔さを保ってください。例については、「:ref:`variable_examples`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:355 -msgid "Some behavioral parameters that you can set in variables you can also set in Ansible configuration, as command-line options, and using playbook keywords. For example, you can define the user Ansible uses to connect to remote devices as a variable with ``ansible_user``, in a configuration file with ``DEFAULT_REMOTE_USER``, as a command-line option with ``-u``, and with the playbook keyword ``remote_user``. If you define the same parameter in a variable and by another method, the variable overrides the other setting. This approach allows host-specific settings to override more general settings. For examples and more details on the precedence of these various settings, see :ref:`general_precedence_rules`." -msgstr "変数で設定できる動作パラメーターの中には、Ansible の構成、コマンドラインオプション、および Playbook キーワードで設定できるものがあります。たとえば、Ansible がリモートデバイスへの接続に使用するユーザーは、変数では ``ansible_user``、構成ファイルでは ``DEFAULT_REMOTE_USER``、コマンドラインオプションでは ``-u`` 、Playbook キーワードでは ``remote_user`` で定義できます。変数と別の方法で同じパラメーターを定義した場合は、変数が別の設定を上書きします。この方法では、ホスト固有の設定がより一般的な設定を上書きします。これらのさまざまな設定の優先順位の例や詳細は、「:ref:`general_precedence_rules`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:358 -msgid "Understanding variable precedence" -msgstr "変数の優先順位について" - -#: ../../rst/playbook_guide/playbooks_variables.rst:360 -msgid "Ansible does apply variable precedence, and you might have a use for it. Here is the order of precedence from least to greatest (the last listed variables override all other variables):" -msgstr "Ansible では変数の優先順位を適用しており、それを利用できる場合があります。ここでは、優先順位の低いものから高いものまでを紹介します (最後に挙げた変数が他のすべての変数を上書きします)。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:362 -msgid "command line values (for example, ``-u my_user``, these are not variables)" -msgstr "コマンドラインの値 (例: ``-u my_user`` (これらは変数ではありません))" - -#: ../../rst/playbook_guide/playbooks_variables.rst:363 -msgid "role defaults (defined in role/defaults/main.yml) [1]_" -msgstr "ロールのデフォルト(role/defaults/main.yml で定義) [1]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:364 -msgid "inventory file or script group vars [2]_" -msgstr "インベントリーファイルまたはスクリプトのグループ変数 [2]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:365 -msgid "inventory group_vars/all [3]_" -msgstr "インベントリー group_vars/all [3]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:366 -msgid "playbook group_vars/all [3]_" -msgstr "playbook group_vars/all [3]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:367 -msgid "inventory group_vars/* [3]_" -msgstr "インベントリー group_vars/* [3]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:368 -msgid "playbook group_vars/* [3]_" -msgstr "playbook group_vars/* [3]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:369 -msgid "inventory file or script host vars [2]_" -msgstr "インベントリーファイルまたはスクリプトホスト変数 [2]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:370 -msgid "inventory host_vars/* [3]_" -msgstr "インベントリー host_vars/* [3]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:371 -msgid "playbook host_vars/* [3]_" -msgstr "playbook host_vars/* [3]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:372 -msgid "host facts / cached set_facts [4]_" -msgstr "ホストファクト / キャッシュ済み set_facts [4]_" - -#: ../../rst/playbook_guide/playbooks_variables.rst:373 -msgid "play vars" -msgstr "プレイ変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:374 -msgid "play vars_prompt" -msgstr "play vars_prompt" - -#: ../../rst/playbook_guide/playbooks_variables.rst:375 -msgid "play vars_files" -msgstr "play vars_files" - -#: ../../rst/playbook_guide/playbooks_variables.rst:376 -msgid "role vars (defined in role/vars/main.yml)" -msgstr "role 変数 (role/vars/main.yml で定義)" - -#: ../../rst/playbook_guide/playbooks_variables.rst:377 -msgid "block vars (only for tasks in block)" -msgstr "ブロック変数 (ブロックのタスクにのみ適用)" - -#: ../../rst/playbook_guide/playbooks_variables.rst:378 -msgid "task vars (only for the task)" -msgstr "タスク変数 (タスク専用)" - -#: ../../rst/playbook_guide/playbooks_variables.rst:379 -msgid "include_vars" -msgstr "include_vars" - -#: ../../rst/playbook_guide/playbooks_variables.rst:380 -msgid "set_facts / registered vars" -msgstr "set_facts / 登録変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:381 -msgid "role (and include_role) params" -msgstr "role (および include_role) パラメーター" - -#: ../../rst/playbook_guide/playbooks_variables.rst:382 -msgid "include params" -msgstr "include パラメーター" - -#: ../../rst/playbook_guide/playbooks_variables.rst:383 -msgid "extra vars (for example, ``-e \"user=my_user\"``)(always win precedence)" -msgstr "追加の変数 (例: ``-e \"user=my_user\"``)(常に優先されます)" - -#: ../../rst/playbook_guide/playbooks_variables.rst:385 -msgid "In general, Ansible gives precedence to variables that were defined more recently, more actively, and with more explicit scope. Variables in the defaults folder inside a role are easily overridden. Anything in the vars directory of the role overrides previous versions of that variable in the namespace. Host and/or inventory variables override role defaults, but explicit includes such as the vars directory or an ``include_vars`` task override inventory variables." -msgstr "一般的に、Ansible は、より新しく、より積極的に、より明確なスコープで定義された変数を優先します。ロール内の defaults フォルダーにある変数は簡単に上書きされます。ロールの vars ディレクトリーにあるものは、名前空間内のその変数の以前のバージョンを上書きします。ホストおよび/またはインベントリー変数はロールのデフォルトを上書きしますが、vars ディレクトリーや ``include_vars`` タスクなどの明示的なインクルードはインベントリー変数を上書きします。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:387 -msgid "Ansible merges different variables set in inventory so that more specific settings override more generic settings. For example, ``ansible_ssh_user`` specified as a group_var is overridden by ``ansible_user`` specified as a host_var. For details about the precedence of variables set in inventory, see :ref:`how_we_merge`." -msgstr "Ansible は、インベントリーに設定した異なる変数をマージして、より特定の設定がより一般的な設定を上書きするようにします。たとえば、group_var として指定した ``ansible_ssh_user`` は、host_var として指定した ``ansible_user`` により上書きされます。インベントリーで設定された変数の優先順位の詳細については、「:ref:`how_we_merge`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:390 -msgid "Footnotes" -msgstr "注記" - -#: ../../rst/playbook_guide/playbooks_variables.rst:391 -msgid "Tasks in each role see their own role's defaults. Tasks defined outside of a role see the last role's defaults." -msgstr "各ロールのタスクには、それぞれのロールのデフォルト値が表示されます。ロールの外で定義されたタスクには、最後のロールのデフォルトが表示されます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:392 -msgid "Variables defined in inventory file or provided by dynamic inventory." -msgstr "インベントリーファイルで定義される変数、または動的インベントリーで指定される変数。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:393 -msgid "Includes vars added by 'vars plugins' as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible." -msgstr "「vars プラグイン」と、Ansible に同梱されるデフォルトの vars プラグインにより追加される host_vars および group_vars が含まれるインクルード変数。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:394 -msgid "When created with set_facts's cacheable option, variables have the high precedence in the play, but are the same as a host facts precedence when they come from the cache." -msgstr "set_facts のキャッシュ可能なオプションを使用して作成すると、変数がプレイに優先されますが、キャッシュからのホストのファクトと同様に優先されます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:397 -msgid "Within any section, redefining a var overrides the previous instance. If multiple groups have the same variable, the last one loaded wins. If you define a variable twice in a play's ``vars:`` section, the second one wins." -msgstr "どのセクションでも、変数を再定義すると前のインスタンスが上書きされます。複数のグループが同じ変数を持っている場合は、最後に読み込まれたものが優先されます。プレイ中の ``vars:`` のセクションで変数を 2 回定義した場合は、2 回目の変数が優先されます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:400 -msgid "The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite." -msgstr "以前は、デフォルトの設定 ``hash_behaviour=replace`` を説明し、``merge`` に切り替えてを部分的に上書きします。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:405 -msgid "Scoping variables" -msgstr "変数のスコープ設定" - -#: ../../rst/playbook_guide/playbooks_variables.rst:407 -msgid "You can decide where to set a variable based on the scope you want that value to have. Ansible has three main scopes:" -msgstr "変数をどこに設定するかは、その値が持つべきスコープに基づいて決めることができます。Ansible には大きく分けて 3 つのスコープがあります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:409 -msgid "Global: this is set by config, environment variables and the command line" -msgstr "グローバル: これは、設定、環境変数、およびコマンドラインで設定されます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:410 -msgid "Play: each play and contained structures, vars entries (vars; vars_files; vars_prompt), role defaults and vars." -msgstr "プレイ: 各プレイおよび含まれる構造、変数エントリー (vars、vars_files、vars_prompt)、ロールのデフォルト、および変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:411 -msgid "Host: variables directly associated to a host, like inventory, include_vars, facts or registered task outputs" -msgstr "ホスト: インベントリー、include_vars、ファクト、または登録されたタスクの出力などのホストに直接関連付けられる変数" - -#: ../../rst/playbook_guide/playbooks_variables.rst:413 -msgid "Inside a template, you automatically have access to all variables that are in scope for a host, plus any registered variables, facts, and magic variables." -msgstr "テンプレート内では、ホストのスコープ内にあるすべての変数と、登録済みの変数、ファクト、およびマジック変数に自動的にアクセスできます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:418 -msgid "Tips on where to set variables" -msgstr "変数を設定する場所に関するヒント" - -#: ../../rst/playbook_guide/playbooks_variables.rst:420 -msgid "You should choose where to define a variable based on the kind of control you might want over values." -msgstr "変数を定義する場所は、値をどのように制御するかによって選択する必要があります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:422 -msgid "Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: child groups override parent groups, and host variables override group variables. See :ref:`define_variables_in_inventory` for details on setting host and group variables." -msgstr "地理や動作を扱うインベントリーに変数を設定します。グループは、ホストにロールをマッピングするエンティティーであることが多いため、ロールに変数を定義する代わりに、グループに変数を設定することができます。子グループが親グループを上書きし、ホスト変数がグループ変数を上書きすることを忘れないでください。ホスト変数とグループ変数の設定の詳細は、「:ref:`define_variables_in_inventory`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:424 -msgid "Set common defaults in a ``group_vars/all`` file. See :ref:`splitting_out_vars` for details on how to organize host and group variables in your inventory. Group variables are generally placed alongside your inventory file, but they can also be returned by dynamic inventory (see :ref:`intro_dynamic_inventory`) or defined in AWX or on :ref:`ansible_platform` from the UI or API:" -msgstr "``group_vars/all`` ファイルで共通のデフォルトを設定します。インベントリーでホスト変数とグループ変数を整理する方法の詳細については、「:ref:`splitting_out_vars`」を参照してください。グループ変数は通常、インベントリーファイルと一緒に置かれますが、動的インベントリー (:ref:`intro_dynamic_inventory` を参照) で返されたり、AWX、または UI や API から :ref:`ansible_platform` で定義することもできます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:433 -msgid "Set location-specific variables in ``group_vars/my_location`` files. All groups are children of the ``all`` group, so variables set here override those set in ``group_vars/all``:" -msgstr "``group_vars/my_location`` ファイルにロケーション固有の変数を設定します。すべてのグループは ``all`` グループの子であるため、ここに設定される変数は ``group_vars/all`` で設定した変数を上書きします。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:441 -msgid "If one host used a different NTP server, you could set that in a host_vars file, which would override the group variable:" -msgstr "1 つのホストが別の NTP サーバーを使用している場合は、host_vars ファイルにそのホストを設定できます。これにより、グループ変数が上書きされます。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:449 -msgid "Set defaults in roles to avoid undefined-variable errors. If you share your roles, other users can rely on the reasonable defaults you added in the ``roles/x/defaults/main.yml`` file, or they can easily override those values in inventory or at the command line. See :ref:`playbooks_reuse_roles` for more info. For example:" -msgstr "未定義な変数エラーを防ぐために、ロールにデフォルト値を設定します。ロールを共有している場合、他のユーザーは、``roles/x/defaults/main.yml`` ファイルで追加した妥当なデフォルト値を信頼するか、インベントリーやコマンドラインで簡単にその値を上書きすることができます。詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:458 -msgid "Set variables in roles to ensure a value is used in that role, and is not overridden by inventory variables. If you are not sharing your role with others, you can define app-specific behaviors like ports this way, in ``roles/x/vars/main.yml``. If you are sharing roles with others, putting variables here makes them harder to override, although they still can by passing a parameter to the role or setting a variable with ``-e``:" -msgstr "ロールに変数を設定することで、値がそのロールで使用され、インベントリー変数で上書きされないようにします。ロールを他の人と共有していない場合は、ポートなどのアプリ固有の動作を、このように ``roles/x/vars/main.yml`` で定義できます。他の人とロールを共有している場合は、ここに変数を置くことで上書きされにくくなります。ただし、ロールにパラメーターを渡したり、``-e`` で変数を設定したりすれば、上書きされる可能性はあります。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:467 -msgid "Pass variables as parameters when you call roles for maximum clarity, flexibility, and visibility. This approach overrides any defaults that exist for a role. For example:" -msgstr "明確さ、柔軟性、および可視性を最大化するためにロールを呼び出す場合は、パラメーターとして変数を渡します。この方法では、ロールに存在するデフォルトを上書きします。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:476 -msgid "When you read this playbook it is clear that you have chosen to set a variable or override a default. You can also pass multiple values, which allows you to run the same role multiple times. See :ref:`run_role_twice` for more details. For example:" -msgstr "この Playbook を読むと、変数の設定やデフォルトの上書きを選択したことがわかります。また、複数の値を渡すことができるため、同じロールを複数回実行することができます。詳細は「:ref:`run_role_twice`」を参照してください。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:494 -msgid "Variables set in one role are available to later roles. You can set variables in a ``roles/common_settings/vars/main.yml`` file and use them in other roles and elsewhere in your playbook:" -msgstr "1 つのロールに設定された変数は、後のロールで使用できます。変数は、``roles/common_settings/vars/main.yml`` ファイルに設定して、他のロールや Playbook の他の場所で使用します。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:505 -msgid "There are some protections in place to avoid the need to namespace variables. In this example, variables defined in 'common_settings' are available to 'something' and 'something_else' tasks, but tasks in 'something' have foo set at 12, even if 'common_settings' sets foo to 20." -msgstr "変数の名前空間化の必要性を回避するために、いくつかの保護機能があります。この例では、「common_settings」で定義された変数は「something」と「something_else」のタスクで使用できますが、「common_settings」で foo が 20 に設定されていても、「something」のタスクでは foo が 12 に設定されています。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:508 -msgid "Instead of worrying about variable precedence, we encourage you to think about how easily or how often you want to override a variable when deciding where to set it. If you are not sure what other variables are defined, and you need a particular value, use ``--extra-vars`` (``-e``) to override all other variables." -msgstr "変数の優先順位を気にするのではなく、変数をどこに設定するかを決める際には、どれだけ簡単に、あるいはどれだけ頻繁に変数を上書きしたいかを考えることが推奨されます。他の変数がどのように定義されているかわからず、特定の値が必要な場合は、``--extra-vars`` (``-e``) を使用して、他のすべての変数を上書きします。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:511 -msgid "Using advanced variable syntax" -msgstr "高度な変数構文の使用" - -#: ../../rst/playbook_guide/playbooks_variables.rst:513 -msgid "For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see :ref:`playbooks_advanced_syntax`." -msgstr "変数を宣言するのに使用される高度な YAML 構文、および Ansible により使用される YAML ファイルにあるデータに対する制御の詳細は、「:ref:`playbooks_advanced_syntax`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_variables.rst:522 -msgid "Jinja2 filters and their uses" -msgstr "Jinja2 フィルターおよびその使用" - -#: ../../rst/playbook_guide/playbooks_variables.rst:529 -msgid ":ref:`special_variables`" -msgstr ":ref:`special_variables`" - -#: ../../rst/playbook_guide/playbooks_variables.rst:530 -msgid "List of special variables" -msgstr "特殊な変数のリスト" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:5 -msgid "Discovering variables: facts and magic variables" -msgstr "変数の検出: ファクトおよびマジック変数" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:7 -msgid "With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself. Variables related to remote systems are called facts. With facts, you can use the behavior or state of one system as configuration on other systems. For example, you can use the IP address of one system as a configuration value on another system. Variables related to Ansible are called magic variables." -msgstr "Ansible では、リモートシステムや Ansible 自体に関する情報を含む特定の変数を取得または検出を行うことができます。リモートシステムに関連する変数をファクトと呼びます。ファクトを使用すると、あるシステムの動作や状態を他のシステムの設定値として使用することができます。たとえば、あるシステムの IP アドレスを、他のシステムの設定値として使用することができます。Ansible に関連する変数をマジック変数と呼びます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:13 -msgid "Ansible facts" -msgstr "Ansible ファクト" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:15 -msgid "Ansible facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. You can access this data in the ``ansible_facts`` variable. By default, you can also access some Ansible facts as top-level variables with the ``ansible_`` prefix. You can disable this behavior using the :ref:`INJECT_FACTS_AS_VARS` setting. To see all available facts, add this task to a play:" -msgstr "Ansible のファクトは、オペレーティングシステム、IP アドレス、添付のファイルシステムなど、リモートシステムに関連するデータです。このデータには、``ansible_facts`` という変数でアクセスできます。デフォルトでは、一部の Ansible ファクトは、``ansible_`` というプレフィックスを持つトップレベルの変数としてアクセスすることもできます。この動作は、:ref:`INJECT_FACTS_AS_VARS` の設定で無効にすることができます。利用可能なすべてのファクトを表示するには、このタスクをプレイに追加します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:23 -msgid "To see the 'raw' information as gathered, run this command at the command line:" -msgstr "収集された「生」の情報を見るには、コマンドラインで次のコマンドを実行します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:29 -msgid "Facts include a large amount of variable data, which may look like this:" -msgstr "ファクトには大量の変数データが含まれており、それは次のようなものです。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:490 -msgid "You can reference the model of the first disk in the facts shown above in a template or playbook as:" -msgstr "上記のファクトの最初のディスクのモデルをテンプレートまたは Playbook で参照できます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:496 -msgid "To reference the system hostname:" -msgstr "システムのホスト名を参照するには、以下を実行します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:502 -msgid "You can use facts in conditionals (see :ref:`playbooks_conditionals`) and also in templates. You can also use facts to create dynamic groups of hosts that match particular criteria, see the :ref:`group_by module ` documentation for details." -msgstr "ファクトは、条件式 (:ref:`playbooks_conditionals` を参照) やテンプレートでも使用できます。また、ファクトを使用して、特定の条件に一致するホストの動的なグループを作成することもできます。詳細は、:ref:`group_by モジュール ` のドキュメントを参照してください。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:504 -#, python-format -msgid "Because ``ansible_date_time`` is created and cached when Ansible gathers facts before each playbook run, it can get stale with long-running playbooks. If your playbook takes a long time to run, use the ``pipe`` filter (for example, ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``) or :ref:`now() ` with a Jinja 2 template instead of ``ansible_date_time``." -msgstr "``ansible_date_time`` は、Ansible が各 Playbook の実行前にファクトを収集したときにキャッシュされるため、長時間実行される Playbook で古くなる可能性があります。Playbook の実行に長い時間がかかる場合は、``ansible_date_time`` ではなく Jinja 2 テンプレートで ``pipe`` フィルター（例: ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``）または :ref:`now() ` を使用します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:509 -msgid "Package requirements for fact gathering" -msgstr "ファクト収集のパッケージ要件" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:511 -msgid "On some distros, you may see missing fact values or facts set to default values because the packages that support gathering those facts are not installed by default. You can install the necessary packages on your remote hosts using the OS package manager. Known dependencies include:" -msgstr "一部のディストリビューションでは、ファクトの収集をサポートするパッケージがデフォルトでインストールされていないため、ファクトの値が見つからなかったり、ファクトがデフォルト値に設定されたりすることがあります。OS のパッケージマネージャーを使用して、リモートホストに必要なパッケージをインストールすることができます。既知の依存関係には以下のものがあります。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:513 -msgid "Linux Network fact gathering - Depends on the ``ip`` binary, commonly included in the ``iproute2`` package." -msgstr "Linux ネットワークファクト収集 - 一般的に ``iproute2`` パッケージに含まれる ``ip`` バイナリーによって異なります。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:518 -msgid "Caching facts" -msgstr "ファクトのキャッシュ" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:520 -msgid "Like registered variables, facts are stored in memory by default. However, unlike registered variables, facts can be gathered independently and cached for repeated use. With cached facts, you can refer to facts from one system when configuring a second system, even if Ansible executes the current play on the second system first. For example:" -msgstr "登録された変数と同様に、ファクトはデフォルトでメモリーに保存されます。ただし、登録された変数とは異なり、ファクトは独立して収集し、繰り返し使用するためにキャッシュすることができます。キャッシュされたファクトを使用すると、Ansible が 2 つ目のシステムで現在のプレイを最初に実行した場合でも、1 つのシステムのファクトを参照して 2 つ目のシステムを設定することができます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:526 -msgid "Caching is controlled by the cache plugins. By default, Ansible uses the memory cache plugin, which stores facts in memory for the duration of the current playbook run. To retain Ansible facts for repeated use, select a different cache plugin. See :ref:`cache_plugins` for details." -msgstr "キャッシュ処理は、キャッシュプラグインによって制御されます。デフォルトでは、Ansible はメモリーキャッシュプラグインを使用し、現在の Playbook の実行期間中、メモリーにファクトを保存します。Ansible のファクトを繰り返し使用するために保持するには、別のキャッシュプラグインを選択します。詳細は「:ref:`cache_plugins`」を参照してください。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:528 -msgid "Fact caching can improve performance. If you manage thousands of hosts, you can configure fact caching to run nightly, then manage configuration on a smaller set of servers periodically throughout the day. With cached facts, you have access to variables and information about all hosts even when you are only managing a small number of servers." -msgstr "ファクトキャッシュ処理はパフォーマンスを向上させます。何千台ものホストを管理している場合は、ファクトキャッシュ処理を毎晩実行するように設定し、小規模なサーバ群の設定を 1 日中定期的に管理することができます。キャッシュされたファクトがあれば、少数のサーバーしか管理していなくても、すべてのホストに関する変数および情報にアクセスすることができます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:533 -msgid "Disabling facts" -msgstr "ファクトの無効化" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:535 -msgid "By default, Ansible gathers facts at the beginning of each play. If you do not need to gather facts (for example, if you know everything about your systems centrally), you can turn off fact gathering at the play level to improve scalability. Disabling facts may particularly improve performance in push mode with very large numbers of systems, or if you are using Ansible on experimental platforms. To disable fact gathering:" -msgstr "デフォルトでは、Ansible は各プレイの開始時にファクトを収集します。ファクトを収集する必要がない場合 (たとえば、システムに関する情報をすべて一元的に把握している場合) は、プレイレベルでのファクト収集をオフにすることで、スケーラビリティーを向上させることができます。ファクトを無効にすると、非常に多数のシステムを使用するプッシュモードや、実験的なプラットフォームで Ansible を使用している場合に、特にパフォーマンスが向上することがあります。ファクトの収集を無効にするには、以下を行います。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:543 -msgid "Adding custom facts" -msgstr "カスタムファクトの追加" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:545 -msgid "The setup module in Ansible automatically discovers a standard set of facts about each host. If you want to add custom values to your facts, you can write a custom facts module, set temporary facts with a ``ansible.builtin.set_fact`` task, or provide permanent custom facts using the facts.d directory." -msgstr "Ansible のセットアップモジュールは、各ホストに関する標準的なファクトのセットを自動的に検出します。ファクトにカスタム値を追加したい場合は、カスタムファクトモジュールを記述したり、``ansible.builtin.set_fact`` タスクで一時的なファクトを設定したり、facts.d ディレクトリーを使用して恒久的なカスタムファクトを提供したりすることができます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:550 -msgid "facts.d or local facts" -msgstr "facts.d またはローカルファクト" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:554 -msgid "You can add static custom facts by adding static files to facts.d, or add dynamic facts by adding executable scripts to facts.d. For example, you can add a list of all users on a host to your facts by creating and running a script in facts.d." -msgstr "静的なカスタムファクトは、静的ファイルを facts.d に追加することで追加でき、動的なファクトは実行可能なスクリプトを facts.d に追加することで追加できます。たとえば、facts.d でスクリプトを作成して実行することにより、ホスト上のすべてのユーザーのリストをファクトに追加できます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:556 -msgid "To use facts.d, create an ``/etc/ansible/facts.d`` directory on the remote host or hosts. If you prefer a different directory, create it and specify it using the ``fact_path`` play keyword. Add files to the directory to supply your custom facts. All file names must end with ``.fact``. The files can be JSON, INI, or executable files returning JSON." -msgstr "facts.d を使用するには、リモートホストまたはホスト上に ``/etc/ansible/facts.d`` ディレクトリーを作成します。別のディレクトリーを使用する場合は、そのディレクトリーを作成し、プレイキーワード ``fact_path`` を使用して指定します。このディレクトリーにファイルを追加して、カスタムファクトを提供します。すべてのファイル名は、``.fact`` で終わる必要があります。ファイルには、JSON、INI、または JSON を返す実行可能ファイルを使用できます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:558 -msgid "To add static facts, simply add a file with the ``.fact`` extension. For example, create ``/etc/ansible/facts.d/preferences.fact`` with this content:" -msgstr "静的ファクトを追加するには、``.fact`` 拡張子を持つファイルを追加するだけです。たとえば、以下の内容で ``/etc/ansible/facts.d/preferences.fact`` を作成します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:566 -msgid "Make sure the file is not executable as this will break the ``ansible.builtin.setup`` module." -msgstr "``ansible.builtin.setup`` モジュールが壊れるため、このファイルが実行ファイルではないことを確認してください。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:568 -msgid "The next time fact gathering runs, your facts will include a hash variable fact named ``general`` with ``asdf`` and ``bar`` as members. To validate this, run the following:" -msgstr "次回、ファクト収集が実行されると、ファクトには、``asdf`` と ``bar`` をメンバーとする ``general`` という名前のハッシュ変数ファクトが含まれるようになります。これを検証するには、次のように実行します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:574 -msgid "And you will see your custom fact added:" -msgstr "これにより、カスタムファクトが追加されているのが確認できます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:589 -msgid "The ansible_local namespace separates custom facts created by facts.d from system facts or variables defined elsewhere in the playbook, so variables will not override each other. You can access this custom fact in a template or playbook as:" -msgstr "ansible_local 名前空間は、facts.d で作成されたカスタムファクトと、システムファクトや Playbook 内の他の場所で定義された変数を分離し、変数が互いに上書きされないようにします。このカスタムファクトには、テンプレートや Playbook で次のようにアクセスできます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:595 -msgid "The key part in the key=value pairs will be converted into lowercase inside the ansible_local variable. Using the example above, if the ini file contained ``XYZ=3`` in the ``[general]`` section, then you should expect to access it as: ``{{ ansible_local['preferences']['general']['xyz'] }}`` and not ``{{ ansible_local['preferences']['general']['XYZ'] }}``. This is because Ansible uses Python's `ConfigParser`_ which passes all option names through the `optionxform`_ method and this method's default implementation converts option names to lower case." -msgstr "鍵と値のペアの鍵の部分は、ansible_local 変数内で小文字に変換されます。上記の例では、ini ファイルの ``[general]`` セクションに ``XYZ=3`` が含まれていた場合は、``{{ ansible_local['preferences']['general']['XYZ'] }}`` ではなく、``{{ ansible_local['preferences']['general']['xyz'] }}`` としてアクセスすることになります。これは、Ansible が Python の `ConfigParser`_ を使用して、すべてのオプション名を `optionxform`_ メソッドに渡しており、このメソッドのデフォルトの実装では、オプション名が小文字に変換されるためです。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:600 -msgid "You can also use facts.d to execute a script on the remote host, generating dynamic custom facts to the ansible_local namespace. For example, you can generate a list of all users that exist on a remote host as a fact about that host. To generate dynamic custom facts using facts.d:" -msgstr "facts.d を使用して、リモートホスト上でスクリプトを実行し、ansible_local 名前空間に動的なカスタムファクトを生成することもできます。たとえば、リモートホストに存在するすべてのユーザーのリストを、そのホストに関するファクトとして生成することができます。facts.d を使用して動的なカスタムファクトを生成するには、以下の手順に従います。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:602 -msgid "Write and test a script to generate the JSON data you want." -msgstr "スクリプトを作成してテストして、必要な JSON データを生成します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:603 -msgid "Save the script in your facts.d directory." -msgstr "スクリプトを facts.d ディレクトリーに保存します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:604 -msgid "Make sure your script has the ``.fact`` file extension." -msgstr "スクリプトに ``.fact`` ファイル拡張子があることを確認します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:605 -msgid "Make sure your script is executable by the Ansible connection user." -msgstr "スクリプトが Ansible 接続ユーザーによって実行可能であることを確認します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:606 -msgid "Gather facts to execute the script and add the JSON output to ansible_local." -msgstr "スクリプトを実行するファクトを収集し、JSON 出力を ansible_local に追加します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:608 -msgid "By default, fact gathering runs once at the beginning of each play. If you create a custom fact using facts.d in a playbook, it will be available in the next play that gathers facts. If you want to use it in the same play where you created it, you must explicitly re-run the setup module. For example:" -msgstr "デフォルトでは、ファクトの収集は各プレイの開始時に一度だけ実行します。Playbook で facts.d を使用してカスタムファクトを作成すると、ファクトを収集する次のプレイで使用できるようになります。作成したのと同じプレイで使用したい場合は、セットアップモジュールを明示的に再実行する必要があります。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:630 -msgid "If you use this pattern frequently, a custom facts module would be more efficient than facts.d." -msgstr "このパターンを頻繁に使用すると、カスタムファクトモジュールは facts.d よりも効率が上がります。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:635 -msgid "Information about Ansible: magic variables" -msgstr "Ansible に関する情報: マジック変数" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:637 -msgid "You can access information about Ansible operations, including the python version being used, the hosts and groups in inventory, and the directories for playbooks and roles, using \"magic\" variables. Like connection variables, magic variables are :ref:`special_variables`. Magic variable names are reserved - do not set variables with these names. The variable ``environment`` is also reserved." -msgstr "使用している Python のバージョン、インベントリー内のホストやグループ、Playbook やロールのディレクトリーなど、Ansible の操作に関する情報は、「マジック」変数を使用してアクセスすることができます。接続変数と同様に、マジック変数は :ref:`special_variables` です。マジック変数の名前は予約済みです。これらの名前で変数を設定しないでください。変数 ``environment`` も予約済みです。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:639 -msgid "The most commonly used magic variables are ``hostvars``, ``groups``, ``group_names``, and ``inventory_hostname``. With ``hostvars``, you can access variables defined for any host in the play, at any point in a playbook. You can access Ansible facts using the ``hostvars`` variable too, but only after you have gathered (or cached) facts. Note that variables defined at play objects are not defined for specific hosts and therefore are not mapped to hostvars." -msgstr "最も一般的に使用されるマジック変数は、``hostvars``、``groups``、``group_names``、および ``inventory_hostname`` です。``hostvars`` を使用すると、Playbook 内の任意の時点で、プレイ内の任意のホストに対して定義された変数にアクセスできます。``hostvars`` 変数を使用して Ansible のファクトにアクセスすることもできますが、ファクトを収集 (またはキャッシュ) した後でなければなりません。プレイオブジェクトで定義された変数は特定のホストに対して定義されていないため、hostvars にマップされないことに注意してください。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:641 -msgid "If you want to configure your database server using the value of a 'fact' from another node, or the value of an inventory variable assigned to another node, you can use ``hostvars`` in a template or on an action line:" -msgstr "他のノードの「ファクト」の値や、他のノードに割り当てられたインベントリー変数の値を使用してデータベースサーバーを設定する場合は、テンプレートやアクション行で ``hostvars`` を使用することができます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:647 -msgid "With ``groups``, a list of all the groups (and hosts) in the inventory, you can enumerate all hosts within a group. For example:" -msgstr "``groups`` では、インベントリー内のすべてのグループ (およびホスト) のリストで、グループ内のすべてのホストを列挙できます。以下に例を示します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:655 -msgid "You can use ``groups`` and ``hostvars`` together to find all the IP addresses in a group." -msgstr "``groups`` と ``hostvars`` を一緒に使用して、グループ内のすべての IP アドレスを探すことができます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:663 -msgid "You can use this approach to point a frontend proxy server to all the hosts in your app servers group, to set up the correct firewall rules between servers, and so on. You must either cache facts or gather facts for those hosts before the task that fills out the template." -msgstr "この方法を使用して、フロントエンドプロキシーサーバーがアプリサーバーグループ内のすべてのホストを指すようにしたり、サーバー間に正しいファイアウォールルールを設定したりできます。テンプレートに入力するタスクの前に、ファクトをキャッシュするか、それらのホストのファクトを収集する必要があります。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:665 -msgid "With ``group_names``, a list (array) of all the groups the current host is in, you can create templated files that vary based on the group membership (or role) of the host:" -msgstr "``group_names`` では、現在のホストが置かれているすべてのグループのリスト (配列) は、ホストのグループメンバーシップ (またはロール) に基づいて異なるテンプレートファイルを作成できます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:673 -msgid "You can use the magic variable ``inventory_hostname``, the name of the host as configured in your inventory, as an alternative to ``ansible_hostname`` when fact-gathering is disabled. If you have a long FQDN, you can use ``inventory_hostname_short``, which contains the part up to the first period, without the rest of the domain." -msgstr "ファクト収集が無効になっているときには、``ansible_hostname`` の代わりに、インベントリーで設定されたホストの名前であるマジック変数 ``inventory_hostname`` を使用できます。長い FQDN がある場合には、最初のピリオドまでの部分を含み、ドメインの残りの部分を含まない ``inventory_hostname_short`` を使用することができます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:675 -msgid "Other useful magic variables refer to the current play or playbook. These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer." -msgstr "その他の有用なマジック変数は、現在のプレイや Playbook を参照します。これらの変数は、複数のホスト名でテンプレートを埋めるときや、ロードバランサーのルールにリストを注入するときに便利です。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:677 -msgid "``ansible_play_hosts`` is the list of all hosts still active in the current play." -msgstr "``ansible_play_hosts`` は、現在のプレイでアクティブなままになっているすべてのホストの完全なリストです。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:679 -msgid "``ansible_play_batch`` is a list of hostnames that are in scope for the current 'batch' of the play." -msgstr "``ansible_play_batch`` は、現在のプレイの「バッチ」の範囲内にあるホスト名のリストです。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:681 -msgid "The batch size is defined by ``serial``, when not set it is equivalent to the whole play (making it the same as ``ansible_play_hosts``)." -msgstr "バッチサイズは ``serial`` で定義されます。設定されていない場合は、プレイ全体に相当するようになります (``ansible_play_hosts`` と同じになります)。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:683 -msgid "``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool." -msgstr "``ansible_playbook_python`` は、Ansible コマンドラインツールを起動するのに使用される Python 実行ファイルへのパスです。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:685 -msgid "``inventory_dir`` is the pathname of the directory holding Ansible's inventory host file." -msgstr "``inventory_dir`` は、Ansible のインベントリーホストファイルを保持するディレクトリーのパス名です。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:687 -msgid "``inventory_file`` is the pathname and the filename pointing to the Ansible's inventory host file." -msgstr "``inventory_file`` は、Ansible のインベントリーホストファイルを参照するパス名とファイル名です。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:689 -msgid "``playbook_dir`` contains the playbook base directory." -msgstr "``playbook_dir`` には Playbook のベースディレクトリーが含まれます。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:691 -msgid "``role_path`` contains the current role's pathname and only works inside a role." -msgstr "``role_path`` には現在のロールのパス名が含まれ、ロール内でのみ動作します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:693 -msgid "``ansible_check_mode`` is a boolean, set to ``True`` if you run Ansible with ``--check``." -msgstr "``ansible_check_mode`` が ``--check`` で Ansible を実行する場合は ``True`` に設定します。" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:698 -msgid "Ansible version" -msgstr "Ansible のバージョン" - -#: ../../rst/playbook_guide/playbooks_vars_facts.rst:702 -msgid "To adapt playbook behavior to different versions of Ansible, you can use the variable ``ansible_version``, which has the following structure:" -msgstr "Playbook の動作をさまざまなバージョンの Ansible に適用するには、``ansible_version`` 変数を使用できます。この変数には、以下の構造があります。" - -#: ../../rst/playbook_guide/playbooks_vault.rst:4 -msgid "Using vault in playbooks" -msgstr "Playbook での Vault の使用" - -#: ../../rst/playbook_guide/playbooks_vault.rst:6 -msgid "The documentation regarding Ansible Vault has moved. The new location is here: :ref:`vault`. Please update any links you may have made directly to this page." -msgstr "Ansible Vault に関するドキュメントが移動しました。新しい場所は「:ref:`vault`」です。このページに直接作成した可能性のあるリンクを更新してください。" - -#~ msgid "If the option is a boolean value, you can use any of the boolean values recognized by Ansible: (such as true/false or yes/no). Choose the one that reads better in the context of the option." -#~ msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/plugins.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/plugins.po deleted file mode 100644 index 0a618d1138e..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/plugins.po +++ /dev/null @@ -1,1337 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/plugins/action.rst:4 ../../rst/plugins/cache.rst:123 -#: ../../rst/plugins/callback.rst:100 -msgid "Action plugins" -msgstr "action プラグイン" - -#: ../../rst/plugins/action.rst:10 -msgid "Action plugins act in conjunction with :ref:`modules ` to execute the actions required by playbook tasks. They usually execute automatically in the background doing prerequisite work before modules execute." -msgstr "action プラグインは、:ref:`modules ` と連携して、Playbook タスクに必要なアクションを実行します。これらは通常、モジュールが実行される前に、前提条件の作業を行うバックグラウンドで自動的に実行します。" - -#: ../../rst/plugins/action.rst:12 -msgid "The 'normal' action plugin is used for modules that do not already have an action plugin. If necessary, you can :ref:`create custom action plugins `." -msgstr "action プラグインが指定されていないモジュールには、「一般的な」action プラグインが使用されます。必要に応じて:ref:`create custom action plugins ` できます。" - -#: ../../rst/plugins/action.rst:17 -msgid "Enabling action plugins" -msgstr "action プラグインの有効化" - -#: ../../rst/plugins/action.rst:19 -msgid "You can enable a custom action plugin by either dropping it into the ``action_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the action plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの action プラグインを有効にするには、カスタムのプラグインを、ロール内のプレイの隣りにある ``action_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` に設定した action プラグインのディレクトリーソースの 1 つに配置します。" - -#: ../../rst/plugins/action.rst:24 -msgid "Using action plugins" -msgstr "action プラグインの使用" - -#: ../../rst/plugins/action.rst:26 -msgid "Action plugin are executed by default when an associated module is used; no action is required." -msgstr "action プラグインは、関連のモジュールを使用する場合にはデフォルトで実行するため、特に作業は必要ありません。" - -#: ../../rst/plugins/action.rst:29 ../../rst/plugins/cache.rst:115 -#: ../../rst/plugins/callback.rst:92 ../../rst/plugins/connection.rst:55 -#: ../../rst/plugins/filter.rst:43 ../../rst/plugins/inventory.rst:159 -#: ../../rst/plugins/lookup.rst:147 ../../rst/plugins/strategy.rst:57 -#: ../../rst/plugins/test.rst:78 ../../rst/plugins/vars.rst:53 -msgid "Plugin list" -msgstr "プラグイン一覧" - -#: ../../rst/plugins/action.rst:31 -msgid "You cannot list action plugins directly, they show up as their counterpart modules:" -msgstr "直接 action プラグインの一覧を表示することはできませんが、対応のモジュールとして表示されます。" - -#: ../../rst/plugins/action.rst:33 -msgid "Use ``ansible-doc -l`` to see the list of available modules. Use ``ansible-doc `` to see specific documentation and examples, this should note if the module has a corresponding action plugin." -msgstr "``ansible-doc -l`` を使用して、利用可能なモジュールの一覧を表示します。特定のドキュメントおよび例を参照するには ``ansible-doc `` を使用してください。モジュールに対応の action プラグインがある場合には、この点に注意してください。" - -#: ../../rst/plugins/action.rst:38 ../../rst/plugins/callback.rst:101 -#: ../../rst/plugins/vars.rst:60 -msgid ":ref:`cache_plugins`" -msgstr ":ref:`cache_plugins`" - -#: ../../rst/plugins/action.rst:39 ../../rst/plugins/cache.rst:4 -#: ../../rst/plugins/callback.rst:102 ../../rst/plugins/vars.rst:61 -msgid "Cache plugins" -msgstr "Cache プラグイン" - -#: ../../rst/plugins/action.rst:40 ../../rst/plugins/become.rst:56 -#: ../../rst/plugins/cache.rst:124 ../../rst/plugins/connection.rst:65 -#: ../../rst/plugins/filter.rst:54 ../../rst/plugins/inventory.rst:168 -#: ../../rst/plugins/lookup.rst:158 ../../rst/plugins/shell.rst:42 -#: ../../rst/plugins/strategy.rst:69 -msgid ":ref:`callback_plugins`" -msgstr ":ref:`callback_plugins`" - -#: ../../rst/plugins/action.rst:41 ../../rst/plugins/become.rst:57 -#: ../../rst/plugins/cache.rst:125 ../../rst/plugins/callback.rst:4 -#: ../../rst/plugins/connection.rst:66 ../../rst/plugins/filter.rst:55 -#: ../../rst/plugins/inventory.rst:169 ../../rst/plugins/shell.rst:43 -#: ../../rst/plugins/strategy.rst:70 -msgid "Callback plugins" -msgstr "callback プラグイン" - -#: ../../rst/plugins/action.rst:42 ../../rst/plugins/cache.rst:126 -#: ../../rst/plugins/callback.rst:103 ../../rst/plugins/inventory.rst:170 -#: ../../rst/plugins/terminal.rst:44 -msgid ":ref:`connection_plugins`" -msgstr ":ref:`connection_plugins`" - -#: ../../rst/plugins/action.rst:43 ../../rst/plugins/cache.rst:127 -#: ../../rst/plugins/callback.rst:104 ../../rst/plugins/connection.rst:4 -#: ../../rst/plugins/inventory.rst:171 ../../rst/plugins/terminal.rst:45 -msgid "Connection plugins" -msgstr "connection プラグイン" - -#: ../../rst/plugins/action.rst:44 ../../rst/plugins/become.rst:54 -#: ../../rst/plugins/cache.rst:128 ../../rst/plugins/callback.rst:105 -#: ../../rst/plugins/filter.rst:52 ../../rst/plugins/lookup.rst:156 -#: ../../rst/plugins/shell.rst:40 ../../rst/plugins/strategy.rst:67 -msgid ":ref:`inventory_plugins`" -msgstr ":ref:`inventory_plugins`" - -#: ../../rst/plugins/action.rst:45 ../../rst/plugins/become.rst:55 -#: ../../rst/plugins/cache.rst:129 ../../rst/plugins/callback.rst:106 -#: ../../rst/plugins/filter.rst:53 ../../rst/plugins/inventory.rst:4 -#: ../../rst/plugins/shell.rst:41 ../../rst/plugins/strategy.rst:68 -msgid "Inventory plugins" -msgstr "inventory プラグイン" - -#: ../../rst/plugins/action.rst:46 ../../rst/plugins/cache.rst:130 -#: ../../rst/plugins/callback.rst:107 -msgid ":ref:`shell_plugins`" -msgstr ":ref:`shell_plugins`" - -#: ../../rst/plugins/action.rst:47 ../../rst/plugins/cache.rst:131 -#: ../../rst/plugins/callback.rst:108 ../../rst/plugins/shell.rst:4 -msgid "Shell plugins" -msgstr "shell プラグイン" - -#: ../../rst/plugins/action.rst:48 ../../rst/plugins/cache.rst:132 -#: ../../rst/plugins/callback.rst:109 -msgid ":ref:`strategy_plugins`" -msgstr ":ref:`strategy_plugins`" - -#: ../../rst/plugins/action.rst:49 ../../rst/plugins/cache.rst:133 -#: ../../rst/plugins/callback.rst:110 ../../rst/plugins/strategy.rst:4 -msgid "Strategy plugins" -msgstr "strategy プラグイン" - -#: ../../rst/plugins/action.rst:50 ../../rst/plugins/cache.rst:134 -#: ../../rst/plugins/callback.rst:111 ../../rst/plugins/connection.rst:73 -#: ../../rst/plugins/inventory.rst:178 -msgid ":ref:`vars_plugins`" -msgstr ":ref:`vars_plugins`" - -#: ../../rst/plugins/action.rst:51 ../../rst/plugins/cache.rst:135 -#: ../../rst/plugins/callback.rst:112 ../../rst/plugins/connection.rst:74 -#: ../../rst/plugins/inventory.rst:179 ../../rst/plugins/vars.rst:4 -msgid "Vars plugins" -msgstr "vars プラグイン" - -#: ../../rst/plugins/action.rst:52 ../../rst/plugins/become.rst:64 -#: ../../rst/plugins/cliconf.rst:44 ../../rst/plugins/connection.rst:75 -#: ../../rst/plugins/docs_fragment.rst:32 ../../rst/plugins/filter.rst:60 -#: ../../rst/plugins/httpapi.rst:69 ../../rst/plugins/inventory.rst:180 -#: ../../rst/plugins/lookup.rst:164 ../../rst/plugins/module.rst:40 -#: ../../rst/plugins/module_util.rst:32 ../../rst/plugins/netconf.rst:44 -#: ../../rst/plugins/plugins.rst:45 ../../rst/plugins/shell.rst:50 -#: ../../rst/plugins/strategy.rst:77 ../../rst/plugins/terminal.rst:46 -#: ../../rst/plugins/test.rst:98 ../../rst/plugins/vars.rst:64 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/plugins/action.rst:53 ../../rst/plugins/become.rst:65 -#: ../../rst/plugins/cache.rst:137 ../../rst/plugins/callback.rst:114 -#: ../../rst/plugins/cliconf.rst:45 ../../rst/plugins/connection.rst:76 -#: ../../rst/plugins/docs_fragment.rst:33 ../../rst/plugins/filter.rst:61 -#: ../../rst/plugins/httpapi.rst:70 ../../rst/plugins/inventory.rst:181 -#: ../../rst/plugins/lookup.rst:165 ../../rst/plugins/module.rst:41 -#: ../../rst/plugins/module_util.rst:33 ../../rst/plugins/netconf.rst:45 -#: ../../rst/plugins/plugins.rst:46 ../../rst/plugins/shell.rst:51 -#: ../../rst/plugins/strategy.rst:78 ../../rst/plugins/terminal.rst:47 -#: ../../rst/plugins/test.rst:99 ../../rst/plugins/vars.rst:65 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/plugins/action.rst:54 ../../rst/plugins/become.rst:66 -#: ../../rst/plugins/cache.rst:138 ../../rst/plugins/callback.rst:115 -#: ../../rst/plugins/connection.rst:77 ../../rst/plugins/docs_fragment.rst:34 -#: ../../rst/plugins/filter.rst:62 ../../rst/plugins/inventory.rst:182 -#: ../../rst/plugins/lookup.rst:166 ../../rst/plugins/plugins.rst:47 -#: ../../rst/plugins/shell.rst:52 ../../rst/plugins/strategy.rst:79 -#: ../../rst/plugins/test.rst:100 ../../rst/plugins/vars.rst:66 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/plugins/action.rst:55 ../../rst/plugins/become.rst:67 -#: ../../rst/plugins/cache.rst:139 ../../rst/plugins/callback.rst:116 -#: ../../rst/plugins/connection.rst:78 ../../rst/plugins/docs_fragment.rst:35 -#: ../../rst/plugins/filter.rst:63 ../../rst/plugins/inventory.rst:183 -#: ../../rst/plugins/lookup.rst:167 ../../rst/plugins/plugins.rst:48 -#: ../../rst/plugins/shell.rst:53 ../../rst/plugins/strategy.rst:80 -#: ../../rst/plugins/test.rst:101 ../../rst/plugins/vars.rst:67 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/plugins/become.rst:4 -msgid "Become plugins" -msgstr "become プラグイン" - -#: ../../rst/plugins/become.rst:12 -msgid "Become plugins work to ensure that Ansible can use certain privilege escalation systems when running the basic commands to work with the target machine as well as the modules required to execute the tasks specified in the play." -msgstr "bocome プラグインは、基本的なコマンドの実行時に、Ansible が特定の特権昇格システムを使用して、プレイで指定されたタスクを実行するのに必要なモジュールやターゲットマシンと連携できるようにします。" - -#: ../../rst/plugins/become.rst:16 -msgid "These utilities (``sudo``, ``su``, ``doas``, and so on) generally let you 'become' another user to execute a command with the permissions of that user." -msgstr "通常、``sudo``、``su``、``doas`` などのユーティリティーを使用すると、別のユーザーになって (become)、そのユーザーのパーミッションでコマンドを実行できるようになります。" - -#: ../../rst/plugins/become.rst:23 -msgid "Enabling Become Plugins" -msgstr "become プラグインの有効化" - -#: ../../rst/plugins/become.rst:25 -msgid "The become plugins shipped with Ansible are already enabled. Custom plugins can be added by placing them into a ``become_plugins`` directory adjacent to your play, inside a role, or by placing them in one of the become plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "Ansible に同梱されている become プラグインはすでに有効になっています。カスタムのプラグインを追加するには、ロール内のプレイの隣りにある ``become_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定した become プラグインのディレクトリーソースの 1 つに配置します。" - -#: ../../rst/plugins/become.rst:33 -msgid "Using Become Plugins" -msgstr "become プラグインの使用" - -#: ../../rst/plugins/become.rst:35 -msgid "In addition to the default configuration settings in :ref:`ansible_configuration_settings` or the ``--become-method`` command line option, you can use the ``become_method`` keyword in a play or, if you need to be 'host specific', the connection variable ``ansible_become_method`` to select the plugin to use." -msgstr ":ref:`ansible_configuration_settings` や ``--become-method`` コマンドラインオプションでのデフォルト設定に加え、プレイで ``become_method`` キーワードを使用できます。「ホスト固有」にする必要がある場合は、接続変数 ``ansible_become_method`` で、使用するプラグインを選択します。" - -#: ../../rst/plugins/become.rst:39 ../../rst/plugins/shell.rst:33 -msgid "You can further control the settings for each plugin via other configuration options detailed in the plugin themselves (linked below)." -msgstr "プラグイン自体 (以下にリンク) に詳述されているその他の設定オプションを使用して、各プラグインの設定をさらに制御できます。" - -#: ../../rst/plugins/become.rst:45 -msgid "Plugin List" -msgstr "プラグイン一覧" - -#: ../../rst/plugins/become.rst:47 -msgid "You can use ``ansible-doc -t become -l`` to see the list of available plugins. Use ``ansible-doc -t become `` to see specific documentation and examples." -msgstr "``ansible-doc -t become -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t become `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/become.rst:52 ../../rst/plugins/filter.rst:50 -#: ../../rst/plugins/inventory.rst:166 ../../rst/plugins/lookup.rst:154 -#: ../../rst/plugins/module.rst:34 ../../rst/plugins/shell.rst:38 -#: ../../rst/plugins/strategy.rst:65 ../../rst/plugins/test.rst:86 -msgid ":ref:`about_playbooks`" -msgstr ":ref:`about_playbooks`" - -#: ../../rst/plugins/become.rst:53 ../../rst/plugins/connection.rst:64 -#: ../../rst/plugins/filter.rst:51 ../../rst/plugins/inventory.rst:167 -#: ../../rst/plugins/lookup.rst:155 ../../rst/plugins/module.rst:35 -#: ../../rst/plugins/shell.rst:39 ../../rst/plugins/strategy.rst:66 -#: ../../rst/plugins/test.rst:87 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/plugins/become.rst:58 ../../rst/plugins/connection.rst:67 -#: ../../rst/plugins/inventory.rst:172 ../../rst/plugins/lookup.rst:160 -#: ../../rst/plugins/shell.rst:44 ../../rst/plugins/strategy.rst:71 -#: ../../rst/plugins/test.rst:92 -msgid ":ref:`filter_plugins`" -msgstr ":ref:`filter_plugins`" - -#: ../../rst/plugins/become.rst:59 ../../rst/plugins/connection.rst:68 -#: ../../rst/plugins/filter.rst:4 ../../rst/plugins/inventory.rst:173 -#: ../../rst/plugins/shell.rst:45 ../../rst/plugins/strategy.rst:72 -#: ../../rst/plugins/test.rst:93 -msgid "Filter plugins" -msgstr "filter プラグイン" - -#: ../../rst/plugins/become.rst:60 ../../rst/plugins/connection.rst:69 -#: ../../rst/plugins/filter.rst:56 ../../rst/plugins/inventory.rst:174 -#: ../../rst/plugins/lookup.rst:162 ../../rst/plugins/shell.rst:46 -#: ../../rst/plugins/strategy.rst:73 -msgid ":ref:`test_plugins`" -msgstr ":ref:`test_plugins`" - -#: ../../rst/plugins/become.rst:61 ../../rst/plugins/connection.rst:70 -#: ../../rst/plugins/filter.rst:57 ../../rst/plugins/inventory.rst:175 -#: ../../rst/plugins/shell.rst:47 ../../rst/plugins/strategy.rst:74 -#: ../../rst/plugins/test.rst:4 -msgid "Test plugins" -msgstr "test プラグイン" - -#: ../../rst/plugins/become.rst:62 ../../rst/plugins/connection.rst:71 -#: ../../rst/plugins/filter.rst:58 ../../rst/plugins/inventory.rst:176 -#: ../../rst/plugins/shell.rst:48 ../../rst/plugins/strategy.rst:75 -#: ../../rst/plugins/test.rst:96 ../../rst/plugins/vars.rst:62 -msgid ":ref:`lookup_plugins`" -msgstr ":ref:`lookup_plugins`" - -#: ../../rst/plugins/become.rst:63 ../../rst/plugins/connection.rst:72 -#: ../../rst/plugins/filter.rst:59 ../../rst/plugins/inventory.rst:177 -#: ../../rst/plugins/lookup.rst:4 ../../rst/plugins/shell.rst:49 -#: ../../rst/plugins/strategy.rst:76 ../../rst/plugins/test.rst:97 -#: ../../rst/plugins/vars.rst:63 -msgid "Lookup plugins" -msgstr "lookup プラグイン" - -#: ../../rst/plugins/cache.rst:10 -msgid "Cache plugins allow Ansible to store gathered facts or inventory source data without the performance hit of retrieving them from source." -msgstr "cache プラグインを使用すると、Ansible は、ソースから取得するパフォーマンスに影響を与えずに、収集したファクトまたはインベントリーソースデータを保存できるようになります。" - -#: ../../rst/plugins/cache.rst:12 -msgid "The default cache plugin is the :ref:`memory ` plugin, which only caches the data for the current execution of Ansible. Other plugins with persistent storage are available to allow caching the data across runs. Some of these cache plugins write to files, others write to databases." -msgstr "デフォルトのキャッシュプラグインは :ref:`memory ` プラグインです。Ansible の現在の実行のデータのみをキャッシュします。永続ストレージを備えた他のプラグインを使用して、実行間でデータをキャッシュできます。これらのキャッシュプラグインの中にはファイルに書き込むものもあれば、データベースに書き込むものもあります。" - -#: ../../rst/plugins/cache.rst:14 -msgid "You can use different cache plugins for inventory and facts. If you enable inventory caching without setting an inventory-specific cache plugin, Ansible uses the fact cache plugin for both facts and inventory. If necessary, you can :ref:`create custom cache plugins `." -msgstr "インベントリーとファクトにさまざまな cache プラグインを使用できます。インベントリー固有の cache プラグインを設定せずにインベントリー固有のキャッシュを有効にした場合、Ansible は、ファクトとインベントリー両方に cache プラグインを使用します。必要に応じて:ref:`create custom cache plugins `できます。" - -#: ../../rst/plugins/cache.rst:19 -msgid "Enabling fact cache plugins" -msgstr "ファクトの cache プラグインの有効化" - -#: ../../rst/plugins/cache.rst:21 -msgid "Fact caching is always enabled. However, only one fact cache plugin can be active at a time. You can select the cache plugin to use for fact caching in the Ansible configuration, either with an environment variable:" -msgstr "ファクトキャッシングは常に有効になっています。ただし、一度にアクティブにできるファクトの cache プラグインは 1 つだけです。環境変数を使用して、Ansible 設定でファクトキャッシュに使用するキャッシュプラグインを選択できます。" - -#: ../../rst/plugins/cache.rst:27 ../../rst/plugins/cache.rst:54 -msgid "or in the ``ansible.cfg`` file:" -msgstr "または ``ansible.cfg`` ファイルで、以下を行います。" - -#: ../../rst/plugins/cache.rst:34 -msgid "If the cache plugin is in a collection use the fully qualified name:" -msgstr "cache プラグインをコレクションで使用する場合は、完全修飾名を使用してください。" - -#: ../../rst/plugins/cache.rst:41 -msgid "To enable a custom cache plugin, save it in a ``cache_plugins`` directory adjacent to your play, inside a role, or in one of the directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの cache プラグインを有効にするには、ロール内のプレイの隣りにある ``cache_plugins`` ディレクトリーに保存するか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに保存します。" - -#: ../../rst/plugins/cache.rst:43 -msgid "You also need to configure other settings specific to each plugin. Consult the individual plugin documentation or the Ansible :ref:`configuration ` for more details." -msgstr "また、各プラグインに固有の他の設定を構成する必要があります。個々のプラグインのドキュメントまたは Ansible の「:ref:`設定 `」を参照してください。" - -#: ../../rst/plugins/cache.rst:46 -msgid "Enabling inventory cache plugins" -msgstr "インベントリーの cache プラグインの有効化" - -#: ../../rst/plugins/cache.rst:48 -msgid "Inventory caching is disabled by default. To cache inventory data, you must enable inventory caching and then select the specific cache plugin you want to use. Not all inventory plugins support caching, so check the documentation for the inventory plugin(s) you want to use. You can enable inventory caching with an environment variable:" -msgstr "インベントリーキャッシュはデフォルトで無効になっています。インベントリーデータをキャッシュするには、インベントリーキャッシュを有効にしてから、使用する特定の cache プラグインを選択する必要があります。すべての intentory プラグインがキャッシュをサポートしているわけではないため、使用する inventory プラグインのドキュメントを確認してください。環境変数を使用してインベントリーキャッシュを有効にできます。" - -#: ../../rst/plugins/cache.rst:61 ../../rst/plugins/cache.rst:82 -msgid "or if the inventory plugin accepts a YAML configuration source, in the configuration file:" -msgstr "または、inventory プラグインが YAML 設定ソースに対応している場合は、設定ファイルで以下を指定します。" - -#: ../../rst/plugins/cache.rst:69 -msgid "Only one inventory cache plugin can be active at a time. You can set it with an environment variable:" -msgstr "一度にアクティブにできるインベントリーの cache プラグインは 1 つだけです。環境変数を使用して設定できます。" - -#: ../../rst/plugins/cache.rst:75 -msgid "or in the ansible.cfg file:" -msgstr "または、ansible.cfg ファイルで以下を設定します。" - -#: ../../rst/plugins/cache.rst:90 -msgid "To cache inventory with a custom plugin in your plugin path, follow the :ref:`developer guide on cache plugins`." -msgstr "プラグインパスにカスタムプラグインを使用してインベントリーをキャッシュするには、「:ref:`cache プラグインの開発者ガイド`」の手順に従ってください。" - -#: ../../rst/plugins/cache.rst:92 -msgid "To cache inventory with a cache plugin in a collection, use the FQCN:" -msgstr "コレクション内の cache プラグインを使用してインベントリーをキャッシュするには、FQCN を使用します。" - -#: ../../rst/plugins/cache.rst:99 -msgid "If you enable caching for inventory plugins without selecting an inventory-specific cache plugin, Ansible falls back to caching inventory with the fact cache plugin you configured. Consult the individual inventory plugin documentation or the Ansible :ref:`configuration ` for more details." -msgstr "インベントリー固有の cache プラグインを選択せずに inventory プラグインのキャッシュを有効にした場合、Ansible は、設定済みのファクトの cache プラグインでインベントリーのキャッシュが行われるようにフォールバックします。詳細は、inventory プラグインのドキュメント、または Ansible の「:ref:`設定 `」を参照してください。" - -#: ../../rst/plugins/cache.rst:107 -msgid "Using cache plugins" -msgstr "cache プラグインの使用" - -#: ../../rst/plugins/cache.rst:109 -msgid "Cache plugins are used automatically once they are enabled." -msgstr "cache プラグインは、有効になると自動的に使用されます。" - -#: ../../rst/plugins/cache.rst:117 -msgid "You can use ``ansible-doc -t cache -l`` to see the list of available plugins. Use ``ansible-doc -t cache `` to see specific documentation and examples." -msgstr "``ansible-doc -t cache -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t cache `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/cache.rst:122 ../../rst/plugins/callback.rst:99 -msgid ":ref:`action_plugins`" -msgstr ":ref:`action_plugins`" - -#: ../../rst/plugins/cache.rst:136 ../../rst/plugins/callback.rst:113 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/plugins/callback.rst:10 -msgid "Callback plugins enable adding new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs, but can also be used to add additional output, integrate with other tools and marshal the events to a storage backend. If necessary, you can :ref:`create custom callback plugins `." -msgstr "callback プラグインを使用すると、イベントに応答するときに Ansible に新しい動作を追加できます。デフォルトでは、callback プラグインは、コマンドラインプログラムを実行時に表示される出力の大半を制御しますが、他の出力を追加し、他のツールと統合し、ストレージバックエンドにイベントをマーシャリングすることにも使用できます。必要に応じて:ref:`create custom callback plugins `できます。" - -#: ../../rst/plugins/callback.rst:15 -msgid "Example callback plugins" -msgstr "callback プラグインの例" - -#: ../../rst/plugins/callback.rst:17 -msgid "The :ref:`log_plays ` callback is an example of how to record playbook events to a log file, and the :ref:`mail ` callback sends email on playbook failures." -msgstr ":ref:`log_plays ` のコールバックは、Playbook のイベントをログファイルに記録する一例で、:ref:`mail ` コールバックは Playbook の失敗時にメールを送信します。" - -#: ../../rst/plugins/callback.rst:19 -msgid "The :ref:`say ` callback responds with computer synthesized speech in relation to playbook events." -msgstr "また、:ref:`say ` コールバックは、Playbook のイベントに関連して、コンピューターで合成された音声で応答します。" - -#: ../../rst/plugins/callback.rst:24 -msgid "Enabling callback plugins" -msgstr "callback プラグインの有効化" - -#: ../../rst/plugins/callback.rst:26 -msgid "You can activate a custom callback by either dropping it into a ``callback_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the callback directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの callback を有効にするには、その callback を、ロール内のプレイの隣りにある ``callback_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定した callback ディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/callback.rst:28 -msgid "Plugins are loaded in alphanumeric order. For example, a plugin implemented in a file named `1_first.py` would run before a plugin file named `2_second.py`." -msgstr "プラグインは英数字順に読み込まれます。たとえば、`1_first.py` という名前で実装されているプラグインは、`2_second.py` という名前のプラグインファイルより先に実行されます。" - -#: ../../rst/plugins/callback.rst:30 -msgid "Most callbacks shipped with Ansible are disabled by default and need to be enabled in your :ref:`ansible.cfg ` file in order to function. For example:" -msgstr "Ansible に同梱されるほとんどの callback プラグインはデフォルトで無効になっており、このプラグインを機能させるには、:ref:`ansible.cfg ` ファイルで有効にする必要があります。以下に例を示します。" - -#: ../../rst/plugins/callback.rst:37 -msgid "Setting a callback plugin for ``ansible-playbook``" -msgstr "``ansible-playbook`` の callback プラグインの設定" - -#: ../../rst/plugins/callback.rst:39 -msgid "You can only have one plugin be the main manager of your console output. If you want to replace the default, you should define ``CALLBACK_TYPE = stdout`` in the subclass and then configure the stdout plugin in :ref:`ansible.cfg `. For example:" -msgstr "コンソール出力のメインマネージャーは、1 つのプラグインのみにすることができます。デフォルトを置き換える場合は、サブクラスに ``CALLBACK_TYPE = stdout`` を定義して、:ref:`ansible.cfg ` に stdout プラグインを設定する必要があります。以下に例を示します。" - -#: ../../rst/plugins/callback.rst:45 -msgid "or for my custom callback:" -msgstr "または、カスタムのコールバックの場合は以下を実行します。" - -#: ../../rst/plugins/callback.rst:51 -msgid "This only affects :ref:`ansible-playbook` by default." -msgstr "これは、デフォルトでは、:ref:`ansible-playbook` にのみ影響を及ぼします。" - -#: ../../rst/plugins/callback.rst:54 -msgid "Setting a callback plugin for ad hoc commands" -msgstr "アドホックコマンドへの callback プラグインの設定" - -#: ../../rst/plugins/callback.rst:56 -msgid "The :ref:`ansible` ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in :ref:`ansible_configuration_settings` you need to add to use the stdout callback defined above:" -msgstr ":ref:`ansible` アドホックコマンドは、特に stdout には別の callback プラグインを使用するため、上記に定義した stdout callback を使用するには、追加する必要がある :ref:`ansible_configuration_settings` にさらに設定を追加する必要があります。" - -#: ../../rst/plugins/callback.rst:63 -msgid "You can also set this as an environment variable:" -msgstr "これを環境変数として設定することもできます。" - -#: ../../rst/plugins/callback.rst:73 -msgid "Types of callback plugins" -msgstr "callback プラグインのタイプ" - -#: ../../rst/plugins/callback.rst:75 -msgid "There are three types of callback plugins:" -msgstr "callback プラグインには 3 種類あります。" - -#: ../../rst/plugins/callback.rst -msgid "stdout callback plugins" -msgstr "stdout callback プラグイン" - -#: ../../rst/plugins/callback.rst:79 -msgid "These plugins handle the main console output. Only one of these can be active." -msgstr "これらのプラグインは、メインコンソール出力を処理します。これらのうち、アクティブにできるのは 1 つだけです。" - -#: ../../rst/plugins/callback.rst -msgid "aggregate callback plugins" -msgstr "aggregate callback プラグイン" - -#: ../../rst/plugins/callback.rst:83 -msgid "Aggregate callbacks can add additional console output next to a stdout callback. This can be aggregate information at the end of a playbook run, additional per-task output, or anything else." -msgstr "aggregate callback は、stdout callback の隣に追加のコンソール出力を追加できます。これは、Playbook 実行の終了時の集計情報、追加のタスクごとの出力などの可能性があります。" - -#: ../../rst/plugins/callback.rst -msgid "notification callback plugins" -msgstr "notification callback プラグイン" - -#: ../../rst/plugins/callback.rst:87 -msgid "Notification callbacks inform other applications, services, or systems. This can be anything from logging to databases, informing on errors in Instant Messaging applications, or sending emails when a server is unreachable." -msgstr "notification callback は、他のアプリケーション、サービス、またはシステムに通知します。これには、データベースへのログ記録、インスタントメッセージングアプリケーションでのエラーの通知、サーバーに到達できない場合のメールの送信などがあります。" - -#: ../../rst/plugins/callback.rst:94 -msgid "You can use ``ansible-doc -t callback -l`` to see the list of available plugins. Use ``ansible-doc -t callback `` to see specific documents and examples." -msgstr "``ansible-doc -t callback -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t callback `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/cliconf.rst:4 -msgid "Cliconf plugins" -msgstr "cliconf プラグイン" - -#: ../../rst/plugins/cliconf.rst:10 -msgid "Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices." -msgstr "cliconf プラグインは、ネットワークデバイスへの CLI インターフェースを介した抽象化です。これらは、Ansible がこれらのネットワークデバイスでタスクを実行するための標準インターフェースを提供します。" - -#: ../../rst/plugins/cliconf.rst:12 -msgid "These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ``ansible_network_os`` variable." -msgstr "通常、これらのプラグインはネットワークデバイスのプラットフォームに 1 対 1 で対応します。Ansible は ``ansible_network_os`` 変数に基づいて適切な cliconf プラグインを自動的に読み込みます。" - -#: ../../rst/plugins/cliconf.rst:17 -msgid "Adding cliconf plugins" -msgstr "cliconf プラグインの追加" - -#: ../../rst/plugins/cliconf.rst:19 -msgid "You can extend Ansible to support other network devices by dropping a custom plugin into the ``cliconf_plugins`` directory." -msgstr "``cliconf_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他のネットワークデバイスをサポートするように拡張できます。" - -#: ../../rst/plugins/cliconf.rst:24 -msgid "Using cliconf plugins" -msgstr "cliconf プラグインの使用" - -#: ../../rst/plugins/cliconf.rst:26 -msgid "The cliconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality." -msgstr "使用する cliconf プラグインは ``ansible_network_os`` 変数から自動的に決定されます。この機能を上書きする理由はありません。" - -#: ../../rst/plugins/cliconf.rst:28 -msgid "Most cliconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into CLI commands." -msgstr "ほとんどの cliconf プラグインは設定なしで動作します。タスクが CLI コマンドにどのように変換されるかに影響する追加オプションがいくつかあります。" - -#: ../../rst/plugins/cliconf.rst:30 ../../rst/plugins/httpapi.rst:32 -#: ../../rst/plugins/netconf.rst:30 ../../rst/plugins/terminal.rst:30 -msgid "Plugins are self-documenting. Each plugin should document its configuration options." -msgstr "プラグインは自己文書化されています。プラグインごとに、設定オプションについて文書化する必要があります。" - -#: ../../rst/plugins/cliconf.rst:35 -msgid "Viewing cliconf plugins" -msgstr "cliconf プラグインの表示" - -#: ../../rst/plugins/cliconf.rst:37 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several cliconf plugins. To list all available cliconf plugins on your control node, type ``ansible-doc -t cliconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t cliconf``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の cliconf プラグインにアクセスできます。コントロールノードで利用可能な cliconf プラグインの一覧を表示するには、``ansible-doc -t cliconf -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t cliconf`` を使用します。" - -#: ../../rst/plugins/cliconf.rst:42 ../../rst/plugins/httpapi.rst:65 -#: ../../rst/plugins/netconf.rst:42 ../../rst/plugins/terminal.rst:42 -msgid ":ref:`Ansible for Network Automation`" -msgstr ":ref:`Ansible for Network Automation`" - -#: ../../rst/plugins/cliconf.rst:43 ../../rst/plugins/httpapi.rst:66 -#: ../../rst/plugins/netconf.rst:43 ../../rst/plugins/terminal.rst:43 -msgid "An overview of using Ansible to automate networking devices." -msgstr "Ansible を使用したネットワークデバイスの自動化の概要" - -#: ../../rst/plugins/cliconf.rst:46 ../../rst/plugins/httpapi.rst:71 -#: ../../rst/plugins/module.rst:42 ../../rst/plugins/module_util.rst:34 -#: ../../rst/plugins/netconf.rst:46 ../../rst/plugins/terminal.rst:48 -msgid "`irc.libera.chat `_" -msgstr "`irc.libera.chat `_" - -#: ../../rst/plugins/cliconf.rst:47 ../../rst/plugins/httpapi.rst:72 -#: ../../rst/plugins/netconf.rst:47 ../../rst/plugins/terminal.rst:49 -msgid "#ansible-network IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-network)" - -#: ../../rst/plugins/connection.rst:10 -msgid "Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time." -msgstr "connection プラグインにより、Ansible はターゲットホストに接続してそのホストにあるタスクを実行できるようにします。Ansible には多くの connection プラグインが同梱されていますが、一度に使用できるのは 1 つのみとなります。" - -#: ../../rst/plugins/connection.rst:12 -msgid "By default, Ansible ships with several connection plugins. The most commonly used are the :ref:`paramiko SSH`, native ssh (just called :ref:`ssh`), and :ref:`local` connection types. All of these can be used in playbooks and with :command:`/usr/bin/ansible` to decide how you want to talk to remote machines. If necessary, you can :ref:`create custom connection plugins `." -msgstr "デフォルトでは、Ansible には複数の connection プラグインが同梱されています。最も一般的に使用されるものは、:ref:`paramiko SSH` ネイティブ ssh (ただ :ref:`ssh` と呼ばれます)、および :ref:`local` 接続タイプです。これらはすべて、リモートマシンとの通信方法を決定するために Playbook と :command:`/usr/bin/ansible` で使用できます。必要に応じて:ref:`create custom connection plugins ` ができます。" - -#: ../../rst/plugins/connection.rst:14 -msgid "The basics of these connection types are covered in the :ref:`getting started` section." -msgstr "このような接続タイプの基本情報は、:ref:`getting started` のセクションで説明しています。" - -#: ../../rst/plugins/connection.rst:19 -msgid "``ssh`` plugins" -msgstr "``ssh`` プラグイン" - -#: ../../rst/plugins/connection.rst:21 -msgid "Because ssh is the default protocol used in system administration and the protocol most used in Ansible, ssh options are included in the command line tools. See :ref:`ansible-playbook` for more details." -msgstr "ssh は、システム管理で使用されるデフォルトのプロトコルであり、Ansible で最も使用されるプロトコルでもあるため、コマンドラインツールに ssh オプションが含まれています。詳細は、「:ref:`ansible-playbook`」を参照してください。" - -#: ../../rst/plugins/connection.rst:26 -msgid "Adding connection plugins" -msgstr "connection プラグインの追加" - -#: ../../rst/plugins/connection.rst:28 -msgid "You can extend Ansible to support other transports (such as SNMP or message bus) by dropping a custom plugin into the ``connection_plugins`` directory." -msgstr "カスタムのプラグインを ``connection_plugins`` ディレクトリーに置いて、他のトランスポート (SNMP やメッセージバスなど) をサポートするように Ansible を拡張できます。" - -#: ../../rst/plugins/connection.rst:34 -msgid "Using connection plugins" -msgstr "connection プラグインの使用" - -#: ../../rst/plugins/connection.rst:36 -msgid "You can set the connection plugin globally via :ref:`configuration`, at the command line (``-c``, ``--connection``), as a :ref:`keyword ` in your play, or by setting a :ref:`variable`, most often in your inventory. For example, for Windows machines you might want to set the :ref:`winrm ` plugin as an inventory variable." -msgstr "connection プラグインは、:ref:`設定`、コマンドライン (``-c``、``--connection``)を経由するか、プレイの :ref:`キーワード ` として使用するか、インベントリーにある :ref:`変数` を設定すること (もっとも多い例) で設定できます。たとえば、Windows マシンでは :ref:`winrm ` プラグインをインベントリー変数として設定できます。" - -#: ../../rst/plugins/connection.rst:39 -msgid "Most connection plugins can operate with minimal configuration. By default they use the :ref:`inventory hostname` and defaults to find the target host." -msgstr "ほとんどの connection プラグインは最小設定で動作します。デフォルトでは :ref:`インベントリーのホスト名` を使用し、デフォルトではターゲットホストを検索します。" - -#: ../../rst/plugins/connection.rst:41 -msgid "Plugins are self-documenting. Each plugin should document its configuration options. The following are connection variables common to most connection plugins:" -msgstr "プラグインは自己文書化されています。各プラグインは、その設定オプションを文書化する必要があります。以下は、ほとんどの connection プラグインに共通する接続変数です。" - -#: ../../rst/plugins/connection.rst:43 -msgid ":ref:`ansible_host`" -msgstr ":ref:`ansible_host`" - -#: ../../rst/plugins/connection.rst:44 -msgid "The name of the host to connect to, if different from the :ref:`inventory ` hostname." -msgstr "接続するホストの名前 (:ref:`インベントリー ` のホスト名と異なる場合)。" - -#: ../../rst/plugins/connection.rst:45 -msgid ":ref:`ansible_port`" -msgstr ":ref:`ansible_port`" - -#: ../../rst/plugins/connection.rst:46 -msgid "The ssh port number, for :ref:`ssh ` and :ref:`paramiko_ssh ` it defaults to 22." -msgstr ":ref:`ssh ` および :ref:`paramiko_ssh ` の場合は ssh ポート番号。デフォルトは 22 です。" - -#: ../../rst/plugins/connection.rst:48 -msgid ":ref:`ansible_user`" -msgstr ":ref:`ansible_user`" - -#: ../../rst/plugins/connection.rst:48 -msgid "The default user name to use for log in. Most plugins default to the 'current user running Ansible'." -msgstr "ログインに使用するデフォルトのユーザー名。ほとんどのプラグインはデフォルトで Ansible を実行している現在のユーザーです。" - -#: ../../rst/plugins/connection.rst:50 -msgid "Each plugin might also have a specific version of a variable that overrides the general version. For example, ``ansible_ssh_host`` for the :ref:`ssh ` plugin." -msgstr "プラグインごとに、一般的なバージョンを上書きする特定の変数バージョンが存在する場合もあります。たとえば、:ref:`ssh ` プラグインの場合は ``ansible_ssh_host`` です。" - -#: ../../rst/plugins/connection.rst:57 -msgid "You can use ``ansible-doc -t connection -l`` to see the list of available plugins. Use ``ansible-doc -t connection `` to see detailed documentation and examples." -msgstr "``ansible-doc -t connection -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t connection `` を使用して、詳細なドキュメントと例を参照してください。" - -#: ../../rst/plugins/connection.rst:63 -msgid ":ref:`Working with Playbooks`" -msgstr ":ref:`Working with Playbooks`" - -#: ../../rst/plugins/docs_fragment.rst:4 -msgid "Docs fragments" -msgstr "ドキュメントフラグメント" - -#: ../../rst/plugins/docs_fragment.rst:10 -msgid "Docs fragments allow you to document common parameters of multiple plugins or modules in a single place." -msgstr "このドキュメントフラグメントを使用すると、複数のプラグインまたはモジュールの共通のパラメーターを 1 カ所で文書化できます。" - -#: ../../rst/plugins/docs_fragment.rst:15 -msgid "Enabling docs fragments" -msgstr "ドキュメントフラグメントの有効化" - -#: ../../rst/plugins/docs_fragment.rst:17 -msgid "You can add a custom docs fragment by dropping it into a ``doc_fragments`` directory adjacent to your collection or role, just like any other plugin." -msgstr "他のプラグインと同様に、コレクションやロールに隣接する ``doc_fragments`` ディレクトリーに置くことで、カスタムドキュメントフラグメントを追加できます。" - -#: ../../rst/plugins/docs_fragment.rst:22 -msgid "Using docs fragments" -msgstr "ドキュメントフラグメントの使用" - -#: ../../rst/plugins/docs_fragment.rst:24 -msgid "Only collection developers and maintainers use docs fragments. For more information on using docs fragments, see :ref:`module_docs_fragments` or :ref:`docfragments_collections`." -msgstr "コレクション開発者およびメンテナンス管理者のみがドキュメントフラグメントを使用します。ドキュメントフラグメントの使用方法は、「:ref:`module_docs_fragments`」または「:ref:`docfragments_collections`」を参照してください。" - -#: ../../rst/plugins/docs_fragment.rst:28 ../../rst/plugins/module.rst:36 -#: ../../rst/plugins/module_util.rst:28 -msgid ":ref:`developing_modules_general`" -msgstr ":ref:`developing_modules_general`" - -#: ../../rst/plugins/docs_fragment.rst:29 ../../rst/plugins/module.rst:37 -#: ../../rst/plugins/module_util.rst:29 -msgid "An introduction to creating Ansible modules" -msgstr "Ansible モジュール作成の概要" - -#: ../../rst/plugins/docs_fragment.rst:30 ../../rst/plugins/module.rst:38 -#: ../../rst/plugins/module_util.rst:30 -msgid ":ref:`developing_collections`" -msgstr ":ref:`developing_collections`" - -#: ../../rst/plugins/docs_fragment.rst:31 ../../rst/plugins/module.rst:39 -#: ../../rst/plugins/module_util.rst:31 -msgid "An guide to creating Ansible collections" -msgstr "Ansible コレクションの作成ガイド" - -#: ../../rst/plugins/filter.rst:10 -msgid "Filter plugins manipulate data. With the right filter you can extract a particular value, transform data types and formats, perform mathematical calculations, split and concatenate strings, insert dates and times, and do much more. Ansible uses the :ref:`standard filters ` shipped with Jinja2 and adds some specialized filter plugins. You can :ref:`create custom Ansible filters as plugins `." -msgstr "Filter プラグインはデータを操作します。適切なフィルターを使用すると、特定の値の抽出、データ型と形式の変換、数学的な計算の実行、連結文字列や連結文字列の実行、日付と時間の挿入などを行うことができます。Ansible は Jinja2 に同梱されている :ref:`standard filters ` を使用して、特別な filter プラグインを追加します。:ref:`create custom Ansible filters as plugins ` が可能です。" - -#: ../../rst/plugins/filter.rst:15 -msgid "Enabling filter plugins" -msgstr "filter プラグインの有効化" - -#: ../../rst/plugins/filter.rst:17 -msgid "You can add a custom filter plugin by dropping it into a ``filter_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the filter plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの filter プラグインを追加するには、そのプラグインを、ロール内のプレイの隣りにある ``filter_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/filter.rst:22 -msgid "Using filter plugins" -msgstr "filter プラグインの使用" - -#: ../../rst/plugins/filter.rst:24 -msgid "You can use filters anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using filter plugins, see :ref:`playbooks_filters`. Filters can return any type of data, but if you want to always return a boolean (``True`` or ``False``) you should be looking at a test instead." -msgstr "フィルターは、プレイ、変数ファイル、あるいは :ref:`template ` モジュールの Jinja2 テンプレートでクラスなど、Ansible の中でテンプレートを使用できる場所であれば使用できます。フィルタープラグインの使用の詳細は、:ref:`playbooks_filters` を参照してください。フィルターは任意のタイプのデータを返すことができますが、常にブール値 (``True`` または ``False``) を返す場合は、代わりにテストする必要があります。" - -#: ../../rst/plugins/filter.rst:31 -msgid "Filters are the preferred way to manipulate data in Ansible, you can identify a filter because it is normally preceded by a ``|``, with the expression on the left of it being the first input of the filter. Additional parameters may be passed into the filter itself as you would to most programming functions. These parameters can be either ``positional`` (passed in order) or ``named`` (passed as key=value pairs). When passing both types, positional arguments should go first." -msgstr "フィルターは、Ansible でデータを操作するのに推奨される方法です。フィルターは、通常 ``|`` の前にあり、フィルターの左側にある式はフィルターの最初の入力であるため、特定できます。ほとんどのプログラミング関数と同様に、追加のパラメーターはフィルター自体に渡すことができます。これらのパラメーターは、``positional`` (順番に渡す) または ``named`` のいずれかになります。両方のタイプを渡す場合は、位置引数が最初に指定する必要があります。" - -#: ../../rst/plugins/filter.rst:39 -msgid "In the documentation, filters will always have a C(_input) option that corresponds to the expression to the left of c(|). A C(positional:) field in the documentation will show which options are positional and in which order they are required." -msgstr "ドキュメントでは、フィルターには常に c(|) の左側の式に対応する C(_input) オプションがあります。ドキュメントの AC(positional:) フィールドは、どのオプションが位置引数で、どの順番に実行する必要があるかを示します。" - -#: ../../rst/plugins/filter.rst:45 ../../rst/plugins/test.rst:80 -msgid "You can use ``ansible-doc -t filter -l`` to see the list of available plugins. Use ``ansible-doc -t filter `` to see specific documents and examples." -msgstr "``ansible-doc -t filter -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t filter `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/httpapi.rst:4 -msgid "Httpapi plugins" -msgstr "httpapi プラグイン" - -#: ../../rst/plugins/httpapi.rst:10 -msgid "Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the device." -msgstr "httpapi プラグインは、Ansible に対して、リモートデバイスの HTTP ベースの API と対話して、そのデバイスでタスクを実行する方法を指示します。" - -#: ../../rst/plugins/httpapi.rst:13 -msgid "Each plugin represents a particular dialect of API. Some are platform-specific (Arista eAPI, Cisco NXAPI), while others might be usable on a variety of platforms (RESTCONF). Ansible loads the appropriate httpapi plugin automatically based on the ``ansible_network_os`` variable." -msgstr "各プラグインは、特定の API 方言を表します。プラットフォーム固有のもの (Arista eAPI、Cisco NXAPI) があり、さまざまなプラットフォーム (RESTCONF) を使用できる場合があります。Ansible は ``ansible_network_os`` 変数に基づいて適切な httpapi プラグインを自動的に読み込みます。" - -#: ../../rst/plugins/httpapi.rst:19 -msgid "Adding httpapi plugins" -msgstr "httpapi プラグインの追加" - -#: ../../rst/plugins/httpapi.rst:21 -msgid "You can extend Ansible to support other APIs by dropping a custom plugin into the ``httpapi_plugins`` directory. See :ref:`developing_plugins_httpapi` for details." -msgstr "``httpapi_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他の API をサポートするように拡張できます。詳細は、「:ref:`developing_plugins_httpapi`」を参照してください。" - -#: ../../rst/plugins/httpapi.rst:26 -msgid "Using httpapi plugins" -msgstr "httpapi プラグインの使用" - -#: ../../rst/plugins/httpapi.rst:28 -msgid "The httpapi plugin to use is determined automatically from the ``ansible_network_os`` variable." -msgstr "使用する httpapi プラグインは、``ansible_network_os`` 変数から自動的に判断されます。" - -#: ../../rst/plugins/httpapi.rst:30 -msgid "Most httpapi plugins can operate without configuration. Additional options may be defined by each plugin." -msgstr "ほとんどの httpapi プラグインは設定なしで動作します。追加オプションは各プラグインで定義できます。" - -#: ../../rst/plugins/httpapi.rst:35 -msgid "The following sample playbook shows the httpapi plugin for an Arista network device, assuming an inventory variable set as ``ansible_network_os=eos`` for the httpapi plugin to trigger off:" -msgstr "以下の Playbook サンプルでは、Arista ネットワークデバイスの httpapi プラグインについて示します。この例では、インベントリー変数を ``ansible_network_os=eos`` に設定して httpapi プラグインがオフになるようにトリガーすることを想定しています。" - -#: ../../rst/plugins/httpapi.rst:54 -msgid "See the full working example `on GitHub `_." -msgstr "`GitHub `_ にある完全な作業例を参照してください。" - -#: ../../rst/plugins/httpapi.rst:59 -msgid "Viewing httpapi plugins" -msgstr "httpapi プラグインの表示" - -#: ../../rst/plugins/httpapi.rst:61 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several httpapi plugins. To list all available httpapi plugins on your control node, type ``ansible-doc -t httpapi -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t httpapi``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の httpapi プラグインにアクセスできます。コントロールノードで利用可能な httpapi プラグインの一覧を表示するには、``ansible-doc -t httpapi -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t httpapi`` を使用します。" - -#: ../../rst/plugins/httpapi.rst:67 -msgid ":ref:`Developing network modules`" -msgstr ":ref:`Developing network modules`" - -#: ../../rst/plugins/httpapi.rst:68 -msgid "How to develop network modules." -msgstr "ネットワークモジュールの開発方法" - -#: ../../rst/plugins/inventory.rst:10 -msgid "Inventory plugins allow users to point at data sources to compile the inventory of hosts that Ansible uses to target tasks, either using the ``-i /path/to/file`` and/or ``-i 'host1, host2'`` command line parameters or from other configuration sources. If necessary, you can :ref:`create custom inventory plugins `." -msgstr "inventory プラグインでは、``-i /path/to/file`` や ``-i 'host1, host2'`` コマンドラインパラメーターを使用したり、他の設定ソースを使用したりして、Ansible がタスクの対象として使用するホストのインベントリーをコンパイルするためのデータソースを指定できます。必要に応じて:ref:`create custom inventory plugins `できます。" - -#: ../../rst/plugins/inventory.rst:15 -msgid "Enabling inventory plugins" -msgstr "inventory プラグインの有効化" - -#: ../../rst/plugins/inventory.rst:17 -msgid "Most inventory plugins shipped with Ansible are enabled by default or can be used by with the ``auto`` plugin." -msgstr "Ansible に同梱されるほとんどの inventory プラグインはデフォルトで有効になっているか、``auto`` プラグインで使用することができます。" - -#: ../../rst/plugins/inventory.rst:19 -msgid "In some circumstances, for example, if the inventory plugin does not use a YAML configuration file, you may need to enable the specific plugin. You can do this by setting ``enable_plugins`` in your :ref:`ansible.cfg ` file in the ``[inventory]`` section. Modifying this will override the default list of enabled plugins. Here is the default list of enabled plugins that ships with Ansible:" -msgstr "たとえば、インベントリープラグインが YAML 設定ファイルを使用しない場合は、特定のプラグインを有効にする必要があります。これを行うには、``[inventory]`` セクションの :ref:`ansible.cfg ` ファイルで ``enable_plugins`` を設定します。これを変更すると、有効化されたプラグインのデフォルト一覧が上書きされます。以下は、Ansible に同梱される有効なプラグインのデフォルト一覧です。" - -#: ../../rst/plugins/inventory.rst:26 -msgid "If the plugin is in a collection and is not being picked up by the `auto` statement, you can append the fully qualified name:" -msgstr "プラグインがコレクションにあり、`auto` ステートメントで取得されていない場合は、完全修飾名を追加できます。" - -#: ../../rst/plugins/inventory.rst:33 -msgid "Or, if it is a local plugin, perhaps stored in the path set by :ref:`DEFAULT_INVENTORY_PLUGIN_PATH`, you could reference it as follows:" -msgstr "または、ローカルのプラグインdで、:ref:`DEFAULT_INVENTORY_PLUGIN_PATH` で設定されたパスに保存されている場合には、以下のように参照できます。" - -#: ../../rst/plugins/inventory.rst:40 -msgid "If you use a plugin that supports a YAML configuration source, make sure that the name matches the name provided in the ``plugin`` entry of the inventory source file." -msgstr "YAML 設定ソースをサポートするプラグインを使用する場合は、名前がインベントリーソースファイルの ``plugin`` エントリーで指定された名前と一致していることを確認してください。" - -#: ../../rst/plugins/inventory.rst:45 -msgid "Using inventory plugins" -msgstr "inventory プラグインの使用" - -#: ../../rst/plugins/inventory.rst:47 -msgid "To use an inventory plugin, you must provide an inventory source. Most of the time this is a file containing host information or a YAML configuration file with options for the plugin. You can use the ``-i`` flag to provide inventory sources or configure a default inventory path." -msgstr "inventory プラグインを使用するには、インベントリーソースを指定する必要があります。そのほとんどは、プラグインのオプションを持つホスト情報または YAML 設定ファイルを含むファイルです。``-i`` フラグを使用してインベントリーソースを提供するか、デフォルトのインベントリーパスを設定することができます。" - -#: ../../rst/plugins/inventory.rst:53 -msgid "To start using an inventory plugin with a YAML configuration source, create a file with the accepted filename schema documented for the plugin in question, then add ``plugin: plugin_name``. Use the fully qualified name if the plugin is in a collection." -msgstr "YAML 設定ソースで inventory プラグインの使用を開始するには、該当するプラグインで文書化されている受け入れ可能なファイル名のスキーマでファイルを作成し、そのファイルに ``plugin: plugin_name`` を追加します。プラグインがコレクションにある場合は、完全修飾名を使用します。" - -#: ../../rst/plugins/inventory.rst:60 -msgid "Each plugin should document any naming restrictions. In addition, the YAML config file must end with the extension ``yml`` or ``yaml`` to be enabled by default with the ``auto`` plugin (otherwise, see the section above on enabling plugins)." -msgstr "各プラグインは命名制限について記載する必要があります。また、YAML 設定ファイルは、``auto`` プラグインでデフォルトで有効にする拡張子 ``yml`` または ``yaml`` で終了する必要があります (同様に、プラグインを有効にする際の上記のセクションを参照してください)。" - -#: ../../rst/plugins/inventory.rst:62 -msgid "After providing any required options, you can view the populated inventory with ``ansible-inventory -i demo.aws_ec2.yml --graph``:" -msgstr "必要なオプションを指定したら、``ansible-inventory -i demo.aws_ec2.yml --graph`` で設定され追加されたインベントリーを表示できます。" - -#: ../../rst/plugins/inventory.rst:72 -msgid "If you are using an inventory plugin in a playbook-adjacent collection and want to test your setup with ``ansible-inventory``, use the ``--playbook-dir`` flag." -msgstr "Playbook に隣接するコレクションで inventory プラグインを使用して、``ansible-inventory`` で設定をテストするには、``--playbook-dir`` フラグを使用する必要があります。" - -#: ../../rst/plugins/inventory.rst:74 -msgid "Your inventory source might be a directory of inventory configuration files. The constructed inventory plugin only operates on those hosts already in inventory, so you may want the constructed inventory configuration parsed at a particular point (such as last). Ansible parses the directory recursively, alphabetically. You cannot configure the parsing approach, so name your files to make it work predictably. Inventory plugins that extend constructed features directly can work around that restriction by adding constructed options in addition to the inventory plugin options. Otherwise, you can use ``-i`` with multiple sources to impose a specific order, for example ``-i demo.aws_ec2.yml -i clouds.yml -i constructed.yml``." -msgstr "インベントリーソースは、インベントリー設定ファイルのディレクトリーである場合があります。構築した inventory プラグインは、インベントリーにすでに存在するホストでのみ動作するため、特定のタイミング (「最後」など) で構築したインベントリー設定を解析してください。Ansible は、ディレクトリーを再帰的にアルファベットで解析します。解析アプローチは設定できないため、想定通りに機能するように、ファイルの名前を指定します。構築した機能を直接拡張した inventory プラグインは、inventory プラグインのオプションに構築したオプションを追加し、制約を回避して機能させることができます。それ以外の場合は、複数ソースに ``-i`` を使用して特定の順番を指定します (例: ``-i demo.aws_ec2.yml -i clouds.yml -i constructed.yml``)。" - -#: ../../rst/plugins/inventory.rst:76 -msgid "You can create dynamic groups using host variables with the constructed ``keyed_groups`` option. The option ``groups`` can also be used to create groups and ``compose`` creates and modifies host variables. Here is an aws_ec2 example utilizing constructed features:" -msgstr "構築した ``keyed_groups`` オプションとホスト変数を使用して、動的なグループを作成できます。``groups`` オプションを使用してグループを作成し、``compose`` でホスト変数を作成して変更できます。以下は、構築した機能を使用する aws_ec2 のサンプルです。" - -#: ../../rst/plugins/inventory.rst:109 -msgid "Now the output of ``ansible-inventory -i demo.aws_ec2.yml --graph``:" -msgstr "これで、``ansible-inventory -i demo.aws_ec2.yml --graph`` の出力が表示されます。" - -#: ../../rst/plugins/inventory.rst:129 -msgid "If a host does not have the variables in the configuration above (in other words, ``tags.Name``, ``tags``, ``private_ip_address``), the host will not be added to groups other than those that the inventory plugin creates and the ``ansible_host`` host variable will not be modified." -msgstr "上記の設定でホストに変数がない場合には (つまり ``tags.Name``、``tags``、``private_ip_address``)、ホストは inventory プラグインが作成したグループ以外には追加されず、また ``ansible_host`` のホスト変数も変更されません。" - -#: ../../rst/plugins/inventory.rst:131 -msgid "Inventory plugins that support caching can use the general settings for the fact cache defined in the ``ansible.cfg`` file's ``[defaults]`` section or define inventory-specific settings in the ``[inventory]`` section. Individual plugins can define plugin-specific cache settings in their config file:" -msgstr "キャッシュをサポートする inventory プラグインは、``ansible.cfg`` ファイルの ``[defaults]`` セクションに定義されたファクトキャッシュの一般設定を使用するか、``[inventory]`` セクションにインベントリー固有の設定を定義することができます。個々のプラグインは、設定ファイルでプラグイン固有のキャッシュ設定を定義できます。" - -#: ../../rst/plugins/inventory.rst:143 -msgid "Here is an example of setting inventory caching with some fact caching defaults for the cache plugin used and the timeout in an ``ansible.cfg`` file:" -msgstr "以下は、``ansible.cfg`` ファイルに、使用する chache プラグインにデフォルト設定されているファクトキャッシュの一部を使用したインベントリーキャッシュと、タイムアウトを設定する例です。" - -#: ../../rst/plugins/inventory.rst:161 -msgid "You can use ``ansible-doc -t inventory -l`` to see the list of available plugins. Use ``ansible-doc -t inventory `` to see plugin-specific documentation and examples." -msgstr "``ansible-doc -t inventory -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t inventory `` を使用して、プラグイン固有のドキュメントと例を参照してください。" - -#: ../../rst/plugins/lookup.rst:10 -msgid "Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks. Like all :ref:`templating `, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. You can use lookup plugins to load variables or templates with information from external sources. You can :ref:`create custom lookup plugins `." -msgstr "lookup プラグインは、Jinja2 テンプレート言語への Ansible 固有の拡張です。lookup プラグインを使用して、Playbook 内の外部ソース (ファイル、データベース、キー/値のストア、API、その他のサービス) からデータにアクセスできます。:ref:`templating ` はすべて、Ansible 制御マシンで lookup を実行し、評価されます。Ansible は、標準の一時システムで利用可能な lookup プラグインにより返されたデータを提供します。lookup プラグインを使用すると、変数やテンプレートに外部ソースからの情報を読み込むことができます。:ref:`create custom lookup plugins ` できます。" - -#: ../../rst/plugins/lookup.rst:13 -msgid "Lookups are executed with a working directory relative to the role or play, as opposed to local tasks, which are executed relative the executed script." -msgstr "ルックアップは、ロールやプレイに相対する作業ディレクトリーで実行されます。一方、ローカルタスクは、実行されたスクリプトに相対して実行されます。" - -#: ../../rst/plugins/lookup.rst:15 -msgid "Pass ``wantlist=True`` to lookups to use in Jinja2 template \"for\" loops." -msgstr "``wantlist=True`` を lookup に渡して、Jinja2 テンプレート「for」ループで使用できます。" - -#: ../../rst/plugins/lookup.rst:16 -msgid "By default, lookup return values are marked as unsafe for security reasons. If you trust the outside source your lookup accesses, pass ``allow_unsafe=True`` to allow Jinja2 templates to evaluate lookup values." -msgstr "デフォルトでは、ルックアップの戻り値はセキュリティー上の理由で安全でないと識別されます。ルックアップがアクセスする外部ソースを信頼する場合は、``allow_unsafe=True`` を渡して Jinja2 テンプレートがルックアップ値を評価できるようにします。" - -#: ../../rst/plugins/lookup.rst:19 -msgid "Some lookups pass arguments to a shell. When using variables from a remote/untrusted source, use the `|quote` filter to ensure safe usage." -msgstr "ルックアップの中には、シェルに引数を渡すものがあります。リモート/信頼されていないソースから変数を使用する場合には、`|quote` フィルターを使用して、安全に使用できるようにします。" - -#: ../../rst/plugins/lookup.rst:25 -msgid "Enabling lookup plugins" -msgstr "lookup プラグインの有効化" - -#: ../../rst/plugins/lookup.rst:27 -msgid "Ansible enables all lookup plugins it can find. You can activate a custom lookup by either dropping it into a ``lookup_plugins`` directory adjacent to your play, inside the ``plugins/lookup/`` directory of a collection you have installed, inside a standalone role, or in one of the lookup directory sources configured in :ref:`ansible.cfg `." -msgstr "Ansibleは、検出したすべての lookup プラグインを有効にします。カスタム lookup を有効にするには、プレイに隣接する ``lookup_plugins`` ディレクトリー、インストールしたコレクションの ``plugins/lookup/`` ディレクトリー、スタンドアロンロール、または :ref:`ansible.cfg ` で設定したルックアップディレクトリソースのいずれかに置きます。" - -#: ../../rst/plugins/lookup.rst:33 -msgid "Using lookup plugins" -msgstr "lookup プラグインの使用" - -#: ../../rst/plugins/lookup.rst:35 -msgid "You can use lookup plugins anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using lookup plugins, see :ref:`playbooks_lookups`." -msgstr "lookup プラグインは、Ansible でテンプレートを使用できる場所で使用できます。これはプレイ、変数ファイル、または :ref:`template ` モジュールの Jinja2 テンプレートで使用できます。lookup プラグインの使用の詳細は、:ref:`playbooks_lookups` を参照してください。" - -#: ../../rst/plugins/lookup.rst:42 -msgid "Lookups are an integral part of loops. Wherever you see ``with_``, the part after the underscore is the name of a lookup. For this reason, lookups are expected to output lists; for example, ``with_items`` uses the :ref:`items ` lookup:" -msgstr "lookup はループには欠かせない要素です。``with_`` と表示される場合は、アンダースコアの後の部分が lookup の名前になります。このような理由から、lookup はリストを出力することが想定されます。たとえば、``with_items`` は :ref:`items ` lookup を使用します。" - -#: ../../rst/plugins/lookup.rst:51 -msgid "You can combine lookups with :ref:`filters `, :ref:`tests ` and even each other to do some complex data generation and manipulation. For example:" -msgstr "lookup と :ref:`filters `、:ref:`tests `、またはそれぞれを組み合わせて複雑なデータ生成やデータ操作が可能です。以下に例を示します。" - -#: ../../rst/plugins/lookup.rst:65 -msgid "You can control how errors behave in all lookup plugins by setting ``errors`` to ``ignore``, ``warn``, or ``strict``. The default setting is ``strict``, which causes the task to fail if the lookup returns an error. For example:" -msgstr "``errors`` を ``ignore``、``warn``、または ``strict`` に設定して、すべての lookup プラグインでエラーの動作を制御できます。デフォルト設定は ``strict`` で、lookup がエラーを返すとタスクは失敗します。以下に例を示します。" - -#: ../../rst/plugins/lookup.rst:67 -msgid "To ignore lookup errors:" -msgstr "lookup エラーを無視するには、以下を行います。" - -#: ../../rst/plugins/lookup.rst:83 -msgid "To get a warning instead of a failure:" -msgstr "失敗させるのではなく警告を出すには、以下を使用します。" - -#: ../../rst/plugins/lookup.rst:101 -msgid "To get a fatal error (the default):" -msgstr "致命的なエラーを取得する (デフォルト) には、以下を行います::" - -#: ../../rst/plugins/lookup.rst:118 -msgid "Forcing lookups to return lists: ``query`` and ``wantlist=True``" -msgstr "ルックアップが強制的にリストを返すようにする： ``query`` および ``wantlist=True``" - -#: ../../rst/plugins/lookup.rst:122 -msgid "In Ansible 2.5, a new Jinja2 function called ``query`` was added for invoking lookup plugins. The difference between ``lookup`` and ``query`` is largely that ``query`` will always return a list. The default behavior of ``lookup`` is to return a string of comma separated values. ``lookup`` can be explicitly configured to return a list using ``wantlist=True``." -msgstr "Ansible 2.5 では、lookup プラグインを呼び出すために ``query`` と呼ばれる新しい Jinja2 関数が追加されました。``lookup`` と ``query`` の相違点は、``query`` が常にリストを返すことです。``lookup`` のデフォルト動作は、コンマ区切りの値の文字列を返すことです。``lookup`` は、``wantlist=True`` を使用してリストを返すように明示的に設定できます。" - -#: ../../rst/plugins/lookup.rst:125 -msgid "This feature provides an easier and more consistent interface for interacting with the new ``loop`` keyword, while maintaining backwards compatibility with other uses of ``lookup``." -msgstr "この機能により、新しい ``loop`` キーワードを操作するための、より簡単で一貫性のあるインターフェースが提供され、同時に ``lookup`` の他の使い方との後方互換性も維持されます。" - -#: ../../rst/plugins/lookup.rst:127 -msgid "The following examples are equivalent:" -msgstr "以下の例はどちらも同等の操作ができます。" - -#: ../../rst/plugins/lookup.rst:135 -msgid "As demonstrated above, the behavior of ``wantlist=True`` is implicit when using ``query``." -msgstr "上記の例のように、``query`` を使用する場合、``wantlist=True`` の動作は暗黙的になります。" - -#: ../../rst/plugins/lookup.rst:137 -msgid "Additionally, ``q`` was introduced as a shortform of ``query``:" -msgstr "また、``query`` の短縮形となる ``q`` が導入されました。" - -#: ../../rst/plugins/lookup.rst:149 -msgid "You can use ``ansible-doc -t lookup -l`` to see the list of available plugins. Use ``ansible-doc -t lookup `` to see specific documents and examples." -msgstr "``ansible-doc -t lookup -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t lookup `` を使用して、特定のドキュメントと例を参照してください。" - -#: ../../rst/plugins/lookup.rst:157 -msgid "Ansible inventory plugins" -msgstr "Ansible inventory プラグインの使用" - -#: ../../rst/plugins/lookup.rst:159 -msgid "Ansible callback plugins" -msgstr "Ansible callback プラグイン" - -#: ../../rst/plugins/lookup.rst:161 -msgid "Jinja2 filter plugins" -msgstr "Jinja2 filter プラグイン" - -#: ../../rst/plugins/lookup.rst:163 -msgid "Jinja2 test plugins" -msgstr "Jinja2 test プラグイン" - -#: ../../rst/plugins/module.rst:4 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/plugins/module.rst:10 -msgid "Modules are the main building blocks of Ansible playbooks. Although we do not generally speak of \"module plugins\", a module is a type of plugin. For a developer-focused description of the differences between modules and other plugins, see :ref:`modules_vs_plugins`." -msgstr "モジュールは Ansible Playbook の主なビルディングブロックです。一般的には「module プラグイン」はあまり言及されませんが、モジュールはプラグインの一種です。モジュールと他のプラグインの相違点に関する開発者向けの説明は「:ref:`modules_vs_plugins`」を参照してください。" - -#: ../../rst/plugins/module.rst:15 -msgid "Enabling modules" -msgstr "モジュールの有効化" - -#: ../../rst/plugins/module.rst:17 -msgid "You can enable a custom module by dropping it into one of these locations:" -msgstr "カスタムモジュールは、以下の場所のいずれかに配置します。" - -#: ../../rst/plugins/module.rst:19 -msgid "any directory added to the ``ANSIBLE_LIBRARY`` environment variable (``$ANSIBLE_LIBRARY`` takes a colon-separated list like ``$PATH``)" -msgstr "``ANSIBLE_LIBRARY`` 環境変数に追加されたディレクトリー (``$ANSIBLE_LIBRARY`` は ``$PATH`` のようにコロンで区切った一覧)" - -#: ../../rst/plugins/module.rst:20 -msgid "``~/.ansible/plugins/modules/``" -msgstr "``~/.ansible/plugins/modules/``" - -#: ../../rst/plugins/module.rst:21 -msgid "``/usr/share/ansible/plugins/modules/``" -msgstr "``/usr/share/ansible/plugins/modules/``" - -#: ../../rst/plugins/module.rst:23 -msgid "For more information on using local custom modules, see :ref:`local_modules`." -msgstr "ローカルカスタムモジュールの使用方法は、「:ref:`local_modules`」を参照してください。" - -#: ../../rst/plugins/module.rst:28 -msgid "Using modules" -msgstr "モジュールの使用" - -#: ../../rst/plugins/module.rst:30 -msgid "For information on using modules in ad hoc tasks, see :ref:`intro_adhoc`. For information on using modules in playbooks, see :ref:`playbooks_intro`." -msgstr "アドホックタスクでモジュールを使用する方法は、「:ref:`intro_adhoc`」を参照してください。Playbook でモジュールを使用する方法は、「:ref:`playbooks_intro`」を参照してください。" - -#: ../../rst/plugins/module.rst:43 ../../rst/plugins/module_util.rst:35 -msgid "#ansible-devel IRC chat channel" -msgstr "IRC チャットチャンネル (#ansible-devel)" - -#: ../../rst/plugins/module_util.rst:4 -msgid "Module utilities" -msgstr "モジュールユーティリティー" - -#: ../../rst/plugins/module_util.rst:10 -msgid "Module utilities contain shared code used by multiple plugins. You can write :ref:`custom module utilities `." -msgstr "モジュールユーティリティーには、複数のプラグインが使用する共有コードが含まれています。:ref:`custom module utilities ` を記述できます。" - -#: ../../rst/plugins/module_util.rst:15 -msgid "Enabling module utilities" -msgstr "モジュールユーティリティーの有効化" - -#: ../../rst/plugins/module_util.rst:17 -msgid "You can add a custom module utility by dropping it into a ``module_utils`` directory adjacent to your collection or role, just like any other plugin." -msgstr "他のプラグインと同様に、コレクションやロールに隣接する ``module_utils`` ディレクトリーに置くことで、カスタムモジュールフラグメントを追加できます。" - -#: ../../rst/plugins/module_util.rst:22 -msgid "Using module utilities" -msgstr "モジュールユーティリティーの使用" - -#: ../../rst/plugins/module_util.rst:24 -msgid "For information on using module utilities, see :ref:`developing_module_utilities`." -msgstr "モジュールユーティリティーの使用方法は、「:ref:`developing_module_utilities`」を参照してください。" - -#: ../../rst/plugins/netconf.rst:4 -msgid "Netconf plugins" -msgstr "netconf プラグイン" - -#: ../../rst/plugins/netconf.rst:10 -msgid "Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices." -msgstr "netconf プラグインは、ネットワークデバイスへの Netconf インターフェイスを介した抽象化です。これらは、Ansible がこれらのネットワークデバイスでタスクを実行するための標準インターフェースを提供します。" - -#: ../../rst/plugins/netconf.rst:12 -msgid "These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate netconf plugin automatically based on the ``ansible_network_os`` variable. If the platform supports standard Netconf implementation as defined in the Netconf RFC specification, Ansible loads the ``default`` netconf plugin. If the platform supports propriety Netconf RPCs, Ansible loads the platform-specific netconf plugin." -msgstr "これらのプラグインは通常、ネットワークデバイスプラットフォームに 1 対 1 に対応します。Ansible は ``ansible_network_os`` 変数に基づいて適切な netconf プラグインを自動的に読み込みます。プラットフォームが Netconf の RFC 仕様で定義されている標準の Netconf 実装をサポートする場合、Ansible は ``default`` netconf プラグインを読み込みます。プラットフォームがプロプライエタリーな Netconf RPC をサポートする場合、Ansible はプラットフォーム固有の netconf プラグインを読み込みます。" - -#: ../../rst/plugins/netconf.rst:17 -msgid "Adding netconf plugins" -msgstr "netconf プラグインの追加" - -#: ../../rst/plugins/netconf.rst:19 -msgid "You can extend Ansible to support other network devices by dropping a custom plugin into the ``netconf_plugins`` directory." -msgstr "``netconf_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他のネットワークデバイスをサポートするように拡張できます。" - -#: ../../rst/plugins/netconf.rst:24 -msgid "Using netconf plugins" -msgstr "netconf プラグインの使用" - -#: ../../rst/plugins/netconf.rst:26 -msgid "The netconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality." -msgstr "使用する netconf プラグインは ``ansible_network_os`` 変数から自動的に決定されます。この機能を上書きする理由はありません。" - -#: ../../rst/plugins/netconf.rst:28 -msgid "Most netconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into netconf commands. A ncclient device specific handler name can be set in the netconf plugin or else the value of ``default`` is used as per ncclient device handler." -msgstr "ほとんどの netconf プラグインは設定せずに動作します。タスクがどのように netconf コマンドに変換されるかに影響を与えるように設定できる追加オプションがいくつかあります。ncclient デバイス固有のハンドラー名は netconf プラグインで設定するか、ncclient デバイスハンドラーごとに ``default`` の値を使用することができます。" - -#: ../../rst/plugins/netconf.rst:35 -msgid "Listing netconf plugins" -msgstr "netconf プラグインの一覧表示" - -#: ../../rst/plugins/netconf.rst:37 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several netconf plugins. To list all available netconf plugins on your control node, type ``ansible-doc -t netconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t netconf``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の netconf プラグインにアクセスできます。コントロールノードで利用可能な netconf プラグインの一覧を表示するには、``ansible-doc -t netconf -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t netconf`` を使用します。" - -#: ../../rst/plugins/plugins.rst:6 -msgid "Working with plugins" -msgstr "プラグインの使用" - -#: ../../rst/plugins/plugins.rst:8 -msgid "Plugins are pieces of code that augment Ansible's core functionality. Ansible uses a plugin architecture to enable a rich, flexible and expandable feature set." -msgstr "プラグインは、Ansible のコア機能を拡張するコードの一部です。Ansible はプラグインアーキテクチャーを使用して、豊富で柔軟な拡張性のある機能セットを実現しています。" - -#: ../../rst/plugins/plugins.rst:10 -msgid "Ansible ships with a number of handy plugins, and you can easily write your own." -msgstr "Ansible には、便利なプラグインが多数同梱されています。また、簡単に独自のプラグインを作成することもできます。" - -#: ../../rst/plugins/plugins.rst:12 -msgid "This section covers the various types of plugins that are included with Ansible:" -msgstr "本セクションでは、Ansible に含まれるさまざまなプラグインを説明します。" - -#: ../../rst/plugins/plugins.rst:39 -msgid ":ref:`plugin_filtering_config`" -msgstr ":ref:`plugin_filtering_config`" - -#: ../../rst/plugins/plugins.rst:40 -msgid "Controlling access to modules" -msgstr "モジュールへのアクセス制御" - -#: ../../rst/plugins/plugins.rst:41 -msgid ":ref:`ansible_configuration_settings`" -msgstr ":ref:`ansible_configuration_settings`" - -#: ../../rst/plugins/plugins.rst:42 -msgid "Ansible configuration documentation and settings" -msgstr "Ansible 設定ドキュメントおよび設定" - -#: ../../rst/plugins/plugins.rst:43 -msgid ":ref:`command_line_tools`" -msgstr ":ref:`command_line_tools`" - -#: ../../rst/plugins/plugins.rst:44 -msgid "Ansible tools, description and options" -msgstr "Ansible ツール、説明、およびオプション" - -#: ../../rst/plugins/shell.rst:10 -msgid "Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks." -msgstr "shell プラグインは、Ansible が実行する基本的なコマンドが正しくフォーマットされ、ターゲットマシンと連携し、Ansible のタスク実行方法に関連する特定の動作を設定できるように機能します。" - -#: ../../rst/plugins/shell.rst:16 -msgid "Enabling shell plugins" -msgstr "shell プラグインの有効化" - -#: ../../rst/plugins/shell.rst:18 -msgid "You can add a custom shell plugin by dropping it into a ``shell_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the shell plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの shell プラグインを追加するには、そのプラグインを、ロール内のプレイの隣りにある ``shell_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/shell.rst:21 -msgid "You should not alter which plugin is used unless you have a setup in which the default ``/bin/sh`` is not a POSIX compatible shell or is not available for execution." -msgstr "デフォルトの ``/bin/sh`` が POSIX に準拠していないシェルで、実行に利用できない場合以外は、使用するプラグインを変更するべきではありません。" - -#: ../../rst/plugins/shell.rst:27 -msgid "Using shell plugins" -msgstr "shell プラグインの使用" - -#: ../../rst/plugins/shell.rst:29 -msgid "In addition to the default configuration settings in :ref:`ansible_configuration_settings`, you can use the connection variable :ref:`ansible_shell_type ` to select the plugin to use. In this case, you will also want to update the :ref:`ansible_shell_executable ` to match." -msgstr ":ref:`ansible_configuration_settings` のデフォルト設定に加えて、接続プロファイル :ref:`ansible_shell_type ` を使用して、使用するプラグインを選択できます。この場合は、一致するように :ref:`ansible_shell_executable ` も更新します。" - -#: ../../rst/plugins/strategy.rst:10 -msgid "Strategy plugins control the flow of play execution by handling task and host scheduling. For more information on using strategy plugins and other ways to control execution order, see :ref:`playbooks_strategies`." -msgstr "strategy プラグインは、タスクおよびホストスケジューリングを処理し、プレイ実行のフローを制御します。strategy プラグインの使用方法や、実行の順番を制御する他の方法は、「:ref:`playbooks_strategies`」を参照してください。" - -#: ../../rst/plugins/strategy.rst:15 -msgid "Enabling strategy plugins" -msgstr "strategy プラグインの有効化" - -#: ../../rst/plugins/strategy.rst:17 -msgid "All strategy plugins shipped with Ansible are enabled by default. You can enable a custom strategy plugin by putting it in one of the lookup directory sources configured in :ref:`ansible.cfg `." -msgstr "Ansible に同梱されているすべての strategy プラグインは、デフォルトで有効になっています。カスタムの strategy プラグインを有効にするには、:ref:`ansible.cfg ` で設定したルックアップディレクトリーソースの 1 つにそれを置きます。" - -#: ../../rst/plugins/strategy.rst:23 -msgid "Using strategy plugins" -msgstr "strategy プラグインの使用" - -#: ../../rst/plugins/strategy.rst:25 -msgid "Only one strategy plugin can be used in a play, but you can use different ones for each play in a playbook or ansible run. By default Ansible uses the :ref:`linear ` plugin. You can change this default in Ansible :ref:`configuration ` using an environment variable:" -msgstr "プレイで使用できる strategy プラグインは 1 つだけですが、Playbook または ansible の実行でプレイごとに異なるプラグインを使用できます。デフォルトでは Ansible は :ref:`linear ` プラグインを使用します。環境変数を使用して、Ansible :ref:`configuration ` でこのデフォルトを変更できます。" - -#: ../../rst/plugins/strategy.rst:31 -msgid "or in the `ansible.cfg` file:" -msgstr "または `ansible.cfg` ファイルで、以下を行います。" - -#: ../../rst/plugins/strategy.rst:38 -msgid "You can also specify the strategy plugin in the play via the :ref:`strategy keyword ` in a play:" -msgstr "プレイの :ref:`strategy keyword ` を使用して、プレイの strategy プラグインを指定することもできます。" - -#: ../../rst/plugins/strategy.rst:59 -msgid "You can use ``ansible-doc -t strategy -l`` to see the list of available plugins. Use ``ansible-doc -t strategy `` to see plugin-specific specific documentation and examples." -msgstr "``ansible-doc -t strategy -l`` を使用して、利用可能なプラグインの一覧を表示します。``ansible-doc -t strategy `` を使用して、プラグイン固有のドキュメントと例を参照してください。" - -#: ../../rst/plugins/terminal.rst:4 -msgid "Terminal plugins" -msgstr "terminal プラグイン" - -#: ../../rst/plugins/terminal.rst:10 -msgid "Terminal plugins contain information on how to prepare a particular network device's SSH shell is properly initialized to be used with Ansible. This typically includes disabling automatic paging, detecting errors in output, and enabling privileged mode if supported and required on the device." -msgstr "terminal プラグインには、特定のネットワークデバイスの SSH シェルを準備する方法に関する情報が含まれています。通常、自動ページングの無効化、自動ページングの無効化、出力でエラーの検出、およびデバイスでサポートおよび必要な場合の特権モードの有効化などです。" - -#: ../../rst/plugins/terminal.rst:12 -msgid "These plugins correspond one-to-one to network device platforms. Ansible loads the appropriate terminal plugin automatically based on the ``ansible_network_os`` variable." -msgstr "これらのプラグインはネットワークデバイスのプラットフォームに 1 対 1 で対応します。Ansible は ``ansible_network_os`` 変数に基づいて適切な terminal プラグインを自動的に読み込みます。" - -#: ../../rst/plugins/terminal.rst:17 -msgid "Adding terminal plugins" -msgstr "terminal プラグインの追加" - -#: ../../rst/plugins/terminal.rst:19 -msgid "You can extend Ansible to support other network devices by dropping a custom plugin into the ``terminal_plugins`` directory." -msgstr "``terminal_plugins`` ディレクトリーにカスタムのプラグインを置いて、Ansible が他のネットワークデバイスをサポートするように拡張できます。" - -#: ../../rst/plugins/terminal.rst:24 -msgid "Using terminal plugins" -msgstr "terminal プラグインの使用" - -#: ../../rst/plugins/terminal.rst:26 -msgid "Ansible determines which terminal plugin to use automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality." -msgstr "Ansible は、``ansible_network_os`` 変数をもとに、使用する terminal プラグインを自動的に決定します。この機能を上書きする理由はありません。" - -#: ../../rst/plugins/terminal.rst:28 -msgid "Terminal plugins operate without configuration. All options to control the terminal are exposed in the ``network_cli`` connection plugin." -msgstr "terminal プラグインは、設定なしで動作します。端末を制御するオプションはすべて、``network_cli`` connection プラグインに公開されます。" - -#: ../../rst/plugins/terminal.rst:35 -msgid "Viewing terminal plugins" -msgstr "terminal プラグインの表示" - -#: ../../rst/plugins/terminal.rst:37 -msgid "These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several terminal plugins. To list all available terminal plugins on your control node, type ``ansible-doc -t terminal -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t terminal``." -msgstr "これらのプラグインは `Ansible Galaxy `_ のコレクションに移行しました。``pip`` を使用して Ansible バージョン 2.10 以降をインストールしている場合は、複数の terminal プラグインにアクセスできます。コントロールノードで利用可能な terminal プラグインの一覧を表示するには、``ansible-doc -t terminal -l`` と入力します。プラグイン固有のドキュメントと例を確認するには、``ansible-doc -t terminal`` を使用します。" - -#: ../../rst/plugins/test.rst:10 -msgid "Test plugins evaluate template expressions and return True or False. With test plugins you can create :ref:`conditionals ` to implement the logic of your tasks, blocks, plays, playbooks, and roles. Ansible uses the `standard tests `_ shipped as part of Jinja, and adds some specialized test plugins. You can :ref:`create custom Ansible test plugins `." -msgstr "test プラグインは template 式を評価し、True または False を返します。test プラグインを使用すると、:ref:`conditionals ` を作成して、タスク、ブロック、プレイ、Playbook、およびロールのロジックを実装できます。Ansible は Jinja の一部として同梱される `standard tests `_ を使用し、特殊な tesst プラグインを追加します。:ref:`create custom Ansible test plugins ` が可能です。" - -#: ../../rst/plugins/test.rst:16 -msgid "Enabling test plugins" -msgstr "test プラグインの有効化" - -#: ../../rst/plugins/test.rst:18 -msgid "You can add a custom test plugin by dropping it into a ``test_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the test plugin directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの test プラグインを追加するには、そのプラグインを、ロール内のプレイの隣りにある ``test_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/test.rst:24 -msgid "Using test plugins" -msgstr "test プラグインの使用" - -#: ../../rst/plugins/test.rst:26 -msgid "You can use tests anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using test plugins, see :ref:`playbooks_tests`." -msgstr "テストは、Ansible でテンプレートを使用できる場所で使用できます。これはプレイ、変数ファイル、または :ref:`template ` モジュールの Jinja2 テンプレートで使用できます。test プラグインの使用の詳細は、:ref:`playbooks_tests` を参照してください。" - -#: ../../rst/plugins/test.rst:28 -msgid "Tests always return ``True`` or ``False``, they are always a boolean, if you need a different return type, you should be looking at filters." -msgstr "テストは常に ``True`` または ``False`` を返し、ブール型です。別の戻り型が必要な場合には、フィルターを確認する必要があります。" - -#: ../../rst/plugins/test.rst:30 -msgid "You can recognize test plugins by the use of the ``is`` statement in a template, they can also be used as part of the ``select`` family of filters." -msgstr "test プラグインは、テンプレートの ``is`` ステートメントを使用して認識できます。また、フィルターの ``select`` ファミリーの一部として使用することもできます。" - -#: ../../rst/plugins/test.rst:42 -msgid "Tests will always have an ``_input`` and this is normally what is on the left side of ``is``. Tests can also take additional parameters as you would to most programming functions. These parameters can be either ``positional`` (passed in order) or ``named`` (passed as key=value pairs). When passing both types, positional arguments should go first." -msgstr "テストには常に ``_input`` があり、これは通常 ``is`` の左側にあります。テストは、ほとんどのプログラミング関数と同様に追加のパラメーターを取ることもできます。これらのパラメーターは ``positional`` (key=value ペアとして渡される) または ``named`` (key=value ペアとして渡される) のいずれかになります。両方のタイプを渡す場合は、位置引数を最初に指定する必要があります。。" - -#: ../../rst/plugins/test.rst:61 -msgid "Using test plugins with lists" -msgstr "リストと test プラグインの使用" - -#: ../../rst/plugins/test.rst:63 -msgid "As mentioned above, one way to use tests is with the ``select`` familiy of filters (``select``, ``reject``, ``selectattr``, ``rejectattr``)." -msgstr "前述のように、テストを使用する 1 つの方法として、``select`` の フィルターファミリー (``select``、``reject``、``selectattr``、および ``rejectattr``) を使用できます。" - -#: ../../rst/plugins/test.rst:88 ../../rst/plugins/test.rst:94 -msgid ":ref:`playbooks_tests`" -msgstr ":ref:`playbooks_tests`" - -#: ../../rst/plugins/test.rst:89 ../../rst/plugins/test.rst:95 -msgid "Using tests" -msgstr "テストの使用" - -#: ../../rst/plugins/test.rst:90 -msgid ":ref:`playbooks_conditionals`" -msgstr ":ref:`playbooks_conditionals`" - -#: ../../rst/plugins/test.rst:91 -msgid "Using conditional statements" -msgstr "条件分岐文の使用" - -#: ../../rst/plugins/vars.rst:10 -msgid "Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins. For more details about variables in Ansible, see :ref:`playbooks_variables`." -msgstr "vars プラグインは、インベントリーソース、Playbook、またはコマンドラインに組み込まれていない Ansible の実行に、変数データを追加します。「host_vars」や「group_vars」のような Playbook の構成要素は、vars プラグインを使用します。Ansible での変数の詳細は、:ref:`playbooks_variables` を参照してください。" - -#: ../../rst/plugins/vars.rst:12 -msgid "Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4." -msgstr "vars プラグインは Ansible 2.0 に部分的に実装され、Ansible 2.4 以降では、完全実装になるように書き直されました。" - -#: ../../rst/plugins/vars.rst:14 -msgid "The :ref:`host_group_vars ` plugin shipped with Ansible enables reading variables from :ref:`host_variables` and :ref:`group_variables`." -msgstr "Ansible に同梱される :ref:`host_group_vars ` プラグインは、:ref:`host_variables` および :ref:`group_variables` から変数の読み取りを可能にします。" - -#: ../../rst/plugins/vars.rst:19 -msgid "Enabling vars plugins" -msgstr "vars プラグインの有効化" - -#: ../../rst/plugins/vars.rst:21 -msgid "You can activate a custom vars plugin by either dropping it into a ``vars_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the directory sources configured in :ref:`ansible.cfg `." -msgstr "カスタムの vars プラグインを有効にするには、カスタムのプラグインを、ロール内のプレイの隣りにある ``vars_plugins`` ディレクトリーに置くか、:ref:`ansible.cfg ` で設定したディレクトリーソースの 1 つに置きます。" - -#: ../../rst/plugins/vars.rst:23 -msgid "Most vars plugins are disabled by default. To enable a vars plugin, set ``vars_plugins_enabled`` in the ``defaults`` section of :ref:`ansible.cfg ` or set the ``ANSIBLE_VARS_ENABLED`` environment variable to the list of vars plugins you want to execute. By default, the :ref:`host_group_vars ` plugin shipped with Ansible is enabled." -msgstr "ほとんどの vars プラグインはデフォルトで無効になっています。vars プラグインを有効にするには、:ref:`ansible.cfg ` の ``defaults`` セクションで ``vars_plugins_enabled`` を設定するか、実行する vars プラグインの一覧に ``ANSIBLE_VARS_ENABLED`` 環境変数を設定します。デフォルトでは、Ansible に同梱される :ref:`host_group_vars ` プラグインが有効になっています。" - -#: ../../rst/plugins/vars.rst:25 -msgid "Starting in Ansible 2.10, you can use vars plugins in collections. All vars plugins in collections must be explicitly enabled and must use the fully qualified collection name in the format ``namespace.collection_name.vars_plugin_name``." -msgstr "Ansible 2.10 以降では、コレクションで vars プラグインを使用できます。コレクションのすべての vars プラグインは明示的に有効で、``namespace.collection_name.vars_plugin_name`` 形式で完全修飾コレクション名を使用する必要があります。" - -#: ../../rst/plugins/vars.rst:35 -msgid "Using vars plugins" -msgstr "vars プラグインの使用" - -#: ../../rst/plugins/vars.rst:37 -msgid "By default, vars plugins are used on demand automatically after they are enabled." -msgstr "デフォルトでは、vars プラグインは、有効になった後に自動的にオンデマンドで使用されます。" - -#: ../../rst/plugins/vars.rst:39 -msgid "Starting in Ansible 2.10, vars plugins can be made to run at specific times. `ansible-inventory` does not use these settings, and always loads vars plugins." -msgstr "Ansible 2.10 以降、vars プラグインは特定のタイミングで実行できます。`ansible-inventory` はこれらの設定を使用せず、常に vars プラグインを読み込みます。" - -#: ../../rst/plugins/vars.rst:41 -msgid "The global setting ``RUN_VARS_PLUGINS`` can be set in ``ansible.cfg`` using ``run_vars_plugins`` in the ``defaults`` section or by the ``ANSIBLE_RUN_VARS_PLUGINS`` environment variable. The default option, ``demand``, runs any enabled vars plugins relative to inventory sources whenever variables are demanded by tasks. You can use the option ``start`` to run any enabled vars plugins relative to inventory sources after importing that inventory source instead." -msgstr "グローバル設定 ``RUN_VARS_PLUGINS`` は、``defaults`` セクションの ``run_vars_plugins`` を使用して、または ``ANSIBLE_RUN_VARS_PLUGINS`` 環境変数により、``ansible.cfg``に設定できます。デフォルトのオプションである ``demand`` は、タスクで変数が必要となった場合には必ず、インベントリーソースに対して有効な vars プラグインを実行します。代わりに、インベントリーソースをインポートした後に、``start`` オプションを使用して、インベントリーソースと相対的な位置にある、有効化された Vars プラグインを実行できます。" - -#: ../../rst/plugins/vars.rst:43 -msgid "You can also control vars plugin execution on a per-plugin basis for vars plugins that support the ``stage`` option. To run the :ref:`host_group_vars ` plugin after importing inventory you can add the following to :ref:`ansible.cfg `:" -msgstr "また、``stage`` オプションをサポートする vars プラグインの場合は、プラグインごとに vars プラグインの実行を制御することもできます。インベントリーのインポート後に :ref:`host_group_vars ` プラグインを実行するには、以下を :ref:`ansible.cfg ` に追加します。" - -#: ../../rst/plugins/vars.rst:55 -msgid "You can use ``ansible-doc -t vars -l`` to see the list of available vars plugins. Use ``ansible-doc -t vars `` to see plugin-specific documentation and examples." -msgstr "``ansible-doc -t vars -l`` を使用して、利用可能な var プラグインの一覧を表示します。``ansible-doc -t vars `` を使用して、プラグイン固有のドキュメントと例を参照してください。" - -#~ msgid "Ansible Cache plugins" -#~ msgstr "Ansible cache プラグイン" - -#~ msgid "Ansible connection plugins" -#~ msgstr "Ansible connection プラグイン" - -#~ msgid "Ansible Shell plugins" -#~ msgstr "Ansible shell プラグイン" - -#~ msgid "Ansible Strategy plugins" -#~ msgstr "Ansible strategy プラグイン" - -#~ msgid "Ansible Vars plugins" -#~ msgstr "Ansible vars プラグイン" - -#~ msgid "`irc.freenode.net `_" -#~ msgstr "`irc.freenode.net `_" - -#~ msgid ":ref:`playbooks_lookups`" -#~ msgstr ":ref:`playbooks_lookups`" - -#~ msgid "Jinja2 lookup plugins" -#~ msgstr "Jinja2 lookup プラグイン" - -#~ msgid "Ansible Action plugins" -#~ msgstr "Ansible action プラグイン" - -#~ msgid "`webchat.freenode.net `_" -#~ msgstr "`webchat.freenode.net `_" - -#~ msgid "Ansible cache plugins" -#~ msgstr "Ansible cache プラグイン" - -#~ msgid ":ref:`Filters`" -#~ msgstr ":ref:`Filters`" - -#~ msgid ":ref:`Tests`" -#~ msgstr ":ref:`Tests`" - -#~ msgid ":ref:`Lookups`" -#~ msgstr ":ref:`Lookups`" - -#~ msgid "Ansible vars plugins" -#~ msgstr "Ansible vars プラグイン" - -#~ msgid "Strategy plugins control the flow of play execution by handling task and host scheduling." -#~ msgstr "strategy プラグインは、タスクおよびホストスケジューリングを処理し、プレイ実行のフローを制御します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/porting_guides.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/porting_guides.po deleted file mode 100644 index 9d16f26e5ff..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/porting_guides.po +++ /dev/null @@ -1,13837 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/porting_guides/core_porting_guides.rst:5 -msgid "Ansible Core Porting Guides" -msgstr "Ansible Core 移植ガイド" - -#: ../../rst/porting_guides/core_porting_guides.rst:7 -msgid "This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of ``ansible-core`` to the next." -msgstr "本セクションでは、``ansible-core`` のあるバージョンから次のバージョンに、Ansible インフラストラクチャーの Playbook、プラグインなどを更新するのに役に立つ移植ガイドを紹介します。" - -#: ../../rst/porting_guides/core_porting_guides.rst:9 -msgid "Please note that this is not a complete list. If you believe any extra information would be useful in these pages, you can edit by clicking `Edit on GitHub` on the top right, or raising an issue." -msgstr "これは完全な一覧ではないことに注意してください。以下のページに役に立つ追加情報をお持ちの場合は、右上の「`Edit on GitHub`」をクリックするか、問題を報告することで編集が可能になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:6 -msgid "Ansible 2.0 Porting Guide" -msgstr "Ansible 2.0 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:8 -msgid "This section discusses the behavioral changes between Ansible 1.x and Ansible 2.0." -msgstr "このセクションでは、Ansible 1.x から Ansible 2.0 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:10 -#: ../../rst/porting_guides/porting_guide_2.10.rst:16 -#: ../../rst/porting_guides/porting_guide_2.3.rst:10 -#: ../../rst/porting_guides/porting_guide_2.4.rst:10 -#: ../../rst/porting_guides/porting_guide_2.5.rst:9 -#: ../../rst/porting_guides/porting_guide_2.6.rst:9 -#: ../../rst/porting_guides/porting_guide_2.7.rst:9 -#: ../../rst/porting_guides/porting_guide_2.8.rst:9 -#: ../../rst/porting_guides/porting_guide_2.9.rst:10 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:10 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:10 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:10 -msgid "It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible." -msgstr "本ガイドは、このバージョンの Ansible で動作するように、Playbook、プラグイン、その他の Ansible インフラストラクチャーを更新する際にご利用になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:13 -msgid "We suggest you read this page along with `Ansible Changelog for 2.0 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.0 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:15 -#: ../../rst/porting_guides/porting_guide_2.3.rst:15 -#: ../../rst/porting_guides/porting_guide_2.4.rst:15 -#: ../../rst/porting_guides/porting_guide_2.5.rst:13 -#: ../../rst/porting_guides/porting_guide_2.6.rst:13 -#: ../../rst/porting_guides/porting_guide_2.7.rst:13 -#: ../../rst/porting_guides/porting_guide_2.8.rst:13 -#: ../../rst/porting_guides/porting_guide_2.9.rst:14 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:14 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:14 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:14 -msgid "This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `." -msgstr "このドキュメントは、移植に関する内容の一部です。移植ガイドの完全なリストは :ref:`porting guides ` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:17 -#: ../../rst/porting_guides/porting_guide_2.3.rst:17 -#: ../../rst/porting_guides/porting_guide_2.4.rst:17 -#: ../../rst/porting_guides/porting_guide_2.5.rst:15 -#: ../../rst/porting_guides/porting_guide_2.6.rst:15 -#: ../../rst/porting_guides/porting_guide_2.7.rst:15 -#: ../../rst/porting_guides/porting_guide_2.9.rst:17 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:17 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:17 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:17 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:20 -#: ../../rst/porting_guides/porting_guide_2.10.rst:33 -#: ../../rst/porting_guides/porting_guide_2.3.rst:20 -#: ../../rst/porting_guides/porting_guide_2.5.rst:18 -#: ../../rst/porting_guides/porting_guide_2.6.rst:18 -#: ../../rst/porting_guides/porting_guide_2.7.rst:54 -#: ../../rst/porting_guides/porting_guide_2.8.rst:19 -#: ../../rst/porting_guides/porting_guide_2.9.rst:20 -#: ../../rst/porting_guides/porting_guide_4.rst:18 -#: ../../rst/porting_guides/porting_guide_5.rst:22 -#: ../../rst/porting_guides/porting_guide_6.rst:22 -#: ../../rst/porting_guides/porting_guide_7.rst:22 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:26 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:21 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:20 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:20 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:20 -msgid "Playbook" -msgstr "Playbook" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:22 -msgid "This section discusses any changes you may need to make to your playbooks." -msgstr "本セクションでは、Playbook に加える必要のある変更を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:24 -msgid "Syntax in 1.9.x" -msgstr "1.9.x の構文" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:32 -#: ../../rst/porting_guides/porting_guide_2.0.rst:75 -msgid "Syntax in 2.0.x" -msgstr "2.0.x の構文" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:40 -msgid "Output:" -msgstr "出力:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:46 -msgid "To make an escaped string that will work on all versions you have two options::" -msgstr "すべてのバージョンで機能するエスケープされた文字列を作成するには、2 つのオプションがあります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:50 -msgid "uses key=value escaping which has not changed. The other option is to check for the ansible version::" -msgstr "key=value エスケープを使用しますが、これは、変更されていません。もう 1 つの方法は、ansible のバージョンを確認することです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:54 -msgid "trailing newline When a string with a trailing newline was specified in the playbook through yaml dict format, the trailing newline was stripped. When specified in key=value format, the trailing newlines were kept. In v2, both methods of specifying the string will keep the trailing newlines. If you relied on the trailing newline being stripped, you can change your playbook using the following as an example::" -msgstr "末尾に改行: 末尾に改行がある文字列が yaml dict 形式で Playbook に指定されている場合、末尾の改行は削除されます。key=value 形式で指定すると、末尾に改行が保持されます。v2 では、この文字列を指定するメソッドはともに改行を保持します。末尾の改行が自動的に削除されるのに依存していた場合は、以下のように Playbook を変更できます。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:88 -msgid "Output" -msgstr "出力" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:94 -msgid "Behavior of templating DOS-type text files changes with Ansible v2." -msgstr "DOS タイプのテキストファイルをテンプレート化する動作は Ansible v2 で変わります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:96 -msgid "A bug in Ansible v1 causes DOS-type text files (using a carriage return and newline) to be templated to Unix-type text files (using only a newline). In Ansible v2 this long-standing bug was finally fixed and DOS-type text files are preserved correctly. This may be confusing when you expect your playbook to not show any differences when migrating to Ansible v2, while in fact you will see every DOS-type file being completely replaced (with what appears to be the exact same content)." -msgstr "Ansible v1 のバグにより、DOS タイプのテキストファイル (キャリッジリターンと改行を使用) が、Unix タイプのテキストファイル (改行のみを使用) にテンプレート化していました。Ansible v2 では、この長年のバグがようやく修正され、DOS 形式のテキストファイルが正しく保存されるようになりました。これは、Ansible v2 への移行時に Playbook に変更がないことを期待している場合には混乱するかもしれませんが、実際には、すべての DOS 型ファイルが完全に置き換えられています (ただし、完全に同一の内容であるように表示される場合があります)。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:98 -msgid "When specifying complex args as a variable, the variable must use the full jinja2 variable syntax (```{{var_name}}```) - bare variable names there are no longer accepted. In fact, even specifying args with variables has been deprecated, and will not be allowed in future versions:" -msgstr "複雑な引数を変数として指定する場合、変数は完全な jinja2 変数構文 (```{{var_name}}```) を使用する必要があります。ベア変数名は使用できなくなりました。実際、変数で引数を指定することも非推奨となり、将来のバージョンでは使用できなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:118 -msgid "porting task includes" -msgstr "移植タスクに含まれるもの" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:119 -msgid "More dynamic. Corner-case formats that were not supposed to work now do not, as expected." -msgstr "より動的に。動作すると想定していなかったコーナーケース (めったに発生しない厄介なケース) の形式が、期待通りに動作しなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:120 -msgid "variables defined in the yaml dict format see `issue 13324 `_" -msgstr "yaml の dict 形式で定義される変数は、`issue 13324 `_ を参照してください" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:121 -msgid "templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string. If you need the old behavior, quote the value to pass it around as a string." -msgstr "テンプレート化 (Playbook およびテンプレート検索の変数) は、すべてを文字列にするのではなく、オリジナルを維持するという点で改善されました。以前の動作が必要な場合は、値を引用符で囲み、文字列として渡してください。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:123 -msgid "Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`. You can override the `null_representation` setting to an empty string in your config file by setting the :envvar:`ANSIBLE_NULL_REPRESENTATION` environment variable." -msgstr "空の変数と、yaml で null に設定された変数は、空の文字列に変換されなくなり、`None` の値を維持します。環境変数 :envvar:`ANSIBLE_NULL_REPRESENTATION` を設定することで、設定ファイルで `null_representation` が空文字列に設定されるのを上書きすることができます。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:125 -msgid "Extras callbacks must be enabled in ansible.cfg. Copying is no longer necessary but you must enable them in ansible.cfg." -msgstr "ansible.cfg で追加のコールバックを有効にする必要があります。コピーは不要になりますが、ansible.cfg で有効にする必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:126 -msgid "dnf module has been rewritten. Some minor changes in behavior may be observed." -msgstr "dnf モジュールが書き直されました。いくつかの細かい動作の変更があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:127 -msgid "win_updates has been rewritten and works as expected now." -msgstr "win_updates は書き直され、期待通りに動作するようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:128 -msgid "from 2.0.1 onwards, the implicit setup task from gather_facts now correctly inherits everything from play, but this might cause issues for those setting `environment` at the play level and depending on `ansible_env` existing. Previously this was ignored but now might issue an 'Undefined' error." -msgstr "2.0.1 以降、gather_facts の暗黙的な設定タスクは、プレイからすべて正しく継承されるようになりましたが、これにより、プレイレベルで `environment` を設定し、`ansible_env` の存在に依存している場合に問題が発生する可能性がありましたが、以前はこの問題は無視されていました。これからは「Undefined」エラーが発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:132 -#: ../../rst/porting_guides/porting_guide_2.10.rst:51 -#: ../../rst/porting_guides/porting_guide_2.4.rst:52 -#: ../../rst/porting_guides/porting_guide_2.5.rst:101 -#: ../../rst/porting_guides/porting_guide_2.6.rst:23 -#: ../../rst/porting_guides/porting_guide_2.7.rst:104 -#: ../../rst/porting_guides/porting_guide_2.8.rst:325 -#: ../../rst/porting_guides/porting_guide_2.9.rst:43 -#: ../../rst/porting_guides/porting_guide_4.rst:30 -#: ../../rst/porting_guides/porting_guide_5.rst:63 -#: ../../rst/porting_guides/porting_guide_6.rst:48 -#: ../../rst/porting_guides/porting_guide_7.rst:47 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:44 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:33 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:61 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:46 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:45 -msgid "Deprecated" -msgstr "非推奨" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:134 -msgid "While all items listed here will show a deprecation warning message, they still work as they did in 1.9.x. Please note that they will be removed in 2.2 (Ansible always waits two major releases to remove a deprecated feature)." -msgstr "ここに掲載されているすべての項目には、非推奨の警告メッセージが表示されますが、1.9.x での動作と同じ動作になります。ただし、2.2 で削除されることに注意してください (Ansible は常に 2 つのメジャーリリースを待ってから非推奨の機能を削除します)。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:136 -msgid "Bare variables in ``with_`` loops should instead use the ``\"{{ var }}\"`` syntax, which helps eliminate ambiguity." -msgstr "``with_`` ループ内のベア変数は、代わりに ``\"{{ var }}\"`` 構文を使用する必要があります。これにより、曖昧さがなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:137 -msgid "The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead." -msgstr "ansible-galaxy テキスト形式の要件ファイル。ユーザーは、代わりに要件に YAML 形式を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:138 -msgid "Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error." -msgstr "``with_`` ループのリストに含まれる未定義の変数は、現在のところループを中断することはありませんが、警告を出力します。今後はエラーを出力します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:139 -msgid "Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. Example of a deprecated variant:" -msgstr "ディクショナリー変数を使用してすべてのタスクパラメーターを設定することは安全ではないため、将来のバージョンで削除される予定です。以下は、非推奨のバリアントの例になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:153 -msgid "Example of a recommended variant:" -msgstr "推奨されるバリアントの例は以下のとおりです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:166 -msgid "Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern." -msgstr "ホストパターンで、パターン内のホスト/グループを分離する場合は、セミコロン (;) の代わりにコンマ (,) またはコロン (:) を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:167 -msgid "Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y]." -msgstr "ホストパターンで指定した範囲は、[x-y] 構文ではなく [x:y] 構文を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:168 -msgid "Playbooks using privilege escalation should always use \"become*\" options rather than the old su*/sudo* options." -msgstr "権限昇格を使用した Playbook は、古い su*/sudo* オプションではなく「become*」オプションを常に使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:169 -msgid "The \"short form\" for vars_prompt is no longer supported. For example::" -msgstr "vars_prompt の「短縮形」はサポートされなくなりました。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:175 -msgid "Specifying variables at the top level of a task include statement is no longer supported. For example::" -msgstr "タスクのinclude 文の最上位で変数を指定することはサポートされなくなりました。たとえば次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:180 -msgid "Should now be::" -msgstr "以下のようになるはずです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:186 -msgid "Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only." -msgstr "タスクで any_errors_fatal の設定がサポートされなくなりました。これはプレイレベルでのみ設定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:187 -msgid "Bare variables in the `environment` dictionary (for plays/tasks/and so on) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'." -msgstr "`environment` ディクショナリー (プレイ、タスクなど) のベアメタル変数がサポートされなくなりました。指定される変数は、完全な変数構文 (「{{foo}}」) を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:188 -msgid "Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task. For example::" -msgstr "タグ (または他のディレクティブ) は、タスクのインクルードの中で他のパラメーターと一緒に指定しないでください。代わりに、タスクのオプションとして指定する必要があります。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:193 -msgid "Should be::" -msgstr "以下のようになるはずです。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:198 -msgid "The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin." -msgstr "タスクの first_available_file オプションが非推奨になりました。ユーザーは、with_first_found オプションまたは lookup ('first_found', …) プラグインを使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:202 -#: ../../rst/porting_guides/porting_guide_2.3.rst:100 -#: ../../rst/porting_guides/porting_guide_2.4.rst:72 -msgid "Other caveats" -msgstr "その他の注意事項" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:204 -msgid "Here are some corner cases encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored." -msgstr "ここでは、更新時に遭遇するいくつかのコーナーケース (めったに発生しない厄介なケース) を紹介します。これらは主に、パーサーの検証がより厳しくなったことと、以前は無視されていたエラーが捕捉されたことが原因です。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:206 -msgid "Bad variable composition::" -msgstr "誤った変数の構成:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:210 -msgid "This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead.::" -msgstr "これは、エラーが再テンプレート化され、変数を解決することになったため、「偶然」機能しましたが、有効な構文として意図されたものではありませんでしたが、現在は適切にエラーを返しています。代わりに以下を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:214 -msgid "Misspelled directives::" -msgstr "スペルが間違っているディレクティブ:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:219 -msgid "The task always ran without using privilege escalation (for that you need `become`) but was also silently ignored so the play 'ran' even though it should not, now this is a parsing error." -msgstr "タスクは常に、権限エスカレーションを使用せずに (`become` が必要なため) 実行されますが、通知なく無視されるために、プレイが実行させるべきでないにも関わらず「実行」されていましたが、これは解析エラーとなるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:222 -msgid "Duplicate directives::" -msgstr "重複ディレクティブ:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:228 -msgid "The first `when` was ignored and only the 2nd one was used as the play ran w/o warning it was ignoring one of the directives, now this produces a parsing error." -msgstr "最初の `when` は無視され、2 つ目のものだけが使用されました。プレーは警告なしに実行され、ディレクティブの 1 つを無視していましたが、解析エラーが生成されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:230 -msgid "Conflating variables and directives::" -msgstr "変数およびディレクティブの制限::" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:237 -msgid "The `port` variable is reserved as a play/task directive for overriding the connection port, in previous versions this got conflated with a variable named `port` and was usable later in the play, this created issues if a host tried to reconnect or was using a non caching connection. Now it will be correctly identified as a directive and the `port` variable will appear as undefined, this now forces the use of non conflicting names and removes ambiguity when adding settings and variables to a role invocation." -msgstr "`port` 変数は、接続ポートを上書きするための play/task ディレクティブとして予約されています。以前のバージョンでは、`port` という名前の変数と融合し、後でプレイで使用できますが、そのホストが再接続をしようとしたり、非キャッシュ接続を使用していた場合にこの問題が発生します。今回のリリースより、ディレクティブとして正しく識別され、`port` 変数は未定義として表示されます。これにより、競合する名前を使用しないようにし、ロールの呼び出しに設定および変数を追加する際に曖昧さがなくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:241 -msgid "Bare operations on `with_`::" -msgstr "`with_` でのベア操作:" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:245 -msgid "An issue with the 'bare variable' features, which was supposed only template a single variable without the need of braces ({{ )}}, would in some versions of Ansible template full expressions. Now you need to use proper templating and braces for all expressions everywhere except conditionals (`when`)::" -msgstr "「ベア変数」関数の問題は、中括弧 ({{ )}} を必要としない単一の変数のみをテンプレート化することになっていましたが、Ansible の一部のバージョンでは完全な式をテンプレート化していました。現在では、条件式 (`when`) を除くすべての場所のすべての式に対して、適切なテンプレート化と中括弧を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:250 -msgid "The bare feature itself is deprecated as an undefined variable is indistinguishable from a string which makes it difficult to display a proper error." -msgstr "未定義の変数は文字列と区別がつかず、適切なエラーを表示することが難しいため、ベア関数自体が非推奨となっています。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:253 -msgid "Porting plugins" -msgstr "Porting プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:255 -msgid "In ansible-1.9.x, you would generally copy an existing plugin to create a new one. Simply implementing the methods and attributes that the caller of the plugin expected made it a plugin of that type. In ansible-2.0, most plugins are implemented by subclassing a base class for each plugin type. This way the custom plugin does not need to contain methods which are not customized." -msgstr "ansible-1.9.xでは、通常、既存のプラグインをコピーして新しいプラグインを作成します。プラグインの呼び出し元が期待するメソッドおよび属性を実装するだけで、そのタイプのプラグインになりました。ansible-2.0では、ほとんどのプラグインが、各プラグインタイプのベースクラスをサブクラス化することで実装されています。こうすることで、カスタムプラグインはカスタマイズされていないメソッドを含む必要がなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:259 -#: ../../rst/porting_guides/porting_guide_2.0.rst:340 -msgid "Lookup plugins" -msgstr "lookup プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:261 -msgid "lookup plugins ; import version" -msgstr "lookup プラグイン; バージョンのインポート" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:265 -#: ../../rst/porting_guides/porting_guide_2.0.rst:312 -#: ../../rst/porting_guides/porting_guide_2.0.rst:408 -#: ../../rst/porting_guides/porting_guide_2.0.rst:423 -msgid "Connection plugins" -msgstr "connection プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:267 -#: ../../rst/porting_guides/porting_guide_2.0.rst:314 -#: ../../rst/porting_guides/porting_guide_2.0.rst:410 -#: ../../rst/porting_guides/porting_guide_2.0.rst:425 -msgid "connection plugins" -msgstr "conneciton プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:270 -#: ../../rst/porting_guides/porting_guide_2.0.rst:413 -msgid "Action plugins" -msgstr "action プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:273 -#: ../../rst/porting_guides/porting_guide_2.0.rst:415 -msgid "action plugins" -msgstr "action プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:276 -#: ../../rst/porting_guides/porting_guide_2.0.rst:418 -#: ../../rst/porting_guides/porting_guide_2.4.rst:132 -msgid "Callback plugins" -msgstr "callback プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:278 -msgid "Although Ansible 2.0 provides a new callback API the old one continues to work for most callback plugins. However, if your callback plugin makes use of :attr:`self.playbook`, :attr:`self.play`, or :attr:`self.task` then you will have to store the values for these yourself as ansible no longer automatically populates the callback with them. Here's a short snippet that shows you how:" -msgstr "Ansible 2.0 では新しいコールバック API が提供されていますが、ほとんどのコールバックプラグインでは古い API も引き続き使用できます。ただし、コールバックプラグインが :attr:`self.playbook`、:attr:`self.play`、または :attr:`self.task` を使用している場合は、ansible がコールバックに自動的に値を入力しなくなったため、これらの値を自分で保存する必要があります。ここでは、その方法を示す短いスニペットをご紹介します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:318 -msgid "Hybrid plugins" -msgstr "ハイブリッドプラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:320 -msgid "In specific cases you may want a plugin that supports both ansible-1.9.x *and* ansible-2.0. Much like porting plugins from v1 to v2, you need to understand how plugins work in each version and support both requirements." -msgstr "特定のケースでは、ansible-1.9.x *および* ansible-2.0 の両方をサポートするプラグインが必要になる場合があります。v1 から v2 へのプラグインの移植と同様に、各バージョンでプラグインがどのように機能し、両方の要件をサポートするかを理解する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:322 -msgid "Since the ansible-2.0 plugin system is more advanced, it is easier to adapt your plugin to provide similar pieces (subclasses, methods) for ansible-1.9.x as ansible-2.0 expects. This way your code will look a lot cleaner." -msgstr "ansible-2.0 プラグインシステムはより高度なため、ansible-2.0 が想定するとおりに、ansible-1.9.x の同様の部分 (サブクラス、メソッド) を提供するためにプラグインを調整することがより容易になります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:324 -msgid "You may find the following tips useful:" -msgstr "以下のヒントを参考にしてみてください。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:326 -msgid "Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (for example, ``__init__``)" -msgstr "ansible-2.0 のクラスが利用可能かどうかを確認し、クラスが不足している場合 (ansible-1.9.x) は、必要なメソッド (``__init__`` など) でそれらを模倣します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:328 -msgid "When ansible-2.0 python modules are imported, and they fail (ansible-1.9.x), catch the ``ImportError`` exception and perform the equivalent imports for ansible-1.9.x. With possible translations (for example, importing specific methods)." -msgstr "ansible-2.0 python モジュールをインポートして失敗すると (ansible-1.9.x)、``ImportError`` 例外を捕捉して、ansible-1.9.x の同等のインポートを実行します。翻訳 (たとえば、特定のメソッドをインポートすること) が行われることもあります。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:330 -msgid "Use the existence of these methods as a qualifier to what version of Ansible you are running. So rather than using version checks, you can do capability checks instead. (See examples below)" -msgstr "これらのメソッドの存在を、実行中の Ansible バージョンへの修飾子として使用します。そのため、バージョンチェックを使用するのではなく、代わりに機能チェックを行うことができます (以下の例を参照)。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:332 -msgid "Document for each if-then-else case for which specific version each block is needed. This will help others to understand how they have to adapt their plugins, but it will also help you to remove the older ansible-1.9.x support when it is deprecated." -msgstr "各ブロックがどのバージョンで必要とされているか、if-then-else のケースごとに文書化します。これは、他の人が自分のプラグインをどのように適応させなければならないかを理解するのに役立つだけでなく、以前の ansible-1.9.x のサポートが非推奨になったときに削除するのに役立ちます。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:334 -msgid "When doing plugin development, it is very useful to have the ``warning()`` method during development, but it is also important to emit warnings for deadends (cases that you expect should never be triggered) or corner cases (for example, cases where you expect misconfigurations)." -msgstr "プラグインの開発を行う場合は、開発中に ``warning()`` メソッドがあると非常に便利ですが、デッドエンド (絶対に発生してはいけないと予想されるケース）やコーナーケース (めったに発生しない厄介なケース、たとえば設定が間違っている可能性があるケース) に対して警告を発することも重要です。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:336 -msgid "It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes and methods are available." -msgstr "API がどのように機能するか、どのようなモジュール、クラス、メソッドが利用できるかを理解するには、ansible-1.9.x や ansible-2.0 の他のプラグインを確認するのが有効です。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:342 -msgid "As a simple example we are going to make a hybrid ``fileglob`` lookup plugin." -msgstr "簡単な例として、ハイブリッドの ``fileglob`` lookup プラグインを作成します。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:403 -msgid "In the above example we did not use the ``warning()`` method as we had no direct use for it in the final version. However we left this code in so people can use this part during development/porting/use." -msgstr "上記の例では、最終バージョンで直接使用することがなかったため、``warning()`` メソッドを使用していません。しかし、開発、移植、および使用の際にこの部分を利用できるように、このコードを残しました。" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:420 -msgid "callback plugins" -msgstr "callback プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:429 -#: ../../rst/porting_guides/porting_guide_2.10.rst:97 -#: ../../rst/porting_guides/porting_guide_2.3.rst:160 -#: ../../rst/porting_guides/porting_guide_2.5.rst:281 -#: ../../rst/porting_guides/porting_guide_2.6.rst:102 -#: ../../rst/porting_guides/porting_guide_2.7.rst:241 -#: ../../rst/porting_guides/porting_guide_2.8.rst:549 -#: ../../rst/porting_guides/porting_guide_2.9.rst:722 -#: ../../rst/porting_guides/porting_guide_4.rst:131 -#: ../../rst/porting_guides/porting_guide_5.rst:120 -#: ../../rst/porting_guides/porting_guide_6.rst:92 -#: ../../rst/porting_guides/porting_guide_7.rst:85 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:90 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:134 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:118 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:90 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:83 -msgid "Porting custom scripts" -msgstr "カスタムスクリプトの移植" - -#: ../../rst/porting_guides/porting_guide_2.0.rst:431 -msgid "Custom scripts that used the ``ansible.runner.Runner`` API in 1.x have to be ported in 2.x. Please refer to: :ref:`developing_api`" -msgstr "1.x で ``ansible.runner.Runner`` API を使用したカスタムスクリプトは、2.x に移植する必要があります。「:ref:`developing_api`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:8 -msgid "Ansible 2.10 Porting Guide" -msgstr "Ansible 2.10 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:12 -msgid "In Ansible 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. Your playbooks should continue to work without any changes. We recommend you start using the fully-qualified collection name (FQCN) in your playbooks as the explicit and authoritative indicator of which collection to use as some collections may contain duplicate module names. You can search the `index of all modules `_ to find the collection a module has been relocated to." -msgstr "Ansible 2.10 では、多くのプラグインやモジュールが、`Ansible Galaxy `_ のコレクションに移行しました。お使いの Playbook は何の変更もなく継続してお使いいただけます。一部のコレクションではモジュール名が重複している可能性があるため、どのコレクションを使用するかの明示的かつ権威的な指標として、Playbook で、完全修飾コレクション名（FQCN）を使用することが推奨されます。`すべてのモジュールのインデックス `_ を検索すると、モジュールが再配置されたコレクションを見つけることができます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:14 -msgid "This section discusses the behavioral changes between Ansible 2.9 and Ansible 2.10." -msgstr "このセクションでは、Ansible 2.9 から Ansible 2.10 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:18 -msgid "We suggest you read this page along with the `Ansible Changelog for 2.10 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible 2.10 のチェンジログ `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:20 -msgid "Since 2.10, Ansible consists of two parts:" -msgstr "2.10 以降、Ansible は以下の 2 つの部分から構成されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:22 -msgid "ansible-base, which includes the command line tools with a small selection of plugins and modules, and" -msgstr "ansible-base: プラグインやモジュールが少ないコマンドラインツールが含まれます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:23 -msgid "a `set of collections `_." -msgstr "`コレクションのセット `" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:25 -msgid "The :ref:`porting_2.10_guide_base` is included in this porting guide. The complete list of porting guides can be found at :ref:`porting guides `." -msgstr ":ref:`porting_2.10_guide_base` は、この移植ガイドに含まれます。移植ガイドの一覧は「:ref:`移植ガイド `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:35 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:28 -msgid "Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean Example: ``diff: yes-`` was returning ``False``." -msgstr "ランダムな文字列が「False」を返すブール値のキーワードのバグを修正しました。適切なブール値ではない場合はエラーを返すはずです (例: ``diff: yes-`` が ``False`` を返している場合)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:37 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:30 -msgid "A new fact, ``ansible_processor_nproc`` reflects the number of vcpus available to processes (falls back to the number of vcpus available to the scheduler)." -msgstr "新しいファクト ``ansible_processor_nproc`` は、プロセスで利用可能な vcpu の数を反映しています (スケジューラーで利用可能な vcpu の数に戻されます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:43 -#: ../../rst/porting_guides/porting_guide_2.7.rst:18 -#: ../../rst/porting_guides/porting_guide_2.8.rst:305 -#: ../../rst/porting_guides/porting_guide_2.9.rst:37 -#: ../../rst/porting_guides/porting_guide_4.rst:24 -#: ../../rst/porting_guides/porting_guide_5.rst:57 -#: ../../rst/porting_guides/porting_guide_6.rst:42 -#: ../../rst/porting_guides/porting_guide_7.rst:40 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:36 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:27 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:55 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:40 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:38 -msgid "Command Line" -msgstr "コマンドライン" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:45 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:38 -msgid "The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or collections to Galaxy through ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI through a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) through the ``--token`` argument to ``ansible-galaxy``." -msgstr "GitHub 認証に使用される基礎となる API がシャットダウンされたため、``ansible-galaxy login`` コマンドが削除されました。``ansible-galaxy`` 経由で Galaxy にロールまたはコレクションを公開する場合は、Galaxy API トークンをトークンファイル (デフォルトの場所 ``~/.ansible/galaxy_token``) または ``--token`` 引数から ``ansible-galaxy`` に (セキュリティーを確保せずにセキュアに) 渡すことが必要になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:53 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:46 -msgid "Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`." -msgstr "Windows Server 2008 および 2008 R2 は、次回の Ansible リリースではサポートされず、テストされなくなります。「:ref:`windows_faq_server2008`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:57 -#: ../../rst/porting_guides/porting_guide_2.3.rst:108 -#: ../../rst/porting_guides/porting_guide_2.4.rst:77 -#: ../../rst/porting_guides/porting_guide_2.5.rst:156 -#: ../../rst/porting_guides/porting_guide_2.6.rst:28 -#: ../../rst/porting_guides/porting_guide_2.7.rst:154 -#: ../../rst/porting_guides/porting_guide_2.8.rst:364 -#: ../../rst/porting_guides/porting_guide_2.9.rst:72 -#: ../../rst/porting_guides/porting_guide_4.rst:95 -#: ../../rst/porting_guides/porting_guide_5.rst:83 -#: ../../rst/porting_guides/porting_guide_6.rst:54 -#: ../../rst/porting_guides/porting_guide_7.rst:53 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:50 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:98 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:81 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:52 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:51 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:61 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:54 -msgid "Links on this page may not point to the most recent versions of modules. We will update them when we can." -msgstr "このページのリンクは、最新のバージョンのモジュールを参照していない可能性があります。可能な限り更新していきます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:63 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:56 -msgid "Version 2.10.0 of ansible-base changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.10.1, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible." -msgstr "ansible-base のバージョン 2.10.0 は、ユーザーがファイルベースのタスクで ``mode`` パラメーターを指定しなかった場合に、ファイルベースのタスクのデフォルトモードを ``0o600 & ~umask`` に変更しました。これは、再編成した CVE レポートに対する対応でした。その結果、2.10.1 ではモードの変更が元に戻され、以前のバージョンの Ansible と同様に、モードのデフォルトが ``0o666 & ~umask`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:64 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:57 -msgid "If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1." -msgstr "2.10.0 を使用する際に、より制限の少ないパーミッションを指定するようにタスクを変更した場合、2.10.1 ではその変更は不要になります (ただし、害はありません)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:65 -#: ../../rst/porting_guides/porting_guide_2.8.rst:376 -#: ../../rst/porting_guides/porting_guide_2.9.rst:79 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:58 -msgid "To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it." -msgstr "CVE-2020-1736 で発生する問題を回避するには、それを受け入れるファイルベースのタスクで ``mode`` パラメーターを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:67 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:60 -msgid "``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task." -msgstr "``dnf`` および ``yum`` - バージョン 2.10.1 より、``dnf`` モジュール (および ``dnf`` を使用する場合は ``yum`` アクション) がパッケージの GPG 署名を正しく検証するようになりました (CVE-2020-14365)。``Failed to validate GPG signature for [package name]`` のようなエラーが表示された場合は、使用している DNF リポジトリーやパッケージの GPG キーが正しくインポートされていることを確認してください。これを行う 1 つの方法として、``rpm_key`` モジュールの使用があります。推奨はしませんが、場合によっては GPG チェックを無効にする必要があるかもしれません。これは、``dnf`` タスクまたは ``yum`` タスクに ``disable_gpg_check: yes`` を明示的に追加することで実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:71 -#: ../../rst/porting_guides/porting_guide_2.3.rst:141 -#: ../../rst/porting_guides/porting_guide_2.4.rst:99 -#: ../../rst/porting_guides/porting_guide_2.5.rst:207 -#: ../../rst/porting_guides/porting_guide_2.6.rst:49 -#: ../../rst/porting_guides/porting_guide_2.7.rst:193 -#: ../../rst/porting_guides/porting_guide_2.8.rst:414 -#: ../../rst/porting_guides/porting_guide_2.9.rst:699 -#: ../../rst/porting_guides/porting_guide_4.rst:116 -#: ../../rst/porting_guides/porting_guide_5.rst:107 -#: ../../rst/porting_guides/porting_guide_6.rst:74 -#: ../../rst/porting_guides/porting_guide_7.rst:73 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:64 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:119 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:105 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:72 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:71 -msgid "Noteworthy module changes" -msgstr "モジュール変更に関する注目点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:73 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:66 -msgid "Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves." -msgstr "``add_file_common_args=True`` で作成された Ansible モジュールにより、特定アクションプラグインの実装を容易にするために、文書化されていない引数が複数追加されています。ドキュメント化されていない引数 ``src``、``follow``、``force``、``content``、``backup``、``remote_src``、``regexp``、``delimiter``、および ``directory_mode`` が追加されなくなりました。オプションを追加するため、これらのオプションが追加されることに依存しているモジュールは、自分でそれらを指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:74 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:67 -msgid "Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``." -msgstr "Ansible は、Ansible モジュールの実行時に、現在の作業ディレクトリー (通常は ``remote_user`` のホームディレクトリー) にある Python モジュールを検索しなくなりました。これにより、OpenBSD で権限のないユーザーになり (become)、悪意のあるユーザーが現在の作業ディレクトリーを書き込み可能な場合に攻撃ベクトルを軽減することができます。Ansible モジュールを、システム全体の管理ノードまたは ``remote_user`` の ``$PYTHONPATH`` にあり、``become_user`` が読み取り可能な別のディレクトリーに、Ansible モジュールを実行するのに必要な Python モジュールをインストールします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:78 -#: ../../rst/porting_guides/porting_guide_2.3.rst:155 -#: ../../rst/porting_guides/porting_guide_2.4.rst:107 -#: ../../rst/porting_guides/porting_guide_2.5.rst:237 -#: ../../rst/porting_guides/porting_guide_2.6.rst:83 -#: ../../rst/porting_guides/porting_guide_2.7.rst:231 -#: ../../rst/porting_guides/porting_guide_2.8.rst:511 -#: ../../rst/porting_guides/porting_guide_2.9.rst:713 -#: ../../rst/porting_guides/porting_guide_4.rst:124 -#: ../../rst/porting_guides/porting_guide_5.rst:113 -#: ../../rst/porting_guides/porting_guide_6.rst:86 -#: ../../rst/porting_guides/porting_guide_7.rst:79 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:71 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:127 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:111 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:84 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:77 -msgid "Plugins" -msgstr "プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:81 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:74 -msgid "Lookup plugin names case-sensitivity" -msgstr "大文字小文字を区別してプラグイン名の検索" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:83 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:76 -msgid "Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked through ``with_``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive." -msgstr "Ansible ``2.10`` の lookup プラグイン名が ``lookup()`` 関数に引数として渡される前に、``with_`` を介して呼び出されるルックアップとは異なり、大文字と小文字を区別しないものとして処理されます。``2.10`` では、``lookup()`` と ``with_`` の両方で大文字小文字を区別するように整合性が取られています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:86 -#: ../../rst/porting_guides/porting_guide_2.6.rst:94 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:79 -msgid "Noteworthy plugin changes" -msgstr "注目すべきプラグインの変更点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:88 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:81 -msgid "Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching." -msgstr "コレクションの cache プラグインを使用すると、インベントリープラグインからデータをキャッシュできます。以前は、コレクションの cache プラグインはファクトキャッシュにしか使用できませんでした。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:89 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:82 -msgid "Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``." -msgstr "``FILE_COMMON_ARGUMENTS`` から、文書化されていない引数がいくつか削除されました。これらの特定のアクションプラグインを使用するプラグインは、調整する必要があります。削除されたドキュメントなしの引数は、``src``、``follow``、``force``、``content``、``backup``、``remote_src``、``regexp``、``delimiter``、および ``directory_mode`` です。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:92 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:85 -msgid "Action plugins which execute modules should use fully-qualified module names" -msgstr "モジュールを実行するアクションプラグインは完全修飾モジュール名の使用が必要" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:94 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:87 -msgid "Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended." -msgstr "モジュールを呼び出すアクションプラグインは、可能な限り明示的な完全修飾モジュール名を ``_execute_module()`` に渡す必要があります (例: ``file``ではなく ``ansible.builtin.file``)。これにより、タスクのコレクション検索順序がモジュールを解決するように参照されなくなります。そうしないと、意図していないときに検索パスの前の方のコレクションのモジュールが使用されてしまう可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:99 -#: ../../rst/porting_guides/porting_guide_2.9.rst:45 -#: ../../rst/porting_guides/porting_guide_2.9.rst:724 -#: ../../rst/porting_guides/porting_guide_4.rst:106 -#: ../../rst/porting_guides/porting_guide_4.rst:112 -#: ../../rst/porting_guides/porting_guide_4.rst:133 -#: ../../rst/porting_guides/porting_guide_5.rst:97 -#: ../../rst/porting_guides/porting_guide_5.rst:103 -#: ../../rst/porting_guides/porting_guide_5.rst:109 -#: ../../rst/porting_guides/porting_guide_5.rst:122 -#: ../../rst/porting_guides/porting_guide_5.rst:128 -#: ../../rst/porting_guides/porting_guide_6.rst:44 -#: ../../rst/porting_guides/porting_guide_6.rst:50 -#: ../../rst/porting_guides/porting_guide_6.rst:64 -#: ../../rst/porting_guides/porting_guide_6.rst:70 -#: ../../rst/porting_guides/porting_guide_6.rst:76 -#: ../../rst/porting_guides/porting_guide_6.rst:88 -#: ../../rst/porting_guides/porting_guide_6.rst:94 -#: ../../rst/porting_guides/porting_guide_6.rst:100 -#: ../../rst/porting_guides/porting_guide_7.rst:49 -#: ../../rst/porting_guides/porting_guide_7.rst:55 -#: ../../rst/porting_guides/porting_guide_7.rst:63 -#: ../../rst/porting_guides/porting_guide_7.rst:69 -#: ../../rst/porting_guides/porting_guide_7.rst:75 -#: ../../rst/porting_guides/porting_guide_7.rst:81 -#: ../../rst/porting_guides/porting_guide_7.rst:87 -#: ../../rst/porting_guides/porting_guide_7.rst:93 -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:92 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:109 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:115 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:136 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:95 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:101 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:107 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:120 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:126 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:42 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:48 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:62 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:68 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:74 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:86 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:92 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:98 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:47 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:53 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:61 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:67 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:73 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:79 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:85 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:91 -msgid "No notable changes" -msgstr "主な変更はありません" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:102 -msgid "Porting Guide for v2.10.7" -msgstr "v2.10.7 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:105 -#: ../../rst/porting_guides/porting_guide_2.10.rst:191 -#: ../../rst/porting_guides/porting_guide_2.10.rst:264 -#: ../../rst/porting_guides/porting_guide_2.10.rst:376 -#: ../../rst/porting_guides/porting_guide_2.10.rst:469 -#: ../../rst/porting_guides/porting_guide_3.rst:103 -#: ../../rst/porting_guides/porting_guide_3.rst:205 -#: ../../rst/porting_guides/porting_guide_4.rst:36 -#: ../../rst/porting_guides/porting_guide_4.rst:192 -#: ../../rst/porting_guides/porting_guide_4.rst:541 -#: ../../rst/porting_guides/porting_guide_5.rst:169 -#: ../../rst/porting_guides/porting_guide_5.rst:460 -#: ../../rst/porting_guides/porting_guide_6.rst:80 -#: ../../rst/porting_guides/porting_guide_6.rst:171 -#: ../../rst/porting_guides/porting_guide_6.rst:431 -#: ../../rst/porting_guides/porting_guide_7.rst:121 -#: ../../rst/porting_guides/porting_guide_7.rst:304 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:39 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:78 -msgid "Breaking Changes" -msgstr "互換性を失わせる変更点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:108 -#: ../../rst/porting_guides/porting_guide_2.10.rst:150 -#: ../../rst/porting_guides/porting_guide_2.10.rst:202 -#: ../../rst/porting_guides/porting_guide_2.10.rst:275 -#: ../../rst/porting_guides/porting_guide_2.10.rst:360 -#: ../../rst/porting_guides/porting_guide_2.10.rst:518 -#: ../../rst/porting_guides/porting_guide_2.10.rst:651 -#: ../../rst/porting_guides/porting_guide_2.10.rst:809 -#: ../../rst/porting_guides/porting_guide_2.10.rst:924 -#: ../../rst/porting_guides/porting_guide_3.rst:174 -#: ../../rst/porting_guides/porting_guide_3.rst:225 -#: ../../rst/porting_guides/porting_guide_3.rst:329 -#: ../../rst/porting_guides/porting_guide_3.rst:467 -#: ../../rst/porting_guides/porting_guide_3.rst:608 -#: ../../rst/porting_guides/porting_guide_4.rst:414 -#: ../../rst/porting_guides/porting_guide_4.rst:491 -#: ../../rst/porting_guides/porting_guide_4.rst:563 -#: ../../rst/porting_guides/porting_guide_4.rst:717 -#: ../../rst/porting_guides/porting_guide_4.rst:868 -#: ../../rst/porting_guides/porting_guide_5.rst:231 -#: ../../rst/porting_guides/porting_guide_5.rst:259 -#: ../../rst/porting_guides/porting_guide_5.rst:268 -#: ../../rst/porting_guides/porting_guide_5.rst:312 -#: ../../rst/porting_guides/porting_guide_5.rst:402 -#: ../../rst/porting_guides/porting_guide_5.rst:549 -#: ../../rst/porting_guides/porting_guide_5.rst:706 -#: ../../rst/porting_guides/porting_guide_5.rst:850 -#: ../../rst/porting_guides/porting_guide_5.rst:969 -#: ../../rst/porting_guides/porting_guide_6.rst:150 -#: ../../rst/porting_guides/porting_guide_6.rst:174 -#: ../../rst/porting_guides/porting_guide_6.rst:182 -#: ../../rst/porting_guides/porting_guide_6.rst:203 -#: ../../rst/porting_guides/porting_guide_6.rst:234 -#: ../../rst/porting_guides/porting_guide_6.rst:251 -#: ../../rst/porting_guides/porting_guide_6.rst:375 -#: ../../rst/porting_guides/porting_guide_6.rst:404 -#: ../../rst/porting_guides/porting_guide_6.rst:518 -#: ../../rst/porting_guides/porting_guide_6.rst:690 -#: ../../rst/porting_guides/porting_guide_6.rst:802 -#: ../../rst/porting_guides/porting_guide_6.rst:931 -#: ../../rst/porting_guides/porting_guide_7.rst:124 -#: ../../rst/porting_guides/porting_guide_7.rst:176 -#: ../../rst/porting_guides/porting_guide_7.rst:261 -#: ../../rst/porting_guides/porting_guide_7.rst:434 -#: ../../rst/porting_guides/porting_guide_7.rst:606 -#: ../../rst/porting_guides/porting_guide_7.rst:870 -#: ../../rst/porting_guides/porting_guide_7.rst:1034 -msgid "community.general" -msgstr "community.general" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:110 -#: ../../rst/porting_guides/porting_guide_3.rst:269 -#: ../../rst/porting_guides/porting_guide_4.rst:574 -msgid "utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736)." -msgstr "utm_proxy_auth_profile - ``frontend_cookie_secret`` の戻り値に、モジュールの ``frontend_cookie_secret`` パラメーターではなくプレースホルダーの文字列が含まれるようになりました (https://github.com/ansible-collections/community.general/pull/1736)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:113 -#: ../../rst/porting_guides/porting_guide_2.10.rst:147 -#: ../../rst/porting_guides/porting_guide_2.10.rst:199 -#: ../../rst/porting_guides/porting_guide_2.10.rst:272 -#: ../../rst/porting_guides/porting_guide_2.10.rst:384 -#: ../../rst/porting_guides/porting_guide_2.10.rst:425 -#: ../../rst/porting_guides/porting_guide_2.10.rst:613 -#: ../../rst/porting_guides/porting_guide_3.rst:34 -#: ../../rst/porting_guides/porting_guide_3.rst:68 -#: ../../rst/porting_guides/porting_guide_3.rst:131 -#: ../../rst/porting_guides/porting_guide_3.rst:321 -#: ../../rst/porting_guides/porting_guide_4.rst:139 -#: ../../rst/porting_guides/porting_guide_4.rst:177 -#: ../../rst/porting_guides/porting_guide_4.rst:220 -#: ../../rst/porting_guides/porting_guide_4.rst:254 -#: ../../rst/porting_guides/porting_guide_4.rst:279 -#: ../../rst/porting_guides/porting_guide_4.rst:353 -#: ../../rst/porting_guides/porting_guide_4.rst:381 -#: ../../rst/porting_guides/porting_guide_4.rst:437 -#: ../../rst/porting_guides/porting_guide_4.rst:594 -#: ../../rst/porting_guides/porting_guide_5.rst:140 -#: ../../rst/porting_guides/porting_guide_5.rst:179 -#: ../../rst/porting_guides/porting_guide_5.rst:215 -#: ../../rst/porting_guides/porting_guide_5.rst:276 -#: ../../rst/porting_guides/porting_guide_5.rst:300 -#: ../../rst/porting_guides/porting_guide_5.rst:340 -#: ../../rst/porting_guides/porting_guide_5.rst:372 -#: ../../rst/porting_guides/porting_guide_5.rst:421 -#: ../../rst/porting_guides/porting_guide_5.rst:594 -#: ../../rst/porting_guides/porting_guide_6.rst:115 -#: ../../rst/porting_guides/porting_guide_6.rst:179 -#: ../../rst/porting_guides/porting_guide_6.rst:218 -#: ../../rst/porting_guides/porting_guide_6.rst:259 -#: ../../rst/porting_guides/porting_guide_6.rst:295 -#: ../../rst/porting_guides/porting_guide_6.rst:335 -#: ../../rst/porting_guides/porting_guide_6.rst:566 -#: ../../rst/porting_guides/porting_guide_7.rst:129 -#: ../../rst/porting_guides/porting_guide_7.rst:232 -#: ../../rst/porting_guides/porting_guide_7.rst:470 -msgid "Major Changes" -msgstr "主な変更点" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:115 -msgid "Restricting the version of the community.okd collection to 1.0.0. The previously included version, 1.0.1, had a dependency on kubernetes.core and thus required the installation of an additional collection that was not included in Ansible 2.10. Version 1.0.0 is essentially identical to 1.0.1, except that it uses community.kubernetes, which is included in Ansible 2.10." -msgstr "community.okd コレクションのバージョンを 1.0.0 に制限しました。これまで含まれていたバージョン 1.0.1 は、kubernetes.core に依存していたため、Ansible 2.10 に含まれていない追加のコレクションをインストールする必要がありました。バージョン 1.0.0 は、Ansible 2.10 に含まれている community.kubernetes を使用している以外は、1.0.1 と基本的に同じです。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:118 -#: ../../rst/porting_guides/porting_guide_2.10.rst:392 -#: ../../rst/porting_guides/porting_guide_2.10.rst:739 -#: ../../rst/porting_guides/porting_guide_3.rst:415 -#: ../../rst/porting_guides/porting_guide_4.rst:287 -#: ../../rst/porting_guides/porting_guide_5.rst:795 -#: ../../rst/porting_guides/porting_guide_6.rst:762 -msgid "ovirt.ovirt" -msgstr "ovirt.ovirt" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:120 -#: ../../rst/porting_guides/porting_guide_3.rst:424 -msgid "ovirt_system_option_info - Add new module (https://github.com/oVirt/ovirt-ansible-collection/pull/206)." -msgstr "ovirt_system_option_info - 新しいモジュールを追加します (https://github.com/oVirt/ovirt-ansible-collection/pull/206)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:123 -#: ../../rst/porting_guides/porting_guide_3.rst:430 -#: ../../rst/porting_guides/porting_guide_4.rst:584 -#: ../../rst/porting_guides/porting_guide_4.rst:689 -msgid "servicenow.servicenow" -msgstr "servicenow.servicenow" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:125 -#: ../../rst/porting_guides/porting_guide_3.rst:432 -msgid "add new tests (find with no result, search many)" -msgstr "新規テストの追加 (結果がない検索、多数の検索)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:126 -#: ../../rst/porting_guides/porting_guide_3.rst:433 -msgid "add related tests" -msgstr "関連テストの追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:127 -#: ../../rst/porting_guides/porting_guide_3.rst:434 -msgid "add support for ServiceNOW table api display_value exclude_reference_link and suppress_pagination_header" -msgstr "ServiceNOW テーブル api display_value exclude_reference_link および suppress_pagination_header のサポートを追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:128 -#: ../../rst/porting_guides/porting_guide_3.rst:435 -msgid "use new API for pysnow >=0.6.0" -msgstr "0.6.0 以降の pysnow で新しい API の使用" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:131 -#: ../../rst/porting_guides/porting_guide_2.10.rst:238 -#: ../../rst/porting_guides/porting_guide_2.10.rst:357 -#: ../../rst/porting_guides/porting_guide_2.10.rst:414 -#: ../../rst/porting_guides/porting_guide_2.10.rst:434 -#: ../../rst/porting_guides/porting_guide_2.10.rst:851 -#: ../../rst/porting_guides/porting_guide_3.rst:52 -#: ../../rst/porting_guides/porting_guide_3.rst:76 -#: ../../rst/porting_guides/porting_guide_3.rst:111 -#: ../../rst/porting_guides/porting_guide_3.rst:155 -#: ../../rst/porting_guides/porting_guide_3.rst:587 -#: ../../rst/porting_guides/porting_guide_4.rst:148 -#: ../../rst/porting_guides/porting_guide_4.rst:200 -#: ../../rst/porting_guides/porting_guide_4.rst:228 -#: ../../rst/porting_guides/porting_guide_4.rst:268 -#: ../../rst/porting_guides/porting_guide_4.rst:292 -#: ../../rst/porting_guides/porting_guide_4.rst:322 -#: ../../rst/porting_guides/porting_guide_4.rst:361 -#: ../../rst/porting_guides/porting_guide_4.rst:402 -#: ../../rst/porting_guides/porting_guide_4.rst:478 -#: ../../rst/porting_guides/porting_guide_4.rst:829 -#: ../../rst/porting_guides/porting_guide_5.rst:148 -#: ../../rst/porting_guides/porting_guide_5.rst:192 -#: ../../rst/porting_guides/porting_guide_5.rst:228 -#: ../../rst/porting_guides/porting_guide_5.rst:245 -#: ../../rst/porting_guides/porting_guide_5.rst:265 -#: ../../rst/porting_guides/porting_guide_5.rst:289 -#: ../../rst/porting_guides/porting_guide_5.rst:309 -#: ../../rst/porting_guides/porting_guide_5.rst:348 -#: ../../rst/porting_guides/porting_guide_5.rst:389 -#: ../../rst/porting_guides/porting_guide_5.rst:872 -#: ../../rst/porting_guides/porting_guide_6.rst:147 -#: ../../rst/porting_guides/porting_guide_6.rst:193 -#: ../../rst/porting_guides/porting_guide_6.rst:227 -#: ../../rst/porting_guides/porting_guide_6.rst:248 -#: ../../rst/porting_guides/porting_guide_6.rst:273 -#: ../../rst/porting_guides/porting_guide_6.rst:303 -#: ../../rst/porting_guides/porting_guide_6.rst:350 -#: ../../rst/porting_guides/porting_guide_6.rst:889 -#: ../../rst/porting_guides/porting_guide_7.rst:151 -#: ../../rst/porting_guides/porting_guide_7.rst:258 -#: ../../rst/porting_guides/porting_guide_7.rst:935 -msgid "Deprecated Features" -msgstr "非推奨の機能" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:134 -#: ../../rst/porting_guides/porting_guide_2.10.rst:417 -#: ../../rst/porting_guides/porting_guide_2.10.rst:437 -#: ../../rst/porting_guides/porting_guide_3.rst:590 -#: ../../rst/porting_guides/porting_guide_4.rst:151 -#: ../../rst/porting_guides/porting_guide_4.rst:236 -#: ../../rst/porting_guides/porting_guide_4.rst:330 -#: ../../rst/porting_guides/porting_guide_4.rst:642 -#: ../../rst/porting_guides/porting_guide_4.rst:844 -#: ../../rst/porting_guides/porting_guide_5.rst:392 -#: ../../rst/porting_guides/porting_guide_5.rst:920 -#: ../../rst/porting_guides/porting_guide_6.rst:676 -#: ../../rst/porting_guides/porting_guide_6.rst:913 -#: ../../rst/porting_guides/porting_guide_7.rst:573 -#: ../../rst/porting_guides/porting_guide_7.rst:750 -msgid "cisco.nxos" -msgstr "cisco.nxos" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:136 -#: ../../rst/porting_guides/porting_guide_3.rst:592 -msgid "Deprecated `nxos_bgp` and `nxos_bgp_neighbor` modules in favor of `nxos_bgp_global` resource module." -msgstr "`nxos_bgp` モジュールおよび `nxos_bgp_neighbor` モジュールが非推奨となり、`nxos_bgp_global` リソースモジュールが使用されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:139 -#: ../../rst/porting_guides/porting_guide_2.10.rst:537 -#: ../../rst/porting_guides/porting_guide_2.10.rst:827 -#: ../../rst/porting_guides/porting_guide_2.10.rst:944 -#: ../../rst/porting_guides/porting_guide_3.rst:79 -#: ../../rst/porting_guides/porting_guide_3.rst:634 -#: ../../rst/porting_guides/porting_guide_4.rst:241 -#: ../../rst/porting_guides/porting_guide_4.rst:384 -#: ../../rst/porting_guides/porting_guide_4.rst:887 -#: ../../rst/porting_guides/porting_guide_5.rst:726 -#: ../../rst/porting_guides/porting_guide_5.rst:1001 -#: ../../rst/porting_guides/porting_guide_6.rst:543 -#: ../../rst/porting_guides/porting_guide_6.rst:714 -#: ../../rst/porting_guides/porting_guide_6.rst:847 -#: ../../rst/porting_guides/porting_guide_7.rst:446 -#: ../../rst/porting_guides/porting_guide_7.rst:900 -msgid "community.vmware" -msgstr "community.vmware" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:141 -#: ../../rst/porting_guides/porting_guide_3.rst:636 -msgid "vmware_host_firewall_manager - the creation of new rule with no ``allowed_ip`` entry in the ``allowed_hosts`` dictionary won't be allowed after 2.0.0 release." -msgstr "vmware_host_firewall_manager - ``allowed_hosts`` ディクショナリーに ``allowed_ip`` エントリーがない新規ルールの作成は、2.0.0 リリース後は許可されなくなります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:144 -msgid "Porting Guide for v2.10.6" -msgstr "v2.10.6 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:152 -msgid "For community.general 2.0.0, the kubevirt modules will be moved to the `community.kubevirt `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、kubevirt モジュールは `community.kubevirt `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:155 -msgid "If you use Ansible 2.9 and explicitly use kubevirt modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.kubevirt.`` instead of ``community.general.``, for example replace ``community.general.kubevirt_vm`` in a task by ``community.kubevirt.kubevirt_vm``." -msgstr "Ansible 2.9 を使用し、このコレクションからの kubevirt モジュールを明示的に使用する場合は、``community.general.`` ではなく ``community.kubevirt.`` で始まる FQCN を使用するように Playbook およびロールを調整する必要があります (例: ``community.kubevirt.kubevirt_vm`` によるタスクで ``community.general.kubevirt_vm`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:158 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the kubevirt modules, you have to make sure to install the ``community.kubevirt`` collection as well. If you are using FQCNs, for example ``community.general.kubevirt_vm`` instead of ``kubevirt_vm``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、kubevirt モジュールに依存している場合は、``community.kubevirt`` コレクションもインストールする必要があります。FQCN を使用している場合は、たとえば ``kubevirt_vm`` の代わりに ``community.general.kubevirt_vm`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:162 -#: ../../rst/porting_guides/porting_guide_2.10.rst:304 -#: ../../rst/porting_guides/porting_guide_2.10.rst:368 -#: ../../rst/porting_guides/porting_guide_2.10.rst:532 -#: ../../rst/porting_guides/porting_guide_2.10.rst:822 -#: ../../rst/porting_guides/porting_guide_3.rst:282 -#: ../../rst/porting_guides/porting_guide_3.rst:551 -#: ../../rst/porting_guides/porting_guide_3.rst:629 -#: ../../rst/porting_guides/porting_guide_4.rst:807 -#: ../../rst/porting_guides/porting_guide_5.rst:200 -#: ../../rst/porting_guides/porting_guide_6.rst:700 -#: ../../rst/porting_guides/porting_guide_6.rst:831 -#: ../../rst/porting_guides/porting_guide_6.rst:952 -#: ../../rst/porting_guides/porting_guide_7.rst:617 -#: ../../rst/porting_guides/porting_guide_7.rst:884 -msgid "community.network" -msgstr "community.network" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:164 -msgid "For community.network 2.0.0, the Cisco NSO modules will be moved to the `cisco.nso `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.network 2.0.0 では、Cisco NSO モジュールは `cisco.nso `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更しなくてもよいように、リダイレクトが挿入されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:167 -msgid "If you use Ansible 2.9 and explicitly use Cisco NSO modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``cisco.nso.`` instead of ``community.network.``, for example replace ``community.network.nso_config`` in a task by ``cisco.nso.nso_config``." -msgstr "Ansible 2.9 を使用し、このコレクションから Cisco NSO モジュールを明示的に使用する場合は、Playbook およびロールを ``community.network.`` ではなく ``cisco.nso.`` で始まる FQCN を使用するように調整する必要があります (例: ``cisco.nso.nso_config`` によるタスクで ``community.network.nso_config`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:170 -msgid "If you use ansible-base and installed ``community.network`` manually and rely on the Cisco NSO modules, you have to make sure to install the ``cisco.nso`` collection as well. If you are using FQCNs, for example ``community.network.nso_config`` instead of ``nso_config``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.network`` を手動でインストールし、Cisco NSO モジュールに依存している場合は、``cisco.nso`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``nso_config`` の代わりに ``community.network.nso_config`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:172 -msgid "For community.network 2.0.0, the FortiOS modules will be moved to the `community.fortios `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.network 2.0.0 では、FortiOS モジュールは `community.fortios `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更しなくてもよいように、リダイレクトが挿入されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:175 -msgid "If you use Ansible 2.9 and explicitly use FortiOS modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.fortios.`` instead of ``community.network.``, for example replace ``community.network.fmgr_device`` in a task by ``community.fortios.fmgr_device``." -msgstr "Ansible 2.9 を使用し、このコレクションから FortiOS モジュールを明示的に使用する場合は、Playbook およびロールを ``community.network.`` ではなく ``community.fortios.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.fortios.fmgr_device`` によるタスクで ``community.network.fmgr_device`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:178 -msgid "If you use ansible-base and installed ``community.network`` manually and rely on the FortiOS modules, you have to make sure to install the ``community.fortios`` collection as well. If you are using FQCNs, for example ``community.network.fmgr_device`` instead of ``fmgr_device``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.network`` を手動でインストールし、FortiOS モジュールに依存している場合は、``community.fortios`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``fmgr_device`` の代わりに ``community.network.fmgr_device`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:182 -#: ../../rst/porting_guides/porting_guide_2.10.rst:387 -#: ../../rst/porting_guides/porting_guide_2.10.rst:409 -#: ../../rst/porting_guides/porting_guide_2.10.rst:728 -#: ../../rst/porting_guides/porting_guide_2.10.rst:841 -#: ../../rst/porting_guides/porting_guide_2.10.rst:958 -#: ../../rst/porting_guides/porting_guide_3.rst:84 -#: ../../rst/porting_guides/porting_guide_3.rst:148 -#: ../../rst/porting_guides/porting_guide_3.rst:373 -#: ../../rst/porting_guides/porting_guide_3.rst:582 -#: ../../rst/porting_guides/porting_guide_4.rst:813 -#: ../../rst/porting_guides/porting_guide_4.rst:892 -#: ../../rst/porting_guides/porting_guide_5.rst:303 -#: ../../rst/porting_guides/porting_guide_6.rst:732 -msgid "f5networks.f5_modules" -msgstr "f5networks.f5_modules" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:184 -#: ../../rst/porting_guides/porting_guide_3.rst:376 -msgid "Added async_timeout parameter to bigip_ucs_fetch module to allow customization of module wait for async interface" -msgstr "bigip_ucs_fetch モジュールに async_timeout パラメーターを追加して、モジュールが async インターフェースを待機できるようにします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:185 -#: ../../rst/porting_guides/porting_guide_3.rst:377 -msgid "Changed bigip_ucs_fetch module to use asynchronous interface when generating UCS files" -msgstr "UCS ファイルの生成時に非同期インターフェースを使用するように bigip_ucs_fetch モジュールの変更" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:188 -msgid "Porting Guide for v2.10.5" -msgstr "v2.10.5 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:194 -#: ../../rst/porting_guides/porting_guide_2.10.rst:251 -#: ../../rst/porting_guides/porting_guide_3.rst:272 -#: ../../rst/porting_guides/porting_guide_3.rst:619 -#: ../../rst/porting_guides/porting_guide_4.rst:212 -#: ../../rst/porting_guides/porting_guide_4.rst:364 -#: ../../rst/porting_guides/porting_guide_4.rst:420 -#: ../../rst/porting_guides/porting_guide_5.rst:195 -#: ../../rst/porting_guides/porting_guide_5.rst:384 -#: ../../rst/porting_guides/porting_guide_5.rst:407 -#: ../../rst/porting_guides/porting_guide_5.rst:556 -#: ../../rst/porting_guides/porting_guide_5.rst:866 -#: ../../rst/porting_guides/porting_guide_5.rst:989 -#: ../../rst/porting_guides/porting_guide_6.rst:306 -#: ../../rst/porting_guides/porting_guide_6.rst:823 -#: ../../rst/porting_guides/porting_guide_6.rst:944 -#: ../../rst/porting_guides/porting_guide_7.rst:209 -#: ../../rst/porting_guides/porting_guide_7.rst:440 -#: ../../rst/porting_guides/porting_guide_7.rst:1051 -msgid "community.hashi_vault" -msgstr "community.hashi_vault" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:196 -#: ../../rst/porting_guides/porting_guide_3.rst:274 -msgid "hashi_vault - the ``VAULT_ADDR`` environment variable is now checked last for the ``url`` parameter. For details on which use cases are impacted, see (https://github.com/ansible-collections/community.hashi_vault/issues/8)." -msgstr "hashi_vault - ``VAULT_ADDR`` 環境変数が、最後に ``url`` パラメーターについてチェックされるようになりました。影響を受けるユースケースの詳細は、https://github.com/ansible-collections/community.hashi_vault/issues/8 を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:204 -msgid "For community.general 2.0.0, the Google modules will be moved to the `community.google `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、Google モジュールは `community.google `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:207 -msgid "If you use Ansible 2.9 and explicitly use Google modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.google.`` instead of ``community.general.``, for example replace ``community.general.gcpubsub`` in a task by ``community.google.gcpubsub``." -msgstr "Ansible 2.9 を使用し、このコレクションから Google モジュールを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``community.google.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.google.gcpubsub`` によるタスクで ``community.general.gcpubsub`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:210 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the Google modules, you have to make sure to install the ``community.google`` collection as well. If you are using FQCNs, for example ``community.general.gcpubsub`` instead of ``gcpubsub``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、Google モジュールに依存している場合は、``community.google`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``gcpubsub`` の代わりに ``community.general.gcpubsub`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:212 -msgid "For community.general 2.0.0, the OC connection plugin will be moved to the `community.okd `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、OC 接続プラグインは `community.okd `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:215 -msgid "If you use Ansible 2.9 and explicitly use OC connection plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.okd.oc`` instead of ``community.general.oc``." -msgstr "Ansible 2.9 を使用し、このコレクションから OC 接続プラグインを明示的に使用する場合は、Playbook およびロールを ``community.general.oc`` ではなく FQCN の ``community.okd.oc`` を使用するように調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:217 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the OC connection plugin, you have to make sure to install the ``community.okd`` collection as well. If you are using FQCNs, in other words ``community.general.oc`` instead of ``oc``, it will continue working, but we still recommend to adjust this FQCN as well." -msgstr "ansible-base を使用し、手動でインストールした ``community.general`` を使用し、OC 接続プラグインに依存する場合は、``community.okd`` コレクションもインストールしてください。FQCN を使用している場合、つまり、``oc`` の代わりに ``community.general.oc`` を使用している場合、動作は継続されますが、この FQCN も調整することを推奨します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:219 -msgid "For community.general 2.0.0, the hashi_vault lookup plugin will be moved to the `community.hashi_vault `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、hashi_vault lookup プラグインは `community.hashi_vault `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:222 -msgid "If you use Ansible 2.9 and explicitly use hashi_vault lookup plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.hashi_vault.hashi_vault`` instead of ``community.general.hashi_vault``." -msgstr "Ansible 2.9 を使用し、このコレクションの hashi_vault lookup プラグインを明示的に使用する場合は、``community.general.hashi_vault`` ではなく FQCN ``community.hashi_vault.hashi_vault`` を使用するように Playbook およびロールを調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:224 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the hashi_vault lookup plugin, you have to make sure to install the ``community.hashi_vault`` collection as well. If you are using FQCNs, in other words ``community.general.hashi_vault`` instead of ``hashi_vault``, it will continue working, but we still recommend to adjust this FQCN as well." -msgstr "ansible-base を使用し、手動でインストールした ``community.general`` を手動でし、hashi_vault lookup プラグインに依存する場合は、``community.hashi_vault`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり、``hashi_vault`` ではなく ``community.general.hashi_vault`` を使用している場合、動作は継続されますが、この FQCN も調整することを推奨します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:228 -#: ../../rst/porting_guides/porting_guide_2.10.rst:559 -#: ../../rst/porting_guides/porting_guide_3.rst:405 -#: ../../rst/porting_guides/porting_guide_4.rst:465 -#: ../../rst/porting_guides/porting_guide_5.rst:785 -msgid "netbox.netbox" -msgstr "netbox.netbox" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:230 -#: ../../rst/porting_guides/porting_guide_3.rst:407 -msgid "nb_inventory - Add ``dns_name`` option that adds ``dns_name`` to the host when ``True`` and device has a primary IP address. (#394)" -msgstr "nb_inventory - ``True`` およびデバイスにプライマリー IP アドレスがある場合に ``dns_name`` をホストに追加する ``dns_name`` オプションを追加します。(#394)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:231 -#: ../../rst/porting_guides/porting_guide_3.rst:408 -msgid "nb_inventory - Add ``status`` as a ``group_by`` option. (398)" -msgstr "nb_inventory - ``group_by`` オプションとして ``status`` を追加します。(398)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:232 -#: ../../rst/porting_guides/porting_guide_3.rst:409 -msgid "nb_inventory - Move around ``extracted_primary_ip`` to allow for ``config_context`` or ``custom_field`` to overwrite. (#377)" -msgstr "nb_inventory - ``config_context`` または ``custom_field`` の上書きを許可する ``extracted_primary_ip`` を移動します。(#377)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:233 -#: ../../rst/porting_guides/porting_guide_3.rst:410 -msgid "nb_inventory - Services are now a list of integers due to NetBox 2.10 changes. (#396)" -msgstr "nb_inventory - サービスは、NetBox 2.10 の変更により整数の一覧になりました。(#396)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:234 -#: ../../rst/porting_guides/porting_guide_3.rst:411 -msgid "nb_lookup - Allow ID to be passed in and use ``.get`` instead of ``.filter``. (#376)" -msgstr "nb_lookup - ID を渡すことができ、``.filter`` の代わりに ``.get`` を使用できます。(#376)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:235 -#: ../../rst/porting_guides/porting_guide_3.rst:412 -msgid "nb_lookup - Allow ``api_endpoint`` and ``token`` to be found through env. (#391)" -msgstr "nb_lookup - env.から``api_endpoint`` と``token`` を検索できるようにしました (#391)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:241 -#: ../../rst/porting_guides/porting_guide_2.10.rst:892 -#: ../../rst/porting_guides/porting_guide_3.rst:55 -#: ../../rst/porting_guides/porting_guide_3.rst:163 -#: ../../rst/porting_guides/porting_guide_3.rst:598 -#: ../../rst/porting_guides/porting_guide_4.rst:855 -#: ../../rst/porting_guides/porting_guide_5.rst:498 -#: ../../rst/porting_guides/porting_guide_5.rst:681 -#: ../../rst/porting_guides/porting_guide_5.rst:926 -#: ../../rst/porting_guides/porting_guide_6.rst:358 -#: ../../rst/porting_guides/porting_guide_6.rst:473 -#: ../../rst/porting_guides/porting_guide_6.rst:684 -#: ../../rst/porting_guides/porting_guide_7.rst:357 -#: ../../rst/porting_guides/porting_guide_7.rst:579 -#: ../../rst/porting_guides/porting_guide_7.rst:768 -#: ../../rst/porting_guides/porting_guide_7.rst:1002 -msgid "community.aws" -msgstr "community.aws" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:243 -#: ../../rst/porting_guides/porting_guide_3.rst:600 -msgid "ec2_vpc_igw_info - After 2022-06-22 the ``convert_tags`` parameter default value will change from ``False`` to ``True`` to match the collection standard behavior (https://github.com/ansible-collections/community.aws/pull/318)." -msgstr "ec2_vpc_igw_info - 2022-06-22 以降、``convert_tags`` パラメーターのデフォルト値が ``False`` から ``True`` に変更し、コレクションの標準動作と一致するようになります (https://github.com/ansible-collections/community.aws/pull/318)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:246 -#: ../../rst/porting_guides/porting_guide_2.10.rst:331 -#: ../../rst/porting_guides/porting_guide_3.rst:60 -#: ../../rst/porting_guides/porting_guide_3.rst:106 -#: ../../rst/porting_guides/porting_guide_3.rst:441 -#: ../../rst/porting_guides/porting_guide_3.rst:603 -#: ../../rst/porting_guides/porting_guide_4.rst:335 -#: ../../rst/porting_guides/porting_guide_4.rst:486 -#: ../../rst/porting_guides/porting_guide_4.rst:558 -#: ../../rst/porting_guides/porting_guide_5.rst:153 -#: ../../rst/porting_guides/porting_guide_5.rst:544 -#: ../../rst/porting_guides/porting_guide_5.rst:842 -#: ../../rst/porting_guides/porting_guide_5.rst:962 -#: ../../rst/porting_guides/porting_guide_6.rst:369 -#: ../../rst/porting_guides/porting_guide_6.rst:923 -#: ../../rst/porting_guides/porting_guide_7.rst:423 -#: ../../rst/porting_guides/porting_guide_7.rst:584 -#: ../../rst/porting_guides/porting_guide_7.rst:858 -#: ../../rst/porting_guides/porting_guide_7.rst:1026 -msgid "community.docker" -msgstr "community.docker" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:248 -#: ../../rst/porting_guides/porting_guide_3.rst:605 -msgid "docker_container - currently ``published_ports`` can contain port mappings next to the special value ``all``, in which case the port mappings are ignored. This behavior is deprecated for community.docker 2.0.0, at which point it will either be forbidden, or this behavior will be properly implemented similar to how the Docker CLI tool handles this (https://github.com/ansible-collections/community.docker/issues/8, https://github.com/ansible-collections/community.docker/pull/60)." -msgstr "docker_container - 現在、``published_ports`` には、特別な値 ``all`` の横にポートマッピングを含めることができます。この動作は、community.docker 2.0.0 では非推奨です。その時点で、禁止されるか、Docker CLI ツールがどのようにこれを処理するかと同じように、この動作が適切に実装されます (https://github.com/ansible-collections/community.docker/issues/8、https://github.com/ansible-collections/community.docker/pull/60)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:253 -#: ../../rst/porting_guides/porting_guide_3.rst:621 -msgid "hashi_vault - ``VAULT_ADDR`` environment variable for option ``url`` will have its precedence lowered in 1.0.0; use ``ANSIBLE_HASHI_VAULT_ADDR`` to intentionally override a config value (https://github.com/ansible-collections/community.hashi_vault/issues/8)." -msgstr "hashi_vault - オプション ``url`` の ``VAULT_ADDR`` 環境変数の優先度は 1.0.0 で低くなります。設定値を意図的に上書きするには ``ANSIBLE_HASHI_VAULT_ADDR`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/8)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:254 -#: ../../rst/porting_guides/porting_guide_3.rst:622 -msgid "hashi_vault - ``VAULT_AUTH_METHOD`` environment variable for option ``auth_method`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/17)." -msgstr "hashi_vault - オプション ``auth_method`` の ``VAULT_AUTH_METHOD`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/17)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:255 -#: ../../rst/porting_guides/porting_guide_3.rst:623 -msgid "hashi_vault - ``VAULT_ROLE_ID`` environment variable for option ``role_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_ROLE_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20)." -msgstr "hashi_vault - オプション ``role_id`` の ``VAULT_ROLE_ID`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_ROLE_ID`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/20)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:256 -#: ../../rst/porting_guides/porting_guide_3.rst:624 -msgid "hashi_vault - ``VAULT_SECRET_ID`` environment variable for option ``secret_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_SECRET_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20)." -msgstr "hashi_vault - オプション ``secret_id`` の ``VAULT_SECRET_ID`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_SECRET_ID`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/20)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:257 -#: ../../rst/porting_guides/porting_guide_3.rst:625 -msgid "hashi_vault - ``VAULT_TOKEN_FILE`` environment variable for option ``token_file`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15)." -msgstr "hashi_vault - オプション ``token_file`` の ``VAULT_TOKEN_FILE`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/15)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:258 -#: ../../rst/porting_guides/porting_guide_3.rst:626 -msgid "hashi_vault - ``VAULT_TOKEN_PATH`` environment variable for option ``token_path`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15)." -msgstr "hashi_vault - オプション ``token_path`` の ``VAULT_TOKEN_PATH`` 環境変数は 2.0.0 で削除されます。代わりに ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` を使用します (https://github.com/ansible-collections/community.hashi_vault/issues/15)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:261 -msgid "Porting Guide for v2.10.4" -msgstr "v2.10.4 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:267 -#: ../../rst/porting_guides/porting_guide_3.rst:277 -msgid "community.hrobot" -msgstr "community.hrobot" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:269 -#: ../../rst/porting_guides/porting_guide_3.rst:279 -msgid "firewall - now requires the `ipaddress `_ library (https://github.com/ansible-collections/community.hrobot/pull/2)." -msgstr "firewall - `ipaddress `_ ライブラリーが必要になりました (https://github.com/ansible-collections/community.hrobot/pull/2)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:277 -msgid "For community.general 2.0.0, the Hetzner Robot modules will be moved to the `community.hrobot `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、Heatzner Robot モジュールが `community.hrobot `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更しないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:280 -msgid "If you use Ansible 2.9 and explicitly use Hetzner Robot modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.hrobot.`` instead of ``community.general.hetzner_``, for example replace ``community.general.hetzner_firewall_info`` in a task by ``community.hrobot.firewall_info``." -msgstr "Ansible 2.9 を使用して、このコレクションから Hetzner Robot モジュールを明示的に使用する場合は、``community.general.hetzner_`` ではなく ``community.hrobot.`` で始まる FQCN を使用するように Playbook およびロールを調整する必要があります (例: ``community.hrobot.firewall_info`` で、タスク内の ``community.general.hetzner_firewall_info`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:283 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the Hetzner Robot modules, you have to make sure to install the ``community.hrobot`` collection as well. If you are using FQCNs, i.e. ``community.general.hetzner_failover_ip`` instead of ``hetzner_failover_ip``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、Hetzner Robot モジュールに依存している場合は、``community.hrobot`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``hetzner_failover_ip`` の代わりに ``community.general.hetzner_failover_ip`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:285 -msgid "For community.general 2.0.0, the ``docker`` modules and plugins will be moved to the `community.docker `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、``docker`` モジュールおよびプラグインは `community.docker `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:288 -msgid "If you use Ansible 2.9 and explicitly use ``docker`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.docker.`` instead of ``community.general.``, for example replace ``community.general.docker_container`` in a task by ``community.docker.docker_container``." -msgstr "Ansible 2.9 を使用し、このコレクションから ``docker`` コンテンツを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``community.docker.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.docker.docker_container`` によるタスクで ``community.general.docker_container`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:291 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the ``docker`` content, you have to make sure to install the ``community.docker`` collection as well. If you are using FQCNs, i.e. ``community.general.docker_container`` instead of ``docker_container``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、``docker`` コンテンツに依存している場合は、``community.docker`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり ``docker_container`` の代わりに ``community.general.docker_container`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:293 -msgid "For community.general 2.0.0, the ``postgresql`` modules and plugins will be moved to the `community.postgresql `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 2.0.0 の場合、``postgresql`` モジュールおよびプラグインは `community.postgresql `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:296 -msgid "If you use Ansible 2.9 and explicitly use ``postgresql`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.postgresql.`` instead of ``community.general.``, for example replace ``community.general.postgresql_info`` in a task by ``community.postgresql.postgresql_info``." -msgstr "Ansible 2.9 を使用し、このコレクションから ``postgresql`` コンテンツを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``community.postgresql.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.postgresql.postgresql_info`` によるタスクで ``community.general.postgresql_info`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:299 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the ``postgresql`` content, you have to make sure to install the ``community.postgresql`` collection as well. If you are using FQCNs, i.e. ``community.general.postgresql_info`` instead of ``postgresql_info``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、``postgresql`` コンテンツに依存している場合は、``community.postgresql`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり ``postgresql_info`` の代わりに ``community.general.postgresql_info`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:301 -#: ../../rst/porting_guides/porting_guide_3.rst:340 -msgid "The community.general collection no longer depends on the ansible.posix collection (https://github.com/ansible-collections/community.general/pull/1157)." -msgstr "community.general コレクションは ansible.posix コレクションに依存しなくなりました (https://github.com/ansible-collections/community.general/pull/1157)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:306 -msgid "For community.network 2.0.0, the ``routeros`` modules and plugins will be moved to the `community.routeros `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.network 2.0.0 の場合、``routeros`` モジュールおよびプラグインは `community.routeros `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:309 -msgid "If you use Ansible 2.9 and explicitly use ``routeros`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.routeros.`` instead of ``community.network.routeros_``, for example replace ``community.network.routeros_api`` in a task by ``community.routeros.api``." -msgstr "Ansible 2.9 を使用し、このコレクションから ``routeros`` コンテンツを明示的に使用する場合は、Playbook およびロールを ``community.network.routeros_`` ではなく ``community.routeros.`` で始まる FQCN を使用するように調整する必要があります (例: ``community.routeros.api`` によるタスクで ``community.network.routeros_api`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:312 -msgid "If you use ansible-base and installed ``community.network`` manually and rely on the ``routeros`` content, you have to make sure to install the ``community.routeros`` collection as well. If you are using FQCNs, i.e. ``community.network.routeros_command`` instead of ``routeros_command``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.network`` を手動でインストールし、``routeros`` コンテンツに依存している場合は、``community.routeros`` コレクションもインストールする必要があります。FQCN を使用している場合、つまり ``routeros_command`` の代わりに ``community.network.routeros_command`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:314 -msgid "In community.network 2.0.0, the ``fortimanager`` httpapi plugin will be removed and replaced by a redirect to the corresponding plugin in the fortios.fortimanager collection. For Ansible 2.10 and ansible-base 2.10 users, this means that it will continue to work assuming that collection is installed. For Ansible 2.9 users, this means that they have to adjust the FQCN from ``community.network.fortimanager`` to ``fortios.fortimanager.fortimanager`` (https://github.com/ansible-collections/community.network/pull/151)." -msgstr "community.network 2.0.0 では、``fortimanager`` httpapi プラグインが削除され、fortios.fortimanager コレクションにある対応するプラグインへのリダイレクトに置き換えられます。Ansible 2.10 および ansible-base 2.10 ユーザーの場合は、コレクションがインストールされていると仮定して動作は継続します。Ansible 2.9 ユーザーは、FQCN を ``community.network.fortimanager`` から ``fortios.fortimanager.fortimanager`` へ調整する必要があることを意味します。(https://github.com/ansible-collections/community.network/pull/151)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:317 -#: ../../rst/porting_guides/porting_guide_3.rst:349 -#: ../../rst/porting_guides/porting_guide_5.rst:561 -#: ../../rst/porting_guides/porting_guide_5.rst:716 -msgid "community.okd" -msgstr "community.okd" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:319 -#: ../../rst/porting_guides/porting_guide_3.rst:351 -msgid "Add custom k8s module, integrate better Molecule tests (https://github.com/ansible-collections/community.okd/pull/7)." -msgstr "カスタム k8s モジュールを追加し、優れた Molecule テストを統合します (https://github.com/ansible-collections/community.okd/pull/7)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:320 -#: ../../rst/porting_guides/porting_guide_3.rst:352 -msgid "Add downstream build scripts to build redhat.openshift (https://github.com/ansible-collections/community.okd/pull/20)." -msgstr "redhat.openshift を構築するためのダウンストリームビルドスクリプトを追加します (https://github.com/ansible-collections/community.okd/pull/20)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:321 -#: ../../rst/porting_guides/porting_guide_3.rst:353 -msgid "Add openshift connection plugin, update inventory plugin to use it (https://github.com/ansible-collections/community.okd/pull/18)." -msgstr "openshift 接続プラグインを追加し、使用するインベントリープラグインを更新します (https://github.com/ansible-collections/community.okd/pull/18)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:322 -#: ../../rst/porting_guides/porting_guide_3.rst:354 -msgid "Add openshift_process module for template rendering and optional application of rendered resources (https://github.com/ansible-collections/community.okd/pull/44)." -msgstr "テンプレートをレンダリングし、レンダリングされたリソースの任意のアプリケーション用に openshift_process モジュールを追加します (https://github.com/ansible-collections/community.okd/pull/44)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:323 -#: ../../rst/porting_guides/porting_guide_3.rst:355 -msgid "Add openshift_route module for creating routes from services (https://github.com/ansible-collections/community.okd/pull/40)." -msgstr "サービスからルートを作成する openshift_route モジュールを追加します (https://github.com/ansible-collections/community.okd/pull/40)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:324 -#: ../../rst/porting_guides/porting_guide_3.rst:356 -msgid "Initial content migration from community.kubernetes (https://github.com/ansible-collections/community.okd/pull/3)." -msgstr "community.kubernetes からの最初のコンテンツの移行 (https://github.com/ansible-collections/community.okd/pull/3)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:325 -#: ../../rst/porting_guides/porting_guide_3.rst:357 -msgid "openshift_auth - new module (migrated from k8s_auth in community.kubernetes) (https://github.com/ansible-collections/community.okd/pull/33)." -msgstr "openshift_auth - 新しいモジュール (community.kubernetes の k8s_auth からの移行) (https://github.com/ansible-collections/community.okd/pull/33)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:328 -#: ../../rst/porting_guides/porting_guide_2.10.rst:406 -#: ../../rst/porting_guides/porting_guide_2.10.rst:786 -#: ../../rst/porting_guides/porting_guide_3.rst:145 -#: ../../rst/porting_guides/porting_guide_3.rst:438 -#: ../../rst/porting_guides/porting_guide_4.rst:470 -#: ../../rst/porting_guides/porting_guide_4.rst:703 -#: ../../rst/porting_guides/porting_guide_5.rst:381 -#: ../../rst/porting_guides/porting_guide_5.rst:800 -#: ../../rst/porting_guides/porting_guide_6.rst:787 -#: ../../rst/porting_guides/porting_guide_7.rst:686 -msgid "Removed Features" -msgstr "削除された機能" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:333 -#: ../../rst/porting_guides/porting_guide_3.rst:443 -msgid "docker_container - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_container - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:334 -#: ../../rst/porting_guides/porting_guide_3.rst:444 -msgid "docker_container - the default of ``networks_cli_compatible`` changed to ``true`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_container - ``networks_cli_compatible`` のデフォルトが ``true`` に変更になりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:335 -#: ../../rst/porting_guides/porting_guide_3.rst:445 -msgid "docker_container - the unused option ``trust_image_content`` has been removed (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_container - 未使用のオプション ``trust_image_content`` が削除されました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:336 -#: ../../rst/porting_guides/porting_guide_3.rst:446 -msgid "docker_image - ``state=build`` has been removed. Use ``present`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``state=build`` は削除されました。代わりに ``present`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:337 -#: ../../rst/porting_guides/porting_guide_3.rst:447 -msgid "docker_image - the ``container_limits``, ``dockerfile``, ``http_timeout``, ``nocache``, ``rm``, ``path``, ``buildargs``, ``pull`` have been removed. Use the corresponding suboptions of ``build`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``container_limits``、``dockerfile``、``http_timeout``、``nocache``、``rm``、``path``、``buildargs``、``pull`` が削除されました。 代わりに ``build`` の該当するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:338 -#: ../../rst/porting_guides/porting_guide_3.rst:448 -msgid "docker_image - the ``force`` option has been removed. Use the more specific ``force_*`` options instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``force`` オプションは削除されました。代わりに、より具体的な ``force_*`` オプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:339 -#: ../../rst/porting_guides/porting_guide_3.rst:449 -msgid "docker_image - the ``source`` option is now mandatory (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``source`` オプションが必須になりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:340 -#: ../../rst/porting_guides/porting_guide_3.rst:450 -msgid "docker_image - the ``use_tls`` option has been removed. Use ``tls`` and ``validate_certs`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``use_tls`` オプションが削除されました。代わりに ``tls`` および ``validate_certs`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:341 -#: ../../rst/porting_guides/porting_guide_3.rst:451 -msgid "docker_image - the default of the ``build.pull`` option changed to ``false`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - ``build.pull`` オプションのデフォルトが ``false`` に変更になりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:342 -#: ../../rst/porting_guides/porting_guide_3.rst:452 -msgid "docker_image_facts - this alias is on longer available, use ``docker_image_info`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_image - このエイリアスは利用できなくなります。代わりに ``docker_image_info`` を使用します (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:343 -#: ../../rst/porting_guides/porting_guide_3.rst:453 -msgid "docker_network - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_network - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:344 -#: ../../rst/porting_guides/porting_guide_3.rst:454 -msgid "docker_network - the ``ipam_options`` option has been removed. Use ``ipam_config`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_network - ``ipam_options`` オプションは削除されました。代わりに ``ipam_config`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:345 -#: ../../rst/porting_guides/porting_guide_3.rst:455 -msgid "docker_service - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_service - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:346 -#: ../../rst/porting_guides/porting_guide_3.rst:456 -msgid "docker_swarm - ``state=inspect`` has been removed. Use ``docker_swarm_info`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm - ``state=inspect`` が削除されました。代わりに ``docker_swarm_info`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:347 -#: ../../rst/porting_guides/porting_guide_3.rst:457 -msgid "docker_swarm_service - the ``constraints`` option has been removed. Use ``placement.constraints`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``constraints`` オプションは削除されました。代わりに ``placement.constraints`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:348 -#: ../../rst/porting_guides/porting_guide_3.rst:458 -msgid "docker_swarm_service - the ``limit_cpu`` and ``limit_memory`` options has been removed. Use the corresponding suboptions in ``limits`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``limit_cpu`` オプションおよび ``limit_memory`` オプションが削除されました。代わりに ``limits`` の対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:349 -#: ../../rst/porting_guides/porting_guide_3.rst:459 -msgid "docker_swarm_service - the ``log_driver`` and ``log_driver_options`` options has been removed. Use the corresponding suboptions in ``logging`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``log_driver`` オプションおよび ``log_driver_options`` オプションが削除されました。代わりに ``logging`` の対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:350 -#: ../../rst/porting_guides/porting_guide_3.rst:460 -msgid "docker_swarm_service - the ``reserve_cpu`` and ``reserve_memory`` options has been removed. Use the corresponding suboptions in ``reservations`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``reserve_cpu`` オプションおよび ``reserve_memory`` オプションが削除されました。代わりに ``reservations`` の対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:351 -#: ../../rst/porting_guides/porting_guide_3.rst:461 -msgid "docker_swarm_service - the ``restart_policy``, ``restart_policy_attempts``, ``restart_policy_delay`` and ``restart_policy_window`` options has been removed. Use the corresponding suboptions in ``restart_config`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``restart_policy`` オプション、``restart_policy_attempts`` オプション、``restart_policy_delay`` オプション、および ``restart_policy_window`` オプションが削除されました。代わりに ``restart_config`` の対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:352 -#: ../../rst/porting_guides/porting_guide_3.rst:462 -msgid "docker_swarm_service - the ``update_delay``, ``update_parallelism``, ``update_failure_action``, ``update_monitor``, ``update_max_failure_ratio`` and ``update_order`` options has been removed. Use the corresponding suboptions in ``update_config`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_swarm_service - ``update_delay`` オプション、``update_parallelism`` オプション、``update_failure_action`` オプション、``update_monitor``、``update_max_failure_ratio`` オプション、および ``update_order`` オプションが削除されました。代わりに ``update_config`` で対応するサブオプションを使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:353 -#: ../../rst/porting_guides/porting_guide_3.rst:463 -msgid "docker_volume - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_volume - ``ansible_facts`` が返されなくなりました (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:354 -#: ../../rst/porting_guides/porting_guide_3.rst:464 -msgid "docker_volume - the ``force`` option has been removed. Use ``recreate`` instead (https://github.com/ansible-collections/community.docker/pull/1)." -msgstr "docker_volume - ``force`` オプションは削除されました。代わりに ``recreate`` を使用してください (https://github.com/ansible-collections/community.docker/pull/1)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:362 -#: ../../rst/porting_guides/porting_guide_3.rst:612 -msgid "django_manage - the parameter ``liveserver`` relates to a no longer maintained third-party module for django. It is now deprecated, and will be remove in community.general 3.0.0 (https://github.com/ansible-collections/community.general/pull/1154)." -msgstr "django_manage - パラメーター ``liveserver`` は、django の維持されているサードパーティーモジュールに関連しなくなりました。現在は非推奨になり、community.general 3.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/1154)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:363 -#: ../../rst/porting_guides/porting_guide_3.rst:613 -msgid "proxmox - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850)." -msgstr "proxmox - 新しい ``proxmox_default_behavior`` オプションのデフォルトが community.general 4.0.0 で ``compatibility`` から ``no_defaults`` に変更します。非推奨の警告を防ぐために、オプションを明示的な値に設定します (https://github.com/ansible-collections/community.general/pull/850)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:364 -#: ../../rst/porting_guides/porting_guide_3.rst:614 -msgid "proxmox_kvm - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850)." -msgstr "proxmox_kvm - 新しい ``proxmox_default_behavior`` オプションのデフォルトが community.general 4.0.0 で ``compatibility`` から ``no_defaults`` に変更されます。非推奨の警告を防ぐために、オプションを明示的な値に設定します (https://github.com/ansible-collections/community.general/pull/850)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:365 -#: ../../rst/porting_guides/porting_guide_3.rst:615 -msgid "syspatch - deprecate the redundant ``apply`` argument (https://github.com/ansible-collections/community.general/pull/360)." -msgstr "syspatch - 冗長な ``apply`` 引数を非推奨にします (https://github.com/ansible-collections/community.general/pull/360)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:370 -#: ../../rst/porting_guides/porting_guide_3.rst:631 -msgid "Deprecate connection=local support for network platforms using persistent framework (https://github.com/ansible-collections/community.network/pull/120)." -msgstr "永続的なフレームワークを使用したネットワークプラットフォームの connection=local サポートを非推奨にします（https://github.com/ansible-collections/community.network/pull/120)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:373 -msgid "Porting Guide for v2.10.2" -msgstr "v2.10.2 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:379 -#: ../../rst/porting_guides/porting_guide_2.10.rst:616 -#: ../../rst/porting_guides/porting_guide_2.10.rst:789 -#: ../../rst/porting_guides/porting_guide_2.10.rst:856 -#: ../../rst/porting_guides/porting_guide_3.rst:37 -#: ../../rst/porting_guides/porting_guide_3.rst:208 -msgid "Ansible-base" -msgstr "Ansible-base" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:381 -msgid "ansible-galaxy login command has been removed (see https://github.com/ansible/ansible/issues/71560)" -msgstr "ansible-galaxy login コマンドが削除されました (https://github.com/ansible/ansible/issues/71560 を参照))。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:389 -#: ../../rst/porting_guides/porting_guide_3.rst:375 -msgid "Add phone home Teem integration into all modules, functionality can be disabled by setting up F5_TEEM environment variable or no_f5_teem provider parameter" -msgstr "すべてのモジュールに phone home Teem 統合を追加します。F5_TEEM 環境変数または no_f5_teem プロバイダーパラメーターを設定して機能を無効にできます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:394 -#: ../../rst/porting_guides/porting_guide_3.rst:417 -msgid "cluster_upgrade - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/94)." -msgstr "cluster_upgrade - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/94)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:395 -#: ../../rst/porting_guides/porting_guide_3.rst:418 -msgid "disaster_recovery - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/134)." -msgstr "disaster_recovery - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/134)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:396 -#: ../../rst/porting_guides/porting_guide_3.rst:419 -msgid "engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/69)." -msgstr "engine_setup - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/69)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:397 -#: ../../rst/porting_guides/porting_guide_3.rst:420 -msgid "hosted_engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/106)." -msgstr "hosted_engine_setup - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/106)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:398 -#: ../../rst/porting_guides/porting_guide_3.rst:421 -msgid "image_template - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/95)." -msgstr "image_template - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/95)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:399 -#: ../../rst/porting_guides/porting_guide_3.rst:422 -msgid "infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/92)." -msgstr "infra - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/92)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:400 -#: ../../rst/porting_guides/porting_guide_3.rst:423 -msgid "manageiq - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/97)." -msgstr "manageiq - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/97)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:401 -#: ../../rst/porting_guides/porting_guide_3.rst:425 -msgid "repositories - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/96)." -msgstr "repositories - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/96)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:402 -#: ../../rst/porting_guides/porting_guide_3.rst:426 -msgid "shutdown_env - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/112)." -msgstr "shutdown_env - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/112)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:403 -#: ../../rst/porting_guides/porting_guide_3.rst:427 -msgid "vm_infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/93)." -msgstr "vm_infra - ロールを移行します (https://github.com/oVirt/ovirt-ansible-collection/pull/93)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:411 -#: ../../rst/porting_guides/porting_guide_3.rst:584 -msgid "Removed arp_state parameter from the bigip_virtual_address module" -msgstr "bigip_virtual_address モジュールから arp_state パラメーターを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:419 -#: ../../rst/porting_guides/porting_guide_3.rst:593 -msgid "Deprecated `nxos_interface_ospf` in favor of `nxos_ospf_interfaces` Resource Module." -msgstr "`nxos_interface_ospf` を非推奨にし、`nxos_ospf_interfaces` Resource Module が採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:422 -msgid "Porting Guide for v2.10.1" -msgstr "v2.10.1 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:428 -#: ../../rst/porting_guides/porting_guide_2.10.rst:664 -#: ../../rst/porting_guides/porting_guide_3.rst:343 -#: ../../rst/porting_guides/porting_guide_5.rst:711 -#: ../../rst/porting_guides/porting_guide_5.rst:996 -msgid "community.kubernetes" -msgstr "community.kubernetes" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:430 -#: ../../rst/porting_guides/porting_guide_3.rst:345 -msgid "k8s - Add support for template parameter (https://github.com/ansible-collections/community.kubernetes/pull/230)." -msgstr "k8s - テンプレートパラメーターのサポートを追加します (https://github.com/ansible-collections/community.kubernetes/pull/230)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:431 -#: ../../rst/porting_guides/porting_guide_3.rst:346 -msgid "k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/community.kubernetes/pull/193)." -msgstr "k8s_* - Vault 済み kubeconfig および src のサポートを追加します (https://github.com/ansible-collections/community.kubernetes/pull/193)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:439 -#: ../../rst/porting_guides/porting_guide_3.rst:594 -msgid "Deprecated `nxos_smu` in favor of `nxos_rpm` module." -msgstr "`nxos_smu` を非推奨にし、`nxos_rpm` モジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:440 -#: ../../rst/porting_guides/porting_guide_3.rst:595 -msgid "The `nxos_ospf_vrf` module is deprecated by `nxos_ospfv2` and `nxos_ospfv3` Resource Modules." -msgstr "`nxos_ospf_vrf` モジュールは、`nxos_ospfv2` および `nxos_ospfv3` Resource Module によって非推奨となりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:443 -msgid "Porting Guide for v2.10.0" -msgstr "v2.10.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:446 -#: ../../rst/porting_guides/porting_guide_3.rst:23 -#: ../../rst/porting_guides/porting_guide_3.rst:92 -#: ../../rst/porting_guides/porting_guide_3.rst:122 -#: ../../rst/porting_guides/porting_guide_3.rst:195 -#: ../../rst/porting_guides/porting_guide_4.rst:169 -#: ../../rst/porting_guides/porting_guide_4.rst:314 -#: ../../rst/porting_guides/porting_guide_4.rst:372 -#: ../../rst/porting_guides/porting_guide_4.rst:428 -#: ../../rst/porting_guides/porting_guide_4.rst:520 -#: ../../rst/porting_guides/porting_guide_5.rst:256 -#: ../../rst/porting_guides/porting_guide_5.rst:320 -#: ../../rst/porting_guides/porting_guide_5.rst:359 -#: ../../rst/porting_guides/porting_guide_5.rst:439 -#: ../../rst/porting_guides/porting_guide_6.rst:106 -#: ../../rst/porting_guides/porting_guide_6.rst:163 -#: ../../rst/porting_guides/porting_guide_6.rst:287 -#: ../../rst/porting_guides/porting_guide_6.rst:319 -#: ../../rst/porting_guides/porting_guide_6.rst:391 -#: ../../rst/porting_guides/porting_guide_7.rst:105 -#: ../../rst/porting_guides/porting_guide_7.rst:223 -#: ../../rst/porting_guides/porting_guide_7.rst:278 -msgid "Known Issues" -msgstr "既知の問題" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:448 -msgid "Due to a limitation in pip, you cannot ``pip install --upgrade`` from ansible-2.9 or earlier to ansible-2.10 or higher. Instead, you must explicitly use ``pip uninstall ansible`` before pip installing the new version. If you attempt to upgrade Ansible with pip without first uninstalling, the installer warns you to uninstall first." -msgstr "pip の制限により、ansible-2.9 以前から ansible-2.10 以降には ``pip install --upgrade`` を行うことができません。代わりに、pip で新しいバージョンをインストールする前に ``pip uninstall ansible`` を明示的に使用する必要があります。最初にアンインストールせずに pip で Ansible をアップグレードする場合は、インストーラーが最初にアンインストールを警告します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:449 -#, python-format -msgid "The individual collections that make up the ansible-2.10.0 package can be viewed independently. However, they are not currently listed by ansible-galaxy. To view these collections with ansible-galaxy, explicitly specify where ansible has installed the collections -- ``COLLECTION_INSTALL=$(python -c 'import ansible, os.path ; print(\"%s/../ansible_collections\" % os.path.dirname(ansible.__file__))') ansible-galaxy collection list -p \"$COLLECTION_INSTALL\"``." -msgstr "ansible-2.10.0 パッケージを構成する個々のコレクションは個別に表示できますが、現在 ansible-galaxy により一覧表示されていません。ansible-galaxy でこれらのコレクションを表示するには、ansible がコレクションをインストールした場所を明示的に指定します。``COLLECTION_INSTALL=$(python -c 'import ansible, os.path ; print(\"%s/../ansible_collections\" % os.path.dirname(ansible.__file__))') ansible-galaxy collection list -p \"$COLLECTION_INSTALL\"``" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:450 -msgid "These fortios modules are not automatically redirected from their 2.9.x names to the new 2.10.x names within collections. You must modify your playbooks to use fully qualified collection names for them. You can use the documentation (https://docs.ansible.com/ansible/2.10/collections/fortinet/fortios/) for the ``fortinet.fortios`` collection to determine what the fully qualified collection names are." -msgstr "これらの fortios モジュールは、コレクション内で 2.9.x の名前から新しい 2.10.x の名前に自動的にリダイレクトされません。これらのモジュールに完全修飾コレクション名を使用するように Playbook を変更する必要があります。完全修飾コレクション名については、``fortinet.fortios`` コレクションのドキュメント (https://docs.ansible.com/ansible/2.10/collections/fortinet/fortios/) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:452 -msgid "fortios_address" -msgstr "fortios_address" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:453 -msgid "fortios_config" -msgstr "fortios_config" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:454 -msgid "fortios_firewall_DoS_policy" -msgstr "fortios_firewall_DoS_policy" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:455 -msgid "fortios_firewall_DoS_policy6" -msgstr "fortios_firewall_DoS_policy6" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:456 -msgid "fortios_ipv4_policy" -msgstr "fortios_ipv4_policy" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:457 -msgid "fortios_switch_controller_802_1X_settings" -msgstr "fortios_switch_controller_802_1X_settings" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:458 -msgid "fortios_switch_controller_security_policy_802_1X" -msgstr "fortios_switch_controller_security_policy_802_1X" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:459 -msgid "fortios_system_firmware_upgrade" -msgstr "fortios_system_firmware_upgrade" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:460 -msgid "fortios_system_nd_proxy" -msgstr "fortios_system_nd_proxy" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:461 -msgid "fortios_webfilter" -msgstr "fortios_webfilter" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:464 -#: ../../rst/porting_guides/porting_guide_2.10.rst:658 -#: ../../rst/porting_guides/porting_guide_3.rst:134 -#: ../../rst/porting_guides/porting_guide_4.rst:271 -#: ../../rst/porting_guides/porting_guide_4.rst:648 -#: ../../rst/porting_guides/porting_guide_5.rst:984 -msgid "community.grafana" -msgstr "community.grafana" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:466 -msgid "grafana_datasource doesn't set password correctly (#113)" -msgstr "grafana_datasource でパスワードが正しく設定されない (#113)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:471 -msgid "cisco.nxos.nxos_igmp_interface - no longer supports the deprecated ``oif_prefix`` and ``oif_source`` options. These have been superseded by ``oif_ps``." -msgstr "cisco.nxos.nxos_igmp_interface - 非推奨の ``oif_prefix`` オプションおよび ``oif_source`` オプションをサポートしなくなりました。これらは ``oif_ps`` に置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:472 -msgid "community.grafana.grafana_dashboard - the parameter ``message`` is renamed to ``commit_message`` since ``message`` is used by Ansible Core engine internally." -msgstr "community.grafana.grafana_dashboard - ``message`` は内部的に Ansible Core Engine で使用されるため、パラメーター ``message`` の名前が ``commit_message`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:473 -msgid "purestorage.flashblade.purefb_fs - no longer supports the deprecated ``nfs`` option. This has been superseded by ``nfsv3``." -msgstr "purestorage.flashblade.purefb_fs - 非推奨の ``nfs`` オプションに対応しなくなりました。これは ``nfsv3`` に置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:476 -#: ../../rst/porting_guides/porting_guide_2.10.rst:627 -#: ../../rst/porting_guides/porting_guide_2.10.rst:863 -#: ../../rst/porting_guides/porting_guide_5.rst:481 -#: ../../rst/porting_guides/porting_guide_5.rst:618 -#: ../../rst/porting_guides/porting_guide_5.rst:883 -#: ../../rst/porting_guides/porting_guide_6.rst:441 -#: ../../rst/porting_guides/porting_guide_6.rst:577 -#: ../../rst/porting_guides/porting_guide_6.rst:901 -#: ../../rst/porting_guides/porting_guide_7.rst:321 -#: ../../rst/porting_guides/porting_guide_7.rst:482 -#: ../../rst/porting_guides/porting_guide_7.rst:708 -#: ../../rst/porting_guides/porting_guide_7.rst:956 -msgid "amazon.aws" -msgstr "amazon.aws" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:478 -msgid "aws_s3 - can now delete versioned buckets even when they are not empty - set mode to delete to delete a versioned bucket and everything in it." -msgstr "aws_s3 - バージョンアップされたバケットが空でなくても削除できるようになりました。モードを delete に設定すると、バージョンアップされたバケットとその中のものがすべて削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:481 -#: ../../rst/porting_guides/porting_guide_2.10.rst:799 -#: ../../rst/porting_guides/porting_guide_2.10.rst:882 -#: ../../rst/porting_guides/porting_guide_4.rst:407 -#: ../../rst/porting_guides/porting_guide_4.rst:473 -#: ../../rst/porting_guides/porting_guide_4.rst:481 -#: ../../rst/porting_guides/porting_guide_5.rst:810 -#: ../../rst/porting_guides/porting_guide_5.rst:895 -#: ../../rst/porting_guides/porting_guide_7.rst:141 -msgid "ansible.windows" -msgstr "ansible.windows" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:483 -msgid "setup - Make sure ``ansible_date_time.epoch`` is seconds since EPOCH in UTC to mirror the POSIX facts. The ``ansible_date_time.epoch_local`` contains seconds since EPOCH in the local timezone for backwards compatibility" -msgstr "setup - POSIX ファクトを反映させるために、``ansible_date_time.epoch`` が UTC の EPOCH 以降の秒数であることを確認します。後方互換のために、``ansible_date_time.epoch_local`` には、ローカルタイムゾーンの EPOCH 以降の秒数が含まれています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:484 -msgid "setup - Will now add the IPv6 scope on link local addresses for ``ansible_ip_addresses``" -msgstr "setup - ``ansible_ip_addresses`` のリンクローカルアドレスに IPv6 スコープを追加します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:485 -msgid "setup - ``ansible_processor`` will now return the index before the other values to match the POSIX fact behaviour" -msgstr "setup - ``ansible_processor`` が、POSIX ファクトの動作に一致するために他の値の前にインデックスを返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:486 -msgid "win_find - No longer filters by size on directories, this feature had a lot of bugs, slowed down the module, and not a supported scenario with the ``find`` module." -msgstr "win_find - ディレクトリーにおいてサイズでフィルターが設定されるようになり、この機能はバグが多くなり、モジュールの速度が低下し、``find`` モジュールでの対応シナリオはありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:489 -msgid "win_find - module has been refactored to better match the behaviour of the ``find`` module. Here is what has changed:" -msgstr "win_find - モジュールは、``find`` モジュールの動作に合わせてリファクタリングされました。これが変更になりました:" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:488 -msgid "When the directory specified by ``paths`` does not exist or is a file, it will no longer fail and will just warn the user" -msgstr "``paths`` で指定されたディレクトリーが存在しないか、ファイルであると、失敗しなくなり、ユーザーに警告が表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:489 -msgid "Junction points are no longer reported as ``islnk``, use ``isjunction`` to properly report these files. This behaviour matches the win_stat module" -msgstr "ジャンクションポイントは ``islnk`` として報告されなくなりました。これらのファイルを正しく報告するには ``isjunction`` を使用してください。この動作は win_stat モジュールと一致します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:490 -msgid "Directories no longer return a ``size``, this matches the ``stat`` and ``find`` behaviour and has been removed due to the difficulties in correctly reporting the size of a directory" -msgstr "ディレクトリーが ``size`` を返さなくなりました。これは ``stat`` および ``find`` の動作と一致し、ディレクトリーのサイズを正しく報告することが困難であるため、削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:491 -msgid "win_user - Change idempotency checks for ``description`` to be case sensitive" -msgstr "win_user - 大文字と小文字を区別するために ``description`` の冪等性チェックを変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:492 -msgid "win_user - Change idempotency checks for ``fullname`` to be case sensitive" -msgstr "win_user - 大文字と小文字を区別するために ``fullname`` の冪等性チェックを変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:495 -#: ../../rst/porting_guides/porting_guide_2.10.rst:642 -#: ../../rst/porting_guides/porting_guide_5.rst:343 -#: ../../rst/porting_guides/porting_guide_6.rst:118 -#: ../../rst/porting_guides/porting_guide_6.rst:671 -#: ../../rst/porting_guides/porting_guide_7.rst:116 -#: ../../rst/porting_guides/porting_guide_7.rst:235 -msgid "cisco.meraki" -msgstr "cisco.meraki" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:497 -msgid "meraki_device - Changed tags from string to list" -msgstr "meraki_device - 文字列からリストにタグを変更しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:498 -msgid "meraki_device - Removed serial_lldp_cdp parameter" -msgstr "meraki_device - serial_lldp_cdp パラメーターを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:499 -msgid "meraki_device - Removed serial_uplink parameter" -msgstr "meraki_device - serial_uplink パラメーターを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:500 -msgid "meraki_intrusion_prevention - Rename whitedlisted_rules to allowed_rules" -msgstr "meraki_intrusion_prevention - whitedlisted_rules の名前を allowed_rules に変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:501 -msgid "meraki_mx_l3_firewall - Rule responses are now in a `rules` list" -msgstr "meraki_mx_l3_firewall - ルール応答が `rules` リストに表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:502 -msgid "meraki_mx_l7_firewall - Rename blacklisted_countries to blocked_countries" -msgstr "meraki_mx_l7_firewall - blocked_countries の名前を blacklisted_countries に変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:503 -msgid "meraki_mx_l7_firewall - Rename whitelisted_countries to allowed_countries" -msgstr "meraki_mx_l7_firewall - whitelisted_countries の名前を allowed_countries に変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:504 -msgid "meraki_network - Local and remote status page settings cannot be set during network creation" -msgstr "meraki_network - ネットワークの作成時にローカルおよびリモートステータスページ設定を設定できません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:505 -msgid "meraki_network - `disableRemoteStatusPage` response is now `remote_status_page_enabled`" -msgstr "meraki_network - `disableRemoteStatusPage` の応答が `remote_status_page_enabled` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:506 -msgid "meraki_network - `disable_my_meraki_com` response is now `local_status_page_enabled`" -msgstr "meraki_network - `disable_my_meraki_com` の応答が `local_status_page_enabled` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:507 -msgid "meraki_network - `disable_my_meraki` has been deprecated" -msgstr "meraki_network - `disable_my_meraki` が非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:508 -msgid "meraki_network - `enable_my_meraki` is now called `local_status_page_enabled`" -msgstr "meraki_network - `enable_my_meraki` が `local_status_page_enabled` と呼ばれるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:509 -msgid "meraki_network - `enable_remote_status_page` is now called `remote_status_page_enabled`" -msgstr "meraki_network - `enable_remote_status_page` が `remote_status_page_enabled` と呼ばれるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:510 -msgid "meraki_network - `enabled` response for VLAN status is now `vlans_enabled`" -msgstr "meraki_network - VLAN ステータスに対する `enabled` 応答が `vlans_enabled` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:511 -msgid "meraki_network - `tags` and `type` now return a list" -msgstr "meraki_network - `tags` および `type` が一覧を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:512 -msgid "meraki_snmp - peer_ips is now a list" -msgstr "meraki_snmp - peer_ips がリストになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:513 -msgid "meraki_switchport - `access_policy_number` is now an int and not a string" -msgstr "meraki_switchport - `access_policy_number` は文字列型ではなく int 型になりました" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:514 -msgid "meraki_switchport - `tags` is now a list and not a string" -msgstr "meraki_switchport - `tags` が文字列型ではなくリスト型になりました" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:515 -msgid "meraki_webhook - Querying test status now uses state of query." -msgstr "meraki_webhook - テストステータスのクエリーはクエリー状態を使用するようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:520 -msgid "The environment variable for the auth context for the oc.py connection plugin has been corrected (K8S_CONTEXT). It was using an initial lowercase k by mistake. (https://github.com/ansible-collections/community.general/pull/377)." -msgstr "oc.py 接続プラグインの認証コンテキストの環境変数 (K8S_CONTEXT) が修正されました。これは、最初の小文字の k を間違って使用していました (https://github.com/ansible-collections/community.general/pull/377)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:521 -msgid "bigpanda - the parameter ``message`` was renamed to ``deployment_message`` since ``message`` is used by Ansible Core engine internally." -msgstr "bigpanda - ``message`` は Ansible Core Engine で内部的に使用されているため、パラメーター ``message`` は ``deployment_message`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:522 -msgid "cisco_spark - the module option ``message`` was renamed to ``msg``, as ``message`` is used internally in Ansible Core engine (https://github.com/ansible/ansible/issues/39295)" -msgstr "cisco_spark - Ansible Core エンジンで ``message`` が内部で使用されるため、モジュールオプション ``message`` の名前が ``msg`` に変更されました (https://github.com/ansible/ansible/issues/39295)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:523 -msgid "datadog - the parameter ``message`` was renamed to ``notification_message`` since ``message`` is used by Ansible Core engine internally." -msgstr "datadog - ``message`` は Ansible Core Engine で内部的に使用されているため、パラメーターの名前 ``message`` は ``notification_message`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:524 -msgid "docker_container - no longer passes information on non-anonymous volumes or binds as ``Volumes`` to the Docker daemon. This increases compatibility with the ``docker`` CLI program. Note that if you specify ``volumes: strict`` in ``comparisons``, this could cause existing containers created with docker_container from Ansible 2.9 or earlier to restart." -msgstr "docker_container - 匿名でないボリュームの情報や ``Volumes`` としてのバインドを Docker デーモンに渡さなくなりました。これにより、``docker`` CLI プログラムとの互換性が高まりました。なお、``comparisons`` に``volumes: strict`` を指定すると、Ansible 2.9 以前の docker_container で作成された既存のコンテナーが再起動する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:525 -msgid "docker_container - support for port ranges was adjusted to be more compatible to the ``docker`` command line utility: a one-port container range combined with a multiple-port host range will no longer result in only the first host port be used, but the whole range being passed to Docker so that a free port in that range will be used." -msgstr "docker_container - ポート範囲のサポートは、``docker`` コマンドラインユーティリティーとの互換性を高めるために調整されました。1 ポートのコンテナー範囲と複数ポートのホスト範囲を組み合わせた場合は、最初のホストポートのみが使用されることはなくなり、範囲全体が Docker に渡され、その範囲内の空きポートが使用されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:526 -msgid "hashi_vault lookup - now returns the latest version when using the KV v2 secrets engine. Previously, it returned all versions of the secret which required additional steps to extract and filter the desired version." -msgstr "hashi_vault lookup - KV v2 シークレットエンジンを使用する際に、最新バージョンを返すようになりました。これまでは、すべてのバージョンのシークレットが返されていたため、目的のバージョンを抽出してフィルタリングするための追加手順が必要でした。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:527 -#: ../../rst/porting_guides/porting_guide_3.rst:264 -msgid "log_plays callback - add missing information to the logs generated by the callback plugin. This changes the log message format (https://github.com/ansible-collections/community.general/pull/442)." -msgstr "log_plays callback - callback プラグインで生成されたログに不足している情報を追加します。これにより、ログメッセージの形式が変更されます (https://github.com/ansible-collections/community.general/pull/442)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:528 -#: ../../rst/porting_guides/porting_guide_3.rst:266 -msgid "pkgng - passing ``name: *`` with ``state: absent`` will no longer remove every installed package from the system. It is now a noop. (https://github.com/ansible-collections/community.general/pull/569)." -msgstr "pkgng - ``name: *`` に ``state: absent`` を渡すと、インストール済みパッケージがすべてシステムから削除されなくなり、noop になりました (https://github.com/ansible-collections/community.general/pull/569)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:529 -#: ../../rst/porting_guides/porting_guide_3.rst:267 -msgid "pkgng - passing ``name: *`` with ``state: latest`` or ``state: present`` will no longer install every package from the configured package repositories. Instead, ``name: *, state: latest`` will upgrade all already-installed packages, and ``name: *, state: present`` is a noop. (https://github.com/ansible-collections/community.general/pull/569)." -msgstr "pkgng - ``name: *`` に ``state: latest`` または``state: present`` を渡すと、設定されたパッケージリポジトリーからすべてのパッケージをインストールしなくなります。代わりに、``name: *, state: latest`` は既にインストールされているパッケージをすべてアップグレードし、``name: *, state: present`` は noop です (https://github.com/ansible-collections/community.general/pull/569)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:534 -msgid "routeros_facts - allow multiple addresses and neighbors per interface. This makes ``ansible_net_neighbors`` a list instead of a dict (https://github.com/ansible-collections/community.network/pull/6)." -msgstr "routeros_facts - インターフェースごとに複数のアドレスと近接アドレスを許可します。これにより、``ansible_net_neighbors`` が dict ではなく list になります (https://github.com/ansible-collections/community.network/pull/6)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:539 -msgid "vmware_datastore_maintenancemode - now returns ``datastore_status`` instead of Ansible internal key ``results``." -msgstr "vmware_datastore_maintenancemode - Ansible 内部キー ``results`` の代わりに ``datastore_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:540 -msgid "vmware_guest_custom_attributes - does not require VM name which was a required parameter for releases prior to Ansible 2.10." -msgstr "vmware_guest_custom_attributes - Ansible 2.10 より前のリリースで必須だったパラメーターである仮想マシン名は必要ありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:541 -msgid "vmware_guest_find - the ``datacenter`` option has been removed." -msgstr "vmware_guest_find - ``datacenter`` オプションは削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:542 -msgid "vmware_host_kernel_manager - now returns ``host_kernel_status`` instead of Ansible internal key ``results``." -msgstr "vmware_host_kernel_manager - Ansible 内部キー ``results`` の代わりに ``host_kernel_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:543 -msgid "vmware_host_ntp - now returns ``host_ntp_status`` instead of Ansible internal key ``results``." -msgstr "vmware_host_ntp - Ansible 内部キー ``results`` の代わりに ``host_ntp_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:544 -msgid "vmware_host_service_manager - now returns ``host_service_status`` instead of Ansible internal key ``results``." -msgstr "vmware_host_service_manager - Ansible 内部キー ``results`` の代わりに ``host_service_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:545 -msgid "vmware_tag - now returns ``tag_status`` instead of Ansible internal key ``results``." -msgstr "vmware_tag - Ansible 内部キー ``results`` の代わりに ``tag_status`` を返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:546 -msgid "vmware_vmkernel - the options ``ip_address`` and ``subnet_mask`` have been removed; use the suboptions ``ip_address`` and ``subnet_mask`` of the ``network`` option instead." -msgstr "vmware_vmkernel - ``ip_address`` オプションおよび ``subnet_mask`` オプションが削除されました。代わりに ``network`` オプションのサブオプション ``ip_address`` および ``subnet_mask`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:549 -#: ../../rst/porting_guides/porting_guide_2.10.rst:835 -msgid "community.windows" -msgstr "community.windows" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:551 -msgid "win_pester - no longer runs all ``*.ps1`` file in the directory specified due to it executing potentially unknown scripts. It will follow the default behaviour of only running tests for files that are like ``*.tests.ps1`` which is built into Pester itself." -msgstr "win_pester - 未知のスクリプトを実行する可能性があるため、指定したディレクトリー内のすべての ``*.ps1`` ファイルを実行しなくなりました。Pester 自体に組み込まれている ``*.tests.ps1`` のようなファイルに対してのみテストを実行するというデフォルトの動作に従います。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:554 -#: ../../rst/porting_guides/porting_guide_2.10.rst:953 -#: ../../rst/porting_guides/porting_guide_4.rst:195 -#: ../../rst/porting_guides/porting_guide_5.rst:573 -#: ../../rst/porting_guides/porting_guide_6.rst:124 -#: ../../rst/porting_guides/porting_guide_7.rst:241 -msgid "community.zabbix" -msgstr "community.zabbix" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:556 -msgid "zabbix_javagateway - options ``javagateway_pidfile``, ``javagateway_listenip``, ``javagateway_listenport`` and ``javagateway_startpollers`` renamed to ``zabbix_javagateway_xyz`` (see `UPGRADE.md `_)." -msgstr "zabbix_javagateway - ``javagateway_pidfile`` オプション、``javagateway_listenip`` オプション、``javagateway_listenport``、および ``javagateway_startpollers`` オプションの名前が ``zabbix_javagateway_xyz`` に変更されています (`UPGRADE.md `_ を参照してください)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:561 -msgid "Change ``ip-addresses`` key in netbox inventory plugin to ``ip_addresses`` (https://github.com/netbox-community/ansible_modules/issues/139)" -msgstr "netbox インベントリープラグインの ``ip-addresses`` キーを ``ip_addresses`` に変更します (https://github.com/netbox-community/ansible_modules/issues/139)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:562 -msgid "Changed ``group`` to ``tenant_group`` in ``netbox_tenant.py`` (https://github.com/netbox-community/ansible_modules/issues/9)" -msgstr "``netbox_tenant.py`` の ``group`` を ``tenant_group`` へ変更しました (https://github.com/netbox-community/ansible_modules/issues/9)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:563 -msgid "Changed ``role`` to ``prefix_role`` in ``netbox_prefix.py`` (https://github.com/netbox-community/ansible_modules/issues/9)" -msgstr "``netbox_prefix.py`` の ``role`` を ``prefix_role`` へ変更しました (https://github.com/netbox-community/ansible_modules/issues/9)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:564 -msgid "Module failures when required fields aren't provided (https://github.com/netbox-community/ansible_modules/issues/24)" -msgstr "必須フィールドが提供されていない場合のモジュールの失敗 (https://github.com/netbox-community/ansible_modules/issues/24)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:565 -msgid "Renamed ``netbox_interface`` to ``netbox_device_interface`` (https://github.com/netbox-community/ansible_modules/issues/9)" -msgstr "``netbox_interface`` の名前が ``netbox_device_interface`` に変更 (https://github.com/netbox-community/ansible_modules/issues/9)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:566 -msgid "This version has a few breaking changes due to new namespace and collection name. I felt it necessary to change the name of the lookup plugin and inventory plugin just not to have a non descriptive namespace call to use them. Below is an example: ``netbox.netbox.netbox`` would be used for both inventory plugin and lookup plugin, but in different contexts so no collision will arise, but confusion will. I renamed the lookup plugin to ``nb_lookup`` so it will be used with the FQCN ``netbox.netbox.nb_lookup``. The inventory plugin will now be called within an inventory file by ``netbox.netbox.nb_inventory``" -msgstr "このバージョンには、新しい名前空間とコレクション名のためにいくつかの重大な変更があります。lookup プラグインと inventory プラグインの名前を変更して、それを使用するための非記述的な名前空間呼び出しを行わないようにする必要があると感じました。以下に例を示します。inventory プラグインと lookup プラグインの両方に ``netbox.netbox.netbox`` が使用されますが、コンテキストが異なるため、衝突は発生しませんが、混乱が発生します。lookup プラグインの名前を ``nb_lookup`` に変更しました。そのため、FQCN ``netbox.netbox.nb_lookup`` で使用されます。インベントリープラグインは、インベントリーファイル内で ``netbox.netbox.nb_inventory`` により呼び出されるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:570 -msgid "To pass in integers through Ansible Jinja filters for a key in ``data`` that requires querying an endpoint is now done by making it a dictionary with an ``id`` key. The previous behavior was to just pass in an integer and it was converted when normalizing the data, but some people may have names that are all integers and those were being converted erroneously so we made the decision to change the method to convert to an integer for the NetBox API." -msgstr "エンドポイントへの問い合わせが必要な ``data`` のキーに対して、Ansible Jinja のフィルターで整数を渡すためには、``id`` キーを持つディクショナリーにすることで行うようになりました。これまでの動作では、整数を渡すだけでデータの正規化時に変換されていましたが、人によっては名前がすべて整数である場合があり、それらが誤って変換されていたため、NetBox API では整数に変換する方法に変更することにしました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:593 -msgid "``pynetbox`` changed to using ``requests.Session()`` to manage the HTTP session which broke passing in ``ssl_verify`` when building the NetBox API client. This PR makes ``pynetbox 5.0.4+`` the new required version of `pynetbox` for the Ansible modules and lookup plugin. (https://github.com/netbox-community/ansible_modules/pull/269)" -msgstr "``pynetbox`` は、NetBox API クライアントを構築する際に ``ssl_verify`` を渡すことができなくなったため、HTTP セッションの管理に ``requests.Session()`` を使用するように変更しました。この PR により、``pynetbox 5.0.4+`` は、Ansible モジュールと lookup プラグインに必要な `pynetbox` の新しいバージョンとなりました (https://github.com/netbox-community/ansible_modules/pull/269)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:599 -#: ../../rst/porting_guides/porting_guide_4.rst:589 -#: ../../rst/porting_guides/porting_guide_6.rst:560 -msgid "theforeman.foreman" -msgstr "theforeman.foreman" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:601 -msgid "All modules were renamed to drop the ``foreman_`` and ``katello_`` prefixes. Additionally to the prefix removal, the following modules were further ranamed:" -msgstr "すべてのモジュールの名前が ``foreman_`` 接頭辞および ``katello_`` 接頭辞を削除するように変更されました。接頭辞の削除以外に、以下のモジュールの名前がさらに無視されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:604 -msgid "katello_upload to content_upload" -msgstr "katello_upload から content_upload へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:605 -msgid "katello_sync to repository_sync" -msgstr "katello_sync から repository_sync へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:606 -msgid "katello_manifest to subscription_manifest" -msgstr "katello_manifest から subscription_manifest へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:607 -msgid "foreman_search_facts to resource_info" -msgstr "foreman_search_facts から resource_info へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:608 -msgid "foreman_ptable to partition_table" -msgstr "foreman_ptable から partition_table へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:609 -msgid "foreman_model to hardware_model" -msgstr "foreman_model から hardware_model へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:610 -msgid "foreman_environment to puppet_environment" -msgstr "foreman_environment から puppet_environment へ" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:618 -msgid "Both ansible-doc and ansible-console's help command will error for modules and plugins whose return documentation cannot be parsed as YAML. All modules and plugins passing ``ansible-test sanity --test yamllint`` will not be affected by this." -msgstr "ansible-doc と ansible-console の help コマンドの両方が、リターンドキュメントが YAML として解析できないモジュールとプラグインに対してエラーを出します。``ansible-test sanity --test yamllint`` を通過するすべてのモジュールとプラグインは、この影響を受けません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:619 -msgid "Collections may declare a list of supported/tested Ansible versions for the collection. A warning is issued if a collection does not support the Ansible version that loads it (can also be configured as silent or a fatal error). Collections that do not declare supported Ansible versions do not issue a warning/error." -msgstr "コレクションは、そのコレクションでサポート/テストされている Ansible のバージョンのリストを宣言することができます。コレクションが、それを読み込む Ansible バージョンをサポートしていない場合は、警告が発行されます (サイレントまたは致命的なエラーとして設定することもできます)。サポートされている Ansible のバージョンを宣言していないコレクションは、警告/エラーを発行しません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:620 -msgid "Plugin routing allows collections to declare deprecation, redirection targets, and removals for all plugin types." -msgstr "プラグインルーティングにより、コレクションはすべてのプラグインタイプの非推奨、リダイレクトターゲット、および削除を宣言できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:621 -msgid "Plugins that import module_utils and other ansible namespaces that have moved to collections should continue to work unmodified." -msgstr "コレクションに移動した module_utils およびその他の Ansible 名前空間をインポートするプラグインは、変更せずに動作し続けます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:622 -msgid "Routing data built into Ansible 2.10 ensures that 2.9 content should work unmodified on 2.10. Formerly included modules and plugins that were moved to collections are still accessible by their original unqualified names, so long as their destination collections are installed." -msgstr "Ansible 2.10 に組み込まれたルーティングデータにより、2.9 のコンテンツが 2.10 で変更なく動作することが保証されます。コレクションに移動した以前に同梱されているモジュールやプラグインは、移動先のコレクションがインストールされている限り、元の未修飾名でアクセスできます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:623 -msgid "When deprecations are done in code, they to specify a ``collection_name`` so that deprecation warnings can mention which collection - or ansible-base - is deprecating a feature. This affects all ``Display.deprecated()`` or ``AnsibleModule.deprecate()`` or ``Ansible.Basic.Deprecate()`` calls, and ``removed_in_version``/``removed_at_date`` or ``deprecated_aliases`` in module argument specs." -msgstr "コードで非推奨となった場合は、非推奨の警告でどのコレクション (または ansible-base) が機能を非推奨としているかを言及できるように、``collection_name`` を指定する必要があります。これは、すべての ``Display.deprecated()``、``AnsibleModule.deprecate()``、または``Ansible.Basic.Deprecate()`` の呼び出し、およびモジュール引数仕様の ``removed_in_version``/``removed_at_date`` または ``deprecated_aliases`` に影響します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:624 -msgid "ansible-test now uses a different ``default`` test container for Ansible Collections" -msgstr "ansible-test が、Ansible Collections に異なる ``default`` テストコンテナーを使用するようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:629 -msgid "ec2 module_utils - The ``AWSRetry`` decorator no longer catches ``NotFound`` exceptions by default. ``NotFound`` exceptions need to be explicitly added using ``catch_extra_error_codes``. Some AWS modules may see an increase in transient failures due to AWS''s eventual consistency model." -msgstr "ec2 module_utils - ``AWSRetry`` デコレーターは、デフォルトで ``NotFound`` の例外をキャッチしなくなりました。``NotFound`` の例外は、``catch_extra_error_codes`` を使用して明示的に追加する必要があります。一部の AWS モジュールでは、AWS の最終的な一貫性モデルにより、一時的な障害が増加する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:632 -#: ../../rst/porting_guides/porting_guide_2.10.rst:794 -#: ../../rst/porting_guides/porting_guide_4.rst:295 -#: ../../rst/porting_guides/porting_guide_4.rst:553 -#: ../../rst/porting_guides/porting_guide_4.rst:613 -#: ../../rst/porting_guides/porting_guide_4.rst:839 -#: ../../rst/porting_guides/porting_guide_5.rst:890 -#: ../../rst/porting_guides/porting_guide_6.rst:399 -#: ../../rst/porting_guides/porting_guide_6.rst:460 -#: ../../rst/porting_guides/porting_guide_6.rst:582 -#: ../../rst/porting_guides/porting_guide_7.rst:718 -msgid "ansible.netcommon" -msgstr "ansible.netcommon" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:634 -msgid "Add libssh connection plugin and refactor network_cli (https://github.com/ansible-collections/ansible.netcommon/pull/30)" -msgstr "libssh 接続プラグインを追加し、refactor network_cli をリファクタリングします (https://github.com/ansible-collections/ansible.netcommon/pull/30)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:637 -msgid "ansible.posix" -msgstr "ansible.posix" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:639 -msgid "Bootstrap Collection (https://github.com/ansible-collections/ansible.posix/pull/1)." -msgstr "ブートストラップコレクション (https://github.com/ansible-collections/ansible.posix/pull/1)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:644 -msgid "Rewrite requests method for version 1.0 API and improved readability" -msgstr "バージョン 1.0 の API に合わせて requests メソッドを書き換え、読みやすさを向上させました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:645 -msgid "meraki_mr_rf_profile - Configure wireless RF profiles." -msgstr "meraki_mr_rf_profile - ワイヤレス RF プロファイルを設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:646 -msgid "meraki_mr_settings - Configure network settings for wireless." -msgstr "meraki_mr_settings - ワイヤレスのネットワーク設定を構成します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:647 -msgid "meraki_ms_l3_interface - New module" -msgstr "meraki_ms_l3_interface - 新しいモジュール" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:648 -msgid "meraki_ms_ospf - Configure OSPF." -msgstr "meraki_ms_ospf - OSPF を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:653 -msgid "docker_container - the ``network_mode`` option will be set by default to the name of the first network in ``networks`` if at least one network is given and ``networks_cli_compatible`` is ``true`` (will be default from community.general 2.0.0 on). Set to an explicit value to avoid deprecation warnings if you specify networks and set ``networks_cli_compatible`` to ``true``. The current default (not specifying it) is equivalent to the value ``default``." -msgstr "docker_container -``network_mode`` オプションは、少なくとも 1 つのネットワークが指定され、``networks_cli_compatible`` が``true`` である場合は、``networks`` の最初のネットワークの名前がデフォルトで設定されます (community.general 2.0.0 以降はデフォルトになります)。ネットワークを指定して ``networks_cli_compatible`` を ``true`` に設定した場合の非推奨警告を回避するために、明示的な値に設定します。現在のデフォルト (指定なし) は、``default`` の値と同等です。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:654 -msgid "docker_container - the module has a new option, ``container_default_behavior``, whose default value will change from ``compatibility`` to ``no_defaults``. Set to an explicit value to avoid deprecation warnings." -msgstr "docker_container - モジュールには新しいオプション ``container_default_behavior`` があり、そのデフォルト値は ``compatibility`` から ``no_defaults`` に変更になります。非推奨の警告を回避するために明示的な値を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:655 -msgid "gitlab_user - no longer requires ``name``, ``email`` and ``password`` arguments when ``state=absent``." -msgstr "gitlab_user - ``state=absent`` の場合に ``name`` 引数、``email`` 引数、および ``password`` 引数が必要なくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:660 -msgid "Add changelog management for ansible 2.10 (#112)" -msgstr "Ansible 2.10 の changelog 管理を追加 (#112)" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:661 -msgid "grafana_datasource ; adding additional_json_data param" -msgstr "grafana_datasource - additional_json_data パラメーターの追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:666 -msgid "Add changelog and fragments and document changelog process (https://github.com/ansible-collections/community.kubernetes/pull/131)." -msgstr "変更ログおよびフラグメントを追加し、変更ログプロセスを文書化します (https://github.com/ansible-collections/community.kubernetes/pull/131)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:667 -msgid "helm - New module for managing Helm charts (https://github.com/ansible-collections/community.kubernetes/pull/61)." -msgstr "helm - Helm チャート管理用の新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:668 -msgid "helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/community.kubernetes/pull/61)." -msgstr "helm_info - Helm チャート情報を取得する新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:669 -msgid "helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154)." -msgstr "helm_plugin - Helm プラグインを管理する新しいモジュール (https://github.com/ansible-collections/community.kubernetes/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:670 -msgid "helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154)." -msgstr "helm_plugin_info - Helm プラグインに関する情報を収集する新しいモジュール (https://github.com/ansible-collections/community.kubernetes/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:671 -msgid "helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/community.kubernetes/pull/61)." -msgstr "helm_repository - Helm リポジトリーを管理するための新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:672 -#: ../../rst/porting_guides/porting_guide_3.rst:389 -msgid "k8s - Inventory source migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s - Ansible 2.9 から Kubernetes コレクションに移行したインベントリーソース。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:673 -#: ../../rst/porting_guides/porting_guide_3.rst:390 -msgid "k8s - Lookup plugin migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s - Ansible 2.9 から Kubernetes コレクションに移行したプラグイン。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:674 -#: ../../rst/porting_guides/porting_guide_3.rst:391 -msgid "k8s - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:675 -#: ../../rst/porting_guides/porting_guide_3.rst:393 -msgid "k8s_auth - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_auth - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:676 -#: ../../rst/porting_guides/porting_guide_3.rst:394 -msgid "k8s_config_resource_name - Filter plugin migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_config_resource_name - Ansible 2.9 から Kubernetes コレクションに移行したプラグインにフィルターを設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:677 -msgid "k8s_exec - New module for executing commands on pods through Kubernetes API (https://github.com/ansible-collections/community.kubernetes/pull/14)." -msgstr "k8s_exec - Kubernetes API を使用して Pod でコマンドを実行する新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/14)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:678 -msgid "k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/community.kubernetes/pull/158)." -msgstr "k8s_exec - 実行したコマンドの rc を返します (https://github.com/ansible-collections/community.kubernetes/pull/158)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:679 -#: ../../rst/porting_guides/porting_guide_3.rst:397 -msgid "k8s_info - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_info - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:680 -msgid "k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/community.kubernetes/pull/16)." -msgstr "k8s_log - Pod ログを取得する新規モジュール (https://github.com/ansible-collections/community.kubernetes/pull/16)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:681 -#: ../../rst/porting_guides/porting_guide_3.rst:399 -msgid "k8s_scale - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_scale - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:682 -#: ../../rst/porting_guides/porting_guide_3.rst:400 -msgid "k8s_service - Module migrated from Ansible 2.9 to Kubernetes collection." -msgstr "k8s_service - Ansible 2.9 から Kubernetes コレクションに移行したモジュール。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:683 -#: ../../rst/porting_guides/porting_guide_3.rst:401 -msgid "kubectl - Connection plugin migrated from Ansible 2.9 to Kubernetes collection." -msgstr "kubectl - Ansible 2.9 から Kubernetes コレクションに移行した接続プラグイン。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:684 -#: ../../rst/porting_guides/porting_guide_3.rst:402 -msgid "openshift - Inventory source migrated from Ansible 2.9 to Kubernetes collection." -msgstr "openshift - Ansible 2.9 から Kubernetes コレクションに移行したインベントリーソース。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:687 -msgid "community.libvirt" -msgstr "community.libvirt" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:689 -msgid "added generic libvirt inventory plugin" -msgstr "汎用 libvirt インベントリープラグインの追加" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:690 -msgid "removed libvirt_lxc inventory script" -msgstr "libvirt_lxc インベントリースクリプトを削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:693 -#: ../../rst/porting_guides/porting_guide_3.rst:309 -#: ../../rst/porting_guides/porting_guide_3.rst:367 -msgid "dellemc.os10" -msgstr "dellemc.os10" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:695 -msgid "New role os10_aaa - Facilitates the configuration of Authentication Authorization and Accounting (AAA), TACACS and RADIUS server." -msgstr "新しいロール os10_aaa - 認証承認およびアカウント (AAA)、TACACS サーバーおよび RADIUS サーバーの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:696 -msgid "New role os10_acl - Facilitates the configuration of Access Control lists." -msgstr "新しいロール os10_acl - アクセス制御リストの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:697 -msgid "New role os10_bfd - Facilitates the configuration of BFD global attributes." -msgstr "新しいロール os10_bfd - BFD グローバル属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:698 -msgid "New role os10_bgp - Facilitates the configuration of border gateway protocol (BGP) attributes." -msgstr "新しいロール os10_bgp - 境界線ゲートウェイプロトコル (BGP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:699 -msgid "New role os10_copy_config - This role pushes the backup running configuration into a OS10 device." -msgstr "新しいロール os10_copy_config - このロールは、バックアップの実行設定を OS10 デバイスにプッシュします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:700 -msgid "New role os10_dns - Facilitates the configuration of domain name service (DNS)." -msgstr "新しいロール os10_dns - ドメインネームサービス (DNS) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:701 -msgid "New role os10_ecmp - Facilitates the configuration of equal cost multi-path (ECMP) for IPv4." -msgstr "新しいロール os10_ecmp - IPv4 用の同等のコストマルチパス (ECMP) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:702 -msgid "New role os10_fabric_summary Facilitates to get show system information of all the OS10 switches in the fabric." -msgstr "新しいロール os10_fabric_summary - ファブリック内のすべての OS10 スイッチのシステム情報を表示するのを容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:703 -msgid "New role os10_flow_monitor Facilitates the configuration of ACL flow-based monitoring attributes." -msgstr "新しいロール os10_flow_monitor - ACL フローベースの監視属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:704 -msgid "New role os10_image_upgrade Facilitates installation of OS10 software images." -msgstr "新しいロール os10_image_upgrade - OS10 ソフトウェアイメージのインストールを容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:705 -msgid "New role os10_interface Facilitates the configuration of interface attributes." -msgstr "新しいロール os10_interface - インターフェース属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:706 -msgid "New role os10_lag Facilitates the configuration of link aggregation group (LAG) attributes." -msgstr "新しいロール os10_lag - リンクアグリゲーショングループ (LAG) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:707 -msgid "New role os10_lldp Facilitates the configuration of link layer discovery protocol (LLDP) attributes at global and interface level." -msgstr "新しいロール os10_lldp - グローバルおよびインターフェースレベルでのリンクレイヤー検出プロトコル (LLDP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:708 -msgid "New role os10_logging Facilitates the configuration of global logging attributes and logging servers." -msgstr "新しいロール os10_logging - グローバルロギング属性およびロギングサーバーの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:709 -msgid "New role os10_network_validation Facilitates validation of wiring connection, BGP neighbors, MTU between neighbors and VLT pair." -msgstr "新しいロール os10_network_validation - 配線接続、BGP 近接、近接間 MTU、VLT ペアの検証を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:710 -msgid "New role os10_ntp Facilitates the configuration of network time protocol (NTP) attributes." -msgstr "新しいロール os10_ntp - ネットワークタイムプロトコル (NTP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:711 -msgid "New role os10_prefix_list Facilitates the configuration of IP prefix-list." -msgstr "新しいロール os10_prefix_list - IP プレフィックスリストの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:712 -msgid "New role os10_qos Facilitates the configuration of quality of service attributes including policy-map and class-map." -msgstr "新しいロール os10_qos - policy-map および class-map を含む QoS (Quality of Service) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:713 -msgid "New role os10_raguard Facilitates the configuration of IPv6 RA Guard attributes." -msgstr "新しいロール os10_raguard - IPv6 RA Guard 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:714 -msgid "New role os10_route_map Facilitates the configuration of route-map attributes." -msgstr "新しいロール os10_route_map - route-map 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:715 -msgid "New role os10_snmp Facilitates the configuration of global SNMP attributes." -msgstr "新しいロール os10_snmp - グローバル SNMP 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:716 -msgid "New role os10_system Facilitates the configuration of hostname and hashing algorithm." -msgstr "新しいロール os10_system - ホスト名とハッシュアルゴリズムの設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:717 -msgid "New role os10_template The role takes the raw string input from the CLI of OS10 device, and returns a structured text in the form of a Python dictionary." -msgstr "新しいロール os10_template - このロールは、OS10 デバイスの CLI から raw 文字列入力を取得し、Python ディクショナリーの形式で構造化されたテキストを返します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:718 -msgid "New role os10_uplink Facilitates the configuration of uplink attributes like uplink-state group." -msgstr "新しいロール os10_uplink - uplink-state グループのようなアップリンク属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:719 -msgid "New role os10_users Facilitates the configuration of global system user attributes." -msgstr "新しいロール os10_users - グローバルシステムユーザー属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:720 -msgid "New role os10_vlan Facilitates the configuration of virtual LAN (VLAN) attributes." -msgstr "新しいロール os10_vlan - 仮想 LAN (VLAN) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:721 -msgid "New role os10_vlt Facilitates the configuration of virtual link trunking (VLT)." -msgstr "新しいロール os10_vlt - 仮想リンクトランク (VLT) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:722 -msgid "New role os10_vrf Facilitates the configuration of virtual routing and forwarding (VRF)." -msgstr "新しいロール os10_vrf - VRF (Virtual Routing and Forwarding) の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:723 -msgid "New role os10_vrrp Facilitates the configuration of virtual router redundancy protocol (VRRP) attributes." -msgstr "新しいロール os10_vrrp - 仮想ルーター冗長性プロトコル (VRRP) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:724 -msgid "New role os10_vxlan Facilitates the configuration of virtual extensible LAN (VXLAN) attributes." -msgstr "新しいロール os10_vxlan - 仮想拡張可能 LAN (VXLAN) 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:725 -msgid "New role os10_xstp Facilitates the configuration of xSTP attributes." -msgstr "新しいロール os10_xstp - xSTP 属性の設定を容易にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:730 -msgid "Broke apart bigip_device_auth_radius to implement radius server configuration in bigip_device_auth_server module. Refer to module documentation for usage details" -msgstr "bigip_device_auth_radius を分割し、radius サーバの設定を bigip_device_auth_server モジュールに実装しました。使用方法の詳細はモジュールのドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:731 -msgid "Remove redundant parameters in f5_provider to fix disparity between documentation and module parameters" -msgstr "f5_provider で冗長なパラメーターを削除して、ドキュメントとモジュールパラメーターの不一致を修正します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:734 -#: ../../rst/porting_guides/porting_guide_4.rst:263 -#: ../../rst/porting_guides/porting_guide_5.rst:763 -msgid "gluster.gluster" -msgstr "gluster.gluster" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:736 -msgid "geo_rep - Added the independent module of geo rep with other gluster modules (https://github.com/gluster/gluster-ansible-collection/pull/2)." -msgstr "geo_rep - 他の gluster モジュールと、geo rep の独立したモジュールが追加されました (https://github.com/gluster/gluster-ansible-collection/pull/2)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:741 -msgid "ovirt_disk - Add backup (https://github.com/oVirt/ovirt-ansible-collection/pull/57)." -msgstr "ovirt_disk - バックアップ追加します (https://github.com/oVirt/ovirt-ansible-collection/pull/57)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:742 -msgid "ovirt_disk - Support direct upload/download (https://github.com/oVirt/ovirt-ansible-collection/pull/35)." -msgstr "ovirt_disk - 直接アップロード/ダウンロードをサポートします (https://github.com/oVirt/ovirt-ansible-collection/pull/35)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:743 -msgid "ovirt_host - Add ssh_port (https://github.com/oVirt/ovirt-ansible-collection/pull/60)." -msgstr "ovirt_host - ssh_port を追加します (https://github.com/oVirt/ovirt-ansible-collection/pull/60)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:744 -msgid "ovirt_vm_os_info - Creation of module (https://github.com/oVirt/ovirt-ansible-collection/pull/26)." -msgstr "ovirt_vm_os_info - モジュールを作成します (https://github.com/oVirt/ovirt-ansible-collection/pull/26)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:747 -#: ../../rst/porting_guides/porting_guide_5.rst:335 -#: ../../rst/porting_guides/porting_guide_5.rst:351 -#: ../../rst/porting_guides/porting_guide_6.rst:426 -#: ../../rst/porting_guides/porting_guide_6.rst:962 -msgid "purestorage.flasharray" -msgstr "purestorage.flasharray" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:749 -msgid "purefa_console - manage Console Lock setting for the FlashArray" -msgstr "purefa_console - FlashArray のコンソールロック設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:750 -msgid "purefa_endpoint - manage VMware protocol-endpoints on the FlashArray" -msgstr "purefa_endpoint - FlashArray で VMware プロトコルエンドポイントを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:751 -msgid "purefa_eula - sign, or resign, FlashArray EULA" -msgstr "purefa_eula - sign または resign、FlashArray EULA" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:752 -msgid "purefa_inventory - get hardware inventory information from a FlashArray" -msgstr "purefa_inventory - FlashArray からハードウェアインベントリー情報を取得します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:753 -msgid "purefa_network - manage the physical and virtual network settings on the FlashArray" -msgstr "purefa_network - FlashArray で物理および仮想ネットワークの設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:754 -msgid "purefa_pgsched - manage protection group snapshot and replication schedules on the FlashArray" -msgstr "purefa_pgsched - FlashArray で保護グループのスナップショットおよびレプリケーションスケジュールを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:755 -msgid "purefa_pod - manage ActiveCluster pods in FlashArrays" -msgstr "purefa_pod - FlashArray で ActiveCluster Pod を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:756 -msgid "purefa_pod_replica - manage ActiveDR pod replica links in FlashArrays" -msgstr "purefa_pod_replica - FlashArray で ActiveDR Pod レプリカリンクを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:757 -msgid "purefa_proxy - manage the phonehome HTTPS proxy setting for the FlashArray" -msgstr "purefa_proxy - FlashArray の phonehome HTTPS プロキシー設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:758 -msgid "purefa_smis - manage SMI-S settings on the FlashArray" -msgstr "purefa_smis - FlashArray で SMI-S 設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:759 -msgid "purefa_subnet - manage network subnets on the FlashArray" -msgstr "purefa_subnet - FlashArray でネットワークサブネットを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:760 -msgid "purefa_timeout - manage the GUI idle timeout on the FlashArray" -msgstr "purefa_timeout - FlashArray で GUI のアイドルタイムアウトを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:761 -msgid "purefa_vlan - manage VLAN interfaces on the FlashArray" -msgstr "purefa_vlan - FlashArray で VLAN インターフェースを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:762 -msgid "purefa_vnc - manage VNC for installed applications on the FlashArray" -msgstr "purefa_vnc - FlashArray にインストールされたアプリケーションの VNC を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:763 -msgid "purefa_volume_tags - manage volume tags on the FlashArray" -msgstr "purefa_volume_tags - FlashArray でボリュームタグを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:766 -#: ../../rst/porting_guides/porting_guide_4.rst:172 -#: ../../rst/porting_guides/porting_guide_5.rst:455 -msgid "purestorage.flashblade" -msgstr "purestorage.flashblade" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:768 -msgid "purefb_alert - manage alert email settings on a FlashBlade" -msgstr "purefb_alert - FlashBlade でアラートのメール設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:769 -msgid "purefb_bladename - manage FlashBlade name" -msgstr "purefb_bladename - FlashBlade 名を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:770 -msgid "purefb_bucket_replica - manage bucket replica links on a FlashBlade" -msgstr "purefb_bucket_replica - FlashBlade でバケットレプリカリンクを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:771 -msgid "purefb_connect - manage connections between FlashBlades" -msgstr "purefb_connect - FlashBlades 間の接続を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:772 -msgid "purefb_dns - manage DNS settings on a FlashBlade" -msgstr "purefb_dns - FlashBlade で DNS 設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:773 -msgid "purefb_fs_replica - manage filesystem replica links on a FlashBlade" -msgstr "purefb_fs_replica - FlashBlade でファイルシステムレプリカリンクを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:774 -msgid "purefb_inventory - get information about the hardware inventory of a FlashBlade" -msgstr "purefb_inventory - FlashBlade のハードウェアインベントリーに関する情報を取得します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:775 -msgid "purefb_ntp - manage the NTP settings for a FlashBlade" -msgstr "purefb_ntp - FlashBlade の NTP 設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:776 -msgid "purefb_phonehome - manage the phone home settings for a FlashBlade" -msgstr "purefb_phonehome - FlashBlade の電話ホームディレクトリー設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:777 -msgid "purefb_policy - manage the filesystem snapshot policies for a FlashBlade" -msgstr "purefb_policy - FlashBlade のファイルシステムスナップショットポリシーを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:778 -msgid "purefb_proxy - manage the phone home HTTP proxy settings for a FlashBlade" -msgstr "purefb_proxy - FlashBlade の電話ホーム HTTP プロキシー設定を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:779 -msgid "purefb_remote_cred - manage the Object Store Remote Credentials on a FlashBlade" -msgstr "purefb_remote_cred - FlashBlade でオブジェクトストアのリモート認証情報を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:780 -msgid "purefb_snmp_agent - modify the FlashBlade SNMP Agent" -msgstr "purefb_snmp_agent - FlashBlade SNMP エージェントを変更します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:781 -msgid "purefb_snmp_mgr - manage SNMP Managers on a FlashBlade" -msgstr "purefb_snmp_mgr - FlashBlade で SNMP Manager を管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:782 -msgid "purefb_target - manage remote S3-capable targets for a FlashBlade" -msgstr "purefb_target - FlashBlade のリモート S3 対応ターゲットを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:783 -msgid "purefb_user - manage local ``pureuser`` account password on a FlashBlade" -msgstr "purefb_user - FlashBlade でローカルの ``pureuser`` アカウントのパスワードを管理します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:791 -msgid "core - remove support for ``check_invalid_arguments`` in ``AnsibleModule``, ``AzureModule`` and ``UTMModule``." -msgstr "core - ``AnsibleModule``、``AzureModule``、および ``UTMModule`` の ``check_invalid_arguments`` のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:796 -msgid "module_utils.network.common.utils.ComplexDict has been removed" -msgstr "module_utils.network.common.utils.ComplexDict が削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:801 -msgid "win_stat - removed the deprecated ``get_md55`` option and ``md5`` return value." -msgstr "win_stat - 非推奨の ``get_md55`` オプションと ``md5`` の戻り値を削除します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:804 -#: ../../rst/porting_guides/porting_guide_2.10.rst:919 -#: ../../rst/porting_guides/porting_guide_3.rst:114 -#: ../../rst/porting_guides/porting_guide_3.rst:169 -#: ../../rst/porting_guides/porting_guide_4.rst:862 -#: ../../rst/porting_guides/porting_guide_5.rst:515 -#: ../../rst/porting_guides/porting_guide_5.rst:815 -#: ../../rst/porting_guides/porting_guide_5.rst:952 -#: ../../rst/porting_guides/porting_guide_6.rst:364 -#: ../../rst/porting_guides/porting_guide_7.rst:1021 -msgid "community.crypto" -msgstr "community.crypto" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:806 -msgid "The ``letsencrypt`` module has been removed. Use ``acme_certificate`` instead." -msgstr "``letsencrypt`` モジュールが削除されました。代わりに ``acme_certificate`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:811 -#: ../../rst/porting_guides/porting_guide_3.rst:538 -msgid "conjur_variable lookup - has been moved to the ``cyberark.conjur`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/570)." -msgstr "conjur_variable ルックアップ - ``cyberark.conjur`` コレクションに移動しました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/570)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:812 -msgid "core - remove support for ``check_invalid_arguments`` in ``UTMModule``." -msgstr "core - ``UTMModule`` の ``check_invalid_arguments`` のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:813 -#: ../../rst/porting_guides/porting_guide_3.rst:539 -msgid "digital_ocean_* - all DigitalOcean modules have been moved to the ``community.digitalocean`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/622)." -msgstr "digital_ocean_* - すべての DigitalOcean モジュールが ``community.digitalocean`` コレクションに移動しました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/622)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:814 -#: ../../rst/porting_guides/porting_guide_3.rst:540 -msgid "infini_* - all infinidat modules have been moved to the ``infinidat.infinibox`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/607)." -msgstr "infini_* - すべての infinidat モジュールが ``infinidat.infinibox`` コレクションに移動されました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/607)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:815 -#: ../../rst/porting_guides/porting_guide_3.rst:542 -msgid "logicmonitor - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541)." -msgstr "logicmonitor - このモジュールは、メンテナンス対象外で、モジュールが使用する API が 2017 年に削除されたため、1.0.0 で削除されました (https://github.com/ansible-collections/community.general/issues/539、https://github.com/ansible-collections/community.general/pull/541)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:816 -#: ../../rst/porting_guides/porting_guide_3.rst:543 -msgid "logicmonitor_facts - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541)." -msgstr "logicmonitor_facts - このモジュールは、メンテナンス対象外で、モジュールが使用する API が 2017 年に削除されたため、1.0.0 で削除されました (https://github.com/ansible-collections/community.general/issues/539、https://github.com/ansible-collections/community.general/pull/541)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:817 -#: ../../rst/porting_guides/porting_guide_3.rst:545 -msgid "mysql_* - all MySQL modules have been moved to the ``community.mysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/633)." -msgstr "mysql_* - すべての MySQL モジュールが ``community.mysql`` コレクションに移動しました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/633)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:818 -msgid "pacman - Removed deprecated ``recurse`` option, use ``extra_args=--recursive`` instead" -msgstr "pacman - 非推奨の ``recurse`` オプションを削除しました。代わりに ``extra_args=--recursive`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:819 -#: ../../rst/porting_guides/porting_guide_3.rst:546 -msgid "proxysql_* - all ProxySQL modules have been moved to the ``community.proxysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/624)." -msgstr "proxysql_* - すべての ProxySQL モジュールが ``community.proxysql`` コレクションに移動されました。リダイレクトはアクティブで、バージョン 2.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/624)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:824 -#: ../../rst/porting_guides/porting_guide_3.rst:579 -msgid "onyx - all onyx modules and plugins have been moved to the mellanox.onyx collection. Redirects have been added that will be removed in community.network 2.0.0 (https://github.com/ansible-collections/community.network/pull/83)." -msgstr "onyx - すべての onyx モジュールとプラグインは、mellanox.onyx コレクションに移動しました。community.network 2.0.0 で削除される予定のリダイレクトが追加されました (https://github.com/ansible-collections/community.network/pull/83)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:829 -msgid "vmware_guest_find - Removed deprecated ``datacenter`` option" -msgstr "vmware_guest_find - 非推奨の ``datacenter`` オプションを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:830 -msgid "vmware_portgroup - removed 'inbound_policy', and 'rolling_order' deprecated options." -msgstr "vmware_portgroup - 「inbound_policy」および「rolling_order」の非推奨オプションを削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:831 -msgid "vmware_vmkernel - Removed deprecated ``ip_address`` option; use sub-option ip_address in the network option instead" -msgstr "vms_vmkernel - 非推奨の ``ip_address`` オプション。代わりに network オプションにサブオプション ip_address を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:832 -msgid "vmware_vmkernel - Removed deprecated ``subnet_mask`` option; use sub-option subnet_mask in the network option instead" -msgstr "vmware_vmkernel - 非推奨の ``subnet_mask`` オプションを削除しました。代わりに network オプションにサブオプション subnet_mask を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:837 -msgid "win_disk_image - removed the deprecated return value ``mount_path`` in favor of ``mount_paths``." -msgstr "win_disk_image - 非推奨の戻り値 ``mount_path`` が削除され、``mount_paths`` が変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:838 -msgid "win_psexec - removed the deprecated ``extra_opts`` option." -msgstr "win_psexec - 非推奨の ``extra_opts`` オプションが削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:843 -msgid "Remove _bigip_iapplx_package alias" -msgstr "_bigip_iapplx_package エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:844 -msgid "Remove _bigip_security_address_list alias" -msgstr "_bigip_security_address_list エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:845 -msgid "Remove _bigip_security_port_list alias" -msgstr "_bigip_security_port_list エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:846 -msgid "Remove _bigip_traffic_group alias" -msgstr "_bigip_traffic_group エイリアスの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:847 -msgid "Remove bigip_appsvcs_extension module" -msgstr "bigip_appsvcs_extension モジュールの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:848 -msgid "Remove bigip_asm_policy module" -msgstr "bigip_asm_policy モジュールの削除" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:853 -msgid "The vyos.vyos.vyos_static_route module has been deprecated and will be removed in a later release; use vyos.vyos.vyos_static_routes instead." -msgstr "vyos.vyos.vyos_static_route モジュールは非推奨となり、今後のリリースで削除される予定です。代わりに、vyos.vyos.vyos_static_routes を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:858 -msgid "Using the DefaultCallback without the correspodning doc_fragment or copying the documentation." -msgstr "対応する doc_fragment を使用せずに DefaultCallback を使用、またはドキュメントのコピー" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:859 -msgid "hash_behaviour - Deprecate ``hash_behaviour`` for future removal." -msgstr "hash_behaviour - 今後削除される ``hash_behaviour`` を非推奨にします。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:860 -msgid "script inventory plugin - The 'cache' option is deprecated and will be removed in 2.12. Its use has been removed from the plugin since it has never had any effect." -msgstr "スクリプトインベントリープラグイン - 「cache」オプションは非推奨になり、2.12 で削除されます。何も効果がないため、その使用はプラグインから削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:865 -msgid "All AWS Modules - ``aws_access_key``, ``aws_secret_key`` and ``security_token`` will be made mutually exclusive with ``profile`` after 2022-06-01." -msgstr "すべての AWS モジュール - ``aws_access_key``、``aws_secret_key``、および ``security_token`` は 2022-06-01 以降に ``profile`` と相互に排他的になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:866 -#: ../../rst/porting_guides/porting_guide_2.10.rst:894 -msgid "cloudformation - The ``template_format`` option had no effect since Ansible 2.3 and will be removed after 2022-06-01" -msgstr "cloudformation - ``template_format`` オプションは Ansible 2.3 以降には影響しませんが、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:867 -msgid "cloudformation - the ``template_format`` option has been deprecated and will be removed in a later release. It has been ignored by the module since Ansible 2.3." -msgstr "cloudformation - ``template_format`` オプションは非推奨となり、今後のリリースで削除されます。これは Ansible 2.3 以降モジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:868 -msgid "data_pipeline - The ``version`` option had no effect and will be removed in after 2022-06-01" -msgstr "data_pipeline - ``version`` オプションは影響を受けず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:869 -msgid "ec2 - in a later release, the ``group`` and ``group_id`` options will become mutually exclusive. Currently ``group_id`` is ignored if you pass both." -msgstr "ec2 - 今後のリリースでは、``group`` オプションと ``group_id`` オプションが相互に排他的になります。現時点では、両方を渡すと ``group_id`` は無視されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:870 -msgid "ec2_ami - The ``no_device`` alias ``NoDevice`` has been deprecated and will be removed after 2022-06-01" -msgstr "ec2_ami - ``no_device`` エイリアス ``NoDevice`` は非推奨となり、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:871 -msgid "ec2_ami - The ``virtual_name`` alias ``VirtualName`` has been deprecated and will be removed after 2022-06-01" -msgstr "ec2_ami - ``virtual_name`` エイリアス ``VirtualName`` は非推奨となり、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:872 -#: ../../rst/porting_guides/porting_guide_2.10.rst:897 -msgid "ec2_eip - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_eip - ``wait_timeout`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:873 -#: ../../rst/porting_guides/porting_guide_2.10.rst:899 -msgid "ec2_key - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_key - ``wait_timeout`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:874 -#: ../../rst/porting_guides/porting_guide_2.10.rst:900 -msgid "ec2_key - The ``wait`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_key - ``wait`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:875 -msgid "ec2_key - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5." -msgstr "ec2_key - ``wait_timeout`` オプションは非推奨となり、今後のリリースで削除される予定です。Ansible 2.5 以降には変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:876 -msgid "ec2_key - the ``wait`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5." -msgstr "ec2_key - ``wait`` オプションは非推奨となり、今後のリリースで削除される予定です。Ansible 2.5 以降には変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:877 -#: ../../rst/porting_guides/porting_guide_2.10.rst:901 -msgid "ec2_lc - The ``associate_public_ip_address`` option had no effect and will be removed after 2022-06-01" -msgstr "ec2_lc - ``associate_public_ip_address`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:878 -msgid "ec2_tag - deprecate the ``list`` option in favor of ec2_tag_info" -msgstr "ec2_tag - ``list`` オプションが非推奨になり、ec2_tag_info が採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:879 -msgid "ec2_tag - support for ``list`` as a state has been deprecated and will be removed in a later release. The ``ec2_tag_info`` can be used to fetch the tags on an EC2 resource." -msgstr "ec2_tag - 状態としての ``list`` のサポートは非推奨となり、今後のリリースで削除されます。``ec2_tag_info`` を使用すると、EC2 リソースでタグを取得できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:884 -msgid "win_domain_computer - Deprecated the undocumented ``log_path`` option. This option will be removed in a major release after ``2022-07-01``." -msgstr "win_domain_ computers - ドキュメント化されていない ``log_path`` オプションが非推奨になりました。このオプションは ``2022-07-01`` 後のメジャーリリースで削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:885 -msgid "win_domain_controller - the ``log_path`` option has been deprecated and will be removed in a later release. This was undocumented and only related to debugging information for module development." -msgstr "win_domain_controller - ``log_path`` オプションは非推奨となり、今後のリリースで削除されます。これは文書化されておらず、モジュール開発のデバッグ情報にのみ関連しています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:886 -msgid "win_package - the ``ensure`` alias for the ``state`` option has been deprecated and will be removed in a later release. Please use ``state`` instead of ``ensure``." -msgstr "win_package - ``state`` オプションの ``ensure`` エイリアスは非推奨となり、今後のリリースで削除されます。``ensure`` の代わりに ``state`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:887 -msgid "win_package - the ``productid`` alias for the ``product_id`` option has been deprecated and will be removed in a later release. Please use ``product_id`` instead of ``productid``." -msgstr "win_package - ``product_id`` オプションの ``productid`` エイリアスは非推奨となり、今後のリリースで削除されます。``productid`` の代わりに ``product_id`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:888 -msgid "win_package - the ``username`` and ``password`` options has been deprecated and will be removed in a later release. The same functionality can be done by using ``become: yes`` and ``become_flags: logon_type=new_credentials logon_flags=netcredentials_only`` on the task." -msgstr "win_package - ``username`` オプションおよび ``password`` オプションは非推奨となり、今後のリリースで削除されます。同様に、タスクの ``become: yes`` および ``become_flags: logon_type=new_credentials logon_flags=netcredentials_only`` を使用して実行できます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:889 -msgid "win_regedit - Deprecated using forward slashes as a path separator, use backslashes to avoid ambiguity between a forward slash in the key name or a forward slash as a path separator. This feature will be removed in a major release after ``2021-07-01``." -msgstr "win_regedit - スラッシュをパス区切り文字として使用し、バックスラッシュを使用して、キー名のスラッシュとパス区切りのスラッシュの曖昧さを回避します。この機能は、``2021-07-01`` の後のメジャーリリースで削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:895 -msgid "data_pipeline - The ``version`` option had no effect and will be removed after 2022-06-01" -msgstr "data_pipeline - ``version`` オプションは影響を受けておらず、2022-06-01 以降削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:896 -msgid "data_pipeline - the ``version`` option has been deprecated and will be removed in a later release. It has always been ignored by the module." -msgstr "data_pipeline - ``version`` オプションは非推奨となり、今後のリリースで削除されます。常にモジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:898 -msgid "ec2_eip - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.3." -msgstr "ec2_eip - ``wait_timeout`` オプションは非推奨となり、今後のリリースで削除される予定です。Ansible 2.3 以降は変更されません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:902 -msgid "ec2_lc - the ``associate_public_ip_address`` option has been deprecated and will be removed after a later release. It has always been ignored by the module." -msgstr "ec2_lc - ``associate_public_ip_address`` オプションは非推奨となり、今後のリリースで削除されます。常にモジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:903 -msgid "elb_network_lb - The current default value of the ``state`` option has been deprecated and will change from absent to present after 2022-06-01" -msgstr "elb_network_lb - ``state`` オプションの現在のデフォルト値は非推奨となり、2022-06-01 以降に absent から present に変更する予定です。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:904 -msgid "elb_network_lb - in a later release, the default behaviour for the ``state`` option will change from ``absent`` to ``present``. To maintain the existing behavior explicitly set state to ``absent``." -msgstr "elb_network_lb - 今後のリリースでは、``state`` オプションのデフォルト動作が ``absent`` から ``present`` に変更なります。既存の動作を維持するには、状態を明示的に ``absent`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:905 -msgid "iam_managed_policy - The ``fail_on_delete`` option had no effect and will be removed after 2022-06-01" -msgstr "iam_managed_policy - ``fail_on_delete`` オプションは影響を受けず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:906 -msgid "iam_managed_policy - the ``fail_on_delete`` option has been deprecated and will be removed after a later release. It has always been ignored by the module." -msgstr "iam_managed_policy - ``fail_on_delete`` オプションは非推奨となり、今後のリリースで削除されます。常にモジュールによって無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:907 -msgid "iam_policy - The ``policy_document`` will be removed after 2022-06-01. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin." -msgstr "iam_policy - ``policy_document`` は 2022-06-01 以降削除されます。既存の動作を維持するには、``policy_json`` オプションを使用して ``lookup`` プラグインでファイルを読み取ります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:908 -msgid "iam_policy - The default value of ``skip_duplicates`` will change after 2022-06-01 from ``true`` to ``false``." -msgstr "iam_policy -``skip_duplicates`` のデフォルト値は、2022-06-01 以降、``true`` から``false`` に変更になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:909 -msgid "iam_policy - in a later release, the default value for the ``skip_duplicates`` option will change from ``true`` to ``false``. To maintain the existing behavior explicitly set it to ``true``." -msgstr "iam_policy - 今後のリリースでは、``skip_duplicates`` オプションのデフォルト値が ``true`` から``false`` に変更になります。既存の動作を維持するには、明示的に ``true`` に設定してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:910 -msgid "iam_policy - the ``policy_document`` option has been deprecated and will be removed after a later release. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin." -msgstr "iam_policy - ``policy_document`` オプションは非推奨となり、後のリリースで削除される予定です。既存の動作を維持するには、``policy_json`` オプションを使用し、``lookup`` プラグインでファイルを読み込んでください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:911 -msgid "iam_role - The default value of the purge_policies has been deprecated and will change from true to false after 2022-06-01" -msgstr "iam_role - purge_policies のデフォルト値は非推奨となり、2022-06-01 以降は true から false に変更になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:912 -msgid "iam_role - in a later release, the ``purge_policies`` option (also know as ``purge_policy``) default value will change from ``true`` to ``false``" -msgstr "iam_role - 今後のリリースでは、``purge_policies`` オプション (``purge_policy`` とも呼ばれる) のデフォルト値が ``true`` から ``false`` に変更になります。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:913 -msgid "s3_lifecycle - The ``requester_pays`` option had no effect and will be removed after 2022-06-01" -msgstr "s3_lifecycle - ``requester_pays`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:914 -msgid "s3_lifecycle - the ``requester_pays`` option has been deprecated and will be removed after a later release. It has always been ignored by the module." -msgstr "s3_lifecycle - ``requester_pays`` オプションは非推奨となり、今後のリリースで削除される予定です。モジュールでは常に無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:915 -msgid "s3_sync - The ``retries`` option had no effect and will be removed after 2022-06-01" -msgstr "s3_sync - ``retries`` オプションは影響を受けておらず、2022-06-01 以降に削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:916 -msgid "s3_sync - the ``retries`` option has been deprecated and will be removed after 2022-06-01. It has always been ignored by the module." -msgstr "s3_sync - ``retries`` オプションは非推奨となり、2022-06-01 以降は削除されます。モジュールでは常に無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:921 -msgid "openssl_csr - all values for the ``version`` option except ``1`` are deprecated. The value 1 denotes the current only standardized CSR version." -msgstr "openssl_csr - ``version`` オプションの ``1`` 以外の値は非推奨です。値 1 は、現在唯一標準化されている CSR バージョンを示します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:926 -#: ../../rst/porting_guides/porting_guide_3.rst:611 -msgid "The ldap_attr module has been deprecated and will be removed in a later release; use ldap_attrs instead." -msgstr "ldap_attr モジュールは非推奨となり、今後のリリースで削除されます。代わりに ldap_attrs を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:927 -msgid "airbrake_deployment - Add deprecation notice for ``token`` parameter and v2 api deploys. This feature will be removed in community.general 3.0.0." -msgstr "airbrake_deployment - ``token`` パラメーターと v2 api のデプロイに関する非推奨の告知を追加します。この機能は community.general 3.0.0 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:928 -msgid "clc_aa_policy - The ``wait`` option had no effect and will be removed in community.general 3.0.0." -msgstr "clc_aa_policy - ``wait`` オプションは影響を受けず、community.general 3.0.0 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:929 -msgid "clc_aa_policy - the ``wait`` parameter will be removed. It has always been ignored by the module." -msgstr "clc_aa_policy - ``wait`` パラメーターは削除されます。常にモジュールにより無視されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:930 -msgid "docker_container - the ``trust_image_content`` option is now deprecated and will be removed in community.general 3.0.0. It has never been used by the module." -msgstr "docker_container - ``trust_image_content`` オプションは非推奨となり、community.general 3.0.0 で削除されます。モジュールで使用されることはありません。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:931 -msgid "docker_container - the ``trust_image_content`` option will be removed. It has always been ignored by the module." -msgstr "docker_container - ``trust_image_content`` オプションは削除されます。これまでもモジュールはこのオプションを無視していました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:932 -msgid "docker_container - the default of ``container_default_behavior`` will change from ``compatibility`` to ``no_defaults`` in community.general 3.0.0. Set the option to an explicit value to avoid a deprecation warning." -msgstr "docker_container - ``container_default_behavior`` のデフォルト値が community.general 3.0.0 で ``compatibility`` から ``no_defaults`` に変更になります。非推奨の警告を防ぐために、オプションを明示的に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:933 -msgid "docker_container - the default value for ``network_mode`` will change in community.general 3.0.0, provided at least one network is specified and ``networks_cli_compatible`` is ``true``. See porting guide, module documentation or deprecation warning for more details." -msgstr "docker_container - community.general 3.0.0 では、少なくとも 1 つのネットワークが指定され、``networks_cli_compatible`` が ``true`` である場合は、``network_mode`` のデフォルト値が変更します。詳細は移植ガイド、モジュールのドキュメント、または非推奨の警告を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:934 -msgid "docker_stack - Return values ``out`` and ``err`` have been deprecated and will be removed in community.general 3.0.0. Use ``stdout`` and ``stderr`` instead." -msgstr "docker_stack - 戻り値の ``out`` と``err`` は非推奨であり、community.general 3.0.0 で削除されます。代わりに ``stdout`` と``stderr`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:935 -msgid "docker_stack - the return values ``err`` and ``out`` have been deprecated. Use ``stdout`` and ``stderr`` from now on instead." -msgstr "docker_stack - ``err`` と``out`` の戻り値は非推奨となりました。今後は ``stdout`` と ``stderr`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:936 -msgid "helm - Put ``helm`` module to deprecated. New implementation is available in community.kubernetes collection." -msgstr "helm - ``helm`` モジュールを非推奨にしました。新しい実装は community.kubernetes コレクションで公開されています。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:937 -msgid "redfish_config - Deprecate ``bios_attribute_name`` and ``bios_attribute_value`` in favor of new `bios_attributes`` option." -msgstr "redfish_config - ``bios_attribute_name`` と ``bios_attribute_value`` を非推奨とし、新しい `bios_attributes`` オプションを採用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:938 -msgid "redfish_config - the ``bios_attribute_name`` and ``bios_attribute_value`` options will be removed. To maintain the existing behavior use the ``bios_attributes`` option instead." -msgstr "redfish_config - ``bios_attribute_name`` オプションおよび ``bios_attribute_value`` オプションを削除します。既存の動作を維持するには、代わりに ``bios_attributes`` オプションを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:939 -msgid "redfish_config and redfish_command - the behavior to select the first System, Manager, or Chassis resource to modify when multiple are present will be removed. Use the new ``resource_id`` option to specify target resource to modify." -msgstr "redfish_config および redfish_command - 複数のリソースが存在する場合に修正する最初の System リソース、Manager リソース、または Chassis リソースを選択する動作が削除されます。新しい ``resource_id`` オプションを使用して、変更する対象のリソースを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:940 -msgid "redfish_config, redfish_command - Behavior to modify the first System, Manager, or Chassis resource when multiple are present is deprecated. Use the new ``resource_id`` option to specify target resource to modify." -msgstr "redfish_config、redfish_command - 複数のリソースが存在する場合、最初の System、Mananger、または Chassis リソースを修正する動作は非推奨です。新しい ``resource_id`` オプションを使用して、変更する対象のリソースを指定してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:941 -#: ../../rst/porting_guides/porting_guide_3.rst:616 -msgid "xbps - the ``force`` option never had any effect. It is now deprecated, and will be removed in 3.0.0 (https://github.com/ansible-collections/community.general/pull/568)." -msgstr "xbps - ``force`` オプションには何も効果がありません。現在非推奨になり、3.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/568)。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:946 -msgid "The vmware_dns_config module has been deprecated and will be removed in a later release; use vmware_host_dns instead." -msgstr "vmware_dns_config モジュールは非推奨となり、今後のリリースで削除される予定です。代わりに vmware_host_dns を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:947 -msgid "vca - vca_fw, vca_nat, vca_app are deprecated since these modules rely on deprecated part of Pyvcloud library." -msgstr "vca - vca_fw モジュール、vca_nat モジュール、vca_app モジュールは、Pyvcloud ライブラリーの非推奨の部分に依存しているため非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:948 -msgid "vmware_dns_config - Deprecate in favor of new module vmware_host_dns." -msgstr "vmc_dns_config - 非推奨になり、新しいモジュール vmware_host_dns が採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:949 -msgid "vmware_guest - deprecate specifying CDROM configuration as a dict, instead use a list." -msgstr "vmware_guest - CDROM 設定を dict として指定することを非推奨とし、代わりにリストを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:950 -msgid "vmware_tag_info - in a later release, the module will not return ``tag_facts`` since it does not return multiple tags with the same name and different category id. To maintain the existing behavior use ``tag_info`` which is a list of tag metadata." -msgstr "vmware_tag_info - 今後のリリースでは、同じ名前で異なるカテゴリー ID を持つ複数のタグを返さないため、モジュールは ``tag_facts`` を返しません。既存の動作を維持するには、タグのメタデータのリストである ``tag_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:955 -msgid "zabbix_proxy (module) - deprecates ``interface`` sub-options ``type`` and ``main`` when proxy type is set to passive through ``status=passive``. Make sure these suboptions are removed from your playbook as they were never supported by Zabbix in the first place." -msgstr "zabbix_proxy (モジュール) - ``status=passive`` でプロキシーが passive に設定されている場合は、``interface`` のサブオプション ``type`` と ``main`` を非推奨とします。これらのサブオプションはそもそも Zabbix ではサポートされていないため、必ず Playbook から削除してください。" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:960 -msgid "Deprecated bigip_appsvcs_extension module" -msgstr "非推奨の bigip_appsvcs_extension モジュール" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:961 -msgid "Deprecated bigip_device_facts module name" -msgstr "非推奨の bigip_device_facts モジュール名" - -#: ../../rst/porting_guides/porting_guide_2.10.rst:962 -msgid "Deprecated bigiq_device_facts module name" -msgstr "非推奨の bigiq_device_facts モジュール名" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:6 -msgid "Ansible 2.3 Porting Guide" -msgstr "Ansible 2.3 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:8 -msgid "This section discusses the behavioral changes between Ansible 2.2 and Ansible 2.3." -msgstr "このセクションでは、Ansible 2.2 から Ansible 2.3 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:13 -msgid "We suggest you read this page along with `Ansible Changelog for 2.3 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.3 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:23 -msgid "Restructured async to work with action plugins" -msgstr "アクションプラグインと連携するように async を再構築しました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:25 -msgid "In Ansible 2.2 (and possibly earlier) the `async:` keyword could not be used in conjunction with the action plugins such as `service`. This limitation has been removed in Ansible 2.3" -msgstr "Ansible 2.2 (およびそれ以前) では、`async:` キーワードを `service` などのアクションプラグインと併用できませんでした。この制限は Ansible 2.3 で削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:27 -#: ../../rst/porting_guides/porting_guide_2.3.rst:53 -#: ../../rst/porting_guides/porting_guide_2.3.rst:69 -#: ../../rst/porting_guides/porting_guide_2.3.rst:208 -msgid "**NEW** In Ansible 2.3:" -msgstr "Ansible 2.3 における **新機能**:" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:40 -msgid "OpenBSD version facts" -msgstr "OpenBSD バージョンファクト" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:42 -msgid "The `ansible_distribution_release` and `ansible_distribution_version` facts on OpenBSD hosts were reversed in Ansible 2.2 and earlier. This has been changed so that version has the numeric portion and release has the name of the release." -msgstr "OpenBSD ホストの `ansible_distribution_release` と`ansible_distribution_version` のファクトは、Ansible 2.2 以前では逆になっていました。これは、バージョンに数字の部分があり、リリースにはリリースの名前があるように変更されています。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:44 -msgid "**OLD** In Ansible 2.2 (and earlier)" -msgstr "Ansible 2.2 以前における **以前の機能**:" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:64 -msgid "Names Blocks" -msgstr "Names ブロック" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:66 -msgid "Blocks can now have names, this allows you to avoid the ugly `# this block is for...` comments." -msgstr "ブロックに名前を付けられるようになりました。これにより、冗長な `# this block is for...` のコメントを回避できます。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:91 -#: ../../rst/porting_guides/porting_guide_2.4.rst:62 -msgid "Use of multiple tags" -msgstr "複数のタグの使用" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:93 -msgid "Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last specified tag overriding all the other specified tags. This behaviour is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behaviour." -msgstr "現在、コマンドラインで ``--tags`` (または ``--skip-tags``) を複数回指定すると、最後に指定したタグが他のすべての指定したタグよりも優先されます。この動作は推奨されません。将来的には、--tags を複数回指定した場合、タグは統合されます。今後は、1 つのコマンドラインで ``--tags`` を複数回使用すると、非推奨の警告が表示されます。``ansible.cfg`` ファイルで ``merge_multiple_cli_tags`` オプションを True に設定すると、新しい動作が有効になります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:95 -msgid "In 2.4, the default will be to merge the tags. You can enable the old overwriting behavior through the config option. In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behaviour." -msgstr "2.4 では、デフォルトでタグのマージが行われます。古い上書きの動作は、設定オプションで有効にすることができます。2.5 では、複数の ``--tags`` オプションがマージされますが、以前の動作に戻すことはできません。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:102 -msgid "Here are some rare cases that might be encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored." -msgstr "ここでは、更新時に遭遇するめったに発生しないケースを紹介します。これらは主に、パーサーの検証がより厳しくなったことと、以前は無視されていたエラーが捕捉されたことが原因です。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:105 -msgid "Made ``any_errors_fatal`` inheritable from play to task and all other objects in between." -msgstr "``any_errors_fatal`` をプレイからタスクおよび他のオブジェクトへ継承できるようにしました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:110 -#: ../../rst/porting_guides/porting_guide_2.3.rst:115 -#: ../../rst/porting_guides/porting_guide_2.3.rst:157 -#: ../../rst/porting_guides/porting_guide_2.3.rst:162 -#: ../../rst/porting_guides/porting_guide_2.4.rst:74 -msgid "No major changes in this version." -msgstr "このバージョンには大きな変更がありません。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:113 -#: ../../rst/porting_guides/porting_guide_2.4.rst:84 -#: ../../rst/porting_guides/porting_guide_2.5.rst:168 -#: ../../rst/porting_guides/porting_guide_2.6.rst:34 -#: ../../rst/porting_guides/porting_guide_2.7.rst:168 -#: ../../rst/porting_guides/porting_guide_2.8.rst:382 -#: ../../rst/porting_guides/porting_guide_2.9.rst:122 -#: ../../rst/porting_guides/porting_guide_4.rst:102 -#: ../../rst/porting_guides/porting_guide_5.rst:93 -#: ../../rst/porting_guides/porting_guide_6.rst:60 -#: ../../rst/porting_guides/porting_guide_7.rst:59 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:105 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:91 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:58 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:57 -msgid "Modules removed" -msgstr "削除されたモジュール" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:118 -#: ../../rst/porting_guides/porting_guide_2.4.rst:91 -#: ../../rst/porting_guides/porting_guide_2.5.rst:194 -#: ../../rst/porting_guides/porting_guide_2.6.rst:40 -#: ../../rst/porting_guides/porting_guide_2.6.rst:86 -#: ../../rst/porting_guides/porting_guide_2.7.rst:174 -#: ../../rst/porting_guides/porting_guide_2.8.rst:393 -#: ../../rst/porting_guides/porting_guide_2.9.rst:139 -#: ../../rst/porting_guides/porting_guide_4.rst:110 -#: ../../rst/porting_guides/porting_guide_5.rst:101 -#: ../../rst/porting_guides/porting_guide_6.rst:68 -#: ../../rst/porting_guides/porting_guide_7.rst:67 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:113 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:99 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:66 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:65 -msgid "Deprecation notices" -msgstr "非推奨のお知らせ" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:120 -msgid "The following modules will be removed in Ansible 2.5. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.5 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:122 -msgid "ec2_vpc" -msgstr "ec2_vpc" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:123 -msgid "cl_bond" -msgstr "cl_bond" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:124 -msgid "cl_bridge" -msgstr "cl_bridge" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:125 -msgid "cl_img_install" -msgstr "cl_img_install" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:126 -msgid "cl_interface" -msgstr "cl_interface" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:127 -msgid "cl_interface_policy" -msgstr "cl_interface_policy" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:128 -msgid "cl_license" -msgstr "cl_license" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:129 -msgid "cl_ports" -msgstr "cl_ports" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:130 -msgid "nxos_mtu use :ref:`nxos_system ` instead" -msgstr "nxos_mtu は、代わりに :ref:`nxos_system ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:134 -msgid "These modules may no longer have documentation in the current release. Please see the `Ansible 2.3 module documentation `_ if you need to know how they worked for porting your playbooks." -msgstr "これらのモジュールには現在のリリースのドキュメントが含まれていない可能性があります。Playbook の移植方法を把握する必要がある場合は、`Ansible 2.3 モジュールドキュメント `_ を確認してください。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:144 -msgid "AWS lambda" -msgstr "AWS ラムダ" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:145 -msgid "Previously ignored changes that only affected one parameter. Existing deployments may have outstanding changes that this bug fix will apply." -msgstr "以前は、1 つのパラメーターにのみ影響する変更を無視していました。既存のデプロイメントでは、このバグ修正が適用される未処理の変更がある可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:149 -msgid "Mount" -msgstr "マウント" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:151 -msgid "Mount: Some fixes so bind mounts are not mounted each time the playbook runs." -msgstr "マウント: Playbook の実行時にバインドマウントがマウントされないようにする修正もあります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:165 -#: ../../rst/porting_guides/porting_guide_2.4.rst:199 -#: ../../rst/porting_guides/porting_guide_2.6.rst:107 -#: ../../rst/porting_guides/porting_guide_2.7.rst:246 -#: ../../rst/porting_guides/porting_guide_2.8.rst:575 -#: ../../rst/porting_guides/porting_guide_2.9.rst:728 -#: ../../rst/porting_guides/porting_guide_5.rst:126 -#: ../../rst/porting_guides/porting_guide_6.rst:98 -#: ../../rst/porting_guides/porting_guide_7.rst:91 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:124 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:96 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:89 -msgid "Networking" -msgstr "ネットワーキング" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:167 -msgid "There have been a number of changes to number of changes to how Networking Modules operate." -msgstr "ネットワーキングモジュールの運用方法に、いくつかの変更がありました。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:169 -#: ../../rst/porting_guides/porting_guide_2.4.rst:203 -msgid "Playbooks should still use ``connection: local``." -msgstr "Playbook は引き続き ``connection: local`` を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:171 -msgid "The following changes apply to:" -msgstr "以下の変更が適用されます。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:173 -msgid "dellos6" -msgstr "dellos6" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:174 -msgid "dellos9" -msgstr "dellos9" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:175 -msgid "dellos10" -msgstr "dellos10" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:176 -msgid "eos" -msgstr "eos" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:177 -msgid "ios" -msgstr "ios" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:178 -msgid "iosxr" -msgstr "iosxr" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:179 -msgid "junos" -msgstr "junos" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:180 -msgid "sros" -msgstr "sros" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:181 -msgid "vyos" -msgstr "vyos" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:184 -msgid "Deprecation of top-level connection arguments" -msgstr "トップレベルの接続引数を非推奨にする" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:186 -msgid "**OLD** In Ansible 2.2:" -msgstr "Ansible 2.2 における **以前の機能**:" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:199 -msgid "Will result in:" -msgstr "結果は以下のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:223 -msgid "ProxyCommand replaces delegate_to" -msgstr "ProxyCommand は delegate_to を置き換えます。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:225 -msgid "The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport no longer supports the use of the ``delegate_to`` directive. In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` transport, network modules now support the use of ``ProxyCommand``." -msgstr "``cli`` トランスポートを使用する Ansible 2.3 のネットワークモジュールの新しい接続フレームワークは、``delegate_to`` ディレクティブの使用をサポートしなくなりました。bastion または中間ジャンプホストを使用して ``cli`` トランスポートでネットワークデバイスに接続するために、ネットワークモジュールは ``ProxyCommand`` の使用に対応します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:230 -msgid "To use ``ProxyCommand`` configure the proxy settings in the Ansible inventory file to specify the proxy host through ``ansible_ssh_common_args``." -msgstr "``ProxyCommand`` を使用するには、Ansible インベントリーファイルでプロキシー設定を構成して、``ansible_ssh_common_args`` を使用してプロキシーホストを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.3.rst:233 -msgid "For details on how to do this see the :ref:`network proxy guide `." -msgstr "これを行う方法は、「:ref:`ネットワークプロキシーガイド `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:6 -msgid "Ansible 2.4 Porting Guide" -msgstr "Ansible 2.4 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:8 -msgid "This section discusses the behavioral changes between Ansible 2.3 and Ansible 2.4." -msgstr "このセクションでは、Ansible 2.3 から Ansible 2.4 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:13 -msgid "We suggest you read this page along with `Ansible Changelog for 2.4 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.4 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:20 -msgid "Python version" -msgstr "Python バージョン" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:22 -msgid "Ansible will not support Python 2.4 or 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller." -msgstr "Ansible は、ターゲットホストで Python 2.4 または 2.5 に対応しなくなりました。今後は、コントローラーと同様、ターゲットでも Python 2.6 以降が必要となります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:26 -#: ../../rst/porting_guides/porting_guide_2.5.rst:242 -#: ../../rst/porting_guides/porting_guide_2.9.rst:23 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:28 -msgid "Inventory has been refactored to be implemented through plugins and now allows for multiple sources. This change is mostly transparent to users." -msgstr "インベントリーはプラグインで実装できるようにリファクタリングされ、複数のソースを使用できるようになりました。この変更はユーザーにはほとんどわかりません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:30 -msgid "One exception is the ``inventory_dir``, which is now a host variable; previously it could only have one value so it was set globally. This means you can no longer use it early in plays to determine ``hosts:`` or similar keywords. This also changes the behaviour of ``add_hosts`` and the implicit localhost; because they no longer automatically inherit the global value, they default to ``None``. See the module documentation for more information." -msgstr "1 つの例外は ``inventory_dir`` で、これはホスト変数になりました。以前は 1 つの値しか持てなかったため、グローバルに設定されていました。これは、``hosts:`` や同様のキーワードを決定するためにプレイの早い段階でそれを使用できなくなったことを意味します。これにより、``add_hosts`` および暗黙のローカルホストの動作も変更されます。グローバル値を自動的に継承しなくなったため、デフォルトで ``None`` となります。詳細は、モジュールのドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:35 -msgid "The ``inventory_file`` remains mostly unchanged, as it was always host specific." -msgstr "``inventory_file`` は常に特定のホスト固有の状態であったため、ほとんど変更されません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:37 -msgid "Since there is no longer a single inventory, the 'implicit localhost' doesn't get either of these variables defined." -msgstr "インベントリーが 1 つなくなるため、「暗黙的な localhost」は、これらの変数のいずれかが定義されていません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:39 -msgid "A bug was fixed with the inventory path/directory, which was defaulting to the current working directory. This caused ``group_vars`` and ``host_vars`` to be picked up from the current working directory instead of just adjacent to the playbook or inventory directory when a host list (comma separated host names) was provided as inventory." -msgstr "インベントリーのパス/ディレクトリーのデフォルトが現在のワーキングディレクトリーになっていたバグが修正されました。これにより、インベントリーとしてホストリスト (カンマで区切られたホスト名) が提供された場合に、``group_vars`` と``host_vars`` が Playbook やインベントリーのディレクトリーに隣接するのではなく、現在の作業ディレクトリーから選択されていました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:42 -msgid "Initial playbook relative group_vars and host_vars" -msgstr "初期 Playbook の相対的な group_vars および host_vars" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:44 -msgid "In Ansible versions prior to 2.4, the inventory system would maintain the context of the initial playbook that was executed. This allowed successively included playbooks from other directories to inherit group_vars and host_vars placed relative to the top level playbook file." -msgstr "Ansible 2.4 以前のバージョンでは、インベントリーシステムが、最初に実行した Playbook のコンテキストを維持していました。これにより、他のディレクトリーから連続してインクルードされた Playbook は、最上位レベルの Playbook ファイルに相対的に配置された group_vars や host_vars を継承することができました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:46 -msgid "Due to some behavioral inconsistencies, this functionality will not be included in the new inventory system starting with Ansible version 2.4." -msgstr "一部の動作上の不整合により、この機能は Ansible バージョン 2.4 以降の新規インベントリーシステムに含まれません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:49 -msgid "Similar functionality can still be achieved by using vars_files, include_vars, or group_vars and host_vars placed relative to the inventory file." -msgstr "同様の機能は、インベントリーファイルに相対的に配置された vars_files、include_vars、または group_vars と host_vars を使用しても実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:55 -msgid "Specifying Inventory sources" -msgstr "インベントリーソースの指定" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:57 -msgid "Use of ``--inventory-file`` on the command line is now deprecated. Use ``--inventory`` or ``-i``. The associated ini configuration key, ``hostfile``, and environment variable, ``ANSIBLE_HOSTS``, are also deprecated. Replace them with the configuration key ``inventory`` and environment variable :envvar:`ANSIBLE_INVENTORY`." -msgstr "コマンドラインでの ``--inventory-file`` の使用は推奨されていません。``--inventory`` または``-i`` を使用してください。また、関連する ini 設定キー ``hostfile`` や環境変数 ``ANSIBLE_HOSTS`` も非推奨となっています。これらは、設定キー ``inventory`` と環境変数 :envvar:`ANSIBLE_INVENTORY` で置き換えてください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:64 -msgid "Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last one overriding all the previous ones. This behavior is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behavior." -msgstr "現在、コマンドラインで ``--tags`` (または ``--skip-tags``) を複数回指定すると、最後に指定したタグがその前に指定したすべてのタグよりも優先されます。この動作は推奨されません。将来的には、--tags を複数回指定した場合、タグは統合されます。今後は、1 つのコマンドラインで ``--tags`` を複数回使用すると、非推奨の警告が表示されます。``ansible.cfg`` ファイルで ``merge_multiple_cli_tags`` オプションを True に設定すると、新しい動作が有効になります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:66 -msgid "In 2.4, the default has change to merge the tags. You can enable the old overwriting behavior through the config option." -msgstr "2.4 では、デフォルトでタグのマージが行われるようになりました。以前の上書きの動作は、設定オプションで有効にすることができます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:68 -msgid "In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behavior." -msgstr "2.5 では、複数の ``--tags`` オプションがマージされ、古い動作に戻る方法はありません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:79 -#: ../../rst/porting_guides/porting_guide_2.7.rst:156 -#: ../../rst/porting_guides/porting_guide_2.8.rst:366 -msgid "Major changes in popular modules are detailed here" -msgstr "一般的なモジュールの主な変更点は、以下を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:81 -msgid "The :ref:`win_shell ` and :ref:`win_command ` modules now properly preserve quoted arguments in the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked to remove the superfluous escaping. See `Issue 23019 `_ for additional detail." -msgstr ":ref:`win_shell ` モジュールおよび :ref:`win_command ` モジュールは、コマンドラインに適切に引用符で囲まれた引数を保持するようになりました。余分な引用符やエスケープを追加してこの問題を回避しようとしたタスクは、不必要なエスケープを取り除くために再作業が必要になるかもしれません。詳細は `Issue 23019 `_ を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:86 -#: ../../rst/porting_guides/porting_guide_2.5.rst:170 -#: ../../rst/porting_guides/porting_guide_2.6.rst:36 -#: ../../rst/porting_guides/porting_guide_2.7.rst:170 -#: ../../rst/porting_guides/porting_guide_2.8.rst:384 -#: ../../rst/porting_guides/porting_guide_2.9.rst:124 -#: ../../rst/porting_guides/porting_guide_4.rst:104 -#: ../../rst/porting_guides/porting_guide_5.rst:95 -#: ../../rst/porting_guides/porting_guide_6.rst:62 -#: ../../rst/porting_guides/porting_guide_7.rst:61 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:107 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:93 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:60 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:59 -msgid "The following modules no longer exist:" -msgstr "次のモジュールはもう存在していません。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:88 -msgid "None" -msgstr "なし" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:93 -msgid "The following modules will be removed in Ansible 2.8. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.8 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:95 -msgid "azure, use :ref:`azure_rm_virtualmachine `, which uses the new Resource Manager SDK." -msgstr "azure - 新しい Resource Manager SDK を使用する :ref:`azure_rm_virtualmachine ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:96 -msgid "win_msi, use :ref:`win_package ` instead" -msgstr "win_msi - 代わりに :ref:`win_package ` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:101 -msgid "The :ref:`win_get_url ` module has the dictionary ``win_get_url`` in its results deprecated, its content is now also available directly in the resulting output, like other modules. This dictionary will be removed in Ansible 2.8." -msgstr ":ref:`win_get_url ` モジュールでは、ディクショナリー ``win_get_url`` が非推奨となり、他のモジュールと同様に、生成された出力でコンテンツが直接利用可能になりました。このディクショナリーは Ansible 2.8 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:102 -msgid "The :ref:`win_unzip ` module no longer includes the dictionary ``win_unzip`` in its results; the contents are now included directly in the resulting output, like other modules." -msgstr ":ref:`win_unzip ` モジュールの結果には、ディクショナリー ``win_unzip`` が含まれなくなりました。コンテンツは、他のモジュールのように、出力に直接追加されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:103 -msgid "The :ref:`win_package ` module return values ``exit_code`` and ``restart_required`` have been deprecated in favor of ``rc`` and ``reboot_required`` respectively. The deprecated return values will be removed in Ansible 2.6." -msgstr ":ref:`win_package ` モジュールの戻り値 ``exit_code`` と ``restart_required`` が非推奨になり、``rc`` および ``reboot_required`` がそれぞれ採用されました。非推奨の戻り値は Ansible 2.6 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:109 -msgid "A new way to configure and document plugins has been introduced. This does not require changes to existing setups but developers should start adapting to the new infrastructure now. More details will be available in the developer documentation for each plugin type." -msgstr "プラグインを設定して文書化する方法が新たに導入されました。これには、既存の設定への変更は必要ありませんが、開発者は新しいインフラストラクチャーへの適合を開始する必要があります。詳細は、各プラグインタイプの開発者ドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:112 -msgid "Vars plugin changes" -msgstr "vars プラグインの変更点" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:114 -msgid "There have been many changes to the implementation of vars plugins, but both users and developers should not need to change anything to keep current setups working. Developers should consider changing their plugins take advantage of new features." -msgstr "vars プラグインの実装には多くの変更が加えられていますが、ユーザーも開発者も、現在の設定を維持するために何も変更する必要はありません。開発者は、新機能を利用したプラグインの変更を検討してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:116 -msgid "The most notable difference to users is that vars plugins now get invoked on demand instead of at inventory build time. This should make them more efficient for large inventories, especially when using a subset of the hosts." -msgstr "ユーザーにとって最も重要な相違点は、vars プラグインがインベントリー構築時ではなく、必要に応じて起動されるようになったことです。これにより、大規模なインベントリー、特にホストのサブセットを使用する場合に、より効率的になります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:120 -msgid "This also creates a difference with group/host_vars when using them adjacent to playbooks. Before, the 'first' playbook loaded determined the variables; now the 'current' playbook does. We are looking to fix this soon, since 'all playbooks' in the path should be considered for variable loading." -msgstr "また、group/host_vars を Playbook に隣接して使用する場合にも違いが生じます。以前は、「最初に」読み込まれた Playbook が変数を決定していましたが、現在は「現在の」Playbook が決定しています。変数の読み込みには、パスに含まれる「すべての Playbook」を考慮する必要があるため、近々この問題を修正したいと考えています。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:121 -msgid "In 2.4.1 we added a toggle to allow you to control this behaviour, 'top' will be the pre 2.4, 'bottom' will use the current playbook hosting the task and 'all' will use them all from top to bottom." -msgstr "2.4.1 では、この動作を制御するためのトグルが追加されました。「top」は 2.4 以前になり、「bottom」はタスクをホストする現在の Playbook を使用し、「all」は上から順にこれらを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:125 -msgid "Inventory plugins" -msgstr "inventory プラグイン" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:127 -msgid "Developers should start migrating from hardcoded inventory with dynamic inventory scripts to the new Inventory Plugins. The scripts will still work through the ``script`` inventory plugin but Ansible development efforts will now concentrate on writing plugins rather than enhancing existing scripts." -msgstr "開発者は、動的インベントリーリスクリプトによるハードコードされたインベントリーから、新しいインベントリースクリプトへの移行を開始する必要があります。スクリプトは、``script`` インベントリープラグインを介して引き続き動作しますが、Ansible の開発努力は、既存のスクリプトの改良ではなく、プラグインの作成に集中することになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:129 -msgid "Both users and developers should look into the new plugins because they are intended to alleviate the need for many of the hacks and workarounds found in the dynamic inventory scripts." -msgstr "ユーザーおよび開発者は、動的インベントリースクリプトにある多くのハッキングや回避策を低減することを目的としているため、ユーザーと開発者は新しいプラグインを調べる必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:134 -msgid "Users:" -msgstr "ユーザー:" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:136 -msgid "Callbacks are now using the new configuration system. Users should not need to change anything as the old system still works, but you might see a deprecation notice if any callbacks used are not inheriting from the built in classes. Developers need to update them as stated below." -msgstr "コールバックは新しい設定システムを使用しています。古いシステムはまだ機能しているため、ユーザーは何も変更する必要はありませんが、使用されているコールバックが組み込みクラスを継承していない場合は、非推奨の通知が表示されるかもしれません。開発者は以下のように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:139 -msgid "Developers:" -msgstr "開発者:" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:141 -msgid "If your callback does not inherit from ``CallbackBase`` (directly or indirectly through another callback), it will still work, but issue a deprecation notice. To avoid this and ensure it works in the future change it to inherit from ``CallbackBase`` so it has the new options handling methods and properties. You can also implement the new options handling methods and properties but that won't automatically inherit changes added in the future. You can look at ``CallbackBase`` itself and/or ``AnsiblePlugin`` for details." -msgstr "コールバックが ``CallbackBase`` を継承していない場合 (直接または他のコールバックを経由して間接的に)、コールバックは動作しますが、非推奨の警告が表示されます。これを回避し、将来も確実に動作させるには、``CallbackBase`` を継承するように変更し、新しいオプション処理のメソッドとプロパティーを持つようにします。新しいオプション処理のメソッドやプロパティーを実装することもできますが、将来追加される変更を自動的に継承することはできません。詳細は、``CallbackBase`` 自体や ``AnsiblePlugin`` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:144 -msgid "Any callbacks inheriting from other callbacks might need to also be updated to contain the same documented options as the parent or the options won't be available. This is noted in the developer guide." -msgstr "他のコールバックから継承されるコールバックも更新して、親と同じ記述されたオプションを含むか、またはオプションを利用できないようにする必要があります。これは、開発者ガイドに記載されています。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:148 -msgid "Template lookup plugin: Escaping Strings" -msgstr "テンプレートルックアッププラグイン: 文字列のエスケープ" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:150 -msgid "Prior to Ansible 2.4, backslashes in strings passed to the template lookup plugin would be escaped automatically. In 2.4, users are responsible for escaping backslashes themselves. This change brings the template lookup plugin inline with the template module so that the same backslash escaping rules apply to both." -msgstr "Ansible 2.4 より前は、テンプレートの lookup プラグインに渡される文字列のバックスラッシュは自動的にエスケープされていました。2.4 では、ユーザーは自分でバックスラッシュをエスケープする責任があります。この変更により、テンプレートの lookup プラグインがテンプレートモジュールとインラインになり、同じバックスラッシュエスケープルールが両方に適用されるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:155 -msgid "If you have a template lookup like this::" -msgstr "以下のようなテンプレート検索がある場合:" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:160 -msgid "**OLD** In Ansible 2.3 (and earlier) :file:`template.j2` would look like this:" -msgstr "Ansible 2.3 以前における **以前の機能** :file:`template.j2` は以下のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:166 -msgid "**NEW** In Ansible 2.4 it should be changed to look like this:" -msgstr "**新機能** Ansible 2.4 では、以下のように変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:173 -msgid "Tests" -msgstr "テスト" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:176 -msgid "Tests succeeded/failed" -msgstr "テストの成功/失敗" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:178 -msgid "Prior to Ansible version 2.4, a task return code of ``rc`` would override a return code of ``failed``. In version 2.4, both ``rc`` and ``failed`` are used to calculate the state of the task. Because of this, test plugins ``succeeded``/``failed``` have also been changed. This means that overriding a task failure with ``failed_when: no`` will result in ``succeeded``/``failed`` returning ``True``/``False``. For example::" -msgstr "Ansible バージョン 2.4 以前では、タスクのリターンコードが ``rc`` の場合は、リターンコードが ``failed`` の場合よりも優先されていました。バージョン 2.4 では、タスクの状態を計算するのに ``rc`` と``failed`` の両方が使用されます。このため、テスト用プラグイン ``succeeded``/``failed``` も変更しました。これは、``failed_when: no`` でタスクの失敗を上書きすると ``succeeded``/``failed`` が ``True``/``False`` となります。たとえば次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:196 -msgid "As we can see from the example above, in Ansible 2.3 ``succeeded``/``failed`` only checked the value of ``rc``." -msgstr "上記の例で分かるように、Ansible 2.3 ``succeeded``/``failed`` では ``rc`` の値のみを確認しています。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:201 -msgid "There have been a number of changes to how Networking Modules operate." -msgstr "Networking モジュールの動作に複数の変更が加えられました。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:206 -msgid "Persistent Connection" -msgstr "永続的な接続" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:208 -msgid "The configuration variables ``connection_retries`` and ``connect_interval`` which were added in Ansible 2.3 are now deprecated. For Ansible 2.4 and later use ``connection_retry_timeout``." -msgstr "Ansible 2.3 で追加された設定変数 ``connection_retries`` および ``connect_interval`` が非推奨になりました。Ansible 2.4 以降では、``connection_retry_timeout`` が使用されます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:210 -msgid "To control timeouts use ``command_timeout`` rather than the previous top level ``timeout`` variable under ``[default]``" -msgstr "タイムアウトを制御するには、``[default]`` の下の以前の最上位である ``timeout`` ではなく、``command_timeout`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:212 -msgid "See :ref:`Ansible Network debug guide ` for more information." -msgstr "詳細は、「:ref:`Ansible Network debug guide `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:216 -msgid "Configuration" -msgstr "Configuration (構成)" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:219 -msgid "The configuration system has had some major changes. Users should be unaffected except for the following:" -msgstr "設定システムに大きな変更が加えられました。以下の点を除き、ユーザーは影響を受けないはずです。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:221 -msgid "All relative paths defined are relative to the `ansible.cfg` file itself. Previously they varied by setting. The new behavior should be more predictable." -msgstr "定義されている相対パスはすべて、`ansible.cfg` ファイル自体に相対的です。以前は設定により変化していました。新しい動作はより予測する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:222 -msgid "A new macro ``{{CWD}}`` is available for paths, which will make paths relative to the 'current working directory', this is unsafe but some users really want to rely on this behaviour." -msgstr "新しいマクロ ``{{CWD}}`` がパスで利用できます。このパスでは、「現在の作業ディレクトリー」に相対的なパスが作成されます。この方法は安全ではありませんが、これを使用したい場合があります。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:225 -msgid "Developers that were working directly with the previous API should revisit their usage as some methods (for example, ``get_config``) were kept for backwards compatibility but will warn users that the function has been deprecated." -msgstr "以前の API を直接使用していた開発者は、使用方法を見直す必要があります。いくつかのメソッド (たとえば ``get_config``) は後方互換性のために残されていますが、その関数が非推奨であることが警告されます。" - -#: ../../rst/porting_guides/porting_guide_2.4.rst:227 -msgid "The new configuration has been designed to minimize the need for code changes in core for new plugins. The plugins just need to document their settings and the configuration system will use the documentation to provide what they need. This is still a work in progress; currently only 'callback' and 'connection' plugins support this. More details will be added to the specific plugin developer guides." -msgstr "新しい設定は、新しいプラグインのためにコアのコードを変更する必要性を最小限に抑えるように設計されています。プラグインは設定を文書化するだけでよく、設定システムはその文書を使用して必要なものを提供します。これはまだ作業中で、現在は「callback」プラグインと「connection」プラグインのみがサポートしています。詳細は、各プラグインの開発者ガイドに追加される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:5 -msgid "Ansible 2.5 Porting Guide" -msgstr "Ansible 2.5 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.4 and Ansible 2.5." -msgstr "このセクションでは、Ansible 2.4 から Ansible 2.5 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.5 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.5 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:21 -msgid "Dynamic includes and attribute inheritance" -msgstr "ダイナミックインクルードと属性の継承" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:23 -msgid "In Ansible version 2.4, the concept of dynamic includes (``include_tasks``), as opposed to static imports (``import_tasks``), was introduced to clearly define the differences in how ``include`` works between dynamic and static includes." -msgstr "Ansible バージョン 2.4 では、静的インポート (``import_tasks``) とは対照的に、動的インクルード (``include_tasks``) という概念が導入され、動的インクルードと静的インクルードの ``include`` の動作の違いが明確に定義されました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:25 -msgid "All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a static ``import_*`` would be inherited by the tasks within." -msgstr "動的な ``include_*`` に適用されるすべての属性はインクルード自体にのみ適用されます。静的な ``import_*`` に適用される属性は、タスクによって継承されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:28 -msgid "This separation was only partially implemented in Ansible version 2.4. As of Ansible version 2.5, this work is complete and the separation now behaves as designed; attributes applied to an ``include_*`` task will not be inherited by the tasks within." -msgstr "この分離は、Ansible バージョン 2.4 では部分的にしか実装されていませんでした。Ansible バージョン 2.5 では、この作業が完了し、設計通りに動作するようになりました。``include_*`` タスクに適用された属性は、その中のタスクには継承されません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:30 -msgid "To achieve an outcome similar to how Ansible worked prior to version 2.5, playbooks should use an explicit application of the attribute on the needed tasks, or use blocks to apply the attribute to many tasks. Another option is to use a static ``import_*`` when possible instead of a dynamic task." -msgstr "バージョン 2.5 以前の Ansible と同様の結果を得るためには、Playbook では、必要なタスクに属性を明示的に適用するか、ブロックを使用して多くのタスクに属性を適用する必要があります。また、動的なタスクではなく、可能な限り静的な ``import_*`` を使用するという方法もあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:32 -msgid "**OLD** In Ansible 2.4:" -msgstr "Ansible 2.4 における **以前の機能**:" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:40 -#: ../../rst/porting_guides/porting_guide_2.5.rst:62 -msgid "Included file:" -msgstr "同梱されるファイル:" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:52 -msgid "**NEW** In Ansible 2.5:" -msgstr "Ansible 2.5 における **新機能**:" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:54 -msgid "Including task:" -msgstr "以下のタスクを含みます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:76 -msgid "The relevant change in those examples is, that in Ansible 2.5, the included file defines the tag ``distro_include`` again. The tag is not inherited automatically." -msgstr "これらの例に関連する変更点は、Ansible 2.5 では、同梱されるファイルで ``distro_include`` というタグが再び定義されていることです。このタグは自動的には継承されません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:79 -msgid "Fixed handling of keywords and inline variables" -msgstr "キーワードおよびインライン変数の処理を修正しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:81 -msgid "We made several fixes to how we handle keywords and 'inline variables', to avoid conflating the two. Unfortunately these changes mean you must specify whether `name` is a keyword or a variable when calling roles. If you have playbooks that look like this::" -msgstr "キーワードと「インライン変数」の扱い方をいくつか修正し、両者の混同を避けるようにしました。残念ながら、この変更により、ロールを呼び出す際に `name` がキーワードなのか変数なのかを指定しなければならなくなりました。以下のような Playbook をお持ちの方は、ご注意ください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:86 -msgid "You will run into errors because Ansible reads name in this context as a keyword. Beginning in 2.5, if you want to use a variable name that is also a keyword, you must explicitly declare it as a variable for the role::" -msgstr "この文脈では、Ansible は名前をキーワードとして読み取るため、エラーが発生します。2.5 以降では、キーワードでもある変数名を使用したい場合は、ロールの変数として明示的に宣言する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:92 -msgid "For a full list of keywords see :ref:`playbook_keywords`." -msgstr "キーワードの完全なリストは、「:ref:`playbook_keywords`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:95 -msgid "Migrating from with_X to loop" -msgstr "with_X から loop への移行" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:1 -msgid "In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``." -msgstr "ほとんどの場合、ループは、``with_X`` スタイルのループではなく、``loop`` キーワードで最適に機能します。``loop`` 構文は通常、``query`` や ``lookup`` の複雑な使用ではなく、フィルターを使用して表現できます。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:3 -msgid "These examples show how to convert many common ``with_`` style loops to ``loop`` and filters." -msgstr "以下の例では、一般的な ``with_`` スタイルのループを ``loop`` およびフィルターに変換する方法を示しています。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:6 -msgid "with_list" -msgstr "with_list" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:8 -msgid "``with_list`` is directly replaced by ``loop``." -msgstr "``with_list`` は、直接 ``loop`` に置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:27 -msgid "with_items" -msgstr "with_items" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:29 -msgid "``with_items`` is replaced by ``loop`` and the ``flatten`` filter." -msgstr "``with_items`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:44 -msgid "with_indexed_items" -msgstr "with_indexed_items" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:46 -msgid "``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``." -msgstr "``with_indexed_items`` は、``loop``、``flatten`` フィルター、および ``loop_control.index_var`` に置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:63 -msgid "with_flattened" -msgstr "with_flattened" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:65 -msgid "``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter." -msgstr "``with_flattened`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:80 -msgid "with_together" -msgstr "with_together" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:82 -msgid "``with_together`` is replaced by ``loop`` and the ``zip`` filter." -msgstr "``with_together`` は、``loop`` フィルターおよび ``zip`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:98 -msgid "Another example with complex data" -msgstr "複雑なデータがある別の例" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:113 -msgid "with_dict" -msgstr "with_dict" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:115 -msgid "``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters." -msgstr "``with_dict`` は、``loop`` フィルターと、``dictsort`` フィルターまたは ``dict2items`` フィルターのいずれかのフィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:135 -msgid "with_sequence" -msgstr "with_sequence" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:137 -msgid "``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter." -msgstr "``with_sequence`` は、``loop`` 関数と ``range`` の関数、そして潜在的には ``format`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:151 -msgid "The range of the loop is exclusive of the end point." -msgstr "ループの範囲はエンドポイントを除きます。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:154 -msgid "with_subelements" -msgstr "with_subelements" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:156 -msgid "``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter." -msgstr "``with_subelements`` は、``loop`` フィルターおよび ``subelements`` フィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:173 -msgid "with_nested/with_cartesian" -msgstr "with_nested/with_cartesian" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:175 -msgid "``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter." -msgstr "``with_nested`` と``with_cartesian`` は、ループと ``product`` のフィルターに置き換えられました。" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:192 -msgid "with_random_choice" -msgstr "with_random_choice" - -#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:194 -msgid "``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``." -msgstr "``with_random_choice`` は、``random`` フィルターを使用するだけで、``loop`` を必要とせずに置き換えることができます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:104 -msgid "Jinja tests used as filters" -msgstr "フィルターとして使用される Jinja テスト" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:106 -msgid "Using Ansible-provided jinja tests as filters will be removed in Ansible 2.9." -msgstr "Ansible が提供する jinja テストをフィルターとして使用することは、Ansible 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:108 -msgid "Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while jinja tests are referenced as ``variable is test_name``." -msgstr "Ansible 2.5 以前は、Ansible に含まれる jinja テストは、ほとんどがフィルターとして使用されていました。使用方法の大きな違いは、フィルターは ``variable | filter_name`` として参照されるのに対し、jinja テストは ``variable is test_name`` として参照されることです。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:110 -msgid "Jinja tests are used for comparisons, while filters are used for data manipulation and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used." -msgstr "jinja テストは比較のために使用され、フィルターはデータ操作のために使用され、それぞれ用途が異なります。この変更は、jinja の理解を深めるために概念を区別し、それぞれが適切に使用される場所を示すためのものです。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:112 -msgid "As of Ansible 2.5, using an Ansible provided jinja test with filter syntax, will display a deprecation error." -msgstr "Ansible 2.5 以降では、Ansible が提供する jinja テストをフィルター構文で使用すると、非推奨エラーが表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:114 -msgid "**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this:" -msgstr "Ansible 2.4 (以前) における **以前の機能** Ansible に含まれる jinja テストを使用すると、次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:122 -msgid "**NEW** In Ansible 2.5 it should be changed to look like this:" -msgstr "**新機能** Ansible 2.5 では、以下のように変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:130 -msgid "In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests. These new tests make more sense grammatically with the jinja test syntax, such as the new ``successful`` test which aliases ``success``." -msgstr "非推奨の警告に加えて、古いテストのエイリアスである多くの新しいテストが導入されました。これらの新しいテストは、``success`` のエイリアスを設定した新しい ``successful`` テストのように、jinja のテスト構文では文法的に意味をなします。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:136 -msgid "See :ref:`playbooks_tests` for more information." -msgstr "詳細は、「:ref:`playbooks_tests`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:138 -msgid "Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py `_." -msgstr "さらに、フィルター構文を使ったテストを適切な jinja テスト構文に変換するためのスクリプトも作成しました。このスクリプトを使用して、Ansible のすべての統合テストを正しい形式に変換しました。いくつかの制限事項が記載されているため、このスクリプトによる変更は、修正した Playbook を実行する前に正しいかどうか評価する必要があります。このスクリプトは `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py `_ にあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:141 -msgid "Ansible fact namespacing" -msgstr "Ansible のファクト名前空間設定" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:143 -msgid "Ansible facts, which have historically been written to names like ``ansible_*`` in the main facts namespace, have been placed in their own new namespace, ``ansible_facts.*`` For example, the fact ``ansible_distribution`` is now best queried through the variable structure ``ansible_facts.distribution``." -msgstr "Ansible のファクトは、これまで主なファクトの名前空間で ``ansible_*`` のような名前で書かれていましたが、独自の新しい名前空間 ``ansible_facts.*`` に配置されました。たとえば、ファクト ``ansible_distribution`` は、変数構造 ``ansible_facts.distribution`` を通じて最もよく照会されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:148 -msgid "A new configuration variable, ``inject_facts_as_vars``, has been added to ansible.cfg. Its default setting, 'True', keeps the 2.4 behavior of facts variables being set in the old ``ansible_*`` locations (while also writing them to the new namespace). This variable is expected to be set to 'False' in a future release. When ``inject_facts_as_vars`` is set to False, you must refer to ansible_facts through the new ``ansible_facts.*`` namespace." -msgstr "ansible.cfg に、新しい設定変数 ``inject_facts_as_vars`` が追加されました。デフォルトの設定は「True」で、2.4 の動作であるファクト変数が古い ``ansible_*`` の場所に設定されたままになります (新しい名前空間にも書き込まれます)。この変数は、将来のリリースでは「False」に設定される予定です。``inject_facts_as_vars`` が False に設定されると、新しい ``ansible_facts.*`` 名前空間を通して ansible_facts を参照する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:158 -msgid "Major changes in popular modules are detailed here." -msgstr "一般的なモジュールの主な変更点は、こちらを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:161 -msgid "github_release" -msgstr "github_release" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:163 -msgid "In Ansible versions 2.4 and older, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module reported state as ``skipped``. In Ansible version 2.5 and later, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module now reports state as ``changed``." -msgstr "Ansible バージョン 2.4 以前では、``create_release`` 状態を使用して GitHub リリースを作成すると、``github_release`` モジュールの状態が ``skipped`` と報告します。Ansible バージョン 2.5 以降では、``create_release`` 状態を使用して GitHub リリースを作成した後に、``github_release`` モジュールの状態が ``changed`` として報告されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:172 -msgid "nxos_mtu use :ref:`nxos_system `'s ``system_mtu`` option or :ref:`nxos_interface ` instead" -msgstr "nxos_mtu は、代わりに :ref:`nxos_system `の ``system_mtu`` オプションまたは :ref:`nxos_interface ` を使用します" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:173 -msgid "cl_interface_policy use :ref:`nclu ` instead" -msgstr "cl_interface_policy は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:174 -msgid "cl_bridge use :ref:`nclu ` instead" -msgstr "cl_bridge は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:175 -msgid "cl_img_install use :ref:`nclu ` instead" -msgstr "cl_img_install は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:176 -msgid "cl_ports use :ref:`nclu ` instead" -msgstr "cl_ports は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:177 -msgid "cl_license use :ref:`nclu ` instead" -msgstr "cl_license は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:178 -msgid "cl_interface use :ref:`nclu ` instead" -msgstr "cl_interface は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:179 -msgid "cl_bond use :ref:`nclu ` instead" -msgstr "cl_bond は、代わりに :ref:`nclu ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:180 -msgid "ec2_vpc use :ref:`ec2_vpc_net ` along with supporting modules :ref:`ec2_vpc_igw `, :ref:`ec2_vpc_route_table `, :ref:`ec2_vpc_subnet `, :ref:`ec2_vpc_dhcp_option `, :ref:`ec2_vpc_nat_gateway `, :ref:`ec2_vpc_nacl ` instead." -msgstr "ec2_vpc は、:ref:`ec2_vpc_net ` とサポートモジュール :ref:`ec2_vpc_igw `、:ref:`ec2_vpc_route_table `、:ref:`ec2_vpc_subnet `、:ref:`ec2_vpc_dhcp_option `、:ref:`ec2_vpc_nat_gateway `、:ref:`ec2_vpc_nacl ` を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:181 -msgid "ec2_ami_search use :ref:`ec2_ami_facts ` instead" -msgstr "ec2_ami_search は、代わりに :ref:`ec2_ami_facts ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:182 -msgid "docker use :ref:`docker_container ` and :ref:`docker_image ` instead" -msgstr "docker は、代わりに :ref:`docker_container ` および :ref:`docker_image ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:186 -msgid "These modules may no longer have documentation in the current release. Please see the `Ansible 2.4 module documentation `_ if you need to know how they worked for porting your playbooks." -msgstr "これらのモジュールには現在のリリースのドキュメントが含まれていない可能性があります。Playbook の移植方法を把握する必要がある場合は、`Ansible 2.4 モジュールのドキュメント `_ を確認してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:196 -msgid "The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.9 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:198 -msgid "Apstra's ``aos_*`` modules are deprecated as they do not work with AOS 2.1 or higher. See new modules at `https://github.com/apstra `_." -msgstr "AOS 2.1 以降では動作しないため、Apstra の ``aos_*`` モジュールは非推奨になりました。`https://github.com/apstra `_ で新しいモジュールを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:199 -msgid "nxos_ip_interface use :ref:`nxos_l3_interface ` instead." -msgstr "nxos_ip_interface は、代わりに :ref:`nxos_l3_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:200 -msgid "nxos_portchannel use :ref:`nxos_linkagg ` instead." -msgstr "nxos_portchannel は、代わりに :ref:`nxos_linkagg ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:201 -msgid "nxos_switchport use :ref:`nxos_l2_interface ` instead." -msgstr "nxos_switchport は、代わりに :ref:`nxos_l2_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:202 -msgid "panos_security_policy use :ref:`panos_security_rule ` instead." -msgstr "panos_security_policy は、代わりに :ref:`panos_security_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:203 -msgid "panos_nat_policy use :ref:`panos_nat_rule ` instead." -msgstr "panos_nat_policy は、代わりに :ref:`panos_nat_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:204 -msgid "vsphere_guest use :ref:`vmware_guest ` instead." -msgstr "vsphere_guest は、代わりに :ref:`vmware_guest ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:209 -msgid "The :ref:`stat ` and :ref:`win_stat ` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``." -msgstr ":ref:`stat ` モジュールおよび :ref:`win_stat ` モジュールは、オプション``get_md5`` のデフォルトを ``true`` から``false`` に変更しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:211 -msgid "This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True`` and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is desired." -msgstr "このオプションは、Ansible バージョン 2.9 以降で削除されます。MD5 チェックサムが必要な場合は、``get_checksum: True`` と ``checksum_algorithm: md5`` のオプションを引き続き使用できます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:215 -msgid "``osx_say`` module was renamed into :ref:`say `." -msgstr "``osx_say`` モジュールの名前が :ref:`say ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:216 -msgid "Several modules which could deal with symlinks had the default value of their ``follow`` option changed as part of a feature to `standardize the behavior of follow `_:" -msgstr "シンボリックリンクを処理することができる複数のモジュールでは、``follow`` オプションのデフォルト値が機能の一部として `standardize the behavior of follow `_ に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:220 -msgid "The :ref:`file module ` changed from ``follow=False`` to ``follow=True`` because its purpose is to modify the attributes of a file and most systems do not allow attributes to be applied to symlinks, only to real files." -msgstr ":ref:`file モジュール ` が ``follow=False`` から ``follow=True`` に変更になったのは、その目的がファイルの属性を変更することであり、ほとんどのシステムでは属性をシンボリックリンクに適用することはできず、実際のファイルにのみ適用することができるからです。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:223 -msgid "The :ref:`replace module ` had its ``follow`` parameter removed because it inherently modifies the content of an existing file so it makes no sense to operate on the link itself." -msgstr ":ref:`replace module ` は、既存ファイルの内容を本質的に変更するため、``follow`` パラメーターが削除されました。したがって、リンク自体で操作することは適切ではありません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:226 -msgid "The :ref:`blockinfile module ` had its ``follow`` parameter removed because it inherently modifies the content of an existing file so it makes no sense to operate on the link itself." -msgstr ":ref:`blockinfile module ` は、既存ファイルの内容を本質的に変更するため、``follow`` パラメーターが削除されました。したがって、リンク自体で操作することは適切ではありません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:229 -msgid "In Ansible-2.5.3, the :ref:`template module ` became more strict about its ``src`` file being proper utf-8. Previously, non-utf8 contents in a template module src file would result in a mangled output file (the non-utf8 characters would be replaced with a unicode replacement character). Now, on Python2, the module will error out with the message, \"Template source files must be utf-8 encoded\". On Python3, the module will first attempt to pass the non-utf8 characters through verbatim and fail if that does not succeed." -msgstr "Ansible-2.5.3 では、:ref:`template module ` が、その ``src`` ファイルが適切な utf-8 であることについて、より厳密になりました。これまでは、テンプレートモジュールの src ファイルに utf8 でないコンテンツがあると、出力ファイルが文字化けしていました (utf8 でない文字は unicode の置換文字で置き換えられます)。現在、Python2 では、モジュールは「Template source files must be utf-8 encoded」というメッセージでエラーになります。Python3 では、モジュールはまず非 utf8 文字をそのまま通過させようとし、それが成功しない場合は失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:239 -msgid "As a developer, you can now use 'doc fragments' for common configuration options on plugin types that support the new plugin configuration system." -msgstr "開発者は、新しいプラグイン設定システムをサポートするプラグインタイプの共通設定オプションに「doc フラグメント」を使用できるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:244 -msgid "Inventory plugins have been fine tuned, and we have started to add some common features:" -msgstr "インベントリープラグインは微調整され、共通の機能を追加しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:246 -msgid "The ability to use a cache plugin to avoid costly API/DB queries is disabled by default. If using inventory scripts, some may already support a cache, but it is outside of Ansible's knowledge and control. Moving to the internal cache will allow you to use Ansible's existing cache refresh/invalidation mechanisms." -msgstr "cache プラグインを使用して、コストのかかる API/DB クエリーを回避するためにする機能は、デフォルトでは無効になっています。インベントリースクリプトを使用している場合、一部のスクリプトはすでにキャッシュをサポートしているかもしれませんが、それは Ansible の知識とコントロールの範囲外となります。内部キャッシュに移行することで、Ansible の既存のキャッシュリフレッシュ/無効化メカニズムを使用できるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:250 -msgid "A new 'auto' plugin, enabled by default, that can automatically detect the correct plugin to use IF that plugin is using our 'common YAML configuration format'. The previous host_list, script, yaml and ini plugins still work as they did, the auto plugin is now the last one we attempt to use. If you had customized the enabled plugins you should revise the setting to include the new auto plugin." -msgstr "デフォルトで有効になっている新しい「auto」プラグイン。プラグインが「共通の YAML 設定形式」を使用している場合に使用する正しいプラグインを自動的に検出できます。以前の host_list、script、yaml、および ini プラグインは引き続き機能しますが、自動プラグインが最後に使用を試みます。有効なプラグインをカスタマイズした場合は、新しい自動プラグインを含めるように設定を変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:255 -msgid "Shell" -msgstr "シェル" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:257 -msgid "Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables." -msgstr "シェルプラグインが、新しいプラグイン設定フレームワークに移行しました。より多くの設定をカスタマイズできるようになり、これまで「グローバル」だった設定を、ホスト固有の変数を使用してオーバーライドできるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:259 -msgid "For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``." -msgstr "たとえば、``system_temps`` は、Ansible が「システム一時ディレクトリー」とみなすものを制御することができる新しい設定です。これは、管理者ではないユーザーの権限を昇格させる際に使用されます。これまでは「/tmp」にハードコードされていましたが、システムによっては特権の昇格に使用できない場合があります。この設定のデフォルトは ``[ '/var/tmp', '/tmp']`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:261 -msgid "Another new setting is ``admin_users`` which allows you to specify a list of users to be considered 'administrators'. Previously this was hardcoded to ``root``. It now it defaults to ``[root, toor, admin]``. This information is used when choosing between your ``remote_temp`` and ``system_temps`` directory." -msgstr "もう一つの新しい設定は ``admin_users`` で、「管理者」とみなされるユーザーのリストを指定することができます。これまでは、``root`` にハードコードされていました。現在はデフォルトで ``[root, toor, admin]`` になっています。この情報は、``remote_temp`` と ``system_temps`` のディレクトリーを選択する際に使用されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:263 -msgid "For a full list, check the shell plugin you are using, the default shell plugin is ``sh``." -msgstr "全一覧については、使用しているシェルプラグインを確認してください。デフォルトのシェルプラグインは ``sh`` です。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:265 -msgid "Those that had to work around the global configuration limitations can now migrate to a per host/group settings, but also note that the new defaults might conflict with existing usage if the assumptions don't correlate to your environment." -msgstr "グローバル設定の制限を回避する必要があった場合は、ホスト/グループごとの設定に移行することができますが、新しいデフォルト設定がお客様の環境と関連していない場合は、既存の使用方法と競合する可能性があることに注意してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:269 -msgid "Filter" -msgstr "フィルター" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:271 -msgid "The lookup plugin API now throws an error if a non-iterable value is returned from a plugin. Previously, numbers or other non-iterable types returned by a plugin were accepted without error or warning. This change was made because plugins should always return a list. Please note that plugins that return strings and other non-list iterable values will not throw an error, but may cause unpredictable behavior. If you have a custom lookup plugin that does not return a list, you should modify it to wrap the return values in a list." -msgstr "プラグインから反復不可能値が返された場合は、lookup プラグイン API がエラーを発生させるようになりました。以前は、プラグインによって返される数値またはその他の反復不可能な型は、エラーや警告なしに受け入れられていました。プラグインは常にリストを返す必要があるため、この変更が行われました。文字列やその他のリストされていない反復可能な値を返すプラグインはエラーを発生させませんが、予期しない動作を引き起こす可能性があることに注意してください。リストを返さないカスタム lookup プラグインがある場合は、戻り値をリストでラップするようにプラグインを変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:275 -msgid "Lookup" -msgstr "Lookup" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:277 -msgid "A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup ` page for more details." -msgstr "新しいオプションは、``error`` という名前のプラグインをグローバルで検索するために追加されました。このプラグインでは、このオプションが常に致命的になる前に、検索によって生成されるエラーの処理方法を制御できます。このオプションの有効な値は ``warn``、``ignore``、および ``strict`` です。詳細は「:ref:`lookup `」ページを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:283 -#: ../../rst/porting_guides/porting_guide_2.6.rst:104 -#: ../../rst/porting_guides/porting_guide_2.6.rst:109 -#: ../../rst/porting_guides/porting_guide_2.7.rst:243 -#: ../../rst/porting_guides/porting_guide_2.7.rst:248 -msgid "No notable changes." -msgstr "主な変更はありません。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:286 -msgid "Network" -msgstr "ネットワーク" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:289 -msgid "Expanding documentation" -msgstr "ドキュメントの拡張" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:291 -msgid "We're expanding the network documentation. There's new content and a :ref:`new Ansible Network landing page`. We will continue to build the network-related documentation moving forward." -msgstr "ネットワークドキュメントを拡充しています。新しいコンテンツと :ref:`new Ansible Network landing page` があります。今後もネットワーク関連のドキュメントを充実させていく予定です。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:294 -msgid "Top-level connection arguments will be removed in 2.9" -msgstr "最上位レベルの接続引数が 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:296 -msgid "Top-level connection arguments like ``username``, ``host``, and ``password`` are deprecated and will be removed in version 2.9." -msgstr "``username``、``host``、``password`` などの最上位レベルの接続引数は非推奨となり、バージョン 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:298 -#: ../../rst/porting_guides/porting_guide_2.9.rst:745 -msgid "**OLD** In Ansible < 2.4" -msgstr "Ansible 2.4 より前のバージョンにおける **以前の機能**" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:311 -msgid "The deprecation warnings reflect this schedule. The task above, run in Ansible 2.5, will result in:" -msgstr "非推奨の警告にはこのスケジュールが反映されます。上記のタスクを Ansible 2.5 で実行すると、以下のような結果になります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:322 -msgid "We recommend using the new connection types ``network_cli`` and ``netconf`` (see below), using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`." -msgstr "新しい接続タイプ ``network_cli`` および ``netconf`` (下記参照) を使用し、Ansible の標準的な接続プロパティーを使用し、インベントリーでそれらのプロパティをグループごとに設定することが推奨されます。Playbook やインベントリーファイルを更新する際に、特権昇格のために ``become`` への変更を簡単に行うことができます (サポートしているプラットフォームの場合)。詳細は、「:ref:`ネットワークモジュールを使用した become の使用`」ガイドおよび「:ref:`プラットフォームドキュメント`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:325 -msgid "Adding persistent connection types ``network_cli`` and ``netconf``" -msgstr "永続的な接続タイプ ``network_cli`` および ``netconf`` の追加" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:327 -msgid "Ansible 2.5 introduces two top-level persistent connection types, ``network_cli`` and ``netconf``. With ``connection: local``, each task passed the connection parameters, which had to be stored in your playbooks. With ``network_cli`` and ``netconf`` the playbook passes the connection parameters once, so you can pass them at the command line if you prefer. We recommend you use ``network_cli`` and ``netconf`` whenever possible. Note that eAPI and NX-API still require ``local`` connections with ``provider`` dictionaries. See the :ref:`platform documentation` for more information. Unless you need a ``local`` connection, update your playbooks to use ``network_cli`` or ``netconf`` and to specify your connection variables with standard Ansible connection variables:" -msgstr "Ansible 2.5 では、``network_cli`` と``netconf`` という 2 つの最上位レベルの永続的な接続タイプが導入されました。``connection: local`` では、各タスクが接続パラメーターを渡していたため、Playbook に保存しておく必要がありました。``network_cli`` および ``netconf`` では、Playbook が接続パラメータを一度だけ渡すため、必要に応じてコマンドラインでパラメーターを渡すことができます。可能な限り ``network_cli`` と ``netconf`` を使用することが推奨されます。なお、eAPI と NX-API では、``provider`` ディレクトリーを使用した ``local`` の接続がまだ必要です。詳細は「:ref:`プラットフォームドキュメント`」を参照してください。``local`` の接続が必要な場合を除き、``network_cli`` または ``netconf`` を使用し、Ansible の標準的な接続変数を指定するように Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:330 -#: ../../rst/porting_guides/porting_guide_2.5.rst:379 -msgid "**OLD** In Ansible 2.4" -msgstr "Ansible 2.4 における **以前の機能**" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:349 -#: ../../rst/porting_guides/porting_guide_2.5.rst:385 -msgid "**NEW** In Ansible 2.5" -msgstr "Ansible 2.5 における **新機能**" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:365 -msgid "Using a provider dictionary with either ``network_cli`` or ``netconf`` will result in a warning." -msgstr "``network_cli`` または ``netconf`` のいずれかでプロバイダーディクショナリーを使用すると、警告が表示されます。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:369 -msgid "Developers: Shared Module Utilities Moved" -msgstr "Developers: 共有モジュールのユーティリティーが移動しました" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:371 -msgid "Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``." -msgstr "Ansible 2.5 以降、ネットワークモジュールの共有モジュールユーティリティーが ``ansible.module_utils.network`` に移動しました。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:373 -msgid "Platform-independent utilities are found in ``ansible.module_utils.network.common``" -msgstr "プラットフォームに依存しないユーティリティーは、``ansible.module_utils.network.common`` にあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:375 -msgid "Platform-specific utilities are found in ``ansible.module_utils.network.{{ platform }}``" -msgstr "プラットフォーム固有のユーティリティーは、``ansible.module_utils.network.{{ platform }}`` にあります。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:377 -msgid "If your module uses shared module utilities, you must update all references. For example, change:" -msgstr "モジュールで共有モジュールユーティリティーを使用している場合は、すべての参照を更新する必要があります。たとえば、以下のように変更します。" - -#: ../../rst/porting_guides/porting_guide_2.5.rst:392 -msgid "See the module utilities developer guide see :ref:`developing_module_utilities` for more information." -msgstr "詳細は、モジュールユーティリティーの開発者ガイドの「:ref:`developing_module_utilities`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:5 -msgid "Ansible 2.6 Porting Guide" -msgstr "Ansible 2.6 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.5 and Ansible 2.6." -msgstr "このセクションでは、Ansible 2.5 から Ansible 2.6 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.6 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.6 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:20 -msgid "The deprecated task option ``always_run`` has been removed, please use ``check_mode: no`` instead." -msgstr "非推奨のタスクオプション ``always_run`` が削除されました。代わりに ``check_mode: no`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:25 -msgid "In the :ref:`nxos_igmp_interface module`, ``oif_prefix`` and ``oif_source`` properties are deprecated. Use ``ois_ps`` parameter with a dictionary of prefix and source to values instead." -msgstr ":ref:`nxos_igmp_interface モジュール ` で、``oif_prefix`` プロパティーおよび ``oif_source`` プロパティーでは非推奨になりました。代わりに、接頭辞のディクショナリーとソースから値へのディクショナリーを付けて ``ois_ps`` パラメーターを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:30 -msgid "Major changes in popular modules are detailed here:" -msgstr "一般的なモジュールの主な変更点は、以下を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:42 -#: ../../rst/porting_guides/porting_guide_2.6.rst:88 -msgid "The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.10 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:44 -msgid "``k8s_raw`` use :ref:`k8s ` instead." -msgstr "``k8s_raw`` は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:45 -msgid "``openshift_raw`` use :ref:`k8s ` instead." -msgstr "``openshift_raw`` は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:46 -msgid "``openshift_scale`` use :ref:`k8s_scale ` instead." -msgstr "``openshift_scale`` は、代わりに :ref:`k8s_scale ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:51 -msgid "The ``upgrade`` module option for ``win_chocolatey`` has been removed; use ``state: latest`` instead." -msgstr "``win_chocolatey`` の ``upgrade`` モジュールオプションが削除されました。代わりに ``state: latest`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:52 -msgid "The ``reboot`` module option for ``win_feature`` has been removed; use the ``win_reboot`` action plugin instead." -msgstr "``win_feature`` の ``reboot`` モジュールオプションが削除されました。代わりに ``win_reboot`` アクションプラグインを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:53 -msgid "The ``win_iis_webapppool`` module no longer accepts a string for the ``attributes`` module option; use the free form dictionary value instead." -msgstr "``win_iis_webapppool`` モジュールは ``attributes`` モジュールオプションの文字列を受け入れなくなりました。代わりに自由形式のディクショナリー値を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:54 -msgid "The ``name`` module option for ``win_package`` has been removed; this is not used anywhere and should just be removed from your playbooks." -msgstr "``win_package`` の ``name`` モジュールオプションが削除されました。これはいずれも使用されず、Playbook から削除されるだけです。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:55 -msgid "The ``win_regedit`` module no longer automatically corrects the hive path ``HCCC`` to ``HKCC``; use ``HKCC`` because this is the correct hive path." -msgstr "``win_regedit`` モジュールは、ハイブパス ``HCCC`` から``HKCC`` を自動的に修正しなくなりました。正しいハイブパスは``HKCC`` です。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:56 -msgid "The :ref:`file_module` now emits a deprecation warning when ``src`` is specified with a state other than ``hard`` or ``link`` as it is only supposed to be useful with those. This could have an effect on people who were depending on a buggy interaction between src and other state's to place files into a subdirectory. For instance::" -msgstr ":ref:`file_module` は、``src`` が ``hard`` または ``link`` 以外の状態で指定された場合、非推奨の警告を表示するようになりました。これは、これらの状態でのみ有用であると考えられているからです。これにより、src と他の状態との間のバグのある相互作用を利用してファイルをサブディレクトリーに置いていた場合は影響が出る可能性があります。たとえば、以下のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:63 -msgid "Would create a directory named ``/tmp/lib``. Instead of the above, simply spell out the entire destination path like this::" -msgstr "``/tmp/lib`` という名前のディレクトリーが作成されます。上記の代わりに、単純に目的地のパス全体を次のように綴ります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:68 -msgid "The ``k8s_raw`` and ``openshift_raw`` modules have been aliased to the new ``k8s`` module." -msgstr "``k8s_raw`` モジュールおよび ``openshift_raw`` モジュールは新しい ``k8s`` モジュールにエイリアスが設定されました。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:69 -msgid "The ``k8s`` module supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources." -msgstr "``k8s`` モジュールは、Custom Resource Definitions や集約された API サーバーからのものを含むすべての Kubernetes リソースをサポートします。これには、すべての OpenShift リソースも含まれます。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:70 -msgid "The ``k8s`` module will not accept resources where subkeys have been snake_cased. This was a workaround that was suggested with the ``k8s_raw`` and ``openshift_raw`` modules." -msgstr "``k8s`` モジュールは、サブキーを使用して snake_cased となったリソースを受け入れません。これは、``k8s_raw`` モジュールおよび ``openshift_raw`` モジュールに提案された回避策です。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:71 -msgid "The ``k8s`` module may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource." -msgstr "``k8s`` モジュールは、``api_version`` が Kubernetes Python クライアントの短縮バージョンに合わせて変更されたリソースを受け入れない場合があります。これからは、リソースに対して適切な完全な Kubernetes ``api_version`` を指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:72 -msgid "The ``k8s`` module can now process multi-document YAML files if they are passed with the ``src`` parameter. It will process each document as a separate resource. Resources provided inline with the ``resource_definition`` parameter must still be a single document." -msgstr "``k8s`` モジュールは、複数ドキュメントの YAML ファイルが ``src`` パラメーターで渡された場合に、それを処理できるようになりました。各ドキュメントは個別のリソースとして処理されます。``resource_definition`` パラメーターを使用してインラインで提供されるリソースは、1 つのドキュメントでなければなりません。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:73 -msgid "The ``k8s`` module will not automatically change ``Project`` creation requests into ``ProjectRequest`` creation requests as the ``openshift_raw`` module did. You must now specify the ``ProjectRequest`` kind explicitly." -msgstr "``openshift_raw`` モジュールが行ったため、``k8s`` モジュールは ``Project`` 作成要求を自動的に ``ProjectRequest`` 作成要求に変更しません。``ProjectRequest`` の種類を明示的に指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:74 -msgid "The ``k8s`` module will not automatically remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block." -msgstr "``k8s`` モジュールは、Ansible の戻り値 (ひいてはログ) からシークレットを自動的に削除しません。タスク内のシークレット値がログに残らないようにするには、タスクブロックに ``no_log`` パラメーターを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:75 -msgid "The ``k8s_scale`` module now supports scalable OpenShift objects, such as ``DeploymentConfig``." -msgstr "``k8s_scale`` モジュールは、``DeploymentConfig`` などのスケーラブルな OpenShift オブジェクトをサポートするようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:76 -msgid "The ``lineinfile`` module was changed to show a warning when using an empty string as a regexp. Since an empty regexp matches every line in a file, it will replace the last line in a file rather than inserting. If this is the desired behavior, use ``'^'`` which will match every line and will not trigger the warning." -msgstr "``lineinfile`` モジュールは、空の文字列を正規表現として使用する際に警告を表示するように変更になりました。空の正規表現はファイルのすべての行に一致するため、ファイルの最後の行を挿入するのではなく、置き換えてしまいます。このような動作をさせたい場合は、``'^'`` を使用すると、すべての行に一致し、警告は発生しません。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:80 -msgid "Openstack modules are no longer using ``shade`` library. Instead ``openstacksdk`` is used. Since ``openstacksdk`` should be already present as a dependency to ``shade`` no additional actions are required." -msgstr "Openstack モジュールで ``shade`` ライブラリーが使用されなくなりました。代わりに ``openstacksdk`` が使用されます。``openstacksdk`` は ``shade`` の依存関係として既に存在しているため、追加のアクションは必要ありません。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:90 -msgid "``openshift`` use ``k8s`` instead." -msgstr "``openshift`` は、代わりに ``k8s`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:96 -msgid "The ``k8s`` lookup plugin now supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources." -msgstr "``k8s`` lookup モジュールは、Custom Resource Definitions や集約された API サーバーからのものを含むすべての Kubernetes リソースをサポートします。これには、すべての OpenShift リソースも含まれます。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:97 -msgid "The ``k8s`` lookup plugin may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource." -msgstr "``k8s`` lookup モジュールは、``api_version`` が Kubernetes Python クライアントの短縮バージョンに合わせて変更されたリソースを受け入れない場合があります。これからは、リソースに対して適切な完全な Kubernetes ``api_version`` を指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:98 -msgid "The ``k8s`` lookup plugin will no longer remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block." -msgstr "``k8s`` lookup プラグインは、Ansible の戻り値 (ひいてはログ) からシークレットを自動的に削除しません。タスク内のシークレット値がログに残らないようにするには、タスクブロックに ``no_log`` パラメーターを指定します。" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:112 -msgid "Dynamic inventory scripts" -msgstr "動的インベントリースクリプト" - -#: ../../rst/porting_guides/porting_guide_2.6.rst:114 -msgid "``contrib/inventory/openstack.py`` has been renamed to ``contrib/inventory/openstack_inventory.py``. If you have used ``openstack.py`` as a name for your OpenStack dynamic inventory file, change it to ``openstack_inventory.py``. Otherwise the file name will conflict with imports from ``openstacksdk``." -msgstr "``contrib/inventory/openstack.py`` の名前が ``contrib/inventory/openstack_inventory.py`` に変更になりました。OpenStack の動的インベントリーファイルの名前として ``openstack.py`` を使用している場合は、``openstack_inventory.py`` に変更してください。そうしないと、ファイル名が ``openstacksdk`` からのインポートと競合します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:5 -msgid "Ansible 2.7 Porting Guide" -msgstr "Ansible 2.7 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.6 and Ansible 2.7." -msgstr "このセクションでは、Ansible 2.6 から Ansible 2.7 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.7 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.7 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:20 -msgid "If you specify ``--tags`` or ``--skip-tags`` multiple times on the command line, Ansible will merge the specified tags together. In previous versions of Ansible, you could set ``merge_multiple_cli_tags`` to ``False`` if you wanted to keep only the last-specified ``--tags``. This config option existed for backwards compatibility. The overwriting behavior was deprecated in 2.3 and the default behavior was changed in 2.4. Ansible-2.7 removes the config option; multiple ``--tags`` are now always merged." -msgstr "コマンドラインで ``--tags`` や ``--skip-tags`` を複数回指定した場合、Ansible は指定されたタグをまとめてマージします。Ansible の以前のバージョンでは、最後に指定した ``--tags`` だけを残したい場合は、``merge_multiple_cli_tags`` を ``False`` に設定することができました。この設定オプションは後方互換性のために存在していました。上書きの動作は 2.3 で非推奨となり、2.4 ではデフォルトの動作が変更されました。Ansible-2.7 では、この設定オプションが削除され、複数の ``--tags`` が常にマージされるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:27 -msgid "If you have a shell script that depends on setting ``merge_multiple_cli_tags`` to ``False``, please upgrade your script so it only adds the ``--tags`` you actually want before upgrading to Ansible-2.7." -msgstr "``merge_multiple_cli_tags`` から ``False`` への設定に依存するシェルスクリプトがある場合は、スクリプトをアップグレードして Ansible-2.7 にアップグレードする前に実際に必要な ``--tags`` のみを追加してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:32 -msgid "Python Compatibility" -msgstr "Python の互換性" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:34 -msgid "Ansible has dropped compatibility with Python-2.6 on the controller (The host where :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` is run). Modules shipped with Ansible can still be used to manage hosts which only have Python-2.6. You just need to have a host with Python-2.7 or Python-3.5 or greater to manage those hosts from." -msgstr "Ansible は、コントローラー (:command:`/usr/bin/ansible` または :command:`/usr/bin/ansible-playbook` が実行されるホスト) での Python-2.6 との互換性を失いました。Ansible に同梱されているモジュールは、Python-2.6 しか搭載していないホストの管理に使用できます。ただし、Python-2.7 以上または Python-3.5 以上のホストから管理する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:39 -msgid "One thing that this does affect is the ability to use :command:`/usr/bin/ansible-pull` to manage a host which has Python-2.6. ``ansible-pull`` runs on the host being managed but it is a controller script, not a module so it will need an updated Python. Actively developed Linux distros which ship with Python-2.6 have some means to install newer Python versions (For instance, you can install Python-2.7 through an SCL on RHEL-6) but you may need to also install Python bindings for many common modules to work (For RHEL-6, for instance, selinux bindings and yum would have to be installed for the updated Python install)." -msgstr "これが影響することの 1 つは、:command:`/usr/bin/ansible-pull` を使用して、Python-2.6 を搭載したホストを管理する機能です。``ansible-pull`` は管理対象のホストで実行しますが、これはコントローラースクリプトであり、モジュールではないため、更新された Python が必要になります。Python-2.6 に同梱されているアクティブに開発された Linux ディストリビューションには、新しい Python バージョンをインストールする手段があります (たとえば、RHEL-6 の SCL を介して Python-2.7 をインストールすることが可能) が、多くの一般的なモジュールの Python バインディングもインストールしないといけない場合があります (たとえば、RHEL-6 の場合、更新された Python インストールには selinux バインディングと yum をインストールする必要があります)。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:47 -msgid "The decision to drop Python-2.6 support on the controller was made because many dependent libraries are becoming unavailable there. In particular, python-cryptography is no longer available for Python-2.6 and the last release of pycrypto (the alternative to python-cryptography) has known security bugs which will never be fixed." -msgstr "コントローラの Python-2.6 サポートを終了する決定を下したのは、多くの依存ライブラリーが利用できなくなってきたためです。特に、python-cryptography は Python-2.6 では利用できなくなり、pycrypto (python-cryptography の代替品) の最後のリリースには、今後も修正されない既知のセキュリティーバグがあります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:57 -msgid "Role Precedence Fix during Role Loading" -msgstr "ロール読み込み時のロールの優先順位の修正" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:59 -msgid "Ansible 2.7 makes a small change to variable precedence when loading roles, resolving a bug, ensuring that role loading matches :ref:`variable precedence expectations `." -msgstr "Ansible 2.7 では、ロールの読み込み時に変数の優先順位が若干変更され、バグを解決し、ロールの読み込みが :ref:`variable precedence expectations ` と一致するようにします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:61 -msgid "Before Ansible 2.7, when loading a role, the variables defined in the role's ``vars/main.yml`` and ``defaults/main.yml`` were not available when parsing the role's ``tasks/main.yml`` file. This prevented the role from utilizing these variables when being parsed. The problem manifested when ``import_tasks`` or ``import_role`` was used with a variable defined in the role's vars or defaults." -msgstr "Ansible 2.7 より前のバージョンでは、ロールを読み込む際に、ロールの ``vars/main.yml`` および``defaults/main.yml`` で定義された変数が、ロールの ``tasks/main.yml`` ファイルを解析するときに利用できませんでした。このため、ロールの解析時にこれらの変数を利用することができませんでした。この問題は、``import_tasks`` または ``import_role`` が、ロールの vars または defaults で定義された変数と一緒に使用されたときに明らかになりました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:63 -msgid "In Ansible 2.7, role ``vars`` and ``defaults`` are now parsed before ``tasks/main.yml``. This can cause a change in behavior if the same variable is defined at the play level and the role level with different values, and used in ``import_tasks`` or ``import_role`` to define the role or file to import." -msgstr "Ansible 2.7 では、ロール ``vars`` および ``defaults`` が ``tasks/main.yml`` の前に解析されるようになりました。これにより、プレイレベルとロールレベルで同じ変数が異なる値で定義されており、``import_tasks`` や``import_role`` でインポートするロールやファイルを定義するのに使用されている場合は、動作が変化する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:66 -msgid "include_role and import_role variable exposure" -msgstr "include_role および import_role の変数の公開" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:68 -msgid "In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks. This value defaults to ``public: False``, matching current behavior." -msgstr "Ansible 2.7 では、``public`` という名前の新しいモジュール引数が ``include_role`` モジュールに追加され、ロールの ``defaults`` および ``vars`` がロール外部に公開され、後のタスクでこれらの変数を使用できるようにします。この値は ``public: False`` にデフォルト設定されており、現在の動作と一致させます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:70 -msgid "``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functionality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play." -msgstr "``import_role`` では ``public`` 引数はサポートされず、ロールの ``defaults`` と ``vars`` は無条件で Playbook の残りの値に公開されます。この機能では、``import_role`` がプレイの ``roles`` ヘッダー内に一覧表示されるロールに綿密な調整されます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:72 -msgid "There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task." -msgstr "``include_role`` (動的) がロールの変数を公開する方法は、``import_role`` (静的) とは重要な違いがあります。``import_role`` はプリプロセッサーであり、``defaults`` と``vars`` は Playbook の解析時に評価され、プレイのどの時点でもリストされているタスクとロールが変数を利用できるようになります。``include_role`` は条件付きタスクであり、``defaults`` と ``vars`` は実行時に評価され、``include_role`` タスクの *後* にリストされているタスクとロールが変数を利用できるようになります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:75 -msgid "include_tasks/import_tasks inline variables" -msgstr "include_tasks/import_tasks インライン変数" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:77 -msgid "As of Ansible 2.7, `include_tasks` and `import_tasks` can no longer accept inline variables. Instead of using inline variables, tasks should supply variables under the ``vars`` keyword." -msgstr "Ansible 2.7 では、`include_tasks` および `import_tasks` はインライン変数を受け付けなくなりました。インライン変数を使用する代わりに、タスクは ``vars`` キーワードで変数を提供する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:79 -msgid "**OLD** In Ansible 2.6 (and earlier) the following was valid syntax for specifying variables:" -msgstr "Ansible 2.6 以前における **以前の機能** 以下は、変数を指定するのに有効な構文でした。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:85 -msgid "**NEW** In Ansible 2.7 the task should be changed to use the ``vars`` keyword:" -msgstr "**新機能** Ansible 2.7 では、``vars`` キーワードを使用するようにタスクを変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:94 -msgid "vars_prompt with unknown algorithms" -msgstr "アルゴリズムが不明な vars_prompt" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:96 -msgid "vars_prompt now throws an error if the hash algorithm specified in encrypt is not supported by the controller. This increases the safety of vars_prompt as it previously returned None if the algorithm was unknown. Some modules, notably the user module, treated a password of None as a request not to set a password. If your playbook starts erroring because of this, change the hashing algorithm being used with this filter." -msgstr "暗号化で指定されたハッシュアルゴリズムがコントローラーでサポートされていない場合は、vars_prompt がエラーを出力するようになりました。これにより、以前はアルゴリズムが不明な場合に None が返されたため、vars_prompt の安全性が向上します。一部のモジュール、特にユーザーモジュールは、None のパスワードをパスワードを設定しない要求として扱いました。これが原因で Playbook でエラーが発生し始めた場合は、このフィルターで使用されているハッシュアルゴリズムを変更してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:107 -msgid "Expedited Deprecation: Use of ``__file__`` in ``AnsibleModule``" -msgstr "Expedited Deprecation: ``AnsibleModule`` での ``__file__`` の使用" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:109 -msgid "The use of the ``__file__`` variable is deprecated in Ansible 2.7 and **will be eliminated in Ansible 2.8**. This is much quicker than our usual 4-release deprecation cycle." -msgstr "``__file__`` 変数の使用は、Ansible 2.7 で非推奨となり、**Ansible 2.8 で廃止される予定です**。これは、通常の 4 リリースの非推奨サイクルよりもはるかに早いものです。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:111 -msgid "We are deprecating the use of the ``__file__`` variable to refer to the file containing the currently-running code. This common Python technique for finding a filesystem path does not always work (even in vanilla Python). Sometimes a Python module can be imported from a virtual location (like inside of a zip file). When this happens, the ``__file__`` variable will reference a virtual location pointing to inside of the zip file. This can cause problems if, for instance, the code was trying to use ``__file__`` to find the directory containing the python module to write some temporary information." -msgstr "現在実行中のコードを含むファイルを参照する ``__file__`` 変数の使用は非推奨になります。ファイルシステムパスを見つけるためのこの一般的な Python の手法は、(vanilla Python でも) 常に機能するとは限りません。Python モジュールを仮想の場所 (zip ファイル内など) からインポートできる場合があります。これが発生すると、``__file__`` 変数は、zip ファイルの内部を指す仮想の場所を参照します。これは、たとえば、コードが ``__file__`` を使用して、一時的な情報を書き込むための Python モジュールを含むディレクトリーを検索する場合に、問題が発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:113 -msgid "Before the introduction of AnsiBallZ in Ansible 2.1, using ``__file__`` worked in ``AnsibleModule`` sometimes, but any module that used it would fail when pipelining was turned on (because the module would be piped into the python interpreter's standard input, so ``__file__`` wouldn't contain a file path). AnsiBallZ unintentionally made using ``__file__`` work, by always creating a temporary file for ``AnsibleModule`` to reside in." -msgstr "Ansible 2.1 で AnsiBallZ が導入される前は、``__file__`` を使用すると ``AnsibleModule`` で動作することがありましたが、パイプラインが有効になっていると、これを使用したモジュールは失敗していました (モジュールは python インタープリターの標準入力にパイプされるため、``__file__`` にはファイルパスが含まれないためです)。AnsiBallZ は、``AnsibleModule`` が常駐するための一時ファイルを常に作成することで、``__file__`` を意図せずに利用できるようにしました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:115 -msgid "Ansible 2.8 will no longer create a temporary file for ``AnsibleModule``; instead it will read the file out of a zip file. This change should speed up module execution, but it does mean that starting with Ansible 2.8, referencing ``__file__`` will always fail in ``AnsibleModule``." -msgstr "Ansible 2.8 は、``AnsibleModule`` 用の一時ファイルを作成しません。この変更により、zip ファイルからファイルを読み取ることになります。この変更により、モジュールの実行が迅速化されますが、Ansible 2.8 以降で ``__file__`` 参照が常に ``AnsibleModule`` で失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:117 -msgid "If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module `:" -msgstr "``__file__`` と ``AnsibleModule`` を併用しているサードパーティーモジュールを作成した場合は、``__file__`` が利用可能な状態ではあってもその使用が非推奨となっている間に、ご自身のモジュールを更新してください。``__file__`` の最も一般的な使い方は、一時ファイルを書き込むディレクトリーを探すことです。Ansible 2.5 以降では、:ref:`apt モジュール ` のコードにあるように、``AnsibleModule`` インスタンスに ``tmpdir`` 属性を使用することができます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:127 -msgid "Using a loop on a package module through squash_actions" -msgstr "squash_actions を使ったパッケージモジュールのループの利用" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:129 -msgid "The use of ``squash_actions`` to invoke a package module, such as \"yum\", to only invoke the module once is deprecated, and will be removed in Ansible 2.11." -msgstr "``squash_actions`` を使用して「yum」などのパッケージモジュールを呼び出して、モジュールが非推奨にしてからのみ起動し、Ansible 2.11 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:131 -msgid "Instead of relying on implicit squashing, tasks should instead supply the list directly to the ``name``, ``pkg`` or ``package`` parameter of the module. This functionality has been supported in most modules since Ansible 2.3." -msgstr "暗黙的な権限付けに依存せずに、タスクは代わりにモジュールの ``name`` パラメーター、``pkg`` パラメーター、または ``package`` パラメーターに直接リストを提供する必要があります。この機能は Ansible 2.3 以降のほとんどのモジュールでサポートされています。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:133 -msgid "**OLD** In Ansible 2.6 (and earlier) the following task would invoke the \"yum\" module only 1 time to install multiple packages" -msgstr "Ansible 2.6 以前における **以前の機能** 以下のタスクが「yum」モジュールを一度だけ呼び出して複数のパッケージをインストールします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:143 -msgid "**NEW** In Ansible 2.7 it should be changed to look like this:" -msgstr "**新機能** Ansible 2.7 では、以下のように変更する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:158 -msgid "The :ref:`DEFAULT_SYSLOG_FACILITY` configuration option tells Ansible modules to use a specific `syslog facility `_ when logging information on all managed machines. Due to a bug with older Ansible versions, this setting did not affect machines using journald with the systemd Python bindings installed. On those machines, Ansible log messages were sent to ``/var/log/messages``, even if you set :ref:`DEFAULT_SYSLOG_FACILITY`. Ansible 2.7 fixes this bug, routing all Ansible log messages according to the value set for :ref:`DEFAULT_SYSLOG_FACILITY`. If you have :ref:`DEFAULT_SYSLOG_FACILITY` configured, the location of remote logs on systems which use journald may change." -msgstr ":ref:`DEFAULT_SYSLOG_FACILITY` 設定オプションは、すべての管理マシンの情報をログに記録する際に、特定の `syslog ファシリティー `_ を使用するように Ansible モジュールに指示します。古い Ansible バージョンのバグにより、この設定は systemd Python バインディングがインストールされた journald を使用するマシンには影響しませんでした。これらのマシンでは、:ref:`DEFAULT_SYSLOG_FACILITY` を設定しても、Ansible のログメッセージは ``/var/log/messages`` に送信されていました。Ansible 2.7 ではこのバグが修正され、すべての Ansible ログメッセージが :ref:`DEFAULT_SYSLOG_FACILITY` に設定された値に従ってルーティングされるようになりました。:ref:`DEFAULT_SYSLOG_FACILITY` を設定している場合は、journald を使用しているシステムのリモートログの場所が変わる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:176 -msgid "The following modules will be removed in Ansible 2.11. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.11 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:178 -msgid "``na_cdot_aggregate`` use :ref:`na_ontap_aggregate ` instead." -msgstr "``na_cdot_aggregate`` は、代わりに :ref:`na_ontap_aggregate ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:179 -msgid "``na_cdot_license`` use :ref:`na_ontap_license ` instead." -msgstr "``na_cdot_license`` は、代わりに :ref:`na_ontap_license ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:180 -msgid "``na_cdot_lun`` use :ref:`na_ontap_lun ` instead." -msgstr "``na_cdot_lun`` は、代わりに :ref:`na_ontap_lun ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:181 -msgid "``na_cdot_qtree`` use :ref:`na_ontap_qtree ` instead." -msgstr "``na_cdot_qtree`` は、代わりに :ref:`na_ontap_qtree ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:182 -msgid "``na_cdot_svm`` use :ref:`na_ontap_svm ` instead." -msgstr "``na_cdot_svm`` は、代わりに :ref:`na_ontap_svm ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:183 -msgid "``na_cdot_user`` use :ref:`na_ontap_user ` instead." -msgstr "``na_cdot_user`` は、代わりに :ref:`na_ontap_user ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:184 -msgid "``na_cdot_user_role`` use :ref:`na_ontap_user_role ` instead." -msgstr "``na_cdot_user_role`` は、代わりに :ref:`na_ontap_user_role ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:185 -msgid "``na_cdot_volume`` use :ref:`na_ontap_volume ` instead." -msgstr "``na_cdot_volume`` は、代わりに :ref:`na_ontap_volume ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:186 -msgid "``sf_account_manager`` use :ref:`na_elementsw_account` instead." -msgstr "``sf_account_manager`` は、代わりに :ref:`na_elementsw_account` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:187 -msgid "``sf_check_connections`` use :ref:`na_elementsw_check_connections` instead." -msgstr "``sf_check_connections`` は、代わりに :ref:`na_elementsw_check_connections` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:188 -msgid "``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule` instead." -msgstr "``sf_snapshot_schedule_manager`` は、代わりに :ref:`na_elementsw_snapshot_schedule` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:189 -msgid "``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group` instead." -msgstr "``sf_volume_access_group_manager`` は、代わりに :ref:`na_elementsw_access_group` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:190 -msgid "``sf_volume_manager`` use :ref:`na_elementsw_volume` instead." -msgstr "``sf_volume_manager`` は、代わりに :ref:`na_elementsw_volume` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:195 -msgid "Check mode is now supported in the ``command`` and ``shell`` modules. However, only when ``creates`` or ``removes`` is specified. If either of these are specified, the module will check for existence of the file and report the correct changed status, if they are not included the module will skip like it had done previously." -msgstr "``command`` モジュールおよび ``shell`` モジュールでチェックモードがサポートされるようになりました。ただし、``creates`` または ``removes`` が指定されている場合に限ります。これらのいずれかが指定された場合、モジュールはファイルの存在をチェックし、正しく変更された状態を報告しますが、これらが含まれていない場合、モジュールは以前のようにスキップします。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:199 -msgid "The ``win_chocolatey`` module originally required the ``proxy_username`` and ``proxy_password`` to escape any double quotes in the value. This is no longer required and the escaping may cause further issues." -msgstr "``win_chocolatey`` モジュールでは、もともと ``proxy_username`` と ``proxy_password`` で値の中の二重引用符をエスケープする必要がありました。これは必須ではなくなり、エスケープすることでさらに問題が発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:203 -msgid "The ``win_uri`` module has removed the deprecated option ``use_basic_parsing``, since Ansible 2.5 this option did nothing" -msgstr "``win_uri`` モジュールは、非推奨のオプション ``use_basic_parsing`` が Ansible 2.5 以降機能していなかっため、削除しました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:206 -msgid "The ``win_scheduled_task`` module has removed the following deprecated options:" -msgstr "``win_scheduled_task`` モジュールでは、以下の非推奨オプションが削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:208 -msgid "``executable``, use ``path`` in an actions entry instead" -msgstr "``executable``。代わりに、アクションエントリーで ``path`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:209 -msgid "``argument``, use ``arguments`` in an actions entry instead" -msgstr "``argument``。代わりに、アクションエントリーで ``arguments`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:210 -msgid "``store_password``, set ``logon_type: password`` instead" -msgstr "``store_password``。代わりに ``logon_type: password`` を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:211 -msgid "``days_of_week``, use ``monthlydow`` in a triggers entry instead" -msgstr "``days_of_week``。代わりに、トリガーエントリーで ``monthlydow`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:212 -msgid "``frequency``, use ``type``, in a triggers entry instead" -msgstr "``frequency``。代わりに、トリガーエントリーで ``type`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:213 -msgid "``time``, use ``start_boundary`` in a triggers entry instead" -msgstr "``time``。代わりに、トリガーエントリーで ``start_boundary`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:215 -msgid "The ``interface_name`` module option for ``na_ontap_net_vlan`` has been removed and should be removed from your playbooks" -msgstr "``na_ontap_net_vlan`` の ``interface_name`` モジュールオプションが削除され、Playbook から削除される必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:217 -msgid "The ``win_disk_image`` module has deprecated the return value ``mount_path``, use ``mount_paths[0]`` instead. This will be removed in Ansible 2.11." -msgstr "``win_disk_image`` モジュールは、戻り値 ``mount_path`` を非推奨とし、代わりに ``mount_paths[0]`` を使用します。この戻り値は Ansible 2.11で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:220 -msgid "``include_role`` and ``include_tasks`` can now be used directly from ``ansible`` (adhoc) and ``ansible-console``::" -msgstr "``include_role`` および ``include_tasks`` は、``ansible`` (adhoc) と``ansible-console`` から直接使用できるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:224 -msgid "The ``pip`` module has added a dependency on ``setuptools`` to support version requirements, this requirement is for the Python interpreter that executes the module and not the Python interpreter that the module is managing." -msgstr "``pip`` モジュールは、バージョン要件をサポートするために ``setuptools`` への依存を追加しました。この要件は、モジュールを実行する Python インタープリターに対するもので、モジュールが管理する Python インタープリターに対するものではありません。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:227 -msgid "Prior to Ansible 2.7.10, the ``replace`` module did the opposite of what was intended when using the ``before`` and ``after`` options together. This now works properly but may require changes to tasks." -msgstr "Ansible 2.7.10 より前のバージョンでは、``replace`` モジュールは、``before`` オプションと ``after`` オプションを同時に使用する際に意図された内容と反対に実行していました。これにより、タスクへの変更が必要になる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.7.rst:233 -msgid "The hash_password filter now throws an error if the hash algorithm specified is not supported by the controller. This increases the safety of the filter as it previously returned None if the algorithm was unknown. Some modules, notably the user module, treated a password of None as a request not to set a password. If your playbook starts erroring because of this, change the hashing algorithm being used with this filter." -msgstr "指定されたハッシュアルゴリズムがコントローラーでサポートされていない場合は、hash_password フィルターがエラーを出力するようになりました。これにより、アルゴリズムが不明な場合、以前は None が返されたため、フィルターの安全性が向上します。一部のモジュール、特にユーザーモジュールは、None のパスワードをパスワードを設定しない要求として扱いました。これが原因で Playbook でエラーが発生し始めた場合は、このフィルターで使用されているハッシュアルゴリズムを変更してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:5 -msgid "Ansible 2.8 Porting Guide" -msgstr "Ansible 2.8 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:7 -msgid "This section discusses the behavioral changes between Ansible 2.7 and Ansible 2.8." -msgstr "このセクションでは、Ansible 2.7 から Ansible 2.8 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:11 -msgid "We suggest you read this page along with `Ansible Changelog for 2.8 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.8 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:22 -msgid "Distribution Facts" -msgstr "分散ファクト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:24 -msgid "The information returned for the ``ansible_distribution_*`` group of facts may have changed slightly. Ansible 2.8 uses a new backend library for information about distributions: `nir0s/distro `_. This library runs on Python-3.8 and fixes many bugs, including correcting release and version names." -msgstr "ファクトの ``ansible_distribution_*`` グループで返される情報は、若干変更されている可能性があります。Ansible 2.8 では、ディストリビューションに関する情報を得るために、新しいバックエンドライブラリー (`nir0s/distro `_) を使用しています。このライブラリーは Python-3.8 上で動作し、リリース名やバージョン名の修正など、多くのバグが修正されています。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:27 -msgid "The two facts used in playbooks most often, ``ansible_distribution`` and ``ansible_distribution_major_version``, should not change. If you discover a change in these facts, please file a bug so we can address the difference. However, other facts like ``ansible_distribution_release`` and ``ansible_distribution_version`` may change as erroneous information gets corrected." -msgstr "Playbook で最もよく使われる 2 つのファクト (``ansible_distribution`` と``ansible_distribution_major_version``) は変更しないでください。これらのファクトが変更されているのを発見した場合は、バグを提出してください。ただし、``ansible_distribution_release`` や``ansible_distribution_version`` のような他のファクトは、誤った情報が修正された場合に変更される可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:32 -msgid "Imports as handlers" -msgstr "ハンドラーとしてインポート" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:34 -msgid "Beginning in version 2.8, a task cannot notify ``import_tasks`` or a static ``include`` that is specified in ``handlers``." -msgstr "バージョン 2.8 以降、タスクは ``handlers`` で指定される ``import_tasks`` または静的 ``include`` に通知することができません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:36 -msgid "The goal of a static import is to act as a pre-processor, where the import is replaced by the tasks defined within the imported file. When using an import, a task can notify any of the named tasks within the imported file, but not the name of the import itself." -msgstr "静的インポートの目的は、インポートがインポートファイル内で定義されたタスクに置き換えられる、事前プロセッサーとして機能することです。インポートを使用する場合、タスクはインポートされたファイル内で名前付きのタスクのいずれかに通知されますが、これはインポート自体の名前ではありません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:39 -msgid "To achieve the results of notifying a single name but running multiple handlers, utilize ``include_tasks``, or ``listen`` :ref:`handlers`." -msgstr "単一の名前に通知するが、複数のハンドラーを実行している場合には、``include_tasks``、または ``listen`` :ref:`handlers` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:42 -msgid "Jinja Undefined values" -msgstr "Jinja の未定義の値" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:44 -msgid "Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure when you don't know if the intermediate values are defined." -msgstr "バージョン 2.8 から、Jinja で Undefined の値の属性にアクセスしようとすると、すぐにエラーが発生するのではなく、別の Undefined の値が返されます。これにより、中間値が定義されているかどうかわからない場合に、ネストされたデータ構造の中の値でデフォルト簡単に使用することができるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:47 -msgid "In Ansible 2.8::" -msgstr "Ansible 2.8 の場合::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:51 -msgid "In Ansible 2.7 and older::" -msgstr "Ansible 2.7 以前::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:55 -msgid "or::" -msgstr "または::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:60 -msgid "Module option conversion to string" -msgstr "モジュールオプションの文字列への変換" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:62 -msgid "Beginning in version 2.8, Ansible will warn if a module expects a string, but a non-string value is passed and automatically converted to a string. This highlights potential problems where, for example, a ``yes`` or ``true`` (parsed as truish boolean value) would be converted to the string ``'True'``, or where a version number ``1.10`` (parsed as float value) would be converted to ``'1.1'``. Such conversions can result in unexpected behavior depending on context." -msgstr "バージョン 2.8 以降、Ansible は、モジュールが文字列を期待しているにもかかわらず、文字列ではない値が渡され、自動的に文字列に変換された場合に警告を発します。これにより、たとえば、``yes`` や ``true`` (truish のブール値として解析) が文字列 ``'True'`` に変換されたり、バージョン番号 ``1.10`` (float 値として解析) が ``'1.1'`` に変換されたりする潜在的な問題が浮き彫りになります。このような変換は、コンテキストによっては予期せぬ動作が発生する可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:64 -msgid "This behavior can be changed to be an error or to be ignored by setting the ``ANSIBLE_STRING_CONVERSION_ACTION`` environment variable, or by setting the ``string_conversion_action`` configuration in the ``defaults`` section of ``ansible.cfg``." -msgstr "この動作は、``ANSIBLE_STRING_CONVERSION_ACTION`` 環境変数を設定したり、``ansible.cfg`` の``defaults`` セクションで``string_conversion_action`` の設定を行うことで、エラーにしたり、無視するように変更することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:67 -msgid "Command line facts" -msgstr "コマンドラインファクト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:69 -msgid "``cmdline`` facts returned in system will be deprecated in favor of ``proc_cmdline``. This change handles special case where Kernel command line parameter contains multiple values with the same key." -msgstr "システムで返される ``cmdline`` ファクトは非推奨となり、``proc_cmdline`` が採用されます。この変更により、カーネルのコマンドラインパラメーターに同じキーを持つ複数の値が含まれている特殊なケースに対応します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:72 -msgid "Bare variables in conditionals" -msgstr "条件のベアメタル変数" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:74 -msgid "In Ansible 2.7 and earlier, top-level variables sometimes treated boolean strings as if they were boolean values. This led to inconsistent behavior in conditional tests built on top-level variables defined as strings. Ansible 2.8 began changing this behavior. For example, if you set two conditions like this:" -msgstr "Ansible 2.7 およびそれ以前のバージョンでは、最上位レベルの変数が、ブール値の文字列をブール値のように扱うことがありました。このため、文字列として定義された最上位レベルの変数に基づいて構築された条件付きテストで、一貫性のない動作が発生していました。Ansible 2.8 では、この動作が変更になりました。たとえば、以下のように 2 つの条件を設定した場合は、次のようになります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:85 -msgid "based on a variable you define **as a string** (with quotation marks around it):" -msgstr "**文字列** として定義する変数に基づきます (引用符で囲みます)。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:87 -msgid "In Ansible 2.7 and earlier, the two conditions above evaluated as ``True`` and ``False`` respectively if ``teardown: 'true'``" -msgstr "Ansible 2.7 以前では、``teardown: 'true'`` と設定すると、上記の 2 つの条件はそれぞれ ``True`` と ``False`` と評価されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:88 -msgid "In Ansible 2.7 and earlier, both conditions evaluated as ``False`` if ``teardown: 'false'``" -msgstr "Ansible 2.7 以前では、``teardown: 'false'`` の場合に、両方の条件が ``False`` と評価されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:89 -msgid "In Ansible 2.8 and later, you have the option of disabling conditional bare variables, so ``when: teardown`` always evaluates as ``True`` and ``when: not teardown`` always evaluates as ``False`` when ``teardown`` is a non-empty string (including ``'true'`` or ``'false'``)" -msgstr "Ansible 2.8 以降では、条件付きベア変数を無効にするオプションがあるため、``when: teardown`` は常に ``True`` として評価され、``when: not teardown`` は ``teardown`` が空ではない文字列 (``'true'`` または ``'false'`` を含む) の場合は常に ``False`` として評価されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:91 -msgid "Ultimately, ``when: 'string'`` will always evaluate as ``True`` and ``when: not 'string'`` will always evaluate as ``False``, as long as ``'string'`` is not empty, even if the value of ``'string'`` itself looks like a boolean. For users with playbooks that depend on the old behavior, we added a config setting that preserves it. You can use the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable or ``conditional_bare_variables`` in the ``defaults`` section of ``ansible.cfg`` to select the behavior you want on your control node. The default setting is ``true``, which preserves the old behavior. Set the config value or environment variable to ``false`` to start using the new option." -msgstr "最終的に、``when: 'string'`` は常に ``True`` として評価され、``when: not 'string'`` は ``'string'`` が空でない限り、``'string'`` 自身の値がブール値のように見えたとしても、``False`` として常に評価されます。以前の動作に依存している Playbook を使用している場合に向けて、以前の動作を維持するための設定を追加しました。環境変数 ``ANSIBLE_CONDITIONAL_BARE_VARS`` または ``ansible.cfg`` の ``defaults`` セクションにある ``conditional_bare_variables`` を使用して、制御ノードに必要な動作を選択することができます。デフォルトの設定は ``true`` で、以前の動作を保持します。新しいオプションの使用を開始するには、設定値または環境変数を ``false`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:95 -msgid "In 2.10 the default setting for ``conditional_bare_variables`` will change to ``false``. In 2.12 the old behavior will be deprecated." -msgstr "2.10 では、``conditional_bare_variables`` のデフォルト設定が ``false`` に変更されます。2.12 では、以前の動作は非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:98 -msgid "Updating your playbooks" -msgstr "Playbook の更新" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:100 -msgid "To prepare your playbooks for the new behavior, you must update your conditional statements so they accept only boolean values. For variables, you can use the ``bool`` filter to evaluate the string ``'false'`` as ``False``:" -msgstr "Playbook を新しい動作に対応させるには、条件文を更新して、ブール値のみを受け付けるようにする必要があります。変数については ``bool`` フィルターを使用して、文字列 ``'false'`` を ``False`` として評価することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:114 -msgid "Alternatively, you can re-define your variables as boolean values (without quotation marks) instead of strings:" -msgstr "変数を、文字列ではなくブール値として再定義することができます (引用符は使用しません)。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:128 -msgid "For dictionaries and lists, use the ``length`` filter to evaluate the presence of a dictionary or list as ``True``:" -msgstr "ディクショナリーおよびリストについては、``length`` フィルターを使用してディクショナリーまたはリストの存在を ``True`` として評価します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:138 -msgid "Do not use the ``bool`` filter with lists or dictionaries. If you use ``bool`` with a list or dict, Ansible will always evaluate it as ``False``." -msgstr "``bool`` フィルターをリストまたはディクショナリーと共に使用しないでください。``bool`` をリストまたはディクショナリーと共に使用する場合、Ansible は常に ``False`` として評価します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:141 -msgid "Double-interpolation" -msgstr "二重の解釈" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:143 -msgid "The ``conditional_bare_variables`` setting also affects variables set based on other variables. The old behavior unexpectedly double-interpolated those variables. For example:" -msgstr "``conditional_bare_variables`` の設定は、他の変数に基づいて設定された変数にも影響します。以前の動作では、それらの変数が予期せず二重に補間されていました。以下に例を示します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:155 -msgid "In Ansible 2.7 and earlier, ``when: double_interpolated`` evaluated to the value of ``bare_variable``, in this case, ``False``. If the variable ``bare_variable`` is undefined, the conditional fails." -msgstr "Ansible 2.7 以前のバージョンでは、``when: double_interpolated`` は``bare_variable`` の値に評価され、この場合は ``False`` となります。変数 ``bare_variable`` が未定義の場合、この条件式は失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:156 -msgid "In Ansible 2.8 and later, with bare variables disabled, Ansible evaluates ``double_interpolated`` as the string ``'bare_variable'``, which is ``True``." -msgstr "Ansible 2.8 以降では、ベア変数が無効な状態で、Ansible は ``double_interpolated`` を文字列 ``'bare_variable'`` として評価します。これは ``True`` となります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:158 -msgid "To double-interpolate variable values, use curly braces:" -msgstr "変数の値を二重引用符で囲むには、中括弧を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:167 -msgid "Nested variables" -msgstr "ネストされた変数" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:169 -msgid "The ``conditional_bare_variables`` setting does not affect nested variables. Any string value assigned to a subkey is already respected and not treated as a boolean. If ``complex_variable['subkey']`` is a non-empty string, then ``when: complex_variable['subkey']`` is always ``True`` and ``when: not complex_variable['subkey']`` is always ``False``. If you want a string subkey like ``complex_variable['subkey']`` to be evaluated as a boolean, you must use the ``bool`` filter." -msgstr "``conditional_bare_variables`` 設定はネストされた変数には影響を与えません。サブキーに割り当てられる文字列値はすでに考慮され、ブール値として処理されません。``complex_variable['subkey']`` が空ではない文字列である場合、``when: complex_variable['subkey']`` は常に ``True`` となり、``when: not complex_variable['subkey']`` は常に ``False`` になります。``complex_variable['subkey']`` などの文字列サブキーをブール値として評価するには、``bool`` フィルターを使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:172 -msgid "Gathering Facts" -msgstr "ファクトの収集" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:174 -msgid "In Ansible 2.8 the implicit \"Gathering Facts\" task in a play was changed to obey play tags. Previous to 2.8, the \"Gathering Facts\" task would ignore play tags and tags supplied from the command line and always run in a task." -msgstr "Ansible 2.8 では、プレイの中で暗黙的に実行される「Gathering Facts」タスクが、プレイタグに従うように変更されました。2.8 より前のバージョンでは、「Gathering Facts」タスクは play タグやコマンドラインから提供されたタグを無視し、常にタスクの中で実行されていました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:178 -msgid "The behavior change affects the following example play." -msgstr "動作の変更は、次のプレイ例に影響します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:193 -msgid "In Ansible 2.8, if you supply ``--tags nginx``, the implicit \"Gathering Facts\" task will be skipped, as the task now inherits the tag of ``webserver`` instead of ``always``." -msgstr "Ansible 2.8 では、``--tags nginx`` を指定すると、タスクが ``always`` ではなく ``webserver`` のタグを継承するため、暗黙的な「Gathering Facts」タスクが省略されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:197 -msgid "If no play level tags are set, the \"Gathering Facts\" task will be given a tag of ``always`` and will effectively match prior behavior." -msgstr "プレイレベルのタグが設定されていない場合、「Gathering Facts」タスクには ``always`` というタグが与えられ、それまでの行動と効果的に一致します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:201 -msgid "You can achieve similar results to the pre-2.8 behavior, by using an explicit ``gather_facts`` task in your ``tasks`` list." -msgstr "``tasks`` で一覧で明示的な ``gather_facts`` タスクを使用すると、バージョン 2.8 より前の動作と同様の結果が得られます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:224 -#: ../../rst/porting_guides/porting_guide_5.rst:47 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:45 -msgid "Python Interpreter Discovery" -msgstr "Python インタープリターの検出" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:226 -msgid "In Ansible 2.7 and earlier, Ansible defaulted to :command:`/usr/bin/python` as the setting for ``ansible_python_interpreter``. If you ran Ansible against a system that installed Python with a different name or a different path, your playbooks would fail with ``/usr/bin/python: bad interpreter: No such file or directory`` unless you either set ``ansible_python_interpreter`` to the correct value for that system or added a Python interpreter and any necessary dependencies at :command:`usr/bin/python`." -msgstr "Ansible 2.7 以前のバージョンでは、``ansible_python_interpreter`` の設定として :command:`/usr/bin/python` が Ansible のデフォルトでした。異なる名前やパスで Python をインストールしたシステムに対して Ansible を実行した場合は、``ansible_python_interpreter`` をそのシステムの正しい値に設定するか、Python インタープリターと必要な依存関係を :command:`usr/bin/python` に追加しない限り、Playbook は ``/usr/bin/python: bad interpreter: No such file or directory`` で失敗します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:234 -msgid "Starting in Ansible 2.8, Ansible searches for the correct path and executable name for Python on each target system, first in a lookup table of default Python interpreters for common distros, then in an ordered fallback list of possible Python interpreter names/paths." -msgstr "Ansible 2.8 以降、Ansible は各ターゲットシステム上の Python の正しいパスと実行ファイル名を、最初は一般的なディストリビューションのデフォルト Python インタープリターの lookup テーブルから、次に可能な Python インタープリター名/パスの順序付きフォールバックリストから検索します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:239 -msgid "It's risky to rely on a Python interpreter set from the fallback list, because the interpreter may change on future runs. If an interpreter from higher in the fallback list gets installed (for example, as a side-effect of installing other packages), your original interpreter and its dependencies will no longer be used. For this reason, Ansible warns you when it uses a Python interpreter discovered from the fallback list. If you see this warning, the best solution is to explicitly set ``ansible_python_interpreter`` to the path of the correct interpreter for those target systems." -msgstr "フォールバックリストから設定された Python インタープリターに依存するのはリスクがあります。なぜなら、将来の実行時にインタープリターが変更される可能性があるためです。フォールバックリストの上位にあるインタープリタがインストールされると (たとえば、他のパッケージをインストールする際の副作用として)、元のインタープリターとその依存関係は使用できなくなります。このような理由から、Ansible はフォールバックリストから検出された Python インタープリターを使用する際に警告を表示します。この警告が表示された場合、最良の解決策は、明示的に ``ansible_python_interpreter`` にそれらのターゲットシステムの正しいインタープリターのパスを設定することです。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:248 -msgid "You can still set ``ansible_python_interpreter`` to a specific path at any variable level (as a host variable, in vars files, in playbooks, and so on). If you prefer to use the Python interpreter discovery behavior, use one of the four new values for ``ansible_python_interpreter`` introduced in Ansible 2.8:" -msgstr "これまで通り、どの変数レベル (ホスト変数、vars ファイル、Playbook など) でも、``ansible_python_interpreter`` を特定のパスに設定することができます。Python インタープリターの検出動作を使用する場合は、Ansible 2.8 で導入された ``ansible_python_interpreter`` の新しい 4 つの値のうちの 1 つを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:255 -msgid "New value" -msgstr "新しい値" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:255 -msgid "Behavior" -msgstr "動作" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:257 -msgid "auto |br| (future default)" -msgstr "自動 |br| (将来のデフォルト)" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:257 -msgid "If a Python interpreter is discovered, Ansible uses the discovered Python, even if :command:`/usr/bin/python` is also present. Warns when using the fallback list." -msgstr "Python インタープリターが検出され、:command:`/usr/bin/python` がない場合に、Ansible は検出された Python を使用します。フォールバックリストを使用する際に警告します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:262 -msgid "**auto_legacy** |br| (Ansible 2.8 default)" -msgstr "**auto_legacy** |br| (Ansible 2.8 デフォルト)" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:262 -msgid "If a Python interpreter is discovered, and :command:`/usr/bin/python` is absent, Ansible uses the discovered Python. Warns when using the fallback list." -msgstr "Python インタープリターが検出され、:command:`/usr/bin/python` がない場合に、Ansible は検出された Python を使用します。フォールバックリストを使用する際に警告します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:267 -msgid "If a Python interpreter is discovered, and :command:`/usr/bin/python` is present, Ansible uses :command:`/usr/bin/python` and prints a deprecation warning about future default behavior. Warns when using the fallback list." -msgstr "Python インタープリターが発見され、:command:`/usr/bin/python` が存在する場合、Ansible は :command:`/usr/bin/python` を使用し、将来のデフォルトの動作について非推奨の警告を表示します。フォールバックリストを使用する際に警告します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:274 -msgid "auto_legacy_silent" -msgstr "auto_legacy_silent" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:274 -msgid "Behaves like ``auto_legacy`` but suppresses the deprecation and fallback-list warnings." -msgstr "``auto_legacy`` のような動作はしますが、非推奨とフォールバックリストに関する警告は抑制されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:277 -msgid "auto_silent" -msgstr "auto_silent" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:277 -msgid "Behaves like ``auto`` but suppresses the fallback-list warning." -msgstr "``auto`` のように動作しますが、fallback-list の警告は表示されません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:282 -msgid "In Ansible 2.12, Ansible will switch the default from :literal:`auto_legacy` to :literal:`auto`. The difference in behaviour is that :literal:`auto_legacy` uses :command:`/usr/bin/python` if present and falls back to the discovered Python when it is not present. :literal:`auto` will always use the discovered Python, regardless of whether :command:`/usr/bin/python` exists. The :literal:`auto_legacy` setting provides compatibility with previous versions of Ansible that always defaulted to :command:`/usr/bin/python`." -msgstr "Ansible 2.12 では、Ansible はデフォルトを :literal:`auto_legacy` から :literal:`auto` に変更します。挙動の違いは、:literal:`auto_legacy` は :command:`/usr/bin/python` が存在すればそれを使用し、存在しなければ検出された Python にフォールバックします。:literal:`auto` は :command:`/usr/bin/python` が存在するかどうかに関わらず、常に検出された Python を使用します。:literal:`auto_legacy` の設定は、常に :command:`/usr/bin/python` をデフォルトとしていた以前のバージョンの Ansible との互換性を提供します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:289 -msgid "If you installed Python and dependencies (``boto``, and so on) to :command:`/usr/bin/python` as a workaround on distros with a different default Python interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two options:" -msgstr "異なるデフォルトの Python インタープリターを持つディストリビューション (例: Ubuntu 16.04 以降、RHEL 8、Fedora 23 以降) での回避策として、Python と依存ファイル (``boto`` など) を :command:`/usr/bin/python` にインストールした場合のオプションが 2 つあります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:294 -msgid "Move existing dependencies over to the default Python for each platform/distribution/version." -msgstr "各プラットフォーム/ディストリビューション/バージョンで、既存の依存関係をデフォルトの Python に移動します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:295 -msgid "Use ``auto_legacy``. This setting lets Ansible find and use the workaround Python on hosts that have it, while also finding the correct default Python on newer hosts. But remember, the default will change in 4 releases." -msgstr "``auto_legacy`` を使用します。この設定により、Ansible は Python があるホストでは回避策の Python を見つけて使用し、新しいホストでは正しいデフォルトの Python を見つけることができます。ただし、デフォルトは 4 つのリリースで変更されることを忘れないでください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:299 -msgid "Retry File Creation default" -msgstr "ファイル作成の再試行デフォルト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:301 -msgid "In Ansible 2.8, ``retry_files_enabled`` now defaults to ``False`` instead of ``True``. The behavior can be modified to previous version by editing the default ``ansible.cfg`` file and setting the value to ``True``." -msgstr "Ansible 2.8 では、``retry_files_enabled`` は ``True`` ではなく ``False`` にデフォルト設定されています。動作は、デフォルトの ``ansible.cfg`` ファイルを編集し、値を ``True`` に設定すると変更できます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:308 -msgid "Become Prompting" -msgstr "Become プロンプト" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:310 -msgid "Beginning in version 2.8, by default Ansible will use the word ``BECOME`` to prompt you for a password for elevated privileges (``sudo`` privileges on Unix systems or ``enable`` mode on network devices):" -msgstr "バージョン 2.8 以降、Ansible のデフォルトでは、昇格権限 (Unix システムでは ``sudo`` 権限、またはネットワークデバイスでは ``enable`` モード) のパスワードの入力を促す際に、``BECOME`` という単語を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:312 -msgid "By default in Ansible 2.8::" -msgstr "Ansible 2.8 のデフォルト::" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:317 -msgid "If you want the prompt to display the specific ``become_method`` you're using, instead of the general value ``BECOME``, set :ref:`AGNOSTIC_BECOME_PROMPT` to ``False`` in your Ansible configuration." -msgstr "使用している特定の ``become_method`` をプロンプトで表示する場合は、Ansible 設定で一般的な値の ``BECOME`` ではなく、:ref:`AGNOSTIC_BECOME_PROMPT` を ``False`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:319 -msgid "By default in Ansible 2.7, or with ``AGNOSTIC_BECOME_PROMPT=False`` in Ansible 2.8::" -msgstr "デフォルトでは Ansible 2.7、または Ansible 2.8 の ``AGNOSTIC_BECOME_PROMPT=False`` で使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:327 -msgid "Setting the async directory using ``ANSIBLE_ASYNC_DIR`` as an task/play environment key is deprecated and will be removed in Ansible 2.12. You can achieve the same result by setting ``ansible_async_dir`` as a variable like::" -msgstr "``ANSIBLE_ASYNC_DIR`` を task/play 環境キーとして使用して非同期ディレクトリーを設定することは非推奨であり、Ansible 2.12 で削除される予定です。``ansible_async_dir`` を次のように変数として設定することで、同じ結果を得ることができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:336 -msgid "Plugin writers who need a ``FactCache`` object should be aware of two deprecations:" -msgstr "``FactCache`` オブジェクトを必要とするプラグイン作成者は、以下の 2 つの非推奨を認識する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:338 -msgid "The ``FactCache`` class has moved from ``ansible.plugins.cache.FactCache`` to ``ansible.vars.fact_cache.FactCache``. This is because the ``FactCache`` is not part of the cache plugin API and cache plugin authors should not be subclassing it. ``FactCache`` is still available from its old location but will issue a deprecation warning when used from there. The old location will be removed in Ansible 2.12." -msgstr "``FactCache`` クラスは ``ansible.plugins.cache.FactCache`` から``ansible.vars.fact_cache.FactCache`` へ移動しました。これは、``FactCache`` が cache プラグイン API の一部ではないため、cache プラグインの作成者はこれをサブクラス化すべきではないという理由によるものです。``FactCache`` は以前の場所でも利用できますが、そこから使用すると非推奨の警告が表示されます。この古い場所は Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:344 -msgid "The ``FactCache.update()`` method has been converted to follow the dict API. It now takes a dictionary as its sole argument and updates itself with the dictionary's items. The previous API where ``update()`` took a key and a value will now issue a deprecation warning and will be removed in 2.12. If you need the old behavior switch to ``FactCache.first_order_merge()`` instead." -msgstr "``FactCache.update()`` メソッドは、dict API に従うように変更されました。ディレクトリーを唯一の引数として受け取り、そのディレクトリーの項目で自身を更新するようになりました。``update()`` がキーと値を受け取っていた以前の API は、現在は非推奨の警告が表示されされ、2.12 で削除されます。以前の動作が必要な場合は、代わりに ``FactCache.first_order_merge()`` に切り替えてください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:350 -msgid "Supporting file-backed caching through self.cache is deprecated and will be removed in Ansible 2.12. If you maintain an inventory plugin, update it to use ``self._cache`` as a dictionary. For implementation details, see the :ref:`developer guide on inventory plugins`." -msgstr "self.cache によるファイルバックキャッシングのサポートは非推奨で、Ansible 2.12 で削除されます。インベントリープラグインを管理している場合は、ディクショナリーとして ``self._cache`` を使用するように更新してください。実装の詳細は、「:ref:`developer guide on inventory plugins`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:354 -msgid "Importing cache plugins directly is deprecated and will be removed in Ansible 2.12. Use the plugin_loader so direct options, environment variables, and other means of configuration can be reconciled using the config system rather than constants." -msgstr "cache プラグインを直接インポートすることは非推奨であり、Ansible 2.12 で削除される予定です。plugin_loader を使用することで、ダイレクトオプション、環境変数、その他の設定手段を、定数ではなく設定システムを使って調整することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:368 -msgid "The exec wrapper that runs PowerShell modules has been changed to set ``$ErrorActionPreference = \"Stop\"`` globally. This may mean that custom modules can fail if they implicitly relied on this behavior. To get the old behavior back, add ``$ErrorActionPreference = \"Continue\"`` to the top of the module. This change was made to restore the old behavior of the EAP that was accidentally removed in a previous release and ensure that modules are more resilient to errors that may occur in execution." -msgstr "PowerShell モジュールを実行する exec ラッパーは、``$ErrorActionPreference = \"Stop\"`` をグローバルに設定するように変更になりました。これにより、カスタムモジュールがこの動作に暗黙的に依存していた場合は、失敗する可能性があります。以前の動作を取り戻すには、モジュールの先頭に ``$ErrorActionPreference = \"Continue\"`` を追加してください。この変更は、以前のリリースで誤って削除された EAP の古い動作を復元し、実行時に発生するエラーに対してモジュールがより耐性を持つようにするために行われました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:374 -msgid "Version 2.8.14 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the ``mode`` change has been reverted in 2.8.15, and ``mode`` will now default to ``0o666 & ~umask`` as in previous versions of Ansible." -msgstr "Ansible のバージョン 2.8.14 は、ユーザーがファイルベースのタスクで ``mode`` パラメーターを指定しなかった場合に、ファイルベースのタスクのデフォルトモードを ``0o600 & ~umask`` に変更しました。これは、再編成した CVE レポートに対する対応でした。その結果、2.8.15 では ``mode`` の変更が元に戻され、以前のバージョンの Ansible と同様に、``mode`` のデフォルトが ``0o666 & ~umask`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:375 -msgid "If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15." -msgstr "2.8.14 を使用する際に、より制限の少ないパーミッションを指定するようにタスクを変更した場合、2.8.15 ではその変更は不要になります (ただし、害はありません)。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:378 -msgid "``dnf`` and ``yum`` - As of version 2.8.15, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task." -msgstr "``dnf`` および ``yum`` - バージョン 2.8.15 より、``dnf`` モジュール (および ``dnf`` を使用する場合は ``yum`` アクション) がパッケージの GPG 署名を正しく検証するようになりました (CVE-2020-14365)。``Failed to validate GPG signature for [package name]`` のようなエラーが表示された場合は、使用している DNF リポジトリーやパッケージの GPG キーが正しくインポートされていることを確認してください。これを行う 1 つの方法として、``rpm_key`` モジュールの使用があります。推奨はしませんが、場合によっては GPG チェックを無効にする必要があるかもしれません。これは、``dnf`` タスクまたは ``yum`` タスクに ``disable_gpg_check: yes`` を明示的に追加することで実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:386 -msgid "ec2_remote_facts" -msgstr "ec2_remote_facts" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:387 -msgid "azure" -msgstr "azure" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:388 -msgid "cs_nic" -msgstr "cs_nic" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:389 -msgid "netscaler" -msgstr "netscaler" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:390 -msgid "win_msi" -msgstr "win_msi" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:395 -msgid "The following modules will be removed in Ansible 2.12. Please update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.12 で削除されます。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:397 -msgid "``foreman`` use `foreman-ansible-modules `_ instead." -msgstr "``foreman`` は、代わりに `foreman-ansible-modules `_ を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:398 -msgid "``katello`` use `foreman-ansible-modules `_ instead." -msgstr "``katello`` は、代わりに `foreman-ansible-modules `_ を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:399 -msgid "``github_hooks`` use :ref:`github_webhook ` and :ref:`github_webhook_facts ` instead." -msgstr "``github_hooks`` は、代わりに :ref:`github_webhook ` および :ref:`github_webhook_facts ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:400 -msgid "``digital_ocean`` use :ref:`digital_ocean_droplet ` instead." -msgstr "``digital_ocean`` は、代わりに :ref:`digital_ocean_droplet ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:401 -msgid "``gce`` use :ref:`gcp_compute_instance ` instead." -msgstr "``gce`` は、代わりに :ref:`gcp_compute_instance ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:402 -msgid "``gcspanner`` use :ref:`gcp_spanner_instance ` and :ref:`gcp_spanner_database ` instead." -msgstr "``gcspanner`` は、代わりに :ref:`gcp_spanner_instance ` および :ref:`gcp_spanner_database ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:403 -msgid "``gcdns_record`` use :ref:`gcp_dns_resource_record_set ` instead." -msgstr "``gcdns_record`` は、代わりに :ref:`gcp_dns_resource_record_set ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:404 -msgid "``gcdns_zone`` use :ref:`gcp_dns_managed_zone ` instead." -msgstr "``gcdns_zone`` は、代わりに :ref:`gcp_dns_managed_zone ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:405 -msgid "``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule ` or :ref:`gcp_compute_forwarding_rule ` instead." -msgstr "``gcp_forwarding_rule`` は、代わりに :ref:`gcp_compute_global_forwarding_rule ` または:ref:`gcp_compute_forwarding_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:406 -msgid "``gcp_healthcheck`` use :ref:`gcp_compute_health_check `, :ref:`gcp_compute_http_health_check `, or :ref:`gcp_compute_https_health_check ` instead." -msgstr "``gcp_healthcheck`` は、代わりに :ref:`gcp_compute_health_check `、:ref:`gcp_compute_http_health_check `、または :ref:`gcp_compute_https_health_check ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:407 -msgid "``gcp_backend_service`` use :ref:`gcp_compute_backend_service ` instead." -msgstr "``gcp_backend_service`` は、代わりに :ref:`gcp_compute_backend_service ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:408 -msgid "``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy ` instead." -msgstr "``gcp_target_proxy`` は、代わりに :ref:`gcp_compute_target_http_proxy ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:409 -msgid "``gcp_url_map`` use :ref:`gcp_compute_url_map ` instead." -msgstr "``gcp_url_map`` は、代わりに :ref:`gcp_compute_url_map ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:410 -msgid "``panos`` use the `Palo Alto Networks Ansible Galaxy role `_ instead." -msgstr "``panos`` は、代わりに `Palo Alto Networks Ansible Galaxy role `_ を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:416 -msgid "The ``foreman`` and ``katello`` modules have been deprecated in favor of a set of modules that are broken out per entity with better idempotency in mind." -msgstr "``foreman`` と ``katello`` のモジュールは非推奨になり、より良い冪等性を考慮してエンティティーごとに分割されたモジュールのセットが採用されました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:417 -msgid "The ``foreman`` and ``katello`` modules replacement is officially part of the Foreman Community and supported there." -msgstr "``foreman`` モジュールおよび ``katello`` モジュールの置き換えは、Foreman Community の一部であり、そこでサポートされます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:418 -msgid "The ``tower_credential`` module originally required the ``ssh_key_data`` to be the path to a ssh_key_file. In order to work like AWX/Tower/RHAAP, ``ssh_key_data`` now contains the content of the file. The previous behavior can be achieved with ``lookup('file', '/path/to/file')``." -msgstr "``tower_credential`` モジュールでは、もともと ``ssh_key_data`` に ssh_key_file のパスを指定する必要がありました。AWX/Tower/RHAAP のように動作させるために、``ssh_key_data`` にファイルの内容を含めるようになりました。以前の動作は ``lookup('file', '/path/to/file')`` で実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:421 -msgid "The ``win_scheduled_task`` module deprecated support for specifying a trigger repetition as a list and this format will be removed in Ansible 2.12. Instead specify the repetition as a dictionary value." -msgstr "``win_scheduled_task`` モジュールは、トリガーの繰り返しをリストとして指定するサポートを非推奨としており、このフォーマットは Ansible 2.12で 削除される予定です。代わりに、繰り返しをディクショナリーの値として指定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:424 -msgid "The ``win_feature`` module has removed the deprecated ``restart_needed`` return value, use the standardized ``reboot_required`` value instead." -msgstr "``win_feature`` モジュールによって非推奨の ``restart_needed`` の戻り値が削除され、代わりに標準化された ``reboot_required`` 値を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:427 -msgid "The ``win_package`` module has removed the deprecated ``restart_required`` and ``exit_code`` return value, use the standardized ``reboot_required`` and ``rc`` value instead." -msgstr "``win_package`` モジュールによって非推奨の ``restart_required`` および ``exit_code`` の戻り値が削除され、代わりに標準化された ``reboot_required`` および ``rc`` の値が使用します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:430 -msgid "The ``win_get_url`` module has removed the deprecated ``win_get_url`` return dictionary, contained values are returned directly." -msgstr "``win_get_url`` モジュールは、非推奨の ``win_get_url`` 戻りディクショナリーを削除し、含まれる値が直接返されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:433 -msgid "The ``win_get_url`` module has removed the deprecated ``skip_certificate_validation`` option, use the standardized ``validate_certs`` option instead." -msgstr "``win_get_url`` モジュールによって非推奨の ``skip_certificate_validation`` オプションが削除され、代わりに標準化された ``validate_certs`` オプションを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:436 -msgid "The ``vmware_local_role_facts`` module now returns a list of dicts instead of a dict of dicts for role information." -msgstr "``vmware_local_role_facts`` モジュールは、ロール情報に対して、dict の中の dict ではなく、dict のリストを返すようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:438 -msgid "If ``docker_network`` or ``docker_volume`` were called with ``diff: yes``, ``check_mode: yes`` or ``debug: yes``, a return value called ``diff`` was returned of type ``list``. To enable proper diff output, this was changed to type ``dict``; the original ``list`` is returned as ``diff.differences``." -msgstr "``docker_network`` または ``docker_volume`` が ``diff: yes``、``check_mode: yes``、または``debug: yes`` で呼び出された場合は、``diff`` と呼ばれる ``list`` タイプの戻り値が返されていました。適切な diff 出力を可能にするために、これを ``dict`` タイプに変更し、元の ``list`` は``diff.differences`` として返されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:442 -msgid "The ``na_ontap_cluster_peer`` module has replaced ``source_intercluster_lif`` and ``dest_intercluster_lif`` string options with ``source_intercluster_lifs`` and ``dest_intercluster_lifs`` list options" -msgstr "``na_ontap_cluster_peer`` モジュールでは、文字列オプションの ``source_intercluster_lif`` および ``dest_intercluster_lif`` が、リストオプションの ``source_intercluster_lifs`` および ``dest_intercluster_lifs`` に置き換わりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:445 -msgid "The ``modprobe`` module now detects kernel builtins. Previously, attempting to remove (with ``state: absent``) a builtin kernel module succeeded without any error message because ``modprobe`` did not detect the module as ``present``. Now, ``modprobe`` will fail if a kernel module is builtin and ``state: absent`` (with an error message from the modprobe binary like ``modprobe: ERROR: Module nfs is builtin.``), and it will succeed without reporting changed if ``state: present``. Any playbooks that are using ``changed_when: no`` to mask this quirk can safely remove that workaround. To get the previous behavior when applying ``state: absent`` to a builtin kernel module, use ``failed_when: false`` or ``ignore_errors: true`` in your playbook." -msgstr "``modprobe`` モジュールがカーネルビルドインを検出するようになりました。これまでは、``modprobe`` がそのモジュールを ``present`` として検出していなかったため、組み込みカーネルモジュールを (``state: absent`` で) 削除しようとすると、成功してエラーメッセージも表示されませんでした。現在では、``modprobe`` はカーネルモジュールが組み込まれて ``state: absent`` の場合は失敗し (modprobe バイナリーから ``modprobe: ERROR: Module nfs is builtin.`` のようなエラーメッセージが表示されます)、``state: present`` の場合は変更を報告せずに成功します。この特異な動作を隠すために ``changed_when: no`` を使用している Playbook は、その回避策を削除しても問題はありません。組み込みカーネルモジュールに ``state: absent`` を適用して以前の動作を得るには、Playbook で ``failed_when: false`` または ``ignore_errors: true`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:453 -msgid "The ``digital_ocean`` module has been deprecated in favor of modules that do not require external dependencies. This allows for more flexibility and better module support." -msgstr "``digital_ocean`` モジュールは非推奨となり、外部依存を必要としないモジュールが採用されました。これにより、より柔軟で優れたモジュールサポートが可能になります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:456 -msgid "The ``docker_container`` module has deprecated the returned fact ``docker_container``. The same value is available as the returned variable ``container``. The returned fact will be removed in Ansible 2.12." -msgstr "``docker_container`` モジュールは、返されるファクト ``docker_container`` を非推奨としています。返される変数 ``container`` と同じ値が利用できます。返されるファクトは Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:458 -msgid "The ``docker_network`` module has deprecated the returned fact ``docker_container``. The same value is available as the returned variable ``network``. The returned fact will be removed in Ansible 2.12." -msgstr "``docker_network`` モジュールは、返されるファクト ``docker_container`` を非推奨としています。返される変数 ``network`` と同じ値が利用できます。返されるファクトは Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:460 -msgid "The ``docker_volume`` module has deprecated the returned fact ``docker_container``. The same value is available as the returned variable ``volume``. The returned fact will be removed in Ansible 2.12." -msgstr "``docker_volume`` モジュールは、返されるファクト ``docker_container`` を非推奨としています。返される変数 ``volume`` と同じ値が利用できます。返されるファクトは Ansible 2.12 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:463 -msgid "The ``docker_service`` module was renamed to :ref:`docker_compose `." -msgstr "``docker_service`` モジュールの名前が :ref:`docker_compose ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:464 -msgid "The renamed ``docker_compose`` module used to return one fact per service, named same as the service. A dictionary of these facts is returned as the regular return value ``services``. The returned facts will be removed in Ansible 2.12." -msgstr "サービスと同じ名前に変更した ``docker_compose`` モジュールは、サービスごとに 1 つのファクトを返すために使用されます。これらのファクトのディクショナリーは、通常の戻り値 ``services`` として返されます。返されるファクトは Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:471 -msgid "The ``docker_swarm_service`` module no longer sets a defaults for the following options:" -msgstr "``docker_swarm_service`` モジュールでは、以下のオプションにデフォルトを設定しなくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:469 -msgid "``user``. Before, the default was ``root``." -msgstr "``user``。以前のデフォルトは ``root`` です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:470 -msgid "``update_delay``. Before, the default was ``10``." -msgstr "``update_delay``。以前のデフォルトは ``10`` です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:471 -msgid "``update_parallelism``. Before, the default was ``1``." -msgstr "``update_parallelism``。以前のデフォルトは ``1`` です。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:473 -msgid "``vmware_vm_facts`` used to return dict of dict with virtual machine's facts. Ansible 2.8 and onwards will return list of dict with virtual machine's facts. Please see module ``vmware_vm_facts`` documentation for example." -msgstr "``vmware_vm_facts`` は、仮想マシンのファクトを含む dict の dict を返すために使用されます。Ansible 2.8 以降では、仮想マシンのファクトを含む dict のリストを返します。例として、モジュール ``vmware_vm_facts`` のドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:476 -msgid "``vmware_guest_snapshot`` module used to return ``results``. Since Ansible 2.8 and onwards ``results`` is a reserved keyword, it is replaced by ``snapshot_results``. Please see module ``vmware_guest_snapshots`` documentation for example." -msgstr "``results`` を返すのに使用される ``vmware_guest_snapshot`` モジュール。Ansible 2.8 以降、``results`` は予約キーワードであるため、``snapshot_results`` に置き換えられています。たとえば、モジュール ``vmware_guest_snapshots`` ドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:479 -msgid "The ``panos`` modules have been deprecated in favor of using the Palo Alto Networks `Ansible Galaxy role `_. Contributions to the role can be made `here `_." -msgstr "``panos`` モジュールが非推奨となり、Palo Alto Networks の `Ansible Galaxy ロール `_ が使用されるようになりました。ロールへの貢献は `こちら `_ から行うことができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:483 -msgid "The ``ipa_user`` module originally always sent ``password`` to FreeIPA regardless of whether the password changed. Now the module only sends ``password`` if ``update_password`` is set to ``always``, which is the default." -msgstr "``ipa_user`` モジュールは、パスワードが変更されたかどうかに関わらず、常に ``password`` を FreeIPA に送信します。現在は、``update_password`` がデフォルトである ``always`` に設定されている場合のみ ``password`` を送信します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:485 -msgid "The ``win_psexec`` has deprecated the undocumented ``extra_opts`` module option. This will be removed in Ansible 2.10." -msgstr "``win_psexec`` では、文書化されていない ``extra_opts`` モジュールオプションが非推奨になりました。これは Ansible 2.10 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:487 -msgid "The ``win_nssm`` module has deprecated the following options in favor of using the ``win_service`` module to configure the service after installing it with ``win_nssm``: * ``dependencies``, use ``dependencies`` of ``win_service`` instead * ``start_mode``, use ``start_mode`` of ``win_service`` instead * ``user``, use ``username`` of ``win_service`` instead * ``password``, use ``password`` of ``win_service`` instead These options will be removed in Ansible 2.12." -msgstr "``win_nssm`` モジュールでは、以下のオプションが非推奨になり、``win_nssm`` を使用したインストール後のサービス設定に ``win_service`` を使用することが推奨されます。* ``dependencies`` の代わりに ``win_service`` の ``dependencies`` を使用します。 * ``start_mode`` の代わりに ``win_service`` の ``start_mode`` を使用します。 * ``user`` の代わりに ``win_service`` の ``username`` を使用します。 * ``password`` の代わりに ``win_service`` の ``password`` を使用します。このオプションは、Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:494 -msgid "The ``win_nssm`` module has also deprecated the ``start``, ``stop``, and ``restart`` values of the ``status`` option. You should use the ``win_service`` module to control the running state of the service. This will be removed in Ansible 2.12." -msgstr "``win_nssm`` モジュールでは、``status`` オプションの ``start``、``stop``、および ``restart`` の値も非推奨になりました。``win_service`` モジュールを使用して、サービスの実行状態を制御する必要があります。これは、Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:497 -msgid "The ``status`` module option for ``win_nssm`` has changed its default value to ``present``. Before, the default was ``start``. Consequently, the service is no longer started by default after creation with ``win_nssm``, and you should use the ``win_service`` module to start it if needed." -msgstr "``win_nssm`` の ``status`` モジュールオプションのデフォルト値が ``present`` に変更されました。以前のデフォルトは ``start`` でした。その結果、``win_nssm`` で作成したサービスはデフォルトでは開始されなくなり、必要に応じて ``win_service`` モジュールを使用してサービスを開始する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:501 -msgid "The ``app_parameters`` module option for ``win_nssm`` has been deprecated; use ``argument`` instead. This will be removed in Ansible 2.12." -msgstr "``win_nssm`` の ``app_parameters`` モジュールオプションは非推奨となります。代わりに ``argument`` を使用してください。このオプションは、Ansible 2.12 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:503 -msgid "The ``app_parameters_free_form`` module option for ``win_nssm`` has been aliased to the new ``arguments`` option." -msgstr "``win_nssm`` 用の ``app_parameters_free_form`` モジュールオプションは、新しい ``arguments`` オプションに対してエイリアスが設定されました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:505 -msgid "The ``win_dsc`` module will now validate the input options for a DSC resource. In previous versions invalid options would be ignored but are now not." -msgstr "``win_dsc`` モジュールは、DSC リソースの入力オプションを検証しました。以前のバージョンでは無効なオプションは無視されますが、今回は無視されません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:508 -msgid "The ``openssl_pkcs12`` module will now regenerate the pkcs12 file if there are differences between the file on disk and the parameters passed to the module." -msgstr "ディスク上のファイルと、モジュールに渡すパラメーターに違いがある場合は、``openssl_pkcs12`` モジュールが pkcs12 ファイルを再生成するようになります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:513 -msgid "Ansible no longer defaults to the ``paramiko`` connection plugin when using macOS as the control node. Ansible will now use the ``ssh`` connection plugin by default on a macOS control node. Since ``ssh`` supports connection persistence between tasks and playbook runs, it performs better than ``paramiko``. If you are using password authentication, you will need to install ``sshpass`` when using the ``ssh`` connection plugin. Or you can explicitly set the connection type to ``paramiko`` to maintain the pre-2.8 behavior on macOS." -msgstr "Ansible は、macOS を制御ノードとして使用する場合は、``paramiko`` connection プラグインをデフォルトで使用しなくなりました。Ansible は、macOS のコントロールノードではデフォルトで ``ssh`` connection プラグインを使用するようになりました。``ssh`` は、タスクと Playbook の実行間の接続持続性をサポートしているため、``paramiko`` よりもパフォーマンスが高くなります。パスワード認証を使用している場合は、``ssh`` connection プラグインを使用する際に ``sshpass`` をインストールする必要があります。または、接続タイプを明示的に ``paramiko`` に設定することで、macOS での 2.8 以前の動作を維持することができます。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:515 -msgid "Connection plugins have been standardized to allow use of ``ansible__user`` and ``ansible__password`` variables. Variables such as ``ansible__pass`` and ``ansible__username`` are treated with lower priority than the standardized names and may be deprecated in the future. In general, the ``ansible_user`` and ``ansible_password`` vars should be used unless there is a reason to use the connection-specific variables." -msgstr "connection プラグインは、``ansible__user`` 変数および ``ansible__password`` 変数を使用できるように標準化されました。``ansible__pass`` や ``ansible__username`` のような変数は、標準化された名前よりも優先度が低く扱われ、将来的には非推奨になる可能性があります。一般的には、接続専用の変数を使用する理由がない限り、``ansible_user`` と ``ansible_password`` の変数を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:522 -msgid "The ``powershell`` shell plugin now uses ``async_dir`` to define the async path for the results file and the default has changed to ``%USERPROFILE%\\.ansible_async``. To control this path now, either set the ``ansible_async_dir`` variable or the ``async_dir`` value in the ``powershell`` section of the config ini." -msgstr "``powershell`` シェルプラグインでは、結果ファイルの非同期パスの定義に ``async_dir`` を使用するようになり、デフォルトは ``%USERPROFILE%\\.ansible_async`` に変更になりました。このパスを制御するには、``ansible_async_dir`` 変数を設定するか、config ini の ``powershell`` セクションで ``async_dir`` の値を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:526 -msgid "Order of enabled inventory plugins (:ref:`INVENTORY_ENABLED`) has been updated, :ref:`auto ` is now before :ref:`yaml ` and :ref:`ini `." -msgstr "有効なインベントリープラグイン (:ref:`INVENTORY_ENABLED`) の順序が更新されました。:ref:`auto ` は :ref:`yaml ` および :ref:`ini ` の前に追加されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:528 -msgid "The private ``_options`` attribute has been removed from the ``CallbackBase`` class of callback plugins. If you have a third-party callback plugin which needs to access the command line arguments, use code like the following instead of trying to use ``self._options``:" -msgstr "``_options`` のプライベート属性は、コールバックプラグインの ``CallbackBase`` クラスから削除されました。コマンドライン引数にアクセスする必要のあるサードパーティー製 callback プラグインをお持ちの場合は、``self._options`` を使用する代わりに、以下のようなコードを使用してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:538 -msgid "``context.CLIARGS`` is a read-only dictionary so normal dictionary retrieval methods like ``CLIARGS.get('tags')`` and ``CLIARGS['tags']`` work as expected but you won't be able to modify the cli arguments at all." -msgstr "``context.CLIARGS`` は読み取り専用のディクショナリーであるため、``CLIARGS.get('tags')`` や``CLIARGS['tags']`` のような通常のディクショナリーの検索方法は期待通りに動作しますが、cli 引数を変更することは一切できません。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:542 -msgid "Play recap now counts ``ignored`` and ``rescued`` tasks as well as ``ok``, ``changed``, ``unreachable``, ``failed`` and ``skipped`` tasks, thanks to two additional stat counters in the ``default`` callback plugin. Tasks that fail and have ``ignore_errors: yes`` set are listed as ``ignored``. Tasks that fail and then execute a rescue section are listed as ``rescued``. Note that ``rescued`` tasks are no longer counted as ``failed`` as in Ansible 2.7 (and earlier)." -msgstr "プレイの要約では、``default`` callback プラグインの 2 つの追加スタットカウンターのおかげで、タスクは ``ignored`` と``rescued`` だけでなく、``ok``、``changed``、``unreachable``、``failed``、``skipped`` もカウントされるようになりました。失敗して``ignore_errors: yes`` が設定されたタスクは ``ignored`` としてリストアップされます。失敗してレスキューセクションを実行したタスクは、``rescued`` としてリストアップされます。なお、Ansible 2.7 (およびそれ以前) では、``rescued`` タスクは ``failed`` としてカウントされなくなりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:544 -msgid "``osx_say`` callback plugin was renamed into :ref:`say `." -msgstr "``osx_say`` callback プラグインの名前が :ref:`say ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:546 -msgid "Inventory plugins now support caching through cache plugins. To start using a cache plugin with your inventory see the section on caching in the :ref:`inventory guide`. To port a custom cache plugin to be compatible with inventory see :ref:`developer guide on cache plugins`." -msgstr "inventory プラグインが cache プラグインによるキャッシュ設定に対応しました。インベントリーで cache プラグインの使用を開始するには、「:ref:`inventory guide`」のキャッシュ設定に関するセクションを参照してください。カスタム cache プラグインをインベントリーと互換性があるように移植するには、「:ref:`developer guide on cache plugins`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:552 -msgid "Display class" -msgstr "クラスの表示" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:554 -msgid "As of Ansible 2.8, the ``Display`` class is now a \"singleton\". Instead of using ``__main__.display`` each file should import and instantiate ``ansible.utils.display.Display`` on its own." -msgstr "Ansible 2.8では、``Display`` クラスが「シングルトン」になりました。各ファイルは、``__main__.display`` を使用する代わりに ``ansible.utils.display.Display`` をインポートして独自にインスタンス化する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:557 -msgid "**OLD** In Ansible 2.7 (and earlier) the following was used to access the ``display`` object:" -msgstr "Ansible 2.7 以前における **以前の機能** ``display`` オブジェクトへのアクセスには以下が使用されていました。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:567 -msgid "**NEW** In Ansible 2.8 the following should be used:" -msgstr "**新機能** Ansible 2.8 では、以下を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:577 -msgid "The ``eos_config``, ``ios_config``, and ``nxos_config`` modules have removed the deprecated ``save`` and ``force`` parameters, use the ``save_when`` parameter to replicate their functionality." -msgstr "``eos_config`` モジュール、``ios_config`` モジュール、および ``nxos_config`` モジュールは非推奨の ``save`` パラメーターおよび ``force`` パラメーターを削除し、``save_when`` パラメーターを使用して機能を複製します。" - -#: ../../rst/porting_guides/porting_guide_2.8.rst:581 -msgid "The ``nxos_vrf_af`` module has removed the ``safi`` parameter. This parameter was deprecated in Ansible 2.4 and has had no impact on the module since then." -msgstr "``nxos_vrf_af`` モジュールは ``safi`` パラメーターを削除しました。このパラメーターは Ansible 2.4 で非推奨となり、それ以降モジュールに影響を及ぼしませんでした。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:6 -msgid "Ansible 2.9 Porting Guide" -msgstr "Ansible 2.9 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:8 -msgid "This section discusses the behavioral changes between Ansible 2.8 and Ansible 2.9." -msgstr "このセクションでは、Ansible 2.8 と Ansible 2.9 での動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:12 -msgid "We suggest you read this page along with `Ansible Changelog for 2.9 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible Changelog for 2.9 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:25 -msgid "``hash_behaviour`` now affects inventory sources. If you have it set to ``merge``, the data you get from inventory might change and you will have to update playbooks accordingly. If you're using the default setting (``overwrite``), you will see no changes. Inventory was ignoring this setting." -msgstr "``hash_behaviour`` インベントリーソースに影響します。これを ``merge`` に設定した場合は、インベントリーから取得したデータが変更され、Playbook が適切に更新される必要があります。デフォルト設定 (``overwrite``) を使用している場合は、変更されません。インベントリーは、この設定を無視していました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:28 -msgid "Loops" -msgstr "ループ" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:30 -msgid "Ansible 2.9 handles \"unsafe\" data more robustly, ensuring that data marked \"unsafe\" is not templated. In previous versions, Ansible recursively marked all data returned by the direct use of ``lookup()`` as \"unsafe\", but only marked structured data returned by indirect lookups using ``with_X`` style loops as \"unsafe\" if the returned elements were strings. Ansible 2.9 treats these two approaches consistently." -msgstr "Ansible 2.9 では、「unsafe」とマークされたデータがテンプレート化されないように、「unsafe」データをより強固に処理します。以前のバージョンでは、Ansible は``lookup()`` を直接使用して返されたすべてのデータを再帰的に「unsafe」と表示していましたが、``with_X`` スタイルのループを使用して間接的にルックアップして返された構造化データは、返される要素が文字列の場合にのみ「unsafe」と表示していました。Ansible 2.9 では、この 2 つのアプローチを一貫して扱います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:32 -msgid "As a result, if you use ``with_dict`` to return keys with templatable values, your templates may no longer work as expected in Ansible 2.9." -msgstr "その結果、``with_dict`` を使用して、テンプレート化できる値とキーが返されると、テンプレートは Ansible 2.9 では想定どおりに動作しなくなる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:34 -msgid "To allow the old behavior, switch from using ``with_X`` to using ``loop`` with a filter as described at :ref:`migrating_to_loop`." -msgstr "以前の動作を許可するには、「:ref:`migrating_to_loop`」で説明されているフィルターで使用する ``with_X`` を ``loop`` に切り替えてください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:39 -msgid "The location of the Galaxy token file has changed from ``~/.ansible_galaxy`` to ``~/.ansible/galaxy_token``. You can configure both path and file name with the :ref:`galaxy_token_path` config." -msgstr "Galaxy トークンファイルの場所が ``~/.ansible_galaxy`` から ``~/.ansible/galaxy_token`` に変更になりました。:ref:`galaxy_token_path` 設定で、パスとファイル名の両方を設定できます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:49 -msgid "Collection loader changes" -msgstr "コレクションローダーの変更" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:51 -msgid "The way to import a PowerShell or C# module util from a collection has changed in the Ansible 2.9 release. In Ansible 2.8 a util was imported with the following syntax:" -msgstr "Ansible 2.9 リリースでは、コレクションから PowerShell または C# モジュールユーティリティーをインポートする方法が変更されました。Ansible 2.8 では、以下の構文で ユーティリティーがインポートされました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:59 -msgid "In Ansible 2.9 this was changed to:" -msgstr "Ansible 2.9 では、上記は次のように変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:66 -msgid "The change in the collection import name also requires any C# util namespaces to be updated with the newer name format. This is more verbose but is designed to make sure we avoid plugin name conflicts across separate plugin types and to standardise how imports work in PowerShell with how Python modules work." -msgstr "また、コレクションのインポート名の変更に伴い、C# ユーティリティーの名前空間も新しい名前形式に更新する必要があります。新しい形式はより冗長になっていますが、他のプラグインタイプとの間でプラグイン名が競合しないようにするため、また PowerShell でのインポートの動作と Python モジュールの動作を標準化するためのものです。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:74 -msgid "The ``win_get_url`` and ``win_uri`` module now sends requests with a default ``User-Agent`` of ``ansible-httpget``. This can be changed by using the ``http_agent`` key." -msgstr "``win_get_url`` モジュールおよび ``win_uri`` モジュールは、``ansible-httpget`` のデフォルトの ``User-Agent`` で要求を送信するようになりました。これは ``http_agent`` キーを使用して変更できます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:75 -msgid "The ``apt`` module now honors ``update_cache=false`` while installing its own dependency and skips the cache update. Explicitly setting ``update_cache=true`` or omitting the param ``update_cache`` will result in a cache update while installing its own dependency." -msgstr "``apt`` モジュールは、自身の依存関係をインストールする際に ``update_cache=false`` を尊重し、キャッシュの更新をスキップするようになりました。``update_cache=true`` を明示的に設定するか、パラメーターの ``update_cache`` を省略すると、自身の依存関係をインストールしている間にキャッシュの更新が行われます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:77 -msgid "Version 2.9.12 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.9.13, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible." -msgstr "Ansible のバージョン 2.9.12 は、ユーザーがファイルベースのタスクで ``mode`` パラメーターを指定しなかった場合に、ファイルベースのタスクのデフォルトモードを ``0o600 & ~umask`` に変更しました。これは、再編成した CVE レポートに対する対応でした。その結果、2.9.13 ではモードの変更が元に戻され、以前のバージョンの Ansible と同様に、モードのデフォルトが ``0o666 & ~umask`` になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:78 -msgid "If you changed any tasks to specify less restrictive permissions while using 2.9.12, those changes will be unnecessary (but will do no harm) in 2.9.13." -msgstr "2.9.12 を使用する際に、より制限の少ないパーミッションを指定するようにタスクを変更した場合、2.9.13 ではその変更は不要になります (ただし、害はありません)。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:81 -msgid "``dnf`` and ``yum`` - As of version 2.9.13, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task." -msgstr "``dnf`` および ``yum`` - バージョン 2.9.13 より、``dnf`` モジュール (および ``dnf`` を使用する場合は ``yum`` アクション) がパッケージの GPG 署名を正しく検証するようになりました (CVE-2020-14365)。``Failed to validate GPG signature for [package name]`` のようなエラーが表示された場合は、使用している DNF リポジトリーやパッケージの GPG キーが正しくインポートされていることを確認してください。これを行う 1 つの方法として、``rpm_key`` モジュールの使用があります。推奨はしませんが、場合によっては GPG チェックを無効にする必要があるかもしれません。これは、``dnf`` タスクまたは ``yum`` タスクに ``disable_gpg_check: yes`` を明示的に追加することで実現できます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:85 -msgid "Renaming from ``_facts`` to ``_info``" -msgstr "``_facts`` から ``_info`` へ名前を変更します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:87 -msgid "Ansible 2.9 renamed a lot of modules from ``_facts`` to ``_info``, because the modules do not return :ref:`Ansible facts `. Ansible facts relate to a specific host. For example, the configuration of a network interface, the operating system on a unix server, and the list of packages installed on a Windows box are all Ansible facts. The renamed modules return values that are not unique to the host. For example, account information or region data for a cloud provider. Renaming these modules should provide more clarity about the types of return values each set of modules offers." -msgstr "Ansible 2.9 では、モジュールが :ref:`Ansible facts ` を返さないため、多くのモジュールの名前が ``_facts`` から``_info`` に変更なりました。Ansible のファクトは、特定のホストに関連するものです。たとえば、ネットワークインターフェースの設定、Unix サーバーのオペレーティングシステム、Windows ボックスにインストールされたパッケージのリストは、すべて Ansible のファクトです。名前が変更したモジュールは、ホストに固有ではない値を返します。クラウドプロバイダーのアカウント情報やリージョンデータなどです。これらのモジュールの名前を変更することで、モジュールの各セットが提供する戻り値の種類がより明確になるはずです。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:90 -msgid "Writing modules" -msgstr "モジュールの記述" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:92 -msgid "Module and module_utils files can now use relative imports to include other module_utils files. This is useful for shortening long import lines, especially in collections." -msgstr "モジュールおよび module_utils ファイルは、他の module_utils ファイルを含めるために相対インポートを使用できるようになりました。これは、特にコレクションにおいて、長いインポート行を短くするのに便利です。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:95 -msgid "Example of using a relative import in collections:" -msgstr "コレクションで相対インポートを使用する例:" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:105 -msgid "Modules and module_utils shipped with Ansible can use relative imports as well but the savings are smaller:" -msgstr "Ansible に同梱されているモジュールと module_utils では、相対インポートも使用できますが、短縮される量は少なくなります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:116 -msgid "Each single dot (``.``) represents one level of the tree (equivalent to ``../`` in filesystem relative links)." -msgstr "単一ドット (``.``) はそれぞれツリーの 1 レベル (ファイルシステムの相対リンクの ``../`` に相当) を表します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:118 -msgid "`The Python Relative Import Docs `_ go into more detail of how to write relative imports." -msgstr "`Python Relative Import ドキュメント `_ では、相対的なインポートをどのように書くか、より詳細に説明します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:126 -msgid "Apstra's ``aos_*`` modules. See the new modules at `https://github.com/apstra `_." -msgstr "Apstra の ``aos_*`` モジュール。新しいモジュールは `https://github.com/apstra `_ にあります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:127 -msgid "ec2_ami_find use :ref:`ec2_ami_facts ` instead." -msgstr "ec2_ami_find は、代わりに :ref:`ec2_ami_facts ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:128 -msgid "kubernetes use :ref:`k8s ` instead." -msgstr "kubernetes は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:129 -msgid "nxos_ip_interface use :ref:`nxos_l3_interface ` instead." -msgstr "nxos_ip_interface は、代わりに :ref:`nxos_l3_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:130 -msgid "nxos_portchannel use :ref:`nxos_linkagg ` instead." -msgstr "nxos_portchannel は、代わりに :ref:`nxos_linkagg ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:131 -msgid "nxos_switchport use :ref:`nxos_l2_interface ` instead." -msgstr "nxos_switchport は、代わりに :ref:`nxos_l2_interface ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:132 -msgid "oc use :ref:`k8s ` instead." -msgstr "oc は、代わりに :ref:`k8s ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:133 -msgid "panos_nat_policy use :ref:`panos_nat_rule ` instead." -msgstr "panos_nat_policy は、代わりに :ref:`panos_nat_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:134 -msgid "panos_security_policy use :ref:`panos_security_rule ` instead." -msgstr "panos_security_policy は、代わりに :ref:`panos_security_rule ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:135 -msgid "vsphere_guest use :ref:`vmware_guest ` instead." -msgstr "vsphere_guest は、代わりに :ref:`vmware_guest ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:141 -msgid "The following modules will be removed in Ansible 2.13. Please update update your playbooks accordingly." -msgstr "以下のモジュールは Ansible 2.13 で削除されます。Playbook を適宜更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:143 -msgid "cs_instance_facts use :ref:`cs_instance_info ` instead." -msgstr "cs_instance_facts は、代わりに :ref:`cs_instance_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:145 -msgid "cs_zone_facts use :ref:`cs_zone_info ` instead." -msgstr "cs_zone_facts は、代わりに :ref:`cs_zone_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:147 -msgid "digital_ocean_sshkey_facts use :ref:`digital_ocean_sshkey_info ` instead." -msgstr "digital_ocean_sshkey_facts は、代わりに :ref:`digital_ocean_sshkey_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:149 -msgid "eos_interface use :ref:`eos_interfaces ` instead." -msgstr "edos_interface は、代わりに :ref:`eos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:151 -msgid "eos_l2_interface use :ref:`eos_l2_interfaces ` instead." -msgstr "eos_l2_interface は、代わりに :ref:`eos_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:153 -msgid "eos_l3_interface use :ref:`eos_l3_interfaces ` instead." -msgstr "eos_l3_interface は、代わりに :ref:`eos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:155 -msgid "eos_linkagg use :ref:`eos_lag_interfaces ` instead." -msgstr "ems_linkagg は、代わりに :ref:`eos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:157 -msgid "eos_lldp_interface use :ref:`eos_lldp_interfaces ` instead." -msgstr "eds_lldp_interface は、代わりに :ref:`eos_lldp_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:159 -msgid "eos_vlan use :ref:`eos_vlans ` instead." -msgstr "eos_vlan は、代わりに :ref:`eos_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:161 -msgid "ios_interface use :ref:`ios_interfaces ` instead." -msgstr "ios_interface は、代わりに :ref:`ios_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:163 -msgid "ios_l2_interface use :ref:`ios_l2_interfaces ` instead." -msgstr "ios_l2_interface は、代わりに :ref:`ios_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:165 -msgid "ios_l3_interface use :ref:`ios_l3_interfaces ` instead." -msgstr "ios_l3_interface は、代わりに :ref:`ios_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:167 -msgid "ios_vlan use :ref:`ios_vlans ` instead." -msgstr "ios_vlan は、代わりに :ref:`ios_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:169 -msgid "iosxr_interface use :ref:`iosxr_interfaces ` instead." -msgstr "iosxr_interface は、代わりに :ref:`iosxr_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:171 -msgid "junos_interface use :ref:`junos_interfaces ` instead." -msgstr "junos_interface は、代わりに :ref:`junos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:173 -msgid "junos_l2_interface use :ref:`junos_l2_interfaces ` instead." -msgstr "junos_l2_interface は、代わりに :ref:`junos_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:175 -msgid "junos_l3_interface use :ref:`junos_l3_interfaces ` instead." -msgstr "junos_l3_interface は、代わりに :ref:`junos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:177 -msgid "junos_linkagg use :ref:`junos_lag_interfaces ` instead." -msgstr "junos_linkagg は、代わりに :ref:`junos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:179 -msgid "junos_lldp use :ref:`junos_lldp_global ` instead." -msgstr "junos_lldp は、代わりに :ref:`junos_lldp_global ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:181 -msgid "junos_lldp_interface use :ref:`junos_lldp_interfaces ` instead." -msgstr "junos_lldp_interface は、代わりに :ref:`junos_lldp_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:183 -msgid "junos_vlan use :ref:`junos_vlans ` instead." -msgstr "junos_vlan は、代わりに :ref:`junos_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:185 -msgid "lambda_facts use :ref:`lambda_info ` instead." -msgstr "lambda_facts は、代わりに :ref:`lambda_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:187 -msgid "na_ontap_gather_facts use :ref:`na_ontap_info ` instead." -msgstr "na_ontap_gather_facts は、代わりに :ref:`na_ontap_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:189 -msgid "net_banner use the platform-specific [netos]_banner modules instead." -msgstr "net_banner は、代わりにプラットフォーム固有の [netos]_banner モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:191 -msgid "net_interface use the new platform-specific [netos]_interfaces modules instead." -msgstr "net_interface は、代わりにプラットフォーム固有の新しい [netos]_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:193 -msgid "net_l2_interface use the new platform-specific [netos]_l2_interfaces modules instead." -msgstr "net_l2_interface は、代わりにプラットフォーム固有の新しい [netos]_l2_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:195 -msgid "net_l3_interface use the new platform-specific [netos]_l3_interfaces modules instead." -msgstr "net_l3_interface は、代わりにプラットフォーム固有の新しい [netos]_l3_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:197 -msgid "net_linkagg use the new platform-specific [netos]_lag modules instead." -msgstr "net_linkagg は、代わりにプラットフォーム固有の新しい [netos]_lag モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:199 -msgid "net_lldp use the new platform-specific [netos]_lldp_global modules instead." -msgstr "net_lldp は、代わりにプラットフォーム固有の新しい [netos]_lldp_global モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:201 -msgid "net_lldp_interface use the new platform-specific [netos]_lldp_interfaces modules instead." -msgstr "net_lldp_interface は、代わりにプラットフォーム固有の新しい [netos]_lldp_interfaces モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:203 -msgid "net_logging use the platform-specific [netos]_logging modules instead." -msgstr "net_logging は、代わりにプラットフォーム固有の [netos]_logging モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:205 -msgid "net_static_route use the platform-specific [netos]_static_route modules instead." -msgstr "net_static_route は、代わりにプラットフォーム固有の [netos]_static_route モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:207 -msgid "net_system use the platform-specific [netos]_system modules instead." -msgstr "net_system は、代わりにプラットフォーム固有の [netos]_system モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:209 -msgid "net_user use the platform-specific [netos]_user modules instead." -msgstr "net_user は、代わりにプラットフォーム固有の [netos]_user モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:211 -msgid "net_vlan use the new platform-specific [netos]_vlans modules instead." -msgstr "net_vlan は、代わりにプラットフォーム固有の新しい [netos]_vlans モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:213 -msgid "net_vrf use the platform-specific [netos]_vrf modules instead." -msgstr "net_vrf は、代わりにプラットフォーム固有の [netos]_vrf モジュールを使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:215 -msgid "nginx_status_facts use :ref:`nginx_status_info ` instead." -msgstr "nginx_status_facts は、代わりに :ref:`nginx_status_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:217 -msgid "nxos_interface use :ref:`nxos_interfaces ` instead." -msgstr "nxos_interface は、代わりに :ref:`nxos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:219 -msgid "nxos_l2_interface use :ref:`nxos_l2_interfaces ` instead." -msgstr "nxos_l2_interface は、代わりに :ref:`nxos_l2_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:221 -msgid "nxos_l3_interface use :ref:`nxos_l3_interfaces ` instead." -msgstr "nxos_l3_interface は、代わりに :ref:`nxos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:223 -msgid "nxos_linkagg use :ref:`nxos_lag_interfaces ` instead." -msgstr "nxos_linkagg は、代わりに :ref:`nxos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:225 -msgid "nxos_vlan use :ref:`nxos_vlans ` instead." -msgstr "nxos_vlan は、代わりに :ref:`nxos_vlans ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:227 -msgid "online_server_facts use :ref:`online_server_info ` instead." -msgstr "online_server_facts は、代わりに :ref:`online_server_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:229 -msgid "online_user_facts use :ref:`online_user_info ` instead." -msgstr "online_user_facts は、代わりに :ref:`online_user_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:231 -msgid "purefa_facts use :ref:`purefa_info ` instead." -msgstr "purefa_facts は、代わりに :ref:`purefa_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:233 -msgid "purefb_facts use :ref:`purefb_info ` instead." -msgstr "purefb_facts は、代わりに :ref:`purefb_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:235 -msgid "scaleway_image_facts use :ref:`scaleway_image_info ` instead." -msgstr "scaleway_image_facts は、代わりに :ref:`scaleway_image_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:237 -msgid "scaleway_ip_facts use :ref:`scaleway_ip_info ` instead." -msgstr "scaleway_ip_facts は、代わりに :ref:`scaleway_ip_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:239 -msgid "scaleway_organization_facts use :ref:`scaleway_organization_info ` instead." -msgstr "scaleway_organization_facts は、代わりに :ref:`scaleway_organization_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:241 -msgid "scaleway_security_group_facts use :ref:`scaleway_security_group_info ` instead." -msgstr "scaleway_security_group_facts は、代わりに :ref:`scaleway_security_group_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:243 -msgid "scaleway_server_facts use :ref:`scaleway_server_info ` instead." -msgstr "scaleway_server_facts は、代わりに :ref:`scaleway_server_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:245 -msgid "scaleway_snapshot_facts use :ref:`scaleway_snapshot_info ` instead." -msgstr "scaleway_snapshot_facts は、代わりに :ref:`scaleway_snapshot_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:247 -msgid "scaleway_volume_facts use :ref:`scaleway_volume_info ` instead." -msgstr "scaleway_volume_facts は、代わりに :ref:`scaleway_volume_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:249 -msgid "vcenter_extension_facts use :ref:`vcenter_extension_info ` instead." -msgstr "vcenter_extension_facts は、代わりに :ref:`vcenter_extension_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:251 -msgid "vmware_about_facts use :ref:`vmware_about_info ` instead." -msgstr "vmware_about_facts は、代わりに :ref:`vmware_about_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:253 -msgid "vmware_category_facts use :ref:`vmware_category_info ` instead." -msgstr "vmware_category_facts は、代わりに :ref:`vmware_category_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:255 -msgid "vmware_drs_group_facts use :ref:`vmware_drs_group_info ` instead." -msgstr "vmware_drs_group_facts は、代わりに :ref:`vmware_drs_group_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:257 -msgid "vmware_drs_rule_facts use :ref:`vmware_drs_rule_info ` instead." -msgstr "vmware_drs_rule_facts は、代わりに :ref:`vmware_drs_rule_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:259 -msgid "vmware_dvs_portgroup_facts use :ref:`vmware_dvs_portgroup_info ` instead." -msgstr "vmware_dvs_portgroup_facts は、代わりに :ref:`vmware_dvs_portgroup_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:261 -msgid "vmware_guest_boot_facts use :ref:`vmware_guest_boot_info ` instead." -msgstr "vmware_guest_boot_facts は、代わりに :ref:`vmware_guest_boot_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:263 -msgid "vmware_guest_customization_facts use :ref:`vmware_guest_customization_info ` instead." -msgstr "vmware_guest_customization_facts は、代わりに :ref:`vmware_guest_customization_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:265 -msgid "vmware_guest_disk_facts use :ref:`vmware_guest_disk_info ` instead." -msgstr "vmware_guest_disk_facts は、代わりに :ref:`vmware_guest_disk_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:267 -msgid "vmware_host_capability_facts use :ref:`vmware_host_capability_info ` instead." -msgstr "vmware_host_capability_facts は、代わりに :ref:`vmware_host_capability_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:269 -msgid "vmware_host_config_facts use :ref:`vmware_host_config_info ` instead." -msgstr "vmware_host_config_facts は、代わりに :ref:`vmware_host_config_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:271 -msgid "vmware_host_dns_facts use :ref:`vmware_host_dns_info ` instead." -msgstr "vmware_host_dns_facts は、代わりに :ref:`vmware_host_dns_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:273 -msgid "vmware_host_feature_facts use :ref:`vmware_host_feature_info ` instead." -msgstr "vmware_host_feature_facts は、代わりに :ref:`vmware_host_feature_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:275 -msgid "vmware_host_firewall_facts use :ref:`vmware_host_firewall_info ` instead." -msgstr "vmware_host_firewall_facts は、代わりに :ref:`vmware_host_firewall_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:277 -msgid "vmware_host_ntp_facts use :ref:`vmware_host_ntp_info ` instead." -msgstr "vmware_host_ntp_facts は、代わりに :ref:`vmware_host_ntp_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:279 -msgid "vmware_host_package_facts use :ref:`vmware_host_package_info ` instead." -msgstr "vmware_host_package_facts は、代わりに :ref:`vmware_host_package_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:281 -msgid "vmware_host_service_facts use :ref:`vmware_host_service_info ` instead." -msgstr "vmware_host_service_facts は、代わりに :ref:`vmware_host_service_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:283 -msgid "vmware_host_ssl_facts use :ref:`vmware_host_ssl_info ` instead." -msgstr "vmware_host_ssl_facts は、代わりに :ref:`vmware_host_ssl_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:285 -msgid "vmware_host_vmhba_facts use :ref:`vmware_host_vmhba_info ` instead." -msgstr "vmware_host_vmhba_facts は、代わりに :ref:`vmware_host_vmhba_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:287 -msgid "vmware_host_vmnic_facts use :ref:`vmware_host_vmnic_info ` instead." -msgstr "vmware_host_vmnic_facts は、代わりに :ref:`vmware_host_vmnic_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:289 -msgid "vmware_local_role_facts use :ref:`vmware_local_role_info ` instead." -msgstr "vmware_local_role_facts は、代わりに :ref:`vmware_local_role_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:291 -msgid "vmware_local_user_facts use :ref:`vmware_local_user_info ` instead." -msgstr "vmware_local_user_facts は、代わりに :ref:`vmware_local_user_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:293 -msgid "vmware_portgroup_facts use :ref:`vmware_portgroup_info ` instead." -msgstr "vmware_portgroup_facts は、代わりに :ref:`vmware_portgroup_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:295 -msgid "vmware_resource_pool_facts use :ref:`vmware_resource_pool_info ` instead." -msgstr "vmware_resource_pool_facts は、代わりに :ref:`vmware_resource_pool_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:297 -msgid "vmware_target_canonical_facts use :ref:`vmware_target_canonical_info ` instead." -msgstr "vmware_target_canonical_facts は、代わりに :ref:`vmware_target_canonical_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:299 -msgid "vmware_vmkernel_facts use :ref:`vmware_vmkernel_info ` instead." -msgstr "vmware_vmkernel_facts は、代わりに :ref:`vmware_vmkernel_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:301 -msgid "vmware_vswitch_facts use :ref:`vmware_vswitch_info ` instead." -msgstr "vmware_vswitch_facts は、代わりに :ref:`vmware_vswitch_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:303 -msgid "vultr_account_facts use :ref:`vultr_account_info ` instead." -msgstr "vultr_account_facts は、代わりに :ref:`vultr_account_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:305 -msgid "vultr_block_storage_facts use :ref:`vultr_block_storage_info ` instead." -msgstr "vultr_block_storage_facts は、代わりに :ref:`vultr_block_storage_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:307 -msgid "vultr_dns_domain_facts use :ref:`vultr_dns_domain_info ` instead." -msgstr "vultr_dns_domain_facts は、代わりに :ref:`vultr_dns_domain_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:309 -msgid "vultr_firewall_group_facts use :ref:`vultr_firewall_group_info ` instead." -msgstr "vultr_firewall_group_facts は、代わりに :ref:`vultr_firewall_group_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:311 -msgid "vultr_network_facts use :ref:`vultr_network_info ` instead." -msgstr "vultr_network_facts は、代わりに :ref:`vultr_network_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:313 -msgid "vultr_os_facts use :ref:`vultr_os_info ` instead." -msgstr "vultr_os_facts は、代わりに :ref:`vultr_os_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:315 -msgid "vultr_plan_facts use :ref:`vultr_plan_info ` instead." -msgstr "vultr_plan_facts は、代わりに :ref:`vultr_plan_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:317 -msgid "vultr_region_facts use :ref:`vultr_region_info ` instead." -msgstr "vultr_region_facts は、代わりに :ref:`vultr_region_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:319 -msgid "vultr_server_facts use :ref:`vultr_server_info ` instead." -msgstr "vultr_server_facts は、代わりに :ref:`vultr_server_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:321 -msgid "vultr_ssh_key_facts use :ref:`vultr_ssh_key_info ` instead." -msgstr "vultr_ssh_key_facts は、代わりに :ref:`vultr_ssh_key_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:323 -msgid "vultr_startup_script_facts use :ref:`vultr_startup_script_info ` instead." -msgstr "vultr_startup_script_facts は、代わりに :ref:`vultr_startup_script_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:325 -msgid "vultr_user_facts use :ref:`vultr_user_info ` instead." -msgstr "vultr_user_facts は、代わりに :ref:`vultr_user_info ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:327 -msgid "vyos_interface use :ref:`vyos_interfaces ` instead." -msgstr "vyos_interface は、代わりに :ref:`vyos_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:329 -msgid "vyos_l3_interface use :ref:`vyos_l3_interfaces ` instead." -msgstr "vyos_l3_interface は、代わりに :ref:`vyos_l3_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:331 -msgid "vyos_linkagg use :ref:`vyos_lag_interfaces ` instead." -msgstr "vyos_linkagg は、代わりに :ref:`vyos_lag_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:333 -msgid "vyos_lldp use :ref:`vyos_lldp_global ` instead." -msgstr "vyos_lldp は、代わりに :ref:`vyos_lldp_global ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:335 -msgid "vyos_lldp_interface use :ref:`vyos_lldp_interfaces ` instead." -msgstr "vyos_lldp_interface は、代わりに :ref:`vyos_lldp_interfaces ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:338 -msgid "The following functionality will be removed in Ansible 2.12. Please update update your playbooks accordingly." -msgstr "以下の機能は Ansible 2.12 で削除されます。それに伴い、Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:340 -msgid "``vmware_cluster`` DRS, HA and VSAN configuration; use :ref:`vmware_cluster_drs `, :ref:`vmware_cluster_ha ` and :ref:`vmware_cluster_vsan ` instead." -msgstr "``vmware_cluster`` の DRS、HA、および VSAN の設定。代わりに :ref:`vmware_cluster_drs `、:ref:`vmware_cluster_ha `、および :ref:`vmware_cluster_vsan ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:343 -msgid "The following functionality will be removed in Ansible 2.13. Please update update your playbooks accordingly." -msgstr "以下の機能は Ansible 2.13 では削除されます。それに伴い、Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:345 -msgid "``openssl_certificate`` deprecates the ``assertonly`` provider. Please see the :ref:`openssl_certificate ` documentation examples on how to replace the provider with the :ref:`openssl_certificate_info `, :ref:`openssl_csr_info `, :ref:`openssl_privatekey_info ` and :ref:`assert ` modules." -msgstr "``openssl_certificate`` は、``assertonly`` プロバイダーを非推奨にします。プロバイダーを :ref:`openssl_certificate_info ` モジュール、:ref:`openssl_csr_info ` モジュール、:ref:`openssl_privatekey_info ` モジュール、および :ref:`assert ` モジュールに置き換える方法は、:ref:`openssl_certificate ` のドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:352 -msgid "For the following modules, the PyOpenSSL-based backend ``pyopenssl`` has been deprecated and will be removed in Ansible 2.13:" -msgstr "以下のモジュールについては、PyOpenSSL ベースのバックエンド ``pyopenssl`` がすでに非推奨になっており、Ansible 2.13 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:355 -msgid ":ref:`get_certificate `" -msgstr ":ref:`get_certificate `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:356 -msgid ":ref:`openssl_certificate `" -msgstr ":ref:`openssl_certificate `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:357 -msgid ":ref:`openssl_certificate_info `" -msgstr ":ref:`openssl_certificate_info `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:358 -msgid ":ref:`openssl_csr `" -msgstr ":ref:`openssl_csr `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:359 -msgid ":ref:`openssl_csr_info `" -msgstr ":ref:`openssl_csr_info `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:360 -msgid ":ref:`openssl_privatekey `" -msgstr ":ref:`openssl_privatekey `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:361 -msgid ":ref:`openssl_privatekey_info `" -msgstr ":ref:`openssl_privatekey_info `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:362 -msgid ":ref:`openssl_publickey `" -msgstr ":ref:`openssl_publickey `" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:366 -msgid "Renamed modules" -msgstr "名前が変更になったモジュール" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:368 -msgid "The following modules have been renamed. The old name is deprecated and will be removed in Ansible 2.13. Please update update your playbooks accordingly." -msgstr "以下のモジュールの名称が変更になりました。古い名前は非推奨で、Ansible 2.13 で削除される予定です。それに応じて Playbook を更新してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:371 -msgid "The ``ali_instance_facts`` module was renamed to :ref:`ali_instance_info `." -msgstr "``ali_instance_facts`` モジュールの名前が :ref:`ali_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:372 -msgid "The ``aws_acm_facts`` module was renamed to :ref:`aws_acm_info `." -msgstr "``aws_acm_facts`` モジュールの名前が :ref:`aws_acm_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:373 -msgid "The ``aws_az_facts`` module was renamed to :ref:`aws_az_info `." -msgstr "``aws_az_facts`` モジュールの名前が :ref:`aws_az_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:374 -msgid "The ``aws_caller_facts`` module was renamed to :ref:`aws_caller_info `." -msgstr "``aws_caller_facts`` モジュールの名前が :ref:`aws_caller_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:375 -msgid "The ``aws_kms_facts`` module was renamed to :ref:`aws_kms_info `." -msgstr "``aws_kms_facts`` モジュールの名前が :ref:`aws_kms_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:376 -msgid "The ``aws_region_facts`` module was renamed to :ref:`aws_region_info `." -msgstr "``aws_region_facts`` モジュールの名前が :ref:`aws_region_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:377 -msgid "The ``aws_s3_bucket_facts`` module was renamed to :ref:`aws_s3_bucket_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``aws_s3_bucket_facts`` モジュールの名前が :ref:`aws_s3_bucket_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:380 -msgid "The ``aws_sgw_facts`` module was renamed to :ref:`aws_sgw_info `." -msgstr "``aws_sgw_facts`` モジュールの名前が :ref:`aws_sgw_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:381 -msgid "The ``aws_waf_facts`` module was renamed to :ref:`aws_waf_info `." -msgstr "``aws_waf_facts`` モジュールの名前が :ref:`aws_waf_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:382 -msgid "The ``azure_rm_aks_facts`` module was renamed to :ref:`azure_rm_aks_info `." -msgstr "``azure_rm_aks_facts`` モジュールの名前が :ref:`azure_rm_aks_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:383 -msgid "The ``azure_rm_aksversion_facts`` module was renamed to :ref:`azure_rm_aksversion_info `." -msgstr "``azure_rm_aksversion_facts`` モジュールの名前が :ref:`azure_rm_aksversion_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:384 -msgid "The ``azure_rm_applicationsecuritygroup_facts`` module was renamed to :ref:`azure_rm_applicationsecuritygroup_info `." -msgstr "``azure_rm_applicationsecuritygroup_facts`` モジュールの名前が :ref:`azure_rm_applicationsecuritygroup_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:385 -msgid "The ``azure_rm_appserviceplan_facts`` module was renamed to :ref:`azure_rm_appserviceplan_info `." -msgstr "``azure_rm_appserviceplan_facts`` モジュールの名前が :ref:`azure_rm_appserviceplan_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:386 -msgid "The ``azure_rm_automationaccount_facts`` module was renamed to :ref:`azure_rm_automationaccount_info `." -msgstr "``azure_rm_automationaccount_facts`` モジュールの名前が :ref:`azure_rm_automationaccount_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:387 -msgid "The ``azure_rm_autoscale_facts`` module was renamed to :ref:`azure_rm_autoscale_info `." -msgstr "``azure_rm_autoscale_facts`` モジュールの名前が :ref:`azure_rm_autoscale_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:388 -msgid "The ``azure_rm_availabilityset_facts`` module was renamed to :ref:`azure_rm_availabilityset_info `." -msgstr "``azure_rm_availabilityset_facts`` モジュールの名前が :ref:`azure_rm_availabilityset_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:389 -msgid "The ``azure_rm_cdnendpoint_facts`` module was renamed to :ref:`azure_rm_cdnendpoint_info `." -msgstr "``azure_rm_cdnendpoint_facts`` モジュールの名前が :ref:`azure_rm_cdnendpoint_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:390 -msgid "The ``azure_rm_cdnprofile_facts`` module was renamed to :ref:`azure_rm_cdnprofile_info `." -msgstr "``azure_rm_cdnprofile_facts`` モジュールの名前が :ref:`azure_rm_cdnprofile_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:391 -msgid "The ``azure_rm_containerinstance_facts`` module was renamed to :ref:`azure_rm_containerinstance_info `." -msgstr "``azure_rm_containerinstance_facts`` モジュールの名前が :ref:`azure_rm_containerinstance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:392 -msgid "The ``azure_rm_containerregistry_facts`` module was renamed to :ref:`azure_rm_containerregistry_info `." -msgstr "``azure_rm_containerregistry_facts`` モジュールの名前が :ref:`azure_rm_containerregistry_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:393 -msgid "The ``azure_rm_cosmosdbaccount_facts`` module was renamed to :ref:`azure_rm_cosmosdbaccount_info `." -msgstr "``azure_rm_cosmosdbaccount_facts`` モジュールの名前が :ref:`azure_rm_cosmosdbaccount_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:394 -msgid "The ``azure_rm_deployment_facts`` module was renamed to :ref:`azure_rm_deployment_info `." -msgstr "``azure_rm_deployment_facts`` モジュールの名前が :ref:`azure_rm_deployment_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:395 -msgid "The ``azure_rm_resourcegroup_facts`` module was renamed to :ref:`azure_rm_resourcegroup_info `." -msgstr "``azure_rm_resourcegroup_facts`` モジュールの名前が :ref:`azure_rm_resourcegroup_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:396 -msgid "The ``bigip_device_facts`` module was renamed to :ref:`bigip_device_info `." -msgstr "``bigip_device_facts`` モジュールの名前が :ref:`bigip_device_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:397 -msgid "The ``bigiq_device_facts`` module was renamed to :ref:`bigiq_device_info `." -msgstr "``bigiq_device_facts`` モジュールの名前が :ref:`bigiq_device_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:398 -msgid "The ``cloudformation_facts`` module was renamed to :ref:`cloudformation_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``cloudformation_facts`` モジュールの名前が :ref:`cloudformation_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:401 -msgid "The ``cloudfront_facts`` module was renamed to :ref:`cloudfront_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``cloudfront_facts`` モジュールの名前が :ref:`cloudfront_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:404 -msgid "The ``cloudwatchlogs_log_group_facts`` module was renamed to :ref:`cloudwatchlogs_log_group_info `." -msgstr "``cloudwatchlogs_log_group_facts`` モジュールの名前が :ref:`cloudwatchlogs_log_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:405 -msgid "The ``digital_ocean_account_facts`` module was renamed to :ref:`digital_ocean_account_info `." -msgstr "``digital_ocean_account_facts`` モジュールの名前が :ref:`digital_ocean_account_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:406 -msgid "The ``digital_ocean_certificate_facts`` module was renamed to :ref:`digital_ocean_certificate_info `." -msgstr "``digital_ocean_certificate_facts`` モジュールの名前が :ref:`digital_ocean_certificate_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:407 -msgid "The ``digital_ocean_domain_facts`` module was renamed to :ref:`digital_ocean_domain_info `." -msgstr "``digital_ocean_domain_facts`` モジュールの名前が :ref:`digital_ocean_domain_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:408 -msgid "The ``digital_ocean_firewall_facts`` module was renamed to :ref:`digital_ocean_firewall_info `." -msgstr "``digital_ocean_firewall_facts`` モジュールの名前が :ref:`digital_ocean_firewall_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:409 -msgid "The ``digital_ocean_floating_ip_facts`` module was renamed to :ref:`digital_ocean_floating_ip_info `." -msgstr "``digital_ocean_floating_ip_facts`` モジュールの名前が :ref:`digital_ocean_floating_ip_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:410 -msgid "The ``digital_ocean_image_facts`` module was renamed to :ref:`digital_ocean_image_info `." -msgstr "``digital_ocean_image_facts`` モジュールの名前が :ref:`digital_ocean_image_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:411 -msgid "The ``digital_ocean_load_balancer_facts`` module was renamed to :ref:`digital_ocean_load_balancer_info `." -msgstr "``digital_ocean_load_balancer_facts`` モジュールの名前が :ref:`digital_ocean_load_balancer_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:412 -msgid "The ``digital_ocean_region_facts`` module was renamed to :ref:`digital_ocean_region_info `." -msgstr "``digital_ocean_region_facts`` モジュールの名前が :ref:`digital_ocean_region_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:413 -msgid "The ``digital_ocean_size_facts`` module was renamed to :ref:`digital_ocean_size_info `." -msgstr "``digital_ocean_size_facts`` モジュールの名前が :ref:`digital_ocean_size_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:414 -msgid "The ``digital_ocean_snapshot_facts`` module was renamed to :ref:`digital_ocean_snapshot_info `." -msgstr "``digital_ocean_snapshot_facts`` モジュールの名前が :ref:`digital_ocean_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:415 -msgid "The ``digital_ocean_tag_facts`` module was renamed to :ref:`digital_ocean_tag_info `." -msgstr "``digital_ocean_tag_facts`` モジュールの名前が :ref:`digital_ocean_tag_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:416 -msgid "The ``digital_ocean_volume_facts`` module was renamed to :ref:`digital_ocean_volume_info `." -msgstr "``digital_ocean_volume_facts`` モジュールの名前が :ref:`digital_ocean_volume_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:417 -msgid "The ``ec2_ami_facts`` module was renamed to :ref:`ec2_ami_info `." -msgstr "``ec2_ami_facts`` モジュールの名前が :ref:`ec2_ami_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:418 -msgid "The ``ec2_asg_facts`` module was renamed to :ref:`ec2_asg_info `." -msgstr "``ec2_asg_facts`` モジュールの名前が :ref:`ec2_asg_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:419 -msgid "The ``ec2_customer_gateway_facts`` module was renamed to :ref:`ec2_customer_gateway_info `." -msgstr "``ec2_customer_gateway_facts`` モジュールの名前が :ref:`ec2_customer_gateway_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:420 -msgid "The ``ec2_eip_facts`` module was renamed to :ref:`ec2_eip_info `." -msgstr "``ec2_eip_facts`` モジュールの名前が :ref:`ec2_eip_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:421 -msgid "The ``ec2_elb_facts`` module was renamed to :ref:`ec2_elb_info `." -msgstr "``ec2_elb_facts`` モジュールの名前が :ref:`ec2_elb_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:422 -msgid "The ``ec2_eni_facts`` module was renamed to :ref:`ec2_eni_info `." -msgstr "``ec2_eni_facts`` モジュールの名前が :ref:`ec2_eni_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:423 -msgid "The ``ec2_group_facts`` module was renamed to :ref:`ec2_group_info `." -msgstr "``ec2_group_facts`` モジュールの名前が :ref:`ec2_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:424 -msgid "The ``ec2_instance_facts`` module was renamed to :ref:`ec2_instance_info `." -msgstr "``ec2_instance_facts`` モジュールの名前が :ref:`ec2_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:425 -msgid "The ``ec2_lc_facts`` module was renamed to :ref:`ec2_lc_info `." -msgstr "``ec2_lc_facts`` モジュールの名前が :ref:`ec2_lc_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:426 -msgid "The ``ec2_placement_group_facts`` module was renamed to :ref:`ec2_placement_group_info `." -msgstr "``ec2_placement_group_facts`` モジュールの名前が :ref:`ec2_placement_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:427 -msgid "The ``ec2_snapshot_facts`` module was renamed to :ref:`ec2_snapshot_info `." -msgstr "``ec2_snapshot_facts`` モジュールの名前が :ref:`ec2_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:428 -msgid "The ``ec2_vol_facts`` module was renamed to :ref:`ec2_vol_info `." -msgstr "``ec2_vol_facts`` モジュールの名前が :ref:`ec2_vol_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:429 -msgid "The ``ec2_vpc_dhcp_option_facts`` module was renamed to :ref:`ec2_vpc_dhcp_option_info `." -msgstr "``ec2_vpc_dhcp_option_facts`` モジュールの名前が :ref:`ec2_vpc_dhcp_option_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:430 -msgid "The ``ec2_vpc_endpoint_facts`` module was renamed to :ref:`ec2_vpc_endpoint_info `." -msgstr "``ec2_vpc_endpoint_facts`` モジュールの名前が :ref:`ec2_vpc_endpoint_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:431 -msgid "The ``ec2_vpc_igw_facts`` module was renamed to :ref:`ec2_vpc_igw_info `." -msgstr "``ec2_vpc_igw_facts`` モジュールの名前が :ref:`ec2_vpc_igw_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:432 -msgid "The ``ec2_vpc_nacl_facts`` module was renamed to :ref:`ec2_vpc_nacl_info `." -msgstr "``ec2_vpc_nacl_facts`` モジュールの名前が :ref:`ec2_vpc_nacl_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:433 -msgid "The ``ec2_vpc_nat_gateway_facts`` module was renamed to :ref:`ec2_vpc_nat_gateway_info `." -msgstr "``ec2_vpc_nat_gateway_facts`` モジュールの名前が :ref:`ec2_vpc_nat_gateway_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:434 -msgid "The ``ec2_vpc_net_facts`` module was renamed to :ref:`ec2_vpc_net_info `." -msgstr "``ec2_vpc_net_facts`` モジュールの名前が :ref:`ec2_vpc_net_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:435 -msgid "The ``ec2_vpc_peering_facts`` module was renamed to :ref:`ec2_vpc_peering_info `." -msgstr "``ec2_vpc_peering_facts`` モジュールの名前が :ref:`ec2_vpc_peering_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:436 -msgid "The ``ec2_vpc_route_table_facts`` module was renamed to :ref:`ec2_vpc_route_table_info `." -msgstr "``ec2_vpc_route_table_facts`` モジュールの名前が :ref:`ec2_vpc_route_table_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:437 -msgid "The ``ec2_vpc_subnet_facts`` module was renamed to :ref:`ec2_vpc_subnet_info `." -msgstr "``ec2_vpc_subnet_facts`` モジュールの名前が :ref:`ec2_vpc_subnet_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:438 -msgid "The ``ec2_vpc_vgw_facts`` module was renamed to :ref:`ec2_vpc_vgw_info `." -msgstr "``ec2_vpc_vgw_facts`` モジュールの名前が :ref:`ec2_vpc_vgw_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:439 -msgid "The ``ec2_vpc_vpn_facts`` module was renamed to :ref:`ec2_vpc_vpn_info `." -msgstr "``ec2_vpc_vpn_facts`` モジュールの名前が :ref:`ec2_vpc_vpn_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:440 -msgid "The ``ecs_service_facts`` module was renamed to :ref:`ecs_service_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ecs_service_facts`` モジュールの名前が :ref:`ecs_service_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:443 -msgid "The ``ecs_taskdefinition_facts`` module was renamed to :ref:`ecs_taskdefinition_info `." -msgstr "``ecs_taskdefinition_facts`` モジュールの名前が :ref:`ecs_taskdefinition_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:444 -msgid "The ``efs_facts`` module was renamed to :ref:`efs_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``efs_facts`` モジュールの名前が :ref:`efs_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:447 -msgid "The ``elasticache_facts`` module was renamed to :ref:`elasticache_info `." -msgstr "``elasticache_facts`` モジュールの名前が :ref:`elasticache_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:448 -msgid "The ``elb_application_lb_facts`` module was renamed to :ref:`elb_application_lb_info `." -msgstr "``elb_application_lb_facts`` モジュールの名前が :ref:`elb_application_lb_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:449 -msgid "The ``elb_classic_lb_facts`` module was renamed to :ref:`elb_classic_lb_info `." -msgstr "``elb_classic_lb_facts`` モジュールの名前が :ref:`elb_classic_lb_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:450 -msgid "The ``elb_target_facts`` module was renamed to :ref:`elb_target_info `." -msgstr "``elb_target_facts`` モジュールの名前が :ref:`elb_target_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:451 -msgid "The ``elb_target_group_facts`` module was renamed to :ref:`elb_target_group_info `." -msgstr "``elb_target_group_facts`` モジュールの名前が :ref:`elb_target_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:452 -msgid "The ``gcp_bigquery_dataset_facts`` module was renamed to :ref:`gcp_bigquery_dataset_info `." -msgstr "``gcp_bigquery_dataset_facts`` モジュールの名前が :ref:`gcp_bigquery_dataset_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:453 -msgid "The ``gcp_bigquery_table_facts`` module was renamed to :ref:`gcp_bigquery_table_info `." -msgstr "``gcp_bigquery_table_facts`` モジュールの名前が :ref:`gcp_bigquery_table_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:454 -msgid "The ``gcp_cloudbuild_trigger_facts`` module was renamed to :ref:`gcp_cloudbuild_trigger_info `." -msgstr "``gcp_cloudbuild_trigger_facts`` モジュールの名前が :ref:`gcp_cloudbuild_trigger_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:455 -msgid "The ``gcp_compute_address_facts`` module was renamed to :ref:`gcp_compute_address_info `." -msgstr "``gcp_compute_address_facts`` モジュールの名前が :ref:`gcp_compute_address_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:456 -msgid "The ``gcp_compute_backend_bucket_facts`` module was renamed to :ref:`gcp_compute_backend_bucket_info `." -msgstr "``gcp_compute_backend_bucket_facts`` モジュールの名前が :ref:`gcp_compute_backend_bucket_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:457 -msgid "The ``gcp_compute_backend_service_facts`` module was renamed to :ref:`gcp_compute_backend_service_info `." -msgstr "``gcp_compute_backend_service_facts`` モジュールの名前が :ref:`gcp_compute_backend_service_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:458 -msgid "The ``gcp_compute_disk_facts`` module was renamed to :ref:`gcp_compute_disk_info `." -msgstr "``gcp_compute_disk_facts`` モジュールの名前が :ref:`gcp_compute_disk_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:459 -msgid "The ``gcp_compute_firewall_facts`` module was renamed to :ref:`gcp_compute_firewall_info `." -msgstr "``gcp_compute_firewall_facts`` モジュールの名前が :ref:`gcp_compute_firewall_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:460 -msgid "The ``gcp_compute_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_forwarding_rule_info `." -msgstr "``gcp_compute_forwarding_rule_facts`` モジュールの名前が :ref:`gcp_compute_forwarding_rule_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:461 -msgid "The ``gcp_compute_global_address_facts`` module was renamed to :ref:`gcp_compute_global_address_info `." -msgstr "``gcp_compute_global_address_facts`` モジュールの名前が :ref:`gcp_compute_global_address_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:462 -msgid "The ``gcp_compute_global_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_global_forwarding_rule_info `." -msgstr "``gcp_compute_global_forwarding_rule_facts`` モジュールの名前が :ref:`gcp_compute_global_forwarding_rule_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:463 -msgid "The ``gcp_compute_health_check_facts`` module was renamed to :ref:`gcp_compute_health_check_info `." -msgstr "``gcp_compute_health_check_facts`` モジュールの名前が :ref:`gcp_compute_health_check_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:464 -msgid "The ``gcp_compute_http_health_check_facts`` module was renamed to :ref:`gcp_compute_http_health_check_info `." -msgstr "``gcp_compute_http_health_check_facts`` モジュールの名前が :ref:`gcp_compute_http_health_check_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:465 -msgid "The ``gcp_compute_https_health_check_facts`` module was renamed to :ref:`gcp_compute_https_health_check_info `." -msgstr "``gcp_compute_https_health_check_facts`` モジュールの名前が :ref:`gcp_compute_https_health_check_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:466 -msgid "The ``gcp_compute_image_facts`` module was renamed to :ref:`gcp_compute_image_info `." -msgstr "``gcp_compute_image_facts`` モジュールの名前が :ref:`gcp_compute_image_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:467 -msgid "The ``gcp_compute_instance_facts`` module was renamed to :ref:`gcp_compute_instance_info `." -msgstr "``gcp_compute_instance_facts`` モジュールの名前が :ref:`gcp_compute_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:468 -msgid "The ``gcp_compute_instance_group_facts`` module was renamed to :ref:`gcp_compute_instance_group_info `." -msgstr "``gcp_compute_instance_group_facts`` モジュールの名前が :ref:`gcp_compute_instance_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:469 -msgid "The ``gcp_compute_instance_group_manager_facts`` module was renamed to :ref:`gcp_compute_instance_group_manager_info `." -msgstr "``gcp_compute_instance_group_manager_facts`` モジュールの名前が :ref:`gcp_compute_instance_group_manager_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:470 -msgid "The ``gcp_compute_instance_template_facts`` module was renamed to :ref:`gcp_compute_instance_template_info `." -msgstr "``gcp_compute_instance_template_facts`` モジュールの名前が :ref:`gcp_compute_instance_template_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:471 -msgid "The ``gcp_compute_interconnect_attachment_facts`` module was renamed to :ref:`gcp_compute_interconnect_attachment_info `." -msgstr "``gcp_compute_interconnect_attachment_facts`` モジュールの名前が :ref:`gcp_compute_interconnect_attachment_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:472 -msgid "The ``gcp_compute_network_facts`` module was renamed to :ref:`gcp_compute_network_info `." -msgstr "``gcp_compute_network_facts`` モジュールの名前が :ref:`gcp_compute_network_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:473 -msgid "The ``gcp_compute_region_disk_facts`` module was renamed to :ref:`gcp_compute_region_disk_info `." -msgstr "``gcp_compute_region_disk_facts`` モジュールの名前が :ref:`gcp_compute_region_disk_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:474 -msgid "The ``gcp_compute_route_facts`` module was renamed to :ref:`gcp_compute_route_info `." -msgstr "``gcp_compute_route_facts`` モジュールの名前が :ref:`gcp_compute_route_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:475 -msgid "The ``gcp_compute_router_facts`` module was renamed to :ref:`gcp_compute_router_info `." -msgstr "``gcp_compute_router_facts`` モジュールの名前が :ref:`gcp_compute_router_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:476 -msgid "The ``gcp_compute_ssl_certificate_facts`` module was renamed to :ref:`gcp_compute_ssl_certificate_info `." -msgstr "``gcp_compute_ssl_certificate_facts`` モジュールの名前が :ref:`gcp_compute_ssl_certificate_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:477 -msgid "The ``gcp_compute_ssl_policy_facts`` module was renamed to :ref:`gcp_compute_ssl_policy_info `." -msgstr "``gcp_compute_ssl_policy_facts`` モジュールの名前が :ref:`gcp_compute_ssl_policy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:478 -msgid "The ``gcp_compute_subnetwork_facts`` module was renamed to :ref:`gcp_compute_subnetwork_info `." -msgstr "``gcp_compute_subnetwork_facts`` モジュールの名前が :ref:`gcp_compute_subnetwork_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:479 -msgid "The ``gcp_compute_target_http_proxy_facts`` module was renamed to :ref:`gcp_compute_target_http_proxy_info `." -msgstr "``gcp_compute_target_http_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_http_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:480 -msgid "The ``gcp_compute_target_https_proxy_facts`` module was renamed to :ref:`gcp_compute_target_https_proxy_info `." -msgstr "``gcp_compute_target_https_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_https_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:481 -msgid "The ``gcp_compute_target_pool_facts`` module was renamed to :ref:`gcp_compute_target_pool_info `." -msgstr "``gcp_compute_target_pool_facts`` モジュールの名前が :ref:`gcp_compute_target_pool_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:482 -msgid "The ``gcp_compute_target_ssl_proxy_facts`` module was renamed to :ref:`gcp_compute_target_ssl_proxy_info `." -msgstr "``gcp_compute_target_ssl_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_ssl_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:483 -msgid "The ``gcp_compute_target_tcp_proxy_facts`` module was renamed to :ref:`gcp_compute_target_tcp_proxy_info `." -msgstr "``gcp_compute_target_tcp_proxy_facts`` モジュールの名前が :ref:`gcp_compute_target_tcp_proxy_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:484 -msgid "The ``gcp_compute_target_vpn_gateway_facts`` module was renamed to :ref:`gcp_compute_target_vpn_gateway_info `." -msgstr "``gcp_compute_target_vpn_gateway_facts`` モジュールの名前が :ref:`gcp_compute_target_vpn_gateway_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:485 -msgid "The ``gcp_compute_url_map_facts`` module was renamed to :ref:`gcp_compute_url_map_info `." -msgstr "``gcp_compute_url_map_facts`` モジュールの名前が :ref:`gcp_compute_url_map_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:486 -msgid "The ``gcp_compute_vpn_tunnel_facts`` module was renamed to :ref:`gcp_compute_vpn_tunnel_info `." -msgstr "``gcp_compute_vpn_tunnel_facts`` モジュールの名前が :ref:`gcp_compute_vpn_tunnel_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:487 -msgid "The ``gcp_container_cluster_facts`` module was renamed to :ref:`gcp_container_cluster_info `." -msgstr "``gcp_container_cluster_facts`` モジュールの名前が :ref:`gcp_container_cluster_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:488 -msgid "The ``gcp_container_node_pool_facts`` module was renamed to :ref:`gcp_container_node_pool_info `." -msgstr "``gcp_container_node_pool_facts`` モジュールの名前が :ref:`gcp_container_node_pool_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:489 -msgid "The ``gcp_dns_managed_zone_facts`` module was renamed to :ref:`gcp_dns_managed_zone_info `." -msgstr "``gcp_dns_managed_zone_facts`` モジュールの名前が :ref:`gcp_dns_managed_zone_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:490 -msgid "The ``gcp_dns_resource_record_set_facts`` module was renamed to :ref:`gcp_dns_resource_record_set_info `." -msgstr "``gcp_dns_resource_record_set_facts`` モジュールの名前が :ref:`gcp_dns_resource_record_set_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:491 -msgid "The ``gcp_iam_role_facts`` module was renamed to :ref:`gcp_iam_role_info `." -msgstr "``gcp_iam_role_facts`` モジュールの名前が :ref:`gcp_iam_role_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:492 -msgid "The ``gcp_iam_service_account_facts`` module was renamed to :ref:`gcp_iam_service_account_info `." -msgstr "``gcp_iam_service_account_facts`` モジュールの名前が :ref:`gcp_iam_service_account_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:493 -msgid "The ``gcp_pubsub_subscription_facts`` module was renamed to :ref:`gcp_pubsub_subscription_info `." -msgstr "``gcp_pubsub_subscription_facts`` モジュールの名前が :ref:`gcp_pubsub_subscription_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:494 -msgid "The ``gcp_pubsub_topic_facts`` module was renamed to :ref:`gcp_pubsub_topic_info `." -msgstr "``gcp_pubsub_topic_facts`` モジュールの名前が :ref:`gcp_pubsub_topic_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:495 -msgid "The ``gcp_redis_instance_facts`` module was renamed to :ref:`gcp_redis_instance_info `." -msgstr "``gcp_redis_instance_facts`` モジュールの名前が :ref:`gcp_redis_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:496 -msgid "The ``gcp_resourcemanager_project_facts`` module was renamed to :ref:`gcp_resourcemanager_project_info `." -msgstr "``gcp_resourcemanager_project_facts`` モジュールの名前が :ref:`gcp_resourcemanager_project_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:497 -msgid "The ``gcp_sourcerepo_repository_facts`` module was renamed to :ref:`gcp_sourcerepo_repository_info `." -msgstr "``gcp_sourcerepo_repository_facts`` モジュールの名前が :ref:`gcp_sourcerepo_repository_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:498 -msgid "The ``gcp_spanner_database_facts`` module was renamed to :ref:`gcp_spanner_database_info `." -msgstr "``gcp_spanner_database_facts`` モジュールの名前が :ref:`gcp_spanner_database_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:499 -msgid "The ``gcp_spanner_instance_facts`` module was renamed to :ref:`gcp_spanner_instance_info `." -msgstr "``gcp_spanner_instance_facts`` モジュールの名前が :ref:`gcp_spanner_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:500 -msgid "The ``gcp_sql_database_facts`` module was renamed to :ref:`gcp_sql_database_info `." -msgstr "``gcp_sql_database_facts`` モジュールの名前が :ref:`gcp_sql_database_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:501 -msgid "The ``gcp_sql_instance_facts`` module was renamed to :ref:`gcp_sql_instance_info `." -msgstr "``gcp_sql_instance_facts`` モジュールの名前が :ref:`gcp_sql_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:502 -msgid "The ``gcp_sql_user_facts`` module was renamed to :ref:`gcp_sql_user_info `." -msgstr "``gcp_sql_user_facts`` モジュールの名前が :ref:`gcp_sql_user_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:503 -msgid "The ``gcp_tpu_node_facts`` module was renamed to :ref:`gcp_tpu_node_info `." -msgstr "``gcp_tpu_node_facts`` モジュールの名前が :ref:`gcp_tpu_node_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:504 -msgid "The ``gcpubsub_facts`` module was renamed to :ref:`gcpubsub_info `." -msgstr "``gcpubsub_facts`` モジュールの名前が :ref:`gcpubsub_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:505 -msgid "The ``github_webhook_facts`` module was renamed to :ref:`github_webhook_info `." -msgstr "``github_webhook_facts`` モジュールの名前が :ref:`github_webhook_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:506 -msgid "The ``gluster_heal_facts`` module was renamed to :ref:`gluster_heal_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``gluster_heal_facts`` モジュールの名前が :ref:`gluster_heal_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:509 -msgid "The ``hcloud_datacenter_facts`` module was renamed to :ref:`hcloud_datacenter_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_datacenter_facts`` モジュールの名前が :ref:`hcloud_datacenter_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:512 -msgid "The ``hcloud_floating_ip_facts`` module was renamed to :ref:`hcloud_floating_ip_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_floating_ip_facts`` モジュールの名前が :ref:`hcloud_floating_ip_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:515 -msgid "The ``hcloud_image_facts`` module was renamed to :ref:`hcloud_image_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_image_facts`` モジュールの名前が :ref:`hcloud_image_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:518 -msgid "The ``hcloud_location_facts`` module was renamed to :ref:`hcloud_location_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_location_facts`` モジュールの名前が :ref:`hcloud_location_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:521 -msgid "The ``hcloud_server_facts`` module was renamed to :ref:`hcloud_server_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_server_facts`` モジュールの名前が :ref:`hcloud_server_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:524 -msgid "The ``hcloud_server_type_facts`` module was renamed to :ref:`hcloud_server_type_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_server_type_facts`` モジュールの名前が :ref:`hcloud_server_type_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:527 -msgid "The ``hcloud_ssh_key_facts`` module was renamed to :ref:`hcloud_ssh_key_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_ssh_key_facts`` モジュールの名前が :ref:`hcloud_ssh_key_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:530 -msgid "The ``hcloud_volume_facts`` module was renamed to :ref:`hcloud_volume_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hcloud_volume_facts`` モジュールの名前が :ref:`hcloud_volume_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:533 -msgid "The ``hpilo_facts`` module was renamed to :ref:`hpilo_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``hpilo_facts`` モジュールの名前が :ref:`hpilo_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:536 -msgid "The ``iam_mfa_device_facts`` module was renamed to :ref:`iam_mfa_device_info `." -msgstr "``iam_mfa_device_facts`` モジュールの名前が :ref:`iam_mfa_device_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:537 -msgid "The ``iam_role_facts`` module was renamed to :ref:`iam_role_info `." -msgstr "``iam_role_facts`` モジュールの名前が :ref:`iam_role_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:538 -msgid "The ``iam_server_certificate_facts`` module was renamed to :ref:`iam_server_certificate_info `." -msgstr "``iam_server_certificate_facts`` モジュールの名前が :ref:`iam_server_certificate_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:539 -msgid "The ``idrac_redfish_facts`` module was renamed to :ref:`idrac_redfish_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``idrac_redfish_facts`` モジュールの名前が :ref:`idrac_redfish_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:542 -msgid "The ``intersight_facts`` module was renamed to :ref:`intersight_info `." -msgstr "``intersight_facts`` モジュールの名前が :ref:`intersight_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:543 -msgid "The ``jenkins_job_facts`` module was renamed to :ref:`jenkins_job_info `." -msgstr "``jenkins_job_facts`` モジュールの名前が :ref:`jenkins_job_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:544 -msgid "The ``k8s_facts`` module was renamed to :ref:`k8s_info `." -msgstr "``k8s_facts`` モジュールの名前が :ref:`k8s_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:545 -msgid "The ``memset_memstore_facts`` module was renamed to :ref:`memset_memstore_info `." -msgstr "``memset_memstore_facts`` モジュールの名前が :ref:`memset_memstore_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:546 -msgid "The ``memset_server_facts`` module was renamed to :ref:`memset_server_info `." -msgstr "``memset_server_facts`` モジュールの名前が :ref:`memset_server_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:547 -msgid "The ``one_image_facts`` module was renamed to :ref:`one_image_info `." -msgstr "``one_image_facts`` モジュールの名前が :ref:`one_image_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:548 -msgid "The ``onepassword_facts`` module was renamed to :ref:`onepassword_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``onepassword_facts`` モジュールの名前が :ref:`onepassword_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:551 -msgid "The ``oneview_datacenter_facts`` module was renamed to :ref:`oneview_datacenter_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_datacenter_facts`` モジュールの名前が :ref:`oneview_datacenter_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:554 -msgid "The ``oneview_enclosure_facts`` module was renamed to :ref:`oneview_enclosure_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_enclosure_facts`` モジュールの名前が :ref:`oneview_enclosure_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:557 -msgid "The ``oneview_ethernet_network_facts`` module was renamed to :ref:`oneview_ethernet_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_ethernet_network_facts`` モジュールの名前が :ref:`oneview_ethernet_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:560 -msgid "The ``oneview_fc_network_facts`` module was renamed to :ref:`oneview_fc_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_fc_network_facts`` モジュールの名前が :ref:`oneview_fc_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:563 -msgid "The ``oneview_fcoe_network_facts`` module was renamed to :ref:`oneview_fcoe_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_fcoe_network_facts`` モジュールの名前が :ref:`oneview_fcoe_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:566 -msgid "The ``oneview_logical_interconnect_group_facts`` module was renamed to :ref:`oneview_logical_interconnect_group_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_logical_interconnect_group_facts`` モジュールの名前が :ref:`oneview_logical_interconnect_group_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:569 -msgid "The ``oneview_network_set_facts`` module was renamed to :ref:`oneview_network_set_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_network_set_facts`` モジュールの名前が :ref:`oneview_network_set_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:572 -msgid "The ``oneview_san_manager_facts`` module was renamed to :ref:`oneview_san_manager_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``oneview_san_manager_facts`` モジュールの名前が :ref:`oneview_san_manager_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:575 -msgid "The ``os_flavor_facts`` module was renamed to :ref:`os_flavor_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_flavor_facts`` モジュールの名前が :ref:`os_flavor_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:578 -msgid "The ``os_image_facts`` module was renamed to :ref:`os_image_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_image_facts`` モジュールの名前が :ref:`os_image_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:581 -msgid "The ``os_keystone_domain_facts`` module was renamed to :ref:`os_keystone_domain_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_keystone_domain_facts`` モジュールの名前が :ref:`os_keystone_domain_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:584 -msgid "The ``os_networks_facts`` module was renamed to :ref:`os_networks_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_networks_facts`` モジュールの名前が :ref:`os_networks_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:587 -msgid "The ``os_port_facts`` module was renamed to :ref:`os_port_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_port_facts`` モジュールの名前が :ref:`os_port_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:590 -msgid "The ``os_project_facts`` module was renamed to :ref:`os_project_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_project_facts`` モジュールの名前が :ref:`os_project_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:593 -msgid "The ``os_server_facts`` module was renamed to :ref:`os_server_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_server_facts`` モジュールの名前が :ref:`os_server_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:596 -msgid "The ``os_subnets_facts`` module was renamed to :ref:`os_subnets_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_subnets_facts`` モジュールの名前が :ref:`os_subnets_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:599 -msgid "The ``os_user_facts`` module was renamed to :ref:`os_user_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``os_user_facts`` モジュールの名前が :ref:`os_user_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:602 -msgid "The ``ovirt_affinity_label_facts`` module was renamed to :ref:`ovirt_affinity_label_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_affinity_label_facts`` モジュールの名前が :ref:`ovirt_affinity_label_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:605 -msgid "The ``ovirt_api_facts`` module was renamed to :ref:`ovirt_api_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_api_facts`` モジュールの名前が :ref:`ovirt_api_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:608 -msgid "The ``ovirt_cluster_facts`` module was renamed to :ref:`ovirt_cluster_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_cluster_facts`` モジュールの名前が :ref:`ovirt_cluster_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:611 -msgid "The ``ovirt_datacenter_facts`` module was renamed to :ref:`ovirt_datacenter_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_datacenter_facts`` モジュールの名前が :ref:`ovirt_datacenter_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:614 -msgid "The ``ovirt_disk_facts`` module was renamed to :ref:`ovirt_disk_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_disk_facts`` モジュールの名前が :ref:`ovirt_disk_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:617 -msgid "The ``ovirt_event_facts`` module was renamed to :ref:`ovirt_event_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_event_facts`` モジュールの名前が :ref:`ovirt_event_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:620 -msgid "The ``ovirt_external_provider_facts`` module was renamed to :ref:`ovirt_external_provider_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_external_provider_facts`` モジュールの名前が :ref:`ovirt_external_provider_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:623 -msgid "The ``ovirt_group_facts`` module was renamed to :ref:`ovirt_group_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_group_facts`` モジュールの名前が :ref:`ovirt_group_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:626 -msgid "The ``ovirt_host_facts`` module was renamed to :ref:`ovirt_host_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_host_facts`` モジュールの名前が :ref:`ovirt_host_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:629 -msgid "The ``ovirt_host_storage_facts`` module was renamed to :ref:`ovirt_host_storage_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_host_storage_facts`` モジュールの名前が :ref:`ovirt_host_storage_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:632 -msgid "The ``ovirt_network_facts`` module was renamed to :ref:`ovirt_network_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_network_facts`` モジュールの名前が :ref:`ovirt_network_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:635 -msgid "The ``ovirt_nic_facts`` module was renamed to :ref:`ovirt_nic_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_nic_facts`` モジュールの名前が :ref:`ovirt_nic_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:638 -msgid "The ``ovirt_permission_facts`` module was renamed to :ref:`ovirt_permission_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_permission_facts`` モジュールの名前が :ref:`ovirt_permission_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:641 -msgid "The ``ovirt_quota_facts`` module was renamed to :ref:`ovirt_quota_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_quota_facts`` モジュールの名前が :ref:`ovirt_quota_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:644 -msgid "The ``ovirt_scheduling_policy_facts`` module was renamed to :ref:`ovirt_scheduling_policy_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_scheduling_policy_facts`` モジュールの名前が :ref:`ovirt_scheduling_policy_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:647 -msgid "The ``ovirt_snapshot_facts`` module was renamed to :ref:`ovirt_snapshot_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_snapshot_facts`` モジュールの名前が :ref:`ovirt_snapshot_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:650 -msgid "The ``ovirt_storage_domain_facts`` module was renamed to :ref:`ovirt_storage_domain_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_storage_domain_facts`` モジュールの名前が :ref:`ovirt_storage_domain_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:653 -msgid "The ``ovirt_storage_template_facts`` module was renamed to :ref:`ovirt_storage_template_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_storage_template_facts`` モジュールの名前が :ref:`ovirt_storage_template_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:656 -msgid "The ``ovirt_storage_vm_facts`` module was renamed to :ref:`ovirt_storage_vm_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_storage_vm_facts`` モジュールの名前が :ref:`ovirt_storage_vm_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:659 -msgid "The ``ovirt_tag_facts`` module was renamed to :ref:`ovirt_tag_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_tag_facts`` モジュールの名前が :ref:`ovirt_tag_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:662 -msgid "The ``ovirt_template_facts`` module was renamed to :ref:`ovirt_template_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_template_facts`` モジュールの名前が :ref:`ovirt_template_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:665 -msgid "The ``ovirt_user_facts`` module was renamed to :ref:`ovirt_user_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_user_facts`` モジュールの名前が :ref:`ovirt_user_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:668 -msgid "The ``ovirt_vm_facts`` module was renamed to :ref:`ovirt_vm_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_vm_facts`` モジュールの名前が :ref:`ovirt_vm_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:671 -msgid "The ``ovirt_vmpool_facts`` module was renamed to :ref:`ovirt_vmpool_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``ovirt_vmpool_facts`` モジュールの名前が :ref:`ovirt_vmpool_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:674 -msgid "The ``python_requirements_facts`` module was renamed to :ref:`python_requirements_info `." -msgstr "``python_requirements_facts`` モジュールの名前が :ref:`python_requirements_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:675 -msgid "The ``rds_instance_facts`` module was renamed to :ref:`rds_instance_info `." -msgstr "``rds_instance_facts`` モジュールの名前が :ref:`rds_instance_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:676 -msgid "The ``rds_snapshot_facts`` module was renamed to :ref:`rds_snapshot_info `." -msgstr "``rds_snapshot_facts`` モジュールの名前が :ref:`rds_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:677 -msgid "The ``redfish_facts`` module was renamed to :ref:`redfish_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``redfish_facts`` モジュールの名前が :ref:`redfish_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:680 -msgid "The ``redshift_facts`` module was renamed to :ref:`redshift_info `." -msgstr "``redshift_facts`` モジュールの名前が :ref:`redshift_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:681 -msgid "The ``route53_facts`` module was renamed to :ref:`route53_info `." -msgstr "``route53_facts`` モジュールの名前が :ref:`route53_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:682 -msgid "The ``smartos_image_facts`` module was renamed to :ref:`smartos_image_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``smartos_image_facts`` モジュールの名前が :ref:`smartos_image_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:685 -msgid "The ``vertica_facts`` module was renamed to :ref:`vertica_info `. When called with the new name, the module no longer returns ``ansible_facts``. To access return values, :ref:`register a variable `." -msgstr "``vertica_facts`` モジュールの名前が :ref:`vertica_info ` になりました。新しい名前で呼び出すと、このモジュールは ``ansible_facts`` を返さなくなりました。戻り値にアクセスするには、:ref:`変数の登録 ` を行います。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:688 -msgid "The ``vmware_cluster_facts`` module was renamed to :ref:`vmware_cluster_info `." -msgstr "``vmware_cluster_facts`` モジュールの名前が :ref:`vmware_cluster_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:689 -msgid "The ``vmware_datastore_facts`` module was renamed to :ref:`vmware_datastore_info `." -msgstr "``vmware_datastore_facts`` モジュールの名前が :ref:`vmware_datastore_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:690 -msgid "The ``vmware_guest_facts`` module was renamed to :ref:`vmware_guest_info `." -msgstr "``vmware_guest_facts`` モジュールの名前が :ref:`vmware_guest_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:691 -msgid "The ``vmware_guest_snapshot_facts`` module was renamed to :ref:`vmware_guest_snapshot_info `." -msgstr "``vmware_guest_snapshot_facts`` モジュールの名前が :ref:`vmware_guest_snapshot_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:692 -msgid "The ``vmware_tag_facts`` module was renamed to :ref:`vmware_tag_info `." -msgstr "``vmware_tag_facts`` モジュールの名前が :ref:`vmware_tag_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:693 -msgid "The ``vmware_vm_facts`` module was renamed to :ref:`vmware_vm_info `." -msgstr "``vmware_vm_facts`` モジュールの名前が :ref:`vmware_vm_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:694 -msgid "The ``xenserver_guest_facts`` module was renamed to :ref:`xenserver_guest_info `." -msgstr "``xenserver_guest_facts`` モジュールの名前が :ref:`xenserver_guest_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:695 -msgid "The ``zabbix_group_facts`` module was renamed to :ref:`zabbix_group_info `." -msgstr "``zabbix_group_facts`` モジュールの名前が :ref:`zabbix_group_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:696 -msgid "The ``zabbix_host_facts`` module was renamed to :ref:`zabbix_host_info `." -msgstr "``zabbix_host_facts`` モジュールの名前が :ref:`zabbix_host_info ` に変更になりました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:701 -msgid ":ref:`vmware_cluster ` was refactored for easier maintenance/bugfixes. Use the three new, specialized modules to configure clusters. Configure DRS with :ref:`vmware_cluster_drs `, HA with :ref:`vmware_cluster_ha ` and vSAN with :ref:`vmware_cluster_vsan `." -msgstr ":ref:`vmware_cluster ` がリファクタリングされ、維持やバグ修正が容易になりました。クラスターの構成には、3 つの新しい専用モジュールを使用します。:ref:`vmware_cluster_drs ` で DRS を設定し、:ref:`vmware_cluster_ha ` で HA を設定し、:ref:`vmware_cluster_vsan ` で vSAN を設定します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:702 -msgid ":ref:`vmware_dvswitch ` accepts ``folder`` parameter to place dvswitch in user defined folder. This option makes ``datacenter`` as an optional parameter." -msgstr ":ref:`vmware_dvswitch ` は、ユーザー定義のディレクトリーに dvswitch を配置する ``folder`` パラメーターを受け入れます。このオプションは ``datacenter`` を任意のパラメーターとして指定します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:703 -msgid ":ref:`vmware_datastore_cluster ` accepts ``folder`` parameter to place datastore cluster in user defined folder. This option makes ``datacenter`` as an optional parameter." -msgstr ":ref:`vmware_datastore_cluster ` は、ユーザー定義のディレクトリーにデータストアクラスターを配置する ``folder`` パラメーターを受け入れます。このオプションは ``datacenter`` を任意のパラメーターとして指定します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:704 -msgid ":ref:`mysql_db ` returns new ``db_list`` parameter in addition to ``db`` parameter. This ``db_list`` parameter refers to list of database names. ``db`` parameter will be deprecated in version 2.13." -msgstr ":ref:`mysql_db ` は、``db`` パラメーターに加えて、新しい``db_list`` パラメーターを返します。この ``db_list`` パラメーターは、データベース名のリストを参照します。``db`` パラメーターは、バージョン 2.13 で非推奨となります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:705 -msgid ":ref:`snow_record ` and :ref:`snow_record_find ` now takes environment variables for ``instance``, ``username`` and ``password`` parameters. This change marks these parameters as optional." -msgstr ":ref:`snow_record ` と:ref:`snow_record_find ` は、``instance``、``username``、``password`` のパラメータに環境変数を使用するようになりました。この変更により、これらのパラメータは任意となります。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:706 -msgid "The deprecated ``force`` option in ``win_firewall_rule`` has been removed." -msgstr "``win_firewall_rule`` の非推奨の ``force`` オプションは削除されました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:707 -msgid ":ref:`openssl_certificate `'s ``ownca`` provider creates authority key identifiers if not explicitly disabled with ``ownca_create_authority_key_identifier: no``. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available." -msgstr ":ref:`openssl_certificate ` の ``ownca`` プロバイダーは、``ownca_create_authority_key_identifier: no`` で明示的に無効にしていなければ、権限キーの識別子を作成します。これは、``cryptography`` バックエンドの場合のみで、``cryptography`` ライブラリーが利用可能な場合はデフォルトで選択されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:708 -msgid ":ref:`openssl_certificate `'s ``ownca`` and ``selfsigned`` providers create subject key identifiers if not explicitly disabled with ``ownca_create_subject_key_identifier: never_create`` resp. ``selfsigned_create_subject_key_identifier: never_create``. If a subject key identifier is provided by the CSR, it is taken; if not, it is created from the public key. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available." -msgstr ":ref:`openssl_certificate ` の``ownca`` プロバイダーおよび ``selfsigned`` プロバイダーは、``ownca_create_subject_key_identifier: never_create`` および ``selfsigned_create_subject_key_identifier: never_create`` でそれぞれ明示的に無効化されていなければ、サブジェクト鍵の識別子を作成します。CSR によってサブジェクト鍵識別子が提供されている場合はそれが使用され、提供されていない場合は公開鍵から作成されます。これは ``cryptography`` バックエンドの場合のみで、``cryptography`` ライブラリーが利用可能な場合はデフォルトで選択されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:709 -msgid ":ref:`openssh_keypair ` now applies the same file permissions and ownership to both public and private keys (both get the same ``mode``, ``owner``, ``group``, and so on). If you need to change permissions / ownership on one key, use the :ref:`file ` to modify it after it is created." -msgstr ":ref:`openssh_keypair ` は、公開鍵と秘密鍵の両方に同じファイルのパーミッションと所有権を適用するようになりました (両方に同じ ``mode``、``owner``、``group`` などが適用されます)。ある鍵のパーミッション/所有権を変更する必要がある場合は、作成後に :ref:`file ` を使用して変更します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:716 -msgid "Removed Lookup Plugins" -msgstr "削除されたルックアッププラグイン" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:718 -msgid "``redis_kv`` use :ref:`redis ` instead." -msgstr "``redis_kv`` は、代わりに :ref:`redis ` を使用します。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:731 -msgid "Network resource modules" -msgstr "ネットワークリソースモジュール" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:733 -msgid "Ansible 2.9 introduced the first batch of network resource modules. Sections of a network device's configuration can be thought of as a resource provided by that device. Network resource modules are intentionally scoped to configure a single resource and you can combine them as building blocks to configure complex network services. The older modules are deprecated in Ansible 2.9 and will be removed in Ansible 2.13. You should scan the list of deprecated modules above and replace them with the new network resource modules in your playbooks. See `Ansible Network Features in 2.9 `_ for details." -msgstr "Ansible 2.9 では、ネットワークリソースモジュールの最初のバッチが導入されました。ネットワークデバイスの設定のセクションは、そのデバイスが提供するリソースと考えることができます。ネットワークリソースモジュールは、意図的に 1 つのリソースを設定するようにスコープされており、複雑なネットワークサービスを設定するためのビルディングブロックとして組み合わせることができます。古いモジュールは、Ansible 2.9 で非推奨となり、Ansible 2.13 で削除される予定です。上記の非推奨モジュールのリストをスキャンし、Playbook の中で新しいネットワークリソースモジュールに置き換える必要があります。詳細は「`2.9 の Ansible ネットワーク機能 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:736 -msgid "Improved ``gather_facts`` support for network devices" -msgstr "ネットワークデバイスの ``gather_facts`` サポートが改善されました。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:738 -msgid "In Ansible 2.9, the ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`eos_facts `) to return just a subset of the device configuration. See :ref:`network_gather_facts` for an example." -msgstr "Ansible 2.9 では、``gather_facts`` キーワードが、標準化されたキー/値のペアでのネットワークデバイスのファクトの収集に対応しました。これらのネットワークファクトを、ネットワークデバイスを管理するためのさらなるタスクに投入することができます。また、新しい ``gather_network_resources`` パラメーターをネットワーク ``*_facts`` モジュール (:ref:`eos_facts ` など) と一緒に使用することで、デバイス構成のサブセットのみを返すことができます。その例として、「:ref:`network_gather_facts`」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:741 -msgid "Top-level connection arguments removed in 2.9" -msgstr "2.9 で削除された最上位の接続引数" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:743 -msgid "Top-level connection arguments like ``username``, ``host``, and ``password`` are removed in version 2.9." -msgstr "``username``、``host``、``password`` などの最上位レベルの接続引数は、バージョン 2.9 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_2.9.rst:759 -msgid "Change your playbooks to the connection types ``network_cli`` and ``netconf`` using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`." -msgstr "Playbook を、Ansible の標準的な接続プロパティーを使用して接続タイプ ``network_cli`` および``netconf`` に変更し、インベントリーでこれらのプロパティーをグループごとに設定します。Playbook とインベントリーファイルを更新する際に、特権昇格のために ``become`` への変更を簡単に行うことができます (サポートしているプラットフォームの場合)。詳細については、「:ref:`ネットワークモジュールで become の使用`」ガイドおよび :ref:`プラットフォームのドキュメント` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:8 -msgid "Ansible 3 Porting Guide" -msgstr "Ansible 3 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:15 -msgid "Ansible 3 is based on Ansible-Base 2.10, which is the same major release as Ansible 2.10. Therefore, there is no section on ansible-base in this porting guide. If you are upgrading from Ansible 2.9, please first consult the Ansible 2.10 porting guide before continuing with the Ansible 3 porting guide." -msgstr "Ansible 3 は、Ansible 2.10 と同じメジャーリリースである Ansible-Base 2.10 をベースにしています。そのため、この移植ガイドには、ansible-base に関するセクションはありません。Ansible 2.9 からアップグレードする場合は、まず Ansible 2.10 の移植ガイドを参照してから、Ansible 3 の移植ガイドに進んでください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:17 -msgid "We suggest you read this page along with the `Ansible 3 Changelog `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible 3 Changelog `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_3.rst:20 -msgid "Porting Guide for v3.4.0" -msgstr "v3.4.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:26 -#: ../../rst/porting_guides/porting_guide_3.rst:95 -#: ../../rst/porting_guides/porting_guide_3.rst:125 -#: ../../rst/porting_guides/porting_guide_3.rst:198 -#: ../../rst/porting_guides/porting_guide_3.rst:360 -#: ../../rst/porting_guides/porting_guide_3.rst:639 -#: ../../rst/porting_guides/porting_guide_4.rst:317 -#: ../../rst/porting_guides/porting_guide_4.rst:375 -#: ../../rst/porting_guides/porting_guide_4.rst:389 -#: ../../rst/porting_guides/porting_guide_4.rst:431 -#: ../../rst/porting_guides/porting_guide_4.rst:450 -#: ../../rst/porting_guides/porting_guide_4.rst:528 -#: ../../rst/porting_guides/porting_guide_5.rst:323 -#: ../../rst/porting_guides/porting_guide_5.rst:362 -#: ../../rst/porting_guides/porting_guide_5.rst:447 -#: ../../rst/porting_guides/porting_guide_5.rst:737 -#: ../../rst/porting_guides/porting_guide_6.rst:322 -#: ../../rst/porting_guides/porting_guide_6.rst:410 -#: ../../rst/porting_guides/porting_guide_6.rst:555 -#: ../../rst/porting_guides/porting_guide_6.rst:725 -#: ../../rst/porting_guides/porting_guide_7.rst:286 -#: ../../rst/porting_guides/porting_guide_7.rst:636 -msgid "dellemc.openmanage" -msgstr "dellemc.openmanage" - -#: ../../rst/porting_guides/porting_guide_3.rst:28 -#: ../../rst/porting_guides/porting_guide_3.rst:97 -#: ../../rst/porting_guides/porting_guide_4.rst:319 -#: ../../rst/porting_guides/porting_guide_4.rst:377 -#: ../../rst/porting_guides/porting_guide_4.rst:433 -#: ../../rst/porting_guides/porting_guide_4.rst:530 -#: ../../rst/porting_guides/porting_guide_5.rst:449 -msgid "idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again." -msgstr "idrac_user - Issue(192043)モジュールは ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress`` メッセージでエラーが発生する可能性があります。ジョブが完了するまで待機し、タスクを再度実行します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:29 -#: ../../rst/porting_guides/porting_guide_3.rst:98 -#: ../../rst/porting_guides/porting_guide_4.rst:531 -msgid "ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator." -msgstr "ome_configuration_compliance_info - Issue(195592) モジュールは ``unable to process the request because an error occurred`` メッセージでエラーが発生する可能性があります。問題が解決しない場合は、システム管理者に報告してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:30 -#: ../../rst/porting_guides/porting_guide_3.rst:99 -#: ../../rst/porting_guides/porting_guide_3.rst:127 -#: ../../rst/porting_guides/porting_guide_4.rst:532 -msgid "ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported." -msgstr "ome_smart_fabric - Issue(185322)は OpenManage Enterprise Modular でサポートされている 3 つの設計タイプのみですが、モジュールは設計タイプがサポートされていないと、ファブリックが正常に作成されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:31 -#: ../../rst/porting_guides/porting_guide_3.rst:100 -#: ../../rst/porting_guides/porting_guide_3.rst:128 -#: ../../rst/porting_guides/porting_guide_4.rst:378 -#: ../../rst/porting_guides/porting_guide_4.rst:434 -#: ../../rst/porting_guides/porting_guide_4.rst:533 -#: ../../rst/porting_guides/porting_guide_5.rst:452 -msgid "ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified." -msgstr "ome_smart_fabric_uplink - Issue(186024)ome_smart_fabric_uplink モジュールでは、OpenManage Enterprise Modular でサポートされていても、同じ名前の複数のアップリンクの作成はできません。アップリンクが既存のアップリンクと同じ名前を使用して作成されると、既存のアップが変更します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:39 -#: ../../rst/porting_guides/porting_guide_4.rst:610 -#: ../../rst/porting_guides/porting_guide_5.rst:610 -msgid "ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients." -msgstr "ansible-test - ``centos6`` および ``default`` テストコンテナーで実行されるテストでは、Python 2.6 の使用時に PyPI プロキシーコンテナーを使用して PyPI にアクセスできるようになりました。これにより、Python 2.6 で実行されるテストは、PyPI 以外のクライアントのサポートがある場合でも引き続き機能します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:42 -#: ../../rst/porting_guides/porting_guide_4.rst:445 -#: ../../rst/porting_guides/porting_guide_5.rst:187 -#: ../../rst/porting_guides/porting_guide_5.rst:218 -#: ../../rst/porting_guides/porting_guide_5.rst:721 -#: ../../rst/porting_guides/porting_guide_6.rst:298 -#: ../../rst/porting_guides/porting_guide_6.rst:705 -#: ../../rst/porting_guides/porting_guide_7.rst:623 -msgid "community.postgresql" -msgstr "community.postgresql" - -#: ../../rst/porting_guides/porting_guide_3.rst:44 -#: ../../rst/porting_guides/porting_guide_4.rst:447 -#: ../../rst/porting_guides/porting_guide_5.rst:723 -msgid "postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85)." -msgstr "postgresql_query - ``as_single_query`` オプションのデフォルト値が community.postgresql 2.0.0 で ``yes`` に変更になります (https://github.com/ansible-collections/community.postgresql/issues/85)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:47 -#: ../../rst/porting_guides/porting_guide_4.rst:679 -#: ../../rst/porting_guides/porting_guide_6.rst:290 -#: ../../rst/porting_guides/porting_guide_7.rst:299 -msgid "netapp.ontap" -msgstr "netapp.ontap" - -#: ../../rst/porting_guides/porting_guide_3.rst:49 -#: ../../rst/porting_guides/porting_guide_4.rst:681 -msgid "na_ontap_autosupport - Added REST support to the module." -msgstr "na_ontap_autosupport - モジュールに REST サポートを追加。" - -#: ../../rst/porting_guides/porting_guide_3.rst:57 -#: ../../rst/porting_guides/porting_guide_4.rst:859 -msgid "ec2_vpc_endpoint_info - the ``query`` option has been deprecated and will be removed after 2022-12-01 (https://github.com/ansible-collections/community.aws/pull/346). The ec2_vpc_endpoint_info now defaults to listing information about endpoints. The ability to search for information about available services has been moved to the dedicated module ``ec2_vpc_endpoint_service_info``." -msgstr "ec2_vpc_endpoint_info - ``query`` オプションは非推奨となり、2022-12-01 以降に削除されます（https://github.com/ansible-collections/community.aws/pull/346）。ec2_vpc_endpoint_info は、デフォルトでエンドポイントに関する情報を一覧表示するようになりました。利用可能なサービスに関する情報の検索機能が、専用のモジュール ``ec2_vpc_endpoint_service_info`` に移動しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:62 -#: ../../rst/porting_guides/porting_guide_4.rst:488 -#: ../../rst/porting_guides/porting_guide_5.rst:964 -msgid "docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134)." -msgstr "docker_* モジュールおよびプラグイン（``docker_swarm`` 接続プラグイン、``docker_compose`` モジュール、および '`docker_stack*` モジュールを除く）は非推奨になりました。``tls_hostname`` の現在のデフォルト ``localhost`` は非推奨になりました。community.docker 2.0.0 では、代わりに ``docker_host`` から計算されます（https://github.com/ansible-collections/community.docker/pull/134）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:65 -msgid "Porting Guide for v3.3.0" -msgstr "v3.3.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:71 -#: ../../rst/porting_guides/porting_guide_3.rst:139 -#: ../../rst/porting_guides/porting_guide_4.rst:653 -#: ../../rst/porting_guides/porting_guide_5.rst:182 -#: ../../rst/porting_guides/porting_guide_6.rst:262 -#: ../../rst/porting_guides/porting_guide_6.rst:535 -#: ../../rst/porting_guides/porting_guide_6.rst:695 -#: ../../rst/porting_guides/porting_guide_7.rst:612 -msgid "community.mysql" -msgstr "community.mysql" - -#: ../../rst/porting_guides/porting_guide_3.rst:73 -#: ../../rst/porting_guides/porting_guide_4.rst:662 -msgid "mysql_user - the ``REQUIRESSL`` is an alias for the ``ssl`` key in the ``tls_requires`` option in ``community.mysql`` 2.0.0 and support will be dropped altogether in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/121)." -msgstr "``REQUIRESSL`` は、``community.mysql`` 2.0.0 の ``tls_requires`` オプションにある ``ssl`` キーのエイリアスです。サポートは ``community.mysql`` 3.0.0 ですべて削除されます（https://github.com/ansible-collections/community.mysql/issues/121）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:81 -#: ../../rst/porting_guides/porting_guide_4.rst:889 -msgid "vmware_vmkernel_ip_config - deprecate in favor of vmware_vmkernel (https://github.com/ansible-collections/community.vmware/pull/667)." -msgstr "vmware_vmkernel_ip_config - vmware_vmkernel が採用される（非推奨）（https://github.com/ansible-collections/community.vmware/pull/667）" - -#: ../../rst/porting_guides/porting_guide_3.rst:86 -#: ../../rst/porting_guides/porting_guide_4.rst:894 -msgid "Support for Python versions earlier than 3.5 is being deprecated" -msgstr "3.5 よりも前の Python バージョンのサポートが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:89 -msgid "Porting Guide for v3.2.0" -msgstr "v3.2.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:108 -#: ../../rst/porting_guides/porting_guide_4.rst:560 -msgid "docker_swarm - if ``join_token`` is specified, a returned join token with the same value will be replaced by ``VALUE_SPECIFIED_IN_NO_LOG_PARAMETER``. Make sure that you do not blindly use the join tokens from the return value of this module when the module is invoked with ``join_token`` specified! This breaking change appears in a minor release since it is necessary to fix a security issue (https://github.com/ansible-collections/community.docker/pull/103)." -msgstr "docker_swarm - ``join_token`` が指定されている場合、返される結合トークンが ``VALUE_SPECIFIED_IN_NO_LOG_PARAMETER`` に置き換えられます。これにより、モジュールが ``join_token`` で呼び出されると、このモジュールの戻り値から結合トークンを使用しないようにします。この重大な変更は、セキュリティーの問題を修正するために必要なため、マイナーリリースに変更になりました（https://github.com/ansible-collections/community.docker/pull/103）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:116 -#: ../../rst/porting_guides/porting_guide_4.rst:864 -msgid "acme module_utils - the ``acme`` module_utils (``ansible_collections.community.crypto.plugins.module_utils.acme``) is deprecated and will be removed in community.crypto 2.0.0. Use the new Python modules in the ``acme`` package instead (``ansible_collections.community.crypto.plugins.module_utils.acme.xxx``) (https://github.com/ansible-collections/community.crypto/pull/184)." -msgstr "acme module_utils - ``acme`` module_utils（``ansible_collections.community.crypto.plugins.module_utils.acme``）は非推奨となり、community.crypto 2.0.0 で削除されます。代わりに ``acme`` パッケージで新しい Python モジュールを使用してください（``ansible_collections.community.crypto.plugins.module_utils.acme.xxx``)（https://github.com/ansible-collections/community.crypto/pull/184）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:119 -msgid "Porting Guide for v3.1.0" -msgstr "v3.1.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:136 -#: ../../rst/porting_guides/porting_guide_4.rst:650 -msgid "introduce \"skip_version_check\" parameter in grafana_teams and grafana_folder modules (#147)" -msgstr "grafana_teams モジュールおよび grafana_folder モジュールに「skip_version_check」パラメーターが追加されました(#147)" - -#: ../../rst/porting_guides/porting_guide_3.rst:141 -#: ../../rst/porting_guides/porting_guide_4.rst:657 -msgid "mysql_replication - the mode options values ``getslave``, ``startslave``, ``stopslave``, ``resetslave``, ``resetslaveall` and the master_use_gtid option ``slave_pos`` are deprecated (see the alternative values) and will be removed in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/97)." -msgstr "mysql_replication - モードオプションの値 ``getslave``、``startslave``、``stopslave``、``resetslave``、`resetslaveall`、および master_use_gtid オプション ``slave_pos`` は非推奨となり（別の値を参照）、``community.mysql`` 3.0.0 で削除されます（別の値を参照）（https://github.com/ansible-collections/community.mysql/pull/97）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:142 -#: ../../rst/porting_guides/porting_guide_4.rst:659 -msgid "mysql_replication - the word ``SLAVE`` in messages returned by the module will be changed to ``REPLICA`` in ``community.mysql`` 2.0.0 (https://github.com/ansible-collections/community.mysql/issues/98)." -msgstr "mysql_replication - モジュールによって返されたメッセージの ``SLAVE`` という単語は ``community.mysql`` 2.0.0 では ``REPLICA`` に変更されます（https://github.com/ansible-collections/community.mysql/issues/98）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:150 -#: ../../rst/porting_guides/porting_guide_4.rst:815 -msgid "Removed TMOS v11 support for bigip_gtm_pool and bigip_gtm_wide_ip modules" -msgstr "bigip_gtm_pool および bigip_gtm_wide_ip モジュールの TMOS v11 サポートを削除" - -#: ../../rst/porting_guides/porting_guide_3.rst:151 -#: ../../rst/porting_guides/porting_guide_4.rst:816 -msgid "Removed quorum and monitor_type parameters in bigip_node module. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html" -msgstr "bigip_node モジュールで quorum および monitor_type パラメーターが削除されました。移植ガイドのセクション（https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html）を参照してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:152 -#: ../../rst/porting_guides/porting_guide_4.rst:817 -msgid "Removed syslog_settings and pool_settings parameters in bigip_log_destination moduke. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html" -msgstr "bigip_log_destination モジュールで syslog_settings パラメーターおよび pool_settings パラメーターが削除されました。移植ガイドのセクション（https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html）を参照してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:158 -#: ../../rst/porting_guides/porting_guide_3.rst:220 -#: ../../rst/porting_guides/porting_guide_4.rst:440 -#: ../../rst/porting_guides/porting_guide_4.rst:850 -#: ../../rst/porting_guides/porting_guide_5.rst:676 -msgid "cloudscale_ch.cloud" -msgstr "cloudscale_ch.cloud" - -#: ../../rst/porting_guides/porting_guide_3.rst:160 -#: ../../rst/porting_guides/porting_guide_4.rst:852 -msgid "The aliases ``server_uuids`` and ``server_uuid`` of the servers parameter in the volume module will be removed in version 3.0.0." -msgstr "ボリュームモジュールの server パラメーターのエイリアス ``server_uuids`` および ``server_uuid`` は、バージョン 3.0.0 で削除されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:165 -#: ../../rst/porting_guides/porting_guide_4.rst:857 -msgid "ec2_eip - formally deprecate the ``instance_id`` alias for ``device_id`` (https://github.com/ansible-collections/community.aws/pull/349)." -msgstr "ec2_eip - ``device_id`` の ``instance_id`` エイリアスを正式に非推奨化（https://github.com/ansible-collections/community.aws/pull/349）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:166 -#: ../../rst/porting_guides/porting_guide_4.rst:858 -msgid "ec2_vpc_endpoint - deprecate the policy_file option and recommend using policy with a lookup (https://github.com/ansible-collections/community.aws/pull/366)." -msgstr "ec2_vpc_endpoint - policy_file オプションを非推奨にし、ルックアップでのポリシーの使用を推奨します（https://github.com/ansible-collections/community.aws/pull/366）" - -#: ../../rst/porting_guides/porting_guide_3.rst:171 -#: ../../rst/porting_guides/porting_guide_4.rst:865 -msgid "acme_account_info - when ``retrieve_orders=url_list``, ``orders`` will no longer be returned in community.crypto 2.0.0. Use ``order_uris`` instead (https://github.com/ansible-collections/community.crypto/pull/178)." -msgstr "acme_account_info - ``retrieve_orders=url_list`` の場合、``orders`` は community.crypto 2.0.0 で返されなくなります。代わりに ``order_uris`` を使用します（https://github.com/ansible-collections/community.crypto/pull/178）" - -#: ../../rst/porting_guides/porting_guide_3.rst:176 -#: ../../rst/porting_guides/porting_guide_4.rst:870 -msgid "apt_rpm - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "apt_rpm - 非推奨の無効なパラメーターエイリアス ``update-cache`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）" - -#: ../../rst/porting_guides/porting_guide_3.rst:177 -#: ../../rst/porting_guides/porting_guide_4.rst:871 -msgid "composer - deprecated invalid parameter aliases ``working-dir``, ``global-command``, ``prefer-source``, ``prefer-dist``, ``no-dev``, ``no-scripts``, ``no-plugins``, ``optimize-autoloader``, ``classmap-authoritative``, ``apcu-autoloader``, ``ignore-platform-reqs``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "composer - 非推奨の無効なパラメーターエイリアス ``working-dir``、``global-command``、``prefer-source``、``prefer-dist``、``no-dev``、``no-scripts``、``no-plugins``、``optimize-autoloader``、``classmap-authoritative``、``apcu-autoloader``、``ignore-platform-reqs`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:178 -#: ../../rst/porting_guides/porting_guide_4.rst:873 -msgid "github_deploy_key - deprecated invalid parameter alias ``2fa_token``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "github_deploy_key - 非推奨の無効なパラメーターエイリアス ``2fa_token`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）" - -#: ../../rst/porting_guides/porting_guide_3.rst:179 -#: ../../rst/porting_guides/porting_guide_4.rst:874 -msgid "grove - the option ``message`` will be removed in community.general 4.0.0. Use the new option ``message_content`` instead (https://github.com/ansible-collections/community.general/pull/1929)." -msgstr "grove - オプション ``message`` は community.general 4.0.0 で削除されます。代わりに、新しいオプション ``message_content`` を使用してください（https://github.com/ansible-collections/community.general/pull/1929）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:180 -#: ../../rst/porting_guides/porting_guide_4.rst:875 -msgid "homebrew - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "homebrew - 非推奨の無効なパラメーターエイリアス ``update-brew`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）" - -#: ../../rst/porting_guides/porting_guide_3.rst:181 -#: ../../rst/porting_guides/porting_guide_4.rst:876 -msgid "homebrew_cask - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "homebrew_cask - 非推奨の無効なパラメーターエイリアス ``update-brew`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:182 -#: ../../rst/porting_guides/porting_guide_4.rst:877 -msgid "opkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "opkg - 非推奨の無効なパラメーターエイリアス ``update-cache`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:183 -#: ../../rst/porting_guides/porting_guide_4.rst:878 -msgid "pacman - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "pacman - 非推奨の無効なパラメーターエイリアス ``update-cache`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:184 -#: ../../rst/porting_guides/porting_guide_4.rst:879 -msgid "puppet - deprecated undocumented parameter ``show_diff``, will be removed in 7.0.0. (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "puppet - ドキュメント化されていない非推奨のパラメーター ``show_diff`` が 7.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:185 -#: ../../rst/porting_guides/porting_guide_4.rst:880 -msgid "runit - unused parameter ``dist`` marked for deprecation (https://github.com/ansible-collections/community.general/pull/1830)." -msgstr "runit - 未使用のパラメーター ``dist`` は非推奨と示されています（https://github.com/ansible-collections/community.general/pull/1830）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:186 -#: ../../rst/porting_guides/porting_guide_4.rst:881 -msgid "slackpkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "slackpkg - 非推奨の無効なパラメーターエイリアス ``update-cache`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:187 -#: ../../rst/porting_guides/porting_guide_4.rst:882 -msgid "urpmi - deprecated invalid parameter aliases ``update-cache`` and ``no-recommends``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "urpmi - 非推奨の無効なパラメーターエイリアス ``update-cache`` および ``no-recommends`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:188 -#: ../../rst/porting_guides/porting_guide_4.rst:883 -msgid "xbps - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927)." -msgstr "xbps - 非推奨の無効なパラメーターエイリアス ``update-cache`` が 5.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/1927）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:189 -#: ../../rst/porting_guides/porting_guide_4.rst:884 -msgid "xfconf - returning output as facts is deprecated, this will be removed in community.general 4.0.0. Please register the task output in a variable and use it instead. You can already switch to the new behavior now by using the new ``disable_facts`` option (https://github.com/ansible-collections/community.general/pull/1747)." -msgstr "xfconf - 出力をファクトとして返すのは非推奨です。これは community.general 4.0.0 で削除されます。タスクの出力を変数に登録して代わりに使用してください。新しい``disable_facts`` オプション使用すると新しい挙動に切り替えることができます（https://github.com/ansible-collections/community.general/pull/1747）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:192 -msgid "Porting Guide for v3.0.0" -msgstr "v3.0.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_3.rst:200 -msgid "Issue 1(186024): ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified." -msgstr "Issue 1(186024): ome_smart_fabric_uplink モジュールでは、OpenManage Enterprise Modular でサポートされていても、同じ名前の複数のアップリンクの作成はできません。アップリンクが既存のアップリンクと同じ名前を使用して作成されると、既存のアップが変更します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:201 -msgid "Issue 2(187956): If an invalid job_id is provided, idrac_lifecycle_controller_job_status_info returns an error message. This error message does not contain information about the exact issue with the invalid job_id." -msgstr "Issue 2(187956): 無効なjob_idが提供された場合、idrac_lifecycle_controller_job_status_infoはエラーメッセージを返します。このエラーメッセージには、無効なjob_idに関する正確な問題についての情報が含まれていません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:202 -msgid "Issue 3(188267): While updating the iDRAC firmware, the idrac_firmware module completes execution before the firmware update job is completed. An incorrect message is displayed in the task output as 'DRAC WSMAN endpoint returned HTTP code '400' Reason 'Bad Request''. This issue may occur if the target iDRAC firmware version is less than 3.30.30.30" -msgstr "Issue 3(188267): iDRACファームウェアの更新中に、idrac_firmwareモジュールは、ファームウェア更新ジョブが完了する前に実行を完了します。タスク出力に誤ったメッセージ'DRAC WSMAN endpoint returned HTTP code '400' Reason 'Bad Request''が表示されます。この問題は、ターゲットiDRACファームウェアバージョンが3.30.30.30未満の場合に発生する可能性があります" - -#: ../../rst/porting_guides/porting_guide_3.rst:210 -msgid "ansible-galaxy login command has been removed ( see `issue 71560 `_)" -msgstr "ansible-galaxy login コマンドが削除されました (`issue 71560 ` を参照))。" - -#: ../../rst/porting_guides/porting_guide_3.rst:213 -msgid "ansible.utils" -msgstr "ansible.utils" - -#: ../../rst/porting_guides/porting_guide_3.rst:215 -msgid "If added custom sub plugins in your collection move from old location `plugins/` to the new location `plugins/sub_plugins/` and update the imports as required" -msgstr "コレクションにカスタムサブプラグインを追加した場合、以前の場所 `plugins/` から新しい場所 `plugins/sub_plugins/` に移動し、必要に応じてインポートを更新します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:216 -msgid "Move sub plugins cli_parsers, fact_diff and validate to `plugins/sub_plugins` folder" -msgstr "サブプラグイン cli_parsers、fact_diff、および validate を `plugins/sub_plugins` ディレクトリーに移動します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:217 -msgid "The `cli_parsers` sub plugins folder name is changed to `cli_parse` to have consistent naming convention, that is all the cli_parse subplugins will now be in `plugins/sub_plugins/cli_parse` folder" -msgstr "`cli_parsers` サブプラグインのディレクトリー名が、一貫性のある命名規則を持つように `cli_parse` に変更になり、cli_parse サブプラグインはすべて `plugins/sub_plugins/cli_parse` ディレクトリーに置かれます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:222 -msgid "floating_ip - ``name`` is required for assigning a new floating IP." -msgstr "floating_ip - 新しい Floating IP アドレスの割り当てには ``name`` が必要です。" - -#: ../../rst/porting_guides/porting_guide_3.rst:227 -msgid "If you use Ansible 2.9 and the Google cloud plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Google cloud content by FQCN, like ``community.general.gce_img``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.google.gce_img`` for the previous example) and to make sure that you have ``community.google`` installed." -msgstr "Ansible 2.9 とこのコレクションの Google Cloud プラグインまたはモジュールを使用している場合、community.general 2.0.0 では、``community.general.gce_img`` のように FQCN で Google Cloud コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.google.gce_img``) を使用するために Playbook とロールを手動で調整し、``community.google`` がインストールされているかどうかを確認する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:230 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.google`` or ``google.cloud`` collections if you are using any of the Google cloud plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) した場合、Google cloud プラグインまたはモジュールを使用している場合は、``community.google`` コレクションまたは ``google.cloud`` コレクションもインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.google など) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:232 -msgid "If you use Ansible 2.9 and the Kubevirt plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Kubevirt content by FQCN, like ``community.general.kubevirt_vm``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.kubevirt.kubevirt_vm`` for the previous example) and to make sure that you have ``community.kubevirt`` installed." -msgstr "Ansible 2.9 とこのコレクションの Kubevirt プラグインまたはモジュールを使用している場合、community.general 2.0.0 では、``community.general.kubevirt_vm`` のような FQCN による Kubevirt コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN を使用するために Playbook とロールを手動で調整する必要があります (前述の例では ``community.kubevirt.kubevirt_vm``)。また、``community.kubevirt`` がインストールされていることを確認してください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:235 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.kubevirt`` collection if you are using any of the Kubevirt plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、Kubevirt プラグインまたはモジュールを使用している場合は、``community.kubevirt`` コレクションもインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.google など) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:237 -msgid "If you use Ansible 2.9 and the ``docker`` plugins or modules from this collections, community.general 2.0.0 results in errors when trying to use the docker content by FQCN, like ``community.general.docker_container``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.docker.docker_container`` for the previous example) and to make sure that you have ``community.docker`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``docker`` プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.docker_container`` のように FQCN による docker コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.docker.docker_container``) を使用し、``community.docker`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:240 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.docker`` if you are using any of the ``docker`` plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.docker) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) した場合、``docker`` プラグインまたはモジュールを使用している場合は、``community.docker`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.docker) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:242 -msgid "If you use Ansible 2.9 and the ``hashi_vault`` lookup plugin from this collections, community.general 2.0.0 results in errors when trying to use the Hashi Vault content by FQCN, like ``community.general.hashi_vault``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.hashi_vault.hashi_vault``) and to make sure that you have ``community.hashi_vault`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``hashi_vault`` lookup プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.hashi_vault`` のように FQCN による Hashi Vault コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (``community.hashi_vault.hashi_vault``) を使用し、``community.hashi_vault`` がインストールされていることを確認するために、インベントリー、変数ファイル、Playbook、およびロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:245 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hashi_vault`` if you are using the ``hashi_vault`` plugin. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hashi_vault) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、``hashi_vault`` プラグインを使用している場合は、``community.hashi_vault`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.hashi_vault) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:247 -msgid "If you use Ansible 2.9 and the ``hetzner`` modules from this collections, community.general 2.0.0 results in errors when trying to use the hetzner content by FQCN, like ``community.general.hetzner_firewall``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.hrobot.firewall`` for the previous example) and to make sure that you have ``community.hrobot`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``hetzner`` プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.hetzner_firewall`` のように FQCN による hetzner コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.hrobot.firewall``) を使用し、``community.hrobot`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:250 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hrobot`` if you are using any of the ``hetzner`` modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hrobot) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) した場合、``hetzner`` モジュールを使用している場合は、``community.hrobot`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.hrobot) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:252 -msgid "If you use Ansible 2.9 and the ``oc`` connection plugin from this collections, community.general 2.0.0 results in errors when trying to use the oc content by FQCN, like ``community.general.oc``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.okd.oc``) and to make sure that you have ``community.okd`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``oc`` connection プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.oc`` のように FQCN による oc コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (``community.okd.oc``) を使用し、``community.okd`` がインストールされていることを確認するために、インベントリー、変数ファイル、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:255 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.okd`` if you are using the ``oc`` plugin. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.okd) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、``oc`` プラグインを使用している場合は、``community.okd`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.okd) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:257 -msgid "If you use Ansible 2.9 and the ``postgresql`` modules from this collections, community.general 2.0.0 results in errors when trying to use the postgresql content by FQCN, like ``community.general.postgresql_info``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.postgresql.postgresql_info`` for the previous example) and to make sure that you have ``community.postgresql`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``postgresql`` プラグインやモジュールを使用している場合、community.general 2.0.0 では、``community.general.postgresql_info`` のように FQCN による postgresql コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.postgresql.postgresql_info``) を使用し、``community.postgresql`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:260 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.postgresql`` if you are using any of the ``postgresql`` modules. While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.postgresql) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、``postgresql`` モジュールを使用している場合は、``community.postgresql`` もインストールする必要があります。ansible-base 2.10 以降では、community.general 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.postgresql) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:262 -#: ../../rst/porting_guides/porting_guide_3.rst:493 -msgid "The Google cloud inventory script ``gce.py`` has been migrated to the ``community.google`` collection. Install the ``community.google`` collection in order to continue using it." -msgstr "Google クラウドインベントリースクリプト ``gce.py`` を ``community.google`` コレクションに移行しました。使用を継続するには、``community.google`` コレクションをインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:263 -msgid "archive - remove path folder itself when ``remove`` parameter is true (https://github.com/ansible-collections/community.general/issues/1041)." -msgstr "archive - ``remove`` パラメーターが true の場合にパスフォルダー自体を削除します（https://github.com/ansible-collections/community.general/issues/1041）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:265 -msgid "passwordstore lookup plugin - now parsing a password store entry as YAML if possible, skipping the first line (which by convention only contains the password and nothing else). If it cannot be parsed as YAML, the old ``key: value`` parser will be used to process the entry. Can break backwards compatibility if YAML formatted code was parsed in a non-YAML interpreted way, for example ``foo: [bar, baz]``, will become a list with two elements in the new version, but a string ``'[bar, baz]'`` in the old (https://github.com/ansible-collections/community.general/issues/1673)." -msgstr "passwordstore lookup プラグイン - パスワードストアのエントリーを可能な限り YAML として解析するようになり、最初の行 (慣例ではパスワードのみを含み、他には何もない) をスキップするようになりました。YAML として解析できない場合は、古い ``key: value`` パーサーがエントリーの処理に使用されます。YAML 形式のコードが YAML ではない解釈方法で解析された場合は、下位互換性を失う可能性があります。たとえば、``foo: [bar, baz]`` は新バージョンでは 2 つの要素を持つリストになりますが、旧バージョンでは文字列 ``'[bar, baz]'`` になります (https://github.com/ansible-collections/community.general/issues/1673)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:268 -msgid "proxmox_kvm - recognize ``force=yes`` in conjunction with ``state=absent`` to forcibly remove a running VM (https://github.com/ansible-collections/community.general/pull/849)." -msgstr "proxmox_kvm - ``force=yes`` を ``state=absent`` と併用して、実行中の仮想マシンを強制的に削除します (https://github.com/ansible-collections/community.general/pull/849)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:284 -msgid "If you use Ansible 2.9 and the FortiOS modules from this collection, community.network 2.0.0 results in errors when trying to use the FortiOS content by FQCN, like ``community.network.fmgr_device``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.fortios.fmgr_device`` for the previous example) and to make sure that you have ``community.fortios`` installed." -msgstr "このコレクションの Ansible 2.9 と FortiOS モジュールを使用する場合は、community.network 2.0.0 を使用すると、FQCN で ``community.network.fmgr_device`` のような FortiOS コンテンツを使用しようとすると、エラーが発生します。Ansible 2.9 はリダイレクトを使用できないため、新しい FQCN を使用し、``community.fortios`` がインストールされているのを確認するには、Playbook とロールを手動で調整する必要があります (前の例の ``community.fortios.fmgr_device``)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:287 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.fortios`` if you are using any of the FortiOS modules. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.fortios) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) した場合、FortiOS モジュールを使用している場合は、``community.fortios`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.fortios) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:289 -msgid "If you use Ansible 2.9 and the ``cp_publish`` module from this collection, community.network 2.0.0 results in errors when trying to use the module by FQCN, i.e. ``community.network.cp_publish``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``check_point.mgmt.cp_mgmt_publish``) and to make sure that you have ``check_point.mgmt`` installed. If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``check_point.mgmt`` if you are using the ``cp_publish`` module. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (check_point.mgmt) must be installed for them to work." -msgstr "Ansible 2.9 とこのコレクションの ``cp_publish`` モジュールを使用している場合、community.network 2.0.0 では、FQCN でモジュールを使用しようとするとエラーが発生します (``community.network.cp_publish``)。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (``check_point.mgmt.cp_mgmt_publish``) を使用し、``check_point.mgmt`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、community.network を手動でインストール (またはアップグレード) し、``cp_publish`` モジュールを使用している場合は、``check_point.mgmt`` もインストールする必要があります。ansible-base 2.10 以降では community.network 2.0.0 が追加するリダイレクトを使用することができますが、リダイレクト先のコレクション (check_point.mgmt) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:291 -msgid "If you use Ansible 2.9 and the ``fortimanager`` httpapi plugin from this collection, community.network 2.0.0 results in errors when trying to use it by FQCN (``community.network.fortimanager``). Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCN ``fortinet.fortimanager.fortimanager`` and to make sure that you have ``fortinet.fortimanager`` installed." -msgstr "Ansible 2.9 とこのコレクションの ``fortimanager`` httpapi プラグインを使用している場合、community.network 2.0.0 では、FQCN (``community.network.fortimanager``) で使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN ``fortinet.fortimanager.fortimanager`` を使用し、``fortinet.fortimanager`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:294 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``fortinet.fortimanager`` if you are using the ``fortimanager`` httpapi plugin. While ansible-base 2.10 or newer can use the redirect that community.network 2.0.0 adds, the collection they point to (fortinet.fortimanager) must be installed for it to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) し、``fortimanager`` httpapi プラグインを使用している場合は、``fortinet.fortimanager`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (fortinet.fortimanager) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:296 -msgid "If you use Ansible 2.9 and the ``nso`` modules from this collection, community.network 2.0.0 results in errors when trying to use the nso content by FQCN, like ``community.network.nso_config``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``cisco.nso.nso_config`` for the previous example) and to make sure that you have ``cisco.nso`` installed." -msgstr "Ansible 2.9 とこのコレクションの ``nso`` モジュールを使用している場合、community.network 2.0.0 では、``community.network.nso_config`` のように FQCN による nso コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では``cisco.nso.nso_config``) を使用し、``cisco.nso`` がインストールされていることを確認するには、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:299 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``cisco.nso`` if you are using any of the ``nso`` modules. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (cisco.nso) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) し、``nso`` モジュールを使用している場合は、``cisco.nso`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (cisco.nso) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:301 -msgid "If you use Ansible 2.9 and the ``routeros`` plugins or modules from this collections, community.network 2.0.0 results in errors when trying to use the routeros content by FQCN, like ``community.network.routeros_command``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.routeros.command`` for the previous example) and to make sure that you have ``community.routeros`` installed." -msgstr "Ansible 2.9 と、このコレクションの ``routeros`` プラグインやモジュールを使用している場合、community.network 2.0.0 では、``community.network.routeros_command`` のように FQCN による routeros コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``community.routeros.command``) を使用し、``community.routeros`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:304 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.routeros`` if you are using any of the ``routeros`` plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.routeros) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 3.0.0 をインストールせず、手動で community.network をインストール (またはアップグレード) し、``routeros`` プラグインまたはモジュールを使用している場合は、``community.routeros`` もインストールする必要があります。ansible-base 2.10 以降では、community.network 2.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (community.routeros) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_3.rst:306 -msgid "cnos_static_route - move ipaddress import from ansible.netcommon to builtin or package before ipaddress is removed from ansible.netcommon. You need to make sure to have the ipaddress package installed if you are using this module on Python 2.7 (https://github.com/ansible-collections/community.network/pull/129)." -msgstr "cnos_static_route - ansible.netcommon から ipaddress が削除される前に、ansible.netcommon から ipaddress のインポートをビルドインまたはパッケージに移動します。このモジュールを Python 2.7 で使う場合は、ipaddress パッケージがインストールされていることを確認する必要があります (https://github.com/ansible-collections/community.network/pull/129)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:311 -msgid "os10_bgp - Changed \"subnet\" key as list format instead of dictionary format under \"listen\" key to support multiple neighbor prefix for listen command" -msgstr "os10_bgp - listen コマンドの複数の neighbor 接頭辞をサポートするために、「listen」キーの「subnet」キーを、ディクショナリー形式からリスト形式に変更しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:312 -msgid "os10_bgp - Changed \"vrf\" key as list format instead of dictionary format to support multiple VRF in router BGP and changed the \"vrf\" key name to \"vrfs\"" -msgstr "os10_bgp - ルーター BGP で複数の VRF をサポートするために、「vrf」キーをディクショナリー形式ではなくリスト形式に変更し、「vrf」キーの名前を「vrfs」に変更しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:315 -msgid "ngine_io.cloudstack" -msgstr "ngine_io.cloudstack" - -#: ../../rst/porting_guides/porting_guide_3.rst:317 -msgid "Authentication option using INI files for example ``cloudstack.ini``, has been removed. The only supported option to authenticate is by using the module params with fallback to the ENV variables." -msgstr "INI ファイル (例: ``cloudstack.ini``) を使用した認証オプションは削除されました。現在サポートされている認証方法は、ENV 変数にフォールバックしてモジュールパラメーターを使用する方法のみです。" - -#: ../../rst/porting_guides/porting_guide_3.rst:318 -msgid "default zone deprecation - The `zone` param default value, across multiple modules, has been deprecated due to unreliable API (https://github.com/ngine-io/ansible-collection-cloudstack/pull/62)." -msgstr "デフォルトゾーンが非推奨になる - API の信頼性が低いため、複数のモジュール間で `zone` パラメーターのデフォルト値が非推奨になりました (https://github.com/ngine-io/ansible-collection-cloudstack/pull/62)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:324 -msgid "cisco.aci" -msgstr "cisco.aci" - -#: ../../rst/porting_guides/porting_guide_3.rst:326 -msgid "Change certificate_name to name in aci_aaa_user_certificate module for query operation" -msgstr "クエリー操作の certificate_name の名前を aci_aaa_user_certificate モジュールの名前に変更します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:331 -msgid "For community.general 3.0.0, the ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules will be moved to the `dellemc.openmanage `_ collection. A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything." -msgstr "community.general 3.0.0 の場合、``ome_device_info`` モジュール、``idrac_firmware`` モジュール、および ``idrac_server_config_profile`` モジュールは `dellemc.openmanage `_ コレクションに移動します。ansible-base 2.10 以降を使用しているユーザーが何も変更する必要がないようにリダイレクトを挿入します。" - -#: ../../rst/porting_guides/porting_guide_3.rst:334 -msgid "If you use Ansible 2.9 and explicitly use the DellEMC modules mentioned above from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``dellemc.openmanage.`` instead of ``community.general.``, for example replace ``community.general.ome_device_info`` in a task by ``dellemc.openmanage.ome_device_info``." -msgstr "Ansible 2.9 を使用し、このコレクションから上記の DellEMC モジュールを明示的に使用する場合は、Playbook およびロールを ``community.general.`` ではなく ``dellemc.openmanage.`` で始まる FQCN を使用するように調整する必要があります (例: ``dellemc.openmanage.ome_device_info`` によるタスクで ``community.general.ome_device_info`` を置き換えます)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:337 -msgid "If you use ansible-base and installed ``community.general`` manually and rely on the DellEMC modules mentioned above, you have to make sure to install the ``dellemc.openmanage`` collection as well. If you are using FQCNs, for example ``community.general.ome_device_info`` instead of ``ome_device_info``, it will continue working, but we still recommend to adjust the FQCNs as well." -msgstr "ansible-base を使用して ``community.general`` を手動でインストールし、上記の DellEMC モジュールに依存している場合は、``dellemc.openmanage`` コレクションもインストールする必要があります。FQCN を使用している場合、たとえば ``ome_device_info`` の代わりに ``community.general.ome_device_info`` を使用している場合、動作は継続されますが、この FQCN も調整することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:339 -msgid "The community.general collection no longer depends on the ansible.netcommon collection (https://github.com/ansible-collections/community.general/pull/1561)." -msgstr "community.general コレクションは、ansible.netcommon コレクションに依存しなくなりました (https://github.com/ansible-collections/community.general/pull/1561)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:362 -msgid "Removed the existing deprecated modules." -msgstr "既存の非推奨モジュールを削除。" - -#: ../../rst/porting_guides/porting_guide_3.rst:363 -msgid "Standardization of ten iDRAC ansible modules based on ansible guidelines." -msgstr "Ansible ガイドラインに基づく 10 個の iDRAC Ansible モジュールの標準化。" - -#: ../../rst/porting_guides/porting_guide_3.rst:364 -msgid "Support for OpenManage Enterprise Modular." -msgstr "OpenManage Enterprise Modular のサポート。" - -#: ../../rst/porting_guides/porting_guide_3.rst:369 -msgid "os10_bgp - Enhanced router bgp keyword support for non-default vrf which are supported for default vrf and additional keyword to support both default and non-default vrf" -msgstr "os10_bgp - デフォルト vrf に対応している非デフォルト vrf 用のルーター bgp キーワードのサポートを強化し、デフォルトおよび非デフォルトの vrf の両方に対応するための追加キーワードを追加しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:370 -msgid "os10_snmp role - Added support for snmp V3 features in community, group, host, engineID" -msgstr "os10_snmp role - コミュニティー、グループ、ホスト、engineID における snmp V3 機能のサポートを追加しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:380 -#: ../../rst/porting_guides/porting_guide_5.rst:578 -#: ../../rst/porting_guides/porting_guide_5.rst:773 -msgid "kubernetes.core" -msgstr "kubernetes.core" - -#: ../../rst/porting_guides/porting_guide_3.rst:382 -msgid "Add changelog and fragments and document changelog process (https://github.com/ansible-collections/kubernetes.core/pull/131)." -msgstr "変更ログおよびフラグメントを追加し、変更ログプロセスを文書化します (https://github.com/ansible-collections/kubernetes.core/pull/131)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:383 -msgid "helm - New module for managing Helm charts (https://github.com/ansible-collections/kubernetes.core/pull/61)." -msgstr "helm - Helm チャート管理用の新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:384 -msgid "helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/kubernetes.core/pull/61)." -msgstr "helm_info - Helm チャート情報を取得する新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:385 -msgid "helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154)." -msgstr "helm_plugin - Helm プラグインを管理する新しいモジュール (https://github.com/ansible-collections/kubernetes.core/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:386 -msgid "helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154)." -msgstr "helm_plugin_info - Helm プラグインに関する情報を収集する新しいモジュール (https://github.com/ansible-collections/kubernetes.core/pull/154)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:387 -msgid "helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/kubernetes.core/pull/61)." -msgstr "helm_repository - Helm リポジトリーを管理するための新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/61)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:388 -msgid "k8s - Add support for template parameter (https://github.com/ansible-collections/kubernetes.core/pull/230)." -msgstr "k8s - テンプレートパラメーターのサポートを追加します (https://github.com/ansible-collections/kubernetes.core/pull/230)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:392 -msgid "k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/kubernetes.core/pull/193)." -msgstr "k8s_* - Vault 済み kubeconfig および src のサポートを追加します (https://github.com/ansible-collections/kubernetes.core/pull/193)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:395 -msgid "k8s_exec - New module for executing commands on pods through Kubernetes API (https://github.com/ansible-collections/kubernetes.core/pull/14)." -msgstr "k8s_exec - Kubernetes API を使用して Pod でコマンドを実行する新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/14)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:396 -msgid "k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/kubernetes.core/pull/158)." -msgstr "k8s_exec - 実行したコマンドの rc を返します (https://github.com/ansible-collections/kubernetes.core/pull/158)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:398 -msgid "k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/kubernetes.core/pull/16)." -msgstr "k8s_log - Pod ログを取得する新規モジュール (https://github.com/ansible-collections/kubernetes.core/pull/16)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:469 -msgid "All Google cloud modules and plugins have now been migrated away from this collection. They can be found in either the `community.google `_ or `google.cloud `_ collections. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "Google クラウドモジュールおよびプラグインはすべて、このコレクションから移行されました。これらは `community.google `_ コレクションまたは `google.cloud `_ コレクションにあります。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されています。" - -#: ../../rst/porting_guides/porting_guide_3.rst:473 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.gce_img`` → ``community.google.gce_img``) and make sure to install the community.google or google.cloud collections as appropriate." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN を調整 (``community.general.gce_img`` →``community.google.gce_img``) し、必要に応じて community.google コレクションまたは google.cloud collections コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:474 -msgid "All Kubevirt modules and plugins have now been migrated from community.general to the `community.kubevirt `_ Ansible collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての Kubevirt モジュールおよびプラグインは、community.general から `community.kubevirt `_ Ansibleコレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:477 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.kubevirt_vm`` → ``community.kubevirt.kubevirt_vm``) and make sure to install the community.kubevirt collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.kubevirt_vm`` →``community.kubevirt.kubevirt_vm``) を調整し、community.kubevirt コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:478 -msgid "All ``docker`` modules and plugins have been removed from this collection. They have been migrated to the `community.docker `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``docker`` モジュールとプラグインが、このコレクションから削除されました。これらは `community.docker `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:482 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.docker_container`` → ``community.docker.docker_container``) and make sure to install the community.docker collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.docker_container`` →``community.docker.docker_container``) を調整し、community.docker コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:483 -msgid "All ``hetzner`` modules have been removed from this collection. They have been migrated to the `community.hrobot `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``hetzner`` モジュールが、このコレクションから削除されました。これらは `community.hrobot `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:487 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hetzner_firewall`` → ``community.hrobot.firewall``) and make sure to install the community.hrobot collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.hetzner_firewall`` →``community.hrobot.firewall``) を調整し、community.hrobot コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:488 -msgid "All ``postgresql`` modules have been removed from this collection. They have been migrated to the `community.postgresql `_ collection." -msgstr "すべての ``postgresql`` モジュールはこのコレクションから削除されました。これらは `community.postgresql `_ コレクションに移行しました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:491 -msgid "If you use ansible-base 2.10 or newer, redirections have been provided. If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.postgresql_info`` → ``community.postgresql.postgresql_info``) and make sure to install the community.postgresql collection." -msgstr "ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されています。Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.postgresql_info`` →``community.postgresql.postgresql_info``) を調整し、必要に応じて community.postgresql コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:494 -msgid "The ``hashi_vault`` lookup plugin has been removed from this collection. It has been migrated to the `community.hashi_vault `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "``hashi_vault`` lookup プラグインはこのコレクションから削除されました。これは `community.hashi_vault `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されています。" - -#: ../../rst/porting_guides/porting_guide_3.rst:498 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hashi_vault`` → ``community.hashi_vault.hashi_vault``) and make sure to install the community.hashi_vault collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.hashi_vault`` →``community.hashi_vault.hashi_vault``) を調整し、community.hashi_vault コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:499 -msgid "The ``oc`` connection plugin has been removed from this collection. It has been migrated to the `community.okd `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "``oc`` connection プラグインはこのコレクションから削除されました。これは `community.okd `_ コレクションに移行されました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:503 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.oc`` → ``community.okd.oc``) and make sure to install the community.okd collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.oc`` →``community.okd.oc``) を調整し、community.okd コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:504 -msgid "The deprecated ``actionable`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` and ``display_ok_hosts = no`` options instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``actionable`` コールバックプラグインが削除されました。代わりに、``ansible.builtin.default`` コールバックプラグインを ``display_skipped_hosts = no`` オプションおよび ``display_ok_hosts = no`` オプションと一緒に使用してください (https://github.com/ansible-collections/community.general/pull/1347）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:505 -msgid "The deprecated ``foreman`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347) (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``foreman`` モジュールが削除されました。代わりに theforeman.foreman コレクションのモジュールを使用してください (https://github.com/ansible-collections/community.general/pull/1347)(https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:506 -msgid "The deprecated ``full_skip`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` option instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``full_skip`` コールバックプラグインが削除されました。代わりに、``ansible.builtin.default`` コールバックプラグインを ``display_skipped_hosts = no`` オプションと一緒に使用してください (https://github.com/ansible-collections/community.general/pull/1347）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:507 -msgid "The deprecated ``gcdns_record`` module has been removed. Use ``google.cloud.gcp_dns_resource_record_set`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcdns_record`` モジュールが削除されました。代わりに ``google.cloud.gcp_dns_resource_record_set`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:508 -msgid "The deprecated ``gcdns_zone`` module has been removed. Use ``google.cloud.gcp_dns_managed_zone`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcdns_zone`` モジュールが削除されました。代わりに ``google.cloud.gcp_dns_managed_zone`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:509 -msgid "The deprecated ``gce`` module has been removed. Use ``google.cloud.gcp_compute_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gce`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_instance`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:510 -msgid "The deprecated ``gcp_backend_service`` module has been removed. Use ``google.cloud.gcp_compute_backend_service`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_backend_service`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_backend_service`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:511 -msgid "The deprecated ``gcp_forwarding_rule`` module has been removed. Use ``google.cloud.gcp_compute_forwarding_rule`` or ``google.cloud.gcp_compute_global_forwarding_rule`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_forwarding_rule`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_forwarding_rule`` または ``google.cloud.gcp_compute_global_forwarding_rule`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:512 -msgid "The deprecated ``gcp_healthcheck`` module has been removed. Use ``google.cloud.gcp_compute_health_check``, ``google.cloud.gcp_compute_http_health_check`` or ``google.cloud.gcp_compute_https_health_check`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_healthcheck`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_health_check``、``google.cloud.gcp_compute_http_health_check``、または ``google.cloud.gcp_compute_https_health_check`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:513 -msgid "The deprecated ``gcp_target_proxy`` module has been removed. Use ``google.cloud.gcp_compute_target_http_proxy`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_target_proxy`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_target_http_proxy`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:514 -msgid "The deprecated ``gcp_url_map`` module has been removed. Use ``google.cloud.gcp_compute_url_map`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcp_url_map`` モジュールが削除されました。代わりに ``google.cloud.gcp_compute_url_map`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:515 -msgid "The deprecated ``gcspanner`` module has been removed. Use ``google.cloud.gcp_spanner_database`` and/or ``google.cloud.gcp_spanner_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370)." -msgstr "非推奨の ``gcspanner`` モジュールが削除されました。代わりに ``google.cloud.gcp_spanner_database`` や ``google.cloud.gcp_spanner_instance`` を使用してください (https://github.com/ansible-collections/community.general/pull/1370)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:516 -msgid "The deprecated ``github_hooks`` module has been removed. Use ``community.general.github_webhook`` and ``community.general.github_webhook_info`` instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``github_hooks`` モジュールが削除されました。代わりに ``community.general.github_webhook`` および ``community.general.github_webhook_info`` を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:517 -msgid "The deprecated ``katello`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``katello`` モジュールが削除されました。代わりに theforeman.foreman コレクションのモジュールを使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:518 -msgid "The deprecated ``na_cdot_aggregate`` module has been removed. Use netapp.ontap.na_ontap_aggregate instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_aggregate`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_aggregate を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:519 -msgid "The deprecated ``na_cdot_license`` module has been removed. Use netapp.ontap.na_ontap_license instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_license`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_license を使用します (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:520 -msgid "The deprecated ``na_cdot_lun`` module has been removed. Use netapp.ontap.na_ontap_lun instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_lun`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_lun を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:521 -msgid "The deprecated ``na_cdot_qtree`` module has been removed. Use netapp.ontap.na_ontap_qtree instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_qtree`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_qtree を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:522 -msgid "The deprecated ``na_cdot_svm`` module has been removed. Use netapp.ontap.na_ontap_svm instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_svm`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_svm を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:523 -msgid "The deprecated ``na_cdot_user_role`` module has been removed. Use netapp.ontap.na_ontap_user_role instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_user_role`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_user_role を使用します (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:524 -msgid "The deprecated ``na_cdot_user`` module has been removed. Use netapp.ontap.na_ontap_user instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_user`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_user を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:525 -msgid "The deprecated ``na_cdot_volume`` module has been removed. Use netapp.ontap.na_ontap_volume instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``na_cdot_volume`` モジュールが削除されました。代わりに netapp.ontap.na_ontap_volume を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:526 -msgid "The deprecated ``sf_account_manager`` module has been removed. Use netapp.elementsw.na_elementsw_account instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_account_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_account を使用してください (https://github.com/ansible-collections/community.general/pull/1347）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:527 -msgid "The deprecated ``sf_check_connections`` module has been removed. Use netapp.elementsw.na_elementsw_check_connections instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_check_connections`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_check_connections を使用してください (https://github.com/ansible-collections/community.general/pull/1347）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:528 -msgid "The deprecated ``sf_snapshot_schedule_manager`` module has been removed. Use netapp.elementsw.na_elementsw_snapshot_schedule instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_snapshot_schedule_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_snapshot_schedule を使用してください (https://github.com/ansible-collections/community.general/pull/1347）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:529 -msgid "The deprecated ``sf_volume_access_group_manager`` module has been removed. Use netapp.elementsw.na_elementsw_access_group instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_volume_access_group_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_access_group を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:530 -msgid "The deprecated ``sf_volume_manager`` module has been removed. Use netapp.elementsw.na_elementsw_volume instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``sf_volume_manager`` モジュールが削除されました。代わりに netapp.elementsw.na_elementsw_volume を使用してください (https://github.com/ansible-collections/community.general/pull/1347)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:531 -msgid "The deprecated ``stderr`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_failed_stderr = yes`` option instead (https://github.com/ansible-collections/community.general/pull/1347)." -msgstr "非推奨の ``stderr`` コールバックプラグインが削除されました。代わりに、``ansible.builtin.default`` コールバックプラグインを ``display_failed_stderr = yes`` オプションと一緒に使用してください (https://github.com/ansible-collections/community.general/pull/1347）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:532 -msgid "The redirect of the ``conjur_variable`` lookup plugin to ``cyberark.conjur.conjur_variable`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``conjur_variable`` ルックアッププラグインの ``cyberark.conjur.conjur_variable`` コレクションへのリダイレクトが削除されました (https://github.com/ansible-collections/community.general/pull/1346）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:533 -msgid "The redirect of the ``firewalld`` module and the ``firewalld`` module_utils to the ``ansible.posix`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``firewalld`` モジュールおよび ``firewalld`` module_utils の ``ansible.posix`` コレクションへのリダイレクトが削除されました (https://github.com/ansible-collections/community.general/pull/1346）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:534 -msgid "The redirect to the ``community.digitalocean`` collection was removed for: the ``digital_ocean`` doc fragment, the ``digital_ocean`` module_utils, and the following modules: ``digital_ocean``, ``digital_ocean_account_facts``, ``digital_ocean_account_info``, ``digital_ocean_block_storage``, ``digital_ocean_certificate``, ``digital_ocean_certificate_facts``, ``digital_ocean_certificate_info``, ``digital_ocean_domain``, ``digital_ocean_domain_facts``, ``digital_ocean_domain_info``, ``digital_ocean_droplet``, ``digital_ocean_firewall_facts``, ``digital_ocean_firewall_info``, ``digital_ocean_floating_ip``, ``digital_ocean_floating_ip_facts``, ``digital_ocean_floating_ip_info``, ``digital_ocean_image_facts``, ``digital_ocean_image_info``, ``digital_ocean_load_balancer_facts``, ``digital_ocean_load_balancer_info``, ``digital_ocean_region_facts``, ``digital_ocean_region_info``, ``digital_ocean_size_facts``, ``digital_ocean_size_info``, ``digital_ocean_snapshot_facts``, ``digital_ocean_snapshot_info``, ``digital_ocean_sshkey``, ``digital_ocean_sshkey_facts``, ``digital_ocean_sshkey_info``, ``digital_ocean_tag``, ``digital_ocean_tag_facts``, ``digital_ocean_tag_info``, ``digital_ocean_volume_facts``, ``digital_ocean_volume_info`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``community.digitalocean`` コレクションへのリダイレクトが削除されたのは、``digital_ocean`` ドキュメントのフラグメント、``digital_ocean`` module_utils、およびモジュール ``digital_ocean``、``digital_ocean_account_facts``、``digital_ocean_account_info``、``digital_ocean_block_storage``、``digital_ocean_certificate``、``digital_ocean_certificate_facts``、``digital_ocean_certificate_info``、``digital_ocean_domain``、``digital_ocean_domain_facts``、``digital_ocean_domain_info``、``digital_ocean_droplet``、``digital_ocean_firewall_facts``、``digital_ocean_firewall_info``、``digital_ocean_floating_ip``、``digital_ocean_floating_ip_facts``、``digital_ocean_floating_ip_info``、``digital_ocean_image_facts``、``digital_ocean_image_info``、``digital_ocean_load_balancer_facts``、``digital_ocean_load_balancer_info``、``digital_ocean_region_facts``、``digital_ocean_region_info``、``digital_ocean_size_facts``、``digital_ocean_size_info``、``digital_ocean_snapshot_facts``、``digital_ocean_snapshot_info``、``digital_ocean_sshkey``、``digital_ocean_sshkey_facts``、``digital_ocean_sshkey_info``、``digital_ocean_tag``、``digital_ocean_tag_facts``、``digital_ocean_tag_info``、``digital_ocean_volume_facts``、``digital_ocean_volume_info`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:535 -msgid "The redirect to the ``community.mysql`` collection was removed for: the ``mysql`` doc fragment, the ``mysql`` module_utils, and the following modules: ``mysql_db``, ``mysql_info``, ``mysql_query``, ``mysql_replication``, ``mysql_user``, ``mysql_variables`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``community.mysql`` コレクションへのリダイレクトが削除されたのは、``mysql`` ドキュメントのフラグメント、``mysql`` module_utils、およびモジュール ``mysql_db``、``mysql_info``、``mysql_query``、``mysql_replication``、``mysql_user``、``mysql_variables`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:536 -msgid "The redirect to the ``community.proxysql`` collection was removed for: the ``proxysql`` doc fragment, and the following modules: ``proxysql_backend_servers``, ``proxysql_global_variables``, ``proxysql_manage_config``, ``proxysql_mysql_users``, ``proxysql_query_rules``, ``proxysql_replication_hostgroups``, ``proxysql_scheduler`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``community.proxysql`` コレクションへのリダイレクトが削除されたのは、``proxysql`` ドキュメントのフラグメントおよびモジュール ``proxysql_backend_servers``、``proxysql_global_variables``、``proxysql_manage_config``、``proxysql_mysql_users``、``proxysql_query_rules``、``proxysql_replication_hostgroups``、``proxysql_scheduler`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:537 -msgid "The redirect to the ``infinidat.infinibox`` collection was removed for: the ``infinibox`` doc fragment, the ``infinibox`` module_utils, and the following modules: ``infini_export``, ``infini_export_client``, ``infini_fs``, ``infini_host``, ``infini_pool``, ``infini_vol`` (https://github.com/ansible-collections/community.general/pull/1346)." -msgstr "``infinidat.infinibox`` コレクションへのリダイレクトが削除されたのは、``infinibox`` ドキュメントのフラグメント、``infinibox`` module_utils、およびモジュール ``infini_export``、``infini_export_client``、``infini_fs``、``infini_host``、``infini_pool``、``infini_vol`` です (https://github.com/ansible-collections/community.general/pull/1346)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:541 -msgid "iptables_state - the ``ANSIBLE_ASYNC_DIR`` environment is no longer supported, use the ``async_dir`` shell option instead (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "iptables_state - ``ANSIBLE_ASYNC_DIR`` 環境はサポート対象外になったため、代わりに ``async_dir`` シェルオプションを使用してください (https://github.com/ansible-collections/community.general/pull/1371）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:544 -msgid "memcached cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "memcached cache プラグイン - ``CacheModule`` を直接インポートしません。代わりに ``ansible.plugins.loader.cache_loader`` を使用します (https://github.com/ansible-collections/community.general/pull/1371）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:547 -msgid "redis cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "redis cache プラグイン - ``CacheModule`` を直接インポートしません。代わりに ``ansible.plugins.loader.cache_loader`` を使用してください (https://github.com/ansible-collections/community.general/pull/1371）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:548 -msgid "xml - when ``content=attribute``, the ``attribute`` option is ignored (https://github.com/ansible-collections/community.general/pull/1371)." -msgstr "XML - ``content=attribute`` の場合、``attribute`` オプションが無視されます (https://github.com/ansible-collections/community.general/pull/1371）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:553 -msgid "All FortiOS modules and plugins have been removed from this collection. They have been migrated to the `community.fortios `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての FortiOS モジュールとプラグインが、このコレクションから削除されました。これらは `community.fortios `_ コレクションに移行されました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:557 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fmgr_device`` → ``community.fortios.fmgr_device``) and make sure to install the `community.fortios` collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.fmgr_device`` →``community.fortios.fmgr_device``) を調整し、`community.fortios` コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:558 -msgid "All ``nso`` modules have been removed from this collection. They have been migrated to the `cisco.nso `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``nso`` モジュールが、このコレクションから削除されました。これらは `cisco.nso `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:562 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.nso_config`` → ``cisco.nso.nso_config``) and make sure to install the `cisco.nso` collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.nso_config`` →``cisco.nso.nso_config``) を調整し、`cisco.nso` コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:563 -msgid "All ``routeros`` modules and plugins have been removed from this collection. They have been migrated to the `community.routeros `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "すべての ``routeros`` モジュールとプラグインが、このコレクションから削除されました。これらは `community.routeros `_ コレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_3.rst:567 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.routeros_command`` → ``community.routeros.command``) and make sure to install the community.routeros collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN を調整 (``community.network.routeros_command`` →``community.routeros.command``) し、community.routeros コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:568 -msgid "The ``cp_publish`` module has been removed from this collection. It was a duplicate of ``check_point.mgmt.cp_mgmt_publish`` in the `check_point.mgmt `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided. If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.cp_publish`` → ``check_point.mgmt.cp_mgmt_publish``) and make sure to install the check_point.mgmt collection." -msgstr "``cp_publish`` モジュールはこのコレクションから削除されました。これは `check_point.mgmt `_ コレクションの ``check_point.mgmt.cp_mgmt_publish`` と重複していました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.cp_publish`` →``check_point.mgmt.cp_mgmt_publish``) を調整する必要があります。また、check_point.mgmt コレクションをインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:570 -msgid "The ``fortimanager`` httpapi plugin has been removed from this collection. It was a duplicate of the one in the `fortinet.fortimanager `_ collection. If you use ansible-base 2.10 or newer, a redirection has been provided." -msgstr "``fortimanager`` httpapi プラグインはこのコレクションから削除されました。これは `fortinet.fortimanager `_ コレクションにあるものと重複していました。ansible-base 2.10 以降をお使いの方は、リダイレクトが用意されています。" - -#: ../../rst/porting_guides/porting_guide_3.rst:574 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fortimanager`` → ``fortinet.fortimanager.fortimanager``) and make sure to install the `fortinet.fortimanager` collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.network.fortimanager`` →``fortinet.fortimanager.fortimanager``) を調整し、`fortinet.fortimanager` コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:575 -msgid "The dependency on the ``check_point.mgmt`` collection has been removed. If you depend on that installing ``community.network`` also installs ``check_point.mgmt``, you have to make sure to install ``check_point.mgmt`` explicitly." -msgstr "``check_point.mgmt`` コレクションの依存関係が削除されました。``community.network`` のインストールによって ``check_point.mgmt`` もインストールされている場合は、必ず ``check_point.mgmt`` を明示的にインストールする必要があります。" - -#: ../../rst/porting_guides/porting_guide_3.rst:576 -msgid "The deprecated Pluribus Networks modules ``pn_cluster``, ``pn_ospf``, ``pn_ospfarea``, ``pn_show``, ``pn_trunk``, ``pn_vlag``, ``pn_vlan``, ``pn_vrouter``, ``pn_vrouterbgp``, ``pn_vrouterif``, ``pn_vrouterlbif`` have been removed (https://github.com/ansible-collections/community.network/pull/176)." -msgstr "非推奨の Pluribus Networks モジュール ``pn_cluster``、``pn_ospf``、``pn_ospfarea``、``pn_show``、``pn_trunk``、``pn_vlag`` ``pn_vlan``、``pn_vrouter``、``pn_vrouterbgp``、``pn_vrouterif``、および ``pn_vrouterlbif`` が削除されました (https://github.com/ansible-collections/community.network/pull/176）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:577 -msgid "The deprecated modules ``panos_admin``, ``panos_admpwd``, ``panos_cert_gen_ssh``, ``panos_check``, ``panos_commit``, ``panos_dag``, ``panos_dag_tags``, ``panos_import``, ``panos_interface``, ``panos_lic``, ``panos_loadcfg``, ``panos_match_rule``, ``panos_mgtconfig``, ``panos_nat_rule``, ``panos_object``, ``panos_op``, ``panos_pg``, ``panos_query_rules``, ``panos_restart``, ``panos_sag``, ``panos_security_rule``, ``panos_set`` have been removed. Use modules from the `paloaltonetworks.panos collection `_ instead (https://github.com/ansible-collections/community.network/pull/176)." -msgstr "非推奨のモジュール ``panos_admin``、``panos_admpwd``、``panos_cert_gen_ssh``、``panos_check``、``panos_commit``、``panos_dag``、``panos_dag_tags`` ``panos_import``、``panos_interface``、``panos_lic``、``panos_loadcfg``、``panos_match_rule``、``panos_mgtconfig``、``panos_nat_rule``、``panos_object``、``panos_op``、``panos_pg``、``panos_query_rules``、``panos_restart``、``panos_sag``、``panos_security_rule``、および ``panos_set`` が削除されました。代わりに `paloaltonetworks.panos collection `_ のモジュールを使用します (https://github.com/ansible-collections/community.network/pull/176）。" - -#: ../../rst/porting_guides/porting_guide_3.rst:578 -msgid "The redirect to the ``mellanox.onyx`` collection was removed for: the ``onyx`` cliconf plugin, terminal plugin, module_utils, action plugin, doc fragment, and the following modules: ``onyx_aaa``, ``onyx_bfd``, ``onyx_bgp``, ``onyx_buffer_pool``, ``onyx_command``, ``onyx_config``, ``onyx_facts``, ``onyx_igmp``, ``onyx_igmp_interface``, ``onyx_igmp_vlan``, ``onyx_interface``, ``onyx_l2_interface``, ``onyx_l3_interface``, ``onyx_linkagg``, ``onyx_lldp``, ``onyx_lldp_interface``, ``onyx_magp``, ``onyx_mlag_ipl``, ``onyx_mlag_vip``, ``onyx_ntp``, ``onyx_ntp_servers_peers``, ``onyx_ospf``, ``onyx_pfc_interface``, ``onyx_protocol``, ``onyx_ptp_global``, ``onyx_ptp_interface``, ``onyx_qos``, ``onyx_snmp``, ``onyx_snmp_hosts``, ``onyx_snmp_users``, ``onyx_syslog_files``, ``onyx_syslog_remote``, ``onyx_traffic_class``, ``onyx_username``, ``onyx_vlan``, ``onyx_vxlan``, ``onyx_wjh`` (https://github.com/ansible-collections/community.network/pull/175)." -msgstr "``mellanox.onyx`` コレクションへのリダイレクトが削除されたのは、``onyx`` cliconf プラグイン、ターミナルプラグイン、module_utils、action プラグイン、ドキュメントのフラグメント、およびモジュール ``onyx_aaa``、``onyx_bfd``、``onyx_bgp``、``onyx_buffer_pool``、``onyx_command``、``onyx_config``、``onyx_facts``、``onyx_igmp``、``onyx_igmp_interface``、``onyx_igmp_vlan``、``onyx_interface``、``onyx_l2_interface``、``onyx_l3_interface``、``onyx_linkagg``、``onyx_lldp``、``onyx_lldp_interface``、``onyx_magp``、``onyx_mlag_ipl``、``onyx_mlag_vip``、``onyx_ntp``、``onyx_ntp_servers_peers``、``onyx_ospf``、``onyx_pfc_interface``、``onyx_protocol``、``onyx_ptp_global``、``onyx_ptp_interface``、``onyx_qos``、``onyx_snmp``、``onyx_snmp_hosts``、``onyx_snmp_users``、``onyx_syslog_files``、``onyx_syslog_remote``、``onyx_traffic_class``、``onyx_username``、``onyx_vlan``、``onyx_vxlan``、``onyx_wjh`` です (https://github.com/ansible-collections/community.network/pull/175)。" - -#: ../../rst/porting_guides/porting_guide_3.rst:610 -msgid "The ``gluster_heal_info``, ``gluster_peer`` and ``gluster_volume`` modules have migrated to the `gluster.gluster `_ collection. Ansible-base 2.10.1 adjusted the routing target to point to the modules in that collection, so we will remove these modules in community.general 3.0.0. If you use Ansible 2.9, or use FQCNs ``community.general.gluster_*`` in your playbooks and/or roles, please update them to use the modules from ``gluster.gluster`` instead." -msgstr "``gluster_heal_info`` モジュール、``gluster_peer`` モジュール、および ``gluster_volume`` モジュールは `gluster.gluster `_ コレクションに移行しました。Ansible-base 2.10.1 では、ルーティングターゲットがこのコレクションのモジュールを参照するように調整されたため、community.general 3.0.0 でこれらのモジュールを削除する予定です。Ansible 2.9 を使用している場合や、Playbook やロールで FQCN の ``community.general.gluster_*`` を使用している場合は、代わりにこれらをアップデートして ``gluster.gluster`` のモジュールを使用するようにしてください。" - -#: ../../rst/porting_guides/porting_guide_3.rst:641 -msgid "The ``dellemc_get_firmware_inventory`` module is deprecated and replaced with ``idrac_firmware_info``." -msgstr "``dellemc_get_firmware_inventory`` モジュールは非推奨となり、``idrac_firmware_info`` に置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:642 -msgid "The ``dellemc_get_system_inventory`` module is deprecated and replaced with ``idrac_system_info``." -msgstr "``dellemc_get_system_inventory`` モジュールは非推奨となり、``idrac_system_info`` に置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:643 -msgid "The dellemc_change_power_state module is deprecated and replaced with the redfish_powerstate module." -msgstr "dellemc_change_power_state モジュールは非推奨となり、redfish_powerstate モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:644 -msgid "The dellemc_configure_bios module is deprecated and replaced with the idrac_bios module." -msgstr "dellemc_configure_bios モジュールは非推奨となり、idrac_bios モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:645 -msgid "The dellemc_configure_idrac_network module is deprecated and replaced with the idrac_network module." -msgstr "dellemc_configure_idrac_network モジュールは非推奨となり、idrac_network モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:646 -msgid "The dellemc_configure_idrac_timezone module is deprecated and replaced with the idrac_timezone_ntp module." -msgstr "dellemc_configure_idrac_timezone モジュールは非推奨となり、idrac_timezone_ntp モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:647 -msgid "The dellemc_configure_idrac_users module is deprecated and replaced with the idrac_user module." -msgstr "dellemc_configure_idrac_users モジュールは非推奨となり、idrac_user モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:648 -msgid "The dellemc_delete_lc_job and dellemc_delete_lc_job_queue modules are deprecated and replaced with the idrac_lifecycle_controller_jobs module." -msgstr "dellemc_delete_lc_job モジュールおよび dellemc_delete_lc_job_queue モジュールは非推奨となり、idrac_lifecycle_controller_jobs モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:649 -msgid "The dellemc_export_lc_logs module is deprecated and replaced with the idrac_lifecycle_controller_logs module." -msgstr "dellemc_export_lc_logs モジュールは非推奨となり、idrac_lifecycle_controller_logs モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:650 -msgid "The dellemc_get_lc_job_status module is deprecated and replaced with the idrac_lifecycle_controller_job_status_info module." -msgstr "dellemc_get_lc_job_status モジュールは非推奨となり、idrac_lifecycle_controller_job_status_info モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:651 -msgid "The dellemc_get_lcstatus module is deprecated and replaced with the idrac_lifecycle_controller_status_info module." -msgstr "dellemc_get_lcstatus モジュールは非推奨となり、idrac_lifecycle_controller_status_info モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:652 -msgid "The dellemc_idrac_reset module is deprecated and replaced with the idrac_reset module." -msgstr "dellemc_idrac_reset モジュールは非推奨となり、idrac_reset モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_3.rst:653 -msgid "The dellemc_setup_idrac_syslog module is deprecated and replaced with the idrac_syslog module." -msgstr "dellemc_setup_idrac_syslog モジュールは非推奨となり、idrac_syslog モジュールに置き換えられました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:8 -msgid "Ansible 4 Porting Guide" -msgstr "Ansible 4 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:15 -msgid "We suggest you read this page along with the `Ansible 4 Changelog `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible 4 Changelog `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:20 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:23 -msgid "The ``jinja2_native`` setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argument ``jinja2_native`` (off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on the ``jinja2_native`` setting." -msgstr "``jinja2_native`` 設定は、暗黙的に文字列を返すテンプレートモジュールには影響を及ぼしません。テンプレートの検索では、その機能を制御する新しい引数 ``jinja2_native`` (デフォルトでは off) が追加されました。残りの Jinja2 式は、``jinja2_native`` 設定に基づいて動作します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:26 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:29 -msgid "The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth has been shut down. Publishing roles or collections to Galaxy with ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI using a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) with the ``--token`` argument to ``ansible-galaxy``." -msgstr "GitHub 認証に使用される基礎となる API がシャットダウンされるため、``ansible-galaxy login`` コマンドが削除されました。``ansible-galaxy`` 経由で Galaxy にロールまたはコレクションを公開する場合は、Galaxy API トークンをトークンファイル (デフォルトの場所 ``~/.ansible/galaxy_token``) または ``--token`` 引数から ``ansible-galaxy`` に (セキュリティーを確保せずに) 渡すことが必要になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:32 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:35 -msgid "The constant ``ansible.module_utils.basic._CHECK_ARGUMENT_TYPES_DISPATCHER`` is deprecated. Use :const:`ansible.module_utils.common.parameters.DEFAULT_TYPE_VALIDATORS` instead." -msgstr "定数 ``ansible.module_utils.basic._CHECK_ARGUMENT_TYPES_DISPATCHER`` は廃止されました。代わりに :const:`ansible.module_utils.common.parameters.DEFAULT_TYPE_VALIDATORS` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:39 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:42 -msgid "Changes to ``AnsibleModule``" -msgstr "``AnsibleModule`` の変更点" - -#: ../../rst/porting_guides/porting_guide_4.rst:41 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:44 -msgid "With the move to :class:`ArgumentSpecValidator ` for performing argument spec validation, the following private methods in :class:`AnsibleModule ` have been removed:" -msgstr "引数仕様の検証を実行するために :class:`ArgumentSpecValidator ` に移行したことで、:class:`AnsibleModule ` にある以下のプライベートメソッドが削除されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:43 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:46 -msgid "``_check_argument_types()``" -msgstr "``_check_argument_types()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:44 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:47 -msgid "``_check_argument_values()``" -msgstr "``_check_argument_values()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:45 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:48 -msgid "``_check_arguments()``" -msgstr "``_check_arguments()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:46 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:49 -msgid "``_check_mutually_exclusive()`` --> :func:`ansible.module_utils.common.validation.check_mutually_exclusive`" -msgstr "``_check_mutually_exclusive()`` --> :func:`ansible.module_utils.common.validation.check_mutually_exclusive`" - -#: ../../rst/porting_guides/porting_guide_4.rst:47 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:50 -msgid "``_check_required_arguments()`` --> :func:`ansible.module_utils.common.validation.check_required_arguments`" -msgstr "``_check_required_arguments()`` --> :func:`ansible.module_utils.common.validation.check_required_arguments`" - -#: ../../rst/porting_guides/porting_guide_4.rst:48 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:51 -msgid "``_check_required_by()`` --> :func:`ansible.module_utils.common.validation.check_required_by`" -msgstr "``_check_required_by()`` --> :func:`ansible.module_utils.common.validation.check_required_by`" - -#: ../../rst/porting_guides/porting_guide_4.rst:49 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:52 -msgid "``_check_required_if()`` --> :func:`ansible.module_utils.common.validation.check_required_if`" -msgstr "``_check_required_if()`` --> :func:`ansible.module_utils.common.validation.check_required_if`" - -#: ../../rst/porting_guides/porting_guide_4.rst:50 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:53 -msgid "``_check_required_one_of()`` --> :func:`ansible.module_utils.common.validation.check_required_one_of`" -msgstr "``_check_required_one_of()`` --> :func:`ansible.module_utils.common.validation.check_required_one_of`" - -#: ../../rst/porting_guides/porting_guide_4.rst:51 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:54 -msgid "``_check_required_together()`` --> :func:`ansible.module_utils.common.validation.check_required_together`" -msgstr "``_check_required_together()`` --> :func:`ansible.module_utils.common.validation.check_required_together`" - -#: ../../rst/porting_guides/porting_guide_4.rst:52 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:55 -msgid "``_check_type_bits()`` --> :func:`ansible.module_utils.common.validation.check_type_bits`" -msgstr "``_check_type_bits()`` --> :func:`ansible.module_utils.common.validation.check_type_bits`" - -#: ../../rst/porting_guides/porting_guide_4.rst:53 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:56 -msgid "``_check_type_bool()`` --> :func:`ansible.module_utils.common.validation.check_type_bool`" -msgstr "``_check_type_bool()`` --> :func:`ansible.module_utils.common.validation.check_type_bool`" - -#: ../../rst/porting_guides/porting_guide_4.rst:54 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:57 -msgid "``_check_type_bytes()`` --> :func:`ansible.module_utils.common.validation.check_type_bytes`" -msgstr "``_check_type_bytes()`` --> :func:`ansible.module_utils.common.validation.check_type_bytes`" - -#: ../../rst/porting_guides/porting_guide_4.rst:55 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:58 -msgid "``_check_type_dict()`` --> :func:`ansible.module_utils.common.validation.check_type_dict`" -msgstr "``_check_type_dict()`` --> :func:`ansible.module_utils.common.validation.check_type_dict`" - -#: ../../rst/porting_guides/porting_guide_4.rst:56 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:59 -msgid "``_check_type_float()`` --> :func:`ansible.module_utils.common.validation.check_type_float`" -msgstr "``_check_type_float()`` --> :func:`ansible.module_utils.common.validation.check_type_float`" - -#: ../../rst/porting_guides/porting_guide_4.rst:57 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:60 -msgid "``_check_type_int()`` --> :func:`ansible.module_utils.common.validation.check_type_int`" -msgstr "``_check_type_int()`` --> :func:`ansible.module_utils.common.validation.check_type_int`" - -#: ../../rst/porting_guides/porting_guide_4.rst:58 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:61 -msgid "``_check_type_jsonarg()`` --> :func:`ansible.module_utils.common.validation.check_type_jsonarg`" -msgstr "``_check_type_jsonarg()`` --> :func:`ansible.module_utils.common.validation.check_type_jsonarg`" - -#: ../../rst/porting_guides/porting_guide_4.rst:59 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:62 -msgid "``_check_type_list()`` --> :func:`ansible.module_utils.common.validation.check_type_list`" -msgstr "``_check_type_list()`` --> :func:`ansible.module_utils.common.validation.check_type_list`" - -#: ../../rst/porting_guides/porting_guide_4.rst:60 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:63 -msgid "``_check_type_path()`` --> :func:`ansible.module_utils.common.validation.check_type_path`" -msgstr "``_check_type_path()`` --> :func:`ansible.module_utils.common.validation.check_type_path`" - -#: ../../rst/porting_guides/porting_guide_4.rst:61 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:64 -msgid "``_check_type_raw()`` --> :func:`ansible.module_utils.common.validation.check_type_raw`" -msgstr "``_check_type_raw()`` --> :func:`ansible.module_utils.common.validation.check_type_raw`" - -#: ../../rst/porting_guides/porting_guide_4.rst:62 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:65 -msgid "``_check_type_str()`` --> :func:`ansible.module_utils.common.validation.check_type_str`" -msgstr "``_check_type_str()`` --> :func:`ansible.module_utils.common.validation.check_type_str`" - -#: ../../rst/porting_guides/porting_guide_4.rst:63 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:66 -msgid "``_count_terms()`` --> :func:`ansible.module_utils.common.validation.count_terms`" -msgstr "``_count_terms()`` --> :func:`ansible.module_utils.common.validation.count_terms`" - -#: ../../rst/porting_guides/porting_guide_4.rst:64 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:67 -msgid "``_get_wanted_type()``" -msgstr "``_get_wanted_type()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:65 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:68 -msgid "``_handle_aliases()``" -msgstr "``_handle_aliases()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:66 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:69 -msgid "``_handle_no_log_values()``" -msgstr "``_handle_no_log_values()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:67 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:70 -msgid "``_handle_options()``" -msgstr "``_handle_options()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:68 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:71 -msgid "``_set_defaults()``" -msgstr "``_set_defaults()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:69 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:72 -msgid "``_set_fallbacks()``" -msgstr "``_set_fallbacks()``" - -#: ../../rst/porting_guides/porting_guide_4.rst:71 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:74 -msgid "Modules or plugins using these private methods should use the public functions in :mod:`ansible.module_utils.common.validation` or :meth:`ArgumentSpecValidator.validate() ` if no public function was listed above." -msgstr "これらのプライベートメソッドを使用するモジュールまたはプラグインは、:mod:`ansible.module_utils.common.validation` の公開関数 (公開関数が上記の一覧に記載されていない場合は :meth:`ArgumentSpecValidator.validate() `) を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:75 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:78 -msgid "Changes to :mod:`ansible.module_utils.common.parameters`" -msgstr ":mod:`ansible.module_utils.common.parameters` の変更点" - -#: ../../rst/porting_guides/porting_guide_4.rst:77 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:80 -msgid "The following functions in :mod:`ansible.module_utils.common.parameters` are now private and should not be used directly. Use :meth:`ArgumentSpecValidator.validate() ` instead." -msgstr ":mod:`ansible.module_utils.common.parameters` の以下の機能はプライベートであるため、直接使用しないでください。代わりに :meth:`ArgumentSpecValidator.validate() ` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:79 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:82 -msgid "``list_no_log_values``" -msgstr "``list_no_log_values``" - -#: ../../rst/porting_guides/porting_guide_4.rst:80 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:83 -msgid "``list_deprecations``" -msgstr "``list_deprecations``" - -#: ../../rst/porting_guides/porting_guide_4.rst:81 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:84 -msgid "``handle_aliases``" -msgstr "``handle_aliases``" - -#: ../../rst/porting_guides/porting_guide_4.rst:85 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:88 -msgid "Other" -msgstr "その他" - -#: ../../rst/porting_guides/porting_guide_4.rst:87 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:90 -msgid "**Upgrading**: If upgrading from ``ansible < 2.10`` or from ``ansible-base`` and using pip, you must ``pip uninstall ansible`` or ``pip uninstall ansible-base`` before installing ``ansible-core`` to avoid conflicts." -msgstr "**アップグレード**: ``ansible < 2.10`` または ``ansible-base`` からアップグレードして pip を使用している場合は、``ansible-core`` をインストールする前に、``pip uninstall ansible`` または ``pip uninstall ansible-base`` を指定して競合を回避する必要があります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:88 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:91 -msgid "Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 still works with the same versions of Python that ``ansible-base`` 2.10 worked with, however 2.11 emits a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater." -msgstr "コントローラーノードの Python 3.8 は、本リリースではソフト要件です。``ansible-core`` 2.11 は、``ansible-base`` 2.10 が動作したのと同じバージョンの Python で引き続き機能しますが、2.11 では、Python バージョンが 3.8 未満のコントローラーノードで実行すると警告が表示されます。この警告は、お使いの環境に ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` を設定して無効にできます。``ansible-core`` 2.12 の場合は Python 3.8 以降が必要になります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:89 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:92 -msgid "The configuration system now validates the ``choices`` field, so any settings that violate it and were ignored in 2.10 cause an error in 2.11. For example, ``ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0`` now causes an error (valid choices are ``ignore``, ``warn`` or ``error``)." -msgstr "設定システムは ``choices`` フィールドを検証し、これを違反し、2.10 で無視されていたすべての設定が 2.11 でエラーとなるようになりました。たとえば、``ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0`` でエラーが発生するようになりました (有効な選択肢は ``ignore``、``warn``、``error``です)。" - -#: ../../rst/porting_guides/porting_guide_4.rst:90 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:93 -msgid "The ``ansible-galaxy`` command now uses ``resolvelib`` for resolving dependencies. In most cases this should not make a user-facing difference beyond being more performant, but we note it here for posterity and completeness." -msgstr "``ansible-galaxy`` コマンドでは、依存関係の解決に ``resolvelib`` が使用されます。ほとんどの場合、パフォーマンスが向上するだけで、ユーザーにとっては何の変化もありませんが、記録のためにここに記しておきます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:91 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:94 -msgid "If you import Python ``module_utils`` into any modules you maintain, you may now mark the import as optional during the module payload build by wrapping the ``import`` statement in a ``try`` or ``if`` block. This allows modules to use ``module_utils`` that may not be present in all versions of Ansible or a collection, and to perform arbitrary recovery or fallback actions during module runtime." -msgstr "Python ``module_utils`` を、メンテナンスするモジュールにインポートする場合は、``try`` ブロックまたは ``if`` ブロックの ``import`` ステートメントをラップして、モジュールペイロードの構築時にインポートをオプションとマークできるようになりました。これにより、モジュールはすべてのバージョンの Ansible またはコレクションに存在しない ``module_utils`` を使用し、モジュールランタイム時の任意のリカバリーまたはフォールバックのアクションを実行できます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:97 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:100 -msgid "The ``apt_key`` module has explicitly defined ``file`` as mutually exclusive with ``data``, ``keyserver`` and ``url``. They cannot be used together anymore." -msgstr "``apt_key`` モジュールは、``data``、``keyserver``、および ``url`` と相互に排他的なものとして、``file`` を明示的に定義します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:98 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:101 -msgid "The ``meta`` module now supports tags for user-defined tasks. Set the task's tags to 'always' to maintain the previous behavior. Internal ``meta`` tasks continue to always run." -msgstr "``meta`` モジュールは、ユーザー定義のタスクのタグをサポートするようになりました。以前の動作を維持するために、タスクのタグを「always」に設定します。内部の ``meta`` タスクは常に実行を継続します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:118 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:121 -msgid "facts - On NetBSD, ``ansible_virtualization_type`` now tries to report a more accurate result than ``xen`` when virtualized and not running on Xen." -msgstr "ファクト - NetBSD において、Xen 上で仮想化されていて実行していない場合、``ansible_virtualization_type`` は、``xen`` よりも正確な結果を報告しようとするようになりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:119 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:122 -msgid "facts - Virtualization facts now include ``virtualization_tech_guest`` and ``virtualization_tech_host`` keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, if you set up a host to provide both KVM and VirtualBox, both values are included in ``virtualization_tech_host``. Similarly, a podman container running on a VM powered by KVM has a ``virtualization_tech_guest`` of ``[\"kvm\", \"podman\", \"container\"]``." -msgstr "ファクト: 仮想化ファクトに ``virtualization_tech_guest`` キーおよび ``virtualization_tech_host`` キーが含まれるようになりました。以下は、ゲストが、またはホストが提供する仮想化テクノロジーの一覧です。たとえば、KVM と VirtualBox の両方を提供するホストを設定する場合は、両方の値が ``virtualization_tech_host`` に組み込まれます。同様に、KVM が対応する仮想マシンで実行している podman コンテナーには、 ``[\"kvm\", \"podman\", \"container\"]`` の ``virtualization_tech_guest`` があります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:120 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:123 -msgid "The parameter ``filter`` type is changed from ``string`` to ``list`` in the :ref:`setup ` module in order to use more than one filter. Previous behavior (using a ``string``) still remains and works as a single filter." -msgstr "複数のフィルターを使用するために、パラメーター ``filter`` タイプは :ref:`setup ` モジュールの ``string`` から ``list`` に変更されています。以前の動作は (``string`` を使用) はそのままで、単一のフィルターとして機能します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:126 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:129 -msgid "inventory plugins - ``CachePluginAdjudicator.flush()`` now calls the underlying cache plugin's ``flush()`` instead of only deleting keys that it knows about. Inventory plugins should use ``delete()`` to remove any specific keys. As a user, this means that when an inventory plugin calls its ``clear_cache()`` method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache." -msgstr "インベントリープラグイン - ``CachePluginAdjudicator.flush()`` は、認識している鍵を削除するのではなく、基礎となるキャッシュプラグインの ``flush()`` を呼び出すようになりました。インベントリープラグインは、``delete()`` を使用して特定キーを削除する必要があります。ユーザーとして、インベントリープラグインが ``clear_cache()`` メソッドを呼び出すと、ファクトをキャッシュからフラッシュすることもできます。これを回避するには、ファクトキャッシュから独立したキャッシュバックエンドを使用するようにインベントリープラグインを設定できます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:127 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:130 -msgid "callback plugins - ``meta`` task execution is now sent to ``v2_playbook_on_task_start`` like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation." -msgstr "callback プラグイン - ``meta`` タスクの実行は、他のタスクと同様に ``v2_playbook_on_task_start`` に送られるようになりました。デフォルトでは、明示的なメタタスクのみが送信されます。コールバックプラグインは、プラグイン開発のドキュメントにあるように、内部で暗黙的に作成されたタスクを受け取って、それらにも対処することを選択できます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:128 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:131 -msgid "The ``choices`` are now validated, so plugins that were using incorrect or incomplete choices issue an error in 2.11 if the value provided does not match. This has a simple fix: update the entries in ``choices`` to match reality." -msgstr "``choices`` が検証されるようになったため、誤った選択、または不完全な選択を使用していたプラグインが、2.11 では提供された値が一致しない場合にエラーになるようになりました。これは簡単に修正できます。実際の設定に合わせて ``choices`` のエントリーを更新してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:136 -msgid "Porting Guide for v4.10.0" -msgstr "v4.10.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:142 -#: ../../rst/porting_guides/porting_guide_4.rst:257 -#: ../../rst/porting_guides/porting_guide_5.rst:375 -#: ../../rst/porting_guides/porting_guide_5.rst:731 -#: ../../rst/porting_guides/porting_guide_6.rst:130 -#: ../../rst/porting_guides/porting_guide_6.rst:719 -#: ../../rst/porting_guides/porting_guide_7.rst:247 -msgid "containers.podman" -msgstr "containers.podman" - -#: ../../rst/porting_guides/porting_guide_4.rst:144 -#: ../../rst/porting_guides/porting_guide_5.rst:377 -#: ../../rst/porting_guides/porting_guide_6.rst:721 -msgid "Add podman_tag module" -msgstr "podman_tag モジュールの追加" - -#: ../../rst/porting_guides/porting_guide_4.rst:145 -#: ../../rst/porting_guides/porting_guide_5.rst:378 -#: ../../rst/porting_guides/porting_guide_6.rst:722 -msgid "Add secrets driver and driver opts support" -msgstr "シークレットドライバーおよびドライバーオプションのサポートの追加" - -#: ../../rst/porting_guides/porting_guide_4.rst:153 -#: ../../rst/porting_guides/porting_guide_5.rst:394 -#: ../../rst/porting_guides/porting_guide_6.rst:915 -msgid "Deprecated nxos_snmp_community module." -msgstr "nxos_snmp_community モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:154 -#: ../../rst/porting_guides/porting_guide_5.rst:395 -#: ../../rst/porting_guides/porting_guide_6.rst:916 -msgid "Deprecated nxos_snmp_contact module." -msgstr "nxos_snmp_contact モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:155 -#: ../../rst/porting_guides/porting_guide_5.rst:396 -#: ../../rst/porting_guides/porting_guide_6.rst:917 -msgid "Deprecated nxos_snmp_host module." -msgstr "nxos_snmp_host モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:156 -#: ../../rst/porting_guides/porting_guide_5.rst:397 -#: ../../rst/porting_guides/porting_guide_6.rst:918 -msgid "Deprecated nxos_snmp_location module." -msgstr "nxos_snmp_location モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:157 -#: ../../rst/porting_guides/porting_guide_5.rst:398 -#: ../../rst/porting_guides/porting_guide_6.rst:919 -msgid "Deprecated nxos_snmp_traps module." -msgstr "nxos_snmp_traps モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:158 -#: ../../rst/porting_guides/porting_guide_5.rst:399 -#: ../../rst/porting_guides/porting_guide_6.rst:920 -msgid "Deprecated nxos_snmp_user module." -msgstr "nxos_snmp_user モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:161 -#: ../../rst/porting_guides/porting_guide_4.rst:246 -#: ../../rst/porting_guides/porting_guide_4.rst:306 -#: ../../rst/porting_guides/porting_guide_4.rst:340 -#: ../../rst/porting_guides/porting_guide_4.rst:673 -#: ../../rst/porting_guides/porting_guide_5.rst:413 -#: ../../rst/porting_guides/porting_guide_5.rst:1022 -#: ../../rst/porting_guides/porting_guide_6.rst:755 -#: ../../rst/porting_guides/porting_guide_6.rst:957 -#: ../../rst/porting_guides/porting_guide_7.rst:671 -#: ../../rst/porting_guides/porting_guide_7.rst:912 -msgid "junipernetworks.junos" -msgstr "junipernetworks.junos" - -#: ../../rst/porting_guides/porting_guide_4.rst:163 -#: ../../rst/porting_guides/porting_guide_5.rst:415 -#: ../../rst/porting_guides/porting_guide_6.rst:959 -msgid "'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resuorce module." -msgstr "junos_ospf_interfaces、junos_ospfv2、および junos_ospfv3リソースモジュールの'router_id' オプションが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:166 -msgid "Porting Guide for v4.9.0" -msgstr "v4.9.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:174 -#: ../../rst/porting_guides/porting_guide_5.rst:457 -msgid "purefb_lag - The mac_address field in the response is not populated. This will be fixed in a future FlashBlade update." -msgstr "purefb_lag - 応答の mac_address フィールドに値が反映されません。これは今後の FlashBlade の更新で修正される予定です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:180 -#: ../../rst/porting_guides/porting_guide_4.rst:395 -#: ../../rst/porting_guides/porting_guide_4.rst:456 -#: ../../rst/porting_guides/porting_guide_4.rst:536 -#: ../../rst/porting_guides/porting_guide_4.rst:577 -#: ../../rst/porting_guides/porting_guide_4.rst:665 -#: ../../rst/porting_guides/porting_guide_4.rst:820 -#: ../../rst/porting_guides/porting_guide_5.rst:143 -#: ../../rst/porting_guides/porting_guide_5.rst:223 -#: ../../rst/porting_guides/porting_guide_5.rst:746 -#: ../../rst/porting_guides/porting_guide_6.rst:142 -#: ../../rst/porting_guides/porting_guide_6.rst:267 -#: ../../rst/porting_guides/porting_guide_6.rst:738 -#: ../../rst/porting_guides/porting_guide_7.rst:253 -#: ../../rst/porting_guides/porting_guide_7.rst:657 -msgid "fortinet.fortios" -msgstr "fortinet.fortios" - -#: ../../rst/porting_guides/porting_guide_4.rst:182 -#: ../../rst/porting_guides/porting_guide_5.rst:748 -msgid "Add real-world use cases in the example section for some configuration modules." -msgstr "一部の設定モジュールの例のセクションに、実際のユースケースを追加しました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:183 -#: ../../rst/porting_guides/porting_guide_5.rst:749 -msgid "Collect the current configurations of the modules and convert them into playbooks." -msgstr "モジュールの現在の設定を収集し、それらを Playbook に変換します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:184 -#: ../../rst/porting_guides/porting_guide_5.rst:752 -msgid "Support FortiOS 7.0.1." -msgstr "FortiOS 7.0.1 をサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:185 -#: ../../rst/porting_guides/porting_guide_5.rst:757 -msgid "Support member operation (delete/add extra members) on an object that has a list of members in it." -msgstr "メンバーの一覧が含まれるオブジェクトでのメンバー操作（追加メンバーの削除/追加）をサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:186 -#: ../../rst/porting_guides/porting_guide_5.rst:759 -msgid "Support selectors feature in ``fortios_monitor_fact`` and ``fortios_log_fact``." -msgstr "``fortios_monitor_fact`` および ``fortios_log_fact`` のセレクター機能をサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:189 -msgid "Porting Guide for v4.8.0" -msgstr "v4.8.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:197 -msgid "all roles now reference other roles and modules through their fully qualified collection names, which makes Ansible 2.10 minimum supported version for roles (see `issue 477 `_)." -msgstr "すべてのロールは、完全修飾コレクション名で他のロールおよびモジュールを参照するようになりました。これにより、ロールのAnsible 2.10 最低サポートバージョンを作成します (`issue 477 `_ を参照してください)。" - -#: ../../rst/porting_guides/porting_guide_4.rst:203 -#: ../../rst/porting_guides/porting_guide_5.rst:943 -#: ../../rst/porting_guides/porting_guide_7.rst:781 -msgid "community.azure" -msgstr "community.azure" - -#: ../../rst/porting_guides/porting_guide_4.rst:205 -#: ../../rst/porting_guides/porting_guide_5.rst:945 -msgid "All community.azure.azure_rm__facts modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24)." -msgstr "すべての community.azure.azure_rm__facts モジュールが非推奨になりました。代わりに azure.azcollection.azure_rm__info モジュールを使用してください（https://github.com/ansible-collections/community.azure/pull/24）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:206 -#: ../../rst/porting_guides/porting_guide_5.rst:946 -msgid "All community.azure.azure_rm__info modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24)." -msgstr "すべての community.azure.azure_rm__info モジュールが非推奨になりました。代わりに azure.azcollection.azure_rm__info モジュールを使用してください（https://github.com/ansible-collections/community.azure/pull/24）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:207 -#: ../../rst/porting_guides/porting_guide_5.rst:947 -msgid "community.azure.azure_rm_managed_disk and community.azure.azure_rm_manageddisk are deprecated. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/24)." -msgstr "community.azure.azure_rm_managed_disk および community.azure.azure_rm_manageddisk は非推奨になりました。代わりに azure.azcollection.azure_rm_manageddisk を使用してください（https://github.com/ansible-collections/community.azure/pull/24）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:208 -#: ../../rst/porting_guides/porting_guide_5.rst:948 -msgid "community.azure.azure_rm_virtualmachine_extension and community.azure.azure_rm_virtualmachineextension are deprecated. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/24)." -msgstr "community.azure.azure_rm_virtualmachine_extension および community.azure.azure_rm_virtualmachineextension は非推奨になりました。代わりに azure.azcollection.azure_rm_virtualmachineextension を使用してください（https://github.com/ansible-collections/community.azure/pull/24）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:209 -#: ../../rst/porting_guides/porting_guide_5.rst:949 -msgid "community.azure.azure_rm_virtualmachine_scaleset and community.azure.azure_rm_virtualmachinescaleset are deprecated. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/24)." -msgstr "community.azure.azure_rm_virtualmachine_scaleset および community.azure.azure_rm_virtualmachinescaleset は非推奨になりました。代わりに azure.azcollection.azure_rm_virtualmachinescaleset を使用してください（https://github.com/ansible-collections/community.azure/pull/24）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:214 -#: ../../rst/porting_guides/porting_guide_5.rst:993 -msgid "lookup hashi_vault - the ``[lookup_hashi_vault]`` section in the ``ansible.cfg`` file is deprecated and will be removed in collection version ``3.0.0``. Instead, the section ``[hashi_vault_collection]`` can be used, which will apply to all plugins in the collection going forward (https://github.com/ansible-collections/community.hashi_vault/pull/144)." -msgstr "lookup hashi_vault - ``ansible.cfg`` ファイルの ``[lookup_hashi_vault]`` セクションは非推奨になり、コレクションバージョン ``3.0.0`` で削除されます。代わりに、``[hashi_vault_collection]`` セクションを使用することができます。これは、今後のコレクションのすべてのプラグインに適用されます（https://github.com/ansible-collections/community.hashi_vault/pull/144）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:217 -msgid "Porting Guide for v4.7.0" -msgstr "v4.7.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:223 -#: ../../rst/porting_guides/porting_guide_4.rst:684 -#: ../../rst/porting_guides/porting_guide_5.rst:790 -msgid "openvswitch.openvswitch" -msgstr "openvswitch.openvswitch" - -#: ../../rst/porting_guides/porting_guide_4.rst:225 -#: ../../rst/porting_guides/porting_guide_5.rst:792 -msgid "By mistake we tagged the repo to 2.0.0 and as it wasn't intended and cannot be reverted we're releasing 2.0.1 to make the community aware of the major version update." -msgstr "誤ってリポジトリーが 2.0.0 にタグ付けされました。これは意図したものではなく、元に戻すことができないため、2.0.1 をリリースし、メジャーバージョンの更新についてコミュニティーが認識できるようにしています。" - -#: ../../rst/porting_guides/porting_guide_4.rst:231 -#: ../../rst/porting_guides/porting_guide_4.rst:300 -#: ../../rst/porting_guides/porting_guide_4.rst:629 -#: ../../rst/porting_guides/porting_guide_5.rst:248 -#: ../../rst/porting_guides/porting_guide_5.rst:292 -#: ../../rst/porting_guides/porting_guide_5.rst:908 -#: ../../rst/porting_guides/porting_guide_6.rst:353 -#: ../../rst/porting_guides/porting_guide_6.rst:606 -#: ../../rst/porting_guides/porting_guide_6.rst:907 -#: ../../rst/porting_guides/porting_guide_7.rst:164 -#: ../../rst/porting_guides/porting_guide_7.rst:561 -#: ../../rst/porting_guides/porting_guide_7.rst:736 -#: ../../rst/porting_guides/porting_guide_7.rst:992 -msgid "cisco.ios" -msgstr "cisco.ios" - -#: ../../rst/porting_guides/porting_guide_4.rst:233 -#: ../../rst/porting_guides/porting_guide_5.rst:911 -msgid "Deprecated ios_ntp modules." -msgstr "ios_ntp モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:238 -#: ../../rst/porting_guides/porting_guide_5.rst:922 -msgid "Deprecated `nxos_ntp`, `nxos_ntp_options`, `nxos_ntp_auth` modules." -msgstr "`nxos_ntp`、`nxos_ntp_options`、`nxos_ntp_auth` モジュールが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:243 -#: ../../rst/porting_guides/porting_guide_5.rst:1003 -msgid "vmware_guest_vnc - Sphere 7.0 removed the built-in VNC server (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#productsupport)." -msgstr "vmware_guest_vnc - Sphere 7.0 でビルトイン VNC サーバーが廃止されました（https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#productsupport）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:248 -#: ../../rst/porting_guides/porting_guide_5.rst:1024 -msgid "Deprecated router_id from ospfv2 resource module." -msgstr "ospfv2 リソースモジュールの router_id が非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:251 -msgid "Porting Guide for v4.6.0" -msgstr "v4.6.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:259 -#: ../../rst/porting_guides/porting_guide_5.rst:733 -msgid "Add systemd generation for pods" -msgstr "Pod の systemd 生成を追加" - -#: ../../rst/porting_guides/porting_guide_4.rst:260 -#: ../../rst/porting_guides/porting_guide_5.rst:734 -msgid "Generate systemd service files for containers" -msgstr "コンテナーの systemd サービスファイルの生成" - -#: ../../rst/porting_guides/porting_guide_4.rst:265 -#: ../../rst/porting_guides/porting_guide_5.rst:765 -msgid "enable client.ssl,server.ssl before starting the gluster volume (https://github.com/gluster/gluster-ansible-collection/pull/19)" -msgstr "gluster ボリュームを起動する前に client.ssl,server.ssl を有効にします（https://github.com/gluster/gluster-ansible-collection/pull/19）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:273 -#: ../../rst/porting_guides/porting_guide_5.rst:986 -msgid "grafana_dashboard lookup - Providing a mangled version of the API key is no longer preferred." -msgstr "grafana_dashboard lookup - API キーの mangled バージョンの提供は推奨されなくなりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:276 -msgid "Porting Guide for v4.5.0" -msgstr "v4.5.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:282 -#: ../../rst/porting_guides/porting_guide_5.rst:768 -msgid "hetzner.hcloud" -msgstr "hetzner.hcloud" - -#: ../../rst/porting_guides/porting_guide_4.rst:284 -#: ../../rst/porting_guides/porting_guide_5.rst:770 -msgid "Introduction of placement groups" -msgstr "配置グループの概要" - -#: ../../rst/porting_guides/porting_guide_4.rst:289 -#: ../../rst/porting_guides/porting_guide_5.rst:797 -msgid "remove_stale_lun - Add role for removing stale LUN (https://bugzilla.redhat.com/1966873)." -msgstr "remove_stale_lun - 古い LUN を削除するロールを追加します（https://bugzilla.redhat.com/1966873）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:297 -#: ../../rst/porting_guides/porting_guide_5.rst:892 -msgid "network_cli - The paramiko_ssh setting ``look_for_keys`` was set automatically based on the values of the ``password`` and ``private_key_file`` options passed to network_cli. This option can now be set explicitly, and the automatic setting of ``look_for_keys`` will be removed after 2024-01-01 (https://github.com/ansible-collections/ansible.netcommon/pull/271)." -msgstr "network_cli - paramiko_ssh 設定 ``look_for_keys`` は、network_cli に渡される ``password`` オプションおよび ``private_key_file`` オプションの値に基づいて自動的に設定されます。このオプションは明示的に設定でき、``look_for_keys`` の自動設定は 2024-01-01 以降削除されます（https://github.com/ansible-collections/ansible.netcommon/pull/271）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:302 -#: ../../rst/porting_guides/porting_guide_5.rst:910 -msgid "Deprecated ios_bgp in favor of ios_bgp_global and ios_bgp_address_family." -msgstr "ios_bgp_global が非推奨となり、ios_bgp は ios_bgp_global および ios_bgp_address_family が採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:303 -#: ../../rst/porting_guides/porting_guide_5.rst:905 -#: ../../rst/porting_guides/porting_guide_5.rst:912 -msgid "Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests." -msgstr "ansible-test 統合ジョブのプロバイダーでテストを削除します。これにより、network-ee統合テストに移行するのに便利です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:308 -#: ../../rst/porting_guides/porting_guide_5.rst:1025 -msgid "Deprecated router_id from ospfv3 resource module." -msgstr "ospfv3 リソースモジュールの router_id が非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:311 -msgid "Porting Guide for v4.4.0" -msgstr "v4.4.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:325 -#: ../../rst/porting_guides/porting_guide_4.rst:635 -#: ../../rst/porting_guides/porting_guide_5.rst:915 -#: ../../rst/porting_guides/porting_guide_6.rst:613 -#: ../../rst/porting_guides/porting_guide_7.rst:567 -#: ../../rst/porting_guides/porting_guide_7.rst:745 -msgid "cisco.iosxr" -msgstr "cisco.iosxr" - -#: ../../rst/porting_guides/porting_guide_4.rst:327 -#: ../../rst/porting_guides/porting_guide_5.rst:917 -msgid "The iosxr_logging module has been deprecated in favor of the new iosxr_logging_global resource module and will be removed in a release after '2023-08-01'." -msgstr "iosxr_logging モジュールが非推奨となり、'2023-08-01' の後にリリースから削除されます。新しい iosxr_logging_global リソースモジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:332 -#: ../../rst/porting_guides/porting_guide_5.rst:923 -msgid "The nxos_logging module has been deprecated in favor of the new nxos_logging_global resource module and will be removed in a release after '2023-08-01'." -msgstr "nxos_logging モジュールが非推奨となり、'2023-08-01' の後にリリースから削除されます。新しい nxos_logging_global リソースモジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:337 -#: ../../rst/porting_guides/porting_guide_5.rst:965 -msgid "docker_container - the new ``command_handling``'s default value, ``compatibility``, is deprecated and will change to ``correct`` in community.docker 3.0.0. A deprecation warning is emitted by the module in cases where the behavior will change. Please note that ansible-core will output a deprecation warning only once, so if it is shown for an earlier task, there could be more tasks with this warning where it is not shown (https://github.com/ansible-collections/community.docker/pull/186)." -msgstr "docker_container - 新しい ``command_handling``のデフォルト値 ``compatibility`` は非推奨となり、community.docker 3.0.0 で ``correct`` に変更になります。非推奨の警告は、動作が変わる場合にモジュールによって出力されます。ansible-core は非推奨の警告を一度だけ出力するため、以前のタスクでは表示されない場合、表示されていない場所でこの警告でより表示されるタスクが増える可能性があることに注意してください（https://github.com/ansible-collections/community.docker/pull/186）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:342 -#: ../../rst/porting_guides/porting_guide_5.rst:1026 -msgid "The junos_logging module has been deprecated in favor of the new junos_logging_global resource module and will be removed in a release after '2023-08-01'." -msgstr "junos_logging モジュールが非推奨となり、'2023-08-01' の後にリリースから削除されます。新しい junos_logging_global リソースモジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:345 -#: ../../rst/porting_guides/porting_guide_4.rst:696 -#: ../../rst/porting_guides/porting_guide_5.rst:284 -#: ../../rst/porting_guides/porting_guide_5.rst:1029 -#: ../../rst/porting_guides/porting_guide_6.rst:773 -#: ../../rst/porting_guides/porting_guide_7.rst:676 -#: ../../rst/porting_guides/porting_guide_7.rst:925 -msgid "vyos.vyos" -msgstr "vyos.vyos" - -#: ../../rst/porting_guides/porting_guide_4.rst:347 -#: ../../rst/porting_guides/porting_guide_5.rst:1031 -msgid "The vyos_logging module has been deprecated in favor of the new vyos_logging_global resource module and will be removed in a release after \"2023-08-01\"." -msgstr "vyos_logging モジュールが非推奨となり、'2023-08-01' の後にリリースから削除されます。新しい vyos_logging_global リソースモジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:350 -msgid "Porting Guide for v4.3.0" -msgstr "v4.3.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:356 -#: ../../rst/porting_guides/porting_guide_5.rst:780 -msgid "netapp.cloudmanager" -msgstr "netapp.cloudmanager" - -#: ../../rst/porting_guides/porting_guide_4.rst:358 -#: ../../rst/porting_guides/porting_guide_5.rst:782 -msgid "Adding stage environment to all modules in cloudmanager" -msgstr "cloudmanager のすべてのモジュールへのステージ環境の追加" - -#: ../../rst/porting_guides/porting_guide_4.rst:366 -#: ../../rst/porting_guides/porting_guide_5.rst:992 -msgid "hashi_vault collection - support for Python 3.5 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81)." -msgstr "hashi_vault コレクション - Python 3.5 のサポートが、``community.hashi_vault`` のバージョン ``2.0.0`` で削除されます (https://github.com/ansible-collections/community.hashi_vault/issues/81)。" - -#: ../../rst/porting_guides/porting_guide_4.rst:369 -msgid "Porting Guide for v4.2.0" -msgstr "v4.2.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:386 -#: ../../rst/porting_guides/porting_guide_5.rst:728 -msgid "vmware_object_custom_attributes_info - added a new module to gather custom attributes of an object (https://github.com/ansible-collections/community.vmware/pull/851)." -msgstr "vmware_object_custom_attributes_info - オブジェクトのカスタム属性を収集する新しいモジュールが追加されました（https://github.com/ansible-collections/community.vmware/pull/851）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:391 -#: ../../rst/porting_guides/porting_guide_5.rst:739 -msgid "idrac_server_config_profile - Added support for exporting and importing Server Configuration Profile through HTTP/HTTPS share." -msgstr "idrac_server_config_profile - HTTP/HTTPS 共有でのサーバー設定プロファイルのエクスポートおよびインポートのサポートが追加されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:392 -#: ../../rst/porting_guides/porting_guide_5.rst:740 -msgid "ome_device_group - Added support for adding devices to a group using the IP addresses of the devices and group ID." -msgstr "ome_device_group - デバイスおよびグループ ID の IP アドレスを使用して、デバイスをグループに追加するためのサポートが追加されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:397 -#: ../../rst/porting_guides/porting_guide_5.rst:751 -msgid "New module fortios_monitor_fact." -msgstr "新しいモジュール fortios_monitor_fact。" - -#: ../../rst/porting_guides/porting_guide_4.rst:398 -#: ../../rst/porting_guides/porting_guide_5.rst:753 -msgid "Support Fortios 7.0." -msgstr "Fortios 7.0 をサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:399 -#: ../../rst/porting_guides/porting_guide_5.rst:754 -msgid "Support Log APIs." -msgstr "ログ API をサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:404 -msgid "The community.kubernetes collection is being renamed to kubernetes.core. In Ansible 5, community.kubernetes will be replaced by an empty collection which has deprecated redirects for all the current content to kubernetes.core. If you are using FQCNs starting with ``community.kubernetes.``, please update them to ``kubernetes.core.`` now. Note that kubernetes.core has been included in Ansible since Ansible 3.0.0 (https://github.com/ansible-community/community-topics/issues/22)." -msgstr "community.kubernetes コレクションは kubernetes.core に変更されました。Ansible 5 では、community.kubernetes は、現在のすべてのコンテンツを kubernetes.core にリダイレクトする空のコレクションに置き換えられます。FQCN を使用している場合は、``community.kubernetes.`` で始まる FQCN を ``kubernetes.core.`` に更新してください。Ansible 3.0.0 以降、kubernetes.core は Ansible に組み込まれている点に注意してください（https://github.com/ansible-community/community-topics/issues/22）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:409 -#: ../../rst/porting_guides/porting_guide_5.rst:898 -msgid "win_updates - Deprecated the ``filtered_reason`` return value for each filtered up in favour of ``filtered_reasons``. This has been done to show all the reasons why an update was filtered and not just the first reason." -msgstr "win_updates - フィルター処理されたそれぞれの``filtered_reason``戻り値が非推奨になり、``filtered_reasons``が採用されました。これは、最初の理由だけでなく、更新がフィルタリングされたすべての理由を示すために行われました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:410 -#: ../../rst/porting_guides/porting_guide_5.rst:899 -msgid "win_updates - Deprecated the ``use_scheduled_task`` option as it is no longer used." -msgstr "win_updates - 使用されなくなった ``use_scheduled_task`` オプションが非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:411 -#: ../../rst/porting_guides/porting_guide_5.rst:900 -msgid "win_updates - Deprecated the ``whitelist`` and ``blacklist`` options in favour of ``accept_list`` and ``reject_list`` respectively to conform to the new standards used in Ansible for these types of options." -msgstr "win_updates - ``whitelist`` オプションおよび ``blacklist`` オプションが非推奨になりました。オプションの種類について Ansible で使用される新しい標準に準拠するためにそれぞれ ``accept_list`` と ``reject_list`` が採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:416 -#: ../../rst/porting_guides/porting_guide_5.rst:972 -msgid "ali_instance_info - marked removal version of deprecated parameters ``availability_zone`` and ``instance_names`` (https://github.com/ansible-collections/community.general/issues/2429)." -msgstr "ali_instance_info - 非推奨のパラメーター``availability_zone``と``instance_names``の削除バージョンが示されました（https://github.com/ansible-collections/community.general/issues/2429）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:417 -#: ../../rst/porting_guides/porting_guide_5.rst:980 -msgid "serverless - deprecating parameter ``functions`` because it was not used in the code (https://github.com/ansible-collections/community.general/pull/2845)." -msgstr "serverless - コードで使用されていないためパラメーター ``functions`` を非推奨化（https://github.com/ansible-collections/community.general/pull/2845）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:422 -#: ../../rst/porting_guides/porting_guide_5.rst:991 -msgid "hashi_vault collection - support for Python 2 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81)." -msgstr "hashi_vault コレクション - Python 2 のサポートがバージョン``2.0.0``の``community.hashi_vault``で削除されます（https://github.com/ansible-collections/community.hashi_vault/issues/81）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:425 -msgid "Porting Guide for v4.1.0" -msgstr "v4.1.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:442 -#: ../../rst/porting_guides/porting_guide_5.rst:678 -msgid "Add custom_image module" -msgstr "custom_image モジュールの追加" - -#: ../../rst/porting_guides/porting_guide_4.rst:452 -#: ../../rst/porting_guides/porting_guide_5.rst:742 -msgid "ome_firmware_baseline - Module supports check mode, and allows the modification and deletion of firmware baselines." -msgstr "ome_firmware_baseline - モジュールはチェックモードをサポートし、ファームウェアベースラインの変更や削除を可能にします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:453 -#: ../../rst/porting_guides/porting_guide_5.rst:743 -msgid "ome_firmware_catalog - Module supports check mode, and allows the modification and deletion of firmware catalogs." -msgstr "ome_firmware_catalog - モジュールはチェックモードをサポートし、ファームウェアカタログの変更や削除を可能にします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:458 -#: ../../rst/porting_guides/porting_guide_5.rst:750 -msgid "Improve ``fortios_configuration_fact`` to use multiple selectors concurrently." -msgstr "複数のセレクターを同時に使用するように ``fortios_configuration_fact`` を改善します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:459 -#: ../../rst/porting_guides/porting_guide_5.rst:755 -msgid "Support ``check_mode`` in all cofigurationAPI-based modules." -msgstr "すべての cofigurationAPI ベースのモジュールの ``check_mode`` をサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:460 -#: ../../rst/porting_guides/porting_guide_5.rst:756 -msgid "Support filtering for fact gathering modules ``fortios_configuration_fact`` and ``fortios_monitor_fact``." -msgstr "ファクト収集モジュール ``fortios_configuration_fact`` および ``fortios_monitor_fact`` のフィルタリングをサポートします。" - -#: ../../rst/porting_guides/porting_guide_4.rst:461 -#: ../../rst/porting_guides/porting_guide_5.rst:758 -msgid "Support moving policy in ``firewall_central_snat_map``." -msgstr "``firewall_central_snat_map`` での移行ポリシーのサポート" - -#: ../../rst/porting_guides/porting_guide_4.rst:462 -#: ../../rst/porting_guides/porting_guide_5.rst:760 -msgid "Unify schemas for monitor API." -msgstr "モニター API のスキーマの統一" - -#: ../../rst/porting_guides/porting_guide_4.rst:467 -#: ../../rst/porting_guides/porting_guide_5.rst:787 -msgid "packages is now a required Python package and gets installed through Ansible 2.10+." -msgstr "パッケージが必要な Python パッケージになり、Ansible 2.10 以降からインストールされます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:475 -#: ../../rst/porting_guides/porting_guide_5.rst:812 -msgid "win_reboot - Removed ``shutdown_timeout`` and ``shutdown_timeout_sec`` which has not done anything since Ansible 2.5." -msgstr "win_reboot - ``shutdown_timeout`` および ``shutdown_timeout_sec`` を削除しましたが、Ansible 2.5 以降は実行されていません。" - -#: ../../rst/porting_guides/porting_guide_4.rst:483 -#: ../../rst/porting_guides/porting_guide_5.rst:897 -msgid "win_reboot - Unreachable hosts can be ignored with ``ignore_errors: True``, this ability will be removed in a future version. Use ``ignore_unreachable: True`` to ignore unreachable hosts instead. - https://github.com/ansible-collections/ansible.windows/issues/62" -msgstr "win_reboot - ``ignore_errors: True`` で到達できないホストを無視できます。この機能は今後のバージョンで削除される予定です。代わりに ``ignore_unreachable: True`` を使用して、到達不能なホストを無視します（https://github.com/ansible-collections/ansible.windows/issues/62）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:493 -msgid "All inventory and vault scripts will be removed from community.general in version 4.0.0. If you are referencing them, please update your references to the new `contrib-scripts GitHub repository `_ so your workflow will not break once community.general 4.0.0 is released (https://github.com/ansible-collections/community.general/pull/2697)." -msgstr "インベントリーおよび vault スクリプトはすべて、バージョン 4.0.0 の community.general から削除されます。それらを参照する場合は、新しい `contrib-scripts GitHub repository `_ への参照を更新してください。これにより、community.general 4.0.0 がリリースされてもワークフローが破損することはありません（https://github.com/ansible-collections/community.general/pull/2697）" - -#: ../../rst/porting_guides/porting_guide_4.rst:494 -msgid "The nios, nios_next_ip, nios_next_network lookup plugins, the nios documentation fragment, and the nios_host_record, nios_ptr_record, nios_mx_record, nios_fixed_address, nios_zone, nios_member, nios_a_record, nios_aaaa_record, nios_network, nios_dns_view, nios_txt_record, nios_naptr_record, nios_srv_record, nios_cname_record, nios_nsgroup, and nios_network_view module have been deprecated and will be removed from community.general 5.0.0. Please install the `infoblox.nios_modules `_ collection instead and use its plugins and modules (https://github.com/ansible-collections/community.general/pull/2458)." -msgstr "nios、nios_next_ip、nios_next_networkルックアッププラグイン、niosドキュメントフラグメント、およびnios_host_record、nios_ptr_record、nios_mx_record、nios_fixed_address、nios_zone、nios_member、nios_a_record、nios_aaaa_record、nios_network、nios_dns_view、nios_txt_record、nios_naptr_record、nios_srv_record、nios_cname_record、nios_nsgroup、および nios_network_view モジュールは非推奨になり、community.general 5.0.0から削除されます。代わりに `infoblox.nios_modules `_ をインストールし、そのプラグインとモジュールを使用してください（https://github.com/ansible-collections/community.general/pull/2458）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:495 -msgid "The vendored copy of ``ipaddress`` will be removed in community.general 4.0.0. Please switch to ``ipaddress`` from the Python 3 standard library, or `from pypi `_, if your code relies on the vendored version of ``ipaddress`` (https://github.com/ansible-collections/community.general/pull/2459)." -msgstr "``ipaddress`` のベンダーコピーは、community.general 4.0.0 で削除されます。Python 3 標準ライブラリーから ``ipaddress`` に切り替えるか、コードがベンダーバージョンの ``ipaddress`` に依存している場合は `from pypi `_ に切り替えるようにしてください（https://github.com/ansible-collections/community.general/pull/2459）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:496 -#: ../../rst/porting_guides/porting_guide_5.rst:978 -msgid "linode - parameter ``backupsenabled`` is deprecated and will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2410)." -msgstr "linode - パラメーター``backupsenabled``は非推奨になり、community.general 5.0.0で削除されます（https://github.com/ansible-collections/community.general/pull/2410）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:497 -msgid "lxd inventory plugin - the plugin will require ``ipaddress`` installed when used with Python 2 from community.general 4.0.0 on. ``ipaddress`` is part of the Python 3 standard library, but can be installed for Python 2 from pypi (https://github.com/ansible-collections/community.general/pull/2459)." -msgstr "lxd inventory プラグイン - プラグインは community.general 4.0.0 の Python 2 で使用する際に ``ipaddress`` をインストールする必要があります。``ipaddress`` は Python 3 標準ライブラリーの一部ですが、pypi から Python 2 用にインストールできます（https://github.com/ansible-collections/community.general/pull/2459）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:498 -msgid "scaleway_security_group_rule - the module will require ``ipaddress`` installed when used with Python 2 from community.general 4.0.0 on. ``ipaddress`` is part of the Python 3 standard library, but can be installed for Python 2 from pypi (https://github.com/ansible-collections/community.general/pull/2459)." -msgstr "scaleway_security_group_rule - モジュールは、community.general 4.0.0 の Python 2 で使用する際に ``ipaddress`` がインストールされている必要があります。``ipaddress`` は Python 3 標準ライブラリーの一部ですが、pypi から Python 2 用にインストールできます（https://github.com/ansible-collections/community.general/pull/2459）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:501 -#: ../../rst/porting_guides/porting_guide_5.rst:1006 -msgid "inspur.sm" -msgstr "inspur.sm" - -#: ../../rst/porting_guides/porting_guide_4.rst:503 -#: ../../rst/porting_guides/porting_guide_5.rst:1008 -msgid "add_ad_group - This feature will be removed in inspur.sm.add_ad_group 3.0.0. replaced with inspur.sm.ad_group." -msgstr "add_ad_group - この機能は inspur.sm.add_ad_group 3.0.0 で削除され、inspur.sm.ad_group に置き換えられる予定です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:504 -#: ../../rst/porting_guides/porting_guide_5.rst:1009 -msgid "add_ldap_group - This feature will be removed in inspur.sm.add_ldap_group 3.0.0. replaced with inspur.sm.ldap_group." -msgstr "add_ldap_group - この機能は inspur.sm.add_ldap_group 3.0.0 で削除され、inspur.sm.ldap_group に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:505 -#: ../../rst/porting_guides/porting_guide_5.rst:1010 -msgid "add_user - This feature will be removed in inspur.sm.add_user 3.0.0. replaced with inspur.sm.user." -msgstr "add_user - この機能は inspur.sm.add_user 3.0.0. で削除され、inspur.sm.user に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:506 -#: ../../rst/porting_guides/porting_guide_5.rst:1011 -msgid "add_user_group - This feature will be removed in inspur.sm.add_user_group 3.0.0. replaced with inspur.sm.user_group." -msgstr "add_user_group - この機能は inspur.sm.add_user_group 3.0.0 で削除され、inspur.sm.user_group に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:507 -#: ../../rst/porting_guides/porting_guide_5.rst:1012 -msgid "del_ad_group - This feature will be removed in inspur.sm.del_ad_group 3.0.0. replaced with inspur.sm.ad_group." -msgstr "del_ad_group - この機能は inspur.sm.del_ad_group 3.0.0 で削除され、inspur.sm.ad_group に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:508 -#: ../../rst/porting_guides/porting_guide_5.rst:1013 -msgid "del_ldap_group - This feature will be removed in inspur.sm.del_ldap_group 3.0.0. replaced with inspur.sm.ldap_group." -msgstr "del_ldap_group - この機能は inspur.sm.del_ldap_group 3.0.0 で削除され、inspur.sm.ldap_group に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:509 -#: ../../rst/porting_guides/porting_guide_5.rst:1014 -msgid "del_user - This feature will be removed in inspur.sm.del_user 3.0.0. replaced with inspur.sm.user." -msgstr "del_user - この機能は inspur.sm.del_user 3.0.0. で削除され、inspur.sm.user に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:510 -#: ../../rst/porting_guides/porting_guide_5.rst:1015 -msgid "del_user_group - This feature will be removed in inspur.sm.del_user_group 3.0.0. replaced with inspur.sm.user_group." -msgstr "del_user_group - この機能は inspur.sm.del_user_group 3.0.0 で削除され、inspur.sm.user_group に置き換えられます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:511 -#: ../../rst/porting_guides/porting_guide_5.rst:1016 -msgid "edit_ad_group - This feature will be removed in inspur.sm.edit_ad_group 3.0.0. replaced with inspur.sm.ad_group." -msgstr "edit_ad_group - この機能は inspur.sm.edit_ad_group 3.0.0 で削除され、inspur.sm.ad_group に置き換えられる予定です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:512 -#: ../../rst/porting_guides/porting_guide_5.rst:1017 -msgid "edit_ldap_group - This feature will be removed in inspur.sm.edit_ldap_group 3.0.0. replaced with inspur.sm.ldap_group." -msgstr "edit_ldap_group - この機能は、inspur.sm.edit_ldap_group 3.0.0 で削除され、inspur.sm.ldap_group に置き換えられる予定です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:513 -#: ../../rst/porting_guides/porting_guide_5.rst:1018 -msgid "edit_user - This feature will be removed in inspur.sm.edit_user 3.0.0. replaced with inspur.sm.user." -msgstr "edit_user - この機能は inspur.sm.edit_user 3.0.0. で削除され、inspur.sm.user に置き換えられる予定です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:514 -#: ../../rst/porting_guides/porting_guide_5.rst:1019 -msgid "edit_user_group - This feature will be removed in inspur.sm.edit_user_group 3.0.0. replaced with inspur.sm.user_group." -msgstr "edit_user_group: この機能は inspur.sm.edit_user_group 3.0.0 で削除され、inspur.sm.user_group に置き換えられる予定です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:517 -msgid "Porting Guide for v4.0.0" -msgstr "v4.0.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_4.rst:523 -#: ../../rst/porting_guides/porting_guide_4.rst:544 -#: ../../rst/porting_guides/porting_guide_4.rst:597 -#: ../../rst/porting_guides/porting_guide_4.rst:706 -#: ../../rst/porting_guides/porting_guide_4.rst:832 -#: ../../rst/porting_guides/porting_guide_5.rst:442 -#: ../../rst/porting_guides/porting_guide_5.rst:463 -#: ../../rst/porting_guides/porting_guide_5.rst:597 -#: ../../rst/porting_guides/porting_guide_5.rst:803 -#: ../../rst/porting_guides/porting_guide_5.rst:875 -#: ../../rst/porting_guides/porting_guide_6.rst:394 -#: ../../rst/porting_guides/porting_guide_6.rst:434 -#: ../../rst/porting_guides/porting_guide_6.rst:571 -#: ../../rst/porting_guides/porting_guide_6.rst:793 -#: ../../rst/porting_guides/porting_guide_6.rst:894 -#: ../../rst/porting_guides/porting_guide_7.rst:108 -#: ../../rst/porting_guides/porting_guide_7.rst:132 -#: ../../rst/porting_guides/porting_guide_7.rst:309 -#: ../../rst/porting_guides/porting_guide_7.rst:473 -#: ../../rst/porting_guides/porting_guide_7.rst:689 -#: ../../rst/porting_guides/porting_guide_7.rst:944 -msgid "Ansible-core" -msgstr "Ansible-core" - -#: ../../rst/porting_guides/porting_guide_4.rst:525 -msgid "ansible-test - The ``pylint`` sanity test no longer correctly detects \"bad\" variable names for non-constants. See `issue 3701 `_ for additional details." -msgstr "ansible-test - ``pylint`` 健全性テストは、非制約のため\"bad\" 変数名を正しく検出しなくなりました。詳細は、`issue 3701 ` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:538 -msgid "Modules for monitor API are not versioned yet." -msgstr "モニター API 用のモジュールはまだバージョン化されていません。" - -#: ../../rst/porting_guides/porting_guide_4.rst:546 -msgid "Made SCM collections be reinstalled regardless of ``--force`` being present." -msgstr "作成された SCM コレクションは、``--force`` が存在するかどうかに関わらず再インストールされます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:547 -msgid "NetBSD virtualization facts (specifically ``ansible_virtualization_type``) now returns a more accurate value by checking the value of the ``machdep.hypervisor`` ``sysctl`` key. This change is breaking because in some cases previously, we would erroneously report ``xen`` even when the target is not running on Xen. This prevents that behavior in most cases. (https://github.com/ansible/ansible/issues/69352)" -msgstr "NetBSD 仮想化ファクト（具体的には ``ansible_virtualization_type``）は、``machdep.hypervisor`` ``sysctl`` キーの値をチェックすることで、より正確な値を返すようになりました。以前は、ターゲットが Xen で実行していない場合でも ``xen``を誤って報告していたため、この変更は重要です。これにより、ほとんどの場合、その動作が阻止されます（https://github.com/ansible/ansible/issues/69352）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:548 -msgid "Replaced the in-tree dependency resolver with an external implementation that pip >= 20.3 uses now by default — ``resolvelib``. (https://github.com/ansible/ansible/issues/71784)" -msgstr "ツリー内の依存関係リゾルバーが、pip> = 20.3がデフォルトで使用する外部実装``resolvelib``に置き換えられました（https://github.com/ansible/ansible/issues/71784）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:549 -msgid "The ``meta`` module now supports tags for user-defined tasks. Internal ``meta`` tasks continue to always run. (https://github.com/ansible/ansible/issues/64558)" -msgstr "``meta`` モジュールは、ユーザー定義のタスクのタグをサポートするようになりました。内部 ``meta`` タスクは常に実行されます（https://github.com/ansible/ansible/issues/64558）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:550 -msgid "ansible-galaxy login command has been removed (see `issue 71560 `_)" -msgstr "ansible-galaxy login コマンドが削除されました (`issue 71560 `_ を参照)。" - -#: ../../rst/porting_guides/porting_guide_4.rst:555 -msgid "Removed vendored ipaddress package from collection. If you use ansible_collections.ansible.netcommon.plugins.module_utils.compat.ipaddress in your collection, you will need to change this to import ipaddress instead. If your content using ipaddress supports Python 2.7, you will additionally need to make sure that the user has the ipaddress package installed. Please refer to https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#importing-and-using-shared-code to see how to safely import external packages that may be missing from the user's system A backport of ipaddress for Python 2.7 is available at https://pypi.org/project/ipaddress/" -msgstr "コレクションからベンダー化された ipaddress パッケージが削除されました。コレクションのansible_collections.ansible.netcommon.plugins.module_utils.compat.ipaddress を使用する場合は、代わりに ipaddress をインポートするためにこれを変更する必要があります。ipaddress を使用するコンテンツが Python 2.7 に対応している場合は、さらにユーザーが ipaddress パッケージがインストールされていることを確認する必要があります。ユーザーのシステム A に欠落している可能性のある外部パッケージを安全にインポートする方法については、https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#importing-and-using-shared-codeを参照してください。Python 2.7用のipaddressのバックポートは、https://pypi.org/project/ipaddress/で利用できます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:565 -msgid "If you use Ansible 2.9 and these plugins or modules from this collection, community.general 3.0.0 results in errors when trying to use the DellEMC content by FQCN, like ``community.general.idrac_firmware``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``dellemc.openmanage.idrac_firmware`` for the previous example) and to make sure that you have ``dellemc.openmanage`` installed." -msgstr "Ansible 2.9 と、このコレクションのプラグインやモジュールを使用している場合、community.general 3.0.0 では、``community.general.idrac_firmware`` のように FQCN による DellEMC コンテンツを使用しようとするとエラーになります。Ansible 2.9 はリダイレクトを使用することができないため、新しい FQCN (前の例では ``dellemc.openmanage.idrac_firmware``) を使用し、``dellemc.openmanage`` がインストールされていることを確認するために、Playbook とロールを手動で調整する必要があります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:568 -msgid "If you use ansible-base 2.10 or newer and did not install Ansible 4.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``dellemc.openmanage`` collection if you are using any of these plugins or modules. While ansible-base 2.10 or newer can use the redirects that community.general 3.0.0 adds, the collection they point to (such as dellemc.openmanage) must be installed for them to work." -msgstr "ansible-base 2.10 以降を使用していて、Ansible 4.0.0 をインストールせず、手動で community.general をインストール (またはアップグレード) し、このプラグインまたはモジュールを使用している場合は、``dellemc.openmanage`` コレクションもインストールする必要があります。ansible-base 2.10 以降では、community.general 3.0.0 が追加したリダイレクトを使用することができますが、リダイレクト先のコレクション (dellemc.openmanage など) がインストールされていないと動作しません。" - -#: ../../rst/porting_guides/porting_guide_4.rst:570 -msgid "gitlab_deploy_key - if for an already existing key title a different public key was given as parameter nothing happened, now this changed so that the public key is updated to the new value (https://github.com/ansible-collections/community.general/pull/1661)." -msgstr "gitlab_deploy_key - 既存の鍵タイトルに対して、パラメーターとして別の公開鍵が何も起こらなかった場合、これが変更され、公開鍵が新しい値に更新されます（https://github.com/ansible-collections/community.general/pull/1661）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:571 -msgid "java_keystore - instead of failing, now overwrites keystore if the alias (name) is changed. This was originally the intended behavior, but did not work due to a logic error. Make sure that your playbooks and roles do not depend on the old behavior of failing instead of overwriting (https://github.com/ansible-collections/community.general/issues/1671)." -msgstr "java_keystore - 失敗する代わりに、エイリアス（名前）が変更した場合にキーストアを上書きするようになりました。これは元々意図された動作でしたが、論理エラーのために機能しませんでした。Playbook とロールが、上書きする代わりに失敗するという古い動作に依存していないことを確認してください（https://github.com/ansible-collections/community.general/issues/1671）" - -#: ../../rst/porting_guides/porting_guide_4.rst:572 -msgid "java_keystore - instead of failing, now overwrites keystore if the passphrase is changed. Make sure that your playbooks and roles do not depend on the old behavior of failing instead of overwriting (https://github.com/ansible-collections/community.general/issues/1671)." -msgstr "java_keystore - 失敗する代わりに、パスフレーズが変更した場合にキーストアを上書きするようになりました。Playbook とロールが、上書きする代わりに失敗するという古い動作に依存していないことを確認してください（https://github.com/ansible-collections/community.general/issues/1671）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:573 -msgid "one_image - use pyone instead of python-oca (https://github.com/ansible-collections/community.general/pull/2032)." -msgstr "one_image - python-oca の代わりに pyone を使用します（https://github.com/ansible-collections/community.general/pull/2032）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:579 -msgid "Generic FortiOS Module - FOS module to issue generic request with Ansible." -msgstr "汎用 FortiOS モジュール - Ansible で汎用要求を発行するための FOS モジュール。" - -#: ../../rst/porting_guides/porting_guide_4.rst:580 -msgid "Support for FOS Monitor API - several modules are new for monitor API." -msgstr "FOS Monitor API のサポート - 複数のモジュールがモニター API 用に新たに追加されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:581 -msgid "Unified Collection - The fortios collection itself will be adapting any FOS platforms." -msgstr "統合コレクション - fortios コレクション自体が、FOS プラットフォームに適応します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:586 -msgid "auth field now required for anything other than Basic authentication" -msgstr "Basic 認証以外のすべてのフィールドに認証フィールドが必要になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:591 -msgid "All role variables are now prefixed with ``foreman_`` to avoid clashes with similarly named variables from roles outside this collection." -msgstr "このコレクション外のロールからの同様の名前の変数との衝突を回避するため、すべてのロール変数には ``foreman_`` のプレフィックスが付けられました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:599 -msgid "A collection can be reinstalled with new version requirements without using the ``--force`` flag. The collection's dependencies will also be updated if necessary with the new requirements. Use ``--upgrade`` to force transitive dependency updates." -msgstr "コレクションは、``--force`` フラグを使用せずに、新しいバージョンの要件で再インストールできます。また、新しい要件で必要な場合は、コレクションの依存関係も更新されます。``--upgrade`` を使用して、推移的な依存関係の更新を強制します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:600 -msgid "AnsibleModule - use ``ArgumentSpecValidator`` class for validating argument spec and remove private methods related to argument spec validation. Any modules using private methods should now use the ``ArgumentSpecValidator`` class or the appropriate validation function." -msgstr "AnsibleModule - 引数仕様を検証するために ``ArgumentSpecValidator`` クラスを使用し、引数仕様の検証に関連するプライベートメソッドを削除します。プライベートメソッドを使用するすべてのモジュールは、``ArgumentSpecValidator`` クラスまたは適切な検証機能を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:601 -msgid "Declared ``resolvelib >= 0.5.3, < 0.6.0`` a direct dependency of ansible-core. Refs: - https://github.com/sarugaku/resolvelib - https://pypi.org/p/resolvelib - https://pradyunsg.me/blog/2020/03/27/pip-resolver-testing" -msgstr "ansible-core の直接の依存関係``resolvelib >= 0.5.3, < 0.6.0`` が宣言されます。https://github.com/sarugaku/resolvelib、https://pypi.org/p/resolvelib、https://pradyunsg.me/blog/2020/03/27/pip-resolver-testing を参照してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:606 -msgid "It became possible to install Ansible Collections from local folders and namespaces folder similar to SCM structure with multiple collections." -msgstr "複数のコレクションを持つ SCM 構造と同様に、ローカルフォルダーおよび namespace フォルダーから Ansible Collections をインストールできるようになりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:607 -msgid "It became possible to upgrade Ansible collections from Galaxy servers using the ``--upgrade`` option with ``ansible-galaxy collection install``." -msgstr "``ansible-galaxy collection install`` で ``--upgrade`` オプションを使用して、Galaxy サーバーから Ansible コレクションをアップグレードできるようになりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:608 -msgid "Support for role argument specification validation at role execution time. When a role contains an argument spec, an implicit validation task is inserted at the start of role execution." -msgstr "ロール実行時にロール引数の仕様検証のサポート。ロールに引数の仕様が含まれる場合は、暗黙的な検証タスクがロール実行の開始時に挿入されます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:609 -msgid "add ``ArgumentSpecValidator`` class for validating parameters against an argument spec outside of ``AnsibleModule`` (https://github.com/ansible/ansible/pull/73335)" -msgstr "``AnsibleModule`` に含まれない引数仕様に対してパラメーターを検証する ``ArgumentSpecValidator`` クラスを追加します (https://github.com/ansible/ansible/pull/73335)。" - -#: ../../rst/porting_guides/porting_guide_4.rst:615 -msgid "Remove deprecated connection arguments from netconf_config" -msgstr "netconf_config から非推奨の接続引数を削除" - -#: ../../rst/porting_guides/porting_guide_4.rst:618 -#: ../../rst/porting_guides/porting_guide_5.rst:493 -#: ../../rst/porting_guides/porting_guide_5.rst:903 -#: ../../rst/porting_guides/porting_guide_6.rst:467 -#: ../../rst/porting_guides/porting_guide_6.rst:588 -#: ../../rst/porting_guides/porting_guide_7.rst:527 -msgid "arista.eos" -msgstr "arista.eos" - -#: ../../rst/porting_guides/porting_guide_4.rst:620 -msgid "Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules` - Please refer to ansible.netcommon `changelog `_ for more details." -msgstr "`ansible_network_single_user_mode` および `ansible_network_import_modules` をサポートするには、ansible.netcommon v2.0.0 以降が必要です。詳細は、ansible.netcommon の `changelog `_ を参照してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:623 -#: ../../rst/porting_guides/porting_guide_6.rst:600 -#: ../../rst/porting_guides/porting_guide_7.rst:550 -msgid "cisco.asa" -msgstr "cisco.asa" - -#: ../../rst/porting_guides/porting_guide_4.rst:625 -msgid "Please refer to ansible.netcommon `changelog ` for more details." -msgstr "詳細は、ansible.netcommon の `changelog ` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:626 -#: ../../rst/porting_guides/porting_guide_4.rst:632 -#: ../../rst/porting_guides/porting_guide_4.rst:638 -#: ../../rst/porting_guides/porting_guide_4.rst:645 -#: ../../rst/porting_guides/porting_guide_4.rst:676 -msgid "Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`." -msgstr "`ansible_network_single_user_mode` および `ansible_network_import_modules` をサポートするには、ansible.netcommon v2.0.0 以降が必要です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:631 -#: ../../rst/porting_guides/porting_guide_4.rst:637 -#: ../../rst/porting_guides/porting_guide_4.rst:644 -#: ../../rst/porting_guides/porting_guide_4.rst:675 -#: ../../rst/porting_guides/porting_guide_4.rst:698 -msgid "Please refer to ansible.netcommon `changelog `_ for more details." -msgstr "詳細は、ansible.netcommon `changelog `_ を参照してください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:639 -#: ../../rst/porting_guides/porting_guide_4.rst:700 -msgid "ipaddress is no longer in ansible.netcommon. For Python versions without ipaddress (< 3.0), the ipaddress package is now required." -msgstr "ipaddress は ansible.netcommon ではなくなりました。ipaddress (< 3.0) のない Python バージョンでは、ipaddress パッケージが必要になりました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:655 -msgid "mysql_replication - add deprecation warning that the ``Is_Slave`` and ``Is_Master`` return values will be replaced with ``Is_Primary`` and ``Is_Replica`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/147)." -msgstr "mysql_replication - ``Is_Slave`` および ``Is_Master`` の戻り値が ``community.mysql`` 3.0.0 の ``Is_Primary`` および ``Is_Replica`` に置き換えられたことを示す非推奨の警告を追加します（https://github.com/ansible-collections/community.mysql/pull/147）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:656 -msgid "mysql_replication - the choices of the ``state`` option containing ``master`` will be finally replaced with the alternative ``primary`` choices in ``community.mysql`` 3.0.0, add deprecation warnings (https://github.com/ansible-collections/community.mysql/pull/150)." -msgstr "mysql_replication - ``master`` が含まれる ``state`` オプションの選択が、最終的に ``community.mysql`` 3.0.0 の代替 ``primary`` の選択肢に置き換えられ、非推奨の警告を追加します（https://github.com/ansible-collections/community.mysql/pull/150）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:658 -msgid "mysql_replication - the return value ``Is_Slave`` and ``Is_Master`` will be replaced with ``Is_Replica`` and ``Is_Primary`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/145)." -msgstr "mysql_replication - 戻り値 ``Is_Slave`` および ``Is_Master`` は、``community.mysql`` 3.0.0 で ``Is_Replica`` および ``Is_Primary`` に置き換えられます（https://github.com/ansible-collections/community.mysql/issues/145）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:660 -msgid "mysql_replication - the word ``master`` in messages returned by the module will be replaced with ``primary`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/145)." -msgstr "mysql_replication - モジュールによって返されたメッセージの単語 ``master`` は、``community.mysql`` 3.0.0 で ``primary`` に置き換えられます（https://github.com/ansible-collections/community.mysql/issues/145）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:661 -msgid "mysql_replication - the word ``slave`` in messages returned by the module replaced with ``replica`` (https://github.com/ansible-collections/community.mysql/issues/98)." -msgstr "mysql_replication - ``replica`` に置き換えられたモジュールによって返されたメッセージの単語 ``slave`` です（https://github.com/ansible-collections/community.mysql/issues/98）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:667 -msgid "New module fortios_configuration_fact" -msgstr "新しいモジュール fortios_configuration_fact" - -#: ../../rst/porting_guides/porting_guide_4.rst:668 -msgid "New module fortios_json_generic" -msgstr "新しいモジュール fortios_json_generic" - -#: ../../rst/porting_guides/porting_guide_4.rst:669 -msgid "New module fortios_monitor" -msgstr "新しいモジュール fortios_monitor" - -#: ../../rst/porting_guides/porting_guide_4.rst:670 -msgid "New module fortios_monitor_fact" -msgstr "新しいモジュール fortios_monitor_fact" - -#: ../../rst/porting_guides/porting_guide_4.rst:686 -msgid "There is no major changes for this particular release and it was tagged by mistake and cannot be reverted." -msgstr "この特定のリリースには大きな変更がなく、誤りによってタグ付けされ、元に戻すことはできません。" - -#: ../../rst/porting_guides/porting_guide_4.rst:691 -msgid "refactored client to inherit from AnsibleModule" -msgstr "AnsibleModule から継承するリファクタークライアント" - -#: ../../rst/porting_guides/porting_guide_4.rst:692 -msgid "supports OpenID Connect authentication protocol" -msgstr "OpenID Connect による認証プロトコルのサポート" - -#: ../../rst/porting_guides/porting_guide_4.rst:693 -msgid "supports bearer tokens for authentication" -msgstr "認証用のベアラートークンのサポート" - -#: ../../rst/porting_guides/porting_guide_4.rst:699 -msgid "Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`" -msgstr "`ansible_network_single_user_mode` をサポートするには、ansible.netcommon v2.0.0 以降および `ansible_network_import_modules` が必要です。" - -#: ../../rst/porting_guides/porting_guide_4.rst:708 -msgid "Removed `SharedPluginLoaderObj` class from ansible.plugins.strategy. It was deprecated in favor of using the standard plugin loader." -msgstr "標準のプラグインローダーの使用が採用されたため、ansible.plugins.strategy から `SharedPluginLoaderObj` クラスが削除されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:709 -msgid "Removed `_get_item()` alias from callback plugin base class which had been deprecated in favor of `_get_item_label()`." -msgstr "非推奨になっていた `_get_item()` エイリアスをコールバックプラグインベースクラスから削除され、`_get_item_label()` が採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:710 -msgid "The \"user\" parameter was previously deprecated and is now removed in favor of \"scope\"" -msgstr "「user」パラメーターは非推奨となっており、削除されました。「scope」が採用されています。" - -#: ../../rst/porting_guides/porting_guide_4.rst:711 -msgid "The deprecated ``ansible.constants.BECOME_METHODS`` has been removed." -msgstr "非推奨の ``ansible.constants.BECOME_METHODS`` は削除されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:712 -msgid "The deprecated ``ansible.constants.get_config()`` has been removed." -msgstr "非推奨の ``ansible.constants.get_config()`` は削除されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:713 -msgid "The deprecated ``ansible.constants.mk_boolean()`` has been removed." -msgstr "非推奨の ``ansible.constants.mk_boolean()`` は削除されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:714 -msgid "`with_*` loops are no longer optimized for modules whose `name` parameters can take lists (mostly package managers). Use `name` instead of looping over individual names with `with_items` and friends." -msgstr "`with_*` ループは、`name` パラメーターがリスト（ほとんどの場合はパッケージマネージャー）を取ることができるモジュール向けに最適化されなくなりました。`with_items` およびフレンズを使用して個別名にループする代わりに、`name` を使用します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:719 -msgid "The ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules have now been migrated from community.general to the `dellemc.openmanage `_ Ansible collection. If you use ansible-base 2.10 or newer, redirections have been provided." -msgstr "``ome_device_info``、``idrac_firmware``、および ``idrac_server_config_profile`` モジュールは、community.general から `dellemc.openmanage `_ Ansibleコレクションに移行しました。ansible-base 2.10 以降を使用している場合は、リダイレクトが提供されます。" - -#: ../../rst/porting_guides/porting_guide_4.rst:722 -msgid "If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.idrac_firmware`` → ``dellemc.openmanage.idrac_firmware``) and make sure to install the dellemc.openmanage collection." -msgstr "Ansible 2.9 を使用し、このコレクションをインストールした場合は、FQCN (``community.general.idrac_firmware`` →``dellemc.openmanage.idrac_firmware``) を調整し、dellemc.openmanage コレクションをインストールするようにしてください。" - -#: ../../rst/porting_guides/porting_guide_4.rst:723 -msgid "The deprecated ali_instance_facts module has been removed. Use ali_instance_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ali_instance_facts モジュールが削除されました。代わりに ali_instance_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:724 -msgid "The deprecated gluster_heal_info module has been removed. Use gluster.gluster.gluster_heal_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の gluster_heal_info モジュールが削除されました。代わりに gluster.gluster.gluster_heal_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:725 -msgid "The deprecated gluster_peer module has been removed. Use gluster.gluster.gluster_peer instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の gluster_peer モジュールが削除されました。代わりに gluster.gluster.gluster_peer を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:726 -msgid "The deprecated gluster_volume module has been removed. Use gluster.gluster.gluster_volume instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の gluster_volume モジュールが削除されました。代わりに gluster.gluster.gluster_volume を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:727 -msgid "The deprecated helm module has been removed. Use community.kubernetes.helm instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の helm モジュールが削除されました。代わりに community.kubernetes.helm を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:728 -msgid "The deprecated hpilo_facts module has been removed. Use hpilo_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の hpilo_facts モジュールが削除されました。代わりに hpilo_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:729 -msgid "The deprecated idrac_redfish_facts module has been removed. Use idrac_redfish_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の idrac_redfish_facts モジュールが削除されました。代わりに idrac_redfish_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:730 -msgid "The deprecated jenkins_job_facts module has been removed. Use jenkins_job_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の jenkins_job_facts モジュールが削除されました。代わりに jenkins_job_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:731 -msgid "The deprecated ldap_attr module has been removed. Use ldap_attrs instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ldap_attr モジュールが削除されました。代わりに ldap_attrs を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:732 -msgid "The deprecated memset_memstore_facts module has been removed. Use memset_memstore_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の memset_memstore_facts モジュールが削除されました。代わりに memset_memstore_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:733 -msgid "The deprecated memset_server_facts module has been removed. Use memset_server_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の memset_server_facts モジュールが削除されました。代わりに memset_server_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:734 -msgid "The deprecated na_ontap_gather_facts module has been removed. Use netapp.ontap.na_ontap_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の na_ontap_gather_facts モジュールが削除されました。代わりに netapp.ontap.na_ontap_volume を使用してください (https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:735 -msgid "The deprecated nginx_status_facts module has been removed. Use nginx_status_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の nginx_status_facts モジュールが削除されました。代わりに nginx_status_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:736 -msgid "The deprecated one_image_facts module has been removed. Use one_image_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の one_image_facts モジュールが削除されました。代わりに one_image_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:737 -msgid "The deprecated onepassword_facts module has been removed. Use onepassword_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の onepassword_facts モジュールが削除されました。代わりに onepassword_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:738 -msgid "The deprecated oneview_datacenter_facts module has been removed. Use oneview_datacenter_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_datacenter_facts モジュールが削除されました。代わりに oneview_datacenter_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:739 -msgid "The deprecated oneview_enclosure_facts module has been removed. Use oneview_enclosure_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_enclosure_facts モジュールが削除されました。代わりに oneview_enclosure_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:740 -msgid "The deprecated oneview_ethernet_network_facts module has been removed. Use oneview_ethernet_network_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_ethernet_network_facts モジュールが削除されました。代わりに oneview_ethernet_network_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:741 -msgid "The deprecated oneview_fc_network_facts module has been removed. Use oneview_fc_network_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_fc_network_facts モジュールが削除されました。代わりに oneview_fc_network_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:742 -msgid "The deprecated oneview_fcoe_network_facts module has been removed. Use oneview_fcoe_network_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_fcoe_network_facts モジュールが削除されました。代わりに oneview_fcoe_network_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:743 -msgid "The deprecated oneview_logical_interconnect_group_facts module has been removed. Use oneview_logical_interconnect_group_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_logical_interconnect_group_facts モジュールが削除されました。代わりに oneview_logical_interconnect_group_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:744 -msgid "The deprecated oneview_network_set_facts module has been removed. Use oneview_network_set_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_network_set_facts モジュールが削除されました。代わりに oneview_network_set_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:745 -msgid "The deprecated oneview_san_manager_facts module has been removed. Use oneview_san_manager_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の oneview_san_manager_facts モジュールが削除されました。代わりに oneview_san_manager_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:746 -msgid "The deprecated online_server_facts module has been removed. Use online_server_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の online_server_facts モジュールが削除されました。代わりに online_server_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:747 -msgid "The deprecated online_user_facts module has been removed. Use online_user_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の online_user_facts モジュールが削除されました。代わりに online_user_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:748 -msgid "The deprecated ovirt module has been removed. Use ovirt.ovirt.ovirt_vm instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt モジュールが削除されました。代わりに ovirt.ovirt.ovirt_vm を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:749 -msgid "The deprecated ovirt_affinity_label_facts module has been removed. Use ovirt.ovirt.ovirt_affinity_label_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_affinity_label_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_affinity_label_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:750 -msgid "The deprecated ovirt_api_facts module has been removed. Use ovirt.ovirt.ovirt_api_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_api_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_api_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:751 -msgid "The deprecated ovirt_cluster_facts module has been removed. Use ovirt.ovirt.ovirt_cluster_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_cluster_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_cluster_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:752 -msgid "The deprecated ovirt_datacenter_facts module has been removed. Use ovirt.ovirt.ovirt_datacenter_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_datacenter_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_datacenter_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:753 -msgid "The deprecated ovirt_disk_facts module has been removed. Use ovirt.ovirt.ovirt_disk_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_disk_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_disk_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:754 -msgid "The deprecated ovirt_event_facts module has been removed. Use ovirt.ovirt.ovirt_event_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_event_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_event_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:755 -msgid "The deprecated ovirt_external_provider_facts module has been removed. Use ovirt.ovirt.ovirt_external_provider_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_external_provider_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_external_provider_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:756 -msgid "The deprecated ovirt_group_facts module has been removed. Use ovirt.ovirt.ovirt_group_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_group_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_group_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:757 -msgid "The deprecated ovirt_host_facts module has been removed. Use ovirt.ovirt.ovirt_host_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_host_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_host_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:758 -msgid "The deprecated ovirt_host_storage_facts module has been removed. Use ovirt.ovirt.ovirt_host_storage_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_host_storage_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_host_storage_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:759 -msgid "The deprecated ovirt_network_facts module has been removed. Use ovirt.ovirt.ovirt_network_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_network_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_network_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:760 -msgid "The deprecated ovirt_nic_facts module has been removed. Use ovirt.ovirt.ovirt_nic_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_nic_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_nic_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:761 -msgid "The deprecated ovirt_permission_facts module has been removed. Use ovirt.ovirt.ovirt_permission_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_permission_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_permission_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:762 -msgid "The deprecated ovirt_quota_facts module has been removed. Use ovirt.ovirt.ovirt_quota_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_quota_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_quota_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:763 -msgid "The deprecated ovirt_scheduling_policy_facts module has been removed. Use ovirt.ovirt.ovirt_scheduling_policy_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_scheduling_policy_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_scheduling_policy_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:764 -msgid "The deprecated ovirt_snapshot_facts module has been removed. Use ovirt.ovirt.ovirt_snapshot_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_snapshot_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_snapshot_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:765 -msgid "The deprecated ovirt_storage_domain_facts module has been removed. Use ovirt.ovirt.ovirt_storage_domain_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_storage_domain_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_storage_domain_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:766 -msgid "The deprecated ovirt_storage_template_facts module has been removed. Use ovirt.ovirt.ovirt_storage_template_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_storage_template_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_storage_template_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:767 -msgid "The deprecated ovirt_storage_vm_facts module has been removed. Use ovirt.ovirt.ovirt_storage_vm_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_storage_vm_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_storage_vm_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:768 -msgid "The deprecated ovirt_tag_facts module has been removed. Use ovirt.ovirt.ovirt_tag_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_tag_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_tag_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:769 -msgid "The deprecated ovirt_template_facts module has been removed. Use ovirt.ovirt.ovirt_template_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_template_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_template_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:770 -msgid "The deprecated ovirt_user_facts module has been removed. Use ovirt.ovirt.ovirt_user_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_user_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_user_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:771 -msgid "The deprecated ovirt_vm_facts module has been removed. Use ovirt.ovirt.ovirt_vm_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_vm_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_vm_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:772 -msgid "The deprecated ovirt_vmpool_facts module has been removed. Use ovirt.ovirt.ovirt_vmpool_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の ovirt_vmpool_facts モジュールが削除されました。代わりに ovirt.ovirt.ovirt_vmpool_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:773 -msgid "The deprecated purefa_facts module has been removed. Use purestorage.flasharray.purefa_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の purefa_facts モジュールが削除されました。代わりに purestorage.flasharray.purefa_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:774 -msgid "The deprecated purefb_facts module has been removed. Use purestorage.flasharray.purefb_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の purefb_facts モジュールが削除されました。代わりに purestorage.flasharray.purefb_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:775 -msgid "The deprecated python_requirements_facts module has been removed. Use python_requirements_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の python_requirements_facts モジュールが削除されました。代わりに python_requirements_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:776 -msgid "The deprecated redfish_facts module has been removed. Use redfish_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の redfish_facts モジュールが削除されました。代わりに redfish_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:777 -msgid "The deprecated scaleway_image_facts module has been removed. Use scaleway_image_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_image_facts モジュールが削除されました。代わりに scaleway_image_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:778 -msgid "The deprecated scaleway_ip_facts module has been removed. Use scaleway_ip_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_ip_facts モジュールが削除されました。代わりに scaleway_ip_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:779 -msgid "The deprecated scaleway_organization_facts module has been removed. Use scaleway_organization_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_organization_facts モジュールが削除されました。代わりに scaleway_organization_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:780 -msgid "The deprecated scaleway_security_group_facts module has been removed. Use scaleway_security_group_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_security_group_facts モジュールが削除されました。代わりに scaleway_security_group_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:781 -msgid "The deprecated scaleway_server_facts module has been removed. Use scaleway_server_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_server_facts モジュールが削除されました。代わりに scaleway_server_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:782 -msgid "The deprecated scaleway_snapshot_facts module has been removed. Use scaleway_snapshot_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_snapshot_facts モジュールが削除されました。代わりに scaleway_snapshot_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:783 -msgid "The deprecated scaleway_volume_facts module has been removed. Use scaleway_volume_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の scaleway_volume_facts モジュールが削除されました。代わりに scaleway_volume_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:784 -msgid "The deprecated smartos_image_facts module has been removed. Use smartos_image_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の smartos_image_facts モジュールが削除されました。代わりに smartos_image_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:785 -msgid "The deprecated vertica_facts module has been removed. Use vertica_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の vertica_facts モジュールが削除されました。代わりに vertica_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:786 -msgid "The deprecated xenserver_guest_facts module has been removed. Use xenserver_guest_info instead (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "非推奨の xenserver_guest_facts モジュールが削除されました。代わりに xenserver_guest_info を使用してください（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:787 -msgid "The ovirt_facts docs fragment has been removed (https://github.com/ansible-collections/community.general/pull/1924)." -msgstr "ovirt_facts ドキュメントのフラグメントが削除されました（https://github.com/ansible-collections/community.general/pull/1924）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:788 -msgid "airbrake_deployment - removed deprecated ``token`` parameter. Use ``project_id`` and ``project_key`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "airbrake_deployment - 非推奨の ``token`` パラメーターが削除されました。代わりに ``project_id`` および ``project_key`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:789 -msgid "bigpanda - the alias ``message`` has been removed. Use ``deployment_message`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "bigpanda - エイリアス ``message`` が削除されました。代わりに ``deployment_message`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:790 -msgid "cisco_spark, cisco_webex - the alias ``message`` has been removed. Use ``msg`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "cisco_spark, cisco_webex - エイリアス ``message`` が削除されました。代わりに ``msg`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:791 -msgid "clc_aa_policy - the ``wait`` parameter has been removed. It did not have any effect (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "clc_aa_policy - ``wait`` パラメーターが削除されました。影響はありません（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:792 -msgid "datadog_monitor - the alias ``message`` has been removed. Use ``notification_message`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "datadog_monitor - エイリアス ``message`` が削除されました。代わりに ``notification_message`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:793 -msgid "django_manage - the parameter ``liveserver`` has been removed (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "django_manage - パラメーター ``liveserver`` が削除されました（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:794 -msgid "idrac_redfish_config - the parameters ``manager_attribute_name`` and ``manager_attribute_value`` have been removed. Use ``manager_attributes`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "idrac_redfish_config - ``manager_attribute_name`` パラメーターおよび ``manager_attribute_value`` パラメーターが削除されました。代わりに ``manager_attributes`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:795 -msgid "iso_extract - the alias ``thirsty`` has been removed. Use ``force`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "iso_extract - エイリアス ``thirsty`` が削除されました。代わりに ``force`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:796 -msgid "ldap_entry - the ``params`` parameter is now completely removed. Using it already triggered an error since community.general 0.1.2 (https://github.com/ansible-collections/community.general/pull/2257)." -msgstr "ldap_entry - ``params`` パラメーターは完全に削除されました。community.general 0.1.2 以降、これを使用するとエラーがトリガーされています。https://github.com/ansible-collections/community.general/pull/2257）" - -#: ../../rst/porting_guides/porting_guide_4.rst:797 -msgid "pulp_repo - the ``feed_client_cert`` parameter no longer defaults to the value of the ``client_cert`` parameter (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "pulp_repo - ``feed_client_cert`` パラメーターにより、``client_cert`` パラメーターの値にデフォルト設定されなくなりました（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:798 -msgid "pulp_repo - the ``feed_client_key`` parameter no longer defaults to the value of the ``client_key`` parameter (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "pulp_repo - ``feed_client_key`` パラメーターにより、``client_key`` パラメーターの値にデフォルト設定されなくなりました（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:799 -msgid "pulp_repo - the alias ``ca_cert`` has been removed. Use ``feed_ca_cert`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "pulp_repo - ``ca_cert`` モジュールが削除されました。代わりに ``feed_ca_cert`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:800 -msgid "rax - unused parameter ``service`` removed (https://github.com/ansible-collections/community.general/pull/2020)." -msgstr "rax - 未使用のパラメーター ``service`` が削除されました（https://github.com/ansible-collections/community.general/pull/2020）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:801 -msgid "redfish modules - issuing a data modification command without specifying the ID of the target System, Chassis or Manager resource when there is more than one is no longer allowed. Use the ``resource_id`` option to specify the target ID (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "redfish モジュール - 複数のリソースが許可されなくなったときに、ターゲットシステム、シャーシ、またはマネージャーのリソースの ID を指定せずにデータ変更コマンドを実行することはできなくなりました。``resource_id`` オプションを使用してターゲットIDを指定します（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:802 -msgid "redfish_config - the parameters ``bios_attribute_name`` and ``bios_attribute_value`` have been removed. Use ``bios_attributes`` instead (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "redfish_config - ``bios_attribute_name`` パラメーターおよび ``bios_attribute_value`` パラメーターが削除されました。代わりに ``bios_attributes`` を使用してください（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:803 -msgid "syspatch - the ``apply`` parameter has been removed. This is the default mode, so simply removing it will not change the behavior (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "syspatch - ``apply`` パラメーターが削除されました。これはデフォルトモードであるため、削除しても動作は変更されません（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:804 -msgid "xbps - the ``force`` parameter has been removed. It did not have any effect (https://github.com/ansible-collections/community.general/pull/1926)." -msgstr "xbps - ``force`` パラメーターが削除されました。影響はありません（https://github.com/ansible-collections/community.general/pull/1926）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:809 -msgid "The deprecated ``community.network.ce_sflow`` parameters: ``rate_limit``, ``rate_limit_slot``, and ``forward_enp_slot`` have been removed (https://github.com/ansible-collections/community.network/pull/255)." -msgstr "非推奨の ``community.network.ce_sflow`` パラメーター (``rate_limit``、``rate_limit_slot``、および ``forward_enp_slot``) が削除されました (https://github.com/ansible-collections/community.network/pull/255)。" - -#: ../../rst/porting_guides/porting_guide_4.rst:810 -msgid "The deprecated ``community.network.sros`` netconf plugin has been removed. Use ``nokia.sros.md`` instead (https://github.com/ansible-collections/community.network/pull/255)." -msgstr "非推奨の ``community.network.sros`` netconf プラグインが削除されました。代わりに ``nokia.sros.md`` を使用してください (https://github.com/ansible-collections/community.network/pull/255）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:822 -msgid "Removed module fortios_facts" -msgstr "fortios_facts モジュールを削除" - -#: ../../rst/porting_guides/porting_guide_4.rst:823 -msgid "Removed module fortios_registration_forticare" -msgstr "fortios_registration_forticare モジュールを削除" - -#: ../../rst/porting_guides/porting_guide_4.rst:824 -msgid "Removed module fortios_registration_vdom" -msgstr "fortios_registration_vdom モジュールを削除" - -#: ../../rst/porting_guides/porting_guide_4.rst:825 -msgid "Removed module fortios_system_config_backup_restore" -msgstr "fortios_system_config_backup_restore モジュールを削除" - -#: ../../rst/porting_guides/porting_guide_4.rst:826 -msgid "Removed module fortios_system_vmlicense" -msgstr "fortios_system_vmlicense モジュールを削除" - -#: ../../rst/porting_guides/porting_guide_4.rst:834 -msgid "Starting in 2.14, shell and command modules will no longer have the option to warn and suggest modules in lieu of commands. The ``warn`` parameter to these modules is now deprecated and defaults to ``False``. Similarly, the ``COMMAND_WARNINGS`` configuration option is also deprecated and defaults to ``False``. These will be removed and their presence will become an error in 2.14." -msgstr "2.14 以降、シェルおよびコマンドモジュールでは、コマンドの代わりにモジュールの警告および提案のオプションがなくなりました。これらのモジュールの ``warn`` パラメーターは非推奨となり、デフォルトで ``False`` になりました。同様に、``COMMAND_WARNINGS`` 設定オプションも非推奨で、デフォルトは ``False`` に設定されます。これらは削除され、2.14 ではエラーになります。" - -#: ../../rst/porting_guides/porting_guide_4.rst:835 -msgid "apt_key - the parameter ``key`` does not have any effect, has been deprecated and will be removed in ansible-core version 2.14 (https://github.com/ansible/ansible/pull/70319)." -msgstr "apt_key - パラメーター ``key`` には影響がなく、非推奨になり、ansible-core バージョン 2.14 で削除される予定です（https://github.com/ansible/ansible/pull/70319）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:836 -msgid "psrp - Set the minimum version of ``pypsrp`` to ``0.4.0``." -msgstr "psrp - ``pypsrp`` の最小バージョンを ``0.4.0`` に設定します。" - -#: ../../rst/porting_guides/porting_guide_4.rst:841 -msgid "Deprecate cli_parse module and textfsm, ttp, xml, json parser plugins as they are moved to ansible.utils collection (https://github.com/ansible-collections/ansible.netcommon/pull/182 https://github.com/ansible-collections/ansible.utils/pull/28)" -msgstr "cli_parse モジュールと textfsm、ttp、xml、json パーサープラグインが ansible.utils コレクションに移動したため、非推奨になります（https://github.com/ansible-collections/ansible.netcommon/pull/182 https://github.com/ansible-collections/ansible.utils/pull/28）。" - -#: ../../rst/porting_guides/porting_guide_4.rst:846 -msgid "Deprecated nxos_bgp_af in favour of nxos_bgp_address_family resource module." -msgstr "nxos_bgp_af が非推奨になり、nxos_bgp_address_familyリソースモジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:847 -msgid "Deprecated nxos_bgp_neighbor_af in favour of nxos_bgp_neighbor_address_family resource module." -msgstr "nxos_bgp_neighbor_af を非推奨にし、nxos_bgp_neighbor_address_family リソースモジュールが採用されました。" - -#: ../../rst/porting_guides/porting_guide_4.rst:872 -msgid "cpanm - parameter ``system_lib`` deprecated in favor of using ``become`` (https://github.com/ansible-collections/community.general/pull/2218)." -msgstr "cpanm - パラメーター ``system_lib`` が非推奨になり、``become`` の使用が採用されます（https://github.com/ansible-collections/community.general/pull/2218）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:8 -msgid "Ansible 5 Porting Guide" -msgstr "Ansible 5 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:15 -msgid "Ansible 5 is based on Ansible-core 2.12." -msgstr "Ansible 5 は Ansible-core 2.12 をベースにしています。" - -#: ../../rst/porting_guides/porting_guide_5.rst:18 -msgid "We suggest you read this page along with the `Ansible 5 Changelog `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible 5 Changelog `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_5.rst:24 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:22 -msgid "When calling tasks and setting ``async``, setting ``ANSIBLE_ASYNC_DIR`` under ``environment:`` is no longer valid. Instead, use the shell configuration variable ``async_dir``, for example by setting ``ansible_async_dir``:" -msgstr "タスクを呼び出して ``async`` を設定する場合は、``environment:`` で ``ANSIBLE_ASYNC_DIR`` の設定は有効ではなくなりました。代わりに、``ansible_async_dir`` を設定してシェル設定変数 ``async_dir`` を使用します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:37 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:35 -msgid "The ``undef()`` function is added to the templating environment for creating undefined variables directly in a template. Optionally, a hint may be provided for variables which are intended to be overridden." -msgstr "未定義の変数をテンプレートで直接作成するために、``undef()`` 関数が環境のテンプレートに追加されました。オプションで、上書きする変数にヒントを指定できます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:49 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:47 -msgid "The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``." -msgstr "``INTERPRETER_PYTHON`` のデフォルト値は ``auto`` に変更になりましたが、``INTERPRETER_PYTHON_FALLBACK`` の Python インタープリターのリストが、Python 2 よりも Python 3 を優先するように変更されました。これらの変更の組み合わせにより、新しいデフォルト動作では、リモートホストの Python 2 よりも Python 3 が暗黙的に優先されます。これまで、インタープリター検出で Python 3 が使用されているという非推奨の警告は、Python 3 を使用しますが、インタープリターの検出が ``/usr/bin/python`` に設定されている状態でした。" - -#: ../../rst/porting_guides/porting_guide_5.rst:51 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:49 -msgid "``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable." -msgstr "``INTERPRETER_PYTHON_FALLBACK`` は、``ansible_interpreter_python_fallback`` 変数を設定して、インタープリターのデフォルトリストから変更できます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:53 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:51 -msgid "See :ref:`interpreter discovery documentation ` for more details." -msgstr "詳細は、:ref:`interpreter discovery documentation ` を参照してください。" - -#: ../../rst/porting_guides/porting_guide_5.rst:59 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:57 -msgid "Python 3.8 on the controller node is a hard requirement for this release. The command line scripts will not function with a lower Python version." -msgstr "コントローラーノードの Python 3.8 は、本リリースではハード要件です。コマンドラインスクリプトは、より低い Python バージョンでは機能しません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:60 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:58 -msgid "``ansible-vault`` no longer supports ``PyCrypto`` and requires ``cryptography``." -msgstr "``ansible-vault`` は ``PyCrypto`` に対応しなくなり、``cryptography`` が必要なくなりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:65 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:63 -msgid "Python 2.6 on the target node is deprecated in this release. ``ansible-core`` 2.13 will remove support for Python 2.6." -msgstr "ターゲットノード上の Python 2.6 は本リリースで非推奨となりました。``ansible-core`` 2.13 では、Python 2.6 のサポートが削除されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:66 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:64 -msgid "Bare variables in conditionals: ``when`` conditionals no longer automatically parse string booleans such as ``\"true\"`` and ``\"false\"`` into actual booleans. Any variable containing a non-empty string is considered true. This was previously configurable with the ``CONDITIONAL_BARE_VARS`` configuration option (and the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable). This setting no longer has any effect. Users can work around the issue by using the ``|bool`` filter:" -msgstr "条件のベアメタル変数: ``when`` 条件は、``\"true\"`` や ``\"false\"`` などの文字列ブール値を実際のブール値に自動的に解析しなくなりました。空でない文字列を含む変数は true と見なされます。これは以前は ``CONDITIONAL_BARE_VARS`` 設定オプション（および ``ANSIBLE_CONDITIONAL_BARE_VARS`` 環境変数）で設定可能でした。この設定は影響はありません。``|bool`` フィルターを使用することで問題を回避できます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:80 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:78 -msgid "The ``_remote_checksum()`` method in ``ActionBase`` is deprecated. Any action plugin using this method should use ``_execute_remote_stat()`` instead." -msgstr "``ActionBase`` の ``_remote_checksum()`` メソッドは非推奨になりました。このメソッドを使用するアクションプラグインは、代わりに ``_execute_remote_stat()`` を使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:85 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:83 -msgid "``cron`` now requires ``name`` to be specified in all cases." -msgstr "``cron`` は、すべてのケースで ``name`` を指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:86 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:84 -msgid "``cron`` no longer allows a ``reboot`` parameter. Use ``special_time: reboot`` instead." -msgstr "``cron`` は、``reboot`` パラメーターが許可されなくなりました。代わりに ``special_time: reboot`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_5.rst:87 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:85 -msgid "``hostname`` - On FreeBSD, the ``before`` result will no longer be ``\"temporarystub\"`` if permanent hostname file does not exist. It will instead be ``\"\"`` (empty string) for consistency with other systems." -msgstr "``hostname`` - FreeBSD では、永続的なホスト名ファイルが存在しない場合、``before`` の結果は ``\"temporarystub\"`` にならなくなりました。これは、他のシステムとの整合性を保つために ``\"\"`` （空の文字列）になります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:88 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:86 -msgid "``hostname`` - On OpenRC and Solaris based systems, the ``before`` result will no longer be ``\"UNKNOWN\"`` if the permanent hostname file does not exist. It will instead be ``\"\"`` (empty string) for consistency with other systems." -msgstr "``hostname`` - OpenRC および Solaris ベースのシステムでは、永続的なホスト名ファイルが存在しない場合、``before`` の結果は ``\"UNKNOWN\"`` になります。これは、他のシステムとの整合性を保つために ``\"\"``（空の文字列）になります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:89 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:87 -msgid "``pip`` now uses the ``pip`` Python module installed for the Ansible module's Python interpreter, if available, unless ``executable`` or ``virtualenv`` were specified." -msgstr "``pip`` は、``executable`` または ``virtualenv`` が指定されていない限り、Ansible モジュールの Python インタープリターにインストールされた ``pip`` Python モジュールを使用するようになりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:115 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:113 -msgid "``unique`` filter with Jinja2 < 2.10 is case-sensitive and now raise coherently an error if ``case_sensitive=False`` instead of when ``case_sensitive=True``." -msgstr "2.10 より前の Jinja2 を使用する ``unique`` フィルターは、大文字と小文字が区別され、``case_sensitive=True`` ではなく ``case_sensitive=False`` の場合に一貫してエラーが発生していました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:116 -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:114 -msgid "Set theory filters (``intersect``, ``difference``, ``symmetric_difference`` and ``union``) are now case-sensitive. Explicitly use ``case_sensitive=False`` to keep previous behavior. Note: with Jinja2 < 2.10, the filters were already case-sensitive by default." -msgstr "理論フィルター（``intersect``、``difference``、``symmetric_difference``、および ``union``）の設定は、大文字と小文字が区別されるようになりました。明示的な ``case_sensitive=False`` を使用して以前の動作を維持します。2.10 より前の Jinja2 で、フィルターはすでに大文字と小文字を区別しています。" - -#: ../../rst/porting_guides/porting_guide_5.rst:117 -msgid "``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256``, now default to the \"2b\" format and if the \"2a\" format is required it must be specified." -msgstr "``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256`` はデフォルトで「2b」フォーマットになり、「2a」フォーマットが必要な場合は指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:131 -msgid "Porting Guide for v5.9.0" -msgstr "v5.9.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:134 -#: ../../rst/porting_guides/porting_guide_5.rst:164 -#: ../../rst/porting_guides/porting_guide_5.rst:240 -#: ../../rst/porting_guides/porting_guide_5.rst:429 -#: ../../rst/porting_guides/porting_guide_6.rst:158 -#: ../../rst/porting_guides/porting_guide_6.rst:242 -#: ../../rst/porting_guides/porting_guide_6.rst:282 -#: ../../rst/porting_guides/porting_guide_6.rst:314 -#: ../../rst/porting_guides/porting_guide_6.rst:383 -#: ../../rst/porting_guides/porting_guide_7.rst:99 -#: ../../rst/porting_guides/porting_guide_7.rst:218 -#: ../../rst/porting_guides/porting_guide_7.rst:269 -msgid "Added Collections" -msgstr "コレクションの追加" - -#: ../../rst/porting_guides/porting_guide_5.rst:136 -#: ../../rst/porting_guides/porting_guide_6.rst:385 -msgid "cisco.dnac (version 6.4.0)" -msgstr "cisco.dnac (version 6.4.0)" - -#: ../../rst/porting_guides/porting_guide_5.rst:137 -#: ../../rst/porting_guides/porting_guide_6.rst:387 -msgid "community.sap_libs (version 1.1.0)" -msgstr "community.sap_libs (version 1.1.0)" - -#: ../../rst/porting_guides/porting_guide_5.rst:145 -#: ../../rst/porting_guides/porting_guide_5.rst:225 -#: ../../rst/porting_guides/porting_guide_6.rst:740 -msgid "Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5." -msgstr "FortiOS 7.0.2、7.0.3、7.0.4、7.0.5 をサポートします。" - -#: ../../rst/porting_guides/porting_guide_5.rst:150 -#: ../../rst/porting_guides/porting_guide_6.rst:891 -msgid "The collection ``community.sap`` has been renamed to ``community.sap_libs``. For now both collections are included in Ansible. The content in ``community.sap`` will be replaced with deprecated redirects to the new collection in Ansible 7.0.0, and these redirects will eventually be removed from Ansible. Please update your FQCNs for ``community.sap``." -msgstr "コレクション ``community.sap`` の名前が ``community.sap_libs`` に変更されました。両方のコレクションが Ansible に含まれています。``community.sap`` の内容は、Ansible 7.0.0 の新しいコレクションへの非推奨リダイレクトに置き換えられます。これらのリダイレクトは、最終的に Ansible から削除されます。``community.sap`` の FQCN を更新してください。" - -#: ../../rst/porting_guides/porting_guide_5.rst:155 -#: ../../rst/porting_guides/porting_guide_6.rst:925 -msgid "Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.docker/pull/361)." -msgstr "Ansible 2.9 および ansible-base 2.10 のサポートは非推奨になり、次のメジャーリリース (community.docker 3.0.0) で削除されます。モジュールによっては、その後もこれらのバージョンで引き続き動作する可能性がありますが、サポートするために必要な互換性コードは保持されなくなります (https://github.com/ansible-collections/community.docker/pull/361)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:156 -#: ../../rst/porting_guides/porting_guide_6.rst:926 -msgid "The dependency on docker-compose for Execution Environments is deprecated and will be removed in community.docker 3.0.0. The `Python docker-compose library `__ is unmaintained and can cause dependency issues. You can manually still install it in an Execution Environment when needed (https://github.com/ansible-collections/community.docker/pull/373)." -msgstr "実行環境の docker-compose への依存は非推奨になり、community.docker3.0.0 で削除されます。`Python docker-compose library `__ は保守されておらず、依存関係の問題を引き起こす可能性があります。必要に応じて、実行環境に手動でインストールすることもできます (https://github.com/ansible-collections/community.docker/pull/373)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:157 -#: ../../rst/porting_guides/porting_guide_6.rst:927 -msgid "Various modules - the default of ``tls_hostname`` that was supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362)." -msgstr "さまざまなモジュール - community.docker 2.0.0 で削除される予定であった ``tls_hostname`` のデフォルトが、バージョン 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362) で削除されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:158 -#: ../../rst/porting_guides/porting_guide_6.rst:928 -msgid "docker_stack - the return values ``out`` and ``err`` that were supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362)." -msgstr "docker_stack - community.docker 2.0.0 で削除される予定であった戻り値 ``out`` および ``err`` が、バージョン 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362) で削除されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:161 -msgid "Porting Guide for v5.8.0" -msgstr "v5.8.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:166 -#: ../../rst/porting_guides/porting_guide_6.rst:388 -msgid "vmware.vmware_rest (version 2.1.5)" -msgstr "vmware.vmware_rest (バージョン 2.1.5)" - -#: ../../rst/porting_guides/porting_guide_5.rst:172 -#: ../../rst/porting_guides/porting_guide_5.rst:205 -msgid "vmware.vmware_rest" -msgstr "vmware.vmware_rest" - -#: ../../rst/porting_guides/porting_guide_5.rst:174 -msgid "The vmware_rest 2.0.0 support vSphere 7.0.2 onwards." -msgstr "vmware_rest 2.0.0 は vSphere 7.0.2 以降をサポートします。" - -#: ../../rst/porting_guides/porting_guide_5.rst:175 -msgid "vcenter_vm_storage_policy - the format of the ``disks`` parameter has changed." -msgstr "vcenter_vm_storage_policy - ``disks`` パラメーターの形式が変更されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:176 -msgid "vcenter_vm_storage_policy - the module has a new mandatory paramter: ``vm_home``." -msgstr "vcenter_vm_storage_policy - モジュールには、必須のパラメーターが新たに追加されました (``vm_home``)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:184 -#: ../../rst/porting_guides/porting_guide_6.rst:697 -msgid "The community.mysql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.mysql/pull/343)." -msgstr "community.mysql コレクションは ``Ansible 2.9`` および ``ansible-base 2.10`` をサポートしなくなりました。使用を防ぐための積極的な措置は講じておらず、モジュールに互換性のないコードを導入する予定はありませんが、``Ansible 2.9`` および ``ansible-base 2.10`` に対するテストは停止します。どちらも間もなくライフサイクル終了日に達します。使用を継続している場合は、できるだけ早く ``latest Ansible / ansible-core 2.11 or later`` へのアップグレードを検討する必要があります (https://github.com/ansible-collections/community.mysql/pull/343)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:189 -#: ../../rst/porting_guides/porting_guide_6.rst:707 -msgid "The community.postgresql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.postgresql/pull/245)." -msgstr "community.postgresql コレクションは ``Ansible 2.9`` および ``ansible-base 2.10`` をサポートしなくなりました。使用を防ぐための積極的な措置は講じておらず、モジュールに互換性のないコードを導入する予定はありませんが、``Ansible 2.9`` および ``ansible-base 2.10`` に対するテストは停止します。どちらも間もなくライフサイクル終了日に達します。使用を継続している場合は、できるだけ早く ``latest Ansible / ansible-core 2.11 or later`` へのアップグレードを検討する必要があります (https://github.com/ansible-collections/community.postgresql/pull/245)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:197 -#: ../../rst/porting_guides/porting_guide_6.rst:948 -msgid "token_validate options - the shared auth option ``token_validate`` will change its default from ``True`` to ``False`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``True`` (https://github.com/ansible-collections/community.hashi_vault/issues/248)." -msgstr "token_validate オプション - 共有認証オプション ``token_validate`` のデフォルトは、community.hashi_vault バージョン 4.0.0 で ``True`` から ``False`` に変更されます。``vault_login`` ルックアップおよびモジュールは、デフォルト値の ``True`` を保持します (https://github.com/ansible-collections/community.hashi_vault/issues/248)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:202 -#: ../../rst/porting_guides/porting_guide_6.rst:954 -msgid "Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.network 4.0.0) this spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.network 3.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.network/pull/382)." -msgstr "Ansible 2.9 および ansible-base 2.10 のサポートは非推奨になり、今春の次のメジャーリリース (community.network 4.0.0) で削除される予定です。ほとんどのコンテンツは ansible-base 2.10 で引き続き機能すると予想されますが、モジュールおよび action プラグインのシンボリックリンクは削除され、Ansible 2.9 では使用できないようになります。 Ansible 2.9 および ansible-base 2.10 では community.network 3.x.y を使用してください。ライフサイクル終了後でも、これらのリリースは Ansible 2.9 および ansible-base 2.10 のサポートを継続するためです (https://github.com/ansible-community/community-topics/issues/50、https://github.com/ansible-collections/community.network/pull/382)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:207 -msgid "vcenter_vm_storage_policy_compliance - drop the module, it returns 404 error." -msgstr "vcenter_vm_storage_policy_compliance - モジュールをドロップし、404 エラーを返します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:208 -msgid "vcenter_vm_tools - remove the ``upgrade`` state." -msgstr "vcenter_vm_tools - ``upgrade`` の状態を削除します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:209 -msgid "vcenter_vm_tools_installer - remove the module from the collection." -msgstr "vcenter_vm_tools_installer - コレクションからモジュールを削除します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:212 -msgid "Porting Guide for v5.7.0" -msgstr "v5.7.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:220 -#: ../../rst/porting_guides/porting_guide_6.rst:711 -msgid "postgresql_user - the ``priv`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_privs`` module to grant/revoke privileges instead (https://github.com/ansible-collections/community.postgresql/issues/212)." -msgstr "postgresql_user - ``priv`` 引数は非推奨になり、``community.postgresql 3.0.0`` で削除されます。権限を付与/取り消すには、代わりに ``postgresql_privs``を使用してください (https://github.com/ansible-collections/community.postgresql/issues/212)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:233 -#: ../../rst/porting_guides/porting_guide_6.rst:938 -msgid "nmcli - deprecate default hairpin mode for a bridge. This so we can change it to ``false`` in community.general 7.0.0, as this is also the default in ``nmcli`` (https://github.com/ansible-collections/community.general/pull/4334)." -msgstr "nmcli - ブリッジのデフォルト hairpin モードを非推奨にします。したがって、community.general 7.0.0 ではこれを ``false`` に変更できます。これは、``nmcli`` のデフォルトでもあります (https://github.com/ansible-collections/community.general/pull/4334)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:234 -#: ../../rst/porting_guides/porting_guide_6.rst:940 -msgid "proxmox inventory plugin - the current default ``true`` of the ``want_proxmox_nodes_ansible_host`` option has been deprecated. The default will change to ``false`` in community.general 6.0.0. To keep the current behavior, explicitly set ``want_proxmox_nodes_ansible_host`` to ``true`` in your inventory configuration. We suggest to already switch to the new behavior by explicitly setting it to ``false``, and by using ``compose:`` to set ``ansible_host`` to the correct value. See the examples in the plugin documentation for details (https://github.com/ansible-collections/community.general/pull/4466)." -msgstr "proxmox インベントリープラグイン - ``want_proxmox_nodes_ansible_host`` オプションの現在のデフォルト ``true`` が非推奨になりました。community.general 6.0.0 では、デフォルトが ``false`` に変更されます。現在の動作を維持するには、インベントリー設定で ``want_proxmox_nodes_ansible_host`` を明示的に ``true`` に設定します。明示的に ``false`` に設定し、``compose:`` を使用して ``ansible_host`` を正しい値に設定することで新しい動作に切り替えることをお勧めします。詳細は、プラグインドキュメントの例 (https://github.com/ansible-collections/community.general/pull/4466) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_5.rst:237 -msgid "Porting Guide for v5.6.0" -msgstr "v5.6.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:242 -#: ../../rst/porting_guides/porting_guide_6.rst:386 -msgid "community.sap (version 1.0.0)" -msgstr "community.sap (バージョン 1.0.0)" - -#: ../../rst/porting_guides/porting_guide_5.rst:250 -#: ../../rst/porting_guides/porting_guide_6.rst:909 -msgid "Deprecates lldp module." -msgstr "lldp モジュールが非推奨になります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:253 -msgid "Porting Guide for v5.5.0" -msgstr "v5.5.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:261 -#: ../../rst/porting_guides/porting_guide_6.rst:406 -msgid "pacman - ``update_cache`` cannot differentiate between up to date and outdated package lists and will report ``changed`` in both situations (https://github.com/ansible-collections/community.general/pull/4318)." -msgstr "pacman - ``update_cache`` は最新のパッケージ一覧と古いパッケージ一覧を区別できず、両方の状況で ``changed`` を報告します（https://github.com/ansible-collections/community.general/pull/4318）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:262 -#: ../../rst/porting_guides/porting_guide_6.rst:407 -msgid "pacman - binaries specified in the ``executable`` parameter must support ``--print-format`` in order to be used by this module. In particular, AUR helper ``yay`` is known not to currently support it (https://github.com/ansible-collections/community.general/pull/4312)." -msgstr "pacman - このモジュールで使用するためには、``executable`` パラメーターで指定されたバイナリーは ``--print-format`` をサポートする必要があります。特に、AUR ヘルパー ``yay`` は現在サポートしていないことが知られています（https://github.com/ansible-collections/community.general/pull/4312）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:270 -#: ../../rst/porting_guides/porting_guide_6.rst:939 -msgid "pacman - from community.general 5.0.0 on, the ``changed`` status of ``update_cache`` will no longer be ignored if ``name`` or ``upgrade`` is specified. To keep the old behavior, add something like ``register: result`` and ``changed_when: result.packages | length > 0`` to your task (https://github.com/ansible-collections/community.general/pull/4329)." -msgstr "pacman - community.general 5.0.0 から、``name`` または ``upgrade`` が指定されている場合は ``update_cache`` の``changed``ステータスは無視されなくなりました。以前の動作を維持するには、``register: result`` および``changed_when: result.packages | length > 0``をタスクに追加します（https://github.com/ansible-collections/community.general/pull/4329）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:273 -msgid "Porting Guide for v5.4.0" -msgstr "v5.4.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:279 -#: ../../rst/porting_guides/porting_guide_6.rst:338 -#: ../../rst/porting_guides/porting_guide_6.rst:595 -#: ../../rst/porting_guides/porting_guide_7.rst:146 -#: ../../rst/porting_guides/porting_guide_7.rst:159 -#: ../../rst/porting_guides/porting_guide_7.rst:544 -msgid "chocolatey.chocolatey" -msgstr "chocolatey.chocolatey" - -#: ../../rst/porting_guides/porting_guide_5.rst:281 -#: ../../rst/porting_guides/porting_guide_6.rst:597 -msgid "win_chocolatey - Added choco_args option to pass additional arguments directly to Chocolatey." -msgstr "win_chocolatey - 追加の引数を直接 Chocolatey に渡すために choco_args オプションが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:286 -#: ../../rst/porting_guides/porting_guide_6.rst:775 -msgid "Add 'pool' as value to server key in ntp_global." -msgstr "ntp_global のサーバーキーに「pool」が値として追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:294 -msgid "`ios_acls` - Deprecated fragment attribute added boolean alternate as enable_fragment." -msgstr "`ios_acls` - 非推奨のフラグメント属性により、enable_fragment としてブール値代替が追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:297 -msgid "Porting Guide for v5.3.0" -msgstr "v5.3.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:305 -#: ../../rst/porting_guides/porting_guide_6.rst:734 -msgid "bigip_device_info - pagination logic has also been added to help with api stability." -msgstr "bigip_device_info - API の安定性に役立つページネーションロジックも追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:306 -#: ../../rst/porting_guides/porting_guide_6.rst:735 -msgid "bigip_device_info - the module no longer gathers information from all partitions on device. This change will stabalize the module by gathering resources only from the given partition and prevent the module from gathering way too much information that might result in crashing." -msgstr "bigip_device_info - モジュールは、デバイスのすべてのパーティションから情報を収集しなくなりました。この変更により、指定のパーティションからのみリソースを収集し、モジュールが大量の情報を収集してクラッシュするのを防ぐことで、モジュールを安定させます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:314 -#: ../../rst/porting_guides/porting_guide_6.rst:936 -msgid "mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140)." -msgstr "メールコールバックプラグイン - ``sender`` を指定しない設定は非推奨になり、community.general 6.0.0 では許可されません（https://github.com/ansible-collections/community.general/pull/4140）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:317 -msgid "Porting Guide for v5.2.0" -msgstr "v5.2.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:325 -#: ../../rst/porting_guides/porting_guide_5.rst:364 -#: ../../rst/porting_guides/porting_guide_6.rst:324 -#: ../../rst/porting_guides/porting_guide_6.rst:412 -#: ../../rst/porting_guides/porting_guide_7.rst:288 -msgid "idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again." -msgstr "idrac_user - Issue(192043)。モジュールは ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress`` メッセージでエラーが発生する可能性があります。ジョブが完了するまで待機し、タスクを再度実行します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:326 -#: ../../rst/porting_guides/porting_guide_5.rst:365 -#: ../../rst/porting_guides/porting_guide_6.rst:325 -#: ../../rst/porting_guides/porting_guide_6.rst:413 -#: ../../rst/porting_guides/porting_guide_7.rst:289 -msgid "ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters." -msgstr "ome_application_alerts_smtp - Issue(212310)。destination_address が 255 文字を超える場合に、モジュールは適切なエラーメッセージを提供しません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:327 -#: ../../rst/porting_guides/porting_guide_5.rst:366 -#: ../../rst/porting_guides/porting_guide_6.rst:326 -#: ../../rst/porting_guides/porting_guide_6.rst:414 -#: ../../rst/porting_guides/porting_guide_7.rst:290 -msgid "ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters." -msgstr "ome_application_alerts_syslog - Issue(215374)。destination_address が 255 文字を超える場合に、モジュールは適切なエラーメッセージを提供しません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:328 -#: ../../rst/porting_guides/porting_guide_6.rst:327 -#: ../../rst/porting_guides/porting_guide_6.rst:416 -#: ../../rst/porting_guides/porting_guide_7.rst:291 -msgid "ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular." -msgstr "ome_device_local_access_configuration - Issue(215035)。パラメーター timeout_limit にサポートされていない値が指定されている場合に、モジュールは ``Successfully updated the local access setting`` を報告します。ただし、この値は OpenManage Enterprise Modular では実際には適用されません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:329 -#: ../../rst/porting_guides/porting_guide_6.rst:328 -#: ../../rst/porting_guides/porting_guide_6.rst:417 -#: ../../rst/porting_guides/porting_guide_7.rst:292 -msgid "ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters." -msgstr "ome_device_local_access_configuration - Issue(217865)。user_defined および lcd_language パラメーターにサポートされていない値を指定すると、モジュールは適切なエラーメッセージを表示しません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:330 -#: ../../rst/porting_guides/porting_guide_5.rst:367 -#: ../../rst/porting_guides/porting_guide_6.rst:329 -#: ../../rst/porting_guides/porting_guide_6.rst:418 -#: ../../rst/porting_guides/porting_guide_7.rst:293 -msgid "ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout." -msgstr "ome_device_network_services - Issue(212681)。パラメーター port_number、community_name、max_sessions、max_auth_retries、および idle_timeout にサポートされていない値を指定すると、このモジュールは適切なエラーメッセージを提供しません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:331 -#: ../../rst/porting_guides/porting_guide_5.rst:368 -#: ../../rst/porting_guides/porting_guide_6.rst:420 -msgid "ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``" -msgstr "ome_device_power_settings - Issue(212679)。パラメーター ``power_cap`` に指定された値がサポートされる 0 から 32767 の範囲内にない場合、モジュールは``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``のメッセージと共にエラーを発生します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:332 -#: ../../rst/porting_guides/porting_guide_5.rst:369 -#: ../../rst/porting_guides/porting_guide_6.rst:332 -#: ../../rst/porting_guides/porting_guide_6.rst:423 -#: ../../rst/porting_guides/porting_guide_7.rst:296 -msgid "ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified." -msgstr "ome_smart_fabric_uplink - Issue(186024)。OpenManage Enterprise Modular でサポートされていても、モジュールでは同じ名前の複数のアップリンクの作成はできません。アップリンクが既存のアップリンクと同じ名前を使用して作成されると、既存のアップリンクが変更されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:337 -#: ../../rst/porting_guides/porting_guide_6.rst:428 -msgid "purefa_admin - Once `max_login` and `lockout` have been set there is currently no way to rest these to zero except through the FlashArray GUI" -msgstr "purefa_admin - `max_login` および `lockout` を設定すると、現在 FlashArray GUI 以外はゼロに戻す方法はありません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:345 -#: ../../rst/porting_guides/porting_guide_6.rst:673 -msgid "meraki_mr_radio - New module" -msgstr "meraki_mr_radio - 新しいモジュール" - -#: ../../rst/porting_guides/porting_guide_5.rst:353 -#: ../../rst/porting_guides/porting_guide_6.rst:964 -msgid "purefa_sso - Deprecated in favor of M(purefa_admin). Will be removed in Collection 2.0" -msgstr "purefa_sso - M（purefa_admin）が優先されるため非推奨になりました。コレクション 2.0 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_5.rst:356 -msgid "Porting Guide for v5.1.0" -msgstr "v5.1.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:386 -#: ../../rst/porting_guides/porting_guide_6.rst:828 -msgid "the \"legacy\" integration test setup has been removed; this does not affect end users and is only relevant to contributors (https://github.com/ansible-collections/community.hashi_vault/pull/191)." -msgstr "「レガシー」インテグレーションテストの設定が削除されました。これはエンドユーザーには影響しませんが、コントリビューターに関係します（https://github.com/ansible-collections/community.hashi_vault/pull/191）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:404 -#: ../../rst/porting_guides/porting_guide_6.rst:937 -msgid "module_helper module utils - deprecated the attribute ``ModuleHelper.VarDict`` (https://github.com/ansible-collections/community.general/pull/3801)." -msgstr "module_helper モジュールユーティリティー - 属性``ModuleHelper.VarDict``が非推奨になりました（https://github.com/ansible-collections/community.general/pull/3801）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:409 -#: ../../rst/porting_guides/porting_guide_6.rst:946 -msgid "Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.hashi_vault 3.0.0) next spring (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.hashi_vault/issues/189)." -msgstr "Ansible 2.9 および ansible-base 2.10 のサポートは非推奨になり、来年春の次のメジャーリリース(community.hashi_vault 3.0.0)で削除される予定です（https://github.com/ansible-community/community-topics/issues/50、https://github.com/ansible-collections/community.hashi_vault/issues/189）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:410 -#: ../../rst/porting_guides/porting_guide_6.rst:947 -msgid "aws_iam_login auth method - the ``aws_iam_login`` method has been renamed to ``aws_iam``. The old name will be removed in collection version ``3.0.0``. Until then both names will work, and a warning will be displayed when using the old name (https://github.com/ansible-collections/community.hashi_vault/pull/193)." -msgstr "aws_iam_login 認証メソッド - ``aws_iam_login`` メソッドの名前が ``aws_iam`` に変更されました。古い名前はコレクションバージョン ``3.0.0`` で削除されます。それまでは両方の名前が機能し、古い名前を使用すると警告が表示されます（https://github.com/ansible-collections/community.hashi_vault/pull/193）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:418 -msgid "Porting Guide for v5.0.1" -msgstr "v5.0.1 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:423 -msgid "Raised python requirement of the ansible package from >=2.7 to >=3.8 to match ansible-core" -msgstr "ansible-core に一致させるために、ansible パッケージの Python 要件を 2.7 以上から 3.8 以上に上げました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:426 -msgid "Porting Guide for v5.0.0" -msgstr "v5.0.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_5.rst:431 -msgid "cisco.ise (version 1.2.1)" -msgstr "cisco.ise（バージョン 1.2.1）" - -#: ../../rst/porting_guides/porting_guide_5.rst:432 -msgid "cloud.common (version 2.1.0)" -msgstr "cloud.common (バージョン 2.1.0)" - -#: ../../rst/porting_guides/porting_guide_5.rst:433 -msgid "community.ciscosmb (version 1.0.4)" -msgstr "community.ciscosmb (バージョン 1.0.4)" - -#: ../../rst/porting_guides/porting_guide_5.rst:434 -msgid "community.dns (version 2.0.3)" -msgstr "community.dns (バージョン 2.0.3)" - -#: ../../rst/porting_guides/porting_guide_5.rst:435 -msgid "infoblox.nios_modules (version 1.1.2)" -msgstr "infoblox.nios_modules (バージョン 1.1.2)" - -#: ../../rst/porting_guides/porting_guide_5.rst:436 -msgid "netapp.storagegrid (version 21.7.0)" -msgstr "netapp.storagegrid (バージョン 21.7.0)" - -#: ../../rst/porting_guides/porting_guide_5.rst:444 -msgid "ansible-test - Tab completion anywhere other than the end of the command with the new composite options will provide incorrect results. See `issue 351 `_ for additional details." -msgstr "ansible-test - 新しい複合オプションを使用したコマンドの終わり以外の場所でタブ補完を行うと、誤った結果が得られます。詳細は、`issue 351 `_ を参照してください。" - -#: ../../rst/porting_guides/porting_guide_5.rst:450 -msgid "ome_device_power_settings - Issue(212679) The ome_device_power_settings module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``" -msgstr "ome_device_power_settings - Issue(212679)。パラメーター ``power_cap`` に指定された値がサポートされる 0 から 32767 の範囲内にない場合、ome_device_power_settingsモジュールは``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``のメッセージと共にエラーを発生します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:451 -msgid "ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified." -msgstr "ome_smart_fabric_uplink - Issue(186024)。OpenManage Enterprise Modular でサポートされていても、ome_smart_fabric_uplinkモジュールでは同じ名前の複数のアップリンクの作成はできません。アップリンクが既存のアップリンクと同じ名前を使用して作成されると、既存のアップリンクが変更されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:465 -msgid "Action, module, and group names in module_defaults must be static values. Their values can still be templates." -msgstr "module_defaults の アクション、モジュール、およびグループ名は静的な値である必要があります。その値はテンプレートにすることができます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:466 -msgid "Fully qualified 'ansible.legacy' plugin names are not included implicitly in action_groups." -msgstr "完全修飾「ansible.legacy」プラグイン名は、action_groups に暗黙的に含まれません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:467 -msgid "Unresolvable groups, action plugins, and modules in module_defaults are an error." -msgstr "module_defaults の解決できないグループ、アクションプラグイン、およびモジュールはエラーです。" - -#: ../../rst/porting_guides/porting_guide_5.rst:468 -msgid "ansible-test - Automatic installation of requirements for \"cloud\" test plugins no longer occurs. The affected test plugins are ``aws``, ``azure``, ``cs``, ``hcloud``, ``nios``, ``opennebula``, ``openshift`` and ``vcenter``. Collections should instead use one of the supported integration test requirements files, such as the ``tests/integration/requirements.txt`` file." -msgstr "ansible-test -「クラウド」テストプラグインの要件の自動インストールは発生しなくなりました。影響を受けるテストプラグインは、``aws``、``azure``、``cs``、``hcloud``、``nios``、``opennebula``、``openshift``、および ``vcenter`` です。コレクションは、代わりに ``tests/integration/requirements.txt`` ファイルなどのサポートされるインテグレーションテスト要件ファイルのいずれかを使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:469 -msgid "ansible-test - The HTTP Tester is no longer available with the ``ansible-test shell`` command. Only the ``integration`` and ``windows-integration`` commands provide HTTP Tester." -msgstr "ansible-test - HTTP Testerは ``ansible-test shell`` コマンドで利用できなくなりました。``integration`` コマンドおよび ``windows-integration`` コマンドのみが HTTP Testerを提供します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:470 -msgid "ansible-test - The ``--disable-httptester`` option is no longer available. The HTTP Tester is no longer optional for tests that specify it." -msgstr "ansible-test - ``--disable-httptester`` オプションは利用できなくなりました。HTTP Testerは、それを指定するテストのオプションではなくなりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:471 -msgid "ansible-test - The ``--httptester`` option is no longer available. To override the container used for HTTP Tester tests, set the ``ANSIBLE_HTTP_TEST_CONTAINER`` environment variable instead." -msgstr "ansible-test - ``--httptester`` オプションは利用できなくなりました。HTTP Testerのテストに使用するコンテナーを上書きするには、代わりに ``ANSIBLE_HTTP_TEST_CONTAINER`` 環境変数を設定します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:472 -msgid "ansible-test - Unit tests for ``modules`` and ``module_utils`` are now limited to importing only ``ansible.module_utils`` from the ``ansible`` module." -msgstr "ansible-test - ``modules`` および ``module_utils`` のユニットテストは、``ansible`` モジュールからの ``ansible.module_utils`` のインポートだけに制限されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:473 -msgid "conditionals - ``when`` conditionals no longer automatically parse string booleans such as ``\"true\"`` and ``\"false\"`` into actual booleans. Any non-empty string is now considered true. The ``CONDITIONAL_BARE_VARS`` configuration variable no longer has any effect." -msgstr "conditionals - ``when`` 条件は、``\"true\"`` や ``\"false\"`` などの文字列ブール値を実際のブール値に自動的に解析しなくなりました。空でない文字列は true とみなされます。``CONDITIONAL_BARE_VARS`` 設定変数は効果がなくなりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:474 -msgid "hostname - Drops any remaining support for Python 2.4 by using ``with open()`` to simplify exception handling code which leaked file handles in several spots" -msgstr "hostname - ``with open()`` を使用して、複数のスポットでファイルハンドルをリークした例外処理コードを簡素化することで、Python 2.4 の残りのサポートが廃止されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:475 -msgid "hostname - On FreeBSD, the string ``temporarystub`` no longer gets written to the hostname file in the get methods (and in check_mode). As a result, the default hostname will now appear as ``''`` (empty string) instead of ``temporarystub`` for consistency with other strategies. This means the ``before`` result will be different." -msgstr "hostname - FreeBSD では、文字列 ``temporarystub`` は get メソッド（および check_mode）のホスト名ファイルに書き込まれなくなりました。その結果、他のストラテジーとの整合性を保つために、デフォルトのホスト名は ``temporarystub`` ではなく``''``（空の文字列）として表示されるようになりました。つまり、``before`` の結果は異なります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:476 -msgid "hostname - On OpenRC systems and Solaris, the ``before`` value will now be ``''`` (empty string) if the permanent hostname file does not exist, for consistency with other strategies." -msgstr "hostname - OpenRC システムおよび Solaris では、他のストラテジーとの整合性を保つため、永続的なホスト名ファイルが存在しない場合に、``before`` の値が ``''``（空の文字列）になりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:477 -msgid "intersect, difference, symmetric_difference, union filters - the default behavior is now to be case-sensitive (https://github.com/ansible/ansible/issues/74255)" -msgstr "intersect、difference、symmetric_difference、union フィルター： デフォルトの動作では、大文字と小文字が区別されるようになりました（https://github.com/ansible/ansible/issues/74255）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:478 -msgid "unique filter - the default behavior is now to fail if Jinja2's filter fails and explicit ``case_sensitive=False`` as the Ansible's fallback is case-sensitive (https://github.com/ansible/ansible/pull/74256)" -msgstr "unique filter - Ansible のフォールバックでは大文字と小文字が区別されるので、Jinja2 のフィルターが失敗し、明示的に``case_sensitive=False``が設定されている場合、デフォルトの動作では失敗するようになりました（https://github.com/ansible/ansible/pull/74256）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:483 -msgid "ec2_instance - instance wait for state behaviour has changed. If plays require the old behavior of waiting for the instance monitoring status to become ``OK`` when launching a new instance, the action will need to specify ``state: started`` (https://github.com/ansible-collections/amazon.aws/pull/481)." -msgstr "ec2_instance - インスタンスは状態の動作が変更されるのを待ちます。新規インスタンスを起動する際に、プレイでインスタンスの監視ステータスが ``OK`` になるのを待機する以前の動作が必要な場合は、アクションで``state: started`` を指定する必要があります（https://github.com/ansible-collections/amazon.aws/pull/481）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:484 -msgid "ec2_snapshot - support for waiting indefinitely has been dropped, new default is 10 minutes (https://github.com/ansible-collections/amazon.aws/pull/356)." -msgstr "ec2_snapshot - 無制限に待機するサポートが廃止されました。新しいデフォルトは 10 分です（https://github.com/ansible-collections/amazon.aws/pull/356）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:485 -msgid "ec2_vol_info - return ``attachment_set`` is now a list of attachments with Multi-Attach support on disk. (https://github.com/ansible-collections/amazon.aws/pull/362)." -msgstr "ec2_vol_info - 戻り値``attachment_set``は、ディスク上でマルチアタッチをサポートするアタッチメントのリストになりました（https://github.com/ansible-collections/amazon.aws/pull/362）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:486 -msgid "ec2_vpc_dhcp_option - The module has been refactored to use boto3. Keys and value types returned by the module are now consistent, which is a change from the previous behaviour. A ``purge_tags`` option has been added, which defaults to ``True``. (https://github.com/ansible-collections/amazon.aws/pull/252)" -msgstr "ec2_vpc_dhcp_option - モジュールは、boto3 を使用するようにリファクタリングされました。モジュールが返すキーと値の型の一貫性が維持されるようになりました。これは以前の動作からの変更です。``purge_tags`` オプションが追加されました。デフォルトは ``True`` です（https://github.com/ansible-collections/amazon.aws/pull/252）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:487 -msgid "ec2_vpc_dhcp_option_info - Now preserves case for tag keys in return value. (https://github.com/ansible-collections/amazon.aws/pull/252)" -msgstr "ec2_vpc_dhcp_option_info - 戻り値のタグキーについて大文字小文字を保持するようになりました（https://github.com/ansible-collections/amazon.aws/pull/252）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:488 -msgid "module_utils.core - The boto3 switch has been removed from the region parameter (https://github.com/ansible-collections/amazon.aws/pull/287)." -msgstr "module_utils.core - boto3 スイッチが region パラメーターから削除されました（https://github.com/ansible-collections/amazon.aws/pull/287）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:489 -msgid "module_utils/compat - vendored copy of ipaddress removed (https://github.com/ansible-collections/amazon.aws/pull/461)." -msgstr "module_utils/compat - ipaddress のベンダーコピーが削除されました（https://github.com/ansible-collections/amazon.aws/pull/461）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:490 -msgid "module_utils/core - updated the ``scrub_none_parameters`` function so that ``descend_into_lists`` is set to ``True`` by default (https://github.com/ansible-collections/amazon.aws/pull/297)." -msgstr "module_utils/core - ``descend_into_lists`` がデフォルトで ``True`` に設定されるように ``scrub_none_parameters`` 関数が更新されました（https://github.com/ansible-collections/amazon.aws/pull/297）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:495 -msgid "Arista released train 4.23.X and newer and along with it replaced and deprecated lots of commands. This PR adds support for syntax changes in release train 4.23 and after. Going forward the eos modules will not support eos sw version < 4.23." -msgstr "Arista は train4.23.X 以降をリリースし、それに伴い多くのコマンドが置き換えまたは非推奨になりました。この PR は、リリース train 4.23 以降での構文変更のサポートを追加します。今後、eos モジュールは 4.23より前のバージョンのeos sw をサポートしなくなります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:500 -msgid "ec2_instance - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``." -msgstr "ec2_instance - モジュールは ``amazon.aws`` コレクションに移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_instance`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:501 -msgid "ec2_instance_info - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``." -msgstr "ec2_instance_info - モジュールは ``amazon.aws`` コレクションに移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_instance_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:502 -#: ../../rst/porting_guides/porting_guide_5.rst:624 -msgid "ec2_vpc_endpoint - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint``." -msgstr "ec2_vpc_endpoint - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_endpoint`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:503 -#: ../../rst/porting_guides/porting_guide_5.rst:625 -msgid "ec2_vpc_endpoint_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``." -msgstr "ec2_vpc_endpoint_facts - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_endpoint_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:504 -#: ../../rst/porting_guides/porting_guide_5.rst:626 -msgid "ec2_vpc_endpoint_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``." -msgstr "ec2_vpc_endpoint_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_endpoint_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:505 -#: ../../rst/porting_guides/porting_guide_5.rst:627 -msgid "ec2_vpc_endpoint_service_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_service_info``." -msgstr "ec2_vpc_endpoint_service_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_endpoint_service_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:506 -#: ../../rst/porting_guides/porting_guide_5.rst:628 -msgid "ec2_vpc_igw - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw``." -msgstr "ec2_vpc_igw - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_igw`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:507 -msgid "ec2_vpc_igw_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``." -msgstr "ec2_vpc_igw_facts - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_igw_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:508 -#: ../../rst/porting_guides/porting_guide_5.rst:630 -msgid "ec2_vpc_igw_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``." -msgstr "ec2_vpc_igw_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_igw_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:509 -#: ../../rst/porting_guides/porting_guide_5.rst:631 -msgid "ec2_vpc_nat_gateway - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway``." -msgstr "ec2_vpc_nat_gateway - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_nat_gateway`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:510 -#: ../../rst/porting_guides/porting_guide_5.rst:632 -msgid "ec2_vpc_nat_gateway_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``." -msgstr "ec2_vpc_nat_gateway_facts - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_nat_gateway_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:511 -#: ../../rst/porting_guides/porting_guide_5.rst:633 -msgid "ec2_vpc_nat_gateway_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``." -msgstr "ec2_vpc_nat_gateway_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_nat_gateway_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:512 -msgid "kms_info - key details are now returned in the ``kms_keys`` attribute rather than the ``keys`` attribute (https://github.com/ansible-collections/community.aws/pull/648)." -msgstr "kms_info - キーの詳細が ``keys`` 属性ではなく ``kms_keys`` 属性で返されるようになりました（https://github.com/ansible-collections/community.aws/pull/648）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:517 -msgid "Adjust ``dirName`` text parsing and to text converting code to conform to `Sections 2 and 3 of RFC 4514 `_. This is similar to how `cryptography handles this `_ (https://github.com/ansible-collections/community.crypto/pull/274)." -msgstr "``dirName`` テキスト解析およびテキスト変換コードを、`Sections 2 and 3 of RFC 4514 `_ に準拠するよう調整します。これは、`cryptography handles this `_ 仕組みと似ています（https://github.com/ansible-collections/community.crypto/pull/274）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:518 -msgid "acme module utils - removing compatibility code (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "acme モジュールユーティリティー - 互換性コードを削除します（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:519 -msgid "acme_* modules - removed vendored copy of the Python library ``ipaddress``. If you are using Python 2.x, please make sure to install the library (https://github.com/ansible-collections/community.crypto/pull/287)." -msgstr "acme_* モジュール - Python ライブラリー ``ipaddress`` のベンダーコピーが削除されました。Python 2.x を使用している場合は、必ずライブラリーをインストールしてください（https://github.com/ansible-collections/community.crypto/pull/287）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:520 -msgid "compatibility module_utils - removed vendored copy of the Python library ``ipaddress`` (https://github.com/ansible-collections/community.crypto/pull/287)." -msgstr "互換性module_utils - Python ライブラリー ``ipaddress`` のベンダーコピーが削除されました（https://github.com/ansible-collections/community.crypto/pull/287）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:521 -msgid "crypto module utils - removing compatibility code (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "暗号モジュールユーティリティー - 互換性コードを削除します（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:522 -msgid "get_certificate, openssl_csr_info, x509_certificate_info - depending on the ``cryptography`` version used, the modules might not return the ASN.1 value for an extension as contained in the certificate respectively CSR, but a re-encoded version of it. This should usually be identical to the value contained in the source file, unless the value was malformed. For extensions not handled by C(cryptography) the value contained in the source file is always returned unaltered (https://github.com/ansible-collections/community.crypto/pull/318)." -msgstr "get_certificate、openssl_csr_info、x509_certificate_info - 使用される ``cryptography`` バージョンによっては、モジュールが証明書の各CSRに含まれた拡張の ASN.1 値を返さずに、その再エンコードされたバージョンを返す場合があります。値が不正でない限り、通常これはソースファイルに含まれている値と同一でなければなりません。C(cryptography)で処理されない拡張の場合、ソースファイルに含まれる値は常に変更されずに返されます（https://github.com/ansible-collections/community.crypto/pull/318）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:523 -msgid "module_utils - removed various PyOpenSSL support functions and default backend values that are not needed for the openssl_pkcs12 module (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "module_utils - openssl_pkcs12 モジュールに必要のないさまざまな PyOpenSSL サポート関数およびデフォルトのバックエンド値が削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:524 -msgid "openssl_csr, openssl_csr_pipe, x509_crl - the ``subject`` respectively ``issuer`` fields no longer ignore empty values, but instead fail when encountering them (https://github.com/ansible-collections/community.crypto/pull/316)." -msgstr "openssl_csr、openssl_csr_pipe、x509_crl - ``subject`` のそれぞれの ``issuer`` フィールドは、空の値を無視せず、その場合は失敗するようになりました（https://github.com/ansible-collections/community.crypto/pull/316）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:525 -msgid "openssl_privatekey_info - by default consistency checks are not run; they need to be explicitly requested by passing ``check_consistency=true`` (https://github.com/ansible-collections/community.crypto/pull/309)." -msgstr "openssl_privatekey_info - デフォルトでは整合性チェックは実行されず、``check_consistency=true`` を渡して明示的に要求する必要があります（https://github.com/ansible-collections/community.crypto/pull/309）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:526 -msgid "x509_crl - for idempotency checks, the ``issuer`` order is ignored. If order is important, use the new ``issuer_ordered`` option (https://github.com/ansible-collections/community.crypto/pull/316)." -msgstr "x509_crl - 冪等性チェックの場合、``issuer`` の順序は無視されます。順序が重要な場合は、新しい ``issuer_ordered`` オプションを使用してください（https://github.com/ansible-collections/community.crypto/pull/316）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:529 -#: ../../rst/porting_guides/porting_guide_5.rst:701 -#: ../../rst/porting_guides/porting_guide_5.rst:957 -#: ../../rst/porting_guides/porting_guide_7.rst:171 -msgid "community.dns" -msgstr "community.dns" - -#: ../../rst/porting_guides/porting_guide_5.rst:531 -msgid "All Hetzner modules and plugins which handle DNS records now work with unquoted TXT values by default. The old behavior can be obtained by setting ``txt_transformation=api`` (https://github.com/ansible-collections/community.dns/issues/48, https://github.com/ansible-collections/community.dns/pull/57, https://github.com/ansible-collections/community.dns/pull/60)." -msgstr "DNS レコードを処理するすべての Hetzner モジュールおよびプラグインは、デフォルトで引用符で囲まれていない TXT 値で動作するようになりました。以前の動作は、``txt_transformation=api`` を設定して得られます（https://github.com/ansible-collections/community.dns/issues/48、https://github.com/ansible-collections/community.dns/pull/57、https://github.com/ansible-collections/community.dns/pull/60）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:532 -msgid "Hosttech API creation - now requires a ``ModuleOptionProvider`` object instead of an ``AnsibleModule`` object. Alternatively an Ansible plugin instance can be passed (https://github.com/ansible-collections/community.dns/pull/37)." -msgstr "Hosttech API 作成 - ``AnsibleModule`` オブジェクトではなく ``ModuleOptionProvider`` オブジェクトを必要とするようになりました。あるいは、Ansible プラグインインスタンスを渡すことができます（https://github.com/ansible-collections/community.dns/pull/37）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:533 -msgid "The hetzner_dns_record_info and hosttech_dns_record_info modules have been renamed to hetzner_dns_record_set_info and hosttech_dns_record_set_info, respectively (https://github.com/ansible-collections/community.dns/pull/54)." -msgstr "hetzner_dns_record_info モジュールおよび hosttech_dns_record_info モジュールの名前が、それぞれ hetzner_dns_record_set_info と hosttech_dns_record_set_info に変更されました（https://github.com/ansible-collections/community.dns/pull/54）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:534 -msgid "The hosttech_dns_record module has been renamed to hosttech_dns_record_set (https://github.com/ansible-collections/community.dns/pull/31)." -msgstr "hosttech_dns_record モジュールの名前が hosttech_dns_record_set に変更されました（https://github.com/ansible-collections/community.dns/pull/31）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:535 -msgid "The internal bulk record updating helper (``bulk_apply_changes``) now also returns the records that were deleted, created or updated (https://github.com/ansible-collections/community.dns/pull/63)." -msgstr "内部の一括レコード更新ヘルパー(``bulk_apply_changes``)も、削除、作成、または更新されたレコードを返すようになりました（https://github.com/ansible-collections/community.dns/pull/63）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:536 -msgid "The internal record API no longer allows to manage comments explicitly (https://github.com/ansible-collections/community.dns/pull/63)." -msgstr "内部レコード API ではコメントを明示的に管理できなくなりました（https://github.com/ansible-collections/community.dns/pull/63）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:537 -msgid "When using the internal modules API, now a zone ID type and a provider information object must be passed (https://github.com/ansible-collections/community.dns/pull/27)." -msgstr "内部モジュール API を使用する場合、ゾーン ID タイプおよびプロバイダー情報オブジェクトを渡す必要があります（https://github.com/ansible-collections/community.dns/pull/27）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:538 -msgid "hetzner_dns_record* modules - implement correct handling of default TTL. The value ``none`` is now accepted and returned in this case (https://github.com/ansible-collections/community.dns/pull/52, https://github.com/ansible-collections/community.dns/issues/50)." -msgstr "hetzner_dns_record* モジュール - デフォルトの TTL の正しい処理を実装します。この場合、``none`` の値が許可され返されます（https://github.com/ansible-collections/community.dns/pull/52、https://github.com/ansible-collections/community.dns/issues/50）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:539 -msgid "hetzner_dns_record, hetzner_dns_record_set, hetzner_dns_record_sets - the default TTL is now 300 and no longer 3600, which equals the default in the web console (https://github.com/ansible-collections/community.dns/pull/43)." -msgstr "hetzner_dns_record、hetzner_dns_record_set、hetzner_dns_record_sets - デフォルトの TTL は 3600 ではなく 300 になり、Web コンソールのデフォルトと同じになりました（https://github.com/ansible-collections/community.dns/pull/43）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:540 -msgid "hosttech_* module_utils - completely rewrite and refactor to support new JSON API and allow to re-use provider-independent module logic (https://github.com/ansible-collections/community.dns/pull/4)." -msgstr "hosttech_* module_utils - 新しい JSON API をサポートするように完全に書き換え、リファクタリングされ、プロバイダーに依存しないモジュールロジックを再利用できます（https://github.com/ansible-collections/community.dns/pull/4）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:541 -msgid "hosttech_dns_record_set - the option ``overwrite`` was replaced by a new option ``on_existing``. Specifying ``overwrite=true`` is equivalent to ``on_existing=replace`` (the new default). Specifying ``overwrite=false`` with ``state=present`` is equivalent to ``on_existing=keep_and_fail``, and specifying ``overwrite=false`` with ``state=absent`` is equivalent to ``on_existing=keep`` (https://github.com/ansible-collections/community.dns/pull/31)." -msgstr "hosttech_dns_record_set - オプション ``overwrite`` は新しいオプション ``on_existing`` に置き換えられました。``overwrite=true`` の指定は ``on_existing=replace``（新しいデフォルト）と同等です。``state=present`` と共に ``overwrite=false`` を指定することは ``on_existing=keep_and_fail`` と同等で、``state=absent`` と共に ``overwrite=false`` を指定することは ``on_existing=keep`` と同じです（https://github.com/ansible-collections/community.dns/pull/31）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:546 -msgid "docker_compose - fixed ``timeout`` defaulting behavior so that ``stop_grace_period``, if defined in the compose file, will be used if `timeout`` is not specified (https://github.com/ansible-collections/community.docker/pull/163)." -msgstr "docker_compose - ``timeout`` のデフォルトの動作が修正され、compose ファイルで定義された場合に `timeout` が指定されていない場合に``stop_grace_period``が使用されるようになりました（https://github.com/ansible-collections/community.docker/pull/163）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:551 -msgid "archive - adding idempotency checks for changes to file names and content within the ``destination`` file (https://github.com/ansible-collections/community.general/pull/3075)." -msgstr "アーカイブ - ``destination``ファイル内のファイル名と内容の変更に対する冪等性チェックが追加されました (https://github.com/ansible-collections/community.general/pull/3075）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:552 -msgid "lxd inventory plugin - when used with Python 2, the plugin now needs ``ipaddress`` installed `from pypi `_ (https://github.com/ansible-collections/community.general/pull/2441)." -msgstr "lxd インベントリープラグイン - Python 2 で使用した場合に、プラグインに `from pypi `_ ``ipaddress``をインストールする必要があります（https://github.com/ansible-collections/community.general/pull/2441）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:553 -msgid "scaleway_security_group_rule - when used with Python 2, the module now needs ``ipaddress`` installed `from pypi `_ (https://github.com/ansible-collections/community.general/pull/2441)." -msgstr "scaleway_security_group_rule - Python 2 で使用した場合に、モジュールに `from pypi `_ ``ipaddress``をインストールする必要があります（https://github.com/ansible-collections/community.general/pull/2441）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:558 -msgid "connection options - there is no longer a default value for the ``url`` option (the Vault address), so a value must be supplied (https://github.com/ansible-collections/community.hashi_vault/issues/83)." -msgstr "接続オプション - ``url`` オプション（Vault アドレス）のデフォルト値がなくなったため、値を指定する必要があります（https://github.com/ansible-collections/community.hashi_vault/issues/83）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:563 -msgid "drop python 2 support (https://github.com/openshift/community.okd/pull/93)." -msgstr "Python 2 サポートが廃止されました (https://github.com/openshift/community.okd/pull/93)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:566 -#: ../../rst/porting_guides/porting_guide_6.rst:109 -#: ../../rst/porting_guides/porting_guide_6.rst:166 -#: ../../rst/porting_guides/porting_guide_7.rst:226 -#: ../../rst/porting_guides/porting_guide_7.rst:281 -msgid "community.routeros" -msgstr "community.routeros" - -#: ../../rst/porting_guides/porting_guide_5.rst:568 -msgid "api - due to a programming error, the module never failed on errors. This has now been fixed. If you are relying on the module not failing in case of idempotent commands (resulting in errors like ``failure: already have such address``), you need to adjust your roles/playbooks. We suggest to use ``failed_when`` to accept failure in specific circumstances, for example ``failed_when: \"'failure: already have ' in result.msg[0]\"`` (https://github.com/ansible-collections/community.routeros/pull/39)." -msgstr "api - プログラミングエラーにより、エラー時にモジュールが失敗しませんでした。現在これは修正されています。もし、idempotent コマンドの場合にモジュールが失敗しないことに依存している場合 (``failure: already have such address``のようなエラーが発生する)、ロール/プレイブックを調整する必要があります。``failed_when: \"'failure: already have ' in result.msg[0]\"``のように、``failed_when``を使用して特定の状況下で失敗を受け入れることを提案します(https://github.com/ansible-collections/community.routeros/pull/39）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:569 -msgid "api - splitting commands no longer uses a naive split by whitespace, but a more RouterOS CLI compatible splitting algorithm (https://github.com/ansible-collections/community.routeros/pull/45)." -msgstr "api - 分割コマンドは、スペースによるシンプルな分割ではなく、より RouterOS CLI と互換性のある分割アルゴリズムをしようするようになりました（https://github.com/ansible-collections/community.routeros/pull/45）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:570 -msgid "command - the module now always indicates that a change happens. If this is not correct, please use ``changed_when`` to determine the correct changed status for a task (https://github.com/ansible-collections/community.routeros/pull/50)." -msgstr "command - モジュールは、変更が発生したことを常に示すようになりました。これが正しくない場合は、``changed_when`` を使用してタスクの正しい変更されたステータスを判断してください（https://github.com/ansible-collections/community.routeros/pull/50）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:575 -msgid "all roles now reference other roles and modules through their fully qualified collection names, which makes Ansible 2.10 minimum supported version for roles (See `issue 477 `_)." -msgstr "すべてのロールは、完全修飾コレクション名で他のロールおよびモジュールを参照するようになりました。これにより、ロールのAnsible 2.10 最低サポートバージョンを作成します (`issue 477 `_ を参照してください)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:580 -msgid "Drop python 2 support (https://github.com/ansible-collections/kubernetes.core/pull/86)." -msgstr "Python 2 サポートが廃止されました（https://github.com/ansible-collections/kubernetes.core/pull/86）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:581 -msgid "helm_plugin - remove unused ``release_namespace`` parameter (https://github.com/ansible-collections/kubernetes.core/pull/85)." -msgstr "helm_plugin - 使用されない ``release_namespace`` パラメーターが削除されました（https://github.com/ansible-collections/kubernetes.core/pull/85）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:582 -msgid "helm_plugin_info - remove unused ``release_namespace`` parameter (https://github.com/ansible-collections/kubernetes.core/pull/85)." -msgstr "helm_plugin_info - 使用されない ``release_namespace`` パラメーターが削除されました（https://github.com/ansible-collections/kubernetes.core/pull/85）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:583 -msgid "k8s_cluster_info - returned apis as list to avoid being overwritten in case of multiple version (https://github.com/ansible-collections/kubernetes.core/pull/41)." -msgstr "k8s_cluster_info - 複数バージョンの場合に上書きされないように apis を一覧として返しました（https://github.com/ansible-collections/kubernetes.core/pull/41）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:584 -msgid "k8s_facts - remove the deprecated alias from k8s_facts to k8s_info (https://github.com/ansible-collections/kubernetes.core/pull/125)." -msgstr "k8s_facts - k8s_facts から k8s_infoへの非推奨のエイリアスが削除されました（https://github.com/ansible-collections/kubernetes.core/pull/125）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:587 -msgid "netapp.storagegrid" -msgstr "netapp.storagegrid" - -#: ../../rst/porting_guides/porting_guide_5.rst:589 -msgid "This version introduces a breaking change. All modules have been renamed from ``nac_sg_*`` to ``na_sg_*``. Playbooks and Roles must be updated to match." -msgstr "このバージョンでは、重大な変更が導入されています。すべてのモジュールの名前が ``nac_sg_*`` から ``na_sg_*`` に変更されました。それに合わせてPlaybook とロールを更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:599 -msgid "Python Controller Requirement - Python 3.8 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/74013)" -msgstr "Python コントローラーの要件 - コントロールノード（Ansible を実行するマシン）には Python 3.8 以降が必要です（https://github.com/ansible/ansible/pull/74013）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:600 -msgid "ansible-test - All \"cloud\" plugins which use containers can now be used with all POSIX and Windows hosts. Previously the plugins did not work with Windows at all, and support for hosts created with the ``--remote`` option was inconsistent." -msgstr "ansible-test - コンテナーを使用するすべての「クラウド」プラグインが、すべての POSIX および Windows ホストで使用できるようになりました。これまでは、プラグインは Windows ではまったく機能せず、``--remote`` オプションで作成されたホストに対するサポートに一貫性がありませんでした。" - -#: ../../rst/porting_guides/porting_guide_5.rst:601 -msgid "ansible-test - Collections can now specify controller and target specific integration test requirements and constraints. If provided, they take precedence over the previously available requirements and constraints files." -msgstr "ansible-test - コレクションで、コントローラーおよびターゲット固有のインテグレーションテスト要件と制約を指定できるようになりました。指定されている場合は、以前に利用可能だった要件と制約のファイルよりも優先されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:602 -msgid "ansible-test - Integration tests run with the ``integration`` command can now be executed on two separate hosts instead of always running on the controller. The target host can be one provided by ``ansible-test`` or by the user, as long as it is accessible using SSH." -msgstr "ansible-test - ``integration`` コマンドで実行されるインテグレーションテストは、常にコントローラーで実行されるのではなく、2 つの別個のホストで実行できるようになりました。SSH でアクセス可能であれば、ターゲットホストは``ansible-test`` またはユーザーが指定するホストに設定できます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:603 -msgid "ansible-test - Most container features are now supported under Podman. Previously a symbolic link for ``docker`` pointing to ``podman`` was required." -msgstr "ansible-test - ほとんどのコンテナー機能は Podman でサポートされるようになりました。以前のバージョンでは、``podman`` をポイントする ``docker`` のシンボリックリンクが必要でした。" - -#: ../../rst/porting_guides/porting_guide_5.rst:604 -msgid "ansible-test - New ``--controller`` and ``--target`` / ``--target-python`` options have been added to allow more control over test environments." -msgstr "ansible-test - テスト環境をより制御できるように、新しい ``--controller`` および ``--target`` / ``--target-python`` オプションが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:605 -msgid "ansible-test - Python 3.8 - 3.10 are now required to run ``ansible-test``, thus matching the Ansible controller Python requirements. Older Python versions (2.6 - 2.7 and 3.5 - 3.10) can still be the target for relevant tests." -msgstr "ansible-test - Python 3.8 - 3.10 は ``ansible-test`` の実行に必要なため、Ansible コントローラーの Python 要件に一致します。以前の Python バージョン（2.6 - 2.7 および 3.5 - 3.10）は、引き続き関連するテストのターゲットにすることができます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:606 -msgid "ansible-test - SSH port forwarding and redirection is now used exclusively to make container ports available on non-container hosts. When testing on POSIX systems this requires SSH login as root. Previously SSH port forwarding was combined with firewall rules or other port redirection methods, with some platforms being unsupported." -msgstr "ansible-test - SSH ポート転送およびリダイレクトを、コンテナーポートを非コンテナーホストで利用可能にするためだけに使用できるようになりました。POSIX システムでテストする場合は、root としての SSH ログインが必要になります。これまでは SSH ポート転送はファイアウォールルールや他のポートリダイレクト方法と組み合わされ、一部のプラットフォームはサポートされませんでした。" - -#: ../../rst/porting_guides/porting_guide_5.rst:607 -msgid "ansible-test - Sanity tests always run in isolated Python virtual environments specific to the requirements of each test. The environments are cached." -msgstr "ansible-test - 健全性テストは常に、各テストの要件に固有の分離された Python 仮想環境で実行されます。環境はキャッシュされます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:608 -msgid "ansible-test - Sanity tests are now separated into two categories, controller and target. All tests except ``import`` and ``compile`` are controller tests. The controller tests always run using the same Python version used to run ``ansible-test``. The target tests use the Python version(s) specified by the user, or all available Python versions." -msgstr "ansible-test - 健全性テストがコントローラーとターゲットの 2 つのカテゴリに分けられるようになりました。``import``と``compile``以外のテストはすべてコントローラーのテストです。コントローラーテストは常に``ansible-test``を実行するために使われたものと同じ Python のバージョンを使って実行されます。ターゲットテストは、ユーザーが指定した Python のバージョン、または利用可能なすべての Python のバージョンを使用します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:609 -msgid "ansible-test - Sanity tests now use fully pinned requirements that are independent of each other and other test types." -msgstr "ansible-test - 健全性テストでは、互いに、また他のテストタイプから独立した、完全に固定された要件を使用するようになりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:611 -msgid "ansible-test - The ``future-import-boilerplate`` and ``metaclass-boilerplate`` sanity tests are limited to remote-only code. Additionally, they are skipped for collections which declare no support for Python 2.x." -msgstr "ansible-test - ``future-import-boilerplate`` および ``metaclass-boilerplate`` 健全性テストは、リモートのみのコードに制限されます。さらに、Python 2.x のサポートを宣言しないコレクションについては省略されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:612 -msgid "ansible-test - The ``import`` and ``compile`` sanity tests limit remote-only Python version checks to remote-only code." -msgstr "ansible-test - ``import`` および ``compile`` の健全性テストは、リモートのみの Python バージョンチェックをリモートのみのコードに制限します。" - -#: ../../rst/porting_guides/porting_guide_5.rst:613 -msgid "ansible-test - Unit tests for controller-only code now require Python 3.8 or later." -msgstr "ansible-test - コントローラーのみのコードのユニットテストは Python 3.8 以降を必要とするようになりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:614 -msgid "ansible-test - Version neutral sanity tests now require Python 3.8 or later." -msgstr "ansible-test - バージョンに依存しない健全性テストは Python 3.8 以降を必要とするようになりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:615 -msgid "junit callback - The ``junit_xml`` and ``ordereddict`` Python modules are no longer required to use the ``junit`` callback plugin." -msgstr "junit コールバック - ``junit_xml`` および ``ordereddict`` Python モジュールは、``junit`` コールバックプラグインを使用するのに必要なくなりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:620 -msgid "amazon.aws collection - Due to the AWS SDKs announcing the end of support for Python less than 3.6 (https://boto3.amazonaws.com/v1/documentation/api/1.17.64/guide/migrationpy3.html) this collection now requires Python 3.6+ (https://github.com/ansible-collections/amazon.aws/pull/298)." -msgstr "amazon.aws コレクション - Python 3.6 未満のサポート終了を通知するAWS SDK (https://boto3.amazonaws.com/v1/documentation/api/1.17.64/guide/migrationpy3.html)により、このコレクションは、Python 3.6+ を必要とするようになりました(https://github.com/ansible-collections/amazon.aws/pull/298)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:621 -msgid "amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/502)." -msgstr "amazon.aws コレクション - amazon.aws コレクションでは ``botocore<1.18.0`` および ``boto3<1.15.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。古いバージョンの SDK を使用する場合は、Ansible によって警告が出力されます（https://github.com/ansible-collections/amazon.aws/pull/502）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:622 -msgid "ec2_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``." -msgstr "ec2_instance - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.ec2_instance`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:623 -msgid "ec2_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``." -msgstr "ec2_instance_info - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.ec2_instance_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:629 -msgid "ec2_vpc_igw_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_facts``." -msgstr "ec2_vpc_igw_facts - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_igw_facts`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:634 -#: ../../rst/porting_guides/porting_guide_7.rst:377 -msgid "ec2_vpc_route_table - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table``." -msgstr "ec2_vpc_route_table - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_route_table`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:635 -msgid "ec2_vpc_route_table_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_facts``." -msgstr "ec2_vpc_route_table_facts - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_route_table_facts`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:636 -#: ../../rst/porting_guides/porting_guide_7.rst:378 -msgid "ec2_vpc_route_table_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_info``." -msgstr "ec2_vpc_route_table_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_vpc_route_table_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_5.rst:639 -#: ../../rst/porting_guides/porting_guide_6.rst:620 -msgid "cisco.ise" -msgstr "cisco.ise" - -#: ../../rst/porting_guides/porting_guide_5.rst:641 -msgid "Adds ``ise_uses_api_gateway`` to module options." -msgstr "モジュールオプションに ``ise_uses_api_gateway`` が追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:642 -msgid "Adds a 'aws_deployment' role that allows the deployment of an arbitrary large ISE cluster to AWS." -msgstr "任意の大きな ISE クラスターを AWS にデプロイメントできる 'aws_deployment' ロールが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:643 -msgid "Adds ise_responses to return values of info modules." -msgstr "info モジュールの値を返すise_responses が追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:644 -msgid "Adds ise_update_response to return values of non-info modules." -msgstr "info 以外のモジュールの値を返すise_update_response が追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:645 -msgid "Fixes inner logic of modules that have no get by name and have not working filter." -msgstr "get by nameフィルターおよび機能するフィルターを持たないモジュールの内部ロジックが修正されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:646 -msgid "Renamed module device_administration_authorization_exception_rules to device_administration_local_exception_rules." -msgstr "モジュール device_administration_authorization_exception_rules の名前が device_administration_local_exception_rules に変更されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:647 -msgid "Renamed module device_administration_authorization_global_exception_rules to device_administration_global_exception_rules." -msgstr "モジュール device_administration_authorization_global_exception_rules の名前が device_administration_global_exception_rules に変更されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:648 -msgid "Renamed module network_access_authorization_exception_rules to network_access_local_exception_rules." -msgstr "モジュール network_access_authorization_exception_rules の名前が network_access_local_exception_rules に変更されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:649 -msgid "Renamed module network_access_authorization_global_exception_rules to network_access_global_exception_rules." -msgstr "モジュール network_access_authorization_global_exception_rules の名前が network_access_global_exception_rules に変更されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:650 -msgid "Updates options required for modules." -msgstr "モジュールに必要なオプションが更新されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:651 -msgid "Updates sdk parameters for previous modules" -msgstr "以前のモジュールの sdk パラメーターが更新されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:652 -msgid "device_administration_authorization_exception_rules - removed module." -msgstr "device_administration_authorization_exception_rules - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:653 -msgid "device_administration_authorization_exception_rules_info - removed module." -msgstr "device_administration_authorization_exception_rules_info - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:654 -msgid "device_administration_authorization_global_exception_rules - removed module." -msgstr "device_administration_authorization_global_exception_rules - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:655 -msgid "device_administration_authorization_global_exception_rules_info - removed module." -msgstr "device_administration_authorization_global_exception_rules_info - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:656 -msgid "guest_user_reinstante - removed module." -msgstr "guest_user_reinstante - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:657 -msgid "import_trust_cert - removed module." -msgstr "import_trust_cert - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:658 -msgid "network_access_authorization_exception_rules - removed module." -msgstr "network_access_authorization_exception_rules - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:659 -msgid "network_access_authorization_exception_rules_info - removed module." -msgstr "network_access_authorization_exception_rules_info - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:660 -msgid "network_access_authorization_global_exception_rules - removed module." -msgstr "network_access_authorization_global_exception_rules - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:661 -msgid "network_access_authorization_global_exception_rules_info - removed module." -msgstr "network_access_authorization_global_exception_rules_info - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:662 -msgid "personas_check_standalone - Adds module for the deployment of personas to existing nodes in an ISE cluster." -msgstr "personas_check_standalone - ISE クラスターの既存ノードに personas をデプロイするモジュールが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:663 -msgid "personas_export_certs - Adds module for the deployment of personas to existing nodes in an ISE cluster." -msgstr "personas_export_certs - ISE クラスターの既存ノードに personas をデプロイするモジュールが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:664 -msgid "personas_promote_primary - Adds module for the deployment of personas to existing nodes in an ISE cluster." -msgstr "personas_promote_primary - ISE クラスターの既存ノードに personas をデプロイするモジュールが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:665 -msgid "personas_update_roles - Adds module for the deployment of personas to existing nodes in an ISE cluster." -msgstr "personas_update_roles - ISE クラスターの既存ノードに personas をデプロイするモジュールが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:666 -msgid "service_info - removed module." -msgstr "service_info - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:667 -msgid "system_certificate_export - removed module." -msgstr "system_certificate_export - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:668 -msgid "telemetry_info_info - removed module." -msgstr "telemetry_info_info - モジュールが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:671 -msgid "cloud.common" -msgstr "cloud.common" - -#: ../../rst/porting_guides/porting_guide_5.rst:673 -msgid "turbo - enable turbo mode for lookup plugins" -msgstr "turbo - lookup プラグインの turbo モードを有効にします。" - -#: ../../rst/porting_guides/porting_guide_5.rst:683 -msgid "community.aws collection - The community.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0`` (https://github.com/ansible-collections/community.aws/pull/711). Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/442)." -msgstr "community.aws コレクション - community.aws コレクションでは ``botocore<1.18.0`` および ``boto3<1.15.0`` のサポートを廃止しました (https://github.com/ansible-collections/community.aws/pull/711)。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。SDK の古いバージョンを使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/amazon.aws/pull/442)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:686 -msgid "community.ciscosmb" -msgstr "community.ciscosmb" - -#: ../../rst/porting_guides/porting_guide_5.rst:688 -msgid "Python 2.6, 2.7, 3.5 is required" -msgstr "Python 2.6、2.7、3.5 が必要です" - -#: ../../rst/porting_guides/porting_guide_5.rst:689 -msgid "add CBS350 support" -msgstr "CBS350 サポートの追加" - -#: ../../rst/porting_guides/porting_guide_5.rst:690 -msgid "add antsibull-changelog support" -msgstr "antsibull-changelog サポートの追加" - -#: ../../rst/porting_guides/porting_guide_5.rst:691 -msgid "add ciscosmb_command" -msgstr "ciscosmb_command の追加" - -#: ../../rst/porting_guides/porting_guide_5.rst:692 -msgid "added facts subset \"interfaces\"" -msgstr "ファクトサブセット「interfaces」の追加" - -#: ../../rst/porting_guides/porting_guide_5.rst:693 -msgid "ciscosmb_facts with default subset and unit tests" -msgstr "ciscosmb_facts（デフォルトサブセットおよびユニットテストあり）" - -#: ../../rst/porting_guides/porting_guide_5.rst:694 -msgid "interface name canonicalization" -msgstr "インターフェース名の正規化" - -#: ../../rst/porting_guides/porting_guide_5.rst:695 -msgid "transform collection qaxi.ciscosmb to community.ciscosmb" -msgstr "コレクション qaxi.ciscosmb の community.ciscosmb への変換" - -#: ../../rst/porting_guides/porting_guide_5.rst:696 -msgid "transform community.ciscosmb.ciscosmb_command to community.ciscosmb.command" -msgstr "community.ciscosmb.ciscosmb_command の community.ciscosmb.command への変換" - -#: ../../rst/porting_guides/porting_guide_5.rst:697 -msgid "transform community.ciscosmb.ciscosmb_facts to community.ciscosmb.facts" -msgstr "community.ciscosmb.ciscosmb_facts の community.ciscosmb.facts への変換" - -#: ../../rst/porting_guides/porting_guide_5.rst:698 -msgid "unit tests for CBS350" -msgstr "CBS350 のユニットテスト" - -#: ../../rst/porting_guides/porting_guide_5.rst:703 -msgid "hosttech_* modules - support the new JSON API at https://api.ns1.hosttech.eu/api/documentation/ (https://github.com/ansible-collections/community.dns/pull/4)." -msgstr "hosttech_* モジュール - https://api.ns1.hosttech.eu/api/documentation/ の新しい JSON API をサポートします（https://github.com/ansible-collections/community.dns/pull/4）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:708 -msgid "bitbucket_* modules - ``client_id`` is no longer marked as ``no_log=true``. If you relied on its value not showing up in logs and output, please mark the whole tasks with ``no_log: true`` (https://github.com/ansible-collections/community.general/pull/2045)." -msgstr "bitbucket_* モジュール - ``client_id`` は ``no_log=true`` としてマークされなくなりました。ログや出力に表示されない値に依存している場合は、タスク全体を ``no_log: true`` でマークしてください（https://github.com/ansible-collections/community.general/pull/2045）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:713 -msgid "redirect everything from ``community.kubernetes`` to ``kubernetes.core`` (https://github.com/ansible-collections/community.kubernetes/pull/425)." -msgstr "すべてを ``community.kubernetes`` から ``kubernetes.core`` にリダイレクトします（https://github.com/ansible-collections/community.kubernetes/pull/425）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:718 -msgid "update to use kubernetes.core 2.0 (https://github.com/openshift/community.okd/pull/93)." -msgstr "kubernetes.core 2.0 を使用するように更新します(https://github.com/openshift/community.okd/pull/93)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:741 -msgid "ome_firmware - Added option to stage the firmware update and support for selecting components and devices for baseline-based firmware update." -msgstr "ome_firmware - ベースラインベースのファームウェア更新に対して、ファームウェアの更新をステージングし、コンポーネントおよびデバイスを選択するサポートが追加されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:775 -msgid "k8s - deprecate merge_type=json. The JSON patch functionality has never worked (https://github.com/ansible-collections/kubernetes.core/pull/99)." -msgstr "k8s - merge_type=json が非推奨になりました。JSON パッチ機能は機能していません（https://github.com/ansible-collections/kubernetes.core/pull/99）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:776 -msgid "k8s_json_patch - split JSON patch functionality out into a separate module (https://github.com/ansible-collections/kubernetes.core/pull/99)." -msgstr "k8s_json_patch - JSON パッチ機能を別個のモジュールに分割します（https://github.com/ansible-collections/kubernetes.core/pull/99）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:777 -msgid "replaces the openshift client with the official kubernetes client (https://github.com/ansible-collections/kubernetes.core/issues/34)." -msgstr "openshift クライアントを公式の kubernetes クライアントに置き換えます（https://github.com/ansible-collections/kubernetes.core/issues/34）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:805 -msgid "The built-in module_util ``ansible.module_utils.common.removed`` was previously deprecated and has been removed." -msgstr "ビルトインの module_util ``ansible.module_utils.common.removed`` はすでに非推奨になり、削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:806 -msgid "connections, removed password check stubs that had been moved to become plugins." -msgstr "接続では、移動したパスワードチェックスタブが削除されプラグインになりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:807 -msgid "task, inline parameters being auto coerced into variables has been removed." -msgstr "変数に自動強制されるインラインパラメーターが削除されました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:817 -msgid "acme_* modules - the ``acme_directory`` option is now required (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "acme_* モジュール - ``acme_directory`` オプションが必須になりました（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:818 -msgid "acme_* modules - the ``acme_version`` option is now required (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "acme_* モジュール - ``acme_version`` オプションが必須になりました（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:819 -msgid "acme_account_facts - the deprecated redirect has been removed. Use community.crypto.acme_account_info instead (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "acme_account_facts - 非推奨のリダイレクトが削除されました。代わりに community.crypto.acme_account_info を使用してください（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:820 -msgid "acme_account_info - ``retrieve_orders=url_list`` no longer returns the return value ``orders``. Use the ``order_uris`` return value instead (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "acme_account_info - ``retrieve_orders=url_list`` が戻り値 ``orders`` を返さなくなりました。代わりに ``order_uris`` の戻り値を使用してください（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:821 -msgid "crypto.info module utils - the deprecated redirect has been removed. Use ``crypto.pem`` instead (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "crypto.info モジュールユーティリティー - 非推奨のリダイレクトが削除されました。代わりに ``crypto.pem`` を使用してください（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:822 -msgid "get_certificate - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "get_certificate - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:823 -msgid "openssl_certificate - the deprecated redirect has been removed. Use community.crypto.x509_certificate instead (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "openssl_certificate - 非推奨のリダイレクトが削除されました。代わりに community.crypto.x509_certificate を使用してください（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:824 -msgid "openssl_certificate_info - the deprecated redirect has been removed. Use community.crypto.x509_certificate_info instead (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "openssl_certificate_info - 非推奨のリダイレクトが削除されました。代わりに community.crypto.x509_certificate_info を使用してください（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:825 -msgid "openssl_csr - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_csr - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:826 -msgid "openssl_csr and openssl_csr_pipe - ``version`` now only accepts the (default) value 1 (https://github.com/ansible-collections/community.crypto/pull/290)." -msgstr "openssl_csr および openssl_csr_pipe - ``version`` は、（デフォルト）値の 1 のみを受け入れるようになりました（https://github.com/ansible-collections/community.crypto/pull/290）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:827 -msgid "openssl_csr_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_csr_info - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:828 -msgid "openssl_csr_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_csr_pipe - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:829 -msgid "openssl_privatekey - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_privatekey - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:830 -msgid "openssl_privatekey_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_privatekey_info - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:831 -msgid "openssl_privatekey_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_privatekey_pipe - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:832 -msgid "openssl_publickey - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_publickey - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:833 -msgid "openssl_publickey_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_publickey_info - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:834 -msgid "openssl_signature - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_signature - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:835 -msgid "openssl_signature_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "openssl_signature_info - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:836 -msgid "x509_certificate - remove ``assertonly`` provider (https://github.com/ansible-collections/community.crypto/pull/289)." -msgstr "x509_certificate - ``assertonly`` プロバイダーが削除されました（https://github.com/ansible-collections/community.crypto/pull/289）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:837 -msgid "x509_certificate - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "x509_certificate - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:838 -msgid "x509_certificate_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "x509_certificate_info - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:839 -msgid "x509_certificate_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273)." -msgstr "x509_certificate_pipe - ``pyopenssl`` バックエンドが削除されました（https://github.com/ansible-collections/community.crypto/pull/273）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:844 -msgid "docker_container - the default value of ``container_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.docker/pull/210)." -msgstr "docker_container - ``container_default_behavior`` のデフォルトが ``no_defaults`` に変更されました (https://github.com/ansible-collections/community.docker/pull/210)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:845 -msgid "docker_container - the default value of ``network_mode`` is now the name of the first network specified in ``networks`` if such are specified and ``networks_cli_compatible=true`` (https://github.com/ansible-collections/community.docker/pull/210)." -msgstr "docker_container - ``networks`` で最初のネットワークが指定され ``networks_cli_compatible=true`` が設定されている場合、``network_mode`` のデフォルト値にはそのネットワークの名前が使用されるようになりました (https://github.com/ansible-collections/community.docker/pull/210)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:846 -msgid "docker_container - the special value ``all`` can no longer be used in ``published_ports`` next to other values. Please use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/210)." -msgstr "docker_container - 特殊な値 ``all`` は、他の値の横にある ``published_ports`` で使用できなくなりました。代わりに ``publish_all_ports=true`` を使用してください（https://github.com/ansible-collections/community.docker/pull/210）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:847 -msgid "docker_login - removed the ``email`` option (https://github.com/ansible-collections/community.docker/pull/210)." -msgstr "docker_login - ``email`` オプションが削除されました（https://github.com/ansible-collections/community.docker/pull/210）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:852 -msgid "All inventory and vault scripts contained in community.general were moved to the `contrib-scripts GitHub repository `_ (https://github.com/ansible-collections/community.general/pull/2696)." -msgstr "community.general に含まれるインベントリーおよび vault スクリプトはすべて、`contrib-scripts GitHub repository `_ に移動されました（https://github.com/ansible-collections/community.general/pull/2696）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:853 -msgid "ModuleHelper module utils - remove fallback when value could not be determined for a parameter (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "ModuleHelper モジュールユーティリティー - 値がパラメーターに対して判断されない場合のフォールバックが削除されました（https://github.com/ansible-collections/community.general/pull/3461）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:854 -msgid "Removed deprecated netapp module utils and doc fragments (https://github.com/ansible-collections/community.general/pull/3197)." -msgstr "非推奨の netapp モジュールユーティリティーおよびドキュメントフラグメントが削除されました（https://github.com/ansible-collections/community.general/pull/3197）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:855 -msgid "The nios, nios_next_ip, nios_next_network lookup plugins, the nios documentation fragment, and the nios_host_record, nios_ptr_record, nios_mx_record, nios_fixed_address, nios_zone, nios_member, nios_a_record, nios_aaaa_record, nios_network, nios_dns_view, nios_txt_record, nios_naptr_record, nios_srv_record, nios_cname_record, nios_nsgroup, and nios_network_view module have been removed from community.general 4.0.0 and were replaced by redirects to the `infoblox.nios_modules `_ collection. Please install the ``infoblox.nios_modules`` collection to continue using these plugins and modules, and update your FQCNs (https://github.com/ansible-collections/community.general/pull/3592)." -msgstr "nios、nios_next_ip、nios_next_network lookup プラグイン、niosドキュメントフラグメント、およびnios_host_record、nios_ptr_record、nios_mx_record、nios_fixed_address、nios_zone、nios_member、nios_a_record、nios_aaaa_record、nios_network、nios_dns_view、nios_txt_record、nios_naptr_record、nios_srv_record、nios_cname_record、nios_nsgroup、および nios_network_view モジュールはcommunity.general 4.0.0から削除され、`infoblox.nios_modules `_へのリダイレクトに置き換えられています。これらのプラグインとモジュールの使用を続けるには、``infoblox.nios_modules``コレクションをインストールし、FQCNを更新しててください（https://github.com/ansible-collections/community.general/pull/3592）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:856 -msgid "The vendored copy of ``ipaddress`` has been removed. Please use ``ipaddress`` from the Python 3 standard library, or `from pypi `_. (https://github.com/ansible-collections/community.general/pull/2441)." -msgstr "``ipaddress`` のベンダーコピーが削除されました。Python 3 標準ライブラリーまたは`from pypi `_から ``ipaddress`` を使用してください(https://github.com/ansible-collections/community.general/pull/2441)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:857 -msgid "cpanm - removed the deprecated ``system_lib`` option. Use Ansible's privilege escalation mechanism instead; the option basically used ``sudo`` (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "cpanm - 非推奨の ``system_lib`` オプションが削除されました。代わりに Ansible の特権昇格メカニズムを使用してください。このオプションでは基本的に ``sudo`` が使用されます（https://github.com/ansible-collections/community.general/pull/3461）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:858 -msgid "grove - removed the deprecated alias ``message`` of the ``message_content`` option (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "grove - ``message_content`` オプションの非推奨のエイリアス ``message`` が削除されました(https://github.com/ansible-collections/community.general/pull/3461)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:859 -msgid "proxmox - default value of ``proxmox_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "proxmox - ``proxmox_default_behavior`` のデフォルト値が ``no_defaults`` に変更されました（https://github.com/ansible-collections/community.general/pull/3461）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:860 -msgid "proxmox_kvm - default value of ``proxmox_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "proxmox_kvm - ``proxmox_default_behavior`` のデフォルトが ``no_defaults`` に変更されました (https://github.com/ansible-collections/community.general/pull/3461)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:861 -msgid "runit - removed the deprecated ``dist`` option which was not used by the module (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "runit - モジュールで使用されていなかった非推奨の ``dist`` オプションが削除されました（https://github.com/ansible-collections/community.general/pull/3461）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:862 -msgid "telegram - removed the deprecated ``msg``, ``msg_format`` and ``chat_id`` options (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "telegram - 非推奨の ``msg``、``msg_format``、および ``chat_id`` オプションが削除されました(https://github.com/ansible-collections/community.general/pull/3461)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:863 -msgid "xfconf - the default value of ``disable_facts`` changed to ``true``, and the value ``false`` is no longer allowed. Register the module results instead (https://github.com/ansible-collections/community.general/pull/3461)." -msgstr "xfconf - ``disable_facts`` のデフォルト値が ``true`` に変更され、値 ``false`` は許可されなくなりました。代わりにモジュールの結果を登録します（https://github.com/ansible-collections/community.general/pull/3461）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:868 -msgid "drop support for Python 2 and Python 3.5 (https://github.com/ansible-collections/community.hashi_vault/issues/81)." -msgstr "Python 2 および Python 3.5 のサポートが廃止されました（https://github.com/ansible-collections/community.hashi_vault/issues/81）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:869 -msgid "support for the following deprecated environment variables has been removed: ``VAULT_AUTH_METHOD``, ``VAULT_TOKEN_PATH``, ``VAULT_TOKEN_FILE``, ``VAULT_ROLE_ID``, ``VAULT_SECRET_ID`` (https://github.com/ansible-collections/community.hashi_vault/pull/173)." -msgstr "非推奨の環境変数 ``VAULT_AUTH_METHOD``、``VAULT_TOKEN_PATH``、``VAULT_TOKEN_FILE``、``VAULT_ROLE_ID``、``VAULT_SECRET_ID`` に対応しなくなりました (https://github.com/ansible-collections/community.hashi_vault/pull/173)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:877 -msgid "ansible-test - The ``--docker-no-pull`` option is deprecated and has no effect." -msgstr "ansible-test - ``--docker-no-pull``オプションは非推奨になり、効果はありません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:878 -msgid "ansible-test - The ``--no-pip-check`` option is deprecated and has no effect." -msgstr "ansible-test - ``--no-pip-check``オプションは非推奨になり、効果はありません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:879 -msgid "include action is deprecated in favor of include_tasks, import_tasks and import_playbook." -msgstr "include_tasks、import_tasks、および import_playbook が優先されるため、include アクションは非推奨になりました。" - -#: ../../rst/porting_guides/porting_guide_5.rst:880 -msgid "module_utils' FileLock is scheduled to be removed, it is not used due to its unreliable nature." -msgstr "module_utils の FileLock は削除予定です。信頼性が低いため使用されません。" - -#: ../../rst/porting_guides/porting_guide_5.rst:885 -msgid "ec2 - the boto based ``ec2`` module has been deprecated in favour of the boto3 based ``ec2_instance`` module. The ``ec2`` module will be removed in release 4.0.0 (https://github.com/ansible-collections/amazon.aws/pull/424)." -msgstr "ec2 - boto ベースの ``ec2`` モジュールは、boto3 ベースの ``ec2_instance`` モジュールが優先されるため非推奨になりました。``ec2`` モジュールはリリース 4.0.0 で削除されます（https://github.com/ansible-collections/amazon.aws/pull/424）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:886 -msgid "ec2_classic_lb - setting of the ``ec2_elb`` fact has been deprecated and will be removed in release 4.0.0 of the collection. The module now returns ``elb`` which can be accessed using the register keyword (https://github.com/ansible-collections/amazon.aws/pull/552)." -msgstr "ec2_classic_lb - ``ec2_elb`` ファクトの設定は非推奨になり、コレクションのリリース 4.0.0 で削除されます。モジュールは、レジスターキーワードを使用してアクセス可能な ``elb`` を返すようになりました（https://github.com/ansible-collections/amazon.aws/pull/552）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:887 -msgid "ec2_vpc_dhcp_option - The ``new_config`` return key has been deprecated and will be removed in a future release. It will be replaced by ``dhcp_config``. Both values are returned in the interim. (https://github.com/ansible-collections/amazon.aws/pull/252)" -msgstr "ec2_vpc_dhcp_option - ``new_config`` の戻りキーは非推奨になり、今後のリリースで削除されます。これは ``dhcp_config`` に置き換えられます。それまでの間は、どちらの値も返されます（https://github.com/ansible-collections/amazon.aws/pull/252）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:928 -msgid "dynamodb_table - DynamoDB does not support specifying non-key-attributes when creating an ``ALL`` index. Passing ``includes`` for such indexes is currently ignored but will result in failures after version 3.0.0 (https://github.com/ansible-collections/community.aws/pull/726)." -msgstr "dynamodb_table - ``ALL`` インデックスの作成時に、DynamoDB はキー以外の属性の指定をサポートしません。このようなインデックスに ``includes`` を渡すと、現在は無視されますが、バージョン 3.0.0 以降は失敗します（https://github.com/ansible-collections/community.aws/pull/726）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:929 -msgid "dynamodb_table - DynamoDB does not support updating the primary indexes on a table. Attempts to make such changes are currently ignored but will result in failures after version 3.0.0 (https://github.com/ansible-collections/community.aws/pull/726)." -msgstr "dynamodb_table - DynamoDB は、テーブルのプライマリーインデックスの更新をサポートしません。このような変更は現在は無視されますが、バージョン 3.0.0 以降は失敗します（https://github.com/ansible-collections/community.aws/pull/726）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:930 -msgid "ec2_elb - the ``ec2_elb`` module has been removed and redirected to the ``elb_instance`` module which functions identically. The original ``ec2_elb`` name is now deprecated and will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/586)." -msgstr "ec2_elb - ``ec2_elb`` モジュールが削除され、同様に機能する ``elb_instance`` モジュールにリダイレクトされます。元の ``ec2_elb`` 名は非推奨になり、リリース 3.0.0 で削除されます（https://github.com/ansible-collections/community.aws/pull/586）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:931 -msgid "ec2_elb_info - the boto based ``ec2_elb_info`` module has been deprecated in favour of the boto3 based ``elb_classic_lb_info`` module. The ``ec2_elb_info`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/586)." -msgstr "ec2_elb_info - boto ベースの ``ec2_elb_info`` モジュールは、boto3 ベースの ``elb_classic_lb_info`` モジュールが優先されるため非推奨になりました。``ec2_elb_info`` モジュールはリリース 3.0.0 で削除されます（https://github.com/ansible-collections/community.aws/pull/586）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:932 -msgid "elb_classic_lb - the ``elb_classic_lb`` module has been removed and redirected to the ``amazon.aws.ec2_elb_lb`` module which functions identically." -msgstr "elb_classic_lb - ``elb_classic_lb`` モジュールが削除され、同様に機能する ``amazon.aws.ec2_elb_lb`` モジュールにリダイレクトされます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:933 -msgid "elb_instance - setting of the ``ec2_elb`` fact has been deprecated and will be removed in release 4.0.0 of the collection. See the module documentation for an alternative example using the register keyword (https://github.com/ansible-collections/community.aws/pull/773)." -msgstr "elb_instance - ``ec2_elb`` ファクトの設定は非推奨になり、コレクションのリリース 4.0.0 で削除されます。レギスターキーワードを使用した別の例については、モジュールのドキュメントを参照してください（https://github.com/ansible-collections/community.aws/pull/773）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:934 -msgid "iam - the boto based ``iam`` module has been deprecated in favour of the boto3 based ``iam_user``, ``iam_group`` and ``iam_role`` modules. The ``iam`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/664)." -msgstr "iam - boto ベースの ``iam`` モジュールは、boto3 ベースの ``iam_user``、``iam_group``、および ``iam_role`` モジュールが優先されるため非推奨になりました。``iam`` モジュールはリリース 3.0.0 で削除されます（https://github.com/ansible-collections/community.aws/pull/664）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:935 -msgid "iam_cert - the iam_cert module has been renamed to iam_server_certificate for consistency with the companion iam_server_certificate_info module. The usage of the module has not changed. The iam_cert alias will be removed in version 4.0.0 (https://github.com/ansible-collections/community.aws/pull/728)." -msgstr "iam_cert - 対になるiam_server_certificate_infoモジュールとの一貫性を保つために、iam_cert モジュールの名前が iam_server_certificate に変更されました。モジュールの使用方法に変更はありません。iam_cert エイリアスはバージョン 4.0.0 で削除されます（https://github.com/ansible-collections/community.aws/pull/728）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:936 -msgid "iam_server_certificate - Passing file names to the ``cert``, ``chain_cert`` and ``key`` parameters has been deprecated. We recommend using a lookup plugin to read the files instead, see the documentation for an example (https://github.com/ansible-collections/community.aws/pull/735)." -msgstr "iam_server_certificate - ファイル名を ``cert``、``chain_cert``、および ``key`` パラメーターに渡すことが非推奨になりました。代わりにlookup プラグインを使用してファイルを読み取ることが推奨されます。例については、ドキュメントを参照してください（https://github.com/ansible-collections/community.aws/pull/735）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:937 -msgid "iam_server_certificate - the default value for the ``dup_ok`` parameter is currently ``false``, in version 4.0.0 this will be updated to ``true``. To preserve the current behaviour explicitly set the ``dup_ok`` parameter to ``false`` (https://github.com/ansible-collections/community.aws/pull/737)." -msgstr "iam_server_certificate - ``dup_ok`` パラメーターのデフォルト値は、現在 ``false`` で、バージョン 4.0.0 では ``true`` に更新されます。現在の動作を維持するには、``dup_ok`` パラメーターを ``false`` に明示的に設定します（https://github.com/ansible-collections/community.aws/pull/737）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:938 -msgid "rds - the boto based ``rds`` module has been deprecated in favour of the boto3 based ``rds_instance`` module. The ``rds`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/663)." -msgstr "rds - boto ベースの ``rds`` モジュールは、boto3 ベースの ``rds_instance`` モジュールが優先されるため非推奨になりました。``rds`` モジュールはリリース 3.0.0 で削除されます（https://github.com/ansible-collections/community.aws/pull/663）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:939 -msgid "rds_snapshot - the rds_snapshot module has been renamed to rds_instance_snapshot. The usage of the module has not changed. The rds_snapshot alias will be removed in version 4.0.0 (https://github.com/ansible-collections/community.aws/pull/783)." -msgstr "rds_snapshot - rds_snapshot モジュールの名前が rds_instance_snapshot に変更されました。モジュールの使用方法に変更はありません。rds_snapshot エイリアスはバージョン 4.0.0 で削除されます（https://github.com/ansible-collections/community.aws/pull/783）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:940 -msgid "script_inventory_ec2 - The ec2.py inventory script is being moved to a new repository. The script can now be downloaded from https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py and will be removed from this collection in the 3.0 release. We recommend migrating from the script to the `amazon.aws.ec2` inventory plugin." -msgstr "script_inventory_ec2 - ec2.py インベントリースクリプトは、新しいリポジトリーに移動します。現在はスクリプトは https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py からダウンロードできますが、3.0 リリースでこのコレクションから削除されます。スクリプトから `amazon.aws.ec2` インベントリープラグインに移行することが推奨されます。" - -#: ../../rst/porting_guides/porting_guide_5.rst:954 -msgid "acme_* modules - ACME version 1 is now deprecated and support for it will be removed in community.crypto 2.0.0 (https://github.com/ansible-collections/community.crypto/pull/288)." -msgstr "acme_* モジュール - ACME バージョン 1 は非推奨になり、community.crypto 2.0.0でのサポートは削除されます（https://github.com/ansible-collections/community.crypto/pull/288）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:959 -msgid "The hosttech_dns_records module has been renamed to hosttech_dns_record_sets. The old name will stop working in community.dns 3.0.0 (https://github.com/ansible-collections/community.dns/pull/31)." -msgstr "hosttech_dns_records モジュールの名前が hosttech_dns_record_sets に変更されました。古い名前はcommunity.dns 3.0.0では機能しなくなります（https://github.com/ansible-collections/community.dns/pull/31）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:966 -msgid "docker_container - using the special value ``all`` in ``published_ports`` has been deprecated. Use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/210)." -msgstr "docker_container - ``published_ports`` で特殊な値 ``all`` を使用することが非推奨となりました。代わりに ``publish_all_ports=true`` を使用してください（https://github.com/ansible-collections/community.docker/pull/210）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:971 -msgid "Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.general 5.0.0) next spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.general 4.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.general/pull/3723)." -msgstr "Ansible 2.9 および ansible-base 2.10 のサポートは非推奨になり、来年春の次のメジャーリリース(community.general 5.0.0)で削除される予定です。ほとんどのコンテンツは ansible-base 2.10 で引き続き機能すると予想されますが、モジュールおよび action プラグインのシンボリックリンクは削除され、Ansible 2.9 では使用できないようになります。 Ansible 2.9 および ansible-base 2.10 では community.general 4.x.y を使用してください。ライフサイクル終了後でも、これらのリリースは Ansible 2.9 および ansible-base 2.10 のサポートを継続するためです（https://github.com/ansible-community/community-topics/issues/50、https://github.com/ansible-collections/community.general/pull/3723）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:973 -msgid "bitbucket_* modules - ``username`` options have been deprecated in favor of ``workspace`` and will be removed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/2045)." -msgstr "bitbucket_* モジュール - ``username`` オプションは、``workspace`` が優先されるため非推奨になり、community.general 6.0.0 で削除されます（https://github.com/ansible-collections/community.general/pull/2045）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:974 -msgid "dnsimple - python-dnsimple < 2.0.0 is deprecated and support for it will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2946#discussion_r667624693)." -msgstr "dnsimple - python-dnsimple < 2.0.0 は非推奨になり、community.general 5.0.0 ではサポートされなくなります（https://github.com/ansible-collections/community.general/pull/2946#discussion_r667624693）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:975 -msgid "gitlab_group_members - setting ``gitlab_group`` to ``name`` or ``path`` is deprecated. Use ``full_path`` instead (https://github.com/ansible-collections/community.general/pull/3451)." -msgstr "gitlab_group_members - ``gitlab_group`` を ``name`` または ``path`` に設定することは非推奨になりました。代わりに ``full_path`` を使用してください（https://github.com/ansible-collections/community.general/pull/3451）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:976 -msgid "keycloak_authentication - the return value ``flow`` is now deprecated and will be removed in community.general 6.0.0; use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/3280)." -msgstr "keycloak_authentication - 戻り値の ``flow`` は非推奨になり、community.general 6.0.0 で削除されます。代わりに ``end_state`` を使用してください(https://github.com/ansible-collections/community.general/pull/3280)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:977 -msgid "keycloak_group - the return value ``group`` is now deprecated and will be removed in community.general 6.0.0; use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/3280)." -msgstr "keycloak_group - 戻り値の ``group`` は非推奨になり、community.general 6.0.0 で削除されます。代わりに ``end_state`` を使用してください(https://github.com/ansible-collections/community.general/pull/3280)。" - -#: ../../rst/porting_guides/porting_guide_5.rst:979 -msgid "lxd_container - the current default value ``true`` of ``ignore_volatile_options`` is deprecated and will change to ``false`` in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/3429)." -msgstr "lxd_container - ``ignore_volatile_options``の現在のデフォルト値 ``true`` は非推奨になり、community.general 6.0.0 で ``false`` に変更されます（https://github.com/ansible-collections/community.general/pull/3429）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:981 -msgid "xfconf - deprecate the ``get`` state. The new module ``xfconf_info`` should be used instead (https://github.com/ansible-collections/community.general/pull/3049)." -msgstr "xfconf - ``get`` の状態が非推奨になりました。代わりに新しいモジュール ``xfconf_info`` を使用する必要があります（https://github.com/ansible-collections/community.general/pull/3049）。" - -#: ../../rst/porting_guides/porting_guide_5.rst:998 -msgid "The ``community.kubernetes`` collection is being renamed to ``kubernetes.core``. All content in the collection has been replaced by deprecated redirects to ``kubernetes.core``. If you are using FQCNs starting with ``community.kubernetes``, please update them to ``kubernetes.core`` (https://github.com/ansible-collections/community.kubernetes/pull/439)." -msgstr "``community.kubernetes`` コレクションの名前が ``kubernetes.core`` に変更されます。コレクションのすべてのコンテンツは、非推奨の ``kubernetes.core`` へのリダイレクトに置き換えられています。``community.kubernetes`` で始まる FQCN を使用している場合は、それらを ``kubernetes.core`` に更新してください（https://github.com/ansible-collections/community.kubernetes/pull/439）。" - -#: ../../rst/porting_guides/porting_guide_6.rst:8 -msgid "Ansible 6 Porting Guide" -msgstr "Ansible 6 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:15 -msgid "Ansible 6 is based on Ansible-core 2.13." -msgstr "Ansible 6 は Ansible-core 2.13 をベースにしています。" - -#: ../../rst/porting_guides/porting_guide_6.rst:18 -msgid "We suggest you read this page along with the `Ansible 6 Changelog `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて `Ansible 6 Changelog `_ を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_6.rst:24 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:22 -msgid "Templating - You can no longer perform arithmetic and concatenation operations outside of the jinja template. The following statement will need to be rewritten to produce ``[1, 2]``:" -msgstr "テンプレート化 - jinja テンプレート外で、演算操作や連結操作は実行できなくなりました。``[1, 2]`` を生成するには、以下のステートメントを書き換える必要があります。" - -#: ../../rst/porting_guides/porting_guide_6.rst:36 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:34 -#, python-format -msgid "The return value of the ``__repr__`` method of an undefined variable represented by the ``AnsibleUndefined`` object changed. ``{{ '%r'|format(undefined_variable) }}`` returns ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` in 2.13 as opposed to just ``AnsibleUndefined`` in versions 2.12 and prior." -msgstr "``AnsibleUndefined`` オブジェクトによって表される未定義の変数の ``__repr__`` メソッドの戻り値が変更されました。単に``AnsibleUndefined`` を返すバージョン 2.12 以前とは異なり、2.13 では``{{ '%r'|format(undefined_variable) }}`` は ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` を返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:38 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:36 -msgid "The ``finalize`` method is no longer exposed in the globals for use in templating. To convert ``None`` to an empty string the following expression can be used: ``{{ value if value is not none }}``." -msgstr "テンプレート化のユースケースでは、``finalize`` メソッドは、グローバルで公開されなくなりました。``None`` を空の文字列に変換するには、``{{ value if value is not none }}`` の式を使用できます。" - -#: ../../rst/porting_guides/porting_guide_6.rst:56 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:54 -msgid "To use ansible-core 2.13 for module execution, you must use Python 2 version 2.7 or Python 3 version 3.5 or newer. Any code utilizing ``ansible.module_utils.basic`` will not function with lower Python versions." -msgstr "モジュールの実行に ansible-core 2.13 を使用するには、Python 2 バージョン 2.7 または Python 3 バージョン 3.5 以降を使用する必要があります。``ansible.module_utils.basic`` を使用するコードは、より低い Python バージョンでは機能しません。" - -#: ../../rst/porting_guides/porting_guide_6.rst:82 -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:80 -msgid "``ansible.module_utils.urls.fetch_url`` will now return the captured ``HTTPError`` exception as ``r``. ``HTTPError`` is a response like object that can offer more information to module authors. Modules should rely on ``info['status'] >= 400`` to determine if there was a failure, instead of using ``r is None`` or catching ``AttributeError`` when attempting ``r.read()``." -msgstr "``ansible.module_utils.urls.fetch_url`` は、キャプチャーされた ``HTTPError`` 例外を ``r`` として返すようになりました。``HTTPError`` はオブジェクトのような応答で、モジュール作成者により多くの情報を提供できます。失敗があったかどうか判断するのに、モジュールは``r.read()`` を試みる際に``r is None`` を使用したり ``AttributeError`` をキャッチしたりする代わりに、``info['status'] >= 400``に依存する必要があります。" - -#: ../../rst/porting_guides/porting_guide_6.rst:103 -msgid "Porting Guide for v6.7.0" -msgstr "v6.7.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:111 -#: ../../rst/porting_guides/porting_guide_7.rst:228 -msgid "api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131)." -msgstr "api_modify - ``queue tree`` のエントリーの制限が人間が判読できるように定義されている (``25M`` など) 場合は、設定は ROS で正しく設定されますが、モジュールは、変更が行われていなくても、実行ごとに項目が変更されたことを示します。これは、数値を``25000000`` (これは CLI の動作と矛盾しています) などのバイト単位で返す ROS API が原因です。それを軽減するために、制限をバイト単位で定義する必要があります (これらは、ROS CLI で人間が判読できるように引き続き表示されます) (https://github.com/ansible-collections/community.routeros/pull/131)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:112 -#: ../../rst/porting_guides/porting_guide_7.rst:229 -msgid "api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131)." -msgstr "api_modify, api_info - ``routing ospf area``、``routing ospf area range``、``routing ospf instance``、``routing ospf interface-template`` パスは、ROS6 と ROS7 の間で大幅な変更が行われたため、ROS6 では完全には実装されていません (https://github.com/ansible-collections/community.routeros/pull/131)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:120 -#: ../../rst/porting_guides/porting_guide_7.rst:237 -msgid "meraki_mr_l7_firewall - New module" -msgstr "meraki_mr_l7_firewall - 新しいモジュール" - -#: ../../rst/porting_guides/porting_guide_6.rst:121 -#: ../../rst/porting_guides/porting_guide_7.rst:238 -msgid "meraki_webhook_payload_template - New module" -msgstr "meraki_webhook_payload_template - 新しいモジュール" - -#: ../../rst/porting_guides/porting_guide_6.rst:126 -#: ../../rst/porting_guides/porting_guide_7.rst:243 -msgid "all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate" -msgstr "すべてのモジュールは zabbix-api を使用せず、httpapi ansible.netcommon プラグインを使用しています。次のメジャーリリースまで、後方互換性のために zabbix-api をサポートします。移行方法の詳細については、README.md を参照してください" - -#: ../../rst/porting_guides/porting_guide_6.rst:127 -#: ../../rst/porting_guides/porting_guide_7.rst:244 -msgid "zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate" -msgstr "zabbix_agent および zabbix_proxy のロールは、zabbix-api を使用せず、httpapi ansible.netcommon プラグインを使用します。次のメジャーリリースまで、後方互換性のために zabbix-api をサポートします。移行方法の詳細については、README.md を参照してください" - -#: ../../rst/porting_guides/porting_guide_6.rst:132 -#: ../../rst/porting_guides/porting_guide_7.rst:249 -msgid "New become plugin - podman_unshare" -msgstr "新しい become プラグイン - podman_unshare" - -#: ../../rst/porting_guides/porting_guide_6.rst:133 -#: ../../rst/porting_guides/porting_guide_7.rst:250 -msgid "Podman generate systemd module" -msgstr "Podman は systemd モジュールを生成します" - -#: ../../rst/porting_guides/porting_guide_6.rst:136 -#: ../../rst/porting_guides/porting_guide_6.rst:187 -#: ../../rst/porting_guides/porting_guide_7.rst:649 -msgid "fortinet.fortimanager" -msgstr "fortinet.fortimanager" - -#: ../../rst/porting_guides/porting_guide_6.rst:138 -#: ../../rst/porting_guides/porting_guide_7.rst:651 -msgid "Fix compatibility issue for ansible 2.9.x and ansible-base 2.10.x." -msgstr "ansible 2.9.x および ansible-base 2.10.x の互換性の問題を修正します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:139 -#: ../../rst/porting_guides/porting_guide_7.rst:654 -msgid "support Ansible changelogs." -msgstr "Ansible changelog をサポートします。" - -#: ../../rst/porting_guides/porting_guide_6.rst:144 -#: ../../rst/porting_guides/porting_guide_7.rst:255 -msgid "Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2." -msgstr "FortiOS v7.0.6、v7.0.7、v7.0.8、v7.2.1、v7.2.2 をサポートします。" - -#: ../../rst/porting_guides/porting_guide_6.rst:152 -msgid "Please note that some tools, like the VScode plugin (https://github.com/ansible/vscode-ansible/issues/573), or ``ansible-doc --list --type module``, suggest to replace the correct FQCNs for modules and actions in community.general with internal names that have more than three components. For example, ``community.general.ufw`` is suggested to be replaced by ``community.general.system.ufw``. While these longer names do work, they are considered **internal names** by the collection and are subject to change and be removed at all time. They **will** be removed in community.general 6.0.0 and result in deprecation messages. Avoid using these internal names, and use general three-component FQCNs (``community.general.``) instead (https://github.com/ansible-collections/community.general/pull/5373)." -msgstr "VScode プラグイン (https://github.com/ansible/vscode-ansible/issues/573) または ``ansible-doc --list --type module`` などの一部のツールは、community.general のモジュールとアクションの正しい FQCN を、3 つ以上のコンポーネントを持つインターナル名に置き換えることを提案します。たとえば、``community.general.ufw`` は ``community.general.system.ufw`` に置き換えることが提案されています。このような長い名前でも問題ありませんが、これらはコレクションによって **インターナル名** と見なされ、変更される可能性があるため、いつでも削除される可能性があります。これらは community.general 6.0.0 で **削除される予定**で、その結果、非推奨のメッセージが表示されることになります。これらのインターナル名の使用を避け、代わりに一般的な 3 つのコンポーネントの FQCN (``community.general.``) を使用してください (https://github.com/ansible-collections/community.general/pull/5373)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:155 -msgid "Porting Guide for v6.6.0" -msgstr "v6.6.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:160 -#: ../../rst/porting_guides/porting_guide_7.rst:273 -msgid "lowlydba.sqlserver (version 1.0.4)" -msgstr "lowlydba.sqlserver (バージョン 1.0.4)" - -#: ../../rst/porting_guides/porting_guide_6.rst:168 -#: ../../rst/porting_guides/porting_guide_7.rst:283 -msgid "The ``community.routeros.command`` module claims to support check mode. Since it cannot judge whether the commands executed modify state or not, this behavior is incorrect. Since this potentially breaks existing playbooks, we will not change this behavior until community.routeros 3.0.0." -msgstr "``community.routeros.command`` モジュールは、チェックモードをサポートすると主張しています。実行されたコマンドが状態を変更するかどうかを判断できないため、この動作は正しくありません。これは既存の Playbook を壊す可能性があるため、community.routeros 3.0.0 までこの動作は変更しません。" - -#: ../../rst/porting_guides/porting_guide_6.rst:176 -#: ../../rst/porting_guides/porting_guide_7.rst:436 -msgid "newrelic_deployment - ``revision`` is required for v2 API (https://github.com/ansible-collections/community.general/pull/5341)." -msgstr "newrelic_deployment -``revision`` は、v2 API 用に必要です (https://github.com/ansible-collections/community.general/pull/5341)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:184 -#: ../../rst/porting_guides/porting_guide_7.rst:609 -msgid "newrelic_deployment - removed New Relic v1 API, added support for v2 API (https://github.com/ansible-collections/community.general/pull/5341)." -msgstr "newrelic_deployment - New Relic v1 API を削除し、v2 API のサポートを追加しました (https://github.com/ansible-collections/community.general/pull/5341)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:189 -#: ../../rst/porting_guides/porting_guide_7.rst:652 -msgid "Many fixes for Ansible sanity test warnings & errors." -msgstr "Ansible の健全性テストの警告とエラーに対する多くの修正。" - -#: ../../rst/porting_guides/porting_guide_6.rst:190 -#: ../../rst/porting_guides/porting_guide_7.rst:653 -msgid "Support FortiManager Schema 7.2.0 , 98 new modules" -msgstr "FortiManager Schema 7.2.0、98 個の新しいモジュールをサポートします" - -#: ../../rst/porting_guides/porting_guide_6.rst:195 -#: ../../rst/porting_guides/porting_guide_7.rst:941 -msgid "The mellanox.onyx collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/136)." -msgstr "mellanox.onyx コレクションはメンテナンスされていないと見なされ、Ansible 8 より先に再びメンテナンスを開始する人がいない場合、Ansible 8 から削除されます。`the removal process for details on how this works `__ を参照してください (https://github.com/ansible-community/community-topics/issues/136)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:198 -#: ../../rst/porting_guides/porting_guide_7.rst:997 -msgid "cisco.mso" -msgstr "cisco.mso" - -#: ../../rst/porting_guides/porting_guide_6.rst:200 -#: ../../rst/porting_guides/porting_guide_7.rst:999 -msgid "The mso_schema_template_contract_filter contract_filter_type attribute is deprecated. The value is now deduced from filter_type." -msgstr "mso_schema_template_contract_filter contract_filter_type 属性は非推奨となりました。この値は filter_type から推測されるようになりました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:205 -#: ../../rst/porting_guides/porting_guide_7.rst:1036 -msgid "ArgFormat module utils - deprecated along ``CmdMixin``, in favor of the ``cmd_runner_fmt`` module util (https://github.com/ansible-collections/community.general/pull/5370)." -msgstr "ArgFormat モジュール utils - ``CmdMixin`` とともに非推奨となり、``cmd_runner_fmt`` モジュール utils が使用されるようになりました (https://github.com/ansible-collections/community.general/pull/5370)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:206 -#: ../../rst/porting_guides/porting_guide_7.rst:1037 -msgid "CmdMixin module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370)." -msgstr "CmdMixin モジュール utils - 非推奨となり、``CmdRunner`` モジュール util に移行しました (https://github.com/ansible-collections/community.general/pull/5370)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:207 -#: ../../rst/porting_guides/porting_guide_7.rst:1038 -msgid "CmdModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370)." -msgstr "CmdModuleHelper モジュール utils - 非推奨となり、``CmdRunner`` モジュール util に移行しました (https://github.com/ansible-collections/community.general/pull/5370)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:208 -#: ../../rst/porting_guides/porting_guide_7.rst:1039 -msgid "CmdStateModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370)." -msgstr "CmdStateModuleHelper モジュール utils - 非推奨となり、``CmdRunner`` モジュール util に移行しました (https://github.com/ansible-collections/community.general/pull/5370)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:209 -#: ../../rst/porting_guides/porting_guide_7.rst:1041 -msgid "django_manage - support for Django releases older than 4.1 has been deprecated and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400)." -msgstr "django_manage - 4.1 より古い Django のリリースに対するサポートは非推奨となり、community.general 9.0.0 で削除される予定です (https://github.com/ansible-collections/community.general/pull/5400)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:210 -#: ../../rst/porting_guides/porting_guide_7.rst:1042 -msgid "django_manage - support for the commands ``cleanup``, ``syncdb`` and ``validate`` that have been deprecated in Django long time ago will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400)." -msgstr "django_manage - だいぶ前に Django で非推奨となったコマンド ``cleanup``、``syncdb``、``validate`` のサポートは community.general 9.0.0 で削除される予定です (https://github.com/ansible-collections/community.general/pull/5400)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:211 -#: ../../rst/porting_guides/porting_guide_7.rst:1043 -msgid "django_manage - the behavior of \"creating the virtual environment when missing\" is being deprecated and will be removed in community.general version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5405)." -msgstr "django_manage - 「不足時に仮想環境を作成する」という動作は非推奨となり、community.general バージョン 9.0.0 で削除される予定です (https://github.com/ansible-collections/community.general/pull/5405)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:212 -#: ../../rst/porting_guides/porting_guide_7.rst:1046 -msgid "newrelic_deployment - ``appname`` and ``environment`` are no longer valid options in the v2 API. They will be removed in community.general 7.0.0 (https://github.com/ansible-collections/community.general/pull/5341)." -msgstr "newrelic_deployment -``appname`` と``environment`` は、v2 API では有効なオプションではなくなりました。community.general 7.0.0 (https://github.com/ansible-collections/community.general/pull/5341) で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_6.rst:215 -msgid "Porting Guide for v6.5.0" -msgstr "v6.5.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:221 -#: ../../rst/porting_guides/porting_guide_6.rst:344 -#: ../../rst/porting_guides/porting_guide_7.rst:663 -msgid "infoblox.nios_modules" -msgstr "infoblox.nios_modules" - -#: ../../rst/porting_guides/porting_guide_6.rst:223 -#: ../../rst/porting_guides/porting_guide_7.rst:665 -msgid "Feature for extra layer security , with `cert` and `key` parameters in playbooks for authenticating using certificate and key ``*.pem`` file absolute path `#154 `_" -msgstr "証明書とキー ``*.pem`` ファイルの絶対パスを使用して認証するための Playbook の `cert` と `key` パラメーターを使用した、追加のレイヤーセキュリティーの機能 `#154 `_" - -#: ../../rst/porting_guides/porting_guide_6.rst:224 -#: ../../rst/porting_guides/porting_guide_7.rst:666 -msgid "Fix to remove issue causing due to template attr in deleting network using Ansible module nios network `#147 `_" -msgstr "Ansible モジュール nios network を使用してネットワークを削除する際にテンプレート attr が原因で発生する問題を削除する修正 `#147 `_" - -#: ../../rst/porting_guides/porting_guide_6.rst:229 -#: ../../rst/porting_guides/porting_guide_7.rst:937 -msgid "The dellemc.os10 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/134)." -msgstr "dellemc.os10 コレクションはメンテナンスされていないと見なされ、Ansible 8 より先に再びメンテナンスを開始する人がいない場合、Ansible 8 から削除されます。`the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/134) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:230 -#: ../../rst/porting_guides/porting_guide_7.rst:938 -msgid "The dellemc.os6 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/132)." -msgstr "dellemc.os6 コレクションはメンテナンスされていないと見なされ、Ansible 8 より先に再びメンテナンスを開始する人がいない場合、Ansible 8 から削除されます。`the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/132) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:231 -#: ../../rst/porting_guides/porting_guide_7.rst:939 -msgid "The dellemc.os9 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/133)." -msgstr "dellemc.os9 コレクションはメンテナンスされていないと見なされ、Ansible 8 より先に再びメンテナンスを開始する人がいない場合、Ansible 8 から削除されます。`the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/133) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:236 -#: ../../rst/porting_guides/porting_guide_7.rst:1045 -msgid "lxc_container - the module will no longer make any effort to support Python 2 (https://github.com/ansible-collections/community.general/pull/5304)." -msgstr "lxc_container - このモジュールは Python 2 をサポートしなくなりました (https://github.com/ansible-collections/community.general/pull/5304)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:239 -msgid "Porting Guide for v6.4.0" -msgstr "v6.4.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:244 -msgid "inspur.ispim (version 1.0.1)" -msgstr "inspur.ispim (バージョン 1.0.1)" - -#: ../../rst/porting_guides/porting_guide_6.rst:245 -msgid "vultr.cloud (version 1.1.0)" -msgstr "vultr.cloud (バージョン 1.1.0)" - -#: ../../rst/porting_guides/porting_guide_6.rst:253 -#: ../../rst/porting_guides/porting_guide_7.rst:1047 -msgid "proxmox - deprecated the current ``unprivileged`` default value, will be changed to ``true`` in community.general 7.0.0 (https://github.com/pull/5224)." -msgstr "proxmox - 現在の ``unprivileged`` のデフォルト値は非推奨となり、community.general 7.0.0 で ``true`` に変更されます (https://github.com/pull/5224)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:256 -msgid "Porting Guide for v6.3.0" -msgstr "v6.3.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:264 -#: ../../rst/porting_guides/porting_guide_7.rst:614 -msgid "mysql_db - the ``pipefail`` argument's default value will be changed to ``true`` in community.mysql 4.0.0. If your target machines do not use ``bash`` as a default interpreter, set ``pipefail`` to ``false`` explicitly. However, we strongly recommend setting up ``bash`` as a default and ``pipefail=true`` as it will protect you from getting broken dumps you don't know about (https://github.com/ansible-collections/community.mysql/issues/407)." -msgstr "mysql_db - ``pipefail`` 引数のデフォルト値が community.mysql 4.0.0 では ``true`` に変更されます。ターゲットマシンがデフォルトのインタープリターとして ``bash`` を使用しない場合は、``pipefail`` を ``false`` に明示的に設定してください。ただし、知らない間に壊れたダンプを取得することから保護するため、``bash`` (デフォルト) および ``pipefail=true`` をセットアップすることを強くお勧めします (https://github.com/ansible-collections/community.mysql/issues/407)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:269 -#: ../../rst/porting_guides/porting_guide_7.rst:659 -msgid "Support Diff feature in check_mode." -msgstr "check_mode で Diff 機能をサポートします。" - -#: ../../rst/porting_guides/porting_guide_6.rst:270 -#: ../../rst/porting_guides/porting_guide_7.rst:660 -msgid "Support Fortios 7.2.0." -msgstr "Fortios 7.2.0 をサポートします。" - -#: ../../rst/porting_guides/porting_guide_6.rst:275 -#: ../../rst/porting_guides/porting_guide_7.rst:940 -msgid "The google.cloud collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/105)." -msgstr "google.cloud コレクションはメンテナンスされていないと見なされ、Ansible 8 より先に再びメンテナンスを開始する人がいない場合、Ansible 8 から削除されます。`the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/105) を参照してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:276 -msgid "The servicenow.servicenow collection has been deprecated by its maintainers (https://github.com/ServiceNowITOM/servicenow-ansible/pull/69) and will be removed from Ansible 7. It can still be installed manually, but it is suggested to swich to `servicenow.itsm `__ instead (https://github.com/ansible-community/community-topics/issues/124)." -msgstr "servicenow.servicenow コレクションは、そのメンテナーによって非推奨となり (https://github.com/ServiceNowITOM/servicenow-ansible/pull/69)、Ansible 7 から削除されます。引き続き手動でインストールできますが、`servicenow.itsm `__ instead に切り替えることをお勧めします (https://github.com/ansible-community/community-topics/issues/124)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:279 -msgid "Porting Guide for v6.2.0" -msgstr "v6.2.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:284 -msgid "ibm.spectrum_virtualize (version 1.9.0)" -msgstr "ibm.spectrum_virtualize (version 1.9.0)" - -#: ../../rst/porting_guides/porting_guide_6.rst:292 -#: ../../rst/porting_guides/porting_guide_7.rst:301 -msgid "na_ontap_snapshot - added documentation to use UTC format for ``expiry_time``." -msgstr "na_ontap_snapshot - ``expiry_time`` 用の UTC 形式を使用するためのドキュメントを追加しました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:300 -#: ../../rst/porting_guides/porting_guide_7.rst:625 -msgid "postgresql_user - the ``groups`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_membership`` module to specify group/role memberships instead (https://github.com/ansible-collections/community.postgresql/issues/277)." -msgstr "postgresql_user - ``groups`` 引数は非推奨になり、``community.postgresql 3.0.0`` で削除されます。グループ/ロールメンバーシップの指定には、代わりに ``postgresql_membership``を使用してください (https://github.com/ansible-collections/community.postgresql/issues/277)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:308 -#: ../../rst/porting_guides/porting_guide_7.rst:1053 -msgid "vault_kv2_get lookup - the ``engine_mount_point option`` in the ``vault_kv2_get`` lookup only will change its default from ``kv`` to ``secret`` in community.hashi_vault version 4.0.0 (https://github.com/ansible-collections/community.hashi_vault/issues/279)." -msgstr "vault_kv2_get ルックアップ - ``vault_kv2_get`` ルックアップの ``engine_mount_point option`` のみが、community.hashi_vault バージョン 4.0.0 でデフォルトを ``kv`` から ``secret`` に変更します (https://github.com/ansible-collections/community.hashi_vault/issues/279)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:311 -msgid "Porting Guide for v6.1.0" -msgstr "v6.1.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:316 -msgid "purestorage.fusion (version 1.0.2)" -msgstr "purestorage.fusion (バージョン 1.0.2)" - -#: ../../rst/porting_guides/porting_guide_6.rst:330 -#: ../../rst/porting_guides/porting_guide_6.rst:419 -#: ../../rst/porting_guides/porting_guide_7.rst:294 -msgid "ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``" -msgstr "ome_device_power_settings - Issue(212679)。パラメーター ``power_cap`` に指定された値がサポートされる 0 から 32767 の範囲内にない場合、モジュールは ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` woと共にエラーを発生します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:331 -#: ../../rst/porting_guides/porting_guide_6.rst:422 -#: ../../rst/porting_guides/porting_guide_7.rst:295 -msgid "ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters." -msgstr "ome_device_quick_deploy - Issue(216352)。ipv6_prefix_length および vlan_id パラメーターにサポートされていない値を指定すると、モジュールは適切なエラーメッセージを表示しません。" - -#: ../../rst/porting_guides/porting_guide_6.rst:340 -#: ../../rst/porting_guides/porting_guide_7.rst:546 -msgid "win_chocolatey - Added bootstrap_script option to allow users to target a script URL for installing Chocolatey on clients." -msgstr "win_chocolatey - クライアントに Chocolatey をインストールするためのスクリプト URL をユーザーがターゲットにできるようにするための bootstrap_script オプションを追加しました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:341 -#: ../../rst/porting_guides/porting_guide_7.rst:547 -msgid "win_chocolatey_facts - Added outdated packages list to data returned." -msgstr "win_chocolatey_facts - 返されるデータに古いパッケージのリストを追加しました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:346 -#: ../../rst/porting_guides/porting_guide_7.rst:667 -msgid "Update `text` field of TXT Record `#128 `_" -msgstr "TXT Record `#128 `_ の `text` フィールドを更新します" - -#: ../../rst/porting_guides/porting_guide_6.rst:347 -#: ../../rst/porting_guides/porting_guide_7.rst:668 -msgid "Update operation using `old_name` and `new_name` for the object with dummy name in `old_name` (which does not exist in system) will not create a new object in the system. An error will be thrown stating the object does not exist in the system `#129 `_" -msgstr "`old_name` (システム内に存在しない) にダミー名を持つオブジェクトの `old_name` および `new_name` を使用して操作を更新しても、システム内に新しいオブジェクトは作成されません。そのオブジェクトはシステムに存在しないというエラーが投げられます `#129 `_" - -#: ../../rst/porting_guides/porting_guide_6.rst:355 -#: ../../rst/porting_guides/porting_guide_7.rst:994 -msgid "Deprecated ios_linkagg_module in favor of ios_lag_interfaces." -msgstr "ios_lag_interfaces を優先して ios_linkagg_module を非推奨としました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:360 -#: ../../rst/porting_guides/porting_guide_7.rst:1005 -msgid "aws_codebuild - The ``tags`` parameter currently uses a non-standard format and has been deprecated. In release 6.0.0 this parameter will accept a simple key/value pair dictionary instead of the current list of dictionaries. It is recommended to migrate to using the resource_tags parameter which already accepts the simple dictionary format (https://github.com/ansible-collections/community.aws/pull/1221)." -msgstr "aws_codebuild - ``tags`` パラメーターは現在、非標準形式を使用しているため、非推奨となりました。リリース 6.0.0 では、このパラメーターは、現在のディクショナリーのリストではなく、単純なキーと値のペアのディクショナリーを受け入れます。単純なディクショナリー形式をすでに受け入れている resource_tags パラメーターを使用するように移行することをお勧めします (https://github.com/ansible-collections/community.aws/pull/1221)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:361 -#: ../../rst/porting_guides/porting_guide_7.rst:1016 -msgid "route53_info - The CamelCase return values for ``HostedZones``, ``ResourceRecordSets``, and ``HealthChecks`` have been deprecated, in the future release you must use snake_case return values ``hosted_zones``, ``resource_record_sets``, and ``health_checks`` instead respectively\"." -msgstr "route53_info - ``HostedZones``、``ResourceRecordSets`` の CamelCase の戻り値および ``HealthChecks`` が非推奨となりました。今後のリリースでは、代わりに ``hosted_zones``、``resource_record_sets`` の snake_case の戻り値および ``health_checks`` をそれぞれ使用する必要があります。" - -#: ../../rst/porting_guides/porting_guide_6.rst:366 -#: ../../rst/porting_guides/porting_guide_7.rst:1023 -msgid "Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.crypto 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.crypto/pull/460)." -msgstr "Ansible 2.9 および ansible-base 2.10 のサポートは非推奨になり、次のメジャーリリース (community.crypto 3.0.0) で削除されます。モジュールによっては、その後もこれらのバージョンで引き続き動作する可能性がありますが、サポートするために必要な互換性コードは保持されなくなります (https://github.com/ansible-collections/community.crypto/pull/460)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:371 -#: ../../rst/porting_guides/porting_guide_7.rst:1028 -msgid "Support for Docker API version 1.20 to 1.24 has been deprecated and will be removed in community.docker 3.0.0. The first Docker version supporting API version 1.25 was Docker 1.13, released in January 2017. This affects the modules ``docker_container``, ``docker_container_exec``, ``docker_container_info``, ``docker_compose``, ``docker_login``, ``docker_image``, ``docker_image_info``, ``docker_image_load``, ``docker_host_info``, ``docker_network``, ``docker_network_info``, ``docker_node_info``, ``docker_swarm_info``, ``docker_swarm_service``, ``docker_swarm_service_info``, ``docker_volume_info``, and ``docker_volume``, whose minimally supported API version is between 1.20 and 1.24 (https://github.com/ansible-collections/community.docker/pull/396)." -msgstr "Docker API バージョン 1.20 から 1.24 のサポートは非推奨となり、community.docker 3.0.0 で削除される予定です。API バージョン 1.25 をサポートする最初の Docker バージョンは、2017 年 1 月にリリースされた Docker 1.13 でした。これは、``docker_container``、``docker_container_exec``、``docker_container_info``、``docker_compose``、``docker_login``、``docker_image``、``docker_image_info``、``docker_image_load``、``docker_host_info``、``docker_network``、``docker_network_info``、``docker_node_info``、``docker_swarm_info``、``docker_swarm_service``、``docker_swarm_service_info``、``docker_volume_info`` および ``docker_volume`` モジュールに影響します。これらの最低限サポートされている API バージョンは 1.20 から 1.24 の間になります (https://github.com/ansible-collections/community.docker/pull/396)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:372 -#: ../../rst/porting_guides/porting_guide_7.rst:1029 -msgid "Support for Python 2.6 is deprecated and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with Python 2.6, but we will no longer try to ensure compatibility (https://github.com/ansible-collections/community.docker/pull/388)." -msgstr "Python 2.6 のサポートが非推奨となり、次のメジャーリリース (community.docker 3.0.0) で削除される予定です。一部のモジュールは引き続き Python 2.6 で動作する可能性がありますが、今後は互換性の確保を試行することはありません (https://github.com/ansible-collections/community.docker/pull/388)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:377 -#: ../../rst/porting_guides/porting_guide_7.rst:1040 -msgid "cmd_runner module utils - deprecated ``fmt`` in favour of ``cmd_runner_fmt`` as the parameter format object (https://github.com/ansible-collections/community.general/pull/4777)." -msgstr "cmd_runner モジュール utils - パラメーター形式オブジェクトとして、``cmd_runner_fmt`` を優先して ``fmt`` を非推奨としました (https://github.com/ansible-collections/community.general/pull/4777)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:380 -msgid "Porting Guide for v6.0.0" -msgstr "v6.0.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_6.rst:396 -msgid "get_url - document ``check_mode`` correctly with unreliable changed status (https://github.com/ansible/ansible/issues/65687)." -msgstr "get_url - 信頼できない changed ステータスの ``check_mode`` を正しく記録します (https://github.com/ansible/ansible/issues/65687)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:401 -msgid "eos - When using eos modules on Ansible 2.9, tasks will occasionally fail with ``import_modules`` enabled. This can be avoided by setting ``import_modules: no``" -msgstr "EOS - Ansible 2.9 で eos モジュールを使用すると、``import_modules`` が有効化されてタスクが失敗することがあります。これは、``import_modules: no`` を設定することで回避できる可能性があります。" - -#: ../../rst/porting_guides/porting_guide_6.rst:415 -msgid "ome_application_console_preferences - Issue(224690) - The module does not display a proper error message when an unsupported value is provided for the parameters report_row_limit, email_sender_settings, and metric_collection_settings, and the value is applied on OpenManage Enterprise." -msgstr "ome_application_console_preferences - Issue (224690)。モジュールは、report_row_limit、email_sender_settings、metric_collection_settings パラメーターにサポートされていない値を指定すると、適切なエラーメッセージを表示しません。また、値は OpenManage Enterprise に適用されます。" - -#: ../../rst/porting_guides/porting_guide_6.rst:421 -msgid "ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``" -msgstr "ome_device_power_settings - Issue(212679)。パラメーター ``power_cap`` に指定された値がサポートされる 0 から 32767 の範囲内にない場合、モジュールは``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.``のメッセージと共にエラーを発生します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:436 -msgid "Module Python Dependency - Drop support for Python 2.6 in module execution." -msgstr "モジュール Python の依存関係 - モジュール実行で Python 2.6 のドロップサポートを廃止します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:437 -msgid "Templating - it is no longer allowed to perform arithmetic and concatenation operations outside of the jinja template (https://github.com/ansible/ansible/pull/75587)" -msgstr "テンプレート化 - jinja テンプレートの外部で算術演算と連結演算を実行できなくなりました (https://github.com/ansible/ansible/pull/75587)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:438 -msgid "The ``finalize`` method is no longer exposed in the globals for use in templating." -msgstr "``finalize`` メソッドは、テンプレートで使用するためにグローバルで公開されなくなりました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:443 -msgid "aws_caller_facts - Remove deprecated ``aws_caller_facts`` alias. Please use ``aws_caller_info`` instead." -msgstr "aws_caller_facts - 非推奨の ``aws_caller_facts`` エイリアスを削除します。代わりに ``aws_caller_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:444 -msgid "cloudformation_facts - Remove deprecated ``cloudformation_facts`` alias. Please use ``cloudformation_info`` instead." -msgstr "cloudformation_facts - 非推奨の ``cloudformation_facts`` エイリアスを削除します。代わりに ``cloudformation_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:445 -msgid "ec2_ami_facts - Remove deprecated ``ec2_ami_facts`` alias. Please use ``ec2_ami_info`` instead." -msgstr "ec2_ami_facts - 非推奨の ``ec2_ami_facts`` エイリアスを削除します。代わりに ``ec2_ami_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:446 -msgid "ec2_eni_facts - Remove deprecated ``ec2_eni_facts`` alias. Please use ``ec2_eni_info`` instead." -msgstr "ec2_eni_facts - 非推奨の ``ec2_eni_facts`` エイリアスを削除します。代わりに ``ec2_eni_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:447 -msgid "ec2_group_facts - Remove deprecated ``ec2_group_facts`` alias. Please use ``ec2_group_info`` instead." -msgstr "ec2_group_facts - 非推奨の ``ec2_group_facts`` エイリアスを削除します。代わりに ``ec2_group_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:448 -msgid "ec2_instance_facts - Remove deprecated ``ec2_instance_facts`` alias. Please use ``ec2_instance_info`` instead." -msgstr "ec2_instance_facts - 非推奨の ``ec2_instance_facts`` エイリアスを削除します。代わりに ``ec2_instance_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:449 -msgid "ec2_snapshot_facts - Remove deprecated ``ec2_snapshot_facts`` alias. Please use ``ec2_snapshot_info`` instead." -msgstr "ec2_snapshot_facts - 非推奨の ``ec2_snapshot_facts`` エイリアスを削除します。代わりに ``ec2_snapshot_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:450 -msgid "ec2_vol_facts - Remove deprecated ``ec2_vol_facts`` alias. Please use ``ec2_vol_info`` instead." -msgstr "ec2_vol_facts - 非推奨の ``ec2_vol_facts`` エイリアスを削除します。代わりに ``ec2_vol_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:451 -msgid "ec2_vpc_dhcp_option_facts - Remove deprecated ``ec2_vpc_dhcp_option_facts`` alias. Please use ``ec2_vpc_dhcp_option_info`` instead." -msgstr "ec2_vpc_dhcp_option_facts - 非推奨の ``ec2_vpc_dhcp_option_facts`` エイリアスを削除します。代わりに ``ec2_vpc_dhcp_option_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:452 -msgid "ec2_vpc_endpoint_facts - Remove deprecated ``ec2_vpc_endpoint_facts`` alias. Please use ``ec2_vpc_endpoint_info`` instead." -msgstr "ec2_vpc_endpoint_facts - 非推奨の ``ec2_vpc_endpoint_facts`` エイリアスを削除します。代わりに ``ec2_vpc_endpoint_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:453 -msgid "ec2_vpc_igw_facts - Remove deprecated ``ec2_vpc_igw_facts`` alias. Please use ``ec2_vpc_igw_info`` instead." -msgstr "ec2_vpc_igw_facts - 非推奨の ``ec2_vpc_igw_facts`` エイリアスを削除します。代わりに ``ec2_vpc_igw_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:454 -msgid "ec2_vpc_nat_gateway_facts - Remove deprecated ``ec2_vpc_nat_gateway_facts`` alias. Please use ``ec2_vpc_nat_gateway_info`` instead." -msgstr "ec2_vpc_nat_gateway_facts - 非推奨の ``ec2_vpc_nat_gateway_facts`` エイリアスを削除します。代わりに ``ec2_vpc_nat_gateway_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:455 -msgid "ec2_vpc_net_facts - Remove deprecated ``ec2_vpc_net_facts`` alias. Please use ``ec2_vpc_net_info`` instead." -msgstr "ec2_vpc_net_facts - 非推奨の ``ec2_vpc_net_facts`` エイリアスを削除します。代わりに ``ec2_vpc_net_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:456 -msgid "ec2_vpc_route_table_facts - Remove deprecated ``ec2_vpc_route_table_facts`` alias. Please use ``ec2_vpc_route_table_info`` instead." -msgstr "ec2_vpc_route_table_facts - 非推奨の ``ec2_vpc_route_table_facts`` エイリアスを削除します。代わりに ``ec2_vpc_route_table_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:457 -msgid "ec2_vpc_subnet_facts - Remove deprecated ``ec2_vpc_subnet_facts`` alias. Please use ``ec2_vpc_subnet_info`` instead." -msgstr "ec2_vpc_subnet_facts - 非推奨の ``ec2_vpc_subnet_facts`` エイリアスを削除します。代わりに ``ec2_vpc_subnet_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:462 -msgid "httpapi - Change default value of ``import_modules`` option from ``no`` to ``yes``" -msgstr "httpapi - ``import_modules`` オプションのデフォルト値を ``no`` から ``yes`` に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:463 -msgid "netconf - Change default value of ``import_modules`` option from ``no`` to ``yes``" -msgstr "netconf - ``import_modules`` オプションのデフォルト値を ``no`` から ``yes`` に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:464 -msgid "network_cli - Change default value of ``import_modules`` option from ``no`` to ``yes``" -msgstr "network_cli - ``import_modules`` オプションのデフォルト値を ``no`` から ``yes`` に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:469 -msgid "eos_command - new suboption ``version`` of parameter ``command``, which controls the JSON response version. Previously the value was assumed to be \"latest\" for network_cli and \"1\" for httpapi, but the default will now be \"latest\" for both connections. This option is also available for use in modules making their own device requests with ``plugins.module_utils.network.eos.eos.run_commands()`` with the same new default behavior. (https://github.com/ansible-collections/arista.eos/pull/258)." -msgstr "eos_command - パラメーター ``command`` の新しいサブオプション ``version`` は、JSON 応答バージョンを制御します。これまでは、値は network_cli の場合は「latest」、httpapi の場合は「1」と想定されていましたが、両方の接続のデフォルトは「latest」になりました。このオプションは、同じ新しいデフォルトの動作で ``plugins.module_utils.network.eos.eos.run_commands()`` を使用して独自のデバイス要求を行うモジュールでも使用できます (https://github.com/ansible-collections/arista.eos/pull/258)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:470 -msgid "httpapi - the ``eos_use_sessions`` option is now a boolean instead of an integer." -msgstr "httpapi - ``eos_use_sessions`` オプションは整数ではなくブール値になりました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:475 -msgid "aws_acm_facts - Remove deprecated alias ``aws_acm_facts``. Please use ``aws_acm_info`` instead." -msgstr "aws_acm_facts - 非推奨のエイリアス ``aws_acm_facts`` を削除します。代わりに ``aws_acm_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:476 -msgid "aws_kms_facts - Remove deprecated alias ``aws_kms_facts``. Please use ``aws_kms_info`` instead." -msgstr "aws_kms_facts - 非推奨のエイリアス ``aws_kms_facts`` を削除します。代わりに ``aws_kms_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:477 -msgid "aws_kms_info - Deprecated ``keys_attr`` field is now ignored (https://github.com/ansible-collections/community.aws/pull/838)." -msgstr "aws_kms_info - 非推奨の ``keys_attr`` フィールドは無視されます (https://github.com/ansible-collections/community.aws/pull/838)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:478 -msgid "aws_region_facts - Remove deprecated alias ``aws_region_facts``. Please use ``aws_region_info`` instead." -msgstr "aws_region_facts - 非推奨のエイリアス ``aws_region_facts`` を削除します。代わりに ``aws_region_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:479 -msgid "aws_s3_bucket_facts - Remove deprecated alias ``aws_s3_bucket_facts``. Please use ``aws_s3_bucket_info`` instead." -msgstr "aws_s3_bucket_facts - 非推奨のエイリアス ``aws_s3_bucket_facts`` を削除します。代わりに ``aws_s3_bucket_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:480 -msgid "aws_sgw_facts - Remove deprecated alias ``aws_sgw_facts``. Please use ``aws_sgw_info`` instead." -msgstr "aws_sgw_facts - 非推奨のエイリアス ``aws_sgw_facts`` を削除します。代わりに ``aws_sgw_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:481 -msgid "aws_waf_facts - Remove deprecated alias ``aws_waf_facts``. Please use ``aws_waf_info`` instead." -msgstr "aws_waf_facts - 非推奨のエイリアス ``aws_waf_facts`` を削除します。代わりに ``aws_waf_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:482 -msgid "cloudfront_facts - Remove deprecated alias ``cloudfront_facts``. Please use ``cloudfront_info`` instead." -msgstr "cloudfront_facts - 非推奨のエイリアス ``cloudfront_facts`` を削除します。代わりに ``cloudfront_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:483 -msgid "cloudwatchlogs_log_group_facts - Remove deprecated alias ``cloudwatchlogs_log_group_facts``. Please use ``cloudwatchlogs_log_group_info`` instead." -msgstr "cloudwatchlogs_log_group_facts - 非推奨のエイリアス ``cloudwatchlogs_log_group_facts`` を削除します。代わりに ``cloudwatchlogs_log_group_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:484 -msgid "dynamodb_table - deprecated updates currently ignored for primary keys and global_all indexes will now result in a failure. (https://github.com/ansible-collections/community.aws/pull/837)." -msgstr "dynamodb_table - プライマリーキーと global_all インデックスで現在無視されている更新が非推奨になり、今後は失敗するようになります (https://github.com/ansible-collections/community.aws/pull/837)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:485 -msgid "ec2_asg_facts - Remove deprecated alias ``ec2_asg_facts``. Please use ``ec2_asg_info`` instead." -msgstr "ec2_asg_facts - 非推奨のエイリアス ``ec2_asg_facts`` を削除します。代わりに ``ec2_asg_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:486 -msgid "ec2_customer_gateway_facts - Remove deprecated alias ``ec2_customer_gateway_facts``. Please use ``ec2_customer_gateway_info`` instead." -msgstr "ec2_customer_gateway_facts - 非推奨のエイリアス ``ec2_customer_gateway_facts`` を削除します。代わりに ``ec2_customer_gateway_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:487 -msgid "ec2_eip_facts - Remove deprecated alias ``ec2_eip_facts``. Please use ``ec2_eip_info`` instead." -msgstr "ec2_eip_facts - 非推奨のエイリアス ``ec2_eip_facts`` を削除します。代わりに ``ec2_eip_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:488 -msgid "ec2_elb_facts - Remove deprecated alias ``ec2_elb_facts``. Please use ``ec2_elb_info`` instead." -msgstr "ec2_elb_facts - 非推奨のエイリアス ``ec2_elb_facts`` を削除します。代わりに ``ec2_elb_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:489 -msgid "ec2_elb_info - The ``ec2_elb_info`` module has been removed. Please use ``the ``elb_classic_lb_info`` module." -msgstr "ec2_elb_info - ``ec2_elb_info`` モジュールが削除されました。``the ``elb_classic_lb_info'' モジュールを使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:490 -msgid "ec2_lc_facts - Remove deprecated alias ``ec2_lc_facts``. Please use ``ec2_lc_info`` instead." -msgstr "ec2_lc_facts - 非推奨のエイリアス ``ec2_lc_facts`` を削除します。代わりに ``ec2_lc_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:491 -msgid "ec2_placement_group_facts - Remove deprecated alias ``ec2_placement_group_facts``. Please use ``ec2_placement_group_info`` instead." -msgstr "ec2_placement_group_facts - 非推奨のエイリアス ``ec2_placement_group_facts`` を削除します。代わりに ``ec2_placement_group_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:492 -msgid "ec2_vpc_nacl_facts - Remove deprecated alias ``ec2_vpc_nacl_facts``. Please use ``ec2_vpc_nacl_info`` instead." -msgstr "ec2_vpc_nacl_facts - 非推奨のエイリアス ``ec2_vpc_nacl_facts`` を削除します。代わりに ``ec2_vpc_nacl_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:493 -msgid "ec2_vpc_peering_facts - Remove deprecated alias ``ec2_vpc_peering_facts``. Please use ``ec2_vpc_peering_info`` instead." -msgstr "ec2_vpc_peering_facts - 非推奨のエイリアス ``ec2_vpc_peering_facts`` を削除します。代わりに ``ec2_vpc_peering_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:494 -msgid "ec2_vpc_route_table_facts - Remove deprecated alias ``ec2_vpc_route_table_facts``. Please use ``ec2_vpc_route_table_info`` instead." -msgstr "ec2_vpc_route_table_facts - 非推奨のエイリアス ``ec2_vpc_route_table_facts`` を削除します。代わりに ``ec2_vpc_route_table_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:495 -msgid "ec2_vpc_vgw_facts - Remove deprecated alias ``ec2_vpc_vgw_facts``. Please use ``ec2_vpc_vgw_info`` instead." -msgstr "ec2_vpc_vgw_facts - 非推奨のエイリアス ``ec2_vpc_vgw_facts`` を削除します。代わりに ``ec2_vpc_vgw_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:496 -msgid "ec2_vpc_vpn_facts - Remove deprecated alias ``ec2_vpc_vpn_facts``. Please use ``ec2_vpc_vpn_info`` instead." -msgstr "ec2_vpc_vpn_facts - 非推奨のエイリアス ``ec2_vpc_vpn_facts`` を削除します。代わりに ``ec2_vpc_vpn_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:497 -msgid "ecs_service_facts - Remove deprecated alias ``ecs_service_facts``. Please use ``ecs_service_info`` instead." -msgstr "ecs_service_facts - 非推奨のエイリアス ``ecs_service_facts`` を削除します。代わりに ``ecs_service_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:498 -msgid "ecs_taskdefinition_facts - Remove deprecated alias ``ecs_taskdefinition_facts``. Please use ``ecs_taskdefinition_info`` instead." -msgstr "ecs_taskdefinition_facts - 非推奨のエイリアス ``ecs_taskdefinition_facts`` を削除します。代わりに ``ecs_taskdefinition_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:499 -msgid "efs_facts - Remove deprecated alias ``efs_facts``. Please use ``efs_info`` instead." -msgstr "efs_facts - 非推奨のエイリアス ``efs_facts`` を削除します。代わりに ``efs_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:500 -msgid "elasticache_facts - Remove deprecated alias ``elasticache_facts``. Please use ``elasticache_info`` instead." -msgstr "elasticache_facts - 非推奨のエイリアス ``elasticache_facts`` を削除します。代わりに ``elasticache_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:501 -msgid "elb_application_lb_facts - Remove deprecated alias ``elb_application_lb_facts``. Please use ``elb_application_lb_info`` instead." -msgstr "elb_application_lb_facts - 非推奨のエイリアス ``elb_application_lb_facts`` を削除します。代わりに ``elb_application_lb_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:502 -msgid "elb_classic_lb_facts - Remove deprecated alias ``elb_classic_lb_facts``. Please use ``elb_classic_lb_info`` instead." -msgstr "elb_classic_lb_facts - 非推奨のエイリアス ``elb_classic_lb_facts`` を削除します。代わりに ``elb_classic_lb_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:503 -msgid "elb_target_facts - Remove deprecated alias ``elb_target_facts``. Please use ``elb_target_info`` instead." -msgstr "elb_target_facts - 非推奨のエイリアス ``elb_target_facts`` を削除します。代わりに ``elb_target_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:504 -msgid "elb_target_group_facts - Remove deprecated alias ``elb_target_group_facts``. Please use ``elb_target_group_info`` instead." -msgstr "elb_target_group_facts - 非推奨のエイリアス ``elb_target_group_facts`` を削除します。代わりに ``elb_target_group_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:505 -msgid "iam - Removed deprecated ``community.aws.iam`` module. Please use ``community.aws.iam_user``, ``community.aws.iam_access_key`` or ``community.aws.iam_group`` (https://github.com/ansible-collections/community.aws/pull/839)." -msgstr "iam - 非推奨の ``community.aws.iam`` モジュールを削除しました。``community.aws.iam_user``、``community.aws.iam_access_key``、または ``community.aws.iam_group`` (https://github.com/ansible-collections/community.aws/pull/839) を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:506 -msgid "iam_cert_facts - Remove deprecated alias ``iam_cert_facts``. Please use ``iam_cert_info`` instead." -msgstr "iam_cert_facts - 非推奨のエイリアス ``iam_cert_facts`` を削除します。代わりに ``iam_cert_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:507 -msgid "iam_mfa_device_facts - Remove deprecated alias ``iam_mfa_device_facts``. Please use ``iam_mfa_device_info`` instead." -msgstr "iam_mfa_device_facts - 非推奨のエイリアス ``iam_mfa_device_facts`` を削除します。代わりに ``iam_mfa_device_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:508 -msgid "iam_role_facts - Remove deprecated alias ``iam_role_facts``. Please use ``iam_role_info`` instead." -msgstr "iam_role_facts - 非推奨のエイリアス ``iam_role_facts`` を削除します。代わりに ``iam_role_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:509 -msgid "iam_server_certificate_facts - Remove deprecated alias ``iam_server_certificate_facts``. Please use ``iam_server_certificate_info`` instead." -msgstr "iam_server_certificate_facts - 非推奨のエイリアス ``iam_server_certificate_facts`` を削除します。代わりに ``iam_server_certificate_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:510 -msgid "lambda_facts - Remove deprecated module lambda_facts``. Please use ``lambda_info`` instead." -msgstr "lambda_facts - 非推奨のモジュール lambda_facts を削除します。代わりに``. Please use ``lambda_info'' を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:511 -msgid "rds - Removed deprecated ``community.aws.rds`` module. Please use ``community.aws.rds_instance`` (https://github.com/ansible-collections/community.aws/pull/839)." -msgstr "RDS - 非推奨の ``community.aws.rds`` モジュールを削除しました。``community.aws.rds_instance`` を使用してください(https://github.com/ansible-collections/community.aws/pull/839)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:512 -msgid "rds_instance_facts - Remove deprecated alias ``rds_instance_facts``. Please use ``rds_instance_info`` instead." -msgstr "rds_instance_facts - 非推奨のエイリアス ``rds_instance_facts`` を削除します。代わりに ``rds_instance_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:513 -msgid "rds_snapshot_facts - Remove deprecated alias ``rds_snapshot_facts``. Please use ``rds_snapshot_info`` instead." -msgstr "rds_snapshot_facts - 非推奨のエイリアス ``rds_snapshot_facts`` を削除します。代わりに ``rds_snapshot_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:514 -msgid "redshift_facts - Remove deprecated alias ``redshift_facts``. Please use ``redshift_info`` instead." -msgstr "redshift_facts - 非推奨のエイリアス ``redshift_facts`` を削除します。代わりに ``redshift_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:515 -msgid "route53_facts - Remove deprecated alias ``route53_facts``. Please use ``route53_info`` instead." -msgstr "route53_facts - 非推奨のエイリアス ``route53_facts`` を削除します。代わりに ``route53_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:520 -msgid "Parts of this collection do not work with ansible-core 2.11 on Python 3.12+. Please either upgrade to ansible-core 2.12+, or use Python 3.11 or earlier (https://github.com/ansible-collections/community.general/pull/3988)." -msgstr "このコレクションの一部は、Python 3.12+ の ansible-core 2.11 では機能しません。ansible-core 2.12+ にアップグレードするか、Python 3.11 以前を使用してください (https://github.com/ansible-collections/community.general/pull/3988)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:521 -msgid "The symbolic links used to implement flatmapping for all modules were removed and replaced by ``meta/runtime.yml`` redirects. This effectively breaks compatibility with Ansible 2.9 for all modules (without using their \"long\" names, which is discouraged and which can change without previous notice since they are considered an implementation detail) (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "すべてのモジュールでフラットマッピングの実装に使用されるシンボリックリンクが削除され、``meta/runtime.yml`` リダイレクトに置き換えられました。これにより、すべてのモジュールの Ansible 2.9 との互換性が事実上失われます (非推奨であり、実装の詳細とみなされるため事前の通知なしに変更できる、「長い」名前は使用しません) (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:522 -msgid "a_module test plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "a_module テストプラグイン - Ansible 2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:523 -msgid "archive - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "archive - Ansible 2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:524 -msgid "git_config - remove Ansible 2.9 and early ansible-base 2.10 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "git_config - Ansible 2.9 および初期 ansible-base 2.10 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:525 -msgid "java_keystore - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "java_keystore - Ansible 2.9 互換コードを削除します(https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:526 -msgid "lists_mergeby and groupby_as_dict filter plugins - adjust filter plugin filename. This change is not visible to end-users, it only affects possible other collections importing Python paths (https://github.com/ansible-collections/community.general/pull/4625)." -msgstr "lists_mergeby および groupby_as_dict フィルタープラグイン - フィルタープラグインのファイル名を調整します。この変更はエンドユーザーには表示されませんが、Python パスをインポートする他のコレクションにのみ影響があります (https://github.com/ansible-collections/community.general/pull/4625)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:527 -msgid "lists_mergeby filter plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "lists_mergeby フィルタープラグイン - Ansible2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:528 -msgid "maven_artifact - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "maven_artifact - Ansible 2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:529 -msgid "memcached cache plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "memcached キャッシュプラグイン - Ansible2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:530 -msgid "path_join filter plugin shim - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "path_join フィルタープラグインshim _ Ansible 2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:531 -msgid "redis cache plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "redis キャッシュプラグイン - Ansible2.9 互換性コードを削除します (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:532 -msgid "yarn - remove unsupported and unnecessary ``--no-emoji`` flag (https://github.com/ansible-collections/community.general/pull/4662)." -msgstr "yarn - サポートされていない不要な ``--no-emoji`` フラグを削除します (https://github.com/ansible-collections/community.general/pull/4662)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:537 -msgid "mysql_replication - remove ``Is_Slave`` and ``Is_Master`` return values (were replaced with ``Is_Primary`` and ``Is_Replica`` (https://github.com/ansible-collections /community.mysql/issues/145)." -msgstr "mysql_replication - ``Is_Slave``と``Is_Master``戻り値を削除します (``Is_Primary`` と ``Is_Replica`` に置き換えられました (https://github.com/ansible-collections/community.mysql/issues/145))。" - -#: ../../rst/porting_guides/porting_guide_6.rst:538 -msgid "mysql_replication - remove the mode options values containing ``master``/``slave`` and the master_use_gtid option ``slave_pos`` (were replaced with corresponding ``primary``/``replica`` values) (https://github.com/ansible-collections/community.mysql/issues/145)." -msgstr "mysql_replication - ``master``/``slave`` および master_use_gtid オプション ``slave_pos`` (対応する ``primary``/``replica`` の値に置き換えられました) を含むモードオプション値を削除します (https://github.com/ansible-collections/community.mysql/issues/145)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:539 -msgid "mysql_user - remove support for the `REQUIRESSL` special privilege as it has ben superseded by the `tls_requires` option (https://github.com/ansible-collections/community.mysql/discussions/121)." -msgstr "mysql_user - `tls_requires` オプションに取って代わられた `REQUIRESSL` 特別権限のサポートを削除します (https://github.com/ansible-collections/community.mysql/discussions/121)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:540 -msgid "mysql_user - validate privileges using database engine directly (https://github.com/ansible-collections/community.mysql/issues/234 https://github.com/ansible-collections/community.mysql/pull/243). Do not validate privileges in this module anymore." -msgstr "mysql_user - データベースエンジンを直接使用して特権を検証します (https://github.com/ansible-collections/community.mysql/issues/234 https://github.com/ansible-collections/community.mysql/pull/243)。このモジュールの特権は、これ以上検証しないでください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:545 -msgid "The collection now requires at least ansible-core 2.11.0. Ansible 3 and before, and ansible-base versions are no longer supported." -msgstr "コレクションには、少なくとも ansible-core 2.11.0 が必要になります。Ansible 3 以前と、ansible-base バージョンはサポートされなくなりました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:546 -msgid "vmware_cluster_drs - The default for ``enable`` has been changed from ``false`` to ``true``." -msgstr "vmware_cluster_drs - ``enable`` のデフォルトが ``false`` から ``true`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:547 -msgid "vmware_cluster_drs - The parameter alias ``enable_drs`` has been removed, use ``enable`` instead." -msgstr "vmware_cluster_drs - パラメーターエイリアス ``enable_drs`` が削除されました。代わりに ``enable`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:548 -msgid "vmware_cluster_ha - The default for ``enable`` has been changed from ``false`` to ``true``." -msgstr "vmware_cluster_ha - ``enable`` のデフォルトが ``false`` から ``true`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:549 -msgid "vmware_cluster_ha - The parameter alias ``enable_ha`` has been removed, use ``enable`` instead." -msgstr "vmware_cluster_ha - パラメーターエイリアス ``enable_ha`` が削除されました。代わりに ``enable`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:550 -msgid "vmware_cluster_vsan - The default for ``enable`` has been changed from ``false`` to ``true``." -msgstr "vmware_cluster_vsan - ``enable`` のデフォルトが ``false`` から ``true`` に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:551 -msgid "vmware_cluster_vsan - The parameter alias ``enable_vsan`` has been removed, use ``enable`` instead." -msgstr "vmware_cluster_vsan - パラメーターエイリアス ``enable_vsan`` が削除されました。代わりに ``enable`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:552 -msgid "vmware_guest - Virtualization Based Security has some requirements (``nested_virt``, ``secure_boot`` and ``iommu``) that the module silently enabled. They have to be enabled explicitly now." -msgstr "vmware_guest - 仮想化ベースのセキュリティーには、モジュールが警告なしで有効にする要件 (``nested_virt``、``secure_boot``、および ``iommu``) がいくつかあります。これらは、明示的に有効にしなければならなくなりました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:557 -msgid "HTTPS SSL certificate validation is a **breaking change** and will require modification in the existing playbooks. Please refer to `SSL Certificate Validation `_ section in the `README.md `_ for modification to existing playbooks." -msgstr "HTTPS SSL 証明書の検証は**互換性を損なう変更**で、既存の Playbook への変更が必要になります。既存の Playbook の変更については、`README.md `_ の `SSL Certificate Validation `_ セクションを参照してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:562 -msgid "Set use_reports_api default value to true for the inventory plugin" -msgstr "インベントリープラグインの use_reports_api のデフォルト値を true に設定します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:563 -msgid "Support for Ansible 2.8 is removed" -msgstr "Ansible 2.8 のサポートが削除されました" - -#: ../../rst/porting_guides/porting_guide_6.rst:568 -msgid "Add a ``ansible-community`` CLI tool that allows to print the version of the Ansible community distribution. Use ``ansible-community --version`` to print this version." -msgstr "Ansible コミュニティーディストリビューションのバージョンを印刷できるようにする ``ansible-community`` CLI ツールを追加します。``ansible-community --version`` を使用してこのバージョンを出力します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:573 -msgid "Jinja2 Controller Requirement - Jinja2 3.0.0 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/75881)" -msgstr "Jinja2 コントローラーの要件 - コントロールノード (Ansible を実行するマシン) には Jinja2 3.0.0 以降が必要です (https://github.com/ansible/ansible/pull/75881)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:574 -msgid "Templating - remove ``safe_eval`` in favor of using ``NativeEnvironment`` but utilizing ``literal_eval`` only in cases when ``safe_eval`` was used (https://github.com/ansible/ansible/pull/75587)" -msgstr "テンプレート化 - ``NativeEnvironment`` の使用を優先して ``safe_eval`` を削除しますが、``safe_eval`` が使用された場合に限り ``literal_eval`` が使用されます (https://github.com/ansible/ansible/pull/75587)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:579 -msgid "amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574)." -msgstr "amazon.aws コレクション - amazon.aws コレクションでは ``botocore<1.19.0`` および ``boto3<1.16.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。古いバージョンの SDK を使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/amazon.aws/pull/574)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:584 -msgid "cli_parse - this module has been moved to the ansible.utils collection. ``ansible.netcommon.cli_parse`` will continue to work to reference the module in its new location, but this redirect will be removed in a future release" -msgstr "cli_parse - このモジュールは ansible.utils コレクションに移動されました。``ansible.netcommon.cli_parse`` は、引き続き機能して新しい場所のモジュールを参照しますが、このリダイレクトは今後のリリースで削除されます。" - -#: ../../rst/porting_guides/porting_guide_6.rst:585 -msgid "network_cli - Change default value of `ssh_type` option from `paramiko` to `auto`. This value will use libssh if the ansible-pylibssh module is installed, otherwise will fallback to paramiko." -msgstr "network_cli - `ssh_type` オプションのデフォルト値を `paramiko` から `auto` に変更します。この値は、ansible-pylibssh モジュールがインストールされている場合は libssh を使用し、それ以外の場合は paramiko にフォールバックします。" - -#: ../../rst/porting_guides/porting_guide_6.rst:590 -#: ../../rst/porting_guides/porting_guide_6.rst:602 -#: ../../rst/porting_guides/porting_guide_6.rst:608 -#: ../../rst/porting_guides/porting_guide_6.rst:615 -#: ../../rst/porting_guides/porting_guide_6.rst:745 -#: ../../rst/porting_guides/porting_guide_6.rst:751 -#: ../../rst/porting_guides/porting_guide_6.rst:757 -#: ../../rst/porting_guides/porting_guide_6.rst:769 -#: ../../rst/porting_guides/porting_guide_6.rst:776 -msgid "Minimum required ansible.netcommon version is 2.5.1." -msgstr "最低限必要な ansible.netcommon バージョンは 2.5.1 です。" - -#: ../../rst/porting_guides/porting_guide_6.rst:591 -#: ../../rst/porting_guides/porting_guide_6.rst:603 -#: ../../rst/porting_guides/porting_guide_6.rst:609 -#: ../../rst/porting_guides/porting_guide_6.rst:616 -#: ../../rst/porting_guides/porting_guide_6.rst:679 -#: ../../rst/porting_guides/porting_guide_6.rst:746 -#: ../../rst/porting_guides/porting_guide_6.rst:752 -#: ../../rst/porting_guides/porting_guide_6.rst:758 -#: ../../rst/porting_guides/porting_guide_6.rst:770 -#: ../../rst/porting_guides/porting_guide_6.rst:777 -msgid "Updated base plugin references to ansible.netcommon." -msgstr "ansible.netcommon へのベースプラグイン参照を更新しました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:592 -msgid "`eos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/arista.eos/issues/306)." -msgstr "`eos_facts` - デフォルトの gather_subset を `min` から `!config` に変更します (https://github.com/ansible-collections/arista.eos/issues/306)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:610 -msgid "facts - default value for gather_subset is changed to min instead of !config." -msgstr "facts - gather_subset のデフォルト値が !config の代わりに min に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:617 -msgid "`facts` - default value for `gather_subset` is changed to min instead of !config." -msgstr "`facts` - `gather_subset` のデフォルト値は、！config ではなく min に変更されています。" - -#: ../../rst/porting_guides/porting_guide_6.rst:622 -msgid "Update ciscoisesdk requirement to 1.2.0" -msgstr "ciscoisesdk 要件を 1.2.0 に更新" - -#: ../../rst/porting_guides/porting_guide_6.rst:623 -msgid "anc_endpoint_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "anc_endpoint_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:624 -msgid "anc_policy_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "anc_policy_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:625 -msgid "backup_last_status_info - change return value, it returns response content." -msgstr "backup_last_status_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:626 -msgid "device_administration_authentication_rules - deletes parameter identitySourceId." -msgstr "device_administration_authentication_rules - パラメーター identitySourceId を削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:627 -msgid "device_administration_authentication_rules_info - change return value, it returns response content." -msgstr "device_administration_authentication_rules_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:628 -msgid "device_administration_authorization_rules_info - change return value, it returns response content." -msgstr "device_administration_authorization_rules_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:629 -msgid "device_administration_conditions - deletes parameter attributeId." -msgstr "device_administration_conditions - パラメーター attributeId を削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:630 -msgid "device_administration_conditions_for_authentication_rule_info - change return value, it returns response content." -msgstr "device_administration_conditions_for_authentication_rule_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:631 -msgid "device_administration_conditions_for_authorization_rule_info - change return value, it returns response content." -msgstr "device_administration_conditions_for_authorization_rule_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:632 -msgid "device_administration_conditions_for_policy_set_info - change return value, it returns response content." -msgstr "device_administration_conditions_for_policy_set_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:633 -msgid "device_administration_conditions_info - change return value, it returns response content." -msgstr "device_administration_conditions_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:634 -msgid "device_administration_dictionary_attributes_authentication_info - change return value, it returns response content." -msgstr "device_administration_dictionary_attributes_authentication_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:635 -msgid "device_administration_dictionary_attributes_authorization_info - change return value, it returns response content." -msgstr "device_administration_dictionary_attributes_authorization_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:636 -msgid "device_administration_dictionary_attributes_policy_set_info - change return value, it returns response content." -msgstr "device_administration_dictionary_attributes_policy_set_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:637 -msgid "device_administration_global_exception_rules_info - change return value, it returns response content." -msgstr "device_administration_global_exception_rules_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:638 -msgid "device_administration_network_conditions_info - change return value, it returns response content." -msgstr "device_administration_network_conditions_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:639 -msgid "device_administration_time_date_conditions - deletes parameter attributeId." -msgstr "device_administration_time_date_conditions - パラメーター attributeId を削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:640 -msgid "device_administration_time_date_conditions_info - change return value, it returns response content." -msgstr "device_administration_time_date_conditions_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:641 -msgid "egress_matrix_cell_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "egress_matrix_cell_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:642 -msgid "network_access_authentication_rules - deletes parameter identitySourceId." -msgstr "network_access_authentication_rules - パラメーター identitySourceId を削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:643 -msgid "network_access_conditions - deletes parameter attributeId." -msgstr "network_access_conditions - パラメーター attributeId を削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:644 -msgid "network_access_time_date_conditions - deletes parameter attributeId." -msgstr "network_access_time_date_conditions - パラメーター attributeId を削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:645 -msgid "node_deployment - update parameters." -msgstr "node_deployment - パラメーターを更新します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:646 -msgid "node_deployment_info - add filter and filterType parameters." -msgstr "node_deployment_info - filter および filterType パラメーターを追加します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:647 -msgid "node_group - fixes response recollection." -msgstr "node_group - 応答の再コレクションを修正します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:648 -msgid "node_group_info - fixes response recollection." -msgstr "node_group_info - 応答の再コレクションを修正します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:649 -msgid "repository_files_info - change return value, it returns response content." -msgstr "repository_files_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:650 -msgid "repository_info - change return value, it returns response content." -msgstr "repository_info - 戻り値を変更します。応答コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:651 -msgid "sg_acl_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sg_acl_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:652 -msgid "sg_mapping_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sg_mapping_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:653 -msgid "sg_mapping_group_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sg_mapping_group_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:654 -msgid "sg_mapping_group_info - change return value, it returns BulkStatus content." -msgstr "sg_mapping_group_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:655 -msgid "sg_to_vn_to_vlan_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sg_to_vn_to_vlan_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:656 -msgid "sgt - change generationId type from int to str." -msgstr "Sgt - generationId タイプを int から str に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:657 -msgid "sgt_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sgt_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:658 -msgid "sxp_connections_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sxp_connections_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:659 -msgid "sxp_local_bindings_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sxp_local_bindings_bulk_monitor_status_info - 戻り値を変更し、BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:660 -msgid "sxp_vpns_bulk_monitor_status_info - change return value, it returns BulkStatus content." -msgstr "sxp_vpns_bulk_monitor_status_info - 戻り値を変更します。BulkStatus コンテンツを返します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:661 -msgid "system_certificate - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject." -msgstr "system_certificate - 新しいパラメーター portalTagTransferForSameSubject および roleTransferForSameSubject。" - -#: ../../rst/porting_guides/porting_guide_6.rst:662 -msgid "system_certificate - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject." -msgstr "system_certificate - portalTagTransferForSameSubject パラメーターの名前が allowPortalTagTransferForSameSubject に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:663 -msgid "system_certificate - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject." -msgstr "system_certificate - roleTransferForSameSubject パラメーターの名前が allowRoleTransferForSameSubject に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:664 -msgid "system_certificate_import - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject." -msgstr "system_certificate_import - 新しいパラメーター portalTagTransferForSameSubject および roleTransferForSameSubject。" - -#: ../../rst/porting_guides/porting_guide_6.rst:665 -msgid "system_certificate_import - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject." -msgstr "system_certificate_import - portalTagTransferForSameSubject パラメーターの名前が allowPortalTagTransferForSameSubject に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:666 -msgid "system_certificate_import - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject." -msgstr "system_certificate_import - roleTransferForSameSubject パラメーターの名前が allowRoleTransferForSameSubject に変更されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:667 -msgid "trustsec_nbar_app_info - change type from str to list." -msgstr "trustsec_nbar_app_info - タイプを str から list に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:668 -msgid "trustsec_vn_info - change type from str to list." -msgstr "trustsec_vn_info - タイプを str から list に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:678 -msgid "The minimum required ansible.netcommon version has been bumped to v2.6.1." -msgstr "最低限必要な ansible.netcommon バージョンが v2.6.1 に引き上げられました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:680 -msgid "`nxos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/cisco.nxos/issues/418)." -msgstr "`nxos_facts` - デフォルトの gather_subset を `min` から `!config` に変更します (https://github.com/ansible-collections/cisco.nxos/issues/418)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:681 -msgid "nxos_file_copy has been rewritten as a module. This change also removes the dependency on pexpect for file_pull operation. Since this now uses AnsibleModule class for argspec validation, the validation messages will be slighlty different. Expect changes in the return payload in some cases. All functionality remains unchanged." -msgstr "nxos_file_copy がモジュールとして書き直されました。この変更により、file_pull 操作の pexpect への依存もなくなります。これで argspec 検証に AnsibleModule クラスが使用されるようになったため、検証メッセージは少し異なります。場合によっては、リターンペイロードの変更が予想されます。すべての機能は変更されません。" - -#: ../../rst/porting_guides/porting_guide_6.rst:686 -msgid "community.aws collection - The community.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/809)." -msgstr "community.aws コレクション - community.aws コレクションでは ``botocore<1.19.0`` および ``boto3<1.16.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。SDK の古いバージョンを使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/community.aws/pull/809)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:687 -msgid "s3_bucket_notifications - refactor module to support SNS / SQS targets as well as the existing support for Lambda functions (https://github.com/ansible-collections/community.aws/issues/140)." -msgstr "s3_bucket_notifications - SNS/SQS ターゲットをサポートするモジュールと Lambda 関数の既存のサポートをリファクタリングします (https://github.com/ansible-collections/community.aws/issues/140)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:692 -msgid "The community.general collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove a lot of compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.general/pull/4548)." -msgstr "community.general コレクションは、Ansible 2.9 と ansible-base 2.10 をサポートしなくなりました。使用を防ぐための積極的な措置は講じていませんが、Ansible 2.9 の場合はこのコレクションのほとんどのコンテンツ、ansible-base 2.10 の場合はこのコレクションの一部のコンテンツの使用を効果的に防止する多数の互換性コードとその他の互換性措置を削除する予定です。Ansible 2.9 と ansible-base 2.10 は、どちらも間もなくライフサイクル終了日に達するため、いずれかを使用している場合は早急に ansible-core 2.11 以降にアップグレードすることを検討する必要があります (https://github.com/ansible-collections/community.general/pull/4548)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:702 -#: ../../rst/porting_guides/porting_guide_7.rst:619 -msgid "The community.network collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.network/pull/426)." -msgstr "community.network コレクションは、Ansible 2.9 と ansible-base 2.10 をサポートしなくなりました。使用を防ぐための積極的な措置は講じていませんが、Ansible 2.9 の場合はこのコレクションのほとんどのコンテンツ、ansible-base 2.10 の場合はこのコレクションの一部のコンテンツの使用を効果的に防止する互換性コードとその他の互換性措置を削除する予定です。Ansible 2.9 と ansible-base 2.10 は、どちらも間もなくライフサイクル終了日に達するため、いずれかを使用している場合は早急に ansible-core 2.11 以降にアップグレードすることを検討する必要があります (https://github.com/ansible-collections/community.network/pull/426)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:708 -msgid "postgresql_privs - the ``usage_on_types`` feature have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``type`` option with the ``type`` value to explicitly grant/revoke privileges on types (https://github.com/ansible-collections/community.postgresql/issues/207)." -msgstr "postgresql_privs - ``usage_on_types`` 機能は非推奨となり、``community.postgresql 3.0.0`` で削除されます。``type`` 値で ``type`` オプション を使用し、タイプの特権を明示的に付与/取り消してください (https://github.com/ansible-collections/community.postgresql/issues/207)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:709 -msgid "postgresql_query - the ``path_to_script`` and ``as_single_query`` options as well as the ``query_list`` and ``query_all_results`` return values have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``community.postgresql.postgresql_script`` module to execute statements from scripts (https://github.com/ansible-collections/community.postgresql/issues/189)." -msgstr "postgresql_query - ``path_to_script`` オプションと ``as_single_query`` オプション、および ``query_list`` と ``query_all_results`` の戻り値は非推奨となり、``community.postgresql 3.0.0`` で削除されます。``community.postgresql.postgresql_script`` モジュールを使用して、スクリプトからステートメントを実行してください (https://github.com/ansible-collections/community.postgresql/issues/189)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:710 -msgid "postgresql_query - the default value of the ``as_single_query`` option changes to ``yes``. If the related behavior of your tasks where the module is involved changes, please adjust the parameter's value correspondingly (https://github.com/ansible-collections/community.postgresql/issues/85)." -msgstr "postgresql_query - ``as_single_query`` オプションのデフォルト値が ``yes`` に変更されます。モジュールが関係するタスクの関連動作が変更される場合は、対応するパラメーターの値を適宜調整してください (https://github.com/ansible-collections/community.postgresql/issues/85)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:716 -msgid "Drop VCSIM as a test target (https://github.com/ansible-collections/community.vmware/pull/1294)." -msgstr "テストターゲットとして VCSIM を破棄します (https://github.com/ansible-collections/community.vmware/pull/1294)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:727 -msgid "All modules can read custom or organizational CA signed certificate from the environment variables. Please refer to `SSL Certificate Validation `_ section in the `README.md `_ for modification to existing playbooks or setting environment variable." -msgstr "すべてのモジュールは、環境変数からカスタムまたは組織 CA 署名証明書を読み取ることができます。既存の Playbook の変更や環境変数の設定については、`README.md `_ の `SSL Certificate Validation `_ セクションを参照してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:728 -msgid "All modules now support SSL over HTTPS and socket level timeout." -msgstr "すべてのモジュールが、SSL over HTTPS およびソケットレベルのタイムアウトをサポートするようになりました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:729 -msgid "idrac_server_config_profile - The module is enhanced to support export, import, and preview the SCP configuration using Redfish and added support for check mode." -msgstr "idrac_server_config_profile - モジュールは、Redfish を使用した SCP 設定のエクスポート、インポート、およびプレビューをサポートするように拡張され、チェックモードのサポートが追加されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:743 -msgid "frr.frr" -msgstr "frr.frr" - -#: ../../rst/porting_guides/porting_guide_6.rst:749 -msgid "ibm.qradar" -msgstr "ibm.qradar" - -#: ../../rst/porting_guides/porting_guide_6.rst:759 -msgid "`junos_facts` - change default gather_subset to `min` from `!config`." -msgstr "`junos_facts` - デフォルトの gather_subset を `min` から `!config` に変更します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:764 -msgid "manageiq - role removed (https://github.com/oVirt/ovirt-ansible-collection/pull/375)." -msgstr "pidgin - ロールが削除されました(https://github.com/oVirt/ovirt-ansible-collection/pull/375)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:767 -msgid "splunk.es" -msgstr "splunk.es" - -#: ../../rst/porting_guides/porting_guide_6.rst:778 -msgid "`vyos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/vyos.vyos/issues/231)." -msgstr "`vyos_facts` - デフォルトの gather_subset を `min` から `!config` に変更します (https://github.com/ansible-collections/vyos.vyos/issues/231)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:781 -#: ../../rst/porting_guides/porting_guide_7.rst:681 -msgid "Removed Collections" -msgstr "削除されたコレクション" - -#: ../../rst/porting_guides/porting_guide_6.rst:783 -msgid "community.kubernetes (previously included version: 2.0.1)" -msgstr "community.kubernetes (これまで含まれていたバージョン:2.0.1)" - -#: ../../rst/porting_guides/porting_guide_6.rst:784 -msgid "community.kubevirt (previously included version: 1.0.0)" -msgstr "community.kubevirt (これまで含まれていたバージョン:1.0.0)" - -#: ../../rst/porting_guides/porting_guide_6.rst:789 -msgid "The community.kubernetes collection has been removed from Ansible 6. It has been deprecated since Ansible 4.2, and version 2.0.0 included since Ansible 5 is only a set of deprecated redirects from community.kubernetes to kubernetes.core. If you still need the redirects, you can manually install community.kubernetes with ``ansible-galaxy collection install community.kubernetes`` (https://github.com/ansible-community/community-topics/issues/93)." -msgstr "community.kubernetes コレクションは Ansible 6 から削除されました。Ansible 4.2 以降は非推奨となり、Ansible5 が community.kubernetes から kubernetes.core への非推奨リダイレクトのセットであるためバージョン 2.0.0 が含まれています。それでもリダイレクトが必要な場合は、``ansible-galaxy collection install community.kubernetes`` で community.kubernetes を手動でインストールできます (https://github.com/ansible-community/community-topics/issues/93)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:790 -msgid "The community.kubevirt collection has been removed from Ansible 6. It has not been working with the community.kubernetes collection included since Ansible 5.0.0, and unfortunately nobody managed to adjust the collection to work with kubernetes.core >= 2.0.0. If you need to use this collection, you need to manually install community.kubernetes < 2.0.0 together with community.kubevirt with ``ansible-galaxy collection install community.kubevirt 'community.kubernetes:<2.0.0'`` (https://github.com/ansible-community/community-topics/issues/92)." -msgstr "community.kubevirt コレクションは Ansible 6 から削除されました。Ansible 5.0.0 以降に含まれている community.kubernetes コレクションでは機能していません。残念ながら、kubernetes.core>=2.0.0 で機能するようにコレクションを調整することはできませんでした。このコレクションを使用する必要がある場合は、2.0.0 より前の community.kubernetes を community.kubevirt と ``ansible-galaxy collection install community.kubevirt 'community.kubernetes:<2.0.0'`` と一緒に手動でインストールする必要があります (https://github.com/ansible-community/community-topics/issues/92)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:795 -msgid "Remove deprecated ``Templar.set_available_variables()`` method (https://github.com/ansible/ansible/issues/75828)" -msgstr "非推奨の ``Templar.set_available_variables()`` メソッドを削除します (https://github.com/ansible/ansible/issues/75828)" - -#: ../../rst/porting_guides/porting_guide_6.rst:796 -msgid "cli - remove deprecated ability to set verbosity before the sub-command (https://github.com/ansible/ansible/issues/75823)" -msgstr "cli - サブコマンドの前に冗長性を設定する非推奨の機能を削除します (https://github.com/ansible/ansible/issues/75823)" - -#: ../../rst/porting_guides/porting_guide_6.rst:797 -msgid "copy - remove deprecated ``thirsty`` alias (https://github.com/ansible/ansible/issues/75824)" -msgstr "copy - 非推奨の ``thirsty`` エイリアスを削除します (https://github.com/ansible/ansible/issues/75824)" - -#: ../../rst/porting_guides/porting_guide_6.rst:798 -msgid "psrp - Removed fallback on ``put_file`` with older ``pypsrp`` versions. Users must have at least ``pypsrp>=0.4.0``." -msgstr "PSRP - 古い ``put_file`` バージョンで ``pypsrp`` のフォールバックを削除しました。ユーザーは少なくとも ``pypsrp>=0.4.0`` が必要です。" - -#: ../../rst/porting_guides/porting_guide_6.rst:799 -msgid "url_argument_spec - remove deprecated ``thirsty`` alias for ``get_url`` and ``uri`` modules (https://github.com/ansible/ansible/issues/75825, https://github.com/ansible/ansible/issues/75826)" -msgstr "url_argument_spec - ``thirsty`` および ``get_url`` モジュールの非推奨の ``uri`` エイリアスを削除します (https://github.com/ansible/ansible/issues/75825、https://github.com/ansible/ansible/issues/75826)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:804 -msgid "ali_instance_info - removed the options ``availability_zone``, ``instance_ids``, and ``instance_names``. Use filter item ``zone_id`` instead of ``availability_zone``, filter item ``instance_ids`` instead of ``instance_ids``, and filter item ``instance_name`` instead of ``instance_names`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "ali_instance_info - オプション ``availability_zone``、``instance_ids``、および ``instance_names`` が削除されました。``availability_zone`` の代わりにフィルターアイテム ``zone_id``、``instance_ids`` の代わりにフィルターアイテム ``instance_ids``、``instance_names`` の代わりにフィルターアイテム ``instance_name`` を使用します (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:805 -msgid "apt_rpm - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "apt_rpm - ``update_cache`` の非推奨のエイリアス ``update-cache`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:806 -msgid "compose - removed various deprecated aliases. Use the version with ``_`` instead of ``-`` instead (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "Compose - 非推奨のさまざまなエイリアスを削除しました。このバージョンでは ``-`` の代わりに ``_`` を使用します (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:807 -msgid "dnsimple - remove support for dnsimple < 2.0.0 (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "dnsimple - dnsimple < 2.0.0 のサポートを削除します (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:808 -msgid "github_deploy_key - removed the deprecated alias ``2fa_token`` of ``otp`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "github_deploy_key - ``otp`` の 非推奨エイリアス ``2fa_token`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:809 -msgid "homebrew, homebrew_cask - removed the deprecated alias ``update-brew`` of ``update_brew`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "homebrew、homebrew_cask - ``update_brew`` の非推奨エイリアス ``update-brew`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:810 -msgid "linode - removed the ``backupsenabled`` option. Use ``backupweeklyday`` or ``backupwindow`` to enable backups (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "linode - ``backupsenabled`` オプションを削除しました。バックアップを有効にするには、``backupweeklyday`` または ``backupwindow`` を使用してください (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:811 -msgid "opkg - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "opkg - ``update_cache`` の 非推奨エイリアス ``update-cache`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:812 -msgid "pacman - if ``update_cache=true`` is used with ``name`` or ``upgrade``, the changed state will now also indicate if only the cache was updated. To keep the old behavior - only indicate ``changed`` when a package was installed/upgraded -, use ``changed_when`` as indicated in the module examples (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "pacman - ``update_cache=true`` が ``name`` または ``upgrade`` と使用されている場合、変更された状態はキャッシュのみが更新されているかどうかも示すようになりました。以前の動作 (パッケージのインストール/アップグレード時のみ ``changed`` を示す) を維持するには、モジュール例に示されているように ``changed_when`` を使用します (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:813 -msgid "pacman - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "pacman - ``update_cache`` の 非推奨エイリアス ``update-cache`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:814 -msgid "proxmox, proxmox_kvm, proxmox_snap - no longer allow to specify a VM name that matches multiple VMs. If this happens, the modules now fail (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "proxmox、proxmox_kvm、proxmox_snap - 複数の仮想マシンに一致する仮想マシン名を指定できなくなりました。これが発生した場合、モジュールは失敗します (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:815 -msgid "serverless - removed the ``functions`` option. It was not used by the module (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "serverless - ``functions`` オプションを削除しました。モジュールで使用されていませんでした (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:816 -msgid "slackpkg - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "slackpkg - ``update_cache`` の 非推奨エイリアス ``update-cache`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:817 -msgid "urpmi - removed the deprecated alias ``no-recommends`` of ``no_recommends`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "urpmi - ``no_recommends`` の 非推奨エイリアス ``no-recommends`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:818 -msgid "urpmi - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "urpmi - ``update_cache`` の 非推奨エイリアス ``update-cache`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:819 -msgid "xbps - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "xbps - ``update_cache`` の 非推奨エイリアス ``update-cache`` を削除しました (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:820 -msgid "xfconf - the ``get`` state has been removed. Use the ``xfconf_info`` module instead (https://github.com/ansible-collections/community.general/pull/4516)." -msgstr "xfconf - ``get`` 状態が削除されました。代わりに ``xfconf_info`` モジュールを使用してください (https://github.com/ansible-collections/community.general/pull/4516)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:825 -msgid "aws_iam auth - the deprecated alias ``aws_iam_login`` for the ``aws_iam`` value of the ``auth_method`` option has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/194)." -msgstr "aws_iam auth - ``auth_method`` オプションの ``aws_iam`` 値の非推奨エイリアス ``aws_iam_login`` は削除されました (https://github.com/ansible-collections/community.hashi_vault/issues/194)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:826 -msgid "community.hashi_vault collection - support for Ansible 2.9 and ansible-base 2.10 has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/189)." -msgstr "community.hashi_vault コレクション - Ansible 2.9 および ansible-base 2.10 のサポートが削除されました (https://github.com/ansible-collections/community.hashi_vault/issues/189)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:827 -msgid "hashi_vault lookup - the deprecated ``[lookup_hashi_vault]`` INI config section has been removed in favor of the collection-wide ``[hashi_vault_collection]`` section (https://github.com/ansible-collections/community.hashi_vault/issues/179)." -msgstr "hashi_vault ルックアップ - コレクション全体の ``[lookup_hashi_vault]`` セクションが優先されるため、非推奨の ``[hashi_vault_collection]`` INI 設定セクションが削除されました (https://github.com/ansible-collections/community.hashi_vault/issues/179)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:833 -#: ../../rst/porting_guides/porting_guide_7.rst:886 -msgid "aireos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "aireos モジュール - 非推奨の ``connection: local`` サポートが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:834 -#: ../../rst/porting_guides/porting_guide_7.rst:887 -msgid "aireos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "aireos モジュール - 非推奨の ``provider`` オプションが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:835 -#: ../../rst/porting_guides/porting_guide_7.rst:888 -msgid "aruba modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "aruba モジュール - 非推奨の ``connection: local`` サポートが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:836 -#: ../../rst/porting_guides/porting_guide_7.rst:889 -msgid "aruba modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "aruba モジュール - 非推奨の ``provider`` オプションが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:837 -#: ../../rst/porting_guides/porting_guide_7.rst:890 -msgid "ce modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "ce モジュール - 非推奨の ``connection: local`` サポートが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:838 -#: ../../rst/porting_guides/porting_guide_7.rst:891 -msgid "ce modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "ce モジュール - 非推奨の ``provider`` オプションが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:839 -#: ../../rst/porting_guides/porting_guide_7.rst:892 -msgid "enos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "enos モジュール - 非推奨の ``connection: local`` サポートが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:840 -#: ../../rst/porting_guides/porting_guide_7.rst:893 -msgid "enos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "enos モジュール - 非推奨の ``provider`` オプションが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:841 -#: ../../rst/porting_guides/porting_guide_7.rst:894 -msgid "ironware modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "ironware モジュール - 非推奨の ``connection: local`` サポートが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:842 -#: ../../rst/porting_guides/porting_guide_7.rst:895 -msgid "ironware modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "ironware モジュール - 非推奨の ``provider`` オプションが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:843 -#: ../../rst/porting_guides/porting_guide_7.rst:896 -msgid "sros modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "sros モジュール - 非推奨の ``connection: local`` サポートが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:844 -#: ../../rst/porting_guides/porting_guide_7.rst:897 -msgid "sros modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440)." -msgstr "sros モジュール - 非推奨の ``provider`` オプションが削除されました。代わりに ``connection: network_cli`` を使用してください (https://github.com/ansible-collections/community.network/pull/440)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:849 -msgid "vcenter_extension_facts - The deprecated module ``vcenter_extension_facts`` has been removed, use ``vcenter_extension_info`` instead." -msgstr "vcenter_extension_facts - 非推奨のモジュール ``vcenter_extension_facts`` が削除されました。代わりに ``vcenter_extension_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:850 -msgid "vmware_about_facts - The deprecated module ``vmware_about_facts`` has been removed, use ``vmware_about_info`` instead." -msgstr "vmware_about_facts - 非推奨のモジュール ``vmware_about_facts`` が削除されました。代わりに ``vmware_about_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:851 -msgid "vmware_category_facts - The deprecated module ``vmware_category_facts`` has been removed, use ``vmware_category_info`` instead." -msgstr "vmware_category_facts - 非推奨のモジュール ``vmware_category_facts`` が削除されました。代わりに ``vmware_category_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:852 -msgid "vmware_cluster - Remove DRS configuration in favour of module ``vmware_cluster_drs``." -msgstr "vmware_cluster - DRS 設定を削除し、モジュール ``vmware_cluster_drs`` を優先します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:853 -msgid "vmware_cluster - Remove HA configuration in favour of module ``vmware_cluster_ha``." -msgstr "vmware_cluster - HA 設定を削除し、モジュール ``vmware_cluster_ha`` を優先します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:854 -msgid "vmware_cluster - Remove VSAN configuration in favour of module ``vmware_cluster_vsan``." -msgstr "vmware_cluster - VSAN 設定を削除し、モジュール ``vmware_cluster_vsan`` を優先します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:855 -msgid "vmware_cluster_facts - The deprecated module ``vmware_cluster_facts`` has been removed, use ``vmware_cluster_info`` instead." -msgstr "vmware_cluster_facts - 非推奨のモジュール ``vmware_cluster_facts`` が削除されました。代わりに ``vmware_cluster_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:856 -msgid "vmware_datastore_facts - The deprecated module ``vmware_datastore_facts`` has been removed, use ``vmware_datastore_info`` instead." -msgstr "vmware_datastore_facts - 非推奨のモジュール ``vmware_datastore_facts`` が削除されました。代わりに ``vmware_datastore_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:857 -msgid "vmware_drs_group_facts - The deprecated module ``vmware_drs_group_facts`` has been removed, use ``vmware_drs_group_info`` instead." -msgstr "vmware_drs_group_facts - 非推奨のモジュール ``vmware_drs_group_facts`` が削除されました。代わりに ``vmware_drs_group_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:858 -msgid "vmware_drs_rule_facts - The deprecated module ``vmware_drs_rule_facts`` has been removed, use ``vmware_drs_rule_info`` instead." -msgstr "vmware_drs_rule_facts - 非推奨のモジュール ``vmware_drs_rule_facts`` が削除されました。代わりに ``vmware_drs_rule_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:859 -msgid "vmware_dvs_portgroup - The deprecated parameter ``portgroup_type`` has been removed, use ``port_binding`` instead." -msgstr "vmware_dvs_portgroup - 非推奨のパラメーター ``portgroup_type`` が削除されました。代わりに ``port_binding`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:860 -msgid "vmware_dvs_portgroup_facts - The deprecated module ``vmware_dvs_portgroup_facts`` has been removed, use ``vmware_dvs_portgroup_info`` instead." -msgstr "vmware_dvs_portgroup_facts - 非推奨のモジュール ``vmware_dvs_portgroup_facts`` が削除されました。代わりに ``vmware_dvs_portgroup_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:861 -msgid "vmware_guest_boot_facts - The deprecated module ``vmware_guest_boot_facts`` has been removed, use ``vmware_guest_boot_info`` instead." -msgstr "vmware_guest_boot_facts - 非推奨のモジュール ``vmware_guest_boot_facts`` が削除されました。代わりに ``vmware_guest_boot_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:862 -msgid "vmware_guest_customization_facts - The deprecated module ``vmware_guest_customization_facts`` has been removed, use ``vmware_guest_customization_info`` instead." -msgstr "vmware_guest_customization_facts - 非推奨のモジュール ``vmware_guest_customization_facts`` が削除されました。代わりに ``vmware_guest_customization_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:863 -msgid "vmware_guest_disk_facts - The deprecated module ``vmware_guest_disk_facts`` has been removed, use ``vmware_guest_disk_info`` instead." -msgstr "vmware_guest_disk_facts - 非推奨のモジュール ``vmware_guest_disk_facts`` が削除されました。代わりに ``vmware_guest_disk_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:864 -msgid "vmware_guest_facts - The deprecated module ``vmware_guest_facts`` has been removed, use ``vmware_guest_info`` instead." -msgstr "vmware_guest_facts - 非推奨のモジュール ``vmware_guest_facts`` が削除されました。代わりに ``vmware_guest_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:865 -msgid "vmware_guest_snapshot_facts - The deprecated module ``vmware_guest_snapshot_facts`` has been removed, use ``vmware_guest_snapshot_info`` instead." -msgstr "vmware_guest_snapshot_facts - 非推奨のモジュール ``vmware_guest_snapshot_facts`` が削除されました。代わりに ``vmware_guest_snapshot_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:866 -msgid "vmware_host_capability_facts - The deprecated module ``vmware_host_capability_facts`` has been removed, use ``vmware_host_capability_info`` instead." -msgstr "vmware_host_capability_facts - 非推奨のモジュール ``vmware_host_capability_facts`` が削除されました。代わりに ``vmware_host_capability_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:867 -msgid "vmware_host_config_facts - The deprecated module ``vmware_host_config_facts`` has been removed, use ``vmware_host_config_info`` instead." -msgstr "vmware_host_config_facts - 非推奨のモジュール ``vmware_host_config_facts`` が削除されました。代わりに ``vmware_host_config_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:868 -msgid "vmware_host_dns_facts - The deprecated module ``vmware_host_dns_facts`` has been removed, use ``vmware_host_dns_info`` instead." -msgstr "vmware_host_dns_facts - 非推奨のモジュール ``vmware_host_dns_facts`` が削除されました。代わりに ``vmware_host_dns_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:869 -msgid "vmware_host_feature_facts - The deprecated module ``vmware_host_feature_facts`` has been removed, use ``vmware_host_feature_info`` instead." -msgstr "vmware_host_feature_facts - 非推奨のモジュール ``vmware_host_feature_facts`` が削除されました。代わりに ``vmware_host_feature_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:870 -msgid "vmware_host_firewall_facts - The deprecated module ``vmware_host_firewall_facts`` has been removed, use ``vmware_host_firewall_info`` instead." -msgstr "vmware_host_firewall_facts - 非推奨のモジュール ``vmware_host_firewall_facts`` が削除されました。代わりに ``vmware_host_firewall_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:871 -msgid "vmware_host_ntp_facts - The deprecated module ``vmware_host_ntp_facts`` has been removed, use ``vmware_host_ntp_info`` instead." -msgstr "vmware_host_ntp_facts - 非推奨のモジュール ``vmware_host_ntp_facts`` が削除されました。代わりに ``vmware_host_ntp_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:872 -msgid "vmware_host_package_facts - The deprecated module ``vmware_host_package_facts`` has been removed, use ``vmware_host_package_info`` instead." -msgstr "vmware_host_package_facts - 非推奨のモジュール ``vmware_host_package_facts`` が削除されました。代わりに ``vmware_host_package_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:873 -msgid "vmware_host_service_facts - The deprecated module ``vmware_host_service_facts`` has been removed, use ``vmware_host_service_info`` instead." -msgstr "vmware_host_service_facts - 非推奨のモジュール ``vmware_host_service_facts`` が削除されました。代わりに ``vmware_host_service_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:874 -msgid "vmware_host_ssl_facts - The deprecated module ``vmware_host_ssl_facts`` has been removed, use ``vmware_host_ssl_info`` instead." -msgstr "vmware_host_ssl_facts - 非推奨のモジュール ``vmware_host_ssl_facts`` が削除されました。代わりに ``vmware_host_ssl_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:875 -msgid "vmware_host_vmhba_facts - The deprecated module ``vmware_host_vmhba_facts`` has been removed, use ``vmware_host_vmhba_info`` instead." -msgstr "vmware_host_vmhba_facts - 非推奨のモジュール ``vmware_host_vmhba_facts`` が削除されました。代わりに ``vmware_host_vmhba_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:876 -msgid "vmware_host_vmnic_facts - The deprecated module ``vmware_host_vmnic_facts`` has been removed, use ``vmware_host_vmnic_info`` instead." -msgstr "vmware_host_vmnic_facts - 非推奨のモジュール ``vmware_host_vmnic_facts`` が削除されました。代わりに ``vmware_host_vmnic_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:877 -msgid "vmware_local_role_facts - The deprecated module ``vmware_local_role_facts`` has been removed, use ``vmware_local_role_info`` instead." -msgstr "vmware_local_role_facts - 非推奨のモジュール ``vmware_local_role_facts`` が削除されました。代わりに ``vmware_local_role_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:878 -msgid "vmware_local_user_facts - The deprecated module ``vmware_local_user_facts`` has been removed, use ``vmware_local_user_info`` instead." -msgstr "vmware_local_user_facts - 非推奨のモジュール ``vmware_local_user_facts`` が削除されました。代わりに ``vmware_local_user_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:879 -msgid "vmware_portgroup_facts - The deprecated module ``vmware_portgroup_facts`` has been removed, use ``vmware_portgroup_info`` instead." -msgstr "vmware_portgroup_facts - 非推奨のモジュール ``vmware_portgroup_facts`` が削除されました。代わりに ``vmware_portgroup_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:880 -msgid "vmware_resource_pool_facts - The deprecated module ``vmware_resource_pool_facts`` has been removed, use ``vmware_resource_pool_info`` instead." -msgstr "vmware_resource_pool_facts - 非推奨のモジュール ``vmware_resource_pool_facts`` が削除されました。代わりに ``vmware_resource_pool_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:881 -msgid "vmware_tag_facts - The deprecated module ``vmware_tag_facts`` has been removed, use ``vmware_tag_info`` instead." -msgstr "vmware_tag_facts - 非推奨のモジュール ``vmware_tag_facts`` が削除されました。代わりに ``vmware_tag_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:882 -msgid "vmware_target_canonical_facts - The deprecated module ``vmware_target_canonical_facts`` has been removed, use ``vmware_target_canonical_info`` instead." -msgstr "vmware_target_canonical_facts - 非推奨のモジュール ``vmware_target_canonical_facts`` が削除されました。代わりに ``vmware_target_canonical_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:883 -msgid "vmware_vm_facts - The deprecated module ``vmware_vm_facts`` has been removed, use ``vmware_vm_info`` instead." -msgstr "vmware_vm_facts - 非推奨のモジュール ``vmware_vm_facts`` が削除されました。代わりに ``vmware_vm_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:884 -msgid "vmware_vmkernel_facts - The deprecated module ``vmware_vmkernel_facts`` has been removed, use ``vmware_vmkernel_info`` instead." -msgstr "vmware_vmkernel_facts - 非推奨のモジュール ``vmware_vmkernel_facts`` が削除されました。代わりに ``vmware_vmkernel_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:885 -msgid "vmware_vmkernel_ip_config - The deprecated module ``vmware_vmkernel_ip_config`` has been removed, use ``vmware_vmkernel`` instead." -msgstr "vmware_vmkernel_ip_config - 非推奨のモジュール ``vmware_vmkernel_ip_config`` が削除されました。代わりに ``vmware_vmkernel`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:886 -msgid "vmware_vswitch_facts - The deprecated module ``vmware_vswitch_facts`` has been removed, use ``vmware_vswitch_info`` instead." -msgstr "vmware_vswitch_facts - 非推奨のモジュール ``vmware_vswitch_facts`` が削除されました。代わりに ``vmware_vswitch_info`` を使用してください。" - -#: ../../rst/porting_guides/porting_guide_6.rst:896 -msgid "ansible-core - Remove support for Python 2.6." -msgstr "ansible-core - Python2.6 のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:897 -msgid "ansible-test - Remove support for Python 2.6." -msgstr "ansible-test - Python 2.6 のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:898 -msgid "ssh connection plugin option scp_if_ssh in favor of ssh_transfer_method." -msgstr "ssh 接続プラグインオプション scp_if_ssh で ssh_transfer_method を優先します。" - -#: ../../rst/porting_guides/porting_guide_6.rst:903 -#: ../../rst/porting_guides/porting_guide_7.rst:975 -msgid "ec2_instance - The default value for ```instance_type``` has been deprecated, in the future release you must set an instance_type or a launch_template (https://github.com/ansible-collections/amazon.aws/pull/587)." -msgstr "ec2_instance - '``instance_type``' のデフォルト値は非推奨となり、今後のリリースで instance_type または launch_template を設定する必要があります (https://github.com/ansible-collections/amazon.aws/pull/587)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:904 -msgid "module_utils - support for the original AWS SDK `boto` has been deprecated in favour of the `boto3`/`botocore` SDK. All `boto` based modules have either been deprecated or migrated to `botocore`, and the remaining support code in module_utils will be removed in release 4.0.0 of the amazon.aws collection. Any modules outside of the amazon.aws and community.aws collections based on the `boto` library will need to be migrated to the `boto3`/`botocore` libraries (https://github.com/ansible-collections/amazon.aws/pull/575)." -msgstr "module_utils - 元の AWS SDK `boto` のサポートが非推奨となり、`boto3`/`botocore` SDK が採用されました。`boto` ベースのモジュールはすべて非推奨になるか、`botocore` に移行されており、module_utils の残りのサポートコードは amazon.aws コレクションのリリース 4.0.0 で削除されます。`boto` ライブラリーに基づいた amazon.aws コレクションおよび community.aws コレクション以外のモジュールは、`boto3`/`botocore` ライブラリーに移行する必要があります (https://github.com/ansible-collections/amazon.aws/pull/575)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:910 -msgid "ios_acls - Deprecated fragment attribute added boolean alternate as enable_fragment." -msgstr "ios_acls - 非推奨のフラグメント属性により、enable_fragment としてブール値代替が追加されました。" - -#: ../../rst/porting_guides/porting_guide_6.rst:933 -msgid "ansible_galaxy_install - deprecated support for ``ansible`` 2.9 and ``ansible-base`` 2.10 (https://github.com/ansible-collections/community.general/pull/4601)." -msgstr "ansible_galaxy_install - ``ansible`` 2.9 および ``ansible-base`` 2.10 のサポートが非推奨になりました (https://github.com/ansible-collections/community.general/pull/4601)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:934 -msgid "dig lookup plugin - the ``DLV`` record type has been decommissioned in 2017 and support for it will be removed from community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4618)." -msgstr "dig lookup プラグイン - 2017 年に非推奨となった ``DLV`` レコードタイプのサポートが community.general 6.0.0 から削除されます (https://github.com/ansible-collections/community.general/pull/4618)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:935 -msgid "gem - the default of the ``norc`` option has been deprecated and will change to ``true`` in community.general 6.0.0. Explicitly specify a value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/4517)." -msgstr "gem - ``norc``オプションのデフォルトは廃止され、community.general6.0.0 で ``true`` に変更されます。非推奨の警告を防ぐために、値を明示的に指定します (https://github.com/ansible-collections/community.general/pull/4517)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:941 -msgid "vmadm - deprecated module parameter ``debug`` that was not used anywhere (https://github.com/ansible-collections/community.general/pull/4580)." -msgstr "vmadm - どこにも使用されていない非推奨のモジュールパラメーター ``debug`` (https://github.com/ansible-collections/community.general/pull/4580)。" - -#: ../../rst/porting_guides/porting_guide_6.rst:949 -msgid "token_validate options - the shared auth option ``token_validate`` will change its default from ``true`` to ``false`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``true`` (https://github.com/ansible-collections/community.hashi_vault/issues/248)." -msgstr "token_validate オプション - 共有認証オプション ``token_validate`` のデフォルトは、community.hashi_vault バージョン 4.0.0 で ``true`` から ``false`` に変更されます。``vault_login`` ルックアップおよびモジュールは、デフォルト値の ``true`` を保持します (https://github.com/ansible-collections/community.hashi_vault/issues/248)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:8 -msgid "Ansible 7 Porting Guide" -msgstr "Ansible 7 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_7.rst:15 -msgid "Ansible 7 is based on Ansible-core 2.14." -msgstr "Ansible 7 は Ansible-core 2.14 をベースにしています。" - -#: ../../rst/porting_guides/porting_guide_7.rst:18 -msgid "We suggest you read this page along with the `Ansible 7 Changelog `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて `Ansible 7 Changelog `_ を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_7.rst:24 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:22 -msgid "Variables are now evaluated lazily; only when they are actually used. For example, in ansible-core 2.14 an expression ``{{ defined_variable or undefined_variable }}`` does not fail on ``undefined_variable`` if the first part of ``or`` is evaluated to ``True`` as it is not needed to evaluate the second part. One particular case of a change in behavior to note is the task below which uses the ``undefined`` test. Prior to version 2.14 this would result in a fatal error trying to access the undefined value in the dictionary. In 2.14 the assertion passes as the dictionary is evaluated as undefined through one of its undefined values:" -msgstr "変数は、実際に使用する場合のみ、遅延評価されるようになりました。たとえば、ansible-core 2.14 では、``or`` の最初の部分が ``True`` と評価されている場合、式 ``{{ defined_variable or undefined_variable }}`` は ``undefined_variable`` で失敗しません。これは、2 番目の部分を評価する必要がないためです。動作の変化で特に注意すべきは、``undefined`` テストを使用した以下のタスクです。バージョン 2.14 より前では、ディクショナリー内の未定義の値にアクセスしようとすると、致命的なエラーが発生していました。2.14 では、ディクショナリーが未定義の値の 1 つを介して未定義として評価されると、アサーションが渡されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:42 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:40 -msgid "Python 3.9 on the controller node is a hard requirement for this release." -msgstr "コントローラーノードの Python 3.9 は、本リリースではハード要件になります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:43 -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:41 -msgid "At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. If you were previously using the ``C`` or ``POSIX`` locale, you may be able to use ``C.UTF-8``. If you were previously using a locale such as ``en_US.ISO-8859-1``, you may be able to use ``en_US.UTF-8``. For simplicity it may be easiest to export the appropriate locale using the ``LC_ALL`` environment variable. An alternative to modifying your system locale is to run Python in UTF-8 mode; See the `Python documentation `_ for more information." -msgstr "起動時に、ファイルシステムのエンコーディングとロケールがチェックされ、UTF-8 であることが確認されます。確認しない場合、プロセスは誤ったエンコーディングを報告するエラーで終了します。以前に ``C`` また ``POSIX`` ロケールを使用していた場合は、``C.UTF-8`` を使用できる場合があります。以前に ``en_US.ISO-8859-1`` のようなロケールを使用していた場合は、``en_US.UTF-8`` を使用できる場合があります。簡単にするために、``LC_ALL`` 環境変数をしようして、適切なロケールをエクスポートすることが最も簡単かもしれません。システムロケールを変更する代わりに、Python を UTF-8 モードで実行することもできます。詳細は、`Python documentation `_ を参照してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:96 -msgid "Porting Guide for v7.2.0" -msgstr "v7.2.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_7.rst:101 -msgid "dellemc.powerflex (version 1.5.0)" -msgstr "dellemc.powerflex (バージョン 1.5.0)" - -#: ../../rst/porting_guides/porting_guide_7.rst:102 -msgid "dellemc.unity (version 1.5.0)" -msgstr "dellemc.unity (バージョン 1.5.0)" - -#: ../../rst/porting_guides/porting_guide_7.rst:110 -msgid "ansible-test - Additional configuration may be required for certain container host and container combinations. Further details are available in the testing documentation." -msgstr "ansible-test - 特定のコンテナーホストとコンテナーの組み合わせでは、追加の設定が必要になる場合があります。詳細については、テストドキュメントを参照してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:111 -msgid "ansible-test - Custom containers with ``VOLUME`` instructions may be unable to start, when previously the containers started correctly. Remove the ``VOLUME`` instructions to resolve the issue. Containers with this condition will cause ``ansible-test`` to emit a warning." -msgstr "ansible-test - ``VOLUME`` 指示のあるカスタムコンテナーは、以前はコンテナーが正しく起動していた場合、開始できない場合があります。``VOLUME`` 指示を取り外し、問題を解決してください。この状態のコンテナーは ``ansible-test`` の原因となり、警告を発します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:112 -msgid "ansible-test - Systems with Podman networking issues may be unable to run containers, when previously the issue went unreported. Correct the networking issues to continue using ``ansible-test`` with Podman." -msgstr "ansible-test - 以前は問題が報告されていなかった場合、Podman ネットワークの問題があるシステムはコンテナーを実行できない可能性があります。Podman で ``ansible-test`` を引き続き使用するには、ネットワークの問題を修正してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:113 -msgid "ansible-test - Using Docker on systems with SELinux may require setting SELinux to permissive mode. Podman should work with SELinux in enforcing mode." -msgstr "ansible-test - SELinux を搭載したシステムで Docker を使用するには、SELinux を Permissive モードに設定する必要がある場合があります。Podman は、Enforcing モードで SELinux と連携する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:118 -msgid "meraki_network - Updated documentation for `local_status_page_enabled` and `remote_status_page_enabled` as these no longer work." -msgstr "meraki_network - `local_status_page_enabled` および `remote_status_page_enabled` は機能しなくなったので、これらに関するドキュメントを更新しました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:126 -msgid "ModuleHelper module utils - when the module sets output variables named ``msg``, ``exception``, ``output``, ``vars``, or ``changed``, the actual output will prefix those names with ``_`` (underscore symbol) only when they clash with output variables generated by ModuleHelper itself, which only occurs when handling exceptions. Please note that this breaking change does not require a new major release since before this release, it was not possible to add such variables to the output `due to a bug `__ (https://github.com/ansible-collections/community.general/pull/5765)." -msgstr "ModuleHelper module utils - モジュールセットが、``msg``、``exception``、``output``、``vars``、または ``changed`` という名前の変数を出力すると、実際の出力では、これらの名前の前に ``_`` (アンダースコア記号) が付けられます。これは、ModuleHelper そのものによって生成された出力変数とクラッシュする時のみに付けられ、例外を処理するときにのみ発生します。この重大な変更には新しいメジャーリリースは必要ないことに注意してください。このリリースより前は、`due to a bug `__ により、そのような変数を出力に追加することができなかったからです (https://github.com/ansible-collections/community.general/pull/5765)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:134 -msgid "ansible-test - Docker Desktop on WSL2 is now supported (additional configuration required)." -msgstr "ansible-test - Docker Desktop on WSL2 がサポートされるようになりました (追加の設定が必要です)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:135 -msgid "ansible-test - Docker and Podman are now supported on hosts with cgroup v2 unified. Previously only cgroup v1 and cgroup v2 hybrid were supported." -msgstr "ansible-test - cgroup v2 が統合されたホストで Docker と Podman がサポートされるようになりました。以前は、cgroup v1 および cgroup v2 ハイブリッドのみがサポートされていました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:136 -msgid "ansible-test - Podman now works on container hosts without systemd. Previously only some containers worked, while others required rootfull or rootless Podman, but would not work with both. Some containers did not work at all." -msgstr "ansible-test - Podman が systemd のないコンテナーホストで動作するようになりました。以前は、一部のコンテナーのみが動作し、他のコンテナーは rootfull または rootless Podman を必要としていましたが、両方では動作しませんでした。まったく動作しないコンテナーもありました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:137 -msgid "ansible-test - Podman on WSL2 is now supported." -msgstr "ansible-test - WSL2 の Podman がサポートされるようになりました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:138 -msgid "ansible-test - When additional cgroup setup is required on the container host, this will be automatically detected. Instructions on how to configure the host will be provided in the error message shown." -msgstr "ansible-test - コンテナーホストで追加の cgroup セットアップが必要な場合、これは自動的に検出されます。ホストの設定方法については、表示されるエラーメッセージに記載されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:143 -msgid "Set the minimum Ansible version supported by this collection to Ansible 2.12" -msgstr "このコレクションでサポートされる Ansible の最小バージョンを Ansible 2.12 に設定します" - -#: ../../rst/porting_guides/porting_guide_7.rst:148 -msgid "win_chocolatey - Allow users to select the TLS versions used for bootstrapping Chocolatey installation." -msgstr "win_chocolatey - Chocolatey インストールのブートストラップに使用する TLS バージョンをユーザーが選択できるようにします。" - -#: ../../rst/porting_guides/porting_guide_7.rst:153 -msgid "The cisco.nso collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/155)." -msgstr "cisco.nso コレクションはメンテナンスされていないと見なされ、Ansible 9 より先に再びメンテナンスを開始する人がいない場合は、Ansible 9 から削除されます。`the removal process for details on how this works `__ を参照してください (https://github.com/ansible-community/community-topics/issues/155)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:154 -msgid "The community.fortios collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/162)." -msgstr "community.fortios コレクションはメンテナンスされていないと見なされ、Ansible 9 より先に再びメンテナンスを開始する人がいない場合、Ansible 9 から削除されます。`the removal process for details on how this works `__ を参照してください (https://github.com/ansible-community/community-topics/issues/162)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:155 -msgid "The community.google collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/160)." -msgstr "community.google コレクションはメンテナンスされていないと見なされ、Ansible 9 より先に再びメンテナンスを開始する人がいない場合、Ansible 9 から削除されます。`the removal process for details on how this works `__ を参照してください (https://github.com/ansible-community/community-topics/issues/160)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:156 -msgid "The community.skydive collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/171)." -msgstr "community.skydive コレクションはメンテナンスされていないと見なされ、Ansible 9 より先に再びメンテナンスを開始する人がいない場合、Ansible 9 から削除されます。`the removal process for details on how this works `__ を参照してください (https://github.com/ansible-community/community-topics/issues/171)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:161 -msgid "win_chocolatey - Deprecate side-by-side installs." -msgstr "win_chocolatey - サイドバイサイド方式のインストールを廃止します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:166 -msgid "ios_bgp_address_family - deprecate neighbors.address/tag/ipv6_adddress with neighbor_address which enables common attributes for facts rendering" -msgstr "ios_bgp_address_family - neighbors.address/tag/ipv6_addaddress を非推奨にし、ファクトレンダリングの共通属性を有効にする neighbor_address を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:167 -msgid "ios_bgp_address_family - deprecate neighbors.password with password_options which allows encryption and password" -msgstr "ios_bgp_address_family - 暗号化とパスワードを許可する password_options を使用して、neighbors.password を非推奨にします" - -#: ../../rst/porting_guides/porting_guide_7.rst:168 -msgid "ios_bgp_address_family - deprecate slow_peer with slow_peer_options which supports a dict attribute" -msgstr "ios_bgp_address_family - dict 属性をサポートする slow_peer_options を持つ slow_peer を非推奨にします" - -#: ../../rst/porting_guides/porting_guide_7.rst:173 -msgid "The default of the newly added option ``txt_character_encoding`` will change from ``octal`` to ``decimal`` in community.dns 3.0.0. The new default will be compatible with `RFC 1035 `__ (https://github.com/ansible-collections/community.dns/pull/134)." -msgstr "新しく追加されたオプション ``txt_character_encoding``は、community.dns 3.0.0 で ``octal`` から ``decimal`` へ変更します。新しいデフォルトは `RFC 1035 `__ と互換性があります (https://github.com/ansible-collections/community.dns/pull/134)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:178 -msgid "consul - deprecate using parameters unused for ``state=absent`` (https://github.com/ansible-collections/community.general/pull/5772)." -msgstr "consul - ``state=absent`` の未使用であるパラメーターの使用は非推奨となります (https://github.com/ansible-collections/community.general/pull/5772)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:179 -msgid "gitlab_runner - the default of the new option ``access_level_on_creation`` will change from ``false`` to ``true`` in community.general 7.0.0. This will cause ``access_level`` to be used during runner registration as well, and not only during updates (https://github.com/ansible-collections/community.general/pull/5908)." -msgstr "gitlab_runner - 新しいオプションのデフォルト ``access_level_on_creation`` は、community.general 7.0.0 で ``false`` から ``true`` へ変更されます。これにより、``access_level`` は更新時だけでなく、ランナー登録時にも使用されることになります (https://github.com/ansible-collections/community.general/pull/5908)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:180 -msgid "manageiq_policies - deprecate ``state=list`` in favour of using ``community.general.manageiq_policies_info`` (https://github.com/ansible-collections/community.general/pull/5721)." -msgstr "manageiq_policies - ``state=list`` を非推奨とし、``community.general.manageiq_policies_info`` を使用します (https://github.com/ansible-collections/community.general/pull/5721)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:181 -msgid "rax - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:182 -msgid "rax_cbs - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_cbs - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:183 -msgid "rax_cbs_attachments - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_cbs_attachments - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:184 -msgid "rax_cdb - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_cdb - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:185 -msgid "rax_cdb_database - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_cdb_database - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:186 -msgid "rax_cdb_user - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_cdb_user - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:187 -msgid "rax_clb - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_clb - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:188 -msgid "rax_clb_nodes - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_clb_nodes - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:189 -msgid "rax_clb_ssl - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_clb_ssl - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:190 -msgid "rax_dns - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_dns - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:191 -msgid "rax_dns_record - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_dns_record - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:192 -msgid "rax_facts - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_facts - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:193 -msgid "rax_files - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_files - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:194 -msgid "rax_files_objects - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_files_objects - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:195 -msgid "rax_identity - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_identity - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:196 -msgid "rax_keypair - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_keypair - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:197 -msgid "rax_meta - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_meta - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:198 -msgid "rax_mon_alarm - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_mon_alarm - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:199 -msgid "rax_mon_check - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_mon_check - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:200 -msgid "rax_mon_entity - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_mon_entity - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:201 -msgid "rax_mon_notification - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_mon_notification - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:202 -msgid "rax_mon_notification_plan - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_mon_notification_plan - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:203 -msgid "rax_network - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_network - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:204 -msgid "rax_queue - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_queue - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:205 -msgid "rax_scaling_group - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_scaling_group - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:206 -msgid "rax_scaling_policy - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733)." -msgstr "rax_scaling_policy - モジュールは、非推奨のライブラリー ``pyrax`` に依存しています。メンテナーがこのモジュールに取り組むための対策をとらない限り、これは community.general 7.0.0 で非推奨としてマークされ、バージョン 9.0.0 で削除されます (https://github.com/ansible-collections/community.general/pull/5733)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:211 -msgid "ansible-core - support for ``ansible-core`` versions ``2.11`` and ``2.12`` will be dropped in collection version ``5.0.0``, making ``2.13`` the minimum supported version of ``ansible-core`` (https://github.com/ansible-collections/community.hashi_vault/issues/340)." -msgstr "ansible-core - のサポート``ansible-core`` バージョン ``2.11`` と ``2.12`` のサポートは、コレクションバージョン ``5.0.0`` で削除されます。これにより、``2.13`` が ``ansible-core`` のサポートされている最小バージョンとなります (https://github.com/ansible-collections/community.hashi_vault/issues/340)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:212 -msgid "hvac - the minimum version of ``hvac`` to be supported in collection version ``5.0.0`` will be at least ``1.0.2``; this minimum may be raised before ``5.0.0`` is released, so please subscribe to the linked issue and look out for new notices in the changelog (https://github.com/ansible-collections/community.hashi_vault/issues/324)." -msgstr "hvac - コレクションバージョン ``5.0.0`` でサポートされる予定の ``hvac`` の最小バージョンは、少なくとも ``1.0.2`` です。この最小バージョンは、``5.0.0`` がリリースされる前に引き上げられる可能性がありますので、リンクされている問題にサブスクライブし、changelog で新しい通知に注意してください (https://github.com/ansible-collections/community.hashi_vault/issues/324)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:215 -msgid "Porting Guide for v7.1.0" -msgstr "v7.1.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_7.rst:220 -msgid "grafana.grafana (version 1.1.0)" -msgstr "grafana.grafana (バージョン 1.1.0)" - -#: ../../rst/porting_guides/porting_guide_7.rst:263 -msgid "The ``sap`` modules ``sapcar_extract``, ``sap_task_list_execute``, and ``hana_query``, will be removed from this collection in community.general 7.0.0 and replaced with redirects to ``community.sap_libs``. If you want to continue using these modules, make sure to also install ``community.sap_libs`` (it is part of the Ansible package) (https://github.com/ansible-collections/community.general/pull/5614)." -msgstr "``sap`` モジュールの ``sapcar_extract``、``sap_task_list_execute``、および ``hana_query`` は、community.general 7.0.0 でこのコレクションから削除され、``community.sap_libs`` へのリダイレクトに置き換えられます。これらのモジュールを引き続き使用する場合は、必ず ``community.sap_libs`` もインストールしてください (これは Ansible パッケージの一部です) (https://github.com/ansible-collections/community.general/pull/5614)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:266 -msgid "Porting Guide for v7.0.0" -msgstr "v7.0.0 の移植ガイド" - -#: ../../rst/porting_guides/porting_guide_7.rst:271 -msgid "ibm.spectrum_virtualize (version 1.10.0)" -msgstr "ibm.spectrum_virtualize (version 1.10.0)" - -#: ../../rst/porting_guides/porting_guide_7.rst:272 -msgid "inspur.ispim (version 1.2.0)" -msgstr "inspur.ispim (バージョン 1.2.0)" - -#: ../../rst/porting_guides/porting_guide_7.rst:274 -msgid "purestorage.fusion (version 1.1.1)" -msgstr "purestorage.fusion (バージョン 1.1.1)" - -#: ../../rst/porting_guides/porting_guide_7.rst:275 -msgid "vultr.cloud (version 1.3.1)" -msgstr "vultr.cloud (バージョン 1.3.1)" - -#: ../../rst/porting_guides/porting_guide_7.rst:306 -msgid "Ansible 7 requires Python 3.9 on the controller, same as ansible-core 2.14." -msgstr "Ansible 7 は、ansible-core 2.14 と同じように、コントローラー上に Python 3.9 を必要とします。" - -#: ../../rst/porting_guides/porting_guide_7.rst:311 -msgid "Allow for lazy evaluation of Jinja2 expressions (https://github.com/ansible/ansible/issues/56017)" -msgstr "Jinja2 式の遅延評価を許可します (https://github.com/ansible/ansible/issues/56017)" - -#: ../../rst/porting_guides/porting_guide_7.rst:312 -msgid "The default ansible-galaxy role skeletons no longer contain .travis.yml files. You can configure ansible-galaxy to use a custom role skeleton that contains a .travis.yml file to continue using Galaxy's integration with Travis CI." -msgstr "デフォルトの ansible-galaxy ロールスケルトンには、.travis.yml ファイルが含まれなくなりました。.travis.yml ファイルを含むカスタムロールのスケルトンを使用するように ansible-galaxy を設定して、Galaxy と Travis CI の統合を引き続き使用することができます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:313 -#: ../../rst/porting_guides/porting_guide_7.rst:476 -msgid "ansible - At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding." -msgstr "ansible - 起動時に、ファイルシステムのエンコーディングとロケールがチェックされ、UTF-8 であることが確認されます。確認しない場合、プロセスは誤ったエンコーディングを報告するエラーで終了します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:314 -#: ../../rst/porting_guides/porting_guide_7.rst:477 -msgid "ansible - Increase minimum Python requirement to Python 3.9 for CLI utilities and controller code" -msgstr "ansible - CLI ユーティリティーとコントローラーコードの Python の最小要件を Python 3.9 に増やします。" - -#: ../../rst/porting_guides/porting_guide_7.rst:315 -#: ../../rst/porting_guides/porting_guide_7.rst:478 -msgid "ansible-test - At startup the filesystem encoding is checked to verify it is UTF-8. If not, the process exits with an error reporting the errant encoding." -msgstr "ansible-test - 起動時にファイルシステムのエンコーディングがチェックされ、UTF-8 であることが確認されます。確認しない場合、プロセスは誤ったエンコーディングを報告するエラーで終了します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:316 -#: ../../rst/porting_guides/porting_guide_7.rst:479 -msgid "ansible-test - At startup the locale is configured as ``en_US.UTF-8``, with a fallback to ``C.UTF-8``. If neither encoding is available the process exits with an error. If the fallback is used, a warning is displayed. In previous versions the ``en_US.UTF-8`` locale was always requested. However, no startup checking was performed to verify the locale was successfully configured." -msgstr "ansible-test - 起動時にロケールは、``C.UTF-8`` へのフォールバックのある ``en_US.UTF-8`` として設定されます。どちらのエンコーディングも利用できない場合、プロセスはエラーで終了します。フォールバックが使用される場合、警告が表示されます。以前のバージョンでは、``en_US.UTF-8`` ロケールは常に要求されました。ただし、ロケールが正常に設定されたことを確認するための起動時のチェックは実行されませんでした。" - -#: ../../rst/porting_guides/porting_guide_7.rst:317 -msgid "ansible-test validate-modules - Removed the ``missing-python-doc`` error code in validate modules, ``missing-documentation`` is used instead for missing PowerShell module documentation." -msgstr "ansible-test validate-modules - モジュールの検証で ``missing-python-doc`` エラーコードを削除しました。``missing-documentation`` は、PowerShell モジュールのドキュメントがない場合に代わりに使用されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:318 -msgid "strategy plugins - Make ``ignore_unreachable`` to increase ``ignored`` and ``ok`` and counter, not ``skipped`` and ``unreachable``. (https://github.com/ansible/ansible/issues/77690)" -msgstr "ストラテジープラグイン - ``ignore_unreachable`` が、``skipped`` および ``unreachable`` ではなく、``ignored``、``ok``、およびカウンターを増やすようにします (https://github.com/ansible/ansible/issues/77690)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:323 -#: ../../rst/porting_guides/porting_guide_7.rst:359 -msgid "Tags beginning with ``aws:`` will not be removed when purging tags, these tags are reserved by Amazon and may not be updated or deleted (https://github.com/ansible-collections/amazon.aws/issues/817)." -msgstr "``aws:`` で始まるタグは、タグをパージしても削除されません。これらのタグは Amazon によって予約されており、更新または削除できません (https://github.com/ansible-collections/amazon.aws/issues/817)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:324 -msgid "amazon.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/amazon.aws/pull/1087)." -msgstr "amazon.aws コレクション - ansible-core < 2.11 のサポートは終了しました (https://github.com/ansible-collections/amazon.aws/pull/1087)." - -#: ../../rst/porting_guides/porting_guide_7.rst:325 -msgid "amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/934)." -msgstr "amazon.aws コレクション - amazon.aws コレクションでは ``botocore<1.21.0`` および ``boto3<1.18.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。古いバージョンの SDK を使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/amazon.aws/pull/934)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:326 -msgid "amazon.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834)." -msgstr "amazon.aws コレクション - ``profile``パラメーターは現在、``aws_access_key``、``aws_secret_key``、および ``security_token`` でパラメーターにより相互に排他的です (https://github.com/ansible-collections/amazon.aws/pull/834)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:327 -msgid "aws_az_info - the module alias ``aws_az_facts`` was deprecated in Ansible 2.9 and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/832)." -msgstr "aws_az_info - モジュールのエイリアス ``aws_az_facts`` は Ansible 2.9 で非推奨となり、現在は削除されています (https://github.com/ansible-collections/amazon.aws/pull/832)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:328 -msgid "aws_s3 - the default value for ``ensure overwrite`` has been changed to ``different`` instead of ``always`` so that the module is idempotent by default (https://github.com/ansible-collections/amazon.aws/issues/811)." -msgstr "aws_s3 - モジュールがデフォルトでべき等であるように、``ensure overwrite`` のデフォルト値が ``always`` の代わりに ``different`` に変更されました (https://github.com/ansible-collections/amazon.aws/issues/811)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:329 -msgid "aws_ssm - on_denied and on_missing now both default to error, for consistency with both aws_secret and the base Lookup class (https://github.com/ansible-collections/amazon.aws/issues/617)." -msgstr "aws_ssm - aws_secret とベース Lookup クラスの両方との一貫性を保つために、on_denied および on_missing の両方がデフォルトでエラーとなりました (https://github.com/ansible-collections/amazon.aws/issues/617)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:330 -msgid "doc_fragments - remove minimum collection requirements from doc_fragments/aws.py and allow pulling those from doc_fragments/aws_boto3.py instead (https://github.com/ansible-collections/amazon.aws/pull/985)." -msgstr "doc_fragments - doc_fragments/aws.py から最小限のコレクション要件を削除し、代わりに doc_fragments/aws_boto3.py からそれらをプルできるようにしました (https://github.com/ansible-collections/amazon.aws/pull/985)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:331 -msgid "ec2 - The ``ec2`` module has been removed in release 4.0.0 and replaced by the ``ec2_instance`` module (https://github.com/ansible-collections/amazon.aws/pull/630)." -msgstr "ec2 - ``ec2`` モジュールはリリース 4.0.0 で削除され、``ec2_instance`` モジュールに置き換えられました (https://github.com/ansible-collections/amazon.aws/pull/630)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:332 -msgid "ec2_ami - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_ami -``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:333 -msgid "ec2_ami - the parameter aliases ``DeviceName``, ``VirtualName`` and ``NoDevice`` were previously deprecated and have been removed, please use ``device_name``, ``virtual_name`` and ``no_device`` instead (https://github.com/ansible-collections/amazon.aws/pull/913)." -msgstr "ec2_ami - パラメーターのエイリアス ``DeviceName``、``VirtualName``、および ``NoDevice`` は以前非推奨となり、削除されました。代わりに ``device_name``、``virtual_name``、および ``no_device`` を使用してください (https://github.com/ansible-collections/amazon.aws/pull/913)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:334 -msgid "ec2_eni_info - the mutual exclusivity of the ``eni_id`` and ``filters`` parameters is now enforced, previously ``filters`` would be ignored if ``eni_id`` was set (https://github.com/ansible-collections/amazon.aws/pull/954)." -msgstr "ec2_eni_info - ``eni_id`` と``filters`` パラメーターの相互排他性が強制されるようになりました。以前は``eni_id`` が設定されている場合は ``filters`` は無視されていました (https://github.com/ansible-collections/amazon.aws/pull/954)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:335 -msgid "ec2_instance - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_instance - ``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:336 -msgid "ec2_key - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_key - ``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:337 -msgid "ec2_vol - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_vol - ``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:338 -msgid "ec2_vpc_dhcp_option_info - the parameter aliases ``DhcpOptionIds`` and ``DryRun`` were previously deprecated and have been removed, please use ``dhcp_options_ids`` and ``no_device`` instead (https://github.com/ansible-collections/amazon.aws/pull/913)." -msgstr "ec2_vpc_dhcp_option_info - パラメーターのエイリアス ``DhcpOptionIds`` および ``DryRun`` は以前非推奨となり、削除されました。代わりに ``dhcp_options_ids`` および ``no_device`` を使用してください (https://github.com/ansible-collections/amazon.aws/pull/913)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:339 -msgid "ec2_vpc_endpoint - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_vpc_endpoint - ``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:340 -msgid "ec2_vpc_igw_info - The default value for ``convert_tags`` has been changed to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/835)." -msgstr "ec2_vpc_igw_info - ``convert_tags`` のデフォルト値が ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/835)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:341 -msgid "ec2_vpc_net - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_vpc_net - ``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:342 -msgid "ec2_vpc_route_table - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916)." -msgstr "ec2_vpc_route_table - ``purge_tags`` のデフォルト値が、``False`` から ``True`` に変更されました (https://github.com/ansible-collections/amazon.aws/pull/916)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:343 -msgid "elb_classic_lb - the ``ec2_elb`` fact has been removed (https://github.com/ansible-collections/amazon.aws/pull/827)." -msgstr "elb_classic_lb - ``ec2_elb`` ファクトは削除されました (https://github.com/ansible-collections/amazon.aws/pull/827)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:344 -msgid "module_utils - Support for the original AWS SDK aka ``boto`` has been removed, including all relevant helper functions. All modules should now use the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/amazon.aws/pull/630)" -msgstr "module_utils - 関連するすべてのヘルパー関数を含む、元の AWS SDK (別名 ``boto``) のサポートが削除されました。すべてのモジュールは今後、``boto3``/``botocore`` AWS SDK を使用する必要があります (https://github.com/ansible-collections/amazon.aws/pull/630)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:345 -msgid "s3_bucket - the previously deprecated alias ``S3_URL`` for the ``s3_url`` parameter has been removed. Playbooks shuold be updated to use ``s3_url`` (https://github.com/ansible-collections/amazon.aws/pull/908)." -msgstr "s3_bucket - 以前に非推奨となった ``s3_url`` パラメーターのエイリアス ``S3_URL`` は削除されました。Playbook は ``s3_url`` を使うように更新する必要があります (https://github.com/ansible-collections/amazon.aws/pull/908)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:346 -msgid "s3_object - the previously deprecated alias ``S3_URL`` for the ``s3_url`` parameter has been removed. Playbooks should be updated to use ``s3_url`` (https://github.com/ansible-collections/amazon.aws/pull/908)." -msgstr "s3_object - 以前に非推奨となった ``s3_url`` パラメーターのエイリアス ``S3_URL`` は削除されました。Playbook は ``s3_url`` を使うように更新する必要があります (https://github.com/ansible-collections/amazon.aws/pull/908)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:349 -#: ../../rst/porting_guides/porting_guide_7.rst:539 -msgid "check_point.mgmt" -msgstr "check_point.mgmt" - -#: ../../rst/porting_guides/porting_guide_7.rst:351 -msgid "cp_mgmt_access_role - the 'machines' parameter now accepts a single str and a new parameter 'machines_list' of type dict has been added. the 'users' parameter now accepts a single str and a new parameter 'users_list' of type dict has been added." -msgstr "cp_mgmt_access_role - 'machines' パラメーターが単一の str を受け入れるようになり、タイプ dict の新しいパラメーター 'machines_list' が追加されました。'users' パラメーターは単一の str を受け入れるようになり、タイプ dict の新しいパラメーター 'users_list' が追加されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:352 -msgid "cp_mgmt_access_rule - the 'vpn' parameter now accepts a single str and a new parameter 'vpn_list' of type dict has been added. the 'position_by_rule' parameter has been changed to 'relative_position' with support of positioning above/below a section (and not just a rule). the 'relative_position' parameter has also 'top' and 'bottom' suboptions which allows positioning a rule at the top and bottom of a section respectively. a new parameter 'search_entire_rulebase' has been added to allow the relative positioning to be unlimited (was previously limited to 50 rules)" -msgstr "cp_mgmt_access_rule - 'vpn' パラメーターは単一の str を受け入れるようになり、タイプ dict の新しいパラメーター 'vpn_list' が追加されました。'position_by_rule' パラメーターが 'relative_position' に変更され、セクションの上/下の配置がサポートされました (ルールだけではありません)。'relative_position' パラメーターには 'top' および 'bottom' のサブオプションもあり、それぞれセクションの上部と下部にルールを配置できます。新しいパラメーター 'search_entire_rulebase' が追加され、相対位置を無制限とすることができるようになりました (以前は 50 ルールに制限されていました)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:353 -msgid "cp_mgmt_administrator - the 'permissions_profile' parameter now accepts a single str and a new parameter 'permissions_profile_list' of type dict has been added." -msgstr "cp_mgmt_administrator - 'permissions_profile' パラメーターは単一の str を受け入れるようになり、タイプ dict の新しいパラメーター 'permissions_profile_list' が追加されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:354 -msgid "cp_mgmt_publish - the 'uid' parameter has been removed." -msgstr "cp_mgmt_publish - 'uid' パラメーターが削除されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:360 -msgid "acm_certificate - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "acm_certificate - 以前に非推奨となったデフォルト値 ``purge_tags=False`` は、``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:361 -#: ../../rst/porting_guides/porting_guide_7.rst:485 -msgid "autoscaling_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group``." -msgstr "autoscaling_group - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.autoscaling_group`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:362 -#: ../../rst/porting_guides/porting_guide_7.rst:486 -msgid "autoscaling_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group_info``." -msgstr "autoscaling_group_info - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.autoscaling_group_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:363 -msgid "aws_secret - tags are no longer removed when the ``tags`` parameter is not set. To remove all tags set ``tags={}`` (https://github.com/ansible-collections/community.aws/issues/1146)." -msgstr "aws_secret - ``tags`` パラメーターが設定されていない場合、タグが削除されなくなりました。すべてのタグを削除するには ``tags={}`` を設定します (https://github.com/ansible-collections/community.aws/issues/1146)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:364 -msgid "cloudfront_distribution - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "cloudfront_distribution - 以前に非推奨となったデフォルト値 ``purge_tags=False`` は、``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:365 -msgid "cloudtrail - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``." -msgstr "cloudtrail - モジュールは ``amazon.aws`` コレクションに移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.cloudtrail`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:366 -#: ../../rst/porting_guides/porting_guide_7.rst:488 -msgid "cloudwatch_metric_alarm - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatch_metric_alarm``." -msgstr "cloudwatch_metric_alarm - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.cloudwatch_metric_alarm`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:367 -#: ../../rst/porting_guides/porting_guide_7.rst:489 -msgid "cloudwatchevent_rule - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchevent_rule``." -msgstr "cloudwatchevent_rule - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.cloudwatchevent_rule`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:368 -#: ../../rst/porting_guides/porting_guide_7.rst:490 -msgid "cloudwatchlogs_log_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group``." -msgstr "cloudwatchlogs_log_group - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.cloudwatchlogs_log_group`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:369 -#: ../../rst/porting_guides/porting_guide_7.rst:491 -msgid "cloudwatchlogs_log_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_info``." -msgstr "cloudwatchlogs_log_group_info - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.cloudwatchlogs_log_group_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:370 -#: ../../rst/porting_guides/porting_guide_7.rst:492 -msgid "cloudwatchlogs_log_group_metric_filter - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_metric_filter``." -msgstr "cloudwatchlogs_log_group_metric_filter - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.cloudwatchlogs_log_group_metric_filter`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:371 -msgid "community.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/community.aws/pull/1541)." -msgstr "community.aws コレクション - ansible-core < 2.11 のサポートは終了しました (https://github.com/ansible-collections/community.aws/pull/1541)." - -#: ../../rst/porting_guides/porting_guide_7.rst:372 -msgid "community.aws collection - The ``community.aws`` collection has now dropped support for and any requirements upon the original ``boto`` AWS SDK, and now uses the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/community.aws/pull/898)." -msgstr "community.aws コレクション - ``community.aws`` コレクションは現在、元の ``boto`` AWS SDK へのサポートと要件をすべて削除し、``boto3``/``botocore`` AWS SDK を使用するようになりました (https://github.com/ansible-collections/community.aws/pull/898)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:373 -msgid "community.aws collection - The community.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/1362)." -msgstr "community.aws コレクション - community.aws コレクションでは ``botocore<1.21.0`` および ``boto3<1.18.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。SDK の古いバージョンを使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/community.aws/pull/1362)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:374 -msgid "community.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834)." -msgstr "community.aws コレクション - ``profile`` パラメーターは現在、``aws_access_key``、``aws_secret_key``、および ``security_token`` パラメーターと相互に排他的です (https://github.com/ansible-collections/amazon.aws/pull/834)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:375 -#: ../../rst/porting_guides/porting_guide_7.rst:493 -msgid "ec2_eip - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip``." -msgstr "ec2_eip - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_eip`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:376 -#: ../../rst/porting_guides/porting_guide_7.rst:494 -msgid "ec2_eip_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip_info``." -msgstr "ec2_eip_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.ec2_eip_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:379 -msgid "ec2_vpc_vpn - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "ec2_vpc_vpn - これまで非推奨だったデフォルト値``purge_tags=False`` は、``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:380 -#: ../../rst/porting_guides/porting_guide_7.rst:495 -msgid "elb_application_lb - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb``." -msgstr "elb_application_lb - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.elb_application_lb`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:381 -#: ../../rst/porting_guides/porting_guide_7.rst:496 -msgid "elb_application_lb_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb_info``." -msgstr "elb_application_lb_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.elb_application_lb_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:382 -msgid "elb_instance - the ``ec2_elbs`` fact has been removed, ``updated_elbs`` has been added the return values and includes the same information (https://github.com/ansible-collections/community.aws/pull/1173)." -msgstr "elb_instance - ``ec2_elbs`` ファクトが削除され、``updated_elbs`` には戻り値が追加され、同じ情報が含まれています (https://github.com/ansible-collections/community.aws/pull/1173)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:383 -msgid "elb_network_lb - the default value of ``state`` has changed from ``absent`` to ``present`` (https://github.com/ansible-collections/community.aws/pull/1167)." -msgstr "elb_network_lb - ``state`` のデフォルト値が``absent`` から ``present`` に変更されました (https://github.com/ansible-collections/community.aws/pull/1167)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:384 -#: ../../rst/porting_guides/porting_guide_7.rst:497 -msgid "execute_lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.execute_lambda``." -msgstr "execute_lambda - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.execute_lambda`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:385 -#: ../../rst/porting_guides/porting_guide_7.rst:498 -msgid "iam_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy``." -msgstr "iam_policy - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.iam_policy`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:386 -#: ../../rst/porting_guides/porting_guide_7.rst:499 -msgid "iam_policy_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy_info``." -msgstr "iam_policy_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.iam_policy_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:387 -msgid "iam_server_certificate - Passing file names to the ``cert``, ``chain_cert`` and ``key`` parameters has been removed. We recommend using a lookup plugin to read the files instead, see the documentation for an example (https://github.com/ansible-collections/community.aws/pull/1265)." -msgstr "iam_server_certificate - ファイル名を ``cert``、``chain_cert``、および ``key`` パラメーターに渡すことが削除されました。代わりにlookup プラグインを使用してファイルを読み取ることが推奨されます。例については、ドキュメントを参照してください (https://github.com/ansible-collections/community.aws/pull/1265)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:388 -msgid "iam_server_certificate - the default value for the ``dup_ok`` parameter has been changed to ``true``. To preserve the original behaviour explicitly set the ``dup_ok`` parameter to ``false`` (https://github.com/ansible-collections/community.aws/pull/1265)." -msgstr "iam_server_certificate - ``dup_ok`` パラメーターのデフォルト値は、``true`` に変更されました。元の動作を保持するには、明示的に ``dup_ok`` パラメーターを ``false`` に設定してください (https://github.com/ansible-collections/community.aws/pull/1265)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:389 -#: ../../rst/porting_guides/porting_guide_7.rst:500 -msgid "iam_user - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user``." -msgstr "iam_user - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.iam_user`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:390 -#: ../../rst/porting_guides/porting_guide_7.rst:501 -msgid "iam_user_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user_info``." -msgstr "iam_user_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.iam_user_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:391 -#: ../../rst/porting_guides/porting_guide_7.rst:502 -msgid "kms_key - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key``." -msgstr "kms_key - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.kms_key`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:392 -msgid "kms_key - managing the KMS IAM Policy via ``policy_mode`` and ``policy_grant_types`` was previously deprecated and has been removed in favor of the ``policy`` option (https://github.com/ansible-collections/community.aws/pull/1344)." -msgstr "kms_key - KMS IAM Policy を``policy_mode`` と``policy_grant_types`` で管理していましたが、``policy`` のオプションを優先して、非推奨となり、削除されました (https://github.com/ansible-collections/community.aws/pull/1344)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:393 -msgid "kms_key - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "kms_key - 以前に非推奨となったデフォルト値 ``purge_tags=False`` が ``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:394 -#: ../../rst/porting_guides/porting_guide_7.rst:503 -msgid "kms_key_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key_info``." -msgstr "kms_key_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.kms_key_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:395 -#: ../../rst/porting_guides/porting_guide_7.rst:504 -msgid "lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda``." -msgstr "lambda - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.lambda`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:396 -#: ../../rst/porting_guides/porting_guide_7.rst:505 -msgid "lambda_alias - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_alias``." -msgstr "lambda_alias - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.lambda_alias`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:397 -#: ../../rst/porting_guides/porting_guide_7.rst:506 -msgid "lambda_event - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_event``." -msgstr "lambda_event - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.lambda_event`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:398 -#: ../../rst/porting_guides/porting_guide_7.rst:507 -msgid "lambda_execute - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_execute``." -msgstr "lambda_execute - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.lambda_execute`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:399 -#: ../../rst/porting_guides/porting_guide_7.rst:508 -msgid "lambda_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_info``." -msgstr "lambda_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.lambda_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:400 -#: ../../rst/porting_guides/porting_guide_7.rst:509 -msgid "lambda_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_policy``." -msgstr "lambda_policy - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.lambda_policy`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:401 -#: ../../rst/porting_guides/porting_guide_7.rst:510 -msgid "rds_cluster - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster``." -msgstr "rds_cluster - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.rds_cluster`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:402 -#: ../../rst/porting_guides/porting_guide_7.rst:511 -msgid "rds_cluster_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_info``." -msgstr "rds_cluster_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.rds_cluster_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:403 -#: ../../rst/porting_guides/porting_guide_7.rst:512 -msgid "rds_cluster_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_snapshot``." -msgstr "rds_cluster_snapshot - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.rds_cluster_snapshot`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:404 -#: ../../rst/porting_guides/porting_guide_7.rst:513 -msgid "rds_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance``." -msgstr "rds_instance - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_instance`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:405 -#: ../../rst/porting_guides/porting_guide_7.rst:514 -msgid "rds_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_info``." -msgstr "rds_instance_info - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_instance_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:406 -#: ../../rst/porting_guides/porting_guide_7.rst:515 -msgid "rds_instance_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_snapshot``." -msgstr "rds_instance_snapshot - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.rds_instance_snapshot`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:407 -#: ../../rst/porting_guides/porting_guide_7.rst:516 -msgid "rds_option_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group``." -msgstr "rds_option_group - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_option_group`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:408 -#: ../../rst/porting_guides/porting_guide_7.rst:517 -msgid "rds_option_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group_info``." -msgstr "rds_option_group_info - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_option_group_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:409 -#: ../../rst/porting_guides/porting_guide_7.rst:518 -msgid "rds_param_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_param_group``." -msgstr "rds_param_group - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_param_group`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:410 -msgid "rds_param_group - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "rds_param_group - 以前に非推奨となったデフォルト値 ``purge_tags=False`` が ``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:411 -#: ../../rst/porting_guides/porting_guide_7.rst:519 -msgid "rds_snapshot_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_snapshot_info``." -msgstr "rds_snapshot_info - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_snapshot_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:412 -#: ../../rst/porting_guides/porting_guide_7.rst:520 -msgid "rds_subnet_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_subnet_group``." -msgstr "rds_subnet_group - モジュールは ``community.aws`` コレクションから移行されました。このモジュールの完全修飾コレクション名を使用する Playbook は、``amazon.aws.rds_subnet_group`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:413 -#: ../../rst/porting_guides/porting_guide_7.rst:521 -msgid "route53 - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53``." -msgstr "route53 - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.route53`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:414 -#: ../../rst/porting_guides/porting_guide_7.rst:522 -msgid "route53_health_check - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_health_check``." -msgstr "route53_health_check - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.route53_health_check`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:415 -msgid "route53_health_check - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "route53_health_check - 以前に非推奨となったデフォルト値 ``purge_tags=False`` が ``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:416 -#: ../../rst/porting_guides/porting_guide_7.rst:523 -msgid "route53_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_info``." -msgstr "route53_info - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.route53_info`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:417 -#: ../../rst/porting_guides/porting_guide_7.rst:524 -msgid "route53_zone - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_zone``." -msgstr "route53_zone - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.route53_zone`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:418 -msgid "route53_zone - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "route53_zone - 以前に非推奨となったデフォルト値 ``purge_tags=False`` が ``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:419 -msgid "script_inventory_ec2 - The ec2.py inventory script has been moved to a new repository. The script can now be downloaded from https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py and has been removed from this collection. We recommend migrating from the script to the amazon.aws.ec2 inventory plugin. (https://github.com/ansible-collections/community.aws/pull/898)" -msgstr "script_inventory_ec2 - ec2.py インベントリースクリプトが新しいリポジトリーに移動されました。スクリプトはhttps://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py からダウンロードでき、このコレクションから削除されました。スクリプトから amazon.aws.ec2 インベントリープラグインに移行することをお勧めします。(https://github.com/ansible-collections/community.aws/pull/898)" - -#: ../../rst/porting_guides/porting_guide_7.rst:420 -msgid "sqs_queue - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343)." -msgstr "sqs_queue - 以前に非推奨となったデフォルト値 ``purge_tags=False`` が ``purge_tags=True`` に更新されました (https://github.com/ansible-collections/community.aws/pull/1343)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:425 -msgid "This collection does not work with ansible-core 2.11 on Python 3.12+. Please either upgrade to ansible-core 2.12+, or use Python 3.11 or earlier (https://github.com/ansible-collections/community.docker/pull/271)." -msgstr "このコレクションは、Python 3.12 以降の ansible-core 2.11 では機能しません。ansible-core 2.12+ にアップグレードするか、Python 3.11 以前を使用してください (https://github.com/ansible-collections/community.docker/pull/271)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:426 -msgid "docker_container - ``exposed_ports`` is no longer ignored in ``comparisons``. Before, its value was assumed to be identical with the value of ``published_ports`` (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container - ``exposed_ports`` は、``comparisons`` で無視されなくなりました。以前は、その値は ``published_ports`` の値と同じであると想定されていました (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:427 -msgid "docker_container - ``log_options`` can no longer be specified when ``log_driver`` is not specified (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container - ``log_driver`` が指定されていない場合、``log_options`` は指定できなくなりました (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:428 -msgid "docker_container - ``publish_all_ports`` is no longer ignored in ``comparisons`` (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container -``publish_all_ports`` は ``comparisons`` で無視されなくなりました (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:429 -msgid "docker_container - ``restart_retries`` can no longer be specified when ``restart_policy`` is not specified (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container - ``restart_policy`` が指定されていない場合、``restart_retries`` を指定できなくなりました (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:430 -msgid "docker_container - ``stop_timeout`` is no longer ignored for idempotency if told to be not ignored in ``comparisons``. So far it defaulted to ``ignore`` there, and setting it to ``strict`` had no effect (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container - ``comparisons`` で無視しないように指示された場合、``stop_timeout`` はべき等性のために無視されなくなりました。これまでのところ、そこではデフォルトで ``ignore`` となり、それを ``strict`` に設定しても効果はありませんでした (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:431 -msgid "modules and plugins communicating directly with the Docker daemon - when connecting by SSH and not using ``use_ssh_client=true``, reject unknown host keys instead of accepting them. This is only a breaking change relative to older community.docker 3.0.0 pre-releases or with respect to Docker SDK for Python < 6.0.0. Docker SDK for Python 6.0.0 will also include this change (https://github.com/ansible-collections/community.docker/pull/434)." -msgstr "Docker デーモンと直接通信するモジュールとプラグイン - SSH で接続し、``use_ssh_client=true`` を使用しない場合、不明なホストキーを受け入れる代わりに拒否します。これは、古い community.docker 3.0.0 プレリリース、または Docker SDK for Python < 6.0.0 に関連する互換性を失わせる変更にすぎません。Docker SDK for Python 6.0.0 にもこの変更が含まれます (https://github.com/ansible-collections/community.docker/pull/434)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:437 -msgid "scaleway_container_registry_info - no longer replace ``secret_environment_variables`` in the output by ``SENSITIVE_VALUE`` (https://github.com/ansible-collections/community.general/pull/5497)." -msgstr "scaleway_container_registry_info - ``SENSITIVE_VALUE`` による出力で、``secret_environment_variables`` に置き換わることはなくなりました (https://github.com/ansible-collections/community.general/pull/5497)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:442 -msgid "auth - the default value for ``token_validate`` has changed from ``true`` to ``false``, as previously announced (https://github.com/ansible-collections/community.hashi_vault/issues/248)." -msgstr "auth - 以前発表したように、``token_validate`` のデフォルト値は、``true`` から ``false`` に変更されました (https://github.com/ansible-collections/community.hashi_vault/issues/248)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:443 -msgid "vault_kv2_get lookup - as previously announced, the default value for ``engine_mount_point`` in the ``vault_kv2_get`` lookup has changed from ``kv`` to ``secret`` (https://github.com/ansible-collections/community.hashi_vault/issues/279)." -msgstr "vault_kv2_get lookup - 以前発表したように、``vault_kv2_get`` lookup の ``engine_mount_point`` のデフォルト値は、``kv`` から ``secret`` に変更されました (https://github.com/ansible-collections/community.hashi_vault/issues/279)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:448 -msgid "Removed support for ansible-core version < 2.13.0." -msgstr "ansible-core バージョン < 2.13.0 のサポートを削除しました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:449 -msgid "vmware_dvs_portgroup - Add a new sub-option `inherited` to the `in_traffic_shaping` parameter. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483)." -msgstr "vmware_dvs_portgroup - `in_traffic_shaping` パラメーターに新しいサブオプション `inherited` を追加します。これは、パラメーターを定義しないことで設定をそのまま維持できることを意味しますが、PG レベルで設定を上書きする場合は、設定を `inherited` でないものとして定義する必要があることも意味します (https://github.com/ansible-collections/community.vmware/pull/1483)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:450 -msgid "vmware_dvs_portgroup - Add a new sub-option `inherited` to the `out_traffic_shaping` parameter. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483)." -msgstr "vmware_dvs_portgroup - `out_traffic_shaping` パラメーターに新しいサブオプション `inherited` を追加します。これは、パラメーターを定義しないことで設定をそのまま維持できることを意味しますが、PG レベルで設定を上書きする場合は、設定を `inherited` でないものとして定義する必要があることも意味します (https://github.com/ansible-collections/community.vmware/pull/1483)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:451 -msgid "vmware_dvs_portgroup - Change the type of `net_flow` to string to allow setting it implicitly to inherited or to keep the value as-is. This means you can keep the setting as-is by not defining the parameter, but also that while `true` or `no` still work, `True` or `Off` (uppercase) won't (https://github.com/ansible-collections/community.vmware/pull/1483)." -msgstr "vmware_dvs_portgroup - `net_flow` のタイプを文字列に変更し、継承済みと暗黙的に設定するか、または値をそのまま維持するようにします。これは、パラメーターを定義しないことで設定をそのまま維持できることを意味しますが、`true` や `no` はまだ機能しますが、`True` や `Off` (大文字) は機能しないことを意味します (https://github.com/ansible-collections/community.vmware/pull/1483)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:452 -msgid "vmware_dvs_portgroup - Remove support for vSphere API less than 6.7." -msgstr "vmware_dvs_portgroup - 6.7 未満の vSphere API のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:453 -msgid "vmware_dvs_portgroup - Remove the default for `network_policy` and add a new sub-option `inherited`. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483)." -msgstr "vmware_dvs_portgroup - `network_policy` のデフォルトを削除し、新しいサブオプション `inherited` を追加します。これは、パラメーターを定義しないことで設定をそのまま維持できることを意味しますが、PG レベルで設定を上書きする場合は、設定を `inherited` でないものとして定義する必要があることも意味します (https://github.com/ansible-collections/community.vmware/pull/1483)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:454 -msgid "vmware_dvs_portgroup_info - Remove support for vSphere API less than 6.7." -msgstr "vmware_dvs_portgroup_info - 6.7 未満の vSphere API のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:455 -msgid "vmware_dvswitch - Remove support for vSphere API less than 6.7." -msgstr "vmware_dvswitch - 6.7 未満の vSphere API のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:456 -msgid "vmware_dvswitch_uplink_pg - Remove support for vSphere API less than 6.7." -msgstr "vmware_dvswitch_uplink_pg - 6.7 未満の vSphere API のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:457 -msgid "vmware_guest_boot_manager - Remove default for ``secure_boot_enabled`` parameter (https://github.com/ansible-collections/community.vmware/issues/1461)." -msgstr "vmware_guest_boot_manager - ``secure_boot_enabled`` パラメーターのデフォルトを削除します (https://github.com/ansible-collections/community.vmware/issues/1461)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:458 -msgid "vmware_vm_config_option - Dict item names in result are changed from strings joined with spaces to strings joined with underlines, e.g. `Guest fullname` is changed to `guest_fullname` (https://github.com/ansible-collections/community.vmware/issues/1268)." -msgstr "vmware_vm_config_option - 結果の Dict アイテム名は、スペースで結合された文字列からアンダーラインで結合された文字列に変更されます。たとえば、`Guest fullname` は `guest_fullname` に変更されます (https://github.com/ansible-collections/community.vmware/issues/1268)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:459 -msgid "vmware_vspan_session - Remove support for vSphere API less than 6.7." -msgstr "vmware_vspan_session - 6.7 未満の vSphere API のサポートを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:462 -#: ../../rst/porting_guides/porting_guide_7.rst:628 -msgid "dellemc.enterprise_sonic" -msgstr "dellemc.enterprise_sonic" - -#: ../../rst/porting_guides/porting_guide_7.rst:464 -msgid "bgp_af - Add the route_advertise_list dictionary to the argspec to replace the deleted, obsolete advertise_prefix attribute used for SONiC 3.x images on the 1.x branch of this collection. This change corresponds to a SONiC 4.0 OC YANG REST compliance change for the BGP AF REST API. It enables specification of a route map in conjunction with each route advertisement prefix (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/63)." -msgstr "bgp_af - route_advertise_list ディクショナリーを argspec に追加して、このコレクションの 1.x ブランチの SONiC 3.x イメージに使用される、削除され、廃止された advertise_prefix 属性を置き換えます。この変更は、BGP AF REST API の SONiC 4.0 OC YANG REST コンプライアンスの変更に対応しています。 各ルートアドバタイズメントのプレフィックスと連動したルートマップの指定が可能になります (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/63)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:465 -msgid "bgp_af - remove the obsolete 'advertise_prefix' attribute from argspec and config code. This and subsequent co-req replacement with the new route advertise list argument structure require corresponding changes in playbooks previoulsly used for configuring route advertise prefixes for SONiC 3.x images. (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/60)" -msgstr "bgp_af - 古い 'advertise_prefix' 属性を argspec と設定コードから削除します。この新しいルートアドバタイズリスト引数構造によるこれと後続の co-req 置換には、SONiC 3.x イメージのルートアドバタイズのプレフィックスを設定するために以前に使用された Playbook でも対応する変更が必要です (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/60)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:466 -msgid "bgp_neighbors - Replace the previously defined standalone \"bfd\" attribute with a bfd dictionary containing multiple attributes. This change corresponds to the revised SONiC 4.x implementation of OC YANG compatible REST APIs. Playbooks previously using the bfd attributes for SONiC 3.x images must be modified for useon SONiC 4.0 images to use the new definition for the bfd attribute argspec structure (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/72)." -msgstr "bgp_neighbors - 以前に定義されたスタンドアロンの \"bfd\" 属性を、複数の属性を含む bfd ディクショナリーに置き換えます。この変更は、OC YANG 互換 REST API の改訂された SONiC 4.x 実装に対応しています。以前に SONiC 3.x イメージの bfd 属性を使用していた Playbook は、SONiC 4.0 イメージで使用するために変更して、bfd 属性 argspec 構造の新しい定義を使用する必要があります (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/72)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:467 -msgid "bgp_neighbors - Replace, for BGP peer groups, the previously defined standalone \"bfd\" attribute with a bfd dictionary containing multiple attributes. This change corresponds to the revised SONiC 4.x implementation of OC YANG compatible REST APIs. Playbooks previously using the bfd attributes for SONiC 3.x images must be modified for useon SONiC 4.0 images to use the new definition for the bfd attribute argspec structure (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/81)." -msgstr "bgp_neighbors - BGP ピアグループの場合、以前に定義されたスタンドアロンの \"bfd\" 属性を、複数の属性を含む bfd ディクショナリーに置き換えます。この変更は、OC YANG 互換 REST API の改訂された SONiC 4.x 実装に対応しています。以前に SONiC 3.x イメージの bfd 属性を使用していた Playbook は、SONiC 4.0 イメージで使用するために変更して、bfd 属性 argspec 構造の新しい定義を使用する必要があります (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/81)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:475 -msgid "Move handler processing into new ``PlayIterator`` phase to use the configured strategy (https://github.com/ansible/ansible/issues/65067)" -msgstr "ハンドラー処理を新しい ``PlayIterator`` フェーズに移動し、設定されたストラテジーを使用します (https://github.com/ansible/ansible/issues/65067)" - -#: ../../rst/porting_guides/porting_guide_7.rst:484 -msgid "amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574)." -msgstr "amazon.aws コレクション - amazon.aws コレクションでは ``botocore<1.20.0`` および ``boto3<1.17.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。古いバージョンの SDK を使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/amazon.aws/pull/574)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:487 -msgid "cloudtrail - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``." -msgstr "cloudtrail - モジュールは ``community.aws`` コレクションから移行しました。このモジュールの完全修飾コレクション名を使用する Playbook を ``amazon.aws.cloudtrail`` を使用するように更新する必要があります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:529 -msgid "Remove following EOS dprecated modules" -msgstr "以下の EOS の非推奨となったモジュールを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:530 -#: ../../rst/porting_guides/porting_guide_7.rst:556 -#: ../../rst/porting_guides/porting_guide_7.rst:673 -#: ../../rst/porting_guides/porting_guide_7.rst:678 -msgid "Use of connection: local and the provider option are no longer valid on any modules in this collection." -msgstr "connection: local と provider オプションの使用は、このコレクション内のどのモジュールでも有効ではなくなりました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:531 -msgid "eos_interface" -msgstr "eos_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:532 -msgid "eos_l2_interface" -msgstr "eos_l2_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:533 -msgid "eos_l3_interface" -msgstr "eos_l3_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:534 -msgid "eos_linkagg" -msgstr "eos_linkagg" - -#: ../../rst/porting_guides/porting_guide_7.rst:535 -msgid "eos_static_route" -msgstr "eos_static_route" - -#: ../../rst/porting_guides/porting_guide_7.rst:536 -msgid "eos_vlan" -msgstr "eos_vlan" - -#: ../../rst/porting_guides/porting_guide_7.rst:541 -msgid "plugins/httpapi/checkpoint - Support for Smart-1 Cloud with new variable 'ansible_cloud_mgmt_id'" -msgstr "plugins/httpapi/checkpoint - 新しい変数 'ansible_cloud_mgmt_id' による Smart-1 Cloud のサポート" - -#: ../../rst/porting_guides/porting_guide_7.rst:552 -#: ../../rst/porting_guides/porting_guide_7.rst:575 -msgid "Please use either of the following connection types - network_cli, httpapi or netconf." -msgstr "接続形態は、network_cli、httpapi、netconf のいずれかをご利用ください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:553 -msgid "This includes the following modules:" -msgstr "これには以下のモジュールが含まれます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:554 -#: ../../rst/porting_guides/porting_guide_7.rst:564 -#: ../../rst/porting_guides/porting_guide_7.rst:570 -#: ../../rst/porting_guides/porting_guide_7.rst:576 -msgid "This release drops support for `connection: local` and provider dictionary." -msgstr "このリリースでは、`connection: local` とプロバイダーディクショナリーのサポートを停止しています。" - -#: ../../rst/porting_guides/porting_guide_7.rst:555 -msgid "This release removes all deprecated plugins that have reached their end-of-life." -msgstr "このリリースでは、有効期限の切れたすべての非推奨プラグインを削除しています。" - -#: ../../rst/porting_guides/porting_guide_7.rst:557 -msgid "asa_acl" -msgstr "asa_acl" - -#: ../../rst/porting_guides/porting_guide_7.rst:558 -msgid "asa_og" -msgstr "asa_og" - -#: ../../rst/porting_guides/porting_guide_7.rst:563 -msgid "Only valid connection types for this collection is network_cli." -msgstr "このコレクションで有効な接続タイプは network_cli のみです。" - -#: ../../rst/porting_guides/porting_guide_7.rst:569 -msgid "Only valid connection types for this collection are network_cli and netconf." -msgstr "このコレクションで有効な接続タイプは、network_cli と netconf のみです。" - -#: ../../rst/porting_guides/porting_guide_7.rst:581 -msgid "community.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/956)." -msgstr "community.aws コレクション - amazon.aws コレクションでは ``botocore<1.20.0`` および ``boto3<1.17.0`` のサポートを廃止しました。ほとんどのモジュールは、AWS SDK の古いバージョンで引き続き機能しますが、SDK の古いバージョンとの互換性は保証されず、テストされません。古いバージョンの SDK を使用する場合は、Ansible によって警告が出力されます (https://github.com/ansible-collections/community.aws/pull/956)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:586 -msgid "The collection now contains vendored code from the Docker SDK for Python to talk to the Docker daemon. Modules and plugins using this code no longer need the Docker SDK for Python installed on the machine the module or plugin is running on (https://github.com/ansible-collections/community.docker/pull/398)." -msgstr "コレクションには、Docker デーモンと通信するための Docker SDK for Python からのベンダーコードが含まれるようになりました。このコードを使用するモジュールとプラグインは、モジュールまたはプラグインが実行されているマシンに Docker SDK for Python をインストールする必要がなくなりました (https://github.com/ansible-collections/community.docker/pull/398)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:587 -msgid "docker_api connection plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/414)." -msgstr "docker_api 接続プラグイン - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/414)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:588 -msgid "docker_container - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:589 -msgid "docker_container - the module was completely rewritten from scratch (https://github.com/ansible-collections/community.docker/pull/422)." -msgstr "docker_container - モジュールはゼロから完全に書き直されました (https://github.com/ansible-collections/community.docker/pull/422)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:590 -msgid "docker_container_exec - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/401)." -msgstr "docker_container_exec - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/401)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:591 -msgid "docker_container_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/402)." -msgstr "docker_container_info - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/402)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:592 -msgid "docker_containers inventory plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/413)." -msgstr "docker_containers インベントリープラグイン - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/413)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:593 -msgid "docker_host_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/403)." -msgstr "docker_host_info - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/403)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:594 -msgid "docker_image - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/404)." -msgstr "docker_image - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/404)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:595 -msgid "docker_image_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/405)." -msgstr "docker_image_info - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/405)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:596 -msgid "docker_image_load - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/406)." -msgstr "docker_image_load - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/406)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:597 -msgid "docker_login - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/407)." -msgstr "docker_login - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/407)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:598 -msgid "docker_network - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/408)." -msgstr "docker_network - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/408)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:599 -msgid "docker_network_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/409)." -msgstr "docker_network_info - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/409)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:600 -msgid "docker_plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/429)." -msgstr "docker_plugin - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/429)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:601 -msgid "docker_prune - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/410)." -msgstr "docker_prune - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/410)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:602 -msgid "docker_volume - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/411)." -msgstr "docker_volume - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/411)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:603 -msgid "docker_volume_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/412)." -msgstr "docker_volume_info - Docker SDK for Python を使用しなくなりました。これには、``requests`` をインストールする必要があり、使用する機能によっては、さらに要件があります。Docker SDK for Python がインストールされている場合は、これらの要件が満たされている可能性があります (https://github.com/ansible-collections/community.docker/pull/412)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:608 -msgid "The internal structure of the collection was changed for modules and action plugins. These no longer live in a directory hierarchy ordered by topic, but instead are now all in a single (flat) directory. This has no impact on users *assuming they did not use internal FQCNs*. These will still work, but result in deprecation warnings. They were never officially supported and thus the redirects are kept as a courtsey, and this is not labelled as a breaking change. Note that for example the Ansible VScode plugin started recommending these internal names. If you followed its recommendation, you will now have to change back to the short names to avoid deprecation warnings, and potential errors in the future as these redirects will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5461)." -msgstr "モジュールとアクションのプラグインのコレクションの内部構造が変更されました。これらは、トピックごとに並べられたディレクトリー階層に存在しなくなりましたが、代わりにすべてが単一の (フラットな) ディレクトリーにあります。*ユーザーが内部 FQCN を使用していないと仮定すると*、これがユーザーに影響を及ぼすことはありません。これらは引き続き機能しますが、非推奨の警告が表示される結果となります。これらは公式にサポートされたことがないため、リダイレクトは念のため保持されており、これは重大な変更として分類されていません。たとえば、Ansible VScode プラグインはこれらの内部名の推奨を開始したことに注意してください。その推奨事項に従った場合は、これらのリダイレクトは community.general 9.0.0 で削除されるため、非推奨の警告と将来的にエラーが発生する可能性を回避するために、短い名前に戻す必要があります (https://github.com/ansible-collections/community.general/pull/5461)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:620 -msgid "The internal structure of the collection was changed for modules and action plugins. These no longer live in a directory hierarchy ordered by topic, but instead are now all in a single (flat) directory. This has no impact on users *assuming they did not use internal FQCNs*. These will still work, but result in deprecation warnings. They were never officially supported and thus the redirects are kept as a courtsey, and this is not labelled as a breaking change. Note that for example the Ansible VScode plugin started recommending these internal names. If you followed its recommendation, you will now have to change back to the short names to avoid deprecation warnings, and potential errors in the future as these redirects will be removed in community.network 8.0.0 (https://github.com/ansible-collections/community.network/pull/482)." -msgstr "モジュールとアクションのプラグインのコレクションの内部構造が変更されました。これらは、トピックごとに並べられたディレクトリー階層に存在しなくなりましたが、代わりにすべてが単一の (フラットな) ディレクトリーにあります。*ユーザーが内部 FQCN を使用していないと仮定すると*、これがユーザーに影響を及ぼすことはありません。これらは引き続き機能しますが、非推奨の警告が表示される結果となります。これらは公式にサポートされたことがないため、リダイレクトは念のため保持されており、これは重大な変更として分類されていません。たとえば、Ansible VScode プラグインはこれらの内部名の推奨を開始したことに注意してください。その推奨事項に従った場合は、これらのリダイレクトは community.general 9.0.0 で削除されるため、非推奨の警告と将来的にエラーが発生する可能性を回避するために、短い名前に戻す必要があります (https://github.com/ansible-collections/community.network/pull/482)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:630 -msgid "Added 'static_routes' module to collection (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/82)." -msgstr "コレクションに 'static_routes' モジュールを追加しました (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/82)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:631 -msgid "Added a resource module for NTP support (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/99)." -msgstr "NTP サポート用のリソースモジュールを追加しました (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/99)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:632 -msgid "Added a resource module for support of prefix lists (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/100)." -msgstr "プレフィックスのリストをサポートするためのリソースモジュールを追加しました (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/100)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:633 -msgid "Updated backend REST API request formats in all applicable modules for compatibility with SONiC 4.x openconfig YANG compliant REST APIs. (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/53)" -msgstr "SONiC 4.x openconfig YANG 準拠の REST API との互換性のために、適用可能なすべてのモジュールでバックエンド REST API 要求形式を更新しました。(https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/53)" - -#: ../../rst/porting_guides/porting_guide_7.rst:638 -msgid "Added collection metadata for creating execution environments." -msgstr "実行環境を作成するためのコレクションメタデータが追加されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:639 -msgid "Refactored the Markdown (MD) files and content for better readability." -msgstr "読みやすくするために、Markdown (MD) ファイルとコンテンツをリファクタリングしました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:640 -msgid "The share parameters are deprecated from the following modules - idrac_network, idrac_timezone_ntp, dellemc_configure_idrac_eventing, dellemc_configure_idrac_services, dellemc_idrac_lc_attributes, dellemc_system_lockdown_mode." -msgstr "共有パラメーターは、idrac_network、idrac_timezone_ntp、dellemc_configure_idrac_eventing、dellemc_configure_idrac_services、dellemc_idrac_lc_attributes、dellemc_system_lockdown_mode のモジュールでは非推奨となりました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:641 -msgid "idrac_bios - The module is enhanced to support clear pending BIOS attributes, reset BIOS to default settings, and configure BIOS attribute using Redfish." -msgstr "idrac_bios - 保留中の BIOS 属性のクリア、BIOS のデフォルト設定へのリセット、および Redfish を使用した BIOS 属性の設定をサポートするようにモジュールが強化されています。" - -#: ../../rst/porting_guides/porting_guide_7.rst:642 -msgid "idrac_boot - Support for configuring the boot settings on iDRAC." -msgstr "idrac_boot - iDRAC での起動設定の構成のサポート。" - -#: ../../rst/porting_guides/porting_guide_7.rst:643 -msgid "idrac_redfish_storage_controller - This module is enhanced to support LockVirtualDisk operation." -msgstr "idrac_redfish_storage_controller - このモジュールは、LockVirtualDisk 操作をサポートするように拡張されています。" - -#: ../../rst/porting_guides/porting_guide_7.rst:644 -msgid "idrac_virtual_media - This module allows to configure Remote File Share settings." -msgstr "idrac_virtual_media - このモジュールを使用すると、Remote File Share を設定できます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:645 -msgid "ome_device_group - The module is enhanced to support the removal of devices from a static device group." -msgstr "ome_device_group - モジュールが拡張され、静的デバイスグループからのデバイスの削除がサポートされるようになりました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:646 -msgid "ome_devices - Support for performing device-specific operations on OpenManage Enterprise." -msgstr "ome_devices - OpenManage Enterprise でデバイス固有の操作を実行するためのサポート。" - -#: ../../rst/porting_guides/porting_guide_7.rst:683 -msgid "servicenow.servicenow (previously included version: 1.0.6)" -msgstr "servicenow.servicenow (以前含まれていたバージョン: 1.0.6)" - -#: ../../rst/porting_guides/porting_guide_7.rst:691 -msgid "PlayIterator - remove deprecated ``PlayIterator.ITERATING_*`` and ``PlayIterator.FAILED_*``" -msgstr "PlayIterator - 非推奨となった ``PlayIterator.ITERATING_*`` および ``PlayIterator.FAILED_*`` を削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:692 -msgid "Remove deprecated ``ALLOW_WORLD_READABLE_TMPFILES`` configuration option (https://github.com/ansible/ansible/issues/77393)" -msgstr "非推奨となった ``ALLOW_WORLD_READABLE_TMPFILES`` 設定オプションを削除します (https://github.com/ansible/ansible/issues/77393)" - -#: ../../rst/porting_guides/porting_guide_7.rst:693 -msgid "Remove deprecated ``COMMAND_WARNINGS`` configuration option (https://github.com/ansible/ansible/issues/77394)" -msgstr "非推奨となった ``COMMAND_WARNINGS`` 設定オプションを削除します (https://github.com/ansible/ansible/issues/77394)" - -#: ../../rst/porting_guides/porting_guide_7.rst:694 -msgid "Remove deprecated ``DISPLAY_SKIPPED_HOSTS`` environment variable (https://github.com/ansible/ansible/issues/77396)" -msgstr "非推奨となった ``DISPLAY_SKIPPED_HOSTS`` 環境変数を削除します (https://github.com/ansible/ansible/issues/77396)" - -#: ../../rst/porting_guides/porting_guide_7.rst:695 -msgid "Remove deprecated ``LIBVIRT_LXC_NOSECLABEL`` environment variable (https://github.com/ansible/ansible/issues/77395)" -msgstr "非推奨となった ``LIBVIRT_LXC_NOSECLABEL`` 環境変数を削除します (https://github.com/ansible/ansible/issues/77395)" - -#: ../../rst/porting_guides/porting_guide_7.rst:696 -msgid "Remove deprecated ``NETWORK_GROUP_MODULES`` environment variable (https://github.com/ansible/ansible/issues/77397)" -msgstr "非推奨となった ``NETWORK_GROUP_MODULES`` 環境変数を削除します (https://github.com/ansible/ansible/issues/77397" - -#: ../../rst/porting_guides/porting_guide_7.rst:697 -msgid "Remove deprecated ``UnsafeProxy``" -msgstr "非推奨となった ``UnsafeProxy`` を削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:698 -msgid "Remove deprecated ``plugin_filters_cfg`` config option from ``default`` section (https://github.com/ansible/ansible/issues/77398)" -msgstr "非推奨となった ``plugin_filters_cfg`` 設定オプションを ``default`` セクションから削除します (https://github.com/ansible/ansible/issues/77398)" - -#: ../../rst/porting_guides/porting_guide_7.rst:699 -msgid "Remove deprecated functionality that allows loading cache plugins directly without using ``cache_loader``." -msgstr "``cache_loader`` を使用せずに、キャッシュプラグインを直接ロードできる非推奨の機能を削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:700 -msgid "Remove deprecated functionality that allows subclassing ``DefaultCallback`` without the corresponding ``doc_fragment``." -msgstr "対応する ``doc_fragment`` なしに ``DefaultCallback`` のサブクラス化を可能にする非推奨の機能を削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:701 -msgid "Remove deprecated powershell functions ``Load-CommandUtils`` and ``Import-PrivilegeUtil``" -msgstr "非推奨となった powershell 関数 ``Load-CommandUtils`` および ``Import-PrivilegeUtil`` を削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:702 -msgid "apt_key - remove deprecated ``key`` module param" -msgstr "apt_key - 非推奨となった ``key`` モジュールパラメーターを削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:703 -msgid "command/shell - remove deprecated ``warn`` module param" -msgstr "コマンド/シェル - 非推奨となった ``warn``モジュールパラメーターを削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:704 -msgid "get_url - remove deprecated ``sha256sum`` module param" -msgstr "get_url - 非推奨となった ``sha256sum`` モジュールパラメーターを削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:705 -msgid "import_playbook - remove deprecated functionality that allows providing additional parameters in free form" -msgstr "import_playbook - 自由形式で追加のパラメーターを提供できる非推奨の機能を削除します" - -#: ../../rst/porting_guides/porting_guide_7.rst:710 -msgid "cloudformation - the ``template_format`` option has been removed. It has been ignored by the module since Ansible 2.3 (https://github.com/ansible-collections/amazon.aws/pull/833)." -msgstr "cloudformation - ``template_format`` オプションが削除されました。これは Ansible 2.3 以降モジュールによって無視されています (https://github.com/ansible-collections/amazon.aws/pull/833)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:711 -msgid "ec2_key - the ``wait_timeout`` option had no effect, was deprecated in release 1.0.0, and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/830)." -msgstr "ec2_key - ``wait_timeout`` オプションは効果がなく、リリース 1.0.0 で非推奨となり、現在は削除されています (https://github.com/ansible-collections/amazon.aws/pull/830)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:712 -msgid "ec2_key - the ``wait`` option had no effect, was deprecated in release 1.0.0, and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/830)." -msgstr "ec2_key - ``wait`` オプションは効果がなく、リリース 1.0.0 で非推奨となり、現在は削除されています (https://github.com/ansible-collections/amazon.aws/pull/830)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:713 -msgid "ec2_tag - the previously deprecated state ``list`` has been removed. To list tags on an EC2 resource the ``ec2_tag_info`` module can be used (https://github.com/ansible-collections/amazon.aws/pull/829)." -msgstr "ec2_tag - 以前に非推奨となった状態 ``list`` が削除されました。EC2 リソースのタグを一覧表示するには、``ec2_tag_info`` モジュールを使用できます (https://github.com/ansible-collections/amazon.aws/pull/829)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:714 -msgid "ec2_vol - the previously deprecated state ``list`` has been removed. To list volumes the ``ec2_vol_info`` module can be used (https://github.com/ansible-collections/amazon.aws/pull/828)." -msgstr "ec2_vol - 以前に非推奨となった状態 ``list`` が削除されました。ボリュームを一覧表示するには ``ec2_vol_info`` モジュールを使用できます (https://github.com/ansible-collections/amazon.aws/pull/828)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:715 -msgid "module_utils.batch - the class ``ansible_collections.amazon.aws.plugins.module_utils.batch.AWSConnection`` has been removed. Please use ``AnsibleAWSModule.client()`` instead (https://github.com/ansible-collections/amazon.aws/pull/831)." -msgstr "module_utils.batch - クラス ``ansible_collections.amazon.aws.plugins.module_utils.batch.AWSConnection`` が削除されました。代わりに ``AnsibleAWSModule.client()`` を使用してください (https://github.com/ansible-collections/amazon.aws/pull/831)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:720 -msgid "napalm - Removed unused connection plugin." -msgstr "napalm - 未使用の接続プラグインを削除しました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:721 -msgid "net_banner - Use _banner instead." -msgstr "net_banner - 代わりに _banner を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:722 -msgid "net_interface - Use _interfaces instead." -msgstr "net_interface - _interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:723 -msgid "net_l2_interface - Use _l2_interfaces instead." -msgstr "net_l2_interface - _l2_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:724 -msgid "net_l3_interface - Use _l3_interfaces instead." -msgstr "net_l3_interface - _l3_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:725 -msgid "net_linkagg - Use _lag_interfaces instead." -msgstr "net_linkagg - _lag_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:726 -msgid "net_lldp - Use _lldp_global instead." -msgstr "net_lldp - _lldp_global を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:727 -msgid "net_lldp_interface - Use _lldp_interfaces instead." -msgstr "net_lldp_interface - _lldp_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:728 -msgid "net_logging - Use _logging_global instead." -msgstr "net_logging - _logging_global を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:729 -msgid "net_static_route - Use _static_routes instead." -msgstr "net_static_route - _static_routes を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:730 -msgid "net_system - Use _system instead." -msgstr "net_system - _system を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:731 -msgid "net_user - Use _user instead." -msgstr "net_user - _user を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:732 -msgid "net_vlan - Use _vlans instead." -msgstr "net_vlan - _vlans を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:733 -msgid "net_vrf - Use _vrf instead." -msgstr "net_vrf - _vrf を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:738 -msgid "ios_interface - use ios_interfaces instead." -msgstr "ios_interface - ios_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:739 -msgid "ios_l2_interface - use ios_l2_interfaces instead." -msgstr "ios_l2_interface - ios_l2_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:740 -msgid "ios_l3_interface - use ios_l3_interfaces instead." -msgstr "ios_l3_interface - ios_l3_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:741 -msgid "ios_static_route - use ios_static_routes instead." -msgstr "ios_static_route - ios_static_routes を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:742 -msgid "ios_vlan - use ios_vlans instead." -msgstr "ios_vlan - ios_vlans を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:747 -msgid "iosxr_interface - use iosxr_interfaces instead." -msgstr "iosxr_interface - iosxr_interfaces を代わりに使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:752 -msgid "This release removes the following deprecated plugins that have reached their end-of-life." -msgstr "このリリースでは、有効期限の切れた以下の非推奨プラグインを削除しています。" - -#: ../../rst/porting_guides/porting_guide_7.rst:753 -msgid "nxos_acl" -msgstr "nxos_acl" - -#: ../../rst/porting_guides/porting_guide_7.rst:754 -msgid "nxos_acl_interface" -msgstr "nxos_acl_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:755 -msgid "nxos_interface" -msgstr "nxos_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:756 -msgid "nxos_interface_ospf" -msgstr "nxos_interface_ospf" - -#: ../../rst/porting_guides/porting_guide_7.rst:757 -msgid "nxos_l2_interface" -msgstr "nxos_l2_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:758 -msgid "nxos_l3_interface" -msgstr "nxos_l3_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:759 -msgid "nxos_linkagg" -msgstr "nxos_linkagg" - -#: ../../rst/porting_guides/porting_guide_7.rst:760 -msgid "nxos_lldp" -msgstr "nxos_lldp" - -#: ../../rst/porting_guides/porting_guide_7.rst:761 -msgid "nxos_ospf" -msgstr "nxos_ospf" - -#: ../../rst/porting_guides/porting_guide_7.rst:762 -msgid "nxos_ospf_vrf" -msgstr "nxos_ospf_vrf" - -#: ../../rst/porting_guides/porting_guide_7.rst:763 -msgid "nxos_smu" -msgstr "nxos_smu" - -#: ../../rst/porting_guides/porting_guide_7.rst:764 -msgid "nxos_static_route" -msgstr "nxos_static_route" - -#: ../../rst/porting_guides/porting_guide_7.rst:765 -msgid "nxos_vlan" -msgstr "nxos_vlan" - -#: ../../rst/porting_guides/porting_guide_7.rst:770 -msgid "aws_kms_info - the unused and deprecated ``keys_attr`` parameter has been removed (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "aws_kms_info - 未使用および非推奨の ``keys_attr`` パラメーターが削除されました (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:771 -msgid "data_pipeline - the ``version`` option has always been ignored and has been removed (https://github.com/ansible-collections/community.aws/pull/1160\"" -msgstr "data_pipeline - ``version`` オプションは常に無視され、削除されました (https://github.com/ansible-collections/community.aws/pull/1160\"" - -#: ../../rst/porting_guides/porting_guide_7.rst:772 -msgid "ec2_eip - The ``wait_timeout`` option has been removed. It has always been ignored by the module (https://github.com/ansible-collections/community.aws/pull/1159)." -msgstr "ec2_eip - ``wait_timeout`` オプションが削除されました。これは、モジュールによって常に無視されていました (https://github.com/ansible-collections/community.aws/pull/1159)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:773 -msgid "ec2_lc - the ``associate_public_ip_address`` option has been removed. It has always been ignored by the module (https://github.com/ansible-collections/community.aws/pull/1158)." -msgstr "ec2_lc - ``associate_public_ip_address`` オプションが削除されました。これは、モジュールによって常に無視されていました (https://github.com/ansible-collections/community.aws/pull/1158)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:774 -msgid "ec2_metric_alarm - support for using the ``<=``, ``<``, ``>`` and ``>=`` operators for comparison has been dropped. Please use ``LessThanOrEqualToThreshold``, ``LessThanThreshold``, ``GreaterThanThreshold`` or ``GreaterThanOrEqualToThreshold`` instead (https://github.com/ansible-collections/amazon.aws/pull/1164)." -msgstr "ec2_metric_alarm - 比較用の ``<=``、``<``、``>`` および ``>=`` Operator の使用へのサポートは削除されました。代わりに、``LessThanOrEqualToThreshold``、``LessThanThreshold``、``GreaterThanThreshold`` または ``GreaterThanOrEqualToThreshold`` を使用してください (https://github.com/ansible-collections/amazon.aws/pull/1164)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:775 -msgid "ecs_ecr - The deprecated alias ``delete_policy`` has been removed. Please use ``purge_policy`` instead (https://github.com/ansible-collections/community.aws/pull/1161)." -msgstr "ecs_ecr - 非推奨のエイリアス ``delete_policy`` が削除されました。代わりに ``purge_policy`` を使用してください (https://github.com/ansible-collections/community.aws/pull/1161)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:776 -msgid "iam_managed_policy - the unused ``fail_on_delete`` parameter has been removed (https://github.com/ansible-collections/community.aws/pull/1168)" -msgstr "iam_managed_policy - 未使用の ``fail_on_delete`` パラメーターが削除されました (https://github.com/ansible-collections/community.aws/pull/1168)" - -#: ../../rst/porting_guides/porting_guide_7.rst:777 -msgid "s3_lifecycle - the unused parameter ``requester_pays`` has been removed (https://github.com/ansible-collections/community.aws/pull/1165)." -msgstr "s3_lifecycle - 未使用のパラメーター ``requester_pays`` が削除されました (https://github.com/ansible-collections/community.aws/pull/1165)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:778 -msgid "s3_sync - remove unused ``retries`` parameter (https://github.com/ansible-collections/community.aws/pull/1166)." -msgstr "s3_sync - 未使用の ``retries`` パラメーターを削除します (https://github.com/ansible-collections/community.aws/pull/1166)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:783 -msgid "azure_rm_aks_facts, azure_rm_aks_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_aks_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_aks_facts、azure_rm_aks_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_aks_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:784 -msgid "azure_rm_aksversion_facts, azure_rm_aksversion_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_aksversion_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_aksversion_facts、azure_rm_aksversion_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_aksversion_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:785 -msgid "azure_rm_applicationsecuritygroup_facts, azure_rm_applicationsecuritygroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_applicationsecuritygroup_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_applicationsecuritygroup_facts、azure_rm_applicationsecuritygroup_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_applicationsecuritygroup_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:786 -msgid "azure_rm_appserviceplan_facts, azure_rm_appserviceplan_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_appserviceplan_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_appserviceplan_facts、azure_rm_appserviceplan_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_appserviceplan_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:787 -msgid "azure_rm_automationaccount_facts, azure_rm_automationaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_automationaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_automationaccount_facts、azure_rm_automationaccount_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_automationaccount_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:788 -msgid "azure_rm_autoscale_facts, azure_rm_autoscale_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_autoscale_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_autoscale_facts、azure_rm_autoscale_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_autoscale_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:789 -msgid "azure_rm_availabilityset_facts, azure_rm_availabilityset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_availabilityset_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_availabilityset_facts、azure_rm_availabilityset_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_availabilityset_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:790 -msgid "azure_rm_cdnendpoint_facts, azure_rm_cdnendpoint_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cdnendpoint_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_cdnendpoint_facts、azure_rm_cdnendpoint_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_cdnendpoint_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:791 -msgid "azure_rm_cdnprofile_facts, azure_rm_cdnprofile_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cdnprofile_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_cdnprofile_facts、azure_rm_cdnprofile_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_cdnprofile_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:792 -msgid "azure_rm_containerinstance_facts, azure_rm_containerinstance_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_containerinstance_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_containerinstance_facts、azure_rm_containerinstance_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_containerinstance_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:793 -msgid "azure_rm_containerregistry_facts, azure_rm_containerregistry_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_containerregistry_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_containerregistry_facts、azure_rm_containerregistry_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_containerregistry_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:794 -msgid "azure_rm_cosmosdbaccount_facts, azure_rm_cosmosdbaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cosmosdbaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_cosmosdbaccount_facts、azure_rm_cosmosdbaccount_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_cosmosdbaccount_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:795 -msgid "azure_rm_deployment_facts, azure_rm_deployment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_deployment_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_deployment_facts、azure_rm_deployment_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_deployment_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:796 -msgid "azure_rm_devtestlab_facts, azure_rm_devtestlab_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlab_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlab_facts、azure_rm_devtestlab_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlab_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:797 -msgid "azure_rm_devtestlabarmtemplate_facts, azure_rm_devtestlabarmtemplate_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabarmtemplate_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabarmtemplate_facts、azure_rm_devtestlabarmtemplate_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabarmtemplate_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:798 -msgid "azure_rm_devtestlabartifact_facts, azure_rm_devtestlabartifact_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabartifact_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabartifact_facts、azure_rm_devtestlabartifact_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabartifact_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:799 -msgid "azure_rm_devtestlabartifactsource_facts, azure_rm_devtestlabartifactsource_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabartifactsource_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabartifactsource_facts、azure_rm_devtestlabartifactsource_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabartifactsource_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:800 -msgid "azure_rm_devtestlabcustomimage_facts, azure_rm_devtestlabcustomimage_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabcustomimage_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabcustomimage_facts、azure_rm_devtestlabcustomimage_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabcustomimage_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:801 -msgid "azure_rm_devtestlabenvironment_facts, azure_rm_devtestlabenvironment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabenvironment_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabenvironment_facts、azure_rm_devtestlabenvironment_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabenvironment_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:802 -msgid "azure_rm_devtestlabpolicy_facts, azure_rm_devtestlabpolicy_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabpolicy_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabpolicy_facts、azure_rm_devtestlabpolicy_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabpolicy_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:803 -msgid "azure_rm_devtestlabschedule_facts, azure_rm_devtestlabschedule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabschedule_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabschedule_facts、azure_rm_devtestlabschedule_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabschedule_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:804 -msgid "azure_rm_devtestlabvirtualmachine_facts, azure_rm_devtestlabvirtualmachine_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabvirtualmachine_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabvirtualmachine_facts、azure_rm_devtestlabvirtualmachine_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabvirtualmachine_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:805 -msgid "azure_rm_devtestlabvirtualnetwork_facts, azure_rm_devtestlabvirtualnetwork_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabvirtualnetwork_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_devtestlabvirtualnetwork_facts、azure_rm_devtestlabvirtualnetwork_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_devtestlabvirtualnetwork_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:806 -msgid "azure_rm_dnsrecordset_facts, azure_rm_dnsrecordset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_dnsrecordset_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_dnsrecordset_facts、azure_rm_dnsrecordset_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_dnsrecordset_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:807 -msgid "azure_rm_dnszone_facts, azure_rm_dnszone_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_dnszone_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_dnszone_facts、azure_rm_dnszone_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_dnszone_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:808 -msgid "azure_rm_functionapp_facts, azure_rm_functionapp_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_functionapp_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_functionapp_facts、azure_rm_functionapp_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_functionapp_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:809 -msgid "azure_rm_hdinsightcluster_facts, azure_rm_hdinsightcluster_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_hdinsightcluster_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_hdinsightcluster_facts、azure_rm_hdinsightcluster_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_hdinsightcluster_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:810 -msgid "azure_rm_image_facts, azure_rm_image_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_image_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_image_facts、azure_rm_image_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_image_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:811 -msgid "azure_rm_loadbalancer_facts, azure_rm_loadbalancer_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_loadbalancer_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_loadbalancer_facts、azure_rm_loadbalancer_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_loadbalancer_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:812 -msgid "azure_rm_lock_facts, azure_rm_lock_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_lock_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_lock_facts、azure_rm_lock_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_lock_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:813 -msgid "azure_rm_loganalyticsworkspace_facts, azure_rm_loganalyticsworkspace_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_loganalyticsworkspace_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_loganalyticsworkspace_facts、azure_rm_loganalyticsworkspace_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_loganalyticsworkspace_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:814 -msgid "azure_rm_managed_disk, azure_rm_manageddisk - the deprecated modules have been removed. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_managed_disk、azure_rm_manageddisk - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_manageddisk を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:815 -msgid "azure_rm_managed_disk_facts, azure_rm_manageddisk_facts, azure_rm_manageddisk_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_manageddisk_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_managed_disk_facts、azure_rm_manageddisk_facts、azure_rm_manageddisk_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_manageddisk_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:816 -msgid "azure_rm_mariadbconfiguration_facts, azure_rm_mariadbconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mariadbconfiguration_facts、azure_rm_mariadbconfiguration_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mariadbconfiguration_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:817 -msgid "azure_rm_mariadbdatabase_facts, azure_rm_mariadbdatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbdatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mariadbdatabase_facts、azure_rm_mariadbdatabase_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mariadbdatabase_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:818 -msgid "azure_rm_mariadbfirewallrule_facts, azure_rm_mariadbfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mariadbfirewallrule_facts、azure_rm_mariadbfirewallrule_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mariadbfirewallrule_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:819 -msgid "azure_rm_mariadbserver_facts, azure_rm_mariadbserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbserver_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mariadbserver_facts、azure_rm_mariadbserver_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mariadbserver_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:820 -msgid "azure_rm_mysqlconfiguration_facts, azure_rm_mysqlconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mysqlconfiguration_facts、azure_rm_mysqlconfiguration_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mysqlconfiguration_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:821 -msgid "azure_rm_mysqldatabase_facts, azure_rm_mysqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mysqldatabase_facts、azure_rm_mysqldatabase_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mysqldatabase_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:822 -msgid "azure_rm_mysqlfirewallrule_facts, azure_rm_mysqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mysqlfirewallrule_facts、azure_rm_mysqlfirewallrule_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mysqlfirewallrule_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:823 -msgid "azure_rm_mysqlserver_facts, azure_rm_mysqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_mysqlserver_facts、azure_rm_mysqlserver_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_mysqlserver_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:824 -msgid "azure_rm_networkinterface_facts, azure_rm_networkinterface_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_networkinterface_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_networkinterface_facts、azure_rm_networkinterface_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_networkinterface_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:825 -msgid "azure_rm_postgresqlconfiguration_facts, azure_rm_postgresqlconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_postgresqlconfiguration_facts、azure_rm_postgresqlconfiguration_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_postgresqlconfiguration_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:826 -msgid "azure_rm_postgresqldatabase_facts, azure_rm_postgresqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_postgresqldatabase_facts、azure_rm_postgresqldatabase_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_postgresqldatabase_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:827 -msgid "azure_rm_postgresqlfirewallrule_facts, azure_rm_postgresqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_postgresqlfirewallrule_facts、azure_rm_postgresqlfirewallrule_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_postgresqlfirewallrule_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:828 -msgid "azure_rm_postgresqlserver_facts, azure_rm_postgresqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_postgresqlserver_facts、azure_rm_postgresqlserver_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_postgresqlserver_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:829 -msgid "azure_rm_publicipaddress_facts, azure_rm_publicipaddress_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_publicipaddress_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_publicipaddress_facts、azure_rm_publicipaddress_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_publicipaddress_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:830 -msgid "azure_rm_rediscache_facts, azure_rm_rediscache_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_rediscache_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_rediscache_facts、azure_rm_rediscache_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_rediscache_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:831 -msgid "azure_rm_resource_facts, azure_rm_resource_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_resource_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_resource_facts、azure_rm_resource_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_resource_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:832 -msgid "azure_rm_resourcegroup_facts, azure_rm_resourcegroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_resourcegroup_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_resourcegroup_facts、azure_rm_resourcegroup_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_resourcegroup_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:833 -msgid "azure_rm_roleassignment_facts, azure_rm_roleassignment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_roleassignment_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_roleassignment_facts、azure_rm_roleassignment_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_roleassignment_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:834 -msgid "azure_rm_roledefinition_facts, azure_rm_roledefinition_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_roledefinition_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_roledefinition_facts、azure_rm_roledefinition_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_roledefinition_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:835 -msgid "azure_rm_routetable_facts, azure_rm_routetable_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_routetable_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_routetable_facts、azure_rm_routetable_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_routetable_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:836 -msgid "azure_rm_securitygroup_facts, azure_rm_securitygroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_securitygroup_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_securitygroup_facts、azure_rm_securitygroup_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_securitygroup_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:837 -msgid "azure_rm_servicebus_facts, azure_rm_servicebus_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_servicebus_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_servicebus_facts、azure_rm_servicebus_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_servicebus_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:838 -msgid "azure_rm_sqldatabase_facts, azure_rm_sqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_sqldatabase_facts、azure_rm_sqldatabase_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_sqldatabase_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:839 -msgid "azure_rm_sqlfirewallrule_facts, azure_rm_sqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_sqlfirewallrule_facts、azure_rm_sqlfirewallrule_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_sqlfirewallrule_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:840 -msgid "azure_rm_sqlserver_facts, azure_rm_sqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_sqlserver_facts、azure_rm_sqlserver_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_sqlserver_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:841 -msgid "azure_rm_storageaccount_facts, azure_rm_storageaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_storageaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_storageaccount_facts、azure_rm_storageaccount_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_storageaccount_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:842 -msgid "azure_rm_subnet_facts, azure_rm_subnet_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_subnet_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_subnet_facts、azure_rm_subnet_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_subnet_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:843 -msgid "azure_rm_trafficmanagerendpoint_facts, azure_rm_trafficmanagerendpoint_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_trafficmanagerendpoint_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_trafficmanagerendpoint_facts、azure_rm_trafficmanagerendpoint_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_trafficmanagerendpoint_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:844 -msgid "azure_rm_trafficmanagerprofile_facts, azure_rm_trafficmanagerprofile_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_trafficmanagerprofile_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_trafficmanagerprofile_facts、azure_rm_trafficmanagerprofile_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_trafficmanagerprofile_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:845 -msgid "azure_rm_virtualmachine_extension, azure_rm_virtualmachineextension - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachine_extension、azure_rm_virtualmachineextension - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachineextension を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:846 -msgid "azure_rm_virtualmachine_facts, azure_rm_virtualmachine_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachine_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachine_facts、azure_rm_virtualmachine_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachine_info を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:847 -msgid "azure_rm_virtualmachine_scaleset, azure_rm_virtualmachinescaleset - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachine_scaleset、azure_rm_virtualmachinescaleset - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachinescaleset を使用します (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:848 -msgid "azure_rm_virtualmachine_scaleset_facts, azure_rm_virtualmachinescaleset_facts, azure_rm_virtualmachinescaleset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescaleset_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachine_scaleset_facts、azure_rm_virtualmachinescaleset_facts、azure_rm_virtualmachinescaleset_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachinescaleset_info instead を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:849 -msgid "azure_rm_virtualmachineextension_facts, azure_rm_virtualmachineextension_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineextension_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachineextension_facts、azure_rm_virtualmachineextension_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachineextension_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:850 -msgid "azure_rm_virtualmachineimage_facts, azure_rm_virtualmachineimage_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineimage_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachineimage_facts、azure_rm_virtualmachineimage_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachineimage_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:851 -msgid "azure_rm_virtualmachinescalesetextension_facts, azure_rm_virtualmachinescalesetextension_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescalesetextension_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachinescalesetextension_facts、azure_rm_virtualmachinescalesetextension_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachinescalesetextension_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:852 -msgid "azure_rm_virtualmachinescalesetinstance_facts, azure_rm_virtualmachinescalesetinstance_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescalesetinstance_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualmachinescalesetinstance_facts、azure_rm_virtualmachinescalesetinstance_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualmachinescalesetinstance_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:853 -msgid "azure_rm_virtualnetwork_facts, azure_rm_virtualnetwork_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualnetwork_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualnetwork_facts、azure_rm_virtualnetwork_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualnetwork_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:854 -msgid "azure_rm_virtualnetworkpeering_facts, azure_rm_virtualnetworkpeering_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualnetworkpeering_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_virtualnetworkpeering_facts, azure_rm_virtualnetworkpeering_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_virtualnetworkpeering_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:855 -msgid "azure_rm_webapp_facts, azure_rm_webapp_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_webapp_info instead (https://github.com/ansible-collections/community.azure/pull/31)." -msgstr "azure_rm_webapp_facts, azure_rm_webapp_info - 非推奨のモジュールが削除されました。代わりに azure.azcollection.azure_rm_webapp_info を使用してください (https://github.com/ansible-collections/community.azure/pull/31)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:860 -msgid "Execution Environments built with community.docker no longer include docker-compose < 2.0.0. If you need to use it with the ``docker_compose`` module, please install that requirement manually (https://github.com/ansible-collections/community.docker/pull/400)." -msgstr "community.docker でビルドされた実行環境には、docker-compose < 2.0.0 が含まれなくなりました。``docker_compose`` モジュールで使用する必要がある場合は、その要件を手動でインストールしてください (https://github.com/ansible-collections/community.docker/pull/400)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:861 -msgid "Support for Ansible 2.9 and ansible-base 2.10 has been removed. If you need support for Ansible 2.9 or ansible-base 2.10, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400)." -msgstr "Ansible 2.9 および ansible-base 2.10 のサポートが削除されました。Ansible 2.9 または ansible-base 2.10 のサポートが必要な場合は、community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400) を使用してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:862 -msgid "Support for Docker API versions 1.20 to 1.24 has been removed. If you need support for these API versions, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400)." -msgstr "Docker API バージョン 1.20 から 1.24 のサポートが削除されました。これらの API バージョンのサポートが必要な場合は、community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400) を使用してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:863 -msgid "Support for Python 2.6 has been removed. If you need support for Python 2.6, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400)." -msgstr "Python 2.6 のサポートが削除されました。Python 2.6 のサポートが必要な場合は、community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400) を使用してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:864 -msgid "Various modules - the default of ``tls_hostname`` (``localhost``) has been removed. If you want to continue using ``localhost``, you need to specify it explicitly (https://github.com/ansible-collections/community.docker/pull/363)." -msgstr "さまざまなモジュール - ``tls_hostname`` (``localhost``) のデフォルトが削除されました。``localhost`` を引き続き使用する場合は、明示的に指定する必要があります (https://github.com/ansible-collections/community.docker/pull/363)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:865 -msgid "docker_container - the ``all`` value is no longer allowed in ``published_ports``. Use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/399)." -msgstr "docker_container - ``all`` の値は ``published_ports`` で許可されなくなりました。代わりに ``publish_all_ports=true`` を使用してください (https://github.com/ansible-collections/community.docker/pull/399)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:866 -msgid "docker_container - the default of ``command_handling`` was changed from ``compatibility`` to ``correct``. Older versions were warning for every invocation of the module when this would result in a change of behavior (https://github.com/ansible-collections/community.docker/pull/399)." -msgstr "docker_container - ``command_handling`` のデフォルトが ``compatibility`` から ``correct`` に変更されました。古いバージョンでは、動作の変更につながる場合、モジュールの呼び出しごとに警告が表示されていました (https://github.com/ansible-collections/community.docker/pull/399)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:867 -msgid "docker_stack - the return values ``out`` and ``err`` have been removed. Use ``stdout`` and ``stderr`` instead (https://github.com/ansible-collections/community.docker/pull/363)." -msgstr "docker_stack - ``out`` と``err`` の戻り値は削除されました。代わりに ``stdout`` と ``stderr`` を使用してください (https://github.com/ansible-collections/community.docker/pull/363)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:872 -msgid "bitbucket* modules - ``username`` is no longer an alias of ``workspace``, but of ``user`` (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "bitbucket* modules - ``username`` は、``workspace`` のエイリアスではなくなり、``user`` のエイリアスとなりました (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:873 -msgid "gem - the default of the ``norc`` option changed from ``false`` to ``true`` (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "gem - ``norc`` オプションのデフォルトは、``false`` から ``true`` に変更されました (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:874 -msgid "gitlab_group_members - ``gitlab_group`` must now always contain the full path, and no longer just the name or path (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "gitlab_group_members - ``gitlab_group`` は、単に名前とパスだけでなく、今後は常にフルパスを含む必要があります (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:875 -msgid "keycloak_authentication - the return value ``flow`` has been removed. Use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "keycloak_authentication - 戻り値 ``flow`` は削除されました。代わりに ``end_state`` を使用してください (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:876 -msgid "keycloak_group - the return value ``group`` has been removed. Use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "keycloak_group - 戻り値 ``group`` は削除されました。代わりに ``end_state`` を使用してください(https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:877 -msgid "lxd_container - the default of the ``ignore_volatile_options`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "lxd_container - ``ignore_volatile_options`` オプションのデフォルトは、``true`` から ``false`` に変更されました (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:878 -msgid "mail callback plugin - the ``sender`` option is now required (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "mail callback plugin - ``sender`` オプションが必要になりました (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:879 -msgid "module_helper module utils - remove the ``VarDict`` attribute from ``ModuleHelper``. Import ``VarDict`` from ``ansible_collections.community.general.plugins.module_utils.mh.mixins.vars`` instead (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "module_helper module utils - ``ModuleHelper`` から ``VarDict`` 属性を削除します。代わりに ``ansible_collections.community.general.plugins.module_utils.mh.mixins.vars`` から ``VarDict`` をインポートします (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:880 -msgid "proxmox inventory plugin - the default of the ``want_proxmox_nodes_ansible_host`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "proxmox inventory plugin - ``want_proxmox_nodes_ansible_host`` オプションのデフォルトは、``true`` から ``false`` に変更されたました (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:881 -msgid "vmadm - the ``debug`` option has been removed. It was not used anyway (https://github.com/ansible-collections/community.general/pull/5326)." -msgstr "vmadm - ``debug``オプションが削除されました。これは使用されていませんでした (https://github.com/ansible-collections/community.general/pull/5326)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:902 -msgid "vca_fw - The deprecated module ``vca_fw`` has been removed." -msgstr "vca_fw - 非推奨のモジュール ``vca_fw`` は削除されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:903 -msgid "vca_nat - The deprecated module ``vca_nat`` has been removed." -msgstr "vca_nat - 非推奨のモジュール``vca_nat`` は削除されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:904 -msgid "vca_vapp - The deprecated module ``vca_vapp`` has been removed." -msgstr "vca_vapp - 非推奨のモジュール``vca_vapp`` は削除されました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:905 -msgid "vmware_dns_config - The deprecated module ``vmware_dns_config`` has been removed, you can use ``vmware_host_dns`` instead." -msgstr "vmware_dns_config - 非推奨のモジュール ``vmware_dns_config`` は削除されました。代わりに ``vmware_host_dns`` を使用することができます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:906 -msgid "vmware_guest_network - The deprecated parameter ``networks`` has been removed, use loops to handle multiple interfaces (https://github.com/ansible-collections/community.vmware/pull/1459)." -msgstr "vmware_guest_network - 非推奨のパラメーター ``networks`` は削除されました。複数のインターフェイスを処理する場合はループを使用します (https://github.com/ansible-collections/community.vmware/pull/1459)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:907 -msgid "vmware_guest_vnc - The deprecated module ``vmware_guest_vnc`` has been removed. The VNC support has been dropped with vSphere 7 and later (https://github.com/ansible-collections/community.vmware/pull/1454)." -msgstr "vmware_guest_vnc - 非推奨のモジュール ``vmware_guest_vnc`` は削除されました。VNC のサポートは vSphere 7 以降で停止されました (https://github.com/ansible-collections/community.vmware/pull/1454)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:908 -msgid "vmware_host_firewall_manager - The module doesn't accept a list for ``allowed_hosts`` anymore, use a dict instead. Additionally, ``all_ip`` is now a required sub-option of ``allowed_hosts`` (https://github.com/ansible-collections/community.vmware/pull/1463)." -msgstr "vmware_host_firewall_manager - このモジュールは ``allowed_hosts`` のリストを受け付けなくなりました。代わりに dict を使ってください。さらに、``all_ip`` は ``allowed_hosts`` の必須サブオプションとなりました (https://github.com/ansible-collections/community.vmware/pull/1463)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:909 -msgid "vsphere_copy - The deprecated parameters ``host`` and ``login`` have been removed. Use ``hostname`` and ``username`` instead (https://github.com/ansible-collections/community.vmware/pull/1456)." -msgstr "vsphere_copy - 非推奨のパラメーター ``host`` および ``login`` は削除されました。代わりに ``hostname`` と ``username`` を使用してください (https://github.com/ansible-collections/community.vmware/pull/1456)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:914 -msgid "Remove following deprecated Junos Modules." -msgstr "以下の非推奨の Junos モジュールを削除します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:915 -msgid "junos_interface" -msgstr "junos_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:916 -msgid "junos_l2_interface" -msgstr "junos_l2_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:917 -msgid "junos_l3_interface" -msgstr "junos_l3_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:918 -msgid "junos_linkagg" -msgstr "junos_linkagg" - -#: ../../rst/porting_guides/porting_guide_7.rst:919 -msgid "junos_lldp" -msgstr "junos_lldp" - -#: ../../rst/porting_guides/porting_guide_7.rst:920 -msgid "junos_lldp_interface" -msgstr "junos_lldp_interface" - -#: ../../rst/porting_guides/porting_guide_7.rst:921 -msgid "junos_static_route" -msgstr "junos_static_route" - -#: ../../rst/porting_guides/porting_guide_7.rst:922 -msgid "junos_vlan" -msgstr "junos_vlan" - -#: ../../rst/porting_guides/porting_guide_7.rst:927 -msgid "vyos_interface - use vyos_interfaces instead." -msgstr "vyos_interface - 代わりに vyos_interfaces を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:928 -msgid "vyos_l3_interface - use vyos_l3_interfaces instead." -msgstr "vyos_l3_interface - 代わりに vyos_l3_interfaces を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:929 -msgid "vyos_linkagg - use vyos_lag_interfaces instead." -msgstr "vyos_linkagg - 代わりに vyos_lag_interfaces を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:930 -msgid "vyos_lldp - use vyos_lldp_global instead." -msgstr "vyos_lldp - 代わりに vyos_lldp_global を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:931 -msgid "vyos_lldp_interface - use vyos_lldp_interfaces instead." -msgstr "vyos_lldp_interface - 代わりに vyos_lldp_interfaces を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:932 -msgid "vyos_static_route - use vyos_static_routes instead." -msgstr "vyos_static_route - 代わりに vyos_static_routes を使用します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:946 -msgid "Deprecate ability of lookup plugins to return arbitrary data. Lookup plugins must return lists, failing to do so will be an error in 2.18. (https://github.com/ansible/ansible/issues/77788)" -msgstr "ルックアッププラグインが任意のデータを返す機能を非推奨にします。ルックアッププラグインはリストを返す必要があり、失敗すると 2.18 ではエラーになります (https://github.com/ansible/ansible/issues/77788)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:947 -msgid "Encryption - Deprecate use of the Python crypt module due to it's impending removal from Python 3.13" -msgstr "encryption - Python crypt モジュールが Python 3.13 から間もなく削除されるため、使用を非推奨とします。" - -#: ../../rst/porting_guides/porting_guide_7.rst:948 -msgid "PlayContext.verbosity is deprecated and will be removed in 2.18. Use ansible.utils.display.Display().verbosity as the single source of truth." -msgstr "PlayContext.verbosity は非推奨となり、2.18 で削除されます。信頼できる唯一のソースとして ansible.utils.display.Display().verbosity を使用してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:949 -msgid "``DEFAULT_FACT_PATH``, ``DEFAULT_GATHER_SUBSET`` and ``DEFAULT_GATHER_TIMEOUT`` are deprecated and will be removed in 2.18. Use ``module_defaults`` keyword instead." -msgstr "``DEFAULT_FACT_PATH``、``DEFAULT_GATHER_SUBSET``、および ``DEFAULT_GATHER_TIMEOUT`` は非推奨であり、2.18 で削除されます。代わりに ``module_defaults`` キーワードを使用してください。" - -#: ../../rst/porting_guides/porting_guide_7.rst:950 -msgid "``PlayIterator`` - deprecate ``cache_block_tasks`` and ``get_original_task`` which are noop and unused." -msgstr "``PlayIterator`` - noop および未使用の ``cache_block_tasks`` および ``get_original_task`` を非推奨にします。" - -#: ../../rst/porting_guides/porting_guide_7.rst:951 -msgid "``Templar`` - deprecate ``shared_loader_obj`` option which is unused. ``ansible.plugins.loader`` is used directly instead." -msgstr "``Templar`` - 未使用の ``shared_loader_obj`` オプションを非推奨にします。代わりに ``ansible.plugins.loader`` が直接使用されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:952 -msgid "listify_lookup_plugin_terms, deprecate 'loader/dataloader' parameter as it not used." -msgstr "listify_lookup_plugin_terms、loader/dataloader パラメーターは使用されていないため、非推奨となりました。" - -#: ../../rst/porting_guides/porting_guide_7.rst:953 -msgid "vars plugins - determining whether or not to run ansible.legacy vars plugins with the class attribute REQUIRES_WHITELIST is deprecated, set REQUIRES_ENABLED instead." -msgstr "vars プラグイン - クラス属性 REQUIRES_WHITELIST を使用して ansible.legacy vars プラグインを実行するかどうかを判別します。この属性が非推奨となっている場合は、代わりに REQUIRES_ENABLED を設定します。" - -#: ../../rst/porting_guides/porting_guide_7.rst:958 -msgid "amazon.aws collection - Support for the ``EC2_ACCESS_KEY`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``access_key`` parameter or ``AWS_ACCESS_KEY_ID`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``EC2_ACCESS_KEY`` 環境変数のサポートは非推奨となり、2024-12-01 より後のリリースで削除される予定です。代わりに ``access_key`` パラメーターまたは ``AWS_ACCESS_KEY_ID`` 環境変数をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:959 -msgid "amazon.aws collection - Support for the ``EC2_REGION`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``region`` parameter or ``AWS_REGION`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``EC2_REGION`` 環境変数のサポートは非推奨となり、2024-12-01 より後のリリースで削除される予定です。代わりに ``region`` パラメーターまたは ``AWS_REGION`` 環境変数をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:960 -msgid "amazon.aws collection - Support for the ``EC2_SECRET_KEY`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``secret_key`` parameter or ``AWS_SECRET_ACCESS_KEY`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``EC2_SECRET_KEY`` 環境変数のサポートは非推奨となり、2024-12-01 より後のリリースで削除される予定です。代わりに ``secret_key`` パラメーターまたは ``AWS_SECRET_ACCESS_KEY`` 環境変数をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:961 -msgid "amazon.aws collection - Support for the ``EC2_SECURITY_TOKEN`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` parameter or ``AWS_SESSION_TOKEN`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``EC2_SECURITY_TOKEN`` 環境変数のサポートは非推奨となり、2024-12-01 より後のリリースで削除される予定です。代わりに ``session_token`` パラメーターまたは ``AWS_SESSION_TOKEN`` 環境変数をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:962 -msgid "amazon.aws collection - Support for the ``EC2_URL`` and ``S3_URL`` environment variables has been deprecated and will be removed in a release after 2024-12-01. Please use the ``endpoint_url`` parameter or ``AWS_ENDPOINT_URL`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``EC2_URL`` および ``S3_URL`` 環境変数のサポートは非推奨となり、2024-12-01 より後のリリースで削除される予定です。代わりに ``endpoint_url`` パラメーターまたは ``AWS_ENDPOINT_URL`` 環境変数をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:963 -msgid "amazon.aws collection - The ``access_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``session_token`` パラメーターの ``access_token`` エイリアスは非推奨となり、2024 年 12 月 1 日より後のリリースで削除される予定です。代わりに ``session_token`` 名をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:964 -msgid "amazon.aws collection - The ``aws_security_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``session_token`` パラメーターの ``aws_security_token`` エイリアスは非推奨となり、2024 年 12 月 1 日より後のリリースで削除される予定です。代わりに ``session_token`` 名をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:965 -msgid "amazon.aws collection - The ``ec2_access_key`` alias for the ``access_key`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``access_key`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``access_key`` パラメーターの ``ec2_access_key`` エイリアスは非推奨となり、2024 年 12 月 1 日より後のリリースで削除される予定です。代わりに ``access_key`` 名をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:966 -msgid "amazon.aws collection - The ``ec2_region`` alias for the ``region`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``region`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``region`` パラメーターの ``ec2_region`` エイリアスは非推奨となり、2024 年 12 月 1 日より後のリリースで削除される予定です。代わりに ``region`` 名をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:967 -msgid "amazon.aws collection - The ``ec2_secret_key`` alias for the ``secret_key`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``secret_key`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``secret_key`` パラメーターの ``ec2_secret_key`` エイリアスは非推奨となり、2024 年 12 月 1 日より後のリリースで削除される予定です。代わりに ``secret_key`` 名をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:968 -msgid "amazon.aws collection - The ``security_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172)." -msgstr "amazon.aws コレクション - ``session_token`` パラメーターの ``security_token`` エイリアスは非推奨となり、2024 年 12 月 1 日より後のリリースで削除される予定です。代わりに ``session_token`` 名をご利用ください (https://github.com/ansible-collections/amazon.aws/pull/1172)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:969 -msgid "amazon.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in a release after 2023-05-31 (https://github.com/ansible-collections/amazon.aws/pull/935)." -msgstr "amazon.aws コレクション - Python の バージョン 3.7 未満のサポート終了を通知する AWS SDK により (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/)、このコレクションによる Python のバージョン 3.7 未満のサポートは非推奨となり、2023 年 6 月 1 日以降のリリースで削除される予定です (https://github.com/ansible-collections/amazon.aws/pull/935)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:970 -msgid "aws_s3 - The ``S3_URL`` alias for the s3_url option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "aws_s3 - s3_url オプションの ``S3_URL`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:971 -msgid "ec2_ami - The ``DeviceName`` alias for the device_name option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "ec2_ami - device_name オプションの ``DeviceName`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:972 -msgid "ec2_ami - The ``NoDevice`` alias for the no_device option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "ec2_ami - no_device オプションの ``NoDevice`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:973 -msgid "ec2_ami - The ``VirtualName`` alias for the virtual_name option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "ec2_ami - virtual_name オプションの ``VirtualName`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:974 -msgid "ec2_ami - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846)." -msgstr "ec2_ami - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/846)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:976 -msgid "ec2_instance - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/849)." -msgstr "ec2_instance - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/849)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:977 -msgid "ec2_key - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846)." -msgstr "ec2_key - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/846)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:978 -msgid "ec2_security_group - support for passing nested lists to ``cidr_ip`` and ``cidr_ipv6`` has been deprecated. Nested lists can be passed through the ``flatten`` filter instead ``cidr_ip: '{{ my_cidrs | flatten }}'`` (https://github.com/ansible-collections/amazon.aws/pull/1213)." -msgstr "ec2_security_group - ネストされたリストを ``cidr_ip`` および ``cidr_ipv6`` へ渡すためのサポートは非推奨となりました。ネストされたリストは、代わりに ``flatten`` フィルターを通じて渡すことができます ``cidr_ip: '{{ my_cidrs | flatten }}'`` (https://github.com/ansible-collections/amazon.aws/pull/1213)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:979 -msgid "ec2_vol - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846)." -msgstr "ec2_vol - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/846)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:980 -msgid "ec2_vpc_dhcp_option_info - The ``DhcpOptionIds`` alias for the dhcp_option_ids option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "ec2_vpc_dhcp_option_info - dhcp_option_ids オプションの ``DhcpOptionIds`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:981 -msgid "ec2_vpc_dhcp_option_info - The ``DryRun`` alias for the dry_run option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "ec2_vpc_dhcp_option_info - dry_run オプションの ``DryRun`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:982 -msgid "ec2_vpc_endpoint - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846)." -msgstr "ec2_vpc_endpoint - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/846)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:983 -msgid "ec2_vpc_net - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/848)." -msgstr "ec2_vpc_net - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/848)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:984 -msgid "ec2_vpc_route_table - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846)." -msgstr "ec2_vpc_route_table - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます (https://github.com/ansible-collections/amazon.aws/pull/846)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:985 -msgid "inventory/aws_ec2 - the ``include_extra_api_calls`` is now deprecated, its value is silently ignored (https://github.com/ansible-collections/amazon.aws/pull/1097)." -msgstr "inventory/aws_ec2 - ``include_extra_api_calls`` は非推奨となりました。その値はサイレントに無視されます (https://github.com/ansible-collections/amazon.aws/pull/1097)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:986 -msgid "module_utils.cloud - removal of the ``CloudRetry.backoff`` has been delayed until release 6.0.0. It is recommended to update custom modules to use ``jittered_backoff`` or ``exponential_backoff`` instead (https://github.com/ansible-collections/amazon.aws/pull/951)." -msgstr "module_utils.cloud - ``CloudRetry.backoff`` の削除は、リリース 6.0.0 まで延期となりました。代わりに ``jittered_backoff`` または ``exponential_backoff`` を使用するようにカスタムモジュールを更新することが推奨されます (https://github.com/ansible-collections/amazon.aws/pull/951)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:987 -msgid "module_utils.url - ``ansible_collections.amazon.aws.module_utils.urls`` is believed to be unused and has been deprecated and will be removed in release 7.0.0." -msgstr "module_utils.url - ``ansible_collections.amazon.aws.module_utils.urls`` は、使用されていないと考えられるため、非推奨となり、リリース 7.0.0 で削除される予定です。" - -#: ../../rst/porting_guides/porting_guide_7.rst:988 -msgid "s3_bucket - The ``S3_URL`` alias for the s3_url option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795)." -msgstr "s3_bucket - s3_url オプションの ``S3_URL`` エイリアスは非推奨となり、リリース 5.0.0 で削除されます (https://github.com/ansible-collections/community.aws/pull/795)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:989 -msgid "s3_object - Support for creation and deletion of S3 buckets has been deprecated. Please use the ``amazon.aws.s3_bucket`` module to create and delete buckets (https://github.com/ansible-collections/amazon.aws/pull/869)." -msgstr "s3_object - S3 バケットの作成および削除のサポートが非推奨となりました。バケットの作成と削除には、``amazon.aws.s3_bucket`` モジュールを使用してください (https://github.com/ansible-collections/amazon.aws/pull/869)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1004 -msgid "aws_acm - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "aws_acm - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1006 -msgid "aws_glue_connection - the ``connection_parameters`` return key has been deprecated and will be removed in a release after 2024-06-01, it is being replaced by the ``raw_connection_parameters`` key (https://github.com/ansible-collections/community.aws/pull/518)." -msgstr "aws_glue_connection - ``connection_parameters`` の戻りキーは非推奨となり、2024 年 06 月 01 以降のリリースで削除され、``raw_connection_parameters`` キーに置き換えられます (https://github.com/ansible-collections/community.aws/pull/518)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1007 -msgid "aws_kms - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "aws_kms - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1008 -msgid "cloudfront_distribution - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "cloudfront_distribution - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1009 -msgid "community.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in a release after 2023-05-31 (https://github.com/ansible-collections/community.aws/pull/1361)." -msgstr "community.aws コレクション - Python の バージョン 3.7 未満のサポート終了を通知する AWS SDK により (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/)、このコレクションによる Python のバージョン 3.7 未満のサポートは非推奨となり、2023 年 6 月 1 日以降のリリースで削除される予定です (https://github.com/ansible-collections/community.aws/pull/1361)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1010 -msgid "ec2_vpc_vpn - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "ec2_vpc_vpn - ``purge_tags`` の現在の ``False`` のデフォルト値は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1011 -msgid "iam_policy - the ``policies`` return value has been renamed ``policy_names`` and will be removed in a release after 2024-08-01, both values are currently returned (https://github.com/ansible-collections/community.aws/pull/1375)." -msgstr "iam_policy - ``policies`` の戻り値の名前が ``policy_names`` に変更されました。2024 年 8 月 2 日以降のリリースで削除されるため、現在は両方の値が返されます (https://github.com/ansible-collections/community.aws/pull/1375)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1012 -msgid "lambda_info - The ``function`` return key returns a dictionary of dictionaries and has been deprecated. In a release after 2025-01-01, this key will be removed in favor of ``functions``, which returns a list of dictionaries (https://github.com/ansible-collections/community.aws/pull/1239)." -msgstr "lambda_info - の``function`` リターンキーは複数のディクショナリーのうちの 1 つのディクショナリーを返しますが、非推奨となりました。2025 年 1 月 2 日以降のリリースでは、ディクショナリーのリストを返す ``functions`` を優先して、このキーは削除されます (https://github.com/ansible-collections/community.aws/pull/1239)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1013 -msgid "rds_param_group - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "rds_param_group - ``purge_tags`` の現在の ``False`` のデフォルト値は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1014 -msgid "route53_health_check - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "route53_health_check - ``purge_tags`` の現在の ``False`` のデフォルト値は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1015 -msgid "route53_info - The CamelCase return values for ``DelegationSets``, ``CheckerIpRanges``, and ``HealthCheck`` have been deprecated, in the future release you must use snake_case return values ``delegation_sets``, ``checker_ip_ranges``, and ``health_check`` instead respectively\" (https://github.com/ansible-collections/community.aws/pull/1322)." -msgstr "route53_info - ``DelegationSets``、``CheckerIpRanges`` の CamelCase の戻り値および ``HealthCheck`` が非推奨となりました。今後のリリースでは、代わりに ``delegation_sets``、``checker_ip_ranges`` の snake_case の戻り値および ``health_check`` をそれぞれ使用する必要があります (https://github.com/ansible-collections/community.aws/pull/1322)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1017 -msgid "route53_zone - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "route53_zone - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1018 -msgid "sqs_queue - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``." -msgstr "sqs_queue - ``purge_tags`` の現在のデフォルト値 ``False`` は非推奨となり、リリース 5.0.0 で ``True`` に更新されます。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1030 -msgid "docker_container - the ``ignore_image`` option is deprecated and will be removed in community.docker 4.0.0. Use ``image: ignore`` in ``comparisons`` instead (https://github.com/ansible-collections/community.docker/pull/487)." -msgstr "docker_container -``ignore_image`` オプションは非推奨となり、community.docker 4.0.0 で削除されます。代わりに ``comparisons`` では ``image: ignore`` を使用してください (https://github.com/ansible-collections/community.docker/pull/487)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1031 -msgid "docker_container - the ``purge_networks`` option is deprecated and will be removed in community.docker 4.0.0. Use ``networks: strict`` in ``comparisons`` instead, and make sure to provide ``networks``, with value ``[]`` if all networks should be removed (https://github.com/ansible-collections/community.docker/pull/487)." -msgstr "docker_container -``purge_networks`` オプションは非推奨となり、community.docker 4.0.0 で削除されます。代わりに ``comparisons`` では ``networks: strict`` を使用してください。また、すべてのネットワークを削除する必要がある場合は ``[]`` の値で ``networks`` を必ず提供してください (https://github.com/ansible-collections/community.docker/pull/487)。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1044 -msgid "gconftool2 - deprecates ``state=get`` in favor of using the module ``gconftool2_info`` (https://github.com/ansible-collections/community.general/pull/4778)." -msgstr "gconftool2 - モジュール ``gconftool2_info`` (https://github.com/ansible-collections/community.general/pull/4778) を使用するため、``state=get`` は非推奨となります。" - -#: ../../rst/porting_guides/porting_guide_7.rst:1048 -msgid "xfconf - deprecated parameter ``disable_facts``, as since version 4.0.0 it only allows value ``true`` (https://github.com/ansible-collections/community.general/pull/4520)." -msgstr "xfconf - バージョン 4.0.0 以降、値 ``true`` (https://github.com/ansible-collections/community.general/pull/4520) しか許可されないため、パラメーター ``disable_facts`` は非推奨となりました。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:6 -msgid "Ansible-base 2.10 Porting Guide" -msgstr "Ansible-base 2.10 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:10 -msgid "In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide `_. We expect the 2.10 Porting Guide to change frequently up to the 2.10 release. Follow the conversations about collections on our various :ref:`communication` channels for the latest information on the status of the ``devel`` branch." -msgstr "2.10 のリリース準備のために、多くのプラグインおよびモジュールが `Ansible Galaxy `_ の Collection に移行しています。Collection および FAQ の現在の開発ステータスは、「`Ansible Collections コミュニティーガイド `_」を参照してください。2.10 の「移植ガイド」は、2.10 のリリースに合わせて頻繁に変更することを想定しています。``devel`` ブランチのステータスに関する最新情報は、さまざまな :ref:`communication` チャンネルにあるコレクションに関する議論を確認してください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:12 -msgid "This section discusses the behavioral changes between Ansible 2.9 and Ansible-base 2.10." -msgstr "このセクションでは、Ansible 2.9 と Ansible-base 2.10 での動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:14 -msgid "It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible-base." -msgstr "本ガイドは、このバージョンの Ansible-base で動作するように、Playbook、プラグイン、その他の Ansible インフラストラクチャーを更新する際にご利用になります。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:16 -msgid "We suggest you read this page along with the `Ansible-base Changelog for 2.10 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`Ansible-base Changelog for 2.10 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:18 -msgid "Ansible-base is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install ansible." -msgstr "Ansible-base は、主に、利用可能なコレクションのうち、制御された小さなサブセットのみを使用したい開発者やユーザーの興味を引く製品です。一般ユーザーは Ansible をインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:20 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:16 -msgid "The complete list of porting guides can be found at :ref:`porting guides `." -msgstr "移植ガイドの完全なリストは、「:ref:`porting guides `」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_base_2.10.rst:23 -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:18 -msgid "Contents" -msgstr "コンテンツ" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:6 -msgid "Ansible-core 2.11 Porting Guide" -msgstr "Ansible-core 2.11 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:8 -msgid "This section discusses the behavioral changes between ``ansible-base`` 2.10 and ``ansible-core`` 2.11." -msgstr "このセクションでは、``ansible-base`` 2.10 から ``ansible-core`` 2.11 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:10 -msgid "It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they work with this version of ``ansible-core``." -msgstr "本ガイドは、このバージョンの ``ansible-core`` で動作するように、Playbook、プラグイン、その他の Ansible インフラストラクチャーを更新する際にご利用になれます。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:12 -msgid "We suggest you read this page along with the `ansible-core Changelog for 2.11 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`ansible-core Changelog for 2.11 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_core_2.11.rst:14 -msgid "``ansible-core`` is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install Ansible." -msgstr "``ansible-core`` は、主に、利用可能なコレクションのうち、制御された小さなサブセットのみを使用したい開発者やユーザーの興味を引く製品です。一般ユーザーは Ansible をインストールしてください。" - -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:6 -msgid "Ansible-core 2.12 Porting Guide" -msgstr "Ansible-core 2.12 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:8 -msgid "This section discusses the behavioral changes between ``ansible-core`` 2.11 and ``ansible-core`` 2.12." -msgstr "このセクションでは、``ansible-core`` 2.11 から ``ansible-core`` 2.12 における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:12 -msgid "We suggest you read this page along with `ansible-core Changelog for 2.12 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`ansible-core Changelog for 2.12 `_」を参照してください。" - -#: ../../rst/porting_guides/porting_guide_core_2.12.rst:115 -msgid "``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256`` now default to the \"2b\" format and if the \"2a\" format is required it must be specified." -msgstr "``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256`` はデフォルトで「2b」フォーマットになり、「2a」フォーマットが必要な場合は指定する必要があります。" - -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:6 -msgid "Ansible-core 2.13 Porting Guide" -msgstr "Ansible-core 2.13 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:8 -msgid "This section discusses the behavioral changes between ``ansible-core`` 2.12 and ``ansible-core`` 2.13." -msgstr "このセクションでは、``ansible-core`` 2.12 と ``ansible-core`` 2.13 間における動作の変更点を説明します。" - -#: ../../rst/porting_guides/porting_guide_core_2.13.rst:12 -msgid "We suggest you read this page along with `ansible-core Changelog for 2.13 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`ansible-core Changelog for 2.13 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:6 -msgid "Ansible-core 2.14 Porting Guide" -msgstr "Ansible-core 2.14 移植ガイド" - -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:8 -msgid "This section discusses the behavioral changes between ``ansible-core`` 2.13 and ``ansible-core`` 2.14." -msgstr "このセクションでは、``ansible-core`` 2.13 と ``ansible-core`` 2.14 間における動作の変更点について説明します。" - -#: ../../rst/porting_guides/porting_guide_core_2.14.rst:12 -msgid "We suggest you read this page along with `ansible-core Changelog for 2.14 `_ to understand what updates you may need to make." -msgstr "必要な更新について理解するには、このページと併せて「`ansible-core Changelog for 2.14 `_」を参照することをお勧めします。" - -#: ../../rst/porting_guides/porting_guides.rst:5 -msgid "Ansible Porting Guides" -msgstr "Ansible 移植ガイド" - -#: ../../rst/porting_guides/porting_guides.rst:7 -msgid "This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of Ansible to the next." -msgstr "本セクションでは、Ansible のあるバージョンから次のバージョンに、Ansible インフラストラクチャーの Playbook、プラグインなどを更新するのに役に立つ移植ガイドを紹介します。" - -#~ msgid "We suggest you read this page along with the `ansible-core Changelog for 2.11 `_ to understand what updates you may need to make." -#~ msgstr "" - -#~ msgid "The configuration system now validates the ``choices`` field, so any settings that currently violate it and are currently ignored will now cause an error. For example, `ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0` will now cause an error (valid chioces are 'ignore', 'warn' or 'error'." -#~ msgstr "" - -#~ msgid "Due to a scheduling conflict, the latest version of Ansible 2.10 (2.10.7) has a few collections which are newer than Ansible 3.0.0. Ansible 3.1.0 will contain updated versions of those collections." -#~ msgstr "スケジュールの都合上、Ansible 2.10 の最新版 (2.10.7) には、Ansible 3.0.0 よりも新しいコレクションがいくつかあります。Ansible 3.1.0 には、これらのコレクションのアップデート版が含まれます。" - -#~ msgid "Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 will continue to work with the same versions of Python that ``ansible-base`` 2.10 worked with, however it will emit a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater." -#~ msgstr "コントローラーノードの Python 3.8 は、本リリースではソフト要件です。``ansible-core`` 2.11 は、``ansible-base`` 2.10 が動作したのと同じバージョンの Python で引き続き機能しますが、Python バージョンが 3.8 未満のコントローラーノードで実行すると警告が表示されます。この警告は、お使いの環境に ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` を設定して無効にできます。``ansible-core`` 2.12 の場合は Python 3.8 以降が必要になります。" - -#~ msgid "The configuration system now validates the ``choices`` field, so any settings that currently violate it and are currently ignored will now cause an error. For example, `ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0` will now cause an error (valid choices are 'ignore', 'warn' or 'error')." -#~ msgstr "設定システムは ``choices`` フィールドを検証するため、現在それに違反している設定があるとエラーが生じます。たとえば、`ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0` を選択すると、エラーが発生します (有効な選択肢は「ignore」、「warn」、または「error」です)。" - -#~ msgid "delegate_to vs ProxyCommand" -#~ msgstr "delegate_to 対 ProxyCommand" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/reference_appendices.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/reference_appendices.po deleted file mode 100644 index d06d1e91feb..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/reference_appendices.po +++ /dev/null @@ -1,11604 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:5 -msgid "YAML Syntax" -msgstr "YAML 構文" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:7 -msgid "This page provides a basic overview of correct YAML syntax, which is how Ansible playbooks (our configuration management language) are expressed." -msgstr "このページでは、Ansible Playbook (Ansible での設定管理言語) の表現方法である、正しい YAML 構文について概説します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:10 -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." -msgstr "Ansible では、XML や JSON などのような一般的なその他のデータ形式に比べて人間による解読および記述が簡単であるため、YAML を使用しています。さらに、プログラミング言語の多くには、YAML に対応するライブラリーが提供されています。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:14 -msgid "You may also wish to read :ref:`working_with_playbooks` at the same time to see how this is used in practice." -msgstr ":ref:`working_with_playbooks` も合わせて参照し、実際にどのように使用されているかを確認してください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:19 -msgid "YAML Basics" -msgstr "YAML の基礎" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:21 -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." -msgstr "Ansible で使用する場合は、YAML ファイルのほぼすべてがリストで開始します。リストの各項目は、一般的に「ハッシュ」または「ディクショナリー」と呼ばれるキー/値のペアのリストとなっています。そのため、YAML でリストとディクショナリーを記述する方法を理解する必要があります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:26 -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." -msgstr "YAML には、他にもわずかな特徴があります。YAML ファイルはすべて (Ansible との関係の有無に関係なく)、必要に応じて ``---`` で開始して ``...`` で終わらせることができます。これは、YAML 形式の一部で、ドキュメントの最初と最後を示します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:29 -msgid "All members of a list are lines beginning at the same indentation level starting with a ``\"- \"`` (a dash and a space):" -msgstr "リストのメンバーはすべて同じインデントレベルで、``\"- \"`` (ダッシュとスペース) で開始する行になります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:41 -msgid "A dictionary is represented in a simple ``key: value`` form (the colon must be followed by a space):" -msgstr "ディクショナリーは、シンプルな ``key: value`` の形式で表現します (コロンの後にはスペースを挿入する必要があります)。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:51 -msgid "More complicated data structures are possible, such as lists of dictionaries, dictionaries whose values are lists or a mix of both:" -msgstr "リストがディクショナリーやその値の場合や、ディクショナリーと値が混合している場合など、より複雑なデータ構造も可能です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:71 -msgid "Dictionaries and lists can also be represented in an abbreviated form if you really want to:" -msgstr "ディクショナリーとリストは、必要であれば、略語形式で表現することも可能です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:79 -msgid "These are called \"Flow collections\"." -msgstr "以下は「フローコレクション」と呼ばれます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:83 -msgid "Ansible doesn't really use these too much, but you can also specify a :ref:`boolean value ` (true/false) in several forms:" -msgstr "Ansible では以下の形式はあまり使用されませんが、:ref:`boolean value ` を複数の形式で指定することもできます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:93 -msgid "Use lowercase 'true' or 'false' for boolean values in dictionaries if you want to be compatible with default yamllint options." -msgstr "デフォルトの yamllint オプションと互換性を持たせる場合は、ディクショナリーのブール値に小文字の「true」または「false」を使用します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:95 -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:" -msgstr "値は、``|`` または ``>`` を使用することで複数の行にまたがって指定することができます。「リテラル形式のブロックスカラー」 ``|`` を使用して複数行にまたがる場合は、改行と末尾のスペースが含まれます。「折り畳み形式のブロックスカラー」 ``>`` を使用すると、折り返しに使用される改行はすべてスペースに変換されます。これは、非常に長い行を読みやすく、編集しやすくするために使われます。いずれの場合も、インデントは無視されます。以下に例を示します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:112 -msgid "While in the above ``>`` example all newlines are folded into spaces, there are two ways to enforce a newline to be kept:" -msgstr "上記の ``>`` の例では、改行はすべてスペースに変換されますが、強制的に改行を行う方法が 2 種類あります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:125 -msgid "Alternatively, it can be enforced by including newline ``\\n`` characters:" -msgstr "あるいは、改行 ``\\n" -"`` 文字を含めることで強制できます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:131 -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:" -msgstr "これまでに説明した内容を、任意の YAML の例にまとめてみましょう。以下は、Ansible とは関係ありませんが、どのような形式になるかを示しています。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:156 -msgid "That's all you really need to know about YAML to start writing `Ansible` playbooks." -msgstr "`Ansible` Playbook の記述を開始するにあたり、以上が YAML について理解しておく必要のある内容です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:159 -msgid "Gotchas" -msgstr "Gotchas" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:161 -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." -msgstr "引用符で囲まれていないスカラーには何でも挿入できますが、一部例外があります。コロンの後にスペース (または改行) を続けて記述 (``\": \"``) した場合は、マッピングを示すインジケーターになります。スペースに続けてポンド記号を記述 (``\" #\"``) した場合は、コメントの開始を表します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:165 -msgid "Because of this, the following is going to result in a YAML syntax error:" -msgstr "このため、以下のような場合には、YAML 構文がエラーになります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:173 -msgid "...but this will work:" -msgstr "...ただし、以下は有効です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:179 -msgid "You will want to quote hash values using colons followed by a space or the end of the line:" -msgstr "コロンを使用してハッシュ記号を引用し、その後ろにスペースを指定するか、行末にしてください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:187 -msgid "...and then the colon will be preserved." -msgstr "...そしてコロンが保存されます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:189 -msgid "Alternatively, you can use double quotes:" -msgstr "または、二重引用符を使用してください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:197 -msgid "The difference between single quotes and double quotes is that in double quotes you can use escapes:" -msgstr "二重引用符ではエスケープを使用できる点が、一重引用符と二重引用符との相違点です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:204 -msgid "The list of allowed escapes can be found in the YAML Specification under \"Escape Sequences\" (YAML 1.1) or \"Escape Characters\" (YAML 1.2)." -msgstr "使用可能なエスケープの一覧は、YAML 仕様の「Escape Sequences」(YAML 1.1) または「Escape Characters」(YAML 1.2) を参照してください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:206 -msgid "The following is invalid YAML:" -msgstr "以下は無効な YAML です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:213 -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:" -msgstr "さらに、Ansible は変数に \"{{ var }}\" を使用します。コロンの後に \"{\" が指定されている場合は、その値がディクショナリーであると YAML が認識するため、以下のように引用する必要があります::" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:220 -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:" -msgstr "値を引用符でする場合は、値の一部だけでなく、値全体を引用符で囲む必要があります。値を引用する方法について正しい例を以下に示します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:228 -msgid "Not valid:" -msgstr "以下は有効ではありません。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:234 -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: ``[] {} > | * & ! % # ` @ ,``." -msgstr "``'`` および ``\"`` 以外に、引用符で囲まれていないスカラーの最初の文字として使用できない特殊文字 (予約文字) がいくつかあります (``[] {} > | * & ! % # ` @ ,`` など)。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:237 -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." -msgstr "また、``? : -`` には常に注意してください。YAML では、スペース以外の文字が続く場合は、文字列の先頭で許可されますが、YAML プロセッサーの実装は異なるため、引用符を使用することが推奨されます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:240 -msgid "In Flow Collections, the rules are a bit more strict:" -msgstr "フローコレクションでは、ルールはもう少し厳密です。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:248 -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:" -msgstr "ブール値の変換は便利ですが、リテラルの `yes` や、文字列として他のブール値を指定する場合など問題になる場合があります。この場合は、引用符だけを使用します。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:257 -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:" -msgstr "YAML は、特定の文字列を文字列 `1.0` などの浮動小数点値に変換します。(たとえば requirements.yml ファイルで) バージョン番号を指定する必要があり、それが浮動小数点の値のように見える場合は、その値を引用符で囲む必要があります。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:269 -#: ../../rst/reference_appendices/faq.rst:925 -#: ../../rst/reference_appendices/glossary.rst:536 -#: ../../rst/reference_appendices/test_strategies.rst:296 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:270 -msgid "Learn what playbooks can do and how to write/run them." -msgstr "Playbook でできることと、Playbook を記述および実行する方法を学びます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:271 -msgid "`YAMLLint `_" -msgstr "`YAMLLint `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:272 -msgid "YAML Lint (online) helps you debug YAML syntax if you are having problems" -msgstr "YAML ヒント (オンライン) は、問題が発生した場合に YAML 構文のデバッグに役立ちます。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:273 -msgid "`GitHub examples directory `_" -msgstr "`GitHub examples directory `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:274 -msgid "Complete playbook files from the github project source" -msgstr "Github プロジェクトソースの完全な Playbook ファイル" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:275 -msgid "`Wikipedia YAML syntax reference `_" -msgstr "`Wikipedia YAML syntax reference `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:276 -msgid "A good guide to YAML syntax" -msgstr "YAML 構文の適切なガイド" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:277 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:278 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:279 -#: ../../rst/reference_appendices/common_return_values.rst:250 -#: ../../rst/reference_appendices/glossary.rst:542 -#: ../../rst/reference_appendices/release_and_maintenance.rst:394 -#: ../../rst/reference_appendices/test_strategies.rst:302 -msgid ":ref:`communication_irc`" -msgstr ":ref:`communication_irc`" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:280 -msgid "How to join Ansible chat channels (join #yaml for yaml-specific questions)" -msgstr "Ansible チャットチャンネルに参加する方法 (yaml 固有の質問は #yaml に参加してください)" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:282 -msgid "`YAML 1.1 Specification `_" -msgstr "`YAML 1.1 Specification `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:282 -msgid "The Specification for YAML 1.1, which PyYAML and libyaml are currently implementing" -msgstr "PyYAML および libyaml が現在実装されている YAML 1.1 の仕様" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:284 -msgid "`YAML 1.2 Specification `_" -msgstr "`YAML 1.2 Specification `_" - -#: ../../rst/reference_appendices/YAMLSyntax.rst:285 -msgid "For completeness, YAML 1.2 is the successor of 1.1" -msgstr "完全を期すため、YAML 1.2 は 1.1 の後継となります。" - -#: ../../rst/reference_appendices/automationhub.rst:4 -msgid "Ansible Automation Hub" -msgstr "Ansible Automation Hub" - -#: ../../rst/reference_appendices/automationhub.rst:8 -msgid "Red Hat Ansible Automation Platform will soon be available on Microsoft Azure. `Sign up to preview the experience `_." -msgstr "Red Hat Ansible Automation Platform は、まもなく Microsoft Azure でも使用できるようになります。`Sign up to preview the experience `_。" - -#: ../../rst/reference_appendices/automationhub.rst:10 -msgid "`Ansible Automation Hub `_ is the official location to discover and download supported :ref:`collections `, included as part of an Ansible Automation Platform subscription. These content collections contain modules, plugins, roles, and playbooks in a downloadable package." -msgstr "`Ansible Automation Hub `_ は、Ansible Platform サブスクリプションに同梱される、サポート対象の :ref:`コレクション ` を検出してダウンロードする公式の場所です。このようなコンテンツコレクションでは、ダウンロード可能なパッケージにモジュール、プラグイン、ロール、Playbook が含まれます。" - -#: ../../rst/reference_appendices/automationhub.rst:12 -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 パートナー組織別に検索できます。" - -#: ../../rst/reference_appendices/automationhub.rst:14 -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 `_. 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 `_」を参照してください。Ansible Automation Hub は、Red Hat Ansible Automation Platform サブスクリプションで利用でき、Red Hat, Inc のサポートが含まれています。" - -#: ../../rst/reference_appendices/common_return_values.rst:4 -msgid "Return Values" -msgstr "戻り値" - -#: ../../rst/reference_appendices/common_return_values.rst:6 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/reference_appendices/common_return_values.rst:8 -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`)." -msgstr "Ansible のモジュールは通常、データ構造を返します。このデータ構造は、変数に登録したり、`ansible` プログラムで出力されたときに直接確認したりできます。各モジュールは任意で、独自の戻り値をドキュメント化できます (ansible-doc や :ref:`メインのドキュメントサイト` で確認できます)。" - -#: ../../rst/reference_appendices/common_return_values.rst:11 -msgid "This document covers return values common to all modules." -msgstr "本ガイドでは、全モジュールに共通する戻り値を説明します。" - -#: ../../rst/reference_appendices/common_return_values.rst:13 -msgid "Some of these keys might be set by Ansible itself once it processes the module's return information." -msgstr "モジュールの戻り値情報の処理が終わると、Ansible によりこのキーの一部が設定される場合があります。" - -#: ../../rst/reference_appendices/common_return_values.rst:17 -msgid "Common" -msgstr "共通" - -#: ../../rst/reference_appendices/common_return_values.rst:20 -msgid "backup_file" -msgstr "backup_file" - -#: ../../rst/reference_appendices/common_return_values.rst:21 -msgid "For those modules that implement `backup=no|yes` when manipulating files, a path to the backup file created." -msgstr "ファイルを操作するときに `backup=no|yes` を実装するモジュール向け。作成したバックアップファイルへのパス。" - -#: ../../rst/reference_appendices/common_return_values.rst:29 -#: ../../rst/reference_appendices/config.rst:497 -msgid "changed" -msgstr "changed" - -#: ../../rst/reference_appendices/common_return_values.rst:30 -msgid "A boolean indicating if the task had to make changes to the target or delegated host." -msgstr "タスクがターゲットまたは委任されたホストに変更を加える必要があるかどうかを示すブール値。" - -#: ../../rst/reference_appendices/common_return_values.rst:37 -#: ../../rst/reference_appendices/playbooks_keywords.rst:62 -#: ../../rst/reference_appendices/playbooks_keywords.rst:200 -#: ../../rst/reference_appendices/playbooks_keywords.rst:296 -#: ../../rst/reference_appendices/playbooks_keywords.rst:407 -msgid "diff" -msgstr "diff" - -#: ../../rst/reference_appendices/common_return_values.rst:38 -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." -msgstr "直前と現在の状態の相違点に関する情報。通常、``before`` と ``after`` のエントリーが含まれるディクショナリーを指し、callback プラグインによって、このディクショナリーが相違点のビュー書式に整えられます。" - -#: ../../rst/reference_appendices/common_return_values.rst:55 -msgid "failed" -msgstr "失敗" - -#: ../../rst/reference_appendices/common_return_values.rst:56 -msgid "A boolean that indicates if the task was failed or not." -msgstr "タスクが失敗したかどうかを示すブール値。" - -#: ../../rst/reference_appendices/common_return_values.rst:63 -msgid "invocation" -msgstr "invocation" - -#: ../../rst/reference_appendices/common_return_values.rst:64 -msgid "Information on how the module was invoked." -msgstr "モジュールがどのように呼び出されたかを示す情報。" - -#: ../../rst/reference_appendices/common_return_values.rst:96 -msgid "msg" -msgstr "msg" - -#: ../../rst/reference_appendices/common_return_values.rst:97 -msgid "A string with a generic message relayed to the user." -msgstr "ユーザーに渡される一般的なメッセージを含む文字列。" - -#: ../../rst/reference_appendices/common_return_values.rst:104 -msgid "rc" -msgstr "rc" - -#: ../../rst/reference_appendices/common_return_values.rst:105 -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." -msgstr "コマンドラインユーティリティーを実行したり、(raw、shell、command など) 直接コマンドを実行するように設定されているモジュール。このフィールドにはこのようなユーティリティーの「戻りコード」が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:112 -msgid "results" -msgstr "results" - -#: ../../rst/reference_appendices/common_return_values.rst:113 -msgid "If this key exists, it indicates that a loop was present for the task and that it contains a list of the normal module 'result' per item." -msgstr "このキーが存在する場合には、タスクに対してループが存在し、アイテムごとに通常のモジュールの「結果」が含まれていることを示します。" - -#: ../../rst/reference_appendices/common_return_values.rst:175 -msgid "skipped" -msgstr "スキップ済" - -#: ../../rst/reference_appendices/common_return_values.rst:176 -msgid "A boolean that indicates if the task was skipped or not" -msgstr "タスクがスキップされたかどうかを示すブール値。" - -#: ../../rst/reference_appendices/common_return_values.rst:183 -msgid "stderr" -msgstr "stderr" - -#: ../../rst/reference_appendices/common_return_values.rst:184 -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." -msgstr "コマンドラインユーティリティーを実行したり、(raw、shell、command などの) コマンドを直接実行するように調整されているモジュール。このフィールドにはこのようなユーティリティーのエラー出力が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:191 -msgid "stderr_lines" -msgstr "stderr_lines" - -#: ../../rst/reference_appendices/common_return_values.rst:192 -msgid "When `stderr` is returned we also always provide this field which is a list of strings, one item per line from the original." -msgstr "`stderr` が返されると、文字列のリストであるこのフィールドも常に表示されます (元の出力の 1 行に 1 項目)。" - -#: ../../rst/reference_appendices/common_return_values.rst:201 -msgid "stdout" -msgstr "stdout" - -#: ../../rst/reference_appendices/common_return_values.rst:202 -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." -msgstr "コマンドラインユーティリティーを実行したり、(raw、shell、command などの) コマンドを直接実行するように調整されているモジュール。このフィールドにはこのようなユーティリティーの通常出力が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:209 -msgid "stdout_lines" -msgstr "stdout_lines" - -#: ../../rst/reference_appendices/common_return_values.rst:210 -msgid "When `stdout` is returned, Ansible always provides a list of strings, each containing one item per line from the original output." -msgstr "`stdout` が返されると、Ansible は常に文字列のリスト (元の出力の 1 行に項目を 1 つ含める) を渡します。" - -#: ../../rst/reference_appendices/common_return_values.rst:222 -msgid "Internal use" -msgstr "Ansible 内での使用" - -#: ../../rst/reference_appendices/common_return_values.rst:224 -msgid "These keys can be added by modules but will be removed from registered variables; they are 'consumed' by Ansible itself." -msgstr "以下のキーはモジュールで追加できますが、登録変数からは削除されます。これらのキーは、Ansible 自体が「使用」します。" - -#: ../../rst/reference_appendices/common_return_values.rst:227 -#: ../../rst/reference_appendices/special_variables.rst:139 -msgid "ansible_facts" -msgstr "ansible_facts" - -#: ../../rst/reference_appendices/common_return_values.rst:228 -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." -msgstr "このキーには、ホストに割り当てられたファクトに追加するディクショナリーが含まれているはずです。このキーは、直接アクセスでき、登録変数を使用する必要はありません。" - -#: ../../rst/reference_appendices/common_return_values.rst:231 -msgid "exception" -msgstr "exception" - -#: ../../rst/reference_appendices/common_return_values.rst:232 -msgid "This key can contain traceback information caused by an exception in a module. It will only be displayed on high verbosity (-vvv)." -msgstr "このキーには、モジュールの例外で発生したトレースバックの情報が含まれます。これは、詳細レベルが高い (-vvv) 場合に限り表示されます。" - -#: ../../rst/reference_appendices/common_return_values.rst:235 -msgid "warnings" -msgstr "warnings" - -#: ../../rst/reference_appendices/common_return_values.rst:236 -msgid "This key contains a list of strings that will be presented to the user." -msgstr "このキーには、ユーザーに表示される文字列の一覧が含まれます。" - -#: ../../rst/reference_appendices/common_return_values.rst:239 -msgid "deprecations" -msgstr "deprecations" - -#: ../../rst/reference_appendices/common_return_values.rst:240 -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." -msgstr "このキーには、ユーザーに表示されるディクショナリー一覧が含まれます。ディクショナリーのキーは `msg` と `version` で、値は文字列です。`version` キーの値は空白の文字列にすることができます。" - -#: ../../rst/reference_appendices/common_return_values.rst:244 -#: ../../rst/reference_appendices/test_strategies.rst:294 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/reference_appendices/common_return_values.rst:245 -#: ../../rst/reference_appendices/test_strategies.rst:295 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/reference_appendices/common_return_values.rst:246 -msgid "`GitHub modules directory `_" -msgstr "`GitHub モジュールディレクトリー `_" - -#: ../../rst/reference_appendices/common_return_values.rst:247 -msgid "Browse source of core and extras modules" -msgstr "コアモジュールおよび追加モジュールのソースの参照" - -#: ../../rst/reference_appendices/common_return_values.rst:248 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/reference_appendices/common_return_values.rst:249 -msgid "Development mailing list" -msgstr "開発メーリングリスト" - -#: ../../rst/reference_appendices/common_return_values.rst:251 -#: ../../rst/reference_appendices/glossary.rst:543 -#: ../../rst/reference_appendices/release_and_maintenance.rst:395 -#: ../../rst/reference_appendices/test_strategies.rst:303 -msgid "How to join Ansible chat channels" -msgstr "Ansible チャットチャンネルへの参加方法" - -#: ../../rst/reference_appendices/config.rst:5 -msgid "Ansible Configuration Settings" -msgstr "Ansible 構成設定" - -#: ../../rst/reference_appendices/config.rst:7 -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." -msgstr "``ansible-config`` ユーティリティーを使用すると、ユーザーは利用可能なすべての構成設定、デフォルト値、設定方法、および現在の値を受け取る場所を確認できます。詳細は「:ref:`ansible-config`」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:15 -msgid "The configuration file" -msgstr "設定ファイル" - -#: ../../rst/reference_appendices/config.rst:17 -msgid "Changes can be made and used in a configuration file which will be searched for in the following order:" -msgstr "変更を行い、次の順序で検索される構成ファイルで使用できます。" - -#: ../../rst/reference_appendices/config.rst:19 -#: ../../rst/reference_appendices/general_precedence.rst:34 -msgid "``ANSIBLE_CONFIG`` (environment variable if set)" -msgstr "``ANSIBLE_CONFIG`` (設定されている場合は環境変数メソッド)" - -#: ../../rst/reference_appendices/config.rst:20 -#: ../../rst/reference_appendices/general_precedence.rst:35 -msgid "``ansible.cfg`` (in the current directory)" -msgstr "``ansible.cfg`` (現在のディレクトリー)" - -#: ../../rst/reference_appendices/config.rst:21 -#: ../../rst/reference_appendices/general_precedence.rst:36 -msgid "``~/.ansible.cfg`` (in the home directory)" -msgstr "``~/.ansible.cfg`` (ホームディレクトリー)" - -#: ../../rst/reference_appendices/config.rst:22 -#: ../../rst/reference_appendices/general_precedence.rst:37 -msgid "``/etc/ansible/ansible.cfg``" -msgstr "``/etc/ansible/ansible.cfg``" - -#: ../../rst/reference_appendices/config.rst:24 -msgid "Ansible will process the above list and use the first file found, all others are ignored." -msgstr "Ansible は上記の一覧を処理し、見つかった最初のファイルを使用しますが、その他はすべて無視されます。" - -#: ../../rst/reference_appendices/config.rst:28 -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::" -msgstr "設定ファイルは、INI 形式の 1 つのバリアントです。コメントが行を開始する場合は、ハッシュ記号 (``#``) とセミコロン (``;``) の両方がコメントマーカーとして許可されます。ただし、コメントが通常の値でインラインである場合は、セミコロンだけがコメントを追加できます。以下に例を示します。" - -#: ../../rst/reference_appendices/config.rst:42 -msgid "Generating a sample ``ansible.cfg`` file" -msgstr "サンプルの ``ansible.cfg`` ファイル生成" - -#: ../../rst/reference_appendices/config.rst:44 -msgid "You can generate a fully commented-out example ``ansible.cfg`` file, for example::" -msgstr "すべてコメントアウトした ``ansible.cfg`` のサンプルファイルを生成できます。例::" - -#: ../../rst/reference_appendices/config.rst:48 -msgid "You can also have a more complete file that includes existing plugins::" -msgstr "また、既存のプラグインを含むより完全なファイルを作成することもできます。" - -#: ../../rst/reference_appendices/config.rst:52 -msgid "You can use these as starting points to create your own ``ansible.cfg`` file." -msgstr "これらを出発点として使用して、独自の ``ansible.cfg`` ファイルを作成できます。" - -#: ../../rst/reference_appendices/config.rst:57 -msgid "Avoiding security risks with ``ansible.cfg`` in the current directory" -msgstr "現行ディレクトリーで ``ansible.cfg`` を使用したセキュリティーリスクを回避" - -#: ../../rst/reference_appendices/config.rst:60 -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." -msgstr "Ansible が、グローバルで書き込み可能な現在の作業ディレクトリーから ``ansible.cfg`` を読み込んだ場合は、深刻なセキュリティーリスクが発生します。別のユーザーが、場合により昇格した権限で Ansible がローカルとリモートの両方で悪意のあるコードを実行するように設計された独自の構成ファイルをそこに配置できます。そのため、ディレクトリーが誰でも書き込み可能な状態である場合、Ansible は現在の作業ディレクトリーから設定ファイルを自動的に読み込みません。" - -#: ../../rst/reference_appendices/config.rst:67 -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 を実行しているユーザーおよびグループが読み取りおよび書き込みをできるようになり、他のユーザーには許可しないようにすることができます。正しい設定の詳細は、以下を参照してください。" - -#: ../../rst/reference_appendices/config.rst:78 -msgid "for Vagrant, the `Vagrant documentation `_ covers synced folder permissions." -msgstr "Vagrant の場合、`Vagrant ドキュメント `_ は同期されたフォルダーのパーミッションに対応します。" - -#: ../../rst/reference_appendices/config.rst:79 -msgid "for WSL, the `WSL docs `_ and this `Microsoft blog post `_ cover mount options." -msgstr "WSL の場合、`WSL ドキュメント `_ および `Microsoft のブログ投稿 `_ はマウントオプションに対応しています。" - -#: ../../rst/reference_appendices/config.rst:82 -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." -msgstr "誰でも書き込み可能な現在の作業ディレクトリーに Ansible 設定を保存することを完全に依存している場合は、:envvar:`ANSIBLE_CONFIG` 環境変数を介して設定ファイルを明示的に指定できます。セキュリティーに関する懸念を軽減するための適切な手順を実行してください。" - -#: ../../rst/reference_appendices/config.rst:89 -msgid "Relative paths for configuration" -msgstr "設定の相対パス" - -#: ../../rst/reference_appendices/config.rst:91 -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``." -msgstr "多くの設定オプションに相対パスを指定できます。ほとんどの場合、使用されるパスは、現在の実行に使用される ``ansible.cfg`` ファイルの相対パスになります。現在の作業ディレクトリー (CWD) への相対パスが必要な場合は、``{{CWD}}`` マクロを使用して指定できます。相対パスのルートとして CWD を使用するとセキュリティーリスクが発生する可能性があるため、この方法は推奨されません。たとえば、``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml`` となります。" - -#: ../../rst/reference_appendices/config.rst:101 -msgid "Common Options" -msgstr "共通オプション" - -#: ../../rst/reference_appendices/config.rst:103 -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." -msgstr "これは、リリースで利用可能なオプションのコピーで、追加プラグインにより、ローカルインストールに追加のオプションが存在する可能性があります。上記のコマンドラインユーティリティー (`ansible-config`) を使用して、これらを閲覧することができます。" - -#: ../../rst/reference_appendices/config.rst:111 -msgid "ACTION_WARNINGS" -msgstr "ACTION_WARNINGS" - -#: ../../rst/reference_appendices/config.rst -msgid "Description" -msgstr "説明" - -#: ../../rst/reference_appendices/config.rst:113 -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." -msgstr "デフォルトでは、Ansible はタスクアクション (モジュールまたは action プラグイン) から受け取ると、警告を False に調整することで警告を非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst -msgid "Type" -msgstr "タイプ" - -#: ../../rst/reference_appendices/config.rst:114 -#: ../../rst/reference_appendices/config.rst:129 -#: ../../rst/reference_appendices/config.rst:211 -#: ../../rst/reference_appendices/config.rst:240 -#: ../../rst/reference_appendices/config.rst:256 -#: ../../rst/reference_appendices/config.rst:270 -#: ../../rst/reference_appendices/config.rst:286 -#: ../../rst/reference_appendices/config.rst:301 -#: ../../rst/reference_appendices/config.rst:460 -#: ../../rst/reference_appendices/config.rst:1000 -#: ../../rst/reference_appendices/config.rst:1013 -#: ../../rst/reference_appendices/config.rst:1027 -#: ../../rst/reference_appendices/config.rst:1041 -#: ../../rst/reference_appendices/config.rst:1055 -#: ../../rst/reference_appendices/config.rst:1177 -#: ../../rst/reference_appendices/config.rst:1234 -#: ../../rst/reference_appendices/config.rst:1399 -#: ../../rst/reference_appendices/config.rst:1414 -#: ../../rst/reference_appendices/config.rst:1428 -#: ../../rst/reference_appendices/config.rst:1443 -#: ../../rst/reference_appendices/config.rst:1602 -#: ../../rst/reference_appendices/config.rst:1616 -#: ../../rst/reference_appendices/config.rst:1675 -#: ../../rst/reference_appendices/config.rst:1785 -#: ../../rst/reference_appendices/config.rst:1867 -#: ../../rst/reference_appendices/config.rst:1976 -#: ../../rst/reference_appendices/config.rst:1990 -#: ../../rst/reference_appendices/config.rst:2032 -#: ../../rst/reference_appendices/config.rst:2047 -#: ../../rst/reference_appendices/config.rst:2106 -#: ../../rst/reference_appendices/config.rst:2121 -#: ../../rst/reference_appendices/config.rst:2237 -#: ../../rst/reference_appendices/config.rst:2363 -#: ../../rst/reference_appendices/config.rst:2395 -#: ../../rst/reference_appendices/config.rst:2437 -#: ../../rst/reference_appendices/config.rst:2453 -#: ../../rst/reference_appendices/config.rst:2607 -#: ../../rst/reference_appendices/config.rst:2622 -#: ../../rst/reference_appendices/config.rst:2638 -#: ../../rst/reference_appendices/config.rst:2707 -#: ../../rst/reference_appendices/config.rst:2721 -#: ../../rst/reference_appendices/config.rst:2734 -#: ../../rst/reference_appendices/config.rst:2954 -#: ../../rst/reference_appendices/config.rst:2998 -#: ../../rst/reference_appendices/config.rst:3048 -msgid "boolean" -msgstr "boolean" - -#: ../../rst/reference_appendices/config.rst -msgid "Default" -msgstr "デフォルト" - -#: ../../rst/reference_appendices/config.rst:115 -#: ../../rst/reference_appendices/config.rst:130 -#: ../../rst/reference_appendices/config.rst:461 -#: ../../rst/reference_appendices/config.rst:1868 -#: ../../rst/reference_appendices/config.rst:1977 -#: ../../rst/reference_appendices/config.rst:1991 -#: ../../rst/reference_appendices/config.rst:2048 -#: ../../rst/reference_appendices/config.rst:2122 -#: ../../rst/reference_appendices/config.rst:2364 -#: ../../rst/reference_appendices/config.rst:2396 -#: ../../rst/reference_appendices/config.rst:2438 -#: ../../rst/reference_appendices/config.rst:2608 -#: ../../rst/reference_appendices/config.rst:2623 -#: ../../rst/reference_appendices/config.rst:2639 -#: ../../rst/reference_appendices/config.rst:2735 -#: ../../rst/reference_appendices/config.rst:2955 -#: ../../rst/reference_appendices/config.rst:2999 -#: ../../rst/reference_appendices/config.rst:3063 -msgid "``True``" -msgstr "``True``" - -#: ../../rst/reference_appendices/config.rst -msgid "Version Added" -msgstr "追加されたバージョン" - -#: ../../rst/reference_appendices/config.rst:116 -#: ../../rst/reference_appendices/config.rst:131 -#: ../../rst/reference_appendices/config.rst:2108 -#: ../../rst/reference_appendices/config.rst:2397 -#: ../../rst/reference_appendices/config.rst:2970 -#: ../../rst/reference_appendices/config.rst:2985 -msgid "2.5" -msgstr "2.5" - -#: ../../rst/reference_appendices/config.rst -msgid "Ini" -msgstr "Ini" - -#: ../../rst/reference_appendices/config.rst -msgid "Section" -msgstr "セクション" - -#: ../../rst/reference_appendices/config.rst:118 -#: ../../rst/reference_appendices/config.rst:162 -#: ../../rst/reference_appendices/config.rst:167 -#: ../../rst/reference_appendices/config.rst:187 -#: ../../rst/reference_appendices/config.rst:200 -#: ../../rst/reference_appendices/config.rst:214 -#: ../../rst/reference_appendices/config.rst:229 -#: ../../rst/reference_appendices/config.rst:243 -#: ../../rst/reference_appendices/config.rst:259 -#: ../../rst/reference_appendices/config.rst:275 -#: ../../rst/reference_appendices/config.rst:290 -#: ../../rst/reference_appendices/config.rst:319 -#: ../../rst/reference_appendices/config.rst:334 -#: ../../rst/reference_appendices/config.rst:347 -#: ../../rst/reference_appendices/config.rst:360 -#: ../../rst/reference_appendices/config.rst:373 -#: ../../rst/reference_appendices/config.rst:387 -#: ../../rst/reference_appendices/config.rst:401 -#: ../../rst/reference_appendices/config.rst:406 -#: ../../rst/reference_appendices/config.rst:429 -#: ../../rst/reference_appendices/config.rst:444 -#: ../../rst/reference_appendices/config.rst:446 -#: ../../rst/reference_appendices/config.rst:463 -#: ../../rst/reference_appendices/config.rst:950 -#: ../../rst/reference_appendices/config.rst:989 -#: ../../rst/reference_appendices/config.rst:1004 -#: ../../rst/reference_appendices/config.rst:1016 -#: ../../rst/reference_appendices/config.rst:1030 -#: ../../rst/reference_appendices/config.rst:1124 -#: ../../rst/reference_appendices/config.rst:1138 -#: ../../rst/reference_appendices/config.rst:1152 -#: ../../rst/reference_appendices/config.rst:1166 -#: ../../rst/reference_appendices/config.rst:1180 -#: ../../rst/reference_appendices/config.rst:1193 -#: ../../rst/reference_appendices/config.rst:1206 -#: ../../rst/reference_appendices/config.rst:1223 -#: ../../rst/reference_appendices/config.rst:1238 -#: ../../rst/reference_appendices/config.rst:1252 -#: ../../rst/reference_appendices/config.rst:1266 -#: ../../rst/reference_appendices/config.rst:1282 -#: ../../rst/reference_appendices/config.rst:1303 -#: ../../rst/reference_appendices/config.rst:1320 -#: ../../rst/reference_appendices/config.rst:1334 -#: ../../rst/reference_appendices/config.rst:1348 -#: ../../rst/reference_appendices/config.rst:1363 -#: ../../rst/reference_appendices/config.rst:1375 -#: ../../rst/reference_appendices/config.rst:1388 -#: ../../rst/reference_appendices/config.rst:1403 -#: ../../rst/reference_appendices/config.rst:1417 -#: ../../rst/reference_appendices/config.rst:1447 -#: ../../rst/reference_appendices/config.rst:1461 -#: ../../rst/reference_appendices/config.rst:1475 -#: ../../rst/reference_appendices/config.rst:1489 -#: ../../rst/reference_appendices/config.rst:1503 -#: ../../rst/reference_appendices/config.rst:1516 -#: ../../rst/reference_appendices/config.rst:1527 -#: ../../rst/reference_appendices/config.rst:1540 -#: ../../rst/reference_appendices/config.rst:1551 -#: ../../rst/reference_appendices/config.rst:1563 -#: ../../rst/reference_appendices/config.rst:1577 -#: ../../rst/reference_appendices/config.rst:1591 -#: ../../rst/reference_appendices/config.rst:1605 -#: ../../rst/reference_appendices/config.rst:1619 -#: ../../rst/reference_appendices/config.rst:1636 -#: ../../rst/reference_appendices/config.rst:1650 -#: ../../rst/reference_appendices/config.rst:1664 -#: ../../rst/reference_appendices/config.rst:1678 -#: ../../rst/reference_appendices/config.rst:1692 -#: ../../rst/reference_appendices/config.rst:1704 -#: ../../rst/reference_appendices/config.rst:1718 -#: ../../rst/reference_appendices/config.rst:1746 -#: ../../rst/reference_appendices/config.rst:1760 -#: ../../rst/reference_appendices/config.rst:1774 -#: ../../rst/reference_appendices/config.rst:1788 -#: ../../rst/reference_appendices/config.rst:1801 -#: ../../rst/reference_appendices/config.rst:1815 -#: ../../rst/reference_appendices/config.rst:1829 -#: ../../rst/reference_appendices/config.rst:1843 -#: ../../rst/reference_appendices/config.rst:1856 -#: ../../rst/reference_appendices/config.rst:1871 -#: ../../rst/reference_appendices/config.rst:1885 -#: ../../rst/reference_appendices/config.rst:1897 -#: ../../rst/reference_appendices/config.rst:1910 -#: ../../rst/reference_appendices/config.rst:1923 -#: ../../rst/reference_appendices/config.rst:1937 -#: ../../rst/reference_appendices/config.rst:1951 -#: ../../rst/reference_appendices/config.rst:1965 -#: ../../rst/reference_appendices/config.rst:1979 -#: ../../rst/reference_appendices/config.rst:1993 -#: ../../rst/reference_appendices/config.rst:2036 -#: ../../rst/reference_appendices/config.rst:2050 -#: ../../rst/reference_appendices/config.rst:2064 -#: ../../rst/reference_appendices/config.rst:2078 -#: ../../rst/reference_appendices/config.rst:2095 -#: ../../rst/reference_appendices/config.rst:2110 -#: ../../rst/reference_appendices/config.rst:2124 -#: ../../rst/reference_appendices/config.rst:2138 -#: ../../rst/reference_appendices/config.rst:2366 -#: ../../rst/reference_appendices/config.rst:2399 -#: ../../rst/reference_appendices/config.rst:2413 -#: ../../rst/reference_appendices/config.rst:2441 -#: ../../rst/reference_appendices/config.rst:2563 -#: ../../rst/reference_appendices/config.rst:2579 -#: ../../rst/reference_appendices/config.rst:2625 -#: ../../rst/reference_appendices/config.rst:2642 -#: ../../rst/reference_appendices/config.rst:2656 -#: ../../rst/reference_appendices/config.rst:2670 -#: ../../rst/reference_appendices/config.rst:2696 -#: ../../rst/reference_appendices/config.rst:2711 -#: ../../rst/reference_appendices/config.rst:2807 -#: ../../rst/reference_appendices/config.rst:2825 -#: ../../rst/reference_appendices/config.rst:2840 -#: ../../rst/reference_appendices/config.rst:2852 -#: ../../rst/reference_appendices/config.rst:2868 -#: ../../rst/reference_appendices/config.rst:2882 -#: ../../rst/reference_appendices/config.rst:2900 -#: ../../rst/reference_appendices/config.rst:2914 -#: ../../rst/reference_appendices/config.rst:2929 -#: ../../rst/reference_appendices/config.rst:2957 -#: ../../rst/reference_appendices/config.rst:3002 -#: ../../rst/reference_appendices/config.rst:3017 -#: ../../rst/reference_appendices/config.rst:3037 -#: ../../rst/reference_appendices/config.rst:3051 -#: ../../rst/reference_appendices/config.rst:3066 -#: ../../rst/reference_appendices/config.rst:3081 -#: ../../rst/reference_appendices/config.rst:3096 -#: ../../rst/reference_appendices/config.rst:3111 -#: ../../rst/reference_appendices/config.rst:3126 -#: ../../rst/reference_appendices/config.rst:3166 -msgid "[defaults]" -msgstr "[defaults]" - -#: ../../rst/reference_appendices/config.rst -msgid "Key" -msgstr "キー" - -#: ../../rst/reference_appendices/config.rst:119 -msgid "action_warnings" -msgstr "action_warnings" - -#: ../../rst/reference_appendices/config.rst -msgid "Environment" -msgstr "環境" - -#: ../../rst/reference_appendices/config.rst -msgid "Variable" -msgstr "変数" - -#: ../../rst/reference_appendices/config.rst:121 -msgid ":envvar:`ANSIBLE_ACTION_WARNINGS`" -msgstr ":envvar:`ANSIBLE_ACTION_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:126 -msgid "AGNOSTIC_BECOME_PROMPT" -msgstr "AGNOSTIC_BECOME_PROMPT" - -#: ../../rst/reference_appendices/config.rst:128 -#: ../../rst/reference_appendices/config.rst:3298 -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:133 -#: ../../rst/reference_appendices/config.rst:304 -#: ../../rst/reference_appendices/config.rst:1044 -#: ../../rst/reference_appendices/config.rst:1058 -#: ../../rst/reference_appendices/config.rst:1071 -#: ../../rst/reference_appendices/config.rst:1084 -#: ../../rst/reference_appendices/config.rst:1097 -#: ../../rst/reference_appendices/config.rst:1110 -msgid "[privilege_escalation]" -msgstr "[privilege_escalation]" - -#: ../../rst/reference_appendices/config.rst:134 -msgid "agnostic_become_prompt" -msgstr "agnostic_become_prompt" - -#: ../../rst/reference_appendices/config.rst:136 -msgid ":envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`" -msgstr ":envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`" - -#: ../../rst/reference_appendices/config.rst:141 -msgid "ANSIBLE_CONNECTION_PATH" -msgstr "ANSIBLE_CONNECTION_PATH" - -#: ../../rst/reference_appendices/config.rst:143 -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." -msgstr "ansible-connection スクリプトを探す場所を指定します。この場所は、$PATH の検索前に確認されます。null に設定すると、Ansible は ansible スクリプトと同じディレクトリーで起動します。" - -#: ../../rst/reference_appendices/config.rst:144 -#: ../../rst/reference_appendices/config.rst:225 -#: ../../rst/reference_appendices/config.rst:315 -#: ../../rst/reference_appendices/config.rst:946 -#: ../../rst/reference_appendices/config.rst:1486 -#: ../../rst/reference_appendices/config.rst:1661 -#: ../../rst/reference_appendices/config.rst:1948 -#: ../../rst/reference_appendices/config.rst:2151 -#: ../../rst/reference_appendices/config.rst:2166 -#: ../../rst/reference_appendices/config.rst:2223 -#: ../../rst/reference_appendices/config.rst:2294 -#: ../../rst/reference_appendices/config.rst:2348 -#: ../../rst/reference_appendices/config.rst:2790 -#: ../../rst/reference_appendices/config.rst:2804 -#: ../../rst/reference_appendices/config.rst:2836 -#: ../../rst/reference_appendices/config.rst:2879 -msgid "path" -msgstr "path" - -#: ../../rst/reference_appendices/config.rst:145 -#: ../../rst/reference_appendices/config.rst:185 -#: ../../rst/reference_appendices/config.rst:316 -#: ../../rst/reference_appendices/config.rst:358 -#: ../../rst/reference_appendices/config.rst:947 -#: ../../rst/reference_appendices/config.rst:1069 -#: ../../rst/reference_appendices/config.rst:1082 -#: ../../rst/reference_appendices/config.rst:1487 -#: ../../rst/reference_appendices/config.rst:1525 -#: ../../rst/reference_appendices/config.rst:1634 -#: ../../rst/reference_appendices/config.rst:1662 -#: ../../rst/reference_appendices/config.rst:1690 -#: ../../rst/reference_appendices/config.rst:1949 -#: ../../rst/reference_appendices/config.rst:2209 -#: ../../rst/reference_appendices/config.rst:2681 -#: ../../rst/reference_appendices/config.rst:2837 -#: ../../rst/reference_appendices/config.rst:2880 -msgid "``None``" -msgstr "``None``" - -#: ../../rst/reference_appendices/config.rst:146 -#: ../../rst/reference_appendices/config.rst:332 -#: ../../rst/reference_appendices/config.rst:2076 -#: ../../rst/reference_appendices/config.rst:2382 -#: ../../rst/reference_appendices/config.rst:2411 -#: ../../rst/reference_appendices/config.rst:2427 -#: ../../rst/reference_appendices/config.rst:2709 -#: ../../rst/reference_appendices/config.rst:2850 -#: ../../rst/reference_appendices/config.rst:2927 -#: ../../rst/reference_appendices/config.rst:3035 -#: ../../rst/reference_appendices/config.rst:3109 -msgid "2.8" -msgstr "2.8" - -#: ../../rst/reference_appendices/config.rst:148 -#: ../../rst/reference_appendices/config.rst:2751 -#: ../../rst/reference_appendices/config.rst:2765 -#: ../../rst/reference_appendices/config.rst:2779 -#: ../../rst/reference_appendices/config.rst:2793 -msgid "[persistent_connection]" -msgstr "[persistent_connection]" - -#: ../../rst/reference_appendices/config.rst:149 -msgid "ansible_connection_path" -msgstr "ansible_connection_path" - -#: ../../rst/reference_appendices/config.rst:151 -msgid ":envvar:`ANSIBLE_CONNECTION_PATH`" -msgstr ":envvar:`ANSIBLE_CONNECTION_PATH`" - -#: ../../rst/reference_appendices/config.rst:156 -#: ../../rst/reference_appendices/config.rst:176 -#: ../../rst/reference_appendices/config.rst:3213 -msgid "ANSIBLE_COW_ACCEPTLIST" -msgstr "ANSIBLE_COW_ACCEPTLIST" - -#: ../../rst/reference_appendices/config.rst:158 -#: ../../rst/reference_appendices/config.rst:3207 -#: ../../rst/reference_appendices/config.rst:3217 -msgid "Accept list of cowsay templates that are 'safe' to use, set to empty list if you want to enable all installed templates." -msgstr "「安全」に使用できる cowsay テンプレートの許可リスト。インストールされたすべてのテンプレートを有効にする場合は空のリストに設定します。" - -#: ../../rst/reference_appendices/config.rst:159 -#: ../../rst/reference_appendices/config.rst:398 -#: ../../rst/reference_appendices/config.rst:1263 -#: ../../rst/reference_appendices/config.rst:1472 -#: ../../rst/reference_appendices/config.rst:1729 -#: ../../rst/reference_appendices/config.rst:1934 -#: ../../rst/reference_appendices/config.rst:2135 -#: ../../rst/reference_appendices/config.rst:2179 -#: ../../rst/reference_appendices/config.rst:2250 -#: ../../rst/reference_appendices/config.rst:2307 -#: ../../rst/reference_appendices/config.rst:2334 -#: ../../rst/reference_appendices/config.rst:2425 -#: ../../rst/reference_appendices/config.rst:2532 -#: ../../rst/reference_appendices/config.rst:2560 -#: ../../rst/reference_appendices/config.rst:2576 -#: ../../rst/reference_appendices/config.rst:2667 -#: ../../rst/reference_appendices/config.rst:2693 -#: ../../rst/reference_appendices/config.rst:2940 -#: ../../rst/reference_appendices/config.rst:2968 -#: ../../rst/reference_appendices/config.rst:2983 -#: ../../rst/reference_appendices/config.rst:3077 -#: ../../rst/reference_appendices/config.rst:3092 -#: ../../rst/reference_appendices/config.rst:3163 -msgid "list" -msgstr "list" - -#: ../../rst/reference_appendices/config.rst:160 -msgid "``['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake', 'elephant', 'eyes', 'hellokitty', 'kitty', 'luke-koala', 'meow', 'milk', 'moofasa', 'moose', 'ren', 'sheep', 'small', 'stegosaurus', 'stimpy', 'supermilker', 'three-eyes', 'turkey', 'turtle', 'tux', 'udder', 'vader-koala', 'vader', 'www']``" -msgstr "``['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake', 'elephant', 'eyes', 'hellokitty', 'kitty', 'luke-koala', 'meow', 'milk', 'moofasa', 'moose', 'ren', 'sheep', 'small', 'stegosaurus', 'stimpy', 'supermilker', 'three-eyes', 'turkey', 'turtle', 'tux', 'udder', 'vader-koala', 'vader', 'www']``" - -#: ../../rst/reference_appendices/config.rst:163 -msgid "cow_whitelist" -msgstr "cow_whitelist" - -#: ../../rst/reference_appendices/config.rst -msgid "Deprecated in" -msgstr "非推奨になるバージョン" - -#: ../../rst/reference_appendices/config.rst:164 -#: ../../rst/reference_appendices/config.rst:174 -#: ../../rst/reference_appendices/config.rst:403 -#: ../../rst/reference_appendices/config.rst:411 -#: ../../rst/reference_appendices/config.rst:3211 -#: ../../rst/reference_appendices/config.rst:3641 -#: ../../rst/reference_appendices/release_and_maintenance.rst:83 -msgid "2.15" -msgstr "2.15" - -#: ../../rst/reference_appendices/config.rst -msgid "Deprecated detail" -msgstr "非推奨の詳細" - -#: ../../rst/reference_appendices/config.rst:165 -#: ../../rst/reference_appendices/config.rst:175 -#: ../../rst/reference_appendices/config.rst:404 -#: ../../rst/reference_appendices/config.rst:412 -#: ../../rst/reference_appendices/config.rst:3212 -#: ../../rst/reference_appendices/config.rst:3642 -msgid "normalizing names to new standard" -msgstr "名前を新しい標準に正規化" - -#: ../../rst/reference_appendices/config.rst -msgid "Deprecated alternatives" -msgstr "非推奨の代替手段" - -#: ../../rst/reference_appendices/config.rst:166 -#: ../../rst/reference_appendices/config.rst:168 -msgid "cowsay_enabled_stencils" -msgstr "cowsay_enabled_stencils" - -#: ../../rst/reference_appendices/config.rst:169 -#: ../../rst/reference_appendices/config.rst:172 -#: ../../rst/reference_appendices/config.rst:248 -#: ../../rst/reference_appendices/config.rst:408 -#: ../../rst/reference_appendices/config.rst:415 -#: ../../rst/reference_appendices/config.rst:2153 -#: ../../rst/reference_appendices/config.rst:3221 -#: ../../rst/reference_appendices/config.rst:3245 -#: ../../rst/reference_appendices/config.rst:3651 -#: ../../rst/reference_appendices/release_and_maintenance.rst:87 -msgid "2.11" -msgstr "2.11" - -#: ../../rst/reference_appendices/config.rst:171 -msgid ":envvar:`ANSIBLE_COW_ACCEPTLIST`" -msgstr ":envvar:`ANSIBLE_COW_ACCEPTLIST`" - -#: ../../rst/reference_appendices/config.rst:173 -msgid ":envvar:`ANSIBLE_COW_WHITELIST`" -msgstr ":envvar:`ANSIBLE_COW_WHITELIST`" - -#: ../../rst/reference_appendices/config.rst:181 -msgid "ANSIBLE_COW_PATH" -msgstr "ANSIBLE_COW_PATH" - -#: ../../rst/reference_appendices/config.rst:183 -#: ../../rst/reference_appendices/config.rst:3258 -msgid "Specify a custom cowsay path or swap in your cowsay implementation of choice" -msgstr "選択する Cowsay 実装でカスタムの Cowsay パスまたは swap を指定します。" - -#: ../../rst/reference_appendices/config.rst:184 -#: ../../rst/reference_appendices/config.rst:1204 -#: ../../rst/reference_appendices/config.rst:1314 -#: ../../rst/reference_appendices/config.rst:2087 -#: ../../rst/reference_appendices/config.rst:2925 -#: ../../rst/reference_appendices/config.rst:3028 -msgid "string" -msgstr "string" - -#: ../../rst/reference_appendices/config.rst:188 -msgid "cowpath" -msgstr "cowpath" - -#: ../../rst/reference_appendices/config.rst:190 -msgid ":envvar:`ANSIBLE_COW_PATH`" -msgstr ":envvar:`ANSIBLE_COW_PATH`" - -#: ../../rst/reference_appendices/config.rst:195 -msgid "ANSIBLE_COW_SELECTION" -msgstr "ANSIBLE_COW_SELECTION" - -#: ../../rst/reference_appendices/config.rst:197 -#: ../../rst/reference_appendices/config.rst:3199 -msgid "This allows you to chose a specific cowsay stencil for the banners or use 'random' to cycle through them." -msgstr "これにより、バナーの特定の cowsay ステンシルを選択するか、「random」を使用してバナーを循環させることができます。" - -#: ../../rst/reference_appendices/config.rst:198 -#: ../../rst/reference_appendices/config.rst:1744 -#: ../../rst/reference_appendices/config.rst:1921 -msgid "``default``" -msgstr "``default``" - -#: ../../rst/reference_appendices/config.rst:201 -msgid "cow_selection" -msgstr "cow_selection" - -#: ../../rst/reference_appendices/config.rst:203 -msgid ":envvar:`ANSIBLE_COW_SELECTION`" -msgstr ":envvar:`ANSIBLE_COW_SELECTION`" - -#: ../../rst/reference_appendices/config.rst:208 -msgid "ANSIBLE_FORCE_COLOR" -msgstr "ANSIBLE_FORCE_COLOR" - -#: ../../rst/reference_appendices/config.rst:210 -#: ../../rst/reference_appendices/config.rst:3226 -msgid "This option forces color mode even when running without a TTY or the \"nocolor\" setting is True." -msgstr "このオプションは、TTY を使用せずに実行し、または「nocolor」設定が True であっても色モードを強制的に実行します。" - -#: ../../rst/reference_appendices/config.rst:212 -#: ../../rst/reference_appendices/config.rst:241 -#: ../../rst/reference_appendices/config.rst:257 -#: ../../rst/reference_appendices/config.rst:271 -#: ../../rst/reference_appendices/config.rst:287 -#: ../../rst/reference_appendices/config.rst:302 -#: ../../rst/reference_appendices/config.rst:1001 -#: ../../rst/reference_appendices/config.rst:1014 -#: ../../rst/reference_appendices/config.rst:1028 -#: ../../rst/reference_appendices/config.rst:1042 -#: ../../rst/reference_appendices/config.rst:1056 -#: ../../rst/reference_appendices/config.rst:1178 -#: ../../rst/reference_appendices/config.rst:1235 -#: ../../rst/reference_appendices/config.rst:1400 -#: ../../rst/reference_appendices/config.rst:1415 -#: ../../rst/reference_appendices/config.rst:1429 -#: ../../rst/reference_appendices/config.rst:1444 -#: ../../rst/reference_appendices/config.rst:1603 -#: ../../rst/reference_appendices/config.rst:1617 -#: ../../rst/reference_appendices/config.rst:1676 -#: ../../rst/reference_appendices/config.rst:1786 -#: ../../rst/reference_appendices/config.rst:1908 -#: ../../rst/reference_appendices/config.rst:2005 -#: ../../rst/reference_appendices/config.rst:2033 -#: ../../rst/reference_appendices/config.rst:2107 -#: ../../rst/reference_appendices/config.rst:2194 -#: ../../rst/reference_appendices/config.rst:2454 -#: ../../rst/reference_appendices/config.rst:2469 -#: ../../rst/reference_appendices/config.rst:2547 -#: ../../rst/reference_appendices/config.rst:2594 -#: ../../rst/reference_appendices/config.rst:2708 -#: ../../rst/reference_appendices/config.rst:2722 -#: ../../rst/reference_appendices/config.rst:2866 -#: ../../rst/reference_appendices/config.rst:2912 -#: ../../rst/reference_appendices/config.rst:3049 -#: ../../rst/reference_appendices/config.rst:3108 -msgid "``False``" -msgstr "``False``" - -#: ../../rst/reference_appendices/config.rst:215 -msgid "force_color" -msgstr "force_color" - -#: ../../rst/reference_appendices/config.rst:217 -msgid ":envvar:`ANSIBLE_FORCE_COLOR`" -msgstr ":envvar:`ANSIBLE_FORCE_COLOR`" - -#: ../../rst/reference_appendices/config.rst:222 -msgid "ANSIBLE_HOME" -msgstr "ANSIBLE_HOME" - -#: ../../rst/reference_appendices/config.rst:224 -#: ../../rst/reference_appendices/config.rst:3183 -msgid "The default root path for Ansible config files on the controller." -msgstr "コントローラー上の Ansible 設定ファイルのデフォルトのルートパス。" - -#: ../../rst/reference_appendices/config.rst:226 -msgid "``~/.ansible``" -msgstr "``~/.ansible``" - -#: ../../rst/reference_appendices/config.rst:227 -#: ../../rst/reference_appendices/config.rst:2609 -#: ../../rst/reference_appendices/release_and_maintenance.rst:84 -msgid "2.14" -msgstr "2.14" - -#: ../../rst/reference_appendices/config.rst:230 -msgid "home" -msgstr "home" - -#: ../../rst/reference_appendices/config.rst:232 -msgid ":envvar:`ANSIBLE_HOME`" -msgstr ":envvar:`ANSIBLE_HOME`" - -#: ../../rst/reference_appendices/config.rst:237 -msgid "ANSIBLE_NOCOLOR" -msgstr "ANSIBLE_NOCOLOR" - -#: ../../rst/reference_appendices/config.rst:239 -#: ../../rst/reference_appendices/config.rst:3234 -#: ../../rst/reference_appendices/config.rst:3241 -msgid "This setting allows suppressing colorizing output, which is used to give a better indication of failure and status information." -msgstr "この設定により、色付け出力を抑制できます。これは、障害およびステータスの情報をより適切に示すために使用されます。" - -#: ../../rst/reference_appendices/config.rst:244 -msgid "nocolor" -msgstr "nocolor" - -#: ../../rst/reference_appendices/config.rst:246 -msgid ":envvar:`ANSIBLE_NOCOLOR`" -msgstr ":envvar:`ANSIBLE_NOCOLOR`" - -#: ../../rst/reference_appendices/config.rst:247 -msgid ":envvar:`NO_COLOR`" -msgstr ":envvar:`NO_COLOR`" - -#: ../../rst/reference_appendices/config.rst:253 -msgid "ANSIBLE_NOCOWS" -msgstr "ANSIBLE_NOCOWS" - -#: ../../rst/reference_appendices/config.rst:255 -#: ../../rst/reference_appendices/config.rst:3250 -msgid "If you have cowsay installed but want to avoid the 'cows' (why????), use this." -msgstr "cowsay がインストールされているにもかかわらず、「cows」を回避するには、これを使用します。" - -#: ../../rst/reference_appendices/config.rst:260 -msgid "nocows" -msgstr "nocows" - -#: ../../rst/reference_appendices/config.rst:262 -msgid ":envvar:`ANSIBLE_NOCOWS`" -msgstr ":envvar:`ANSIBLE_NOCOWS`" - -#: ../../rst/reference_appendices/config.rst:267 -msgid "ANSIBLE_PIPELINING" -msgstr "ANSIBLE_PIPELINING" - -#: ../../rst/reference_appendices/config.rst:269 -msgid "This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all. 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. It 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 setting will be disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled." -msgstr "これはグローバルオプションであり、各 connection プラグインは、より具体的なオプションを指定するか、パイプをサポートしないかのいずれかによりオーバーライドすることができます。パイプライン (connection プラグインでサポートされる場合) は、実際のファイル転送をせずに多数の Ansible モジュールを実行して、リモートサーバーでモジュールを実行するために必要なネットワーク操作の数を減らします。これにより、有効にするとパフォーマンスが大幅に向上する可能性があります。ただし、これは特権昇格 (become) と競合します。たとえば、「sudo:」操作を使用する場合は、すべての管理対象ホストの /etc/sudoers で「requiretty」を無効にする必要があります。これが、デフォルトで無効になっている理由です。``ANSIBLE_KEEP_REMOTE_FILES`` が有効な場合、この設定は無効になります。" - -#: ../../rst/reference_appendices/config.rst:273 -msgid "[connection]" -msgstr "[connection]" - -#: ../../rst/reference_appendices/config.rst:274 -#: ../../rst/reference_appendices/config.rst:276 -msgid "pipelining" -msgstr "pipelining" - -#: ../../rst/reference_appendices/config.rst:278 -msgid ":envvar:`ANSIBLE_PIPELINING`" -msgstr ":envvar:`ANSIBLE_PIPELINING`" - -#: ../../rst/reference_appendices/config.rst:283 -msgid "ANY_ERRORS_FATAL" -msgstr "ANY_ERRORS_FATAL" - -#: ../../rst/reference_appendices/config.rst:285 -#: ../../rst/reference_appendices/config.rst:3274 -msgid "Sets the default value for the any_errors_fatal keyword, if True, Task failures will be considered fatal errors." -msgstr "any_errors_fatal キーワードのデフォルト値を設定します。True の場合、タスクの失敗は致命的なエラーとみなされます。" - -#: ../../rst/reference_appendices/config.rst:288 -#: ../../rst/reference_appendices/config.rst:3094 -msgid "2.4" -msgstr "2.4" - -#: ../../rst/reference_appendices/config.rst:291 -#: ../../rst/reference_appendices/playbooks_keywords.rst:27 -#: ../../rst/reference_appendices/playbooks_keywords.rst:159 -#: ../../rst/reference_appendices/playbooks_keywords.rst:252 -#: ../../rst/reference_appendices/playbooks_keywords.rst:354 -msgid "any_errors_fatal" -msgstr "any_errors_fatal" - -#: ../../rst/reference_appendices/config.rst:293 -msgid ":envvar:`ANSIBLE_ANY_ERRORS_FATAL`" -msgstr ":envvar:`ANSIBLE_ANY_ERRORS_FATAL`" - -#: ../../rst/reference_appendices/config.rst:298 -msgid "BECOME_ALLOW_SAME_USER" -msgstr "BECOME_ALLOW_SAME_USER" - -#: ../../rst/reference_appendices/config.rst:300 -msgid "This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root. If executable, it will be run and the resulting stdout will be used as the password." -msgstr "この設定は、リモートユーザーと become ユーザーが同じである場合に、become をスキップするかどうか (root sudo から root) を制御します。実行可能な場合には、実行されて、生成される標準出力がパスワードとして使用されます。" - -#: ../../rst/reference_appendices/config.rst:305 -msgid "become_allow_same_user" -msgstr "become_allow_same_user" - -#: ../../rst/reference_appendices/config.rst:307 -msgid ":envvar:`ANSIBLE_BECOME_ALLOW_SAME_USER`" -msgstr ":envvar:`ANSIBLE_BECOME_ALLOW_SAME_USER`" - -#: ../../rst/reference_appendices/config.rst:312 -msgid "BECOME_PASSWORD_FILE" -msgstr "BECOME_PASSWORD_FILE" - -#: ../../rst/reference_appendices/config.rst:314 -msgid "The password file to use for the become plugin. --become-password-file. If executable, it will be run and the resulting stdout will be used as the password." -msgstr "become プラグインに使用するパスワードファイル。--become-password-file。実行可能の場合は、実行されて、生成される標準出力がパスワードとして使用されます。" - -#: ../../rst/reference_appendices/config.rst:317 -#: ../../rst/reference_appendices/config.rst:948 -#: ../../rst/reference_appendices/config.rst:3064 -#: ../../rst/reference_appendices/release_and_maintenance.rst:86 -msgid "2.12" -msgstr "2.12" - -#: ../../rst/reference_appendices/config.rst:320 -msgid "become_password_file" -msgstr "become_password_file" - -#: ../../rst/reference_appendices/config.rst:322 -msgid ":envvar:`ANSIBLE_BECOME_PASSWORD_FILE`" -msgstr ":envvar:`ANSIBLE_BECOME_PASSWORD_FILE`" - -#: ../../rst/reference_appendices/config.rst:327 -msgid "BECOME_PLUGIN_PATH" -msgstr "BECOME_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:329 -#: ../../rst/reference_appendices/config.rst:3605 -msgid "Colon separated paths in which Ansible will search for Become Plugins." -msgstr "Ansible が Become プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:330 -#: ../../rst/reference_appendices/config.rst:441 -#: ../../rst/reference_appendices/config.rst:986 -#: ../../rst/reference_appendices/config.rst:1121 -#: ../../rst/reference_appendices/config.rst:1135 -#: ../../rst/reference_appendices/config.rst:1149 -#: ../../rst/reference_appendices/config.rst:1163 -#: ../../rst/reference_appendices/config.rst:1220 -#: ../../rst/reference_appendices/config.rst:1345 -#: ../../rst/reference_appendices/config.rst:1372 -#: ../../rst/reference_appendices/config.rst:1500 -#: ../../rst/reference_appendices/config.rst:1560 -#: ../../rst/reference_appendices/config.rst:1574 -#: ../../rst/reference_appendices/config.rst:1588 -#: ../../rst/reference_appendices/config.rst:1715 -#: ../../rst/reference_appendices/config.rst:1771 -#: ../../rst/reference_appendices/config.rst:1812 -#: ../../rst/reference_appendices/config.rst:1826 -#: ../../rst/reference_appendices/config.rst:1882 -#: ../../rst/reference_appendices/config.rst:2061 -msgid "pathspec" -msgstr "pathspec" - -#: ../../rst/reference_appendices/config.rst:331 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/become:/usr/share/ansible/plugins/become\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/become:/usr/share/ansible/plugins/become\" }}``" - -#: ../../rst/reference_appendices/config.rst:335 -msgid "become_plugins" -msgstr "become_plugins" - -#: ../../rst/reference_appendices/config.rst:337 -msgid ":envvar:`ANSIBLE_BECOME_PLUGINS`" -msgstr ":envvar:`ANSIBLE_BECOME_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:342 -msgid "CACHE_PLUGIN" -msgstr "CACHE_PLUGIN" - -#: ../../rst/reference_appendices/config.rst:344 -#: ../../rst/reference_appendices/config.rst:3306 -msgid "Chooses which cache plugin to use, the default 'memory' is ephemeral." -msgstr "使用する cache プラグインを選択します。デフォルトの「メモリー」は一時的です。" - -#: ../../rst/reference_appendices/config.rst:345 -msgid "``memory``" -msgstr "``memory``" - -#: ../../rst/reference_appendices/config.rst:348 -msgid "fact_caching" -msgstr "fact_caching" - -#: ../../rst/reference_appendices/config.rst:350 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN`" - -#: ../../rst/reference_appendices/config.rst:355 -msgid "CACHE_PLUGIN_CONNECTION" -msgstr "CACHE_PLUGIN_CONNECTION" - -#: ../../rst/reference_appendices/config.rst:357 -#: ../../rst/reference_appendices/config.rst:3314 -msgid "Defines connection or path information for the cache plugin" -msgstr "cache プラグインの接続またはパスの情報を定義します。" - -#: ../../rst/reference_appendices/config.rst:361 -msgid "fact_caching_connection" -msgstr "fact_caching_connection" - -#: ../../rst/reference_appendices/config.rst:363 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_CONNECTION`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_CONNECTION`" - -#: ../../rst/reference_appendices/config.rst:368 -msgid "CACHE_PLUGIN_PREFIX" -msgstr "CACHE_PLUGIN_PREFIX" - -#: ../../rst/reference_appendices/config.rst:370 -#: ../../rst/reference_appendices/config.rst:3322 -msgid "Prefix to use for cache plugin files/tables" -msgstr "cache プラグインファイル/テーブルに使用する接頭辞。" - -#: ../../rst/reference_appendices/config.rst:371 -msgid "``ansible_facts``" -msgstr "``ansible_facts``" - -#: ../../rst/reference_appendices/config.rst:374 -msgid "fact_caching_prefix" -msgstr "fact_caching_prefix" - -#: ../../rst/reference_appendices/config.rst:376 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`" - -#: ../../rst/reference_appendices/config.rst:381 -msgid "CACHE_PLUGIN_TIMEOUT" -msgstr "CACHE_PLUGIN_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:383 -#: ../../rst/reference_appendices/config.rst:3330 -msgid "Expiration timeout for the cache plugin data" -msgstr "cache プラグインデータの有効期限のタイムアウト。" - -#: ../../rst/reference_appendices/config.rst:384 -#: ../../rst/reference_appendices/config.rst:1249 -#: ../../rst/reference_appendices/config.rst:1280 -#: ../../rst/reference_appendices/config.rst:1647 -#: ../../rst/reference_appendices/config.rst:1689 -#: ../../rst/reference_appendices/config.rst:1840 -#: ../../rst/reference_appendices/config.rst:1962 -#: ../../rst/reference_appendices/config.rst:2018 -#: ../../rst/reference_appendices/config.rst:2762 -#: ../../rst/reference_appendices/config.rst:2776 -#: ../../rst/reference_appendices/config.rst:3013 -#: ../../rst/reference_appendices/config.rst:3122 -#: ../../rst/reference_appendices/config.rst:3139 -msgid "integer" -msgstr "integer" - -#: ../../rst/reference_appendices/config.rst:385 -msgid "``86400``" -msgstr "``86400``" - -#: ../../rst/reference_appendices/config.rst:388 -msgid "fact_caching_timeout" -msgstr "fact_caching_timeout" - -#: ../../rst/reference_appendices/config.rst:390 -msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:395 -msgid "CALLBACKS_ENABLED" -msgstr "CALLBACKS_ENABLED" - -#: ../../rst/reference_appendices/config.rst:397 -#: ../../rst/reference_appendices/config.rst:3637 -#: ../../rst/reference_appendices/config.rst:3647 -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." -msgstr "有効なコールバックのリストです。すべてのコールバックを有効にする必要はありませんが、Ansible に同梱されるコールバックの多くは、デフォルトでアクティブ化されたくないため、そのようになっています。" - -#: ../../rst/reference_appendices/config.rst:399 -#: ../../rst/reference_appendices/config.rst:1386 -#: ../../rst/reference_appendices/config.rst:1473 -#: ../../rst/reference_appendices/config.rst:1935 -#: ../../rst/reference_appendices/config.rst:2577 -#: ../../rst/reference_appendices/config.rst:2969 -#: ../../rst/reference_appendices/config.rst:2984 -msgid "``[]``" -msgstr "``[]``" - -#: ../../rst/reference_appendices/config.rst:402 -msgid "callback_whitelist" -msgstr "callback_whitelist" - -#: ../../rst/reference_appendices/config.rst:405 -#: ../../rst/reference_appendices/config.rst:407 -msgid "callbacks_enabled" -msgstr "callbacks_enabled" - -#: ../../rst/reference_appendices/config.rst:410 -msgid ":envvar:`ANSIBLE_CALLBACK_WHITELIST`" -msgstr ":envvar:`ANSIBLE_CALLBACK_WHITELIST`" - -#: ../../rst/reference_appendices/config.rst:413 -#: ../../rst/reference_appendices/config.rst:3643 -msgid "ANSIBLE_CALLBACKS_ENABLED" -msgstr "ANSIBLE_CALLBACKS_ENABLED" - -#: ../../rst/reference_appendices/config.rst:414 -msgid ":envvar:`ANSIBLE_CALLBACKS_ENABLED`" -msgstr ":envvar:`ANSIBLE_CALLBACKS_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:420 -msgid "COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH" -msgstr "COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH" - -#: ../../rst/reference_appendices/config.rst:422 -#: ../../rst/reference_appendices/config.rst:3364 -msgid "When a collection is loaded that does not support the running Ansible version (with the collection metadata key `requires_ansible`)." -msgstr "実行中の Ansible バージョンをサポートしないコレクションがロードされた場合 (コレクションメタデータキー `requires_ansible` を使用)。" - -#: ../../rst/reference_appendices/config.rst:423 -#: ../../rst/reference_appendices/config.rst:2377 -msgid "``warning``" -msgstr "``warning``" - -#: ../../rst/reference_appendices/config.rst -msgid "Choices" -msgstr "選択肢" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:729 -msgid "error" -msgstr "error" - -#: ../../rst/reference_appendices/config.rst:425 -#: ../../rst/reference_appendices/config.rst:2090 -#: ../../rst/reference_appendices/config.rst:2379 -msgid "issue a 'fatal' error and stop the play" -msgstr "「致命的な」エラーを発行してプレイを停止します" - -#: ../../rst/reference_appendices/config.rst -msgid "warning" -msgstr "warning" - -#: ../../rst/reference_appendices/config.rst:426 -#: ../../rst/reference_appendices/config.rst:2091 -#: ../../rst/reference_appendices/config.rst:2380 -msgid "issue a warning but continue" -msgstr "警告を出力しますがそのまま続行されます" - -#: ../../rst/reference_appendices/config.rst -msgid "ignore" -msgstr "ignore" - -#: ../../rst/reference_appendices/config.rst:427 -#: ../../rst/reference_appendices/config.rst:2092 -#: ../../rst/reference_appendices/config.rst:2381 -msgid "just continue silently" -msgstr "エラーなしにそのまま続行されます" - -#: ../../rst/reference_appendices/config.rst:430 -msgid "collections_on_ansible_version_mismatch" -msgstr "collections_on_ansible_version_mismatch" - -#: ../../rst/reference_appendices/config.rst:432 -msgid ":envvar:`ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH`" - -#: ../../rst/reference_appendices/config.rst:437 -msgid "COLLECTIONS_PATHS" -msgstr "COLLECTIONS_PATHS" - -#: ../../rst/reference_appendices/config.rst:439 -#: ../../rst/reference_appendices/config.rst:3346 -#: ../../rst/reference_appendices/config.rst:3354 -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_HOME ~ \"/collections\" }}'``, and you want to add ``my.collection`` to that directory, it must be saved as ``'{{ ANSIBLE_HOME} ~ \"/collections/ansible_collections/my/collection\" }}'``." -msgstr "Ansible がコレクションコンテンツを検索するコロン区切りパス。コレクションは、これらのディレクトリーに直接ではなく、入れ子の *サブディレクトリー* に置かれる必要があります。たとえば、``COLLECTIONS_PATHS`` には ``'{{ ANSIBLE_HOME ~ \"/collections\" }}'`` が含まれ、そのディレクトリーに ``my.collection`` を追加する場合は、``'{{ ANSIBLE_HOME} ~ \"/collections/ansible_collections/my/collection\" }}'`` として保存する必要があります。" - -#: ../../rst/reference_appendices/config.rst:442 -msgid "``{{ ANSIBLE_HOME ~ \"/collections:/usr/share/ansible/collections\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/collections:/usr/share/ansible/collections\" }}``" - -#: ../../rst/reference_appendices/config.rst:445 -msgid "collections_paths" -msgstr "collections_paths" - -#: ../../rst/reference_appendices/config.rst:447 -msgid "collections_path" -msgstr "collections_path" - -#: ../../rst/reference_appendices/config.rst:448 -#: ../../rst/reference_appendices/config.rst:451 -#: ../../rst/reference_appendices/config.rst:2210 -#: ../../rst/reference_appendices/config.rst:2898 -#: ../../rst/reference_appendices/config.rst:3015 -#: ../../rst/reference_appendices/config.rst:3079 -#: ../../rst/reference_appendices/config.rst:3124 -#: ../../rst/reference_appendices/config.rst:3141 -#: ../../rst/reference_appendices/config.rst:3153 -#: ../../rst/reference_appendices/config.rst:3359 -#: ../../rst/reference_appendices/release_and_maintenance.rst:88 -#: ../../rst/reference_appendices/release_and_maintenance.rst:89 -msgid "2.10" -msgstr "2.10" - -#: ../../rst/reference_appendices/config.rst:450 -msgid ":envvar:`ANSIBLE_COLLECTIONS_PATH`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_PATH`" - -#: ../../rst/reference_appendices/config.rst:452 -msgid ":envvar:`ANSIBLE_COLLECTIONS_PATHS`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_PATHS`" - -#: ../../rst/reference_appendices/config.rst:457 -msgid "COLLECTIONS_SCAN_SYS_PATH" -msgstr "COLLECTIONS_SCAN_SYS_PATH" - -#: ../../rst/reference_appendices/config.rst:459 -#: ../../rst/reference_appendices/config.rst:3338 -msgid "A boolean to enable or disable scanning the sys.path for installed collections" -msgstr "インストールされたコレクションの sys.path のスキャンを有効または無効にするブール値。" - -#: ../../rst/reference_appendices/config.rst:464 -msgid "collections_scan_sys_path" -msgstr "collections_scan_sys_path" - -#: ../../rst/reference_appendices/config.rst:466 -msgid ":envvar:`ANSIBLE_COLLECTIONS_SCAN_SYS_PATH`" -msgstr ":envvar:`ANSIBLE_COLLECTIONS_SCAN_SYS_PATH`" - -#: ../../rst/reference_appendices/config.rst:471 -msgid "COLOR_CHANGED" -msgstr "COLOR_CHANGED" - -#: ../../rst/reference_appendices/config.rst:473 -#: ../../rst/reference_appendices/config.rst:3372 -msgid "Defines the color to use on 'Changed' task status" -msgstr "「Changed」タスクの状態に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:474 -msgid "``yellow``" -msgstr "``yellow``" - -#: ../../rst/reference_appendices/config.rst:476 -#: ../../rst/reference_appendices/config.rst:509 -#: ../../rst/reference_appendices/config.rst:543 -#: ../../rst/reference_appendices/config.rst:576 -#: ../../rst/reference_appendices/config.rst:609 -#: ../../rst/reference_appendices/config.rst:642 -#: ../../rst/reference_appendices/config.rst:675 -#: ../../rst/reference_appendices/config.rst:708 -#: ../../rst/reference_appendices/config.rst:741 -#: ../../rst/reference_appendices/config.rst:774 -#: ../../rst/reference_appendices/config.rst:807 -#: ../../rst/reference_appendices/config.rst:840 -#: ../../rst/reference_appendices/config.rst:873 -#: ../../rst/reference_appendices/config.rst:906 -msgid "black" -msgstr "black" - -#: ../../rst/reference_appendices/config.rst:477 -#: ../../rst/reference_appendices/config.rst:510 -#: ../../rst/reference_appendices/config.rst:544 -#: ../../rst/reference_appendices/config.rst:577 -#: ../../rst/reference_appendices/config.rst:610 -#: ../../rst/reference_appendices/config.rst:643 -#: ../../rst/reference_appendices/config.rst:676 -#: ../../rst/reference_appendices/config.rst:709 -#: ../../rst/reference_appendices/config.rst:742 -#: ../../rst/reference_appendices/config.rst:775 -#: ../../rst/reference_appendices/config.rst:808 -#: ../../rst/reference_appendices/config.rst:841 -#: ../../rst/reference_appendices/config.rst:874 -#: ../../rst/reference_appendices/config.rst:907 -msgid "bright gray" -msgstr "bright gray" - -#: ../../rst/reference_appendices/config.rst:478 -#: ../../rst/reference_appendices/config.rst:511 -#: ../../rst/reference_appendices/config.rst:545 -#: ../../rst/reference_appendices/config.rst:578 -#: ../../rst/reference_appendices/config.rst:611 -#: ../../rst/reference_appendices/config.rst:644 -#: ../../rst/reference_appendices/config.rst:677 -#: ../../rst/reference_appendices/config.rst:710 -#: ../../rst/reference_appendices/config.rst:743 -#: ../../rst/reference_appendices/config.rst:776 -#: ../../rst/reference_appendices/config.rst:809 -#: ../../rst/reference_appendices/config.rst:842 -#: ../../rst/reference_appendices/config.rst:875 -#: ../../rst/reference_appendices/config.rst:908 -msgid "blue" -msgstr "blue" - -#: ../../rst/reference_appendices/config.rst:479 -#: ../../rst/reference_appendices/config.rst:512 -#: ../../rst/reference_appendices/config.rst:546 -#: ../../rst/reference_appendices/config.rst:579 -#: ../../rst/reference_appendices/config.rst:612 -#: ../../rst/reference_appendices/config.rst:645 -#: ../../rst/reference_appendices/config.rst:678 -#: ../../rst/reference_appendices/config.rst:711 -#: ../../rst/reference_appendices/config.rst:744 -#: ../../rst/reference_appendices/config.rst:777 -#: ../../rst/reference_appendices/config.rst:810 -#: ../../rst/reference_appendices/config.rst:843 -#: ../../rst/reference_appendices/config.rst:876 -#: ../../rst/reference_appendices/config.rst:909 -msgid "white" -msgstr "white" - -#: ../../rst/reference_appendices/config.rst:480 -#: ../../rst/reference_appendices/config.rst:513 -#: ../../rst/reference_appendices/config.rst:547 -#: ../../rst/reference_appendices/config.rst:580 -#: ../../rst/reference_appendices/config.rst:613 -#: ../../rst/reference_appendices/config.rst:646 -#: ../../rst/reference_appendices/config.rst:679 -#: ../../rst/reference_appendices/config.rst:712 -#: ../../rst/reference_appendices/config.rst:745 -#: ../../rst/reference_appendices/config.rst:778 -#: ../../rst/reference_appendices/config.rst:811 -#: ../../rst/reference_appendices/config.rst:844 -#: ../../rst/reference_appendices/config.rst:877 -#: ../../rst/reference_appendices/config.rst:910 -msgid "green" -msgstr "green" - -#: ../../rst/reference_appendices/config.rst:481 -#: ../../rst/reference_appendices/config.rst:514 -#: ../../rst/reference_appendices/config.rst:548 -#: ../../rst/reference_appendices/config.rst:581 -#: ../../rst/reference_appendices/config.rst:614 -#: ../../rst/reference_appendices/config.rst:647 -#: ../../rst/reference_appendices/config.rst:680 -#: ../../rst/reference_appendices/config.rst:713 -#: ../../rst/reference_appendices/config.rst:746 -#: ../../rst/reference_appendices/config.rst:779 -#: ../../rst/reference_appendices/config.rst:812 -#: ../../rst/reference_appendices/config.rst:845 -#: ../../rst/reference_appendices/config.rst:878 -#: ../../rst/reference_appendices/config.rst:911 -msgid "bright blue" -msgstr "bright blue" - -#: ../../rst/reference_appendices/config.rst:482 -#: ../../rst/reference_appendices/config.rst:515 -#: ../../rst/reference_appendices/config.rst:549 -#: ../../rst/reference_appendices/config.rst:582 -#: ../../rst/reference_appendices/config.rst:615 -#: ../../rst/reference_appendices/config.rst:648 -#: ../../rst/reference_appendices/config.rst:681 -#: ../../rst/reference_appendices/config.rst:714 -#: ../../rst/reference_appendices/config.rst:747 -#: ../../rst/reference_appendices/config.rst:780 -#: ../../rst/reference_appendices/config.rst:813 -#: ../../rst/reference_appendices/config.rst:846 -#: ../../rst/reference_appendices/config.rst:879 -#: ../../rst/reference_appendices/config.rst:912 -msgid "cyan" -msgstr "cyan" - -#: ../../rst/reference_appendices/config.rst:483 -#: ../../rst/reference_appendices/config.rst:516 -#: ../../rst/reference_appendices/config.rst:550 -#: ../../rst/reference_appendices/config.rst:583 -#: ../../rst/reference_appendices/config.rst:616 -#: ../../rst/reference_appendices/config.rst:649 -#: ../../rst/reference_appendices/config.rst:682 -#: ../../rst/reference_appendices/config.rst:715 -#: ../../rst/reference_appendices/config.rst:748 -#: ../../rst/reference_appendices/config.rst:781 -#: ../../rst/reference_appendices/config.rst:814 -#: ../../rst/reference_appendices/config.rst:847 -#: ../../rst/reference_appendices/config.rst:880 -#: ../../rst/reference_appendices/config.rst:913 -msgid "bright green" -msgstr "bright green" - -#: ../../rst/reference_appendices/config.rst:484 -#: ../../rst/reference_appendices/config.rst:517 -#: ../../rst/reference_appendices/config.rst:551 -#: ../../rst/reference_appendices/config.rst:584 -#: ../../rst/reference_appendices/config.rst:617 -#: ../../rst/reference_appendices/config.rst:650 -#: ../../rst/reference_appendices/config.rst:683 -#: ../../rst/reference_appendices/config.rst:716 -#: ../../rst/reference_appendices/config.rst:749 -#: ../../rst/reference_appendices/config.rst:782 -#: ../../rst/reference_appendices/config.rst:815 -#: ../../rst/reference_appendices/config.rst:848 -#: ../../rst/reference_appendices/config.rst:881 -#: ../../rst/reference_appendices/config.rst:914 -msgid "red" -msgstr "red" - -#: ../../rst/reference_appendices/config.rst:485 -#: ../../rst/reference_appendices/config.rst:518 -#: ../../rst/reference_appendices/config.rst:552 -#: ../../rst/reference_appendices/config.rst:585 -#: ../../rst/reference_appendices/config.rst:618 -#: ../../rst/reference_appendices/config.rst:651 -#: ../../rst/reference_appendices/config.rst:684 -#: ../../rst/reference_appendices/config.rst:717 -#: ../../rst/reference_appendices/config.rst:750 -#: ../../rst/reference_appendices/config.rst:783 -#: ../../rst/reference_appendices/config.rst:816 -#: ../../rst/reference_appendices/config.rst:849 -#: ../../rst/reference_appendices/config.rst:882 -#: ../../rst/reference_appendices/config.rst:915 -msgid "bright cyan" -msgstr "bright cyan" - -#: ../../rst/reference_appendices/config.rst:486 -#: ../../rst/reference_appendices/config.rst:519 -#: ../../rst/reference_appendices/config.rst:553 -#: ../../rst/reference_appendices/config.rst:586 -#: ../../rst/reference_appendices/config.rst:619 -#: ../../rst/reference_appendices/config.rst:652 -#: ../../rst/reference_appendices/config.rst:685 -#: ../../rst/reference_appendices/config.rst:718 -#: ../../rst/reference_appendices/config.rst:751 -#: ../../rst/reference_appendices/config.rst:784 -#: ../../rst/reference_appendices/config.rst:817 -#: ../../rst/reference_appendices/config.rst:850 -#: ../../rst/reference_appendices/config.rst:883 -#: ../../rst/reference_appendices/config.rst:916 -msgid "purple" -msgstr "purple" - -#: ../../rst/reference_appendices/config.rst:487 -#: ../../rst/reference_appendices/config.rst:520 -#: ../../rst/reference_appendices/config.rst:554 -#: ../../rst/reference_appendices/config.rst:587 -#: ../../rst/reference_appendices/config.rst:620 -#: ../../rst/reference_appendices/config.rst:653 -#: ../../rst/reference_appendices/config.rst:686 -#: ../../rst/reference_appendices/config.rst:719 -#: ../../rst/reference_appendices/config.rst:752 -#: ../../rst/reference_appendices/config.rst:785 -#: ../../rst/reference_appendices/config.rst:818 -#: ../../rst/reference_appendices/config.rst:851 -#: ../../rst/reference_appendices/config.rst:884 -#: ../../rst/reference_appendices/config.rst:917 -msgid "bright red" -msgstr "bright red" - -#: ../../rst/reference_appendices/config.rst:488 -#: ../../rst/reference_appendices/config.rst:521 -#: ../../rst/reference_appendices/config.rst:555 -#: ../../rst/reference_appendices/config.rst:588 -#: ../../rst/reference_appendices/config.rst:621 -#: ../../rst/reference_appendices/config.rst:654 -#: ../../rst/reference_appendices/config.rst:687 -#: ../../rst/reference_appendices/config.rst:720 -#: ../../rst/reference_appendices/config.rst:753 -#: ../../rst/reference_appendices/config.rst:786 -#: ../../rst/reference_appendices/config.rst:819 -#: ../../rst/reference_appendices/config.rst:852 -#: ../../rst/reference_appendices/config.rst:885 -#: ../../rst/reference_appendices/config.rst:918 -msgid "yellow" -msgstr "yellow" - -#: ../../rst/reference_appendices/config.rst:489 -#: ../../rst/reference_appendices/config.rst:522 -#: ../../rst/reference_appendices/config.rst:556 -#: ../../rst/reference_appendices/config.rst:589 -#: ../../rst/reference_appendices/config.rst:622 -#: ../../rst/reference_appendices/config.rst:655 -#: ../../rst/reference_appendices/config.rst:688 -#: ../../rst/reference_appendices/config.rst:721 -#: ../../rst/reference_appendices/config.rst:754 -#: ../../rst/reference_appendices/config.rst:787 -#: ../../rst/reference_appendices/config.rst:820 -#: ../../rst/reference_appendices/config.rst:853 -#: ../../rst/reference_appendices/config.rst:886 -#: ../../rst/reference_appendices/config.rst:919 -msgid "bright purple" -msgstr "bright purple" - -#: ../../rst/reference_appendices/config.rst:490 -#: ../../rst/reference_appendices/config.rst:523 -#: ../../rst/reference_appendices/config.rst:557 -#: ../../rst/reference_appendices/config.rst:590 -#: ../../rst/reference_appendices/config.rst:623 -#: ../../rst/reference_appendices/config.rst:656 -#: ../../rst/reference_appendices/config.rst:689 -#: ../../rst/reference_appendices/config.rst:722 -#: ../../rst/reference_appendices/config.rst:755 -#: ../../rst/reference_appendices/config.rst:788 -#: ../../rst/reference_appendices/config.rst:821 -#: ../../rst/reference_appendices/config.rst:854 -#: ../../rst/reference_appendices/config.rst:887 -#: ../../rst/reference_appendices/config.rst:920 -msgid "dark gray" -msgstr "dark gray" - -#: ../../rst/reference_appendices/config.rst:491 -#: ../../rst/reference_appendices/config.rst:524 -#: ../../rst/reference_appendices/config.rst:558 -#: ../../rst/reference_appendices/config.rst:591 -#: ../../rst/reference_appendices/config.rst:624 -#: ../../rst/reference_appendices/config.rst:657 -#: ../../rst/reference_appendices/config.rst:690 -#: ../../rst/reference_appendices/config.rst:723 -#: ../../rst/reference_appendices/config.rst:756 -#: ../../rst/reference_appendices/config.rst:789 -#: ../../rst/reference_appendices/config.rst:822 -#: ../../rst/reference_appendices/config.rst:855 -#: ../../rst/reference_appendices/config.rst:888 -#: ../../rst/reference_appendices/config.rst:921 -msgid "bright yellow" -msgstr "bright yellow" - -#: ../../rst/reference_appendices/config.rst:492 -#: ../../rst/reference_appendices/config.rst:525 -#: ../../rst/reference_appendices/config.rst:559 -#: ../../rst/reference_appendices/config.rst:592 -#: ../../rst/reference_appendices/config.rst:625 -#: ../../rst/reference_appendices/config.rst:658 -#: ../../rst/reference_appendices/config.rst:691 -#: ../../rst/reference_appendices/config.rst:724 -#: ../../rst/reference_appendices/config.rst:757 -#: ../../rst/reference_appendices/config.rst:790 -#: ../../rst/reference_appendices/config.rst:823 -#: ../../rst/reference_appendices/config.rst:856 -#: ../../rst/reference_appendices/config.rst:889 -#: ../../rst/reference_appendices/config.rst:922 -msgid "magenta" -msgstr "magenta" - -#: ../../rst/reference_appendices/config.rst:493 -#: ../../rst/reference_appendices/config.rst:526 -#: ../../rst/reference_appendices/config.rst:560 -#: ../../rst/reference_appendices/config.rst:593 -#: ../../rst/reference_appendices/config.rst:626 -#: ../../rst/reference_appendices/config.rst:659 -#: ../../rst/reference_appendices/config.rst:692 -#: ../../rst/reference_appendices/config.rst:725 -#: ../../rst/reference_appendices/config.rst:758 -#: ../../rst/reference_appendices/config.rst:791 -#: ../../rst/reference_appendices/config.rst:824 -#: ../../rst/reference_appendices/config.rst:857 -#: ../../rst/reference_appendices/config.rst:890 -#: ../../rst/reference_appendices/config.rst:923 -msgid "bright magenta" -msgstr "bright magenta" - -#: ../../rst/reference_appendices/config.rst:494 -#: ../../rst/reference_appendices/config.rst:527 -#: ../../rst/reference_appendices/config.rst:561 -#: ../../rst/reference_appendices/config.rst:594 -#: ../../rst/reference_appendices/config.rst:627 -#: ../../rst/reference_appendices/config.rst:660 -#: ../../rst/reference_appendices/config.rst:693 -#: ../../rst/reference_appendices/config.rst:726 -#: ../../rst/reference_appendices/config.rst:759 -#: ../../rst/reference_appendices/config.rst:792 -#: ../../rst/reference_appendices/config.rst:825 -#: ../../rst/reference_appendices/config.rst:858 -#: ../../rst/reference_appendices/config.rst:891 -#: ../../rst/reference_appendices/config.rst:924 -msgid "normal" -msgstr "normal" - -#: ../../rst/reference_appendices/config.rst:496 -#: ../../rst/reference_appendices/config.rst:530 -#: ../../rst/reference_appendices/config.rst:563 -#: ../../rst/reference_appendices/config.rst:596 -#: ../../rst/reference_appendices/config.rst:629 -#: ../../rst/reference_appendices/config.rst:662 -#: ../../rst/reference_appendices/config.rst:695 -#: ../../rst/reference_appendices/config.rst:728 -#: ../../rst/reference_appendices/config.rst:761 -#: ../../rst/reference_appendices/config.rst:794 -#: ../../rst/reference_appendices/config.rst:827 -#: ../../rst/reference_appendices/config.rst:860 -#: ../../rst/reference_appendices/config.rst:893 -#: ../../rst/reference_appendices/config.rst:926 -msgid "[colors]" -msgstr "[colors]" - -#: ../../rst/reference_appendices/config.rst:499 -msgid ":envvar:`ANSIBLE_COLOR_CHANGED`" -msgstr ":envvar:`ANSIBLE_COLOR_CHANGED`" - -#: ../../rst/reference_appendices/config.rst:504 -msgid "COLOR_CONSOLE_PROMPT" -msgstr "COLOR_CONSOLE_PROMPT" - -#: ../../rst/reference_appendices/config.rst:506 -#: ../../rst/reference_appendices/config.rst:3380 -msgid "Defines the default color to use for ansible-console" -msgstr "ansible-console に使用するデフォルトの色を定義します。" - -#: ../../rst/reference_appendices/config.rst:507 -#: ../../rst/reference_appendices/config.rst:739 -msgid "``white``" -msgstr "``white``" - -#: ../../rst/reference_appendices/config.rst:528 -#: ../../rst/reference_appendices/config.rst:1401 -#: ../../rst/reference_appendices/config.rst:2439 -#: ../../rst/reference_appendices/config.rst:2455 -#: ../../rst/reference_appendices/config.rst:3000 -msgid "2.7" -msgstr "2.7" - -#: ../../rst/reference_appendices/config.rst:531 -msgid "console_prompt" -msgstr "console_prompt" - -#: ../../rst/reference_appendices/config.rst:533 -msgid ":envvar:`ANSIBLE_COLOR_CONSOLE_PROMPT`" -msgstr ":envvar:`ANSIBLE_COLOR_CONSOLE_PROMPT`" - -#: ../../rst/reference_appendices/config.rst:538 -msgid "COLOR_DEBUG" -msgstr "COLOR_DEBUG" - -#: ../../rst/reference_appendices/config.rst:540 -#: ../../rst/reference_appendices/config.rst:3388 -msgid "Defines the color to use when emitting debug messages" -msgstr "デバッグメッセージを生成する際に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:541 -msgid "``dark gray``" -msgstr "``dark gray``" - -#: ../../rst/reference_appendices/config.rst:564 -#: ../../rst/reference_appendices/config.rst:1181 -msgid "debug" -msgstr "debug" - -#: ../../rst/reference_appendices/config.rst:566 -msgid ":envvar:`ANSIBLE_COLOR_DEBUG`" -msgstr ":envvar:`ANSIBLE_COLOR_DEBUG`" - -#: ../../rst/reference_appendices/config.rst:571 -msgid "COLOR_DEPRECATE" -msgstr "COLOR_DEPRECATE" - -#: ../../rst/reference_appendices/config.rst:573 -#: ../../rst/reference_appendices/config.rst:3396 -msgid "Defines the color to use when emitting deprecation messages" -msgstr "非推奨メッセージを生成するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:574 -msgid "``purple``" -msgstr "``purple``" - -#: ../../rst/reference_appendices/config.rst:597 -msgid "deprecate" -msgstr "deprecate" - -#: ../../rst/reference_appendices/config.rst:599 -msgid ":envvar:`ANSIBLE_COLOR_DEPRECATE`" -msgstr ":envvar:`ANSIBLE_COLOR_DEPRECATE`" - -#: ../../rst/reference_appendices/config.rst:604 -msgid "COLOR_DIFF_ADD" -msgstr "COLOR_DIFF_ADD" - -#: ../../rst/reference_appendices/config.rst:606 -#: ../../rst/reference_appendices/config.rst:3404 -msgid "Defines the color to use when showing added lines in diffs" -msgstr "diffs で追加した行を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:607 -#: ../../rst/reference_appendices/config.rst:772 -msgid "``green``" -msgstr "``green``" - -#: ../../rst/reference_appendices/config.rst:630 -msgid "diff_add" -msgstr "diff_add" - -#: ../../rst/reference_appendices/config.rst:632 -msgid ":envvar:`ANSIBLE_COLOR_DIFF_ADD`" -msgstr ":envvar:`ANSIBLE_COLOR_DIFF_ADD`" - -#: ../../rst/reference_appendices/config.rst:637 -msgid "COLOR_DIFF_LINES" -msgstr "COLOR_DIFF_LINES" - -#: ../../rst/reference_appendices/config.rst:639 -#: ../../rst/reference_appendices/config.rst:3412 -msgid "Defines the color to use when showing diffs" -msgstr "差異を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:640 -#: ../../rst/reference_appendices/config.rst:805 -msgid "``cyan``" -msgstr "``cyan``" - -#: ../../rst/reference_appendices/config.rst:663 -msgid "diff_lines" -msgstr "diff_lines" - -#: ../../rst/reference_appendices/config.rst:665 -msgid ":envvar:`ANSIBLE_COLOR_DIFF_LINES`" -msgstr ":envvar:`ANSIBLE_COLOR_DIFF_LINES`" - -#: ../../rst/reference_appendices/config.rst:670 -msgid "COLOR_DIFF_REMOVE" -msgstr "COLOR_DIFF_REMOVE" - -#: ../../rst/reference_appendices/config.rst:672 -#: ../../rst/reference_appendices/config.rst:3420 -msgid "Defines the color to use when showing removed lines in diffs" -msgstr "diffs で削除した行を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:673 -#: ../../rst/reference_appendices/config.rst:706 -msgid "``red``" -msgstr "``red``" - -#: ../../rst/reference_appendices/config.rst:696 -msgid "diff_remove" -msgstr "diff_remove" - -#: ../../rst/reference_appendices/config.rst:698 -msgid ":envvar:`ANSIBLE_COLOR_DIFF_REMOVE`" -msgstr ":envvar:`ANSIBLE_COLOR_DIFF_REMOVE`" - -#: ../../rst/reference_appendices/config.rst:703 -msgid "COLOR_ERROR" -msgstr "COLOR_ERROR" - -#: ../../rst/reference_appendices/config.rst:705 -#: ../../rst/reference_appendices/config.rst:3428 -msgid "Defines the color to use when emitting error messages" -msgstr "エラーメッセージを生成する際に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:731 -msgid ":envvar:`ANSIBLE_COLOR_ERROR`" -msgstr ":envvar:`ANSIBLE_COLOR_ERROR`" - -#: ../../rst/reference_appendices/config.rst:736 -msgid "COLOR_HIGHLIGHT" -msgstr "COLOR_HIGHLIGHT" - -#: ../../rst/reference_appendices/config.rst:738 -#: ../../rst/reference_appendices/config.rst:3436 -msgid "Defines the color to use for highlighting" -msgstr "強調表示に使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:762 -msgid "highlight" -msgstr "highlight" - -#: ../../rst/reference_appendices/config.rst:764 -msgid ":envvar:`ANSIBLE_COLOR_HIGHLIGHT`" -msgstr ":envvar:`ANSIBLE_COLOR_HIGHLIGHT`" - -#: ../../rst/reference_appendices/config.rst:769 -msgid "COLOR_OK" -msgstr "COLOR_OK" - -#: ../../rst/reference_appendices/config.rst:771 -#: ../../rst/reference_appendices/config.rst:3444 -msgid "Defines the color to use when showing 'OK' task status" -msgstr "タスク状態「OK」を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:795 -msgid "ok" -msgstr "ok" - -#: ../../rst/reference_appendices/config.rst:797 -msgid ":envvar:`ANSIBLE_COLOR_OK`" -msgstr ":envvar:`ANSIBLE_COLOR_OK`" - -#: ../../rst/reference_appendices/config.rst:802 -msgid "COLOR_SKIP" -msgstr "COLOR_SKIP" - -#: ../../rst/reference_appendices/config.rst:804 -#: ../../rst/reference_appendices/config.rst:3452 -msgid "Defines the color to use when showing 'Skipped' task status" -msgstr "タスク状態「Skipped」を表示するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:828 -#: ../../rst/reference_appendices/config.rst:2988 -msgid "skip" -msgstr "skip" - -#: ../../rst/reference_appendices/config.rst:830 -msgid ":envvar:`ANSIBLE_COLOR_SKIP`" -msgstr ":envvar:`ANSIBLE_COLOR_SKIP`" - -#: ../../rst/reference_appendices/config.rst:835 -msgid "COLOR_UNREACHABLE" -msgstr "COLOR_UNREACHABLE" - -#: ../../rst/reference_appendices/config.rst:837 -#: ../../rst/reference_appendices/config.rst:3460 -msgid "Defines the color to use on 'Unreachable' status" -msgstr "タスク状態「到達不能」状態で使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:838 -msgid "``bright red``" -msgstr "``bright red``" - -#: ../../rst/reference_appendices/config.rst:861 -msgid "unreachable" -msgstr "unreachable" - -#: ../../rst/reference_appendices/config.rst:863 -msgid ":envvar:`ANSIBLE_COLOR_UNREACHABLE`" -msgstr ":envvar:`ANSIBLE_COLOR_UNREACHABLE`" - -#: ../../rst/reference_appendices/config.rst:868 -msgid "COLOR_VERBOSE" -msgstr "COLOR_VERBOSE" - -#: ../../rst/reference_appendices/config.rst:870 -#: ../../rst/reference_appendices/config.rst:3468 -msgid "Defines the color to use when emitting verbose messages. i.e those that show with '-v's." -msgstr "詳細メッセージを生成する際に使用する色を定義します (つまり、'-v's で示されるものとなります)。" - -#: ../../rst/reference_appendices/config.rst:871 -msgid "``blue``" -msgstr "``blue``" - -#: ../../rst/reference_appendices/config.rst:894 -msgid "verbose" -msgstr "verbose" - -#: ../../rst/reference_appendices/config.rst:896 -msgid ":envvar:`ANSIBLE_COLOR_VERBOSE`" -msgstr ":envvar:`ANSIBLE_COLOR_VERBOSE`" - -#: ../../rst/reference_appendices/config.rst:901 -msgid "COLOR_WARN" -msgstr "COLOR_WARN" - -#: ../../rst/reference_appendices/config.rst:903 -#: ../../rst/reference_appendices/config.rst:3476 -msgid "Defines the color to use when emitting warning messages" -msgstr "警告メッセージを生成するときに使用する色を定義します。" - -#: ../../rst/reference_appendices/config.rst:904 -msgid "``bright purple``" -msgstr "``bright purple``" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:927 -msgid "warn" -msgstr "warn" - -#: ../../rst/reference_appendices/config.rst:929 -msgid ":envvar:`ANSIBLE_COLOR_WARN`" -msgstr ":envvar:`ANSIBLE_COLOR_WARN`" - -#: ../../rst/reference_appendices/config.rst:934 -msgid "CONNECTION_FACTS_MODULES" -msgstr "CONNECTION_FACTS_MODULES" - -#: ../../rst/reference_appendices/config.rst:936 -msgid "Which modules to run during a play's fact gathering stage based on connection" -msgstr "接続に基づいてプレイのファクト収集ステージ時に実行するモジュール。" - -#: ../../rst/reference_appendices/config.rst:937 -msgid "dict" -msgstr "dict" - -#: ../../rst/reference_appendices/config.rst:938 -msgid "``{'asa': 'ansible.legacy.asa_facts', 'cisco.asa.asa': 'cisco.asa.asa_facts', 'eos': 'ansible.legacy.eos_facts', 'arista.eos.eos': 'arista.eos.eos_facts', 'frr': 'ansible.legacy.frr_facts', 'frr.frr.frr': 'frr.frr.frr_facts', 'ios': 'ansible.legacy.ios_facts', 'cisco.ios.ios': 'cisco.ios.ios_facts', 'iosxr': 'ansible.legacy.iosxr_facts', 'cisco.iosxr.iosxr': 'cisco.iosxr.iosxr_facts', 'junos': 'ansible.legacy.junos_facts', 'junipernetworks.junos.junos': 'junipernetworks.junos.junos_facts', 'nxos': 'ansible.legacy.nxos_facts', 'cisco.nxos.nxos': 'cisco.nxos.nxos_facts', 'vyos': 'ansible.legacy.vyos_facts', 'vyos.vyos.vyos': 'vyos.vyos.vyos_facts', 'exos': 'ansible.legacy.exos_facts', 'extreme.exos.exos': 'extreme.exos.exos_facts', 'slxos': 'ansible.legacy.slxos_facts', 'extreme.slxos.slxos': 'extreme.slxos.slxos_facts', 'voss': 'ansible.legacy.voss_facts', 'extreme.voss.voss': 'extreme.voss.voss_facts', 'ironware': 'ansible.legacy.ironware_facts', 'community.network.ironware': 'community.network.ironware_facts'}``" -msgstr "``{'asa': 'ansible.legacy.asa_facts', 'cisco.asa.asa': 'cisco.asa.asa_facts', 'eos': 'ansible.legacy.eos_facts', 'arista.eos.eos': 'arista.eos.eos_facts', 'frr': 'ansible.legacy.frr_facts', 'frr.frr.frr': 'frr.frr.frr_facts', 'ios': 'ansible.legacy.ios_facts', 'cisco.ios.ios': 'cisco.ios.ios_facts', 'iosxr': 'ansible.legacy.iosxr_facts', 'cisco.iosxr.iosxr': 'cisco.iosxr.iosxr_facts', 'junos': 'ansible.legacy.junos_facts', 'junipernetworks.junos.junos': 'junipernetworks.junos.junos_facts', 'nxos': 'ansible.legacy.nxos_facts', 'cisco.nxos.nxos': 'cisco.nxos.nxos_facts', 'vyos': 'ansible.legacy.vyos_facts', 'vyos.vyos.vyos': 'vyos.vyos.vyos_facts', 'exos': 'ansible.legacy.exos_facts', 'extreme.exos.exos': 'extreme.exos.exos_facts', 'slxos': 'ansible.legacy.slxos_facts', 'extreme.slxos.slxos': 'extreme.slxos.slxos_facts', 'voss': 'ansible.legacy.voss_facts', 'extreme.voss.voss': 'extreme.voss.voss_facts', 'ironware': 'ansible.legacy.ironware_facts', 'community.network.ironware': 'community.network.ironware_facts'}``" - -#: ../../rst/reference_appendices/config.rst:943 -msgid "CONNECTION_PASSWORD_FILE" -msgstr "CONNECTION_PASSWORD_FILE" - -#: ../../rst/reference_appendices/config.rst:945 -#: ../../rst/reference_appendices/config.rst:3484 -msgid "The password file to use for the connection plugin. --connection-password-file." -msgstr "connection プラグインに使用するパスワードファイル。--connection-password-file。" - -#: ../../rst/reference_appendices/config.rst:951 -msgid "connection_password_file" -msgstr "connection_password_file" - -#: ../../rst/reference_appendices/config.rst:953 -msgid ":envvar:`ANSIBLE_CONNECTION_PASSWORD_FILE`" -msgstr ":envvar:`ANSIBLE_CONNECTION_PASSWORD_FILE`" - -#: ../../rst/reference_appendices/config.rst:958 -msgid "COVERAGE_REMOTE_OUTPUT" -msgstr "COVERAGE_REMOTE_OUTPUT" - -#: ../../rst/reference_appendices/config.rst:960 -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." -msgstr "リモートホストの出力ディレクトリーを設定してカバレッジレポートを生成します。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:961 -#: ../../rst/reference_appendices/config.rst:974 -#: ../../rst/reference_appendices/config.rst:2280 -#: ../../rst/reference_appendices/config.rst:2893 -msgid "str" -msgstr "str" - -#: ../../rst/reference_appendices/config.rst:962 -#: ../../rst/reference_appendices/config.rst:976 -#: ../../rst/reference_appendices/config.rst:2093 -#: ../../rst/reference_appendices/config.rst:2335 -#: ../../rst/reference_appendices/config.rst:2350 -#: ../../rst/reference_appendices/config.rst:2805 -#: ../../rst/reference_appendices/config.rst:3960 -msgid "2.9" -msgstr "2.9" - -#: ../../rst/reference_appendices/config.rst:964 -msgid ":envvar:`_ANSIBLE_COVERAGE_REMOTE_OUTPUT`" -msgstr ":envvar:`_ANSIBLE_COVERAGE_REMOTE_OUTPUT`" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/general_precedence.rst:23 -#: ../../rst/reference_appendices/general_precedence.rst:98 -msgid "Variables" -msgstr "変数" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/playbooks_keywords.rst:101 -#: ../../rst/reference_appendices/playbooks_keywords.rst:215 -#: ../../rst/reference_appendices/playbooks_keywords.rst:311 -#: ../../rst/reference_appendices/playbooks_keywords.rst:434 -msgid "name" -msgstr "名前" - -#: ../../rst/reference_appendices/config.rst:966 -msgid "`_ansible_coverage_remote_output`" -msgstr "`_ansible_coverage_remote_output`" - -#: ../../rst/reference_appendices/config.rst:971 -msgid "COVERAGE_REMOTE_PATHS" -msgstr "COVERAGE_REMOTE_PATHS" - -#: ../../rst/reference_appendices/config.rst:973 -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." -msgstr "リモートホストで実行するときにカバレッジを実行する Ansible コントローラー上のファイルのパスのリスト。パスグロブに一致するファイルのみがカバレッジを収集します。パスグロブは、``:`` で区切ることで複数指定できます。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:975 -msgid "``*``" -msgstr "``*``" - -#: ../../rst/reference_appendices/config.rst:978 -msgid ":envvar:`_ANSIBLE_COVERAGE_REMOTE_PATH_FILTER`" -msgstr ":envvar:`_ANSIBLE_COVERAGE_REMOTE_PATH_FILTER`" - -#: ../../rst/reference_appendices/config.rst:983 -msgid "DEFAULT_ACTION_PLUGIN_PATH" -msgstr "DEFAULT_ACTION_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:985 -#: ../../rst/reference_appendices/config.rst:3540 -msgid "Colon separated paths in which Ansible will search for Action Plugins." -msgstr "Ansible が Action プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:987 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/action:/usr/share/ansible/plugins/action\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/action:/usr/share/ansible/plugins/action\" }}``" - -#: ../../rst/reference_appendices/config.rst:990 -msgid "action_plugins" -msgstr "action_plugins" - -#: ../../rst/reference_appendices/config.rst:992 -msgid ":envvar:`ANSIBLE_ACTION_PLUGINS`" -msgstr ":envvar:`ANSIBLE_ACTION_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:997 -msgid "DEFAULT_ALLOW_UNSAFE_LOOKUPS" -msgstr "DEFAULT_ALLOW_UNSAFE_LOOKUPS" - -#: ../../rst/reference_appendices/config.rst:999 -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 backward 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" -msgstr "このオプションを有効にすると、(変数で ``{{lookup('foo')}}`` として、または with_foo のようなループとして使用されているかに関係なく) lookup プラグインが「安全でない」と表示されていないデータを返します。デフォルトでは、このようなデータは、テンプレートエンジンが jinja2 テンプレート言語を評価できないようにするために、安全ではないと表示されています。これは、セキュリティーリスクを示している場合があるためです。このオプションは、下位互換性を確保するために提供されていますが、ユーザーはまず、後でテンプレートエンジンを介して実行する可能性のあるデータが含まれていると予想されるルックアップに allow_unsafe=True を追加することを検討する必要があります。" - -#: ../../rst/reference_appendices/config.rst:1002 -msgid "2.2.3" -msgstr "2.2.3" - -#: ../../rst/reference_appendices/config.rst:1005 -msgid "allow_unsafe_lookups" -msgstr "allow_unsafe_lookups" - -#: ../../rst/reference_appendices/config.rst:1010 -msgid "DEFAULT_ASK_PASS" -msgstr "DEFAULT_ASK_PASS" - -#: ../../rst/reference_appendices/config.rst:1012 -#: ../../rst/reference_appendices/config.rst:3549 -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." -msgstr "これは、Ansible Playbook がログインパスワードを要求するかどうかを制御します。認証に SSH 鍵を使用する場合は、この設定を変更する必要がない可能性があります。" - -#: ../../rst/reference_appendices/config.rst:1017 -msgid "ask_pass" -msgstr "ask_pass" - -#: ../../rst/reference_appendices/config.rst:1019 -msgid ":envvar:`ANSIBLE_ASK_PASS`" -msgstr ":envvar:`ANSIBLE_ASK_PASS`" - -#: ../../rst/reference_appendices/config.rst:1024 -msgid "DEFAULT_ASK_VAULT_PASS" -msgstr "DEFAULT_ASK_VAULT_PASS" - -#: ../../rst/reference_appendices/config.rst:1026 -#: ../../rst/reference_appendices/config.rst:3557 -msgid "This controls whether an Ansible playbook should prompt for a vault password." -msgstr "これは、Ansible Playbook が Vault パスワードを要求するかどうかを制御します。" - -#: ../../rst/reference_appendices/config.rst:1031 -msgid "ask_vault_pass" -msgstr "ask_vault_pass" - -#: ../../rst/reference_appendices/config.rst:1033 -msgid ":envvar:`ANSIBLE_ASK_VAULT_PASS`" -msgstr ":envvar:`ANSIBLE_ASK_VAULT_PASS`" - -#: ../../rst/reference_appendices/config.rst:1038 -msgid "DEFAULT_BECOME" -msgstr "DEFAULT_BECOME" - -#: ../../rst/reference_appendices/config.rst:1040 -#: ../../rst/reference_appendices/config.rst:3565 -msgid "Toggles the use of privilege escalation, allowing you to 'become' another user after login." -msgstr "権限昇格の使用を切り替えて、ログイン後に別のユーザーになる (「become」) ことができるようにします。" - -#: ../../rst/reference_appendices/config.rst:1045 -#: ../../rst/reference_appendices/playbooks_keywords.rst:30 -#: ../../rst/reference_appendices/playbooks_keywords.rst:162 -#: ../../rst/reference_appendices/playbooks_keywords.rst:255 -#: ../../rst/reference_appendices/playbooks_keywords.rst:363 -msgid "become" -msgstr "become" - -#: ../../rst/reference_appendices/config.rst:1047 -msgid ":envvar:`ANSIBLE_BECOME`" -msgstr ":envvar:`ANSIBLE_BECOME`" - -#: ../../rst/reference_appendices/config.rst:1052 -msgid "DEFAULT_BECOME_ASK_PASS" -msgstr "DEFAULT_BECOME_ASK_PASS" - -#: ../../rst/reference_appendices/config.rst:1054 -#: ../../rst/reference_appendices/config.rst:3573 -msgid "Toggle to prompt for privilege escalation password." -msgstr "切り替えて、権限昇格パスワードの入力を求めます。" - -#: ../../rst/reference_appendices/config.rst:1059 -msgid "become_ask_pass" -msgstr "become_ask_pass" - -#: ../../rst/reference_appendices/config.rst:1061 -msgid ":envvar:`ANSIBLE_BECOME_ASK_PASS`" -msgstr ":envvar:`ANSIBLE_BECOME_ASK_PASS`" - -#: ../../rst/reference_appendices/config.rst:1066 -msgid "DEFAULT_BECOME_EXE" -msgstr "DEFAULT_BECOME_EXE" - -#: ../../rst/reference_appendices/config.rst:1068 -#: ../../rst/reference_appendices/config.rst:3589 -msgid "executable to use for privilege escalation, otherwise Ansible will depend on PATH" -msgstr "特権昇格に使用する実行ファイル。それ以外の場合、Ansible は PATH に依存します。" - -#: ../../rst/reference_appendices/config.rst:1072 -#: ../../rst/reference_appendices/playbooks_keywords.rst:33 -#: ../../rst/reference_appendices/playbooks_keywords.rst:165 -#: ../../rst/reference_appendices/playbooks_keywords.rst:258 -#: ../../rst/reference_appendices/playbooks_keywords.rst:366 -msgid "become_exe" -msgstr "become_exe" - -#: ../../rst/reference_appendices/config.rst:1074 -msgid ":envvar:`ANSIBLE_BECOME_EXE`" -msgstr ":envvar:`ANSIBLE_BECOME_EXE`" - -#: ../../rst/reference_appendices/config.rst:1079 -msgid "DEFAULT_BECOME_FLAGS" -msgstr "DEFAULT_BECOME_FLAGS" - -#: ../../rst/reference_appendices/config.rst:1081 -#: ../../rst/reference_appendices/config.rst:3597 -msgid "Flags to pass to the privilege escalation executable." -msgstr "権限昇格実行ファイルに渡すフラグ。" - -#: ../../rst/reference_appendices/config.rst:1085 -#: ../../rst/reference_appendices/playbooks_keywords.rst:36 -#: ../../rst/reference_appendices/playbooks_keywords.rst:168 -#: ../../rst/reference_appendices/playbooks_keywords.rst:261 -#: ../../rst/reference_appendices/playbooks_keywords.rst:369 -msgid "become_flags" -msgstr "become_flags" - -#: ../../rst/reference_appendices/config.rst:1087 -msgid ":envvar:`ANSIBLE_BECOME_FLAGS`" -msgstr ":envvar:`ANSIBLE_BECOME_FLAGS`" - -#: ../../rst/reference_appendices/config.rst:1092 -msgid "DEFAULT_BECOME_METHOD" -msgstr "DEFAULT_BECOME_METHOD" - -#: ../../rst/reference_appendices/config.rst:1094 -#: ../../rst/reference_appendices/config.rst:3581 -msgid "Privilege escalation method to use when `become` is enabled." -msgstr "`become` が有効な場合に使用する権限昇格方法です。" - -#: ../../rst/reference_appendices/config.rst:1095 -msgid "``sudo``" -msgstr "``sudo``" - -#: ../../rst/reference_appendices/config.rst:1098 -#: ../../rst/reference_appendices/playbooks_keywords.rst:39 -#: ../../rst/reference_appendices/playbooks_keywords.rst:171 -#: ../../rst/reference_appendices/playbooks_keywords.rst:264 -#: ../../rst/reference_appendices/playbooks_keywords.rst:372 -msgid "become_method" -msgstr "become_method" - -#: ../../rst/reference_appendices/config.rst:1100 -msgid ":envvar:`ANSIBLE_BECOME_METHOD`" -msgstr ":envvar:`ANSIBLE_BECOME_METHOD`" - -#: ../../rst/reference_appendices/config.rst:1105 -msgid "DEFAULT_BECOME_USER" -msgstr "DEFAULT_BECOME_USER" - -#: ../../rst/reference_appendices/config.rst:1107 -#: ../../rst/reference_appendices/config.rst:3613 -msgid "The user your login/remote user 'becomes' when using privilege escalation, most systems will use 'root' when no user is specified." -msgstr "権限昇格を使用する際にログイン/リモートユーザーが「なる(becomes)」ユーザー。ユーザーを指定しないと、ほとんどのシステムは「root」を使用します。" - -#: ../../rst/reference_appendices/config.rst:1108 -msgid "``root``" -msgstr "``root``" - -#: ../../rst/reference_appendices/config.rst:1111 -#: ../../rst/reference_appendices/playbooks_keywords.rst:42 -#: ../../rst/reference_appendices/playbooks_keywords.rst:174 -#: ../../rst/reference_appendices/playbooks_keywords.rst:267 -#: ../../rst/reference_appendices/playbooks_keywords.rst:375 -msgid "become_user" -msgstr "become_user" - -#: ../../rst/reference_appendices/config.rst:1113 -msgid ":envvar:`ANSIBLE_BECOME_USER`" -msgstr ":envvar:`ANSIBLE_BECOME_USER`" - -#: ../../rst/reference_appendices/config.rst:1118 -msgid "DEFAULT_CACHE_PLUGIN_PATH" -msgstr "DEFAULT_CACHE_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1120 -#: ../../rst/reference_appendices/config.rst:3621 -msgid "Colon separated paths in which Ansible will search for Cache Plugins." -msgstr "Ansible が Cache プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1122 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/cache:/usr/share/ansible/plugins/cache\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/cache:/usr/share/ansible/plugins/cache\" }}``" - -#: ../../rst/reference_appendices/config.rst:1125 -msgid "cache_plugins" -msgstr "cache_plugins" - -#: ../../rst/reference_appendices/config.rst:1127 -msgid ":envvar:`ANSIBLE_CACHE_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CACHE_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1132 -msgid "DEFAULT_CALLBACK_PLUGIN_PATH" -msgstr "DEFAULT_CALLBACK_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1134 -#: ../../rst/reference_appendices/config.rst:3629 -msgid "Colon separated paths in which Ansible will search for Callback Plugins." -msgstr "Ansible が Callback プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1136 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/callback:/usr/share/ansible/plugins/callback\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/callback:/usr/share/ansible/plugins/callback\" }}``" - -#: ../../rst/reference_appendices/config.rst:1139 -msgid "callback_plugins" -msgstr "callback_plugins" - -#: ../../rst/reference_appendices/config.rst:1141 -msgid ":envvar:`ANSIBLE_CALLBACK_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CALLBACK_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1146 -msgid "DEFAULT_CLICONF_PLUGIN_PATH" -msgstr "DEFAULT_CLICONF_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1148 -#: ../../rst/reference_appendices/config.rst:3656 -msgid "Colon separated paths in which Ansible will search for Cliconf Plugins." -msgstr "Ansible が Cliconf プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1150 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/cliconf:/usr/share/ansible/plugins/cliconf\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/cliconf:/usr/share/ansible/plugins/cliconf\" }}``" - -#: ../../rst/reference_appendices/config.rst:1153 -msgid "cliconf_plugins" -msgstr "cliconf_plugins" - -#: ../../rst/reference_appendices/config.rst:1155 -msgid ":envvar:`ANSIBLE_CLICONF_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CLICONF_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1160 -msgid "DEFAULT_CONNECTION_PLUGIN_PATH" -msgstr "DEFAULT_CONNECTION_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1162 -#: ../../rst/reference_appendices/config.rst:3664 -msgid "Colon separated paths in which Ansible will search for Connection Plugins." -msgstr "Ansible が connection プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1164 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/connection:/usr/share/ansible/plugins/connection\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/connection:/usr/share/ansible/plugins/connection\" }}``" - -#: ../../rst/reference_appendices/config.rst:1167 -msgid "connection_plugins" -msgstr "connection_plugins" - -#: ../../rst/reference_appendices/config.rst:1169 -msgid ":envvar:`ANSIBLE_CONNECTION_PLUGINS`" -msgstr ":envvar:`ANSIBLE_CONNECTION_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1174 -msgid "DEFAULT_DEBUG" -msgstr "DEFAULT_DEBUG" - -#: ../../rst/reference_appendices/config.rst:1176 -#: ../../rst/reference_appendices/config.rst:3672 -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." -msgstr "Ansible でデバッグ出力を切り替えます。これは *非常に* 詳細であり、マルチプロセッシングを妨げる可能性があります。no_log 設定が有効になっている場合でも、デバッグ出力に秘密情報を含めることができます。つまり、デバッグモードは、実稼働環境で使用しないでください。" - -#: ../../rst/reference_appendices/config.rst:1183 -msgid ":envvar:`ANSIBLE_DEBUG`" -msgstr ":envvar:`ANSIBLE_DEBUG`" - -#: ../../rst/reference_appendices/config.rst:1188 -msgid "DEFAULT_EXECUTABLE" -msgstr "DEFAULT_EXECUTABLE" - -#: ../../rst/reference_appendices/config.rst:1190 -#: ../../rst/reference_appendices/config.rst:3680 -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." -msgstr "これは、ターゲットでの Ansible の実行ニーズに合わせてシェルを生成するために使用するコマンドを示します。シェルの使用が制限されている場合、ユーザーはまれにこれを変更する必要がありますが、ほとんどの場合は、そのままにしておくことができます。" - -#: ../../rst/reference_appendices/config.rst:1191 -msgid "``/bin/sh``" -msgstr "``/bin/sh``" - -#: ../../rst/reference_appendices/config.rst:1194 -msgid "executable" -msgstr "executable" - -#: ../../rst/reference_appendices/config.rst:1196 -msgid ":envvar:`ANSIBLE_EXECUTABLE`" -msgstr ":envvar:`ANSIBLE_EXECUTABLE`" - -#: ../../rst/reference_appendices/config.rst:1201 -msgid "DEFAULT_FACT_PATH" -msgstr "DEFAULT_FACT_PATH" - -#: ../../rst/reference_appendices/config.rst:1203 -msgid "This option allows you to globally configure a custom path for 'local_facts' for the implied :ref:`ansible_collections.ansible.builtin.setup_module` task when using fact gathering. If not set, it will fallback to the default from the ``ansible.builtin.setup`` module: ``/etc/ansible/facts.d``. This does **not** affect user defined tasks that use the ``ansible.builtin.setup`` module. The real action being created by the implicit task is currently ``ansible.legacy.gather_facts`` module, which then calls the configured fact modules, by default this will be ``ansible.builtin.setup`` for POSIX systems but other platforms might have different defaults." -msgstr "このオプションを使用すると、ファクト収集を使用している場合に暗黙的な:ref:`ansible_collections.ansible.builtin.setup_module`タスクの「local_facts」のカスタムパスをグローバルに設定できます。これが設定されていない場合には、``ansible.builtin.setup`` モジュール: ``/etc/ansible/facts.d`` からデフォルトにフォールバックします。この設定は、``ansible.builtin.setup`` モジュールを使用するユーザー定義のタスクには影響は **ありません**。暗黙的なタスクで作成される実際のアクションは現在は、 ``ansible.legacy.gather_facts`` モジュールで、このモジュールが設定済みのファクトモジュールを呼び出します。デフォルトでは、これは POSIX の ``ansible.builtin.setup`` ですが、他のプラットフォームには別の初期値がある可能性があります。" - -#: ../../rst/reference_appendices/config.rst:1207 -#: ../../rst/reference_appendices/playbooks_keywords.rst:68 -msgid "fact_path" -msgstr "fact_path" - -#: ../../rst/reference_appendices/config.rst:1209 -msgid ":envvar:`ANSIBLE_FACT_PATH`" -msgstr ":envvar:`ANSIBLE_FACT_PATH`" - -#: ../../rst/reference_appendices/config.rst:1210 -#: ../../rst/reference_appendices/config.rst:1270 -#: ../../rst/reference_appendices/config.rst:1286 -msgid "2.18" -msgstr "2.18" - -#: ../../rst/reference_appendices/config.rst:1211 -#: ../../rst/reference_appendices/config.rst:1271 -#: ../../rst/reference_appendices/config.rst:1287 -msgid "the module_defaults keyword is a more generic version and can apply to all calls to the M(ansible.builtin.gather_facts) or M(ansible.builtin.setup) actions" -msgstr "module_defaults キーワードはより一般的なバージョンであり、M(ansible.builtin.gather_facts) または M(ansible.builtin.setup) アクションへのすべての呼び出しに適用できます。" - -#: ../../rst/reference_appendices/config.rst:1212 -#: ../../rst/reference_appendices/config.rst:1272 -#: ../../rst/reference_appendices/config.rst:1288 -#: ../../rst/reference_appendices/playbooks_keywords.rst:98 -#: ../../rst/reference_appendices/playbooks_keywords.rst:212 -#: ../../rst/reference_appendices/playbooks_keywords.rst:308 -#: ../../rst/reference_appendices/playbooks_keywords.rst:431 -msgid "module_defaults" -msgstr "module_defaults" - -#: ../../rst/reference_appendices/config.rst:1217 -msgid "DEFAULT_FILTER_PLUGIN_PATH" -msgstr "DEFAULT_FILTER_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1219 -#: ../../rst/reference_appendices/config.rst:3696 -msgid "Colon separated paths in which Ansible will search for Jinja2 Filter Plugins." -msgstr "Ansible が Jinja2 フィルタープラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1221 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/filter:/usr/share/ansible/plugins/filter\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/filter:/usr/share/ansible/plugins/filter\" }}``" - -#: ../../rst/reference_appendices/config.rst:1224 -msgid "filter_plugins" -msgstr "filter_plugins" - -#: ../../rst/reference_appendices/config.rst:1226 -msgid ":envvar:`ANSIBLE_FILTER_PLUGINS`" -msgstr ":envvar:`ANSIBLE_FILTER_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1231 -msgid "DEFAULT_FORCE_HANDLERS" -msgstr "DEFAULT_FORCE_HANDLERS" - -#: ../../rst/reference_appendices/config.rst:1233 -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." -msgstr "このオプションは、ホストで障害が発生した場合でも、通知されたハンドラーがホストで実行されるかどうかを制御します。false にすると、ホストで障害が発生した場合に、ハンドラーは実行されません。これは、プレイごとまたはコマンドラインで設定することもできます。詳細は、「ハンドラーおよび失敗」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:1236 -msgid "1.9.1" -msgstr "1.9.1" - -#: ../../rst/reference_appendices/config.rst:1239 -#: ../../rst/reference_appendices/playbooks_keywords.rst:71 -msgid "force_handlers" -msgstr "force_handlers" - -#: ../../rst/reference_appendices/config.rst:1241 -msgid ":envvar:`ANSIBLE_FORCE_HANDLERS`" -msgstr ":envvar:`ANSIBLE_FORCE_HANDLERS`" - -#: ../../rst/reference_appendices/config.rst:1246 -msgid "DEFAULT_FORKS" -msgstr "DEFAULT_FORKS" - -#: ../../rst/reference_appendices/config.rst:1248 -#: ../../rst/reference_appendices/config.rst:3712 -msgid "Maximum number of forks Ansible will use to execute tasks on target hosts." -msgstr "ターゲットホストでタスクを実行するのに Ansible が使用するフォークの最大数。" - -#: ../../rst/reference_appendices/config.rst:1250 -#: ../../rst/reference_appendices/config.rst:3123 -msgid "``5``" -msgstr "``5``" - -#: ../../rst/reference_appendices/config.rst:1253 -msgid "forks" -msgstr "forks" - -#: ../../rst/reference_appendices/config.rst:1255 -msgid ":envvar:`ANSIBLE_FORKS`" -msgstr ":envvar:`ANSIBLE_FORKS`" - -#: ../../rst/reference_appendices/config.rst:1260 -msgid "DEFAULT_GATHER_SUBSET" -msgstr "DEFAULT_GATHER_SUBSET" - -#: ../../rst/reference_appendices/config.rst:1262 -msgid "Set the `gather_subset` option for the :ref:`ansible_collections.ansible.builtin.setup_module` task in the implicit fact gathering. See the module documentation for specifics. It does **not** apply to user defined ``ansible.builtin.setup`` tasks." -msgstr "暗黙的なファクト収集の :ref:`ansible_collections.ansible.builtin.setup_module` タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の ``ansible.builtin.setup`` タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:1264 -#: ../../rst/reference_appendices/config.rst:1430 -#: ../../rst/reference_appendices/config.rst:2034 -msgid "2.1" -msgstr "2.1" - -#: ../../rst/reference_appendices/config.rst:1267 -#: ../../rst/reference_appendices/playbooks_keywords.rst:77 -msgid "gather_subset" -msgstr "gather_subset" - -#: ../../rst/reference_appendices/config.rst:1269 -msgid ":envvar:`ANSIBLE_GATHER_SUBSET`" -msgstr ":envvar:`ANSIBLE_GATHER_SUBSET`" - -#: ../../rst/reference_appendices/config.rst:1277 -msgid "DEFAULT_GATHER_TIMEOUT" -msgstr "DEFAULT_GATHER_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:1279 -msgid "Set the timeout in seconds for the implicit fact gathering, see the module documentation for specifics. It does **not** apply to user defined :ref:`ansible_collections.ansible.builtin.setup_module` tasks." -msgstr "暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の :ref:`ansible_collections.ansible.builtin.setup_module` タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:1283 -#: ../../rst/reference_appendices/playbooks_keywords.rst:80 -msgid "gather_timeout" -msgstr "gather_timeout" - -#: ../../rst/reference_appendices/config.rst:1285 -msgid ":envvar:`ANSIBLE_GATHER_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_GATHER_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:1293 -msgid "DEFAULT_GATHERING" -msgstr "DEFAULT_GATHERING" - -#: ../../rst/reference_appendices/config.rst:1295 -msgid "This setting controls the default policy of fact gathering (facts discovered about remote systems). This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin." -msgstr "この設定は、ファクト収集 (リモートシステムについて検出されたファクト) のデフォルトポリシーを制御します。このオプションは、ファクト収集の時間を節約する場合に役立ちます。'smart' と 'explicit' の両方がキャッシュプラグインを使用します。" - -#: ../../rst/reference_appendices/config.rst:1296 -msgid "``implicit``" -msgstr "``implicit``" - -#: ../../rst/reference_appendices/config.rst -msgid "implicit" -msgstr "implicit" - -#: ../../rst/reference_appendices/config.rst:1298 -msgid "the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set." -msgstr "'gather_facts:False' が設定されていない限り、キャッシュプラグインは無視され、ファクトはプレイごとに収集されます。" - -#: ../../rst/reference_appendices/config.rst -msgid "explicit" -msgstr "explicit" - -#: ../../rst/reference_appendices/config.rst:1299 -msgid "facts will not be gathered unless directly requested in the play." -msgstr "プレイで直接要求されない限り、ファクトは収集されません。" - -#: ../../rst/reference_appendices/config.rst -msgid "smart" -msgstr "smart" - -#: ../../rst/reference_appendices/config.rst:1300 -msgid "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 run." -msgstr "ファクトが検出されていない新しいホストはそれぞれスキャンされますが、同じホストが複数のプレイでアドレス指定されている場合には、実行中に再度接続されることはありません。" - -#: ../../rst/reference_appendices/config.rst:1301 -msgid "1.6" -msgstr "1.6" - -#: ../../rst/reference_appendices/config.rst:1304 -msgid "gathering" -msgstr "gathering" - -#: ../../rst/reference_appendices/config.rst:1306 -msgid ":envvar:`ANSIBLE_GATHERING`" -msgstr ":envvar:`ANSIBLE_GATHERING`" - -#: ../../rst/reference_appendices/config.rst:1311 -msgid "DEFAULT_HASH_BEHAVIOUR" -msgstr "DEFAULT_HASH_BEHAVIOUR" - -#: ../../rst/reference_appendices/config.rst:1313 -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'**." -msgstr "この設定は、ディクショナリー変数 (別名ハッシュ、マップ、連想配列) の重複した定義を Ansible でどのように扱うかを制御します。この設定は、値がスカラー (整数、文字列) や配列である変数には影響しません。**警告** これは脆弱で、コンテンツ (プレイ、ロール、コレクション) が移植できなくなり、継続的な混乱と誤用を招く恐れがあるため、この設定を変更することは推奨されません。絶対に必要であると思われる場合を除き、この設定を変更しないでください。変数名の再利用は回避し、``combine`` フィルターと ``vars`` ルックアップおよび ``varnames`` ルックアップを利用して、個々の変数のマージバージョンを作成することが推奨されます。経験上、このようなことが本当に必要とされることはほとんどなく、データ構造やプレイが複雑になりすぎていることを示しています。用途によっては、入力時にマージするカスタム vars_plugins を検討することもできますし、``host_vars/`` ディレクトリーおよび ``group_vars/`` ディレクトリーの解析を担当するデフォルトの ``host_group_vars`` を置き換えることもできます。この設定のほとんどのユーザーはインベントリースコープにしか興味がありませんが、この設定自体がすべてのソースに影響し、デバッグをさらに困難にします。公式のサンプルリポジトリーにある Playbook およびロールはすべて、この設定のデフォルトを想定しています。``merge`` に設定を変更すると、変数ソース全体に適用されますが、多くのソースでは内部的に変数が上書きされたままになります。たとえば、``include_vars`` は、Ansible を更新する前に内部で変数の重複を排除し、「最終定義」が同じファイルの以前の定義を上書きします。Ansible プロジェクトでは、**新規プロジェクトでは** ``merge`` **を回避する** ことが推奨されます。Ansible 開発者は、最終的にこの設定を非推奨にして削除することを意図していますが、一部のユーザーがこの設定に大きく依存しているため、この設定を残しています。新しいプロジェクトでは、**「merge」を回避** してください。" - -#: ../../rst/reference_appendices/config.rst:1315 -msgid "``replace``" -msgstr "``replace``" - -#: ../../rst/reference_appendices/config.rst -msgid "replace" -msgstr "replace" - -#: ../../rst/reference_appendices/config.rst:1317 -msgid "Any variable that is defined more than once is overwritten using the order from variable precedence rules (highest wins)." -msgstr "複数の変数が定義されている変数は、変数の優先順位ルール (最も高いものが優先されます) の順序を使用して上書きされます。" - -#: ../../rst/reference_appendices/config.rst -msgid "merge" -msgstr "merge" - -#: ../../rst/reference_appendices/config.rst:1318 -msgid "Any dictionary variable will be recursively merged with new definitions across the different variable definition sources." -msgstr "ディクショナリー変数は、異なる変数定義ソース全体で新しい定義と再帰的にマージされます。" - -#: ../../rst/reference_appendices/config.rst:1321 -msgid "hash_behaviour" -msgstr "hash_behaviour" - -#: ../../rst/reference_appendices/config.rst:1323 -msgid ":envvar:`ANSIBLE_HASH_BEHAVIOUR`" -msgstr ":envvar:`ANSIBLE_HASH_BEHAVIOUR`" - -#: ../../rst/reference_appendices/config.rst:1328 -msgid "DEFAULT_HOST_LIST" -msgstr "DEFAULT_HOST_LIST" - -#: ../../rst/reference_appendices/config.rst:1330 -#: ../../rst/reference_appendices/config.rst:3752 -msgid "Comma separated list of Ansible inventory sources" -msgstr "Ansible インベントリーソースのコンマ区切り一覧。" - -#: ../../rst/reference_appendices/config.rst:1331 -msgid "pathlist" -msgstr "pathlist" - -#: ../../rst/reference_appendices/config.rst:1332 -msgid "``/etc/ansible/hosts``" -msgstr "``/etc/ansible/hosts``" - -#: ../../rst/reference_appendices/config.rst:1335 -msgid "inventory" -msgstr "インベントリー" - -#: ../../rst/reference_appendices/config.rst:1337 -msgid ":envvar:`ANSIBLE_INVENTORY`" -msgstr ":envvar:`ANSIBLE_INVENTORY`" - -#: ../../rst/reference_appendices/config.rst:1342 -msgid "DEFAULT_HTTPAPI_PLUGIN_PATH" -msgstr "DEFAULT_HTTPAPI_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1344 -#: ../../rst/reference_appendices/config.rst:3760 -msgid "Colon separated paths in which Ansible will search for HttpApi Plugins." -msgstr "Ansible が HttpApi プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1346 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/httpapi:/usr/share/ansible/plugins/httpapi\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/httpapi:/usr/share/ansible/plugins/httpapi\" }}``" - -#: ../../rst/reference_appendices/config.rst:1349 -msgid "httpapi_plugins" -msgstr "httpapi_plugins" - -#: ../../rst/reference_appendices/config.rst:1351 -msgid ":envvar:`ANSIBLE_HTTPAPI_PLUGINS`" -msgstr ":envvar:`ANSIBLE_HTTPAPI_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1356 -msgid "DEFAULT_INTERNAL_POLL_INTERVAL" -msgstr "DEFAULT_INTERNAL_POLL_INTERVAL" - -#: ../../rst/reference_appendices/config.rst:1358 -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" -msgstr "これにより、Ansible の内部プロセスが相互にポーリングする間隔 (秒単位) が設定されます。値を低くすると、CPU の負荷が増える代わりに、大きな Playbook のパフォーマンスが改善します。UI の応答性は必要ありませんが、CPU 使用率が問題になる可能性がある場合は、自動化シナリオでの Ansible の使用には高い値が適しています。デフォルトは、2.1 以下の Ansible でハードコードされた値に対応します。" - -#: ../../rst/reference_appendices/config.rst:1359 -#: ../../rst/reference_appendices/config.rst:3151 -msgid "float" -msgstr "float" - -#: ../../rst/reference_appendices/config.rst:1360 -msgid "``0.001``" -msgstr "``0.001``" - -#: ../../rst/reference_appendices/config.rst:1361 -msgid "2.2" -msgstr "2.2" - -#: ../../rst/reference_appendices/config.rst:1364 -msgid "internal_poll_interval" -msgstr "internal_poll_interval" - -#: ../../rst/reference_appendices/config.rst:1369 -msgid "DEFAULT_INVENTORY_PLUGIN_PATH" -msgstr "DEFAULT_INVENTORY_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1371 -#: ../../rst/reference_appendices/config.rst:3769 -msgid "Colon separated paths in which Ansible will search for Inventory Plugins." -msgstr "Ansible が inventory プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1373 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/inventory:/usr/share/ansible/plugins/inventory\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/inventory:/usr/share/ansible/plugins/inventory\" }}``" - -#: ../../rst/reference_appendices/config.rst:1376 -msgid "inventory_plugins" -msgstr "inventory_plugins" - -#: ../../rst/reference_appendices/config.rst:1378 -msgid ":envvar:`ANSIBLE_INVENTORY_PLUGINS`" -msgstr ":envvar:`ANSIBLE_INVENTORY_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1383 -msgid "DEFAULT_JINJA2_EXTENSIONS" -msgstr "DEFAULT_JINJA2_EXTENSIONS" - -#: ../../rst/reference_appendices/config.rst:1385 -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 :)" -msgstr "これは、追加の Jinja2 拡張機能を有効にすることができる開発者固有の機能です。詳細については、Jinja2 ドキュメントを参照してください。この拡張機能が何をするのかわからない場合は、おそらくこの設定を変更する必要はありません。" - -#: ../../rst/reference_appendices/config.rst:1389 -msgid "jinja2_extensions" -msgstr "jinja2_extensions" - -#: ../../rst/reference_appendices/config.rst:1391 -msgid ":envvar:`ANSIBLE_JINJA2_EXTENSIONS`" -msgstr ":envvar:`ANSIBLE_JINJA2_EXTENSIONS`" - -#: ../../rst/reference_appendices/config.rst:1396 -msgid "DEFAULT_JINJA2_NATIVE" -msgstr "DEFAULT_JINJA2_NATIVE" - -#: ../../rst/reference_appendices/config.rst:1398 -#: ../../rst/reference_appendices/config.rst:3785 -msgid "This option preserves variable types during template operations." -msgstr "このオプションは、テンプレート操作中、変数タイプを保持します。" - -#: ../../rst/reference_appendices/config.rst:1404 -msgid "jinja2_native" -msgstr "jinja2_native" - -#: ../../rst/reference_appendices/config.rst:1406 -msgid ":envvar:`ANSIBLE_JINJA2_NATIVE`" -msgstr ":envvar:`ANSIBLE_JINJA2_NATIVE`" - -#: ../../rst/reference_appendices/config.rst:1411 -msgid "DEFAULT_KEEP_REMOTE_FILES" -msgstr "DEFAULT_KEEP_REMOTE_FILES" - -#: ../../rst/reference_appendices/config.rst:1413 -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``." -msgstr "リモートでタスクを実行するために Ansible が使用する一時ファイルのクリーンアップを有効または無効にします。このオプションを有効にすると、``ANSIBLE_PIPELINING`` を無効にします。" - -#: ../../rst/reference_appendices/config.rst:1418 -msgid "keep_remote_files" -msgstr "keep_remote_files" - -#: ../../rst/reference_appendices/config.rst:1420 -msgid ":envvar:`ANSIBLE_KEEP_REMOTE_FILES`" -msgstr ":envvar:`ANSIBLE_KEEP_REMOTE_FILES`" - -#: ../../rst/reference_appendices/config.rst:1425 -msgid "DEFAULT_LIBVIRT_LXC_NOSECLABEL" -msgstr "DEFAULT_LIBVIRT_LXC_NOSECLABEL" - -#: ../../rst/reference_appendices/config.rst:1427 -#: ../../rst/reference_appendices/config.rst:3801 -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." -msgstr "この設定により、--noseclabel を virsh に渡して、libvirt が lxc コンテナーに接続します。これは、SELinux がないシステムで実行する際に必要です。" - -#: ../../rst/reference_appendices/config.rst:1432 -#: ../../rst/reference_appendices/config.rst:1732 -msgid "[selinux]" -msgstr "[selinux]" - -#: ../../rst/reference_appendices/config.rst:1433 -msgid "libvirt_lxc_noseclabel" -msgstr "libvirt_lxc_noseclabel" - -#: ../../rst/reference_appendices/config.rst:1435 -msgid ":envvar:`ANSIBLE_LIBVIRT_LXC_NOSECLABEL`" -msgstr ":envvar:`ANSIBLE_LIBVIRT_LXC_NOSECLABEL`" - -#: ../../rst/reference_appendices/config.rst:1440 -msgid "DEFAULT_LOAD_CALLBACK_PLUGINS" -msgstr "DEFAULT_LOAD_CALLBACK_PLUGINS" - -#: ../../rst/reference_appendices/config.rst:1442 -#: ../../rst/reference_appendices/config.rst:3809 -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``." -msgstr "/usr/bin/ansible の実行時に callback プラグインを読み込まれるかどうかを制御します。これは、コマンドラインからのアクティビティのログ記録、通知の送信などに使用できます。``ansible-playbook`` に callback プラグインが常に読み込まれます。" - -#: ../../rst/reference_appendices/config.rst:1445 -msgid "1.8" -msgstr "1.8" - -#: ../../rst/reference_appendices/config.rst:1448 -msgid "bin_ansible_callbacks" -msgstr "bin_ansible_callbacks" - -#: ../../rst/reference_appendices/config.rst:1450 -msgid ":envvar:`ANSIBLE_LOAD_CALLBACK_PLUGINS`" -msgstr ":envvar:`ANSIBLE_LOAD_CALLBACK_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1455 -msgid "DEFAULT_LOCAL_TMP" -msgstr "DEFAULT_LOCAL_TMP" - -#: ../../rst/reference_appendices/config.rst:1457 -#: ../../rst/reference_appendices/config.rst:3817 -msgid "Temporary directory for Ansible to use on the controller." -msgstr "Ansible がコントローラーで使用するための一時ディレクトリー。" - -#: ../../rst/reference_appendices/config.rst:1458 -msgid "tmppath" -msgstr "tmppath" - -#: ../../rst/reference_appendices/config.rst:1459 -msgid "``{{ ANSIBLE_HOME ~ \"/tmp\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/tmp\" }}``" - -#: ../../rst/reference_appendices/config.rst:1462 -msgid "local_tmp" -msgstr "local_tmp" - -#: ../../rst/reference_appendices/config.rst:1464 -msgid ":envvar:`ANSIBLE_LOCAL_TEMP`" -msgstr ":envvar:`ANSIBLE_LOCAL_TEMP`" - -#: ../../rst/reference_appendices/config.rst:1469 -msgid "DEFAULT_LOG_FILTER" -msgstr "DEFAULT_LOG_FILTER" - -#: ../../rst/reference_appendices/config.rst:1471 -#: ../../rst/reference_appendices/config.rst:3833 -msgid "List of logger names to filter out of the log file" -msgstr "ログファイルから除外するロガー名の一覧。" - -#: ../../rst/reference_appendices/config.rst:1476 -msgid "log_filter" -msgstr "log_filter" - -#: ../../rst/reference_appendices/config.rst:1478 -msgid ":envvar:`ANSIBLE_LOG_FILTER`" -msgstr ":envvar:`ANSIBLE_LOG_FILTER`" - -#: ../../rst/reference_appendices/config.rst:1483 -msgid "DEFAULT_LOG_PATH" -msgstr "DEFAULT_LOG_PATH" - -#: ../../rst/reference_appendices/config.rst:1485 -#: ../../rst/reference_appendices/config.rst:3825 -msgid "File to which Ansible will log on the controller. When empty logging is disabled." -msgstr "Ansible がコントローラーにログインするファイル。空のロギングが無効になっている場合。" - -#: ../../rst/reference_appendices/config.rst:1490 -msgid "log_path" -msgstr "log_path" - -#: ../../rst/reference_appendices/config.rst:1492 -msgid ":envvar:`ANSIBLE_LOG_PATH`" -msgstr ":envvar:`ANSIBLE_LOG_PATH`" - -#: ../../rst/reference_appendices/config.rst:1497 -msgid "DEFAULT_LOOKUP_PLUGIN_PATH" -msgstr "DEFAULT_LOOKUP_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1499 -#: ../../rst/reference_appendices/config.rst:3841 -msgid "Colon separated paths in which Ansible will search for Lookup Plugins." -msgstr "Ansible が Lookup プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1501 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/lookup:/usr/share/ansible/plugins/lookup\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/lookup:/usr/share/ansible/plugins/lookup\" }}``" - -#: ../../rst/reference_appendices/config.rst:1504 -msgid "lookup_plugins" -msgstr "lookup_plugins" - -#: ../../rst/reference_appendices/config.rst:1506 -msgid ":envvar:`ANSIBLE_LOOKUP_PLUGINS`" -msgstr ":envvar:`ANSIBLE_LOOKUP_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1511 -msgid "DEFAULT_MANAGED_STR" -msgstr "DEFAULT_MANAGED_STR" - -#: ../../rst/reference_appendices/config.rst:1513 -msgid "Sets the macro for the 'ansible_managed' variable available for :ref:`ansible_collections.ansible.builtin.template_module` and :ref:`ansible_collections.ansible.windows.win_template_module`. This is only relevant for those two modules." -msgstr ":ref:`ansible_collections.ansible.builtin.template_module` および :ref:`ansible_collections.ansible.windows.win_template_module` 'ansible_managed' 変数のマクロを設定します。該当するのは、これら 2 つのモジュールのみです。" - -#: ../../rst/reference_appendices/config.rst:1514 -msgid "``Ansible managed``" -msgstr "``Ansible managed``" - -#: ../../rst/reference_appendices/config.rst:1517 -msgid "ansible_managed" -msgstr "ansible_managed" - -#: ../../rst/reference_appendices/config.rst:1522 -msgid "DEFAULT_MODULE_ARGS" -msgstr "DEFAULT_MODULE_ARGS" - -#: ../../rst/reference_appendices/config.rst:1524 -#: ../../rst/reference_appendices/config.rst:3850 -msgid "This sets the default arguments to pass to the ``ansible`` adhoc binary if no ``-a`` is specified." -msgstr "これにより、``ansible`` が指定されていない場合に、``-a`` アドホックバイナリーに渡すデフォルトの引数が設定されます。" - -#: ../../rst/reference_appendices/config.rst:1528 -msgid "module_args" -msgstr "module_args" - -#: ../../rst/reference_appendices/config.rst:1530 -msgid ":envvar:`ANSIBLE_MODULE_ARGS`" -msgstr ":envvar:`ANSIBLE_MODULE_ARGS`" - -#: ../../rst/reference_appendices/config.rst:1535 -msgid "DEFAULT_MODULE_COMPRESSION" -msgstr "DEFAULT_MODULE_COMPRESSION" - -#: ../../rst/reference_appendices/config.rst:1537 -msgid "Compression scheme to use when transferring Python modules to the target." -msgstr "Python モジュールをターゲットに転送する際に使用する圧縮スキーム。" - -#: ../../rst/reference_appendices/config.rst:1538 -msgid "``ZIP_DEFLATED``" -msgstr "``ZIP_DEFLATED``" - -#: ../../rst/reference_appendices/config.rst:1541 -msgid "module_compression" -msgstr "module_compression" - -#: ../../rst/reference_appendices/config.rst:1546 -msgid "DEFAULT_MODULE_NAME" -msgstr "DEFAULT_MODULE_NAME" - -#: ../../rst/reference_appendices/config.rst:1548 -msgid "Module to use with the ``ansible`` AdHoc command, if none is specified via ``-m``." -msgstr "``-m`` で何も指定されていない場合は、``ansible`` AdHoc コマンドで使用するモジュール。" - -#: ../../rst/reference_appendices/config.rst:1549 -msgid "``command``" -msgstr "``command``" - -#: ../../rst/reference_appendices/config.rst:1552 -msgid "module_name" -msgstr "module_name" - -#: ../../rst/reference_appendices/config.rst:1557 -msgid "DEFAULT_MODULE_PATH" -msgstr "DEFAULT_MODULE_PATH" - -#: ../../rst/reference_appendices/config.rst:1559 -#: ../../rst/reference_appendices/config.rst:3860 -msgid "Colon separated paths in which Ansible will search for Modules." -msgstr "Ansible がモジュールを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1561 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/modules:/usr/share/ansible/plugins/modules\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/modules:/usr/share/ansible/plugins/modules\" }}``" - -#: ../../rst/reference_appendices/config.rst:1564 -msgid "library" -msgstr "library" - -#: ../../rst/reference_appendices/config.rst:1566 -msgid ":envvar:`ANSIBLE_LIBRARY`" -msgstr ":envvar:`ANSIBLE_LIBRARY`" - -#: ../../rst/reference_appendices/config.rst:1571 -msgid "DEFAULT_MODULE_UTILS_PATH" -msgstr "DEFAULT_MODULE_UTILS_PATH" - -#: ../../rst/reference_appendices/config.rst:1573 -#: ../../rst/reference_appendices/config.rst:3868 -msgid "Colon separated paths in which Ansible will search for Module utils files, which are shared by modules." -msgstr "モジュールが共有するモジュールのユーティリティーファイルを Ansible が検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1575 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/module_utils:/usr/share/ansible/plugins/module_utils\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/module_utils:/usr/share/ansible/plugins/module_utils\" }}``" - -#: ../../rst/reference_appendices/config.rst:1578 -msgid "module_utils" -msgstr "モジュールユーティリティー" - -#: ../../rst/reference_appendices/config.rst:1580 -msgid ":envvar:`ANSIBLE_MODULE_UTILS`" -msgstr ":envvar:`ANSIBLE_MODULE_UTILS`" - -#: ../../rst/reference_appendices/config.rst:1585 -msgid "DEFAULT_NETCONF_PLUGIN_PATH" -msgstr "DEFAULT_NETCONF_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1587 -#: ../../rst/reference_appendices/config.rst:3876 -msgid "Colon separated paths in which Ansible will search for Netconf Plugins." -msgstr "Ansible が Netconf プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1589 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/netconf:/usr/share/ansible/plugins/netconf\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/netconf:/usr/share/ansible/plugins/netconf\" }}``" - -#: ../../rst/reference_appendices/config.rst:1592 -msgid "netconf_plugins" -msgstr "netconf_plugins" - -#: ../../rst/reference_appendices/config.rst:1594 -msgid ":envvar:`ANSIBLE_NETCONF_PLUGINS`" -msgstr ":envvar:`ANSIBLE_NETCONF_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1599 -msgid "DEFAULT_NO_LOG" -msgstr "DEFAULT_NO_LOG" - -#: ../../rst/reference_appendices/config.rst:1601 -#: ../../rst/reference_appendices/config.rst:3884 -msgid "Toggle Ansible's display and logging of task details, mainly used to avoid security disclosures." -msgstr "主にセキュリティーの公開を回避するために、Ansible の表示およびタスク詳細のロギングを使用します。" - -#: ../../rst/reference_appendices/config.rst:1606 -#: ../../rst/reference_appendices/playbooks_keywords.rst:104 -#: ../../rst/reference_appendices/playbooks_keywords.rst:218 -#: ../../rst/reference_appendices/playbooks_keywords.rst:314 -#: ../../rst/reference_appendices/playbooks_keywords.rst:437 -msgid "no_log" -msgstr "no_log" - -#: ../../rst/reference_appendices/config.rst:1608 -msgid ":envvar:`ANSIBLE_NO_LOG`" -msgstr ":envvar:`ANSIBLE_NO_LOG`" - -#: ../../rst/reference_appendices/config.rst:1613 -msgid "DEFAULT_NO_TARGET_SYSLOG" -msgstr "DEFAULT_NO_TARGET_SYSLOG" - -#: ../../rst/reference_appendices/config.rst:1615 -#: ../../rst/reference_appendices/config.rst:3892 -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." -msgstr "タスクの実行時に、Ansible ログをターゲットの syslog へ切り替えます。Windows ホストでは、これにより、新しいスタイルの PowerShell モジュールがイベントログに書き込むことができなくなります。" - -#: ../../rst/reference_appendices/config.rst:1620 -msgid "no_target_syslog" -msgstr "no_target_syslog" - -#: ../../rst/reference_appendices/config.rst:1622 -msgid ":envvar:`ANSIBLE_NO_TARGET_SYSLOG`" -msgstr ":envvar:`ANSIBLE_NO_TARGET_SYSLOG`" - -#: ../../rst/reference_appendices/config.rst:1624 -msgid "`ansible_no_target_syslog` :Version Added: 2.10" -msgstr "`ansible_no_target_syslog` :Version Added: 2.10" - -#: ../../rst/reference_appendices/config.rst:1630 -msgid "DEFAULT_NULL_REPRESENTATION" -msgstr "DEFAULT_NULL_REPRESENTATION" - -#: ../../rst/reference_appendices/config.rst:1632 -#: ../../rst/reference_appendices/config.rst:3900 -msgid "What templating should return as a 'null' value. When not set it will let Jinja2 decide." -msgstr "テンプレートが「null」値として返すもの。設定しないと、Jinja2 が決定します。" - -#: ../../rst/reference_appendices/config.rst:1633 -msgid "raw" -msgstr "raw" - -#: ../../rst/reference_appendices/config.rst:1637 -msgid "null_representation" -msgstr "null_representation" - -#: ../../rst/reference_appendices/config.rst:1639 -msgid ":envvar:`ANSIBLE_NULL_REPRESENTATION`" -msgstr ":envvar:`ANSIBLE_NULL_REPRESENTATION`" - -#: ../../rst/reference_appendices/config.rst:1644 -msgid "DEFAULT_POLL_INTERVAL" -msgstr "DEFAULT_POLL_INTERVAL" - -#: ../../rst/reference_appendices/config.rst:1646 -#: ../../rst/reference_appendices/config.rst:3908 -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." -msgstr "Ansible の非同期タスク (「非同期アクションとポーリング」で説明) では、これは、明示的なポーリング間隔が指定されていない場合に、これらのタスクのステータスを確認する頻度です。デフォルトは適度に中程度の 15 秒です。これは、頻繁に確認することと、何かが完了したときに迅速に対応することとのトレードオフになっています。" - -#: ../../rst/reference_appendices/config.rst:1648 -#: ../../rst/reference_appendices/config.rst:2763 -msgid "``15``" -msgstr "``15``" - -#: ../../rst/reference_appendices/config.rst:1651 -msgid "poll_interval" -msgstr "poll_interval" - -#: ../../rst/reference_appendices/config.rst:1653 -msgid ":envvar:`ANSIBLE_POLL_INTERVAL`" -msgstr ":envvar:`ANSIBLE_POLL_INTERVAL`" - -#: ../../rst/reference_appendices/config.rst:1658 -msgid "DEFAULT_PRIVATE_KEY_FILE" -msgstr "DEFAULT_PRIVATE_KEY_FILE" - -#: ../../rst/reference_appendices/config.rst:1660 -#: ../../rst/reference_appendices/config.rst:3916 -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." -msgstr "エージェントやパスワードではなく、証明書またはキーファイルを使用して認証する接続のオプションです。ここでデフォルト値を設定して、呼び出しごとに --private-key が再指定されないようにすることができます。" - -#: ../../rst/reference_appendices/config.rst:1665 -msgid "private_key_file" -msgstr "private_key_file" - -#: ../../rst/reference_appendices/config.rst:1667 -msgid ":envvar:`ANSIBLE_PRIVATE_KEY_FILE`" -msgstr ":envvar:`ANSIBLE_PRIVATE_KEY_FILE`" - -#: ../../rst/reference_appendices/config.rst:1672 -msgid "DEFAULT_PRIVATE_ROLE_VARS" -msgstr "DEFAULT_PRIVATE_ROLE_VARS" - -#: ../../rst/reference_appendices/config.rst:1674 -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." -msgstr "ロール変数が他のロールからアクセスできないようにします。これは、Playbook でロールが複数回使用されている場合に、ロール変数をデフォルト値にリセットする方法として導入されました。" - -#: ../../rst/reference_appendices/config.rst:1679 -msgid "private_role_vars" -msgstr "private_role_vars" - -#: ../../rst/reference_appendices/config.rst:1681 -msgid ":envvar:`ANSIBLE_PRIVATE_ROLE_VARS`" -msgstr ":envvar:`ANSIBLE_PRIVATE_ROLE_VARS`" - -#: ../../rst/reference_appendices/config.rst:1686 -msgid "DEFAULT_REMOTE_PORT" -msgstr "DEFAULT_REMOTE_PORT" - -#: ../../rst/reference_appendices/config.rst:1688 -#: ../../rst/reference_appendices/config.rst:3932 -msgid "Port to use in remote connections, when blank it will use the connection plugin default." -msgstr "リモート接続で使用するポート。空の場合は、connection プラグインのデフォルトを使用します。" - -#: ../../rst/reference_appendices/config.rst:1693 -msgid "remote_port" -msgstr "remote_port" - -#: ../../rst/reference_appendices/config.rst:1695 -msgid ":envvar:`ANSIBLE_REMOTE_PORT`" -msgstr ":envvar:`ANSIBLE_REMOTE_PORT`" - -#: ../../rst/reference_appendices/config.rst:1700 -msgid "DEFAULT_REMOTE_USER" -msgstr "DEFAULT_REMOTE_USER" - -#: ../../rst/reference_appendices/config.rst:1702 -msgid "Sets the login user for the target machines When blank it uses the connection plugin's default, normally the user currently executing Ansible." -msgstr "ターゲットマシンのログインユーザーを設定します。空の場合は、connection プラグインのデフォルト (通常は現在 Ansible を実行しているユーザー) を使用します。" - -#: ../../rst/reference_appendices/config.rst:1705 -#: ../../rst/reference_appendices/playbooks_keywords.rst:119 -#: ../../rst/reference_appendices/playbooks_keywords.rst:224 -#: ../../rst/reference_appendices/playbooks_keywords.rst:323 -#: ../../rst/reference_appendices/playbooks_keywords.rst:452 -msgid "remote_user" -msgstr "remote_user" - -#: ../../rst/reference_appendices/config.rst:1707 -msgid ":envvar:`ANSIBLE_REMOTE_USER`" -msgstr ":envvar:`ANSIBLE_REMOTE_USER`" - -#: ../../rst/reference_appendices/config.rst:1712 -msgid "DEFAULT_ROLES_PATH" -msgstr "DEFAULT_ROLES_PATH" - -#: ../../rst/reference_appendices/config.rst:1714 -#: ../../rst/reference_appendices/config.rst:3948 -msgid "Colon separated paths in which Ansible will search for Roles." -msgstr "Ansible がロールを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1716 -msgid "``{{ ANSIBLE_HOME ~ \"/roles:/usr/share/ansible/roles:/etc/ansible/roles\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/roles:/usr/share/ansible/roles:/etc/ansible/roles\" }}``" - -#: ../../rst/reference_appendices/config.rst:1719 -msgid "roles_path" -msgstr "roles_path" - -#: ../../rst/reference_appendices/config.rst:1721 -msgid ":envvar:`ANSIBLE_ROLES_PATH`" -msgstr ":envvar:`ANSIBLE_ROLES_PATH`" - -#: ../../rst/reference_appendices/config.rst:1726 -msgid "DEFAULT_SELINUX_SPECIAL_FS" -msgstr "DEFAULT_SELINUX_SPECIAL_FS" - -#: ../../rst/reference_appendices/config.rst:1728 -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." -msgstr "一部のファイルシステムは安全な操作をサポートしていないか、一貫性のないエラーを返します。この設定により、Ansible はリスト内のエラーを「許容」し、致命的なエラーを引き起こしません。ファイルシステムがリストに含まれていると、データが破損する可能性があり、書き込みが常に検証されるとは限りません。" - -#: ../../rst/reference_appendices/config.rst:1730 -msgid "``fuse, nfs, vboxsf, ramfs, 9p, vfat``" -msgstr "``fuse, nfs, vboxsf, ramfs, 9p, vfat``" - -#: ../../rst/reference_appendices/config.rst:1733 -msgid "special_context_filesystems" -msgstr "special_context_filesystems" - -#: ../../rst/reference_appendices/config.rst:1735 -msgid ":envvar:`ANSIBLE_SELINUX_SPECIAL_FS` :Version Added: 2.9" -msgstr ":envvar:`ANSIBLE_SELINUX_SPECIAL_FS` :Version Added: 2.9" - -#: ../../rst/reference_appendices/config.rst:1741 -msgid "DEFAULT_STDOUT_CALLBACK" -msgstr "DEFAULT_STDOUT_CALLBACK" - -#: ../../rst/reference_appendices/config.rst:1743 -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. See :ref:`callback_plugins` for a list of available options." -msgstr "Ansible 出力の表示に使用されるメインコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、標準出力 (stdout) に使用できるのは 1 つだけです。利用可能なオプションの一覧は、:ref:`callback_plugins` を参照してください。" - -#: ../../rst/reference_appendices/config.rst:1747 -msgid "stdout_callback" -msgstr "stdout_callback" - -#: ../../rst/reference_appendices/config.rst:1749 -msgid ":envvar:`ANSIBLE_STDOUT_CALLBACK`" -msgstr ":envvar:`ANSIBLE_STDOUT_CALLBACK`" - -#: ../../rst/reference_appendices/config.rst:1754 -msgid "DEFAULT_STRATEGY" -msgstr "DEFAULT_STRATEGY" - -#: ../../rst/reference_appendices/config.rst:1756 -#: ../../rst/reference_appendices/config.rst:3989 -msgid "Set the default strategy used for plays." -msgstr "プレイに使用するデフォルトのストラテジーを設定します。" - -#: ../../rst/reference_appendices/config.rst:1757 -msgid "``linear``" -msgstr "``linear``" - -#: ../../rst/reference_appendices/config.rst:1758 -msgid "2.3" -msgstr "2.3" - -#: ../../rst/reference_appendices/config.rst:1761 -#: ../../rst/reference_appendices/playbooks_keywords.rst:131 -msgid "strategy" -msgstr "strategy" - -#: ../../rst/reference_appendices/config.rst:1763 -msgid ":envvar:`ANSIBLE_STRATEGY`" -msgstr ":envvar:`ANSIBLE_STRATEGY`" - -#: ../../rst/reference_appendices/config.rst:1768 -msgid "DEFAULT_STRATEGY_PLUGIN_PATH" -msgstr "DEFAULT_STRATEGY_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1770 -#: ../../rst/reference_appendices/config.rst:3997 -msgid "Colon separated paths in which Ansible will search for Strategy Plugins." -msgstr "Ansible が Strategy プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1772 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/strategy:/usr/share/ansible/plugins/strategy\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/strategy:/usr/share/ansible/plugins/strategy\" }}``" - -#: ../../rst/reference_appendices/config.rst:1775 -msgid "strategy_plugins" -msgstr "strategy_plugins" - -#: ../../rst/reference_appendices/config.rst:1777 -msgid ":envvar:`ANSIBLE_STRATEGY_PLUGINS`" -msgstr ":envvar:`ANSIBLE_STRATEGY_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1782 -msgid "DEFAULT_SU" -msgstr "DEFAULT_SU" - -#: ../../rst/reference_appendices/config.rst:1784 -#: ../../rst/reference_appendices/config.rst:4005 -msgid "Toggle the use of \"su\" for tasks." -msgstr "タスクに「su」の使用を切り替えます。" - -#: ../../rst/reference_appendices/config.rst:1789 -msgid "su" -msgstr "su" - -#: ../../rst/reference_appendices/config.rst:1791 -msgid ":envvar:`ANSIBLE_SU`" -msgstr ":envvar:`ANSIBLE_SU`" - -#: ../../rst/reference_appendices/config.rst:1796 -msgid "DEFAULT_SYSLOG_FACILITY" -msgstr "DEFAULT_SYSLOG_FACILITY" - -#: ../../rst/reference_appendices/config.rst:1798 -#: ../../rst/reference_appendices/config.rst:4013 -msgid "Syslog facility to use when Ansible logs to the remote target" -msgstr "Ansible がリモートターゲットにログを記録するときに使用する syslog ファシリティー。" - -#: ../../rst/reference_appendices/config.rst:1799 -msgid "``LOG_USER``" -msgstr "``LOG_USER``" - -#: ../../rst/reference_appendices/config.rst:1802 -msgid "syslog_facility" -msgstr "syslog_facility" - -#: ../../rst/reference_appendices/config.rst:1804 -msgid ":envvar:`ANSIBLE_SYSLOG_FACILITY`" -msgstr ":envvar:`ANSIBLE_SYSLOG_FACILITY`" - -#: ../../rst/reference_appendices/config.rst:1809 -msgid "DEFAULT_TERMINAL_PLUGIN_PATH" -msgstr "DEFAULT_TERMINAL_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1811 -#: ../../rst/reference_appendices/config.rst:4021 -msgid "Colon separated paths in which Ansible will search for Terminal Plugins." -msgstr "Ansible が Terminal プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1813 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/terminal:/usr/share/ansible/plugins/terminal\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/terminal:/usr/share/ansible/plugins/terminal\" }}``" - -#: ../../rst/reference_appendices/config.rst:1816 -msgid "terminal_plugins" -msgstr "terminal_plugins" - -#: ../../rst/reference_appendices/config.rst:1818 -msgid ":envvar:`ANSIBLE_TERMINAL_PLUGINS`" -msgstr ":envvar:`ANSIBLE_TERMINAL_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1823 -msgid "DEFAULT_TEST_PLUGIN_PATH" -msgstr "DEFAULT_TEST_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1825 -#: ../../rst/reference_appendices/config.rst:4029 -msgid "Colon separated paths in which Ansible will search for Jinja2 Test Plugins." -msgstr "Ansible が Jinja2 テストプラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1827 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/test:/usr/share/ansible/plugins/test\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/test:/usr/share/ansible/plugins/test\" }}``" - -#: ../../rst/reference_appendices/config.rst:1830 -msgid "test_plugins" -msgstr "test_plugins" - -#: ../../rst/reference_appendices/config.rst:1832 -msgid ":envvar:`ANSIBLE_TEST_PLUGINS`" -msgstr ":envvar:`ANSIBLE_TEST_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1837 -msgid "DEFAULT_TIMEOUT" -msgstr "DEFAULT_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:1839 -#: ../../rst/reference_appendices/config.rst:4037 -msgid "This is the default timeout for connection plugins to use." -msgstr "これは、connection プラグインが使用するデフォルトのタイムアウトです。" - -#: ../../rst/reference_appendices/config.rst:1841 -msgid "``10``" -msgstr "``10``" - -#: ../../rst/reference_appendices/config.rst:1844 -#: ../../rst/reference_appendices/playbooks_keywords.rst:143 -#: ../../rst/reference_appendices/playbooks_keywords.rst:236 -#: ../../rst/reference_appendices/playbooks_keywords.rst:338 -#: ../../rst/reference_appendices/playbooks_keywords.rst:467 -msgid "timeout" -msgstr "timeout" - -#: ../../rst/reference_appendices/config.rst:1846 -msgid ":envvar:`ANSIBLE_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:1851 -msgid "DEFAULT_TRANSPORT" -msgstr "DEFAULT_TRANSPORT" - -#: ../../rst/reference_appendices/config.rst:1853 -#: ../../rst/reference_appendices/config.rst:4045 -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:1854 -msgid "``smart``" -msgstr "``smart``" - -#: ../../rst/reference_appendices/config.rst:1857 -msgid "transport" -msgstr "transport" - -#: ../../rst/reference_appendices/config.rst:1859 -msgid ":envvar:`ANSIBLE_TRANSPORT`" -msgstr ":envvar:`ANSIBLE_TRANSPORT`" - -#: ../../rst/reference_appendices/config.rst:1864 -msgid "DEFAULT_UNDEFINED_VAR_BEHAVIOR" -msgstr "DEFAULT_UNDEFINED_VAR_BEHAVIOR" - -#: ../../rst/reference_appendices/config.rst:1866 -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." -msgstr "True にすると、タイプミスの可能性が高い変数名を参照するステップが失敗するテンプレートが作成されます。True に設定しないと、未定義の変数を含む '{{ template_expression }}' は、記述されたとおりにテンプレートまたは ansible のアクション行にレンダリングされます。" - -#: ../../rst/reference_appendices/config.rst:1869 -msgid "1.3" -msgstr "1.3" - -#: ../../rst/reference_appendices/config.rst:1872 -msgid "error_on_undefined_vars" -msgstr "error_on_undefined_vars" - -#: ../../rst/reference_appendices/config.rst:1874 -msgid ":envvar:`ANSIBLE_ERROR_ON_UNDEFINED_VARS`" -msgstr ":envvar:`ANSIBLE_ERROR_ON_UNDEFINED_VARS`" - -#: ../../rst/reference_appendices/config.rst:1879 -msgid "DEFAULT_VARS_PLUGIN_PATH" -msgstr "DEFAULT_VARS_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:1881 -#: ../../rst/reference_appendices/config.rst:4061 -msgid "Colon separated paths in which Ansible will search for Vars Plugins." -msgstr "Ansible が Vars プラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:1883 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/vars:/usr/share/ansible/plugins/vars\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/vars:/usr/share/ansible/plugins/vars\" }}``" - -#: ../../rst/reference_appendices/config.rst:1886 -msgid "vars_plugins" -msgstr "vars_plugins" - -#: ../../rst/reference_appendices/config.rst:1888 -msgid ":envvar:`ANSIBLE_VARS_PLUGINS`" -msgstr ":envvar:`ANSIBLE_VARS_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:1893 -msgid "DEFAULT_VAULT_ENCRYPT_IDENTITY" -msgstr "DEFAULT_VAULT_ENCRYPT_IDENTITY" - -#: ../../rst/reference_appendices/config.rst:1895 -#: ../../rst/reference_appendices/config.rst:4085 -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." -msgstr "デフォルトで暗号化に使用する vault_id です。複数の vault_ids が提供されると、暗号化に使用するものを指定します。--encrypt-vault-id cli オプションは、設定した値をオーバーライドします。" - -#: ../../rst/reference_appendices/config.rst:1898 -msgid "vault_encrypt_identity" -msgstr "vault_encrypt_identity" - -#: ../../rst/reference_appendices/config.rst:1900 -msgid ":envvar:`ANSIBLE_VAULT_ENCRYPT_IDENTITY`" -msgstr ":envvar:`ANSIBLE_VAULT_ENCRYPT_IDENTITY`" - -#: ../../rst/reference_appendices/config.rst:1905 -msgid "DEFAULT_VAULT_ID_MATCH" -msgstr "DEFAULT_VAULT_ID_MATCH" - -#: ../../rst/reference_appendices/config.rst:1907 -#: ../../rst/reference_appendices/config.rst:4069 -msgid "If true, decrypting vaults with a vault id will only try the password from the matching vault-id" -msgstr "true の場合、Vault id で Vault を復号すると、一致する Vault id からのみパスワードを試みます。" - -#: ../../rst/reference_appendices/config.rst:1911 -msgid "vault_id_match" -msgstr "vault_id_match" - -#: ../../rst/reference_appendices/config.rst:1913 -msgid ":envvar:`ANSIBLE_VAULT_ID_MATCH`" -msgstr ":envvar:`ANSIBLE_VAULT_ID_MATCH`" - -#: ../../rst/reference_appendices/config.rst:1918 -msgid "DEFAULT_VAULT_IDENTITY" -msgstr "DEFAULT_VAULT_IDENTITY" - -#: ../../rst/reference_appendices/config.rst:1920 -#: ../../rst/reference_appendices/config.rst:4077 -msgid "The label to use for the default vault id label in cases where a vault id label is not provided" -msgstr "Vault id ラベルが指定されていない場合にデフォルトの Vault id ラベルに使用するラベル。" - -#: ../../rst/reference_appendices/config.rst:1924 -msgid "vault_identity" -msgstr "vault_identity" - -#: ../../rst/reference_appendices/config.rst:1926 -msgid ":envvar:`ANSIBLE_VAULT_IDENTITY`" -msgstr ":envvar:`ANSIBLE_VAULT_IDENTITY`" - -#: ../../rst/reference_appendices/config.rst:1931 -msgid "DEFAULT_VAULT_IDENTITY_LIST" -msgstr "DEFAULT_VAULT_IDENTITY_LIST" - -#: ../../rst/reference_appendices/config.rst:1933 -#: ../../rst/reference_appendices/config.rst:4093 -msgid "A list of vault-ids to use by default. Equivalent to multiple --vault-id args. Vault-ids are tried in order." -msgstr "デフォルトで使用する vault-id の一覧。複数の --vault-id 引数と同等です。vault-ids は順番に試行されます。" - -#: ../../rst/reference_appendices/config.rst:1938 -msgid "vault_identity_list" -msgstr "vault_identity_list" - -#: ../../rst/reference_appendices/config.rst:1940 -msgid ":envvar:`ANSIBLE_VAULT_IDENTITY_LIST`" -msgstr ":envvar:`ANSIBLE_VAULT_IDENTITY_LIST`" - -#: ../../rst/reference_appendices/config.rst:1945 -msgid "DEFAULT_VAULT_PASSWORD_FILE" -msgstr "DEFAULT_VAULT_PASSWORD_FILE" - -#: ../../rst/reference_appendices/config.rst:1947 -msgid "The vault password file to use. Equivalent to --vault-password-file or --vault-id If executable, it will be run and the resulting stdout will be used as the password." -msgstr "使用する Vault パスワードファイル。--vault-password-file または --vault-id と同等です。実行可能な場合には、実行されて、生成される標準出力がパスワードとして使用されます。" - -#: ../../rst/reference_appendices/config.rst:1952 -msgid "vault_password_file" -msgstr "vault_password_file" - -#: ../../rst/reference_appendices/config.rst:1954 -msgid ":envvar:`ANSIBLE_VAULT_PASSWORD_FILE`" -msgstr ":envvar:`ANSIBLE_VAULT_PASSWORD_FILE`" - -#: ../../rst/reference_appendices/config.rst:1959 -msgid "DEFAULT_VERBOSITY" -msgstr "DEFAULT_VERBOSITY" - -#: ../../rst/reference_appendices/config.rst:1961 -#: ../../rst/reference_appendices/config.rst:4109 -msgid "Sets the default verbosity, equivalent to the number of ``-v`` passed in the command line." -msgstr "コマンドラインで渡された ``-v`` の数と同等の、デフォルトの詳細レベルを設定します。" - -#: ../../rst/reference_appendices/config.rst:1963 -#: ../../rst/reference_appendices/config.rst:2849 -#: ../../rst/reference_appendices/config.rst:3014 -#: ../../rst/reference_appendices/config.rst:3140 -msgid "``0``" -msgstr "``0``" - -#: ../../rst/reference_appendices/config.rst:1966 -msgid "verbosity" -msgstr "verbosity" - -#: ../../rst/reference_appendices/config.rst:1968 -msgid ":envvar:`ANSIBLE_VERBOSITY`" -msgstr ":envvar:`ANSIBLE_VERBOSITY`" - -#: ../../rst/reference_appendices/config.rst:1973 -msgid "DEPRECATION_WARNINGS" -msgstr "DEPRECATION_WARNINGS" - -#: ../../rst/reference_appendices/config.rst:1975 -#: ../../rst/reference_appendices/config.rst:4117 -msgid "Toggle to control the showing of deprecation warnings" -msgstr "非推奨の警告の表示を制御するために切り替えます。" - -#: ../../rst/reference_appendices/config.rst:1980 -msgid "deprecation_warnings" -msgstr "deprecation_warnings" - -#: ../../rst/reference_appendices/config.rst:1982 -msgid ":envvar:`ANSIBLE_DEPRECATION_WARNINGS`" -msgstr ":envvar:`ANSIBLE_DEPRECATION_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:1987 -msgid "DEVEL_WARNING" -msgstr "DEVEL_WARNING" - -#: ../../rst/reference_appendices/config.rst:1989 -#: ../../rst/reference_appendices/config.rst:4125 -msgid "Toggle to control showing warnings related to running devel" -msgstr "devel の実行に関連する警告を表示するように制御を切り替えます。" - -#: ../../rst/reference_appendices/config.rst:1994 -msgid "devel_warning" -msgstr "devel_warning" - -#: ../../rst/reference_appendices/config.rst:1996 -msgid ":envvar:`ANSIBLE_DEVEL_WARNING`" -msgstr ":envvar:`ANSIBLE_DEVEL_WARNING`" - -#: ../../rst/reference_appendices/config.rst:2001 -msgid "DIFF_ALWAYS" -msgstr "DIFF_ALWAYS" - -#: ../../rst/reference_appendices/config.rst:2003 -#: ../../rst/reference_appendices/config.rst:4133 -msgid "Configuration toggle to tell modules to show differences when in 'changed' status, equivalent to ``--diff``." -msgstr "構成の切り替えにより、「changed」状態のときに相違点を表示するようにモジュールに指示します (``--diff`` 相当)。" - -#: ../../rst/reference_appendices/config.rst:2004 -#: ../../rst/reference_appendices/config.rst:2193 -#: ../../rst/reference_appendices/config.rst:2208 -#: ../../rst/reference_appendices/config.rst:2468 -#: ../../rst/reference_appendices/config.rst:2546 -#: ../../rst/reference_appendices/config.rst:2593 -#: ../../rst/reference_appendices/config.rst:2865 -#: ../../rst/reference_appendices/config.rst:2911 -#: ../../rst/reference_appendices/config.rst:3062 -#: ../../rst/reference_appendices/config.rst:3107 -msgid "bool" -msgstr "bool" - -#: ../../rst/reference_appendices/config.rst:2007 -#: ../../rst/reference_appendices/config.rst:2021 -msgid "[diff]" -msgstr "[diff]" - -#: ../../rst/reference_appendices/config.rst -#: ../../rst/reference_appendices/config.rst:2008 -#: ../../rst/reference_appendices/playbooks_keywords.rst:249 -msgid "always" -msgstr "always" - -#: ../../rst/reference_appendices/config.rst:2010 -msgid ":envvar:`ANSIBLE_DIFF_ALWAYS`" -msgstr ":envvar:`ANSIBLE_DIFF_ALWAYS`" - -#: ../../rst/reference_appendices/config.rst:2015 -msgid "DIFF_CONTEXT" -msgstr "DIFF_CONTEXT" - -#: ../../rst/reference_appendices/config.rst:2017 -#: ../../rst/reference_appendices/config.rst:4141 -msgid "How many lines of context to show when displaying the differences between files." -msgstr "ファイル間の差異を表示する際に表示するコンテキストの行数。" - -#: ../../rst/reference_appendices/config.rst:2019 -msgid "``3``" -msgstr "``3``" - -#: ../../rst/reference_appendices/config.rst:2022 -msgid "context" -msgstr "context" - -#: ../../rst/reference_appendices/config.rst:2024 -msgid ":envvar:`ANSIBLE_DIFF_CONTEXT`" -msgstr ":envvar:`ANSIBLE_DIFF_CONTEXT`" - -#: ../../rst/reference_appendices/config.rst:2029 -msgid "DISPLAY_ARGS_TO_STDOUT" -msgstr "DISPLAY_ARGS_TO_STDOUT" - -#: ../../rst/reference_appendices/config.rst:2031 -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." -msgstr "通常、``ansible-playbook`` は、実行された各タスクのヘッダーが出力されます。これらのヘッダーにはタスクの name: フィールドが指定されていればそれが含まれます。指定していない場合は、``ansible-playbook`` がタスクのアクションを使用して、どのタスクが現在実行されているかを知ることができます。同じアクションの多くを実行する場合は、同じアクションの他のタスクと区別するために、タスクに関する詳細情報が必要になることがあります。設定でこの変数を True に設定すると、``ansible-playbook`` では、タスクの引数もヘッダーに含まれます。パラメーターに機密性の高い値が含まれている可能性があり、それらを出力しないため、この設定の既定値は False です。これを True に設定した場合は、環境の標準出力 (誰もあなたの画面を肩越しに盗み見ることができず、あなたは標準出力を安全でないファイルに保存していません) を確実に保護するか、すべての Playbook で機密性の高い値を持つタスクに ``no_log: True`` パラメーターを明示的に追加する必要があります。詳細は、「Playbook に機密データを保存するにはどうすれば良いですか」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:2037 -msgid "display_args_to_stdout" -msgstr "display_args_to_stdout" - -#: ../../rst/reference_appendices/config.rst:2039 -msgid ":envvar:`ANSIBLE_DISPLAY_ARGS_TO_STDOUT`" -msgstr ":envvar:`ANSIBLE_DISPLAY_ARGS_TO_STDOUT`" - -#: ../../rst/reference_appendices/config.rst:2044 -msgid "DISPLAY_SKIPPED_HOSTS" -msgstr "DISPLAY_SKIPPED_HOSTS" - -#: ../../rst/reference_appendices/config.rst:2046 -#: ../../rst/reference_appendices/config.rst:4157 -msgid "Toggle to control displaying skipped task/host entries in a task in the default callback" -msgstr "デフォルトのコールバックのタスクにスキップされたタスク/ホストエントリーの表示を制御するように切り替えます。" - -#: ../../rst/reference_appendices/config.rst:2051 -msgid "display_skipped_hosts" -msgstr "display_skipped_hosts" - -#: ../../rst/reference_appendices/config.rst:2053 -msgid ":envvar:`ANSIBLE_DISPLAY_SKIPPED_HOSTS`" -msgstr ":envvar:`ANSIBLE_DISPLAY_SKIPPED_HOSTS`" - -#: ../../rst/reference_appendices/config.rst:2058 -msgid "DOC_FRAGMENT_PLUGIN_PATH" -msgstr "DOC_FRAGMENT_PLUGIN_PATH" - -#: ../../rst/reference_appendices/config.rst:2060 -#: ../../rst/reference_appendices/config.rst:3532 -msgid "Colon separated paths in which Ansible will search for Documentation Fragments Plugins." -msgstr "Ansible が ドキュメントフラグメントプラグインを検索するコロン区切りパス。" - -#: ../../rst/reference_appendices/config.rst:2062 -msgid "``{{ ANSIBLE_HOME ~ \"/plugins/doc_fragments:/usr/share/ansible/plugins/doc_fragments\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/plugins/doc_fragments:/usr/share/ansible/plugins/doc_fragments\" }}``" - -#: ../../rst/reference_appendices/config.rst:2065 -msgid "doc_fragment_plugins" -msgstr "doc_fragment_plugins" - -#: ../../rst/reference_appendices/config.rst:2067 -msgid ":envvar:`ANSIBLE_DOC_FRAGMENT_PLUGINS`" -msgstr ":envvar:`ANSIBLE_DOC_FRAGMENT_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:2072 -msgid "DOCSITE_ROOT_URL" -msgstr "DOCSITE_ROOT_URL" - -#: ../../rst/reference_appendices/config.rst:2074 -msgid "Root docsite URL used to generate docs URLs in warning/error text; must be an absolute URL with valid scheme and trailing slash." -msgstr "警告/エラーテキストでドキュメント URL を生成するために使用されるルートドキュメントサイト URL。有効なスキームおよび末尾のスラッシュが含まれる絶対 URL でなければなりません。" - -#: ../../rst/reference_appendices/config.rst:2075 -msgid "``https://docs.ansible.com/ansible-core/``" -msgstr "``https://docs.ansible.com/ansible-core/``" - -#: ../../rst/reference_appendices/config.rst:2079 -msgid "docsite_root_url" -msgstr "docsite_root_url" - -#: ../../rst/reference_appendices/config.rst:2084 -msgid "DUPLICATE_YAML_DICT_KEY" -msgstr "DUPLICATE_YAML_DICT_KEY" - -#: ../../rst/reference_appendices/config.rst:2086 -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." -msgstr "デフォルトでは、Ansible は、YAML で重複した dict キーが発生した場合に警告を発行します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:2088 -#: ../../rst/reference_appendices/config.rst:2926 -msgid "``warn``" -msgstr "``warn``" - -#: ../../rst/reference_appendices/config.rst:2096 -msgid "duplicate_dict_key" -msgstr "duplicate_dict_key" - -#: ../../rst/reference_appendices/config.rst:2098 -msgid ":envvar:`ANSIBLE_DUPLICATE_YAML_DICT_KEY`" -msgstr ":envvar:`ANSIBLE_DUPLICATE_YAML_DICT_KEY`" - -#: ../../rst/reference_appendices/config.rst:2103 -msgid "ENABLE_TASK_DEBUGGER" -msgstr "ENABLE_TASK_DEBUGGER" - -#: ../../rst/reference_appendices/config.rst:2105 -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." -msgstr "タスクデバッガーを有効にするかどうかにかかわらず、これは以前は strategy プラグインとして実行されていました。これで、すべての strategy プラグインがこの動作を継承できるようになりました。デバッガーは、タスクが到達不能で失敗したときにデフォルトでアクティブになります。柔軟性を高めるには、debugger キーワードを使用します。" - -#: ../../rst/reference_appendices/config.rst:2111 -msgid "enable_task_debugger" -msgstr "enable_task_debugger" - -#: ../../rst/reference_appendices/config.rst:2113 -msgid ":envvar:`ANSIBLE_ENABLE_TASK_DEBUGGER`" -msgstr ":envvar:`ANSIBLE_ENABLE_TASK_DEBUGGER`" - -#: ../../rst/reference_appendices/config.rst:2118 -msgid "ERROR_ON_MISSING_HANDLER" -msgstr "ERROR_ON_MISSING_HANDLER" - -#: ../../rst/reference_appendices/config.rst:2120 -#: ../../rst/reference_appendices/config.rst:4174 -msgid "Toggle to allow missing handlers to become a warning instead of an error when notifying." -msgstr "通知時に、エラーではなく、不足しているハンドラーが警告になるように切り替えます。" - -#: ../../rst/reference_appendices/config.rst:2125 -msgid "error_on_missing_handler" -msgstr "error_on_missing_handler" - -#: ../../rst/reference_appendices/config.rst:2127 -msgid ":envvar:`ANSIBLE_ERROR_ON_MISSING_HANDLER`" -msgstr ":envvar:`ANSIBLE_ERROR_ON_MISSING_HANDLER`" - -#: ../../rst/reference_appendices/config.rst:2132 -msgid "FACTS_MODULES" -msgstr "FACTS_MODULES" - -#: ../../rst/reference_appendices/config.rst:2134 -msgid "Which modules to run during a play's fact gathering stage, using the default of 'smart' will try to figure it out based on connection type. If adding your own modules but you still want to use the default Ansible facts, you will want to include 'setup' or corresponding network module to the list (if you add 'smart', Ansible will also figure it out). This does not affect explicit calls to the 'setup' module, but does always affect the 'gather_facts' action (implicit or explicit)." -msgstr "プレイのファクト収集段階で実行するモジュールは、デフォルトの「smart」を使用すると接続タイプに基づいて確認を試みます。独自のモジュールを追加したうえで、デフォルトの Ansible ファクトを使用したい場合は、「setup」または対応するネットワークモジュールをリストに含める必要があります (「smart」を追加すると、Ansible もそれを認識します)。これは、「setup」モジュールへの明示的な呼び出しには影響しませんが、常に 'gather_facts' アクションに影響します (暗黙的または明示的)。" - -#: ../../rst/reference_appendices/config.rst:2136 -msgid "``['smart']``" -msgstr "``['smart']``" - -#: ../../rst/reference_appendices/config.rst:2139 -msgid "facts_modules" -msgstr "facts_modules" - -#: ../../rst/reference_appendices/config.rst:2141 -msgid ":envvar:`ANSIBLE_FACTS_MODULES`" -msgstr ":envvar:`ANSIBLE_FACTS_MODULES`" - -#: ../../rst/reference_appendices/config.rst:2143 -msgid "`ansible_facts_modules`" -msgstr "`ansible_facts_modules`" - -#: ../../rst/reference_appendices/config.rst:2148 -msgid "GALAXY_CACHE_DIR" -msgstr "GALAXY_CACHE_DIR" - -#: ../../rst/reference_appendices/config.rst:2150 -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." -msgstr "Galaxy サーバーからキャッシュされた応答を保存するディレクトリーです。これは ``ansible-galaxy collection install`` コマンドおよび ``download`` コマンドによってのみ使用されます。このディレクトリー内のキャッシュファイルは、誰でも書き込み可能であれば無視されます。" - -#: ../../rst/reference_appendices/config.rst:2152 -msgid "``{{ ANSIBLE_HOME ~ \"/galaxy_cache\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/galaxy_cache\" }}``" - -#: ../../rst/reference_appendices/config.rst:2155 -#: ../../rst/reference_appendices/config.rst:2168 -#: ../../rst/reference_appendices/config.rst:2182 -#: ../../rst/reference_appendices/config.rst:2197 -#: ../../rst/reference_appendices/config.rst:2212 -#: ../../rst/reference_appendices/config.rst:2226 -#: ../../rst/reference_appendices/config.rst:2239 -#: ../../rst/reference_appendices/config.rst:2269 -#: ../../rst/reference_appendices/config.rst:2283 -#: ../../rst/reference_appendices/config.rst:2296 -#: ../../rst/reference_appendices/config.rst:2310 -#: ../../rst/reference_appendices/config.rst:2323 -#: ../../rst/reference_appendices/config.rst:2337 -#: ../../rst/reference_appendices/config.rst:2352 -msgid "[galaxy]" -msgstr "[galaxy]" - -#: ../../rst/reference_appendices/config.rst:2156 -msgid "cache_dir" -msgstr "cache_dir" - -#: ../../rst/reference_appendices/config.rst:2158 -msgid ":envvar:`ANSIBLE_GALAXY_CACHE_DIR`" -msgstr ":envvar:`ANSIBLE_GALAXY_CACHE_DIR`" - -#: ../../rst/reference_appendices/config.rst:2163 -msgid "GALAXY_COLLECTION_SKELETON" -msgstr "GALAXY_COLLECTION_SKELETON" - -#: ../../rst/reference_appendices/config.rst:2165 -#: ../../rst/reference_appendices/config.rst:4215 -msgid "Collection skeleton directory to use as a template for the ``init`` action in ``ansible-galaxy collection``, same as ``--collection-skeleton``." -msgstr "``ansible-galaxy collection`` の ``init`` アクションのテンプレートとして使用するコレクションのスケルトンディレクトリー。``--collection-skeleton`` と同じです。" - -#: ../../rst/reference_appendices/config.rst:2169 -msgid "collection_skeleton" -msgstr "collection_skeleton" - -#: ../../rst/reference_appendices/config.rst:2171 -msgid ":envvar:`ANSIBLE_GALAXY_COLLECTION_SKELETON`" -msgstr ":envvar:`ANSIBLE_GALAXY_COLLECTION_SKELETON`" - -#: ../../rst/reference_appendices/config.rst:2176 -msgid "GALAXY_COLLECTION_SKELETON_IGNORE" -msgstr "GALAXY_COLLECTION_SKELETON_IGNORE" - -#: ../../rst/reference_appendices/config.rst:2178 -#: ../../rst/reference_appendices/config.rst:4223 -msgid "patterns of files to ignore inside a Galaxy collection skeleton directory" -msgstr "Galaxy コレクションスケルトンディレクトリー内で無視するファイルのパターン。" - -#: ../../rst/reference_appendices/config.rst:2180 -#: ../../rst/reference_appendices/config.rst:2308 -msgid "``['^.git$', '^.*/.git_keep$']``" -msgstr "``['^.git$', '^.*/.git_keep$']``" - -#: ../../rst/reference_appendices/config.rst:2183 -msgid "collection_skeleton_ignore" -msgstr "collection_skeleton_ignore" - -#: ../../rst/reference_appendices/config.rst:2185 -msgid ":envvar:`ANSIBLE_GALAXY_COLLECTION_SKELETON_IGNORE`" -msgstr ":envvar:`ANSIBLE_GALAXY_COLLECTION_SKELETON_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2190 -msgid "GALAXY_DISABLE_GPG_VERIFY" -msgstr "GALAXY_DISABLE_GPG_VERIFY" - -#: ../../rst/reference_appendices/config.rst:2192 -#: ../../rst/reference_appendices/config.rst:4271 -msgid "Disable GPG signature verification during collection installation." -msgstr "コレクションのインストール中に GPG 署名の検証を無効にします。" - -#: ../../rst/reference_appendices/config.rst:2195 -#: ../../rst/reference_appendices/config.rst:2224 -#: ../../rst/reference_appendices/release_and_maintenance.rst:85 -msgid "2.13" -msgstr "2.13" - -#: ../../rst/reference_appendices/config.rst:2198 -msgid "disable_gpg_verify" -msgstr "disable_gpg_verify" - -#: ../../rst/reference_appendices/config.rst:2200 -msgid ":envvar:`ANSIBLE_GALAXY_DISABLE_GPG_VERIFY`" -msgstr ":envvar:`ANSIBLE_GALAXY_DISABLE_GPG_VERIFY`" - -#: ../../rst/reference_appendices/config.rst:2205 -msgid "GALAXY_DISPLAY_PROGRESS" -msgstr "GALAXY_DISPLAY_PROGRESS" - -#: ../../rst/reference_appendices/config.rst:2207 -msgid "Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputing 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." -msgstr "``ansible-galaxy`` の一部の手順では、特定の表示で、または標準出力 (stdout) をファイルに出力するときに問題が発生する可能性のある進行状況ホイールを表示します。この設定オプションは、表示ホイールを表示するかどうかを制御します。デフォルトでは、stdout に tty があると、表示ホイールが表示されます。" - -#: ../../rst/reference_appendices/config.rst:2213 -msgid "display_progress" -msgstr "display_progress" - -#: ../../rst/reference_appendices/config.rst:2215 -msgid ":envvar:`ANSIBLE_GALAXY_DISPLAY_PROGRESS`" -msgstr ":envvar:`ANSIBLE_GALAXY_DISPLAY_PROGRESS`" - -#: ../../rst/reference_appendices/config.rst:2220 -msgid "GALAXY_GPG_KEYRING" -msgstr "GALAXY_GPG_KEYRING" - -#: ../../rst/reference_appendices/config.rst:2222 -#: ../../rst/reference_appendices/config.rst:4279 -msgid "Configure the keyring used for GPG signature verification during collection installation and verification." -msgstr "コレクションのインストールおよび検証中に GPG 署名の検証に使用されるキーリングを設定します。" - -#: ../../rst/reference_appendices/config.rst:2227 -msgid "gpg_keyring" -msgstr "gpg_keyring" - -#: ../../rst/reference_appendices/config.rst:2229 -msgid ":envvar:`ANSIBLE_GALAXY_GPG_KEYRING`" -msgstr ":envvar:`ANSIBLE_GALAXY_GPG_KEYRING`" - -#: ../../rst/reference_appendices/config.rst:2234 -msgid "GALAXY_IGNORE_CERTS" -msgstr "GALAXY_IGNORE_CERTS" - -#: ../../rst/reference_appendices/config.rst:2236 -#: ../../rst/reference_appendices/config.rst:4191 -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." -msgstr "yes に設定すると、ansible-galaxy が TLS 証明書を検証しません。これは、自己署名証明書を使用するサーバーに対してテストを行う場合に便利です。" - -#: ../../rst/reference_appendices/config.rst:2240 -msgid "ignore_certs" -msgstr "ignore_certs" - -#: ../../rst/reference_appendices/config.rst:2242 -msgid ":envvar:`ANSIBLE_GALAXY_IGNORE`" -msgstr ":envvar:`ANSIBLE_GALAXY_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2247 -msgid "GALAXY_IGNORE_INVALID_SIGNATURE_STATUS_CODES" -msgstr "GALAXY_IGNORE_INVALID_SIGNATURE_STATUS_CODES" - -#: ../../rst/reference_appendices/config.rst:2249 -msgid "A list of GPG status codes to ignore during GPG signature verification. See L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) for status code descriptions. If fewer signatures successfully verify the collection than `GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`, signature verification will fail even if all error codes are ignored." -msgstr "GPG 署名の検証中に無視する GPG ステータスコードのリスト。ステータスコードの説明は、L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) を参照してください。コレクションの検証で正常な署名数が `GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` よりも少ない場合には、エラーコードが無視されている場合でも署名の検証に失敗します。" - -#: ../../rst/reference_appendices/config.rst:2252 -msgid "EXPSIG" -msgstr "EXPSIG" - -#: ../../rst/reference_appendices/config.rst:2253 -msgid "EXPKEYSIG" -msgstr "EXPKEYSIG" - -#: ../../rst/reference_appendices/config.rst:2254 -msgid "REVKEYSIG" -msgstr "REVKEYSIG" - -#: ../../rst/reference_appendices/config.rst:2255 -msgid "BADSIG" -msgstr "BADSIG" - -#: ../../rst/reference_appendices/config.rst:2256 -msgid "ERRSIG" -msgstr "ERRSIG" - -#: ../../rst/reference_appendices/config.rst:2257 -msgid "NO_PUBKEY" -msgstr "NO_PUBKEY" - -#: ../../rst/reference_appendices/config.rst:2258 -msgid "MISSING_PASSPHRASE" -msgstr "MISSING_PASSPHRASE" - -#: ../../rst/reference_appendices/config.rst:2259 -msgid "BAD_PASSPHRASE" -msgstr "BAD_PASSPHRASE" - -#: ../../rst/reference_appendices/config.rst:2260 -msgid "NODATA" -msgstr "NODATA" - -#: ../../rst/reference_appendices/config.rst:2261 -msgid "UNEXPECTED" -msgstr "UNEXPECTED" - -#: ../../rst/reference_appendices/config.rst:2262 -msgid "ERROR" -msgstr "ERROR" - -#: ../../rst/reference_appendices/config.rst:2263 -msgid "FAILURE" -msgstr "FAILURE" - -#: ../../rst/reference_appendices/config.rst:2264 -msgid "BADARMOR" -msgstr "BADARMOR" - -#: ../../rst/reference_appendices/config.rst:2265 -msgid "KEYEXPIRED" -msgstr "KEYEXPIRED" - -#: ../../rst/reference_appendices/config.rst:2266 -msgid "KEYREVOKED" -msgstr "KEYREVOKED" - -#: ../../rst/reference_appendices/config.rst:2267 -msgid "NO_SECKEY" -msgstr "NO_SECKEY" - -#: ../../rst/reference_appendices/config.rst:2270 -msgid "ignore_signature_status_codes" -msgstr "ignore_signature_status_codes" - -#: ../../rst/reference_appendices/config.rst:2272 -msgid ":envvar:`ANSIBLE_GALAXY_IGNORE_SIGNATURE_STATUS_CODES`" -msgstr ":envvar:`ANSIBLE_GALAXY_IGNORE_SIGNATURE_STATUS_CODES`" - -#: ../../rst/reference_appendices/config.rst:2277 -msgid "GALAXY_REQUIRED_VALID_SIGNATURE_COUNT" -msgstr "GALAXY_REQUIRED_VALID_SIGNATURE_COUNT" - -#: ../../rst/reference_appendices/config.rst:2279 -msgid "The number of signatures that must be successful during GPG signature verification while installing or verifying collections. This should be a positive integer or all to indicate all signatures must successfully validate the collection. Prepend + to the value to fail if no valid signatures are found for the collection." -msgstr "コレクションのインストールまたは検証中の GPG 署名検証中に成功する必要がある署名の数。これは、正の整数または all の場合、すべての署名がコレクションの検証に成功する必要があることを指定します。有効な署名がコレクションで見つからなかった場合に失敗させるには、+ を値の前につけます。" - -#: ../../rst/reference_appendices/config.rst:2281 -msgid "``1``" -msgstr "``1``" - -#: ../../rst/reference_appendices/config.rst:2284 -msgid "required_valid_signature_count" -msgstr "required_valid_signature_count" - -#: ../../rst/reference_appendices/config.rst:2286 -msgid ":envvar:`ANSIBLE_GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`" -msgstr ":envvar:`ANSIBLE_GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`" - -#: ../../rst/reference_appendices/config.rst:2291 -msgid "GALAXY_ROLE_SKELETON" -msgstr "GALAXY_ROLE_SKELETON" - -#: ../../rst/reference_appendices/config.rst:2293 -#: ../../rst/reference_appendices/config.rst:4199 -msgid "Role skeleton directory to use as a template for the ``init`` action in ``ansible-galaxy``/``ansible-galaxy role``, same as ``--role-skeleton``." -msgstr "``ansible-galaxy``/``ansible-galaxy role`` の ``init`` アクションのテンプレートとして使用するロールのスケルトンディレクトリー。``--role-skeleton`` と同じです。" - -#: ../../rst/reference_appendices/config.rst:2297 -msgid "role_skeleton" -msgstr "role_skeleton" - -#: ../../rst/reference_appendices/config.rst:2299 -msgid ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON`" -msgstr ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON`" - -#: ../../rst/reference_appendices/config.rst:2304 -msgid "GALAXY_ROLE_SKELETON_IGNORE" -msgstr "GALAXY_ROLE_SKELETON_IGNORE" - -#: ../../rst/reference_appendices/config.rst:2306 -#: ../../rst/reference_appendices/config.rst:4207 -msgid "patterns of files to ignore inside a Galaxy role or collection skeleton directory" -msgstr "Galaxy ロールまたはコレクションスケルトンディレクトリー内で無視するファイルのパターン。" - -#: ../../rst/reference_appendices/config.rst:2311 -msgid "role_skeleton_ignore" -msgstr "role_skeleton_ignore" - -#: ../../rst/reference_appendices/config.rst:2313 -msgid ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON_IGNORE`" -msgstr ":envvar:`ANSIBLE_GALAXY_ROLE_SKELETON_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2318 -msgid "GALAXY_SERVER" -msgstr "GALAXY_SERVER" - -#: ../../rst/reference_appendices/config.rst:2320 -#: ../../rst/reference_appendices/config.rst:4231 -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:2321 -msgid "``https://galaxy.ansible.com``" -msgstr "``https://galaxy.ansible.com``" - -#: ../../rst/reference_appendices/config.rst:2324 -msgid "server" -msgstr "server" - -#: ../../rst/reference_appendices/config.rst:2326 -msgid ":envvar:`ANSIBLE_GALAXY_SERVER`" -msgstr ":envvar:`ANSIBLE_GALAXY_SERVER`" - -#: ../../rst/reference_appendices/config.rst:2331 -msgid "GALAXY_SERVER_LIST" -msgstr "GALAXY_SERVER_LIST" - -#: ../../rst/reference_appendices/config.rst:2333 -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." -msgstr "コレクションのインストール時に使用する Galaxy サーバーの一覧。値は、サーバーの詳細を定義する config ini ヘッダー ``[galaxy_server.{{item}}]`` に対応します。Galaxy サーバーの定義方法の詳細は、「:ref:`galaxy_server_config`」を参照してください。この一覧のサーバーの順序は、コレクションの解決順序として使用されます。この設定オプションを設定すると、:ref:`galaxy_server` の設定オプションは無視されます。" - -#: ../../rst/reference_appendices/config.rst:2338 -msgid "server_list" -msgstr "server_list" - -#: ../../rst/reference_appendices/config.rst:2340 -msgid ":envvar:`ANSIBLE_GALAXY_SERVER_LIST`" -msgstr ":envvar:`ANSIBLE_GALAXY_SERVER_LIST`" - -#: ../../rst/reference_appendices/config.rst:2345 -msgid "GALAXY_TOKEN_PATH" -msgstr "GALAXY_TOKEN_PATH" - -#: ../../rst/reference_appendices/config.rst:2347 -#: ../../rst/reference_appendices/config.rst:4247 -msgid "Local path to galaxy access token file" -msgstr "galaxy アクセストークンファイルへのローカルパス。" - -#: ../../rst/reference_appendices/config.rst:2349 -msgid "``{{ ANSIBLE_HOME ~ \"/galaxy_token\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/galaxy_token\" }}``" - -#: ../../rst/reference_appendices/config.rst:2353 -msgid "token_path" -msgstr "token_path" - -#: ../../rst/reference_appendices/config.rst:2355 -msgid ":envvar:`ANSIBLE_GALAXY_TOKEN_PATH`" -msgstr ":envvar:`ANSIBLE_GALAXY_TOKEN_PATH`" - -#: ../../rst/reference_appendices/config.rst:2360 -msgid "HOST_KEY_CHECKING" -msgstr "HOST_KEY_CHECKING" - -#: ../../rst/reference_appendices/config.rst:2362 -#: ../../rst/reference_appendices/config.rst:4303 -msgid "Set this to \"False\" if you want to avoid host key checking by the underlying tools Ansible uses to connect to the host" -msgstr "Ansible がホストへの接続に使用する基盤のツールでホストキーの確認を行わないようにするには、このパラメーターを「False」に設定します。" - -#: ../../rst/reference_appendices/config.rst:2367 -msgid "host_key_checking" -msgstr "host_key_checking" - -#: ../../rst/reference_appendices/config.rst:2369 -msgid ":envvar:`ANSIBLE_HOST_KEY_CHECKING`" -msgstr ":envvar:`ANSIBLE_HOST_KEY_CHECKING`" - -#: ../../rst/reference_appendices/config.rst:2374 -msgid "HOST_PATTERN_MISMATCH" -msgstr "HOST_PATTERN_MISMATCH" - -#: ../../rst/reference_appendices/config.rst:2376 -#: ../../rst/reference_appendices/config.rst:4311 -msgid "This setting changes the behaviour of mismatched host patterns, it allows you to force a fatal error, a warning or just ignore it" -msgstr "この設定により、一致しないホストパターンの動作が変更されます。これにより、致命的なエラーや警告を強制したり、無視することが可能になります。" - -#: ../../rst/reference_appendices/config.rst:2384 -#: ../../rst/reference_appendices/config.rst:2457 -#: ../../rst/reference_appendices/config.rst:2471 -#: ../../rst/reference_appendices/config.rst:2483 -#: ../../rst/reference_appendices/config.rst:2495 -#: ../../rst/reference_appendices/config.rst:2508 -#: ../../rst/reference_appendices/config.rst:2521 -#: ../../rst/reference_appendices/config.rst:2535 -#: ../../rst/reference_appendices/config.rst:2549 -#: ../../rst/reference_appendices/config.rst:2565 -#: ../../rst/reference_appendices/config.rst:2581 -#: ../../rst/reference_appendices/config.rst:2596 -#: ../../rst/reference_appendices/config.rst:2611 -msgid "[inventory]" -msgstr "[inventory]" - -#: ../../rst/reference_appendices/config.rst:2385 -msgid "host_pattern_mismatch" -msgstr "host_pattern_mismatch" - -#: ../../rst/reference_appendices/config.rst:2387 -msgid ":envvar:`ANSIBLE_HOST_PATTERN_MISMATCH`" -msgstr ":envvar:`ANSIBLE_HOST_PATTERN_MISMATCH`" - -#: ../../rst/reference_appendices/config.rst:2392 -msgid "INJECT_FACTS_AS_VARS" -msgstr "INJECT_FACTS_AS_VARS" - -#: ../../rst/reference_appendices/config.rst:2394 -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." -msgstr "ファクトは `ansible_facts` 変数内で利用できます。この設定は、主な名前空間で独自の変数としてプッシュされます。`ansible_facts` ディクショナリー内とは異なり、これは `ansible_` の接頭辞があります。" - -#: ../../rst/reference_appendices/config.rst:2400 -msgid "inject_facts_as_vars" -msgstr "inject_facts_as_vars" - -#: ../../rst/reference_appendices/config.rst:2402 -msgid ":envvar:`ANSIBLE_INJECT_FACT_VARS`" -msgstr ":envvar:`ANSIBLE_INJECT_FACT_VARS`" - -#: ../../rst/reference_appendices/config.rst:2407 -msgid "INTERPRETER_PYTHON" -msgstr "INTERPRETER_PYTHON" - -#: ../../rst/reference_appendices/config.rst:2409 -#: ../../rst/reference_appendices/config.rst:4319 -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`` (the default), ``auto_silent``, ``auto_legacy``, and ``auto_legacy_silent``. 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`` or ``auto_legacy_silent``. The 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." -msgstr "リモートターゲットまたは自動検出モードでのモジュール実行に使用される Python インタープリターへのパス。サポートされている検出モードは、``auto`` (デフォルト)、``auto_silent``、``auto_legacy``、および ``auto_legacy_silent`` です。すべての検出モードは、含まれているシステムの Python (含むことがディストリビューションで) を使用するためにルックアップテーブルを使用し、プラットフォーム固有のデフォルトが使用できない場合は、よく知られた Python インタープリターの位置の固定された順序リストにフォールバックします。フォールバック動作では、インタープリターを明示的に設定する必要があるという警告が出力されます (後からインストールされたインタープリターが、使用するインタープリターを変更する可能性があるからです)。この警告動作を無効にするには、``auto_silent`` または ``auto_legacy_silent`` を設定します。 ``auto_legacy`` の値はすべて同じ動作を指定しますが、以前の Ansible リリースとの下位互換性を確保するために常にデフォルトで ``/usr/bin/python`` に設定されていた場合には、インタープリターがあれば、それを使用します。" - -#: ../../rst/reference_appendices/config.rst:2410 -msgid "``auto``" -msgstr "``auto``" - -#: ../../rst/reference_appendices/config.rst:2414 -msgid "interpreter_python" -msgstr "interpreter_python" - -#: ../../rst/reference_appendices/config.rst:2416 -msgid ":envvar:`ANSIBLE_PYTHON_INTERPRETER`" -msgstr ":envvar:`ANSIBLE_PYTHON_INTERPRETER`" - -#: ../../rst/reference_appendices/config.rst:2418 -msgid "`ansible_python_interpreter`" -msgstr "`ansible_python_interpreter`" - -#: ../../rst/reference_appendices/config.rst:2423 -msgid "INTERPRETER_PYTHON_FALLBACK" -msgstr "INTERPRETER_PYTHON_FALLBACK" - -#: ../../rst/reference_appendices/config.rst:2426 -msgid "``['python3.11', 'python3.10', 'python3.9', 'python3.8', 'python3.7', 'python3.6', 'python3.5', '/usr/bin/python3', '/usr/libexec/platform-python', 'python2.7', '/usr/bin/python', 'python']``" -msgstr "``['python3.11', 'python3.10', 'python3.9', 'python3.8', 'python3.7', 'python3.6', 'python3.5', '/usr/bin/python3', '/usr/libexec/platform-python', 'python2.7', '/usr/bin/python', 'python']``" - -#: ../../rst/reference_appendices/config.rst:2429 -msgid "`ansible_interpreter_python_fallback`" -msgstr "`ansible_interpreter_python_fallback`" - -#: ../../rst/reference_appendices/config.rst:2434 -msgid "INVALID_TASK_ATTRIBUTE_FAILED" -msgstr "INVALID_TASK_ATTRIBUTE_FAILED" - -#: ../../rst/reference_appendices/config.rst:2436 -#: ../../rst/reference_appendices/config.rst:4336 -msgid "If 'false', invalid attributes for a task will result in warnings instead of errors" -msgstr "「false」の場合は、タスクの無効な属性により、エラーではなく警告が発生します。" - -#: ../../rst/reference_appendices/config.rst:2442 -msgid "invalid_task_attribute_failed" -msgstr "invalid_task_attribute_failed" - -#: ../../rst/reference_appendices/config.rst:2444 -msgid ":envvar:`ANSIBLE_INVALID_TASK_ATTRIBUTE_FAILED`" -msgstr ":envvar:`ANSIBLE_INVALID_TASK_ATTRIBUTE_FAILED`" - -#: ../../rst/reference_appendices/config.rst:2449 -msgid "INVENTORY_ANY_UNPARSED_IS_FAILED" -msgstr "INVENTORY_ANY_UNPARSED_IS_FAILED" - -#: ../../rst/reference_appendices/config.rst:2451 -#: ../../rst/reference_appendices/config.rst:4344 -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." -msgstr "「true」の場合は、指定のインベントリーソースを利用可能な inventory プラグインで正常に解析できない場合に致命的なエラーになります。そうでないと、この状況は警告を招くだけとなります。" - -#: ../../rst/reference_appendices/config.rst:2458 -msgid "any_unparsed_is_failed" -msgstr "any_unparsed_is_failed" - -#: ../../rst/reference_appendices/config.rst:2460 -msgid ":envvar:`ANSIBLE_INVENTORY_ANY_UNPARSED_IS_FAILED`" -msgstr ":envvar:`ANSIBLE_INVENTORY_ANY_UNPARSED_IS_FAILED`" - -#: ../../rst/reference_appendices/config.rst:2465 -msgid "INVENTORY_CACHE_ENABLED" -msgstr "INVENTORY_CACHE_ENABLED" - -#: ../../rst/reference_appendices/config.rst:2467 -msgid "Toggle to turn on inventory caching. This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`. The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory configuration. This message will be removed in 2.16." -msgstr "切り替えてイベントリーキャッシュをオンにします。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリー設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:2472 -msgid "cache" -msgstr "cache" - -#: ../../rst/reference_appendices/config.rst:2474 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE`" - -#: ../../rst/reference_appendices/config.rst:2479 -msgid "INVENTORY_CACHE_PLUGIN" -msgstr "INVENTORY_CACHE_PLUGIN" - -#: ../../rst/reference_appendices/config.rst:2481 -msgid "The plugin for caching inventory. This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`. The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16." -msgstr "キャッシュインベントリーのプラグイン。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:2484 -msgid "cache_plugin" -msgstr "cache_plugin" - -#: ../../rst/reference_appendices/config.rst:2486 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN`" - -#: ../../rst/reference_appendices/config.rst:2491 -msgid "INVENTORY_CACHE_PLUGIN_CONNECTION" -msgstr "INVENTORY_CACHE_PLUGIN_CONNECTION" - -#: ../../rst/reference_appendices/config.rst:2493 -msgid "The inventory cache connection. This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`. The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16." -msgstr "インベントリーキャッシュコネクション。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:2496 -msgid "cache_connection" -msgstr "cache_connection" - -#: ../../rst/reference_appendices/config.rst:2498 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_CONNECTION`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_CONNECTION`" - -#: ../../rst/reference_appendices/config.rst:2503 -msgid "INVENTORY_CACHE_PLUGIN_PREFIX" -msgstr "INVENTORY_CACHE_PLUGIN_PREFIX" - -#: ../../rst/reference_appendices/config.rst:2505 -msgid "The table prefix for the cache plugin. This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`. The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16." -msgstr "キャッシュプラグインの表の接頭辞。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:2506 -msgid "``ansible_inventory_``" -msgstr "``ansible_inventory_``" - -#: ../../rst/reference_appendices/config.rst:2509 -msgid "cache_prefix" -msgstr "cache_prefix" - -#: ../../rst/reference_appendices/config.rst:2511 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN_PREFIX`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_PLUGIN_PREFIX`" - -#: ../../rst/reference_appendices/config.rst:2516 -msgid "INVENTORY_CACHE_TIMEOUT" -msgstr "INVENTORY_CACHE_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2518 -msgid "Expiration timeout for the inventory cache plugin data. This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`. The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16." -msgstr "インベントリーキャッシュプラグインデータの有効期限のタイムアウト。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:2519 -msgid "``3600``" -msgstr "``3600``" - -#: ../../rst/reference_appendices/config.rst:2522 -msgid "cache_timeout" -msgstr "cache_timeout" - -#: ../../rst/reference_appendices/config.rst:2524 -msgid ":envvar:`ANSIBLE_INVENTORY_CACHE_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_INVENTORY_CACHE_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2529 -msgid "INVENTORY_ENABLED" -msgstr "INVENTORY_ENABLED" - -#: ../../rst/reference_appendices/config.rst:2531 -#: ../../rst/reference_appendices/config.rst:4393 -msgid "List of enabled inventory plugins, it also determines the order in which they are used." -msgstr "有効な inventory プラグインのリスト。また、使用する順序も決定します。" - -#: ../../rst/reference_appendices/config.rst:2533 -msgid "``['host_list', 'script', 'auto', 'yaml', 'ini', 'toml']``" -msgstr "``['host_list', 'script', 'auto', 'yaml', 'ini', 'toml']``" - -#: ../../rst/reference_appendices/config.rst:2536 -msgid "enable_plugins" -msgstr "enable_plugins" - -#: ../../rst/reference_appendices/config.rst:2538 -msgid ":envvar:`ANSIBLE_INVENTORY_ENABLED`" -msgstr ":envvar:`ANSIBLE_INVENTORY_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:2543 -msgid "INVENTORY_EXPORT" -msgstr "INVENTORY_EXPORT" - -#: ../../rst/reference_appendices/config.rst:2545 -#: ../../rst/reference_appendices/config.rst:4401 -msgid "Controls if ansible-inventory will accurately reflect Ansible's view into inventory or its optimized for exporting." -msgstr "ansible-inventory が Ansible のビューをインベントリーに正確に反映させるか、またはエクスポートに最適化するかを制御します。" - -#: ../../rst/reference_appendices/config.rst:2550 -msgid "export" -msgstr "export" - -#: ../../rst/reference_appendices/config.rst:2552 -msgid ":envvar:`ANSIBLE_INVENTORY_EXPORT`" -msgstr ":envvar:`ANSIBLE_INVENTORY_EXPORT`" - -#: ../../rst/reference_appendices/config.rst:2557 -msgid "INVENTORY_IGNORE_EXTS" -msgstr "INVENTORY_IGNORE_EXTS" - -#: ../../rst/reference_appendices/config.rst:2559 -#: ../../rst/reference_appendices/config.rst:4409 -msgid "List of extensions to ignore when using a directory as an inventory source" -msgstr "ディレクトリーをインベントリーソースとして使用する際に無視する拡張機能の一覧。" - -#: ../../rst/reference_appendices/config.rst:2561 -msgid "``{{(REJECT_EXTS + ('.orig', '.ini', '.cfg', '.retry'))}}``" -msgstr "``{{(REJECT_EXTS + ('.orig', '.ini', '.cfg', '.retry'))}}``" - -#: ../../rst/reference_appendices/config.rst:2564 -msgid "inventory_ignore_extensions" -msgstr "inventory_ignore_extensions" - -#: ../../rst/reference_appendices/config.rst:2566 -msgid "ignore_extensions" -msgstr "ignore_extensions" - -#: ../../rst/reference_appendices/config.rst:2568 -msgid ":envvar:`ANSIBLE_INVENTORY_IGNORE`" -msgstr ":envvar:`ANSIBLE_INVENTORY_IGNORE`" - -#: ../../rst/reference_appendices/config.rst:2573 -msgid "INVENTORY_IGNORE_PATTERNS" -msgstr "INVENTORY_IGNORE_PATTERNS" - -#: ../../rst/reference_appendices/config.rst:2575 -#: ../../rst/reference_appendices/config.rst:4417 -msgid "List of patterns to ignore when using a directory as an inventory source" -msgstr "ディレクトリーをインベントリーソースとして使用する場合に無視するパターンの一覧。" - -#: ../../rst/reference_appendices/config.rst:2580 -msgid "inventory_ignore_patterns" -msgstr "inventory_ignore_patterns" - -#: ../../rst/reference_appendices/config.rst:2582 -msgid "ignore_patterns" -msgstr "ignore_patterns" - -#: ../../rst/reference_appendices/config.rst:2584 -msgid ":envvar:`ANSIBLE_INVENTORY_IGNORE_REGEX`" -msgstr ":envvar:`ANSIBLE_INVENTORY_IGNORE_REGEX`" - -#: ../../rst/reference_appendices/config.rst:2589 -msgid "INVENTORY_UNPARSED_IS_FAILED" -msgstr "INVENTORY_UNPARSED_IS_FAILED" - -#: ../../rst/reference_appendices/config.rst:2591 -#: ../../rst/reference_appendices/config.rst:4425 -msgid "If 'true' it is a fatal error if every single potential inventory source fails to parse, otherwise this situation will only attract a warning." -msgstr "「true」にすると、すべての潜在的なインベントリーソースが解析に失敗した場合に致命的なエラーとなります。そうしないと、この状況は警告を招くだけです。" - -#: ../../rst/reference_appendices/config.rst:2597 -msgid "unparsed_is_failed" -msgstr "unparsed_is_failed" - -#: ../../rst/reference_appendices/config.rst:2599 -msgid ":envvar:`ANSIBLE_INVENTORY_UNPARSED_FAILED`" -msgstr ":envvar:`ANSIBLE_INVENTORY_UNPARSED_FAILED`" - -#: ../../rst/reference_appendices/config.rst:2604 -msgid "INVENTORY_UNPARSED_WARNING" -msgstr "INVENTORY_UNPARSED_WARNING" - -#: ../../rst/reference_appendices/config.rst:2606 -msgid "By default Ansible will issue a warning when no inventory was loaded and notes that it will use an implicit localhost-only inventory. These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible は、インベントリーがロードされていない場合に警告を発行し、暗黙的なローカルホストのみのインベントリーを使用することを通知します。これらの警告の通知は、この設定を False に調整して、オフにできます。" - -#: ../../rst/reference_appendices/config.rst:2612 -msgid "inventory_unparsed_warning" -msgstr "inventory_unparsed_warning" - -#: ../../rst/reference_appendices/config.rst:2614 -msgid ":envvar:`ANSIBLE_INVENTORY_UNPARSED_WARNING`" -msgstr ":envvar:`ANSIBLE_INVENTORY_UNPARSED_WARNING`" - -#: ../../rst/reference_appendices/config.rst:2619 -msgid "JINJA2_NATIVE_WARNING" -msgstr "JINJA2_NATIVE_WARNING" - -#: ../../rst/reference_appendices/config.rst:2621 -#: ../../rst/reference_appendices/config.rst:4434 -msgid "Toggle to control showing warnings related to running a Jinja version older than required for jinja2_native" -msgstr "jinja2_native に必要なバージョンよりも古い Jinja の実行に関連する警告の表示を制御するように切り替えます。" - -#: ../../rst/reference_appendices/config.rst:2626 -msgid "jinja2_native_warning" -msgstr "jinja2_native_warning" - -#: ../../rst/reference_appendices/config.rst:2628 -msgid ":envvar:`ANSIBLE_JINJA2_NATIVE_WARNING` :Deprecated in: 2.17 :Deprecated detail: This option is no longer used in the Ansible Core code base." -msgstr "`ANSIBLE_JINJA2_NATIVE_WARNING`: 非推奨:2.17。 :非推奨の詳細: このオプションは、Ansible Core コードベースでは使用されなくなりました。" - -#: ../../rst/reference_appendices/config.rst:2635 -msgid "LOCALHOST_WARNING" -msgstr "LOCALHOST_WARNING" - -#: ../../rst/reference_appendices/config.rst:2637 -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." -msgstr "デフォルトでは、Ansible は、インベントリーにホストがない場合に警告を表示します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:2640 -msgid "2.6" -msgstr "2.6" - -#: ../../rst/reference_appendices/config.rst:2643 -msgid "localhost_warning" -msgstr "localhost_warning" - -#: ../../rst/reference_appendices/config.rst:2645 -msgid ":envvar:`ANSIBLE_LOCALHOST_WARNING`" -msgstr ":envvar:`ANSIBLE_LOCALHOST_WARNING`" - -#: ../../rst/reference_appendices/config.rst:2650 -msgid "MAX_FILE_SIZE_FOR_DIFF" -msgstr "MAX_FILE_SIZE_FOR_DIFF" - -#: ../../rst/reference_appendices/config.rst:2652 -#: ../../rst/reference_appendices/config.rst:4444 -msgid "Maximum size of files to be considered for diff display" -msgstr "diff 表示に考慮されるファイルの最大サイズ。" - -#: ../../rst/reference_appendices/config.rst:2653 -#: ../../rst/reference_appendices/config.rst:2748 -msgid "int" -msgstr "int" - -#: ../../rst/reference_appendices/config.rst:2654 -msgid "``104448``" -msgstr "``104448``" - -#: ../../rst/reference_appendices/config.rst:2657 -msgid "max_diff_size" -msgstr "max_diff_size" - -#: ../../rst/reference_appendices/config.rst:2659 -msgid ":envvar:`ANSIBLE_MAX_DIFF_SIZE`" -msgstr ":envvar:`ANSIBLE_MAX_DIFF_SIZE`" - -#: ../../rst/reference_appendices/config.rst:2664 -msgid "MODULE_IGNORE_EXTS" -msgstr "MODULE_IGNORE_EXTS" - -#: ../../rst/reference_appendices/config.rst:2666 -msgid "List of extensions to ignore when looking for modules to load This is for rejecting script and binary module fallback extensions" -msgstr "読み込むモジュールを探すときに無視する拡張機能のリスト。これは、スクリプトおよびバイナリーモジュールのフォールバック拡張機能を拒否するためのものです。" - -#: ../../rst/reference_appendices/config.rst:2668 -msgid "``{{(REJECT_EXTS + ('.yaml', '.yml', '.ini'))}}``" -msgstr "``{{(REJECT_EXTS + ('.yaml', '.yml', '.ini'))}}``" - -#: ../../rst/reference_appendices/config.rst:2671 -msgid "module_ignore_exts" -msgstr "module_ignore_exts" - -#: ../../rst/reference_appendices/config.rst:2673 -msgid ":envvar:`ANSIBLE_MODULE_IGNORE_EXTS`" -msgstr ":envvar:`ANSIBLE_MODULE_IGNORE_EXTS`" - -#: ../../rst/reference_appendices/config.rst:2678 -msgid "NETCONF_SSH_CONFIG" -msgstr "NETCONF_SSH_CONFIG" - -#: ../../rst/reference_appendices/config.rst:2680 -#: ../../rst/reference_appendices/config.rst:4682 -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." -msgstr "この変数は、netconf 接続で bastion/ジャンプホストを有効にするために使用されます。True に設定すると、bastion/ジャンプホストの ssh 設定が ~/.ssh/config ファイルに存在する必要があります。または、カスタムの ssh 設定ファイルパスに設定して、bastion/ジャンプホストの設定を読み取ることもできます。" - -#: ../../rst/reference_appendices/config.rst:2683 -msgid "[netconf_connection]" -msgstr "[netconf_connection]" - -#: ../../rst/reference_appendices/config.rst:2684 -msgid "ssh_config" -msgstr "ssh_config" - -#: ../../rst/reference_appendices/config.rst:2686 -msgid ":envvar:`ANSIBLE_NETCONF_SSH_CONFIG`" -msgstr ":envvar:`ANSIBLE_NETCONF_SSH_CONFIG`" - -#: ../../rst/reference_appendices/config.rst:2691 -msgid "NETWORK_GROUP_MODULES" -msgstr "NETWORK_GROUP_MODULES" - -#: ../../rst/reference_appendices/config.rst:2694 -msgid "``['eos', 'nxos', 'ios', 'iosxr', 'junos', 'enos', 'ce', 'vyos', 'sros', 'dellos9', 'dellos10', 'dellos6', 'asa', 'aruba', 'aireos', 'bigip', 'ironware', 'onyx', 'netconf', 'exos', 'voss', 'slxos']``" -msgstr "``['eos', 'nxos', 'ios', 'iosxr', 'junos', 'enos', 'ce', 'vyos', 'sros', 'dellos9', 'dellos10', 'dellos6', 'asa', 'aruba', 'aireos', 'bigip', 'ironware', 'onyx', 'netconf', 'exos', 'voss', 'slxos']``" - -#: ../../rst/reference_appendices/config.rst:2697 -msgid "network_group_modules" -msgstr "network_group_modules" - -#: ../../rst/reference_appendices/config.rst:2699 -msgid ":envvar:`ANSIBLE_NETWORK_GROUP_MODULES`" -msgstr ":envvar:`ANSIBLE_NETWORK_GROUP_MODULES`" - -#: ../../rst/reference_appendices/config.rst:2704 -msgid "OLD_PLUGIN_CACHE_CLEARING" -msgstr "OLD_PLUGIN_CACHE_CLEARING" - -#: ../../rst/reference_appendices/config.rst:2706 -#: ../../rst/reference_appendices/config.rst:4475 -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 prevoius plays would be unexpectedly 'sticky'. This setting allows to return to that behaviour." -msgstr "以前の Ansible は、新しいロールを読み込むときにプラグインの読み込みキャッシュの一部のみを削除していました。これにより、以前のプレイで読み込まれたプラグインが予期せず「スティッキー」になる動作が発生しました。この設定により、その動作に戻ることができます。" - -#: ../../rst/reference_appendices/config.rst:2712 -msgid "old_plugin_cache_clear" -msgstr "old_plugin_cache_clear" - -#: ../../rst/reference_appendices/config.rst:2714 -msgid ":envvar:`ANSIBLE_OLD_PLUGIN_CACHE_CLEAR`" -msgstr ":envvar:`ANSIBLE_OLD_PLUGIN_CACHE_CLEAR`" - -#: ../../rst/reference_appendices/config.rst:2719 -msgid "PARAMIKO_HOST_KEY_AUTO_ADD" -msgstr "PARAMIKO_HOST_KEY_AUTO_ADD" - -#: ../../rst/reference_appendices/config.rst:2724 -#: ../../rst/reference_appendices/config.rst:2737 -msgid "[paramiko_connection]" -msgstr "[paramiko_connection]" - -#: ../../rst/reference_appendices/config.rst:2725 -msgid "host_key_auto_add" -msgstr "host_key_auto_add" - -#: ../../rst/reference_appendices/config.rst:2727 -msgid ":envvar:`ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD`" -msgstr ":envvar:`ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD`" - -#: ../../rst/reference_appendices/config.rst:2732 -msgid "PARAMIKO_LOOK_FOR_KEYS" -msgstr "PARAMIKO_LOOK_FOR_KEYS" - -#: ../../rst/reference_appendices/config.rst:2738 -msgid "look_for_keys" -msgstr "look_for_keys" - -#: ../../rst/reference_appendices/config.rst:2740 -msgid ":envvar:`ANSIBLE_PARAMIKO_LOOK_FOR_KEYS`" -msgstr ":envvar:`ANSIBLE_PARAMIKO_LOOK_FOR_KEYS`" - -#: ../../rst/reference_appendices/config.rst:2745 -msgid "PERSISTENT_COMMAND_TIMEOUT" -msgstr "PERSISTENT_COMMAND_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2747 -#: ../../rst/reference_appendices/config.rst:4521 -msgid "This controls the amount of time to wait for response from remote device before timing out persistent connection." -msgstr "これは、永続的な接続をタイムアウトする前に、リモートデバイスからの応答を待つ時間を制御します。" - -#: ../../rst/reference_appendices/config.rst:2749 -#: ../../rst/reference_appendices/config.rst:2777 -msgid "``30``" -msgstr "``30``" - -#: ../../rst/reference_appendices/config.rst:2752 -msgid "command_timeout" -msgstr "command_timeout" - -#: ../../rst/reference_appendices/config.rst:2754 -msgid ":envvar:`ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2759 -msgid "PERSISTENT_CONNECT_RETRY_TIMEOUT" -msgstr "PERSISTENT_CONNECT_RETRY_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2761 -#: ../../rst/reference_appendices/config.rst:4513 -msgid "This controls the retry timeout for persistent connection to connect to the local domain socket." -msgstr "これにより、ローカルドメインソケットに接続する永続接続の再試行タイムアウトを制御します。" - -#: ../../rst/reference_appendices/config.rst:2766 -msgid "connect_retry_timeout" -msgstr "connect_retry_timeout" - -#: ../../rst/reference_appendices/config.rst:2768 -msgid ":envvar:`ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2773 -msgid "PERSISTENT_CONNECT_TIMEOUT" -msgstr "PERSISTENT_CONNECT_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:2775 -#: ../../rst/reference_appendices/config.rst:4505 -msgid "This controls how long the persistent connection will remain idle before it is destroyed." -msgstr "これは、アイドル状態になり、永続接続が破棄されるまでの期間を制御します。" - -#: ../../rst/reference_appendices/config.rst:2780 -msgid "connect_timeout" -msgstr "connect_timeout" - -#: ../../rst/reference_appendices/config.rst:2782 -msgid ":envvar:`ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:2787 -msgid "PERSISTENT_CONTROL_PATH_DIR" -msgstr "PERSISTENT_CONTROL_PATH_DIR" - -#: ../../rst/reference_appendices/config.rst:2789 -#: ../../rst/reference_appendices/config.rst:4497 -msgid "Path to socket to be used by the connection persistence system." -msgstr "接続永続システムによって使用されるソケットへのパス。" - -#: ../../rst/reference_appendices/config.rst:2791 -msgid "``{{ ANSIBLE_HOME ~ \"/pc\" }}``" -msgstr "``{{ ANSIBLE_HOME ~ \"/pc\" }}``" - -#: ../../rst/reference_appendices/config.rst:2794 -msgid "control_path_dir" -msgstr "control_path_dir" - -#: ../../rst/reference_appendices/config.rst:2796 -msgid ":envvar:`ANSIBLE_PERSISTENT_CONTROL_PATH_DIR`" -msgstr ":envvar:`ANSIBLE_PERSISTENT_CONTROL_PATH_DIR`" - -#: ../../rst/reference_appendices/config.rst:2801 -msgid "PLAYBOOK_DIR" -msgstr "PLAYBOOK_DIR" - -#: ../../rst/reference_appendices/config.rst:2803 -#: ../../rst/reference_appendices/config.rst:4529 -msgid "A number of non-playbook CLIs have a ``--playbook-dir`` argument; this sets the default value for it." -msgstr "Playbook 以外の CLI の多くに ``--playbook-dir`` 引数があり、これによりデフォルト値が設定されます。" - -#: ../../rst/reference_appendices/config.rst:2808 -#: ../../rst/reference_appendices/special_variables.rst:122 -msgid "playbook_dir" -msgstr "playbook_dir" - -#: ../../rst/reference_appendices/config.rst:2810 -msgid ":envvar:`ANSIBLE_PLAYBOOK_DIR`" -msgstr ":envvar:`ANSIBLE_PLAYBOOK_DIR`" - -#: ../../rst/reference_appendices/config.rst:2815 -msgid "PLAYBOOK_VARS_ROOT" -msgstr "PLAYBOOK_VARS_ROOT" - -#: ../../rst/reference_appendices/config.rst:2817 -#: ../../rst/reference_appendices/config.rst:4537 -msgid "This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_vars" -msgstr "これにより、どの Playbookdir が vars プラグインを処理するためのルートとして使用されるかが設定されます。これには、host_vars/group_vars の検索が含まれます。" - -#: ../../rst/reference_appendices/config.rst:2818 -msgid "``top``" -msgstr "``top``" - -#: ../../rst/reference_appendices/config.rst -msgid "top" -msgstr "top" - -#: ../../rst/reference_appendices/config.rst:2820 -msgid "follows the traditional behavior of using the top playbook in the chain to find the root directory." -msgstr "チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。" - -#: ../../rst/reference_appendices/config.rst -msgid "bottom" -msgstr "bottom" - -#: ../../rst/reference_appendices/config.rst:2821 -msgid "follows the 2.4.0 behavior of using the current playbook to find the root directory." -msgstr "現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。" - -#: ../../rst/reference_appendices/config.rst -msgid "all" -msgstr "all" - -#: ../../rst/reference_appendices/config.rst:2822 -msgid "examines from the first parent to the current playbook." -msgstr "最初の親から現在の Playbook までを調べます。" - -#: ../../rst/reference_appendices/config.rst:2823 -msgid "2.4.1" -msgstr "2.4.1" - -#: ../../rst/reference_appendices/config.rst:2826 -msgid "playbook_vars_root" -msgstr "playbook_vars_root" - -#: ../../rst/reference_appendices/config.rst:2828 -msgid ":envvar:`ANSIBLE_PLAYBOOK_VARS_ROOT`" -msgstr ":envvar:`ANSIBLE_PLAYBOOK_VARS_ROOT`" - -#: ../../rst/reference_appendices/config.rst:2833 -msgid "PLUGIN_FILTERS_CFG" -msgstr "PLUGIN_FILTERS_CFG" - -#: ../../rst/reference_appendices/config.rst:2835 -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" -msgstr "システムにインストールされているプラグインのうち、どのプラグインの使用を許可するかをフィルタリングするための設定のパスです。フィルターファイルの形式の詳細は、「:ref:`plugin_filtering_config`」を参照してください。デフォルトは /etc/ansible/plugin_filters.yml です。" - -#: ../../rst/reference_appendices/config.rst:2838 -msgid "2.5.0" -msgstr "2.5.0" - -#: ../../rst/reference_appendices/config.rst:2841 -msgid "plugin_filters_cfg" -msgstr "plugin_filters_cfg" - -#: ../../rst/reference_appendices/config.rst:2846 -msgid "PYTHON_MODULE_RLIMIT_NOFILE" -msgstr "PYTHON_MODULE_RLIMIT_NOFILE" - -#: ../../rst/reference_appendices/config.rst:2848 -#: ../../rst/reference_appendices/config.rst:4546 -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." -msgstr "Python モジュールの実行時に RLIMIT_NOFILE ソフト制限を指定された値に設定しようとします (Python2.x でのサブプロセスの使用を高速化できます。https://bugs.python.org/issue11284 を参照してください)。この値は、既存のハード制限によって制限されます。デフォルト値の 0 は、既存のシステム定義の制限を調整しようとはしません。" - -#: ../../rst/reference_appendices/config.rst:2853 -msgid "python_module_rlimit_nofile" -msgstr "python_module_rlimit_nofile" - -#: ../../rst/reference_appendices/config.rst:2855 -msgid ":envvar:`ANSIBLE_PYTHON_MODULE_RLIMIT_NOFILE`" -msgstr ":envvar:`ANSIBLE_PYTHON_MODULE_RLIMIT_NOFILE`" - -#: ../../rst/reference_appendices/config.rst:2857 -msgid "`ansible_python_module_rlimit_nofile`" -msgstr "`ansible_python_module_rlimit_nofile`" - -#: ../../rst/reference_appendices/config.rst:2862 -msgid "RETRY_FILES_ENABLED" -msgstr "RETRY_FILES_ENABLED" - -#: ../../rst/reference_appendices/config.rst:2864 -#: ../../rst/reference_appendices/config.rst:4554 -msgid "This controls whether a failed Ansible playbook should create a .retry file." -msgstr "これにより、失敗した Ansible Playbook が .retry ファイルを作成するかどうかを制御します。" - -#: ../../rst/reference_appendices/config.rst:2869 -msgid "retry_files_enabled" -msgstr "retry_files_enabled" - -#: ../../rst/reference_appendices/config.rst:2871 -msgid ":envvar:`ANSIBLE_RETRY_FILES_ENABLED`" -msgstr ":envvar:`ANSIBLE_RETRY_FILES_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:2876 -msgid "RETRY_FILES_SAVE_PATH" -msgstr "RETRY_FILES_SAVE_PATH" - -#: ../../rst/reference_appendices/config.rst:2878 -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." -msgstr "これにより、Playbook が失敗し、再試行ファイルが有効になっている場合に、Ansible が .retry ファイルを保存するパスが設定されます。このファイルは、実行するたびに、すべてのプレイで失敗したホストのリストで上書きされます。" - -#: ../../rst/reference_appendices/config.rst:2883 -msgid "retry_files_save_path" -msgstr "retry_files_save_path" - -#: ../../rst/reference_appendices/config.rst:2885 -msgid ":envvar:`ANSIBLE_RETRY_FILES_SAVE_PATH`" -msgstr ":envvar:`ANSIBLE_RETRY_FILES_SAVE_PATH`" - -#: ../../rst/reference_appendices/config.rst:2890 -msgid "RUN_VARS_PLUGINS" -msgstr "RUN_VARS_PLUGINS" - -#: ../../rst/reference_appendices/config.rst:2892 -#: ../../rst/reference_appendices/config.rst:4570 -msgid "This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection." -msgstr "この設定は、ユーザーのインベントリーサイズとプレイの選択内容に応じて vars_plugin の使用量を最適化するために使用できます。" - -#: ../../rst/reference_appendices/config.rst:2894 -msgid "``demand``" -msgstr "``demand``" - -#: ../../rst/reference_appendices/config.rst -msgid "demand" -msgstr "demand" - -#: ../../rst/reference_appendices/config.rst:2896 -msgid "will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks." -msgstr "変数がタスクによって要求されるときはいつでも、インベントリーソースに合わせて vars_plugins を実行します。" - -#: ../../rst/reference_appendices/config.rst -msgid "start" -msgstr "start" - -#: ../../rst/reference_appendices/config.rst:2897 -msgid "will run vars_plugins relative to inventory sources after importing that inventory source." -msgstr "インベントリーソースをインポートした後に、インベントリーソースに合わせて vars_plugins を実行します。" - -#: ../../rst/reference_appendices/config.rst:2901 -msgid "run_vars_plugins" -msgstr "run_vars_plugins" - -#: ../../rst/reference_appendices/config.rst:2903 -msgid ":envvar:`ANSIBLE_RUN_VARS_PLUGINS`" -msgstr ":envvar:`ANSIBLE_RUN_VARS_PLUGINS`" - -#: ../../rst/reference_appendices/config.rst:2908 -msgid "SHOW_CUSTOM_STATS" -msgstr "SHOW_CUSTOM_STATS" - -#: ../../rst/reference_appendices/config.rst:2910 -#: ../../rst/reference_appendices/config.rst:4578 -msgid "This adds the custom stats set via the set_stats plugin to the default output" -msgstr "これにより、set_stats プラグインを介してカスタム統計セットがデフォルトの出力に追加されます。" - -#: ../../rst/reference_appendices/config.rst:2915 -msgid "show_custom_stats" -msgstr "show_custom_stats" - -#: ../../rst/reference_appendices/config.rst:2917 -msgid ":envvar:`ANSIBLE_SHOW_CUSTOM_STATS`" -msgstr ":envvar:`ANSIBLE_SHOW_CUSTOM_STATS`" - -#: ../../rst/reference_appendices/config.rst:2922 -msgid "STRING_CONVERSION_ACTION" -msgstr "STRING_CONVERSION_ACTION" - -#: ../../rst/reference_appendices/config.rst:2924 -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." -msgstr "モジュールパラメーター値が文字列に変換されるときに実行するアクション (これは変数には影響しません)。文字列パラメーターの場合、「1.00」、「['a', 'b',]」、「yes」、「y」などの値は、完全に引用されていない限り、YAML パーサーにより変換されます。有効なオプションは、「error」、「warn」、および「ignore」です。2.8 以降、このオプションのデフォルトは「warn」ですが、2.12では「error」に変更されます。" - -#: ../../rst/reference_appendices/config.rst:2930 -msgid "string_conversion_action" -msgstr "string_conversion_action" - -#: ../../rst/reference_appendices/config.rst:2932 -msgid ":envvar:`ANSIBLE_STRING_CONVERSION_ACTION`" -msgstr ":envvar:`ANSIBLE_STRING_CONVERSION_ACTION`" - -#: ../../rst/reference_appendices/config.rst:2937 -msgid "STRING_TYPE_FILTERS" -msgstr "STRING_TYPE_FILTERS" - -#: ../../rst/reference_appendices/config.rst:2939 -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." -msgstr "このフィルターのリストは、変数をテンプレート化するときに「型変換」を回避します。たとえば、JSON 文字列のリストやディレクトリーへの変換を回避したい場合に便利です。" - -#: ../../rst/reference_appendices/config.rst:2941 -msgid "``['string', 'to_json', 'to_nice_json', 'to_yaml', 'to_nice_yaml', 'ppretty', 'json']``" -msgstr "``['string', 'to_json', 'to_nice_json', 'to_yaml', 'to_nice_yaml', 'ppretty', 'json']``" - -#: ../../rst/reference_appendices/config.rst:2943 -msgid "[jinja2]" -msgstr "[jinja2]" - -#: ../../rst/reference_appendices/config.rst:2944 -msgid "dont_type_filters" -msgstr "dont_type_filters" - -#: ../../rst/reference_appendices/config.rst:2946 -msgid ":envvar:`ANSIBLE_STRING_TYPE_FILTERS`" -msgstr ":envvar:`ANSIBLE_STRING_TYPE_FILTERS`" - -#: ../../rst/reference_appendices/config.rst:2951 -msgid "SYSTEM_WARNINGS" -msgstr "SYSTEM_WARNINGS" - -#: ../../rst/reference_appendices/config.rst:2953 -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." -msgstr "Ansible 自体を実行している (管理対象ホストではない) システムの潜在的な問題に関連する警告を無効にすることができます。これには、サードパーティーのパッケージに関する警告や、可能であれば解決する必要のあるその他の条件が含まれる場合があります。" - -#: ../../rst/reference_appendices/config.rst:2958 -msgid "system_warnings" -msgstr "system_warnings" - -#: ../../rst/reference_appendices/config.rst:2960 -msgid ":envvar:`ANSIBLE_SYSTEM_WARNINGS`" -msgstr ":envvar:`ANSIBLE_SYSTEM_WARNINGS`" - -#: ../../rst/reference_appendices/config.rst:2965 -msgid "TAGS_RUN" -msgstr "TAGS_RUN" - -#: ../../rst/reference_appendices/config.rst:2967 -#: ../../rst/reference_appendices/config.rst:4602 -msgid "default list of tags to run in your plays, Skip Tags has precedence." -msgstr "プレイで実行するタグのデフォルト一覧。Skip Tags が優先されます。" - -#: ../../rst/reference_appendices/config.rst:2972 -#: ../../rst/reference_appendices/config.rst:2987 -msgid "[tags]" -msgstr "[tags]" - -#: ../../rst/reference_appendices/config.rst:2973 -msgid "run" -msgstr "run" - -#: ../../rst/reference_appendices/config.rst:2975 -msgid ":envvar:`ANSIBLE_RUN_TAGS`" -msgstr ":envvar:`ANSIBLE_RUN_TAGS`" - -#: ../../rst/reference_appendices/config.rst:2980 -msgid "TAGS_SKIP" -msgstr "TAGS_SKIP" - -#: ../../rst/reference_appendices/config.rst:2982 -#: ../../rst/reference_appendices/config.rst:4610 -msgid "default list of tags to skip in your plays, has precedence over Run Tags" -msgstr "プレイでスキップするタグのデフォルト一覧は Run Tags よりも優先されます。" - -#: ../../rst/reference_appendices/config.rst:2990 -msgid ":envvar:`ANSIBLE_SKIP_TAGS`" -msgstr ":envvar:`ANSIBLE_SKIP_TAGS`" - -#: ../../rst/reference_appendices/config.rst:2995 -msgid "TASK_DEBUGGER_IGNORE_ERRORS" -msgstr "TASK_DEBUGGER_IGNORE_ERRORS" - -#: ../../rst/reference_appendices/config.rst:2997 -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." -msgstr "このオプションは、ignore_errors=True が指定されている場合に、失敗したタスクでタスクデバッガーが呼び出されるかどうかを定義します。True に設定すると、デバッガーが ignore_errors を許可するように指定し、False に設定すると ignore_errors が無効になります。" - -#: ../../rst/reference_appendices/config.rst:3003 -msgid "task_debugger_ignore_errors" -msgstr "task_debugger_ignore_errors" - -#: ../../rst/reference_appendices/config.rst:3005 -msgid ":envvar:`ANSIBLE_TASK_DEBUGGER_IGNORE_ERRORS`" -msgstr ":envvar:`ANSIBLE_TASK_DEBUGGER_IGNORE_ERRORS`" - -#: ../../rst/reference_appendices/config.rst:3010 -msgid "TASK_TIMEOUT" -msgstr "TASK_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:3012 -msgid "Set the maximum time (in seconds) that a task can run for. If set to 0 (the default) there is no timeout." -msgstr "タスクを実行できる最大時間 (秒単位) を設定します。0 (デフォルト) に設定するとタイムアウトはありません。" - -#: ../../rst/reference_appendices/config.rst:3018 -msgid "task_timeout" -msgstr "task_timeout" - -#: ../../rst/reference_appendices/config.rst:3020 -msgid ":envvar:`ANSIBLE_TASK_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_TASK_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:3025 -msgid "TRANSFORM_INVALID_GROUP_CHARS" -msgstr "TRANSFORM_INVALID_GROUP_CHARS" - -#: ../../rst/reference_appendices/config.rst:3027 -#: ../../rst/reference_appendices/config.rst:4328 -msgid "Make ansible transform invalid characters in group names supplied by inventory sources." -msgstr "Ansible を使用してインベントリーソースが提供したグループ名で無効な文字を変換させます。" - -#: ../../rst/reference_appendices/config.rst:3029 -msgid "``never``" -msgstr "``never``" - -#: ../../rst/reference_appendices/config.rst:3031 -msgid "it will replace any invalid characters with '_' (underscore) and warn the user" -msgstr "無効な文字を '_' (アンダースコア) に置き換え、ユーザーに警告します" - -#: ../../rst/reference_appendices/config.rst -msgid "never" -msgstr "never" - -#: ../../rst/reference_appendices/config.rst:3032 -msgid "it will allow for the group name but warn about the issue" -msgstr "グループ名は許可されますが、問題を警告します" - -#: ../../rst/reference_appendices/config.rst:3033 -msgid "it does the same as 'never', without issuing a warning" -msgstr "警告を出力せずに、'never' と同じように動作します" - -#: ../../rst/reference_appendices/config.rst -msgid "silently" -msgstr "silently" - -#: ../../rst/reference_appendices/config.rst:3034 -msgid "it does the same as 'always', without issuing a warning" -msgstr "警告を出力せずに、'always' と同じように動作します" - -#: ../../rst/reference_appendices/config.rst:3038 -msgid "force_valid_group_names" -msgstr "force_valid_group_names" - -#: ../../rst/reference_appendices/config.rst:3040 -msgid ":envvar:`ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS`" -msgstr ":envvar:`ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS`" - -#: ../../rst/reference_appendices/config.rst:3045 -msgid "USE_PERSISTENT_CONNECTIONS" -msgstr "USE_PERSISTENT_CONNECTIONS" - -#: ../../rst/reference_appendices/config.rst:3047 -#: ../../rst/reference_appendices/config.rst:4642 -msgid "Toggles the use of persistence for connections." -msgstr "接続に対して永続性の使用を切り替えます。" - -#: ../../rst/reference_appendices/config.rst:3052 -msgid "use_persistent_connections" -msgstr "use_persistent_connections" - -#: ../../rst/reference_appendices/config.rst:3054 -msgid ":envvar:`ANSIBLE_USE_PERSISTENT_CONNECTIONS`" -msgstr ":envvar:`ANSIBLE_USE_PERSISTENT_CONNECTIONS`" - -#: ../../rst/reference_appendices/config.rst:3059 -msgid "VALIDATE_ACTION_GROUP_METADATA" -msgstr "VALIDATE_ACTION_GROUP_METADATA" - -#: ../../rst/reference_appendices/config.rst:3061 -#: ../../rst/reference_appendices/config.rst:4698 -msgid "A toggle to disable validating a collection's 'metadata' entry for a module_defaults action group. Metadata containing unexpected fields or value types will produce a warning when this is True." -msgstr "module_defaults アクショングループのコレクションの「metadata」エントリーの検証を無効にする切り替えです。予期しないフィールドまたは値タイプを含むメタデータがあると、True の場合に警告が表示されます。" - -#: ../../rst/reference_appendices/config.rst:3067 -msgid "validate_action_group_metadata" -msgstr "validate_action_group_metadata" - -#: ../../rst/reference_appendices/config.rst:3069 -msgid ":envvar:`ANSIBLE_VALIDATE_ACTION_GROUP_METADATA`" -msgstr ":envvar:`ANSIBLE_VALIDATE_ACTION_GROUP_METADATA`" - -#: ../../rst/reference_appendices/config.rst:3074 -msgid "VARIABLE_PLUGINS_ENABLED" -msgstr "VARIABLE_PLUGINS_ENABLED" - -#: ../../rst/reference_appendices/config.rst:3076 -#: ../../rst/reference_appendices/config.rst:4650 -msgid "Accept list for variable plugins that require it." -msgstr "必要になる vars プラグインの許可リスト。" - -#: ../../rst/reference_appendices/config.rst:3078 -msgid "``['host_group_vars']``" -msgstr "``['host_group_vars']``" - -#: ../../rst/reference_appendices/config.rst:3082 -msgid "vars_plugins_enabled" -msgstr "vars_plugins_enabled" - -#: ../../rst/reference_appendices/config.rst:3084 -msgid ":envvar:`ANSIBLE_VARS_ENABLED`" -msgstr ":envvar:`ANSIBLE_VARS_ENABLED`" - -#: ../../rst/reference_appendices/config.rst:3089 -msgid "VARIABLE_PRECEDENCE" -msgstr "VARIABLE_PRECEDENCE" - -#: ../../rst/reference_appendices/config.rst:3091 -#: ../../rst/reference_appendices/config.rst:4658 -msgid "Allows to change the group variable precedence merge order." -msgstr "グループ変数の優先順位のマージ順序を変更できます。" - -#: ../../rst/reference_appendices/config.rst:3093 -msgid "``['all_inventory', 'groups_inventory', 'all_plugins_inventory', 'all_plugins_play', 'groups_plugins_inventory', 'groups_plugins_play']``" -msgstr "``['all_inventory', 'groups_inventory', 'all_plugins_inventory', 'all_plugins_play', 'groups_plugins_inventory', 'groups_plugins_play']``" - -#: ../../rst/reference_appendices/config.rst:3097 -msgid "precedence" -msgstr "precedence" - -#: ../../rst/reference_appendices/config.rst:3099 -msgid ":envvar:`ANSIBLE_PRECEDENCE`" -msgstr ":envvar:`ANSIBLE_PRECEDENCE`" - -#: ../../rst/reference_appendices/config.rst:3104 -msgid "VERBOSE_TO_STDERR" -msgstr "VERBOSE_TO_STDERR" - -#: ../../rst/reference_appendices/config.rst:3106 -#: ../../rst/reference_appendices/config.rst:4706 -msgid "Force 'verbose' option to use stderr instead of stdout" -msgstr "stdout の代わりに「verbose」オプションを強制的に使用します。" - -#: ../../rst/reference_appendices/config.rst:3112 -msgid "verbose_to_stderr" -msgstr "verbose_to_stderr" - -#: ../../rst/reference_appendices/config.rst:3114 -msgid ":envvar:`ANSIBLE_VERBOSE_TO_STDERR`" -msgstr ":envvar:`ANSIBLE_VERBOSE_TO_STDERR`" - -#: ../../rst/reference_appendices/config.rst:3119 -msgid "WIN_ASYNC_STARTUP_TIMEOUT" -msgstr "WIN_ASYNC_STARTUP_TIMEOUT" - -#: ../../rst/reference_appendices/config.rst:3121 -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." -msgstr "Ansible の非同期タスク (「非同期アクションおよびポーリング」で説明) の場合、これは、Ansible が生成するタスクが Windows システムで使用される名前付きパイプに接続するのを待機する時間 (秒単位) です。デフォルトは 5 秒です。これは、低速のシステムや高負荷のシステムでは低すぎる可能性があります。これは、非同期コマンドを実行できる合計時間ではありませんが、非同期コマンドの開始を待機する別のタイムアウトです。タスクは、パイプに接続された後にのみ async_timeout に対してタイムアウトが開始するため、タスクの全体的な最大期間は、ここで指定された分だけ延長されます。" - -#: ../../rst/reference_appendices/config.rst:3127 -msgid "win_async_startup_timeout" -msgstr "win_async_startup_timeout" - -#: ../../rst/reference_appendices/config.rst:3129 -msgid ":envvar:`ANSIBLE_WIN_ASYNC_STARTUP_TIMEOUT`" -msgstr ":envvar:`ANSIBLE_WIN_ASYNC_STARTUP_TIMEOUT`" - -#: ../../rst/reference_appendices/config.rst:3131 -msgid "`ansible_win_async_startup_timeout`" -msgstr "`ansible_win_async_startup_timeout`" - -#: ../../rst/reference_appendices/config.rst:3136 -msgid "WORKER_SHUTDOWN_POLL_COUNT" -msgstr "WORKER_SHUTDOWN_POLL_COUNT" - -#: ../../rst/reference_appendices/config.rst:3138 -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." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認する最大回数。この制限に達すると、まだ実行中のワーカープロセスはすべて終了します。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:3143 -msgid ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_COUNT`" -msgstr ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_COUNT`" - -#: ../../rst/reference_appendices/config.rst:3148 -msgid "WORKER_SHUTDOWN_POLL_DELAY" -msgstr "WORKER_SHUTDOWN_POLL_DELAY" - -#: ../../rst/reference_appendices/config.rst:3150 -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." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認するときに、ポーリングループ間でスリープする秒数。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:3152 -msgid "``0.1``" -msgstr "``0.1``" - -#: ../../rst/reference_appendices/config.rst:3155 -msgid ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_DELAY`" -msgstr ":envvar:`ANSIBLE_WORKER_SHUTDOWN_POLL_DELAY`" - -#: ../../rst/reference_appendices/config.rst:3160 -msgid "YAML_FILENAME_EXTENSIONS" -msgstr "YAML_FILENAME_EXTENSIONS" - -#: ../../rst/reference_appendices/config.rst:3162 -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." -msgstr "YAML または JSON、あるいはこれらの Vault バージョンである必要がある「変数」ファイルを探すときは、これらすべての拡張子を確認してください。これは、vars_files、include_vars、inventory、vars プラグインなどに影響します。" - -#: ../../rst/reference_appendices/config.rst:3164 -msgid "``['.yml', '.yaml', '.json']``" -msgstr "``['.yml', '.yaml', '.json']``" - -#: ../../rst/reference_appendices/config.rst:3167 -msgid "yaml_valid_extensions" -msgstr "yaml_valid_extensions" - -#: ../../rst/reference_appendices/config.rst:3169 -msgid ":envvar:`ANSIBLE_YAML_FILENAME_EXT`" -msgstr ":envvar:`ANSIBLE_YAML_FILENAME_EXT`" - -#: ../../rst/reference_appendices/config.rst:3173 -msgid "Environment Variables" -msgstr "環境変数" - -#: ../../rst/reference_appendices/config.rst:3178 -msgid "Override the default ansible config file" -msgstr "デフォルトの ansible config ファイルを上書きします。" - -#: ../../rst/reference_appendices/config.rst:3185 -msgid "See also :ref:`ANSIBLE_HOME `" -msgstr ":ref:`ANSIBLE_HOME ` も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3191 -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." -msgstr "ansible-connection スクリプトを探す場所を指定します。この場所は、$PATH の検索前にチェックされます。null に設定すると、Ansible は ansible スクリプトと同じディレクトリーで起動します。" - -#: ../../rst/reference_appendices/config.rst:3193 -msgid "See also :ref:`ANSIBLE_CONNECTION_PATH `" -msgstr "「:ref:`ANSIBLE_CONNECTION_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3201 -msgid "See also :ref:`ANSIBLE_COW_SELECTION `" -msgstr "「:ref:`ANSIBLE_COW_SELECTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3209 -#: ../../rst/reference_appendices/config.rst:3219 -msgid "See also :ref:`ANSIBLE_COW_ACCEPTLIST `" -msgstr "「:ref:`ANSIBLE_COW_ACCEPTLIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3228 -msgid "See also :ref:`ANSIBLE_FORCE_COLOR `" -msgstr "「:ref:`ANSIBLE_FORCE_COLOR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3236 -#: ../../rst/reference_appendices/config.rst:3243 -msgid "See also :ref:`ANSIBLE_NOCOLOR `" -msgstr "「:ref:`ANSIBLE_NOCOLOR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3252 -msgid "See also :ref:`ANSIBLE_NOCOWS `" -msgstr "「:ref:`ANSIBLE_NOCOWS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3260 -msgid "See also :ref:`ANSIBLE_COW_PATH `" -msgstr "「:ref:`ANSIBLE_COW_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3266 -msgid "This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all.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.It 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 setting will be disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled." -msgstr "パイプライン (connection プラグインでサポートされる場合) は、実際のファイル転送をせずに多数の Ansible モジュールを実行して、リモートサーバーでモジュールを実行するために必要なネットワーク操作の数を減らします。これにより、有効にするとパフォーマンスが大幅に向上する可能性があります。ただし、これは特権昇格 (become) と競合します。たとえば、「sudo:」操作を使用する場合は、すべての管理対象ホストの /etc/sudoers で「requiretty」を無効にする必要があります。これが、デフォルトで無効になっている理由です。``ANSIBLE_KEEP_REMOTE_FILES`` が有効な場合、このオプションは無効になります。これはグローバルオプションであり、各 connection プラグインは、より具体的なオプションを指定するか、パイプをサポートしないかのいずれかによりオーバーライドすることができます。" - -#: ../../rst/reference_appendices/config.rst:3268 -msgid "See also :ref:`ANSIBLE_PIPELINING `" -msgstr "「:ref:`ANSIBLE_PIPELINING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3276 -msgid "See also :ref:`ANY_ERRORS_FATAL `" -msgstr "「:ref:`ANY_ERRORS_FATAL `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3282 -msgid "This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root.If executable, it will be run and the resulting stdout will be used as the password." -msgstr "この設定は、リモートユーザーと become ユーザーが同じである場合に、become をスキップするかどうか (root sudo から root) を制御します。実行可能な場合には、実行されて、生成される標準出力がパスワードとして使用されます。" - -#: ../../rst/reference_appendices/config.rst:3284 -msgid "See also :ref:`BECOME_ALLOW_SAME_USER `" -msgstr "「:ref:`BECOME_ALLOW_SAME_USER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3290 -msgid "The password file to use for the become plugin. --become-password-file.If executable, it will be run and the resulting stdout will be used as the password." -msgstr "become プラグインに使用するパスワードファイル。--become-password-file。実行可能の場合は、実行されて、生成される標準出力がパスワードとして使用されます。" - -#: ../../rst/reference_appendices/config.rst:3292 -msgid "See also :ref:`BECOME_PASSWORD_FILE `" -msgstr ":ref:`BECOME_PASSWORD_FILE ` も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3300 -msgid "See also :ref:`AGNOSTIC_BECOME_PROMPT `" -msgstr "「:ref:`AGNOSTIC_BECOME_PROMPT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3308 -msgid "See also :ref:`CACHE_PLUGIN `" -msgstr "「:ref:`CACHE_PLUGIN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3316 -msgid "See also :ref:`CACHE_PLUGIN_CONNECTION `" -msgstr "「:ref:`CACHE_PLUGIN_CONNECTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3324 -msgid "See also :ref:`CACHE_PLUGIN_PREFIX `" -msgstr "「:ref:`CACHE_PLUGIN_PREFIX `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3332 -msgid "See also :ref:`CACHE_PLUGIN_TIMEOUT `" -msgstr "「:ref:`CACHE_PLUGIN_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3340 -msgid "See also :ref:`COLLECTIONS_SCAN_SYS_PATH `" -msgstr "「:ref:`COLLECTIONS_SCAN_SYS_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3349 -#: ../../rst/reference_appendices/config.rst:3357 -msgid "See also :ref:`COLLECTIONS_PATHS `" -msgstr "「:ref:`COLLECTIONS_PATHS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3366 -msgid "See also :ref:`COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH `" -msgstr "「:ref:`COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3374 -msgid "See also :ref:`COLOR_CHANGED `" -msgstr "「:ref:`COLOR_CHANGED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3382 -msgid "See also :ref:`COLOR_CONSOLE_PROMPT `" -msgstr "「:ref:`COLOR_CONSOLE_PROMPT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3390 -msgid "See also :ref:`COLOR_DEBUG `" -msgstr "「:ref:`COLOR_DEBUG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3398 -msgid "See also :ref:`COLOR_DEPRECATE `" -msgstr "「:ref:`COLOR_DEPRECATE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3406 -msgid "See also :ref:`COLOR_DIFF_ADD `" -msgstr "「:ref:`COLOR_DIFF_ADD `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3414 -msgid "See also :ref:`COLOR_DIFF_LINES `" -msgstr "「:ref:`COLOR_DIFF_LINES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3422 -msgid "See also :ref:`COLOR_DIFF_REMOVE `" -msgstr "「:ref:`COLOR_DIFF_REMOVE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3430 -msgid "See also :ref:`COLOR_ERROR `" -msgstr "「:ref:`COLOR_ERROR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3438 -msgid "See also :ref:`COLOR_HIGHLIGHT `" -msgstr "「:ref:`COLOR_HIGHLIGHT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3446 -msgid "See also :ref:`COLOR_OK `" -msgstr "「:ref:`COLOR_OK `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3454 -msgid "See also :ref:`COLOR_SKIP `" -msgstr "「:ref:`COLOR_SKIP `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3462 -msgid "See also :ref:`COLOR_UNREACHABLE `" -msgstr "「:ref:`COLOR_UNREACHABLE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3470 -msgid "See also :ref:`COLOR_VERBOSE `" -msgstr "「:ref:`COLOR_VERBOSE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3478 -msgid "See also :ref:`COLOR_WARN `" -msgstr "「:ref:`COLOR_WARN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3486 -msgid "See also :ref:`CONNECTION_PASSWORD_FILE `" -msgstr ":ref:`CONNECTION_PASSWORD_FILE ` も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3492 -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." -msgstr "リモートホストの出力ディレクトリーを設定してカバレッジレポートを生成します。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:3494 -msgid "See also :ref:`COVERAGE_REMOTE_OUTPUT `" -msgstr "「:ref:`COVERAGE_REMOTE_OUTPUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3500 -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." -msgstr "リモートホストで実行するときにカバレッジを実行する Ansible コントローラー上のファイルのパスのリスト。パスグロブに一致するファイルのみがカバレッジを収集します。パスグロブは、``:`` で区切ることで複数指定できます。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。" - -#: ../../rst/reference_appendices/config.rst:3502 -msgid "See also :ref:`COVERAGE_REMOTE_PATHS `" -msgstr "「:ref:`COVERAGE_REMOTE_PATHS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3508 -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." -msgstr "デフォルトでは、Ansible はタスクアクション (モジュールまたは action プラグイン) から受け取ると、警告を False に調整することで警告を非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:3510 -msgid "See also :ref:`ACTION_WARNINGS `" -msgstr "「:ref:`ACTION_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3516 -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." -msgstr "デフォルトでは、Ansible は、インベントリーにホストがない場合に警告を表示します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:3518 -msgid "See also :ref:`LOCALHOST_WARNING `" -msgstr "「:ref:`LOCALHOST_WARNING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3524 -msgid "By default Ansible will issue a warning when no inventory was loaded and notes that it will use an implicit localhost-only inventory.These warnings can be silenced by adjusting this setting to False." -msgstr "デフォルトでは、Ansible は、インベントリーがロードされていない場合に警告を発行し、暗黙的なローカルホストのみのインベントリーを使用することを通知します。これらの警告の通知は、この設定を False に調整して、オフにできます。" - -#: ../../rst/reference_appendices/config.rst:3526 -msgid "See also :ref:`INVENTORY_UNPARSED_WARNING `" -msgstr ":ref:`INVENTORY_UNPARSED_WARNING ` も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3534 -msgid "See also :ref:`DOC_FRAGMENT_PLUGIN_PATH `" -msgstr "「:ref:`DOC_FRAGMENT_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3542 -msgid "See also :ref:`DEFAULT_ACTION_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_ACTION_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3551 -msgid "See also :ref:`DEFAULT_ASK_PASS `" -msgstr "「:ref:`DEFAULT_ASK_PASS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3559 -msgid "See also :ref:`DEFAULT_ASK_VAULT_PASS `" -msgstr "「:ref:`DEFAULT_ASK_VAULT_PASS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3567 -msgid "See also :ref:`DEFAULT_BECOME `" -msgstr "「:ref:`DEFAULT_BECOME `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3575 -msgid "See also :ref:`DEFAULT_BECOME_ASK_PASS `" -msgstr "「:ref:`DEFAULT_BECOME_ASK_PASS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3583 -msgid "See also :ref:`DEFAULT_BECOME_METHOD `" -msgstr "「:ref:`DEFAULT_BECOME_METHOD `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3591 -msgid "See also :ref:`DEFAULT_BECOME_EXE `" -msgstr "「:ref:`DEFAULT_BECOME_EXE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3599 -msgid "See also :ref:`DEFAULT_BECOME_FLAGS `" -msgstr "「:ref:`DEFAULT_BECOME_FLAGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3607 -msgid "See also :ref:`BECOME_PLUGIN_PATH `" -msgstr "「:ref:`BECOME_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3615 -msgid "See also :ref:`DEFAULT_BECOME_USER `" -msgstr "「:ref:`DEFAULT_BECOME_USER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3623 -msgid "See also :ref:`DEFAULT_CACHE_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CACHE_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3631 -msgid "See also :ref:`DEFAULT_CALLBACK_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CALLBACK_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3639 -#: ../../rst/reference_appendices/config.rst:3649 -msgid "See also :ref:`CALLBACKS_ENABLED `" -msgstr "「:ref:`CALLBACKS_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3658 -msgid "See also :ref:`DEFAULT_CLICONF_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CLICONF_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3666 -msgid "See also :ref:`DEFAULT_CONNECTION_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_CONNECTION_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3674 -msgid "See also :ref:`DEFAULT_DEBUG `" -msgstr "「:ref:`DEFAULT_DEBUG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3682 -msgid "See also :ref:`DEFAULT_EXECUTABLE `" -msgstr "「:ref:`DEFAULT_EXECUTABLE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3688 -msgid "This option allows you to globally configure a custom path for 'local_facts' for the implied :ref:`ansible_collections.ansible.builtin.setup_module` task when using fact gathering.If not set, it will fallback to the default from the ``ansible.builtin.setup`` module: ``/etc/ansible/facts.d``.This does **not** affect user defined tasks that use the ``ansible.builtin.setup`` module.The real action being created by the implicit task is currently ``ansible.legacy.gather_facts`` module, which then calls the configured fact modules, by default this will be ``ansible.builtin.setup`` for POSIX systems but other platforms might have different defaults." -msgstr "このオプションを使用すると、ファクト収集を使用している場合に暗黙的な:ref:`ansible_collections.ansible.builtin.setup_module` タスクの「local_facts」のカスタムパスをグローバルに設定できます。これが設定されていない場合には、``ansible.builtin.setup`` モジュール: ``/etc/ansible/facts.d`` からデフォルトにフォールバックします。この設定は、``ansible.builtin.setup`` モジュールを使用するユーザー定義のタスクには影響は **ありません**。暗黙的なタスクで作成される実際のアクションは現在は、 ``ansible.legacy.gather_facts`` モジュールで、このモジュールが設定済みのファクトモジュールを呼び出します。デフォルトでは、これは POSIX の ``ansible.builtin.setup`` ですが、他のプラットフォームには別の初期値がある可能性があります。" - -#: ../../rst/reference_appendices/config.rst:3690 -msgid "See also :ref:`DEFAULT_FACT_PATH `" -msgstr "「:ref:`DEFAULT_FACT_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3698 -msgid "See also :ref:`DEFAULT_FILTER_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_FILTER_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3704 -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." -msgstr "このオプションは、ホストで障害が発生した場合でも、通知されたハンドラーがホストで実行されるかどうかを制御します。false にすると、ホストで障害が発生した場合に、ハンドラーは実行されません。これは、プレイごとまたはコマンドラインで設定することもできます。詳細については、「ハンドラーおよび失敗」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:3706 -msgid "See also :ref:`DEFAULT_FORCE_HANDLERS `" -msgstr "「:ref:`DEFAULT_FORCE_HANDLERS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3714 -msgid "See also :ref:`DEFAULT_FORKS `" -msgstr "「:ref:`DEFAULT_FORKS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3720 -msgid "This setting controls the default policy of fact gathering (facts discovered about remote systems).This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin." -msgstr "この設定は、ファクト収集 (リモートシステムについて検出されたファクト) のデフォルトポリシーを制御します。このオプションは、ファクト収集の時間を節約する場合に役立ちます。'smart' と 'explicit' の両方がキャッシュプラグインを使用します。" - -#: ../../rst/reference_appendices/config.rst:3722 -msgid "See also :ref:`DEFAULT_GATHERING `" -msgstr "「:ref:`DEFAULT_GATHERING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3728 -msgid "Set the `gather_subset` option for the :ref:`ansible_collections.ansible.builtin.setup_module` task in the implicit fact gathering. See the module documentation for specifics.It does **not** apply to user defined ``ansible.builtin.setup`` tasks." -msgstr "暗黙的なファクト収集の :ref:`ansible_collections.ansible.builtin.setup_module` タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の ``ansible.builtin.setup`` タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:3730 -msgid "See also :ref:`DEFAULT_GATHER_SUBSET `" -msgstr "「:ref:`DEFAULT_GATHER_SUBSET `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3736 -msgid "Set the timeout in seconds for the implicit fact gathering, see the module documentation for specifics.It does **not** apply to user defined :ref:`ansible_collections.ansible.builtin.setup_module` tasks." -msgstr "暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の :ref:`ansible_collections.ansible.builtin.setup_module` タスクには **適用されません**。" - -#: ../../rst/reference_appendices/config.rst:3738 -msgid "See also :ref:`DEFAULT_GATHER_TIMEOUT `" -msgstr "「:ref:`DEFAULT_GATHER_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3744 -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'**." -msgstr "この設定は、ディクショナリー変数 (別名ハッシュ、マップ、連想配列) の重複した定義を Ansible でどのように扱うかを制御します。この設定は、値がスカラー (整数、文字列) や配列である変数には影響しません。**警告** これは脆弱で、コンテンツ (プレイ、ロール、コレクション) が移植できなくなり、継続的な混乱と誤用を招く恐れがあるため、この設定を変更することは推奨されません。絶対に必要であると思われる場合を除き、この設定を変更しないでください。変数名の再利用は避け、``combine`` フィルターと ``vars`` ルックアップおよび ``varnames`` ルックアップを利用して、個々の変数のマージバージョンを作成することが推奨されます。経験上、このようなことが本当に必要とされることはほとんどなく、データ構造やプレイが複雑になりすぎていることを示しています。用途によっては、入力時にマージするカスタム vars_plugins を検討することもできますし、``host_vars/`` ディレクトリーおよび ``group_vars/`` ディレクトリーの解析を担当するデフォルトの ``host_group_vars`` を置き換えることもできます。この設定を使用するほとんどのユーザーはインベントリースコープにしか興味がありませんが、この設定自体がすべてのソースに影響し、デバッグをさらに困難にします。公式のサンプルリポジトリーにある Playbook およびロールはすべて、この設定のデフォルトを想定しています。``merge`` に設定を変更すると、変数ソース全体に適用されますが、多くのソースでは内部的に変数が上書きされたままになります。たとえば、``include_vars`` は、Ansible を更新する前に内部で変数の重複を排除し、「最終定義」が同じファイルの以前の定義を上書きします。Ansible プロジェクトでは、**新規プロジェクトでは** ``merge`` **を回避する** ことが推奨されます。Ansible 開発者は、最終的にこの設定を非推奨にして削除することを意図していますが、一部のユーザーがこの設定に大きく依存しているため、この設定を残しています。新しいプロジェクトでは、**「merge」を回避** してください。" - -#: ../../rst/reference_appendices/config.rst:3746 -msgid "See also :ref:`DEFAULT_HASH_BEHAVIOUR `" -msgstr "「:ref:`DEFAULT_HASH_BEHAVIOUR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3754 -msgid "See also :ref:`DEFAULT_HOST_LIST `" -msgstr "「:ref:`DEFAULT_HOST_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3762 -msgid "See also :ref:`DEFAULT_HTTPAPI_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_HTTPAPI_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3771 -msgid "See also :ref:`DEFAULT_INVENTORY_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_INVENTORY_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3777 -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 :)" -msgstr "これは、追加の Jinja2 拡張機能を有効にすることができる開発者固有の機能です。詳細については、Jinja2 ドキュメントを参照してください。この拡張機能が何をするのかわからない場合は、おそらくこの設定を変更する必要はありません。" - -#: ../../rst/reference_appendices/config.rst:3779 -msgid "See also :ref:`DEFAULT_JINJA2_EXTENSIONS `" -msgstr "「:ref:`DEFAULT_JINJA2_EXTENSIONS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3787 -msgid "See also :ref:`DEFAULT_JINJA2_NATIVE `" -msgstr "「:ref:`DEFAULT_JINJA2_NATIVE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3793 -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``." -msgstr "リモートでタスクを実行するために Ansible が使用する一時ファイルのクリーンアップを有効または無効にします。このオプションを有効にすると、``ANSIBLE_PIPELINING`` を無効にします。" - -#: ../../rst/reference_appendices/config.rst:3795 -msgid "See also :ref:`DEFAULT_KEEP_REMOTE_FILES `" -msgstr "「:ref:`DEFAULT_KEEP_REMOTE_FILES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3803 -msgid "See also :ref:`DEFAULT_LIBVIRT_LXC_NOSECLABEL `" -msgstr "「:ref:`DEFAULT_LIBVIRT_LXC_NOSECLABEL `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3811 -msgid "See also :ref:`DEFAULT_LOAD_CALLBACK_PLUGINS `" -msgstr "「:ref:`DEFAULT_LOAD_CALLBACK_PLUGINS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3819 -msgid "See also :ref:`DEFAULT_LOCAL_TMP `" -msgstr "「:ref:`DEFAULT_LOCAL_TMP `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3827 -msgid "See also :ref:`DEFAULT_LOG_PATH `" -msgstr "「:ref:`DEFAULT_LOG_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3835 -msgid "See also :ref:`DEFAULT_LOG_FILTER `" -msgstr "「:ref:`DEFAULT_LOG_FILTER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3843 -msgid "See also :ref:`DEFAULT_LOOKUP_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_LOOKUP_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3852 -msgid "See also :ref:`DEFAULT_MODULE_ARGS `" -msgstr "「:ref:`DEFAULT_MODULE_ARGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3862 -msgid "See also :ref:`DEFAULT_MODULE_PATH `" -msgstr "「:ref:`DEFAULT_MODULE_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3870 -msgid "See also :ref:`DEFAULT_MODULE_UTILS_PATH `" -msgstr "「:ref:`DEFAULT_MODULE_UTILS_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3878 -msgid "See also :ref:`DEFAULT_NETCONF_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_NETCONF_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3886 -msgid "See also :ref:`DEFAULT_NO_LOG `" -msgstr "「:ref:`DEFAULT_NO_LOG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3894 -msgid "See also :ref:`DEFAULT_NO_TARGET_SYSLOG `" -msgstr "「:ref:`DEFAULT_NO_TARGET_SYSLOG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3902 -msgid "See also :ref:`DEFAULT_NULL_REPRESENTATION `" -msgstr "「:ref:`DEFAULT_NULL_REPRESENTATION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3910 -msgid "See also :ref:`DEFAULT_POLL_INTERVAL `" -msgstr "「:ref:`DEFAULT_POLL_INTERVAL `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3918 -msgid "See also :ref:`DEFAULT_PRIVATE_KEY_FILE `" -msgstr "「:ref:`DEFAULT_PRIVATE_KEY_FILE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3924 -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." -msgstr "ロール変数が他のロールからアクセスできないようにします。これは、Playbook でロールが複数回使用されている場合に、ロール変数をデフォルト値にリセットする方法として導入されました。" - -#: ../../rst/reference_appendices/config.rst:3926 -msgid "See also :ref:`DEFAULT_PRIVATE_ROLE_VARS `" -msgstr "「:ref:`DEFAULT_PRIVATE_ROLE_VARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3934 -msgid "See also :ref:`DEFAULT_REMOTE_PORT `" -msgstr "「:ref:`DEFAULT_REMOTE_PORT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3940 -msgid "Sets the login user for the target machinesWhen blank it uses the connection plugin's default, normally the user currently executing Ansible." -msgstr "ターゲットマシンのログインユーザーを設定します。空の場合は、connection プラグインのデフォルト (通常は現在 Ansible を実行しているユーザー) を使用します。" - -#: ../../rst/reference_appendices/config.rst:3942 -msgid "See also :ref:`DEFAULT_REMOTE_USER `" -msgstr "「:ref:`DEFAULT_REMOTE_USER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3950 -msgid "See also :ref:`DEFAULT_ROLES_PATH `" -msgstr "「:ref:`DEFAULT_ROLES_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3956 -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." -msgstr "一部のファイルシステムは安全な操作をサポートしていないか、一貫性のないエラーを返します。この設定により、Ansible はリスト内のエラーを「許容」し、致命的なエラーを引き起こしません。ファイルシステムがリストに含まれていると、データが破損する可能性があり、書き込みが常に検証されるとは限りません。" - -#: ../../rst/reference_appendices/config.rst:3958 -msgid "See also :ref:`DEFAULT_SELINUX_SPECIAL_FS `" -msgstr "「:ref:`DEFAULT_SELINUX_SPECIAL_FS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3965 -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.See :ref:`callback_plugins` for a list of available options." -msgstr "Ansible 出力の表示に使用されるメインコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、標準出力 (stdout) に使用できるのは 1 つだけです。利用可能なオプションの一覧は、:ref:`callback_plugins` を参照してください。" - -#: ../../rst/reference_appendices/config.rst:3967 -msgid "See also :ref:`DEFAULT_STDOUT_CALLBACK `" -msgstr "「:ref:`DEFAULT_STDOUT_CALLBACK `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3973 -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." -msgstr "タスクデバッガーを有効にするかどうかにかかわらず、これは以前はストラテジープラグインとして実行されていました。これで、すべての strategy プラグインがこの動作を継承できるようになりました。デバッガーは、タスクが到達不能で失敗したときにデフォルトでアクティブになります。柔軟性を高めるには、debugger キーワードを使用します。" - -#: ../../rst/reference_appendices/config.rst:3975 -msgid "See also :ref:`ENABLE_TASK_DEBUGGER `" -msgstr "「:ref:`ENABLE_TASK_DEBUGGER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3981 -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." -msgstr "このオプションは、ignore_errors=True が指定されている場合に、失敗したタスクでタスクデバッガーが呼び出されるかどうかを定義します。True に設定すると、デバッガーが ignore_errors を許可するように指定し、False に設定すると ignore_errors が無効になります。" - -#: ../../rst/reference_appendices/config.rst:3983 -msgid "See also :ref:`TASK_DEBUGGER_IGNORE_ERRORS `" -msgstr "「:ref:`TASK_DEBUGGER_IGNORE_ERRORS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3991 -msgid "See also :ref:`DEFAULT_STRATEGY `" -msgstr "「:ref:`DEFAULT_STRATEGY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:3999 -msgid "See also :ref:`DEFAULT_STRATEGY_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_STRATEGY_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4007 -msgid "See also :ref:`DEFAULT_SU `" -msgstr "「:ref:`DEFAULT_SU `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4015 -msgid "See also :ref:`DEFAULT_SYSLOG_FACILITY `" -msgstr "「:ref:`DEFAULT_SYSLOG_FACILITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4023 -msgid "See also :ref:`DEFAULT_TERMINAL_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_TERMINAL_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4031 -msgid "See also :ref:`DEFAULT_TEST_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_TEST_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4039 -msgid "See also :ref:`DEFAULT_TIMEOUT `" -msgstr "「:ref:`DEFAULT_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4047 -msgid "See also :ref:`DEFAULT_TRANSPORT `" -msgstr "「:ref:`DEFAULT_TRANSPORT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4053 -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." -msgstr "True にすると、これにより、タイプミスの可能性が高い変数名を参照するステップが失敗するテンプレートが作成されます。それ以外の場合は、未定義の変数を含む '{{ template_expression }}' は、記述されたとおりにテンプレートまたは Ansible のアクション行にレンダリングされます。" - -#: ../../rst/reference_appendices/config.rst:4055 -msgid "See also :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR `" -msgstr "「:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4063 -msgid "See also :ref:`DEFAULT_VARS_PLUGIN_PATH `" -msgstr "「:ref:`DEFAULT_VARS_PLUGIN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4071 -msgid "See also :ref:`DEFAULT_VAULT_ID_MATCH `" -msgstr "「:ref:`DEFAULT_VAULT_ID_MATCH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4079 -msgid "See also :ref:`DEFAULT_VAULT_IDENTITY `" -msgstr "「:ref:`DEFAULT_VAULT_IDENTITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4087 -msgid "See also :ref:`DEFAULT_VAULT_ENCRYPT_IDENTITY `" -msgstr "「:ref:`DEFAULT_VAULT_ENCRYPT_IDENTITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4095 -msgid "See also :ref:`DEFAULT_VAULT_IDENTITY_LIST `" -msgstr "「:ref:`DEFAULT_VAULT_IDENTITY_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4101 -msgid "The vault password file to use. Equivalent to --vault-password-file or --vault-idIf executable, it will be run and the resulting stdout will be used as the password." -msgstr "使用する Vault パスワードファイル。--vault-password-file または --vault-id と同等です。実行可能な場合には、実行されて、生成される標準出力がパスワードとして使用されます。" - -#: ../../rst/reference_appendices/config.rst:4103 -msgid "See also :ref:`DEFAULT_VAULT_PASSWORD_FILE `" -msgstr "「:ref:`DEFAULT_VAULT_PASSWORD_FILE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4111 -msgid "See also :ref:`DEFAULT_VERBOSITY `" -msgstr "「:ref:`DEFAULT_VERBOSITY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4119 -msgid "See also :ref:`DEPRECATION_WARNINGS `" -msgstr "「:ref:`DEPRECATION_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4127 -msgid "See also :ref:`DEVEL_WARNING `" -msgstr "「:ref:`DEVEL_WARNING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4135 -msgid "See also :ref:`DIFF_ALWAYS `" -msgstr "「:ref:`DIFF_ALWAYS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4143 -msgid "See also :ref:`DIFF_CONTEXT `" -msgstr "「:ref:`DIFF_CONTEXT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4149 -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." -msgstr "通常、``ansible-playbook`` は、実行された各タスクのヘッダーが出力されます。これらのヘッダーにはタスクの name: フィールドが指定されていればそれが含まれます。指定していない場合は、``ansible-playbook`` がタスクのアクションを使用して、どのタスクが現在実行されているかを知ることができます。多くの同じアクションを実行する場合は、同じアクションの他のタスクと区別するために、タスクに関する詳細情報が必要になることがあります。設定でこの変数を True に設定すると、``ansible-playbook`` では、タスクの引数もヘッダーに含まれます。パラメーターに機密性の高い値が含まれている可能性があり、それらを出力しないため、この設定のデフォルトは False です。これを True に設定した場合は、環境の標準出力 (誰もあなたの画面を肩越しに盗み見ることができず、あなたは標準出力を安全でないファイルに保存していません) を確実に保護するか、すべての Playbook で機密性の高い値を持つタスクに ``no_log: True`` パラメーターを明示的に追加する必要があります。詳細は、「Playbook に機密データを保存するにはどうすれば良いですか」を参照してください。" - -#: ../../rst/reference_appendices/config.rst:4151 -msgid "See also :ref:`DISPLAY_ARGS_TO_STDOUT `" -msgstr "「:ref:`DISPLAY_ARGS_TO_STDOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4159 -msgid "See also :ref:`DISPLAY_SKIPPED_HOSTS `" -msgstr "「:ref:`DISPLAY_SKIPPED_HOSTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4166 -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." -msgstr "デフォルトでは、Ansible は、YAML で重複した dict キーが発生した場合に警告を発行します。この警告は、この設定を False に設定すると非表示にすることができます。" - -#: ../../rst/reference_appendices/config.rst:4168 -msgid "See also :ref:`DUPLICATE_YAML_DICT_KEY `" -msgstr "「:ref:`DUPLICATE_YAML_DICT_KEY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4176 -msgid "See also :ref:`ERROR_ON_MISSING_HANDLER `" -msgstr "「:ref:`ERROR_ON_MISSING_HANDLER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4183 -msgid "Which modules to run during a play's fact gathering stage, using the default of 'smart' will try to figure it out based on connection type.If adding your own modules but you still want to use the default Ansible facts, you will want to include 'setup' or corresponding network module to the list (if you add 'smart', Ansible will also figure it out).This does not affect explicit calls to the 'setup' module, but does always affect the 'gather_facts' action (implicit or explicit)." -msgstr "プレイのファクト収集段階で実行するモジュールは、デフォルトの「smart」を使用すると接続タイプに基づいて確認を試みます。独自のモジュールを追加したうえで、デフォルトの Ansible ファクトを使用したい場合は、「setup」または対応するネットワークモジュールをリストに含める必要があります (「smart」を追加すると、Ansible もそれを認識します)。これは、「setup」モジュールへの明示的な呼び出しには影響しませんが、常に 'gather_facts' アクションに影響します (暗黙的または明示的)。" - -#: ../../rst/reference_appendices/config.rst:4185 -msgid "See also :ref:`FACTS_MODULES `" -msgstr "「:ref:`FACTS_MODULES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4193 -msgid "See also :ref:`GALAXY_IGNORE_CERTS `" -msgstr "「:ref:`GALAXY_IGNORE_CERTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4201 -msgid "See also :ref:`GALAXY_ROLE_SKELETON `" -msgstr "「:ref:`GALAXY_ROLE_SKELETON `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4209 -msgid "See also :ref:`GALAXY_ROLE_SKELETON_IGNORE `" -msgstr "「:ref:`GALAXY_ROLE_SKELETON_IGNORE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4217 -msgid "See also :ref:`GALAXY_COLLECTION_SKELETON `" -msgstr "「:ref:`GALAXY_COLLECTION_SKELETON `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4225 -msgid "See also :ref:`GALAXY_COLLECTION_SKELETON_IGNORE `" -msgstr "「:ref:`GALAXY_COLLECTION_SKELETON_IGNORE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4233 -msgid "See also :ref:`GALAXY_SERVER `" -msgstr "「:ref:`GALAXY_SERVER `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4239 -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." -msgstr "コレクションのインストール時に使用する Galaxy サーバーの一覧。値は、サーバーの詳細を定義する config ini ヘッダー ``[galaxy_server.{{item}}]`` に対応します。Galaxy サーバーの定義方法の詳細は、「:ref:`galaxy_server_config`」を参照してください。この一覧のサーバーの順序は、コレクションの解決順序として使用されます。この設定オプションを設定すると、:ref:`galaxy_server` の設定オプションは無視されます。" - -#: ../../rst/reference_appendices/config.rst:4241 -msgid "See also :ref:`GALAXY_SERVER_LIST `" -msgstr "「:ref:`GALAXY_SERVER_LIST `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4249 -msgid "See also :ref:`GALAXY_TOKEN_PATH `" -msgstr "「:ref:`GALAXY_TOKEN_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4255 -msgid "Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputing 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." -msgstr "``ansible-galaxy`` の一部の手順では、特定の表示で、または標準出力 (stdout) をファイルに出力するときに問題を引き起こす可能性のある進行状況ホイールを表示します。この設定オプションは、表示ホイールを表示するかどうかを制御します。デフォルトでは、stdout に tty があると、表示ホイールが表示されます。" - -#: ../../rst/reference_appendices/config.rst:4257 -msgid "See also :ref:`GALAXY_DISPLAY_PROGRESS `" -msgstr "「:ref:`GALAXY_DISPLAY_PROGRESS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4263 -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." -msgstr "Galaxy サーバーからキャッシュされた応答を保存するディレクトリーです。これは ``ansible-galaxy collection install`` コマンドおよび ``download`` コマンドによってのみ使用されます。このディレクトリー内のキャッシュファイルは、誰でも書き込み可能であれば無視されます。" - -#: ../../rst/reference_appendices/config.rst:4265 -msgid "See also :ref:`GALAXY_CACHE_DIR `" -msgstr "「:ref:`GALAXY_CACHE_DIR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4273 -msgid "See also :ref:`GALAXY_DISABLE_GPG_VERIFY `" -msgstr "「:ref:`GALAXY_DISABLE_GPG_VERIFY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4281 -msgid "See also :ref:`GALAXY_GPG_KEYRING `" -msgstr "「:ref:`GALAXY_GPG_KEYRING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4287 -msgid "A list of GPG status codes to ignore during GPG signature verification. See L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) for status code descriptions.If fewer signatures successfully verify the collection than `GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`, signature verification will fail even if all error codes are ignored." -msgstr "GPG 署名の検証中に無視する GPG ステータスコードのリスト。ステータスコードの説明は、L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) を参照してください。コレクションの検証で正常な署名数が `GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` よりも少ない場合には、エラーコードが無視されている場合でも署名の検証に失敗します。" - -#: ../../rst/reference_appendices/config.rst:4289 -msgid "See also :ref:`GALAXY_IGNORE_INVALID_SIGNATURE_STATUS_CODES `" -msgstr "「:ref:`GALAXY_IGNORE_INVALID_SIGNATURE_STATUS_CODES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4295 -msgid "The number of signatures that must be successful during GPG signature verification while installing or verifying collections.This should be a positive integer or all to indicate all signatures must successfully validate the collection.Prepend + to the value to fail if no valid signatures are found for the collection." -msgstr "コレクションのインストールまたは検証中の GPG 署名検証中に成功する必要がある署名の数。これは、正の整数または all の場合、すべての署名がコレクションの検証に成功する必要があることを指定します。有効な署名がコレクションで見つからなかった場合に失敗させるには、+ を値の前につけます。" - -#: ../../rst/reference_appendices/config.rst:4297 -msgid "See also :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT `" -msgstr "「:ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4305 -msgid "See also :ref:`HOST_KEY_CHECKING `" -msgstr "「:ref:`HOST_KEY_CHECKING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4313 -msgid "See also :ref:`HOST_PATTERN_MISMATCH `" -msgstr "「:ref:`HOST_PATTERN_MISMATCH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4321 -msgid "See also :ref:`INTERPRETER_PYTHON `" -msgstr "「:ref:`INTERPRETER_PYTHON `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4330 -msgid "See also :ref:`TRANSFORM_INVALID_GROUP_CHARS `" -msgstr "「:ref:`TRANSFORM_INVALID_GROUP_CHARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4338 -msgid "See also :ref:`INVALID_TASK_ATTRIBUTE_FAILED `" -msgstr "「:ref:`INVALID_TASK_ATTRIBUTE_FAILED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4347 -msgid "See also :ref:`INVENTORY_ANY_UNPARSED_IS_FAILED `" -msgstr "「:ref:`INVENTORY_ANY_UNPARSED_IS_FAILED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4353 -msgid "Toggle to turn on inventory caching.This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`.The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory configuration.This message will be removed in 2.16." -msgstr "切り替えてイベントリーキャッシュをオンにします。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリー設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:4355 -msgid "See also :ref:`INVENTORY_CACHE_ENABLED `" -msgstr "「:ref:`INVENTORY_CACHE_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4361 -msgid "The plugin for caching inventory.This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`.The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration.This message will be removed in 2.16." -msgstr "キャッシュインベントリーのプラグイン。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:4363 -msgid "See also :ref:`INVENTORY_CACHE_PLUGIN `" -msgstr "「:ref:`INVENTORY_CACHE_PLUGIN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4369 -msgid "The inventory cache connection.This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`.The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration.This message will be removed in 2.16." -msgstr "インベントリーキャッシュコネクション。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:4371 -msgid "See also :ref:`INVENTORY_CACHE_PLUGIN_CONNECTION `" -msgstr "「:ref:`INVENTORY_CACHE_PLUGIN_CONNECTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4377 -msgid "The table prefix for the cache plugin.This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`.The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration.This message will be removed in 2.16." -msgstr "キャッシュプラグインの表の接頭辞。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:4379 -msgid "See also :ref:`INVENTORY_CACHE_PLUGIN_PREFIX `" -msgstr "「:ref:`INVENTORY_CACHE_PLUGIN_PREFIX `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4385 -msgid "Expiration timeout for the inventory cache plugin data.This setting has been moved to the individual inventory plugins as a plugin option :ref:`inventory_plugins`.The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration.This message will be removed in 2.16." -msgstr "インベントリーキャッシュプラグインデータの有効期限のタイムアウト。この設定は、プラグインオプション :ref:`inventory_plugins` として個々のインベントリープラグインに移動しました。インベントリーおよびファクトキャッシュ設定から別のオプションを追加する inventory プラグインで、既存の設定も使用できます。このメッセージは 2.16 で削除されます。" - -#: ../../rst/reference_appendices/config.rst:4387 -msgid "See also :ref:`INVENTORY_CACHE_TIMEOUT `" -msgstr "「:ref:`INVENTORY_CACHE_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4395 -msgid "See also :ref:`INVENTORY_ENABLED `" -msgstr "「:ref:`INVENTORY_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4403 -msgid "See also :ref:`INVENTORY_EXPORT `" -msgstr "「:ref:`INVENTORY_EXPORT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4411 -msgid "See also :ref:`INVENTORY_IGNORE_EXTS `" -msgstr "「:ref:`INVENTORY_IGNORE_EXTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4419 -msgid "See also :ref:`INVENTORY_IGNORE_PATTERNS `" -msgstr "「:ref:`INVENTORY_IGNORE_PATTERNS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4428 -msgid "See also :ref:`INVENTORY_UNPARSED_IS_FAILED `" -msgstr "「:ref:`INVENTORY_UNPARSED_IS_FAILED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4436 -msgid "See also :ref:`JINJA2_NATIVE_WARNING `" -msgstr ":ref:`JINJA2_NATIVE_WARNING ` も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4438 -msgid "2.17" -msgstr "2.17" - -#: ../../rst/reference_appendices/config.rst:4439 -msgid "This option is no longer used in the Ansible Core code base." -msgstr "このオプションは、Ansible Core コードベースでは使用されなくなりました。" - -#: ../../rst/reference_appendices/config.rst:4446 -msgid "See also :ref:`MAX_FILE_SIZE_FOR_DIFF `" -msgstr "「:ref:`MAX_FILE_SIZE_FOR_DIFF `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4453 -msgid "See also :ref:`NETWORK_GROUP_MODULES `" -msgstr "「:ref:`NETWORK_GROUP_MODULES `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4459 -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." -msgstr "ファクトは `ansible_facts` 変数内で利用できます。この設定は、主な名前空間で独自の変数としてプッシュされます。`ansible_facts` ディクショナリー内とは異なり、これには `ansible_` の接頭辞があります。" - -#: ../../rst/reference_appendices/config.rst:4461 -msgid "See also :ref:`INJECT_FACTS_AS_VARS `" -msgstr "「:ref:`INJECT_FACTS_AS_VARS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4467 -msgid "List of extensions to ignore when looking for modules to loadThis is for rejecting script and binary module fallback extensions" -msgstr "読み込むモジュールを探すときに無視する拡張機能のリスト。これは、スクリプトおよびバイナリーモジュールのフォールバック拡張機能を拒否するためのものです。" - -#: ../../rst/reference_appendices/config.rst:4469 -msgid "See also :ref:`MODULE_IGNORE_EXTS `" -msgstr "「:ref:`MODULE_IGNORE_EXTS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4477 -msgid "See also :ref:`OLD_PLUGIN_CACHE_CLEARING `" -msgstr "「:ref:`OLD_PLUGIN_CACHE_CLEARING `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4484 -msgid "See also :ref:`PARAMIKO_HOST_KEY_AUTO_ADD `" -msgstr "「:ref:`PARAMIKO_HOST_KEY_AUTO_ADD `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4491 -msgid "See also :ref:`PARAMIKO_LOOK_FOR_KEYS `" -msgstr "「:ref:`PARAMIKO_LOOK_FOR_KEYS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4499 -msgid "See also :ref:`PERSISTENT_CONTROL_PATH_DIR `" -msgstr "「:ref:`PERSISTENT_CONTROL_PATH_DIR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4507 -msgid "See also :ref:`PERSISTENT_CONNECT_TIMEOUT `" -msgstr "「:ref:`PERSISTENT_CONNECT_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4515 -msgid "See also :ref:`PERSISTENT_CONNECT_RETRY_TIMEOUT `" -msgstr "「:ref:`PERSISTENT_CONNECT_RETRY_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4523 -msgid "See also :ref:`PERSISTENT_COMMAND_TIMEOUT `" -msgstr "「:ref:`PERSISTENT_COMMAND_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4531 -msgid "See also :ref:`PLAYBOOK_DIR `" -msgstr "「:ref:`PLAYBOOK_DIR `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4539 -msgid "See also :ref:`PLAYBOOK_VARS_ROOT `" -msgstr "「:ref:`PLAYBOOK_VARS_ROOT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4548 -msgid "See also :ref:`PYTHON_MODULE_RLIMIT_NOFILE `" -msgstr "「:ref:`PYTHON_MODULE_RLIMIT_NOFILE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4556 -msgid "See also :ref:`RETRY_FILES_ENABLED `" -msgstr "「:ref:`RETRY_FILES_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4562 -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." -msgstr "これにより、Playbook が失敗し、再試行ファイルが有効になっている場合に、Ansible が .retry ファイルを保存するパスが設定されます。このファイルは、実行するたびに、すべてのプレイで失敗したホストのリストで上書きされます。" - -#: ../../rst/reference_appendices/config.rst:4564 -msgid "See also :ref:`RETRY_FILES_SAVE_PATH `" -msgstr "「:ref:`RETRY_FILES_SAVE_PATH `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4572 -msgid "See also :ref:`RUN_VARS_PLUGINS `" -msgstr "「:ref:`RUN_VARS_PLUGINS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4580 -msgid "See also :ref:`SHOW_CUSTOM_STATS `" -msgstr "「:ref:`SHOW_CUSTOM_STATS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4586 -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." -msgstr "このフィルターのリストは、変数をテンプレート化するときに「型変換」を回避します。たとえば、JSON 文字列のリストやディレクトリーへの変換を回避したい場合に便利です。" - -#: ../../rst/reference_appendices/config.rst:4588 -msgid "See also :ref:`STRING_TYPE_FILTERS `" -msgstr "「:ref:`STRING_TYPE_FILTERS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4594 -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." -msgstr "Ansible 自体を実行している (管理対象ホストではない) システムの潜在的な問題に関連する警告を無効にすることができます。これには、サードパーティーのパッケージに関する警告や、可能であれば解決する必要のあるその他の条件が含まれる場合があります。" - -#: ../../rst/reference_appendices/config.rst:4596 -msgid "See also :ref:`SYSTEM_WARNINGS `" -msgstr "「:ref:`SYSTEM_WARNINGS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4604 -msgid "See also :ref:`TAGS_RUN `" -msgstr "「:ref:`TAGS_RUN `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4612 -msgid "See also :ref:`TAGS_SKIP `" -msgstr "「:ref:`TAGS_SKIP `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4618 -msgid "Set the maximum time (in seconds) that a task can run for.If set to 0 (the default) there is no timeout." -msgstr "タスクを実行する最大時間 (秒単位) を設定します。0 (デフォルト) に設定するとタイムアウトはありません。" - -#: ../../rst/reference_appendices/config.rst:4620 -msgid "See also :ref:`TASK_TIMEOUT `" -msgstr "「:ref:`TASK_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4626 -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." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認する最大回数。この制限に達すると、まだ実行中のワーカープロセスはすべて終了します。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:4628 -msgid "See also :ref:`WORKER_SHUTDOWN_POLL_COUNT `" -msgstr "「:ref:`WORKER_SHUTDOWN_POLL_COUNT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4634 -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." -msgstr "Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認するときに、ポーリングループ間でスリープする秒数。これは内部使用のみです。" - -#: ../../rst/reference_appendices/config.rst:4636 -msgid "See also :ref:`WORKER_SHUTDOWN_POLL_DELAY `" -msgstr "「:ref:`WORKER_SHUTDOWN_POLL_DELAY `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4644 -msgid "See also :ref:`USE_PERSISTENT_CONNECTIONS `" -msgstr "「:ref:`USE_PERSISTENT_CONNECTIONS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4652 -msgid "See also :ref:`VARIABLE_PLUGINS_ENABLED `" -msgstr "「:ref:`VARIABLE_PLUGINS_ENABLED `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4660 -msgid "See also :ref:`VARIABLE_PRECEDENCE `" -msgstr "「:ref:`VARIABLE_PRECEDENCE `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4666 -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." -msgstr "Ansible の非同期タスク (「非同期アクションおよびポーリング」で説明) の場合、これは、Ansible が生成するタスクが Windows システムで使用される名前付きパイプに接続するのを待機する時間 (秒単位) です。デフォルトは 5 秒です。これは、低速のシステムや高負荷のシステムでは低すぎる可能性があります。これは、非同期コマンドを実行できる合計時間ではありませんが、非同期コマンドの開始を待機する別のタイムアウトです。タスクは、パイプに接続された後にのみ async_timeout に対してタイムアウトが開始するため、タスクの全体的な最大期間は、ここで指定された分だけ延長されます。" - -#: ../../rst/reference_appendices/config.rst:4668 -msgid "See also :ref:`WIN_ASYNC_STARTUP_TIMEOUT `" -msgstr "「:ref:`WIN_ASYNC_STARTUP_TIMEOUT `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4674 -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." -msgstr "YAML または JSON、あるいはこれらの Vault バージョンである必要がある「変数」ファイルを探すときは、これらすべての拡張子を確認してください。これは、vars_files、include_vars、inventory、vars プラグインなどに影響します。" - -#: ../../rst/reference_appendices/config.rst:4676 -msgid "See also :ref:`YAML_FILENAME_EXTENSIONS `" -msgstr "「:ref:`YAML_FILENAME_EXTENSIONS `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4684 -msgid "See also :ref:`NETCONF_SSH_CONFIG `" -msgstr "「:ref:`NETCONF_SSH_CONFIG `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4690 -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." -msgstr "モジュールパラメーター値が文字列に変換されるときに実行するアクション (これは変数には影響しません)。文字列パラメーターの場合、「1.00」、「['a', 'b',]」、「yes」、「y」などの値は、完全に引用されていない限り、YAML パーサーにより変換されます。有効なオプションは、「error」、「warn」、および「ignore」です。2.8 以降、このオプションのデフォルトは「warn」ですが、2.12では「error」に変更されます。" - -#: ../../rst/reference_appendices/config.rst:4692 -msgid "See also :ref:`STRING_CONVERSION_ACTION `" -msgstr "「:ref:`STRING_CONVERSION_ACTION `」も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4700 -msgid "See also :ref:`VALIDATE_ACTION_GROUP_METADATA `" -msgstr ":ref:`VALIDATE_ACTION_GROUP_METADATA ` も参照してください。" - -#: ../../rst/reference_appendices/config.rst:4708 -msgid "See also :ref:`VERBOSE_TO_STDERR `" -msgstr "「:ref:`VERBOSE_TO_STDERR `」も参照してください。" - -#: ../../rst/reference_appendices/faq.rst:4 -msgid "Frequently Asked Questions" -msgstr "よくある質問 (FAQ)" - -#: ../../rst/reference_appendices/faq.rst:6 -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 `_. 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 `_ and placed them in :ref:`collections `. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository `_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core`` (it was briefly called ``ansible-base`` for version 2.10)." -msgstr "2019 年 7 月、コレクションが `今後の Ansible コンテンツ配布 `_ になることが発表されました。コレクションは、Playbook、ロール、モジュール、およびプラグインを含む Ansible コンテンツの配布形式です。Ansible 2.9 では、コレクションのサポートを追加しました。Ansible 2.10 では、`ansible/ansible のメインリポジトリーからほとんどモジュールを取り出して `_、そのモジュールを :ref:`コレクション ` に置きました。コレクションは、Ansible チーム、Ansible コミュニティー、または Ansible パートナーによって維持されます。`ansible/ansible リポジトリー `_ には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能および関数のコードが含まれています。このコードは ``ansible-core`` とも呼ばれます (バージョン 2.10 の場合は ``ansible-base`` と呼ばれています)。" - -#: ../../rst/reference_appendices/faq.rst:15 -msgid "To learn more about using collections, see :ref:`collections`." -msgstr "コレクションの使用に関する詳細は、「:ref:`collections`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:16 -msgid "To learn more about developing collections, see :ref:`developing_collections`." -msgstr "コレクション開発に関する詳細は、「:ref:`developing_collections`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:17 -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." -msgstr "既存のコレクションへの貢献の詳細については、個々のコレクションリポジトリーでガイドラインを参照するか、Ansible が管理するコレクションのいずれかに貢献する方法を「:ref:`contributing_maintained_collections`」で参照してください。" - -#: ../../rst/reference_appendices/faq.rst:22 -msgid "Where did this specific module go?" -msgstr "この特定のモジュールはどこに移されましたか" - -#: ../../rst/reference_appendices/faq.rst:24 -msgid "IF you are searching for a specific module, you can check the `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 `_ or ask on one of our :ref:`chat channels `." -msgstr "特定のモジュールを検索する場合は、`runtime.yml `_ ファイルをチェックできます。このファイルには、メインの ansible/ansible リポジトリーから抽出した各モジュールの最初の宛先がリストされています。その後、いくつかのモジュールが再び移動しました。`Ansible Galaxy `_ で検索することもできますし、いずれかの :ref:`chat channels ` で尋ねることもできます。" - -#: ../../rst/reference_appendices/faq.rst:29 -msgid "How can I speed up Ansible on systems with slow disks?" -msgstr "ディスクの速度が遅いシステムで、Ansible を高速化するにはどうすればいいですか" - -#: ../../rst/reference_appendices/faq.rst:31 -msgid "Ansible may feel sluggish on systems with slow disks, such as Raspberry PI. See `Ansible might be running slow if libyaml is not available `_ for hints on how to improve this." -msgstr "Ansible は、Raspberry PI など、ディスクの速度が遅いシステムでスラグが発生する場合があります。これを改善する方法は、`Ansible might be running slow if libyaml is not available `_ を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:38 -msgid "How can I set the PATH or any other environment variable for a task or entire play?" -msgstr "タスクやプレイ全体に PATH またはその他の環境変数をどのように設定すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:40 -msgid "Setting environment variables can be done with the `environment` keyword. It can be used at the task or other levels in the play." -msgstr "環境変数の設定は、`environment` キーワードで実行できます。これは、プレイ内のタスクや他のレベルで使用できます。" - -#: ../../rst/reference_appendices/faq.rst:56 -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." -msgstr "2.0.1 以降で、``gather_facts`` の設定タスクは、プレイからの環境ディレクティブも継承します。これがプレイレベルで設定されている場合は、``|default`` フィルターを使用したエラーの回避が必要になる場合があります。" - -#: ../../rst/reference_appendices/faq.rst:61 -msgid "How do I handle different machines needing different user accounts or ports to log in with?" -msgstr "異なるユーザーアカウントまたはポートでログインする必要のある各種マシンをどのように処理すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:63 -msgid "Setting inventory variables in the inventory file is the easiest way." -msgstr "インベントリーファイルにインベントリー変数を設定する方法が最も簡単です。" - -#: ../../rst/reference_appendices/faq.rst:65 -msgid "For instance, suppose these hosts have different usernames and ports:" -msgstr "たとえば、以下では、ホストに異なるユーザー名とポートが指定されています。" - -#: ../../rst/reference_appendices/faq.rst:73 -msgid "You can also dictate the connection type to be used, if you want:" -msgstr "任意で、使用する接続タイプを指定できます。" - -#: ../../rst/reference_appendices/faq.rst:82 -msgid "You may also wish to keep these in group variables instead, or file them in a group_vars/ file. See the rest of the documentation for more information about how to organize variables." -msgstr "上記の値を、代わりにグループ変数や group_vars/ ファイルに保持できます。変数を整理する方法は、本ガイドの他のセクションを参照してください。" - -#: ../../rst/reference_appendices/faq.rst:88 -msgid "How do I get ansible to reuse connections, enable Kerberized SSH, or have Ansible pay attention to my local SSH config file?" -msgstr "Ansible を使用して接続を再利用したり、Kerberos を設定した SSH を有効にしたり、Ansible がローカルの SSH 設定を使用するにはどうしたら良いですか" - -#: ../../rst/reference_appendices/faq.rst:90 -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." -msgstr "設定ファイルのデフォルトの接続タイプを ``ssh`` に切り替えるか、Python Paramiko ライブラリーの代わりに、``-c ssh`` で、接続にネイティブの OpenSSH を使用してください。Ansible 1.2.1 以降では、OpenSSH が新しく、オプションとして ControlPersist をサポートする場合にはデフォルトで ``ssh`` を使用します。" - -#: ../../rst/reference_appendices/faq.rst:94 -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." -msgstr "Paramiko は使用を開始するときには便利ですが、OpenSSH のタイプでは多数の詳細オプションを利用できます。OpenSSH の接続タイプを使用する場合には、ControlPersist をサポートできる新しいマシンから Ansible を実行してください。古いクライアントは引き続き管理できます。RHEL 6、CentOS 6、SLES 10、または SLES 11 を使用している場合は、OpenSSH のバージョンが若干古いため、以前のノードを管理している場合でも、Fedora または openSUSE クライアントからの管理を検討するか、paramiko を使用してください。" - -#: ../../rst/reference_appendices/faq.rst:99 -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." -msgstr "Paramiko は、これらのエンタープライズオペレーティングシステムに Ansible を最初にインストールしている場合と同じようにデフォルトのままとなっており、新規ユーザーによって使用しやすくなっています。" - -#: ../../rst/reference_appendices/faq.rst:104 -msgid "How do I configure a jump host to access servers that I have no direct access to?" -msgstr "直接アクセス権のないサーバーにジャンプホストを使用してアクセスできるように設定するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:106 -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:" -msgstr "``ansible_ssh_common_args`` インベントリー変数に ``ProxyCommand`` を設定することができます。該当のホストに接続したときに、この変数に指定した引数は、sftp/scp/ssh コマンドラインに追加されます。次のインベントリーグループについて考えてみます。" - -#: ../../rst/reference_appendices/faq.rst:117 -msgid "You can create `group_vars/gatewayed.yml` with the following contents:" -msgstr "以下の内容で `group_vars/gatewayed.yml` を作成できます。" - -#: ../../rst/reference_appendices/faq.rst:123 -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``.)" -msgstr "Ansible は、``gatewayed`` グループのホストに接続しようとすると、コマンドラインに 3 つの引数を追加します。(``ansible.cfg`` からの ``ssh_args`` に加えて、上記の引数が使用されるため、``ansible_ssh_common_args`` のグローバル ``ControlPersist`` 設定を繰り返す必要はありません)。" - -#: ../../rst/reference_appendices/faq.rst:128 -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." -msgstr "``ssh -W`` は、OpenSSH 5.4 以降でのみ利用できます。以前のバージョンでは、bastion ホストで ``nc %h:%p`` を実行するか、同等のコマンドを実行する必要があります。" - -#: ../../rst/reference_appendices/faq.rst:132 -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``." -msgstr "Ansible の以前のバージョンでは、``~/.ssh/config`` のホスト 1 台または複数台に適切な ``ProxyCommand`` を設定するか、``ansible.cfg`` に ``ssh_args`` をグローバルに設定する必要がありました。" - -#: ../../rst/reference_appendices/faq.rst:139 -msgid "How do I get Ansible to notice a dead target in a timely manner?" -msgstr "Ansible がダウンしているターゲットを適宜検出できるようにするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:141 -msgid "You can add ``-o ServerAliveInterval=NumberOfSeconds`` with the ``ssh_args`` parameter in `SSH connection plugin `_. 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." -msgstr "`SSH connection plugin ` から、``ssh_args`` パラメーターに指定して ``-o ServerAliveInterval=NumberOfSeconds`` を追加できます。このオプションがないと、SSH と Ansible は TCP 接続がタイムアウトになるまで待機します。別の解決方法は、``ServerAliveInterval`` をグローバルの SSH 設定に追加することです。``ServerAliveInterval`` に適した値は、ユーザーが決定します。ただし、SSH のデフォルトは ``ServerAliveCountMax=3`` であるため、SSH セッションの終了前に設定した値が 3 倍になる点に注意してください。" - -#: ../../rst/reference_appendices/faq.rst:149 -msgid "How do I speed up run of ansible for servers from cloud providers (EC2, openstack,.. )?" -msgstr "クラウドプロバイダー (EC2、openstack など) からのサーバーで Ansible の実行を高速化するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:151 -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." -msgstr "ラップトップからクラウドプロバイダーのマシンのフリートを管理しようとしないでください。代わりに、最初にこのクラウドプロバイダー内の管理ノードに接続し、そこから Ansible を実行します。" - -#: ../../rst/reference_appendices/faq.rst:157 -msgid "How do I handle not having a Python interpreter at /usr/bin/python on a remote machine?" -msgstr "リモートマシンの /usr/bin/python に Python インタープリターを配置せずに対応するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:159 -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." -msgstr "Ansible モジュールはどの言語でも記述できますが、Ansible の機能を司るコアモジュールなど、Ansible モジュールの多くは Python で記述されています。" - -#: ../../rst/reference_appendices/faq.rst:162 -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." -msgstr "デフォルトでは、Ansible は、Python2 のバージョン 2.6 以降または Python3 の 3.5 以降のリモートマシンの :command:`/usr/bin/python` を検出できます。" - -#: ../../rst/reference_appendices/faq.rst:165 -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." -msgstr "ホストにインベントリー変数 ``ansible_python_interpreter`` を設定すると、Ansible に対して、代わりに Python インタープリターをこのインベントリー変数の値に自動で置き換えるように指示を出します。このように、お使いのシステムの :command:`/usr/bin/python` が互換性のある Python インタープリターを指定していない場合は、使用する Python を指定できます。" - -#: ../../rst/reference_appendices/faq.rst:170 -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 through ``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 through ``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 `_ so that the incompatibility can be fixed in a future release." -msgstr "プラットフォームによっては、デフォルトで Python3 のみがインストールされている場合があります。:command:`/usr/bin/python` としてインストールされていない場合は、``ansible_python_interpreter`` を介してインタープリターへのパスを設定する必要があります。コアモジュールの多くが Python 3 と連携しますが、いくつかの特殊用途のモジュールは動作しないかもしれないし、特殊なケースでバグが発生するかもしれません。一時的な回避策として、管理対象ホストに Python 2をインストールし、``ansible_python_interpreter`` からその Python を使用するように Ansible を構成できます。モジュールのドキュメントに Python 2 が必要あるとの記載がない場合は、今後このリリースで非互換性の問題が解決されるように、`bug tracker `_ で、バグを報告できます。" - -#: ../../rst/reference_appendices/faq.rst:179 -msgid "Do not replace the shebang lines of your python modules. Ansible will do this for you automatically at deploy time." -msgstr "Python モジュールのシバン行は置き換えないでください。デプロイ時に Ansible が自動でこれを行います。" - -#: ../../rst/reference_appendices/faq.rst:181 -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." -msgstr "また、これは、ruby などのすべてのインタープリター (ruby: ``ansible_ruby_interpreter``、perl: ``ansible_perl_interpreter`` など) で機能するため、任意のスクリプト言語で記述したカスタムモジュールにこれを使用して、インタープリターの場所を管理できます。" - -#: ../../rst/reference_appendices/faq.rst:184 -msgid "Keep in mind that if you put ``env`` in your module shebang line (``#!/usr/bin/env ``), this facility will be ignored so you will be at the mercy of the remote `$PATH`." -msgstr "モジュールのシバンの行 (``#!/usr/bin/env ``) に ``env`` を挿入すると、この機能は無視され、リモートの `$PATH` の設定が使用されます。" - -#: ../../rst/reference_appendices/faq.rst:190 -msgid "How do I handle the package dependencies required by Ansible package dependencies during Ansible installation ?" -msgstr "Ansible インストール中に Ansible パッケージに必要な依存関係にどのように対応すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:192 -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:196 -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." -msgstr "このような依存関係の問題を解決するには、OS ネイティブのパッケージマネージャー (`yum`、`dnf`、`apt`、またはパッケージのインストールガイドに記載のもの) を使用して必要なパッケージをインストールしないといけない場合があります。" - -#: ../../rst/reference_appendices/faq.rst:199 -msgid "Refer to the documentation of the respective package for such dependencies and their installation methods." -msgstr "このような依存関係とそのインストール方法については、各パッケージのドキュメントを参照してください。" - -#: ../../rst/reference_appendices/faq.rst:202 -msgid "Common Platform Issues" -msgstr "一般的なプラットフォームの問題" - -#: ../../rst/reference_appendices/faq.rst:205 -msgid "What customer platforms does Red Hat support?" -msgstr "Red Hat では、どのような顧客のプラットフォームをサポートしていますか" - -#: ../../rst/reference_appendices/faq.rst:207 -msgid "A number of them! For a definitive list please see this `Knowledge Base article `_." -msgstr "その数は多数です。具体的な一覧は、`ナレッジベースの記事 `_ を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:210 -msgid "Running in a virtualenv" -msgstr "virtualenv での実行" - -#: ../../rst/reference_appendices/faq.rst:212 -msgid "You can install Ansible into a virtualenv on the controller quite simply:" -msgstr "コントローラーの virtualenv に Ansible を簡単にインストールできます。" - -#: ../../rst/reference_appendices/faq.rst:220 -msgid "If you want to run under Python 3 instead of Python 2 you may want to change that slightly:" -msgstr "Python 2 ではなく Python 3 で実行する場合は、以下のように変更する場合があります。" - -#: ../../rst/reference_appendices/faq.rst:228 -msgid "If you need to use any libraries which are not available through 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:232 -msgid "When you create the virtualenv, specify ``--system-site-packages`` to make use of any libraries installed in the system's Python:" -msgstr "virtualenv の作成時に、``--system-site-packages`` を指定して、お使いのシステムの Python にインストールされているライブラリーを使用します。" - -#: ../../rst/reference_appendices/faq.rst:239 -msgid "Copy those files in manually from the system. For instance, for SELinux bindings you might do:" -msgstr "システムから手動でこれらのファイルをコピーします。たとえば、SELinux バインディングでは、以下を行うことができます。" - -#: ../../rst/reference_appendices/faq.rst:249 -msgid "Running on macOS" -msgstr "macOS での実行" - -#: ../../rst/reference_appendices/faq.rst:251 -msgid "When executing Ansible on a system with macOS as a controller machine one might encounter the following error:" -msgstr "コントローラーマシンとして macOS を使用しているシステムで Ansible を実行すると、次のエラーが発生する場合があります。" - -#: ../../rst/reference_appendices/faq.rst:254 -msgid "+[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. ERROR! A worker was found in a dead state" -msgstr "+[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. ERROR! A worker was found in a dead state" - -#: ../../rst/reference_appendices/faq.rst:257 -msgid "In general the recommended workaround is to set the following environment variable in your shell:" -msgstr "一般的に推奨される回避策は、シェルに次の環境変数を設定することです。" - -#: ../../rst/reference_appendices/faq.rst:265 -msgid "Running on BSD" -msgstr "BSD での実行" - -#: ../../rst/reference_appendices/faq.rst:267 -msgid ":ref:`working_with_bsd`" -msgstr ":ref:`working_with_bsd`" - -#: ../../rst/reference_appendices/faq.rst:271 -msgid "Running on Solaris" -msgstr "Solaris での実行" - -#: ../../rst/reference_appendices/faq.rst:273 -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:" -msgstr "デフォルトでは Solaris 10 以前では POSIX 以外のシェルを実行しますが、Ansible が使用するデフォルトの tmp ディレクトリー (:file:`~/.ansible/tmp`) を正しく展開しません。Solaris マシンでモジュールの問題が発生する場合には、上記が問題の可能性が高いです。回避策はいくつかあります。" - -#: ../../rst/reference_appendices/faq.rst:277 -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`, :ref:`fish shell`, and :ref:`Powershell`). For example, in the ansible config file you can set:" -msgstr "使用するシェル (:ref:`C shell`、:ref:`fish shell`、および :ref:`Powershell` のプラグインのドキュメントを参照) で正しく展開されるパスに ``remote_tmp`` を設定します。設定する ansible 設定ファイルで、以下を指定します。" - -#: ../../rst/reference_appendices/faq.rst:285 -msgid "In Ansible 2.5 and later, you can also set it per-host in inventory like this:" -msgstr "Ansible 2.5 以降では、以下のようにインベントリーでホストごとに設定することも可能です。" - -#: ../../rst/reference_appendices/faq.rst:291 -msgid "You can set :ref:`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` を、POSIX の互換性のあるパスに設定します。たとえば、多数の Solaris ホストでは POSIX シェルが、:file:`/usr/xpg4/bin/sh` に配置されているため、インベントリーにこの値を以下のように設定できます。" - -#: ../../rst/reference_appendices/faq.rst:299 -msgid "(bash, ksh, and zsh should also be POSIX compatible if you have any of those installed)." -msgstr "(bash、ksh、または zsh のいずれかがインストールされている場合には、これも POSIX の互換性が必要です)。" - -#: ../../rst/reference_appendices/faq.rst:302 -msgid "Running on z/OS" -msgstr "z/OS での実行" - -#: ../../rst/reference_appendices/faq.rst:304 -msgid "There are a few common errors that one might run into when trying to execute Ansible on z/OS as a target." -msgstr "z/OS でターゲットとして Ansible を実行しようとすると、複数の共通のエラーが発生する可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:306 -msgid "Version 2.7.6 of python for z/OS will not work with Ansible because it represents strings internally as EBCDIC." -msgstr "z/OS 向けの Python バージョン 2.7.6 は、内部で文字列を EBCDIC として表現するため、Ansible では機能しない。" - -#: ../../rst/reference_appendices/faq.rst:308 -msgid "To get around this limitation, download and install a later version of `python for z/OS `_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work." -msgstr "この制限を回避するには、文字列を ASCII で表現する `python for z/OS `_ (2.7.13 または 3.6.1) をダウンロードしてインストールしてください。バージョン 2.7.13 では機能することが確認されています。" - -#: ../../rst/reference_appendices/faq.rst:310 -msgid "When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode through sftp however execution of python fails with" -msgstr "`/etc/ansible/ansible.cfg` で ``pipelining = False`` と指定されている場合、以下により、Ansible モジュールは Python の実行エラーが何であっても、sftp 経由でバイナリーモードで転送される。" - -#: ../../rst/reference_appendices/faq.rst:313 -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:315 -msgid "To fix it set ``pipelining = True`` in `/etc/ansible/ansible.cfg`." -msgstr "これを修正するには、`/etc/ansible/ansible.cfg` に ``pipelining = True`` を設定します。" - -#: ../../rst/reference_appendices/faq.rst:317 -msgid "Python interpret cannot be found in default location ``/usr/bin/python`` on target host." -msgstr "Python インタープリターがターゲットホストのデフォルトの場所 ``/usr/bin/python`` で検出できない。" - -#: ../../rst/reference_appendices/faq.rst:320 -msgid "/usr/bin/python: EDC5129I No such file or directory" -msgstr "/usr/bin/python: EDC5129I No such file or directory" - -#: ../../rst/reference_appendices/faq.rst:322 -msgid "To fix this set the path to the python installation in your inventory like so::" -msgstr "これを解決するには、以下のようにインベントリーでパスを Python インストールに設定してください。" - -#: ../../rst/reference_appendices/faq.rst:326 -msgid "zos1 ansible_python_interpreter=/usr/lpp/python/python-2017-04-12-py27/python27/bin/python" -msgstr "zos1 ansible_python_interpreter=/usr/lpp/python/python-2017-04-12-py27/python27/bin/python" - -#: ../../rst/reference_appendices/faq.rst:328 -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:331 -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:333 -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``:" -msgstr "z/OS では、gnu bash から python を実行する必要があります。gnu bash が ``/usr/lpp/bash`` にインストールされている場合は、インベントリーで ``ansible_shell_executable`` を指定して修正できます。" - -#: ../../rst/reference_appendices/faq.rst:341 -msgid "Running under fakeroot" -msgstr "fakeroot 下で実行" - -#: ../../rst/reference_appendices/faq.rst:343 -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)." -msgstr "``fakeroot`` は、デフォルトでは完全なシステムも POSIX 準拠のシステムも作成しないため、いくつかの問題が発生します。Ansible が使用するデフォルトの tmp ディレクトリー (:file:`~/.ansible/tmp`) を正しく展開しないことがわかっています。モジュール障害が発生している場合は、これが問題である可能性があります。簡単な回避策は、正しく展開されるパスに ``remote_tmp`` を設定することです (詳細については、使用している shell プラグインのドキュメントを参照してください)。" - -#: ../../rst/reference_appendices/faq.rst:348 -msgid "For example, in the ansible config file (or through environment variable) you can set:" -msgstr "設定する ansible 設定ファイルで (または環境変数を介して)、以下を指定します。" - -#: ../../rst/reference_appendices/faq.rst:359 -msgid "What is the best way to make content reusable/redistributable?" -msgstr "コンテンツを再利用/再配信できるようにする最適な方法にはどんなものがありますか" - -#: ../../rst/reference_appendices/faq.rst:361 -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." -msgstr "Playbook ドキュメントの「ロール」の情報をまだ確認していない場合は、一読してください。Playbook のコンテンツを自己完結型にし、git submodules などと連携させて、他とのコンテンツ共有が容易になります。" - -#: ../../rst/reference_appendices/faq.rst:364 -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:369 -msgid "Where does the configuration file live and what can I configure in it?" -msgstr "設定ファイルの配置場所はどこですか。または、どのように設定すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:372 -msgid "See :ref:`intro_configuration`." -msgstr "「:ref:`intro_configuration`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:377 -msgid "How do I disable cowsay?" -msgstr "cowsay はどのように無効化すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:379 -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:" -msgstr "cowsay がインストールされている場合は、Playbook を実行すると、Ansible がすべてを引き受けて処理します。プロフェッショナルな cowsay のない環境で作業する場合は、cowsay をアンインストールするか、``ansible.cfg`` に ``nocows=1`` を設定するか、:envvar:`ANSIBLE_NOCOWS` の環境変数を設定します。" - -#: ../../rst/reference_appendices/faq.rst:390 -msgid "How do I see a list of all of the ansible\\_ variables?" -msgstr "ansible\\_ 変数一覧を確認するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:392 -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:" -msgstr "Ansible はデフォルトで、管理対象のマシンの「ファクト」を収集し、このファクトには Playbook またはテンプレートでアクセスできます。あるマシンで利用可能なファクトの一覧を表示するには、``setup`` モジュールを ad-hoc アクションとして実行できます。" - -#: ../../rst/reference_appendices/faq.rst:400 -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'." -msgstr "これにより、特定のホストで利用可能な全ファクトのディクショナリーが出力されます。ページャーの出力をパイプする場合は、インベントリー変数や内部の「magic」変数は含まれません。「ファクト」以外の情報が必要な場合は、次の質問を確認してください。" - -#: ../../rst/reference_appendices/faq.rst:408 -msgid "How do I see all the inventory variables defined for my host?" -msgstr "ホストに定義されたインベントリー変数をすべて確認するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:410 -msgid "By running the following command, you can see inventory variables for a host:" -msgstr "以下のコマンドを実行すると、ホストのインベントリー変数を確認できます。" - -#: ../../rst/reference_appendices/faq.rst:420 -msgid "How do I see all the variables specific to my host?" -msgstr "ホスト固有の全変数を確認するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:422 -msgid "To see all host specific variables, which might include facts and other sources:" -msgstr "ホスト固有の変数をすべて確認するには以下を実行します (ファクトや他のソースが含まれる可能性があります)。" - -#: ../../rst/reference_appendices/faq.rst:428 -msgid "Unless you are using a fact cache, you normally need to use a play that gathers facts first, for facts included in the task above." -msgstr "ファクトキャッシュを使用していない限り、上記のタスクに含まれるファクトについては、通常、先にファクトを収集するプレイを使用する必要があります。" - -#: ../../rst/reference_appendices/faq.rst:434 -msgid "How do I loop over a list of hosts in a group, inside of a template?" -msgstr "テンプレート内のグループに含まれるホストの一覧をループするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:436 -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:" -msgstr "非常に一般的なパターンでは、ホストグループ内でホストのリストを反復処理することです。おそらく、テンプレート設定ファイルにサーバーの一覧を入力します。これを行うには、次のように、テンプレートで「$ groups」ディクショナリーにアクセスするだけです。" - -#: ../../rst/reference_appendices/faq.rst:445 -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:454 -msgid "Then you can use the facts inside your template, like this:" -msgstr "次に、以下のように、テンプレート内のファクトを使用できます。" - -#: ../../rst/reference_appendices/faq.rst:465 -msgid "How do I access a variable name programmatically?" -msgstr "プログラムで変数名にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:467 -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 through a role parameter or other input. Variable names can be built by adding strings together using \"~\", like so:" -msgstr "たとえば、任意のインターフェースの ipv4 アドレスを取得する必要があるかもしれません。そこでは、使用されるインターフェースがロールパラメーターまたは他の入力を介して提供される場合があります。変数名は、次のように「~」を使用して文字列を一緒に追加することで作成できます。" - -#: ../../rst/reference_appendices/faq.rst:474 -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." -msgstr "それは、変数の名前空間全体のディクショナリーであるため、hostvars 全体をチェックするにはコツが必要です。``inventory_hostname`` はマジック変数で、ホストループでループを行う現在のホストを指定します。" - -#: ../../rst/reference_appendices/faq.rst:477 -msgid "In the example above, if your interface names have dashes, you must replace them with underscores:" -msgstr "上記の例では、インターフェース名にダッシュが含まれている場合は、アンダースコアに置き換える必要があります。" - -#: ../../rst/reference_appendices/faq.rst:483 -msgid "Also see dynamic_variables_." -msgstr "「dynamic_variables_」も参照してください。" - -#: ../../rst/reference_appendices/faq.rst:489 -msgid "How do I access a group variable?" -msgstr "グループ変数にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:491 -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." -msgstr "技術的には、Ansible は実際にはグループを直接使用しません。グループはホスト選択のラベルであり、変数を一括で割り当てる手段を提供します。グループは第一級のエンティティーではなく、Ansible はホストとタスクのみを考慮します。" - -#: ../../rst/reference_appendices/faq.rst:494 -msgid "That said, you could just access the variable by selecting a host that is part of that group, see first_host_in_a_group_ below for an example." -msgstr "ただし、対象のグループに含まれるホストを選択すると、変数にアクセスできます。例については、以下の「first_host_in_a_group_」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:500 -msgid "How do I access a variable of the first host in a group?" -msgstr "グループ内の最初のホストの変数にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:502 -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 AWX or the :ref:`Red Hat Ansible Automation Platform `, it will use database order, so this isn't a problem even if you are using cloud based inventory scripts)." -msgstr "webservers グループの最初の webserver の IP アドレスが必要な場合にはどうすれば良いですか。それも行うことができます。動的インベントリーを使用している場合は、どのホストが「最初」であるかが一貫していない可能性があるため、インベントリーが静的で予測可能でない限り、実行しないようにしてください (AWX または :ref:`Red Hat Ansible Automation Platform ` を使用している場合は、データベースの順序を使用するため、クラウドベースのインベントリースクリプトを使用している場合でも、これは問題になりません)。" - -#: ../../rst/reference_appendices/faq.rst:507 -msgid "Anyway, here's the trick:" -msgstr "以下に方法を示します。" - -#: ../../rst/reference_appendices/faq.rst:513 -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:" -msgstr "webserver グループの最初のマシンのホスト名を取得している点に注意してください。テンプレートでこれを実行する場合は、Jinja2 '#set' ディレクティブを使用して簡素化するか、Playbook の場合は set_fact を使用することも可能です。" - -#: ../../rst/reference_appendices/faq.rst:522 -msgid "Notice how we interchanged the bracket syntax for dots -- that can be done anywhere." -msgstr "ドットの代わりに括弧の構文を使用している点に注意してください。これはどこでも使用できます。" - -#: ../../rst/reference_appendices/faq.rst:527 -msgid "How do I copy files recursively onto a target host?" -msgstr "ターゲットホストにファイルを再帰的にコピーするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:529 -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." -msgstr "``copy`` モジュールには再帰的なパラメーターがありますが、多数のファイルにより効率的な場合は、``synchronize`` モジュールを参照してください。``synchronize`` モジュールは rsync をラップします。これらの両方のモジュールの情報は、モジュールインデックスを参照してください。" - -#: ../../rst/reference_appendices/faq.rst:535 -msgid "How do I access shell environment variables?" -msgstr "shell 環境変数にアクセスするにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:538 -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:549 -msgid "**On target machines :** Environment variables are available through facts in the ``ansible_env`` variable:" -msgstr "**ターゲットマシン:** 環境変数の場合には、``ansible_env`` 変数のファクトを使用して入手します。" - -#: ../../rst/reference_appendices/faq.rst:555 -msgid "If you need to set environment variables for TASK execution, see :ref:`playbooks_environment` in the :ref:`Advanced Playbooks ` section. There are several ways to set environment variables on your target machines. You can use the :ref:`template `, :ref:`replace `, or :ref:`lineinfile ` modules to introduce environment variables into files. The exact files to edit vary depending on your OS and distribution and local configuration." -msgstr "タスクを実行するために環境変数を設定する必要がある場合は、:ref:`詳細な Playbook ` セクションの「:ref:`playbooks_environment`」を参照してください。ターゲットマシンで環境変数を設定するには、いくつかの方法があります。:ref:`template ` モジュール、:ref:`replace ` モジュール、または :ref:`lineinfile ` モジュールを使用して、環境変数をファイルに取り込むことができます。編集するファイルは、OS、ディストリビューション、およびローカル設定によって異なります。" - -#: ../../rst/reference_appendices/faq.rst:565 -msgid "How do I generate encrypted passwords for the user module?" -msgstr "ユーザーモジュールの暗号化パスワードを生成するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:567 -msgid "Ansible ad hoc command is the easiest option:" -msgstr "Ansible ad-hoc コマンドを使用するのが最も簡単なオプションです。" - -#: ../../rst/reference_appendices/faq.rst:573 -msgid "The ``mkpasswd`` utility that is available on most Linux systems is also a great option:" -msgstr "ほとんどの Linux システムで利用できる ``mkpasswd`` ユーティリティーも優れたオプションです。" - -#: ../../rst/reference_appendices/faq.rst:580 -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 `_ password hashing library is installed:" -msgstr "お使いのシステムにこのユーティリティーがインストールされていない場合 (例: MacOS を使用している場合など) には、Python を使用してこのようなパスワードを簡単に生成できます。まず、`Passlib `_ パスワードハッシュライブラリーがインストールされていることを確認します。" - -#: ../../rst/reference_appendices/faq.rst:588 -msgid "Once the library is ready, SHA512 password values can then be generated as follows:" -msgstr "ライブラリーの準備ができたら、以下のように SHA512 パスワードの値を生成できます。" - -#: ../../rst/reference_appendices/faq.rst:594 -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." -msgstr "統合された :ref:`hash_filters` を使用して、ハッシュ化されたパスワードを生成します。Playbook や host_vars にプレーンテキストのパスワードは使用しないでください。代わりに、:ref:`playbooks_vault` を使用して、機密データを暗号化してください。" - -#: ../../rst/reference_appendices/faq.rst:597 -msgid "In OpenBSD, a similar option is available in the base system called ``encrypt (1)``" -msgstr "OpenBSDでは、``encrypt (1)`` と呼ばれるベースシステムで同様のオプションが利用可能です。" - -#: ../../rst/reference_appendices/faq.rst:602 -msgid "Ansible allows dot notation and array notation for variables. Which notation should I use?" -msgstr "Ansible では、変数のドット表記とアレイ表記が可能です。どの表記を使用する必要がありますか" - -#: ../../rst/reference_appendices/faq.rst:604 -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." -msgstr "ドット表記は Jinja からのもので、特殊文字なしに変数と合わせて使用できます。変数にドット (.)、コロン (:)、またはハイフン (-) が含まれていて、キーが 2 つのアンダースコアで開始および終了する場合、またはキーが既知のパブリック属性のいずれかを使用する場合は、配列表記を使用する方が安全です。既知のパブリック属性の一覧は、「:ref:`playbooks_variables`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:617 -msgid "Also array notation allows for dynamic variable composition, see dynamic_variables_." -msgstr "また、アレイ表記は、動的な変数の構成が可能です。詳細は、「dynamic_variables_」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:619 -msgid "Another problem with 'dot notation' is that some keys can cause problems because they collide with attributes and methods of python dictionaries." -msgstr "「ドット表記」の他の問題として、ドット表記のキーによっては、Python ディクショナリーの属性とメソッドと競合するため、問題が発生する可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:621 -msgid "Example of incorrect syntax when ``item`` is a dictionary:" -msgstr "``item`` がディクショナリーの場合の誤った構文の例:" - -#: ../../rst/reference_appendices/faq.rst:627 -msgid "This variant causes a syntax error because ``update()`` is a Python method for dictionaries." -msgstr "``update()`` がディクショナリー用の Python メソッドであるため、このバリアントは構文エラーを引き起こします。" - -#: ../../rst/reference_appendices/faq.rst:629 -msgid "Example of correct syntax:" -msgstr "正しい構文の例:" - -#: ../../rst/reference_appendices/faq.rst:639 -msgid "When is it unsafe to bulk-set task arguments from a variable?" -msgstr "変数からタスク引数の一括設定をすると安全でないのはどのような場合ですか" - -#: ../../rst/reference_appendices/faq.rst:642 -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:" -msgstr "ディクショナリー型の変数からタスクの引数をすべて設定することができます。この手法は、動的な実行シナリオで便利な場合があります。ただし、セキュリティーリスクがあります。これは推奨されないため、このような操作を行うと、Ansible では警告を発行します。" - -#: ../../rst/reference_appendices/faq.rst:658 -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:" -msgstr "この特定の例は、安全です。ただし、``usermod_args`` に渡されるパラメーターや値が、セキュリティー侵害を受けたターゲットマシンの ``host facts`` に含まれる悪意のある値で置き換えられる可能性があるため、このようなタスクの構築にはリスクがあります。このリスクを軽減するには、以下を行います。" - -#: ../../rst/reference_appendices/faq.rst:663 -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)" -msgstr ":ref:`ansible_variable_precedence` にある優先順位で、``host facts`` より優先順位の高いレベルで一括変数を設定します (プレイ変数はファクトより優先度が高いため、上記の例は安全です)。" - -#: ../../rst/reference_appendices/faq.rst:666 -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)" -msgstr "ファクトの値が変数と競合しないように :ref:`inject_facts_as_vars` 設定オプションを無効にします (元の警告も無効になります)。" - -#: ../../rst/reference_appendices/faq.rst:673 -msgid "Can I get training on Ansible?" -msgstr "Ansible のトレーニングはありますか" - -#: ../../rst/reference_appendices/faq.rst:675 -msgid "Yes! See our `services page `_ for information on our services and training offerings. Email `info@ansible.com `_ for further details." -msgstr "サービスおよびトレーニングサービスに関する情報は、「`サービスページ `_」を参照してください。詳細は、`info@ansible.com `_ にお問い合わせください。" - -#: ../../rst/reference_appendices/faq.rst:678 -msgid "We also offer free web-based training classes on a regular basis. See our `webinar page `_ for more info on upcoming webinars." -msgstr "また、定期的に、Web ベースのトレーニングも無料で提供しています。今後予定されているウェビナーの詳細は、`ウェビナーページ `_ を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:685 -msgid "Is there a web interface / REST API / GUI?" -msgstr "Web インターフェース、REST API、GUI はありますか" - -#: ../../rst/reference_appendices/faq.rst:687 -msgid "Yes! The open-source web interface is Ansible AWX. The supported Red Hat product that makes Ansible even more powerful and easy to use is :ref:`Red Hat Ansible Automation Platform `." -msgstr "はい。オープンソース Web インターフェースは Ansible AWX です。Ansible がより強力で、使いやすい、Red Hat のサポート対象製品は、 :ref:`Red Hat Ansible Automation Platform ` です。" - -#: ../../rst/reference_appendices/faq.rst:693 -msgid "How do I keep secret data in my playbook?" -msgstr "Playbook に機密データを保存するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:695 -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`." -msgstr "Ansible のコンテンツに機密データを保存してそのコンテンツを公開するか、ソースコントロールに保持する場合は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:697 -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:" -msgstr "-v (詳細) モードの使用時に、結果や指定したコマンドを表示したくないタスクがある場合は、次のようなタスクや Playbook 属性が便利です。" - -#: ../../rst/reference_appendices/faq.rst:705 -msgid "This can be used to keep verbose output but hide sensitive information from others who would otherwise like to be able to see the output." -msgstr "これは、詳細な出力を維持しつつ、出力を見たいと思っている人から機密情報を隠すために使うことができます。" - -#: ../../rst/reference_appendices/faq.rst:707 -msgid "The ``no_log`` attribute can also apply to an entire play:" -msgstr "``no_log`` 属性は、プレイ全体にも適用できます。" - -#: ../../rst/reference_appendices/faq.rst:714 -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 through the :envvar:`ANSIBLE_DEBUG` environment variable." -msgstr "ただし、これを使用すると、プレイのデバッグが困難になります。Playbook が完了すると、この属性は単一のタスクにのみ適用することが推奨されます。``no_log`` 属性を使用しても、:envvar:`ANSIBLE_DEBUG` 環境変数で Ansible 自体をデバッグするときに、データが表示されてしまう点に注意してください。" - -#: ../../rst/reference_appendices/faq.rst:725 -msgid "When should I use {{ }}? Also, how to interpolate variables or dynamic variable names" -msgstr "{{ }} はいつ使用する必要がありますか。また、変数または動的な変数名を補間するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:727 -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 ``{{ }}``." -msgstr "不動のルールは「``when:`` の場合を除いて常に ``{{ }}`` を使用する」です。この条件は、式の解決として Jinja2 を介して実行するため、``when:``、``failed_when:``、および ``changed_when:`` は常にテンプレート化され、``{{ }}`` の追加は回避してください。" - -#: ../../rst/reference_appendices/faq.rst:731 -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." -msgstr "それ以外のケースでは、以前は ``loop`` 句または ``with_`` 句などを指定しなくても変数を使用できていた場合でも、常に括弧を使用するようにしてください。理由は、未定義の変数と文字列を区別しにくいためです。" - -#: ../../rst/reference_appendices/faq.rst:734 -msgid "Another rule is 'moustaches don't stack'. We often see this:" -msgstr "他には「波括弧は並べて使用できない」というルールがありますが、これは頻繁に見受けられます。" - -#: ../../rst/reference_appendices/faq.rst:740 -msgid "The above DOES NOT WORK as you expect, if you need to use a dynamic variable use the following as appropriate:" -msgstr "上記の例は想定通り、機能しません。動的変数を使用する必要がある場合には、随時、以下を使用してください。" - -#: ../../rst/reference_appendices/faq.rst:746 -msgid "For 'non host vars' you can use the :ref:`vars lookup` plugin:" -msgstr "「non host vars」の場合には、:ref:`vars lookup` プラグインを使用できます。" - -#: ../../rst/reference_appendices/faq.rst:752 -msgid "To determine if a keyword requires ``{{ }}`` or even supports templating, use ``ansible-doc -t keyword ``, this will return documentation on the keyword including a ``template`` field with the values ``explicit`` (requires ``{{ }}``), ``implicit`` (assumes ``{{ }}``, so no needed) or ``static`` (no templating supported, all characters will be interpreted literally)" -msgstr "キーワードに ``{{ }}`` が必要か、テンプレートをサポートするかを判断するには、``ansible-doc -t keyword `` を使用します。これにより、値 ``explicit`` (``{{ }}`` が必要)、``implicit`` (``{{ }}`` を前提、必要なし)、または ``static`` (テンプレートのサポートなし、文字はすべてそのまま文字通り解釈される) の値が含まれる ``template`` フィールドを含むキーワードのドキュメントを返します。" - -#: ../../rst/reference_appendices/faq.rst:759 -msgid "How do I get the original ansible_host when I delegate a task?" -msgstr "タスクを委譲した場合に元の ansible_host をどのように取得すれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:761 -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 through ``hostvars``:" -msgstr "ドキュメントに記載されているように、接続変数は ``delegate_to`` ホストから取得されるため、``ansible_host`` は上書きされますが、``hostvars`` を使用して元の ansible_host にアクセスできます。" - -#: ../../rst/reference_appendices/faq.rst:768 -msgid "This works for all overridden connection variables, like ``ansible_user``, ``ansible_port``, and so on." -msgstr "これは、``ansible_user``、``ansible_port`` などのように、すべての上書きされた接続変数に有効です。" - -#: ../../rst/reference_appendices/faq.rst:774 -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:776 -msgid "Since release ``7.9p1`` of OpenSSH there is a `bug `_ in the SCP client that can trigger this error on the Ansible controller when using SCP as the file transfer mechanism:" -msgstr "OpenSSH のリリース ``7.9p1`` では、SCP クライアントに `bug `_ があり、ファイル転送メカニズムとして SCP を使用する場合に、Ansible コントローラーで以下のエラーが出力される可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:781 -msgid "failed to transfer file to /tmp/ansible/file.txt\\r\\nprotocol error: filename does not match request" -msgstr "ファイルを /tmp/ansible/file.txt\\r\\n" -"protocol に転送できませんでした。エラー: ファイル名はリクエストに一致しません。" - -#: ../../rst/reference_appendices/faq.rst:783 -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:" -msgstr "新しいリリースでは、SCP は、取得するファイルのパスが要求したパスと一致することを検証しようとします。リモートのファイル名が、パスでスペースや ASCII 文字以外の文字を引用符でエスケープする必要がある場合には、検証に失敗します。このエラーを回避するには、以下を行います。" - -#: ../../rst/reference_appendices/faq.rst:791 -msgid "Use SFTP instead of SCP by setting ``scp_if_ssh`` to ``smart`` (which tries SFTP first) or to ``False``. You can do this in one of four ways:" -msgstr "``scp_if_ssh`` を ``smart`` (先に SFTP を試す)、または ``False`` に設定して、SCP の代わりに SFTP を使用します。" - -#: ../../rst/reference_appendices/faq.rst:788 -msgid "Rely on the default setting, which is ``smart`` - this works if ``scp_if_ssh`` is not explicitly set anywhere" -msgstr "``smart`` のデフォルトの設定に依存します。``scp_if_ssh`` が明示的にどこにも設定されていない場合に機能します。" - -#: ../../rst/reference_appendices/faq.rst:789 -msgid "Set a :ref:`host variable ` or :ref:`group variable ` in inventory: ``ansible_scp_if_ssh: False``" -msgstr "インベントリーに :ref:`ホスト変数 ` または :ref:`グループ変数 ` を設定します (``ansible_scp_if_ssh: False``)。" - -#: ../../rst/reference_appendices/faq.rst:790 -msgid "Set an environment variable on your control node: ``export ANSIBLE_SCP_IF_SSH=False``" -msgstr "コントロールノードで環境変数を設定します (``export ANSIBLE_SCP_IF_SSH=False``)。" - -#: ../../rst/reference_appendices/faq.rst:791 -msgid "Pass an environment variable when you run Ansible: ``ANSIBLE_SCP_IF_SSH=smart ansible-playbook``" -msgstr "Ansible を実行するときに環境変数を渡します (``ANSIBLE_SCP_IF_SSH=smart ansible-playbook``)。" - -#: ../../rst/reference_appendices/faq.rst:792 -msgid "Modify your ``ansible.cfg`` file: add ``scp_if_ssh=False`` to the ``[ssh_connection]`` section" -msgstr "``ansible.cfg`` ファイルの変更: ``scp_if_ssh=False`` を ``[ssh_connection]`` セクションに追加します。" - -#: ../../rst/reference_appendices/faq.rst:796 -msgid "If you must use SCP, set the ``-T`` arg to tell the SCP client to ignore path validation. You can do this in one of three ways:" -msgstr "SCP を使用する必要がある場合は、``-T`` 引数を設定して、SCP クライアントにパスの検証を無視するように指示します。以下の 3 つの方法のいずれかで実行できます。" - -#: ../../rst/reference_appendices/faq.rst:794 -msgid "Set a :ref:`host variable ` or :ref:`group variable `: ``ansible_scp_extra_args=-T``," -msgstr ":ref:`ホスト変数 ` または :ref:`グループ変数 ` を設定します (``ansible_scp_extra_args=-T``)。" - -#: ../../rst/reference_appendices/faq.rst:795 -msgid "Export or pass an environment variable: ``ANSIBLE_SCP_EXTRA_ARGS=-T``" -msgstr "環境変数をエクスポートするか、渡します (``ANSIBLE_SCP_EXTRA_ARGS=-T``)。" - -#: ../../rst/reference_appendices/faq.rst:796 -msgid "Modify your ``ansible.cfg`` file: add ``scp_extra_args=-T`` to the ``[ssh_connection]`` section" -msgstr "``ansible.cfg`` ファイルの変更: ``scp_extra_args=-T`` を ``[ssh_connection]`` セクションに追加します。" - -#: ../../rst/reference_appendices/faq.rst:798 -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." -msgstr "``-T`` の使用時に ``invalid argument`` エラーが表示される場合は、SCP クライアントがファイル名を検証しておらず、このエラーは発生しません。" - -#: ../../rst/reference_appendices/faq.rst:803 -msgid "Does Ansible support multiple factor authentication 2FA/MFA/biometrics/finterprint/usbkey/OTP/..." -msgstr "Ansible では、複数のファクター認証 2FA/MFA/biometrics/finterprint/usbkey/OTP/... がサポートされますか" - -#: ../../rst/reference_appendices/faq.rst:805 -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." -msgstr "いいえ、Ansible は複数のターゲットに対して複数のタスクを実行するように設計されており、ユーザーの操作を最小限に抑えることができます。ほとんどの自動化ツールと同様に、人間の相互作用を処理するように設計されたインタラクティブなセキュリティーシステムとの互換性はありません。これらのシステムのほとんどは、ターゲットごとにセカンダリープロンプトを必要とするため、数千のターゲットに拡張することができません。また、これらのシステムは有効期限が非常に短いため、再認証が頻繁に必要となりますが、これも多くのホストや長いタスクセットでは問題となります。" - -#: ../../rst/reference_appendices/faq.rst:811 -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. With AWX or the :ref:`Red Hat Ansible Automation Platform `, administrators can set up RBAC access to inventory, along with managing credentials and job execution." -msgstr "このような環境では、Ansible の実行を保護しながら、そのような手段を必要としない「自動化ユーザー」の使用を許可することが推奨されます。AWX または :ref:`Red Hat Ansible Automation Platform ` を使用すると、管理者がインベントリーへの RBAC アクセスを設定し、認証情報とジョブの実行を管理できます。" - -#: ../../rst/reference_appendices/faq.rst:818 -msgid "The 'validate' option is not enough for my needs, what do I do?" -msgstr "弊社の要件には、「validate」オプションは十分ではありません。どうすればよいでしょうか？" - -#: ../../rst/reference_appendices/faq.rst:820 -msgid "Many Ansible modules that create or update files have a ``validate`` option that allows you to abort the update if the validation command fails. This uses the temporary file Ansible creates before doing the final update. In many cases this does not work since the validation tools for the specific application require either specific names, multiple files or some other factor that is not present in this simple feature." -msgstr "ファイル作成または更新の Ansible モジュールの多くには ``validate`` オプションがあり、検証コマンドが失敗した場合に更新を中止できます。これは、最終更新を行う前に Ansible が作成する一時ファイルを使用します。多くの場合、特定のアプリケーションの検証ツールには特定の名前、複数のファイル以外に、この単純な機能に含まれていない他の要素が必要になるため、これは機能しません。" - -#: ../../rst/reference_appendices/faq.rst:824 -msgid "For these cases you have to handle the validation and restoration yourself. The following is a simple example of how to do this with block/rescue and backups, which most file based modules also support:" -msgstr "このような場合は、検証と復元を自分で処理する必要があります。以下は、ブロック/レスキューおよびバックアップでこの作業を行う簡単な例で、ほとんどのファイルベースのモジュールもサポートしています。" - -#: ../../rst/reference_appendices/faq.rst:856 -msgid "Why does the ``regex_search`` filter return `None` instead of an empty string?" -msgstr "``regex_search`` フィルターが空の文字列ではなく `None` を返すのはなぜですか。" - -#: ../../rst/reference_appendices/faq.rst:858 -msgid "Until the jinja2 2.10 release, Jinja was only able to return strings, but Ansible needed Python objects in some cases. Ansible uses ``safe_eval`` and only sends strings that look like certain types of Python objects through this function. With ``regex_search`` that does not find a match, the result (``None``) is converted to the string \"None\" which is not useful in non-native jinja2." -msgstr "jinja2 2.10 リリースまで、Jinja は文字列しか返すことができませんでしたが、Ansible で Python オブジェクトが必要な場合がありました。Ansible は``safe_eval`` を使用し、この関数を介して特定のタイプの Python オブジェクトのように見える文字列のみを送信します。``regex_search`` で一致するものが見つからない場合、結果 (``None``) は、非ネイティブの jinja2 では役に立たない文字列「None」に変換されます。" - -#: ../../rst/reference_appendices/faq.rst:860 -msgid "The following example of a single templating action shows this behavior:" -msgstr "次の単一のテンプレートアクション例は、この動作を示しています。" - -#: ../../rst/reference_appendices/faq.rst:866 -msgid "This example does not result in a Python ``None``, so Ansible historically converted it to \"\" (empty string)." -msgstr "この例では Python ``None`` が発生しないため、これまで Ansible はこれを \"\" (空の文字列) に変換していました。" - -#: ../../rst/reference_appendices/faq.rst:868 -msgid "The native jinja2 functionality actually allows us to return full Python objects, that are always represented as Python objects everywhere, and as such the result of a single templating action with ``regex_search`` can result in the Python ``None``." -msgstr "ネイティブ jinja2 機能を使用すると、実際に完全な Python オブジェクトを返すことができます。これは、常にどこでも Python オブジェクトとして表され、そのため、``regex_search`` の結果が Python ``None`` になる可能性があります。" - -#: ../../rst/reference_appendices/faq.rst:872 -msgid "Native jinja2 functionality is not needed when ``regex_search`` is used as an intermediate result that is then compared to the jinja2 ``none`` test." -msgstr "``regex_search`` を中間結果として使用し、jinja2 ``none`` テストと比較する場合、ネイティブ jinja2 機能は必要ありません。" - -#: ../../rst/reference_appendices/faq.rst:882 -msgid "How do I submit a change to the documentation?" -msgstr "ドキュメントへの変更を提出するにはどうすれば良いですか" - -#: ../../rst/reference_appendices/faq.rst:884 -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 `_. Thanks!" -msgstr "Ansible のドキュメントは、主要プロジェクトの git リポジトリーに保存されており、貢献に関する説明が `GitHub で確認できる `_ README に記載されています。" - -#: ../../rst/reference_appendices/faq.rst:891 -msgid "What is the difference between ``ansible.legacy`` and ``ansible.builtin`` collections?" -msgstr "``ansible.legacy`` コレクションと ``ansible.builtin`` コレクションの違いは何ですか ?" - -#: ../../rst/reference_appendices/faq.rst:893 -msgid "Neither is a real collection. They are virtually constructed by the core engine (synthetic collections)." -msgstr "どちらも本当のコレクションではありません。これらは、コアエンジン (合成コレクション) によって仮想的に構築されます。" - -#: ../../rst/reference_appendices/faq.rst:895 -msgid "The ``ansible.builtin`` collection only refers to plugins that ship with ``ansible-core``." -msgstr "``ansible.builtin`` コレクションは、``ansible-core`` に同梱されるプラグインのみを参照します。" - -#: ../../rst/reference_appendices/faq.rst:897 -msgid "The ``ansible.legacy`` collection is a superset of ``ansible.builtin`` (you can reference the plugins from builtin through ``ansible.legacy``). You also get the ability to add 'custom' plugins in the :ref:`configured paths and adjacent directories `, with the ability to override the builtin plugins that have the same name." -msgstr "``ansible.legacy`` コレクションは、``ansible.builtin`` のスーパーセット (``ansible.legacy`` を使用して組子荒れたプラグインを参照可能) です。さらに、同じ名前の組み込みプラグインを上書きできるので、:ref:`configured paths and adjacent directories ` のカスタムプラグインを追加できるようになります。" - -#: ../../rst/reference_appendices/faq.rst:900 -msgid "Also, ``ansible.legacy`` is what you get by default when you do not specify an FQCN. So this:" -msgstr "また、``ansible.legacy`` は、FQCN を指定しない場合にデフォルトで取得するものです。" - -#: ../../rst/reference_appendices/faq.rst:907 -msgid "Is really equivalent to:" -msgstr "これは以下と同等です。" - -#: ../../rst/reference_appendices/faq.rst:913 -msgid "Though, if you do not override the ``shell`` module, you can also just write it as ``ansible.builtin.shell``, since legacy will resolve to the builtin collection." -msgstr "``shell`` モジュールを上書きしない場合は、レガシーが組み込みコレクションに対して解決するので、``ansible.builtin.shell`` と記述することもできます。" - -#: ../../rst/reference_appendices/faq.rst:919 -msgid "I don't see my question here" -msgstr "ここに記載されている以外に質問があります" - -#: ../../rst/reference_appendices/faq.rst:921 -msgid "If you have not found an answer to your questions, you can ask on one of our mailing lists or chat channels. For instructions on subscribing to a list or joining a chat channel, see :ref:`communication`." -msgstr "ご不明な点がございましたら、メーリングリストまたはチャットチャンネルのいずれかを尋ねることができます。リストのサブスクライブ方法や、チャットチャンネルへの参加方法は、:ref:`communication`を参照してください。" - -#: ../../rst/reference_appendices/faq.rst:926 -#: ../../rst/reference_appendices/glossary.rst:537 -#: ../../rst/reference_appendices/test_strategies.rst:297 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/reference_appendices/faq.rst:927 -#: ../../rst/reference_appendices/glossary.rst:538 -msgid ":ref:`playbooks_best_practices`" -msgstr ":ref:`playbooks_best_practices`" - -#: ../../rst/reference_appendices/faq.rst:928 -#: ../../rst/reference_appendices/glossary.rst:539 -msgid "Tips and tricks for playbooks" -msgstr "Playbook のヒントと裏技" - -#: ../../rst/reference_appendices/faq.rst:929 -#: ../../rst/reference_appendices/test_strategies.rst:300 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/reference_appendices/faq.rst:930 -#: ../../rst/reference_appendices/glossary.rst:541 -#: ../../rst/reference_appendices/test_strategies.rst:301 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/reference_appendices/general_precedence.rst:4 -msgid "Controlling how Ansible behaves: precedence rules" -msgstr "Ansible の動作の制御: 優先順位のルール" - -#: ../../rst/reference_appendices/general_precedence.rst:6 -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." -msgstr "Ansible には、環境の管理に最大限の柔軟性をもたせられるように、管理対象ノードへの接続方法や、接続後の動作など、Ansible の動作を制御する手段が多数あります。Ansible を使用して多数のサーバー、ネットワークデバイス、クラウドリソースを管理する場合に、Ansible の動作をさまざまな場所で定義して、さまざまな方法で Ansible にその情報を渡すことができます。柔軟性があると便利ですが、優先順位ルールを理解していない場合は、逆効果となる可能性があります。" - -#: ../../rst/reference_appendices/general_precedence.rst:10 -msgid "These precedence rules apply to any setting that can be defined in multiple ways (by configuration settings, command-line options, playbook keywords, variables)." -msgstr "このような優先順位ルールは、複数の方法で定義できるオプション (設定オプション、コマンドラインオプション、Playbook キーワード、変数) に適用されます。" - -#: ../../rst/reference_appendices/general_precedence.rst:16 -msgid "Precedence categories" -msgstr "優先順位のカテゴリー" - -#: ../../rst/reference_appendices/general_precedence.rst:18 -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:" -msgstr "Ansible では、動作の制御に使用するソースが 4 つあります。カテゴリーは以下のとおりです (優先順位の低いもの、つまり最も簡単にオーバーライドされるものから、高いもの、つまり他のすべてをオーバーライドするものに並べています)。" - -#: ../../rst/reference_appendices/general_precedence.rst:20 -#: ../../rst/reference_appendices/general_precedence.rst:30 -msgid "Configuration settings" -msgstr "設定オプション" - -#: ../../rst/reference_appendices/general_precedence.rst:21 -#: ../../rst/reference_appendices/general_precedence.rst:42 -msgid "Command-line options" -msgstr "コマンドラインオプション" - -#: ../../rst/reference_appendices/general_precedence.rst:22 -#: ../../rst/reference_appendices/general_precedence.rst:65 -msgid "Playbook keywords" -msgstr "Playbook キーワード" - -#: ../../rst/reference_appendices/general_precedence.rst:25 -msgid "Each category overrides any information from all lower-precedence categories. For example, a playbook keyword will override any configuration setting." -msgstr "各カテゴリーは、そのカテゴリーよりも優先順位の低いカテゴリーからの情報をすべてオーバーライドします。たとえば、Playbook キーワードは、設定オプションをオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:27 -msgid "Within each precedence category, specific rules apply. However, generally speaking, 'last defined' wins and overrides any previous definitions." -msgstr "各優先順位カテゴリーで、固有のルールが適用されます。ただし、一般的に「最後に定義 (last defined)」した内容の優先度が高く、以前の定義をオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:32 -msgid ":ref:`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:" -msgstr ":ref:`構成設定` には、``ansible.cfg`` ファイルと環境変数からの両方の値が含まれます。このカテゴリーでは、設定ファイルに指定した値のほうが優先順位が低くなります。Ansible では最初に見つかった ``ansible.cfg`` を使用し、他はすべて無視します。Ansible は、これらの場所で順番に ``ansible.cfg`` を選択します。" - -#: ../../rst/reference_appendices/general_precedence.rst:39 -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." -msgstr "環境変数は、``ansible.cfg`` のエントリーよりも優先されます。コントロールノードに環境変数を設定している場合には、Ansible が読み込む ``ansible.cfg`` ファイルの設定よりも、環境変数が優先されます。指定された環境変数の値は、shell の通常の優先順位 (最後に定義した値が、それ以前の値をオーバーライド) に準拠します。" - -#: ../../rst/reference_appendices/general_precedence.rst:44 -msgid "Any command-line option will override any configuration setting." -msgstr "コマンドラインオプションは、設定オプションをすべてオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:46 -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." -msgstr "コマンドラインに直接入力すると、手動で入力した値が、それ以外の設定をすべてオーバーライドするように感じますが、Ansible の仕様は異なります。コマンドラインオプションの優先順位は低いため、オーバーライドできるのは、設定のみです。Playbook のキーワードや、インベントリーからの変数、または Playbook から変数をオーバーライドすることはありません。" - -#: ../../rst/reference_appendices/general_precedence.rst:48 -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`." -msgstr ":ref:`general_precedence_extra_vars` により、コマンドラインで、他の優先順位カテゴリーの他のソースからの他の設定をすべて上書きできます。ただし、これはコマンドラインオプションではなく、:ref:`variable` を渡す手段としてコマンドラインを使用しています。" - -#: ../../rst/reference_appendices/general_precedence.rst:50 -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` will connect as ``carol``, not as ``mike``:" -msgstr "コマンドラインで、単値のみを受け入れるパラメーターに多値を渡すと、最後に定義された値が優先されます。たとえば、この :ref:`ad hoc task` は、``mike`` ではなく、``carol`` として接続します。" - -#: ../../rst/reference_appendices/general_precedence.rst:56 -msgid "Some parameters allow multiple values. In this case, Ansible will append all values from the hosts listed in inventory files inventory1 and inventory2:" -msgstr "パラメーターによっては、多値を使用できます。以下の場合には、Ansible は、インベントリーファイル「inventory1」および「inventory2」に記載されているホストからの値をすべて追加します。" - -#: ../../rst/reference_appendices/general_precedence.rst:62 -msgid "The help for each :ref:`command-line tool` lists available options for that tool." -msgstr "各 :ref:`コマンドラインツール` のヘルプは、対象のツールで利用可能なオプションを表示します。" - -#: ../../rst/reference_appendices/general_precedence.rst:67 -msgid "Any :ref:`playbook keyword` will override any command-line option and any configuration setting." -msgstr ":ref:`Playbook キーワード` は、コマンドラインオプションと、構成設定をすべてオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:69 -msgid "Within playbook keywords, precedence flows with the playbook itself; the more specific wins against the more general:" -msgstr "Playbook キーワード内の優先順位は、Playbook の内容により左右されます (一般的な設定より具体的な設定が優先されます)。" - -#: ../../rst/reference_appendices/general_precedence.rst:71 -msgid "play (most general)" -msgstr "プレイ (最も一般的)" - -#: ../../rst/reference_appendices/general_precedence.rst:72 -msgid "blocks/includes/imports/roles (optional and can contain tasks and each other)" -msgstr "blocks/includes/imports/roles (任意で、タスクを含めることも、相互に含めることも可能)" - -#: ../../rst/reference_appendices/general_precedence.rst:73 -msgid "tasks (most specific)" -msgstr "タスク (最も具体的)" - -#: ../../rst/reference_appendices/general_precedence.rst:75 -msgid "A simple example:" -msgstr "簡単な例:" - -#: ../../rst/reference_appendices/general_precedence.rst:89 -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." -msgstr "この例では、``connection`` キーワードはプレイレベルで ``ssh`` に設定されています。最初のタスクはその値を継承し、``ssh`` を使用して接続します。2 番目のタスクは、その値を継承してオーバーライドし、``paramiko`` を使用して接続します。ブロックやロールでも同じロジックが適用されます。プレイ内のタスク、ブロック、およびロールはすべて、プレイレベルのキーワードを継承します。キーワードよりタスク、ブロック、またはロールを優先させるには、タスク、ブロック、またはロール内の対象のキーワードに異なる値を定義します。" - -#: ../../rst/reference_appendices/general_precedence.rst:92 -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." -msgstr "上記は、変数ではなく、キーワードである点に注意してください。Playbook や変数ファイルはいずれも YAML で定義しますが、それぞれ重要性が異なります。Playbook はコマンドまたは Ansible の「状態記述」構造で、変数は Playbook をより動的に使用できるようにするためのデータです。" - -#: ../../rst/reference_appendices/general_precedence.rst:100 -msgid "Any variable will override any playbook keyword, any command-line option, and any configuration setting." -msgstr "変数は、Playbook のキーワード、コマンドラインオプション、構成設定をすべてオーバーライドします。" - -#: ../../rst/reference_appendices/general_precedence.rst:102 -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." -msgstr "同等の Playbook キーワード、コマンドラインオプション、および構成設定を含む変数は :ref:`connection_variables` と呼ばれています。このカテゴリーは、当初は設定パラメーター向けに設計されてましたが、一時ディレクトリーや Python インタープリターなど、他のコア変数を含めるように拡張されました。" - -#: ../../rst/reference_appendices/general_precedence.rst:104 -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`. You can define variables for tasks and plays in ``vars:`` blocks in :ref:`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 ` as any other variables." -msgstr "接続変数はすべての変数と同様、複数の手法や場所で設定できます。:ref:`インベントリー` でホストとグループの変数を定義できます。:ref:`Playbook` の ``vars:`` ブロックに、タスクとプレイの変数を定義できます。ただし、上記は、キーワードや構成設定ではなく、データを格納する変数です。Playbook キーワード、コマンドラインオプション、および設定オプションをオーバーライドする変数は、他の変数が使用する :ref:`変数の優先順位 ` と同じルールに従います。" - -#: ../../rst/reference_appendices/general_precedence.rst:106 -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:" -msgstr "変数は、Playbook に設定されると、Playbook キーワードと同じ継承ルールに従います。プレイの値を設定すると、タスク、ブロック、またはロールの値をオーバーライドできます。" - -#: ../../rst/reference_appendices/general_precedence.rst:133 -msgid "Variable scope: how long is a value available?" -msgstr "変数の範囲: 値が有効な期間" - -#: ../../rst/reference_appendices/general_precedence.rst:135 -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." -msgstr "Playbook に設定した変数の値は、その値を定義する Playbook オブジェクト内にのみ存在します。このような「Playbook オブジェクトの範囲」の変数は、他のプレイなど、後続のオブジェクトでは利用できません。" - -#: ../../rst/reference_appendices/general_precedence.rst:137 -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` and :ref:`include_vars`, are available to all plays. These 'host scope' variables are also available through the ``hostvars[]`` dictionary." -msgstr "インベントリー、vars プラグイン、:ref:`set_fact` や :ref:`include_vars` といったモジュールの使用など、ホストやグループに直接関連付けられた変数値は、全プレイで利用できます。また、これらの「ホスト範囲」変数は、``hostvars[]`` ディクショナリーから利用できます。" - -#: ../../rst/reference_appendices/general_precedence.rst:142 -msgid "Using ``-e`` extra variables at the command line" -msgstr "コマンドラインでの追加変数 (``-e``) の使用" - -#: ../../rst/reference_appendices/general_precedence.rst:144 -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``:" -msgstr "他のカテゴリーの全設定をオーバーライドするには、コマンドラインで追加変数 (``--extra-vars`` または ``-e``) を使用します。``-e`` で渡される値は、コマンドラインオプションではなく変数で、他で設定した変数をはじめ、構成設定、コマンドラインオプション、Playbook キーワードをオーバーライドします。たとえば、このタスクは、``carol`` ではなく ``brian`` として接続します。" - -#: ../../rst/reference_appendices/general_precedence.rst:150 -msgid "You must specify both the variable name and the value with ``--extra-vars``." -msgstr "変数名と値は、``--extra-vars`` で指定する必要があります。" - -#: ../../rst/reference_appendices/glossary.rst:2 -msgid "Glossary" -msgstr "用語集" - -#: ../../rst/reference_appendices/glossary.rst:4 -msgid "The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation." -msgstr "以下は、Ansible ドキュメントの各所で使用される用語の定義 (と再説) 一覧です。" - -#: ../../rst/reference_appendices/glossary.rst:6 -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." -msgstr "全ドキュメント、および文中で用語を確認するには、ドキュメントのホームページを参照してください。このページは、Ansible のコンポーネントの説明を読み、どのように組み合わされているかを理解するのに適しています。レビューのために、またはメーリングリストで用語が使用された時などにご利用になれます。" - -#: ../../rst/reference_appendices/glossary.rst:11 -msgid "Action" -msgstr "アクション" - -#: ../../rst/reference_appendices/glossary.rst:13 -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." -msgstr "アクションはタスクの一部を指し、実行するモジュールや、そのモジュールが渡す引数を指定します。各タスクには、アクションを 1 つだけ指定できますが、他に複数のパラメーターが指定されている可能性があります。" - -#: ../../rst/reference_appendices/glossary.rst:16 -msgid "Ad Hoc" -msgstr "アドホック" - -#: ../../rst/reference_appendices/glossary.rst:18 -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 ` and playbooks can also glue lots of other operations together." -msgstr "Ansible を実行して、:command:`/usr/bin/ansible-playbook` の :term:`オーケストレーション` 言語ではなく、:command:`/usr/bin/ansible` を使用してクイックコマンドを実行することを指します。アドホックコマンドの例には、インフラストラクチャー内での 50 台のマシンを再起動することなどが含まれます。アドホックに実行できるすべてのことは :term:`playbook ` を作成して実行でき、Playbook は数多くの他の操作を 1 つにまとめることができます。" - -#: ../../rst/reference_appendices/glossary.rst:25 -msgid "Ansible (the package)" -msgstr "Ansible (パッケージ)" - -#: ../../rst/reference_appendices/glossary.rst:27 -msgid "A software package (Python, deb, rpm, and so on) that contains ansible-core 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-.build` file in the release-specific directory at `ansible-build-data `_ for a list of collections included in Ansible, as well as the included ``ansible-core`` version." -msgstr "ansible-core および選択したコレクショングループを含むソフトウェアパッケージ (Python、deb、rpm など)。Ansible 2.9 で動作した Playbook は、Ansible 2.10 パッケージでも動作するはずです。Ansible に含まれているコレクションのリストと同梱されている ``ansible-core`` バージョンについては、`ansible-build-data `_ のリリース固有のディレクトリーにある :file:`ansible-.build` ファイルを参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:28 -msgid "ansible-base" -msgstr "ansible-base" - -#: ../../rst/reference_appendices/glossary.rst:30 -msgid "Used only for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. See ``ansible-core``." -msgstr "2.10 でのみ使用されます。`ansible/ansible リポジトリー `_ から生成されたインストール可能なパッケージ (RPM/Python/Deb パッケージ) です。「``ansible-core``」を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:31 -#: ../../rst/reference_appendices/release_and_maintenance.rst:10 -msgid "ansible-core" -msgstr "ansible-core" - -#: ../../rst/reference_appendices/glossary.rst:33 -msgid "Name used starting with 2.11. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-core`` package includes a few modules and plugins and allows you to add others by installing collections." -msgstr "2.11 以降で使用される名前。`ansible/ansible リポジトリー `_ から生成されるインストール可能なパッケージ (RPM/Python/Deb パッケージ)。コマンドラインツールと、基本的な機能および関数 (モジュールコードの管理対象ノードへのコピーなど) のコードが含まれています。``ansible-core`` パッケージにはいくつかのモジュールとプラグインが含まれており、コレクションをインストールすることで他のモジュールを追加できます。" - -#: ../../rst/reference_appendices/glossary.rst:34 -msgid "Ansible Galaxy" -msgstr "Ansible Galaxy" - -#: ../../rst/reference_appendices/glossary.rst:36 -msgid "An `online distribution server `_ for finding and sharing Ansible community content, sometimes referred to as community Galaxy. Also, the command-line utility that lets users install individual Ansible Collections, for example ``ansible-galaxy collection install community.crypto``." -msgstr "Ansible コミュニティーのコンテンツ (コミュニティー Galaxy と呼ばれる場合もあり) を見つけて共有するための `online distribution server `_。また、ユーザーが個々の Ansible コレクションをインストールできるようにするコマンドラインユーティリティー (``ansible-galaxy collection install community.crypto`` など)。" - -#: ../../rst/reference_appendices/glossary.rst:37 -msgid "Async" -msgstr "非同期" - -#: ../../rst/reference_appendices/glossary.rst:39 -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`." -msgstr "完了を待たずにバックグラウンドで実行するように構成されたタスクを指します。SSH タイムアウトよりも長く実行される長いプロセスがある場合は、そのタスクを非同期モードで起動することは理にかなっています。非同期モードでは、何秒かごとに完了をポーリングすることも、「ファイアアンドフォーゲット (自動追尾機能)」ように設定することもできます。その場合、Ansible は再度タスクをチェックしません。起動して次のステップに進みます。非同期モードは :command:`/usr/bin/ansible` と :command:`/usr/bin/ansible-playbook` の両方で動作します。" - -#: ../../rst/reference_appendices/glossary.rst:47 -msgid "Callback Plugin" -msgstr "Callback Plugin (コールバックプラグイン)" - -#: ../../rst/reference_appendices/glossary.rst:49 -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." -msgstr "Ansible からの結果を傍受でき、それらについて何らかの処理を行うユーザー作成コードを指します。GitHub プロジェクトで提供されている一部のサンプルの実行内容には、カスタムロギングやメール送信、さらにはサウンド効果のプレイなどが含まれます。" - -#: ../../rst/reference_appendices/glossary.rst:53 -msgid "Check Mode" -msgstr "Check Mode (チェックモード)" - -#: ../../rst/reference_appendices/glossary.rst:55 -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." -msgstr "``--check`` オプションを指定して Ansible を実行することを指します。このオプションを選択してもリモートシステムに変更は加えられることはなく、コマンドがこのフラグなしに実行された場合に生じる可能性のある変更のみを出力します。これは、他のシステムでのいわゆる「ドライラン」モードに類似しています。ただし、この場合は予期しないコマンドの失敗やカスケード効果が考慮されないことに注意してください (他のシステムの同様のモードについても同じです)。このモードを使用すると、起こり得ることの概要を把握することはできますが、これが適切なステージング環境の代わりになる訳ではありません。" - -#: ../../rst/reference_appendices/glossary.rst:63 -msgid "Collection" -msgstr "コレクション" - -#: ../../rst/reference_appendices/glossary.rst:65 -msgid "A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-core`` 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 ``." -msgstr "プラグイン、ロール、モジュールなどを含む Ansible コンテンツをバンドルして配布するためのパッケージングフォーマット。コレクションは他のコレクションまたは ``ansible-core`` とは独立してリリースされるため、ユーザーはより早く機能を利用できます。一部のコレクションは Ansible (バージョン 2.10 以降) でパッケージ化されています。他のコレクション (またはコレクションの他のバージョン) は、``ansible-galaxy collection install `` でインストールできます。" - -#: ../../rst/reference_appendices/glossary.rst:66 -msgid "Collection name" -msgstr "コレクション名" - -#: ../../rst/reference_appendices/glossary.rst:68 -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." -msgstr "完全修飾コレクション名の 2 番目の部分。コレクション名は、コレクションの名前空間を分割し、通常はコレクションの内容の機能を反映します。たとえば、``cisco`` 名前空間には、``cisco.ios``、``cisco.aci``、および ``cisco.nxos`` が含まれ、シスコが管理するさまざまなネットワークデバイスを管理するためのコンテンツが含まれます。" - -#: ../../rst/reference_appendices/glossary.rst:69 -msgid "community.general (collection)" -msgstr "community.general (コレクション)" - -#: ../../rst/reference_appendices/glossary.rst:71 -msgid "A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do not have their own dedicated Collection. See `community.general `_ on Galaxy." -msgstr "Ansible 2.9 に同梱された、専用のコレクションを持たないすべてのモジュールとプラグインを含む Ansible Community Team が管理する特定のコレクション。Galaxy の `community.general `_ を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:72 -msgid "community.network (collection)" -msgstr "community.network (コレクション)" - -#: ../../rst/reference_appendices/glossary.rst:74 -msgid "Similar to ``community.general``, focusing on network content. `community.network `_ on Galaxy." -msgstr "``community.general`` と同様に、ネットワークコンテンツに焦点を宛てています (Galaxy の `community.network `_)。" - -#: ../../rst/reference_appendices/glossary.rst:75 -msgid "Connection Plugin" -msgstr "Connection プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:77 -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 `. 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." -msgstr "デフォルトでは、Ansible はプラグ可能なライブラリーを介してリモートマシンと対話します。Ansible はネイティブの OpenSSH (:term:`SSH (Native)`) や、:term:`paramiko` と呼ばれる Python の実装を使用します。最新バージョンを使用している場合は OpenSSH が推奨され、Kerberos やジャンプホストなどの一部の機能も有効になります。これについては、「:ref:`getting started section `」で説明します。他にも ``accelerate`` モードのような接続タイプがあります。これは SSH ベースの接続タイプのうちのひとつを使用して起動しなければなりませんが、非常に高速です。また、ローカルシステム上で動作するローカルモードもあります。ユーザーは独自の connection プラグインを記述することもできます。" - -#: ../../rst/reference_appendices/glossary.rst:87 -msgid "Conditionals" -msgstr "条件分岐 (Conditional)" - -#: ../../rst/reference_appendices/glossary.rst:89 -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`." -msgstr "条件は、True または False に評価して、指定のタスクを所定のマシンで実行するかどうかを決定する式のことです。Ansible の条件文は、「when」ステートメントによって強化されています。「:ref:`working_with_playbooks`」を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:93 -msgid "Declarative" -msgstr "宣言的 (Declarative)" - -#: ../../rst/reference_appendices/glossary.rst:95 -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." -msgstr "あるタスクを達成するために、その状態を達成するために必要な一連の手順を記述するのではなく、最終的な状態を記述するアプローチのこと。現実世界の例では、「私をカリフォルニアに連れて行ってください」というタスクの宣言的な指定があります。あなたの現在地によって、あなたをカリフォルニアに連れて行くための一連のステップは異なるかもしれないし、あなたがすでにカリフォルニアにいる場合は、何もする必要はありません。Ansible の Resource は宣言型で、最終的な状態を実現するために必要なステップを把握しています。また、最終的な状態に到達するために必要なステップがあるかどうかも知ることができます。" - -#: ../../rst/reference_appendices/glossary.rst:105 -msgid "Diff Mode" -msgstr "差分モード" - -#: ../../rst/reference_appendices/glossary.rst:107 -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." -msgstr "``--diff`` フラグを Ansible に渡して、それをサポートするモジュールで何が変更されたかを示すことができます。``--check`` と組み合わせると優れた「ドライラン」を得ることができます。ファイルの差分は通常、統一された差分形式です。" - -#: ../../rst/reference_appendices/glossary.rst:110 -msgid "Distribution server" -msgstr "配信サーバー" - -#: ../../rst/reference_appendices/glossary.rst:112 -msgid "A server, such as Ansible Galaxy or Red Hat Automation Hub where you can distribute your collections and allow others to access these collections. See :ref:`distributing_collections` for a list of distribution server types. Some Ansible features are only available on certain distribution servers." -msgstr "Ansible Galaxy や Red Hat Automation Hub などのサーバー。コレクションを配布し、他のサーバーがこれらのコレクションにアクセスできるようにします。配信サーバータイプの一覧は、:ref:`distributing_collections` を参照してください。一部の Ansible 機能は、特定の配信サーバーでのみ利用できます。" - -#: ../../rst/reference_appendices/glossary.rst:113 -msgid "Executor" -msgstr "エグゼキューター (Executor)" - -#: ../../rst/reference_appendices/glossary.rst:115 -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 `. The Executor is something Ansible developers may talk about, but it's not really user land vocabulary." -msgstr "Ansible の中核となるソフトウェアコンポーネントで、:command:`/usr/bin/ansible` を直接支える力であり、:term:`Playbook ` の各タスクの呼び出しに対応しています。エグゼキューターは、Ansible の開発者が使用する用語で、ユーザー側が使用する用語ではありません。" - -#: ../../rst/reference_appendices/glossary.rst:120 -#: ../../rst/reference_appendices/special_variables.rst:134 -msgid "Facts" -msgstr "ファクト" - -#: ../../rst/reference_appendices/glossary.rst:122 -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 ` 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 through 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 through ``gather_subset:``)" -msgstr "端的に言うと、ファクトはリモートノードについて発見される事柄を指します。ファクトは変数のように :term:`playbooks` やテンプレートで使用できますが、ファクトは設定される事柄というよりは推測される事柄と言えます。ファクトは、リモートノードで内部 :ref:`setup module ` を実行することでプレイの実行中に Ansible により自動的に検出されるため、セットアップモジュールを明示的に呼び出すことはありません。それはただ実行されます。その必要がなければ時間を節約するために無効にすることもできますし、``gather_subset:`` オプションで全ファクトのサブセットだけを収集するように Ansible に指示することもできます。他の設定管理システムから切り替えを行われている場合の利点として、ファクトモジュールは、Chef と Puppet のファクトライブラリーから、それぞれ :program:`ohai` ツールおよび :program:`facter` ツールからも (インストールされている場合) ファクトを取り込みます (これは ``gather_subset:`` で無効にすることもできます)。" - -#: ../../rst/reference_appendices/glossary.rst:136 -msgid "Filter Plugin" -msgstr "Filter プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:138 -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 `." -msgstr "filter プラグインは、ほとんどのユーザーが理解する必要がないものです。この filter プラグインは、新しい :term:`Jinja2` フィルターを作成するためのもので、多かれ少なかれ、Jinja2 のフィルターを知っている人にしか使えません。必要であれば、:ref:`API ドキュメントのセクション ` で記述方法を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:143 -msgid "Forks" -msgstr "フォーク" - -#: ../../rst/reference_appendices/glossary.rst:145 -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." -msgstr "Ansible は、複数のリモートノードと同時に対話でき、その並列処理のレベルは、``--forks`` を渡すか、設定ファイルのデフォルトを編集することで設定できます。デフォルトには非常に控え目に 5 つのフォークが設定されていますが、RAM が多数ある場合は、並列処理のレベルを上げるために値を大きく (50 など) 設定することもできます。" - -#: ../../rst/reference_appendices/glossary.rst:150 -msgid "Fully Qualified Collection Name (FQCN)" -msgstr "FQCN (完全修飾コレクション名)" - -#: ../../rst/reference_appendices/glossary.rst:152 -msgid "The full definition of a module, plugin, or role hosted within a collection, in the form . 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." -msgstr "コレクション内でホストされているモジュール、プラグイン、またはロールの完全な定義を のような形で示します。Playbook が特定のソースから特定のモジュールまたはプラグインを曖昧さのない方法で参照できるようにします (たとえば、``community.grafana.grafana_dashboard`` です)。FQCN は、プラグインの正確なソースを指定したい場合に必要です。たとえば、複数のコレクションに ``user`` という名前の module プラグインが含まれている場合、FQCN は特定のタスクにどのプラグインを使用するかを指定します。複数のコレクションがインストールされている場合、FQCN は常に、各タスクに適したプラグインをどのコレクションで検索するかを明示的かつ権威的に示します。" - -#: ../../rst/reference_appendices/glossary.rst:153 -msgid "Gather Facts (Boolean)" -msgstr "ファクトの収集 (ブール値)" - -#: ../../rst/reference_appendices/glossary.rst:155 -msgid ":term:`Facts` are mentioned above. Sometimes when running a multi-play :term:`playbook `, 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." -msgstr ":term:`ファクト` は上述のとおりです。マルチプレイ (:term:`Playbook `) を実行する際に、これらの値を利用する必要がない場合は、ファクト計算を行わないプレイをいくつか用意することが望ましい場合があります。Playbook に ``gather_facts: False`` を設定すると、この暗黙のファクト収集を省略することができます。" - -#: ../../rst/reference_appendices/glossary.rst:160 -msgid "Globbing" -msgstr "グラッビング (Globbing)" - -#: ../../rst/reference_appendices/glossary.rst:162 -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." -msgstr "グラッビングとは、特定のホスト名や所属するグループ名ではなく、ワイルドカードに基づいて多数のホストを選択する方法です。たとえば ``ww*`` を選択すると、``www`` で始まるすべてのホストに一致させることができます。この概念は、Ansible の創始者である Michael DeHaan 氏の初期のプロジェクトの 1 つである :program:`Func` から直接引用しています。基本的なグラッビングに加えて、「このグループに含まれ、他のグループには含まれないホスト」など、さまざまなセット操作が可能です。" - -#: ../../rst/reference_appendices/glossary.rst:170 -msgid "Group" -msgstr "グループ" - -#: ../../rst/reference_appendices/glossary.rst:172 -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." -msgstr "グループは、プールに割り当てられた複数のホストで構成されます。これらのホストは、一緒に対象に設定でき、それらが共通して共有する特定の変数です。" - -#: ../../rst/reference_appendices/glossary.rst:175 -msgid "Group Vars" -msgstr "Group Vars (グループ変数)" - -#: ../../rst/reference_appendices/glossary.rst:177 -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 `." -msgstr ":file:`group_vars/` ファイルは、各グループに由来する任意のファイル名で、インベントリーファイルと共にディレクトリーに存在するファイルのことです。このファイルは、特にデータ構造が複雑な場合などに、所定グループに提供される変数を配置できる便利な場所になります。これにより、これらの変数が :term:`inventory` ファイルまたは :term:`Playbook ` に埋め込む必要がなくなります。" - -#: ../../rst/reference_appendices/glossary.rst:183 -msgid "Handlers" -msgstr "Handler (ハンドラー)" - -#: ../../rst/reference_appendices/glossary.rst:185 -msgid "Handlers are just like regular tasks in an Ansible :term:`playbook ` (see :term:`Tasks`) but are only run if the Task contains a ``notify`` keyword 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." -msgstr "ハンドラーは Ansible :term:`playbook ` の通常のタスクのような機能を持ちます (「:term:`Tasks`」を参照) が、タスクに ``notify`` キーワードがあり、変更があったことが示唆される場合にのみ実行されます。たとえば、設定ファイルが変更された後に、設定ファイルを参照するテンプレート作成操作のタスクは、サービス再起動ハンドラーに通知する可能性があります。これは、サービスが再起動する必要がある場合にのみバウンスできることを意味します。ハンドラーはサービスの再起動以外のタスクに使用できますが、サービスの再起動が最も一般的な使用例になります。" - -#: ../../rst/reference_appendices/glossary.rst:193 -msgid "Host" -msgstr "ホスト" - -#: ../../rst/reference_appendices/glossary.rst:195 -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." -msgstr "ホストとは、Ansible が管理するリモートマシンのことです。ホストには、個別に変数を割り当てることも、グループでまとめることもできます。すべてのホストには、アクセス可能な名前 (IP アドレスまたはドメイン名) と、デフォルトの SSH ポートでアクセスしない場合は、任意でポート番号が割り当てられます。" - -#: ../../rst/reference_appendices/glossary.rst:200 -msgid "Host Specifier" -msgstr "Host Specifier (ホスト指定子)" - -#: ../../rst/reference_appendices/glossary.rst:202 -msgid "Each :term:`Play ` in Ansible maps a series of :term:`tasks` (which define the role, purpose, or orders of a system) to a set of systems." -msgstr "Ansible の各 :term:`プレイ ` は、一連の :term:`タスク` (システムのロール、目的、または順序を定義します) を一連のシステムにマッピングします。" - -#: ../../rst/reference_appendices/glossary.rst:205 -msgid "This ``hosts:`` keyword in each play is often called the hosts specifier." -msgstr "各プレイの ``hosts:`` キーワードは、しばしばホスト指定子と呼ばれます。" - -#: ../../rst/reference_appendices/glossary.rst:207 -msgid "It may select one system, many systems, one or more groups, or even some hosts that are in one group and explicitly not in another." -msgstr "1 つのシステム、多数のシステム、1 つ以上のグループ、または 1 つのグループにあり明示的に別のグループにはない複数のホストを選択することができます。" - -#: ../../rst/reference_appendices/glossary.rst:209 -msgid "Host Vars" -msgstr "ホスト変数" - -#: ../../rst/reference_appendices/glossary.rst:211 -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." -msgstr ":term:`Group Vars` のように、インベントリーファイルの横にある :file:`host_vars/` ディレクトリーには、インベントリーファイルの各ホスト名にちなんで :term:`YAML` 形式のファイルを置くことができます。これは、:term:`inventory` ファイルに変数を埋め込まなくても、ホストに変数を割り当てるための便利な場所となります。ホストの vars ファイルは、インベントリーファイルでは表現できない複雑なデータ構造を定義するのにも使用できます。" - -#: ../../rst/reference_appendices/glossary.rst:217 -msgid "Idempotency" -msgstr "冪等性" - -#: ../../rst/reference_appendices/glossary.rst:219 -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." -msgstr "操作を 1 回実行した結果が、何も介入せずに繰り返し実行した結果とまったく同じであれば、操作は冪等です。" - -#: ../../rst/reference_appendices/glossary.rst:222 -msgid "Includes" -msgstr "インクルード (Include)" - -#: ../../rst/reference_appendices/glossary.rst:224 -msgid "The idea that :term:`playbook ` 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``." -msgstr ":term:`Playbook ` のファイル (これは :term:`プレイ` のリストに他ならない) は、他のプレイリストを含むことができ、タスクリストは他のファイルの :term:`タスク` のリストを具体化することができ、:term:`ハンドラー` でも同様となるという考え方です。インクルードはパラメーター化できるため、読み込まれたファイルは変数を渡すことができます。たとえば、WordPress ブログをセットアップするためのインクルードプレイは、``user`` というパラメーターを取り、そのプレイを複数回インクルードすることで、``alice`` と ``bob`` の両方にブログを作成することができます。" - -#: ../../rst/reference_appendices/glossary.rst:232 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/reference_appendices/glossary.rst:234 -msgid "A file (by default, Ansible uses a simple INI format) that describes :term:`Hosts ` and :term:`Groups ` in Ansible. Inventory can also be provided through an :term:`Inventory Script` (sometimes called an \"External Inventory Script\")." -msgstr "Ansible で :term:`Hosts ` と :term:`Groups ` を記述したファイル (デフォルトでは、Ansible は簡単な INI 形式を使用)。インベントリーは、:term:`Inventory Script` (「外部インベントリースクリプト」と呼ばれることもあります) を介して提供することもできます。" - -#: ../../rst/reference_appendices/glossary.rst:238 -msgid "Inventory Script" -msgstr "Inventory Script (インベントリースクリプト)" - -#: ../../rst/reference_appendices/glossary.rst:240 -msgid "A very simple program (or a complicated one) that looks up :term:`hosts `, :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." -msgstr ":term:`ホスト `、ホストの :term:`グループ` メンバーシップ、および変数情報を、SQL データベース、CMDB ソリューションまたは LDAP に類する外部リソースから参照する非常に簡単なプログラム (または複雑なプログラム) のことです。この概念は Puppet (「外部ノード分類子」と呼ばれています) から採用されたもので、ほぼ同じように機能します。" - -#: ../../rst/reference_appendices/glossary.rst:246 -msgid "Jinja2" -msgstr "Jinja2" - -#: ../../rst/reference_appendices/glossary.rst:248 -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." -msgstr "Jinja2 は、Ansible のテンプレートモジュールで推奨されるテンプレート言語です。これは非常にシンプルな Python テンプレート言語であり、一般的に読みやすく、簡単に記述できます。" - -#: ../../rst/reference_appendices/glossary.rst:251 -msgid "JSON" -msgstr "JSON" - -#: ../../rst/reference_appendices/glossary.rst:253 -msgid "Ansible uses JSON for return data from remote modules. This allows modules to be written in any language, not just Python." -msgstr "Ansible はリモートモジュールから返されるデータに JSON を使用します。モジュールは Python だけではなくすべての言語で作成することができます。" - -#: ../../rst/reference_appendices/glossary.rst:255 -msgid "Keyword" -msgstr "キーワード" - -#: ../../rst/reference_appendices/glossary.rst:257 -msgid "The main expressions that make up Ansible, which apply to playbook objects (Play, Block, Role and Task). For example 'vars:' is a keyword that lets you define variables in the scope of the playbook object it is applied to." -msgstr "Ansibleを構成する主な表現で、Playbook オブジェクト（Play、Block、Role、およびTask）に適用されます。たとえば、「vars：」は、適用先の Playbook オブジェクトの範囲内で、変数を定義できるようにするキーワードです。" - -#: ../../rst/reference_appendices/glossary.rst:260 -msgid "Lazy Evaluation" -msgstr "遅延評価" - -#: ../../rst/reference_appendices/glossary.rst:262 -msgid "In general, Ansible evaluates any variables in :term:`playbook ` 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." -msgstr "一般的に Ansible は、:term:`Playbook ` のコンテンツに含まれるすべての変数を可能な限り最後の瞬間に評価します。つまり、データ構造を定義した場合、そのデータ構造自体がその中に変数値を定義することができ、すべてが期待通りに「ただ動く」のです。これは、変数文字列が、その文字列内に他の変数を含むことができることも意味します。" - -#: ../../rst/reference_appendices/glossary.rst:268 -msgid "Library" -msgstr "ライブラリー" - -#: ../../rst/reference_appendices/glossary.rst:270 -msgid "A collection of modules made available to :command:`/usr/bin/ansible` or an Ansible :term:`playbook `." -msgstr ":command:`/usr/bin/ansible` または Ansible :term:`Playbook ` で利用できるようになったモジュールのコレクション。" - -#: ../../rst/reference_appendices/glossary.rst:272 -msgid "Limit Groups" -msgstr "グループの制限" - -#: ../../rst/reference_appendices/glossary.rst:274 -msgid "By passing ``--limit somegroup`` to :command:`ansible` or :command:`ansible-playbook`, the commands can be limited to a subset of :term:`hosts `. For instance, this can be used to run a :term:`playbook ` that normally targets an entire set of servers to one particular server." -msgstr "``--limit somegroup`` を :command:`ansible` または :command:`ansible-playbook` に渡すことで、コマンドを :term:`ホスト ` のサブセットに限定することができます。たとえば、通常はサーバーのセット全体を対象としている :term:`Playbook ` を、特定のサーバーに向けて実行する場合に使用できます。" - -#: ../../rst/reference_appendices/glossary.rst:279 -msgid "Local Action" -msgstr "ローカルアクション" - -#: ../../rst/reference_appendices/glossary.rst:281 -msgid "This keyword is an alias for ``delegate_to: localhost``. Used when you want to redirect an action from the remote to execute on the controller itself." -msgstr "このキーワードは ``delegate_to: localhost`` のエイリアスです。リモートからアクションをリダイレクトしてコントローラー自体で実行する場合に使用します。" - -#: ../../rst/reference_appendices/glossary.rst:284 -msgid "Local Connection" -msgstr "ローカル接続" - -#: ../../rst/reference_appendices/glossary.rst:286 -msgid "By using ``connection: local`` in a :term:`playbook `, or passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates that we are executing a local fork instead of executing on the remote machine. You probably want ``local_action`` or ``delegate_to: localhost`` instead as this ONLY changes the connection and no other context for execution." -msgstr ":term:`playbook ` でを ``connection: local`` 使用するか、:command:`/usr/bin/ansible` に ``-c local`` を指定することで、リモートマシンで実行するのではなく、ローカルのフォークを実行することを指示します。コネクションだけが変更されて、実行の他のコンテキストを変更しないので、代わりに ``local_action`` か ``delegate_to: localhost`` を指定することを推奨します。" - -#: ../../rst/reference_appendices/glossary.rst:291 -msgid "Lookup Plugin" -msgstr "Lookup プラグイン" - -#: ../../rst/reference_appendices/glossary.rst:293 -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." -msgstr "Lookup プラグインとは、外部から Ansible にデータを取り込むための方法です。Lookup プラグインは Jinja2 の拡張機能で、``{{ lookup('file','/path/to/file') }}`` などのテンプレートでアクセスできます。``with_items`` のようなものがこれらによって実装されています。Lookup プラグインには、``file`` のようにファイルからデータを読み込むものや、環境変数や DNS のテキストレコード、キーバリューストアなどを照会するものもあります。" - -#: ../../rst/reference_appendices/glossary.rst:300 -msgid "Loops" -msgstr "ループ" - -#: ../../rst/reference_appendices/glossary.rst:302 -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 ` and :ref:`apt `, 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." -msgstr "一般的に、Ansible はプログラミング言語ではありません。しかし、``loop`` のような様々な構造によって、リストの複数のアイテムに対して特定のタスクを繰り返すことができます。:ref:`yum ` や:ref:`apt ` などのモジュールは、実際にリストを直接受け取り、それらのリストで指定されたすべてのパッケージを 1 つのトランザクション内でインストールすることができ、設定にかかる時間を劇的に短縮することができます。したがってループを使用せずに使用できます。" - -#: ../../rst/reference_appendices/glossary.rst:309 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/reference_appendices/glossary.rst:311 -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 take advantage of 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`." -msgstr "モジュールは、Ansible がリモートマシンに送出する作業単位です。モジュールは、:command:`/usr/bin/ansible` か :command:`/usr/bin/ansible-playbook` (複数のタスクが多数の異なるモジュールを組み合わせて使用する場合) のいずれかで起動します。モジュールは、Perl、Bash、Ruby を含む任意の言語で実装できますが、Python で記述されている場合は、いくつかの有用な共通ライブラリーコードを利用できます。モジュールは :term:`JSON` を返せば十分です。モジュールがリモートマシン上で実行すると、それらは削除されるため、実行中のデーモンは使用されません。Ansible は、利用可能なモジュールの集合を :term:`library` として参照します。" - -#: ../../rst/reference_appendices/glossary.rst:321 -msgid "Multi-Tier" -msgstr "多層" - -#: ../../rst/reference_appendices/glossary.rst:323 -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." -msgstr "IT システムは、一度に 1 つのシステムではなく、複数のシステムとシステムのグループ間の相互作用によって、明確に定義された順序で管理されるという概念です。たとえば、データベースサーバーの前に Web サーバーを更新する必要があり、*その* データベースサーバーとさまざまなロードバランサーおよび監視サーバーに接続する必要がある場合は、Web サーバー上の部分を更新する必要があります。Ansible は、「一度に 1 つのシステム」の観点から構成を検討するのではなく、IT トポロジーとワークフロー全体をモデル化します。" - -#: ../../rst/reference_appendices/glossary.rst:331 -msgid "Namespace" -msgstr "名前空間" - -#: ../../rst/reference_appendices/glossary.rst:333 -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 `_ on the Galaxy docsite for namespace requirements." -msgstr "完全修飾コレクション名の最初の部分で、名前空間は通常、機能的なコンテンツカテゴリーを反映しています。たとえば、``cisco.ios.ios_config`` では、``cisco`` が名前空間になります。名前空間は Red Hat によって予約され、Red Hat の裁量で配布されます。すべてではありませんが、多くの名前空間はベンダーの名前に対応しています。名前空間の要件については、Galaxy ドキュメントサイトの「`Galaxy 名前空間 `_」を参照してください。" - -#: ../../rst/reference_appendices/glossary.rst:334 -msgid "Notify" -msgstr "Notify (通知)" - -#: ../../rst/reference_appendices/glossary.rst:336 -msgid "The act of a :term:`task ` registering a change event and informing a :term:`handler ` task that another :term:`action` needs to be run at the end of the :term:`play `. 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." -msgstr "変更イベントを登録し、:term:`ハンドラー ` タスクに :term:`プレイ ` の終了時に別の :term:`操作` の実行が必要であることを知らせる :term:`タスク ` の行為です。ハンドラーが複数のタスクによる通知を受けても、ハンドラーは 1 回のみ実行されます。ハンドラーは、それらが通知を受けた順番ではなく、一覧表示された順に実行されます。" - -#: ../../rst/reference_appendices/glossary.rst:342 -msgid "Orchestration" -msgstr "オーケストレーション" - -#: ../../rst/reference_appendices/glossary.rst:344 -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 のオーケストレーションは、このようなプロセスをモデル化するためのものです。" - -#: ../../rst/reference_appendices/glossary.rst:355 -msgid "paramiko" -msgstr "Paramiko" - -#: ../../rst/reference_appendices/glossary.rst:357 -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." -msgstr "デフォルトでは、Ansible は SSH でマシンを管理します。Ansible がこれを行うためにデフォルトで使用しているのは、paramiko という名前の Python を使用したライブラリーです。paramiko ライブラリーは一般的に高速で管理も簡単ですが、Kerberos や Jump Host を使用する場合は、:term:`Playbook` で接続タイプを指定するか、``-c ssh`` フラグを使用して OpenSSH などのネイティブな SSH バイナリーに切り替えたほうが良いでしょう。" - -#: ../../rst/reference_appendices/glossary.rst:363 -msgid "Playbooks" -msgstr "Playbook" - -#: ../../rst/reference_appendices/glossary.rst:365 -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 :)" -msgstr "Playbook は、Ansible がシステムのオーケストレーション、設定、管理、またはデプロイするための言語です。これが Playbook と呼ばれるのは、ある種スポーツに似ており、それを使用することで楽しめるからです。したがって、ワークブックではありません。" - -#: ../../rst/reference_appendices/glossary.rst:369 -msgid "Plays" -msgstr "プレイ" - -#: ../../rst/reference_appendices/glossary.rst:371 -msgid "A :term:`playbook ` is a list of plays. A play is minimally a mapping between a set of :term:`hosts ` selected by a host specifier (usually chosen by :term:`groups ` but sometimes by hostname :term:`globs `) 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." -msgstr ":term:`Playbook ` はプレイのリストです。最小単位のプレイのマッピングは、ホスト指定子で選択される :term:`ホスト ` のセット (通常は :term:`グループ ` で選択されますが、ホスト名 :term:`グロブ ` で選択されることもある) と、システムが実行するロールを定義するためにホストで実行される :term:`タスク` 間のマッピングです。Playbook には 1 つまたは数多くのプレイが含まれる場合があります。" - -#: ../../rst/reference_appendices/glossary.rst:377 -msgid "Pull Mode" -msgstr "プルモード" - -#: ../../rst/reference_appendices/glossary.rst:379 -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 `. Most Ansible users use push mode, but pull mode is included for variety and the sake of having choices." -msgstr "デフォルトでは、Ansible は :term:`プッシュモード` で実行します。これにより、各システムと対話するタイミングを非常に細かく制御することができます。また、特定のスケジュールで N 分ごとにノードをチェックしたい場合は、プルモードが用意されています。これには :command:`ansible-pull` というプログラムを使用します。また、プッシュモード :term:`Playbook ` を使用して設定 (または再設定) することもできます。ほとんどの Ansible ユーザーはプッシュモードを使用していますが、多様性と選択肢を持たせるためにプルモードも含まれています。" - -#: ../../rst/reference_appendices/glossary.rst:388 -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." -msgstr ":command:`ansible-pull` は、crontab で git から設定順序を確認し、:term:`local connection` プラグインを使用してマシンをローカルで管理することで機能します。" - -#: ../../rst/reference_appendices/glossary.rst:391 -msgid "Pulp 3 Galaxy" -msgstr "Pulp 3 Galaxy" - -#: ../../rst/reference_appendices/glossary.rst:393 -msgid "A self-hosted distribution server based on the `GalaxyNG codebase `_, based on Pulp version 3. Use it to find and share your own curated set of content. You can access your content with the ``ansible-galaxy collection`` command." -msgstr "Pulp バージョン 3 をベースとする、`GalaxyNG codebase `_ に基づくセルフホスト配信サーバー。これを使用して、独自のキュレートされたコンテンツセットを見つけて共有します。コンテンツは、``ansible-galaxy collection`` コマンドを使用してアクセスできます。" - -#: ../../rst/reference_appendices/glossary.rst:395 -msgid "Push Mode" -msgstr "プッシュモード" - -#: ../../rst/reference_appendices/glossary.rst:397 -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." -msgstr "プッシュモードは、Ansible のデフォルトモードです。実際には、モードというよりも、意識していないときに Ansible がどのように動作するかを示すものです。プッシュモードでは、Ansible を細かく設定することができ、複雑なオーケストレーションプロセスでもノードのチェックインを待たずに実行することができます。" - -#: ../../rst/reference_appendices/glossary.rst:402 -msgid "Register Variable" -msgstr "登録変数" - -#: ../../rst/reference_appendices/glossary.rst:404 -msgid "The result of running any :term:`task ` 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." -msgstr "Ansible で :term:`タスク ` を実行した結果を変数に格納し、テンプレートや条件文で使用することができます。変数の定義に使用されるキーワードは ``register`` と呼ばれ、その名前はアセンブリープログラミングにおけるレジスターの考え方に由来しています (ただし、Ansible がアセンブリープログラミングのように感じることはありません)。登録に使用できる変数名は無限にあります。" - -#: ../../rst/reference_appendices/glossary.rst:410 -msgid "Resource Model" -msgstr "リソースモデル" - -#: ../../rst/reference_appendices/glossary.rst:412 -msgid "Ansible modules work in terms of resources. For instance, the :ref:`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 ` 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." -msgstr "Ansible モジュールは、リソースの観点から動作します。たとえば、:ref:`ファイルモジュール ` は、特定のファイルを選択し、そのリソースの属性が特定のモデルと一致することを確認します。たとえば、:file:`/etc/motd` の所有者が ``root`` に設定されていなければ ``root`` に変更し、そのモードが ``0644`` に設定されていなければ ``0644`` に設定したいとします。リソースモデルは :term:`冪等 `、つまり変更コマンドは必要な時以外は実行されず、Ansible は、実際の状態に関わらず、システムを望ましい状態に戻してくれますが、その状態になるための方法を指示する必要はありません。" - -#: ../../rst/reference_appendices/glossary.rst:422 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/reference_appendices/glossary.rst:424 -msgid "Roles are units of organization in Ansible. Assigning a role to a group of :term:`hosts ` (or a set of :term:`groups `, or :term:`host patterns `, 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." -msgstr "ロールは Ansible における組織単位です。ロールを :term:`ホスト ` のグループ (もしくは :term:`グループ ` または :term:`ホストパターン ` のセットなど) に割り当てることは、ホストのグループが特定の動作を実装することを意味します。ロールには特定の変数の値、特定の :term:`タスク`、特定の :term:`ハンドラー`、またはこれらの 1 つまたは複数を適用することが含まれます。ファイル構造がロールに関連付けられていることから、ロールは再配布可能な単位であり、これを使用して :term:`Playbook` 間または他のユーザーと動作を共有することができます。" - -#: ../../rst/reference_appendices/glossary.rst:432 -msgid "Rolling Update" -msgstr "ローリング更新" - -#: ../../rst/reference_appendices/glossary.rst:434 -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." -msgstr "一度にすべてのノードを更新してシステムがオフラインになるのを回避するために、グループ N 内のいくつかのノードに対して一度に処理する行為。たとえば、非常に大きなボリュームを扱う 500 台のノードからなる Web トポロジーでは、一度に 10 台または 20 台のマシンを更新し、更新が完了したら次の 10 台または 20 台に移るのが妥当な場合があります。Ansible :term:`Playbook` の ``serial:`` キーワードは、ローリングアップデートプールのサイズを制御します。デフォルトでは、一度にバッチサイズに対応するようになっているため、これを選択する必要があります。OS の設定 (設定ファイルが正しいかどうかの確認など) では、通常、ローリングアップデートモデルを使用する必要はありませんが、必要に応じて使用することができます。" - -#: ../../rst/reference_appendices/glossary.rst:444 -msgid "Serial" -msgstr "シリアル" - -#: ../../rst/reference_appendices/glossary.rst:448 -msgid ":term:`Rolling Update`" -msgstr ":term:`ローリングアップデート`" - -#: ../../rst/reference_appendices/glossary.rst:449 -msgid "Sudo" -msgstr "Sudo" - -#: ../../rst/reference_appendices/glossary.rst:451 -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 `, :ref:`template `, and :ref:`fetch ` modules while running in sudo mode." -msgstr "Ansible では root ログインが不要であり、デーモンも不要のため、root レベルのデーモンも要求されません (これは機密環境ではセキュリティー上の懸念点となる可能性があります)。Ansible は sudo コマンドでログインでき、このコマンドでラップされた数多くの操作を実行でき、パスワードなしか、またはパスワードを使用する sudo で機能します。通常 sudo で機能しない操作 (scp ファイル転送など) については、sudo モードで実行中の Ansible の :ref:`copy `、:ref:`template `、および :ref:`fetch ` モジュールを使用して実行できます。" - -#: ../../rst/reference_appendices/glossary.rst:459 -msgid "SSH (Native)" -msgstr "SSH (ネイティブ)" - -#: ../../rst/reference_appendices/glossary.rst:461 -msgid "Native OpenSSH as an Ansible transport is specified with ``-c ssh`` (or a config file, or a keyword in the :term:`playbook `) and can be useful if wanting to login through 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." -msgstr "Ansible のトランスポートとしてのネイティブな OpenSSH は、``-c ssh`` (または設定ファイル、あるいは :term:`playbook ` のキーワード) で指定します。これは Kerberized SSH でログインしたい場合や、SSH ジャンプホストを使用したい場合などに便利です。1.2.1 では、コントロールマシン上の OpenSSH バイナリーが十分に新しい場合は、``ssh`` がデフォルトで使用されます。これまでの Ansible では、デフォルトで ``paramiko`` が選択されていました。最大限のパフォーマンスを得るためには、``ControlMaster`` および ``ControlPersist`` をサポートしているクライアントを使用することが推奨されています。もしそれがなく、Kerberos やジャンプホストなどの機能が不要な場合は、``paramiko`` を使用することが推奨されます。Ansible は、ControlMaster/ControlPersist 機能を検出できないと警告を発します。" - -#: ../../rst/reference_appendices/glossary.rst:472 -msgid "Tags" -msgstr "タグ" - -#: ../../rst/reference_appendices/glossary.rst:474 -msgid "Ansible allows tagging resources in a :term:`playbook ` 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." -msgstr "Ansible では、:term:`Playbook ` 内のリソースに任意のキーワードをタグ付けし、そのキーワードに対応する Playbook の部分のみを実行することができます。たとえば、OS 全体の設定を行い、特定のステップにラベル ``ntp`` を付け、``ntp`` のステップだけを実行して、リモートホストのタイムサーバー情報を再設定することができます。" - -#: ../../rst/reference_appendices/glossary.rst:480 -#: ../../rst/reference_appendices/playbooks_keywords.rst:348 -msgid "Task" -msgstr "タスク" - -#: ../../rst/reference_appendices/glossary.rst:482 -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 keywords `). :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." -msgstr ":term:`Playbooks` はタスクを実行するために存在します。タスクは、:term:`action` (モジュールとその引数) と名前、そして (:term:`looping keywords ` のような) その他の任意のキーワードを組み合わせたものです。:term:`Handlers` もタスクですが、これは特別な種類のタスクで、タスクがリモートシステム上で根本的な変更を報告したときに名前で通知されない限り実行されません。" - -#: ../../rst/reference_appendices/glossary.rst:488 -msgid "Tasks" -msgstr "タスク" - -#: ../../rst/reference_appendices/glossary.rst:490 -msgid "A list of :term:`Task`." -msgstr ":term:`タスク` の一覧です。" - -#: ../../rst/reference_appendices/glossary.rst:491 -msgid "Templates" -msgstr "テンプレート" - -#: ../../rst/reference_appendices/glossary.rst:493 -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." -msgstr "Ansible は、ファイルをリモートシステムに簡単に転送できますが、他のファイルの変数を置き換えることが望ましい場合があります。変数は、:term:`inventory` ファイル、:term:`Host Vars`、:term:`Group Vars`、または :term:`ファクト` から設定できます。テンプレートは、:term:`Jinja2` テンプレートエンジンを使用し、ループや if ステートメントなどの論理構造を含めることもできます。" - -#: ../../rst/reference_appendices/glossary.rst:499 -msgid "Transport" -msgstr "トランスポート" - -#: ../../rst/reference_appendices/glossary.rst:501 -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 ` (using OpenSSH), and :term:`local `." -msgstr "Ansible は :term:``Connection Plugins`` を使用して、利用可能なトランスポートの種類を定義します。これらは単に、Ansible が管理されたシステムに到達する方法です。含まれるトランスポートは、:term:`paramiko`、:term:`ssh ` (OpenSSH を使用)、および :term:`local ` です。" - -#: ../../rst/reference_appendices/glossary.rst:506 -msgid "When" -msgstr "When" - -#: ../../rst/reference_appendices/glossary.rst:508 -msgid "An optional conditional statement attached to a :term:`task ` 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." -msgstr ":term:`タスク ` に付けられた任意の条件文で、タスクが実行されるべきかどうかを判断するために使用されます。``when:`` キーワードに続く式が false と評価された場合、そのタスクは無視されます。" - -#: ../../rst/reference_appendices/glossary.rst:511 -msgid "Vars (Variables)" -msgstr "変数" - -#: ../../rst/reference_appendices/glossary.rst:513 -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)." -msgstr ":term:`ファクト` とは対照的に、変数は、テンプレートや :term:`Playbook` で使用できる値の名前 (整数、ブール値、文字列などの単純なスカラー値など) や複雑な名前 (ディクショナリー/ハッシュ、リスト) となります。これらは宣言されたものであり、リモートシステムの現在の状態や性質から推測されるものではありません (これがファクトです)。" - -#: ../../rst/reference_appendices/glossary.rst:519 -msgid "YAML" -msgstr "YAML" - -#: ../../rst/reference_appendices/glossary.rst:521 -msgid "Ansible does not want to force people to write programming language code to automate infrastructure, so Ansible uses YAML to define :term:`playbook ` 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)." -msgstr "Ansible は、インフラストラクチャーを自動化するためのプログラミング言語コードの記述を強制しないように、YAML を使用して :term:`Playbook ` 設定言語と変数ファイルを定義します。YAML は、最小限の構文しか使用されていないため、非常にわかりやすく、簡単に確認できるため優れています。これは、設定ファイルやユーザーにとって優れたデータ形式ですが、機械でも判別可能です。Ansible での YAML の使用は、2006 年頃に Michael DeHaan が Cobbler 内で最初に使用したことに端を発しています。YAML は動的言語コミュニティーで非常に人気があり、この形式には多くの言語 (Python、Perl、Ruby など) でシリアル化できるライブラリーがあります。" - -#: ../../rst/reference_appendices/glossary.rst:534 -msgid ":ref:`ansible_faq`" -msgstr ":ref:`ansible_faq`" - -#: ../../rst/reference_appendices/glossary.rst:535 -msgid "Frequently asked questions" -msgstr "よくある質問 (FAQ)" - -#: ../../rst/reference_appendices/glossary.rst:540 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:4 -msgid "Interpreter Discovery" -msgstr "インタープリターの検出" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:6 -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." -msgstr "POSIX 環境で実行されるほとんどの Ansible モジュールには、ターゲットホスト上に Python インタープリターが必要です。特に設定されていない限り、Ansible は、Python モジュールがそのホストに対して最初に実行されるときに、各ターゲットホストで適切な Python インタープリターを検出しようとします。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:11 -msgid "To control the discovery behavior:" -msgstr "検出動作を制御するには、以下を実行します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:13 -msgid "for individual hosts and groups, use the ``ansible_python_interpreter`` inventory variable" -msgstr "個別のホストおよびグループの場合は、``ansible_python_interpreter`` インベントリー変数を使用します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:14 -msgid "globally, use the ``interpreter_python`` key in the ``[defaults]`` section of ``ansible.cfg``" -msgstr "グローバル設定として、``interpreter_python`` の ``[defaults]`` セクションに ``ansible.cfg`` キーを使用します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:16 -msgid "Use one of the following values:" -msgstr "以下のいずれかの値を使用します。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:31 -msgid "auto_legacy :" -msgstr "auto_legacy:" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:19 -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." -msgstr "ターゲット OS プラットフォーム、ディストリビューション、およびバージョンを検出してから、各プラットフォーム/ディストリビューション/バージョンに適した Python インタープリターとパスを表示するテーブルを参照します。エントリーが見つかり、``/usr/bin/python`` が存在していない場合は、検出されたインタープリター (およびパス) を使用します。エントリーが見つかり、``/usr/bin/python`` が存在する場合は、``/usr/bin/python`` を使用して警告を出力します。この例外は、常に ``/usr/bin/python`` にデフォルトで設定されていた以前のバージョンの Ansible との一時的な互換性を提供されているため、Python や一部のホストの ``/usr/bin/python`` にその他の依存関係である場合は、Ansible はこの設定でそれらを見つけて使用します。エントリーが見つからなかった場合や、リストされた Python がターゲットホストにない場合は、一般的な Python インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別の Python インタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:41 -msgid "auto" -msgstr "auto" - -msgid "(default in 2.12)" -msgstr "(2.12 でデフォルト)" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:34 -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 インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別のインタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:44 -msgid "auto_legacy_silent" -msgstr "auto_legacy_silent" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:44 -msgid "Same as ``auto_legacy``, but does not issue warnings." -msgstr "``auto_legacy`` と同じですが、警告は表示しません。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:47 -msgid "auto_silent" -msgstr "auto_silent" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:47 -msgid "Same as ``auto``, but does not issue warnings." -msgstr "``auto`` と同じですが、警告は表示しません。" - -#: ../../rst/reference_appendices/interpreter_discovery.rst:49 -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." -msgstr "``ansible_python_interpreter`` を変数レベルで特定のパスに設定できます (例: host_vars に、vars ファイルに、Playbook になど)。特定のパスを設定すると、自動インタープリターの検出が完全に無効化され、Ansible は常に指定されたパスを使用します。" - -#: ../../rst/reference_appendices/logging.rst:3 -msgid "Logging Ansible output" -msgstr "Ansible 出力のロギング" - -#: ../../rst/reference_appendices/logging.rst:5 -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:" -msgstr "デフォルトでは、Ansible はプレイ、タスク、およびモジュール引数の出力を、コントロールノードの画面 (STDOUT) に送信します。Ansible 出力をログに記録する場合は、以下の 3 つのオプションを使用することができます。" - -#: ../../rst/reference_appendices/logging.rst:7 -msgid "To save Ansible output in a single log on the control node, set the ``log_path`` :ref:`configuration file setting `. You may also want to set ``display_args_to_stdout``, which helps to differentiate similar tasks by including variable values in the Ansible output." -msgstr "コントロールノードの 1 つのログに Ansible 出力を保存するには、``log_path`` の :ref:`設定ファイルオプション ` を設定します。``display_args_to_stdout`` を設定すると、Ansible の出力に変数の値を追加し、同様のタスクを区別しやすくなります。" - -#: ../../rst/reference_appendices/logging.rst:8 -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 `." -msgstr "各管理ノードごとに異なるログに Ansible 出力を保存するには、``no_target_syslog`` および ``syslog_facility`` の :ref:`構成ファイル設定 ` を設定します。" - -#: ../../rst/reference_appendices/logging.rst:9 -msgid "To save Ansible output to a secure database, use AWX or :ref:`Red Hat Ansible Automation Platform `. You can then review history based on hosts, projects, and particular inventories over time, using graphs and/or a REST API." -msgstr "Ansible の出力を安全なデータベースに保存するには、AWX または :ref:`Red Hat Ansible Automation Platform ` を使用します。こうすることでグラフや 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." -msgstr "Ansible 出力をログに保存すると、パスワードやユーザー名などの秘密データが Ansible 出力に公開されます。機密性の高い値をログに記録しないようにするには、それらを公開するタスクに、``no_log: True`` 属性で印を付けます。ただし、``no_log`` 属性は、デバッグ出力に影響を与えないため、実稼働環境で Playbook をデバッグしないように注意してください。サンプルは、「:ref:`keep_secret_data`」を参照してください。" - -#: ../../rst/reference_appendices/module_utils.rst:6 -msgid "Ansible Reference: Module Utilities" -msgstr "Ansible 参考資料: モジュールユーティリティー" - -#: ../../rst/reference_appendices/module_utils.rst:8 -msgid "This page documents utilities intended to be helpful when writing Ansible modules in Python." -msgstr "このページでは、Python で Ansible モジュールを記述するときに役立つユーティリティーについてまとめています。" - -#: ../../rst/reference_appendices/module_utils.rst:13 -msgid "AnsibleModule" -msgstr "AnsibleModule" - -#: ../../rst/reference_appendices/module_utils.rst:15 -msgid "To use this functionality, include ``from ansible.module_utils.basic import AnsibleModule`` in your module." -msgstr "この機能を使用するには、モジュールに ``from ansible.module_utils.basic import AnsibleModule`` を追加します。" - -#: ansible.module_utils.basic.AnsibleModule:1 of -msgid "Common code for quickly building an ansible module in Python (although you can write modules with anything that can return JSON)." -msgstr "Python で Ansible モジュールを迅速に構築するための一般的なコード (ただし、JSON を返すことができるものならなんでもモジュールを作成できます）。" - -#: ansible.module_utils.basic.AnsibleModule:4 of -msgid "See :ref:`developing_modules_general` for a general introduction and :ref:`developing_program_flow_modules` for more detailed explanation." -msgstr "全般の概要は「:ref:`developing_modules_general`」を参照してください。詳細な説明は「:ref:`developing_program_flow_modules`」を参照してください。" - -#: ansible.module_utils.basic.AnsibleModule.add_path_info:1 of -msgid "for results that are files, supplement the info about the file in the return path with stats about the file path." -msgstr "ファイルの結果については、ファイルパスに関する統計で、リターンパスのファイルに関する情報を補完します。" - -#: 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" -msgstr "src を dest にアトミックに移動し、dest から属性をコピーし、成功すると true を返します。これはアトミック操作であるため、os.rename を使用してこれを確認します。残りの関数は、制限や、めったに発生しない厄介なケースを回避し、可能であれば selinux コンテキストが保存されるようにします。" - -#: ansible.module_utils.basic.AnsibleModule.backup_local:1 of -msgid "make a date-marked backup of the specified file, return True or False on success or failure" -msgstr "指定されたファイルの日付マーク付きバックアップを作成し、成功した場合は True、失敗した場合は False を返します" - -#: ansible.module_utils.basic.AnsibleModule.boolean:1 of -msgid "Convert the argument to a boolean" -msgstr "引数をブール値に変換します。" - -#: ansible.module_utils.basic.AnsibleModule.digest_from_file:1 of -msgid "Return hex digest of local file for a digest_method specified by name, or None if file is not present." -msgstr "名前が指定した digest_method のローカルファイルの 16 進数ダイジェストを返します。ファイルが存在しない場合は None を返します。" - -#: ansible.module_utils.basic.AnsibleModule.exit_json:1 of -msgid "return from the module, without error" -msgstr "モジュールから返します。エラーはありません。" - -#: ansible.module_utils.basic.AnsibleModule.fail_json:1 of -msgid "return from the module, with an error message" -msgstr "エラーメッセージを含むモジュールから返します。" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point:1 of -msgid "Takes a path and returns it's mount point" -msgstr "パスを取得し、そのマウントポイントを返します。" - -#: ../../rst/reference_appendices/module_utils.rst:50 -#: ansible.module_utils.basic.AnsibleModule.find_mount_point -#: ansible.module_utils.basic.AnsibleModule.get_bin_path -#: ansible.module_utils.basic.AnsibleModule.run_command -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate -#: ansible.module_utils.common.arg_spec.ValidationResult -#: ansible.module_utils.common.file.is_executable -#: ansible.module_utils.common.parameters.sanitize_keys -#: ansible.module_utils.common.validation.check_missing_parameters -#: ansible.module_utils.common.validation.check_mutually_exclusive -#: ansible.module_utils.common.validation.check_required_arguments -#: ansible.module_utils.common.validation.check_required_by -#: ansible.module_utils.common.validation.check_required_if -#: ansible.module_utils.common.validation.check_required_one_of -#: ansible.module_utils.common.validation.check_required_together -#: ansible.module_utils.common.validation.check_type_bool -#: ansible.module_utils.common.validation.check_type_dict -#: ansible.module_utils.common.validation.check_type_float -#: ansible.module_utils.common.validation.check_type_int -#: ansible.module_utils.common.validation.check_type_list -#: ansible.module_utils.common.validation.check_type_str -#: ansible.module_utils.common.validation.count_terms of -msgid "Parameters" -msgstr "パラメーター" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point:3 of -msgid "a string type with a filesystem path" -msgstr "ファイルシステムパスがある文字列のタイプ" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point -#: ansible.module_utils.basic.AnsibleModule.get_bin_path -#: ansible.module_utils.basic.AnsibleModule.run_command -#: ansible.module_utils.basic.get_platform -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate -#: ansible.module_utils.common.parameters.sanitize_keys -#: ansible.module_utils.common.validation.check_missing_parameters -#: ansible.module_utils.common.validation.check_mutually_exclusive -#: ansible.module_utils.common.validation.check_required_arguments -#: ansible.module_utils.common.validation.check_required_by -#: ansible.module_utils.common.validation.check_required_if -#: ansible.module_utils.common.validation.check_required_one_of -#: ansible.module_utils.common.validation.check_required_together -#: ansible.module_utils.common.validation.check_type_bool -#: ansible.module_utils.common.validation.check_type_dict -#: ansible.module_utils.common.validation.check_type_float -#: ansible.module_utils.common.validation.check_type_int -#: ansible.module_utils.common.validation.check_type_list -#: ansible.module_utils.common.validation.check_type_str -#: ansible.module_utils.common.validation.count_terms of -msgid "Returns" -msgstr "戻り値" - -#: ansible.module_utils.basic.AnsibleModule.find_mount_point:4 of -msgid "the path to the mount point as a text type" -msgstr "テキストタイプとしてのマウントポイントへのパス" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:1 of -msgid "Find system executable in PATH." -msgstr "PATH でシステムの実行ファイルを検索します。" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:3 of -msgid "The executable to find." -msgstr "検索する実行ファイル。" - -#: ansible.module_utils.basic.AnsibleModule.get_bin_path:4 of -msgid "if executable is not found and required is ``True``, fail_json" -msgstr "実行ファイルが見つからず、required が ``True`` の場合は、fail_json となります。" - -#: 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.common.file.is_executable:1 of -msgid "is the given path executable?" -msgstr "指定のパスは実行ファイルですか。" - -#: ansible.module_utils.common.file.is_executable:3 of -msgid "The path of the file to check." -msgstr "確認するファイルのパス。" - -#: ansible.module_utils.common.file.is_executable:5 of -msgid "Limitations:" -msgstr "制限事項:" - -#: ansible.module_utils.common.file.is_executable:7 of -msgid "Does not account for FSACLs." -msgstr "FSACL を考慮しません。" - -#: ansible.module_utils.common.file.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." -msgstr "ほとんどの場合は、「現在のユーザーがこのファイルを実行できるかどうか」を本当に知りたいのです。この関数は、実行ビットが設定されているかどうかだけで、それを知ることはできません。" - -#: 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)." -msgstr "指定されたパスが NFS またはその他の「特別な」fs マウントポイント上にある場合は (True, selinux_context) を含むタプルを返し、そうでない場合は (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." -msgstr "多くのモジュールがファイルを扱うため、ファイルモジュールが受け付ける共通のオプションをカプセル化して、すべてのモジュールが直接利用できるようにし、コードを共有できるようにしています。" - -#: ansible.module_utils.basic.AnsibleModule.load_file_common_arguments:5 of -msgid "Allows to overwrite the path/dest module argument by providing path." -msgstr "パスを指定して、パス/dest モジュール引数を上書きできるようにします。" - -#: ansible.module_utils.basic.AnsibleModule.md5:1 of -msgid "Return MD5 hex digest of local file using digest_from_file()." -msgstr "digest_from_file() を使用してローカルファイルの MD5 hex ダイジェストを返します。" - -#: 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." -msgstr "これは実行するコマンドです * 引数がリストの場合、コマンドは shell=False で実行します。 * 引数が文字列で、use_unsafe_shell=False の場合は、引数をリストに分割して shell=False で実行します * 引数が文字列で use_unsafe_shell=True の場合は、shell=True で実行します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw check_rc" -msgstr "kw check_rc" - -#: ansible.module_utils.basic.AnsibleModule.run_command:7 of -msgid "Whether to call fail_json in case of non zero RC. Default False" -msgstr "RC がゼロ以外の場合に fail_json を呼び出すかどうか。デフォルトは False です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw close_fds" -msgstr "kw close_fds" - -#: ansible.module_utils.basic.AnsibleModule.run_command:9 of -msgid "See documentation for subprocess.Popen(). Default True" -msgstr "subprocess.Popen() のドキュメントを参照してください。デフォルト は True です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw executable" -msgstr "kw executable" - -#: ansible.module_utils.basic.AnsibleModule.run_command:10 of -msgid "See documentation for subprocess.Popen(). Default None" -msgstr "subprocess.Popen() のドキュメントを参照してください。デフォルトは None です。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw data" -msgstr "kw data" - -#: ansible.module_utils.basic.AnsibleModule.run_command:11 of -msgid "If given, information to write to the stdin of the command" -msgstr "指定した場合は、コマンドの stdin に書き込む情報。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw binary_data" -msgstr "kw binary_data" - -#: ansible.module_utils.basic.AnsibleModule.run_command:12 of -msgid "If False, append a newline to the data. Default False" -msgstr "False の場合は、データに新しい行を追加します。デフォルトは False です。" - -#: 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" -msgstr "指定されている場合は、コマンドを見つけるための追加のパスです。これにより、PATH 環境変数が追加されるため、同じディレクトリー内のヘルパーコマンドも見つけることができます。" - -#: 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)" -msgstr "標準出力内のプロンプトを検出するために使用できる Regex 文字列 (コンパイルされた正規表現ではありません)。そうしないと、実行がハングします (特に入力データが指定されていない場合)。" - -#: 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* environ variables with" -msgstr "環境変数を*更新*するディクショナリー" - -#: 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." -msgstr "ネイティブ文字列を返すため、python3 では、バイトからテキストに変換するためのエンコーディングを知る必要があります。常にバイトを返したい場合は、encoding=None を使用してください。デフォルトは「utf-8」です。これは引数として与えられた文字列の変換には影響しません。" - -#: 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." -msgstr "ネイティブ文字列を返すため、python3 では stdout と stderr をバイトからテキストに変換する必要があります。もしバイトが指定された ``encoding`` でデコードできない場合は、このエラーハンドラを使用して処理します。デフォルトは ``surrogate_or_strict`` で、利用可能であれば surrogateescape エラーハンドラーを使ってバイトがデコードされることを意味します (サポートしている python3 バージョンで利用可能)。これは、引数として与えられた文字列の変換には影響しません。" - -#: 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." -msgstr "``use_unsafe_shell=False`` の場合、この引数は、コマンドを実行する前に、パスで ``~`` を展開し、環境変数を展開するかどうかを指示します。``True`` の場合、``$SHELL`` のような文字列は、エスケープに関係なく展開されます。``False`` および ``use_unsafe_shell=False`` の場合、パスや変数の展開は行われません。" - -#: 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." -msgstr "Python 3 で実行する場合、この引数は ``Popen`` の基礎となるコンストラクターにどのファイル記述子を渡すべきかを指示します。Python 2 では、この引数は ``close_fds`` を 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)" -msgstr "この関数は、``Popen`` オブジェクトが作成されると呼び出されますが、プロセスに通信する前に呼び出されます (``Popen`` オブジェクトは最初の引数としてコールバックに渡されます)。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw ignore_invalid_cwd" -msgstr "kw ignore_invalid_cwd" - -#: ansible.module_utils.basic.AnsibleModule.run_command:50 of -msgid "This flag indicates whether an invalid ``cwd`` (non-existent or not a directory) should be ignored or should raise an exception." -msgstr "このフラグは、無効な ``cwd`` (存在しないまたはディレクトリーではない) を無視するべきか、例外を発生させるべきかを示します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command of -msgid "kw handle_exceptions" -msgstr "kw handle_exceptions" - -#: ansible.module_utils.basic.AnsibleModule.run_command:53 of -msgid "This flag indicates whether an exception will be handled inline and issue a failed_json or if the caller should handle it." -msgstr "このフラグは、例外をインラインで処理して failed_json を発行するかどうか、または呼び出し元がそれを処理する必要があるかどうかを示します。" - -#: ansible.module_utils.basic.AnsibleModule.run_command:56 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." -msgstr "リターンコード (整数)、stdout (ネイティブ文字列) 、および stderr (ネイティブ文字列) の 3 つのタプルです。python2 では stdout と stderr はどちらもバイト文字列です。python3 では、stdout と stderr は、encoding パラメーターと errors パラメーターに従って変換されたテキスト文字列です。python3 でバイト文字列にしたい場合は、encoding=None を使用してテキストへのデコードをオフにしてください。" - -#: ansible.module_utils.basic.AnsibleModule.sha1:1 of -msgid "Return SHA1 hex digest of local file using digest_from_file()." -msgstr "digest_from_file() を使用してローカルファイルの SHA1 hex ダイジェストを返します。" - -#: ansible.module_utils.basic.AnsibleModule.sha256:1 of -msgid "Return SHA-256 hex digest of local file using digest_from_file()." -msgstr "digest_from_file() を使用してローカルファイルの SHA-256 hex ダイジェストを返します。" - -#: ../../rst/reference_appendices/module_utils.rst:22 -msgid "Basic" -msgstr "基本" - -#: ../../rst/reference_appendices/module_utils.rst:24 -msgid "To use this functionality, include ``import ansible.module_utils.basic`` in your module." -msgstr "この機能を使用するには、モジュールに ``import ansible.module_utils.basic`` を追加します。" - -#: ansible.module_utils.basic.get_all_subclasses:1 of -msgid "**Deprecated**: Use ansible.module_utils.common._utils.get_all_subclasses instead" -msgstr "**非推奨**: 代わりに ansible.module_utils.common._utils.get_all_subclasses を使用します。" - -#: ansible.module_utils.basic.get_platform:1 of -msgid "**Deprecated** Use :py:func:`platform.system` directly." -msgstr "**非推奨** :py:func:`platform.system` を直接使用します。" - -#: ansible.module_utils.basic.get_platform:3 of -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`." -msgstr "プラットフォーム (「Linux」、「Solaris」など) にラベルを付けるネイティブ文字列を返します。現在、これは :py:func:`platform.system` を呼び出した結果になります。" - -#: ansible.module_utils.basic.heuristic_log_sanitize:1 of -msgid "Remove strings that look like passwords from log messages" -msgstr "ログメッセージからパスワードのように見える文字列を削除します。" - -#: ansible.module_utils.basic.load_platform_subclass:1 of -msgid "**Deprecated**: Use ansible.module_utils.common.sys_info.get_platform_subclass instead" -msgstr "**非推奨**: 代わりに ansible.module_utils.common.sys_info.get_platform_subclass を使用します。" - -#: ../../rst/reference_appendices/module_utils.rst:31 -msgid "Argument Spec" -msgstr "引数の仕様" - -#: ../../rst/reference_appendices/module_utils.rst:33 -msgid "Classes and functions for validating parameters against an argument spec." -msgstr "引数仕様に対してパラメーターを検証するクラスおよび関数です。" - -#: ../../rst/reference_appendices/module_utils.rst:36 -msgid "ArgumentSpecValidator" -msgstr "ArgumentSpecValidator" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:1 of -msgid "Argument spec validation class" -msgstr "引数仕様検証クラス" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:3 of -msgid "Creates a validator based on the ``argument_spec`` that can be used to validate a number of parameters using the :meth:`validate` method." -msgstr ":meth:`validate` メソッドを使用して多くのパラメーターを検証するために使用できる ``argument_spec`` に基づいてバリデーターを作成します。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:6 of -msgid "Specification of valid parameters and their type. May include nested argument specs." -msgstr "有効なパラメーターとそのタイプを指定します。ネストされた引数仕様を含めることができます。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:10 of -msgid "List or list of lists of terms that should not be provided together." -msgstr "まとめて提供すべきでない用語のリスト、またはリストのリスト。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:14 of -msgid "List of lists of terms that are required together." -msgstr "同時に必要となる用語のリストのリスト。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:17 of -msgid "List of lists of terms, one of which in each list is required." -msgstr "用語のリストのリスト。各リストに 1 つの用語が必要になります。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:21 of -msgid "List of lists of ``[parameter, value, [parameters]]`` where one of ``[parameters]`` is required if ``parameter == value``." -msgstr "``parameter == value`` の場合に ``[parameters]`` の 1 つが必要になる ``[parameter, value, [parameters]]`` のリストのリストです。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator:25 of -msgid "Dictionary of parameter names that contain a list of parameters required by each key in the dictionary." -msgstr "ディクショナリーの各キーに必要なパラメーター名の一覧が含まれるパラメーター名のディクショナリー。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate:1 of -msgid "Validate ``parameters`` against argument spec." -msgstr "引数仕様に対して ``parameters`` を検証します。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate:3 of -msgid "Error messages in the :class:`ValidationResult` may contain no_log values and should be sanitized with :func:`~ansible.module_utils.common.parameters.sanitize_keys` before logging or displaying." -msgstr ":class:`ValidationResult` のエラーメッセージに no_log の値が含まれている可能性があり、ログまたは表示の前に :func:`~ansible.module_utils.common.parameters.sanitize_keys` でサニタイズされるはずです。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate:6 of -msgid "Parameters to validate against the argument spec" -msgstr "引数仕様に対して検証するパラメーター" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate:9 of -msgid ":class:`ValidationResult` containing validated parameters." -msgstr "検証済みパラメーターが含まれる :class:`ValidationResult`。" - -#: ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate of -msgid "Simple Example" -msgstr "簡単な例" - -#: ../../rst/reference_appendices/module_utils.rst:42 -msgid "ValidationResult" -msgstr "ValidationResult" - -#: ansible.module_utils.common.arg_spec.ValidationResult:1 of -msgid "Result of argument spec validation." -msgstr "引数の仕様検証の結果です。" - -#: ansible.module_utils.common.arg_spec.ValidationResult:3 of -msgid "This is the object returned by :func:`ArgumentSpecValidator.validate() ` containing the validated parameters and any errors." -msgstr "これは、検証したパラメーターおよびエラーが含まれる :func:`ArgumentSpecValidator.validate() ` によって返されるオブジェクトです。" - -#: ansible.module_utils.common.arg_spec.ValidationResult:7 of -msgid "Terms to be validated and coerced to the correct type." -msgstr "検証され、正しいタイプに強制される用語です。" - -#: ../../docstring -#: ansible.module_utils.common.arg_spec.ValidationResult.errors:1 of -msgid ":class:`~ansible.module_utils.errors.AnsibleValidationErrorMultiple` containing all :class:`~ansible.module_utils.errors.AnsibleValidationError` objects if there were any failures during validation." -msgstr "検証中に失敗した場合は、すべての :class:`~ansible.module_utils.errors.AnsibleValidationError` オブジェクトを含む :class:`~ansible.module_utils.errors.AnsibleValidationErrorMultiple`。" - -#: ansible.module_utils.common.arg_spec.ValidationResult.validated_parameters:1 -#: of -msgid "Validated and coerced parameters." -msgstr "検証および強制されたパラメーター。" - -#: ansible.module_utils.common.arg_spec.ValidationResult.unsupported_parameters:1 -#: of -msgid ":class:`set` of unsupported parameter names." -msgstr "サポート対象外のパラメーター名の :class:`set`。" - -#: ansible.module_utils.common.arg_spec.ValidationResult.error_messages:1 of -msgid ":class:`list` of all error messages from each exception in :attr:`errors`." -msgstr ":attr:`errors` の各例外のすべてのエラーメッセージの :class:`list`。" - -#: ../../rst/reference_appendices/module_utils.rst:57 -msgid ":class:`dict` of type names, such as ``'str'``, and the default function used to check that type, :func:`~ansible.module_utils.common.validation.check_type_str` in this case." -msgstr "``'str'`` などｍｐタイプ名の :class:`dict` と、そのタイプの確認に使用されるデフォルトの関数。この場合は :func:`~ansible.module_utils.common.validation.check_type_str` になります。" - -#: ansible.module_utils.common.parameters.env_fallback:1 of -msgid "Load value from environment variable" -msgstr "環境変数からの値を読み込みます。" - -#: ansible.module_utils.common.parameters.remove_values:1 of -msgid "Remove strings in ``no_log_strings`` from value." -msgstr "``no_log_strings`` の文字列を値から削除します。" - -#: ansible.module_utils.common.parameters.remove_values:3 of -msgid "If value is a container type, then remove a lot more." -msgstr "値がコンテナータイプである場合は、さらに削除します。" - -#: ansible.module_utils.common.parameters.remove_values:5 of -msgid "Use of ``deferred_removals`` exists, rather than a pure recursive solution, because of the potential to hit the maximum recursion depth when dealing with large amounts of data (see `issue #24560 `_)." -msgstr "大量のデータを処理する際に最大再帰深度に達する可能性があるため、純粋な再帰的なソリューションではなく、``deferred_removals`` が使用されます (`issue #24560 `_ を参照)。" - -#: ansible.module_utils.common.parameters.sanitize_keys:1 of -msgid "Sanitize the keys in a container object by removing ``no_log`` values from key names." -msgstr "``no_log`` の値をキー名から削除して、コンテナーオブジェクトでキーをサニタイズします。" - -#: ansible.module_utils.common.parameters.sanitize_keys:3 of -msgid "This is a companion function to the :func:`remove_values` function. Similar to that function, we make use of ``deferred_removals`` to avoid hitting maximum recursion depth in cases of large data structures." -msgstr "これは、:func:`remove_values` 関数のコンパニオン関数です。この関数と同様に、``deferred_removals`` を使用して大きなデータ構造の場合に最大再帰深度に到達しないようにします。" - -#: ansible.module_utils.common.parameters.sanitize_keys:7 of -msgid "The container object to sanitize. Non-container objects are returned unmodified." -msgstr "サニタイズするコンテナーオブジェクト。非コンテナーオブジェクトは変更されずに返されます。" - -#: ansible.module_utils.common.parameters.sanitize_keys:8 of -msgid "A set of string values we do not want logged." -msgstr "ログに記録したくない文字列値のセット。" - -#: ansible.module_utils.common.parameters.sanitize_keys:9 of -msgid "A set of string values of keys to not sanitize." -msgstr "サニタイズしないキーの文字列値のセット。" - -#: ansible.module_utils.common.parameters.sanitize_keys:11 of -msgid "An object with sanitized keys." -msgstr "サニタイズされたキーを持つオブジェクト。" - -#: ../../rst/reference_appendices/module_utils.rst:61 -msgid "Validation" -msgstr "検証" - -#: ../../rst/reference_appendices/module_utils.rst:63 -msgid "Standalone functions for validating various parameter types." -msgstr "さまざまなパラメータータイプを検証するスタンドアロン機能。" - -#: ansible.module_utils.common.validation.check_missing_parameters:1 of -msgid "This is for checking for required params when we can not check via argspec because we need more information than is simply given in the argspec." -msgstr "これは、単に argspec で指定されるよりも多くの情報が必要なため、argspec を介して確認できない場合に必要なパラメーターを確認するためのものです。" - -#: ansible.module_utils.common.validation.check_missing_parameters:4 of -msgid "Raises :class:`TypeError` if any required parameters are missing" -msgstr "必要なパラメーターがない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_missing_parameters:6 -#: ansible.module_utils.common.validation.check_mutually_exclusive:7 -#: ansible.module_utils.common.validation.check_required_arguments:8 -#: ansible.module_utils.common.validation.check_required_by:7 -#: ansible.module_utils.common.validation.check_required_if:18 -#: ansible.module_utils.common.validation.check_required_one_of:8 -#: ansible.module_utils.common.validation.check_required_together:9 -#: ansible.module_utils.common.validation.count_terms:4 of -msgid "Dictionary of parameters" -msgstr "パラメーターのディクショナリー" - -#: ansible.module_utils.common.validation.check_missing_parameters:7 of -msgid "List of parameters to look for in the given parameters." -msgstr "指定のパラメーターを検索するパラメーターの一覧" - -#: ansible.module_utils.common.validation.check_missing_parameters:9 -#: ansible.module_utils.common.validation.check_mutually_exclusive:11 -#: ansible.module_utils.common.validation.check_required_arguments:12 -#: ansible.module_utils.common.validation.check_required_one_of:12 -#: ansible.module_utils.common.validation.check_required_together:13 of -msgid "Empty list or raises :class:`TypeError` if the check fails." -msgstr "空のリスト (確認に失敗した場合は :class:`TypeError` が発生)" - -#: ansible.module_utils.common.validation.check_mutually_exclusive:1 of -msgid "Check mutually exclusive terms against argument parameters" -msgstr "引数パラメーターに対して相互排他的な用語を確認します。" - -#: ansible.module_utils.common.validation.check_mutually_exclusive:3 of -msgid "Accepts a single list or list of lists that are groups of terms that should be mutually exclusive with one another" -msgstr "相互に排他的な用語のグループである単一のリストまたはリストのリストを受け入れます。" - -#: ansible.module_utils.common.validation.check_mutually_exclusive:6 of -msgid "List of mutually exclusive parameters" -msgstr "相互排他的パラメーターのリスト" - -#: ansible.module_utils.common.validation.check_mutually_exclusive:8 -#: ansible.module_utils.common.validation.check_required_one_of:9 -#: ansible.module_utils.common.validation.check_required_together:10 of -msgid "List of strings of parent key names if ``terms`` are in a sub spec." -msgstr "``terms`` がサブ仕様にある場合は、親キー名の文字列のリスト" - -#: ansible.module_utils.common.validation.check_required_arguments:1 of -msgid "Check all parameters in argument_spec and return a list of parameters that are required but not present in parameters." -msgstr "argument_spec 内のすべてのパラメーターを確認し、必須ではあるがパラメーターに存在しないパラメーターのリストを返します。" - -#: ansible.module_utils.common.validation.check_required_arguments:4 -#: ansible.module_utils.common.validation.check_required_if:3 of -msgid "Raises :class:`TypeError` if the check fails" -msgstr "確認に失敗すると :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_required_arguments:6 of -msgid "Argument spec dictionary containing all parameters and their specification" -msgstr "すべてのパラメーターとそれらの仕様を含む引数仕様ディクショナリー" - -#: ansible.module_utils.common.validation.check_required_arguments:9 of -msgid "List of strings of parent key names if ``argument_spec`` are in a sub spec." -msgstr "``argument_spec`` がサブ仕様にある場合は、親キー名の文字列のリスト" - -#: ansible.module_utils.common.validation.check_required_by:1 of -msgid "For each key in requirements, check the corresponding list to see if they exist in parameters." -msgstr "要件の各キーについて、対応するリストを確認して、それらがパラメーターに存在するかどうかを確認します。" - -#: ansible.module_utils.common.validation.check_required_by:4 of -msgid "Accepts a single string or list of values for each key." -msgstr "各キーに単一の文字列または値のリストを受け入れます。" - -#: ansible.module_utils.common.validation.check_required_by:6 of -msgid "Dictionary of requirements" -msgstr "要件のディクショナリー" - -#: ansible.module_utils.common.validation.check_required_by:8 -#: ansible.module_utils.common.validation.check_required_if:45 of -msgid "List of strings of parent key names if ``requirements`` are in a sub spec." -msgstr "``requirements`` がサブ仕様にある場合は、親キー名の文字列のリスト" - -#: ansible.module_utils.common.validation.check_required_by:11 of -msgid "Empty dictionary or raises :class:`TypeError` if the" -msgstr "空のディクショナリー (確認に失敗した場合は :class:`TypeError` が発生)" - -#: ansible.module_utils.common.validation.check_required_if:1 of -msgid "Check parameters that are conditionally required" -msgstr "条件付きで必要なパラメーターを確認します。" - -#: ansible.module_utils.common.validation.check_required_if:5 of -msgid "List of lists specifying a parameter, value, parameters required when the given parameter is the specified value, and optionally a boolean indicating any or all parameters are required." -msgstr "パラメーター、値、指定されたパラメーターが指定された値である場合に必要なパラメーター、ならびに必要に応じて一部またはすべてのパラメーターが必要であることを示すブール値を指定するリストのリスト。" - -#: ansible.module_utils.common.validation.check_required_if of -msgid "Example" -msgstr "例" - -#: ansible.module_utils.common.validation.check_required_if:20 of -msgid "Empty list or raises :class:`TypeError` if the check fails. The results attribute of the exception contains a list of dictionaries. Each dictionary is the result of evaluating each item in requirements. Each return dictionary contains the following keys: :key missing: List of parameters that are required but missing :key requires: 'any' or 'all' :key parameter: Parameter name that has the requirement :key value: Original value of the parameter :key requirements: Original required parameters :Example: .. code-block:: python [ { 'parameter': 'someint', 'value': 99 'requirements': ('bool_param', 'string_param'), 'missing': ['string_param'], 'requires': 'all', } ]" -msgstr "空のリスト (確認に失敗した場合は :class:`TypeError` が発生)。例外の結果属性には、ディクショナリーのリストが含まれます。各ディクショナリーは、要件内の各項目を評価した結果です。それぞれの戻り値のディクショナリーには、以下のキーが含まれます: :key missing: 必須であるにもかかわらず、欠落しているパラメーターのリスト :key requires: 「any」または「all」 :key parameter: 要件を満たすパラメーター名 :key value: パラメーターの元の値 :key requirements: 元の必須パラメーター :例: .. code-block:: python [ { 'parameter': 'someint', 'value': 99 'requirements': ('bool_param', 'string_param'), 'missing': ['string_param'], 'requires': 'all', } ]" - -#: ansible.module_utils.common.validation.check_required_if:20 of -msgid "Empty list or raises :class:`TypeError` if the check fails. The results attribute of the exception contains a list of dictionaries. Each dictionary is the result of evaluating each item in requirements. Each return dictionary contains the following keys:" -msgstr "空のリスト (確認に失敗した場合は :class:`TypeError` が発生)。例外の結果属性には、ディクショナリーのリストが含まれます。各ディクショナリーは、要件内の各項目を評価した結果です。それぞれの戻り値のディクショナリーには、以下のキーが含まれます。" - -#: ansible.module_utils.common.validation.check_required_if of -msgid "key missing" -msgstr "key missing" - -#: ansible.module_utils.common.validation.check_required_if:25 of -msgid "List of parameters that are required but missing" -msgstr "必須であるにもかかわらず、欠落しているパラメーターのリスト" - -#: ansible.module_utils.common.validation.check_required_if of -msgid "key requires" -msgstr "key requires" - -#: ansible.module_utils.common.validation.check_required_if:26 of -msgid "'any' or 'all'" -msgstr "「any」または「all」" - -#: ansible.module_utils.common.validation.check_required_if of -msgid "key parameter" -msgstr "key parameter" - -#: ansible.module_utils.common.validation.check_required_if:27 of -msgid "Parameter name that has the requirement" -msgstr "要件を満たすパラメーター名" - -#: ansible.module_utils.common.validation.check_required_if of -msgid "key value" -msgstr "key value" - -#: ansible.module_utils.common.validation.check_required_if:28 of -msgid "Original value of the parameter" -msgstr "パラメーターの元の値" - -#: ansible.module_utils.common.validation.check_required_if of -msgid "key requirements" -msgstr "key requirements" - -#: ansible.module_utils.common.validation.check_required_if:29 of -msgid "Original required parameters" -msgstr "元の必須パラメーター" - -#: ansible.module_utils.common.validation.check_required_one_of:1 of -msgid "Check each list of terms to ensure at least one exists in the given module parameters" -msgstr "用語の各リストを確認して、指定されたモジュールパラメーターに少なくとも 1 つが存在することを確認してください。" - -#: ansible.module_utils.common.validation.check_required_one_of:4 of -msgid "Accepts a list of lists or tuples" -msgstr "リストまたはタプルの一覧を受け入れます。" - -#: ansible.module_utils.common.validation.check_required_one_of:6 of -msgid "List of lists of terms to check. For each list of terms, at least one is required." -msgstr "確認する用語リストのリスト。用語の各リストに対して、少なくとも 1 つが必要です。" - -#: ansible.module_utils.common.validation.check_required_together:1 of -msgid "Check each list of terms to ensure every parameter in each list exists in the given parameters." -msgstr "用語の各リストを確認して、各リストのすべてのパラメーターが指定されたパラメーターに存在することを確認してください。" - -#: ansible.module_utils.common.validation.check_required_together:4 of -msgid "Accepts a list of lists or tuples." -msgstr "リストまたはタプルのリストを受け入れます。" - -#: ansible.module_utils.common.validation.check_required_together:6 of -msgid "List of lists of terms to check. Each list should include parameters that are all required when at least one is specified in the parameters." -msgstr "確認する用語リストのリスト。各リストには、パラメーターで少なくとも 1 つが指定されている場合に必要なすべてのパラメーターを含める必要があります。" - -#: ansible.module_utils.common.validation.check_type_bits:1 of -msgid "Convert a human-readable string bits value to bits in integer." -msgstr "人間が判読できる文字列ビットの値を整数のビットに変換します。" - -#: ansible.module_utils.common.validation.check_type_bits:3 of -msgid "Example: ``check_type_bits('1Mb')`` returns integer 1048576." -msgstr "例: ``check_type_bits('1Mb')`` は整数 1048576 を返します。" - -#: ansible.module_utils.common.validation.check_type_bits:5 of -msgid "Raises :class:`TypeError` if unable to covert the value." -msgstr "値を非表示にできない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_bool:1 of -msgid "Verify that the value is a bool or convert it to a bool and return it." -msgstr "値がブール値であることを確認するか、ブールに変換して返します。" - -#: ansible.module_utils.common.validation.check_type_bool:3 of -msgid "Raises :class:`TypeError` if unable to convert to a bool" -msgstr "値をブール値に変換できない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_bool:5 of -msgid "String, int, or float to convert to bool. Valid booleans include: '1', 'on', 1, '0', 0, 'n', 'f', 'false', 'true', 'y', 't', 'yes', 'no', 'off'" -msgstr "ブール値に変換する文字列、整数、浮動小数点。有効なブール値には、'1'、'on'、1、'0'、0、'n'、'f'、'false'、'true'、'y'、't'、'yes'、'no'、'off' が含まれます。" - -#: ansible.module_utils.common.validation.check_type_bool:8 of -msgid "Boolean True or False" -msgstr "ブール値 True または False" - -#: ansible.module_utils.common.validation.check_type_bytes:1 of -msgid "Convert a human-readable string value to bytes" -msgstr "人間が判読できる文字列の値をバイトに変換します。" - -#: ansible.module_utils.common.validation.check_type_bytes:3 -#: ansible.module_utils.common.validation.check_type_jsonarg:4 of -msgid "Raises :class:`TypeError` if unable to covert the value" -msgstr "値を非表示にできない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_dict:1 of -msgid "Verify that value is a dict or convert it to a dict and return it." -msgstr "値がディクショナリーであることを確認するか、これをディクショナリーに変換して、返します。" - -#: ansible.module_utils.common.validation.check_type_dict:3 of -msgid "Raises :class:`TypeError` if unable to convert to a dict" -msgstr "値をディクショナリーに変換できない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_dict:5 of -msgid "Dict or string to convert to a dict. Accepts ``k1=v2, k2=v2``." -msgstr "ディクショナリーに変換するディクショナリーまたは文字列。``k1=v2, k2=v2`` を使用できます。" - -#: ansible.module_utils.common.validation.check_type_dict:7 of -msgid "value converted to a dictionary" -msgstr "ディクショナリーに変換された値" - -#: ansible.module_utils.common.validation.check_type_float:1 of -msgid "Verify that value is a float or convert it to a float and return it" -msgstr "値が浮動小数点であることを確認するか、これを浮動小数点に変換して、返します。" - -#: ansible.module_utils.common.validation.check_type_float:3 of -msgid "Raises :class:`TypeError` if unable to convert to a float" -msgstr "値を浮動小数点に変換できない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_float:5 of -msgid "float, int, str, or bytes to verify or convert and return." -msgstr "検証または変換して返す浮動小数点、整数、文字列、またはバイト。" - -#: ansible.module_utils.common.validation.check_type_float:7 of -msgid "float of given value." -msgstr "指定された値の浮動小数点" - -#: ansible.module_utils.common.validation.check_type_int:1 of -msgid "Verify that the value is an integer and return it or convert the value to an integer and return it" -msgstr "値が整数であることを確認して返すか、値を整数に変換して返します。" - -#: ansible.module_utils.common.validation.check_type_int:4 of -msgid "Raises :class:`TypeError` if unable to convert to an int" -msgstr "値を整数に変換できない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_int:6 of -msgid "String or int to convert of verify" -msgstr "検証の変換を行う文字列または整数" - -#: ansible.module_utils.common.validation.check_type_int:8 of -msgid "int of given value" -msgstr "指定された値の int" - -#: ansible.module_utils.common.validation.check_type_jsonarg:1 of -msgid "Return a jsonified string. Sometimes the controller turns a json string into a dict/list so transform it back into json here" -msgstr "json 化された文字列を返します。コントローラーが json 文字列をディクショナリーまたはリストに変換する場合があるため、ここで json に変換し直してください。" - -#: ansible.module_utils.common.validation.check_type_list:1 of -msgid "Verify that the value is a list or convert to a list" -msgstr "値がリストであるか、またはリストに変換されていることを確認します。" - -#: ansible.module_utils.common.validation.check_type_list:3 of -msgid "A comma separated string will be split into a list. Raises a :class:`TypeError` if unable to convert to a list." -msgstr "コンマ区切りの文字列はリストに分割されます。リストにに変換できない場合は :class:`TypeError` を発生させます。" - -#: ansible.module_utils.common.validation.check_type_list:6 of -msgid "Value to validate or convert to a list" -msgstr "リストを検証または変換する値" - -#: ansible.module_utils.common.validation.check_type_list:8 of -msgid "Original value if it is already a list, single item list if a float, int, or string without commas, or a multi-item list if a comma-delimited string." -msgstr "すでにリストである場合は元の値。浮動小数点、int、またはコンマのない文字列の場合は単一項目のリスト。コンマ区切りの文字列の場合は複数項目のリスト。" - -#: ansible.module_utils.common.validation.check_type_path:1 of -msgid "Verify the provided value is a string or convert it to a string, then return the expanded path" -msgstr "指定された値が文字列であることを確認するか、文字列に変換してから、展開されたパスを返します" - -#: ansible.module_utils.common.validation.check_type_raw:1 of -msgid "Returns the raw value" -msgstr "生の値を返します。" - -#: ansible.module_utils.common.validation.check_type_str:1 of -msgid "Verify that the value is a string or convert to a string." -msgstr "値が文字列であることを確認するか、これを文字列に変換します。" - -#: ansible.module_utils.common.validation.check_type_str:3 of -msgid "Since unexpected changes can sometimes happen when converting to a string, ``allow_conversion`` controls whether or not the value will be converted or a TypeError will be raised if the value is not a string and would be converted" -msgstr "文字列への変換時に予期せぬ変更が生じる可能性があるため、``allow_conversion`` は、値が変換されるかどうか、または値が文字列でなければ TypeError が発生させ、変換するかどうかを制御します。" - -#: ansible.module_utils.common.validation.check_type_str:7 of -msgid "Value to validate or convert to a string" -msgstr "検証または文字列に変換する値" - -#: ansible.module_utils.common.validation.check_type_str:8 of -msgid "Whether to convert the string and return it or raise a TypeError" -msgstr "文字列を変換して返すか、TypeError を発生させるか" - -#: ansible.module_utils.common.validation.check_type_str:11 of -msgid "Original value if it is a string, the value converted to a string if allow_conversion=True, or raises a TypeError if allow_conversion=False." -msgstr "文字列の場合は元の値。allow_conversion=True の場合は値を文字列に変換し、allow_conversion=False の場合は TypeError を発生させます。" - -#: ansible.module_utils.common.validation.count_terms:1 of -msgid "Count the number of occurrences of a key in a given dictionary" -msgstr "特定のディクショナリーでキーの発生回数をカウントします。" - -#: ansible.module_utils.common.validation.count_terms:3 of -msgid "String or iterable of values to check" -msgstr "確認する値の文字列または反復可能" - -#: ansible.module_utils.common.validation.count_terms:6 of -msgid "An integer that is the number of occurrences of the terms values in the provided dictionary." -msgstr "提供されたディクショナリーでの用語の値の出現回数を表す整数。" - -#: ../../rst/reference_appendices/module_utils.rst:70 -msgid "Errors" -msgstr "エラー" - -#: ansible.module_utils.errors.AnsibleFallbackNotFound:1 of -msgid "Fallback validator was not found" -msgstr "フォールバックバリデーターが見つかりませんでした。" - -#: ansible.module_utils.errors.AnsibleValidationError:1 of -msgid "Single argument spec validation error" -msgstr "単一の引数の仕様検証エラー" - -#: ../../docstring -#: ansible.module_utils.errors.AnsibleValidationError.error_message:1 -#: ansible.module_utils.errors.AnsibleValidationError.msg:1 of -msgid "The error message passed in when the exception was raised." -msgstr "例外が発生したときに渡されたエラーメッセージ" - -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple:1 of -msgid "Multiple argument spec validation errors" -msgstr "複数の引数仕様検証エラー" - -#: ../../docstring -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple.errors:1 of -msgid ":class:`list` of :class:`AnsibleValidationError` objects" -msgstr ":class:`AnsibleValidationError` オブジェクトの :class:`list`" - -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple.msg:1 of -msgid "The first message from the first error in ``errors``." -msgstr "``errors`` の最初のエラーからの最初のメッセージ" - -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple.messages:1 of -msgid ":class:`list` of each error message in ``errors``." -msgstr "``errors`` の各エラーメッセージの :class:`list`" - -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple.append:1 of -msgid "Append a new error to ``self.errors``." -msgstr "``self.errors`` に新しいエラーを追加します。" - -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple.append:3 of -msgid "Only :class:`AnsibleValidationError` should be added." -msgstr ":class:`AnsibleValidationError` だけを追加する必要があります。" - -#: ansible.module_utils.errors.AnsibleValidationErrorMultiple.extend:1 of -msgid "Append each item in ``errors`` to ``self.errors``. Only :class:`AnsibleValidationError` should be added." -msgstr "``errors`` の各アイテムを ``self.errors`` に追加します。:class:`AnsibleValidationError` のみを追加する必要があります。" - -#: ansible.module_utils.errors.AliasError:1 of -msgid "Error handling aliases" -msgstr "エイリアスの処理中のエラー" - -#: ansible.module_utils.errors.ArgumentTypeError:1 of -msgid "Error with parameter type" -msgstr "パラメータータイプのエラー" - -#: ansible.module_utils.errors.ArgumentValueError:1 of -msgid "Error with parameter value" -msgstr "パラメーター値のエラー" - -#: ansible.module_utils.errors.DeprecationError:1 of -msgid "Error processing parameter deprecations" -msgstr "パラメーターの非推奨アイテムの処理中に発生するエラー" - -#: ansible.module_utils.errors.ElementError:1 of -msgid "Error when validating elements" -msgstr "要素検証時のエラー" - -#: ansible.module_utils.errors.MutuallyExclusiveError:1 of -msgid "Mutually exclusive parameters were supplied" -msgstr "相互に排他的なパラメーターが指定されています。" - -#: ansible.module_utils.errors.NoLogError:1 of -msgid "Error converting no_log values" -msgstr "no_log 値の変換エラー" - -#: ansible.module_utils.errors.RequiredByError:1 of -msgid "Error with parameters that are required by other parameters" -msgstr "他のパラメーターで必要なパラメーターでエラー" - -#: ansible.module_utils.errors.RequiredDefaultError:1 of -msgid "A required parameter was assigned a default value" -msgstr "必須パラメーターにデフォルト値が割り当てられています。" - -#: ansible.module_utils.errors.RequiredError:1 of -msgid "Missing a required parameter" -msgstr "必須パラメーターがありません" - -#: ansible.module_utils.errors.RequiredIfError:1 of -msgid "Error with conditionally required parameters" -msgstr "条件的必須パラメーターのエラー" - -#: ansible.module_utils.errors.RequiredOneOfError:1 of -msgid "Error with parameters where at least one is required" -msgstr "最低 1 つは必要なパラメーターに関するエラー" - -#: ansible.module_utils.errors.RequiredTogetherError:1 of -msgid "Error with parameters that are required together" -msgstr "同時に必要となるパラメーターに関するエラー" - -#: ansible.module_utils.errors.SubParameterTypeError:1 of -msgid "Incorrect type for subparameter" -msgstr "サブパラメーターの型が正しくありません。" - -#: ansible.module_utils.errors.UnsupportedError:1 of -msgid "Unsupported parameters were supplied" -msgstr "サポートされていないパラメーターが指定されました。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:4 -msgid "Playbook Keywords" -msgstr "Playbook キーワード" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:6 -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." -msgstr "これらのキーワードは、一般的な Playbook オブジェクトで利用できます。キーワードは、Ansible の動作を設定する複数のソースのいずれかです。各ソースの相対優先順位に関する詳細は、「:ref:`general_precedence_rules`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:9 -msgid "Please note:" -msgstr "注意:" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:11 -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." -msgstr "ディレクティブのエイリアスはここでは反映されておらず、変更可能なものでもありません。たとえば、タスクの :term:`action` は、Ansible モジュールの名前に置き換えられます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:13 -msgid "The keywords do not have ``version_added`` information at this time" -msgstr "現時点ではキーワードに ``version_added`` 情報がありません" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:14 -msgid "Some keywords set defaults for the objects inside of them rather than for the objects themselves" -msgstr "キーワードによっては、オブジェクト自体ではなく、オブジェクト内にデフォルトを設定するものもあります。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:24 -msgid "Play" -msgstr "プレイ" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:27 -#: ../../rst/reference_appendices/playbooks_keywords.rst:159 -#: ../../rst/reference_appendices/playbooks_keywords.rst:252 -#: ../../rst/reference_appendices/playbooks_keywords.rst:354 -msgid "Force any un-handled task errors on any host to propagate to all hosts and end the play." -msgstr "ホストで処理されていないタスクエラーを強制的に実行し、すべてのホストに伝播してプレイを終了します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:30 -#: ../../rst/reference_appendices/playbooks_keywords.rst:162 -#: ../../rst/reference_appendices/playbooks_keywords.rst:255 -#: ../../rst/reference_appendices/playbooks_keywords.rst:363 -msgid "Boolean that controls if privilege escalation is used or not on :term:`Task` execution. Implemented by the become plugin. See :ref:`become_plugins`." -msgstr ":term:`タスク` の実行時に特権昇格が使用されるかどうかを制御するブール値。become プラグインによって実装されます。「:ref:`become_plugins`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:33 -#: ../../rst/reference_appendices/playbooks_keywords.rst:165 -#: ../../rst/reference_appendices/playbooks_keywords.rst:258 -#: ../../rst/reference_appendices/playbooks_keywords.rst:366 -msgid "Path to the executable used to elevate privileges. Implemented by the become plugin. See :ref:`become_plugins`." -msgstr "権限の昇格に使用する実行可能ファイルへのパス。become プラグインによって実装されます。「:ref:`become_plugins`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:36 -#: ../../rst/reference_appendices/playbooks_keywords.rst:168 -#: ../../rst/reference_appendices/playbooks_keywords.rst:261 -#: ../../rst/reference_appendices/playbooks_keywords.rst:369 -msgid "A string of flag(s) to pass to the privilege escalation program when :term:`become` is True." -msgstr ":term:`become` が True の場合に特権昇格プログラムに渡すフラグの文字列。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:39 -#: ../../rst/reference_appendices/playbooks_keywords.rst:171 -#: ../../rst/reference_appendices/playbooks_keywords.rst:264 -#: ../../rst/reference_appendices/playbooks_keywords.rst:372 -msgid "Which method of privilege escalation to use (such as sudo or su)." -msgstr "使用する権限昇格の方法 (sudo、su など)。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:42 -#: ../../rst/reference_appendices/playbooks_keywords.rst:174 -#: ../../rst/reference_appendices/playbooks_keywords.rst:267 -#: ../../rst/reference_appendices/playbooks_keywords.rst:375 -msgid "User that you 'become' after using privilege escalation. The remote/login user must have permissions to become this user." -msgstr "特権昇格を使用した後に「become」となるユーザーです。リモート/ログインユーザーには、このユーザーになる (become) ためのパーミッションが必要です。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:45 -#: ../../rst/reference_appendices/playbooks_keywords.rst:177 -#: ../../rst/reference_appendices/playbooks_keywords.rst:273 -#: ../../rst/reference_appendices/playbooks_keywords.rst:381 -msgid "check_mode" -msgstr "check_mode" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:45 -#: ../../rst/reference_appendices/playbooks_keywords.rst:177 -#: ../../rst/reference_appendices/playbooks_keywords.rst:273 -#: ../../rst/reference_appendices/playbooks_keywords.rst:381 -msgid "A boolean that controls if a task is executed in 'check' mode. See :ref:`check_mode_dry`." -msgstr "「check」モードでタスクが実行されるかどうかを制御するブール値。「:ref:`check_mode_dry`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:53 -#: ../../rst/reference_appendices/playbooks_keywords.rst:185 -#: ../../rst/reference_appendices/playbooks_keywords.rst:281 -#: ../../rst/reference_appendices/playbooks_keywords.rst:389 -msgid "collections" -msgstr "collections" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:48 -#: ../../rst/reference_appendices/playbooks_keywords.rst:180 -#: ../../rst/reference_appendices/playbooks_keywords.rst:276 -#: ../../rst/reference_appendices/playbooks_keywords.rst:384 -msgid "List of collection namespaces to search for modules, plugins, and roles. See :ref:`collections_using_playbook`" -msgstr "モジュール、プラグイン、およびロールを検索するコレクション名前空間の一覧。「:ref:`collections_using_playbook`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:52 -#: ../../rst/reference_appendices/playbooks_keywords.rst:184 -#: ../../rst/reference_appendices/playbooks_keywords.rst:280 -#: ../../rst/reference_appendices/playbooks_keywords.rst:388 -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." -msgstr "ロール内のタスクは、プレイから ``collections`` の値を継承しません。ロール検索でコレクションの一覧を取得するには、ロール内で ``meta/main.yml`` の ``collections`` キーワードを使用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:56 -#: ../../rst/reference_appendices/playbooks_keywords.rst:188 -#: ../../rst/reference_appendices/playbooks_keywords.rst:284 -#: ../../rst/reference_appendices/playbooks_keywords.rst:392 -msgid "connection" -msgstr "connection" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:56 -#: ../../rst/reference_appendices/playbooks_keywords.rst:188 -#: ../../rst/reference_appendices/playbooks_keywords.rst:284 -#: ../../rst/reference_appendices/playbooks_keywords.rst:392 -msgid "Allows you to change the connection plugin used for tasks to execute on the target. See :ref:`using_connection`." -msgstr "ターゲットで実行するタスクに使用される connection プラグインを変更できます。「:ref:`using_connection`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:59 -#: ../../rst/reference_appendices/playbooks_keywords.rst:191 -#: ../../rst/reference_appendices/playbooks_keywords.rst:287 -#: ../../rst/reference_appendices/playbooks_keywords.rst:395 -msgid "debugger" -msgstr "debugger" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:59 -#: ../../rst/reference_appendices/playbooks_keywords.rst:191 -#: ../../rst/reference_appendices/playbooks_keywords.rst:287 -#: ../../rst/reference_appendices/playbooks_keywords.rst:395 -msgid "Enable debugging tasks based on state of the task result. See :ref:`playbook_debugger`." -msgstr "タスク結果の状態に基づいて、デバッグタスクを有効にします。「:ref:`playbook_debugger`」を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:62 -#: ../../rst/reference_appendices/playbooks_keywords.rst:200 -#: ../../rst/reference_appendices/playbooks_keywords.rst:296 -#: ../../rst/reference_appendices/playbooks_keywords.rst:407 -msgid "Toggle to make tasks return 'diff' information or not." -msgstr "タスクが「diff」情報を返すように切り替えます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:65 -#: ../../rst/reference_appendices/playbooks_keywords.rst:203 -#: ../../rst/reference_appendices/playbooks_keywords.rst:299 -#: ../../rst/reference_appendices/playbooks_keywords.rst:410 -msgid "environment" -msgstr "environment" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:65 -#: ../../rst/reference_appendices/playbooks_keywords.rst:203 -#: ../../rst/reference_appendices/playbooks_keywords.rst:299 -#: ../../rst/reference_appendices/playbooks_keywords.rst:410 -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." -msgstr "実行時に、タスク用に提供された環境変数に変換されるディクショナリー。これは、モジュールでのみ使用できます。これは、他のタイプのプラグインや Ansible 自体、その設定ではサポートされていません。タスクの実行を担当するコードの変数だけを設定します。これは、機密性の高いデータに渡すための推奨方法ではありません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:68 -msgid "Set the fact path option for the fact gathering plugin controlled by :term:`gather_facts`." -msgstr ":term:`gather_facts` が制御するファクト収集プラグインのファクトパスオプションを設定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:71 -msgid "Will force notified handler execution for hosts even if they failed during the play. Will not trigger if the play itself fails." -msgstr "プレイ中に失敗した場合でも、ホストの通知ハンドラー実行を強制的に実行します。プレイ自体が失敗した場合は発生しません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:74 -msgid "gather_facts" -msgstr "gather_facts" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:74 -msgid "A boolean that controls if the play will automatically run the 'setup' task to gather facts for the hosts." -msgstr "プレイが自動的に「setup」タスクを実行してホストのファクトを収集するかどうかを制御するブール値。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:77 -msgid "Allows you to pass subset options to the fact gathering plugin controlled by :term:`gather_facts`." -msgstr ":term:`gather_facts` が制御するファクト収集プラグインにサブセットオプションを渡すことができます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:80 -msgid "Allows you to set the timeout for the fact gathering plugin controlled by :term:`gather_facts`." -msgstr ":term:`gather_facts` が制御するファクト収集プラグインのタイムアウトを設定できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:83 -msgid "handlers" -msgstr "handlers" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:83 -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." -msgstr "ハンドラーとして扱われるタスクが含まれるセクションは、タスクの各セクションの完了後に通知される場合にのみ、通常どおり実行されません。ハンドラーの `listen` フィールドはテンプレート化できません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:86 -msgid "hosts" -msgstr "ホスト" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:86 -msgid "A list of groups, hosts or host pattern that translates into a list of hosts that are the play's target." -msgstr "プレイのターゲットであるホストの一覧に変換するグループ、ホスト、またはホストパターンの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:89 -#: ../../rst/reference_appendices/playbooks_keywords.rst:206 -#: ../../rst/reference_appendices/playbooks_keywords.rst:302 -#: ../../rst/reference_appendices/playbooks_keywords.rst:416 -msgid "ignore_errors" -msgstr "ignore_errors" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:89 -#: ../../rst/reference_appendices/playbooks_keywords.rst:206 -#: ../../rst/reference_appendices/playbooks_keywords.rst:302 -#: ../../rst/reference_appendices/playbooks_keywords.rst:416 -msgid "Boolean that allows you to ignore task failures and continue with play. It does not affect connection errors." -msgstr "タスクの失敗を無視してプレイを続行できるブール値。接続エラーには影響を及ぼしません。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:92 -#: ../../rst/reference_appendices/playbooks_keywords.rst:209 -#: ../../rst/reference_appendices/playbooks_keywords.rst:305 -#: ../../rst/reference_appendices/playbooks_keywords.rst:419 -msgid "ignore_unreachable" -msgstr "ignore_unreachable" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:92 -#: ../../rst/reference_appendices/playbooks_keywords.rst:209 -#: ../../rst/reference_appendices/playbooks_keywords.rst:305 -#: ../../rst/reference_appendices/playbooks_keywords.rst:419 -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." -msgstr "到達不可能なホストが原因でタスクの失敗を無視し、プレイを続行できるブール値。これは他のタスクエラーには影響を与えません (「:term:`ignore_errors`」参照)。揮発性/一時ホストのグループに役に立ちます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:95 -msgid "max_fail_percentage" -msgstr "max_fail_percentage" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:95 -msgid "can be used to abort the run after a given percentage of hosts in the current batch has failed. This only works on linear or linear derived strategies." -msgstr "現在のバッチ内の特定の割合のホストに障害が発生した後、実行を中止するために使用できます。これは、線形または線形派生ストラテジーにのみ影響します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:98 -#: ../../rst/reference_appendices/playbooks_keywords.rst:212 -#: ../../rst/reference_appendices/playbooks_keywords.rst:308 -#: ../../rst/reference_appendices/playbooks_keywords.rst:431 -msgid "Specifies default parameter values for modules." -msgstr "モジュールのデフォルトパラメーター値を指定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:101 -#: ../../rst/reference_appendices/playbooks_keywords.rst:215 -#: ../../rst/reference_appendices/playbooks_keywords.rst:311 -#: ../../rst/reference_appendices/playbooks_keywords.rst:434 -msgid "Identifier. Can be used for documentation, or in tasks/handlers." -msgstr "識別子。ドキュメントまたはタスク/ハンドラーに使用することができます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:104 -#: ../../rst/reference_appendices/playbooks_keywords.rst:218 -#: ../../rst/reference_appendices/playbooks_keywords.rst:314 -#: ../../rst/reference_appendices/playbooks_keywords.rst:437 -msgid "Boolean that controls information disclosure." -msgstr "情報の公開を制御するブール値。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:107 -msgid "order" -msgstr "order" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:107 -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." -msgstr "プレイの実行に使用するホストのソートを制御します。使用できる値は、inventory (デフォルト)、sorted、reverse_sorted、reverse_inventory、および shuffle です。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:110 -#: ../../rst/reference_appendices/playbooks_keywords.rst:221 -#: ../../rst/reference_appendices/playbooks_keywords.rst:320 -#: ../../rst/reference_appendices/playbooks_keywords.rst:446 -msgid "port" -msgstr "port" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:110 -#: ../../rst/reference_appendices/playbooks_keywords.rst:221 -#: ../../rst/reference_appendices/playbooks_keywords.rst:320 -#: ../../rst/reference_appendices/playbooks_keywords.rst:446 -msgid "Used to override the default port used in a connection." -msgstr "接続で使用されるデフォルトのポートを上書きするのに使用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:113 -msgid "post_tasks" -msgstr "post_tasks" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:113 -msgid "A list of tasks to execute after the :term:`tasks` section." -msgstr ":term:`tasks` セクションの後に実行するタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:116 -msgid "pre_tasks" -msgstr "pre_tasks" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:116 -msgid "A list of tasks to execute before :term:`roles`." -msgstr ":term:`roles` の前に実行するタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:119 -#: ../../rst/reference_appendices/playbooks_keywords.rst:224 -#: ../../rst/reference_appendices/playbooks_keywords.rst:323 -#: ../../rst/reference_appendices/playbooks_keywords.rst:452 -msgid "User used to log into the target via the connection plugin." -msgstr "connection プラグインでターゲットにログインするのに使用するユーザー。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:122 -msgid "roles" -msgstr "roles" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:122 -msgid "List of roles to be imported into the play" -msgstr "プレイにインポートするロールの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:125 -#: ../../rst/reference_appendices/playbooks_keywords.rst:227 -#: ../../rst/reference_appendices/playbooks_keywords.rst:329 -#: ../../rst/reference_appendices/playbooks_keywords.rst:458 -msgid "run_once" -msgstr "run_once" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:125 -#: ../../rst/reference_appendices/playbooks_keywords.rst:227 -#: ../../rst/reference_appendices/playbooks_keywords.rst:329 -#: ../../rst/reference_appendices/playbooks_keywords.rst:458 -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." -msgstr "ホストループを回避するブール値。タスクは、使用可能な最初のホストで実行を試行し、その後、同じバッチ内のすべてのアクティブなホストに結果とファクトを適用します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:128 -msgid "serial" -msgstr "serial" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:128 -msgid "Explicitly define how Ansible batches the execution of the current play on the play's target. See :ref:`rolling_update_batch_size`." -msgstr "Ansible が、プレイのターゲットで現在のプレイの実行をバッチ処理する方法を明示的に定義します。:ref:`rolling_update_batch_size` を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:131 -msgid "Allows you to choose the connection plugin to use for the play." -msgstr "プレイに使用する connection プラグインを選択できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:134 -#: ../../rst/reference_appendices/playbooks_keywords.rst:230 -#: ../../rst/reference_appendices/playbooks_keywords.rst:332 -#: ../../rst/reference_appendices/playbooks_keywords.rst:461 -msgid "tags" -msgstr "タグ" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:134 -#: ../../rst/reference_appendices/playbooks_keywords.rst:230 -#: ../../rst/reference_appendices/playbooks_keywords.rst:332 -#: ../../rst/reference_appendices/playbooks_keywords.rst:461 -msgid "Tags applied to the task or included tasks, this allows selecting subsets of tasks from the command line." -msgstr "タスクまたは含まれるタスクに適用されるタグ。これにより、コマンドラインからタスクのサブセットを選択できます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:137 -msgid "tasks" -msgstr "tasks" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:137 -msgid "Main list of tasks to execute in the play, they run after :term:`roles` and before :term:`post_tasks`." -msgstr "プレイで実行するタスクの主な一覧。:term:`roles` から :term:`post_tasks` の間に実行されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:140 -#: ../../rst/reference_appendices/playbooks_keywords.rst:233 -#: ../../rst/reference_appendices/playbooks_keywords.rst:335 -#: ../../rst/reference_appendices/playbooks_keywords.rst:464 -msgid "throttle" -msgstr "throttle" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:140 -#: ../../rst/reference_appendices/playbooks_keywords.rst:233 -#: ../../rst/reference_appendices/playbooks_keywords.rst:335 -#: ../../rst/reference_appendices/playbooks_keywords.rst:464 -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." -msgstr "タスク、ブロック、および Playbook レベルで実行される同時タスクの数を制限します。これはフォークとシリアル設定とは独立していますが、このような制限よりも高く設定することはできません。たとえば、フォークを 10 に設定し、スロットルが 15 に設定すると、ほぼ 10 台のホストを並行して操作します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:143 -#: ../../rst/reference_appendices/playbooks_keywords.rst:236 -#: ../../rst/reference_appendices/playbooks_keywords.rst:338 -#: ../../rst/reference_appendices/playbooks_keywords.rst:467 -msgid "Time limit for task to execute in, if exceeded Ansible will interrupt and fail the task." -msgstr "実行するタスクの時間制限。これを超えると、Ansible が割り込みし、タスクが失敗します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:146 -#: ../../rst/reference_appendices/playbooks_keywords.rst:239 -#: ../../rst/reference_appendices/playbooks_keywords.rst:341 -#: ../../rst/reference_appendices/playbooks_keywords.rst:473 -msgid "vars" -msgstr "vars" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:146 -#: ../../rst/reference_appendices/playbooks_keywords.rst:239 -#: ../../rst/reference_appendices/playbooks_keywords.rst:341 -#: ../../rst/reference_appendices/playbooks_keywords.rst:473 -msgid "Dictionary/map of variables" -msgstr "変数のディクショナリー/マップ。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:149 -msgid "vars_files" -msgstr "vars_files" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:149 -msgid "List of files that contain vars to include in the play." -msgstr "プレイに含まれる vars が含まれるファイルの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:153 -msgid "vars_prompt" -msgstr "vars_prompt" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:152 -msgid "list of variables to prompt for." -msgstr "プロンプトする変数の一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:156 -msgid "Role" -msgstr "ロール" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:194 -#: ../../rst/reference_appendices/playbooks_keywords.rst:290 -#: ../../rst/reference_appendices/playbooks_keywords.rst:401 -msgid "delegate_facts" -msgstr "delegate_facts" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:194 -#: ../../rst/reference_appendices/playbooks_keywords.rst:290 -#: ../../rst/reference_appendices/playbooks_keywords.rst:401 -msgid "Boolean that allows you to apply facts to a delegated host instead of inventory_hostname." -msgstr "inventory_hostname の代わりに委譲されたホストにファクトを適用できるようにするブール値。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:197 -#: ../../rst/reference_appendices/playbooks_keywords.rst:293 -#: ../../rst/reference_appendices/playbooks_keywords.rst:404 -msgid "delegate_to" -msgstr "delegate_to" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:197 -#: ../../rst/reference_appendices/playbooks_keywords.rst:293 -#: ../../rst/reference_appendices/playbooks_keywords.rst:404 -msgid "Host to execute task instead of the target (inventory_hostname). Connection vars from the delegated host will also be used for the task." -msgstr "ターゲットの代わりにタスクを実行するホスト (inventory_hostname)。委譲されたホストからの接続変数もタスクに使用されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:243 -#: ../../rst/reference_appendices/playbooks_keywords.rst:345 -#: ../../rst/reference_appendices/playbooks_keywords.rst:476 -msgid "when" -msgstr "when" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:242 -#: ../../rst/reference_appendices/playbooks_keywords.rst:344 -#: ../../rst/reference_appendices/playbooks_keywords.rst:476 -msgid "Conditional expression, determines if an iteration of a task is run or not." -msgstr "条件式。タスクの反復を実行するかどうかを決定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:246 -msgid "Block" -msgstr "ブロック (Block)" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:249 -msgid "List of tasks, in a block, that execute no matter if there is an error in the block or not." -msgstr "ブロックにエラーがあるかどうかに関係なく実行される、ブロック内のタスクのリスト。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:270 -msgid "block" -msgstr "block" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:270 -msgid "List of tasks in a block." -msgstr "ブロック内のタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:317 -#: ../../rst/reference_appendices/playbooks_keywords.rst:440 -msgid "notify" -msgstr "notify" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:317 -#: ../../rst/reference_appendices/playbooks_keywords.rst:440 -msgid "List of handlers to notify when the task returns a 'changed=True' status." -msgstr "タスクが「changed=True」の状態を返す際に通知するハンドラーのリスト。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:326 -msgid "rescue" -msgstr "rescue" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:326 -msgid "List of tasks in a :term:`block` that run if there is a task error in the main :term:`block` list." -msgstr "メインの :term:`block` 一覧にタスクエラーがある場合に実行される :term:`block` 内のタスクの一覧。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:351 -msgid "action" -msgstr "action" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:351 -msgid "The 'action' to execute for a task, it normally translates into a C(module) or action plugin." -msgstr "タスクで実行する「アクション」は、通常 C(module) または action プラグインに変換されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:357 -msgid "args" -msgstr "args" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:357 -msgid "A secondary way to add arguments into a task. Takes a dictionary in which keys map to options and values." -msgstr "引数をタスクに追加するセカンダリー方法。キーをオプションおよび値にマップするディクショナリーを作成します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:360 -msgid "async" -msgstr "async" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:360 -msgid "Run a task asynchronously if the C(action) supports this; value is maximum runtime in seconds." -msgstr "C(action) がこれをサポートする場合はタスクを非同期に実行します。値は、最大ランタイム (秒単位) です。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:378 -msgid "changed_when" -msgstr "changed_when" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:378 -msgid "Conditional expression that overrides the task's normal 'changed' status." -msgstr "タスクの通常の「changed」状態を上書きする条件式。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:398 -msgid "delay" -msgstr "delay" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:398 -msgid "Number of seconds to delay between retries. This setting is only used in combination with :term:`until`." -msgstr "再試行の間隔の遅延秒数。この設定は :term:`until` と組み合わせてのみ使用されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:413 -msgid "failed_when" -msgstr "failed_when" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:413 -msgid "Conditional expression that overrides the task's normal 'failed' status." -msgstr "タスクの通常の「failed」状態を上書きする条件式。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:422 -msgid "local_action" -msgstr "local_action" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:422 -msgid "Same as action but also implies ``delegate_to: localhost``" -msgstr "アクションと同じですが、``delegate_to: localhost`` という意味を含みます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:425 -msgid "loop" -msgstr "loop" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:425 -msgid "Takes a list for the task to iterate over, saving each list element into the ``item`` variable (configurable via loop_control)" -msgstr "タスクのリストを取り、各リスト要素を ``item`` 変数に保存します (loop_control で設定可能)。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:428 -msgid "loop_control" -msgstr "loop_control" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:428 -msgid "Several keys here allow you to modify/set loop behaviour in a task. See :ref:`loop_control`." -msgstr "ここにあるいくつかのキーを使用すると、タスクのループ動作を変更/設定できます。:ref:`loop_control` を参照してください。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:443 -msgid "poll" -msgstr "poll" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:443 -msgid "Sets the polling interval in seconds for async tasks (default 10s)." -msgstr "非同期タスク (デフォルトは 10) のポーリング間隔を秒単位で設定します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:449 -msgid "register" -msgstr "register" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:449 -msgid "Name of variable that will contain task status and module return data." -msgstr "タスクステータスとモジュールリターンデータが含まれる変数の名前。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:455 -msgid "retries" -msgstr "retries" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:455 -msgid "Number of retries before giving up in a :term:`until` loop. This setting is only used in combination with :term:`until`." -msgstr ":term:`until` ループで断念するまでの再試行回数。この設定は :term:`until` と組み合わせる場合にのみ使用されます。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:470 -msgid "until" -msgstr "until" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:470 -msgid "This keyword implies a ':term:`retries` loop' that will go on until the condition supplied here is met or we hit the :term:`retries` limit." -msgstr "このキーワードは、ここで提供された条件が満たされるまで、または :term:`retries` の制限に到達するまで実行される ':term:`retries` loop' を意味します。" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:481 -msgid "with_" -msgstr "with_" - -#: ../../rst/reference_appendices/playbooks_keywords.rst:479 -msgid "The same as ``loop`` but magically adds the output of any lookup plugin to generate the item list." -msgstr "``loop`` と同じですが、アイテム一覧を生成するために lookup プラグインの出力が視覚的に追加されます。" - -#: ../../rst/reference_appendices/python_3_support.rst:3 -msgid "Python 3 Support" -msgstr "Python 3 サポート" - -#: ../../rst/reference_appendices/python_3_support.rst:5 -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." -msgstr "Ansible 2.5 以降では Python 3 を使用しますが、Python 3 を使用する Ansible 2.4 以前のバージョンは、テクノロジープレビューとみなされます。以下のトピックでは、Python 3 を使用できるようにコントローラーと管理マシンを設定する方法を説明します。" - -#: ../../rst/reference_appendices/python_3_support.rst:9 -msgid "See :ref: `Control Node Requirements ` and :ref: `Managed Node Requirements ` for the specific versions supported." -msgstr "サポート対象のバージョンは、:ref:`Control Node Requirements ` および :ref:`Managed Node Requirements ` を参照してください。" - -#: ../../rst/reference_appendices/python_3_support.rst:12 -msgid "On the controller side" -msgstr "コントローラー側" - -#: ../../rst/reference_appendices/python_3_support.rst:14 -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:" -msgstr "Python 3 で :command:`/usr/bin/ansible` を最も簡単に実行するには、pip の Python 3 バージョンをインストールします。これでデフォルトで、Python 3 を使用して :command:`/usr/bin/ansible` を実行できます。" - -#: ../../rst/reference_appendices/python_3_support.rst:23 -msgid "If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your command through ``python3``. For example:" -msgstr "Ansible :ref:`from_source` を実行していて、ソースのチェックアウトに Python 3 を使用するには、``python3`` でコマンドを実行します。以下に例を示します。" - -#: ../../rst/reference_appendices/python_3_support.rst:32 -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 (through a separate package or through some commands that are run after install). You'll need to check with your distro to see if that applies in your case." -msgstr "個々の Linux ディストリビューションパッケージは、Python2 または Python3 にパッケージ化されます。ディストリビューションから実行する場合は、インストールされている Python バージョンでのみ Ansible を使用できます。障害により、複数の Python バージョン (別のパッケージ、またはインストール後に実行される一部のコマンドを介して) インストールを行う手段が提供されます。" - -#: ../../rst/reference_appendices/python_3_support.rst:40 -msgid "Using Python 3 on the managed machines with commands and playbooks" -msgstr "コマンドおよび Playbook を使用した管理マシンでの Python 3 の使用" - -#: ../../rst/reference_appendices/python_3_support.rst:42 -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``." -msgstr "Ansible は、同梱されている多数のプラットフォームで Python 3 を自動的に検出して使用します。Python 3 インタープリターを明示的に設定するには、グループまたはホストレベルで、:command:`/usr/bin/python3` などのように、``ansible_python_interpreter`` のインベントリー変数を Python 3 インタープリターの場所に指定します。デフォルトのインタープリターパスも、``ansible.cfg`` に設定できます。" - -#: ../../rst/reference_appendices/python_3_support.rst:47 -msgid ":ref:`interpreter_discovery` for more information." -msgstr "詳細は「:ref:`interpreter_discovery`」を参照してください。" - -#: ../../rst/reference_appendices/python_3_support.rst:62 -msgid ":ref:`intro_inventory` for more information." -msgstr "詳細は「:ref:`intro_inventory`」を参照してください。" - -#: ../../rst/reference_appendices/python_3_support.rst:64 -msgid "Run your command or playbook:" -msgstr "コマンドまたは Playbook を実行します。" - -#: ../../rst/reference_appendices/python_3_support.rst:72 -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:" -msgstr "コマンドの実行時に、`-e` コマンドラインオプションを指定して、手動で Python インタープリターを設定することもできる点に注意してください。これは、Python 3 で固有のモジュールや Playbook にバグが発生しているかをテストする場合に便利です。" - -#: ../../rst/reference_appendices/python_3_support.rst:82 -msgid "What to do if an incompatibility is found" -msgstr "非互換性が見つかった場合の対処方法" - -#: ../../rst/reference_appendices/python_3_support.rst:84 -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." -msgstr "Python 2 および Python 3 の両方で Ansible でコアとなる機能が実行できるように、複数リリースにわたってバグ修正や、新規テストが追加されました。ただし、バグは、エッジケースなどでまだ存在する可能性があります。また、Ansible に同梱されている多くのモジュールは、コミュニティーがメンテナンスを実施しており、すべてが移植されているわけではありません。" - -#: ../../rst/reference_appendices/python_3_support.rst:89 -msgid "If you find a bug running under Python 3 you can submit a bug report on `Ansible's GitHub project `_. Be sure to mention Python3 in the bug report so that the right people look at it." -msgstr "Python 3 で実行中にバグを発見した場合には、`Ansible の GitHub プロジェクト `_ からバグ報告を提出してください。適切な担当者が対応できるように、バグ報告には Python3 と記載するようにしてください。" - -#: ../../rst/reference_appendices/python_3_support.rst:93 -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." -msgstr "コードを修正して github へのプル要求を送信する場合は、Ansible コードベースで一般的な Python 3 の互換性の問題を修正する方法は、「:ref:`developing_python_3`」参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:5 -msgid "Releases and maintenance" -msgstr "リリースおよびメンテナンス" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:7 -msgid "This section describes release cycles, rules, and maintenance schedules for both Ansible community projects: the Ansible community package and ``ansible-core``. The two projects have different versioning systems, maintenance structures, contents, and workflows." -msgstr "このセクションでは、Ansibleコミュニティプロジェクトの両方 (Ansibleコミュニティパッケージと``ansible-core``) のリリースサイクル、ルール、およびメンテナンススケジュールについて説明します。この2つのプロジェクトのバージョン管理システム、保守構造、コンテンツ、およびワークフローは異なります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:10 -msgid "Ansible community package" -msgstr "Ansibleコミュニティパッケージ" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:12 -msgid "Uses new versioning (2.10, then 3.0.0)" -msgstr "新しいバージョン管理を使用する（2.10、次に3.0.0）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:12 -msgid "Continues \"classic Ansible\" versioning (2.11, then 2.12)" -msgstr "従来の Ansible バージョン管理を続行する（2.11、次に2.12）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:13 -msgid "Follows semantic versioning rules" -msgstr "セマンティックバージョニングルールに従う" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:13 -msgid "Does not use semantic versioning" -msgstr "セマンティックバージョニングを使用しない" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:14 -msgid "Maintains only one version at a time" -msgstr "一度に1つのバージョンのみを維持する" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:14 -msgid "Maintains latest version plus two older versions" -msgstr "最新バージョンと以前のバージョンを2つ維持する" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:15 -msgid "Includes language, runtime, and selected Collections" -msgstr "言語、ランタイム、および選択したコレクションが含まれる" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:15 -msgid "Includes language, runtime, and builtin plugins" -msgstr "言語、ランタイム、および組み込みプラグインが含まれる" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:16 -msgid "Developed and maintained in Collection repositories" -msgstr "コレクションリポジトリで開発および保守されている" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:16 -msgid "Developed and maintained in ansible/ansible repository" -msgstr "ansible / ansibleリポジトリで開発および保守されている" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:19 -msgid "Many community users install the Ansible community package. The Ansible community package offers the functionality that existed in Ansible 2.9, with more than 85 Collections containing thousands of modules and plugins. The ``ansible-core`` option is primarily for developers and users who want to install only the collections they need." -msgstr "多くのコミュニティユーザーがAnsibleコミュニティパッケージをインストールします。Ansibleコミュニティパッケージでは、Ansible 2.9に存在していた機能と、85を超えるコレクション (数千のモジュールとプラグインを含む) が提供されます。``ansible-core``オプションは主に、必要なコレクションだけをインストールする開発者とユーザー向けです。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:27 -msgid "Release cycle overview" -msgstr "リリースサイクルの概要" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:29 -msgid "The two community releases are related - the release cycle follows this pattern:" -msgstr "2つのコミュニティリリースは関連しており、リリースサイクルは以下のようなパターンになっています。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:31 -msgid "Release of a new ansible-core major version, for example, ansible-core 2.11" -msgstr "新しいansible-coreメジャーバージョンのリリース（ansible-core 2.11など）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:33 -msgid "New release of ansible-core and two prior versions are now maintained (in this case, ansible-base 2.10, Ansible 2.9)" -msgstr "ansible-coreの新しいリリースと2つ前までのバージョンが維持されるように（今回の場合はansible-base 2.10とAnsible 2.9）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:34 -msgid "Work on new features for ansible-core continues in the ``devel`` branch" -msgstr "ansible-coreの新機能に関する作業は``devel``ブランチで継続される" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:36 -msgid "Collection freeze (no new Collections or new versions of existing Collections) on the Ansible community package" -msgstr "Ansibleコミュニティパッケージでのコレクションのフリーズ（新しいコレクションや既存のコレクションの新しいバージョンはありません）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:37 -msgid "Release candidate for Ansible community package, testing, additional release candidates as necessary" -msgstr "Ansibleコミュニティパッケージのリリース候補、テスト、必要に応じて追加のリリース候補" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:38 -msgid "Release of a new Ansible community package major version based on the new ansible-core, for example, Ansible 4.0.0 based on ansible-core 2.11" -msgstr "新しいansible-coreに基づく新しいAnsibleコミュニティパッケージメジャーバージョンのリリース（例: ansible-core2.11に基づくAnsible4.0.0)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:40 -msgid "Newest release of the Ansible community package is the only version now maintained" -msgstr "Ansibleコミュニティパッケージの最新リリースだけが現在維持されているバージョンである" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:41 -msgid "Work on new features continues in Collections" -msgstr "新機能の作業はコレクションで継続される" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:42 -msgid "Individual Collections can make multiple minor and major releases" -msgstr "個々のコレクションは、複数のマイナーリリースおよび/またはメジャーリリースを作成できる" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:44 -msgid "Minor releases of three maintained ansible-core versions every three weeks (2.11.1)" -msgstr "3つのansible-core管理バージョンを3週間毎にマイナーリリース（2.11.1）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:45 -msgid "Minor releases of the single maintained Ansible community package version every three weeks (4.1.0)" -msgstr "Ansibleコミュニティーパッケージの管理バージョン1つを3週間毎にマイナーリリース（4.1.0）" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:46 -msgid "Feature freeze on ansible-core" -msgstr "ansible-core 機能のフリーズ" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:47 -msgid "Release candidate for ansible-core, testing, additional release candidates as necessary" -msgstr "ansible-core のリリース候補、テスト、必要に応じて追加のリリース候補" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:48 -msgid "Release of the next ansible-core major version, cycle begins again" -msgstr "次のansible-coreメジャーバージョンのリリース。サイクルの再開" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:51 -msgid "Ansible community package release cycle" -msgstr "Ansible コミュニティーパッケージのリリースサイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:53 -msgid "The Ansible community team typically releases two major versions of the community package per year, on a flexible release cycle that trails the release of ``ansible-core``. This cycle can be extended to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`ansible_roadmaps` for upcoming release details. Between major versions, we release a new minor version of the Ansible community package every three weeks. Minor releases include new backwards-compatible features, modules and plugins, as well as bug fixes." -msgstr "Ansible コミュニティーチームは通常、1年に2回メジャーバージョンをリリースし、柔軟なリリースサイクルで ``ansible-core`` のリリースに続きます。このサイクルは、新しいリリースを提供する前に規模の大きい変更を正しく実装してテストできるように、延期できるようになっています。今後のリリースの詳細は、:ref:`ansible_roadmaps`を参照してください。次のメジャーバージョンがリリースされるまでに、Ansible コミュニティーパッケージの新規マイナーバージョンが3週間毎にリリースされます。マイナーリリースには、後方互換性のある機能、モジュール、プラグインだけでなく、バグ修正が含まれます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:55 -msgid "Starting with version 2.10, the Ansible community team guarantees maintenance for only one major community package release at a time. For example, when Ansible 4.0.0 gets released, the team will stop making new 3.x releases. Community members may maintain older versions if desired." -msgstr "バージョン2.10以降、Ansibleコミュニティチームは、一度に主要なコミュニティパッケージリリースの保守の保証するのは1バージョンのみです。たとえば、Ansible チームでは、Ansible 4.0.0がリリースされると、新しい3.xリリースの作成を停止します。コミュニティメンバーは、必要に応じて古いバージョンを維持できます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:59 -msgid "Each Ansible EOL version may issue one final maintenance release at or shortly after the first release of the next version. When this happens, the final maintenance release is EOL at the date it releases." -msgstr "各 AnsibleEOL バージョンは、次のバージョンの最初のリリース時またはその直後に、1 つの最終メンテナンスリリースを発行する場合があります。その場合、最終メンテナンスリリースはリリース日で EOL になります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:64 -msgid "Older, unmaintained versions of the Ansible community package might contain unfixed security vulnerabilities (*CVEs*). If you are using a release of the Ansible community package that is no longer maintained, we strongly encourage you to upgrade as soon as possible to benefit from the latest features and security fixes." -msgstr "メンテナンスされていない以前のバージョンのAnsibleコミュニティパッケージには、修正されていないセキュリティの脆弱性（* CVE *）が含まれている可能性があります。メンテナンスが終了したAnsibleコミュニティパッケージのリリースを使用している場合は、できるだけ早くアップグレードして、最新の機能とセキュリティ修正を利用することを強くお勧めします。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:66 -msgid "Each major release of the Ansible community package accepts the latest released version of each included Collection and the latest released version of ansible-core. For specific schedules and deadlines, see the :ref:`ansible_roadmaps` for each version. Major releases of the Ansible community package can contain breaking changes in the modules and other plugins within the included Collections and in core features." -msgstr "Ansible コミュニティーパッケージの各メジャーリリースには、追加するコレクションごとの最新のリリースバージョンと、最新リリースバージョンの ansible-core を追加できます。具体的なスケジュールや期限については、各バージョンの:ref:`ansible_roadmaps`を参照してください。Ansible コミュニティーパッケージのメジャーリリースに含まれるコレクションやコア機能に、モジュールやその他の大規模な変更が含まれる可能性があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:68 -msgid "The Ansible community package follows semantic versioning rules. Minor releases of the Ansible community package accept only backwards-compatible changes in included Collections, that is, not Collections major releases. Collections must also use semantic versioning, so the Collection version numbers reflect this rule. For example, if Ansible 3.0.0 releases with community.general 2.0.0, then all minor releases of Ansible 3.x (such as Ansible 3.1.0 or Ansible 3.5.0) must include a 2.x release of community.general (such as 2.8.0 or 2.9.5) and not 3.x.x or later major releases." -msgstr "Ansibleコミュニティパッケージは、セマンティックバージョニングルールを使用します。Ansibleコミュニティパッケージのマイナーリリースは、同梱されているコレクションと下位互換性のある変更のみを受け入れます。つまり、コレクションのメジャーリリースは受け入れません。コレクションもセマンティックバージョニングを使用する必要があるため、コレクションのバージョン番号もこのルールを反映しています。たとえば、community.general 2.0.0 が含まれる Ansible 3.0.0 リリースの場合には、Ansible 3.x の全マイナーリリース (Ansbile 3.1.0 または Ansible 3.5.0など)には、3.0.0 以降のメジャーリリースではなく、 community.general (2.8.0 または 2.9.5など)の2.xリリースを含める必要があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:70 -msgid "Work in Collections is tracked within the individual Collection repositories." -msgstr "コレクションでの作業は、個々のコレクションリポジトリ内で追跡されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:72 -msgid "You can refer to the :ref:`Ansible package porting guides` for tips on updating your playbooks to run on newer versions of Ansible. For Ansible 2.10 and later releases, you can install the Ansible package with ``pip``. See :ref:`intro_installation_guide` for details. You can download older Ansible releases from ``_." -msgstr "Ansible Playbook を更新して新しいバージョンで実行するときのヒントについては、「:ref:`Ansible package porting guides`」を参照してください。Ansible 2.10 以降のリリースでは、``pip`` で Ansible パッケージをインストールできます。詳細は、「:ref:`intro_installation_guide`」を参照してください。Ansible リリースは ``_ からダウンロードできます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:76 -msgid "Ansible community changelogs" -msgstr "Ansible コミュニティーの変更ログ" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:78 -msgid "This table links to the changelogs for each major Ansible release. These changelogs contain the dates and significant changes in each minor release." -msgstr "以下の表には、Ansible の各メジャーリリースの変更ログへのリンクが含まれています。このような変更ログには、各マイナーリリースの日付や、大きな変更が含まれます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:81 -msgid "Ansible Community Package Release" -msgstr "Ansible コミュニティーパッケージのリリース" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:81 -msgid "Status" -msgstr "ステータス" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:81 -msgid "Core version dependency" -msgstr "Core バージョンの依存関係" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:83 -msgid "8.0.0" -msgstr "8.0.0" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:83 -msgid "In development (unreleased)" -msgstr "開発中 (未リリース)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:84 -msgid "`7.x Changelogs`_" -msgstr "`7.x Changelogs`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:84 -msgid "Current" -msgstr "現行" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:85 -msgid "`6.x Changelogs`_" -msgstr "`6.x Changelogs`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:85 -msgid "Unmaintained (end of life) after Ansible 6.7.0" -msgstr "Ansible 6.7.0 以降、メンテナンス対象外 (サポート終了)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:86 -msgid "`5.x Changelogs`_" -msgstr "`5.x Changelogs`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:86 -#: ../../rst/reference_appendices/release_and_maintenance.rst:87 -#: ../../rst/reference_appendices/release_and_maintenance.rst:88 -#: ../../rst/reference_appendices/release_and_maintenance.rst:89 -msgid "Unmaintained (end of life)" -msgstr "メンテナンス対象外 (エンドオフライフ)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:87 -msgid "`4.x Changelogs`_" -msgstr "`4.x Changelogs`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:88 -msgid "`3.x Changelogs`_" -msgstr "`3.x Changelogs`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:89 -msgid "`2.10 Changelogs`_" -msgstr "`2.10 Changelogs`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:101 -msgid "ansible-core release cycle" -msgstr "ansible-core リリースサイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:103 -msgid "``ansible-core`` is developed and released on a flexible release cycle. We can extend this cycle to properly implement and test larger changes before a new release is made available. See :ref:`ansible_core_roadmaps` for upcoming release details." -msgstr "``ansible-core`` は、柔軟なリリースサイクルで開発およびリリースされます。このサイクルを延長して、新しいリリースが利用可能になる前に、より大きな変更を適切に実装およびテストできます。今後のリリースの詳細については :ref:`ansible_core_roadmaps` を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:105 -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." -msgstr "``ansible-core`` には、3 つのメジャーリリースで展開される段階的なメンテナンス構造があります。詳細は、「:ref:`development_and_stable_version_maintenance_workflow`」を参照してください。また、現在のリリースがどの程度メンテナンスされているかについては、:ref:`release_schedule` の表を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:111 -msgid "Older, unmaintained versions of ``ansible-core`` can contain unfixed security vulnerabilities (*CVEs*). If you are using a release of ``ansible-core`` that is no longer maintained, we strongly encourage you to upgrade as soon as possible to benefit from the latest features and security fixes. ``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." -msgstr "``ansible-core``のメンテナンスされていない以前のバージョンには、セキュリティー脆弱性 (*CVE*) が含まれる場合があります。保守のない``ansible-core``のリリースを使用している場合には、最新の機能およびセキュリティー修正を活用できるように、すぐにアップグレードすることを強く推奨します。``ansible-core``の保守は、3リリース分継続されます。そのため、最新のリリースでは、初回リリース時にセキュリティーと一般的なバグ修正が、次の``ansible-core``バージョンがリリースされると、セキュリティーと重大なバグ修正が、その次のバージョンがリリースされると、セキュリティー修正**のみ**が提供されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:113 -msgid "You can refer to the :ref:`core_porting_guides` for tips on updating your playbooks to run on newer versions of ``ansible-core``." -msgstr "Playbook を更新して``ansible-core`` の新しいバージョンで実行するときのヒントは、「:ref:`core_porting_guides`」を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:115 -msgid "You can install ``ansible-core`` with ``pip``. See :ref:`intro_installation_guide` for details." -msgstr "``pip`` で ``ansible-core`` をインストールできます。詳細は、「:ref:`intro_installation_guide`」を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:121 -msgid "``ansible-core`` support matrix" -msgstr "``ansible-core`` サポートマトリックス" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:123 -msgid "This table links to the changelogs for each major ``ansible-core`` release. These changelogs contain the dates and significant changes in each minor release. Dates listed indicate the start date of the maintenance cycle." -msgstr "以下の表には、``ansible-core`` の各メジャーリリースの変更ログへのリンクが含まれています。このような変更ログには、各マイナーリリースの日付や、大きな変更が含まれます。記載の日付は、メンテナンスサイクルの開始日を指します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:129 -msgid "Version" -msgstr "バージョン" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:130 -msgid "Support" -msgstr "サポート" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:131 -msgid "End Of Life" -msgstr "ライフサイクル終了日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:132 -msgid "Controller Python" -msgstr "Controller Python" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:133 -msgid "Target Python / PowerShell" -msgstr "Target Python / PowerShell" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:134 -msgid "`2.15`_" -msgstr "`2.15`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 22 May 2023" -msgstr "一般提供: 2023 年 5 月 22 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 06 Nov 2023" -msgstr "クリティカル: 2023 年 11 月 6 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 20 May 2024" -msgstr "セキュリティー: 2024 年 5 月 20 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:138 -msgid "Nov 2024" -msgstr "2024 年 11 月" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 3.9 - 3.11" -msgstr "Python 3.9 - 3.11" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 2.7" -msgstr "Python 2.7" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 3.5 - 3.11" -msgstr "Python 3.5 - 3.11" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "PowerShell 3 - 5.1" -msgstr "PowerShell 3 - 5.1" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:143 -msgid "`2.14`_" -msgstr "`2.14`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 07 Nov 2022" -msgstr "一般提供: 2022 年 11 月 7 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 22 May 2023" -msgstr "クリティカル: 2023 年 5 月 22 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 06 Nov 2023" -msgstr "セキュリティー: 2023 年 11 月 6 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:147 -msgid "20 May 2024" -msgstr "2024 年 5 月 20 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:152 -msgid "`2.13`_" -msgstr "`2.13`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 23 May 2022" -msgstr "一般提供: 2022 年 5 月 23 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 07 Nov 2022" -msgstr "クリティカル: 2022 年 11 月 7 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 22 May 2023" -msgstr "セキュリティー: 2023 年 5 月 22 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:156 -msgid "06 Nov 2023" -msgstr "2023 年 11 月 6 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 3.8 - 3.10" -msgstr "Python 3.8 - 3.10" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 3.5 - 3.10" -msgstr "Python 3.5 - 3.10" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:161 -msgid "`2.12`_" -msgstr "`2.12`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 08 Nov 2021" -msgstr "一般提供: 2021 年 11 月 8 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 23 May 2022" -msgstr "クリティカル: 2022 年 5 月 23 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 07 Nov 2022" -msgstr "セキュリティー: 2022 年 11 月 7 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:165 -msgid "22 May 2023" -msgstr "2023 年 5 月 22 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 2.6" -msgstr "Python 2.6" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:170 -msgid "`2.11`_" -msgstr "`2.11`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 26 Apr 2021" -msgstr "一般提供: 2021 年 4 月 26 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 08 Nov 2021" -msgstr "クリティカル: 2021 年 11 月 8 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 23 May 2022" -msgstr "セキュリティー: 2022 年 5 月 23 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "**EOL**" -msgstr "**EOL**" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "07 Nov 2022" -msgstr "2023 年 11 月 7 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 3.5 - 3.9" -msgstr "Python 3.5 - 3.9" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 2.6 - 2.7" -msgstr "Python 2.6 - 2.7" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:181 -msgid "`2.10`_" -msgstr "`2.10`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 13 Aug 2020" -msgstr "一般提供: 2020 年 8 月 13 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 26 Apr 2021" -msgstr "クリティカル: 2021 年 4 月 26 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 08 Nov 2021" -msgstr "セキュリティー: 2021 年 11 月 8 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "23 May 2022" -msgstr "2022 年 5 月 23 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:192 -msgid "`2.9`_" -msgstr "`2.9`_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "GA: 31 Oct 2019" -msgstr "一般提供: 2019 年 10 月 31 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Critical: 13 Aug 2020" -msgstr "クリティカル: 2020 年 8 月 13 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Security: 26 Apr 2021" -msgstr "セキュリティー: 2021 年 4 月 26 日" - -#: ../../rst/reference_appendices/release_and_maintenance.rst -msgid "Python 3.5 - 3.8" -msgstr "Python 3.5 - 3.8" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:295 -msgid "Preparing for a new release" -msgstr "新しいリリースの準備" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:300 -msgid "Feature freezes" -msgstr "機能フリーズ" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:302 -msgid "During final preparations for a new release, core developers and maintainers focus on improving the release candidate, not on adding or reviewing new features. We may impose a feature freeze." -msgstr "新しいリリースの最終準備中、コア開発者とメンテナは、新機能の追加やレビューではなく、リリース候補の改善に集中します。機能フリーズを指示する場合があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:304 -msgid "A feature freeze means that we delay new features and fixes unrelated to the pending release so we can create the new release as soon as possible." -msgstr "機能フリーズとは、保留中のリリースに関連のない新機能や修正を遅らせて、新しいリリースをできるだけ早く作成できるようにすることを意味します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:309 -msgid "Release candidates" -msgstr "リリースの候補 (Release Candidate)" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:311 -msgid "We create at least one release candidate before each new major release of Ansible or ``ansible-core``. Release candidates allow the Ansible community to try out new features, test existing playbooks on the release candidate, and report bugs or issues they find." -msgstr "Ansibleまたは``ansible-core``の新しいメジャーリリースの前に毎回、少なくとも1つのリリース候補を作成します。リリース候補を使用することで、Ansibleコミュニティは新機能を試したり、リリース候補で既存のPlaybookをテストしたり、見つかったバグや問題を報告したりできます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:313 -msgid "Ansible and ``ansible-core`` tag the first release candidate (RC1) which is usually scheduled to last five business days. If no major bugs or issues are identified during this period, the release candidate becomes the final release." -msgstr "Ansible および ``ansible-core`` は、最初のリリース候補のタグ (RC1) が付けられます。通常、RC1 は最後の5営業日にスケジュールされます。この期間にメジャーなバグや問題が特定されない場合には、リリース候補が最終リリースとなります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:315 -msgid "If there are major problems with the first candidate, the team and the community fix them and tag a second release candidate (RC2). This second candidate lasts for a shorter duration than the first. If no problems have been reported for an RC2 after two business days, the second release candidate becomes the final release." -msgstr "最初の候補に大きな問題がある場合は、チームおよびコミュニティーが修正を加えて、2 番目の候補のタグ (RC2) が付けられます。2 番目の候補は、1 番目よりも期間は短くなります。2 営業日が経過して問題が報告されない場合は、この2番目のリリース候補が最終的なリリースとなります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:317 -msgid "If there are major problems in RC2, the cycle begins again with another release candidate and repeats until the maintainers agree that all major problems have been fixed." -msgstr "RC2に重大な問題がある場合には、サイクルは別のリリース候補から再開され、すべての主要な問題が修正されたことにメンテナが同意するまで繰り返されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:323 -msgid "Development and maintenance workflows" -msgstr "開発と保守のワークフロー" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:325 -msgid "In between releases, the Ansible community develops new features, maintains existing functionality, and fixes bugs in ``ansible-core`` and in the collections included in the Ansible community package." -msgstr "次のリリースまでの間に、Ansibleコミュニティは新しい機能を開発して既存の機能のメンテナンスを行い、``ansible-core`` や Ansible コミュニティーパッケージに含まれるコレクションのバグを修正します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:328 -msgid "Ansible community package workflow" -msgstr "Ansible コミュニティパッケージのワークフロー" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:330 -msgid "The Ansible community develops and maintains the features and functionality included in the Ansible community package in Collections repositories, with a workflow that looks like this:" -msgstr "Ansibleコミュニティは、コレクションリポジトリのAnsibleコミュニティパッケージに含まれる機能を開発および保守します。ワークフローは次のようになります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:332 -msgid "Developers add new features and bug fixes to the individual Collections, following each Collection's rules on contributing." -msgstr "開発者は、貢献に関する各コレクションのルールに従って、個々のコレクションに新機能とバグ修正を追加する。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:333 -#: ../../rst/reference_appendices/release_and_maintenance.rst:347 -msgid "Each new feature and each bug fix includes a changelog fragment describing the work." -msgstr "各新機能と各バグ修正には、作業を説明する変更ログフラグメントが含まれている。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:334 -msgid "Release engineers create a minor release for the current version every three weeks to ensure that the latest bug fixes are available to users." -msgstr "リリースエンジニアは、最新のバグ修正をユーザーが利用できるように、現在のバージョンのマイナーリリースを3週間ごとに作成する。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:335 -msgid "At the end of the development period, the release engineers announce which Collections, and which major version of each included Collection, will be included in the next release of the Ansible community package. New Collections and new major versions may not be added after this, and the work of creating a new release begins." -msgstr "開発期間の終わりに、リリースエンジニアは、Ansibleコミュニティパッケージの次のリリースに含まれるコレクションと、追加済みの各コレクションのメジャーバージョンを発表します。これ以降は、コレクションおよびメジャーバージョンは新たに追加できず、新しいリリースの作成準備が開始されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:337 -msgid "We generally do not provide fixes for unmaintained releases of the Ansible community package, however, there can sometimes be exceptions for critical issues." -msgstr "通常、Ansible コミュニティーパッケージで保守されていないバージョンに対する修正は提供していませんが、重大な問題に関しては例外で対応する可能性があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:339 -msgid "Some Collections are maintained by the Ansible team, some by Partner organizations, and some by community teams. For more information on adding features or fixing bugs in Ansible-maintained Collections, see :ref:`contributing_maintained_collections`." -msgstr "Ansibleチーム、パートナー組織、コミュニティチームがコレクションをそれぞれ部分的に管理しています。 Ansibleで管理されているコレクションの機能の追加やバグの修正の詳細については、:ref:`contributing_maintained_collections` を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:342 -msgid "ansible-core workflow" -msgstr "ansible-core ワークフロー" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:344 -msgid "The Ansible community develops and maintains ``ansible-core`` on GitHub_, with a workflow that looks like this:" -msgstr "Ansibleコミュニティは、GitHub_の``ansible-core``で開発と維持を行っており、次のようなワークフローを使用します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:346 -msgid "Developers add new features and bug fixes to the ``devel`` branch." -msgstr "開発者は、``devel``ブランチに新機能とバグ修正を追加する。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:348 -msgid "The development team backports bug fixes to one, two, or three stable branches, depending on the severity of the bug. They do not backport new features." -msgstr "開発チームは、バグの重大度に応じて、バグ修正を1つ、2つ、または3つの安定したブランチにバックポートし、新機能のバックポートは行わない。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:349 -msgid "Release engineers create a minor release for each maintained version every three weeks to ensure that the latest bug fixes are available to users." -msgstr "リリースエンジニアは、最新のバグ修正をユーザーが利用できるように、各保守バージョンのマイナーリリースを3週間ごとに作成する。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:350 -msgid "At the end of the development period, the release engineers impose a feature freeze and the work of creating a new release begins." -msgstr "開発期間の終わりに、リリースエンジニアは機能をフリーズし、新しいリリースの準備を開始する。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:352 -msgid "We generally do not provide fixes for unmaintained releases of ``ansible-core``, however, there can sometimes be exceptions for critical issues." -msgstr "通常、メンテナンスされていない``ansible-core``リリースに対する修正は提供していませんが、重大な問題に関しては例外で対応する可能性があります。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:354 -msgid "For more information about adding features or fixing bugs in ``ansible-core`` see :ref:`community_development_process`." -msgstr "``ansible-core`` の機能の追加またはバグの修正の詳細については、:ref:`community_development_process` を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:361 -msgid "Generating changelogs" -msgstr "変更ログの生成" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:363 -msgid "We generate changelogs based on fragments. When creating new features for existing modules and plugins 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." -msgstr "変更ログは、フラグメントに基づいて生成されます。既存のモジュールやプラグインの新しい機能を作成したり、バグを修正したりするときは、変更点を記述した変更ログフラグメントを作成します。変更ログのエントリーは、新しいモジュールやプラグインには必要ありません。それらの項目の詳細は、モジュールのドキュメントから生成されます。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:365 -msgid "To add changelog fragments to Collections in the Ansible community package, we recommend the `antsibull-changelog utility `_." -msgstr "Ansibleコミュニティパッケージのコレクションに変更ログフラグメントを追加するには、`antsibull-changelog utility `_を推奨します。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:367 -msgid "To add changelog fragments for new features and bug fixes in ``ansible-core``, see the :ref:`changelog examples and instructions` in the Community Guide." -msgstr "``ansible-core``に新機能とバグ修正の変更ログフラグメントを追加するには、コミュニティガイドの:ref:`changelog examples and instructions`を参照してください。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:370 -msgid "Deprecation cycles" -msgstr "非推奨サイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:372 -msgid "Sometimes we 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." -msgstr "通常、再実装してジョブ実行の改善を希望する場合など、機能を削除することがあります。これを行うために、非推奨のサイクルがあります。まず、機能を「非推奨」としてマークします。これには通常、非推奨になった理由、ユーザーが切り替える必要のある代替手段、および機能を完全に削除する予定の時期 (バージョン) に関する警告が伴います。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:375 -msgid "Ansible community package deprecation cycle" -msgstr "Ansibleコミュニティパッケージの非推奨サイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:377 -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 3.1.0 and do not remove the feature until 5.0.0 or 4.0.0 at the earliest. Collections should use semantic versioning, such that the major collection version cannot be changed within an Ansible major version. Therefore, the removal should not happen before the next major Ansible community package release. This is up to each collection maintainer and cannot be guaranteed." -msgstr "Ansible は個別のコレクションのパッケージであるため、非推奨のサイクルはコレクションのメンテナーによって異なります。コレクションメンテナーは 1 つの Ansible メジャーバージョンでこの機能を非推奨にし、1 年間でその機能を削除するか、少なくとも次の Ansible バージョンまでに削除しないことを推奨します。たとえば、3.1.0 でこの機能を非推奨にした場合は、最低でも 5.0.0 または 4.0.0 までの機能を削除しないでください。コレクションはセマンティックバージョニングを使用する必要があります。したがって、メジャーコレクションバージョンは、Ansible メジャーバージョン内で変更できません。したがって、次のメジャーリリースの Ansible コミュニティーパッケージリリースの前に削除することはできません。これは、各コレクションのメンテナーの役割であり、保証されているものではありません。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:380 -msgid "ansible-core deprecation cycle" -msgstr "ansible-core 非推奨サイクル" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:382 -msgid "The deprecation cycle in ``ansible-core`` is normally across 4 feature releases (2.x. where the x marks a feature release). The feature is normally removed in the 4th release after we announce the deprecation. For example, something deprecated in 2.10 will be removed in 2.14. The tracking is tied to the number of releases, not the release numbering itself." -msgstr "``ansible-core`` の非推奨サイクルは通常 4 つの機能リリース (たとえば 2.x. の x は機能リリースを示す) にまたがるため、機能は通常、非推奨を発表してから 4 番目のリリースで削除されます。たとえば、2.10 で非推奨になったものは、2.14 で削除されます。追跡は、リリース番号ではなく、リリースの数に自体に関連付けられています。" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:386 -msgid ":ref:`community_committer_guidelines`" -msgstr ":ref:`community_committer_guidelines`" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:387 -msgid "Guidelines for Ansible core contributors and maintainers" -msgstr "Ansible で中心となる貢献者およびメンテナー向けガイドライン" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:388 -msgid ":ref:`testing_strategies`" -msgstr ":ref:`testing_strategies`" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:389 -msgid "Testing strategies" -msgstr "ストラテジーのテスト" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:390 -msgid ":ref:`ansible_community_guide`" -msgstr ":ref:`ansible_community_guide`" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:391 -msgid "Community information and contributing" -msgstr "コミュニティー情報および貢献" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:392 -msgid "`Development Mailing List `_" -msgstr "`Development Mailing List `_" - -#: ../../rst/reference_appendices/release_and_maintenance.rst:393 -msgid "Mailing list for development topics" -msgstr "開発トピックのメーリングリスト" - -#: ../../rst/reference_appendices/special_variables.rst:4 -msgid "Special Variables" -msgstr "特別な変数" - -#: ../../rst/reference_appendices/special_variables.rst:7 -msgid "Magic variables" -msgstr "マジック変数" - -#: ../../rst/reference_appendices/special_variables.rst:8 -msgid "These variables cannot be set directly by the user; Ansible will always override them to reflect internal state." -msgstr "マジック変数は、ユーザーが直接設定できません。Ansible がシステム内の状態を反映してこの変数を常にオーバーライドします。" - -#: ../../rst/reference_appendices/special_variables.rst:11 -msgid "ansible_check_mode" -msgstr "ansible_check_mode" - -#: ../../rst/reference_appendices/special_variables.rst:11 -msgid "Boolean that indicates if we are in check mode or not" -msgstr "チェックモードかどうかを指定するブール値" - -#: ../../rst/reference_appendices/special_variables.rst:14 -msgid "ansible_config_file" -msgstr "ansible_config_file" - -#: ../../rst/reference_appendices/special_variables.rst:14 -msgid "The full path of used Ansible configuration file" -msgstr "Ansbile 設定ファイルに使用するフルパス" - -#: ../../rst/reference_appendices/special_variables.rst:17 -msgid "ansible_dependent_role_names" -msgstr "ansible_dependent_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:17 -msgid "The names of the roles currently imported into the current play as dependencies of other plays" -msgstr "他のプレイの依存関係として現在のプレイに現在インポートされているロールの名前" - -#: ../../rst/reference_appendices/special_variables.rst:20 -msgid "ansible_diff_mode" -msgstr "ansible_diff_mode" - -#: ../../rst/reference_appendices/special_variables.rst:20 -msgid "Boolean that indicates if we are in diff mode or not" -msgstr "diff モードかどうかを指定するブール値" - -#: ../../rst/reference_appendices/special_variables.rst:23 -msgid "ansible_forks" -msgstr "ansible_forks" - -#: ../../rst/reference_appendices/special_variables.rst:23 -msgid "Integer reflecting the number of maximum forks available to this run" -msgstr "今回の実行で利用可能な最大フォーク数 (整数)" - -#: ../../rst/reference_appendices/special_variables.rst:26 -msgid "ansible_inventory_sources" -msgstr "ansible_inventory_sources" - -#: ../../rst/reference_appendices/special_variables.rst:26 -msgid "List of sources used as inventory" -msgstr "インベントリーとして使用されるソースの一覧" - -#: ../../rst/reference_appendices/special_variables.rst:29 -msgid "ansible_limit" -msgstr "ansible_limit" - -#: ../../rst/reference_appendices/special_variables.rst:29 -msgid "Contents of the ``--limit`` CLI option for the current execution of Ansible" -msgstr "Ansible の現在の実行に対して、CLI オプション ``--limit`` として指定する内容" - -#: ../../rst/reference_appendices/special_variables.rst:32 -msgid "ansible_loop" -msgstr "ansible_loop" - -#: ../../rst/reference_appendices/special_variables.rst:32 -msgid "A dictionary/map containing extended loop information when enabled through ``loop_control.extended``" -msgstr "``loop_control.extended`` で有効にした場合に loop の拡張情報を含むディクショナリー/マップ" - -#: ../../rst/reference_appendices/special_variables.rst:35 -msgid "ansible_loop_var" -msgstr "ansible_loop_var" - -#: ../../rst/reference_appendices/special_variables.rst:35 -msgid "The name of the value provided to ``loop_control.loop_var``. Added in ``2.8``" -msgstr "``loop_control.loop_var`` に渡す値の名前。``2.8`` に追加。" - -#: ../../rst/reference_appendices/special_variables.rst:38 -msgid "ansible_index_var" -msgstr "ansible_index_var" - -#: ../../rst/reference_appendices/special_variables.rst:38 -msgid "The name of the value provided to ``loop_control.index_var``. Added in ``2.9``" -msgstr "``loop_control.index_var`` に渡す値の名前。``2.9`` に追加。" - -#: ../../rst/reference_appendices/special_variables.rst:44 -msgid "ansible_parent_role_names" -msgstr "ansible_parent_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:41 -msgid "When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` 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." -msgstr "現在のロールが、:ref:`include_role ` アクションまたは :ref:`import_role ` アクションによって実行されている場合、この変数にはすべての親ロールのリストが含まれ、最新のロール (つまり、このロールを含む/インポートしたロール) がリストの最初の項目になります。複数の包含が発生する場合、このリストには、*最後の* ロール (つまり、このロールを含むロール) がリストの *最初の* 項目として挙げられます。このリストに特定の役割が複数存在する可能性もあります。" - -#: ../../rst/reference_appendices/special_variables.rst:44 -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']``." -msgstr "たとえば、ロール **A** にロール **B** が含まれる場合は、ロール B 内の ``ansible_parent_role_names`` は ``['A']`` と等しくなります。次にロール **B** にロール **C** が含まれると、一覧は ``['B', 'A']`` になります。" - -#: ../../rst/reference_appendices/special_variables.rst:48 -msgid "ansible_parent_role_paths" -msgstr "ansible_parent_role_paths" - -#: ../../rst/reference_appendices/special_variables.rst:47 -msgid "When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` action, this variable contains a list of all parent roles paths, 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." -msgstr "現在のロールが :ref:`include_role ` アクションまたは :ref:`import_role ` アクションで実行されていると、この変数には親のロールパスの全一覧と、その一覧の最初の項目である最新のロール (つまり、このロールを追加/インポートしたロール) が含まれます。このリストの項目の順序は、「``ansible_parent_role_names``」を参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:51 -msgid "ansible_play_batch" -msgstr "ansible_play_batch" - -#: ../../rst/reference_appendices/special_variables.rst:51 -msgid "List of active hosts in the current play run limited by the serial, aka 'batch'. Failed/Unreachable hosts are not considered 'active'." -msgstr "シリアルで制限される現在のプレイ実行に含まれるアクティブなホスト一覧 (「バッチ」と呼ばれます)。失敗したホストや到達不可能なホストは、「アクティブ」とはみなされません。" - -#: ../../rst/reference_appendices/special_variables.rst:54 -msgid "ansible_play_hosts" -msgstr "ansible_play_hosts" - -#: ../../rst/reference_appendices/special_variables.rst:54 -msgid "List of hosts in the current play run, not limited by the serial. Failed/Unreachable hosts are excluded from this list." -msgstr "現在のプレイのホスト一覧は、シリアルによって制限されません。失敗したホストまたは到達不可能なホストはこの一覧から除外されます。" - -#: ../../rst/reference_appendices/special_variables.rst:57 -msgid "ansible_play_hosts_all" -msgstr "ansible_play_hosts_all" - -#: ../../rst/reference_appendices/special_variables.rst:57 -msgid "List of all the hosts that were targeted by the play" -msgstr "プレイが対象としたホストの一覧" - -#: ../../rst/reference_appendices/special_variables.rst:61 -msgid "ansible_play_role_names" -msgstr "ansible_play_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:60 -msgid "The names of the roles currently imported into the current play. This list does **not** contain the role names that are implicitly included through dependencies." -msgstr "現在のプレイにインポートされているロール名。この一覧には、依存関係で暗黙的に含まれるロール名は **含まれません**。" - -#: ../../rst/reference_appendices/special_variables.rst:64 -msgid "ansible_playbook_python" -msgstr "ansible_playbook_python" - -#: ../../rst/reference_appendices/special_variables.rst:64 -msgid "The path to the python interpreter being used by Ansible on the controller" -msgstr "Ansible が使用する Python インタープリターへのコントローラー上のパス" - -#: ../../rst/reference_appendices/special_variables.rst:68 -msgid "ansible_role_names" -msgstr "ansible_role_names" - -#: ../../rst/reference_appendices/special_variables.rst:67 -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." -msgstr "現在のプレイに現在インポートされているロール名、または現在のプレイにインポートされているロールの依存関係として参照されているロール名" - -#: ../../rst/reference_appendices/special_variables.rst:71 -msgid "ansible_role_name" -msgstr "ansible_role_name" - -#: ../../rst/reference_appendices/special_variables.rst:71 -msgid "The fully qualified collection role name, in the format of ``namespace.collection.role_name``" -msgstr "``namespace.collection.role_name`` の形式である完全修飾コレクションのロール名" - -#: ../../rst/reference_appendices/special_variables.rst:74 -msgid "ansible_collection_name" -msgstr "ansible_collection_name" - -#: ../../rst/reference_appendices/special_variables.rst:74 -msgid "The name of the collection the task that is executing is a part of. In the format of ``namespace.collection``" -msgstr "実行しているタスクが一部であるコレクションの名前 (``namespace.collection`` の形式)。" - -#: ../../rst/reference_appendices/special_variables.rst:77 -msgid "ansible_run_tags" -msgstr "ansible_run_tags" - -#: ../../rst/reference_appendices/special_variables.rst:77 -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\"]``." -msgstr "CLI オプション ``--tags`` の内容。現在の実行に含まれるタグを指定します。``--tags`` が渡されない場合、この変数はデフォルトで ``[\"all\"]`` になります。" - -#: ../../rst/reference_appendices/special_variables.rst:80 -msgid "ansible_search_path" -msgstr "ansible_search_path" - -#: ../../rst/reference_appendices/special_variables.rst:80 -msgid "Current search path for action plugins and lookups, in other words, where we search for relative paths when you do ``template: src=myfile``" -msgstr "action プラグインとルックアップの現在の検索パス。つまり、``template: src=myfile`` を指定したときに検索する相対パスです。" - -#: ../../rst/reference_appendices/special_variables.rst:83 -msgid "ansible_skip_tags" -msgstr "ansible_skip_tags" - -#: ../../rst/reference_appendices/special_variables.rst:83 -msgid "Contents of the ``--skip-tags`` CLI option, which specifies which tags will be skipped for the current run." -msgstr "現在の実行で省略するタグを指定する ``--skip-tags`` CLI オプションの内容。" - -#: ../../rst/reference_appendices/special_variables.rst:86 -msgid "ansible_verbosity" -msgstr "ansible_verbosity" - -#: ../../rst/reference_appendices/special_variables.rst:86 -msgid "Current verbosity setting for Ansible" -msgstr "Ansible の現在の詳細レベル設定" - -#: ../../rst/reference_appendices/special_variables.rst:89 -msgid "ansible_version" -msgstr "ansible_version" - -#: ../../rst/reference_appendices/special_variables.rst:89 -msgid "Dictionary/map that contains information about the current running version of ansible, it has the following keys: full, major, minor, revision and string." -msgstr "現在実行している Ansible のバージョンに関する情報を含むディクショナリー/マップ。full、major、minor、revision、string などのキーが含まれます。" - -#: ../../rst/reference_appendices/special_variables.rst:92 -msgid "group_names" -msgstr "group_names" - -#: ../../rst/reference_appendices/special_variables.rst:92 -msgid "List of groups the current host is part of" -msgstr "現在のホストが所属するグループの一覧" - -#: ../../rst/reference_appendices/special_variables.rst:95 -msgid "groups" -msgstr "グループ" - -#: ../../rst/reference_appendices/special_variables.rst:95 -msgid "A dictionary/map with all the groups in inventory and each group has the list of hosts that belong to it" -msgstr "インベントリー内の全グループを含むディクショナリー/マップ。各グループには、所属するホストの一覧が含まれます。" - -#: ../../rst/reference_appendices/special_variables.rst:98 -msgid "hostvars" -msgstr "hostvars" - -#: ../../rst/reference_appendices/special_variables.rst:98 -msgid "A dictionary/map with all the hosts in inventory and variables assigned to them" -msgstr "インベントリー内の全ホスト、そのホストに割当てられた変数を含むディクショナリー/マップ" - -#: ../../rst/reference_appendices/special_variables.rst:101 -msgid "inventory_hostname" -msgstr "inventory_hostname" - -#: ../../rst/reference_appendices/special_variables.rst:101 -msgid "The inventory name for the 'current' host being iterated over in the play" -msgstr "プレイで繰り返される「現在」のホストのイベントリー名" - -#: ../../rst/reference_appendices/special_variables.rst:104 -msgid "inventory_hostname_short" -msgstr "inventory_hostname_short" - -#: ../../rst/reference_appendices/special_variables.rst:104 -msgid "The short version of `inventory_hostname`" -msgstr "`inventory_hostname` の短縮版" - -#: ../../rst/reference_appendices/special_variables.rst:107 -msgid "inventory_dir" -msgstr "inventory_dir" - -#: ../../rst/reference_appendices/special_variables.rst:107 -msgid "The directory of the inventory source in which the `inventory_hostname` was first defined" -msgstr "`inventory_hostname` を最初に定義したインベントリーソースのディレクトリー" - -#: ../../rst/reference_appendices/special_variables.rst:110 -msgid "inventory_file" -msgstr "inventory_file" - -#: ../../rst/reference_appendices/special_variables.rst:110 -msgid "The file name of the inventory source in which the `inventory_hostname` was first defined" -msgstr "`inventory_hostname` を最初に定義したインベントリーソースのファイル名" - -#: ../../rst/reference_appendices/special_variables.rst:113 -msgid "omit" -msgstr "omit" - -#: ../../rst/reference_appendices/special_variables.rst:113 -msgid "Special variable that allows you to 'omit' an option in a task, for example ``- user: name=bob home={{ bobs_home|default(omit) }}``" -msgstr "タスクのオプションを「省略」できるようにする特別変数 (つまり ``- user: name=bob home={{ bobs_home|default(omit) }}``)" - -#: ../../rst/reference_appendices/special_variables.rst:116 -msgid "play_hosts" -msgstr "play_hosts" - -#: ../../rst/reference_appendices/special_variables.rst:116 -msgid "Deprecated, the same as ansible_play_batch" -msgstr "非推奨。ansible_play_batch と同じです。" - -#: ../../rst/reference_appendices/special_variables.rst:119 -msgid "ansible_play_name" -msgstr "ansible_play_name" - -#: ../../rst/reference_appendices/special_variables.rst:119 -msgid "The name of the currently executed play. Added in ``2.8``. (`name` attribute of the play, not file name of the playbook.)" -msgstr "現在実行されたプレイの名前です。``2.8`` で追加されました (Playbook のファイル名ではなく、プレイの `name` 属性)。" - -#: ../../rst/reference_appendices/special_variables.rst:122 -msgid "The path to the directory of the current playbook being executed. NOTE: This might be different than directory of the playbook passed to the ``ansible-playbook`` command line when a playbook contains a ``import_playbook`` statement." -msgstr "実行中の現在の Playbook のディレクトリーへのパス。注記: これは、Playbook に ``import_playbook`` のステートメントが含まれる場合には、``ansible-playbook`` のコマンドラインで渡される Playbook のディレクトリーとは異なる場合があります。" - -#: ../../rst/reference_appendices/special_variables.rst:125 -msgid "role_name" -msgstr "role_name" - -#: ../../rst/reference_appendices/special_variables.rst:125 -msgid "The name of the role currently being executed." -msgstr "現在実行中のロール名。" - -#: ../../rst/reference_appendices/special_variables.rst:128 -msgid "role_names" -msgstr "role_names" - -#: ../../rst/reference_appendices/special_variables.rst:128 -msgid "Deprecated, the same as ansible_play_role_names" -msgstr "非推奨。ansible_play_role_names と同じです。" - -#: ../../rst/reference_appendices/special_variables.rst:131 -msgid "role_path" -msgstr "role_path" - -#: ../../rst/reference_appendices/special_variables.rst:131 -msgid "The path to the dir of the currently running role" -msgstr "現在実行中のロールのディレクトリーへのパス" - -#: ../../rst/reference_appendices/special_variables.rst:135 -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." -msgstr "これは、現在のホストに関連する情報を含む変数です (`inventory_hostname`)。この変数は、最初に収集した場合にのみ利用できます。詳細は、「:ref:`vars_and_facts`」を参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:138 -msgid "Contains any facts gathered or cached for the `inventory_hostname` Facts are normally gathered by the :ref:`setup ` module automatically in a play, but any module can return facts." -msgstr "`inventory_hostname` 向けに収集またはキャッシュしたファクトが含まれます。ファクトは通常、プレイで自動的に :ref:`setup ` モジュールにより収集されますが、どのモジュールでもファクトを返すことができます。" - -#: ../../rst/reference_appendices/special_variables.rst:144 -msgid "ansible_local" -msgstr "ansible_local" - -#: ../../rst/reference_appendices/special_variables.rst:142 -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 ` module and :ref:`local_facts` for more details." -msgstr "`inventory_hostname` が収集またはキャッシュする「ローカルファクト」が含まれます。利用可能なキーは、作成したカスタムファクトによって異なります。詳細は、:ref:`setup ` モジュールおよび :ref:`local_facts` モジュールを参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:149 -msgid "Connection variables" -msgstr "接続変数" - -#: ../../rst/reference_appendices/special_variables.rst:150 -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`, :ref:`command-line options`, and :ref:`playbook keywords`." -msgstr "接続変数は通常、ターゲットでのアクション実行方法を具体的に設定する時に使用します。接続変数の大半が connection プラグインに対応していますが、connection プラグイン固有のものではなく、通常は shell、terminal、become などの他のプラグインも使用します。各 connection/become/shell/etc プラグインは、自身のオーバーライドや固有の変数を定義するため、一般的なもののみを説明します。接続変数が :ref:`構成設定`、:ref:`コマンドラインオプション`、および :ref:`Playbook キーワード` と相互作用する方法は、「:ref:`general_precedence_rules`」を参照してください。" - -#: ../../rst/reference_appendices/special_variables.rst:155 -msgid "ansible_become_user" -msgstr "ansible_become_user" - -#: ../../rst/reference_appendices/special_variables.rst:155 -msgid "The user Ansible 'becomes' after using privilege escalation. This must be available to the 'login user'." -msgstr "特権昇格後に Ansible がなる (become) ユーザー。このユーザーは、「ログインユーザー」が利用できるようになっている必要があります。" - -#: ../../rst/reference_appendices/special_variables.rst:158 -msgid "ansible_connection" -msgstr "ansible_connection" - -#: ../../rst/reference_appendices/special_variables.rst:158 -msgid "The connection plugin actually used for the task on the target host." -msgstr "ターゲットホストでタスクに実際に使用する connection プラグイン" - -#: ../../rst/reference_appendices/special_variables.rst:161 -msgid "ansible_host" -msgstr "ansible_host" - -#: ../../rst/reference_appendices/special_variables.rst:161 -msgid "The ip/name of the target host to use instead of `inventory_hostname`." -msgstr "`inventory_hostname` の代わりに使用するターゲットホストの ip/名前" - -#: ../../rst/reference_appendices/special_variables.rst:164 -msgid "ansible_python_interpreter" -msgstr "ansible_python_interpreter" - -#: ../../rst/reference_appendices/special_variables.rst:164 -msgid "The path to the Python executable Ansible should use on the target host." -msgstr "Ansible がターゲットホストで使用すべき Python 実行ファイルへのパス" - -#: ../../rst/reference_appendices/special_variables.rst:168 -msgid "ansible_user" -msgstr "ansible_user" - -#: ../../rst/reference_appendices/special_variables.rst:167 -msgid "The user Ansible 'logs in' as." -msgstr "Ansible がログインするユーザー" - -#: ../../rst/reference_appendices/test_strategies.rst:4 -msgid "Testing Strategies" -msgstr "ストラテジーのテスト" - -#: ../../rst/reference_appendices/test_strategies.rst:9 -msgid "Integrating Testing With Ansible Playbooks" -msgstr "Ansible Playbook とテストの統合" - -#: ../../rst/reference_appendices/test_strategies.rst:11 -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." -msgstr "「Ansible Playbook とテストを最適な方法で統合するにはどうしたらいいのか」との質問が多数寄せられます。統合のオプションは、多数あります。Ansible は実際には、「フェイルファースト (Fail fast)」の順番ベースのシステムとなるように設計されているため、Ansible Playbookに直接、テストを簡単に埋め込むことができます。本章では、インフラストラクチャーのテスト統合パターンについて触れ、適切にテストするための正しいレベルについても説明します。" - -#: ../../rst/reference_appendices/test_strategies.rst:15 -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." -msgstr "以下の章は、デプロイするアプリケーションをテストする方法を説明しており、開発時に Ansible モジュールをテストする方法は説明していません。Ansible のテスト方法は、開発のセクションで参照してください。" - -#: ../../rst/reference_appendices/test_strategies.rst:17 -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 used 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." -msgstr "開発のワークフローにテストをある程度組み込むことで、実稼働環境でコードを使用時に、慌てることが少なくなります。多くの場合は、実稼働環境でテストを活用して、更新の失敗が、インストール全体に移行されてしまうのを防ぐことができます。また、プッシュベースになっているため、ローカルホストやテストサーバーで手順を非常に簡単に実行することができます。Ansible は、多くのチェックを挿入できるため、アップグレードのワークフローを希望のレベルに調節できます。" - -#: ../../rst/reference_appendices/test_strategies.rst:22 -msgid "The Right Level of Testing" -msgstr "適切なレベルのテスト" - -#: ../../rst/reference_appendices/test_strategies.rst:24 -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." -msgstr "Ansible リソースは、任意の状態のモデルです。サービスの起動、パッケージのインストールなどのテストを行う必要はありません。Ansible は、上記の内容が True と宣言されていることを確認するシステムで、代わりに、以下の項目を Playbook にアサートします。" - -#: ../../rst/reference_appendices/test_strategies.rst:36 -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)." -msgstr "サービスが起動しない可能性があると思われる場合は、サービスの開始を要求するのが最善の方法です。サービスの開始に失敗した場合は、Ansible により随時指示がでます (これは、サービスが機能的なことを行っているかどうかと混同しないでください。これについては、後で詳しく説明します)。" - -#: ../../rst/reference_appendices/test_strategies.rst:43 -msgid "Check Mode As A Drift Test" -msgstr "ドリフトテストとしての check モード" - -#: ../../rst/reference_appendices/test_strategies.rst:45 -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." -msgstr "上記の設定では、Ansible の ``--check`` モードは、テストのレイヤーとしても使用できます。既存のシステムに対してデプロイメントの Playbook を実行する場合に ``--check`` フラグを `ansible` コマンドに使用すると、変更が加えられてシステムが適切な状態になっていると Ansible が判断しているかどうかをレポートします。" - -#: ../../rst/reference_appendices/test_strategies.rst:49 -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:" -msgstr "このレポートにより、特定のシステムにデプロイメントが必要かどうかを事前に把握できます。check モードでは、一般的なスクリプトやコマンドは実行されないため、スクリプトモジュールへの呼び出しなど、``--check`` フラグが使用されていても通常モードで特定の手順を実行する場合は、このようなタスクのチェックモードを無効にしてください::" - -#: ../../rst/reference_appendices/test_strategies.rst:63 -msgid "Modules That Are Useful for Testing" -msgstr "テストに便利なモジュール" - -#: ../../rst/reference_appendices/test_strategies.rst:65 -msgid "Certain playbook modules are particularly good for testing. Below is an example that ensures a port is open:" -msgstr "Playbook のモジュールでは、特にテストに適しているものもあります。以下の例は、ポートが開放されていることを確認します。" - -#: ../../rst/reference_appendices/test_strategies.rst:76 -msgid "Here's an example of using the URI module to make sure a web service returns:" -msgstr "以下の例は、URI モジュールを使用して、Web サービスが返されることを確認します。" - -#: ../../rst/reference_appendices/test_strategies.rst:89 -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:" -msgstr "リモートホストで任意のスクリプト (言語は問わない) が簡単にプッシュされるため、ゼロ以外のリターンコードが指定されていると、スクリプトは自動的に失敗します。" - -#: ../../rst/reference_appendices/test_strategies.rst:98 -msgid "If using roles (you should be, roles are great!), scripts pushed by the script module can live in the 'files/' directory of a role." -msgstr "ロールを使用する場合 (ロールは便利なので使用を推奨)、スクリプトモジュールがプッシュするスクリプトは、ロールの「files/」ディレクトリーに配置されます。" - -#: ../../rst/reference_appendices/test_strategies.rst:100 -msgid "And the assert module makes it very easy to validate various kinds of truth:" -msgstr "また、アサートモジュールを使用すると、さまざまな真偽の検証が非常に簡単にできます。" - -#: ../../rst/reference_appendices/test_strategies.rst:114 -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:" -msgstr "Ansible 設定で設定が宣言されていないファイルの存在をテストする必要がある場合は、「stat」モジュールが最適です。" - -#: ../../rst/reference_appendices/test_strategies.rst:129 -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." -msgstr "上記のように、コマンドのリターンコードなどをチェックする必要はありません。Ansible がこのようなコードを自動的にチェックします。ユーザーの存在をチェックする代わりに、ユーザーモジュールを使用してユーザーを存在させます。" - -#: ../../rst/reference_appendices/test_strategies.rst:132 -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." -msgstr "Ansible はフェイルファーストシステムであるため、ユーザーの作成時にエラーがあると、Playbook の実行が停止します。バックグラウンドで行われている内容を確認する必要はありません。" - -#: ../../rst/reference_appendices/test_strategies.rst:136 -msgid "Testing Lifecycle" -msgstr "ライフサイクルのテスト" - -#: ../../rst/reference_appendices/test_strategies.rst:138 -msgid "If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy." -msgstr "アプリケーションの基本検証を Playbook に記述すると、デプロイ時に必ずこの検証が実行されます。" - -#: ../../rst/reference_appendices/test_strategies.rst:140 -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." -msgstr "そのため、ローカルの開発仮想マシンやステージ環境にデプロイするといずれも、実稼働でのデプロイの前に計画通りに作業が進んでいるかどうかを検証します。" - -#: ../../rst/reference_appendices/test_strategies.rst:143 -msgid "Your workflow may be something like this:" -msgstr "ワークフローは、次のようになります。" - -#: ../../rst/reference_appendices/test_strategies.rst:152 -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 に組み込まれているものではありません。" - -#: ../../rst/reference_appendices/test_strategies.rst:155 -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." -msgstr "ただし、いくつかの基本的なヘルスチェックを Playbook に追加すると便利です。場合によっては、リモートノードに対して QA バッテリーのサブセットを実行することもできます。この点については、次のセクションで説明します。" - -#: ../../rst/reference_appendices/test_strategies.rst:159 -msgid "Integrating Testing With Rolling Updates" -msgstr "ローリングアップデートへのテストの統合" - -#: ../../rst/reference_appendices/test_strategies.rst:161 -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." -msgstr ":ref:`playbooks_delegation` を読むと、ローリングアップデートのパターンを拡張でき、また、Playbook 実行の成否でロードバランサーにマシンを 1 台追加するかどうかを決定できることが即座に明確になったことでしょう。" - -#: ../../rst/reference_appendices/test_strategies.rst:164 -msgid "This is the great culmination of embedded tests:" -msgstr "これは、組み込みテストの集大成です。" - -#: ../../rst/reference_appendices/test_strategies.rst:200 -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." -msgstr "上記では当然、「プールから取得する」手順や「追加し直す」手順は、Ansible のロードバランサーモジュールや、適切な shell コマンドの呼び出しに置き換えられます。また、マシンのサービス停止期間を開始/終了するモニタリングモジュールを使用する手順なども含まれている場合がありますが、" - -#: ../../rst/reference_appendices/test_strategies.rst:204 -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." -msgstr "上記で分かるように、テストはゲートとして使用されています。つまり、「apply_testing_checks」の手順が実行されない場合は、マシンがプールに戻らないようになっています。" - -#: ../../rst/reference_appendices/test_strategies.rst:207 -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." -msgstr "ローリングアップデートの続行を妨げるテストの失敗回数を制御できます。この点については、「max_fail_percentage」向けの章を参照してください。" - -#: ../../rst/reference_appendices/test_strategies.rst:210 -msgid "This above approach can also be modified to run a step from a testing machine remotely against a machine:" -msgstr "上記のアプローチを変更して、マシンに対してリモートのテストマシンから手順を実行することも可能です。" - -#: ../../rst/reference_appendices/test_strategies.rst:240 -msgid "In the above example, a script is run from the testing server against a remote node prior to bringing it back into the pool." -msgstr "上記の例では、プールにマシンを戻す前に、リモートのノードに対してテストサーバーからスクリプトを実行します。" - -#: ../../rst/reference_appendices/test_strategies.rst:243 -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." -msgstr "問題が発生した場合には、Ansible が自動で生成した再試行ファイルを使用して、失敗したサーバー数台を修正し、そのサーバーだけにデプロイメントを繰り返し実行します。" - -#: ../../rst/reference_appendices/test_strategies.rst:247 -msgid "Achieving Continuous Deployment" -msgstr "継続的なデプロイメントの実現" - -#: ../../rst/reference_appendices/test_strategies.rst:249 -msgid "If desired, the above techniques may be extended to enable continuous deployment practices." -msgstr "任意で、上記の手法を拡張して、継続してデプロイメントができるようにします。" - -#: ../../rst/reference_appendices/test_strategies.rst:251 -msgid "The workflow may look like this:" -msgstr "ワークフローは、次のようになります。" - -#: ../../rst/reference_appendices/test_strategies.rst:260 -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." -msgstr "Ansible ユーザーによっては、上記のアプローチを使用して、すべてのインフラストラクチャーをオフラインにすることなく、1 時間に 6 回、または 12 回デプロイしています。このレベルに到達するには、自動化 QA の文化が必要不可欠です。" - -#: ../../rst/reference_appendices/test_strategies.rst:263 -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'." -msgstr "大量の QA を手動で続けている場合には、手動でデプロイするべきかどうか決定する必要がありますが、前項のようにローリングアップデートのパターンを使用して作業をし、「script」、「stat」、「uri」、「assert」などのモジュールで基本的なヘルスチェックを組み込むだけでも役立つ場合があります。" - -#: ../../rst/reference_appendices/test_strategies.rst:268 -msgid "Conclusion" -msgstr "まとめ" - -#: ../../rst/reference_appendices/test_strategies.rst:270 -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." -msgstr "Ansible では、インフラストラクチャーの基本的な内容が正しいかを検証するフレームワークを別に用意する必要はないと考えます。これは、Ansible は順序ベースのシステムで、ホストに未処理のエラーがあると即座に失敗し、そのホストの設定がこれ以上進まないようにします。こうすることで、エラーが表面化し、Ansible の実行の最後にまとめとして、エラーが表示されます。" - -#: ../../rst/reference_appendices/test_strategies.rst:274 -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." -msgstr "ただし、Ansible は、複数階層のオーケストレーションシステムとして設計されているため、非常に簡単にタスクまたはロールを使用して Playbook 実行の最後にテストを組み込むことができます。ローリングアップデートで使用する場合は、テストの手順で、ロードバランサーのプールにマシンを戻すかどうかを判断できます。" - -#: ../../rst/reference_appendices/test_strategies.rst:278 -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." -msgstr "最後に、Ansible のエラーは、Ansible のプログラム自体のリターンコードにまで伝搬され、また Ansible はデフォルトで簡単なプッシュベースモードで実行されるため、上記のセクションで説明されているように、これを使用して継続的な統合/継続的なデリバリーパイプラインの一部としてシステムを展開する場合に Ansible をビルド環境に活用すると大きな一歩になります。" - -#: ../../rst/reference_appendices/test_strategies.rst:282 -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." -msgstr "インフラストラクチャーテストではなく、アプリケーションのテストに焦点を当てるため、QA チームと連携して、どのようなテストを、開発仮想マシンのデプロイメント時に毎回実行すると便利か、またデプロイメント時に毎回、ステージ環境にどのようなテストを実行するかを確認してください。明らかに、開発段階では、ユニットテストも素晴らしいですが、Playbook をユニットテストにはしないでください。Ansible はリソースの状態を宣言的に記述するため、その必要はありません。ただし、何かを確認したい場合は、stat/assert のようなモジュールを使用すると良いでしょう。" - -#: ../../rst/reference_appendices/test_strategies.rst:288 -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." -msgstr "結局、テストは非常に組織的で、サイト固有の内容となっています。テストは必ず行うべきですが、貴社の環境に最も有用なテストは、デプロイメントの内容や、誰が使用するかにより異なります。しかし、誰もが、強力で信頼性の高いデプロイメントシステムから恩恵を受けることができます。" - -#: ../../rst/reference_appendices/test_strategies.rst:298 -msgid ":ref:`playbooks_delegation`" -msgstr ":ref:`playbooks_delegation`" - -#: ../../rst/reference_appendices/test_strategies.rst:299 -msgid "Delegation, useful for working with load balancers, clouds, and locally executed steps." -msgstr "委譲 (ロードバランサー、クラウド、およびローカルで実行した手順を使用する際に役に立ちます)" - -#: ../../rst/reference_appendices/tower.rst:4 -msgid "Red Hat Ansible Automation Platform" -msgstr "Red Hat Ansible Automation Platform" - -#: ../../rst/reference_appendices/tower.rst:8 -msgid "Red Hat Ansible Automation Platform is available on multiple cloud platforms. See `Ansible on Clouds `_ for details." -msgstr "Red Hat Ansible Automation Platform は、複数のクラウドプラットフォームで利用できます。詳細は、`Ansible on Clouds `_ を参照してください。" - -#: ../../rst/reference_appendices/tower.rst:10 -msgid "`Red Hat Ansible Automation Platform `_ (RHAAP) is an integrated solution for operationalizing Ansible across your team, organization, and enterprise. The platform includes a controller with a web console and REST API, analytics, execution environments, and much more." -msgstr "`Red Hat Ansible Automation Platform `_(RHAAP)は、チーム、組織、企業全体で Ansible を操作する統合ソリューションです。このプラットフォームには、Web コンソールおよび REST API、解析、実行環境を備えたコントローラーが含まれます。" - -#: ../../rst/reference_appendices/tower.rst:12 -msgid "RHAAP gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model complex processes." -msgstr "RHAAP には、セキュアに保存されている SSH や他のサービスの認証情報の使用時に制御するなど、ロールベースのアクセス制御が含まれています。インベントリーは、幅広いクラウドソースと同期でき、強力な Playbook ワークフローを複数使用することで、複雑なプロセスをモデル化できます。" - -#: ../../rst/reference_appendices/tower.rst:14 -msgid "RHAAP 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 "RHAAP は、すべてのジョブをログ記録し、LDAP、SAML、他の認証ソースと統合の相性がよく、ブラウザーで使用可能な素晴らしい REST API が含まれます。また、Jenkins と簡単に統合できるように、コマンドラインも利用できます。" - -#: ../../rst/reference_appendices/tower.rst:16 -msgid "RHAAP incorporates the downstream Red Hat supported product version of Ansible AWX, the downstream Red Hat supported product version of Ansible Galaxy, and multiple SaaS offerings. Find out more about RHAAP features and on the `Red Hat Ansible Automation Platform webpage `_. A Red Hat Ansible Automation Platform subscription includes support from Red Hat, Inc." -msgstr "RHAAP は、Red Hat がサポートする Ansible AWX の製品バージョン、ダウンストリームの Red Hat がサポートする Ansible Galaxy の製品バージョン、および SaaS オファリングのダウンストリームが含まれています。RHAAP 機能の詳細は、`Red Hat Ansible Automation Platform webpage `_を参照してください。Red Hat Ansible Automation Platform サブスクリプションには、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." -#~ msgstr "" - -#~ msgid "-C -o ControlMaster=auto -o ControlPersist=60s" -#~ msgstr "" - -#~ msgid "[ssh_connection]" -#~ msgstr "" - -#~ msgid "ssh_args" -#~ msgstr "" - -#~ msgid ":envvar:`ANSIBLE_SSH_ARGS`" -#~ msgstr "" - -#~ msgid "ANSIBLE_SSH_CONTROL_PATH" -#~ 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 "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 `" -#~ 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 `" -#~ 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 `" -#~ 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 `" -#~ msgstr "" - -#~ msgid "See also :ref:`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 `" -#~ msgstr "" - -#~ msgid "See also :ref:`DEFAULT_SFTP_BATCH_MODE `" -#~ msgstr "" - -#~ msgid "See also :ref:`DEFAULT_SSH_TRANSFER_METHOD `" -#~ msgstr "" - -#~ msgid "`irc.freenode.net `_" -#~ msgstr "`irc.freenode.net `_" - -#~ msgid "True" -#~ msgstr "True" - -#~ msgid "ALLOW_WORLD_READABLE_TMPFILES" -#~ msgstr "ALLOW_WORLD_READABLE_TMPFILES" - -#~ 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." -#~ msgstr "これにより、マシンで作成された一時ファイルが誰でも読み取り可能になり、タスクが失敗する代わりに警告が表示されます。これは、権限のないユーザーに変わる (become) 場合に役立ちます。" - -#~ msgid "False" -#~ msgstr "False" - -#~ msgid "allow_world_readable_tmpfiles" -#~ msgstr "allow_world_readable_tmpfiles" - -#~ msgid "moved to a per plugin approach that is more flexible" -#~ msgstr "より柔軟なプラグインのアプローチへ移行" - -#~ msgid "mostly the same config will work, but now controlled from the plugin itself and not using the general constant." -#~ msgstr "ほとんどの同じ設定は機能しますが、プラグイン自体から制御され、一般的な定数は使用しません。" - -#~ msgid "None" -#~ msgstr "なし" - -#~ msgid "CALLABLE_ACCEPT_LIST" -#~ msgstr "CALLABLE_ACCEPT_LIST" - -#~ msgid "Whitelist of callable methods to be made available to template evaluation" -#~ msgstr "テンプレート評価で利用できる呼び出し可能なメソッドのホワイトリスト" - -#~ msgid "[]" -#~ msgstr "[]" - -#~ msgid "callable_whitelist" -#~ msgstr "callable_whitelist" - -#~ msgid "callable_enabled" -#~ msgstr "callable_enabled" - -#~ msgid ":envvar:`ANSIBLE_CALLABLE_ENABLED`" -#~ msgstr ":envvar:`ANSIBLE_CALLABLE_ENABLED`" - -#~ msgid ":envvar:`ANSIBLE_CALLABLE_WHITELIST`" -#~ msgstr ":envvar:`ANSIBLE_CALLABLE_WHITELIST`" - -#~ msgid "ANSIBLE_CALLABLE_ENABLED" -#~ msgstr "ANSIBLE_CALLABLE_ENABLED" - -#~ msgid "callback_enabled" -#~ msgstr "callback_enabled" - -#~ 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." -#~ msgstr "(コレクションメタデータキー `requires_ansible` を介して) 実行中の Ansible バージョンをサポートしないコレクションが読み込まれると、デフォルトの動作では、警告を表示してとにかく続行します。この値を `ignore` に設定すると警告を完全に飛ばします。`fatal` に設定すると、Ansible の実行をすぐに停止します。" - -#~ msgid "COMMAND_WARNINGS" -#~ msgstr "COMMAND_WARNINGS" - -#~ 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." -#~ msgstr "Ansible は、シェルまたはコマンドモジュールが使用され、コマンドが既存の Ansible モジュールと類似しているように見えます。これらの設定を False に設定することで、これらの警告を非表示にすることができます。また、モジュールのオプション ``warn`` を使用してタスクレベルで制御することもできます。バージョン 2.11 の時点で、これはデフォルトでは無効になっています。" - -#~ msgid "command_warnings" -#~ msgstr "command_warnings" - -#~ msgid ":envvar:`ANSIBLE_COMMAND_WARNINGS`" -#~ msgstr ":envvar:`ANSIBLE_COMMAND_WARNINGS`" - -#~ msgid "the command warnings feature is being removed" -#~ msgstr "コマンド警告機能が削除されています。" - -#~ msgid "CONDITIONAL_BARE_VARS" -#~ msgstr "CONDITIONAL_BARE_VARS" - -#~ 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" -#~ msgstr "この設定を (True) にすると、条件付き評価「var」の実行は「var.subkey」とは異なる方法で処理されます。最初の評価は直接評価され、2 番目の評価は Jinja2 パーサーを通過するためです。ただし、「var」の「false」文字列はブール値として評価されます。この設定をオフにすると、どちらも同じように評価されますが、「var」が「false」(文字列) の場合は、ブール値として評価されなくなります。現在、この設定のデフォルトは「True」ですが、まもなく「False」に変更され、将来のバージョンで設定自体が削除されます。この設定は、2.12 以降で最終的に非推奨になると予想されます。" - -#~ msgid "conditional_bare_variables" -#~ msgstr "conditional_bare_variables" - -#~ msgid ":envvar:`ANSIBLE_CONDITIONAL_BARE_VARS`" -#~ msgstr ":envvar:`ANSIBLE_CONDITIONAL_BARE_VARS`" - -#~ msgid "connection_facts_modules" -#~ msgstr "connection_facts_modules" - -#~ msgid ":envvar:`ANSIBLE_CONNECTION_FACTS_MODULES`" -#~ msgstr ":envvar:`ANSIBLE_CONNECTION_FACTS_MODULES`" - -#~ msgid "CONTROLLER_PYTHON_WARNING" -#~ msgstr "CONTROLLER_PYTHON_WARNING" - -#~ msgid "controller_python_warning" -#~ msgstr "controller_python_warning" - -#~ msgid ":envvar:`ANSIBLE_CONTROLLER_PYTHON_WARNING`" -#~ msgstr ":envvar:`ANSIBLE_CONTROLLER_PYTHON_WARNING`" - -#~ 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." -#~ msgstr "このオプションを使用すると、ファクト収集を使用するときに、暗黙の M(ansible.builtin.setup) タスクの「local_facts」のカスタムパスをグローバルに設定できます。設定されていない場合は、M(ansible.builtin.setup) モジュールからデフォルトにフォールバックします (``/etc/ansible/facts.d``)。これは、M(ansible.builtin.setup) モジュールを使用するユーザー定義のタスクには **影響しません**。" - -#~ msgid "5" -#~ msgstr "5" - -#~ 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." -#~ msgstr "暗黙的なファクト収集の M(ansible.builtin.setup) タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#~ msgid "['all']" -#~ msgstr "['all']" - -#~ msgid "Set the timeout in seconds for the implicit fact gathering. It does **not** apply to user defined M(ansible.builtin.setup) tasks." -#~ msgstr "暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#~ msgid "10" -#~ msgstr "10" - -#~ 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." -#~ msgstr "この設定は、ファクト収集 (リモートシステムに関して検出されたファクト) のデフォルトポリシーを制御します。「implicit」(デフォルト) の場合、cache プラグインは無視され、「gather_facts: False」が設定されていない限り、プレイごとにファクトが収集されます。「explicit」の場合はその逆で、プレイ中に直接要求されない限り、ファクトは収集されません。「smart」の値は、検出されたファクトを持たない各新規ホストがスキャンされることを意味しますが、同じホストが複数のプレイで扱われた場合は、Playbook の実行中に再び接触することはありません。このオプションは、ファクト収集の時間を短縮したい場合に便利です。「smart」と「explicit」の両方とも、cache プラグインを使用します。" - -#~ msgid "DEFAULT_HANDLER_INCLUDES_STATIC" -#~ msgstr "DEFAULT_HANDLER_INCLUDES_STATIC" - -#~ 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'." -#~ msgstr "2.0 M(ansible.builtin.include) は「動的」である可能性があるため、この設定 (True の場合) は、``handlers`` セクションに表示されるインクルードが「静的」になります。" - -#~ msgid "handler_includes_static" -#~ msgstr "handler_includes_static" - -#~ msgid ":envvar:`ANSIBLE_HANDLER_INCLUDES_STATIC`" -#~ msgstr ":envvar:`ANSIBLE_HANDLER_INCLUDES_STATIC`" - -#~ msgid "include itself is deprecated and this setting will not matter in the future" -#~ msgstr "インクルード自体は非推奨であるため、この設定は今後重要ではありません。" - -#~ msgid "none as its already built into the decision between include_tasks and import_tasks" -#~ msgstr "include_tasks と import_tasks の決定にすでに組み込まれてるため、none です。" - -#~ msgid ":envvar:`LIBVIRT_LXC_NOSECLABEL`" -#~ msgstr ":envvar:`LIBVIRT_LXC_NOSECLABEL`" - -#~ msgid "environment variables without ``ANSIBLE_`` prefix are deprecated" -#~ msgstr "``ANSIBLE_`` 接頭辞のない環境変数が非推奨になりました。" - -#~ msgid "the ``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` environment variable" -#~ msgstr "``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` 環境変数" - -#~ msgid "~/.ansible/tmp" -#~ msgstr "~/.ansible/tmp" - -#~ msgid "Ansible managed" -#~ msgstr "Ansible が管理" - -#~ msgid "ZIP_DEFLATED" -#~ msgstr "ZIP_DEFLATED" - -#~ msgid "15" -#~ msgstr "15" - -#~ 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." -#~ msgstr "Ansible 出力の表示に使用されるメインのコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、stdout に使用できるのは 1 つだけです。" - -#~ msgid "LOG_USER" -#~ msgstr "LOG_USER" - -#~ msgid "DEFAULT_TASK_INCLUDES_STATIC" -#~ msgstr "DEFAULT_TASK_INCLUDES_STATIC" - -#~ 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." -#~ msgstr "`include` タスクは静的または動的にすることができます。これは、自動検出が失敗し、タスクに自動検出が明示的に設定されていない場合に、デフォルトの想定される動作を切り替えます。" - -#~ msgid "task_includes_static" -#~ msgstr "task_includes_static" - -#~ msgid ":envvar:`ANSIBLE_TASK_INCLUDES_STATIC`" -#~ msgstr ":envvar:`ANSIBLE_TASK_INCLUDES_STATIC`" - -#~ msgid "None, as its already built into the decision between include_tasks and import_tasks" -#~ msgstr "include_tasks と import_tasks の決定にすでに組み込まれてるため、none です。" - -#~ msgid "0" -#~ msgstr "0" - -#~ msgid "3" -#~ msgstr "3" - -#~ msgid ":envvar:`DISPLAY_SKIPPED_HOSTS`" -#~ msgstr ":envvar:`DISPLAY_SKIPPED_HOSTS`" - -#~ msgid "the ``ANSIBLE_DISPLAY_SKIPPED_HOSTS`` environment variable" -#~ msgstr "``ANSIBLE_DISPLAY_SKIPPED_HOSTS`` 環境変数" - -#~ msgid "Which modules to run during a play's fact gathering stage, using the default of 'smart' will try to figure it out based on connection type." -#~ msgstr "プレイのファクト収集段階で実行するモジュールは、デフォルトの「smart」を使用すると接続タイプに基づいて確認を試みます。" - -#~ 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." -#~ msgstr "リモートターゲットまたは自動検出モードでのモジュール実行に使用される Python インタープリターへのパス。サポートされている検出モードは、``auto``、``auto_silent``、および ``auto_legacy`` (デフォルト) です。すべての検出モードは、含まれているシステムの Python (含むことがディストリビューションで) を使用するためにルックアップテーブルを使用し、プラットフォーム固有のデフォルトが使用できない場合は、よく知られた Python インタープリターの位置の固定された順序リストにフォールバックします。フォールバック動作では、インタープリターを明示的に設定する必要があるという警告が出力されます (後からインストールされたインタープリターが、使用するインタープリターを変更する可能性があるからです)。この警告動作を無効にするには、``auto_silent`` を設定します。``auto_legacy`` のデフォルト値はすべて同じ動作を提供しますが、以前の Ansible リリースとの下位互換性のために、常にデフォルトで ``/usr/bin/python`` に設定されていた場合、存在する場合はそのインタープリターを使用します (デフォルトの動作が将来の Ansible リリースの ``auto`` の動作に変更することを示す警告を表示します)。" - -#~ msgid "INTERPRETER_PYTHON_DISTRO_MAP" -#~ msgstr "INTERPRETER_PYTHON_DISTRO_MAP" - -#~ msgid "{'centos': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'debian': {'10': '/usr/bin/python3'}, 'fedora': {'23': '/usr/bin/python3'}, 'oracle': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'redhat': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'rhel': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'ubuntu': {'14': '/usr/bin/python', '16': '/usr/bin/python3'}}" -#~ msgstr "{'centos': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'debian': {'10': '/usr/bin/python3'}, 'fedora': {'23': '/usr/bin/python3'}, 'oracle': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'redhat': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'rhel': {'6': '/usr/bin/python', '8': '/usr/libexec/platform-python'}, 'ubuntu': {'14': '/usr/bin/python', '16': '/usr/bin/python3'}}" - -#~ msgid "Toggle to turn on inventory caching" -#~ msgstr "インベントリーキャッシュを有効に切り替えます。" - -#~ msgid "The plugin for caching inventory. If INVENTORY_CACHE_PLUGIN is not provided CACHE_PLUGIN can be used instead." -#~ msgstr "インベントリーのキャッシュ用のプラグイン。INVENTORY_CACHE_PLUGIN が指定されていない場合は、CACHE_PLUGIN を代わりに使用できます。" - -#~ msgid "The inventory cache connection. If INVENTORY_CACHE_PLUGIN_CONNECTION is not provided CACHE_PLUGIN_CONNECTION can be used instead." -#~ msgstr "インベントリーキャッシュ接続。INVENTORY_CACHE_PLUGIN_CONNECTION が指定されていない場合は、代わりに CACHE_PLUGIN_CONNECTION を使用できます。" - -#~ msgid "The table prefix for the cache plugin. If INVENTORY_CACHE_PLUGIN_PREFIX is not provided CACHE_PLUGIN_PREFIX can be used instead." -#~ msgstr "cache プラグインのテーブル接頭辞。INVENTORY_CACHE_PLUGIN_PREFIX が指定されていない場合は、代わりに CACHE_PLUGIN_PREFIX を使用できます。" - -#~ msgid "Expiration timeout for the inventory cache plugin data. If INVENTORY_CACHE_TIMEOUT is not provided CACHE_TIMEOUT can be used instead." -#~ msgstr "inventory cache プラグインデータの有効期限のタイムアウト。INVENTORY_CACHE_TIMEOUT が指定されていない場合は、代わりに CACHE_TIMEOUT を使用できます。" - -#~ msgid ":envvar:`NETWORK_GROUP_MODULES`" -#~ msgstr ":envvar:`NETWORK_GROUP_MODULES`" - -#~ msgid "the ``ANSIBLE_NETWORK_GROUP_MODULES`` environment variable" -#~ msgstr "``ANSIBLE_NETWORK_GROUP_MODULES`` 環境変数" - -#~ msgid "30" -#~ msgstr "30" - -#~ 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." -#~ msgstr "これにより、vars プラグインを処理するためのルートとして使用される Playbook ディレクトリーが設定されます。これには、host_vars/group_vars の検索が含まれます。``top`` オプションは、チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。``bottom`` オプションは、現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。``all`` オプションは、最初の親から現在の Playbook までを調べます。" - -#~ msgid "[default]" -#~ msgstr "[default]" - -#~ msgid "specifying \"plugin_filters_cfg\" under the \"default\" section is deprecated" -#~ msgstr "「default」セクションに「plugin_filters_cfg」を指定することが非推奨になりました。" - -#~ msgid "the \"defaults\" section instead" -#~ msgstr "代わりに「default」セクションが使用されます。" - -#~ 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." -#~ msgstr "この設定は、ユーザーのインベントリーサイズとプレイの選択に応じて vars_plugin の使用を最適化するために使用できます。C(demand) に設定すると、タスクによって変数が「要求」されるたびに、インベントリーソースに関連して vars_plugins が実行されます。C(start) に設定すると、インベントリーソースをインポートした後、インベントリーソースに関連して vars_plugins が実行されます。" - -#~ 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." -#~ msgstr "インベントリーソースから提供されたグループ名の無効な文字を Ansible が変換します。「never」の場合、グループ名は許可されますが、問題について警告されます。「ignore」の場合は、警告を出力せずに「never」と同じように動作します。「always」の場合は、無効な文字を「_」(アンダースコア) に置き換えてユーザーに警告します。「silently」の場合は、警告を発行せずに「always」と同じように動作します。" - -#~ 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" -#~ msgstr "この設定を (True) にすると、条件付き評価「var」の実行は「var.subkey」とは異なる方法で処理されます。最初の評価は直接評価され、2 番目の評価は Jinja2 パーサーを通過するためです。ただし、「var」の「false」文字列はブール値として評価されます。この設定をオフにすると、どちらも同じように評価されますが、「var」が「false」(文字列) の場合は、ブール値として評価されなくなります。現在、この設定のデフォルトは「True」ですが、まもなく「False」に変更され、将来のバージョンで設定自体が削除されます。この設定は、2.12 以降で最終的に非推奨になると予想されます。" - -#~ msgid "See also :ref:`CONDITIONAL_BARE_VARS `" -#~ msgstr "「:ref:`CONDITIONAL_BARE_VARS `」も参照してください。" - -#~ 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." -#~ msgstr "Ansible は、シェルまたはコマンドモジュールが使用され、コマンドが既存の Ansible モジュールと類似しているように見えます。これらの設定を False に設定することで、これらの警告を非表示にすることができます。また、モジュールのオプション ``warn`` を使用してタスクレベルで制御することもできます。バージョン 2.11 の時点で、これはデフォルトでは無効になっています。" - -#~ msgid "See also :ref:`COMMAND_WARNINGS `" -#~ msgstr "「:ref:`COMMAND_WARNINGS `」も参照してください。" - -#~ msgid "See also :ref:`CALLABLE_ACCEPT_LIST `" -#~ msgstr "「:ref:`CALLABLE_ACCEPT_LIST `」も参照してください。" - -#~ msgid "See also :ref:`CONTROLLER_PYTHON_WARNING `" -#~ msgstr "「:ref:`CONTROLLER_PYTHON_WARNING `」も参照してください。" - -#~ 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." -#~ msgstr "このオプションを使用すると、ファクト収集を使用するときに、暗黙の M(ansible.builtin.setup) タスクの「local_facts」のカスタムパスをグローバルに設定できます。設定されていない場合は、M(ansible.builtin.setup) モジュールからデフォルトにフォールバックします (``/etc/ansible/facts.d``)。これは、M(ansible.builtin.setup) モジュールを使用するユーザー定義のタスクには **影響しません**。" - -#~ 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." -#~ msgstr "この設定は、ファクト収集 (リモートシステムに関して検出されたファクト) のデフォルトポリシーを制御します。「implicit」(デフォルト) の場合、cache プラグインは無視され、「gather_facts: False」が設定されていない限り、プレイごとにファクトが収集されます。「explicit」の場合はその逆で、プレイ中に直接要求されない限り、ファクトは収集されません。「smart」の値は、検出されたファクトを持たない各新規ホストがスキャンされることを意味しますが、同じホストが複数のプレイで扱われた場合は、Playbook の実行中に再び接触することはありません。このオプションは、ファクト収集の時間を短縮したい場合に便利です。「smart」と「explicit」の両方とも、cache プラグインを使用します。" - -#~ 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." -#~ msgstr "暗黙的なファクト収集の M(ansible.builtin.setup) タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。" - -#~ msgid "See also :ref:`DEFAULT_HANDLER_INCLUDES_STATIC `" -#~ msgstr "「:ref:`DEFAULT_HANDLER_INCLUDES_STATIC `」も参照してください。" - -#~ 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." -#~ msgstr "Ansible 出力の表示に使用されるメインコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、標準出力 (stdout) に使用できるのは 1 つだけです。" - -#~ msgid "See also :ref:`DEFAULT_TASK_INCLUDES_STATIC `" -#~ msgstr "「:ref:`DEFAULT_TASK_INCLUDES_STATIC `」も参照してください。" - -#~ msgid "See also :ref:`CONNECTION_FACTS_MODULES `" -#~ msgstr "「:ref:`CONNECTION_FACTS_MODULES `」も参照してください。" - -#~ 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." -#~ msgstr "インベントリーソースから提供されたグループ名の無効な文字を Ansible が変換します。「never」の場合、グループ名は許可されますが、問題について警告されます。「ignore」の場合は、警告を出力せずに「never」と同じように動作します。「always」の場合は、無効な文字を「_」(アンダースコア) に置き換えてユーザーに警告します。「silently」の場合は、警告を出力しませんが「always」と同じように動作します。" - -#~ 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." -#~ msgstr "これにより、vars プラグインを処理するためのルートとして使用される Playbook ディレクトリーが設定されます。これには、host_vars/group_vars の検索が含まれます。``top`` オプションは、チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。``bottom`` オプションは、現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。``all`` オプションは、最初の親から現在の Playbook までを調べます。" - -#~ 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." -#~ msgstr "この設定は、ユーザーのインベントリーサイズとプレイの選択に応じて vars_plugin の使用を最適化するために使用できます。C(demand) に設定すると、タスクによって変数が「要求」されるたびに、インベントリーソースに関連して vars_plugins が実行されます。C(start) に設定すると、インベントリーソースをインポートした後、インベントリーソースに関連して vars_plugins が実行されます。" - -#~ msgid "Yes! Ansible, Inc makes a great product that makes Ansible even more powerful and easy to use. See :ref:`ansible_tower`." -#~ msgstr "Ansible, Inc は、Ansible がより強力で使いやすくなるように、優れた製品を提供しています。「:ref:`ansible_tower`」を参照してください。" - -#~ msgid "Why don't you ship ansible in wheel format (or other packaging format) ?" -#~ msgstr "wheel 形式 (またはその他のパッケージ形式) で ansible が同梱されないのはなぜですか。" - -#~ 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." -#~ msgstr "多くの場合に、メンテナンスができるかどうかに関係します。ソフトウェアを提供する方法は多数あり、全プラットフォームで Ansible をリリースするリソースがありません。場合によっては、技術的な問題があります。たとえば、Python Wheel には依存関係がありません。" - -#~ msgid "Please see the section below for a link to IRC and the Google Group, where you can ask your question there." -#~ msgstr "以下のセクションに、IRC および Google グループへのリンクがあります。こちらから、質問をしてください。" - -#~ msgid "New for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. 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." -#~ msgstr "2.10 の新機能。`ansible/ansible リポジトリー `_ から生成されるインストール可能なパッケージ (RPM/Python/Deb パッケージ)。コマンドラインツールと、基本的な機能と関数 (モジュールコードの管理対象ノードへのコピーなど) のコードが含まれています。``ansible-base`` パッケージにはいくつかのモジュールとプラグインが含まれており、コレクションをインストールすることで他のモジュールを追加できます。" - -#~ msgid "Handlers are just like regular tasks in an Ansible :term:`playbook ` (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." -#~ msgstr "ハンドラーは Ansible :term:`playbook ` の通常のタスクのような機能を持ちます(「:term:`タスク`」を参照) が、タスクに ``notify`` ディレクティブがあり、変更があったことが示唆される場合にのみ実行されます。たとえば、設定ファイルが変更された後に、設定ファイルを参照するテンプレート作成操作のタスクは、サービス再起動ハンドラーに通知する可能性があります。これは、サービスが再起動する必要がある場合にのみバウンスできることを意味します。ハンドラーはサービスの再起動以外のタスクに使用できますが、サービスの再起動が最も一般的な使用例になります。" - -#~ msgid "A local_action directive in a :term:`playbook ` 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." -#~ msgstr "リモートマシンを対象とした :term:`playbook ` の local_action ディレクティブは、指定した手順が実際にはローカルマシン上で実行されるが、そのステップで参照されるリモートホスト名を参照するために変数 ``{{ ansible_hostname }}`` を渡すことができることを意味します。これを利用して、たとえば rsync の操作を行うことができます。" - -#~ msgid "By using ``connection: local`` in a :term:`playbook `, or passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates that we are managing the local host and not a remote machine." -#~ msgstr ":term:`playbook ` で ``connection: local`` を使用するか、``-c local`` を :command:`/usr/bin/ansible` に渡した場合は、リモートホストではなくローカルホストを管理していることを示しています。" - -#~ msgid "To save Ansible output to a secure database, use :ref:`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 ` を使用します。Tower を使用すると、グラフや REST API を使用して、ホスト、プロジェクト、および特定のインベントリーに基づいて履歴を確認できます。" - -#~ msgid ":ref:`rolling_update_batch_size`" -#~ msgstr ":ref:`rolling_update_batch_size`" - -#~ msgid ":ref:`loop_control`" -#~ msgstr ":ref:`loop_control`" - -#~ msgid "This section describes the Ansible and ``ansible-core`` releases. Ansible is the package that most users install. ``ansible-core`` is primarily for developers." -#~ msgstr "本セクションでは、Ansible および ``ansible-core`` リリースを説明します。Ansible は、ほとんどのユーザーがインストールするパッケージです。``ansible-core`` は主に開発者向けのものです。" - -#~ 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." -#~ msgstr "Ansibleは、柔軟なリリースサイクルで開発およびリリースされます。このサイクルは、大規模な変更を正しく実装して、テストしてから新しいリリースが公開されるように、延長することが可能です。今後のリリースの詳細については、「:ref:`roadmaps`」を参照してください。" - -#~ 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." -#~ msgstr "Ansible バージョン 2.10 以降では、メジャーリリースは 1 つのリリースサイクルで維持されます。次のリリースがなくなると (この例では 2.11)、古いリリース (この例では 2.10) は維持されなくなります。" - -#~ 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." -#~ msgstr "メンテナンスされていない Ansible のリリースを使用している場合には、最新の機能やセキュリティー修正からの恩恵を受けられるようにできるだけ早くアップグレードすることを強く推奨します。" - -#~ msgid "Older, unmaintained versions of Ansible can contain unfixed security vulnerabilities (*CVE*)." -#~ msgstr "メンテナンスのない、以前の Ansible バージョンには、未修正のセキュリティーの脆弱性が含まれている可能性があります (*CVE*)。" - -#~ msgid "Ansible Release" -#~ msgstr "Ansible リリース" - -#~ msgid "`2.10 Release Notes`_" -#~ msgstr "`2.10 リリースノート`_" - -#~ msgid "In development (2.10 alpha/beta)" -#~ msgstr "開発 (2.10 アルファ/ベータ)" - -#~ msgid "`2.9 Release Notes`_" -#~ msgstr "`2.9 リリースノート`_" - -#~ msgid "`2.8 Release Notes`_" -#~ msgstr "`2.8 リリースノート`_" - -#~ msgid "`2.7 Release Notes`_" -#~ msgstr "`2.7 リリースノート`_" - -#~ msgid "`2.6 Release Notes`_" -#~ msgstr "`2.6 リリースノート`_" - -#~ msgid "`2.5 Release Notes`_" -#~ msgstr "`2.5 リリースノート`_" - -#~ 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." -#~ msgstr "``ansible-core`` は、柔軟なリリースサイクルで開発およびリリースされます。このサイクルは、大規模な変更を正しく実装して、テストしてから新しいリリースが公開されるように、延長することが可能です。今後のリリースの詳細は、「:ref:`roadmaps`」を参照してください。" - -#~ 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." -#~ msgstr "メンテナンスされなくなった ``ansible-core`` のリリースを使用している場合は、最新の機能やセキュリティー修正からの恩恵を受けられるようにできるだけ早くアップグレードすることが強く推奨されます。" - -#~ msgid "Older, unmaintained versions of ``ansible-core`` can contain unfixed security vulnerabilities (*CVE*)." -#~ msgstr "メンテナンスされていない、以前の ``ansible-core`` バージョンには、未修正のセキュリティーの脆弱性が含まれている可能性があります (*CVE*)。" - -#~ 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." -#~ msgstr "コレクションの更新 (新しいモジュール、プラグイン、機能、バグ修正) は常に、Ansible の次のバージョンに統合されます。この作業は、個々のコレクションリポジトリー内で追跡されます。" - -#~ 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-`` git branches." -#~ msgstr "Ansible と ``ansible-core`` は、最新のメジャーリリースに対するバグ修正およびセキュリティーの改善を提供します。``ansible-core`` の 1 つ前のメジャーリリースでは、セキュリティー問題や重要なバグの修正のみが含まれます。``ansible-core`` では、2 リリース前のリリースに対してのみセキュリティー修正が適用されます。この作業は ``stable-`` の git ブランチで追跡されています。" - -#~ msgid "The fixes that land in maintained stable branches will eventually be released as a new version when necessary." -#~ msgstr "維持される安定版のブランチに保存された修正は、最終的に、必要に応じて新しいバージョンとしてリリースされます。" - -#~ 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." -#~ msgstr "変更ログは、フラグメントに基づいて生成されます。ここに例として 2.9_ の生成された変更ログがあります。新しい機能を作成したり、バグを修正したりするときは、変更点を記述した変更ログフラグメントを作成します。変更ログのエントリーは、新しいモジュールやプラグインには必要ありません。それらの項目の詳細は、モジュールのドキュメントから生成されます。" - -#~ msgid "We've got :ref:`examples and instructions on creating changelog fragments ` in the Community Guide." -#~ msgstr "コミュニティーガイドの :ref:`changelog フラグメントの作成例および指示 ` にあります。" - -#~ msgid "Before a new release or version of Ansible or ``ansible-core`` can be done, it will typically go through a release candidate process." -#~ msgstr "Ansible または ``ansible-core`` の新規リリースまたはバージョンを公開する前に、通常はリリース候補のプロセスを行います。" - -#~ msgid "This provides the Ansible community the opportunity to test these releases and report bugs or issues they might come across." -#~ msgstr "このプロセスでは、Ansible コミュニティーは、これらのリリースをテストして、今後発生する可能性のあるバグや修正を報告する機会があります。" - -#~ 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." -#~ msgstr "最初の候補に大きな問題がある場合は、必要な修正がプッシュされた時点で、2 番目の候補のタグ (``RC2``) が付けられます。2 番目の候補は、1 番目よりも期間は短くなります。2 営業日が経過して問題が報告されない場合は、最終的なリリースとなります。" - -#~ 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." -#~ msgstr "Ansible または ``ansible-core`` の中心となるメンテナーが最終リリース前に修正が必要とみなしたバグがある場合は、必要に応じて追加のリリース候補タグを付けることができます。" - -#~ msgid "While there is a pending release candidate, the focus of core developers and maintainers will on fixes towards the release candidate." -#~ msgstr "保留中のリリース候補がある場合は、中心となる開発者やメンテナーは、リリース候補に向けた修正に焦点を当てます。" - -#~ 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." -#~ msgstr "できるだけ早く新規リリースを公開するために、リリース候補に関連のない新機能や修正のマージが遅れる可能性があります。" - -#~ msgid "Ansible deprecation cycle" -#~ msgstr "Ansible 非推奨サイクル" - -#~ 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." -#~ msgstr "サイクルは通常 4 つの機能リリース (たとえば 2.x.y では、x は機能リリースを示し、y はバグ修正リリースを示します) にまたがるため、機能は通常、非推奨を発表してから 4 番目のリリースで削除されます。たとえば、2.9 で非推奨になったものは、バージョンがそのまま 3.x に続くと仮定すると、2.13 で削除されます。追跡は、リリース番号ではなく、リリースの数に関連付けられています。" - -#~ msgid "For modules/plugins, we keep the documentation after the removal for users of older versions." -#~ msgstr "モジュール/プラグインについては、以前のバージョンをご利用の方のために、削除後もドキュメントは保持します。" - -#~ msgid "The path to the directory of the playbook that was passed to the ``ansible-playbook`` command line." -#~ msgstr "``ansible-playbook`` コマンドラインに渡した Playbook のディレクトリーへのパス" - -#~ 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." -#~ msgstr "開発のワークフローにテストをある程度組み込むことで、実稼働環境でコードを使用時に、慌てることが少なくなります。多くの場合は、実稼働環境でテストを活用して、更新の失敗が、インストール全体に移行されてしまうのを防ぐことができます。また、プッシュベースになっているため、ローカルホストやテストサーバーで手順を非常に簡単に実行することができます。Ansible は、多くのチェックを挿入できるため、アップグレードのワークフローを希望のレベルに調節できます。" - -#~ msgid "Red Hat Ansible Tower" -#~ msgstr "Red Hat Ansible Tower" - -#~ msgid "`Red Hat Ansible 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 `_ は、チーム、組織、企業全体で Ansible を操作する Web コンソールおよび REST API です。Red Hat Ansible Tower は、すべての自動化タスクのハブとなるように設計されています。" - -#~ 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." -#~ msgstr "Ansible Tower には、セキュアに保存されている SSH や他のサービスの認証情報の使用時に制御するなど、ロールベースのアクセス制御が含まれています。Ansible Tower インベントリーは、幅広いクラウドソースと同期でき、強力な Playbook ワークフローを複数使用することで、複雑なプロセスをモデル化できます。" - -#~ 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 `_. 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 ページ `_ を参照してください。Ansible Tower は、Red Hat Ansible Automation サブスクリプションに含まれ、Red Hat, Inc のサポートが利用できます。" - -#~ 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." -#~ msgstr "``ansible.cfg`` から、``ssh_args`` に ``-o ServerAliveInterval=NumberOfSeconds`` を追加できます。このオプションがないと、SSH と Ansible は TCP 接続がタイムアウトになるまで待機します。別の解決方法は、``ServerAliveInterval`` をグローバルの SSH 設定に追加することです。``ServerAliveInterval`` に適した値は、ユーザーが決定します。ただし、SSH のデフォルトは ``ServerAliveCountMax=3`` であるため、SSH セッションの終了前に設定した値が 3 倍になる点に注意してください。" - -#~ msgid "A file (by default, Ansible uses a simple INI format) that describes :term:`Hosts ` and :term:`Groups ` in Ansible. Inventory can also be provided via an :term:`Inventory Script` (sometimes called an \"External Inventory Script\")." -#~ msgstr "Ansible で :term:`ホスト ` と :term:`グループ ` を記述したファイル (デフォルトでは、Ansible は簡単な INI 形式を使用)。インベントリーは、:term:`インベントリースクリプト` (「外部インベントリースクリプト」と呼ばれることもあります) を介して提供することもできます。" - -#~ msgid ":class:`set` of values marked as ``no_log`` in the argument spec. This is a temporary holding place for these values and may move in the future." -#~ msgstr "引数仕様で ``no_log`` とマークされた値の :class:`set`。これは、これらの値の一時的な保持となり、今後移動する可能性があります。" - -#~ 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." -#~ msgstr "コントローラーでは、Python 3.5 以降、および Python 2.7 以降をサポートしています。モジュール側では、Python 3.5 以降、Python 2.6 以降をサポートします。" - -#~ msgid "``ansible-core``/``ansible-base``" -#~ msgstr "``ansible-core``/``ansible-base``" - -#~ msgid "Release" -#~ msgstr "Release" - -#~ msgid "devel" -#~ msgstr "devel" - -#~ msgid "In development (ansible-core 2.14 unreleased, trunk)" -#~ msgstr "開発中 (未リリースの ansible-core 2.14 (trunk))" - -#~ msgid "TBD" -#~ msgstr "TBD" - -#~ msgid "`2.13 ansible-core Changelogs`_" -#~ msgstr "`2.10 ansible-base Release Notes`_" - -#~ msgid "Maintained (security **and** general bug fixes)" -#~ msgstr "メンテナンス対象 (セキュリティー **および** 一般的なバグの修正)" - -#~ msgid "`2.12 ansible-core Changelogs`_" -#~ msgstr "`2.10 ansible-base Release Notes`_" - -#~ msgid "Maintained (security **and** critical bug fixes)" -#~ msgstr "メンテナンス対象 (セキュリティー **および** 重大なバグの修正)" - -#~ msgid "`2.11 ansible-core Changelogs`_" -#~ msgstr "`2.10 ansible-base Release Notes`_" - -#~ msgid "Maintained (security bug fixes only)" -#~ msgstr "メンテナンス対象 (セキュリティーバグ修正のみ)" - -#~ msgid "`2.10 ansible-base Changelogs`_" -#~ msgstr "`2.10 ansible-base Release Notes`_" - -#~ msgid "EOL" -#~ msgstr "EOL" - -#~ msgid "`2.9 Changelogs`_" -#~ msgstr "`2.9 Changelogs`_" - -#~ msgid "`2.8 Changelogs`_" -#~ msgstr "`2.8 Changelogs`_" - -#~ msgid "`2.7 Changelogs`_" -#~ msgstr "`2.7 Changelogs`_" - -#~ msgid "`2.6 Changelogs`_" -#~ msgstr "`2.6 Changelogs`_" - -#~ msgid "`2.5 Changelogs`_" -#~ msgstr "`2.5 Changelogs`_" - -#~ msgid "<2.5" -#~ msgstr "2.5 より前のバージョン" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po deleted file mode 100644 index 04857f635db..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po +++ /dev/null @@ -1,2087 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2021 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:3 -msgid "Ansible project 2.10" -msgstr "Ansible プロジェクト 2.10" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:5 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_10` for the most recent updates on ansible-base." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-base `_ パッケージの日付もいくつか含まれています。この日付はすべて変更する可能性があります。ansible-base の最新の更新については「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:11 -#: ../../rst/roadmap/ROADMAP_2_10.rst:11 ../../rst/roadmap/ROADMAP_2_11.rst:11 -#: ../../rst/roadmap/ROADMAP_2_12.rst:11 ../../rst/roadmap/ROADMAP_2_13.rst:11 -#: ../../rst/roadmap/ROADMAP_2_14.rst:11 ../../rst/roadmap/ROADMAP_2_6.rst:8 -#: ../../rst/roadmap/ROADMAP_2_7.rst:8 ../../rst/roadmap/ROADMAP_2_8.rst:9 -#: ../../rst/roadmap/ROADMAP_2_9.rst:9 -msgid "Release Schedule" -msgstr "リリーススケジュール" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:13 -#: ../../rst/roadmap/ROADMAP_2_10.rst:19 ../../rst/roadmap/ROADMAP_2_11.rst:19 -#: ../../rst/roadmap/ROADMAP_2_12.rst:19 ../../rst/roadmap/ROADMAP_2_13.rst:19 -#: ../../rst/roadmap/ROADMAP_2_14.rst:18 -msgid "Dates subject to change." -msgstr "日付は変更する可能性があります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:14 -msgid "We plan to post weekly alpha releases to the `PyPI ansible project `_ for testing." -msgstr "テストのため、`PyPI ansible プロジェクト `_ に Alpha リリースを毎週公開することが予定されています。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:17 -msgid "We initially were going to have feature freeze on 2020-08-18. We tried this but decided to change course. Instead, we'll enter feature freeze when ansible-2.10.0 beta1 is released." -msgstr "当初は 2020 年 08 月 18 日に機能フリーズが行われる予定でした。フリーズを試みましたが、予定が変更になりました。代わりに、ansible-2.10.0 Beta1 がリリースされたときに機能フリーズになります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:20 -msgid "2020-06-23: ansible-2.10 alpha freeze. No net new collections will be added to the ``ansible-2.10`` package after this date." -msgstr "2020 年 06 月 23 日: ansible-2.10 Alpha フリーズ。この日付を過ぎると、新しいコレクションが ``ansible-2.10`` パッケージに追加されなくなります。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:22 -msgid "2020-07-10: Ansible collections freeze date for content shuffling. Content should be in its final collection for the ansible-2.10 series of releases. No more content should move out of the ``community.general`` or ``community.network`` collections." -msgstr "2020 年 07 月 10 日: コンテンツ入れ替えの Ansible コレクション。コンテンツは、ansible-2.10 シリーズのリリースの最終コレクションにあるはずです。他のコンテンツは ``community.general`` コレクションまたは ``community.network`` コレクションに含まれるコンテンツは他にありません。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:24 -msgid "2020-08-13: ansible-base 2.10 Release date, see :ref:`base_roadmap_2_10`." -msgstr "2020 年 08 月 13 日: ansible-base 2.10 リリース日。「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:25 -msgid "2020-08-14: final ansible-2.10 alpha." -msgstr "2020 年 08 月 14 日: 最終的な ansible-2.10 Alpha。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:26 -msgid "2020-09-01: ansible-2.10.0 beta1 and feature freeze." -msgstr "2020 年 09 月 01 日: ansible-2.10.0 Beta1 および機能フリーズ。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:28 -msgid "No new modules or major features will be added after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-1.1.0; ansible-2.10.0 could ship with community-crypto-1.1.1. It would not ship with community-crypto-1.2.0." -msgstr "この日付以降は、新しいモジュールや主な機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-1.1.0 であれば、ansible-2.10.0 は community-crypto-1.1.1 に同梱される可能性がありました。community-crypto-1.2.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:30 -msgid "2020-09-08: ansible-2.10.0 beta2." -msgstr "2020 年 09 月 08 日: Ansible-2.10.0 beta2。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:31 -msgid "2020-09-15: ansible-2.10.0 rc1 and final freeze." -msgstr "2020 年 09 月 15 日: Ansible-2.10.0 rc1 および最終フリーズ。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:33 -msgid "After this date only changes blocking a release are accepted." -msgstr "この日付以降は、リリースをブロックする変更のみが許可されます。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:34 -msgid "Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at the community meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_." -msgstr "コレクションは、ブロッカーが承認された場合にのみ新規バージョンに更新されます。コレクションの所有者は、修正のためにコレクションのバージョンを上げるかどうかを決めるために、コミュニティーミーティングのブロッカーについて (9 ~ 17 上) 議論する必要があります。`Community meeting agenda `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:36 -msgid "** Additional release candidates to be published as needed as blockers are fixed **" -msgstr "**ブロッカーが修正されると、必要に応じて公開される追加のリリース候補**" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:38 -msgid "2020-09-22: ansible-2.10 GA release date." -msgstr "2020 年 09 月 22 日: Ansible-2.10 GA リリース日。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:40 -msgid "Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0)." -msgstr "コレクションに変更が加えられた場合、または後で ansible-base-2.10.x へのアップグレードを強制する必要があると見なされた場合、Ansible-2.10.x パッチのリリースは約 3 週間ごとに行われます。Ansible-2.10.x パッチリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときは変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-2.10 が community-crypto-1.1.0 に同梱されると、ansible-2.10.1 は community-crypto-1.2.0 に同梱される場合がありますが、community-crypto-2.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:45 -msgid "Minor releases will stop when :ref:`Ansible-3 ` is released. See the :ref:`Release and Maintenance Page ` for more information." -msgstr ":ref:`Ansible-3 ` がリリースされると、マイナーリリースは停止します。詳細は「:ref:`リリースおよびメンテナンスページ `」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:48 -msgid "Breaking changes may be introduced in ansible-3.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly." -msgstr "ansible-3.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、非互換性になる前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。" - -#: ../../rst/roadmap/COLLECTIONS_2_10.rst:51 -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:52 -#: ../../rst/roadmap/COLLECTIONS_4.rst:55 -#: ../../rst/roadmap/COLLECTIONS_5.rst:58 -#: ../../rst/roadmap/COLLECTIONS_6.rst:56 -#: ../../rst/roadmap/COLLECTIONS_7.rst:57 -msgid "For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details." -msgstr "詳細は、メーリングリストまたはチャットチャンネルをご利用ください。「:ref:`communication`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:5 -msgid "Ansible project 3.0" -msgstr "Ansible プロジェクト 3.0" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:7 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. Ansible 3.x.x includes ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for the most recent updates on ``ansible-base``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-base `_ パッケージの日付もいくつか含まれています。この日付はすべて変更する可能性があります。Ansible 3.x.x には ``ansible-base`` 2.10 が含まれます。``ansible-base`` の最新の更新については、「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:13 -#: ../../rst/roadmap/COLLECTIONS_4.rst:14 -#: ../../rst/roadmap/COLLECTIONS_5.rst:14 -#: ../../rst/roadmap/COLLECTIONS_6.rst:14 -#: ../../rst/roadmap/COLLECTIONS_7.rst:14 -msgid "Release schedule" -msgstr "リリーススケジュール" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:17 -msgid "Ansible is switching from its traditional versioning scheme to `semantic versioning `_ starting with this release. So this version is 3.0.0 instead of 2.11.0." -msgstr "Ansible は、本リリース以降の従来のバージョン管理スキームから `semantic versioning `_ に切り替えるため、このバージョンは 2.11.0 ではなく 3.0.0 になります。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2020-12-16" -msgstr "2020 年 12 月 16 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:21 -msgid "Finalize rules for net-new collections submitted for the ansible release." -msgstr "Ansible リリースに送信された net-new コレクションのルールのファイナライズ。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-01-27" -msgstr "2021 年 01 月 27 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:22 -msgid "Final day for new collections to be **reviewed and approved**. They MUST be submitted prior to this to give reviewers a chance to look them over and for collection owners to fix any problems." -msgstr "新しいコレクションの **レビューおよび承認** の最終日。レビュー担当者が新しいコレクションを確認し、コレクションの所有者が問題を修正する機会を得るために、この日付までに提出する必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-02-02" -msgstr "2021 年 02 月 02 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:25 -msgid "Ansible-3.0.0-beta1 -- feature freeze [1]_" -msgstr "ansible-3.0.0-beta1 -- 機能フリーズ [1]_" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-02-09" -msgstr "2021 年 02 月 09 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:26 -msgid "Ansible-3.0.0-rc1 -- final freeze [2]_ [3]_" -msgstr "Ansible-3.0.0-rc1 -- 最終フリーズ [2]_ [3]_" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-02-16" -msgstr "2021 年 02 月 16 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:27 -msgid "Release of Ansible-3.0.0" -msgstr "Ansible-3.0.0 のリリース" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst -msgid "2021-03-09" -msgstr "2021 年 03 月 09 日" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:28 -msgid "Release of Ansible-3.1.0 (bugfix + compatible features: every three weeks)" -msgstr "Ansible-3.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:30 -msgid "No new modules or major features accepted after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0." -msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-2.1.0 であれば、ansible-3.0.0 は community-crypto-2.1.1 に同梱される可能性がありました。community-crypto-2.2.0 は同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:32 -#: ../../rst/roadmap/COLLECTIONS_4.rst:35 -#: ../../rst/roadmap/COLLECTIONS_5.rst:38 -#: ../../rst/roadmap/COLLECTIONS_6.rst:36 -#: ../../rst/roadmap/COLLECTIONS_7.rst:37 -msgid "After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date." -msgstr "この日付以降は、リリースをブロックする変更のみが許可されます。受け入れ可能な変更には、新しい rc を作成する必要があり、最終リリース日は処理されない可能性があります。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:33 -msgid "Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_." -msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティーミーティングのブロッカーについて検討する必要があります。`Community meeting agenda `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:38 -msgid "Breaking changes may be introduced in Ansible 3.0.0, although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before the breaking change happens." -msgstr "Ansible3.0.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:42 -#: ../../rst/roadmap/COLLECTIONS_4.rst:45 -#: ../../rst/roadmap/COLLECTIONS_5.rst:48 -#: ../../rst/roadmap/COLLECTIONS_6.rst:46 -#: ../../rst/roadmap/COLLECTIONS_7.rst:47 -msgid "Ansible minor releases" -msgstr "Ansible マイナーリリース" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:44 -msgid "Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-3.0.0 ships with community-crypto-2.1.0; Ansible-3.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0)." -msgstr "コレクションに変更が加えられた場合、または後で ansible-base-2.10.x へのアップグレードを強制する必要があると見なされた場合、Ansible 3.x.x マイナーリリースは約 3 週間ごとに行われます。Ansible 3.x.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-3.0.0 が community-crypto-2.1.0 に同梱されると、Ansible-3.1.0 は community-crypto-2.2.0 に同梱される場合がありますが、community-crypto-3.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:49 -msgid "Minor releases will stop when :ref:`Ansible-4 ` is released. See the :ref:`Release and Maintenance Page ` for more information." -msgstr ":ref:`Ansible-4 ` がリリースされると、マイナーリリースは停止します。詳細は「:ref:`リリースおよびメンテナンスページ `」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:56 -msgid "ansible-base release" -msgstr "ansible-base リリース" - -#: ../../rst/roadmap/COLLECTIONS_3_0.rst:58 -msgid "Ansible 3.x.x works with ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for details." -msgstr "Ansible 3.x.x は ``ansible-base`` 2.10 で動作します。詳細は、「:ref:`base_roadmap_2_10`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:5 -msgid "Ansible project 4.0" -msgstr "Ansible プロジェクト 4.0" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:7 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_11` for the most recent updates on ``ansible-core``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-core `_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については「:ref:`base_roadmap_2_11`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-01-26" -msgstr "2021 年 01 月 26日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:17 -msgid "New Collections will be reviewed for inclusion in Ansible 4. Submit a request to include a new collection in this `GitHub Discussion `_." -msgstr "新しいコレクションは、Ansible 4 に含まれるようにレビューされます。この `GitHub ディスカッション `_ に新しいコレクションを追加するリクエストを送信してください。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-03-03" -msgstr "2021 年 03 月 03 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:18 -msgid "Ansible-4.0.0 alpha1 (biweekly ``ansible`` alphas. These are timed to coincide with the start of the ``ansible-core-2.11`` pre-releases)." -msgstr "Ansible-4.0.0 alpha1 (``ansible`` Alpha は隔週)。これらは ``ansible-core-2.11`` プレリリースの開始と合致するようにタイミングが調整されます。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-03-16" -msgstr "2021 年 03 月 16 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:19 -msgid "Ansible-4.0.0 alpha2" -msgstr "Ansible-4.0.0 alpha2" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-03-30" -msgstr "2021 年 03 月 30 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:20 -msgid "Ansible-4.0.0 alpha3" -msgstr "Ansible-4.0.0 alpha3" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-13" -msgstr "2021 年 04 月 13 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:21 -msgid "Last day for new collections to be submitted for inclusion in Ansible 4. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion." -msgstr "Ansible 4 に含めるために新しいコレクションを送信する最終日。コレクションを含める前に、コレクションをレビューして承認する必要があることに注意してください。すべてのコレクションをレビューする保証はありません。コレクションが早く提出されるほど、コレクションがレビューされ、必要なフィードバックが含まれるのに間に合うように対処される可能性が高くなります。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:22 -msgid "Ansible-4.0.0 alpha4" -msgstr "Ansible-4.0.0 alpha4" - -#: ../../rst/roadmap/COLLECTIONS_4.rst ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-04-14" -msgstr "2021 年 04 月 14 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:23 -msgid "Community Meeting topic: list any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate." -msgstr "コミュニティーミーティングのトピック: リリースをブロックする新しいコレクションレビューを一覧表示します。beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-21" -msgstr "2021 年 04 月 21 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:24 -#: ../../rst/roadmap/COLLECTIONS_5.rst:25 -#: ../../rst/roadmap/COLLECTIONS_6.rst:23 -#: ../../rst/roadmap/COLLECTIONS_7.rst:23 -msgid "Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline." -msgstr "コミュニティーミーティングのトピック: 期限に間に合わないブロッカーに対してアクティブにする不測の事態を決定します。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-26" -msgstr "2021 年 04 月 26 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:25 -msgid "Last day for new collections to be **reviewed and approved** for inclusion in Ansible 4." -msgstr "新しいコレクションを Ansible 4 に含めるために **レビューおよび承認** される最終日。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:26 -msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible 4." -msgstr "コレクションが Ansible 4 に受け入れられる後方互換性のないリリースを作成する最終日。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-04-27" -msgstr "2021 年 04 月 27 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:27 -msgid "Ansible-4.0.0 beta1 -- feature freeze [1]_ (weekly beta releases. Collection owners and interested users should test for bugs)." -msgstr "Ansible-4.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-05-04" -msgstr "2021 年 05 月 04 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:28 -msgid "Ansible-4.0.0 beta2" -msgstr "Ansible-4.0.0 beta2" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-05-11" -msgstr "2021 年 05 月 11 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:29 -msgid "Ansible-4.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed. Test and alert us to any blocker bugs)." -msgstr "Ansible-4.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-05-18" -msgstr "2021 年 05 月 18 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:30 -msgid "Ansible-4.0.0 release" -msgstr "Ansible-4.0.0 リリース" - -#: ../../rst/roadmap/COLLECTIONS_4.rst -msgid "2021-06-08" -msgstr "2021 年 06 月 08 日" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:31 -msgid "Release of Ansible-4.1.0 (bugfix + compatible features: every three weeks)" -msgstr "Ansible-4.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:33 -msgid "No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0." -msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-2.1.0 であれば、ansible-3.0.0 は community-crypto-2.1.1 に同梱される可能性がありました。community-crypto-2.2.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:36 -msgid "Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a Community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_." -msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティーミーティングのブロッカーについて検討する必要があります。`Community meeting agenda `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:41 -msgid "Breaking changes will be introduced in Ansible 4.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed." -msgstr "Ansible 4.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:47 -msgid "Ansible 4.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.11.x. Ansible 4.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-4.0.0 ships with community-crypto-2.1.0; Ansible-4.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0)." -msgstr "コレクションに変更が加えられた場合、または後で ansible-core-2.11.x へのアップグレードを強制する必要があると見なされた場合、Ansible 4.x マイナーリリースは約 3 週間ごとに行われます。Ansible 4.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-4.0.0 が community-crypto-2.1.0 に同梱されると、Ansible-4.1.0 は community-crypto-2.2.0 に同梱される場合がありますが、community-crypto-3.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_4.rst:52 -msgid "Minor releases will stop when Ansible-5 is released. See the :ref:`Release and Maintenance Page ` for more information." -msgstr "Ansible-5 がリリースされると、マイナーリリースは停止します。詳細は「:ref:`リリースおよびメンテナンスページ `」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:5 -msgid "Ansible project 5.0" -msgstr "Ansible プロジェクト 5.0" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:7 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`core_roadmap_2_12` for the most recent updates on ``ansible-core``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-core `_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については「:ref:`core_roadmap_2_12`」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:16 -msgid "New Collections can be reviewed for inclusion in Ansible 5. Submit a request to include a new collection in this `GitHub Discussion `_." -msgstr "新しいコレクションは、Ansible 5 に含まれるようにレビューされます。この `GitHub Discussion `_ に新しいコレクションを追加するリクエストを送信してください。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-09-24" -msgstr "2021-09-24" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:17 -msgid "ansible-core feature freeze." -msgstr "ansible-core 機能のフリーズ。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-09-27" -msgstr "2021-09-27" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:18 -msgid "Start of ansible-core 2.12 betas (weekly, as needed)." -msgstr "ansible-core 2.12 ベータ版（必要に応じて毎週）の開始。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-05" -msgstr "2021-10-05" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:19 -msgid "Ansible-5.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.12`` pre-releases)." -msgstr "Ansible-5.0.0 alpha1（ほぼ隔週。``ansible`` のアルファ版。``ansible-core-2.12``プレリリースとタイミングをあわせる）。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-12" -msgstr "2021-10-12" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:20 -msgid "Last day for new collections to be submitted for inclusion in Ansible-5. Collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion." -msgstr "Ansible 5 に含めるために新しいコレクションを送信する最終日。コレクションを含める前に、コレクションをレビューして承認する必要があります。すべてのコレクションをレビューする保証はありません。コレクションが早く提出されるほど、コレクションがレビューされ、必要なフィードバックが含まれるのに間に合うように対処される可能性が高くなります。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-13" -msgstr "2021-10-13" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:21 -msgid "Community Meeting topic: List any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate." -msgstr "コミュニティーミーティングのトピック: リリースをブロックする新しいコレクションレビューを一覧表示します。beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-18" -msgstr "2021-10-18" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:22 -msgid "First ansible-core release candidate, stable-2.12 branch created." -msgstr "最初の ansible-core リリース候補、stable-2.12 ブランチの作成。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-19" -msgstr "2021-10-19" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:23 -msgid "Ansible-5.0.0 alpha2." -msgstr "Ansible-5.0.0 alpha2" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-26" -msgstr "2021-10-26" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:24 -msgid "Last day for new collections to be **reviewed and approved** for inclusion in Ansible-5." -msgstr "新しいコレクションを Ansible 5 に含めるために **レビューおよび承認** される最終日。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-10-27" -msgstr "2021-10-27" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-11-02" -msgstr "2021-11-02" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:26 -msgid "Ansible-5.0.0 alpha3." -msgstr "Ansible-5.0.0 alpha3" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-11-08" -msgstr "2021-11-08" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:27 -msgid "Ansible-core-2.12 released." -msgstr "ansible-core-2.12 のリリース" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:28 -msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible-5." -msgstr "後方互換性のないリリースをまとめたコレクションを Ainbile-5 に採用される最終日。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-11-09" -msgstr "2021-11-09" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:29 -msgid "Create the ansible-build-data directory and files for Ansible-6. New collection approvals will target this." -msgstr "Ansible-6 向けの ansible-build-data ディレクトリーとファイルを作成。新規コレクションの承認はこれを対象とします。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:30 -msgid "Ansible-5.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs)." -msgstr "Ansible-5.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-11-16" -msgstr "2021-11-16" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:31 -msgid "Ansible-5.0.0 beta2." -msgstr "Ansible-5.0.0 beta2" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-11-23" -msgstr "2021-11-23" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:32 -msgid "Ansible-5.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release." -msgstr "Ansible-5.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)。ブロッカーバグはリリースを遅延させます。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-11-30" -msgstr "2021-11-30" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:33 -msgid "Ansible-5.0.0 release." -msgstr "Ansible-5.0.0 リリース" - -#: ../../rst/roadmap/COLLECTIONS_5.rst -msgid "2021-12-21" -msgstr "2021-12-21" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:34 -msgid "Release of Ansible-5.1.0 (bugfix + compatible features: every three weeks.)" -msgstr "Ansible-5.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:36 -msgid "No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.1.0; Ansible-5.0.0 could ship with community.crypto 2.1.1. It would not ship with community.crypto 2.2.0." -msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community.crypto 2.1.0 であれば、ansible-5.0.0 は community.crypto 2.1.1 に同梱される可能性がありました。community.crypto 2.2.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:40 -#: ../../rst/roadmap/COLLECTIONS_6.rst:38 -#: ../../rst/roadmap/COLLECTIONS_7.rst:39 -msgid "Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_." -msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティー IRC ミーティングのブロッカーについて検討する必要があります。`コミュニティー IRC ミーティングの議題 `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:44 -msgid "Breaking changes will be introduced in Ansible 5.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed." -msgstr "Ansible 5.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:50 -msgid "Ansible 5.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.12.x. Ansible 5.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-5.0.0 ships with community.crypto 2.1.0; Ansible-5.1.0 may ship with community.crypto 2.2.0 but would not ship with community.crypto 3.0.0." -msgstr "コレクションに変更が加えられた場合、または後で ansible-core-2.12.x へのアップグレードを強制する必要があると見なされた場合、Ansible 5.x マイナーリリースは約 3 週間ごとに行われます。Ansible 5.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-5.0.0 が community.crypto 2.1.0 に同梱されると、Ansible-5.1.0 は community.crypto 2.2.0 に同梱される場合がありますが、community.crypto.3.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_5.rst:55 -msgid "Minor releases will stop when Ansible-6 is released. See the :ref:`Release and Maintenance Page ` for more information." -msgstr "Ansible-6 がリリースされると、マイナーリリースは停止します。詳細は「:ref:`Release and Maintenance Page `」を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:5 -msgid "Ansible project 6.0" -msgstr "Ansible プロジェクト 6.0" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:7 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.13 Roadmap `_ for the most recent updates on ``ansible-core``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-core `_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については `ansible-core 2.13 Roadmap ` を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-03-28" -msgstr "2022-03-28" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:17 -msgid "ansible-core feature freeze, stable-2.13 branch created." -msgstr "ansible-core 機能のフリーズ、stable-2.13 ブランチが作成されました。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-04-11" -msgstr "2022-04-11" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:18 -msgid "Start of ansible-core 2.13 betas (biweekly, as needed)." -msgstr "ansible-core 2.123 ベータ版 (必要に応じて毎週) の開始。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-04-12" -msgstr "2022-04-12" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:19 -msgid "Ansible-6.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.13`` pre-releases)." -msgstr "Ansible-6.0.0 alpha1 (ほぼ隔週。``ansible`` のアルファ版。``ansible-core-2.13``プレリリースとタイミングをあわせる)。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-04-27" -msgstr "2022-04-27" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:20 -msgid "Community Meeting topic: List any backwards incompatible collection releases that beta1 should try to accommodate." -msgstr "コミュニティーミーティングのトピック: beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-02" -msgstr "2022-05-02" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:21 -msgid "First ansible-core release candidate." -msgstr "最初の ansible-core リリース候補。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-03" -msgstr "2022-05-03" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:22 -msgid "Ansible-6.0.0 alpha2." -msgstr "Ansible-6.0.0 alpha2。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-11" -msgstr "2022-05-11" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-16" -msgstr "2022-05-16" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:24 -msgid "Ansible-core-2.13 released." -msgstr "ansible-core-2.13 のリリース。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-17" -msgstr "2022-05-17" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:25 -msgid "Ansible-6.0.0 alpha3." -msgstr "Ansible-6.0.0 alpha3。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-23" -msgstr "2022-05-23" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:26 -msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible-6. This includes adding new collections to Ansible 6.0.0; from now on new collections have to wait for 6.1.0 or later." -msgstr "コレクションが Ansible-6 に受け入れられる下位互換性のないリリースを作成する最終日。これには、Ansible 6.0.0 への新しいコレクションの追加が含まれます。今後、新しいコレクションは 6.1.0 以降を待つ必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-24" -msgstr "2022-05-24" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:27 -msgid "Create the ansible-build-data directory and files for Ansible-7." -msgstr "Ansible-7 用の ansible-build-data ディレクトリーおよびファイルを作成します。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:28 -msgid "Ansible-6.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs)." -msgstr "Ansible-6.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-05-31" -msgstr "2022-05-31" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:29 -msgid "Ansible-6.0.0 beta2." -msgstr "Ansible-6.0.0 beta2" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-06-07" -msgstr "2022-06-07" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:30 -msgid "Ansible-6.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release." -msgstr "Ansible-6.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)。ブロッカーバグはリリースを遅延させます。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-06-21" -msgstr "2022-06-21" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:31 -msgid "Ansible-6.0.0 release." -msgstr "Ansible-6.0.0 リリース" - -#: ../../rst/roadmap/COLLECTIONS_6.rst -msgid "2022-07-12" -msgstr "2022-07-12" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:32 -msgid "Release of Ansible-6.1.0 (bugfix + compatible features: every three weeks.)" -msgstr "Ansible-6.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:34 -msgid "No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-6.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0." -msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community.crypto 2.3.0 であれば、ansible-6.0.0 は community.crypto 2.3.1 に同梱される可能性がありました。community.crypto 2.4.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:42 -msgid "Breaking changes will be introduced in Ansible 6.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed." -msgstr "Ansible 6.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:48 -msgid "Ansible 6.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.13.x. Ansible 6.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-6.0.0 ships with community.crypto 2.3.0; Ansible-6.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0." -msgstr "コレクションに変更が加えられた場合、または後で ansible-core-2.13.x へのアップグレードを強制する必要があると見なされた場合、Ansible 6.x マイナーリリースは約 3 週間ごとに行われます。Ansible 6.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-6.0.0 が community.crypto 2.3.0 に同梱されると、Ansible-6.1.0 は community.crypto 2.4.0 に同梱される場合がありますが、community.crypto.3.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:53 -msgid "Minor releases will stop when Ansible-7 is released. See the :ref:`Release and Maintenance Page ` for more information." -msgstr "Ansible-7 がリリースされると、マイナーリリースは停止します。詳細は :ref:`Release and Maintenance Page ` を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:59 ../../rst/roadmap/ROADMAP_2_10.rst:36 -#: ../../rst/roadmap/ROADMAP_2_11.rst:38 ../../rst/roadmap/ROADMAP_2_12.rst:38 -#: ../../rst/roadmap/ROADMAP_2_13.rst:49 ../../rst/roadmap/ROADMAP_2_14.rst:49 -#: ../../rst/roadmap/ROADMAP_2_8.rst:36 ../../rst/roadmap/ROADMAP_2_9.rst:37 -msgid "Planned work" -msgstr "予定される作業" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:61 -msgid "More details can be found in `the community-topics planning issue `_." -msgstr "詳細は `the community-topics planning issue `_ を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:63 -msgid "Remove compatibility code which prevents parallel install of Ansible 6 with Ansible 2.9 or ansible-base 2.10" -msgstr "Ansible 2.9 または ansible-base 2.10 と Ansible 6 の並列インストールを妨げる互換性コードを削除します" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:64 -msgid "Stop installing files (such as tests and development artifacts like editor configs) we have no use for" -msgstr "使用しないファイル (エディター設定などのテストや開発アーティファクトなど) のインストールを停止します" - -#: ../../rst/roadmap/COLLECTIONS_6.rst:65 -msgid "Ship Python wheels (as ansible-core 2.13 will likely also do) to improve installation performance" -msgstr "インストールパフォーマンスを向上させるために、Python wheel を出荷します (ansible-core 2.13 もそうなる可能性があります)" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:5 -msgid "Ansible project 7.0" -msgstr "Ansible プロジェクト 7.0" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:7 -msgid "This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.14 Roadmap `_ for the most recent updates on ``ansible-core``." -msgstr "本リリーススケジュールには、`ansible `_ パッケージの日付が含まれており、`ansible-core `_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については `ansible-core 2.14 Roadmap ` を参照してください。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-09-19" -msgstr "2022-09-19" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:17 -msgid "ansible-core feature freeze, stable-2.14 branch created." -msgstr "ansible-core 機能のフリーズ、stable-2.14 ブランチが作成されました。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-09-26" -msgstr "2022-09-26" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:18 -msgid "Start of ansible-core 2.14 betas (biweekly, as needed)." -msgstr "ansible-core 2.14 ベータ版 (必要に応じて毎週) の開始。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-09-27" -msgstr "2022-09-27" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:19 -msgid "Ansible-7.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.14`` pre-releases)." -msgstr "Ansible-7.0.0 alpha1 (ほぼ隔週。``ansible`` のアルファ版。``ansible-core-2.14``プレリリースとタイミングをあわせる)。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-10-12" -msgstr "2022-10-12" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:20 -msgid "Community topic: List any backwards incompatible collection releases that beta1 should try to accommodate." -msgstr "コミュニティーのトピック: beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-10-17" -msgstr "2022-10-17" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:21 -msgid "First ansible-core 2.14 release candidate." -msgstr "最初の ansible-core 2.14 リリース候補。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-10-25" -msgstr "2022-10-25" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:22 -msgid "Ansible-7.0.0 alpha2." -msgstr "Ansible-7.0.0 alpha2。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-10-26" -msgstr "2022-10-26" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-11-07" -msgstr "2022-11-07" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:24 -msgid "Ansible-core-2.14.0 released." -msgstr "Ansible-core-2.14.0 のリリース。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:25 -msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible-7. This includes adding new collections to Ansible 7.0.0; from now on new collections have to wait for 7.1.0 or later." -msgstr "コレクションが Ansible-7 に受け入れられる下位互換性のないリリースを作成する最終日。これには、Ansible 7.0.0 への新しいコレクションの追加が含まれます。今後、新しいコレクションは 7.1.0 以降を待つ必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-11-08" -msgstr "2022-11-08" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:26 -msgid "Create the ansible-build-data directory and files for Ansible-8." -msgstr "Ansible-8 用の ansible-build-data ディレクトリーおよびファイルを作成します。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:27 -msgid "Ansible-7.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs)." -msgstr "Ansible-7.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-11-15" -msgstr "2022-11-15" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:28 -msgid "Ansible-7.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release." -msgstr "Ansible-7.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)。ブロッカーバグはリリースを遅延させます。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-11-18" -msgstr "2022-11-18" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:29 -msgid "Last day to trigger an Ansible-7.0.0rc2 release because of major defects in Ansible-7.0.0rc1." -msgstr "Ansible-7.0.0rc2 リリースをトリガーする最終日 (Ansible-7.0.0rc1 に重大な問題がある場合)。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-11-22" -msgstr "2022-11-22" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:30 -msgid "Ansible-7.0.0rc2 when necessary, otherwise Ansible-7.0.0 release." -msgstr "必要に応じて Ansible-7.0.0rc2。それ以外は Ansible-7.0.0 リリース。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-11-29" -msgstr "2022-11-29" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:31 -msgid "Ansible-7.0.0 release when Ansible-7.0.0rc2 was necessary." -msgstr "Ansible-7.0.0 リリース (Ansible-7.0.0rc2 が必要だった場合)。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-12-05" -msgstr "2022-12-05" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:32 -msgid "Release of ansible-core 2.14.1." -msgstr "Ansible-core 2.14.1 のリリース" - -#: ../../rst/roadmap/COLLECTIONS_7.rst -msgid "2022-12-06" -msgstr "2022-12-06" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:33 -msgid "Release of Ansible-7.1.0 (bugfix + compatible features: every four weeks.)" -msgstr "Ansible-7.1.0 のリリース (バグ修正 + 互換性のある機能: 4 週間ごと)" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:35 -msgid "No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-7.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0." -msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community.crypto 2.3.0 であれば、ansible-7.0.0 は community.crypto 2.3.1 に同梱される可能性がありました。community.crypto 2.4.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:43 -msgid "Breaking changes will be introduced in Ansible 7.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed." -msgstr "Ansible 7.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:49 -msgid "Ansible 7.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.14.x. Ansible 7.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-7.0.0 ships with community.crypto 2.3.0; Ansible-7.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0." -msgstr "コレクションに変更が加えられた場合、または後にリリースされる ansible-core-2.14.x と調整する必要がある場合に、Ansible 7.x マイナーリリースは約 4 週間ごとに行われます。Ansible 7.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-7.0.0 が community.crypto 2.3.0 に同梱されると、Ansible-6.1.0 は community.crypto 2.4.0 に同梱される場合がありますが、community.crypto.3.0.0 には同梱されません。" - -#: ../../rst/roadmap/COLLECTIONS_7.rst:54 -msgid "Minor releases will stop when Ansible-8 is released. See the :ref:`Release and Maintenance Page ` for more information." -msgstr "Ansible-8 がリリースされると、マイナーリリースは停止します。詳細は :ref:`Release and Maintenance Page ` を参照してください。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:5 -msgid "Ansible-base 2.10" -msgstr "Ansible-base 2.10" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:14 ../../rst/roadmap/ROADMAP_2_11.rst:14 -#: ../../rst/roadmap/ROADMAP_2_12.rst:14 ../../rst/roadmap/ROADMAP_2_13.rst:14 -#: ../../rst/roadmap/ROADMAP_2_14.rst:14 ../../rst/roadmap/ROADMAP_2_7.rst:11 -#: ../../rst/roadmap/ROADMAP_2_8.rst:12 ../../rst/roadmap/ROADMAP_2_9.rst:12 -msgid "Expected" -msgstr "予定" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:16 -msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-base release." -msgstr "プル要求は、この ansible-base リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:18 -msgid "There is no Alpha phase in 2.10." -msgstr "2.10 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:21 -msgid "2020-06-16 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code" -msgstr "2020 年 06 月 16 日 Beta 1 **機能フリーズ** どのコードにも新しい機能 (モジュール、プラグインなど) はありません。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:24 -msgid "2020-07-21 Release Candidate 1 (bumped from 2020-07-14)" -msgstr "2020 年 07 月 21 日 リリース候補 1 (2020-07-14 からバージョンを上げました)" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:25 -msgid "2020-07-24 Release Candidate 2" -msgstr "2020 年 07 月 24 日 リリース候補 2" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:26 -msgid "2020-07-25 Release Candidate 3" -msgstr "2020 年 07 月 25 日 リリース候補 3" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:27 -msgid "2020-07-30 Release Candidate 4" -msgstr "2020 年 07 月 30 日 リリース候補 4" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:28 -msgid "2020-08-13 Release" -msgstr "2020 年 08 月 13 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:31 ../../rst/roadmap/ROADMAP_2_11.rst:33 -#: ../../rst/roadmap/ROADMAP_2_12.rst:33 ../../rst/roadmap/ROADMAP_2_13.rst:44 -#: ../../rst/roadmap/ROADMAP_2_14.rst:44 ../../rst/roadmap/ROADMAP_2_5.rst:19 -#: ../../rst/roadmap/ROADMAP_2_6.rst:27 ../../rst/roadmap/ROADMAP_2_7.rst:24 -#: ../../rst/roadmap/ROADMAP_2_8.rst:31 ../../rst/roadmap/ROADMAP_2_9.rst:31 -msgid "Release Manager" -msgstr "リリースマネージャー" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:33 -msgid "@sivel" -msgstr "@sivel" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:38 -msgid "Migrate non-base plugins and modules from the ``ansible/ansible`` repository to smaller collection repositories" -msgstr "ベースでないプラグインとモジュールを ``ansible/ansible`` リポジトリーから小規模なコレクションリポジトリーに移行します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:39 -msgid "Add functionality to ease transition to collections, such as automatic redirects from the 2.9 names to the new FQCN of the plugin" -msgstr "2.9 の名前からプラグインの新しい FQCN への自動リダイレクトなど、コレクションへの移行を容易にする機能を追加します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:40 -msgid "Create new ``ansible-base`` package representing the ``ansible/ansible`` repository" -msgstr "``ansible-base`` リポジトリーを表す新しい ``ansible/ansible`` パッケージを作成します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:43 -msgid "Additional Resources" -msgstr "関連情報" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:45 -msgid "The 2.10 release of Ansible will fundamentally change the scope of plugins included in the ``ansible/ansible`` repository, by moving much of the plugins into smaller collection repositories that will be shipped through https://galaxy.ansible.com/" -msgstr "Ansible の 2.10 リリースでは、プラグインの大半を、https://galaxy.ansible.com/ から同梱する小規模なコレクションリポジトリーに移動することで、``ansible/ansible`` リポジトリーに含まれるプラグインの範囲を基本的に変更します。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:48 -msgid "The following links have more information about this process:" -msgstr "以下のリンクには、このプロセスに関する詳細情報が含まれます。" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:50 -msgid "https://groups.google.com/d/msg/ansible-devel/oKqgCeYTs-M/cHrOgMw8CAAJ" -msgstr "https://groups.google.com/d/msg/ansible-devel/oKqgCeYTs-M/cHrOgMw8CAAJ" - -#: ../../rst/roadmap/ROADMAP_2_10.rst:51 -msgid "https://github.com/ansible-collections/overview/blob/main/README.rst" -msgstr "https://github.com/ansible-collections/overview/blob/main/README.rst" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:5 -msgid "Ansible-core 2.11" -msgstr "Ansible-core 2.11" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:16 ../../rst/roadmap/ROADMAP_2_12.rst:16 -#: ../../rst/roadmap/ROADMAP_2_13.rst:16 ../../rst/roadmap/ROADMAP_2_14.rst:16 -msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release." -msgstr "プル要求は、この ansible-core リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:18 -msgid "There is no Alpha phase in 2.11." -msgstr "2.11 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:21 -msgid "2021-02-12 Feature Freeze No new functionality (including modules/plugins) to any code" -msgstr "2021 年 02 月 12 日 機能フリーズ。コードへの新しい機能 (モジュール/プラグインを含む) はありません。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:24 -msgid "2021-03-02 Beta 1" -msgstr "2021 年 03 月 02 日 Beta 1" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:25 -msgid "2021-03-15 Beta 2 (if necessary)" -msgstr "2021 年 03 月 15 日 Beta 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:27 -msgid "2021-03-29 Release Candidate 1 (and ``stable-2.11`` branching from ``devel``)" -msgstr "2021 年 03 月 29 日 リリース候補 1 (および ``devel`` の ``stable-2.11`` ブランチ)" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:28 -msgid "2021-04-12 Release Candidate 2 (if necessary)" -msgstr "2021 年 04 月 12 日 リリース候補 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:30 -msgid "2021-04-26 Release" -msgstr "2021 年 04 月 26 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:35 ../../rst/roadmap/ROADMAP_2_12.rst:35 -#: ../../rst/roadmap/ROADMAP_2_13.rst:46 ../../rst/roadmap/ROADMAP_2_14.rst:46 -msgid "Ansible Core Team" -msgstr "Ansible Core Team" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:40 -msgid "Rename ``ansible-base`` to ``ansible-core``." -msgstr "``ansible-base`` の名前を ``ansible-core`` に変更します。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:41 -msgid "Improve UX of ``ansible-galaxy collection`` CLI, specifically as it relates to install and upgrade." -msgstr "特にインストールおよびアップグレードに関連する ``ansible-galaxy collection`` CLI の UX が改善されます。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:42 -msgid "Add new Role Argument Spec feature that will allow a role to define an argument spec to be used in validating variables used by the role." -msgstr "ロールが使用する変数の検証に使用する引数の仕様を定義できるように、新規の Role 引数仕様機能を追加します。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:44 -msgid "Bump the minimum Python version requirement for the controller to Python 3.8. There will be no breaking changes to this release, however ``ansible-core`` will only be packaged for Python 3.8+. ``ansible-core==2.12`` will include breaking changes requiring at least Python 3.8." -msgstr "コントローラーの最小 Python バージョン要件を Python 3.8 に上げます。今回のリリースには、重大な変更はありませんが、``ansible-core`` は Python 3.8 以降に対してのみパッケージ化されます。``ansible-core==2.12`` には、Python 3.8 以上を必要とする重大な変更が含まれます。" - -#: ../../rst/roadmap/ROADMAP_2_11.rst:47 ../../rst/roadmap/ROADMAP_2_12.rst:42 -msgid "Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from dependencies on the target." -msgstr "``ansible-test`` に split-controller テストが導入され、コントローラーの依存関係をターゲットの依存関係から分離します。" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:5 -msgid "Ansible-core 2.12" -msgstr "Ansible-core 2.12" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:18 -msgid "There is no Alpha phase in 2.12." -msgstr "2.12 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:21 -msgid "2021-09-24 Feature Freeze (and ``stable-2.12`` branching from ``devel``) No new functionality (including modules/plugins) to any code" -msgstr "2021 年 9 月 24 日 機能フリーズ (``devel`` からの ``stable-2.12`` のブランチ作成)。 (モジュール/プラグインなど)コードに対して新しい機能なし" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:24 -msgid "2021-09-27 Beta 1" -msgstr "2021 年 9 月 27 日 Beta 1" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:25 -msgid "2021-10-04 Beta 2 (if necessary)" -msgstr "2021 年 10 月 4 日 Beta 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:27 -msgid "2021-10-18 Release Candidate 1" -msgstr "2021 年 10 月 18 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:28 -msgid "2021-10-25 Release Candidate 2 (if necessary)" -msgstr "2021 年 10 月 25 日 リリース候補 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:30 -msgid "2021-11-08 Release" -msgstr "2021 年 11 月 8 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:40 -msgid "Bump the minimum Python version requirement for the controller to Python 3.8. This will be a hard requirement." -msgstr "コントローラーの Python バージョンの最小要件を Python 3.8 に変更します。これはハード要件になります。" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:41 -msgid "Deprecate Python 2.6 support for managed/target hosts. The release of ``ansible-core==2.13`` will remove Python 2.6 support." -msgstr "管理/ターゲットホストの Python 2.6 サポートを非推奨にします。``ansible-core==2.13`` のリリースでは、Python 2.6 のサポートが削除されます。" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:43 -msgid "Extend the functionality of ``module_defaults`` ``action_groups`` to be created and presented by collections." -msgstr "コレクションによって作成され、提示されるように ``module_defaults`` ``action_groups`` の機能を拡張します。" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:46 ../../rst/roadmap/ROADMAP_2_13.rst:60 -#: ../../rst/roadmap/ROADMAP_2_14.rst:59 -msgid "Delayed work" -msgstr "作業の遅延" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:48 ../../rst/roadmap/ROADMAP_2_13.rst:62 -msgid "The following work has been delayed and retargeted for a future release" -msgstr "以下の作業は、遅延しており、今後のバージョンを目標にリリースを行うことになりました。" - -#: ../../rst/roadmap/ROADMAP_2_12.rst:50 -msgid "Implement object proxies, to expose restricted interfaces between parts of the code, and enable deprecations of attributes and variables." -msgstr "オブジェクトプロキシーを実装して部分的なコード同士の間でインターフェースを限定し、属性と変数を廃止できるようにします。" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:5 -msgid "Ansible-core 2.13" -msgstr "Ansible-core 2.13" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:18 -msgid "There is no Alpha phase in 2.13." -msgstr "2.13 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:22 ../../rst/roadmap/ROADMAP_2_14.rst:21 -msgid "Development Phase" -msgstr "開発フェーズ" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:24 ../../rst/roadmap/ROADMAP_2_14.rst:23 -msgid "The ``milestone`` branch will be advanced at the start date of each development phase." -msgstr "``milestone`` ブランチは、各開発フェーズの開始日に進められます。" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:26 -msgid "2021-09-27 Development Phase 1" -msgstr "2021 年 9 月 27 日 開発フェーズ 1" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:27 -msgid "2021-12-13 Development Phase 2" -msgstr "2021 年 12 月 13 日 開発フェーズ 2" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:28 -msgid "2022-02-14 Development Phase 3" -msgstr "2022 年 2 月 14 日 開発フェーズ 3" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:31 ../../rst/roadmap/ROADMAP_2_14.rst:30 -msgid "Release Phase" -msgstr "リリースフェーズ" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:33 -msgid "2022-03-28 Feature Freeze (and ``stable-2.13`` branching from ``devel``) No new functionality (including modules/plugins) to any code" -msgstr "2022 年 3 月 28 日 機能フリーズ (``devel`` からの ``stable-2.13`` のブランチ作成)。(モジュール/プラグインなど) コードに対して新しい機能なし" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:36 -msgid "2022-04-11 Beta 1" -msgstr "2022 年 4 月 11 日 Beta 1" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:37 -msgid "2022-04-25 Beta 2 (if necessary)" -msgstr "2022 年 4 月 25 日 Beta 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:39 -msgid "2022-05-02 Release Candidate 1" -msgstr "2022 年 5 月 2 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:41 -msgid "2022-05-16 Release" -msgstr "2022 年 5 月 16 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:51 -msgid "``ansible-doc`` extended dump support for devtools integration" -msgstr "``ansible-doc`` が devtools 統合のためのダンプサポートを拡張" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:52 -msgid "``ansible-galaxy`` CLI collection verification, source, and trust" -msgstr "``ansible-galaxy`` CLI コレクションの検証、ソース、および信頼" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:53 -msgid "``jinja2`` 3.0+ dependency" -msgstr "``jinja2`` 3.0+ 依存関係" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:54 -msgid "Consolidate template handling to always use ``jinja2`` native" -msgstr "常に ``jinja2`` ネイティブを使用するためにテンプレート処理を統合" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:55 -msgid "Drop Python 2.6 support for module execution" -msgstr "モジュール実行の Python 2.6 サポートを削除" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:56 -msgid "Update the collection loader to Python 3.x loader API, due to removal of the Python 2 API in Python 3.12" -msgstr "Python3.12 で Python 2 API が削除されたため、コレクションローダーを Python3.x ローダー API に更新" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:57 -msgid "Modernize python packaging and installation" -msgstr "Python のパッケージ化とインストールを最新化" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:64 ../../rst/roadmap/ROADMAP_2_14.rst:63 -msgid "Data Tagging" -msgstr "データのタグ付け" - -#: ../../rst/roadmap/ROADMAP_2_13.rst:65 ../../rst/roadmap/ROADMAP_2_14.rst:51 -msgid "Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules" -msgstr "フィルター/テストプラグイン、および Python 以外のモジュールのドキュメント化をサポートするサイドカードキュメントを実装" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:5 -msgid "Ansible-core 2.14" -msgstr "Ansible-core 2.14" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:25 -msgid "2022-05-02 Development Phase 1" -msgstr "2022 年 ５ 月 2 日 開発フェーズ 1" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:26 -msgid "2022-06-27 Development Phase 2" -msgstr "2022 年 6 月 27 日 開発フェーズ 2" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:27 -msgid "2022-08-08 Development Phase 3" -msgstr "2022 年 8 月 8 日 開発フェーズ 3" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:32 -msgid "2022-09-19 Feature Freeze (and ``stable-2.14`` branching from ``devel``) No new functionality (including modules/plugins) to any code" -msgstr "2022 年 9 月 19 日 機能フリーズ (``devel`` からの ``stable-2.14`` のブランチ作成)。(モジュール/プラグインなど) コードに対して新しい機能なし" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:35 -msgid "2022-09-26 Beta 1" -msgstr "2022 年 9 月 26 日 Beta 1" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:37 -msgid "2022-10-17 Release Candidate 1" -msgstr "2022 年 10 月 17 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:39 -msgid "2022-11-07 Release" -msgstr "2022 年 11 月 7 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:41 -msgid "The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release." -msgstr "ベータおよびリリース候補のスケジュールでは、リリース作成の必要性に応じて、毎週のスケジュールで最大 3 つリリースできます。" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:52 -msgid "Proxy Display over queue from forks" -msgstr "フォークからのキューのプロキシーディスプレイ" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:53 -msgid "Move handler processing into new PlayIterator phase to use the configured strategy" -msgstr "ハンドラー処理を新しい PlayIterator フェーズに移動し、設定されたストラテジーを使用" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:54 -msgid "Convert FieldAttribute to data descriptors to avoid complex meta classes" -msgstr "FieldAttribute をデータ記述子に変換し、複雑なメタクラスを回避" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:55 -msgid "Drop Python 3.8 support for controller" -msgstr "モジュール実行の Python 3.8 サポートを削除" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:56 -msgid "Enforce running controller code with the Python locale and filesystem encoding set to UTF-8" -msgstr "Python ロケールおよびファイルシステムのエンコーディングを UTF-8 に設定して、コントローラーコードの矯正実行" - -#: ../../rst/roadmap/ROADMAP_2_14.rst:61 -msgid "The following work has been delayed and retargeted for a future release:" -msgstr "以下の作業は、遅延しており、今後のバージョンを目標にリリースを行うことになりました。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:3 -msgid "Ansible 2.5" -msgstr "Ansible 2.5" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:4 -msgid "**Core Engine Freeze and Module Freeze: 22 January 2018**" -msgstr "**コアエンジンのフリーズおよびモジュールのフリーズ: 2018 年 1 月 22 日**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:6 -msgid "**Core and Curated Module Freeze: 22 January 2018**" -msgstr "**コアおよびキューレーションモジュールのフリーズ: 2018 年 1 月 22 日**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:8 -msgid "**Community Module Freeze: 7 February 2018**" -msgstr "**コミュニティーモジュールのフリーズ: 2018 年 2 月 7 日**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:10 -msgid "**Release Candidate 1 will be 21 February, 2018**" -msgstr "**リリース候補 1 は 2018 年 2 月 21 日です。**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:12 -msgid "**Target: March 2018**" -msgstr "**ターゲット: 2018 年 3 月**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:14 -msgid "**Service Release schedule: every 2-3 weeks**" -msgstr "**サービスリリーススケジュール: 2 ~ 3 週間ごと**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:16 ../../rst/roadmap/ROADMAP_2_6.rst:5 -#: ../../rst/roadmap/ROADMAP_2_7.rst:5 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:20 -msgid "Matt Davis (IRC/GitHub: @nitzmahone)" -msgstr "Matt Davis (IRC/GitHub: @nitzmahone)" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:24 ../../rst/roadmap/ROADMAP_2_6.rst:33 -msgid "Engine improvements" -msgstr "エンジンの改善" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:25 -msgid "Assemble module improvements - assemble just skips when in check mode, it should be able to test if there is a difference and changed=true/false. - The same with diff, it should work as template modules does" -msgstr "assemble モジュールの改善 - チェックモードでは assemble はスキップするだけで、違いがあり、変更があるかどうかをテストできます (true/false)。diff と同じように、テンプレートモジュールと同じように機能するはずです。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:28 -msgid "Handle Password reset prompts cleaner" -msgstr "パスワードリセットプロンプトクリーナーの処理" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:29 -msgid "Tasks stats for rescues and ignores" -msgstr "rescue および ignore のタスク統計" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:30 -msgid "Normalize temp dir usage across all subsystems" -msgstr "すべてのサブシステムで一時ディレクトリーの使用を正規化" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:31 -msgid "Add option to set playbook dir for adhoc, inventory and console to allow for 'relative path loading'" -msgstr "アドホック、インベントリー、およびコンソールに Playbook ディレクトリーを設定して、「相対パスの読み込み」を可能にするオプションを追加します" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:35 -msgid "Ansible-Config" -msgstr "Ansible-Config" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:36 -msgid "Extend config to more plugin types and update plugins to support the new config" -msgstr "設定を他のプラグインタイプに拡張し、新しい設定をサポートするようにプラグインを更新します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:39 -msgid "Inventory" -msgstr "インベントリー" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:40 -msgid "ansible-inventory option to output group variable assignment and data (--export)" -msgstr "グループ変数の割り当ておよびデータを出力する ansible-inventory オプション (--export)" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:41 -msgid "Create inventory plugins for: - aws" -msgstr "- aws にインベントリープラグインを作成します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:45 -msgid "Facts" -msgstr "ファクト" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:46 -msgid "Namespacing fact variables (via a config option) implemented in ansible/ansible PR `#18445 `_. Proposal found in ansible/proposals issue `#17 `_." -msgstr "ansible/ansible のプル要求に実装されたファクト変数 (設定オプション経由) の名前空間 (`#18445 `_)。ansible/proposals 問題に表示される提案 (`#17 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:48 -msgid "Make fact collectors and gather_subset specs finer grained" -msgstr "ファクトコレクターと gather_subset の仕様をより詳細にする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:49 -msgid "Eliminate unneeded deps between fact collectors" -msgstr "ファクトコレクター間の不要なデッドを排除する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:50 -msgid "Allow fact collectors to indicate if they need information from another fact collector to be gathered first." -msgstr "ファクトコレクターは、別のファクトコレクターからの情報を最初に収集する必要があるかどうかを示すことができるようにします。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:53 -msgid "Static Loop Keyword" -msgstr "静的ループキーのパスワード" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:55 -msgid "A simpler alternative to ``with_``, ``loop:`` only takes a list" -msgstr "``with_`` のより簡単な代替方法としては、``loop:`` はリストのみを使用します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:56 -msgid "Remove complexity from loops, lookups are still available to users" -msgstr "ループから複雑性を削除し、ユーザーは、引き続き検索を利用できます。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:57 -msgid "Less confusing having a static directive vs a one that is dynamic depending on plugins loaded." -msgstr "読み込まれたプラグインに応じて動的なディレクティブと比較して、静的なディレクティブを持つことで混乱が少なくなります。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:60 -msgid "Vault" -msgstr "Vault" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:61 -msgid "Vault secrets client inc new 'keyring' client" -msgstr "新しい「キーリング」クライアントを含む Vault シークレットクライアント" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:64 -msgid "Runtime Check on Modules for Disabling" -msgstr "無効にするモジュールのランタイムチェック" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:65 -msgid "Filter on things like \"supported_by\" in module metadata" -msgstr "モジュールメタデータに「supported_by」などの内容にフィルタリングする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:66 -msgid "Provide users with an option of \"warning, error or allow/ignore\"" -msgstr "「warning, error or allow/ignore」のオプションをユーザーに指定する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:67 -msgid "Configurable via ansible.cfg and environment variable" -msgstr "ansible.cfg および環境変数を使用して設定可能に" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:70 ../../rst/roadmap/ROADMAP_2_6.rst:78 -#: ../../rst/roadmap/ROADMAP_2_7.rst:94 -msgid "Windows" -msgstr "Windows" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:71 -msgid "Implement gather_subset on Windows facts" -msgstr "Windows ファクトへの gather_subset の実装" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:72 -msgid "Fix Windows async + become to allow them to work together" -msgstr "Windows の非同期を修正し、それらが連携できるようにする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:73 -msgid "Implement Windows become flags for controlling various modes **(done)** - logontype - elevation behavior" -msgstr "さまざまなモードを制御するための Windows の become フラグを実装する **(完了)** - logontype - elevation behavior" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:76 -msgid "Convert win_updates to action plugin for auto reboot and extra features **(done)**" -msgstr "自動再起動および追加機能の Win_updates からアクションプラグインに変換する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:77 -msgid "Spike out changing the connection over to PSRP instead of WSMV **(done- it's possible)**" -msgstr "接続を WSMV ではなく PSRP に変更することを明確にする **(完了 - 可能)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:78 -msgid "Module updates" -msgstr "モジュールの更新" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:80 -msgid "win_updates **(done)**" -msgstr "win_updates **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:82 -msgid "Fix win_updates to detect (or request) become" -msgstr "become を検出 (または要求) するように win_updates を修正する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:83 -msgid "Add enable/disable features to win_updates" -msgstr "win_updates に有効化/無効化機能を追加する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:84 -msgid "win_dsc further improvements **(done)**" -msgstr "win_dsc をさらに改善する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:87 -msgid "General Cloud" -msgstr "一般クラウド" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:88 -msgid "Make multi-cloud provisioning easier" -msgstr "マルチクラウドのプロビジョニングを容易にする" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:89 -msgid "Diff mode will output provisioning task results of ansible-playbook runs" -msgstr "diff モードは、ansible-playbook の実行のプロビジョニングタスク結果を出力する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:90 -msgid "Terraform module" -msgstr "Terraform モジュール" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:93 ../../rst/roadmap/ROADMAP_2_7.rst:62 -msgid "AWS" -msgstr "AWS" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:94 -msgid "Focus on pull requests for various modules" -msgstr "さまざまなモジュールのプル要求に焦点" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:95 -msgid "Triage existing merges for modules" -msgstr "モジュールの既存マージの優先順位付け" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:96 -msgid "Module work" -msgstr "モジュール作業" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:98 -msgid "ec2_instance" -msgstr "ec2_instance" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:99 -msgid "ec2_vpc: Allow the addition of secondary IPv4 CIDRS to existing VPCs." -msgstr "ec2_vpc: 既存の VPC へのセカンダリー IPv4 CIDRS の追加を許可します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:100 -msgid "AWS Network Load Balancer support (NLB module, ASG support, and so on)" -msgstr "AWS Network Load Balancer サポート (NLB モジュール、ASG サポートなど)" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:101 -msgid "rds_instance" -msgstr "rds_instance" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:104 ../../rst/roadmap/ROADMAP_2_7.rst:71 -msgid "Azure" -msgstr "Azure" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:105 -msgid "Azure CLI auth **(done)**" -msgstr "Azure CLI 認証 **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:106 -msgid "Fix Azure module results to have \"high-level\" output instead of raw REST API dictionary **(partial, more to come in 2.6)**" -msgstr "生の REST API ディレクトリーではなく「高レベル」の出力を表示するように Azure モジュールの結果を修正する **(部分的。2.6 でさらに追加予定)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:107 -msgid "Deprecate Azure automatic storage accounts in azure_rm_virtualmachine **(breaks on Azure Stack, punted until AS supports managed disks)**" -msgstr "azure_rm_virtualmachine の Azure 自動ストレージアカウントを非推奨に **(Azure Stack で中断。AS が管理対象ディスクをサポートするまで保留)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:110 -msgid "Network Roadmap" -msgstr "ネットワークのロードマップ" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:111 -msgid "Refactor common network shared code into package **(done)**" -msgstr "共通ネットワーク共有コードをパッケージにリファクタリングする **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:112 -msgid "Convert various nxos modules to use declarative intent **(done)**" -msgstr "さまざまな nxos モジュールを変換し、宣言的推論 **(完了)** を活用" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:113 -msgid "Refactor various modules to use the cliconf plugin **(done)**" -msgstr "cliconf プラグインを活用するために各種モジュールをリファクタリングする **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:114 -msgid "Add various missing declarative modules for supported platforms and functions **(done)**" -msgstr "サポートされるプラットフォームおよび機能用に、不足しているさまざまな宣言型モジュールを追加する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:115 -msgid "Implement a feature that handles platform differences and feature unavailability **(done)**" -msgstr "プラットフォームの違いと機能の利用不可に対応する機能を実装する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:116 -msgid "netconf-config.py should provide control for deployment strategy" -msgstr "netconf-config.py がデプロイメントストラテジーの制御を提供する必要がある" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:117 -msgid "Create netconf connection plugin **(done)**" -msgstr "netconf connection プラグインを作成する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:118 -msgid "Create netconf fact module" -msgstr "netconf ファクトモジュールを作成する" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:119 -msgid "Turn network_cli into a usable connection type **(done)**" -msgstr "network_cli を使用可能な接続タイプに変換する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:120 -msgid "Implements jsonrpc message passing for ansible-connection **(done)**" -msgstr "ansible-connection に渡す jsonrpc メッセージを実装する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:121 -msgid "Improve logging for ansible-connection **(done)**" -msgstr "ansible-connection のロギングを改善する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:122 -msgid "Improve stdout output for failures whilst using persistent connection **(done)**" -msgstr "永続的な接続の使用中に傷害が発生した場合の stdout 出力を改善する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:123 -msgid "Create IOS-XR NetConf Plugin and refactor iosxr modules to use netconf plugin **(done)**" -msgstr "IOS-XR NetConf プラグインを作成し、iosxr モジュールをリファクタリングして netconf プラグインを活用する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:124 -msgid "Refactor junos modules to use netconf plugin **(done)**" -msgstr "netconf プラグインを使用するように junos モジュールをリファクタリングする **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:125 -msgid "Filters: Add a filter to convert XML response from a network device to JSON object **(done)**" -msgstr "フィルター: XML 応答をネットワークデバイスから JSON オブジェクトに変換するフィルターを追加する **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:128 -msgid "Documentation" -msgstr "ドキュメント" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:129 -msgid "Extend documentation to more plugins" -msgstr "ドキュメントを他のプラグインへ拡張" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:130 -msgid "Document vault-password-client scripts." -msgstr "vault-password-client スクリプトを文書化します。" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:131 -msgid "Network Documentation" -msgstr "ネットワークドキュメント" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:133 -msgid "New landing page (to replace intro_networking) **(done)**" -msgstr "新しいランディングページ (intro_networking を置き換えるため) **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:134 -msgid "Platform specific guides **(done)**" -msgstr "プラットフォーム固有のガイド **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:135 -msgid "Walk through: Getting Started **(done)**" -msgstr "ウォークスルー: はじめに **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:136 -msgid "Networking and ``become`` **(done)**" -msgstr "ネットワークおよび ``become`` **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:137 -msgid "Best practice **(done)**" -msgstr "ベストプラクティス **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:140 -msgid "Contributor Quality of Life" -msgstr "貢献者の生活の質" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:141 -msgid "Finish PSScriptAnalyer integration with ansible-test (for enforcing Powershell style) **(done)**" -msgstr "PSScriptAnalyer と ansible-test の統合を完了する (Powershell スタイルを適用するため) **(完了)**" - -#: ../../rst/roadmap/ROADMAP_2_5.rst:142 -msgid "Resolve issues requiring skipping of some integration tests on Python 3." -msgstr "Python 3 で一部の統合テストをスキップする必要がある問題を解決する。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:3 -msgid "Ansible 2.6" -msgstr "Ansible 2.6" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:11 -msgid "Actual" -msgstr "実績" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:13 -msgid "2018-05-17 Core Freeze (Engine and Core Modules/Plugins)" -msgstr "2018 年 05 月 17 日 コアフリーズ (Engine および Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:14 -msgid "2018-05-21 Alpha Release 1" -msgstr "2018 年 05 月 21 日 Alpha リリース 1" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:15 -msgid "2018-05-25 Community Freeze (Non-Core Modules/Plugins)" -msgstr "2018 年 05 月 25 日 コミュニティーフリーズ (非 Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:16 -msgid "2018-05-25 Branch stable-2.6" -msgstr "2018 年 05 月 25 日 ブランチの stable-2.6" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:17 -msgid "2018-05-30 Alpha Release 2" -msgstr "2018 年 05 月 30 日 Ahpha リリース 2" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:18 -msgid "2018-06-05 Release Candidate 1" -msgstr "2018 年 06 月 05 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:19 -msgid "2018-06-08 Release Candidate 2" -msgstr "2018 年 06 月 08 日 リリース候補 2" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:20 -msgid "2018-06-18 Release Candidate 3" -msgstr "2018 年 06 月 18 日 リリース候補 3" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:21 -msgid "2018-06-25 Release Candidate 4" -msgstr "2018 年 06 月 25 日 リリース候補 4" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:22 -msgid "2018-06-26 Release Candidate 5" -msgstr "2018 年 06 月 26 日 リリース候補 5" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:23 -msgid "2018-06-28 Final Release" -msgstr "2018 年 06 月 28 日 最終リリース" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:28 -msgid "2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay)" -msgstr "2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:29 -msgid "2.6.13+ Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger)" -msgstr "2.6.13+ Toshio Kuratomi (IRC: abadger1999、GitHub: @abadger)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:35 -msgid "Version 2.6 is largely going to be a stabilization release for Core code." -msgstr "バージョン 2.6 は、主に Core コード用の安定版リリースになります。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:36 -msgid "Some of the items covered in this release, but are not limited to are the following:" -msgstr "一部の項目は、本リリースで説明されていますが、以下に限定されません。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:38 -msgid "``ansible-inventory``" -msgstr "``ansible-inventory``" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:39 -msgid "``import_*``" -msgstr "``import_*``" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:40 -msgid "``include_*``" -msgstr "``include_*``" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:41 -msgid "Test coverage" -msgstr "テストカバレッジ" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:42 -msgid "Performance Testing" -msgstr "パフォーマンステスト" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:45 ../../rst/roadmap/ROADMAP_2_7.rst:44 -msgid "Core Modules" -msgstr "コアモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:46 -msgid "Adopt-a-module Campaign" -msgstr "adopt-a-module キャンペーン" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:48 -msgid "Review current status of all Core Modules" -msgstr "すべての Core モジュールの現在の状態の確認" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:49 -msgid "Reduce backlog of open issues against these modules" -msgstr "これらのモジュールに対してオープン問題のバックログを減らす" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:52 ../../rst/roadmap/ROADMAP_2_7.rst:55 -msgid "Cloud Modules" -msgstr "クラウドモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:55 ../../rst/roadmap/ROADMAP_2_7.rst:77 -msgid "Network" -msgstr "ネットワーク" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:58 -msgid "Connection work" -msgstr "接続作業" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:60 -msgid "New connection plugin: eAPI `proposal#102 `_" -msgstr "新規 connection プラグイン: eAPI (`proposal#102 `_)" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:61 -msgid "New connection plugin: NX-API" -msgstr "新規 connection プラグイン: NX-API" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:62 -msgid "Support for configurable options for network_cli & netconf" -msgstr "network_cli & netconf の設定可能なオプションのサポート" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:65 ../../rst/roadmap/ROADMAP_2_7.rst:87 -#: ../../rst/roadmap/ROADMAP_2_7.rst:102 -msgid "Modules" -msgstr "モジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:67 -msgid "New ``net_get`` - platform independent module for pulling configuration via SCP/SFTP over network_cli" -msgstr "新しい ``net_get`` - network_cli 経由で SCP/SFTP を介して設定をプルするプラットフォームに依存しないモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:68 -msgid "New ``net_put`` - platform independent module for pushing configuration via SCP/SFTP over network_cli" -msgstr "新しい ``net_put`` - network_cli 経由で SCP/SFTP を介して設定をプッシュするプラットフォームに依存しないモジュール" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:69 -msgid "New ``netconf_get`` - Netconf module to fetch configuration and state data `proposal#104 `_" -msgstr "新しい ``netconf_get`` - 設定および状態データを取得する Netconf モジュール (`proposal#104 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:72 -msgid "Other Features" -msgstr "その他の機能" - -#: ../../rst/roadmap/ROADMAP_2_6.rst:74 -msgid "Stretch & tech preview: Configuration caching for network_cli. Opt-in feature to avoid ``show running`` performance hit" -msgstr "ストレッチおよびテクノロジープレビュー: network_cli の構成キャッシュ。``show running`` パフォーマンスヒットを回避するオプトイン機能" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:3 -msgid "Ansible 2.7" -msgstr "Ansible 2.7" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:13 -msgid "2018-08-23 Core Freeze (Engine and Core Modules/Plugins)" -msgstr "2018 年 08 月 23 日 コアフリーズ (Engine および Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:14 -msgid "2018-08-23 Alpha Release 1" -msgstr "2018 年 08 月 23 日 Ahpha リリース 1" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:15 -msgid "2018-08-30 Community Freeze (Non-Core Modules/Plugins)" -msgstr "2018 年 08 月 30 日 コミュニティーフリーズ (非 Core モジュール/プラグイン)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:16 -msgid "2018-08-30 Beta Release 1" -msgstr "2018 年 08 月 30 日 Beta リリース 1" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:17 -msgid "2018-09-06 Release Candidate 1 (If needed)" -msgstr "2018 年 09 月 06 日 リリース候補 1 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:18 -msgid "2018-09-13 Release Candidate 2 (If needed)" -msgstr "2018 年 09 月 13日 リリース候補 2 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:19 -msgid "2018-09-20 Release Candidate 3 (If needed)" -msgstr "2018 年 09 月 20 日 リリース候補 3 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:20 -msgid "2018-09-27 Release Candidate 4 (If needed)" -msgstr "2018 年 09 月 27日 リリース候補 4 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:21 -msgid "2018-10-04 General Availability" -msgstr "2018 年 10 月 04 日 一般提供 (GA)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:25 ../../rst/roadmap/ROADMAP_2_8.rst:33 -msgid "Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger)" -msgstr "Toshio Kuratomi (IRC: abadger1999、GitHub: @abadger)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:29 -msgid "Cleaning Duty" -msgstr "責務の消去" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:31 -msgid "Drop Py2.6 for controllers `Docs PR #42971 `_ and `issue #42972 `_" -msgstr "コントローラー `Docs PR #42971 `_ および `issue #42972 `_ の場合は、Py2.6 を破棄します。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:33 -msgid "Remove dependency on simplejson `issue #42761 `_" -msgstr "simplejson `issue #42761 `_ の依存関係を削除します。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:37 -msgid "Engine Improvements" -msgstr "エンジンの改善" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:39 -msgid "Performance improvement invoking Python modules `pr #41749 `_" -msgstr "Python モジュール `pr #41749 `_ を呼び出すパフォーマンスが向上しました。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:40 -msgid "Jinja native types will allow for users to render a Python native type. `pr #32738 `_" -msgstr "Jinja ネイティブタイプを使用すると、ユーザーは Python ネイティブタイプをレンダリングできます (`pr #32738 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:46 -msgid "Include feature changes and improvements" -msgstr "機能変更および改善の追加" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:48 -msgid "Create new argument ``apply`` that will allow for included tasks to inherit explicitly provided attributes. `pr #39236 `_" -msgstr "含まれるタスクが明示的に指定した属性を継承するように、新しい引数 ``apply`` を作成します (`pr #39236 `)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:49 -msgid "Create \"private\" functionality for allowing vars/default to be exposed outside of roles. `pr #41330 `_" -msgstr "ロール外に vars/default が公開されるように「プライベート」機能を作成します (`pr #41330 `)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:50 -msgid "Provide a parameter for the ``template`` module to output to different encoding formats `pr #42171 `_" -msgstr "``template`` モジュールが、異なるエンコーディング形式に出力するパラメーターを提供します (`pr #42171 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:52 -msgid "``reboot`` module for Linux hosts (@samdoran) `pr #35205 `_" -msgstr "Linux ホストの ``reboot`` モジュール (@samdoran) (`pr #35205 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:58 ../../rst/roadmap/ROADMAP_2_7.rst:80 -#: ../../rst/roadmap/ROADMAP_2_7.rst:97 -msgid "General" -msgstr "全般" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:59 -msgid "Cloud auth plugin `proposal #24 `_" -msgstr "クラウド認証プラグイン (`proposal #24 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:63 -msgid "Inventory plugin for RDS `pr #41919 `_" -msgstr "RDS のインベントリープラグイン (`pr #41919 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:64 -msgid "Count support for `ec2_instance`" -msgstr "`ec2_instance` のカウントサポート" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:65 -msgid "`aws_eks` module `pr #41183 `_" -msgstr "`aws_eks` モジュール `pr #41183 `_" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:66 -msgid "Cloudformation stack sets support (`PR#41669 `_)" -msgstr "CloudFormation スタックセットのサポート (`PR#41669 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:67 -msgid "RDS instance and snapshot modules `pr #39994 `_ `pr #43789 `_" -msgstr "RDS インスタンスおよびスナップショットモジュール (`pr #39994 `_ `pr #43789 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:68 -msgid "Diff mode improvements for cloud modules `pr #44533 `_" -msgstr "クラウドモジュールの diff モードが改善 (`pr #44533 `)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:73 -msgid "Azure inventory plugin `issue #42769 `__" -msgstr "Azure インベントリープラグイン (`issue #42769 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:82 -msgid "Refactor the APIs in cliconf (`issue #39056 `_) and netconf (`issue #39160 `_) plugins so that they have a uniform signature across supported network platforms. **done** (`PR #41846 `_) (`PR #43643 `_) (`PR #43837 `_) (`PR #43203 `_) (`PR #42300 `_) (`PR #44157 `_)" -msgstr "サポートされているネットワークプラットフォーム全体で統一された署名を持つように cliconf (`issue #39056 `_) プラグインおよび netconf (`issue #39160 `_) プラグインで API をリファクタリングする。**完了** (`PR #41846 `_) (`PR #43643 `_) (`PR #43837 `_) (`PR #43203 `_) (`PR #42300 `_) (`PR #44157 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:89 -msgid "New ``cli_config`` module `issue #39228 `_ **done** `PR #42413 `_." -msgstr "新しい ``cli_config`` モジュール (`issue #39228 `_ **完了** (`PR #42413 `_))。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:90 -msgid "New ``cli_command`` module `issue #39284 `_" -msgstr "新しい ``cli_command`` モジュール (`issue #39284 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:91 -msgid "Refactor ``netconf_config`` module to add additional functionality. **done** `proposal #104 `_ (`PR #44379 `_)" -msgstr "``netconf_config`` モジュールをリファクタリングして、追加機能を追加する **完了** (`proposal #104 `_ (`PR #44379 `_))" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:99 -msgid "Added new connection plugin that uses PSRP as the connection protocol `pr #41729 `__" -msgstr "PSRP を接続プロトコルとして使用する新規 connection プラグインを追加する (`pr #41729 `_)。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:104 -msgid "Revamp Chocolatey to fix bugs and support offline installation `pr #43013 `_." -msgstr "Chocolatey を改良してバグを修正し、オフラインインストールをサポートする (`pr #43013 `_)" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:105 -msgid "Add Chocolatey modules that can manage the following Chocolatey features" -msgstr "以下の Chocolatey 機能を管理できる Chocolatey モジュールを追加する。" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:107 -msgid "`Sources `_ `pr #42790 `_" -msgstr "`Sources `_ `pr #42790 `_" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:108 -msgid "`Features `_ `pr #42848 `_" -msgstr "`Features `_ `pr #42848 `_" - -#: ../../rst/roadmap/ROADMAP_2_7.rst:109 -msgid "`Config `_ `pr #42915 `_" -msgstr "`Config `_ `pr #42915 `_" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:3 -msgid "Ansible 2.8" -msgstr "Ansible 2.8" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:14 ../../rst/roadmap/ROADMAP_2_9.rst:14 -msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release." -msgstr "プル要求は、この Ansible リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:16 -msgid "2019-04-04 Alpha 1 **Core freeze** No new features to ``support:core`` code. Includes no new options to existing Core modules" -msgstr "2019 年 04 月 04 日 Alpha 1 **コアフリーズ** ``support:core`` コードへの新機能はありません。既存のコアモジュールに新しいオプションは含まれません。" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:20 -msgid "2019-04-11 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code" -msgstr "2019 年 04 月 11 日 ベータ 1 ** 機能フリーズ** いずれのコードへの新機能なし (モジュール/プラグインを含む)" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:23 -msgid "2019-04-25 Release Candidate 1" -msgstr "2019 年 04 月 25 日 リリース候補 1" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:24 -msgid "2019-05-02 Release Candidate 2" -msgstr "2019 年 05 月 02 日 リリース候補 2" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:25 -msgid "2019-05-10 Release Candidate 3" -msgstr "2019 年 05 月 10 日 リリース候補 3" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:26 -msgid "2019-05-16 Release" -msgstr "2019 年 05 月 16 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_8.rst:38 -msgid "See the `Ansible 2.8 Project Board `_" -msgstr "「`Ansible 2.8 Project Board `_」を参照してください。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:3 -msgid "Ansible 2.9" -msgstr "Ansible 2.9" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:16 -msgid "There is no Alpha phase in 2.9." -msgstr "2.9 には、Alpha フェーズはありません。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:18 -msgid "2019-08-29 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code" -msgstr "2019 年 08 月 29 日 Beta 1 **機能フリーズ** どのコードにも新しい機能 (モジュール、プラグインなど) はありません。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:21 -msgid "2019-09-19 Release Candidate 1" -msgstr "2019 年 09 月 19 日 リリースの候補 1" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:22 -msgid "2019-10-03 Release Candidate 2" -msgstr "2019 年 10 月 03 日 リリースの候補 2" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:23 -msgid "2019-10-10 Release Candidate 3" -msgstr "2019 年 10 月 10 日 リリースの候補 3" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:24 -msgid "2019-10-17 Release Candidate 4 (if needed)" -msgstr "2019 年 10 月 17 日 リリースの候補 4 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:25 -msgid "2019-10-24 Release Candidate 5 (if needed)" -msgstr "2019 年 10 月 24 日 リリースの候補 5 (必要な場合)" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:26 -msgid "2019-10-31 Release" -msgstr "2019 年 10 月 31 日 リリース" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:32 -msgid "TBD" -msgstr "TBD" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:34 -msgid "Temporarily, Matt Davis (@nitzmahone) or Matt Clay (@mattclay) on IRC or github." -msgstr "IRC または github で、暫定的に Matt Davis (@nitzmahone) または Matt Clay (@mattclay) が担当しています。" - -#: ../../rst/roadmap/ROADMAP_2_9.rst:39 -msgid "See the `Ansible 2.9 Project Board `_" -msgstr "「`Ansible 2.9 Project Board `_」を参照してください。" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:5 -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:23 -msgid "ansible-core Roadmaps" -msgstr "ansible-core ロードマップ" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:7 -msgid "The ``ansible-core`` team develops a roadmap for each major and minor ``ansible-core`` release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not." -msgstr "``ansible-core`` チームは、``ansible-core`` の各メジャーリリースとマイナーリリースのロードマップを開発しています。最新のロードマップは現在の作業を示し、古いロードマップはプロジェクトの履歴を示します。サブマイナーバージョンのロードマップは公開していません。2.10 と 2.11 にはロードマップがありますが、2.10.1 にはありません。" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:9 -#: ../../rst/roadmap/ansible_roadmap_index.rst:9 -msgid "We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions." -msgstr "各ロードマップにチームとコミュニティーのフィードバックを組み込むことで、コミュニティーの要望と提供されたものをより多く追加し、透明性もより高いものにすることを目指しています。" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:11 -msgid "Each roadmap offers a *best guess*, based on the ``ansible-core`` team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on." -msgstr "各ロードマップは、``ansible-core`` チームの経験とコミュニティーからの要求やフィードバックに基づいて、特定のリリースに何が含まれるかについて *最良の推測* を提供します。ただし、ロードマップの一部の項目は、時間的制約、コミュニティーのメンテナー不足などのために削除される場合があります。" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:13 -msgid "Each roadmap is published both as an idea of what is upcoming in ``ansible-core``, and as a medium for seeking further feedback from the community." -msgstr "各ロードマップは、``ansible-core`` の今後の予定、およびコミュニティーからのフィードバックを募る媒体として公開されています。" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:15 -#: ../../rst/roadmap/ansible_roadmap_index.rst:15 -msgid "You can submit feedback on the current roadmap in multiple ways:" -msgstr "現在のロードマップに関するフィードバックは、複数の方法で送信できます。" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:17 -msgid "Edit the agenda of an `Core Team Meeting `_ (preferred)" -msgstr "`Core Team Meeting `_ の議題を編集 (推奨)" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:18 -msgid "Post on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)" -msgstr "``#ansible-devel`` チャットチャンネルに投稿（ansible.im の表を使用するか、`irc.libera.chat `_ で IRC を使用）" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:19 -msgid "Email the ansible-devel list" -msgstr "ansible-devel リストへのメール送信" - -#: ../../rst/roadmap/ansible_core_roadmap_index.rst:21 -msgid "See :ref:`Ansible communication channels ` for details on how to join and use the email lists and chat channels." -msgstr "メーリングリストおよびチャットチャンネルに参加して使用する方法は、「:ref:`Ansible communication channels `」を参照してください。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:22 -msgid "Ansible Release Roadmaps" -msgstr "Ansible リリースロードマップ" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:5 -msgid "Ansible Roadmap" -msgstr "Ansible ロードマップ" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:7 -msgid "The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not." -msgstr "Ansible チームは、Ansible の各メジャーリリースとマイナーリリースのロードマップを開発しています。最新のロードマップは現在の作業を示し、古いロードマップはプロジェクトの履歴を示します。サブマイナーバージョンのロードマップは公開していません。2.10 と 2.11 にはロードマップがありますが、2.10.1 にはありません。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:11 -msgid "Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on." -msgstr "各ロードマップは、Ansible チームの経験とコミュニティーからの要求やフィードバックに基づいて、特定のリリースに何が含まれるかについて *最良の推測* を提供します。ただし、ロードマップの一部の項目は、時間的制約、コミュニティーのメンテナー不足などのために削除される場合があります。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:13 -msgid "Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community." -msgstr "各ロードマップは、Ansible の今後の予定、およびコミュニティーからのフィードバックを募る媒体として公開されています。" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:17 -msgid "Edit the agenda of an `Ansible Community Meeting `_ (preferred)" -msgstr "`Ansible Community Meeting `_ の議題を編集 (推奨)" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:18 -msgid "Post on the ``#ansible-community`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_)" -msgstr "``#ansible-community`` チャットチャンネルに投稿（ansible.im の表を使用するか、`irc.libera.chat `_ で IRC を使用）" - -#: ../../rst/roadmap/ansible_roadmap_index.rst:20 -msgid "See :ref:`Ansible communication channels ` for details on how to join and use our chat channels." -msgstr "チャットチャンネルに参加して使用する方法は、「:ref:`Ansible communication channels `」を参照してください。" - -#: ../../rst/roadmap/index.rst:4 -msgid "Roadmaps" -msgstr "ロードマップ" - -#: ../../rst/roadmap/old_roadmap_index.rst:4 -#: ../../rst/roadmap/old_roadmap_index.rst:10 -msgid "Older Roadmaps" -msgstr "古いロードマップ" - -#: ../../rst/roadmap/old_roadmap_index.rst:6 -msgid "Older roadmaps are listed here to provide a history of the Ansible project." -msgstr "Ansible プロジェクトの履歴は、以下に示す以前のロードマップから確認できます。" - -#: ../../rst/roadmap/old_roadmap_index.rst:8 -msgid "See :ref:`roadmaps` to find current Ansible and ``ansible-base`` roadmaps." -msgstr "現在の Ansible および ``ansible-base`` のロードマップを確認するには、「:ref:`roadmaps`」を参照してください。" - -#~ msgid "The rough schedule for Ansible-2.11 and beyond (such as how many months we'll aim for between versions) is still to be discussed and likely will be made after 2.10.0 has been released." -#~ msgstr "Ansible-2.11 以降の大まかなスケジュール (バージョン間の目標数など) は依然として検討されており、2.10.0 のリリース後に行われる可能性があります。" - -#~ msgid "New Collections will be reviewed for inclusion in Ansible 4." -#~ msgstr "新しいコレクションは、Ansible 4 に含まれるようにレビューされています。" - -#~ msgid "Ansible renamed ``ansible-base`` to ``ansible-core``." -#~ msgstr "Ansible の名前は ``ansible-base`` から ``ansible-core`` に変更しました。" - -#~ msgid "Post on the ``#ansible-devel`` Freenode IRC channel" -#~ msgstr "Freenode IRC チャンネル ``#ansible-devel`` で発言" - -#~ msgid "Post on the ``#ansible-community`` Freenode IRC channel" -#~ msgstr "Freenode IRC チャンネル ``#ansible-community`` で発言" - -#~ msgid "2022-10-18" -#~ msgstr "2022-10-18" - -#~ msgid "Ansible-7.0.0 release." -#~ msgstr "Ansible-7.0.0 リリース" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/scenario_guides.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/scenario_guides.po deleted file mode 100644 index 156f5bc4057..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/scenario_guides.po +++ /dev/null @@ -1,7209 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) 2019 Red Hat, Inc. -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2021. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2023-03-01 20:16+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.9.0\n" - -#: ../../rst/scenario_guides/cloud_guides.rst:5 -#: ../../rst/scenario_guides/guides.rst:17 -msgid "Legacy Public Cloud Guides" -msgstr "従来のパブリッククラウドガイド" - -#: ../../rst/scenario_guides/cloud_guides.rst:7 -msgid "The legacy guides in this section may be out of date. They cover using Ansible with a range of public cloud platforms. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "本セクションの従来のガイドは、情報が古くなっている可能性があります。ガイドでは、さまざまなパブリッククラウドプラットフォームでの Ansible の使用を説明します。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/cloud_guides.rst:9 -msgid "Guides for using public clouds are moving into collections. We are migrating these guides into collections. Please update your links for the following guides:" -msgstr "パブリッククラウド使用のガイドは、コレクションに移されています。これらのガイドをコレクションに移行しています。以下のガイドのリンクを更新してください。" - -#: ../../rst/scenario_guides/cloud_guides.rst:11 -#: ../../rst/scenario_guides/guides.rst:15 -msgid ":ref:`ansible_collections.amazon.aws.docsite.aws_intro`" -msgstr ":ref:`ansible_collections.amazon.aws.docsite.aws_intro`" - -#: ../../rst/scenario_guides/guide_aci.rst:4 -msgid "Cisco ACI Guide" -msgstr "Cisco ACI ガイド" - -#: ../../rst/scenario_guides/guide_aci.rst:10 -msgid "What is Cisco ACI ?" -msgstr "Cisco ACI とは" - -#: ../../rst/scenario_guides/guide_aci.rst:13 -msgid "Application Centric Infrastructure (ACI)" -msgstr "ACI (Application Centric Infrastructure)" - -#: ../../rst/scenario_guides/guide_aci.rst:14 -msgid "The Cisco Application Centric Infrastructure (ACI) allows application requirements to define the network. This architecture simplifies, optimizes, and accelerates the entire application deployment life cycle." -msgstr "ACI (Cisco Application Centric Infrastructure) を使用すると、アプリケーション要件でネットワークを定義できます。このアーキテクチャーは、アプリケーションのデプロイメントライフサイクル全体を単純化し、最適化し、高速化します。" - -#: ../../rst/scenario_guides/guide_aci.rst:18 -msgid "Application Policy Infrastructure Controller (APIC)" -msgstr "APIC (Application Policy Infrastructure Controller)" - -#: ../../rst/scenario_guides/guide_aci.rst:19 -msgid "The APIC manages the scalable ACI multi-tenant fabric. The APIC provides a unified point of automation and management, policy programming, application deployment, and health monitoring for the fabric. The APIC, which is implemented as a replicated synchronized clustered controller, optimizes performance, supports any application anywhere, and provides unified operation of the physical and virtual infrastructure." -msgstr "APIC は、スケーラブルな ACI マルチテナントファブリックを管理します。APIC は、ファブリックの自動化と管理、ポリシープログラミング、アプリケーションのデプロイメント、ヘルスモニタリングの統合ポイントを提供します。APIC は、複製された同期クラスターコントローラーとして実装され、パフォーマンスを最適化し、任意のアプリケーションをどこでもサポートし、物理インフラストラクチャーおよび仮想インフラストラクチャーの統一された操作を提供します。" - -#: ../../rst/scenario_guides/guide_aci.rst:21 -msgid "The APIC enables network administrators to easily define the optimal network for applications. Data center operators can clearly see how applications consume network resources, easily isolate and troubleshoot application and infrastructure problems, and monitor and profile resource usage patterns." -msgstr "APIC により、ネットワーク管理者はアプリケーションに最適なネットワークを簡単に定義できます。データセンターオペレーターは、アプリケーションがネットワークリソースをどのように消費するかを明確に確認し、アプリケーションとインフラストラクチャーの問題を簡単に特定してトラブルシューティングを行い、リソースの使用状況パターンを監視およびプロファイルできます。" - -#: ../../rst/scenario_guides/guide_aci.rst:23 -msgid "The Cisco Application Policy Infrastructure Controller (APIC) API enables applications to directly connect with a secure, shared, high-performance resource pool that includes network, compute, and storage capabilities." -msgstr "APIC (Cisco Application Policy Infrastructure Controller) API を使用すると、アプリケーションと、ネットワーク、コンピュート、およびストレージの機能を含む、安全で共有されている高性能リソースプールを直接接続できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:27 -msgid "ACI Fabric" -msgstr "ACI Fabric" - -#: ../../rst/scenario_guides/guide_aci.rst:28 -msgid "The Cisco Application Centric Infrastructure (ACI) Fabric includes Cisco Nexus 9000 Series switches with the APIC to run in the leaf/spine ACI fabric mode. These switches form a \"fat-tree\" network by connecting each leaf node to each spine node; all other devices connect to the leaf nodes. The APIC manages the ACI fabric." -msgstr "Cisco ACI (Application Centric Infrastructure) Fabric には、リーフ/スパインの ACI ファブリックモードで実行する APIC を搭載した Cisco Nexus 9000 シリーズスイッチと同梱されます。このスイッチは、各リーフノードを各スパインノードに接続し、その他のデバイスはリーフノードに接続することで「fat-tree」ネットワークを形成します。APIC は ACI ファブリックを管理します。" - -#: ../../rst/scenario_guides/guide_aci.rst:30 -msgid "The ACI fabric provides consistent low-latency forwarding across high-bandwidth links (40 Gbps, with a 100-Gbps future capability). Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch." -msgstr "ACI ファブリックは、高帯域幅のリンクで一貫した低レイテンシー転送を提供します (40 Gbps、将来的には 100-Gbps)。送信元および宛先が同じリーフスイッチにあるトラフィックはローカルで処理され、他のすべてのトラフィックはスパインスイッチを介して入力リーフから出力リーフに送信されます。このアーキテクチャーは、物理的には 2 つのホップとして表示されますが、このファブリックが単一の Layer 3 スイッチとして機能するため、実際には単一の Layer 3 ホップとなります。" - -#: ../../rst/scenario_guides/guide_aci.rst:32 -msgid "The ACI fabric object-oriented operating system (OS) runs on each Cisco Nexus 9000 Series node. It enables programming of objects for each configurable element of the system. The ACI fabric OS renders policies from the APIC into a concrete model that runs in the physical infrastructure. The concrete model is analogous to compiled software; it is the form of the model that the switch operating system can execute." -msgstr "ACI ファブリックオブジェクト指向のオペレーティングシステム (OS) は、それぞれの Cisco Nexus 9000 シリーズノードで実行します。ACI ファブリック OS は、APIC からのポリシーを物理インフラストラクチャーで実行する具体的なモデルにレンダリングします。具体的なモデルは、コンパイルされたソフトウェアに似ています。これは、スイッチオペレーティングシステムを実行できるモデルの形式です。" - -#: ../../rst/scenario_guides/guide_aci.rst:34 -msgid "All the switch nodes contain a complete copy of the concrete model. When an administrator creates a policy in the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the intermediate step of creating a fully elaborated policy that it pushes into all the switch nodes where the concrete model is updated." -msgstr "すべてのスイッチノードには、具体的なモデルの完全なコピーが含まれます。管理者が設定を表す APIC にポリシーを作成すると、APIC は論理モデルを更新します。その後、APIC は、具体的なモデルが更新されるすべてのスイッチノードにプッシュされる完全に改良されたポリシーを作成する中間ステップを実行します。" - -#: ../../rst/scenario_guides/guide_aci.rst:36 -msgid "The APIC is responsible for fabric activation, switch firmware management, network policy configuration, and instantiation. While the APIC acts as the centralized policy and network management engine for the fabric, it is completely removed from the data path, including the forwarding topology. Therefore, the fabric can still forward traffic even when communication with the APIC is lost." -msgstr "APIC は、ファブリックのアクティブ化、ファームウェア管理の切り替え、ネットワークポリシーの設定、およびインスタンス化を行います。APIC はそのファブリックの集中管理ポリシーおよびネットワーク管理エンジンとして機能しますが、転送トポロジーを含むデータパスから完全に削除されます。したがって、ファブリックは APIC との通信が失われてもトラフィックを転送できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:40 -#: ../../rst/scenario_guides/guide_aci.rst:285 -#: ../../rst/scenario_guides/guide_aci.rst:435 -#: ../../rst/scenario_guides/guide_aci.rst:528 -msgid "More information" -msgstr "詳細情報" - -#: ../../rst/scenario_guides/guide_aci.rst:41 -msgid "Various resources exist to start learning ACI, here is a list of interesting articles from the community." -msgstr "ACI の学習を開始するためのさまざまなリソースが存在します。ここでは、コミュニティーからの興味深い記事を記載しています。" - -#: ../../rst/scenario_guides/guide_aci.rst:43 -msgid "`Adam Raffe: Learning ACI `_" -msgstr "`Adam Raffe: Learning ACI `_" - -#: ../../rst/scenario_guides/guide_aci.rst:44 -msgid "`Luca Relandini: ACI for dummies `_" -msgstr "`Luca Relandini: ACI for dummies `_" - -#: ../../rst/scenario_guides/guide_aci.rst:45 -msgid "`Cisco DevNet Learning Labs about ACI `_" -msgstr "`Cisco DevNet Learning Labs about ACI `_" - -#: ../../rst/scenario_guides/guide_aci.rst:51 -msgid "Using the ACI modules" -msgstr "ACI モジュールの使用" - -#: ../../rst/scenario_guides/guide_aci.rst:52 -msgid "The Ansible ACI modules provide a user-friendly interface to managing your ACI environment using Ansible playbooks." -msgstr "Ansible ACI モジュールは、Ansible Playbook を使用して ACI 環境を管理するユーザーフレンドリーなインターフェースを提供します。" - -#: ../../rst/scenario_guides/guide_aci.rst:54 -msgid "For instance ensuring that a specific tenant exists, is done using the following Ansible task using the aci_tenant module:" -msgstr "たとえば、特定のテナントが存在することを確認するには、aci_tenant モジュールを使用して以下の Ansible タスクを使用します。" - -#: ../../rst/scenario_guides/guide_aci.rst:68 -msgid "A complete list of existing ACI modules is available on the content tab of the `ACI collection on Ansible Galaxy `_." -msgstr "既存の ACI モジュールの完全な一覧は、「`Ansible Galaxy での ACI コレクション `_」にあるコンテンツタブで確認できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:70 -msgid "If you want to learn how to write your own ACI modules to contribute, look at the :ref:`Developing Cisco ACI modules ` section." -msgstr "独自の ACI モジュールを作成して貢献する方法を学ぶ場合は、「:ref:`Cisco ACI モジュールの開発 `」セクションを参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:73 -msgid "Querying ACI configuration" -msgstr "ACI 設定のクエリー" - -#: ../../rst/scenario_guides/guide_aci.rst:75 -msgid "A module can also be used to query a specific object." -msgstr "モジュールは、特定のオブジェクトのクエリーにも使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:89 -msgid "Or query all objects." -msgstr "または、すべてのオブジェクトをクエリーします。" - -#: ../../rst/scenario_guides/guide_aci.rst:102 -msgid "After registering the return values of the aci_tenant task as shown above, you can access all tenant information from variable ``all_tenants``." -msgstr "上記のように aci_tenant タスクの戻り値を登録した後、変数 ``all_tenants`` からすべてのテナント情報にアクセスできます。" - -#: ../../rst/scenario_guides/guide_aci.rst:106 -msgid "Running on the controller locally" -msgstr "コントローラーでローカルに実行" - -#: ../../rst/scenario_guides/guide_aci.rst:107 -msgid "As originally designed, Ansible modules are shipped to and run on the remote target(s), however the ACI modules (like most network-related modules) do not run on the network devices or controller (in this case the APIC), but they talk directly to the APIC's REST interface." -msgstr "最初に設計されたように、Ansible モジュールはリモートターゲットに同梱され、実行しますが、ACI モジュール (ほとんどのネットワーク関連モジュールなど) はネットワークデバイスやコントローラー (この場合は APIC) では動作しませんが、APIC の REST インターフェースと直接対話します。" - -#: ../../rst/scenario_guides/guide_aci.rst:109 -msgid "For this very reason, the modules need to run on the local Ansible controller (or are delegated to another system that *can* connect to the APIC)." -msgstr "このため、モジュールはローカルの Ansible コントローラーで実行する必要があります (または、APIC に接続 *できる* 別のシステムに委譲されます)。" - -#: ../../rst/scenario_guides/guide_aci.rst:113 -msgid "Gathering facts" -msgstr "ファクトの収集" - -#: ../../rst/scenario_guides/guide_aci.rst:114 -msgid "Because we run the modules on the Ansible controller gathering facts will not work. That is why when using these ACI modules it is mandatory to disable facts gathering. You can do this globally in your ``ansible.cfg`` or by adding ``gather_facts: false`` to every play." -msgstr "Ansible コントローラーでモジュールを実行するため、ファクトの収集は機能しません。そのため、これらの ACI モジュールを使用する場合はファクトの収集を無効にする必要があります。これは、``ansible.cfg`` でグローバルに行うか、すべてのプレイに ``gather_facts: false`` を追加して行うことができます。" - -#: ../../rst/scenario_guides/guide_aci.rst:128 -msgid "Delegating to localhost" -msgstr "ローカルホストへの委譲" - -#: ../../rst/scenario_guides/guide_aci.rst:129 -msgid "So let us assume we have our target configured in the inventory using the FQDN name as the ``ansible_host`` value, as shown below." -msgstr "そのため、以下に示すように、FQDN 名を ``ansible_host`` 値として使用し、ターゲットをインベントリーに設定したと仮定します。" - -#: ../../rst/scenario_guides/guide_aci.rst:140 -msgid "One way to set this up is to add to every task the directive: ``delegate_to: localhost``." -msgstr "これを設定する方法は、ディレクティブのすべてのタスク (``delegate_to: localhost``) に追加することです。" - -#: ../../rst/scenario_guides/guide_aci.rst:155 -msgid "If one would forget to add this directive, Ansible will attempt to connect to the APIC using SSH and attempt to copy the module and run it remotely. This will fail with a clear error, yet may be confusing to some." -msgstr "このディレクティブの追加を忘れると、Ansible は SSH を使用して APIC への接続を試み、モジュールをコピーしてリモートで実行しようとします。これはクリアエラーで失敗しますが、混乱が生じる可能性があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:159 -msgid "Using the local connection method" -msgstr "ローカル接続方法の使用" - -#: ../../rst/scenario_guides/guide_aci.rst:160 -msgid "Another option frequently used, is to tie the ``local`` connection method to this target so that every subsequent task for this target will use the local connection method (hence run it locally, rather than use SSH)." -msgstr "よく使用される別のオプションは、``local`` 接続方法をこのターゲットに結び付けることです。これにより、このターゲットの後続のすべてのタスクでローカル接続方法が使用されます (したがって、SSH を使用するのではなくローカルで実行します)。" - -#: ../../rst/scenario_guides/guide_aci.rst:162 -msgid "In this case the inventory may look like this:" -msgstr "この場合、インベントリーは以下のようになります。" - -#: ../../rst/scenario_guides/guide_aci.rst:174 -msgid "But used tasks do not need anything special added." -msgstr "ただし、使用したタスクには特別な追加は必要ありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:187 -msgid "For clarity we have added ``delegate_to: localhost`` to all the examples in the module documentation. This helps to ensure first-time users can easily copy&paste parts and make them work with a minimum of effort." -msgstr "分かりやすくするために、モジュールドキュメントのすべての例に ``delegate_to: localhost`` を追加しました。これにより、初回のユーザーが簡単に一部をコピーして、最低限の努力で作業できるようになります。" - -#: ../../rst/scenario_guides/guide_aci.rst:191 -msgid "Common parameters" -msgstr "一般的なパラメーター" - -#: ../../rst/scenario_guides/guide_aci.rst:192 -msgid "Every Ansible ACI module accepts the following parameters that influence the module's communication with the APIC REST API:" -msgstr "すべての Ansible ACI モジュールは、APIC REST API を使用したモジュールの通信に影響を与える以下のパラメーターを受け入れます。" - -#: ../../rst/scenario_guides/guide_aci.rst:195 -#: ../../rst/scenario_guides/guide_meraki.rst:65 -msgid "host" -msgstr "host" - -#: ../../rst/scenario_guides/guide_aci.rst:195 -msgid "Hostname or IP address of the APIC." -msgstr "APIC のホスト名または IP アドレス。" - -#: ../../rst/scenario_guides/guide_aci.rst:198 -msgid "port" -msgstr "port" - -#: ../../rst/scenario_guides/guide_aci.rst:198 -msgid "Port to use for communication. (Defaults to ``443`` for HTTPS, and ``80`` for HTTP)" -msgstr "通信に使用するポート (デフォルトでは、HTTPS の場合は ``443``、HTTP の場合は ``80``)。" - -#: ../../rst/scenario_guides/guide_aci.rst:201 -msgid "username" -msgstr "username" - -#: ../../rst/scenario_guides/guide_aci.rst:201 -msgid "User name used to log on to the APIC. (Defaults to ``admin``)" -msgstr "APIC にログインするのに使用されるユーザー名 (デフォルトは ``admin``)。" - -#: ../../rst/scenario_guides/guide_aci.rst:204 -#: ../../rst/scenario_guides/guide_azure.rst:136 -#: ../../rst/scenario_guides/guide_azure.rst:142 -msgid "password" -msgstr "password" - -#: ../../rst/scenario_guides/guide_aci.rst:204 -msgid "Password for ``username`` to log on to the APIC, using password-based authentication." -msgstr "パスワードベースの認証を使用して APIC にログインする ``username`` のパスワード。" - -#: ../../rst/scenario_guides/guide_aci.rst:209 -msgid "private_key" -msgstr "private_key" - -#: ../../rst/scenario_guides/guide_aci.rst:207 -msgid "Private key for ``username`` to log on to APIC, using signature-based authentication. This could either be the raw private key content (include header/footer) or a file that stores the key content. *New in version 2.5*" -msgstr "署名ベースの認証を使用して APIC にログインする ``username`` の秘密鍵。これは、(ヘッダー/フッターを含む) 生の秘密鍵コンテンツ、または鍵コンテンツを格納するファイルのいずれかになります。*バージョン 2.5 の新機能* です。" - -#: ../../rst/scenario_guides/guide_aci.rst:214 -msgid "certificate_name" -msgstr "certificate_name" - -#: ../../rst/scenario_guides/guide_aci.rst:212 -msgid "Name of the certificate in the ACI Web GUI. This defaults to either the ``username`` value or the ``private_key`` file base name). *New in version 2.5*" -msgstr "ACI Web GUI の証明書の名前。デフォルトは ``username`` 値または ``private_key`` ファイルのベース名になります。*バージョン 2.5 の新機能* です。" - -#: ../../rst/scenario_guides/guide_aci.rst:217 -msgid "timeout" -msgstr "timeout" - -#: ../../rst/scenario_guides/guide_aci.rst:217 -msgid "Timeout value for socket-level communication." -msgstr "ソケットレベルの通信のタイムアウト値。" - -#: ../../rst/scenario_guides/guide_aci.rst:220 -#: ../../rst/scenario_guides/guide_meraki.rst:71 -msgid "use_proxy" -msgstr "use_proxy" - -#: ../../rst/scenario_guides/guide_aci.rst:220 -msgid "Use system proxy settings. (Defaults to ``yes``)" -msgstr "システムプロキシー設定を使用します (``yes`` にデフォルト設定)。" - -#: ../../rst/scenario_guides/guide_aci.rst:223 -msgid "use_ssl" -msgstr "use_ssl" - -#: ../../rst/scenario_guides/guide_aci.rst:223 -msgid "Use HTTPS or HTTP for APIC REST communication. (Defaults to ``yes``)" -msgstr "APIC REST 通信には HTTPS または HTTP を使用します (``yes`` にデフォルト設定)。" - -#: ../../rst/scenario_guides/guide_aci.rst:226 -#: ../../rst/scenario_guides/guide_meraki.rst:74 -msgid "validate_certs" -msgstr "validate_certs" - -#: ../../rst/scenario_guides/guide_aci.rst:226 -msgid "Validate certificate when using HTTPS communication. (Defaults to ``yes``)" -msgstr "HTTPS 通信を使用する場合に証明書を検証します (``yes`` にデフォルト設定)。" - -#: ../../rst/scenario_guides/guide_aci.rst:230 -msgid "output_level" -msgstr "output_level" - -#: ../../rst/scenario_guides/guide_aci.rst:229 -msgid "Influence the level of detail ACI modules return to the user. (One of ``normal``, ``info`` or ``debug``) *New in version 2.5*" -msgstr "詳細な ACI モジュールがユーザーに返すレベルに影響します (``normal``、``info``、または ``debug`` のいずれか)。*バージョン 2.5 の新機能* です。" - -#: ../../rst/scenario_guides/guide_aci.rst:233 -msgid "Proxy support" -msgstr "プロキシーのサポート" - -#: ../../rst/scenario_guides/guide_aci.rst:234 -msgid "By default, if an environment variable ``_proxy`` is set on the target host, requests will be sent through that proxy. This behaviour can be overridden by setting a variable for this task (see :ref:`playbooks_environment`), or by using the ``use_proxy`` module parameter." -msgstr "デフォルトでは、環境変数 ``_proxy`` がターゲットホストに設定されていると、要求はそのプロキシー経由で送信されます。この動作は、このタスクに変数を設定して上書きする (「:ref:`playbooks_environment`」を参照) か、``use_proxy`` モジュールパラメーターを使用して上書きできます。" - -#: ../../rst/scenario_guides/guide_aci.rst:236 -msgid "HTTP redirects can redirect from HTTP to HTTPS so ensure that the proxy environment for both protocols is correctly configured." -msgstr "HTTP リダイレクトは HTTP から HTTPS へリダイレクトできるため、両方のプロトコルのプロキシー環境が正しく設定されていることを確認します。" - -#: ../../rst/scenario_guides/guide_aci.rst:238 -msgid "If proxy support is not needed, but the system may have it configured nevertheless, use the parameter ``use_proxy: false`` to avoid accidental system proxy usage." -msgstr "プロキシーサポートが必要なくても、システムがそれを設定する可能性がある場合は、``use_proxy: false`` パラメーターを使用して、誤ったシステムプロキシーの使用を回避します。" - -#: ../../rst/scenario_guides/guide_aci.rst:240 -msgid "Selective proxy support using the ``no_proxy`` environment variable is also supported." -msgstr "``no_proxy`` 環境変数を使用した選択的プロキシーサポートにも対応しています。" - -#: ../../rst/scenario_guides/guide_aci.rst:244 -msgid "Return values" -msgstr "戻り値" - -#: ../../rst/scenario_guides/guide_aci.rst:248 -msgid "The following values are always returned:" -msgstr "以下の値が常に返されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:251 -msgid "current" -msgstr "current" - -#: ../../rst/scenario_guides/guide_aci.rst:251 -msgid "The resulting state of the managed object, or results of your query." -msgstr "管理オブジェクトの結果の状態、またはクエリーの結果。" - -#: ../../rst/scenario_guides/guide_aci.rst:253 -msgid "The following values are returned when ``output_level: info``:" -msgstr "``output_level: info`` の場合は、以下の値が常に返されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:256 -msgid "previous" -msgstr "previous" - -#: ../../rst/scenario_guides/guide_aci.rst:256 -msgid "The original state of the managed object (before any change was made)." -msgstr "管理対象オブジェクトの元の状態 (変更が行われる前の状態)。" - -#: ../../rst/scenario_guides/guide_aci.rst:259 -msgid "proposed" -msgstr "proposed" - -#: ../../rst/scenario_guides/guide_aci.rst:259 -msgid "The proposed config payload, based on user-supplied values." -msgstr "ユーザーが指定した値に基づいた、提案された設定ペイロード。" - -#: ../../rst/scenario_guides/guide_aci.rst:262 -msgid "sent" -msgstr "sent" - -#: ../../rst/scenario_guides/guide_aci.rst:262 -msgid "The sent config payload, based on user-supplied values and the existing configuration." -msgstr "ユーザーが指定した値、および既存の設定に基づく、送信された設定ペイロード。" - -#: ../../rst/scenario_guides/guide_aci.rst:264 -msgid "The following values are returned when ``output_level: debug`` or ``ANSIBLE_DEBUG=1``:" -msgstr "``output_level: debug`` または``ANSIBLE_DEBUG=1`` の場合は、以下の値が常に返されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:267 -msgid "filter_string" -msgstr "filter_string" - -#: ../../rst/scenario_guides/guide_aci.rst:267 -msgid "The filter used for specific APIC queries." -msgstr "特定の APIC クエリーに使用されるフィルター。" - -#: ../../rst/scenario_guides/guide_aci.rst:270 -msgid "method" -msgstr "method" - -#: ../../rst/scenario_guides/guide_aci.rst:270 -msgid "The HTTP method used for the sent payload. (Either ``GET`` for queries, ``DELETE`` or ``POST`` for changes)" -msgstr "送信されたペイロードに使用される HTTP メソッド (問い合わせの ``GET``、もしくは変更の ``DELETE`` または``POST`` のいずれか)。" - -#: ../../rst/scenario_guides/guide_aci.rst:273 -msgid "response" -msgstr "response" - -#: ../../rst/scenario_guides/guide_aci.rst:273 -msgid "The HTTP response from the APIC." -msgstr "APIC からの HTTP 応答。" - -#: ../../rst/scenario_guides/guide_aci.rst:276 -msgid "status" -msgstr "status" - -#: ../../rst/scenario_guides/guide_aci.rst:276 -msgid "The HTTP status code for the request." -msgstr "リクエストの HTTP ステータスコード。" - -#: ../../rst/scenario_guides/guide_aci.rst:279 -msgid "url" -msgstr "url" - -#: ../../rst/scenario_guides/guide_aci.rst:279 -msgid "The url used for the request." -msgstr "要求に使用される URL。" - -#: ../../rst/scenario_guides/guide_aci.rst:281 -msgid "The module return values are documented in detail as part of each module's documentation." -msgstr "モジュールの戻り値は、各モジュールのドキュメントで詳細に説明されています。" - -#: ../../rst/scenario_guides/guide_aci.rst:286 -msgid "Various resources exist to start learn more about ACI programmability, we recommend the following links:" -msgstr "ACI プログラミングの詳細を学ぶために、さまざまなリソースがあります。以下のリンクが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:288 -#: ../../rst/scenario_guides/guide_aci.rst:650 -msgid ":ref:`Developing Cisco ACI modules `" -msgstr ":ref:`Developing Cisco ACI modules `" - -#: ../../rst/scenario_guides/guide_aci.rst:289 -msgid "`Jacob McGill: Automating Cisco ACI with Ansible `_" -msgstr "`Jacob McGill: Automating Cisco ACI with Ansible `_" - -#: ../../rst/scenario_guides/guide_aci.rst:290 -msgid "`Cisco DevNet Learning Labs about ACI and Ansible `_" -msgstr "`Cisco DevNet Learning Labs about ACI and Ansible `_" - -#: ../../rst/scenario_guides/guide_aci.rst:296 -msgid "ACI authentication" -msgstr "ACI 認証" - -#: ../../rst/scenario_guides/guide_aci.rst:299 -msgid "Password-based authentication" -msgstr "パスワードベースの認証" - -#: ../../rst/scenario_guides/guide_aci.rst:300 -msgid "If you want to log on using a username and password, you can use the following parameters with your ACI modules:" -msgstr "ユーザー名とパスワードを使用してログインする場合は、ACI モジュールで以下のパラメーターを使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:307 -msgid "Password-based authentication is very simple to work with, but it is not the most efficient form of authentication from ACI's point-of-view as it requires a separate login-request and an open session to work. To avoid having your session time-out and requiring another login, you can use the more efficient Signature-based authentication." -msgstr "パスワードベースの認証は非常に簡単ですが、別のログイン要求とオープンセッションが機能する必要があるため、ACI の観点から最も効率的な認証形式ではありません。セッションのタイムアウトや別のログインを必要としないように、より効率的な署名ベースの認証を使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:309 -msgid "Password-based authentication also may trigger anti-DoS measures in ACI v3.1+ that causes session throttling and results in HTTP 503 errors and login failures." -msgstr "パスワードベースの認証では、ACI v3.1 以降の DoS 対策がトリガーとなり、セッションスロットルが発生し、HTTP 503 エラーとなり、ログインが失敗する可能性があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:311 -msgid "Never store passwords in plain text." -msgstr "プレーンテキストにパスワードを保存しないでください。" - -#: ../../rst/scenario_guides/guide_aci.rst:313 -#: ../../rst/scenario_guides/guide_meraki.rst:100 -msgid "The \"Vault\" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information." -msgstr "Ansible の「Vault」機能を使用すると、パスワードやキーなどの機密データを、Playbook やロールのプレーンテキストとしてではなく、暗号化されたファイルに保存することができます。この Vault ファイルは、ソース制御に配布または配置することができます。詳細は、「:ref:`playbooks_vault`」を参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:317 -msgid "Signature-based authentication using certificates" -msgstr "証明書を使用した署名ベースの認証" - -#: ../../rst/scenario_guides/guide_aci.rst:321 -msgid "Using signature-based authentication is more efficient and more reliable than password-based authentication." -msgstr "署名ベースの認証の使用は、パスワードベースの認証よりも効率的で、信頼性が高くなります。" - -#: ../../rst/scenario_guides/guide_aci.rst:324 -msgid "Generate certificate and private key" -msgstr "証明書と秘密鍵の生成" - -#: ../../rst/scenario_guides/guide_aci.rst:325 -msgid "Signature-based authentication requires a (self-signed) X.509 certificate with private key, and a configuration step for your AAA user in ACI. To generate a working X.509 certificate and private key, use the following procedure:" -msgstr "署名ベースの認証では、秘密鍵を持つ (自己署名) X.509 証明書と、ACI の AAA ユーザーの設定手順が必要になります。稼働中の X.509 証明書および秘密鍵を生成するには、以下の手順に従います。" - -#: ../../rst/scenario_guides/guide_aci.rst:332 -msgid "Configure your local user" -msgstr "ローカルユーザーの設定" - -#: ../../rst/scenario_guides/guide_aci.rst:333 -msgid "Perform the following steps:" -msgstr "以下の手順を実行します。" - -#: ../../rst/scenario_guides/guide_aci.rst:335 -msgid "Add the X.509 certificate to your ACI AAA local user at :guilabel:`ADMIN` » :guilabel:`AAA`" -msgstr ":guilabel:`ADMIN` » :guilabel:`AAA` で、ACI AAA ローカルユーザーに X.509 証明書を追加します。" - -#: ../../rst/scenario_guides/guide_aci.rst:336 -msgid "Click :guilabel:`AAA Authentication`" -msgstr ":guilabel:`AAA Authentication` をクリックします。" - -#: ../../rst/scenario_guides/guide_aci.rst:337 -msgid "Check that in the :guilabel:`Authentication` field the :guilabel:`Realm` field displays :guilabel:`Local`" -msgstr ":guilabel:`Authentication` フィールドで、:guilabel:`Realm` フィールドが :guilabel:`Local` と表示されていることを確認します。" - -#: ../../rst/scenario_guides/guide_aci.rst:338 -msgid "Expand :guilabel:`Security Management` » :guilabel:`Local Users`" -msgstr ":guilabel:`Security Management` » :guilabel:`Local Users` と展開します。" - -#: ../../rst/scenario_guides/guide_aci.rst:339 -msgid "Click the name of the user you want to add a certificate to, in the :guilabel:`User Certificates` area" -msgstr ":guilabel:`User Certificates` エリアで、証明書を追加するユーザー名をクリックします。" - -#: ../../rst/scenario_guides/guide_aci.rst:340 -msgid "Click the :guilabel:`+` sign and in the :guilabel:`Create X509 Certificate` enter a certificate name in the :guilabel:`Name` field" -msgstr ":guilabel:`+` 記号をクリックし、:guilabel:`Create X509 Certificate` の :guilabel:`Name` フィールドに証明書名を入力します。" - -#: ../../rst/scenario_guides/guide_aci.rst:342 -msgid "If you use the basename of your private key here, you don't need to enter ``certificate_name`` in Ansible" -msgstr "ここで秘密鍵のベース名を使用する場合は、Ansible で ``certificate_name`` を入力する必要はありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:344 -msgid "Copy and paste your X.509 certificate in the :guilabel:`Data` field." -msgstr ":guilabel:`Data` フィールドに X.509 証明書をコピーして貼り付けます。" - -#: ../../rst/scenario_guides/guide_aci.rst:346 -msgid "You can automate this by using the following Ansible task:" -msgstr "これは、以下の Ansible タスクを使用して自動化できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:360 -msgid "Signature-based authentication only works with local users." -msgstr "署名ベースの認証は、ローカルユーザーでのみ機能します。" - -#: ../../rst/scenario_guides/guide_aci.rst:364 -msgid "Use signature-based authentication with Ansible" -msgstr "Ansible での署名ベースの認証の使用" - -#: ../../rst/scenario_guides/guide_aci.rst:365 -msgid "You need the following parameters with your ACI module(s) for it to work:" -msgstr "これを有効にするには、ACI モジュールで以下のパラメーターが必要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:374 -msgid "or you can use the private key content:" -msgstr "または、秘密鍵のコンテンツを使用できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:387 -msgid "If you use a certificate name in ACI that matches the private key's basename, you can leave out the ``certificate_name`` parameter like the example above." -msgstr "秘密鍵のベース名に一致する ACI で証明書名を使用する場合は、上記の例のような ``certificate_name`` パラメーターを省略できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:391 -msgid "Using Ansible Vault to encrypt the private key" -msgstr "Ansible Vault を使用した秘密鍵の暗号化" - -#: ../../rst/scenario_guides/guide_aci.rst:394 -msgid "To start, encrypt the private key and give it a strong password." -msgstr "まず、秘密鍵を暗号化して強固なパスワードを付与します。" - -#: ../../rst/scenario_guides/guide_aci.rst:400 -msgid "Use a text editor to open the private-key. You should have an encrypted cert now." -msgstr "テキストエディターを使用して、秘密鍵を開きます。これで、暗号化された証明書が存在するはずです。" - -#: ../../rst/scenario_guides/guide_aci.rst:409 -msgid "Copy and paste the new encrypted cert into your playbook as a new variable." -msgstr "新しい暗号化された証明書を新規の変数として Playbook にコピーアンドペーストします。" - -#: ../../rst/scenario_guides/guide_aci.rst:419 -msgid "Use the new variable for the private_key:" -msgstr "private_key の新しい変数を使用します。" - -#: ../../rst/scenario_guides/guide_aci.rst:427 -msgid "When running the playbook, use \"--ask-vault-pass\" to decrypt the private key." -msgstr "Playbook の実行時に、「--ask-vault-pass」を使用して秘密鍵を復号します。" - -#: ../../rst/scenario_guides/guide_aci.rst:436 -msgid "Detailed information about Signature-based Authentication is available from `Cisco APIC Signature-Based Transactions `_." -msgstr "- 署名ベースの認証に関する詳細情報は、「`Cisco APIC Signature-Based Transactions `_」を参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:437 -msgid "More information on Ansible Vault can be found on the :ref:`Ansible Vault ` page." -msgstr "Ansible Vault の詳細は、「:ref:`Ansible Vault `」ページを参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:443 -msgid "Using ACI REST with Ansible" -msgstr "Ansible での ACI REST の使用" - -#: ../../rst/scenario_guides/guide_aci.rst:444 -msgid "While already a lot of ACI modules exists in the Ansible distribution, and the most common actions can be performed with these existing modules, there's always something that may not be possible with off-the-shelf modules." -msgstr "すでに多くの ACI モジュールが Ansible ディストリビューションに同梱されており、最も一般的なアクションはこれらの既存のモジュールで実行できますが、既製のモジュールではできないことは常にあります。" - -#: ../../rst/scenario_guides/guide_aci.rst:446 -msgid "The aci_rest module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly." -msgstr "aci_rest モジュールを使用すると、APIC REST API に直接アクセスでき、既存のモジュールで対応していないタスクを実行できます。これは複雑な作業のように思えるかもしれませんが、ACI Web インターフェースで実行されるアクションに必要な REST ペイロードを簡単に生成できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:450 -msgid "Built-in idempotency" -msgstr "組み込みの冪等性" - -#: ../../rst/scenario_guides/guide_aci.rst:451 -msgid "Because the APIC REST API is intrinsically idempotent and can report whether a change was made, the aci_rest module automatically inherits both capabilities and is a first-class solution for automating your ACI infrastructure. As a result, users that require more powerful low-level access to their ACI infrastructure don't have to give up on idempotency and don't have to guess whether a change was performed when using the aci_rest module." -msgstr "APIC REST API は冪等であり、変更されたかどうかを報告することができるため、aci_rest モジュールは両方の機能を自動的に継承し、ACI インフラストラクチャーを自動化するファーストクラスソリューションとなります。その結果、ACI インフラストラクチャーへのより強力な低レベルアクセスを必要とするユーザーは、冪等性をあきらめる必要がなく、aci_rest モジュールの使用時に変更が行われたかどうかを推測する必要もありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:455 -msgid "Using the aci_rest module" -msgstr "aci_rest モジュールの使用" - -#: ../../rst/scenario_guides/guide_aci.rst:456 -msgid "The aci_rest module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require the path to end with ``.json``." -msgstr "aci_rest モジュールはネイティブの XML ペイロードおよび JSON ペイロードを受け入れますが、(JSON などの) インライン YAML ペイロードも追加で受け入れます。XML ペイロードでは、``.xml`` で終わるパスを使用する必要がありますが、JSON または YAML には ``.json`` で終わるパスが必要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:458 -msgid "When you're making modifications, you can use the POST or DELETE methods, whereas doing just queries require the GET method." -msgstr "変更を行う場合は、POST メソッドまたは DELETE メソッドを使用できますが、クエリーのみを実行するには GET メソッドが必要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:460 -msgid "For instance, if you would like to ensure a specific tenant exists on ACI, these below four examples are functionally identical:" -msgstr "たとえば、特定のテナントが ACI に存在することを確認する場合は、以下の 4 つの例が機能的に同じです。" - -#: ../../rst/scenario_guides/guide_aci.rst:462 -msgid "**XML** (Native ACI REST)" -msgstr "**XML** (ネイティブの ACI REST)" - -#: ../../rst/scenario_guides/guide_aci.rst:475 -msgid "**JSON** (Native ACI REST)" -msgstr "**JSON** (ネイティブの ACI REST)" - -#: ../../rst/scenario_guides/guide_aci.rst:495 -msgid "**YAML** (Ansible-style REST)" -msgstr "**YAML** (Ansible スタイルの REST)" - -#: ../../rst/scenario_guides/guide_aci.rst:511 -msgid "**Ansible task** (Dedicated module)" -msgstr "**Ansible タスク** (専用モジュール)" - -#: ../../rst/scenario_guides/guide_aci.rst:524 -msgid "The XML format is more practical when there is a need to template the REST payload (inline), but the YAML format is more convenient for maintaining your infrastructure-as-code and feels more naturally integrated with Ansible playbooks. The dedicated modules offer a more simple, abstracted, but also a more limited experience. Use what feels best for your use-case." -msgstr "XML 形式は、REST ペイロード (インライン) のテンプレートが必要な場合により実用的なものですが、YAML 形式は infrastructure-as-code を維持するのに便利で、Ansible Playbook との統合もより自然に感じられます。専用モジュールは、よりシンプルで抽象化されたモジュールを提供しますが、より限定的なエクスペリエンスも提供します。ユースケースに最適なものを使用してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:529 -msgid "Plenty of resources exist to learn about ACI's APIC REST interface, we recommend the links below:" -msgstr "ACI の APIC REST インターフェースを学ぶためのリソースは多数あります。以下のリンクが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:531 -msgid "`The ACI collection on Ansible Galaxy `_" -msgstr "`The ACI collection on Ansible Galaxy `_" - -#: ../../rst/scenario_guides/guide_aci.rst:532 -msgid "`APIC REST API Configuration Guide `_ -- Detailed guide on how the APIC REST API is designed and used, incl. many examples" -msgstr "`APIC REST API 設定ガイド `_ -- APIC REST API を設計および使用する方法についての詳細ガイド。多数の例があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:533 -msgid "`APIC Management Information Model reference `_ -- Complete reference of the APIC object model" -msgstr "`APIC 管理情報モデルリファレンス `_ -- APIC オブジェクトモデルの完全なリファレンス。" - -#: ../../rst/scenario_guides/guide_aci.rst:534 -msgid "`Cisco DevNet Learning Labs about ACI and REST `_" -msgstr "`Cisco DevNet Learning Labs about ACI and REST `_" - -#: ../../rst/scenario_guides/guide_aci.rst:540 -msgid "Operational examples" -msgstr "運用例" - -#: ../../rst/scenario_guides/guide_aci.rst:541 -msgid "Here is a small overview of useful operational tasks to reuse in your playbooks." -msgstr "以下は、Playbook で再利用する有用な運用タスクのいくつかの概要です。" - -#: ../../rst/scenario_guides/guide_aci.rst:543 -msgid "Feel free to contribute more useful snippets." -msgstr "より便利なスニペットを自由に投稿してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:547 -msgid "Waiting for all controllers to be ready" -msgstr "Waiting for all controllers to be ready" - -#: ../../rst/scenario_guides/guide_aci.rst:548 -msgid "You can use the below task after you started to build your APICs and configured the cluster to wait until all the APICs have come online. It will wait until the number of controllers equals the number listed in the ``apic`` inventory group." -msgstr "APIC の構築を開始し、すべての APIC がオンラインになるまで待機するようにクラスターを設定したら、以下のタスクを使用できます。これは、コントローラーの数が ``apic`` インベントリーに挙げられている数と等しくなるまで待機します。" - -#: ../../rst/scenario_guides/guide_aci.rst:565 -msgid "Waiting for cluster to be fully-fit" -msgstr "Waiting for cluster to be fully-fit" - -#: ../../rst/scenario_guides/guide_aci.rst:566 -msgid "The below example waits until the cluster is fully-fit. In this example you know the number of APICs in the cluster and you verify each APIC reports a 'fully-fit' status." -msgstr "以下の例では、クラスターが完全に調整されるまで待機します。この例では、クラスター内の APIC の数を把握し、各 APIC が「完全に適切な」状態を報告することを確認します。" - -#: ../../rst/scenario_guides/guide_aci.rst:590 -msgid "APIC error messages" -msgstr "APIC エラーメッセージ" - -#: ../../rst/scenario_guides/guide_aci.rst:591 -msgid "The following error messages may occur and this section can help you understand what exactly is going on and how to fix/avoid them." -msgstr "以下のエラーメッセージが表示される場合があります。本セクションは、何が起っているのか、およびそのエラーを修正または回避する方法を正確に理解するのに役立ちます。" - -#: ../../rst/scenario_guides/guide_aci.rst:595 -msgid "APIC Error 122: unknown managed object class 'polUni'" -msgstr "APIC Error 122: unknown managed object class 'polUni'" - -#: ../../rst/scenario_guides/guide_aci.rst:594 -msgid "In case you receive this error while you are certain your aci_rest payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (for example, the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload, which are easier to construct correctly and modify later." -msgstr "aci_rest ペイロードとオブジェクトクラスが一見正しいように見える場合にこのエラーが発生する場合は、ペイロードの JSON に誤りがあり (たとえば、送信されたペイロードが二重引用符ではなく一重引用符を使用している) 、その結果 APIC がペイロードからオブジェクトクラスを正しく解析していない可能性があります。これを回避する 1 つの方法は、YAML 形式または XML 形式のペイロードを使用することです。これにより、正しく構築して後で変更するのが簡単になります。" - -#: ../../rst/scenario_guides/guide_aci.rst:599 -msgid "APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag" -msgstr "APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag" - -#: ../../rst/scenario_guides/guide_aci.rst:598 -msgid "Although the JSON specification allows unordered elements, the APIC REST API requires that the JSON ``attributes`` element precede the ``children`` array or other elements. So you need to ensure that your payload conforms to this requirement. Sorting your dictionary keys will do the trick just fine. If you don't have any attributes, it may be necessary to add: ``attributes: {}`` as the APIC does expect the entry to precede any ``children``." -msgstr "JSON 仕様は順序付けされていない要素を許可しますが、APIC REST API では、JSON の ``attributes`` 要素が ``children`` アレイまたは他の要素の前になければなりません。そのため、ペイロードがこの要件に準拠していることを確認する必要があります。ディクショナリーキーを並び替えると問題なく終了します。属性を持たない場合、APIC は、エントリーが ``children`` の前にあることを期待しているため、``attributes: {}`` を追加する必要があるかもしれません。" - -#: ../../rst/scenario_guides/guide_aci.rst:603 -msgid "APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A \"legacy\" network'" -msgstr "APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A \"legacy\" network'" - -#: ../../rst/scenario_guides/guide_aci.rst:602 -msgid "Some values in the APIC have strict format-rules to comply to, and the internal APIC validation check for the provided value failed. In the above case, the ``description`` parameter (internally known as ``descr``) only accepts values conforming to Regex: ``[a-zA-Z0-9\\\\!#$%()*,-./:;@ _{|}~?&+]+``, in general it must not include quotes or square brackets." -msgstr "APIC 内の一部の値には準拠が必要な厳格な形式ルールがあり、提供される値に対する内部 APIC 検証チェックに失敗しました。上記のケースでは、``description`` パラメーター (内部的には``descr``) は、Regex: ``[a-zA-Z0-9\\\\!#$%()*,-./:;@ _{|}~?&+]+`` に準拠した値のみを受け入れ、一般的には引用符や角括弧を含むことはできません。" - -#: ../../rst/scenario_guides/guide_aci.rst:608 -msgid "Known issues" -msgstr "既知の問題" - -#: ../../rst/scenario_guides/guide_aci.rst:609 -msgid "The aci_rest module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of this module." -msgstr "aci_rest モジュールは、APIC REST API のラッパーです。これにより、APIC に関連する問題がこのモジュールの使用に反映されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:611 -msgid "All below issues either have been reported to the vendor, and most can simply be avoided." -msgstr "以下の問題はすべてベンダー企業に報告されており、ほとんどの場合は回避できます。" - -#: ../../rst/scenario_guides/guide_aci.rst:617 -msgid "Too many consecutive API calls may result in connection throttling" -msgstr "連続する API 呼び出しが多くなりすぎると、接続のスロットルが発生する可能性があります。" - -#: ../../rst/scenario_guides/guide_aci.rst:614 -msgid "Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific threshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended." -msgstr "ACI v3.1 以降、APIC は特定のしきい値で、パスワードベースの認証接続レートをアクティブにスロットルします。これは DDOS 対策の一環ですが、ACI でパスワードベースの認証で Ansible を使用している場合に問題が発生する可能性があります。現在のところ、nginx の設定でこのしきい値を増やすことで解決していますが、署名ベースの認証を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:616 -msgid "**NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules." -msgstr "**注記:** 接続スロットルを回避するだけでなく、ACI モジュールを使用する場合の全般的なパフォーマンスを向上させるため、ACI で署名ベースの認証を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_aci.rst:623 -msgid "Specific requests may not reflect changes correctly (`#35401 `_)" -msgstr "特定の要求には、変更が正しく反映されない場合があります (`#35401 `_)。" - -#: ../../rst/scenario_guides/guide_aci.rst:620 -msgid "There is a known issue where specific requests to the APIC do not properly reflect changed in the resulting output, even when we request those changes explicitly from the APIC. In one instance using the path ``api/node/mo/uni/infra.xml`` fails, where ``api/node/mo/uni/infra/.xml`` does work correctly." -msgstr "APIC に明示的に変更を要求しても、結果の出力に変更が正しく反映されないという問題がありました。ある例では、``api/node/mo/uni/infra.xml`` というパスを使用すると失敗しますが、``api/node/mo/uni/infra/.xml`` は正しく動作します。" - -#: ../../rst/scenario_guides/guide_aci.rst:622 -msgid "**NOTE:** A workaround is to register the task return values (for example, ``register: this``) and influence when the task should report a change by adding: ``changed_when: this.imdata != []``." -msgstr "**注記:** 回避策は、タスクの戻り値 (例: ``register: this``) を登録し、``changed_when: this.imdata != []`` を追加してタスクが変更を報告する場合に影響を及ぼすことです。" - -#: ../../rst/scenario_guides/guide_aci.rst:629 -msgid "Specific requests are known to not be idempotent (`#35050 `_)" -msgstr "特定のリクエストは冪等でないことが知られています (`#35050 `_)。" - -#: ../../rst/scenario_guides/guide_aci.rst:626 -msgid "The behaviour of the APIC is inconsistent to the use of ``status=\"created\"`` and ``status=\"deleted\"``. The result is that when you use ``status=\"created\"`` in your payload the resulting tasks are not idempotent and creation will fail when the object was already created. However this is not the case with ``status=\"deleted\"`` where such call to an non-existing object does not cause any failure whatsoever." -msgstr "APIC の動作は、``status=\"created\"`` および ``status=\"deleted\"`` の使用と矛盾しています。そのため、ペイロードで ``status=\"created\"`` を使用すると、作成されるタスクが冪等ではなく、オブジェクトがすでに作成されても作成に失敗します。しかし、``status=\"deleted\"`` の場合はそのようなことはなく、存在しないオブジェクトへの呼び出しでも何も失敗しません。" - -#: ../../rst/scenario_guides/guide_aci.rst:628 -msgid "**NOTE:** A workaround is to avoid using ``status=\"created\"`` and instead use ``status=\"modified\"`` when idempotency is essential to your workflow.." -msgstr "**注記:** ワークフローにおける冪等が必須である場合は、回避策として、``status=\"created\"`` を使用せず、``status=\"modified\"`` を使用してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:635 -msgid "Setting user password is not idempotent (`#35544 `_)" -msgstr "ユーザーパスワードの設定は冪等ではありません (`#35544 `_)" - -#: ../../rst/scenario_guides/guide_aci.rst:632 -msgid "Due to an inconsistency in the APIC REST API, a task that sets the password of a locally-authenticated user is not idempotent. The APIC will complain with message ``Password history check: user dag should not use previous 5 passwords``." -msgstr "APIC REST API の不整合により、ローカル認証されたユーザーのパスワードを設定するタスクは冪等ではありません。APIC は、``Password history check: user dag should not use previous 5 passwords`` メッセージを出力します。" - -#: ../../rst/scenario_guides/guide_aci.rst:634 -msgid "**NOTE:** There is no workaround for this issue." -msgstr "**注記:** この問題に対する回避策はありません。" - -#: ../../rst/scenario_guides/guide_aci.rst:640 -msgid "ACI Ansible community" -msgstr "ACI Ansible コミュニティー" - -#: ../../rst/scenario_guides/guide_aci.rst:641 -msgid "If you have specific issues with the ACI modules, or a feature request, or you like to contribute to the ACI project by proposing changes or documentation updates, look at the Ansible Community wiki ACI page at: https://github.com/ansible/community/wiki/Network:-ACI" -msgstr "ACI モジュールまたは機能要求に特定の問題が発生した場合や、変更やドキュメントの更新を提案して ACI プロジェクトに貢献する場合は、Ansible Community wiki の ACI ページ (https://github.com/ansible/community/wiki/Network:-ACI) を参照してください。" - -#: ../../rst/scenario_guides/guide_aci.rst:643 -msgid "You will find our roadmap, an overview of open ACI issues and pull-requests, and more information about who we are. If you have an interest in using ACI with Ansible, feel free to join! We occasionally meet online (on the #ansible-network chat channel, using Matrix at ansible.im or using IRC at `irc.libera.chat `_) to track progress and prepare for new Ansible releases." -msgstr "ロードマップ、オープンな ACI の問題およびプル要求の概要、ならびにこのコミュニティーに関する詳細情報を確認できます。ACI を Ansible で使用することを検討している場合は、お気軽にご参加ください。進捗状況を追跡し、新しい Ansible リリースの準備をするために、オンラインミーティング (#ansible-network チャンネル、ansible.im の表、または `irc.libera.chat `_ の IRC を使用) を行う場合もあります。" - -#: ../../rst/scenario_guides/guide_aci.rst:648 -msgid "`ACI collection on Ansible Galaxy `_" -msgstr "`ACI collection on Ansible Galaxy `_" - -#: ../../rst/scenario_guides/guide_aci.rst:649 -msgid "View the content tab for a complete list of supported ACI modules." -msgstr "サポートされている ACI モジュールの完全なリストは、コンテンツタブをご覧ください。" - -#: ../../rst/scenario_guides/guide_aci.rst:651 -msgid "A walkthrough on how to develop new Cisco ACI modules to contribute back." -msgstr "新しい Cisco ACI モジュールを開発して貢献する方法に関するウォークスルー" - -#: ../../rst/scenario_guides/guide_aci.rst:652 -msgid "`ACI community `_" -msgstr "`ACI community `_" - -#: ../../rst/scenario_guides/guide_aci.rst:653 -msgid "The Ansible ACI community wiki page, includes roadmap, ideas and development documentation." -msgstr "Ansible ACI コミュニティーの wiki ページ。ロードマップ、概念、および開発ドキュメントが含まれます。" - -#: ../../rst/scenario_guides/guide_aci.rst:654 -msgid ":ref:`network_guide`" -msgstr ":ref:`network_guide`" - -#: ../../rst/scenario_guides/guide_aci.rst:655 -msgid "A detailed guide on how to use Ansible for automating network infrastructure." -msgstr "ネットワークインフラストラクチャーの自動化に Ansible を使用する方法に関する詳細なガイドです。" - -#: ../../rst/scenario_guides/guide_aci.rst:656 -msgid "`Network Working Group `_" -msgstr "`Network Working Group `_" - -#: ../../rst/scenario_guides/guide_aci.rst:657 -msgid "The Ansible Network community page, includes contact information and meeting information." -msgstr "Ansible Network コミュニティーページ。連絡先情報およびミーティング情報が含まれます。" - -#: ../../rst/scenario_guides/guide_aci.rst:658 -msgid "`User Mailing List `_" -msgstr "`User Mailing List `_" - -#: ../../rst/scenario_guides/guide_aci.rst:659 -msgid "Have a question? Stop by the google group!" -msgstr "ご質問はございますか。Google Group をご覧ください。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:2 -msgid "Alibaba Cloud Compute Services Guide" -msgstr "Alibaba Cloud コンピュートサービスガイド" - -#: ../../rst/scenario_guides/guide_alicloud.rst:7 -#: ../../rst/scenario_guides/guide_cloudstack.rst:7 -#: ../../rst/scenario_guides/guide_gce.rst:7 -#: ../../rst/scenario_guides/guide_online.rst:6 -#: ../../rst/scenario_guides/guide_oracle.rst:7 -#: ../../rst/scenario_guides/guide_packet.rst:6 -#: ../../rst/scenario_guides/guide_rax.rst:7 -#: ../../rst/scenario_guides/guide_scaleway.rst:10 -#: ../../rst/scenario_guides/guide_vagrant.rst:7 -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:12 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:12 -msgid "Introduction" -msgstr "はじめに" - -#: ../../rst/scenario_guides/guide_alicloud.rst:9 -msgid "Ansible contains several modules for controlling and managing Alibaba Cloud Compute Services (Alicloud). This guide explains how to use the Alicloud Ansible modules together." -msgstr "Ansible には、Alibaba Cloud Compute Services (Alicloud) を制御および管理するためのモジュールが複数含まれています。Alicloud Ansible モジュールを一緒に使用する方法を説明します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:12 -msgid "All Alicloud modules require ``footmark`` - install it on your control machine with ``pip install footmark``." -msgstr "すべての Alicloud モジュールには ``footmark`` が必要です。これは、``pip install footmark`` で、コントロールマシンにインストールします。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:14 -msgid "Cloud modules, including Alicloud modules, execute on your local machine (the control machine) with ``connection: local``, rather than on remote machines defined in your hosts." -msgstr "Alicloud モジュールを含むクラウドモジュールは、ホストに定義されたリモートマシンではなく、ローカルマシン (コントロールマシン) で ``connection: local`` を使用して実行します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:16 -msgid "Normally, you'll use the following pattern for plays that provision Alicloud resources:" -msgstr "通常、Alicloud リソースをプロビジョニングするプレイには次のパターンを使用します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:30 -#: ../../rst/scenario_guides/guide_vultr.rst:45 -msgid "Authentication" -msgstr "認証" - -#: ../../rst/scenario_guides/guide_alicloud.rst:32 -msgid "You can specify your Alicloud authentication credentials (access key and secret key) by passing them as environment variables or by storing them in a vars file." -msgstr "Alicloud の認証情報 (アクセスキーおよびシークレットキー) を指定するには、その認証情報を環境変数として渡すか、vars ファイルに保存します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:35 -msgid "To pass authentication credentials as environment variables:" -msgstr "環境変数として認証情報を渡すには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:42 -msgid "To store authentication credentials in a vars_files, encrypt them with :ref:`Ansible Vault` to keep them secure, then list them:" -msgstr "認証情報を vars_file に保存するには、:ref:`Ansible Vault` で認証情報を暗号化してセキュアに維持してから、その認証情報の一覧を表示します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:50 -msgid "Note that if you store your credentials in a vars_files, you need to refer to them in each Alicloud module. For example:" -msgstr "認証情報を vars_file に保存する場合は、各 Alicloud モジュールで認証情報を参照する必要があることに注意してください。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:62 -#: ../../rst/scenario_guides/guide_rax.rst:86 -msgid "Provisioning" -msgstr "プロビジョニング" - -#: ../../rst/scenario_guides/guide_alicloud.rst:64 -msgid "Alicloud modules create Alicloud ECS instances, disks, virtual private clouds, virtual switches, security groups and other resources." -msgstr "Alicloud モジュールは、Alicloud ECS インスタンス、ディスク、仮想プライベートクラウド、仮想スイッチ、セキュリティーグループ、およびその他のリソースを作成します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:66 -msgid "You can use the ``count`` parameter to control the number of resources you create or terminate. For example, if you want exactly 5 instances tagged ``NewECS``, set the ``count`` of instances to 5 and the ``count_tag`` to ``NewECS``, as shown in the last task of the example playbook below. If there are no instances with the tag ``NewECS``, the task creates 5 new instances. If there are 2 instances with that tag, the task creates 3 more. If there are 8 instances with that tag, the task terminates 3 of those instances." -msgstr "``count`` パラメーターを使用して、作成または終了するリソースの数を制御することができます。たとえば、``NewECS`` とタグが付いたインスタンスが 5 つ必要な場合は、以下の Playbook の例の最後のタスクのように、インスタンスの ``count`` を 5 に、``count_tag`` を ``NewECS`` に、それぞれ設定します。タグが ``NewECS`` のインスタンスがない場合、タスクは 5 つの新規インスタンスを作成します。そのタグを持つインスタンスが 2 つある場合、このタスクはさらに 3 つのインスタンスを作成します。そのタグを持つ 8 つのインスタンスがある場合、タスクはそのインスタンスのうち 3 つを終了します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:71 -msgid "If you do not specify a ``count_tag``, the task creates the number of instances you specify in ``count`` with the ``instance_name`` you provide." -msgstr "``count_tag`` を指定しないと、タスクは、指定した ``instance_name`` で ``count`` に指定したインスタンスの数を作成します。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:129 -msgid "In the example playbook above, data about the vpc, vswitch, group, and instances created by this playbook are saved in the variables defined by the \"register\" keyword in each task." -msgstr "上記のサンプル Playbook では、この Playbook で作成される vpc、vswitch、group、およびインスタンスに関するデータが、各タスクの「register」キーワードで定義される変数に保存されます。" - -#: ../../rst/scenario_guides/guide_alicloud.rst:132 -msgid "Each Alicloud module offers a variety of parameter options. Not all options are demonstrated in the above example. See each individual module for further details and examples." -msgstr "各 Alicloud モジュールは、さまざまなパラメーターオプションを提供します。上記の例で、すべてのオプションが示されているわけではありません。詳細およびサンプルは、各モジュールを参照してください。" - -#: ../../rst/scenario_guides/guide_aws.rst:4 -msgid "Amazon Web Services Guide" -msgstr "Amazon Web Services ガイド" - -#: ../../rst/scenario_guides/guide_aws.rst:6 -msgid "The content on this page has moved. Please see the updated :ref:`ansible_collections.amazon.aws.docsite.aws_intro` in the AWS collection." -msgstr "このページのコンテンツは移動しました。AWSコレクションにある更新された :ref:`ansible_collections.amazon.aws.docsite.aws_intro` をご覧ください。" - -#: ../../rst/scenario_guides/guide_azure.rst:2 -msgid "Microsoft Azure Guide" -msgstr "Microsoft Azure ガイド" - -#: ../../rst/scenario_guides/guide_azure.rst:6 -msgid "Red Hat Ansible Automation Platform will soon be available on Microsoft Azure. `Sign up to preview the experience `_." -msgstr "Red Hat Ansible Automation Platform は、まもなく Microsoft Azure でも使用できるようになります。`Sign up to preview the experience `_。" - -#: ../../rst/scenario_guides/guide_azure.rst:8 -msgid "Ansible includes a suite of modules for interacting with Azure Resource Manager, giving you the tools to easily create and orchestrate infrastructure on the Microsoft Azure Cloud." -msgstr "Ansible には、Azure Resource Manager と対話するためのモジュールのスイートが含まれており、簡単に作成し、Microsoft Azure Cloud 上のインフラストラクチャーを調整するツールを提供します。" - -#: ../../rst/scenario_guides/guide_azure.rst:12 -#: ../../rst/scenario_guides/guide_oracle.rst:13 -#: ../../rst/scenario_guides/guide_packet.rst:16 -#: ../../rst/scenario_guides/guide_scaleway.rst:26 -#: ../../rst/scenario_guides/guide_vultr.rst:10 -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:12 -msgid "Requirements" -msgstr "要件" - -#: ../../rst/scenario_guides/guide_azure.rst:14 -msgid "Using the Azure Resource Manager modules requires having specific Azure SDK modules installed on the host running Ansible." -msgstr "Azure Resource Manager モジュールを使用するには、Ansible を実行しているホストに特定の Azure SDK モジュールをインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:21 -msgid "If you are running Ansible from source, you can install the dependencies from the root directory of the Ansible repo." -msgstr "ソースから Ansible を実行している場合は、Ansible リポジトリーの root ディレクトリーから依存関係をインストールできます。" - -#: ../../rst/scenario_guides/guide_azure.rst:28 -msgid "You can also directly run Ansible in `Azure Cloud Shell `_, where Ansible is pre-installed." -msgstr "また、Ansible が事前にインストールされている `Azure Cloud Shell `_ で Ansible を直接実行することもできます。" - -#: ../../rst/scenario_guides/guide_azure.rst:31 -msgid "Authenticating with Azure" -msgstr "API での認証" - -#: ../../rst/scenario_guides/guide_azure.rst:33 -msgid "Using the Azure Resource Manager modules requires authenticating with the Azure API. You can choose from two authentication strategies:" -msgstr "Azure Resource Manager モジュールを使用するには、Azure API で認証する必要があります。以下の認証ストラテジーを選択できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:35 -msgid "Active Directory Username/Password" -msgstr "Active Directory ユーザー名/パスワード" - -#: ../../rst/scenario_guides/guide_azure.rst:36 -msgid "Service Principal Credentials" -msgstr "サービスプリンシパルの認証情報" - -#: ../../rst/scenario_guides/guide_azure.rst:38 -msgid "Follow the directions for the strategy you wish to use, then proceed to `Providing Credentials to Azure Modules`_ for instructions on how to actually use the modules and authenticate with the Azure API." -msgstr "使用するストラテジーの指示に従い、実際にモジュールを使用して Azure API で認証する方法は、「`Azure モジュールへの認証情報の提供`_」を参照してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:43 -msgid "Using Service Principal" -msgstr "サービスプリンシパルの使用" - -#: ../../rst/scenario_guides/guide_azure.rst:45 -msgid "There is now a detailed official tutorial describing `how to create a service principal `_." -msgstr "「`サービスプリンシパルの作成方法 `_」を説明する詳細な公式チュートリアルがあります。" - -#: ../../rst/scenario_guides/guide_azure.rst:47 -msgid "After stepping through the tutorial you will have:" -msgstr "チュートリアルを実行すると、以下が可能になります。" - -#: ../../rst/scenario_guides/guide_azure.rst:49 -msgid "Your Client ID, which is found in the \"client id\" box in the \"Configure\" page of your application in the Azure portal" -msgstr "Azure ポータルのアプリケーションの「設定」ページの「クライアント ID」ボックスにあるクライアント ID。" - -#: ../../rst/scenario_guides/guide_azure.rst:50 -msgid "Your Secret key, generated when you created the application. You cannot show the key after creation. If you lost the key, you must create a new one in the \"Configure\" page of your application." -msgstr "シークレットキーは、アプリケーションの作成時に生成されます。キーが紛失した場合は、アプリケーションの「設定」ページで新しいキーを作成する必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:52 -msgid "And finally, a tenant ID. It's a UUID (for example, ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your application. You will find it in the URL from within the Azure portal, or in the \"view endpoints\" of any given URL." -msgstr "そして最後に、テナント ID です。これは、アプリケーションを含む AD を指し示す UUID (例: ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) です。この ID は、Azure ポータル内の URL や、指定の URL の「エンドポイントの表示」に記載されています。" - -#: ../../rst/scenario_guides/guide_azure.rst:57 -msgid "Using Active Directory Username/Password" -msgstr "Active Directory のユーザー名/パスワードの使用" - -#: ../../rst/scenario_guides/guide_azure.rst:59 -msgid "To create an Active Directory username/password:" -msgstr "Active Directory のユーザー名/パスワードを作成するには、以下を行います。" - -#: ../../rst/scenario_guides/guide_azure.rst:61 -msgid "Connect to the Azure Classic Portal with your admin account" -msgstr "管理者アカウントを使用して Azure Classic Portal に接続します。" - -#: ../../rst/scenario_guides/guide_azure.rst:62 -msgid "Create a user in your default AAD. You must NOT activate Multi-Factor Authentication" -msgstr "デフォルトの AAD でユーザーを作成します。マルチファクター認証をアクティブにしないでください。" - -#: ../../rst/scenario_guides/guide_azure.rst:63 -msgid "Go to Settings - Administrators" -msgstr "Settings、Administrator の順に移動します。" - -#: ../../rst/scenario_guides/guide_azure.rst:64 -msgid "Click on Add and enter the email of the new user." -msgstr "追加をクリックして、新規ユーザーのメールを入力します。" - -#: ../../rst/scenario_guides/guide_azure.rst:65 -msgid "Check the checkbox of the subscription you want to test with this user." -msgstr "このユーザーでテストするサブスクリプションのチェックボックスを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:66 -msgid "Login to Azure Portal with this new user to change the temporary password to a new one. You will not be able to use the temporary password for OAuth login." -msgstr "この新規ユーザーで Azure Portal にログインし、一時パスワードを新規パスワードに変更します。OAuth ログインに、一時パスワードを使用することはできません。" - -#: ../../rst/scenario_guides/guide_azure.rst:70 -msgid "Providing Credentials to Azure Modules" -msgstr "Azure モジュールへの認証情報の提供" - -#: ../../rst/scenario_guides/guide_azure.rst:72 -msgid "The modules offer several ways to provide your credentials. For a CI/CD tool such as Ansible AWX or Jenkins, you will most likely want to use environment variables. For local development you may wish to store your credentials in a file within your home directory. And of course, you can always pass credentials as parameters to a task within a playbook. The order of precedence is parameters, then environment variables, and finally a file found in your home directory." -msgstr "モジュールには、認証情報を提供するいくつかの方法があります。Ansible AWX や Jenkins のような CI/CD ツールでは、環境変数を使用することが多いでしょう。ローカルでの開発では、ホームディレクトリー内のファイルに認証情報を保存することができます。認証情報はパラメーターとして Playbook 内のタスクに渡すこともできます。優先される順序は、パラメーター、環境変数、および最後にホームディレクトリーにあるファイルになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:78 -msgid "Using Environment Variables" -msgstr "追加の環境変数" - -#: ../../rst/scenario_guides/guide_azure.rst:80 -msgid "To pass service principal credentials through the environment, define the following variables:" -msgstr "環境経由でサービスプリンシパルの認証情報を渡すには、以下の変数を定義します。" - -#: ../../rst/scenario_guides/guide_azure.rst:82 -#: ../../rst/scenario_guides/guide_azure.rst:97 -msgid "AZURE_CLIENT_ID" -msgstr "AZURE_CLIENT_ID" - -#: ../../rst/scenario_guides/guide_azure.rst:83 -msgid "AZURE_SECRET" -msgstr "AZURE_SECRET" - -#: ../../rst/scenario_guides/guide_azure.rst:84 -#: ../../rst/scenario_guides/guide_azure.rst:91 -msgid "AZURE_SUBSCRIPTION_ID" -msgstr "AZURE_SUBSCRIPTION_ID" - -#: ../../rst/scenario_guides/guide_azure.rst:85 -#: ../../rst/scenario_guides/guide_azure.rst:98 -msgid "AZURE_TENANT" -msgstr "AZURE_TENANT" - -#: ../../rst/scenario_guides/guide_azure.rst:87 -msgid "To pass Active Directory username/password through the environment, define the following variables:" -msgstr "環境経由で Active Directory のユーザー名/パスワードを渡すには、以下の変数を定義します。" - -#: ../../rst/scenario_guides/guide_azure.rst:89 -#: ../../rst/scenario_guides/guide_azure.rst:95 -msgid "AZURE_AD_USER" -msgstr "AZURE_AD_USER" - -#: ../../rst/scenario_guides/guide_azure.rst:90 -#: ../../rst/scenario_guides/guide_azure.rst:96 -msgid "AZURE_PASSWORD" -msgstr "AZURE_PASSWORD" - -#: ../../rst/scenario_guides/guide_azure.rst:93 -msgid "To pass Active Directory username/password in ADFS through the environment, define the following variables:" -msgstr "環境経由で ADFS に Active Directory のユーザー名/パスワードを渡すには、以下の変数を定義します。" - -#: ../../rst/scenario_guides/guide_azure.rst:99 -msgid "AZURE_ADFS_AUTHORITY_URL" -msgstr "AZURE_ADFS_AUTHORITY_URL" - -#: ../../rst/scenario_guides/guide_azure.rst:101 -msgid "\"AZURE_ADFS_AUTHORITY_URL\" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs." -msgstr "「AZURE_ADFS_AUTHORITY_URL」は任意です。これは、https://yourdomain.com/adfs といった独自の認証機関がある場合にのみ必要です。" - -#: ../../rst/scenario_guides/guide_azure.rst:104 -msgid "Storing in a File" -msgstr "ファイルへの保存" - -#: ../../rst/scenario_guides/guide_azure.rst:106 -msgid "When working in a development environment, it may be desirable to store credentials in a file. The modules will look for credentials in ``$HOME/.azure/credentials``. This file is an ini style file. It will look as follows:" -msgstr "開発環境で作業する場合は、ファイルに認証情報を保存することが望ましい場合があります。このモジュールは ``$HOME/.azure/credentials`` にある認証情報を探します。このファイルは ini 形式のファイルです。以下のようになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:117 -msgid "If your secret values contain non-ASCII characters, you must `URL Encode `_ them to avoid login errors." -msgstr "シークレット値に ASCII 以外の文字が含まれる場合は、ログインエラーを回避するために `URL エンコード `_ を行う必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:119 -msgid "It is possible to store multiple sets of credentials within the credentials file by creating multiple sections. Each section is considered a profile. The modules look for the [default] profile automatically. Define AZURE_PROFILE in the environment or pass a profile parameter to specify a specific profile." -msgstr "複数のセクションを作成することで、認証情報ファイルに複数の認証情報を保存することができます。各セクションはプロファイルとみなされます。モジュールは [default] プロファイルを自動的に検索します。環境内で AZURE_PROFILE を定義するか、特定のプロファイルを指定するために profile パラメーターを渡すことができます。" - -#: ../../rst/scenario_guides/guide_azure.rst:124 -msgid "Passing as Parameters" -msgstr "パラメーターとして渡す" - -#: ../../rst/scenario_guides/guide_azure.rst:126 -msgid "If you wish to pass credentials as parameters to a task, use the following parameters for service principal:" -msgstr "認証情報をパラメーターとしてタスクに渡すには、サービスプリンシパルについて以下のパラメーターを使用します。" - -#: ../../rst/scenario_guides/guide_azure.rst:128 -#: ../../rst/scenario_guides/guide_azure.rst:143 -msgid "client_id" -msgstr "client_id" - -#: ../../rst/scenario_guides/guide_azure.rst:129 -msgid "secret" -msgstr "secret" - -#: ../../rst/scenario_guides/guide_azure.rst:130 -#: ../../rst/scenario_guides/guide_azure.rst:137 -msgid "subscription_id" -msgstr "subscription_id" - -#: ../../rst/scenario_guides/guide_azure.rst:131 -#: ../../rst/scenario_guides/guide_azure.rst:144 -msgid "tenant" -msgstr "tenant" - -#: ../../rst/scenario_guides/guide_azure.rst:133 -msgid "Or, pass the following parameters for Active Directory username/password:" -msgstr "または Active Directory のユーザー名/パスワードについての以下のパラメーターを渡します。" - -#: ../../rst/scenario_guides/guide_azure.rst:135 -#: ../../rst/scenario_guides/guide_azure.rst:141 -msgid "ad_user" -msgstr "ad_user" - -#: ../../rst/scenario_guides/guide_azure.rst:139 -msgid "Or, pass the following parameters for ADFS username/password:" -msgstr "または、以下のパラメーターを ADFS ユーザー名またはパスワードに渡します。" - -#: ../../rst/scenario_guides/guide_azure.rst:145 -msgid "adfs_authority_url" -msgstr "adfs_authority_url" - -#: ../../rst/scenario_guides/guide_azure.rst:147 -msgid "\"adfs_authority_url\" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs." -msgstr "「adfs_authority_url」は任意です。これは、https://yourdomain.com/adfs といった独自の認証機関がある場合に限り必要です。" - -#: ../../rst/scenario_guides/guide_azure.rst:151 -msgid "Other Cloud Environments" -msgstr "その他のクラウド環境" - -#: ../../rst/scenario_guides/guide_azure.rst:153 -msgid "To use an Azure Cloud other than the default public cloud (for example, Azure China Cloud, Azure US Government Cloud, Azure Stack), pass the \"cloud_environment\" argument to modules, configure it in a credential profile, or set the \"AZURE_CLOUD_ENVIRONMENT\" environment variable. The value is either a cloud name as defined by the Azure Python SDK (for example, \"AzureChinaCloud\", \"AzureUSGovernment\"; defaults to \"AzureCloud\") or an Azure metadata discovery URL (for Azure Stack)." -msgstr "デフォルトのパブリッククラウド (Azure China Cloud、Azure US Government Cloud、Azure US Government Cloud、Azure Stack など) 以外の Azure Cloud を使用するには、「cloud_environment」引数をモジュールに渡すか、認証情報プロファイルでこれを設定するか、「AZURE_CLOUD_ENVIRONMENT」環境変数を設定します。この値は、Azure Python SDK で定義されるクラウド名 (例:「AzureChinaCloud」、「AzureUSGovernment」。デフォルトは「AzureCloud」) または Azure メタデータ検出 URL (Azure Stack 用) のいずれかになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:159 -msgid "Creating Virtual Machines" -msgstr "仮想マシンの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:161 -msgid "There are two ways to create a virtual machine, both involving the azure_rm_virtualmachine module. We can either create a storage account, network interface, security group and public IP address and pass the names of these objects to the module as parameters, or we can let the module do the work for us and accept the defaults it chooses." -msgstr "azure_rm_virtualmachine モジュールに関連する仮想マシンを作成する方法は 2 つあります。ストレージアカウント、ネットワークインターフェース、セキュリティーグループ、パブリック IP アドレスを作成し、これらのオブジェクトの名前をパラメーターとしてモジュールに渡す方法と、モジュールに作業を任せ、モジュールが選択するデフォルトを受け入れる方法です。" - -#: ../../rst/scenario_guides/guide_azure.rst:166 -msgid "Creating Individual Components" -msgstr "個別コンポーネントの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:168 -msgid "An Azure module is available to help you create a storage account, virtual network, subnet, network interface, security group and public IP. Here is a full example of creating each of these and passing the names to the ``azure.azcollection.azure_rm_virtualmachine`` module at the end:" -msgstr "Azure モジュールは、ストレージアカウント、仮想ネットワーク、サブネット、ネットワークインターフェース、セキュリティーグループ、およびパブリック IP の作成に役立ちます。ここでは、これらを作成し、最後に ``azure.azcollection.azure_rm_virtualmachine`` モジュールに名前を渡すための完全な例を紹介します。" - -#: ../../rst/scenario_guides/guide_azure.rst:237 -msgid "Each of the Azure modules offers a variety of parameter options. Not all options are demonstrated in the above example. See each individual module for further details and examples." -msgstr "Azure の各モジュールは、さまざまなパラメーターオプションを提供します。上記の例で、すべてのオプションが示されているわけではありません。詳細およびサンプルは、各モジュールを参照してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:242 -msgid "Creating a Virtual Machine with Default Options" -msgstr "デフォルトオプションを使用した仮想マシンの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:244 -msgid "If you simply want to create a virtual machine without specifying all the details, you can do that as well. The only caveat is that you will need a virtual network with one subnet already in your resource group. Assuming you have a virtual network already with an existing subnet, you can run the following to create a VM:" -msgstr "すべての詳細を指定せずに仮想マシンを作成する場合は、これも実行できます。唯一の注意点は、リソースグループ内に 1 つのサブネットを持つ仮想ネットワークが必要となることです。既存サブネットを使用する仮想ネットワークが既にある場合は、以下のように実行して仮想マシンを作成できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:265 -msgid "Creating a Virtual Machine in Availability Zones" -msgstr "アベイラビリティーゾーンでの仮想マシンの作成" - -#: ../../rst/scenario_guides/guide_azure.rst:267 -msgid "If you want to create a VM in an availability zone, consider the following:" -msgstr "アベイラビリティーゾーンに仮想マシンを作成する場合は、以下を検討してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:270 -msgid "Both OS disk and data disk must be a 'managed disk', not an 'unmanaged disk'." -msgstr "OS ディスクとデータディスクはいずれも「非管理ディスク」ではなく、「管理ディスク」である必要があります。" - -#: ../../rst/scenario_guides/guide_azure.rst:271 -msgid "When creating a VM with the ``azure.azcollection.azure_rm_virtualmachine`` module, you need to explicitly set the ``managed_disk_type`` parameter to change the OS disk to a managed disk. Otherwise, the OS disk becomes an unmanaged disk." -msgstr "``azure.azcollection.azure_rm_virtualmachine`` モジュールで仮想マシンを作成する場合は、``managed_disk_type`` パラメーターを明示的に設定して OS ディスクを管理ディスクに変更します。そうでないと、OS ディスクは非管理ディスクになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:275 -msgid "When you create a data disk with the ``azure.azcollection.azure_rm_manageddisk`` module, you need to explicitly specify the ``storage_account_type`` parameter to make it a managed disk. Otherwise, the data disk will be an unmanaged disk." -msgstr "``azure.azcollection.azure_rm_manageddisk`` モジュールでデータディスクを作成する場合は、``storage_account_type`` パラメーターを明示的に指定して管理ディスクを作成する必要があります。そうでないと、データディスクは非管理ディスクになります。" - -#: ../../rst/scenario_guides/guide_azure.rst:279 -msgid "A managed disk does not require a storage account or a storage container, unlike an unmanaged disk. In particular, note that once a VM is created on an unmanaged disk, an unnecessary storage container named \"vhds\" is automatically created." -msgstr "管理ディスクは、非管理ディスクと異なり、ストレージアカウントやストレージコンテナーを必要としません。特に、非管理ディスクに仮想マシン作成すると、「vhds」という名前の不要なストレージコンテナーが自動的に作成されることに注意してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:283 -msgid "When you create an IP address with the ``azure.azcollection.azure_rm_publicipaddress`` module, you must set the ``sku`` parameter to ``standard``. Otherwise, the IP address cannot be used in an availability zone." -msgstr "``azure.azcollection.azure_rm_publicipaddress`` モジュールで IP アドレスを作成する場合は、``sku`` パラメーターを ``standard`` に設定する必要があります。そうでない場合は、アベイラビリティーゾーンで IP アドレスを使用することができません。" - -#: ../../rst/scenario_guides/guide_azure.rst:289 -#: ../../rst/scenario_guides/guide_packet.rst:207 -#: ../../rst/scenario_guides/guide_scaleway.rst:170 -msgid "Dynamic Inventory Script" -msgstr "動的インベントリースクリプト" - -#: ../../rst/scenario_guides/guide_azure.rst:291 -msgid "If you are not familiar with Ansible's dynamic inventory scripts, check out :ref:`Intro to Dynamic Inventory `." -msgstr "Ansible の動的インベントリースクリプトに慣れていない場合は、「:ref:`動的インベントリーの概要 `」を参照してください。" - -#: ../../rst/scenario_guides/guide_azure.rst:293 -msgid "The Azure Resource Manager inventory script is called `azure_rm.py `_. It authenticates with the Azure API exactly the same as the Azure modules, which means you will either define the same environment variables described above in `Using Environment Variables`_, create a ``$HOME/.azure/credentials`` file (also described above in `Storing in a File`_), or pass command line parameters. To see available command line options execute the following:" -msgstr "Azure Resource Manager インベントリースクリプトは `azure_rm.py `_ と呼ばれます。Azure API での認証は Azure モジュールと同じになります。つまり、「`Using Environment Variables`_」で説明されている環境変数と同じ環境変数を定義するか、``$HOME/.azure/credentials`` ファイルを作成するか (「`Storing in a File`_」を参照)、またはコマンドラインパラメーターを渡します。利用可能なコマンドラインオプションを表示するには、以下のコマンドを実行します。" - -#: ../../rst/scenario_guides/guide_azure.rst:303 -msgid "As with all dynamic inventory scripts, the script can be executed directly, passed as a parameter to the ansible command, or passed directly to ansible-playbook using the -i option. No matter how it is executed the script produces JSON representing all of the hosts found in your Azure subscription. You can narrow this down to just hosts found in a specific set of Azure resource groups, or even down to a specific host." -msgstr "すべての動的インベントリースクリプトと同様に、このスクリプトは直接実行することも、ansible コマンドのパラメータとして渡すことも、-i オプションを使用して ansible-playbook に直接渡すこともできます。どのように実行しても、スクリプトは、Azure サブスクリプションで見つかったすべてのホストを表す JSON を生成します。これを、特定の Azure リソースグループのセットで見つかったホストだけに絞り込んだり、特定のホストに絞り込んだりすることができます。" - -#: ../../rst/scenario_guides/guide_azure.rst:308 -msgid "For a given host, the inventory script provides the following host variables:" -msgstr "インベントリースクリプトは、指定のホストに対して以下のホスト変数を提供します。" - -#: ../../rst/scenario_guides/guide_azure.rst:354 -msgid "Host Groups" -msgstr "ホストグループ" - -#: ../../rst/scenario_guides/guide_azure.rst:356 -msgid "By default hosts are grouped by:" -msgstr "デフォルトでは、ホストは以下のようにグループ化されます。" - -#: ../../rst/scenario_guides/guide_azure.rst:358 -msgid "azure (all hosts)" -msgstr "azure (全てのホスト)" - -#: ../../rst/scenario_guides/guide_azure.rst:359 -msgid "location name" -msgstr "ロケーション名" - -#: ../../rst/scenario_guides/guide_azure.rst:360 -msgid "resource group name" -msgstr "リソースグループ名" - -#: ../../rst/scenario_guides/guide_azure.rst:361 -msgid "security group name" -msgstr "セキュリティーグループ名" - -#: ../../rst/scenario_guides/guide_azure.rst:362 -msgid "tag key" -msgstr "タグキー" - -#: ../../rst/scenario_guides/guide_azure.rst:363 -msgid "tag key_value" -msgstr "タグの key_value" - -#: ../../rst/scenario_guides/guide_azure.rst:364 -msgid "os_disk operating_system_type (Windows/Linux)" -msgstr "os_disk operating_system_type (Windows/Linux)" - -#: ../../rst/scenario_guides/guide_azure.rst:366 -msgid "You can control host groupings and host selection by either defining environment variables or creating an azure_rm.ini file in your current working directory." -msgstr "環境変数を定義するか、現在の作業ディレクトリーに azure_rm.ini ファイルを作成して、ホストのグループ化とホストの選択を制御できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:369 -msgid "NOTE: An .ini file will take precedence over environment variables." -msgstr "注記: .ini ファイルは環境変数よりも優先されます。" - -#: ../../rst/scenario_guides/guide_azure.rst:371 -msgid "NOTE: The name of the .ini file is the basename of the inventory script (in other words, 'azure_rm') with a '.ini' extension. This allows you to copy, rename and customize the inventory script and have matching .ini files all in the same directory." -msgstr "注記: .ini ファイルの名前は、「.ini」拡張子が付いたインベントリースクリプトのベース名 (つまり「azure_rm」) です。これにより、インベントリースクリプトのコピー、名前変更、カスタマイズが可能となり、すべて同じディレクトリー内の .ini ファイルが一致します。" - -#: ../../rst/scenario_guides/guide_azure.rst:375 -msgid "Control grouping using the following variables defined in the environment:" -msgstr "環境で定義された以下の変数を使用してグループ化を制御します。" - -#: ../../rst/scenario_guides/guide_azure.rst:377 -msgid "AZURE_GROUP_BY_RESOURCE_GROUP=yes" -msgstr "AZURE_GROUP_BY_RESOURCE_GROUP=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:378 -msgid "AZURE_GROUP_BY_LOCATION=yes" -msgstr "AZURE_GROUP_BY_LOCATION=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:379 -msgid "AZURE_GROUP_BY_SECURITY_GROUP=yes" -msgstr "AZURE_GROUP_BY_SECURITY_GROUP=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:380 -msgid "AZURE_GROUP_BY_TAG=yes" -msgstr "AZURE_GROUP_BY_TAG=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:381 -msgid "AZURE_GROUP_BY_OS_FAMILY=yes" -msgstr "AZURE_GROUP_BY_OS_FAMILY=yes" - -#: ../../rst/scenario_guides/guide_azure.rst:383 -msgid "Select hosts within specific resource groups by assigning a comma separated list to:" -msgstr "コンマ区切りリストを割り当てて、特定のリソースグループ内のホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:385 -msgid "AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b" -msgstr "AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b" - -#: ../../rst/scenario_guides/guide_azure.rst:387 -msgid "Select hosts for specific tag key by assigning a comma separated list of tag keys to:" -msgstr "タグキーのコンマ区切りリストを割り当てて、定のタグキーのホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:389 -msgid "AZURE_TAGS=key1,key2,key3" -msgstr "AZURE_TAGS=key1,key2,key3" - -#: ../../rst/scenario_guides/guide_azure.rst:391 -msgid "Select hosts for specific locations by assigning a comma separated list of locations to:" -msgstr "ロケーションのコンマ区切りリストを割り当てて、特定のロケーションのホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:393 -msgid "AZURE_LOCATIONS=eastus,eastus2,westus" -msgstr "AZURE_LOCATIONS=eastus,eastus2,westus" - -#: ../../rst/scenario_guides/guide_azure.rst:395 -msgid "Or, select hosts for specific tag key:value pairs by assigning a comma separated list key:value pairs to:" -msgstr "または、コンマ区切りのリスト key:value ペアを割り当て、特定のタグ key:value ペアのホストを選択します。" - -#: ../../rst/scenario_guides/guide_azure.rst:397 -msgid "AZURE_TAGS=key1:value1,key2:value2" -msgstr "AZURE_TAGS=key1:value1,key2:value2" - -#: ../../rst/scenario_guides/guide_azure.rst:399 -msgid "If you don't need the powerstate, you can improve performance by turning off powerstate fetching:" -msgstr "電源状態を必要としない場合は、電源状態の取得をオフにしてパフォーマンスを向上させることができます。" - -#: ../../rst/scenario_guides/guide_azure.rst:401 -msgid "AZURE_INCLUDE_POWERSTATE=no" -msgstr "AZURE_INCLUDE_POWERSTATE=no" - -#: ../../rst/scenario_guides/guide_azure.rst:403 -msgid "A sample azure_rm.ini file is included along with the inventory script in `here `_. An .ini file will contain the following:" -msgstr "azure_rm.ini ファイルのサンプルは、`here `_ のインベントリースクリプトとともに含まれています。.ini ファイルには、以下が含まれます。" - -#: ../../rst/scenario_guides/guide_azure.rst:432 -#: ../../rst/scenario_guides/guide_oracle.rst:73 -msgid "Examples" -msgstr "例" - -#: ../../rst/scenario_guides/guide_azure.rst:434 -msgid "Here are some examples using the inventory script:" -msgstr "以下は、インベントリースクリプトの使用例です。" - -#: ../../rst/scenario_guides/guide_azure.rst:456 -msgid "Here is a simple playbook to exercise the Azure inventory script:" -msgstr "以下は、Azure インベントリースクリプトを実行するための単純な Playbook です。" - -#: ../../rst/scenario_guides/guide_azure.rst:468 -msgid "You can execute the playbook with something like:" -msgstr "Playbook は以下のような方法で実行できます。" - -#: ../../rst/scenario_guides/guide_azure.rst:476 -msgid "Disabling certificate validation on Azure endpoints" -msgstr "Azure エンドポイントでの証明書検証の無効化" - -#: ../../rst/scenario_guides/guide_azure.rst:478 -msgid "When an HTTPS proxy is present, or when using Azure Stack, it may be necessary to disable certificate validation for Azure endpoints in the Azure modules. This is not a recommended security practice, but may be necessary when the system CA store cannot be altered to include the necessary CA certificate. Certificate validation can be controlled by setting the \"cert_validation_mode\" value in a credential profile, through the \"AZURE_CERT_VALIDATION_MODE\" environment variable, or by passing the \"cert_validation_mode\" argument to any Azure module. The default value is \"validate\"; setting the value to \"ignore\" will prevent all certificate validation. The module argument takes precedence over a credential profile value, which takes precedence over the environment value." -msgstr "HTTPS プロキシーが存在する場合、または Azure Stack を使用している場合は、Azure モジュールで Azure エンドポイントの証明書検証を無効にしなければならない場合があります。これは推奨されるセキュリティー対策ではありませんが、システム CA ストアを変更して必要な CA 証明書を含めることができない場合に必要になることがあります。証明書の検証は、認証情報プロファイルで「cert_validation_mode」値を設定するか、環境変数「AZURE_CERT_VALIDATION_MODE」を経由するか、「cert_validation_mode」引数を任意の Azure モジュールに渡すことで制御できます。デフォルト値は「validate」で、「ignore」に設定すると証明書の検証は行われません。モジュールの引数は、環境の値よりも優先される認証情報プロファイルの値よりも優先されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:2 -msgid "CloudStack Cloud Guide" -msgstr "CloudStack Cloud ガイド" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:8 -msgid "The purpose of this section is to explain how to put Ansible modules together to use Ansible in a CloudStack context. You will find more usage examples in the details section of each module." -msgstr "本セクションの目的は、Ansible モジュールを 1 つにまとめて CloudStack コンテキストで Ansible を使用する方法を説明します。詳細は、各モジュールの詳細セクションを参照してください。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:10 -msgid "Ansible contains a number of extra modules for interacting with CloudStack based clouds. All modules support check mode, are designed to be idempotent, have been created and tested, and are maintained by the community." -msgstr "Ansible には、CloudStack ベースのクラウドと対話するための追加モジュールが多数含まれています。モジュールサポートのチェックモードはすべて、冪等性があり、コミュニティーによって作成、テストされ、維持されています。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:12 -msgid "Some of the modules will require domain admin or root admin privileges." -msgstr "一部のモジュールには、ドメイン管理または root 管理者権限が必要です。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:15 -#: ../../rst/scenario_guides/guide_infoblox.rst:16 -#: ../../rst/scenario_guides/scenario_template.rst:17 -msgid "Prerequisites" -msgstr "要件" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:16 -msgid "Prerequisites for using the CloudStack modules are minimal. In addition to Ansible itself, all of the modules require the python library ``cs`` https://pypi.org/project/cs/" -msgstr "CloudStack モジュールを使用するための前提条件は最小限です。Ansible 自体に加えて、すべてのモジュールには python ライブラリー ``cs`` https://pypi.org/project/cs/ が必要です。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:18 -msgid "You'll need this Python module installed on the execution host, usually your workstation." -msgstr "この Python モジュールは、実行ホスト (通常はワークステーション) にインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:24 -msgid "Or alternatively starting with Debian 9 and Ubuntu 16.04:" -msgstr "もしくは、Debian 9 および Ubuntu 16.04 から始まります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:30 -msgid "cs also includes a command line interface for ad hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``." -msgstr "cs には、CloudStack API とのアドホック対話用のコマンドラインインターフェース (例: ``$ cs listVirtualMachines state=Running``) も含まれます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:33 -msgid "Limitations and Known Issues" -msgstr "制限および既知の問題" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:34 -msgid "VPC support has been improved since Ansible 2.3 but is still not yet fully implemented. The community is working on the VPC integration." -msgstr "Ansible 2.3 以降、VPC サポートが改善されましたが、まだ実装されていません。コミュニティーは VPC の統合に取り組んでいます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:37 -#: ../../rst/scenario_guides/guide_rax.rst:48 -msgid "Credentials File" -msgstr "認証情報ファイル" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:38 -msgid "You can pass credentials and the endpoint of your cloud as module arguments, however in most cases it is a far less work to store your credentials in the cloudstack.ini file." -msgstr "認証情報とクラウドのエンドポイントをモジュール引数として渡すことができますが、ほとんどの場合、認証情報を cloudstack.ini ファイルに保存する作業ははるかに少なくなります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:40 -msgid "The python library cs looks for the credentials file in the following order (last one wins):" -msgstr "Python ライブラリー cs は、以下の順番で認証情報ファイルを検索します (最後のコピーが優先されます)。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:42 -msgid "A ``.cloudstack.ini`` (note the dot) file in the home directory." -msgstr "ホームディレクトリーの ``.cloudstack.ini`` ファイル (ドットに注意)。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:43 -msgid "A ``CLOUDSTACK_CONFIG`` environment variable pointing to an .ini file." -msgstr ".ini ファイルを参照する ``CLOUDSTACK_CONFIG`` 環境変数。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:44 -msgid "A ``cloudstack.ini`` (without the dot) file in the current working directory, same directory as your playbooks are located." -msgstr "現在の作業ディレクトリー内の ``cloudstack.ini`` ファイル (ドットなし) は、Playbook が置かれているディレクトリーと同じディレクトリーです。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:46 -msgid "The structure of the ini file must look like this:" -msgstr "ini ファイルの構造は以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:57 -msgid "The section ``[cloudstack]`` is the default section. ``CLOUDSTACK_REGION`` environment variable can be used to define the default section." -msgstr "``[cloudstack]`` セクションはデフォルトのセクションです。``CLOUDSTACK_REGION`` 環境変数を使用して、デフォルトのセクションを定義できます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:61 -msgid "The ENV variables support ``CLOUDSTACK_*`` as written in the documentation of the library ``cs``, like ``CLOUDSTACK_TIMEOUT``, ``CLOUDSTACK_METHOD``, and so on. has been implemented into Ansible. It is even possible to have some incomplete config in your cloudstack.ini:" -msgstr "ENV 変数はライブラリー ``cs`` のドキュメントに記載されているように、``CLOUDSTACK_TIMEOUT``、``CLOUDSTACK_METHOD`` などの ``CLOUDSTACK_*`` をサポートします。cloudstack.ini に不完全な設定の一部を含めることもできます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:70 -msgid "and fulfill the missing data by either setting ENV variables or tasks params:" -msgstr "ENV 変数または tasks パラメーターを設定して、不足しているデータに対応します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:86 -msgid "Regions" -msgstr "リージョン" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:87 -msgid "If you use more than one CloudStack region, you can define as many sections as you want and name them as you like, for example:" -msgstr "複数の CloudStack リージョンを使用する場合は、必要な数だけセクションを定義し、任意の名前を付けることができます。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:107 -msgid "Sections can also be used to for login into the same region using different accounts." -msgstr "セクションは、異なるアカウントを使用して同じリージョンにログインするのにも使用できます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:109 -msgid "By passing the argument ``api_region`` with the CloudStack modules, the region wanted will be selected." -msgstr "CloudStack モジュールで引数 ``api_region`` を渡すと、希望のリージョンが選択されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:120 -msgid "Or by looping over a regions list if you want to do the task in every region:" -msgstr "または、すべてのリージョンでタスクを実行する場合は、リージョンリストをループします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:135 -msgid "Environment Variables" -msgstr "環境変数" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:138 -msgid "Since Ansible 2.3 it is possible to use environment variables for domain (``CLOUDSTACK_DOMAIN``), account (``CLOUDSTACK_ACCOUNT``), project (``CLOUDSTACK_PROJECT``), VPC (``CLOUDSTACK_VPC``) and zone (``CLOUDSTACK_ZONE``). This simplifies the tasks by not repeating the arguments for every tasks." -msgstr "Ansible 2.3 以降、ドメイン (``CLOUDSTACK_DOMAIN``)、アカウント (``CLOUDSTACK_ACCOUNT``)、プロジェクト (``CLOUDSTACK_PROJECT``)、VPC (``CLOUDSTACK_VPC``)、およびゾーン (``CLOUDSTACK_ZONE``) に環境変数を使用することができます。これにより、全タスクの引数を繰り返す必要がなくなり、タスクが簡素化されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:140 -msgid "Below you see an example how it can be used in combination with Ansible's block feature:" -msgstr "以下は、Ansible のブロック機能と組み合わせて使用する例を示しています。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:166 -msgid "You are still able overwrite the environment variables using the module arguments, for example ``zone: sf-2``" -msgstr "モジュールの引数を使用して環境変数を上書きできます (例: ``zone: sf-2``)。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:168 -msgid "Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ignored in the CLI ``cs``." -msgstr "``CLOUDSTACK_REGION`` とは異なり、CLI ``cs`` ではこれらの追加の環境変数は無視されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:171 -#: ../../rst/scenario_guides/guide_rax.rst:406 -msgid "Use Cases" -msgstr "ユースケース" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:172 -msgid "The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start." -msgstr "以下では、モジュールを使用して仮想マシンをクラウドにプロビジョニングする方法を示します。これを行う方法は 1 つではありませんが、最初はシンプルにすることが推奨されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:175 -msgid "Use Case: Provisioning in a Advanced Networking CloudStack setup" -msgstr "ユースケース: Advanced Networking CloudStack 設定でのプロビジョニング" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:176 -msgid "Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host." -msgstr "CloudStack クラウドには高度なネットワーク設定があり、静的な NAT を取得し、ファイアウォールポート 80 および 443 を開く Web サーバーのプロビジョニングを行います。また、データベースサーバーもプロビジョニングしますが、これにはアクセス権が付与されていません。SSH による仮想マシンへのアクセスには SSH ジャンプホストを使用します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:178 -#: ../../rst/scenario_guides/guide_cloudstack.rst:285 -msgid "This is how our inventory looks like:" -msgstr "インベントリーは以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:198 -msgid "As you can see, the public IPs for our web servers and jumphost has been assigned as variable ``public_ip`` directly in the inventory." -msgstr "ご覧のように、Web サーバーおよびジャンプホストのパブリック IP は、インベントリーで直接変数 ``public_ip`` として割り当てられます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:200 -msgid "The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifying the defaults of our cloud infrastructure." -msgstr "ジャンプホスト、Web サーバー、およびデータベースサーバーを設定します。``group_vars`` を使用します。``group_vars`` ディレクトリーには、グループ設定用の 4 つのファイル (cloud-vm、jumphost、webserver、および db-server) を含みます。cloud-vm はクラウドインフラストラクチャーのデフォルトを指定するために存在します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:209 -msgid "Our database servers should get more CPU and RAM, so we define to use a ``Large`` offering for them." -msgstr "データベースサーバーはより多くの CPU および RAM を取得する必要があるため、``Large`` オファリングの使用を定義します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:217 -msgid "The web servers should get a ``Small`` offering as we would scale them horizontally, which is also our default offering. We also ensure the known web ports are opened for the world." -msgstr "Web サーバーは、水平方向に拡張するため、``Small`` を提供しています。これは、デフォルトのオファリングでもあります。また、既知の Web ポートがグローバルに開いていることを確認します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:227 -msgid "Further we provision a jump host which has only port 22 opened for accessing the VMs from our office IPv4 network." -msgstr "さらに、オフィス IPv4 ネットワークから仮想マシンにアクセスするためにポート 22 のみを開くジャンプホストをプロビジョニングします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:236 -msgid "Now to the fun part. We create a playbook to create our infrastructure we call it ``infra.yml``:" -msgstr "ここからが重要です。インフラストラクチャーを構築するための Playbook を作成します。これは、``infra.yml`` と呼ばれます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:267 -msgid "In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``delegate_to: localhost`` to execute the API calls locally from our workstation." -msgstr "上記のプレイでは、3 つのタスクを定義し、グループ ``cloud-vm`` をターゲットとして使用し、クラウド内の仮想マシンをすべて処理しますが、代わりにこれらの仮想マシンに SSH を使用するため、``delegate_to: localhost`` を使用してワークステーションからローカルに API 呼び出しを実行します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:269 -msgid "In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again." -msgstr "最初のタスクでは、Debian テンプレートで実行中の仮想マシンが作成されていることを確認しました。仮想マシンが作成されていて停止している場合は、開始するだけです。既存の仮想マシンでオファリングを変更する場合は ``force: yes`` をタスクに追加します。これにより、仮想マシンは停止し、オファリングを変更して再度仮想マシンを開始します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:271 -msgid "In the second task we ensure the ports are opened if we give a public IP to the VM." -msgstr "2 つ目のタスクでは、仮想マシンにパブリック IP を付与した場合にポートが開くようにします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:273 -msgid "In the third task we add static NAT to the VMs having a public IP defined." -msgstr "3 つ目のタスクでは、パブリック IP が定義されている仮想マシンに静的 NAT を追加します。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:276 -msgid "The public IP addresses must have been acquired in advance, also see ``cs_ip_address``" -msgstr "パブリック IP アドレスは事前に取得されている必要があります。「``cs_ip_address``」を参照してください。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:278 -msgid "For some modules, for example ``cs_sshkeypair`` you usually want this to be executed only once, not for every VM. Therefore you would make a separate play for it targeting localhost. You find an example in the use cases below." -msgstr "たとえば、``cs_sshkeypair`` などの一部のモジュールでは、仮想マシンごとに一度だけこれを実行する必要があります。ローカルホストを対象とする別のプレイを作成します。以下のユースケースで例を見てみましょう。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:281 -msgid "Use Case: Provisioning on a Basic Networking CloudStack setup" -msgstr "ユースケース: 基本的なネットワーク CloudStack 設定のプロビジョニング" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:283 -msgid "A basic networking CloudStack setup is slightly different: Every VM gets a public IP directly assigned and security groups are used for access restriction policy." -msgstr "基本的なネットワーク CloudStack の設定は若干異なります。すべての仮想マシンが直接割り当てられたパブリック IP を取得し、セキュリティーグループがアクセス制限ポリシーに使用されます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:296 -msgid "The default for your VMs looks like this:" -msgstr "仮想マシンのデフォルトは以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:305 -msgid "Our webserver will also be in security group ``web``:" -msgstr "Web サーバーもセキュリティーグループ ``web`` に含まれます。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:313 -msgid "The playbook looks like the following:" -msgstr "Playbook は以下のようになります。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:375 -msgid "In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accessing the VMs with their DNS name." -msgstr "最初のプレイでは、セキュリティグループを設定し、2 つ目のプレイでは、仮想マシンがこれらのグループに割り当てられるように作成されます。さらに、モジュールから返されたパブリック IP をホストのインベントリーに割り当てることが確認できます。これは、事前に取得する IP を把握していないため必要になります。次のステップでは、このような IP を使用して DNS サーバーを設定し、仮想マシンに DNS 名でアクセスできるようにします。" - -#: ../../rst/scenario_guides/guide_cloudstack.rst:377 -msgid "In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure." -msgstr "最後のタスクでは、SSH がアクセス可能になるのを待ちます。したがって、後続のプレイでは、SSH で仮想マシンにアクセスする際に失敗せずに実行できます。" - -#: ../../rst/scenario_guides/guide_docker.rst:4 -msgid "Docker Guide" -msgstr "Docker ガイド" - -#: ../../rst/scenario_guides/guide_docker.rst:6 -msgid "The content on this page has moved. Please see the updated :ref:`ansible_collections.community.docker.docsite.scenario_guide` in the `community.docker collection `_." -msgstr "このページのコンテンツは移動しました。`community.docker collection `_ にある更新された :ref:`ansible_collections.community.docker.docsite.scenario_guide` をご覧ください。" - -#: ../../rst/scenario_guides/guide_gce.rst:2 -msgid "Google Cloud Platform Guide" -msgstr "Google Cloud Platform ガイド" - -#: ../../rst/scenario_guides/guide_gce.rst:9 -msgid "Ansible + Google have been working together on a set of auto-generated Ansible modules designed to consistently and comprehensively cover the entirety of the Google Cloud Platform (GCP)." -msgstr "Ansible および Google はともに、Google Cloud Platform (GCP) 全体を一貫して包括的に対応するために設計された、自動生成される Ansible モジュールのセットを開発しました。" - -#: ../../rst/scenario_guides/guide_gce.rst:13 -msgid "Ansible contains modules for managing Google Cloud Platform resources, including creating instances, controlling network access, working with persistent disks, managing load balancers, and a lot more." -msgstr "Ansible には、インスタンスの作成、ネットワークアクセスの制御、永続的なディスクの使用、ロードバランサーの管理など、Google Cloud Platform リソースを管理するためのモジュールが含まれます。" - -#: ../../rst/scenario_guides/guide_gce.rst:17 -msgid "These new modules can be found under a new consistent name scheme \"gcp_*\" (Note: gcp_target_proxy and gcp_url_map are legacy modules, despite the \"gcp_*\" name. Please use gcp_compute_target_proxy and gcp_compute_url_map instead)." -msgstr "これらの新しいモジュールは、新しい一貫した名前スキーム「gcp_*」で見つけることができます (注: gcp_target_proxy および gcp_url_map は 「gcp_*」の名前ですが、レガシーモジュールです。代わりに gcp_compute_target_proxy および gcp_compute_url_map を使用してください)。" - -#: ../../rst/scenario_guides/guide_gce.rst:21 -msgid "Additionally, the gcp_compute inventory plugin can discover all Google Compute Engine (GCE) instances and make them automatically available in your Ansible inventory." -msgstr "さらに、gcp_compute インベントリープラグインは、すべての Google Compute Engine(GCE) インスタンスを検出し、Ansible インベントリーで自動的に利用可能にすることができます。" - -#: ../../rst/scenario_guides/guide_gce.rst:25 -msgid "You may see a collection of other GCP modules that do not conform to this naming convention. These are the original modules primarily developed by the Ansible community. You will find some overlapping functionality such as with the \"gce\" module and the new \"gcp_compute_instance\" module. Either can be used, but you may experience issues trying to use them together." -msgstr "この命名規則に準拠していない他の GCP モジュールのコレクションが表示されることがあります。これらは、主に Ansible コミュニティーによって開発されたオリジナルのモジュールです。「gce」モジュールと新しい「gcp_compute_instance」モジュールのように、機能が重複しているものがあります。どちらを使用しても構いませんが、一緒に使用すると問題が発生する可能性があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:31 -msgid "While the community GCP modules are not going away, Google is investing effort into the new \"gcp_*\" modules. Google is committed to ensuring the Ansible community has a great experience with GCP and therefore recommends adopting these new modules if possible." -msgstr "コミュニティーの GCP モジュールはなくなるわけではありませんが、Google は新しい「gcp_*」モジュールに力を注いでいます。Google は、Ansible コミュニティーが GCP で豊富な経験があることを確かにするためにコミットされているため、可能な場合はこれらの新規モジュールの導入を推奨しています。" - -#: ../../rst/scenario_guides/guide_gce.rst:38 -msgid "Requisites" -msgstr "要件" - -#: ../../rst/scenario_guides/guide_gce.rst:39 -msgid "The GCP modules require both the ``requests`` and the ``google-auth`` libraries to be installed." -msgstr "GCP モジュールでは、``requests`` ライブラリーと ``google-auth`` ライブラリーの両方をインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:46 -msgid "Alternatively for RHEL / CentOS, the ``python-requests`` package is also available to satisfy ``requests`` libraries." -msgstr "RHEL/CentOS の場合は、``python-requests`` ライブラリーを満たすために ``requests`` パッケージも利用できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:54 -msgid "Credentials" -msgstr "認証情報" - -#: ../../rst/scenario_guides/guide_gce.rst:55 -msgid "It's easy to create a GCP account with credentials for Ansible. You have multiple options to get your credentials - here are two of the most common options:" -msgstr "Ansible の認証情報を使用して GCP アカウントを作成できます。認証情報を取得するオプションは複数あります。以下に、最も一般的なオプションの 2 つがあります。" - -#: ../../rst/scenario_guides/guide_gce.rst:58 -msgid "Service Accounts (Recommended): Use JSON service accounts with specific permissions." -msgstr "サービスアカウント (推奨): 特定のパーミッションを持つ JSON サービスアカウントを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:59 -msgid "Machine Accounts: Use the permissions associated with the GCP Instance you're using Ansible on." -msgstr "マシンアカウント: Ansible をお使いの GCP インスタンスに関連付けられたパーミッションを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:61 -msgid "For the following examples, we'll be using service account credentials." -msgstr "以下の例では、サービスアカウントの認証情報を使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:63 -msgid "To work with the GCP modules, you'll first need to get some credentials in the JSON format:" -msgstr "GCP モジュールを使用するには、最初に JSON 形式でいくつかの認証情報を取得する必要があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:66 -msgid "`Create a Service Account `_" -msgstr "`Create a Service Account `_" - -#: ../../rst/scenario_guides/guide_gce.rst:67 -msgid "`Download JSON credentials `_" -msgstr "`Download JSON credentials `_" - -#: ../../rst/scenario_guides/guide_gce.rst:69 -msgid "Once you have your credentials, there are two different ways to provide them to Ansible:" -msgstr "認証情報を取得したあと、Ansible に提供する方法は 2 つあります。" - -#: ../../rst/scenario_guides/guide_gce.rst:71 -msgid "by specifying them directly as module parameters" -msgstr "モジュールパラメーターとして直接指定" - -#: ../../rst/scenario_guides/guide_gce.rst:72 -msgid "by setting environment variables" -msgstr "環境変数を設定" - -#: ../../rst/scenario_guides/guide_gce.rst:75 -msgid "Providing Credentials as Module Parameters" -msgstr "認証情報をモジュールパラメーターとして指定" - -#: ../../rst/scenario_guides/guide_gce.rst:77 -msgid "For the GCE modules you can specify the credentials as arguments:" -msgstr "GCE モジュールでは、認証情報を引数として指定できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:79 -msgid "``auth_kind``: type of authentication being used (choices: machineaccount, serviceaccount, application)" -msgstr "``auth_kind``: 使用される認証のタイプ (選択肢: machineaccount、serviceaccount、application)" - -#: ../../rst/scenario_guides/guide_gce.rst:80 -msgid "``service_account_email``: email associated with the project" -msgstr "``service_account_email``: プロジェクトに関連する電子メール" - -#: ../../rst/scenario_guides/guide_gce.rst:81 -msgid "``service_account_file``: path to the JSON credentials file" -msgstr "``service_account_file``: JSON 認証情報ファイルへのパス" - -#: ../../rst/scenario_guides/guide_gce.rst:82 -msgid "``project``: id of the project" -msgstr "``project``: プロジェクトの ID" - -#: ../../rst/scenario_guides/guide_gce.rst:83 -msgid "``scopes``: The specific scopes that you want the actions to use." -msgstr "``scopes``: アクションで使用する特定のスコープ。" - -#: ../../rst/scenario_guides/guide_gce.rst:85 -msgid "For example, to create a new IP address using the ``gcp_compute_address`` module, you can use the following configuration:" -msgstr "たとえば、``gcp_compute_address`` モジュールを使用して新規 IP アドレスを作成するには、以下の設定を使用できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:114 -msgid "Providing Credentials as Environment Variables" -msgstr "認証情報を環境変数として指定" - -#: ../../rst/scenario_guides/guide_gce.rst:116 -msgid "Set the following environment variables before running Ansible in order to configure your credentials:" -msgstr "認証情報を設定するために Ansible を実行する前に、以下の環境変数を設定します。" - -#: ../../rst/scenario_guides/guide_gce.rst:126 -msgid "GCE Dynamic Inventory" -msgstr "GCE 動的インベントリー" - -#: ../../rst/scenario_guides/guide_gce.rst:128 -msgid "The best way to interact with your hosts is to use the gcp_compute inventory plugin, which dynamically queries GCE and tells Ansible what nodes can be managed." -msgstr "ホストと対話する最適な方法は、gcp_compute インベントリープラグインを使用することです。このプラグインは、GCE に動的にクエリーを送信し、管理できるノードを Ansible に通知します。" - -#: ../../rst/scenario_guides/guide_gce.rst:130 -msgid "To be able to use this GCE dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "この GCE 動的インベントリープラグインを使用するには、最初に ``ansible.cfg`` ファイルに以下を指定して有効にする必要があります。" - -#: ../../rst/scenario_guides/guide_gce.rst:137 -msgid "Then, create a file that ends in ``.gcp.yml`` in your root directory." -msgstr "次に、root ディレクトリーに、名前の末尾が ``.gcp.yml`` で終わるファイルを作成します。" - -#: ../../rst/scenario_guides/guide_gce.rst:139 -msgid "The gcp_compute inventory script takes in the same authentication information as any module." -msgstr "gcp_compute スクリプトは、モジュールと同じ認証情報を取得します。" - -#: ../../rst/scenario_guides/guide_gce.rst:141 -msgid "Here's an example of a valid inventory file:" -msgstr "以下は、有効なインベントリーファイルの例です。" - -#: ../../rst/scenario_guides/guide_gce.rst:152 -msgid "Executing ``ansible-inventory --list -i .gcp.yml`` will create a list of GCP instances that are ready to be configured using Ansible." -msgstr "``ansible-inventory --list -i .gcp.yml`` を実行すると、Ansible を使用して設定する準備ができている GCP インスタンスの一覧が作成されます。" - -#: ../../rst/scenario_guides/guide_gce.rst:155 -msgid "Create an instance" -msgstr "インスタンスの作成" - -#: ../../rst/scenario_guides/guide_gce.rst:157 -msgid "The full range of GCP modules provide the ability to create a wide variety of GCP resources with the full support of the entire GCP API." -msgstr "GCP モジュールの全範囲により、GCP API 全体の完全なサポートにより、さまざまな GCP リソースを作成することができます。" - -#: ../../rst/scenario_guides/guide_gce.rst:160 -msgid "The following playbook creates a GCE Instance. This instance relies on other GCP resources like Disk. By creating other resources separately, we can give as much detail as necessary about how we want to configure the other resources, for example formatting of the Disk. By registering it to a variable, we can simply insert the variable into the instance task. The gcp_compute_instance module will figure out the rest." -msgstr "以下の Playbook は GCE インスタンスを作成します。このインスタンスは、Disk などの他の GCP リソースに依存します。他のリソースを個別に作成すると、ディスクのフォーマットなど、他のリソースの設定方法を必要なだけ提供できます。これを変数に登録すると、その変数をインスタンスタスクに挿入することができます。gcp_compute_instance モジュールは、残りを確認できます。" - -#: ../../rst/scenario_guides/guide_gce.rst:242 -msgid "Note that use of the \"add_host\" module above creates a temporary, in-memory group. This means that a play in the same playbook can then manage machines in the 'new_instances' group, if so desired. Any sort of arbitrary configuration is possible at this point." -msgstr "上記の「add_host」モジュールを使用すると、一時的なインメモリーグループが作成されます。これは、同じ Playbook 内のプレイが「new_instances」グループ内のマシンを管理できることを意味します。この時点で任意の設定が可能です。" - -#: ../../rst/scenario_guides/guide_gce.rst:245 -msgid "For more information about Google Cloud, please visit the `Google Cloud website `_." -msgstr "Google Cloud の詳細は、`Google Cloud Web サイト `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_gce.rst:248 -msgid "Migration Guides" -msgstr "移行ガイド" - -#: ../../rst/scenario_guides/guide_gce.rst:251 -msgid "gce.py -> gcp_compute_instance.py" -msgstr "gce.py -> gcp_compute_instance.py" - -#: ../../rst/scenario_guides/guide_gce.rst:252 -msgid "As of Ansible 2.8, we're encouraging everyone to move from the ``gce`` module to the ``gcp_compute_instance`` module. The ``gcp_compute_instance`` module has better support for all of GCP's features, fewer dependencies, more flexibility, and better supports GCP's authentication systems." -msgstr "Ansible 2.8 では、すべてのユーザーが ``gce`` モジュールから ``gcp_compute_instance`` モジュールに移行することを推奨しています。``gcp_compute_instance`` モジュールは、すべての GCP の機能のサポートと、依存関係が少なく、柔軟性が高い、GCP の認証システムにもより良いサポートを提供します。" - -#: ../../rst/scenario_guides/guide_gce.rst:257 -msgid "The ``gcp_compute_instance`` module supports all of the features of the ``gce`` module (and more!). Below is a mapping of ``gce`` fields over to ``gcp_compute_instance`` fields." -msgstr "``gcp_compute_instance`` モジュールは、``gce`` モジュール (およびそれ以上) のすべての機能をサポートします。これは、``gce`` フィールドから ``gcp_compute_instance`` フィールドへのマッピングです。" - -#: ../../rst/scenario_guides/guide_gce.rst:262 -msgid "gce.py" -msgstr "gce.py" - -#: ../../rst/scenario_guides/guide_gce.rst:262 -msgid "gcp_compute_instance.py" -msgstr "gcp_compute_instance.py" - -#: ../../rst/scenario_guides/guide_gce.rst:262 -msgid "Notes" -msgstr "備考" - -#: ../../rst/scenario_guides/guide_gce.rst:264 -#: ../../rst/scenario_guides/guide_meraki.rst:91 -msgid "state" -msgstr "state" - -#: ../../rst/scenario_guides/guide_gce.rst:264 -msgid "state/status" -msgstr "state/status" - -#: ../../rst/scenario_guides/guide_gce.rst:264 -msgid "State on gce has multiple values: \"present\", \"absent\", \"stopped\", \"started\", \"terminated\". State on gcp_compute_instance is used to describe if the instance exists (present) or does not (absent). Status is used to describe if the instance is \"started\", \"stopped\" or \"terminated\"." -msgstr "gce の状態には、複数の値 (「present」、「absent」、「stopped」、「started」、「terminated」) があります。gcp_compute_instance は、インスタンスが存在するか (present) か、そうでないか (absent) を示します。ステータスは、インスタンスが「started」、「stopped」、または「terminated」であるかを説明するために使用されます。" - -#: ../../rst/scenario_guides/guide_gce.rst:265 -msgid "image" -msgstr "image" - -#: ../../rst/scenario_guides/guide_gce.rst:265 -#: ../../rst/scenario_guides/guide_gce.rst:266 -#: ../../rst/scenario_guides/guide_gce.rst:267 -msgid "disks[].initialize_params.source_image" -msgstr "disks[].initialize_params.source_image" - -#: ../../rst/scenario_guides/guide_gce.rst:265 -msgid "You'll need to create a single disk using the disks[] parameter and set it to be the boot disk (disks[].boot = true)" -msgstr "disks[] パラメーターを使用してディスクを 1 つ作成し、それをブートディスクに設定する必要があります (disks[].boot = true)。" - -#: ../../rst/scenario_guides/guide_gce.rst:266 -msgid "image_family" -msgstr "image_family" - -#: ../../rst/scenario_guides/guide_gce.rst:266 -msgid "See above." -msgstr "上記を参照してください。" - -#: ../../rst/scenario_guides/guide_gce.rst:267 -msgid "external_projects" -msgstr "external_projects" - -#: ../../rst/scenario_guides/guide_gce.rst:267 -msgid "The name of the source_image will include the name of the project." -msgstr "source_image の名前には、プロジェクトの名前が含まれます。" - -#: ../../rst/scenario_guides/guide_gce.rst:268 -msgid "instance_names" -msgstr "instance_names" - -#: ../../rst/scenario_guides/guide_gce.rst:268 -msgid "Use a loop or multiple tasks." -msgstr "ループまたは複数のタスクを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:268 -msgid "Using loops is a more Ansible-centric way of creating multiple instances and gives you the most flexibility." -msgstr "ループの使用は、複数のインスタンスを作成するよりも Ansible に適した方法で、柔軟性が最も高くなります。" - -#: ../../rst/scenario_guides/guide_gce.rst:269 -msgid "service_account_email" -msgstr "service_account_email" - -#: ../../rst/scenario_guides/guide_gce.rst:269 -msgid "service_accounts[].email" -msgstr "service_accounts[].email" - -#: ../../rst/scenario_guides/guide_gce.rst:269 -msgid "This is the service_account email address that you want the instance to be associated with. It is not the service_account email address that is used for the credentials necessary to create the instance." -msgstr "これは、インスタンスが関連付けられる service_account のメールアドレスです。インスタンスの作成に必要な認証情報に使用される service_account のメールアドレスではありません。" - -#: ../../rst/scenario_guides/guide_gce.rst:270 -msgid "service_account_permissions" -msgstr "service_account_permissions" - -#: ../../rst/scenario_guides/guide_gce.rst:270 -msgid "service_accounts[].scopes" -msgstr "service_accounts[].scopes" - -#: ../../rst/scenario_guides/guide_gce.rst:270 -msgid "These are the permissions you want to grant to the instance." -msgstr "これらは、インスタンスに付与するパーミッションです。" - -#: ../../rst/scenario_guides/guide_gce.rst:271 -msgid "pem_file" -msgstr "pem_file" - -#: ../../rst/scenario_guides/guide_gce.rst:271 -msgid "Not supported." -msgstr "サポート対象外。" - -#: ../../rst/scenario_guides/guide_gce.rst:271 -msgid "We recommend using JSON service account credentials instead of PEM files." -msgstr "PEM ファイルの代わりに JSON サービスアカウントの認証情報を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_gce.rst:272 -msgid "credentials_file" -msgstr "credentials_file" - -#: ../../rst/scenario_guides/guide_gce.rst:272 -msgid "service_account_file" -msgstr "service_account_file" - -#: ../../rst/scenario_guides/guide_gce.rst:273 -msgid "project_id" -msgstr "project_id" - -#: ../../rst/scenario_guides/guide_gce.rst:273 -msgid "project" -msgstr "project" - -#: ../../rst/scenario_guides/guide_gce.rst:274 -msgid "name" -msgstr "名前" - -#: ../../rst/scenario_guides/guide_gce.rst:274 -msgid "This field does not accept an array of names. Use a loop to create multiple instances." -msgstr "このフィールドは名前の配列を受け入れません。複数インスタンスを作成するにはループを使用します。" - -#: ../../rst/scenario_guides/guide_gce.rst:275 -msgid "num_instances" -msgstr "num_instances" - -#: ../../rst/scenario_guides/guide_gce.rst:275 -msgid "Use a loop" -msgstr "ループの使用" - -#: ../../rst/scenario_guides/guide_gce.rst:275 -msgid "For maximum flexibility, we're encouraging users to use Ansible features to create multiple instances, rather than letting the module do it for you." -msgstr "最大限の柔軟性を得るには、モジュールに任せず、Ansible 機能を使用して複数のインスタンスを作成することを推奨しています。" - -#: ../../rst/scenario_guides/guide_gce.rst:276 -msgid "network" -msgstr "network" - -#: ../../rst/scenario_guides/guide_gce.rst:276 -msgid "network_interfaces[].network" -msgstr "network_interfaces[].network" - -#: ../../rst/scenario_guides/guide_gce.rst:277 -msgid "subnetwork" -msgstr "subnetwork" - -#: ../../rst/scenario_guides/guide_gce.rst:277 -msgid "network_interfaces[].subnetwork" -msgstr "network_interfaces[].subnetwork" - -#: ../../rst/scenario_guides/guide_gce.rst:278 -msgid "persistent_boot_disk" -msgstr "persistent_boot_disk" - -#: ../../rst/scenario_guides/guide_gce.rst:278 -msgid "disks[].type = 'PERSISTENT'" -msgstr "disks[].type = 'PERSISTENT'" - -#: ../../rst/scenario_guides/guide_gce.rst:279 -msgid "disks" -msgstr "disks" - -#: ../../rst/scenario_guides/guide_gce.rst:279 -msgid "disks[]" -msgstr "disks[]" - -#: ../../rst/scenario_guides/guide_gce.rst:280 -msgid "ip_forward" -msgstr "ip_forward" - -#: ../../rst/scenario_guides/guide_gce.rst:280 -msgid "can_ip_forward" -msgstr "can_ip_forward" - -#: ../../rst/scenario_guides/guide_gce.rst:281 -msgid "external_ip" -msgstr "external_ip" - -#: ../../rst/scenario_guides/guide_gce.rst:281 -msgid "network_interfaces[].access_configs.nat_ip" -msgstr "network_interfaces[].access_configs.nat_ip" - -#: ../../rst/scenario_guides/guide_gce.rst:281 -msgid "This field takes multiple types of values. You can create an IP address with ``gcp_compute_address`` and place the name/output of the address here. You can also place the string value of the IP address's GCP name or the actual IP address." -msgstr "このフィールドは、複数のタイプの値を取ります。``gcp_compute_address`` で IP アドレスを作成し、そのアドレスの名前/出力をここに入力します。IP アドレスの GCP 名または実際の IP アドレスの文字列値を入力することもできます。" - -#: ../../rst/scenario_guides/guide_gce.rst:282 -msgid "disks_auto_delete" -msgstr "disks_auto_delete" - -#: ../../rst/scenario_guides/guide_gce.rst:282 -msgid "disks[].auto_delete" -msgstr "disks[].auto_delete" - -#: ../../rst/scenario_guides/guide_gce.rst:283 -msgid "preemptible" -msgstr "preemptible" - -#: ../../rst/scenario_guides/guide_gce.rst:283 -msgid "scheduling.preemptible" -msgstr "scheduling.preemptible" - -#: ../../rst/scenario_guides/guide_gce.rst:284 -msgid "disk_size" -msgstr "disk_size" - -#: ../../rst/scenario_guides/guide_gce.rst:284 -msgid "disks[].initialize_params.disk_size_gb" -msgstr "disks[].initialize_params.disk_size_gb" - -#: ../../rst/scenario_guides/guide_gce.rst:287 -msgid "An example playbook is below:" -msgstr "Playbook の例を以下に示します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:5 -msgid "Infoblox Guide" -msgstr "Infoblox ガイド" - -#: ../../rst/scenario_guides/guide_infoblox.rst:7 -msgid "Topics" -msgstr "トピック" - -#: ../../rst/scenario_guides/guide_infoblox.rst:9 -msgid "This guide describes how to use Ansible with the Infoblox Network Identity Operating System (NIOS). With Ansible integration, you can use Ansible playbooks to automate Infoblox Core Network Services for IP address management (IPAM), DNS, and inventory tracking." -msgstr "本ガイドでは、Infoblox NIOS (Network Identity Operating System) で Ansible を使用する方法を説明します。Ansible 統合では、Ansible Playbook を使用して、IP アドレス管理 (IPAM)、DNS、およびインベントリー追跡について Infoblox Core Network Services を自動化できます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:11 -msgid "You can review simple example tasks in the documentation for any of the :ref:`NIOS modules ` or look at the `Use cases with modules`_ section for more elaborate examples. See the `Infoblox `_ website for more information on the Infoblox product." -msgstr "簡単なタスクの例については、:ref:`NIOS モジュール ` のいずれかについてのドキュメントを参照するか、`モジュールのユースケース`_ セクションを参照してタスクの例を確認してください。Infoblox 製品の詳細は、`Infoblox `_ の Web サイトを参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:13 -msgid "You can retrieve most of the example playbooks used in this guide from the `network-automation/infoblox_ansible `_ GitHub repository." -msgstr "本ガイドで使用されている Playbook サンプルの大半は、`network-automation/infoblox_ansible `_ GitHub リポジトリーから取得できます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:17 -msgid "Before using Ansible ``nios`` modules with Infoblox, you must install the ``infoblox-client`` on your Ansible control node:" -msgstr "Infoblox で Ansible ``nios`` モジュールを使用する前に、Ansible コントロールノードに ``infoblox-client`` をインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:24 -msgid "You need an NIOS account with the WAPI feature enabled to use Ansible with Infoblox." -msgstr "Infoblox で Ansible を使用するには、WAPI 機能が有効になっている NIOS アカウントが必要です。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:29 -#: ../../rst/scenario_guides/scenario_template.rst:22 -msgid "Credentials and authenticating" -msgstr "認証情報および認証" - -#: ../../rst/scenario_guides/guide_infoblox.rst:31 -msgid "To use Infoblox ``nios`` modules in playbooks, you need to configure the credentials to access your Infoblox system. The examples in this guide use credentials stored in ``/group_vars/nios.yml``. Replace these values with your Infoblox credentials:" -msgstr "Playbook で Infoblox ``nios`` モジュールを使用するには、Infoblox システムにアクセスするための認証情報を設定する必要があります。本ガイドの例では、``/group_vars/nios.yml`` に保存されている認証情報を使用します。この値をお使いの Infoblox 認証情報に置き換えます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:42 -msgid "NIOS lookup plugins" -msgstr "NIOS Lookup プラグイン" - -#: ../../rst/scenario_guides/guide_infoblox.rst:44 -msgid "Ansible includes the following lookup plugins for NIOS:" -msgstr "Ansible には、NIOS 用に以下の lookup プラグインが含まれます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:46 -msgid ":ref:`nios ` Uses the Infoblox WAPI API to fetch NIOS specified objects, for example network views, DNS views, and host records." -msgstr ":ref:`nios ` Infoblox WAPI API を使用して NIOS が指定されたオブジェクト (ネットワークビュー、DNS ビュー、ホストレコードなど) を取得します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:47 -msgid ":ref:`nios_next_ip ` Provides the next available IP address from a network. You'll see an example of this in `Creating a host record`_." -msgstr ":ref:`nios_next_ip ` は、ネットワークから次に利用可能な IP アドレスを提供します。「`ホストレコードの作成`_」に、この例を示します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:48 -msgid ":ref:`nios_next_network ` - Returns the next available network range for a network-container." -msgstr ":ref:`nios_next_network ` - ネットワークコンテナーの次に利用可能なネットワーク範囲を返します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:50 -msgid "You must run the NIOS lookup plugins locally by specifying ``connection: local``. See :ref:`lookup plugins ` for more detail." -msgstr "``connection: local`` を指定して NIOS ルックアッププラグインをローカルで実行する必要があります。詳細は「:ref:`lookup プラグイン `」を参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:54 -msgid "Retrieving all network views" -msgstr "すべてのネットワークビューの取得" - -#: ../../rst/scenario_guides/guide_infoblox.rst:56 -msgid "To retrieve all network views and save them in a variable, use the :ref:`set_fact ` module with the :ref:`nios ` lookup plugin:" -msgstr "すべてのネットワークビューを取得して変数に保存するには、:ref:`nios ` ルックアッププラグインで :ref:`set_fact ` モジュールを使用します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:74 -msgid "Retrieving a host record" -msgstr "ホストレコードの取得" - -#: ../../rst/scenario_guides/guide_infoblox.rst:76 -msgid "To retrieve a set of host records, use the ``set_fact`` module with the ``nios`` lookup plugin and include a filter for the specific hosts you want to retrieve:" -msgstr "ホストレコードのセットを取得するには、``nios`` ルックアッププラグインで ``set_fact`` モジュールを使用し、取得する特定ホストのフィルターを追加します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:105 -msgid "If you run this ``get_host_record.yml`` playbook, you should see results similar to the following:" -msgstr "この ``get_host_record.yml`` Playbook を実行すると、以下のような結果が表示されるはずです。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:156 -msgid "The output above shows the host record for ``leaf01.ansible.com`` and ``leaf02.ansible.com`` that were retrieved by the ``nios`` lookup plugin. This playbook saves the information in variables which you can use in other playbooks. This allows you to use Infoblox as a single source of truth to gather and use information that changes dynamically. See :ref:`playbooks_variables` for more information on using Ansible variables. See the :ref:`nios ` examples for more data options that you can retrieve." -msgstr "上記の出力には、``nios`` ルックアッププラグインによって取得された ``leaf01.ansible.com`` および ``leaf02.ansible.com`` のホストレコードが表示されます。この Playbook は、他の Playbook で使用できる変数に情報を保存します。これにより、Infoblox を信頼できる単一のソースとして使用し、動的に変更する情報を収集し、使用できます。Ansible 変数の使用の詳細は、「:ref:`playbooks_variables`」を参照してください。取得できるその他のデータオプションは、「:ref:`nios `」の例を参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:158 -msgid "You can access these playbooks at `Infoblox lookup playbooks `_." -msgstr "この Playbook には、「`Infoblox lookup playbooks `_」からアクセスできます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:161 -msgid "Use cases with modules" -msgstr "モジュールを使用したユースケース" - -#: ../../rst/scenario_guides/guide_infoblox.rst:163 -msgid "You can use the ``nios`` modules in tasks to simplify common Infoblox workflows. Be sure to set up your :ref:`NIOS credentials` before following these examples." -msgstr "``nios`` モジュールをタスクで使用すると、共通の Infoblox ワークフローを単純化できます。これらの例を行う前に、「:ref:`NIOS 認証情報`」を設定するようにしてください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:166 -msgid "Configuring an IPv4 network" -msgstr "IPv4 ネットワークの設定" - -#: ../../rst/scenario_guides/guide_infoblox.rst:168 -msgid "To configure an IPv4 network, use the :ref:`nios_network ` module:" -msgstr "IPv4 ネットワークを設定するには、:ref:`nios_network ` モジュールを使用します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:186 -msgid "Notice the last parameter, ``provider``, uses the variable ``nios_provider`` defined in the ``group_vars/`` directory." -msgstr "最後のパラメーター ``provider`` は、``nios_provider`` ディレクトリーで定義されている ``group_vars/`` 変数を使用することに注意してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:189 -msgid "Creating a host record" -msgstr "ホストレコードの作成" - -#: ../../rst/scenario_guides/guide_infoblox.rst:191 -msgid "To create a host record named `leaf03.ansible.com` on the newly-created IPv4 network:" -msgstr "新たに作成した IPv4 ネットワーク上で `leaf03.ansible.com` という名前のホストレコードを作成するには、次を実行します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:208 -msgid "Notice the IPv4 address in this example uses the :ref:`nios_next_ip ` lookup plugin to find the next available IPv4 address on the network." -msgstr "この例の IPv4 アドレスは、:ref:`nios_next_ip ` lookup プラグインを使用して、ネットワーク上で次に利用可能な IPv4 アドレスを検索します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:211 -msgid "Creating a forward DNS zone" -msgstr "正引き DNS ゾーンの作成" - -#: ../../rst/scenario_guides/guide_infoblox.rst:213 -msgid "To configure a forward DNS zone use, the ``nios_zone`` module:" -msgstr "正引き DNS ゾーンを設定するには、``nios_zone`` モジュールを使用します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:229 -msgid "Creating a reverse DNS zone" -msgstr "逆引き DNS ゾーンの作成" - -#: ../../rst/scenario_guides/guide_infoblox.rst:231 -msgid "To configure a reverse DNS zone:" -msgstr "逆引き DNS ゾーンを設定するには、以下を行います。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:247 -msgid "Dynamic inventory script" -msgstr "動的インベントリースクリプト" - -#: ../../rst/scenario_guides/guide_infoblox.rst:249 -msgid "You can use the Infoblox dynamic inventory script to import your network node inventory with Infoblox NIOS. To gather the inventory from Infoblox, you need two files:" -msgstr "Infoblox 動的インベントリースクリプトを使用して、Infoblox NIOS でネットワークノードのインベントリーをインポートできます。Infoblox からインベントリーを収集するには、以下の 2 つのファイルが必要です。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:251 -msgid "`infoblox.yaml `_ - A file that specifies the NIOS provider arguments and optional filters." -msgstr "`infoblox.yaml `_ - NIOS プロバイダー引数および任意のフィルターを指定するファイル。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:253 -msgid "`infoblox.py `_ - The python script that retrieves the NIOS inventory." -msgstr "`infoblox.py `_ - NIOS インベントリーを取得する python スクリプト。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:257 -msgid "Please note that the inventory script only works when Ansible 2.9, 2.10 or 3 have been installed. The inventory script will eventually be removed from `community.general `_, and will not work if `community.general` is only installed with `ansible-galaxy collection install`. Please use the inventory plugin from `infoblox.nios_modules `_ instead." -msgstr "インベントリースクリプトは、Ansible 2.9、2.10、または 3 がインストールされた場合にのみ機能することに注意してください。インベントリースクリプトは最終的に `community.general `_ から削除され、`community.general` が `ansible-galaxy collection install` と共にインストールされている場合に限り動作しません。代わりに `infoblox.nios_modules `_ からインベントリープラグインを使用してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:259 -msgid "To use the Infoblox dynamic inventory script:" -msgstr "Infoblox 動的インベントリースクリプトを使用するには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:261 -msgid "Download the ``infoblox.yaml`` file and save it in the ``/etc/ansible`` directory." -msgstr "``infoblox.yaml`` ファイルをダウンロードして、``/etc/ansible`` ディレクトリーに保存します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:263 -msgid "Modify the ``infoblox.yaml`` file with your NIOS credentials." -msgstr "NIOS 認証情報を使用して ``infoblox.yaml`` ファイルを変更します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:265 -msgid "Download the ``infoblox.py`` file and save it in the ``/etc/ansible/hosts`` directory." -msgstr "``infoblox.py`` ファイルをダウンロードして、``/etc/ansible/hosts`` ディレクトリーに保存します。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:267 -msgid "Change the permissions on the ``infoblox.py`` file to make the file an executable:" -msgstr "``infoblox.py`` ファイルのパーミッションを変更して、ファイルを実行可能にします。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:273 -msgid "You can optionally use ``./infoblox.py --list`` to test the script. After a few minutes, you should see your Infoblox inventory in JSON format. You can explicitly use the Infoblox dynamic inventory script as follows:" -msgstr "必要に応じて ``./infoblox.py --list`` を使用してスクリプトをテストすることができます。数分後、JSON 形式で Infoblox インベントリーが表示されるはずです。以下のように Infoblox 動的インベントリースクリプトを明示的に使用できます。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:279 -msgid "You can also implicitly use the Infoblox dynamic inventory script by including it in your inventory directory (``etc/ansible/hosts`` by default). See :ref:`dynamic_inventory` for more details." -msgstr "また、インベントリーディレクトリー (``etc/ansible/hosts`` がデフォルト) に追加して Infoblox 動的インベントリースクリプトを暗黙的で使用することもできます。詳細は「:ref:`dynamic_inventory`」を参照してください。" - -#: ../../rst/scenario_guides/guide_infoblox.rst:283 -msgid "`Infoblox website `_" -msgstr "`Infoblox website `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:284 -msgid "The Infoblox website" -msgstr "Infoblox の Web サイト" - -#: ../../rst/scenario_guides/guide_infoblox.rst:285 -msgid "`Infoblox and Ansible Deployment Guide `_" -msgstr "`Infoblox and Ansible Deployment Guide `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:286 -msgid "The deployment guide for Ansible integration provided by Infoblox." -msgstr "Infoblox が提供する Ansible 統合のデプロイメントガイド" - -#: ../../rst/scenario_guides/guide_infoblox.rst:287 -msgid "`Infoblox Integration in Ansible 2.5 `_" -msgstr "`Infoblox Integration in Ansible 2.5 `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:288 -msgid "Ansible blog post about Infoblox." -msgstr "Infoblox に関する Ansible ブログ投稿" - -#: ../../rst/scenario_guides/guide_infoblox.rst:289 -msgid ":ref:`Ansible NIOS modules `" -msgstr ":ref:`Ansible NIOS modules `" - -#: ../../rst/scenario_guides/guide_infoblox.rst:290 -msgid "The list of supported NIOS modules, with examples." -msgstr "対応している NIOS モジュールの一覧 (サンプルあり)" - -#: ../../rst/scenario_guides/guide_infoblox.rst:291 -msgid "`Infoblox Ansible Examples `_" -msgstr "`Infoblox Ansible Examples `_" - -#: ../../rst/scenario_guides/guide_infoblox.rst:292 -msgid "Infoblox example playbooks." -msgstr "Infoblox の Playbook サンプル" - -#: ../../rst/scenario_guides/guide_meraki.rst:5 -msgid "Cisco Meraki Guide" -msgstr "Cisco Meraki ガイド" - -#: ../../rst/scenario_guides/guide_meraki.rst:14 -msgid "What is Cisco Meraki?" -msgstr "Cisco Meraki とは" - -#: ../../rst/scenario_guides/guide_meraki.rst:16 -msgid "Cisco Meraki is an easy-to-use, cloud-based, network infrastructure platform for enterprise environments. While most network hardware uses command-line interfaces (CLIs) for configuration, Meraki uses an easy-to-use Dashboard hosted in the Meraki cloud. No on-premises management hardware or software is required - only the network infrastructure to run your business." -msgstr "Cisco Meraki は、エンタープライズ環境向けの使いやすいクラウドベースのネットワークインフラストラクチャープラットフォームです。ほとんどのネットワークハードウェアは、設定にコマンドラインインターフェース (CLI) を使用しますが、Meraki は Meraki クラウドでホストされる使いやすい Dashboard を使用します。オンプレミスの管理用ハードウェアやソフトウェアは必要なく、ビジネスに必要なネットワークインフラストラクチャーのみが用意されています。" - -#: ../../rst/scenario_guides/guide_meraki.rst:19 -msgid "MS Switches" -msgstr "MS スイッチ" - -#: ../../rst/scenario_guides/guide_meraki.rst:21 -msgid "Meraki MS switches come in multiple flavors and form factors. Meraki switches support 10/100/1000/10000 ports, as well as Cisco's mGig technology for 2.5/5/10Gbps copper connectivity. 8, 24, and 48 port flavors are available with PoE (802.3af/802.3at/UPoE) available on many models." -msgstr "Meraki MS スイッチには複数のフレーバーおよび形式要素があります。Meraki スイッチは、10/100/1000/10000 ポートと、2.5/5/10 Gbps のカッパー接続用である Cisco 社の mGig テクノロジーに対応しています。8、24、および 48 のポートフレーバーは、多くのモデルで利用可能な PoE (802.3af/802.3at/UPoE) で利用できます。" - -#: ../../rst/scenario_guides/guide_meraki.rst:24 -msgid "MX Firewalls" -msgstr "MX ファイアウォール" - -#: ../../rst/scenario_guides/guide_meraki.rst:26 -msgid "Meraki's MX firewalls support full layer 3-7 deep packet inspection. MX firewalls are compatible with a variety of VPN technologies including IPSec, SSL VPN, and Meraki's easy-to-use AutoVPN." -msgstr "Meraki の MX ファイアウォールは、レイヤー 3 から 7 のディープパケット検査をサポートします。MX ファイアウォールは、IPsec、SSL VPN、および Meraki の使いやすい AutoVPN など、さまざまな VPN テクノロジーと互換性があります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:29 -msgid "MR Wireless Access Points" -msgstr "MR ワイヤレスアクセスポイント" - -#: ../../rst/scenario_guides/guide_meraki.rst:31 -msgid "MR access points are enterprise-class, high-performance access points for the enterprise. MR access points have MIMO technology and integrated beamforming built-in for high performance applications. BLE allows for advanced location applications to be developed with no on-premises analytics platforms." -msgstr "MR アクセスポイントは、エンタープライズクラスの高パフォーマンスのアクセスポイントです。MR アクセスポイントには、高性能アプリケーション向けに、MIMO テクノロジーと統合ビームフォーマーが組み込まれています。BLE は、オンプレミスの解析プラットフォームを使用せずに高度なロケーションアプリケーションを開発できるようにします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:34 -msgid "Using the Meraki modules" -msgstr "Meraki モジュールの使用" - -#: ../../rst/scenario_guides/guide_meraki.rst:36 -msgid "Meraki modules provide a user-friendly interface to manage your Meraki environment using Ansible. For example, details about SNMP settings for a particular organization can be discovered using the module `meraki_snmp `." -msgstr "Meraki モジュールは、Ansible を使用して Meraki 環境を管理するユーザーフレンドリーなインターフェースを提供します。たとえば、特定の組織の SNMP 設定の詳細は、`meraki_snmp ` モジュールを使用して検出できます。" - -#: ../../rst/scenario_guides/guide_meraki.rst:47 -msgid "Information about a particular object can be queried. For example, the `meraki_admin ` module supports" -msgstr "特定のオブジェクトに関する情報をクエリーできます。たとえば、`meraki_admin ` モジュールがサポートするものです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:60 -msgid "Common Parameters" -msgstr "一般的なパラメーター" - -#: ../../rst/scenario_guides/guide_meraki.rst:62 -msgid "All Ansible Meraki modules support the following parameters which affect communication with the Meraki Dashboard API. Most of these should only be used by Meraki developers and not the general public." -msgstr "すべての Ansible Meraki モジュールは、Meraki Dashboard API との通信に影響する以下のパラメーターに対応します。これらのほとんどは、一般的には使用するものではなく、Meraki 開発者が使用するためのものです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:65 -msgid "Hostname or IP of Meraki Dashboard." -msgstr "Meraki Dashboard のホスト名または IP。" - -#: ../../rst/scenario_guides/guide_meraki.rst:68 -msgid "use_https" -msgstr "use_https" - -#: ../../rst/scenario_guides/guide_meraki.rst:68 -msgid "Specifies whether communication should be over HTTPS. (Defaults to ``yes``)" -msgstr "通信が HTTPS を使用するかどうかを指定します (デフォルトは ``yes``)。" - -#: ../../rst/scenario_guides/guide_meraki.rst:71 -msgid "Whether to use a proxy for any communication." -msgstr "通信にプロキシーを使用するかどうか。" - -#: ../../rst/scenario_guides/guide_meraki.rst:74 -msgid "Determine whether certificates should be validated or trusted. (Defaults to ``yes``)" -msgstr "証明書を検証すべきか、それとも信用すべきを指定します (デフォルトは ``yes``)。" - -#: ../../rst/scenario_guides/guide_meraki.rst:76 -msgid "These are the common parameters which are used for most every module." -msgstr "以下は、大抵のモジュールに使用される一般的なパラメーターです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:79 -msgid "org_name" -msgstr "org_name" - -#: ../../rst/scenario_guides/guide_meraki.rst:79 -msgid "Name of organization to perform actions in." -msgstr "アクションを実行する組織の名前。" - -#: ../../rst/scenario_guides/guide_meraki.rst:82 -msgid "org_id" -msgstr "org_id" - -#: ../../rst/scenario_guides/guide_meraki.rst:82 -msgid "ID of organization to perform actions in." -msgstr "アクションを実行する組織の ID。" - -#: ../../rst/scenario_guides/guide_meraki.rst:85 -msgid "net_name" -msgstr "net_name" - -#: ../../rst/scenario_guides/guide_meraki.rst:85 -msgid "Name of network to perform actions in." -msgstr "アクションを実行するネットワークの名前。" - -#: ../../rst/scenario_guides/guide_meraki.rst:88 -msgid "net_id" -msgstr "net_id" - -#: ../../rst/scenario_guides/guide_meraki.rst:88 -msgid "ID of network to perform actions in." -msgstr "アクションを実行するネットワークの ID。" - -#: ../../rst/scenario_guides/guide_meraki.rst:91 -msgid "General specification of what action to take. ``query`` does lookups. ``present`` creates or edits. ``absent`` deletes." -msgstr "実行するアクションに関する一般的な仕様。``query`` は検索を行い、``present`` は作成または編集を行います。``absent`` は削除します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:93 -msgid "Use the ``org_id`` and ``net_id`` parameters when possible. ``org_name`` and ``net_name`` require additional behind-the-scenes API calls to learn the ID values. ``org_id`` and ``net_id`` will perform faster." -msgstr "可能な場合は、``org_id`` パラメーターおよび ``net_id`` パラメーターを使用します。``org_name`` および ``net_name``は、ID 値を確認するために、その裏で追加の API 呼び出しが必要です。``org_id`` および ``net_id`` の動作はより速くなります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:96 -msgid "Meraki Authentication" -msgstr "Meraki 認証" - -#: ../../rst/scenario_guides/guide_meraki.rst:98 -msgid "All API access with the Meraki Dashboard requires an API key. An API key can be generated from the organization's settings page. Each play in a playbook requires the ``api_key`` parameter to be specified." -msgstr "Meraki Dashboard を使用した API アクセスはすべて API キーを必要とします。API キーは組織の設定ページから生成できます。Playbook の各プレイには ``api_key`` パラメーターを指定する必要があります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:102 -msgid "Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first." -msgstr "API キーが正しくない場合は、Meraki の API が 404 エラーを返します。キーが正しくないことを示す特定のエラーは提供されません。404 エラーを受け取った場合は、最初に API キーを確認してください。" - -#: ../../rst/scenario_guides/guide_meraki.rst:105 -msgid "Returned Data Structures" -msgstr "返されたデータ構造" - -#: ../../rst/scenario_guides/guide_meraki.rst:107 -msgid "Meraki and its related Ansible modules return most information in the form of a list. For example, this is returned information by ``meraki_admin`` querying administrators. It returns a list even though there's only one." -msgstr "Meraki とその関連 Ansible モジュールは、リスト形式でほとんどの情報を返します。たとえば、これは、管理者のクエリーを行う ``meraki_admin`` により情報を返します。管理者が 1 人しかいなくても一覧を返します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:123 -msgid "Handling Returned Data" -msgstr "返されたデータの処理" - -#: ../../rst/scenario_guides/guide_meraki.rst:125 -msgid "Since Meraki's response data uses lists instead of properly keyed dictionaries for responses, certain strategies should be used when querying data for particular information. For many situations, use the ``selectattr()`` Jinja2 function." -msgstr "Meraki の応答データは応答に適切に鍵付けされたディクショナリーではなくリストを使用するため、特定情報に対してデータのクエリーを行う際に特定のストラテジーを使用する必要があります。多くの状況では、Jinja2 機能 ``selectattr()`` を使用します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:128 -msgid "Merging Existing and New Data" -msgstr "既存データと新規データのマージ" - -#: ../../rst/scenario_guides/guide_meraki.rst:130 -msgid "Ansible's Meraki modules do not allow for manipulating data. For example, you may need to insert a rule in the middle of a firewall ruleset. Ansible and the Meraki modules lack a way to directly merge to manipulate data. However, a playlist can use a few tasks to split the list where you need to insert a rule and then merge them together again with the new rule added. The steps involved are as follows:" -msgstr "Ansible の Meraki モジュールは、データの操作を許可しません。たとえば、ファイアウォールルールセットの途中でルールを挿入しなければならない場合があります。Ansible モジュールおよび Meraki モジュールには、データを操作するために直接マージする方法がありません。ただし、プレイリストでは、いくつかのタスクを使用して、ルールを挿入する必要のあるリストを分割し、新しいルールを追加して再びマージすることができます。その手順は以下の通りです。" - -#: ../../rst/scenario_guides/guide_meraki.rst:136 -msgid "Create blank \"front\" and \"back\" lists." -msgstr "空の「前」リストおよび「後」リストを作成します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:149 -msgid "Get existing firewall rules from Meraki and create a new variable." -msgstr "Meraki から既存のファイアウォールルールを取得して、新しい変数を作成します。" - -#: ../../rst/scenario_guides/guide_meraki.rst:162 -msgid "Write the new rule. The new rule needs to be in a list so it can be merged with other lists in an upcoming step. The blank `-` puts the rule in a list so it can be merged." -msgstr "新しいルールを記述します。新しいルールは、今後のステップで他のリストにマージできるように、リストに入れる必要があります。空白の `-` は、ルールをリストに入れて、マージできるようにします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:169 -msgid "Split the rules into two lists. This assumes the existing ruleset is 2 rules long." -msgstr "ルールを 2 つのリストに分割します。これは、既存のルールセットが 2 つのルールの長さであることを前提としています。" - -#: ../../rst/scenario_guides/guide_meraki.rst:174 -msgid "Merge rules with the new rule in the middle." -msgstr "ルールを、中間の新しいルールとマージします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:186 -msgid "Upload new ruleset to Meraki." -msgstr "新しいルールセットを Meraki にアップロードします。" - -#: ../../rst/scenario_guides/guide_meraki.rst:189 -msgid "Error Handling" -msgstr "エラー処理" - -#: ../../rst/scenario_guides/guide_meraki.rst:191 -msgid "Ansible's Meraki modules will often fail if improper or incompatible parameters are specified. However, there will likely be scenarios where the module accepts the information but the Meraki API rejects the data. If this happens, the error will be returned in the ``body`` field for HTTP status of 400 return code." -msgstr "Ansible の Meraki モジュールは、不適切なパラメーターや互換性のないパラメーターが指定されている場合に失敗することがよくあります。ただし、モジュールが情報を受け入れても Meraki API がデータを拒否する場合があります。これに生じると、``body`` フィールドにエラーが返され、HTTP ステータスは 400 の戻りコードになります。" - -#: ../../rst/scenario_guides/guide_meraki.rst:193 -msgid "Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first. 404 errors can also occur if improper object IDs (ex. ``org_id``) are specified." -msgstr "API キーが正しくないと、Meraki の API は 404 エラーを返します。このキーが正しくないことを示す特別なエラーはありません。404 エラーを受け取った場合は、最初に API キーを確認してください。また、不適切なオブジェクトID (例: ``org_id``) を指定した場合にも 404 エラーが出力される可能性があります。" - -#: ../../rst/scenario_guides/guide_online.rst:3 -msgid "Online.net Guide" -msgstr "Online.net ガイド" - -#: ../../rst/scenario_guides/guide_online.rst:8 -msgid "Online is a French hosting company mainly known for providing bare-metal servers named Dedibox. Check it out: `https://www.online.net/en `_" -msgstr "Online は、主に Dedibox という名前のベアメタルサーバーを提供するフランス系のホスティング企業です。`https://www.online.net/en `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_online.rst:12 -msgid "Dynamic inventory for Online resources" -msgstr "Online リソースの動的インベントリー" - -#: ../../rst/scenario_guides/guide_online.rst:14 -msgid "Ansible has a dynamic inventory plugin that can list your resources." -msgstr "Ansible には、リソースを一覧表示できる動的インベントリープラグインがあります。" - -#: ../../rst/scenario_guides/guide_online.rst:16 -msgid "Create a YAML configuration such as ``online_inventory.yml`` with this content:" -msgstr "以下の内容で ``online_inventory.yml`` などの YAML 設定を作成します。" - -#: ../../rst/scenario_guides/guide_online.rst:24 -msgid "Set your ``ONLINE_TOKEN`` environment variable with your token." -msgstr "トークンを使用して、``ONLINE_TOKEN`` 環境変数を設定します。" - -#: ../../rst/scenario_guides/guide_online.rst:23 -msgid "You need to open an account and log into it before you can get a token. You can find your token at the following page: `https://console.online.net/en/api/access `_" -msgstr "トークンを取得するには、アカウントを開き、ログインする必要があります。トークンは、`https://console.online.net/en/api/access `_ のページで確認することができます。" - -#: ../../rst/scenario_guides/guide_online.rst:26 -msgid "You can test that your inventory is working by running:" -msgstr "以下を実行すると、インベントリーが機能していることをテストできます。" - -#: ../../rst/scenario_guides/guide_online.rst:33 -msgid "Now you can run your playbook or any other module with this inventory:" -msgstr "これで、Playbook またはその他のモジュールをこのインベントリーで実行できます。" - -#: ../../rst/scenario_guides/guide_oracle.rst:3 -msgid "Oracle Cloud Infrastructure Guide" -msgstr "Oracle Cloud Infrastructure ガイド" - -#: ../../rst/scenario_guides/guide_oracle.rst:9 -msgid "Oracle provides a number of Ansible modules to interact with Oracle Cloud Infrastructure (OCI). In this guide, we will explain how you can use these modules to orchestrate, provision and configure your infrastructure on OCI." -msgstr "Oracle では、Oracle Cloud Infrastructure (OCI) と対話する Ansible モジュールが多数提供されています。本ガイドでは、OCI でこれらのモジュールを使用したインフラストラクチャーのオーケストレーション、プロビジョニング、および設定の方法を説明します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:14 -msgid "To use the OCI Ansible modules, you must have the following prerequisites on your control node, the computer from which Ansible playbooks are executed." -msgstr "OCI Ansible モジュールを使用するには、Ansible Playbook を実行するコンピューターのコントロールノードに、以下の前提条件を設定する必要があります。" - -#: ../../rst/scenario_guides/guide_oracle.rst:16 -msgid "`An Oracle Cloud Infrastructure account. `_" -msgstr "`An Oracle Cloud Infrastructure account. `_" - -#: ../../rst/scenario_guides/guide_oracle.rst:18 -msgid "A user created in that account, in a security group with a policy that grants the necessary permissions for working with resources in those compartments. For guidance, see `How Policies Work `_." -msgstr "それらのコンパートメント内のリソースを操作するために必要なパーミッションを付与するポリシーを持つセキュリティーグループで、そのアカウントで作成されたユーザー。ガイダンスについては、「`ポリシーの仕組み `_」を参照してください。" - -#: ../../rst/scenario_guides/guide_oracle.rst:20 -msgid "The necessary credentials and OCID information." -msgstr "必要な認証情報および OCID 情報" - -#: ../../rst/scenario_guides/guide_oracle.rst:24 -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:37 -msgid "Installation" -msgstr "インストール" - -#: ../../rst/scenario_guides/guide_oracle.rst:25 -msgid "Install the Oracle Cloud Infrastructure Python SDK (`detailed installation instructions `_):" -msgstr "Oracle Cloud Infrastructure Python SDK (`detailed installation instructions `_) をインストールします。" - -#: ../../rst/scenario_guides/guide_oracle.rst:31 -msgid "Install the Ansible OCI Modules in one of two ways:" -msgstr "以下のいずれかの方法で Ansible OCI モジュールをインストールします。" - -#: ../../rst/scenario_guides/guide_oracle.rst:33 -msgid "From Galaxy:" -msgstr "Galaxy の場合:" - -#: ../../rst/scenario_guides/guide_oracle.rst:39 -msgid "From GitHub:" -msgstr "GitHub で、以下を行います。" - -#: ../../rst/scenario_guides/guide_oracle.rst:50 -msgid "Run one of the following commands:" -msgstr "以下のコマンドのいずれかを実行します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:52 -msgid "If Ansible is installed only for your user:" -msgstr "Ansible をお使いのユーザーにのみインストールする場合は、以下を実行します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:58 -msgid "If Ansible is installed as root:" -msgstr "Ansible を root でインストールする場合は、以下を実行します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:66 -#: ../../rst/scenario_guides/guide_vultr.rst:16 -msgid "Configuration" -msgstr "Configuration (構成)" - -#: ../../rst/scenario_guides/guide_oracle.rst:68 -msgid "When creating and configuring Oracle Cloud Infrastructure resources, Ansible modules use the authentication information outlined `here `_. ." -msgstr "Oracle Cloud Infrastructure リソースを作成して設定する際に、Ansible モジュールは `こちら `_ で説明されている認証情報を使用します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:75 -msgid "Launch a compute instance" -msgstr "コンピュートインスタンスの起動" - -#: ../../rst/scenario_guides/guide_oracle.rst:76 -msgid "This `sample launch playbook `_ launches a public Compute instance and then accesses the instance from an Ansible module over an SSH connection. The sample illustrates how to:" -msgstr "この `サンプルの起動 Playbook `_ は、パブリック Compute インスタンスを起動し、SSH 接続を介して Ansible モジュールからインスタンスにアクセスします。以下に例を示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:79 -msgid "Generate a temporary, host-specific SSH key pair." -msgstr "一時的なホスト固有の SSH キーペアを生成します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:80 -msgid "Specify the public key from the key pair for connecting to the instance, and then launch the instance." -msgstr "インスタンスに接続する鍵ペアから公開鍵を指定し、インスタンスを起動します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:81 -msgid "Connect to the newly launched instance using SSH." -msgstr "SSH を使用して新たに起動したインスタンスに接続します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:84 -msgid "Create and manage Autonomous Data Warehouses" -msgstr "Autonomous Data Warehouse の作成および管理" - -#: ../../rst/scenario_guides/guide_oracle.rst:85 -msgid "This `sample warehouse playbook `_ creates an Autonomous Data Warehouse and manage its lifecycle. The sample shows how to:" -msgstr "この `サンプルのウェアハウス Playbook `_ は自律型データウェアハウス (Autonomous Data Warehouse ) を作成し、そのライフサイクルを管理します。サンプルでは以下の方法を示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:87 -msgid "Set up an Autonomous Data Warehouse." -msgstr "Autonomous Data Warehouse を設定します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:88 -msgid "List all of the Autonomous Data Warehouse instances available in a compartment, filtered by the display name." -msgstr "表示名で対象を絞った、コンパートメントで利用可能な Autonomous Data Warehouse インスタンスの一覧を表示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:89 -msgid "Get the \"facts\" for a specified Autonomous Data Warehouse." -msgstr "指定した Autonomous Data Warehouse の「ファクト」を取得します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:90 -msgid "Stop and start an Autonomous Data Warehouse instance." -msgstr "Autonomous Data Warehouse インスタンスを停止して起動します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:91 -msgid "Delete an Autonomous Data Warehouse instance." -msgstr "Autonomous Data Warehouse インスタンスを削除します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:94 -msgid "Create and manage Autonomous Transaction Processing" -msgstr "Autonomous Transaction Processing の作成と管理" - -#: ../../rst/scenario_guides/guide_oracle.rst:95 -msgid "This `sample playbook `_ creates an Autonomous Transaction Processing database and manage its lifecycle. The sample shows how to:" -msgstr "この `Playbook サンプル `_ は、自律型トランザクション処理データベースを作成し、そのライフサイクルを管理します。サンプルは以下の方法を示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:98 -msgid "Set up an Autonomous Transaction Processing database instance." -msgstr "Autonomous Transaction Processing データベースインスタンスを設定します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:99 -msgid "List all of the Autonomous Transaction Processing instances in a compartment, filtered by the display name." -msgstr "表示名で対象を絞った、コンパートメントで利用可能な Autonomous Transaction Processing インスタンスの一覧を表示します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:100 -msgid "Get the \"facts\" for a specified Autonomous Transaction Processing instance." -msgstr "指定した Autonomous Transaction Processing インスタンスに対して「ファクト」を取得します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:101 -msgid "Delete an Autonomous Transaction Processing database instance." -msgstr "Autonomous Transaction Processing データベースインスタンスを削除します。" - -#: ../../rst/scenario_guides/guide_oracle.rst:103 -msgid "You can find more examples here: `Sample Ansible Playbooks `_." -msgstr "詳細は、`サンプル Ansible Playbook `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:3 -msgid "Packet.net Guide" -msgstr "Packet.net ガイド" - -#: ../../rst/scenario_guides/guide_packet.rst:8 -msgid "`Packet.net `_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) through a dynamic inventory script and two cloud modules. The two modules are:" -msgstr "`Packet.net `_ は、動的インベントリースクリプトと 2 つのクラウドモジュールを介して Ansible (2.3 以降) で対応しているベアメタルインフラストラクチャーホストです。この 2 つのモジュールは次のとおりです。" - -#: ../../rst/scenario_guides/guide_packet.rst:10 -msgid "packet_sshkey: adds a public SSH key from file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys." -msgstr "packet_sshkey: ファイルまたは値から Packet インフラストラクチャーに公開 SSH 鍵を追加します。今後作成されるすべてのデバイスの .ssh/authorized_keys にこの公開鍵がインストールされます。" - -#: ../../rst/scenario_guides/guide_packet.rst:11 -msgid "packet_device: manages servers on Packet. You can use this module to create, restart and delete devices." -msgstr "packet_device: パケット上のサーバーを管理します。このモジュールを使用して、デバイスの作成、再起動、および削除を行うことができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:13 -msgid "Note, this guide assumes you are familiar with Ansible and how it works. If you're not, have a look at their :ref:`docs ` before getting started." -msgstr "注記: 本ガイドでは、Ansible に精通していることを前提としています。Ansible にあまり精通していない場合は、開始する前に「:ref:`docs `」をお読みください。" - -#: ../../rst/scenario_guides/guide_packet.rst:18 -msgid "The Packet modules and inventory script connect to the Packet API using the packet-python package. You can install it with pip:" -msgstr "Packet モジュールとインベントリースクリプトは、packets-python パッケージを使用して Packet API に接続します。これは、pip でインストールできます。" - -#: ../../rst/scenario_guides/guide_packet.rst:24 -msgid "In order to check the state of devices created by Ansible on Packet, it's a good idea to install one of the `Packet CLI clients `_. Otherwise you can check them through the `Packet portal `_." -msgstr "パケット上で Ansible が作成したデバイスの状態をチェックするには、`Packet CLI clients `_ のいずれかをインストールすることが推奨されます。そうでない場合は、`Packet portal `_ で確認することができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:26 -msgid "To use the modules and inventory script you'll need a Packet API token. You can generate an API token through the Packet portal `here `__. The simplest way to authenticate yourself is to set the Packet API token in an environment variable:" -msgstr "モジュールおよびインベントリースクリプトを使用するには、パケット API トークンが必要です。パケットポータル (`here `__) を使用して API トークンを生成することができます。認証する最も簡単な方法は、環境変数で Packet API トークンを設定することです。" - -#: ../../rst/scenario_guides/guide_packet.rst:32 -msgid "If you're not comfortable exporting your API token, you can pass it as a parameter to the modules." -msgstr "API トークンのエクスポートが不明な場合は、これをパラメーターとしてモジュールに渡すことができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:34 -msgid "On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or through one of the available `CLIs `_." -msgstr "パケットでは、デバイスと予約済みの IP アドレスは、`projects `_ に属します。packet_device モジュールを使用するには、デバイスの作成または管理を行うプロジェクトの UUID を指定する必要があります。プロジェクトの UUID は、パケットポータル (`here `_ (プロジェクトテーブルのすぐ下にあります)) または利用可能な `CLIs `_ のいずれかを介して見つけることができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:37 -#: ../../rst/scenario_guides/guide_scaleway.rst:39 -msgid "If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as:" -msgstr "本チュートリアルで新しい SSH キーペアを使用する場合は、以下のように ``./id_rsa`` および ``./id_rsa.pub`` に生成してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:43 -#: ../../rst/scenario_guides/guide_scaleway.rst:45 -msgid "If you want to use an existing key pair, just copy the private and public key over to the playbook directory." -msgstr "既存のキーペアを使用する場合は、秘密鍵と公開鍵を Playbook ディレクトリーにコピーします。" - -#: ../../rst/scenario_guides/guide_packet.rst:47 -msgid "Device Creation" -msgstr "デバイスの作成" - -#: ../../rst/scenario_guides/guide_packet.rst:49 -msgid "The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters through a `CLI client `_." -msgstr "以下のコードブロックは、`Type 0 `_ サーバー (「plan」パラメーター) を作成する簡単な Playbook です。「plan」および「operating_system」を定義する必要があります。「location」は、「ewr1」(Parsippany、NJ) に設定されます。`CLI client `_ を介して、パラメーターで可能な値をすべて確認できます。" - -#: ../../rst/scenario_guides/guide_packet.rst:70 -msgid "After running ``ansible-playbook playbook_create.yml``, you should have a server provisioned on Packet. You can verify through a CLI or in the `Packet portal `__." -msgstr "``ansible-playbook playbook_create.yml`` の実行後に、パケット上にサーバーをプロビジョニングする必要があります。CLI または `Packet portal `__ で確認することができます。" - -#: ../../rst/scenario_guides/guide_packet.rst:72 -msgid "If you get an error with the message \"failed to set machine state present, error: Error 404: Not Found\", please verify your project UUID." -msgstr "エラーが発生して「failed to set machine state present, error: Error 404: Not Found」メッセージが表示された場合は、プロジェクトの UUID を確認してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:76 -msgid "Updating Devices" -msgstr "デバイスの更新" - -#: ../../rst/scenario_guides/guide_packet.rst:78 -msgid "The two parameters used to uniquely identify Packet devices are: \"device_ids\" and \"hostnames\". Both parameters accept either a single string (later converted to a one-element list), or a list of strings." -msgstr "Packet デバイスを一意に識別するために、「device_ids」および「hostnames」という 2 つのパラメーターがあります。どちらのパラメーターも、1 つの文字列 (後で単一の要素の一覧に変換) または文字列の一覧を受け入れます。" - -#: ../../rst/scenario_guides/guide_packet.rst:80 -msgid "The 'device_ids' and 'hostnames' parameters are mutually exclusive. The following values are all acceptable:" -msgstr "「device_ids」パラメーターおよび「hostnames」パラメーターは相互排他的です。以下の値はすべて受け入れ可能です。" - -#: ../../rst/scenario_guides/guide_packet.rst:82 -msgid "device_ids: a27b7a83-fc93-435b-a128-47a5b04f2dcf" -msgstr "device_ids: a27b7a83-fc93-435b-a128-47a5b04f2dcf" - -#: ../../rst/scenario_guides/guide_packet.rst:84 -msgid "hostnames: mydev1" -msgstr "hostnames: mydev1" - -#: ../../rst/scenario_guides/guide_packet.rst:86 -msgid "device_ids: [a27b7a83-fc93-435b-a128-47a5b04f2dcf, 4887130f-0ccd-49a0-99b0-323c1ceb527b]" -msgstr "device_ids: [a27b7a83-fc93-435b-a128-47a5b04f2dcf, 4887130f-0ccd-49a0-99b0-323c1ceb527b]" - -#: ../../rst/scenario_guides/guide_packet.rst:88 -msgid "hostnames: [mydev1, mydev2]" -msgstr "hostnames: [mydev1, mydev2]" - -#: ../../rst/scenario_guides/guide_packet.rst:90 -#, python-format -msgid "In addition, hostnames can contain a special '%d' formatter along with a 'count' parameter that lets you easily expand hostnames that follow a simple name and number pattern; in other words, ``hostnames: \"mydev%d\", count: 2`` will expand to [mydev1, mydev2]." -msgstr "さらに、ホスト名には、簡単な名前と数字のパターンに従うホスト名を簡単に拡張できる「count」パラメーターとともに特別な「%d」フォーマッターを含めることができます。つまり、``hostnames: \"mydev%d\", count: 2`` は [mydev1, mydev2] に拡張されます。" - -#: ../../rst/scenario_guides/guide_packet.rst:92 -msgid "If your playbook acts on existing Packet devices, you can only pass the 'hostname' and 'device_ids' parameters. The following playbook shows how you can reboot a specific Packet device by setting the 'hostname' parameter:" -msgstr "Playbook が既存のパケットデバイスに機能する場合は、「hostname」および「device_ids」のパラメーターを渡すことができます。以下の Playbook は、「hostname」パラメーターを設定して特定のパケットデバイスを再起動する方法を示しています。" - -#: ../../rst/scenario_guides/guide_packet.rst:107 -msgid "You can also identify specific Packet devices with the 'device_ids' parameter. The device's UUID can be found in the `Packet Portal `_ or by using a `CLI `_. The following playbook removes a Packet device using the 'device_ids' field:" -msgstr "「device_ids」パラメーターを使用して特定のパケットデバイスを識別することもできます。デバイスの UUID は、`Packet ポータル `_ か `CLI `_ を使用して確認できます。以下の Playbook は「device_ids」フィールドを使用してパケットデバイスを削除します。" - -#: ../../rst/scenario_guides/guide_packet.rst:124 -msgid "More Complex Playbooks" -msgstr "より複雑な Playbook" - -#: ../../rst/scenario_guides/guide_packet.rst:126 -msgid "In this example, we'll create a CoreOS cluster with `user data `_." -msgstr "この例では、`ユーザーデータ `_ で CoreOS クラスターを作成します。" - -#: ../../rst/scenario_guides/guide_packet.rst:129 -msgid "The CoreOS cluster will use `etcd `_ for discovery of other servers in the cluster. Before provisioning your servers, you'll need to generate a discovery token for your cluster:" -msgstr "CoreOS クラスターは、クラスター内の他のサーバーの検出に `etcd `_ を使用します。サーバーをプロビジョニングする前に、クラスターの検出トークンを生成する必要があります。" - -#: ../../rst/scenario_guides/guide_packet.rst:135 -msgid "The following playbook will create an SSH key, 3 Packet servers, and then wait until SSH is ready (or until 5 minutes passed). Make sure to substitute the discovery token URL in 'user_data', and the 'project_id' before running ``ansible-playbook``. Also, feel free to change 'plan' and 'facility'." -msgstr "以下の Playbook は、SSH キー、3 台の Packet サーバーを作成し、SSH の準備ができるまで (または 5 分経過するまで) 待ちます。``ansible-playbook`` を実行する前に、「user_data」の検出トークン URL と「project_id」を置き換えてください。また、「plan」と「facility」は自由に変更してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:184 -msgid "As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect." -msgstr "ほとんどの Ansible モジュールと同様に、Packet モジュールのデフォルト状態は冪等です。つまり、Playbook を再実行した後もプロジェクトのリソースは同じままになります。したがって、Playbook で ``packet_sshkey`` モジュールの呼び出しを維持できます。パブリックキーがすでにパケットアカウントにある場合は、呼び出しても効果がありません。" - -#: ../../rst/scenario_guides/guide_packet.rst:186 -msgid "The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified by the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter." -msgstr "2 つ目のモジュール呼び出しは、「project_id」パラメーターで識別されるプロジェクトの 3 Packet タイプ 0 (「plan」パラメーターで指定) サーバーをプロビジョニングします。サーバーはすべて CoreOS ベータでプロビジョニングされ (「operating_system」パラメーター)、「user_data」パラメーターに渡される cloud-config ユーザーデータでカスタマイズされます。" - -#: ../../rst/scenario_guides/guide_packet.rst:188 -msgid "The ``packet_device`` module has a ``wait_for_public_IPv`` that is used to specify the version of the IP address to wait for (valid values are ``4`` or ``6`` for IPv4 or IPv6). If specified, Ansible will wait until the GET API call for a device contains an Internet-routeable IP address of the specified version. When referring to an IP address of a created device in subsequent module calls, it's wise to use the ``wait_for_public_IPv`` parameter, or ``state: active`` in the packet_device module call." -msgstr "``packet_device`` モジュールには、待機する IP アドレスのバージョンを指定するために使用される ``wait_for_public_IPv`` があります (有効な値は、IPv4 または IPv6 である ``4`` または ``6``)。これが指定されている場合、Ansible はデバイスの GET API 呼び出しに指定バージョンのインターネットルーティング可能な IP アドレスが含まれるまで待機します。後続のモジュール呼び出しで作成されたデバイスの IP アドレスを参照する場合は、packet_device モジュール呼び出しで ``wait_for_public_IPv`` パラメーターまたは ``state: active`` を使用することが推奨されます。" - -#: ../../rst/scenario_guides/guide_packet.rst:190 -msgid "Run the playbook:" -msgstr "Playbook を実行します。" - -#: ../../rst/scenario_guides/guide_packet.rst:196 -msgid "Once the playbook quits, your new devices should be reachable through SSH. Try to connect to one and check if etcd has started properly:" -msgstr "Playbook が終了すると、SSH を介して新規デバイスにアクセスできるはずです。1 つのデバイスに接続して、etcd が正常に起動したかどうかを確認します。" - -#: ../../rst/scenario_guides/guide_packet.rst:203 -msgid "Once you create a couple of devices, you might appreciate the dynamic inventory script..." -msgstr "いくつかのデバイスを作成したら、動的インベントリースクリプトを利用できます。" - -#: ../../rst/scenario_guides/guide_packet.rst:209 -msgid "The dynamic inventory script queries the Packet API for a list of hosts, and exposes it to Ansible so you can easily identify and act on Packet devices." -msgstr "動的インベントリースクリプトは、ホストの一覧に Packet API をクエリーし、これを Ansible に公開して、Packet デバイスを簡単に識別し、操作できるようにします。" - -#: ../../rst/scenario_guides/guide_packet.rst:211 -msgid "You can find it in Ansible Community General Collection's git repo at `scripts/inventory/packet_net.py `_." -msgstr "Ansible Community General Collection の git リポジトリーは、`scripts/inventory/packet_net.py `_ にあります。" - -#: ../../rst/scenario_guides/guide_packet.rst:213 -msgid "The inventory script is configurable through an `ini file `_." -msgstr "インベントリースクリプトは、`ini file `_ で設定可能です。" - -#: ../../rst/scenario_guides/guide_packet.rst:215 -msgid "If you want to use the inventory script, you must first export your Packet API token to a PACKET_API_TOKEN environment variable." -msgstr "インベントリースクリプトを使用する場合、最初に Packet API トークンを PACKET_API_TOKEN 環境変数にエクスポートする必要があります。" - -#: ../../rst/scenario_guides/guide_packet.rst:217 -msgid "You can either copy the inventory and ini config out from the cloned git repo, or you can download it to your working directory like so:" -msgstr "インベントリーおよび ini 設定をクローンされた git リポジトリーからコピーするか、以下のように作業ディレクトリーにダウンロードできます。" - -#: ../../rst/scenario_guides/guide_packet.rst:225 -msgid "In order to understand what the inventory script gives to Ansible you can run:" -msgstr "インベントリースクリプトが Ansible に与える影響を理解するために、次を実行できます。" - -#: ../../rst/scenario_guides/guide_packet.rst:231 -msgid "It should print a JSON document looking similar to following trimmed dictionary:" -msgstr "以下のトリムされたディクショナリーのような JSON ドキュメントを出力する必要があります。" - -#: ../../rst/scenario_guides/guide_packet.rst:289 -msgid "In the ``['_meta']['hostvars']`` key, there is a list of devices (uniquely identified by their public IPv4 address) with their parameters. The other keys under ``['_meta']`` are lists of devices grouped by some parameter. Here, it is type (all devices are of type baremetal_0), operating system, and facility (ewr1 and sjc1)." -msgstr "``['_meta']['hostvars']`` キーには、デバイスの一覧 (特にパブリック IPv4 アドレスで識別されるもの) とそのパラメーターがあります。``['_meta']`` 以下の他のキーは、何らかのパラメータでグループ化されたデバイスのリストです。これは種類 (すべてのデバイスの種類は baremetal_0)、オペレーティングシステム、およびファシリティー (ewr1 および sjc1) です。" - -#: ../../rst/scenario_guides/guide_packet.rst:291 -msgid "In addition to the parameter groups, there are also one-item groups with the UUID or hostname of the device." -msgstr "パラメーターグループの他に、デバイスの UUID またはホスト名を持つ 1 項目グループもあります。" - -#: ../../rst/scenario_guides/guide_packet.rst:293 -msgid "You can now target groups in playbooks! The following playbook will install a role that supplies resources for an Ansible target into all devices in the \"coreos_beta\" group:" -msgstr "Playbook でグループをターゲットにできるようになりました。以下の Playbook は、「coreos_beta」グループのすべてのデバイスに Ansible ターゲットのリソースを提供するロールをインストールします。" - -#: ../../rst/scenario_guides/guide_packet.rst:304 -msgid "Don't forget to supply the dynamic inventory in the ``-i`` argument!" -msgstr "``-i`` 引数で忘れずに動的インベントリーを指定してください。" - -#: ../../rst/scenario_guides/guide_packet.rst:311 -msgid "If you have any questions or comments let us know! help@packet.net" -msgstr "ご質問やご感想は、help@packet.net までご連絡ください。" - -#: ../../rst/scenario_guides/guide_rax.rst:2 -msgid "Rackspace Cloud Guide" -msgstr "Rackspace Cloud ガイド" - -#: ../../rst/scenario_guides/guide_rax.rst:9 -msgid "Rackspace functionality in Ansible is not maintained and users should consider the `OpenStack collection `_ instead." -msgstr "Ansible の Rackspace 機能は維持されず、ユーザーは代わりに `OpenStack collection `_ を検討する必要があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:11 -msgid "Ansible contains a number of core modules for interacting with Rackspace Cloud." -msgstr "Ansible には、Rackspace Cloud と対話するためのコアモジュールが多数含まれています。" - -#: ../../rst/scenario_guides/guide_rax.rst:13 -msgid "The purpose of this section is to explain how to put Ansible modules together (and use inventory scripts) to use Ansible in a Rackspace Cloud context." -msgstr "本セクションでは、Ansible モジュールを組み合わせて (インベントリースクリプトを使用して)、Rackspace Cloudのコンテキストで Ansible を使用する方法を説明します。" - -#: ../../rst/scenario_guides/guide_rax.rst:16 -msgid "Prerequisites for using the rax modules are minimal. In addition to ansible itself, all of the modules require and are tested against pyrax 1.5 or higher. You'll need this Python module installed on the execution host." -msgstr "rax モジュール使用の前提条件は最小限です。Ansible 自体の他に、すべてのモジュールが必要で、pyrax 1.5 以降に対してテストされています。実行ホストに、この Python モジュールをインストールする必要があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:20 -msgid "``pyrax`` is not currently available in many operating system package repositories, so you will likely need to install it through pip:" -msgstr "``pyrax`` は、現在多くのオペレーティングシステムパッケージリポジトリーでは利用できないため、pip を使用してインストールしなければならない場合があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:27 -msgid "Ansible creates an implicit localhost that executes in the same context as the ``ansible-playbook`` and the other CLI tools. If for any reason you need or want to have it in your inventory you should do something like the following:" -msgstr "Ansible は、``ansible-playbook`` およびその他の CLI ツールと同じコンテキストで実行する暗黙的なローカルホストを作成します。何らかの理由で必要な場合やこれを使用する場合は、以下のような作業を行います。" - -#: ../../rst/scenario_guides/guide_rax.rst:35 -msgid "For more information see :ref:`Implicit Localhost `" -msgstr "詳細情報は、「:ref:`Implicit Localhost `」を参照してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:37 -msgid "In playbook steps, we'll typically be using the following pattern:" -msgstr "Playbook のステップでは、通常、以下のパターンを使用します。" - -#: ../../rst/scenario_guides/guide_rax.rst:50 -msgid "The `rax.py` inventory script and all `rax` modules support a standard `pyrax` credentials file that looks like:" -msgstr "`rax.py` インベントリースクリプトとすべての `rax` モジュールは、以下のような標準の `pyrax` 認証情報ファイルをサポートします。" - -#: ../../rst/scenario_guides/guide_rax.rst:58 -msgid "Setting the environment parameter ``RAX_CREDS_FILE`` to the path of this file will help Ansible find how to load this information." -msgstr "環境パラメーター ``RAX_CREDS_FILE`` にこのファイルのパスを設定することで、Ansible はこの情報を読み込む方法を見つけることができます。" - -#: ../../rst/scenario_guides/guide_rax.rst:61 -msgid "More information about this credentials file can be found at https://github.com/pycontribs/pyrax/blob/master/docs/getting_started.md#authenticating" -msgstr "この認証情報ファイルに関する詳細情報は、https://github.com/pycontribs/pyrax/blob/master/docs/getting_started.md#authenticating を参照してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:68 -msgid "Running from a Python Virtual Environment (Optional)" -msgstr "Python 仮想環境からの実行 (任意)" - -#: ../../rst/scenario_guides/guide_rax.rst:70 -msgid "Most users will not be using virtualenv, but some users, particularly Python developers sometimes like to." -msgstr "ほとんどのユーザーは virtualenv を使用しませんが、一部のユーザー、特に Python の開発者はそれを使用する場合があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:72 -msgid "There are special considerations when Ansible is installed to a Python virtualenv, rather than the default of installing at a global scope. Ansible assumes, unless otherwise instructed, that the python binary will live at /usr/bin/python. This is done through the interpreter line in modules, however when instructed by setting the inventory variable 'ansible_python_interpreter', Ansible will use this specified path instead to find Python. This can be a cause of confusion as one may assume that modules running on 'localhost', or perhaps running through 'local_action', are using the virtualenv Python interpreter. By setting this line in the inventory, the modules will execute in the virtualenv interpreter and have available the virtualenv packages, specifically pyrax. If using virtualenv, you may wish to modify your localhost inventory definition to find this location as follows:" -msgstr "Ansible が Python virtualenv にインストールされる場合には、デフォルトのグローバルスコープでのインストールではなく、特別な考慮事項があります。Ansible は、特に指示がない限り、Python のバイナリーを /usr/bin/python に置くことを前提としています。これは、モジュールのインタープリターの行から行われますが、インベントリー変数「ansible_python_interpreter」を設定して指示すると、Ansible は Python の検索の代わりに、この指定されたパスを使用します。これは、「localhost」で実行しているモジュール、または「local_action」で実行されるモジュールが virtualenv Python インタープリターを使用していると思い込んでしまうため、混乱が生じる可能性があります。この行をインベントリーに設定すると、モジュールは virtualenv インタープリターで実行し、virtualenv パッケージ (具体的には pyrax) が利用できるようになります。virtualenv を使用している場合は、以下のように、localhost インベントリー定義を変更してこの場所が検出されるようにします。" - -#: ../../rst/scenario_guides/guide_rax.rst:81 -msgid "pyrax may be installed in the global Python package scope or in a virtual environment. There are no special considerations to keep in mind when installing pyrax." -msgstr "pyrax は、グローバルな Python パッケージスコープまたは仮想環境にインストールすることができます。pyrax をインストールする際には、特別な考慮事項に留意してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:88 -msgid "Now for the fun parts." -msgstr "ここからが重要です。" - -#: ../../rst/scenario_guides/guide_rax.rst:90 -msgid "The 'rax' module provides the ability to provision instances within Rackspace Cloud. Typically the provisioning task will be performed from your Ansible control server (in our example, localhost) against the Rackspace cloud API. This is done for several reasons:" -msgstr "「rax」モジュールは、Rackspace Cloud 内でインスタンスをプロビジョニングする機能を提供します。通常、プロビジョニングタスクは、Rackspace Cloud API に対して Ansible コントロールサーバー (この例ではローカルホスト) から実行します。これには、いくつかの理由があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:92 -msgid "Avoiding installing the pyrax library on remote nodes" -msgstr "リモートノードに pyrax ライブラリーをインストールしないようにする" - -#: ../../rst/scenario_guides/guide_rax.rst:93 -msgid "No need to encrypt and distribute credentials to remote nodes" -msgstr "認証情報を暗号化してリモートノードに配布する必要はない" - -#: ../../rst/scenario_guides/guide_rax.rst:94 -msgid "Speed and simplicity" -msgstr "スピードおよび単純化" - -#: ../../rst/scenario_guides/guide_rax.rst:98 -msgid "Authentication with the Rackspace-related modules is handled by either specifying your username and API key as environment variables or passing them as module arguments, or by specifying the location of a credentials file." -msgstr "Rackspace に関連するモジュールを使用した認証は、ユーザー名および API キーを環境変数として指定するか、モジュール引数として渡すか、認証情報ファイルの場所を指定して処理されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:103 -msgid "Here is a basic example of provisioning an instance in ad hoc mode:" -msgstr "以下は、アドホックモードでのインスタンスをプロビジョニングする基本的な例です。" - -#: ../../rst/scenario_guides/guide_rax.rst:109 -msgid "Here's what it would look like in a playbook, assuming the parameters were defined in variables:" -msgstr "以下は、パラメーターが変数に定義されていると仮定した場合の、Playbook で表示される内容です。" - -#: ../../rst/scenario_guides/guide_rax.rst:125 -msgid "The rax module returns data about the nodes it creates, like IP addresses, hostnames, and login passwords. By registering the return value of the step, it is possible used this data to dynamically add the resulting hosts to inventory (temporarily, in memory). This facilitates performing configuration actions on the hosts in a follow-on task. In the following example, the servers that were successfully created using the above task are dynamically added to a group called \"raxhosts\", with each nodes hostname, IP address, and root password being added to the inventory." -msgstr "rax モジュールは、IP アドレス、ホスト名、ログインパスワードなど、作成するノードのデータを返します。ステップの戻り値を登録すると、このデータを使用して、作成されるホストをインベントリー (通常はメモリー内) に動的に追加できます。これにより、後続のタスクによるホストでの設定アクションの実行が容易になります。以下の例では、上記のタスクを使用して正常に作成されたサーバーは「raxhosts」というグループに動的に追加され、各ノードのホスト名、IP アドレス、および root パスワードがインベントリーに追加されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:138 -msgid "With the host group now created, the next play in this playbook could now configure servers belonging to the raxhosts group." -msgstr "これでホストグループが作成され、この Playbook の次のプレイで raxhosts グループに属するサーバーを設定できるようになりました。" - -#: ../../rst/scenario_guides/guide_rax.rst:149 -msgid "The method above ties the configuration of a host with the provisioning step. This isn't always what you want, and leads us to the next section." -msgstr "上記の方法でプロビジョニングステップでホストの設定を統合します。これは必ずしも望ましいことではなく、次のセクションにつながります。" - -#: ../../rst/scenario_guides/guide_rax.rst:155 -msgid "Host Inventory" -msgstr "ホストインベントリー" - -#: ../../rst/scenario_guides/guide_rax.rst:157 -msgid "Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle this is to use the \"rax\" inventory plugin, which dynamically queries Rackspace Cloud and tells Ansible what nodes you have to manage. You might want to use this even if you are spinning up cloud instances through other tools, including the Rackspace Cloud user interface. The inventory plugin can be used to group resources by metadata, region, OS, and so on. Utilizing metadata is highly recommended in \"rax\" and can provide an easy way to sort between host groups and roles. If you don't want to use the ``rax.py`` dynamic inventory script, you could also still choose to manually manage your INI inventory file, though this is less recommended." -msgstr "ノードが起動したら、再びノードとやり取りしたくなるでしょう。これを処理する最善の方法は、「rax」インベントリープラグインを使用することです。これは、Rackspace Cloud に動的にクエリーを実行し、管理する必要があるノードを Ansible に通知します。Rackspace Cloud ユーザーインターフェースなど、他のツールでクラウドインスタンスを起動している場合でも、このプラグインを使用することができます。インベントリープラグインは、メタデータ、リージョン、OS などでリソースをグループ化するために使用できます。メタデータの使用は「rax」で強く推奨され、ホストグループとロールとの間で簡単に並べ替えることができます。``rax.py`` ダイナミックインベントリースクリプトを使用したくない場合は、INI インベントリーファイルを手動で管理することもできますが、これはあまりお勧めできません。" - -#: ../../rst/scenario_guides/guide_rax.rst:159 -msgid "In Ansible it is quite possible to use multiple dynamic inventory plugins along with INI file data. Just put them in a common directory and be sure the scripts are chmod +x, and the INI-based ones are not." -msgstr "Ansible では、INI ファイルデータとともに複数の動的インベントリープラグインを使用できます。これらのプラグインを共通ディレクトリーに置き、スクリプトに chmod +x を設定し、INI ベースのファイルには chmod +x を設定しないようにします。" - -#: ../../rst/scenario_guides/guide_rax.rst:164 -msgid "rax.py" -msgstr "rax.py" - -#: ../../rst/scenario_guides/guide_rax.rst:166 -msgid "To use the Rackspace dynamic inventory script, copy ``rax.py`` into your inventory directory and make it executable. You can specify a credentials file for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable." -msgstr "Rackspace 動的インベントリースクリプトを使用するには、``rax.py`` をインベントリーディレクトリーにコピーして、実行可能にします。``RAX_CREDS_FILE`` 環境変数を使用すると、``rax.py`` 用の認証情報ファイルを指定できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:168 -msgid "Dynamic inventory scripts (like ``rax.py``) are saved in ``/usr/share/ansible/inventory`` if Ansible has been installed globally. If installed to a virtualenv, the inventory scripts are installed to ``$VIRTUALENV/share/inventory``." -msgstr "Ansible がグローバルにインストールされている場合は、動的インベントリースクリプト (``rax.py`` など) が ``/usr/share/ansible/inventory`` に保存されます。virtualenv にインストールされると、インベントリースクリプトは ``$VIRTUALENV/share/inventory`` にインストールされます。" - -#: ../../rst/scenario_guides/guide_rax.rst:170 -msgid "Users of :ref:`ansible_platform` will note that dynamic inventory is natively supported by the controller in the platform, and all you have to do is associate a group with your Rackspace Cloud credentials, and it will easily synchronize without going through these steps::" -msgstr ":ref:`ansible_platform` のユーザーは、プラットフォームのコントローラーが動的インベントリーをネイティブにサポートしており、グループを Rackspace Cloud 認証情報に関連付けるだけで、このステップを実行せずに簡単に同期できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:174 -msgid "``rax.py`` also accepts a ``RAX_REGION`` environment variable, which can contain an individual region, or a comma separated list of regions." -msgstr "``rax.py`` は、個別のリージョンまたはコンマ区切りのリージョン一覧を指定できる ``RAX_REGION`` 環境変数も受け入れます。" - -#: ../../rst/scenario_guides/guide_rax.rst:176 -msgid "When using ``rax.py``, you will not have a 'localhost' defined in the inventory." -msgstr "``rax.py`` を使用する場合は、インベントリーに「localhost」が定義されません。" - -#: ../../rst/scenario_guides/guide_rax.rst:178 -msgid "As mentioned previously, you will often be running most of these modules outside of the host loop, and will need 'localhost' defined. The recommended way to do this, would be to create an ``inventory`` directory, and place both the ``rax.py`` script and a file containing ``localhost`` in it." -msgstr "前述したように、これらのモジュールのほとんどは、ホストループの外で実行されることが多いため、「localhost」を定義する必要があります。これを行うには、``inventory`` ディレクトリーを作成し、``rax.py`` スクリプトと、``localhost`` を含むファイルの両方をそのディレクトリーに置くことが推奨されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:180 -msgid "Executing ``ansible`` or ``ansible-playbook`` and specifying the ``inventory`` directory instead of an individual file, will cause ansible to evaluate each file in that directory for inventory." -msgstr "``ansible`` または ``ansible-playbook`` を実行し、個別のファイルではなく ``inventory`` ディレクトリーを指定すると、Ansible はインベントリー用にそのディレクトリー内の各ファイルを評価します。" - -#: ../../rst/scenario_guides/guide_rax.rst:183 -msgid "Let's test our inventory script to see if it can talk to Rackspace Cloud." -msgstr "インベントリースクリプトをテストし、Rackspace Cloud と通信できるかどうかを確認します。" - -#: ../../rst/scenario_guides/guide_rax.rst:189 -msgid "Assuming things are properly configured, the ``rax.py`` inventory script will output information similar to the following information, which will be utilized for inventory and variables." -msgstr "設定が適切に行われていれば、``rax.py`` インベントリスクリプトは、インベントリーおよび変数に使用される以下のような情報と同様の情報を出力します。" - -#: ../../rst/scenario_guides/guide_rax.rst:287 -msgid "Standard Inventory" -msgstr "標準インベントリー" - -#: ../../rst/scenario_guides/guide_rax.rst:289 -msgid "When utilizing a standard ini formatted inventory file (as opposed to the inventory plugin), it may still be advantageous to retrieve discoverable hostvar information from the Rackspace API." -msgstr "(インベントリープラグインではなく) 標準の ini 形式のインベントリーファイルを使用する場合でも、検出可能な hostvar 情報を Rackspace API から取得すると有効な場合があります。" - -#: ../../rst/scenario_guides/guide_rax.rst:291 -msgid "This can be achieved with the ``rax_facts`` module and an inventory file similar to the following:" -msgstr "これは、``rax_facts`` モジュールと以下のようなインベントリーファイルで実現できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:315 -msgid "While you don't need to know how it works, it may be interesting to know what kind of variables are returned." -msgstr "どのように機能するかを知る必要はありませんが、返される変数の種類を把握しておくといいでしょう、" - -#: ../../rst/scenario_guides/guide_rax.rst:317 -msgid "The ``rax_facts`` module provides facts as following, which match the ``rax.py`` inventory script:" -msgstr "``rax_facts`` モジュールは、``rax.py`` インベントリースクリプトに一致する以下のようなファクトを提供します。" - -#: ../../rst/scenario_guides/guide_rax.rst:408 -msgid "This section covers some additional usage examples built around a specific use case." -msgstr "本セクションでは、特定のユースケースを中心とした、その他の使用例を説明します。" - -#: ../../rst/scenario_guides/guide_rax.rst:413 -msgid "Network and Server" -msgstr "ネットワークおよびサーバー" - -#: ../../rst/scenario_guides/guide_rax.rst:415 -msgid "Create an isolated cloud network and build a server" -msgstr "分離したクラウドネットワークを作成し、サーバーを構築します。" - -#: ../../rst/scenario_guides/guide_rax.rst:455 -msgid "Complete Environment" -msgstr "完全な環境" - -#: ../../rst/scenario_guides/guide_rax.rst:457 -msgid "Build a complete webserver environment with servers, custom networks and load balancers, install nginx and create a custom index.html" -msgstr "サーバー、カスタムネットワーク、およびロードバランサーで完全な Web サーバー環境を構築し、nginx をインストールしてカスタムの index.html を作成します。" - -#: ../../rst/scenario_guides/guide_rax.rst:555 -msgid "RackConnect and Managed Cloud" -msgstr "RackConnect および Managed Cloud" - -#: ../../rst/scenario_guides/guide_rax.rst:557 -msgid "When using RackConnect version 2 or Rackspace Managed Cloud there are Rackspace automation tasks that are executed on the servers you create after they are successfully built. If your automation executes before the RackConnect or Managed Cloud automation, you can cause failures and unusable servers." -msgstr "RackConnect バージョン 2 または Rackspace Managed Cloud を使用する場合は、作成したサーバーが正常に構築された後に実行される Rackspace の自動化タスクがあります。その自動化が「RackConnect」または「Managed Cloud」の自動化よりも前に実行されてしまうと、障害が発生したり、サーバーが利用できなくなったりします。" - -#: ../../rst/scenario_guides/guide_rax.rst:559 -msgid "These examples show creating servers, and ensuring that the Rackspace automation has completed before Ansible continues onwards." -msgstr "これらの例は、サーバーを作成し、Ansible が続行する前に、Rackspace 自動化が完了したことを確認します。" - -#: ../../rst/scenario_guides/guide_rax.rst:561 -msgid "For simplicity, these examples are joined, however both are only needed when using RackConnect. When only using Managed Cloud, the RackConnect portion can be ignored." -msgstr "分かりやすくするために、この例は一緒になっていますが、どちらも RackConnect を使用する場合に限り必要です。Managed Cloud のみを使用する場合は、RackConnect の部分が無視されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:563 -msgid "The RackConnect portions only apply to RackConnect version 2." -msgstr "RackConnect の部分は、RackConnect バージョン 2 にのみ適用されます。" - -#: ../../rst/scenario_guides/guide_rax.rst:568 -msgid "Using a Control Machine" -msgstr "コントロールマシンの使用" - -#: ../../rst/scenario_guides/guide_rax.rst:655 -msgid "Using Ansible Pull" -msgstr "Ansible Pull の使用" - -#: ../../rst/scenario_guides/guide_rax.rst:713 -msgid "Using Ansible Pull with XenStore" -msgstr "XenStore での Ansible Pull の使用" - -#: ../../rst/scenario_guides/guide_rax.rst:781 -msgid "Advanced Usage" -msgstr "高度な使用方法" - -#: ../../rst/scenario_guides/guide_rax.rst:786 -msgid "Autoscaling with AWX or Red Hat Ansible Automation Platform" -msgstr "AWX または Red Hat Ansible Automation Platform での自動スケーリング" - -#: ../../rst/scenario_guides/guide_rax.rst:788 -msgid "The GUI component of :ref:`Red Hat Ansible Automation Platform ` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call a defined URL and the server will \"dial out\" to the requester and configure an instance that is spinning up. This can be a great way to reconfigure ephemeral nodes. See `the documentation on provisioning callbacks `_ for more details." -msgstr "また、:ref:`Red Hat Ansible Automation Platform ` の GUI コンポーネントは、自動スケーリングのユースケースには非常に優れた機能も含まれています。このモードでは、簡単な curl スクリプトは定義された URL を呼び出すことができ、サーバーは要求元に対して「ダイヤルアウト」し、起動しているインスタンスを構成します。これは、一時ノードを再設定する優れた方法になります。詳細は、`the documentation on provisioning callbacks `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_rax.rst:792 -msgid "A benefit of using the callback approach over pull mode is that job results are still centrally recorded and less information has to be shared with remote hosts." -msgstr "pull モードでコールバックアプローチを使用する利点は、ジョブの結果が引き続き中央で記録され、リモートホストと共有する必要のある情報が少なくなることです。" - -#: ../../rst/scenario_guides/guide_rax.rst:798 -msgid "Orchestration in the Rackspace Cloud" -msgstr "Rackspace Cloud のオーケストレーション" - -#: ../../rst/scenario_guides/guide_rax.rst:800 -msgid "Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other piece of software in an environment. Complex deployments might have previously required manual manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additional nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example:" -msgstr "Ansible は強力なオーケストレーションツールであり、rax モジュールを使用することで、複雑なタスク、デプロイメント、および設定のオーケストレーションが可能になります。ここでは、環境内にある他のソフトウェアと同様、インフラストラクチャーのプロビジョニングを自動化することが重要になります。複雑なデプロイメントを行う場合、これまではロードバランサーを手動で操作したり、サーバーのプロビジョニングを手動で行う必要があったかもしれません。Ansible に含まれる rax モジュールを利用すると、現在稼働しているノードの数に応じてノードを追加したり、共通のメタデータを使用してノードの数に応じてクラスター化されたアプリケーションを構成したりすることができます。たとえば、以下のようなシナリオを自動化できます。" - -#: ../../rst/scenario_guides/guide_rax.rst:802 -msgid "Servers that are removed from a Cloud Load Balancer one-by-one, updated, verified, and returned to the load balancer pool" -msgstr "Cloud Load Balancer から 1 つずつ削除され、更新され、検証され、ロードバランサープールに返されるサーバー" - -#: ../../rst/scenario_guides/guide_rax.rst:803 -msgid "Expansion of an already-online environment, where nodes are provisioned, bootstrapped, configured, and software installed" -msgstr "ノードのプロビジョニング、ブートストラップ、設定、およびソフトウェアがインストールされている、すでにオンラインの環境の拡張" - -#: ../../rst/scenario_guides/guide_rax.rst:804 -msgid "A procedure where app log files are uploaded to a central location, like Cloud Files, before a node is decommissioned" -msgstr "ノードが廃止される前に、アプリのログファイルが Cloud Files などの中央の場所にアップロードされる手順" - -#: ../../rst/scenario_guides/guide_rax.rst:805 -msgid "Servers and load balancers that have DNS records created and destroyed on creation and decommissioning, respectively" -msgstr "作成時に DNS レコードが作成され、廃止時に破棄されるサーバーとロードバランサー" - -#: ../../rst/scenario_guides/guide_scaleway.rst:5 -msgid "Scaleway Guide" -msgstr "Scaleway ガイド" - -#: ../../rst/scenario_guides/guide_scaleway.rst:12 -msgid "`Scaleway `_ is a cloud provider supported by Ansible, version 2.6 or higher through a dynamic inventory plugin and modules. Those modules are:" -msgstr "`Scaleway `_ は、動的インベントリープラグインおよびモジュールを介して Ansible (バージョン 2.6 以降) が対応するクラウドプロバイダーです。このモジュールは以下のようになります。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:15 -msgid ":ref:`scaleway_sshkey_module`: adds a public SSH key from a file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys." -msgstr ":ref:`scaleway_sshkey_module`: ファイルまたは値から Packet インフラストラクチャーに公開 SSH 鍵を追加します。後に作成したすべてのデバイスの .ssh/authorized_keys にこの公開鍵がインストールされます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:16 -msgid ":ref:`scaleway_compute_module`: manages servers on Scaleway. You can use this module to create, restart and delete servers." -msgstr ":ref:`scaleway_compute_module`: Scaleway でサーバーを管理します。このモジュールを使用してサーバーを作成、再起動、および削除できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:17 -msgid ":ref:`scaleway_volume_module`: manages volumes on Scaleway." -msgstr ":ref:`scaleway_volume_module`: Scaleway でボリュームを管理します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:20 -msgid "This guide assumes you are familiar with Ansible and how it works. If you're not, have a look at :ref:`ansible_documentation` before getting started." -msgstr "本ガイドでは、Ansible に精通していることを前提としています。Ansible にあまり精通していない場合は、開始する前に「:ref:`ansible_documentation`」をお読みください。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:28 -msgid "The Scaleway modules and inventory script connect to the Scaleway API using `Scaleway REST API `_. To use the modules and inventory script you'll need a Scaleway API token. You can generate an API token through the Scaleway console `here `__. The simplest way to authenticate yourself is to set the Scaleway API token in an environment variable:" -msgstr "Scaleway モジュールとインベントリースクリプトは、`Scaleway REST API `_ を使用して Scaleway API に接続します。モジュールとインベントリースクリプトを使用するには、Scaleway API トークンが必要です。API トークンは、Scaleway コンソール (`here `__) で生成できます。自身を認証する最も簡単な方法は、環境変数に Scaleway API トークンを設定することです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:37 -msgid "If you're not comfortable exporting your API token, you can pass it as a parameter to the modules using the ``api_token`` argument." -msgstr "API トークンのエクスポートに抵抗がある場合は、``api_token`` 引数を使用してこれをパラメーターとしてモジュールに渡すことができます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:50 -msgid "How to add an SSH key?" -msgstr "SSH キーの追加方法" - -#: ../../rst/scenario_guides/guide_scaleway.rst:52 -msgid "Connection to Scaleway Compute nodes use Secure Shell. SSH keys are stored at the account level, which means that you can re-use the same SSH key in multiple nodes. The first step to configure Scaleway compute resources is to have at least one SSH key configured." -msgstr "Scaleway コンピュートノードへの接続は、Secure Shell を使用します。SSH キーはアカウントレベルに保存されるため、同じ SSH キーを複数のノードで再利用できます。Scaleway コンピュートリソースを設定する最初の手順は、少なくとも 1 つの SSH キーを設定することです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:56 -msgid ":ref:`scaleway_sshkey_module` is a module that manages SSH keys on your Scaleway account. You can add an SSH key to your account by including the following task in a playbook:" -msgstr ":ref:`scaleway_sshkey_module` は、Scaleway アカウントで SSH キーを管理するモジュールです。SSH キーは、Playbook に以下のタスクを含めることでアカウントに追加できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:66 -msgid "The ``ssh_pub_key`` parameter contains your ssh public key as a string. Here is an example inside a playbook:" -msgstr "``ssh_pub_key`` パラメーターには、文字列として ssh 公開鍵が含まれます。これは、Playbook 内の例です。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:91 -msgid "How to create a compute instance?" -msgstr "コンピュートインスタンスの作成方法" - -#: ../../rst/scenario_guides/guide_scaleway.rst:93 -msgid "Now that we have an SSH key configured, the next step is to spin up a server! :ref:`scaleway_compute_module` is a module that can create, update and delete Scaleway compute instances:" -msgstr "これで SSH キーが設定されたため、次の手順ではサーバーを起動します。:ref:`scaleway_compute_module` は、Scaleway コンピュートインスタンスの作成、更新、および削除が可能なモジュールです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:107 -msgid "Here are the parameter details for the example shown above:" -msgstr "以下は、上述のパラメーターの詳細です。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:109 -msgid "``name`` is the name of the instance (the one that will show up in your web console)." -msgstr "``name`` インスタンスの名前 (Web コンソールに表示されるもの)。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:110 -msgid "``image`` is the UUID of the system image you would like to use. A list of all images is available for each availability zone." -msgstr "``image`` は、使用するシステムイメージの UUID です。各アベイラビリティーゾーンでイメージ一覧が利用できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:112 -msgid "``organization`` represents the organization that your account is attached to." -msgstr "``organization`` アカウントを登録している組織を表します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:113 -msgid "``region`` represents the Availability Zone which your instance is in (for this example, par1 and ams1)." -msgstr "``region`` は、インスタンスが存在するアベイラビリティーゾーン (例: par1 および ams1) を表します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:114 -msgid "``commercial_type`` represents the name of the commercial offers. You can check out the Scaleway pricing page to find which instance is right for you." -msgstr "``commercial_type`` は、販売サービスの名前を表します。Scaleway 価格ページでは、どのインスタンスが適しているかを確認できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:117 -msgid "Take a look at this short playbook to see a working example using ``scaleway_compute``:" -msgstr "この短い Playbook を参照して、``scaleway_compute`` を使用した作業例を確認してください。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:172 -msgid "Ansible ships with :ref:`scaleway_inventory`. You can now get a complete inventory of your Scaleway resources through this plugin and filter it on different parameters (``regions`` and ``tags`` are currently supported)." -msgstr "Ansible には :ref:`scaleway_inventory` が同梱されます。このプラグインを介して、Scaleway リソースの完全なインベントリーを取得し、異なるパラメーターでフィルターできるようになりました (``regions`` および ``tags`` は現在サポートされています)。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:176 -msgid "Let's create an example! Suppose that we want to get all hosts that got the tag web_server. Create a file named ``scaleway_inventory.yml`` with the following content:" -msgstr "以下に例を示します。web_server タグを付けたすべてのホストを取得します。以下の内容で ``scaleway_inventory.yml`` という名前のファイルを作成します。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:189 -msgid "This inventory means that we want all hosts that got the tag ``web_server`` on the zones ``ams1`` and ``par1``. Once you have configured this file, you can get the information using the following command:" -msgstr "このインベントリーは、``ams1`` ゾーンおよび ``par1`` ゾーンでタグ ``web_server`` を取得したすべてのホストが必要なことを示しています。このファイルを設定したら、以下のコマンドを使用して情報を取得できます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:196 -msgid "The output will be:" -msgstr "出力は以下のようになります。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:239 -msgid "As you can see, we get different groups of hosts. ``par1`` and ``ams1`` are groups based on location. ``web_server`` is a group based on a tag." -msgstr "ご覧のとおり、ホストのグループが異なります。``par1`` および ``ams1`` は場所に基づいたグループです。``web_server`` は、タグに基づいたグループです。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:243 -msgid "In case a filter parameter is not defined, the plugin supposes all values possible are wanted. This means that for each tag that exists on your Scaleway compute nodes, a group based on each tag will be created." -msgstr "フィルターパラメーターが定義されていないと、プラグインは可能な値がすべて必要であると想定します。これにより、Scaleway コンピュートノードに存在するタグごとに、各タグに基づいたグループが作成されます。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:247 -msgid "Scaleway S3 object storage" -msgstr "Scaleway S3 オブジェクトストレージ" - -#: ../../rst/scenario_guides/guide_scaleway.rst:249 -msgid "`Object Storage `_ allows you to store any kind of objects (documents, images, videos, and so on). As the Scaleway API is S3 compatible, Ansible supports it natively through the modules: :ref:`s3_bucket_module`, :ref:`aws_s3_module`." -msgstr "`Object Storage `_ を使用すると、あらゆる種類のオブジェクト (ドキュメント、イメージ、録画など) を保存できます。Scaleway API は S3 互換であるため、Ansible はモジュール :ref:`s3_bucket_module`、:ref:`aws_s3_module` でネイティブにサポートします。" - -#: ../../rst/scenario_guides/guide_scaleway.rst:252 -msgid "You can find many examples in the `scaleway_s3 integration tests `_." -msgstr "`scaleway_s3 統合ゲスト `_ に、例が多数あります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:2 -msgid "Vagrant Guide" -msgstr "Vagrant ガイド" - -#: ../../rst/scenario_guides/guide_vagrant.rst:9 -msgid "`Vagrant `_ is a tool to manage virtual machine environments, and allows you to configure and use reproducible work environments on top of various virtualization and cloud platforms. It also has integration with Ansible as a provisioner for these virtual machines, and the two tools work together well." -msgstr "`Vagrant `_ は、仮想マシン環境を管理するためのツールで、さまざまな仮想化やクラウドプラットフォームで、再現性のある作業環境を構成して利用することができます。また、これらの仮想マシンのプロビジョナーとして Ansible と連携しており、2 つのツールが適切に連携しています。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:15 -msgid "This guide will describe how to use Vagrant 1.7+ and Ansible together." -msgstr "本ガイドでは、Vagrant 1.7 以降および Ansible を一緒に使用する方法を説明します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:17 -msgid "If you're not familiar with Vagrant, you should visit `the documentation `_." -msgstr "Vagrant に精通していない場合は、`the documentation `_ にアクセスする必要があります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:20 -msgid "This guide assumes that you already have Ansible installed and working. Running from a Git checkout is fine. Follow the :ref:`installation_guide` guide for more information." -msgstr "本ガイドでは、すでに Ansible がインストールされ、動作していることを前提としています。Git checkout からの実行も可能です。詳細は、「:ref:`installation_guide`」ガイドを参照してください。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:27 -msgid "Vagrant Setup" -msgstr "Vagrant 設定" - -#: ../../rst/scenario_guides/guide_vagrant.rst:29 -msgid "The first step once you've installed Vagrant is to create a ``Vagrantfile`` and customize it to suit your needs. This is covered in detail in the Vagrant documentation, but here is a quick example that includes a section to use the Ansible provisioner to manage a single machine:" -msgstr "Vagrant をインストールしたらまず、``Vagrantfile`` を作成し、ニーズに合わせてカスタマイズすることになります。これについては Vagrant のドキュメントで詳しく説明されていますが、ここでは簡単な例として、Ansible プロビジョナーを使用して 1 台のマシンを管理するセクションを紹介します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:50 -msgid "Notice the ``config.vm.provision`` section that refers to an Ansible playbook called ``playbook.yml`` in the same directory as the ``Vagrantfile``. Vagrant runs the provisioner once the virtual machine has booted and is ready for SSH access." -msgstr "``Vagrantfile`` と同じディレクトリーにある ``playbook.yml`` という名前の Ansible Playbook を参照している ``config.vm.provision`` セクションに注目してください。Vagrant は、仮想マシンが起動し、SSH アクセスの準備が整ったらプロビジョナーを実行します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:55 -msgid "There are a lot of Ansible options you can configure in your ``Vagrantfile``. Visit the `Ansible Provisioner documentation `_ for more information." -msgstr "``Vagrantfile`` で設定できる Ansible オプションが多数あります。詳細は、`Ansible Provisioner ドキュメント `_ を参照してください。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:64 -msgid "This will start the VM, and run the provisioning playbook (on the first VM startup)." -msgstr "これにより、仮想マシンが起動し、(最初の仮想マシンの起動で) プロビジョニング Playbook を実行します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:68 -msgid "To re-run a playbook on an existing VM, just run:" -msgstr "既存の仮想マシンで Playbook を再実行するには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:74 -msgid "This will re-run the playbook against the existing VM." -msgstr "これにより、Playbook が既存の仮想マシンに対して再実行されます。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:76 -msgid "Note that having the ``ansible.verbose`` option enabled will instruct Vagrant to show the full ``ansible-playbook`` command used behind the scene, as illustrated by this example:" -msgstr "``ansible.verbose`` オプションを有効にすると、以下の例のように、内部で使用される ``ansible-playbook`` コマンド全体を表示するよう Vagrant に指示することに注意してください。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:84 -msgid "This information can be quite useful to debug integration issues and can also be used to manually execute Ansible from a shell, as explained in the next section." -msgstr "この情報は、統合の問題のデバッグに非常に便利です。また、次のセクションで説明されているように、シェルから Ansible を手動で実行するために使用できます。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:91 -msgid "Running Ansible Manually" -msgstr "Ansible の手動実行" - -#: ../../rst/scenario_guides/guide_vagrant.rst:93 -msgid "Sometimes you may want to run Ansible manually against the machines. This is faster than kicking ``vagrant provision`` and pretty easy to do." -msgstr "マシンに対して手動で Ansible を実行したい場合があります。これは、``vagrant provision`` を実行するよりも速く、非常に簡単にできます。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:96 -msgid "With our ``Vagrantfile`` example, Vagrant automatically creates an Ansible inventory file in ``.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory``. This inventory is configured according to the SSH tunnel that Vagrant automatically creates. A typical automatically-created inventory file for a single machine environment may look something like this:" -msgstr "``Vagrantfile`` の例では、Vagrant が ``.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory`` に Ansible インベントリーファイルを自動的に作成します。このインベントリーは Vagrant が自動的に作成する SSH トンネルに従って設定されます。シングルマシン環境用で典型的な自動作成されたインベントリーファイルは、以下のようになります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:108 -msgid "If you want to run Ansible manually, you will want to make sure to pass ``ansible`` or ``ansible-playbook`` commands the correct arguments, at least for the *inventory*." -msgstr "Ansible を手動で実行する場合は、少なくとも *インベントリー* 対して、``ansible`` コマンドまたは ``ansible-playbook`` コマンドに正しい引数を渡す必要があります。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:117 -msgid "Advanced Usages" -msgstr "高度な使用方法" - -#: ../../rst/scenario_guides/guide_vagrant.rst:119 -msgid "The \"Tips and Tricks\" chapter of the `Ansible Provisioner documentation `_ provides detailed information about more advanced Ansible features like:" -msgstr "`Ansible Provisioner ドキュメント `_ の「ヒントおよび裏技」の章では、以下のような高度な Ansible 機能に関する詳細情報が提供されています。" - -#: ../../rst/scenario_guides/guide_vagrant.rst:122 -msgid "how to execute a playbook in parallel within a multi-machine environment" -msgstr "マルチマシン環境内で Playbook を並行して実行する方法" - -#: ../../rst/scenario_guides/guide_vagrant.rst:123 -msgid "how to integrate a local ``ansible.cfg`` configuration file" -msgstr "ローカルの ``ansible.cfg`` 設定ファイルを統合する方法" - -#: ../../rst/scenario_guides/guide_vagrant.rst:127 -msgid "`Vagrant Home `_" -msgstr "`Vagrant Home `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:128 -msgid "The Vagrant homepage with downloads" -msgstr "ダウンロードを含む Vagrant ホームページ" - -#: ../../rst/scenario_guides/guide_vagrant.rst:129 -msgid "`Vagrant Documentation `_" -msgstr "`Vagrant Documentation `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:130 -msgid "Vagrant Documentation" -msgstr "Vagrant ドキュメント" - -#: ../../rst/scenario_guides/guide_vagrant.rst:131 -msgid "`Ansible Provisioner `_" -msgstr "`Ansible Provisioner `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:132 -msgid "The Vagrant documentation for the Ansible provisioner" -msgstr "Ansible プロビジョナーの Vagrant ドキュメント" - -#: ../../rst/scenario_guides/guide_vagrant.rst:133 -#, python-format -msgid "`Vagrant Issue Tracker `_" -msgstr "`Vagrant Issue Tracker `_" - -#: ../../rst/scenario_guides/guide_vagrant.rst:134 -msgid "The open issues for the Ansible provisioner in the Vagrant project" -msgstr "Vagrant プロジェクトでの Ansible プロビジョナーに関する未解決な問題" - -#: ../../rst/scenario_guides/guide_vagrant.rst:135 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/scenario_guides/guide_vagrant.rst:136 -msgid "An introduction to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/scenario_guides/guide_vmware_rest.rst:5 -msgid "VMware REST Scenarios" -msgstr "VMware REST シナリオ" - -#: ../../rst/scenario_guides/guide_vmware_rest.rst:7 -msgid "These scenarios teach you how to accomplish common VMware tasks using the REST API and the Ansible ``vmware.vmware_rest`` collection. To get started, please select the task you want to accomplish." -msgstr "これらのシナリオは、REST API と Ansible ``vmware.vmware_rest`` コレクションを使用して一般的な VMware タスクを実現する方法を説明します。開始するには、達成するタスクを選択してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:2 -msgid "Vultr Guide" -msgstr "Vultr ガイド" - -#: ../../rst/scenario_guides/guide_vultr.rst:4 -msgid "Ansible offers a set of modules to interact with `Vultr `_ cloud platform." -msgstr "Ansible は、`Vultr `_ クラウドプラットフォームと対話するためのモジュールセットを提供します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:6 -msgid "This set of module forms a framework that allows one to easily manage and orchestrate one's infrastructure on Vultr cloud platform." -msgstr "このモジュールセットは、Vultr クラウドプラットフォームのインフラストラクチャーを簡単に管理および調整できるようにするフレームワークを形成します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:12 -msgid "There is actually no technical requirement; simply an already created Vultr account." -msgstr "技術的要件はありません。すでに作成されている Vultr アカウントが必要です。" - -#: ../../rst/scenario_guides/guide_vultr.rst:18 -msgid "Vultr modules offer a rather flexible way with regard to configuration." -msgstr "Vultr モジュールは、設定に関してかなり柔軟な方法を提供します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:20 -msgid "Configuration is read in that order:" -msgstr "設定は、以下の順序で読み込まれます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:22 -msgid "Environment Variables (eg. ``VULTR_API_KEY``, ``VULTR_API_TIMEOUT``)" -msgstr "環境変数 (例: ``VULTR_API_KEY``、``VULTR_API_TIMEOUT``)" - -#: ../../rst/scenario_guides/guide_vultr.rst:23 -msgid "File specified by environment variable ``VULTR_API_CONFIG``" -msgstr "環境変数 ``VULTR_API_CONFIG`` で指定されるファイル" - -#: ../../rst/scenario_guides/guide_vultr.rst:24 -msgid "``vultr.ini`` file located in current working directory" -msgstr "現在の作業ディレクトリーにある ``vultr.ini`` ファイル" - -#: ../../rst/scenario_guides/guide_vultr.rst:25 -msgid "``$HOME/.vultr.ini``" -msgstr "``$HOME/.vultr.ini``" - -#: ../../rst/scenario_guides/guide_vultr.rst:28 -msgid "Ini file are structured this way:" -msgstr "ini ファイルは以下のような構成になっています。" - -#: ../../rst/scenario_guides/guide_vultr.rst:41 -msgid "If ``VULTR_API_ACCOUNT`` environment variable or ``api_account`` module parameter is not specified, modules will look for the section named \"default\"." -msgstr "``VULTR_API_ACCOUNT`` 環境変数または ``api_account`` モジュールパラメーターが指定されていない場合、モジュールは「default」という名前のセクションを探します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:47 -msgid "Before using the Ansible modules to interact with Vultr, you need an API key. If you don't yet own one, log in to `Vultr `_ go to Account, then API, enable API then the API key should show up." -msgstr "Ansible モジュールを使用して Vultr と対話する前に、API キーが必要です。まだ API キーを所有していない場合は、`Vultr `_ にログインしてアカウントに移動して API を有効にすると、API キーが表示されるはずです。" - -#: ../../rst/scenario_guides/guide_vultr.rst:50 -msgid "Ensure you allow the usage of the API key from the proper IP addresses." -msgstr "適切な IP アドレスから API キーを使用できるようにします。" - -#: ../../rst/scenario_guides/guide_vultr.rst:52 -msgid "Refer to the Configuration section to find out where to put this information." -msgstr "この情報をどこに置くかは、「構成」セクションを参照してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:54 -msgid "To check that everything is working properly run the following command:" -msgstr "すべてが適切に機能していることを確認するには、次のコマンドを実行します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:76 -msgid "If a similar output displays then everything is setup properly, else please ensure the proper ``VULTR_API_KEY`` has been specified and that Access Controls on Vultr > Account > API page are accurate." -msgstr "同様の出力が表示され、すべての設定が適切に行われた場合は、適切な ``VULTR_API_KEY`` が正しく指定されており、Vultr > Account > API ページのアクセス制御が正確であることを確認してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:80 -msgid "Usage" -msgstr "使用法" - -#: ../../rst/scenario_guides/guide_vultr.rst:82 -msgid "Since `Vultr `_ offers a public API, the execution of the module to manage the infrastructure on their platform will happen on localhost. This translates to:" -msgstr "`Vultr `_ は、パブリック API を提供するため、プラットフォーム上のインフラストラクチャーを管理するためのモジュールの実行はローカルホストで行われます。これは、以下に変換されます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:96 -msgid "From that point on, only your creativity is the limit. Make sure to read the documentation of the `available modules `_." -msgstr "これ以降は、ユーザーの創造性だけが限界となります。`利用可能なモジュール `_ のドキュメントを確認してください。" - -#: ../../rst/scenario_guides/guide_vultr.rst:100 -msgid "Dynamic Inventory" -msgstr "動的インベントリー" - -#: ../../rst/scenario_guides/guide_vultr.rst:102 -msgid "Ansible provides a dynamic inventory plugin for `Vultr `_. The configuration process is exactly the same as for the modules." -msgstr "Ansible は、`Vultr `_ の動的インベントリープラグインを提供します。設定プロセスは、モジュールの場合と同じです。" - -#: ../../rst/scenario_guides/guide_vultr.rst:105 -msgid "To be able to use it you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -msgstr "これを使用できるようにするには、``ansible.cfg`` ファイルで以下を指定して、まず有効にする必要があります。" - -#: ../../rst/scenario_guides/guide_vultr.rst:112 -msgid "And provide a configuration file to be used with the plugin, the minimal configuration file looks like this:" -msgstr "また、プラグインで使用する設定ファイルを提供します。最小設定ファイルは以下のようになります。" - -#: ../../rst/scenario_guides/guide_vultr.rst:119 -msgid "To list the available hosts one can simply run:" -msgstr "利用可能なホストを一覧表示するには、以下を実行します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:126 -msgid "For example, this allows you to take action on nodes grouped by location or OS name:" -msgstr "たとえば、これにより、場所別または OS 名別にグループにまとめたノードでアクションを実行できます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:139 -msgid "Integration tests" -msgstr "統合テスト" - -#: ../../rst/scenario_guides/guide_vultr.rst:141 -msgid "Ansible includes integration tests for all Vultr modules." -msgstr "Ansible には、すべての Vultr モジュールの統合テストが含まれます。" - -#: ../../rst/scenario_guides/guide_vultr.rst:143 -msgid "These tests are meant to run against the public Vultr API and that is why they require a valid key to access the API." -msgstr "これらのテストは、パブリック Vultr API に対して実行されることが意図されています。これが、API にアクセスするために有効な鍵が必要となる理由です。" - -#: ../../rst/scenario_guides/guide_vultr.rst:145 -msgid "Prepare the test setup:" -msgstr "テスト設定を準備します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:152 -msgid "Set the Vultr API key:" -msgstr "Vultr API キーを設定します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:160 -msgid "Run all Vultr tests:" -msgstr "すべての Vultr テストを実行します。" - -#: ../../rst/scenario_guides/guide_vultr.rst:167 -msgid "To run a specific test, for example vultr_account_info:" -msgstr "特定のテスト (例: vultr_account_info) を実行するには、以下を実行します。" - -#: ../../rst/scenario_guides/guides.rst:32 -#: ../../rst/scenario_guides/network_guides.rst:5 -msgid "Network Technology Guides" -msgstr "ネットワークテクノロジーガイド" - -#: ../../rst/scenario_guides/guides.rst:40 -msgid "Virtualization & Containerization Guides" -msgstr "仮想化およびコンテナー化ガイド" - -#: ../../rst/scenario_guides/guides.rst:7 -msgid "Scenario Guides" -msgstr "シナリオガイド" - -#: ../../rst/scenario_guides/guides.rst:9 -msgid "The guides in this section are migrating into collections. Remaining guides may be out of date." -msgstr "本セクションのガイドはコレクションに移行しています。残されたガイドは、情報が古くなっている可能性があります。" - -#: ../../rst/scenario_guides/guides.rst:11 -msgid "These guides cover integrating Ansible with a variety of platforms, products, and technologies. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "これらのガイドでは、Ansible とさまざまなプラットフォーム、製品、およびテクノロジーの統合を説明します。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/guides.rst:13 -msgid "We are migrating these guides into collections. Please update your links for the following guides:" -msgstr "これらのガイドをコレクションに移行しています。以下のガイドのリンクを更新してください。" - -#: ../../rst/scenario_guides/network_guides.rst:7 -msgid "The guides in this section cover using Ansible with specific network technologies. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "本セクションのガイドでは、特定のネットワーク技術を使用した Ansible の使用について説明します。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/network_guides.rst:16 -msgid "To learn more about Network Automation with Ansible, see :ref:`network_getting_started` and :ref:`network_advanced`." -msgstr "Ansible を使用したネットワーク自動化の詳細は、「:ref:`network_getting_started`」および「:ref:`network_advanced`」を参照してください。" - -#: ../../rst/scenario_guides/scenario_template.rst:7 -msgid "Sample scenario for Ansible platforms" -msgstr "Ansible プラットフォームのサンプルシナリオ" - -#: ../../rst/scenario_guides/scenario_template.rst:9 -msgid "*Use this ``rst`` file as a starting point to create a scenario guide for your platform. The sections below are suggestions on what should be in a scenario guide.*" -msgstr "*この ``rst`` ファイルを、お使いのプラットフォームのシナリオガイドを作成するための出発点として使用します。以下のセクションは、シナリオガイドに含まれるべき内容を提案しています。*" - -#: ../../rst/scenario_guides/scenario_template.rst:11 -msgid "Introductory paragraph." -msgstr "概要" - -#: ../../rst/scenario_guides/scenario_template.rst:19 -msgid "Describe the requirements and assumptions for this scenario. This should include applicable subsections for hardware, software, and any other caveats to using the scenarios in this guide." -msgstr "このシナリオの要件および前提条件を説明します。これには、ハードウェア、ソフトウェア、およびその他のシナリオで使用するための適用可能なサブセクションを含める必要があります。" - -#: ../../rst/scenario_guides/scenario_template.rst:24 -msgid "Describe credential requirements and how to authenticate to this platform." -msgstr "認証情報の要件と、このプラットフォームへの認証方法を説明します。" - -#: ../../rst/scenario_guides/scenario_template.rst:27 -msgid "Using dynamic inventory" -msgstr "動的インベントリーの使用" - -#: ../../rst/scenario_guides/scenario_template.rst:29 -msgid "If applicable, describe how to use a dynamic inventory plugin for this platform." -msgstr "該当する場合は、このプラットフォームで動的インベントリープラグインを使用する方法を記述します。" - -#: ../../rst/scenario_guides/scenario_template.rst:33 -msgid "Example description" -msgstr "例の説明" - -#: ../../rst/scenario_guides/scenario_template.rst:35 -msgid "Description and code here. Change the section header to something descriptive about this example, such as \"Renaming a virtual machine\". The goal is that this is the text someone would search for to find your example." -msgstr "ここには説明とコードが含まれます。セクションヘッダーを、「Renaming a virtual machine (仮想マシンの名前変更)」など、このサンプルを説明するものに変更します。これは、作成した例を他の誰かが検索する際に使用するテキストになります。" - -#: ../../rst/scenario_guides/scenario_template.rst:39 -msgid "Example output" -msgstr "出力例" - -#: ../../rst/scenario_guides/scenario_template.rst:41 -msgid "What the user should expect to see." -msgstr "期待される結果。" - -#: ../../rst/scenario_guides/scenario_template.rst:45 -msgid "Troubleshooting" -msgstr "トラブルシューティング" - -#: ../../rst/scenario_guides/scenario_template.rst:47 -msgid "What to look for if it breaks." -msgstr "壊れたときの注意点・" - -#: ../../rst/scenario_guides/scenario_template.rst:51 -msgid "Conclusion and where to go next" -msgstr "結論および次のステップ" - -#: ../../rst/scenario_guides/scenario_template.rst:53 -msgid "Recap of important points. For more information please see: links." -msgstr "重要なポイントの要約。詳細は、リンクを参照してください。" - -#: ../../rst/scenario_guides/virt_guides.rst:5 -msgid "Virtualization and Containerization Guides" -msgstr "仮想化およびコンテナー化ガイド" - -#: ../../rst/scenario_guides/virt_guides.rst:7 -msgid "The guides in this section cover integrating Ansible with popular tools for creating virtual machines and containers. They explore particular use cases in greater depth and provide a more \"top-down\" explanation of some basic features." -msgstr "このセクションのガイドでは、仮想マシンやコンテナーを作成する一般的なツールと Ansible の統合を説明しています。特定のユースケースをより深く掘り下げ、いくつかの基本的な機能を「トップダウン」で説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:5 -msgid "How to configure the vmware_rest collection" -msgstr "vmware_rest コレクションの設定方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:14 -msgid "The vcenter_rest modules need to be authenticated. There are two different" -msgstr "vcenter_rest モジュールを認証する必要があります。2 つの異なるモジュールがあります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:17 -msgid "Environment variables" -msgstr "環境変数" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:20 -msgid "This solution requires that you call the modules from the local machine." -msgstr "このソリューションでは、ローカルマシンからモジュールを呼び出す必要があります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:22 -msgid "You need to export some environment variables in your shell before you call the modules." -msgstr "モジュールを呼び出す前に、シェルで環境変数の一部をエクスポートする必要があります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:32 -msgid "Module parameters" -msgstr "モジュールパラメーター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:34 -msgid "All the vcenter_rest modules accept the following arguments:" -msgstr "すべての vcenter_rest モジュールは、以下の引数を受け入れます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:36 -msgid "``vcenter_hostname``" -msgstr "``vcenter_hostname``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:37 -msgid "``vcenter_username``" -msgstr "``vcenter_username``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:38 -msgid "``vcenter_password``" -msgstr "``vcenter_password``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:42 -msgid "Ignore SSL certificate error" -msgstr "SSL 証明書エラーを無視します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:44 -msgid "It's common to run a test environment without a proper SSL certificate configuration." -msgstr "適切な SSL 証明書設定なしでテスト環境を実行することが一般的です。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/authentication.rst:46 -msgid "To ignore the SSL error, you can use the ``vcenter_validate_certs: no`` argument or ``export VMWARE_VALIDATE_CERTS=no`` to set the environment variable." -msgstr "SSL エラーを無視するには、``vcenter_validate_certs: no`` 引数または ``export VMWARE_VALIDATE_CERTS=no`` を使用して環境変数を設定します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:5 -msgid "How to collect information about your environment" -msgstr "環境に関する情報を収集する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:14 -msgid "This section shows you how to utilize Ansible to collect information about your environment. This information is useful for the other tutorials." -msgstr "本セクションでは、Ansible を使用してお使いの環境に関する情報を収集する方法を説明します。この情報は、他のチュートリアルに役立ちます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:18 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:17 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:17 -msgid "Scenario requirements" -msgstr "シナリオの要件" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:20 -msgid "In this scenario we've got a vCenter with an ESXi host." -msgstr "このシナリオでは、ESXi ホストを搭載する vCenter があります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:22 -msgid "Our environment is pre-initialized with the following elements:" -msgstr "お使いの環境は、以下の要素で事前に初期化されています。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:24 -msgid "A datacenter called ``my_dc``" -msgstr "``my_dc`` という名前のデータセンター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:25 -msgid "A cluster called ``my_cluster``" -msgstr "``my_cluster`` という名前のクラスター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:26 -msgid "An ESXi host called ``esxi1`` is in the cluster" -msgstr "``esxi1`` という名前の ESXi ホストがクラスター内にあります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:27 -msgid "Two datastores on the ESXi: ``rw_datastore`` and ``ro_datastore``" -msgstr "ESXi 上の 2 つのデータストア: ``rw_datastore`` および ``ro_datastore``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:28 -msgid "A dvswitch based guest network" -msgstr "dvswitch ベースのゲストネットワーク" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:30 -msgid "Finally, we use the environment variables to authenticate ourselves as explained in :ref:`vmware_rest_authentication`." -msgstr "最後に、「:ref:`vmware_rest_authentication`」で説明されているように、環境変数を使用して認証を行います。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:33 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:22 -msgid "How to collect information" -msgstr "情報の収集方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:35 -msgid "In these examples, we use the ``vcenter_*_info`` module to collect information about the associated resources." -msgstr "これらの例では、``vcenter_*_info`` モジュールを使用して、関連付けられたリソースに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:37 -msgid "All these modules return a ``value`` key. Depending on the context, this ``value`` key will be either a list or a dictionary." -msgstr "これらのモジュールはすべて ``value`` キーを返します。コンテキストに応じて、この ``value`` キーはリストまたはディクショナリーのいずれかになります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:40 -msgid "Datacenter" -msgstr "データセンター" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:42 -msgid "Here we use the ``vcenter_datacenter_info`` module to list all the datacenters:" -msgstr "ここでは、``vcenter_datacenter_info`` モジュールを使用して、すべてのデータセンターを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:47 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:61 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:70 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:85 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:97 -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:106 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:24 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:37 -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:50 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:46 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:66 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:76 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:88 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:100 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:112 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:124 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:136 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:148 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:34 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:48 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:65 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:79 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:91 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:103 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:115 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:127 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:32 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:43 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:37 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:49 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:61 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:75 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:87 -msgid "Result" -msgstr "結果" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:49 -msgid "As expected, the ``value`` key of the output is a list." -msgstr "想定どおりに、出力の ``value`` キーはリストになります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:54 -msgid "Cluster" -msgstr "Cluster" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:56 -msgid "Here we do the same with ``vcenter_cluster_info``:" -msgstr "ここでは、``vcenter_cluster_info`` でも同じことを行います。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:65 -msgid "And we can also fetch the details about a specific cluster, with the ``cluster`` parameter:" -msgstr "また、``cluster`` パラメーターを使用して、特定のクラスターの詳細を取得することもできます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:72 -msgid "And the ``value`` key of the output is this time a dictionary." -msgstr "また、出力の ``value`` キーは、今回ディクショナリーです。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:78 -msgid "Datastore" -msgstr "データストア" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:80 -msgid "Here we use ``vcenter_datastore_info`` to get a list of all the datastores:" -msgstr "ここでは、``vcenter_datastore_info`` を使用してすべてのデータストアの一覧を取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:90 -msgid "Folder" -msgstr "フォルダー" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:92 -msgid "And here again, you use the ``vcenter_folder_info`` module to retrieve a list of all the folders." -msgstr "また、ここでは ``vcenter_folder_info`` モジュールを使用してすべてのフォルダーの一覧を取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/collect_information.rst:101 -msgid "Most of the time, you will just want one type of folder. In this case we can use filters to reduce the amount to collect. Most of the ``_info`` modules come with similar filters." -msgstr "多くの場合は、1 種類のディレクトリーが必要です。この場合は、フィルターを使用して収集する量を減らすことができます。ほとんどの ``_info`` モジュールには同様のフィルターが含まれます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:5 -msgid "How to create a Virtual Machine" -msgstr "仮想マシンの作成方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:14 -msgid "This section shows you how to use Ansible to create a virtual machine." -msgstr "本セクションでは、Ansible を使用して仮想マシンを作成する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:19 -msgid "You've already followed :ref:`vmware_rest_collect_info` and you've got the following variables defined:" -msgstr "すでに :ref:`vmware_rest_collect_info` に従い、以下の変数が定義済みである。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:21 -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:24 -msgid "``my_cluster_info``" -msgstr "``my_cluster_info``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:22 -msgid "``my_datastore``" -msgstr "``my_datastore``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:23 -msgid "``my_virtual_machine_folder``" -msgstr "``my_virtual_machine_folder``" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:27 -msgid "How to create a virtual machine" -msgstr "仮想マシンの作成方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:29 -msgid "In this example, we will use the ``vcenter_vm`` module to create a new guest." -msgstr "この例では、``vcenter_vm`` モジュールを使用して新規ゲストを作成します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/create_vm.rst:39 -msgid "``vcenter_vm`` accepts more parameters, however you may prefer to start with a simple VM and use the ``vcenter_vm_hardware`` modules to tune it up afterwards. It's easier this way to identify a potential problematical step." -msgstr "``vcenter_vm`` は、より多くのパラメーターを受け入れることができますが、単純な仮想マシンで開始し、後で ``vcenter_vm_hardware`` モジュールを使用して調整したい場合があります。これにより、問題のあるステップを特定するのが容易になります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:5 -msgid "How to install the vmware_rest collection" -msgstr "vmware_rest コレクションをインストールする方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:14 -msgid "The collection depends on:" -msgstr "コレクションは、以下の条件で使用します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:16 -msgid "Ansible >=2.9.10 or greater" -msgstr "2.9.10 以降の Ansible" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:17 -msgid "Python 3.6 or greater" -msgstr "Python 3.6 以降" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:20 -msgid "aiohttp" -msgstr "aiohttp" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:22 -msgid "aiohttp_ is the only dependency of the collection. You can install it with ``pip`` if you use a virtualenv to run Ansible." -msgstr "aiohttp_ はコレクションの唯一の依存関係です。virtualenv を使用して Ansible を実行する場合は ``pip`` でインストールできます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:28 -msgid "Or using an RPM." -msgstr "または RPM を使用します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/installation.rst:39 -msgid "The best option to install the collection is to use the ``ansible-galaxy`` command:" -msgstr "コレクションをインストールする場合は、``ansible-galaxy`` コマンドを使用するのが最適です。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:5 -msgid "How to run a virtual machine" -msgstr "仮想マシンの実行方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:14 -msgid "This section covers the power management of your virtual machine." -msgstr "本セクションでは、仮想マシンの電源管理を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:17 -msgid "Power information" -msgstr "電源情報" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:19 -msgid "Use ``vcenter_vm_power_info`` to know the power state of the VM." -msgstr "``vcenter_vm_power_info`` を使用して、仮想マシンの電源状態を確認します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:30 -msgid "How to start a virtual machine" -msgstr "仮想マシンの起動方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:32 -msgid "Use the ``vcenter_vm_power`` module to start your VM:" -msgstr "``vcenter_vm_power`` モジュールを使用して仮想マシンを起動します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:42 -msgid "How to wait until my virtual machine is ready" -msgstr "仮想マシンの準備ができるまで待機する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst:44 -msgid "If your virtual machine runs VMware Tools, you can build a loop around the ``center_vm_tools_info`` module:" -msgstr "仮想マシンが VMware Tool を実行している場合は、``center_vm_tools_info`` モジュールを中心にループを構築できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:5 -msgid "How to modify a virtual machine" -msgstr "仮想マシンの変更方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:14 -msgid "This section shows you how to use Ansible to modify an existing virtual machine." -msgstr "本セクションでは、Ansible を使用して既存の仮想マシンを変更する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:19 -msgid "You've already followed :ref:`vmware_rest_create_vm` and created a VM." -msgstr "すでに :ref:`vmware_rest_create_vm` に従い、仮想マシンを作成している。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:22 -msgid "How to add a CDROM drive to a virtual machine" -msgstr "CDROM ドライブを仮想マシンに追加する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:24 -msgid "In this example, we use the ``vcenter_vm_hardware_*`` modules to add a new CDROM to an existing VM." -msgstr "この例では、``vcenter_vm_hardware_*`` モジュールを使用して、新しい CDROM を既存の仮想マシンに追加します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:27 -msgid "Add a new SATA adapter" -msgstr "新しい SATA アダプターの追加" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:29 -msgid "First we create a new SATA adapter. We specify the ``pci_slot_number``. This way if we run the task again it won't do anything if there is already an adapter there." -msgstr "最初に新しい SATA アダプターを作成します。``pci_slot_number`` を指定します。これにより、タスクを再度実行する場合は、アダプターがすでに存在していても何も実行されません。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:39 -msgid "Add a CDROM drive" -msgstr "CDROM ドライブの追加" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:41 -msgid "Now we can create the CDROM drive:" -msgstr "これで CDROM ドライブを作成できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:54 -msgid "How to attach a VM to a network" -msgstr "仮想マシンをネットワークに割り当てる方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:57 -msgid "Attach a new NIC" -msgstr "新規 NIC の割り当て" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:59 -msgid "Here we attach the VM to the network (through the portgroup). We specify a ``pci_slot_number`` for the same reason." -msgstr "ここでは、(portgroup から) 仮想マシンをネットワークに接続します。同様に ``pci_slot_number`` を指定します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:61 -msgid "The second task adjusts the NIC configuration." -msgstr "2 つ目のタスクは、NIC 設定を調整します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:71 -msgid "Adjust the configuration of the NIC" -msgstr "NIC の設定の調整" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:81 -msgid "Increase the memory of the VM" -msgstr "仮想マシンのメモリーの増加" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:83 -msgid "We can also adjust the amount of memory that we dedicate to our VM." -msgstr "また、仮想マシンに割り当てるメモリー容量を調整することもできます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:93 -msgid "Upgrade the hardware version of the VM" -msgstr "仮想マシンのハードウェアバージョンをアップグレードします。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:95 -msgid "Here we use the ``vcenter_vm_hardware`` module to upgrade the version of the hardware:" -msgstr "ここでは、``vcenter_vm_hardware`` モジュールを使用してハードウェアのバージョンをアップグレードします。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:105 -msgid "Adjust the number of CPUs of the VM" -msgstr "仮想マシンの CPU 数を調整する" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:107 -msgid "You can use ``vcenter_vm_hardware_cpu`` for that:" -msgstr "そのためには、``vcenter_vm_hardware_cpu`` を使用できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:117 -msgid "Remove a SATA controller" -msgstr "SATA コントローラーの削除" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:119 -msgid "In this example, we remove the SATA controller of the PCI slot 34." -msgstr "この例では、PCI スロット 34 の SATA コントローラーを削除します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:129 -msgid "Attach a floppy drive" -msgstr "フロッピードライブの接続" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:131 -msgid "Here we attach a floppy drive to a VM." -msgstr "ここでは、フロッピードライブを仮想マシンに割り当てます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:141 -msgid "Attach a new disk" -msgstr "新規ディスクの割り当て" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst:143 -msgid "Here we attach a tiny disk to the VM. The ``capacity`` is in bytes." -msgstr "ここでは、仮想マシンに小規模なディスクを割り当てます。``capacity`` はバイト単位です。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:5 -msgid "Retrieve information from a specific VM" -msgstr "特定の仮想マシンからの情報の取得" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:14 -msgid "This section shows you how to use Ansible to retrieve information about a specific virtual machine." -msgstr "本セクションでは、Ansible を使用して特定の仮想マシンに関する情報を取得する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:19 -msgid "You've already followed :ref:`vmware_rest_create_vm` and you've got create a new VM called ``test_vm1``." -msgstr "すでに :ref:`vmware_rest_create_vm` に従い、``test_vm1`` という名前の新しい仮想マシンを作成している。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:22 -msgid "How to collect virtual machine information" -msgstr "仮想マシン情報を収集する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:25 -msgid "List the VM" -msgstr "仮想マシンの一覧表示" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:27 -msgid "In this example, we use the ``vcenter_vm_info`` module to collect information about our new VM." -msgstr "この例では、``vcenter_vm_info`` モジュールを使用して、新しい仮想マシンに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:29 -msgid "In this example, we start by asking for a list of VMs. We use a filter to limit the results to just the VM called ``test_vm1``. So we are in a list context, with one single entry in the ``value`` key." -msgstr "この例では、仮想マシンの一覧を求めることから開始します。結果は、``test_vm1`` と呼ばれる仮想マシンに制限します。そのため、``value`` キーには 1 つのエントリーがあります。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:36 -msgid "As expected, we get a list. And thanks to our filter, we just get one entry." -msgstr "予想通り、リストが表示されます。そして、フィルターのおかげで、エントリーを 1 だけつ得ることができました。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:41 -msgid "Collect the details about a specific VM" -msgstr "特定の仮想マシンに関する詳細の収集" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:43 -msgid "For the next steps, we pass the ID of the VM through the ``vm`` parameter. This allow us to collect more details about this specific VM." -msgstr "次のステップでは、``vm`` パラメーターを使用して仮想マシンの ID を渡します。これにより、この特定の仮想マシンに関する詳細を収集できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:50 -msgid "The result is a structure with all the details about our VM. You will note this is actually the same information that we get when we created the VM." -msgstr "結果は、仮想マシンに関する詳細がすべて記載されている構造です。これは、仮想マシンの作成時に得られる情報と同じです。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:56 -msgid "Get the hardware version of a specific VM" -msgstr "特定の仮想マシンのハードウェアバージョンの取得" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:58 -msgid "We can also use all the ``vcenter_vm_*_info`` modules to retrieve a smaller amount of information. Here we use ``vcenter_vm_hardware_info`` to know the hardware version of the VM." -msgstr "すべての ``vcenter_vm_*_info`` モジュールを使用して、より詳細な情報を取得することもできます。ここでは、``vcenter_vm_hardware_info`` を使用して仮想マシンのハードウェアバージョンを把握します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:70 -msgid "List the SCSI adapter(s) of a specific VM" -msgstr "特定の仮想マシンの SCSI アダプターを一覧表示する" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:72 -msgid "Here for instance, we list the SCSI adapter(s) of the VM:" -msgstr "たとえば、仮想マシンの SCSI アダプターを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:76 -msgid "You can do the same for the SATA controllers with ``vcenter_vm_adapter_sata_info``." -msgstr "``vcenter_vm_adapter_sata_info`` を使用して SATA コントローラーで同じ操作を行うことができます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:84 -msgid "List the CDROM drive(s) of a specific VM" -msgstr "特定の仮想マシンの CDROM ドライブを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:86 -msgid "And we list its CDROM drives." -msgstr "その CDROM ドライブを一覧表示します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:96 -msgid "Get the memory information of the VM" -msgstr "仮想マシンのメモリー情報を取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:98 -msgid "Here we collect the memory information of the VM:" -msgstr "ここでは、仮想マシンのメモリー情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:108 -msgid "Get the storage policy of the VM" -msgstr "仮想マシンのストレージポリシーを取得します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:110 -msgid "We use the ``vcenter_vm_storage_policy_info`` module for that:" -msgstr "そのために ``vcenter_vm_storage_policy_info`` モジュールを使用しています。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:120 -msgid "Get the disk information of the VM" -msgstr "仮想マシンのディスク情報の取得" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_info.rst:122 -msgid "We use the ``vcenter_vm_hardware_disk_info`` for this operation:" -msgstr "この操作には ``vcenter_vm_hardware_disk_info`` を使用します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:5 -msgid "How to configure the VMware tools of a running virtual machine" -msgstr "実行中の仮想マシンの VMware ツールを設定する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:14 -msgid "This section show you how to collection information from a running virtual machine." -msgstr "本セクションでは、実行中の仮想マシンから情報を取得する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:19 -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:19 -msgid "You've already followed :ref:`vmware_rest_run_a_vm` and your virtual machine runs VMware Tools." -msgstr "すでに :ref:`vmware_rest_run_a_vm` に従い、仮想マシンが VMware ツールを実行している。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:22 -msgid "How to change the upgrade policy" -msgstr "アップグレードポリシーを変更する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:25 -msgid "Change the upgrade policy to MANUAL" -msgstr "アップグレードポリシーを MANUAL に変更" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:27 -msgid "You can adjust the VMware Tools upgrade policy with the ``vcenter_vm_tools`` module." -msgstr "``vcenter_vm_tools`` モジュールで VMware Tools アップグレードポリシーを調整することができます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst:38 -msgid "Change the upgrade policy to UPGRADE_AT_POWER_CYCLE" -msgstr "アップグレードポリシーを UPGRADE_AT_POWER_CYCLE に変更" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:5 -msgid "How to get information from a running virtual machine" -msgstr "実行中の仮想マシンから情報を取得する方法" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:14 -msgid "This section shows you how to collection information from a running virtual machine." -msgstr "このセクションでは、実行中の仮想マシンから情報を取得する方法を説明します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:24 -msgid "In this example, we use the ``vcenter_vm_guest_*`` module to collect information about the associated resources." -msgstr "この例では、``vcenter_vm_guest_*`` モジュールを使用して、関連付けられたリソースに関する情報を収集します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:27 -msgid "Filesystem" -msgstr "ファイルシステム" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:29 -msgid "Here we use ``vcenter_vm_guest_localfilesystem_info`` to retrieve the details about the filesystem of the guest. In this example we also use a ``retries`` loop. The VMware Tools may take a bit of time to start and by doing so, we give the VM a bit more time." -msgstr "この例では、``vcenter_vm_guest_localfilesystem_info`` を使用してゲストのファイルシステムの詳細を取得します。この例では、``retries`` ループも使用します。VMware Tool の開始には少し時間がかかる場合がありますが、このようにすることで仮想マシンに少し時間に余裕ができます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:42 -msgid "Guest identity" -msgstr "ゲスト ID" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:44 -msgid "You can use ``vcenter_vm_guest_identity_info`` to get details like the OS family or the hostname of the running VM." -msgstr "``vcenter_vm_guest_identity_info`` を使用すると、OS ファミリーや実行中の仮想マシンのホスト名などの詳細を取得できます。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:54 -msgid "Network" -msgstr "ネットワーク" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:56 -msgid "``vcenter_vm_guest_networking_info`` will return the OS network configuration." -msgstr "``vcenter_vm_guest_networking_info`` は、OS のネットワーク設定を返します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:66 -msgid "Network interfaces" -msgstr "ネットワークインターフェース" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:68 -msgid "``vcenter_vm_guest_networking_interfaces_info`` will return a list of NIC configurations." -msgstr "``vcenter_vm_guest_networking_interfaces_info`` は、NC 設定の一覧を返します。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:70 -msgid "See also :ref:`vmware_rest_attach_a_network`." -msgstr "「:ref:`vmware_rest_attach_a_network`」も参照してください。" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:80 -msgid "Network routes" -msgstr "ネットワークルート" - -#: ../../rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst:82 -msgid "Use ``vcenter_vm_guest_networking_routes_info`` to explore the route table of your virtual machine." -msgstr "仮想マシンのルートテーブルを確認するには、``vcenter_vm_guest_networking_routes_info`` を使用します。" - -#~ msgid "To use an Azure Cloud other than the default public cloud (eg, Azure China Cloud, Azure US Government Cloud, Azure Stack), pass the \"cloud_environment\" argument to modules, configure it in a credential profile, or set the \"AZURE_CLOUD_ENVIRONMENT\" environment variable. The value is either a cloud name as defined by the Azure Python SDK (eg, \"AzureChinaCloud\", \"AzureUSGovernment\"; defaults to \"AzureCloud\") or an Azure metadata discovery URL (for Azure Stack)." -#~ msgstr "" - -#~ msgid "An Azure module is available to help you create a storage account, virtual network, subnet, network interface, security group and public IP. Here is a full example of creating each of these and passing the names to the azure_rm_virtualmachine module at the end:" -#~ msgstr "" - -#~ msgid "When creating a VM with the ``azure_rm_virtualmachine`` module, you need to explicitly set the ``managed_disk_type`` parameter to change the OS disk to a managed disk. Otherwise, the OS disk becomes an unmanaged disk.." -#~ msgstr "" - -#~ msgid "When you create a data disk with the ``azure_rm_manageddisk`` module, you need to explicitly specify the ``storage_account_type`` parameter to make it a managed disk. Otherwise, the data disk will be an unmanaged disk." -#~ msgstr "" - -#~ msgid "A managed disk does not require a storage account or a storage container, unlike a n unmanaged disk. In particular, note that once a VM is created on an unmanaged disk, an unnecessary storage container named \"vhds\" is automatically created." -#~ msgstr "" - -#~ msgid "When you create an IP address with the ``azure_rm_publicipaddress`` module, you must set the ``sku`` parameter to ``standard``. Otherwise, the IP address cannot be used in an availability zone." -#~ msgstr "" - -#~ msgid "cs also includes a command line interface for ad-hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``." -#~ msgstr "" - -#~ msgid "Ansible offers the following modules for orchestrating Docker containers:" -#~ msgstr "" - -#~ msgid "docker_compose" -#~ msgstr "" - -#~ msgid "Use your existing Docker compose files to orchestrate containers on a single Docker daemon or on Swarm. Supports compose versions 1 and 2." -#~ msgstr "" - -#~ msgid "docker_container" -#~ msgstr "" - -#~ msgid "Manages the container lifecycle by providing the ability to create, update, stop, start and destroy a container." -#~ msgstr "" - -#~ msgid "docker_image" -#~ msgstr "" - -#~ msgid "Provides full control over images, including: build, pull, push, tag and remove." -#~ msgstr "" - -#~ msgid "docker_image_info" -#~ msgstr "" - -#~ msgid "Inspects one or more images in the Docker host's image cache, providing the information for making decision or assertions in a playbook." -#~ msgstr "" - -#~ msgid "docker_login" -#~ msgstr "" - -#~ msgid "Authenticates with Docker Hub or any Docker registry and updates the Docker Engine config file, which in turn provides password-free pushing and pulling of images to and from the registry." -#~ msgstr "" - -#~ msgid "docker (dynamic inventory)" -#~ msgstr "" - -#~ msgid "Dynamically builds an inventory of all the available containers from a set of one or more Docker hosts." -#~ msgstr "" - -#~ msgid "Ansible 2.1.0 includes major updates to the Docker modules, marking the start of a project to create a complete and integrated set of tools for orchestrating containers. In addition to the above modules, we are also working on the following:" -#~ msgstr "" - -#~ msgid "There's more planned. See the latest ideas and thinking at the `Ansible proposal repo `_." -#~ msgstr "" - -#~ msgid "Using the docker modules requires having the `Docker SDK for Python `_ installed on the host running Ansible. You will need to have >= 1.7.0 installed. For Python 2.7 or Python 3, you can install it as follows:" -#~ msgstr "" - -#~ msgid "Please note that only one of ``docker`` and ``docker-py`` must be installed. Installing both will result in a broken installation. If this happens, Ansible will detect it and inform you about it::" -#~ msgstr "" - -#~ msgid "The docker_compose module also requires `docker-compose `_" -#~ msgstr "" - -#~ msgid "You can connect to a local or remote API using parameters passed to each task or by setting environment variables. The order of precedence is command line parameters and then environment variables. If neither a command line option or an environment variable is found, a default value will be used. The default values are provided under `Parameters`_" -#~ msgstr "" - -#~ msgid "Control how modules connect to the Docker API by passing the following parameters:" -#~ msgstr "" - -#~ msgid "The URL or Unix socket path used to connect to the Docker API. Defaults to ``unix://var/run/docker.sock``. To connect to a remote host, provide the TCP connection string. For example: ``tcp://192.0.2.23:2376``. If TLS is used to encrypt the connection to the API, then the module will automatically replace 'tcp' in the connection URL with 'https'." -#~ msgstr "" - -#~ msgid "Secure the connection to the API by using TLS without verifying the authenticity of the Docker host server. Defaults to False." -#~ msgstr "" - -#~ msgid "tls_verify" -#~ msgstr "" - -#~ msgid "Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server. Default is False." -#~ msgstr "" - -#~ msgid "When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults to 'localhost'." -#~ msgstr "" - -#~ msgid "Provide a valid SSL version number. Default value determined by docker-py, which at the time of this writing was 1.0" -#~ msgstr "" - -#~ msgid "Control how the modules connect to the Docker API by setting the following variables in the environment of the host running Ansible:" -#~ msgstr "" - -#~ msgid "The inventory script generates dynamic inventory by making API requests to one or more Docker APIs. It's dynamic because the inventory is generated at run-time rather than being read from a static file. The script generates the inventory by connecting to one or many Docker APIs and inspecting the containers it finds at each API. Which APIs the script contacts can be defined using environment variables or a configuration file." -#~ msgstr "" - -#~ msgid "Groups" -#~ msgstr "" - -#~ msgid "The script will create the following host groups:" -#~ msgstr "" - -#~ msgid "container id" -#~ msgstr "" - -#~ msgid "container name" -#~ msgstr "" - -#~ msgid "container short id" -#~ msgstr "" - -#~ msgid "image_name (image_)" -#~ msgstr "" - -#~ msgid "running" -#~ msgstr "" - -#~ msgid "stopped" -#~ msgstr "" - -#~ msgid "You can run the script interactively from the command line or pass it as the inventory to a playbook. Here are few examples to get you started:" -#~ msgstr "" - -#~ msgid "You can control the behavior of the inventory script by defining environment variables, or creating a docker.yml file (sample provided in https://raw.githubusercontent.com/ansible-collections/community.general/main/scripts/inventory/docker.py). The order of precedence is the docker.yml file and then environment variables." -#~ msgstr "" - -#~ msgid "To connect to a single Docker API the following variables can be defined in the environment to control the connection options. These are the same environment variables used by the Docker modules." -#~ msgstr "" - -#~ msgid "The URL or Unix socket path used to connect to the Docker API. Defaults to unix://var/run/docker.sock." -#~ msgstr "" - -#~ msgid "DOCKER_API_VERSION:" -#~ msgstr "" - -#~ msgid "DOCKER_TIMEOUT:" -#~ msgstr "" - -#~ msgid "DOCKER_TLS:" -#~ msgstr "" - -#~ msgid "DOCKER_TLS_VERIFY:" -#~ msgstr "" - -#~ msgid "Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server. Default is False" -#~ msgstr "" - -#~ msgid "DOCKER_TLS_HOSTNAME:" -#~ msgstr "" - -#~ msgid "When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults to localhost." -#~ msgstr "" - -#~ msgid "DOCKER_CERT_PATH:" -#~ msgstr "" - -#~ msgid "DOCKER_SSL_VERSION:" -#~ msgstr "" - -#~ msgid "In addition to the connection variables there are a couple variables used to control the execution and output of the script:" -#~ msgstr "" - -#~ msgid "DOCKER_CONFIG_FILE" -#~ msgstr "" - -#~ msgid "Path to the configuration file. Defaults to ./docker.yml." -#~ msgstr "" - -#~ msgid "DOCKER_PRIVATE_SSH_PORT:" -#~ msgstr "" - -#~ msgid "The private port (container port) on which SSH is listening for connections. Defaults to 22." -#~ msgstr "" - -#~ msgid "DOCKER_DEFAULT_IP:" -#~ msgstr "" - -#~ msgid "The IP address to assign to ansible_host when the container's SSH port is mapped to interface '0.0.0.0'." -#~ msgstr "" - -#~ msgid "Configuration File" -#~ msgstr "" - -#~ msgid "Using a configuration file provides a means for defining a set of Docker APIs from which to build an inventory." -#~ msgstr "" - -#~ msgid "The default name of the file is derived from the name of the inventory script. By default the script will look for basename of the script (in other words, docker) with an extension of '.yml'." -#~ msgstr "" - -#~ msgid "You can also override the default name of the script by defining DOCKER_CONFIG_FILE in the environment." -#~ msgstr "" - -#~ msgid "Here's what you can define in docker_inventory.yml:" -#~ msgstr "" - -#~ msgid "defaults" -#~ msgstr "" - -#~ msgid "Defines a default connection. Defaults will be taken from this and applied to any values not provided for a host defined in the hosts list." -#~ msgstr "" - -#~ msgid "hosts" -#~ msgstr "" - -#~ msgid "If you wish to get inventory from more than one Docker host, define a hosts list." -#~ msgstr "" - -#~ msgid "For the default host and each host in the hosts list define the following attributes:" -#~ msgstr "" - -#~ msgid "Here is a basic example of provisioning an instance in ad-hoc mode:" -#~ msgstr "" - -#~ msgid "`#ansible-network `_" -#~ msgstr "`#ansible-network `_" - -#~ msgid "The #ansible-network IRC chat channel on Freenode.net." -#~ msgstr "Freenode.net の IRC チャットチャンネル (#ansible-network)" - -#~ msgid "Ansible contains a number of modules for controlling Amazon Web Services (AWS). The purpose of this section is to explain how to put Ansible modules together (and use inventory scripts) to use Ansible in AWS context." -#~ msgstr "Ansible には、Amazon Web Services (AWS) を制御するモジュールが多数含まれています。このセクションの目的は、AWS のコンテキストで Ansible を使用するために、Ansible モジュールをどのように組み合わせるか (インベントリースクリプトを使用するか) を説明することです。" - -#~ msgid "Requirements for the AWS modules are minimal." -#~ msgstr "AWS モジュールの要件は最小限です。" - -#~ msgid "All of the modules require and are tested against recent versions of boto, usually boto3. Check the module documentation for the minimum required version for each module. You must have the boto3 Python module installed on your control machine. You may also need the original boto package. You can install these modules from your OS distribution or using the python package installer: ``pip install boto3``." -#~ msgstr "モジュールはすべて必要で、最新バージョンの boto、通常は boto3 に対してテストされています。各モジュールに必要な最小バージョンについては、そのモジュールのドキュメントを確認します。boto3 の Python モジュールをコントロールマシンにインストールする必要があります。元の boto パッケージもインストールする必要があります。これらのモジュールは、OS のディストリビューションからインストールするか、Python パッケージインストーラー ``pip install boto3`` を使用してインストールすることができます。" - -#~ msgid "Whereas classically Ansible will execute tasks in its host loop against multiple remote machines, most cloud-control steps occur on your local machine with reference to the regions to control." -#~ msgstr "従来、Ansible はホストループ内のタスクを複数のリモートマシンに対して実行しますが、ほとんどのクラウド制御手順は、制御するリージョンを参照するローカルマシンで実行します。" - -#~ msgid "In your playbook steps we'll typically be using the following pattern for provisioning steps::" -#~ msgstr "Playbook の手順では、通常、プロビジョニング手順に以下のパターンを使用します::" - -#~ msgid "Authentication with the AWS-related modules is handled by either specifying your access and secret key as ENV variables or module arguments." -#~ msgstr "AWS 関連のモジュールを使用した認証は、ENV 変数またはモジュール引数としてアクセスおよび秘密鍵を指定することにより処理されます。" - -#~ msgid "For environment variables::" -#~ msgstr "環境変数の場合::" - -#~ msgid "For storing these in a vars_file, ideally encrypted with ansible-vault::" -#~ msgstr "vars_file に保存するには、ansible-vault で暗号化することが理想的です::" - -#~ msgid "Note that if you store your credentials in vars_file, you need to refer to them in each AWS-module. For example::" -#~ msgstr "認証情報を vars_file に保存する場合は、各 AWS モジュールで認証情報を参照する必要があることに注意してください。以下に例を示します。" - -#~ msgid "The ec2 module provisions and de-provisions instances within EC2." -#~ msgstr "ec2 モジュールは、EC2 内でインスタンスのプロビジョニングおよびプロビジョニング解除を行います。" - -#~ msgid "An example of making sure there are only 5 instances tagged 'Demo' in EC2 follows." -#~ msgstr "EC2 で「Demo」とタグ付けされたインスタンスが 5 個になるようにする例を以下に示します。" - -#~ msgid "In the example below, the \"exact_count\" of instances is set to 5. This means if there are 0 instances already existing, then 5 new instances would be created. If there were 2 instances, only 3 would be created, and if there were 8 instances, 3 instances would be terminated." -#~ msgstr "以下の例では、インスタンスの「exact_count」は 5 に設定されます。これは、インスタンスがない場合は、新規インスタンスが 5 個作成されることを示しています。インスタンスが 2 個ある場合は、3 個作成され、インスタンスが 8 個ある場合は、3 個のインスタンスが終了します。" - -#~ msgid "What is being counted is specified by the \"count_tag\" parameter. The parameter \"instance_tags\" is used to apply tags to the newly created instance.::" -#~ msgstr "カウントされるものは「count_tag」パラメーターで指定します。「instance_tags」パラメーターは、新たに作成されたインスタンスをタグに適用するために使用されます。" - -#~ msgid "The data about what instances are created is being saved by the \"register\" keyword in the variable named \"ec2\"." -#~ msgstr "作成されるインスタンスに関するデータは、「ec2」という変数の「register」キーワードによって保存されます。" - -#~ msgid "From this, we'll use the add_host module to dynamically create a host group consisting of these new instances. This facilitates performing configuration actions on the hosts immediately in a subsequent task.::" -#~ msgstr "このモジュールから add_host モジュールを使用し、これらの新規インスタンスで構成されるホストグループを動的に作成します。これにより、後続のタスクで、ホストでの設定アクションをすぐに実行できます。" - -#~ msgid "With the host group now created, a second play at the bottom of the same provisioning playbook file might now have some configuration steps::" -#~ msgstr "これでホストグループが作成されたので、同じプロビジョニング Playbook ファイルの下部にある2つ目のプレイでは、以下のような設定ステップが必要になります。" - -#~ msgid "Security Groups" -#~ msgstr "セキュリティーグループ" - -#~ msgid "Security groups on AWS are stateful. The response of a request from your instance is allowed to flow in regardless of inbound security group rules and vice-versa. In case you only want allow traffic with AWS S3 service, you need to fetch the current IP ranges of AWS S3 for one region and apply them as an egress rule.::" -#~ msgstr "AWS のセキュリティーグループはステートフルです。インスタンスからの要求の応答は、受信セキュリティーグループルールに関係なく流入が許可され、その逆も同様です。AWS S3 サービスを使用するトラフィックのみを許可する場合は、あるリージョンに対して AWS S3 の現在の IP 範囲を取得し、それを egress ルールとして適用する必要があります。" - -#~ msgid "Once your nodes are spun up, you'll probably want to talk to them again. With a cloud setup, it's best to not maintain a static list of cloud hostnames in text files. Rather, the best way to handle this is to use the aws_ec2 inventory plugin. See :ref:`dynamic_inventory`." -#~ msgstr "ノードが起動したら、おそらく再通信するようにしたいでしょう。クラウド設定では、テキストファイルに、クラウドホスト名の静的リストを維持しないことが推奨されます。これを処理する最善の方法は、aws_ec2 インベントリープラグインを使用することです。:ref:`dynamic_inventory` を参照してください。" - -#~ msgid "The plugin will also return instances that were created outside of Ansible and allow Ansible to manage them." -#~ msgstr "このプラグインにより、Ansible 外で作成されたインスタンスも選択され、Ansible がインスタンスを管理できるようになります。" - -#~ msgid "Tags And Groups And Variables" -#~ msgstr "タグ、グループ、および変数" - -#~ msgid "When using the inventory plugin, you can configure extra inventory structure based on the metadata returned by AWS." -#~ msgstr "インベントリープラグインを使用する場合は、AWS により返されるメタデータに基づいて追加のインベントリー構造を設定できます。" - -#~ msgid "For instance, you might use ``keyed_groups`` to create groups from instance tags::" -#~ msgstr "たとえば、``keyed_groups`` を使用してインスタンスタグからグループを作成することができます。" - -#~ msgid "You can then target all instances with a \"class\" tag where the value is \"webserver\" in a play::" -#~ msgstr "次に、「class」タグの付いたすべてのインスタンスをターゲットにすることができます。ここで、値はプレイ内の「webserver」になります。" - -#~ msgid "You can also use these groups with 'group_vars' to set variables that are automatically applied to matching instances. See :ref:`splitting_out_vars`." -#~ msgstr "「group_vars」でこれらのグループを使用して、一致するインスタンスに自動的に適用される変数を設定することもできます。「:ref:`splitting_out_vars`」を参照してください。" - -#~ msgid "Autoscaling with Ansible Pull" -#~ msgstr "Ansible Pull を使用した自動スケーリング" - -#~ msgid "Amazon Autoscaling features automatically increase or decrease capacity based on load. There are also Ansible modules shown in the cloud documentation that can configure autoscaling policy." -#~ msgstr "Amazon Autoscaling 機能は、負荷に応じて容量を自動的に増減します。また、クラウドドキュメントで説明されるように、自動スケーリングポリシーを設定する Ansible モジュールがあります。" - -#~ msgid "When nodes come online, it may not be sufficient to wait for the next cycle of an ansible command to come along and configure that node." -#~ msgstr "ノードがオンラインになると、ansible コマンドの次のサイクルが反映されてそのノードを設定するのを待つことができない可能性があります。" - -#~ msgid "To do this, pre-bake machine images which contain the necessary ansible-pull invocation. Ansible-pull is a command line tool that fetches a playbook from a git server and runs it locally." -#~ msgstr "そのためには、必要な ansible-pull 呼び出しを含むマシンイメージを事前に作成します。ansible-pull は、git サーバーから Playbook を取得し、ローカルで実行するコマンドラインツールです。" - -#~ msgid "One of the challenges of this approach is that there needs to be a centralized way to store data about the results of pull commands in an autoscaling context. For this reason, the autoscaling solution provided below in the next section can be a better approach." -#~ msgstr "このアプローチの課題の 1 つとして、pull コマンドの結果に関するデータを自動スケーリングコンテキストに保存する集中的な方法が必要になります。このため、次のセクションで提供される自動スケーリングソリューションの方が適切です。" - -#~ msgid "Read :ref:`ansible-pull` for more information on pull-mode playbooks." -#~ msgstr "pull モードの Playbook の詳細は、「:ref:`ansible-pull`」を参照してください。" - -#~ msgid "Autoscaling with Ansible Tower" -#~ msgstr "Ansible Tower を使用した自動スケーリング" - -#~ msgid ":ref:`ansible_tower` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call a defined URL and the server will \"dial out\" to the requester and configure an instance that is spinning up. This can be a great way to reconfigure ephemeral nodes. See the Tower install and product documentation for more details." -#~ msgstr "また、:ref:`ansible_tower` は、自動スケーリングのユースケースには非常に優れた機能も含まれています。このモードでは、簡単な curl スクリプトは定義された URL を呼び出すことができ、サーバーは要求元に対して「ダイヤルアウト」し、起動しているインスタンスを構成します。これは、一時ノードを再設定する優れた方法になります。詳細は、Tower のインストールと製品のドキュメントを参照してください。" - -#~ msgid "Ansible With (And Versus) CloudFormation" -#~ msgstr "CloudFormation を使用した Ansible (Ansible と CloudFormation の比較)" - -#~ msgid "CloudFormation is a Amazon technology for defining a cloud stack as a JSON or YAML document." -#~ msgstr "CloudFormation は、クラウドスタックを JSON または YAML のドキュメントとして定義する Amazon テクノロジーです。" - -#~ msgid "Ansible modules provide an easier to use interface than CloudFormation in many examples, without defining a complex JSON/YAML document. This is recommended for most users." -#~ msgstr "Ansible モジュールは、複雑な JSON/YAML ドキュメントを定義せずに、多くの例で CloudFormation よりも簡単にインターフェースを使用できます。これは、ほとんどのユーザーに推奨されます。" - -#~ msgid "However, for users that have decided to use CloudFormation, there is an Ansible module that can be used to apply a CloudFormation template to Amazon." -#~ msgstr "ただし、CloudFormation を使用するユーザーには、CloudFormation テンプレートを Amazon に適用するのに使用できる Ansible モジュールがあります。" - -#~ msgid "When using Ansible with CloudFormation, typically Ansible will be used with a tool like Packer to build images, and CloudFormation will launch those images, or ansible will be invoked through user data once the image comes online, or a combination of the two." -#~ msgstr "CloudFormation で Ansible を使用する場合は、通常、Ansible を Packer などのツールで使用してイメージを作成し、CloudFormation がそのイメージを起動するか、イメージがオンラインになると、ユーザーデータを通じて ansible が呼び出されるか、その組み合わせとなります。" - -#~ msgid "Please see the examples in the Ansible CloudFormation module for more details." -#~ msgstr "詳細は、Ansible CloudFormation モジュールのサンプルを参照してください。" - -#~ msgid "AWS Image Building With Ansible" -#~ msgstr "Ansible での AWS イメージの構築" - -#~ msgid "Many users may want to have images boot to a more complete configuration rather than configuring them entirely after instantiation. To do this, one of many programs can be used with Ansible playbooks to define and upload a base image, which will then get its own AMI ID for usage with the ec2 module or other Ansible AWS modules such as ec2_asg or the cloudformation module. Possible tools include Packer, aminator, and Ansible's ec2_ami module." -#~ msgstr "多くの場合、インスタンス化後にイメージを完全に設定するのではなく、より完全な設定での起動を望みます。これを行うには、Ansible Playbook とともに多くのプログラムの中から 1 つ使用してベースイメージを定義し、アップロードできます。これにより、ec2 モジュール、ec2_asg モジュールや cloudformation モジュールなどのその他の Ansible AWS モジュールと使用するため、独自の AMI ID を取得します。ツールには Packer、aminator、および Ansible の ec2_ami モジュールが含まれます。" - -#~ msgid "Generally speaking, we find most users using Packer." -#~ msgstr "一般的には、Packer が使用されます。" - -#~ msgid "See the Packer documentation of the `Ansible local Packer provisioner `_ and `Ansible remote Packer provisioner `_." -#~ msgstr "`Ansible ローカル Packer プロビジョナー `_ および `Ansible リモート Packer プロビジョナー `_ の Packer ドキュメントを参照してください。" - -#~ msgid "If you do not want to adopt Packer at this time, configuring a base-image with Ansible after provisioning (as shown above) is acceptable." -#~ msgstr "現時点では、Packer を使用しない場合は、プロビジョニング後に (上記のように) Ansible を使用したベースイメージの設定が可能です。" - -#~ msgid "Next Steps: Explore Modules" -#~ msgstr "次のステップ: モジュールの検証" - -#~ msgid "Ansible ships with lots of modules for configuring a wide array of EC2 services. Browse the \"Cloud\" category of the module documentation for a full list with examples." -#~ msgstr "Ansible には、さまざまな EC2 サービスを設定するモジュールが多数同梱されています。例を含む完全な一覧については、モジュールドキュメントの「クラウド」カテゴリーを参照してください。" - -#~ msgid ":ref:`list_of_collections`" -#~ msgstr ":ref:`list_of_collections`" - -#~ msgid "Browse existing collections, modules, and plugins" -#~ msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#~ msgid ":ref:`playbooks_delegation`" -#~ msgstr ":ref:`playbooks_delegation`" - -#~ msgid "Delegation, useful for working with loud balancers, clouds, and locally executed steps." -#~ msgstr "委譲 (ロードバランサー、クラウド、ローカルで実行した手順を使用する際に役に立ちます)" - -#~ msgid "`User Mailing List `_" -#~ msgstr "`ユーザーメーリングリスト `_" - -#~ msgid "`irc.freenode.net `_" -#~ msgstr "`irc.freenode.net `_" - -#~ msgid "#ansible IRC chat channel" -#~ msgstr "IRC チャットチャンネル (#ansible)" - -#~ msgid "The Azure Resource Manager inventory script is called `azure_rm.py `_. It authenticates with the Azure API exactly the same as the Azure modules, which means you will either define the same environment variables described above in `Using Environment Variables`_, create a ``$HOME/.azure/credentials`` file (also described above in `Storing in a File`_), or pass command line parameters. To see available command line options execute the following:" -#~ msgstr "Azure Resource Manager インベントリースクリプトは `azure_rm.py `_ と呼ばれます。Azure API での認証は Azure モジュールと同じになります。つまり、「`環境変数の使用`_」で説明されている環境変数と同じ環境変数を定義するか、``$HOME/.azure/credentials`` ファイルを作成するか (「`ファイルの保存`_」を参照)、またはコマンドラインパラメーターを渡します。利用可能なコマンドラインオプションを表示するには、以下のコマンドを実行します。" - -#~ msgid "The `community.docker collection `_ offers several modules and plugins for orchestrating Docker containers and Docker Swarm." -#~ msgstr "`community.docker collection `_ は、複数のモジュールと、Docker コンテナーおよび Docker Swarm のオーケストレーション用のプラグインを提供します。" - -#~ msgid "Most of the modules and plugins in community.docker require the `Docker SDK for Python `_. The SDK needs to be installed on the machines where the modules and plugins are executed, and for the Python version(s) with which the modules and plugins are executed. You can use the :ref:`community.general.python_requirements_info module ` to make sure that the Docker SDK for Python is installed on the correct machine and for the Python version used by Ansible." -#~ msgstr "community.docker におけるほとんどのモジュールおよびプラグインには `Docker SDK for Python `_ が必要です。モジュールとプラグインが実行するマシンに SDK をインストールする必要があり、モジュールおよびプラグインが実行する Python バージョンで :ref:`community.general.python_requirements_info module ` を使用して、Docker SDK for Python が正しいマシンに、Ansible が使用する Python バージョン用にインストールされているようにすることができます。" - -#~ msgid "Note that plugins (inventory plugins and connection plugins) are always executed in the context of Ansible itself. If you use a plugin that requires the Docker SDK for Python, you need to install it on the machine running ``ansible`` or ``ansible-playbook`` and for the same Python interpreter used by Ansible. To see which Python is used, run ``ansible --version``." -#~ msgstr "プラグイン (インベントリープラグインおよび接続プラグイン) は常に Ansible のコンテキストで実行されます。Python 用の Docker SDK を必要とするプラグインを使用する場合は、``ansible`` または ``ansible-playbook`` を実行しているマシンにプラグインをインストールする必要があります。使用する Python を確認するには、``ansible --version`` を実行します。" - -#~ msgid "You can install the Docker SDK for Python for Python 2.7 or Python 3 as follows:" -#~ msgstr "Python 2.7 または Python 3 用の Docker SDK は、以下のようにインストールできます。" - -#~ msgid "For Python 2.6, you need a version before 2.0. For these versions, the SDK was called ``docker-py``, so you need to install it as follows:" -#~ msgstr "Python 2.6 では 2.0 よりも前のバージョンが必要です。これらのバージョンでは、SDK は ``docker-py`` と呼ばれ、以下のようにインストールする必要があります。" - -#~ msgid "Please install only one of ``docker`` or ``docker-py``. Installing both will result in a broken installation. If this happens, Ansible will detect it and inform you about it. If that happens, you must uninstall both and reinstall the correct version." -#~ msgstr "``docker`` または ``docker-py`` のいずれかをインストールするには、インストールが破損します。これがインストールされると、Ansible によって検出され、それについて通知されます。その場合は、両方をアンインストールして再インストールする必要があります。" - -#~ msgid "If in doubt, always install ``docker`` and never ``docker-py``." -#~ msgstr "不明な場合は、常に ``docker`` をインストールし、``docker-py`` はインストールしません。" - -#~ msgid "Connecting to the Docker API" -#~ msgstr "Docker API への接続" - -#~ msgid "You can connect to a local or remote API using parameters passed to each task or by setting environment variables. The order of precedence is command line parameters and then environment variables. If neither a command line option nor an environment variable is found, Ansible uses the default value provided under `Parameters`_." -#~ msgstr "各タスクに渡されるパラメーターを使用するか、環境変数を設定してローカルまたはリモートの API に接続できます。優先順位の順番はコマンドラインパラメーターとその環境変数です。コマンドラインオプションも環境変数も見つからない場合、Ansible は `Parameters`_ で指定したデフォルト値を使用します。" - -#~ msgid "Parameters" -#~ msgstr "パラメーター" - -#~ msgid "Most plugins and modules can be configured by the following parameters:" -#~ msgstr "ほとんどのプラグインおよびモジュールは、以下のパラメーターで設定できます。" - -#~ msgid "docker_host" -#~ msgstr "docker_host" - -#~ msgid "The URL or Unix socket path used to connect to the Docker API. Defaults to ``unix://var/run/docker.sock``. To connect to a remote host, provide the TCP connection string (for example: ``tcp://192.0.2.23:2376``). If TLS is used to encrypt the connection to the API, then the module will automatically replace 'tcp' in the connection URL with 'https'." -#~ msgstr "Docker API への接続に使用される URL または Unix ソケットパス。デフォルトは ``unix://var/run/docker.sock`` です。リモートホストに接続するには、TCP 接続文字列を指定します (例: ``tcp://192.0.2.23:2376``)。TLS を使用して API への接続を暗号化すると、モジュールは、接続 URL の 「tcp」を自動的に「https」に置き換えます。" - -#~ msgid "api_version" -#~ msgstr "api_version" - -#~ msgid "The version of the Docker API running on the Docker Host. Defaults to the latest version of the API supported by the Docker SDK for Python installed." -#~ msgstr "Docker Host 上で実行される Docker API のバージョンです。デフォルトでは、Python 用の Docker SDK によってサポートされる API の最新バージョンに設定されます。" - -#~ msgid "The maximum amount of time in seconds to wait on a response from the API. Defaults to 60 seconds." -#~ msgstr "API からのレスポンスで待機する最大時間 (秒単位)。デフォルトは 60 秒です。" - -#~ msgid "tls" -#~ msgstr "tls" - -#~ msgid "Secure the connection to the API by using TLS without verifying the authenticity of the Docker host server. Defaults to ``false``." -#~ msgstr "Docker ホストサーバーの信頼性を検証せずに TLS を使用して API への接続を保護します。デフォルトは ``false`` です。" - -#~ msgid "Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server. Default is ``false``." -#~ msgstr "TLS を使用し、Docker ホストサーバーの信頼性を検証して、API への接続を保護します。デフォルトは``false`` です。" - -#~ msgid "cacert_path" -#~ msgstr "cacert_path" - -#~ msgid "Use a CA certificate when performing server verification by providing the path to a CA certificate file." -#~ msgstr "CA 証明書ファイルへのパスを指定してサーバーの検証を実行する際に CA 証明書を使用します。" - -#~ msgid "cert_path" -#~ msgstr "cert_path" - -#~ msgid "Path to the client's TLS certificate file." -#~ msgstr "クライアントの TLS 証明書ファイルへのパスです。" - -#~ msgid "key_path" -#~ msgstr "key_path" - -#~ msgid "Path to the client's TLS key file." -#~ msgstr "クライアントの TLS キーファイルへのパスです。" - -#~ msgid "tls_hostname" -#~ msgstr "tls_hostname" - -#~ msgid "When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults to ``localhost``." -#~ msgstr "Docker Host サーバーの信頼性を確認する際に、予想されるサーバー名を提供します。デフォルトは ``localhost`` です。" - -#~ msgid "ssl_version" -#~ msgstr "ssl_version" - -#~ msgid "Provide a valid SSL version number. The default value is determined by the Docker SDK for Python." -#~ msgstr "有効な SSL バージョン番号を提供します。デフォルト値は、Python の Docker SDK により決定されます。" - -#~ msgid "You can also control how the plugins and modules connect to the Docker API by setting the following environment variables." -#~ msgstr "以下の環境変数を設定して、プラグインおよびモジュールが Docker API に接続する方法を制御することもできます。" - -#~ msgid "For plugins, they have to be set for the environment Ansible itself runs in. For modules, they have to be set for the environment the modules are executed in. For modules running on remote machines, the environment variables have to be set on that machine for the user used to execute the modules with." -#~ msgstr "プラグインには、Ansible 自体が実行する環境に合わせて設定する必要があります。モジュールの場合は、モジュールが実行する環境に設定する必要があります。リモートマシンで実行しているモジュールの場合は、モジュールを実行するユーザーのマシンに環境変数を設定する必要があります。" - -#~ msgid "DOCKER_HOST" -#~ msgstr "DOCKER_HOST" - -#~ msgid "The URL or Unix socket path used to connect to the Docker API." -#~ msgstr "Docker API への接続に使用される URL または Unix ソケットパス。" - -#~ msgid "DOCKER_API_VERSION" -#~ msgstr "DOCKER_API_VERSION" - -#~ msgid "The version of the Docker API running on the Docker Host. Defaults to the latest version of the API supported by docker-py." -#~ msgstr "Docker Host 上で実行する Docker API のバージョンです。デフォルトでは、docker-py でサポートされる API の最新バージョンに設定されます。" - -#~ msgid "DOCKER_TIMEOUT" -#~ msgstr "DOCKER_TIMEOUT" - -#~ msgid "The maximum amount of time in seconds to wait on a response from the API." -#~ msgstr "API からの応答で待機する最大時間 (秒単位)。" - -#~ msgid "DOCKER_CERT_PATH" -#~ msgstr "DOCKER_CERT_PATH" - -#~ msgid "Path to the directory containing the client certificate, client key and CA certificate." -#~ msgstr "クライアント証明書、クライアントキー、および CA 証明書を含むディレクトリーへのパス。" - -#~ msgid "DOCKER_SSL_VERSION" -#~ msgstr "DOCKER_SSL_VERSION" - -#~ msgid "Provide a valid SSL version number." -#~ msgstr "有効な SSL バージョン番号を指定します。" - -#~ msgid "DOCKER_TLS" -#~ msgstr "DOCKER_TLS" - -#~ msgid "Secure the connection to the API by using TLS without verifying the authenticity of the Docker Host." -#~ msgstr "Docker ホストの信頼性を検証せずに TLS を使用して API への接続のセキュリティーを保護します。" - -#~ msgid "DOCKER_TLS_VERIFY" -#~ msgstr "DOCKER_TLS_VERIFY" - -#~ msgid "Secure the connection to the API by using TLS and verify the authenticity of the Docker Host." -#~ msgstr "TLS を使用して API への接続のセキュリティーを確保し、Docker ホストの信頼性を検証します。" - -#~ msgid "Plain Docker daemon: images, networks, volumes, and containers" -#~ msgstr "単純な Docker デーモン: イメージ、ネットワーク、ボリューム、およびコンテナー" - -#~ msgid "For working with a plain Docker daemon, that is without Swarm, there are connection plugins, an inventory plugin, and several modules available:" -#~ msgstr "Swarm を使用しないプレーンな Docker デーモンを使用する場合は、接続プラグイン、インベントリープラグイン、および複数のモジュールが利用できます。" - -#~ msgid "docker connection plugin" -#~ msgstr "Docker 接続プラグイン" - -#~ msgid "The :ref:`community.docker.docker connection plugin ` uses the Docker CLI utility to connect to Docker containers and execute modules in them. It essentially wraps ``docker exec`` and ``docker cp``. This connection plugin is supported by the :ref:`ansible.posix.synchronize module `." -#~ msgstr ":ref:`community.docker.docker 接続プラグイン ` は、Docker CLI ユーティリティーを使用して Docker コンテナーに接続し、そのコンテナーでモジュールを実行します。基本的に ``docker exec`` と ``docker cp`` をラップします。この接続プラグインは :ref:`ansible.posix.synchronize module ` によりサポートされます。" - -#~ msgid "docker_api connection plugin" -#~ msgstr "docker_api connection プラグイン" - -#~ msgid "The :ref:`community.docker.docker_api connection plugin ` talks directly to the Docker daemon to connect to Docker containers and execute modules in them." -#~ msgstr ":ref:`community.docker.docker_api 接続プラグイン ` は Docker デーモンに直接対話し、Docker コンテナーに接続し、そのコンテナーでモジュールを実行します。" - -#~ msgid "docker_containers inventory plugin" -#~ msgstr "docker_containers インベントリープラグイン" - -#~ msgid "The :ref:`community.docker.docker_containers inventory plugin ` allows you to dynamically add Docker containers from a Docker Daemon to your Ansible inventory. See :ref:`dynamic_inventory` for details on dynamic inventories." -#~ msgstr ":ref:`community.docker.docker_containers インベントリープラグイン ` では、Docker Daemon から Ansible インベントリーに Docker コンテナーを動的に追加できます。動的インベントリーの詳細は、「:ref:`dynamic_inventory`」を参照してください。" - -#~ msgid "The `docker inventory script `_ is deprecated. Please use the inventory plugin instead. The inventory plugin has several compatibility options. If you need to collect Docker containers from multiple Docker daemons, you need to add every Docker daemon as an individual inventory source." -#~ msgstr "`Docker インベントリースクリプト `_ は非推奨になりました。代わりにインベントリープラグインを使用してください。インベントリープラグインには、複数の互換性オプションがあります。複数の Docker デーモンから Docker コンテナーを収集する必要がある場合は、すべての Docker デーモンを個別のインベントリーソースとして追加する必要があります。" - -#~ msgid "docker_host_info module" -#~ msgstr "docker_host_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_host_info module ` allows you to retrieve information on a Docker daemon, such as all containers, images, volumes, networks and so on." -#~ msgstr ":ref:`community.docker.docker_host_info モジュール ` では、すべてのコンテナー、イメージ、ボリューム、ネットワークなど、Docker デーモンの情報を取得できます。" - -#~ msgid "docker_login module" -#~ msgstr "docker_login モジュール" - -#~ msgid "The :ref:`community.docker.docker_login module ` allows you to log in and out of a remote registry, such as Docker Hub or a private registry. It provides similar functionality to the ``docker login`` and ``docker logout`` CLI commands." -#~ msgstr ":ref:`community.docker.docker_login モジュール ` では、Docker Hub、プライベートレジストリーなどのリモートレジストリーへのログイン、およびリモートレジストリーからのログアウトできます。CLI コマンド ``docker login`` および ``docker logout`` と同様の機能を提供します。" - -#~ msgid "docker_prune module" -#~ msgstr "docker_prune モジュール" - -#~ msgid "The :ref:`community.docker.docker_prune module ` allows you to prune no longer needed containers, images, volumes and so on. It provides similar functionality to the ``docker prune`` CLI command." -#~ msgstr ":ref:`community.docker.docker_prune モジュール ` では、コンテナー、イメージ、ボリュームなどは取り除くことができなくなり、CLI コマンド ``docker prune`` と同様の機能を提供します。" - -#~ msgid "docker_image module" -#~ msgstr "docker_image モジュール" - -#~ msgid "The :ref:`community.docker.docker_image module ` provides full control over images, including: build, pull, push, tag and remove." -#~ msgstr ":ref:`community.docker.docker_image モジュール ` は、build、pull、push、tag、remove などのイメージを完全に制御します。" - -#~ msgid "docker_image_info module" -#~ msgstr "docker_image_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_image_info module ` allows you to list and inspect images." -#~ msgstr ":ref:`community.docker.docker_image_info モジュール ` を使用すると、イメージを一覧表示し、検査することができます。" - -#~ msgid "docker_network module" -#~ msgstr "docker_network モジュール" - -#~ msgid "The :ref:`community.docker.docker_network module ` provides full control over Docker networks." -#~ msgstr ":ref:`community.docker.docker_network モジュール ` は、Docker ネットワークを完全に制御します。" - -#~ msgid "docker_network_info module" -#~ msgstr "docker_network_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_network_info module ` allows you to inspect Docker networks." -#~ msgstr ":ref:`community.docker.docker_network_info モジュール ` では、Docker ネットワークを調べることができます。" - -#~ msgid "docker_volume_info module" -#~ msgstr "docker_volume_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_volume_info module ` provides full control over Docker volumes." -#~ msgstr ":ref:`community.docker.docker_volume_info モジュール ` は、Docker ボリュームを完全に制御します。" - -#~ msgid "docker_volume module" -#~ msgstr "docker_volume モジュール" - -#~ msgid "The :ref:`community.docker.docker_volume module ` allows you to inspect Docker volumes." -#~ msgstr ":ref:`community.docker.docker_volume モジュール ` を使用すると、Docker ボリュームを検査できます。" - -#~ msgid "docker_container module" -#~ msgstr "docker_container モジュール" - -#~ msgid "The :ref:`community.docker.docker_container module ` manages the container lifecycle by providing the ability to create, update, stop, start and destroy a Docker container." -#~ msgstr ":ref:`community.docker.docker_container モジュール ` は、Docker コンテナーの作成、更新、停止、開始、および破棄の機能を提供することで、コンテナーのライフサイクルを管理します。" - -#~ msgid "docker_container_info module" -#~ msgstr "docker_container_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_container_info module ` allows you to inspect a Docker container." -#~ msgstr ":ref:`community.docker.docker_container_info モジュール ` では、Docker コンテナーを検査できます。" - -#~ msgid "Docker Compose" -#~ msgstr "Docker Compose" - -#~ msgid "The :ref:`community.docker.docker_compose module ` allows you to use your existing Docker compose files to orchestrate containers on a single Docker daemon or on Swarm. Supports compose versions 1 and 2." -#~ msgstr ":ref:`community.docker.docker_compose モジュール ` では、既存の Docker Compose ファイルを使用して、単一の Docker デーモンまたは Swarm でコンテナーをオーケストレーションできます。Compose のバージョン 1 および 2 をサポートします。" - -#~ msgid "Next to Docker SDK for Python, you need to install `docker-compose `_ on the remote machines to use the module." -#~ msgstr "モジュールを使用するには、Python の Docker SDK の次に、リモートマシンに `docker-compose `_ をインストールする必要があります。" - -#~ msgid "Docker Machine" -#~ msgstr "Docker マシン" - -#~ msgid "The :ref:`community.docker.docker_machine inventory plugin ` allows you to dynamically add Docker Machine hosts to your Ansible inventory." -#~ msgstr ":ref:`community.docker.docker_machine inventory plugin ` では、Docker マシンホストを Ansible インベントリーに動的に追加できます。" - -#~ msgid "Docker stack" -#~ msgstr "Docker スタック" - -#~ msgid "The :ref:`community.docker.docker_stack module ` module allows you to control Docker stacks. Information on stacks can be retrieved by the :ref:`community.docker.docker_stack_info module `, and information on stack tasks can be retrieved by the :ref:`community.docker.docker_stack_task_info module `." -#~ msgstr ":ref:`community.docker.docker_stack モジュール ` モジュールにより、Docker スタックを制御できます。スタックの情報は、:ref:`community.docker.docker_stack_info モジュール ` で取得でき、スタックタスクに関する情報は :ref:`community.docker.docker_stack_task_info モジュール ` で取得できます。" - -#~ msgid "Docker Swarm" -#~ msgstr "Docker Swarm" - -#~ msgid "The community.docker collection provides multiple plugins and modules for managing Docker Swarms." -#~ msgstr "community.docker コレクションは、Docker Swarm を管理するための複数のプラグインとモジュールを提供します。" - -#~ msgid "Swarm management" -#~ msgstr "Swarm 管理" - -#~ msgid "One inventory plugin and several modules are provided to manage Docker Swarms:" -#~ msgstr "Docker Swarms を管理するために、インベントリープラグインと複数のモジュールが提供されます。" - -#~ msgid "docker_swarm inventory plugin" -#~ msgstr "docker_swarm インベントリープラグイン" - -#~ msgid "The :ref:`community.docker.docker_swarm inventory plugin ` allows you to dynamically add all Docker Swarm nodes to your Ansible inventory." -#~ msgstr ":ref:`community.docker.docker_swarm インベントリープラグイン ` により、すべての Docker Swarm ノードを Ansible インベントリーに動的に追加できます。" - -#~ msgid "docker_swarm module" -#~ msgstr "docker_swarm モジュール" - -#~ msgid "The :ref:`community.docker.docker_swarm module ` allows you to globally configure Docker Swarm manager nodes to join and leave swarms, and to change the Docker Swarm configuration." -#~ msgstr ":ref:`community.docker.docker_swarm モジュール ` では、Docker Swarm マネージャーノードをグローバルに設定し、swarm に参加および swarm から離脱し、Docker Swarm 設定の変更を行うことができます。" - -#~ msgid "docker_swarm_info module" -#~ msgstr "docker_swarm_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_swarm_info module ` allows you to retrieve information on Docker Swarm." -#~ msgstr ":ref:`community.docker.docker_swarm_info モジュール ` では、Docker Swarm に関する情報を取得できます。" - -#~ msgid "docker_node module" -#~ msgstr "docker_node モジュール" - -#~ msgid "The :ref:`community.docker.docker_node module ` allows you to manage Docker Swarm nodes." -#~ msgstr ":ref:`community.docker.docker_node モジュール ` では、Docker Swarm ノードを管理できます。" - -#~ msgid "docker_node_info module" -#~ msgstr "docker_node_info モジュール" - -#~ msgid "The :ref:`community.docker.docker_node_info module ` allows you to retrieve information on Docker Swarm nodes." -#~ msgstr ":ref:`community.docker.docker_node_info モジュール ` では、Docker Swarm ノードの情報を取得できます。" - -#~ msgid "Configuration management" -#~ msgstr "設定管理" - -#~ msgid "The community.docker collection offers modules to manage Docker Swarm configurations and secrets:" -#~ msgstr "community.docker コレクションは、Docker Swarm 設定およびシークレットを管理するモジュールを提供します。" - -#~ msgid "docker_config module" -#~ msgstr "docker_config モジュール" - -#~ msgid "The :ref:`community.docker.docker_config module ` allows you to create and modify Docker Swarm configs." -#~ msgstr ":ref:`community.docker.docker_config モジュール ` を使用すると、Docker Swarm 設定を作成および変更できます。" - -#~ msgid "docker_secret module" -#~ msgstr "docker_secret モジュール" - -#~ msgid "The :ref:`community.docker.docker_secret module ` allows you to create and modify Docker Swarm secrets." -#~ msgstr ":ref:`community.docker.docker_secret モジュール ` では、Docker Swarm シークレットを作成および変更できます。" - -#~ msgid "Swarm services" -#~ msgstr "Swarm サービス" - -#~ msgid "Docker Swarm services can be created and updated with the :ref:`community.docker.docker_swarm_service module `, and information on them can be queried by the :ref:`community.docker.docker_swarm_service_info module `." -#~ msgstr "Docker Swarm サービスは、:ref:`community.docker.docker_swarm_service モジュール ` で作成および更新でき、その情報は、:ref:`community.docker.docker_swarm_service_info モジュール ` でクエリーできます。" - -#~ msgid "Helpful links" -#~ msgstr "便利なリンク" - -#~ msgid "Still using Dockerfile to build images? Check out `ansible-bender `_, and start building images from your Ansible playbooks." -#~ msgstr "Dockerfile を使用してイメージを構築していますか。`ansible-bender `_ を確認して、Ansible Playbook からイメージの構築を開始します。" - -#~ msgid "Use `Ansible Operator `_ to launch your docker-compose file on `OpenShift `_. Go from an app on your laptop to a fully scalable app in the cloud with Kubernetes in just a few moments." -#~ msgstr "`Ansible Operator `_ を使用して、`OpenShift `_ で docker 構成のファイルを起動します。ラップトップ上のアプリケーションから、Kubernetes を使用するクラウド内の完全なスケーラブルなアプリケーション (数分間) に移動します。" - -#~ msgid "Kubernetes Guide" -#~ msgstr "Kubernetes ゲスト" - -#~ msgid "Welcome to the Ansible for Kubernetes Guide!" -#~ msgstr "Kubernetes 向け Ansible ガイドにようこそ!" - -#~ msgid "The purpose of this guide is to teach you everything you need to know about using Ansible with Kubernetes." -#~ msgstr "本ガイドの目的は、Kubernetes での Ansible の使用について理解しておく必要があります。" - -#~ msgid "To get started, please select one of the following topics." -#~ msgstr "最初に以下のトピックのいずれかを選択してください。" - -#~ msgid "This section of the documentation is under construction. We are in the process of adding more examples about the Rackspace modules and how they work together. Once complete, there will also be examples for Rackspace Cloud in `ansible-examples `_." -#~ msgstr "本ガイドに記載するセクションは作成中です。ここでは、Rackspace モジュールやそれがどのように連携するかについての例を追加するプロセスです。完了後は、`ansible-examples `_ に Rackspace Cloud の例もあります。" - -#~ msgid "Autoscaling with Tower" -#~ msgstr "Tower を使用した自動スケーリング" - -#~ msgid "VMware Guide" -#~ msgstr "VMware ガイド" - -#~ msgid "Welcome to the Ansible for VMware Guide!" -#~ msgstr "VMware 向け Ansible ガイドでようこそ!" - -#~ msgid "The purpose of this guide is to teach you everything you need to know about using Ansible with VMware." -#~ msgstr "本ガイドの目的は、VMware で Ansible を使用する際に必要な知識を学習することです。" - -#~ msgid "Introduction to Ansible for Kubernetes" -#~ msgstr "Kubernetes 向け Ansible の概要" - -#~ msgid "Modules for interacting with the Kubernetes (K8s) and OpenShift API are under development, and can be used in preview mode. To use them, review the requirements, and then follow the installation and use instructions." -#~ msgstr "Kubernetes (K8s) および OpenShift API と対話するためのモジュールは開発中であり、プレビューモードで使用することができます。このモジュールを使用するには、要件を確認し、インストールおよび指示に従ってください。" - -#~ msgid "To use the modules, you'll need the following:" -#~ msgstr "モジュールを使用するには、以下が必要になります。" - -#~ msgid "Run Ansible from source. For assistance, view :ref:`from_source`." -#~ msgstr "ソースから Ansible を実行します。サポートについては、「:ref:`from_source`」をご覧ください。" - -#~ msgid "`OpenShift Rest Client `_ installed on the host that will execute the modules." -#~ msgstr "`OpenShift Rest クライアント ` が、モジュールを実行するホストにインストールされている。" - -#~ msgid "The Kubernetes modules are part of the `Ansible Kubernetes collection `_." -#~ msgstr "Kubernetes モジュールは、`Ansible Kubernetes コレクション `_ の一部です。" - -#~ msgid "To install the collection, run the following:" -#~ msgstr "コレクションをインストールするには、以下を実行します。" - -#~ msgid "Authenticating with the API" -#~ msgstr "API での認証" - -#~ msgid "By default the OpenShift Rest Client will look for ``~/.kube/config``, and if found, connect using the active context. You can override the location of the file using the``kubeconfig`` parameter, and the context, using the ``context`` parameter." -#~ msgstr "デフォルトでは、OpenShift Rest Client は ``~/.kube/config`` を検索し、見つかった場合はアクティブなコンテキストを使用して接続します。``kubeconfig`` パラメーターを使用してファイルの場所を上書きし、``context`` パラメーターを使用してコンテキストを上書きできます。" - -#~ msgid "Basic authentication is also supported using the ``username`` and ``password`` options. You can override the URL using the ``host`` parameter. Certificate authentication works through the ``ssl_ca_cert``, ``cert_file``, and ``key_file`` parameters, and for token authentication, use the ``api_key`` parameter." -#~ msgstr "Basic 認証は、``username`` オプションおよび ``password`` オプションを使用してもサポートされます。``host`` パラメーターを使用して URL を上書きできます。証明書認証は、``ssl_ca_cert`` パラメーター、``cert_file`` パラメーター、および ``key_file`` パラメーターで機能します。また、トークン認証には ``api_key`` パラメーターを使用します。" - -#~ msgid "To disable SSL certificate verification, set ``verify_ssl`` to false." -#~ msgstr "SSL 証明書の検証を無効にするには、``verify_ssl`` を false に設定します。" - -#~ msgid "Reporting an issue" -#~ msgstr "問題の報告" - -#~ msgid "If you find a bug or have a suggestion regarding modules, please file issues at `Ansible Kubernetes collection `_. If you find a bug regarding OpenShift client, please file issues at `OpenShift REST Client issues `_. If you find a bug regarding Kubectl binary, please file issues at `Kubectl issue tracker `_" -#~ msgstr "バグが見つかった場合やモジュールに関する提案をお寄せいただける場合は、`Ansible Kubernetes コレクション `_ にファイルの問題を報告してください。OpenShift クライアントに関するバグが見つかった場合は、`OpenShift REST クライアントの問題 `_ に問題を作成してください。Kubectl バイナリーに関するバグは、`Kubectl issue tracker `_ で問題を作成してください。" - -#~ msgid "Using Kubernetes dynamic inventory plugin" -#~ msgstr "Kubernetes 動的インベントリープラグインの使用" - -#~ msgid "Kubernetes dynamic inventory plugin" -#~ msgstr "Kubernetes 動的インベントリープラグイン" - -#~ msgid "The best way to interact with your Pods is to use the Kubernetes dynamic inventory plugin, which dynamically queries Kubernetes APIs using ``kubectl`` command line available on controller node and tells Ansible what Pods can be managed." -#~ msgstr "Pod と対話する最適な方法として、Kubernetes 動的インベントリープラグインを使用します。これは、コントローラーノードで利用可能な ``kubectl`` コマンドラインを使用して Kubernetes API を動的にクエリーし、Ansible で管理できる Pod を示します。" - -#~ msgid "To use the Kubernetes dynamic inventory plugins, you must install `Kubernetes Python client `_, `kubectl `_ and `OpenShift Python client `_ on your control node (the host running Ansible)." -#~ msgstr "Kubernetes の動的インベントリープラグインを使用するには、`Kubernetes Python クライアント `_、`kubectl `_、および `OpenShift Python client `_ をコントロールノード (Ansible を実行するホスト) にインストールする必要があります。" - -#~ msgid "Please refer to Kubernetes official documentation for `installing kubectl `_ on the given operating systems." -#~ msgstr "該当するオペレーティングシステムでは、`kubectl のインストール `_ の Kubernetes の公式ドキュメントを参照してください。" - -#~ msgid "To use this Kubernetes dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -#~ msgstr "この Kubernetes 動的インベントリープラグインを使用するには、``ansible.cfg`` ファイルで以下を指定して、まずこれを有効にする必要があります。" - -#~ msgid "Then, create a file that ends in ``.k8s.yml`` or ``.k8s.yaml`` in your working directory." -#~ msgstr "次に、作業ディレクトリーに、名前の末尾が ``.k8s.yml`` または ``.k8s.yaml`` で終わるファイルを作成します。" - -#~ msgid "The ``community.kubernetes.k8s`` inventory plugin takes in the same authentication information as any other Kubernetes modules." -#~ msgstr "``community.kubernetes.k8s`` インベントリープラグインは、他の Kubernetes モジュールと同じ認証情報を取得します。" - -#~ msgid "Executing ``ansible-inventory --list -i .k8s.yml`` will create a list of Pods that are ready to be configured using Ansible." -#~ msgstr "``ansible-inventory --list -i .k8s.yml`` を実行すると、Ansible を使用して設定できる Pod の一覧が作成されます。" - -#~ msgid "You can also provide the namespace to gather information about specific pods from the given namespace. For example, to gather information about Pods under the ``test`` namespace you will specify the ``namespaces`` parameter:" -#~ msgstr "また、指定された名前空間から特定の Pod に関する情報を収集する名前空間を提供することもできます。たとえば、``test`` 名前空間で Pod に関する情報を収集するには、``namespaces`` パラメーターを指定します。" - -#~ msgid "Using vaulted configuration files" -#~ msgstr "Vault が設定された設定ファイルの使用" - -#~ msgid "Since the inventory configuration file contains Kubernetes related sensitive information in plain text, a security risk, you may want to encrypt your entire inventory configuration file." -#~ msgstr "インベントリー設定ファイルには、Kubernetes 関連の機密情報がプレーンテキストで含まれるため、セキュリティー上のリスクがあります。インベントリー設定ファイル全体を暗号化できます。" - -#~ msgid "You can encrypt a valid inventory configuration file as follows:" -#~ msgstr "有効なインベントリー設定ファイルは以下のように暗号化できます。" - -#~ msgid "And you can use this vaulted inventory configuration file using:" -#~ msgstr "また、以下を使用して、Vault が設定されたこのインベントリー設定ファイルを使用できます。" - -#~ msgid "`Kubernetes Python client `_" -#~ msgstr "`Kubernetes Python クライアント `_" - -#~ msgid "The GitHub Page of Kubernetes Python client" -#~ msgstr "Kubernetes Python クライアントの GitHub ページ" - -#~ msgid "`Kubernetes Python client - Issue Tracker `_" -#~ msgstr "`Kubernetes Python クライアント - Issue Tracker `_" - -#~ msgid "The issue tracker for Kubernetes Python client" -#~ msgstr "Kubernetes Python クライアントの問題トラッカー" - -#~ msgid "`OpenShift Python client `_" -#~ msgstr "`OpenShift Python クライアント `_" - -#~ msgid "The GitHub Page of OpenShift Dynamic API client" -#~ msgstr "OpenShift Dynamic API クライアントの GitHub ページ" - -#~ msgid "`OpenShift Python client - Issue Tracker `_" -#~ msgstr "`OpenShift Python クライアント - Issue Tracker `_" - -#~ msgid "The issue tracker for OpenShift Dynamic API client" -#~ msgstr "OpenShift Dynamic API クライアントの問題トラッカー" - -#~ msgid "`Kubectl installation `_" -#~ msgstr "`Kubectl インストール `_" - -#~ msgid "Installation guide for installing Kubectl" -#~ msgstr "Kubectl をインストールするためのインストールガイド" - -#~ msgid ":ref:`playbooks_vault`" -#~ msgstr ":ref:`playbooks_vault`" - -#~ msgid "Using Vault in playbooks" -#~ msgstr "Playbook での Vault の使用" - -#~ msgid "Ansible for Kubernetes Scenarios" -#~ msgstr "Kubernetes シナリオにおける Ansible" - -#~ msgid "These scenarios teach you how to accomplish common Kubernetes tasks using Ansible. To get started, please select the task you want to accomplish." -#~ msgstr "これらのシナリオは、Ansible を使用して一般的な Kubernetes タスクを実現する方法を説明します。開始するには、達成するタスクを選択してください。" - -#~ msgid "Creating K8S object" -#~ msgstr "K8S オブジェクトの作成" - -#~ msgid "This guide will show you how to utilize Ansible to create Kubernetes objects such as Pods, Deployments, and Secrets." -#~ msgstr "以下では、Ansible を使用して Pod、Deployment、Secret などの Kubernetes オブジェクトを作成する方法を説明します。" - -#~ msgid "Scenario Requirements" -#~ msgstr "シナリオの要件" - -#~ msgid "Software" -#~ msgstr "ソフトウェア" - -#~ msgid "Ansible 2.9.10 or later must be installed" -#~ msgstr "Ansible 2.9.10 以降がインストールされています。" - -#~ msgid "The Python modules ``openshift`` and ``kubernetes`` must be installed on the Ansible controller (or Target host if not executing against localhost)" -#~ msgstr "Python モジュール ``openshift`` および ``kubernetes`` は、Ansible コントローラー (またはローカルホストに対して実行されていない場合のターゲットホスト) にインストールする必要があります。" - -#~ msgid "Kubernetes Cluster" -#~ msgstr "Kubernetes クラスター" - -#~ msgid "Kubectl binary installed on the Ansible controller" -#~ msgstr "Ansible コントローラーにインストールされた Kubectl バイナリー" - -#~ msgid "Access / Credentials" -#~ msgstr "アクセス/認証情報" - -#~ msgid "Kubeconfig configured with the given Kubernetes cluster" -#~ msgstr "指定の Kubernetes クラスターで設定された kubeconfig" - -#~ msgid "Assumptions" -#~ msgstr "前提条件" - -#~ msgid "User has required level of authorization to create, delete and update resources on the given Kubernetes cluster." -#~ msgstr "ユーザーには、指定の Kubernetes クラスターでリソースを作成、削除、および更新するのに必要な承認レベルがあります。" - -#~ msgid "Caveats" -#~ msgstr "注意事項" - -#~ msgid "community.kubernetes 1.1.0 is going to migrate to `kubernetes.core `_" -#~ msgstr "community.kubernetes 1.1.0 は `kubernetes.core `_ に移行する予定です。" - -#~ msgid "Example Description" -#~ msgstr "例の説明" - -#~ msgid "In this use case / example, we will create a Pod in the given Kubernetes Cluster. The following Ansible playbook showcases the basic parameters that are needed for this." -#~ msgstr "このユースケース/サンプルでは、指定した Kubernetes Cluster に Pod を作成します。以下の Ansible Playbook では、これに必要な基本パラメーターについて取り上げます。" - -#~ msgid "Since Ansible utilizes the Kubernetes API to perform actions, in this use case we will be connecting directly to the Kubernetes cluster." -#~ msgstr "Ansible は Kubernetes API を使用してアクションを実行するため、このユースケースでは Kubernetes クラスターに直接接続します。" - -#~ msgid "To begin, there are a few bits of information we will need. Here you are using Kubeconfig which is pre-configured in your machine. The Kubeconfig is generally located at ``~/.kube/config``. It is highly recommended to store sensitive information such as password, user certificates in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_." -#~ msgstr "まず、必要な情報をいくつか紹介します。マシン内で事前設定されている Kubeconfig を使用します。Kubeconfig は通常 ``~/.kube/config`` に置かれます。パスワードやユーザー証明書などの機密情報は、:ref:`ansible-vault` または`Ansible Tower 認証情報 `_ を使用して、より安全な方法で保存することが強く推奨されます。" - -#~ msgid "Now you need to supply the information about the Pod which will be created. Using ``definition`` parameter of the ``community.kubernetes.k8s`` module, you specify `PodTemplate `_. This PodTemplate is identical to what you provide to the ``kubectl`` command." -#~ msgstr "作成される Pod に関する情報を提供する必要があります。``definition`` モジュールの ``community.kubernetes.k8s`` パラメーターを使用して `PodTemplate `_ を指定します。この PodTemplate は、``kubectl`` コマンドに指定する内容と同じです。" - -#~ msgid "What to expect" -#~ msgstr "予想されること" - -#~ msgid "You will see a bit of JSON output after this playbook completes. This output shows various parameters that are returned from the module and from cluster about the newly created Pod." -#~ msgstr "この Playbook が完了すると、JSON の出力が少し表示されます。この出力には、モジュールから返されたさまざまなパラメーターや、新たに作成された Pod に関するクラスターから返されたさまざまなパラメーターが表示されます。" - -#~ msgid "In the above example, 'changed' is ``True`` which notifies that the Pod creation started on the given cluster. This can take some time depending on your environment." -#~ msgstr "上記の例では、「changed」は ``True`` で、指定のクラスターで Pod の作成が開始されていることを通知します。これには、環境に応じて多少時間がかかる場合があります。" - -#~ msgid "Things to inspect" -#~ msgstr "調べること" - -#~ msgid "Check if the values provided for username and password are correct" -#~ msgstr "ユーザー名およびパスワードの値が正しいかどうかを確認します。" - -#~ msgid "Check if the Kubeconfig is populated with correct values" -#~ msgstr "Kubeconfig が正しい値で入力されているかどうかを確認します。" - -#~ msgid "Ansible VMware FAQ" -#~ msgstr "Ansible VMware FAQ" - -#~ msgid "vmware_guest" -#~ msgstr "vmware_guest" - -#~ msgid "Can I deploy a virtual machine on a standalone ESXi server ?" -#~ msgstr "スタンドアロンの ESXi サーバーに仮想マシンをデプロイすることはできますか。" - -#~ msgid "Yes. ``vmware_guest`` can deploy a virtual machine with required settings on a standalone ESXi server. However, you must have a paid license to deploy virtual machines this way. If you are using the free version, the API is read-only." -#~ msgstr "はい。``vmware_guest`` はスタンドアロン ESXi サーバーに必要な設定で仮想マシンをデプロイできます。ただし、この方法で仮想マシンをデプロイするには有料のライセンスが必要になります。フリーバージョンを使用している場合、API は読み取り専用です。" - -#~ msgid "Is ``/vm`` required for ``vmware_guest`` module ?" -#~ msgstr "``vmware_guest`` モジュールには ``/vm`` が必要ですか。" - -#~ msgid "Prior to Ansible version 2.5, ``folder`` was an optional parameter with a default value of ``/vm``." -#~ msgstr "Ansible バージョン 2.5 より前のバージョンでは、``folder`` は、任意のパラメーターで、デフォルト値は ``/vm`` でした。" - -#~ msgid "The folder parameter was used to discover information about virtual machines in the given infrastructure." -#~ msgstr "folder パラメーターは、指定したインフラストラクチャーの仮想マシンに関する情報を検出するために使用されます。" - -#~ msgid "Starting with Ansible version 2.5, ``folder`` is still an optional parameter with no default value. This parameter will be now used to identify a user's virtual machine, if multiple virtual machines or virtual machine templates are found with same name. VMware does not restrict the system administrator from creating virtual machines with same name." -#~ msgstr "Ansible バージョン 2.5 以降、``folder`` は、デフォルト値のない任意のパラメーターです。このパラメーターは、複数の仮想マシンまたは仮想マシンテンプレートが同じ名前で見つかった場合に、ユーザーの仮想マシンを識別するために使用されます。VMware は、システム管理者が同じ名前を持つ仮想マシンを作成することを制限していません。" - -#~ msgid "Deploy a virtual machine from a template" -#~ msgstr "テンプレートからの仮想マシンのデプロイメント" - -#~ msgid "This guide will show you how to utilize Ansible to clone a virtual machine from already existing VMware template or existing VMware guest." -#~ msgstr "本ガイドでは、Ansible を使用して、既存の VMware テンプレートまたは既存の VMware ゲストから仮想マシンのクローンを作成する方法を説明します。" - -#~ msgid "Ansible 2.5 or later must be installed" -#~ msgstr "Ansible 2.5 以降がインストールされています。" - -#~ msgid "The Python module ``Pyvmomi`` must be installed on the Ansible (or Target host if not executing against localhost)" -#~ msgstr "Python モジュール ``Pyvmomi`` を Ansible (ローカルホストに対して実行しない場合にはターゲットホスト) にインストールしている。" - -#~ msgid "Installing the latest ``Pyvmomi`` via ``pip`` is recommended [as the OS provided packages are usually out of date and incompatible]" -#~ msgstr "``pip`` を介して最新の ``Pyvmomi`` をインストールすることが推奨されます (OS 提供パッケージは通常古くなり、互換性がないため)。" - -#~ msgid "Hardware" -#~ msgstr "ハードウェア" - -#~ msgid "vCenter Server with at least one ESXi server" -#~ msgstr "ESXi サーバーが 1 台以上搭載されている vCenter Server" - -#~ msgid "Ansible (or the target server) must have network access to the either vCenter server or the ESXi server you will be deploying to" -#~ msgstr "Ansible (またはターゲットサーバー) には、デプロイする vCenter サーバーまたは ESXi サーバーへのネットワークアクセスが必要です。" - -#~ msgid "Username and Password" -#~ msgstr "ユーザー名とパスワード" - -#~ msgid "Administrator user with following privileges" -#~ msgstr "以下の権限を持つ管理ユーザー" - -#~ msgid "``Datastore.AllocateSpace`` on the destination datastore or datastore folder" -#~ msgstr "宛先データストアまたはデータストアディレクトリーの ``Datastore.AllocateSpace``" - -#~ msgid "``Network.Assign`` on the network to which the virtual machine will be assigned" -#~ msgstr "仮想マシンが割り当てられるネットワークの ``Network.Assign``" - -#~ msgid "``Resource.AssignVMToPool`` on the destination host, cluster, or resource pool" -#~ msgstr "移行先ホスト、クラスター、またはリソースプールの ``Resource.AssignVMToPool``" - -#~ msgid "``VirtualMachine.Config.AddNewDisk`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.AddNewDisk``" - -#~ msgid "``VirtualMachine.Config.AddRemoveDevice`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.AddRemoveDevice``" - -#~ msgid "``VirtualMachine.Interact.PowerOn`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.PowerOn``" - -#~ msgid "``VirtualMachine.Inventory.CreateFromExisting`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Inventory.CreateFromExisting``" - -#~ msgid "``VirtualMachine.Provisioning.Clone`` on the virtual machine you are cloning" -#~ msgstr "クローンを作成している仮想マシンの ``VirtualMachine.Provisioning.Clone``" - -#~ msgid "``VirtualMachine.Provisioning.Customize`` on the virtual machine or virtual machine folder if you are customizing the guest operating system" -#~ msgstr "ゲストオペレーティングシステムをカスタマイズしている場合は、仮想マシンまたは仮想マシンディレクトリーの ``VirtualMachine.Provisioning.Customize``" - -#~ msgid "``VirtualMachine.Provisioning.DeployTemplate`` on the template you are using" -#~ msgstr "使用しているテンプレートの ``VirtualMachine.Provisioning.DeployTemplate``" - -#~ msgid "``VirtualMachine.Provisioning.ReadCustSpecs`` on the root vCenter Server if you are customizing the guest operating system" -#~ msgstr "ゲストオペレーティングシステムをカスタマイズする場合は、ルート vCenter サーバーの ``VirtualMachine.Provisioning.ReadCustSpecs``" - -#~ msgid "Depending on your requirements, you could also need one or more of the following privileges:" -#~ msgstr "要件によっては、以下の権限が 1 つ以上必要になる場合があります。" - -#~ msgid "``VirtualMachine.Config.CPUCount`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.CPUCount``" - -#~ msgid "``VirtualMachine.Config.Memory`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Memory``" - -#~ msgid "``VirtualMachine.Config.DiskExtend`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.DiskExtend``" - -#~ msgid "``VirtualMachine.Config.Annotation`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Annotation``" - -#~ msgid "``VirtualMachine.Config.AdvancedConfig`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.AdvancedConfig``" - -#~ msgid "``VirtualMachine.Config.EditDevice`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.EditDevice``" - -#~ msgid "``VirtualMachine.Config.Resource`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Resource``" - -#~ msgid "``VirtualMachine.Config.Settings`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.Settings``" - -#~ msgid "``VirtualMachine.Config.UpgradeVirtualHardware`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Config.UpgradeVirtualHardware``" - -#~ msgid "``VirtualMachine.Interact.SetCDMedia`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.SetCDMedia``" - -#~ msgid "``VirtualMachine.Interact.SetFloppyMedia`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.SetFloppyMedia``" - -#~ msgid "``VirtualMachine.Interact.DeviceConnection`` on the datacenter or virtual machine folder" -#~ msgstr "データセンターまたは仮想マシンディレクトリーの ``VirtualMachine.Interact.DeviceConnection``" - -#~ msgid "All variable names and VMware object names are case sensitive" -#~ msgstr "変数名および VMware オブジェクト名はすべて大文字と小文字を区別します。" - -#~ msgid "VMware allows creation of virtual machine and templates with same name across datacenters and within datacenters" -#~ msgstr "VMware では、データセンター間およびデータセンター内で、同じ名前の仮想マシンおよびテンプレートを作成できます。" - -#~ msgid "You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviours" -#~ msgstr "``validate_certs`` オプションを使用するには、Python 2.7.9 バージョンを使用する必要があります。このバージョンは、SSL 検証の動作を変更できるためです。" - -#~ msgid "Hosts in the ESXi cluster must have access to the datastore that the template resides on." -#~ msgstr "ESXi クラスター内のホストが、テンプレートが存在するデータストアにアクセスできる必要があります。" - -#~ msgid "Multiple templates with the same name will cause module failures." -#~ msgstr "同じ名前のテンプレートが複数存在する場合、モジュールは失敗します。" - -#~ msgid "In order to utilize Guest Customization, VMware Tools must be installed on the template. For Linux, the ``open-vm-tools`` package is recommended, and it requires that ``Perl`` be installed." -#~ msgstr "ゲストのカスタマイズを使用するには、VMware Tool をテンプレートにインストールする必要があります。Linux の場合は ``open-vm-tools`` パッケージが推奨され、``Perl`` がインストールされている必要があります。" - -#~ msgid "In this use case / example, we will be selecting a virtual machine template and cloning it into a specific folder in our Datacenter / Cluster. The following Ansible playbook showcases the basic parameters that are needed for this." -#~ msgstr "このユースケースまたはサンプルでは、仮想マシンテンプレートを選択し、データセンター/クラスターの特定のディレクトリーにクローンを作成します。以下の Ansible Playbook では、これに必要な基本的なパラメーターについて取り上げます。" - -#~ msgid "Since Ansible utilizes the VMware API to perform actions, in this use case we will be connecting directly to the API from our localhost. This means that our playbooks will not be running from the vCenter or ESXi Server. We do not necessarily need to collect facts about our localhost, so the ``gather_facts`` parameter will be disabled. You can run these modules against another server that would then connect to the API if your localhost does not have access to vCenter. If so, the required Python modules will need to be installed on that target server." -#~ msgstr "Ansible は VMware API を使用してアクションを実行するため、このユースケースではローカルホストから直接 API に接続します。つまり、Playbook は vCenter または ESXi サーバーから実行しないことを意味します。必ずしもローカルホストに関するファクトを収集する必要がないため、``gather_facts`` パラメーターは無効になります。ローカルホストが vCenter にアクセスできない場合は、API に接続する別のサーバーに対してこれらのモジュールを実行することができます。その場合は、必要な Python モジュールを、そのターゲットサーバーにインストールする必要があります。" - -#~ msgid "To begin, there are a few bits of information we will need. First and foremost is the hostname of the ESXi server or vCenter server. After this, you will need the username and password for this server. For now, you will be entering these directly, but in a more advanced playbook this can be abstracted out and stored in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_. If your vCenter or ESXi server is not setup with proper CA certificates that can be verified from the Ansible server, then it is necessary to disable validation of these certificates by using the ``validate_certs`` parameter. To do this you need to set ``validate_certs=False`` in your playbook." -#~ msgstr "まず、いくつかの情報が必要になります。まず第一に、ESXi サーバーのホスト名または vCenter サーバーのホスト名です。その後、このサーバーのユーザー名とパスワードが必要になります。ここでは、これらを直接入力しますが、より高度な Playbook ではこの情報を抽象化し、:ref:`ansible-vault` または `Ansible Tower 認証情報 `_ を使用して、よりセキュアな方法で保存することができます。vCenter サーバーまたは ESXi サーバーに、Ansible サーバーから検証可能な適切な CA 証明書が設定されていない場合は、``validate_certs`` パラメーターを使用してこれらの証明書の検証を無効にする必要があります。そのためには、Playbook で ``validate_certs=False`` を設定する必要があります。" - -#~ msgid "Now you need to supply the information about the virtual machine which will be created. Give your virtual machine a name, one that conforms to all VMware requirements for naming conventions. Next, select the display name of the template from which you want to clone new virtual machine. This must match what's displayed in VMware Web UI exactly. Then you can specify a folder to place this new virtual machine in. This path can either be a relative path or a full path to the folder including the Datacenter. You may need to specify a state for the virtual machine. This simply tells the module which action you want to take, in this case you will be ensure that the virtual machine exists and is powered on. An optional parameter is ``wait_for_ip_address``, this will tell Ansible to wait for the virtual machine to fully boot up and VMware Tools is running before completing this task." -#~ msgstr "ここで、作成される仮想マシンに関する情報を入力する必要があります。仮想マシンの名前は、VMware が要求する命名規則に準拠したものにしてください。次に、新しい仮想マシンのクローンを作成するテンプレートの表示名を選択します。これは、VMware Web UI に表示される内容に一致する必要があります。次に、この新しい仮想マシンを配置するディレクトリーを指定します。このパスは、相対パスでも、データセンターを含むディレクトリーへの完全パスでも構いません。仮想マシンの状態を指定しないといけない場合があります。これは単に、実行するアクションをモジュールに指示するだけです。この場合は、仮想マシンが存在することと、電源がオンになっていることを確認します。任意のパラメーターは ``wait_for_ip_address`` です。これにより、このタスクを完了する前に、仮想マシンが完全に起動し、VMware Tools が実行するのを待つよう Ansible に指示します。" - -#~ msgid "You will see a bit of JSON output after this playbook completes. This output shows various parameters that are returned from the module and from vCenter about the newly created VM." -#~ msgstr "この Playbook が完了すると、JSON の出力が少し表示されます。この出力には、モジュールから返されたさまざまなパラメーターや、新たに作成された仮想マシンに関する vCenter から返されたさまざまなパラメーターが表示されます。" - -#~ msgid "State is changed to ``True`` which notifies that the virtual machine is built using given template. The module will not complete until the clone task in VMware is finished. This can take some time depending on your environment." -#~ msgstr "状態が ``True`` に変更され、仮想マシンが指定のテンプレートを使用して構築されることを通知します。モジュールは、VMware のクローンタスクが終了するまで完了しません。これは環境に応じて多少時間がかかる場合があります。" - -#~ msgid "If you utilize the ``wait_for_ip_address`` parameter, then it will also increase the clone time as it will wait until virtual machine boots into the OS and an IP Address has been assigned to the given NIC." -#~ msgstr "``wait_for_ip_address`` パラメーターを使用すると、仮想マシンが OS で起動し、指定の NIC に IP アドレスが割り当てられるまで待機するため、クローンを作成する時間も長くなります。" - -#~ msgid "Check if the datacenter you provided is available" -#~ msgstr "指定したデータセンターが利用可能かどうかを確認します。" - -#~ msgid "Check if the template specified exists and you have permissions to access the datastore" -#~ msgstr "指定したテンプレートが存在しているかどうか、およびデータストアにアクセスするパーミッションがあるかどうかを確認します。" - -#~ msgid "Ensure the full folder path you specified already exists. It will not create folders automatically for you" -#~ msgstr "指定した完全なディレクトリーパスが存在することを確認してください。ディレクトリーは自動的に作成されません" - -#~ msgid "Find folder path of an existing VMware virtual machine" -#~ msgstr "既存の VMware 仮想マシンのディレクトリーパスの検索" - -#~ msgid "This guide will show you how to utilize Ansible to find folder path of an existing VMware virtual machine." -#~ msgstr "本ガイドでは、Ansible を使用して既存の VMware 仮想マシンのディレクトリーパスを検索する方法を説明します。" - -#~ msgid "Ansible 2.5 or later must be installed." -#~ msgstr "Ansible 2.5 以降がインストールされている必要があります。" - -#~ msgid "The Python module ``Pyvmomi`` must be installed on the Ansible control node (or Target host if not executing against localhost)." -#~ msgstr "Ansible コントロールノード (またはローカルホストで実行していない場合はターゲットホスト) に、Python モジュール ``Pyvmomi`` をインストールしている必要があります。" - -#~ msgid "We recommend installing the latest version with pip: ``pip install Pyvmomi`` (as the OS packages are usually out of date and incompatible)." -#~ msgstr "pip で最新版をインストール (``pip install Pyvmomi``) することが推奨されます (OSのパッケージはたいてい古くて互換性がないため)。" - -#~ msgid "At least one standalone ESXi server or" -#~ msgstr "少なくともスタンドアロンの ESXi サーバー 1 台、または" - -#~ msgid "Ansible (or the target server) must have network access to the either vCenter server or the ESXi server" -#~ msgstr "Ansible (またはターゲットサーバー) には、vCenter サーバーまたは ESXi サーバーへのネットワークアクセスが必要です。" - -#~ msgid "Username and Password for vCenter or ESXi server" -#~ msgstr "vCenter サーバーまたは ESXi サーバーのユーザー名およびパスワード" - -#~ msgid "All variable names and VMware object names are case sensitive." -#~ msgstr "変数名および VMware オブジェクト名はすべて大文字と小文字を区別します。" - -#~ msgid "You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviours." -#~ msgstr "``validate_certs`` オプションを使用するには、Python 2.7.9 バージョンを使用する必要があります。このバージョンは、SSL 検証の動作を変更できるためです。" - -#~ msgid "With the following Ansible playbook you can find the folder path of an existing virtual machine using name." -#~ msgstr "次の Ansible Playbook では、名前を使用して既存の仮想マシンのディレクトリーパスを検索できます。" - -#~ msgid "Since Ansible utilizes the VMware API to perform actions, in this use case it will be connecting directly to the API from localhost." -#~ msgstr "Ansible は VMware API を使用してアクションを実行するため、このユースケースではローカルホストから API に直接接続されます。" - -#~ msgid "This means that playbooks will not be running from the vCenter or ESXi Server." -#~ msgstr "つまり、Playbook は vCenter サーバーまたは ESXi サーバーから実行されないことを示しています。" - -#~ msgid "Note that this play disables the ``gather_facts`` parameter, since you don't want to collect facts about localhost." -#~ msgstr "ローカルホストに関するファクトを収集しないため、このプレイは ``gather_facts`` パラメーターを無効にすることに注意してください。" - -#~ msgid "You can run these modules against another server that would then connect to the API if localhost does not have access to vCenter. If so, the required Python modules will need to be installed on that target server. We recommend installing the latest version with pip: ``pip install Pyvmomi`` (as the OS packages are usually out of date and incompatible)." -#~ msgstr "ローカルホストが vCenter サーバーにアクセスできない場合は、API に接続する別のサーバーに対してこのモジュールを実行できます。その場合は、必要な Python モジュールをターゲットサーバーにインストールする必要があります。pip で最新バージョンをインストールすることが推奨されます。インストールするには ``pip install Pyvmomi`` を実行してください (通常は OS パッケージが古く、互換性がないため)。" - -#~ msgid "Before you begin, make sure you have:" -#~ msgstr "開始する前に、以下の点を確認してください。" - -#~ msgid "Hostname of the ESXi server or vCenter server" -#~ msgstr "ESXi サーバーまたは vCenter サーバーのホスト名" - -#~ msgid "Username and password for the ESXi or vCenter server" -#~ msgstr "ESXi サーバーまたは vCenter サーバーのユーザー名およびパスワード" - -#~ msgid "Name of the existing Virtual Machine for which you want to collect folder path" -#~ msgstr "ディレクトリーパスを収集する既存の仮想マシンの名前" - -#~ msgid "For now, you will be entering these directly, but in a more advanced playbook this can be abstracted out and stored in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_." -#~ msgstr "ここでは、これらを直接入力しますが、より高度な Playbook では :ref:`ansible-vault` または `Ansible Tower 認証情報 `_ を使用して、よりセキュアな方法で保存することができます。" - -#~ msgid "If your vCenter or ESXi server is not setup with proper CA certificates that can be verified from the Ansible server, then it is necessary to disable validation of these certificates by using the ``validate_certs`` parameter. To do this you need to set ``validate_certs=False`` in your playbook." -#~ msgstr "vCenter サーバーまたは ESXi サーバーが Ansible サーバーから検証できる適切な CA 証明書で設定されていない場合は、``validate_certs`` パラメーターを使用してこれらの証明書の検証を無効にする必要があります。これを行うには、Playbook で ``validate_certs=False`` を設定する必要があります。" - -#~ msgid "The name of existing virtual machine will be used as input for ``vmware_guest_find`` module via ``name`` parameter." -#~ msgstr "既存の仮想マシンの名前は、``vmware_guest_find`` パラメーターにより ``name`` モジュールの入力として使用されます。" - -#~ msgid "Running this playbook can take some time, depending on your environment and network connectivity. When the run is complete you will see" -#~ msgstr "ご使用の環境およびネットワーク接続によっては、この Playbook の実行に時間がかかる場合があります。実行が完了すると、以下のようになります。" - -#~ msgid "If your playbook fails:" -#~ msgstr "Playbook が失敗した場合は、以下を行います。" - -#~ msgid "Check if the values provided for username and password are correct." -#~ msgstr "ユーザー名およびパスワードの値が正しいことを確認します。" - -#~ msgid "Check if the datacenter you provided is available." -#~ msgstr "指定したデータセンターが利用可能かどうかを確認します。" - -#~ msgid "Check if the virtual machine specified exists and you have respective permissions to access VMware object." -#~ msgstr "指定した仮想マシンが存在しているかどうか、および VMware オブジェクトにアクセスする各パーミッションがあるかどうかを確認します。" - -#~ msgid "Ensure the full folder path you specified already exists." -#~ msgstr "指定したディレクトリーの完全パスが存在していることを確認します。" - -#~ msgid "Remove an existing VMware virtual machine" -#~ msgstr "既存の VMware 仮想マシンの削除" - -#~ msgid "This guide will show you how to utilize Ansible to remove an existing VMware virtual machine." -#~ msgstr "本ガイドでは、Ansible を使用して既存の VMware 仮想マシンを削除する方法を説明します。" - -#~ msgid "``vmware_guest`` module tries to mimic VMware Web UI and workflow, so the virtual machine must be in powered off state in order to remove it from the VMware inventory." -#~ msgstr "``vmware_guest`` モジュールは、VMware Web UI およびワークフローを模倣するため、VMware インベントリーから仮想マシンを削除するには、電源がオフになっている必要があります。" - -#~ msgid "The removal VMware virtual machine using ``vmware_guest`` module is destructive operation and can not be reverted, so it is strongly recommended to take the backup of virtual machine and related files (vmx and vmdk files) before proceeding." -#~ msgstr "``vmware_guest`` モジュールを使用して VMware 仮想マシンを削除することは破壊的な操作であり、元に戻すことができないため、先に進む前に仮想マシンと関連ファイル (vmx ファイルおよび vmdk ファイル) のバックアップを作成することが強く推奨されます。" - -#~ msgid "In this use case / example, user will be removing a virtual machine using name. The following Ansible playbook showcases the basic parameters that are needed for this." -#~ msgstr "このユースケースまたはサンプルでは、ユーザーが名前を使用して仮想マシンを削除します。以下の Ansible Playbook では、このように削除するのに必要な基本パラメーターについて取り上げます。" - -#~ msgid "Name of the existing Virtual Machine you want to remove" -#~ msgstr "削除する既存の仮想マシンの名前" - -#~ msgid "The name of existing virtual machine will be used as input for ``vmware_guest`` module via ``name`` parameter." -#~ msgstr "既存の仮想マシンの名前は、``vmware_guest`` パラメーターにより ``name`` モジュールの入力として使用されます。" - -#~ msgid "You will not see any JSON output after this playbook completes as compared to other operations performed using ``vmware_guest`` module." -#~ msgstr "``vmware_guest`` モジュールを使用して実行した他の操作と異なり、この Playbook が完了しても、JSON 出力は表示されません。" - -#~ msgid "State is changed to ``True`` which notifies that the virtual machine is removed from the VMware inventory. This can take some time depending upon your environment and network connectivity." -#~ msgstr "状態が ``True`` に変更になり、仮想マシンが VMware インベントリーから削除されたことが通知されます。この処理には、ご使用の環境やネットワーク接続によっては時間がかかる場合があります。" - -#~ msgid "Check if the virtual machine specified exists and you have permissions to access the datastore." -#~ msgstr "指定した仮想マシンが存在しているかどうか、およびデータストアにアクセスするパーミッションがあるかどうかを確認します。" - -#~ msgid "Ensure the full folder path you specified already exists. It will not create folders automatically for you." -#~ msgstr "指定した完全なディレクトリーパスが存在することを確認してください。ディレクトリーは自動的に作成されません。" - -#~ msgid "Rename an existing virtual machine" -#~ msgstr "既存の仮想マシンの名前変更" - -#~ msgid "This guide will show you how to utilize Ansible to rename an existing virtual machine." -#~ msgstr "本ガイドでは、Ansible を使用して既存の仮想マシンの名前を変更する方法を説明します。" - -#~ msgid "With the following Ansible playbook you can rename an existing virtual machine by changing the UUID." -#~ msgstr "以下の Ansible Playbook を使用して、UUID を変更して既存の仮想マシンの名前を変更できます。" - -#~ msgid "The UUID of the existing Virtual Machine you want to rename" -#~ msgstr "名前を変更する既存の仮想マシンの UUID" - -#~ msgid "Now you need to supply the information about the existing virtual machine which will be renamed. For renaming virtual machine, ``vmware_guest`` module uses VMware UUID, which is unique across vCenter environment. This value is autogenerated and can not be changed. You will use ``vmware_guest_facts`` module to find virtual machine and get information about VMware UUID of the virtual machine." -#~ msgstr "ここで、名前を変更する既存の仮想マシンの情報を入力する必要があります。仮想マシンの名前を変更するために、``vmware_guest`` モジュールは vCenter 環境全体で一意となる VMware UUID を使用します。この値は自動生成され、変更はできません。``vmware_guest_facts`` モジュールを使用して、仮想マシンの VMware UUID に関する情報を取得します。" - -#~ msgid "This value will be used input for ``vmware_guest`` module. Specify new name to virtual machine which conforms to all VMware requirements for naming conventions as ``name`` parameter. Also, provide ``uuid`` as the value of VMware UUID." -#~ msgstr "この値は、``vmware_guest`` モジュールの入力を使用します。``name`` パラメーターとして命名規則のすべての VMware 要件に準拠する仮想マシンに新しい名前を指定します。また、``uuid`` を VMware UUID の値として指定します。" - -#~ msgid "confirming that you've renamed the virtual machine." -#~ msgstr "仮想マシンの名前が変更されたことを確認します。" - -#~ msgid "Using VMware HTTP API using Ansible" -#~ msgstr "Ansible を使用した VMware HTTP API の使用" - -#~ msgid "This guide will show you how to utilize Ansible to use VMware HTTP APIs to automate various tasks." -#~ msgstr "本書では、Ansible で VMware HTTP API を使用してさまざまなタスクを自動化する方法を説明します。" - -#~ msgid "We recommend installing the latest version with pip: ``pip install Pyvmomi`` on the Ansible control node (as the OS packages are usually out of date and incompatible) if you are planning to use any existing VMware modules." -#~ msgstr "既存の VMware モジュールを使用する予定がある場合は、Ansible コントロールノードで pip を使用して最新版をインストール (``pip install Pyvmomi``) することが推奨されます (OS のパッケージはたいてい古くて互換性がないため)。" - -#~ msgid "vCenter Server 6.5 and above with at least one ESXi server" -#~ msgstr "少なくとも 1 台の ESXi サーバーを備えた vCenter Server 6.5 以降" - -#~ msgid "Ansible (or the target server) must have network access to either the vCenter server or the ESXi server" -#~ msgstr "Ansible (またはターゲットサーバー) には、vCenter サーバーまたは ESXi サーバーへのネットワークアクセスが必要です。" - -#~ msgid "Username and Password for vCenter" -#~ msgstr "vCenter のユーザー名およびパスワード" - -#~ msgid "VMware HTTP APIs are introduced in vSphere 6.5 and above so minimum level required in 6.5." -#~ msgstr "VMware HTTP API は、vSphere 6.5 以降で導入され、6.5 以上のレベルが必要です。" - -#~ msgid "There are very limited number of APIs exposed, so you may need to rely on XMLRPC based VMware modules." -#~ msgstr "公開される API の数は非常に限られているため、XMLRPC ベースの VMware モジュールが必要になる場合があります。" - -#~ msgid "With the following Ansible playbook you can find the VMware ESXi host system(s) and can perform various tasks depending on the list of host systems. This is a generic example to show how Ansible can be utilized to consume VMware HTTP APIs." -#~ msgstr "以下の Ansible Playbook を使用すると、VMware ESXi ホストシステムを見つけ、ホストシステムの一覧に応じてさまざまなタスクを実行できます。これは、Ansible を使用して VMware HTTP API をどのように消費するかを示す一般的な例です。" - -#~ msgid "Since Ansible utilizes the VMware HTTP API using the ``uri`` module to perform actions, in this use case it will be connecting directly to the VMware HTTP API from localhost." -#~ msgstr "Ansible は ``uri`` モジュールを使用してアクションを実行するために VMware HTTP API を利用して、このユースケースでは、ローカルホストから VMware HTTP API に直接接続されます。" - -#~ msgid "Hostname of the vCenter server" -#~ msgstr "vCenter サーバーのホスト名" - -#~ msgid "Username and password for the vCenter server" -#~ msgstr "vCenter サーバーのユーザー名およびパスワード" - -#~ msgid "Version of vCenter is at least 6.5" -#~ msgstr "vCenter のバージョンは 6.5 以上" - -#~ msgid "If your vCenter server is not setup with proper CA certificates that can be verified from the Ansible server, then it is necessary to disable validation of these certificates by using the ``validate_certs`` parameter. To do this you need to set ``validate_certs=False`` in your playbook." -#~ msgstr "vCenter サーバーが Ansible サーバーから検証できる適切な CA 証明書で設定されていない場合は、``validate_certs`` パラメーターを使用してこれらの証明書の検証を無効にする必要があります。これを行うには、Playbook で ``validate_certs=False`` を設定する必要があります。" - -#~ msgid "As you can see, we are using the ``uri`` module in first task to login into the vCenter server and storing result in the ``login`` variable using register. In the second task, using cookies from the first task we are gathering information about the ESXi host system." -#~ msgstr "ご覧のとおり、最初のタスクで ``uri`` モジュールを使用して vCenter サーバーにログインし、登録を使用して ``login`` 変数に結果を保存しています。次のタスクでは、最初のタスクの Cookie を使用して ESXi ホストシステムに関する情報を収集します。" - -#~ msgid "Using this information, we are changing the ESXi host system's advance configuration." -#~ msgstr "この情報を使用して、ESXi ホストシステムの事前設定を変更します。" - -#~ msgid "Check if you are using vCenter 6.5 and onwards to use this HTTP APIs." -#~ msgstr "この HTTP API を使用するために、vCenter 6.5 以降を使用しているかどうかを確認します。" - -#~ msgid "`VMware vSphere and Ansible From Zero to Useful by @arielsanchezmor `_" -#~ msgstr "`VMware vSphere and Ansible From Zero to Useful by @arielsanchezmor `_" - -#~ msgid "vBrownBag session video related to VMware HTTP APIs" -#~ msgstr "VMware HTTP API に関連する vBrownBag セッションビデオ" - -#~ msgid "`Sample Playbooks for using VMware HTTP APIs `_" -#~ msgstr "`Sample Playbooks for using VMware HTTP APIs `_" - -#~ msgid "GitHub repo for examples of Ansible playbook to manage VMware using HTTP APIs" -#~ msgstr "HTTP API を使用して VMware を管理する Ansible Playbook 例の GitHub リポジトリー" - -#~ msgid "Using vmware_tools connection plugin" -#~ msgstr "vmware_tools 接続プラグインの使用" - -#~ msgid "This guide will show you how to utilize VMware Connection plugin to communicate and automate various tasks on VMware guest machines." -#~ msgstr "本ガイドでは、VMware Connection プラグインを使用して、VMware ゲストマシンでさまざまなタスクと通信し、自動化する方法を説明します。" - -#~ msgid "Ansible 2.9 or later must be installed." -#~ msgstr "Ansible 2.9 以降がインストールされている必要があります。" - -#~ msgid "vCenter Server 6.5 and above" -#~ msgstr "vCenter Server 6.5 以降" - -#~ msgid "Ansible (or the target server) must have network access to either the vCenter server" -#~ msgstr "Ansible (またはターゲットサーバー) には、いずれかの vCenter サーバーへのネットワークアクセスが必要です。" - -#~ msgid "Username and Password for vCenter with required permissions" -#~ msgstr "必要なパーミッションを持つ vCenter のユーザー名およびパスワード" - -#~ msgid "VMware tools or openvm-tools with required dependencies like Perl installed on the given virtual machine" -#~ msgstr "指定の仮想マシンにインストールされている Perl などの必要な依存関係のある VMware ツールまたは openvm-tools" - -#~ msgid "You need to use Python 2.7.9 version in order to use ``validate_certs`` option, as this version is capable of changing the SSL verification behaviors." -#~ msgstr "``validate_certs`` オプションを使用するには、Python 2.7.9 バージョンを使用する必要があります。このバージョンは、SSL 検証の動作を変更できるためです。" - -#~ msgid "User can run playbooks against VMware virtual machines using ``vmware_tools`` connection plugin." -#~ msgstr "ユーザーは、``vmware_tools`` 接続プラグインを使用して VMware 仮想マシンに対して Playbook を実行できます。" - -#~ msgid "In order work with ``vmware_tools`` connection plugin, you will need to specify hostvars for the given virtual machine." -#~ msgstr "``vmware_tools`` 接続プラグインと連携するには、指定の仮想マシンの hostvar を指定する必要があります。" - -#~ msgid "For example, if you want to run a playbook on a virtual machine called ``centos_7`` located at ``/Asia-Datacenter1/prod/centos_7`` in the given vCenter, you will need to specify hostvars as follows:" -#~ msgstr "たとえば、指定の vCenter の ``/Asia-Datacenter1/prod/centos_7`` にある ``centos_7`` という名前の仮想マシンで Playbook を実行する場合は、以下のように hostvars を指定する必要があります。" - -#~ msgid "Here, we are providing vCenter details and credentials for the given virtual machine to run the playbook on. If your virtual machine path is ``Asia-Datacenter1/prod/centos_7``, you specify ``ansible_vmware_guest_path`` as ``Asia-Datacenter1/vm/prod/centos_7``. Please take a note that ``/vm`` is added in the virtual machine path, since this is a logical folder structure in the VMware inventory." -#~ msgstr "ここでは、Playbook を実行するために、指定した仮想マシンの vCenter の詳細と認証情報を提供しています。仮想マシンのパスが ``Asia-Datacenter1/prod/centos_7`` の場合は、``ansible_vmware_guest_path`` を ``Asia-Datacenter1/vm/prod/centos_7`` として指定します。仮想マシンのパスに ``/vm`` が追加されている点に注意してください。これは、VMware インベントリー内が論理的なディレクトリー構造であるためです。" - -#~ msgid "Let us now run following playbook," -#~ msgstr "以下の Playbook を実行します。" - -#~ msgid "Since Ansible utilizes the ``vmware-tools`` or ``openvm-tools`` service capabilities running in the virtual machine to perform actions, in this use case it will be connecting directly to the guest machine." -#~ msgstr "Ansible は仮想マシンで実行している ``vmware-tools`` または ``openvm-tools`` のサービス機能を使用してアクションを実行するため、このユースケースではゲストマシンに直接接続されます。" - -#~ msgid "For now, you will be entering credentials in plain text, but in a more advanced playbook this can be abstracted out and stored in a more secure fashion using :ref:`ansible-vault` or using `Ansible Tower credentials `_." -#~ msgstr "ここでは、プレーンテキストで認証情報を入力しますが、より高度な Playbook では、:ref:`ansible-vault` または `Ansible Tower 認証情報 `_ を使用してよりセキュアな方法で抽象化および保存できます。" - -#~ msgid "Running this playbook can take some time, depending on your environment and network connectivity. When the run is complete you will see:" -#~ msgstr "ご使用の環境およびネットワーク接続によっては、この Playbook の実行に時間がかかる場合があります。実行が完了すると、以下のようになります。" - -#~ msgid "Check if the path of virtual machine is correct. Please mind that ``/vm/`` needs to be provided while specifying virtual machine location." -#~ msgstr "仮想マシンのパスが正しいかどうかを確認します。仮想マシンの場所を指定する際に、``/vm/`` を提供する必要があることに注意してください。" - -#~ msgid "Ansible for VMware Concepts" -#~ msgstr "VMware 向け Ansible の概念" - -#~ msgid "Some of these concepts are common to all uses of Ansible, including VMware automation; some are specific to VMware. You need to understand them to use Ansible for VMware automation. This introduction provides the background you need to follow the :ref:`scenarios` in this guide." -#~ msgstr "これらの概念の中には、VMware の自動化を含む Ansible のすべての用途に共通するものもあれば、VMware に固有のものもあります。VMware の自動化に Ansible を使用するには、これらの概念を理解する必要があります。この章では、本ガイドの :ref:`シナリオ` に従うために必要な背景を説明します。" - -#~ msgid "Control Node" -#~ msgstr "コントロールノード" - -#~ msgid "Any machine with Ansible installed. You can run commands and playbooks, invoking ``/usr/bin/ansible`` or ``/usr/bin/ansible-playbook``, from any control node. You can use any computer that has Python installed on it as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes." -#~ msgstr "Ansible がインストールされているマシン。どのコントロールノードから でも``/usr/bin/ansible`` または ``/usr/bin/ansible-playbook`` を起動して、コマンドや Playbook を実行できます。コントロールノードとして使用し、Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。コントロールノードは複数使用できます。" - -#~ msgid "Delegation" -#~ msgstr "委譲" - -#~ msgid "Delegation allows you to select the system that executes a given task. If you do not have ``pyVmomi`` installed on your control node, use the ``delegate_to`` keyword on VMware-specific tasks to execute them on any host where you have ``pyVmomi`` installed." -#~ msgstr "委譲を使用すると、特定のタスクを実行するシステムを選択できます。コントロールノードに ``pyVmomi`` がインストールされていない場合は、VMware 固有のタスクで ``delegate_to`` キーワードを使用して、``pyVmomi`` がインストールされている任意のホストで実行します。" - -#~ msgid "Modules" -#~ msgstr "モジュール" - -#~ msgid "The units of code Ansible executes. Each module has a particular use, from creating virtual machines on vCenter to managing distributed virtual switches in the vCenter environment. You can invoke a single module with a task, or invoke several different modules in a playbook. For an idea of how many modules Ansible includes, take a look at the :ref:`list of cloud modules`, which includes VMware modules." -#~ msgstr "Ansible が実行するコードの単位。各モジュールには、vCenter での仮想マシンの作成から、vCenter 環境における分散型仮想スイッチの管理まで、特定の用途があります。単一のモジュールを呼び出すか、Playbook でいくつかの異なるモジュールを呼び出します。Ansible に含まれるモジュール数を理解するには、VMware モジュールを含む「:ref:`クラウドモジュールのリスト`」を参照してください。" - -#~ msgid "Playbooks" -#~ msgstr "Playbook" - -#~ msgid "Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand." -#~ msgstr "順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。" - -#~ msgid "pyVmomi" -#~ msgstr "pyVmomi" - -#~ msgid "Ansible VMware modules are written on top of `pyVmomi `_. ``pyVmomi`` is the official Python SDK for the VMware vSphere API that allows user to manage ESX, ESXi, and vCenter infrastructure." -#~ msgstr "Ansible VMware モジュールは、`pyVmomi `_ に記述されています。``pyVmomi`` は、VMware vSphere API の公式 Python SDK で、ユーザーが ESX、ESXi、および vCenter インフラストラクチャーを管理できるようになります。" - -#~ msgid "You need to install this Python SDK on host from where you want to invoke VMware automation. For example, if you are using control node then ``pyVmomi`` must be installed on control node." -#~ msgstr "VMware の自動化を呼び出すホストに、この Python SDK をインストールする必要があります。たとえば、コントロールノードを使用している場合は、``pyVmomi`` をコントロールノードにインストールする必要があります。" - -#~ msgid "If you are using any ``delegate_to`` host which is different from your control node then you need to install ``pyVmomi`` on that ``delegate_to`` node." -#~ msgstr "コントロールノードとは異なる ``delegate_to`` ホストを使用している場合は、その ``delegate_to`` ノードに ``pyVmomi`` をインストールする必要があります。" - -#~ msgid "You can install pyVmomi using pip:" -#~ msgstr "pip を使用して pyVmomi をインストールできます。" - -#~ msgid "Other useful VMware resources" -#~ msgstr "他の便利な VMware リソース" - -#~ msgid "`VMware API and SDK Documentation `_" -#~ msgstr "`VMware API and SDK Documentation `_" - -#~ msgid "`VCSIM test container image `_" -#~ msgstr "`VCSIM test container image `_" - -#~ msgid "`Ansible VMware community wiki page `_" -#~ msgstr "`Ansible VMware community wiki page `_" - -#~ msgid "`VMware's official Guest Operating system customization matrix `_" -#~ msgstr "`VMware's official Guest Operating system customization matrix `_" - -#~ msgid "`VMware Compatibility Guide `_" -#~ msgstr "`VMware Compatibility Guide `_" - -#~ msgid "Getting Started with Ansible for VMware" -#~ msgstr "VMware 向け Ansible の概要" - -#~ msgid "This will have a basic \"hello world\" scenario/walkthrough that gets the user introduced to the basics." -#~ msgstr "ここでは、基本動作を説明する基本的な「hello world」シナリオおよびウォークスルーを紹介します。" - -#~ msgid "Introduction to Ansible for VMware" -#~ msgstr "VMware 向け Ansible の概要" - -#~ msgid "Ansible provides various modules to manage VMware infrastructure, which includes datacenter, cluster, host system and virtual machine." -#~ msgstr "Ansible は、データセンター、クラスター、ホストシステム、仮想マシンを含む VMware インフラストラクチャーを管理するさまざまなモジュールを提供します。" - -#~ msgid "Ansible VMware modules are written on top of `pyVmomi `_. pyVmomi is the Python SDK for the VMware vSphere API that allows user to manage ESX, ESXi, and vCenter infrastructure. You can install pyVmomi using pip:" -#~ msgstr "Ansible VMware モジュールは `pyVmomi `_ に記述されています。pyVmomi は VMware vSphere API の Python SDK で、ユーザーが ESX、ESXi、および vCenter インフラストラクチャーを管理できるようにします。pip を使用して pyVmomi をインストールできます。" - -#~ msgid "Ansible VMware modules leveraging latest vSphere(6.0+) features are using `vSphere Automation Python SDK `_. The vSphere Automation Python SDK also has client libraries, documentation, and sample code for VMware Cloud on AWS Console APIs, NSX VMware Cloud on AWS integration APIs, VMware Cloud on AWS site recovery APIs, NSX-T APIs." -#~ msgstr "最新の vSphere (6.0 以降) 機能を使用する Ansible VMware モジュールは、`vSphere Automation Python SDK `_ を使用しています。VSphere Automation Python SDK には、AWS Console API 向け VMware Cloud、AWS 統合 API 向け NSX VMware Cloud、AWS サイトリカバリー API 向け VMware Cloud、NSX-T API のクライアントライブラリー、ドキュメント、サンプルコードもあります。" - -#~ msgid "You can install vSphere Automation Python SDK using pip:" -#~ msgstr "VSphere Automation Python SDK は、pip を使用してインストールできます。" - -#~ msgid "Note:" -#~ msgstr "注記:" - -#~ msgid "Installing vSphere Automation Python SDK also installs ``pyvmomi``. A separate installation of ``pyvmomi`` is not required." -#~ msgstr "vSphere Automation Python SDK をインストールすると、``pyvmomi`` もインストールされます。``pyvmomi`` の個別インストールは必要ありません。" - -#~ msgid "vmware_guest module" -#~ msgstr "vmware_guest モジュール" - -#~ msgid "The :ref:`vmware_guest` module manages various operations related to virtual machines in the given ESXi or vCenter server." -#~ msgstr ":ref:`vmware_guest` モジュールは、指定の ESXi または vCenter サーバーで仮想マシンに関連するさまざまな操作を管理します。" - -#~ msgid "`pyVmomi `_" -#~ msgstr "`pyVmomi `_" - -#~ msgid "The GitHub Page of pyVmomi" -#~ msgstr "pyVmomi の GitHub ページ" - -#~ msgid "`pyVmomi Issue Tracker `_" -#~ msgstr "`pyVmomi Issue Tracker `_" - -#~ msgid "The issue tracker for the pyVmomi project" -#~ msgstr "pyVmomi プロジェクトの問題トラッカー" - -#~ msgid "`govc `_" -#~ msgstr "`govc `_" - -#~ msgid "govc is a vSphere CLI built on top of govmomi" -#~ msgstr "govc は、govmomi に構築された vSphere CLI です。" - -#~ msgid "Using VMware dynamic inventory plugin" -#~ msgstr "VMware 動的インベントリープラグインの使用" - -#~ msgid "VMware Dynamic Inventory Plugin" -#~ msgstr "VMware 動的インベントリープラグイン" - -#~ msgid "The best way to interact with your hosts is to use the VMware dynamic inventory plugin, which dynamically queries VMware APIs and tells Ansible what nodes can be managed." -#~ msgstr "ホストと対話する最適な方法として、VMware の動的インベントリープラグインを使用します。これにより、VMware API を動的にクエリーし、どのノードが管理できるかを Ansible に通知することができます。" - -#~ msgid "To use the VMware dynamic inventory plugins, you must install `pyVmomi `_ on your control node (the host running Ansible)." -#~ msgstr "VMware 動的インベントリープラグインを使用するには、コントロールノード (Ansible を実行するホスト) に `pyVmomi `_ をインストールする必要があります。" - -#~ msgid "To include tag-related information for the virtual machines in your dynamic inventory, you also need the `vSphere Automation SDK `_, which supports REST API features like tagging and content libraries, on your control node. You can install the ``vSphere Automation SDK`` following `these instructions `_." -#~ msgstr "動的インベントリーに仮想マシンのタグ関連の情報を含めるには、コントロールノードにタグ付けやコンテンツライブラリーなどの REST API 機能をサポートする `vSphere Automation SDK `__ も必要です。`こちらの手順 ` に従って ``vSphere Automation SDK`` をインストールできます。" - -#~ msgid "To use this VMware dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file:" -#~ msgstr "この VMware 動的インベントリープラグインを使用するには、最初に ``ansible.cfg`` ファイルに以下を指定して有効にする必要があります。" - -#~ msgid "Then, create a file that ends in ``.vmware.yml`` or ``.vmware.yaml`` in your working directory." -#~ msgstr "次に、作業ディレクトリーに、名前の末尾が ``.vmware.yml`` または ``.vmware.yaml`` で終わるファイルを作成します。" - -#~ msgid "The ``vmware_vm_inventory`` script takes in the same authentication information as any VMware module." -#~ msgstr "``vmware_vm_inventory`` スクリプトは、VMware モジュールと同じ認証情報を取得します。" - -#~ msgid "Executing ``ansible-inventory --list -i .vmware.yml`` will create a list of VMware instances that are ready to be configured using Ansible." -#~ msgstr "``ansible-inventory --list -i .vmware.yml`` を実行すると、Ansible を使用して設定できる VMware インスタンスの一覧が作成されます。" - -#~ msgid "Since the inventory configuration file contains vCenter password in plain text, a security risk, you may want to encrypt your entire inventory configuration file." -#~ msgstr "インベントリー設定ファイルにはプレーンテキストの vCenter パスワードが含まれるため、セキュリティーリスクがあります。インベントリー設定ファイル全体を暗号化できます。" - -#~ msgid "`vSphere Automation SDK GitHub Page `_" -#~ msgstr "`vSphere Automation SDK GitHub Page `_" - -#~ msgid "The GitHub Page of vSphere Automation SDK for Python" -#~ msgstr "Python 向けの vSphere Automation SDK の GitHub ページ" - -#~ msgid "`vSphere Automation SDK Issue Tracker `_" -#~ msgstr "`vSphere Automation SDK Issue Tracker `_" - -#~ msgid "The issue tracker for vSphere Automation SDK for Python" -#~ msgstr "Python 向けの vSphere Automation SDK の問題トラッカー" - -#~ msgid "Using VMware dynamic inventory plugin - Filters" -#~ msgstr "VMware 動的インベントリープラグインの使用 - フィルター" - -#~ msgid "VMware dynamic inventory plugin - filtering VMware guests" -#~ msgstr "VMware 動的インベントリープラグイン - VMware ゲストのフィルター設定" - -#~ msgid "VMware inventory plugin allows you to filter VMware guests using the ``filters`` configuration parameter." -#~ msgstr "VMware インベントリープラグインを使用すると、``filters`` 設定パラメーターを使用して VMware ゲストにフィルターを設定できます。" - -#~ msgid "This section shows how you configure ``filters`` for the given VMware guest in the inventory." -#~ msgstr "本セクションでは、インベントリー内の特定の VMware ゲストの ``filters`` を設定する方法を説明します。" - -#~ msgid "To include tag-related information for the virtual machines in your dynamic inventory, you also need the `vSphere Automation SDK `_, which supports REST API features such as tagging and content libraries, on your control node. You can install the ``vSphere Automation SDK`` following `these instructions `_." -#~ msgstr "動的インベントリーに仮想マシンのタグ関連の情報を含めるには、コントロールノードにタグ付けやコンテンツライブラリーなどの REST API 機能をサポートする `vSphere Automation SDK `__ も必要です。`こちらの手順 ` に従って ``vSphere Automation SDK`` をインストールできます。" - -#~ msgid "Starting in Ansible 2.10, the VMware dynamic inventory plugin is available in the ``community.vmware`` collection included Ansible. Alternately, to install the latest ``community.vmware`` collection:" -#~ msgstr "Ansible 2.10 以降では、Ansible を含む ``community.vmware`` コレクションで VMware 動的インベントリープラグインを利用できます。最新の ``community.vmware`` コレクションをインストールする場合は、以下を実行します。" - -#~ msgid "To use this VMware dynamic inventory plugin:" -#~ msgstr "VMware 動的インベントリープラグインを使用するには、以下を行います。" - -#~ msgid "Enable it first by specifying the following in the ``ansible.cfg`` file:" -#~ msgstr "``ansible.cfg`` ファイルで以下を指定して、まず有効にします。" - -#~ msgid "Create a file that ends in ``vmware.yml`` or ``vmware.yaml`` in your working directory." -#~ msgstr "作業ディレクトリーに、名前の末尾が ``vmware.yml`` または ``vmware.yaml`` で終わるファイルを作成します。" - -#~ msgid "The ``vmware_vm_inventory`` inventory plugin takes in the same authentication information as any other VMware modules does." -#~ msgstr "``vmware_vm_inventory`` インベントリープラグインは、他の VMware モジュールと同様に認証情報を取得します。" - -#~ msgid "Let us assume we want to list all RHEL7 VMs with the power state as \"poweredOn\". A valid inventory file with filters for the given VMware guest looks as follows:" -#~ msgstr "電源状態が「PoweredOn」である RHEL7 仮想マシンの一覧を表示するとします。指定した VMware ゲストに対してフィルター機能が有効なインベントリーファイルは次のようになります。" - -#~ msgid "Here, we have configured two filters -" -#~ msgstr "ここでは、フィルターを 2 つ設定しました。" - -#~ msgid "``config.guestId`` is equal to ``rhel7_64Guest``" -#~ msgstr "``config.guestId`` は ``rhel7_64Guest`` と等しい" - -#~ msgid "``summary.runtime.powerState`` is equal to ``poweredOn``" -#~ msgstr "``summary.runtime.powerState`` は ``poweredOn`` と等しい" - -#~ msgid "This retrieves all the VMs which satisfy these two conditions and populates them in the inventory. Notice that the conditions are combined using an ``and`` operation." -#~ msgstr "これにより、この 2 つの条件を満たすすべての仮想マシンが取得され、インベントリーに反映されます。``and`` 操作を使用して条件が組み合わされていることに注意してください。" - -#~ msgid "Using ``or`` conditions in filters" -#~ msgstr "フィルターでの ``or`` 条件の使用" - -#~ msgid "Let us assume you want filter RHEL7 and Ubuntu VMs. You can use multiple filters using ``or`` condition in your inventory file." -#~ msgstr "RHEL7 および Ubuntu の仮想マシンにフィルターを設定するとします。インベントリーファイルで ``or`` 条件を使用して複数のフィルターを使用できます。" - -#~ msgid "A valid filter in the VMware inventory file for this example is:" -#~ msgstr "この例の VMware インベントリーファイルにおける有効なフィルターは以下のとおりです。" - -#~ msgid "You can check all allowed properties for filters for the given virtual machine at :ref:`vmware_inventory_vm_attributes`." -#~ msgstr ":ref:`vmware_inventory_vm_attributes` で指定の仮想マシンのフィルターに許可されるすべてのプロパティーを確認できます。" - -#~ msgid "If you are using the ``properties`` parameter with custom VM properties, make sure that you include all the properties used by filters as well in your VM property list." -#~ msgstr "カスタムの仮想マシンのプロパティーで ``properties`` パラメーターを使用している場合は、仮想マシンのプロパティーの一覧にフィルターが使用するすべてのプロパティーを含めるようにしてください。" - -#~ msgid "For example, if we want all RHEL7 and Ubuntu VMs that are poweredOn, you can use inventory file:" -#~ msgstr "たとえば、RHEL7 および Ubuntu の仮想マシンにすべて電源が入っているようにするには、インベントリーファイルを使用できます。" - -#~ msgid "Here, we are using minimum VM properties, that is ``config.name``, ``config.guestId``, ``summary.runtime.powerState``, and ``guest.ipAddress``." -#~ msgstr "ここでは、最小の仮想マシンプロパティー (``config.name``、``config.guestId``、``summary.runtime.powerState``、および ``guest.ipAddress``) を使用します。" - -#~ msgid "``config.name`` is used by the ``hostnames`` parameter." -#~ msgstr "``config.name`` は、``hostnames`` パラメーターにより使用されます。" - -#~ msgid "``config.guestId`` and ``summary.runtime.powerState`` are used by the ``filters`` parameter." -#~ msgstr "``config.guestId`` および ``summary.runtime.powerState`` は、``filters`` パラメーターで使用されます。" - -#~ msgid "``guest.guestId`` is used by ``ansible_host`` internally by the inventory plugin." -#~ msgstr "``guest.guestId`` は、インベントリープラグインにより ``ansible_host`` に内部的に使用されます。" - -#~ msgid "Using regular expression in filters" -#~ msgstr "フィルターでの正規表現の使用" - -#~ msgid "Let us assume you want filter VMs with specific IP range. You can use regular expression in ``filters`` in your inventory file." -#~ msgstr "特定の IP 範囲を持つ仮想マシンにフィルターを設定するとします。インベントリーファイルの ``filters`` で正規表現を使用できます。" - -#~ msgid "Here, we are using ``guest.ipAddress`` VM property. This property is optional and depended upon VMware tools installed on VMs. We are using ``match`` to validate the regular expression for the given IP range." -#~ msgstr "ここで、``guest.ipAddress`` 仮想マシンプロパティーを使用します。このプロパティーは任意で、仮想マシンにインストールされている VMware ツールに依存します。``match`` を使用して、指定された IP 範囲の正規表現を検証します。" - -#~ msgid "Executing ``ansible-inventory --list -i .vmware.yml`` creates a list of the virtual machines that are ready to be configured using Ansible." -#~ msgstr "``ansible-inventory --list -i .vmware.yml`` を実行すると、Ansible を使用して設定できる仮想マシンの一覧が作成されます。" - -#~ msgid "You will notice that the inventory hosts are filtered depending on your ``filters`` section." -#~ msgstr "``filters`` セクションに応じてインベントリーホストにフィルターが設定される点に注意してください。" - -#~ msgid "Troubleshooting filters" -#~ msgstr "フィルターのトラブルシューティング" - -#~ msgid "If the custom property specified in ``filters`` fails:" -#~ msgstr "``filters`` で指定されたカスタムプロパティーが失敗する場合:" - -#~ msgid "Make sure it is a valid property, see :ref:`vmware_inventory_vm_attributes`." -#~ msgstr "有効なプロパティーであることを確認します。「:ref:`vmware_inventory_vm_attributes`」を参照してください。" - -#~ msgid "Use ``strict: True`` to get more information about the error." -#~ msgstr "``strict: True`` を使用して、エラーに関する詳細情報を取得します。" - -#~ msgid "Please make sure that you are using latest version of the VMware collection." -#~ msgstr "VMware コレクションの最新バージョンを使用していることを確認してください。" - -#~ msgid ":ref:`vmware_inventory_vm_attributes`" -#~ msgstr ":ref:`vmware_inventory_vm_attributes`" - -#~ msgid "Using Virtual machine attributes in VMware dynamic inventory plugin" -#~ msgstr "VMware 動的インベントリープラグインでの仮想マシン属性の使用" - -#~ msgid "Using VMware dynamic inventory plugin - Hostnames" -#~ msgstr "VMware 動的インベントリープラグインの使用 - ホスト名" - -#~ msgid "VMware dynamic inventory plugin - customizing hostnames" -#~ msgstr "VMware 動的インベントリープラグイン - ホスト名のカスタマイズ" - -#~ msgid "VMware inventory plugin allows you to configure hostnames using the ``hostnames`` configuration parameter." -#~ msgstr "VMware インベントリープラグインでは、``hostnames`` 設定パラメーターを使用してホスト名を設定できます。" - -#~ msgid "In this scenario guide we will see how you configure hostnames from the given VMware guest in the inventory." -#~ msgstr "このシナリオでは、インベントリーで、指定した VMware ゲストからホスト名を設定する方法を説明します。" - -#~ msgid "Starting in Ansible 2.10, the VMware dynamic inventory plugin is available in the ``community.vmware`` collection included Ansible. To install the latest ``community.vmware`` collection:" -#~ msgstr "Ansible 2.10 以降では、VMware 動的インベントリープラグインが Ansible に含まれる ``community.vmware`` コレクションで利用可能になりました。最新の ``community.vmware`` コレクションをインストールするには、以下を実行します。" - -#~ msgid "Here's an example of a valid inventory file with custom hostname for the given VMware guest:" -#~ msgstr "以下は、特定の VMware ゲストのカスタムホスト名を持つ有効なインベントリーファイルの例です。" - -#~ msgid "Here, we have configured a custom hostname by setting the ``hostnames`` parameter to ``config.name``. This will retrieve the ``config.name`` property from the virtual machine and populate it in the inventory." -#~ msgstr "ここでは、``hostnames`` パラメーターを ``config.name`` に設定してカスタムのホスト名を設定し、仮想マシンから ``config.name`` プロパティーを取得し、これをインベントリーに反映します。" - -#~ msgid "You can check all allowed properties for the given virtual machine at :ref:`vmware_inventory_vm_attributes`." -#~ msgstr ":ref:`vmware_inventory_vm_attributes` で指定の仮想マシンに対して許可されるすべてのプロパティーを確認できます。" - -#~ msgid "You will notice that instead of default behavior of representing the hostname as ``config.name + _ + config.uuid``, the inventory hosts show value as ``config.name``." -#~ msgstr "ホスト名を ``config.name + _ + config.uuid`` として表示する代わりに、インベントリーホストは値を ``config.name`` と表示することに注意してください。" - -#~ msgid "If the custom property specified in ``hostnames`` fails:" -#~ msgstr "``hostnames`` で指定されたカスタムプロパティーが失敗する場合:" - -#~ msgid "Please make sure that you are using latest version VMware collection." -#~ msgstr "最新バージョンの VMware コレクションを使用していることを確認してください。" - -#~ msgid "Virtual machine attributes" -#~ msgstr "仮想マシンの属性" - -#~ msgid "You can use virtual machine properties which can be used to populate ``hostvars`` for the given virtual machine in a VMware dynamic inventory plugin." -#~ msgstr "VMware 動的インベントリープラグインで指定の仮想マシンの ``hostvars`` を設定するのに使用できる仮想マシンプロパティーを使用できます。" - -#~ msgid "capability" -#~ msgstr "機能" - -#~ msgid "This section describes settings for the runtime capabilities of the virtual machine." -#~ msgstr "本セクションでは、仮想マシンのランタイム機能の設定を説明します。" - -#~ msgid "snapshotOperationsSupported (bool)" -#~ msgstr "snapshotOperationsSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports snapshot operations." -#~ msgstr "仮想マシンでスナップショットの操作をサポートするかどうかを示します。" - -#~ msgid "multipleSnapshotsSupported (bool)" -#~ msgstr "multipleSnapshotsSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports multiple snapshots. This value is not set when the virtual machine is unavailable, for instance, when it is being created or deleted." -#~ msgstr "仮想マシンが複数のスナップショットをサポートするかどうかを示します。この値は、仮想マシンの作成時や削除時など、仮想マシンが利用できないときには設定されません。" - -#~ msgid "snapshotConfigSupported (bool)" -#~ msgstr "snapshotConfigSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports snapshot config." -#~ msgstr "仮想マシンがスナップショット設定をサポートするかどうかを示します。" - -#~ msgid "poweredOffSnapshotsSupported (bool)" -#~ msgstr "poweredOffSnapshotsSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports snapshot operations in ``poweredOff`` state." -#~ msgstr "仮想マシンが ``poweredOff`` 状態のスナップショット操作に対応しているかどうかを示します。" - -#~ msgid "memorySnapshotsSupported (bool)" -#~ msgstr "memorySnapshotsSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports memory snapshots." -#~ msgstr "仮想マシンがメモリースナップショットをサポートするかどうかを示します。" - -#~ msgid "revertToSnapshotSupported (bool)" -#~ msgstr "revertToSnapshotSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports reverting to a snapshot." -#~ msgstr "仮想マシンをスナップショットの状態に戻すかどうかを示します。" - -#~ msgid "quiescedSnapshotsSupported (bool)" -#~ msgstr "quiescedSnapshotsSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports quiesced snapshots." -#~ msgstr "仮想マシンが静止状態のスナップショットをサポートするかどうかを示します。" - -#~ msgid "disableSnapshotsSupported (bool)" -#~ msgstr "disableSnapshotsSupported (bool)" - -#~ msgid "Indicates whether or not snapshots can be disabled." -#~ msgstr "スナップショットを無効にすることができるかどうかを示します。" - -#~ msgid "lockSnapshotsSupported (bool)" -#~ msgstr "lockSnapshotsSupported (bool)" - -#~ msgid "Indicates whether or not the snapshot tree can be locked." -#~ msgstr "スナップショットツリーがロックされるかどうかを示します。" - -#~ msgid "consolePreferencesSupported (bool)" -#~ msgstr "consolePreferencesSupported (bool)" - -#~ msgid "Indicates whether console preferences can be set for the virtual machine." -#~ msgstr "コンソール設定を仮想マシンに設定できるかどうかを示します。" - -#~ msgid "cpuFeatureMaskSupported (bool)" -#~ msgstr "cpuFeatureMaskSupported (bool)" - -#~ msgid "Indicates whether CPU feature requirements masks can be set for the virtual machine." -#~ msgstr "CPU 機能要件のマスクを仮想マシンに設定できるかどうかを示します。" - -#~ msgid "s1AcpiManagementSupported (bool)" -#~ msgstr "s1AcpiManagementSupported (bool)" - -#~ msgid "Indicates whether or not a virtual machine supports ACPI S1 settings management." -#~ msgstr "仮想マシンが ACPI S1 設定管理をサポートするかどうかを示します。" - -#~ msgid "settingScreenResolutionSupported (bool)" -#~ msgstr "settingScreenResolutionSupported (bool)" - -#~ msgid "Indicates whether or not the virtual machine supports setting the screen resolution of the console window." -#~ msgstr "仮想マシンがコンソールウィンドウの画面の解像度の設定をサポートするかどうかを示します。" - -#~ msgid "toolsAutoUpdateSupported (bool)" -#~ msgstr "toolsAutoUpdateSupported (bool)" - -#~ msgid "Supports tools auto-update." -#~ msgstr "ツールの自動更新をサポートします。" - -#~ msgid "vmNpivWwnSupported (bool)" -#~ msgstr "vmNpivWwnSupported (bool)" - -#~ msgid "Supports virtual machine NPIV WWN." -#~ msgstr "仮想マシンの NPIV WWN をサポートします。" - -#~ msgid "npivWwnOnNonRdmVmSupported (bool)" -#~ msgstr "npivWwnOnNonRdmVmSupported (bool)" - -#~ msgid "Supports assigning NPIV WWN to virtual machines that do not have RDM disks." -#~ msgstr "RDM ディスクを持たない仮想マシンへの NPIV WWN の割り当てをサポートします。" - -#~ msgid "vmNpivWwnDisableSupported (bool)" -#~ msgstr "vmNpivWwnDisableSupported (bool)" - -#~ msgid "Indicates whether the NPIV disabling operation is supported on the virtual machine." -#~ msgstr "仮想マシンで NPIV の無効化操作がサポートされているかどうかを示します。" - -#~ msgid "vmNpivWwnUpdateSupported (bool)" -#~ msgstr "vmNpivWwnUpdateSupported (bool)" - -#~ msgid "Indicates whether the update of NPIV WWNs are supported on the virtual machine." -#~ msgstr "仮想マシンで NPIV WWN の更新がサポートされているかどうかを示します。" - -#~ msgid "swapPlacementSupported (bool)" -#~ msgstr "swapPlacementSupported (bool)" - -#~ msgid "Flag indicating whether the virtual machine has a configurable (swapfile placement policy)." -#~ msgstr "仮想マシンに設定可能な (swapfile の配置ポリシー) があるかどうかを示すフラグ。" - -#~ msgid "toolsSyncTimeSupported (bool)" -#~ msgstr "toolsSyncTimeSupported (bool)" - -#~ msgid "Indicates whether asking tools to sync time with the host is supported." -#~ msgstr "ツールにホストと時刻の同期を要求することをサポートしているかどうかを示します。" - -#~ msgid "virtualMmuUsageSupported (bool)" -#~ msgstr "virtualMmuUsageSupported (bool)" - -#~ msgid "Indicates whether or not the use of nested page table hardware support can be explicitly set." -#~ msgstr "入れ子ページテーブルのハードウェアサポートを明示的に設定できるかどうかを示します。" - -#~ msgid "diskSharesSupported (bool)" -#~ msgstr "diskSharesSupported (bool)" - -#~ msgid "Indicates whether resource settings for disks can be applied to the virtual machine." -#~ msgstr "ディスクのリソース設定を仮想マシンに適用できるかどうかを示します。" - -#~ msgid "bootOptionsSupported (bool)" -#~ msgstr "bootOptionsSupported (bool)" - -#~ msgid "Indicates whether boot options can be configured for the virtual machine." -#~ msgstr "仮想マシンに起動オプションを設定できるかどうかを示します。" - -#~ msgid "bootRetryOptionsSupported (bool)" -#~ msgstr "bootRetryOptionsSupported (bool)" - -#~ msgid "Indicates whether automatic boot retry can be configured for the virtual machine." -#~ msgstr "仮想マシンに自動起動再試行を設定できるかどうかを示します。" - -#~ msgid "settingVideoRamSizeSupported (bool)" -#~ msgstr "settingVideoRamSizeSupported (bool)" - -#~ msgid "Flag indicating whether the video RAM size of the virtual machine can be configured." -#~ msgstr "仮想マシンのビデオ RAM サイズを設定できるかどうかを示すフラグ。" - -#~ msgid "settingDisplayTopologySupported (bool)" -#~ msgstr "settingDisplayTopologySupported (bool)" - -#~ msgid "Indicates whether or not the virtual machine supports setting the display topology of the console window." -#~ msgstr "仮想マシンがコンソールウィンドウの表示トポロジーの設定に対応しているかどうかを示します。" - -#~ msgid "recordReplaySupported (bool)" -#~ msgstr "recordReplaySupported (bool)" - -#~ msgid "Indicates whether record and replay functionality is supported on the virtual machine." -#~ msgstr "仮想マシンで記録機能および再生機能がサポートされるかどうかを示します。" - -#~ msgid "changeTrackingSupported (bool)" -#~ msgstr "changeTrackingSupported (bool)" - -#~ msgid "Indicates that change tracking is supported for virtual disks of the virtual machine. However, even if change tracking is supported, it might not be available for all disks of the virtual machine. For example, passthru raw disk mappings or disks backed by any Ver1BackingInfo cannot be tracked." -#~ msgstr "仮想マシンの仮想ディスクで、変更追跡がサポートされることを示しますが、変更追跡がサポートされる場合でも、仮想マシンのすべてのディスクで利用できるわけではありません。たとえば、パススルーの RAW ディスクマッピングや、任意の Ver1BackingInfo でバックアップされたディスクは追跡できません。" - -#~ msgid "multipleCoresPerSocketSupported (bool)" -#~ msgstr "multipleCoresPerSocketSupported (bool)" - -#~ msgid "Indicates whether multiple virtual cores per socket is supported on the virtual machine." -#~ msgstr "1 ソケットあたりの複数の仮想コアが仮想マシンでサポートされているかどうかを示します。" - -#~ msgid "hostBasedReplicationSupported (bool)" -#~ msgstr "hostBasedReplicationSupported (bool)" - -#~ msgid "Indicates that host based replication is supported on the virtual machine. However, even if host based replication is supported, it might not be available for all disk types. For example, passthru raw disk mappings can not be replicated." -#~ msgstr "仮想マシンでホストベースのレプリケーションがサポートされていることを示しますが、ホストベースのレプリケーションがサポートされる場合でも、すべてのディスクタイプで利用できない可能性があります。たとえば、パススルーの RAW ディスクマッピングは複製できません。" - -#~ msgid "guestAutoLockSupported (bool)" -#~ msgstr "guestAutoLockSupported (bool)" - -#~ msgid "Indicates whether or not guest autolock is supported on the virtual machine." -#~ msgstr "仮想マシンでゲストの自動ロックがサポートされているかどうかを示します。" - -#~ msgid "memoryReservationLockSupported (bool)" -#~ msgstr "memoryReservationLockSupported (bool)" - -#~ msgid "Indicates whether :ref:`memory_reservation_locked_to_max` may be set to true for the virtual machine." -#~ msgstr "仮想マシンに対して :ref:`memory_reservation_locked_to_max` が true に設定されるかどうかを示します。" - -#~ msgid "featureRequirementSupported (bool)" -#~ msgstr "featureRequirementSupported (bool)" - -#~ msgid "Indicates whether the featureRequirement feature is supported." -#~ msgstr "featureRequirement 機能がサポートされているかどうかを示します。" - -#~ msgid "poweredOnMonitorTypeChangeSupported (bool)" -#~ msgstr "poweredOnMonitorTypeChangeSupported (bool)" - -#~ msgid "Indicates whether a monitor type change is supported while the virtual machine is in the ``poweredOn`` state." -#~ msgstr "仮想マシンが ``poweredOn`` 状態にある間にモニタータイプの変更がサポートされているかどうかを示します。" - -#~ msgid "seSparseDiskSupported (bool)" -#~ msgstr "seSparseDiskSupported (bool)" - -#~ msgid "Indicates whether the virtual machine supports the Flex-SE (space-efficent, sparse) format for virtual disks." -#~ msgstr "仮想マシンが仮想ディスクの Flex-SE (スペースが有効、スパース) 形式をサポートしているかどうかを示します。" - -#~ msgid "nestedHVSupported (bool)" -#~ msgstr "nestedHVSupported (bool)" - -#~ msgid "Indicates whether the virtual machine supports nested hardware-assisted virtualization." -#~ msgstr "仮想マシンがネストされたハードウェア支援型仮想化をサポートしているかどうかを示します。" - -#~ msgid "vPMCSupported (bool)" -#~ msgstr "vPMCSupported (bool)" - -#~ msgid "Indicates whether the virtual machine supports virtualized CPU performance counters." -#~ msgstr "仮想マシンが仮想 CPU パフォーマンスカウンターをサポートしているかどうかを示します。" - -#~ msgid "config" -#~ msgstr "設定" - -#~ msgid "This section describes the configuration settings of the virtual machine, including the name and UUID. This property is set when a virtual machine is created or when the ``reconfigVM`` method is called. The virtual machine configuration is not guaranteed to be available. For example, the configuration information would be unavailable if the server is unable to access the virtual machine files on disk, and is often also unavailable during the initial phases of virtual machine creation." -#~ msgstr "このセクションでは、名前および UUID を含む仮想マシンの設定を説明します。このプロパティーは、仮想マシンの作成時または ``reconfigVM`` メソッドが呼び出される際に設定されます。たとえば、仮想マシンの設定が利用可能になる保証はありません。たとえば、サーバーがディスク上の仮想マシンファイルにアクセスできない場合は、設定情報は利用できません。仮想マシン作成の初期段階でも利用できないことが多々あります。" - -#~ msgid "changeVersion (str)" -#~ msgstr "changeVersion (str)" - -#~ msgid "The changeVersion is a unique identifier for a given version of the configuration. Each change to the configuration updates this value. This is typically implemented as an ever increasing count or a time-stamp. However, a client should always treat this as an opaque string." -#~ msgstr "changeVersion は、設定の特定バージョンの一意の識別子です。設定への変更はそれぞれこの値を更新します。これは通常、増加し続けるカウントやタイムスタンプとして実装されますが、クライアントは常にこれを不透明な文字列として扱う必要があります。" - -#~ msgid "modified (datetime)" -#~ msgstr "modified (datetime)" - -#~ msgid "Last time a virtual machine's configuration was modified." -#~ msgstr "仮想マシンの設定が最後に変更した時間。" - -#~ msgid "name (str)" -#~ msgstr "name (str)" - -#~ msgid "Display name of the virtual machine. Any / (slash), \\ (backslash), character used in this name element is escaped. Similarly, any % (percent) character used in this name element is escaped, unless it is used to start an escape sequence. A slash is escaped as %2F or %2f. A backslash is escaped as %5C or %5c, and a percent is escaped as %25." -#~ msgstr "仮想マシンの表示名です。/ (スラッシュ)、\\ (バックスラッシュ)、この名前要素で使用される文字がエスケープされます。同様に、エスケープ処理を開始するのに使用されていない限り、この名前要素で使用される % (パーセント) 文字はエスケープされます。スラッシュをエスケープする場合は %2F または %2f となり、バックスラッシュをエスケープする場合は %5C または %5c となり、パーセントをエスケープする場合は %25 となります。" - -#~ msgid "guestFullName (str)" -#~ msgstr "guestFullName (str)" - -#~ msgid "This is the full name of the guest operating system for the virtual machine. For example: Windows 2000 Professional. See :ref:`alternate_guest_name`." -#~ msgstr "これは、仮想マシンのゲストオペレーティングシステムの完全な名前です (たとえば、Windows 2000 Professional)。「:ref:`alternate_guest_name`」を参照してください。" - -#~ msgid "version (str)" -#~ msgstr "version (str)" - -#~ msgid "The version string for the virtual machine." -#~ msgstr "仮想マシンのバージョン文字列。" - -#~ msgid "uuid (str)" -#~ msgstr "uuid (str)" - -#~ msgid "128-bit SMBIOS UUID of a virtual machine represented as a hexadecimal string in \"12345678-abcd-1234-cdef-123456789abc\" format." -#~ msgstr "仮想マシンの 128 ビット SMBIOS UUID は、「12345678-abcd-1234-cdef-123456789abc」形式で 16 進数の文字列として表されます。" - -#~ msgid "instanceUuid (str, optional)" -#~ msgstr "instanceUuid (str, optional)" - -#~ msgid "VirtualCenter-specific 128-bit UUID of a virtual machine, represented as a hexadecimal string. This identifier is used by VirtualCenter to uniquely identify all virtual machine instances, including those that may share the same SMBIOS UUID." -#~ msgstr "仮想マシンの VirtualCenter 固有の 128 ビットの UUID は 16 進法として表示されます。この識別子は、同じ SMBIOS UUID を共有する可能性のある仮想マシンインスタンスを含め、すべての仮想マシンインスタンスを一意に識別するために VirtualCenter により使用されます。" - -#~ msgid "npivNodeWorldWideName (long, optional)" -#~ msgstr "npivNodeWorldWideName (long, optional)" - -#~ msgid "A 64-bit node WWN (World Wide Name)." -#~ msgstr "64 ビットノード WWN (World Wide Name)。" - -#~ msgid "npivPortWorldWideName (long, optional)" -#~ msgstr "npivPortWorldWideName (long, optional)" - -#~ msgid "A 64-bit port WWN (World Wide Name)." -#~ msgstr "64 ビットのポート WWN (World Wide Name)。" - -#~ msgid "npivWorldWideNameType (str, optional)" -#~ msgstr "npivWorldWideNameType (str, optional)" - -#~ msgid "The source that provides/generates the assigned WWNs." -#~ msgstr "割り当てられた WWN を提供または生成するソース。" - -#~ msgid "npivDesiredNodeWwns (short, optional)" -#~ msgstr "npivDesiredNodeWwns (short, optional)" - -#~ msgid "The NPIV node WWNs to be extended from the original list of WWN numbers." -#~ msgstr "WWN 番号の元の一覧から拡張される NPIV ノード WWN。" - -#~ msgid "npivDesiredPortWwns (short, optional)" -#~ msgstr "npivDesiredPortWwns (short, optional)" - -#~ msgid "The NPIV port WWNs to be extended from the original list of WWN numbers." -#~ msgstr "WWN 番号の元のリストから拡張される NPIV ポート WWN。" - -#~ msgid "npivTemporaryDisabled (bool, optional)" -#~ msgstr "npivTemporaryDisabled (bool, optional)" - -#~ msgid "This property is used to enable or disable the NPIV capability on a desired virtual machine on a temporary basis." -#~ msgstr "このプロパティーは、必要な仮想マシンの NPIV 機能を一時的に有効または無効にするために使用されます。" - -#~ msgid "npivOnNonRdmDisks (bool, optional)" -#~ msgstr "npivOnNonRdmDisks (bool, optional)" - -#~ msgid "This property is used to check whether the NPIV can be enabled on the Virtual machine with non-rdm disks in the configuration, so this is potentially not enabling npiv on vmfs disks. Also this property is used to check whether RDM is required to generate WWNs for a virtual machine." -#~ msgstr "このプロパティーは、設定内の非 rdm ディスクを持つ仮想マシンで NPIV を有効にすることができるかどうかを確認するのに使用するため、vmfs ディスクで npiv が有効になっていない可能性があります。また、このプロパティーは、仮想マシンの WWN を生成する必要があるかどうかを確認するのに使用されます。" - -#~ msgid "locationId (str, optional)" -#~ msgstr "locationId (str, optional)" - -#~ msgid "Hash incorporating the virtual machine's config file location and the UUID of the host assigned to run the virtual machine." -#~ msgstr "仮想マシンの設定ファイルの場所と、仮想マシンの実行に割り当てられたホストの UUID を組み込んだハッシュ。" - -#~ msgid "template (bool)" -#~ msgstr "template (bool)" - -#~ msgid "Flag indicating whether or not a virtual machine is a template." -#~ msgstr "仮想マシンがテンプレートであるかどうかを示すフラグ。" - -#~ msgid "guestId (str)" -#~ msgstr "guestId (str)" - -#~ msgid "Guest operating system configured on a virtual machine." -#~ msgstr "仮想マシンに設定されたゲストオペレーティングシステム。" - -#~ msgid "alternateGuestName (str)" -#~ msgstr "alternateGuestName (str)" - -#~ msgid "Used as display name for the operating system if guestId isotherorother-64. See :ref:`guest_full_name`." -#~ msgstr "guestId が other または other-64 の場合、オペレーティングシステムの表示名として使用されます。「:ref:`guest_full_name`」を参照してください。" - -#~ msgid "annotation (str, optional)" -#~ msgstr "annotation (str, optional)" - -#~ msgid "Description for the virtual machine." -#~ msgstr "仮想マシンの説明。" - -#~ msgid "files (vim.vm.FileInfo)" -#~ msgstr "files (vim.vm.FileInfo)" - -#~ msgid "Information about the files associated with a virtual machine. This information does not include files for specific virtual disks or snapshots." -#~ msgstr "仮想マシンに関連付けられたファイルに関する情報。この情報には、特定の仮想ディスクやスナップショットのファイルが含まれません。" - -#~ msgid "tools (vim.vm.ToolsConfigInfo, optional)" -#~ msgstr "tools (vim.vm.ToolsConfigInfo, optional)" - -#~ msgid "Configuration of VMware Tools running in the guest operating system." -#~ msgstr "ゲストオペレーティングシステムで実行している VMware ツールの設定。" - -#~ msgid "flags (vim.vm.FlagInfo)" -#~ msgstr "flags (vim.vm.FlagInfo)" - -#~ msgid "Additional flags for a virtual machine." -#~ msgstr "仮想マシンの追加フラグ。" - -#~ msgid "consolePreferences (vim.vm.ConsolePreferences, optional)" -#~ msgstr "consolePreferences (vim.vm.ConsolePreferences, optional)" - -#~ msgid "Legacy console viewer preferences when doing power operations." -#~ msgstr "レガシーコンソールビューアーは、電源操作を実行する際に設定できます。" - -#~ msgid "defaultPowerOps (vim.vm.DefaultPowerOpInfo)" -#~ msgstr "defaultPowerOps (vim.vm.DefaultPowerOpInfo)" - -#~ msgid "Configuration of default power operations." -#~ msgstr "デフォルトの電源操作の設定。" - -#~ msgid "hardware (vim.vm.VirtualHardware)" -#~ msgstr "hardware (vim.vm.VirtualHardware)" - -#~ msgid "Processor, memory, and virtual devices for a virtual machine." -#~ msgstr "仮想マシンのプロセッサー、メモリー、および仮想デバイス。" - -#~ msgid "cpuAllocation (vim.ResourceAllocationInfo, optional)" -#~ msgstr "cpuAllocation (vim.ResourceAllocationInfo, optional)" - -#~ msgid "Resource limits for CPU." -#~ msgstr "CPU のリソース制限。" - -#~ msgid "memoryAllocation (vim.ResourceAllocationInfo, optional)" -#~ msgstr "memoryAllocation (vim.ResourceAllocationInfo, optional)" - -#~ msgid "Resource limits for memory." -#~ msgstr "メモリーのリソース制限。" - -#~ msgid "latencySensitivity (vim.LatencySensitivity, optional)" -#~ msgstr "latencySensitivity (vim.LatencySensitivity, optional)" - -#~ msgid "The latency-sensitivity of the virtual machine." -#~ msgstr "仮想マシンのレイテンシーの感度。" - -#~ msgid "memoryHotAddEnabled (bool, optional)" -#~ msgstr "memoryHotAddEnabled (bool, optional)" - -#~ msgid "Whether memory can be added while the virtual machine is running." -#~ msgstr "仮想マシンの実行中にメモリーを追加できるかどうか。" - -#~ msgid "cpuHotAddEnabled (bool, optional)" -#~ msgstr "cpuHotAddEnabled (bool, optional)" - -#~ msgid "Whether virtual processors can be added while the virtual machine is running." -#~ msgstr "仮想マシンの実行中に仮想プロセッサーを追加できるかどうか。" - -#~ msgid "cpuHotRemoveEnabled (bool, optional)" -#~ msgstr "cpuHotRemoveEnabled (bool, optional)" - -#~ msgid "Whether virtual processors can be removed while the virtual machine is running." -#~ msgstr "仮想マシンの実行中に仮想プロセッサーを削除できるかどうか。" - -#~ msgid "hotPlugMemoryLimit (long, optional)" -#~ msgstr "hotPlugMemoryLimit (long, optional)" - -#~ msgid "The maximum amount of memory, in MB, than can be added to a running virtual machine." -#~ msgstr "実行中の仮想マシンに追加できるメモリーの最大量 (MB 単位)。" - -#~ msgid "hotPlugMemoryIncrementSize (long, optional)" -#~ msgstr "hotPlugMemoryIncrementSize (long, optional)" - -#~ msgid "Memory, in MB that can be added to a running virtual machine." -#~ msgstr "実行中の仮想マシンに追加できるメモリー (MB 単位)。" - -#~ msgid "cpuAffinity (vim.vm.AffinityInfo, optional)" -#~ msgstr "cpuAffinity (vim.vm.AffinityInfo, optional)" - -#~ msgid "Affinity settings for CPU." -#~ msgstr "CPU のアフィニティー設定。" - -#~ msgid "memoryAffinity (vim.vm.AffinityInfo, optional)" -#~ msgstr "memoryAffinity (vim.vm.AffinityInfo, optional)" - -#~ msgid "Affinity settings for memory." -#~ msgstr "メモリーのアフィニティー設定。" - -#~ msgid "networkShaper (vim.vm.NetworkShaperInfo, optional)" -#~ msgstr "networkShaper (vim.vm.NetworkShaperInfo, optional)" - -#~ msgid "Resource limits for network." -#~ msgstr "ネットワークのリソース制限。" - -#~ msgid "extraConfig (vim.option.OptionValue, optional)" -#~ msgstr "extraConfig (vim.option.OptionValue, optional)" - -#~ msgid "Additional configuration information for the virtual machine." -#~ msgstr "仮想マシンの追加設定情報。" - -#~ msgid "cpuFeatureMask (vim.host.CpuIdInfo, optional)" -#~ msgstr "cpuFeatureMask (vim.host.CpuIdInfo, optional)" - -#~ msgid "Specifies CPU feature compatibility masks that override the defaults from the ``GuestOsDescriptor`` of the virtual machine's guest OS." -#~ msgstr "仮想マシンのゲスト OS の ``GuestOsDescriptor`` からデフォルトを上書きする CPU 機能互換性マスクを指定します。" - -#~ msgid "datastoreUrl (vim.vm.ConfigInfo.DatastoreUrlPair, optional)" -#~ msgstr "datastoreUrl (vim.vm.ConfigInfo.DatastoreUrlPair, optional)" - -#~ msgid "Enumerates the set of datastores that the virtual machine is stored on, as well as the URL identification for each of these." -#~ msgstr "仮想マシンが保存されるデータストアのセットと、その各 URL ID を列挙します。" - -#~ msgid "swapPlacement (str, optional)" -#~ msgstr "swapPlacement (str, optional)" - -#~ msgid "Virtual machine swapfile placement policy." -#~ msgstr "仮想マシンの swapfile 配置ポリシー。" - -#~ msgid "bootOptions (vim.vm.BootOptions, optional)" -#~ msgstr "bootOptions (vim.vm.BootOptions, optional)" - -#~ msgid "Configuration options for the boot behavior of the virtual machine." -#~ msgstr "仮想マシンのブート動作の設定オプション。" - -#~ msgid "ftInfo (vim.vm.FaultToleranceConfigInfo, optional)" -#~ msgstr "ftInfo (vim.vm.FaultToleranceConfigInfo, optional)" - -#~ msgid "Fault tolerance settings for the virtual machine." -#~ msgstr "仮想マシンのフォールトトレランス設定。" - -#~ msgid "vAppConfig (vim.vApp.VmConfigInfo, optional)" -#~ msgstr "vAppConfig (vim.vApp.VmConfigInfo, optional)" - -#~ msgid "vApp meta-data for the virtual machine." -#~ msgstr "仮想マシンの vApp メタデータ。" - -#~ msgid "vAssertsEnabled (bool, optional)" -#~ msgstr "vAssertsEnabled (bool, optional)" - -#~ msgid "Indicates whether user-configured virtual asserts will be triggered during virtual machine replay." -#~ msgstr "仮想マシンの再生中にユーザー定義の仮想アサートがトリガーされるかどうかを示します。" - -#~ msgid "changeTrackingEnabled (bool, optional)" -#~ msgstr "changeTrackingEnabled (bool, optional)" - -#~ msgid "Indicates whether changed block tracking for the virtual machine's disks is active." -#~ msgstr "仮想マシンのディスクのブロック追跡がアクティブかどうかを示します。" - -#~ msgid "firmware (str, optional)" -#~ msgstr "firmware (str, optional)" - -#~ msgid "Information about firmware type for the virtual machine." -#~ msgstr "仮想マシンのファームウェアの種類に関する情報。" - -#~ msgid "maxMksConnections (int, optional)" -#~ msgstr "maxMksConnections (int, optional)" - -#~ msgid "Indicates the maximum number of active remote display connections that the virtual machine will support." -#~ msgstr "仮想マシンがサポートするアクティブなリモートディスプレイ接続の最大数を示します。" - -#~ msgid "guestAutoLockEnabled (bool, optional)" -#~ msgstr "guestAutoLockEnabled (bool, optional)" - -#~ msgid "Indicates whether the guest operating system will logout any active sessions whenever there are no remote display connections open to the virtual machine." -#~ msgstr "仮想マシンにリモートディスプレイ接続が開かない場合に、ゲストオペレーティングシステムがアクティブなセッションをすべてログアウトするかどうかを指定します。" - -#~ msgid "managedBy (vim.ext.ManagedByInfo, optional)" -#~ msgstr "managedBy (vim.ext.ManagedByInfo, optional)" - -#~ msgid "Specifies that the virtual machine is managed by a VC Extension." -#~ msgstr "仮想マシンが VC 拡張で管理されるように指定します。" - -#~ msgid "memoryReservationLockedToMax (bool, optional)" -#~ msgstr "memoryReservationLockedToMax (bool, optional)" - -#~ msgid "If set true, memory resource reservation for the virtual machine will always be equal to the virtual machine's memory size; increases in memory size will be rejected when a corresponding reservation increase is not possible." -#~ msgstr "true に設定すると、仮想マシンのメモリーリソース予約は常に仮想マシンのメモリーサイズと同じになります。対応する予約が増えないと、メモリーサイズの増加は拒否されます。" - -#~ msgid "initialOverhead (vim.vm.ConfigInfo.OverheadInfo), optional)" -#~ msgstr "initialOverhead (vim.vm.ConfigInfo.OverheadInfo), optional)" - -#~ msgid "Set of values to be used only to perform admission control when determining if a host has sufficient resources for the virtual machine to power on." -#~ msgstr "ホストに仮想マシンの電源を入れるのに十分なリソースがあるかどうかを判別する際にのみ受付制御を実行するのに使用する値のセット。" - -#~ msgid "nestedHVEnabled (bool, optional)" -#~ msgstr "nestedHVEnabled (bool, optional)" - -#~ msgid "Indicates whether the virtual machine is configured to use nested hardware-assisted virtualization." -#~ msgstr "仮想マシンがネストされたハードウェア支援型仮想化を使用するように設定されているかどうかを示します。" - -#~ msgid "vPMCEnabled (bool, optional)" -#~ msgstr "vPMCEnabled (bool, optional)" - -#~ msgid "Indicates whether the virtual machine have virtual CPU performance counters enabled." -#~ msgstr "仮想マシンの仮想 CPU パフォーマンスカウンターが有効になっているかどうかを示します。" - -#~ msgid "scheduledHardwareUpgradeInfo (vim.vm.ScheduledHardwareUpgradeInfo, optional)" -#~ msgstr "scheduledHardwareUpgradeInfo (vim.vm.ScheduledHardwareUpgradeInfo, optional)" - -#~ msgid "Configuration of scheduled hardware upgrades and result from last attempt to run scheduled hardware upgrade." -#~ msgstr "スケジュールされたハードウェアアップグレードの設定と、スケジュールされたハードウェアアップグレードを最後に実行したときの結果。" - -#~ msgid "vFlashCacheReservation (long, optional)" -#~ msgstr "vFlashCacheReservation (long, optional)" - -#~ msgid "Specifies the total vFlash resource reservation for the vFlash caches associated with the virtual machine's virtual disks, in bytes." -#~ msgstr "仮想マシンの仮想ディスクに関連付けられた vFlash キャッシュの vFlash リソース予約の合計をバイト単位で指定します。" - -#~ msgid "layout" -#~ msgstr "レイアウト" - -#~ msgid "Detailed information about the files that comprise the virtual machine." -#~ msgstr "仮想マシンを構成するファイルに関する詳細情報。" - -#~ msgid "configFile (str, optional)" -#~ msgstr "configFile (str, optional)" - -#~ msgid "A list of files that makes up the configuration of the virtual machine (excluding the .vmx file, since that file is represented in the FileInfo). These are relative paths from the configuration directory. A slash is always used as a separator. This list will typically include the NVRAM file, but could also include other meta-data files." -#~ msgstr "仮想マシンの設定を構成するファイルの一覧 (.vmx ファイルは FileInfo で表現されるため除く)。これらは設定ディレクトリーからの相対パスになります。スラッシュは常にセパレーターとして使用されます。この一覧には通常 NVRAM ファイルが含まれますが、他のメタデータファイルを含めることもできます。" - -#~ msgid "logFile (str, optional)" -#~ msgstr "logFile (str, optional)" - -#~ msgid "A list of files stored in the virtual machine's log directory. These are relative paths from the ``logDirectory``. A slash is always used as a separator." -#~ msgstr "仮想マシンのログディレクトリーに保存されているファイルの一覧。これらは ``logDirectory`` からの相対パスになります。スラッシュは常にセパレーターとして使用されます。" - -#~ msgid "disk (vim.vm.FileLayout.DiskLayout, optional)" -#~ msgstr "disk (vim.vm.FileLayout.DiskLayout, optional)" - -#~ msgid "Files making up each virtual disk." -#~ msgstr "各仮想ディスクを作成するファイル。" - -#~ msgid "snapshot (vim.vm.FileLayout.SnapshotLayout, optional)" -#~ msgstr "snapshot (vim.vm.FileLayout.SnapshotLayout, optional)" - -#~ msgid "Files of each snapshot." -#~ msgstr "各スナップショットのファイル。" - -#~ msgid "swapFile (str, optional)" -#~ msgstr "swapFile (str, optional)" - -#~ msgid "The swapfile specific to the virtual machine, if any. This is a complete datastore path, not a relative path." -#~ msgstr "仮想マシンに固有のスワップファイル (存在する場合)。これは完全データストアパスであり、相対パスではありません。" - -#~ msgid "layoutEx" -#~ msgstr "layoutEx" - -#~ msgid "file (vim.vm.FileLayoutEx.FileInfo, optional)" -#~ msgstr "file (vim.vm.FileLayoutEx.FileInfo, optional)" - -#~ msgid "Information about all the files that constitute the virtual machine including configuration files, disks, swap file, suspend file, log files, core files, memory file and so on." -#~ msgstr "設定ファイル、ディスク、スワップファイル、一時停止ファイル、ログファイル、コアファイル、メモリーファイルなど、仮想マシンを構成するすべてのファイルに関する情報。" - -#~ msgid "disk (vim.vm.FileLayoutEx.DiskLayout, optional)" -#~ msgstr "disk (vim.vm.FileLayoutEx.DiskLayout, optional)" - -#~ msgid "Layout of each virtual disk attached to the virtual machine. For a virtual machine with snaphots, this property gives only those disks that are attached to it at the current point of running." -#~ msgstr "仮想マシンに接続されている各仮想ディスクのレイアウト。スナップショットを持つ仮想マシンでは、このプロパティーは、実行中の時点でアタッチされているディスクのみを提供します。" - -#~ msgid "snapshot (vim.vm.FileLayoutEx.SnapshotLayout, optional)" -#~ msgstr "snapshot (vim.vm.FileLayoutEx.SnapshotLayout, optional)" - -#~ msgid "Layout of each snapshot of the virtual machine." -#~ msgstr "仮想マシンの各スナップショットのレイアウト。" - -#~ msgid "timestamp (datetime)" -#~ msgstr "timestamp (datetime)" - -#~ msgid "Time when values in this structure were last updated." -#~ msgstr "この構造の値が最後に更新された時間。" - -#~ msgid "storage (vim.vm.StorageInfo)" -#~ msgstr "storage (vim.vm.StorageInfo)" - -#~ msgid "Storage space used by the virtual machine, split by datastore." -#~ msgstr "仮想マシンによって使用されるストレージ領域。データストアによって分割されます。" - -#~ msgid "perDatastoreUsage (vim.vm.StorageInfo.UsageOnDatastore, optional)" -#~ msgstr "perDatastoreUsage (vim.vm.StorageInfo.UsageOnDatastore, optional)" - -#~ msgid "Storage space used by the virtual machine on all datastores that it is located on. Total storage space committed to the virtual machine across all datastores is simply an aggregate of the property ``committed``" -#~ msgstr "仮想マシンが配置されているすべてのデータストアで使用されているストレージ領域。すべてのデータストアで仮想マシンにコミットされている総ストレージ容量は、単純にプロパティー ``committed`` を集約したものです。" - -#~ msgid "environmentBrowser (vim.EnvironmentBrowser)" -#~ msgstr "environmentBrowser (vim.EnvironmentBrowser)" - -#~ msgid "The current virtual machine's environment browser object. This contains information on all the configurations that can be used on the virtual machine. This is identical to the environment browser on the ComputeResource to which the virtual machine belongs." -#~ msgstr "現在の仮想マシンの環境ブラウザーオブジェクト。仮想マシンで使用できるすべての設定に関する情報が含まれます。これは、仮想マシンが属する ComputeResource の環境ブラウザーと同じです。" - -#~ msgid "datastoreBrowser (vim.host.DatastoreBrowser)" -#~ msgstr "datastoreBrowser (vim.host.DatastoreBrowser)" - -#~ msgid "DatastoreBrowser to browse datastores that are available on this entity." -#~ msgstr "DatastoreBrowser は、このエンティティーで利用可能なデータストアを参照します。" - -#~ msgid "resourcePool (vim.ResourcePool)" -#~ msgstr "resourcePool (vim.ResourcePool)" - -#~ msgid "The current resource pool that specifies resource allocation for the virtual machine. This property is set when a virtual machine is created or associated with a different resource pool. Returns null if the virtual machine is a template or the session has no access to the resource pool." -#~ msgstr "仮想マシンのリソース割り当てを指定する現在のリソースプール。このプロパティーは、仮想マシンが作成されたか、別のリソースプールに関連付けられたときに設定されます。仮想マシンがテンプレートであるか、セッションがリソースプールにアクセスできない場合は null を返します。" - -#~ msgid "summary (vim.ResourcePool.Summary)" -#~ msgstr "summary (vim.ResourcePool.Summary)" - -#~ msgid "Basic information about a resource pool." -#~ msgstr "リソースプールに関する基本情報。" - -#~ msgid "runtime (vim.ResourcePool.RuntimeInfo)" -#~ msgstr "runtime (vim.ResourcePool.RuntimeInfo)" - -#~ msgid "Runtime information about a resource pool." -#~ msgstr "リソースプールに関するランタイム情報。" - -#~ msgid "owner (vim.ComputeResource)" -#~ msgstr "owner (vim.ComputeResource)" - -#~ msgid "The ComputeResource to which this set of one or more nested resource pools belong." -#~ msgstr "1 つ以上のネストされたリソースプールのセットが属する ComputeResource。" - -#~ msgid "The set of child resource pools." -#~ msgstr "子リソースプールのセット。" - -#~ msgid "vm (vim.VirtualMachine)" -#~ msgstr "vm (vim.VirtualMachine)" - -#~ msgid "The set of virtual machines associated with this resource pool." -#~ msgstr "このリソースプールに関連付けられた仮想マシンのセット。" - -#~ msgid "config (vim.ResourceConfigSpec)" -#~ msgstr "config (vim.ResourceConfigSpec)" - -#~ msgid "Configuration of this resource pool." -#~ msgstr "このリソースプールの設定。" - -#~ msgid "childConfiguration (vim.ResourceConfigSpec)" -#~ msgstr "childConfiguration (vim.ResourceConfigSpec)" - -#~ msgid "The resource configuration of all direct children (VirtualMachine and ResourcePool) of this resource group." -#~ msgstr "このリソースグループのすべての直接の子 (VirtualMachine および ResourcePool) のリソース設定。" - -#~ msgid "parentVApp (vim.ManagedEntity)" -#~ msgstr "parentVApp (vim.ManagedEntity)" - -#~ msgid "Reference to the parent vApp." -#~ msgstr "親 vApp への参照。" - -#~ msgid "parent (vim.ManagedEntity)" -#~ msgstr "parent (vim.ManagedEntity)" - -#~ msgid "Parent of this entity. This value is null for the root object and for (VirtualMachine) objects that are part of a (VirtualApp)." -#~ msgstr "このエンティティーの親。ルートオブジェクトと、(VirtualApp) の一部である (VirtualMachine) オブジェクトの場合、この値は null です。" - -#~ msgid "customValue (vim.CustomFieldsManager.Value)" -#~ msgstr "customValue (vim.CustomFieldsManager.Value)" - -#~ msgid "Custom field values." -#~ msgstr "カスタムフィールドの値。" - -#~ msgid "overallStatus (vim.ManagedEntity.Status)" -#~ msgstr "overallStatus (vim.ManagedEntity.Status)" - -#~ msgid "General health of this managed entity." -#~ msgstr "この管理エンティティーの一般的な正常性。" - -#~ msgid "configStatus (vim.ManagedEntity.Status)" -#~ msgstr "configStatus (vim.ManagedEntity.Status)" - -#~ msgid "The configStatus indicates whether or not the system has detected a configuration issue involving this entity. For example, it might have detected a duplicate IP address or MAC address, or a host in a cluster might be out of ``compliance.property``." -#~ msgstr "configStatus は、システムがこのエンティティーに関連する設定問題を検出したかどうかを示します。たとえば、重複する IP アドレスまたは MAC アドレスを検出したり、クラスター内のホストが ``compliance.property`` 外の可能性があります。" - -#~ msgid "configIssue (vim.event.Event)" -#~ msgstr "configIssue (vim.event.Event)" - -#~ msgid "Current configuration issues that have been detected for this entity." -#~ msgstr "このエンティティーについて検出された現在の設定の問題。" - -#~ msgid "effectiveRole (int)" -#~ msgstr "effectiveRole (int)" - -#~ msgid "Access rights the current session has to this entity." -#~ msgstr "現在のセッションがこのエンティティーに対して設定されているアクセス権。" - -#~ msgid "permission (vim.AuthorizationManager.Permission)" -#~ msgstr "permission (vim.AuthorizationManager.Permission)" - -#~ msgid "List of permissions defined for this entity." -#~ msgstr "このエンティティーに定義されたパーミッションの一覧。" - -#~ msgid "Name of this entity, unique relative to its parent. Any / (slash), \\ (backslash), character used in this name element will be escaped. Similarly, any % (percent) character used in this name element will be escaped, unless it is used to start an escape sequence. A slash is escaped as %2F or %2f. A backslash is escaped as %5C or %5c, and a percent is escaped as %25." -#~ msgstr "このエンティティーの名前で、親との関係は一意です。/ (スラッシュ)、\\ (バックスラッシュ)、この名前要素で使用される文字がエスケープされます。同様に、エスケープ処理を開始するのに使用されていない限り、この名前要素で使用される % (パーセント) 文字はエスケープされます。スラッシュをエスケープする場合は %2F または %2f となり、バックスラッシュをエスケープする場合は %5C または %5c となり、パーセントをエスケープする場合は %25 となります。" - -#~ msgid "disabledMethod (str)" -#~ msgstr "disabledMethod (str)" - -#~ msgid "List of operations that are disabled, given the current runtime state of the entity. For example, a power-on operation always fails if a virtual machine is already powered on." -#~ msgstr "エンティティーの現在のランタイム状態を考慮して、無効となる操作のリスト。たとえば、仮想マシンの電源が入っている場合は常に、パワーオン操作は失敗します。" - -#~ msgid "recentTask (vim.Task)" -#~ msgstr "recentTask (vim.Task)" - -#~ msgid "The set of recent tasks operating on this managed entity. A task in this list could be in one of the four states: pending, running, success or error." -#~ msgstr "この管理エンティティーで動作する最近のタスクセット。このリストのタスクは、4 つの状態 (保留、実行、成功、またはエラー) のいずれかになります。" - -#~ msgid "declaredAlarmState (vim.alarm.AlarmState)" -#~ msgstr "declaredAlarmState (vim.alarm.AlarmState)" - -#~ msgid "A set of alarm states for alarms that apply to this managed entity." -#~ msgstr "この管理エンティティーに適用されるアラームのアラーム状態のセット。" - -#~ msgid "triggeredAlarmState (vim.alarm.AlarmState)" -#~ msgstr "triggeredAlarmState (vim.alarm.AlarmState)" - -#~ msgid "A set of alarm states for alarms triggered by this entity or by its descendants." -#~ msgstr "このエンティティーまたはその子孫によってトリガーされるアラームのアラーム状態のセット。" - -#~ msgid "alarmActionsEnabled (bool)" -#~ msgstr "alarmActionsEnabled (bool)" - -#~ msgid "Whether alarm actions are enabled for this entity. True if enabled; false otherwise." -#~ msgstr "このエンティティーに対してアラームアクションが有効になっているかどうか。有効な場合は True。そうでない場合は false。" - -#~ msgid "tag (vim.Tag)" -#~ msgstr "tag (vim.Tag)" - -#~ msgid "The set of tags associated with this managed entity. Experimental. Subject to change." -#~ msgstr "この管理エンティティーに関連付けられたタグのセット。実験的で、変更する可能性があります。" - -#~ msgid "resourceConfig (vim.ResourceConfigSpec)" -#~ msgstr "resourceConfig (vim.ResourceConfigSpec)" - -#~ msgid "The resource configuration for a virtual machine." -#~ msgstr "仮想マシンのリソース設定。" - -#~ msgid "entity (vim.ManagedEntity, optional)" -#~ msgstr "entity (vim.ManagedEntity, optional)" - -#~ msgid "Reference to the entity with this resource specification: either a VirtualMachine or a ResourcePool." -#~ msgstr "このリソース仕様を持つエンティティーへの参照 (VirtualMachine または ResourcePool のいずれか)。" - -#~ msgid "changeVersion (str, optional)" -#~ msgstr "changeVersion (str, optional)" - -#~ msgid "The changeVersion is a unique identifier for a given version of the configuration. Each change to the configuration will update this value. This is typically implemented as an ever increasing count or a time-stamp." -#~ msgstr "changeVersion は、設定の特定バージョンの一意の識別子です。設定への変更はそれぞれこの値を更新します。これは通常、増加し続けるカウントやタイムスタンプとして実装されます。" - -#~ msgid "lastModified (datetime, optional)" -#~ msgstr "lastModified (datetime, optional)" - -#~ msgid "Timestamp when the resources were last modified. This is ignored when the object is used to update a configuration." -#~ msgstr "リソースが最後に変更した時点のタイムスタンプ。これは、オブジェクトを使用して設定を更新する場合は無視されます。" - -#~ msgid "cpuAllocation (vim.ResourceAllocationInfo)" -#~ msgstr "cpuAllocation (vim.ResourceAllocationInfo)" - -#~ msgid "Resource allocation for CPU." -#~ msgstr "CPU のリソース割り当て。" - -#~ msgid "memoryAllocation (vim.ResourceAllocationInfo)" -#~ msgstr "memoryAllocation (vim.ResourceAllocationInfo)" - -#~ msgid "Resource allocation for memory." -#~ msgstr "メモリーのリソース割り当て。" - -#~ msgid "runtime (vim.vm.RuntimeInfo)" -#~ msgstr "runtime (vim.vm.RuntimeInfo)" - -#~ msgid "Execution state and history for the virtual machine." -#~ msgstr "仮想マシンの実行状態および履歴。" - -#~ msgid "device (vim.vm.DeviceRuntimeInfo, optional)" -#~ msgstr "device (vim.vm.DeviceRuntimeInfo, optional)" - -#~ msgid "Per-device runtime info. This array will be empty if the host software does not provide runtime info for any of the device types currently in use by the virtual machine." -#~ msgstr "デバイスごとのランタイム情報。ホストソフトウェアが、仮想マシンで現在使用されているデバイスタイプのランタイム情報を提供していない場合、この配列は空になります。" - -#~ msgid "host (vim.HostSystem, optional)" -#~ msgstr "host (vim.HostSystem, optional)" - -#~ msgid "The host that is responsible for running a virtual machine. This property is null if the virtual machine is not running and is not assigned to run on a particular host." -#~ msgstr "仮想マシンの実行を担当するホスト。このプロパティーは、仮想マシンが実行中ではなく、特定のホストで実行するように割り当てられていない場合に null になります。" - -#~ msgid "connectionState (vim.VirtualMachine.ConnectionState)" -#~ msgstr "connectionState (vim.VirtualMachine.ConnectionState)" - -#~ msgid "Indicates whether or not the virtual machine is available for management." -#~ msgstr "仮想マシンが管理に使用できるかどうかを示します。" - -#~ msgid "powerState (vim.VirtualMachine.PowerState)" -#~ msgstr "powerState (vim.VirtualMachine.PowerState)" - -#~ msgid "The current power state of the virtual machine." -#~ msgstr "仮想マシンの現在の状態。" - -#~ msgid "faultToleranceState (vim.VirtualMachine.FaultToleranceState)" -#~ msgstr "faultToleranceState (vim.VirtualMachine.FaultToleranceState)" - -#~ msgid "The fault tolerance state of the virtual machine." -#~ msgstr "仮想マシンのフォールトトレランス状態。" - -#~ msgid "dasVmProtection (vim.vm.RuntimeInfo.DasProtectionState, optional)" -#~ msgstr "dasVmProtection (vim.vm.RuntimeInfo.DasProtectionState, optional)" - -#~ msgid "The vSphere HA protection state for a virtual machine. Property is unset if vSphere HA is not enabled." -#~ msgstr "仮想マシンの vSphere HA 保護の状態。vSphere HA が有効になっていないと、プロパティーは設定されません。" - -#~ msgid "toolsInstallerMounted (bool)" -#~ msgstr "toolsInstallerMounted (bool)" - -#~ msgid "Flag to indicate whether or not the VMware Tools installer is mounted as a CD-ROM." -#~ msgstr "VMware Tool インストーラーが CD-ROM としてマウントされているかどうかを示すフラグ。" - -#~ msgid "suspendTime (datetime, optional)" -#~ msgstr "suspendTime (datetime, optional)" - -#~ msgid "The timestamp when the virtual machine was most recently suspended. This property is updated every time the virtual machine is suspended." -#~ msgstr "仮想マシンが最近一時停止された時点のタイムスタンプ。このプロパティーは、仮想マシンが一時停止されるたびに更新されます。" - -#~ msgid "bootTime (datetime, optional)" -#~ msgstr "bootTime (datetime, optional)" - -#~ msgid "The timestamp when the virtual machine was most recently powered on. This property is updated when the virtual machine is powered on from the poweredOff state, and is cleared when the virtual machine is powered off. This property is not updated when a virtual machine is resumed from a suspended state." -#~ msgstr "仮想マシンの電源が最後に入った時のタイムスタンプです。このプロパティーは、仮想マシンが、poweredOff 状態から電源がオンになると更新し、仮想マシンの電源がオフになる削除されます。このプロパティーは、仮想マシンが一時停止状態から再開したときには更新されません。" - -#~ msgid "suspendInterval (long, optional)" -#~ msgstr "suspendInterval (long, optional)" - -#~ msgid "The total time the virtual machine has been suspended since it was initially powered on. This time excludes the current period, if the virtual machine is currently suspended. This property is updated when the virtual machine resumes, and is reset to zero when the virtual machine is powered off." -#~ msgstr "仮想マシンの電源が最初に入ってから一時停止状態になっていた合計時間。この時間により、仮想マシンが現在一時停止になっている場合は、現在の期間が除外されます。このプロパティーは仮想マシンが再開したときに更新され、仮想マシンの電源オフ時にゼロにリセットされます。" - -#~ msgid "question (vim.vm.QuestionInfo, optional)" -#~ msgstr "question (vim.vm.QuestionInfo, optional)" - -#~ msgid "The current question, if any, that is blocking the virtual machine's execution." -#~ msgstr "仮想マシンの実行をブロックする現在の質問 (ある場合)。" - -#~ msgid "memoryOverhead (long, optional)" -#~ msgstr "memoryOverhead (long, optional)" - -#~ msgid "The amount of memory resource (in bytes) that will be used by the virtual machine above its guest memory requirements. This value is set if and only if the virtual machine is registered on a host that supports memory resource allocation features. For powered off VMs, this is the minimum overhead required to power on the VM on the registered host. For powered on VMs, this is the current overhead reservation, a value which is almost always larger than the minimum overhead, and which grows with time." -#~ msgstr "仮想マシンがゲストのメモリー要件を超えて使用するメモリーリソースの量 (バイト数) です。この値は、仮想マシンがメモリーリソースの割り当て機能に対応するホストに登録されている場合にのみ設定されます。仮想マシンの電源が切れている場合、これは登録されているホストの仮想マシンの電源を入れるために必要な最小のオーバーヘッドです。仮想マシンの電源が入っている場合、これは現在のオーバーヘッドの予約値で、ほとんどの場合、最小オーバーヘッドよりも大きく、時間とともに増加します。" - -#~ msgid "maxCpuUsage (int, optional)" -#~ msgstr "maxCpuUsage (int, optional)" - -#~ msgid "Current upper-bound on CPU usage. The upper-bound is based on the host the virtual machine is current running on, as well as limits configured on the virtual machine itself or any parent resource pool. Valid while the virtual machine is running." -#~ msgstr "CPU 使用率の現在の上限。上限は、仮想マシンが現在実行しているホストに基づき、仮想マシン自体または親リソースプールに設定された制限に基づいています。仮想マシンが実行中の間有効です。" - -#~ msgid "maxMemoryUsage (int, optional)" -#~ msgstr "maxMemoryUsage (int, optional)" - -#~ msgid "Current upper-bound on memory usage. The upper-bound is based on memory configuration of the virtual machine, as well as limits configured on the virtual machine itself or any parent resource pool. Valid while the virtual machine is running." -#~ msgstr "メモリー使用量の現在の上限。上限は仮想マシンのメモリー設定と、仮想マシン自体または親リソースプールに設定された制限に基づいています。仮想マシンが実行中の間は有効です。" - -#~ msgid "numMksConnections (int)" -#~ msgstr "numMksConnections (int)" - -#~ msgid "Number of active MKS connections to the virtual machine." -#~ msgstr "仮想マシンへのアクティブな MKS 接続の数。" - -#~ msgid "recordReplayState (vim.VirtualMachine.RecordReplayState)" -#~ msgstr "recordReplayState (vim.VirtualMachine.RecordReplayState)" - -#~ msgid "Record / replay state of the virtual machine." -#~ msgstr "仮想マシンの状態の記録/再生。" - -#~ msgid "cleanPowerOff (bool, optional)" -#~ msgstr "cleanPowerOff (bool, optional)" - -#~ msgid "For a powered off virtual machine, indicates whether the virtual machine's last shutdown was an orderly power off or not. Unset if the virtual machine is running or suspended." -#~ msgstr "仮想マシンの電源がオフの場合、仮想マシンの最後のシャットダウンが順序通り行われたかどうかを示します。仮想マシンが実行中か、サスペンドされていた場合は設定されません。" - -#~ msgid "needSecondaryReason (str, optional)" -#~ msgstr "needSecondaryReason (str, optional)" - -#~ msgid "If set, indicates the reason the virtual machine needs a secondary." -#~ msgstr "設定されていると、仮想マシンがセカンダリーを必要とする理由を示します。" - -#~ msgid "onlineStandby (bool)" -#~ msgstr "onlineStandby (bool)" - -#~ msgid "This property indicates whether the guest has gone into one of the s1, s2 or s3 standby modes. False indicates the guest is awake." -#~ msgstr "このプロパティーは、ゲストが s1、s2、または s3 のスタンバイモードのいずれかに切り替わったかどうかを示します。False は、ゲストが稼働していることを示しています。" - -#~ msgid "minRequiredEVCModeKey (str, optional)" -#~ msgstr "minRequiredEVCModeKey (str, optional)" - -#~ msgid "For a powered-on or suspended virtual machine in a cluster with Enhanced VMotion Compatibility (EVC) enabled, this identifies the least-featured EVC mode (among those for the appropriate CPU vendor) that could admit the virtual machine. This property will be unset if the virtual machine is powered off or is not in an EVC cluster. This property may be used as a general indicator of the CPU feature baseline currently in use by the virtual machine. However, the virtual machine may be suppressing some of the features present in the CPU feature baseline of the indicated mode, either explicitly (in the virtual machine's configured ``cpuFeatureMask``) or implicitly (in the default masks for the ``GuestOsDescriptor`` appropriate for the virtual machine's configured guest OS)." -#~ msgstr "EVC (Enhanced VMotion Compatibility) が有効になっているクラスターで仮想マシンの電源が入っている、または一時停止している場合、これは仮想マシンを許可する可能性がある最小機能の EVC モード (適切な CPU ベンダー用) を特定します。仮想マシンの電源がオフの場合、または EVC クラスターにない場合は、このプロパティーの設定を解除します。このプロパティーは、仮想マシンが現在使用している CPU 機能ベースラインの一般的なインジケーターとして使用できます。ただし、仮想マシンは、明示的 (仮想マシンの設定済み ``cpuFeatureMask``) または暗黙的 (仮想マシンの設定済みゲスト OS に適切な ``GuestOsDescriptor`` のデフォルトマスク) に指定したモードの CPU 機能ベースラインに存在する機能の一部を抑制している可能性があります。" - -#~ msgid "consolidationNeeded (bool)" -#~ msgstr "consolidationNeeded (bool)" - -#~ msgid "Whether any disk of the virtual machine requires consolidation. This can happen for example when a snapshot is deleted but its associated disk is not committed back to the base disk." -#~ msgstr "仮想マシンのディスクが統合する必要があるかどうか。これは、スナップショットが削除されても、関連付けられたディスクがベースディスクにコミットされない場合などに発生する可能性があります。" - -#~ msgid "offlineFeatureRequirement (vim.vm.FeatureRequirement, optional)" -#~ msgstr "offlineFeatureRequirement (vim.vm.FeatureRequirement, optional)" - -#~ msgid "These requirements must have equivalent host capabilities ``featureCapability`` in order to power on." -#~ msgstr "これらの要件には、電源を入れるのに同等のホスト機能 ``featureCapability`` が必要です。" - -#~ msgid "featureRequirement (vim.vm.FeatureRequirement, optional)" -#~ msgstr "featureRequirement (vim.vm.FeatureRequirement, optional)" - -#~ msgid "These requirements must have equivalent host capabilities ``featureCapability`` in order to power on, resume, or migrate to the host." -#~ msgstr "ホストの電源オン、再開、または移行を行うには、これらの要件に同等のホスト機能 ``featureCapability`` が必要です。" - -#~ msgid "featureMask (vim.host.FeatureMask, optional)" -#~ msgstr "featureMask (vim.host.FeatureMask, optional)" - -#~ msgid "The masks applied to an individual virtual machine as a result of its configuration." -#~ msgstr "設定の結果として、個々の仮想マシンに適用されるマスク。" - -#~ msgid "vFlashCacheAllocation (long, optional)" -#~ msgstr "vFlashCacheAllocation (long, optional)" - -#~ msgid "Specifies the total allocated vFlash resource for the vFlash caches associated with VM's VMDKs when VM is powered on, in bytes." -#~ msgstr "仮想マシンの電源が入ったときに、仮想マシンの VMDK に関連付けられた vFlash キャッシュに割り当てられる vFlash リソースの合計をバイト単位で指定します。" - -#~ msgid "guest (vim.vm.GuestInfo)" -#~ msgstr "guest (vim.vm.GuestInfo)" - -#~ msgid "Information about VMware Tools and about the virtual machine from the perspective of VMware Tools. Information about the guest operating system is available in VirtualCenter. Guest operating system information reflects the last known state of the virtual machine. For powered on machines, this is current information. For powered off machines, this is the last recorded state before the virtual machine was powered off." -#~ msgstr "VMware Tool に関する情報、および VMware Tool ツールから見た仮想マシンに関する情報。ゲストオペレーティングシステムに関する情報は、VirtualCenter で利用できます。ゲストオペレーティングシステムの情報には、仮想マシンの最後の既知の状態を反映します。マシンの電源が入っていると、これは現在の情報になります。マシンの電源が切れていると、仮想マシンの電源が切れる前に最後に記録された状態になります。" - -#~ msgid "toolsStatus (vim.vm.GuestInfo.ToolsStatus, optional)" -#~ msgstr "toolsStatus (vim.vm.GuestInfo.ToolsStatus, optional)" - -#~ msgid "Current status of VMware Tools in the guest operating system, if known." -#~ msgstr "ゲストオペレーティングシステムの VMware Tool の現在の状態 (判明している場合)。" - -#~ msgid "toolsVersionStatus (str, optional)" -#~ msgstr "toolsVersionStatus (str, optional)" - -#~ msgid "Current version status of VMware Tools in the guest operating system, if known." -#~ msgstr "ゲストオペレーティングシステムの VMware ツールの現在のバージョンステータス (判明している場合)。" - -#~ msgid "toolsVersionStatus2 (str, optional)" -#~ msgstr "toolsVersionStatus2 (str, optional)" - -#~ msgid "toolsRunningStatus (str, optional)" -#~ msgstr "toolsRunningStatus (str, optional)" - -#~ msgid "Current running status of VMware Tools in the guest operating system, if known." -#~ msgstr "ゲストオペレーティングシステムの VMware ツールの現在の実行ステータス (判明している場合)。" - -#~ msgid "toolsVersion (str, optional)" -#~ msgstr "toolsVersion (str, optional)" - -#~ msgid "Current version of VMware Tools, if known." -#~ msgstr "VMware ツールの現行バージョン (判明している場合)。" - -#~ msgid "guestId (str, optional)" -#~ msgstr "guestId (str, optional)" - -#~ msgid "Guest operating system identifier (short name), if known." -#~ msgstr "既知の場合は、ゲストオペレーティングシステム識別子 (短縮名)。" - -#~ msgid "guestFamily (str, optional)" -#~ msgstr "guestFamily (str, optional)" - -#~ msgid "Guest operating system family, if known." -#~ msgstr "ゲストオペレーティングシステムファミリー (判明している場合)。" - -#~ msgid "guestFullName (str, optional)" -#~ msgstr "guestFullName (str, optional)" - -#~ msgid "See :ref:`guest_full_name`." -#~ msgstr "「:ref:`guest_full_name`」を参照してください。" - -#~ msgid "hostName (str, optional)" -#~ msgstr "hostName (str, optional)" - -#~ msgid "Hostname of the guest operating system, if known." -#~ msgstr "ゲストオペレーティングシステムのホスト名 (判明している場合)。" - -#~ msgid "ipAddress (str, optional)" -#~ msgstr "ipAddress (str, optional)" - -#~ msgid "Primary IP address assigned to the guest operating system, if known." -#~ msgstr "ゲストオペレーティングシステムに割り当てられるプライマリー IP アドレス (判明している場合)。" - -#~ msgid "net (vim.vm.GuestInfo.NicInfo, optional)" -#~ msgstr "net (vim.vm.GuestInfo.NicInfo, optional)" - -#~ msgid "Guest information about network adapters, if known." -#~ msgstr "ネットワークアダプターに関するゲスト情報 (判明している場合)。" - -#~ msgid "ipStack (vim.vm.GuestInfo.StackInfo, optional)" -#~ msgstr "ipStack (vim.vm.GuestInfo.StackInfo, optional)" - -#~ msgid "Guest information about IP networking stack, if known." -#~ msgstr "IP ネットワークスタックに関するゲスト情報 (判明している場合)。" - -#~ msgid "disk (vim.vm.GuestInfo.DiskInfo, optional)" -#~ msgstr "disk (vim.vm.GuestInfo.DiskInfo, optional)" - -#~ msgid "Guest information about disks. You can obtain Linux guest disk information for the following file system types only: Ext2, Ext3, Ext4, ReiserFS, ZFS, NTFS, VFAT, UFS, PCFS, HFS, and MS-DOS." -#~ msgstr "ディスクに関するゲスト情報。次のファイルシステムタイプの Linux ゲストディスク情報を取得できます (Ext2、Ext3、Ext4、ReiserFS、ZFS、NTFS、VFAT、UFS、PCFS、HFS、および MS-DOS)。" - -#~ msgid "screen (vim.vm.GuestInfo.ScreenInfo, optional)" -#~ msgstr "screen (vim.vm.GuestInfo.ScreenInfo, optional)" - -#~ msgid "Guest screen resolution info, if known." -#~ msgstr "ゲスト画面の解像度情報 (判明している場合)。" - -#~ msgid "guestState (str)" -#~ msgstr "guestState (str)" - -#~ msgid "Operation mode of guest operating system." -#~ msgstr "ゲストオペレーティングシステムの操作モード。" - -#~ msgid "appHeartbeatStatus (str, optional)" -#~ msgstr "appHeartbeatStatus (str, optional)" - -#~ msgid "Application heartbeat status." -#~ msgstr "アプリケーションのハートビート状態。" - -#~ msgid "appState (str, optional)" -#~ msgstr "appState (str, optional)" - -#~ msgid "Application state. If vSphere HA is enabled and the vm is configured for Application Monitoring and this field's value is ``appStateNeedReset`` then HA will attempt immediately reset the virtual machine. There are some system conditions which may delay the immediate reset. The immediate reset will be performed as soon as allowed by vSphere HA and ESX. If during these conditions the value is changed to ``appStateOk`` the reset will be cancelled." -#~ msgstr "アプリケーションの状態。vSphere HA が有効で、仮想マシンがアプリケーション監視用に設定されていて、およびこのフィールドの値が ``appStateNeedReset`` の場合、HA は仮想マシンの即時リセットを試みます。システムの状態によっては、即時リセットが遅れる場合があります。即時リセットは、vSphere HA と ESX で許可されるとすぐに、即時リセットが実行されます。これらの条件で値が ``appStateOk`` に変更になると、リセットが取り消されます。" - -#~ msgid "guestOperationsReady (bool, optional)" -#~ msgstr "guestOperationsReady (bool, optional)" - -#~ msgid "Guest Operations availability. If true, the vitrual machine is ready to process guest operations." -#~ msgstr "ゲスト操作の可用性。true の場合は、ゲスト操作を処理する準備が整います。" - -#~ msgid "interactiveGuestOperationsReady (bool, optional)" -#~ msgstr "interactiveGuestOperationsReady (bool, optional)" - -#~ msgid "Interactive Guest Operations availability. If true, the virtual machine is ready to process guest operations as the user interacting with the guest desktop." -#~ msgstr "インタラクティブなゲスト操作の可用性。true の場合は、ゲストデスクトップと対話するユーザーがゲスト操作を処理する準備が整います。" - -#~ msgid "generationInfo (vim.vm.GuestInfo.NamespaceGenerationInfo, privilege: VirtualMachine.Namespace.EventNotify, optional)" -#~ msgstr "generationInfo (vim.vm.GuestInfo.NamespaceGenerationInfo, privilege: VirtualMachine.Namespace.EventNotify, optional)" - -#~ msgid "A list of namespaces and their corresponding generation numbers. Only namespaces with non-zero ``maxSizeEventsFromGuest`` are guaranteed to be present here." -#~ msgstr "名前空間の一覧とそれに対応する生成番号。ゼロ以外の ``maxSizeEventsFromGuest`` の名前空間のみがここに存在することが保証されます。" - -#~ msgid "summary (vim.vm.Summary)" -#~ msgstr "summary (vim.vm.Summary)" - -#~ msgid "Basic information about the virtual machine." -#~ msgstr "仮想マシンに関する基本情報。" - -#~ msgid "vm (vim.VirtualMachine, optional)" -#~ msgstr "vm (vim.VirtualMachine, optional)" - -#~ msgid "Reference to the virtual machine managed object." -#~ msgstr "仮想マシン管理オブジェクトへの参照。" - -#~ msgid "Runtime and state information of a running virtual machine. Most of this information is also available when a virtual machine is powered off. In that case, it contains information from the last run, if available." -#~ msgstr "実行中の仮想マシンのランタイムおよび状態の情報。この情報のほとんどは、仮想マシンの電源が切れたときにも利用できます。その場合は、最後の実行からの情報 (利用可能な場合) が含まれます。" - -#~ msgid "guest (vim.vm.Summary.GuestSummary, optional)" -#~ msgstr "guest (vim.vm.Summary.GuestSummary, optional)" - -#~ msgid "Guest operating system and VMware Tools information." -#~ msgstr "ゲストオペレーティングシステムおよび VMware Tool の情報。" - -#~ msgid "config (vim.vm.Summary.ConfigSummary)" -#~ msgstr "config (vim.vm.Summary.ConfigSummary)" - -#~ msgid "Basic configuration information about the virtual machine. This information is not available when the virtual machine is unavailable, for instance, when it is being created or deleted." -#~ msgstr "仮想マシンの基本的な設定情報です。この情報は、仮想マシンの作成時や削除時など、仮想マシンが利用できないときには利用できません。" - -#~ msgid "storage (vim.vm.Summary.StorageSummary, optional)" -#~ msgstr "storage (vim.vm.Summary.StorageSummary, optional)" - -#~ msgid "Storage information of the virtual machine." -#~ msgstr "仮想マシンのストレージ情報。" - -#~ msgid "quickStats (vim.vm.Summary.QuickStats)" -#~ msgstr "quickStats (vim.vm.Summary.QuickStats)" - -#~ msgid "A set of statistics that are typically updated with near real-time regularity." -#~ msgstr "通常、ほぼリアルタイム正規表現で更新される統計セット。" - -#~ msgid "Overall alarm status on this node." -#~ msgstr "このノードの全体的なアラーム状態。" - -#~ msgid "customValue (vim.CustomFieldsManager.Value, optional)" -#~ msgstr "customValue (vim.CustomFieldsManager.Value, optional)" - -#~ msgid "datastore (vim.Datastore)" -#~ msgstr "datastore (vim.Datastore)" - -#~ msgid "A collection of references to the subset of datastore objects in the datacenter that is used by the virtual machine." -#~ msgstr "仮想マシンが使用するデータセンターのデータストアオブジェクトのサブセットへの参照のコレクション。" - -#~ msgid "info (vim.Datastore.Info)" -#~ msgstr "info (vim.Datastore.Info)" - -#~ msgid "Specific information about the datastore." -#~ msgstr "データストアに関する具体的な情報。" - -#~ msgid "summary (vim.Datastore.Summary)" -#~ msgstr "summary (vim.Datastore.Summary)" - -#~ msgid "Global properties of the datastore." -#~ msgstr "データストアのグローバルプロパティー。" - -#~ msgid "host (vim.Datastore.HostMount)" -#~ msgstr "host (vim.Datastore.HostMount)" - -#~ msgid "Hosts attached to this datastore." -#~ msgstr "このデータストアに接続されたホスト。" - -#~ msgid "Virtual machines stored on this datastore." -#~ msgstr "このデータストアに保存されている仮想マシン。" - -#~ msgid "browser (vim.host.DatastoreBrowser)" -#~ msgstr "browser (vim.host.DatastoreBrowser)" - -#~ msgid "DatastoreBrowser used to browse this datastore." -#~ msgstr "このデータストアの閲覧に使用する DatastoreBrowser。" - -#~ msgid "capability (vim.Datastore.Capability)" -#~ msgstr "capability (vim.Datastore.Capability)" - -#~ msgid "Capabilities of this datastore." -#~ msgstr "このデータストアの機能。" - -#~ msgid "iormConfiguration (vim.StorageResourceManager.IORMConfigInfo)" -#~ msgstr "iormConfiguration (vim.StorageResourceManager.IORMConfigInfo)" - -#~ msgid "Configuration of storage I/O resource management for the datastore. Currently VMware only support storage I/O resource management on VMFS volumes of a datastore. This configuration may not be available if the datastore is not accessible from any host, or if the datastore does not have VMFS volume." -#~ msgstr "データストアのストレージ I/O リソース管理の設定。現在、VMware は、データストアの VMFS ボリュームでのストレージ I/O リソース管理のみをサポートします。この設定は、データストアがいずれかのホストからアクセスできない場合や、データストアに VMFS ボリュームがない場合には利用できません。" - -#~ msgid "network (vim.Network)" -#~ msgstr "network (vim.Network)" - -#~ msgid "A collection of references to the subset of network objects in the datacenter that is used by the virtual machine." -#~ msgstr "仮想マシンが使用するデータセンター内のネットワークオブジェクトのサブセットへの参照のコレクション。" - -#~ msgid "Name of this network." -#~ msgstr "このネットワークの名前。" - -#~ msgid "summary (vim.Network.Summary)" -#~ msgstr "summary (vim.Network.Summary)" - -#~ msgid "Properties of a network." -#~ msgstr "ネットワークのプロパティー。" - -#~ msgid "host (vim.HostSystem)" -#~ msgstr "host (vim.HostSystem)" - -#~ msgid "Hosts attached to this network." -#~ msgstr "このネットワークに接続されたホスト。" - -#~ msgid "Virtual machines using this network." -#~ msgstr "このネットワークを使用する仮想マシン。" - -#~ msgid "snapshot (vim.vm.SnapshotInfo)" -#~ msgstr "snapshot (vim.vm.SnapshotInfo)" - -#~ msgid "Current snapshot and tree. The property is valid if snapshots have been created for the virtual machine." -#~ msgstr "現在のスナップショットおよびツリー。このプロパティーは、仮想マシン用にスナップショットが作成された場合に有効です。" - -#~ msgid "currentSnapshot (vim.vm.Snapshot, optional)" -#~ msgstr "currentSnapshot (vim.vm.Snapshot, optional)" - -#~ msgid "Current snapshot of the virtual machineThis property is set by calling ``Snapshot.revert`` or ``VirtualMachine.createSnapshot``. This property will be empty when the working snapshot is at the root of the snapshot tree." -#~ msgstr "仮想マシンの現在のスナップショット。このプロパティーは、``Snapshot.revert`` または ``VirtualMachine.createSnapshot`` を呼び出すことで設定されます。このプロパティーは、作業スナップショットがスナップショットツリーのルートにあると空になります。" - -#~ msgid "rootSnapshotList (vim.vm.SnapshotTree)" -#~ msgstr "rootSnapshotList (vim.vm.SnapshotTree)" - -#~ msgid "Data for the entire set of snapshots for one virtual machine." -#~ msgstr "1 台の仮想マシンのスナップショットの全セットのデータ。" - -#~ msgid "rootSnapshot (vim.vm.Snapshot)" -#~ msgstr "rootSnapshot (vim.vm.Snapshot)" - -#~ msgid "The roots of all snapshot trees for the virtual machine." -#~ msgstr "仮想マシンのすべてのスナップショットツリーのルート。" - -#~ msgid "config (vim.vm.ConfigInfo)" -#~ msgstr "config (vim.vm.ConfigInfo)" - -#~ msgid "Information about the configuration of the virtual machine when this snapshot was taken. The datastore paths for the virtual machine disks point to the head of the disk chain that represents the disk at this given snapshot." -#~ msgstr "このスナップショットが取られた時点の仮想マシンの設定に関する情報。仮想マシンディスクのデータストアパスは、この指定したスナップショットのディスクを表すディスクチェーンのヘッドを参照します。" - -#~ msgid "childSnapshot (vim.vm.Snapshot)" -#~ msgstr "childSnapshot (vim.vm.Snapshot)" - -#~ msgid "All snapshots for which this snapshot is the parent." -#~ msgstr "このスナップショットが親であるすべてのスナップショット。" - -#~ msgid "guestHeartbeatStatus (vim.ManagedEntity.Status)" -#~ msgstr "guestHeartbeatStatus (vim.ManagedEntity.Status)" - -#~ msgid "The guest heartbeat." -#~ msgstr "ゲストのハートビート。" - -#~ msgid "rst/scenario_guides/guide_vmware.rst" -#~ msgstr "rst/scenario_guides/guide_vmware.rst" - -#~ msgid "Ansible VMware Module Guide" -#~ msgstr "Ansible VMware モジュールガイド" - -#~ msgid "This will be a listing similar to the module index in our core docs." -#~ msgstr "ここでは、コアドキュメントのモジュールインデックスと同様のリストを紹介します。" - -#~ msgid "VMware Prerequisites" -#~ msgstr "VMware の要件" - -#~ msgid "Installing SSL Certificates" -#~ msgstr "SSL 証明書のインストール" - -#~ msgid "All vCenter and ESXi servers require SSL encryption on all connections to enforce secure communication. You must enable SSL encryption for Ansible by installing the server's SSL certificates on your Ansible control node or delegate node." -#~ msgstr "すべての vCenter サーバーおよび ESXi サーバーでは、安全な通信を実現するために、すべての接続に SSL 暗号化が必要です。サーバーの SSL 証明書を Ansible コントロールノードまたは委譲ノードにインストールして、Ansible の SSL 暗号化を有効にする必要があります。" - -#~ msgid "If the SSL certificate of your vCenter or ESXi server is not correctly installed on your Ansible control node, you will see the following warning when using Ansible VMware modules:" -#~ msgstr "vCenter サーバーまたは ESXi サーバーの SSL 証明書が Ansible コントロールノードに正しくインストールされていない場合は、Ansible VMware モジュールを使用する際に以下の警告が表示されます。" - -#~ msgid "``Unable to connect to vCenter or ESXi API at xx.xx.xx.xx on TCP/443: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)``" -#~ msgstr "``Unable to connect to vCenter or ESXi API at xx.xx.xx.xx on TCP/443: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)``" - -#~ msgid "To install the SSL certificate for your VMware server, and run your Ansible VMware modules in encrypted mode, please follow the instructions for the server you are running with VMware." -#~ msgstr "VMware サーバーに SSL 証明書をインストールし、Ansible VMware モジュールを暗号化モードで実行するには、VMware で実行しているサーバーの手順に従ってください。" - -#~ msgid "Installing vCenter SSL certificates for Ansible" -#~ msgstr "Ansible 用の vCenter SSL 証明書のインストール" - -#~ msgid "From any web browser, go to the base URL of the vCenter Server without port number like ``https://vcenter-domain.example.com``" -#~ msgstr "任意の Web ブラウザーから、``https://vcenter-domain.example.com`` などポート番号のない vCenter Server のベース URL に移動します。" - -#~ msgid "Click the \"Download trusted root CA certificates\" link at the bottom of the grey box on the right and download the file." -#~ msgstr "右側の灰色の領域の下部にある「Download trusted root CA certificates (信頼されたルート CA 証明書のダウンロード)」のリンクをクリックして、ファイルをダウンロードします。" - -#~ msgid "Change the extension of the file to .zip. The file is a ZIP file of all root certificates and all CRLs." -#~ msgstr "ファイルの拡張子を .zip に変更します。このファイルは、すべてのルート証明書とすべての CRL が含まれる ZIP ファイルです。" - -#~ msgid "Extract the contents of the zip file. The extracted directory contains a ``.certs`` directory that contains two types of files. Files with a number as the extension (.0, .1, and so on) are root certificates." -#~ msgstr "zip ファイルの内容を展開します。展開したディレクトリーには、両タイプのファイルが含まれる ``.certs`` ディレクトリーが含まれます。数字が拡張子 (.0、.1 など) になっているファイルは、ルート証明書です。" - -#~ msgid "Install the certificate files are trusted certificates by the process that is appropriate for your operating system." -#~ msgstr "証明書ファイルを、オペレーティングシステムに適したプロセスで信頼されている証明書にインストールします。" - -#~ msgid "Installing ESXi SSL certificates for Ansible" -#~ msgstr "Ansible 用の ESXi SSL 証明書のインストール" - -#~ msgid "Enable SSH Service on ESXi either by using Ansible VMware module `vmware_host_service_manager `_ or manually using vSphere Web interface." -#~ msgstr "Ansible VMware モジュール `vmware_host_service_manager `_ を使用するか、vSphere Web インターフェースを手動で使用して、ESXi で SSH サービスを有効にします。" - -#~ msgid "SSH to ESXi server using administrative credentials, and navigate to directory ``/etc/vmware/ssl``" -#~ msgstr "管理認証情報を使用して ESXi サーバーに SSH 接続し、``/etc/vmware/ssl`` ディレクトリーに移動します。" - -#~ msgid "Secure copy (SCP) ``rui.crt`` located in ``/etc/vmware/ssl`` directory to Ansible control node." -#~ msgstr "``/etc/vmware/ssl`` ディレクトリーにある SCP (Secure Copy) ``rui.crt`` を Ansible コントロールノードへ置きます。" - -#~ msgid "Install the certificate file by the process that is appropriate for your operating system." -#~ msgstr "オペレーティングシステムに適したプロセスで、証明書ファイルをインストールします。" - -#~ msgid "Using custom path for SSL certificates" -#~ msgstr "SSL 証明書のカスタムパスの使用" - -#~ msgid "If you need to use a custom path for SSL certificates, you can set the ``REQUESTS_CA_BUNDLE`` environment variable in your playbook." -#~ msgstr "SSL 証明書にカスタムパスを使用しないといけない場合は、Playbook に ``REQUESTS_CA_BUNDLE`` 環境変数を設定することができます。" - -#~ msgid "For example, if ``/var/vmware/certs/vcenter1.crt`` is the SSL certificate for your vCenter Server, you can use the :ref:`environment ` keyword to pass it to the modules:" -#~ msgstr "たとえば、``/var/vmware/certs/vcenter1.crt`` が vCenter Server の SSL 証明書である場合は、:ref:`environment ` キーワードを使用してモジュールに渡すことができます。" - -#~ msgid "Ansible for VMware Scenarios" -#~ msgstr "VMware シナリオにおける Ansible" - -#~ msgid "These scenarios teach you how to accomplish common VMware tasks using Ansible. To get started, please select the task you want to accomplish." -#~ msgstr "以下のシナリオでは、Ansible を使用して一般的な VMware タスクを実行する方法を説明します。最初に、実行するタスクを選択してください。" - -#~ msgid "Troubleshooting Ansible for VMware" -#~ msgstr "Ansible for VMware のトラブルシューティング" - -#~ msgid "This section lists things that can go wrong and possible ways to fix them." -#~ msgstr "本セクションでは、問題が発生する可能性があるものと、その修正方法を紹介します。" - -#~ msgid "Debugging Ansible for VMware" -#~ msgstr "Ansible for VMware のデバッグ" - -#~ msgid "When debugging or creating a new issue, you will need information about your VMware infrastructure. You can get this information using `govc `_, For example:" -#~ msgstr "新しい問題をデバッグまたは作成する場合は、VMware インフラストラクチャーに関する情報が必要になります。この情報は、`govc `_ を使用して取得できます。以下に例を示します。" - -#~ msgid "Known issues with Ansible for VMware" -#~ msgstr "Ansible for VMware に関する既知の問題" - -#~ msgid "Network settings with vmware_guest in Ubuntu 18.04" -#~ msgstr "Ubuntu 18.04 で vmware_guest を使用したネットワーク設定" - -#~ msgid "Setting the network with ``vmware_guest`` in Ubuntu 18.04 is known to be broken, due to missing support for ``netplan`` in the ``open-vm-tools``. This issue is tracked via:" -#~ msgstr "``open-vm-tools`` に ``netplan`` のサポートがないため、Ubuntu 18.04 で ``vmware_guest`` を使用してネットワークを設定すると破損することが知られています。これは以下の問題で追跡されています。" - -#~ msgid "https://github.com/vmware/open-vm-tools/issues/240" -#~ msgstr "https://github.com/vmware/open-vm-tools/issues/240" - -#~ msgid "https://github.com/ansible/ansible/issues/41133" -#~ msgstr "https://github.com/ansible/ansible/issues/41133" - -#~ msgid "Potential Workarounds" -#~ msgstr "潜在的な回避策" - -#~ msgid "There are several workarounds for this issue." -#~ msgstr "この問題には、複数の回避策があります。" - -#~ msgid "Modify the Ubuntu 18.04 images and installing ``ifupdown`` in them via ``sudo apt install ifupdown``. If so you need to remove ``netplan`` via ``sudo apt remove netplan.io`` and you need stop ``systemd-networkd`` via ``sudo systemctl disable systemctl-networkd``." -#~ msgstr "Ubuntu 18.04 イメージを変更し、``sudo apt install ifupdown`` で ``ifupdown`` をインストールします。この場合、``sudo apt remove netplan.io`` から ``netplan`` を削除して、``sudo systemctl disable systemctl-networkd`` で ``systemd-networkd`` を停止する必要があります。" - -#~ msgid "Generate the ``systemd-networkd`` files with a task in your VMware Ansible role:" -#~ msgstr "VMware Ansible ロールでタスクを使用して ``systemd-networkd`` ファイルを生成します。" - -#~ msgid "Wait for ``netplan`` support in ``open-vm-tools``" -#~ msgstr "``open-vm-tools`` で ``netplan`` がサポートされるのを待ちます。" - -#~ msgid "To pass Active Directory username/password in ADFS via the environment, define the following variables:" -#~ msgstr "環境経由で Active Directory のユーザー名/パスワードを渡すには、以下の変数を定義します。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/shared_snippets.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/shared_snippets.po deleted file mode 100644 index cd0173cb9a9..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/shared_snippets.po +++ /dev/null @@ -1,31 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../rst/shared_snippets/installing_collections_file.rst:1 -msgid "Ansible can also install from a source directory in several ways:" -msgstr "Ansible は、複数の方法でソースディレクトリーからインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_file.rst:14 -msgid "Ansible can also install a collection collected with ``ansible-galaxy collection build`` or downloaded from Galaxy for offline use by specifying the output file directly:" -msgstr "出力ファイルを直接指定して、Ansible は``ansible-galaxy collection build`` で収集したコレクションまたは Galaxy からダウンロードしたコレクションをオフライン用にインストールすることもできます。" - -#: ../../rst/shared_snippets/installing_collections_file.rst:24 -msgid "Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file." -msgstr "相対パスは、現在の作業ディレクトリー（``ansible-galaxy install -r`` を呼び出しているディレクトリー）から計算されます。これは、``requirements.yml`` ファイルからの相対パスではありません。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/sphinx.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/sphinx.po deleted file mode 100644 index fd416915975..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/sphinx.po +++ /dev/null @@ -1,36 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../.templates/breadcrumbs.html:8 ../../.templates/breadcrumbs.html:26 -#: ../../.templates/breadcrumbs.html:28 -msgid "Edit on GitHub" -msgstr "GitHub で編集" - -#: ../../.templates/breadcrumbs.html:34 ../../.templates/breadcrumbs.html:36 -msgid "Edit on Bitbucket" -msgstr "Bitbucket で編集" - -#: ../../.templates/breadcrumbs.html:41 ../../.templates/breadcrumbs.html:43 -msgid "Edit on GitLab" -msgstr "GitLab で編集" - -#: ../../.templates/breadcrumbs.html:46 ../../.templates/breadcrumbs.html:48 -msgid "View page source" -msgstr "ページソースの表示" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/tips_tricks.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/tips_tricks.po deleted file mode 100644 index 252137bddce..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/tips_tricks.po +++ /dev/null @@ -1,457 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:4 -msgid "General tips" -msgstr "一般的なヒント" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:6 -msgid "These concepts apply to all Ansible activities and artifacts." -msgstr "この概念は、すべての Ansible アクティビティーおよびアーティファクトに適用されます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:9 -msgid "Keep it simple" -msgstr "シンプルに" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:11 -msgid "Whenever you can, do things simply. Use advanced features only when necessary, and select the feature that best matches your use case. For example, you will probably not need ``vars``, ``vars_files``, ``vars_prompt`` and ``--extra-vars`` all at once, while also using an external inventory file. If something feels complicated, it probably is. Take the time to look for a simpler solution." -msgstr "できる限りシンプルに。高度な機能は必要な場合にのみ使用し、自身のユースケースに最も一致した機能を選択してください。たとえば、外部のインベントリーファイルを使用しながら、``vars``、``vars_files``、``vars_prompt``、および ``--extra-vars`` を一度に使用することはないでしょう。何かが複雑に感じられる場合は、おそらく複雑なのです。時間をかけて、よりシンプルなソリューションを探してみてください。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:16 -msgid "Use version control" -msgstr "バージョン制御を使用する" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:18 -msgid "Keep your playbooks, roles, inventory, and variables files in git or another version control system and make commits to the repository when you make changes. Version control gives you an audit trail describing when and why you changed the rules that automate your infrastructure." -msgstr "Playbook、ロール、インベントリー、変数などのファイルを git などのバージョン管理システムで管理し、変更があった場合はリポジトリーにコミットします。バージョン管理は、インフラストラクチャーを自動化するルールをいつ、なぜ変更したかを示す監査証跡となります。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:22 -msgid "Customize the CLI output" -msgstr "CLI 出力のカスタマイズ" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:24 -msgid "You can change the output from Ansible CLI commands using :ref:`callback_plugins`." -msgstr ":ref:`callback_plugins` を使用して、Ansible CLI コマンドからの出力を変更できます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:29 -msgid "Playbook tips" -msgstr "Playbook のヒント" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:31 -msgid "These tips help make playbooks and roles easier to read, maintain, and debug." -msgstr "このヒントは、Playbook とロールの読み取り、維持、およびデバッグを容易にするのに役立ちます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:34 -msgid "Use whitespace" -msgstr "空白を使用する" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:36 -msgid "Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan." -msgstr "各ブロックやタスクの前に空の行など、空白を使用すると Playbook を簡単にスキャンできます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:39 -msgid "Always name tasks" -msgstr "常にタスクに名前を付ける" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:41 -msgid "Task names are optional, but extremely useful. In its output, Ansible shows you the name of each task it runs. Choose names that describe what each task does and why." -msgstr "タスク名は任意ですが、非常に便利なものになります。その出力で、Ansible では、実行する各タスクの名前が記載されます。各タスクの機能や理由を説明する名前を選択します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:45 -msgid "Always mention the state" -msgstr "状態について常に言及する" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:47 -msgid "For many modules, the 'state' parameter is optional. Different modules have different default settings for 'state', and some modules support several 'state' settings. Explicitly setting 'state=present' or 'state=absent' makes playbooks and roles clearer." -msgstr "多くのモジュールでは、「state」パラメーターは任意です。モジュールによって「state」のデフォルト設定は異なり、複数の「state」設定をサポートしているモジュールもあります。「state=present」や「state=absent」を明示的に設定することで、Playbook やロールがより明確になります。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:52 -msgid "Use comments" -msgstr "コマンドを使用する" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:54 -msgid "Even with task names and explicit state, sometimes a part of a playbook or role (or inventory/variable file) needs more explanation. Adding a comment (any line starting with '#') helps others (and possibly yourself in future) understand what a play or task (or variable setting) does, how it does it, and why." -msgstr "タスク名や状態が明示されていても、Playbook やロール (またはインベントリー/変数ファイル) の一部にさらに説明が必要な場合があります。コメント (「#」で始まる行) を追加することで、プレイやタスク (または変数設定) が何をどのように行うのか、またその理由を他のユーザー (そして将来的には自分自身) が理解するのに役立ちます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:60 -msgid "Inventory tips" -msgstr "インベントリーのヒント" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:62 -msgid "These tips help keep your inventory well organized." -msgstr "これらのヒントは、インベントリーを十分に整理するのに役に立ちます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:65 -msgid "Use dynamic inventory with clouds" -msgstr "クラウドでの動的インベントリーの使用" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:67 -msgid "With cloud providers and other systems that maintain canonical lists of your infrastructure, use :ref:`dynamic inventory ` to retrieve those lists instead of manually updating static inventory files. With cloud resources, you can use tags to differentiate production and staging environments." -msgstr "クラウドプロバイダーやその他のシステムがインフラストラクチャーの正規のリストを管理している場合は、静的なインベントリーファイルを手動で更新する代わりに、:ref:`動的インベントリー ` を使用してこれらのリストを取得します。クラウドリソースでは、タグを使用して本番環境とステージング環境を区別することができます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:71 -msgid "Group inventory by function" -msgstr "機能別にインベントリーのグループ化" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:73 -msgid "A system can be in multiple groups. See :ref:`intro_inventory` and :ref:`intro_patterns`. If you create groups named for the function of the nodes in the group, for example *webservers* or *dbservers*, your playbooks can target machines based on function. You can assign function-specific variables using the group variable system, and design Ansible roles to handle function-specific use cases. See :ref:`playbooks_reuse_roles`." -msgstr "1 つのシステムは複数のグループに属することができます。「:ref:`intro_inventory`」および「:ref:`intro_patterns`」を参照してください。*webservers*、*dbservers* など、グループ内のノードの機能に応じた名前のグループを作成すると、Playbook で機能に応じてマシンをターゲットにすることができます。グループ変数システムを使用して機能固有の変数を割り当て、機能固有のユースケースを処理するために Ansible ロールを設計することができます。「:ref:`playbooks_reuse_roles`」を参照してください。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:79 -msgid "Separate production and staging inventory" -msgstr "別個の実稼働およびステージングのインベントリー" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:81 -msgid "You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. This way you pick with -i what you are targeting. Keeping all your environments in one file can lead to surprises! For example, all vault passwords used in an inventory need to be available when using that inventory. If an inventory contains both production and development environments, developers using that inventory would be able to access production secrets." -msgstr "実稼働を開発環境、テスト環境、ステージング環境から分離するには、それぞれの環境に個別のインベントリーファイルまたはディレクトリーを使用します。この方法では、-i で対象となるものを選ぶことができます。すべての環境を 1 つのファイルにまとめておくと、驚くようなことが起こります。たとえば、インベントリーで使用するすべての Vault パスワードは、そのインベントリーの使用時に利用可能でなければなりません。インベントリーに実稼働環境と開発環境の両方が含まれる場合、そのインベントリーを使用する開発者は実稼働シークレットにアクセスできます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:90 -msgid "Keep vaulted variables safely visible" -msgstr "Vault 処理された変数を安全に表示" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:92 -msgid "You should encrypt sensitive or secret variables with Ansible Vault. However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. To circumvent this, you can encrypt the variables individually using ``ansible-vault encrypt_string``, or add the following layer of indirection to keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets:" -msgstr "機密性の高い変数や秘密の変数は、Ansible Vault で暗号化する必要があります。しかし、変数名だけでなく変数の値も暗号化すると、どこから値を取得しているかを見つけるのが難しくなります。これを回避するには、``ansible-vault encrypt_string``を使用して変数を個別に暗号化するか、以下の間接層を追加して、秘密を公開することなく、変数の名前を (たとえば ``grep`` で) アクセスできる状態に維持することができます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:96 -msgid "Create a ``group_vars/`` subdirectory named after the group." -msgstr "グループの名前が付けられた ``group_vars/`` サブディレクトリーを作成します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:97 -msgid "Inside this subdirectory, create two files named ``vars`` and ``vault``." -msgstr "このサブディレクトリー内に、``vars`` と ``vault`` という名前のファイルを作成します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:98 -msgid "In the ``vars`` file, define all of the variables needed, including any sensitive ones." -msgstr "``vars`` ファイルで、機密性の高い変数など、必要な変数をすべて定義します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:99 -msgid "Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``." -msgstr "すべての機密変数を ``vault`` ファイルにコピーし、この変数の前に ``vault_`` を付けます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:100 -msgid "Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: {{ vault_db_password }}``." -msgstr "jinja2 構文を使用して一致する ``vault_`` 変数を参照するように、``vars`` ファイルの変数を調整します (``db_password: {{ vault_db_password }}``)。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:101 -msgid "Encrypt the ``vault`` file to protect its contents." -msgstr "``vault`` ファイルを暗号化することで、そのコンテンツを保護します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:102 -msgid "Use the variable name from the ``vars`` file in your playbooks." -msgstr "Playbook の ``vars`` ファイルの変数名を使用します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:104 -msgid "When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. There is no limit to the number of variable and vault files or their names." -msgstr "Playbook を実行する際、Ansible は暗号化されていないファイルの変数を見つけ、暗号化されたファイルから機密性の高い変数の値を引き出します。変数ファイルと Vault ファイルの数や名前に制限はありません。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:107 -msgid "Note that using this strategy in your inventory still requires *all vault passwords to be available* (for example for ``ansible-playbook`` or `AWX/Ansible Tower `_) when run with that inventory." -msgstr "インベントリーでこのストラテジーを使用するには、そのインベントリーで実行する場合は *すべての Vault パスワードが利用可能でなければなりません*（例：``ansible-playbook`` または `AWX/Ansible Tower `_）。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:112 -msgid "Execution tricks" -msgstr "実行トリック" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:114 -msgid "These tips apply to using Ansible, rather than to Ansible artifacts." -msgstr "このヒントは、Ansible アーティファクトではなく Ansible の使用に適用されます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:117 -msgid "Try it in staging first" -msgstr "最初にステージングで試す" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:119 -msgid "Testing changes in a staging environment before rolling them out in production is always a great idea. Your environments need not be the same size and you can use group variables to control the differences between those environments." -msgstr "変更を実稼働環境に展開する前にステージング環境でテストすることは、常に素晴らしい考えです。環境は同じ大きさである必要はなく、グループ変数を使用して環境間の違いを制御することができます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:123 -msgid "Update in batches" -msgstr "バッチの更新" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:125 -msgid "Use the 'serial' keyword to control how many machines you update at once in the batch. See :ref:`playbooks_delegation`." -msgstr "「serial」キーワードを使用して、バッチで一度にアップデートするマシンの数を制御します。「:ref:`playbooks_delegation`」を参照してください。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:131 -msgid "Handling OS and distro differences" -msgstr "OS とディストリビューションの相違点の処理" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:133 -msgid "Group variables files and the ``group_by`` module work together to help Ansible execute across a range of operating systems and distributions that require different settings, packages, and tools. The ``group_by`` module creates a dynamic group of hosts that match certain criteria. This group does not need to be defined in the inventory file. This approach lets you execute different tasks on different operating systems or distributions." -msgstr "グループ変数ファイルと ``group_by`` モジュールが連携することで、Ansible は、異なる設定、パッケージ、ツールを必要とするさまざまなオペレーティングシステムやディストリビューションに対応して実行することができます。``group_by`` モジュールは、特定の条件に一致するホストの動的グループを作成します。このグループは、インベントリーファイルで定義する必要はありません。この方法では、異なるオペレーティングシステムやディストリビューション上で異なるタスクを実行することができます。以下に例を示します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:138 -msgid "For example, the following play categorizes all systems into dynamic groups based on the operating system name:" -msgstr "たとえば、以下のプレイでは、オペレーティングシステムの名前に基づいてすべてのシステムを動的グループに分類します。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:143 -msgid "Subsequent plays can use these groups as patterns on the ``hosts`` line as follows:" -msgstr "以降のプレイでは、以下のように ``hosts`` の行にパターンとしてこれらのグループを使用することができます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:148 -msgid "You can also add group-specific settings in group vars files. In the following example, CentOS machines get the value of '42' for `asdf` but other machines get '10'. You can also use group vars files to apply roles to systems as well as set variables." -msgstr "グループ変数ファイルにグループ固有の設定を追加することもできます。以下の例では、CentOS マシンでは `asdf` に 42 の値を取得しますが、他のマシンは '10' を取得します。また、グループ変数ファイルを使用してロールをシステムに適用したり、変数を設定したりすることもできます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:163 -msgid "All three names must match: the name created by the ``group_by`` task, the name of the pattern in subsequent plays, and the name of the group vars file." -msgstr "``group_by`` タスクで作成された名前、後続のプレイのパターンの名前、およびグループ変数ファイルの名前の 3 つの名前がすべて一致している必要があります。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:165 -msgid "You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks:" -msgstr "タスクではなく、OS 固有の変数のみを必要とする場合は、``include_vars`` で同じ設定を使用できます。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:170 -msgid "This pulls in variables from the `group_vars/os_CentOS.yml` file." -msgstr "`group_vars/os_CentOS.yml` ファイルから変数をプルします。" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:174 -#: ../../rst/tips_tricks/sample_setup.rst:282 -msgid ":ref:`yaml_syntax`" -msgstr ":ref:`yaml_syntax`" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:175 -#: ../../rst/tips_tricks/sample_setup.rst:283 -msgid "Learn about YAML syntax" -msgstr "YAML 構文について" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:176 -#: ../../rst/tips_tricks/sample_setup.rst:284 -msgid ":ref:`working_with_playbooks`" -msgstr ":ref:`working_with_playbooks`" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:177 -#: ../../rst/tips_tricks/sample_setup.rst:285 -msgid "Review the basic playbook features" -msgstr "基本的な Playbook 機能の確認" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:178 -#: ../../rst/tips_tricks/sample_setup.rst:286 -msgid ":ref:`list_of_collections`" -msgstr ":ref:`list_of_collections`" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:179 -#: ../../rst/tips_tricks/sample_setup.rst:287 -msgid "Browse existing collections, modules, and plugins" -msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:180 -#: ../../rst/tips_tricks/sample_setup.rst:288 -msgid ":ref:`developing_modules`" -msgstr ":ref:`developing_modules`" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:181 -#: ../../rst/tips_tricks/sample_setup.rst:289 -msgid "Learn how to extend Ansible by writing your own modules" -msgstr "独自のモジュールを作成して Ansible を拡張する方法について" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:182 -#: ../../rst/tips_tricks/sample_setup.rst:290 -msgid ":ref:`intro_patterns`" -msgstr ":ref:`intro_patterns`" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:183 -#: ../../rst/tips_tricks/sample_setup.rst:291 -msgid "Learn about how to select hosts" -msgstr "ホストの選択方法について" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:184 -#: ../../rst/tips_tricks/sample_setup.rst:292 -msgid "`GitHub examples directory `_" -msgstr "`GitHub examples ディレクトリー `_" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:185 -#: ../../rst/tips_tricks/sample_setup.rst:293 -msgid "Complete playbook files from the github project source" -msgstr "Github プロジェクトソースの完全な Playbook ファイル" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:186 -#: ../../rst/tips_tricks/sample_setup.rst:294 -msgid "`Mailing List `_" -msgstr "`Mailing List `_" - -#: ../../rst/tips_tricks/ansible_tips_tricks.rst:187 -#: ../../rst/tips_tricks/sample_setup.rst:295 -msgid "Questions? Help? Ideas? Stop by the list on Google Groups" -msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" - -#: ../../rst/tips_tricks/index.rst:6 -msgid "Ansible tips and tricks" -msgstr "Ansible のヒントと裏技" - -#: ../../rst/tips_tricks/index.rst:10 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/tips_tricks/index.rst:12 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/tips_tricks/index.rst:14 -msgid "Welcome to the Ansible tips and tricks guide. These tips and tricks have helped us optimize our Ansible usage and we offer them here as suggestions. We hope they will help you organize content, write playbooks, maintain inventory, and execute Ansible. Ultimately, though, you should use Ansible in the way that makes most sense for your organization and your goals." -msgstr "Ansible のヒントと裏技ガイドへようこそ。これらのヒントとコツは、Ansible の使用法を最適化するのに役に立ったため、提案としてここに示します。コンテンツの整理、Playbook の作成、インベントリーの維持、Ansible の実行に役立つことを願っています。ただし、最終的には、自身の組織と目標に最も適した方法で Ansible を使用する必要があります。" - -#: ../../rst/tips_tricks/sample_setup.rst:5 -msgid "Sample Ansible setup" -msgstr "Ansible 設定の例" - -#: ../../rst/tips_tricks/sample_setup.rst:7 -msgid "You have learned about playbooks, inventory, roles, and variables. This section combines all those elements, and outlines a sample setup for automating a web service. You can find more example playbooks that illustrate these patterns in our `ansible-examples repository `_. (NOTE: These examples do not use all of the latest features, but are still an excellent reference.)." -msgstr "ここまで、Playbook、インベントリー、ロール、および変数について学んできました。このセクションでは、これらの要素をまとめて、Web サービスを自動化するためのセットアップのサンプルを紹介します。これらのパターンを示す Playbook の例は、`ansible-examples repository `_ を参照してください (注: 最新のリリースではすべての機能を使用していない場合がありますが、それでも優れた参考資料となります)。" - -#: ../../rst/tips_tricks/sample_setup.rst:9 -msgid "The sample setup organizes playbooks, roles, inventory, and files with variables by function. Tags at the play and task level provide greater granularity and control. This is a powerful and flexible approach, but there are other ways to organize Ansible content. Your usage of Ansible should fit your needs, so feel free to modify this approach and organize your content accordingly." -msgstr "サンプルの設定では、機能別に Playbook、ロール、インベントリー、変数が含まれるファイルを整理します。プレイやタスクのレベルのタグを使用すると、より詳細にわたり制御できるようになります。これは強力で柔軟なアプローチですが、Ansible コンテンツの整理には他の方法があります。Ansible は、ニーズに合わせて使用するべきであるため、このアプローチを自由に変更して、自分のコンテンツに合わせて整理してください。" - -#: ../../rst/tips_tricks/sample_setup.rst:15 -msgid "Sample directory layout" -msgstr "ディレクトリーレイアウトの例" - -#: ../../rst/tips_tricks/sample_setup.rst:17 -msgid "This layout organizes most tasks in roles, with a single inventory file for each environment and a few playbooks in the top-level directory:" -msgstr "このレイアウトでは、ほとんどのタスクがロールごとに整理されており、環境ごとに 1 つのインベントリーファイルを作成し、トップレベルのディレクトリーにいくつかの Playbook を置いています。" - -#: ../../rst/tips_tricks/sample_setup.rst:42 -msgid "By default, Ansible assumes your playbooks are stored in one directory with roles stored in a sub-directory called ``roles/``. With more tasks to automate, you can consider moving your playbooks into a sub-directory called ``playbooks/``. If you do this, you must configure the path to your ``roles/`` directory using the ``roles_path`` setting in the ``ansible.cfg`` file." -msgstr "デフォルトでは、Ansible は、Playbook が ``roles/`` という名前のサブディレクトリーに保存されているロールを持つ 1 つのディレクトリーに保存されていることを前提とします。自動化するタスクが増えると、Playbook を ``playbooks/`` というサブディレクトリーに移動することを検討してください。移動する場合には、``ansible.cfg`` ファイルの ``roles_path`` 設定を使用して ``roles/`` ディレクトリーにパスを設定する必要があります。" - -#: ../../rst/tips_tricks/sample_setup.rst:45 -msgid "Alternative directory layout" -msgstr "代替ディレクトリーレイアウト" - -#: ../../rst/tips_tricks/sample_setup.rst:47 -msgid "You can also put each inventory file with its ``group_vars``/``host_vars`` in a separate directory. This is particularly useful if your ``group_vars``/``host_vars`` do not have that much in common in different environments. The layout could look like this example:" -msgstr "また、``group_vars``/``host_vars`` を含む各インベントリーファイルを別のディレクトリーに置くこともできます。これは、``group_vars``/``host_vars`` が異なる環境であまり共通していない場合に特に有効です。レイアウトは以下の例のようになります。" - -#: ../../rst/tips_tricks/sample_setup.rst:84 -msgid "This layout gives you more flexibility for larger environments, as well as a total separation of inventory variables between different environments. However, this approach is harder to maintain, because there are more files. For more information on organizing group and host variables, see :ref:`splitting_out_vars`." -msgstr "このレイアウトにより、大規模な環境にも柔軟に対応することができ、異なる環境間でインベントリー変数を完全に分離することができます。しかし、この方法では、ファイル数が多くなるため、メンテナンスが難しくなります。グループ変数とホスト変数の整理の詳細は、「:ref:`splitting_out_vars`」を参照してください。" - -#: ../../rst/tips_tricks/sample_setup.rst:89 -msgid "Sample group and host variables" -msgstr "グループ変数およびホスト変数の例" - -#: ../../rst/tips_tricks/sample_setup.rst:91 -msgid "These sample group and host files with variables contain the values that apply to each machine or a group of machines. For instance, the data center in Atlanta has its own NTP servers. As a result, when setting up the ``ntp.conf`` file, you could use similar code as in this example:" -msgstr "変数を含めたこれらのサンプルグループおよびホストファイルには、各マシンまたはマシングループに適用する値が含まれます。たとえば、アトランタのデータセンターには、独自の NTP サーバーがあります。そのため、``ntp.conf`` ファイルを設定すると、この例のように類似するコードを使用できます。" - -#: ../../rst/tips_tricks/sample_setup.rst:100 -msgid "Similarly, hosts in the webservers group have some configuration that does not apply to the database servers:" -msgstr "同様に、Web サーバーグループのホストには、データベースサーバーには適用されない以下のような設定があります。" - -#: ../../rst/tips_tricks/sample_setup.rst:109 -msgid "Default values, or values that are universally true, belong in a file called ``group_vars/all``:" -msgstr "デフォルト値または汎用的に true である値がある場合は、それらを ``group_vars/all`` というファイルに配置します。" - -#: ../../rst/tips_tricks/sample_setup.rst:118 -msgid "If necessary, you can define specific hardware variance in systems in the ``host_vars`` directory:" -msgstr "必要に応じて、システムの特定のハードウェアの差異を ``host_vars`` ファイルに定義することができます。" - -#: ../../rst/tips_tricks/sample_setup.rst:127 -msgid "If you use :ref:`dynamic inventory `, Ansible creates many dynamic groups automatically. As a result, a tag like ``class:webserver`` will load in variables from the file ``group_vars/ec2_tag_class_webserver`` automatically." -msgstr "これにより、Ansible は多くの動的グループを自動的に作成します。その結果、:ref:などのタグは、自動的にファイル`dynamic inventory ` から変数に読み込まれます。" - -#: ../../rst/tips_tricks/sample_setup.rst:129 -msgid "You can access host variables with a special variable called ``hostvars``. See :ref:`special_variables` for a list of these variables. The ``hostvars`` variable can access only host-specific variables, not group variables." -msgstr "ホスト変数は、``hostvars`` と呼ばれる特別な変数を使用してアクセスできます。これらの変数の一覧は :ref:`special_variables` を参照してください。``hostvars`` 変数は、グループ変数ではなく、ホスト固有の変数のみにアクセスできます。" - -#: ../../rst/tips_tricks/sample_setup.rst:135 -msgid "Sample playbooks organized by function" -msgstr "関数別に整理された Playbook のサンプル" - -#: ../../rst/tips_tricks/sample_setup.rst:137 -msgid "With this setup, a single playbook can define the entire infrastructure. The ``site.yml`` playbook imports two other playbooks. One for the webservers and one for the database servers:" -msgstr "この設定では、1 つの Playbook ですべてのインフラストラクチャーを定義することができます。``site.yml`` Playbook は、Web サーバー用とデータベースサーバー用の 2 つの Playbook をインポートしています。" - -#: ../../rst/tips_tricks/sample_setup.rst:146 -msgid "The ``webservers.yml`` playbook, also at the top level, maps the configuration of the webservers group to the roles related to the webservers group:" -msgstr "同じくトップレベルにある ``webservers.yml`` Playbook は、webservers グループの設定を、webservers グループに関連するロールにマッピングします。" - -#: ../../rst/tips_tricks/sample_setup.rst:157 -msgid "With this setup, you can configure your entire infrastructure by running ``site.yml``. Alternatively, to configure just a portion of your infrastructure, run ``webservers.yml``. This is similar to the Ansible ``--limit`` parameter but a little more explicit:" -msgstr "この設定では、``site.yml`` を実行してインフラストラクチャー全体を設定できます。または、インフラストラクチャーの一部を設定するには、``webservers.yml`` を実行します。これは Ansible ``--limit`` パラメーターに似ていますが、もう少し明示的です。" - -#: ../../rst/tips_tricks/sample_setup.rst:167 -msgid "Sample task and handler files in a function-based role" -msgstr "関数ベースのロール内のタスクおよびハンドラーのサンプルファイル" - -#: ../../rst/tips_tricks/sample_setup.rst:169 -msgid "Ansible loads any file called ``main.yml`` in a role sub-directory. This sample ``tasks/main.yml`` file configures NTP:" -msgstr "Ansible は、ロールのサブディレクトリーに ``main.yml`` というファイルをすべて読み込みます。このサンプル ``tasks/main.yml`` ファイルは NTP を設定します。" - -#: ../../rst/tips_tricks/sample_setup.rst:197 -msgid "Here is an example handlers file. Handlers are only triggered when certain tasks report changes. Handlers run at the end of each play:" -msgstr "ハンドラーファイルの例を紹介します。ハンドラーは特定のタスクが変更を報告したときにのみ起動し、各プレイの最後に実行します。" - -#: ../../rst/tips_tricks/sample_setup.rst:208 -msgid "See :ref:`playbooks_reuse_roles` for more information." -msgstr "詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。" - -#: ../../rst/tips_tricks/sample_setup.rst:214 -msgid "What the sample setup enables" -msgstr "設定例の有効化" - -#: ../../rst/tips_tricks/sample_setup.rst:216 -msgid "The basic organizational structure described above enables a lot of different automation options. To reconfigure your entire infrastructure:" -msgstr "上記の基本的な組織構造により、多くの異なる自動化オプションが可能になります。インフラストラクチャー全体を再構成するには、以下のようになります。" - -#: ../../rst/tips_tricks/sample_setup.rst:222 -msgid "To reconfigure NTP on everything:" -msgstr "全面的に NTP を再設定するには、以下を実行します。" - -#: ../../rst/tips_tricks/sample_setup.rst:228 -msgid "To reconfigure only the webservers:" -msgstr "webservers のみを再設定するには、以下を実行します。" - -#: ../../rst/tips_tricks/sample_setup.rst:234 -msgid "To reconfigure only the webservers in Boston:" -msgstr "Boston で webservers のみを再設定するには、以下を実行します。" - -#: ../../rst/tips_tricks/sample_setup.rst:240 -msgid "To reconfigure only the first 10 webservers in Boston, and then the next 10:" -msgstr "Boston で最初の 10 台の webservers だけを再設定し、次の 10 台は、以下のようにします。" - -#: ../../rst/tips_tricks/sample_setup.rst:247 -msgid "The sample setup also supports basic ad hoc commands:" -msgstr "設定例では、基本的なアドホックコマンドもサポートします。" - -#: ../../rst/tips_tricks/sample_setup.rst:254 -msgid "To discover what tasks would run or what hostnames would be affected by a particular Ansible command:" -msgstr "実行するタスクまたは特定の Ansible コマンドの影響を受けるホスト名を検出するには、以下を実行します。" - -#: ../../rst/tips_tricks/sample_setup.rst:267 -msgid "Organizing for deployment or configuration" -msgstr "デプロイメントまたは設定の整理" - -#: ../../rst/tips_tricks/sample_setup.rst:269 -msgid "The sample setup illustrates a typical configuration topology. When you do multi-tier deployments, you will likely need some additional playbooks that hop between tiers to roll out an application. In this case, you can augment ``site.yml`` with playbooks like ``deploy_exampledotcom.yml``. However, the general concepts still apply. With Ansible you can deploy and configure using the same utility. Therefore, you will probably reuse groups and keep the OS configuration in separate playbooks or roles from the application deployment." -msgstr "サンプルの設定は、一般的な設定トポロジーを示しています。多層デプロイメントを行う場合、アプリケーションをロールアウトするために改装間を移動する追加の Playbook が必要になる可能性があります。この場合、``deploy_exampledotcom.yml`` のような Playbook で ``site.yml`` を補完できます。ただし、一般的な概念は引き続き適用されます。Ansible では、同じユーティリティーを使用してデプロイおよび設定できるので、グループを再利用し、OS の設定をアプリケーションのデプロイメントとは別の Playbook やロールにまとめたりできます。" - -#: ../../rst/tips_tricks/sample_setup.rst:271 -msgid "Consider \"playbooks\" as a sports metaphor -- you can have one set of plays to use against all your infrastructure. Then you have situational plays that you use at different times and for different purposes." -msgstr "Playbook をスポーツに例えて考えてみましょう。すべてのインフラストラクチャーに対して使用する 1 セットのプレイと、時と場合に応じて使用する状況に応じたプレイがあります。" - -#: ../../rst/tips_tricks/sample_setup.rst:276 -msgid "Using local Ansible modules" -msgstr "ローカル Ansible モジュールの使用" - -#: ../../rst/tips_tricks/sample_setup.rst:278 -msgid "If a playbook has a :file:`./library` directory relative to its YAML file, you can use this directory to add Ansible modules automatically to the module path. This organizes modules with playbooks. For example, see the directory structure at the start of this section." -msgstr "Playbook に、YAML ファイルと相対的な :file:`./library` ディレクトリーがある場合は、このディレクトリーを使用して、Ansible モジュールを自動的にモジュールパスに追加できます。これは Playbook でモジュールを整理します。たとえば、このセクションの最初にあるディレクトリー構造を参照してください。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po deleted file mode 100644 index 6a7c7f6902d..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po +++ /dev/null @@ -1,493 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../rst/user_guide/basic_concepts.rst:5 -msgid "Ansible concepts" -msgstr "Ansible の概念" - -#: ../../rst/user_guide/basic_concepts.rst:7 -msgid "This page has moved to :ref:`Getting started with Ansible`." -msgstr "このページは :ref:`Getting started with Ansible` に移動しました。" - -#: ../../rst/user_guide/become.rst:5 -msgid "Understanding privilege escalation: become" -msgstr "権限昇格の理解: become" - -#: ../../rst/user_guide/become.rst:7 -msgid "This page has moved to :ref:`playbooks_privilege_escalation`." -msgstr "このページは :ref:`playbooks_privilege_escalation` に移動しました。" - -#: ../../rst/user_guide/cheatsheet.rst:5 -msgid "Ansible CLI cheatsheet" -msgstr "Ansible CLI のチートシート" - -#: ../../rst/user_guide/cheatsheet.rst:7 -msgid "This page has moved to :ref:`cheatsheet`." -msgstr "このページは :ref:`cheatsheet` に移動しました。" - -#: ../../rst/user_guide/collections_using.rst:6 -msgid "Using collections" -msgstr "コレクションの使用" - -#: ../../rst/user_guide/collections_using.rst:8 -msgid "This page has moved to :ref:`collections_index`." -msgstr "このページは :ref:`collections_index` に移動しました。" - -#: ../../rst/user_guide/command_line_tools.rst:4 -msgid "Working with command line tools" -msgstr "コマンドラインツールの使用" - -#: ../../rst/user_guide/command_line_tools.rst:6 -msgid "This page has moved to :ref:`command_line_tools`." -msgstr "このページは :ref:`command_line_tools` に移動しました。" - -#: ../../rst/user_guide/complex_data_manipulation.rst:4 -msgid "Data manipulation" -msgstr "データ操作" - -#: ../../rst/user_guide/complex_data_manipulation.rst:6 -msgid "This page has moved to :ref:`complex_data_manipulation`." -msgstr "このページは :ref:`complex_data_manipulation` に移動しました。" - -#: ../../rst/user_guide/connection_details.rst:5 -msgid "Connection methods and details" -msgstr "接続方法および詳細" - -#: ../../rst/user_guide/connection_details.rst:7 -msgid "This page has moved to :ref:`connections`." -msgstr "このページは :ref:`connections` に移動しました。" - -#: ../../rst/user_guide/index.rst:7 -msgid "User Guide" -msgstr "ユーザーガイド" - -#: ../../rst/user_guide/index.rst:11 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/user_guide/index.rst:13 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/user_guide/index.rst:15 -msgid "Welcome to the Ansible User Guide! This guide is now deprecated to improve navigation and organization. You can find all the user guide content in the following sections:" -msgstr "Ansible ユーザーガイドへようこそ! このガイドは、ナビゲーションと組織を改善するために非推奨になりました。すべてのユーザーガイドの内容は、以下のセクションで確認できます。" - -#: ../../rst/user_guide/index.rst:19 -msgid ":ref:`inventory_guide_index`" -msgstr ":ref:`inventory_guide_index`" - -#: ../../rst/user_guide/index.rst:20 -msgid ":ref:`command_guide_index`" -msgstr ":ref:`command_guide_index`" - -#: ../../rst/user_guide/index.rst:21 -msgid ":ref:`playbook_guide_index`" -msgstr ":ref:`playbook_guide_index`" - -#: ../../rst/user_guide/index.rst:22 -msgid ":ref:`vault_guide_index`" -msgstr ":ref:`vault_guide_index`" - -#: ../../rst/user_guide/index.rst:23 -msgid ":ref:`modules_plugins_index`" -msgstr ":ref:`modules_plugins_index`" - -#: ../../rst/user_guide/index.rst:24 -msgid ":ref:`collections_index`" -msgstr ":ref:`collections_index`" - -#: ../../rst/user_guide/index.rst:25 -msgid ":ref:`os_guide_index`" -msgstr ":ref:`os_guide_index`" - -#: ../../rst/user_guide/index.rst:26 -msgid ":ref:`tips_tricks_index`" -msgstr ":ref:`tips_tricks_index`" - -#: ../../rst/user_guide/intro.rst:4 -msgid "Introduction" -msgstr "はじめに" - -#: ../../rst/user_guide/intro.rst:6 -msgid "Before we start exploring the main components of Ansible -- playbooks, configuration management, deployment, and orchestration -- we'll learn how to get Ansible installed and cover some basic concepts. We'll also go over how to execute ad hoc commands in parallel across your nodes using /usr/bin/ansible, and see what modules are available in Ansible's core (you can also write your own, which is covered later)." -msgstr "ここでは、Ansible の主なコンポーネントである Playbook、構成管理、デプロイメント、オーケストレーションについて説明しますが、その前に、Ansible のインストール方法と基本的な概念について説明します。また、/usr/bin/ansible を使用してノード間でアドホックコマンドを並列実行する方法や、Ansible のコアにはどのようなモジュールが用意されているかを見ていきます (自分で作成することもできますが、これは後で説明します)。" - -#: ../../rst/user_guide/intro_adhoc.rst:5 -msgid "Introduction to ad hoc commands" -msgstr "アドホックコマンドの概要" - -#: ../../rst/user_guide/intro_adhoc.rst:7 -msgid "This page has moved to :ref:`intro_adhoc`." -msgstr "このページは :ref:`intro_adhoc` に移動しました。" - -#: ../../rst/user_guide/intro_bsd.rst:4 -msgid "Ansible and BSD" -msgstr "Ansible および BSD" - -#: ../../rst/user_guide/intro_bsd.rst:6 -msgid "This page has moved to :ref:`working_with_bsd`." -msgstr "このページは :ref:`working_with_bsd` に移動しました。" - -#: ../../rst/user_guide/intro_dynamic_inventory.rst:5 -msgid "Working with dynamic inventory" -msgstr "動的インベントリーの使用" - -#: ../../rst/user_guide/intro_dynamic_inventory.rst:7 -msgid "This page has moved to :ref:`intro_dynamic_inventory`." -msgstr "このページは :ref:`intro_dynamic_inventory` に移動しました。" - -#: ../../rst/user_guide/intro_inventory.rst:5 -msgid "How to build your inventory" -msgstr "インベントリーの構築方法" - -#: ../../rst/user_guide/intro_inventory.rst:7 -msgid "This page has moved to :ref:`intro_inventory`." -msgstr "このページは :ref:`intro_inventory` に移動しました。" - -#: ../../rst/user_guide/intro_patterns.rst:4 -msgid "Patterns: targeting hosts and groups" -msgstr "パターン: ホストおよびグループを対象とする" - -#: ../../rst/user_guide/intro_patterns.rst:6 -msgid "This page has moved to :ref:`intro_patterns`." -msgstr "このページは :ref:`intro_patterns` に移動しました。" - -#: ../../rst/user_guide/intro_windows.rst:2 -msgid "Windows Support" -msgstr "Windows サポート" - -#: ../../rst/user_guide/intro_windows.rst:4 ../../rst/user_guide/windows.rst:6 -msgid "You can find documentation for using Ansible on Windows at :ref:`os_guide_index`." -msgstr "Windows で Ansible を使用するドキュメントは、:ref:`os_guide_index` で参照できます。" - -#: ../../rst/user_guide/modules.rst:4 -msgid "Working With Modules" -msgstr "モジュールの使用" - -#: ../../rst/user_guide/modules.rst:6 ../../rst/user_guide/modules_intro.rst:6 -#: ../../rst/user_guide/modules_support.rst:7 -#: ../../rst/user_guide/plugin_filtering_config.rst:6 -msgid "This page has moved to :ref:`modules_plugins_index`." -msgstr "このページは :ref:`modules_plugins_index` に移動しました。" - -#: ../../rst/user_guide/modules_intro.rst:4 -msgid "Introduction to modules" -msgstr "モジュールの概要" - -#: ../../rst/user_guide/modules_support.rst:5 -msgid "Module Maintenance & Support" -msgstr "モジュールのメンテナンスおよびサポート" - -#: ../../rst/user_guide/playbooks.rst:4 -msgid "Working with playbooks" -msgstr "Playbook の操作" - -#: ../../rst/user_guide/playbooks.rst:6 -msgid "This page has moved to :ref:`working_with_playbooks`." -msgstr "このページは :ref:`working_with_playbooks` に移動しました。" - -#: ../../rst/user_guide/playbooks_advanced_syntax.rst:5 -msgid "Advanced Syntax" -msgstr "高度な構文" - -#: ../../rst/user_guide/playbooks_advanced_syntax.rst:7 -msgid "This page has moved to :ref:`playbooks_advanced_syntax`." -msgstr "このページは :ref:`playbooks_advanced_syntax` に移動しました。" - -#: ../../rst/user_guide/playbooks_async.rst:4 -msgid "Asynchronous actions and polling" -msgstr "非同期アクションおよびポーリング" - -#: ../../rst/user_guide/playbooks_async.rst:6 -msgid "This page has moved to :ref:`playbooks_async`." -msgstr "このページは :ref:`playbooks_async` に移動しました。" - -#: ../../rst/user_guide/playbooks_best_practices.rst:5 -msgid "Tips and tricks" -msgstr "ヒントと裏技" - -#: ../../rst/user_guide/playbooks_best_practices.rst:7 -msgid "This page has moved to :ref:`tips_and_tricks`." -msgstr "このページは :ref:`tips_and_tricks` に移動しました。" - -#: ../../rst/user_guide/playbooks_blocks.rst:5 -msgid "Blocks" -msgstr "ブロック" - -#: ../../rst/user_guide/playbooks_blocks.rst:7 -msgid "This page has moved to :ref:`playbooks_blocks`." -msgstr "このページは :ref:`playbooks_blocks` に移動しました。" - -#: ../../rst/user_guide/playbooks_checkmode.rst:5 -msgid "Validating tasks: check mode and diff mode" -msgstr "タスクの検証: チェックモードと差分モード" - -#: ../../rst/user_guide/playbooks_checkmode.rst:7 -msgid "This page has moved to :ref:`check_mode_dry`." -msgstr "このページは :ref:`check_mode_dry` に移動しました。" - -#: ../../rst/user_guide/playbooks_conditionals.rst:5 -msgid "Conditionals" -msgstr "条件分岐 (Conditional)" - -#: ../../rst/user_guide/playbooks_conditionals.rst:7 -msgid "This page has moved to :ref:`playbooks_conditionals`." -msgstr "このページは :ref:`playbooks_conditionals` に移動しました。" - -#: ../../rst/user_guide/playbooks_debugger.rst:5 -msgid "Debugging tasks" -msgstr "タスクのデバッグ" - -#: ../../rst/user_guide/playbooks_debugger.rst:7 -msgid "This page has moved to :ref:`playbook_debugger`." -msgstr "このページは :ref:`playbook_debugger` に移動しました。" - -#: ../../rst/user_guide/playbooks_delegation.rst:4 -msgid "Controlling where tasks run: delegation and local actions" -msgstr "タスクの実行場所の制御: 委譲およびローカルアクション" - -#: ../../rst/user_guide/playbooks_delegation.rst:6 -msgid "This page has moved to :ref:`playbooks_delegation`." -msgstr "このページは :ref:`playbooks_delegation` に移動しました。" - -#: ../../rst/user_guide/playbooks_environment.rst:4 -msgid "Setting the remote environment" -msgstr "リモート環境の設定" - -#: ../../rst/user_guide/playbooks_environment.rst:6 -msgid "This page has moved to :ref:`playbooks_environment`." -msgstr "このページは :ref:`playbooks_environment` に移動しました。" - -#: ../../rst/user_guide/playbooks_error_handling.rst:5 -msgid "Error handling in playbooks" -msgstr "Playbook でのエラー処理" - -#: ../../rst/user_guide/playbooks_error_handling.rst:7 -msgid "This page has moved to :ref:`playbooks_error_handling`." -msgstr "このページは :ref:`playbooks_error_handling` に移動しました。" - -#: ../../rst/user_guide/playbooks_filters.rst:5 -msgid "Using filters to manipulate data" -msgstr "フィルターを使用したデータの操作" - -#: ../../rst/user_guide/playbooks_filters.rst:7 -msgid "This page has moved to :ref:`playbooks_filters`." -msgstr "このページは :ref:`playbooks_filters` に移動しました。" - -#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:6 -msgid "ipaddr filter" -msgstr "ipaddr フィルター" - -#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:8 -msgid "This document has moved to :ref:`plugins_in_ansible.utils`." -msgstr "このドキュメントは :ref:`plugins_in_ansible.utils` に移動しました。" - -#: ../../rst/user_guide/playbooks_handlers.rst:4 -msgid "Handlers: running operations on change" -msgstr "ハンドラー: 変更時に実行する操作" - -#: ../../rst/user_guide/playbooks_handlers.rst:6 -msgid "This page has moved to :ref:`handlers`." -msgstr "このページは :ref:`handlers` に移動しました。" - -#: ../../rst/user_guide/playbooks_intro.rst:5 -msgid "Intro to playbooks" -msgstr "Playbook の概要" - -#: ../../rst/user_guide/playbooks_intro.rst:7 -msgid "This page has moved to :ref:`playbooks_intro`." -msgstr "このページは :ref:`playbooks_intro` に移動しました。" - -#: ../../rst/user_guide/playbooks_lookups.rst:5 -msgid "Lookups" -msgstr "ルックアップ (lookup)" - -#: ../../rst/user_guide/playbooks_lookups.rst:7 -msgid "This page has moved to :ref:`playbooks_lookups`." -msgstr "このページは :ref:`playbooks_lookups` に移動しました。" - -#: ../../rst/user_guide/playbooks_loops.rst:5 -msgid "Loops" -msgstr "ループ" - -#: ../../rst/user_guide/playbooks_loops.rst:7 -msgid "This page has moved to :ref:`playbooks_loops`." -msgstr "このページは :ref:`playbooks_loops` に移動しました。" - -#: ../../rst/user_guide/playbooks_module_defaults.rst:4 -msgid "Module defaults" -msgstr "モジュールのデフォルト" - -#: ../../rst/user_guide/playbooks_module_defaults.rst:6 -msgid "This page has moved to :ref:`module_defaults`." -msgstr "このページは :ref:`module_defaults` に移動しました。" - -#: ../../rst/user_guide/playbooks_prompts.rst:5 -msgid "Interactive input: prompts" -msgstr "インタラクティブな入力: prompt" - -#: ../../rst/user_guide/playbooks_prompts.rst:7 -msgid "This page has moved to :ref:`playbooks_prompts`." -msgstr "このページは :ref:`playbooks_prompts` に移動しました。" - -#: ../../rst/user_guide/playbooks_reuse.rst:5 -msgid "Re-using Ansible artifacts" -msgstr "Ansible アーティファクトの再利用" - -#: ../../rst/user_guide/playbooks_reuse.rst:7 -msgid "This page has moved to :ref:`playbooks_reuse`." -msgstr "このページは :ref:`playbooks_reuse` に移動しました。" - -#: ../../rst/user_guide/playbooks_reuse_includes.rst:4 -msgid "Including and importing" -msgstr "インクルードおよびインポート" - -#: ../../rst/user_guide/playbooks_reuse_includes.rst:6 -msgid "The content on this page has been moved to :ref:`playbooks_reuse`." -msgstr "このページのコンテンツは :ref:`playbooks_reuse` に移動しました。" - -#: ../../rst/user_guide/playbooks_reuse_roles.rst:5 -msgid "Roles" -msgstr "ロール" - -#: ../../rst/user_guide/playbooks_reuse_roles.rst:7 -msgid "This page has moved to :ref:`playbooks_reuse_roles`." -msgstr "このページは :ref:`playbooks_reuse_roles` に移動しました。" - -#: ../../rst/user_guide/playbooks_startnstep.rst:5 -msgid "Executing playbooks for troubleshooting" -msgstr "トラブルシューティングのための Playbook の実行" - -#: ../../rst/user_guide/playbooks_startnstep.rst:7 -msgid "This page has moved to :ref:`playbooks_start_and_step`." -msgstr "このページは :ref:`playbooks_start_and_step` に移動しました。" - -#: ../../rst/user_guide/playbooks_strategies.rst:4 -msgid "Controlling playbook execution: strategies and more" -msgstr "Playbook の実行の制御: strategy など" - -#: ../../rst/user_guide/playbooks_strategies.rst:6 -msgid "This page has moved to :ref:`playbooks_strategies`." -msgstr "このページは :ref:`playbooks_strategies` に移動しました。" - -#: ../../rst/user_guide/playbooks_tags.rst:5 -msgid "Tags" -msgstr "タグ" - -#: ../../rst/user_guide/playbooks_tags.rst:7 -msgid "This page has moved to :ref:`tags`." -msgstr "このページは :ref:`tags` に移動しました。" - -#: ../../rst/user_guide/playbooks_tests.rst:5 -msgid "Tests" -msgstr "テスト" - -#: ../../rst/user_guide/playbooks_tests.rst:7 -msgid "This page has moved to :ref:`playbooks_tests`." -msgstr "このページは :ref:`playbooks_tests` に移動しました。" - -#: ../../rst/user_guide/playbooks_variables.rst:5 -msgid "Using Variables" -msgstr "変数の使用" - -#: ../../rst/user_guide/playbooks_variables.rst:7 -msgid "This page has moved to :ref:`playbooks_variables`." -msgstr "このページは :ref:`playbooks_variables` に移動しました。" - -#: ../../rst/user_guide/playbooks_vars_facts.rst:5 -msgid "Discovering variables: facts and magic variables" -msgstr "変数の検出: ファクトおよびマジック変数" - -#: ../../rst/user_guide/playbooks_vars_facts.rst:7 -msgid "This page has moved to :ref:`vars_and_facts`." -msgstr "このページは :ref:`vars_and_facts` に移動しました。" - -#: ../../rst/user_guide/plugin_filtering_config.rst:4 -msgid "Rejecting modules" -msgstr "モジュールの拒否" - -#: ../../rst/user_guide/sample_setup.rst:5 -msgid "Sample Ansible setup" -msgstr "Ansible 設定の例" - -#: ../../rst/user_guide/sample_setup.rst:7 -msgid "This page has moved to :ref:`sample_setup`." -msgstr "このページは :ref:`sample_setup` に移動しました。" - -#: ../../rst/user_guide/vault.rst:5 -msgid "Encrypting content with Ansible Vault" -msgstr "Ansible Vault を使用したコンテンツの暗号化" - -#: ../../rst/user_guide/vault.rst:7 -msgid "This page has moved to :ref:`vault_guide_index`." -msgstr "このページは :ref:`vault_guide_index` に移動しました。" - -#: ../../rst/user_guide/windows.rst:4 -msgid "Windows Guides" -msgstr "Windows ガイド" - -#: ../../rst/user_guide/windows_dsc.rst:4 -msgid "Desired State Configuration" -msgstr "Desired State Configuration" - -#: ../../rst/user_guide/windows_dsc.rst:6 -msgid "This page has moved to :ref:`windows_dsc`." -msgstr "このページは :ref:`windows_dsc` に移動しました。" - -#: ../../rst/user_guide/windows_faq.rst:4 -msgid "Windows Frequently Asked Questions" -msgstr "Windows に関するよくある質問 (FAQ)" - -#: ../../rst/user_guide/windows_faq.rst:6 -msgid "This page has moved to :ref:`windows_faq`." -msgstr "このページは :ref:`windows_faq` に移動しました。" - -#: ../../rst/user_guide/windows_performance.rst:4 -msgid "Windows performance" -msgstr "Windows パフォーマンス" - -#: ../../rst/user_guide/windows_performance.rst:6 -msgid "This page has moved to :ref:`windows_performance`." -msgstr "このページは :ref:`windows_performance` に移動しました。" - -#: ../../rst/user_guide/windows_setup.rst:4 -msgid "Setting up a Windows Host" -msgstr "Windows ホストのセットアップ" - -#: ../../rst/user_guide/windows_setup.rst:6 -msgid "This page has moved to :ref:`windows_setup`." -msgstr "このページは :ref:`windows_setup` に移動しました。" - -#: ../../rst/user_guide/windows_usage.rst:4 -msgid "Using Ansible and Windows" -msgstr "Ansible および Windows の使用" - -#: ../../rst/user_guide/windows_usage.rst:6 -msgid "This page has moved to :ref:`windows_usage`." -msgstr "このページは :ref:`windows_usage` に移動しました。" - -#: ../../rst/user_guide/windows_winrm.rst:4 -msgid "Windows Remote Management" -msgstr "Windows リモート管理" - -#: ../../rst/user_guide/windows_winrm.rst:6 -msgid "This page has moved to :ref:`windows_winrm`." -msgstr "このページは :ref:`windows_winrm` に移動しました。" - - diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/vault_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/vault_guide.po deleted file mode 100644 index ae3b5d13193..00000000000 --- a/docs/docsite/rst/locales/ja/LC_MESSAGES/vault_guide.po +++ /dev/null @@ -1,802 +0,0 @@ -# SOME DESCRIPTIVE TITLE. -# Copyright (C) Ansible project contributors -# This file is distributed under the same license as the Ansible package. -# FIRST AUTHOR , 2022. -# -msgid "" -msgstr "" -"Project-Id-Version: Ansible devel\n" -"Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2022-10-05 09:34+0200\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=utf-8\n" -"Content-Transfer-Encoding: 8bit\n" -"Generated-By: Babel 2.8.1\n" - -#: ../../rst/vault_guide/index.rst:5 -msgid "Protecting sensitive data with Ansible vault" -msgstr "Ansible Vault を使用した機密データの保護" - -#: ../../rst/vault_guide/index.rst:9 -msgid "**Making Open Source More Inclusive**" -msgstr "**多様性を受け入れるオープンソースの強化**" - -#: ../../rst/vault_guide/index.rst:11 -msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_." -msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ `_ を参照してください。" - -#: ../../rst/vault_guide/index.rst:13 -msgid "Welcome to the Ansible vault documentation. Ansible vault provides a way to encrypt and manage sensitive data such as passwords. This guide introduces you to Ansible vault and covers the following topics:" -msgstr "Ansible Vault ドキュメントへようこそ。Ansible vault は、パスワードなどの機密データを暗号化および管理する方法を提供します。本書では、Ansible Vault を紹介し、以下のトピックについて説明します。" - -#: ../../rst/vault_guide/index.rst:17 -msgid "Managing vault passwords." -msgstr "Vault パスワードの管理" - -#: ../../rst/vault_guide/index.rst:18 -msgid "Encrypting content and files with Ansible vault." -msgstr "Ansible Vault を使用したコンテンツおよびファイルの暗号化" - -#: ../../rst/vault_guide/index.rst:19 -msgid "Using encrypted variables and files." -msgstr "暗号化された変数とファイルの使用" - -#: ../../rst/vault_guide/vault.rst:5 -msgid "Ansible Vault" -msgstr "Ansible Vault" - -#: ../../rst/vault_guide/vault.rst:7 -msgid "Ansible Vault encrypts variables and files so you can protect sensitive content such as passwords or keys rather than leaving it visible as plaintext in playbooks or roles. To use Ansible Vault you need one or more passwords to encrypt and decrypt content. If you store your vault passwords in a third-party tool such as a secret manager, you need a script to access them. Use the passwords with the :ref:`ansible-vault` command-line tool to create and view encrypted variables, create encrypted files, encrypt existing files, or edit, re-key, or decrypt files. You can then place encrypted content under source control and share it more safely." -msgstr "Ansible Vault は変数やファイルを暗号化するため、パスワードや鍵などの機密コンテンツを Playbook やロールの中で平文のまま放置することなく保護することができます。Ansible Vault を使用するには、コンテンツを暗号化および復号を行うために 1 つ以上のパスワードが必要です。シークレットマネージャーなどのサードパーティーツールに Vault のパスワードを保存している場合は、そのパスワードにアクセスするためのスクリプトが必要です。:ref:`ansible-vault` コマンドラインツールでパスワードを使用して、暗号化された変数の作成と表示、暗号化されたファイルの作成、既存ファイルの暗号化、またはファイルの編集、鍵の再設定、復号を行います。また、暗号化されたコンテンツをソースコントロール下に置き、より安全に共有することができます。" - -#: ../../rst/vault_guide/vault.rst:14 -msgid "Encryption with Ansible Vault ONLY protects 'data at rest'. Once the content is decrypted ('data in use'), play and plugin authors are responsible for avoiding any secret disclosure, see :ref:`no_log ` for details on hiding output and :ref:`vault_securing_editor` for security considerations on editors you use with Ansible Vault." -msgstr "Ansible Vault による暗号化は、「静止状態のデータ」のみを保護します。コンテンツが復号化された後 (「使用中のデータ」)、プレイやプラグインの作者は、秘密の漏洩を回避する責任があります。出力の非表示に関する詳細は「:ref:`no_log `」を、Ansible Vault で使用するエディターのセキュリティーに関する考慮点は「:ref:`vault_securing_editor`」を参照してください。" - -#: ../../rst/vault_guide/vault.rst:17 -msgid "You can use encrypted variables and files in ad hoc commands and playbooks by supplying the passwords you used to encrypt them. You can modify your ``ansible.cfg`` file to specify the location of a password file or to always prompt for the password." -msgstr "暗号化された変数やファイルは、暗号化に使用したパスワードを入力することで、アドホックコマンドや Playbook で使用することができます。``ansible.cfg`` ファイルを変更して、パスワードファイルの場所を指定したり、常にパスワードの入力を促すようにすることができます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:4 -msgid "Encrypting content with Ansible Vault" -msgstr "Ansible Vault を使用したコンテンツの暗号化" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:6 -msgid "Once you have a strategy for managing and storing vault passwords, you can start encrypting content. You can encrypt two types of content with Ansible Vault: variables and files. Encrypted content always includes the ``!vault`` tag, which tells Ansible and YAML that the content needs to be decrypted, and a ``|`` character, which allows multi-line strings. Encrypted content created with ``--vault-id`` also contains the vault ID label. For more details about the encryption process and the format of content encrypted with Ansible Vault, see :ref:`vault_format`. This table shows the main differences between encrypted variables and encrypted files:" -msgstr "Vault のパスワードを管理および保管するためのストラテジーができたら、コンテンツの暗号化を開始できます。Ansible Vault では、変数とファイルの 2 種類のコンテンツを暗号化することができます。暗号化されたコンテンツには、必ず ``!vault`` タグが含まれます。これは、コンテンツの復号が必要であることを Ansible と YAML に伝えるもので、複数行の文字列を可能にする ``|`` 文字も含まれています。``--vault-id`` で作成された暗号化コンテンツには、Vault ID ラベルも含まれます。Ansible Vault における暗号化プロセスと形式の詳細は、「:ref:`vault_format`」を参照してください。この表は、暗号化された変数と暗号化されたファイルの主な違いを示しています。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:12 -msgid "Encrypted variables" -msgstr "暗号化された変数" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:12 -msgid "Encrypted files" -msgstr "暗号化されたファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:14 -msgid "How much is encrypted?" -msgstr "どのくらい暗号化されているのか" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:14 -msgid "Variables within a plaintext file" -msgstr "平文ファイル内の変数" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:14 -msgid "The entire file" -msgstr "ファイル全体" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:16 -msgid "When is it decrypted?" -msgstr "復号するタイミング" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:16 -msgid "On demand, only when needed" -msgstr "オンデマンドで (必要な場合にのみ)" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:16 -msgid "Whenever loaded or referenced [#f1]_" -msgstr "読み込みまたは参照する場合 [#f1]_" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:18 -msgid "What can be encrypted?" -msgstr "暗号化できるもの" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:18 -msgid "Only variables" -msgstr "変数のみ" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:18 -msgid "Any structured data file" -msgstr "構造化データファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:22 -msgid "Ansible cannot know if it needs content from an encrypted file unless it decrypts the file, so it decrypts all encrypted files referenced in your playbooks and roles." -msgstr "Ansible は、ファイルを復号しない限り、暗号化されたファイルからコンテンツを必要とするかどうかを認識できないため、Playbook およびロールで参照される暗号化されたファイルをすべて復号します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:28 -msgid "Encrypting individual variables with Ansible Vault" -msgstr "Ansible Vault による個々の変数の暗号化" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:30 -msgid "You can encrypt single values inside a YAML file using the :ref:`ansible-vault encrypt_string ` command. For one way to keep your vaulted variables safely visible, see :ref:`tip_for_variables_and_vaults`." -msgstr ":ref:`ansible-vault encrypt_string ` コマンドを使用して、YAML ファイル内で 1 つの値を暗号化することができます。Vault を使用した変数を安全に表示できる方法は、「:ref:`tip_for_variables_and_vaults`」を参照してください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:33 -msgid "Advantages and disadvantages of encrypting variables" -msgstr "変数を暗号化することの利点および欠点" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:35 -msgid "With variable-level encryption, your files are still easily legible. You can mix plaintext and encrypted variables, even inline in a play or role. However, password rotation is not as simple as with file-level encryption. You cannot :ref:`rekey ` encrypted variables. Also, variable-level encryption only works on variables. If you want to encrypt tasks or other content, you must encrypt the entire file." -msgstr "変数レベルの暗号化では、ファイルを簡単に読み取ることができます。平文の変数と暗号化された変数を混在させることができ、プレイやロールの中でインラインでも使用できます。しかし、パスワードのローテーションはファイルレベルの暗号化のように簡単ではありません。暗号化された変数に :ref:`鍵の再設定 ` は使用できません。また、変数レベルの暗号化は変数に対してのみ機能します。タスクやその他のコンテンツを暗号化する場合は、ファイル全体を暗号化する必要があります。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:40 -msgid "Creating encrypted variables" -msgstr "暗号化されたファイルの作成" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:42 -msgid "The :ref:`ansible-vault encrypt_string ` command encrypts and formats any string you type (or copy or generate) into a format that can be included in a playbook, role, or variables file. To create a basic encrypted variable, pass three options to the :ref:`ansible-vault encrypt_string ` command:" -msgstr ":ref:`ansible-vault encrypt_string ` コマンドは、入力 (もしくはコピーまたは生成) した文字列を暗号化して、Playbook、ロール、変数ファイルに含めることができる形式にします。基本的な暗号化変数を作成するには、:ref:`ansible-vault encrypt_string ` コマンドに 3 つのオプションを渡します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:44 -msgid "a source for the vault password (prompt, file, or script, with or without a vault ID)" -msgstr "Vault パスワードのソース (プロンプト、ファイル、またはスクリプト、Vault ID あり/なし)" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:45 -msgid "the string to encrypt" -msgstr "暗号化する文字列" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:46 -msgid "the string name (the name of the variable)" -msgstr "文字列名 (変数の名前)" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:48 -msgid "The pattern looks like this:" -msgstr "パターンは以下のようになります。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:54 -msgid "For example, to encrypt the string 'foobar' using the only password stored in 'a_password_file' and name the variable 'the_secret':" -msgstr "たとえば、「a_password_file」に保存されたパスワードのみを使用して文字列を「foobar」を暗号化する際に、変数「the_secret」に名前を付けます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:60 -#: ../../rst/vault_guide/vault_encrypting_content.rst:78 -msgid "The command above creates this content:" -msgstr "上記のコマンドにより、以下のような内容が作成されます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:72 -msgid "To encrypt the string 'foooodev', add the vault ID label 'dev' with the 'dev' vault password stored in 'a_password_file', and call the encrypted variable 'the_dev_secret':" -msgstr "文字列「foooodev」を暗号化するには、Vault ID ラベル「dev」に「a_password_file」に格納されている「dev」の Vault パスワードを追加し、暗号化された変数「the_dev_secret」を呼び出します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:90 -msgid "To encrypt the string 'letmein' read from stdin, add the vault ID 'dev' using the 'dev' vault password stored in `a_password_file`, and name the variable 'db_password':" -msgstr "標準入力から読み込んだ文字列「letmein」を暗号化するために、`a_password_file` に保存されている「dev」の Vault のパスワードを使用して Vault ID「dev」を追加し、変数に「db_password」という名前を付けます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:98 -msgid "Typing secret content directly at the command line (without a prompt) leaves the secret string in your shell history. Do not do this outside of testing." -msgstr "秘密の内容をコマンドラインで直接入力すると (プロンプトなし)、シェルの履歴に秘密の文字列が残ります。テスト時以外はこのようなことをしないでください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:100 -msgid "The command above creates this output:" -msgstr "上記のコマンドにより、以下が出力されます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:113 -msgid "To be prompted for a string to encrypt, encrypt it with the 'dev' vault password from 'a_password_file', name the variable 'new_user_password' and give it the vault ID label 'dev':" -msgstr "暗号化する文字列の入力を求められるため、「a_password_file」の「dev」の Vault パスワードで暗号化し、変数名を「new_user_password」とし、Vault ID ラベル「dev」を付与します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:119 -msgid "The command above triggers this prompt:" -msgstr "上記のコマンドにより、以下のプロンプトが表示されます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:125 -msgid "Type the string to encrypt (for example, 'hunter2'), hit ctrl-d, and wait." -msgstr "暗号化する文字列 (「hunter2」など) を入力し、ctrl-d を押してお待ちください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:129 -msgid "Do not press ``Enter`` after supplying the string to encrypt. That will add a newline to the encrypted value." -msgstr "暗号化する文字列を指定した後に ``Enter`` を押さないでください。暗号化された値に改行を追加します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:131 -msgid "The sequence above creates this output:" -msgstr "上記のシーケンスにより、以下のような出力が作成されます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:143 -msgid "You can add the output from any of the examples above to any playbook, variables file, or role for future use. Encrypted variables are larger than plain-text variables, but they protect your sensitive content while leaving the rest of the playbook, variables file, or role in plain text so you can easily read it." -msgstr "上記の例の出力を将来使用するために、任意の Playbook、変数ファイル、またはロールに追加することができます。暗号化された変数は、平文の変数よりもサイズが大きくなりますが、機密性の高いコンテンツを保護する一方で、Playbook、変数ファイル、またはロールの残りの部分は平文のままなとなるため、簡単に読み取ることができます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:146 -msgid "Viewing encrypted variables" -msgstr "暗号化された変数の表示" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:148 -msgid "You can view the original value of an encrypted variable using the debug module. You must pass the password that was used to encrypt the variable. For example, if you stored the variable created by the last example above in a file called 'vars.yml', you could view the unencrypted value of that variable like this:" -msgstr "暗号化された変数の元の値は、デバッグモジュールを使用して見ることができます。その際には、変数の暗号化に使用したパスワードを渡す必要があります。たとえば、上記の最後の例で作成した変数を「vars.yml」というファイルに保存した場合に、その変数の暗号化されていない値を見るには次のようにします。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:160 -msgid "Encrypting files with Ansible Vault" -msgstr "Ansible Vault によるファイルの暗号化" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:162 -msgid "Ansible Vault can encrypt any structured data file used by Ansible, including:" -msgstr "Ansible Vault は、Ansible が使用するあらゆる構造化データファイルを暗号化することができます。以下に例を示します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:164 -msgid "group variables files from inventory" -msgstr "インベントリーからのグループ変数ファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:165 -msgid "host variables files from inventory" -msgstr "インベントリーからのホスト変数ファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:166 -msgid "variables files passed to ansible-playbook with ``-e @file.yml`` or ``-e @file.json``" -msgstr "``-e @file.yml`` または ``-e @file.json`` で ansible-playbook に渡される変数ファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:167 -msgid "variables files loaded by ``include_vars`` or ``vars_files``" -msgstr "``include_vars`` または ``vars_files`` により読み込まれた変数ファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:168 -msgid "variables files in roles" -msgstr "ロールの変数ファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:169 -msgid "defaults files in roles" -msgstr "ロール内のデフォルトファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:170 -msgid "tasks files" -msgstr "タスクファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:171 -msgid "handlers files" -msgstr "ハンドラーファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:172 -msgid "binary files or other arbitrary files" -msgstr "バイナリーファイルまたはその他の任意のファイル" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:174 -msgid "The full file is encrypted in the vault." -msgstr "完全なファイルは Vault で暗号化されます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:178 -msgid "Ansible Vault uses an editor to create or modify encrypted files. See :ref:`vault_securing_editor` for some guidance on securing the editor." -msgstr "Ansible Vault はエディターを使用して暗号化されたファイルの作成または変更します。エディターのセキュリティー保護に関するいくつかのガイダンスは、「:ref:`vault_securing_editor`」を参照してください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:182 -msgid "Advantages and disadvantages of encrypting files" -msgstr "ファイルを暗号化することの利点および欠点" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:184 -msgid "File-level encryption is easy to use. Password rotation for encrypted files is straightforward with the :ref:`rekey ` command. Encrypting files can hide not only sensitive values, but the names of the variables you use. However, with file-level encryption the contents of files are no longer easy to access and read. This may be a problem with encrypted tasks files. When encrypting a variables file, see :ref:`tip_for_variables_and_vaults` for one way to keep references to these variables in a non-encrypted file. Ansible always decrypts the entire encrypted file when it is when loaded or referenced, because Ansible cannot know if it needs the content unless it decrypts it." -msgstr "ファイルレベルの暗号化は簡単に使用できます。暗号化されたファイルのパスワードローテーションは、:ref:`rekey ` コマンドで簡単に行うことができます。ファイルを暗号化すると、慎重に扱うべき値だけでなく、使用する変数の名前も隠すことができます。しかし、ファイルレベルの暗号化では、ファイルの内容に簡単にアクセスして読むことができなくなります。これは暗号化されたタスクファイルでは問題になるかもしれません。変数ファイルを暗号化する場合、これらの変数への参照を暗号化されていないファイルに保持する 1 つの方法、「:ref:`tip_for_variables_and_vaults`」を参照してください。Ansible は、暗号化されたファイルを読み込んだり参照したりする際には、常に暗号化されたファイル全体を復号します。これは、Ansible は復号しない限りコンテンツが必要かどうかを知ることができないからです。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:189 -msgid "Creating encrypted files" -msgstr "暗号化されたファイルの作成" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:191 -msgid "To create a new encrypted data file called 'foo.yml' with the 'test' vault password from 'multi_password_file':" -msgstr "「multi_password_file」の Vault パスワード「test」を使用して、「foo.yml」という名前の新しい暗号化データファイルを作成するには、以下を行います。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:197 -msgid "The tool launches an editor (whatever editor you have defined with $EDITOR, default editor is vi). Add the content. When you close the editor session, the file is saved as encrypted data. The file header reflects the vault ID used to create it:" -msgstr "このツールは、エディター ($EDITOR で定義したエディターがなんであれ、デフォルトは vi) を起動します。コンテンツを追加します。エディターセッションを終了すると、ファイルは暗号化されたデータとして保存されます。ファイルのヘッダーには、作成時に使用した Vault ID が反映されます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:203 -msgid "To create a new encrypted data file with the vault ID 'my_new_password' assigned to it and be prompted for the password:" -msgstr "Vault ID「my_new_password」が割り当てられた新しい暗号化データファイルを作成し、パスワードの入力を求められるようにするには、以下を行います。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:209 -msgid "Again, add content to the file in the editor and save. Be sure to store the new password you created at the prompt, so you can find it when you want to decrypt that file." -msgstr "ここでも、エディターのファイルにコンテンツを追加して保存します。プロンプトで作成した新しいパスワードを必ず保存し、そのファイルを復号するときに見つけられるようにしてください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:214 -msgid "Encrypting existing files" -msgstr "既存ファイルの暗号化" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:216 -msgid "To encrypt an existing file, use the :ref:`ansible-vault encrypt ` command. This command can operate on multiple files at once. For example:" -msgstr "既存ファイルを暗号化するには、:ref:`ansible-vault encrypt ` コマンドを使用します。このコマンドは、一度に複数のファイルで動作します。以下に例を示します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:222 -msgid "To encrypt existing files with the 'project' ID and be prompted for the password:" -msgstr "「プロジェクト」IDで既存のファイルを暗号化し、パスワードの入力を求めるプロンプトを表示するには、以下のようになります。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:232 -msgid "Viewing encrypted files" -msgstr "暗号化したファイルの表示" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:234 -msgid "To view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view ` command:" -msgstr "暗号化したファイルの内容を編集せずに表示する場合は、:ref:`ansible-vault view ` コマンドを使用できます。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:244 -msgid "Editing encrypted files" -msgstr "暗号化されたファイルの編集" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:246 -msgid "To edit an encrypted file in place, use the :ref:`ansible-vault edit ` command. This command decrypts the file to a temporary file, allows you to edit the content, then saves and re-encrypts the content and removes the temporary file when you close the editor. For example:" -msgstr "暗号化されたファイルをその場で編集するには、:ref:`ansible-vault edit ` コマンドを使用します。このコマンドは、ファイルを一時的なファイルに復号し、内容を編集できるようにした後、内容を保存して再度暗号化し、エディターを閉じるときに一時的なファイルを削除します。以下に例を示します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:252 -msgid "To edit a file encrypted with the ``vault2`` password file and assigned the vault ID ``pass2``:" -msgstr "「``vault2``」パスワードファイルで暗号化され、Vault ID「``pass2``」を割り当てたファイルを編集するには、以下を実行します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:262 -msgid "Changing the password and/or vault ID on encrypted files" -msgstr "暗号化されたファイルのパスワードまたは Vault ID の変更" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:264 -msgid "To change the password on an encrypted file or files, use the :ref:`rekey ` command:" -msgstr "暗号化された 1 つまたは複数のファイルのパスワードを変更するには、:ref:`rekey ` コマンドを使用します。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:270 -msgid "This command can rekey multiple data files at once and will ask for the original password and also the new password. To set a different ID for the rekeyed files, pass the new ID to ``--new-vault-id``. For example, to rekey a list of files encrypted with the 'preprod1' vault ID from the 'ppold' file to the 'preprod2' vault ID and be prompted for the new password:" -msgstr "このコマンドは、複数のデータファイルの鍵を一度に再設定することができ、元のパスワードと新しいパスワードを要求します。鍵を一度に再設定したファイルに別の ID を設定するには、新しい ID を ``--new-vault-id`` に渡します。たとえば、「ppold」ファイルから「preprod1」の Vault ID で暗号化されたファイルのリストで Vault ID「preprod2」に鍵を再設定し、新しいパスワードの入力を求める場合です。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:280 -msgid "Decrypting encrypted files" -msgstr "暗号化されたファイルの復号化" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:282 -msgid "If you have an encrypted file that you no longer want to keep encrypted, you can permanently decrypt it by running the :ref:`ansible-vault decrypt ` command. This command will save the file unencrypted to the disk, so be sure you do not want to :ref:`edit ` it instead." -msgstr "暗号化されたファイルがあり、そのファイルを暗号化したままにしておきたくない場合は、:ref:`ansible-vault decrypt ` コマンドを実行することで永久に暗号化を解除することができます。このコマンドは暗号化されていないファイルをディスクに保存するため、代わりに :ref:`edit ` を使用しないようにしてください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:292 -msgid "Steps to secure your editor" -msgstr "エディターを確保するための手順" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:294 -msgid "Ansible Vault relies on your configured editor, which can be a source of disclosures. Most editors have ways to prevent loss of data, but these normally rely on extra plain text files that can have a clear text copy of your secrets. Consult your editor documentation to configure the editor to avoid disclosing secure data. The following sections provide some guidance on common editors but should not be taken as a complete guide to securing your editor." -msgstr "Ansible Vault は、設定されたエディターに依存しており、これが情報漏えいの原因となることがあります。ほとんどのエディターには、データの損失を防ぐ方法がありますが、通常は、秘密のコピーが平文で保存されている可能性のある追加の平文ファイルに依存しています。エディターのドキュメントを参照して、セキュアなデータの開示を回避するようにエディターを設定してください。以下のセクションでは、一般的なエディターに関するガイダンスを提供していますが、エディターのセキュリティーを確保するための完全なガイドと考えるべきではありません。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:298 -msgid "vim" -msgstr "vim" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:300 -msgid "You can set the following ``vim`` options in command mode to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the ``vim`` documentation." -msgstr "以下の ``vim`` オプションをコマンドモードで設定することで、情報漏えいのケースを回避することができます。特にプラグインを使用している場合など、セキュリティーを確保するために変更しなければならない設定が他にもあるかもしれないため、``vim`` のドキュメントを参照してください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:303 -msgid "Disable swapfiles that act like an autosave in case of crash or interruption." -msgstr "クラッシュまたは中断が発生した場合に自動保存として機能する swapfiles を無効にします。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:309 -#: ../../rst/vault_guide/vault_encrypting_content.rst:343 -msgid "Disable creation of backup files." -msgstr "バックアップファイルの作成を無効にします。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:316 -msgid "Disable the viminfo file from copying data from your current session." -msgstr "viminfo ファイルを無効にして、現在のセッションからデータをコピーします。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:322 -msgid "Disable copying to the system clipboard." -msgstr "システムクリップボードへのコピーを無効にします。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:329 -msgid "You can optionally add these settings in ``.vimrc`` for all files, or just specific paths or extensions. See the ``vim`` manual for details." -msgstr "必要に応じて、すべてのファイルまたは特定のパスまたは拡張の ``.vimrc`` にこれらの設定を追加できます。詳細は、``vim`` マニュアルを参照してください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:333 -msgid "Emacs" -msgstr "Emacs" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:335 -msgid "You can set the following Emacs options to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the Emacs documentation." -msgstr "以下の Emacs オプションを設定することで、情報漏えいを回避することができます。特にプラグインを使用する場合は、セキュリティーを確保するために変更する必要がある設定が他にもあるかもしれないため、Emacs のドキュメントを参照してください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:337 -msgid "Do not copy data to the system clipboard." -msgstr "データをシステムクリップボードにコピーしないでください。" - -#: ../../rst/vault_guide/vault_encrypting_content.rst:349 -msgid "Disable autosave files." -msgstr "自動保存ファイルを無効にします。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:4 -msgid "Managing vault passwords" -msgstr "Vault パスワードの管理" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:6 -msgid "Managing your encrypted content is easier if you develop a strategy for managing your vault passwords. A vault password can be any string you choose. There is no special command to create a vault password. However, you need to keep track of your vault passwords. Each time you encrypt a variable or file with Ansible Vault, you must provide a password. When you use an encrypted variable or file in a command or playbook, you must provide the same password that was used to encrypt it. To develop a strategy for managing vault passwords, start with two questions:" -msgstr "暗号化されたコンテンツを管理するには、Vault のパスワードを管理するためのストラテジーを立てるとよいでしょう。Vault パスワードは任意の文字列です。Vault パスワードを作成するための特別なコマンドはありません。しかし、Vault パスワードを管理する必要があります。Ansible Vault で変数やファイルを暗号化する際は、毎回パスワードを入力する必要があります。暗号化された変数やファイルをコマンドや Playbook で使用する際には、暗号化に使用したパスワードを入力する必要があります。Vault のパスワードを管理するためのストラテジーを立てるには、次の 2 つの質問から始めます。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:8 -msgid "Do you want to encrypt all your content with the same password, or use different passwords for different needs?" -msgstr "同じパスワードですべてのコンテンツを暗号化する必要がりますか。または、異なるニーズに合わせて異なるパスワードを使用しますか" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:9 -msgid "Where do you want to store your password or passwords?" -msgstr "パスワードをどこに保存しますか。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:12 -msgid "Choosing between a single password and multiple passwords" -msgstr "1 つのパスワードと複数のパスワードの選択" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:14 -msgid "If you have a small team or few sensitive values, you can use a single password for everything you encrypt with Ansible Vault. Store your vault password securely in a file or a secret manager as described below." -msgstr "少人数のチームや機密性の高い値が少ない場合は、Ansible Vault で暗号化するすべてのものに 1 つのパスワードを使用することができます。Vault のパスワードは、後述するようにファイルやシークレットマネージャーに安全に保管してください。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:16 -msgid "If you have a larger team or many sensitive values, you can use multiple passwords. For example, you can use different passwords for different users or different levels of access. Depending on your needs, you might want a different password for each encrypted file, for each directory, or for each environment. For example, you might have a playbook that includes two vars files, one for the dev environment and one for the production environment, encrypted with two different passwords. When you run the playbook, select the correct vault password for the environment you are targeting, using a vault ID." -msgstr "チームの規模が大きかったり、機密性の高い値が多い場合は、複数のパスワードを使用することができます。たとえば、ユーザーやアクセスレベルごとに異なるパスワードを使用することができます。必要に応じて、暗号化したファイルごと、ディレクトリーごと、あるいは環境ごとに異なるパスワードが必要になる場合があります。たとえば、開発環境用と実稼働環境用の 2 つの vars ファイルを含む Playbook を作成し、2 つの異なるパスワードで暗号化する場合などです。Playbook を実行する際には、Vault ID を使用して、対象となる環境に適した Vault パスワードを選択します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:21 -msgid "Managing multiple passwords with vault IDs" -msgstr "Vault ID を使用した複数パスワードの管理" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:23 -msgid "If you use multiple vault passwords, you can differentiate one password from another with vault IDs. You use the vault ID in three ways:" -msgstr "複数の Vault パスワードを使用する場合は、Vault ID から別のパスワードを区別することができます。以下の 3 つの方法で Vault ID を使用します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:25 -msgid "Pass it with :option:`--vault-id ` to the :ref:`ansible-vault` command when you create encrypted content" -msgstr "暗号化されたコンテンツの作成時に、:option:`--vault-id ` を :ref:`ansible-vault` コマンドに渡します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:26 -msgid "Include it wherever you store the password for that vault ID (see :ref:`storing_vault_passwords`)" -msgstr "その Vault ID のパスワードを保存する場所を追加します (「:ref:`storing_vault_passwords`」を参照)。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:27 -msgid "Pass it with :option:`--vault-id ` to the :ref:`ansible-playbook` command when you run a playbook that uses content you encrypted with that vault ID" -msgstr "Vault ID で暗号化されたコンテンツを使用する Playbook を実行する際に、これを :option:`--vault-id ` で :ref:`ansible-playbook` コマンドに渡します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:29 -msgid "When you pass a vault ID as an option to the :ref:`ansible-vault` command, you add a label (a hint or nickname) to the encrypted content. This label documents which password you used to encrypt it. The encrypted variable or file includes the vault ID label in plain text in the header. The vault ID is the last element before the encrypted content. For example:" -msgstr ":ref:`ansible-vault` コマンドのオプションとして Vault ID を渡すと、暗号化されたコンテンツにラベル (ヒントやニックネーム) が追加されます。このラベルは、どのパスワードを使用して暗号化したかを記録します。暗号化された変数やファイルは、ヘッダーに平文で Vault ID ラベルを含みます。Vault ID は暗号化されたコンテンツの前の最後の要素です。以下に例を示します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:41 -msgid "In addition to the label, you must provide a source for the related password. The source can be a prompt, a file, or a script, depending on how you are storing your vault passwords. The pattern looks like this:" -msgstr "ラベルに加えて、関連するパスワードのソースを提供する必要があります。ソースは、Vault パスワードをどのように保存するかによって、プロンプト、ファイル、またはスクリプトになります。パターンは次のようになります。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:47 -msgid "If your playbook uses multiple encrypted variables or files that you encrypted with different passwords, you must pass the vault IDs when you run that playbook. You can use :option:`--vault-id ` by itself, with :option:`--vault-password-file `, or with :option:`--ask-vault-pass `. The pattern is the same as when you create encrypted content: include the label and the source for the matching password." -msgstr "Playbook が複数の暗号化された変数や、異なるパスワードで暗号化したファイルを使用する場合は、その Playbook を実行する際に Vault ID を渡す必要があります。:option:`--vault-id ` を単独で、もしくは :option:`--vault-password-file ` または :option:`--ask-vault-pass ` と一緒に使用することができます。パターンは、暗号化されたコンテンツを作成するときと同じで、一致するパスワードのラベルとソースを含めます。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:49 -msgid "See below for examples of encrypting content with vault IDs and using content encrypted with vault IDs. The :option:`--vault-id ` option works with any Ansible command that interacts with vaults, including :ref:`ansible-vault`, :ref:`ansible-playbook`, and so on." -msgstr "Vault ID でコンテンツを暗号化する例と、Vault ID で暗号化されたコンテンツを使用する例については、以下を参照してください。:option:`--vault-id ` オプションは、:ref:`ansible-vault`、:ref:`ansible-playbook` など、Vault と相互作用するすべての Ansible コマンドで動作します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:52 -msgid "Limitations of vault IDs" -msgstr "Vault ID の制限" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:54 -msgid "Ansible does not enforce using the same password every time you use a particular vault ID label. You can encrypt different variables or files with the same vault ID label but different passwords. This usually happens when you type the password at a prompt and make a mistake. It is possible to use different passwords with the same vault ID label on purpose. For example, you could use each label as a reference to a class of passwords, rather than a single password. In this scenario, you must always know which specific password or file to use in context. However, you are more likely to encrypt two files with the same vault ID label and different passwords by mistake. If you encrypt two files with the same label but different passwords by accident, you can :ref:`rekey ` one file to fix the issue." -msgstr "Ansible は、特定の Vault ID ラベルを使用するたびに同じパスワードを使用することを強制しません。異なる変数やファイルを、同じ Vault ID ラベルで異なるパスワードを使用して暗号化することができます。これは通常、プロンプトでパスワードを入力して間違えた場合に起こります。意図的に、同じ Vault ID ラベルで異なるパスワードを使用することは可能です。たとえば、各ラベルを、単一のパスワードではなく、パスワードのクラスへの参照として使用することができます。このシナリオでは、どの特定のパスワードまたはファイルを使用するかを常にコンテキストで知っておく必要があります。しかし、誤って同じ Vault ID ラベルと異なるパスワードを使用する 2 つのファイルを暗号化してしまう可能性が高くなります。誤って同じラベルで異なるパスワードの 2 つのファイルを暗号化してしまった場合は、1つのファイルで :ref:`rekey ` を行って問題を解決できます。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:57 -msgid "Enforcing vault ID matching" -msgstr "Vault ID 一致の強制" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:59 -msgid "By default the vault ID label is only a hint to remind you which password you used to encrypt a variable or file. Ansible does not check that the vault ID in the header of the encrypted content matches the vault ID you provide when you use the content. Ansible decrypts all files and variables called by your command or playbook that are encrypted with the password you provide. To check the encrypted content and decrypt it only when the vault ID it contains matches the one you provide with ``--vault-id``, set the config option :ref:`DEFAULT_VAULT_ID_MATCH`. When you set :ref:`DEFAULT_VAULT_ID_MATCH`, each password is only used to decrypt data that was encrypted with the same label. This is efficient, predictable, and can reduce errors when different values are encrypted with different passwords." -msgstr "デフォルトでは、Vault ID ラベルは、変数やファイルの暗号化にどのパスワードを使用したかを思い出させるためのヒントに過ぎません。Ansible は、暗号化されたコンテンツのヘッダーにある Vault ID が、コンテンツの使用時に指定した Vault ID と一致するかどうかはチェックしません。Ansible は、指定したパスワードで暗号化されたコマンドまたは Playbook によって呼び出されたすべてのファイルおよび変数を復号します。暗号化されたコンテンツをチェックし、コンテンツに含まれる Vault ID が ``--vault-id`` で指定したものと一致した場合にのみ暗号化を解除するには、設定オプション :ref:`DEFAULT_VAULT_ID_MATCH` を設定します。:ref:`DEFAULT_VAULT_ID_MATCH` を設定すると、各パスワードは同じラベルで暗号化したデータを復号するためにのみ使用されます。これは効率的で予測可能であり、異なる値が異なるパスワードで暗号化された場合のエラーを減らすことができます。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:62 -msgid "Even with the :ref:`DEFAULT_VAULT_ID_MATCH` setting enabled, Ansible does not enforce using the same password every time you use a particular vault ID label." -msgstr ":ref:`DEFAULT_VAULT_ID_MATCH` の設定が有効になっている場合でも、特定の Vault ID ラベルを使用するたびに、Ansible は同じパスワードの使用を強制しません。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:67 -msgid "Storing and accessing vault passwords" -msgstr "Vault パスワードの保存およびアクセス" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:69 -msgid "You can memorize your vault password, or manually copy vault passwords from any source and paste them at a command-line prompt, but most users store them securely and access them as needed from within Ansible. You have two options for storing vault passwords that work from within Ansible: in files, or in a third-party tool such as the system keyring or a secret manager. If you store your passwords in a third-party tool, you need a vault password client script to retrieve them from within Ansible." -msgstr "Valut パスワードを記憶したり、Valut パスワードを任意のソースから手動でコピーしてコマンドラインプロンプトに貼り付けたりすることもできますが、ほとんどのユーザーは安全に保管し、必要に応じて Ansible 内からアクセスします。Ansible 内で機能する Valut パスワードの保管方法には、ファイルに保管する方法と、システムキーリングやシークレットマネージャーなどのサードパーティーツールに保管する方法があります。サードパーティーのツールにパスワードを保存する場合、Ansible 内からパスワードを取得するには、Vault パスワードクライアントスクリプトが必要です。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:72 -msgid "Storing passwords in files" -msgstr "パスワードのファイルへの保存" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:74 -msgid "To store a vault password in a file, enter the password as a string on a single line in the file. Make sure the permissions on the file are appropriate. Do not add password files to source control." -msgstr "Vault のパスワードをファイルに保存するには、ファイルの 1 行にパスワードを文字列で入力します。ファイルのパーミッションが適切であることを確認してください。パスワードファイルをソースコントロールに追加しないでください。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:79 -msgid "Storing passwords in third-party tools with vault password client scripts" -msgstr "Vault パスワードクライアントスクリプトを使用したサードパーティーツールへのパスワードの保存" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:81 -msgid "You can store your vault passwords on the system keyring, in a database, or in a secret manager and retrieve them from within Ansible using a vault password client script. Enter the password as a string on a single line. If your password has a vault ID, store it in a way that works with your password storage tool." -msgstr "Valut パスワードは、システムキーリング、データベース、またはシークレットマネージャーに保存し、Valut パスワードクライアントスクリプトを使用して Ansible 内から取り出すことができます。パスワードは 1 行の文字列として入力します。パスワードに Vault ID がある場合は、パスワード保存ツールと連携する方法で保存します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:83 -msgid "To create a vault password client script:" -msgstr "Vault パスワードクライアントスクリプトを作成するには、以下のようにします。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:85 -msgid "Create a file with a name ending in either ``-client`` or ``-client.EXTENSION``" -msgstr "``-client`` または ``-client.EXTENSION`` で終わる名前でファイルを作成します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:86 -msgid "Make the file executable" -msgstr "ファイルを実行可能な状態にします。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:90 -msgid "Within the script itself:" -msgstr "スクリプト自体:" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:88 -msgid "Print the passwords to standard output" -msgstr "標準出力にパスワードを出力します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:89 -msgid "Accept a ``--vault-id`` option" -msgstr "``--vault-id`` オプションを許可します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:90 -msgid "If the script prompts for data (for example, a database password), display the prompts to the TTY." -msgstr "スクリプトがデータ (データベースパスワードなど) の入力を求める場合は、TTY にプロンプトが表示されます。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:92 -msgid "When you run a playbook that uses vault passwords stored in a third-party tool, specify the script as the source within the ``--vault-id`` flag. For example:" -msgstr "サードパーティーのツールに保存されている Vault パスワードを使用する Playbook を実行する場合は、``--vault-id`` フラグ内でスクリプトをソースとして指定します。以下を例に示します。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:98 -msgid "Ansible executes the client script with a ``--vault-id`` option so the script knows which vault ID label you specified. For example a script loading passwords from a secret manager can use the vault ID label to pick either the 'dev' or 'prod' password. The example command above results in the following execution of the client script:" -msgstr "Ansible はクライアントスクリプトを ``--vault-id`` オプション付きで実行するため、スクリプトは指定された Vault ID ラベルを知ることができます。たとえば、シークレットマネージャーからパスワードを読み込むスクリプトは、Vault ID ラベルを使用して、「dev」または「prod」のいずれかのパスワードを選択できます。上記のコマンドの例では、クライアントスクリプトの実行結果は次のようになります。" - -#: ../../rst/vault_guide/vault_managing_passwords.rst:104 -msgid "For an example of a client script that loads passwords from the system keyring, see the `vault-keyring-client script `_." -msgstr "システムキーリングからパスワードを読み込むクライアントスクリプトの例は、:file:`vault-keyring-client script ` を参照してください。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:6 -msgid "Using encrypted variables and files" -msgstr "暗号化された変数とファイルの使用" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:8 -msgid "When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or by setting a default password source in a config option or an environment variable." -msgstr "暗号化された変数やファイルを使用するタスクや Playbook を実行する場合は、変数やファイルを復号するためのパスワードを指定する必要があります。コマンドラインまたは、設定オプションか、環境変数でデフォルトのパスワードソースを設定して、これを指定できます。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:11 -msgid "Passing a single password" -msgstr "単一のパスワードを渡す" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:13 -msgid "If all the encrypted variables and files your task or playbook needs use a single password, you can use the :option:`--ask-vault-pass ` or :option:`--vault-password-file ` cli options." -msgstr "タスクや Playbook が必要とするすべての暗号化された変数やファイルが単一のパスワードを使用する場合は、CLI オプション :option:`--ask-vault-pass ` または :option:`--vault-password-file ` を使用できます。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:15 -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:83 -msgid "To prompt for the password:" -msgstr "パスワードを要求する場合は、以下のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:21 -msgid "To retrieve the password from the :file:`/path/to/my/vault-password-file` file:" -msgstr ":file:`/path/to/my/vault-password-file` ファイルからパスワードを取得するには、以下を行います。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:27 -msgid "To get the password from the vault password client script :file:`my-vault-password-client.py`:" -msgstr "Vault パスワードクライアントスクリプト :file:`my-vault-password-client.py` から Vault パスワードを取得する場合は、以下のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:37 -msgid "Passing vault IDs" -msgstr "Vault ID を渡す" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:39 -msgid "You can also use the :option:`--vault-id ` option to pass a single password with its vault label. This approach is clearer when multiple vaults are used within a single inventory." -msgstr ":option:`--vault-id ` オプションを使用して、Vault ラベルで単一のパスワードを渡すこともできます。この方法は、1 つのインベントリー内で複数の vault を使用している場合はより明確になります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:41 -msgid "To prompt for the password for the 'dev' vault ID:" -msgstr "Vault ID「dev」のパスワードを要求する場合は、次のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:47 -msgid "To retrieve the password for the 'dev' vault ID from the :file:`dev-password` file:" -msgstr "「dev」の Vault ID のパスワードを :file:`dev-password` のファイルから取得するには、以下を行います。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:53 -msgid "To get the password for the 'dev' vault ID from the vault password client script :file:`my-vault-password-client.py`:" -msgstr "Vault パスワードクライアントスクリプト :file:`my-vault-password-client.py` から Vault ID 「dev」のパスワードを取得する場合は、以下を行います。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:60 -msgid "Passing multiple vault passwords" -msgstr "複数の Vault パスワードを渡す" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:62 -msgid "If your task or playbook requires multiple encrypted variables or files that you encrypted with different vault IDs, you must use the :option:`--vault-id ` option, passing multiple ``--vault-id`` options to specify the vault IDs ('dev', 'prod', 'cloud', 'db') and sources for the passwords (prompt, file, script). . For example, to use a 'dev' password read from a file and to be prompted for the 'prod' password:" -msgstr "タスクや Playbook で、異なる Vault ID で暗号化した複数の暗号化変数やファイルが必要な場合は、:option:`--vault-id ` オプションを使用し、複数の ``--vault-id`` オプションを渡して Vault ID (「dev」、「prod」、「cloud」、「db」) とパスワードのソース (プロンプト、ファイル、スクリプト) を指定する必要があります。たとえば、ファイルから読み込んだ「dev」のパスワードを使用し、「prod」のパスワードを求めるプロンプトを表示する場合などです。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:68 -msgid "By default the vault ID labels (dev, prod and so on) are only hints. Ansible attempts to decrypt vault content with each password. The password with the same label as the encrypted data will be tried first, after that each vault secret will be tried in the order they were provided on the command line." -msgstr "デフォルトでは、Vault ID ラベル (dev、prodなど) はヒントでしかありません。Ansible は、各パスワードで Vault のコンテンツの復号を試みます。暗号化されたデータと同じラベルのパスワードが最初に試行され、その後、コマンドラインで指定された順に各 Vault シークレットが試行されます。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:70 -msgid "Where the encrypted data has no label, or the label does not match any of the provided labels, the passwords will be tried in the order they are specified. In the example above, the 'dev' password will be tried first, then the 'prod' password for cases where Ansible doesn't know which vault ID is used to encrypt something." -msgstr "暗号化されたデータにラベルがない場合、またはラベルが、提供されたラベルのどれとも一致しない場合、パスワードは指定された順に試行されます。上の例では、「dev」パスワードが最初に試行され、次に「prod」パスワードが試行されます。これは、Ansible がどの Vault ID が何かの暗号化に使用されているかを知らない場合に行われます。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:73 -msgid "Using ``--vault-id`` without a vault ID" -msgstr "Vault ID なしで ``--vault-id`` を使用" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:75 -msgid "The :option:`--vault-id ` option can also be used without specifying a vault-id. This behavior is equivalent to :option:`--ask-vault-pass ` or :option:`--vault-password-file ` so is rarely used." -msgstr ":option:`--vault-id ` オプションは、vault-id を指定せずに使用することもできます。この動作は :option:`--ask-vault-pass ` または :option:`--vault-password-file ` と同等であるため、ほとんど使用されません。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:77 -msgid "For example, to use a password file :file:`dev-password`:" -msgstr "たとえば、パスワードファイル :file:`dev-password` を使用する場合は、以下のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:89 -msgid "To get the password from an executable script :file:`my-vault-password-client.py`:" -msgstr "実行スクリプト :file:`my-vault-password-client.py` からパスワードを取得する場合は、以下のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:96 -msgid "Configuring defaults for using encrypted content" -msgstr "暗号化されたコンテンツを使用するためのデフォルトの設定" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:99 -msgid "Setting a default vault ID" -msgstr "デフォルトの Vault ID の設定" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:101 -msgid "If you use one vault ID more frequently than any other, you can set the config option :ref:`DEFAULT_VAULT_IDENTITY_LIST` to specify a default vault ID and password source. Ansible will use the default vault ID and source any time you do not specify :option:`--vault-id `. You can set multiple values for this option. Setting multiple values is equivalent to passing multiple :option:`--vault-id ` cli options." -msgstr "ある Vault ID を他の Vault IDよ りも頻繁に使用する場合は、設定オプション :ref:`DEFAULT_VAULT_IDENTITY_LIST` を設定して、デフォルトの Vault ID とパスワードソースを指定することができます。Ansible は、:option:`--vault-id ` を指定しない場合は、デフォルトの Vault ID とソースを使用します。このオプションには複数の値を設定できます。複数の値を設定することは、複数の CLI オプション :option:`--vault-id ` を渡すことと同じです。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:104 -msgid "Setting a default password source" -msgstr "デフォルトのパスワードソースの設定" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:106 -msgid "If you don't want to provide the password file on the command line or if you use one vault password file more frequently than any other, you can set the :ref:`DEFAULT_VAULT_PASSWORD_FILE` config option or the :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` environment variable to specify a default file to use. For example, if you set ``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt``, Ansible will automatically search for the password in that file. This is useful if, for example, you use Ansible from a continuous integration system such as Jenkins." -msgstr "コマンドラインでパスワードファイルを指定しない場合や、ある Vault パスワードファイルを他のファイルよりも頻繁に使用する場合は、:ref:`DEFAULT_VAULT_PASSWORD_FILE` 設定オプションまたは環境変数 :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` を設定して、デフォルトファイルを指定して使用できます。たとえば、``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt`` を設定すると、Ansible は自動的にそのファイル内のパスワードを検索します。これは、たとえば、Jenkins などの継続的統合システムから Ansible を使用する場合に便利です。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:108 -msgid "The file that you reference can be either a file containing the password (in plain text), or it can be a script (with executable permissions set) that returns the password." -msgstr "参照するファイルは、パスワードを含むファイル (プレーンテキスト) か、パスワードを返すスクリプト (実行権限が設定されている) のいずれかです。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:111 -msgid "When are encrypted files made visible?" -msgstr "暗号化ファイルをいつ表示するか。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:113 -msgid "In general, content you encrypt with Ansible Vault remains encrypted after execution. However, there is one exception. If you pass an encrypted file as the ``src`` argument to the :ref:`copy `, :ref:`template `, :ref:`unarchive `, :ref:`script ` or :ref:`assemble ` module, the file will not be encrypted on the target host (assuming you supply the correct vault password when you run the play). This behavior is intended and useful. You can encrypt a configuration file or template to avoid sharing the details of your configuration, but when you copy that configuration to servers in your environment, you want it to be decrypted so local users and processes can access it." -msgstr "一般的に、Ansible Vault で暗号化したコンテンツは、実行後も暗号化されたままです。ただし、1 つだけ例外があります。:ref:`copy ` モジュール、:ref:`template ` モジュール、:ref:`unarchive ` モジュール、:ref:`script ` モジュール、または :ref:`assemble ` モジュールへの ``src`` 引数として暗号化されたファイルを渡した場合、そのファイルはターゲットホスト上では暗号化されません (プレイの実行時に正しい Vault パスワードを供給していることが前提です)。この動作は意図されたものであり、便利なものです。設定ファイルやテンプレートを暗号化して、設定の詳細を共有しないようにすることができますが、その設定を環境内のサーバーにコピーするときは、ローカルのユーザーやプロセスがアクセスできるように、暗号化を解除します。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:118 -msgid "Format of files encrypted with Ansible Vault" -msgstr "Ansible Vault で暗号化されたファイルの形式" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:120 -msgid "Ansible Vault creates UTF-8 encoded txt files. The file format includes a newline terminated header. For example:" -msgstr "Ansible Vault は、UTF-8 でエンコードされたテキストファイルを作成します。ファイル形式には、改行で終了するヘッダーが含まれます。以下に例を示します。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:126 -msgid "or" -msgstr "または" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:132 -msgid "The header contains up to four elements, separated by semi-colons (``;``)." -msgstr "ヘッダーには、セミコロン (``;``) で区切られた最大 4 つの要素が含まれます。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:134 -msgid "The format ID (``$ANSIBLE_VAULT``). Currently ``$ANSIBLE_VAULT`` is the only valid format ID. The format ID identifies content that is encrypted with Ansible Vault (via vault.is_encrypted_file())." -msgstr "形式 ID (``$ANSIBLE_VAULT``)。現在、``$ANSIBLE_VAULT`` は唯一の有効な形式 ID です。フォーマット ID は、(vault.is_encrypted_file() を介して) Ansible Vault で暗号化されているコンテンツを識別します。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:136 -msgid "The vault format version (``1.X``). All supported versions of Ansible will currently default to '1.1' or '1.2' if a labeled vault ID is supplied. The '1.0' format is supported for reading only (and will be converted automatically to the '1.1' format on write). The format version is currently used as an exact string compare only (version numbers are not currently 'compared')." -msgstr "Vault 形式バージョン (``1.X``) です。現在、サポートされているすべてのバージョンの Ansible では、ラベル付きの Vault IDが指定された場合は、デフォルトで「1.1」または「1.2」になります。「1.0」形式は読み込みのみサポートしています (書き込み時には自動的に「1.1」形式に変換されます)。形式のバージョンは、現在、正確な文字列の比較としてのみ使用されています (バージョン番号は現在「比較」されません)。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:138 -msgid "The cipher algorithm used to encrypt the data (``AES256``). Currently ``AES256`` is the only supported cipher algorithm. Vault format 1.0 used 'AES', but current code always uses 'AES256'." -msgstr "データの暗号化に使用される暗号アルゴリズム (``AES256``)。現在、``AES256`` が唯一サポートされている暗号アルゴリズムです。Vault 形式 1.0 では「AES」を使用していましたが、現在のコードでは常に「AES256」を使用します。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:140 -msgid "The vault ID label used to encrypt the data (optional, ``vault-id-label``) For example, if you encrypt a file with ``--vault-id dev@prompt``, the vault-id-label is ``dev``." -msgstr "データの暗号化に使用される vault ID ラベル (任意: ``vault-id-label``)。たとえば、``--vault-id dev@prompt`` でファイルを暗号化する場合は、vault-id-label が ``dev`` になります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:142 -msgid "Note: In the future, the header could change. Fields after the format ID and format version depend on the format version, and future vault format versions may add more cipher algorithm options and/or additional fields." -msgstr "注: 将来的には、ヘッダーが変更する可能性があります。形式 ID と形式バージョンの後のフィールドは、形式のバージョンに依存しており、将来の Vault 形式のバージョンでは、暗号アルゴリズムのオプションやフィールドが追加される可能性があります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:144 -msgid "The rest of the content of the file is the 'vaulttext'. The vaulttext is a text armored version of the encrypted ciphertext. Each line is 80 characters wide, except for the last line which may be shorter." -msgstr "ファイルの残りの内容は「vaulttext」です。vaulttext は、暗号化された暗号文のテキスト版です。各行の幅は 80 文字です。ただし、最終行は短くなる場合があります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:148 -msgid "Ansible Vault payload format 1.1 - 1.2" -msgstr "Ansible Vault ペイロード形式 1.1 - 1.2" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:150 -msgid "The vaulttext is a concatenation of the ciphertext and a SHA256 digest with the result 'hexlifyied'." -msgstr "vaulttext は、暗号化テキストと SHA256 ダイジェストを連結したもので、結果は「hexlifyied」です。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:152 -msgid "'hexlify' refers to the ``hexlify()`` method of the Python Standard Library's `binascii `_ module." -msgstr "「hexlify」は、Python 標準ライブラリーの `binascii `_ モジュールの ``hexlify()`` メソッドを指します。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:154 -msgid "hexlify()'ed result of:" -msgstr "hexlify() が行われた結果:" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:156 -msgid "hexlify()'ed string of the salt, followed by a newline (``0x0a``)" -msgstr "hexlify() で編集されたソルトの文字列とそれに続く改行 (``0x0a``)。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:157 -msgid "hexlify()'ed string of the crypted HMAC, followed by a newline. The HMAC is:" -msgstr "hexlify() で暗号化された HMAC の文字列の後に、改行を入れます。その HMAC は以下のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:159 -msgid "a `RFC2104 `_ style HMAC" -msgstr "`RFC2104 `_ スタイルの HMAC" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:161 -msgid "inputs are:" -msgstr "入力は次のとおりです。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:163 -msgid "The AES256 encrypted ciphertext" -msgstr "AES256 で暗号化した暗号文" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:164 -msgid "A PBKDF2 key. This key, the cipher key, and the cipher IV are generated from:" -msgstr "PBKDF2 キー。このキー、暗号キー、および暗号 IV を生成します。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:166 -msgid "the salt, in bytes" -msgstr "バイト単位のソルト" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:167 -msgid "10000 iterations" -msgstr "10000 回の繰り返し" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:168 -msgid "SHA256() algorithm" -msgstr "SHA256() アルゴリズム" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:169 -msgid "the first 32 bytes are the cipher key" -msgstr "最初の 32 バイトは暗号キーです。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:170 -msgid "the second 32 bytes are the HMAC key" -msgstr "2 番目の 32 バイトは HMAC キーです。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:171 -msgid "remaining 16 bytes are the cipher IV" -msgstr "残りの 16 バイトは暗号 IV です。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:173 -msgid "hexlify()'ed string of the ciphertext. The ciphertext is:" -msgstr "暗号文の hexlify() が行われた文字列です。暗号文は以下のようになります。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:175 -msgid "AES256 encrypted data. The data is encrypted using:" -msgstr "AES256 で暗号化されたデータです。データは次を使用して暗号化されます。" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:177 -msgid "AES-CTR stream cipher" -msgstr "AES-CTR ストリーム暗号" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:178 -msgid "cipher key" -msgstr "暗号鍵" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:179 -msgid "IV" -msgstr "IV" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:180 -msgid "a 128 bit counter block seeded from an integer IV" -msgstr "整数 IV からシードされた 128 ビットのカウンターブロック" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:181 -msgid "the plaintext" -msgstr "平文" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:183 -msgid "the original plaintext" -msgstr "元の平文" - -#: ../../rst/vault_guide/vault_using_encrypted_content.rst:184 -msgid "padding up to the AES256 blocksize. (The data used for padding is based on `RFC5652 `_)" -msgstr "AES256 ブロックサイズまでのパディング (パディングに使用するデータは `RFC5652 `_ に基づいています)" - - diff --git a/docs/docsite/rst/module_plugin_guide/index.rst b/docs/docsite/rst/module_plugin_guide/index.rst deleted file mode 100644 index 6f914d0e70d..00000000000 --- a/docs/docsite/rst/module_plugin_guide/index.rst +++ /dev/null @@ -1,30 +0,0 @@ -.. _modules_plugins_index: - -################################# -Using Ansible modules and plugins -################################# - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible guide for working with modules, plugins, and collections. - -Ansible modules are units of code that can control system resources or execute system commands. -Ansible provides a module library that you can execute directly on remote hosts or through playbooks. -You can also write custom modules. - -Similar to modules are plugins, which are pieces of code that extend core Ansible functionality. -Ansible uses a plugin architecture to enable a rich, flexible, and expandable feature set. -Ansible ships with several plugins and lets you easily use your own plugins. - -.. toctree:: - :maxdepth: 2 - - modules_intro - modules_support - plugin_filtering_config - ../plugins/plugins - modules_plugins_index \ No newline at end of file diff --git a/docs/docsite/rst/module_plugin_guide/modules_intro.rst b/docs/docsite/rst/module_plugin_guide/modules_intro.rst deleted file mode 100644 index d6f67c701ff..00000000000 --- a/docs/docsite/rst/module_plugin_guide/modules_intro.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. _intro_modules: - -Introduction to modules -======================= - -Modules (also referred to as "task plugins" or "library plugins") are discrete units of code that can be used from the command line or in a playbook task. Ansible executes each module, usually on the remote managed node, and collects return values. In Ansible 2.10 and later, most modules are hosted in collections. - -You can execute modules from the command line. - -.. code-block:: shell-session - - ansible webservers -m service -a "name=httpd state=started" - ansible webservers -m ping - ansible webservers -m command -a "/sbin/reboot -t now" - -Each module supports taking arguments. Nearly all modules take ``key=value`` arguments, space delimited. Some modules take no arguments, and the command/shell modules simply take the string of the command you want to run. - -From playbooks, Ansible modules are executed in a very similar way. - -.. code-block:: yaml - - - name: reboot the servers - command: /sbin/reboot -t now - -Another way to pass arguments to a module is using YAML syntax, also called 'complex args'. - -.. code-block:: yaml - - - name: restart webserver - service: - name: httpd - state: restarted - -All modules return JSON format data. This means modules can be written in any programming language. Modules should be idempotent, and should avoid making any changes if they detect that the current state matches the desired final state. When used in an Ansible playbook, modules can trigger 'change events' in the form of notifying :ref:`handlers ` to run additional tasks. - -You can access the documentation for each module from the command line with the ansible-doc tool. - -.. code-block:: shell-session - - ansible-doc yum - -For a list of all available modules, see the :ref:`Collection docs `, or run the following at a command prompt. - -.. code-block:: shell-session - - ansible-doc -l - - -.. seealso:: - - :ref:`intro_adhoc` - Examples of using modules in /usr/bin/ansible - :ref:`working_with_playbooks` - Examples of using modules with /usr/bin/ansible-playbook - :ref:`developing_modules` - How to write your own modules - :ref:`developing_api` - Examples of using modules with the Python API - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/module_plugin_guide/modules_plugins_index.rst b/docs/docsite/rst/module_plugin_guide/modules_plugins_index.rst deleted file mode 100644 index 4b7f5503237..00000000000 --- a/docs/docsite/rst/module_plugin_guide/modules_plugins_index.rst +++ /dev/null @@ -1,6 +0,0 @@ -.. _index_modules_plugins: - -Modules and plugins index -========================= - -You can find an index of modules and plugins at :ref:`all_modules_and_plugins`. \ No newline at end of file diff --git a/docs/docsite/rst/module_plugin_guide/modules_support.rst b/docs/docsite/rst/module_plugin_guide/modules_support.rst deleted file mode 100644 index 566ae438834..00000000000 --- a/docs/docsite/rst/module_plugin_guide/modules_support.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _modules_support: - -****************************** -Module maintenance and support -****************************** - -If you are using a module and you discover a bug, you may want to know where to report that bug, who is responsible for fixing it, and how you can track changes to the module. If you are a Red Hat subscriber, you may want to know whether you can get support for the issue you are facing. - -Starting in Ansible 2.10, most modules live in collections. The distribution method for each collection reflects the maintenance and support for the modules in that collection. - -.. contents:: - :local: - -Maintenance -=========== - -.. table:: - :class: documentation-table - - ============================= ========================================== ========================== - Collection Code location Maintained by - ============================= ========================================== ========================== - ansible.builtin `ansible/ansible repo`_ on GitHub core team - - distributed on Galaxy various; follow ``repo`` link community or partners - - distributed on Automation Hub various; follow ``repo`` link content team or partners - ============================= ========================================== ========================== - -.. _ansible/ansible repo: https://github.com/ansible/ansible/tree/devel/lib/ansible/modules - -Issue Reporting -=============== - -If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-core``: - - #. Confirm that you are running the latest stable version of Ansible or the devel branch. - #. Look at the `issue tracker in the Ansible repo `_ to see if an issue has already been filed. - #. Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered. - -If you find a bug that affects a plugin in a Galaxy collection: - - #. Find the collection on Galaxy. - #. Find the issue tracker for the collection. - #. Look there to see if an issue has already been filed. - #. Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered. - -Some partner collections may be hosted in private repositories. - -If you are not sure whether the behavior you see is a bug, if you have questions, if you want to discuss development-oriented topics, or if you just want to get in touch, use one of our Google mailing lists or chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) to :ref:`communicate with Ansiblers `. - -If you find a bug that affects a module in an Automation Hub collection: - - #. If the collection offers an Issue Tracker link on Automation Hub, click there and open an issue on the collection repository. If it does not, follow the standard process for reporting issues on the `Red Hat Customer Portal `_. You must have a subscription to the Red Hat Ansible Automation Platform to create an issue on the portal. - -Support -======= - -All plugins that remain in ``ansible-core`` and all collections hosted in Automation Hub are supported by Red Hat. No other plugins or collections are supported by Red Hat. If you have a subscription to the Red Hat Ansible Automation Platform, you can find more information and resources on the `Red Hat Customer Portal. `_ - -.. seealso:: - - :ref:`intro_adhoc` - Examples of using modules in /usr/bin/ansible - :ref:`working_with_playbooks` - Examples of using modules with /usr/bin/ansible-playbook - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/module_plugin_guide/plugin_filtering_config.rst b/docs/docsite/rst/module_plugin_guide/plugin_filtering_config.rst deleted file mode 100644 index 28f7d48794b..00000000000 --- a/docs/docsite/rst/module_plugin_guide/plugin_filtering_config.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _plugin_filtering_config: - -Rejecting modules -================= - -If you want to avoid using certain modules, you can add them to a reject list to prevent Ansible from loading them. To reject plugins, create a yaml configuration file. The default location for this file is :file:`/etc/ansible/plugin_filters.yml`. You can select a different path for the reject list using the :ref:`PLUGIN_FILTERS_CFG` setting in the ``defaults`` section of your ansible.cfg. Here is an example reject list: - -.. code-block:: YAML - - --- - filter_version: '1.0' - module_rejectlist: - # Deprecated - - docker - # We only allow pip, not easy_install - - easy_install - -The file contains two fields: - - * A file version so that you can update the format while keeping backwards compatibility in the future. The present version should be the string, ``"1.0"`` - - * A list of modules to reject. Ansible will not load any module in this list when it searches for a module to invoke for a task. - -.. note:: - - The ``stat`` module is required for Ansible to run. Do not add this module to your reject list. diff --git a/docs/docsite/rst/network/dev_guide/developing_plugins_network.rst b/docs/docsite/rst/network/dev_guide/developing_plugins_network.rst deleted file mode 100644 index b550c280ff6..00000000000 --- a/docs/docsite/rst/network/dev_guide/developing_plugins_network.rst +++ /dev/null @@ -1,265 +0,0 @@ - -.. _developing_modules_network: -.. _developing_plugins_network: - -************************** -Developing network plugins -************************** - -You can extend the existing network modules with custom plugins in your collection. - -.. contents:: - :local: - -Network connection plugins -========================== -Each network connection plugin has a set of its own plugins which provide a specification of the -connection for a particular set of devices. The specific plugin used is selected at runtime based -on the value of the ``ansible_network_os`` variable assigned to the host. This variable should be -set to the same value as the name of the plugin to be loaded. Thus, ``ansible_network_os=nxos`` -will try to load a plugin in a file named ``nxos.py``, so it is important to name the plugin in a -way that will be sensible to users. - -Public methods of these plugins may be called from a module or module_utils with the connection -proxy object just as other connection methods can. The following is a very simple example of using -such a call in a module_utils file so it may be shared with other modules. - -.. code-block:: python - - from ansible.module_utils.connection import Connection - - def get_config(module): - # module is your AnsibleModule instance. - connection = Connection(module._socket_path) - - # You can now call any method (that doesn't start with '_') of the connection - # plugin or its platform-specific plugin - return connection.get_config() - -.. contents:: - :local: - -.. _developing_plugins_httpapi: - -Developing httpapi plugins -========================== - -:ref:`httpapi plugins ` serve as adapters for various HTTP(S) APIs for use with the ``httpapi`` connection plugin. They should implement a minimal set of convenience methods tailored to the API you are attempting to use. - -Specifically, there are a few methods that the ``httpapi`` connection plugin expects to exist. - -Making requests ---------------- - -The ``httpapi`` connection plugin has a ``send()`` method, but an httpapi plugin needs a ``send_request(self, data, **message_kwargs)`` method as a higher-level wrapper to ``send()``. This method should prepare requests by adding fixed values like common headers or URL root paths. This method may do more complex work such as turning data into formatted payloads, or determining which path or method to request. It may then also unpack responses to be more easily consumed by the caller. - -.. code-block:: python - - from ansible.module_utils.six.moves.urllib.error import HTTPError - - def send_request(self, data, path, method='POST'): - # Fixed headers for requests - headers = {'Content-Type': 'application/json'} - try: - response, response_content = self.connection.send(path, data, method=method, headers=headers) - except HTTPError as exc: - return exc.code, exc.read() - - # handle_response (defined separately) will take the format returned by the device - # and transform it into something more suitable for use by modules. - # This may be JSON text to Python dictionaries, for example. - return handle_response(response_content) - -Authenticating --------------- - -By default, all requests will authenticate with HTTP Basic authentication. If a request can return some kind of token to stand in place of HTTP Basic, the ``update_auth(self, response, response_text)`` method should be implemented to inspect responses for such tokens. If the token is meant to be included with the headers of each request, it is sufficient to return a dictionary which will be merged with the computed headers for each request. The default implementation of this method does exactly this for cookies. If the token is used in another way, say in a query string, you should instead save that token to an instance variable, where the ``send_request()`` method (above) can add it to each request - -.. code-block:: python - - def update_auth(self, response, response_text): - cookie = response.info().get('Set-Cookie') - if cookie: - return {'Cookie': cookie} - - return None - -If instead an explicit login endpoint needs to be requested to receive an authentication token, the ``login(self, username, password)`` method can be implemented to call that endpoint. If implemented, this method will be called once before requesting any other resources of the server. By default, it will also be attempted once when a HTTP 401 is returned from a request. - -.. code-block:: python - - def login(self, username, password): - login_path = '/my/login/path' - data = {'user': username, 'password': password} - - response = self.send_request(data, path=login_path) - try: - # This is still sent as an HTTP header, so we can set our connection's _auth - # variable manually. If the token is returned to the device in another way, - # you will have to keep track of it another way and make sure that it is sent - # with the rest of the request from send_request() - self.connection._auth = {'X-api-token': response['token']} - except KeyError: - raise AnsibleAuthenticationFailure(message="Failed to acquire login token.") - -Similarly, ``logout(self)`` can be implemented to call an endpoint to invalidate and/or release the current token, if such an endpoint exists. This will be automatically called when the connection is closed (and, by extension, when reset). - -.. code-block:: python - - def logout(self): - logout_path = '/my/logout/path' - self.send_request(None, path=logout_path) - - # Clean up tokens - self.connection._auth = None - -Error handling --------------- - -The ``handle_httperror(self, exception)`` method can deal with status codes returned by the server. The return value indicates how the plugin will continue with the request: - -* A value of ``true`` means that the request can be retried. This my be used to indicate a transient error, or one that has been resolved. For example, the default implementation will try to call ``login()`` when presented with a 401, and return ``true`` if successful. - -* A value of ``false`` means that the plugin is unable to recover from this response. The status code will be raised as an exception to the calling module. - -* Any other value will be taken as a nonfatal response from the request. This may be useful if the server returns error messages in the body of the response. Returning the original exception is usually sufficient in this case, as HTTPError objects have the same interface as a successful response. - -For example httpapi plugins, see the `source code for the httpapi plugins `_ included with Ansible Core. - - - -Developing NETCONF plugins -========================== - -The :ref:`netconf ` connection plugin provides a connection to remote devices over the ``SSH NETCONF`` subsystem. Network devices typically use this connection plugin to send and receive ``RPC`` calls over ``NETCONF``. - -The ``netconf`` connection plugin uses the ``ncclient`` Python library under the hood to initiate a NETCONF session with a NETCONF-enabled remote network device. ``ncclient`` also executes NETCONF RPC requests and receives responses. You must install the ``ncclient`` on the local Ansible controller. - -To use the ``netconf`` connection plugin for network devices that support standard NETCONF (:RFC:`6241`) operations such as ``get``, ``get-config``, ``edit-config``, set ``ansible_network_os=default``. -You can use :ref:`netconf_get `, :ref:`netconf_config ` and :ref:`netconf_rpc ` modules to talk to a NETCONF enabled remote host. - -As a contributor and user, you should be able to use all the methods under the ``NetconfBase`` class if your device supports standard NETCONF. You can contribute a new plugin if the device you are working with has a vendor specific NETCONF RPC. -To support a vendor specific NETCONF RPC, add the implementation in the network OS specific NETCONF plugin. - -For Junos for example: - -* See the vendor-specific Junos RPC methods implemented in ``plugins/netconf/junos.py``. -* Set the value of ``ansible_network_os`` to the name of the netconf plugin file, that is ``junos`` in this case. - -.. _developing_plugins_network_cli: - -Developing network_cli plugins -============================== - -The :ref:`network_cli ` connection type uses ``paramiko_ssh`` under the hood which creates a pseudo terminal to send commands and receive responses. -``network_cli`` loads two platform specific plugins based on the value of ``ansible_network_os``: - -* Terminal plugin (for example ``plugins/terminal/ios.py``) - Controls the parameters related to terminal, such as setting terminal length and width, page disabling and privilege escalation. Also defines regex to identify the command prompt and error prompts. - -* :ref:`cliconf_plugins` (for example, :ref:`ios cliconf `) - Provides an abstraction layer for low level send and receive operations. For example, the ``edit_config()`` method ensures that the prompt is in ``config`` mode before executing configuration commands. - -To contribute a new network operating system to work with the ``network_cli`` connection, implement the ``cliconf`` and ``terminal`` plugins for that network OS. - -The plugins can reside in: - -* Adjacent to playbook in folders - - .. code-block:: bash - - cliconf_plugins/ - terminal_plugins/ - -* Roles - - .. code-block:: bash - - myrole/cliconf_plugins/ - myrole/terminal_plugins/ - -* Collections - - .. code-block:: bash - - myorg/mycollection/plugins/terminal/ - myorg/mycollection/plugins/cliconf/ - -The user can also set the :ref:`DEFAULT_CLICONF_PLUGIN_PATH` to configure the ``cliconf`` plugin path. - -After adding the ``cliconf`` and ``terminal`` plugins in the expected locations, users can: - -* Use the :ref:`cli_command ` to run an arbitrary command on the network device. -* Use the :ref:`cli_config ` to implement configuration changes on the remote hosts without platform-specific modules. - - -.. _develop_cli_parse_plugins: - -Developing cli_parser plugins in a collection -=============================================== - -You can use ``cli_parse`` as an entry point for a cli_parser plugin in -your own collection. - -The following sample shows the start of a custom cli_parser plugin: - -.. code-block:: python - - from ansible_collections.ansible.netcommon.plugins.module_utils.cli_parser.cli_parserbase import ( - CliParserBase, - ) - - class CliParser(CliParserBase): - """ Sample cli_parser plugin - """ - - # Use the follow extension when loading a template - DEFAULT_TEMPLATE_EXTENSION = "txt" - # Provide the contents of the template to the parse function - PROVIDE_TEMPLATE_CONTENTS = True - - def myparser(text, template_contents): - # parse the text using the template contents - return {...} - - def parse(self, *_args, **kwargs): - """ Standard entry point for a cli_parse parse execution - - :return: Errors or parsed text as structured data - :rtype: dict - - :example: - - The parse function of a parser should return a dict: - {"errors": [a list of errors]} - or - {"parsed": obj} - """ - template_contents = kwargs["template_contents"] - text = self._task_args.get("text") - try: - parsed = myparser(text, template_contents) - except Exception as exc: - msg = "Custom parser returned an error while parsing. Error: {err}" - return {"errors": [msg.format(err=to_native(exc))]} - return {"parsed": parsed} - -The following task uses this custom cli_parser plugin: - -.. code-block:: yaml - - - name: Use a custom cli_parser - ansible.netcommon.cli_parse: - command: ls -l - parser: - name: my_organiztion.my_collection.custom_parser - -To develop a custom plugin: -- Each cli_parser plugin requires a ``CliParser`` class. -- Each cli_parser plugin requires a ``parse`` function. -- Always return a dictionary with ``errors`` or ``parsed``. -- Place the custom cli_parser in plugins/cli_parsers directory of the collection. -- See the `current cli_parsers `_ for examples to follow. - - -.. seealso:: - - * :ref:`cli_parsing` diff --git a/docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst b/docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst deleted file mode 100644 index fe16c57e951..00000000000 --- a/docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst +++ /dev/null @@ -1,826 +0,0 @@ - -.. _developing_resource_modules: - -*********************************** -Developing network resource modules -*********************************** - -.. contents:: - :local: - :depth: 2 - -Understanding network and security resource modules -=================================================== - -Network and security devices separate configuration into sections (such as interfaces, VLANs, and so on) that apply to a network or security service. Ansible resource modules take advantage of this to allow users to configure subsections or resources within the device configuration. Resource modules provide a consistent experience across different network and security devices. For example, a network resource module may only update the configuration for a specific portion of the network interfaces, VLANs, ACLs, and so on for a network device. The resource module: - -#. Fetches a piece of the configuration (fact gathering), for example, the interfaces configuration. -#. Converts the returned configuration into key-value pairs. -#. Places those key-value pairs into an internal independent structured data format. - -Now that the configuration data is normalized, the user can update and modify the data and then use the resource module to send the configuration data back to the device. This results in a full round-trip configuration update without the need for manual parsing, data manipulation, and data model management. - -The resource module has two top-level keys - ``config`` and ``state``: - -* ``config`` defines the resource configuration data model as key-value pairs. The type of the ``config`` option can be ``dict`` or ``list of dict`` based on the resource managed. That is, if the device has a single global configuration, it should be a ``dict`` (for example, a global LLDP configuration). If the device has multiple instances of configuration, it should be of type ``list`` with each element in the list of type ``dict`` (for example, interfaces configuration). - - -* ``state`` defines the action the resource module takes on the end device. - -The ``state`` for a new resource module should support the following values (as applicable for the devices that support them): - -merged - Ansible merges the on-device configuration with the provided configuration in the task. - -replaced - Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task. - -overridden - Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration). - -deleted - Ansible deletes the on-device configuration subsection and restores any default settings. - -gathered - Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result. - -rendered - Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline. - -parsed - Ansible parses the configuration from the ``running_configuration`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline. - - -Modules in Ansible-maintained collections must support these state values. If you develop a module with only "present" and "absent" for state, you may submit it to a community collection. - -.. note:: - - The states ``rendered``, ``gathered``, and ``parsed`` do not perform any change on the device. - -.. seealso:: - - `Deep Dive on VLANs Resource Modules for Network Automation `_ - Walkthrough of how state values are implemented for VLANs. - - -Developing network and security resource modules -================================================= - -The Ansible Engineering team ensures the module design and code pattern within Ansible-maintained collections is uniform across resources and across platforms to give a vendor-independent feel and deliver good quality code. We recommend you use the `resource module builder `_ to develop a resource module. - - -The highlevel process for developing a resource module is: - -#. Create and share a resource model design in the `resource module models repository `_ as a PR for review. -#. Download the latest version of the `resource module builder `_. -#. Run the ``resource module builder`` to create a collection scaffold from your approved resource model. -#. Write the code to implement your resource module. -#. Develop integration and unit tests to verify your resource module. -#. Create a PR to the appropriate collection that you want to add your new resource module to. See :ref:`contributing_maintained_collections` for details on determining the correct collection for your module. - - -Understanding the model and resource module builder ------------------------------------------------------ - -The resource module builder is an Ansible Playbook that helps developers scaffold and maintain an Ansible resource module. It uses a model as the single source of truth for the module. This model is a ``yaml`` file that is used for the module DOCUMENTATION section and the argument spec. - -The resource module builder has the following capabilities: - -- Uses a defined model to scaffold a resource module directory layout and initial class files. -- Scaffolds either an Ansible role or a collection. -- Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring. -- Allows you to store complex examples along side the model in the same directory. -- Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed. -- Generates working sample modules for both ``_`` and ``_facts``. - -Accessing the resource module builder -------------------------------------- - -To access the resource module builder: - -1. clone the github repository: - - .. code-block:: bash - - git clone https://github.com/ansible-network/resource_module_builder.git - -2. Install the requirements: - - .. code-block:: bash - - pip install -r requirements.txt - -Creating a model ------------------ - -You must create a model for your new resource. The model is the single source of truth for both the argspec and docstring, keeping them in sync. Once your model is approved, you can use the resource module builder to generate three items based on the model: - -* The scaffold for a new module -* The argspec for the new module -* The docstring for the new module - -For any subsequent changes to the functionality, update the model first and use the resource module builder to update the module argspec and docstring. - -For example, the resource model builder includes the ``myos_interfaces.yml`` sample in the :file:`models` directory, as seen below: - -.. code-block:: yaml - - --- - GENERATOR_VERSION: '1.0' - - NETWORK_OS: myos - RESOURCE: interfaces - COPYRIGHT: Copyright 2019 Red Hat - LICENSE: gpl-3.0.txt - - DOCUMENTATION: | - module: myos_interfaces - version_added: 1.0.0 - short_description: 'Manages attributes of ' - description: 'Manages attributes of .' - author: Ansible Network Engineer - notes: - - 'Tested against ' - options: - config: - description: The provided configuration - type: list - elements: dict - suboptions: - name: - type: str - description: The name of the - some_string: - type: str - description: - - The some_string_01 - choices: - - choice_a - - choice_b - - choice_c - default: choice_a - some_bool: - description: - - The some_bool. - type: bool - some_int: - description: - - The some_int. - type: int - version_added: '1.1.0' - some_dict: - type: dict - description: - - The some_dict. - suboptions: - property_01: - description: - - The property_01 - type: str - state: - description: - - The state of the configuration after module completion. - type: str - choices: - - merged - - replaced - - overridden - - deleted - default: merged - EXAMPLES: - - deleted_example_01.txt - - merged_example_01.txt - - overridden_example_01.txt - - replaced_example_01.txt - -Notice that you should include examples for each of the states that the resource supports. The resource module builder also includes these in the sample model. - -Share this model as a PR for review at `resource module models repository `_. You can also see more model examples at that location. - - -Creating a collection scaffold from a resource model ----------------------------------------------------- - -To use the resource module builder to create a collection scaffold from your approved resource model: - -.. code-block:: bash - - ansible-playbook -e rm_dest= \ - -e structure=collection \ - -e collection_org= \ - -e collection_name= \ - -e model= \ - site.yml - -Where the parameters are as follows: - -- ``rm_dest``: The directory where the resource module builder places the files and directories for the resource module and facts modules. -- ``structure``: The directory layout type (role or collection) - - - ``role``: Generate a role directory layout. - - ``collection``: Generate a collection directory layout. - -- ``collection_org``: The organization of the collection, required when `structure=collection`. -- ``collection_name``: The name of the collection, required when `structure=collection`. -- ``model``: The path to the model file. - -To use the resource module builder to create a role scaffold: - -.. code-block:: bash - - ansible-playbook -e rm_dest= \ - -e structure=role \ - -e model= \ - site.yml - -Examples -======== - -Collection directory layout ---------------------------- - -This example shows the directory layout for the following: - -- ``network_os``: myos -- ``resource``: interfaces - -.. code-block:: bash - - ansible-playbook -e rm_dest=~/github/rm_example \ - -e structure=collection \ - -e collection_org=cidrblock \ - -e collection_name=my_collection \ - -e model=models/myos/interfaces/myos_interfaces.yml \ - site.yml - -.. code-block:: text - - ├── docs - ├── LICENSE.txt - ├── playbooks - ├── plugins - | ├── action - | ├── filter - | ├── inventory - | ├── modules - | | ├── __init__.py - | | ├── myos_facts.py - | | └── myos_interfaces.py - | └── module_utils - | ├── __init__.py - | └── network - | ├── __init__.py - | └── myos - | ├── argspec - | | ├── facts - | | | ├── facts.py - | | | └── __init__.py - | | ├── __init__.py - | | └── interfaces - | | ├── __init__.py - | | └── interfaces.py - | ├── config - | | ├── __init__.py - | | └── interfaces - | | ├── __init__.py - | | └── interfaces.py - | ├── facts - | | ├── facts.py - | | ├── __init__.py - | | └── interfaces - | | ├── __init__.py - | | └── interfaces.py - | ├── __init__.py - | └── utils - | ├── __init__.py - | └── utils.py - ├── README.md - └── roles - - -Role directory layout ---------------------- - -This example displays the role directory layout for the following: - -- ``network_os``: myos -- ``resource``: interfaces - -.. code-block:: bash - - ansible-playbook -e rm_dest=~/github/rm_example/roles/my_role \ - -e structure=role \ - -e model=models/myos/interfaces/myos_interfaces.yml \ - site.yml - - -.. code-block:: text - - roles - └── my_role - ├── library - │ ├── __init__.py - │ ├── myos_facts.py - │ └── myos_interfaces.py - ├── LICENSE.txt - ├── module_utils - │ ├── __init__.py - │ └── network - │ ├── __init__.py - │ └── myos - │ ├── argspec - │ │ ├── facts - │ │ │ ├── facts.py - │ │ │ └── __init__.py - │ │ ├── __init__.py - │ │ └── interfaces - │ │ ├── __init__.py - │ │ └── interfaces.py - │ ├── config - │ │ ├── __init__.py - │ │ └── interfaces - │ │ ├── __init__.py - │ │ └── interfaces.py - │ ├── facts - │ │ ├── facts.py - │ │ ├── __init__.py - │ │ └── interfaces - │ │ ├── __init__.py - │ │ └── interfaces.py - │ ├── __init__.py - │ └── utils - │ ├── __init__.py - │ └── utils.py - └── README.md - - -Using the collection --------------------- - -This example shows how to use the generated collection in a playbook: - - .. code-block:: yaml - - ---- - - hosts: myos101 - gather_facts: False - tasks: - - cidrblock.my_collection.myos_interfaces: - register: result - - debug: - var: result - - cidrblock.my_collection.myos_facts: - - debug: - var: ansible_network_resources - - -Using the role --------------- - -This example shows how to use the generated role in a playbook: - -.. code-block:: yaml - - - hosts: myos101 - gather_facts: False - roles: - - my_role - - - hosts: myos101 - gather_facts: False - tasks: - - myos_interfaces: - register: result - - debug: - var: result - - myos_facts: - - debug: - var: ansible_network_resources - - -Resource module structure and workflow -====================================== - -The resource module structure includes the following components: - -Module - * ``library/_.py``. - * Imports the ``module_utils`` resource package and calls ``execute_module`` API: - - .. code-block:: text - - def main(): - result = (module).execute_module() - -Module argspec - * ``module_utils//argspec//``. - * Argspec for the resource. - -Facts - * ``module_utils//facts//``. - * Populate facts for the resource. - * Entry in ``module_utils//facts/facts.py`` for ``get_facts`` API to keep ``_facts`` module and facts gathered for the resource module in sync for every subset. - * Entry of Resource subset in FACTS_RESOURCE_SUBSETS list in ``module_utils//facts/facts.py`` to make facts collection work. - -Module package in module_utils - * ``module_utils////``. - * Implement ``execute_module`` API that loads the configuration to device and generates the result with ``changed``, ``commands``, ``before`` and ``after`` keys. - * Call ``get_facts`` API that returns the ```` configuration facts or return the difference if the device has onbox diff support. - * Compare facts gathered and given key-values if diff is not supported. - * Generate final configuration. - -Utils - * ``module_utils//utils``. - * Utilities for the ```` platform. - -.. _tox_resource_modules: - -Running ``ansible-test sanity`` and ``tox`` on resource modules -================================================================ - -You should run ``ansible-test sanity`` and ``tox -elinters`` from the collection root directory before pushing your PR to an Ansible-maintained collection. The CI runs both and will fail if these tests fail. See :ref:`developing_testing` for details on ``ansible-test sanity``. - -To install the necessary packages: - -#. Ensure you have a valid Ansible development environment configured. See :ref:`environment_setup` for details. -#. Run ``pip install -r requirements.txt`` from the collection root directory. - - - Running ``tox -elinters``: - - * Reads :file:`tox.ini` from the collection root directory and installs required dependencies (such as ``black`` and ``flake8``). - * Runs these with preconfigured options (such as line-length and ignores.) - * Runs ``black`` in check mode to show which files will be formatted without actually formatting them. - -Testing resource modules -======================== - -The tests rely on a role generated by the resource module builder. After changes to the resource module builder, the role should be regenerated and the tests modified and run as needed. To generate the role after changes: - -.. code-block:: bash - - rm -rf rmb_tests/roles/my_role - ansible-playbook -e rm_dest=./rmb_tests/roles/my_role \ - -e structure=role \ - -e model=models/myos/interfaces/myos_interfaces.yml \ - site.yml - - -.. _testing_resource_modules: - -Resource module integration tests ----------------------------------- - -High-level integration test requirements for new resource modules are as follows: - -#. Write a test case for every state. -#. Write additional test cases to test the behavior of the module when an empty ``config.yaml`` is given. -#. Add a round trip test case. This involves a ``merge`` operation, followed by ``gather_facts``, a ``merge`` update with additional configuration, and then reverting back to the base configuration using the previously gathered facts with the ``state`` set to ``overridden``. -#. Wherever applicable, assertions should check after and before ``dicts`` against a hard coded Source of Truth. - -.. _using_zuul_resource_modules: - -We use Zuul as the CI to run the integration test. - -* To view the report, click :guilabel:`Details` on the CI comment in the PR -* To view a failure report, click :guilabel:`ansible/check` and select the failed test. -* To view logs while the test is running, check for your PR number in the `Zuul status board `_. -* To fix static test failure locally, run the :command:`tox -e black` **inside the root folder of collection**. - -To view The Ansible run logs and debug test failures: - -#. Click the failed job to get the summary, and click :guilabel:`Logs` for the log. -#. Click :guilabel:`console` and scroll down to find the failed test. -#. Click :guilabel:`>` next to the failed test for complete details. - - -Integration test structure -........................... - -Each test case should generally follow this pattern: - -* setup —> test —> assert —> test again (for idempotency) —> assert —> tear down (if needed) -> done. This keeps test playbooks from becoming monolithic and difficult to troubleshoot. -* Include a name for each task that is not an assertion. You can add names to assertions as well, but it is easier to identify the broken task within a failed test if you add a name for each task. -* Files containing test cases must end in ``.yaml`` - -Implementation -.............. - -For platforms that support ``connection: local`` *and* ``connection: network_cli`` use the following guidance: - -* Name the :file:`targets/` directories after the module name. -* The :file:`main.yaml` file should just reference the transport. - -The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos `_ collection: - -``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml`` - -.. code-block:: yaml - - --- - - import_tasks: cli.yaml - tags: - - cli - -``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml`` - -.. code-block:: yaml - - --- - - name: collect all cli test cases - find: - paths: "{{ role_path }}/tests/cli" - patterns: "{{ testcase }}.yaml" - register: test_cases - delegate_to: localhost - - - name: set test_items - set_fact: test_items="{{ test_cases.files | map(attribute='path') | list }}" - - - name: run test cases (connection=network_cli) - include_tasks: - file: "{{ test_case_to_run }}" - vars: - ansible_connection: network_cli - with_items: "{{ test_items }}" - loop_control: - loop_var: test_case_to_run - - - name: run test case (connection=local) - include_tasks: - file: "{{ test_case_to_run }}" - vars: - ansible_connection: local - ansible_become: no - with_first_found: "{{ test_items }}" - loop_control: - loop_var: test_case_to_run - -``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml`` - -.. code-block:: yaml - - --- - - debug: - msg: START vyos_l3_interfaces merged integration tests on connection={{ ansible_connection - }} - - - import_tasks: _remove_config.yaml - - - block: - - - import_tasks: _populate.yaml - - - name: Overrides all device configuration with provided configuration - register: result - vyos.vyos.vyos_l3_interfaces: &id001 - config: - - - name: eth0 - ipv4: - - - address: dhcp - - - name: eth1 - ipv4: - - - address: 192.0.2.15/24 - state: overridden - - - name: Assert that before dicts were correctly generated - assert: - that: - - "{{ populate | symmetric_difference(result['before']) |length == 0 }}" - - - name: Assert that correct commands were generated - assert: - that: - - "{{ overridden['commands'] | symmetric_difference(result['commands'])\ - \ |length == 0 }}" - - - name: Assert that after dicts were correctly generated - assert: - that: - - "{{ overridden['after'] | symmetric_difference(result['after']) |length\ - \ == 0 }}" - - - name: Overrides all device configuration with provided configurations (IDEMPOTENT) - register: result - vyos.vyos.vyos_l3_interfaces: *id001 - - - name: Assert that the previous task was idempotent - assert: - that: - - result['changed'] == false - - - name: Assert that before dicts were correctly generated - assert: - that: - - "{{ overridden['after'] | symmetric_difference(result['before']) |length\ - \ == 0 }}" - always: - - - import_tasks: _remove_config.yaml - - -Detecting test resources at runtime -................................... - -Your tests should detect resources (such as interfaces) at runtime rather than hard-coding them into the test. This allows the test to run on a variety of systems. - -For example: - -.. code-block:: yaml - - - name: Collect interface list - connection: ansible.netcommon.network_cli - register: intout - cisco.nxos.nxos_command: - commands: - - show interface brief | json - - - set_fact: - intdataraw: "{{ intout.stdout_lines[0]['TABLE_interface']['ROW_interface'] }}" - - - set_fact: - nxos_int1: '{{ intdataraw[1].interface }}' - - - set_fact: - nxos_int2: '{{ intdataraw[2].interface }}' - - - set_fact: - nxos_int3: '{{ intdataraw[3].interface }}' - - -See the complete test example of this at https://github.com/ansible-collections/cisco.nxos/blob/main/tests/integration/targets/prepare_nxos_tests/tasks/main.yml. - - -Running network integration tests -.................................. - -Ansible uses Zuul to run an integration test suite on every PR, including new tests introduced by that PR. To find and fix problems in network modules, run the network integration test locally before you submit a PR. - - -First, create an inventory file that points to your test machines. The inventory group should match the platform name (for example, ``eos``, ``ios``): - -.. code-block:: bash - - cd test/integration - cp inventory.network.template inventory.networking - ${EDITOR:-vi} inventory.networking - # Add in machines for the platform(s) you wish to test - -To run these network integration tests, use ``ansible-test network-integration --inventory     ``: - -.. code-block:: console - - ansible-test network-integration --inventory ~/myinventory -vvv vyos_facts - ansible-test network-integration --inventory ~/myinventory -vvv vyos_.* - - - -To run all network tests for a particular platform: - -.. code-block:: bash - - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_.* - -This example will run against all ``vyos`` modules. Note that ``vyos_.*`` is a regex match, not a bash wildcard - include the `.` if you modify this example. - -To run integration tests for a specific module: - -.. code-block:: bash - - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces - -To run a single test case on a specific module: - -.. code-block:: bash - - # Only run vyos_l3_interfaces/tests/cli/gathered.yaml - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces --testcase gathered - -To run integration tests for a specific transport: - -.. code-block:: bash - - # Only run nxapi test - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking --tags="nxapi" nxos_.* - - # Skip any cli tests - ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking --skip-tags="cli" nxos_.* - -See `test/integration/targets/nxos_bgp/tasks/main.yaml `_ for how this is implemented in the tests. - -For more options: - -.. code-block:: bash - - ansible-test network-integration --help - -If you need additional help or feedback, reach out in the ``#ansible-network`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_). - -Unit test requirements ------------------------ - -High-level unit test requirements that new resource modules should follow: - -#. Write test cases for all the states with all possible combinations of config values. -#. Write test cases to test the error conditions ( negative scenarios). -#. Check the value of ``changed`` and ``commands`` keys in every test case. - -We run all unit test cases on our Zuul test suite, on the latest python version supported by our CI setup. - -Use the :ref:`same procedure ` as the integration tests to view Zuul unit tests reports and logs. - -See :ref:`unit module testing ` for general unit test details. - -.. end of cut n .. parsed-literal:: - - -Example: Unit testing Ansible network resource modules -====================================================== - - -This section walks through an example of how to develop unit tests for Ansible resource -modules. - -See :ref:`testing_units` and :ref:`testing_units_modules` for general documentation on Ansible unit tests for modules. -Please read those pages first to understand unit tests and why and when you should use them. - - -Using mock objects to unit test Ansible network resource modules ----------------------------------------------------------------- - - -`Mock objects `_ can be very -useful in building unit tests for special or difficult cases, but they can also -lead to complex and confusing coding situations. One good use for mocks would be to -simulate an API. The ``mock`` Python package is bundled with Ansible (use -``import units.compat.mock``). - -You can mock the device connection and output from the device as follows: - -.. code-block:: python - - self.mock_get_config = patch( "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.network.Config.get_config" - ) - self.get_config = self.mock_get_config.start() - - self.mock_load_config = patch( - "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.network.Config.load_config" - ) - self.load_config = self.mock_load_config.start() - - self.mock_get_resource_connection_config = patch( - "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.cfg.base.get_resource_connection" - ) - self.get_resource_connection_config = (self.mock_get_resource_connection_config.start()) - - self.mock_get_resource_connection_facts = patch( - "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.facts.facts.get_resource_connection" - ) - self.get_resource_connection_facts = (self.mock_get_resource_connection_facts.start()) - - self.mock_edit_config = patch( - "ansible_collections.arista.eos.plugins.module_utils.network.eos.providers.providers.CliProvider.edit_config" - ) - self.edit_config = self.mock_edit_config.start() - - self.mock_execute_show_command = patch( - "ansible_collections.arista.eos.plugins.module_utils.network.eos.facts.l2_interfaces.l2_interfaces.L2_interfacesFacts.get_device_data" - ) - self.execute_show_command = self.mock_execute_show_command.start() - - -The facts file of the module now includes a new method, ``get_device_data``. Call ``get_device_data`` here to emulate the device output. - - -Mocking device data ------------------------ - -To mock fetching results from devices or provide other complex data structures that -come from external libraries, you can use ``fixtures`` to read in pre-generated data. The text files for this pre-generated data live in ``test/units/modules/network/PLATFORM/fixtures/``. See for example the `eos_l2_interfaces.cfg file `_. - -Load data using the ``load_fixture`` method and set this data as the return value of the -``get_device_data`` method in the facts file: - -.. code-block:: python - - def load_fixtures(self, commands=None, transport='cli'): - def load_from_file(*args, **kwargs): - return load_fixture('eos_l2_interfaces_config.cfg') - self.execute_show_command.side_effect = load_from_file - -See the unit test file `test_eos_l2_interfaces `_ -for a practical example. - - -.. seealso:: - - :ref:`testing_units` - Deep dive into developing unit tests for Ansible modules - :ref:`testing_running_locally` - Running tests locally including gathering and reporting coverage data - :ref:`developing_modules_general` - Get started developing a module diff --git a/docs/docsite/rst/network/dev_guide/documenting_modules_network.rst b/docs/docsite/rst/network/dev_guide/documenting_modules_network.rst deleted file mode 100644 index 99ba7a95e50..00000000000 --- a/docs/docsite/rst/network/dev_guide/documenting_modules_network.rst +++ /dev/null @@ -1,52 +0,0 @@ - -.. _documenting_modules_network: - -********************************* -Documenting new network platforms -********************************* - -.. contents:: - :local: - -When you create network modules for a new platform, or modify the connections provided by an existing network platform (such as ``network_cli`` and ``httpapi``), you also need to update the :ref:`settings_by_platform` table and add or modify the Platform Options file for your platform. - -You should already have documented each module as described in :ref:`developing_modules_documenting`. - -Modifying the platform options table -==================================== - -The :ref:`settings_by_platform` table is a convenient summary of the connections options provided by each network platform that has modules in Ansible. Add a row for your platform to this table, in alphabetical order. For example: - -.. code-block:: text - - +-------------------+-------------------------+-------------+---------+---------+----------+ - | My OS | ``myos`` | ✓ | ✓ | | ✓ | - -Ensure that the table stays formatted correctly. That is: - -* Each row is inserted in alphabetical order. -* The cell division ``|`` markers line up with the ``+`` markers. -* The check marks appear only for the connection types provided by the network modules. - - - -Adding a platform-specific options section -========================================== - -The platform- specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules. Name your new file ``platform_.rst`` (for example, ``platform_myos.rst``). The platform name should match the module prefix. See `platform_eos.rst `_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section. - -Your platform-specific section should include the following: - -* **Connections available table** - a deeper dive into each connection type, including details on credentials, indirect access, connections settings, and enable mode. -* **How to use each connection type** - with working examples of each connection type. - -If your network platform supports SSH connections, also include the following at the bottom of your ``.rst`` file: - -.. code-block:: text - - .. include:: shared_snippets/SSH_warning.txt - -Adding your new file to the table of contents -============================================= - -As a final step, add your new file in alphabetical order in the ``platform_index.rst`` file. You should then build the documentation to verify your additions. See :ref:`community_documentation_contributions` for more details. diff --git a/docs/docsite/rst/network/dev_guide/index.rst b/docs/docsite/rst/network/dev_guide/index.rst deleted file mode 100644 index 5f0e7924ec0..00000000000 --- a/docs/docsite/rst/network/dev_guide/index.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _network_developer_guide: - -********************************** -Network Developer Guide -********************************** - -Welcome to the Developer Guide for Ansible Network Automation! - -**Who should use this guide?** - -If you want to extend Ansible for Network Automation by creating a module or plugin, this guide is for you. This guide is specific to networking. You should already be familiar with how to create, test, and document modules and plugins, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository. See the :ref:`developer_guide` for details. Before you proceed, please read: - -* How to :ref:`add a custom plugin or module locally `. -* How to figure out if :ref:`developing a module is the right approach ` for my use case. -* How to :ref:`set up my Python development environment `. -* How to :ref:`get started writing a module `. - - -Find the network developer task that best describes what you want to do: - - * I want to :ref:`develop a network resource module `. - * I want to :ref:`develop a network connection plugin `. - * I want to :ref:`document my set of modules for a network platform `. - -If you prefer to read the entire guide, here's a list of the pages in order. - -.. toctree:: - :maxdepth: 1 - - developing_resource_modules_network - developing_plugins_network - documenting_modules_network diff --git a/docs/docsite/rst/network/getting_started/basic_concepts.rst b/docs/docsite/rst/network/getting_started/basic_concepts.rst deleted file mode 100644 index 980b144d35b..00000000000 --- a/docs/docsite/rst/network/getting_started/basic_concepts.rst +++ /dev/null @@ -1,10 +0,0 @@ -************** -Basic Concepts -************** - -These concepts are common to all uses of Ansible, including network automation. You need to understand them to use Ansible for network automation. This basic introduction provides the background you need to follow the examples in this guide. - -.. contents:: - :local: - -.. include:: ../../shared_snippets/basic_concepts.txt diff --git a/docs/docsite/rst/network/getting_started/first_inventory.rst b/docs/docsite/rst/network/getting_started/first_inventory.rst deleted file mode 100644 index 1562ed42c65..00000000000 --- a/docs/docsite/rst/network/getting_started/first_inventory.rst +++ /dev/null @@ -1,431 +0,0 @@ -*********************************************** -Build Your Inventory -*********************************************** - -Running a playbook without an inventory requires several command-line flags. Also, running a playbook against a single device is not a huge efficiency gain over making the same change manually. The next step to harnessing the full power of Ansible is to use an inventory file to organize your managed nodes into groups with information like the ``ansible_network_os`` and the SSH user. A fully-featured inventory file can serve as the source of truth for your network. Using an inventory file, a single playbook can maintain hundreds of network devices with a single command. This page shows you how to build an inventory file, step by step. - -.. contents:: - :local: - -Basic inventory -================================================== - -First, group your inventory logically. Best practice is to group servers and network devices by their What (application, stack or microservice), Where (datacenter or region), and When (development stage): - -- **What**: db, web, leaf, spine -- **Where**: east, west, floor_19, building_A -- **When**: dev, test, staging, prod - -Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in your group names. Group names are case sensitive. - -This tiny example data center illustrates a basic group structure. You can group groups using the syntax ``[metagroupname:children]`` and listing groups as members of the metagroup. Here, the group ``network`` includes all leafs and all spines; the group ``datacenter`` includes all network devices plus all webservers. - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - leaf02: - ansible_host: 10.16.10.12 - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - spine02: - ansible_host: 10.16.10.14 - - network: - children: - leafs: - spines: - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - webserver02: - ansible_host: 10.16.10.16 - - datacenter: - children: - network: - webservers: - - - -You can also create this same inventory in INI format. - -.. code-block:: ini - - [leafs] - leaf01 - leaf02 - - [spines] - spine01 - spine02 - - [network:children] - leafs - spines - - [webservers] - webserver01 - webserver02 - - [datacenter:children] - network - webservers - - -Add variables to the inventory -================================================================================ - -Next, you can set values for many of the variables you needed in your first Ansible command in the inventory, so you can skip them in the ``ansible-playbook`` command. In this example, the inventory includes each network device's IP, OS, and SSH user. If your network devices are only accessible by IP, you must add the IP to the inventory file. If you access your network devices using hostnames, the IP is not necessary. - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - leaf02: - ansible_host: 10.16.10.12 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - spine02: - ansible_host: 10.16.10.14 - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - network: - children: - leafs: - spines: - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - ansible_user: my_server_user - webserver02: - ansible_host: 10.16.10.16 - ansible_user: my_server_user - - datacenter: - children: - network: - webservers: - - -Group variables within inventory -================================================================================ - -When devices in a group share the same variable values, such as OS or SSH user, you can reduce duplication and simplify maintenance by consolidating these into group variables: - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - leaf02: - ansible_host: 10.16.10.12 - vars: - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - spine02: - ansible_host: 10.16.10.14 - vars: - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - network: - children: - leafs: - spines: - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - webserver02: - ansible_host: 10.16.10.16 - vars: - ansible_user: my_server_user - - datacenter: - children: - network: - webservers: - -Variable syntax -================================================================================ - -The syntax for variable values is different in inventory, in playbooks, and in the ``group_vars`` files, which are covered below. Even though playbook and ``group_vars`` files are both written in YAML, you use variables differently in each. - -- In an ini-style inventory file you **must** use the syntax ``key=value`` for variable values: ``ansible_network_os=vyos.vyos.vyos``. -- In any file with the ``.yml`` or ``.yaml`` extension, including playbooks and ``group_vars`` files, you **must** use YAML syntax: ``key: value``. - -- In ``group_vars`` files, use the full ``key`` name: ``ansible_network_os: vyos.vyos.vyos``. -- In playbooks, use the short-form ``key`` name, which drops the ``ansible`` prefix: ``network_os: vyos.vyos.vyos``. - - -Group inventory by platform -================================================================================ - -As your inventory grows, you may want to group devices by platform. This allows you to specify platform-specific variables easily for all devices on that platform: - -.. code-block:: yaml - - --- - - leafs: - hosts: - leaf01: - ansible_host: 10.16.10.11 - leaf02: - ansible_host: 10.16.10.12 - - spines: - hosts: - spine01: - ansible_host: 10.16.10.13 - spine02: - ansible_host: 10.16.10.14 - - network: - children: - leafs: - spines: - vars: - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - - webservers: - hosts: - webserver01: - ansible_host: 10.16.10.15 - webserver02: - ansible_host: 10.16.10.16 - vars: - ansible_user: my_server_user - - datacenter: - children: - network: - webservers: - -With this setup, you can run ``first_playbook.yml`` with only two flags: - -.. code-block:: console - - ansible-playbook -i inventory.yml -k first_playbook.yml - -With the ``-k`` flag, you provide the SSH password(s) at the prompt. Alternatively, you can store SSH and other secrets and passwords securely in your group_vars files with ``ansible-vault``. See :ref:`network_vault` for details. - -Verifying the inventory -========================= - -You can use the :ref:`ansible-inventory` CLI command to display the inventory as Ansible sees it. - -.. code-block:: console - - $ ansible-inventory -i test.yml --list - { - "_meta": { - "hostvars": { - "leaf01": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.11", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "leaf02": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.12", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "spine01": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.13", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "spine02": { - "ansible_connection": "ansible.netcommon.network_cli", - "ansible_host": "10.16.10.14", - "ansible_network_os": "vyos.vyos.vyos", - "ansible_user": "my_vyos_user" - }, - "webserver01": { - "ansible_host": "10.16.10.15", - "ansible_user": "my_server_user" - }, - "webserver02": { - "ansible_host": "10.16.10.16", - "ansible_user": "my_server_user" - } - } - }, - "all": { - "children": [ - "datacenter", - "ungrouped" - ] - }, - "datacenter": { - "children": [ - "network", - "webservers" - ] - }, - "leafs": { - "hosts": [ - "leaf01", - "leaf02" - ] - }, - "network": { - "children": [ - "leafs", - "spines" - ] - }, - "spines": { - "hosts": [ - "spine01", - "spine02" - ] - }, - "webservers": { - "hosts": [ - "webserver01", - "webserver02" - ] - } - } - -.. _network_vault: - -Protecting sensitive variables with ``ansible-vault`` -================================================================================ - -The ``ansible-vault`` command provides encryption for files and/or individual variables like passwords. This tutorial will show you how to encrypt a single SSH password. You can use the commands below to encrypt other sensitive information, such as database passwords, privilege-escalation passwords and more. - -First you must create a password for ansible-vault itself. It is used as the encryption key, and with this you can encrypt dozens of different passwords across your Ansible project. You can access all those secrets (encrypted values) with a single password (the ansible-vault password) when you run your playbooks. Here's a simple example. - -1. Create a file and write your password for ansible-vault to it: - -.. code-block:: console - - echo "my-ansible-vault-pw" > ~/my-ansible-vault-pw-file - -2. Create the encrypted ssh password for your VyOS network devices, pulling your ansible-vault password from the file you just created: - -.. code-block:: console - - ansible-vault encrypt_string --vault-id my_user@~/my-ansible-vault-pw-file 'VyOS_SSH_password' --name 'ansible_password' - -If you prefer to type your ansible-vault password rather than store it in a file, you can request a prompt: - -.. code-block:: console - - ansible-vault encrypt_string --vault-id my_user@prompt 'VyOS_SSH_password' --name 'ansible_password' - -and type in the vault password for ``my_user``. - -The :option:`--vault-id ` flag allows different vault passwords for different users or different levels of access. The output includes the user name ``my_user`` from your ``ansible-vault`` command and uses the YAML syntax ``key: value``: - -.. code-block:: yaml - - ansible_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;my_user - 66386134653765386232383236303063623663343437643766386435663632343266393064373933 - 3661666132363339303639353538316662616638356631650a316338316663666439383138353032 - 63393934343937373637306162366265383461316334383132626462656463363630613832313562 - 3837646266663835640a313164343535316666653031353763613037656362613535633538386539 - 65656439626166666363323435613131643066353762333232326232323565376635 - Encryption successful - -This is an example using an extract from a YAML inventory, as the INI format does not support inline vaults: - -.. code-block:: yaml - - ... - - vyos: # this is a group in yaml inventory, but you can also do under a host - vars: - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - ansible_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;my_user - 66386134653765386232383236303063623663343437643766386435663632343266393064373933 - 3661666132363339303639353538316662616638356631650a316338316663666439383138353032 - 63393934343937373637306162366265383461316334383132626462656463363630613832313562 - 3837646266663835640a313164343535316666653031353763613037656362613535633538386539 - 65656439626166666363323435613131643066353762333232326232323565376635 - - ... - -To use an inline vaulted variables with an INI inventory you need to store it in a 'vars' file in YAML format, -it can reside in host_vars/ or group_vars/ to be automatically picked up or referenced from a play through ``vars_files`` or ``include_vars``. - -To run a playbook with this setup, drop the ``-k`` flag and add a flag for your ``vault-id``: - -.. code-block:: console - - ansible-playbook -i inventory --vault-id my_user@~/my-ansible-vault-pw-file first_playbook.yml - -Or with a prompt instead of the vault password file: - -.. code-block:: console - - ansible-playbook -i inventory --vault-id my_user@prompt first_playbook.yml - -To see the original value, you can use the debug module. Please note if your YAML file defines the `ansible_connection` variable (as we used in our example), it will take effect when you execute the command below. To prevent this, please make a copy of the file without the ansible_connection variable. - -.. code-block:: console - - cat vyos.yml | grep -v ansible_connection >> vyos_no_connection.yml - - ansible localhost -m debug -a var="ansible_password" -e "@vyos_no_connection.yml" --ask-vault-pass - Vault password: - - localhost | SUCCESS => { - "ansible_password": "VyOS_SSH_password" - } - - -.. warning:: - - Vault content can only be decrypted with the password that was used to encrypt it. If you want to stop using one password and move to a new one, you can update and re-encrypt existing vault content with ``ansible-vault rekey myfile``, then provide the old password and the new password. Copies of vault content still encrypted with the old password can still be decrypted with old password. - -For more details on building inventory files, see :ref:`the introduction to inventory`; for more details on ansible-vault, see :ref:`the full Ansible Vault documentation`. - -Now that you understand the basics of commands, playbooks, and inventory, it's time to explore some more complex Ansible Network examples. diff --git a/docs/docsite/rst/network/getting_started/first_playbook.rst b/docs/docsite/rst/network/getting_started/first_playbook.rst deleted file mode 100644 index 15a4ed16f51..00000000000 --- a/docs/docsite/rst/network/getting_started/first_playbook.rst +++ /dev/null @@ -1,212 +0,0 @@ - -.. _first_network_playbook: - -*************************************************** -Run Your First Command and Playbook -*************************************************** - -Put the concepts you learned to work with this quick tutorial. Install Ansible, execute a network configuration command manually, execute the same command with Ansible, then create a playbook so you can execute the command any time on multiple network devices. - -.. contents:: - :local: - -Prerequisites -================================================== - -Before you work through this tutorial you need: - -- Ansible 2.10 (or higher) installed -- One or more network devices that are compatible with Ansible -- Basic Linux command line knowledge -- Basic knowledge of network switch & router configuration - -Install Ansible -================================================== - -Install Ansible using your preferred method. See :ref:`installation_guide`. Then return to this tutorial. - -Confirm the version of Ansible (must be >= 2.10): - -.. code-block:: bash - - ansible --version - - -Establish a manual connection to a managed node -================================================== - -To confirm your credentials, connect to a network device manually and retrieve its configuration. Replace the sample user and device name with your real credentials. For example, for a VyOS router: - -.. code-block:: bash - - ssh my_vyos_user@vyos.example.net - show config - exit - -This manual connection also establishes the authenticity of the network device, adding its RSA key fingerprint to your list of known hosts. (If you have connected to the device before, you have already established its authenticity.) - - -Run your first network Ansible command -================================================== - -Instead of manually connecting and running a command on the network device, you can retrieve its configuration with a single, stripped-down Ansible command: - -.. code-block:: bash - - ansible all -i vyos.example.net, -c ansible.netcommon.network_cli -u my_vyos_user -k -m vyos.vyos.vyos_facts -e ansible_network_os=vyos.vyos.vyos - -The flags in this command set seven values: - - the host group(s) to which the command should apply (in this case, all) - - the inventory (-i, the device or devices to target - without the trailing comma -i points to an inventory file) - - the connection method (-c, the method for connecting and executing ansible) - - the user (-u, the username for the SSH connection) - - the SSH connection method (-k, please prompt for the password) - - the module (-m, the Ansible module to run, using the fully qualified collection name (FQCN)) - - an extra variable ( -e, in this case, setting the network OS value) - -NOTE: If you use ``ssh-agent`` with ssh keys, Ansible loads them automatically. You can omit ``-k`` flag. - -.. note:: - - If you are running Ansible in a virtual environment, you will also need to add the variable ``ansible_python_interpreter=/path/to/venv/bin/python`` - - -Create and run your first network Ansible Playbook -================================================== - -If you want to run this command every day, you can save it in a playbook and run it with ``ansible-playbook`` instead of ``ansible``. The playbook can store a lot of the parameters you provided with flags at the command line, leaving less to type at the command line. You need two files for this - a playbook and an inventory file. - -1. Download :download:`first_playbook.yml `, which looks like this: - -.. literalinclude:: sample_files/first_playbook.yml - :language: YAML - -The playbook sets three of the seven values from the command line above: the group (``hosts: all``), the connection method (``connection: ansible.netcommon.network_cli``) and the module (in each task). With those values set in the playbook, you can omit them on the command line. The playbook also adds a second task to show the config output. When a module runs in a playbook, the output is held in memory for use by future tasks instead of written to the console. The debug task here lets you see the results in your shell. - -2. Run the playbook with the command: - -.. code-block:: bash - - ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook.yml - -The playbook contains one play with two tasks, and should generate output like this: - -.. code-block:: shell - - $ ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook.yml - - PLAY [Network Getting Started First Playbook] - *************************************************************************************************************************** - - TASK [Get config for VyOS devices] - *************************************************************************************************************************** - ok: [vyos.example.net] - - TASK [Display the config] - *************************************************************************************************************************** - ok: [vyos.example.net] => { - "msg": "The hostname is vyos and the OS is VyOS 1.1.8" - } - -3. Now that you can retrieve the device config, try updating it with Ansible. Download :download:`first_playbook_ext.yml `, which is an extended version of the first playbook: - -.. literalinclude:: sample_files/first_playbook_ext.yml - :language: YAML - -The extended first playbook has five tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config: - -.. code-block:: shell - - $ ansible-playbook -i vyos.example.net, -u ansible -k -e ansible_network_os=vyos.vyos.vyos first_playbook_ext.yml - - PLAY [Network Getting Started First Playbook Extended] - ************************************************************************************************************************************ - - TASK [Get config for VyOS devices] - ********************************************************************************************************************************** - ok: [vyos.example.net] - - TASK [Display the config] - ************************************************************************************************************************************* - ok: [vyos.example.net] => { - "msg": "The hostname is vyos and the OS is VyOS 1.1.8" - } - - TASK [Update the hostname] - ************************************************************************************************************************************* - changed: [vyos.example.net] - - TASK [Get changed config for VyOS devices] - ************************************************************************************************************************************* - ok: [vyos.example.net] - - TASK [Display the changed config] - ************************************************************************************************************************************* - ok: [vyos.example.net] => { - "msg": "The new hostname is vyos-changed and the OS is VyOS 1.1.8" - } - - PLAY RECAP - ************************************************************************************************************************************ - vyos.example.net : ok=5 changed=1 unreachable=0 failed=0 - - - -.. _network_gather_facts: - -Gathering facts from network devices -==================================== - -The ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. - -You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`arista.eos.eos_facts `) to return just a subset of the device configuration, as shown below. - -.. code-block:: yaml - - - hosts: arista - gather_facts: True - gather_subset: interfaces - module_defaults: - arista.eos.eos_facts: - gather_network_resources: interfaces - -The playbook returns the following interface facts: - -.. code-block:: yaml - - "network_resources": { - "interfaces": [ - { - "description": "test-interface", - "enabled": true, - "mtu": "512", - "name": "Ethernet1" - }, - { - "enabled": true, - "mtu": "3000", - "name": "Ethernet2" - }, - { - "enabled": true, - "name": "Ethernet3" - }, - { - "enabled": true, - "name": "Ethernet4" - }, - { - "enabled": true, - "name": "Ethernet5" - }, - { - "enabled": true, - "name": "Ethernet6" - }, - ] - } - - -Note that this returns a subset of what is returned by just setting ``gather_subset: interfaces``. - -You can store these facts and use them directly in another task, such as with the :ref:`eos_interfaces ` resource module. diff --git a/docs/docsite/rst/network/getting_started/index.rst b/docs/docsite/rst/network/getting_started/index.rst deleted file mode 100644 index bf9f2eb01b7..00000000000 --- a/docs/docsite/rst/network/getting_started/index.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. _network_getting_started: - -********************************** -Network Getting Started -********************************** - -Ansible collections support a wide range of vendors, device types, and actions, so you can manage your entire network with a single automation tool. With Ansible, you can: - -- Automate repetitive tasks to speed routine network changes and free up your time for more strategic work -- Leverage the same simple, powerful, and agentless automation tool for network tasks that operations and development use -- Separate the data model (in a playbook or role) from the execution layer (through Ansible modules) to manage heterogeneous network devices -- Benefit from community and vendor-generated sample playbooks and roles to help accelerate network automation projects -- Communicate securely with network hardware over SSH or HTTPS - -**Who should use this guide?** - -This guide is intended for network engineers using Ansible for the first time. If you understand networks but have never used Ansible, work through the guide from start to finish. - -This guide is also useful for experienced Ansible users automating network tasks for the first time. You can use Ansible commands, playbooks and modules to configure hubs, switches, routers, bridges and other network devices. But network modules are different from Linux/Unix and Windows modules, and you must understand some network-specific concepts to succeed. If you understand Ansible but have never automated a network task, start with the second section. - -This guide introduces basic Ansible concepts and guides you through your first Ansible commands, playbooks and inventory entries. - -.. toctree:: - :maxdepth: 2 - :caption: Getting Started Guide - - basic_concepts - network_differences - first_playbook - first_inventory - network_roles - intermediate_concepts - network_connection_options - network_resources diff --git a/docs/docsite/rst/network/getting_started/intermediate_concepts.rst b/docs/docsite/rst/network/getting_started/intermediate_concepts.rst deleted file mode 100644 index 3496f22ecb1..00000000000 --- a/docs/docsite/rst/network/getting_started/intermediate_concepts.rst +++ /dev/null @@ -1,39 +0,0 @@ -***************** -Beyond the basics -***************** - -This page introduces some concepts that help you manage your Ansible workflow with directory structure and source control. Like the Basic Concepts at the beginning of this guide, these intermediate concepts are common to all uses of Ansible. - -.. contents:: - :local: - - -A typical Ansible filetree -========================== - -Ansible expects to find certain files in certain places. As you expand your inventory and create and run more network playbooks, keep your files organized in your working Ansible project directory like this: - -.. code-block:: console - - . - ├── backup - │   ├── vyos.example.net_config.2018-02-08@11:10:15 - │   ├── vyos.example.net_config.2018-02-12@08:22:41 - ├── first_playbook.yml - ├── inventory - ├── group_vars - │   ├── vyos.yml - │   └── eos.yml - ├── roles - │   ├── static_route - │   └── system - ├── second_playbook.yml - └── third_playbook.yml - -The ``backup`` directory and the files in it get created when you run modules like ``vyos_config`` with the ``backup: yes`` parameter. - - -Tracking changes to inventory and playbooks: source control with git -==================================================================== - -As you expand your inventory, roles and playbooks, you should place your Ansible projects under source control. We recommend ``git`` for source control. ``git`` provides an audit trail, letting you track changes, roll back mistakes, view history and share the workload of managing, maintaining and expanding your Ansible ecosystem. There are plenty of tutorials and guides to using ``git`` available. diff --git a/docs/docsite/rst/network/getting_started/network_connection_options.rst b/docs/docsite/rst/network/getting_started/network_connection_options.rst deleted file mode 100644 index bdfb93cb97b..00000000000 --- a/docs/docsite/rst/network/getting_started/network_connection_options.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _network_connection_options: - -*************************************** -Working with network connection options -*************************************** - -Network modules can support multiple connection protocols, such as ``ansible.netcommon.network_cli``, ``ansible.netcommon.netconf``, and ``ansible.netcommon.httpapi``. These connections include some common options you can set to control how the connection to your network device behaves. - -Common options are: - -* ``become`` and ``become_method`` as described in :ref:`privilege_escalation`. -* ``network_os`` - set to match your network platform you are communicating with. See the :ref:`platform-specific ` pages. -* ``remote_user`` as described in :ref:`connection_set_user`. -* Timeout options - ``persistent_command_timeout``, ``persistent_connect_timeout``, and ``timeout``. - -.. _timeout_options: - -Setting timeout options -======================= - -When communicating with a remote device, you have control over how long Ansible maintains the connection to that device, as well as how long Ansible waits for a command to complete on that device. Each of these options can be set as variables in your playbook files, environment variables, or settings in your :ref:`ansible.cfg file `. - -For example, the three options for controlling the connection timeout are as follows. - -Using vars (per task): - -.. code-block:: yaml - - - name: save running-config - cisco.ios.ios_command: - commands: copy running-config startup-config - vars: - ansible_command_timeout: 30 - -Using the environment variable: - -.. code-block:: bash - - $export ANSIBLE_PERSISTENT_COMMAND_TIMEOUT=30 - -Using the global configuration (in :file:`ansible.cfg`) - -.. code-block:: ini - - [persistent_connection] - command_timeout = 30 - -See :ref:`ansible_variable_precedence` for details on the relative precedence of each of these variables. See the individual connection type to understand each option. diff --git a/docs/docsite/rst/network/getting_started/network_differences.rst b/docs/docsite/rst/network/getting_started/network_differences.rst deleted file mode 100644 index 2ae583f18e0..00000000000 --- a/docs/docsite/rst/network/getting_started/network_differences.rst +++ /dev/null @@ -1,68 +0,0 @@ -************************************************************ -How Network Automation is Different -************************************************************ - -Network automation uses the basic Ansible concepts, but there are important differences in how the network modules work. This introduction prepares you to understand the exercises in this guide. - -.. contents:: - :local: - -Execution on the control node -================================================================================ - -Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs. - -Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory. - -Multiple communication protocols -================================================================================ - -Because network modules execute on the control node instead of on the managed nodes, they can support multiple communication protocols. The communication protocol (XML over SSH, CLI over SSH, API over HTTPS) selected for each network module depends on the platform and the purpose of the module. Some network modules support only one protocol; some offer a choice. The most common protocol is CLI over SSH. You set the communication protocol with the ``ansible_connection`` variable: - -.. csv-table:: - :header: "Value of ansible_connection", "Protocol", "Requires", "Persistent?" - :widths: 30, 10, 10, 10 - - "ansible.netcommon.network_cli", "CLI over SSH", "network_os setting", "yes" - "ansible.netcommon.netconf", "XML over SSH", "network_os setting", "yes" - "ansible.netcommon.httpapi", "API over HTTP/HTTPS", "network_os setting", "yes" - "local", "depends on provider", "provider setting", "no" - -.. note:: - ``ansible.netcommon.httpapi`` deprecates ``eos_eapi`` and ``nxos_nxapi``. See :ref:`httpapi_plugins` for details and an example. - -The ``ansible_connection: local`` has been deprecated. Please use one of the persistent connection types listed above instead. With persistent connections, you can define the hosts and credentials only once, rather than in every task. You also need to set the ``network_os`` variable for the specific network platform you are communicating with. For more details on using each connection type on various platforms, see the :ref:`platform-specific ` pages. - - -Collections organized by network platform -================================================================================ - -A network platform is a set of network devices with a common operating system that can be managed by an Ansible collection, for example: - -- Arista: `arista.eos `_ -- Cisco: `cisco.ios `_, `cisco.iosxr `_, `cisco.nxos `_ -- Juniper: `junipernetworks.junos `_ -- VyOS `vyos.vyos `_ - -All modules within a network platform share certain requirements. Some network platforms have specific differences - see the :ref:`platform-specific ` documentation for details. - -.. _privilege_escalation: - -Privilege Escalation: ``enable`` mode, ``become``, and ``authorize`` -================================================================================ - -Several network platforms support privilege escalation, where certain tasks must be done by a privileged user. On network devices this is called the ``enable`` mode (the equivalent of ``sudo`` in \*nix administration). Ansible network modules offer privilege escalation for those network devices that support it. For details of which platforms support ``enable`` mode, with examples of how to use it, see the :ref:`platform-specific ` documentation. - -Using ``become`` for privilege escalation ------------------------------------------ - -Use the top-level Ansible parameter ``become: yes`` with ``become_method: enable`` to run a task, play, or playbook with escalated privileges on any network platform that supports privilege escalation. You must use either ``connection: network_cli`` or ``connection: httpapi`` with ``become: yes`` with ``become_method: enable``. If you are using ``network_cli`` to connect Ansible to your network devices, a ``group_vars`` file would look like: - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: cisco.ios.ios - ansible_become: yes - ansible_become_method: enable - -For more information, see :ref:`Become and Networks` diff --git a/docs/docsite/rst/network/getting_started/network_resources.rst b/docs/docsite/rst/network/getting_started/network_resources.rst deleted file mode 100644 index a69aba905d7..00000000000 --- a/docs/docsite/rst/network/getting_started/network_resources.rst +++ /dev/null @@ -1,47 +0,0 @@ - -.. _network_resources: - -************************ -Resources and next steps -************************ - -.. contents:: - :local: - -Documents -========= - -Read more about Ansible for Network Automation: - -- :ref:`Network Platform Options ` -- Network Automation on the `Ansible website `_ -- Ansible Network `Blog posts `_ - -Events (on video and in person) -=============================== - -All sessions at Ansible events are recorded and include many Network-related topics (use Filter by Category to view only Network topics). You can also join us for future events in your area. See: - -- `Recorded AnsibleFests `_ -- `Recorded AnsibleAutomates `_ -- `Upcoming Ansible Events `_ page. - -GitHub repos -============ - -Ansible hosts module code, examples, demonstrations, and other content on GitHub. Anyone with a GitHub account is able to create Pull Requests (PRs) or issues on these repos: - -- `Network-Automation `_ is an open community for all things network automation. Have an idea, some playbooks, or roles to share? Email ansible-network@redhat.com and we will add you as a contributor to the repository. - -- `Ansible collections `_ is the main repository for Ansible-maintained and community collections, including collections for network devices. - - - -Chat channels -============= - -Got questions? Chat with us on: - -* the ``#ansible-network`` channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) - -* `Ansible Network Slack `_ - Network & Security Automation Slack community. Check out the #devel channel for discussions on module and plugin development. diff --git a/docs/docsite/rst/network/getting_started/network_roles.rst b/docs/docsite/rst/network/getting_started/network_roles.rst deleted file mode 100644 index 4ffb833026f..00000000000 --- a/docs/docsite/rst/network/getting_started/network_roles.rst +++ /dev/null @@ -1,267 +0,0 @@ - -.. _using_network_roles: - -************************* -Use Ansible network roles -************************* - -Roles are sets of Ansible defaults, files, tasks, templates, variables, and other Ansible components that work together. As you saw on :ref:`first_network_playbook`, moving from a command to a playbook makes it easy to run multiple tasks and repeat the same tasks in the same order. Moving from a playbook to a role makes it even easier to reuse and share your ordered tasks. You can look at :ref:`Ansible Galaxy `, which lets you share your roles and use others' roles, either directly or as inspiration. - -.. contents:: - :local: - -Understanding roles -=================== - -So what exactly is a role, and why should you care? Ansible roles are basically playbooks broken up into a known file structure. Moving to roles from a playbook makes sharing, reading, and updating your Ansible workflow easier. Users can write their own roles. So for example, you don't have to write your own DNS playbook. Instead, you specify a DNS server and a role to configure it for you. - -To simplify your workflow even further, the Ansible Network team has written a series of roles for common network use cases. Using these roles means you don't have to reinvent the wheel. Instead of writing and maintaining your own ``create_vlan`` playbooks or roles, you can concentrate on designing, codifying and maintaining the parser templates that describe your network topologies and inventory, and let Ansible's network roles do the work. See the `network-related roles `_ on Ansible Galaxy. - -A sample DNS playbook ---------------------- - -To demonstrate the concept of what a role is, the example ``playbook.yml`` below is a single YAML file containing a two-task playbook. This Ansible Playbook configures the hostname on a Cisco IOS XE device, then it configures the DNS (domain name system) servers. - -.. code-block:: yaml - - --- - - name: configure cisco routers - hosts: routers - connection: ansible.netcommon.network_cli - gather_facts: no - vars: - dns: "8.8.8.8 8.8.4.4" - - tasks: - - name: configure hostname - cisco.ios.ios_config: - lines: hostname {{ inventory_hostname }} - - - name: configure DNS - cisco.ios.ios_config: - lines: ip name-server {{dns}} - -If you run this playbook using the ``ansible-playbook`` command, you'll see the output below. This example used ``-l`` option to limit the playbook to only executing on the **rtr1** node. - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -l rtr1 - - PLAY [configure cisco routers] ************************************************* - - TASK [configure hostname] ****************************************************** - changed: [rtr1] - - TASK [configure DNS] *********************************************************** - changed: [rtr1] - - PLAY RECAP ********************************************************************* - rtr1 : ok=2 changed=2 unreachable=0 failed=0 - - -This playbook configured the hostname and DNS servers. You can verify that configuration on the Cisco IOS XE **rtr1** router: - -.. code-block:: bash - - rtr1#sh run | i name - hostname rtr1 - ip name-server 8.8.8.8 8.8.4.4 - -Convert the playbook into a role ---------------------------------- - -The next step is to convert this playbook into a reusable role. You can create the directory structure manually, or you can use ``ansible-galaxy init`` to create the standard framework for a role. - -.. code-block:: bash - - [user@ansible ~]$ ansible-galaxy init system-demo - [user@ansible ~]$ cd system-demo/ - [user@ansible system-demo]$ tree - . - ├── defaults - │ └── main.yml - ├── files - ├── handlers - │ └── main.yml - ├── meta - │ └── main.yml - ├── README.md - ├── tasks - │ └── main.yml - ├── templates - ├── tests - │ ├── inventory - │ └── test.yml - └── vars - └── main.yml - -This first demonstration uses only the **tasks** and **vars** directories. The directory structure would look as follows: - -.. code-block:: bash - - [user@ansible system-demo]$ tree - . - ├── tasks - │ └── main.yml - └── vars - └── main.yml - -Next, move the content of the ``vars`` and ``tasks`` sections from the original Ansible Playbook into the role. First, move the two tasks into the ``tasks/main.yml`` file: - -.. code-block:: bash - - [user@ansible system-demo]$ cat tasks/main.yml - --- - - name: configure hostname - cisco.ios.ios_config: - lines: hostname {{ inventory_hostname }} - - - name: configure DNS - cisco.ios.ios_config: - lines: ip name-server {{dns}} - -Next, move the variables into the ``vars/main.yml`` file: - -.. code-block:: bash - - [user@ansible system-demo]$ cat vars/main.yml - --- - dns: "8.8.8.8 8.8.4.4" - -Finally, modify the original Ansible Playbook to remove the ``tasks`` and ``vars`` sections and add the keyword ``roles`` with the name of the role, in this case ``system-demo``. You'll have this playbook: - -.. code-block:: yaml - - --- - - name: configure cisco routers - hosts: routers - connection: ansible.netcommon.network_cli - gather_facts: no - - roles: - - system-demo - -To summarize, this demonstration now has a total of three directories and three YAML files. There is the ``system-demo`` folder, which represents the role. This ``system-demo`` contains two folders, ``tasks`` and ``vars``. There is a ``main.yml`` is each respective folder. The ``vars/main.yml`` contains the variables from ``playbook.yml``. The ``tasks/main.yml`` contains the tasks from ``playbook.yml``. The ``playbook.yml`` file has been modified to call the role rather than specifying vars and tasks directly. Here is a tree of the current working directory: - -.. code-block:: bash - - [user@ansible ~]$ tree - . - ├── playbook.yml - └── system-demo - ├── tasks - │ └── main.yml - └── vars - └── main.yml - -Running the playbook results in identical behavior with slightly different output: - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -l rtr1 - - PLAY [configure cisco routers] ************************************************* - - TASK [system-demo : configure hostname] **************************************** - ok: [rtr1] - - TASK [system-demo : configure DNS] ********************************************* - ok: [rtr1] - - PLAY RECAP ********************************************************************* - rtr1 : ok=2 changed=0 unreachable=0 failed=0 - -As seen above each task is now prepended with the role name, in this case ``system-demo``. When running a playbook that contains several roles, this will help pinpoint where a task is being called from. This playbook returned ``ok`` instead of ``changed`` because it has identical behavior for the single file playbook we started from. - -As before, the playbook will generate the following configuration on a Cisco IOS-XE router: - -.. code-block:: bash - - rtr1#sh run | i name - hostname rtr1 - ip name-server 8.8.8.8 8.8.4.4 - - -This is why Ansible roles can be simply thought of as deconstructed playbooks. They are simple, effective and reusable. Now another user can simply include the ``system-demo`` role instead of having to create a custom "hard coded" playbook. - -Variable precedence -------------------- - -What if you want to change the DNS servers? You aren't expected to change the ``vars/main.yml`` within the role structure. Ansible has many places where you can specify variables for a given play. See :ref:`playbooks_variables` for details on variables and precedence. There are actually 21 places to put variables. While this list can seem overwhelming at first glance, the vast majority of use cases only involve knowing the spot for variables of least precedence and how to pass variables with most precedence. See :ref:`ansible_variable_precedence` for more guidance on where you should put variables. - -Lowest precedence -^^^^^^^^^^^^^^^^^ - -The lowest precedence is the ``defaults`` directory within a role. This means all the other 20 locations you could potentially specify the variable will all take higher precedence than ``defaults``, no matter what. To immediately give the vars from the ``system-demo`` role the least precedence, rename the ``vars`` directory to ``defaults``. - -.. code-block:: bash - - [user@ansible system-demo]$ mv vars defaults - [user@ansible system-demo]$ tree - . - ├── defaults - │ └── main.yml - ├── tasks - │ └── main.yml - -Add a new ``vars`` section to the playbook to override the default behavior (where the variable ``dns`` is set to 8.8.8.8 and 8.8.4.4). For this demonstration, set ``dns`` to 1.1.1.1, so ``playbook.yml`` becomes: - -.. code-block:: yaml - - --- - - name: configure cisco routers - hosts: routers - connection: ansible.netcommon.network_cli - gather_facts: no - vars: - dns: 1.1.1.1 - roles: - - system-demo - -Run this updated playbook on **rtr2**: - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -l rtr2 - -The configuration on the **rtr2** Cisco router will look as follows: - -.. code-block:: bash - - rtr2#sh run | i name-server - ip name-server 1.1.1.1 - -The variable configured in the playbook now has precedence over the ``defaults`` directory. In fact, any other spot you configure variables would win over the values in the ``defaults`` directory. - -Highest precedence -^^^^^^^^^^^^^^^^^^ - -Specifying variables in the ``defaults`` directory within a role will always take the lowest precedence, while specifying ``vars`` as extra vars with the ``-e`` or ``--extra-vars=`` will always take the highest precedence, no matter what. Re-running the playbook with the ``-e`` option overrides both the ``defaults`` directory (8.8.4.4 and 8.8.8.8) as well as the newly created ``vars`` within the playbook that contains the 1.1.1.1 dns server. - -.. code-block:: bash - - [user@ansible ~]$ ansible-playbook playbook.yml -e "dns=192.168.1.1" -l rtr3 - -The result on the Cisco IOS XE router will only contain the highest precedence setting of 192.168.1.1: - -.. code-block:: bash - - rtr3#sh run | i name-server - ip name-server 192.168.1.1 - -How is this useful? Why should you care? Extra vars are commonly used by network operators to override defaults. A powerful example of this is with the Job Template Survey feature on AWX or the :ref:`ansible_platform`. It is possible through the web UI to prompt a network operator to fill out parameters with a Web form. This can be really simple for non-technical playbook writers to execute a playbook using their Web browser. - - -Update an installed role ------------------------- - -The Ansible Galaxy page for a role lists all available versions. To update a locally installed role to a new or different version, use the ``ansible-galaxy install`` command with the version and ``--force`` option. You may also need to manually update any dependent roles to support this version. See the role **Read Me** tab in Galaxy for dependent role minimum version requirements. - -.. code-block:: bash - - [user@ansible]$ ansible-galaxy install mynamespace.my_role,v2.7.1 --force - -.. seealso:: - - `Ansible Galaxy documentation `_ - Ansible Galaxy user guide diff --git a/docs/docsite/rst/network/getting_started/sample_files/first_playbook.yml b/docs/docsite/rst/network/getting_started/sample_files/first_playbook.yml deleted file mode 100644 index 908b89f9ae3..00000000000 --- a/docs/docsite/rst/network/getting_started/sample_files/first_playbook.yml +++ /dev/null @@ -1,15 +0,0 @@ ---- - -- name: Network Getting Started First Playbook - connection: ansible.netcommon.network_cli - gather_facts: false - hosts: all - tasks: - - - name: Get config for VyOS devices - vyos.vyos.vyos_facts: - gather_subset: all - - - name: Display the config - debug: - msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" diff --git a/docs/docsite/rst/network/getting_started/sample_files/first_playbook_ext.yml b/docs/docsite/rst/network/getting_started/sample_files/first_playbook_ext.yml deleted file mode 100644 index 2d5f6a5f1f1..00000000000 --- a/docs/docsite/rst/network/getting_started/sample_files/first_playbook_ext.yml +++ /dev/null @@ -1,29 +0,0 @@ ---- - -- name: Network Getting Started First Playbook Extended - connection: ansible.netcommon.network_cli - gather_facts: false - hosts: all - tasks: - - - name: Get config for VyOS devices - vyos.vyos.vyos_facts: - gather_subset: all - - - name: Display the config - debug: - msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" - - - name: Update the hostname - vyos.vyos.vyos_config: - backup: yes - lines: - - set system host-name vyos-changed - - - name: Get changed config for VyOS devices - vyos.vyos.vyos_facts: - gather_subset: all - - - name: Display the changed config - debug: - msg: "The new hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" diff --git a/docs/docsite/rst/network/index.rst b/docs/docsite/rst/network/index.rst deleted file mode 100644 index 257563910c9..00000000000 --- a/docs/docsite/rst/network/index.rst +++ /dev/null @@ -1,20 +0,0 @@ -:orphan: - -.. _network_guide: - -****************************** -Ansible for Network Automation -****************************** - -Ansible Network modules extend the benefits of simple, powerful, agentless automation to network administrators and teams. Ansible Network modules can configure your network stack, test and validate existing network state, and discover and correct network configuration drift. - -If you're new to Ansible, or new to using Ansible for network management, start with :ref:`network_getting_started`. If you are already familiar with network automation with Ansible, see :ref:`network_advanced`. - -For documentation on using a particular network module, consult the :ref:`list of all network modules`. Network modules for various hardware are supported by different teams including the hardware vendors themselves, volunteers from the Ansible community, and the Ansible Network Team. - -.. toctree:: - :maxdepth: 3 - - getting_started/index - user_guide/index - dev_guide/index diff --git a/docs/docsite/rst/network/user_guide/cli_parsing.rst b/docs/docsite/rst/network/user_guide/cli_parsing.rst deleted file mode 100644 index 5b6b40ee1ea..00000000000 --- a/docs/docsite/rst/network/user_guide/cli_parsing.rst +++ /dev/null @@ -1,744 +0,0 @@ -.. _cli_parsing: - -***************************************** -Parsing semi-structured text with Ansible -***************************************** - -The :ref:`cli_parse ` module parses semi-structured data such as network configurations into structured data to allow programmatic use of the data from that device. You can pull information from a network device and update a CMDB in one playbook. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. - - -.. contents:: - :local: - - -Understanding the CLI parser -============================= - -The `ansible.utils `_ collection version 1.0.0 or later includes the :ref:`cli_parse ` module that can run CLI commands and parse the semi-structured text output. You can use the ``cli_parse`` module on a device, host, or platform that only supports a command-line interface and the commands issued return semi-structured text. The ``cli_parse`` module can either run a CLI command on a device and return a parsed result or can simply parse any text document. The ``cli_parse`` module includes cli_parser plugins to interface with a variety of parsing engines. - -Why parse the text? --------------------- - -Parsing semi-structured data such as network configurations into structured data allows programmatic use of the data from that device. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. You may prefer to do this with Ansible natively to take advantage of native Ansible constructs such as: - -- The ``when`` clause to conditionally run other tasks or roles -- The ``assert`` module to check configuration and operational state compliance -- The ``template`` module to generate reports about configuration and operational state information -- Templates and ``command`` or ``config`` modules to generate host, device, or platform commands or configuration -- The current platform ``facts`` modules to supplement native facts information - -By parsing semi-structured text into Ansible native data structures, you can take full advantage of Ansible's network modules and plugins. - - -When not to parse the text ---------------------------- - -You should not parse semi-structured text when: - -- The device, host, or platform has a RESTAPI and returns JSON. -- Existing Ansible facts modules already return the desired data. -- Ansible network resource modules exist for configuration management of the device and resource. - -Parsing the CLI -========================= - -The ``cli_parse`` module includes the following cli_parsing plugins: - -``native`` - The native parsing engine built into Ansible and requires no addition python libraries -``xml`` - Convert XML to an Ansible native data structure -``textfsm`` - A python module which implements a template based state machine for parsing semi-formatted text -``ntc_templates`` - Predefined ``textfsm`` templates packages supporting a variety of platforms and commands -``ttp`` - A library for semi-structured text parsing using templates, with added capabilities to simplify the process -``pyats`` - Uses the parsers included with the Cisco Test Automation & Validation Solution -``jc`` - A python module that converts the output of dozens of popular Linux/UNIX/macOS/Windows commands and file types to python dictionaries or lists of dictionaries. Note: this filter plugin can be found in the ``community.general`` collection. -``json`` - Converts JSON output at the CLI to an Ansible native data structure - -Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task. - -Because ``cli_parse`` uses a plugin based architecture, it can use additional parsing engines from any Ansible collection. - -.. note:: - - The ``ansible.netcommon.native`` and ``ansible.utils.json`` parsing engines are fully supported with a Red Hat Ansible Automation Platform subscription. Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates``, pyATS, ``textfsm``, ``xmltodict``, public APIs as documented. - -Parsing with the native parsing engine --------------------------------------- - -The native parsing engine is included with the ``cli_parse`` module. It uses data captured using regular expressions to populate the parsed data structure. The native parsing engine requires a YAML template file to parse the command output. - -Networking example -^^^^^^^^^^^^^^^^^^ - -This example uses the output of a network device command and applies a native template to produce an output in Ansible structured data format. - -The ``show interface`` command output from the network device looks as follows: - -.. code-block:: console - - Ethernet1/1 is up - admin state is up, Dedicated Interface - Hardware: 100/1000/10000 Ethernet, address: 5254.005a.f8bd (bia 5254.005a.f8bd) - MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec - reliability 255/255, txload 1/255, rxload 1/255 - Encapsulation ARPA, medium is broadcast - Port mode is access - full-duplex, auto-speed - Beacon is turned off - Auto-Negotiation is turned on FEC mode is Auto - Input flow-control is off, output flow-control is off - Auto-mdix is turned off - Switchport monitor is off - EtherType is 0x8100 - EEE (efficient-ethernet) : n/a - Last link flapped 4week(s) 6day(s) - Last clearing of "show interface" counters never - <...> - - -Create the native template to match this output and store it as ``templates/nxos_show_interface.yaml``: - -.. code-block:: yaml - - --- - - example: Ethernet1/1 is up - getval: '(?P\S+) is (?P\S+)' - result: - "{{ name }}": - name: "{{ name }}" - state: - operating: "{{ oper_state }}" - shared: true - - - example: admin state is up, Dedicated Interface - getval: 'admin state is (?P\S+),' - result: - "{{ name }}": - name: "{{ name }}" - state: - admin: "{{ admin_state }}" - - - example: " Hardware: Ethernet, address: 5254.005a.f8b5 (bia 5254.005a.f8b5)" - getval: '\s+Hardware: (?P.*), address: (?P\S+)' - result: - "{{ name }}": - hardware: "{{ hardware }}" - mac_address: "{{ mac }}" - - -This native parser template is structured as a list of parsers, each containing the following key-value pairs: - -- ``example`` - An example line of the text line to be parsed -- ``getval`` - A regular expression using named capture groups to store the extracted data -- ``result`` - A data tree, populated as a template, from the parsed data -- ``shared`` - (optional) The shared key makes the parsed values available to the rest of the parser entries until matched again. - -The following example task uses ``cli_parse`` with the native parser and the example template above to parse the ``show interface`` command from a Cisco NXOS device: - -.. code-block:: yaml - - - name: "Run command and parse with native" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.native - set_fact: interfaces - -Taking a deeper dive into this task: - -- The ``command`` option provides the command you want to run on the device or host. Alternately, you can provide text from a previous command with the ``text`` option instead. -- The ``parser`` option provides information specific to the parser engine. -- The ``name`` suboption provides the fully qualified collection name (FQCN) of the parsing engine (``ansible.netcommon.native``). -- The ``cli_parse`` module, by default, looks for the template in the templates directory as ``{{ short_os }}_{{ command }}.yaml``. - - - The ``short_os`` in the template filename is derived from either the host ``ansible_network_os`` or ``ansible_distribution``. - - Spaces in the network or host command are replace with ``_`` in the ``command`` portion of the template filename. In this example, the ``show interfaces`` network CLI command becomes ``show_interfaces`` in the filename. - -.. note:: - - ``ansible.netcommon.native`` parsing engine is fully supported with a Red Hat Ansible Automation Platform subscription. - -Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the device based on the now-structured data returned from ``cli_parse``: - -.. code-block:: yaml - - Ethernet1/1: - hardware: 100/1000/10000 Ethernet - mac_address: 5254.005a.f8bd - name: Ethernet1/1 - state: - admin: up - operating: up - Ethernet1/10: - hardware: 100/1000/10000 Ethernet - mac_address: 5254.005a.f8c6 - <...> - - -Linux example -^^^^^^^^^^^^^ - -You can also use the native parser to run commands and parse output from Linux hosts. - -The output of a sample Linux command (``ip addr show``) looks as follows: - -.. code-block:: bash - - 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo - valid_lft forever preferred_lft forever - inet6 ::1/128 scope host - valid_lft forever preferred_lft forever - 2: enp0s31f6: mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 - link/ether x2:6a:64:9d:84:19 brd ff:ff:ff:ff:ff:ff - 3: wlp2s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 - link/ether x6:c2:44:f7:41:e0 brd ff:ff:ff:ff:ff:ff permaddr d8:f2:ca:99:5c:82 - -Create the native template to match this output and store it as ``templates/fedora_ip_addr_show.yaml``: - -.. code-block:: yaml - - --- - - example: '1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000' - getval: | - (?x) # free-spacing - \d+:\s # the interface index - (?P\S+):\s # the name - <(?P\S+)> # the properties - \smtu\s(?P\d+) # the mtu - .* # gunk - state\s(?P\S+) # the state of the interface - result: - "{{ name }}": - name: "{{ name }}" - loopback: "{{ 'LOOPBACK' in stats.split(',') }}" - up: "{{ 'UP' in properties.split(',') }}" - carrier: "{{ not 'NO-CARRIER' in properties.split(',') }}" - broadcast: "{{ 'BROADCAST' in properties.split(',') }}" - multicast: "{{ 'MULTICAST' in properties.split(',') }}" - state: "{{ state|lower() }}" - mtu: "{{ mtu }}" - shared: True - - - example: 'inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0' - getval: | - (?x) # free-spacing - \s+inet\s(?P([0-9]{1,3}\.){3}[0-9]{1,3}) # the ip address - /(?P\d{1,2}) # the mask bits - result: - "{{ name }}": - ip_address: "{{ inet }}" - mask_bits: "{{ bits }}" - -.. note:: - - The ``shared`` key in the parser template allows the interface name to be used in subsequent parser entries. The use of examples and free-spacing mode with the regular expressions makes the template easier to read. - -The following example task uses ``cli_parse`` with the native parser and the example template above to parse the Linux output: - -.. code-block:: yaml - - - name: Run command and parse - ansible.utils.cli_parse: - command: ip addr show - parser: - name: ansible.netcommon.native - set_fact: interfaces - -This task assumes you previously gathered facts to determine the ``ansible_distribution`` needed to locate the template. Alternately, you could provide the path in the ``parser/template_path`` option. - - -Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the host, based on the now-structured data returned from ``cli_parse``: - -.. code-block:: yaml - - lo: - broadcast: false - carrier: true - ip_address: 127.0.0.1 - mask_bits: 8 - mtu: 65536 - multicast: false - name: lo - state: unknown - up: true - enp64s0u1: - broadcast: true - carrier: true - ip_address: 192.168.86.83 - mask_bits: 24 - mtu: 1500 - multicast: true - name: enp64s0u1 - state: up - up: true - <...> - - -Parsing JSON -------------- - -Although Ansible will natively convert serialized JSON to Ansible native data when recognized, you can also use the ``cli_parse`` module for this conversion. - -Example task: - -.. code-block:: yaml - - - name: "Run command and parse as json" - ansible.utils.cli_parse: - command: show interface | json - parser: - name: ansible.utils.json - register: interfaces - -Taking a deeper dive into this task: - -- The ``show interface | json`` command is issued on the device. -- The output is set as the ``interfaces`` fact for the device. -- JSON support is provided primarily for playbook consistency. - -.. note:: - - The use of ``ansible.netcommon.json`` is fully supported with a Red Hat Ansible Automation Platform subscription - -Parsing with ntc_templates ----------------------------- - -The ``ntc_templates`` python library includes pre-defined ``textfsm`` templates for parsing a variety of network device commands output. - -Example task: - -.. code-block:: yaml - - - name: "Run command and parse with ntc_templates" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.ntc_templates - set_fact: interfaces - -Taking a deeper dive into this task: - -- The ``ansible_network_os`` of the device is converted to the ntc_template format ``cisco_nxos``. Alternately, you can provide the ``os`` with the ``parser/os`` option instead. -- The ``cisco_nxos_show_interface.textfsm`` template, included with the ``ntc_templates`` package, parses the output. -- See `the ntc_templates README `_ for additional information about the ``ntc_templates`` python library. - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates`` public APIs as documented. - - -This task and and the predefined template sets the following fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - interfaces: - - address: 5254.005a.f8b5 - admin_state: up - bandwidth: 1000000 Kbit - bia: 5254.005a.f8b5 - delay: 10 usec - description: '' - duplex: full-duplex - encapsulation: ARPA - hardware_type: Ethernet - input_errors: '' - input_packets: '' - interface: mgmt0 - ip_address: 192.168.101.14/24 - last_link_flapped: '' - link_status: up - mode: '' - mtu: '1500' - output_errors: '' - output_packets: '' - speed: 1000 Mb/s - - address: 5254.005a.f8bd - admin_state: up - bandwidth: 1000000 Kbit - bia: 5254.005a.f8bd - delay: 10 usec - - -Parsing with pyATS ----------------------- - -``pyATS`` is part of the Cisco Test Automation & Validation Solution. It includes many predefined parsers for a number of network platforms and commands. You can use the predefined parsers that are part of the ``pyATS`` package with the ``cli_parse`` module. - -Example task: - -.. code-block:: yaml - - - name: "Run command and parse with pyats" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.pyats - set_fact: interfaces - - -Taking a deeper dive into this task: - -- The ``cli_parse`` modules converts the ``ansible_network_os`` automatically (in this example, ``ansible_network_os`` set to ``cisco.nxos.nxos``, converts to ``nxos`` for pyATS. Alternately, you can set the OS with the ``parser/os`` option instead. -- Using a combination of the command and OS, the pyATS selects the following parser: https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface. -- The ``cli_parse`` module sets ``cisco.ios.ios`` to ``iosxe`` for pyATS. You can override this with the ``parser/os`` option. -- ``cli_parse`` only uses the predefined parsers in pyATS. See the `pyATS documentation `_ and the full list of `pyATS included parsers `_. - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the pyATS public APIs as documented. - - -This task sets the following fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - mgmt0: - admin_state: up - auto_mdix: 'off' - auto_negotiate: true - bandwidth: 1000000 - counters: - in_broadcast_pkts: 3 - in_multicast_pkts: 1652395 - in_octets: 556155103 - in_pkts: 2236713 - in_unicast_pkts: 584259 - rate: - in_rate: 320 - in_rate_pkts: 0 - load_interval: 1 - out_rate: 48 - out_rate_pkts: 0 - rx: true - tx: true - delay: 10 - duplex_mode: full - enabled: true - encapsulations: - encapsulation: arpa - ethertype: '0x0000' - ipv4: - 192.168.101.14/24: - ip: 192.168.101.14 - prefix_length: '24' - link_state: up - <...> - - -Parsing with textfsm ---------------------- - -``textfsm`` is a Python module which implements a template-based state machine for parsing semi-formatted text. - -The following sample ``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm`` - -.. code-block:: text - - - Value Required INTERFACE (\S+) - Value LINK_STATUS (.+?) - Value ADMIN_STATE (.+?) - Value HARDWARE_TYPE (.\*) - Value ADDRESS ([a-zA-Z0-9]+.[a-zA-Z0-9]+.[a-zA-Z0-9]+) - Value BIA ([a-zA-Z0-9]+.[a-zA-Z0-9]+.[a-zA-Z0-9]+) - Value DESCRIPTION (.\*) - Value IP_ADDRESS (\d+\.\d+\.\d+\.\d+\/\d+) - Value MTU (\d+) - Value MODE (\S+) - Value DUPLEX (.+duplex?) - Value SPEED (.+?) - Value INPUT_PACKETS (\d+) - Value OUTPUT_PACKETS (\d+) - Value INPUT_ERRORS (\d+) - Value OUTPUT_ERRORS (\d+) - Value BANDWIDTH (\d+\s+\w+) - Value DELAY (\d+\s+\w+) - Value ENCAPSULATION (\w+) - Value LAST_LINK_FLAPPED (.+?) - - Start - ^\S+\s+is.+ -> Continue.Record - ^${INTERFACE}\s+is\s+${LINK_STATUS},\sline\sprotocol\sis\s${ADMIN_STATE}$$ - ^${INTERFACE}\s+is\s+${LINK_STATUS}$$ - ^admin\s+state\s+is\s+${ADMIN_STATE}, - ^\s+Hardware(:|\s+is)\s+${HARDWARE_TYPE},\s+address(:|\s+is)\s+${ADDRESS}(.*bia\s+${BIA})* - ^\s+Description:\s+${DESCRIPTION} - ^\s+Internet\s+Address\s+is\s+${IP_ADDRESS} - ^\s+Port\s+mode\s+is\s+${MODE} - ^\s+${DUPLEX}, ${SPEED}(,|$$) - ^\s+MTU\s+${MTU}.\*BW\s+${BANDWIDTH}.\*DLY\s+${DELAY} - ^\s+Encapsulation\s+${ENCAPSULATION} - ^\s+${INPUT_PACKETS}\s+input\s+packets\s+\d+\s+bytes\s\*$$ - ^\s+${INPUT_ERRORS}\s+input\s+error\s+\d+\s+short\s+frame\s+\d+\s+overrun\s+\d+\s+underrun\s+\d+\s+ignored\s\*$$ - ^\s+${OUTPUT_PACKETS}\s+output\s+packets\s+\d+\s+bytes\s\*$$ - ^\s+${OUTPUT_ERRORS}\s+output\s+error\s+\d+\s+collision\s+\d+\s+deferred\s+\d+\s+late\s+collision\s\*$$ - ^\s+Last\s+link\s+flapped\s+${LAST_LINK_FLAPPED}\s\*$$ - -The following task uses the example template for ``textfsm`` with the ``cli_parse`` module. - -.. code-block:: yaml - - - name: "Run command and parse with textfsm" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.utils.textfsm - set_fact: interfaces - -Taking a deeper dive into this task: - -- The ``ansible_network_os`` for the device (``cisco.nxos.nxos``) is converted to ``nxos``. Alternately you can provide the OS in the ``parser/os`` option instead. -- The textfsm template name defaulted to ``templates/nxos_show_interface.textfsm`` using a combination of the OS and command run. Alternately you can override the generated template path with the ``parser/template_path`` option. -- See the `textfsm README `_ for details. -- ``textfsm`` was previously made available as a filter plugin. Ansible users should transition to the ``cli_parse`` module. - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the ``textfsm`` public APIs as documented. - -This task sets the following fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - - ADDRESS: X254.005a.f8b5 - ADMIN_STATE: up - BANDWIDTH: 1000000 Kbit - BIA: X254.005a.f8b5 - DELAY: 10 usec - DESCRIPTION: '' - DUPLEX: full-duplex - ENCAPSULATION: ARPA - HARDWARE_TYPE: Ethernet - INPUT_ERRORS: '' - INPUT_PACKETS: '' - INTERFACE: mgmt0 - IP_ADDRESS: 192.168.101.14/24 - LAST_LINK_FLAPPED: '' - LINK_STATUS: up - MODE: '' - MTU: '1500' - OUTPUT_ERRORS: '' - OUTPUT_PACKETS: '' - SPEED: 1000 Mb/s - - ADDRESS: X254.005a.f8bd - ADMIN_STATE: up - BANDWIDTH: 1000000 Kbit - BIA: X254.005a.f8bd - - -Parsing with TTP ------------------ - -TTP is a Python library for semi-structured text parsing using templates. TTP uses a jinja-like syntax to limit the need for regular expressions. Users familiar with jinja templating may find the TTP template syntax familiar. - -The following is an example TTP template stored as ``templates/nxos_show_interface.ttp``: - -.. code-block:: jinja - - {{ interface }} is {{ state }} - admin state is {{ admin_state }}{{ ignore(".\*") }} - -The following task uses this template to parse the ``show interface`` command output: - -.. code-block:: yaml - - - name: "Run command and parse with ttp" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.utils.ttp - set_fact: interfaces - -Taking a deeper dive in this task: - -- The default template path ``templates/nxos_show_interface.ttp`` was generated using the ``ansible_network_os`` for the host and ``command`` provided. -- TTP supports several additional variables that will be passed to the parser. These include: - - - ``parser/vars/ttp_init`` - Additional parameter passed when the parser is initialized. - - ``parser/vars/ttp_results`` - Additional parameters used to influence the parser output. - - ``parser/vars/ttp_vars`` - Additional variables made available in the template. - -- See the `TTP documentation `_ for details. - - -The task sets the follow fact as the ``interfaces`` fact for the host: - -.. code-block:: yaml - - - admin_state: up, - interface: mgmt0 - state: up - - admin_state: up, - interface: Ethernet1/1 - state: up - - admin_state: up, - interface: Ethernet1/2 - state: up - - -Parsing with JC ------------------ - -JC is a python library that converts the output of dozens of common Linux/UNIX/macOS/Windows command-line tools and file types to python dictionaries or lists of dictionaries for easier parsing. JC is available as a filter plugin in the ``community.general`` collection. - -The following is an example using JC to parse the output of the ``dig`` command: - -.. code-block:: yaml - - - name: "Run dig command and parse with jc" - hosts: ubuntu - tasks: - - shell: dig example.com - register: result - - set_fact: - myvar: "{{ result.stdout | community.general.jc('dig') }}" - - debug: - msg: "The IP is: {{ myvar[0].answer[0].data }}" - -- The JC project and documentation can be found `here `_. -- See this `blog entry `_ for more information. - - -Converting XML ------------------ - -Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task. - -This example task runs the ``show interface`` command and parses the output as XML: - -.. code-block:: yaml - - - name: "Run command and parse as xml" - ansible.utils.cli_parse: - command: show interface | xml - parser: - name: ansible.utils.xml - set_fact: interfaces - -.. note:: - - Red Hat Ansible Automation Platform subscription support is limited to the use of the ``xmltodict`` public APIs as documented. - -This task sets the ``interfaces`` fact for the host based on this returned output: - -.. code-block:: yaml - - nf:rpc-reply: - '@xmlns': http://www.cisco.com/nxos:1.0:if_manager - '@xmlns:nf': urn:ietf:params:xml:ns:netconf:base:1.0 - nf:data: - show: - interface: - __XML__OPT_Cmd_show_interface_quick: - __XML__OPT_Cmd_show_interface___readonly__: - __readonly__: - TABLE_interface: - ROW_interface: - - admin_state: up - encapsulation: ARPA - eth_autoneg: 'on' - eth_bia_addr: x254.005a.f8b5 - eth_bw: '1000000' - - -Advanced use cases -=================== - -The ``cli_parse`` module supports several features to support more complex uses cases. - -Provide a full template path ------------------------------ - -Use the ``template_path`` option to override the default template path in the task: - -.. code-block:: yaml - - - name: "Run command and parse with native" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.native - template_path: /home/user/templates/filename.yaml - - -Provide command to parser different than the command run ------------------------------------------------------------ - -Use the ``command`` suboption for the ``parser`` to configure the command the parser expects if it is different from the command ``cli_parse`` runs: - -.. code-block:: yaml - - - name: "Run command and parse with native" - ansible.utils.cli_parse: - command: sho int - parser: - name: ansible.netcommon.native - command: show interface - -Provide a custom OS value --------------------------------- - -Use the ``os`` suboption to the parser to directly set the OS instead of using ``ansible_network_os`` or ``ansible_distribution`` to generate the template path or with the specified parser engine: - -.. code-block:: yaml - - - name: Use ios instead of iosxe for pyats - ansible.utils.cli_parse: - command: show something - parser: - name: ansible.netcommon.pyats - os: ios - - - name: Use linux instead of fedora from ansible_distribution - ansible.utils.cli_parse: - command: ps -ef - parser: - name: ansible.netcommon.native - os: linux - - -Parse existing text --------------------- - -Use the ``text`` option instead of ``command`` to parse text collected earlier in the playbook. - -.. code-block:: yaml - - # using /home/user/templates/filename.yaml - - name: "Parse text from previous task" - ansible.utils.cli_parse: - text: "{{ output['stdout'] }}" - parser: - name: ansible.netcommon.native - template_path: /home/user/templates/filename.yaml - - # using /home/user/templates/filename.yaml - - name: "Parse text from file" - ansible.utils.cli_parse: - text: "{{ lookup('file', 'path/to/file.txt') }}" - parser: - name: ansible.netcommon.native - template_path: /home/user/templates/filename.yaml - - # using templates/nxos_show_version.yaml - - name: "Parse text from previous task" - ansible.utils.cli_parse: - text: "{{ sho_version['stdout'] }}" - parser: - name: ansible.netcommon.native - os: nxos - command: show version - - -.. seealso:: - - * :ref:`develop_cli_parse_plugins` diff --git a/docs/docsite/rst/network/user_guide/faq.rst b/docs/docsite/rst/network/user_guide/faq.rst deleted file mode 100644 index cb43ac28fec..00000000000 --- a/docs/docsite/rst/network/user_guide/faq.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. _network_faq: - -******************* -Ansible Network FAQ -******************* - -.. contents:: Topics - -.. _network_faq_performance: - -How can I improve performance for network playbooks? -==================================================== - -.. _network_faq_strategy_free: - -Consider ``strategy: free`` if you are running on multiple hosts ---------------------------------------------------------------------------------- - -The ``strategy`` plugin tells Ansible how to order multiple tasks on multiple hosts. :ref:`Strategy` is set at the playbook level. - -The default strategy is ``linear``. With strategy set to ``linear``, Ansible waits until the current task has run on all hosts before starting the next task on any host. Ansible may have forks free, but will not use them until all hosts have completed the current task. If each task in your playbook must succeed on all hosts before you run the next task, use the ``linear`` strategy. - -Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance. - -.. _network_faq_limit_show_running: - -Execute ``show running`` only if you absolutely must ---------------------------------------------------------------------------------- - -The ``show running`` command is the most resource-intensive command to execute on a network device, because of the way queries are handled by the network OS. Using the command in your Ansible playbook will slow performance significantly, especially on large devices; repeating it will multiply the performance hit. If you have a playbook that checks the running config, then executes changes, then checks the running config again, you should expect that playbook to be very slow. - -.. _network_faq_limit_ProxyCommand: - -Use ``ProxyCommand`` only if you absolutely must ---------------------------------------------------------------------------------- - -Network modules support the use of a :ref:`proxy or jump host` with the ``ProxyCommand`` parameter. However, when you use a jump host, Ansible must open a new SSH connection for every task, even if you are using a persistent connection type (``network_cli`` or ``netconf``). To maximize the performance benefits of the persistent connection types introduced in version 2.5, avoid using jump hosts whenever possible. - -.. _network_faq_set_forks: - -Set ``--forks`` to match your needs ---------------------------------------------------------------------------------- - -Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound. - -.. _network_faq_redacted_output: - -Why is my output sometimes replaced with ``********``? -====================================================== - -Ansible replaces any string marked ``no_log``, including passwords, with ``********`` in Ansible output. This is done by design, to protect your sensitive data. Most users are happy to have their passwords redacted. However, Ansible replaces every string that matches your password with ``********``. If you use a common word for your password, this can be a problem. For example, if you choose ``Admin`` as your password, Ansible will replace every instance of the word ``Admin`` with ``********`` in your output. This may make your output harder to read. To avoid this problem, select a secure password that will not occur elsewhere in your Ansible output. - -.. _network_faq_no_abbreviations_with_config: - -Why do the ``*_config`` modules always return ``changed=true`` with abbreviated commands? -========================================================================================= - -When you issue commands directly on a network device, you can use abbreviated commands. For example, ``int g1/0/11`` and ``interface GigabitEthernet1/0/11`` do the same thing; ``shut`` and ``shutdown`` do the same thing. Ansible Network ``*_command`` modules work with abbreviations, because they run commands through the network OS. - -When committing configuration, however, the network OS converts abbreviations into long-form commands. Whether you use ``shut`` or ``shutdown`` on ``GigabitEthernet1/0/11``, the result in the configuration is the same: ``shutdown``. - -Ansible Network ``*_config`` modules compare the text of the commands you specify in ``lines`` to the text in the configuration. If you use ``shut`` in the ``lines`` section of your task, and the configuration reads ``shutdown``, the module returns ``changed=true`` even though the configuration is already correct. Your task will update the configuration every time it runs. - -To avoid this problem, use long-form commands with the ``*_config`` modules: - - -.. code-block:: yaml - - --- - - hosts: all - gather_facts: no - tasks: - - cisco.ios.ios_config: - lines: - - shutdown - parents: interface GigabitEthernet1/0/11 diff --git a/docs/docsite/rst/network/user_guide/index.rst b/docs/docsite/rst/network/user_guide/index.rst deleted file mode 100644 index 306a62704df..00000000000 --- a/docs/docsite/rst/network/user_guide/index.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _network_advanced: - -********************************** -Network Advanced Topics -********************************** - -Once you have mastered the basics of network automation with Ansible, as presented in :ref:`network_getting_started`, use this guide understand platform-specific details, optimization, and troubleshooting tips for Ansible for network automation. - -**Who should use this guide?** - -This guide is intended for network engineers using Ansible for automation. It covers advanced topics. If you understand networks and Ansible, this guide is for you. You may read through the entire guide if you choose, or use the links below to find the specific information you need. - -If you're new to Ansible, or new to using Ansible for network automation, start with the :ref:`network_getting_started`. - -.. toctree:: - :maxdepth: 2 - :caption: Advanced Topics - - network_resource_modules - network_best_practices_2.5 - cli_parsing - validate - network_debug_troubleshooting - network_working_with_command_output - faq - platform_index diff --git a/docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst b/docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst deleted file mode 100644 index 4b236ce6c84..00000000000 --- a/docs/docsite/rst/network/user_guide/network_best_practices_2.5.rst +++ /dev/null @@ -1,483 +0,0 @@ -.. _network-best-practices: - -************************ -Ansible Network Examples -************************ - -This document describes some examples of using Ansible to manage your network infrastructure. - -.. contents:: - :local: - -Prerequisites -============= - -This example requires the following: - -* **Ansible 2.10** (or higher) installed. See :ref:`intro_installation_guide` for more information. -* One or more network devices that are compatible with Ansible. -* Basic understanding of YAML :ref:`yaml_syntax`. -* Basic understanding of Jinja2 templates. See :ref:`playbooks_templating` for more information. -* Basic Linux command line use. -* Basic knowledge of network switch & router configurations. - - -Groups and variables in an inventory file -========================================= - -An ``inventory`` file is a YAML or INI-like configuration file that defines the mapping of hosts into groups. - -In our example, the inventory file defines the groups ``eos``, ``ios``, ``vyos`` and a "group of groups" called ``switches``. Further details about subgroups and inventory files can be found in the :ref:`Ansible inventory Group documentation `. - -Because Ansible is a flexible tool, there are a number of ways to specify connection information and credentials. We recommend using the ``[my_group:vars]`` capability in your inventory file. - -.. code-block:: ini - - [all:vars] - # these defaults can be overridden for any group in the [group:vars] section - ansible_connection=ansible.netcommon.network_cli - ansible_user=ansible - - [switches:children] - eos - ios - vyos - - [eos] - veos01 ansible_host=veos-01.example.net - veos02 ansible_host=veos-02.example.net - veos03 ansible_host=veos-03.example.net - veos04 ansible_host=veos-04.example.net - - [eos:vars] - ansible_become=yes - ansible_become_method=enable - ansible_network_os=arista.eos.eos - ansible_user=my_eos_user - ansible_password=my_eos_password - - [ios] - ios01 ansible_host=ios-01.example.net - ios02 ansible_host=ios-02.example.net - ios03 ansible_host=ios-03.example.net - - [ios:vars] - ansible_become=yes - ansible_become_method=enable - ansible_network_os=cisco.ios.ios - ansible_user=my_ios_user - ansible_password=my_ios_password - - [vyos] - vyos01 ansible_host=vyos-01.example.net - vyos02 ansible_host=vyos-02.example.net - vyos03 ansible_host=vyos-03.example.net - - [vyos:vars] - ansible_network_os=vyos.vyos.vyos - ansible_user=my_vyos_user - ansible_password=my_vyos_password - -If you use ssh-agent, you do not need the ``ansible_password`` lines. If you use ssh keys, but not ssh-agent, and you have multiple keys, specify the key to use for each connection in the ``[group:vars]`` section with ``ansible_ssh_private_key_file=/path/to/correct/key``. For more information on ``ansible_ssh_`` options see :ref:`behavioral_parameters`. - -.. FIXME FUTURE Gundalow - Link to network auth & proxy page (to be written) - -.. warning:: Never store passwords in plain text. - -Ansible vault for password encryption -------------------------------------- - -The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information. - -Here's what it would look like if you specified your SSH passwords (encrypted with Ansible Vault) among your variables: - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: my_vyos_user - ansible_ssh_pass: !vault | - $ANSIBLE_VAULT;1.1;AES256 - 39336231636137663964343966653162353431333566633762393034646462353062633264303765 - 6331643066663534383564343537343334633031656538370a333737656236393835383863306466 - 62633364653238323333633337313163616566383836643030336631333431623631396364663533 - 3665626431626532630a353564323566316162613432373738333064366130303637616239396438 - 9853 - -Common inventory variables --------------------------- - -The following variables are common for all platforms in the inventory, though they can be overwritten for a particular inventory group or host. - -:ansible_connection: - - Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to an appropriate network connection option, such as``ansible.netcommon.network_cli``, so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices. -:ansible_network_os: - Informs Ansible which Network platform this hosts corresponds to. This is required when using the ``ansible.netcommon.*`` connection options. -:ansible_user: The user to connect to the remote device (switch) as. Without this the user that is running ``ansible-playbook`` would be used. - Specifies which user on the network device the connection -:ansible_password: - The corresponding password for ``ansible_user`` to log in as. If not specified SSH key will be used. -:ansible_become: - If enable mode (privilege mode) should be used, see the next section. -:ansible_become_method: - Which type of `become` should be used, for ``network_cli`` the only valid choice is ``enable``. - -Privilege escalation --------------------- - -Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: ansible.netcommon.network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here: - -.. code-block:: ini - - [eos:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=arista.eos.eos - ansible_become=yes - ansible_become_method=enable - -For more information, see the :ref:`using become with network modules` guide. - - -Jump hosts ----------- - -If the Ansible Controller does not have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command ` guide for details on how to achieve this. - -Example 1: collecting facts and creating backup files with a playbook -===================================================================== - -Ansible facts modules gather system information 'facts' that are available to the rest of your playbook. - -Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`arista.eos.eos_facts `, :ref:`cisco.ios.ios_facts ` and :ref:`vyos.vyos.vyos_facts ` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file. - -Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`arista.eos.eos_facts ` and :ref:`vyos.vyos.vyos_facts `. We can use the facts, such as ``ansible_net_version`` late on in the "Display some facts" task. - -To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`. - -In this example, we will create an inventory file containing some network switches, then run a playbook to connect to the network devices and return some information about them. - -Step 1: Creating the inventory ------------------------------- - -First, create a file called ``inventory``, containing: - -.. code-block:: ini - - [switches:children] - eos - ios - vyos - - [eos] - eos01.example.net - - [ios] - ios01.example.net - - [vyos] - vyos01.example.net - - -Step 2: Creating the playbook ------------------------------ - -Next, create a playbook file called ``facts-demo.yml`` containing the following: - -.. code-block:: yaml - - - name: "Demonstrate connecting to switches" - hosts: switches - gather_facts: no - - tasks: - ### - # Collect data - # - - name: Gather facts (eos) - arista.eos.eos_facts: - when: ansible_network_os == 'arista.eos.eos' - - - name: Gather facts (ios) - cisco.ios.ios_facts: - when: ansible_network_os == 'cisco.ios.ios' - - - name: Gather facts (vyos) - vyos.vyos.vyos_facts: - when: ansible_network_os == 'vyos.vyos.vyos' - - ### - # Demonstrate variables - # - - name: Display some facts - debug: - msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}" - - - name: Facts from a specific host - debug: - var: hostvars['vyos01.example.net'] - - - name: Write facts to disk using a template - copy: - content: | - #jinja2: lstrip_blocks: True - EOS device info: - {% for host in groups['eos'] %} - Hostname: {{ hostvars[host].ansible_net_hostname }} - Version: {{ hostvars[host].ansible_net_version }} - Model: {{ hostvars[host].ansible_net_model }} - Serial: {{ hostvars[host].ansible_net_serialnum }} - {% endfor %} - - IOS device info: - {% for host in groups['ios'] %} - Hostname: {{ hostvars[host].ansible_net_hostname }} - Version: {{ hostvars[host].ansible_net_version }} - Model: {{ hostvars[host].ansible_net_model }} - Serial: {{ hostvars[host].ansible_net_serialnum }} - {% endfor %} - - VyOS device info: - {% for host in groups['vyos'] %} - Hostname: {{ hostvars[host].ansible_net_hostname }} - Version: {{ hostvars[host].ansible_net_version }} - Model: {{ hostvars[host].ansible_net_model }} - Serial: {{ hostvars[host].ansible_net_serialnum }} - {% endfor %} - dest: /tmp/switch-facts - run_once: yes - - ### - # Get running configuration - # - - - name: Backup switch (eos) - arista.eos.eos_config: - backup: yes - register: backup_eos_location - when: ansible_network_os == 'arista.eos.eos' - - - name: backup switch (vyos) - vyos.vyos.vyos_config: - backup: yes - register: backup_vyos_location - when: ansible_network_os == 'vyos.vyos.vyos' - - - name: Create backup dir - file: - path: "/tmp/backups/{{ inventory_hostname }}" - state: directory - recurse: yes - - - name: Copy backup files into /tmp/backups/ (eos) - copy: - src: "{{ backup_eos_location.backup_path }}" - dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck" - when: ansible_network_os == 'arista.eos.eos' - - - name: Copy backup files into /tmp/backups/ (vyos) - copy: - src: "{{ backup_vyos_location.backup_path }}" - dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck" - when: ansible_network_os == 'vyos.vyos.vyos' - -Step 3: Running the playbook ----------------------------- - -To run the playbook, run the following from a console prompt: - -.. code-block:: console - - ansible-playbook -i inventory facts-demo.yml - -This should return output similar to the following: - -.. code-block:: console - - PLAY RECAP - eos01.example.net : ok=7 changed=2 unreachable=0 failed=0 - ios01.example.net : ok=7 changed=2 unreachable=0 failed=0 - vyos01.example.net : ok=6 changed=2 unreachable=0 failed=0 - -Step 4: Examining the playbook results --------------------------------------- - -Next, look at the contents of the file we created containing the switch facts: - -.. code-block:: console - - cat /tmp/switch-facts - -You can also look at the backup files: - -.. code-block:: console - - find /tmp/backups - - -If `ansible-playbook` fails, please follow the debug steps in :ref:`network_debug_troubleshooting`. - - -.. _network-independent-examples: - -Example 2: simplifying playbooks with platform-independent modules -================================================================== - -(This example originally appeared in the `Deep Dive on cli_command for Network Automation `_ blog post by Sean Cavanaugh -`@IPvSean `_). - -If you have two or more network platforms in your environment, you can use the platform-independent modules to simplify your playbooks. You can use platform-independent modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks. - -.. note:: - Platform-independent modules require the :ref:`ansible.netcommon.network_cli ` connection plugin. - - -Sample playbook with platform-specific modules ----------------------------------------------- - -This example assumes three platforms, Arista EOS, Cisco NXOS, and Juniper JunOS. Without the platform-independent modules, a sample playbook might contain the following three tasks with platform-specific commands: - -.. code-block:: yaml - - --- - - name: Run Arista command - arista.eos.eos_command: - commands: show ip int br - when: ansible_network_os == 'arista.eos.eos' - - - name: Run Cisco NXOS command - cisco.nxos.nxos_command: - commands: show ip int br - when: ansible_network_os == 'cisco.nxos.nxos' - - - name: Run Vyos command - vyos.vyos.vyos_command: - commands: show interface - when: ansible_network_os == 'vyos.vyos.vyos' - -Simplified playbook with ``cli_command`` platform-independent module --------------------------------------------------------------------- - -You can replace these platform-specific modules with the platform-independent ``ansible.netcommon.cli_command`` module as follows: - -.. code-block:: yaml - - --- - - hosts: network - gather_facts: false - connection: ansible.netcommon.network_cli - - tasks: - - name: Run cli_command on Arista and display results - block: - - name: Run cli_command on Arista - ansible.netcommon.cli_command: - command: show ip int br - register: result - - - name: Display result to terminal window - debug: - var: result.stdout_lines - when: ansible_network_os == 'arista.eos.eos' - - - name: Run cli_command on Cisco IOS and display results - block: - - name: Run cli_command on Cisco IOS - ansible.netcommon.cli_command: - command: show ip int br - register: result - - - name: Display result to terminal window - debug: - var: result.stdout_lines - when: ansible_network_os == 'cisco.ios.ios' - - - name: Run cli_command on Vyos and display results - block: - - name: Run cli_command on Vyos - ansible.netcommon.cli_command: - command: show interfaces - register: result - - - name: Display result to terminal window - debug: - var: result.stdout_lines - when: ansible_network_os == 'vyos.vyos.vyos' - - -If you use groups and group_vars by platform type, this playbook can be further simplified to : - -.. code-block:: yaml - - --- - - name: Run command and print to terminal window - hosts: routers - gather_facts: false - - tasks: - - name: Run show command - ansible.netcommon.cli_command: - command: "{{show_interfaces}}" - register: command_output - - -You can see a full example of this using group_vars and also a configuration backup example at `Platform-independent examples `_. - -Using multiple prompts with the ``ansible.netcommon.cli_command`` -------------------------------------------------------------------- - -The ``ansible.netcommon.cli_command`` also supports multiple prompts. - -.. code-block:: yaml - - --- - - name: Change password to default - ansible.netcommon.cli_command: - command: "{{ item }}" - prompt: - - "New password" - - "Retype new password" - answer: - - "mypassword123" - - "mypassword123" - check_all: True - loop: - - "configure" - - "rollback" - - "set system root-authentication plain-text-password" - - "commit" - -See the :ref:`ansible.netcommon.cli_command ` for full documentation on this command. - - -Implementation Notes -==================== - - -Demo variables --------------- - -Although these tasks are not needed to write data to disk, they are used in this example to demonstrate some methods of accessing facts about the given devices or a named host. - -Ansible ``hostvars`` allows you to access variables from a named host. Without this we would return the details for the current host, rather than the named host. - -For more information, see :ref:`magic_variables_and_hostvars`. - -Get running configuration -------------------------- - -The :ref:`arista.eos.eos_config ` and :ref:`vyos.vyos.vyos_config ` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created. - -To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in ``backup_path``. - -Note that when using variables from tasks in this way we use double quotes (``"``) and double curly-brackets (``{{...}}`` to tell Ansible that this is a variable. - -Troubleshooting -=============== - -If you receive an connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`. - -.. seealso:: - - * :ref:`network_guide` - * :ref:`intro_inventory` - * :ref:`Keeping vaulted variables visible ` diff --git a/docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst b/docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst deleted file mode 100644 index d0fbcd6383f..00000000000 --- a/docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst +++ /dev/null @@ -1,840 +0,0 @@ -.. _network_debug_troubleshooting: - -*************************************** -Network Debug and Troubleshooting Guide -*************************************** - -This section discusses how to debug and troubleshoot network modules in Ansible. - -.. contents:: - :local: - - -How to troubleshoot -=================== - -Ansible network automation errors generally fall into one of the following categories: - -:Authentication issues: - * Not correctly specifying credentials - * Remote device (network switch/router) not falling back to other other authentication methods - * SSH key issues -:Timeout issues: - * Can occur when trying to pull a large amount of data - * May actually be masking a authentication issue -:Playbook issues: - * Use of ``delegate_to``, instead of ``ProxyCommand``. See :ref:`network proxy guide ` for more information. - -.. warning:: ``unable to open shell`` - - The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully - talk to the remote network device. This generally means that there is an authentication issue. See the "Authentication and connection issues" section - in this document for more information. - -.. _enable_network_logging: - -Enabling Networking logging and how to read the logfile -------------------------------------------------------- - -**Platforms:** Any - -Ansible includes logging to help diagnose and troubleshoot issues regarding Ansible Networking modules. - -Because logging is very verbose, it is disabled by default. It can be enabled with the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ``ansible-playbook``. - -Before running ``ansible-playbook``, run the following commands to enable logging: - -.. code:: shell - - # Specify the location for the log file - export ANSIBLE_LOG_PATH=~/ansible.log - # Enable Debug - export ANSIBLE_DEBUG=True - - # Run with 4*v for connection level verbosity - ansible-playbook -vvvv ... - -After Ansible has finished running you can inspect the log file which has been created on the ansible-controller: - -.. code:: - - less $ANSIBLE_LOG_PATH - - 2017-03-30 13:19:52,740 p=28990 u=fred | creating new control socket for host veos01:22 as user admin - 2017-03-30 13:19:52,741 p=28990 u=fred | control socket path is /home/fred/.ansible/pc/ca5960d27a - 2017-03-30 13:19:52,741 p=28990 u=fred | current working directory is /home/fred/ansible/test/integration - 2017-03-30 13:19:52,741 p=28990 u=fred | using connection plugin network_cli - ... - 2017-03-30 13:20:14,771 paramiko.transport userauth is OK - 2017-03-30 13:20:15,283 paramiko.transport Authentication (keyboard-interactive) successful! - 2017-03-30 13:20:15,302 p=28990 u=fred | ssh connection done, setting terminal - 2017-03-30 13:20:15,321 p=28990 u=fred | ssh connection has completed successfully - 2017-03-30 13:20:15,322 p=28990 u=fred | connection established to veos01 in 0:00:22.580626 - - -From the log notice: - -* ``p=28990`` Is the PID (Process ID) of the ``ansible-connection`` process -* ``u=fred`` Is the user `running` ansible, not the remote-user you are attempting to connect as -* ``creating new control socket for host veos01:22 as user admin`` host:port as user -* ``control socket path is`` location on disk where the persistent connection socket is created -* ``using connection plugin network_cli`` Informs you that persistent connection is being used -* ``connection established to veos01 in 0:00:22.580626`` Time taken to obtain a shell on the remote device - - -.. note:: Port None ``creating new control socket for host veos01:None`` - - If the log reports the port as ``None`` this means that the default port is being used. - A future Ansible release will improve this message so that the port is always logged. - -Because the log files are verbose, you can use grep to look for specific information. For example, once you have identified the ``pid`` from the ``creating new control socket for host`` line you can search for other connection log entries: - -.. code:: shell - - grep "p=28990" $ANSIBLE_LOG_PATH - - -Enabling Networking device interaction logging ----------------------------------------------- - -**Platforms:** Any - -Ansible includes logging of device interaction in the log file to help diagnose and troubleshoot -issues regarding Ansible Networking modules. The messages are logged in the file pointed to by the ``log_path`` configuration -option in the Ansible configuration file or by setting the :envvar:`ANSIBLE_LOG_PATH`. - -.. warning:: - The device interaction messages consist of command executed on the target device and the returned response. Since this - log data can contain sensitive information including passwords in plain text it is disabled by default. - Additionally, in order to prevent accidental leakage of data, a warning will be shown on every task with this - setting enabled, specifying which host has it enabled and where the data is being logged. - -Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing a special variable to the task. - -Before running ``ansible-playbook`` run the following commands to enable logging: - -.. code-block:: text - - # Specify the location for the log file - export ANSIBLE_LOG_PATH=~/ansible.log - - -Enable device interaction logging for a given task - -.. code-block:: yaml - - - name: get version information - cisco.ios.ios_command: - commands: - - show version - vars: - ansible_persistent_log_messages: True - - -To make this a global setting, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - log_messages = True - -or enable the environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`: - -.. code-block:: text - - # Enable device interaction logging - export ANSIBLE_PERSISTENT_LOG_MESSAGES=True - -If the task is failing on connection initialization itself, you should enable this option -globally. If an individual task is failing intermittently this option can be enabled for that task itself to find the root cause. - -After Ansible has finished running you can inspect the log file which has been created on the ansible-controller - -.. note:: Be sure to fully understand the security implications of enabling this option as it can log sensitive - information in log file thus creating security vulnerability. - - -Isolating an error ------------------- - -**Platforms:** Any - -As with any effort to troubleshoot it's important to simplify the test case as much as possible. - -For Ansible this can be done by ensuring you are only running against one remote device: - -* Using ``ansible-playbook --limit switch1.example.net...`` -* Using an ad hoc ``ansible`` command - -`ad hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device: - -.. code-block:: text - - ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k - -In the above example, we: - -* connect to ``switch1.example.net`` specified in the inventory file ``inventory`` -* use the module ``arista.eos.eos_command`` -* run the command ``?`` -* connect using the username ``admin`` -* inform the ``ansible`` command to prompt for the SSH password by specifying ``-k`` - -If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter. - -If the connection still fails you can combine it with the enable_network_logging parameter. For example: - -.. code-block:: text - - # Specify the location for the log file - export ANSIBLE_LOG_PATH=~/ansible.log - # Enable Debug - export ANSIBLE_DEBUG=True - # Run with ``-vvvv`` for connection level verbosity - ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k - -Then review the log file and find the relevant error message in the rest of this document. - -.. For details on other ways to authenticate, see LINKTOAUTHHOWTODOCS. - -.. _socket_path_issue: - -Troubleshooting socket path issues -================================== - -**Platforms:** Any - -The ``Socket path does not exist or cannot be found`` and ``Unable to connect to socket`` messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist. - -For example: - -.. code-block:: none - - fatal: [spine02]: FAILED! => { - "changed": false, - "failed": true, - "module_stderr": "Traceback (most recent call last):\n File \"/tmp/ansible_TSqk5J/ansible_modlib.zip/ansible/module_utils/connection.py\", line 115, in _exec_jsonrpc\nansible.module_utils.connection.ConnectionError: Socket path XX does not exist or cannot be found. See Troubleshooting socket path issues in the Network Debug and Troubleshooting Guide\n", - "module_stdout": "", - "msg": "MODULE FAILURE", - "rc": 1 - } - -or - -.. code-block:: none - - fatal: [spine02]: FAILED! => { - "changed": false, - "failed": true, - "module_stderr": "Traceback (most recent call last):\n File \"/tmp/ansible_TSqk5J/ansible_modlib.zip/ansible/module_utils/connection.py\", line 123, in _exec_jsonrpc\nansible.module_utils.connection.ConnectionError: Unable to connect to socket XX. See Troubleshooting socket path issues in Network Debug and Troubleshooting Guide\n", - "module_stdout": "", - "msg": "MODULE FAILURE", - "rc": 1 - } - -Suggestions to resolve: - -#. Verify that you have write access to the socket path described in the error message. - -#. Follow the steps detailed in :ref:`enable network logging `. - -If the identified error message from the log file is: - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | command timeout triggered, timeout value is 30 secs - -or - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | persistent connection idle timeout triggered, timeout value is 30 secs - -Follow the steps detailed in :ref:`timeout issues ` - - -.. _unable_to_open_shell: - -Category "Unable to open shell" -=============================== - - -**Platforms:** Any - -The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`logging ` to find the underlying issues. - - - -For example: - -.. code-block:: none - - TASK [prepare_eos_tests : enable cli on remote device] ************************************************** - fatal: [veos01]: FAILED! => {"changed": false, "failed": true, "msg": "unable to open shell"} - - -or: - - -.. code-block:: none - - TASK [ios_system : configure name_servers] ************************************************************* - task path: - fatal: [ios-csr1000v]: FAILED! => { - "changed": false, - "failed": true, - "msg": "unable to open shell", - } - -Suggestions to resolve: - -Follow the steps detailed in enable_network_logging_. - -Once you've identified the error message from the log file, the specific solution can be found in the rest of this document. - - - -Error: "[Errno -2] Name or service not known" ---------------------------------------------- - -**Platforms:** Any - -Indicates that the remote host you are trying to connect to can not be reached - -For example: - -.. code-block:: yaml - - 2017-04-04 11:39:48,147 p=15299 u=fred | control socket path is /home/fred/.ansible/pc/ca5960d27a - 2017-04-04 11:39:48,147 p=15299 u=fred | current working directory is /home/fred/git/ansible-inc/stable-2.3/test/integration - 2017-04-04 11:39:48,147 p=15299 u=fred | using connection plugin network_cli - 2017-04-04 11:39:48,340 p=15299 u=fred | connecting to host veos01 returned an error - 2017-04-04 11:39:48,340 p=15299 u=fred | [Errno -2] Name or service not known - - -Suggestions to resolve: - -* If you are using the ``provider:`` options ensure that its suboption ``host:`` is set correctly. -* If you are not using ``provider:`` nor top-level arguments ensure your inventory file is correct. - - - - - -Error: "Authentication failed" ------------------------------- - -**Platforms:** Any - -Occurs if the credentials (username, passwords, or ssh keys) passed to ``ansible-connection`` (through ``ansible`` or ``ansible-playbook``) can not be used to connect to the remote device. - - - -For example: - -.. code-block:: yaml - - ESTABLISH CONNECTION FOR USER: cisco on PORT 22 TO ios01 - Authentication failed. - - -Suggestions to resolve: - -If you are specifying credentials through ``password:`` (either directly or through ``provider:``) or the environment variable `ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable "look for keys". This can be done like this: - -.. code-block:: yaml - - export ANSIBLE_PARAMIKO_LOOK_FOR_KEYS=False - -To make this a permanent change, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [paramiko_connection] - look_for_keys = False - - -Error: "connecting to host returned an error" or "Bad address" -------------------------------------------------------------------------- - -This may occur if the SSH fingerprint hasn't been added to Paramiko's (the Python SSH library) know hosts file. - -When using persistent connections with Paramiko, the connection runs in a background process. If the host doesn't already have a valid SSH key, by default Ansible will prompt to add the host key. This will cause connections running in background processes to fail. - -For example: - -.. code-block:: yaml - - 2017-04-04 12:06:03,486 p=17981 u=fred | using connection plugin network_cli - 2017-04-04 12:06:04,680 p=17981 u=fred | connecting to host veos01 returned an error - 2017-04-04 12:06:04,682 p=17981 u=fred | (14, 'Bad address') - 2017-04-04 12:06:33,519 p=17981 u=fred | number of connection attempts exceeded, unable to connect to control socket - 2017-04-04 12:06:33,520 p=17981 u=fred | persistent_connect_interval=1, persistent_connect_retries=30 - - -Suggestions to resolve: - -Use ``ssh-keyscan`` to pre-populate the known_hosts. You need to ensure the keys are correct. - -.. code-block:: shell - - ssh-keyscan veos01 - - -or - -You can tell Ansible to automatically accept the keys - -Environment variable method: - -.. code-block:: shell - - export ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD=True - ansible-playbook ... - -``ansible.cfg`` method: - -ansible.cfg - -.. code-block:: ini - - [paramiko_connection] - host_key_auto_add = True - - - -.. warning: Security warning - - Care should be taken before accepting keys. - -Error: "No authentication methods available" --------------------------------------------- - -For example: - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | creating new control socket for host veos01:None as user admin - 2017-04-04 12:19:05,670 p=18591 u=fred | control socket path is /home/fred/.ansible/pc/ca5960d27a - 2017-04-04 12:19:05,670 p=18591 u=fred | current working directory is /home/fred/git/ansible-inc/ansible-workspace-2/test/integration - 2017-04-04 12:19:05,670 p=18591 u=fred | using connection plugin network_cli - 2017-04-04 12:19:06,606 p=18591 u=fred | connecting to host veos01 returned an error - 2017-04-04 12:19:06,606 p=18591 u=fred | No authentication methods available - 2017-04-04 12:19:35,708 p=18591 u=fred | connect retry timeout expired, unable to connect to control socket - 2017-04-04 12:19:35,709 p=18591 u=fred | persistent_connect_retry_timeout is 15 secs - - -Suggestions to resolve: - -No password or SSH key supplied - -Clearing Out Persistent Connections ------------------------------------ - -**Platforms:** Any - -In Ansible 2.3, persistent connection sockets are stored in ``~/.ansible/pc`` for all network devices. When an Ansible playbook runs, the persistent socket connection is displayed when verbose output is specified. - -`` socket_path: /home/fred/.ansible/pc/f64ddfa760`` - -To clear out a persistent connection before it times out (the default timeout is 30 seconds -of inactivity), simple delete the socket file. - - -.. _timeout_issues: - -Timeout issues -============== - -Persistent connection idle timeout ----------------------------------- - -By default, ``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` is set to 30 (seconds). You may see the following error if this value is too low: - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | persistent connection idle timeout triggered, timeout value is 30 secs - -Suggestions to resolve: - -Increase value of persistent connection idle timeout: - -.. code-block:: sh - - export ANSIBLE_PERSISTENT_CONNECT_TIMEOUT=60 - -To make this a permanent change, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - connect_timeout = 60 - -Command timeout ---------------- - -By default, ``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` is set to 30 (seconds). Prior versions of Ansible had this value set to 10 seconds by default. -You may see the following error if this value is too low: - - -.. code-block:: yaml - - 2017-04-04 12:19:05,670 p=18591 u=fred | command timeout triggered, timeout value is 30 secs - -Suggestions to resolve: - -* Option 1 (Global command timeout setting): - Increase value of command timeout in configuration file or by setting environment variable. - - .. code-block:: yaml - - export ANSIBLE_PERSISTENT_COMMAND_TIMEOUT=60 - - To make this a permanent change, add the following to your ``ansible.cfg`` file: - - .. code-block:: ini - - [persistent_connection] - command_timeout = 60 - -* Option 2 (Per task command timeout setting): - Increase command timeout per task basis. All network modules support a - timeout value that can be set on a per task basis. - The timeout value controls the amount of time in seconds before the - task will fail if the command has not returned. - - For local connection type: - - .. FIXME: Detail error here - - Suggestions to resolve: - - Some modules support a ``timeout`` option, which is different to the ``timeout`` keyword for tasks. - - .. code-block:: yaml - - - name: save running-config - cisco.ios.ios_command: - commands: copy running-config startup-config - provider: "{{ cli }}" - timeout: 30 - - - Suggestions to resolve: - - If the module does not support the ``timeout`` option directly, most networking connection plugins can enable similar functionality with the ``ansible_command_timeout`` variable. - - .. code-block:: yaml - - - name: save running-config - cisco.ios.ios_command: - commands: copy running-config startup-config - vars: - ansible_command_timeout: 60 - -Some operations take longer than the default 30 seconds to complete. One good -example is saving the current running config on IOS devices to startup config. -In this case, changing the timeout value from the default 30 seconds to 60 -seconds will prevent the task from failing before the command completes -successfully. - -Persistent connection retry timeout ------------------------------------ - -By default, ``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` is set to 15 (seconds). You may see the following error if this value is too low: - -.. code-block:: yaml - - 2017-04-04 12:19:35,708 p=18591 u=fred | connect retry timeout expired, unable to connect to control socket - 2017-04-04 12:19:35,709 p=18591 u=fred | persistent_connect_retry_timeout is 15 secs - -Suggestions to resolve: - -Increase the value of the persistent connection idle timeout. -Note: This value should be greater than the SSH timeout value (the timeout value under the defaults -section in the configuration file) and less than the value of the persistent -connection idle timeout (connect_timeout). - -.. code-block:: yaml - - export ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT=30 - -To make this a permanent change, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - connect_retry_timeout = 30 - - -Timeout issue due to platform specific login menu with ``network_cli`` connection type --------------------------------------------------------------------------------------- - -In Ansible 2.9 and later, the network_cli connection plugin configuration options are added -to handle the platform specific login menu. These options can be set as group/host or tasks -variables. - -Example: Handle single login menu prompts with host variables - -.. code-block:: console - - $cat host_vars/.yaml - --- - ansible_terminal_initial_prompt: - - "Connect to a host" - ansible_terminal_initial_answer: - - "3" - -Example: Handle remote host multiple login menu prompts with host variables - -.. code-block:: console - - $cat host_vars/.yaml - --- - ansible_terminal_initial_prompt: - - "Press any key to enter main menu" - - "Connect to a host" - ansible_terminal_initial_answer: - - "\\r" - - "3" - ansible_terminal_initial_prompt_checkall: True - -To handle multiple login menu prompts: - -* The values of ``ansible_terminal_initial_prompt`` and ``ansible_terminal_initial_answer`` should be a list. -* The prompt sequence should match the answer sequence. -* The value of ``ansible_terminal_initial_prompt_checkall`` should be set to ``True``. - -.. note:: If all the prompts in sequence are not received from remote host at the time connection initialization it will result in a timeout. - - -Playbook issues -=============== - -This section details issues are caused by issues with the Playbook itself. - -Error: "Unable to enter configuration mode" -------------------------------------------- - -**Platforms:** Arista EOS and Cisco IOS - -This occurs when you attempt to run a task that requires privileged mode in a user mode shell. - -For example: - -.. code-block:: console - - TASK [ios_system : configure name_servers] ***************************************************************************** - task path: - fatal: [ios-csr1000v]: FAILED! => { - "changed": false, - "failed": true, - "msg": "unable to enter configuration mode", - } - -Suggestions to resolve: - - Use ``connection: ansible.netcommon.network_cli`` and ``become: yes`` - - -Proxy Issues -============ - - .. _network_delegate_to_vs_ProxyCommand: - -delegate_to vs ProxyCommand ---------------------------- - -In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` -transport, network modules support the use of ``ProxyCommand``. - -To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory -file to specify the proxy host. - -.. code-block:: ini - - [nxos] - nxos01 - nxos02 - - [nxos:vars] - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -With the configuration above, simply build and run the playbook as normal with -no additional changes necessary. The network module will now connect to the -network device by first connecting to the host specified in -``ansible_ssh_common_args``, which is ``bastion01`` in the above example. - -You can also set the proxy target for all hosts by using environment variables. - -.. code-block:: sh - - export ANSIBLE_SSH_ARGS='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - -Using bastion/jump host with netconf connection ------------------------------------------------ - -Enabling jump host setting --------------------------- - - -Bastion/jump host with netconf connection can be enabled by: - - Setting Ansible variable ``ansible_netconf_ssh_config`` either to ``True`` or custom ssh config file path - - Setting environment variable ``ANSIBLE_NETCONF_SSH_CONFIG`` to ``True`` or custom ssh config file path - - Setting ``ssh_config = 1`` or ``ssh_config = `` under ``netconf_connection`` section - -If the configuration variable is set to 1 the proxycommand and other ssh variables are read from -default ssh config file (~/.ssh/config). - -If the configuration variable is set to file path the proxycommand and other ssh variables are read -from the given custom ssh file path - -Example ssh config file (~/.ssh/config) ---------------------------------------- - -.. code-block:: ini - - Host jumphost - HostName jumphost.domain.name.com - User jumphost-user - IdentityFile "/path/to/ssh-key.pem" - Port 22 - - # Note: Due to the way that Paramiko reads the SSH Config file, - # you need to specify the NETCONF port that the host uses. - # In other words, it does not automatically use ansible_port - # As a result you need either: - - Host junos01 - HostName junos01 - ProxyCommand ssh -W %h:22 jumphost - - # OR - - Host junos01 - HostName junos01 - ProxyCommand ssh -W %h:830 jumphost - - # Depending on the netconf port used. - -Example Ansible inventory file - -.. code-block:: ini - - [junos] - junos01 - - [junos:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault... - - -.. note:: Using ``ProxyCommand`` with passwords through variables - - By design, SSH doesn't support providing passwords through environment variables. - This is done to prevent secrets from leaking out, for example in ``ps`` output. - - We recommend using SSH Keys, and if needed an ssh-agent, rather than passwords, where ever possible. - -Miscellaneous Issues -==================== - - -Intermittent failure while using ``ansible.netcommon.network_cli`` connection type ------------------------------------------------------------------------------------- - -If the command prompt received in response is not matched correctly within -the ``ansible.netcommon.network_cli`` connection plugin the task might fail intermittently with truncated -response or with the error message ``operation requires privilege escalation``. -Starting in 2.7.1 a new buffer read timer is added to ensure prompts are matched properly -and a complete response is send in output. The timer default value is 0.2 seconds and -can be adjusted on a per task basis or can be set globally in seconds. - -Example Per task timer setting - -.. code-block:: yaml - - - name: gather ios facts - cisco.ios.ios_facts: - gather_subset: all - register: result - vars: - ansible_buffer_read_timeout: 2 - - -To make this a global setting, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - buffer_read_timeout = 2 - -This timer delay per command executed on remote host can be disabled by setting the value to zero. - - -Task failure due to mismatched error regex within command response using ``ansible.netcommon.network_cli`` connection type ----------------------------------------------------------------------------------------------------------------------------- - -In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration options are added -to handle the stdout and stderr regex to identify if the command execution response consist -of a normal response or an error response. These options can be set group/host variables or as -tasks variables. - -Example: For mismatched error response - -.. code-block:: yaml - - - name: fetch logs from remote host - cisco.ios.ios_command: - commands: - - show logging - - -Playbook run output: - -.. code-block:: console - - TASK [first fetch logs] ******************************************************** - fatal: [ios01]: FAILED! => { - "changed": false, - "msg": "RF Name:\r\n\r\n <--nsip--> - \"IPSEC-3-REPLAY_ERROR: Test log\"\r\n*Aug 1 08:36:18.483: %SYS-7-USERLOG_DEBUG: - Message from tty578(user id: ansible): test\r\nan-ios-02#"} - -Suggestions to resolve: - -Modify the error regex for individual task. - -.. code-block:: yaml - - - name: fetch logs from remote host - cisco.ios.ios_command: - commands: - - show logging - vars: - ansible_terminal_stderr_re: - - pattern: 'connection timed out' - flags: 're.I' - -The terminal plugin regex options ``ansible_terminal_stderr_re`` and ``ansible_terminal_stdout_re`` have -``pattern`` and ``flags`` as keys. The value of the ``flags`` key should be a value that is accepted by -the ``re.compile`` python method. - - -Intermittent failure while using ``ansible.netcommon.network_cli`` connection type due to slower network or remote target host ----------------------------------------------------------------------------------------------------------------------------------- - -In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration option is added to control -the number of attempts to connect to a remote host. The default number of attempts is three. -After every retry attempt the delay between retries is increased by power of 2 in seconds until either the -maximum attempts are exhausted or either the ``persistent_command_timeout`` or ``persistent_connect_timeout`` timers are triggered. - -To make this a global setting, add the following to your ``ansible.cfg`` file: - -.. code-block:: ini - - [persistent_connection] - network_cli_retries = 5 diff --git a/docs/docsite/rst/network/user_guide/network_resource_modules.rst b/docs/docsite/rst/network/user_guide/network_resource_modules.rst deleted file mode 100644 index 1d048f5a41f..00000000000 --- a/docs/docsite/rst/network/user_guide/network_resource_modules.rst +++ /dev/null @@ -1,196 +0,0 @@ -.. _resource_modules: - -************************ -Network Resource Modules -************************ - -Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices. - - -.. contents:: - :local: - -Network resource module states -=============================== - -You use the network resource modules by assigning a state to what you want the module to do. The resource modules support the following states: - -merged - Ansible merges the on-device configuration with the provided configuration in the task. - -replaced - Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task. - -overridden - Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration). - -deleted - Ansible deletes the on-device configuration subsection and restores any default settings. - -gathered - Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result. - -rendered - Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline. - -parsed - Ansible parses the configuration from the ``running_config`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline. - -Using network resource modules -============================== - -This example configures the L3 interface resource on a Cisco IOS device, based on different state settings. - - .. code-block:: yaml - - - name: configure l3 interface - cisco.ios.ios_l3_interfaces: - config: "{{ config }}" - state: - -The following table shows an example of how an initial resource configuration changes with this task for different states. - -+-----------------------------------------+------------------------------------+-----------------------------------------+ -| Resource starting configuration | task-provided configuration (YAML) | Final resource configuration on device | -+=========================================+====================================+=========================================+ -| .. code-block:: text | .. code-block:: yaml | *merged* | -| | | .. code-block:: text | -| interface loopback100 | config: | | -| ip address 10.10.1.100 255.255.255.0 | - ipv6: | interface loopback100 | -| ipv6 address FC00:100/64 | - address: fc00::100/64 | ip address 10.10.1.100 255.255.255.0| -| | - address: fc00::101/64 | ipv6 address FC00:100/64 | -| | name: loopback100 | ipv6 address FC00:101/64 | -| | +-----------------------------------------+ -| | | *replaced* | -| | | .. code-block:: text | -| | | | -| | | interface loopback100 | -| | | no ip address | -| | | ipv6 address FC00:100/64 | -| | | ipv6 address FC00:101/64 | -| | +-----------------------------------------+ -| | | *overridden* | -| | | Incorrect use case. This would remove | -| | | all interfaces from the device | -| | | (including the mgmt interface) except | -| | | the configured loopback100 | -| | +-----------------------------------------+ -| | | *deleted* | -| | | .. code-block:: text | -| | | | -| | | interface loopback100 | -| | | no ip address | -+-----------------------------------------+------------------------------------+-----------------------------------------+ - -Network resource modules return the following details: - -* The *before* state - the existing resource configuration before the task was executed. -* The *after* state - the new resource configuration that exists on the network device after the task was executed. -* Commands - any commands configured on the device. - -.. code-block:: yaml - - ok: [nxos101] => - result: - after: - contact: IT Support - location: Room E, Building 6, Seattle, WA 98134 - users: - - algorithm: md5 - group: network-admin - localized_key: true - password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - privacy_password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - username: admin - before: - contact: IT Support - location: Room E, Building 5, Seattle HQ - users: - - algorithm: md5 - group: network-admin - localized_key: true - password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - privacy_password: '0x73fd9a2cc8c53ed3dd4ed8f4ff157e69' - username: admin - changed: true - commands: - - snmp-server location Room E, Building 6, Seattle, WA 98134 - failed: false - - -Example: Verifying the network device configuration has not changed -==================================================================== - -The following playbook uses the :ref:`arista.eos.eos_l3_interfaces ` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`arista.eos.eos_facts ` directly to the ``arista.eos.eos_l3_interfaces`` module. - - -.. code-block:: yaml - - - name: Example of facts being pushed right back to device. - hosts: arista - gather_facts: false - tasks: - - name: grab arista eos facts - arista.eos.eos_facts: - gather_subset: min - gather_network_resources: l3_interfaces - - - name: Ensure that the IP address information is accurate. - arista.eos.eos_l3_interfaces: - config: "{{ ansible_network_resources['l3_interfaces'] }}" - register: result - - - name: Ensure config did not change. - assert: - that: not result.changed - -Example: Acquiring and updating VLANs on a network device -========================================================== - -This example shows how you can use resource modules to: - -#. Retrieve the current configuration on a network device. -#. Save that configuration locally. -#. Update that configuration and apply it to the network device. - -This example uses the ``cisco.ios.ios_vlans`` resource module to retrieve and update the VLANs on an IOS device. - -1. Retrieve the current IOS VLAN configuration: - -.. code-block:: yaml - - - name: Gather VLAN information as structured data - cisco.ios.ios_facts: - gather_subset: - - '!all' - - '!min' - gather_network_resources: - - 'vlans' - -2. Store the VLAN configuration locally: - -.. code-block:: yaml - - - name: Store VLAN facts to host_vars - copy: - content: "{{ ansible_network_resources | to_nice_yaml }}" - dest: "{{ playbook_dir }}/host_vars/{{ inventory_hostname }}" - -3. Modify the stored file to update the VLAN configuration locally. - -4. Merge the updated VLAN configuration with the existing configuration on the device: - -.. code-block:: yaml - - - name: Make VLAN config changes by updating stored facts on the controller. - cisco.ios.ios_vlans: - config: "{{ vlans }}" - state: merged - tags: update_config - -.. seealso:: - - `Network Features in Ansible 2.9 `_ - A introductory blog post on network resource modules. - `Deep Dive into Network Resource Modules `_ - A deeper dive presentation into network resource modules. diff --git a/docs/docsite/rst/network/user_guide/network_working_with_command_output.rst b/docs/docsite/rst/network/user_guide/network_working_with_command_output.rst deleted file mode 100644 index 6215df97efe..00000000000 --- a/docs/docsite/rst/network/user_guide/network_working_with_command_output.rst +++ /dev/null @@ -1,126 +0,0 @@ -.. _networking_working_with_command_output: - -********************************************************** -Working with command output and prompts in network modules -********************************************************** - -.. contents:: - :local: - -Conditionals in networking modules -=================================== - -Ansible allows you to use conditionals to control the flow of your playbooks. Ansible networking command modules use the following unique conditional statements. - -* ``eq`` - Equal -* ``neq`` - Not equal -* ``gt`` - Greater than -* ``ge`` - Greater than or equal -* ``lt`` - Less than -* ``le`` - Less than or equal -* ``contains`` - Object contains specified item - - -Conditional statements evaluate the results from the commands that are -executed remotely on the device. Once the task executes the command -set, the ``wait_for`` argument can be used to evaluate the results before -returning control to the Ansible playbook. - -For example: - -.. code-block:: yaml - - --- - - name: wait for interface to be admin enabled - arista.eos.eos_command: - commands: - - show interface Ethernet4 | json - wait_for: - - "result[0].interfaces.Ethernet4.interfaceStatus eq connected" - -In the above example task, the command :code:`show interface Ethernet4 | json` -is executed on the remote device and the results are evaluated. If -the path -:code:`(result[0].interfaces.Ethernet4.interfaceStatus)` is not equal to -"connected", then the command is retried. This process continues -until either the condition is satisfied or the number of retries has -expired (by default, this is 10 retries at 1 second intervals). - -The commands module can also evaluate more than one set of command -results in an interface. For instance: - -.. code-block:: yaml - - --- - - name: wait for interfaces to be admin enabled - arista.eos.eos_command: - commands: - - show interface Ethernet4 | json - - show interface Ethernet5 | json - wait_for: - - "result[0].interfaces.Ethernet4.interfaceStatus eq connected" - - "result[1].interfaces.Ethernet5.interfaceStatus eq connected" - -In the above example, two commands are executed on the -remote device, and the results are evaluated. By specifying the result -index value (0 or 1), the correct result output is checked against the -conditional. - -The ``wait_for`` argument must always start with result and then the -command index in ``[]``, where ``0`` is the first command in the commands list, -``1`` is the second command, ``2`` is the third and so on. - - -Handling prompts in network modules -=================================== - -Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`cisco.ios.ios_command ` and :ref:`cisco.nxos.nxos_command ` can handle this with a ``prompt`` parameter. - -.. note:: - - ``prompt`` is a Python regex. If you add special characters such as ``?`` in the ``prompt`` value, the prompt won't match and you will get a timeout. To avoid this, ensure that the ``prompt`` value is a Python regex that matches the actual device prompt. Any special characters must be handled correctly in the ``prompt`` regex. - -You can also use the :ref:`ansible.netcommon.cli_command ` to handle multiple prompts. - -.. code-block:: yaml - - --- - - name: multiple prompt, multiple answer (mandatory check for all prompts) - ansible.netcommon.cli_command: - command: "copy sftp sftp://user@host//user/test.img" - check_all: True - prompt: - - "Confirm download operation" - - "Password" - - "Do you want to change that to the standby image" - answer: - - 'y' - - - - 'y' - -You must list the prompt and the answers in the same order (that is, prompt[0] is answered by answer[0]). - -In the above example, ``check_all: True`` ensures that the task gives the matching answer to each prompt. Without that setting, a task with multiple prompts would give the first answer to every prompt. - -In the following example, the second answer would be ignored and ``y`` would be the answer given to both prompts. That is, this task only works because both answers are identical. Also notice again that ``prompt`` must be a Python regex, which is why the ``?`` is escaped in the first prompt. - -.. code-block:: yaml - - --- - - name: reboot ios device - ansible.netcommon.cli_command: - command: reload - prompt: - - Save\? - - confirm - answer: - - y - - y - -.. seealso:: - - `Rebooting network devices with Ansible `_ - Examples using ``wait_for``, ``wait_for_connection``, and ``prompt`` for network devices. - - `Deep dive on cli_command `_ - Detailed overview of how to use the ``cli_command``. diff --git a/docs/docsite/rst/network/user_guide/platform_ce.rst b/docs/docsite/rst/network/user_guide/platform_ce.rst deleted file mode 100644 index 194917482c1..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_ce.rst +++ /dev/null @@ -1,213 +0,0 @@ -.. _ce_platform_options: - -*************************************** -CloudEngine OS Platform Options -*************************************** - -CloudEngine CE OS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NETCONF - - - ==================== ========================================== ========================= - Protocol SSH XML over SSH - - Credentials uses SSH keys / SSH-agent if present uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password accepts ``-u myuser -k`` if using password - - Indirect Access via a bastion (jump host) via a bastion (jump host) - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.netconf`` - - |enable_mode| not supported by ce OS not supported by ce OS - - Returned Data Format Refer to individual module documentation Refer to individual module documentation - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` or ``ansible_connection=ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI inventory ``[ce:vars]`` --------------------------------------- - -.. code-block:: yaml - - [ce:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=community.network.ce - ansible_user=myuser - ansible_password=!vault... - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords via environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve CE OS version - community.network.ce_command: - commands: display version - when: ansible_network_os == 'community.network.ce' - - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the CloudEngine OS device(s) - -To enable NETCONF on a new switch using Ansible, use the ``community.network.ce_config`` module with the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - community.network.ce_config: - lines: - - snetconf server enable - when: ansible_network_os == 'community.network.ce' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[ce:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [ce:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=community.network.ce - ansible_user=myuser - ansible_password=!vault | - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Create a vlan, id is 50(ce) - community.network.ce_vlan: - vlan_id: 50 - name: WEB - when: ansible_network_os == 'community.network.ce' - - -Notes -======================== - -Modules that work with ``ansible.netcommon.network_cli`` ---------------------------------------------------------- - -.. code-block:: yaml - - community.network.ce_acl_interface - community.network.ce_command - community.network.ce_config - community.network.ce_evpn_bgp - community.network.ce_evpn_bgp_rr - community.network.ce_evpn_global - community.network.ce_facts - community.network.ce_mlag_interface - community.network.ce_mtu - community.network.ce_netstream_aging - community.network.ce_netstream_export - community.network.ce_netstream_global - community.network.ce_netstream_template - community.network.ce_ntp_auth - community.network.ce_rollback - community.network.ce_snmp_contact - community.network.ce_snmp_location - community.network.ce_snmp_traps - community.network.ce_startup - community.network.ce_stp - community.network.ce_vxlan_arp - community.network.ce_vxlan_gateway - community.network.ce_vxlan_global - - -Modules that work with ``ansible.netcommon.netconf`` ------------------------------------------------------ - -.. code-block:: yaml - - community.network.ce_aaa_server - community.network.ce_aaa_server_host - community.network.ce_acl - community.network.ce_acl_advance - community.network.ce_bfd_global - community.network.ce_bfd_session - community.network.ce_bfd_view - community.network.ce_bgp - community.network.ce_bgp_af - community.network.ce_bgp_neighbor - community.network.ce_bgp_neighbor_af - community.network.ce_dldp - community.network.ce_dldp_interface - community.network.ce_eth_trunk - community.network.ce_evpn_bd_vni - community.network.ce_file_copy - community.network.ce_info_center_debug - community.network.ce_info_center_global - community.network.ce_info_center_log - community.network.ce_info_center_trap - community.network.ce_interface - community.network.ce_interface_ospf - community.network.ce_ip_interface - community.network.ce_lacp - community.network.ce_link_status - community.network.ce_lldp - community.network.ce_lldp_interface - community.network.ce_mlag_config - community.network.ce_netconf - community.network.ce_ntp - community.network.ce_ospf - community.network.ce_ospf_vrf - community.network.ce_reboot - community.network.ce_sflow - community.network.ce_snmp_community - community.network.ce_snmp_target_host - community.network.ce_snmp_user - community.network.ce_static_route - community.network.ce_static_route_bfd - community.network.ce_switchport - community.network.ce_vlan - community.network.ce_vrf - community.network.ce_vrf_af - community.network.ce_vrf_interface - community.network.ce_vrrp - community.network.ce_vxlan_tunnel - community.network.ce_vxlan_vap - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_cnos.rst b/docs/docsite/rst/network/user_guide/platform_cnos.rst deleted file mode 100644 index 00448474072..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_cnos.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _cnos_platform_options: - -*************************************** -CNOS Platform Options -*************************************** - -CNOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on CNOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/cnos.yml`` --------------------------------------------------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.cnos - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve CNOS OS version - community.network.cnos_command: - commands: show version - when: ansible_network_os == 'community.network.cnos' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_dellos10.rst b/docs/docsite/rst/network/user_guide/platform_dellos10.rst deleted file mode 100644 index cdffdd5545a..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_dellos10.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _dellos10_platform_options: - -*************************************** -Dell OS10 Platform Options -*************************************** - -The `dellemc.os10 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS10 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/dellos10.yml`` ---------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: dellemc.os10.os10 - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (dellos10) - dellemc.os10.os10_config: - backup: yes - register: backup_dellos10_location - when: ansible_network_os == 'dellemc.os10.os10' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_dellos6.rst b/docs/docsite/rst/network/user_guide/platform_dellos6.rst deleted file mode 100644 index ae8083de8d9..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_dellos6.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _dellos6_platform_options: - -*************************************** -Dell OS6 Platform Options -*************************************** - -The `dellemc.os6 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS6 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/dellos6.yml`` --------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: dellemc.os6.os6 - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (dellos6) - dellemc.os6.os6_config: - backup: yes - register: backup_dellso6_location - when: ansible_network_os == 'dellemc.os6.os6' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_dellos9.rst b/docs/docsite/rst/network/user_guide/platform_dellos9.rst deleted file mode 100644 index ac1f52f63db..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_dellos9.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _dellos9_platform_options: - -*************************************** -Dell OS9 Platform Options -*************************************** - -The `dellemc.os9 `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS9 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/dellos9.yml`` --------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: dellemc.os9.os9 - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (dellos9) - dellemc.os9.os9_config: - backup: yes - register: backup_dellos9_location - when: ansible_network_os == 'dellemc.os9.os9' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_enos.rst b/docs/docsite/rst/network/user_guide/platform_enos.rst deleted file mode 100644 index 3cf17c30eee..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_enos.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _enos_platform_options: - -*************************************** -ENOS Platform Options -*************************************** - -ENOS is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ENOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -+---------------------------+-----------------------------------------------+ - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -================================================================================ - -Example CLI ``group_vars/enos.yml`` --------------------------------------------------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.enos - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve ENOS OS version - community.network.enos_command: - commands: show version - when: ansible_network_os == 'community.network.enos' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_eos.rst b/docs/docsite/rst/network/user_guide/platform_eos.rst deleted file mode 100644 index 588118ef27c..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_eos.rst +++ /dev/null @@ -1,140 +0,0 @@ -.. _eos_platform_options: - -*************************************** -EOS Platform Options -*************************************** - -The `Arista EOS `_ collection supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== =========================== - .. CLI eAPI - ==================== ========================================== =========================== - Protocol SSH HTTP(S) - - Credentials uses SSH keys / SSH-agent if present uses HTTPS certificates if - present - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) through a web proxy - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.httpapi`` - - - |enable_mode| supported: |br| supported: |br| - - * use ``ansible_become: yes`` * ``httpapi`` - with ``ansible_become_method: enable`` uses ``ansible_become: yes`` - with ``ansible_become_method: enable`` - - Returned Data Format ``stdout[0].`` ``stdout[0].messages[0].`` - ==================== ========================================== =========================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/eos.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: arista.eos.eos - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (eos) - arista.eos.eos_config: - backup: yes - register: backup_eos_location - when: ansible_network_os == 'arista.eos.eos' - - - -Using eAPI in Ansible -===================== - -Enabling eAPI -------------- - -Before you can use eAPI to connect to a switch, you must enable eAPI. To enable eAPI on a new switch with Ansible, use the ``arista.eos.eos_eapi`` module through the CLI connection. Set up ``group_vars/eos.yml`` just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable eAPI - arista.eos.eos_eapi: - enable_http: yes - enable_https: yes - become: true - become_method: enable - when: ansible_network_os == 'arista.eos.eos' - -You can find more options for enabling HTTP/HTTPS connections in the :ref:`arista.eos.eos_eapi ` module documentation. - -Once eAPI is enabled, change your ``group_vars/eos.yml`` to use the eAPI connection. - -Example eAPI ``group_vars/eos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.httpapi - ansible_network_os: arista.eos.eos - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - proxy_env: - http_proxy: http://proxy.example.com:8080 - -- If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration. -- If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``. - - -Example eAPI task ------------------ - -.. code-block:: yaml - - - name: Backup current switch config (eos) - arista.eos.eos_config: - backup: yes - register: backup_eos_location - environment: "{{ proxy_env }}" - when: ansible_network_os == 'arista.eos.eos' - -In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module in the task. - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_eric_eccli.rst b/docs/docsite/rst/network/user_guide/platform_eric_eccli.rst deleted file mode 100644 index 8e8bef0178c..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_eric_eccli.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _eic_eccli_platform_options: - -*************************************** -ERIC_ECCLI Platform Options -*************************************** - -Extreme ERIC_ECCLI is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on ERIC_ECCLI in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported by ERIC_ECCLI - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -ERIC_ECCLI does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/eric_eccli.yml`` ------------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.eric_eccli - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: run show version on remote devices (eric_eccli) - community.network.eric_eccli_command: - commands: show version - when: ansible_network_os == 'community.network.eric_eccli' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_exos.rst b/docs/docsite/rst/network/user_guide/platform_exos.rst deleted file mode 100644 index 2e74be53f33..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_exos.rst +++ /dev/null @@ -1,108 +0,0 @@ -.. _exos_platform_options: - -*************************************** -EXOS Platform Options -*************************************** - -Extreme EXOS is part of the `community.network `_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI EXOS-API - ==================== ========================================== ========================= - Protocol SSH HTTP(S) - - Credentials uses SSH keys / SSH-agent if present uses HTTPS certificates if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) through a web proxy - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.httpapi`` - - |enable_mode| not supported by EXOS not supported by EXOS - - Returned Data Format ``stdout[0].`` ``stdout[0].messages[0].`` - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -EXOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/exos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.exos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve EXOS OS version - community.network.exos_command: - commands: show version - when: ansible_network_os == 'community.network.exos' - - - -Using EXOS-API in Ansible -========================= - -Example EXOS-API ``group_vars/exos.yml`` ----------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.httpapi - ansible_network_os: community.network.exos - ansible_user: myuser - ansible_password: !vault... - proxy_env: - http_proxy: http://proxy.example.com:8080 - -- If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration. -- If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``. - - -Example EXOS-API task ---------------------- - -.. code-block:: yaml - - - name: Retrieve EXOS OS version - community.network.exos_command: - commands: show version - when: ansible_network_os == 'community.network.exos' - -In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task. - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_frr.rst b/docs/docsite/rst/network/user_guide/platform_frr.rst deleted file mode 100644 index 026125098c5..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_frr.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _frr_platform_options: - -*************************************** -FRR Platform Options -*************************************** - -The `FRR `_ collection supports the ``ansible.netcommon.network_cli`` connection. This section provides details on how to use this connection for Free Range Routing (FRR). - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/frr.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: frr.frr.frr - ansible_user: frruser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - -- The ``ansible_user`` should be a part of the ``frrvty`` group and should have the default shell set to ``/bin/vtysh``. -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Gather FRR facts - frr.frr.frr_facts: - gather_subset: - - config - - hardware - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_icx.rst b/docs/docsite/rst/network/user_guide/platform_icx.rst deleted file mode 100644 index ee87b7682bf..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_icx.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _icx_platform_options: - -*************************************** -ICX Platform Options -*************************************** - -ICX is part of the `community.network `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ICX in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` with - ``ansible_become_method: enable`` and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/icx.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.icx - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (icx) - community.network.icx_config: - backup: yes - register: backup_icx_location - when: ansible_network_os == 'community.network.icx' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_index.rst b/docs/docsite/rst/network/user_guide/platform_index.rst deleted file mode 100644 index f9a8bc5f3c7..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_index.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. _platform_options: - -**************** -Platform Options -**************** - -Some Ansible Network platforms support multiple connection types, privilege escalation (``enable`` mode), or other options. The pages in this section offer standardized guides to understanding available options on each network platform. We welcome contributions from community-maintained platforms to this section. - -.. toctree:: - :maxdepth: 2 - :caption: Platform Options - - platform_ce - platform_cnos - platform_dellos6 - platform_dellos9 - platform_dellos10 - platform_enos - platform_eos - platform_eric_eccli - platform_exos - platform_frr - platform_icx - platform_ios - platform_iosxr - platform_ironware - platform_junos - platform_meraki - platform_netvisor - platform_nos - platform_nxos - platform_routeros - platform_slxos - platform_voss - platform_vyos - platform_weos4 - platform_netconf_enabled - -.. _settings_by_platform: - -Settings by Platform -================================ - -.. raw:: html - - - -.. table:: - :name: network-platform-table - - =============================== ================================ =========== ======= ======= =========== - .. ``ansible_connection:`` settings available - ----------------------------------------------------------------- ------------------------------------------ - Network OS ``ansible_network_os:`` network_cli netconf httpapi local - =============================== ================================ =========== ======= ======= =========== - `Arista EOS`_ `[†]`_ ``arista.eos.eos`` ✓ ✓ ✓ - `Ciena SAOS6`_ ``ciena.saos6.saos6`` ✓ ✓ - `Cisco ASA`_ `[†]`_ ``cisco.asa.asa`` ✓ ✓ - `Cisco IOS`_ `[†]`_ ``cisco.ios.ios`` ✓ ✓ - `Cisco IOS XR`_ `[†]`_ ``cisco.iosxr.iosxr`` ✓ ✓ - `Cisco NX-OS`_ `[†]`_ ``cisco.nxos.nxos`` ✓ ✓ ✓ - `Cloudengine OS`_ ``community.network.ce`` ✓ ✓ ✓ - `Dell OS6`_ ``dellemc.os6.os6`` ✓ ✓ - `Dell OS9`_ ``dellemc.os9.os9`` ✓ ✓ - `Dell OS10`_ ``dellemc.os10.os10`` ✓ ✓ - `Ericsson ECCLI`_ ``community.network.eric_eccli`` ✓ ✓ - `Extreme EXOS`_ ``community.network.exos`` ✓ ✓ - `Extreme IronWare`_ ``community.network.ironware`` ✓ ✓ - `Extreme NOS`_ ``community.network.nos`` ✓ - `Extreme SLX-OS`_ ``community.network.slxos`` ✓ - `Extreme VOSS`_ ``community.network.voss`` ✓ - `F5 BIG-IP`_ ✓ - `F5 BIG-IQ`_ ✓ - `Junos OS`_ `[†]`_ ``junipernetworks.junos.junos`` ✓ ✓ ✓ - `Lenovo CNOS`_ ``community.network.cnos`` ✓ ✓ - `Lenovo ENOS`_ ``community.network.enos`` ✓ ✓ - `Meraki`_ ✓ - `MikroTik RouterOS`_ ``community.network.routeros`` ✓ - `Nokia SR OS`_ ✓ - `Pluribus Netvisor`_ ``community.network.netvisor`` ✓ - `Ruckus ICX`_ ``community.network.icx`` ✓ - `VyOS`_ `[†]`_ ``vyos.vyos.vyos`` ✓ ✓ - `Westermo WeOS 4`_ ``community.network.weos4`` ✓ - OS that supports Netconf `[†]`_ ```` ✓ ✓ - =============================== ================================ =========== ======= ======= =========== - -.. _Arista EOS: https://galaxy.ansible.com/arista/eos -.. _Ciena SAOS6: https://galaxy.ansible.com/ciena/saos6 -.. _Cisco ASA: https://galaxy.ansible.com/cisco/asa -.. _Cisco IOS: https://galaxy.ansible.com/cisco/ios -.. _Cisco IOS XR: https://galaxy.ansible.com/cisco/iosxr -.. _Cisco NX-OS: https://galaxy.ansible.com/cisco/nxos -.. _Cloudengine OS: https://galaxy.ansible.com/community/network -.. _Dell OS6: https://github.com/ansible-collections/dellemc.os6 -.. _Dell OS9: https://github.com/ansible-collections/dellemc.os9 -.. _Dell OS10: https://galaxy.ansible.com/dellemc/os10 -.. _Ericsson ECCLI: https://galaxy.ansible.com/community/network -.. _Extreme EXOS: https://galaxy.ansible.com/community/network -.. _Extreme IronWare: https://galaxy.ansible.com/community/network -.. _Extreme NOS: https://galaxy.ansible.com/community/network -.. _Extreme SLX-OS: https://galaxy.ansible.com/community/network -.. _Extreme VOSS: https://galaxy.ansible.com/community/network -.. _F5 BIG-IP: https://galaxy.ansible.com/f5networks/f5_modules -.. _F5 BIG-IQ: https://galaxy.ansible.com/f5networks/f5_modules -.. _Junos OS: https://galaxy.ansible.com/junipernetworks/junos -.. _Lenovo CNOS: https://galaxy.ansible.com/community/network -.. _Lenovo ENOS: https://galaxy.ansible.com/community/network -.. _Meraki: https://galaxy.ansible.com/cisco/meraki -.. _MikroTik RouterOS: https://galaxy.ansible.com/community/network -.. _Nokia SR OS: https://galaxy.ansible.com/community/network -.. _Pluribus Netvisor: https://galaxy.ansible.com/community/network -.. _Ruckus ICX: https://galaxy.ansible.com/community/network -.. _VyOS: https://galaxy.ansible.com/vyos/vyos -.. _Westermo WeOS 4: https://galaxy.ansible.com/community/network -.. _`[†]`: - -**[†]** Maintained by Ansible Network Team diff --git a/docs/docsite/rst/network/user_guide/platform_ios.rst b/docs/docsite/rst/network/user_guide/platform_ios.rst deleted file mode 100644 index c7bd9ab768b..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_ios.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _ios_platform_options: - -*************************************** -IOS Platform Options -*************************************** - -The `Cisco IOS `_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` with - ``ansible_become_method: enable`` and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/ios.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: cisco.ios.ios - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (ios) - cisco.ios.ios_config: - backup: yes - register: backup_ios_location - when: ansible_network_os == 'cisco.ios.ios' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_iosxr.rst b/docs/docsite/rst/network/user_guide/platform_iosxr.rst deleted file mode 100644 index 30e49951c3c..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_iosxr.rst +++ /dev/null @@ -1,130 +0,0 @@ -.. _iosxr_platform_options: - -*************************************** -IOS-XR Platform Options -*************************************** - -The `Cisco IOS-XR collection `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NETCONF - - only for modules ``iosxr_banner``, - ``iosxr_interface``, ``iosxr_logging``, - ``iosxr_system``, ``iosxr_user`` - ==================== ========================================== ========================= - Protocol SSH XML over SSH - - Credentials uses SSH keys / SSH-agent if present uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) by a bastion (jump host) - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.netconf`` - - |enable_mode| not supported not supported - - Returned Data Format Refer to individual module documentation Refer to individual module documentation - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead. - -Using CLI in Ansible -==================== - -Example CLI inventory ``[iosxr:vars]`` --------------------------------------- - -.. code-block:: yaml - - [iosxr:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=cisco.iosxr.iosxr - ansible_user=myuser - ansible_password=!vault... - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve IOS-XR version - cisco.iosxr.iosxr_command: - commands: show version - when: ansible_network_os == 'cisco.iosxr.iosxr' - - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the Cisco IOS-XR device(s) - -To enable NETCONF on a new switch via Ansible, use the ``cisco.iosxr.iosxr_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - cisco.iosxr.iosxr_netconf: - when: ansible_network_os == 'cisco.iosxr.iosxr' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[iosxr:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [iosxr:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=cisco.iosxr.iosxr - ansible_user=myuser - ansible_password=!vault | - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Configure hostname and domain-name - cisco.iosxr.iosxr_system: - hostname: iosxr01 - domain_name: test.example.com - domain_search: - - ansible.com - - redhat.com - - cisco.com - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_ironware.rst b/docs/docsite/rst/network/user_guide/platform_ironware.rst deleted file mode 100644 index dbb2c412269..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_ironware.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _ironware_platform_options: - -*************************************** -IronWare Platform Options -*************************************** - -IronWare is part of the `community.network `_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IronWare in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/mlx.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.ironware - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (ironware) - community.network.ironware_config: - backup: yes - register: backup_ironware_location - when: ansible_network_os == 'community.network.ironware' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_junos.rst b/docs/docsite/rst/network/user_guide/platform_junos.rst deleted file mode 100644 index 08cf8fc0d11..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_junos.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. _junos_platform_options: - -*************************************** -Junos OS Platform Options -*************************************** - -The `Juniper Junos OS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NETCONF - - ``junos_netconf`` & ``junos_command`` all modules except ``junos_netconf``, - modules only which enables NETCONF - ==================== ========================================== ========================= - Protocol SSH XML over SSH - - Credentials uses SSH keys / SSH-agent if present uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) by a bastion (jump host) - - Connection Settings ``ansible_connection: ``ansible_connection: - ``ansible.netcommon.network_cli`` ``ansible.netcommon.netconf`` - - |enable_mode| not supported by Junos OS not supported by Junos OS - - Returned Data Format ``stdout[0].`` * json: ``result[0]['software-information'][0]['host-name'][0]['data'] foo lo0`` - * text: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0`` - * xml: ``result[1].rpc-reply.interface-information[0].physical-interface[0].name[0].data foo lo0`` - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead. - -Using CLI in Ansible -==================== - -Example CLI inventory ``[junos:vars]`` --------------------------------------- - -.. code-block:: yaml - - [junos:vars] - ansible_connection=ansible.netcommon.network_cli - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault... - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve Junos OS version - junipernetworks.junos.junos_command: - commands: show version - when: ansible_network_os == 'junipernetworks.junos.junos' - - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the Junos OS device(s) - -To enable NETCONF on a new switch through Ansible, use the ``junipernetworks.junos.junos_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - junipernetworks.junos.junos_netconf: - when: ansible_network_os == 'junipernetworks.junos.junos' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[junos:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [junos:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault | - ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Backup current switch config (junos) - junipernetworks.junos.junos_config: - backup: yes - register: backup_junos_location - when: ansible_network_os == 'junipernetworks.junos.junos' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_meraki.rst b/docs/docsite/rst/network/user_guide/platform_meraki.rst deleted file mode 100644 index e51ca5b9120..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_meraki.rst +++ /dev/null @@ -1,44 +0,0 @@ -.. _meraki_platform_options: - -*************************************** -Meraki Platform Options -*************************************** - -The `cisco.meraki `_ collection only supports the ``local`` connection type at this time. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. Dashboard API - ==================== ========================================== - Protocol HTTP(S) - - Credentials uses API key from Dashboard - - Connection Settings ``ansible_connection: localhost`` - - Returned Data Format ``data.`` - ==================== ========================================== - - -Example Meraki task -------------------- - -.. code-block:: yaml - - cisco.meraki.meraki_organization: - auth_key: abc12345 - org_name: YourOrg - state: present - delegate_to: localhost - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_netconf_enabled.rst b/docs/docsite/rst/network/user_guide/platform_netconf_enabled.rst deleted file mode 100644 index e481ed62735..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_netconf_enabled.rst +++ /dev/null @@ -1,133 +0,0 @@ -.. _netconf_enabled_platform_options: - -*************************************** -Netconf enabled Platform Options -*************************************** - -This page offers details on how the netconf connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ -.. table:: - :class: documentation-table - - ==================== ========================================== - .. NETCONF - - all modules except ``junos_netconf``, - which enables NETCONF - ==================== ========================================== - Protocol XML over SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access through a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.netconf`` - ==================== ========================================== - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` instead. - -Using NETCONF in Ansible -======================== - -Enabling NETCONF ----------------- - -Before you can use NETCONF to connect to a switch, you must: - -- install the ``ncclient`` Python package on your control node(s) with ``pip install ncclient`` -- enable NETCONF on the Junos OS device(s) - -To enable NETCONF on a new switch through Ansible, use the platform specific module through the CLI connection or set it manually. -For example set up your platform-level variables just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NETCONF - connection: ansible.netcommon.network_cli - junipernetworks.junos.junos_netconf: - when: ansible_network_os == 'junipernetworks.junos.junos' - -Once NETCONF is enabled, change your variables to use the NETCONF connection. - -Example NETCONF inventory ``[junos:vars]`` ------------------------------------------- - -.. code-block:: yaml - - [junos:vars] - ansible_connection=ansible.netcommon.netconf - ansible_network_os=junipernetworks.junos.junos - ansible_user=myuser - ansible_password=!vault | - - -Example NETCONF task --------------------- - -.. code-block:: yaml - - - name: Backup current switch config - junipernetworks.junos.netconf_config: - backup: yes - register: backup_junos_location - -Example NETCONF task with configurable variables ------------------------------------------------- - -.. code-block:: yaml - - - name: configure interface while providing different private key file path - junipernetworks.junos.netconf_config: - backup: yes - register: backup_junos_location - vars: - ansible_private_key_file: /home/admin/.ssh/newprivatekeyfile - -Note: For netconf connection plugin configurable variables see :ref:`ansible.netcommon.netconf `. - -Bastion/Jumphost configuration ------------------------------- -To use a jump host to connect to a NETCONF enabled device you must set the ``ANSIBLE_NETCONF_SSH_CONFIG`` environment variable. - -``ANSIBLE_NETCONF_SSH_CONFIG`` can be set to either: - - 1 or TRUE (to trigger the use of the default SSH config file ~/.ssh/config) - - The absolute path to a custom SSH config file. - -The SSH config file should look something like: - -.. code-block:: ini - - Host * - proxycommand ssh -o StrictHostKeyChecking=no -W %h:%p jumphost-username@jumphost.fqdn.com - StrictHostKeyChecking no - -Authentication for the jump host must use key based authentication. - -You can either specify the private key used in the SSH config file: - -.. code-block:: ini - - IdentityFile "/absolute/path/to/private-key.pem" - -Or you can use an ssh-agent. - -ansible_network_os auto-detection ---------------------------------- - -If ``ansible_network_os`` is not specified for a host, then Ansible will attempt to automatically detect what ``network_os`` plugin to use. - -``ansible_network_os`` auto-detection can also be triggered by using ``auto`` as the ``ansible_network_os``. (Note: Previously ``default`` was used instead of ``auto``). - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_netvisor.rst b/docs/docsite/rst/network/user_guide/platform_netvisor.rst deleted file mode 100644 index 648e9c1cad6..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_netvisor.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _netvisor_platform_options: - -********************************** -Pluribus NETVISOR Platform Options -********************************** - -Pluribus NETVISOR Ansible is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on NETVISOR in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported by NETVISOR - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -Pluribus NETVISOR does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/netvisor.yml`` ---------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.netcommon.netvisor - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Create access list - community.network.pn_access_list: - pn_name: "foo" - pn_scope: "local" - state: "present" - register: acc_list - when: ansible_network_os == 'community.network.netvisor' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_nos.rst b/docs/docsite/rst/network/user_guide/platform_nos.rst deleted file mode 100644 index 6bc244c8d9b..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_nos.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. _nos_platform_options: - -*************************************** -NOS Platform Options -*************************************** - -Extreme NOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on NOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: community.netcommon.network_cli`` - - |enable_mode| not supported by NOS - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -NOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/nos.yml`` ----------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.nos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Get version information (nos) - community.network.nos_command: - commands: "show version" - register: show_ver - when: ansible_network_os == 'community.network.nos' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_nxos.rst b/docs/docsite/rst/network/user_guide/platform_nxos.rst deleted file mode 100644 index 3794cfc3313..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_nxos.rst +++ /dev/null @@ -1,166 +0,0 @@ -.. _nxos_platform_options: - -*************************************** -NXOS Platform Options -*************************************** - -The `Cisco NXOS `_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== ========================= - .. CLI NX-API - ==================== ========================================== ========================= - Protocol SSH HTTP(S) - - Credentials uses SSH keys / SSH-agent if present uses HTTPS certificates if - present - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) by a web proxy - - Connection Settings ``ansible_connection:`` ``ansible_connection:`` - ``ansible.netcommon.network_cli`` ``ansible.netcommon.httpapi`` - - |enable_mode| supported: use ``ansible_become: yes`` not supported by NX-API - with ``ansible_become_method: enable`` - and ``ansible_become_password:`` - - Returned Data Format ``stdout[0].`` ``stdout[0].messages[0].`` - ==================== ========================================== ========================= - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) |br| supported as of 2.5.3 - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/nxos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: cisco.nxos.nxos - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (nxos) - cisco.nxos.nxos_config: - backup: yes - register: backup_nxos_location - when: ansible_network_os == 'cisco.nxos.nxos' - - - -Using NX-API in Ansible -======================= - -Enabling NX-API ---------------- - -Before you can use NX-API to connect to a switch, you must enable NX-API. To enable NX-API on a new switch through Ansible, use the ``nxos_nxapi`` module through the CLI connection. Set up group_vars/nxos.yml just like in the CLI example above, then run a playbook task like this: - -.. code-block:: yaml - - - name: Enable NX-API - cisco.nxos.nxos_nxapi: - enable_http: yes - enable_https: yes - when: ansible_network_os == 'cisco.nxos.nxos' - -To find out more about the options for enabling HTTP/HTTPS and local http see the :ref:`nxos_nxapi ` module documentation. - -Once NX-API is enabled, change your ``group_vars/nxos.yml`` to use the NX-API connection. - -Example NX-API ``group_vars/nxos.yml`` --------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.httpapi - ansible_network_os: cisco.nxos.nxos - ansible_user: myuser - ansible_password: !vault... - proxy_env: - http_proxy: http://proxy.example.com:8080 - -- If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration. -- If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``. - - -Example NX-API task -------------------- - -.. code-block:: yaml - - - name: Backup current switch config (nxos) - cisco.nxos.nxos_config: - backup: yes - register: backup_nxos_location - environment: "{{ proxy_env }}" - when: ansible_network_os == 'cisco.nxos.nxos' - -In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task. - -.. include:: shared_snippets/SSH_warning.txt - -Cisco Nexus platform support matrix -=================================== - -The following platforms and software versions have been certified by Cisco to work with this version of Ansible. - -.. table:: Platform / Software Minimum Requirements - :align: center - - =================== ===================== - Supported Platforms Minimum NX-OS Version - =================== ===================== - Cisco Nexus N3k 7.0(3)I2(5) and later - Cisco Nexus N9k 7.0(3)I2(5) and later - Cisco Nexus N5k 7.3(0)N1(1) and later - Cisco Nexus N6k 7.3(0)N1(1) and later - Cisco Nexus N7k 7.3(0)D1(1) and later - Cisco Nexus MDS 8.4(1) and later (Please see individual module documentation for compatibility) - =================== ===================== - -.. table:: Platform Models - :align: center - - ======== ============================================== - Platform Description - ======== ============================================== - N3k Support includes N30xx, N31xx and N35xx models - N5k Support includes all N5xxx models - N6k Support includes all N6xxx models - N7k Support includes all N7xxx models - N9k Support includes all N9xxx models - MDS Support includes all MDS 9xxx models - ======== ============================================== - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_routeros.rst b/docs/docsite/rst/network/user_guide/platform_routeros.rst deleted file mode 100644 index ff404e6672d..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_routeros.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _routeros_platform_options: - -*************************************** -RouterOS Platform Options -*************************************** - -RouterOS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on RouterOS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.network.network_cli`` - - |enable_mode| not supported by RouterOS - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -RouterOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/routeros.yml`` ---------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.routeros - ansible_user: myuser - ansible_password: !vault... - ansible_become: yes - ansible_become_method: enable - ansible_become_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. -- If you are getting timeout errors you may want to add ``+cet1024w`` suffix to your username which will disable console colors, enable "dumb" mode, tell RouterOS not to try detecting terminal capabilities and set terminal width to 1024 columns. See article `Console login process `_ in MikroTik wiki for more information. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Display resource statistics (routeros) - community.network.routeros_command: - commands: /system resource print - register: routeros_resources - when: ansible_network_os == 'community.network.routeros' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_slxos.rst b/docs/docsite/rst/network/user_guide/platform_slxos.rst deleted file mode 100644 index 4c4145130ca..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_slxos.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _slxos_platform_options: - -*************************************** -SLX-OS Platform Options -*************************************** - -Extreme SLX-OS is part of the `community.network `_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. -This page offers details on how to use ``ansible.netcommon.network_cli`` on SLX-OS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported by SLX-OS - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -SLX-OS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/slxos.yml`` ------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.slxos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Backup current switch config (slxos) - community.network.slxos_config: - backup: yes - register: backup_slxos_location - when: ansible_network_os == 'community.network.slxos' - - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_voss.rst b/docs/docsite/rst/network/user_guide/platform_voss.rst deleted file mode 100644 index 172a0530c87..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_voss.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _voss_platform_options: - -*************************************** -VOSS Platform Options -*************************************** - -Extreme VOSS is part of the `community.network `_ collection and only supports CLI connections today. This page offers details on how to -use ``ansible.netcommon.network_cli`` on VOSS in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| supported: use ``ansible_become: yes`` - with ``ansible_become_method: enable`` - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -VOSS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/voss.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.voss - ansible_user: myuser - ansible_become: yes - ansible_become_method: enable - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve VOSS info - community.network.voss_command: - commands: show sys-info - when: ansible_network_os == 'community.network.voss' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_vyos.rst b/docs/docsite/rst/network/user_guide/platform_vyos.rst deleted file mode 100644 index f101fe778c5..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_vyos.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _vyos_platform_options: - -*************************************** -VyOS Platform Options -*************************************** - -The `VyOS `_ collection supports the ``ansible.netcommon.network_cli`` connection type. This page offers details on connection options to manage VyOS using Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: ansible.netcommon.network_cli`` - - |enable_mode| not supported - - Returned Data Format Refer to individual module documentation - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - - -The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/vyos.yml`` ------------------------------------ - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: vyos.vyos.vyos - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Retrieve VyOS version info - vyos.vyos.vyos_command: - commands: show version - when: ansible_network_os == 'vyos.vyos.vyos' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/platform_weos4.rst b/docs/docsite/rst/network/user_guide/platform_weos4.rst deleted file mode 100644 index dd5dc83290d..00000000000 --- a/docs/docsite/rst/network/user_guide/platform_weos4.rst +++ /dev/null @@ -1,88 +0,0 @@ -.. _weos4_platform_options: - -*************************************** -WeOS 4 Platform Options -*************************************** - -Westermo WeOS 4 is part of the `community.network `_ collection and only supports CLI connections. -This page offers details on how to use ``ansible.netcommon.network_cli`` on WeOS 4 in Ansible. - -.. contents:: - :local: - -Connections available -================================================================================ - -.. table:: - :class: documentation-table - - ==================== ========================================== - .. CLI - ==================== ========================================== - Protocol SSH - - Credentials uses SSH keys / SSH-agent if present - - accepts ``-u myuser -k`` if using password - - Indirect Access by a bastion (jump host) - - Connection Settings ``ansible_connection: community.netcommon.network_cli`` - - |enable_mode| not supported by WeOS 4 - - Returned Data Format ``stdout[0].`` - ==================== ========================================== - -.. |enable_mode| replace:: Enable Mode |br| (Privilege Escalation) - -WeOS 4 does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``. - -Using CLI in Ansible -==================== - -Example CLI ``group_vars/weos4.yml`` ------------------------------------- - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: community.network.weos4 - ansible_user: myuser - ansible_password: !vault... - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion01"' - - -- If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration. -- If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration. -- If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords through environment variables. - -Example CLI task ----------------- - -.. code-block:: yaml - - - name: Get version information (WeOS 4) - ansible.netcommon.cli_command: - commands: "show version" - register: show_ver - when: ansible_network_os == 'community.network.weos4' - -Example Configuration task --------------------------- - -.. code-block:: yaml - - - name: Replace configuration with file on ansible host (WeOS 4) - ansible.netcommon.cli_config: - config: "{{ lookup('file', 'westermo.conf') }}" - replace: "yes" - diff_match: exact - diff_replace: config - when: ansible_network_os == 'community.network.weos4' - -.. include:: shared_snippets/SSH_warning.txt - -.. seealso:: - - :ref:`timeout_options` diff --git a/docs/docsite/rst/network/user_guide/shared_snippets/SSH_warning.txt b/docs/docsite/rst/network/user_guide/shared_snippets/SSH_warning.txt deleted file mode 100644 index 27424f57776..00000000000 --- a/docs/docsite/rst/network/user_guide/shared_snippets/SSH_warning.txt +++ /dev/null @@ -1,2 +0,0 @@ -.. warning:: - Never store passwords in plain text. We recommend using SSH keys to authenticate SSH connections. Ansible supports ssh-agent to manage your SSH keys. If you must use passwords to authenticate SSH connections, we recommend encrypting them with :ref:`Ansible Vault `. diff --git a/docs/docsite/rst/network/user_guide/validate.rst b/docs/docsite/rst/network/user_guide/validate.rst deleted file mode 100644 index aeda1b2436a..00000000000 --- a/docs/docsite/rst/network/user_guide/validate.rst +++ /dev/null @@ -1,164 +0,0 @@ -.. _validate_data: - -************************************************* -Validate data against set criteria with Ansible -************************************************* - -The :ref:`validate ` module validates data against your predefined criteria using a validation engine. You can pull this data from a device or file, validate it against your defined criteria, and use the results to identify configuration or operational state drift and optionally take remedial action. - - -.. contents:: - :local: - -Understanding the validate plugin -================================== - -The `ansible.utils `_ collection includes the :ref:`validate ` module. - -To validate data: - -#. Pull in structured data or convert your data to structured format with the :ref:`cli_parse ` module. -#. Define the criteria to test that data against. -#. Select a validation engine and test the data to see if it is valid based on the selected criteria and validation engine. - -The structure of the data and the criteria depends on the validation engine you select. The examples here use the ``jsonschema`` validation engine provided in the `ansible.utils `_ collection.Red Hat Ansible Automation Platform subscription supports limited use if jsonschema public APIs as documented. - -Structuring the data -===================== - -You can pull previously structured data from a file, or use the :ref:`cli_parse ` module to structure your data. - -The following example fetches the operational state of some network (Cisco NXOS) interfaces and translates that state to structured data using the ``ansible.netcommon.pyats`` parser. - -.. code-block:: yaml - - --- - - hosts: nxos - connection: ansible.netcommon.network_cli - gather_facts: false - vars: - ansible_network_os: cisco.nxos.nxos - ansible_user: "changeme" - ansible_password: "changeme" - - tasks: - - name: "Fetch interface state and parse with pyats" - ansible.utils.cli_parse: - command: show interface - parser: - name: ansible.netcommon.pyats - register: nxos_pyats_show_interface - - - name: print structured interface state data - ansible.builtin.debug: - msg: "{{ nxos_pyats_show_interface['parsed'] }}" - ---- - -This results in the following structured data. - -.. code-block:: text - - ok: [nxos] => { - "changed": false, - "parsed": { - "Ethernet2/1": { - "admin_state": "down", - "auto_mdix": "off", - "auto_negotiate": false, - "bandwidth": 1000000, - "beacon": "off" - <--output omitted--> - }, - "Ethernet2/10": { - "admin_state": "down", - "auto_mdix": "off", - "auto_negotiate": false, - "bandwidth": 1000000, - "beacon": "off", - <--output omitted--> - } - } - } - -See :ref:`cli_parsing` for details on how to parse semi-structured data into structured data. - -Defining the criteria to validate against -========================================= - -This example uses the `jsonschema `_ validation engine to parse the JSON structured data we created in the prior section. the criteria defines the state we want the data to conform to. In this instance, we can validate against a desired admin state of ``up`` for all the interfaces. - -The criteria for ``jsonschema`` in this example is as follows: - -.. code-block:: text - - $cat criteria/nxos_show_interface_admin_criteria.json - { - "type" : "object", - "patternProperties": { - "^.*": { - "type": "object", - "properties": { - "admin_state": { - "type": "string", - "pattern": "up" - } - } - } - } - } - -Validating the data -==================== - -Now that we have the structured data and the criteria, we can validate this data with the :ref:`validate ` module. - -The following tasks check if the current state of the interfaces match the desired state defined in the criteria file. - -.. code-block:: yaml - - - name: Validate interface admin state - ansible.utils.validate: - data: "{{ nxos_pyats_show_interface['parsed'] }}" - criteria: - - "{{ lookup('file', './criteria/nxos_show_interface_admin_criteria.json') | from_json }}" - engine: ansible.utils.jsonschema - ignore_errors: true - register: result - - - name: Print the interface names that do not satisfy the desired state - ansible.builtin.debug: - msg: "{{ item['data_path'].split('.')[0] }}" - loop: "{{ result['errors'] }}" - when: "'errors' in result" - - -In these tasks, we have: - -#. Set ``data`` to the structured JSON data from the :ref:`cli_parse ` module. -#. Set ``criteria`` to the JSON criteria file we defined. -#. Set the validate engine to ``jsonschema``. - -.. note:: - - The value of the criteria option can be a list and should be in a format that is defined by the validation engine used. You need to install the `jsonschema `_ on the control node for this example. - -The tasks output a list of errors indicating interfaces that do not have admin value in ``up`` state. - -.. code-block:: text - - TASK [Validate interface for admin state] *********************************************************************************************************** - fatal: [nxos02]: FAILED! => {"changed": false, "errors": [{"data_path": "Ethernet2/1.admin_state", "expected": "up", "found": "down", "json_path": "$.Ethernet2/1.admin_state", "message": "'down' does not match 'up'", "relative_schema": {"pattern": "up", "type": "string"}, "schema_path": "patternProperties.^.*.properties.admin_state.pattern", "validator": "pattern"}, {"data_path": "Ethernet2/10.admin_state", "expected": "up", "found": "down", "json_path": "$.Ethernet2/10.admin_state", "message": "'down' does not match 'up'", "relative_schema": {"pattern": "up", "type": "string"}, "schema_path": "patternProperties.^.*.properties.admin_state.pattern", "validator": "pattern"}], "msg": "Validation errors were found.\nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. \nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. \nAt 'patternProperties.^.*.properties.admin_state.pattern' 'down' does not match 'up'. "} - ...ignoring - - - TASK [Print the interface names that do not satisfy the desired state] **************************************************************************** - Monday 14 December 2020 11:05:38 +0530 (0:00:01.661) 0:00:28.676 ******* - ok: [nxos] => { - "msg": "Ethernet2/1" - } - ok: [nxos] => { - "msg": "Ethernet2/10" - } - - -This shows Ethernet2/1 and Ethernet2/10 are not in the desired state based on the defined criteria. You can create a report or take further action to remediate this to bring the interfaces to the desired state based on the defined criteria. diff --git a/docs/docsite/rst/os_guide/index.rst b/docs/docsite/rst/os_guide/index.rst deleted file mode 100644 index 210a69b1c56..00000000000 --- a/docs/docsite/rst/os_guide/index.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _os_guide_index: - -################################ -Using Ansible on Windows and BSD -################################ - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible guide for Microsoft Windows and BSD. -Because Windows is not a POSIX-compliant operating system, Ansible interacts with Windows hosts differently to Linux/Unix hosts. -Likewise managing hosts that run BSD is different to managing other Unix-like host operating systems. -Find out everything you need to know about using Ansible on Windows and with BSD hosts. - -.. toctree:: - :maxdepth: 2 - - windows_setup - windows_usage - windows_winrm - windows_dsc - windows_performance - windows_faq - intro_bsd \ No newline at end of file diff --git a/docs/docsite/rst/os_guide/intro_bsd.rst b/docs/docsite/rst/os_guide/intro_bsd.rst deleted file mode 100644 index 6e92b2a3d4e..00000000000 --- a/docs/docsite/rst/os_guide/intro_bsd.rst +++ /dev/null @@ -1,278 +0,0 @@ -.. _working_with_bsd: - -Managing BSD hosts with Ansible -=============================== - -Managing BSD machines is different from managing other Unix-like machines. If you have managed nodes running BSD, review these topics. - -.. contents:: - :local: - -Connecting to BSD nodes ------------------------ - -Ansible connects to managed nodes using OpenSSH by default. This works on BSD if you use SSH keys for authentication. However, if you use SSH passwords for authentication, Ansible relies on sshpass. Most -versions of sshpass do not deal well with BSD login prompts, so when using SSH passwords against BSD machines, use ``paramiko`` to connect instead of OpenSSH. You can do this in ansible.cfg globally or you can set it as an inventory/group/host variable. For example: - -.. code-block:: text - - [freebsd] - mybsdhost1 ansible_connection=paramiko - -.. _bootstrap_bsd: - -Bootstrapping BSD ------------------ - -Ansible is agentless by default, however, it requires Python on managed nodes. Only the :ref:`raw ` module will operate without Python. Although this module can be used to bootstrap Ansible and install Python on BSD variants (see below), it is very limited and the use of Python is required to make full use of Ansible's features. - -The following example installs Python which includes the json library required for full functionality of Ansible. -On your control machine you can execute the following for most versions of FreeBSD: - -.. code-block:: bash - - ansible -m raw -a "pkg install -y python" mybsdhost1 - -Or for OpenBSD: - -.. code-block:: bash - - ansible -m raw -a "pkg_add python%3.8" - -Once this is done you can now use other Ansible modules apart from the ``raw`` module. - -.. note:: - This example demonstrated using pkg on FreeBSD and pkg_add on OpenBSD, however you should be able to substitute the appropriate package tool for your BSD; the package name may also differ. Refer to the package list or documentation of the BSD variant you are using for the exact Python package name you intend to install. - -.. BSD_python_location: - -Setting the Python interpreter ------------------------------- - -To support a variety of Unix-like operating systems and distributions, Ansible cannot always rely on the existing environment or ``env`` variables to locate the correct Python binary. By default, modules point at ``/usr/bin/python`` as this is the most common location. On BSD variants, this path may differ, so it is advised to inform Ansible of the binary's location. See :ref:`INTERPRETER_PYTHON`. For example, set ``ansible_python_interpreter`` inventory variable: - -.. code-block:: ini - - [freebsd:vars] - ansible_python_interpreter=/usr/local/bin/python - [openbsd:vars] - ansible_python_interpreter=/usr/local/bin/python3.8 - - -FreeBSD packages and ports -"""""""""""""""""""""""""" - -In FreeBSD, there is no guarantee that either ``/usr/local/bin/python`` executable file or a link to an executable file is installed by default. The best practice for a remote host, with respect to Ansible, is to install at least the Python version supported by Ansible, for example, ``lang/python38``, and both meta ports ``lang/python3`` and ``lang/python``. Quoting from */usr/ports/lang/python3/pkg-descr*: - -.. code-block:: text - - This is a meta port to the Python 3.x interpreter and provides symbolic links - to bin/python3, bin/pydoc3, bin/idle3 and so on to allow compatibility with - minor version agnostic python scripts. - -Quoting from */usr/ports/lang/python/pkg-descr*: - -.. code-block:: text - - This is a meta port to the Python interpreter and provides symbolic links - to bin/python, bin/pydoc, bin/idle and so on to allow compatibility with - version agnostic python scripts. - -As a result, the following packages are installed: - -.. code-block:: text - - shell> pkg info | grep python - python-3.8_3,2 "meta-port" for the default version of Python interpreter - python3-3_3 Meta-port for the Python interpreter 3.x - python38-3.8.12_1 Interpreted object-oriented programming language - -and the following executables and links - -.. code-block:: text - - shell> ll /usr/local/bin/ | grep python - lrwxr-xr-x 1 root wheel 7 Jan 24 08:30 python@ -> python3 - lrwxr-xr-x 1 root wheel 14 Jan 24 08:30 python-config@ -> python3-config - lrwxr-xr-x 1 root wheel 9 Jan 24 08:29 python3@ -> python3.8 - lrwxr-xr-x 1 root wheel 16 Jan 24 08:29 python3-config@ -> python3.8-config - -r-xr-xr-x 1 root wheel 5248 Jan 13 01:12 python3.8* - -r-xr-xr-x 1 root wheel 3153 Jan 13 01:12 python3.8-config* - - -INTERPRETER_PYTHON_FALLBACK -""""""""""""""""""""""""""" - -Since version 2.8 Ansible provides a useful variable ``ansible_interpreter_python_fallback`` to specify a list of paths to search for Python. See :ref:`INTERPRETER_PYTHON_FALLBACK`. This list will be searched and the first item found will be used. For example, the configuration below would make the installation of the meta-ports in the previous section redundant, that is, if you don't install the Python meta ports the first two items in the list will be skipped and ``/usr/local/bin/python3.8`` will be discovered. - -.. code-block:: ini - - ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.8'] - - -You can use this variable, prolonged by the lower versions of Python, and put it, for example, into the ``group_vars/all``. Then, override it for specific groups in ``group_vars/{group1, group2, ...}`` and for specific hosts in ``host_vars/{host1, host2, ...}`` if needed. See :ref:`ansible_variable_precedence`. - - -Debug the discovery of Python -""""""""""""""""""""""""""""" - -For example, given the inventory - -.. code-block:: ini - - shell> cat hosts - [test] - test_11 - test_12 - test_13 - - [test:vars] - ansible_connection=ssh - ansible_user=admin - ansible_become=true - ansible_become_user=root - ansible_become_method=sudo - ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.8'] - ansible_perl_interpreter=/usr/local/bin/perl - -The playbook below - -.. code-block:: yaml+jinja - - shell> cat playbook.yml - - hosts: test_11 - gather_facts: false - tasks: - - command: which python - register: result - - debug: - var: result.stdout - - debug: - msg: |- - {% for i in _vars %} - {{ i }}: - {{ lookup('vars', i)|to_nice_yaml|indent(2) }} - {% endfor %} - vars: - _vars: "{{ query('varnames', '.*python.*') }}" - -displays the details - -.. code-block:: yaml - - shell> ansible-playbook -i hosts playbook.yml - - PLAY [test_11] ******************************************************************************* - - TASK [command] ******************************************************************************* - [WARNING]: Platform freebsd on host test_11 is using the discovered Python interpreter at - /usr/local/bin/python, but future installation of another Python interpreter could change the - meaning of that path. See https://docs.ansible.com/ansible- - core/2.12/reference_appendices/interpreter_discovery.html for more information. - changed: [test_11] - - TASK [debug] ********************************************************************************* - ok: [test_11] => - result.stdout: /usr/local/bin/python - - TASK [debug] ********************************************************************************* - ok: [test_11] => - msg: |- - ansible_interpreter_python_fallback: - - /usr/local/bin/python - - /usr/local/bin/python3 - - /usr/local/bin/python3.8 - - discovered_interpreter_python: - /usr/local/bin/python - - ansible_playbook_python: - /usr/bin/python3 - -You can see that the first item from the list ``ansible_interpreter_python_fallback`` was discovered at the FreeBSD remote host. The variable ``ansible_playbook_python`` keeps the path to Python at the Linux controller that ran the playbook. - -Regarding the warning, quoting from :ref:`INTERPRETER_PYTHON` - -.. code-block:: text - - 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 or auto_legacy_silent. ... - -You can either ignore it or get rid of it by setting the variable ``ansible_python_interpreter=auto_silent`` because this is, actually, what you want by using ``/usr/local/bin/python`` (*"interpreters installed later may change which one is used"*). For example - -.. code-block:: ini - - shell> cat hosts - [test] - test_11 - test_12 - test_13 - - [test:vars] - ansible_connection=ssh - ansible_user=admin - ansible_become=true - ansible_become_user=root - ansible_become_method=sudo - ansible_interpreter_python_fallback=['/usr/local/bin/python', '/usr/local/bin/python3', '/usr/local/bin/python3.8'] - ansible_python_interpreter=auto_silent - ansible_perl_interpreter=/usr/local/bin/perl - - -.. seealso:: - - * :ref:`interpreter_discovery` - * `FreeBSD Wiki: Ports/DEFAULT_VERSIONS `_ - - -Additional variables -"""""""""""""""""""" - -If you use additional plugins beyond those bundled with Ansible, you can set similar variables for ``bash``, ``perl`` or ``ruby``, depending on how the plugin is written. For example: - -.. code-block:: ini - - [freebsd:vars] - ansible_python_interpreter=/usr/local/bin/python - ansible_perl_interpreter=/usr/local/bin/perl - - -Which modules are available? ----------------------------- - -The majority of the core Ansible modules are written for a combination of Unix-like machines and other generic services, so most should function well on the BSDs with the obvious exception of those that are aimed at Linux-only technologies (such as LVG). - -Using BSD as the control node ------------------------------ - -Using BSD as the control machine is as simple as installing the Ansible package for your BSD variant or by following the ``pip`` or 'from source' instructions. - -.. _bsd_facts: - -BSD facts ---------- - -Ansible gathers facts from the BSDs in a similar manner to Linux machines, but since the data, names and structures can vary for network, disks and other devices, one should expect the output to be slightly different yet still familiar to a BSD administrator. - -.. _bsd_contributions: - -BSD efforts and contributions ------------------------------ - -BSD support is important to us at Ansible. Even though the majority of our contributors use and target Linux we have an active BSD community and strive to be as BSD-friendly as possible. -Please feel free to report any issues or incompatibilities you discover with BSD; pull requests with an included fix are also welcome! - -.. seealso:: - - :ref:`intro_adhoc` - Examples of basic commands - :ref:`working_with_playbooks` - Learning ansible's configuration management language - :ref:`developing_modules` - How to write modules - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_dsc.rst b/docs/docsite/rst/os_guide/windows_dsc.rst deleted file mode 100644 index 1588a2329fc..00000000000 --- a/docs/docsite/rst/os_guide/windows_dsc.rst +++ /dev/null @@ -1,508 +0,0 @@ -.. _windows_dsc: - -Desired State Configuration -=========================== - -.. contents:: Topics - :local: - -What is Desired State Configuration? -```````````````````````````````````` -Desired State Configuration, or DSC, is a tool built into PowerShell that can -be used to define a Windows host setup through code. The overall purpose of DSC -is the same as Ansible, it is just executed in a different manner. Since -Ansible 2.4, the ``win_dsc`` module has been added and can be used to take advantage of -existing DSC resources when interacting with a Windows host. - -More details on DSC can be viewed at `DSC Overview `_. - -Host Requirements -````````````````` -To use the ``win_dsc`` module, a Windows host must have PowerShell v5.0 or -newer installed. All supported hosts can be upgraded to PowerShell v5. - -Once the PowerShell requirements have been met, using DSC is as simple as -creating a task with the ``win_dsc`` module. - -Why Use DSC? -```````````` -DSC and Ansible modules have a common goal which is to define and ensure the state of a -resource. Because of -this, resources like the DSC `File resource `_ -and Ansible ``win_file`` can be used to achieve the same result. Deciding which to use depends -on the scenario. - -Reasons for using an Ansible module over a DSC resource: - -* The host does not support PowerShell v5.0, or it cannot easily be upgraded -* The DSC resource does not offer a feature present in an Ansible module. For example, - win_regedit can manage the ``REG_NONE`` property type, while the DSC - ``Registry`` resource cannot -* DSC resources have limited check mode support, while some Ansible modules have - better checks -* DSC resources do not support diff mode, while some Ansible modules do -* Custom resources require further installation steps to be run on the host - beforehand, while Ansible modules are built-in to Ansible -* There are bugs in a DSC resource where an Ansible module works - -Reasons for using a DSC resource over an Ansible module: - -* The Ansible module does not support a feature present in a DSC resource -* There is no Ansible module available -* There are bugs in an existing Ansible module - -In the end, it doesn't matter whether the task is performed with DSC or an -Ansible module; what matters is that the task is performed correctly and the -playbooks are still readable. If you have more experience with DSC over Ansible -and it does the job, just use DSC for that task. - -How to Use DSC? -``````````````` -The ``win_dsc`` module takes in a free-form of options so that it changes -according to the resource it is managing. A list of built-in resources can be -found at `resources `_. - -Using the `Registry `_ -resource as an example, this is the DSC definition as documented by Microsoft: - -.. code-block:: powershell - - Registry [string] #ResourceName - { - Key = [string] - ValueName = [string] - [ Ensure = [string] { Enable | Disable } ] - [ Force = [bool] ] - [ Hex = [bool] ] - [ DependsOn = [string[]] ] - [ ValueData = [string[]] ] - [ ValueType = [string] { Binary | Dword | ExpandString | MultiString | Qword | String } ] - } - -When defining the task, ``resource_name`` must be set to the DSC resource being -used - in this case, the ``resource_name`` should be set to ``Registry``. The -``module_version`` can refer to a specific version of the DSC resource -installed; if left blank it will default to the latest version. The other -options are parameters that are used to define the resource, such as ``Key`` and -``ValueName``. While the options in the task are not case sensitive, -keeping the case as-is is recommended because it makes it easier to distinguish DSC -resource options from Ansible's ``win_dsc`` options. - -This is what the Ansible task version of the above DSC Registry resource would look like: - -.. code-block:: yaml+jinja - - - name: Use win_dsc module with the Registry DSC resource - win_dsc: - resource_name: Registry - Ensure: Present - Key: HKEY_LOCAL_MACHINE\SOFTWARE\ExampleKey - ValueName: TestValue - ValueData: TestData - -Starting in Ansible 2.8, the ``win_dsc`` module automatically validates the -input options from Ansible with the DSC definition. This means Ansible will -fail if the option name is incorrect, a mandatory option is not set, or the -value is not a valid choice. When running Ansible with a verbosity level of 3 -or more (``-vvv``), the return value will contain the possible invocation -options based on the ``resource_name`` specified. Here is an example of the -invocation output for the above ``Registry`` task: - -.. code-block:: ansible-output - - changed: [2016] => { - "changed": true, - "invocation": { - "module_args": { - "DependsOn": null, - "Ensure": "Present", - "Force": null, - "Hex": null, - "Key": "HKEY_LOCAL_MACHINE\\SOFTWARE\\ExampleKey", - "PsDscRunAsCredential_password": null, - "PsDscRunAsCredential_username": null, - "ValueData": [ - "TestData" - ], - "ValueName": "TestValue", - "ValueType": null, - "module_version": "latest", - "resource_name": "Registry" - } - }, - "module_version": "1.1", - "reboot_required": false, - "verbose_set": [ - "Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = ResourceSet,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.", - "An LCM method call arrived from computer SERVER2016 with user sid S-1-5-21-3088887838-4058132883-1884671576-1105.", - "[SERVER2016]: LCM: [ Start Set ] [[Registry]DirectResourceAccess]", - "[SERVER2016]: [[Registry]DirectResourceAccess] (SET) Create registry key 'HKLM:\\SOFTWARE\\ExampleKey'", - "[SERVER2016]: [[Registry]DirectResourceAccess] (SET) Set registry key value 'HKLM:\\SOFTWARE\\ExampleKey\\TestValue' to 'TestData' of type 'String'", - "[SERVER2016]: LCM: [ End Set ] [[Registry]DirectResourceAccess] in 0.1930 seconds.", - "[SERVER2016]: LCM: [ End Set ] in 0.2720 seconds.", - "Operation 'Invoke CimMethod' complete.", - "Time taken for configuration job to complete is 0.402 seconds" - ], - "verbose_test": [ - "Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = ResourceTest,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.", - "An LCM method call arrived from computer SERVER2016 with user sid S-1-5-21-3088887838-4058132883-1884671576-1105.", - "[SERVER2016]: LCM: [ Start Test ] [[Registry]DirectResourceAccess]", - "[SERVER2016]: [[Registry]DirectResourceAccess] Registry key 'HKLM:\\SOFTWARE\\ExampleKey' does not exist", - "[SERVER2016]: LCM: [ End Test ] [[Registry]DirectResourceAccess] False in 0.2510 seconds.", - "[SERVER2016]: LCM: [ End Set ] in 0.3310 seconds.", - "Operation 'Invoke CimMethod' complete.", - "Time taken for configuration job to complete is 0.475 seconds" - ] - } - -The ``invocation.module_args`` key shows the actual values that were set as -well as other possible values that were not set. Unfortunately, this will not -show the default value for a DSC property, only what was set from the Ansible -task. Any ``*_password`` option will be masked in the output for security -reasons; if there are any other sensitive module options, set ``no_log: True`` -on the task to stop all task output from being logged. - - -Property Types --------------- -Each DSC resource property has a type that is associated with it. Ansible -will try to convert the defined options to the correct type during execution. -For simple types like ``[string]`` and ``[bool]``, this is a simple operation, -but complex types like ``[PSCredential]`` or arrays (like ``[string[]]``) -require certain rules. - -PSCredential -++++++++++++ -A ``[PSCredential]`` object is used to store credentials in a secure way, but -Ansible has no way to serialize this over JSON. To set a DSC PSCredential property, -the definition of that parameter should have two entries that are suffixed with -``_username`` and ``_password`` for the username and password, respectively. -For example: - -.. code-block:: yaml+jinja - - PsDscRunAsCredential_username: '{{ ansible_user }}' - PsDscRunAsCredential_password: '{{ ansible_password }}' - - SourceCredential_username: AdminUser - SourceCredential_password: PasswordForAdminUser - -.. Note:: On versions of Ansible older than 2.8, you should set ``no_log: true`` - on the task definition in Ansible to ensure any credentials used are not - stored in any log file or console output. - -A ``[PSCredential]`` is defined with ``EmbeddedInstance("MSFT_Credential")`` in -a DSC resource MOF definition. - -CimInstance Type -++++++++++++++++ -A ``[CimInstance]`` object is used by DSC to store a dictionary object based on -a custom class defined by that resource. Defining a value that takes in a -``[CimInstance]`` in YAML is the same as defining a dictionary in YAML. -For example, to define a ``[CimInstance]`` value in Ansible: - -.. code-block:: yaml+jinja - - # [CimInstance]AuthenticationInfo == MSFT_xWebAuthenticationInformation - AuthenticationInfo: - Anonymous: false - Basic: true - Digest: false - Windows: true - -In the above example, the CIM instance is a representation of the class -`MSFT_xWebAuthenticationInformation `_. -This class accepts four boolean variables, ``Anonymous``, ``Basic``, -``Digest``, and ``Windows``. The keys to use in a ``[CimInstance]`` depend on -the class it represents. Please read through the documentation of the resource -to determine the keys that can be used and the types of each key value. The -class definition is typically located in the ``.schema.mof``. - -HashTable Type -++++++++++++++ -A ``[HashTable]`` object is also a dictionary but does not have a strict set of -keys that can/need to be defined. Like a ``[CimInstance]``, define it as a -normal dictionary value in YAML. A ``[HashTable]]`` is defined with -``EmbeddedInstance("MSFT_KeyValuePair")`` in a DSC resource MOF definition. - -Arrays -++++++ -Simple type arrays like ``[string[]]`` or ``[UInt32[]]`` are defined as a list -or as a comma-separated string which is then cast to their type. Using a list -is recommended because the values are not manually parsed by the ``win_dsc`` -module before being passed to the DSC engine. For example, to define a simple -type array in Ansible: - -.. code-block:: yaml+jinja - - # [string[]] - ValueData: entry1, entry2, entry3 - ValueData: - - entry1 - - entry2 - - entry3 - - # [UInt32[]] - ReturnCode: 0,3010 - ReturnCode: - - 0 - - 3010 - -Complex type arrays like ``[CimInstance[]]`` (array of dicts), can be defined -like this example: - -.. code-block:: yaml+jinja - - # [CimInstance[]]BindingInfo == MSFT_xWebBindingInformation - BindingInfo: - - Protocol: https - Port: 443 - CertificateStoreName: My - CertificateThumbprint: C676A89018C4D5902353545343634F35E6B3A659 - HostName: DSCTest - IPAddress: '*' - SSLFlags: 1 - - Protocol: http - Port: 80 - IPAddress: '*' - -The above example is an array with two values of the class `MSFT_xWebBindingInformation `_. -When defining a ``[CimInstance[]]``, be sure to read the resource documentation -to find out what keys to use in the definition. - -DateTime -++++++++ -A ``[DateTime]`` object is a DateTime string representing the date and time in -the `ISO 8601 `_ date time format. The -value for a ``[DateTime]`` field should be quoted in YAML to ensure the string -is properly serialized to the Windows host. Here is an example of how to define -a ``[DateTime]`` value in Ansible: - -.. code-block:: yaml+jinja - - # As UTC-0 (No timezone) - DateTime: '2019-02-22T13:57:31.2311892+00:00' - - # As UTC+4 - DateTime: '2019-02-22T17:57:31.2311892+04:00' - - # As UTC-4 - DateTime: '2019-02-22T09:57:31.2311892-04:00' - -All the values above are equal to a UTC date time of February 22nd 2019 at -1:57pm with 31 seconds and 2311892 milliseconds. - -Run As Another User -------------------- -By default, DSC runs each resource as the SYSTEM account and not the account -that Ansible uses to run the module. This means that resources that are dynamically -loaded based on a user profile, like the ``HKEY_CURRENT_USER`` registry hive, -will be loaded under the ``SYSTEM`` profile. The parameter -``PsDscRunAsCredential`` is a parameter that can be set for every DSC resource, and -force the DSC engine to run under a different account. As -``PsDscRunAsCredential`` has a type of ``PSCredential``, it is defined with the -``_username`` and ``_password`` suffix. - -Using the Registry resource type as an example, this is how to define a task -to access the ``HKEY_CURRENT_USER`` hive of the Ansible user: - -.. code-block:: yaml+jinja - - - name: Use win_dsc with PsDscRunAsCredential to run as a different user - win_dsc: - resource_name: Registry - Ensure: Present - Key: HKEY_CURRENT_USER\ExampleKey - ValueName: TestValue - ValueData: TestData - PsDscRunAsCredential_username: '{{ ansible_user }}' - PsDscRunAsCredential_password: '{{ ansible_password }}' - no_log: true - -Custom DSC Resources -```````````````````` -DSC resources are not limited to the built-in options from Microsoft. Custom -modules can be installed to manage other resources that are not usually available. - -Finding Custom DSC Resources ----------------------------- -You can use the -`PSGallery `_ to find custom resources, along with documentation on how to install them on a Windows host. - -The ``Find-DscResource`` cmdlet can also be used to find custom resources. For example: - -.. code-block:: powershell - - # Find all DSC resources in the configured repositories - Find-DscResource - - # Find all DSC resources that relate to SQL - Find-DscResource -ModuleName "*sql*" - -.. Note:: DSC resources developed by Microsoft that start with ``x`` means the - resource is experimental and comes with no support. - -Installing a Custom Resource ----------------------------- -There are three ways that a DSC resource can be installed on a host: - -* Manually with the ``Install-Module`` cmdlet -* Using the ``win_psmodule`` Ansible module -* Saving the module manually and copying it to another host - -The following is an example of installing the ``xWebAdministration`` resources using -``win_psmodule``: - -.. code-block:: yaml+jinja - - - name: Install xWebAdministration DSC resource - win_psmodule: - name: xWebAdministration - state: present - -Once installed, the win_dsc module will be able to use the resource by referencing it -with the ``resource_name`` option. - -The first two methods above only work when the host has access to the internet. -When a host does not have internet access, the module must first be installed -using the methods above on another host with internet access and then copied -across. To save a module to a local filepath, the following PowerShell cmdlet -can be run: - -.. code-block:: powershell - - Save-Module -Name xWebAdministration -Path C:\temp - -This will create a folder called ``xWebAdministration`` in ``C:\temp``, which -can be copied to any host. For PowerShell to see this offline resource, it must -be copied to a directory set in the ``PSModulePath`` environment variable. -In most cases, the path ``C:\Program Files\WindowsPowerShell\Module`` is set -through this variable, but the ``win_path`` module can be used to add different -paths. - -Examples -```````` -Extract a zip file ------------------- - -.. code-block:: yaml+jinja - - - name: Extract a zip file - win_dsc: - resource_name: Archive - Destination: C:\temp\output - Path: C:\temp\zip.zip - Ensure: Present - -Create a directory ------------------- - -.. code-block:: yaml+jinja - - - name: Create file with some text - win_dsc: - resource_name: File - DestinationPath: C:\temp\file - Contents: | - Hello - World - Ensure: Present - Type: File - - - name: Create directory that is hidden is set with the System attribute - win_dsc: - resource_name: File - DestinationPath: C:\temp\hidden-directory - Attributes: Hidden,System - Ensure: Present - Type: Directory - -Interact with Azure -------------------- - -.. code-block:: yaml+jinja - - - name: Install xAzure DSC resources - win_psmodule: - name: xAzure - state: present - - - name: Create virtual machine in Azure - win_dsc: - resource_name: xAzureVM - ImageName: a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201409.01-en.us-127GB.vhd - Name: DSCHOST01 - ServiceName: ServiceName - StorageAccountName: StorageAccountName - InstanceSize: Medium - Windows: true - Ensure: Present - Credential_username: '{{ ansible_user }}' - Credential_password: '{{ ansible_password }}' - -Setup IIS Website ------------------ - -.. code-block:: yaml+jinja - - - name: Install xWebAdministration module - win_psmodule: - name: xWebAdministration - state: present - - - name: Install IIS features that are required - win_dsc: - resource_name: WindowsFeature - Name: '{{ item }}' - Ensure: Present - loop: - - Web-Server - - Web-Asp-Net45 - - - name: Setup web content - win_dsc: - resource_name: File - DestinationPath: C:\inetpub\IISSite\index.html - Type: File - Contents: | - - IIS Site - This is the body - - Ensure: present - - - name: Create new website - win_dsc: - resource_name: xWebsite - Name: NewIISSite - State: Started - PhysicalPath: C:\inetpub\IISSite\index.html - BindingInfo: - - Protocol: https - Port: 8443 - CertificateStoreName: My - CertificateThumbprint: C676A89018C4D5902353545343634F35E6B3A659 - HostName: DSCTest - IPAddress: '*' - SSLFlags: 1 - - Protocol: http - Port: 8080 - IPAddress: '*' - AuthenticationInfo: - Anonymous: false - Basic: true - Digest: false - Windows: true - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_faq.rst b/docs/docsite/rst/os_guide/windows_faq.rst deleted file mode 100644 index f582d7db201..00000000000 --- a/docs/docsite/rst/os_guide/windows_faq.rst +++ /dev/null @@ -1,257 +0,0 @@ -.. _windows_faq: - -Windows Frequently Asked Questions -================================== - -Here are some commonly asked questions in regards to Ansible and Windows and -their answers. - -.. note:: This document covers questions about managing Microsoft Windows servers with Ansible. - For questions about Ansible Core, please see the - :ref:`general FAQ page `. - -Does Ansible work with Windows XP or Server 2003? -`````````````````````````````````````````````````` -Ansible does not work with Windows XP or Server 2003 hosts. Ansible does work with these Windows operating system versions: - -* Windows Server 2008 :sup:`1` -* Windows Server 2008 R2 :sup:`1` -* Windows Server 2012 -* Windows Server 2012 R2 -* Windows Server 2016 -* Windows Server 2019 -* Windows 7 :sup:`1` -* Windows 8.1 -* Windows 10 - -1 - See the :ref:`Server 2008 FAQ ` entry for more details. - -Ansible also has minimum PowerShell version requirements - please see -:ref:`windows_setup` for the latest information. - -.. _windows_faq_server2008: - -Are Server 2008, 2008 R2 and Windows 7 supported? -````````````````````````````````````````````````` -Microsoft ended Extended Support for these versions of Windows on January 14th, 2020, and Ansible deprecated official support in the 2.10 release. No new feature development will occur targeting these operating systems, and automated testing has ceased. However, existing modules and features will likely continue to work, and simple pull requests to resolve issues with these Windows versions may be accepted. - -Can I manage Windows Nano Server with Ansible? -`````````````````````````````````````````````` -Ansible does not currently work with Windows Nano Server, since it does -not have access to the full .NET Framework that is used by the majority of the -modules and internal components. - -.. _windows_faq_ansible: - -Can Ansible run on Windows? -``````````````````````````` -No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host -natively, though it can run under the Windows Subsystem for Linux (WSL). - -.. note:: The Windows Subsystem for Linux is not supported by Ansible and - should not be used for production systems. - -To install Ansible on WSL, the following commands -can be run in the bash terminal: - -.. code-block:: shell - - sudo apt-get update - sudo apt-get install python3-pip git libffi-dev libssl-dev -y - pip install --user ansible pywinrm - -To run Ansible from source instead of a release on the WSL, simply uninstall the pip -installed version and then clone the git repo. - -.. code-block:: shell - - pip uninstall ansible -y - git clone https://github.com/ansible/ansible.git - source ansible/hacking/env-setup - - # To enable Ansible on login, run the following - echo ". ~/ansible/hacking/env-setup -q' >> ~/.bashrc - -If you encounter timeout errors when running Ansible on the WSL, this may be due to an issue -with ``sleep`` not returning correctly. The following workaround may resolve the issue: - -.. code-block:: shell - - mv /usr/bin/sleep /usr/bin/sleep.orig - ln -s /bin/true /usr/bin/sleep - -Another option is to use WSL 2 if running Windows 10 later than build 2004. - -.. code-block:: shell - - wsl --set-default-version 2 - - -Can I use SSH keys to authenticate to Windows hosts? -```````````````````````````````````````````````````` -You cannot use SSH keys with the WinRM or PSRP connection plugins. -These connection plugins use X509 certificates for authentication instead -of the SSH key pairs that SSH uses. - -The way X509 certificates are generated and mapped to a user is different -from the SSH implementation; consult the :ref:`windows_winrm` documentation for -more information. - -Ansible 2.8 has added an experimental option to use the SSH connection plugin, -which uses SSH keys for authentication, for Windows servers. See :ref:`this question ` -for more information. - -.. _windows_faq_winrm: - -Why can I run a command locally that does not work under Ansible? -````````````````````````````````````````````````````````````````` -Ansible executes commands through WinRM. These processes are different from -running a command locally in these ways: - -* Unless using an authentication option like CredSSP or Kerberos with - credential delegation, the WinRM process does not have the ability to - delegate the user's credentials to a network resource, causing ``Access is - Denied`` errors. - -* All processes run under WinRM are in a non-interactive session. Applications - that require an interactive session will not work. - -* When running through WinRM, Windows restricts access to internal Windows - APIs like the Windows Update API and DPAPI, which some installers and - programs rely on. - -Some ways to bypass these restrictions are to: - -* Use ``become``, which runs a command as it would when run locally. This will - bypass most WinRM restrictions, as Windows is unaware the process is running - under WinRM when ``become`` is used. See the :ref:`become` documentation for more - information. - -* Use a scheduled task, which can be created with ``win_scheduled_task``. Like - ``become``, it will bypass all WinRM restrictions, but it can only be used to run - commands, not modules. - -* Use ``win_psexec`` to run a command on the host. PSExec does not use WinRM - and so will bypass any of the restrictions. - -* To access network resources without any of these workarounds, you can use - CredSSP or Kerberos with credential delegation enabled. - -See :ref:`become` more info on how to use become. The limitations section at -:ref:`windows_winrm` has more details around WinRM limitations. - -This program won't install on Windows with Ansible -`````````````````````````````````````````````````` -See :ref:`this question ` for more information about WinRM limitations. - -What Windows modules are available? -``````````````````````````````````` -Most of the Ansible modules in Ansible Core are written for a combination of -Linux/Unix machines and arbitrary web services. These modules are written in -Python and most of them do not work on Windows. - -Because of this, there are dedicated Windows modules that are written in -PowerShell and are meant to be run on Windows hosts. A list of these modules -can be found :ref:`here `. - -In addition, the following Ansible Core modules/action-plugins work with Windows: - -* add_host -* assert -* async_status -* debug -* fail -* fetch -* group_by -* include -* include_role -* include_vars -* meta -* pause -* raw -* script -* set_fact -* set_stats -* setup -* slurp -* template (also: win_template) -* wait_for_connection - -Ansible Windows modules exist in the :ref:`plugins_in_ansible.windows`, :ref:`plugins_in_community.windows`, and :ref:`plugins_in_chocolatey.chocolatey` collections. - -Can I run Python modules on Windows hosts? -`````````````````````````````````````````` -No, the WinRM connection protocol is set to use PowerShell modules, so Python -modules will not work. A way to bypass this issue to use -``delegate_to: localhost`` to run a Python module on the Ansible controller. -This is useful if during a playbook, an external service needs to be contacted -and there is no equivalent Windows module available. - -.. _windows_faq_ssh: - -Can I connect to Windows hosts over SSH? -```````````````````````````````````````` -Ansible 2.8 has added an experimental option to use the SSH connection plugin -to manage Windows hosts. To connect to Windows hosts over SSH, you must install and configure the `Win32-OpenSSH `_ -fork that is in development with Microsoft on -the Windows host(s). While most of the basics should work with SSH, -``Win32-OpenSSH`` is rapidly changing, with new features added and bugs -fixed in every release. It is highly recommend you `install `_ the latest release -of ``Win32-OpenSSH`` from the GitHub Releases page when using it with Ansible -on Windows hosts. - -To use SSH as the connection to a Windows host, set the following variables in -the inventory: - -.. code-block:: shell - - ansible_connection=ssh - - # Set either cmd or powershell not both - ansible_shell_type=cmd - # ansible_shell_type=powershell - -The value for ``ansible_shell_type`` should either be ``cmd`` or ``powershell``. -Use ``cmd`` if the ``DefaultShell`` has not been configured on the SSH service -and ``powershell`` if that has been set as the ``DefaultShell``. - -Why is connecting to a Windows host through SSH failing? -```````````````````````````````````````````````````````` -Unless you are using ``Win32-OpenSSH`` as described above, you must connect to -Windows hosts using :ref:`windows_winrm`. If your Ansible output indicates that -SSH was used, either you did not set the connection vars properly or the host is not inheriting them correctly. - -Make sure ``ansible_connection: winrm`` is set in the inventory for the Windows -host(s). - -Why are my credentials being rejected? -`````````````````````````````````````` -This can be due to a myriad of reasons unrelated to incorrect credentials. - -See HTTP 401/Credentials Rejected at :ref:`windows_setup` for a more detailed -guide of this could mean. - -Why am I getting an error SSL CERTIFICATE_VERIFY_FAILED? -```````````````````````````````````````````````````````` -When the Ansible controller is running on Python 2.7.9+ or an older version of Python that -has backported SSLContext (like Python 2.7.5 on RHEL 7), the controller will attempt to -validate the certificate WinRM is using for an HTTPS connection. If the -certificate cannot be validated (such as in the case of a self signed cert), it will -fail the verification process. - -To ignore certificate validation, add -``ansible_winrm_server_cert_validation: ignore`` to inventory for the Windows -host. - -.. seealso:: - - :ref:`windows` - The Windows documentation index - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_performance.rst b/docs/docsite/rst/os_guide/windows_performance.rst deleted file mode 100644 index c922b4d9edd..00000000000 --- a/docs/docsite/rst/os_guide/windows_performance.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _windows_performance: - -Windows performance -=================== -This document offers some performance optimizations you might like to apply to -your Windows hosts to speed them up specifically in the context of using Ansible -with them, and generally. - -Optimize PowerShell performance to reduce Ansible task overhead ---------------------------------------------------------------- -To speed up the startup of PowerShell by around 10x, run the following -PowerShell snippet in an Administrator session. Expect it to take tens of -seconds. - -.. note:: - - If native images have already been created by the ngen task or service, you - will observe no difference in performance (but this snippet will at that - point execute faster than otherwise). - -.. code-block:: powershell - - function Optimize-PowershellAssemblies { - # NGEN powershell assembly, improves startup time of powershell by 10x - $old_path = $env:path - try { - $env:path = [Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory() - [AppDomain]::CurrentDomain.GetAssemblies() | % { - if (! $_.location) {continue} - $Name = Split-Path $_.location -leaf - if ($Name.startswith("Microsoft.PowerShell.")) { - Write-Progress -Activity "Native Image Installation" -Status "$name" - ngen install $_.location | % {"`t$_"} - } - } - } finally { - $env:path = $old_path - } - } - Optimize-PowershellAssemblies - -PowerShell is used by every Windows Ansible module. This optimization reduces -the time PowerShell takes to start up, removing that overhead from every invocation. - -This snippet uses `the native image generator, ngen `_ -to pre-emptively create native images for the assemblies that PowerShell relies on. - -Fix high-CPU-on-boot for VMs/cloud instances --------------------------------------------- -If you are creating golden images to spawn instances from, you can avoid a disruptive -high CPU task near startup through `processing the ngen queue `_ -within your golden image creation, if you know the CPU types won't change between -golden image build process and runtime. - -Place the following near the end of your playbook, bearing in mind the factors that can cause native images to be invalidated (`see MSDN `_). - -.. code-block:: yaml - - - name: generate native .NET images for CPU - win_dotnet_ngen: - diff --git a/docs/docsite/rst/os_guide/windows_setup.rst b/docs/docsite/rst/os_guide/windows_setup.rst deleted file mode 100644 index 37ea6093f7c..00000000000 --- a/docs/docsite/rst/os_guide/windows_setup.rst +++ /dev/null @@ -1,499 +0,0 @@ -.. _windows_setup: - -Setting up a Windows Host -========================= -This document discusses the setup that is required before Ansible can communicate with a Microsoft Windows host. - -.. contents:: - :local: - -Host Requirements -````````````````` -For Ansible to communicate to a Windows host and use Windows modules, the -Windows host must meet these base requirements for connectivity: - -* With Ansible you can generally manage Windows versions under the current and extended support from Microsoft. You can also manage desktop OSs including Windows 8.1, and 10, and server OSs including Windows Server 2012, 2012 R2, 2016, 2019, and 2022. - -* You need to install PowerShell 3.0 or newer and at least .NET 4.0 on the Windows host. - -* You need to create and activate a WinRM listener. More details, see `WinRM Setup `_. - -.. Note:: Some Ansible modules have additional requirements, such as a newer OS or PowerShell version. Consult the module documentation page to determine whether a host meets those requirements. - -Upgrading PowerShell and .NET Framework ---------------------------------------- -Ansible requires PowerShell version 3.0 and .NET Framework 4.0 or newer to function on older operating systems like Server 2008 and Windows 7. The base image does not meet this -requirement. You can use the `Upgrade-PowerShell.ps1 `_ script to update these. - -This is an example of how to run this script from PowerShell: - -.. code-block:: powershell - - [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 - $url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Upgrade-PowerShell.ps1" - $file = "$env:temp\Upgrade-PowerShell.ps1" - $username = "Administrator" - $password = "Password" - - (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) - Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force - - &$file -Version 5.1 -Username $username -Password $password -Verbose - -In the script, the ``file`` value can be the PowerShell version 3.0, 4.0, or 5.1. - -Once completed, you need to run the following PowerShell commands: - -1. As an optional but good security practice, you can set the execution policy back to the default. - -.. code-block:: powershell - - Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force - -Use the ``RemoteSigned`` value for Windows servers, or ``Restricted`` for Windows clients. - -2. Remove the auto logon. - -.. code-block:: powershell - - $reg_winlogon_path = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" - Set-ItemProperty -Path $reg_winlogon_path -Name AutoAdminLogon -Value 0 - Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultUserName -ErrorAction SilentlyContinue - Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultPassword -ErrorAction SilentlyContinue - -The script determines what programs you need to install (such as .NET Framework 4.5.2) and what PowerShell version needs to be present. If a reboot is needed and the ``username`` and ``password`` parameters are set, the script will automatically reboot the machine and then logon. If the ``username`` and ``password`` parameters are not set, the script will prompt the user to manually reboot and logon when required. When the user is next logged in, the script will continue where it left off and the process continues until no more -actions are required. - -.. Note:: If you run the script on Server 2008, then you need to install SP2. For Server 2008 R2 or Windows 7 you need SP1. - - On Windows Server 2008 you can install only PowerShell 3.0. A newer version will result in the script failure. - - The ``username`` and ``password`` parameters are stored in plain text in the registry. Run the cleanup commands after the script finishes to ensure no credentials are stored on the host. - - -WinRM Memory Hotfix -------------------- -On PowerShell v3.0, there is a bug that limits the amount of memory available to the WinRM service. Use the `Install-WMF3Hotfix.ps1 `_ script to install a hotfix on affected hosts as part of the system bootstrapping or imaging process. Without this hotfix, Ansible fails to execute certain commands on the Windows host. - -To install the hotfix: - -.. code-block:: powershell - - [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 - $url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Install-WMF3Hotfix.ps1" - $file = "$env:temp\Install-WMF3Hotfix.ps1" - - (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) - powershell.exe -ExecutionPolicy ByPass -File $file -Verbose - -For more details, refer to the `"Out of memory" error on a computer that has a customized MaxMemoryPerShellMB quota set and has WMF 3.0 installed `_ article. - -WinRM Setup -``````````` -You need to configure the WinRM service so that Ansible can connect to it. There are two main components of the WinRM service that governs how Ansible can interface with the Windows host: the ``listener`` and the ``service`` configuration settings. - -WinRM Listener --------------- -The WinRM services listen for requests on one or more ports. Each of these ports must have a listener created and configured. - -To view the current listeners that are running on the WinRM service: - -.. code-block:: powershell - - winrm enumerate winrm/config/Listener - -This will output something like: - -.. code-block:: powershell - - Listener - Address = * - Transport = HTTP - Port = 5985 - Hostname - Enabled = true - URLPrefix = wsman - CertificateThumbprint - ListeningOn = 10.0.2.15, 127.0.0.1, 192.168.56.155, ::1, fe80::5efe:10.0.2.15%6, fe80::5efe:192.168.56.155%8, fe80:: - ffff:ffff:fffe%2, fe80::203d:7d97:c2ed:ec78%3, fe80::e8ea:d765:2c69:7756%7 - - Listener - Address = * - Transport = HTTPS - Port = 5986 - Hostname = SERVER2016 - Enabled = true - URLPrefix = wsman - CertificateThumbprint = E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE - ListeningOn = 10.0.2.15, 127.0.0.1, 192.168.56.155, ::1, fe80::5efe:10.0.2.15%6, fe80::5efe:192.168.56.155%8, fe80:: - ffff:ffff:fffe%2, fe80::203d:7d97:c2ed:ec78%3, fe80::e8ea:d765:2c69:7756%7 - -In the example above there are two listeners activated. One is listening on port 5985 over HTTP and the other is listening on port 5986 over HTTPS. Some of the key options that are useful to understand are: - -* ``Transport``: Whether the listener is run over HTTP or HTTPS. We recommend you use a listener over HTTPS because the data is encrypted without any further changes required. - -* ``Port``: The port the listener runs on. By default it is ``5985`` for HTTP and ``5986`` for HTTPS. This port can be changed to whatever is required and corresponds to the host var ``ansible_port``. - -* ``URLPrefix``: The URL prefix to listen on. By default it is ``wsman``. If you change this option, you need to set the host var ``ansible_winrm_path`` to the same value. - -* ``CertificateThumbprint``: If you use an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell: - -.. code-block:: powershell - - $thumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE" - Get-ChildItem -Path cert:\LocalMachine\My -Recurse | Where-Object { $_.Thumbprint -eq $thumbprint } | Select-Object * - -Setup WinRM Listener -++++++++++++++++++++ -There are three ways to set up a WinRM listener: - -* Using ``winrm quickconfig`` for HTTP or ``winrm quickconfig -transport:https`` for HTTPS. This is the easiest option to use when running outside of a domain environment and a simple listener is required. Unlike the other options, this process also has the added benefit of opening up the firewall for the ports required and starts the WinRM service. - -* Using Group Policy Objects (GPO). This is the best way to create a listener when the host is a member of a domain because the configuration is done automatically without any user input. For more information on group policy objects, see the `Group Policy Objects documentation `_. - -* Using PowerShell to create a listener with a specific configuration. This can be done by running the following PowerShell commands: - - .. code-block:: powershell - - $selector_set = @{ - Address = "*" - Transport = "HTTPS" - } - $value_set = @{ - CertificateThumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE" - } - - New-WSManInstance -ResourceURI "winrm/config/Listener" -SelectorSet $selector_set -ValueSet $value_set - - To see the other options with this PowerShell command, refer to the - `New-WSManInstance `_ documentation. - -.. Note:: When creating an HTTPS listener, you must create and store a certificate in the ``LocalMachine\My`` certificate store. - -Delete WinRM Listener -+++++++++++++++++++++ -* To remove all WinRM listeners: - -.. code-block:: powershell - - Remove-Item -Path WSMan:\localhost\Listener\* -Recurse -Force - -* To remove only those listeners that run over HTTPS: - -.. code-block:: powershell - - Get-ChildItem -Path WSMan:\localhost\Listener | Where-Object { $_.Keys -contains "Transport=HTTPS" } | Remove-Item -Recurse -Force - -.. Note:: The ``Keys`` object is an array of strings, so it can contain different values. By default, it contains a key for ``Transport=`` and ``Address=`` which correspond to the values from the ``winrm enumerate winrm/config/Listeners`` command. - -WinRM Service Options ---------------------- -You can control the behavior of the WinRM service component, including authentication options and memory settings. - -To get an output of the current service configuration options, run the following command: - -.. code-block:: powershell - - winrm get winrm/config/Service - winrm get winrm/config/Winrs - -This will output something like: - -.. code-block:: powershell - - Service - RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD) - MaxConcurrentOperations = 4294967295 - MaxConcurrentOperationsPerUser = 1500 - EnumerationTimeoutms = 240000 - MaxConnections = 300 - MaxPacketRetrievalTimeSeconds = 120 - AllowUnencrypted = false - Auth - Basic = true - Kerberos = true - Negotiate = true - Certificate = true - CredSSP = true - CbtHardeningLevel = Relaxed - DefaultPorts - HTTP = 5985 - HTTPS = 5986 - IPv4Filter = * - IPv6Filter = * - EnableCompatibilityHttpListener = false - EnableCompatibilityHttpsListener = false - CertificateThumbprint - AllowRemoteAccess = true - - Winrs - AllowRemoteShellAccess = true - IdleTimeout = 7200000 - MaxConcurrentUsers = 2147483647 - MaxShellRunTime = 2147483647 - MaxProcessesPerShell = 2147483647 - MaxMemoryPerShellMB = 2147483647 - MaxShellsPerUser = 2147483647 - -You do not need to change the majority of these options. However, some of the important ones to know about are: - -* ``Service\AllowUnencrypted`` - specifies whether WinRM will allow HTTP traffic without message encryption. Message level encryption is only possible when the ``ansible_winrm_transport`` variable is ``ntlm``, ``kerberos`` or ``credssp``. By default, this is ``false`` and you should only set it to ``true`` when debugging WinRM messages. - -* ``Service\Auth\*`` - defines what authentication options you can use with the WinRM service. By default, ``Negotiate (NTLM)`` and ``Kerberos`` are enabled. - -* ``Service\Auth\CbtHardeningLevel`` - specifies whether channel binding tokens are not verified (None), verified but not required (Relaxed), or verified and required (Strict). CBT is only used when connecting with NT LAN Manager (NTLM) or Kerberos over HTTPS. - -* ``Service\CertificateThumbprint`` - thumbprint of the certificate for encrypting the TLS channel used with CredSSP authentication. By default, this is empty. A self-signed certificate is generated when the WinRM service starts and is used in the TLS process. - -* ``Winrs\MaxShellRunTime`` - maximum time, in milliseconds, that a remote command is allowed to execute. - -* ``Winrs\MaxMemoryPerShellMB`` - maximum amount of memory allocated per shell, including its child processes. - -To modify a setting under the ``Service`` key in PowerShell, you need to provide a path to the option after ``winrm/config/Service``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\{path} -Value {some_value} - -For example, to change ``Service\Auth\CbtHardeningLevel``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\Auth\CbtHardeningLevel -Value Strict - -To modify a setting under the ``Winrs`` key in PowerShell, you need to provide a path to the option after ``winrm/config/Winrs``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Shell\{path} -Value {some_value} - -For example, to change ``Winrs\MaxShellRunTime``: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Shell\MaxShellRunTime -Value 2147483647 - -.. Note:: If you run the command in a domain environment, some of these options are set by - GPO and cannot be changed on the host itself. When you configured a key with GPO, it contains the text ``[Source="GPO"]`` next to the value. - -Common WinRM Issues -------------------- -WinRM has a wide range of configuration options, which makes its configuration complex. As a result, errors that Ansible displays could in fact be problems with the host setup instead. - -To identify a host issue, run the following command from another Windows host to connect to the target Windows host. - -* To test HTTP: - -.. code-block:: powershell - - winrs -r:http://server:5985/wsman -u:Username -p:Password ipconfig - -* To test HTTPS: - -.. code-block:: powershell - - winrs -r:https://server:5986/wsman -u:Username -p:Password -ssl ipconfig - -The command will fail if the certificate is not verifiable. - -* To test HTTPS ignoring certificate verification: - -.. code-block:: powershell - - $username = "Username" - $password = ConvertTo-SecureString -String "Password" -AsPlainText -Force - $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password - - $session_option = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck - Invoke-Command -ComputerName server -UseSSL -ScriptBlock { ipconfig } -Credential $cred -SessionOption $session_option - -If any of the above commands fail, the issue is probably related to the WinRM setup. - -HTTP 401/Credentials Rejected -+++++++++++++++++++++++++++++ -An HTTP 401 error indicates the authentication process failed during the initial -connection. You can check the following to troubleshoot: - -* The credentials are correct and set properly in your inventory with the ``ansible_user`` and ``ansible_password`` variables. - -* The user is a member of the local Administrators group, or has been explicitly granted access. You can perform a connection test with the ``winrs`` command to rule this out. - -* The authentication option set by the ``ansible_winrm_transport`` variable is enabled under ``Service\Auth\*``. - -* If running over HTTP and not HTTPS, use ``ntlm``, ``kerberos`` or ``credssp`` with the ``ansible_winrm_message_encryption: auto`` custom inventory variable to enable message encryption. If you use another authentication option, or if it is not possible to upgrade the installed ``pywinrm`` package, you can set ``Service\AllowUnencrypted`` to ``true``. This is recommended only for troubleshooting. - -* The downstream packages ``pywinrm``, ``requests-ntlm``, ``requests-kerberos``, and/or ``requests-credssp`` are up to date using ``pip``. - -* For Kerberos authentication, ensure that ``Service\Auth\CbtHardeningLevel`` is not set to ``Strict``. - -* For Basic or Certificate authentication, make sure that the user is a local account. Domain accounts do not work with Basic and Certificate authentication. - -HTTP 500 Error -++++++++++++++ -An HTTP 500 error indicates a problem with the WinRM service. You can check the following to troubleshoot: - -* The number of your currently open shells has not exceeded either ``WinRsMaxShellsPerUser``. Alternatively, you did not exceed any of the other Winrs quotas. - -Timeout Errors -+++++++++++++++ -Sometimes Ansible is unable to reach the host. These instances usually indicate a problem with the network connection. You can check the following to troubleshoot: - -* The firewall is not set to block the configured WinRM listener ports. -* A WinRM listener is enabled on the port and path set by the host vars. -* The ``winrm`` service is running on the Windows host and is configured for the automatic start. - -Connection Refused Errors -+++++++++++++++++++++++++ -When you communicate with the WinRM service on the host you can encounter some problems. Check the following to help the troubleshooting: - -* The WinRM service is up and running on the host. Use the ``(Get-Service -Name winrm).Status`` command to get the status of the service. -* The host firewall is allowing traffic over the WinRM port. By default this is ``5985`` for HTTP and ``5986`` for HTTPS. - -Sometimes an installer may restart the WinRM or HTTP service and cause this error. The best way to deal with this is to use the ``win_psexec`` module from another Windows host. - -Failure to Load Builtin Modules -+++++++++++++++++++++++++++++++ -Sometimes PowerShell fails with an error message similar to: - -.. code-block:: powershell - - The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded. - -In that case, there could be a problem when trying to access all the paths specified by the ``PSModulePath`` environment variable. - -A common cause of this issue is that ``PSModulePath`` contains a Universal Naming Convention (UNC) path to a file share. Additionally, the double hop/credential delegation issue causes that the Ansible process cannot access these folders. To work around this problem is to either: - -* Remove the UNC path from ``PSModulePath``. - -or - -* Use an authentication option that supports credential delegation like ``credssp`` or ``kerberos``. You need to have the credential delegation enabled. - -See `KB4076842 `_ for more information on this problem. - -Windows SSH Setup -````````````````` -Ansible 2.8 has added an experimental SSH connection for Windows managed nodes. - -.. warning:: - Use this feature at your own risk! Using SSH with Windows is experimental. This implementation may make - backwards incompatible changes in future releases. The server-side components can be unreliable depending on your installed version. - -Installing OpenSSH using Windows Settings ------------------------------------------ -You can use OpenSSH to connect Window 10 clients to Windows Server 2019. OpenSSH Client is available to install on Windows 10 build 1809 and later. OpenSSH Server is available to install on Windows Server 2019 and later. - -For more information, refer to `Get started with OpenSSH for Windows `_. - -Installing Win32-OpenSSH ------------------------- -To install the `Win32-OpenSSH `_ service for use with -Ansible, select one of these installation options: - -* Manually install ``Win32-OpenSSH``, following the `install instructions `_ from Microsoft. - -* Use Chocolatey: - -.. code-block:: powershell - - choco install --package-parameters=/SSHServerFeature openssh - -* Use the ``win_chocolatey`` Ansible module: - -.. code-block:: yaml - - - name: install the Win32-OpenSSH service - win_chocolatey: - name: openssh - package_params: /SSHServerFeature - state: present - -* Install an Ansible Galaxy role for example `jborean93.win_openssh `_: - -.. code-block:: powershell - - ansible-galaxy install jborean93.win_openssh - -* Use the role in your playbook: - -.. code-block:: yaml - - - name: install Win32-OpenSSH service - hosts: windows - gather_facts: false - roles: - - role: jborean93.win_openssh - opt_openssh_setup_service: True - -.. note:: ``Win32-OpenSSH`` is still a beta product and is constantly being updated to include new features and bugfixes. If you use SSH as a connection option for Windows, we highly recommend you install the latest version. - -Configuring the Win32-OpenSSH shell ------------------------------------ - -By default ``Win32-OpenSSH`` uses ``cmd.exe`` as a shell. - -* To configure a different shell, use an Ansible playbook with a task to define the registry setting: - -.. code-block:: yaml - - - name: set the default shell to PowerShell - win_regedit: - path: HKLM:\SOFTWARE\OpenSSH - name: DefaultShell - data: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - type: string - state: present - -* To revert the settings back to the default shell: - -.. code-block:: yaml - - - name: set the default shell to cmd - win_regedit: - path: HKLM:\SOFTWARE\OpenSSH - name: DefaultShell - state: absent - -Win32-OpenSSH Authentication ----------------------------- -Win32-OpenSSH authentication with Windows is similar to SSH authentication on Unix/Linux hosts. You can use a plaintext password or SSH public key authentication. - -For the key-based authentication: - -* Add your public keys to an ``authorized_key`` file in the ``.ssh`` folder of the user's profile directory. - -* Configure the SSH service using the ``sshd_config`` file. - -When using SSH key authentication with Ansible, the remote session will not have access to user credentials and will fail when attempting to access a network resource. This is also known as the double-hop or credential delegation issue. To work around this problem: - -* Use plaintext password authentication by setting the ``ansible_password`` variable. -* Use the ``become`` directive on the task with the credentials of the user that needs access to the remote resource. - -Configuring Ansible for SSH on Windows --------------------------------------- -To configure Ansible to use SSH for Windows hosts, you must set two connection variables: - -* set ``ansible_connection`` to ``ssh`` -* set ``ansible_shell_type`` to ``cmd`` or ``powershell`` - -The ``ansible_shell_type`` variable should reflect the ``DefaultShell`` configured on the Windows host. Set ``ansible_shell_type`` to ``cmd`` for the default shell. Alternatively, set ``ansible_shell_type`` to ``powershell`` if you changed ``DefaultShell`` to PowerShell. - -Known issues with SSH on Windows --------------------------------- -Using SSH with Windows is experimental. Currently existing issues are: - -* Win32-OpenSSH versions older than ``v7.9.0.0p1-Beta`` do not work when ``powershell`` is the shell type. -* While Secure Copy Protocol (SCP) should work, SSH File Transfer Protocol (SFTP) is the recommended mechanism to use when copying or fetching a file. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_usage.rst b/docs/docsite/rst/os_guide/windows_usage.rst deleted file mode 100644 index 0e76646efab..00000000000 --- a/docs/docsite/rst/os_guide/windows_usage.rst +++ /dev/null @@ -1,519 +0,0 @@ -.. _windows_usage: - -Using Ansible and Windows -========================= -When using Ansible to manage Windows, many of the syntax and rules that apply -for Unix/Linux hosts also apply to Windows, but there are still some differences -when it comes to components like path separators and OS-specific tasks. -This document covers details specific to using Ansible for Windows. - -.. contents:: Topics - :local: - -Use Cases -````````` -Ansible can be used to orchestrate a multitude of tasks on Windows servers. -Below are some examples and info about common tasks. - -Installing Software -------------------- -There are three main ways that Ansible can be used to install software: - -* Using the ``win_chocolatey`` module. This sources the program data from the default - public `Chocolatey `_ repository. Internal repositories can - be used instead by setting the ``source`` option. - -* Using the ``win_package`` module. This installs software using an MSI or .exe installer - from a local/network path or URL. - -* Using the ``win_command`` or ``win_shell`` module to run an installer manually. - -The ``win_chocolatey`` module is recommended since it has the most complete logic for checking to see if a package has already been installed and is up-to-date. - -Below are some examples of using all three options to install 7-Zip: - -.. code-block:: yaml+jinja - - # Install/uninstall with chocolatey - - name: Ensure 7-Zip is installed through Chocolatey - win_chocolatey: - name: 7zip - state: present - - - name: Ensure 7-Zip is not installed through Chocolatey - win_chocolatey: - name: 7zip - state: absent - - # Install/uninstall with win_package - - name: Download the 7-Zip package - win_get_url: - url: https://www.7-zip.org/a/7z1701-x64.msi - dest: C:\temp\7z.msi - - - name: Ensure 7-Zip is installed through win_package - win_package: - path: C:\temp\7z.msi - state: present - - - name: Ensure 7-Zip is not installed through win_package - win_package: - path: C:\temp\7z.msi - state: absent - - # Install/uninstall with win_command - - name: Download the 7-Zip package - win_get_url: - url: https://www.7-zip.org/a/7z1701-x64.msi - dest: C:\temp\7z.msi - - - name: Check if 7-Zip is already installed - win_reg_stat: - name: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{23170F69-40C1-2702-1701-000001000000} - register: 7zip_installed - - - name: Ensure 7-Zip is installed through win_command - win_command: C:\Windows\System32\msiexec.exe /i C:\temp\7z.msi /qn /norestart - when: 7zip_installed.exists == false - - - name: Ensure 7-Zip is uninstalled through win_command - win_command: C:\Windows\System32\msiexec.exe /x {23170F69-40C1-2702-1701-000001000000} /qn /norestart - when: 7zip_installed.exists == true - -Some installers like Microsoft Office or SQL Server require credential delegation or -access to components restricted by WinRM. The best method to bypass these -issues is to use ``become`` with the task. With ``become``, Ansible will run -the installer as if it were run interactively on the host. - -.. Note:: Many installers do not properly pass back error information over WinRM. In these cases, if the install has been verified to work locally the recommended method is to use become. - -.. Note:: Some installers restart the WinRM or HTTP services, or cause them to become temporarily unavailable, making Ansible assume the system is unreachable. - -Installing Updates ------------------- -The ``win_updates`` and ``win_hotfix`` modules can be used to install updates -or hotfixes on a host. The module ``win_updates`` is used to install multiple -updates by category, while ``win_hotfix`` can be used to install a single -update or hotfix file that has been downloaded locally. - -.. Note:: The ``win_hotfix`` module has a requirement that the DISM PowerShell cmdlets are - present. These cmdlets were only added by default on Windows Server 2012 - and newer and must be installed on older Windows hosts. - -The following example shows how ``win_updates`` can be used: - -.. code-block:: yaml+jinja - - - name: Install all critical and security updates - win_updates: - category_names: - - CriticalUpdates - - SecurityUpdates - state: installed - register: update_result - - - name: Reboot host if required - win_reboot: - when: update_result.reboot_required - -The following example show how ``win_hotfix`` can be used to install a single -update or hotfix: - -.. code-block:: yaml+jinja - - - name: Download KB3172729 for Server 2012 R2 - win_get_url: - url: http://download.windowsupdate.com/d/msdownload/update/software/secu/2016/07/windows8.1-kb3172729-x64_e8003822a7ef4705cbb65623b72fd3cec73fe222.msu - dest: C:\temp\KB3172729.msu - - - name: Install hotfix - win_hotfix: - hotfix_kb: KB3172729 - source: C:\temp\KB3172729.msu - state: present - register: hotfix_result - - - name: Reboot host if required - win_reboot: - when: hotfix_result.reboot_required - -Set Up Users and Groups ------------------------ -Ansible can be used to create Windows users and groups both locally and on a domain. - -Local -+++++ -The modules ``win_user``, ``win_group`` and ``win_group_membership`` manage -Windows users, groups and group memberships locally. - -The following is an example of creating local accounts and groups that can -access a folder on the same host: - -.. code-block:: yaml+jinja - - - name: Create local group to contain new users - win_group: - name: LocalGroup - description: Allow access to C:\Development folder - - - name: Create local user - win_user: - name: '{{ item.name }}' - password: '{{ item.password }}' - groups: LocalGroup - update_password: false - password_never_expires: true - loop: - - name: User1 - password: Password1 - - name: User2 - password: Password2 - - - name: Create Development folder - win_file: - path: C:\Development - state: directory - - - name: Set ACL of Development folder - win_acl: - path: C:\Development - rights: FullControl - state: present - type: allow - user: LocalGroup - - - name: Remove parent inheritance of Development folder - win_acl_inheritance: - path: C:\Development - reorganize: true - state: absent - -Domain -++++++ -The modules ``win_domain_user`` and ``win_domain_group`` manages users and -groups in a domain. The below is an example of ensuring a batch of domain users -are created: - -.. code-block:: yaml+jinja - - - name: Ensure each account is created - win_domain_user: - name: '{{ item.name }}' - upn: '{{ item.name }}@MY.DOMAIN.COM' - password: '{{ item.password }}' - password_never_expires: false - groups: - - Test User - - Application - company: Ansible - update_password: on_create - loop: - - name: Test User - password: Password - - name: Admin User - password: SuperSecretPass01 - - name: Dev User - password: '@fvr3IbFBujSRh!3hBg%wgFucD8^x8W5' - -Running Commands ----------------- -In cases where there is no appropriate module available for a task, -a command or script can be run using the ``win_shell``, ``win_command``, ``raw``, and ``script`` modules. - -The ``raw`` module simply executes a Powershell command remotely. Since ``raw`` -has none of the wrappers that Ansible typically uses, ``become``, ``async`` -and environment variables do not work. - -The ``script`` module executes a script from the Ansible controller on -one or more Windows hosts. Like ``raw``, ``script`` currently does not support -``become``, ``async``, or environment variables. - -The ``win_command`` module is used to execute a command which is either an -executable or batch file, while the ``win_shell`` module is used to execute commands within a shell. - -Choosing Command or Shell -+++++++++++++++++++++++++ -The ``win_shell`` and ``win_command`` modules can both be used to execute a command or commands. -The ``win_shell`` module is run within a shell-like process like ``PowerShell`` or ``cmd``, so it has access to shell -operators like ``<``, ``>``, ``|``, ``;``, ``&&``, and ``||``. Multi-lined commands can also be run in ``win_shell``. - -The ``win_command`` module simply runs a process outside of a shell. It can still -run a shell command like ``mkdir`` or ``New-Item`` by passing the shell commands -to a shell executable like ``cmd.exe`` or ``PowerShell.exe``. - -Here are some examples of using ``win_command`` and ``win_shell``: - -.. code-block:: yaml+jinja - - - name: Run a command under PowerShell - win_shell: Get-Service -Name service | Stop-Service - - - name: Run a command under cmd - win_shell: mkdir C:\temp - args: - executable: cmd.exe - - - name: Run a multiple shell commands - win_shell: | - New-Item -Path C:\temp -ItemType Directory - Remove-Item -Path C:\temp -Force -Recurse - $path_info = Get-Item -Path C:\temp - $path_info.FullName - - - name: Run an executable using win_command - win_command: whoami.exe - - - name: Run a cmd command - win_command: cmd.exe /c mkdir C:\temp - - - name: Run a vbs script - win_command: cscript.exe script.vbs - -.. Note:: Some commands like ``mkdir``, ``del``, and ``copy`` only exist in - the CMD shell. To run them with ``win_command`` they must be - prefixed with ``cmd.exe /c``. - -Argument Rules -++++++++++++++ -When running a command through ``win_command``, the standard Windows argument -rules apply: - -* Each argument is delimited by a white space, which can either be a space or a - tab. - -* An argument can be surrounded by double quotes ``"``. Anything inside these - quotes is interpreted as a single argument even if it contains whitespace. - -* A double quote preceded by a backslash ``\`` is interpreted as just a double - quote ``"`` and not as an argument delimiter. - -* Backslashes are interpreted literally unless it immediately precedes double - quotes; for example ``\`` == ``\`` and ``\"`` == ``"`` - -* If an even number of backslashes is followed by a double quote, one - backslash is used in the argument for every pair, and the double quote is - used as a string delimiter for the argument. - -* If an odd number of backslashes is followed by a double quote, one backslash - is used in the argument for every pair, and the double quote is escaped and - made a literal double quote in the argument. - -With those rules in mind, here are some examples of quoting: - -.. code-block:: yaml+jinja - - - win_command: C:\temp\executable.exe argument1 "argument 2" "C:\path\with space" "double \"quoted\"" - - argv[0] = C:\temp\executable.exe - argv[1] = argument1 - argv[2] = argument 2 - argv[3] = C:\path\with space - argv[4] = double "quoted" - - - win_command: '"C:\Program Files\Program\program.exe" "escaped \\\" backslash" unquoted-end-backslash\' - - argv[0] = C:\Program Files\Program\program.exe - argv[1] = escaped \" backslash - argv[2] = unquoted-end-backslash\ - - # Due to YAML and Ansible parsing '\"' must be written as '{% raw %}\\{% endraw %}"' - - win_command: C:\temp\executable.exe C:\no\space\path "arg with end \ before end quote{% raw %}\\{% endraw %}" - - argv[0] = C:\temp\executable.exe - argv[1] = C:\no\space\path - argv[2] = arg with end \ before end quote\" - -For more information, see `escaping arguments `_. - -Creating and Running a Scheduled Task -------------------------------------- -WinRM has some restrictions in place that cause errors when running certain -commands. One way to bypass these restrictions is to run a command through a -scheduled task. A scheduled task is a Windows component that provides the -ability to run an executable on a schedule and under a different account. - -Ansible version 2.5 added modules that make it easier to work with scheduled tasks in Windows. -The following is an example of running a script as a scheduled task that deletes itself after -running: - -.. code-block:: yaml+jinja - - - name: Create scheduled task to run a process - win_scheduled_task: - name: adhoc-task - username: SYSTEM - actions: - - path: PowerShell.exe - arguments: | - Start-Sleep -Seconds 30 # This isn't required, just here as a demonstration - New-Item -Path C:\temp\test -ItemType Directory - # Remove this action if the task shouldn't be deleted on completion - - path: cmd.exe - arguments: /c schtasks.exe /Delete /TN "adhoc-task" /F - triggers: - - type: registration - - - name: Wait for the scheduled task to complete - win_scheduled_task_stat: - name: adhoc-task - register: task_stat - until: (task_stat.state is defined and task_stat.state.status != "TASK_STATE_RUNNING") or (task_stat.task_exists == False) - retries: 12 - delay: 10 - -.. Note:: The modules used in the above example were updated/added in Ansible - version 2.5. - -Path Formatting for Windows -``````````````````````````` -Windows differs from a traditional POSIX operating system in many ways. One of -the major changes is the shift from ``/`` as the path separator to ``\``. This -can cause major issues with how playbooks are written, since ``\`` is often used -as an escape character on POSIX systems. - -Ansible allows two different styles of syntax; each deals with path separators for Windows differently: - -YAML Style ----------- -When using the YAML syntax for tasks, the rules are well-defined by the YAML -standard: - -* When using a normal string (without quotes), YAML will not consider the - backslash an escape character. - -* When using single quotes ``'``, YAML will not consider the backslash an - escape character. - -* When using double quotes ``"``, the backslash is considered an escape - character and needs to escaped with another backslash. - -.. Note:: You should only quote strings when it is absolutely - necessary or required by YAML, and then use single quotes. - -The YAML specification considers the following `escape sequences `_: - -* ``\0``, ``\\``, ``\"``, ``\_``, ``\a``, ``\b``, ``\e``, ``\f``, ``\n``, ``\r``, ``\t``, - ``\v``, ``\L``, ``\N`` and ``\P`` -- Single character escape - -* ````, ````, ````, ````, ```` -- Special - characters - -* ``\x..`` -- 2-digit hex escape - -* ``\u....`` -- 4-digit hex escape - -* ``\U........`` -- 8-digit hex escape - -Here are some examples on how to write Windows paths: - -.. code-block:: ini - - # GOOD - tempdir: C:\Windows\Temp - - # WORKS - tempdir: 'C:\Windows\Temp' - tempdir: "C:\\Windows\\Temp" - - # BAD, BUT SOMETIMES WORKS - tempdir: C:\\Windows\\Temp - tempdir: 'C:\\Windows\\Temp' - tempdir: C:/Windows/Temp - -This is an example which will fail: - -.. code-block:: text - - # FAILS - tempdir: "C:\Windows\Temp" - -This example shows the use of single quotes when they are required: - -.. code-block:: yaml+jinja - - --- - - name: Copy tomcat config - win_copy: - src: log4j.xml - dest: '{{tc_home}}\lib\log4j.xml' - -Legacy key=value Style ----------------------- -The legacy ``key=value`` syntax is used on the command line for ad hoc commands, -or inside playbooks. The use of this style is discouraged within playbooks -because backslash characters need to be escaped, making playbooks harder to read. -The legacy syntax depends on the specific implementation in Ansible, and quoting -(both single and double) does not have any effect on how it is parsed by -Ansible. - -The Ansible key=value parser parse_kv() considers the following escape -sequences: - -* ``\``, ``'``, ``"``, ``\a``, ``\b``, ``\f``, ``\n``, ``\r``, ``\t`` and - ``\v`` -- Single character escape - -* ``\x..`` -- 2-digit hex escape - -* ``\u....`` -- 4-digit hex escape - -* ``\U........`` -- 8-digit hex escape - -* ``\N{...}`` -- Unicode character by name - -This means that the backslash is an escape character for some sequences, and it -is usually safer to escape a backslash when in this form. - -Here are some examples of using Windows paths with the key=value style: - -.. code-block:: ini - - # GOOD - tempdir=C:\\Windows\\Temp - - # WORKS - tempdir='C:\\Windows\\Temp' - tempdir="C:\\Windows\\Temp" - - # BAD, BUT SOMETIMES WORKS - tempdir=C:\Windows\Temp - tempdir='C:\Windows\Temp' - tempdir="C:\Windows\Temp" - tempdir=C:/Windows/Temp - - # FAILS - tempdir=C:\Windows\temp - tempdir='C:\Windows\temp' - tempdir="C:\Windows\temp" - -The failing examples don't fail outright but will substitute ``\t`` with the -```` character resulting in ``tempdir`` being ``C:\Windowsemp``. - -Limitations -``````````` -Some things you cannot do with Ansible and Windows are: - -* Upgrade PowerShell - -* Interact with the WinRM listeners - -Because WinRM is reliant on the services being online and running during normal operations, you cannot upgrade PowerShell or interact with WinRM listeners with Ansible. Both of these actions will cause the connection to fail. This can technically be avoided by using ``async`` or a scheduled task, but those methods are fragile if the process it runs breaks the underlying connection Ansible uses, and are best left to the bootstrapping process or before an image is -created. - -Developing Windows Modules -`````````````````````````` -Because Ansible modules for Windows are written in PowerShell, the development -guides for Windows modules differ substantially from those for standard standard modules. Please see -:ref:`developing_modules_general_windows` for more information. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/os_guide/windows_winrm.rst b/docs/docsite/rst/os_guide/windows_winrm.rst deleted file mode 100644 index 242cd1f7b7b..00000000000 --- a/docs/docsite/rst/os_guide/windows_winrm.rst +++ /dev/null @@ -1,1013 +0,0 @@ -.. _windows_winrm: - -Windows Remote Management -========================= -Unlike Linux/Unix hosts, which use SSH by default, Windows hosts are -configured with WinRM. This topic covers how to configure and use WinRM with Ansible. - -.. contents:: - :local: - :depth: 2 - - -What is WinRM? ----------------- - -WinRM is a management protocol used by Windows to remotely communicate with -another server. It is a SOAP-based protocol that communicates over HTTP/HTTPS, and is -included in all recent Windows operating systems. Since Windows -Server 2012, WinRM has been enabled by default, but in most cases extra -configuration is required to use WinRM with Ansible. - -Ansible uses the `pywinrm `_ package to -communicate with Windows servers over WinRM. It is not installed by default -with the Ansible package, but can be installed by running the following: - -.. code-block:: shell - - pip install "pywinrm>=0.3.0" - -.. Note:: on distributions with multiple python versions, use pip2 or pip2.x, - where x matches the python minor version Ansible is running under. - -.. Warning:: - Using the ``winrm`` or ``psrp`` connection plugins in Ansible on MacOS in - the latest releases typically fail. This is a known problem that occurs - deep within the Python stack and cannot be changed by Ansible. The only - workaround today is to set the environment variable ``no_proxy=*`` and - avoid using Kerberos auth. - - -.. _winrm_auth: - -WinRM authentication options ------------------------------ - -When connecting to a Windows host, there are several different options that can be used -when authenticating with an account. The authentication type may be set on inventory -hosts or groups with the ``ansible_winrm_transport`` variable. - -The following matrix is a high level overview of the options: - -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| Option | Local Accounts | Active Directory Accounts | Credential Delegation | HTTP Encryption | -+=============+================+===========================+=======================+=================+ -| Basic | Yes | No | No | No | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| Certificate | Yes | No | No | No | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| Kerberos | No | Yes | Yes | Yes | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| NTLM | Yes | Yes | No | Yes | -+-------------+----------------+---------------------------+-----------------------+-----------------+ -| CredSSP | Yes | Yes | Yes | Yes | -+-------------+----------------+---------------------------+-----------------------+-----------------+ - -.. _winrm_basic: - -Basic -^^^^^^ - -Basic authentication is one of the simplest authentication options to use, but is -also the most insecure. This is because the username and password are simply -base64 encoded, and if a secure channel is not in use (eg, HTTPS) then it can be -decoded by anyone. Basic authentication can only be used for local accounts (not domain accounts). - -The following example shows host vars configured for basic authentication: - -.. code-block:: yaml+jinja - - ansible_user: LocalUsername - ansible_password: Password - ansible_connection: winrm - ansible_winrm_transport: basic - -Basic authentication is not enabled by default on a Windows host but can be -enabled by running the following in PowerShell: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $true - - -.. _winrm_certificate: - -Certificate -^^^^^^^^^^^^ - -Certificate authentication uses certificates as keys similar to SSH key -pairs, but the file format and key generation process is different. - -The following example shows host vars configured for certificate authentication: - -.. code-block:: yaml+jinja - - ansible_connection: winrm - ansible_winrm_cert_pem: /path/to/certificate/public/key.pem - ansible_winrm_cert_key_pem: /path/to/certificate/private/key.pem - ansible_winrm_transport: certificate - -Certificate authentication is not enabled by default on a Windows host but can -be enabled by running the following in PowerShell: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\Auth\Certificate -Value $true - -.. Note:: Encrypted private keys cannot be used as the urllib3 library that - is used by Ansible for WinRM does not support this functionality. - -.. Note:: Certificate authentication does not work with a TLS 1.3 connection. - -.._winrm_certificate_generate: - -Generate a Certificate -++++++++++++++++++++++ - -A certificate must be generated before it can be mapped to a local user. -This can be done using one of the following methods: - -* OpenSSL -* PowerShell, using the ``New-SelfSignedCertificate`` cmdlet -* Active Directory Certificate Services - -Active Directory Certificate Services is beyond of scope in this documentation but may be -the best option to use when running in a domain environment. For more information, -see the `Active Directory Certificate Services documentation `_. - -.. Note:: Using the PowerShell cmdlet ``New-SelfSignedCertificate`` to generate - a certificate for authentication only works when being generated from a - Windows 10 or Windows Server 2012 R2 host or later. OpenSSL is still required to - extract the private key from the PFX certificate to a PEM file for Ansible - to use. - -To generate a certificate with ``OpenSSL``: - -.. code-block:: shell - - # Set the name of the local user that will have the key mapped to - USERNAME="username" - - cat > openssl.conf << EOL - distinguished_name = req_distinguished_name - [req_distinguished_name] - [v3_req_client] - extendedKeyUsage = clientAuth - subjectAltName = otherName:1.3.6.1.4.1.311.20.2.3;UTF8:$USERNAME@localhost - EOL - - export OPENSSL_CONF=openssl.conf - openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out cert.pem -outform PEM -keyout cert_key.pem -subj "/CN=$USERNAME" -extensions v3_req_client - rm openssl.conf - - -To generate a certificate with ``New-SelfSignedCertificate``: - -.. code-block:: powershell - - # Set the name of the local user that will have the key mapped - $username = "username" - $output_path = "C:\temp" - - # Instead of generating a file, the cert will be added to the personal - # LocalComputer folder in the certificate store - $cert = New-SelfSignedCertificate -Type Custom ` - -Subject "CN=$username" ` - -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}upn=$username@localhost") ` - -KeyUsage DigitalSignature,KeyEncipherment ` - -KeyAlgorithm RSA ` - -KeyLength 2048 - - # Export the public key - $pem_output = @() - $pem_output += "-----BEGIN CERTIFICATE-----" - $pem_output += [System.Convert]::ToBase64String($cert.RawData) -replace ".{64}", "$&`n" - $pem_output += "-----END CERTIFICATE-----" - [System.IO.File]::WriteAllLines("$output_path\cert.pem", $pem_output) - - # Export the private key in a PFX file - [System.IO.File]::WriteAllBytes("$output_path\cert.pfx", $cert.Export("Pfx")) - - -.. Note:: To convert the PFX file to a private key that pywinrm can use, run - the following command with OpenSSL - ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:`` - -.. _winrm_certificate_import: - -Import a Certificate to the Certificate Store -+++++++++++++++++++++++++++++++++++++++++++++ - -Once a certificate has been generated, the issuing certificate needs to be -imported into the ``Trusted Root Certificate Authorities`` of the -``LocalMachine`` store, and the client certificate public key must be present -in the ``Trusted People`` folder of the ``LocalMachine`` store. For this example, -both the issuing certificate and public key are the same. - -Following example shows how to import the issuing certificate: - -.. code-block:: powershell - - $cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 "cert.pem" - - $store_name = [System.Security.Cryptography.X509Certificates.StoreName]::Root - $store_location = [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine - $store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $store_name, $store_location - $store.Open("MaxAllowed") - $store.Add($cert) - $store.Close() - - -.. Note:: If using ADCS to generate the certificate, then the issuing - certificate will already be imported and this step can be skipped. - -The code to import the client certificate public key is: - -.. code-block:: powershell - - $cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 "cert.pem" - - $store_name = [System.Security.Cryptography.X509Certificates.StoreName]::TrustedPeople - $store_location = [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine - $store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $store_name, $store_location - $store.Open("MaxAllowed") - $store.Add($cert) - $store.Close() - - -.. _winrm_certificate_mapping: - -Mapping a Certificate to an Account -+++++++++++++++++++++++++++++++++++ - -Once the certificate has been imported, map it to the local user account: - -.. code-block:: powershell - - $username = "username" - $password = ConvertTo-SecureString -String "password" -AsPlainText -Force - $credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password - - # This is the issuer thumbprint which in the case of a self generated cert - # is the public key thumbprint, additional logic may be required for other - # scenarios - $thumbprint = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object { $_.Subject -eq "CN=$username" }).Thumbprint - - New-Item -Path WSMan:\localhost\ClientCertificate ` - -Subject "$username@localhost" ` - -URI * ` - -Issuer $thumbprint ` - -Credential $credential ` - -Force - - -Once this is complete, the hostvar ``ansible_winrm_cert_pem`` should be set to -the path of the public key and the ``ansible_winrm_cert_key_pem`` variable should be set to -the path of the private key. - - -.. _winrm_ntlm: - -NTLM -^^^^^ - -NTLM is an older authentication mechanism used by Microsoft that can support -both local and domain accounts. NTLM is enabled by default on the WinRM -service, so no setup is required before using it. - -NTLM is the easiest authentication protocol to use and is more secure than -``Basic`` authentication. If running in a domain environment, ``Kerberos`` should be used -instead of NTLM. - -Kerberos has several advantages over using NTLM: - -* NTLM is an older protocol and does not support newer encryption - protocols. -* NTLM is slower to authenticate because it requires more round trips to the host in - the authentication stage. -* Unlike Kerberos, NTLM does not allow credential delegation. - -This example shows host variables configured to use NTLM authentication: - -.. code-block:: yaml+jinja - - ansible_user: LocalUsername - ansible_password: Password - ansible_connection: winrm - ansible_winrm_transport: ntlm - -.. _winrm_kerberos: - -Kerberos -^^^^^^^^^ - -Kerberos is the recommended authentication option to use when running in a -domain environment. Kerberos supports features like credential delegation and -message encryption over HTTP and is one of the more secure options that -is available through WinRM. - -Kerberos requires some additional setup work on the Ansible host before it can be -used properly. - -The following example shows host vars configured for Kerberos authentication: - -.. code-block:: yaml+jinja - - ansible_user: username@MY.DOMAIN.COM - ansible_password: Password - ansible_connection: winrm - ansible_port: 5985 - ansible_winrm_transport: kerberos - -As of Ansible version 2.3, the Kerberos ticket will be created based on -``ansible_user`` and ``ansible_password``. If running on an older version of -Ansible or when ``ansible_winrm_kinit_mode`` is ``manual``, a Kerberos -ticket must already be obtained. See below for more details. - -There are some extra host variables that can be set: - -.. code-block:: yaml - - ansible_winrm_kinit_mode: managed/manual (manual means Ansible will not obtain a ticket) - ansible_winrm_kinit_cmd: the kinit binary to use to obtain a Kerberos ticket (default to kinit) - ansible_winrm_service: overrides the SPN prefix that is used, the default is ``HTTP`` and should rarely ever need changing - ansible_winrm_kerberos_delegation: allows the credentials to traverse multiple hops - ansible_winrm_kerberos_hostname_override: the hostname to be used for the kerberos exchange - -.. _winrm_kerberos_install: - -Installing the Kerberos Library -+++++++++++++++++++++++++++++++ - -Some system dependencies that must be installed prior to using Kerberos. The script below lists the dependencies based on the distro: - -.. code-block:: shell - - # Through Yum (RHEL/Centos/Fedora for the older version) - yum -y install gcc python-devel krb5-devel krb5-libs krb5-workstation - - # Through DNF (RHEL/Centos/Fedora for the newer version) - dnf -y install gcc python3-devel krb5-devel krb5-libs krb5-workstation - - # Through Apt (Ubuntu) - sudo apt-get install python-dev libkrb5-dev krb5-user - - # Through Portage (Gentoo) - emerge -av app-crypt/mit-krb5 - emerge -av dev-python/setuptools - - # Through Pkg (FreeBSD) - sudo pkg install security/krb5 - - # Through OpenCSW (Solaris) - pkgadd -d http://get.opencsw.org/now - /opt/csw/bin/pkgutil -U - /opt/csw/bin/pkgutil -y -i libkrb5_3 - - # Through Pacman (Arch Linux) - pacman -S krb5 - - -Once the dependencies have been installed, the ``python-kerberos`` wrapper can -be install using ``pip``: - -.. code-block:: shell - - pip install pywinrm[kerberos] - - -.. note:: - While Ansible has supported Kerberos auth through ``pywinrm`` for some - time, optional features or more secure options may only be available in - newer versions of the ``pywinrm`` and/or ``pykerberos`` libraries. It is - recommended you upgrade each version to the latest available to resolve - any warnings or errors. This can be done through tools like ``pip`` or a - system package manager like ``dnf``, ``yum``, ``apt`` but the package - names and versions available may differ between tools. - - -.. _winrm_kerberos_config: - -Configuring Host Kerberos -+++++++++++++++++++++++++ - -Once the dependencies have been installed, Kerberos needs to be configured so -that it can communicate with a domain. This configuration is done through the -``/etc/krb5.conf`` file, which is installed with the packages in the script above. - -To configure Kerberos, in the section that starts with: - -.. code-block:: ini - - [realms] - -Add the full domain name and the fully qualified domain names of the primary -and secondary Active Directory domain controllers. It should look something -like this: - -.. code-block:: ini - - [realms] - MY.DOMAIN.COM = { - kdc = domain-controller1.my.domain.com - kdc = domain-controller2.my.domain.com - } - -In the section that starts with: - -.. code-block:: ini - - [domain_realm] - -Add a line like the following for each domain that Ansible needs access for: - -.. code-block:: ini - - [domain_realm] - .my.domain.com = MY.DOMAIN.COM - -You can configure other settings in this file such as the default domain. See -`krb5.conf `_ -for more details. - -.. _winrm_kerberos_ticket_auto: - -Automatic Kerberos Ticket Management -++++++++++++++++++++++++++++++++++++ - -Ansible version 2.3 and later defaults to automatically managing Kerberos tickets -when both ``ansible_user`` and ``ansible_password`` are specified for a host. In -this process, a new ticket is created in a temporary credential cache for each -host. This is done before each task executes to minimize the chance of ticket -expiration. The temporary credential caches are deleted after each task -completes and will not interfere with the default credential cache. - -To disable automatic ticket management, set ``ansible_winrm_kinit_mode=manual`` -through the inventory. - -Automatic ticket management requires a standard ``kinit`` binary on the control -host system path. To specify a different location or binary name, set the -``ansible_winrm_kinit_cmd`` hostvar to the fully qualified path to a MIT krbv5 -``kinit``-compatible binary. - -.. _winrm_kerberos_ticket_manual: - -Manual Kerberos Ticket Management -+++++++++++++++++++++++++++++++++ - -To manually manage Kerberos tickets, the ``kinit`` binary is used. To -obtain a new ticket the following command is used: - -.. code-block:: shell - - kinit username@MY.DOMAIN.COM - -.. Note:: The domain must match the configured Kerberos realm exactly, and must be in upper case. - -To see what tickets (if any) have been acquired, use the following command: - -.. code-block:: shell - - klist - -To destroy all the tickets that have been acquired, use the following command: - -.. code-block:: shell - - kdestroy - -.. _winrm_kerberos_troubleshoot: - -Troubleshooting Kerberos -++++++++++++++++++++++++ - -Kerberos is reliant on a properly-configured environment to -work. To troubleshoot Kerberos issues, ensure that: - -* The hostname set for the Windows host is the FQDN and not an IP address. - * If you connect using an IP address you will get the error message `Server not found in Kerberos database`. - * To determine if you are connecting using an IP address or an FQDN run your playbook (or call the ``win_ping`` module) using the `-vvv` flag. - -* The forward and reverse DNS lookups are working properly in the domain. To - test this, ping the windows host by name and then use the ip address returned - with ``nslookup``. The same name should be returned when using ``nslookup`` - on the IP address. - -* The Ansible host's clock is synchronized with the domain controller. Kerberos - is time sensitive, and a little clock drift can cause the ticket generation - process to fail. - -* Ensure that the fully qualified domain name for the domain is configured in - the ``krb5.conf`` file. To check this, run: - - .. code-block:: console - - kinit -C username@MY.DOMAIN.COM - klist - - If the domain name returned by ``klist`` is different from the one requested, - an alias is being used. The ``krb5.conf`` file needs to be updated so that - the fully qualified domain name is used and not an alias. - -* If the default kerberos tooling has been replaced or modified (some IdM solutions may do this), this may cause issues when installing or upgrading the Python Kerberos library. As of the time of this writing, this library is called ``pykerberos`` and is known to work with both MIT and Heimdal Kerberos libraries. To resolve ``pykerberos`` installation issues, ensure the system dependencies for Kerberos have been met (see: `Installing the Kerberos Library`_), remove any custom Kerberos tooling paths from the PATH environment variable, and retry the installation of Python Kerberos library package. - -.. _winrm_credssp: - -CredSSP -^^^^^^^ - -CredSSP authentication is a newer authentication protocol that allows -credential delegation. This is achieved by encrypting the username and password -after authentication has succeeded and sending that to the server using the -CredSSP protocol. - -Because the username and password are sent to the server to be used for double -hop authentication, ensure that the hosts that the Windows host communicates with are -not compromised and are trusted. - -CredSSP can be used for both local and domain accounts and also supports -message encryption over HTTP. - -To use CredSSP authentication, the host vars are configured like so: - -.. code-block:: yaml+jinja - - ansible_user: Username - ansible_password: Password - ansible_connection: winrm - ansible_winrm_transport: credssp - -There are some extra host variables that can be set as shown below: - -.. code-block:: yaml - - ansible_winrm_credssp_disable_tlsv1_2: when true, will not use TLS 1.2 in the CredSSP auth process - -CredSSP authentication is not enabled by default on a Windows host, but can -be enabled by running the following in PowerShell: - -.. code-block:: powershell - - Enable-WSManCredSSP -Role Server -Force - -.. _winrm_credssp_install: - -Installing CredSSP Library -++++++++++++++++++++++++++ - -The ``requests-credssp`` wrapper can be installed using ``pip``: - -.. code-block:: bash - - pip install pywinrm[credssp] - -.. _winrm_credssp_tls: - -CredSSP and TLS 1.2 -+++++++++++++++++++ - -By default the ``requests-credssp`` library is configured to authenticate over -the TLS 1.2 protocol. TLS 1.2 is installed and enabled by default for Windows Server 2012 -and Windows 8 and more recent releases. - -There are two ways that older hosts can be used with CredSSP: - -* Install and enable a hotfix to enable TLS 1.2 support (recommended - for Server 2008 R2 and Windows 7). - -* Set ``ansible_winrm_credssp_disable_tlsv1_2=True`` in the inventory to run - over TLS 1.0. This is the only option when connecting to Windows Server 2008, which - has no way of supporting TLS 1.2 - -See :ref:`winrm_tls12` for more information on how to enable TLS 1.2 on the -Windows host. - -.. _winrm _credssp_cert: - -Set CredSSP Certificate -+++++++++++++++++++++++ - -CredSSP works by encrypting the credentials through the TLS protocol and uses a self-signed certificate by default. The ``CertificateThumbprint`` option under the WinRM service configuration can be used to specify the thumbprint of -another certificate. - -.. Note:: This certificate configuration is independent of the WinRM listener - certificate. With CredSSP, message transport still occurs over the WinRM listener, - but the TLS-encrypted messages inside the channel use the service-level certificate. - -To explicitly set the certificate to use for CredSSP: - -.. code-block:: powershell - - # Note the value $certificate_thumbprint will be different in each - # situation, this needs to be set based on the cert that is used. - $certificate_thumbprint = "7C8DCBD5427AFEE6560F4AF524E325915F51172C" - - # Set the thumbprint value - Set-Item -Path WSMan:\localhost\Service\CertificateThumbprint -Value $certificate_thumbprint - -.. _winrm_nonadmin: - -Non-Administrator Accounts ---------------------------- - -WinRM is configured by default to only allow connections from accounts in the local -``Administrators`` group. This can be changed by running: - -.. code-block:: powershell - - winrm configSDDL default - -This will display an ACL editor, where new users or groups may be added. To run commands -over WinRM, users and groups must have at least the ``Read`` and ``Execute`` permissions -enabled. - -While non-administrative accounts can be used with WinRM, most typical server administration -tasks require some level of administrative access, so the utility is usually limited. - -.. _winrm_encrypt: - -WinRM Encryption ------------------ - -By default WinRM will fail to work when running over an unencrypted channel. -The WinRM protocol considers the channel to be encrypted if using TLS over HTTP -(HTTPS) or using message level encryption. Using WinRM with TLS is the -recommended option as it works with all authentication options, but requires -a certificate to be created and used on the WinRM listener. - -If in a domain environment, ADCS can create a certificate for the host that -is issued by the domain itself. - -If using HTTPS is not an option, then HTTP can be used when the authentication -option is ``NTLM``, ``Kerberos`` or ``CredSSP``. These protocols will encrypt -the WinRM payload with their own encryption method before sending it to the -server. The message-level encryption is not used when running over HTTPS because the -encryption uses the more secure TLS protocol instead. If both transport and -message encryption is required, set ``ansible_winrm_message_encryption=always`` -in the host vars. - -.. Note:: Message encryption over HTTP requires pywinrm>=0.3.0. - -A last resort is to disable the encryption requirement on the Windows host. This -should only be used for development and debugging purposes, as anything sent -from Ansible can be viewed, manipulated and also the remote session can completely -be taken over by anyone on the same network. To disable the encryption -requirement: - -.. code-block:: powershell - - Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $true - -.. Note:: Do not disable the encryption check unless it is - absolutely required. Doing so could allow sensitive information like - credentials and files to be intercepted by others on the network. - -.. _winrm_inventory: - -Inventory Options ------------------- - -Ansible's Windows support relies on a few standard variables to indicate the -username, password, and connection type of the remote hosts. These variables -are most easily set up in the inventory, but can be set on the ``host_vars``/ -``group_vars`` level. - -When setting up the inventory, the following variables are required: - -.. code-block:: yaml+jinja - - # It is suggested that these be encrypted with ansible-vault: - # ansible-vault edit group_vars/windows.yml - ansible_connection: winrm - - # May also be passed on the command-line through --user - ansible_user: Administrator - - # May also be supplied at runtime with --ask-pass - ansible_password: SecretPasswordGoesHere - - -Using the variables above, Ansible will connect to the Windows host with Basic -authentication through HTTPS. If ``ansible_user`` has a UPN value like -``username@MY.DOMAIN.COM`` then the authentication option will automatically attempt -to use Kerberos unless ``ansible_winrm_transport`` has been set to something other than -``kerberos``. - -The following custom inventory variables are also supported -for additional configuration of WinRM connections: - -* ``ansible_port``: The port WinRM will run over, HTTPS is ``5986`` which is - the default while HTTP is ``5985`` - -* ``ansible_winrm_scheme``: Specify the connection scheme (``http`` or - ``https``) to use for the WinRM connection. Ansible uses ``https`` by default - unless ``ansible_port`` is ``5985`` - -* ``ansible_winrm_path``: Specify an alternate path to the WinRM endpoint, - Ansible uses ``/wsman`` by default - -* ``ansible_winrm_realm``: Specify the realm to use for Kerberos - authentication. If ``ansible_user`` contains ``@``, Ansible will use the part - of the username after ``@`` by default - -* ``ansible_winrm_transport``: Specify one or more authentication transport - options as a comma-separated list. By default, Ansible will use ``kerberos, - basic`` if the ``kerberos`` module is installed and a realm is defined, - otherwise it will be ``plaintext`` - -* ``ansible_winrm_server_cert_validation``: Specify the server certificate - validation mode (``ignore`` or ``validate``). Ansible defaults to - ``validate`` on Python 2.7.9 and higher, which will result in certificate - validation errors against the Windows self-signed certificates. Unless - verifiable certificates have been configured on the WinRM listeners, this - should be set to ``ignore`` - -* ``ansible_winrm_operation_timeout_sec``: Increase the default timeout for - WinRM operations, Ansible uses ``20`` by default - -* ``ansible_winrm_read_timeout_sec``: Increase the WinRM read timeout, Ansible - uses ``30`` by default. Useful if there are intermittent network issues and - read timeout errors keep occurring - -* ``ansible_winrm_message_encryption``: Specify the message encryption - operation (``auto``, ``always``, ``never``) to use, Ansible uses ``auto`` by - default. ``auto`` means message encryption is only used when - ``ansible_winrm_scheme`` is ``http`` and ``ansible_winrm_transport`` supports - message encryption. ``always`` means message encryption will always be used - and ``never`` means message encryption will never be used - -* ``ansible_winrm_ca_trust_path``: Used to specify a different cacert container - than the one used in the ``certifi`` module. See the HTTPS Certificate - Validation section for more details. - -* ``ansible_winrm_send_cbt``: When using ``ntlm`` or ``kerberos`` over HTTPS, - the authentication library will try to send channel binding tokens to - mitigate against man in the middle attacks. This flag controls whether these - bindings will be sent or not (default: ``yes``). - -* ``ansible_winrm_*``: Any additional keyword arguments supported by - ``winrm.Protocol`` may be provided in place of ``*`` - -In addition, there are also specific variables that need to be set -for each authentication option. See the section on authentication above for more information. - -.. Note:: Ansible 2.0 has deprecated the "ssh" from ``ansible_ssh_user``, - ``ansible_ssh_pass``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to - become ``ansible_user``, ``ansible_password``, ``ansible_host``, and - ``ansible_port``. If using a version of Ansible prior to 2.0, the older - style (``ansible_ssh_*``) should be used instead. The shorter variables - are ignored, without warning, in older versions of Ansible. - -.. Note:: ``ansible_winrm_message_encryption`` is different from transport - encryption done over TLS. The WinRM payload is still encrypted with TLS - when run over HTTPS, even if ``ansible_winrm_message_encryption=never``. - -.. _winrm_ipv6: - -IPv6 Addresses ---------------- - -IPv6 addresses can be used instead of IPv4 addresses or hostnames. This option -is normally set in an inventory. Ansible will attempt to parse the address -using the `ipaddress `_ -package and pass to pywinrm correctly. - -When defining a host using an IPv6 address, just add the IPv6 address as you -would an IPv4 address or hostname: - -.. code-block:: ini - - [windows-server] - 2001:db8::1 - - [windows-server:vars] - ansible_user=username - ansible_password=password - ansible_connection=winrm - - -.. Note:: The ipaddress library is only included by default in Python 3.x. To - use IPv6 addresses in Python 2.7, make sure to run ``pip install ipaddress`` which installs - a backported package. - -.. _winrm_https: - -HTTPS Certificate Validation ------------------------------ - -As part of the TLS protocol, the certificate is validated to ensure the host -matches the subject and the client trusts the issuer of the server certificate. -When using a self-signed certificate or setting -``ansible_winrm_server_cert_validation: ignore`` these security mechanisms are -bypassed. While self signed certificates will always need the ``ignore`` flag, -certificates that have been issued from a certificate authority can still be -validated. - -One of the more common ways of setting up a HTTPS listener in a domain -environment is to use Active Directory Certificate Service (AD CS). AD CS is -used to generate signed certificates from a Certificate Signing Request (CSR). -If the WinRM HTTPS listener is using a certificate that has been signed by -another authority, like AD CS, then Ansible can be set up to trust that -issuer as part of the TLS handshake. - -To get Ansible to trust a Certificate Authority (CA) like AD CS, the issuer -certificate of the CA can be exported as a PEM encoded certificate. This -certificate can then be copied locally to the Ansible controller and used as a -source of certificate validation, otherwise known as a CA chain. - -The CA chain can contain a single or multiple issuer certificates and each -entry is contained on a new line. To then use the custom CA chain as part of -the validation process, set ``ansible_winrm_ca_trust_path`` to the path of the -file. If this variable is not set, the default CA chain is used instead which -is located in the install path of the Python package -`certifi `_. - -.. Note:: Each HTTP call is done by the Python requests library which does not - use the systems built-in certificate store as a trust authority. - Certificate validation will fail if the server's certificate issuer is - only added to the system's truststore. - -.. _winrm_tls12: - -TLS 1.2 Support ----------------- - -As WinRM runs over the HTTP protocol, using HTTPS means that the TLS protocol -is used to encrypt the WinRM messages. TLS will automatically attempt to -negotiate the best protocol and cipher suite that is available to both the -client and the server. If a match cannot be found then Ansible will error out -with a message similar to: - -.. code-block:: ansible-output - - HTTPSConnectionPool(host='server', port=5986): Max retries exceeded with url: /wsman (Caused by SSLError(SSLError(1, '[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1056)'))) - -Commonly this is when the Windows host has not been configured to support -TLS v1.2 but it could also mean the Ansible controller has an older OpenSSL -version installed. - -Windows 8 and Windows Server 2012 come with TLS v1.2 installed and enabled by -default but older hosts, like Server 2008 R2 and Windows 7, have to be enabled -manually. - -.. Note:: There is a bug with the TLS 1.2 patch for Server 2008 which will stop - Ansible from connecting to the Windows host. This means that Server 2008 - cannot be configured to use TLS 1.2. Server 2008 R2 and Windows 7 are not - affected by this issue and can use TLS 1.2. - -To verify what protocol the Windows host supports, you can run the following -command on the Ansible controller: - -.. code-block:: shell - - openssl s_client -connect :5986 - -The output will contain information about the TLS session and the ``Protocol`` -line will display the version that was negotiated: - -.. code-block:: console - - New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA - Server public key is 2048 bit - Secure Renegotiation IS supported - Compression: NONE - Expansion: NONE - No ALPN negotiated - SSL-Session: - Protocol : TLSv1 - Cipher : ECDHE-RSA-AES256-SHA - Session-ID: 962A00001C95D2A601BE1CCFA7831B85A7EEE897AECDBF3D9ECD4A3BE4F6AC9B - Session-ID-ctx: - Master-Key: .... - Start Time: 1552976474 - Timeout : 7200 (sec) - Verify return code: 21 (unable to verify the first certificate) - --- - - New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 - Server public key is 2048 bit - Secure Renegotiation IS supported - Compression: NONE - Expansion: NONE - No ALPN negotiated - SSL-Session: - Protocol : TLSv1.2 - Cipher : ECDHE-RSA-AES256-GCM-SHA384 - Session-ID: AE16000050DA9FD44D03BB8839B64449805D9E43DBD670346D3D9E05D1AEEA84 - Session-ID-ctx: - Master-Key: .... - Start Time: 1552976538 - Timeout : 7200 (sec) - Verify return code: 21 (unable to verify the first certificate) - -If the host is returning ``TLSv1`` then it should be configured so that -TLS v1.2 is enable. You can do this by running the following PowerShell -script: - -.. code-block:: powershell - - Function Enable-TLS12 { - param( - [ValidateSet("Server", "Client")] - [String]$Component = "Server" - ) - - $protocols_path = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' - New-Item -Path "$protocols_path\TLS 1.2\$Component" -Force - New-ItemProperty -Path "$protocols_path\TLS 1.2\$Component" -Name Enabled -Value 1 -Type DWORD -Force - New-ItemProperty -Path "$protocols_path\TLS 1.2\$Component" -Name DisabledByDefault -Value 0 -Type DWORD -Force - } - - Enable-TLS12 -Component Server - - # Not required but highly recommended to enable the Client side TLS 1.2 components - Enable-TLS12 -Component Client - - Restart-Computer - -The below Ansible tasks can also be used to enable TLS v1.2: - -.. code-block:: yaml+jinja - - - name: enable TLSv1.2 support - win_regedit: - path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\{{ item.type }} - name: '{{ item.property }}' - data: '{{ item.value }}' - type: dword - state: present - register: enable_tls12 - loop: - - type: Server - property: Enabled - value: 1 - - type: Server - property: DisabledByDefault - value: 0 - - type: Client - property: Enabled - value: 1 - - type: Client - property: DisabledByDefault - value: 0 - - - name: reboot if TLS config was applied - win_reboot: - when: enable_tls12 is changed - -There are other ways to configure the TLS protocols as well as the cipher -suites that are offered by the Windows host. One tool that can give you a GUI -to manage these settings is `IIS Crypto `_ -from Nartac Software. - -.. _winrm_limitations: - -WinRM limitations ------------------- -Due to the design of the WinRM protocol , there are a few limitations -when using WinRM that can cause issues when creating playbooks for Ansible. -These include: - -* Credentials are not delegated for most authentication types, which causes - authentication errors when accessing network resources or installing certain - programs. - -* Many calls to the Windows Update API are blocked when running over WinRM. - -* Some programs fail to install with WinRM due to no credential delegation or - because they access forbidden Windows API like WUA over WinRM. - -* Commands under WinRM are done under a non-interactive session, which can prevent - certain commands or executables from running. - -* You cannot run a process that interacts with ``DPAPI``, which is used by some - installers (like Microsoft SQL Server). - -Some of these limitations can be mitigated by doing one of the following: - -* Set ``ansible_winrm_transport`` to ``credssp`` or ``kerberos`` (with - ``ansible_winrm_kerberos_delegation=true``) to bypass the double hop issue - and access network resources - -* Use ``become`` to bypass all WinRM restrictions and run a command as it would - locally. Unlike using an authentication transport like ``credssp``, this will - also remove the non-interactive restriction and API restrictions like WUA and - DPAPI - -* Use a scheduled task to run a command which can be created with the - ``win_scheduled_task`` module. Like ``become``, this bypasses all WinRM - restrictions but can only run a command and not modules. - - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - :ref:`List of Windows Modules ` - Windows specific module list, all implemented in PowerShell - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst b/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst deleted file mode 100644 index e7d23b336fc..00000000000 --- a/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst +++ /dev/null @@ -1,314 +0,0 @@ -.. _complex_data_manipulation: - -Manipulating data -################# - -In many cases, you need to do some complex operation with your variables, while Ansible is not recommended as a data processing/manipulation tool, you can use the existing Jinja2 templating in conjunction with the many added Ansible filters, lookups and tests to do some very complex transformations. - -Let's start with a quick definition of each type of plugin: - - lookups: Mainly used to query 'external data', in Ansible these were the primary part of loops using the ``with_`` construct, but they can be used independently to return data for processing. They normally return a list due to their primary function in loops as mentioned previously. Used with the ``lookup`` or ``query`` Jinja2 operators. - - filters: used to change/transform data, used with the ``|`` Jinja2 operator. - - tests: used to validate data, used with the ``is`` Jinja2 operator. - -.. _note: - * Some tests and filters are provided directly by Jinja2, so their availability depends on the Jinja2 version, not Ansible. - -.. _for_loops_or_list_comprehensions: - -Loops and list comprehensions -============================= - -Most programming languages have loops (``for``, ``while``, and so on) and list comprehensions to do transformations on lists including lists of objects. Jinja2 has a few filters that provide this functionality: ``map``, ``select``, ``reject``, ``selectattr``, ``rejectattr``. - -- map: this is a basic for loop that just allows you to change every item in a list, using the 'attribute' keyword you can do the transformation based on attributes of the list elements. -- select/reject: this is a for loop with a condition, that allows you to create a subset of a list that matches (or not) based on the result of the condition. -- selectattr/rejectattr: very similar to the above but it uses a specific attribute of the list elements for the conditional statement. - - -.. _exponential_backoff: - -Use a loop to create exponential backoff for retries/until. - -.. code-block:: yaml - - - name: retry ping 10 times with exponential backoff delay - ping: - retries: 10 - delay: '{{item|int}}' - loop: '{{ range(1, 10)|map("pow", 2) }}' - - -.. _keys_from_dict_matching_list: - -Extract keys from a dictionary matching elements from a list ------------------------------------------------------------- - -The Python equivalent code would be: - -.. code-block:: python - - chains = [1, 2] - for chain in chains: - for config in chains_config[chain]['configs']: - print(config['type']) - -There are several ways to do it in Ansible, this is just one example: - -.. code-block:: YAML+Jinja - :emphasize-lines: 4 - :caption: Way to extract matching keys from a list of dictionaries - - tasks: - - name: Show extracted list of keys from a list of dictionaries - ansible.builtin.debug: - msg: "{{ chains | map('extract', chains_config) | map(attribute='configs') | flatten | map(attribute='type') | flatten }}" - vars: - chains: [1, 2] - chains_config: - 1: - foo: bar - configs: - - type: routed - version: 0.1 - - type: bridged - version: 0.2 - 2: - foo: baz - configs: - - type: routed - version: 1.0 - - type: bridged - version: 1.1 - - -.. code-block:: ansible-output - :caption: Results of debug task, a list with the extracted keys - - ok: [localhost] => { - "msg": [ - "routed", - "bridged", - "routed", - "bridged" - ] - } - - -.. code-block:: YAML+Jinja - :caption: Get the unique list of values of a variable that vary per host - - vars: - unique_value_list: "{{ groups['all'] | map ('extract', hostvars, 'varname') | list | unique}}" - - -.. _find_mount_point: - -Find mount point ----------------- - -In this case, we want to find the mount point for a given path across our machines, since we already collect mount facts, we can use the following: - -.. code-block:: YAML+Jinja - :caption: Use selectattr to filter mounts into list I can then sort and select the last from - :emphasize-lines: 8 - - - hosts: all - gather_facts: True - vars: - path: /var/lib/cache - tasks: - - name: The mount point for {{path}}, found using the Ansible mount facts, [-1] is the same as the 'last' filter - ansible.builtin.debug: - msg: "{{(ansible_facts.mounts | selectattr('mount', 'in', path) | list | sort(attribute='mount'))[-1]['mount']}}" - - -.. _omit_elements_from_list: - -Omit elements from a list -------------------------- - -The special ``omit`` variable ONLY works with module options, but we can still use it in other ways as an identifier to tailor a list of elements: - -.. code-block:: YAML+Jinja - :caption: Inline list filtering when feeding a module option - :emphasize-lines: 3, 6 - - - name: Enable a list of Windows features, by name - ansible.builtin.set_fact: - win_feature_list: "{{ namestuff | reject('equalto', omit) | list }}" - vars: - namestuff: - - "{{ (fs_installed_smb_v1 | default(False)) | ternary(omit, 'FS-SMB1') }}" - - "foo" - - "bar" - - -Another way is to avoid adding elements to the list in the first place, so you can just use it directly: - -.. code-block:: YAML+Jinja - :caption: Using set_fact in a loop to increment a list conditionally - :emphasize-lines: 3, 4, 6 - - - name: Build unique list with some items conditionally omitted - ansible.builtin.set_fact: - namestuff: ' {{ (namestuff | default([])) | union([item]) }}' - when: item != omit - loop: - - "{{ (fs_installed_smb_v1 | default(False)) | ternary(omit, 'FS-SMB1') }}" - - "foo" - - "bar" - - - -.. _combine_optional_values: - -Combine values from same list of dicts ---------------------------------------- -Combining positive and negative filters from examples above, you can get a 'value when it exists' and a 'fallback' when it doesn't. - -.. code-block:: YAML+Jinja - :caption: Use selectattr and rejectattr to get the ansible_host or inventory_hostname as needed - - - hosts: localhost - tasks: - - name: Check hosts in inventory that respond to ssh port - wait_for: - host: "{{ item }}" - port: 22 - loop: '{{ has_ah + no_ah }}' - vars: - has_ah: '{{ hostvars|dictsort|selectattr("1.ansible_host", "defined")|map(attribute="1.ansible_host")|list }}' - no_ah: '{{ hostvars|dictsort|rejectattr("1.ansible_host", "defined")|map(attribute="0")|list }}' - - -.. _custom_fileglob_variable: - -Custom Fileglob Based on a Variable ------------------------------------ - -This example uses `Python argument list unpacking `_ to create a custom list of fileglobs based on a variable. - -.. code-block:: YAML+Jinja - :caption: Using fileglob with a list based on a variable. - - - hosts: all - vars: - mygroups: - - prod - - web - tasks: - - name: Copy a glob of files based on a list of groups - copy: - src: "{{ item }}" - dest: "/tmp/{{ item }}" - loop: '{{ q("fileglob", *globlist) }}' - vars: - globlist: '{{ mygroups | map("regex_replace", "^(.*)$", "files/\1/*.conf") | list }}' - - -.. _complex_type_transformations: - -Complex Type transformations -============================= - -Jinja provides filters for simple data type transformations (``int``, ``bool``, and so on), but when you want to transform data structures things are not as easy. -You can use loops and list comprehensions as shown above to help, also other filters and lookups can be chained and used to achieve more complex transformations. - - -.. _create_dictionary_from_list: - -Create dictionary from list ---------------------------- - -In most languages it is easy to create a dictionary (a.k.a. map/associative array/hash and so on) from a list of pairs, in Ansible there are a couple of ways to do it and the best one for you might depend on the source of your data. - - -These example produces ``{"a": "b", "c": "d"}`` - -.. code-block:: YAML+Jinja - :caption: Simple list to dict by assuming the list is [key, value , key, value, ...] - - vars: - single_list: [ 'a', 'b', 'c', 'd' ] - mydict: "{{ dict(single_list[::2] | zip_longest(single_list[1::2])) }}" - - -.. code-block:: YAML+Jinja - :caption: It is simpler when we have a list of pairs: - - vars: - list_of_pairs: [ ['a', 'b'], ['c', 'd'] ] - mydict: "{{ dict(list_of_pairs) }}" - -Both end up being the same thing, with ``zip_longest`` transforming ``single_list`` to a ``list_of_pairs`` generator. - - - -A bit more complex, using ``set_fact`` and a ``loop`` to create/update a dictionary with key value pairs from 2 lists: - -.. code-block:: YAML+Jinja - :caption: Using set_fact to create a dictionary from a set of lists - :emphasize-lines: 3, 4 - - - name: Uses 'combine' to update the dictionary and 'zip' to make pairs of both lists - ansible.builtin.set_fact: - mydict: "{{ mydict | default({}) | combine({item[0]: item[1]}) }}" - loop: "{{ (keys | zip(values)) | list }}" - vars: - keys: - - foo - - var - - bar - values: - - a - - b - - c - -This results in ``{"foo": "a", "var": "b", "bar": "c"}``. - - -You can even combine these simple examples with other filters and lookups to create a dictionary dynamically by matching patterns to variable names: - -.. code-block:: YAML+Jinja - :caption: Using 'vars' to define dictionary from a set of lists without needing a task - - vars: - xyz_stuff: 1234 - xyz_morestuff: 567 - myvarnames: "{{ q('varnames', '^xyz_') }}" - mydict: "{{ dict(myvarnames|map('regex_replace', '^xyz_', '')|list | zip(q('vars', *myvarnames))) }}" - -A quick explanation, since there is a lot to unpack from these two lines: - - - The ``varnames`` lookup returns a list of variables that match "begin with ``xyz_``". - - Then feeding the list from the previous step into the ``vars`` lookup to get the list of values. - The ``*`` is used to 'dereference the list' (a pythonism that works in Jinja), otherwise it would take the list as a single argument. - - Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...). - - The dict function then takes this 'list of pairs' to create the dictionary. - - -An example on how to use facts to find a host's data that meets condition X: - - -.. code-block:: YAML+Jinja - - vars: - uptime_of_host_most_recently_rebooted: "{{ansible_play_hosts_all | map('extract', hostvars, 'ansible_uptime_seconds') | sort | first}}" - -An example to show a host uptime in days/hours/minutes/seconds (assumes facts were gathered). - -.. code-block:: YAML+Jinja - - - name: Show the uptime in days/hours/minutes/seconds - ansible.builtin.debug: - msg: Uptime {{ now().replace(microsecond=0) - now().fromtimestamp(now(fmt='%s') | int - ansible_uptime_seconds) }} - - -.. seealso:: - - :ref:`playbooks_filters` - Jinja2 filters included with Ansible - :ref:`playbooks_tests` - Jinja2 tests included with Ansible - `Jinja2 Docs `_ - Jinja2 documentation, includes lists for core filters and tests diff --git a/docs/docsite/rst/playbook_guide/guide_rolling_upgrade.rst b/docs/docsite/rst/playbook_guide/guide_rolling_upgrade.rst deleted file mode 100644 index 3031bf7b937..00000000000 --- a/docs/docsite/rst/playbook_guide/guide_rolling_upgrade.rst +++ /dev/null @@ -1,324 +0,0 @@ -********************************************************** -Playbook Example: Continuous Delivery and Rolling Upgrades -********************************************************** - -.. contents:: - :local: - -.. _lamp_introduction: - -What is continuous delivery? -============================ - -Continuous delivery (CD) means frequently delivering updates to your software application. - -The idea is that by updating more often, you do not have to wait for a specific timed period, and your organization -gets better at the process of responding to change. - -Some Ansible users are deploying updates to their end users on an hourly or even more frequent basis -- sometimes every time -there is an approved code change. To achieve this, you need tools to be able to quickly apply those updates in a zero-downtime way. - -This document describes in detail how to achieve this goal, using one of Ansible's most complete example -playbooks as a template: lamp_haproxy. This example uses a lot of Ansible features: roles, templates, -and group variables, and it also comes with an orchestration playbook that can do zero-downtime -rolling upgrades of the web application stack. - -.. note:: - - `Click here for the latest playbooks for this example - `_. - -The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers. - -We're not going to cover how to run these playbooks here. Read the included README in the github project along with the -example for that information. Instead, we're going to take a close look at every part of the playbook and describe what it does. - -.. _lamp_deployment: - -Site deployment -=============== - -Let's start with ``site.yml``. This is our site-wide deployment playbook. It can be used to initially deploy the site, as well -as push updates to all of the servers: - -.. code-block:: yaml - - --- - # This playbook deploys the whole application stack in this site. - - # Apply common configuration to all hosts - - hosts: all - - roles: - - common - - # Configure and deploy database servers. - - hosts: dbservers - - roles: - - db - - # Configure and deploy the web servers. Note that we include two roles - # here, the 'base-apache' role which simply sets up Apache, and 'web' - # which includes our example web application. - - - hosts: webservers - - roles: - - base-apache - - web - - # Configure and deploy the load balancer(s). - - hosts: lbservers - - roles: - - haproxy - - # Configure and deploy the Nagios monitoring node(s). - - hosts: monitoring - - roles: - - base-apache - - nagios - -.. note:: - - If you're not familiar with terms like playbooks and plays, you should review :ref:`working_with_playbooks`. - -In this playbook we have 5 plays. The first one targets ``all`` hosts and applies the ``common`` role to all of the hosts. -This is for site-wide things like yum repository configuration, firewall configuration, and anything else that needs to apply to all of the servers. - -The next four plays run against specific host groups and apply specific roles to those servers. -Along with the roles for Nagios monitoring, the database, and the web application, we've implemented a -``base-apache`` role that installs and configures a basic Apache setup. This is used by both the -sample web application and the Nagios hosts. - -.. _lamp_roles: - -Reusable content: roles -======================= - -By now you should have a bit of understanding about roles and how they work in Ansible. Roles are a way to organize -content: tasks, handlers, templates, and files, into reusable components. - -This example has six roles: ``common``, ``base-apache``, ``db``, ``haproxy``, ``nagios``, and ``web``. How you organize -your roles is up to you and your application, but most sites will have one or more common roles that are applied to -all systems, and then a series of application-specific roles that install and configure particular parts of the site. - -Roles can have variables and dependencies, and you can pass in parameters to roles to modify their behavior. -You can read more about roles in the :ref:`playbooks_reuse_roles` section. - -.. _lamp_group_variables: - -Configuration: group variables -============================== - -Group variables are variables that are applied to groups of servers. They can be used in templates and in -playbooks to customize behavior and to provide easily-changed settings and parameters. They are stored in -a directory called ``group_vars`` in the same location as your inventory. -Here is lamp_haproxy's ``group_vars/all`` file. As you might expect, these variables are applied to all of the machines in your inventory: - -.. code-block:: yaml - - --- - httpd_port: 80 - ntpserver: 192.0.2.23 - -This is a YAML file, and you can create lists and dictionaries for more complex variable structures. -In this case, we are just setting two variables, one for the port for the web server, and one for the -NTP server that our machines should use for time synchronization. - -Here's another group variables file. This is ``group_vars/dbservers`` which applies to the hosts in the ``dbservers`` group: - -.. code-block:: yaml - - --- - mysqlservice: mysqld - mysql_port: 3306 - dbuser: root - dbname: foodb - upassword: usersecret - -If you look in the example, there are group variables for the ``webservers`` group and the ``lbservers`` group, similarly. - -These variables are used in a variety of places. You can use them in playbooks, like this, in ``roles/db/tasks/main.yml``: - -.. code-block:: yaml - - - name: Create Application Database - mysql_db: - name: "{{ dbname }}" - state: present - - - name: Create Application DB User - mysql_user: - name: "{{ dbuser }}" - password: "{{ upassword }}" - priv: "*.*:ALL" - host: '%' - state: present - -You can also use these variables in templates, like this, in ``roles/common/templates/ntp.conf.j2``: - -.. code-block:: text - - driftfile /var/lib/ntp/drift - - restrict 127.0.0.1 - restrict -6 ::1 - - server {{ ntpserver }} - - includefile /etc/ntp/crypto/pw - - keys /etc/ntp/keys - -You can see that the variable substitution syntax of {{ and }} is the same for both templates and variables. The syntax -inside the curly braces is Jinja2, and you can do all sorts of operations and apply different filters to the -data inside. In templates, you can also use for loops and if statements to handle more complex situations, -like this, in ``roles/common/templates/iptables.j2``: - -.. code-block:: jinja - - {% if inventory_hostname in groups['dbservers'] %} - -A INPUT -p tcp --dport 3306 -j ACCEPT - {% endif %} - -This is testing to see if the inventory name of the machine we're currently operating on (``inventory_hostname``) -exists in the inventory group ``dbservers``. If so, that machine will get an iptables ACCEPT line for port 3306. - -Here's another example, from the same template: - -.. code-block:: jinja - - {% for host in groups['monitoring'] %} - -A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT - {% endfor %} - -This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for -each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts. - -You can learn a lot more about Jinja2 and its capabilities `here `_, and you -can read more about Ansible variables in general in the :ref:`playbooks_variables` section. - -.. _lamp_rolling_upgrade: - -The rolling upgrade -=================== - -Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible's -orchestration features come into play. While some applications use the term 'orchestration' to mean basic ordering or command-blasting, Ansible -refers to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it. - -Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, called ``rolling_update.yml``. - -Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this: - -.. code-block:: yaml - - - hosts: monitoring - tasks: [] - -What's going on here, and why are there no tasks? You might know that Ansible gathers "facts" from the servers before operating upon them. These facts are useful for all sorts of things: networking information, OS/distribution versions, and so on. In our case, we need to know something about all of the monitoring servers in our environment before we perform the update, so this simple play forces a fact-gathering step on our monitoring servers. You will see this pattern sometimes, and it's a useful trick to know. - -The next part is the update play. The first part looks like this: - -.. code-block:: yaml - - - hosts: webservers - user: root - serial: 1 - -This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will parallelize these operations up to the default "forks" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time. - -Here is the next part of the update play: - -.. code-block:: yaml - - pre_tasks: - - name: disable nagios alerts for this host webserver service - nagios: - action: disable_alerts - host: "{{ inventory_hostname }}" - services: webserver - delegate_to: "{{ item }}" - loop: "{{ groups.monitoring }}" - - - name: disable the server in haproxy - shell: echo "disable server myapplb/{{ inventory_hostname }}" | socat stdio /var/lib/haproxy/stats - delegate_to: "{{ item }}" - loop: "{{ groups.lbservers }}" - -.. note:: - - The ``serial`` keyword forces the play to be executed in 'batches'. Each batch counts as a full play with a subselection of hosts. - This has some consequences on play behavior. For example, if all hosts in a batch fails, the play fails, which in turn fails the entire run. You should consider this when combining with ``max_fail_percentage``. - -The ``pre_tasks`` keyword just lets you list tasks to run before the roles are called. This will make more sense in a minute. If you look at the names of these tasks, you can see that we are disabling Nagios alerts and then removing the webserver that we are currently updating from the HAProxy load balancing pool. - -The ``delegate_to`` and ``loop`` arguments, used together, cause Ansible to loop over each monitoring server and load balancer, and perform that operation (delegate that operation) on the monitoring or load balancing server, "on behalf" of the webserver. In programming terms, the outer loop is the list of web servers, and the inner loop is the list of monitoring servers. - -Note that the HAProxy step looks a little complicated. We're using HAProxy in this example because it's freely available, though if you have (for instance) an F5 or Netscaler in your infrastructure (or maybe you have an AWS Elastic IP setup?), you can use Ansible modules to communicate with them instead. You might also wish to use other monitoring modules instead of nagios, but this just shows the main goal of the 'pre tasks' section -- take the server out of monitoring, and take it out of rotation. - -The next step simply re-applies the proper roles to the web servers. This will cause any configuration management declarations in ``web`` and ``base-apache`` roles to be applied to the web servers, including an update of the web application code itself. We don't have to do it this way--we could instead just purely update the web application, but this is a good example of how roles can be used to reuse tasks: - -.. code-block:: yaml - - roles: - - common - - base-apache - - web - -Finally, in the ``post_tasks`` section, we reverse the changes to the Nagios configuration and put the web server back in the load balancing pool: - -.. code-block:: yaml - - post_tasks: - - name: Enable the server in haproxy - shell: echo "enable server myapplb/{{ inventory_hostname }}" | socat stdio /var/lib/haproxy/stats - delegate_to: "{{ item }}" - loop: "{{ groups.lbservers }}" - - - name: re-enable nagios alerts - nagios: - action: enable_alerts - host: "{{ inventory_hostname }}" - services: webserver - delegate_to: "{{ item }}" - loop: "{{ groups.monitoring }}" - -Again, if you were using a Netscaler or F5 or Elastic Load Balancer, you would just substitute in the appropriate modules instead. - -.. _lamp_end_notes: - -Managing other load balancers -============================= - -In this example, we use the simple HAProxy load balancer to front-end the web servers. It's easy to configure and easy to manage. As we have mentioned, Ansible has support for a variety of other load balancers like Citrix NetScaler, F5 BigIP, Amazon Elastic Load Balancers, and more. See the :ref:`working_with_modules` documentation for more information. - -For other load balancers, you may need to send shell commands to them (like we do for HAProxy above), or call an API, if your load balancer exposes one. For the load balancers for which Ansible has modules, you may want to run them as a ``local_action`` if they contact an API. You can read more about local actions in the :ref:`playbooks_delegation` section. Should you develop anything interesting for some hardware where there is not a module, it might make for a good contribution! - -.. _lamp_end_to_end: - -Continuous delivery end-to-end -============================== - -Now that you have an automated way to deploy updates to your application, how do you tie it all together? A lot of organizations use a continuous integration tool like `Jenkins `_ or `Atlassian Bamboo `_ to tie the development, test, release, and deploy steps together. You may also want to use a tool like `Gerrit `_ to add a code review step to commits to either the application code itself, or to your Ansible playbooks, or both. - -Depending on your environment, you might be deploying continuously to a test environment, running an integration test battery against that environment, and then deploying automatically into production. Or you could keep it simple and just use the rolling-update for on-demand deployment into test or production specifically. This is all up to you. - -For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using AWX, the ``tower-cli`` command or the built-in REST API. (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick). - -This should give you a good idea of how to structure a multi-tier application with Ansible, and orchestrate operations upon that app, with the eventual goal of continuous delivery to your customers. You could extend the idea of the rolling upgrade to lots of different parts of the app; maybe add front-end web servers along with application servers, for instance, or replace the SQL database with something like MongoDB or Riak. Ansible gives you the capability to easily manage complicated environments and automate common operations. - -.. seealso:: - - `lamp_haproxy example `_ - The lamp_haproxy example discussed here. - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - An introduction to playbook roles - :ref:`playbooks_variables` - An introduction to Ansible variables - `Ansible.com: Continuous Delivery `_ - An introduction to Continuous Delivery with Ansible diff --git a/docs/docsite/rst/playbook_guide/index.rst b/docs/docsite/rst/playbook_guide/index.rst deleted file mode 100644 index 56f4d2e9b44..00000000000 --- a/docs/docsite/rst/playbook_guide/index.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _playbook_guide_index: - -####################### -Using Ansible playbooks -####################### - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible playbooks guide. -Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure nodes in an inventory. -This guide introduces you to playbooks and then covers different use cases for tasks and plays, such as: - -* Executing tasks with elevated privileges or as a different user. -* Using loops to repeat tasks for items in a list. -* Delegating playbooks to execute tasks on different machines. -* Running conditional tasks and evaluating conditions with playbook tests. -* Using blocks to group sets of tasks. - -You can also learn how to use Ansible playbooks more effectively by creating re-usable files and roles, including and importing playbooks, and running selected parts of a playbook with tags. - -.. toctree:: - :maxdepth: 2 - - playbooks_intro - playbooks - playbooks_execution - playbooks_advanced_syntax - complex_data_manipulation \ No newline at end of file diff --git a/docs/docsite/rst/playbook_guide/playbook_pathing.rst b/docs/docsite/rst/playbook_guide/playbook_pathing.rst deleted file mode 100644 index a049ef0f1cf..00000000000 --- a/docs/docsite/rst/playbook_guide/playbook_pathing.rst +++ /dev/null @@ -1,45 +0,0 @@ -:orphan: - -*********************** -Search paths in Ansible -*********************** - -You can control the paths Ansible searches to find resources on your control node (including configuration, modules, roles, ssh keys, and more) as well as resources on the remote nodes you are managing. Use absolute paths to tell Ansible where to find resources whenever you can. However, absolute paths are not always practical. This page covers how Ansible interprets relative search paths, along with ways to troubleshoot when Ansible cannot find the resource you need. - -.. contents:: - :local: - -Config paths -============ - -By default these should be relative to the config file, some are specifically relative to the current working directory or the playbook and should have this noted in their description. Things like ssh keys are left to use the current working directory because it mirrors how the underlying tools would use it. - -.. _playbook_task_paths: - -Task paths -========== - -Relative paths used in a task typically refer to remote files and directories on the managed nodes. However, paths passed to lookup plugins and some paths used in action plugins such as the "src" path for the :ref:`template ` and :ref:`copy ` modules refer to local files and directories on the control node. - -Resolving local relative paths ------------------------------- - -When you specify a relative path for a local file, Ansible will try to find that file first in the current task's role, then in other roles that included or depend on the current role, then relative to the file in which the task is defined, and finally relative to the current play. It will take the first matching file that it finds. This way, if multiple files with the same filename exist, Ansible will find the file that is closest to the current task and that is most likely to be file you wanted. - -Specifically, Ansible tries to find the file - -1. In the current role. - - 1. In its appropriate subdirectory—"files", "vars", "templates" or "tasks", depending on the kind of file Ansible is searching for. - 2. Directly in its directory. - -2. Like 1, in the parent role that called into this current role with `include_role`, `import_role`, or with a role dependency. If the parent role has its own parent role, Ansible will repeat this step with that role. -3. Like 1, in the current task file's directory. -4. Like 1, in the current play file's directory. - -Ansible does not search the current working directory. (The directory you're in when you execute Ansible.) Also, Ansible will only search within a role if you actually included it with an `include_role` or `import_role` task or a dependency. If you instead use `include`, `include_task` or `import_task` to include just the tasks from a specific file but not the full role, Ansible will not search that role in steps 1 and 2. - -When you execute Ansible, the variable `ansible_search_path` will contain the paths searched, in the order they were searched in but without listing their subdirectories. If you run Ansible in verbosity level 5 by passing the `-vvvvv` argument, Ansible will report each directory as it searches, except when it searches for a tasks file. - - -.. note:: The current working directory might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory. diff --git a/docs/docsite/rst/playbook_guide/playbooks.rst b/docs/docsite/rst/playbook_guide/playbooks.rst deleted file mode 100644 index 48ea92fb57e..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks.rst +++ /dev/null @@ -1,42 +0,0 @@ -.. _working_with_playbooks: - -Working with playbooks -====================== - -Playbooks record and execute Ansible's configuration, deployment, and orchestration functions. -They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process. - -If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material. - -At a basic level, playbooks can be used to manage configurations of and deployments to remote machines. -At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way. - -Playbooks are designed to be human-readable and are developed in a basic text language. -There are multiple ways to organize playbooks and the files they include, and we'll offer up some suggestions on that and making the most out of Ansible. - -You should look at `Example Playbooks `_ while reading along with the playbook documentation. -These illustrate best practices as well as how to put many of the various concepts together. - -.. toctree:: - :maxdepth: 2 - - playbooks_templating - playbooks_filters - playbooks_tests - playbooks_lookups - playbooks_python_version - playbooks_templating_now - playbooks_loops - playbooks_delegation - playbooks_conditionals - playbooks_blocks - playbooks_handlers - playbooks_error_handling - playbooks_environment - playbooks_reuse - playbooks_reuse_roles - playbooks_module_defaults - playbooks_prompts - playbooks_variables - playbooks_vars_facts - guide_rolling_upgrade diff --git a/docs/docsite/rst/playbook_guide/playbooks_advanced_syntax.rst b/docs/docsite/rst/playbook_guide/playbooks_advanced_syntax.rst deleted file mode 100644 index ee6ff67fe98..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_advanced_syntax.rst +++ /dev/null @@ -1,122 +0,0 @@ -.. _playbooks_advanced_syntax: - -************************ -Advanced playbook syntax -************************ - -The advanced YAML syntax examples on this page give you more control over the data placed in YAML files used by Ansible. -You can find additional information about Python-specific YAML in the official `PyYAML Documentation `_. - -.. _unsafe_strings: - -Unsafe or raw strings -===================== - -When handling values returned by lookup plugins, Ansible uses a data type called ``unsafe`` to block templating. Marking data as unsafe prevents malicious users from abusing Jinja2 templates to execute arbitrary code on target machines. The Ansible implementation ensures that unsafe values are never templated. It is more comprehensive than escaping Jinja2 with ``{% raw %} ... {% endraw %}`` tags. - -You can use the same ``unsafe`` data type in variables you define, to prevent templating errors and information disclosure. You can mark values supplied by :ref:`vars_prompts` as unsafe. You can also use ``unsafe`` in playbooks. The most common use cases include passwords that allow special characters like ``{`` or ``%``, and JSON arguments that look like templates but should not be templated. For example: - -.. code-block:: yaml - - --- - mypassword: !unsafe 234%234{435lkj{{lkjsdf - -In a playbook: - -.. code-block:: yaml - - --- - hosts: all - vars: - my_unsafe_variable: !unsafe 'unsafe % value' - tasks: - ... - -For complex variables such as hashes or arrays, use ``!unsafe`` on the individual elements: - -.. code-block:: yaml - - --- - my_unsafe_array: - - !unsafe 'unsafe element' - - 'safe element' - - my_unsafe_hash: - unsafe_key: !unsafe 'unsafe value' - -.. _anchors_and_aliases: - -YAML anchors and aliases: sharing variable values -================================================= - -`YAML anchors and aliases `_ help you define, maintain, and use shared variable values in a flexible way. -You define an anchor with ``&``, then refer to it using an alias, denoted with ``*``. Here's an example that sets three values with an anchor, uses two of those values with an alias, and overrides the third value: - -.. code-block:: yaml - - --- - ... - vars: - app1: - jvm: &jvm_opts - opts: '-Xms1G -Xmx2G' - port: 1000 - path: /usr/lib/app1 - app2: - jvm: - <<: *jvm_opts - path: /usr/lib/app2 - ... - -Here, ``app1`` and ``app2`` share the values for ``opts`` and ``port`` using the anchor ``&jvm_opts`` and the alias ``*jvm_opts``. -The value for ``path`` is merged by ``<<`` or `merge operator `_. - -Anchors and aliases also let you share complex sets of variable values, including nested variables. If you have one variable value that includes another variable value, you can define them separately: - -.. code-block:: yaml - - vars: - webapp_version: 1.0 - webapp_custom_name: ToDo_App-1.0 - -This is inefficient and, at scale, means more maintenance. To incorporate the version value in the name, you can use an anchor in ``app_version`` and an alias in ``custom_name``: - -.. code-block:: yaml - - vars: - webapp: - version: &my_version 1.0 - custom_name: - - "ToDo_App" - - *my_version - -Now, you can re-use the value of ``app_version`` within the value of ``custom_name`` and use the output in a template: - -.. code-block:: yaml - - --- - - name: Using values nested inside dictionary - hosts: localhost - vars: - webapp: - version: &my_version 1.0 - custom_name: - - "ToDo_App" - - *my_version - tasks: - - name: Using Anchor value - ansible.builtin.debug: - msg: My app is called "{{ webapp.custom_name | join('-') }}". - -You've anchored the value of ``version`` with the ``&my_version`` anchor, and re-used it with the ``*my_version`` alias. Anchors and aliases let you access nested values inside dictionaries. - -.. seealso:: - - :ref:`playbooks_variables` - All about variables - :ref:`complex_data_manipulation` - Doing complex data manipulation in Ansible - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_async.rst b/docs/docsite/rst/playbook_guide/playbooks_async.rst deleted file mode 100644 index 2f56dbf78cb..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_async.rst +++ /dev/null @@ -1,189 +0,0 @@ -.. _playbooks_async: - -Asynchronous actions and polling -================================ - -By default Ansible runs tasks synchronously, holding the connection to the remote node open until the action is completed. This means within a playbook, each task blocks the next task by default, meaning subsequent tasks will not run until the current task completes. This behavior can create challenges. For example, a task may take longer to complete than the SSH session allows for, causing a timeout. Or you may want a long-running process to execute in the background while you perform other tasks concurrently. Asynchronous mode lets you control how long-running tasks execute. - -.. contents:: - :local: - -Asynchronous ad hoc tasks -------------------------- - -You can execute long-running operations in the background with :ref:`ad hoc tasks `. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``): - -.. code-block:: bash - - $ ansible all -B 3600 -P 0 -a "/usr/bin/long_running_operation --do-stuff" - -To check on the job status later, use the ``async_status`` module, passing it the job ID that was returned when you ran the original job in the background: - -.. code-block:: bash - - $ ansible web1.example.com -m async_status -a "jid=488359678239.2844" - -Ansible can also check on the status of your long-running job automatically with polling. In most cases, Ansible will keep the connection to your remote node open between polls. To run for 30 minutes and poll for status every 60 seconds: - -.. code-block:: bash - - $ ansible all -B 1800 -P 60 -a "/usr/bin/long_running_operation --do-stuff" - -Poll mode is smart so all jobs will be started before polling begins on any machine. Be sure to use a high enough ``--forks`` value if you want to get all of your jobs started very quickly. After the time limit (in seconds) runs out (``-B``), the process on the remote nodes will be terminated. - -Asynchronous mode is best suited to long-running shell commands or software upgrades. Running the copy module asynchronously, for example, does not do a background file transfer. - -Asynchronous playbook tasks ---------------------------- - -:ref:`Playbooks ` also support asynchronous mode and polling, with a simplified syntax. You can use asynchronous mode in playbooks to avoid connection timeouts or to avoid blocking subsequent tasks. The behavior of asynchronous mode in a playbook depends on the value of `poll`. - -Avoid connection timeouts: poll > 0 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want to set a longer timeout limit for a certain task in your playbook, use ``async`` with ``poll`` set to a positive value. Ansible will still block the next task in your playbook, waiting until the async task either completes, fails or times out. However, the task will only time out if it exceeds the timeout limit you set with the ``async`` parameter. - -To avoid timeouts on a task, specify its maximum runtime and how frequently you would like to poll for status: - -.. code-block:: yaml - - --- - - - hosts: all - remote_user: root - - tasks: - - - name: Simulate long running op (15 sec), wait for up to 45 sec, poll every 5 sec - ansible.builtin.command: /bin/sleep 15 - async: 45 - poll: 5 - -.. note:: - The default poll value is set by the :ref:`DEFAULT_POLL_INTERVAL` setting. - There is no default for the async time limit. If you leave off the - 'async' keyword, the task runs synchronously, which is Ansible's - default. - -.. note:: - As of Ansible 2.3, async does not support check mode and will fail the - task when run in check mode. See :ref:`check_mode_dry` on how to - skip a task in check mode. - -.. note:: - When an async task completes with polling enabled, the temporary async job cache - file (by default in ~/.ansible_async/) is automatically removed. - -Run tasks concurrently: poll = 0 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want to run multiple tasks in a playbook concurrently, use ``async`` with ``poll`` set to 0. When you set ``poll: 0``, Ansible starts the task and immediately moves on to the next task without waiting for a result. Each async task runs until it either completes, fails or times out (runs longer than its ``async`` value). The playbook run ends without checking back on async tasks. - -To run a playbook task asynchronously: - -.. code-block:: yaml - - --- - - - hosts: all - remote_user: root - - tasks: - - - name: Simulate long running op, allow to run for 45 sec, fire and forget - ansible.builtin.command: /bin/sleep 15 - async: 45 - poll: 0 - -.. note:: - Do not specify a poll value of 0 with operations that require exclusive locks (such as yum transactions) if you expect to run other commands later in the playbook against those same resources. - -.. note:: - Using a higher value for ``--forks`` will result in kicking off asynchronous tasks even faster. This also increases the efficiency of polling. - -.. note:: - When running with ``poll: 0``, Ansible will not automatically cleanup the async job cache file. - You will need to manually clean this up with the :ref:`async_status ` module - with ``mode: cleanup``. - -If you need a synchronization point with an async task, you can register it to obtain its job ID and use the :ref:`async_status ` module to observe it in a later task. For example: - -.. code-block:: yaml+jinja - - - name: Run an async task - ansible.builtin.yum: - name: docker-io - state: present - async: 1000 - poll: 0 - register: yum_sleeper - - - name: Check on an async task - async_status: - jid: "{{ yum_sleeper.ansible_job_id }}" - register: job_result - until: job_result.finished - retries: 100 - delay: 10 - -.. note:: - If the value of ``async:`` is not high enough, this will cause the - "check on it later" task to fail because the temporary status file that - the ``async_status:`` is looking for will not have been written or no longer exist - -.. note:: - Asynchronous playbook tasks always return changed. If the task is using a module - that requires the user to annotate changes with ``changed_when``, ``creates``, and so on, - then those should be added to the following ``async_status`` task. - -To run multiple asynchronous tasks while limiting the number of tasks running concurrently: - -.. code-block:: yaml+jinja - - ##################### - # main.yml - ##################### - - name: Run items asynchronously in batch of two items - vars: - sleep_durations: - - 1 - - 2 - - 3 - - 4 - - 5 - durations: "{{ item }}" - include_tasks: execute_batch.yml - loop: "{{ sleep_durations | batch(2) | list }}" - - ##################### - # execute_batch.yml - ##################### - - name: Async sleeping for batched_items - ansible.builtin.command: sleep {{ async_item }} - async: 45 - poll: 0 - loop: "{{ durations }}" - loop_control: - loop_var: "async_item" - register: async_results - - - name: Check sync status - async_status: - jid: "{{ async_result_item.ansible_job_id }}" - loop: "{{ async_results.results }}" - loop_control: - loop_var: "async_result_item" - register: async_poll_results - until: async_poll_results.finished - retries: 30 - -.. seealso:: - - :ref:`playbooks_strategies` - Options for controlling playbook execution - :ref:`playbooks_intro` - An introduction to playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_blocks.rst b/docs/docsite/rst/playbook_guide/playbooks_blocks.rst deleted file mode 100644 index 805045daa38..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_blocks.rst +++ /dev/null @@ -1,193 +0,0 @@ -.. _playbooks_blocks: - -****** -Blocks -****** - -Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages. - -.. contents:: - :local: - -Grouping tasks with blocks -========================== - -All tasks in a block inherit directives applied at the block level. Most of what you can apply to a single task (with the exception of loops) can be applied at the block level, so blocks make it much easier to set data or directives common to the tasks. The directive does not affect the block itself, it is only inherited by the tasks enclosed by a block. For example, a `when` statement is applied to the tasks within a block, not to the block itself. - -.. code-block:: YAML - :emphasize-lines: 3 - :caption: Block example with named tasks inside the block - - tasks: - - name: Install, configure, and start Apache - block: - - name: Install httpd and memcached - ansible.builtin.yum: - name: - - httpd - - memcached - state: present - - - name: Apply the foo config template - ansible.builtin.template: - src: templates/src.j2 - dest: /etc/foo.conf - - - name: Start service bar and enable it - ansible.builtin.service: - name: bar - state: started - enabled: True - when: ansible_facts['distribution'] == 'CentOS' - become: true - become_user: root - ignore_errors: true - -In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: true`` ensures that Ansible continues to execute the playbook even if some of the tasks fail. - -Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook. - -.. _block_error_handling: - -Handling errors with blocks -=========================== - -You can control how Ansible responds to task errors using blocks with ``rescue`` and ``always`` sections. - -Rescue blocks specify tasks to run when an earlier task in a block fails. This approach is similar to exception handling in many programming languages. Ansible only runs rescue blocks after a task returns a 'failed' state. Bad task definitions and unreachable hosts will not trigger the rescue block. - -.. _block_rescue: -.. code-block:: YAML - :emphasize-lines: 3,14 - :caption: Block error handling example - - tasks: - - name: Handle the error - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - - - name: Force a failure - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I never execute, due to the above task failing, :-(' - rescue: - - name: Print when errors - ansible.builtin.debug: - msg: 'I caught an error, can do stuff here to fix it, :-)' - -You can also add an ``always`` section to a block. Tasks in the ``always`` section run no matter what the task status of the previous block is. - -.. _block_always: -.. code-block:: YAML - :emphasize-lines: 2,13 - :caption: Block with always section - - - name: Always do X - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - - - name: Force a failure - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I never execute :-(' - always: - - name: Always do this - ansible.builtin.debug: - msg: "This always executes, :-)" - -Together, these elements offer complex error handling. - -.. code-block:: YAML - :emphasize-lines: 2,13,24 - :caption: Block with all sections - - - name: Attempt and graceful roll back demo - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - - - name: Force a failure - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I never execute, due to the above task failing, :-(' - rescue: - - name: Print when errors - ansible.builtin.debug: - msg: 'I caught an error' - - - name: Force a failure in middle of recovery! >:-) - ansible.builtin.command: /bin/false - - - name: Never print this - ansible.builtin.debug: - msg: 'I also never execute :-(' - always: - - name: Always do this - ansible.builtin.debug: - msg: "This always executes" - -The tasks in the ``block`` execute normally. If any tasks in the block return ``failed``, the ``rescue`` section executes tasks to recover from the error. The ``always`` section runs regardless of the results of the ``block`` and ``rescue`` sections. - -If an error occurs in the block and the rescue task succeeds, Ansible reverts the failed status of the original task for the run and continues to run the play as if the original task had succeeded. The rescued task is considered successful, and does not trigger ``max_fail_percentage`` or ``any_errors_fatal`` configurations. However, Ansible still reports a failure in the playbook statistics. - -You can use blocks with ``flush_handlers`` in a rescue task to ensure that all handlers run even if an error occurs: - -.. code-block:: YAML - :emphasize-lines: 3,12 - :caption: Block run handlers in error handling - - tasks: - - name: Attempt and graceful roll back demo - block: - - name: Print a message - ansible.builtin.debug: - msg: 'I execute normally' - changed_when: true - notify: run me even after an error - - - name: Force a failure - ansible.builtin.command: /bin/false - rescue: - - name: Make sure all handlers run - meta: flush_handlers - handlers: - - name: Run me even after an error - ansible.builtin.debug: - msg: 'This handler runs even on error' - - -.. versionadded:: 2.1 - -Ansible provides a couple of variables for tasks in the ``rescue`` portion of a block: - -ansible_failed_task - The task that returned 'failed' and triggered the rescue. For example, to get the name use ``ansible_failed_task.name``. - -ansible_failed_result - The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the ``register`` keyword. - -.. note:: - - In ``ansible-core`` 2.14 or later, both variables are propagated from an inner block to an outer ``rescue`` portion of a block. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst b/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst deleted file mode 100644 index 6b8c8277318..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst +++ /dev/null @@ -1,107 +0,0 @@ -.. _check_mode_dry: - -****************************************** -Validating tasks: check mode and diff mode -****************************************** - -Ansible provides two modes of execution that validate tasks: check mode and diff mode. These modes can be used separately or together. They are useful when you are creating or editing a playbook or role and you want to know what it will do. In check mode, Ansible runs without making any changes on remote systems. Modules that support check mode report the changes they would have made. Modules that do not support check mode report nothing and do nothing. In diff mode, Ansible provides before-and-after comparisons. Modules that support diff mode display detailed information. You can combine check mode and diff mode for detailed validation of your playbook or role. - -.. contents:: - :local: - -Using check mode -================ - -Check mode is just a simulation. It will not generate output for tasks that use :ref:`conditionals based on registered variables ` (results of prior tasks). However, it is great for validating configuration management playbooks that run on one node at a time. To run a playbook in check mode: - -.. code-block:: console - - ansible-playbook foo.yml --check - -.. _forcing_to_run_in_check_mode: - -Enforcing or preventing check mode on tasks -------------------------------------------- - -.. versionadded:: 2.2 - -If you want certain tasks to run in check mode always, or never, regardless of whether you run the playbook with or without ``--check``, you can add the ``check_mode`` option to those tasks: - - - To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: true``. - - To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: false``. - -For example: - -.. code-block:: yaml - - tasks: - - name: This task will always make changes to the system - ansible.builtin.command: /something/to/run --even-in-check-mode - check_mode: false - - - name: This task will never make changes to the system - ansible.builtin.lineinfile: - line: "important config" - dest: /path/to/myconfig.conf - state: present - check_mode: true - register: changes_to_important_config - -Running single tasks with ``check_mode: true`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes. - -.. note:: Prior to version 2.2 only the equivalent of ``check_mode: false`` existed. The notation for that was ``always_run: yes``. - -Skipping tasks or ignoring errors in check mode ------------------------------------------------ - -.. versionadded:: 2.1 - -If you want to skip a task or ignore errors on a task when you run Ansible in check mode, you can use a boolean magic variable ``ansible_check_mode``, which is set to ``True`` when Ansible runs in check mode. For example: - -.. code-block:: yaml - - tasks: - - - name: This task will be skipped in check mode - ansible.builtin.git: - repo: ssh://git@github.com/mylogin/hello.git - dest: /home/mylogin/hello - when: not ansible_check_mode - - - name: This task will ignore errors in check mode - ansible.builtin.git: - repo: ssh://git@github.com/mylogin/hello.git - dest: /home/mylogin/hello - ignore_errors: "{{ ansible_check_mode }}" - -.. _diff_mode: - -Using diff mode -=============== - -The ``--diff`` option for ansible-playbook can be used alone or with ``--check``. When you run in diff mode, any module that supports diff mode reports the changes made or, if used with ``--check``, the changes that would have been made. Diff mode is most common in modules that manipulate files (for example, the template module) but other modules might also show 'before and after' information (for example, the user module). - -Diff mode produces a large amount of output, so it is best used when checking a single host at a time. For example: - -.. code-block:: console - - ansible-playbook foo.yml --check --diff --limit foo.example.com - -.. versionadded:: 2.4 - -Enforcing or preventing diff mode on tasks ------------------------------------------- - -Because the ``--diff`` option can reveal sensitive information, you can disable it for a task by specifying ``diff: no``. For example: - -.. code-block:: yaml - - tasks: - - name: This task will not report a diff when the file changes - ansible.builtin.template: - src: secret.conf.j2 - dest: /etc/secret.conf - owner: root - group: root - mode: '0600' - diff: false diff --git a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst b/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst deleted file mode 100644 index 1de9ec39c71..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst +++ /dev/null @@ -1,593 +0,0 @@ -.. _playbooks_conditionals: - -************ -Conditionals -************ - -In a playbook, you may want to execute different tasks, or have different goals, depending on the value of a fact (data about the remote system), a variable, or the result of a previous task. You may want the value of some variables to depend on the value of other variables. Or you may want to create additional groups of hosts based on whether the hosts match other criteria. You can do all of these things with conditionals. - -Ansible uses Jinja2 :ref:`tests ` and :ref:`filters ` in conditionals. Ansible supports all the standard tests and filters, and adds some unique ones as well. - -.. note:: - - There are many options to control execution flow in Ansible. You can find more examples of supported conditionals at ``_. - -.. contents:: - :local: - -.. _the_when_statement: - -Basic conditionals with ``when`` -================================ - -The simplest conditional statement applies to a single task. Create the task, then add a ``when`` statement that applies a test. The ``when`` clause is a raw Jinja2 expression without double curly braces (see :ref:`group_by_module`). When you run the task or playbook, Ansible evaluates the test for all hosts. On any host where the test passes (returns a value of True), Ansible runs that task. For example, if you are installing mysql on multiple machines, some of which have SELinux enabled, you might have a task to configure SELinux to allow mysql to run. You would only want that task to run on machines that have SELinux enabled: - -.. code-block:: yaml - - tasks: - - name: Configure SELinux to start mysql on any port - ansible.posix.seboolean: - name: mysql_connect_any - state: true - persistent: true - when: ansible_selinux.status == "enabled" - # all variables can be used directly in conditionals without double curly braces - -Conditionals based on ansible_facts ------------------------------------ - -Often you want to execute or skip a task based on facts. Facts are attributes of individual hosts, including IP address, operating system, the status of a filesystem, and many more. With conditionals based on facts: - - - You can install a certain package only when the operating system is a particular version. - - You can skip configuring a firewall on hosts with internal IP addresses. - - You can perform cleanup tasks only when a filesystem is getting full. - -See :ref:`commonly_used_facts` for a list of facts that frequently appear in conditional statements. Not all facts exist for all hosts. For example, the 'lsb_major_release' fact used in an example below only exists when the lsb_release package is installed on the target host. To see what facts are available on your systems, add a debug task to your playbook: - -.. code-block:: yaml - - - name: Show facts available on the system - ansible.builtin.debug: - var: ansible_facts - -Here is a sample conditional based on a fact: - -.. code-block:: yaml - - tasks: - - name: Shut down Debian flavored systems - ansible.builtin.command: /sbin/shutdown -t now - when: ansible_facts['os_family'] == "Debian" - -If you have multiple conditions, you can group them with parentheses: - -.. code-block:: yaml - - tasks: - - name: Shut down CentOS 6 and Debian 7 systems - ansible.builtin.command: /sbin/shutdown -t now - when: (ansible_facts['distribution'] == "CentOS" and ansible_facts['distribution_major_version'] == "6") or - (ansible_facts['distribution'] == "Debian" and ansible_facts['distribution_major_version'] == "7") - -You can use `logical operators `_ to combine conditions. When you have multiple conditions that all need to be true (that is, a logical ``and``), you can specify them as a list: - -.. code-block:: yaml - - tasks: - - name: Shut down CentOS 6 systems - ansible.builtin.command: /sbin/shutdown -t now - when: - - ansible_facts['distribution'] == "CentOS" - - ansible_facts['distribution_major_version'] == "6" - -If a fact or variable is a string, and you need to run a mathematical comparison on it, use a filter to ensure that Ansible reads the value as an integer: - -.. code-block:: yaml - - tasks: - - ansible.builtin.shell: echo "only on Red Hat 6, derivatives, and later" - when: ansible_facts['os_family'] == "RedHat" and ansible_facts['lsb']['major_release'] | int >= 6 - -.. _conditionals_registered_vars: - -Conditions based on registered variables ----------------------------------------- - -Often in a playbook you want to execute or skip a task based on the outcome of an earlier task. For example, you might want to configure a service after it is upgraded by an earlier task. To create a conditional based on a registered variable: - - #. Register the outcome of the earlier task as a variable. - #. Create a conditional test based on the registered variable. - -You create the name of the registered variable using the ``register`` keyword. A registered variable always contains the status of the task that created it as well as any output that task generated. You can use registered variables in templates and action lines as well as in conditional ``when`` statements. You can access the string contents of the registered variable using ``variable.stdout``. For example: - -.. code-block:: yaml - - - name: Test play - hosts: all - - tasks: - - - name: Register a variable - ansible.builtin.shell: cat /etc/motd - register: motd_contents - - - name: Use the variable in conditional statement - ansible.builtin.shell: echo "motd contains the word hi" - when: motd_contents.stdout.find('hi') != -1 - -You can use registered results in the loop of a task if the variable is a list. If the variable is not a list, you can convert it into a list, with either ``stdout_lines`` or with ``variable.stdout.split()``. You can also split the lines by other fields: - -.. code-block:: yaml - - - name: Registered variable usage as a loop list - hosts: all - tasks: - - - name: Retrieve the list of home directories - ansible.builtin.command: ls /home - register: home_dirs - - - name: Add home dirs to the backup spooler - ansible.builtin.file: - path: /mnt/bkspool/{{ item }} - src: /home/{{ item }} - state: link - loop: "{{ home_dirs.stdout_lines }}" - # same as loop: "{{ home_dirs.stdout.split() }}" - -The string content of a registered variable can be empty. If you want to run another task only on hosts where the stdout of your registered variable is empty, check the registered variable's string contents for emptiness: - -.. code-block:: yaml - - - name: check registered variable for emptiness - hosts: all - - tasks: - - - name: List contents of directory - ansible.builtin.command: ls mydir - register: contents - - - name: Check contents for emptiness - ansible.builtin.debug: - msg: "Directory is empty" - when: contents.stdout == "" - -Ansible always registers something in a registered variable for every host, even on hosts where a task fails or Ansible skips a task because a condition is not met. To run a follow-up task on these hosts, query the registered variable for ``is skipped`` (not for "undefined" or "default"). See :ref:`registered_variables` for more information. Here are sample conditionals based on the success or failure of a task. Remember to ignore errors if you want Ansible to continue executing on a host when a failure occurs: - -.. code-block:: yaml - - tasks: - - name: Register a variable, ignore errors and continue - ansible.builtin.command: /bin/false - register: result - ignore_errors: true - - - name: Run only if the task that registered the "result" variable fails - ansible.builtin.command: /bin/something - when: result is failed - - - name: Run only if the task that registered the "result" variable succeeds - ansible.builtin.command: /bin/something_else - when: result is succeeded - - - name: Run only if the task that registered the "result" variable is skipped - ansible.builtin.command: /bin/still/something_else - when: result is skipped - - - name: Run only if the task that registered the "result" variable changed something. - ansible.builtin.command: /bin/still/something_else - when: result is changed - -.. note:: Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid. - - -Conditionals based on variables -------------------------------- - -You can also create conditionals based on variables defined in the playbooks or inventory. Because conditionals require boolean input (a test must evaluate as True to trigger the condition), you must apply the ``| bool`` filter to non boolean variables, such as string variables with content like 'yes', 'on', '1', or 'true'. You can define variables like this: - -.. code-block:: yaml - - vars: - epic: true - monumental: "yes" - -With the variables above, Ansible would run one of these tasks and skip the other: - -.. code-block:: yaml - - tasks: - - name: Run the command if "epic" or "monumental" is true - ansible.builtin.shell: echo "This certainly is epic!" - when: epic or monumental | bool - - - name: Run the command if "epic" is false - ansible.builtin.shell: echo "This certainly isn't epic!" - when: not epic - -If a required variable has not been set, you can skip or fail using Jinja2's `defined` test. For example: - -.. code-block:: yaml - - tasks: - - name: Run the command if "foo" is defined - ansible.builtin.shell: echo "I've got '{{ foo }}' and am not afraid to use it!" - when: foo is defined - - - name: Fail if "bar" is undefined - ansible.builtin.fail: msg="Bailing out. This play requires 'bar'" - when: bar is undefined - -This is especially useful in combination with the conditional import of vars files (see below). -As the examples show, you do not need to use `{{ }}` to use variables inside conditionals, as these are already implied. - -.. _loops_and_conditionals: - -Using conditionals in loops ---------------------------- - -If you combine a ``when`` statement with a :ref:`loop `, Ansible processes the condition separately for each item. This is by design, so you can execute the task on some items in the loop and skip it on other items. For example: - -.. code-block:: yaml - - tasks: - - name: Run with items greater than 5 - ansible.builtin.command: echo {{ item }} - loop: [ 0, 2, 4, 6, 8, 10 ] - when: item > 5 - -If you need to skip the whole task when the loop variable is undefined, use the `|default` filter to provide an empty iterator. For example, when looping over a list: - -.. code-block:: yaml - - - name: Skip the whole task when a loop variable is undefined - ansible.builtin.command: echo {{ item }} - loop: "{{ mylist|default([]) }}" - when: item > 5 - -You can do the same thing when looping over a dict: - -.. code-block:: yaml - - - name: The same as above using a dict - ansible.builtin.command: echo {{ item.key }} - loop: "{{ query('dict', mydict|default({})) }}" - when: item.value > 5 - -.. _loading_in_custom_facts: - -Loading custom facts --------------------- - -You can provide your own facts, as described in :ref:`developing_modules`. To run them, just make a call to your own custom fact gathering module at the top of your list of tasks, and variables returned there will be accessible to future tasks: - -.. code-block:: yaml - - tasks: - - name: Gather site specific fact data - action: site_facts - - - name: Use a custom fact - ansible.builtin.command: /usr/bin/thingy - when: my_custom_fact_just_retrieved_from_the_remote_system == '1234' - -.. _when_with_reuse: - -Conditionals with re-use ------------------------- - -You can use conditionals with re-usable tasks files, playbooks, or roles. Ansible executes these conditional statements differently for dynamic re-use (includes) and for static re-use (imports). See :ref:`playbooks_reuse` for more information on re-use in Ansible. - -.. _conditional_imports: - -Conditionals with imports -^^^^^^^^^^^^^^^^^^^^^^^^^ - -When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, if you want to define and then display a variable that was not previously defined, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``: - -.. code-block:: yaml - - # all tasks within an imported file inherit the condition from the import statement - # main.yml - - hosts: all - tasks: - - import_tasks: other_tasks.yml # note "import" - when: x is not defined - - # other_tasks.yml - - name: Set a variable - ansible.builtin.set_fact: - x: foo - - - name: Print a variable - ansible.builtin.debug: - var: x - -Ansible expands this at execution time to the equivalent of: - -.. code-block:: yaml - - - name: Set a variable if not defined - ansible.builtin.set_fact: - x: foo - when: x is not defined - # this task sets a value for x - - - name: Do the task if "x" is not defined - ansible.builtin.debug: - var: x - when: x is not defined - # Ansible skips this task, because x is now defined - -If ``x`` is initially defined, both tasks are skipped as intended. But if ``x`` is initially undefined, the debug task will be skipped since the conditional is evaluated for every imported task. The conditional will evaluate to ``true`` for the ``set_fact`` task, which will define the variable and cause the ``debug`` conditional to evaluate to ``false``. - -If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself. - -.. code-block:: yaml - - # using a conditional on include_* only applies to the include task itself - # main.yml - - hosts: all - tasks: - - include_tasks: other_tasks.yml # note "include" - when: x is not defined - -Now if ``x`` is initially undefined, the debug task will not be skipped because the conditional is evaluated at the time of the include and does not apply to the individual tasks. - -You can apply conditions to ``import_playbook`` as well as to the other ``import_*`` statements. When you use this approach, Ansible returns a 'skipped' message for every task on every host that does not match the criteria, creating repetitive output. In many cases the :ref:`group_by module ` can be a more streamlined way to accomplish the same objective; see :ref:`os_variance`. - -.. _conditional_includes: - -Conditionals with includes -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When you use a conditional on an ``include_*`` statement, the condition is applied only to the include task itself and not to any other tasks within the included file(s). To contrast with the example used for conditionals on imports above, look at the same playbook and tasks file, but using an include instead of an import: - -.. code-block:: yaml - - # Includes let you re-use a file to define a variable when it is not already defined - - # main.yml - - include_tasks: other_tasks.yml - when: x is not defined - - # other_tasks.yml - - name: Set a variable - ansible.builtin.set_fact: - x: foo - - - name: Print a variable - ansible.builtin.debug: - var: x - -Ansible expands this at execution time to the equivalent of: - -.. code-block:: yaml - - # main.yml - - include_tasks: other_tasks.yml - when: x is not defined - # if condition is met, Ansible includes other_tasks.yml - - # other_tasks.yml - - name: Set a variable - ansible.builtin.set_fact: - x: foo - # no condition applied to this task, Ansible sets the value of x to foo - - - name: Print a variable - ansible.builtin.debug: - var: x - # no condition applied to this task, Ansible prints the debug statement - -By using ``include_tasks`` instead of ``import_tasks``, both tasks from ``other_tasks.yml`` will be executed as expected. For more information on the differences between ``include`` v ``import`` see :ref:`playbooks_reuse`. - -Conditionals with roles -^^^^^^^^^^^^^^^^^^^^^^^ - -There are three ways to apply conditions to roles: - - - Add the same condition or conditions to all tasks in the role by placing your ``when`` statement under the ``roles`` keyword. See the example in this section. - - Add the same condition or conditions to all tasks in the role by placing your ``when`` statement on a static ``import_role`` in your playbook. - - Add a condition or conditions to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role based on your ``when`` statement. To select or skip tasks within the role, you must have conditions set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the condition or conditions to the include. When you use this approach, Ansible applies the condition to the include itself plus any tasks in the role that also have that ``when`` statement. - -When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds the conditions you define to all the tasks in the role. For example: - -.. code-block:: yaml - - - hosts: webservers - roles: - - role: debian_stock_config - when: ansible_facts['os_family'] == 'Debian' - -.. _conditional_variable_and_files: - -Selecting variables, files, or templates based on facts -------------------------------------------------------- - -Sometimes the facts about a host determine the values you want to use for certain variables or even the file or template you want to select for that host. For example, the names of packages are different on CentOS and on Debian. The configuration files for common services are also different on different OS flavors and versions. To load different variables file, templates, or other files based on a fact about the hosts: - - 1) name your vars files, templates, or files to match the Ansible fact that differentiates them - - 2) select the correct vars file, template, or file for each host with a variable based on that Ansible fact - -Ansible separates variables from tasks, keeping your playbooks from turning into arbitrary code with nested conditionals. This approach results in more streamlined and auditable configuration rules because there are fewer decision points to track. - -Selecting variables files based on facts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can create a playbook that works on multiple platforms and OS versions with a minimum of syntax by placing your variable values in vars files and conditionally importing them. If you want to install Apache on some CentOS and some Debian servers, create variables files with YAML keys and values. For example: - -.. code-block:: yaml - - --- - # for vars/RedHat.yml - apache: httpd - somethingelse: 42 - -Then import those variables files based on the facts you gather on the hosts in your playbook: - -.. code-block:: yaml - - --- - - hosts: webservers - remote_user: root - vars_files: - - "vars/common.yml" - - [ "vars/{{ ansible_facts['os_family'] }}.yml", "vars/os_defaults.yml" ] - tasks: - - name: Make sure apache is started - ansible.builtin.service: - name: '{{ apache }}' - state: started - -Ansible gathers facts on the hosts in the webservers group, then interpolates the variable "ansible_facts['os_family']" into a list of filenames. If you have hosts with Red Hat operating systems (CentOS, for example), Ansible looks for 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. For Debian hosts, Ansible first looks for 'vars/Debian.yml', before falling back on 'vars/os_defaults.yml'. If no files in the list are found, Ansible raises an error. - -Selecting files and templates based on facts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can use the same approach when different OS flavors or versions require different configuration files or templates. Select the appropriate file or template based on the variables assigned to each host. This approach is often much cleaner than putting a lot of conditionals into a single template to cover multiple OS or package versions. - -For example, you can template out a configuration file that is very different between, say, CentOS and Debian: - -.. code-block:: yaml - - - name: Template a file - ansible.builtin.template: - src: "{{ item }}" - dest: /etc/myapp/foo.conf - loop: "{{ query('first_found', { 'files': myfiles, 'paths': mypaths}) }}" - vars: - myfiles: - - "{{ ansible_facts['distribution'] }}.conf" - - default.conf - mypaths: ['search_location_one/somedir/', '/opt/other_location/somedir/'] - -.. _debugging_conditionals: - -Debugging conditionals -====================== - -If your conditional ``when`` statement is not behaving as you intended, you can add a ``debug`` statement to determine if the condition evaluates to ``true`` or ``false``. A common cause of unexpected behavior in conditionals is testing an integer as a string or a string as an integer. To debug a conditional statement, add the entire statement as the ``var:`` value in a ``debug`` task. Ansible then shows the test and how the statement evaluates. For example, here is a set of tasks and sample output: - -.. code-block:: yaml - - - name: check value of return code - ansible.builtin.debug: - var: bar_status.rc - - - name: check test for rc value as string - ansible.builtin.debug: - var: bar_status.rc == "127" - - - name: check test for rc value as integer - ansible.builtin.debug: - var: bar_status.rc == 127 - -.. code-block:: ansible-output - - TASK [check value of return code] ********************************************************************************* - ok: [foo-1] => { - "bar_status.rc": "127" - } - - TASK [check test for rc value as string] ************************************************************************** - ok: [foo-1] => { - "bar_status.rc == \"127\"": false - } - - TASK [check test for rc value as integer] ************************************************************************* - ok: [foo-1] => { - "bar_status.rc == 127": true - } - -.. _commonly_used_facts: - -Commonly-used facts -=================== - -The following Ansible facts are frequently used in conditionals. - -.. _ansible_distribution: - -ansible_facts['distribution'] ------------------------------ - -Possible values (sample, not complete list): - -.. code-block:: text - - Alpine - Altlinux - Amazon - Archlinux - ClearLinux - Coreos - CentOS - Debian - Fedora - Gentoo - Mandriva - NA - OpenWrt - OracleLinux - RedHat - Slackware - SLES - SMGL - SUSE - Ubuntu - VMwareESX - -.. See `OSDIST_LIST` - -.. _ansible_distribution_major_version: - -ansible_facts['distribution_major_version'] -------------------------------------------- - -The major version of the operating system. For example, the value is `16` for Ubuntu 16.04. - -.. _ansible_os_family: - -ansible_facts['os_family'] --------------------------- - -Possible values (sample, not complete list): - -.. code-block:: text - - AIX - Alpine - Altlinux - Archlinux - Darwin - Debian - FreeBSD - Gentoo - HP-UX - Mandrake - RedHat - SGML - Slackware - Solaris - Suse - Windows - -.. Ansible checks `OS_FAMILY_MAP`; if there's no match, it returns the value of `platform.system()`. - -.. seealso:: - - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_debugger.rst b/docs/docsite/rst/playbook_guide/playbooks_debugger.rst deleted file mode 100644 index 79d7c31ee09..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_debugger.rst +++ /dev/null @@ -1,342 +0,0 @@ -.. _playbook_debugger: - -*************** -Debugging tasks -*************** - -Ansible offers a task debugger so you can fix errors during execution instead of editing your playbook and running it again to see if your change worked. You have access to all of the features of the debugger in the context of the task. You can check or set the value of variables, update module arguments, and re-run the task with the new variables and arguments. The debugger lets you resolve the cause of the failure and continue with playbook execution. - -.. contents:: - :local: - -Enabling the debugger -===================== - -The debugger is not enabled by default. If you want to invoke the debugger during playbook execution, you must enable it first. - -Use one of these three methods to enable the debugger: - - * with the debugger keyword - * in configuration or an environment variable, or - * as a strategy - -Enabling the debugger with the ``debugger`` keyword ---------------------------------------------------- - -.. versionadded:: 2.5 - -You can use the ``debugger`` keyword to enable (or disable) the debugger for a specific play, role, block, or task. This option is especially useful when developing or extending playbooks, plays, and roles. You can enable the debugger on new or updated tasks. If they fail, you can fix the errors efficiently. The ``debugger`` keyword accepts five values: - -.. table:: - :class: documentation-table - - ========================= ====================================================== - Value Result - ========================= ====================================================== - always Always invoke the debugger, regardless of the outcome - - never Never invoke the debugger, regardless of the outcome - - on_failed Only invoke the debugger if a task fails - - on_unreachable Only invoke the debugger if a host is unreachable - - on_skipped Only invoke the debugger if the task is skipped - - ========================= ====================================================== - -When you use the ``debugger`` keyword, the value you specify overrides any global configuration to enable or disable the debugger. If you define ``debugger`` at multiple levels, such as in a role and in a task, Ansible honors the most granular definition. The definition at the play or role level applies to all blocks and tasks within that play or role, unless they specify a different value. The definition at the block level overrides the definition at the play or role level, and applies to all tasks within that block, unless they specify a different value. The definition at the task level always applies to the task; it overrides the definitions at the block, play, or role level. - -Examples of using the ``debugger`` keyword -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Example of setting the ``debugger`` keyword on a task: - -.. code-block:: yaml - - - name: Execute a command - ansible.builtin.command: "false" - debugger: on_failed - -Example of setting the ``debugger`` keyword on a play: - -.. code-block:: yaml - - - name: My play - hosts: all - debugger: on_skipped - tasks: - - name: Execute a command - ansible.builtin.command: "true" - when: False - -Example of setting the ``debugger`` keyword at multiple levels: - -.. code-block:: yaml - - - name: Play - hosts: all - debugger: never - tasks: - - name: Execute a command - ansible.builtin.command: "false" - debugger: on_failed - -In this example, the debugger is set to ``never`` at the play level and to ``on_failed`` at the task level. If the task fails, Ansible invokes the debugger, because the definition on the task overrides the definition on its parent play. - -Enabling the debugger in configuration or an environment variable ------------------------------------------------------------------ - -.. versionadded:: 2.5 - -You can enable the task debugger globally with a setting in ansible.cfg or with an environment variable. The only options are ``True`` or ``False``. If you set the configuration option or environment variable to ``True``, Ansible runs the debugger on failed tasks by default. - -To enable the task debugger from ansible.cfg, add this setting to the defaults section: - -.. code-block:: yaml - - [defaults] - enable_task_debugger = True - -To enable the task debugger with an environment variable, pass the variable when you run your playbook: - -.. code-block:: shell - - ANSIBLE_ENABLE_TASK_DEBUGGER=True ansible-playbook -i hosts site.yml - -When you enable the debugger globally, every failed task invokes the debugger, unless the role, play, block, or task explicitly disables the debugger. If you need more granular control over what conditions trigger the debugger, use the ``debugger`` keyword. - -Enabling the debugger as a strategy ------------------------------------ - -If you are running legacy playbooks or roles, you may see the debugger enabled as a :ref:`strategy `. You can do this at the play level, in ansible.cfg, or with the environment variable ``ANSIBLE_STRATEGY=debug``. For example: - -.. code-block:: yaml - - - hosts: test - strategy: debug - tasks: - ... - -Or in ansible.cfg: - -.. code-block:: ini - - [defaults] - strategy = debug - -.. note:: - - This backwards-compatible method, which matches Ansible versions before 2.5, may be removed in a future release. - -Resolving errors in the debugger -================================ - -After Ansible invokes the debugger, you can use the seven :ref:`debugger commands ` to resolve the error that Ansible encountered. Consider this example playbook, which defines the ``var1`` variable but uses the undefined ``wrong_var`` variable in a task by mistake. - -.. code-block:: yaml - - - hosts: test - debugger: on_failed - gather_facts: false - vars: - var1: value1 - tasks: - - name: Use a wrong variable - ansible.builtin.ping: data={{ wrong_var }} - -If you run this playbook, Ansible invokes the debugger when the task fails. From the debug prompt, you can change the module arguments or the variables and run the task again. - -.. code-block:: ansible-output - - PLAY *************************************************************************** - - TASK [wrong variable] ********************************************************** - fatal: [192.0.2.10]: FAILED! => {"failed": true, "msg": "ERROR! 'wrong_var' is undefined"} - Debugger invoked - [192.0.2.10] TASK: wrong variable (debug)> p result._result - {'failed': True, - 'msg': 'The task includes an option with an undefined variable. The error ' - "was: 'wrong_var' is undefined\n" - '\n' - 'The error appears to have been in ' - "'playbooks/debugger.yml': line 7, " - 'column 7, but may\n' - 'be elsewhere in the file depending on the exact syntax problem.\n' - '\n' - 'The offending line appears to be:\n' - '\n' - ' tasks:\n' - ' - name: wrong variable\n' - ' ^ here\n'} - [192.0.2.10] TASK: wrong variable (debug)> p task.args - {u'data': u'{{ wrong_var }}'} - [192.0.2.10] TASK: wrong variable (debug)> task.args['data'] = '{{ var1 }}' - [192.0.2.10] TASK: wrong variable (debug)> p task.args - {u'data': '{{ var1 }}'} - [192.0.2.10] TASK: wrong variable (debug)> redo - ok: [192.0.2.10] - - PLAY RECAP ********************************************************************* - 192.0.2.10 : ok=1 changed=0 unreachable=0 failed=0 - -Changing the task arguments in the debugger to use ``var1`` instead of ``wrong_var`` makes the task run successfully. - -.. _available_commands: - -Available debug commands -======================== - -You can use these seven commands at the debug prompt: - -.. table:: - :class: documentation-table - - ========================== ============ ========================================================= - Command Shortcut Action - ========================== ============ ========================================================= - print p Print information about the task - - task.args[*key*] = *value* no shortcut Update module arguments - - task_vars[*key*] = *value* no shortcut Update task variables (you must ``update_task`` next) - - update_task u Recreate a task with updated task variables - - redo r Run the task again - - continue c Continue executing, starting with the next task - - quit q Quit the debugger - - ========================== ============ ========================================================= - -For more details, see the individual descriptions and examples below. - -.. _pprint_command: - -Print command -------------- - -``print *task/task.args/task_vars/host/result*`` prints information about the task. - -.. code-block:: ansible-output - - [192.0.2.10] TASK: install package (debug)> p task - TASK: install package - [192.0.2.10] TASK: install package (debug)> p task.args - {u'name': u'{{ pkg_name }}'} - [192.0.2.10] TASK: install package (debug)> p task_vars - {u'ansible_all_ipv4_addresses': [u'192.0.2.10'], - u'ansible_architecture': u'x86_64', - ... - } - [192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name'] - u'bash' - [192.0.2.10] TASK: install package (debug)> p host - 192.0.2.10 - [192.0.2.10] TASK: install package (debug)> p result._result - {'_ansible_no_log': False, - 'changed': False, - u'failed': True, - ... - u'msg': u"No package matching 'not_exist' is available"} - -.. _update_args_command: - -Update args command -------------------- - -``task.args[*key*] = *value*`` updates a module argument. This sample playbook has an invalid package name. - -.. code-block:: yaml - - - hosts: test - strategy: debug - gather_facts: true - vars: - pkg_name: not_exist - tasks: - - name: Install a package - ansible.builtin.apt: name={{ pkg_name }} - -When you run the playbook, the invalid package name triggers an error, and Ansible invokes the debugger. You can fix the package name by viewing, then updating the module argument. - -.. code-block:: ansible-output - - [192.0.2.10] TASK: install package (debug)> p task.args - {u'name': u'{{ pkg_name }}'} - [192.0.2.10] TASK: install package (debug)> task.args['name'] = 'bash' - [192.0.2.10] TASK: install package (debug)> p task.args - {u'name': 'bash'} - [192.0.2.10] TASK: install package (debug)> redo - -After you update the module argument, use ``redo`` to run the task again with the new args. - -.. _update_vars_command: - -Update vars command -------------------- - -``task_vars[*key*] = *value*`` updates the ``task_vars``. You could fix the playbook above by viewing, then updating the task variables instead of the module args. - -.. code-block:: ansible-output - - [192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name'] - u'not_exist' - [192.0.2.10] TASK: install package (debug)> task_vars['pkg_name'] = 'bash' - [192.0.2.10] TASK: install package (debug)> p task_vars['pkg_name'] - 'bash' - [192.0.2.10] TASK: install package (debug)> update_task - [192.0.2.10] TASK: install package (debug)> redo - -After you update the task variables, you must use ``update_task`` to load the new variables before using ``redo`` to run the task again. - -.. note:: - In 2.5 this was updated from ``vars`` to ``task_vars`` to avoid conflicts with the ``vars()`` python function. - -.. _update_task_command: - -Update task command -------------------- - -.. versionadded:: 2.8 - -``u`` or ``update_task`` recreates the task from the original task data structure and templates with updated task variables. See the entry :ref:`update_vars_command` for an example of use. - -.. _redo_command: - -Redo command ------------- - -``r`` or ``redo`` runs the task again. - -.. _continue_command: - -Continue command ----------------- - -``c`` or ``continue`` continues executing, starting with the next task. - -.. _quit_command: - -Quit command ------------- - -``q`` or ``quit`` quits the debugger. The playbook execution is aborted. - -How the debugger interacts with the free strategy -================================================= - -With the default ``linear`` strategy enabled, Ansible halts execution while the debugger is active, and runs the debugged task immediately after you enter the ``redo`` command. With the ``free`` strategy enabled, however, Ansible does not wait for all hosts, and may queue later tasks on one host before a task fails on another host. With the ``free`` strategy, Ansible does not queue or execute any tasks while the debugger is active. However, all queued tasks remain in the queue and run as soon as you exit the debugger. If you use ``redo`` to reschedule a task from the debugger, other queued tasks may execute before your rescheduled task. For more information about strategies, see :ref:`playbooks_strategies`. - -.. seealso:: - - :ref:`playbooks_start_and_step` - Running playbooks while debugging or testing - :ref:`playbooks_intro` - An introduction to playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_delegation.rst b/docs/docsite/rst/playbook_guide/playbooks_delegation.rst deleted file mode 100644 index faf7c5b14ce..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_delegation.rst +++ /dev/null @@ -1,174 +0,0 @@ -.. _playbooks_delegation: - -Controlling where tasks run: delegation and local actions -========================================================= - -By default Ansible gathers facts and executes all tasks on the machines that match the ``hosts`` line of your playbook. This page shows you how to delegate tasks to a different machine or group, delegate facts to specific machines or groups, or run an entire playbook locally. Using these approaches, you can manage inter-related environments precisely and efficiently. For example, when updating your webservers, you might need to remove them from a load-balanced pool temporarily. You cannot perform this task on the webservers themselves. By delegating the task to localhost, you keep all the tasks within the same play. - -.. contents:: - :local: - -Tasks that cannot be delegated ------------------------------- - -Some tasks always execute on the controller. These tasks, including ``include``, ``add_host``, and ``debug``, cannot be delegated. - -.. _delegation: - -Delegating tasks ----------------- - -If you want to perform a task on one host with reference to other hosts, use the ``delegate_to`` keyword on a task. This is ideal for managing nodes in a load balanced pool or for controlling outage windows. You can use delegation with the :ref:`serial ` keyword to control the number of hosts executing at one time: - -.. code-block:: yaml - - --- - - hosts: webservers - serial: 5 - - tasks: - - name: Take out of load balancer pool - ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - - - name: Actual steps would go here - ansible.builtin.yum: - name: acme-web-stack - state: latest - - - name: Add back to load balancer pool - ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - -The first and third tasks in this play run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: ``local_action``. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1: - -.. code-block:: yaml - - --- - # ... - - tasks: - - name: Take out of load balancer pool - local_action: ansible.builtin.command /usr/bin/take_out_of_pool {{ inventory_hostname }} - - # ... - - - name: Add back to load balancer pool - local_action: ansible.builtin.command /usr/bin/add_back_to_pool {{ inventory_hostname }} - -You can use a local action to call 'rsync' to recursively copy files to the managed servers: - -.. code-block:: yaml - - --- - # ... - - tasks: - - name: Recursively copy files from management server to target - local_action: ansible.builtin.command rsync -a /path/to/files {{ inventory_hostname }}:/path/to/target/ - -Note that you must have passphrase-less SSH keys or an ssh-agent configured for this to work, otherwise rsync asks for a passphrase. - -To specify more arguments, use the following syntax: - -.. code-block:: yaml - - --- - # ... - - tasks: - - name: Send summary mail - local_action: - module: community.general.mail - subject: "Summary Mail" - to: "{{ mail_recipient }}" - body: "{{ mail_body }}" - run_once: True - -.. note:: - - The `ansible_host` variable and other connection variables, if present, reflects information about the host a task is delegated to, not the inventory_hostname. - -.. warning:: - - Although you can ``delegate_to`` a host that does not exist in inventory (by adding IP address, DNS name or whatever requirement the connection plugin has), doing so does not add the host to your inventory and might cause issues. Hosts delegated to in this way do not inherit variables from the "all" group', so variables like connection user and key are missing. If you must ``delegate_to`` a non-inventory host, use the :ref:`add host module `. - - -.. _delegate_parallel: - -Delegation and parallel execution ---------------------------------- -By default Ansible tasks are executed in parallel. Delegating a task does not change this and does not handle concurrency issues (multiple forks writing to the same file). -Most commonly, users are affected by this when updating a single file on a single delegated to host for all hosts (using the ``copy``, ``template``, or ``lineinfile`` modules, for example). They will still operate in parallel forks (default 5) and overwrite each other. - -This can be handled in several ways: - -.. code-block:: yaml - - - name: "handle concurrency with a loop on the hosts with `run_once: true`" - lineinfile: "" - run_once: true - loop: '{{ ansible_play_hosts_all }}' - -By using an intermediate play with `serial: 1` or using `throttle: 1` at task level, for more detail see :ref:`playbooks_strategies` - -.. _delegate_facts: - -Delegating facts ----------------- - -Delegating Ansible tasks is like delegating tasks in the real world - your groceries belong to you, even if someone else delivers them to your home. Similarly, any facts gathered by a delegated task are assigned by default to the `inventory_hostname` (the current host), not to the host which produced the facts (the delegated to host). To assign gathered facts to the delegated host instead of the current host, set ``delegate_facts`` to ``true``: - -.. code-block:: yaml - - --- - - hosts: app_servers - - tasks: - - name: Gather facts from db servers - ansible.builtin.setup: - delegate_to: "{{ item }}" - delegate_facts: true - loop: "{{ groups['dbservers'] }}" - -This task gathers facts for the machines in the dbservers group and assigns the facts to those machines, even though the play targets the app_servers group. This way you can lookup `hostvars['dbhost1']['ansible_default_ipv4']['address']` even though dbservers were not part of the play, or left out by using `--limit`. - -.. _local_playbooks: - -Local playbooks ---------------- - -It may be useful to use a playbook locally on a remote host, rather than by connecting over SSH. This can be useful for assuring the configuration of a system by putting a playbook in a crontab. This may also be used -to run a playbook inside an OS installer, such as an Anaconda kickstart. - -To run an entire playbook locally, just set the ``hosts:`` line to ``hosts: 127.0.0.1`` and then run the playbook like so: - -.. code-block:: shell - - ansible-playbook playbook.yml --connection=local - -Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook -use the default remote connection type: - -.. code-block:: yaml - - --- - - hosts: 127.0.0.1 - connection: local - -.. note:: - If you set the connection to local and there is no ansible_python_interpreter set, modules will run under /usr/bin/python and not - under {{ ansible_playbook_python }}. Be sure to set ansible_python_interpreter: "{{ ansible_playbook_python }}" in - host_vars/localhost.yml, for example. You can avoid this issue by using ``local_action`` or ``delegate_to: localhost`` instead. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_strategies` - More ways to control how and where Ansible executes - `Ansible Examples on GitHub `_ - Many examples of full-stack deployments - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_environment.rst b/docs/docsite/rst/playbook_guide/playbooks_environment.rst deleted file mode 100644 index d347812b9c2..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_environment.rst +++ /dev/null @@ -1,153 +0,0 @@ -.. _playbooks_environment: - -Setting the remote environment -============================== - -.. versionadded:: 1.1 - -You can use the ``environment`` keyword at the play, block, or task level to set an environment variable for an action on a remote host. With this keyword, you can enable using a proxy for a task that does http requests, set the required environment variables for language-specific version managers, and more. - -When you set a value with ``environment:`` at the play or block level, it is available only to tasks within the play or block that are executed by the same user. The ``environment:`` keyword does not affect Ansible itself, Ansible configuration settings, the environment for other users, or the execution of other plugins like lookups and filters. Variables set with ``environment:`` do not automatically become Ansible facts, even when you set them at the play level. You must include an explicit ``gather_facts`` task in your playbook and set the ``environment`` keyword on that task to turn these values into Ansible facts. - -.. contents:: - :local: - -Setting the remote environment in a task ----------------------------------------- - -You can set the environment directly at the task level. - -.. code-block:: yaml - - - hosts: all - remote_user: root - - tasks: - - - name: Install cobbler - ansible.builtin.package: - name: cobbler - state: present - environment: - http_proxy: http://proxy.example.com:8080 - -You can re-use environment settings by defining them as variables in your play and accessing them in a task as you would access any stored Ansible variable. - -.. code-block:: yaml - - - hosts: all - remote_user: root - - # create a variable named "proxy_env" that is a dictionary - vars: - proxy_env: - http_proxy: http://proxy.example.com:8080 - - tasks: - - - name: Install cobbler - ansible.builtin.package: - name: cobbler - state: present - environment: "{{ proxy_env }}" - -You can store environment settings for re-use in multiple playbooks by defining them in a group_vars file. - -.. code-block:: yaml - - --- - # file: group_vars/boston - - ntp_server: ntp.bos.example.com - backup: bak.bos.example.com - proxy_env: - http_proxy: http://proxy.bos.example.com:8080 - https_proxy: http://proxy.bos.example.com:8080 - -You can set the remote environment at the play level. - -.. code-block:: yaml - - - hosts: testing - - roles: - - php - - nginx - - environment: - http_proxy: http://proxy.example.com:8080 - -These examples show proxy settings, but you can provide any number of settings this way. - -Working with language-specific version managers -=============================================== - -Some language-specific version managers (such as rbenv and nvm) require you to set environment variables while these tools are in use. When using these tools manually, you usually source some environment variables from a script or from lines added to your shell configuration file. In Ansible, you can do this with the environment keyword at the play level. - -.. code-block:: yaml+jinja - - --- - ### A playbook demonstrating a common npm workflow: - # - Check for package.json in the application directory - # - If package.json exists: - # * Run npm prune - # * Run npm install - - - hosts: application - become: false - - vars: - node_app_dir: /var/local/my_node_app - - environment: - NVM_DIR: /var/local/nvm - PATH: /var/local/nvm/versions/node/v4.2.1/bin:{{ ansible_env.PATH }} - - tasks: - - name: Check for package.json - ansible.builtin.stat: - path: '{{ node_app_dir }}/package.json' - register: packagejson - - - name: Run npm prune - ansible.builtin.command: npm prune - args: - chdir: '{{ node_app_dir }}' - when: packagejson.stat.exists - - - name: Run npm install - community.general.npm: - path: '{{ node_app_dir }}' - when: packagejson.stat.exists - -.. note:: - The example above uses ``ansible_env`` as part of the PATH. Basing variables on ``ansible_env`` is risky. Ansible populates ``ansible_env`` values by gathering facts, so the value of the variables depends on the remote_user or become_user Ansible used when gathering those facts. If you change remote_user/become_user the values in ``ansible_env`` may not be the ones you expect. - -.. warning:: - Environment variables are normally passed in clear text (shell plugin dependent) so they are not a recommended way of passing secrets to the module being executed. - -You can also specify the environment at the task level. - -.. code-block:: yaml+jinja - - --- - - name: Install ruby 2.3.1 - ansible.builtin.command: rbenv install {{ rbenv_ruby_version }} - args: - creates: '{{ rbenv_root }}/versions/{{ rbenv_ruby_version }}/bin/ruby' - vars: - rbenv_root: /usr/local/rbenv - rbenv_ruby_version: 2.3.1 - environment: - CONFIGURE_OPTS: '--disable-install-doc' - RBENV_ROOT: '{{ rbenv_root }}' - PATH: '{{ rbenv_root }}/bin:{{ rbenv_root }}/shims:{{ rbenv_plugins }}/ruby-build/bin:{{ ansible_env.PATH }}' - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst b/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst deleted file mode 100644 index d94fc1ef46c..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst +++ /dev/null @@ -1,279 +0,0 @@ -.. _playbooks_error_handling: - -*************************** -Error handling in playbooks -*************************** - -When Ansible receives a non-zero return code from a command or a failure from a module, by default it stops executing on that host and continues on other hosts. However, in some circumstances you may want different behavior. Sometimes a non-zero return code indicates success. Sometimes you want a failure on one host to stop execution on all hosts. Ansible provides tools and settings to handle these situations and help you get the behavior, output, and reporting you want. - -.. contents:: - :local: - -.. _ignoring_failed_commands: - -Ignoring failed commands -======================== - -By default Ansible stops executing tasks on a host when a task fails on that host. You can use ``ignore_errors`` to continue on in spite of the failure. - -.. code-block:: yaml - - - name: Do not count this as a failure - ansible.builtin.command: /bin/false - ignore_errors: true - -The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors. - -.. _ignore_unreachable: - -Ignoring unreachable host errors -================================ - -.. versionadded:: 2.7 - -You can ignore a task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level: - -.. code-block:: yaml - - - name: This executes, fails, and the failure is ignored - ansible.builtin.command: /bin/true - ignore_unreachable: true - - - name: This executes, fails, and ends the play for this host - ansible.builtin.command: /bin/true - -And at the playbook level: - -.. code-block:: yaml - - - hosts: all - ignore_unreachable: true - tasks: - - name: This executes, fails, and the failure is ignored - ansible.builtin.command: /bin/true - - - name: This executes, fails, and ends the play for this host - ansible.builtin.command: /bin/true - ignore_unreachable: false - -.. _resetting_unreachable: - -Resetting unreachable hosts -=========================== - -If Ansible cannot connect to a host, it marks that host as 'UNREACHABLE' and removes it from the list of active hosts for the run. You can use `meta: clear_host_errors` to reactivate all hosts, so subsequent tasks can try to reach them again. - - -.. _handlers_and_failure: - -Handlers and failure -==================== - -Ansible runs :ref:`handlers ` at the end of each play. If a task notifies a handler but -another task fails later in the play, by default the handler does *not* run on that host, -which may leave the host in an unexpected state. For example, a task could update -a configuration file and notify a handler to restart some service. If a -task later in the same play fails, the configuration file might be changed but -the service will not be restarted. - -You can change this behavior with the ``--force-handlers`` command-line option, -by including ``force_handlers: True`` in a play, or by adding ``force_handlers = True`` -to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on -all hosts, even hosts with failed tasks. (Note that certain errors could still prevent -the handler from running, such as a host becoming unreachable.) - -.. _controlling_what_defines_failure: - -Defining failure -================ - -Ansible lets you define what "failure" means in each task using the ``failed_when`` conditional. As with all conditionals in Ansible, lists of multiple ``failed_when`` conditions are joined with an implicit ``and``, meaning the task only fails when *all* conditions are met. If you want to trigger a failure when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. - -You may check for failure by searching for a word or phrase in the output of a command - -.. code-block:: yaml - - - name: Fail task when the command error output prints FAILED - ansible.builtin.command: /usr/bin/example-command -x -y -z - register: command_result - failed_when: "'FAILED' in command_result.stderr" - -or based on the return code - -.. code-block:: yaml - - - name: Fail task when both files are identical - ansible.builtin.raw: diff foo/file1 bar/file2 - register: diff_cmd - failed_when: diff_cmd.rc == 0 or diff_cmd.rc >= 2 - -You can also combine multiple conditions for failure. This task will fail if both conditions are true: - -.. code-block:: yaml - - - name: Check if a file exists in temp and fail task if it does - ansible.builtin.command: ls /tmp/this_should_not_be_here - register: result - failed_when: - - result.rc == 0 - - '"No such" not in result.stdout' - -If you want the task to fail when only one condition is satisfied, change the ``failed_when`` definition to - -.. code-block:: yaml - - failed_when: result.rc == 0 or "No such" not in result.stdout - -If you have too many conditions to fit neatly into one line, you can split it into a multi-line YAML value with ``>``. - -.. code-block:: yaml - - - name: example of many failed_when conditions with OR - ansible.builtin.shell: "./myBinary" - register: ret - failed_when: > - ("No such file or directory" in ret.stdout) or - (ret.stderr != '') or - (ret.rc == 10) - -.. _override_the_changed_result: - -Defining "changed" -================== - -Ansible lets you define when a particular task has "changed" a remote node using the ``changed_when`` conditional. This lets you determine, based on return codes or output, whether a change should be reported in Ansible statistics and whether a handler should be triggered or not. As with all conditionals in Ansible, lists of multiple ``changed_when`` conditions are joined with an implicit ``and``, meaning the task only reports a change when *all* conditions are met. If you want to report a change when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. For example: - -.. code-block:: yaml - - tasks: - - - name: Report 'changed' when the return code is not equal to 2 - ansible.builtin.shell: /usr/bin/billybass --mode="take me to the river" - register: bass_result - changed_when: "bass_result.rc != 2" - - - name: This will never report 'changed' status - ansible.builtin.shell: wall 'beep' - changed_when: False - -You can also combine multiple conditions to override "changed" result. - -.. code-block:: yaml - - - name: Combine multiple conditions to override 'changed' result - ansible.builtin.command: /bin/fake_command - register: result - ignore_errors: True - changed_when: - - '"ERROR" in result.stderr' - - result.rc == 2 - -.. note:: - - Just like ``when`` these two conditionals do not require templating delimiters (``{{ }}``) as they are implied. - -See :ref:`controlling_what_defines_failure` for more conditional syntax examples. - -Ensuring success for command and shell -====================================== - -The :ref:`command ` and :ref:`shell ` modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this: - -.. code-block:: yaml - - tasks: - - name: Run this command and ignore the result - ansible.builtin.shell: /usr/bin/somecommand || /bin/true - - -Aborting a play on all hosts -============================ - -Sometimes you want a failure on a single host, or failures on a certain percentage of hosts, to abort the entire play on all hosts. You can stop play execution after the first failure happens with ``any_errors_fatal``. For finer-grained control, you can use ``max_fail_percentage`` to abort the run after a given percentage of hosts has failed. - -Aborting on the first error: any_errors_fatal ---------------------------------------------- - -If you set ``any_errors_fatal`` and a task returns an error, Ansible finishes the fatal task on all hosts in the current batch, then stops executing the play on all hosts. Subsequent tasks and plays are not executed. You can recover from fatal errors by adding a :ref:`rescue section ` to the block. You can set ``any_errors_fatal`` at the play or block level. - -.. code-block:: yaml - - - hosts: somehosts - any_errors_fatal: true - roles: - - myrole - - - hosts: somehosts - tasks: - - block: - - include_tasks: mytasks.yml - any_errors_fatal: true - -You can use this feature when all tasks must be 100% successful to continue playbook execution. For example, if you run a service on machines in multiple data centers with load balancers to pass traffic from users to the service, you want all load balancers to be disabled before you stop the service for maintenance. To ensure that any failure in the task that disables the load balancers will stop all other tasks: - -.. code-block:: yaml - - --- - - hosts: load_balancers_dc_a - any_errors_fatal: true - - tasks: - - name: Shut down datacenter 'A' - ansible.builtin.command: /usr/bin/disable-dc - - - hosts: frontends_dc_a - - tasks: - - name: Stop service - ansible.builtin.command: /usr/bin/stop-software - - - name: Update software - ansible.builtin.command: /usr/bin/upgrade-software - - - hosts: load_balancers_dc_a - - tasks: - - name: Start datacenter 'A' - ansible.builtin.command: /usr/bin/enable-dc - -In this example Ansible starts the software upgrade on the front ends only if all of the load balancers are successfully disabled. - -.. _maximum_failure_percentage: - -Setting a maximum failure percentage ------------------------------------- - -By default, Ansible continues to execute tasks as long as there are hosts that have not yet failed. In some situations, such as when executing a rolling update, you may want to abort the play when a certain threshold of failures has been reached. To achieve this, you can set a maximum failure percentage on a play: - -.. code-block:: yaml - - --- - - hosts: webservers - max_fail_percentage: 30 - serial: 10 - -The ``max_fail_percentage`` setting applies to each batch when you use it with :ref:`serial `. In the example above, if more than 3 of the 10 servers in the first (or any) batch of servers failed, the rest of the play would be aborted. - -.. note:: - - The percentage set must be exceeded, not equaled. For example, if serial were set to 4 and you wanted the task to abort the play when 2 of the systems failed, set the max_fail_percentage at 49 rather than 50. - -Controlling errors in blocks -============================ - -You can also use blocks to define responses to task errors. This approach is similar to exception handling in many programming languages. See :ref:`block_error_handling` for details and examples. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_execution.rst b/docs/docsite/rst/playbook_guide/playbooks_execution.rst deleted file mode 100644 index b1377cd52ae..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_execution.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. _executing_playbooks: - -Executing playbooks -=================== - -Ready to run your Ansible playbook? - -Running complex playbooks requires some trial and error so learn about some of the abilities that Ansible gives you to ensure successful execution. -You can validate your tasks with "dry run" playbooks, use the start-at-task and step mode options to efficiently troubleshoot playbooks. -You can also use Ansible debugger to correct tasks during execution. -Ansible also offers flexibility with asynchronous playbook execution and tags that let you run specific parts of your playbook. - -.. toctree:: - :maxdepth: 2 - - playbooks_checkmode - playbooks_privilege_escalation - playbooks_tags - playbooks_startnstep - playbooks_debugger - playbooks_async - playbooks_strategies \ No newline at end of file diff --git a/docs/docsite/rst/playbook_guide/playbooks_filters.rst b/docs/docsite/rst/playbook_guide/playbooks_filters.rst deleted file mode 100644 index 52fb861ac12..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_filters.rst +++ /dev/null @@ -1,2203 +0,0 @@ -.. _playbooks_filters: - -******************************** -Using filters to manipulate data -******************************** - -Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters ` in the official Jinja2 template documentation. You can also use :ref:`Python methods ` to transform data. You can :ref:`create custom Ansible filters as plugins `, though we generally welcome new filters into the ansible-core repo so everyone can use them. - -Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally. - -.. contents:: - :local: - -Handling undefined variables -============================ - -Filters can help you manage missing or undefined variables by providing defaults or making some variables optional. If you configure Ansible to ignore most undefined variables, you can mark some variables as requiring values with the ``mandatory`` filter. - -.. _defaulting_undefined_variables: - -Providing default values ------------------------- - -You can provide default values for variables directly in your templates using the Jinja2 'default' filter. This is often a better approach than failing if a variable is not defined: - -.. code-block:: yaml+jinja - - {{ some_variable | default(5) }} - -In the above example, if the variable 'some_variable' is not defined, Ansible uses the default value 5, rather than raising an "undefined variable" error and failing. If you are working within a role, you can also add a ``defaults/main.yml`` to define the default values for variables in your role. - -Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use -a default with a value in a nested data structure (in other words, :code:`{{ foo.bar.baz | default('DEFAULT') }}`) when you do not know if the intermediate values are defined. - -If you want to use the default value when variables evaluate to false or an empty string you have to set the second parameter to ``true``: - -.. code-block:: yaml+jinja - - {{ lookup('env', 'MY_USER') | default('admin', true) }} - -.. _omitting_undefined_variables: - -Making variables optional -------------------------- - -By default Ansible requires values for all variables in a templated expression. However, you can make specific variables optional. For example, you might want to use a system default for some items and control the value for others. To make a variable optional, set the default value to the special variable ``omit``: - -.. code-block:: yaml+jinja - - - name: Touch files with an optional mode - ansible.builtin.file: - dest: "{{ item.path }}" - state: touch - mode: "{{ item.mode | default(omit) }}" - loop: - - path: /tmp/foo - - path: /tmp/bar - - path: /tmp/baz - mode: "0444" - -In this example, the default mode for the files ``/tmp/foo`` and ``/tmp/bar`` is determined by the umask of the system. Ansible does not send a value for ``mode``. Only the third file, ``/tmp/baz``, receives the `mode=0444` option. - -.. note:: If you are "chaining" additional filters after the ``default(omit)`` filter, you should instead do something like this: - ``"{{ foo | default(None) | some_filter or omit }}"``. In this example, the default ``None`` (Python null) value will cause the later filters to fail, which will trigger the ``or omit`` portion of the logic. Using ``omit`` in this manner is very specific to the later filters you are chaining though, so be prepared for some trial and error if you do this. - -.. _forcing_variables_to_be_defined: - -Defining mandatory values -------------------------- - -If you configure Ansible to ignore undefined variables, you may want to define some values as mandatory. By default, Ansible fails if a variable in your playbook or command is undefined. You can configure Ansible to allow undefined variables by setting :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` to ``false``. In that case, you may want to require some variables to be defined. You can do this with: - -.. code-block:: yaml+jinja - - {{ variable | mandatory }} - -The variable value will be used as is, but the template evaluation will raise an error if it is undefined. - -A convenient way of requiring a variable to be overridden is to give it an undefined value using the ``undef`` keyword. This can be useful in a role's defaults. - -.. code-block:: yaml+jinja - - galaxy_url: "https://galaxy.ansible.com" - galaxy_api_key: "{{ undef(hint='You must specify your Galaxy API key') }}" - -Defining different values for true/false/null (ternary) -======================================================= - -You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9): - -.. code-block:: yaml+jinja - - {{ (status == 'needs_restart') | ternary('restart', 'continue') }} - -In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8): - -.. code-block:: yaml+jinja - - {{ enabled | ternary('no shutdown', 'shutdown', omit) }} - -Managing data types -=================== - -You might need to know, change, or set the data type on a variable. For example, a registered variable might contain a dictionary when your next task needs a list, or a user :ref:`prompt ` might return a string when your playbook needs a boolean value. Use the ``type_debug``, ``dict2items``, and ``items2dict`` filters to manage data types. You can also use the data type itself to cast a value as a specific data type. - -Discovering the data type -------------------------- - -.. versionadded:: 2.3 - -If you are unsure of the underlying Python type of a variable, you can use the ``type_debug`` filter to display it. This is useful in debugging when you need a particular type of variable: - -.. code-block:: yaml+jinja - - {{ myvar | type_debug }} - -You should note that, while this may seem like a useful filter for checking that you have the right type of data in a variable, you should often prefer :ref:`type tests `, which will allow you to test for specific data types. - -.. _dict_filter: - -Transforming dictionaries into lists ------------------------------------- - -.. versionadded:: 2.6 - - -Use the ``dict2items`` filter to transform a dictionary into a list of items suitable for :ref:`looping `: - -.. code-block:: yaml+jinja - - {{ dict | dict2items }} - -Dictionary data (before applying the ``dict2items`` filter): - -.. code-block:: yaml - - tags: - Application: payment - Environment: dev - -List data (after applying the ``dict2items`` filter): - -.. code-block:: yaml - - - key: Application - value: payment - - key: Environment - value: dev - -.. versionadded:: 2.8 - -The ``dict2items`` filter is the reverse of the ``items2dict`` filter. - -If you want to configure the names of the keys, the ``dict2items`` filter accepts 2 keyword arguments. Pass the ``key_name`` and ``value_name`` arguments to configure the names of the keys in the list output: - -.. code-block:: yaml+jinja - - {{ files | dict2items(key_name='file', value_name='path') }} - -Dictionary data (before applying the ``dict2items`` filter): - -.. code-block:: yaml - - files: - users: /etc/passwd - groups: /etc/group - -List data (after applying the ``dict2items`` filter): - -.. code-block:: yaml - - - file: users - path: /etc/passwd - - file: groups - path: /etc/group - - -Transforming lists into dictionaries ------------------------------------- - -.. versionadded:: 2.7 - -Use the ``items2dict`` filter to transform a list into a dictionary, mapping the content into ``key: value`` pairs: - -.. code-block:: yaml+jinja - - {{ tags | items2dict }} - -List data (before applying the ``items2dict`` filter): - -.. code-block:: yaml - - tags: - - key: Application - value: payment - - key: Environment - value: dev - -Dictionary data (after applying the ``items2dict`` filter): - -.. code-block:: text - - Application: payment - Environment: dev - -The ``items2dict`` filter is the reverse of the ``dict2items`` filter. - -Not all lists use ``key`` to designate keys and ``value`` to designate values. For example: - -.. code-block:: yaml - - fruits: - - fruit: apple - color: red - - fruit: pear - color: yellow - - fruit: grapefruit - color: yellow - -In this example, you must pass the ``key_name`` and ``value_name`` arguments to configure the transformation. For example: - -.. code-block:: yaml+jinja - - {{ tags | items2dict(key_name='fruit', value_name='color') }} - -If you do not pass these arguments, or do not pass the correct values for your list, you will see ``KeyError: key`` or ``KeyError: my_typo``. - -Forcing the data type ---------------------- - -You can cast values as certain types. For example, if you expect the input "True" from a :ref:`vars_prompt ` and you want Ansible to recognize it as a boolean value instead of a string: - -.. code-block:: yaml - - - ansible.builtin.debug: - msg: test - when: some_string_value | bool - -If you want to perform a mathematical comparison on a fact and you want Ansible to recognize it as an integer instead of a string: - -.. code-block:: yaml - - - shell: echo "only on Red Hat 6, derivatives, and later" - when: ansible_facts['os_family'] == "RedHat" and ansible_facts['lsb']['major_release'] | int >= 6 - - -.. versionadded:: 1.6 - -.. _filters_for_formatting_data: - -Formatting data: YAML and JSON -============================== - -You can switch a data structure in a template from or to JSON or YAML format, with options for formatting, indenting, and loading data. The basic filters are occasionally useful for debugging: - -.. code-block:: yaml+jinja - - {{ some_variable | to_json }} - {{ some_variable | to_yaml }} - -For human readable output, you can use: - -.. code-block:: yaml+jinja - - {{ some_variable | to_nice_json }} - {{ some_variable | to_nice_yaml }} - -You can change the indentation of either format: - -.. code-block:: yaml+jinja - - {{ some_variable | to_nice_json(indent=2) }} - {{ some_variable | to_nice_yaml(indent=8) }} - -The ``to_yaml`` and ``to_nice_yaml`` filters use the `PyYAML library`_ which has a default 80 symbol string length limit. That causes unexpected line break after 80th symbol (if there is a space after 80th symbol) -To avoid such behavior and generate long lines, use the ``width`` option. You must use a hardcoded number to define the width, instead of a construction like ``float("inf")``, because the filter does not support proxying Python functions. For example: - -.. code-block:: yaml+jinja - - {{ some_variable | to_yaml(indent=8, width=1337) }} - {{ some_variable | to_nice_yaml(indent=8, width=1337) }} - -The filter does support passing through other YAML parameters. For a full list, see the `PyYAML documentation`_ for ``dump()``. - -If you are reading in some already formatted data: - -.. code-block:: yaml+jinja - - {{ some_variable | from_json }} - {{ some_variable | from_yaml }} - -for example: - -.. code-block:: yaml+jinja - - tasks: - - name: Register JSON output as a variable - ansible.builtin.shell: cat /some/path/to/file.json - register: result - - - name: Set a variable - ansible.builtin.set_fact: - myvar: "{{ result.stdout | from_json }}" - - -Filter `to_json` and Unicode support ------------------------------------- - -By default `to_json` and `to_nice_json` will convert data received to ASCII, so: - -.. code-block:: yaml+jinja - - {{ 'München'| to_json }} - -will return: - -.. code-block:: text - - 'M\u00fcnchen' - -To keep Unicode characters, pass the parameter `ensure_ascii=False` to the filter: - -.. code-block:: yaml+jinja - - {{ 'München'| to_json(ensure_ascii=False) }} - - 'München' - -.. versionadded:: 2.7 - -To parse multi-document YAML strings, the ``from_yaml_all`` filter is provided. -The ``from_yaml_all`` filter will return a generator of parsed YAML documents. - -for example: - -.. code-block:: yaml+jinja - - tasks: - - name: Register a file content as a variable - ansible.builtin.shell: cat /some/path/to/multidoc-file.yaml - register: result - - - name: Print the transformed variable - ansible.builtin.debug: - msg: '{{ item }}' - loop: '{{ result.stdout | from_yaml_all | list }}' - -Combining and selecting data -============================ - -You can combine data from multiple sources and types, and select values from large data structures, giving you precise control over complex data. - -.. _zip_filter_example: - -Combining items from multiple lists: zip and zip_longest --------------------------------------------------------- - -.. versionadded:: 2.3 - -To get a list combining the elements of other lists use ``zip``: - -.. code-block:: yaml+jinja - - - name: Give me list combo of two lists - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5,6] | zip(['a','b','c','d','e','f']) | list }}" - - # => [[1, "a"], [2, "b"], [3, "c"], [4, "d"], [5, "e"], [6, "f"]] - - - name: Give me shortest combo of two lists - ansible.builtin.debug: - msg: "{{ [1,2,3] | zip(['a','b','c','d','e','f']) | list }}" - - # => [[1, "a"], [2, "b"], [3, "c"]] - -To always exhaust all lists use ``zip_longest``: - -.. code-block:: yaml+jinja - - - name: Give me longest combo of three lists , fill with X - ansible.builtin.debug: - msg: "{{ [1,2,3] | zip_longest(['a','b','c','d','e','f'], [21, 22, 23], fillvalue='X') | list }}" - - # => [[1, "a", 21], [2, "b", 22], [3, "c", 23], ["X", "d", "X"], ["X", "e", "X"], ["X", "f", "X"]] - -Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``: - -.. code-block:: yaml+jinja - - {{ dict(keys_list | zip(values_list)) }} - -List data (before applying the ``zip`` filter): - -.. code-block:: yaml - - keys_list: - - one - - two - values_list: - - apple - - orange - -Dictionary data (after applying the ``zip`` filter): - -.. code-block:: yaml - - one: apple - two: orange - -Combining objects and subelements ---------------------------------- - -.. versionadded:: 2.7 - -The ``subelements`` filter produces a product of an object and the subelement values of that object, similar to the ``subelements`` lookup. This lets you specify individual subelements to use in a template. For example, this expression: - -.. code-block:: yaml+jinja - - {{ users | subelements('groups', skip_missing=True) }} - -Data before applying the ``subelements`` filter: - -.. code-block:: yaml - - users: - - name: alice - authorized: - - /tmp/alice/onekey.pub - - /tmp/alice/twokey.pub - groups: - - wheel - - docker - - name: bob - authorized: - - /tmp/bob/id_rsa.pub - groups: - - docker - -Data after applying the ``subelements`` filter: - -.. code-block:: yaml - - - - - name: alice - groups: - - wheel - - docker - authorized: - - /tmp/alice/onekey.pub - - /tmp/alice/twokey.pub - - wheel - - - - name: alice - groups: - - wheel - - docker - authorized: - - /tmp/alice/onekey.pub - - /tmp/alice/twokey.pub - - docker - - - - name: bob - authorized: - - /tmp/bob/id_rsa.pub - groups: - - docker - - docker - -You can use the transformed data with ``loop`` to iterate over the same subelement for multiple objects: - -.. code-block:: yaml+jinja - - - name: Set authorized ssh key, extracting just that data from 'users' - ansible.posix.authorized_key: - user: "{{ item.0.name }}" - key: "{{ lookup('file', item.1) }}" - loop: "{{ users | subelements('authorized') }}" - -.. _combine_filter: - -Combining hashes/dictionaries ------------------------------ - -.. versionadded:: 2.0 - -The ``combine`` filter allows hashes to be merged. For example, the following would override keys in one hash: - -.. code-block:: yaml+jinja - - {{ {'a':1, 'b':2} | combine({'b':3}) }} - -The resulting hash would be: - -.. code-block:: text - - {'a':1, 'b':3} - -The filter can also take multiple arguments to merge: - -.. code-block:: yaml+jinja - - {{ a | combine(b, c, d) }} - {{ [a, b, c, d] | combine }} - -In this case, keys in ``d`` would override those in ``c``, which would override those in ``b``, and so on. - -The filter also accepts two optional parameters: ``recursive`` and ``list_merge``. - -recursive - Is a boolean, default to ``False``. - Should the ``combine`` recursively merge nested hashes. - Note: It does **not** depend on the value of the ``hash_behaviour`` setting in ``ansible.cfg``. - -list_merge - Is a string, its possible values are ``replace`` (default), ``keep``, ``append``, ``prepend``, ``append_rp`` or ``prepend_rp``. - It modifies the behaviour of ``combine`` when the hashes to merge contain arrays/lists. - -.. code-block:: yaml - - default: - a: - x: default - y: default - b: default - c: default - patch: - a: - y: patch - z: patch - b: patch - -If ``recursive=False`` (the default), nested hash aren't merged: - -.. code-block:: yaml+jinja - - {{ default | combine(patch) }} - -This would result in: - -.. code-block:: yaml - - a: - y: patch - z: patch - b: patch - c: default - -If ``recursive=True``, recurse into nested hash and merge their keys: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, recursive=True) }} - -This would result in: - -.. code-block:: yaml - - a: - x: default - y: patch - z: patch - b: patch - c: default - -If ``list_merge='replace'`` (the default), arrays from the right hash will "replace" the ones in the left hash: - -.. code-block:: yaml - - default: - a: - - default - patch: - a: - - patch - -.. code-block:: yaml+jinja - - {{ default | combine(patch) }} - -This would result in: - -.. code-block:: yaml - - a: - - patch - -If ``list_merge='keep'``, arrays from the left hash will be kept: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='keep') }} - -This would result in: - -.. code-block:: yaml - - a: - - default - -If ``list_merge='append'``, arrays from the right hash will be appended to the ones in the left hash: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='append') }} - -This would result in: - -.. code-block:: yaml - - a: - - default - - patch - -If ``list_merge='prepend'``, arrays from the right hash will be prepended to the ones in the left hash: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='prepend') }} - -This would result in: - -.. code-block:: yaml - - a: - - patch - - default - -If ``list_merge='append_rp'``, arrays from the right hash will be appended to the ones in the left hash. Elements of arrays in the left hash that are also in the corresponding array of the right hash will be removed ("rp" stands for "remove present"). Duplicate elements that aren't in both hashes are kept: - -.. code-block:: yaml - - default: - a: - - 1 - - 1 - - 2 - - 3 - patch: - a: - - 3 - - 4 - - 5 - - 5 - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='append_rp') }} - -This would result in: - -.. code-block:: yaml - - a: - - 1 - - 1 - - 2 - - 3 - - 4 - - 5 - - 5 - -If ``list_merge='prepend_rp'``, the behavior is similar to the one for ``append_rp``, but elements of arrays in the right hash are prepended: - -.. code-block:: yaml+jinja - - {{ default | combine(patch, list_merge='prepend_rp') }} - -This would result in: - -.. code-block:: yaml - - a: - - 3 - - 4 - - 5 - - 5 - - 1 - - 1 - - 2 - -``recursive`` and ``list_merge`` can be used together: - -.. code-block:: yaml - - default: - a: - a': - x: default_value - y: default_value - list: - - default_value - b: - - 1 - - 1 - - 2 - - 3 - patch: - a: - a': - y: patch_value - z: patch_value - list: - - patch_value - b: - - 3 - - 4 - - 4 - - key: value - -.. code-block:: yaml+jinja - - {{ default | combine(patch, recursive=True, list_merge='append_rp') }} - -This would result in: - -.. code-block:: yaml - - a: - a': - x: default_value - y: patch_value - z: patch_value - list: - - default_value - - patch_value - b: - - 1 - - 1 - - 2 - - 3 - - 4 - - 4 - - key: value - - -.. _extract_filter: - -Selecting values from arrays or hashtables -------------------------------------------- - -.. versionadded:: 2.1 - -The `extract` filter is used to map from a list of indices to a list of values from a container (hash or array): - -.. code-block:: yaml+jinja - - {{ [0,2] | map('extract', ['x','y','z']) | list }} - {{ ['x','y'] | map('extract', {'x': 42, 'y': 31}) | list }} - -The results of the above expressions would be: - -.. code-block:: none - - ['x', 'z'] - [42, 31] - -The filter can take another argument: - -.. code-block:: yaml+jinja - - {{ groups['x'] | map('extract', hostvars, 'ec2_ip_address') | list }} - -This takes the list of hosts in group 'x', looks them up in `hostvars`, and then looks up the `ec2_ip_address` of the result. The final result is a list of IP addresses for the hosts in group 'x'. - -The third argument to the filter can also be a list, for a recursive lookup inside the container: - -.. code-block:: yaml+jinja - - {{ ['a'] | map('extract', b, ['x','y']) | list }} - -This would return a list containing the value of `b['a']['x']['y']`. - -Combining lists ---------------- - -This set of filters returns a list of combined lists. - - -permutations -^^^^^^^^^^^^ -To get permutations of a list: - -.. code-block:: yaml+jinja - - - name: Give me largest permutations (order matters) - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5] | ansible.builtin.permutations | list }}" - - - name: Give me permutations of sets of three - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5] | ansible.builtin.permutations(3) | list }}" - -combinations -^^^^^^^^^^^^ -Combinations always require a set size: - -.. code-block:: yaml+jinja - - - name: Give me combinations for sets of two - ansible.builtin.debug: - msg: "{{ [1,2,3,4,5] | ansible.builtin.combinations(2) | list }}" - -Also see the :ref:`zip_filter` - -products -^^^^^^^^ -The product filter returns the `cartesian product `_ of the input iterables. This is roughly equivalent to nested for-loops in a generator expression. - -For example: - -.. code-block:: yaml+jinja - - - name: Generate multiple hostnames - ansible.builtin.debug: - msg: "{{ ['foo', 'bar'] | product(['com']) | map('join', '.') | join(',') }}" - -This would result in: - -.. code-block:: json - - { "msg": "foo.com,bar.com" } - -.. json_query_filter: - -Selecting JSON data: JSON queries ---------------------------------- - -To select a single element or a data subset from a complex data structure in JSON format (for example, Ansible facts), use the ``json_query`` filter. The ``json_query`` filter lets you query a complex JSON structure and iterate over it using a loop structure. - -.. note:: - - This filter has migrated to the `community.general `_ collection. Follow the installation instructions to install that collection. - - -.. note:: You must manually install the **jmespath** dependency on the Ansible controller before using this filter. This filter is built upon **jmespath**, and you can use the same syntax. For examples, see `jmespath examples `_. - -Consider this data structure: - -.. code-block:: json - - { - "domain_definition": { - "domain": { - "cluster": [ - { - "name": "cluster1" - }, - { - "name": "cluster2" - } - ], - "server": [ - { - "name": "server11", - "cluster": "cluster1", - "port": "8080" - }, - { - "name": "server12", - "cluster": "cluster1", - "port": "8090" - }, - { - "name": "server21", - "cluster": "cluster2", - "port": "9080" - }, - { - "name": "server22", - "cluster": "cluster2", - "port": "9090" - } - ], - "library": [ - { - "name": "lib1", - "target": "cluster1" - }, - { - "name": "lib2", - "target": "cluster2" - } - ] - } - } - } - -To extract all clusters from this structure, you can use the following query: - -.. code-block:: yaml+jinja - - - name: Display all cluster names - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query('domain.cluster[*].name') }}" - -To extract all server names: - -.. code-block:: yaml+jinja - - - name: Display all server names - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query('domain.server[*].name') }}" - -To extract ports from cluster1: - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query(server_name_cluster1_query) }}" - vars: - server_name_cluster1_query: "domain.server[?cluster=='cluster1'].port" - -.. note:: You can use a variable to make the query more readable. - -To print out the ports from cluster1 in a comma separated string: - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 as a string - ansible.builtin.debug: - msg: "{{ domain_definition | community.general.json_query('domain.server[?cluster==`cluster1`].port') | join(', ') }}" - -.. note:: In the example above, quoting literals using backticks avoids escaping quotes and maintains readability. - -You can use YAML `single quote escaping `_: - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query('domain.server[?cluster==''cluster1''].port') }}" - -.. note:: Escaping single quotes within single quotes in YAML is done by doubling the single quote. - -To get a hash map with all ports and names of a cluster: - -.. code-block:: yaml+jinja - - - name: Display all server ports and names from cluster1 - ansible.builtin.debug: - var: item - loop: "{{ domain_definition | community.general.json_query(server_name_cluster1_query) }}" - vars: - server_name_cluster1_query: "domain.server[?cluster=='cluster2'].{name: name, port: port}" - -To extract ports from all clusters with name starting with 'server1': - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - msg: "{{ domain_definition | to_json | from_json | community.general.json_query(server_name_query) }}" - vars: - server_name_query: "domain.server[?starts_with(name,'server1')].port" - -To extract ports from all clusters with name containing 'server1': - -.. code-block:: yaml+jinja - - - name: Display all ports from cluster1 - ansible.builtin.debug: - msg: "{{ domain_definition | to_json | from_json | community.general.json_query(server_name_query) }}" - vars: - server_name_query: "domain.server[?contains(name,'server1')].port" - -.. note:: while using ``starts_with`` and ``contains``, you have to use `` to_json | from_json `` filter for correct parsing of data structure. - - -Randomizing data -================ - -When you need a randomly generated value, use one of these filters. - - -.. _random_mac_filter: - -Random MAC addresses --------------------- - -.. versionadded:: 2.6 - -This filter can be used to generate a random MAC address from a string prefix. - -.. note:: - - This filter has migrated to the `community.general `_ collection. Follow the installation instructions to install that collection. - -To get a random MAC address from a string prefix starting with '52:54:00': - -.. code-block:: yaml+jinja - - "{{ '52:54:00' | community.general.random_mac }}" - # => '52:54:00:ef:1c:03' - -Note that if anything is wrong with the prefix string, the filter will issue an error. - - .. versionadded:: 2.9 - -As of Ansible version 2.9, you can also initialize the random number generator from a seed to create random-but-idempotent MAC addresses: - -.. code-block:: yaml+jinja - - "{{ '52:54:00' | community.general.random_mac(seed=inventory_hostname) }}" - - -.. _random_filter_example: - -Random items or numbers ------------------------ - -The ``random`` filter in Ansible is an extension of the default Jinja2 random filter, and can be used to return a random item from a sequence of items or to generate a random number based on a range. - -To get a random item from a list: - -.. code-block:: yaml+jinja - - "{{ ['a','b','c'] | random }}" - # => 'c' - -To get a random number between 0 (inclusive) and a specified integer (exclusive): - -.. code-block:: yaml+jinja - - "{{ 60 | random }} * * * * root /script/from/cron" - # => '21 * * * * root /script/from/cron' - -To get a random number from 0 to 100 but in steps of 10: - -.. code-block:: yaml+jinja - - {{ 101 | random(step=10) }} - # => 70 - -To get a random number from 1 to 100 but in steps of 10: - -.. code-block:: yaml+jinja - - {{ 101 | random(1, 10) }} - # => 31 - {{ 101 | random(start=1, step=10) }} - # => 51 - -You can initialize the random number generator from a seed to create random-but-idempotent numbers: - -.. code-block:: yaml+jinja - - "{{ 60 | random(seed=inventory_hostname) }} * * * * root /script/from/cron" - -Shuffling a list ----------------- - -The ``shuffle`` filter randomizes an existing list, giving a different order every invocation. - -To get a random list from an existing list: - -.. code-block:: yaml+jinja - - {{ ['a','b','c'] | shuffle }} - # => ['c','a','b'] - {{ ['a','b','c'] | shuffle }} - # => ['b','c','a'] - -You can initialize the shuffle generator from a seed to generate a random-but-idempotent order: - -.. code-block:: yaml+jinja - - {{ ['a','b','c'] | shuffle(seed=inventory_hostname) }} - # => ['b','a','c'] - -The shuffle filter returns a list whenever possible. If you use it with a non 'listable' item, the filter does nothing. - - -.. _list_filters: - -Managing list variables -======================= - -You can search for the minimum or maximum value in a list, or flatten a multi-level list. - -To get the minimum value from list of numbers: - -.. code-block:: yaml+jinja - - {{ list1 | min }} - -.. versionadded:: 2.11 - -To get the minimum value in a list of objects: - -.. code-block:: yaml+jinja - - {{ [{'val': 1}, {'val': 2}] | min(attribute='val') }} - -To get the maximum value from a list of numbers: - -.. code-block:: yaml+jinja - - {{ [3, 4, 2] | max }} - -.. versionadded:: 2.11 - -To get the maximum value in a list of objects: - -.. code-block:: yaml+jinja - - {{ [{'val': 1}, {'val': 2}] | max(attribute='val') }} - -.. versionadded:: 2.5 - -Flatten a list (same thing the `flatten` lookup does): - -.. code-block:: yaml+jinja - - {{ [3, [4, 2] ] | flatten }} - # => [3, 4, 2] - -Flatten only the first level of a list (akin to the `items` lookup): - -.. code-block:: yaml+jinja - - {{ [3, [4, [2]] ] | flatten(levels=1) }} - # => [3, 4, [2]] - - -.. versionadded:: 2.11 - -Preserve nulls in a list, by default flatten removes them. : - -.. code-block:: yaml+jinja - - {{ [3, None, [4, [2]] ] | flatten(levels=1, skip_nulls=False) }} - # => [3, None, 4, [2]] - - -.. _set_theory_filters: - -Selecting from sets or lists (set theory) -========================================= - -You can select or combine items from sets or lists. - -.. versionadded:: 1.4 - -To get a unique set from a list: - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - {{ list1 | unique }} - # => [1, 2, 5, 3, 4, 10] - -To get a union of two lists: - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | union(list2) }} - # => [1, 2, 5, 1, 3, 4, 10, 11, 99] - -To get the intersection of 2 lists (unique list of all items in both): - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | intersect(list2) }} - # => [1, 2, 5, 3, 4] - -To get the difference of 2 lists (items in 1 that don't exist in 2): - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | difference(list2) }} - # => [10] - -To get the symmetric difference of 2 lists (items exclusive to each list): - -.. code-block:: yaml+jinja - - # list1: [1, 2, 5, 1, 3, 4, 10] - # list2: [1, 2, 3, 4, 5, 11, 99] - {{ list1 | symmetric_difference(list2) }} - # => [10, 11, 99] - -.. _math_stuff: - -Calculating numbers (math) -========================== - -.. versionadded:: 1.9 - -You can calculate logs, powers, and roots of numbers with Ansible filters. Jinja2 provides other mathematical functions like abs() and round(). - -Get the logarithm (default is e): - -.. code-block:: yaml+jinja - - {{ 8 | log }} - # => 2.0794415416798357 - -Get the base 10 logarithm: - -.. code-block:: yaml+jinja - - {{ 8 | log(10) }} - # => 0.9030899869919435 - -Give me the power of 2! (or 5): - -.. code-block:: yaml+jinja - - {{ 8 | pow(5) }} - # => 32768.0 - -Square root, or the 5th: - -.. code-block:: yaml+jinja - - {{ 8 | root }} - # => 2.8284271247461903 - - {{ 8 | root(5) }} - # => 1.5157165665103982 - - -Managing network interactions -============================= - -These filters help you with common network tasks. - -.. note:: - - These filters have migrated to the `ansible.netcommon `_ collection. Follow the installation instructions to install that collection. - -.. _ipaddr_filter: - -IP address filters ------------------- - -.. versionadded:: 1.9 - -To test if a string is a valid IP address: - -.. code-block:: yaml+jinja - - {{ myvar | ansible.netcommon.ipaddr }} - -You can also require a specific IP protocol version: - -.. code-block:: yaml+jinja - - {{ myvar | ansible.netcommon.ipv4 }} - {{ myvar | ansible.netcommon.ipv6 }} - -IP address filter can also be used to extract specific information from an IP -address. For example, to get the IP address itself from a CIDR, you can use: - -.. code-block:: yaml+jinja - - {{ '192.0.2.1/24' | ansible.netcommon.ipaddr('address') }} - # => 192.0.2.1 - -More information about ``ipaddr`` filter and complete usage guide can be found -in :ref:`playbooks_filters_ipaddr`. - -.. _network_filters: - -Network CLI filters -------------------- - -.. versionadded:: 2.4 - -To convert the output of a network device CLI command into structured JSON -output, use the ``parse_cli`` filter: - -.. code-block:: yaml+jinja - - {{ output | ansible.netcommon.parse_cli('path/to/spec') }} - -The ``parse_cli`` filter will load the spec file and pass the command output -through it, returning JSON output. The YAML spec file defines how to parse the CLI output. - -The spec file should be valid formatted YAML. It defines how to parse the CLI -output and return JSON data. Below is an example of a valid spec file that -will parse the output from the ``show vlan`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - enabled: "{{ item.state != 'act/lshut' }}" - state: "{{ item.state }}" - - keys: - vlans: - value: "{{ vlan }}" - items: "^(?P\\d+)\\s+(?P\\w+)\\s+(?Pactive|act/lshut|suspended)" - state_static: - value: present - - -The spec file above will return a JSON data structure that is a list of hashes -with the parsed VLAN information. - -The same command could be parsed into a hash by using the key and values -directives. Here is an example of how to parse the output into a hash -value using the same ``show vlan`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - key: "{{ item.vlan_id }}" - values: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - enabled: "{{ item.state != 'act/lshut' }}" - state: "{{ item.state }}" - - keys: - vlans: - value: "{{ vlan }}" - items: "^(?P\\d+)\\s+(?P\\w+)\\s+(?Pactive|act/lshut|suspended)" - state_static: - value: present - -Another common use case for parsing CLI commands is to break a large command -into blocks that can be parsed. This can be done using the ``start_block`` and -``end_block`` directives to break the command into blocks that can be parsed. - -.. code-block:: yaml - - --- - vars: - interface: - name: "{{ item[0].match[0] }}" - state: "{{ item[1].state }}" - mode: "{{ item[2].match[0] }}" - - keys: - interfaces: - value: "{{ interface }}" - start_block: "^Ethernet.*$" - end_block: "^$" - items: - - "^(?PEthernet\\d\\/\\d*)" - - "admin state is (?P.+)," - - "Port mode is (.+)" - - -The example above will parse the output of ``show interface`` into a list of -hashes. - -The network filters also support parsing the output of a CLI command using the -TextFSM library. To parse the CLI output with TextFSM use the following -filter: - -.. code-block:: yaml+jinja - - {{ output.stdout[0] | ansible.netcommon.parse_cli_textfsm('path/to/fsm') }} - -Use of the TextFSM filter requires the TextFSM library to be installed. - -Network XML filters -------------------- - -.. versionadded:: 2.5 - -To convert the XML output of a network device command into structured JSON -output, use the ``parse_xml`` filter: - -.. code-block:: yaml+jinja - - {{ output | ansible.netcommon.parse_xml('path/to/spec') }} - -The ``parse_xml`` filter will load the spec file and pass the command output -through formatted as JSON. - -The spec file should be valid formatted YAML. It defines how to parse the XML -output and return JSON data. - -Below is an example of a valid spec file that -will parse the output from the ``show vlan | display xml`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - desc: "{{ item.desc }}" - enabled: "{{ item.state.get('inactive') != 'inactive' }}" - state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}" - - keys: - vlans: - value: "{{ vlan }}" - top: configuration/vlans/vlan - items: - vlan_id: vlan-id - name: name - desc: description - state: ".[@inactive='inactive']" - - -The spec file above will return a JSON data structure that is a list of hashes -with the parsed VLAN information. - -The same command could be parsed into a hash by using the key and values -directives. Here is an example of how to parse the output into a hash -value using the same ``show vlan | display xml`` command. - -.. code-block:: yaml - - --- - vars: - vlan: - key: "{{ item.vlan_id }}" - values: - vlan_id: "{{ item.vlan_id }}" - name: "{{ item.name }}" - desc: "{{ item.desc }}" - enabled: "{{ item.state.get('inactive') != 'inactive' }}" - state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}" - - keys: - vlans: - value: "{{ vlan }}" - top: configuration/vlans/vlan - items: - vlan_id: vlan-id - name: name - desc: description - state: ".[@inactive='inactive']" - - -The value of ``top`` is the XPath relative to the XML root node. -In the example XML output given below, the value of ``top`` is ``configuration/vlans/vlan``, -which is an XPath expression relative to the root node (). -``configuration`` in the value of ``top`` is the outer most container node, and ``vlan`` -is the inner-most container node. - -``items`` is a dictionary of key-value pairs that map user-defined names to XPath expressions -that select elements. The Xpath expression is relative to the value of the XPath value contained in ``top``. -For example, the ``vlan_id`` in the spec file is a user defined name and its value ``vlan-id`` is the -relative to the value of XPath in ``top`` - -Attributes of XML tags can be extracted using XPath expressions. The value of ``state`` in the spec -is an XPath expression used to get the attributes of the ``vlan`` tag in output XML.: - -.. code-block:: none - - - - - - vlan-1 - 200 - This is vlan-1 - - - - - -.. note:: - For more information on supported XPath expressions, see `XPath Support `_. - -Network VLAN filters --------------------- - -.. versionadded:: 2.8 - -Use the ``vlan_parser`` filter to transform an unsorted list of VLAN integers into a -sorted string list of integers according to IOS-like VLAN list rules. This list has the following properties: - -* Vlans are listed in ascending order. -* Three or more consecutive VLANs are listed with a dash. -* The first line of the list can be first_line_len characters long. -* Subsequent list lines can be other_line_len characters. - -To sort a VLAN list: - -.. code-block:: yaml+jinja - - {{ [3003, 3004, 3005, 100, 1688, 3002, 3999] | ansible.netcommon.vlan_parser }} - -This example renders the following sorted list: - -.. code-block:: text - - ['100,1688,3002-3005,3999'] - - -Another example Jinja template: - -.. code-block:: yaml+jinja - - {% set parsed_vlans = vlans | ansible.netcommon.vlan_parser %} - switchport trunk allowed vlan {{ parsed_vlans[0] }} - {% for i in range (1, parsed_vlans | count) %} - switchport trunk allowed vlan add {{ parsed_vlans[i] }} - {% endfor %} - -This allows for dynamic generation of VLAN lists on a Cisco IOS tagged interface. You can store an exhaustive raw list of the exact VLANs required for an interface and then compare that to the parsed IOS output that would actually be generated for the configuration. - - -.. _hash_filters: - -Hashing and encrypting strings and passwords -============================================== - -.. versionadded:: 1.9 - -To get the sha1 hash of a string: - -.. code-block:: yaml+jinja - - {{ 'test1' | hash('sha1') }} - # => "b444ac06613fc8d63795be9ad0beaf55011936ac" - -To get the md5 hash of a string: - -.. code-block:: yaml+jinja - - {{ 'test1' | hash('md5') }} - # => "5a105e8b9d40e1329780d62ea2265d8a" - -Get a string checksum: - -.. code-block:: yaml+jinja - - {{ 'test2' | checksum }} - # => "109f4b3c50d7b0df729d299bc6f8e9ef9066971f" - -Other hashes (platform dependent): - -.. code-block:: yaml+jinja - - {{ 'test2' | hash('blowfish') }} - -To get a sha512 password hash (random salt): - -.. code-block:: yaml+jinja - - {{ 'passwordsaresecret' | password_hash('sha512') }} - # => "$6$UIv3676O/ilZzWEE$ktEfFF19NQPF2zyxqxGkAceTnbEgpEKuGBtk6MlU4v2ZorWaVQUMyurgmHCh2Fr4wpmQ/Y.AlXMJkRnIS4RfH/" - -To get a sha256 password hash with a specific salt: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha256', 'mysecretsalt') }} - # => "$5$mysecretsalt$ReKNyDYjkKNqRVwouShhsEqZ3VOE8eoVO4exihOfvG4" - -An idempotent method to generate unique hashes per system is to use a salt that is consistent between runs: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha512', 65534 | random(seed=inventory_hostname) | string) }} - # => "$6$43927$lQxPKz2M2X.NWO.gK.t7phLwOKQMcSq72XxDZQ0XzYV6DlL1OD72h417aj16OnHTGxNzhftXJQBcjbunLEepM0" - -Hash types available depend on the control system running Ansible, 'hash' depends on `hashlib `_, password_hash depends on `passlib `_. The `crypt `_ is used as a fallback if ``passlib`` is not installed. - -.. versionadded:: 2.7 - -Some hash types allow providing a rounds parameter: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha256', 'mysecretsalt', rounds=10000) }} - # => "$5$rounds=10000$mysecretsalt$Tkm80llAxD4YHll6AgNIztKn0vzAACsuuEfYeGP7tm7" - -The filter `password_hash` produces different results depending on whether you installed `passlib` or not. - -To ensure idempotency, specify `rounds` to be neither `crypt`'s nor `passlib`'s default, which is `5000` for `crypt` and a variable value (`535000` for sha256, `656000` for sha512) for `passlib`: - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('sha256', 'mysecretsalt', rounds=5001) }} - # => "$5$rounds=5001$mysecretsalt$wXcTWWXbfcR8er5IVf7NuquLvnUA6s8/qdtOhAZ.xN." - -Hash type 'blowfish' (BCrypt) provides the facility to specify the version of the BCrypt algorithm. - -.. code-block:: yaml+jinja - - {{ 'secretpassword' | password_hash('blowfish', '1234567890123456789012', ident='2b') }} - # => "$2b$12$123456789012345678901uuJ4qFdej6xnWjOQT.FStqfdoY8dYUPC" - -.. note:: - The parameter is only available for `blowfish (BCrypt) `_. - Other hash types will simply ignore this parameter. - Valid values for this parameter are: ['2', '2a', '2y', '2b'] - -.. versionadded:: 2.12 - -You can also use the Ansible :ref:`vault ` filter to encrypt data: - -.. code-block:: yaml+jinja - - # simply encrypt my key in a vault - vars: - myvaultedkey: "{{ keyrawdata|vault(passphrase) }}" - - - name: save templated vaulted data - template: src=dump_template_data.j2 dest=/some/key/vault.txt - vars: - mysalt: '{{ 2**256|random(seed=inventory_hostname) }}' - template_data: '{{ secretdata|vault(vaultsecret, salt=mysalt) }}' - - -And then decrypt it using the unvault filter: - -.. code-block:: yaml+jinja - - # simply decrypt my key from a vault - vars: - mykey: "{{ myvaultedkey|unvault(passphrase) }}" - - - name: save templated unvaulted data - template: src=dump_template_data.j2 dest=/some/key/clear.txt - vars: - template_data: '{{ secretdata|unvault(vaultsecret) }}' - - -.. _other_useful_filters: - -Manipulating text -================= - -Several filters work with text, including URLs, file names, and path names. - -.. _comment_filter: - -Adding comments to files ------------------------- - -The ``comment`` filter lets you create comments in a file from text in a template, with a variety of comment styles. By default Ansible uses ``#`` to start a comment line and adds a blank comment line above and below your comment text. For example the following: - -.. code-block:: yaml+jinja - - {{ "Plain style (default)" | comment }} - -produces this output: - -.. code-block:: text - - # - # Plain style (default) - # - -Ansible offers styles for comments in C (``//...``), C block -(``/*...*/``), Erlang (``%...``) and XML (````): - -.. code-block:: yaml+jinja - - {{ "C style" | comment('c') }} - {{ "C block style" | comment('cblock') }} - {{ "Erlang style" | comment('erlang') }} - {{ "XML style" | comment('xml') }} - -You can define a custom comment character. This filter: - -.. code-block:: yaml+jinja - - {{ "My Special Case" | comment(decoration="! ") }} - -produces: - -.. code-block:: text - - ! - ! My Special Case - ! - -You can fully customize the comment style: - -.. code-block:: yaml+jinja - - {{ "Custom style" | comment('plain', prefix='#######\n#', postfix='#\n#######\n ###\n #') }} - -That creates the following output: - -.. code-block:: text - - ####### - # - # Custom style - # - ####### - ### - # - -The filter can also be applied to any Ansible variable. For example to -make the output of the ``ansible_managed`` variable more readable, we can -change the definition in the ``ansible.cfg`` file to this: - -.. code-block:: ini - - [defaults] - - ansible_managed = This file is managed by Ansible.%n - template: {file} - date: %Y-%m-%d %H:%M:%S - user: {uid} - host: {host} - -and then use the variable with the `comment` filter: - -.. code-block:: yaml+jinja - - {{ ansible_managed | comment }} - -which produces this output: - -.. code-block:: sh - - # - # This file is managed by Ansible. - # - # template: /home/ansible/env/dev/ansible_managed/roles/role1/templates/test.j2 - # date: 2015-09-10 11:02:58 - # user: ansible - # host: myhost - # - -URLEncode Variables -------------------- - -The ``urlencode`` filter quotes data for use in a URL path or query using UTF-8: - -.. code-block:: yaml+jinja - - {{ 'Trollhättan' | urlencode }} - # => 'Trollh%C3%A4ttan' - -Splitting URLs --------------- - -.. versionadded:: 2.4 - -The ``urlsplit`` filter extracts the fragment, hostname, netloc, password, path, port, query, scheme, and username from an URL. With no arguments, returns a dictionary of all the fields: - -.. code-block:: yaml+jinja - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('hostname') }} - # => 'www.acme.com' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('netloc') }} - # => 'user:password@www.acme.com:9000' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('username') }} - # => 'user' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('password') }} - # => 'password' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('path') }} - # => '/dir/index.html' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('port') }} - # => '9000' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('scheme') }} - # => 'http' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('query') }} - # => 'query=term' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit('fragment') }} - # => 'fragment' - - {{ "http://user:password@www.acme.com:9000/dir/index.html?query=term#fragment" | urlsplit }} - # => - # { - # "fragment": "fragment", - # "hostname": "www.acme.com", - # "netloc": "user:password@www.acme.com:9000", - # "password": "password", - # "path": "/dir/index.html", - # "port": 9000, - # "query": "query=term", - # "scheme": "http", - # "username": "user" - # } - -Searching strings with regular expressions ------------------------------------------- - -To search in a string or extract parts of a string with a regular expression, use the ``regex_search`` filter: - -.. code-block:: yaml+jinja - - # Extracts the database name from a string - {{ 'server1/database42' | regex_search('database[0-9]+') }} - # => 'database42' - - # Example for a case insensitive search in multiline mode - {{ 'foo\nBAR' | regex_search('^bar', multiline=True, ignorecase=True) }} - # => 'BAR' - - # Extracts server and database id from a string - {{ 'server1/database42' | regex_search('server([0-9]+)/database([0-9]+)', '\\1', '\\2') }} - # => ['1', '42'] - - # Extracts dividend and divisor from a division - {{ '21/42' | regex_search('(?P[0-9]+)/(?P[0-9]+)', '\\g', '\\g') }} - # => ['21', '42'] - -The ``regex_search`` filter returns an empty string if it cannot find a match: - -.. code-block:: yaml+jinja - - {{ 'ansible' | regex_search('foobar') }} - # => '' - - -.. note:: - - - The ``regex_search`` filter returns ``None`` when used in a Jinja expression (for example in conjunction with operators, other filters, and so on). See the two examples below. - - .. code-block:: Jinja - - {{ 'ansible' | regex_search('foobar') == '' }} - # => False - {{ 'ansible' | regex_search('foobar') is none }} - # => True - - This is due to historic behavior and the custom re-implementation of some of the Jinja internals in Ansible. Enable the ``jinja2_native`` setting if you want the ``regex_search`` filter to always return ``None`` if it cannot find a match. See :ref:`jinja2_faqs` for details. - -To extract all occurrences of regex matches in a string, use the ``regex_findall`` filter: - -.. code-block:: yaml+jinja - - # Returns a list of all IPv4 addresses in the string - {{ 'Some DNS servers are 8.8.8.8 and 8.8.4.4' | regex_findall('\\b(?:[0-9]{1,3}\\.){3}[0-9]{1,3}\\b') }} - # => ['8.8.8.8', '8.8.4.4'] - - # Returns all lines that end with "ar" - {{ 'CAR\ntar\nfoo\nbar\n' | regex_findall('^.ar$', multiline=True, ignorecase=True) }} - # => ['CAR', 'tar', 'bar'] - - -To replace text in a string with regex, use the ``regex_replace`` filter: - -.. code-block:: yaml+jinja - - # Convert "ansible" to "able" - {{ 'ansible' | regex_replace('^a.*i(.*)$', 'a\\1') }} - # => 'able' - - # Convert "foobar" to "bar" - {{ 'foobar' | regex_replace('^f.*o(.*)$', '\\1') }} - # => 'bar' - - # Convert "localhost:80" to "localhost, 80" using named groups - {{ 'localhost:80' | regex_replace('^(?P.+):(?P\\d+)$', '\\g, \\g') }} - # => 'localhost, 80' - - # Convert "localhost:80" to "localhost" - {{ 'localhost:80' | regex_replace(':80') }} - # => 'localhost' - - # Comment all lines that end with "ar" - {{ 'CAR\ntar\nfoo\nbar\n' | regex_replace('^(.ar)$', '#\\1', multiline=True, ignorecase=True) }} - # => '#CAR\n#tar\nfoo\n#bar\n' - -.. note:: - If you want to match the whole string and you are using ``*`` make sure to always wraparound your regular expression with the start/end anchors. For example ``^(.*)$`` will always match only one result, while ``(.*)`` on some Python versions will match the whole string and an empty string at the end, which means it will make two replacements: - -.. code-block:: yaml+jinja - - # add "https://" prefix to each item in a list - GOOD: - {{ hosts | map('regex_replace', '^(.*)$', 'https://\\1') | list }} - {{ hosts | map('regex_replace', '(.+)', 'https://\\1') | list }} - {{ hosts | map('regex_replace', '^', 'https://') | list }} - - BAD: - {{ hosts | map('regex_replace', '(.*)', 'https://\\1') | list }} - - # append ':80' to each item in a list - GOOD: - {{ hosts | map('regex_replace', '^(.*)$', '\\1:80') | list }} - {{ hosts | map('regex_replace', '(.+)', '\\1:80') | list }} - {{ hosts | map('regex_replace', '$', ':80') | list }} - - BAD: - {{ hosts | map('regex_replace', '(.*)', '\\1:80') | list }} - -.. note:: - Prior to ansible 2.0, if ``regex_replace`` filter was used with variables inside YAML arguments (as opposed to simpler 'key=value' arguments), then you needed to escape backreferences (for example, ``\\1``) with 4 backslashes (``\\\\``) instead of 2 (``\\``). - -.. versionadded:: 2.0 - -To escape special characters within a standard Python regex, use the ``regex_escape`` filter (using the default ``re_type='python'`` option): - -.. code-block:: yaml+jinja - - # convert '^f.*o(.*)$' to '\^f\.\*o\(\.\*\)\$' - {{ '^f.*o(.*)$' | regex_escape() }} - -.. versionadded:: 2.8 - -To escape special characters within a POSIX basic regex, use the ``regex_escape`` filter with the ``re_type='posix_basic'`` option: - -.. code-block:: yaml+jinja - - # convert '^f.*o(.*)$' to '\^f\.\*o(\.\*)\$' - {{ '^f.*o(.*)$' | regex_escape('posix_basic') }} - - -Managing file names and path names ----------------------------------- - -To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt': - -.. code-block:: yaml+jinja - - {{ path | basename }} - -To get the last name of a windows style file path (new in version 2.0): - -.. code-block:: yaml+jinja - - {{ path | win_basename }} - -To separate the windows drive letter from the rest of a file path (new in version 2.0): - -.. code-block:: yaml+jinja - - {{ path | win_splitdrive }} - -To get only the windows drive letter: - -.. code-block:: yaml+jinja - - {{ path | win_splitdrive | first }} - -To get the rest of the path without the drive letter: - -.. code-block:: yaml+jinja - - {{ path | win_splitdrive | last }} - -To get the directory from a path: - -.. code-block:: yaml+jinja - - {{ path | dirname }} - -To get the directory from a windows path (new version 2.0): - -.. code-block:: yaml+jinja - - {{ path | win_dirname }} - -To expand a path containing a tilde (`~`) character (new in version 1.5): - -.. code-block:: yaml+jinja - - {{ path | expanduser }} - -To expand a path containing environment variables: - -.. code-block:: yaml+jinja - - {{ path | expandvars }} - -.. note:: `expandvars` expands local variables; using it on remote paths can lead to errors. - -.. versionadded:: 2.6 - -To get the real path of a link (new in version 1.8): - -.. code-block:: yaml+jinja - - {{ path | realpath }} - -To get the relative path of a link, from a start point (new in version 1.7): - -.. code-block:: yaml+jinja - - {{ path | relpath('/etc') }} - -To get the root and extension of a path or file name (new in version 2.0): - -.. code-block:: yaml+jinja - - # with path == 'nginx.conf' the return would be ('nginx', '.conf') - {{ path | splitext }} - -The ``splitext`` filter always returns a pair of strings. The individual components can be accessed by using the ``first`` and ``last`` filters: - -.. code-block:: yaml+jinja - - # with path == 'nginx.conf' the return would be 'nginx' - {{ path | splitext | first }} - - # with path == 'nginx.conf' the return would be '.conf' - {{ path | splitext | last }} - -To join one or more path components: - -.. code-block:: yaml+jinja - - {{ ('/etc', path, 'subdir', file) | path_join }} - -.. versionadded:: 2.10 - -Manipulating strings -==================== - -To add quotes for shell usage: - -.. code-block:: yaml+jinja - - - name: Run a shell command - ansible.builtin.shell: echo {{ string_value | quote }} - -To concatenate a list into a string: - -.. code-block:: yaml+jinja - - {{ list | join(" ") }} - -To split a string into a list: - -.. code-block:: yaml+jinja - - {{ csv_string | split(",") }} - -.. versionadded:: 2.11 - -To work with Base64 encoded strings: - -.. code-block:: yaml+jinja - - {{ encoded | b64decode }} - {{ decoded | string | b64encode }} - -As of version 2.6, you can define the type of encoding to use, the default is ``utf-8``: - -.. code-block:: yaml+jinja - - {{ encoded | b64decode(encoding='utf-16-le') }} - {{ decoded | string | b64encode(encoding='utf-16-le') }} - -.. note:: The ``string`` filter is only required for Python 2 and ensures that text to encode is a unicode string. Without that filter before b64encode the wrong value will be encoded. - -.. note:: The return value of b64decode is a string. If you decrypt a binary blob using b64decode and then try to use it (for example by using :ref:`copy ` to write it to a file) you will mostly likely find that your binary has been corrupted. If you need to take a base64 encoded binary and write it to disk, it is best to use the system ``base64`` command with the :ref:`shell module `, piping in the encoded data using the ``stdin`` parameter. For example: ``shell: cmd="base64 --decode > myfile.bin" stdin="{{ encoded }}"`` - -.. versionadded:: 2.6 - -Managing UUIDs -============== - -To create a namespaced UUIDv5: - -.. code-block:: yaml+jinja - - {{ string | to_uuid(namespace='11111111-2222-3333-4444-555555555555') }} - -.. versionadded:: 2.10 - -To create a namespaced UUIDv5 using the default Ansible namespace '361E6D51-FAEC-444A-9079-341386DA8E2E': - -.. code-block:: yaml+jinja - - {{ string | to_uuid }} - -.. versionadded:: 1.9 - -To make use of one attribute from each item in a list of complex variables, use the :func:`Jinja2 map filter `: - -.. code-block:: yaml+jinja - - # get a comma-separated list of the mount points (for example, "/,/mnt/stuff") on a host - {{ ansible_mounts | map(attribute='mount') | join(',') }} - -Handling dates and times -======================== - -To get a date object from a string use the `to_datetime` filter: - -.. code-block:: yaml+jinja - - # Get total amount of seconds between two dates. Default date format is %Y-%m-%d %H:%M:%S but you can pass your own format - {{ (("2016-08-14 20:00:12" | to_datetime) - ("2015-12-25" | to_datetime('%Y-%m-%d'))).total_seconds() }} - - # Get remaining seconds after delta has been calculated. NOTE: This does NOT convert years, days, hours, and so on to seconds. For that, use total_seconds() - {{ (("2016-08-14 20:00:12" | to_datetime) - ("2016-08-14 18:00:00" | to_datetime)).seconds }} - # This expression evaluates to "12" and not "132". Delta is 2 hours, 12 seconds - - # get amount of days between two dates. This returns only number of days and discards remaining hours, minutes, and seconds - {{ (("2016-08-14 20:00:12" | to_datetime) - ("2015-12-25" | to_datetime('%Y-%m-%d'))).days }} - -.. note:: For a full list of format codes for working with python date format strings, see the `python datetime documentation `_. - -.. versionadded:: 2.4 - -To format a date using a string (like with the shell date command), use the "strftime" filter: - -.. code-block:: yaml+jinja - - # Display year-month-day - {{ '%Y-%m-%d' | strftime }} - # => "2021-03-19" - - # Display hour:min:sec - {{ '%H:%M:%S' | strftime }} - # => "21:51:04" - - # Use ansible_date_time.epoch fact - {{ '%Y-%m-%d %H:%M:%S' | strftime(ansible_date_time.epoch) }} - # => "2021-03-19 21:54:09" - - # Use arbitrary epoch value - {{ '%Y-%m-%d' | strftime(0) }} # => 1970-01-01 - {{ '%Y-%m-%d' | strftime(1441357287) }} # => 2015-09-04 - -.. versionadded:: 2.13 - -strftime takes an optional utc argument, defaulting to False, meaning times are in the local timezone: - -.. code-block:: yaml+jinja - - {{ '%H:%M:%S' | strftime }} # time now in local timezone - {{ '%H:%M:%S' | strftime(utc=True) }} # time now in UTC - -.. note:: To get all string possibilities, check https://docs.python.org/3/library/time.html#time.strftime - -Getting Kubernetes resource names -================================= - -.. note:: - - These filters have migrated to the `kubernetes.core `_ collection. Follow the installation instructions to install that collection. - -Use the "k8s_config_resource_name" filter to obtain the name of a Kubernetes ConfigMap or Secret, -including its hash: - -.. code-block:: yaml+jinja - - {{ configmap_resource_definition | kubernetes.core.k8s_config_resource_name }} - -This can then be used to reference hashes in Pod specifications: - -.. code-block:: yaml+jinja - - my_secret: - kind: Secret - metadata: - name: my_secret_name - - deployment_resource: - kind: Deployment - spec: - template: - spec: - containers: - - envFrom: - - secretRef: - name: {{ my_secret | kubernetes.core.k8s_config_resource_name }} - -.. versionadded:: 2.8 - -.. _PyYAML library: https://pyyaml.org/ - -.. _PyYAML documentation: https://pyyaml.org/wiki/PyYAMLDocumentation - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - :ref:`playbooks_loops` - Looping in playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_handlers.rst b/docs/docsite/rst/playbook_guide/playbooks_handlers.rst deleted file mode 100644 index 69a865883e3..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_handlers.rst +++ /dev/null @@ -1,196 +0,0 @@ -.. _handlers: - -Handlers: running operations on change -====================================== - -Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified. - -.. contents:: - :local: - -Handler example ---------------- - -This playbook, ``verify-apache.yml``, contains a single play with a handler. - -.. code-block:: yaml - - --- - - name: Verify apache installation - hosts: webservers - vars: - http_port: 80 - max_clients: 200 - remote_user: root - tasks: - - name: Ensure apache is at the latest version - ansible.builtin.yum: - name: httpd - state: latest - - - name: Write the apache config file - ansible.builtin.template: - src: /srv/httpd.j2 - dest: /etc/httpd.conf - notify: - - Restart apache - - - name: Ensure apache is running - ansible.builtin.service: - name: httpd - state: started - - handlers: - - name: Restart apache - ansible.builtin.service: - name: httpd - state: restarted - -In this example playbook, the Apache server is restarted by the handler after all tasks complete in the play. - - -Notifying handlers ------------------- - -Tasks can instruct one or more handlers to execute using the ``notify`` keyword. The ``notify`` keyword can be applied to a task and accepts a list of handler names that are notified on a task change. Alternately, a string containing a single handler name can be supplied as well. The following example demonstrates how multiple handlers can be notified by a single task: - -.. code-block:: yaml - - tasks: - - name: Template configuration file - ansible.builtin.template: - src: template.j2 - dest: /etc/foo.conf - notify: - - Restart apache - - Restart memcached - - handlers: - - name: Restart memcached - ansible.builtin.service: - name: memcached - state: restarted - - - name: Restart apache - ansible.builtin.service: - name: apache - state: restarted - -In the above example the handlers are executed on task change in the following order: ``Restart memcached``, ``Restart apache``. Handlers are executed in the order they are defined in the ``handlers`` section, not in the order listed in the ``notify`` statement. Notifying the same handler multiple times will result in executing the handler only once regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts. - - -Naming handlers ---------------- - -Handlers must be named in order for tasks to be able to notify them using the ``notify`` keyword. - -Alternately, handlers can utilize the ``listen`` keyword. Using this handler keyword, handlers can listen on topics that can group multiple handlers as follows: - -.. code-block:: yaml - - tasks: - - name: Restart everything - command: echo "this task will restart the web services" - notify: "restart web services" - - handlers: - - name: Restart memcached - service: - name: memcached - state: restarted - listen: "restart web services" - - - name: Restart apache - service: - name: apache - state: restarted - listen: "restart web services" - -Notifying the ``restart web services`` topic results in executing all handlers listening to that topic regardless of how those handlers are named. - -This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy). - -Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one defined is notified with ``notify``, effectively shadowing all of the previous handlers with the same name. Alternately handlers sharing the same name can all be notified and executed if they listen on the same topic by notifying that topic. - -There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles. - - -Controlling when handlers run ------------------------------ - -By default, handlers run after all the tasks in a particular play have been completed. Notified handlers are executed automatically after each of the following sections, in the following order: ``pre_tasks``, ``roles``/``tasks`` and ``post_tasks``. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts. - -If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module `, which executes Ansible actions: - -.. code-block:: yaml - - tasks: - - name: Some tasks go here - ansible.builtin.shell: ... - - - name: Flush handlers - meta: flush_handlers - - - name: Some other tasks - ansible.builtin.shell: ... - -The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play. - -Once handlers are executed, either automatically after each mentioned section or manually by the ``flush_handlers`` meta task, they can be notified and run again in later sections of the play. - - -Using variables with handlers ------------------------------ - -You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this: - -.. code-block:: yaml+jinja - - handlers: - # This handler name may cause your play to fail! - - name: Restart "{{ web_service_name }}" - -If the variable used in the handler name is not available, the entire play fails. Changing that variable mid-play **will not** result in newly created handler. - -Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this: - -.. code-block:: yaml+jinja - - tasks: - - name: Set host variables based on distribution - include_vars: "{{ ansible_facts.distribution }}.yml" - - handlers: - - name: Restart web service - ansible.builtin.service: - name: "{{ web_service_name | default('httpd') }}" - state: restarted - -While handler names can contain a template, ``listen`` topics cannot. - - -Handlers in roles ------------------ - -Handlers from roles are not just contained in their roles but rather inserted into global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``. - -Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section, but before any ``tasks`` handlers. - - -Includes and imports in handlers --------------------------------- -Notifying a dynamic include such as ``include_task`` as a handler results in executing all tasks from within the include. It is not possible to notify a handler defined inside a dynamic include. - -Having a static include such as ``import_task`` as a handler results in that handler being effectively rewritten by handlers from within that import before the play execution. A static include itself cannot be notified; the tasks from within that include, on the other hand, can be notified individually. - - -Meta tasks as handlers ----------------------- - -Since Ansible 2.14 :ref:`meta tasks ` are allowed to be used and notified as handlers. Note that however ``flush_handlers`` cannot be used as a handler to prevent unexpected behavior. - - -Limitations ------------ - -A handler cannot run ``import_role`` or ``include_role``. diff --git a/docs/docsite/rst/playbook_guide/playbooks_intro.rst b/docs/docsite/rst/playbook_guide/playbooks_intro.rst deleted file mode 100644 index 8592b0429ff..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_intro.rst +++ /dev/null @@ -1,159 +0,0 @@ -.. _about_playbooks: -.. _playbooks_intro: - -***************** -Ansible playbooks -***************** - -Ansible Playbooks offer a repeatable, re-usable, simple configuration management and multi-machine deployment system, one that is well suited to deploying complex applications. If you need to execute a task with Ansible more than once, write a playbook and put it under source control. Then you can use the playbook to push out new configuration or confirm the configuration of remote systems. The playbooks in the `ansible-examples repository `_ illustrate many useful techniques. You may want to look at these in another tab as you read the documentation. - -Playbooks can: - -* declare configurations -* orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order -* launch tasks synchronously or :ref:`asynchronously ` - -.. contents:: - :local: - -.. _playbook_language_example: - -Playbook syntax -=============== - -Playbooks are expressed in YAML format with a minimum of syntax. If you are not familiar with YAML, look at our overview of :ref:`yaml_syntax` and consider installing an add-on for your text editor (see :ref:`other_tools_and_programs`) to help you write clean YAML syntax in your playbooks. - -A playbook is composed of one or more 'plays' in an ordered list. The terms 'playbook' and 'play' are sports analogies. Each play executes part of the overall goal of the playbook, running one or more tasks. Each task calls an Ansible module. - -Playbook execution -================== - -A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple 'plays' can orchestrate multi-machine deployments, running one play on your webservers, then another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things: - -* the managed nodes to target, using a :ref:`pattern ` -* at least one task to execute - -.. note:: - - In Ansible 2.10 and later, we recommend you use the fully-qualified collection name in your playbooks to ensure the correct module is selected, because multiple collections can contain modules with the same name (for example, ``user``). See :ref:`collections_using_playbook`. - -In this example, the first play targets the web servers; the second play targets the database servers. - -.. code-block:: yaml - - --- - - name: Update web servers - hosts: webservers - remote_user: root - - tasks: - - name: Ensure apache is at the latest version - ansible.builtin.yum: - name: httpd - state: latest - - name: Write the apache config file - ansible.builtin.template: - src: /srv/httpd.j2 - dest: /etc/httpd.conf - - - name: Update db servers - hosts: databases - remote_user: root - - tasks: - - name: Ensure postgresql is at the latest version - ansible.builtin.yum: - name: postgresql - state: latest - - name: Ensure that postgresql is started - ansible.builtin.service: - name: postgresql - state: started - -Your playbook can include more than just a hosts line and tasks. For example, the playbook above sets a ``remote_user`` for each play. This is the user account for the SSH connection. You can add other :ref:`playbook_keywords` at the playbook, play, or task level to influence how Ansible behaves. Playbook keywords can control the :ref:`connection plugin `, whether to use :ref:`privilege escalation `, how to handle errors, and more. To support a variety of environments, Ansible lets you set many of these parameters as command-line flags, in your Ansible configuration, or in your inventory. Learning the :ref:`precedence rules ` for these sources of data will help you as you expand your Ansible ecosystem. - -.. _tasks_list: - -Task execution --------------- - -By default, Ansible executes each task in order, one at a time, against all machines matched by the host pattern. Each task executes a module with specific arguments. When a task has executed on all target machines, Ansible moves on to the next task. You can use :ref:`strategies ` to change this default behavior. Within each play, Ansible applies the same task directives to all hosts. If a task fails on a host, Ansible takes that host out of the rotation for the rest of the playbook. - -When you run a playbook, Ansible returns information about connections, the ``name`` lines of all your plays and tasks, whether each task has succeeded or failed on each machine, and whether each task has made a change on each machine. At the bottom of the playbook execution, Ansible provides a summary of the nodes that were targeted and how they performed. General failures and fatal "unreachable" communication attempts are kept separate in the counts. - -.. _idempotency: - -Desired state and 'idempotency' -------------------------------- - -Most Ansible modules check whether the desired final state has already been achieved, and exit without performing any actions if that state has been achieved, so that repeating the task does not change the final state. Modules that behave this way are often called 'idempotent.' Whether you run a playbook once, or multiple times, the outcome should be the same. However, not all playbooks and not all modules behave this way. If you are unsure, test your playbooks in a sandbox environment before running them multiple times in production. - -.. _executing_a_playbook: - -Running playbooks ------------------ - -To run your playbook, use the :ref:`ansible-playbook` command. - -.. code-block:: bash - - ansible-playbook playbook.yml -f 10 - -Use the ``--verbose`` flag when running your playbook to see detailed output from successful modules as well as unsuccessful ones. - -.. _playbook_ansible-pull: - -Ansible-Pull -============ - -Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead -of pushing configuration out to them, you can. - -The ``ansible-pull`` is a small script that will checkout a repo of configuration instructions from git, and then -run ``ansible-playbook`` against that content. - -Assuming you load balance your checkout location, ``ansible-pull`` scales essentially infinitely. - -Run ``ansible-pull --help`` for details. - -There's also a `clever playbook `_ available to configure ``ansible-pull`` through a crontab from push mode. - -Verifying playbooks -=================== - -You may want to verify your playbooks to catch syntax errors and other problems before you run them. The :ref:`ansible-playbook` command offers several options for verification, including ``--check``, ``--diff``, ``--list-hosts``, ``--list-tasks``, and ``--syntax-check``. The :ref:`validate-playbook-tools` describes other tools for validating and testing playbooks. - -.. _linting_playbooks: - -ansible-lint ------------- - -You can use `ansible-lint `_ for detailed, Ansible-specific feedback on your playbooks before you execute them. For example, if you run ``ansible-lint`` on the playbook called ``verify-apache.yml`` near the top of this page, you should get the following results: - -.. code-block:: bash - - $ ansible-lint verify-apache.yml - [403] Package installs should not use latest - verify-apache.yml:8 - Task/Handler: ensure apache is at the latest version - -The `ansible-lint default rules `_ page describes each error. For ``[403]``, the recommended fix is to change ``state: latest`` to ``state: present`` in the playbook. - -.. seealso:: - - `ansible-lint `_ - Learn how to test Ansible Playbooks syntax - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`tips_and_tricks` - Tips for managing playbooks in the real world - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete end-to-end playbook examples - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/playbook_guide/playbooks_lookups.rst b/docs/docsite/rst/playbook_guide/playbooks_lookups.rst deleted file mode 100644 index 785f150be69..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_lookups.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _playbooks_lookups: - -******* -Lookups -******* - -Lookup plugins retrieve data from outside sources such as files, databases, key/value stores, APIs, and other services. Like all templating, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. Before Ansible 2.5, lookups were mostly used indirectly in ``with_`` constructs for looping. Starting with Ansible 2.5, lookups are used more explicitly as part of Jinja2 expressions fed into the ``loop`` keyword. - -.. _lookups_and_variables: - -Using lookups in variables -========================== - -You can populate variables using lookups. Ansible evaluates the value each time it is executed in a task (or template). - -.. code-block:: yaml+jinja - - vars: - motd_value: "{{ lookup('file', '/etc/motd') }}" - tasks: - - debug: - msg: "motd value is {{ motd_value }}" - -For more details and a list of lookup plugins in ansible-core, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``. - -.. seealso:: - - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - :ref:`playbooks_loops` - Looping in playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_loops.rst b/docs/docsite/rst/playbook_guide/playbooks_loops.rst deleted file mode 100644 index 5e8afdeafb9..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_loops.rst +++ /dev/null @@ -1,499 +0,0 @@ -.. _playbooks_loops: - -***** -Loops -***** - -Ansible offers the ``loop``, ``with_``, and ``until`` keywords to execute a task multiple times. Examples of commonly-used loops include changing ownership on several files and/or directories with the :ref:`file module `, creating multiple users with the :ref:`user module `, and -repeating a polling step until a certain result is reached. - -.. note:: - * We added ``loop`` in Ansible 2.5. It is not yet a full replacement for ``with_``, but we recommend it for most use cases. - * We have not deprecated the use of ``with_`` - that syntax will still be valid for the foreseeable future. - * We are looking to improve ``loop`` syntax - watch this page and the `changelog `_ for updates. - -.. contents:: - :local: - -Comparing ``loop`` and ``with_*`` -================================= - -* The ``with_`` keywords rely on :ref:`lookup_plugins` - even ``items`` is a lookup. -* The ``loop`` keyword is equivalent to ``with_list``, and is the best choice for simple loops. -* The ``loop`` keyword will not accept a string as input, see :ref:`query_vs_lookup`. -* Generally speaking, any use of ``with_*`` covered in :ref:`migrating_to_loop` can be updated to use ``loop``. -* Be careful when changing ``with_items`` to ``loop``, as ``with_items`` performed implicit single-level flattening. You may need to use ``flatten(1)`` with ``loop`` to match the exact outcome. For example, to get the same output as: - -.. code-block:: yaml - - with_items: - - 1 - - [2,3] - - 4 - -you would need - -.. code-block:: yaml+jinja - - loop: "{{ [1, [2, 3], 4] | flatten(1) }}" - -* Any ``with_*`` statement that requires using ``lookup`` within a loop should not be converted to use the ``loop`` keyword. For example, instead of doing: - -.. code-block:: yaml+jinja - - loop: "{{ lookup('fileglob', '*.txt', wantlist=True) }}" - -it's cleaner to keep - -.. code-block:: yaml - - with_fileglob: '*.txt' - -.. _standard_loops: - -Standard loops -============== - -Iterating over a simple list ----------------------------- - -Repeated tasks can be written as standard loops over a simple list of strings. You can define the list directly in the task. - -.. code-block:: yaml+jinja - - - name: Add several users - ansible.builtin.user: - name: "{{ item }}" - state: present - groups: "wheel" - loop: - - testuser1 - - testuser2 - -You can define the list in a variables file, or in the 'vars' section of your play, then refer to the name of the list in the task. - -.. code-block:: yaml+jinja - - loop: "{{ somelist }}" - -Either of these examples would be the equivalent of - -.. code-block:: yaml - - - name: Add user testuser1 - ansible.builtin.user: - name: "testuser1" - state: present - groups: "wheel" - - - name: Add user testuser2 - ansible.builtin.user: - name: "testuser2" - state: present - groups: "wheel" - -You can pass a list directly to a parameter for some plugins. Most of the packaging modules, like :ref:`yum ` and :ref:`apt `, have this capability. When available, passing the list to a parameter is better than looping over the task. For example - -.. code-block:: yaml+jinja - - - name: Optimal yum - ansible.builtin.yum: - name: "{{ list_of_packages }}" - state: present - - - name: Non-optimal yum, slower and may cause issues with interdependencies - ansible.builtin.yum: - name: "{{ item }}" - state: present - loop: "{{ list_of_packages }}" - -Check the :ref:`module documentation ` to see if you can pass a list to any particular module's parameter(s). - -Iterating over a list of hashes -------------------------------- - -If you have a list of hashes, you can reference subkeys in a loop. For example: - -.. code-block:: yaml+jinja - - - name: Add several users - ansible.builtin.user: - name: "{{ item.name }}" - state: present - groups: "{{ item.groups }}" - loop: - - { name: 'testuser1', groups: 'wheel' } - - { name: 'testuser2', groups: 'root' } - -When combining :ref:`conditionals ` with a loop, the ``when:`` statement is processed separately for each item. -See :ref:`the_when_statement` for examples. - -Iterating over a dictionary ---------------------------- - -To loop over a dict, use the :ref:`dict2items `: - -.. code-block:: yaml+jinja - - - name: Using dict2items - ansible.builtin.debug: - msg: "{{ item.key }} - {{ item.value }}" - loop: "{{ tag_data | dict2items }}" - vars: - tag_data: - Environment: dev - Application: payment - -Here, we are iterating over `tag_data` and printing the key and the value from it. - -Registering variables with a loop -================================= - -You can register the output of a loop as a variable. For example - -.. code-block:: yaml+jinja - - - name: Register loop output as a variable - ansible.builtin.shell: "echo {{ item }}" - loop: - - "one" - - "two" - register: echo - -When you use ``register`` with a loop, the data structure placed in the variable will contain a ``results`` attribute that is a list of all responses from the module. This differs from the data structure returned when using ``register`` without a loop. - -.. code-block:: json - - { - "changed": true, - "msg": "All items completed", - "results": [ - { - "changed": true, - "cmd": "echo \"one\" ", - "delta": "0:00:00.003110", - "end": "2013-12-19 12:00:05.187153", - "invocation": { - "module_args": "echo \"one\"", - "module_name": "shell" - }, - "item": "one", - "rc": 0, - "start": "2013-12-19 12:00:05.184043", - "stderr": "", - "stdout": "one" - }, - { - "changed": true, - "cmd": "echo \"two\" ", - "delta": "0:00:00.002920", - "end": "2013-12-19 12:00:05.245502", - "invocation": { - "module_args": "echo \"two\"", - "module_name": "shell" - }, - "item": "two", - "rc": 0, - "start": "2013-12-19 12:00:05.242582", - "stderr": "", - "stdout": "two" - } - ] - } - -Subsequent loops over the registered variable to inspect the results may look like - -.. code-block:: yaml+jinja - - - name: Fail if return code is not 0 - ansible.builtin.fail: - msg: "The command ({{ item.cmd }}) did not have a 0 return code" - when: item.rc != 0 - loop: "{{ echo.results }}" - -During iteration, the result of the current item will be placed in the variable. - -.. code-block:: yaml+jinja - - - name: Place the result of the current item in the variable - ansible.builtin.shell: echo "{{ item }}" - loop: - - one - - two - register: echo - changed_when: echo.stdout != "one" - -.. _complex_loops: - -Complex loops -============= - -Iterating over nested lists ---------------------------- - -You can use Jinja2 expressions to iterate over complex lists. For example, a loop can combine nested lists. - -.. code-block:: yaml+jinja - - - name: Give users access to multiple databases - community.mysql.mysql_user: - name: "{{ item[0] }}" - priv: "{{ item[1] }}.*:ALL" - append_privs: true - password: "foo" - loop: "{{ ['alice', 'bob'] | product(['clientdb', 'employeedb', 'providerdb']) | list }}" - - -.. _do_until_loops: - -Retrying a task until a condition is met ----------------------------------------- - -.. versionadded:: 1.4 - -You can use the ``until`` keyword to retry a task until a certain condition is met. Here's an example: - -.. code-block:: yaml - - - name: Retry a task until a certain condition is met - ansible.builtin.shell: /usr/bin/foo - register: result - until: result.stdout.find("all systems go") != -1 - retries: 5 - delay: 10 - -This task runs up to 5 times with a delay of 10 seconds between each attempt. If the result of any attempt has "all systems go" in its stdout, the task succeeds. The default value for "retries" is 3 and "delay" is 5. - -To see the results of individual retries, run the play with ``-vv``. - -When you run a task with ``until`` and register the result as a variable, the registered variable will include a key called "attempts", which records the number of the retries for the task. - -.. note:: You must set the ``until`` parameter if you want a task to retry. If ``until`` is not defined, the value for the ``retries`` parameter is forced to 1. - -Looping over inventory ----------------------- - -To loop over your inventory, or just a subset of it, you can use a regular ``loop`` with the ``ansible_play_batch`` or ``groups`` variables. - -.. code-block:: yaml+jinja - - - name: Show all the hosts in the inventory - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ groups['all'] }}" - - - name: Show all the hosts in the current play - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ ansible_play_batch }}" - -There is also a specific lookup plugin ``inventory_hostnames`` that can be used like this - -.. code-block:: yaml+jinja - - - name: Show all the hosts in the inventory - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ query('inventory_hostnames', 'all') }}" - - - name: Show all the hosts matching the pattern, ie all but the group www - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ query('inventory_hostnames', 'all:!www') }}" - -More information on the patterns can be found in :ref:`intro_patterns`. - -.. _query_vs_lookup: - -Ensuring list input for ``loop``: using ``query`` rather than ``lookup`` -======================================================================== - -The ``loop`` keyword requires a list as input, but the ``lookup`` keyword returns a string of comma-separated values by default. Ansible 2.5 introduced a new Jinja2 function named :ref:`query ` that always returns a list, offering a simpler interface and more predictable output from lookup plugins when using the ``loop`` keyword. - -You can force ``lookup`` to return a list to ``loop`` by using ``wantlist=True``, or you can use ``query`` instead. - -The following two examples do the same thing. - -.. code-block:: yaml+jinja - - loop: "{{ query('inventory_hostnames', 'all') }}" - - loop: "{{ lookup('inventory_hostnames', 'all', wantlist=True) }}" - - -.. _loop_control: - -Adding controls to loops -======================== -.. versionadded:: 2.1 - -The ``loop_control`` keyword lets you manage your loops in useful ways. - -Limiting loop output with ``label`` ------------------------------------ -.. versionadded:: 2.2 - -When looping over complex data structures, the console output of your task can be enormous. To limit the displayed output, use the ``label`` directive with ``loop_control``. - -.. code-block:: yaml+jinja - - - name: Create servers - digital_ocean: - name: "{{ item.name }}" - state: present - loop: - - name: server1 - disks: 3gb - ram: 15Gb - network: - nic01: 100Gb - nic02: 10Gb - ... - loop_control: - label: "{{ item.name }}" - -The output of this task will display just the ``name`` field for each ``item`` instead of the entire contents of the multi-line ``{{ item }}`` variable. - -.. note:: This is for making console output more readable, not protecting sensitive data. If there is sensitive data in ``loop``, set ``no_log: yes`` on the task to prevent disclosure. - -Pausing within a loop ---------------------- -.. versionadded:: 2.2 - -To control the time (in seconds) between the execution of each item in a task loop, use the ``pause`` directive with ``loop_control``. - -.. code-block:: yaml+jinja - - # main.yml - - name: Create servers, pause 3s before creating next - community.digitalocean.digital_ocean: - name: "{{ item }}" - state: present - loop: - - server1 - - server2 - loop_control: - pause: 3 - -Tracking progress through a loop with ``index_var`` ---------------------------------------------------- -.. versionadded:: 2.5 - -To keep track of where you are in a loop, use the ``index_var`` directive with ``loop_control``. This directive specifies a variable name to contain the current loop index. - -.. code-block:: yaml+jinja - - - name: Count our fruit - ansible.builtin.debug: - msg: "{{ item }} with index {{ my_idx }}" - loop: - - apple - - banana - - pear - loop_control: - index_var: my_idx - -.. note:: `index_var` is 0 indexed. - -Defining inner and outer variable names with ``loop_var`` ---------------------------------------------------------- -.. versionadded:: 2.1 - -You can nest two looping tasks using ``include_tasks``. However, by default Ansible sets the loop variable ``item`` for each loop. This means the inner, nested loop will overwrite the value of ``item`` from the outer loop. -You can specify the name of the variable for each loop using ``loop_var`` with ``loop_control``. - -.. code-block:: yaml+jinja - - # main.yml - - include_tasks: inner.yml - loop: - - 1 - - 2 - - 3 - loop_control: - loop_var: outer_item - - # inner.yml - - name: Print outer and inner items - ansible.builtin.debug: - msg: "outer item={{ outer_item }} inner item={{ item }}" - loop: - - a - - b - - c - -.. note:: If Ansible detects that the current loop is using a variable which has already been defined, it will raise an error to fail the task. - -Extended loop variables ------------------------ -.. versionadded:: 2.8 - -As of Ansible 2.8 you can get extended loop information using the ``extended`` option to loop control. This option will expose the following information. - -========================== =========== -Variable Description --------------------------- ----------- -``ansible_loop.allitems`` The list of all items in the loop -``ansible_loop.index`` The current iteration of the loop. (1 indexed) -``ansible_loop.index0`` The current iteration of the loop. (0 indexed) -``ansible_loop.revindex`` The number of iterations from the end of the loop (1 indexed) -``ansible_loop.revindex0`` The number of iterations from the end of the loop (0 indexed) -``ansible_loop.first`` ``True`` if first iteration -``ansible_loop.last`` ``True`` if last iteration -``ansible_loop.length`` The number of items in the loop -``ansible_loop.previtem`` The item from the previous iteration of the loop. Undefined during the first iteration. -``ansible_loop.nextitem`` The item from the following iteration of the loop. Undefined during the last iteration. -========================== =========== - -:: - - loop_control: - extended: true - -.. note:: When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase. - -.. versionadded:: 2.14 - -To disable the ``ansible_loop.allitems`` item, to reduce memory consumption, set ``loop_control.extended_allitems: no``. - -:: - - loop_control: - extended: true - extended_allitems: false - -Accessing the name of your loop_var ------------------------------------ -.. versionadded:: 2.8 - -As of Ansible 2.8 you can get the name of the value provided to ``loop_control.loop_var`` using the ``ansible_loop_var`` variable - -For role authors, writing roles that allow loops, instead of dictating the required ``loop_var`` value, you can gather the value through the following - -.. code-block:: yaml+jinja - - "{{ lookup('vars', ansible_loop_var) }}" - -.. _migrating_to_loop: - -Migrating from with_X to loop -============================= - -.. include:: shared_snippets/with2loop.txt - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_module_defaults.rst b/docs/docsite/rst/playbook_guide/playbooks_module_defaults.rst deleted file mode 100644 index 3a4bdfc31f8..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_module_defaults.rst +++ /dev/null @@ -1,175 +0,0 @@ -.. _module_defaults: - -Module defaults -=============== - -If you frequently call the same module with the same arguments, it can be useful to define default arguments for that particular module using the ``module_defaults`` keyword. - -Here is a basic example: - -.. code-block:: YAML - - - hosts: localhost - module_defaults: - ansible.builtin.file: - owner: root - group: root - mode: 0755 - tasks: - - name: Create file1 - ansible.builtin.file: - state: touch - path: /tmp/file1 - - - name: Create file2 - ansible.builtin.file: - state: touch - path: /tmp/file2 - - - name: Create file3 - ansible.builtin.file: - state: touch - path: /tmp/file3 - -The ``module_defaults`` keyword can be used at the play, block, and task level. Any module arguments explicitly specified in a task will override any established default for that module argument. - -.. code-block:: YAML - - - block: - - name: Print a message - ansible.builtin.debug: - msg: "Different message" - module_defaults: - ansible.builtin.debug: - msg: "Default message" - -You can remove any previously established defaults for a module by specifying an empty dict. - -.. code-block:: YAML - - - name: Create file1 - ansible.builtin.file: - state: touch - path: /tmp/file1 - module_defaults: - file: {} - -.. note:: - Any module defaults set at the play level (and block/task level when using ``include_role`` or ``import_role``) will apply to any roles used, which may cause unexpected behavior in the role. - -Here are some more realistic use cases for this feature. - -Interacting with an API that requires auth. - -.. code-block:: YAML - - - hosts: localhost - module_defaults: - ansible.builtin.uri: - force_basic_auth: true - user: some_user - password: some_password - tasks: - - name: Interact with a web service - ansible.builtin.uri: - url: http://some.api.host/v1/whatever1 - - - name: Interact with a web service - ansible.builtin.uri: - url: http://some.api.host/v1/whatever2 - - - name: Interact with a web service - ansible.builtin.uri: - url: http://some.api.host/v1/whatever3 - -Setting a default AWS region for specific EC2-related modules. - -.. code-block:: YAML - - - hosts: localhost - vars: - my_region: us-west-2 - module_defaults: - amazon.aws.ec2: - region: '{{ my_region }}' - community.aws.ec2_instance_info: - region: '{{ my_region }}' - amazon.aws.ec2_vpc_net_info: - region: '{{ my_region }}' - -.. _module_defaults_groups: - -Module defaults groups ----------------------- - -.. versionadded:: 2.7 - -Ansible 2.7 adds a preview-status feature to group together modules that share common sets of parameters. This makes it easier to author playbooks making heavy use of API-based modules such as cloud modules. - -+---------+---------------------------+-----------------+ -| Group | Purpose | Ansible Version | -+=========+===========================+=================+ -| aws | Amazon Web Services | 2.7 | -+---------+---------------------------+-----------------+ -| azure | Azure | 2.7 | -+---------+---------------------------+-----------------+ -| gcp | Google Cloud Platform | 2.7 | -+---------+---------------------------+-----------------+ -| k8s | Kubernetes | 2.8 | -+---------+---------------------------+-----------------+ -| os | OpenStack | 2.8 | -+---------+---------------------------+-----------------+ -| acme | ACME | 2.10 | -+---------+---------------------------+-----------------+ -| docker* | Docker | 2.10 | -+---------+---------------------------+-----------------+ -| ovirt | oVirt | 2.10 | -+---------+---------------------------+-----------------+ -| vmware | VMware | 2.10 | -+---------+---------------------------+-----------------+ - -* The `docker_stack `_ module is not included in the ``docker`` defaults group. - -Use the groups with ``module_defaults`` by prefixing the group name with ``group/`` - for example ``group/aws``. - -In a playbook, you can set module defaults for whole groups of modules, such as setting a common AWS region. - -.. code-block:: YAML - - # example_play.yml - - hosts: localhost - module_defaults: - group/aws: - region: us-west-2 - tasks: - - name: Get info - aws_s3_bucket_info: - - # now the region is shared between both info modules - - - name: Get info - ec2_ami_info: - filters: - name: 'RHEL*7.5*' - -In ansible-core 2.12, collections can define their own groups in the ``meta/runtime.yml`` file. ``module_defaults`` does not take the ``collections`` keyword into account, so the fully qualified group name must be used for new groups in ``module_defaults``. - -Here is an example ``runtime.yml`` file for a collection and a sample playbook using the group. - -.. code-block:: YAML - - # collections/ansible_collections/ns/coll/meta/runtime.yml - action_groups: - groupname: - - module - - another.collection.module - -.. code-block:: YAML - - - hosts: localhost - module_defaults: - group/ns.coll.groupname: - option_name: option_value - tasks: - - ns.coll.module: - - another.collection.module diff --git a/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst b/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst deleted file mode 100644 index 7222ab33968..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst +++ /dev/null @@ -1,776 +0,0 @@ -.. _become: -.. _playbooks_privilege_escalation: - -****************************************** -Understanding privilege escalation: become -****************************************** - -Ansible uses existing privilege escalation systems to execute tasks with root privileges or with another user's permissions. Because this feature allows you to 'become' another user, different from the user that logged into the machine (remote user), we call it ``become``. The ``become`` keyword uses existing privilege escalation tools like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, `runas`, `machinectl` and others. - -.. contents:: - :local: - -Using become -============ - -You can control the use of ``become`` with play or task directives, connection variables, or at the command line. If you set privilege escalation properties in multiple ways, review the :ref:`general precedence rules` to understand which settings will be used. - -A full list of all become plugins that are included in Ansible can be found in the :ref:`become_plugin_list`. - -Become directives ------------------ - -You can set the directives that control ``become`` at the play or task level. You can override these by setting connection variables, which often differ from one host to another. These variables and directives are independent. For example, setting ``become_user`` does not set ``become``. - -become - set to ``yes`` to activate privilege escalation. - -become_user - set to user with desired privileges — the user you `become`, NOT the user you login as. Does NOT imply ``become: yes``, to allow it to be set at host level. Default value is ``root``. - -become_method - (at play or task level) overrides the default method set in ansible.cfg, set to use any of the :ref:`become_plugins`. - -become_flags - (at play or task level) permit the use of specific flags for the tasks or role. One common use is to change the user to nobody when the shell is set to nologin. Added in Ansible 2.2. - -For example, to manage a system service (which requires ``root`` privileges) when connected as a non-``root`` user, you can use the default value of ``become_user`` (``root``): - -.. code-block:: yaml - - - name: Ensure the httpd service is running - service: - name: httpd - state: started - become: true - -To run a command as the ``apache`` user: - -.. code-block:: yaml - - - name: Run a command as the apache user - command: somecommand - become: true - become_user: apache - -To do something as the ``nobody`` user when the shell is nologin: - -.. code-block:: yaml - - - name: Run a command as nobody - command: somecommand - become: true - become_method: su - become_user: nobody - become_flags: '-s /bin/sh' - -To specify a password for sudo, run ``ansible-playbook`` with ``--ask-become-pass`` (``-K`` for short). -If you run a playbook utilizing ``become`` and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with `CTRL-c`, then execute the playbook with ``-K`` and the appropriate password. - -Become connection variables ---------------------------- - -You can define different ``become`` options for each managed node or group. You can define these variables in inventory or use them as normal variables. - -ansible_become - overrides the ``become`` directive, decides if privilege escalation is used or not. - -ansible_become_method - which privilege escalation method should be used - -ansible_become_user - set the user you become through privilege escalation; does not imply ``ansible_become: yes`` - -ansible_become_password - set the privilege escalation password. See :ref:`playbooks_vault` for details on how to avoid having secrets in plain text - -ansible_common_remote_group - determines if Ansible should try to ``chgrp`` its temporary files to a group if ``setfacl`` and ``chown`` both fail. See `Risks of becoming an unprivileged user`_ for more information. Added in version 2.10. - -For example, if you want to run all tasks as ``root`` on a server named ``webserver``, but you can only connect as the ``manager`` user, you could use an inventory entry like this: - -.. code-block:: text - - webserver ansible_user=manager ansible_become=yes - -.. note:: - The variables defined above are generic for all become plugins but plugin specific ones can also be set instead. - Please see the documentation for each plugin for a list of all options the plugin has and how they can be defined. - A full list of become plugins in Ansible can be found at :ref:`become_plugins`. - -Become command-line options ---------------------------- - ---ask-become-pass, -K - ask for privilege escalation password; does not imply become will be used. Note that this password will be used for all hosts. - ---become, -b - run operations with become (no password implied) - ---become-method=BECOME_METHOD - privilege escalation method to use (default=sudo), - valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ] - ---become-user=BECOME_USER - run operations as this user (default=root), does not imply --become/-b - -Risks and limitations of become -=============================== - -Although privilege escalation is mostly intuitive, there are a few limitations -on how it works. Users should be aware of these to avoid surprises. - -Risks of becoming an unprivileged user --------------------------------------- - -Ansible modules are executed on the remote machine by first substituting the -parameters into the module file, then copying the file to the remote machine, -and finally executing it there. - -Everything is fine if the module file is executed without using ``become``, -when the ``become_user`` is root, or when the connection to the remote machine -is made as root. In these cases Ansible creates the module file with -permissions that only allow reading by the user and root, or only allow reading -by the unprivileged user being switched to. - -However, when both the connection user and the ``become_user`` are unprivileged, -the module file is written as the user that Ansible connects as (the -``remote_user``), but the file needs to be readable by the user Ansible is set -to ``become``. The details of how Ansible solves this can vary based on platform. -However, on POSIX systems, Ansible solves this problem in the following way: - -First, if :command:`setfacl` is installed and available in the remote ``PATH``, -and the temporary directory on the remote host is mounted with POSIX.1e -filesystem ACL support, Ansible will use POSIX ACLs to share the module file -with the second unprivileged user. - -Next, if POSIX ACLs are **not** available or :command:`setfacl` could not be -run, Ansible will attempt to change ownership of the module file using -:command:`chown` for systems which support doing so as an unprivileged user. - -New in Ansible 2.11, at this point, Ansible will try :command:`chmod +a` which -is a macOS-specific way of setting ACLs on files. - -New in Ansible 2.10, if all of the above fails, Ansible will then check the -value of the configuration setting ``ansible_common_remote_group``. Many -systems will allow a given user to change the group ownership of a file to a -group the user is in. As a result, if the second unprivileged user (the -``become_user``) has a UNIX group in common with the user Ansible is connected -as (the ``remote_user``), and if ``ansible_common_remote_group`` is defined to -be that group, Ansible can try to change the group ownership of the module file -to that group by using :command:`chgrp`, thereby likely making it readable to -the ``become_user``. - -At this point, if ``ansible_common_remote_group`` was defined and a -:command:`chgrp` was attempted and returned successfully, Ansible assumes (but, -importantly, does not check) that the new group ownership is enough and does not -fall back further. That is, Ansible **does not check** that the ``become_user`` -does in fact share a group with the ``remote_user``; so long as the command -exits successfully, Ansible considers the result successful and does not proceed -to check ``allow_world_readable_tmpfiles`` per below. - -If ``ansible_common_remote_group`` is **not** set and the chown above it failed, -or if ``ansible_common_remote_group`` *is* set but the :command:`chgrp` (or -following group-permissions :command:`chmod`) returned a non-successful exit -code, Ansible will lastly check the value of -``allow_world_readable_tmpfiles``. If this is set, Ansible will place the module -file in a world-readable temporary directory, with world-readable permissions to -allow the ``become_user`` (and incidentally any other user on the system) to -read the contents of the file. **If any of the parameters passed to the module -are sensitive in nature, and you do not trust the remote machines, then this is -a potential security risk.** - -Once the module is done executing, Ansible deletes the temporary file. - -Several ways exist to avoid the above logic flow entirely: - -* Use `pipelining`. When pipelining is enabled, Ansible does not save the - module to a temporary file on the client. Instead it pipes the module to - the remote python interpreter's stdin. Pipelining does not work for - python modules involving file transfer (for example: :ref:`copy `, - :ref:`fetch `, :ref:`template `), or for non-python modules. - -* Avoid becoming an unprivileged - user. Temporary files are protected by UNIX file permissions when you - ``become`` root or do not use ``become``. In Ansible 2.1 and above, UNIX - file permissions are also secure if you make the connection to the managed - machine as root and then use ``become`` to access an unprivileged account. - -.. warning:: Although the Solaris ZFS filesystem has filesystem ACLs, the ACLs - are not POSIX.1e filesystem acls (they are NFSv4 ACLs instead). Ansible - cannot use these ACLs to manage its temp file permissions so you may have - to resort to ``allow_world_readable_tmpfiles`` if the remote machines use ZFS. - -.. versionchanged:: 2.1 - -Ansible makes it hard to unknowingly use ``become`` insecurely. Starting in Ansible 2.1, -Ansible defaults to issuing an error if it cannot execute securely with ``become``. -If you cannot use pipelining or POSIX ACLs, must connect as an unprivileged user, -must use ``become`` to execute as a different unprivileged user, -and decide that your managed nodes are secure enough for the -modules you want to run there to be world readable, you can turn on -``allow_world_readable_tmpfiles`` in the :file:`ansible.cfg` file. Setting -``allow_world_readable_tmpfiles`` will change this from an error into -a warning and allow the task to run as it did prior to 2.1. - -.. versionchanged:: 2.10 - -Ansible 2.10 introduces the above-mentioned ``ansible_common_remote_group`` -fallback. As mentioned above, if enabled, it is used when ``remote_user`` and -``become_user`` are both unprivileged users. Refer to the text above for details -on when this fallback happens. - -.. warning:: As mentioned above, if ``ansible_common_remote_group`` and - ``allow_world_readable_tmpfiles`` are both enabled, it is unlikely that the - world-readable fallback will ever trigger, and yet Ansible might still be - unable to access the module file. This is because after the group ownership - change is successful, Ansible does not fall back any further, and also does - not do any check to ensure that the ``become_user`` is actually a member of - the "common group". This is a design decision made by the fact that doing - such a check would require another round-trip connection to the remote - machine, which is a time-expensive operation. Ansible does, however, emit a - warning in this case. - -Not supported by all connection plugins ---------------------------------------- - -Privilege escalation methods must also be supported by the connection plugin -used. Most connection plugins will warn if they do not support become. Some -will just ignore it as they always run as root (jail, chroot, and so on). - -Only one method may be enabled per host ---------------------------------------- - -Methods cannot be chained. You cannot use ``sudo /bin/su -`` to become a user, -you need to have privileges to run the command as that user in sudo or be able -to su directly to it (the same for pbrun, pfexec or other supported methods). - -Privilege escalation must be general ------------------------------------- - -You cannot limit privilege escalation permissions to certain commands. -Ansible does not always -use a specific command to do something but runs modules (code) from -a temporary file name which changes every time. If you have '/sbin/service' -or '/bin/chmod' as the allowed commands this will fail with ansible as those -paths won't match with the temporary file that Ansible creates to run the -module. If you have security rules that constrain your sudo/pbrun/doas environment -to running specific command paths only, use Ansible from a special account that -does not have this constraint, or use AWX or the :ref:`ansible_platform` to manage indirect access to SSH credentials. - -May not access environment variables populated by pamd_systemd --------------------------------------------------------------- - -For most Linux distributions using ``systemd`` as their init, the default -methods used by ``become`` do not open a new "session", in the sense of -systemd. Because the ``pam_systemd`` module will not fully initialize a new -session, you might have surprises compared to a normal session opened through -ssh: some environment variables set by ``pam_systemd``, most notably -``XDG_RUNTIME_DIR``, are not populated for the new user and instead inherited -or just emptied. - -This might cause trouble when trying to invoke systemd commands that depend on -``XDG_RUNTIME_DIR`` to access the bus: - -.. code-block:: console - - $ echo $XDG_RUNTIME_DIR - - $ systemctl --user status - Failed to connect to bus: Permission denied - -To force ``become`` to open a new systemd session that goes through -``pam_systemd``, you can use ``become_method: machinectl``. - -For more information, see `this systemd issue -`_. - -Resolving Temporary File Error Messsages ----------------------------------------- - -* Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user" -* This error can be resolved by installing the package that provides the ``setfacl`` command. (This is frequently the ``acl`` package but check your OS documentation.) - -.. _become_network: - -Become and network automation -============================= - -As of version 2.6, Ansible supports ``become`` for privilege escalation (entering ``enable`` mode or privileged EXEC mode) on all Ansible-maintained network platforms that support ``enable`` mode. Using ``become`` replaces the ``authorize`` and ``auth_pass`` options in a ``provider`` dictionary. - -You must set the connection type to either ``connection: ansible.netcommon.network_cli`` or ``connection: ansible.netcommon.httpapi`` to use ``become`` for privilege escalation on network devices. Check the :ref:`platform_options` documentation for details. - -You can use escalated privileges on only the specific tasks that need them, on an entire play, or on all plays. Adding ``become: yes`` and ``become_method: enable`` instructs Ansible to enter ``enable`` mode before executing the task, play, or playbook where those parameters are set. - -If you see this error message, the task that generated it requires ``enable`` mode to succeed: - -.. code-block:: console - - Invalid input (privileged mode required) - -To set ``enable`` mode for a specific task, add ``become`` at the task level: - -.. code-block:: yaml - - - name: Gather facts (eos) - arista.eos.eos_facts: - gather_subset: - - "!hardware" - become: true - become_method: enable - -To set enable mode for all tasks in a single play, add ``become`` at the play level: - -.. code-block:: yaml - - - hosts: eos-switches - become: true - become_method: enable - tasks: - - name: Gather facts (eos) - arista.eos.eos_facts: - gather_subset: - - "!hardware" - -Setting enable mode for all tasks ---------------------------------- - -Often you wish for all tasks in all plays to run using privilege mode, that is best achieved by using ``group_vars``: - -**group_vars/eos.yml** - -.. code-block:: yaml - - ansible_connection: ansible.netcommon.network_cli - ansible_network_os: arista.eos.eos - ansible_user: myuser - ansible_become: true - ansible_become_method: enable - -Passwords for enable mode -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you need a password to enter ``enable`` mode, you can specify it in one of two ways: - -* providing the :option:`--ask-become-pass ` command line option -* setting the ``ansible_become_password`` connection variable - -.. warning:: - - As a reminder passwords should never be stored in plain text. For information on encrypting your passwords and other secrets with Ansible Vault, see :ref:`vault`. - -authorize and auth_pass ------------------------ - -Ansible still supports ``enable`` mode with ``connection: local`` for legacy network playbooks. To enter ``enable`` mode with ``connection: local``, use the module options ``authorize`` and ``auth_pass``: - -.. code-block:: yaml - - - hosts: eos-switches - ansible_connection: local - tasks: - - name: Gather facts (eos) - eos_facts: - gather_subset: - - "!hardware" - provider: - authorize: true - auth_pass: " {{ secret_auth_pass }}" - -We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` documentation for details. - -.. _become_windows: - -Become and Windows -================== - -Since Ansible 2.3, ``become`` can be used on Windows hosts through the -``runas`` method. Become on Windows uses the same inventory setup and -invocation arguments as ``become`` on a non-Windows host, so the setup and -variable names are the same as what is defined in this document with the exception -of ``become_user``. As there is no sensible default for ``become_user`` on Windows -it is required when using ``become``. See :ref:`ansible.builtin.runas become plugin ` for details. - -While ``become`` can be used to assume the identity of another user, there are other uses for -it with Windows hosts. One important use is to bypass some of the -limitations that are imposed when running on WinRM, such as constrained network -delegation or accessing forbidden system calls like the WUA API. You can use -``become`` with the same user as ``ansible_user`` to bypass these limitations -and run commands that are not normally accessible in a WinRM session. - -.. Note:: - On Windows you cannot connect with an underprivileged account and use become - to elevate your rights. Become can only be used if your connection account - is already an Administrator of the target host. - -Administrative rights ---------------------- - -Many tasks in Windows require administrative privileges to complete. When using -the ``runas`` become method, Ansible will attempt to run the module with the -full privileges that are available to the become user. If it fails to elevate -the user token, it will continue to use the limited token during execution. - -A user must have the ``SeDebugPrivilege`` to run a become process with elevated -privileges. This privilege is assigned to Administrators by default. If the -debug privilege is not available, the become process will run with a limited -set of privileges and groups. - -To determine the type of token that Ansible was able to get, run the following -task: - -.. code-block:: yaml - - - Check my user name - ansible.windows.win_whoami: - become: true - -The output will look something similar to the below: - -.. code-block:: ansible-output - - ok: [windows] => { - "account": { - "account_name": "vagrant-domain", - "domain_name": "DOMAIN", - "sid": "S-1-5-21-3088887838-4058132883-1884671576-1105", - "type": "User" - }, - "authentication_package": "Kerberos", - "changed": false, - "dns_domain_name": "DOMAIN.LOCAL", - "groups": [ - { - "account_name": "Administrators", - "attributes": [ - "Mandatory", - "Enabled by default", - "Enabled", - "Owner" - ], - "domain_name": "BUILTIN", - "sid": "S-1-5-32-544", - "type": "Alias" - }, - { - "account_name": "INTERACTIVE", - "attributes": [ - "Mandatory", - "Enabled by default", - "Enabled" - ], - "domain_name": "NT AUTHORITY", - "sid": "S-1-5-4", - "type": "WellKnownGroup" - }, - ], - "impersonation_level": "SecurityAnonymous", - "label": { - "account_name": "High Mandatory Level", - "domain_name": "Mandatory Label", - "sid": "S-1-16-12288", - "type": "Label" - }, - "login_domain": "DOMAIN", - "login_time": "2018-11-18T20:35:01.9696884+00:00", - "logon_id": 114196830, - "logon_server": "DC01", - "logon_type": "Interactive", - "privileges": { - "SeBackupPrivilege": "disabled", - "SeChangeNotifyPrivilege": "enabled-by-default", - "SeCreateGlobalPrivilege": "enabled-by-default", - "SeCreatePagefilePrivilege": "disabled", - "SeCreateSymbolicLinkPrivilege": "disabled", - "SeDebugPrivilege": "enabled", - "SeDelegateSessionUserImpersonatePrivilege": "disabled", - "SeImpersonatePrivilege": "enabled-by-default", - "SeIncreaseBasePriorityPrivilege": "disabled", - "SeIncreaseQuotaPrivilege": "disabled", - "SeIncreaseWorkingSetPrivilege": "disabled", - "SeLoadDriverPrivilege": "disabled", - "SeManageVolumePrivilege": "disabled", - "SeProfileSingleProcessPrivilege": "disabled", - "SeRemoteShutdownPrivilege": "disabled", - "SeRestorePrivilege": "disabled", - "SeSecurityPrivilege": "disabled", - "SeShutdownPrivilege": "disabled", - "SeSystemEnvironmentPrivilege": "disabled", - "SeSystemProfilePrivilege": "disabled", - "SeSystemtimePrivilege": "disabled", - "SeTakeOwnershipPrivilege": "disabled", - "SeTimeZonePrivilege": "disabled", - "SeUndockPrivilege": "disabled" - }, - "rights": [ - "SeNetworkLogonRight", - "SeBatchLogonRight", - "SeInteractiveLogonRight", - "SeRemoteInteractiveLogonRight" - ], - "token_type": "TokenPrimary", - "upn": "vagrant-domain@DOMAIN.LOCAL", - "user_flags": [] - } - -Under the ``label`` key, the ``account_name`` entry determines whether the user -has Administrative rights. Here are the labels that can be returned and what -they represent: - -* ``Medium``: Ansible failed to get an elevated token and ran under a limited - token. Only a subset of the privileges assigned to user are available during - the module execution and the user does not have administrative rights. - -* ``High``: An elevated token was used and all the privileges assigned to the - user are available during the module execution. - -* ``System``: The ``NT AUTHORITY\System`` account is used and has the highest - level of privileges available. - -The output will also show the list of privileges that have been granted to the -user. When the privilege value is ``disabled``, the privilege is assigned to -the logon token but has not been enabled. In most scenarios these privileges -are automatically enabled when required. - -If running on a version of Ansible that is older than 2.5 or the normal -``runas`` escalation process fails, an elevated token can be retrieved by: - -* Set the ``become_user`` to ``System`` which has full control over the - operating system. - -* Grant ``SeTcbPrivilege`` to the user Ansible connects with on - WinRM. ``SeTcbPrivilege`` is a high-level privilege that grants - full control over the operating system. No user is given this privilege by - default, and care should be taken if you grant this privilege to a user or group. - For more information on this privilege, please see - `Act as part of the operating system `_. - You can use the below task to set this privilege on a Windows host: - - .. code-block:: yaml - - - name: grant the ansible user the SeTcbPrivilege right - ansible.windows.win_user_right: - name: SeTcbPrivilege - users: '{{ansible_user}}' - action: add - -* Turn UAC off on the host and reboot before trying to become the user. UAC is - a security protocol that is designed to run accounts with the - ``least privilege`` principle. You can turn UAC off by running the following - tasks: - - .. code-block:: yaml - - - name: turn UAC off - win_regedit: - path: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system - name: EnableLUA - data: 0 - type: dword - state: present - register: uac_result - - - name: reboot after disabling UAC - win_reboot: - when: uac_result is changed - -.. Note:: Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows - security vulnerabilities and care should be given if these steps are taken. - -Local service accounts ----------------------- - -Prior to Ansible version 2.5, ``become`` only worked on Windows with a local or domain -user account. Local service accounts like ``System`` or ``NetworkService`` -could not be used as ``become_user`` in these older versions. This restriction -has been lifted since the 2.5 release of Ansible. The three service accounts -that can be set under ``become_user`` are: - -* System -* NetworkService -* LocalService - -Because local service accounts do not have passwords, the -``ansible_become_password`` parameter is not required and is ignored if -specified. - -Become without setting a password ---------------------------------- - -As of Ansible 2.8, ``become`` can be used to become a Windows local or domain account -without requiring a password for that account. For this method to work, the -following requirements must be met: - -* The connection user has the ``SeDebugPrivilege`` privilege assigned -* The connection user is part of the ``BUILTIN\Administrators`` group -* The ``become_user`` has either the ``SeBatchLogonRight`` or ``SeNetworkLogonRight`` user right - -Using become without a password is achieved in one of two different methods: - -* Duplicating an existing logon session's token if the account is already logged on -* Using S4U to generate a logon token that is valid on the remote host only - -In the first scenario, the become process is spawned from another logon of that -user account. This could be an existing RDP logon, console logon, but this is -not guaranteed to occur all the time. This is similar to the -``Run only when user is logged on`` option for a Scheduled Task. - -In the case where another logon of the become account does not exist, S4U is -used to create a new logon and run the module through that. This is similar to -the ``Run whether user is logged on or not`` with the ``Do not store password`` -option for a Scheduled Task. In this scenario, the become process will not be -able to access any network resources like a normal WinRM process. - -To make a distinction between using become with no password and becoming an -account that has no password make sure to keep ``ansible_become_password`` as -undefined or set ``ansible_become_password:``. - -.. Note:: Because there are no guarantees an existing token will exist for a - user when Ansible runs, there's a high change the become process will only - have access to local resources. Use become with a password if the task needs - to access network resources - -Accounts without a password ---------------------------- - -.. Warning:: As a general security best practice, you should avoid allowing accounts without passwords. - -Ansible can be used to become a Windows account that does not have a password (like the -``Guest`` account). To become an account without a password, set up the -variables like normal but set ``ansible_become_password: ''``. - -Before become can work on an account like this, the local policy -`Accounts: Limit local account use of blank passwords to console logon only `_ -must be disabled. This can either be done through a Group Policy Object (GPO) -or with this Ansible task: - -.. code-block:: yaml - - - name: allow blank password on become - ansible.windows.win_regedit: - path: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa - name: LimitBlankPasswordUse - data: 0 - type: dword - state: present - -.. Note:: This is only for accounts that do not have a password. You still need - to set the account's password under ``ansible_become_password`` if the - become_user has a password. - -Become flags for Windows ------------------------- - -Ansible 2.5 added the ``become_flags`` parameter to the ``runas`` become method. -This parameter can be set using the ``become_flags`` task directive or set in -Ansible's configuration using ``ansible_become_flags``. The two valid values -that are initially supported for this parameter are ``logon_type`` and -``logon_flags``. - -.. Note:: These flags should only be set when becoming a normal user account, not a local service account like LocalSystem. - -The key ``logon_type`` sets the type of logon operation to perform. The value -can be set to one of the following: - -* ``interactive``: The default logon type. The process will be run under a - context that is the same as when running a process locally. This bypasses all - WinRM restrictions and is the recommended method to use. - -* ``batch``: Runs the process under a batch context that is similar to a - scheduled task with a password set. This should bypass most WinRM - restrictions and is useful if the ``become_user`` is not allowed to log on - interactively. - -* ``new_credentials``: Runs under the same credentials as the calling user, but - outbound connections are run under the context of the ``become_user`` and - ``become_password``, similar to ``runas.exe /netonly``. The ``logon_flags`` - flag should also be set to ``netcredentials_only``. Use this flag if - the process needs to access a network resource (like an SMB share) using a - different set of credentials. - -* ``network``: Runs the process under a network context without any cached - credentials. This results in the same type of logon session as running a - normal WinRM process without credential delegation, and operates under the same - restrictions. - -* ``network_cleartext``: Like the ``network`` logon type, but instead caches - the credentials so it can access network resources. This is the same type of - logon session as running a normal WinRM process with credential delegation. - -For more information, see -`dwLogonType `_. - -The ``logon_flags`` key specifies how Windows will log the user on when creating -the new process. The value can be set to none or multiple of the following: - -* ``with_profile``: The default logon flag set. The process will load the - user's profile in the ``HKEY_USERS`` registry key to ``HKEY_CURRENT_USER``. - -* ``netcredentials_only``: The process will use the same token as the caller - but will use the ``become_user`` and ``become_password`` when accessing a remote - resource. This is useful in inter-domain scenarios where there is no trust - relationship, and should be used with the ``new_credentials`` ``logon_type``. - -By default ``logon_flags=with_profile`` is set, if the profile should not be -loaded set ``logon_flags=`` or if the profile should be loaded with -``netcredentials_only``, set ``logon_flags=with_profile,netcredentials_only``. - -For more information, see `dwLogonFlags `_. - -Here are some examples of how to use ``become_flags`` with Windows tasks: - -.. code-block:: yaml - - - name: copy a file from a fileshare with custom credentials - ansible.windows.win_copy: - src: \\server\share\data\file.txt - dest: C:\temp\file.txt - remote_src: true - vars: - ansible_become: true - ansible_become_method: runas - ansible_become_user: DOMAIN\user - ansible_become_password: Password01 - ansible_become_flags: logon_type=new_credentials logon_flags=netcredentials_only - - - name: run a command under a batch logon - ansible.windows.win_whoami: - become: true - become_flags: logon_type=batch - - - name: run a command and not load the user profile - ansible.windows.win_whomai: - become: true - become_flags: logon_flags= - - -Limitations of become on Windows --------------------------------- - -* Running a task with ``async`` and ``become`` on Windows Server 2008, 2008 R2 - and Windows 7 only works when using Ansible 2.7 or newer. - -* By default, the become user logs on with an interactive session, so it must - have the right to do so on the Windows host. If it does not inherit the - ``SeAllowLogOnLocally`` privilege or inherits the ``SeDenyLogOnLocally`` - privilege, the become process will fail. Either add the privilege or set the - ``logon_type`` flag to change the logon type used. - -* Prior to Ansible version 2.3, become only worked when - ``ansible_winrm_transport`` was either ``basic`` or ``credssp``. This - restriction has been lifted since the 2.4 release of Ansible for all hosts - except Windows Server 2008 (non R2 version). - -* The Secondary Logon service ``seclogon`` must be running to use ``ansible_become_method: runas`` - -* The connection user must already be an Administrator on the Windows host to - use ``runas``. The target become user does not need to be an Administrator - though. - - -.. seealso:: - - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_prompts.rst b/docs/docsite/rst/playbook_guide/playbooks_prompts.rst deleted file mode 100644 index 1afb3fa028f..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_prompts.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. _playbooks_prompts: - -************************** -Interactive input: prompts -************************** - -If you want your playbook to prompt the user for certain input, add a 'vars_prompt' section. Prompting the user for variables lets you avoid recording sensitive data like passwords. In addition to security, prompts support flexibility. For example, if you use one playbook across multiple software releases, you could prompt for the particular release version. - -.. contents:: - :local: - -Here is a most basic example: - -.. code-block:: yaml - - --- - - hosts: all - vars_prompt: - - - name: username - prompt: What is your username? - private: false - - - name: password - prompt: What is your password? - - tasks: - - - name: Print a message - ansible.builtin.debug: - msg: 'Logging in as {{ username }}' - -The user input is hidden by default but it can be made visible by setting ``private: no``. - -.. note:: - Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible AWX). See :ref:`passing_variables_on_the_command_line`. - -If you have a variable that changes infrequently, you can provide a default value that can be overridden. - -.. code-block:: yaml - - vars_prompt: - - - name: release_version - prompt: Product release version - default: "1.0" - -Hashing values supplied by ``vars_prompt`` ------------------------------------------- - -You can hash the entered value so you can use it, for instance, with the user module to define a password: - -.. code-block:: yaml - - vars_prompt: - - - name: my_password2 - prompt: Enter password2 - private: true - encrypt: sha512_crypt - confirm: true - salt_size: 7 - -If you have `Passlib `_ installed, you can use any crypt scheme the library supports: - -- *des_crypt* - DES Crypt -- *bsdi_crypt* - BSDi Crypt -- *bigcrypt* - BigCrypt -- *crypt16* - Crypt16 -- *md5_crypt* - MD5 Crypt -- *bcrypt* - BCrypt -- *sha1_crypt* - SHA-1 Crypt -- *sun_md5_crypt* - Sun MD5 Crypt -- *sha256_crypt* - SHA-256 Crypt -- *sha512_crypt* - SHA-512 Crypt -- *apr_md5_crypt* - Apache's MD5-Crypt variant -- *phpass* - PHPass' Portable Hash -- *pbkdf2_digest* - Generic PBKDF2 Hashes -- *cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash -- *dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash -- *scram* - SCRAM Hash -- *bsd_nthash* - FreeBSD's MCF-compatible nthash encoding - -The only parameters accepted are 'salt' or 'salt_size'. You can use your own salt by defining -'salt', or have one generated automatically using 'salt_size'. By default Ansible generates a salt -of size 8. - -.. versionadded:: 2.7 - -If you do not have Passlib installed, Ansible uses the `crypt `_ library as a fallback. Ansible supports at most four crypt schemes, depending on your platform at most the following crypt schemes are supported: - -- *bcrypt* - BCrypt -- *md5_crypt* - MD5 Crypt -- *sha256_crypt* - SHA-256 Crypt -- *sha512_crypt* - SHA-512 Crypt - -.. versionadded:: 2.8 -.. _unsafe_prompts: - -Allowing special characters in ``vars_prompt`` values ------------------------------------------------------ - -Some special characters, such as ``{`` and ``%`` can create templating errors. If you need to accept special characters, use the ``unsafe`` option: - -.. code-block:: yaml - - vars_prompt: - - name: my_password_with_weird_chars - prompt: Enter password - unsafe: true - private: true - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_python_version.rst b/docs/docsite/rst/playbook_guide/playbooks_python_version.rst deleted file mode 100644 index ee18b60713e..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_python_version.rst +++ /dev/null @@ -1,68 +0,0 @@ -.. _pb-py-compat: - -******************** -Python3 in templates -******************** - -Ansible uses Jinja2 to take advantage of Python data types and standard functions in templates and variables. -You can use these data types and standard functions to perform a rich set of operations on your data. However, -if you use templates, you must be aware of differences between Python versions. - -These topics help you design templates that work on both Python2 and Python3. They might also help if you are upgrading from Python2 to Python3. Upgrading within Python2 or Python3 does not usually introduce changes that affect Jinja2 templates. - -.. _pb-py-compat-dict-views: - -Dictionary views -================ - -In Python2, the :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` -methods return a list. Jinja2 returns that to Ansible using a string -representation that Ansible can turn back into a list. - -In Python3, those methods return a :ref:`dictionary view ` object. The -string representation that Jinja2 returns for dictionary views cannot be parsed back -into a list by Ansible. It is, however, easy to make this portable by -using the :func:`list ` filter whenever using :meth:`dict.keys`, -:meth:`dict.values`, or :meth:`dict.items`. - -.. code-block:: yaml+jinja - - vars: - hosts: - testhost1: 127.0.0.2 - testhost2: 127.0.0.3 - tasks: - - debug: - msg: '{{ item }}' - # Only works with Python 2 - #loop: "{{ hosts.keys() }}" - # Works with both Python 2 and Python 3 - loop: "{{ hosts.keys() | list }}" - -.. _pb-py-compat-iteritems: - -dict.iteritems() -================ - -Python2 dictionaries have :meth:`~dict.iterkeys`, :meth:`~dict.itervalues`, and :meth:`~dict.iteritems` methods. - -Python3 dictionaries do not have these methods. Use :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` to make your playbooks and templates compatible with both Python2 and Python3. - -.. code-block:: yaml+jinja - - vars: - hosts: - testhost1: 127.0.0.2 - testhost2: 127.0.0.3 - tasks: - - debug: - msg: '{{ item }}' - # Only works with Python 2 - #loop: "{{ hosts.iteritems() }}" - # Works with both Python 2 and Python 3 - loop: "{{ hosts.items() | list }}" - -.. seealso:: - * The :ref:`pb-py-compat-dict-views` entry for information on - why the :func:`list filter ` is necessary - here. diff --git a/docs/docsite/rst/playbook_guide/playbooks_reuse.rst b/docs/docsite/rst/playbook_guide/playbooks_reuse.rst deleted file mode 100644 index 89cc5a42161..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_reuse.rst +++ /dev/null @@ -1,226 +0,0 @@ -.. _playbooks_reuse: - -************************** -Re-using Ansible artifacts -************************** - -You can write a simple playbook in one very large file, and most users learn the one-file approach first. However, breaking your automation work up into smaller files is an excellent way to organize complex sets of tasks and reuse them. Smaller, more distributed artifacts let you re-use the same variables, tasks, and plays in multiple playbooks to address different use cases. You can use distributed artifacts across multiple parent playbooks or even multiple times within one playbook. For example, you might want to update your customer database as part of several different playbooks. If you put all the tasks related to updating your database in a tasks file or a role, you can re-use them in many playbooks while only maintaining them in one place. - -.. contents:: - :local: - -Creating re-usable files and roles -================================== - -Ansible offers four distributed, re-usable artifacts: variables files, task files, playbooks, and roles. - - - A variables file contains only variables. - - A task file contains only tasks. - - A playbook contains at least one play, and may contain variables, tasks, and other content. You can re-use tightly focused playbooks, but you can only re-use them statically, not dynamically. - - A role contains a set of related tasks, variables, defaults, handlers, and even modules or other plugins in a defined file-tree. Unlike variables files, task files, or playbooks, roles can be easily uploaded and shared through Ansible Galaxy. See :ref:`playbooks_reuse_roles` for details about creating and using roles. - -.. versionadded:: 2.4 - -Re-using playbooks -================== - -You can incorporate multiple playbooks into a main playbook. However, you can only use imports to re-use playbooks. For example: - -.. code-block:: yaml - - - import_playbook: webservers.yml - - import_playbook: databases.yml - -Importing incorporates playbooks in other playbooks statically. Ansible runs the plays and tasks in each imported playbook in the order they are listed, just as if they had been defined directly in the main playbook. - -You can select which playbook you want to import at runtime by defining your imported playbook filename with a variable, then passing the variable with either ``--extra-vars`` or the ``vars`` keyword. For example: - -.. code-block:: yaml - - - import_playbook: "/path/to/{{ import_from_extra_var }}" - - import_playbook: "{{ import_from_vars }}" - vars: - import_from_vars: /path/to/one_playbook.yml - -If you run this playbook with ``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml``, Ansible imports both one_playbook.yml and other_playbook.yml. - -When to turn a playbook into a role -=================================== - -For some use cases, simple playbooks work well. However, starting at a certain level of complexity, roles work better than playbooks. A role lets you store your defaults, handlers, variables, and tasks in separate directories, instead of in a single long document. Roles are easy to share on Ansible Galaxy. For complex use cases, most users find roles easier to read, understand, and maintain than all-in-one playbooks. - -Re-using files and roles -======================== - -Ansible offers two ways to re-use files and roles in a playbook: dynamic and static. - - - For dynamic re-use, add an ``include_*`` task in the tasks section of a play: - - - :ref:`include_role ` - - :ref:`include_tasks ` - - :ref:`include_vars ` - - - For static re-use, add an ``import_*`` task in the tasks section of a play: - - - :ref:`import_role ` - - :ref:`import_tasks ` - -Task include and import statements can be used at arbitrary depth. - -You can still use the bare :ref:`roles ` keyword at the play level to incorporate a role in a playbook statically. However, the bare :ref:`include ` keyword, once used for both task files and playbook-level includes, is now deprecated. - -Includes: dynamic re-use ------------------------- - -Including roles, tasks, or variables adds them to a playbook dynamically. Ansible processes included files and roles as they come up in a playbook, so included tasks can be affected by the results of earlier tasks within the top-level playbook. Included roles and tasks are similar to handlers - they may or may not run, depending on the results of other tasks in the top-level playbook. - -The primary advantage of using ``include_*`` statements is looping. When a loop is used with an include, the included tasks or role will be executed once for each item in the loop. - -The filenames for included roles, tasks, and vars are templated before inclusion. - -You can pass variables into includes. See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence. - -Imports: static re-use ----------------------- - -Importing roles, tasks, or playbooks adds them to a playbook statically. Ansible pre-processes imported files and roles before it runs any tasks in a playbook, so imported content is never affected by other tasks within the top-level playbook. - -The filenames for imported roles and tasks support templating, but the variables must be available when Ansible is pre-processing the imports. This can be done with the ``vars`` keyword or by using ``--extra-vars``. - -You can pass variables to imports. You must pass variables if you want to run an imported file more than once in a playbook. For example: - -.. code-block:: yaml - - tasks: - - import_tasks: wordpress.yml - vars: - wp_user: timmy - - - import_tasks: wordpress.yml - vars: - wp_user: alice - - - import_tasks: wordpress.yml - vars: - wp_user: bob - -See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence. - -.. _dynamic_vs_static: - -Comparing includes and imports: dynamic and static re-use ------------------------------------------------------------- - -Each approach to re-using distributed Ansible artifacts has advantages and limitations. You may choose dynamic re-use for some playbooks and static re-use for others. Although you can use both dynamic and static re-use in a single playbook, it is best to select one approach per playbook. Mixing static and dynamic re-use can introduce difficult-to-diagnose bugs into your playbooks. This table summarizes the main differences so you can choose the best approach for each playbook you create. - -.. table:: - :class: documentation-table - - ========================= ======================================== ======================================== - .. Include_* Import_* - ========================= ======================================== ======================================== - Type of re-use Dynamic Static - - When processed At runtime, when encountered Pre-processed during playbook parsing - - Task or play All includes are tasks ``import_playbook`` cannot be a task - - Task options Apply only to include task itself Apply to all child tasks in import - - Calling from loops Executed once for each loop item Cannot be used in a loop - - Using ``--list-tags`` Tags within includes not listed All tags appear with ``--list-tags`` - - Using ``--list-tasks`` Tasks within includes not listed All tasks appear with ``--list-tasks`` - - Notifying handlers Cannot trigger handlers within includes Can trigger individual imported handlers - - Using ``--start-at-task`` Cannot start at tasks within includes Can start at imported tasks - - Using inventory variables Can ``include_*: {{ inventory_var }}`` Cannot ``import_*: {{ inventory_var }}`` - - With playbooks No ``include_playbook`` Can import full playbooks - - With variables files Can include variables files Use ``vars_files:`` to import variables - - ========================= ======================================== ======================================== - - -.. note:: - * There are also big differences in resource consumption and performance, imports are quite lean and fast, while includes require a lot of management - and accounting. - -Re-using tasks as handlers -========================== - -You can also use includes and imports in the :ref:`handlers` section of a playbook. For instance, if you want to define how to restart Apache, you only have to do that once for all of your playbooks. You might make a ``restarts.yml`` file that looks like: - -.. code-block:: yaml - - # restarts.yml - - name: Restart apache - ansible.builtin.service: - name: apache - state: restarted - - - name: Restart mysql - ansible.builtin.service: - name: mysql - state: restarted - -You can trigger handlers from either an import or an include, but the procedure is different for each method of re-use. If you include the file, you must notify the include itself, which triggers all the tasks in ``restarts.yml``. If you import the file, you must notify the individual task(s) within ``restarts.yml``. You can mix direct tasks and handlers with included or imported tasks and handlers. - -Triggering included (dynamic) handlers --------------------------------------- - -Includes are executed at run-time, so the name of the include exists during play execution, but the included tasks do not exist until the include itself is triggered. To use the ``Restart apache`` task with dynamic re-use, refer to the name of the include itself. This approach triggers all tasks in the included file as handlers. For example, with the task file shown above: - -.. code-block:: yaml - - - name: Trigger an included (dynamic) handler - hosts: localhost - handlers: - - name: Restart services - include_tasks: restarts.yml - tasks: - - command: "true" - notify: Restart services - -Triggering imported (static) handlers -------------------------------------- - -Imports are processed before the play begins, so the name of the import no longer exists during play execution, but the names of the individual imported tasks do exist. To use the ``Restart apache`` task with static re-use, refer to the name of each task or tasks within the imported file. For example, with the task file shown above: - -.. code-block:: yaml - - - name: Trigger an imported (static) handler - hosts: localhost - handlers: - - name: Restart services - import_tasks: restarts.yml - tasks: - - command: "true" - notify: Restart apache - - command: "true" - notify: Restart mysql - -.. seealso:: - - :ref:`utilities_modules` - Documentation of the ``include*`` and ``import*`` modules discussed here. - :ref:`working_with_playbooks` - Review the basic Playbook language features - :ref:`playbooks_variables` - All about variables in playbooks - :ref:`playbooks_conditionals` - Conditionals in playbooks - :ref:`playbooks_loops` - Loops in playbooks - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`ansible_galaxy` - How to share roles on galaxy, role management - `GitHub Ansible examples `_ - Complete playbook files from the GitHub project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst b/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst deleted file mode 100644 index 99ca2bf1240..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst +++ /dev/null @@ -1,615 +0,0 @@ -.. _playbooks_reuse_roles: - -***** -Roles -***** - -Roles let you automatically load related vars, files, tasks, handlers, and other Ansible artifacts based on a known file structure. After you group your content in roles, you can easily reuse them and share them with other users. - -.. contents:: - :local: - -Role directory structure -======================== - -An Ansible role has a defined directory structure with eight main standard directories. You must include at least one of these directories in each role. You can omit any directories the role does not use. For example: - -.. code-block:: text - - # playbooks - site.yml - webservers.yml - fooservers.yml -.. include:: shared_snippets/role_directory.txt - - -By default Ansible will look in each directory within a role for a ``main.yml`` file for relevant content (also ``main.yaml`` and ``main``): - -- ``tasks/main.yml`` - the main list of tasks that the role executes. -- ``handlers/main.yml`` - handlers, which may be used within or outside this role. -- ``library/my_module.py`` - modules, which may be used within this role (see :ref:`embedding_modules_and_plugins_in_roles` for more information). -- ``defaults/main.yml`` - default variables for the role (see :ref:`playbooks_variables` for more information). These variables have the lowest priority of any variables available, and can be easily overridden by any other variable, including inventory variables. -- ``vars/main.yml`` - other variables for the role (see :ref:`playbooks_variables` for more information). -- ``files/main.yml`` - files that the role deploys. -- ``templates/main.yml`` - templates that the role deploys. -- ``meta/main.yml`` - metadata for the role, including role dependencies and optional Galaxy metadata such as platforms supported. - -You can add other YAML files in some directories. For example, you can place platform-specific tasks in separate files and refer to them in the ``tasks/main.yml`` file: - -.. code-block:: yaml - - # roles/example/tasks/main.yml - - name: Install the correct web server for RHEL - import_tasks: redhat.yml - when: ansible_facts['os_family']|lower == 'redhat' - - - name: Install the correct web server for Debian - import_tasks: debian.yml - when: ansible_facts['os_family']|lower == 'debian' - - # roles/example/tasks/redhat.yml - - name: Install web server - ansible.builtin.yum: - name: "httpd" - state: present - - # roles/example/tasks/debian.yml - - name: Install web server - ansible.builtin.apt: - name: "apache2" - state: present - -Roles may also include modules and other plugin types in a directory called ``library``. For more information, please refer to :ref:`embedding_modules_and_plugins_in_roles` below. - -.. _role_search_path: - -Storing and finding roles -========================= - -By default, Ansible looks for roles in the following locations: - -- in collections, if you are using them -- in a directory called ``roles/``, relative to the playbook file -- in the configured :ref:`roles_path `. The default search path is ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``. -- in the directory where the playbook file is located - -If you store your roles in a different location, set the :ref:`roles_path ` configuration option so Ansible can find your roles. Checking shared roles into a single location makes them easier to use in multiple playbooks. See :ref:`intro_configuration` for details about managing settings in ansible.cfg. - -Alternatively, you can call a role with a fully qualified path: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - role: '/path/to/my/roles/common' - -Using roles -=========== - -You can use roles in three ways: - -- at the play level with the ``roles`` option: This is the classic way of using roles in a play. -- at the tasks level with ``include_role``: You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. -- at the tasks level with ``import_role``: You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. - -.. _roles_keyword: - -Using roles at the play level ------------------------------ - -The classic (original) way to use roles is with the ``roles`` option for a given play: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - common - - webservers - -When you use the ``roles`` option at the play level, for each role 'x': - -- If roles/x/tasks/main.yml exists, Ansible adds the tasks in that file to the play. -- If roles/x/handlers/main.yml exists, Ansible adds the handlers in that file to the play. -- If roles/x/vars/main.yml exists, Ansible adds the variables in that file to the play. -- If roles/x/defaults/main.yml exists, Ansible adds the variables in that file to the play. -- If roles/x/meta/main.yml exists, Ansible adds any role dependencies in that file to the list of roles. -- Any copy, script, template or include tasks (in the role) can reference files in roles/x/{files,templates,tasks}/ (dir depends on task) without having to path them relatively or absolutely. - -When you use the ``roles`` option at the play level, Ansible treats the roles as static imports and processes them during playbook parsing. Ansible executes each play in this order: - -- Any ``pre_tasks`` defined in the play. -- Any handlers triggered by pre_tasks. -- Each role listed in ``roles:``, in the order listed. Any role dependencies defined in the role's ``meta/main.yml`` run first, subject to tag filtering and conditionals. See :ref:`role_dependencies` for more details. -- Any ``tasks`` defined in the play. -- Any handlers triggered by the roles or tasks. -- Any ``post_tasks`` defined in the play. -- Any handlers triggered by post_tasks. - -.. note:: - If using tags with tasks in a role, be sure to also tag your pre_tasks, post_tasks, and role dependencies and pass those along as well, especially if the pre/post tasks and role dependencies are used for monitoring outage window control or load balancing. See :ref:`tags` for details on adding and using tags. - -You can pass other keywords to the ``roles`` option: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - common - - role: foo_app_instance - vars: - dir: '/opt/a' - app_port: 5000 - tags: typeA - - role: foo_app_instance - vars: - dir: '/opt/b' - app_port: 5001 - tags: typeB - -When you add a tag to the ``role`` option, Ansible applies the tag to ALL tasks within the role. - -When using ``vars:`` within the ``roles:`` section of a playbook, the variables are added to the play variables, making them available to all tasks within the play before and after the role. This behavior can be changed by :ref:`DEFAULT_PRIVATE_ROLE_VARS`. - -Including roles: dynamic reuse ------------------------------- - -You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. While roles added in a ``roles`` section run before any other tasks in a play, included roles run in the order they are defined. If there are other tasks before an ``include_role`` task, the other tasks will run first. - -To include a role: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Print a message - ansible.builtin.debug: - msg: "this task runs before the example role" - - - name: Include the example role - include_role: - name: example - - - name: Print a message - ansible.builtin.debug: - msg: "this task runs after the example role" - -You can pass other keywords, including variables and tags, when including roles: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Include the foo_app_instance role - include_role: - name: foo_app_instance - vars: - dir: '/opt/a' - app_port: 5000 - tags: typeA - ... - -When you add a :ref:`tag ` to an ``include_role`` task, Ansible applies the tag `only` to the include itself. This means you can pass ``--tags`` to run only selected tasks from the role, if those tasks themselves have the same tag as the include statement. See :ref:`selective_reuse` for details. - -You can conditionally include a role: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Include the some_role role - include_role: - name: some_role - when: "ansible_facts['os_family'] == 'RedHat'" - -Importing roles: static reuse ------------------------------ - -You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. The behavior is the same as using the ``roles`` keyword. For example: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Print a message - ansible.builtin.debug: - msg: "before we run our role" - - - name: Import the example role - import_role: - name: example - - - name: Print a message - ansible.builtin.debug: - msg: "after we ran our role" - -You can pass other keywords, including variables and tags, when importing roles: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Import the foo_app_instance role - import_role: - name: foo_app_instance - vars: - dir: '/opt/a' - app_port: 5000 - ... - -When you add a tag to an ``import_role`` statement, Ansible applies the tag to `all` tasks within the role. See :ref:`tag_inheritance` for details. - -.. _role_argument_spec: - -Role argument validation -======================== - -Beginning with version 2.11, you may choose to enable role argument validation based on an argument -specification. This specification is defined in the ``meta/argument_specs.yml`` file (or with the ``.yaml`` -file extension). When this argument specification is defined, a new task is inserted at the beginning of role execution -that will validate the parameters supplied for the role against the specification. If the parameters fail -validation, the role will fail execution. - -.. note:: - - Ansible also supports role specifications defined in the role ``meta/main.yml`` file, as well. However, - any role that defines the specs within this file will not work on versions below 2.11. For this reason, - we recommend using the ``meta/argument_specs.yml`` file to maintain backward compatibility. - -.. note:: - - When role argument validation is used on a role that has defined :ref:`dependencies `, - then validation on those dependencies will run before the dependent role, even if argument validation fails - for the dependent role. - -Specification format --------------------- - -The role argument specification must be defined in a top-level ``argument_specs`` block within the -role ``meta/argument_specs.yml`` file. All fields are lower-case. - -:entry-point-name: - - * The name of the role entry point. - * This should be ``main`` in the case of an unspecified entry point. - * This will be the base name of the tasks file to execute, with no ``.yml`` or ``.yaml`` file extension. - - :short_description: - - * A short, one-line description of the entry point. - * The ``short_description`` is displayed by ``ansible-doc -t role -l``. - - :description: - - * A longer description that may contain multiple lines. - - :author: - - * Name of the entry point authors. - * Use a multi-line list if there is more than one author. - - :options: - - * Options are often called "parameters" or "arguments". This section defines those options. - * For each role option (argument), you may include: - - :option-name: - - * The name of the option/argument. - - :description: - - * Detailed explanation of what this option does. It should be written in full sentences. - - :type: - - * The data type of the option. See :ref:`Argument spec ` for allowed values for ``type``. Default is ``str``. - * If an option is of type ``list``, ``elements`` should be specified. - - :required: - - * Only needed if ``true``. - * If missing, the option is not required. - - :default: - - * If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing). - * Ensure that the default value in the docs matches the default value in the code. The actual - default for the role variable will always come from ``defaults/main.yml``. - * The default field must not be listed as part of the description, unless it requires additional information or conditions. - * If the option is a boolean value, you should use `true/false` if you want to be compatible with `ansible-lint`. - - :choices: - - * List of option values. - * Should be absent if empty. - - :elements: - - * Specifies the data type for list elements when type is ``list``. - - :options: - - * If this option takes a dict or list of dicts, you can define the structure here. - -Sample specification --------------------- - -.. code-block:: yaml - - # roles/myapp/meta/argument_specs.yml - --- - argument_specs: - # roles/myapp/tasks/main.yml entry point - main: - short_description: The main entry point for the myapp role. - options: - myapp_int: - type: "int" - required: false - default: 42 - description: "The integer value, defaulting to 42." - - myapp_str: - type: "str" - required: true - description: "The string value" - - # roles/myapp/tasks/alternate.yml entry point - alternate: - short_description: The alternate entry point for the myapp role. - options: - myapp_int: - type: "int" - required: false - default: 1024 - description: "The integer value, defaulting to 1024." - -.. _run_role_twice: - -Running a role multiple times in one play -========================================= - -Ansible only executes each role once in a play, even if you define it multiple times, unless the parameters defined on the role are different for each definition. For example, Ansible only runs the role ``foo`` once in a play like this: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - foo - - bar - - foo - -You have two options to force Ansible to run a role more than once. - -Passing different parameters ----------------------------- - -If you pass different parameters in each role definition, Ansible runs the role more than once. Providing different variable values is not the same as passing different role parameters. You must use the ``roles`` keyword for this behavior, since ``import_role`` and ``include_role`` do not accept role parameters. - -This play runs the ``foo`` role twice: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - { role: foo, message: "first" } - - { role: foo, message: "second" } - -This syntax also runs the ``foo`` role twice; - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - role: foo - message: "first" - - role: foo - message: "second" - -In these examples, Ansible runs ``foo`` twice because each role definition has different parameters. - -Using ``allow_duplicates: true`` --------------------------------- - -Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role: - -.. code-block:: yaml - - # playbook.yml - --- - - hosts: webservers - roles: - - foo - - foo - - # roles/foo/meta/main.yml - --- - allow_duplicates: true - -In this example, Ansible runs ``foo`` twice because we have explicitly enabled it to do so. - -.. _role_dependencies: - -Using role dependencies -======================= - -Role dependencies let you automatically pull in other roles when using a role. - -Role dependencies are prerequisites, not true dependencies. The roles do not have a parent/child relationship. Ansible loads all listed roles, runs the roles listed under ``dependencies`` first, then runs the role that lists them. The play object is the parent of all roles, including roles called by a ``dependencies`` list. - -Role dependencies are stored in the ``meta/main.yml`` file within the role directory. This file should contain a list of roles and parameters to insert before the specified role. For example: - -.. code-block:: yaml - - # roles/myapp/meta/main.yml - --- - dependencies: - - role: common - vars: - some_parameter: 3 - - role: apache - vars: - apache_port: 80 - - role: postgres - vars: - dbname: blarg - other_parameter: 12 - -Ansible always executes roles listed in ``dependencies`` before the role that lists them. Ansible executes this pattern recursively when you use the ``roles`` keyword. For example, if you list role ``foo`` under ``roles:``, role ``foo`` lists role ``bar`` under ``dependencies`` in its meta/main.yml file, and role ``bar`` lists role ``baz`` under ``dependencies`` in its meta/main.yml, Ansible executes ``baz``, then ``bar``, then ``foo``. - -Running role dependencies multiple times in one play ----------------------------------------------------- - -Ansible treats duplicate role dependencies like duplicate roles listed under ``roles:``: Ansible only executes role dependencies once, even if defined multiple times, unless the parameters, tags, or when clause defined on the role are different for each definition. If two roles in a play both list a third role as a dependency, Ansible only runs that role dependency once, unless you pass different parameters, tags, when clause, or use ``allow_duplicates: true`` in the role you want to run multiple times. See :ref:`Galaxy role dependencies ` for more details. - -.. note:: - - Role deduplication does not consult the invocation signature of parent roles. Additionally, when using ``vars:`` instead of role params, there is a side effect of changing variable scoping. Using ``vars:`` results in those variables being scoped at the play level. In the below example, using ``vars:`` would cause ``n`` to be defined as ``4`` through the entire play, including roles called before it. - - In addition to the above, users should be aware that role de-duplication occurs before variable evaluation. This means that :term:`Lazy Evaluation` may make seemingly different role invocations equivalently the same, preventing the role from running more than once. - - -For example, a role named ``car`` depends on a role named ``wheel`` as follows: - -.. code-block:: yaml - - --- - dependencies: - - role: wheel - n: 1 - - role: wheel - n: 2 - - role: wheel - n: 3 - - role: wheel - n: 4 - -And the ``wheel`` role depends on two roles: ``tire`` and ``brake``. The ``meta/main.yml`` for wheel would then contain the following: - -.. code-block:: yaml - - --- - dependencies: - - role: tire - - role: brake - -And the ``meta/main.yml`` for ``tire`` and ``brake`` would contain the following: - -.. code-block:: yaml - - --- - allow_duplicates: true - -The resulting order of execution would be as follows: - -.. code-block:: text - - tire(n=1) - brake(n=1) - wheel(n=1) - tire(n=2) - brake(n=2) - wheel(n=2) - ... - car - -To use ``allow_duplicates: true`` with role dependencies, you must specify it for the role listed under ``dependencies``, not for the role that lists it. In the example above, ``allow_duplicates: true`` appears in the ``meta/main.yml`` of the ``tire`` and ``brake`` roles. The ``wheel`` role does not require ``allow_duplicates: true``, because each instance defined by ``car`` uses different parameter values. - -.. note:: - See :ref:`playbooks_variables` for details on how Ansible chooses among variable values defined in different places (variable inheritance and scope). - Also deduplication happens ONLY at the play level, so multiple plays in the same playbook may rerun the roles. - -.. _embedding_modules_and_plugins_in_roles: - -Embedding modules and plugins in roles -====================================== - -.. note:: - This applies only to standalone roles. Roles in collections do not support plugin embedding; they must use the collection's ``plugins`` structure to distribute plugins. - -If you write a custom module (see :ref:`developing_modules`) or a plugin (see :ref:`developing_plugins`), you might wish to distribute it as part of a role. For example, if you write a module that helps configure your company's internal software, and you want other people in your organization to use this module, but you do not want to tell everyone how to configure their Ansible library path, you can include the module in your internal_config role. - -To add a module or a plugin to a role: -Alongside the 'tasks' and 'handlers' structure of a role, add a directory named 'library' and then include the module directly inside the 'library' directory. - -Assuming you had this: - -.. code-block:: text - - roles/ - my_custom_modules/ - library/ - module1 - module2 - -The module will be usable in the role itself, as well as any roles that are called *after* this role, as follows: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - my_custom_modules - - some_other_role_using_my_custom_modules - - yet_another_role_using_my_custom_modules - -If necessary, you can also embed a module in a role to modify a module in Ansible's core distribution. For example, you can use the development version of a particular module before it is released in production releases by copying the module and embedding the copy in a role. Use this approach with caution, as API signatures may change in core components, and this workaround is not guaranteed to work. - -The same mechanism can be used to embed and distribute plugins in a role, using the same schema. For example, for a filter plugin: - -.. code-block:: text - - roles/ - my_custom_filter/ - filter_plugins - filter1 - filter2 - -These filters can then be used in a Jinja template in any role called after 'my_custom_filter'. - -Sharing roles: Ansible Galaxy -============================= - -`Ansible Galaxy `_ is a free site for finding, downloading, rating, and reviewing all kinds of community-developed Ansible roles and can be a great way to get a jumpstart on your automation projects. - -The client ``ansible-galaxy`` is included in Ansible. The Galaxy client allows you to download roles from Ansible Galaxy and provides an excellent default framework for creating your own roles. - -Read the `Ansible Galaxy documentation `_ page for more information. A page that refers back to this one frequently is the Galaxy Roles document which explains the required metadata your role needs for use in Galaxy . - -.. seealso:: - - :ref:`ansible_galaxy` - How to create new roles, share roles on Galaxy, role management - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic Playbook language features - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`playbooks_variables` - Variables in playbooks - :ref:`playbooks_conditionals` - Conditionals in playbooks - :ref:`playbooks_loops` - Loops in playbooks - :ref:`tags` - Using tags to select or skip roles/tasks in long playbooks - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Extending Ansible by writing your own modules - `GitHub Ansible examples `_ - Complete playbook files from the GitHub project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/playbook_guide/playbooks_roles.rst b/docs/docsite/rst/playbook_guide/playbooks_roles.rst deleted file mode 100644 index f79e23087d5..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_roles.rst +++ /dev/null @@ -1,19 +0,0 @@ -:orphan: - -Playbook Roles and Include Statements -===================================== - -.. contents:: Topics - - -The documentation regarding roles and includes for playbooks have moved. Their new location is here: :ref:`playbooks_reuse`. Please update any links you may have made directly to this page. - -.. seealso:: - - :ref:`ansible_galaxy` - How to share roles on galaxy, role management - :ref:`working_with_playbooks` - Review the basic Playbook language features - :ref:`playbooks_reuse` - Creating reusable Playbooks. - diff --git a/docs/docsite/rst/playbook_guide/playbooks_special_topics.rst b/docs/docsite/rst/playbook_guide/playbooks_special_topics.rst deleted file mode 100644 index 5df72c11d96..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_special_topics.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -.. _playbooks_special_topics: - -Advanced playbooks features -=========================== - -This page is obsolete. Refer to the :ref:`main User Guide index page ` for links to all playbook-related topics. Please update any links you may have made directly to this page. diff --git a/docs/docsite/rst/playbook_guide/playbooks_startnstep.rst b/docs/docsite/rst/playbook_guide/playbooks_startnstep.rst deleted file mode 100644 index e6c78d24edd..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_startnstep.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. _playbooks_start_and_step: - -*************************************** -Executing playbooks for troubleshooting -*************************************** - -When you are testing new plays or debugging playbooks, you may need to run the same play multiple times. To make this more efficient, Ansible offers two alternative ways to execute a playbook: start-at-task and step mode. - -.. _start_at_task: - -start-at-task -------------- - -To start executing your playbook at a particular task (usually the task that failed on the previous run), use the ``--start-at-task`` option. - -.. code-block:: shell - - ansible-playbook playbook.yml --start-at-task="install packages" - -In this example, Ansible starts executing your playbook at a task named "install packages". This feature does not work with tasks inside dynamically re-used roles or tasks (``include_*``), see :ref:`dynamic_vs_static`. - -.. _step: - -Step mode ---------- - -To execute a playbook interactively, use ``--step``. - -.. code-block:: shell - - ansible-playbook playbook.yml --step - -With this option, Ansible stops on each task, and asks if it should execute that task. For example, if you have a task called "configure ssh", the playbook run will stop and ask. - -.. code-block:: shell - - Perform task: configure ssh (y/n/c): - -Answer "y" to execute the task, answer "n" to skip the task, and answer "c" to exit step mode, executing all remaining tasks without asking. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbook_debugger` - Using the Ansible debugger diff --git a/docs/docsite/rst/playbook_guide/playbooks_strategies.rst b/docs/docsite/rst/playbook_guide/playbooks_strategies.rst deleted file mode 100644 index 43d1605c332..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_strategies.rst +++ /dev/null @@ -1,254 +0,0 @@ -.. _playbooks_strategies: - -Controlling playbook execution: strategies and more -=================================================== - -By default, Ansible runs each task on all hosts affected by a play before starting the next task on any host, using 5 forks. If you want to change this default behavior, you can use a different strategy plugin, change the number of forks, or apply one of several keywords like ``serial``. - -.. contents:: - :local: - -Selecting a strategy --------------------- -The default behavior described above is the :ref:`linear strategy`. Ansible offers other strategies, including the :ref:`debug strategy` (see also :ref:`playbook_debugger`) and the :ref:`free strategy`, which allows each host to run until the end of the play as fast as it can: - -.. code-block:: yaml - - - hosts: all - strategy: free - tasks: - # ... - -You can select a different strategy for each play as shown above, or set your preferred strategy globally in ``ansible.cfg``, under the ``defaults`` stanza: - -.. code-block:: ini - - [defaults] - strategy = free - -All strategies are implemented as :ref:`strategy plugins`. Please review the documentation for each strategy plugin for details on how it works. - -Setting the number of forks ---------------------------- -If you have the processing power available and want to use more forks, you can set the number in ``ansible.cfg``: - -.. code-block:: ini - - [defaults] - forks = 30 - -or pass it on the command line: `ansible-playbook -f 30 my_playbook.yml`. - -Using keywords to control execution ------------------------------------ - -In addition to strategies, several :ref:`keywords` also affect play execution. You can set a number, a percentage, or a list of numbers of hosts you want to manage at a time with ``serial``. Ansible completes the play on the specified number or percentage of hosts before starting the next batch of hosts. You can restrict the number of workers allotted to a block or task with ``throttle``. You can control how Ansible selects the next host in a group to execute against with ``order``. You can run a task on a single host with ``run_once``. These keywords are not strategies. They are directives or options applied to a play, block, or task. - -Other keywords that affect play execution include ``ignore_errors``, ``ignore_unreachable``, and ``any_errors_fatal``. These options are documented in :ref:`playbooks_error_handling`. - -.. _rolling_update_batch_size: - -Setting the batch size with ``serial`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible runs in parallel against all the hosts in the :ref:`pattern ` you set in the ``hosts:`` field of each play. If you want to manage only a few machines at a time, for example during a rolling update, you can define how many hosts Ansible should manage at a single time using the ``serial`` keyword: - -.. code-block:: yaml - - - --- - - name: test play - hosts: webservers - serial: 3 - gather_facts: False - - tasks: - - name: first task - command: hostname - - name: second task - command: hostname - -In the above example, if we had 6 hosts in the group 'webservers', Ansible would execute the play completely (both tasks) on 3 of the hosts before moving on to the next 3 hosts: - -.. code-block:: ansible-output - - PLAY [webservers] **************************************** - - TASK [first task] **************************************** - changed: [web3] - changed: [web2] - changed: [web1] - - TASK [second task] *************************************** - changed: [web1] - changed: [web2] - changed: [web3] - - PLAY [webservers] **************************************** - - TASK [first task] **************************************** - changed: [web4] - changed: [web5] - changed: [web6] - - TASK [second task] *************************************** - changed: [web4] - changed: [web5] - changed: [web6] - - PLAY RECAP *********************************************** - web1 : ok=2 changed=2 unreachable=0 failed=0 - web2 : ok=2 changed=2 unreachable=0 failed=0 - web3 : ok=2 changed=2 unreachable=0 failed=0 - web4 : ok=2 changed=2 unreachable=0 failed=0 - web5 : ok=2 changed=2 unreachable=0 failed=0 - web6 : ok=2 changed=2 unreachable=0 failed=0 - - -.. note:: - Setting the batch size with ``serial`` changes the scope of the Ansible failures to the batch size, not the entire host list. You can use :ref:`ignore_unreachable ` or :ref:`max_fail_percentage ` to modify this behavior. - -You can also specify a percentage with the ``serial`` keyword. Ansible applies the percentage to the total number of hosts in a play to determine the number of hosts per pass: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: "30%" - -If the number of hosts does not divide equally into the number of passes, the final pass contains the remainder. In this example, if you had 20 hosts in the webservers group, the first batch would contain 6 hosts, the second batch would contain 6 hosts, the third batch would contain 6 hosts, and the last batch would contain 2 hosts. - -You can also specify batch sizes as a list. For example: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: - - 1 - - 5 - - 10 - -In the above example, the first batch would contain a single host, the next would contain 5 hosts, and (if there are any hosts left), every following batch would contain either 10 hosts or all the remaining hosts, if fewer than 10 hosts remained. - -You can list multiple batch sizes as percentages: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: - - "10%" - - "20%" - - "100%" - -You can also mix and match the values: - -.. code-block:: yaml - - --- - - name: test play - hosts: webservers - serial: - - 1 - - 5 - - "20%" - -.. note:: - No matter how small the percentage, the number of hosts per pass will always be 1 or greater. - -Restricting execution with ``throttle`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``throttle`` keyword limits the number of workers for a particular task. It can be set at the block and task level. Use ``throttle`` to restrict tasks that may be CPU-intensive or interact with a rate-limiting API: - -.. code-block:: yaml - - tasks: - - command: /path/to/cpu_intensive_command - throttle: 1 - -If you have already restricted the number of forks or the number of machines to execute against in parallel, you can reduce the number of workers with ``throttle``, but you cannot increase it. In other words, to have an effect, your ``throttle`` setting must be lower than your ``forks`` or ``serial`` setting if you are using them together. - -Ordering execution based on inventory -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``order`` keyword controls the order in which hosts are run. Possible values for order are: - -inventory: - (default) The order provided by the inventory for the selection requested (see note below) -reverse_inventory: - The same as above, but reversing the returned list -sorted: - Sorted alphabetically sorted by name -reverse_sorted: - Sorted by name in reverse alphabetical order -shuffle: - Randomly ordered on each run - -.. note:: - the 'inventory' order does not equate to the order in which hosts/groups are defined in the inventory source file, but the 'order in which a selection is returned from the compiled inventory'. This is a backwards compatible option and while reproducible it is not normally predictable. Due to the nature of inventory, host patterns, limits, inventory plugins and the ability to allow multiple sources it is almost impossible to return such an order. For simple cases this might happen to match the file definition order, but that is not guaranteed. - -.. _run_once: - -Running on a single machine with ``run_once`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want a task to run only on the first host in your batch of hosts, set ``run_once`` to true on that task: - -.. code-block:: yaml - - --- - # ... - - tasks: - - # ... - - - command: /opt/application/upgrade_db.py - run_once: true - - # ... - -Ansible executes this task on the first host in the current batch and applies all results and facts to all the hosts in the same batch. This approach is similar to applying a conditional to a task such as: - -.. code-block:: yaml - - - command: /opt/application/upgrade_db.py - when: inventory_hostname == webservers[0] - -However, with ``run_once``, the results are applied to all the hosts. To run the task on a specific host, instead of the first host in the batch, delegate the task: - -.. code-block:: yaml - - - command: /opt/application/upgrade_db.py - run_once: true - delegate_to: web01.example.org - -As always with :ref:`delegation `, the action will be executed on the delegated host, but the information is still that of the original host in the task. - -.. note:: - When used together with ``serial``, tasks marked as ``run_once`` will be run on one host in *each* serial batch. If the task must run only once regardless of ``serial`` mode, use - :code:`when: inventory_hostname == ansible_play_hosts_all[0]` construct. - -.. note:: - Any conditional (in other words, `when:`) will use the variables of the 'first host' to decide if the task runs or not, no other hosts will be tested. - -.. note:: - If you want to avoid the default behavior of setting the fact for all hosts, set ``delegate_facts: True`` for the specific task or block. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_delegation` - Running tasks on or assigning facts to specific machines - :ref:`playbooks_reuse_roles` - Playbook organization by roles - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_tags.rst b/docs/docsite/rst/playbook_guide/playbooks_tags.rst deleted file mode 100644 index deff48bd904..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_tags.rst +++ /dev/null @@ -1,432 +0,0 @@ -.. _tags: - -**** -Tags -**** - -If you have a large playbook, it may be useful to run only specific parts of it instead of running the entire playbook. You can do this with Ansible tags. Using tags to execute or skip selected tasks is a two-step process: - - #. Add tags to your tasks, either individually or with tag inheritance from a block, play, role, or import. - #. Select or skip tags when you run your playbook. - -.. contents:: - :local: - -Adding tags with the tags keyword -================================= - -You can add tags to a single task or include. You can also add tags to multiple tasks by defining them at the level of a block, play, role, or import. The keyword ``tags`` addresses all these use cases. The ``tags`` keyword always defines tags and adds them to tasks; it does not select or skip tasks for execution. You can only select or skip tasks based on tags at the command line when you run a playbook. See :ref:`using_tags` for more details. - -Adding tags to individual tasks -------------------------------- - -At the simplest level, you can apply one or more tags to an individual task. You can add tags to tasks in playbooks, in task files, or within a role. Here is an example that tags two tasks with different tags: - -.. code-block:: yaml - - tasks: - - name: Install the servers - ansible.builtin.yum: - name: - - httpd - - memcached - state: present - tags: - - packages - - webservers - - - name: Configure the service - ansible.builtin.template: - src: templates/src.j2 - dest: /etc/foo.conf - tags: - - configuration - -You can apply the same tag to more than one individual task. This example tags several tasks with the same tag, "ntp": - -.. code-block:: yaml - - --- - # file: roles/common/tasks/main.yml - - - name: Install ntp - ansible.builtin.yum: - name: ntp - state: present - tags: ntp - - - name: Configure ntp - ansible.builtin.template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - tags: ntp - - - name: Enable and run ntpd - ansible.builtin.service: - name: ntpd - state: started - enabled: true - tags: ntp - - - name: Install NFS utils - ansible.builtin.yum: - name: - - nfs-utils - - nfs-util-lib - state: present - tags: filesharing - -If you ran these four tasks in a playbook with ``--tags ntp``, Ansible would run the three tasks tagged ``ntp`` and skip the one task that does not have that tag. - -.. _tags_on_includes: - -Adding tags to includes ------------------------ - -You can apply tags to dynamic includes in a playbook. As with tags on an individual task, tags on an ``include_*`` task apply only to the include itself, not to any tasks within the included file or role. If you add ``mytag`` to a dynamic include, then run that playbook with ``--tags mytag``, Ansible runs the include itself, runs any tasks within the included file or role tagged with ``mytag``, and skips any tasks within the included file or role without that tag. See :ref:`selective_reuse` for more details. - -You add tags to includes the same way you add tags to any other task: - -.. code-block:: yaml - - --- - # file: roles/common/tasks/main.yml - - - name: Dynamic re-use of database tasks - include_tasks: db.yml - tags: db - -You can add a tag only to the dynamic include of a role. In this example, the ``foo`` tag will `not` apply to tasks inside the ``bar`` role: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Include the bar role - include_role: - name: bar - tags: - - foo - -With plays, blocks, the ``role`` keyword, and static imports, Ansible applies tag inheritance, adding the tags you define to every task inside the play, block, role, or imported file. However, tag inheritance does *not* apply to dynamic re-use with ``include_role`` and ``include_tasks``. With dynamic re-use (includes), the tags you define apply only to the include itself. If you need tag inheritance, use a static import. If you cannot use an import because the rest of your playbook uses includes, see :ref:`apply_keyword` for ways to work around this behavior. - -.. _tag_inheritance: - -Tag inheritance: adding tags to multiple tasks ----------------------------------------------- - -If you want to apply the same tag or tags to multiple tasks without adding a ``tags`` line to every task, you can define the tags at the level of your play or block, or when you add a role or import a file. Ansible applies the tags down the dependency chain to all child tasks. With roles and imports, Ansible appends the tags set by the ``roles`` section or import to any tags set on individual tasks or blocks within the role or imported file. This is called tag inheritance. Tag inheritance is convenient, because you do not have to tag every task. However, the tags still apply to the tasks individually. - -Adding tags to blocks -^^^^^^^^^^^^^^^^^^^^^ - -If you want to apply a tag to many, but not all, of the tasks in your play, use a :ref:`block ` and define the tags at that level. For example, we could edit the NTP example shown above to use a block: - -.. code-block:: yaml - - # myrole/tasks/main.yml - - name: ntp tasks - tags: ntp - block: - - name: Install ntp - ansible.builtin.yum: - name: ntp - state: present - - - name: Configure ntp - ansible.builtin.template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - - - name: Enable and run ntpd - ansible.builtin.service: - name: ntpd - state: started - enabled: true - - - name: Install NFS utils - ansible.builtin.yum: - name: - - nfs-utils - - nfs-util-lib - state: present - tags: filesharing - -Adding tags to plays -^^^^^^^^^^^^^^^^^^^^ - -If all the tasks in a play should get the same tag, you can add the tag at the level of the play. For example, if you had a play with only the NTP tasks, you could tag the entire play: - -.. code-block:: yaml - - - hosts: all - tags: ntp - tasks: - - name: Install ntp - ansible.builtin.yum: - name: ntp - state: present - - - name: Configure ntp - ansible.builtin.template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - - - name: Enable and run ntpd - ansible.builtin.service: - name: ntpd - state: started - enabled: true - - - hosts: fileservers - tags: filesharing - tasks: - ... - -Adding tags to roles -^^^^^^^^^^^^^^^^^^^^ - -There are three ways to add tags to roles: - - #. Add the same tag or tags to all tasks in the role by setting tags under ``roles``. See examples in this section. - #. Add the same tag or tags to all tasks in the role by setting tags on a static ``import_role`` in your playbook. See examples in :ref:`tags_on_imports`. - #. Add a tag or tags to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role. To select or skip tasks within the role, you must have tags set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the same tag or tags to the include. When you use this approach, and then run your playbook with ``--tags foo``, Ansible runs the include itself plus any tasks in the role that also have the tag ``foo``. See :ref:`tags_on_includes` for details. - -When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds any tags you define to all the tasks in the role. For example: - -.. code-block:: yaml - - roles: - - role: webserver - vars: - port: 5000 - tags: [ web, foo ] - -or: - -.. code-block:: yaml - - --- - - hosts: webservers - roles: - - role: foo - tags: - - bar - - baz - # using YAML shorthand, this is equivalent to: - # - { role: foo, tags: ["bar", "baz"] } - -.. _tags_on_imports: - -Adding tags to imports -^^^^^^^^^^^^^^^^^^^^^^ - -You can also apply a tag or tags to all the tasks imported by the static ``import_role`` and ``import_tasks`` statements: - -.. code-block:: yaml - - --- - - hosts: webservers - tasks: - - name: Import the foo role - import_role: - name: foo - tags: - - bar - - baz - - - name: Import tasks from foo.yml - import_tasks: foo.yml - tags: [ web, foo ] - -.. _apply_keyword: - -Tag inheritance for includes: blocks and the ``apply`` keyword -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, Ansible does not apply :ref:`tag inheritance ` to dynamic re-use with ``include_role`` and ``include_tasks``. If you add tags to an include, they apply only to the include itself, not to any tasks in the included file or role. This allows you to execute selected tasks within a role or task file - see :ref:`selective_reuse` when you run your playbook. - -If you want tag inheritance, you probably want to use imports. However, using both includes and imports in a single playbook can lead to difficult-to-diagnose bugs. For this reason, if your playbook uses ``include_*`` to re-use roles or tasks, and you need tag inheritance on one include, Ansible offers two workarounds. You can use the ``apply`` keyword: - -.. code-block:: yaml - - - name: Apply the db tag to the include and to all tasks in db.yml - include_tasks: - file: db.yml - # adds 'db' tag to tasks within db.yml - apply: - tags: db - # adds 'db' tag to this 'include_tasks' itself - tags: db - -Or you can use a block: - -.. code-block:: yaml - - - block: - - name: Include tasks from db.yml - include_tasks: db.yml - tags: db - -.. _special_tags: - -Special tags: always and never -============================== - -Ansible reserves two tag names for special behavior: always and never. If you assign the ``always`` tag to a task or play, Ansible will always run that task or play, unless you specifically skip it (``--skip-tags always``). - -For example: - -.. code-block:: yaml - - tasks: - - name: Print a message - ansible.builtin.debug: - msg: "Always runs" - tags: - - always - - - name: Print a message - ansible.builtin.debug: - msg: "runs when you use tag1" - tags: - - tag1 - -.. warning:: - * Fact gathering is tagged with 'always' by default. It is only skipped if - you apply a tag to the play and then use a different tag in ``--tags`` or the same - tag in ``--skip-tags``. - -.. warning:: - * The role argument specification validation task is tagged with 'always' by default. This validation - will be skipped if you use ``--skip-tags always``. - -.. versionadded:: 2.5 - -If you assign the ``never`` tag to a task or play, Ansible will skip that task or play unless you specifically request it (``--tags never``). - -For example: - -.. code-block:: yaml - - tasks: - - name: Run the rarely-used debug task - ansible.builtin.debug: - msg: '{{ showmevar }}' - tags: [ never, debug ] - -The rarely-used debug task in the example above only runs when you specifically request the ``debug`` or ``never`` tags. - -.. _using_tags: - -Selecting or skipping tags when you run a playbook -================================================== - -Once you have added tags to your tasks, includes, blocks, plays, roles, and imports, you can selectively execute or skip tasks based on their tags when you run :ref:`ansible-playbook`. Ansible runs or skips all tasks with tags that match the tags you pass at the command line. If you have added a tag at the block or play level, with ``roles``, or with an import, that tag applies to every task within the block, play, role, or imported role or file. If you have a role with lots of tags and you want to call subsets of the role at different times, either :ref:`use it with dynamic includes `, or split the role into multiple roles. - -:ref:`ansible-playbook` offers five tag-related command-line options: - -* ``--tags all`` - run all tasks, ignore tags (default behavior) -* ``--tags [tag1, tag2]`` - run only tasks with either the tag ``tag1`` or the tag ``tag2`` -* ``--skip-tags [tag3, tag4]`` - run all tasks except those with either the tag ``tag3`` or the tag ``tag4`` -* ``--tags tagged`` - run only tasks with at least one tag -* ``--tags untagged`` - run only tasks with no tags - -For example, to run only tasks and blocks tagged either ``configuration`` or ``packages`` in a very long playbook: - -.. code-block:: bash - - ansible-playbook example.yml --tags "configuration,packages" - -To run all tasks except those tagged ``packages``: - -.. code-block:: bash - - ansible-playbook example.yml --skip-tags "packages" - -Previewing the results of using tags ------------------------------------- - -When you run a role or playbook, you might not know or remember which tasks have which tags, or which tags exist at all. Ansible offers two command-line flags for :ref:`ansible-playbook` that help you manage tagged playbooks: - -* ``--list-tags`` - generate a list of available tags -* ``--list-tasks`` - when used with ``--tags tagname`` or ``--skip-tags tagname``, generate a preview of tagged tasks - -For example, if you do not know whether the tag for configuration tasks is ``config`` or ``conf`` in a playbook, role, or tasks file, you can display all available tags without running any tasks: - -.. code-block:: bash - - ansible-playbook example.yml --list-tags - -If you do not know which tasks have the tags ``configuration`` and ``packages``, you can pass those tags and add ``--list-tasks``. Ansible lists the tasks but does not execute any of them. - -.. code-block:: bash - - ansible-playbook example.yml --tags "configuration,packages" --list-tasks - -These command-line flags have one limitation: they cannot show tags or tasks within dynamically included files or roles. See :ref:`dynamic_vs_static` for more information on differences between static imports and dynamic includes. - -.. _selective_reuse: - -Selectively running tagged tasks in re-usable files ---------------------------------------------------- - -If you have a role or a tasks file with tags defined at the task or block level, you can selectively run or skip those tagged tasks in a playbook if you use a dynamic include instead of a static import. You must use the same tag on the included tasks and on the include statement itself. For example you might create a file with some tagged and some untagged tasks: - -.. code-block:: yaml - - # mixed.yml - tasks: - - name: Run the task with no tags - ansible.builtin.debug: - msg: this task has no tags - - - name: Run the tagged task - ansible.builtin.debug: - msg: this task is tagged with mytag - tags: mytag - - - block: - - name: Run the first block task with mytag - ... - - name: Run the second block task with mytag - ... - tags: - - mytag - -And you might include the tasks file above in a playbook: - -.. code-block:: yaml - - # myplaybook.yml - - hosts: all - tasks: - - name: Run tasks from mixed.yml - include_tasks: - name: mixed.yml - tags: mytag - -When you run the playbook with ``ansible-playbook -i hosts myplaybook.yml --tags "mytag"``, Ansible skips the task with no tags, runs the tagged individual task, and runs the two tasks in the block. - -Configuring tags globally -------------------------- - -If you run or skip certain tags by default, you can use the :ref:`TAGS_RUN` and :ref:`TAGS_SKIP` options in Ansible configuration to set those defaults. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_templating.rst b/docs/docsite/rst/playbook_guide/playbooks_templating.rst deleted file mode 100644 index 4382f1573b0..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_templating.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. _playbooks_templating: - -******************* -Templating (Jinja2) -******************* - -Ansible uses Jinja2 templating to enable dynamic expressions and access to :ref:`variables ` and :ref:`facts `. -You can use templating with the :ref:`template module `. -For example, you can create a template for a configuration file, then deploy that configuration file to multiple environments and supply the correct data (IP address, hostname, version) for each environment. -You can also use templating in playbooks directly, by templating task names and more. -You can use all the :ref:`standard filters and tests ` included in Jinja2. -Ansible includes additional specialized filters for selecting and transforming data, tests for evaluating template expressions, and :ref:`lookup_plugins` for retrieving data from external sources such as files, APIs, and databases for use in templating. - -All templating happens on the Ansible controller **before** the task is sent and executed on the target machine. -This approach minimizes the package requirements on the target (jinja2 is only required on the controller). -It also limits the amount of data Ansible passes to the target machine. -Ansible parses templates on the controller and passes only the information needed for each task to the target machine, instead of passing all the data on the controller and parsing it on the target. - -.. note:: - - Files and data used by the :ref:`template module ` must be utf-8 encoded. - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbook_tips` - Tips and tricks for playbooks - `Jinja2 Docs `_ - Jinja2 documentation, includes the syntax and semantics of the templates - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_templating_now.rst b/docs/docsite/rst/playbook_guide/playbooks_templating_now.rst deleted file mode 100644 index 1ca608016f5..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_templating_now.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _templating_now: - -The now function: get the current time -====================================== - -.. versionadded:: 2.8 - -The ``now()`` Jinja2 function retrieves a Python datetime object or a string representation for the current time. - -The ``now()`` function supports 2 arguments: - -utc - Specify ``True`` to get the current time in UTC. Defaults to ``False``. - -fmt - Accepts a `strftime `_ string that returns a formatted date time string. \ No newline at end of file diff --git a/docs/docsite/rst/playbook_guide/playbooks_tests.rst b/docs/docsite/rst/playbook_guide/playbooks_tests.rst deleted file mode 100644 index ccf6f9e642d..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_tests.rst +++ /dev/null @@ -1,542 +0,0 @@ -.. _playbooks_tests: - -***** -Tests -***** - -`Tests `_ in Jinja are a way of evaluating template expressions and returning True or False. Jinja ships with many of these. See `builtin tests`_ in the official Jinja template documentation. - -The main difference between tests and filters are that Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. Tests can also be used in list processing filters, like ``map()`` and ``select()`` to choose items in the list. - -Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data. - -In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own. - -.. contents:: - :local: - -.. _test_syntax: - -Test syntax -=========== - -`Test syntax `_ varies from `filter syntax `_ (``variable | filter``). Historically Ansible has registered tests as both jinja tests and jinja filters, allowing for them to be referenced using filter syntax. - -As of Ansible 2.5, using a jinja test as a filter will generate a deprecation warning. As of Ansible 2.9+ using jinja test syntax is required. - -The syntax for using a jinja test is as follows - -.. code-block:: console - - variable is test_name - -Such as - -.. code-block:: console - - result is failed - -.. _testing_strings: - -Testing strings -=============== - -To match strings against a substring or a regular expression, use the ``match``, ``search`` or ``regex`` tests - -.. code-block:: yaml - - vars: - url: "https://example.com/users/foo/resources/bar" - - tasks: - - debug: - msg: "matched pattern 1" - when: url is match("https://example.com/users/.*/resources") - - - debug: - msg: "matched pattern 2" - when: url is search("users/.*/resources/.*") - - - debug: - msg: "matched pattern 3" - when: url is search("users") - - - debug: - msg: "matched pattern 4" - when: url is regex("example\.com/\w+/foo") - -``match`` succeeds if it finds the pattern at the beginning of the string, while ``search`` succeeds if it finds the pattern anywhere within string. By default, ``regex`` works like ``search``, but ``regex`` can be configured to perform other tests as well, by passing the ``match_type`` keyword argument. In particular, ``match_type`` determines the ``re`` method that gets used to perform the search. The full list can be found in the relevant Python documentation `here `_. - -All of the string tests also take optional ``ignorecase`` and ``multiline`` arguments. These correspond to ``re.I`` and ``re.M`` from Python's ``re`` library, respectively. - -.. _testing_vault: - -Vault -===== - -.. versionadded:: 2.10 - -You can test whether a variable is an inline single vault encrypted value using the ``vault_encrypted`` test. - -.. code-block:: yaml - - vars: - variable: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 61323931353866666336306139373937316366366138656131323863373866376666353364373761 - 3539633234313836346435323766306164626134376564330a373530313635343535343133316133 - 36643666306434616266376434363239346433643238336464643566386135356334303736353136 - 6565633133366366360a326566323363363936613664616364623437336130623133343530333739 - 3039 - - tasks: - - debug: - msg: '{{ (variable is vault_encrypted) | ternary("Vault encrypted", "Not vault encrypted") }}' - -.. _testing_truthiness: - -Testing truthiness -================== - -.. versionadded:: 2.10 - -As of Ansible 2.10, you can now perform Python like truthy and falsy checks. - -.. code-block:: yaml - - - debug: - msg: "Truthy" - when: value is truthy - vars: - value: "some string" - - - debug: - msg: "Falsy" - when: value is falsy - vars: - value: "" - -Additionally, the ``truthy`` and ``falsy`` tests accept an optional parameter called ``convert_bool`` that will attempt -to convert boolean indicators to actual booleans. - -.. code-block:: yaml - - - debug: - msg: "Truthy" - when: value is truthy(convert_bool=True) - vars: - value: "yes" - - - debug: - msg: "Falsy" - when: value is falsy(convert_bool=True) - vars: - value: "off" - -.. _testing_versions: - -Comparing versions -================== - -.. versionadded:: 1.6 - -.. note:: In 2.5 ``version_compare`` was renamed to ``version`` - -To compare a version number, such as checking if the ``ansible_facts['distribution_version']`` -version is greater than or equal to '12.04', you can use the ``version`` test. - -The ``version`` test can also be used to evaluate the ``ansible_facts['distribution_version']`` - -.. code-block:: yaml+jinja - - {{ ansible_facts['distribution_version'] is version('12.04', '>=') }} - -If ``ansible_facts['distribution_version']`` is greater than or equal to 12.04, this test returns True, otherwise False. - -The ``version`` test accepts the following operators - -.. code-block:: console - - <, lt, <=, le, >, gt, >=, ge, ==, =, eq, !=, <>, ne - -This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing as defined by ``ansible.module_utils.compat.version.StrictVersion`` should be used. The default is ``False`` (using ``ansible.module_utils.compat.version.LooseVersion``), ``True`` enables strict version parsing - -.. code-block:: yaml+jinja - - {{ sample_version_var is version('1.0', operator='lt', strict=True) }} - -As of Ansible 2.11 the ``version`` test accepts a ``version_type`` parameter which is mutually exclusive with ``strict``, and accepts the following values - -.. code-block:: console - - loose, strict, semver, semantic, pep440 - -``loose`` - This type corresponds to the Python ``distutils.version.LooseVersion`` class. All version formats are valid for this type. The rules for comparison are simple and predictable, but may not always give expected results. - -``strict`` - This type corresponds to the Python ``distutils.version.StrictVersion`` class. A version number consists of two or three dot-separated numeric components, with an optional "pre-release" tag on the end. The pre-release tag consists of a single letter 'a' or 'b' followed by a number. If the numeric components of two version numbers are equal, then one with a pre-release tag will always be deemed earlier (lesser) than one without. - -``semver``/``semantic`` - This type implements the `Semantic Version `_ scheme for version comparison. - -``pep440`` - This type implements the Python `PEP-440 `_ versioning rules for version comparison. Added in version 2.14. - -Using ``version_type`` to compare a semantic version would be achieved like the following - -.. code-block:: yaml+jinja - - {{ sample_semver_var is version('2.0.0-rc.1+build.123', 'lt', version_type='semver') }} - -In Ansible 2.14, the ``pep440`` option for ``version_type`` was added, and the rules of this type are defined in `PEP-440 `_. The following example showcases how this type can differentiate pre-releases as being less than a general release. - -.. code-block:: yaml+jinja - - {{ '2.14.0rc1' is version('2.14.0', 'lt', version_type='pep440') }} - -When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the `FAQ `_ - -.. code-block:: yaml - - vars: - my_version: 1.2.3 - - tasks: - - debug: - msg: "my_version is higher than 1.0.0" - when: my_version is version('1.0.0', '>') - -.. _math_tests: - -Set theory tests -================ - -.. versionadded:: 2.1 - -.. note:: In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset`` - -To see if a list includes or is included by another list, you can use 'subset' and 'superset' - -.. code-block:: yaml - - vars: - a: [1,2,3,4,5] - b: [2,3] - tasks: - - debug: - msg: "A includes B" - when: a is superset(b) - - - debug: - msg: "B is included in A" - when: b is subset(a) - -.. _contains_test: - -Testing if a list contains a value -================================== - -.. versionadded:: 2.8 - -Ansible includes a ``contains`` test which operates similarly, but in reverse of the Jinja2 provided ``in`` test. -The ``contains`` test is designed to work with the ``select``, ``reject``, ``selectattr``, and ``rejectattr`` filters - -.. code-block:: yaml - - vars: - lacp_groups: - - master: lacp0 - network: 10.65.100.0/24 - gateway: 10.65.100.1 - dns4: - - 10.65.100.10 - - 10.65.100.11 - interfaces: - - em1 - - em2 - - - master: lacp1 - network: 10.65.120.0/24 - gateway: 10.65.120.1 - dns4: - - 10.65.100.10 - - 10.65.100.11 - interfaces: - - em3 - - em4 - - tasks: - - debug: - msg: "{{ (lacp_groups|selectattr('interfaces', 'contains', 'em1')|first).master }}" - -Testing if a list value is True -=============================== - -.. versionadded:: 2.4 - -You can use `any` and `all` to check if any or all elements in a list are true or not - -.. code-block:: yaml - - vars: - mylist: - - 1 - - "{{ 3 == 3 }}" - - True - myotherlist: - - False - - True - tasks: - - - debug: - msg: "all are true!" - when: mylist is all - - - debug: - msg: "at least one is true" - when: myotherlist is any - -.. _path_tests: - -Testing paths -============= - -.. note:: In 2.5 the following tests were renamed to remove the ``is_`` prefix - -The following tests can provide information about a path on the controller - -.. code-block:: yaml - - - debug: - msg: "path is a directory" - when: mypath is directory - - - debug: - msg: "path is a file" - when: mypath is file - - - debug: - msg: "path is a symlink" - when: mypath is link - - - debug: - msg: "path already exists" - when: mypath is exists - - - debug: - msg: "path is {{ (mypath is abs)|ternary('absolute','relative')}}" - - - debug: - msg: "path is the same file as path2" - when: mypath is same_file(path2) - - - debug: - msg: "path is a mount" - when: mypath is mount - - - debug: - msg: "path is a directory" - when: mypath is directory - vars: - mypath: /my/patth - - - debug: - msg: "path is a file" - when: "'/my/path' is file" - - -Testing size formats -==================== - -The ``human_readable`` and ``human_to_bytes`` functions let you test your -playbooks to make sure you are using the right size format in your tasks, and that -you provide Byte format to computers and human-readable format to people. - -Human readable --------------- - -Asserts whether the given string is human readable or not. - -For example - -.. code-block:: yaml+jinja - - - name: "Human Readable" - assert: - that: - - '"1.00 Bytes" == 1|human_readable' - - '"1.00 bits" == 1|human_readable(isbits=True)' - - '"10.00 KB" == 10240|human_readable' - - '"97.66 MB" == 102400000|human_readable' - - '"0.10 GB" == 102400000|human_readable(unit="G")' - - '"0.10 Gb" == 102400000|human_readable(isbits=True, unit="G")' - -This would result in - -.. code-block:: json - - { "changed": false, "msg": "All assertions passed" } - -Human to bytes --------------- - -Returns the given string in the Bytes format. - -For example - -.. code-block:: yaml+jinja - - - name: "Human to Bytes" - assert: - that: - - "{{'0'|human_to_bytes}} == 0" - - "{{'0.1'|human_to_bytes}} == 0" - - "{{'0.9'|human_to_bytes}} == 1" - - "{{'1'|human_to_bytes}} == 1" - - "{{'10.00 KB'|human_to_bytes}} == 10240" - - "{{ '11 MB'|human_to_bytes}} == 11534336" - - "{{ '1.1 GB'|human_to_bytes}} == 1181116006" - - "{{'10.00 Kb'|human_to_bytes(isbits=True)}} == 10240" - -This would result in - -.. code-block:: json - - { "changed": false, "msg": "All assertions passed" } - - -.. _test_task_results: - -Testing task results -==================== - -The following tasks are illustrative of the tests meant to check the status of tasks - -.. code-block:: yaml - - tasks: - - - shell: /usr/bin/foo - register: result - ignore_errors: True - - - debug: - msg: "it failed" - when: result is failed - - # in most cases you'll want a handler, but if you want to do something right now, this is nice - - debug: - msg: "it changed" - when: result is changed - - - debug: - msg: "it succeeded in Ansible >= 2.1" - when: result is succeeded - - - debug: - msg: "it succeeded" - when: result is success - - - debug: - msg: "it was skipped" - when: result is skipped - -.. note:: From 2.1, you can also use success, failure, change, and skip so that the grammar matches, for those who need to be strict about it. - -.. _type_tests: - -Type Tests -========== - -When looking to determine types, it may be tempting to use the ``type_debug`` filter and compare that to the string name of that type, however, you should instead use type test comparisons, such as: - -.. code-block:: yaml - - tasks: - - name: "String interpretation" - vars: - a_string: "A string" - a_dictionary: {"a": "dictionary"} - a_list: ["a", "list"] - assert: - that: - # Note that a string is classed as also being "iterable" and "sequence", but not "mapping" - - a_string is string and a_string is iterable and a_string is sequence and a_string is not mapping - - # Note that a dictionary is classed as not being a "string", but is "iterable", "sequence" and "mapping" - - a_dictionary is not string and a_dictionary is iterable and a_dictionary is mapping - - # Note that a list is classed as not being a "string" or "mapping" but is "iterable" and "sequence" - - a_list is not string and a_list is not mapping and a_list is iterable - - - name: "Number interpretation" - vars: - a_float: 1.01 - a_float_as_string: "1.01" - an_integer: 1 - an_integer_as_string: "1" - assert: - that: - # Both a_float and an_integer are "number", but each has their own type as well - - a_float is number and a_float is float - - an_integer is number and an_integer is integer - - # Both a_float_as_string and an_integer_as_string are not numbers - - a_float_as_string is not number and a_float_as_string is string - - an_integer_as_string is not number and a_float_as_string is string - - # a_float or a_float_as_string when cast to a float and then to a string should match the same value cast only to a string - - a_float | float | string == a_float | string - - a_float_as_string | float | string == a_float_as_string | string - - # Likewise an_integer and an_integer_as_string when cast to an integer and then to a string should match the same value cast only to an integer - - an_integer | int | string == an_integer | string - - an_integer_as_string | int | string == an_integer_as_string | string - - # However, a_float or a_float_as_string cast as an integer and then a string does not match the same value cast to a string - - a_float | int | string != a_float | string - - a_float_as_string | int | string != a_float_as_string | string - - # Again, Likewise an_integer and an_integer_as_string cast as a float and then a string does not match the same value cast to a string - - an_integer | float | string != an_integer | string - - an_integer_as_string | float | string != an_integer_as_string | string - - - name: "Native Boolean interpretation" - loop: - - yes - - true - - True - - TRUE - - no - - No - - NO - - false - - False - - FALSE - assert: - that: - # Note that while other values may be cast to boolean values, these are the only ones which are natively considered boolean - # Note also that `yes` is the only case sensitive variant of these values. - - item is boolean - -.. _builtin tests: https://jinja.palletsprojects.com/en/latest/templates/#builtin-tests - -.. seealso:: - - :ref:`playbooks_intro` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_variables` - All about variables - :ref:`playbooks_loops` - Looping in playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_variables.rst b/docs/docsite/rst/playbook_guide/playbooks_variables.rst deleted file mode 100644 index 9482845dfd9..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_variables.rst +++ /dev/null @@ -1,534 +0,0 @@ -.. _playbooks_variables: - -*************** -Using Variables -*************** - -Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple different systems with a single command. To represent the variations among those different systems, you can create variables with standard YAML syntax, including lists and dictionaries. You can define these variables in your playbooks, in your :ref:`inventory `, in re-usable :ref:`files ` or :ref:`roles `, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable. - -After you create variables, either by defining them in a file, passing them at the command line, or registering the return value or values of a task as a new variable, you can use those variables in module arguments, in :ref:`conditional "when" statements `, in :ref:`templates `, and in :ref:`loops `. The `ansible-examples github repository `_ contains many examples of using variables in Ansible. - -Once you understand the concepts and examples on this page, read about :ref:`Ansible facts `, which are variables you retrieve from remote systems. - -.. contents:: - :local: - -.. _valid_variable_names: - -Creating valid variable names -============================= - -Not all strings are valid Ansible variable names. A variable name can only include letters, numbers, and underscores. `Python keywords`_ or :ref:`playbook keywords` are not valid variable names. A variable name cannot begin with a number. - -Variable names can begin with an underscore. In many programming languages, variables that begin with an underscore are private. This is not true in Ansible. Variables that begin with an underscore are treated exactly the same as any other variable. Do not rely on this convention for privacy or security. - -This table gives examples of valid and invalid variable names: - -.. table:: - :class: documentation-table - - ====================== ==================================================================== - Valid variable names Not valid - ====================== ==================================================================== - ``foo`` ``*foo``, `Python keywords`_ such as ``async`` and ``lambda`` - - ``foo_env`` :ref:`playbook keywords` such as ``environment`` - - ``foo_port`` ``foo-port``, ``foo port``, ``foo.port`` - - ``foo5``, ``_foo`` ``5foo``, ``12`` - ====================== ==================================================================== - -.. _Python keywords: https://docs.python.org/3/reference/lexical_analysis.html#keywords - -Simple variables -================ - -Simple variables combine a variable name with a single value. You can use this syntax (and the syntax for lists and dictionaries shown below) in a variety of places. For details about setting variables in inventory, in playbooks, in reusable files, in roles, or at the command line, see :ref:`setting_variables`. - -Defining simple variables -------------------------- - -You can define a simple variable using standard YAML syntax. For example: - -.. code-block:: text - - remote_install_path: /opt/my_app_config - -Referencing simple variables ----------------------------- - -After you define a variable, use Jinja2 syntax to reference it. Jinja2 variables use double curly braces. For example, the expression ``My amp goes to {{ max_amp_value }}`` demonstrates the most basic form of variable substitution. You can use Jinja2 syntax in playbooks. For example: - -.. code-block:: yaml+jinja - - ansible.builtin.template: - src: foo.cfg.j2 - dest: '{{ remote_install_path }}/foo.cfg' - -In this example, the variable defines the location of a file, which can vary from one system to another. - -.. note:: - - Ansible allows Jinja2 loops and conditionals in :ref:`templates ` but not in playbooks. You cannot create a loop of tasks. Ansible playbooks are pure machine-parseable YAML. - -.. _yaml_gotchas: - -When to quote variables (a YAML gotcha) -======================================= - -If you start a value with ``{{ foo }}``, you must quote the whole expression to create valid YAML syntax. If you do not quote the whole expression, the YAML parser cannot interpret the syntax - it might be a variable or it might be the start of a YAML dictionary. For guidance on writing YAML, see the :ref:`yaml_syntax` documentation. - -If you use a variable without quotes like this: - -.. code-block:: yaml+jinja - - - hosts: app_servers - vars: - app_path: {{ base_path }}/22 - -You will see: ``ERROR! Syntax Error while loading YAML.`` If you add quotes, Ansible works correctly: - -.. code-block:: yaml+jinja - - - hosts: app_servers - vars: - app_path: "{{ base_path }}/22" - -.. _boolean_variables: - -Boolean variables -================= - -Ansible accepts a broad range of values for boolean variables: ``true/false``, ``1/0``, ``yes/no``, ``True/False`` and so on. The matching of valid strings is case insensitive. -While documentation examples focus on ``true/false`` to be compatible with ``ansible-lint`` default settings, you can use any of the following: - -.. table:: - :class: documentation-table - - =============================================================================================== ==================================================================== - Valid values Description - =============================================================================================== ==================================================================== - ``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0`` Truthy values - - ``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0`` Falsy values - - =============================================================================================== ==================================================================== - -.. _list_variables: - -List variables -============== - -A list variable combines a variable name with multiple values. The multiple values can be stored as an itemized list or in square brackets ``[]``, separated with commas. - -Defining variables as lists ---------------------------- - -You can define variables with multiple values using YAML lists. For example: - -.. code-block:: yaml - - region: - - northeast - - southeast - - midwest - -Referencing list variables --------------------------- - -When you use variables defined as a list (also called an array), you can use individual, specific fields from that list. The first item in a list is item 0, the second item is item 1. For example: - -.. code-block:: yaml+jinja - - region: "{{ region[0] }}" - -The value of this expression would be "northeast". - -.. _dictionary_variables: - -Dictionary variables -==================== - -A dictionary stores the data in key-value pairs. Usually, dictionaries are used to store related data, such as the information contained in an ID or a user profile. - -Defining variables as key:value dictionaries --------------------------------------------- - -You can define more complex variables using YAML dictionaries. A YAML dictionary maps keys to values. For example: - -.. code-block:: yaml - - foo: - field1: one - field2: two - -Referencing key:value dictionary variables ------------------------------------------- - -When you use variables defined as a key:value dictionary (also called a hash), you can use individual, specific fields from that dictionary using either bracket notation or dot notation: - -.. code-block:: yaml - - foo['field1'] - foo.field1 - -Both of these examples reference the same value ("one"). Bracket notation always works. Dot notation can cause problems because some keys collide with attributes and methods of python dictionaries. Use bracket notation if you use keys which start and end with two underscores (which are reserved for special meanings in python) or are any of the known public attributes: - -``add``, ``append``, ``as_integer_ratio``, ``bit_length``, ``capitalize``, ``center``, ``clear``, ``conjugate``, ``copy``, ``count``, ``decode``, ``denominator``, ``difference``, ``difference_update``, ``discard``, ``encode``, ``endswith``, ``expandtabs``, ``extend``, ``find``, ``format``, ``fromhex``, ``fromkeys``, ``get``, ``has_key``, ``hex``, ``imag``, ``index``, ``insert``, ``intersection``, ``intersection_update``, ``isalnum``, ``isalpha``, ``isdecimal``, ``isdigit``, ``isdisjoint``, ``is_integer``, ``islower``, ``isnumeric``, ``isspace``, ``issubset``, ``issuperset``, ``istitle``, ``isupper``, ``items``, ``iteritems``, ``iterkeys``, ``itervalues``, ``join``, ``keys``, ``ljust``, ``lower``, ``lstrip``, ``numerator``, ``partition``, ``pop``, ``popitem``, ``real``, ``remove``, ``replace``, ``reverse``, ``rfind``, ``rindex``, ``rjust``, ``rpartition``, ``rsplit``, ``rstrip``, ``setdefault``, ``sort``, ``split``, ``splitlines``, ``startswith``, ``strip``, ``swapcase``, ``symmetric_difference``, ``symmetric_difference_update``, ``title``, ``translate``, ``union``, ``update``, ``upper``, ``values``, ``viewitems``, ``viewkeys``, ``viewvalues``, ``zfill``. - -.. _registered_variables: - -Registering variables -===================== - -You can create variables from the output of an Ansible task with the task keyword ``register``. You can use registered variables in any later tasks in your play. For example: - -.. code-block:: yaml - - - hosts: web_servers - - tasks: - - - name: Run a shell command and register its output as a variable - ansible.builtin.shell: /usr/bin/foo - register: foo_result - ignore_errors: true - - - name: Run a shell command using output of the previous task - ansible.builtin.shell: /usr/bin/bar - when: foo_result.rc == 5 - -For more examples of using registered variables in conditions on later tasks, see :ref:`playbooks_conditionals`. Registered variables may be simple variables, list variables, dictionary variables, or complex nested data structures. The documentation for each module includes a ``RETURN`` section describing the return values for that module. To see the values for a particular task, run your playbook with ``-v``. - -Registered variables are stored in memory. You cannot cache registered variables for use in future playbook runs. Registered variables are only valid on the host for the rest of the current playbook run, including subsequent plays within the same playbook run. - -Registered variables are host-level variables. When you register a variable in a task with a loop, the registered variable contains a value for each item in the loop. The data structure placed in the variable during the loop will contain a ``results`` attribute, that is a list of all responses from the module. For a more in-depth example of how this works, see the :ref:`playbooks_loops` section on using register with a loop. - -.. note:: If a task fails or is skipped, Ansible still registers a variable with a failure or skipped status, unless the task is skipped based on tags. See :ref:`tags` for information on adding and using tags. - -.. _accessing_complex_variable_data: - -Referencing nested variables -============================ - -Many registered variables (and :ref:`facts `) are nested YAML or JSON data structures. You cannot access values from these nested data structures with the simple ``{{ foo }}`` syntax. You must use either bracket notation or dot notation. For example, to reference an IP address from your facts using the bracket notation: - -.. code-block:: yaml+jinja - - {{ ansible_facts["eth0"]["ipv4"]["address"] }} - -To reference an IP address from your facts using the dot notation: - -.. code-block:: yaml+jinja - - {{ ansible_facts.eth0.ipv4.address }} - -.. _about_jinja2: -.. _jinja2_filters: - -Transforming variables with Jinja2 filters -========================================== - -Jinja2 filters let you transform the value of a variable within a template expression. For example, the ``capitalize`` filter capitalizes any value passed to it; the ``to_yaml`` and ``to_json`` filters change the format of your variable values. Jinja2 includes many `built-in filters `_ and Ansible supplies many more filters. To find more examples of filters, see :ref:`playbooks_filters`. - -.. _setting_variables: - -Where to set variables -====================== - -You can define variables in a variety of places, such as in inventory, in playbooks, in reusable files, in roles, and at the command line. Ansible loads every possible variable it finds, then chooses the variable to apply based on :ref:`variable precedence rules `. - -.. _define_variables_in_inventory: - -Defining variables in inventory -------------------------------- - -You can define different variables for each individual host, or set shared variables for a group of hosts in your inventory. For example, if all machines in the ``[Boston]`` group use 'boston.ntp.example.com' as an NTP server, you can set a group variable. The :ref:`intro_inventory` page has details on setting :ref:`host variables ` and :ref:`group variables ` in inventory. - -.. _playbook_variables: - -Defining variables in a play ----------------------------- - -You can define variables directly in a playbook play: - -.. code-block:: yaml - - - hosts: webservers - vars: - http_port: 80 - -When you define variables in a play, they are only visible to tasks executed in that play. - -.. _included_variables: -.. _variable_file_separation_details: - -Defining variables in included files and roles ----------------------------------------------- - -You can define variables in reusable variables files and/or in reusable roles. When you define variables in reusable variable files, the sensitive variables are separated from playbooks. This separation enables you to store your playbooks in a source control software and even share the playbooks, without the risk of exposing passwords or other sensitive and personal data. For information about creating reusable files and roles, see :ref:`playbooks_reuse`. - -This example shows how you can include variables defined in an external file: - -.. code-block:: yaml - - --- - - - hosts: all - remote_user: root - vars: - favcolor: blue - vars_files: - - /vars/external_vars.yml - - tasks: - - - name: This is just a placeholder - ansible.builtin.command: /bin/echo foo - -The contents of each variables file is a simple YAML dictionary. For example: - -.. code-block:: yaml - - --- - # in the above example, this would be vars/external_vars.yml - somevar: somevalue - password: magic - -.. note:: - You can keep per-host and per-group variables in similar files. To learn about organizing your variables, see :ref:`splitting_out_vars`. - -.. _passing_variables_on_the_command_line: - -Defining variables at runtime ------------------------------ - -You can define variables when you run your playbook by passing variables at the command line using the ``--extra-vars`` (or ``-e``) argument. You can also request user input with a ``vars_prompt`` (see :ref:`playbooks_prompts`). When you pass variables at the command line, use a single quoted string, that contains one or more variables, in one of the formats below. - -key=value format -^^^^^^^^^^^^^^^^ - -Values passed in using the ``key=value`` syntax are interpreted as strings. Use the JSON format if you need to pass non-string values such as Booleans, integers, floats, lists, and so on. - -.. code-block:: text - - ansible-playbook release.yml --extra-vars "version=1.23.45 other_variable=foo" - -JSON string format -^^^^^^^^^^^^^^^^^^ - -.. code-block:: shell - - ansible-playbook release.yml --extra-vars '{"version":"1.23.45","other_variable":"foo"}' - ansible-playbook arcade.yml --extra-vars '{"pacman":"mrs","ghosts":["inky","pinky","clyde","sue"]}' - -When passing variables with ``--extra-vars``, you must escape quotes and other special characters appropriately for both your markup (for example, JSON), and for your shell: - -.. code-block:: shell - - ansible-playbook arcade.yml --extra-vars "{\"name\":\"Conan O\'Brien\"}" - ansible-playbook arcade.yml --extra-vars '{"name":"Conan O'\\\''Brien"}' - ansible-playbook script.yml --extra-vars "{\"dialog\":\"He said \\\"I just can\'t get enough of those single and double-quotes"\!"\\\"\"}" - - -vars from a JSON or YAML file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have a lot of special characters, use a JSON or YAML file containing the variable definitions. Prepend both JSON and YAML filenames with `@`. - -.. code-block:: text - - ansible-playbook release.yml --extra-vars "@some_file.json" - ansible-playbook release.yml --extra-vars "@some_file.yaml" - - -.. _ansible_variable_precedence: - -Variable precedence: Where should I put a variable? -=================================================== - -You can set multiple variables with the same name in many different places. When you do this, Ansible loads every possible variable it finds, then chooses the variable to apply based on variable precedence. In other words, the different variables will override each other in a certain order. - -Teams and projects that agree on guidelines for defining variables (where to define certain types of variables) usually avoid variable precedence concerns. We suggest that you define each variable in one place: figure out where to define a variable, and keep it simple. For examples, see :ref:`variable_examples`. - -Some behavioral parameters that you can set in variables you can also set in Ansible configuration, as command-line options, and using playbook keywords. For example, you can define the user Ansible uses to connect to remote devices as a variable with ``ansible_user``, in a configuration file with ``DEFAULT_REMOTE_USER``, as a command-line option with ``-u``, and with the playbook keyword ``remote_user``. If you define the same parameter in a variable and by another method, the variable overrides the other setting. This approach allows host-specific settings to override more general settings. For examples and more details on the precedence of these various settings, see :ref:`general_precedence_rules`. - -Understanding variable precedence ---------------------------------- - -Ansible does apply variable precedence, and you might have a use for it. Here is the order of precedence from least to greatest (the last listed variables override all other variables): - - #. command line values (for example, ``-u my_user``, these are not variables) - #. role defaults (defined in role/defaults/main.yml) [1]_ - #. inventory file or script group vars [2]_ - #. inventory group_vars/all [3]_ - #. playbook group_vars/all [3]_ - #. inventory group_vars/* [3]_ - #. playbook group_vars/* [3]_ - #. inventory file or script host vars [2]_ - #. inventory host_vars/* [3]_ - #. playbook host_vars/* [3]_ - #. host facts / cached set_facts [4]_ - #. play vars - #. play vars_prompt - #. play vars_files - #. role vars (defined in role/vars/main.yml) - #. block vars (only for tasks in block) - #. task vars (only for the task) - #. include_vars - #. set_facts / registered vars - #. role (and include_role) params - #. include params - #. extra vars (for example, ``-e "user=my_user"``)(always win precedence) - -In general, Ansible gives precedence to variables that were defined more recently, more actively, and with more explicit scope. Variables in the defaults folder inside a role are easily overridden. Anything in the vars directory of the role overrides previous versions of that variable in the namespace. Host and/or inventory variables override role defaults, but explicit includes such as the vars directory or an ``include_vars`` task override inventory variables. - -Ansible merges different variables set in inventory so that more specific settings override more generic settings. For example, ``ansible_ssh_user`` specified as a group_var is overridden by ``ansible_user`` specified as a host_var. For details about the precedence of variables set in inventory, see :ref:`how_we_merge`. - -.. rubric:: Footnotes - -.. [1] Tasks in each role see their own role's defaults. Tasks defined outside of a role see the last role's defaults. -.. [2] Variables defined in inventory file or provided by dynamic inventory. -.. [3] Includes vars added by 'vars plugins' as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible. -.. [4] When created with set_facts's cacheable option, variables have the high precedence in the play, - but are the same as a host facts precedence when they come from the cache. - -.. note:: Within any section, redefining a var overrides the previous instance. - If multiple groups have the same variable, the last one loaded wins. - If you define a variable twice in a play's ``vars:`` section, the second one wins. -.. note:: The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite. - -.. _variable_scopes: - -Scoping variables ------------------ - -You can decide where to set a variable based on the scope you want that value to have. Ansible has three main scopes: - - * Global: this is set by config, environment variables and the command line - * Play: each play and contained structures, vars entries (vars; vars_files; vars_prompt), role defaults and vars. - * Host: variables directly associated to a host, like inventory, include_vars, facts or registered task outputs - -Inside a template, you automatically have access to all variables that are in scope for a host, plus any registered variables, facts, and magic variables. - -.. _variable_examples: - -Tips on where to set variables ------------------------------- - -You should choose where to define a variable based on the kind of control you might want over values. - -Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: child groups override parent groups, and host variables override group variables. See :ref:`define_variables_in_inventory` for details on setting host and group variables. - -Set common defaults in a ``group_vars/all`` file. See :ref:`splitting_out_vars` for details on how to organize host and group variables in your inventory. Group variables are generally placed alongside your inventory file, but they can also be returned by dynamic inventory (see :ref:`intro_dynamic_inventory`) or defined in AWX or on :ref:`ansible_platform` from the UI or API: - -.. code-block:: yaml - - --- - # file: /etc/ansible/group_vars/all - # this is the site wide default - ntp_server: default-time.example.com - -Set location-specific variables in ``group_vars/my_location`` files. All groups are children of the ``all`` group, so variables set here override those set in ``group_vars/all``: - -.. code-block:: yaml - - --- - # file: /etc/ansible/group_vars/boston - ntp_server: boston-time.example.com - -If one host used a different NTP server, you could set that in a host_vars file, which would override the group variable: - -.. code-block:: yaml - - --- - # file: /etc/ansible/host_vars/xyz.boston.example.com - ntp_server: override.example.com - -Set defaults in roles to avoid undefined-variable errors. If you share your roles, other users can rely on the reasonable defaults you added in the ``roles/x/defaults/main.yml`` file, or they can easily override those values in inventory or at the command line. See :ref:`playbooks_reuse_roles` for more info. For example: - -.. code-block:: yaml - - --- - # file: roles/x/defaults/main.yml - # if no other value is supplied in inventory or as a parameter, this value will be used - http_port: 80 - -Set variables in roles to ensure a value is used in that role, and is not overridden by inventory variables. If you are not sharing your role with others, you can define app-specific behaviors like ports this way, in ``roles/x/vars/main.yml``. If you are sharing roles with others, putting variables here makes them harder to override, although they still can by passing a parameter to the role or setting a variable with ``-e``: - -.. code-block:: yaml - - --- - # file: roles/x/vars/main.yml - # this will absolutely be used in this role - http_port: 80 - -Pass variables as parameters when you call roles for maximum clarity, flexibility, and visibility. This approach overrides any defaults that exist for a role. For example: - -.. code-block:: yaml - - roles: - - role: apache - vars: - http_port: 8080 - -When you read this playbook it is clear that you have chosen to set a variable or override a default. You can also pass multiple values, which allows you to run the same role multiple times. See :ref:`run_role_twice` for more details. For example: - -.. code-block:: yaml - - roles: - - role: app_user - vars: - myname: Ian - - role: app_user - vars: - myname: Terry - - role: app_user - vars: - myname: Graham - - role: app_user - vars: - myname: John - -Variables set in one role are available to later roles. You can set variables in a ``roles/common_settings/vars/main.yml`` file and use them in other roles and elsewhere in your playbook: - -.. code-block:: yaml - - roles: - - role: common_settings - - role: something - vars: - foo: 12 - - role: something_else - -.. note:: There are some protections in place to avoid the need to namespace variables. - In this example, variables defined in 'common_settings' are available to 'something' and 'something_else' tasks, but tasks in 'something' have foo set at 12, even if 'common_settings' sets foo to 20. - -Instead of worrying about variable precedence, we encourage you to think about how easily or how often you want to override a variable when deciding where to set it. If you are not sure what other variables are defined, and you need a particular value, use ``--extra-vars`` (``-e``) to override all other variables. - -Using advanced variable syntax -============================== - -For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see :ref:`playbooks_advanced_syntax`. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_conditionals` - Conditional statements in playbooks - :ref:`playbooks_filters` - Jinja2 filters and their uses - :ref:`playbooks_loops` - Looping in playbooks - :ref:`playbooks_reuse_roles` - Playbook organization by roles - :ref:`tips_and_tricks` - Tips and tricks for playbooks - :ref:`special_variables` - List of special variables - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst b/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst deleted file mode 100644 index e90947e6f54..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst +++ /dev/null @@ -1,714 +0,0 @@ -.. _vars_and_facts: - -************************************************ -Discovering variables: facts and magic variables -************************************************ - -With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself. Variables related to remote systems are called facts. With facts, you can use the behavior or state of one system as configuration on other systems. For example, you can use the IP address of one system as a configuration value on another system. Variables related to Ansible are called magic variables. - -.. contents:: - :local: - -Ansible facts -============= - -Ansible facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. You can access this data in the ``ansible_facts`` variable. By default, you can also access some Ansible facts as top-level variables with the ``ansible_`` prefix. You can disable this behavior using the :ref:`INJECT_FACTS_AS_VARS` setting. To see all available facts, add this task to a play: - -.. code-block:: yaml - - - name: Print all available facts - ansible.builtin.debug: - var: ansible_facts - -To see the 'raw' information as gathered, run this command at the command line: - -.. code-block:: shell - - ansible -m ansible.builtin.setup - -Facts include a large amount of variable data, which may look like this: - -.. code-block:: json - - { - "ansible_all_ipv4_addresses": [ - "REDACTED IP ADDRESS" - ], - "ansible_all_ipv6_addresses": [ - "REDACTED IPV6 ADDRESS" - ], - "ansible_apparmor": { - "status": "disabled" - }, - "ansible_architecture": "x86_64", - "ansible_bios_date": "11/28/2013", - "ansible_bios_version": "4.1.5", - "ansible_cmdline": { - "BOOT_IMAGE": "/boot/vmlinuz-3.10.0-862.14.4.el7.x86_64", - "console": "ttyS0,115200", - "no_timer_check": true, - "nofb": true, - "nomodeset": true, - "ro": true, - "root": "LABEL=cloudimg-rootfs", - "vga": "normal" - }, - "ansible_date_time": { - "date": "2018-10-25", - "day": "25", - "epoch": "1540469324", - "hour": "12", - "iso8601": "2018-10-25T12:08:44Z", - "iso8601_basic": "20181025T120844109754", - "iso8601_basic_short": "20181025T120844", - "iso8601_micro": "2018-10-25T12:08:44.109968Z", - "minute": "08", - "month": "10", - "second": "44", - "time": "12:08:44", - "tz": "UTC", - "tz_offset": "+0000", - "weekday": "Thursday", - "weekday_number": "4", - "weeknumber": "43", - "year": "2018" - }, - "ansible_default_ipv4": { - "address": "REDACTED", - "alias": "eth0", - "broadcast": "REDACTED", - "gateway": "REDACTED", - "interface": "eth0", - "macaddress": "REDACTED", - "mtu": 1500, - "netmask": "255.255.255.0", - "network": "REDACTED", - "type": "ether" - }, - "ansible_default_ipv6": {}, - "ansible_device_links": { - "ids": {}, - "labels": { - "xvda1": [ - "cloudimg-rootfs" - ], - "xvdd": [ - "config-2" - ] - }, - "masters": {}, - "uuids": { - "xvda1": [ - "cac81d61-d0f8-4b47-84aa-b48798239164" - ], - "xvdd": [ - "2018-10-25-12-05-57-00" - ] - } - }, - "ansible_devices": { - "xvda": { - "holders": [], - "host": "", - "links": { - "ids": [], - "labels": [], - "masters": [], - "uuids": [] - }, - "model": null, - "partitions": { - "xvda1": { - "holders": [], - "links": { - "ids": [], - "labels": [ - "cloudimg-rootfs" - ], - "masters": [], - "uuids": [ - "cac81d61-d0f8-4b47-84aa-b48798239164" - ] - }, - "sectors": "83883999", - "sectorsize": 512, - "size": "40.00 GB", - "start": "2048", - "uuid": "cac81d61-d0f8-4b47-84aa-b48798239164" - } - }, - "removable": "0", - "rotational": "0", - "sas_address": null, - "sas_device_handle": null, - "scheduler_mode": "deadline", - "sectors": "83886080", - "sectorsize": "512", - "size": "40.00 GB", - "support_discard": "0", - "vendor": null, - "virtual": 1 - }, - "xvdd": { - "holders": [], - "host": "", - "links": { - "ids": [], - "labels": [ - "config-2" - ], - "masters": [], - "uuids": [ - "2018-10-25-12-05-57-00" - ] - }, - "model": null, - "partitions": {}, - "removable": "0", - "rotational": "0", - "sas_address": null, - "sas_device_handle": null, - "scheduler_mode": "deadline", - "sectors": "131072", - "sectorsize": "512", - "size": "64.00 MB", - "support_discard": "0", - "vendor": null, - "virtual": 1 - }, - "xvde": { - "holders": [], - "host": "", - "links": { - "ids": [], - "labels": [], - "masters": [], - "uuids": [] - }, - "model": null, - "partitions": { - "xvde1": { - "holders": [], - "links": { - "ids": [], - "labels": [], - "masters": [], - "uuids": [] - }, - "sectors": "167770112", - "sectorsize": 512, - "size": "80.00 GB", - "start": "2048", - "uuid": null - } - }, - "removable": "0", - "rotational": "0", - "sas_address": null, - "sas_device_handle": null, - "scheduler_mode": "deadline", - "sectors": "167772160", - "sectorsize": "512", - "size": "80.00 GB", - "support_discard": "0", - "vendor": null, - "virtual": 1 - } - }, - "ansible_distribution": "CentOS", - "ansible_distribution_file_parsed": true, - "ansible_distribution_file_path": "/etc/redhat-release", - "ansible_distribution_file_variety": "RedHat", - "ansible_distribution_major_version": "7", - "ansible_distribution_release": "Core", - "ansible_distribution_version": "7.5.1804", - "ansible_dns": { - "nameservers": [ - "127.0.0.1" - ] - }, - "ansible_domain": "", - "ansible_effective_group_id": 1000, - "ansible_effective_user_id": 1000, - "ansible_env": { - "HOME": "/home/zuul", - "LANG": "en_US.UTF-8", - "LESSOPEN": "||/usr/bin/lesspipe.sh %s", - "LOGNAME": "zuul", - "MAIL": "/var/mail/zuul", - "PATH": "/usr/local/bin:/usr/bin", - "PWD": "/home/zuul", - "SELINUX_LEVEL_REQUESTED": "", - "SELINUX_ROLE_REQUESTED": "", - "SELINUX_USE_CURRENT_RANGE": "", - "SHELL": "/bin/bash", - "SHLVL": "2", - "SSH_CLIENT": "REDACTED 55672 22", - "SSH_CONNECTION": "REDACTED 55672 REDACTED 22", - "USER": "zuul", - "XDG_RUNTIME_DIR": "/run/user/1000", - "XDG_SESSION_ID": "1", - "_": "/usr/bin/python2" - }, - "ansible_eth0": { - "active": true, - "device": "eth0", - "ipv4": { - "address": "REDACTED", - "broadcast": "REDACTED", - "netmask": "255.255.255.0", - "network": "REDACTED" - }, - "ipv6": [ - { - "address": "REDACTED", - "prefix": "64", - "scope": "link" - } - ], - "macaddress": "REDACTED", - "module": "xen_netfront", - "mtu": 1500, - "pciid": "vif-0", - "promisc": false, - "type": "ether" - }, - "ansible_eth1": { - "active": true, - "device": "eth1", - "ipv4": { - "address": "REDACTED", - "broadcast": "REDACTED", - "netmask": "255.255.224.0", - "network": "REDACTED" - }, - "ipv6": [ - { - "address": "REDACTED", - "prefix": "64", - "scope": "link" - } - ], - "macaddress": "REDACTED", - "module": "xen_netfront", - "mtu": 1500, - "pciid": "vif-1", - "promisc": false, - "type": "ether" - }, - "ansible_fips": false, - "ansible_form_factor": "Other", - "ansible_fqdn": "centos-7-rax-dfw-0003427354", - "ansible_hostname": "centos-7-rax-dfw-0003427354", - "ansible_interfaces": [ - "lo", - "eth1", - "eth0" - ], - "ansible_is_chroot": false, - "ansible_kernel": "3.10.0-862.14.4.el7.x86_64", - "ansible_lo": { - "active": true, - "device": "lo", - "ipv4": { - "address": "127.0.0.1", - "broadcast": "host", - "netmask": "255.0.0.0", - "network": "127.0.0.0" - }, - "ipv6": [ - { - "address": "::1", - "prefix": "128", - "scope": "host" - } - ], - "mtu": 65536, - "promisc": false, - "type": "loopback" - }, - "ansible_local": {}, - "ansible_lsb": { - "codename": "Core", - "description": "CentOS Linux release 7.5.1804 (Core)", - "id": "CentOS", - "major_release": "7", - "release": "7.5.1804" - }, - "ansible_machine": "x86_64", - "ansible_machine_id": "2db133253c984c82aef2fafcce6f2bed", - "ansible_memfree_mb": 7709, - "ansible_memory_mb": { - "nocache": { - "free": 7804, - "used": 173 - }, - "real": { - "free": 7709, - "total": 7977, - "used": 268 - }, - "swap": { - "cached": 0, - "free": 0, - "total": 0, - "used": 0 - } - }, - "ansible_memtotal_mb": 7977, - "ansible_mounts": [ - { - "block_available": 7220998, - "block_size": 4096, - "block_total": 9817227, - "block_used": 2596229, - "device": "/dev/xvda1", - "fstype": "ext4", - "inode_available": 10052341, - "inode_total": 10419200, - "inode_used": 366859, - "mount": "/", - "options": "rw,seclabel,relatime,data=ordered", - "size_available": 29577207808, - "size_total": 40211361792, - "uuid": "cac81d61-d0f8-4b47-84aa-b48798239164" - }, - { - "block_available": 0, - "block_size": 2048, - "block_total": 252, - "block_used": 252, - "device": "/dev/xvdd", - "fstype": "iso9660", - "inode_available": 0, - "inode_total": 0, - "inode_used": 0, - "mount": "/mnt/config", - "options": "ro,relatime,mode=0700", - "size_available": 0, - "size_total": 516096, - "uuid": "2018-10-25-12-05-57-00" - } - ], - "ansible_nodename": "centos-7-rax-dfw-0003427354", - "ansible_os_family": "RedHat", - "ansible_pkg_mgr": "yum", - "ansible_processor": [ - "0", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "1", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "2", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "3", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "4", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "5", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "6", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz", - "7", - "GenuineIntel", - "Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz" - ], - "ansible_processor_cores": 8, - "ansible_processor_count": 8, - "ansible_processor_nproc": 8, - "ansible_processor_threads_per_core": 1, - "ansible_processor_vcpus": 8, - "ansible_product_name": "HVM domU", - "ansible_product_serial": "REDACTED", - "ansible_product_uuid": "REDACTED", - "ansible_product_version": "4.1.5", - "ansible_python": { - "executable": "/usr/bin/python2", - "has_sslcontext": true, - "type": "CPython", - "version": { - "major": 2, - "micro": 5, - "minor": 7, - "releaselevel": "final", - "serial": 0 - }, - "version_info": [ - 2, - 7, - 5, - "final", - 0 - ] - }, - "ansible_python_version": "2.7.5", - "ansible_real_group_id": 1000, - "ansible_real_user_id": 1000, - "ansible_selinux": { - "config_mode": "enforcing", - "mode": "enforcing", - "policyvers": 31, - "status": "enabled", - "type": "targeted" - }, - "ansible_selinux_python_present": true, - "ansible_service_mgr": "systemd", - "ansible_ssh_host_key_ecdsa_public": "REDACTED KEY VALUE", - "ansible_ssh_host_key_ed25519_public": "REDACTED KEY VALUE", - "ansible_ssh_host_key_rsa_public": "REDACTED KEY VALUE", - "ansible_swapfree_mb": 0, - "ansible_swaptotal_mb": 0, - "ansible_system": "Linux", - "ansible_system_capabilities": [ - "" - ], - "ansible_system_capabilities_enforced": "True", - "ansible_system_vendor": "Xen", - "ansible_uptime_seconds": 151, - "ansible_user_dir": "/home/zuul", - "ansible_user_gecos": "", - "ansible_user_gid": 1000, - "ansible_user_id": "zuul", - "ansible_user_shell": "/bin/bash", - "ansible_user_uid": 1000, - "ansible_userspace_architecture": "x86_64", - "ansible_userspace_bits": "64", - "ansible_virtualization_role": "guest", - "ansible_virtualization_type": "xen", - "gather_subset": [ - "all" - ], - "module_setup": true - } - -You can reference the model of the first disk in the facts shown above in a template or playbook as: - -.. code-block:: jinja - - {{ ansible_facts['devices']['xvda']['model'] }} - -To reference the system hostname: - -.. code-block:: jinja - - {{ ansible_facts['nodename'] }} - -You can use facts in conditionals (see :ref:`playbooks_conditionals`) and also in templates. You can also use facts to create dynamic groups of hosts that match particular criteria, see the :ref:`group_by module ` documentation for details. - -.. note:: Because ``ansible_date_time`` is created and cached when Ansible gathers facts before each playbook run, it can get stale with long-running playbooks. If your playbook takes a long time to run, use the ``pipe`` filter (for example, ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``) or :ref:`now() ` with a Jinja 2 template instead of ``ansible_date_time``. - -.. _fact_requirements: - -Package requirements for fact gathering ---------------------------------------- - -On some distros, you may see missing fact values or facts set to default values because the packages that support gathering those facts are not installed by default. You can install the necessary packages on your remote hosts using the OS package manager. Known dependencies include: - -* Linux Network fact gathering - Depends on the ``ip`` binary, commonly included in the ``iproute2`` package. - -.. _fact_caching: - -Caching facts -------------- - -Like registered variables, facts are stored in memory by default. However, unlike registered variables, facts can be gathered independently and cached for repeated use. With cached facts, you can refer to facts from one system when configuring a second system, even if Ansible executes the current play on the second system first. For example: - -.. code-block:: jinja - - {{ hostvars['asdf.example.com']['ansible_facts']['os_family'] }} - -Caching is controlled by the cache plugins. By default, Ansible uses the memory cache plugin, which stores facts in memory for the duration of the current playbook run. To retain Ansible facts for repeated use, select a different cache plugin. See :ref:`cache_plugins` for details. - -Fact caching can improve performance. If you manage thousands of hosts, you can configure fact caching to run nightly, then manage configuration on a smaller set of servers periodically throughout the day. With cached facts, you have access to variables and information about all hosts even when you are only managing a small number of servers. - -.. _disabling_facts: - -Disabling facts ---------------- - -By default, Ansible gathers facts at the beginning of each play. If you do not need to gather facts (for example, if you know everything about your systems centrally), you can turn off fact gathering at the play level to improve scalability. Disabling facts may particularly improve performance in push mode with very large numbers of systems, or if you are using Ansible on experimental platforms. To disable fact gathering: - -.. code-block:: yaml - - - hosts: whatever - gather_facts: false - -Adding custom facts -------------------- - -The setup module in Ansible automatically discovers a standard set of facts about each host. If you want to add custom values to your facts, you can write a custom facts module, set temporary facts with a ``ansible.builtin.set_fact`` task, or provide permanent custom facts using the facts.d directory. - -.. _local_facts: - -facts.d or local facts -^^^^^^^^^^^^^^^^^^^^^^ - -.. versionadded:: 1.3 - -You can add static custom facts by adding static files to facts.d, or add dynamic facts by adding executable scripts to facts.d. For example, you can add a list of all users on a host to your facts by creating and running a script in facts.d. - -To use facts.d, create an ``/etc/ansible/facts.d`` directory on the remote host or hosts. If you prefer a different directory, create it and specify it using the ``fact_path`` play keyword. Add files to the directory to supply your custom facts. All file names must end with ``.fact``. The files can be JSON, INI, or executable files returning JSON. - -To add static facts, simply add a file with the ``.fact`` extension. For example, create ``/etc/ansible/facts.d/preferences.fact`` with this content: - -.. code-block:: ini - - [general] - asdf=1 - bar=2 - -.. note:: Make sure the file is not executable as this will break the ``ansible.builtin.setup`` module. - -The next time fact gathering runs, your facts will include a hash variable fact named ``general`` with ``asdf`` and ``bar`` as members. To validate this, run the following: - -.. code-block:: shell - - ansible -m ansible.builtin.setup -a "filter=ansible_local" - -And you will see your custom fact added: - -.. code-block:: json - - { - "ansible_local": { - "preferences": { - "general": { - "asdf" : "1", - "bar" : "2" - } - } - } - } - -The ansible_local namespace separates custom facts created by facts.d from system facts or variables defined elsewhere in the playbook, so variables will not override each other. You can access this custom fact in a template or playbook as: - -.. code-block:: jinja - - {{ ansible_local['preferences']['general']['asdf'] }} - -.. note:: The key part in the key=value pairs will be converted into lowercase inside the ansible_local variable. Using the example above, if the ini file contained ``XYZ=3`` in the ``[general]`` section, then you should expect to access it as: ``{{ ansible_local['preferences']['general']['xyz'] }}`` and not ``{{ ansible_local['preferences']['general']['XYZ'] }}``. This is because Ansible uses Python's `ConfigParser`_ which passes all option names through the `optionxform`_ method and this method's default implementation converts option names to lower case. - -.. _ConfigParser: https://docs.python.org/3/library/configparser.html -.. _optionxform: https://docs.python.org/3/library/configparser.html#ConfigParser.RawConfigParser.optionxform - -You can also use facts.d to execute a script on the remote host, generating dynamic custom facts to the ansible_local namespace. For example, you can generate a list of all users that exist on a remote host as a fact about that host. To generate dynamic custom facts using facts.d: - - #. Write and test a script to generate the JSON data you want. - #. Save the script in your facts.d directory. - #. Make sure your script has the ``.fact`` file extension. - #. Make sure your script is executable by the Ansible connection user. - #. Gather facts to execute the script and add the JSON output to ansible_local. - -By default, fact gathering runs once at the beginning of each play. If you create a custom fact using facts.d in a playbook, it will be available in the next play that gathers facts. If you want to use it in the same play where you created it, you must explicitly re-run the setup module. For example: - -.. code-block:: yaml - - - hosts: webservers - tasks: - - - name: Create directory for ansible custom facts - ansible.builtin.file: - state: directory - recurse: true - path: /etc/ansible/facts.d - - - name: Install custom ipmi fact - ansible.builtin.copy: - src: ipmi.fact - dest: /etc/ansible/facts.d - - - name: Re-read facts after adding custom fact - ansible.builtin.setup: - filter: ansible_local - -If you use this pattern frequently, a custom facts module would be more efficient than facts.d. - -.. _magic_variables_and_hostvars: - -Information about Ansible: magic variables -========================================== - -You can access information about Ansible operations, including the python version being used, the hosts and groups in inventory, and the directories for playbooks and roles, using "magic" variables. Like connection variables, magic variables are :ref:`special_variables`. Magic variable names are reserved - do not set variables with these names. The variable ``environment`` is also reserved. - -The most commonly used magic variables are ``hostvars``, ``groups``, ``group_names``, and ``inventory_hostname``. With ``hostvars``, you can access variables defined for any host in the play, at any point in a playbook. You can access Ansible facts using the ``hostvars`` variable too, but only after you have gathered (or cached) facts. Note that variables defined at play objects are not defined for specific hosts and therefore are not mapped to hostvars. - -If you want to configure your database server using the value of a 'fact' from another node, or the value of an inventory variable assigned to another node, you can use ``hostvars`` in a template or on an action line: - -.. code-block:: jinja - - {{ hostvars['test.example.com']['ansible_facts']['distribution'] }} - -With ``groups``, a list of all the groups (and hosts) in the inventory, you can enumerate all hosts within a group. For example: - -.. code-block:: jinja - - {% for host in groups['app_servers'] %} - # something that applies to all app servers. - {% endfor %} - -You can use ``groups`` and ``hostvars`` together to find all the IP addresses in a group. - -.. code-block:: jinja - - {% for host in groups['app_servers'] %} - {{ hostvars[host]['ansible_facts']['eth0']['ipv4']['address'] }} - {% endfor %} - -You can use this approach to point a frontend proxy server to all the hosts in your app servers group, to set up the correct firewall rules between servers, and so on. You must either cache facts or gather facts for those hosts before the task that fills out the template. - -With ``group_names``, a list (array) of all the groups the current host is in, you can create templated files that vary based on the group membership (or role) of the host: - -.. code-block:: jinja - - {% if 'webserver' in group_names %} - # some part of a configuration file that only applies to webservers - {% endif %} - -You can use the magic variable ``inventory_hostname``, the name of the host as configured in your inventory, as an alternative to ``ansible_hostname`` when fact-gathering is disabled. If you have a long FQDN, you can use ``inventory_hostname_short``, which contains the part up to the first period, without the rest of the domain. - -Other useful magic variables refer to the current play or playbook. These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer. - -``ansible_play_hosts`` is the list of all hosts still active in the current play. - -``ansible_play_batch`` is a list of hostnames that are in scope for the current 'batch' of the play. - -The batch size is defined by ``serial``, when not set it is equivalent to the whole play (making it the same as ``ansible_play_hosts``). - -``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool. - -``inventory_dir`` is the pathname of the directory holding Ansible's inventory host file. - -``inventory_file`` is the pathname and the filename pointing to the Ansible's inventory host file. - -``playbook_dir`` contains the playbook base directory. - -``role_path`` contains the current role's pathname and only works inside a role. - -``ansible_check_mode`` is a boolean, set to ``True`` if you run Ansible with ``--check``. - -.. _ansible_version: - -Ansible version ---------------- - -.. versionadded:: 1.8 - -To adapt playbook behavior to different versions of Ansible, you can use the variable ``ansible_version``, which has the following structure: - -.. code-block:: json - - { - "ansible_version": { - "full": "2.10.1", - "major": 2, - "minor": 10, - "revision": 1, - "string": "2.10.1" - } - } diff --git a/docs/docsite/rst/playbook_guide/playbooks_vault.rst b/docs/docsite/rst/playbook_guide/playbooks_vault.rst deleted file mode 100644 index 03bd2c040f3..00000000000 --- a/docs/docsite/rst/playbook_guide/playbooks_vault.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Using vault in playbooks -======================== - -The documentation regarding Ansible Vault has moved. The new location is here: :ref:`vault`. Please update any links you may have made directly to this page. diff --git a/docs/docsite/rst/playbook_guide/shared_snippets/role_directory.txt b/docs/docsite/rst/playbook_guide/shared_snippets/role_directory.txt deleted file mode 100644 index 5722f0ee894..00000000000 --- a/docs/docsite/rst/playbook_guide/shared_snippets/role_directory.txt +++ /dev/null @@ -1,26 +0,0 @@ -.. code-block:: yaml - - roles/ - common/ # this hierarchy represents a "role" - tasks/ # - main.yml # <-- tasks file can include smaller files if warranted - handlers/ # - main.yml # <-- handlers file - templates/ # <-- files for use with the template resource - ntp.conf.j2 # <------- templates end in .j2 - files/ # - bar.txt # <-- files for use with the copy resource - foo.sh # <-- script files for use with the script resource - vars/ # - main.yml # <-- variables associated with this role - defaults/ # - main.yml # <-- default lower priority variables for this role - meta/ # - main.yml # <-- role dependencies - library/ # roles can also include custom modules - module_utils/ # roles can also include custom module_utils - lookup_plugins/ # or other types of plugins, like lookup in this case - - webtier/ # same kind of structure as "common" was above, done for the webtier role - monitoring/ # "" - fooapp/ # "" diff --git a/docs/docsite/rst/playbook_guide/shared_snippets/with2loop.txt b/docs/docsite/rst/playbook_guide/shared_snippets/with2loop.txt deleted file mode 100644 index c563dcec2dd..00000000000 --- a/docs/docsite/rst/playbook_guide/shared_snippets/with2loop.txt +++ /dev/null @@ -1,206 +0,0 @@ -In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``. - -These examples show how to convert many common ``with_`` style loops to ``loop`` and filters. - -with_list ---------- - -``with_list`` is directly replaced by ``loop``. - -.. code-block:: yaml+jinja - - - name: with_list - ansible.builtin.debug: - msg: "{{ item }}" - with_list: - - one - - two - - - name: with_list -> loop - ansible.builtin.debug: - msg: "{{ item }}" - loop: - - one - - two - -with_items ----------- - -``with_items`` is replaced by ``loop`` and the ``flatten`` filter. - -.. code-block:: yaml+jinja - - - name: with_items - ansible.builtin.debug: - msg: "{{ item }}" - with_items: "{{ items }}" - - - name: with_items -> loop - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ items|flatten(levels=1) }}" - -with_indexed_items ------------------- - -``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``. - -.. code-block:: yaml+jinja - - - name: with_indexed_items - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - with_indexed_items: "{{ items }}" - - - name: with_indexed_items -> loop - ansible.builtin.debug: - msg: "{{ index }} - {{ item }}" - loop: "{{ items|flatten(levels=1) }}" - loop_control: - index_var: index - -with_flattened --------------- - -``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter. - -.. code-block:: yaml+jinja - - - name: with_flattened - ansible.builtin.debug: - msg: "{{ item }}" - with_flattened: "{{ items }}" - - - name: with_flattened -> loop - ansible.builtin.debug: - msg: "{{ item }}" - loop: "{{ items|flatten }}" - -with_together -------------- - -``with_together`` is replaced by ``loop`` and the ``zip`` filter. - -.. code-block:: yaml+jinja - - - name: with_together - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - with_together: - - "{{ list_one }}" - - "{{ list_two }}" - - - name: with_together -> loop - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - loop: "{{ list_one|zip(list_two)|list }}" - -Another example with complex data - -.. code-block:: yaml+jinja - - - name: with_together -> loop - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }} - {{ item.2 }}" - loop: "{{ data[0]|zip(*data[1:])|list }}" - vars: - data: - - ['a', 'b', 'c'] - - ['d', 'e', 'f'] - - ['g', 'h', 'i'] - -with_dict ---------- - -``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters. - -.. code-block:: yaml+jinja - - - name: with_dict - ansible.builtin.debug: - msg: "{{ item.key }} - {{ item.value }}" - with_dict: "{{ dictionary }}" - - - name: with_dict -> loop (option 1) - ansible.builtin.debug: - msg: "{{ item.key }} - {{ item.value }}" - loop: "{{ dictionary|dict2items }}" - - - name: with_dict -> loop (option 2) - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - loop: "{{ dictionary|dictsort }}" - -with_sequence -------------- - -``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter. - -.. code-block:: yaml+jinja - - - name: with_sequence - ansible.builtin.debug: - msg: "{{ item }}" - with_sequence: start=0 end=4 stride=2 format=testuser%02x - - - name: with_sequence -> loop - ansible.builtin.debug: - msg: "{{ 'testuser%02x' | format(item) }}" - loop: "{{ range(0, 4 + 1, 2)|list }}" - -The range of the loop is exclusive of the end point. - -with_subelements ----------------- - -``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter. - -.. code-block:: yaml+jinja - - - name: with_subelements - ansible.builtin.debug: - msg: "{{ item.0.name }} - {{ item.1 }}" - with_subelements: - - "{{ users }}" - - mysql.hosts - - - name: with_subelements -> loop - ansible.builtin.debug: - msg: "{{ item.0.name }} - {{ item.1 }}" - loop: "{{ users|subelements('mysql.hosts') }}" - -with_nested/with_cartesian --------------------------- - -``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter. - -.. code-block:: yaml+jinja - - - name: with_nested - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - with_nested: - - "{{ list_one }}" - - "{{ list_two }}" - - - name: with_nested -> loop - ansible.builtin.debug: - msg: "{{ item.0 }} - {{ item.1 }}" - loop: "{{ list_one|product(list_two)|list }}" - -with_random_choice ------------------- - -``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``. - -.. code-block:: yaml+jinja - - - name: with_random_choice - ansible.builtin.debug: - msg: "{{ item }}" - with_random_choice: "{{ my_list }}" - - - name: with_random_choice -> loop (No loop is needed here) - ansible.builtin.debug: - msg: "{{ my_list|random }}" - tags: random diff --git a/docs/docsite/rst/plugins/action.rst b/docs/docsite/rst/plugins/action.rst deleted file mode 100644 index fe7c547f4bc..00000000000 --- a/docs/docsite/rst/plugins/action.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _action_plugins: - -Action plugins -============== - -.. contents:: - :local: - :depth: 2 - -Action plugins act in conjunction with :ref:`modules ` to execute the actions required by playbook tasks. They usually execute automatically in the background doing prerequisite work before modules execute. - -The 'normal' action plugin is used for modules that do not already have an action plugin. If necessary, you can :ref:`create custom action plugins `. - -.. _enabling_action: - -Enabling action plugins ------------------------ - -You can enable a custom action plugin by either dropping it into the ``action_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the action plugin directory sources configured in :ref:`ansible.cfg `. - -.. _using_action: - -Using action plugins --------------------- - -Action plugin are executed by default when an associated module is used; no action is required. - -Plugin list ------------ - -You cannot list action plugins directly, they show up as their counterpart modules: - -Use ``ansible-doc -l`` to see the list of available modules. -Use ``ansible-doc `` to see specific documentation and examples, this should note if the module has a corresponding action plugin. - -.. seealso:: - - :ref:`cache_plugins` - Cache plugins - :ref:`callback_plugins` - Callback plugins - :ref:`connection_plugins` - Connection plugins - :ref:`inventory_plugins` - Inventory plugins - :ref:`shell_plugins` - Shell plugins - :ref:`strategy_plugins` - Strategy plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/become.rst b/docs/docsite/rst/plugins/become.rst deleted file mode 100644 index 206a9950864..00000000000 --- a/docs/docsite/rst/plugins/become.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _become_plugins: - -Become plugins -============== - -.. contents:: - :local: - :depth: 2 - -.. versionadded:: 2.8 - -Become plugins work to ensure that Ansible can use certain privilege escalation systems when running the basic -commands to work with the target machine as well as the modules required to execute the tasks specified in -the play. - -These utilities (``sudo``, ``su``, ``doas``, and so on) generally let you 'become' another user to execute a command -with the permissions of that user. - - -.. _enabling_become: - -Enabling Become Plugins ------------------------ - -The become plugins shipped with Ansible are already enabled. Custom plugins can be added by placing -them into a ``become_plugins`` directory adjacent to your play, inside a role, or by placing them in one of -the become plugin directory sources configured in :ref:`ansible.cfg `. - - -.. _using_become: - -Using Become Plugins --------------------- - -In addition to the default configuration settings in :ref:`ansible_configuration_settings` or the -``--become-method`` command line option, you can use the ``become_method`` keyword in a play or, if you need -to be 'host specific', the connection variable ``ansible_become_method`` to select the plugin to use. - -You can further control the settings for each plugin via other configuration options detailed in the plugin -themselves (linked below). - -.. _become_plugin_list: - -Plugin List ------------ - -You can use ``ansible-doc -t become -l`` to see the list of available plugins. -Use ``ansible-doc -t become `` to see specific documentation and examples. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/cache.rst b/docs/docsite/rst/plugins/cache.rst deleted file mode 100644 index 4aa88f9246b..00000000000 --- a/docs/docsite/rst/plugins/cache.rst +++ /dev/null @@ -1,139 +0,0 @@ -.. _cache_plugins: - -Cache plugins -============= - -.. contents:: - :local: - :depth: 2 - -Cache plugins allow Ansible to store gathered facts or inventory source data without the performance hit of retrieving them from source. - -The default cache plugin is the :ref:`memory ` plugin, which only caches the data for the current execution of Ansible. Other plugins with persistent storage are available to allow caching the data across runs. Some of these cache plugins write to files, others write to databases. - -You can use different cache plugins for inventory and facts. If you enable inventory caching without setting an inventory-specific cache plugin, Ansible uses the fact cache plugin for both facts and inventory. If necessary, you can :ref:`create custom cache plugins `. - -.. _enabling_cache: - -Enabling fact cache plugins ---------------------------- - -Fact caching is always enabled. However, only one fact cache plugin can be active at a time. You can select the cache plugin to use for fact caching in the Ansible configuration, either with an environment variable: - -.. code-block:: shell - - export ANSIBLE_CACHE_PLUGIN=jsonfile - -or in the ``ansible.cfg`` file: - -.. code-block:: ini - - [defaults] - fact_caching=redis - -If the cache plugin is in a collection use the fully qualified name: - -.. code-block:: ini - - [defaults] - fact_caching = namespace.collection_name.cache_plugin_name - -To enable a custom cache plugin, save it in a ``cache_plugins`` directory adjacent to your play, inside a role, or in one of the directory sources configured in :ref:`ansible.cfg `. - -You also need to configure other settings specific to each plugin. Consult the individual plugin documentation or the Ansible :ref:`configuration ` for more details. - -Enabling inventory cache plugins --------------------------------- - -Inventory caching is disabled by default. To cache inventory data, you must enable inventory caching and then select the specific cache plugin you want to use. Not all inventory plugins support caching, so check the documentation for the inventory plugin(s) you want to use. You can enable inventory caching with an environment variable: - -.. code-block:: shell - - export ANSIBLE_INVENTORY_CACHE=True - -or in the ``ansible.cfg`` file: - -.. code-block:: ini - - [inventory] - cache=True - -or if the inventory plugin accepts a YAML configuration source, in the configuration file: - -.. code-block:: yaml - - # dev.aws_ec2.yaml - plugin: aws_ec2 - cache: True - -Only one inventory cache plugin can be active at a time. You can set it with an environment variable: - -.. code-block:: shell - - export ANSIBLE_INVENTORY_CACHE_PLUGIN=jsonfile - -or in the ansible.cfg file: - -.. code-block:: ini - - [inventory] - cache_plugin=jsonfile - -or if the inventory plugin accepts a YAML configuration source, in the configuration file: - -.. code-block:: yaml - - # dev.aws_ec2.yaml - plugin: aws_ec2 - cache_plugin: jsonfile - -To cache inventory with a custom plugin in your plugin path, follow the :ref:`developer guide on cache plugins`. - -To cache inventory with a cache plugin in a collection, use the FQCN: - -.. code-block:: ini - - [inventory] - cache_plugin=collection_namespace.collection_name.cache_plugin - -If you enable caching for inventory plugins without selecting an inventory-specific cache plugin, Ansible falls back to caching inventory with the fact cache plugin you configured. Consult the individual inventory plugin documentation or the Ansible :ref:`configuration ` for more details. - -.. Note: In Ansible 2.7 and earlier, inventory plugins can only use file-based cache plugins, such as jsonfile, pickle, and yaml. - - -.. _using_cache: - -Using cache plugins -------------------- - -Cache plugins are used automatically once they are enabled. - - -.. _cache_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t cache -l`` to see the list of available plugins. -Use ``ansible-doc -t cache `` to see specific documentation and examples. - -.. seealso:: - - :ref:`action_plugins` - Action plugins - :ref:`callback_plugins` - Callback plugins - :ref:`connection_plugins` - Connection plugins - :ref:`inventory_plugins` - Inventory plugins - :ref:`shell_plugins` - Shell plugins - :ref:`strategy_plugins` - Strategy plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/callback.rst b/docs/docsite/rst/plugins/callback.rst deleted file mode 100644 index 98e4beb754c..00000000000 --- a/docs/docsite/rst/plugins/callback.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. _callback_plugins: - -Callback plugins -================ - -.. contents:: - :local: - :depth: 2 - -Callback plugins enable adding new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs, but can also be used to add additional output, integrate with other tools and marshal the events to a storage backend. If necessary, you can :ref:`create custom callback plugins `. - -.. _callback_examples: - -Example callback plugins ------------------------- - -The :ref:`log_plays ` callback is an example of how to record playbook events to a log file, and the :ref:`mail ` callback sends email on playbook failures. - -The :ref:`say ` callback responds with computer synthesized speech in relation to playbook events. - -.. _enabling_callbacks: - -Enabling callback plugins -------------------------- - -You can activate a custom callback by either dropping it into a ``callback_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the callback directory sources configured in :ref:`ansible.cfg `. - -Plugins are loaded in alphanumeric order. For example, a plugin implemented in a file named `1_first.py` would run before a plugin file named `2_second.py`. - -Most callbacks shipped with Ansible are disabled by default and need to be enabled in your :ref:`ansible.cfg ` file in order to function. For example: - -.. code-block:: ini - - #callbacks_enabled = timer, mail, profile_roles, collection_namespace.collection_name.custom_callback - -Setting a callback plugin for ``ansible-playbook`` --------------------------------------------------- - -You can only have one plugin be the main manager of your console output. If you want to replace the default, you should define ``CALLBACK_TYPE = stdout`` in the subclass and then configure the stdout plugin in :ref:`ansible.cfg `. For example: - -.. code-block:: ini - - stdout_callback = dense - -or for my custom callback: - -.. code-block:: ini - - stdout_callback = mycallback - -This only affects :ref:`ansible-playbook` by default. - -Setting a callback plugin for ad hoc commands ---------------------------------------------- - -The :ref:`ansible` ad hoc command specifically uses a different callback plugin for stdout, so there is an extra setting in :ref:`ansible_configuration_settings` you need to add to use the stdout callback defined above: - -.. code-block:: ini - - [defaults] - bin_ansible_callbacks=True - -You can also set this as an environment variable: - -.. code-block:: shell - - export ANSIBLE_LOAD_CALLBACK_PLUGINS=1 - - -.. _callback_plugin_types: - -Types of callback plugins -------------------------- - -There are three types of callback plugins: - -:stdout callback plugins: - - These plugins handle the main console output. Only one of these can be active. - -:aggregate callback plugins: - - Aggregate callbacks can add additional console output next to a stdout callback. This can be aggregate information at the end of a playbook run, additional per-task output, or anything else. - -:notification callback plugins: - - Notification callbacks inform other applications, services, or systems. This can be anything from logging to databases, informing on errors in Instant Messaging applications, or sending emails when a server is unreachable. - -.. _callback_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t callback -l`` to see the list of available plugins. -Use ``ansible-doc -t callback `` to see specific documents and examples. - -.. seealso:: - - :ref:`action_plugins` - Action plugins - :ref:`cache_plugins` - Cache plugins - :ref:`connection_plugins` - Connection plugins - :ref:`inventory_plugins` - Inventory plugins - :ref:`shell_plugins` - Shell plugins - :ref:`strategy_plugins` - Strategy plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/cliconf.rst b/docs/docsite/rst/plugins/cliconf.rst deleted file mode 100644 index f5af78c2124..00000000000 --- a/docs/docsite/rst/plugins/cliconf.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _cliconf_plugins: - -Cliconf plugins -=============== - -.. contents:: - :local: - :depth: 2 - -Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices. - -These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ``ansible_network_os`` variable. - -.. _enabling_cliconf: - -Adding cliconf plugins -------------------------- - -You can extend Ansible to support other network devices by dropping a custom plugin into the ``cliconf_plugins`` directory. - -.. _using_cliconf: - -Using cliconf plugins ------------------------- - -The cliconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality. - -Most cliconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into CLI commands. - -Plugins are self-documenting. Each plugin should document its configuration options. - -.. _cliconf_plugin_list: - -Viewing cliconf plugins ------------------------ - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several cliconf plugins. To list all available cliconf plugins on your control node, type ``ansible-doc -t cliconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t cliconf``. - - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/connection.rst b/docs/docsite/rst/plugins/connection.rst deleted file mode 100644 index 3652ffe1783..00000000000 --- a/docs/docsite/rst/plugins/connection.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _connection_plugins: - -Connection plugins -================== - -.. contents:: - :local: - :depth: 2 - -Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time. - -By default, Ansible ships with several connection plugins. The most commonly used are the :ref:`paramiko SSH`, native ssh (just called :ref:`ssh`), and :ref:`local` connection types. All of these can be used in playbooks and with :command:`/usr/bin/ansible` to decide how you want to talk to remote machines. If necessary, you can :ref:`create custom connection plugins `. - -The basics of these connection types are covered in the :ref:`getting started` section. - -.. _ssh_plugins: - -``ssh`` plugins ---------------- - -Because ssh is the default protocol used in system administration and the protocol most used in Ansible, ssh options are included in the command line tools. See :ref:`ansible-playbook` for more details. - -.. _enabling_connection: - -Adding connection plugins -------------------------- - -You can extend Ansible to support other transports (such as SNMP or message bus) by dropping a custom plugin -into the ``connection_plugins`` directory. - -.. _using_connection: - -Using connection plugins ------------------------- - -You can set the connection plugin globally via :ref:`configuration`, at the command line (``-c``, ``--connection``), as a :ref:`keyword ` in your play, or by setting a :ref:`variable`, most often in your inventory. -For example, for Windows machines you might want to set the :ref:`winrm ` plugin as an inventory variable. - -Most connection plugins can operate with minimal configuration. By default they use the :ref:`inventory hostname` and defaults to find the target host. - -Plugins are self-documenting. Each plugin should document its configuration options. The following are connection variables common to most connection plugins: - -:ref:`ansible_host` - The name of the host to connect to, if different from the :ref:`inventory ` hostname. -:ref:`ansible_port` - The ssh port number, for :ref:`ssh ` and :ref:`paramiko_ssh ` it defaults to 22. -:ref:`ansible_user` - The default user name to use for log in. Most plugins default to the 'current user running Ansible'. - -Each plugin might also have a specific version of a variable that overrides the general version. For example, ``ansible_ssh_host`` for the :ref:`ssh ` plugin. - -.. _connection_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t connection -l`` to see the list of available plugins. -Use ``ansible-doc -t connection `` to see detailed documentation and examples. - - -.. seealso:: - - :ref:`Working with Playbooks` - An introduction to playbooks - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/docs_fragment.rst b/docs/docsite/rst/plugins/docs_fragment.rst deleted file mode 100644 index 546229bee79..00000000000 --- a/docs/docsite/rst/plugins/docs_fragment.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _docs_fragment_plugins: - -Docs fragments -============== - -.. contents:: - :local: - :depth: 2 - -Docs fragments allow you to document common parameters of multiple plugins or modules in a single place. - -.. _enabling_docs_fragments: - -Enabling docs fragments ------------------------ - -You can add a custom docs fragment by dropping it into a ``doc_fragments`` directory adjacent to your collection or role, just like any other plugin. - -.. _using_docs_fragments: - -Using docs fragments --------------------- - -Only collection developers and maintainers use docs fragments. For more information on using docs fragments, see :ref:`module_docs_fragments` or :ref:`docfragments_collections`. - -.. seealso:: - - :ref:`developing_modules_general` - An introduction to creating Ansible modules - :ref:`developing_collections` - An guide to creating Ansible collections - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/filter.rst b/docs/docsite/rst/plugins/filter.rst deleted file mode 100644 index b768cfe5944..00000000000 --- a/docs/docsite/rst/plugins/filter.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _filter_plugins: - -Filter plugins -============== - -.. contents:: - :local: - :depth: 2 - -Filter plugins manipulate data. With the right filter you can extract a particular value, transform data types and formats, perform mathematical calculations, split and concatenate strings, insert dates and times, and do much more. Ansible uses the :ref:`standard filters ` shipped with Jinja2 and adds some specialized filter plugins. You can :ref:`create custom Ansible filters as plugins `. - -.. _enabling_filter: - -Enabling filter plugins ------------------------ - -You can add a custom filter plugin by dropping it into a ``filter_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the filter plugin directory sources configured in :ref:`ansible.cfg `. - -.. _using_filter: - -Using filter plugins --------------------- - -You can use filters anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using filter plugins, see :ref:`playbooks_filters`. Filters can return any type of data, but if you want to always return a boolean (``True`` or ``False``) you should be looking at a test instead. - -.. code-block:: YAML+Jinja - - vars: - yaml_string: "{{ some_variable|to_yaml }}" - -Filters are the preferred way to manipulate data in Ansible, you can identify a filter because it is normally preceded by a ``|``, with the expression on the left of it being the first input of the filter. Additional parameters may be passed into the filter itself as you would to most programming functions. These parameters can be either ``positional`` (passed in order) or ``named`` (passed as key=value pairs). When passing both types, positional arguments should go first. - -.. code-block:: YAML+Jinja - - passing_positional: {{ (x == 32) | ternary('x is 32', 'x is not 32') }} - passing_extra_named_parameters: {{ some_variable | to_yaml(indent=8, width=1337) }} - passing_both: {{ some_variable| ternary('true value', 'false value', none_val='NULL') }} - -In the documentation, filters will always have a C(_input) option that corresponds to the expression to the left of c(|). A C(positional:) field in the documentation will show which options are positional and in which order they are required. - - -Plugin list ------------ - -You can use ``ansible-doc -t filter -l`` to see the list of available plugins. Use ``ansible-doc -t filter `` to see specific documents and examples. - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/httpapi.rst b/docs/docsite/rst/plugins/httpapi.rst deleted file mode 100644 index 7ce0573b918..00000000000 --- a/docs/docsite/rst/plugins/httpapi.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. _httpapi_plugins: - -Httpapi plugins -=============== - -.. contents:: - :local: - :depth: 2 - -Httpapi plugins tell Ansible how to interact with a remote device's HTTP-based API and execute tasks on the -device. - -Each plugin represents a particular dialect of API. Some are platform-specific (Arista eAPI, Cisco NXAPI), while others might be usable on a variety of platforms (RESTCONF). Ansible loads the appropriate httpapi plugin automatically based on the ``ansible_network_os`` variable. - - -.. _enabling_httpapi: - -Adding httpapi plugins -------------------------- - -You can extend Ansible to support other APIs by dropping a custom plugin into the ``httpapi_plugins`` directory. See :ref:`developing_plugins_httpapi` for details. - -.. _using_httpapi: - -Using httpapi plugins ------------------------- - -The httpapi plugin to use is determined automatically from the ``ansible_network_os`` variable. - -Most httpapi plugins can operate without configuration. Additional options may be defined by each plugin. - -Plugins are self-documenting. Each plugin should document its configuration options. - - -The following sample playbook shows the httpapi plugin for an Arista network device, assuming an inventory variable set as ``ansible_network_os=eos`` for the httpapi plugin to trigger off: - -.. code-block:: yaml - - - hosts: leaf01 - connection: httpapi - gather_facts: false - tasks: - - - name: type a simple arista command - eos_command: - commands: - - show version | json - register: command_output - - - name: print command output to terminal window - debug: - var: command_output.stdout[0]["version"] - -See the full working example `on GitHub `_. - -.. _httpapi_plugin_list: - -Viewing httpapi plugins ------------------------ - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several httpapi plugins. To list all available httpapi plugins on your control node, type ``ansible-doc -t httpapi -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t httpapi``. - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - :ref:`Developing network modules` - How to develop network modules. - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/index.html b/docs/docsite/rst/plugins/index.html deleted file mode 100644 index a7eac85695c..00000000000 --- a/docs/docsite/rst/plugins/index.html +++ /dev/null @@ -1,4 +0,0 @@ - - -`` to see plugin-specific documentation and examples. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`callback_plugins` - Callback plugins - :ref:`connection_plugins` - Connection plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - :ref:`vars_plugins` - Vars plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/lookup.rst b/docs/docsite/rst/plugins/lookup.rst deleted file mode 100644 index d0336e91a52..00000000000 --- a/docs/docsite/rst/plugins/lookup.rst +++ /dev/null @@ -1,167 +0,0 @@ -.. _lookup_plugins: - -Lookup plugins -============== - -.. contents:: - :local: - :depth: 2 - -Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks. Like all :ref:`templating `, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. You can use lookup plugins to load variables or templates with information from external sources. You can :ref:`create custom lookup plugins `. - -.. note:: - - Lookups are executed with a working directory relative to the role or play, - as opposed to local tasks, which are executed relative the executed script. - - Pass ``wantlist=True`` to lookups to use in Jinja2 template "for" loops. - - By default, lookup return values are marked as unsafe for security reasons. If you trust the outside source your lookup accesses, pass ``allow_unsafe=True`` to allow Jinja2 templates to evaluate lookup values. - -.. warning:: - - Some lookups pass arguments to a shell. When using variables from a remote/untrusted source, use the `|quote` filter to ensure safe usage. - - -.. _enabling_lookup: - -Enabling lookup plugins ------------------------ - -Ansible enables all lookup plugins it can find. You can activate a custom lookup by either dropping it into a ``lookup_plugins`` directory adjacent to your play, inside the ``plugins/lookup/`` directory of a collection you have installed, inside a standalone role, or in one of the lookup directory sources configured in :ref:`ansible.cfg `. - - -.. _using_lookup: - -Using lookup plugins --------------------- - -You can use lookup plugins anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using lookup plugins, see :ref:`playbooks_lookups`. - -.. code-block:: YAML+Jinja - - vars: - file_contents: "{{ lookup('file', 'path/to/file.txt') }}" - -Lookups are an integral part of loops. Wherever you see ``with_``, the part after the underscore is the name of a lookup. For this reason, lookups are expected to output lists; for example, ``with_items`` uses the :ref:`items ` lookup: - -.. code-block:: YAML+Jinja - - tasks: - - name: count to 3 - debug: msg={{ item }} - with_items: [1, 2, 3] - -You can combine lookups with :ref:`filters `, :ref:`tests ` and even each other to do some complex data generation and manipulation. For example: - -.. code-block:: YAML+Jinja - - tasks: - - name: valid but useless and over complicated chained lookups and filters - debug: msg="find the answer here:\n{{ lookup('url', 'https://google.com/search/?q=' + item|urlencode)|join(' ') }}" - with_nested: - - "{{ lookup('consul_kv', 'bcs/' + lookup('file', '/the/question') + ', host=localhost, port=2000')|shuffle }}" - - "{{ lookup('sequence', 'end=42 start=2 step=2')|map('log', 4)|list) }}" - - ['a', 'c', 'd', 'c'] - -.. versionadded:: 2.6 - -You can control how errors behave in all lookup plugins by setting ``errors`` to ``ignore``, ``warn``, or ``strict``. The default setting is ``strict``, which causes the task to fail if the lookup returns an error. For example: - -To ignore lookup errors: - -.. code-block:: YAML+Jinja - - - name: if this file does not exist, I do not care .. file plugin itself warns anyway ... - debug: msg="{{ lookup('file', '/nosuchfile', errors='ignore') }}" - -.. code-block:: ansible-output - - [WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths) - - ok: [localhost] => { - "msg": "" - } - - -To get a warning instead of a failure: - -.. code-block:: YAML+Jinja - - - name: if this file does not exist, let me know, but continue - debug: msg="{{ lookup('file', '/nosuchfile', errors='warn') }}" - -.. code-block:: ansible-output - - [WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths) - - [WARNING]: An unhandled exception occurred while running the lookup plugin 'file'. Error was a , original message: could not locate file in lookup: /nosuchfile - - ok: [localhost] => { - "msg": "" - } - - -To get a fatal error (the default): - -.. code-block:: YAML+Jinja - - - name: if this file does not exist, FAIL (this is the default) - debug: msg="{{ lookup('file', '/nosuchfile', errors='strict') }}" - -.. code-block:: ansible-output - - [WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths) - - fatal: [localhost]: FAILED! => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a , original message: could not locate file in lookup: /nosuchfile"} - - -.. _query: - -Forcing lookups to return lists: ``query`` and ``wantlist=True`` ----------------------------------------------------------------- - -.. versionadded:: 2.5 - -In Ansible 2.5, a new Jinja2 function called ``query`` was added for invoking lookup plugins. The difference between ``lookup`` and ``query`` is largely that ``query`` will always return a list. -The default behavior of ``lookup`` is to return a string of comma separated values. ``lookup`` can be explicitly configured to return a list using ``wantlist=True``. - -This feature provides an easier and more consistent interface for interacting with the new ``loop`` keyword, while maintaining backwards compatibility with other uses of ``lookup``. - -The following examples are equivalent: - -.. code-block:: jinja - - lookup('dict', dict_variable, wantlist=True) - - query('dict', dict_variable) - -As demonstrated above, the behavior of ``wantlist=True`` is implicit when using ``query``. - -Additionally, ``q`` was introduced as a shortform of ``query``: - -.. code-block:: jinja - - q('dict', dict_variable) - - -.. _lookup_plugins_list: - -Plugin list ------------ - -You can use ``ansible-doc -t lookup -l`` to see the list of available plugins. Use ``ansible-doc -t lookup `` to see specific documents and examples. - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Ansible inventory plugins - :ref:`callback_plugins` - Ansible callback plugins - :ref:`filter_plugins` - Jinja2 filter plugins - :ref:`test_plugins` - Jinja2 test plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/module.rst b/docs/docsite/rst/plugins/module.rst deleted file mode 100644 index 4d44f46979c..00000000000 --- a/docs/docsite/rst/plugins/module.rst +++ /dev/null @@ -1,43 +0,0 @@ -.. _module_plugins: - -Modules -======= - -.. contents:: - :local: - :depth: 2 - -Modules are the main building blocks of Ansible playbooks. Although we do not generally speak of "module plugins", a module is a type of plugin. For a developer-focused description of the differences between modules and other plugins, see :ref:`modules_vs_plugins`. - -.. _enabling_modules: - -Enabling modules ----------------- - -You can enable a custom module by dropping it into one of these locations: - -* any directory added to the ``ANSIBLE_LIBRARY`` environment variable (``$ANSIBLE_LIBRARY`` takes a colon-separated list like ``$PATH``) -* ``~/.ansible/plugins/modules/`` -* ``/usr/share/ansible/plugins/modules/`` - -For more information on using local custom modules, see :ref:`local_modules`. - -.. _using_modules: - -Using modules -------------- - -For information on using modules in ad hoc tasks, see :ref:`intro_adhoc`. For information on using modules in playbooks, see :ref:`playbooks_intro`. - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`developing_modules_general` - An introduction to creating Ansible modules - :ref:`developing_collections` - An guide to creating Ansible collections - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-devel IRC chat channel diff --git a/docs/docsite/rst/plugins/module_util.rst b/docs/docsite/rst/plugins/module_util.rst deleted file mode 100644 index c694380c6d4..00000000000 --- a/docs/docsite/rst/plugins/module_util.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _module_util_plugins: - -Module utilities -================ - -.. contents:: - :local: - :depth: 2 - -Module utilities contain shared code used by multiple plugins. You can write :ref:`custom module utilities `. - -.. _enabling_module_utils: - -Enabling module utilities -------------------------- - -You can add a custom module utility by dropping it into a ``module_utils`` directory adjacent to your collection or role, just like any other plugin. - -.. _using_module_utils: - -Using module utilities ----------------------- - -For information on using module utilities, see :ref:`developing_module_utilities`. - -.. seealso:: - - :ref:`developing_modules_general` - An introduction to creating Ansible modules - :ref:`developing_collections` - An guide to creating Ansible collections - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-devel IRC chat channel diff --git a/docs/docsite/rst/plugins/netconf.rst b/docs/docsite/rst/plugins/netconf.rst deleted file mode 100644 index 4f79809d12e..00000000000 --- a/docs/docsite/rst/plugins/netconf.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _netconf_plugins: - -Netconf plugins -=============== - -.. contents:: - :local: - :depth: 2 - -Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices. - -These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate netconf plugin automatically based on the ``ansible_network_os`` variable. If the platform supports standard Netconf implementation as defined in the Netconf RFC specification, Ansible loads the ``default`` netconf plugin. If the platform supports propriety Netconf RPCs, Ansible loads the platform-specific netconf plugin. - -.. _enabling_netconf: - -Adding netconf plugins -------------------------- - -You can extend Ansible to support other network devices by dropping a custom plugin into the ``netconf_plugins`` directory. - -.. _using_netconf: - -Using netconf plugins ------------------------- - -The netconf plugin to use is determined automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality. - -Most netconf plugins can operate without configuration. A few have additional options that can be set to affect how tasks are translated into netconf commands. A ncclient device specific handler name can be set in the netconf plugin or else the value of ``default`` is used as per ncclient device handler. - -Plugins are self-documenting. Each plugin should document its configuration options. - -.. _netconf_plugin_list: - -Listing netconf plugins ------------------------ - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several netconf plugins. To list all available netconf plugins on your control node, type ``ansible-doc -t netconf -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t netconf``. - - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/plugins.rst b/docs/docsite/rst/plugins/plugins.rst deleted file mode 100644 index 46ed28ee542..00000000000 --- a/docs/docsite/rst/plugins/plugins.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _plugins_lookup: -.. _working_with_plugins: - -******************** -Working with plugins -******************** - -Plugins are pieces of code that augment Ansible's core functionality. Ansible uses a plugin architecture to enable a rich, flexible and expandable feature set. - -Ansible ships with a number of handy plugins, and you can easily write your own. - -This section covers the various types of plugins that are included with Ansible: - -.. toctree:: - :maxdepth: 1 - - action - become - cache - callback - cliconf - connection - docs_fragment - filter - httpapi - inventory - lookup - module - module_util - netconf - shell - strategy - terminal - test - vars - -.. seealso:: - - :ref:`plugin_filtering_config` - Controlling access to modules - :ref:`ansible_configuration_settings` - Ansible configuration documentation and settings - :ref:`command_line_tools` - Ansible tools, description and options - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/shell.rst b/docs/docsite/rst/plugins/shell.rst deleted file mode 100644 index 3c9daf3c142..00000000000 --- a/docs/docsite/rst/plugins/shell.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. _shell_plugins: - -Shell plugins -============= - -.. contents:: - :local: - :depth: 2 - -Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with -the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks. - -.. _enabling_shell: - -Enabling shell plugins ----------------------- - -You can add a custom shell plugin by dropping it into a ``shell_plugins`` directory adjacent to your play, inside a role, -or by putting it in one of the shell plugin directory sources configured in :ref:`ansible.cfg `. - -.. warning:: You should not alter which plugin is used unless you have a setup in which the default ``/bin/sh`` - is not a POSIX compatible shell or is not available for execution. - -.. _using_shell: - -Using shell plugins -------------------- - -In addition to the default configuration settings in :ref:`ansible_configuration_settings`, you can use -the connection variable :ref:`ansible_shell_type ` to select the plugin to use. -In this case, you will also want to update the :ref:`ansible_shell_executable ` to match. - -You can further control the settings for each plugin via other configuration options -detailed in the plugin themselves (linked below). - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/strategy.rst b/docs/docsite/rst/plugins/strategy.rst deleted file mode 100644 index 3a90b56c380..00000000000 --- a/docs/docsite/rst/plugins/strategy.rst +++ /dev/null @@ -1,80 +0,0 @@ -.. _strategy_plugins: - -Strategy plugins -================ - -.. contents:: - :local: - :depth: 2 - -Strategy plugins control the flow of play execution by handling task and host scheduling. For more information on using strategy plugins and other ways to control execution order, see :ref:`playbooks_strategies`. - -.. _enable_strategy: - -Enabling strategy plugins -------------------------- - -All strategy plugins shipped with Ansible are enabled by default. You can enable a custom strategy plugin by -putting it in one of the lookup directory sources configured in :ref:`ansible.cfg `. - -.. _using_strategy: - -Using strategy plugins ----------------------- - -Only one strategy plugin can be used in a play, but you can use different ones for each play in a playbook or ansible run. By default Ansible uses the :ref:`linear ` plugin. You can change this default in Ansible :ref:`configuration ` using an environment variable: - -.. code-block:: shell - - export ANSIBLE_STRATEGY=free - -or in the `ansible.cfg` file: - -.. code-block:: ini - - [defaults] - strategy=linear - -You can also specify the strategy plugin in the play via the :ref:`strategy keyword ` in a play: - -.. code-block:: yaml - - - hosts: all - strategy: debug - tasks: - - copy: src=myhosts dest=/etc/hosts - notify: restart_tomcat - - - package: name=tomcat state=present - - handlers: - - name: restart_tomcat - service: name=tomcat state=restarted - -.. _strategy_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t strategy -l`` to see the list of available plugins. -Use ``ansible-doc -t strategy `` to see plugin-specific specific documentation and examples. - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`inventory_plugins` - Inventory plugins - :ref:`callback_plugins` - Callback plugins - :ref:`filter_plugins` - Filter plugins - :ref:`test_plugins` - Test plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/terminal.rst b/docs/docsite/rst/plugins/terminal.rst deleted file mode 100644 index 010805f76c7..00000000000 --- a/docs/docsite/rst/plugins/terminal.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. _terminal_plugins: - -Terminal plugins -================ - -.. contents:: - :local: - :depth: 2 - -Terminal plugins contain information on how to prepare a particular network device's SSH shell is properly initialized to be used with Ansible. This typically includes disabling automatic paging, detecting errors in output, and enabling privileged mode if supported and required on the device. - -These plugins correspond one-to-one to network device platforms. Ansible loads the appropriate terminal plugin automatically based on the ``ansible_network_os`` variable. - -.. _enabling_terminal: - -Adding terminal plugins -------------------------- - -You can extend Ansible to support other network devices by dropping a custom plugin into the ``terminal_plugins`` directory. - -.. _using_terminal: - -Using terminal plugins ------------------------- - -Ansible determines which terminal plugin to use automatically from the ``ansible_network_os`` variable. There should be no reason to override this functionality. - -Terminal plugins operate without configuration. All options to control the terminal are exposed in the ``network_cli`` connection plugin. - -Plugins are self-documenting. Each plugin should document its configuration options. - -.. _terminal_plugin_list: - -Viewing terminal plugins ------------------------- - -These plugins have migrated to collections on `Ansible Galaxy `_. If you installed Ansible version 2.10 or later using ``pip``, you have access to several terminal plugins. To list all available terminal plugins on your control node, type ``ansible-doc -t terminal -l``. To view plugin-specific documentation and examples, use ``ansible-doc -t terminal``. - - -.. seealso:: - - :ref:`Ansible for Network Automation` - An overview of using Ansible to automate networking devices. - :ref:`connection_plugins` - Connection plugins - `User Mailing List `_ - Have a question? Stop by the google group! - `irc.libera.chat `_ - #ansible-network IRC chat channel diff --git a/docs/docsite/rst/plugins/test.rst b/docs/docsite/rst/plugins/test.rst deleted file mode 100644 index 7922c122f77..00000000000 --- a/docs/docsite/rst/plugins/test.rst +++ /dev/null @@ -1,101 +0,0 @@ -.. _test_plugins: - -Test plugins -============= - -.. contents:: - :local: - :depth: 2 - -Test plugins evaluate template expressions and return True or False. With test plugins you can create :ref:`conditionals ` to implement the logic of your tasks, blocks, plays, playbooks, and roles. Ansible uses the `standard tests `_ shipped as part of Jinja, and adds some specialized test plugins. You can :ref:`create custom Ansible test plugins `. - - -.. _enabling_test: - -Enabling test plugins ----------------------- - -You can add a custom test plugin by dropping it into a ``test_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the test plugin directory sources configured in :ref:`ansible.cfg `. - - -.. _using_test: - -Using test plugins -------------------- - -You can use tests anywhere you can use templating in Ansible: in a play, in variables file, or in a Jinja2 template for the :ref:`template ` module. For more information on using test plugins, see :ref:`playbooks_tests`. - -Tests always return ``True`` or ``False``, they are always a boolean, if you need a different return type, you should be looking at filters. - -You can recognize test plugins by the use of the ``is`` statement in a template, they can also be used as part of the ``select`` family of filters. - -.. code-block:: YAML+Jinja - - vars: - is_ready: '{{ task_result is success }}' - - tasks: - - name: conditionals are always in 'template' context - action: dostuff - when: task_result is failed - -Tests will always have an ``_input`` and this is normally what is on the left side of ``is``. Tests can also take additional parameters as you would to most programming functions. These parameters can be either ``positional`` (passed in order) or ``named`` (passed as key=value pairs). When passing both types, positional arguments should go first. - -.. code-block:: YAML+Jinja - - tasks: - - name: pass positional parameter to match test - action: dostuff - when: myurl is match("https://example.com/users/.*/resources") - - - name: pass named parameter to truthy test - action: dostuff - when: myvariable is truthy(convert_bool=True) - - - name: pass both types to 'version' test - action: dostuff - when: sample_semver_var is version('2.0.0-rc.1+build.123', 'lt', version_type='semver') - - -Using test plugins with lists -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As mentioned above, one way to use tests is with the ``select`` family of filters (``select``, ``reject``, ``selectattr``, ``rejectattr``). - -.. code-block:: YAML+Jinja - - # give me only defined variables from a list of variables, using 'defined' test - good_vars: "{{ all_vars|select('defined') }}" - - # this uses the 'equalto' test to filter out non 'fixed' type of addresses from a list - only_fixed_addresses: "{{ all_addresses|selectattr('type', 'equalsto', 'fixed') }}" - - # this does the opposite of the previous one - only_fixed_addresses: "{{ all_addresses|rejectattr('type', 'equalsto', 'fixed') }}" - - -Plugin list ------------ - -You can use ``ansible-doc -t filter -l`` to see the list of available plugins. Use ``ansible-doc -t filter `` to see specific documents and examples. - - - -.. seealso:: - - :ref:`about_playbooks` - An introduction to playbooks - :ref:`playbooks_tests` - Using tests - :ref:`playbooks_conditionals` - Using conditional statements - :ref:`filter_plugins` - Filter plugins - :ref:`playbooks_tests` - Using tests - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/plugins/vars.rst b/docs/docsite/rst/plugins/vars.rst deleted file mode 100644 index 054db623cfb..00000000000 --- a/docs/docsite/rst/plugins/vars.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _vars_plugins: - -Vars plugins -============ - -.. contents:: - :local: - :depth: 2 - -Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins. For more details about variables in Ansible, see :ref:`playbooks_variables`. - -Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. - -The :ref:`host_group_vars ` plugin shipped with Ansible enables reading variables from :ref:`host_variables` and :ref:`group_variables`. - -.. _enable_vars: - -Enabling vars plugins ---------------------- - -You can activate a custom vars plugin by either dropping it into a ``vars_plugins`` directory adjacent to your play, inside a role, or by putting it in one of the directory sources configured in :ref:`ansible.cfg `. - -Most vars plugins are disabled by default. To enable a vars plugin, set ``vars_plugins_enabled`` in the ``defaults`` section of :ref:`ansible.cfg ` or set the ``ANSIBLE_VARS_ENABLED`` environment variable to the list of vars plugins you want to execute. By default, the :ref:`host_group_vars ` plugin shipped with Ansible is enabled. - -Starting in Ansible 2.10, you can use vars plugins in collections. All vars plugins in collections must be explicitly enabled and must use the fully qualified collection name in the format ``namespace.collection_name.vars_plugin_name``. - -.. code-block:: yaml - - [defaults] - vars_plugins_enabled = host_group_vars,namespace.collection_name.vars_plugin_name - -.. _using_vars: - -Using vars plugins ------------------- - -By default, vars plugins are used on demand automatically after they are enabled. - -Starting in Ansible 2.10, vars plugins can be made to run at specific times. `ansible-inventory` does not use these settings, and always loads vars plugins. - -The global setting ``RUN_VARS_PLUGINS`` can be set in ``ansible.cfg`` using ``run_vars_plugins`` in the ``defaults`` section or by the ``ANSIBLE_RUN_VARS_PLUGINS`` environment variable. The default option, ``demand``, runs any enabled vars plugins relative to inventory sources whenever variables are demanded by tasks. You can use the option ``start`` to run any enabled vars plugins relative to inventory sources after importing that inventory source instead. - -You can also control vars plugin execution on a per-plugin basis for vars plugins that support the ``stage`` option. To run the :ref:`host_group_vars ` plugin after importing inventory you can add the following to :ref:`ansible.cfg `: - -.. code-block:: ini - - [vars_host_group_vars] - stage = inventory - -.. _vars_plugin_list: - -Plugin list ------------ - -You can use ``ansible-doc -t vars -l`` to see the list of available vars plugins. Use ``ansible-doc -t vars `` to see plugin-specific documentation and examples. - - -.. seealso:: - - :ref:`cache_plugins` - Cache plugins - :ref:`lookup_plugins` - Lookup plugins - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/porting_guides/core_porting_guides.rst b/docs/docsite/rst/porting_guides/core_porting_guides.rst deleted file mode 100644 index 6ada427ff4a..00000000000 --- a/docs/docsite/rst/porting_guides/core_porting_guides.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _core_porting_guides: - -*************************** -Ansible Core Porting Guides -*************************** - -This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of ``ansible-core`` to the next. - -Please note that this is not a complete list. If you believe any extra information would be useful in these pages, you can edit by clicking `Edit on GitHub` on the top right, or raising an issue. - -.. toctree:: - :maxdepth: 1 - :glob: - - porting_guide_core_2.14 - porting_guide_core_2.13 - porting_guide_core_2.12 - porting_guide_core_2.11 - porting_guide_base_2.10 diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.0.rst b/docs/docsite/rst/porting_guides/porting_guide_2.0.rst deleted file mode 100644 index 876ca5e27e9..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.0.rst +++ /dev/null @@ -1,431 +0,0 @@ - -.. _porting_2.0_guide: - -************************* -Ansible 2.0 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 1.x and Ansible 2.0. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - - -We suggest you read this page along with `Ansible Changelog for 2.0 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -This section discusses any changes you may need to make to your playbooks. - -* Syntax in 1.9.x - -.. code-block:: yaml - - - debug: - msg: "{{ 'test1_junk 1\\\\3' | regex_replace('(.*)_junk (.*)', '\\\\1 \\\\2') }}" - - -* Syntax in 2.0.x - -.. code-block:: yaml - - - debug: - msg: "{{ 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') }}" - - -* Output: - -.. code-block:: yaml - - "msg": "test1 1\\3" - -To make an escaped string that will work on all versions you have two options:: - -- debug: msg="{{ 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') }}" - -uses key=value escaping which has not changed. The other option is to check for the ansible version:: - -"{{ (ansible_version|version_compare('2.0', 'ge'))|ternary( 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') , 'test1_junk 1\\\\3' | regex_replace('(.*)_junk (.*)', '\\\\1 \\\\2') ) }}" - -* trailing newline When a string with a trailing newline was specified in the - playbook through yaml dict format, the trailing newline was stripped. When - specified in key=value format, the trailing newlines were kept. In v2, both - methods of specifying the string will keep the trailing newlines. If you - relied on the trailing newline being stripped, you can change your playbook - using the following as an example:: - - - * Syntax in 1.9.x - - .. code-block:: yaml - - vars: - message: > - Testing - some things - tasks: - - debug: - msg: "{{ message }}" - - - * Syntax in 2.0.x - - .. code-block:: yaml - - vars: - old_message: > - Testing - some things - message: "{{ old_message[:-1] }}" - - debug: - msg: "{{ message }}" - - - * Output - - .. code-block:: yaml - - "msg": "Testing some things" - -* Behavior of templating DOS-type text files changes with Ansible v2. - - A bug in Ansible v1 causes DOS-type text files (using a carriage return and newline) to be templated to Unix-type text files (using only a newline). In Ansible v2 this long-standing bug was finally fixed and DOS-type text files are preserved correctly. This may be confusing when you expect your playbook to not show any differences when migrating to Ansible v2, while in fact you will see every DOS-type file being completely replaced (with what appears to be the exact same content). - -* When specifying complex args as a variable, the variable must use the full jinja2 - variable syntax (```{{var_name}}```) - bare variable names there are no longer accepted. - In fact, even specifying args with variables has been deprecated, and will not be - allowed in future versions: - -.. code-block:: yaml - - --- - - hosts: localhost - connection: local - gather_facts: false - vars: - my_dirs: - - { path: /tmp/3a, state: directory, mode: 0755 } - - { path: /tmp/3b, state: directory, mode: 0700 } - tasks: - - file: - args: "{{item}}" - with_items: "{{my_dirs}}" - -* porting task includes -* More dynamic. Corner-case formats that were not supposed to work now do not, as expected. -* variables defined in the yaml dict format see `issue 13324 `_ -* templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string. - If you need the old behavior, quote the value to pass it around as a string. -* Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`. - You can override the `null_representation` setting to an empty string in your config file by setting the :envvar:`ANSIBLE_NULL_REPRESENTATION` environment variable. -* Extras callbacks must be enabled in ansible.cfg. Copying is no longer necessary but you must enable them in ansible.cfg. -* dnf module has been rewritten. Some minor changes in behavior may be observed. -* win_updates has been rewritten and works as expected now. -* from 2.0.1 onwards, the implicit setup task from gather_facts now correctly inherits everything from play, but this might cause issues for those setting - `environment` at the play level and depending on `ansible_env` existing. Previously this was ignored but now might issue an 'Undefined' error. - -Deprecated ----------- - -While all items listed here will show a deprecation warning message, they still work as they did in 1.9.x. Please note that they will be removed in 2.2 (Ansible always waits two major releases to remove a deprecated feature). - -* Bare variables in ``with_`` loops should instead use the ``"{{ var }}"`` syntax, which helps eliminate ambiguity. -* The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead. -* Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error. -* Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. Example of a deprecated variant: - -.. code-block:: yaml - - - hosts: localhost - gather_facts: no - vars: - debug_params: - msg: "hello there" - tasks: - - debug: "{{debug_params}}" - - debug: - args: "{{debug_params}}" - -Example of a recommended variant: - -.. code-block:: yaml - - - hosts: localhost - gather_facts: no - vars: - debug_params: - msg: "hello there" - tasks: - - debug: - msg: "{{debug_params['msg']}}" - -* Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern. -* Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y]. -* Playbooks using privilege escalation should always use "become*" options rather than the old su*/sudo* options. -* The "short form" for vars_prompt is no longer supported. - For example:: - - vars_prompt: - variable_name: "Prompt string" - -* Specifying variables at the top level of a task include statement is no longer supported. For example:: - - - include_tasks: foo.yml - a: 1 - -Should now be:: - - - include_tasks: foo.yml - vars: - a: 1 - -* Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only. -* Bare variables in the `environment` dictionary (for plays/tasks/and so on) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'. -* Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task. - For example:: - - - include_tasks: foo.yml tags=a,b,c - - Should be:: - - - include_tasks: foo.yml - tags: [a, b, c] - -* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin. - - -Other caveats -------------- - -Here are some corner cases encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored. - -* Bad variable composition:: - - with_items: myvar_{{rest_of_name}} - - This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead.:: - - hostvars[inventory_hostname]['myvar_' + rest_of_name] - -* Misspelled directives:: - - - task: dostuf - becom: yes - - The task always ran without using privilege escalation (for that you need `become`) but was also silently ignored so the play 'ran' even though it should not, now this is a parsing error. - - -* Duplicate directives:: - - - task: dostuf - when: True - when: False - - The first `when` was ignored and only the 2nd one was used as the play ran w/o warning it was ignoring one of the directives, now this produces a parsing error. - -* Conflating variables and directives:: - - - role: {name=rosy, port=435 } - - # in tasks/main.yml - - wait_for: port={{port}} - - The `port` variable is reserved as a play/task directive for overriding the connection port, in previous versions this got conflated with a variable named `port` and was usable - later in the play, this created issues if a host tried to reconnect or was using a non caching connection. Now it will be correctly identified as a directive and the `port` variable - will appear as undefined, this now forces the use of non conflicting names and removes ambiguity when adding settings and variables to a role invocation. - -* Bare operations on `with_`:: - - with_items: var1 + var2 - - An issue with the 'bare variable' features, which was supposed only template a single variable without the need of braces ({{ )}}, would in some versions of Ansible template full expressions. - Now you need to use proper templating and braces for all expressions everywhere except conditionals (`when`):: - - with_items: "{{var1 + var2}}" - - The bare feature itself is deprecated as an undefined variable is indistinguishable from a string which makes it difficult to display a proper error. - -Porting plugins -=============== - -In ansible-1.9.x, you would generally copy an existing plugin to create a new one. Simply implementing the methods and attributes that the caller of the plugin expected made it a plugin of that type. In ansible-2.0, most plugins are implemented by subclassing a base class for each plugin type. This way the custom plugin does not need to contain methods which are not customized. - - -Lookup plugins --------------- - -* lookup plugins ; import version - - -Connection plugins ------------------- - -* connection plugins - -Action plugins --------------- - - -* action plugins - -Callback plugins ----------------- - -Although Ansible 2.0 provides a new callback API the old one continues to work -for most callback plugins. However, if your callback plugin makes use of -:attr:`self.playbook`, :attr:`self.play`, or :attr:`self.task` then you will -have to store the values for these yourself as ansible no longer automatically -populates the callback with them. Here's a short snippet that shows you how: - -.. code-block:: python - - import os - from ansible.plugins.callback import CallbackBase - - class CallbackModule(CallbackBase): - def __init__(self): - self.playbook = None - self.playbook_name = None - self.play = None - self.task = None - - def v2_playbook_on_start(self, playbook): - self.playbook = playbook - self.playbook_name = os.path.basename(self.playbook._file_name) - - def v2_playbook_on_play_start(self, play): - self.play = play - - def v2_playbook_on_task_start(self, task, is_conditional): - self.task = task - - def v2_on_any(self, *args, **kwargs): - self._display.display('%s: %s: %s' % (self.playbook_name, - self.play.name, self.task)) - - -Connection plugins ------------------- - -* connection plugins - - -Hybrid plugins -============== - -In specific cases you may want a plugin that supports both ansible-1.9.x *and* ansible-2.0. Much like porting plugins from v1 to v2, you need to understand how plugins work in each version and support both requirements. - -Since the ansible-2.0 plugin system is more advanced, it is easier to adapt your plugin to provide similar pieces (subclasses, methods) for ansible-1.9.x as ansible-2.0 expects. This way your code will look a lot cleaner. - -You may find the following tips useful: - -* Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (for example, ``__init__``) - -* When ansible-2.0 python modules are imported, and they fail (ansible-1.9.x), catch the ``ImportError`` exception and perform the equivalent imports for ansible-1.9.x. With possible translations (for example, importing specific methods). - -* Use the existence of these methods as a qualifier to what version of Ansible you are running. So rather than using version checks, you can do capability checks instead. (See examples below) - -* Document for each if-then-else case for which specific version each block is needed. This will help others to understand how they have to adapt their plugins, but it will also help you to remove the older ansible-1.9.x support when it is deprecated. - -* When doing plugin development, it is very useful to have the ``warning()`` method during development, but it is also important to emit warnings for deadends (cases that you expect should never be triggered) or corner cases (for example, cases where you expect misconfigurations). - -* It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes and methods are available. - - -Lookup plugins --------------- - -As a simple example we are going to make a hybrid ``fileglob`` lookup plugin. - -.. code-block:: python - - from __future__ import (absolute_import, division, print_function) - __metaclass__ = type - - import os - import glob - - try: - # ansible-2.0 - from ansible.plugins.lookup import LookupBase - except ImportError: - # ansible-1.9.x - - class LookupBase(object): - def __init__(self, basedir=None, runner=None, **kwargs): - self.runner = runner - self.basedir = self.runner.basedir - - def get_basedir(self, variables): - return self.basedir - - try: - # ansible-1.9.x - from ansible.utils import (listify_lookup_plugin_terms, path_dwim, warning) - except ImportError: - # ansible-2.0 - from ansible.utils.display import Display - warning = Display().warning - - class LookupModule(LookupBase): - - # For ansible-1.9.x, we added inject=None as valid argument - def run(self, terms, inject=None, variables=None, **kwargs): - - # ansible-2.0, but we made this work for ansible-1.9.x too ! - basedir = self.get_basedir(variables) - - # ansible-1.9.x - if 'listify_lookup_plugin_terms' in globals(): - terms = listify_lookup_plugin_terms(terms, basedir, inject) - - ret = [] - for term in terms: - term_file = os.path.basename(term) - - # For ansible-1.9.x, we imported path_dwim() from ansible.utils - if 'path_dwim' in globals(): - # ansible-1.9.x - dwimmed_path = path_dwim(basedir, os.path.dirname(term)) - else: - # ansible-2.0 - dwimmed_path = self._loader.path_dwim_relative(basedir, 'files', os.path.dirname(term)) - - globbed = glob.glob(os.path.join(dwimmed_path, term_file)) - ret.extend(g for g in globbed if os.path.isfile(g)) - - return ret - -.. Note:: In the above example we did not use the ``warning()`` method as we had no direct use for it in the final version. However we left this code in so people can use this part during development/porting/use. - - - -Connection plugins ------------------- - -* connection plugins - -Action plugins --------------- - -* action plugins - -Callback plugins ----------------- - -* callback plugins - -Connection plugins ------------------- - -* connection plugins - - -Porting custom scripts -====================== - -Custom scripts that used the ``ansible.runner.Runner`` API in 1.x have to be ported in 2.x. Please refer to: :ref:`developing_api` diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.10.rst b/docs/docsite/rst/porting_guides/porting_guide_2.10.rst deleted file mode 100644 index ff0a1eff690..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.10.rst +++ /dev/null @@ -1,962 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_base_2.10.rst) - -.. _porting_2.10_guide: - -========================== -Ansible 2.10 Porting Guide -========================== - -.. warning:: - - In Ansible 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. Your playbooks should continue to work without any changes. We recommend you start using the fully-qualified collection name (FQCN) in your playbooks as the explicit and authoritative indicator of which collection to use as some collections may contain duplicate module names. You can search the `index of all modules `_ to find the collection a module has been relocated to. - -This section discusses the behavioral changes between Ansible 2.9 and Ansible 2.10. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with the `Ansible Changelog for 2.10 `_ to understand what updates you may need to make. - -Since 2.10, Ansible consists of two parts: - -* ansible-base, which includes the command line tools with a small selection of plugins and modules, and -* a `set of collections `_. - -The :ref:`porting_2.10_guide_base` is included in this porting guide. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - :local: - :depth: 2 - - -Playbook -======== - -* Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean - Example: ``diff: yes-`` was returning ``False``. -* A new fact, ``ansible_processor_nproc`` reflects the number of vcpus - available to processes (falls back to the number of vcpus available to - the scheduler). - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or - collections to Galaxy through ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI through a token file (default location - ``~/.ansible/galaxy_token``) or (insecurely) through the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -* Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`. - - -Modules -======= - -.. warning:: - - Links on this page may not point to the most recent versions of modules. We will update them when we can. - -* Version 2.10.0 of ansible-base changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.10.1, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Noteworthy module changes -------------------------- - -* Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves. -* Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``. - - -Plugins -======= - -Lookup plugin names case-sensitivity ------------------------------------- - -* Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked through ``with_``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive. - -Noteworthy plugin changes -------------------------- - -* Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching. -* Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``. - -Action plugins which execute modules should use fully-qualified module names ----------------------------------------------------------------------------- - -* Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended. - -Porting custom scripts -====================== - -No notable changes - -Porting Guide for v2.10.7 -========================= - -Breaking Changes ----------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736). - -Major Changes -------------- - -- Restricting the version of the community.okd collection to 1.0.0. The previously included version, 1.0.1, had a dependency on kubernetes.core and thus required the installation of an additional collection that was not included in Ansible 2.10. Version 1.0.0 is essentially identical to 1.0.1, except that it uses community.kubernetes, which is included in Ansible 2.10. - -ovirt.ovirt -~~~~~~~~~~~ - -- ovirt_system_option_info - Add new module (https://github.com/oVirt/ovirt-ansible-collection/pull/206). - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- add new tests (find with no result, search many) -- add related tests -- add support for ServiceNOW table api display_value exclude_reference_link and suppress_pagination_header -- use new API for pysnow >=0.6.0 - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_bgp` and `nxos_bgp_neighbor` modules in favor of `nxos_bgp_global` resource module. - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_host_firewall_manager - the creation of new rule with no ``allowed_ip`` entry in the ``allowed_hosts`` dictionary won't be allowed after 2.0.0 release. - -Porting Guide for v2.10.6 -========================= - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 2.0.0, the kubevirt modules will be moved to the `community.kubevirt `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use kubevirt modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.kubevirt.`` instead of ``community.general.``, - for example replace ``community.general.kubevirt_vm`` in a task by ``community.kubevirt.kubevirt_vm``. - - If you use ansible-base and installed ``community.general`` manually and rely on the kubevirt modules, you have to make sure to install the ``community.kubevirt`` collection as well. - If you are using FQCNs, for example ``community.general.kubevirt_vm`` instead of ``kubevirt_vm``, it will continue working, but we still recommend to adjust the FQCNs as well. - -community.network -~~~~~~~~~~~~~~~~~ - -- For community.network 2.0.0, the Cisco NSO modules will be moved to the `cisco.nso `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use Cisco NSO modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``cisco.nso.`` instead of ``community.network.``, - for example replace ``community.network.nso_config`` in a task by ``cisco.nso.nso_config``. - - If you use ansible-base and installed ``community.network`` manually and rely on the Cisco NSO modules, you have to make sure to install the ``cisco.nso`` collection as well. - If you are using FQCNs, for example ``community.network.nso_config`` instead of ``nso_config``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.network 2.0.0, the FortiOS modules will be moved to the `community.fortios `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use FortiOS modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.fortios.`` instead of ``community.network.``, - for example replace ``community.network.fmgr_device`` in a task by ``community.fortios.fmgr_device``. - - If you use ansible-base and installed ``community.network`` manually and rely on the FortiOS modules, you have to make sure to install the ``community.fortios`` collection as well. - If you are using FQCNs, for example ``community.network.fmgr_device`` instead of ``fmgr_device``, it will continue working, but we still recommend to adjust the FQCNs as well. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Added async_timeout parameter to bigip_ucs_fetch module to allow customization of module wait for async interface -- Changed bigip_ucs_fetch module to use asynchronous interface when generating UCS files - -Porting Guide for v2.10.5 -========================= - -Breaking Changes ----------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - the ``VAULT_ADDR`` environment variable is now checked last for the ``url`` parameter. For details on which use cases are impacted, see (https://github.com/ansible-collections/community.hashi_vault/issues/8). - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 2.0.0, the Google modules will be moved to the `community.google `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use Google modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.google.`` instead of ``community.general.``, - for example replace ``community.general.gcpubsub`` in a task by ``community.google.gcpubsub``. - - If you use ansible-base and installed ``community.general`` manually and rely on the Google modules, you have to make sure to install the ``community.google`` collection as well. - If you are using FQCNs, for example ``community.general.gcpubsub`` instead of ``gcpubsub``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.general 2.0.0, the OC connection plugin will be moved to the `community.okd `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use OC connection plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.okd.oc`` instead of ``community.general.oc``. - - If you use ansible-base and installed ``community.general`` manually and rely on the OC connection plugin, you have to make sure to install the ``community.okd`` collection as well. - If you are using FQCNs, in other words ``community.general.oc`` instead of ``oc``, it will continue working, but we still recommend to adjust this FQCN as well. -- For community.general 2.0.0, the hashi_vault lookup plugin will be moved to the `community.hashi_vault `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use hashi_vault lookup plugin from this collection, you will need to adjust your playbooks and roles to use FQCNs ``community.hashi_vault.hashi_vault`` instead of ``community.general.hashi_vault``. - - If you use ansible-base and installed ``community.general`` manually and rely on the hashi_vault lookup plugin, you have to make sure to install the ``community.hashi_vault`` collection as well. - If you are using FQCNs, in other words ``community.general.hashi_vault`` instead of ``hashi_vault``, it will continue working, but we still recommend to adjust this FQCN as well. - -netbox.netbox -~~~~~~~~~~~~~ - -- nb_inventory - Add ``dns_name`` option that adds ``dns_name`` to the host when ``True`` and device has a primary IP address. (#394) -- nb_inventory - Add ``status`` as a ``group_by`` option. (398) -- nb_inventory - Move around ``extracted_primary_ip`` to allow for ``config_context`` or ``custom_field`` to overwrite. (#377) -- nb_inventory - Services are now a list of integers due to NetBox 2.10 changes. (#396) -- nb_lookup - Allow ID to be passed in and use ``.get`` instead of ``.filter``. (#376) -- nb_lookup - Allow ``api_endpoint`` and ``token`` to be found through env. (#391) - -Deprecated Features -------------------- - -community.aws -~~~~~~~~~~~~~ - -- ec2_vpc_igw_info - After 2022-06-22 the ``convert_tags`` parameter default value will change from ``False`` to ``True`` to match the collection standard behavior (https://github.com/ansible-collections/community.aws/pull/318). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - currently ``published_ports`` can contain port mappings next to the special value ``all``, in which case the port mappings are ignored. This behavior is deprecated for community.docker 2.0.0, at which point it will either be forbidden, or this behavior will be properly implemented similar to how the Docker CLI tool handles this (https://github.com/ansible-collections/community.docker/issues/8, https://github.com/ansible-collections/community.docker/pull/60). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - ``VAULT_ADDR`` environment variable for option ``url`` will have its precedence lowered in 1.0.0; use ``ANSIBLE_HASHI_VAULT_ADDR`` to intentionally override a config value (https://github.com/ansible-collections/community.hashi_vault/issues/8). -- hashi_vault - ``VAULT_AUTH_METHOD`` environment variable for option ``auth_method`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/17). -- hashi_vault - ``VAULT_ROLE_ID`` environment variable for option ``role_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_ROLE_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_SECRET_ID`` environment variable for option ``secret_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_SECRET_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_TOKEN_FILE`` environment variable for option ``token_file`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). -- hashi_vault - ``VAULT_TOKEN_PATH`` environment variable for option ``token_path`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). - -Porting Guide for v2.10.4 -========================= - -Breaking Changes ----------------- - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - now requires the `ipaddress `_ library (https://github.com/ansible-collections/community.hrobot/pull/2). - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 2.0.0, the Hetzner Robot modules will be moved to the `community.hrobot `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use Hetzner Robot modules from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.hrobot.`` instead of ``community.general.hetzner_``, - for example replace ``community.general.hetzner_firewall_info`` in a task by ``community.hrobot.firewall_info``. - - If you use ansible-base and installed ``community.general`` manually and rely on the Hetzner Robot modules, you have to make sure to install the ``community.hrobot`` collection as well. - If you are using FQCNs, i.e. ``community.general.hetzner_failover_ip`` instead of ``hetzner_failover_ip``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.general 2.0.0, the ``docker`` modules and plugins will be moved to the `community.docker `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use ``docker`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.docker.`` instead of ``community.general.``, - for example replace ``community.general.docker_container`` in a task by ``community.docker.docker_container``. - - If you use ansible-base and installed ``community.general`` manually and rely on the ``docker`` content, you have to make sure to install the ``community.docker`` collection as well. - If you are using FQCNs, i.e. ``community.general.docker_container`` instead of ``docker_container``, it will continue working, but we still recommend to adjust the FQCNs as well. -- For community.general 2.0.0, the ``postgresql`` modules and plugins will be moved to the `community.postgresql `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use ``postgresql`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.postgresql.`` instead of ``community.general.``, - for example replace ``community.general.postgresql_info`` in a task by ``community.postgresql.postgresql_info``. - - If you use ansible-base and installed ``community.general`` manually and rely on the ``postgresql`` content, you have to make sure to install the ``community.postgresql`` collection as well. - If you are using FQCNs, i.e. ``community.general.postgresql_info`` instead of ``postgresql_info``, it will continue working, but we still recommend to adjust the FQCNs as well. -- The community.general collection no longer depends on the ansible.posix collection (https://github.com/ansible-collections/community.general/pull/1157). - -community.network -~~~~~~~~~~~~~~~~~ - -- For community.network 2.0.0, the ``routeros`` modules and plugins will be moved to the `community.routeros `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use ``routeros`` content from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``community.routeros.`` instead of ``community.network.routeros_``, - for example replace ``community.network.routeros_api`` in a task by ``community.routeros.api``. - - If you use ansible-base and installed ``community.network`` manually and rely on the ``routeros`` content, you have to make sure to install the ``community.routeros`` collection as well. - If you are using FQCNs, i.e. ``community.network.routeros_command`` instead of ``routeros_command``, it will continue working, but we still recommend to adjust the FQCNs as well. -- In community.network 2.0.0, the ``fortimanager`` httpapi plugin will be removed and replaced by a redirect to the corresponding plugin in the fortios.fortimanager collection. For Ansible 2.10 and ansible-base 2.10 users, this means that it will continue to work assuming that collection is installed. For Ansible 2.9 users, this means that they have to adjust the FQCN from ``community.network.fortimanager`` to ``fortios.fortimanager.fortimanager`` (https://github.com/ansible-collections/community.network/pull/151). - -community.okd -~~~~~~~~~~~~~ - -- Add custom k8s module, integrate better Molecule tests (https://github.com/ansible-collections/community.okd/pull/7). -- Add downstream build scripts to build redhat.openshift (https://github.com/ansible-collections/community.okd/pull/20). -- Add openshift connection plugin, update inventory plugin to use it (https://github.com/ansible-collections/community.okd/pull/18). -- Add openshift_process module for template rendering and optional application of rendered resources (https://github.com/ansible-collections/community.okd/pull/44). -- Add openshift_route module for creating routes from services (https://github.com/ansible-collections/community.okd/pull/40). -- Initial content migration from community.kubernetes (https://github.com/ansible-collections/community.okd/pull/3). -- openshift_auth - new module (migrated from k8s_auth in community.kubernetes) (https://github.com/ansible-collections/community.okd/pull/33). - -Removed Features ----------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the default of ``networks_cli_compatible`` changed to ``true`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the unused option ``trust_image_content`` has been removed (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - ``state=build`` has been removed. Use ``present`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``container_limits``, ``dockerfile``, ``http_timeout``, ``nocache``, ``rm``, ``path``, ``buildargs``, ``pull`` have been removed. Use the corresponding suboptions of ``build`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``force`` option has been removed. Use the more specific ``force_*`` options instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``source`` option is now mandatory (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``use_tls`` option has been removed. Use ``tls`` and ``validate_certs`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the default of the ``build.pull`` option changed to ``false`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image_facts - this alias is on longer available, use ``docker_image_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - the ``ipam_options`` option has been removed. Use ``ipam_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_service - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm - ``state=inspect`` has been removed. Use ``docker_swarm_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``constraints`` option has been removed. Use ``placement.constraints`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``limit_cpu`` and ``limit_memory`` options has been removed. Use the corresponding suboptions in ``limits`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``log_driver`` and ``log_driver_options`` options has been removed. Use the corresponding suboptions in ``logging`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``reserve_cpu`` and ``reserve_memory`` options has been removed. Use the corresponding suboptions in ``reservations`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``restart_policy``, ``restart_policy_attempts``, ``restart_policy_delay`` and ``restart_policy_window`` options has been removed. Use the corresponding suboptions in ``restart_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``update_delay``, ``update_parallelism``, ``update_failure_action``, ``update_monitor``, ``update_max_failure_ratio`` and ``update_order`` options has been removed. Use the corresponding suboptions in ``update_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - the ``force`` option has been removed. Use ``recreate`` instead (https://github.com/ansible-collections/community.docker/pull/1). - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- django_manage - the parameter ``liveserver`` relates to a no longer maintained third-party module for django. It is now deprecated, and will be remove in community.general 3.0.0 (https://github.com/ansible-collections/community.general/pull/1154). -- proxmox - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- proxmox_kvm - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- syspatch - deprecate the redundant ``apply`` argument (https://github.com/ansible-collections/community.general/pull/360). - -community.network -~~~~~~~~~~~~~~~~~ - -- Deprecate connection=local support for network platforms using persistent framework (https://github.com/ansible-collections/community.network/pull/120). - -Porting Guide for v2.10.2 -========================= - -Breaking Changes ----------------- - -Ansible-base -~~~~~~~~~~~~ - -- ansible-galaxy login command has been removed (see https://github.com/ansible/ansible/issues/71560) - -Major Changes -------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Add phone home Teem integration into all modules, functionality can be disabled by setting up F5_TEEM environment variable or no_f5_teem provider parameter - -ovirt.ovirt -~~~~~~~~~~~ - -- cluster_upgrade - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/94). -- disaster_recovery - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/134). -- engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/69). -- hosted_engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/106). -- image_template - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/95). -- infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/92). -- manageiq - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/97). -- repositories - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/96). -- shutdown_env - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/112). -- vm_infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/93). - -Removed Features ----------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed arp_state parameter from the bigip_virtual_address module - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_interface_ospf` in favor of `nxos_ospf_interfaces` Resource Module. - -Porting Guide for v2.10.1 -========================= - -Major Changes -------------- - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- k8s - Add support for template parameter (https://github.com/ansible-collections/community.kubernetes/pull/230). -- k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/community.kubernetes/pull/193). - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_smu` in favor of `nxos_rpm` module. -- The `nxos_ospf_vrf` module is deprecated by `nxos_ospfv2` and `nxos_ospfv3` Resource Modules. - -Porting Guide for v2.10.0 -========================= - -Known Issues ------------- - -- Due to a limitation in pip, you cannot ``pip install --upgrade`` from ansible-2.9 or earlier to ansible-2.10 or higher. Instead, you must explicitly use ``pip uninstall ansible`` before pip installing the new version. If you attempt to upgrade Ansible with pip without first uninstalling, the installer warns you to uninstall first. -- The individual collections that make up the ansible-2.10.0 package can be viewed independently. However, they are not currently listed by ansible-galaxy. To view these collections with ansible-galaxy, explicitly specify where ansible has installed the collections -- ``COLLECTION_INSTALL=$(python -c 'import ansible, os.path ; print("%s/../ansible_collections" % os.path.dirname(ansible.__file__))') ansible-galaxy collection list -p "$COLLECTION_INSTALL"``. -- These fortios modules are not automatically redirected from their 2.9.x names to the new 2.10.x names within collections. You must modify your playbooks to use fully qualified collection names for them. You can use the documentation (https://docs.ansible.com/ansible/2.10/collections/fortinet/fortios/) for the ``fortinet.fortios`` collection to determine what the fully qualified collection names are. - - * fortios_address - * fortios_config - * fortios_firewall_DoS_policy - * fortios_firewall_DoS_policy6 - * fortios_ipv4_policy - * fortios_switch_controller_802_1X_settings - * fortios_switch_controller_security_policy_802_1X - * fortios_system_firmware_upgrade - * fortios_system_nd_proxy - * fortios_webfilter - -community.grafana -~~~~~~~~~~~~~~~~~ - -- grafana_datasource doesn't set password correctly (#113) - -Breaking Changes ----------------- - -- cisco.nxos.nxos_igmp_interface - no longer supports the deprecated ``oif_prefix`` and ``oif_source`` options. These have been superseded by ``oif_ps``. -- community.grafana.grafana_dashboard - the parameter ``message`` is renamed to ``commit_message`` since ``message`` is used by Ansible Core engine internally. -- purestorage.flashblade.purefb_fs - no longer supports the deprecated ``nfs`` option. This has been superseded by ``nfsv3``. - -amazon.aws -~~~~~~~~~~ - -- aws_s3 - can now delete versioned buckets even when they are not empty - set mode to delete to delete a versioned bucket and everything in it. - -ansible.windows -~~~~~~~~~~~~~~~ - -- setup - Make sure ``ansible_date_time.epoch`` is seconds since EPOCH in UTC to mirror the POSIX facts. The ``ansible_date_time.epoch_local`` contains seconds since EPOCH in the local timezone for backwards compatibility -- setup - Will now add the IPv6 scope on link local addresses for ``ansible_ip_addresses`` -- setup - ``ansible_processor`` will now return the index before the other values to match the POSIX fact behaviour -- win_find - No longer filters by size on directories, this feature had a lot of bugs, slowed down the module, and not a supported scenario with the ``find`` module. -- win_find - module has been refactored to better match the behaviour of the ``find`` module. Here is what has changed: - * When the directory specified by ``paths`` does not exist or is a file, it will no longer fail and will just warn the user - * Junction points are no longer reported as ``islnk``, use ``isjunction`` to properly report these files. This behaviour matches the win_stat module - * Directories no longer return a ``size``, this matches the ``stat`` and ``find`` behaviour and has been removed due to the difficulties in correctly reporting the size of a directory -- win_user - Change idempotency checks for ``description`` to be case sensitive -- win_user - Change idempotency checks for ``fullname`` to be case sensitive - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_device - Changed tags from string to list -- meraki_device - Removed serial_lldp_cdp parameter -- meraki_device - Removed serial_uplink parameter -- meraki_intrusion_prevention - Rename whitedlisted_rules to allowed_rules -- meraki_mx_l3_firewall - Rule responses are now in a `rules` list -- meraki_mx_l7_firewall - Rename blacklisted_countries to blocked_countries -- meraki_mx_l7_firewall - Rename whitelisted_countries to allowed_countries -- meraki_network - Local and remote status page settings cannot be set during network creation -- meraki_network - `disableRemoteStatusPage` response is now `remote_status_page_enabled` -- meraki_network - `disable_my_meraki_com` response is now `local_status_page_enabled` -- meraki_network - `disable_my_meraki` has been deprecated -- meraki_network - `enable_my_meraki` is now called `local_status_page_enabled` -- meraki_network - `enable_remote_status_page` is now called `remote_status_page_enabled` -- meraki_network - `enabled` response for VLAN status is now `vlans_enabled` -- meraki_network - `tags` and `type` now return a list -- meraki_snmp - peer_ips is now a list -- meraki_switchport - `access_policy_number` is now an int and not a string -- meraki_switchport - `tags` is now a list and not a string -- meraki_webhook - Querying test status now uses state of query. - -community.general -~~~~~~~~~~~~~~~~~ - -- The environment variable for the auth context for the oc.py connection plugin has been corrected (K8S_CONTEXT). It was using an initial lowercase k by mistake. (https://github.com/ansible-collections/community.general/pull/377). -- bigpanda - the parameter ``message`` was renamed to ``deployment_message`` since ``message`` is used by Ansible Core engine internally. -- cisco_spark - the module option ``message`` was renamed to ``msg``, as ``message`` is used internally in Ansible Core engine (https://github.com/ansible/ansible/issues/39295) -- datadog - the parameter ``message`` was renamed to ``notification_message`` since ``message`` is used by Ansible Core engine internally. -- docker_container - no longer passes information on non-anonymous volumes or binds as ``Volumes`` to the Docker daemon. This increases compatibility with the ``docker`` CLI program. Note that if you specify ``volumes: strict`` in ``comparisons``, this could cause existing containers created with docker_container from Ansible 2.9 or earlier to restart. -- docker_container - support for port ranges was adjusted to be more compatible to the ``docker`` command line utility: a one-port container range combined with a multiple-port host range will no longer result in only the first host port be used, but the whole range being passed to Docker so that a free port in that range will be used. -- hashi_vault lookup - now returns the latest version when using the KV v2 secrets engine. Previously, it returned all versions of the secret which required additional steps to extract and filter the desired version. -- log_plays callback - add missing information to the logs generated by the callback plugin. This changes the log message format (https://github.com/ansible-collections/community.general/pull/442). -- pkgng - passing ``name: *`` with ``state: absent`` will no longer remove every installed package from the system. It is now a noop. (https://github.com/ansible-collections/community.general/pull/569). -- pkgng - passing ``name: *`` with ``state: latest`` or ``state: present`` will no longer install every package from the configured package repositories. Instead, ``name: *, state: latest`` will upgrade all already-installed packages, and ``name: *, state: present`` is a noop. (https://github.com/ansible-collections/community.general/pull/569). - -community.network -~~~~~~~~~~~~~~~~~ - -- routeros_facts - allow multiple addresses and neighbors per interface. This makes ``ansible_net_neighbors`` a list instead of a dict (https://github.com/ansible-collections/community.network/pull/6). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_datastore_maintenancemode - now returns ``datastore_status`` instead of Ansible internal key ``results``. -- vmware_guest_custom_attributes - does not require VM name which was a required parameter for releases prior to Ansible 2.10. -- vmware_guest_find - the ``datacenter`` option has been removed. -- vmware_host_kernel_manager - now returns ``host_kernel_status`` instead of Ansible internal key ``results``. -- vmware_host_ntp - now returns ``host_ntp_status`` instead of Ansible internal key ``results``. -- vmware_host_service_manager - now returns ``host_service_status`` instead of Ansible internal key ``results``. -- vmware_tag - now returns ``tag_status`` instead of Ansible internal key ``results``. -- vmware_vmkernel - the options ``ip_address`` and ``subnet_mask`` have been removed; use the suboptions ``ip_address`` and ``subnet_mask`` of the ``network`` option instead. - -community.windows -~~~~~~~~~~~~~~~~~ - -- win_pester - no longer runs all ``*.ps1`` file in the directory specified due to it executing potentially unknown scripts. It will follow the default behaviour of only running tests for files that are like ``*.tests.ps1`` which is built into Pester itself. - -community.zabbix -~~~~~~~~~~~~~~~~ - -- zabbix_javagateway - options ``javagateway_pidfile``, ``javagateway_listenip``, ``javagateway_listenport`` and ``javagateway_startpollers`` renamed to ``zabbix_javagateway_xyz`` (see `UPGRADE.md `_). - -netbox.netbox -~~~~~~~~~~~~~ - -- Change ``ip-addresses`` key in netbox inventory plugin to ``ip_addresses`` (https://github.com/netbox-community/ansible_modules/issues/139) -- Changed ``group`` to ``tenant_group`` in ``netbox_tenant.py`` (https://github.com/netbox-community/ansible_modules/issues/9) -- Changed ``role`` to ``prefix_role`` in ``netbox_prefix.py`` (https://github.com/netbox-community/ansible_modules/issues/9) -- Module failures when required fields aren't provided (https://github.com/netbox-community/ansible_modules/issues/24) -- Renamed ``netbox_interface`` to ``netbox_device_interface`` (https://github.com/netbox-community/ansible_modules/issues/9) -- This version has a few breaking changes due to new namespace and collection name. I felt it necessary to change the name of the lookup plugin and inventory plugin just not to have a non descriptive namespace call to use them. Below is an example: - ``netbox.netbox.netbox`` would be used for both inventory plugin and lookup plugin, but in different contexts so no collision will arise, but confusion will. - I renamed the lookup plugin to ``nb_lookup`` so it will be used with the FQCN ``netbox.netbox.nb_lookup``. - The inventory plugin will now be called within an inventory file by ``netbox.netbox.nb_inventory`` -- To pass in integers through Ansible Jinja filters for a key in ``data`` that - requires querying an endpoint is now done by making it a dictionary with - an ``id`` key. The previous behavior was to just pass in an integer and - it was converted when normalizing the data, but some people may have names - that are all integers and those were being converted erroneously so we made - the decision to change the method to convert to an integer for the NetBox - API. - - :: - - tasks: - - name: Create device within NetBox with only required information - netbox_device: - netbox_url: http://netbox-demo.org:32768 - netbox_token: 0123456789abcdef0123456789abcdef01234567 - data: - name: Test66 - device_type: - id: "{{ some_jinja_variable }}" - device_role: Core Switch - site: Test Site - status: Staged - state: present -- ``pynetbox`` changed to using ``requests.Session()`` to manage the HTTP session - which broke passing in ``ssl_verify`` when building the NetBox API client. - This PR makes ``pynetbox 5.0.4+`` the new required version of `pynetbox` for - the Ansible modules and lookup plugin. (https://github.com/netbox-community/ansible_modules/pull/269) - -theforeman.foreman -~~~~~~~~~~~~~~~~~~ - -- All modules were renamed to drop the ``foreman_`` and ``katello_`` prefixes. - Additionally to the prefix removal, the following modules were further ranamed: - - * katello_upload to content_upload - * katello_sync to repository_sync - * katello_manifest to subscription_manifest - * foreman_search_facts to resource_info - * foreman_ptable to partition_table - * foreman_model to hardware_model - * foreman_environment to puppet_environment - -Major Changes -------------- - -Ansible-base -~~~~~~~~~~~~ - -- Both ansible-doc and ansible-console's help command will error for modules and plugins whose return documentation cannot be parsed as YAML. All modules and plugins passing ``ansible-test sanity --test yamllint`` will not be affected by this. -- Collections may declare a list of supported/tested Ansible versions for the collection. A warning is issued if a collection does not support the Ansible version that loads it (can also be configured as silent or a fatal error). Collections that do not declare supported Ansible versions do not issue a warning/error. -- Plugin routing allows collections to declare deprecation, redirection targets, and removals for all plugin types. -- Plugins that import module_utils and other ansible namespaces that have moved to collections should continue to work unmodified. -- Routing data built into Ansible 2.10 ensures that 2.9 content should work unmodified on 2.10. Formerly included modules and plugins that were moved to collections are still accessible by their original unqualified names, so long as their destination collections are installed. -- When deprecations are done in code, they to specify a ``collection_name`` so that deprecation warnings can mention which collection - or ansible-base - is deprecating a feature. This affects all ``Display.deprecated()`` or ``AnsibleModule.deprecate()`` or ``Ansible.Basic.Deprecate()`` calls, and ``removed_in_version``/``removed_at_date`` or ``deprecated_aliases`` in module argument specs. -- ansible-test now uses a different ``default`` test container for Ansible Collections - -amazon.aws -~~~~~~~~~~ - -- ec2 module_utils - The ``AWSRetry`` decorator no longer catches ``NotFound`` exceptions by default. ``NotFound`` exceptions need to be explicitly added using ``catch_extra_error_codes``. Some AWS modules may see an increase in transient failures due to AWS''s eventual consistency model. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Add libssh connection plugin and refactor network_cli (https://github.com/ansible-collections/ansible.netcommon/pull/30) - -ansible.posix -~~~~~~~~~~~~~ - -- Bootstrap Collection (https://github.com/ansible-collections/ansible.posix/pull/1). - -cisco.meraki -~~~~~~~~~~~~ - -- Rewrite requests method for version 1.0 API and improved readability -- meraki_mr_rf_profile - Configure wireless RF profiles. -- meraki_mr_settings - Configure network settings for wireless. -- meraki_ms_l3_interface - New module -- meraki_ms_ospf - Configure OSPF. - -community.general -~~~~~~~~~~~~~~~~~ - -- docker_container - the ``network_mode`` option will be set by default to the name of the first network in ``networks`` if at least one network is given and ``networks_cli_compatible`` is ``true`` (will be default from community.general 2.0.0 on). Set to an explicit value to avoid deprecation warnings if you specify networks and set ``networks_cli_compatible`` to ``true``. The current default (not specifying it) is equivalent to the value ``default``. -- docker_container - the module has a new option, ``container_default_behavior``, whose default value will change from ``compatibility`` to ``no_defaults``. Set to an explicit value to avoid deprecation warnings. -- gitlab_user - no longer requires ``name``, ``email`` and ``password`` arguments when ``state=absent``. - -community.grafana -~~~~~~~~~~~~~~~~~ - -- Add changelog management for ansible 2.10 (#112) -- grafana_datasource ; adding additional_json_data param - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- Add changelog and fragments and document changelog process (https://github.com/ansible-collections/community.kubernetes/pull/131). -- helm - New module for managing Helm charts (https://github.com/ansible-collections/community.kubernetes/pull/61). -- helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/community.kubernetes/pull/61). -- helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154). -- helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/community.kubernetes/pull/154). -- helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/community.kubernetes/pull/61). -- k8s - Inventory source migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Lookup plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_auth - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_config_resource_name - Filter plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s_exec - New module for executing commands on pods through Kubernetes API (https://github.com/ansible-collections/community.kubernetes/pull/14). -- k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/community.kubernetes/pull/158). -- k8s_info - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/community.kubernetes/pull/16). -- k8s_scale - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_service - Module migrated from Ansible 2.9 to Kubernetes collection. -- kubectl - Connection plugin migrated from Ansible 2.9 to Kubernetes collection. -- openshift - Inventory source migrated from Ansible 2.9 to Kubernetes collection. - -community.libvirt -~~~~~~~~~~~~~~~~~ - -- added generic libvirt inventory plugin -- removed libvirt_lxc inventory script - -dellemc.os10 -~~~~~~~~~~~~ - -- New role os10_aaa - Facilitates the configuration of Authentication Authorization and Accounting (AAA), TACACS and RADIUS server. -- New role os10_acl - Facilitates the configuration of Access Control lists. -- New role os10_bfd - Facilitates the configuration of BFD global attributes. -- New role os10_bgp - Facilitates the configuration of border gateway protocol (BGP) attributes. -- New role os10_copy_config - This role pushes the backup running configuration into a OS10 device. -- New role os10_dns - Facilitates the configuration of domain name service (DNS). -- New role os10_ecmp - Facilitates the configuration of equal cost multi-path (ECMP) for IPv4. -- New role os10_fabric_summary Facilitates to get show system information of all the OS10 switches in the fabric. -- New role os10_flow_monitor Facilitates the configuration of ACL flow-based monitoring attributes. -- New role os10_image_upgrade Facilitates installation of OS10 software images. -- New role os10_interface Facilitates the configuration of interface attributes. -- New role os10_lag Facilitates the configuration of link aggregation group (LAG) attributes. -- New role os10_lldp Facilitates the configuration of link layer discovery protocol (LLDP) attributes at global and interface level. -- New role os10_logging Facilitates the configuration of global logging attributes and logging servers. -- New role os10_network_validation Facilitates validation of wiring connection, BGP neighbors, MTU between neighbors and VLT pair. -- New role os10_ntp Facilitates the configuration of network time protocol (NTP) attributes. -- New role os10_prefix_list Facilitates the configuration of IP prefix-list. -- New role os10_qos Facilitates the configuration of quality of service attributes including policy-map and class-map. -- New role os10_raguard Facilitates the configuration of IPv6 RA Guard attributes. -- New role os10_route_map Facilitates the configuration of route-map attributes. -- New role os10_snmp Facilitates the configuration of global SNMP attributes. -- New role os10_system Facilitates the configuration of hostname and hashing algorithm. -- New role os10_template The role takes the raw string input from the CLI of OS10 device, and returns a structured text in the form of a Python dictionary. -- New role os10_uplink Facilitates the configuration of uplink attributes like uplink-state group. -- New role os10_users Facilitates the configuration of global system user attributes. -- New role os10_vlan Facilitates the configuration of virtual LAN (VLAN) attributes. -- New role os10_vlt Facilitates the configuration of virtual link trunking (VLT). -- New role os10_vrf Facilitates the configuration of virtual routing and forwarding (VRF). -- New role os10_vrrp Facilitates the configuration of virtual router redundancy protocol (VRRP) attributes. -- New role os10_vxlan Facilitates the configuration of virtual extensible LAN (VXLAN) attributes. -- New role os10_xstp Facilitates the configuration of xSTP attributes. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Broke apart bigip_device_auth_radius to implement radius server configuration in bigip_device_auth_server module. Refer to module documentation for usage details -- Remove redundant parameters in f5_provider to fix disparity between documentation and module parameters - -gluster.gluster -~~~~~~~~~~~~~~~ - -- geo_rep - Added the independent module of geo rep with other gluster modules (https://github.com/gluster/gluster-ansible-collection/pull/2). - -ovirt.ovirt -~~~~~~~~~~~ - -- ovirt_disk - Add backup (https://github.com/oVirt/ovirt-ansible-collection/pull/57). -- ovirt_disk - Support direct upload/download (https://github.com/oVirt/ovirt-ansible-collection/pull/35). -- ovirt_host - Add ssh_port (https://github.com/oVirt/ovirt-ansible-collection/pull/60). -- ovirt_vm_os_info - Creation of module (https://github.com/oVirt/ovirt-ansible-collection/pull/26). - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_console - manage Console Lock setting for the FlashArray -- purefa_endpoint - manage VMware protocol-endpoints on the FlashArray -- purefa_eula - sign, or resign, FlashArray EULA -- purefa_inventory - get hardware inventory information from a FlashArray -- purefa_network - manage the physical and virtual network settings on the FlashArray -- purefa_pgsched - manage protection group snapshot and replication schedules on the FlashArray -- purefa_pod - manage ActiveCluster pods in FlashArrays -- purefa_pod_replica - manage ActiveDR pod replica links in FlashArrays -- purefa_proxy - manage the phonehome HTTPS proxy setting for the FlashArray -- purefa_smis - manage SMI-S settings on the FlashArray -- purefa_subnet - manage network subnets on the FlashArray -- purefa_timeout - manage the GUI idle timeout on the FlashArray -- purefa_vlan - manage VLAN interfaces on the FlashArray -- purefa_vnc - manage VNC for installed applications on the FlashArray -- purefa_volume_tags - manage volume tags on the FlashArray - -purestorage.flashblade -~~~~~~~~~~~~~~~~~~~~~~ - -- purefb_alert - manage alert email settings on a FlashBlade -- purefb_bladename - manage FlashBlade name -- purefb_bucket_replica - manage bucket replica links on a FlashBlade -- purefb_connect - manage connections between FlashBlades -- purefb_dns - manage DNS settings on a FlashBlade -- purefb_fs_replica - manage filesystem replica links on a FlashBlade -- purefb_inventory - get information about the hardware inventory of a FlashBlade -- purefb_ntp - manage the NTP settings for a FlashBlade -- purefb_phonehome - manage the phone home settings for a FlashBlade -- purefb_policy - manage the filesystem snapshot policies for a FlashBlade -- purefb_proxy - manage the phone home HTTP proxy settings for a FlashBlade -- purefb_remote_cred - manage the Object Store Remote Credentials on a FlashBlade -- purefb_snmp_agent - modify the FlashBlade SNMP Agent -- purefb_snmp_mgr - manage SNMP Managers on a FlashBlade -- purefb_target - manage remote S3-capable targets for a FlashBlade -- purefb_user - manage local ``pureuser`` account password on a FlashBlade - -Removed Features ----------------- - -Ansible-base -~~~~~~~~~~~~ - -- core - remove support for ``check_invalid_arguments`` in ``AnsibleModule``, ``AzureModule`` and ``UTMModule``. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- module_utils.network.common.utils.ComplexDict has been removed - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_stat - removed the deprecated ``get_md55`` option and ``md5`` return value. - -community.crypto -~~~~~~~~~~~~~~~~ - -- The ``letsencrypt`` module has been removed. Use ``acme_certificate`` instead. - -community.general -~~~~~~~~~~~~~~~~~ - -- conjur_variable lookup - has been moved to the ``cyberark.conjur`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/570). -- core - remove support for ``check_invalid_arguments`` in ``UTMModule``. -- digital_ocean_* - all DigitalOcean modules have been moved to the ``community.digitalocean`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/622). -- infini_* - all infinidat modules have been moved to the ``infinidat.infinibox`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/607). -- logicmonitor - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- logicmonitor_facts - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- mysql_* - all MySQL modules have been moved to the ``community.mysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/633). -- pacman - Removed deprecated ``recurse`` option, use ``extra_args=--recursive`` instead -- proxysql_* - all ProxySQL modules have been moved to the ``community.proxysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/624). - -community.network -~~~~~~~~~~~~~~~~~ - -- onyx - all onyx modules and plugins have been moved to the mellanox.onyx collection. Redirects have been added that will be removed in community.network 2.0.0 (https://github.com/ansible-collections/community.network/pull/83). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_guest_find - Removed deprecated ``datacenter`` option -- vmware_portgroup - removed 'inbound_policy', and 'rolling_order' deprecated options. -- vmware_vmkernel - Removed deprecated ``ip_address`` option; use sub-option ip_address in the network option instead -- vmware_vmkernel - Removed deprecated ``subnet_mask`` option; use sub-option subnet_mask in the network option instead - -community.windows -~~~~~~~~~~~~~~~~~ - -- win_disk_image - removed the deprecated return value ``mount_path`` in favor of ``mount_paths``. -- win_psexec - removed the deprecated ``extra_opts`` option. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Remove _bigip_iapplx_package alias -- Remove _bigip_security_address_list alias -- Remove _bigip_security_port_list alias -- Remove _bigip_traffic_group alias -- Remove bigip_appsvcs_extension module -- Remove bigip_asm_policy module - -Deprecated Features -------------------- - -- The vyos.vyos.vyos_static_route module has been deprecated and will be removed in a later release; use vyos.vyos.vyos_static_routes instead. - -Ansible-base -~~~~~~~~~~~~ - -- Using the DefaultCallback without the correspodning doc_fragment or copying the documentation. -- hash_behaviour - Deprecate ``hash_behaviour`` for future removal. -- script inventory plugin - The 'cache' option is deprecated and will be removed in 2.12. Its use has been removed from the plugin since it has never had any effect. - -amazon.aws -~~~~~~~~~~ - -- All AWS Modules - ``aws_access_key``, ``aws_secret_key`` and ``security_token`` will be made mutually exclusive with ``profile`` after 2022-06-01. -- cloudformation - The ``template_format`` option had no effect since Ansible 2.3 and will be removed after 2022-06-01 -- cloudformation - the ``template_format`` option has been deprecated and will be removed in a later release. It has been ignored by the module since Ansible 2.3. -- data_pipeline - The ``version`` option had no effect and will be removed in after 2022-06-01 -- ec2 - in a later release, the ``group`` and ``group_id`` options will become mutually exclusive. Currently ``group_id`` is ignored if you pass both. -- ec2_ami - The ``no_device`` alias ``NoDevice`` has been deprecated and will be removed after 2022-06-01 -- ec2_ami - The ``virtual_name`` alias ``VirtualName`` has been deprecated and will be removed after 2022-06-01 -- ec2_eip - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_key - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_key - The ``wait`` option had no effect and will be removed after 2022-06-01 -- ec2_key - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5. -- ec2_key - the ``wait`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.5. -- ec2_lc - The ``associate_public_ip_address`` option had no effect and will be removed after 2022-06-01 -- ec2_tag - deprecate the ``list`` option in favor of ec2_tag_info -- ec2_tag - support for ``list`` as a state has been deprecated and will be removed in a later release. The ``ec2_tag_info`` can be used to fetch the tags on an EC2 resource. - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_domain_computer - Deprecated the undocumented ``log_path`` option. This option will be removed in a major release after ``2022-07-01``. -- win_domain_controller - the ``log_path`` option has been deprecated and will be removed in a later release. This was undocumented and only related to debugging information for module development. -- win_package - the ``ensure`` alias for the ``state`` option has been deprecated and will be removed in a later release. Please use ``state`` instead of ``ensure``. -- win_package - the ``productid`` alias for the ``product_id`` option has been deprecated and will be removed in a later release. Please use ``product_id`` instead of ``productid``. -- win_package - the ``username`` and ``password`` options has been deprecated and will be removed in a later release. The same functionality can be done by using ``become: yes`` and ``become_flags: logon_type=new_credentials logon_flags=netcredentials_only`` on the task. -- win_regedit - Deprecated using forward slashes as a path separator, use backslashes to avoid ambiguity between a forward slash in the key name or a forward slash as a path separator. This feature will be removed in a major release after ``2021-07-01``. - -community.aws -~~~~~~~~~~~~~ - -- cloudformation - The ``template_format`` option had no effect since Ansible 2.3 and will be removed after 2022-06-01 -- data_pipeline - The ``version`` option had no effect and will be removed after 2022-06-01 -- data_pipeline - the ``version`` option has been deprecated and will be removed in a later release. It has always been ignored by the module. -- ec2_eip - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_eip - the ``wait_timeout`` option has been deprecated and will be removed in a later release. It has had no effect since Ansible 2.3. -- ec2_key - The ``wait_timeout`` option had no effect and will be removed after 2022-06-01 -- ec2_key - The ``wait`` option had no effect and will be removed after 2022-06-01 -- ec2_lc - The ``associate_public_ip_address`` option had no effect and will be removed after 2022-06-01 -- ec2_lc - the ``associate_public_ip_address`` option has been deprecated and will be removed after a later release. It has always been ignored by the module. -- elb_network_lb - The current default value of the ``state`` option has been deprecated and will change from absent to present after 2022-06-01 -- elb_network_lb - in a later release, the default behaviour for the ``state`` option will change from ``absent`` to ``present``. To maintain the existing behavior explicitly set state to ``absent``. -- iam_managed_policy - The ``fail_on_delete`` option had no effect and will be removed after 2022-06-01 -- iam_managed_policy - the ``fail_on_delete`` option has been deprecated and will be removed after a later release. It has always been ignored by the module. -- iam_policy - The ``policy_document`` will be removed after 2022-06-01. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin. -- iam_policy - The default value of ``skip_duplicates`` will change after 2022-06-01 from ``true`` to ``false``. -- iam_policy - in a later release, the default value for the ``skip_duplicates`` option will change from ``true`` to ``false``. To maintain the existing behavior explicitly set it to ``true``. -- iam_policy - the ``policy_document`` option has been deprecated and will be removed after a later release. To maintain the existing behavior use the ``policy_json`` option and read the file with the ``lookup`` plugin. -- iam_role - The default value of the purge_policies has been deprecated and will change from true to false after 2022-06-01 -- iam_role - in a later release, the ``purge_policies`` option (also know as ``purge_policy``) default value will change from ``true`` to ``false`` -- s3_lifecycle - The ``requester_pays`` option had no effect and will be removed after 2022-06-01 -- s3_lifecycle - the ``requester_pays`` option has been deprecated and will be removed after a later release. It has always been ignored by the module. -- s3_sync - The ``retries`` option had no effect and will be removed after 2022-06-01 -- s3_sync - the ``retries`` option has been deprecated and will be removed after 2022-06-01. It has always been ignored by the module. - -community.crypto -~~~~~~~~~~~~~~~~ - -- openssl_csr - all values for the ``version`` option except ``1`` are deprecated. The value 1 denotes the current only standardized CSR version. - -community.general -~~~~~~~~~~~~~~~~~ - -- The ldap_attr module has been deprecated and will be removed in a later release; use ldap_attrs instead. -- airbrake_deployment - Add deprecation notice for ``token`` parameter and v2 api deploys. This feature will be removed in community.general 3.0.0. -- clc_aa_policy - The ``wait`` option had no effect and will be removed in community.general 3.0.0. -- clc_aa_policy - the ``wait`` parameter will be removed. It has always been ignored by the module. -- docker_container - the ``trust_image_content`` option is now deprecated and will be removed in community.general 3.0.0. It has never been used by the module. -- docker_container - the ``trust_image_content`` option will be removed. It has always been ignored by the module. -- docker_container - the default of ``container_default_behavior`` will change from ``compatibility`` to ``no_defaults`` in community.general 3.0.0. Set the option to an explicit value to avoid a deprecation warning. -- docker_container - the default value for ``network_mode`` will change in community.general 3.0.0, provided at least one network is specified and ``networks_cli_compatible`` is ``true``. See porting guide, module documentation or deprecation warning for more details. -- docker_stack - Return values ``out`` and ``err`` have been deprecated and will be removed in community.general 3.0.0. Use ``stdout`` and ``stderr`` instead. -- docker_stack - the return values ``err`` and ``out`` have been deprecated. Use ``stdout`` and ``stderr`` from now on instead. -- helm - Put ``helm`` module to deprecated. New implementation is available in community.kubernetes collection. -- redfish_config - Deprecate ``bios_attribute_name`` and ``bios_attribute_value`` in favor of new `bios_attributes`` option. -- redfish_config - the ``bios_attribute_name`` and ``bios_attribute_value`` options will be removed. To maintain the existing behavior use the ``bios_attributes`` option instead. -- redfish_config and redfish_command - the behavior to select the first System, Manager, or Chassis resource to modify when multiple are present will be removed. Use the new ``resource_id`` option to specify target resource to modify. -- redfish_config, redfish_command - Behavior to modify the first System, Manager, or Chassis resource when multiple are present is deprecated. Use the new ``resource_id`` option to specify target resource to modify. -- xbps - the ``force`` option never had any effect. It is now deprecated, and will be removed in 3.0.0 (https://github.com/ansible-collections/community.general/pull/568). - -community.vmware -~~~~~~~~~~~~~~~~ - -- The vmware_dns_config module has been deprecated and will be removed in a later release; use vmware_host_dns instead. -- vca - vca_fw, vca_nat, vca_app are deprecated since these modules rely on deprecated part of Pyvcloud library. -- vmware_dns_config - Deprecate in favor of new module vmware_host_dns. -- vmware_guest - deprecate specifying CDROM configuration as a dict, instead use a list. -- vmware_tag_info - in a later release, the module will not return ``tag_facts`` since it does not return multiple tags with the same name and different category id. To maintain the existing behavior use ``tag_info`` which is a list of tag metadata. - -community.zabbix -~~~~~~~~~~~~~~~~ - -- zabbix_proxy (module) - deprecates ``interface`` sub-options ``type`` and ``main`` when proxy type is set to passive through ``status=passive``. Make sure these suboptions are removed from your playbook as they were never supported by Zabbix in the first place. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated bigip_appsvcs_extension module -- Deprecated bigip_device_facts module name -- Deprecated bigiq_device_facts module name diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst b/docs/docsite/rst/porting_guides/porting_guide_2.3.rst deleted file mode 100644 index 9a66c23d0f1..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst +++ /dev/null @@ -1,233 +0,0 @@ - -.. _porting_2.3_guide: - -************************* -Ansible 2.3 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.2 and Ansible 2.3. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - - -We suggest you read this page along with `Ansible Changelog for 2.3 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -Restructured async to work with action plugins ----------------------------------------------- - -In Ansible 2.2 (and possibly earlier) the `async:` keyword could not be used in conjunction with the action plugins such as `service`. This limitation has been removed in Ansible 2.3 - -**NEW** In Ansible 2.3: - - -.. code-block:: yaml - - - name: Install nginx asynchronously - service: - name: nginx - state: restarted - async: 45 - - -OpenBSD version facts ---------------------- - -The `ansible_distribution_release` and `ansible_distribution_version` facts on OpenBSD hosts were reversed in Ansible 2.2 and earlier. This has been changed so that version has the numeric portion and release has the name of the release. - -**OLD** In Ansible 2.2 (and earlier) - - -.. code-block:: bash - - "ansible_distribution": "OpenBSD" - "ansible_distribution_release": "6.0", - "ansible_distribution_version": "release", - -**NEW** In Ansible 2.3: - - -.. code-block:: bash - - "ansible_distribution": "OpenBSD", - "ansible_distribution_release": "release", - "ansible_distribution_version": "6.0", - - -Names Blocks ------------- - -Blocks can now have names, this allows you to avoid the ugly `# this block is for...` comments. - - -**NEW** In Ansible 2.3: - - -.. code-block:: yaml - - - name: Block test case - hosts: localhost - tasks: - - name: Attempt to setup foo - block: - - debug: msg='I execute normally' - - command: /bin/false - - debug: msg='I never execute, cause ERROR!' - rescue: - - debug: msg='I caught an error' - - command: /bin/false - - debug: msg='I also never execute :-(' - always: - - debug: msg="this always executes" - - -Use of multiple tags --------------------- - -Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last specified tag overriding all the other specified tags. This behaviour is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behaviour. - -In 2.4, the default will be to merge the tags. You can enable the old overwriting behavior through the config option. -In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behaviour. - - -Other caveats -------------- - -Here are some rare cases that might be encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored. - - -* Made ``any_errors_fatal`` inheritable from play to task and all other objects in between. - -Modules -======= - -No major changes in this version. - -Modules removed ---------------- - -No major changes in this version. - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.5. Please update your playbooks accordingly. - -* ec2_vpc -* cl_bond -* cl_bridge -* cl_img_install -* cl_interface -* cl_interface_policy -* cl_license -* cl_ports -* nxos_mtu use :ref:`nxos_system ` instead - -.. note:: - - These modules may no longer have documentation in the current release. Please see the - `Ansible 2.3 module documentation - `_ if you need - to know how they worked for porting your playbooks. - - -Noteworthy module changes -------------------------- - -AWS lambda -^^^^^^^^^^ -Previously ignored changes that only affected one parameter. Existing deployments may have outstanding changes that this bug fix will apply. - - -Mount -^^^^^ - -Mount: Some fixes so bind mounts are not mounted each time the playbook runs. - - -Plugins -======= - -No major changes in this version. - -Porting custom scripts -====================== - -No major changes in this version. - -Networking -========== - -There have been a number of changes to number of changes to how Networking Modules operate. - -Playbooks should still use ``connection: local``. - -The following changes apply to: - -* dellos6 -* dellos9 -* dellos10 -* eos -* ios -* iosxr -* junos -* sros -* vyos - -Deprecation of top-level connection arguments ---------------------------------------------- - -**OLD** In Ansible 2.2: - -.. code-block:: yaml - - - name: example of using top-level options for connection properties - ios_command: - commands: show version - host: "{{ inventory_hostname }}" - username: cisco - password: cisco - authorize: yes - auth_pass: cisco - -Will result in: - -.. code-block:: bash - - [WARNING]: argument username has been deprecated and will be removed in a future version - [WARNING]: argument host has been deprecated and will be removed in a future version - [WARNING]: argument password has been deprecated and will be removed in a future version - - -**NEW** In Ansible 2.3: - - -.. code-block:: yaml - - - name: Gather facts - eos_facts: - gather_subset: all - provider: - username: myuser - password: "{{ networkpassword }}" - transport: cli - host: "{{ ansible_host }}" - -ProxyCommand replaces delegate_to ---------------------------------- - -The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport -no longer supports the use of the ``delegate_to`` directive. -In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` -transport, network modules now support the use of ``ProxyCommand``. - -To use ``ProxyCommand`` configure the proxy settings in the Ansible inventory -file to specify the proxy host through ``ansible_ssh_common_args``. - -For details on how to do this see the :ref:`network proxy guide `. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.4.rst b/docs/docsite/rst/porting_guides/porting_guide_2.4.rst deleted file mode 100644 index d58ae48d138..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.4.rst +++ /dev/null @@ -1,227 +0,0 @@ - -.. _porting_2.4_guide: - -************************* -Ansible 2.4 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.3 and Ansible 2.4. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - - -We suggest you read this page along with `Ansible Changelog for 2.4 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Python version -============== - -Ansible will not support Python 2.4 or 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller. - - -Inventory -========= - -Inventory has been refactored to be implemented through plugins and now allows for multiple sources. This change is mostly transparent to users. - -One exception is the ``inventory_dir``, which is now a host variable; previously it could only have one value so it was set globally. -This means you can no longer use it early in plays to determine ``hosts:`` or similar keywords. -This also changes the behaviour of ``add_hosts`` and the implicit localhost; -because they no longer automatically inherit the global value, they default to ``None``. See the module documentation for more information. - -The ``inventory_file`` remains mostly unchanged, as it was always host specific. - -Since there is no longer a single inventory, the 'implicit localhost' doesn't get either of these variables defined. - -A bug was fixed with the inventory path/directory, which was defaulting to the current working directory. This caused ``group_vars`` and ``host_vars`` to be picked up from the current working directory instead of just adjacent to the playbook or inventory directory when a host list (comma separated host names) was provided as inventory. - -Initial playbook relative group_vars and host_vars --------------------------------------------------- - -In Ansible versions prior to 2.4, the inventory system would maintain the context of the initial playbook that was executed. This allowed successively included playbooks from other directories to inherit group_vars and host_vars placed relative to the top level playbook file. - -Due to some behavioral inconsistencies, this functionality will not be included in the new -inventory system starting with Ansible version 2.4. - -Similar functionality can still be achieved by using vars_files, include_vars, or group_vars and host_vars placed relative to the inventory file. - -Deprecated -========== - -Specifying Inventory sources ------------------------------ - -Use of ``--inventory-file`` on the command line is now deprecated. Use ``--inventory`` or ``-i``. -The associated ini configuration key, ``hostfile``, and environment variable, ``ANSIBLE_HOSTS``, -are also deprecated. Replace them with the configuration key ``inventory`` and environment variable :envvar:`ANSIBLE_INVENTORY`. - -Use of multiple tags --------------------- - -Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last one overriding all the previous ones. This behavior is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behavior. - -In 2.4, the default has change to merge the tags. You can enable the old overwriting behavior through the config option. - -In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behavior. - - -Other caveats -------------- - -No major changes in this version. - -Modules -======= - -Major changes in popular modules are detailed here - -* The :ref:`win_shell ` and :ref:`win_command ` modules now properly preserve quoted arguments in the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked to remove the superfluous escaping. See `Issue 23019 `_ for additional detail. - -Modules removed ---------------- - -The following modules no longer exist: - -* None - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.8. Please update your playbooks accordingly. - -* azure, use :ref:`azure_rm_virtualmachine `, which uses the new Resource Manager SDK. -* win_msi, use :ref:`win_package ` instead - -Noteworthy module changes -------------------------- - -* The :ref:`win_get_url ` module has the dictionary ``win_get_url`` in its results deprecated, its content is now also available directly in the resulting output, like other modules. This dictionary will be removed in Ansible 2.8. -* The :ref:`win_unzip ` module no longer includes the dictionary ``win_unzip`` in its results; the contents are now included directly in the resulting output, like other modules. -* The :ref:`win_package ` module return values ``exit_code`` and ``restart_required`` have been deprecated in favor of ``rc`` and ``reboot_required`` respectively. The deprecated return values will be removed in Ansible 2.6. - - -Plugins -======= - -A new way to configure and document plugins has been introduced. This does not require changes to existing setups but developers should start adapting to the new infrastructure now. More details will be available in the developer documentation for each plugin type. - -Vars plugin changes -------------------- - -There have been many changes to the implementation of vars plugins, but both users and developers should not need to change anything to keep current setups working. Developers should consider changing their plugins take advantage of new features. - -The most notable difference to users is that vars plugins now get invoked on demand instead of at inventory build time. This should make them more efficient for large inventories, especially when using a subset of the hosts. - - -.. note:: - - This also creates a difference with group/host_vars when using them adjacent to playbooks. Before, the 'first' playbook loaded determined the variables; now the 'current' playbook does. We are looking to fix this soon, since 'all playbooks' in the path should be considered for variable loading. - - In 2.4.1 we added a toggle to allow you to control this behaviour, 'top' will be the pre 2.4, 'bottom' will use the current playbook hosting the task and 'all' will use them all from top to bottom. - - -Inventory plugins ------------------ - -Developers should start migrating from hardcoded inventory with dynamic inventory scripts to the new Inventory Plugins. The scripts will still work through the ``script`` inventory plugin but Ansible development efforts will now concentrate on writing plugins rather than enhancing existing scripts. - -Both users and developers should look into the new plugins because they are intended to alleviate the need for many of the hacks and workarounds found in the dynamic inventory scripts. - -Callback plugins ----------------- - -Users: - -* Callbacks are now using the new configuration system. Users should not need to change anything as the old system still works, - but you might see a deprecation notice if any callbacks used are not inheriting from the built in classes. Developers need to update them as stated below. - -Developers: - -* If your callback does not inherit from ``CallbackBase`` (directly or indirectly through another callback), it will still work, but issue a deprecation notice. - To avoid this and ensure it works in the future change it to inherit from ``CallbackBase`` so it has the new options handling methods and properties. - You can also implement the new options handling methods and properties but that won't automatically inherit changes added in the future. You can look at ``CallbackBase`` itself and/or ``AnsiblePlugin`` for details. -* Any callbacks inheriting from other callbacks might need to also be updated to contain the same documented options - as the parent or the options won't be available. This is noted in the developer guide. - -Template lookup plugin: Escaping Strings ----------------------------------------- - -Prior to Ansible 2.4, backslashes in strings passed to the template lookup plugin would be escaped -automatically. In 2.4, users are responsible for escaping backslashes themselves. This change -brings the template lookup plugin inline with the template module so that the same backslash -escaping rules apply to both. - -If you have a template lookup like this:: - - - debug: - msg: '{{ lookup("template", "template.j2") }}' - -**OLD** In Ansible 2.3 (and earlier) :file:`template.j2` would look like this: - -.. code-block:: jinja - - {{ "name surname" | regex_replace("^[^\s]+\s+(.*)", "\1") }} - -**NEW** In Ansible 2.4 it should be changed to look like this: - -.. code-block:: jinja - - {{ "name surname" | regex_replace("^[^\\s]+\\s+(.*)", "\\1") }} - -Tests -===== - -Tests succeeded/failed ------------------------ - -Prior to Ansible version 2.4, a task return code of ``rc`` would override a return code of ``failed``. In version 2.4, both ``rc`` and ``failed`` are used to calculate the state of the task. Because of this, test plugins ``succeeded``/``failed``` have also been changed. This means that overriding a task failure with ``failed_when: no`` will result in ``succeeded``/``failed`` returning ``True``/``False``. For example:: - - - command: /bin/false - register: result - failed_when: no - - - debug: - msg: 'This is printed on 2.3' - when: result|failed - - - debug: - msg: 'This is printed on 2.4' - when: result|succeeded - - - debug: - msg: 'This is always printed' - when: result.rc != 0 - -As we can see from the example above, in Ansible 2.3 ``succeeded``/``failed`` only checked the value of ``rc``. - -Networking -========== - -There have been a number of changes to how Networking Modules operate. - -Playbooks should still use ``connection: local``. - -Persistent Connection ---------------------- - -The configuration variables ``connection_retries`` and ``connect_interval`` which were added in Ansible 2.3 are now deprecated. For Ansible 2.4 and later use ``connection_retry_timeout``. - -To control timeouts use ``command_timeout`` rather than the previous top level ``timeout`` variable under ``[default]`` - -See :ref:`Ansible Network debug guide ` for more information. - - -Configuration -============= - - -The configuration system has had some major changes. Users should be unaffected except for the following: - -* All relative paths defined are relative to the `ansible.cfg` file itself. Previously they varied by setting. The new behavior should be more predictable. -* A new macro ``{{CWD}}`` is available for paths, which will make paths relative to the 'current working directory', - this is unsafe but some users really want to rely on this behaviour. - -Developers that were working directly with the previous API should revisit their usage as some methods (for example, ``get_config``) were kept for backwards compatibility but will warn users that the function has been deprecated. - -The new configuration has been designed to minimize the need for code changes in core for new plugins. The plugins just need to document their settings and the configuration system will use the documentation to provide what they need. This is still a work in progress; currently only 'callback' and 'connection' plugins support this. More details will be added to the specific plugin developer guides. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst deleted file mode 100644 index 7a58229d35b..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst +++ /dev/null @@ -1,392 +0,0 @@ -.. _porting_2.5_guide: - -************************* -Ansible 2.5 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.4 and Ansible 2.5. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.5 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -Dynamic includes and attribute inheritance ------------------------------------------- - -In Ansible version 2.4, the concept of dynamic includes (``include_tasks``), as opposed to static imports (``import_tasks``), was introduced to clearly define the differences in how ``include`` works between dynamic and static includes. - -All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a -static ``import_*`` would be inherited by the tasks within. - -This separation was only partially implemented in Ansible version 2.4. As of Ansible version 2.5, this work is complete and the separation now behaves as designed; attributes applied to an ``include_*`` task will not be inherited by the tasks within. - -To achieve an outcome similar to how Ansible worked prior to version 2.5, playbooks should use an explicit application of the attribute on the needed tasks, or use blocks to apply the attribute to many tasks. Another option is to use a static ``import_*`` when possible instead of a dynamic task. - -**OLD** In Ansible 2.4: - -.. code-block:: yaml - - - include_tasks: "{{ ansible_distribution }}.yml" - tags: - - distro_include - -Included file: - -.. code-block:: yaml - - - block: - - debug: - msg: "In included file" - - - apt: - name: nginx - state: latest - -**NEW** In Ansible 2.5: - -Including task: - -.. code-block:: yaml - - - include_tasks: "{{ ansible_distribution }}.yml" - tags: - - distro_include - -Included file: - -.. code-block:: yaml - - - block: - - debug: - msg: "In included file" - - - apt: - name: nginx - state: latest - tags: - - distro_include - -The relevant change in those examples is, that in Ansible 2.5, the included file defines the tag ``distro_include`` again. The tag is not inherited automatically. - -Fixed handling of keywords and inline variables ------------------------------------------------ - -We made several fixes to how we handle keywords and 'inline variables', to avoid conflating the two. Unfortunately these changes mean you must specify whether `name` is a keyword or a variable when calling roles. If you have playbooks that look like this:: - - roles: - - { role: myrole, name: Justin, othervar: othervalue, become: True} - -You will run into errors because Ansible reads name in this context as a keyword. Beginning in 2.5, if you want to use a variable name that is also a keyword, you must explicitly declare it as a variable for the role:: - - roles: - - { role: myrole, vars: {name: Justin, othervar: othervalue}, become: True} - - -For a full list of keywords see :ref:`playbook_keywords`. - -Migrating from with_X to loop ------------------------------ - -.. include:: ../playbook_guide/shared_snippets/with2loop.txt - - -Deprecated -========== - -Jinja tests used as filters ---------------------------- - -Using Ansible-provided jinja tests as filters will be removed in Ansible 2.9. - -Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while jinja tests are referenced as ``variable is test_name``. - -Jinja tests are used for comparisons, while filters are used for data manipulation and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used. - -As of Ansible 2.5, using an Ansible provided jinja test with filter syntax, will display a deprecation error. - -**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this: - -.. code-block:: yaml - - when: - - result | failed - - not result | success - -**NEW** In Ansible 2.5 it should be changed to look like this: - -.. code-block:: yaml - - when: - - result is failed - - results is not successful - -In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests. These new tests make more sense grammatically with the jinja test syntax, such as the new ``successful`` test which aliases ``success``. - -.. code-block:: yaml - - when: result is successful - -See :ref:`playbooks_tests` for more information. - -Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py `_. - -Ansible fact namespacing ------------------------- - -Ansible facts, which have historically been written to names like ``ansible_*`` -in the main facts namespace, have been placed in their own new namespace, -``ansible_facts.*`` For example, the fact ``ansible_distribution`` is now best -queried through the variable structure ``ansible_facts.distribution``. - -A new configuration variable, ``inject_facts_as_vars``, has been added to -ansible.cfg. Its default setting, 'True', keeps the 2.4 behavior of facts -variables being set in the old ``ansible_*`` locations (while also writing them -to the new namespace). This variable is expected to be set to 'False' in a -future release. When ``inject_facts_as_vars`` is set to False, you must -refer to ansible_facts through the new ``ansible_facts.*`` namespace. - -Modules -======= - -Major changes in popular modules are detailed here. - -github_release --------------- - -In Ansible versions 2.4 and older, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module reported state as ``skipped``. -In Ansible version 2.5 and later, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module now reports state as ``changed``. - - -Modules removed ---------------- - -The following modules no longer exist: - -* nxos_mtu use :ref:`nxos_system `'s ``system_mtu`` option or :ref:`nxos_interface ` instead -* cl_interface_policy use :ref:`nclu ` instead -* cl_bridge use :ref:`nclu ` instead -* cl_img_install use :ref:`nclu ` instead -* cl_ports use :ref:`nclu ` instead -* cl_license use :ref:`nclu ` instead -* cl_interface use :ref:`nclu ` instead -* cl_bond use :ref:`nclu ` instead -* ec2_vpc use :ref:`ec2_vpc_net ` along with supporting modules :ref:`ec2_vpc_igw `, :ref:`ec2_vpc_route_table `, :ref:`ec2_vpc_subnet `, :ref:`ec2_vpc_dhcp_option `, :ref:`ec2_vpc_nat_gateway `, :ref:`ec2_vpc_nacl ` instead. -* ec2_ami_search use :ref:`ec2_ami_facts ` instead -* docker use :ref:`docker_container ` and :ref:`docker_image ` instead - -.. note:: - - These modules may no longer have documentation in the current release. Please see the - `Ansible 2.4 module documentation - `_ if you need - to know how they worked for porting your playbooks. - - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly. - -* Apstra's ``aos_*`` modules are deprecated as they do not work with AOS 2.1 or higher. See new modules at `https://github.com/apstra `_. -* nxos_ip_interface use :ref:`nxos_l3_interface ` instead. -* nxos_portchannel use :ref:`nxos_linkagg ` instead. -* nxos_switchport use :ref:`nxos_l2_interface ` instead. -* panos_security_policy use :ref:`panos_security_rule ` instead. -* panos_nat_policy use :ref:`panos_nat_rule ` instead. -* vsphere_guest use :ref:`vmware_guest ` instead. - -Noteworthy module changes -------------------------- - -* The :ref:`stat ` and :ref:`win_stat ` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``. - -This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True`` -and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is -desired. - -* ``osx_say`` module was renamed into :ref:`say `. -* Several modules which could deal with symlinks had the default value of their ``follow`` option - changed as part of a feature to `standardize the behavior of follow - `_: - - * The :ref:`file module ` changed from ``follow=False`` to ``follow=True`` because - its purpose is to modify the attributes of a file and most systems do not allow attributes to be - applied to symlinks, only to real files. - * The :ref:`replace module ` had its ``follow`` parameter removed because it - inherently modifies the content of an existing file so it makes no sense to operate on the link - itself. - * The :ref:`blockinfile module ` had its ``follow`` parameter removed because - it inherently modifies the content of an existing file so it makes no sense to operate on the - link itself. - * In Ansible-2.5.3, the :ref:`template module ` became more strict about its - ``src`` file being proper utf-8. Previously, non-utf8 contents in a template module src file - would result in a mangled output file (the non-utf8 characters would be replaced with a unicode - replacement character). Now, on Python2, the module will error out with the message, "Template - source files must be utf-8 encoded". On Python3, the module will first attempt to pass the - non-utf8 characters through verbatim and fail if that does not succeed. - -Plugins -======= - -As a developer, you can now use 'doc fragments' for common configuration options on plugin types that support the new plugin configuration system. - -Inventory ---------- - -Inventory plugins have been fine tuned, and we have started to add some common features: - -* The ability to use a cache plugin to avoid costly API/DB queries is disabled by default. - If using inventory scripts, some may already support a cache, but it is outside of Ansible's knowledge and control. - Moving to the internal cache will allow you to use Ansible's existing cache refresh/invalidation mechanisms. - -* A new 'auto' plugin, enabled by default, that can automatically detect the correct plugin to use IF that plugin is using our 'common YAML configuration format'. - The previous host_list, script, yaml and ini plugins still work as they did, the auto plugin is now the last one we attempt to use. - If you had customized the enabled plugins you should revise the setting to include the new auto plugin. - -Shell ------ - -Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables. - -For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``. - -Another new setting is ``admin_users`` which allows you to specify a list of users to be considered 'administrators'. Previously this was hardcoded to ``root``. It now it defaults to ``[root, toor, admin]``. This information is used when choosing between your ``remote_temp`` and ``system_temps`` directory. - -For a full list, check the shell plugin you are using, the default shell plugin is ``sh``. - -Those that had to work around the global configuration limitations can now migrate to a per host/group settings, -but also note that the new defaults might conflict with existing usage if the assumptions don't correlate to your environment. - -Filter ------- - -The lookup plugin API now throws an error if a non-iterable value is returned from a plugin. Previously, numbers or -other non-iterable types returned by a plugin were accepted without error or warning. This change was made because plugins should always return a list. Please note that plugins that return strings and other non-list iterable values will not throw an error, but may cause unpredictable behavior. If you have a custom lookup plugin that does not return a list, you should modify it to wrap the return values in a list. - -Lookup -------- - -A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup ` page for more details. - - -Porting custom scripts -====================== - -No notable changes. - -Network -======= - -Expanding documentation ------------------------ - -We're expanding the network documentation. There's new content and a :ref:`new Ansible Network landing page`. We will continue to build the network-related documentation moving forward. - -Top-level connection arguments will be removed in 2.9 ------------------------------------------------------ - -Top-level connection arguments like ``username``, ``host``, and ``password`` are deprecated and will be removed in version 2.9. - -**OLD** In Ansible < 2.4 - -.. code-block:: yaml - - - name: example of using top-level options for connection properties - ios_command: - commands: show version - host: "{{ inventory_hostname }}" - username: cisco - password: cisco - authorize: yes - auth_pass: cisco - -The deprecation warnings reflect this schedule. The task above, run in Ansible 2.5, will result in: - -.. code-block:: yaml - - [DEPRECATION WARNING]: Param 'username' is deprecated. See the module docs for more information. This feature will be removed in version - 2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. - [DEPRECATION WARNING]: Param 'password' is deprecated. See the module docs for more information. This feature will be removed in version - 2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. - [DEPRECATION WARNING]: Param 'host' is deprecated. See the module docs for more information. This feature will be removed in version 2.9. - Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. - -We recommend using the new connection types ``network_cli`` and ``netconf`` (see below), using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`. - -Adding persistent connection types ``network_cli`` and ``netconf`` ------------------------------------------------------------------- - -Ansible 2.5 introduces two top-level persistent connection types, ``network_cli`` and ``netconf``. With ``connection: local``, each task passed the connection parameters, which had to be stored in your playbooks. With ``network_cli`` and ``netconf`` the playbook passes the connection parameters once, so you can pass them at the command line if you prefer. We recommend you use ``network_cli`` and ``netconf`` whenever possible. -Note that eAPI and NX-API still require ``local`` connections with ``provider`` dictionaries. See the :ref:`platform documentation` for more information. Unless you need a ``local`` connection, update your playbooks to use ``network_cli`` or ``netconf`` and to specify your connection variables with standard Ansible connection variables: - -**OLD** In Ansible 2.4 - -.. code-block:: yaml - - --- - vars: - cli: - host: "{{ inventory_hostname }}" - username: operator - password: secret - transport: cli - - tasks: - - nxos_config: - src: config.j2 - provider: "{{ cli }}" - username: admin - password: admin - -**NEW** In Ansible 2.5 - -.. code-block:: ini - - [nxos:vars] - ansible_connection=network_cli - ansible_network_os=nxos - ansible_user=operator - ansible_password=secret - -.. code-block:: yaml - - tasks: - - nxos_config: - src: config.j2 - -Using a provider dictionary with either ``network_cli`` or ``netconf`` will result in a warning. - - -Developers: Shared Module Utilities Moved ------------------------------------------ - -Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``. - -* Platform-independent utilities are found in ``ansible.module_utils.network.common`` - -* Platform-specific utilities are found in ``ansible.module_utils.network.{{ platform }}`` - -If your module uses shared module utilities, you must update all references. For example, change: - -**OLD** In Ansible 2.4 - -.. code-block:: python - - from ansible.module_utils.vyos import get_config, load_config - -**NEW** In Ansible 2.5 - -.. code-block:: python - - from ansible.module_utils.network.vyos.vyos import get_config, load_config - - -See the module utilities developer guide see :ref:`developing_module_utilities` for more information. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.6.rst b/docs/docsite/rst/porting_guides/porting_guide_2.6.rst deleted file mode 100644 index d585c00491f..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.6.rst +++ /dev/null @@ -1,114 +0,0 @@ -.. _porting_2.6_guide: - -************************* -Ansible 2.6 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.5 and Ansible 2.6. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.6 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Playbook -======== - -* The deprecated task option ``always_run`` has been removed, please use ``check_mode: no`` instead. - -Deprecated -========== - -* In the :ref:`nxos_igmp_interface module`, ``oif_prefix`` and ``oif_source`` properties are deprecated. Use ``ois_ps`` parameter with a dictionary of prefix and source to values instead. - -Modules -======= - -Major changes in popular modules are detailed here: - - -Modules removed ---------------- - -The following modules no longer exist: - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly. - -* ``k8s_raw`` use :ref:`k8s ` instead. -* ``openshift_raw`` use :ref:`k8s ` instead. -* ``openshift_scale`` use :ref:`k8s_scale ` instead. - -Noteworthy module changes -------------------------- - -* The ``upgrade`` module option for ``win_chocolatey`` has been removed; use ``state: latest`` instead. -* The ``reboot`` module option for ``win_feature`` has been removed; use the ``win_reboot`` action plugin instead. -* The ``win_iis_webapppool`` module no longer accepts a string for the ``attributes`` module option; use the free form dictionary value instead. -* The ``name`` module option for ``win_package`` has been removed; this is not used anywhere and should just be removed from your playbooks. -* The ``win_regedit`` module no longer automatically corrects the hive path ``HCCC`` to ``HKCC``; use ``HKCC`` because this is the correct hive path. -* The :ref:`file_module` now emits a deprecation warning when ``src`` is specified with a state - other than ``hard`` or ``link`` as it is only supposed to be useful with those. This could have - an effect on people who were depending on a buggy interaction between src and other state's to - place files into a subdirectory. For instance:: - - $ ansible localhost -m file -a 'path=/var/lib src=/tmp/ state=directory' - - Would create a directory named ``/tmp/lib``. Instead of the above, simply spell out the entire - destination path like this:: - - $ ansible localhost -m file -a 'path=/tmp/lib state=directory' - -* The ``k8s_raw`` and ``openshift_raw`` modules have been aliased to the new ``k8s`` module. -* The ``k8s`` module supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources. -* The ``k8s`` module will not accept resources where subkeys have been snake_cased. This was a workaround that was suggested with the ``k8s_raw`` and ``openshift_raw`` modules. -* The ``k8s`` module may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource. -* The ``k8s`` module can now process multi-document YAML files if they are passed with the ``src`` parameter. It will process each document as a separate resource. Resources provided inline with the ``resource_definition`` parameter must still be a single document. -* The ``k8s`` module will not automatically change ``Project`` creation requests into ``ProjectRequest`` creation requests as the ``openshift_raw`` module did. You must now specify the ``ProjectRequest`` kind explicitly. -* The ``k8s`` module will not automatically remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block. -* The ``k8s_scale`` module now supports scalable OpenShift objects, such as ``DeploymentConfig``. -* The ``lineinfile`` module was changed to show a warning when using an empty string as a regexp. - Since an empty regexp matches every line in a file, it will replace the last line in a file rather - than inserting. If this is the desired behavior, use ``'^'`` which will match every line and - will not trigger the warning. -* Openstack modules are no longer using ``shade`` library. Instead ``openstacksdk`` is used. Since ``openstacksdk`` should be already present as a dependency to ``shade`` no additional actions are required. - -Plugins -======= - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly. - -* ``openshift`` use ``k8s`` instead. - - -Noteworthy plugin changes -------------------------- - -* The ``k8s`` lookup plugin now supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources. -* The ``k8s`` lookup plugin may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource. -* The ``k8s`` lookup plugin will no longer remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block. - - -Porting custom scripts -====================== - -No notable changes. - -Networking -========== - -No notable changes. - -Dynamic inventory scripts -========================= - -* ``contrib/inventory/openstack.py`` has been renamed to ``contrib/inventory/openstack_inventory.py``. If you have used ``openstack.py`` as a name for your OpenStack dynamic inventory file, change it to ``openstack_inventory.py``. Otherwise the file name will conflict with imports from ``openstacksdk``. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.7.rst b/docs/docsite/rst/porting_guides/porting_guide_2.7.rst deleted file mode 100644 index 0ab53655d08..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.7.rst +++ /dev/null @@ -1,248 +0,0 @@ -.. _porting_2.7_guide: - -************************* -Ansible 2.7 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.6 and Ansible 2.7. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.7 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - -Command Line -============ - -If you specify ``--tags`` or ``--skip-tags`` multiple times on the command line, Ansible will merge the specified -tags together. In previous versions of Ansible, you could set ``merge_multiple_cli_tags`` to ``False`` -if you wanted to keep only the last-specified ``--tags``. This config -option existed for backwards compatibility. The overwriting behavior was deprecated in 2.3 and -the default behavior was changed in 2.4. Ansible-2.7 removes the config option; multiple -``--tags`` are now always merged. - -If you have a shell script that depends on setting ``merge_multiple_cli_tags`` to ``False``, please upgrade your script -so it only adds the ``--tags`` you actually want before upgrading to Ansible-2.7. - - -Python Compatibility -==================== - -Ansible has dropped compatibility with Python-2.6 on the controller (The host where :command:`/usr/bin/ansible` -or :command:`/usr/bin/ansible-playbook` is run). Modules shipped with Ansible can still be used to -manage hosts which only have Python-2.6. You just need to have a host with Python-2.7 or Python-3.5 -or greater to manage those hosts from. - -One thing that this does affect is the ability to use :command:`/usr/bin/ansible-pull` to manage -a host which has Python-2.6. ``ansible-pull`` runs on the host being managed but it is a controller -script, not a module so it will need an updated Python. Actively developed Linux distros which ship -with Python-2.6 have some means to install newer Python versions (For instance, you can install -Python-2.7 through an SCL on RHEL-6) but you may need to also install Python bindings for many common -modules to work (For RHEL-6, for instance, selinux bindings and yum would have to be installed for -the updated Python install). - -The decision to drop Python-2.6 support on the controller was made because many dependent libraries -are becoming unavailable there. In particular, python-cryptography is no longer available for Python-2.6 -and the last release of pycrypto (the alternative to python-cryptography) has known security bugs -which will never be fixed. - - -Playbook -======== - -Role Precedence Fix during Role Loading ---------------------------------------- - -Ansible 2.7 makes a small change to variable precedence when loading roles, resolving a bug, ensuring that role loading matches :ref:`variable precedence expectations `. - -Before Ansible 2.7, when loading a role, the variables defined in the role's ``vars/main.yml`` and ``defaults/main.yml`` were not available when parsing the role's ``tasks/main.yml`` file. This prevented the role from utilizing these variables when being parsed. The problem manifested when ``import_tasks`` or ``import_role`` was used with a variable defined in the role's vars or defaults. - -In Ansible 2.7, role ``vars`` and ``defaults`` are now parsed before ``tasks/main.yml``. This can cause a change in behavior if the same variable is defined at the play level and the role level with different values, and used in ``import_tasks`` or ``import_role`` to define the role or file to import. - -include_role and import_role variable exposure ----------------------------------------------- - -In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks. This value defaults to ``public: False``, matching current behavior. - -``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functionality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play. - -There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task. - -include_tasks/import_tasks inline variables -------------------------------------------- - -As of Ansible 2.7, `include_tasks` and `import_tasks` can no longer accept inline variables. Instead of using inline variables, tasks should supply variables under the ``vars`` keyword. - -**OLD** In Ansible 2.6 (and earlier) the following was valid syntax for specifying variables: - -.. code-block:: yaml - - - include_tasks: include_me.yml variable=value - -**NEW** In Ansible 2.7 the task should be changed to use the ``vars`` keyword: - -.. code-block:: yaml - - - include_tasks: include_me.yml - vars: - variable: value - -vars_prompt with unknown algorithms ------------------------------------ - -vars_prompt now throws an error if the hash algorithm specified in encrypt is not supported by -the controller. This increases the safety of vars_prompt as it previously returned None if the -algorithm was unknown. Some modules, notably the user module, treated a password of None as -a request not to set a password. If your playbook starts erroring because of this, change the -hashing algorithm being used with this filter. - - -Deprecated -========== - -Expedited Deprecation: Use of ``__file__`` in ``AnsibleModule`` ---------------------------------------------------------------- - -.. note:: The use of the ``__file__`` variable is deprecated in Ansible 2.7 and **will be eliminated in Ansible 2.8**. This is much quicker than our usual 4-release deprecation cycle. - -We are deprecating the use of the ``__file__`` variable to refer to the file containing the currently-running code. This common Python technique for finding a filesystem path does not always work (even in vanilla Python). Sometimes a Python module can be imported from a virtual location (like inside of a zip file). When this happens, the ``__file__`` variable will reference a virtual location pointing to inside of the zip file. This can cause problems if, for instance, the code was trying to use ``__file__`` to find the directory containing the python module to write some temporary information. - -Before the introduction of AnsiBallZ in Ansible 2.1, using ``__file__`` worked in ``AnsibleModule`` sometimes, but any module that used it would fail when pipelining was turned on (because the module would be piped into the python interpreter's standard input, so ``__file__`` wouldn't contain a file path). AnsiBallZ unintentionally made using ``__file__`` work, by always creating a temporary file for ``AnsibleModule`` to reside in. - -Ansible 2.8 will no longer create a temporary file for ``AnsibleModule``; instead it will read the file out of a zip file. This change should speed up module execution, but it does mean that starting with Ansible 2.8, referencing ``__file__`` will always fail in ``AnsibleModule``. - -If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module `: - -.. code-block:: diff - - - tempdir = os.path.dirname(__file__) - - package = os.path.join(tempdir, to_native(deb.rsplit('/', 1)[1])) - + package = os.path.join(module.tmpdir, to_native(deb.rsplit('/', 1)[1])) - - -Using a loop on a package module through squash_actions -------------------------------------------------------- - -The use of ``squash_actions`` to invoke a package module, such as "yum", to only invoke the module once is deprecated, and will be removed in Ansible 2.11. - -Instead of relying on implicit squashing, tasks should instead supply the list directly to the ``name``, ``pkg`` or ``package`` parameter of the module. This functionality has been supported in most modules since Ansible 2.3. - -**OLD** In Ansible 2.6 (and earlier) the following task would invoke the "yum" module only 1 time to install multiple packages - -.. code-block:: yaml - - - name: Install packages - yum: - name: "{{ item }}" - state: present - with_items: "{{ packages }}" - -**NEW** In Ansible 2.7 it should be changed to look like this: - -.. code-block:: yaml - - - name: Install packages - yum: - name: "{{ packages }}" - state: present - - -Modules -======= - -Major changes in popular modules are detailed here - -* The :ref:`DEFAULT_SYSLOG_FACILITY` configuration option tells Ansible modules to use a specific - `syslog facility `_ when logging information on all - managed machines. Due to a bug with older Ansible versions, this setting did not affect machines - using journald with the systemd Python bindings installed. On those machines, Ansible log - messages were sent to ``/var/log/messages``, even if you set :ref:`DEFAULT_SYSLOG_FACILITY`. - Ansible 2.7 fixes this bug, routing all Ansible log messages according to the value set for - :ref:`DEFAULT_SYSLOG_FACILITY`. If you have :ref:`DEFAULT_SYSLOG_FACILITY` configured, the - location of remote logs on systems which use journald may change. - -Modules removed ---------------- - -The following modules no longer exist: - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.11. Please update your playbooks accordingly. - -* ``na_cdot_aggregate`` use :ref:`na_ontap_aggregate ` instead. -* ``na_cdot_license`` use :ref:`na_ontap_license ` instead. -* ``na_cdot_lun`` use :ref:`na_ontap_lun ` instead. -* ``na_cdot_qtree`` use :ref:`na_ontap_qtree ` instead. -* ``na_cdot_svm`` use :ref:`na_ontap_svm ` instead. -* ``na_cdot_user`` use :ref:`na_ontap_user ` instead. -* ``na_cdot_user_role`` use :ref:`na_ontap_user_role ` instead. -* ``na_cdot_volume`` use :ref:`na_ontap_volume ` instead. -* ``sf_account_manager`` use :ref:`na_elementsw_account` instead. -* ``sf_check_connections`` use :ref:`na_elementsw_check_connections` instead. -* ``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule` instead. -* ``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group` instead. -* ``sf_volume_manager`` use :ref:`na_elementsw_volume` instead. - -Noteworthy module changes -------------------------- - -* Check mode is now supported in the ``command`` and ``shell`` modules. However, only when ``creates`` or ``removes`` is - specified. If either of these are specified, the module will check for existence of the file and report the correct - changed status, if they are not included the module will skip like it had done previously. - -* The ``win_chocolatey`` module originally required the ``proxy_username`` and ``proxy_password`` to - escape any double quotes in the value. This is no longer required and the escaping may cause further - issues. - -* The ``win_uri`` module has removed the deprecated option ``use_basic_parsing``, since Ansible 2.5 this option did - nothing - -* The ``win_scheduled_task`` module has removed the following deprecated options: - - * ``executable``, use ``path`` in an actions entry instead - * ``argument``, use ``arguments`` in an actions entry instead - * ``store_password``, set ``logon_type: password`` instead - * ``days_of_week``, use ``monthlydow`` in a triggers entry instead - * ``frequency``, use ``type``, in a triggers entry instead - * ``time``, use ``start_boundary`` in a triggers entry instead - -* The ``interface_name`` module option for ``na_ontap_net_vlan`` has been removed and should be removed from your playbooks - -* The ``win_disk_image`` module has deprecated the return value ``mount_path``, use ``mount_paths[0]`` instead. This will - be removed in Ansible 2.11. - -* ``include_role`` and ``include_tasks`` can now be used directly from ``ansible`` (adhoc) and ``ansible-console``:: - - #> ansible -m include_role -a 'name=myrole' all - -* The ``pip`` module has added a dependency on ``setuptools`` to support version requirements, this requirement is for - the Python interpreter that executes the module and not the Python interpreter that the module is managing. - -* Prior to Ansible 2.7.10, the ``replace`` module did the opposite of what was intended when using the ``before`` and ``after`` options together. This now works properly but may require changes to tasks. - - -Plugins -======= - -* The hash_password filter now throws an error if the hash algorithm specified is not supported by - the controller. This increases the safety of the filter as it previously returned None if the - algorithm was unknown. Some modules, notably the user module, treated a password of None as - a request not to set a password. If your playbook starts erroring because of this, change the - hashing algorithm being used with this filter. - - -Porting custom scripts -====================== - -No notable changes. - -Networking -========== - -No notable changes. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.8.rst b/docs/docsite/rst/porting_guides/porting_guide_2.8.rst deleted file mode 100644 index 1f3903476e8..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.8.rst +++ /dev/null @@ -1,582 +0,0 @@ -.. _porting_2.8_guide: - -************************* -Ansible 2.8 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.7 and Ansible 2.8. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.8 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - :local: - -Playbook -======== - -Distribution Facts ------------------- - -The information returned for the ``ansible_distribution_*`` group of facts may have changed -slightly. Ansible 2.8 uses a new backend library for information about distributions: `nir0s/distro `_. This library runs on Python-3.8 and fixes many bugs, including correcting release and version names. - -The two facts used in playbooks most often, ``ansible_distribution`` and ``ansible_distribution_major_version``, should not change. If you discover a change in these facts, please file a bug so we can address the -difference. However, other facts like ``ansible_distribution_release`` and -``ansible_distribution_version`` may change as erroneous information gets corrected. - -Imports as handlers -------------------- - -Beginning in version 2.8, a task cannot notify ``import_tasks`` or a static ``include`` that is specified in ``handlers``. - -The goal of a static import is to act as a pre-processor, where the import is replaced by the tasks defined within the imported file. When -using an import, a task can notify any of the named tasks within the imported file, but not the name of the import itself. - -To achieve the results of notifying a single name but running multiple handlers, utilize ``include_tasks``, or ``listen`` :ref:`handlers`. - -Jinja Undefined values ----------------------- - -Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use -a default with a value in a nested data structure when you don't know if the intermediate values are defined. - -In Ansible 2.8:: - - {{ foo.bar.baz | default('DEFAULT') }} - -In Ansible 2.7 and older:: - - {{ ((foo | default({})).bar | default({})).baz | default('DEFAULT') }} - -or:: - - {{ foo.bar.baz if (foo is defined and foo.bar is defined and foo.bar.baz is defined) else 'DEFAULT' }} - -Module option conversion to string ----------------------------------- - -Beginning in version 2.8, Ansible will warn if a module expects a string, but a non-string value is passed and automatically converted to a string. This highlights potential problems where, for example, a ``yes`` or ``true`` (parsed as truish boolean value) would be converted to the string ``'True'``, or where a version number ``1.10`` (parsed as float value) would be converted to ``'1.1'``. Such conversions can result in unexpected behavior depending on context. - -This behavior can be changed to be an error or to be ignored by setting the ``ANSIBLE_STRING_CONVERSION_ACTION`` environment variable, or by setting the ``string_conversion_action`` configuration in the ``defaults`` section of ``ansible.cfg``. - -Command line facts ------------------- - -``cmdline`` facts returned in system will be deprecated in favor of ``proc_cmdline``. This change handles special case where Kernel command line parameter contains multiple values with the same key. - -Bare variables in conditionals ------------------------------- - -In Ansible 2.7 and earlier, top-level variables sometimes treated boolean strings as if they were boolean values. This led to inconsistent behavior in conditional tests built on top-level variables defined as strings. Ansible 2.8 began changing this behavior. For example, if you set two conditions like this: - -.. code-block:: yaml - - tasks: - - include_tasks: teardown.yml - when: teardown - - - include_tasks: provision.yml - when: not teardown - -based on a variable you define **as a string** (with quotation marks around it): - -* In Ansible 2.7 and earlier, the two conditions above evaluated as ``True`` and ``False`` respectively if ``teardown: 'true'`` -* In Ansible 2.7 and earlier, both conditions evaluated as ``False`` if ``teardown: 'false'`` -* In Ansible 2.8 and later, you have the option of disabling conditional bare variables, so ``when: teardown`` always evaluates as ``True`` and ``when: not teardown`` always evaluates as ``False`` when ``teardown`` is a non-empty string (including ``'true'`` or ``'false'``) - -Ultimately, ``when: 'string'`` will always evaluate as ``True`` and ``when: not 'string'`` will always evaluate as ``False``, as long as ``'string'`` is not empty, even if the value of ``'string'`` itself looks like a boolean. For users with playbooks that depend on the old behavior, we added a config setting that preserves it. You can use the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable or ``conditional_bare_variables`` in the ``defaults`` section of ``ansible.cfg`` to select the behavior you want on your control node. The default setting is ``true``, which preserves the old behavior. Set the config value or environment variable to ``false`` to start using the new option. - -.. note:: - - In 2.10 the default setting for ``conditional_bare_variables`` will change to ``false``. In 2.12 the old behavior will be deprecated. - -Updating your playbooks -^^^^^^^^^^^^^^^^^^^^^^^ - -To prepare your playbooks for the new behavior, you must update your conditional statements so they accept only boolean values. For variables, you can use the ``bool`` filter to evaluate the string ``'false'`` as ``False``: - -.. code-block:: yaml - - vars: - teardown: 'false' - - tasks: - - include_tasks: teardown.yml - when: teardown | bool - - - include_tasks: provision.yml - when: not teardown | bool - -Alternatively, you can re-define your variables as boolean values (without quotation marks) instead of strings: - -.. code-block:: yaml - - vars: - teardown: false - - tasks: - - include_tasks: teardown.yml - when: teardown - - - include_tasks: provision.yml - when: not teardown - -For dictionaries and lists, use the ``length`` filter to evaluate the presence of a dictionary or list as ``True``: - -.. code-block:: yaml+jinja - - - debug: - when: my_list | length > 0 - - - debug: - when: my_dictionary | length > 0 - -Do not use the ``bool`` filter with lists or dictionaries. If you use ``bool`` with a list or dict, Ansible will always evaluate it as ``False``. - -Double-interpolation -^^^^^^^^^^^^^^^^^^^^ - -The ``conditional_bare_variables`` setting also affects variables set based on other variables. The old behavior unexpectedly double-interpolated those variables. For example: - -.. code-block:: yaml - - vars: - double_interpolated: 'bare_variable' - bare_variable: false - - tasks: - - debug: - when: double_interpolated - -* In Ansible 2.7 and earlier, ``when: double_interpolated`` evaluated to the value of ``bare_variable``, in this case, ``False``. If the variable ``bare_variable`` is undefined, the conditional fails. -* In Ansible 2.8 and later, with bare variables disabled, Ansible evaluates ``double_interpolated`` as the string ``'bare_variable'``, which is ``True``. - -To double-interpolate variable values, use curly braces: - -.. code-block:: yaml+jinja - - vars: - double_interpolated: "{{ other_variable }}" - other_variable: false - -Nested variables -^^^^^^^^^^^^^^^^ - -The ``conditional_bare_variables`` setting does not affect nested variables. Any string value assigned to a subkey is already respected and not treated as a boolean. If ``complex_variable['subkey']`` is a non-empty string, then ``when: complex_variable['subkey']`` is always ``True`` and ``when: not complex_variable['subkey']`` is always ``False``. If you want a string subkey like ``complex_variable['subkey']`` to be evaluated as a boolean, you must use the ``bool`` filter. - -Gathering Facts ---------------- - -In Ansible 2.8 the implicit "Gathering Facts" task in a play was changed to -obey play tags. Previous to 2.8, the "Gathering Facts" task would ignore play -tags and tags supplied from the command line and always run in a task. - -The behavior change affects the following example play. - -.. code-block:: yaml - - - name: Configure Webservers - hosts: webserver - tags: - - webserver - tasks: - - name: Install nginx - package: - name: nginx - tags: - - nginx - -In Ansible 2.8, if you supply ``--tags nginx``, the implicit -"Gathering Facts" task will be skipped, as the task now inherits -the tag of ``webserver`` instead of ``always``. - -If no play level tags are set, the "Gathering Facts" task will -be given a tag of ``always`` and will effectively match prior -behavior. - -You can achieve similar results to the pre-2.8 behavior, by -using an explicit ``gather_facts`` task in your ``tasks`` list. - -.. code-block:: yaml - - - name: Configure Webservers - hosts: webserver - gather_facts: false - tags: - - webserver - tasks: - - name: Gathering Facts - gather_facts: - tags: - - always - - - name: Install nginx - package: - name: nginx - tags: - - nginx - -Python Interpreter Discovery -============================ - -In Ansible 2.7 and earlier, Ansible defaulted to :command:`/usr/bin/python` as the -setting for ``ansible_python_interpreter``. If you ran Ansible against a system -that installed Python with a different name or a different path, your playbooks -would fail with ``/usr/bin/python: bad interpreter: No such file or directory`` -unless you either set ``ansible_python_interpreter`` to the correct value for -that system or added a Python interpreter and any necessary dependencies at -:command:`usr/bin/python`. - -Starting in Ansible 2.8, Ansible searches for the correct path and executable -name for Python on each target system, first in a lookup table of default -Python interpreters for common distros, then in an ordered fallback list of -possible Python interpreter names/paths. - -It's risky to rely on a Python interpreter set from the fallback list, because -the interpreter may change on future runs. If an interpreter from -higher in the fallback list gets installed (for example, as a side-effect of -installing other packages), your original interpreter and its dependencies will -no longer be used. For this reason, Ansible warns you when it uses a Python -interpreter discovered from the fallback list. If you see this warning, the -best solution is to explicitly set ``ansible_python_interpreter`` to the path -of the correct interpreter for those target systems. - -You can still set ``ansible_python_interpreter`` to a specific path at any -variable level (as a host variable, in vars files, in playbooks, and so on). -If you prefer to use the Python interpreter discovery behavior, use -one of the four new values for ``ansible_python_interpreter`` introduced in -Ansible 2.8: - -+---------------------------+---------------------------------------------+ -| New value | Behavior | -+===========================+=============================================+ -| auto |br| | If a Python interpreter is discovered, | -| (future default) | Ansible uses the discovered Python, even if | -| | :command:`/usr/bin/python` is also present. | -| | Warns when using the fallback list. | -+---------------------------+---------------------------------------------+ -| **auto_legacy** |br| | If a Python interpreter is discovered, and | -| (Ansible 2.8 default) | :command:`/usr/bin/python` is absent, | -| | Ansible uses the discovered Python. Warns | -| | when using the fallback list. | -| | | -| | If a Python interpreter is discovered, and | -| | :command:`/usr/bin/python` is present, | -| | Ansible uses :command:`/usr/bin/python` and | -| | prints a deprecation warning about future | -| | default behavior. Warns when using the | -| | fallback list. | -+---------------------------+---------------------------------------------+ -| auto_legacy_silent | Behaves like ``auto_legacy`` but suppresses | -| | the deprecation and fallback-list warnings. | -+---------------------------+---------------------------------------------+ -| auto_silent | Behaves like ``auto`` but suppresses the | -| | fallback-list warning. | -+---------------------------+---------------------------------------------+ - - -In Ansible 2.12, Ansible will switch the default from :literal:`auto_legacy` to :literal:`auto`. -The difference in behaviour is that :literal:`auto_legacy` uses :command:`/usr/bin/python` if -present and falls back to the discovered Python when it is not present. :literal:`auto` will always -use the discovered Python, regardless of whether :command:`/usr/bin/python` exists. The -:literal:`auto_legacy` setting provides compatibility with previous versions of Ansible that always -defaulted to :command:`/usr/bin/python`. - -If you installed Python and dependencies (``boto``, and so on) to -:command:`/usr/bin/python` as a workaround on distros with a different default Python -interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two -options: - - #. Move existing dependencies over to the default Python for each platform/distribution/version. - #. Use ``auto_legacy``. This setting lets Ansible find and use the workaround Python on hosts that have it, while also finding the correct default Python on newer hosts. But remember, the default will change in 4 releases. - - -Retry File Creation default ---------------------------- - -In Ansible 2.8, ``retry_files_enabled`` now defaults to ``False`` instead of ``True``. The behavior can be -modified to previous version by editing the default ``ansible.cfg`` file and setting the value to ``True``. - -Command Line -============ - -Become Prompting ----------------- - -Beginning in version 2.8, by default Ansible will use the word ``BECOME`` to prompt you for a password for elevated privileges (``sudo`` privileges on Unix systems or ``enable`` mode on network devices): - -By default in Ansible 2.8:: - - ansible-playbook --become --ask-become-pass site.yml - BECOME password: - -If you want the prompt to display the specific ``become_method`` you're using, instead of the general value ``BECOME``, set :ref:`AGNOSTIC_BECOME_PROMPT` to ``False`` in your Ansible configuration. - -By default in Ansible 2.7, or with ``AGNOSTIC_BECOME_PROMPT=False`` in Ansible 2.8:: - - ansible-playbook --become --ask-become-pass site.yml - SUDO password: - -Deprecated -========== - -* Setting the async directory using ``ANSIBLE_ASYNC_DIR`` as an task/play environment key is deprecated and will be - removed in Ansible 2.12. You can achieve the same result by setting ``ansible_async_dir`` as a variable like:: - - - name: run task with custom async directory - command: sleep 5 - async: 10 - vars: - ansible_async_dir: /tmp/.ansible_async - -* Plugin writers who need a ``FactCache`` object should be aware of two deprecations: - - 1. The ``FactCache`` class has moved from ``ansible.plugins.cache.FactCache`` to - ``ansible.vars.fact_cache.FactCache``. This is because the ``FactCache`` is not part of the - cache plugin API and cache plugin authors should not be subclassing it. ``FactCache`` is still - available from its old location but will issue a deprecation warning when used from there. The - old location will be removed in Ansible 2.12. - - 2. The ``FactCache.update()`` method has been converted to follow the dict API. It now takes a - dictionary as its sole argument and updates itself with the dictionary's items. The previous - API where ``update()`` took a key and a value will now issue a deprecation warning and will be - removed in 2.12. If you need the old behavior switch to ``FactCache.first_order_merge()`` - instead. - -* Supporting file-backed caching through self.cache is deprecated and will - be removed in Ansible 2.12. If you maintain an inventory plugin, update it to use ``self._cache`` as a dictionary. For implementation details, see - the :ref:`developer guide on inventory plugins`. - -* Importing cache plugins directly is deprecated and will be removed in Ansible 2.12. Use the plugin_loader - so direct options, environment variables, and other means of configuration can be reconciled using the config - system rather than constants. - - .. code-block:: python - - from ansible.plugins.loader import cache_loader - cache = cache_loader.get('redis', **kwargs) - -Modules -======= - -Major changes in popular modules are detailed here - -The exec wrapper that runs PowerShell modules has been changed to set ``$ErrorActionPreference = "Stop"`` globally. -This may mean that custom modules can fail if they implicitly relied on this behavior. To get the old behavior back, -add ``$ErrorActionPreference = "Continue"`` to the top of the module. This change was made to restore the old behavior -of the EAP that was accidentally removed in a previous release and ensure that modules are more resilient to errors -that may occur in execution. - -* Version 2.8.14 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the ``mode`` change has been reverted in 2.8.15, and ``mode`` will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.8.15, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Modules removed ---------------- - -The following modules no longer exist: - -* ec2_remote_facts -* azure -* cs_nic -* netscaler -* win_msi - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.12. Please update your playbooks accordingly. - -* ``foreman`` use `foreman-ansible-modules `_ instead. -* ``katello`` use `foreman-ansible-modules `_ instead. -* ``github_hooks`` use :ref:`github_webhook ` and :ref:`github_webhook_facts ` instead. -* ``digital_ocean`` use :ref:`digital_ocean_droplet ` instead. -* ``gce`` use :ref:`gcp_compute_instance ` instead. -* ``gcspanner`` use :ref:`gcp_spanner_instance ` and :ref:`gcp_spanner_database ` instead. -* ``gcdns_record`` use :ref:`gcp_dns_resource_record_set ` instead. -* ``gcdns_zone`` use :ref:`gcp_dns_managed_zone ` instead. -* ``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule ` or :ref:`gcp_compute_forwarding_rule ` instead. -* ``gcp_healthcheck`` use :ref:`gcp_compute_health_check `, :ref:`gcp_compute_http_health_check `, or :ref:`gcp_compute_https_health_check ` instead. -* ``gcp_backend_service`` use :ref:`gcp_compute_backend_service ` instead. -* ``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy ` instead. -* ``gcp_url_map`` use :ref:`gcp_compute_url_map ` instead. -* ``panos`` use the `Palo Alto Networks Ansible Galaxy role `_ instead. - - -Noteworthy module changes -------------------------- - -* The ``foreman`` and ``katello`` modules have been deprecated in favor of a set of modules that are broken out per entity with better idempotency in mind. -* The ``foreman`` and ``katello`` modules replacement is officially part of the Foreman Community and supported there. -* The ``tower_credential`` module originally required the ``ssh_key_data`` to be the path to a ssh_key_file. - In order to work like AWX/Tower/RHAAP, ``ssh_key_data`` now contains the content of the file. - The previous behavior can be achieved with ``lookup('file', '/path/to/file')``. -* The ``win_scheduled_task`` module deprecated support for specifying a trigger repetition as a list and this format - will be removed in Ansible 2.12. Instead specify the repetition as a dictionary value. - -* The ``win_feature`` module has removed the deprecated ``restart_needed`` return value, use the standardized - ``reboot_required`` value instead. - -* The ``win_package`` module has removed the deprecated ``restart_required`` and ``exit_code`` return value, use the - standardized ``reboot_required`` and ``rc`` value instead. - -* The ``win_get_url`` module has removed the deprecated ``win_get_url`` return dictionary, contained values are - returned directly. - -* The ``win_get_url`` module has removed the deprecated ``skip_certificate_validation`` option, use the standardized - ``validate_certs`` option instead. - -* The ``vmware_local_role_facts`` module now returns a list of dicts instead of a dict of dicts for role information. - -* If ``docker_network`` or ``docker_volume`` were called with ``diff: yes``, ``check_mode: yes`` or ``debug: yes``, - a return value called ``diff`` was returned of type ``list``. To enable proper diff output, this was changed to - type ``dict``; the original ``list`` is returned as ``diff.differences``. - -* The ``na_ontap_cluster_peer`` module has replaced ``source_intercluster_lif`` and ``dest_intercluster_lif`` string options with - ``source_intercluster_lifs`` and ``dest_intercluster_lifs`` list options - -* The ``modprobe`` module now detects kernel builtins. Previously, attempting to remove (with ``state: absent``) - a builtin kernel module succeeded without any error message because ``modprobe`` did not detect the module as - ``present``. Now, ``modprobe`` will fail if a kernel module is builtin and ``state: absent`` (with an error message - from the modprobe binary like ``modprobe: ERROR: Module nfs is builtin.``), and it will succeed without reporting - changed if ``state: present``. Any playbooks that are using ``changed_when: no`` to mask this quirk can safely - remove that workaround. To get the previous behavior when applying ``state: absent`` to a builtin kernel module, - use ``failed_when: false`` or ``ignore_errors: true`` in your playbook. - -* The ``digital_ocean`` module has been deprecated in favor of modules that do not require external dependencies. - This allows for more flexibility and better module support. - -* The ``docker_container`` module has deprecated the returned fact ``docker_container``. The same value is - available as the returned variable ``container``. The returned fact will be removed in Ansible 2.12. -* The ``docker_network`` module has deprecated the returned fact ``docker_container``. The same value is - available as the returned variable ``network``. The returned fact will be removed in Ansible 2.12. -* The ``docker_volume`` module has deprecated the returned fact ``docker_container``. The same value is - available as the returned variable ``volume``. The returned fact will be removed in Ansible 2.12. - -* The ``docker_service`` module was renamed to :ref:`docker_compose `. -* The renamed ``docker_compose`` module used to return one fact per service, named same as the service. A dictionary - of these facts is returned as the regular return value ``services``. The returned facts will be removed in - Ansible 2.12. - -* The ``docker_swarm_service`` module no longer sets a defaults for the following options: - * ``user``. Before, the default was ``root``. - * ``update_delay``. Before, the default was ``10``. - * ``update_parallelism``. Before, the default was ``1``. - -* ``vmware_vm_facts`` used to return dict of dict with virtual machine's facts. Ansible 2.8 and onwards will return list of dict with virtual machine's facts. - Please see module ``vmware_vm_facts`` documentation for example. - -* ``vmware_guest_snapshot`` module used to return ``results``. Since Ansible 2.8 and onwards ``results`` is a reserved keyword, it is replaced by ``snapshot_results``. - Please see module ``vmware_guest_snapshots`` documentation for example. - -* The ``panos`` modules have been deprecated in favor of using the Palo Alto Networks `Ansible Galaxy role - `_. Contributions to the role can be made - `here `_. - -* The ``ipa_user`` module originally always sent ``password`` to FreeIPA regardless of whether the password changed. Now the module only sends ``password`` if ``update_password`` is set to ``always``, which is the default. - -* The ``win_psexec`` has deprecated the undocumented ``extra_opts`` module option. This will be removed in Ansible 2.10. - -* The ``win_nssm`` module has deprecated the following options in favor of using the ``win_service`` module to configure the service after installing it with ``win_nssm``: - * ``dependencies``, use ``dependencies`` of ``win_service`` instead - * ``start_mode``, use ``start_mode`` of ``win_service`` instead - * ``user``, use ``username`` of ``win_service`` instead - * ``password``, use ``password`` of ``win_service`` instead - These options will be removed in Ansible 2.12. - -* The ``win_nssm`` module has also deprecated the ``start``, ``stop``, and ``restart`` values of the ``status`` option. - You should use the ``win_service`` module to control the running state of the service. This will be removed in Ansible 2.12. - -* The ``status`` module option for ``win_nssm`` has changed its default value to ``present``. Before, the default was ``start``. - Consequently, the service is no longer started by default after creation with ``win_nssm``, and you should use - the ``win_service`` module to start it if needed. - -* The ``app_parameters`` module option for ``win_nssm`` has been deprecated; use ``argument`` instead. This will be removed in Ansible 2.12. - -* The ``app_parameters_free_form`` module option for ``win_nssm`` has been aliased to the new ``arguments`` option. - -* The ``win_dsc`` module will now validate the input options for a DSC resource. In previous versions invalid options - would be ignored but are now not. - -* The ``openssl_pkcs12`` module will now regenerate the pkcs12 file if there are differences between the file on disk and the parameters passed to the module. - -Plugins -======= - -* Ansible no longer defaults to the ``paramiko`` connection plugin when using macOS as the control node. Ansible will now use the ``ssh`` connection plugin by default on a macOS control node. Since ``ssh`` supports connection persistence between tasks and playbook runs, it performs better than ``paramiko``. If you are using password authentication, you will need to install ``sshpass`` when using the ``ssh`` connection plugin. Or you can explicitly set the connection type to ``paramiko`` to maintain the pre-2.8 behavior on macOS. - -* Connection plugins have been standardized to allow use of ``ansible__user`` - and ``ansible__password`` variables. Variables such as - ``ansible__pass`` and ``ansible__username`` are treated - with lower priority than the standardized names and may be deprecated in the - future. In general, the ``ansible_user`` and ``ansible_password`` vars should - be used unless there is a reason to use the connection-specific variables. - -* The ``powershell`` shell plugin now uses ``async_dir`` to define the async path for the results file and the default - has changed to ``%USERPROFILE%\.ansible_async``. To control this path now, either set the ``ansible_async_dir`` - variable or the ``async_dir`` value in the ``powershell`` section of the config ini. - -* Order of enabled inventory plugins (:ref:`INVENTORY_ENABLED`) has been updated, :ref:`auto ` is now before :ref:`yaml ` and :ref:`ini `. - -* The private ``_options`` attribute has been removed from the ``CallbackBase`` class of callback - plugins. If you have a third-party callback plugin which needs to access the command line arguments, - use code like the following instead of trying to use ``self._options``: - - .. code-block:: python - - from ansible import context - [...] - tags = context.CLIARGS['tags'] - - ``context.CLIARGS`` is a read-only dictionary so normal dictionary retrieval methods like - ``CLIARGS.get('tags')`` and ``CLIARGS['tags']`` work as expected but you won't be able to modify - the cli arguments at all. - -* Play recap now counts ``ignored`` and ``rescued`` tasks as well as ``ok``, ``changed``, ``unreachable``, ``failed`` and ``skipped`` tasks, thanks to two additional stat counters in the ``default`` callback plugin. Tasks that fail and have ``ignore_errors: yes`` set are listed as ``ignored``. Tasks that fail and then execute a rescue section are listed as ``rescued``. Note that ``rescued`` tasks are no longer counted as ``failed`` as in Ansible 2.7 (and earlier). - -* ``osx_say`` callback plugin was renamed into :ref:`say `. - -* Inventory plugins now support caching through cache plugins. To start using a cache plugin with your inventory see the section on caching in the :ref:`inventory guide`. To port a custom cache plugin to be compatible with inventory see :ref:`developer guide on cache plugins`. - -Porting custom scripts -====================== - -Display class -------------- - -As of Ansible 2.8, the ``Display`` class is now a "singleton". Instead of using ``__main__.display`` each file should -import and instantiate ``ansible.utils.display.Display`` on its own. - -**OLD** In Ansible 2.7 (and earlier) the following was used to access the ``display`` object: - -.. code-block:: python - - try: - from __main__ import display - except ImportError: - from ansible.utils.display import Display - display = Display() - -**NEW** In Ansible 2.8 the following should be used: - -.. code-block:: python - - from ansible.utils.display import Display - display = Display() - -Networking -========== - -* The ``eos_config``, ``ios_config``, and ``nxos_config`` modules have removed the deprecated - ``save`` and ``force`` parameters, use the ``save_when`` parameter to replicate their - functionality. - -* The ``nxos_vrf_af`` module has removed the ``safi`` parameter. This parameter was deprecated - in Ansible 2.4 and has had no impact on the module since then. diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.9.rst b/docs/docsite/rst/porting_guides/porting_guide_2.9.rst deleted file mode 100644 index 463e807ac7c..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_2.9.rst +++ /dev/null @@ -1,759 +0,0 @@ - -.. _porting_2.9_guide: - -************************* -Ansible 2.9 Porting Guide -************************* - -This section discusses the behavioral changes between Ansible 2.8 and Ansible 2.9. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `Ansible Changelog for 2.9 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -Inventory ---------- - - * ``hash_behaviour`` now affects inventory sources. If you have it set to ``merge``, the data you get from inventory might change and you will have to update playbooks accordingly. If you're using the default setting (``overwrite``), you will see no changes. Inventory was ignoring this setting. - -Loops ------ - -Ansible 2.9 handles "unsafe" data more robustly, ensuring that data marked "unsafe" is not templated. In previous versions, Ansible recursively marked all data returned by the direct use of ``lookup()`` as "unsafe", but only marked structured data returned by indirect lookups using ``with_X`` style loops as "unsafe" if the returned elements were strings. Ansible 2.9 treats these two approaches consistently. - -As a result, if you use ``with_dict`` to return keys with templatable values, your templates may no longer work as expected in Ansible 2.9. - -To allow the old behavior, switch from using ``with_X`` to using ``loop`` with a filter as described at :ref:`migrating_to_loop`. - -Command Line -============ - -* The location of the Galaxy token file has changed from ``~/.ansible_galaxy`` to ``~/.ansible/galaxy_token``. You can configure both path and file name with the :ref:`galaxy_token_path` config. - - -Deprecated -========== - -No notable changes - - -Collection loader changes -========================= - -The way to import a PowerShell or C# module util from a collection has changed in the Ansible 2.9 release. In Ansible -2.8 a util was imported with the following syntax: - -.. code-block:: powershell - - #AnsibleRequires -CSharpUtil AnsibleCollections.namespace_name.collection_name.util_filename - #AnsibleRequires -PowerShell AnsibleCollections.namespace_name.collection_name.util_filename - -In Ansible 2.9 this was changed to: - -.. code-block:: powershell - - #AnsibleRequires -CSharpUtil ansible_collections.namespace_name.collection_name.plugins.module_utils.util_filename - #AnsibleRequires -PowerShell ansible_collections.namespace_name.collection_name.plugins.module_utils.util_filename - -The change in the collection import name also requires any C# util namespaces to be updated with the newer name -format. This is more verbose but is designed to make sure we avoid plugin name conflicts across separate plugin types -and to standardise how imports work in PowerShell with how Python modules work. - - -Modules -======= - -* The ``win_get_url`` and ``win_uri`` module now sends requests with a default ``User-Agent`` of ``ansible-httpget``. This can be changed by using the ``http_agent`` key. -* The ``apt`` module now honors ``update_cache=false`` while installing its own dependency and skips the cache update. Explicitly setting ``update_cache=true`` or omitting the param ``update_cache`` will result in a cache update while installing its own dependency. - -* Version 2.9.12 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.9.13, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.9.12, those changes will be unnecessary (but will do no harm) in 2.9.13. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.9.13, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Renaming from ``_facts`` to ``_info`` --------------------------------------- - -Ansible 2.9 renamed a lot of modules from ``_facts`` to ``_info``, because the modules do not return :ref:`Ansible facts `. Ansible facts relate to a specific host. For example, the configuration of a network interface, the operating system on a unix server, and the list of packages installed on a Windows box are all Ansible facts. The renamed modules return values that are not unique to the host. For example, account information or region data for a cloud provider. Renaming these modules should provide more clarity about the types of return values each set of modules offers. - -Writing modules ---------------- - -* Module and module_utils files can now use relative imports to include other module_utils files. - This is useful for shortening long import lines, especially in collections. - - Example of using a relative import in collections: - - .. code-block:: python - - # File: ansible_collections/my_namespace/my_collection/plugins/modules/my_module.py - # Old way to use an absolute import to import module_utils from the collection: - from ansible_collections.my_namespace.my_collection.plugins.module_utils import my_util - # New way using a relative import: - from ..module_utils import my_util - - Modules and module_utils shipped with Ansible can use relative imports as well but the savings - are smaller: - - .. code-block:: python - - # File: ansible/modules/system/ping.py - # Old way to use an absolute import to import module_utils from core: - from ansible.module_utils.basic import AnsibleModule - # New way using a relative import: - from ...module_utils.basic import AnsibleModule - - Each single dot (``.``) represents one level of the tree (equivalent to ``../`` in filesystem relative links). - - .. seealso:: `The Python Relative Import Docs `_ go into more detail of how to write relative imports. - - -Modules removed ---------------- - -The following modules no longer exist: - -* Apstra's ``aos_*`` modules. See the new modules at `https://github.com/apstra `_. -* ec2_ami_find use :ref:`ec2_ami_facts ` instead. -* kubernetes use :ref:`k8s ` instead. -* nxos_ip_interface use :ref:`nxos_l3_interface ` instead. -* nxos_portchannel use :ref:`nxos_linkagg ` instead. -* nxos_switchport use :ref:`nxos_l2_interface ` instead. -* oc use :ref:`k8s ` instead. -* panos_nat_policy use :ref:`panos_nat_rule ` instead. -* panos_security_policy use :ref:`panos_security_rule ` instead. -* vsphere_guest use :ref:`vmware_guest ` instead. - - -Deprecation notices -------------------- - -The following modules will be removed in Ansible 2.13. Please update update your playbooks accordingly. - -* cs_instance_facts use :ref:`cs_instance_info ` instead. - -* cs_zone_facts use :ref:`cs_zone_info ` instead. - -* digital_ocean_sshkey_facts use :ref:`digital_ocean_sshkey_info ` instead. - -* eos_interface use :ref:`eos_interfaces ` instead. - -* eos_l2_interface use :ref:`eos_l2_interfaces ` instead. - -* eos_l3_interface use :ref:`eos_l3_interfaces ` instead. - -* eos_linkagg use :ref:`eos_lag_interfaces ` instead. - -* eos_lldp_interface use :ref:`eos_lldp_interfaces ` instead. - -* eos_vlan use :ref:`eos_vlans ` instead. - -* ios_interface use :ref:`ios_interfaces ` instead. - -* ios_l2_interface use :ref:`ios_l2_interfaces ` instead. - -* ios_l3_interface use :ref:`ios_l3_interfaces ` instead. - -* ios_vlan use :ref:`ios_vlans ` instead. - -* iosxr_interface use :ref:`iosxr_interfaces ` instead. - -* junos_interface use :ref:`junos_interfaces ` instead. - -* junos_l2_interface use :ref:`junos_l2_interfaces ` instead. - -* junos_l3_interface use :ref:`junos_l3_interfaces ` instead. - -* junos_linkagg use :ref:`junos_lag_interfaces ` instead. - -* junos_lldp use :ref:`junos_lldp_global ` instead. - -* junos_lldp_interface use :ref:`junos_lldp_interfaces ` instead. - -* junos_vlan use :ref:`junos_vlans ` instead. - -* lambda_facts use :ref:`lambda_info ` instead. - -* na_ontap_gather_facts use :ref:`na_ontap_info ` instead. - -* net_banner use the platform-specific [netos]_banner modules instead. - -* net_interface use the new platform-specific [netos]_interfaces modules instead. - -* net_l2_interface use the new platform-specific [netos]_l2_interfaces modules instead. - -* net_l3_interface use the new platform-specific [netos]_l3_interfaces modules instead. - -* net_linkagg use the new platform-specific [netos]_lag modules instead. - -* net_lldp use the new platform-specific [netos]_lldp_global modules instead. - -* net_lldp_interface use the new platform-specific [netos]_lldp_interfaces modules instead. - -* net_logging use the platform-specific [netos]_logging modules instead. - -* net_static_route use the platform-specific [netos]_static_route modules instead. - -* net_system use the platform-specific [netos]_system modules instead. - -* net_user use the platform-specific [netos]_user modules instead. - -* net_vlan use the new platform-specific [netos]_vlans modules instead. - -* net_vrf use the platform-specific [netos]_vrf modules instead. - -* nginx_status_facts use :ref:`nginx_status_info ` instead. - -* nxos_interface use :ref:`nxos_interfaces ` instead. - -* nxos_l2_interface use :ref:`nxos_l2_interfaces ` instead. - -* nxos_l3_interface use :ref:`nxos_l3_interfaces ` instead. - -* nxos_linkagg use :ref:`nxos_lag_interfaces ` instead. - -* nxos_vlan use :ref:`nxos_vlans ` instead. - -* online_server_facts use :ref:`online_server_info ` instead. - -* online_user_facts use :ref:`online_user_info ` instead. - -* purefa_facts use :ref:`purefa_info ` instead. - -* purefb_facts use :ref:`purefb_info ` instead. - -* scaleway_image_facts use :ref:`scaleway_image_info ` instead. - -* scaleway_ip_facts use :ref:`scaleway_ip_info ` instead. - -* scaleway_organization_facts use :ref:`scaleway_organization_info ` instead. - -* scaleway_security_group_facts use :ref:`scaleway_security_group_info ` instead. - -* scaleway_server_facts use :ref:`scaleway_server_info ` instead. - -* scaleway_snapshot_facts use :ref:`scaleway_snapshot_info ` instead. - -* scaleway_volume_facts use :ref:`scaleway_volume_info ` instead. - -* vcenter_extension_facts use :ref:`vcenter_extension_info ` instead. - -* vmware_about_facts use :ref:`vmware_about_info ` instead. - -* vmware_category_facts use :ref:`vmware_category_info ` instead. - -* vmware_drs_group_facts use :ref:`vmware_drs_group_info ` instead. - -* vmware_drs_rule_facts use :ref:`vmware_drs_rule_info ` instead. - -* vmware_dvs_portgroup_facts use :ref:`vmware_dvs_portgroup_info ` instead. - -* vmware_guest_boot_facts use :ref:`vmware_guest_boot_info ` instead. - -* vmware_guest_customization_facts use :ref:`vmware_guest_customization_info ` instead. - -* vmware_guest_disk_facts use :ref:`vmware_guest_disk_info ` instead. - -* vmware_host_capability_facts use :ref:`vmware_host_capability_info ` instead. - -* vmware_host_config_facts use :ref:`vmware_host_config_info ` instead. - -* vmware_host_dns_facts use :ref:`vmware_host_dns_info ` instead. - -* vmware_host_feature_facts use :ref:`vmware_host_feature_info ` instead. - -* vmware_host_firewall_facts use :ref:`vmware_host_firewall_info ` instead. - -* vmware_host_ntp_facts use :ref:`vmware_host_ntp_info ` instead. - -* vmware_host_package_facts use :ref:`vmware_host_package_info ` instead. - -* vmware_host_service_facts use :ref:`vmware_host_service_info ` instead. - -* vmware_host_ssl_facts use :ref:`vmware_host_ssl_info ` instead. - -* vmware_host_vmhba_facts use :ref:`vmware_host_vmhba_info ` instead. - -* vmware_host_vmnic_facts use :ref:`vmware_host_vmnic_info ` instead. - -* vmware_local_role_facts use :ref:`vmware_local_role_info ` instead. - -* vmware_local_user_facts use :ref:`vmware_local_user_info ` instead. - -* vmware_portgroup_facts use :ref:`vmware_portgroup_info ` instead. - -* vmware_resource_pool_facts use :ref:`vmware_resource_pool_info ` instead. - -* vmware_target_canonical_facts use :ref:`vmware_target_canonical_info ` instead. - -* vmware_vmkernel_facts use :ref:`vmware_vmkernel_info ` instead. - -* vmware_vswitch_facts use :ref:`vmware_vswitch_info ` instead. - -* vultr_account_facts use :ref:`vultr_account_info ` instead. - -* vultr_block_storage_facts use :ref:`vultr_block_storage_info ` instead. - -* vultr_dns_domain_facts use :ref:`vultr_dns_domain_info ` instead. - -* vultr_firewall_group_facts use :ref:`vultr_firewall_group_info ` instead. - -* vultr_network_facts use :ref:`vultr_network_info ` instead. - -* vultr_os_facts use :ref:`vultr_os_info ` instead. - -* vultr_plan_facts use :ref:`vultr_plan_info ` instead. - -* vultr_region_facts use :ref:`vultr_region_info ` instead. - -* vultr_server_facts use :ref:`vultr_server_info ` instead. - -* vultr_ssh_key_facts use :ref:`vultr_ssh_key_info ` instead. - -* vultr_startup_script_facts use :ref:`vultr_startup_script_info ` instead. - -* vultr_user_facts use :ref:`vultr_user_info ` instead. - -* vyos_interface use :ref:`vyos_interfaces ` instead. - -* vyos_l3_interface use :ref:`vyos_l3_interfaces ` instead. - -* vyos_linkagg use :ref:`vyos_lag_interfaces ` instead. - -* vyos_lldp use :ref:`vyos_lldp_global ` instead. - -* vyos_lldp_interface use :ref:`vyos_lldp_interfaces ` instead. - - -The following functionality will be removed in Ansible 2.12. Please update update your playbooks accordingly. - -* ``vmware_cluster`` DRS, HA and VSAN configuration; use :ref:`vmware_cluster_drs `, :ref:`vmware_cluster_ha ` and :ref:`vmware_cluster_vsan ` instead. - - -The following functionality will be removed in Ansible 2.13. Please update update your playbooks accordingly. - -* ``openssl_certificate`` deprecates the ``assertonly`` provider. - Please see the :ref:`openssl_certificate ` documentation examples on how to - replace the provider with the :ref:`openssl_certificate_info `, - :ref:`openssl_csr_info `, :ref:`openssl_privatekey_info ` - and :ref:`assert ` modules. - - -For the following modules, the PyOpenSSL-based backend ``pyopenssl`` has been deprecated and will be -removed in Ansible 2.13: - -* :ref:`get_certificate ` -* :ref:`openssl_certificate ` -* :ref:`openssl_certificate_info ` -* :ref:`openssl_csr ` -* :ref:`openssl_csr_info ` -* :ref:`openssl_privatekey ` -* :ref:`openssl_privatekey_info ` -* :ref:`openssl_publickey ` - - -Renamed modules -^^^^^^^^^^^^^^^ - -The following modules have been renamed. The old name is deprecated and will -be removed in Ansible 2.13. Please update update your playbooks accordingly. - -* The ``ali_instance_facts`` module was renamed to :ref:`ali_instance_info `. -* The ``aws_acm_facts`` module was renamed to :ref:`aws_acm_info `. -* The ``aws_az_facts`` module was renamed to :ref:`aws_az_info `. -* The ``aws_caller_facts`` module was renamed to :ref:`aws_caller_info `. -* The ``aws_kms_facts`` module was renamed to :ref:`aws_kms_info `. -* The ``aws_region_facts`` module was renamed to :ref:`aws_region_info `. -* The ``aws_s3_bucket_facts`` module was renamed to :ref:`aws_s3_bucket_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``aws_sgw_facts`` module was renamed to :ref:`aws_sgw_info `. -* The ``aws_waf_facts`` module was renamed to :ref:`aws_waf_info `. -* The ``azure_rm_aks_facts`` module was renamed to :ref:`azure_rm_aks_info `. -* The ``azure_rm_aksversion_facts`` module was renamed to :ref:`azure_rm_aksversion_info `. -* The ``azure_rm_applicationsecuritygroup_facts`` module was renamed to :ref:`azure_rm_applicationsecuritygroup_info `. -* The ``azure_rm_appserviceplan_facts`` module was renamed to :ref:`azure_rm_appserviceplan_info `. -* The ``azure_rm_automationaccount_facts`` module was renamed to :ref:`azure_rm_automationaccount_info `. -* The ``azure_rm_autoscale_facts`` module was renamed to :ref:`azure_rm_autoscale_info `. -* The ``azure_rm_availabilityset_facts`` module was renamed to :ref:`azure_rm_availabilityset_info `. -* The ``azure_rm_cdnendpoint_facts`` module was renamed to :ref:`azure_rm_cdnendpoint_info `. -* The ``azure_rm_cdnprofile_facts`` module was renamed to :ref:`azure_rm_cdnprofile_info `. -* The ``azure_rm_containerinstance_facts`` module was renamed to :ref:`azure_rm_containerinstance_info `. -* The ``azure_rm_containerregistry_facts`` module was renamed to :ref:`azure_rm_containerregistry_info `. -* The ``azure_rm_cosmosdbaccount_facts`` module was renamed to :ref:`azure_rm_cosmosdbaccount_info `. -* The ``azure_rm_deployment_facts`` module was renamed to :ref:`azure_rm_deployment_info `. -* The ``azure_rm_resourcegroup_facts`` module was renamed to :ref:`azure_rm_resourcegroup_info `. -* The ``bigip_device_facts`` module was renamed to :ref:`bigip_device_info `. -* The ``bigiq_device_facts`` module was renamed to :ref:`bigiq_device_info `. -* The ``cloudformation_facts`` module was renamed to :ref:`cloudformation_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``cloudfront_facts`` module was renamed to :ref:`cloudfront_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``cloudwatchlogs_log_group_facts`` module was renamed to :ref:`cloudwatchlogs_log_group_info `. -* The ``digital_ocean_account_facts`` module was renamed to :ref:`digital_ocean_account_info `. -* The ``digital_ocean_certificate_facts`` module was renamed to :ref:`digital_ocean_certificate_info `. -* The ``digital_ocean_domain_facts`` module was renamed to :ref:`digital_ocean_domain_info `. -* The ``digital_ocean_firewall_facts`` module was renamed to :ref:`digital_ocean_firewall_info `. -* The ``digital_ocean_floating_ip_facts`` module was renamed to :ref:`digital_ocean_floating_ip_info `. -* The ``digital_ocean_image_facts`` module was renamed to :ref:`digital_ocean_image_info `. -* The ``digital_ocean_load_balancer_facts`` module was renamed to :ref:`digital_ocean_load_balancer_info `. -* The ``digital_ocean_region_facts`` module was renamed to :ref:`digital_ocean_region_info `. -* The ``digital_ocean_size_facts`` module was renamed to :ref:`digital_ocean_size_info `. -* The ``digital_ocean_snapshot_facts`` module was renamed to :ref:`digital_ocean_snapshot_info `. -* The ``digital_ocean_tag_facts`` module was renamed to :ref:`digital_ocean_tag_info `. -* The ``digital_ocean_volume_facts`` module was renamed to :ref:`digital_ocean_volume_info `. -* The ``ec2_ami_facts`` module was renamed to :ref:`ec2_ami_info `. -* The ``ec2_asg_facts`` module was renamed to :ref:`ec2_asg_info `. -* The ``ec2_customer_gateway_facts`` module was renamed to :ref:`ec2_customer_gateway_info `. -* The ``ec2_eip_facts`` module was renamed to :ref:`ec2_eip_info `. -* The ``ec2_elb_facts`` module was renamed to :ref:`ec2_elb_info `. -* The ``ec2_eni_facts`` module was renamed to :ref:`ec2_eni_info `. -* The ``ec2_group_facts`` module was renamed to :ref:`ec2_group_info `. -* The ``ec2_instance_facts`` module was renamed to :ref:`ec2_instance_info `. -* The ``ec2_lc_facts`` module was renamed to :ref:`ec2_lc_info `. -* The ``ec2_placement_group_facts`` module was renamed to :ref:`ec2_placement_group_info `. -* The ``ec2_snapshot_facts`` module was renamed to :ref:`ec2_snapshot_info `. -* The ``ec2_vol_facts`` module was renamed to :ref:`ec2_vol_info `. -* The ``ec2_vpc_dhcp_option_facts`` module was renamed to :ref:`ec2_vpc_dhcp_option_info `. -* The ``ec2_vpc_endpoint_facts`` module was renamed to :ref:`ec2_vpc_endpoint_info `. -* The ``ec2_vpc_igw_facts`` module was renamed to :ref:`ec2_vpc_igw_info `. -* The ``ec2_vpc_nacl_facts`` module was renamed to :ref:`ec2_vpc_nacl_info `. -* The ``ec2_vpc_nat_gateway_facts`` module was renamed to :ref:`ec2_vpc_nat_gateway_info `. -* The ``ec2_vpc_net_facts`` module was renamed to :ref:`ec2_vpc_net_info `. -* The ``ec2_vpc_peering_facts`` module was renamed to :ref:`ec2_vpc_peering_info `. -* The ``ec2_vpc_route_table_facts`` module was renamed to :ref:`ec2_vpc_route_table_info `. -* The ``ec2_vpc_subnet_facts`` module was renamed to :ref:`ec2_vpc_subnet_info `. -* The ``ec2_vpc_vgw_facts`` module was renamed to :ref:`ec2_vpc_vgw_info `. -* The ``ec2_vpc_vpn_facts`` module was renamed to :ref:`ec2_vpc_vpn_info `. -* The ``ecs_service_facts`` module was renamed to :ref:`ecs_service_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ecs_taskdefinition_facts`` module was renamed to :ref:`ecs_taskdefinition_info `. -* The ``efs_facts`` module was renamed to :ref:`efs_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``elasticache_facts`` module was renamed to :ref:`elasticache_info `. -* The ``elb_application_lb_facts`` module was renamed to :ref:`elb_application_lb_info `. -* The ``elb_classic_lb_facts`` module was renamed to :ref:`elb_classic_lb_info `. -* The ``elb_target_facts`` module was renamed to :ref:`elb_target_info `. -* The ``elb_target_group_facts`` module was renamed to :ref:`elb_target_group_info `. -* The ``gcp_bigquery_dataset_facts`` module was renamed to :ref:`gcp_bigquery_dataset_info `. -* The ``gcp_bigquery_table_facts`` module was renamed to :ref:`gcp_bigquery_table_info `. -* The ``gcp_cloudbuild_trigger_facts`` module was renamed to :ref:`gcp_cloudbuild_trigger_info `. -* The ``gcp_compute_address_facts`` module was renamed to :ref:`gcp_compute_address_info `. -* The ``gcp_compute_backend_bucket_facts`` module was renamed to :ref:`gcp_compute_backend_bucket_info `. -* The ``gcp_compute_backend_service_facts`` module was renamed to :ref:`gcp_compute_backend_service_info `. -* The ``gcp_compute_disk_facts`` module was renamed to :ref:`gcp_compute_disk_info `. -* The ``gcp_compute_firewall_facts`` module was renamed to :ref:`gcp_compute_firewall_info `. -* The ``gcp_compute_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_forwarding_rule_info `. -* The ``gcp_compute_global_address_facts`` module was renamed to :ref:`gcp_compute_global_address_info `. -* The ``gcp_compute_global_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_global_forwarding_rule_info `. -* The ``gcp_compute_health_check_facts`` module was renamed to :ref:`gcp_compute_health_check_info `. -* The ``gcp_compute_http_health_check_facts`` module was renamed to :ref:`gcp_compute_http_health_check_info `. -* The ``gcp_compute_https_health_check_facts`` module was renamed to :ref:`gcp_compute_https_health_check_info `. -* The ``gcp_compute_image_facts`` module was renamed to :ref:`gcp_compute_image_info `. -* The ``gcp_compute_instance_facts`` module was renamed to :ref:`gcp_compute_instance_info `. -* The ``gcp_compute_instance_group_facts`` module was renamed to :ref:`gcp_compute_instance_group_info `. -* The ``gcp_compute_instance_group_manager_facts`` module was renamed to :ref:`gcp_compute_instance_group_manager_info `. -* The ``gcp_compute_instance_template_facts`` module was renamed to :ref:`gcp_compute_instance_template_info `. -* The ``gcp_compute_interconnect_attachment_facts`` module was renamed to :ref:`gcp_compute_interconnect_attachment_info `. -* The ``gcp_compute_network_facts`` module was renamed to :ref:`gcp_compute_network_info `. -* The ``gcp_compute_region_disk_facts`` module was renamed to :ref:`gcp_compute_region_disk_info `. -* The ``gcp_compute_route_facts`` module was renamed to :ref:`gcp_compute_route_info `. -* The ``gcp_compute_router_facts`` module was renamed to :ref:`gcp_compute_router_info `. -* The ``gcp_compute_ssl_certificate_facts`` module was renamed to :ref:`gcp_compute_ssl_certificate_info `. -* The ``gcp_compute_ssl_policy_facts`` module was renamed to :ref:`gcp_compute_ssl_policy_info `. -* The ``gcp_compute_subnetwork_facts`` module was renamed to :ref:`gcp_compute_subnetwork_info `. -* The ``gcp_compute_target_http_proxy_facts`` module was renamed to :ref:`gcp_compute_target_http_proxy_info `. -* The ``gcp_compute_target_https_proxy_facts`` module was renamed to :ref:`gcp_compute_target_https_proxy_info `. -* The ``gcp_compute_target_pool_facts`` module was renamed to :ref:`gcp_compute_target_pool_info `. -* The ``gcp_compute_target_ssl_proxy_facts`` module was renamed to :ref:`gcp_compute_target_ssl_proxy_info `. -* The ``gcp_compute_target_tcp_proxy_facts`` module was renamed to :ref:`gcp_compute_target_tcp_proxy_info `. -* The ``gcp_compute_target_vpn_gateway_facts`` module was renamed to :ref:`gcp_compute_target_vpn_gateway_info `. -* The ``gcp_compute_url_map_facts`` module was renamed to :ref:`gcp_compute_url_map_info `. -* The ``gcp_compute_vpn_tunnel_facts`` module was renamed to :ref:`gcp_compute_vpn_tunnel_info `. -* The ``gcp_container_cluster_facts`` module was renamed to :ref:`gcp_container_cluster_info `. -* The ``gcp_container_node_pool_facts`` module was renamed to :ref:`gcp_container_node_pool_info `. -* The ``gcp_dns_managed_zone_facts`` module was renamed to :ref:`gcp_dns_managed_zone_info `. -* The ``gcp_dns_resource_record_set_facts`` module was renamed to :ref:`gcp_dns_resource_record_set_info `. -* The ``gcp_iam_role_facts`` module was renamed to :ref:`gcp_iam_role_info `. -* The ``gcp_iam_service_account_facts`` module was renamed to :ref:`gcp_iam_service_account_info `. -* The ``gcp_pubsub_subscription_facts`` module was renamed to :ref:`gcp_pubsub_subscription_info `. -* The ``gcp_pubsub_topic_facts`` module was renamed to :ref:`gcp_pubsub_topic_info `. -* The ``gcp_redis_instance_facts`` module was renamed to :ref:`gcp_redis_instance_info `. -* The ``gcp_resourcemanager_project_facts`` module was renamed to :ref:`gcp_resourcemanager_project_info `. -* The ``gcp_sourcerepo_repository_facts`` module was renamed to :ref:`gcp_sourcerepo_repository_info `. -* The ``gcp_spanner_database_facts`` module was renamed to :ref:`gcp_spanner_database_info `. -* The ``gcp_spanner_instance_facts`` module was renamed to :ref:`gcp_spanner_instance_info `. -* The ``gcp_sql_database_facts`` module was renamed to :ref:`gcp_sql_database_info `. -* The ``gcp_sql_instance_facts`` module was renamed to :ref:`gcp_sql_instance_info `. -* The ``gcp_sql_user_facts`` module was renamed to :ref:`gcp_sql_user_info `. -* The ``gcp_tpu_node_facts`` module was renamed to :ref:`gcp_tpu_node_info `. -* The ``gcpubsub_facts`` module was renamed to :ref:`gcpubsub_info `. -* The ``github_webhook_facts`` module was renamed to :ref:`github_webhook_info `. -* The ``gluster_heal_facts`` module was renamed to :ref:`gluster_heal_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_datacenter_facts`` module was renamed to :ref:`hcloud_datacenter_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_floating_ip_facts`` module was renamed to :ref:`hcloud_floating_ip_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_image_facts`` module was renamed to :ref:`hcloud_image_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_location_facts`` module was renamed to :ref:`hcloud_location_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_server_facts`` module was renamed to :ref:`hcloud_server_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_server_type_facts`` module was renamed to :ref:`hcloud_server_type_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_ssh_key_facts`` module was renamed to :ref:`hcloud_ssh_key_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hcloud_volume_facts`` module was renamed to :ref:`hcloud_volume_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``hpilo_facts`` module was renamed to :ref:`hpilo_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``iam_mfa_device_facts`` module was renamed to :ref:`iam_mfa_device_info `. -* The ``iam_role_facts`` module was renamed to :ref:`iam_role_info `. -* The ``iam_server_certificate_facts`` module was renamed to :ref:`iam_server_certificate_info `. -* The ``idrac_redfish_facts`` module was renamed to :ref:`idrac_redfish_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``intersight_facts`` module was renamed to :ref:`intersight_info `. -* The ``jenkins_job_facts`` module was renamed to :ref:`jenkins_job_info `. -* The ``k8s_facts`` module was renamed to :ref:`k8s_info `. -* The ``memset_memstore_facts`` module was renamed to :ref:`memset_memstore_info `. -* The ``memset_server_facts`` module was renamed to :ref:`memset_server_info `. -* The ``one_image_facts`` module was renamed to :ref:`one_image_info `. -* The ``onepassword_facts`` module was renamed to :ref:`onepassword_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_datacenter_facts`` module was renamed to :ref:`oneview_datacenter_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_enclosure_facts`` module was renamed to :ref:`oneview_enclosure_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_ethernet_network_facts`` module was renamed to :ref:`oneview_ethernet_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_fc_network_facts`` module was renamed to :ref:`oneview_fc_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_fcoe_network_facts`` module was renamed to :ref:`oneview_fcoe_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_logical_interconnect_group_facts`` module was renamed to :ref:`oneview_logical_interconnect_group_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_network_set_facts`` module was renamed to :ref:`oneview_network_set_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``oneview_san_manager_facts`` module was renamed to :ref:`oneview_san_manager_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_flavor_facts`` module was renamed to :ref:`os_flavor_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_image_facts`` module was renamed to :ref:`os_image_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_keystone_domain_facts`` module was renamed to :ref:`os_keystone_domain_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_networks_facts`` module was renamed to :ref:`os_networks_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_port_facts`` module was renamed to :ref:`os_port_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_project_facts`` module was renamed to :ref:`os_project_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_server_facts`` module was renamed to :ref:`os_server_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_subnets_facts`` module was renamed to :ref:`os_subnets_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``os_user_facts`` module was renamed to :ref:`os_user_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_affinity_label_facts`` module was renamed to :ref:`ovirt_affinity_label_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_api_facts`` module was renamed to :ref:`ovirt_api_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_cluster_facts`` module was renamed to :ref:`ovirt_cluster_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_datacenter_facts`` module was renamed to :ref:`ovirt_datacenter_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_disk_facts`` module was renamed to :ref:`ovirt_disk_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_event_facts`` module was renamed to :ref:`ovirt_event_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_external_provider_facts`` module was renamed to :ref:`ovirt_external_provider_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_group_facts`` module was renamed to :ref:`ovirt_group_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_host_facts`` module was renamed to :ref:`ovirt_host_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_host_storage_facts`` module was renamed to :ref:`ovirt_host_storage_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_network_facts`` module was renamed to :ref:`ovirt_network_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_nic_facts`` module was renamed to :ref:`ovirt_nic_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_permission_facts`` module was renamed to :ref:`ovirt_permission_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_quota_facts`` module was renamed to :ref:`ovirt_quota_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_scheduling_policy_facts`` module was renamed to :ref:`ovirt_scheduling_policy_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_snapshot_facts`` module was renamed to :ref:`ovirt_snapshot_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_storage_domain_facts`` module was renamed to :ref:`ovirt_storage_domain_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_storage_template_facts`` module was renamed to :ref:`ovirt_storage_template_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_storage_vm_facts`` module was renamed to :ref:`ovirt_storage_vm_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_tag_facts`` module was renamed to :ref:`ovirt_tag_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_template_facts`` module was renamed to :ref:`ovirt_template_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_user_facts`` module was renamed to :ref:`ovirt_user_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_vm_facts`` module was renamed to :ref:`ovirt_vm_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``ovirt_vmpool_facts`` module was renamed to :ref:`ovirt_vmpool_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``python_requirements_facts`` module was renamed to :ref:`python_requirements_info `. -* The ``rds_instance_facts`` module was renamed to :ref:`rds_instance_info `. -* The ``rds_snapshot_facts`` module was renamed to :ref:`rds_snapshot_info `. -* The ``redfish_facts`` module was renamed to :ref:`redfish_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``redshift_facts`` module was renamed to :ref:`redshift_info `. -* The ``route53_facts`` module was renamed to :ref:`route53_info `. -* The ``smartos_image_facts`` module was renamed to :ref:`smartos_image_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``vertica_facts`` module was renamed to :ref:`vertica_info `. - When called with the new name, the module no longer returns ``ansible_facts``. - To access return values, :ref:`register a variable `. -* The ``vmware_cluster_facts`` module was renamed to :ref:`vmware_cluster_info `. -* The ``vmware_datastore_facts`` module was renamed to :ref:`vmware_datastore_info `. -* The ``vmware_guest_facts`` module was renamed to :ref:`vmware_guest_info `. -* The ``vmware_guest_snapshot_facts`` module was renamed to :ref:`vmware_guest_snapshot_info `. -* The ``vmware_tag_facts`` module was renamed to :ref:`vmware_tag_info `. -* The ``vmware_vm_facts`` module was renamed to :ref:`vmware_vm_info `. -* The ``xenserver_guest_facts`` module was renamed to :ref:`xenserver_guest_info `. -* The ``zabbix_group_facts`` module was renamed to :ref:`zabbix_group_info `. -* The ``zabbix_host_facts`` module was renamed to :ref:`zabbix_host_info `. - -Noteworthy module changes -------------------------- - -* :ref:`vmware_cluster ` was refactored for easier maintenance/bugfixes. Use the three new, specialized modules to configure clusters. Configure DRS with :ref:`vmware_cluster_drs `, HA with :ref:`vmware_cluster_ha ` and vSAN with :ref:`vmware_cluster_vsan `. -* :ref:`vmware_dvswitch ` accepts ``folder`` parameter to place dvswitch in user defined folder. This option makes ``datacenter`` as an optional parameter. -* :ref:`vmware_datastore_cluster ` accepts ``folder`` parameter to place datastore cluster in user defined folder. This option makes ``datacenter`` as an optional parameter. -* :ref:`mysql_db ` returns new ``db_list`` parameter in addition to ``db`` parameter. This ``db_list`` parameter refers to list of database names. ``db`` parameter will be deprecated in version 2.13. -* :ref:`snow_record ` and :ref:`snow_record_find ` now takes environment variables for ``instance``, ``username`` and ``password`` parameters. This change marks these parameters as optional. -* The deprecated ``force`` option in ``win_firewall_rule`` has been removed. -* :ref:`openssl_certificate `'s ``ownca`` provider creates authority key identifiers if not explicitly disabled with ``ownca_create_authority_key_identifier: no``. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available. -* :ref:`openssl_certificate `'s ``ownca`` and ``selfsigned`` providers create subject key identifiers if not explicitly disabled with ``ownca_create_subject_key_identifier: never_create`` resp. ``selfsigned_create_subject_key_identifier: never_create``. If a subject key identifier is provided by the CSR, it is taken; if not, it is created from the public key. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available. -* :ref:`openssh_keypair ` now applies the same file permissions and ownership to both public and private keys (both get the same ``mode``, ``owner``, ``group``, and so on). If you need to change permissions / ownership on one key, use the :ref:`file ` to modify it after it is created. - - -Plugins -======= - -Removed Lookup Plugins ----------------------- - -* ``redis_kv`` use :ref:`redis ` instead. - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -Network resource modules ------------------------- - -Ansible 2.9 introduced the first batch of network resource modules. Sections of a network device's configuration can be thought of as a resource provided by that device. Network resource modules are intentionally scoped to configure a single resource and you can combine them as building blocks to configure complex network services. The older modules are deprecated in Ansible 2.9 and will be removed in Ansible 2.13. You should scan the list of deprecated modules above and replace them with the new network resource modules in your playbooks. See `Ansible Network Features in 2.9 `_ for details. - -Improved ``gather_facts`` support for network devices ------------------------------------------------------ - -In Ansible 2.9, the ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`eos_facts `) to return just a subset of the device configuration. See :ref:`network_gather_facts` for an example. - -Top-level connection arguments removed in 2.9 ---------------------------------------------- - -Top-level connection arguments like ``username``, ``host``, and ``password`` are removed in version 2.9. - -**OLD** In Ansible < 2.4 - -.. code-block:: yaml - - - name: example of using top-level options for connection properties - ios_command: - commands: show version - host: "{{ inventory_hostname }}" - username: cisco - password: cisco - authorize: yes - auth_pass: cisco - - -Change your playbooks to the connection types ``network_cli`` and ``netconf`` using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules` guide and the :ref:`platform documentation`. diff --git a/docs/docsite/rst/porting_guides/porting_guide_3.rst b/docs/docsite/rst/porting_guides/porting_guide_3.rst deleted file mode 100644 index 12ec21cd08e..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_3.rst +++ /dev/null @@ -1,653 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_base_2.10.rst) - -.. _porting_3_guide: - -======================= -Ansible 3 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 3 is based on Ansible-Base 2.10, which is the same major release as Ansible 2.10. Therefore, there is no section on ansible-base in this porting guide. If you are upgrading from Ansible 2.9, please first consult the Ansible 2.10 porting guide before continuing with the Ansible 3 porting guide. - -We suggest you read this page along with the `Ansible 3 Changelog `_ to understand what updates you may need to make. - -Porting Guide for v3.4.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator. -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -Ansible-base -~~~~~~~~~~~~ - -- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients. - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85). - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_autosupport - Added REST support to the module. - -Deprecated Features -------------------- - -community.aws -~~~~~~~~~~~~~ - -- ec2_vpc_endpoint_info - the ``query`` option has been deprecated and will be removed after 2022-12-01 (https://github.com/ansible-collections/community.aws/pull/346). The ec2_vpc_endpoint_info now defaults to listing information about endpoints. The ability to search for information about available services has been moved to the dedicated module ``ec2_vpc_endpoint_service_info``. - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134). - -Porting Guide for v3.3.0 -======================== - -Major Changes -------------- - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_user - the ``REQUIRESSL`` is an alias for the ``ssl`` key in the ``tls_requires`` option in ``community.mysql`` 2.0.0 and support will be dropped altogether in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/121). - -Deprecated Features -------------------- - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_vmkernel_ip_config - deprecate in favor of vmware_vmkernel (https://github.com/ansible-collections/community.vmware/pull/667). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Python versions earlier than 3.5 is being deprecated - -Porting Guide for v3.2.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator. -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Breaking Changes ----------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_swarm - if ``join_token`` is specified, a returned join token with the same value will be replaced by ``VALUE_SPECIFIED_IN_NO_LOG_PARAMETER``. Make sure that you do not blindly use the join tokens from the return value of this module when the module is invoked with ``join_token`` specified! This breaking change appears in a minor release since it is necessary to fix a security issue (https://github.com/ansible-collections/community.docker/pull/103). - -Deprecated Features -------------------- - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme module_utils - the ``acme`` module_utils (``ansible_collections.community.crypto.plugins.module_utils.acme``) is deprecated and will be removed in community.crypto 2.0.0. Use the new Python modules in the ``acme`` package instead (``ansible_collections.community.crypto.plugins.module_utils.acme.xxx``) (https://github.com/ansible-collections/community.crypto/pull/184). - -Porting Guide for v3.1.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -community.grafana -~~~~~~~~~~~~~~~~~ - -- introduce "skip_version_check" parameter in grafana_teams and grafana_folder modules (#147) - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_replication - the mode options values ``getslave``, ``startslave``, ``stopslave``, ``resetslave``, ``resetslaveall` and the master_use_gtid option ``slave_pos`` are deprecated (see the alternative values) and will be removed in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/97). -- mysql_replication - the word ``SLAVE`` in messages returned by the module will be changed to ``REPLICA`` in ``community.mysql`` 2.0.0 (https://github.com/ansible-collections/community.mysql/issues/98). - -Removed Features ----------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed TMOS v11 support for bigip_gtm_pool and bigip_gtm_wide_ip modules -- Removed quorum and monitor_type parameters in bigip_node module. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html -- Removed syslog_settings and pool_settings parameters in bigip_log_destination moduke. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html - -Deprecated Features -------------------- - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- The aliases ``server_uuids`` and ``server_uuid`` of the servers parameter in the volume module will be removed in version 3.0.0. - -community.aws -~~~~~~~~~~~~~ - -- ec2_eip - formally deprecate the ``instance_id`` alias for ``device_id`` (https://github.com/ansible-collections/community.aws/pull/349). -- ec2_vpc_endpoint - deprecate the policy_file option and recommend using policy with a lookup (https://github.com/ansible-collections/community.aws/pull/366). - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme_account_info - when ``retrieve_orders=url_list``, ``orders`` will no longer be returned in community.crypto 2.0.0. Use ``order_uris`` instead (https://github.com/ansible-collections/community.crypto/pull/178). - -community.general -~~~~~~~~~~~~~~~~~ - -- apt_rpm - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- composer - deprecated invalid parameter aliases ``working-dir``, ``global-command``, ``prefer-source``, ``prefer-dist``, ``no-dev``, ``no-scripts``, ``no-plugins``, ``optimize-autoloader``, ``classmap-authoritative``, ``apcu-autoloader``, ``ignore-platform-reqs``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- github_deploy_key - deprecated invalid parameter alias ``2fa_token``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- grove - the option ``message`` will be removed in community.general 4.0.0. Use the new option ``message_content`` instead (https://github.com/ansible-collections/community.general/pull/1929). -- homebrew - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- homebrew_cask - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- opkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- pacman - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- puppet - deprecated undocumented parameter ``show_diff``, will be removed in 7.0.0. (https://github.com/ansible-collections/community.general/pull/1927). -- runit - unused parameter ``dist`` marked for deprecation (https://github.com/ansible-collections/community.general/pull/1830). -- slackpkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- urpmi - deprecated invalid parameter aliases ``update-cache`` and ``no-recommends``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xbps - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xfconf - returning output as facts is deprecated, this will be removed in community.general 4.0.0. Please register the task output in a variable and use it instead. You can already switch to the new behavior now by using the new ``disable_facts`` option (https://github.com/ansible-collections/community.general/pull/1747). - -Porting Guide for v3.0.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Issue 1(186024): ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. -- Issue 2(187956): If an invalid job_id is provided, idrac_lifecycle_controller_job_status_info returns an error message. This error message does not contain information about the exact issue with the invalid job_id. -- Issue 3(188267): While updating the iDRAC firmware, the idrac_firmware module completes execution before the firmware update job is completed. An incorrect message is displayed in the task output as 'DRAC WSMAN endpoint returned HTTP code '400' Reason 'Bad Request''. This issue may occur if the target iDRAC firmware version is less than 3.30.30.30 - -Breaking Changes ----------------- - -Ansible-base -~~~~~~~~~~~~ - -- ansible-galaxy login command has been removed ( see `issue 71560 `_) - -ansible.utils -~~~~~~~~~~~~~ - -- If added custom sub plugins in your collection move from old location `plugins/` to the new location `plugins/sub_plugins/` and update the imports as required -- Move sub plugins cli_parsers, fact_diff and validate to `plugins/sub_plugins` folder -- The `cli_parsers` sub plugins folder name is changed to `cli_parse` to have consistent naming convention, that is all the cli_parse subplugins will now be in `plugins/sub_plugins/cli_parse` folder - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- floating_ip - ``name`` is required for assigning a new floating IP. - -community.general -~~~~~~~~~~~~~~~~~ - -- If you use Ansible 2.9 and the Google cloud plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Google cloud content by FQCN, like ``community.general.gce_img``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.google.gce_img`` for the previous example) and to make sure that you have ``community.google`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.google`` or ``google.cloud`` collections if you are using any of the Google cloud plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work. -- If you use Ansible 2.9 and the Kubevirt plugins or modules from this collection, community.general 2.0.0 results in errors when trying to use the Kubevirt content by FQCN, like ``community.general.kubevirt_vm``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.kubevirt.kubevirt_vm`` for the previous example) and to make sure that you have ``community.kubevirt`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``community.kubevirt`` collection if you are using any of the Kubevirt plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (such as community.google) must be installed for them to work. -- If you use Ansible 2.9 and the ``docker`` plugins or modules from this collections, community.general 2.0.0 results in errors when trying to use the docker content by FQCN, like ``community.general.docker_container``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.docker.docker_container`` for the previous example) and to make sure that you have ``community.docker`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.docker`` if you are using any of the ``docker`` plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.docker) must be installed for them to work. -- If you use Ansible 2.9 and the ``hashi_vault`` lookup plugin from this collections, community.general 2.0.0 results in errors when trying to use the Hashi Vault content by FQCN, like ``community.general.hashi_vault``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.hashi_vault.hashi_vault``) and to make sure that you have ``community.hashi_vault`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hashi_vault`` if you are using the ``hashi_vault`` plugin. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hashi_vault) must be installed for them to work. -- If you use Ansible 2.9 and the ``hetzner`` modules from this collections, community.general 2.0.0 results in errors when trying to use the hetzner content by FQCN, like ``community.general.hetzner_firewall``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.hrobot.firewall`` for the previous example) and to make sure that you have ``community.hrobot`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.hrobot`` if you are using any of the ``hetzner`` modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.hrobot) must be installed for them to work. -- If you use Ansible 2.9 and the ``oc`` connection plugin from this collections, community.general 2.0.0 results in errors when trying to use the oc content by FQCN, like ``community.general.oc``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your inventories, variable files, playbooks and roles manually to use the new FQCN (``community.okd.oc``) and to make sure that you have ``community.okd`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.okd`` if you are using the ``oc`` plugin. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.okd) must be installed for them to work. -- If you use Ansible 2.9 and the ``postgresql`` modules from this collections, community.general 2.0.0 results in errors when trying to use the postgresql content by FQCN, like ``community.general.postgresql_info``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.postgresql.postgresql_info`` for the previous example) and to make sure that you have ``community.postgresql`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install ``community.postgresql`` if you are using any of the ``postgresql`` modules. - While ansible-base 2.10 or newer can use the redirects that community.general 2.0.0 adds, the collection they point to (community.postgresql) must be installed for them to work. -- The Google cloud inventory script ``gce.py`` has been migrated to the ``community.google`` collection. Install the ``community.google`` collection in order to continue using it. -- archive - remove path folder itself when ``remove`` parameter is true (https://github.com/ansible-collections/community.general/issues/1041). -- log_plays callback - add missing information to the logs generated by the callback plugin. This changes the log message format (https://github.com/ansible-collections/community.general/pull/442). -- passwordstore lookup plugin - now parsing a password store entry as YAML if possible, skipping the first line (which by convention only contains the password and nothing else). If it cannot be parsed as YAML, the old ``key: value`` parser will be used to process the entry. Can break backwards compatibility if YAML formatted code was parsed in a non-YAML interpreted way, for example ``foo: [bar, baz]``, will become a list with two elements in the new version, but a string ``'[bar, baz]'`` in the old (https://github.com/ansible-collections/community.general/issues/1673). -- pkgng - passing ``name: *`` with ``state: absent`` will no longer remove every installed package from the system. It is now a noop. (https://github.com/ansible-collections/community.general/pull/569). -- pkgng - passing ``name: *`` with ``state: latest`` or ``state: present`` will no longer install every package from the configured package repositories. Instead, ``name: *, state: latest`` will upgrade all already-installed packages, and ``name: *, state: present`` is a noop. (https://github.com/ansible-collections/community.general/pull/569). -- proxmox_kvm - recognize ``force=yes`` in conjunction with ``state=absent`` to forcibly remove a running VM (https://github.com/ansible-collections/community.general/pull/849). -- utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - the ``VAULT_ADDR`` environment variable is now checked last for the ``url`` parameter. For details on which use cases are impacted, see (https://github.com/ansible-collections/community.hashi_vault/issues/8). - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - now requires the `ipaddress `_ library (https://github.com/ansible-collections/community.hrobot/pull/2). - -community.network -~~~~~~~~~~~~~~~~~ - -- If you use Ansible 2.9 and the FortiOS modules from this collection, community.network 2.0.0 results in errors when trying to use the FortiOS content by FQCN, like ``community.network.fmgr_device``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.fortios.fmgr_device`` for the previous example) and to make sure that you have ``community.fortios`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.fortios`` if you are using any of the FortiOS modules. - While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.fortios) must be installed for them to work. -- If you use Ansible 2.9 and the ``cp_publish`` module from this collection, community.network 2.0.0 results in errors when trying to use the module by FQCN, i.e. ``community.network.cp_publish``. Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``check_point.mgmt.cp_mgmt_publish``) and to make sure that you have ``check_point.mgmt`` installed. - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``check_point.mgmt`` if you are using the ``cp_publish`` module. While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (check_point.mgmt) must be installed for them to work. -- If you use Ansible 2.9 and the ``fortimanager`` httpapi plugin from this collection, community.network 2.0.0 results in errors when trying to use it by FQCN (``community.network.fortimanager``). - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCN ``fortinet.fortimanager.fortimanager`` and to make sure that you have ``fortinet.fortimanager`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``fortinet.fortimanager`` if you are using the ``fortimanager`` httpapi plugin. - While ansible-base 2.10 or newer can use the redirect that community.network 2.0.0 adds, the collection they point to (fortinet.fortimanager) must be installed for it to work. -- If you use Ansible 2.9 and the ``nso`` modules from this collection, community.network 2.0.0 results in errors when trying to use the nso content by FQCN, like ``community.network.nso_config``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``cisco.nso.nso_config`` for the previous example) and to make sure that you have ``cisco.nso`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``cisco.nso`` if you are using any of the ``nso`` modules. - While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (cisco.nso) must be installed for them to work. -- If you use Ansible 2.9 and the ``routeros`` plugins or modules from this collections, community.network 2.0.0 results in errors when trying to use the routeros content by FQCN, like ``community.network.routeros_command``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``community.routeros.command`` for the previous example) and to make sure that you have ``community.routeros`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 3.0.0, but installed (and/or upgraded) community.network manually, you need to make sure to also install ``community.routeros`` if you are using any of the ``routeros`` plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.network 2.0.0 adds, the collection they point to (community.routeros) must be installed for them to work. -- cnos_static_route - move ipaddress import from ansible.netcommon to builtin or package before ipaddress is removed from ansible.netcommon. You need to make sure to have the ipaddress package installed if you are using this module on Python 2.7 (https://github.com/ansible-collections/community.network/pull/129). - -dellemc.os10 -~~~~~~~~~~~~ - -- os10_bgp - Changed "subnet" key as list format instead of dictionary format under "listen" key to support multiple neighbor prefix for listen command -- os10_bgp - Changed "vrf" key as list format instead of dictionary format to support multiple VRF in router BGP and changed the "vrf" key name to "vrfs" - -ngine_io.cloudstack -~~~~~~~~~~~~~~~~~~~ - -- Authentication option using INI files for example ``cloudstack.ini``, has been removed. The only supported option to authenticate is by using the module params with fallback to the ENV variables. -- default zone deprecation - The `zone` param default value, across multiple modules, has been deprecated due to unreliable API (https://github.com/ngine-io/ansible-collection-cloudstack/pull/62). - -Major Changes -------------- - -cisco.aci -~~~~~~~~~ - -- Change certificate_name to name in aci_aaa_user_certificate module for query operation - -community.general -~~~~~~~~~~~~~~~~~ - -- For community.general 3.0.0, the ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules will be moved to the `dellemc.openmanage `_ collection. - A redirection will be inserted so that users using ansible-base 2.10 or newer do not have to change anything. - - If you use Ansible 2.9 and explicitly use the DellEMC modules mentioned above from this collection, you will need to adjust your playbooks and roles to use FQCNs starting with ``dellemc.openmanage.`` instead of ``community.general.``, - for example replace ``community.general.ome_device_info`` in a task by ``dellemc.openmanage.ome_device_info``. - - If you use ansible-base and installed ``community.general`` manually and rely on the DellEMC modules mentioned above, you have to make sure to install the ``dellemc.openmanage`` collection as well. - If you are using FQCNs, for example ``community.general.ome_device_info`` instead of ``ome_device_info``, it will continue working, but we still recommend to adjust the FQCNs as well. -- The community.general collection no longer depends on the ansible.netcommon collection (https://github.com/ansible-collections/community.general/pull/1561). -- The community.general collection no longer depends on the ansible.posix collection (https://github.com/ansible-collections/community.general/pull/1157). - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- k8s - Add support for template parameter (https://github.com/ansible-collections/community.kubernetes/pull/230). -- k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/community.kubernetes/pull/193). - -community.okd -~~~~~~~~~~~~~ - -- Add custom k8s module, integrate better Molecule tests (https://github.com/ansible-collections/community.okd/pull/7). -- Add downstream build scripts to build redhat.openshift (https://github.com/ansible-collections/community.okd/pull/20). -- Add openshift connection plugin, update inventory plugin to use it (https://github.com/ansible-collections/community.okd/pull/18). -- Add openshift_process module for template rendering and optional application of rendered resources (https://github.com/ansible-collections/community.okd/pull/44). -- Add openshift_route module for creating routes from services (https://github.com/ansible-collections/community.okd/pull/40). -- Initial content migration from community.kubernetes (https://github.com/ansible-collections/community.okd/pull/3). -- openshift_auth - new module (migrated from k8s_auth in community.kubernetes) (https://github.com/ansible-collections/community.okd/pull/33). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Removed the existing deprecated modules. -- Standardization of ten iDRAC ansible modules based on ansible guidelines. -- Support for OpenManage Enterprise Modular. - -dellemc.os10 -~~~~~~~~~~~~ - -- os10_bgp - Enhanced router bgp keyword support for non-default vrf which are supported for default vrf and additional keyword to support both default and non-default vrf -- os10_snmp role - Added support for snmp V3 features in community, group, host, engineID - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Add phone home Teem integration into all modules, functionality can be disabled by setting up F5_TEEM environment variable or no_f5_teem provider parameter -- Added async_timeout parameter to bigip_ucs_fetch module to allow customization of module wait for async interface -- Changed bigip_ucs_fetch module to use asynchronous interface when generating UCS files - -kubernetes.core -~~~~~~~~~~~~~~~ - -- Add changelog and fragments and document changelog process (https://github.com/ansible-collections/kubernetes.core/pull/131). -- helm - New module for managing Helm charts (https://github.com/ansible-collections/kubernetes.core/pull/61). -- helm_info - New module for retrieving Helm chart information (https://github.com/ansible-collections/kubernetes.core/pull/61). -- helm_plugin - new module to manage Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154). -- helm_plugin_info - new modules to gather information about Helm plugins (https://github.com/ansible-collections/kubernetes.core/pull/154). -- helm_repository - New module for managing Helm repositories (https://github.com/ansible-collections/kubernetes.core/pull/61). -- k8s - Add support for template parameter (https://github.com/ansible-collections/kubernetes.core/pull/230). -- k8s - Inventory source migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Lookup plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_* - Add support for vaulted kubeconfig and src (https://github.com/ansible-collections/kubernetes.core/pull/193). -- k8s_auth - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_config_resource_name - Filter plugin migrated from Ansible 2.9 to Kubernetes collection. -- k8s_exec - New module for executing commands on pods through Kubernetes API (https://github.com/ansible-collections/kubernetes.core/pull/14). -- k8s_exec - Return rc for the command executed (https://github.com/ansible-collections/kubernetes.core/pull/158). -- k8s_info - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_log - New module for retrieving pod logs (https://github.com/ansible-collections/kubernetes.core/pull/16). -- k8s_scale - Module migrated from Ansible 2.9 to Kubernetes collection. -- k8s_service - Module migrated from Ansible 2.9 to Kubernetes collection. -- kubectl - Connection plugin migrated from Ansible 2.9 to Kubernetes collection. -- openshift - Inventory source migrated from Ansible 2.9 to Kubernetes collection. - -netbox.netbox -~~~~~~~~~~~~~ - -- nb_inventory - Add ``dns_name`` option that adds ``dns_name`` to the host when ``True`` and device has a primary IP address. (#394) -- nb_inventory - Add ``status`` as a ``group_by`` option. (398) -- nb_inventory - Move around ``extracted_primary_ip`` to allow for ``config_context`` or ``custom_field`` to overwrite. (#377) -- nb_inventory - Services are now a list of integers due to NetBox 2.10 changes. (#396) -- nb_lookup - Allow ID to be passed in and use ``.get`` instead of ``.filter``. (#376) -- nb_lookup - Allow ``api_endpoint`` and ``token`` to be found through env. (#391) - -ovirt.ovirt -~~~~~~~~~~~ - -- cluster_upgrade - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/94). -- disaster_recovery - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/134). -- engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/69). -- hosted_engine_setup - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/106). -- image_template - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/95). -- infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/92). -- manageiq - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/97). -- ovirt_system_option_info - Add new module (https://github.com/oVirt/ovirt-ansible-collection/pull/206). -- repositories - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/96). -- shutdown_env - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/112). -- vm_infra - Migrate role (https://github.com/oVirt/ovirt-ansible-collection/pull/93). - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- add new tests (find with no result, search many) -- add related tests -- add support for ServiceNOW table api display_value exclude_reference_link and suppress_pagination_header -- use new API for pysnow >=0.6.0 - -Removed Features ----------------- - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the default of ``networks_cli_compatible`` changed to ``true`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_container - the unused option ``trust_image_content`` has been removed (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - ``state=build`` has been removed. Use ``present`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``container_limits``, ``dockerfile``, ``http_timeout``, ``nocache``, ``rm``, ``path``, ``buildargs``, ``pull`` have been removed. Use the corresponding suboptions of ``build`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``force`` option has been removed. Use the more specific ``force_*`` options instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``source`` option is now mandatory (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the ``use_tls`` option has been removed. Use ``tls`` and ``validate_certs`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image - the default of the ``build.pull`` option changed to ``false`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_image_facts - this alias is on longer available, use ``docker_image_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_network - the ``ipam_options`` option has been removed. Use ``ipam_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_service - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm - ``state=inspect`` has been removed. Use ``docker_swarm_info`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``constraints`` option has been removed. Use ``placement.constraints`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``limit_cpu`` and ``limit_memory`` options has been removed. Use the corresponding suboptions in ``limits`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``log_driver`` and ``log_driver_options`` options has been removed. Use the corresponding suboptions in ``logging`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``reserve_cpu`` and ``reserve_memory`` options has been removed. Use the corresponding suboptions in ``reservations`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``restart_policy``, ``restart_policy_attempts``, ``restart_policy_delay`` and ``restart_policy_window`` options has been removed. Use the corresponding suboptions in ``restart_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_swarm_service - the ``update_delay``, ``update_parallelism``, ``update_failure_action``, ``update_monitor``, ``update_max_failure_ratio`` and ``update_order`` options has been removed. Use the corresponding suboptions in ``update_config`` instead (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - no longer returns ``ansible_facts`` (https://github.com/ansible-collections/community.docker/pull/1). -- docker_volume - the ``force`` option has been removed. Use ``recreate`` instead (https://github.com/ansible-collections/community.docker/pull/1). - -community.general -~~~~~~~~~~~~~~~~~ - -- All Google cloud modules and plugins have now been migrated away from this collection. - They can be found in either the `community.google `_ or `google.cloud `_ collections. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.gce_img`` → ``community.google.gce_img``) and make sure to install the community.google or google.cloud collections as appropriate. -- All Kubevirt modules and plugins have now been migrated from community.general to the `community.kubevirt `_ Ansible collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.kubevirt_vm`` → ``community.kubevirt.kubevirt_vm``) and make sure to install the community.kubevirt collection. -- All ``docker`` modules and plugins have been removed from this collection. - They have been migrated to the `community.docker `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.docker_container`` → ``community.docker.docker_container``) and make sure to install the community.docker collection. -- All ``hetzner`` modules have been removed from this collection. - They have been migrated to the `community.hrobot `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hetzner_firewall`` → ``community.hrobot.firewall``) and make sure to install the community.hrobot collection. -- All ``postgresql`` modules have been removed from this collection. - They have been migrated to the `community.postgresql `_ collection. - - If you use ansible-base 2.10 or newer, redirections have been provided. - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.postgresql_info`` → ``community.postgresql.postgresql_info``) and make sure to install the community.postgresql collection. -- The Google cloud inventory script ``gce.py`` has been migrated to the ``community.google`` collection. Install the ``community.google`` collection in order to continue using it. -- The ``hashi_vault`` lookup plugin has been removed from this collection. - It has been migrated to the `community.hashi_vault `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.hashi_vault`` → ``community.hashi_vault.hashi_vault``) and make sure to install the community.hashi_vault collection. -- The ``oc`` connection plugin has been removed from this collection. - It has been migrated to the `community.okd `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.oc`` → ``community.okd.oc``) and make sure to install the community.okd collection. -- The deprecated ``actionable`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` and ``display_ok_hosts = no`` options instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``foreman`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347) (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``full_skip`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_skipped_hosts = no`` option instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``gcdns_record`` module has been removed. Use ``google.cloud.gcp_dns_resource_record_set`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcdns_zone`` module has been removed. Use ``google.cloud.gcp_dns_managed_zone`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gce`` module has been removed. Use ``google.cloud.gcp_compute_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_backend_service`` module has been removed. Use ``google.cloud.gcp_compute_backend_service`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_forwarding_rule`` module has been removed. Use ``google.cloud.gcp_compute_forwarding_rule`` or ``google.cloud.gcp_compute_global_forwarding_rule`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_healthcheck`` module has been removed. Use ``google.cloud.gcp_compute_health_check``, ``google.cloud.gcp_compute_http_health_check`` or ``google.cloud.gcp_compute_https_health_check`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_target_proxy`` module has been removed. Use ``google.cloud.gcp_compute_target_http_proxy`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcp_url_map`` module has been removed. Use ``google.cloud.gcp_compute_url_map`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``gcspanner`` module has been removed. Use ``google.cloud.gcp_spanner_database`` and/or ``google.cloud.gcp_spanner_instance`` instead (https://github.com/ansible-collections/community.general/pull/1370). -- The deprecated ``github_hooks`` module has been removed. Use ``community.general.github_webhook`` and ``community.general.github_webhook_info`` instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``katello`` module has been removed. Use the modules from the theforeman.foreman collection instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_aggregate`` module has been removed. Use netapp.ontap.na_ontap_aggregate instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_license`` module has been removed. Use netapp.ontap.na_ontap_license instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_lun`` module has been removed. Use netapp.ontap.na_ontap_lun instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_qtree`` module has been removed. Use netapp.ontap.na_ontap_qtree instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_svm`` module has been removed. Use netapp.ontap.na_ontap_svm instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_user_role`` module has been removed. Use netapp.ontap.na_ontap_user_role instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_user`` module has been removed. Use netapp.ontap.na_ontap_user instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``na_cdot_volume`` module has been removed. Use netapp.ontap.na_ontap_volume instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_account_manager`` module has been removed. Use netapp.elementsw.na_elementsw_account instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_check_connections`` module has been removed. Use netapp.elementsw.na_elementsw_check_connections instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_snapshot_schedule_manager`` module has been removed. Use netapp.elementsw.na_elementsw_snapshot_schedule instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_volume_access_group_manager`` module has been removed. Use netapp.elementsw.na_elementsw_access_group instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``sf_volume_manager`` module has been removed. Use netapp.elementsw.na_elementsw_volume instead (https://github.com/ansible-collections/community.general/pull/1347). -- The deprecated ``stderr`` callback plugin has been removed. Use the ``ansible.builtin.default`` callback plugin with ``display_failed_stderr = yes`` option instead (https://github.com/ansible-collections/community.general/pull/1347). -- The redirect of the ``conjur_variable`` lookup plugin to ``cyberark.conjur.conjur_variable`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect of the ``firewalld`` module and the ``firewalld`` module_utils to the ``ansible.posix`` collection was removed (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``community.digitalocean`` collection was removed for: the ``digital_ocean`` doc fragment, the ``digital_ocean`` module_utils, and the following modules: ``digital_ocean``, ``digital_ocean_account_facts``, ``digital_ocean_account_info``, ``digital_ocean_block_storage``, ``digital_ocean_certificate``, ``digital_ocean_certificate_facts``, ``digital_ocean_certificate_info``, ``digital_ocean_domain``, ``digital_ocean_domain_facts``, ``digital_ocean_domain_info``, ``digital_ocean_droplet``, ``digital_ocean_firewall_facts``, ``digital_ocean_firewall_info``, ``digital_ocean_floating_ip``, ``digital_ocean_floating_ip_facts``, ``digital_ocean_floating_ip_info``, ``digital_ocean_image_facts``, ``digital_ocean_image_info``, ``digital_ocean_load_balancer_facts``, ``digital_ocean_load_balancer_info``, ``digital_ocean_region_facts``, ``digital_ocean_region_info``, ``digital_ocean_size_facts``, ``digital_ocean_size_info``, ``digital_ocean_snapshot_facts``, ``digital_ocean_snapshot_info``, ``digital_ocean_sshkey``, ``digital_ocean_sshkey_facts``, ``digital_ocean_sshkey_info``, ``digital_ocean_tag``, ``digital_ocean_tag_facts``, ``digital_ocean_tag_info``, ``digital_ocean_volume_facts``, ``digital_ocean_volume_info`` (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``community.mysql`` collection was removed for: the ``mysql`` doc fragment, the ``mysql`` module_utils, and the following modules: ``mysql_db``, ``mysql_info``, ``mysql_query``, ``mysql_replication``, ``mysql_user``, ``mysql_variables`` (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``community.proxysql`` collection was removed for: the ``proxysql`` doc fragment, and the following modules: ``proxysql_backend_servers``, ``proxysql_global_variables``, ``proxysql_manage_config``, ``proxysql_mysql_users``, ``proxysql_query_rules``, ``proxysql_replication_hostgroups``, ``proxysql_scheduler`` (https://github.com/ansible-collections/community.general/pull/1346). -- The redirect to the ``infinidat.infinibox`` collection was removed for: the ``infinibox`` doc fragment, the ``infinibox`` module_utils, and the following modules: ``infini_export``, ``infini_export_client``, ``infini_fs``, ``infini_host``, ``infini_pool``, ``infini_vol`` (https://github.com/ansible-collections/community.general/pull/1346). -- conjur_variable lookup - has been moved to the ``cyberark.conjur`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/570). -- digital_ocean_* - all DigitalOcean modules have been moved to the ``community.digitalocean`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/622). -- infini_* - all infinidat modules have been moved to the ``infinidat.infinibox`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/607). -- iptables_state - the ``ANSIBLE_ASYNC_DIR`` environment is no longer supported, use the ``async_dir`` shell option instead (https://github.com/ansible-collections/community.general/pull/1371). -- logicmonitor - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- logicmonitor_facts - the module has been removed in 1.0.0 since it is unmaintained and the API used by the module has been turned off in 2017 (https://github.com/ansible-collections/community.general/issues/539, https://github.com/ansible-collections/community.general/pull/541). -- memcached cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371). -- mysql_* - all MySQL modules have been moved to the ``community.mysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/633). -- proxysql_* - all ProxySQL modules have been moved to the ``community.proxysql`` collection. A redirection is active, which will be removed in version 2.0.0 (https://github.com/ansible-collections/community.general/pull/624). -- redis cache plugin - do not import ``CacheModule``s directly. Use ``ansible.plugins.loader.cache_loader`` instead (https://github.com/ansible-collections/community.general/pull/1371). -- xml - when ``content=attribute``, the ``attribute`` option is ignored (https://github.com/ansible-collections/community.general/pull/1371). - -community.network -~~~~~~~~~~~~~~~~~ - -- All FortiOS modules and plugins have been removed from this collection. - They have been migrated to the `community.fortios `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fmgr_device`` → ``community.fortios.fmgr_device``) and make sure to install the `community.fortios` collection. -- All ``nso`` modules have been removed from this collection. - They have been migrated to the `cisco.nso `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.nso_config`` → ``cisco.nso.nso_config``) and make sure to install the `cisco.nso` collection. -- All ``routeros`` modules and plugins have been removed from this collection. - They have been migrated to the `community.routeros `_ collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.routeros_command`` → ``community.routeros.command``) and make sure to install the community.routeros collection. -- The ``cp_publish`` module has been removed from this collection. It was a duplicate of ``check_point.mgmt.cp_mgmt_publish`` in the `check_point.mgmt `_ collection. If you use ansible-base 2.10 or newer, redirections have been provided. - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.cp_publish`` → ``check_point.mgmt.cp_mgmt_publish``) and make sure to install the check_point.mgmt collection. -- The ``fortimanager`` httpapi plugin has been removed from this collection. - It was a duplicate of the one in the `fortinet.fortimanager `_ collection. - If you use ansible-base 2.10 or newer, a redirection has been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.network.fortimanager`` → ``fortinet.fortimanager.fortimanager``) and make sure to install the `fortinet.fortimanager` collection. -- The dependency on the ``check_point.mgmt`` collection has been removed. If you depend on that installing ``community.network`` also installs ``check_point.mgmt``, you have to make sure to install ``check_point.mgmt`` explicitly. -- The deprecated Pluribus Networks modules ``pn_cluster``, ``pn_ospf``, ``pn_ospfarea``, ``pn_show``, ``pn_trunk``, ``pn_vlag``, ``pn_vlan``, ``pn_vrouter``, ``pn_vrouterbgp``, ``pn_vrouterif``, ``pn_vrouterlbif`` have been removed (https://github.com/ansible-collections/community.network/pull/176). -- The deprecated modules ``panos_admin``, ``panos_admpwd``, ``panos_cert_gen_ssh``, ``panos_check``, ``panos_commit``, ``panos_dag``, ``panos_dag_tags``, ``panos_import``, ``panos_interface``, ``panos_lic``, ``panos_loadcfg``, ``panos_match_rule``, ``panos_mgtconfig``, ``panos_nat_rule``, ``panos_object``, ``panos_op``, ``panos_pg``, ``panos_query_rules``, ``panos_restart``, ``panos_sag``, ``panos_security_rule``, ``panos_set`` have been removed. Use modules from the `paloaltonetworks.panos collection `_ instead (https://github.com/ansible-collections/community.network/pull/176). -- The redirect to the ``mellanox.onyx`` collection was removed for: the ``onyx`` cliconf plugin, terminal plugin, module_utils, action plugin, doc fragment, and the following modules: ``onyx_aaa``, ``onyx_bfd``, ``onyx_bgp``, ``onyx_buffer_pool``, ``onyx_command``, ``onyx_config``, ``onyx_facts``, ``onyx_igmp``, ``onyx_igmp_interface``, ``onyx_igmp_vlan``, ``onyx_interface``, ``onyx_l2_interface``, ``onyx_l3_interface``, ``onyx_linkagg``, ``onyx_lldp``, ``onyx_lldp_interface``, ``onyx_magp``, ``onyx_mlag_ipl``, ``onyx_mlag_vip``, ``onyx_ntp``, ``onyx_ntp_servers_peers``, ``onyx_ospf``, ``onyx_pfc_interface``, ``onyx_protocol``, ``onyx_ptp_global``, ``onyx_ptp_interface``, ``onyx_qos``, ``onyx_snmp``, ``onyx_snmp_hosts``, ``onyx_snmp_users``, ``onyx_syslog_files``, ``onyx_syslog_remote``, ``onyx_traffic_class``, ``onyx_username``, ``onyx_vlan``, ``onyx_vxlan``, ``onyx_wjh`` (https://github.com/ansible-collections/community.network/pull/175). -- onyx - all onyx modules and plugins have been moved to the mellanox.onyx collection. Redirects have been added that will be removed in community.network 2.0.0 (https://github.com/ansible-collections/community.network/pull/83). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed arp_state parameter from the bigip_virtual_address module - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_bgp` and `nxos_bgp_neighbor` modules in favor of `nxos_bgp_global` resource module. -- Deprecated `nxos_interface_ospf` in favor of `nxos_ospf_interfaces` Resource Module. -- Deprecated `nxos_smu` in favor of `nxos_rpm` module. -- The `nxos_ospf_vrf` module is deprecated by `nxos_ospfv2` and `nxos_ospfv3` Resource Modules. - -community.aws -~~~~~~~~~~~~~ - -- ec2_vpc_igw_info - After 2022-06-22 the ``convert_tags`` parameter default value will change from ``False`` to ``True`` to match the collection standard behavior (https://github.com/ansible-collections/community.aws/pull/318). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - currently ``published_ports`` can contain port mappings next to the special value ``all``, in which case the port mappings are ignored. This behavior is deprecated for community.docker 2.0.0, at which point it will either be forbidden, or this behavior will be properly implemented similar to how the Docker CLI tool handles this (https://github.com/ansible-collections/community.docker/issues/8, https://github.com/ansible-collections/community.docker/pull/60). - -community.general -~~~~~~~~~~~~~~~~~ - -- The ``gluster_heal_info``, ``gluster_peer`` and ``gluster_volume`` modules have migrated to the `gluster.gluster `_ collection. Ansible-base 2.10.1 adjusted the routing target to point to the modules in that collection, so we will remove these modules in community.general 3.0.0. If you use Ansible 2.9, or use FQCNs ``community.general.gluster_*`` in your playbooks and/or roles, please update them to use the modules from ``gluster.gluster`` instead. -- The ldap_attr module has been deprecated and will be removed in a later release; use ldap_attrs instead. -- django_manage - the parameter ``liveserver`` relates to a no longer maintained third-party module for django. It is now deprecated, and will be remove in community.general 3.0.0 (https://github.com/ansible-collections/community.general/pull/1154). -- proxmox - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- proxmox_kvm - the default of the new ``proxmox_default_behavior`` option will change from ``compatibility`` to ``no_defaults`` in community.general 4.0.0. Set the option to an explicit value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/850). -- syspatch - deprecate the redundant ``apply`` argument (https://github.com/ansible-collections/community.general/pull/360). -- xbps - the ``force`` option never had any effect. It is now deprecated, and will be removed in 3.0.0 (https://github.com/ansible-collections/community.general/pull/568). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault - ``VAULT_ADDR`` environment variable for option ``url`` will have its precedence lowered in 1.0.0; use ``ANSIBLE_HASHI_VAULT_ADDR`` to intentionally override a config value (https://github.com/ansible-collections/community.hashi_vault/issues/8). -- hashi_vault - ``VAULT_AUTH_METHOD`` environment variable for option ``auth_method`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_AUTH_METHOD`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/17). -- hashi_vault - ``VAULT_ROLE_ID`` environment variable for option ``role_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_ROLE_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_SECRET_ID`` environment variable for option ``secret_id`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_SECRET_ID`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/20). -- hashi_vault - ``VAULT_TOKEN_FILE`` environment variable for option ``token_file`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_FILE`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). -- hashi_vault - ``VAULT_TOKEN_PATH`` environment variable for option ``token_path`` will be removed in 2.0.0, use ``ANSIBLE_HASHI_VAULT_TOKEN_PATH`` instead (https://github.com/ansible-collections/community.hashi_vault/issues/15). - -community.network -~~~~~~~~~~~~~~~~~ - -- Deprecate connection=local support for network platforms using persistent framework (https://github.com/ansible-collections/community.network/pull/120). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_host_firewall_manager - the creation of new rule with no ``allowed_ip`` entry in the ``allowed_hosts`` dictionary won't be allowed after 2.0.0 release. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- The ``dellemc_get_firmware_inventory`` module is deprecated and replaced with ``idrac_firmware_info``. -- The ``dellemc_get_system_inventory`` module is deprecated and replaced with ``idrac_system_info``. -- The dellemc_change_power_state module is deprecated and replaced with the redfish_powerstate module. -- The dellemc_configure_bios module is deprecated and replaced with the idrac_bios module. -- The dellemc_configure_idrac_network module is deprecated and replaced with the idrac_network module. -- The dellemc_configure_idrac_timezone module is deprecated and replaced with the idrac_timezone_ntp module. -- The dellemc_configure_idrac_users module is deprecated and replaced with the idrac_user module. -- The dellemc_delete_lc_job and dellemc_delete_lc_job_queue modules are deprecated and replaced with the idrac_lifecycle_controller_jobs module. -- The dellemc_export_lc_logs module is deprecated and replaced with the idrac_lifecycle_controller_logs module. -- The dellemc_get_lc_job_status module is deprecated and replaced with the idrac_lifecycle_controller_job_status_info module. -- The dellemc_get_lcstatus module is deprecated and replaced with the idrac_lifecycle_controller_status_info module. -- The dellemc_idrac_reset module is deprecated and replaced with the idrac_reset module. -- The dellemc_setup_idrac_syslog module is deprecated and replaced with the idrac_syslog module. diff --git a/docs/docsite/rst/porting_guides/porting_guide_4.rst b/docs/docsite/rst/porting_guides/porting_guide_4.rst deleted file mode 100644 index 5f45910b4f0..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_4.rst +++ /dev/null @@ -1,894 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_base_2.11.rst) - -.. _porting_4_guide: - -======================= -Ansible 4 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -We suggest you read this page along with the `Ansible 4 Changelog `_ to understand what updates you may need to make. - -Playbook -======== - -* The ``jinja2_native`` setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argument ``jinja2_native`` (off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on the ``jinja2_native`` setting. - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth has been shut down. Publishing roles or collections to Galaxy with ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI using a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) with the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -The constant ``ansible.module_utils.basic._CHECK_ARGUMENT_TYPES_DISPATCHER`` is deprecated. Use :const:`ansible.module_utils.common.parameters.DEFAULT_TYPE_VALIDATORS` instead. - - -Breaking Changes -================ - -Changes to ``AnsibleModule`` ----------------------------- - -With the move to :class:`ArgumentSpecValidator ` for performing argument spec validation, the following private methods in :class:`AnsibleModule ` have been removed: - - - ``_check_argument_types()`` - - ``_check_argument_values()`` - - ``_check_arguments()`` - - ``_check_mutually_exclusive()`` --> :func:`ansible.module_utils.common.validation.check_mutually_exclusive` - - ``_check_required_arguments()`` --> :func:`ansible.module_utils.common.validation.check_required_arguments` - - ``_check_required_by()`` --> :func:`ansible.module_utils.common.validation.check_required_by` - - ``_check_required_if()`` --> :func:`ansible.module_utils.common.validation.check_required_if` - - ``_check_required_one_of()`` --> :func:`ansible.module_utils.common.validation.check_required_one_of` - - ``_check_required_together()`` --> :func:`ansible.module_utils.common.validation.check_required_together` - - ``_check_type_bits()`` --> :func:`ansible.module_utils.common.validation.check_type_bits` - - ``_check_type_bool()`` --> :func:`ansible.module_utils.common.validation.check_type_bool` - - ``_check_type_bytes()`` --> :func:`ansible.module_utils.common.validation.check_type_bytes` - - ``_check_type_dict()`` --> :func:`ansible.module_utils.common.validation.check_type_dict` - - ``_check_type_float()`` --> :func:`ansible.module_utils.common.validation.check_type_float` - - ``_check_type_int()`` --> :func:`ansible.module_utils.common.validation.check_type_int` - - ``_check_type_jsonarg()`` --> :func:`ansible.module_utils.common.validation.check_type_jsonarg` - - ``_check_type_list()`` --> :func:`ansible.module_utils.common.validation.check_type_list` - - ``_check_type_path()`` --> :func:`ansible.module_utils.common.validation.check_type_path` - - ``_check_type_raw()`` --> :func:`ansible.module_utils.common.validation.check_type_raw` - - ``_check_type_str()`` --> :func:`ansible.module_utils.common.validation.check_type_str` - - ``_count_terms()`` --> :func:`ansible.module_utils.common.validation.count_terms` - - ``_get_wanted_type()`` - - ``_handle_aliases()`` - - ``_handle_no_log_values()`` - - ``_handle_options()`` - - ``_set_defaults()`` - - ``_set_fallbacks()`` - -Modules or plugins using these private methods should use the public functions in :mod:`ansible.module_utils.common.validation` or :meth:`ArgumentSpecValidator.validate() ` if no public function was listed above. - - -Changes to :mod:`ansible.module_utils.common.parameters` --------------------------------------------------------- - -The following functions in :mod:`ansible.module_utils.common.parameters` are now private and should not be used directly. Use :meth:`ArgumentSpecValidator.validate() ` instead. - - - ``list_no_log_values`` - - ``list_deprecations`` - - ``handle_aliases`` - - -Other -====== - -* **Upgrading**: If upgrading from ``ansible < 2.10`` or from ``ansible-base`` and using pip, you must ``pip uninstall ansible`` or ``pip uninstall ansible-base`` before installing ``ansible-core`` to avoid conflicts. -* Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 still works with the same versions of Python that ``ansible-base`` 2.10 worked with, however 2.11 emits a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater. -* The configuration system now validates the ``choices`` field, so any settings that violate it and were ignored in 2.10 cause an error in 2.11. For example, ``ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0`` now causes an error (valid choices are ``ignore``, ``warn`` or ``error``). -* The ``ansible-galaxy`` command now uses ``resolvelib`` for resolving dependencies. In most cases this should not make a user-facing difference beyond being more performant, but we note it here for posterity and completeness. -* If you import Python ``module_utils`` into any modules you maintain, you may now mark the import as optional during the module payload build by wrapping the ``import`` statement in a ``try`` or ``if`` block. This allows modules to use ``module_utils`` that may not be present in all versions of Ansible or a collection, and to perform arbitrary recovery or fallback actions during module runtime. - - -Modules -======= - -* The ``apt_key`` module has explicitly defined ``file`` as mutually exclusive with ``data``, ``keyserver`` and ``url``. They cannot be used together anymore. -* The ``meta`` module now supports tags for user-defined tasks. Set the task's tags to 'always' to maintain the previous behavior. Internal ``meta`` tasks continue to always run. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -* facts - On NetBSD, ``ansible_virtualization_type`` now tries to report a more accurate result than ``xen`` when virtualized and not running on Xen. -* facts - Virtualization facts now include ``virtualization_tech_guest`` and ``virtualization_tech_host`` keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, if you set up a host to provide both KVM and VirtualBox, both values are included in ``virtualization_tech_host``. Similarly, a podman container running on a VM powered by KVM has a ``virtualization_tech_guest`` of ``["kvm", "podman", "container"]``. -* The parameter ``filter`` type is changed from ``string`` to ``list`` in the :ref:`setup ` module in order to use more than one filter. Previous behavior (using a ``string``) still remains and works as a single filter. - - -Plugins -======= - -* inventory plugins - ``CachePluginAdjudicator.flush()`` now calls the underlying cache plugin's ``flush()`` instead of only deleting keys that it knows about. Inventory plugins should use ``delete()`` to remove any specific keys. As a user, this means that when an inventory plugin calls its ``clear_cache()`` method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache. -* callback plugins - ``meta`` task execution is now sent to ``v2_playbook_on_task_start`` like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation. -* The ``choices`` are now validated, so plugins that were using incorrect or incomplete choices issue an error in 2.11 if the value provided does not match. This has a simple fix: update the entries in ``choices`` to match reality. - -Porting custom scripts -====================== - -No notable changes - -Porting Guide for v4.10.0 -========================= - -Major Changes -------------- - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add podman_tag module -- Add secrets driver and driver opts support - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_snmp_community module. -- Deprecated nxos_snmp_contact module. -- Deprecated nxos_snmp_host module. -- Deprecated nxos_snmp_location module. -- Deprecated nxos_snmp_traps module. -- Deprecated nxos_snmp_user module. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module. - -Porting Guide for v4.9.0 -======================== - -Known Issues ------------- - -purestorage.flashblade -~~~~~~~~~~~~~~~~~~~~~~ - -- purefb_lag - The mac_address field in the response is not populated. This will be fixed in a future FlashBlade update. - -Major Changes -------------- - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add real-world use cases in the example section for some configuration modules. -- Collect the current configurations of the modules and convert them into playbooks. -- Support FortiOS 7.0.1. -- Support member operation (delete/add extra members) on an object that has a list of members in it. -- Support selectors feature in ``fortios_monitor_fact`` and ``fortios_log_fact``. - -Porting Guide for v4.8.0 -======================== - -Breaking Changes ----------------- - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all roles now reference other roles and modules through their fully qualified collection names, which makes Ansible 2.10 minimum supported version for roles (see `issue 477 `_). - -Deprecated Features -------------------- - -community.azure -~~~~~~~~~~~~~~~ - -- All community.azure.azure_rm__facts modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- All community.azure.azure_rm__info modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_managed_disk and community.azure.azure_rm_manageddisk are deprecated. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_extension and community.azure.azure_rm_virtualmachineextension are deprecated. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_scaleset and community.azure.azure_rm_virtualmachinescaleset are deprecated. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/24). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- lookup hashi_vault - the ``[lookup_hashi_vault]`` section in the ``ansible.cfg`` file is deprecated and will be removed in collection version ``3.0.0``. Instead, the section ``[hashi_vault_collection]`` can be used, which will apply to all plugins in the collection going forward (https://github.com/ansible-collections/community.hashi_vault/pull/144). - -Porting Guide for v4.7.0 -======================== - -Major Changes -------------- - -openvswitch.openvswitch -~~~~~~~~~~~~~~~~~~~~~~~ - -- By mistake we tagged the repo to 2.0.0 and as it wasn't intended and cannot be reverted we're releasing 2.0.1 to make the community aware of the major version update. - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_ntp modules. - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_ntp`, `nxos_ntp_options`, `nxos_ntp_auth` modules. - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_guest_vnc - Sphere 7.0 removed the built-in VNC server (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#productsupport). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated router_id from ospfv2 resource module. - -Porting Guide for v4.6.0 -======================== - -Major Changes -------------- - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add systemd generation for pods -- Generate systemd service files for containers - -gluster.gluster -~~~~~~~~~~~~~~~ - -- enable client.ssl,server.ssl before starting the gluster volume (https://github.com/gluster/gluster-ansible-collection/pull/19) - -Deprecated Features -------------------- - -community.grafana -~~~~~~~~~~~~~~~~~ - -- grafana_dashboard lookup - Providing a mangled version of the API key is no longer preferred. - -Porting Guide for v4.5.0 -======================== - -Major Changes -------------- - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- Introduction of placement groups - -ovirt.ovirt -~~~~~~~~~~~ - -- remove_stale_lun - Add role for removing stale LUN (https://bugzilla.redhat.com/1966873). - -Deprecated Features -------------------- - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- network_cli - The paramiko_ssh setting ``look_for_keys`` was set automatically based on the values of the ``password`` and ``private_key_file`` options passed to network_cli. This option can now be set explicitly, and the automatic setting of ``look_for_keys`` will be removed after 2024-01-01 (https://github.com/ansible-collections/ansible.netcommon/pull/271). - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_bgp in favor of ios_bgp_global and ios_bgp_address_family. -- Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated router_id from ospfv3 resource module. - -Porting Guide for v4.4.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. - -Deprecated Features -------------------- - -cisco.iosxr -~~~~~~~~~~~ - -- The iosxr_logging module has been deprecated in favor of the new iosxr_logging_global resource module and will be removed in a release after '2023-08-01'. - -cisco.nxos -~~~~~~~~~~ - -- The nxos_logging module has been deprecated in favor of the new nxos_logging_global resource module and will be removed in a release after '2023-08-01'. - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - the new ``command_handling``'s default value, ``compatibility``, is deprecated and will change to ``correct`` in community.docker 3.0.0. A deprecation warning is emitted by the module in cases where the behavior will change. Please note that ansible-core will output a deprecation warning only once, so if it is shown for an earlier task, there could be more tasks with this warning where it is not shown (https://github.com/ansible-collections/community.docker/pull/186). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- The junos_logging module has been deprecated in favor of the new junos_logging_global resource module and will be removed in a release after '2023-08-01'. - -vyos.vyos -~~~~~~~~~ - -- The vyos_logging module has been deprecated in favor of the new vyos_logging_global resource module and will be removed in a release after "2023-08-01". - -Porting Guide for v4.3.0 -======================== - -Major Changes -------------- - -netapp.cloudmanager -~~~~~~~~~~~~~~~~~~~ - -- Adding stage environment to all modules in cloudmanager - -Deprecated Features -------------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault collection - support for Python 3.5 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). - -Porting Guide for v4.2.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_object_custom_attributes_info - added a new module to gather custom attributes of an object (https://github.com/ansible-collections/community.vmware/pull/851). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_server_config_profile - Added support for exporting and importing Server Configuration Profile through HTTP/HTTPS share. -- ome_device_group - Added support for adding devices to a group using the IP addresses of the devices and group ID. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- New module fortios_monitor_fact. -- Support Fortios 7.0. -- Support Log APIs. - -Deprecated Features -------------------- - -- The community.kubernetes collection is being renamed to kubernetes.core. In Ansible 5, community.kubernetes will be replaced by an empty collection which has deprecated redirects for all the current content to kubernetes.core. If you are using FQCNs starting with ``community.kubernetes.``, please update them to ``kubernetes.core.`` now. Note that kubernetes.core has been included in Ansible since Ansible 3.0.0 (https://github.com/ansible-community/community-topics/issues/22). - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_updates - Deprecated the ``filtered_reason`` return value for each filtered up in favour of ``filtered_reasons``. This has been done to show all the reasons why an update was filtered and not just the first reason. -- win_updates - Deprecated the ``use_scheduled_task`` option as it is no longer used. -- win_updates - Deprecated the ``whitelist`` and ``blacklist`` options in favour of ``accept_list`` and ``reject_list`` respectively to conform to the new standards used in Ansible for these types of options. - -community.general -~~~~~~~~~~~~~~~~~ - -- ali_instance_info - marked removal version of deprecated parameters ``availability_zone`` and ``instance_names`` (https://github.com/ansible-collections/community.general/issues/2429). -- serverless - deprecating parameter ``functions`` because it was not used in the code (https://github.com/ansible-collections/community.general/pull/2845). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault collection - support for Python 2 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). - -Porting Guide for v4.1.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- Add custom_image module - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- ome_firmware_baseline - Module supports check mode, and allows the modification and deletion of firmware baselines. -- ome_firmware_catalog - Module supports check mode, and allows the modification and deletion of firmware catalogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Improve ``fortios_configuration_fact`` to use multiple selectors concurrently. -- Support ``check_mode`` in all cofigurationAPI-based modules. -- Support filtering for fact gathering modules ``fortios_configuration_fact`` and ``fortios_monitor_fact``. -- Support moving policy in ``firewall_central_snat_map``. -- Unify schemas for monitor API. - -netbox.netbox -~~~~~~~~~~~~~ - -- packages is now a required Python package and gets installed through Ansible 2.10+. - -Removed Features ----------------- - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Removed ``shutdown_timeout`` and ``shutdown_timeout_sec`` which has not done anything since Ansible 2.5. - -Deprecated Features -------------------- - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Unreachable hosts can be ignored with ``ignore_errors: True``, this ability will be removed in a future version. Use ``ignore_unreachable: True`` to ignore unreachable hosts instead. - https://github.com/ansible-collections/ansible.windows/issues/62 - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134). - -community.general -~~~~~~~~~~~~~~~~~ - -- All inventory and vault scripts will be removed from community.general in version 4.0.0. If you are referencing them, please update your references to the new `contrib-scripts GitHub repository `_ so your workflow will not break once community.general 4.0.0 is released (https://github.com/ansible-collections/community.general/pull/2697). -- The nios, nios_next_ip, nios_next_network lookup plugins, the nios documentation fragment, and the nios_host_record, nios_ptr_record, nios_mx_record, nios_fixed_address, nios_zone, nios_member, nios_a_record, nios_aaaa_record, nios_network, nios_dns_view, nios_txt_record, nios_naptr_record, nios_srv_record, nios_cname_record, nios_nsgroup, and nios_network_view module have been deprecated and will be removed from community.general 5.0.0. Please install the `infoblox.nios_modules `_ collection instead and use its plugins and modules (https://github.com/ansible-collections/community.general/pull/2458). -- The vendored copy of ``ipaddress`` will be removed in community.general 4.0.0. Please switch to ``ipaddress`` from the Python 3 standard library, or `from pypi `_, if your code relies on the vendored version of ``ipaddress`` (https://github.com/ansible-collections/community.general/pull/2459). -- linode - parameter ``backupsenabled`` is deprecated and will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2410). -- lxd inventory plugin - the plugin will require ``ipaddress`` installed when used with Python 2 from community.general 4.0.0 on. ``ipaddress`` is part of the Python 3 standard library, but can be installed for Python 2 from pypi (https://github.com/ansible-collections/community.general/pull/2459). -- scaleway_security_group_rule - the module will require ``ipaddress`` installed when used with Python 2 from community.general 4.0.0 on. ``ipaddress`` is part of the Python 3 standard library, but can be installed for Python 2 from pypi (https://github.com/ansible-collections/community.general/pull/2459). - -inspur.sm -~~~~~~~~~ - -- add_ad_group - This feature will be removed in inspur.sm.add_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- add_ldap_group - This feature will be removed in inspur.sm.add_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- add_user - This feature will be removed in inspur.sm.add_user 3.0.0. replaced with inspur.sm.user. -- add_user_group - This feature will be removed in inspur.sm.add_user_group 3.0.0. replaced with inspur.sm.user_group. -- del_ad_group - This feature will be removed in inspur.sm.del_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- del_ldap_group - This feature will be removed in inspur.sm.del_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- del_user - This feature will be removed in inspur.sm.del_user 3.0.0. replaced with inspur.sm.user. -- del_user_group - This feature will be removed in inspur.sm.del_user_group 3.0.0. replaced with inspur.sm.user_group. -- edit_ad_group - This feature will be removed in inspur.sm.edit_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- edit_ldap_group - This feature will be removed in inspur.sm.edit_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- edit_user - This feature will be removed in inspur.sm.edit_user 3.0.0. replaced with inspur.sm.user. -- edit_user_group - This feature will be removed in inspur.sm.edit_user_group 3.0.0. replaced with inspur.sm.user_group. - -Porting Guide for v4.0.0 -======================== - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - The ``pylint`` sanity test no longer correctly detects "bad" variable names for non-constants. See `issue 3701 `_ for additional details. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_configuration_compliance_info - Issue(195592) Module may error out with the message ``unable to process the request because an error occurred``. If the issue persists, report it to the system administrator. -- ome_smart_fabric - Issue(185322) Only three design types are supported by OpenManage Enterprise Modular but the module successfully creates a fabric when the design type is not supported. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Modules for monitor API are not versioned yet. - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Made SCM collections be reinstalled regardless of ``--force`` being present. -- NetBSD virtualization facts (specifically ``ansible_virtualization_type``) now returns a more accurate value by checking the value of the ``machdep.hypervisor`` ``sysctl`` key. This change is breaking because in some cases previously, we would erroneously report ``xen`` even when the target is not running on Xen. This prevents that behavior in most cases. (https://github.com/ansible/ansible/issues/69352) -- Replaced the in-tree dependency resolver with an external implementation that pip >= 20.3 uses now by default — ``resolvelib``. (https://github.com/ansible/ansible/issues/71784) -- The ``meta`` module now supports tags for user-defined tasks. Internal ``meta`` tasks continue to always run. (https://github.com/ansible/ansible/issues/64558) -- ansible-galaxy login command has been removed (see `issue 71560 `_) - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Removed vendored ipaddress package from collection. If you use ansible_collections.ansible.netcommon.plugins.module_utils.compat.ipaddress in your collection, you will need to change this to import ipaddress instead. If your content using ipaddress supports Python 2.7, you will additionally need to make sure that the user has the ipaddress package installed. Please refer to https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#importing-and-using-shared-code to see how to safely import external packages that may be missing from the user's system A backport of ipaddress for Python 2.7 is available at https://pypi.org/project/ipaddress/ - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_swarm - if ``join_token`` is specified, a returned join token with the same value will be replaced by ``VALUE_SPECIFIED_IN_NO_LOG_PARAMETER``. Make sure that you do not blindly use the join tokens from the return value of this module when the module is invoked with ``join_token`` specified! This breaking change appears in a minor release since it is necessary to fix a security issue (https://github.com/ansible-collections/community.docker/pull/103). - -community.general -~~~~~~~~~~~~~~~~~ - -- If you use Ansible 2.9 and these plugins or modules from this collection, community.general 3.0.0 results in errors when trying to use the DellEMC content by FQCN, like ``community.general.idrac_firmware``. - Since Ansible 2.9 is not able to use redirections, you will have to adjust your playbooks and roles manually to use the new FQCNs (``dellemc.openmanage.idrac_firmware`` for the previous example) and to make sure that you have ``dellemc.openmanage`` installed. - - If you use ansible-base 2.10 or newer and did not install Ansible 4.0.0, but installed (and/or upgraded) community.general manually, you need to make sure to also install the ``dellemc.openmanage`` collection if you are using any of these plugins or modules. - While ansible-base 2.10 or newer can use the redirects that community.general 3.0.0 adds, the collection they point to (such as dellemc.openmanage) must be installed for them to work. -- gitlab_deploy_key - if for an already existing key title a different public key was given as parameter nothing happened, now this changed so that the public key is updated to the new value (https://github.com/ansible-collections/community.general/pull/1661). -- java_keystore - instead of failing, now overwrites keystore if the alias (name) is changed. This was originally the intended behavior, but did not work due to a logic error. Make sure that your playbooks and roles do not depend on the old behavior of failing instead of overwriting (https://github.com/ansible-collections/community.general/issues/1671). -- java_keystore - instead of failing, now overwrites keystore if the passphrase is changed. Make sure that your playbooks and roles do not depend on the old behavior of failing instead of overwriting (https://github.com/ansible-collections/community.general/issues/1671). -- one_image - use pyone instead of python-oca (https://github.com/ansible-collections/community.general/pull/2032). -- utm_proxy_auth_profile - the ``frontend_cookie_secret`` return value now contains a placeholder string instead of the module's ``frontend_cookie_secret`` parameter (https://github.com/ansible-collections/community.general/pull/1736). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Generic FortiOS Module - FOS module to issue generic request with Ansible. -- Support for FOS Monitor API - several modules are new for monitor API. -- Unified Collection - The fortios collection itself will be adapting any FOS platforms. - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- auth field now required for anything other than Basic authentication - -theforeman.foreman -~~~~~~~~~~~~~~~~~~ - -- All role variables are now prefixed with ``foreman_`` to avoid clashes with similarly named variables from roles outside this collection. - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- A collection can be reinstalled with new version requirements without using the ``--force`` flag. The collection's dependencies will also be updated if necessary with the new requirements. Use ``--upgrade`` to force transitive dependency updates. -- AnsibleModule - use ``ArgumentSpecValidator`` class for validating argument spec and remove private methods related to argument spec validation. Any modules using private methods should now use the ``ArgumentSpecValidator`` class or the appropriate validation function. -- Declared ``resolvelib >= 0.5.3, < 0.6.0`` a direct dependency of - ansible-core. Refs: - - https://github.com/sarugaku/resolvelib - - https://pypi.org/p/resolvelib - - https://pradyunsg.me/blog/2020/03/27/pip-resolver-testing -- It became possible to install Ansible Collections from local folders and namespaces folder similar to SCM structure with multiple collections. -- It became possible to upgrade Ansible collections from Galaxy servers using the ``--upgrade`` option with ``ansible-galaxy collection install``. -- Support for role argument specification validation at role execution time. When a role contains an argument spec, an implicit validation task is inserted at the start of role execution. -- add ``ArgumentSpecValidator`` class for validating parameters against an argument spec outside of ``AnsibleModule`` (https://github.com/ansible/ansible/pull/73335) -- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Remove deprecated connection arguments from netconf_config - -arista.eos -~~~~~~~~~~ - -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules` - Please refer to ansible.netcommon `changelog `_ for more details. - -cisco.asa -~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog ` for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -cisco.ios -~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -cisco.iosxr -~~~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. -- ipaddress is no longer in ansible.netcommon. For Python versions without ipaddress (< 3.0), the ipaddress package is now required. - -cisco.nxos -~~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -community.grafana -~~~~~~~~~~~~~~~~~ - -- introduce "skip_version_check" parameter in grafana_teams and grafana_folder modules (#147) - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_replication - add deprecation warning that the ``Is_Slave`` and ``Is_Master`` return values will be replaced with ``Is_Primary`` and ``Is_Replica`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/147). -- mysql_replication - the choices of the ``state`` option containing ``master`` will be finally replaced with the alternative ``primary`` choices in ``community.mysql`` 3.0.0, add deprecation warnings (https://github.com/ansible-collections/community.mysql/pull/150). -- mysql_replication - the mode options values ``getslave``, ``startslave``, ``stopslave``, ``resetslave``, ``resetslaveall` and the master_use_gtid option ``slave_pos`` are deprecated (see the alternative values) and will be removed in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/pull/97). -- mysql_replication - the return value ``Is_Slave`` and ``Is_Master`` will be replaced with ``Is_Replica`` and ``Is_Primary`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/145). -- mysql_replication - the word ``SLAVE`` in messages returned by the module will be changed to ``REPLICA`` in ``community.mysql`` 2.0.0 (https://github.com/ansible-collections/community.mysql/issues/98). -- mysql_replication - the word ``master`` in messages returned by the module will be replaced with ``primary`` in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/145). -- mysql_replication - the word ``slave`` in messages returned by the module replaced with ``replica`` (https://github.com/ansible-collections/community.mysql/issues/98). -- mysql_user - the ``REQUIRESSL`` is an alias for the ``ssl`` key in the ``tls_requires`` option in ``community.mysql`` 2.0.0 and support will be dropped altogether in ``community.mysql`` 3.0.0 (https://github.com/ansible-collections/community.mysql/issues/121). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- New module fortios_configuration_fact -- New module fortios_json_generic -- New module fortios_monitor -- New module fortios_monitor_fact - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules`. - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_autosupport - Added REST support to the module. - -openvswitch.openvswitch -~~~~~~~~~~~~~~~~~~~~~~~ - -- There is no major changes for this particular release and it was tagged by mistake and cannot be reverted. - -servicenow.servicenow -~~~~~~~~~~~~~~~~~~~~~ - -- refactored client to inherit from AnsibleModule -- supports OpenID Connect authentication protocol -- supports bearer tokens for authentication - -vyos.vyos -~~~~~~~~~ - -- Please refer to ansible.netcommon `changelog `_ for more details. -- Requires ansible.netcommon v2.0.0+ to support `ansible_network_single_user_mode` and `ansible_network_import_modules` -- ipaddress is no longer in ansible.netcommon. For Python versions without ipaddress (< 3.0), the ipaddress package is now required. - -Removed Features ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Removed `SharedPluginLoaderObj` class from ansible.plugins.strategy. It was deprecated in favor of using the standard plugin loader. -- Removed `_get_item()` alias from callback plugin base class which had been deprecated in favor of `_get_item_label()`. -- The "user" parameter was previously deprecated and is now removed in favor of "scope" -- The deprecated ``ansible.constants.BECOME_METHODS`` has been removed. -- The deprecated ``ansible.constants.get_config()`` has been removed. -- The deprecated ``ansible.constants.mk_boolean()`` has been removed. -- `with_*` loops are no longer optimized for modules whose `name` parameters can take lists (mostly package managers). Use `name` instead of looping over individual names with `with_items` and friends. - -community.general -~~~~~~~~~~~~~~~~~ - -- The ``ome_device_info``, ``idrac_firmware`` and ``idrac_server_config_profile`` modules have now been migrated from community.general to the `dellemc.openmanage `_ Ansible collection. - If you use ansible-base 2.10 or newer, redirections have been provided. - - If you use Ansible 2.9 and installed this collection, you need to adjust the FQCNs (``community.general.idrac_firmware`` → ``dellemc.openmanage.idrac_firmware``) and make sure to install the dellemc.openmanage collection. -- The deprecated ali_instance_facts module has been removed. Use ali_instance_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated gluster_heal_info module has been removed. Use gluster.gluster.gluster_heal_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated gluster_peer module has been removed. Use gluster.gluster.gluster_peer instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated gluster_volume module has been removed. Use gluster.gluster.gluster_volume instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated helm module has been removed. Use community.kubernetes.helm instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated hpilo_facts module has been removed. Use hpilo_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated idrac_redfish_facts module has been removed. Use idrac_redfish_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated jenkins_job_facts module has been removed. Use jenkins_job_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ldap_attr module has been removed. Use ldap_attrs instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated memset_memstore_facts module has been removed. Use memset_memstore_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated memset_server_facts module has been removed. Use memset_server_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated na_ontap_gather_facts module has been removed. Use netapp.ontap.na_ontap_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated nginx_status_facts module has been removed. Use nginx_status_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated one_image_facts module has been removed. Use one_image_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated onepassword_facts module has been removed. Use onepassword_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_datacenter_facts module has been removed. Use oneview_datacenter_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_enclosure_facts module has been removed. Use oneview_enclosure_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_ethernet_network_facts module has been removed. Use oneview_ethernet_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_fc_network_facts module has been removed. Use oneview_fc_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_fcoe_network_facts module has been removed. Use oneview_fcoe_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_logical_interconnect_group_facts module has been removed. Use oneview_logical_interconnect_group_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_network_set_facts module has been removed. Use oneview_network_set_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated oneview_san_manager_facts module has been removed. Use oneview_san_manager_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated online_server_facts module has been removed. Use online_server_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated online_user_facts module has been removed. Use online_user_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt module has been removed. Use ovirt.ovirt.ovirt_vm instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_affinity_label_facts module has been removed. Use ovirt.ovirt.ovirt_affinity_label_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_api_facts module has been removed. Use ovirt.ovirt.ovirt_api_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_cluster_facts module has been removed. Use ovirt.ovirt.ovirt_cluster_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_datacenter_facts module has been removed. Use ovirt.ovirt.ovirt_datacenter_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_disk_facts module has been removed. Use ovirt.ovirt.ovirt_disk_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_event_facts module has been removed. Use ovirt.ovirt.ovirt_event_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_external_provider_facts module has been removed. Use ovirt.ovirt.ovirt_external_provider_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_group_facts module has been removed. Use ovirt.ovirt.ovirt_group_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_host_facts module has been removed. Use ovirt.ovirt.ovirt_host_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_host_storage_facts module has been removed. Use ovirt.ovirt.ovirt_host_storage_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_network_facts module has been removed. Use ovirt.ovirt.ovirt_network_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_nic_facts module has been removed. Use ovirt.ovirt.ovirt_nic_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_permission_facts module has been removed. Use ovirt.ovirt.ovirt_permission_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_quota_facts module has been removed. Use ovirt.ovirt.ovirt_quota_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_scheduling_policy_facts module has been removed. Use ovirt.ovirt.ovirt_scheduling_policy_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_snapshot_facts module has been removed. Use ovirt.ovirt.ovirt_snapshot_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_storage_domain_facts module has been removed. Use ovirt.ovirt.ovirt_storage_domain_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_storage_template_facts module has been removed. Use ovirt.ovirt.ovirt_storage_template_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_storage_vm_facts module has been removed. Use ovirt.ovirt.ovirt_storage_vm_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_tag_facts module has been removed. Use ovirt.ovirt.ovirt_tag_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_template_facts module has been removed. Use ovirt.ovirt.ovirt_template_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_user_facts module has been removed. Use ovirt.ovirt.ovirt_user_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_vm_facts module has been removed. Use ovirt.ovirt.ovirt_vm_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated ovirt_vmpool_facts module has been removed. Use ovirt.ovirt.ovirt_vmpool_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated purefa_facts module has been removed. Use purestorage.flasharray.purefa_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated purefb_facts module has been removed. Use purestorage.flasharray.purefb_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated python_requirements_facts module has been removed. Use python_requirements_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated redfish_facts module has been removed. Use redfish_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_image_facts module has been removed. Use scaleway_image_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_ip_facts module has been removed. Use scaleway_ip_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_organization_facts module has been removed. Use scaleway_organization_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_security_group_facts module has been removed. Use scaleway_security_group_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_server_facts module has been removed. Use scaleway_server_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_snapshot_facts module has been removed. Use scaleway_snapshot_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated scaleway_volume_facts module has been removed. Use scaleway_volume_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated smartos_image_facts module has been removed. Use smartos_image_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated vertica_facts module has been removed. Use vertica_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The deprecated xenserver_guest_facts module has been removed. Use xenserver_guest_info instead (https://github.com/ansible-collections/community.general/pull/1924). -- The ovirt_facts docs fragment has been removed (https://github.com/ansible-collections/community.general/pull/1924). -- airbrake_deployment - removed deprecated ``token`` parameter. Use ``project_id`` and ``project_key`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- bigpanda - the alias ``message`` has been removed. Use ``deployment_message`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- cisco_spark, cisco_webex - the alias ``message`` has been removed. Use ``msg`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- clc_aa_policy - the ``wait`` parameter has been removed. It did not have any effect (https://github.com/ansible-collections/community.general/pull/1926). -- datadog_monitor - the alias ``message`` has been removed. Use ``notification_message`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- django_manage - the parameter ``liveserver`` has been removed (https://github.com/ansible-collections/community.general/pull/1926). -- idrac_redfish_config - the parameters ``manager_attribute_name`` and ``manager_attribute_value`` have been removed. Use ``manager_attributes`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- iso_extract - the alias ``thirsty`` has been removed. Use ``force`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- ldap_entry - the ``params`` parameter is now completely removed. Using it already triggered an error since community.general 0.1.2 (https://github.com/ansible-collections/community.general/pull/2257). -- pulp_repo - the ``feed_client_cert`` parameter no longer defaults to the value of the ``client_cert`` parameter (https://github.com/ansible-collections/community.general/pull/1926). -- pulp_repo - the ``feed_client_key`` parameter no longer defaults to the value of the ``client_key`` parameter (https://github.com/ansible-collections/community.general/pull/1926). -- pulp_repo - the alias ``ca_cert`` has been removed. Use ``feed_ca_cert`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- rax - unused parameter ``service`` removed (https://github.com/ansible-collections/community.general/pull/2020). -- redfish modules - issuing a data modification command without specifying the ID of the target System, Chassis or Manager resource when there is more than one is no longer allowed. Use the ``resource_id`` option to specify the target ID (https://github.com/ansible-collections/community.general/pull/1926). -- redfish_config - the parameters ``bios_attribute_name`` and ``bios_attribute_value`` have been removed. Use ``bios_attributes`` instead (https://github.com/ansible-collections/community.general/pull/1926). -- syspatch - the ``apply`` parameter has been removed. This is the default mode, so simply removing it will not change the behavior (https://github.com/ansible-collections/community.general/pull/1926). -- xbps - the ``force`` parameter has been removed. It did not have any effect (https://github.com/ansible-collections/community.general/pull/1926). - -community.network -~~~~~~~~~~~~~~~~~ - -- The deprecated ``community.network.ce_sflow`` parameters: ``rate_limit``, ``rate_limit_slot``, and ``forward_enp_slot`` have been removed (https://github.com/ansible-collections/community.network/pull/255). -- The deprecated ``community.network.sros`` netconf plugin has been removed. Use ``nokia.sros.md`` instead (https://github.com/ansible-collections/community.network/pull/255). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Removed TMOS v11 support for bigip_gtm_pool and bigip_gtm_wide_ip modules -- Removed quorum and monitor_type parameters in bigip_node module. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html -- Removed syslog_settings and pool_settings parameters in bigip_log_destination moduke. See porting guides section at https://clouddocs.f5.com/products/orchestration/ansible/devel/usage/porting-guides.html - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Removed module fortios_facts -- Removed module fortios_registration_forticare -- Removed module fortios_registration_vdom -- Removed module fortios_system_config_backup_restore -- Removed module fortios_system_vmlicense - -Deprecated Features -------------------- - -Ansible-core -~~~~~~~~~~~~ - -- Starting in 2.14, shell and command modules will no longer have the option to warn and suggest modules in lieu of commands. The ``warn`` parameter to these modules is now deprecated and defaults to ``False``. Similarly, the ``COMMAND_WARNINGS`` configuration option is also deprecated and defaults to ``False``. These will be removed and their presence will become an error in 2.14. -- apt_key - the parameter ``key`` does not have any effect, has been deprecated and will be removed in ansible-core version 2.14 (https://github.com/ansible/ansible/pull/70319). -- psrp - Set the minimum version of ``pypsrp`` to ``0.4.0``. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- Deprecate cli_parse module and textfsm, ttp, xml, json parser plugins as they are moved to ansible.utils collection (https://github.com/ansible-collections/ansible.netcommon/pull/182 https://github.com/ansible-collections/ansible.utils/pull/28) - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_bgp_af in favour of nxos_bgp_address_family resource module. -- Deprecated nxos_bgp_neighbor_af in favour of nxos_bgp_neighbor_address_family resource module. - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- The aliases ``server_uuids`` and ``server_uuid`` of the servers parameter in the volume module will be removed in version 3.0.0. - -community.aws -~~~~~~~~~~~~~ - -- ec2_eip - formally deprecate the ``instance_id`` alias for ``device_id`` (https://github.com/ansible-collections/community.aws/pull/349). -- ec2_vpc_endpoint - deprecate the policy_file option and recommend using policy with a lookup (https://github.com/ansible-collections/community.aws/pull/366). -- ec2_vpc_endpoint_info - the ``query`` option has been deprecated and will be removed after 2022-12-01 (https://github.com/ansible-collections/community.aws/pull/346). The ec2_vpc_endpoint_info now defaults to listing information about endpoints. The ability to search for information about available services has been moved to the dedicated module ``ec2_vpc_endpoint_service_info``. - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme module_utils - the ``acme`` module_utils (``ansible_collections.community.crypto.plugins.module_utils.acme``) is deprecated and will be removed in community.crypto 2.0.0. Use the new Python modules in the ``acme`` package instead (``ansible_collections.community.crypto.plugins.module_utils.acme.xxx``) (https://github.com/ansible-collections/community.crypto/pull/184). -- acme_account_info - when ``retrieve_orders=url_list``, ``orders`` will no longer be returned in community.crypto 2.0.0. Use ``order_uris`` instead (https://github.com/ansible-collections/community.crypto/pull/178). - -community.general -~~~~~~~~~~~~~~~~~ - -- apt_rpm - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- composer - deprecated invalid parameter aliases ``working-dir``, ``global-command``, ``prefer-source``, ``prefer-dist``, ``no-dev``, ``no-scripts``, ``no-plugins``, ``optimize-autoloader``, ``classmap-authoritative``, ``apcu-autoloader``, ``ignore-platform-reqs``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- cpanm - parameter ``system_lib`` deprecated in favor of using ``become`` (https://github.com/ansible-collections/community.general/pull/2218). -- github_deploy_key - deprecated invalid parameter alias ``2fa_token``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- grove - the option ``message`` will be removed in community.general 4.0.0. Use the new option ``message_content`` instead (https://github.com/ansible-collections/community.general/pull/1929). -- homebrew - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- homebrew_cask - deprecated invalid parameter alias ``update-brew``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- opkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- pacman - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- puppet - deprecated undocumented parameter ``show_diff``, will be removed in 7.0.0. (https://github.com/ansible-collections/community.general/pull/1927). -- runit - unused parameter ``dist`` marked for deprecation (https://github.com/ansible-collections/community.general/pull/1830). -- slackpkg - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- urpmi - deprecated invalid parameter aliases ``update-cache`` and ``no-recommends``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xbps - deprecated invalid parameter alias ``update-cache``, will be removed in 5.0.0 (https://github.com/ansible-collections/community.general/pull/1927). -- xfconf - returning output as facts is deprecated, this will be removed in community.general 4.0.0. Please register the task output in a variable and use it instead. You can already switch to the new behavior now by using the new ``disable_facts`` option (https://github.com/ansible-collections/community.general/pull/1747). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_vmkernel_ip_config - deprecate in favor of vmware_vmkernel (https://github.com/ansible-collections/community.vmware/pull/667). - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Python versions earlier than 3.5 is being deprecated diff --git a/docs/docsite/rst/porting_guides/porting_guide_5.rst b/docs/docsite/rst/porting_guides/porting_guide_5.rst deleted file mode 100644 index 7afc11e2112..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_5.rst +++ /dev/null @@ -1,1031 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.12.rst) - -.. _porting_5_guide: - -======================= -Ansible 5 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 5 is based on Ansible-core 2.12. - - -We suggest you read this page along with the `Ansible 5 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -* When calling tasks and setting ``async``, setting ``ANSIBLE_ASYNC_DIR`` under ``environment:`` is no longer valid. Instead, use the shell configuration variable ``async_dir``, for example by setting ``ansible_async_dir``: - -.. code-block:: yaml - - tasks: - - dnf: - name: '*' - state: latest - async: 300 - poll: 5 - vars: - ansible_async_dir: /path/to/my/custom/dir - -* The ``undef()`` function is added to the templating environment for creating undefined variables directly in a template. Optionally, a hint may be provided for variables which are intended to be overridden. - -.. code-block:: yaml - - vars: - old: "{{ undef }}" - new: "{{ undef() }}" - new_with_hint: "{{ undef(hint='You must override this variable') }}" - -Python Interpreter Discovery -============================ - -The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``. - -``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable. - -See :ref:`interpreter discovery documentation ` for more details. - - -Command Line -============ - -* Python 3.8 on the controller node is a hard requirement for this release. The command line scripts will not function with a lower Python version. -* ``ansible-vault`` no longer supports ``PyCrypto`` and requires ``cryptography``. - -Deprecated -========== - -* Python 2.6 on the target node is deprecated in this release. ``ansible-core`` 2.13 will remove support for Python 2.6. -* Bare variables in conditionals: ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any variable containing a non-empty string is considered true. This was previously configurable with the ``CONDITIONAL_BARE_VARS`` configuration option (and the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable). This setting no longer has any effect. Users can work around the issue by using the ``|bool`` filter: - -.. code-block:: yaml - - vars: - teardown: 'false' - - tasks: - - include_tasks: teardown.yml - when: teardown | bool - - - include_tasks: provision.yml - when: not teardown | bool - -* The ``_remote_checksum()`` method in ``ActionBase`` is deprecated. Any action plugin using this method should use ``_execute_remote_stat()`` instead. - -Modules -======= - -* ``cron`` now requires ``name`` to be specified in all cases. -* ``cron`` no longer allows a ``reboot`` parameter. Use ``special_time: reboot`` instead. -* ``hostname`` - On FreeBSD, the ``before`` result will no longer be ``"temporarystub"`` if permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``hostname`` - On OpenRC and Solaris based systems, the ``before`` result will no longer be ``"UNKNOWN"`` if the permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``pip`` now uses the ``pip`` Python module installed for the Ansible module's Python interpreter, if available, unless ``executable`` or ``virtualenv`` were specified. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -* ``unique`` filter with Jinja2 < 2.10 is case-sensitive and now raise coherently an error if ``case_sensitive=False`` instead of when ``case_sensitive=True``. -* Set theory filters (``intersect``, ``difference``, ``symmetric_difference`` and ``union``) are now case-sensitive. Explicitly use ``case_sensitive=False`` to keep previous behavior. Note: with Jinja2 < 2.10, the filters were already case-sensitive by default. -* ``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256``, now default to the "2b" format and if the "2a" format is required it must be specified. - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v5.9.0 -======================== - -Added Collections ------------------ - -- cisco.dnac (version 6.4.0) -- community.sap_libs (version 1.1.0) - -Major Changes -------------- - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5. - -Deprecated Features -------------------- - -- The collection ``community.sap`` has been renamed to ``community.sap_libs``. For now both collections are included in Ansible. The content in ``community.sap`` will be replaced with deprecated redirects to the new collection in Ansible 7.0.0, and these redirects will eventually be removed from Ansible. Please update your FQCNs for ``community.sap``. - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.docker/pull/361). -- The dependency on docker-compose for Execution Environments is deprecated and will be removed in community.docker 3.0.0. The `Python docker-compose library `__ is unmaintained and can cause dependency issues. You can manually still install it in an Execution Environment when needed (https://github.com/ansible-collections/community.docker/pull/373). -- Various modules - the default of ``tls_hostname`` that was supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). -- docker_stack - the return values ``out`` and ``err`` that were supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). - -Porting Guide for v5.8.0 -======================== - -Added Collections ------------------ - -- vmware.vmware_rest (version 2.1.5) - -Breaking Changes ----------------- - -vmware.vmware_rest -~~~~~~~~~~~~~~~~~~ - -- The vmware_rest 2.0.0 support vSphere 7.0.2 onwards. -- vcenter_vm_storage_policy - the format of the ``disks`` parameter has changed. -- vcenter_vm_storage_policy - the module has a new mandatory parameter: ``vm_home``. - -Major Changes -------------- - -community.mysql -~~~~~~~~~~~~~~~ - -- The community.mysql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.mysql/pull/343). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- The community.postgresql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.postgresql/pull/245). - -Deprecated Features -------------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- token_validate options - the shared auth option ``token_validate`` will change its default from ``True`` to ``False`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``True`` (https://github.com/ansible-collections/community.hashi_vault/issues/248). - -community.network -~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.network 4.0.0) this spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.network 3.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.network/pull/382). - -vmware.vmware_rest -~~~~~~~~~~~~~~~~~~ - -- vcenter_vm_storage_policy_compliance - drop the module, it returns 404 error. -- vcenter_vm_tools - remove the ``upgrade`` state. -- vcenter_vm_tools_installer - remove the module from the collection. - -Porting Guide for v5.7.0 -======================== - -Major Changes -------------- - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_user - the ``priv`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_privs`` module to grant/revoke privileges instead (https://github.com/ansible-collections/community.postgresql/issues/212). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- nmcli - deprecate default hairpin mode for a bridge. This so we can change it to ``false`` in community.general 7.0.0, as this is also the default in ``nmcli`` (https://github.com/ansible-collections/community.general/pull/4334). -- proxmox inventory plugin - the current default ``true`` of the ``want_proxmox_nodes_ansible_host`` option has been deprecated. The default will change to ``false`` in community.general 6.0.0. To keep the current behavior, explicitly set ``want_proxmox_nodes_ansible_host`` to ``true`` in your inventory configuration. We suggest to already switch to the new behavior by explicitly setting it to ``false``, and by using ``compose:`` to set ``ansible_host`` to the correct value. See the examples in the plugin documentation for details (https://github.com/ansible-collections/community.general/pull/4466). - -Porting Guide for v5.6.0 -======================== - -Added Collections ------------------ - -- community.sap (version 1.0.0) - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- Deprecates lldp module. - -Porting Guide for v5.5.0 -======================== - -Known Issues ------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- pacman - ``update_cache`` cannot differentiate between up to date and outdated package lists and will report ``changed`` in both situations (https://github.com/ansible-collections/community.general/pull/4318). -- pacman - binaries specified in the ``executable`` parameter must support ``--print-format`` in order to be used by this module. In particular, AUR helper ``yay`` is known not to currently support it (https://github.com/ansible-collections/community.general/pull/4312). - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- pacman - from community.general 5.0.0 on, the ``changed`` status of ``update_cache`` will no longer be ignored if ``name`` or ``upgrade`` is specified. To keep the old behavior, add something like ``register: result`` and ``changed_when: result.packages | length > 0`` to your task (https://github.com/ansible-collections/community.general/pull/4329). - -Porting Guide for v5.4.0 -======================== - -Major Changes -------------- - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added choco_args option to pass additional arguments directly to Chocolatey. - -vyos.vyos -~~~~~~~~~ - -- Add 'pool' as value to server key in ntp_global. - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- `ios_acls` - Deprecated fragment attribute added boolean alternate as enable_fragment. - -Porting Guide for v5.3.0 -======================== - -Major Changes -------------- - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- bigip_device_info - pagination logic has also been added to help with api stability. -- bigip_device_info - the module no longer gathers information from all partitions on device. This change will stabalize the module by gathering resources only from the given partition and prevent the module from gathering way too much information that might result in crashing. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140). - -Porting Guide for v5.2.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_admin - Once `max_login` and `lockout` have been set there is currently no way to rest these to zero except through the FlashArray GUI - -Major Changes -------------- - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_radio - New module - -Deprecated Features -------------------- - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_sso - Deprecated in favor of M(purefa_admin). Will be removed in Collection 2.0 - -Porting Guide for v5.1.0 -======================== - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add podman_tag module -- Add secrets driver and driver opts support - -Removed Features ----------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- the "legacy" integration test setup has been removed; this does not affect end users and is only relevant to contributors (https://github.com/ansible-collections/community.hashi_vault/pull/191). - -Deprecated Features -------------------- - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_snmp_community module. -- Deprecated nxos_snmp_contact module. -- Deprecated nxos_snmp_host module. -- Deprecated nxos_snmp_location module. -- Deprecated nxos_snmp_traps module. -- Deprecated nxos_snmp_user module. - -community.general -~~~~~~~~~~~~~~~~~ - -- module_helper module utils - deprecated the attribute ``ModuleHelper.VarDict`` (https://github.com/ansible-collections/community.general/pull/3801). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.hashi_vault 3.0.0) next spring (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.hashi_vault/issues/189). -- aws_iam_login auth method - the ``aws_iam_login`` method has been renamed to ``aws_iam``. The old name will be removed in collection version ``3.0.0``. Until then both names will work, and a warning will be displayed when using the old name (https://github.com/ansible-collections/community.hashi_vault/pull/193). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module. - -Porting Guide for v5.0.1 -======================== - -Major Changes -------------- - -- Raised python requirement of the ansible package from >=2.7 to >=3.8 to match ansible-core - -Porting Guide for v5.0.0 -======================== - -Added Collections ------------------ - -- cisco.ise (version 1.2.1) -- cloud.common (version 2.1.0) -- community.ciscosmb (version 1.0.4) -- community.dns (version 2.0.3) -- infoblox.nios_modules (version 1.1.2) -- netapp.storagegrid (version 21.7.0) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Tab completion anywhere other than the end of the command with the new composite options will provide incorrect results. See `issue 351 `_ for additional details. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) Module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_device_power_settings - Issue(212679) The ome_device_power_settings module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. -- ome_smart_fabric_uplink - Issue(186024) ome_smart_fabric_uplink module does not allow the creation of multiple uplinks of the same name even though this is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -purestorage.flashblade -~~~~~~~~~~~~~~~~~~~~~~ - -- purefb_lag - The mac_address field in the response is not populated. This will be fixed in a future FlashBlade update. - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Action, module, and group names in module_defaults must be static values. Their values can still be templates. -- Fully qualified 'ansible.legacy' plugin names are not included implicitly in action_groups. -- Unresolvable groups, action plugins, and modules in module_defaults are an error. -- ansible-test - Automatic installation of requirements for "cloud" test plugins no longer occurs. The affected test plugins are ``aws``, ``azure``, ``cs``, ``hcloud``, ``nios``, ``opennebula``, ``openshift`` and ``vcenter``. Collections should instead use one of the supported integration test requirements files, such as the ``tests/integration/requirements.txt`` file. -- ansible-test - The HTTP Tester is no longer available with the ``ansible-test shell`` command. Only the ``integration`` and ``windows-integration`` commands provide HTTP Tester. -- ansible-test - The ``--disable-httptester`` option is no longer available. The HTTP Tester is no longer optional for tests that specify it. -- ansible-test - The ``--httptester`` option is no longer available. To override the container used for HTTP Tester tests, set the ``ANSIBLE_HTTP_TEST_CONTAINER`` environment variable instead. -- ansible-test - Unit tests for ``modules`` and ``module_utils`` are now limited to importing only ``ansible.module_utils`` from the ``ansible`` module. -- conditionals - ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any non-empty string is now considered true. The ``CONDITIONAL_BARE_VARS`` configuration variable no longer has any effect. -- hostname - Drops any remaining support for Python 2.4 by using ``with open()`` to simplify exception handling code which leaked file handles in several spots -- hostname - On FreeBSD, the string ``temporarystub`` no longer gets written to the hostname file in the get methods (and in check_mode). As a result, the default hostname will now appear as ``''`` (empty string) instead of ``temporarystub`` for consistency with other strategies. This means the ``before`` result will be different. -- hostname - On OpenRC systems and Solaris, the ``before`` value will now be ``''`` (empty string) if the permanent hostname file does not exist, for consistency with other strategies. -- intersect, difference, symmetric_difference, union filters - the default behavior is now to be case-sensitive (https://github.com/ansible/ansible/issues/74255) -- unique filter - the default behavior is now to fail if Jinja2's filter fails and explicit ``case_sensitive=False`` as the Ansible's fallback is case-sensitive (https://github.com/ansible/ansible/pull/74256) - -amazon.aws -~~~~~~~~~~ - -- ec2_instance - instance wait for state behaviour has changed. If plays require the old behavior of waiting for the instance monitoring status to become ``OK`` when launching a new instance, the action will need to specify ``state: started`` (https://github.com/ansible-collections/amazon.aws/pull/481). -- ec2_snapshot - support for waiting indefinitely has been dropped, new default is 10 minutes (https://github.com/ansible-collections/amazon.aws/pull/356). -- ec2_vol_info - return ``attachment_set`` is now a list of attachments with Multi-Attach support on disk. (https://github.com/ansible-collections/amazon.aws/pull/362). -- ec2_vpc_dhcp_option - The module has been refactored to use boto3. Keys and value types returned by the module are now consistent, which is a change from the previous behaviour. A ``purge_tags`` option has been added, which defaults to ``True``. (https://github.com/ansible-collections/amazon.aws/pull/252) -- ec2_vpc_dhcp_option_info - Now preserves case for tag keys in return value. (https://github.com/ansible-collections/amazon.aws/pull/252) -- module_utils.core - The boto3 switch has been removed from the region parameter (https://github.com/ansible-collections/amazon.aws/pull/287). -- module_utils/compat - vendored copy of ipaddress removed (https://github.com/ansible-collections/amazon.aws/pull/461). -- module_utils/core - updated the ``scrub_none_parameters`` function so that ``descend_into_lists`` is set to ``True`` by default (https://github.com/ansible-collections/amazon.aws/pull/297). - -arista.eos -~~~~~~~~~~ - -- Arista released train 4.23.X and newer and along with it replaced and deprecated lots of commands. This PR adds support for syntax changes in release train 4.23 and after. Going forward the eos modules will not support eos sw version < 4.23. - -community.aws -~~~~~~~~~~~~~ - -- ec2_instance - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``. -- ec2_instance_info - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``. -- ec2_vpc_endpoint - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint``. -- ec2_vpc_endpoint_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_service_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_service_info``. -- ec2_vpc_igw - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw``. -- ec2_vpc_igw_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``. -- ec2_vpc_igw_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``. -- ec2_vpc_nat_gateway - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway``. -- ec2_vpc_nat_gateway_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- ec2_vpc_nat_gateway_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- kms_info - key details are now returned in the ``kms_keys`` attribute rather than the ``keys`` attribute (https://github.com/ansible-collections/community.aws/pull/648). - -community.crypto -~~~~~~~~~~~~~~~~ - -- Adjust ``dirName`` text parsing and to text converting code to conform to `Sections 2 and 3 of RFC 4514 `_. This is similar to how `cryptography handles this `_ (https://github.com/ansible-collections/community.crypto/pull/274). -- acme module utils - removing compatibility code (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_* modules - removed vendored copy of the Python library ``ipaddress``. If you are using Python 2.x, please make sure to install the library (https://github.com/ansible-collections/community.crypto/pull/287). -- compatibility module_utils - removed vendored copy of the Python library ``ipaddress`` (https://github.com/ansible-collections/community.crypto/pull/287). -- crypto module utils - removing compatibility code (https://github.com/ansible-collections/community.crypto/pull/290). -- get_certificate, openssl_csr_info, x509_certificate_info - depending on the ``cryptography`` version used, the modules might not return the ASN.1 value for an extension as contained in the certificate respectively CSR, but a re-encoded version of it. This should usually be identical to the value contained in the source file, unless the value was malformed. For extensions not handled by C(cryptography) the value contained in the source file is always returned unaltered (https://github.com/ansible-collections/community.crypto/pull/318). -- module_utils - removed various PyOpenSSL support functions and default backend values that are not needed for the openssl_pkcs12 module (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_csr, openssl_csr_pipe, x509_crl - the ``subject`` respectively ``issuer`` fields no longer ignore empty values, but instead fail when encountering them (https://github.com/ansible-collections/community.crypto/pull/316). -- openssl_privatekey_info - by default consistency checks are not run; they need to be explicitly requested by passing ``check_consistency=true`` (https://github.com/ansible-collections/community.crypto/pull/309). -- x509_crl - for idempotency checks, the ``issuer`` order is ignored. If order is important, use the new ``issuer_ordered`` option (https://github.com/ansible-collections/community.crypto/pull/316). - -community.dns -~~~~~~~~~~~~~ - -- All Hetzner modules and plugins which handle DNS records now work with unquoted TXT values by default. The old behavior can be obtained by setting ``txt_transformation=api`` (https://github.com/ansible-collections/community.dns/issues/48, https://github.com/ansible-collections/community.dns/pull/57, https://github.com/ansible-collections/community.dns/pull/60). -- Hosttech API creation - now requires a ``ModuleOptionProvider`` object instead of an ``AnsibleModule`` object. Alternatively an Ansible plugin instance can be passed (https://github.com/ansible-collections/community.dns/pull/37). -- The hetzner_dns_record_info and hosttech_dns_record_info modules have been renamed to hetzner_dns_record_set_info and hosttech_dns_record_set_info, respectively (https://github.com/ansible-collections/community.dns/pull/54). -- The hosttech_dns_record module has been renamed to hosttech_dns_record_set (https://github.com/ansible-collections/community.dns/pull/31). -- The internal bulk record updating helper (``bulk_apply_changes``) now also returns the records that were deleted, created or updated (https://github.com/ansible-collections/community.dns/pull/63). -- The internal record API no longer allows to manage comments explicitly (https://github.com/ansible-collections/community.dns/pull/63). -- When using the internal modules API, now a zone ID type and a provider information object must be passed (https://github.com/ansible-collections/community.dns/pull/27). -- hetzner_dns_record* modules - implement correct handling of default TTL. The value ``none`` is now accepted and returned in this case (https://github.com/ansible-collections/community.dns/pull/52, https://github.com/ansible-collections/community.dns/issues/50). -- hetzner_dns_record, hetzner_dns_record_set, hetzner_dns_record_sets - the default TTL is now 300 and no longer 3600, which equals the default in the web console (https://github.com/ansible-collections/community.dns/pull/43). -- hosttech_* module_utils - completely rewrite and refactor to support new JSON API and allow to re-use provider-independent module logic (https://github.com/ansible-collections/community.dns/pull/4). -- hosttech_dns_record_set - the option ``overwrite`` was replaced by a new option ``on_existing``. Specifying ``overwrite=true`` is equivalent to ``on_existing=replace`` (the new default). Specifying ``overwrite=false`` with ``state=present`` is equivalent to ``on_existing=keep_and_fail``, and specifying ``overwrite=false`` with ``state=absent`` is equivalent to ``on_existing=keep`` (https://github.com/ansible-collections/community.dns/pull/31). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_compose - fixed ``timeout`` defaulting behavior so that ``stop_grace_period``, if defined in the compose file, will be used if `timeout`` is not specified (https://github.com/ansible-collections/community.docker/pull/163). - -community.general -~~~~~~~~~~~~~~~~~ - -- archive - adding idempotency checks for changes to file names and content within the ``destination`` file (https://github.com/ansible-collections/community.general/pull/3075). -- lxd inventory plugin - when used with Python 2, the plugin now needs ``ipaddress`` installed `from pypi `_ (https://github.com/ansible-collections/community.general/pull/2441). -- scaleway_security_group_rule - when used with Python 2, the module now needs ``ipaddress`` installed `from pypi `_ (https://github.com/ansible-collections/community.general/pull/2441). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- connection options - there is no longer a default value for the ``url`` option (the Vault address), so a value must be supplied (https://github.com/ansible-collections/community.hashi_vault/issues/83). - -community.okd -~~~~~~~~~~~~~ - -- drop python 2 support (https://github.com/openshift/community.okd/pull/93). - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api - due to a programming error, the module never failed on errors. This has now been fixed. If you are relying on the module not failing in case of idempotent commands (resulting in errors like ``failure: already have such address``), you need to adjust your roles/playbooks. We suggest to use ``failed_when`` to accept failure in specific circumstances, for example ``failed_when: "'failure: already have ' in result.msg[0]"`` (https://github.com/ansible-collections/community.routeros/pull/39). -- api - splitting commands no longer uses a naive split by whitespace, but a more RouterOS CLI compatible splitting algorithm (https://github.com/ansible-collections/community.routeros/pull/45). -- command - the module now always indicates that a change happens. If this is not correct, please use ``changed_when`` to determine the correct changed status for a task (https://github.com/ansible-collections/community.routeros/pull/50). - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all roles now reference other roles and modules through their fully qualified collection names, which makes Ansible 2.10 minimum supported version for roles (See `issue 477 `_). - -kubernetes.core -~~~~~~~~~~~~~~~ - -- Drop python 2 support (https://github.com/ansible-collections/kubernetes.core/pull/86). -- helm_plugin - remove unused ``release_namespace`` parameter (https://github.com/ansible-collections/kubernetes.core/pull/85). -- helm_plugin_info - remove unused ``release_namespace`` parameter (https://github.com/ansible-collections/kubernetes.core/pull/85). -- k8s_cluster_info - returned apis as list to avoid being overwritten in case of multiple version (https://github.com/ansible-collections/kubernetes.core/pull/41). -- k8s_facts - remove the deprecated alias from k8s_facts to k8s_info (https://github.com/ansible-collections/kubernetes.core/pull/125). - -netapp.storagegrid -~~~~~~~~~~~~~~~~~~ - -- This version introduces a breaking change. - All modules have been renamed from ``nac_sg_*`` to ``na_sg_*``. - Playbooks and Roles must be updated to match. - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- Python Controller Requirement - Python 3.8 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/74013) -- ansible-test - All "cloud" plugins which use containers can now be used with all POSIX and Windows hosts. Previously the plugins did not work with Windows at all, and support for hosts created with the ``--remote`` option was inconsistent. -- ansible-test - Collections can now specify controller and target specific integration test requirements and constraints. If provided, they take precedence over the previously available requirements and constraints files. -- ansible-test - Integration tests run with the ``integration`` command can now be executed on two separate hosts instead of always running on the controller. The target host can be one provided by ``ansible-test`` or by the user, as long as it is accessible using SSH. -- ansible-test - Most container features are now supported under Podman. Previously a symbolic link for ``docker`` pointing to ``podman`` was required. -- ansible-test - New ``--controller`` and ``--target`` / ``--target-python`` options have been added to allow more control over test environments. -- ansible-test - Python 3.8 - 3.10 are now required to run ``ansible-test``, thus matching the Ansible controller Python requirements. Older Python versions (2.6 - 2.7 and 3.5 - 3.10) can still be the target for relevant tests. -- ansible-test - SSH port forwarding and redirection is now used exclusively to make container ports available on non-container hosts. When testing on POSIX systems this requires SSH login as root. Previously SSH port forwarding was combined with firewall rules or other port redirection methods, with some platforms being unsupported. -- ansible-test - Sanity tests always run in isolated Python virtual environments specific to the requirements of each test. The environments are cached. -- ansible-test - Sanity tests are now separated into two categories, controller and target. All tests except ``import`` and ``compile`` are controller tests. The controller tests always run using the same Python version used to run ``ansible-test``. The target tests use the Python version(s) specified by the user, or all available Python versions. -- ansible-test - Sanity tests now use fully pinned requirements that are independent of each other and other test types. -- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients. -- ansible-test - The ``future-import-boilerplate`` and ``metaclass-boilerplate`` sanity tests are limited to remote-only code. Additionally, they are skipped for collections which declare no support for Python 2.x. -- ansible-test - The ``import`` and ``compile`` sanity tests limit remote-only Python version checks to remote-only code. -- ansible-test - Unit tests for controller-only code now require Python 3.8 or later. -- ansible-test - Version neutral sanity tests now require Python 3.8 or later. -- junit callback - The ``junit_xml`` and ``ordereddict`` Python modules are no longer required to use the ``junit`` callback plugin. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - Due to the AWS SDKs announcing the end of support for Python less than 3.6 (https://boto3.amazonaws.com/v1/documentation/api/1.17.64/guide/migrationpy3.html) this collection now requires Python 3.6+ (https://github.com/ansible-collections/amazon.aws/pull/298). -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/502). -- ec2_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``. -- ec2_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``. -- ec2_vpc_endpoint - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint``. -- ec2_vpc_endpoint_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_info``. -- ec2_vpc_endpoint_service_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint_service_info``. -- ec2_vpc_igw - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw``. -- ec2_vpc_igw_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_facts``. -- ec2_vpc_igw_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_igw_info``. -- ec2_vpc_nat_gateway - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway``. -- ec2_vpc_nat_gateway_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- ec2_vpc_nat_gateway_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_nat_gateway_info``. -- ec2_vpc_route_table - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table``. -- ec2_vpc_route_table_facts - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_facts``. -- ec2_vpc_route_table_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_info``. - -cisco.ise -~~~~~~~~~ - -- Adds ``ise_uses_api_gateway`` to module options. -- Adds a 'aws_deployment' role that allows the deployment of an arbitrary large ISE cluster to AWS. -- Adds ise_responses to return values of info modules. -- Adds ise_update_response to return values of non-info modules. -- Fixes inner logic of modules that have no get by name and have not working filter. -- Renamed module device_administration_authorization_exception_rules to device_administration_local_exception_rules. -- Renamed module device_administration_authorization_global_exception_rules to device_administration_global_exception_rules. -- Renamed module network_access_authorization_exception_rules to network_access_local_exception_rules. -- Renamed module network_access_authorization_global_exception_rules to network_access_global_exception_rules. -- Updates options required for modules. -- Updates sdk parameters for previous modules -- device_administration_authorization_exception_rules - removed module. -- device_administration_authorization_exception_rules_info - removed module. -- device_administration_authorization_global_exception_rules - removed module. -- device_administration_authorization_global_exception_rules_info - removed module. -- guest_user_reinstante - removed module. -- import_trust_cert - removed module. -- network_access_authorization_exception_rules - removed module. -- network_access_authorization_exception_rules_info - removed module. -- network_access_authorization_global_exception_rules - removed module. -- network_access_authorization_global_exception_rules_info - removed module. -- personas_check_standalone - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- personas_export_certs - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- personas_promote_primary - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- personas_update_roles - Adds module for the deployment of personas to existing nodes in an ISE cluster. -- service_info - removed module. -- system_certificate_export - removed module. -- telemetry_info_info - removed module. - -cloud.common -~~~~~~~~~~~~ - -- turbo - enable turbo mode for lookup plugins - -cloudscale_ch.cloud -~~~~~~~~~~~~~~~~~~~ - -- Add custom_image module - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - The community.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0`` (https://github.com/ansible-collections/community.aws/pull/711). Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/442). - -community.ciscosmb -~~~~~~~~~~~~~~~~~~ - -- Python 2.6, 2.7, 3.5 is required -- add CBS350 support -- add antsibull-changelog support -- add ciscosmb_command -- added facts subset "interfaces" -- ciscosmb_facts with default subset and unit tests -- interface name canonicalization -- transform collection qaxi.ciscosmb to community.ciscosmb -- transform community.ciscosmb.ciscosmb_command to community.ciscosmb.command -- transform community.ciscosmb.ciscosmb_facts to community.ciscosmb.facts -- unit tests for CBS350 - -community.dns -~~~~~~~~~~~~~ - -- hosttech_* modules - support the new JSON API at https://api.ns1.hosttech.eu/api/documentation/ (https://github.com/ansible-collections/community.dns/pull/4). - -community.general -~~~~~~~~~~~~~~~~~ - -- bitbucket_* modules - ``client_id`` is no longer marked as ``no_log=true``. If you relied on its value not showing up in logs and output, please mark the whole tasks with ``no_log: true`` (https://github.com/ansible-collections/community.general/pull/2045). - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- redirect everything from ``community.kubernetes`` to ``kubernetes.core`` (https://github.com/ansible-collections/community.kubernetes/pull/425). - -community.okd -~~~~~~~~~~~~~ - -- update to use kubernetes.core 2.0 (https://github.com/openshift/community.okd/pull/93). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_query - the default value of the ``as_single_query`` option will be changed to ``yes`` in community.postgresql 2.0.0 (https://github.com/ansible-collections/community.postgresql/issues/85). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_object_custom_attributes_info - added a new module to gather custom attributes of an object (https://github.com/ansible-collections/community.vmware/pull/851). - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add systemd generation for pods -- Generate systemd service files for containers - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_server_config_profile - Added support for exporting and importing Server Configuration Profile through HTTP/HTTPS share. -- ome_device_group - Added support for adding devices to a group using the IP addresses of the devices and group ID. -- ome_firmware - Added option to stage the firmware update and support for selecting components and devices for baseline-based firmware update. -- ome_firmware_baseline - Module supports check mode, and allows the modification and deletion of firmware baselines. -- ome_firmware_catalog - Module supports check mode, and allows the modification and deletion of firmware catalogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add real-world use cases in the example section for some configuration modules. -- Collect the current configurations of the modules and convert them into playbooks. -- Improve ``fortios_configuration_fact`` to use multiple selectors concurrently. -- New module fortios_monitor_fact. -- Support FortiOS 7.0.1. -- Support Fortios 7.0. -- Support Log APIs. -- Support ``check_mode`` in all cofigurationAPI-based modules. -- Support filtering for fact gathering modules ``fortios_configuration_fact`` and ``fortios_monitor_fact``. -- Support member operation (delete/add extra members) on an object that has a list of members in it. -- Support moving policy in ``firewall_central_snat_map``. -- Support selectors feature in ``fortios_monitor_fact`` and ``fortios_log_fact``. -- Unify schemas for monitor API. - -gluster.gluster -~~~~~~~~~~~~~~~ - -- enable client.ssl,server.ssl before starting the gluster volume (https://github.com/gluster/gluster-ansible-collection/pull/19) - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- Introduction of placement groups - -kubernetes.core -~~~~~~~~~~~~~~~ - -- k8s - deprecate merge_type=json. The JSON patch functionality has never worked (https://github.com/ansible-collections/kubernetes.core/pull/99). -- k8s_json_patch - split JSON patch functionality out into a separate module (https://github.com/ansible-collections/kubernetes.core/pull/99). -- replaces the openshift client with the official kubernetes client (https://github.com/ansible-collections/kubernetes.core/issues/34). - -netapp.cloudmanager -~~~~~~~~~~~~~~~~~~~ - -- Adding stage environment to all modules in cloudmanager - -netbox.netbox -~~~~~~~~~~~~~ - -- packages is now a required Python package and gets installed through Ansible 2.10+. - -openvswitch.openvswitch -~~~~~~~~~~~~~~~~~~~~~~~ - -- By mistake we tagged the repo to 2.0.0 and as it wasn't intended and cannot be reverted we're releasing 2.0.1 to make the community aware of the major version update. - -ovirt.ovirt -~~~~~~~~~~~ - -- remove_stale_lun - Add role for removing stale LUN (https://bugzilla.redhat.com/1966873). - -Removed Features ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- The built-in module_util ``ansible.module_utils.common.removed`` was previously deprecated and has been removed. -- connections, removed password check stubs that had been moved to become plugins. -- task, inline parameters being auto coerced into variables has been removed. - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Removed ``shutdown_timeout`` and ``shutdown_timeout_sec`` which has not done anything since Ansible 2.5. - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme_* modules - the ``acme_directory`` option is now required (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_* modules - the ``acme_version`` option is now required (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_account_facts - the deprecated redirect has been removed. Use community.crypto.acme_account_info instead (https://github.com/ansible-collections/community.crypto/pull/290). -- acme_account_info - ``retrieve_orders=url_list`` no longer returns the return value ``orders``. Use the ``order_uris`` return value instead (https://github.com/ansible-collections/community.crypto/pull/290). -- crypto.info module utils - the deprecated redirect has been removed. Use ``crypto.pem`` instead (https://github.com/ansible-collections/community.crypto/pull/290). -- get_certificate - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_certificate - the deprecated redirect has been removed. Use community.crypto.x509_certificate instead (https://github.com/ansible-collections/community.crypto/pull/290). -- openssl_certificate_info - the deprecated redirect has been removed. Use community.crypto.x509_certificate_info instead (https://github.com/ansible-collections/community.crypto/pull/290). -- openssl_csr - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_csr and openssl_csr_pipe - ``version`` now only accepts the (default) value 1 (https://github.com/ansible-collections/community.crypto/pull/290). -- openssl_csr_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_csr_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_privatekey - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_privatekey_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_privatekey_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_publickey - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_publickey_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_signature - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- openssl_signature_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- x509_certificate - remove ``assertonly`` provider (https://github.com/ansible-collections/community.crypto/pull/289). -- x509_certificate - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- x509_certificate_info - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). -- x509_certificate_pipe - removed the ``pyopenssl`` backend (https://github.com/ansible-collections/community.crypto/pull/273). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_container - the default value of ``container_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.docker/pull/210). -- docker_container - the default value of ``network_mode`` is now the name of the first network specified in ``networks`` if such are specified and ``networks_cli_compatible=true`` (https://github.com/ansible-collections/community.docker/pull/210). -- docker_container - the special value ``all`` can no longer be used in ``published_ports`` next to other values. Please use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/210). -- docker_login - removed the ``email`` option (https://github.com/ansible-collections/community.docker/pull/210). - -community.general -~~~~~~~~~~~~~~~~~ - -- All inventory and vault scripts contained in community.general were moved to the `contrib-scripts GitHub repository `_ (https://github.com/ansible-collections/community.general/pull/2696). -- ModuleHelper module utils - remove fallback when value could not be determined for a parameter (https://github.com/ansible-collections/community.general/pull/3461). -- Removed deprecated netapp module utils and doc fragments (https://github.com/ansible-collections/community.general/pull/3197). -- The nios, nios_next_ip, nios_next_network lookup plugins, the nios documentation fragment, and the nios_host_record, nios_ptr_record, nios_mx_record, nios_fixed_address, nios_zone, nios_member, nios_a_record, nios_aaaa_record, nios_network, nios_dns_view, nios_txt_record, nios_naptr_record, nios_srv_record, nios_cname_record, nios_nsgroup, and nios_network_view module have been removed from community.general 4.0.0 and were replaced by redirects to the `infoblox.nios_modules `_ collection. Please install the ``infoblox.nios_modules`` collection to continue using these plugins and modules, and update your FQCNs (https://github.com/ansible-collections/community.general/pull/3592). -- The vendored copy of ``ipaddress`` has been removed. Please use ``ipaddress`` from the Python 3 standard library, or `from pypi `_. (https://github.com/ansible-collections/community.general/pull/2441). -- cpanm - removed the deprecated ``system_lib`` option. Use Ansible's privilege escalation mechanism instead; the option basically used ``sudo`` (https://github.com/ansible-collections/community.general/pull/3461). -- grove - removed the deprecated alias ``message`` of the ``message_content`` option (https://github.com/ansible-collections/community.general/pull/3461). -- proxmox - default value of ``proxmox_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.general/pull/3461). -- proxmox_kvm - default value of ``proxmox_default_behavior`` changed to ``no_defaults`` (https://github.com/ansible-collections/community.general/pull/3461). -- runit - removed the deprecated ``dist`` option which was not used by the module (https://github.com/ansible-collections/community.general/pull/3461). -- telegram - removed the deprecated ``msg``, ``msg_format`` and ``chat_id`` options (https://github.com/ansible-collections/community.general/pull/3461). -- xfconf - the default value of ``disable_facts`` changed to ``true``, and the value ``false`` is no longer allowed. Register the module results instead (https://github.com/ansible-collections/community.general/pull/3461). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- drop support for Python 2 and Python 3.5 (https://github.com/ansible-collections/community.hashi_vault/issues/81). -- support for the following deprecated environment variables has been removed: ``VAULT_AUTH_METHOD``, ``VAULT_TOKEN_PATH``, ``VAULT_TOKEN_FILE``, ``VAULT_ROLE_ID``, ``VAULT_SECRET_ID`` (https://github.com/ansible-collections/community.hashi_vault/pull/173). - -Deprecated Features -------------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - The ``--docker-no-pull`` option is deprecated and has no effect. -- ansible-test - The ``--no-pip-check`` option is deprecated and has no effect. -- include action is deprecated in favor of include_tasks, import_tasks and import_playbook. -- module_utils' FileLock is scheduled to be removed, it is not used due to its unreliable nature. - -amazon.aws -~~~~~~~~~~ - -- ec2 - the boto based ``ec2`` module has been deprecated in favour of the boto3 based ``ec2_instance`` module. The ``ec2`` module will be removed in release 4.0.0 (https://github.com/ansible-collections/amazon.aws/pull/424). -- ec2_classic_lb - setting of the ``ec2_elb`` fact has been deprecated and will be removed in release 4.0.0 of the collection. The module now returns ``elb`` which can be accessed using the register keyword (https://github.com/ansible-collections/amazon.aws/pull/552). -- ec2_vpc_dhcp_option - The ``new_config`` return key has been deprecated and will be removed in a future release. It will be replaced by ``dhcp_config``. Both values are returned in the interim. (https://github.com/ansible-collections/amazon.aws/pull/252) - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- network_cli - The paramiko_ssh setting ``look_for_keys`` was set automatically based on the values of the ``password`` and ``private_key_file`` options passed to network_cli. This option can now be set explicitly, and the automatic setting of ``look_for_keys`` will be removed after 2024-01-01 (https://github.com/ansible-collections/ansible.netcommon/pull/271). - -ansible.windows -~~~~~~~~~~~~~~~ - -- win_reboot - Unreachable hosts can be ignored with ``ignore_errors: True``, this ability will be removed in a future version. Use ``ignore_unreachable: True`` to ignore unreachable hosts instead. - https://github.com/ansible-collections/ansible.windows/issues/62 -- win_updates - Deprecated the ``filtered_reason`` return value for each filtered up in favour of ``filtered_reasons``. This has been done to show all the reasons why an update was filtered and not just the first reason. -- win_updates - Deprecated the ``use_scheduled_task`` option as it is no longer used. -- win_updates - Deprecated the ``whitelist`` and ``blacklist`` options in favour of ``accept_list`` and ``reject_list`` respectively to conform to the new standards used in Ansible for these types of options. - -arista.eos -~~~~~~~~~~ - -- Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests. - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_bgp in favor of ios_bgp_global and ios_bgp_address_family. -- Deprecated ios_ntp modules. -- Remove testing with provider for ansible-test integration jobs. This helps prepare us to move to network-ee integration tests. - -cisco.iosxr -~~~~~~~~~~~ - -- The iosxr_logging module has been deprecated in favor of the new iosxr_logging_global resource module and will be removed in a release after '2023-08-01'. - -cisco.nxos -~~~~~~~~~~ - -- Deprecated `nxos_ntp`, `nxos_ntp_options`, `nxos_ntp_auth` modules. -- The nxos_logging module has been deprecated in favor of the new nxos_logging_global resource module and will be removed in a release after '2023-08-01'. - -community.aws -~~~~~~~~~~~~~ - -- dynamodb_table - DynamoDB does not support specifying non-key-attributes when creating an ``ALL`` index. Passing ``includes`` for such indexes is currently ignored but will result in failures after version 3.0.0 (https://github.com/ansible-collections/community.aws/pull/726). -- dynamodb_table - DynamoDB does not support updating the primary indexes on a table. Attempts to make such changes are currently ignored but will result in failures after version 3.0.0 (https://github.com/ansible-collections/community.aws/pull/726). -- ec2_elb - the ``ec2_elb`` module has been removed and redirected to the ``elb_instance`` module which functions identically. The original ``ec2_elb`` name is now deprecated and will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/586). -- ec2_elb_info - the boto based ``ec2_elb_info`` module has been deprecated in favour of the boto3 based ``elb_classic_lb_info`` module. The ``ec2_elb_info`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/586). -- elb_classic_lb - the ``elb_classic_lb`` module has been removed and redirected to the ``amazon.aws.ec2_elb_lb`` module which functions identically. -- elb_instance - setting of the ``ec2_elb`` fact has been deprecated and will be removed in release 4.0.0 of the collection. See the module documentation for an alternative example using the register keyword (https://github.com/ansible-collections/community.aws/pull/773). -- iam - the boto based ``iam`` module has been deprecated in favour of the boto3 based ``iam_user``, ``iam_group`` and ``iam_role`` modules. The ``iam`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/664). -- iam_cert - the iam_cert module has been renamed to iam_server_certificate for consistency with the companion iam_server_certificate_info module. The usage of the module has not changed. The iam_cert alias will be removed in version 4.0.0 (https://github.com/ansible-collections/community.aws/pull/728). -- iam_server_certificate - Passing file names to the ``cert``, ``chain_cert`` and ``key`` parameters has been deprecated. We recommend using a lookup plugin to read the files instead, see the documentation for an example (https://github.com/ansible-collections/community.aws/pull/735). -- iam_server_certificate - the default value for the ``dup_ok`` parameter is currently ``false``, in version 4.0.0 this will be updated to ``true``. To preserve the current behaviour explicitly set the ``dup_ok`` parameter to ``false`` (https://github.com/ansible-collections/community.aws/pull/737). -- rds - the boto based ``rds`` module has been deprecated in favour of the boto3 based ``rds_instance`` module. The ``rds`` module will be removed in release 3.0.0 (https://github.com/ansible-collections/community.aws/pull/663). -- rds_snapshot - the rds_snapshot module has been renamed to rds_instance_snapshot. The usage of the module has not changed. The rds_snapshot alias will be removed in version 4.0.0 (https://github.com/ansible-collections/community.aws/pull/783). -- script_inventory_ec2 - The ec2.py inventory script is being moved to a new repository. The script can now be downloaded from https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py and will be removed from this collection in the 3.0 release. We recommend migrating from the script to the `amazon.aws.ec2` inventory plugin. - -community.azure -~~~~~~~~~~~~~~~ - -- All community.azure.azure_rm__facts modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- All community.azure.azure_rm__info modules are deprecated. Use azure.azcollection.azure_rm__info modules instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_managed_disk and community.azure.azure_rm_manageddisk are deprecated. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_extension and community.azure.azure_rm_virtualmachineextension are deprecated. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/24). -- community.azure.azure_rm_virtualmachine_scaleset and community.azure.azure_rm_virtualmachinescaleset are deprecated. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/24). - -community.crypto -~~~~~~~~~~~~~~~~ - -- acme_* modules - ACME version 1 is now deprecated and support for it will be removed in community.crypto 2.0.0 (https://github.com/ansible-collections/community.crypto/pull/288). - -community.dns -~~~~~~~~~~~~~ - -- The hosttech_dns_records module has been renamed to hosttech_dns_record_sets. The old name will stop working in community.dns 3.0.0 (https://github.com/ansible-collections/community.dns/pull/31). - -community.docker -~~~~~~~~~~~~~~~~ - -- docker_* modules and plugins, except ``docker_swarm`` connection plugin and ``docker_compose`` and ``docker_stack*` modules - the current default ``localhost`` for ``tls_hostname`` is deprecated. In community.docker 2.0.0 it will be computed from ``docker_host`` instead (https://github.com/ansible-collections/community.docker/pull/134). -- docker_container - the new ``command_handling``'s default value, ``compatibility``, is deprecated and will change to ``correct`` in community.docker 3.0.0. A deprecation warning is emitted by the module in cases where the behavior will change. Please note that ansible-core will output a deprecation warning only once, so if it is shown for an earlier task, there could be more tasks with this warning where it is not shown (https://github.com/ansible-collections/community.docker/pull/186). -- docker_container - using the special value ``all`` in ``published_ports`` has been deprecated. Use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/210). - -community.general -~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.general 5.0.0) next spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.general 4.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.general/pull/3723). -- ali_instance_info - marked removal version of deprecated parameters ``availability_zone`` and ``instance_names`` (https://github.com/ansible-collections/community.general/issues/2429). -- bitbucket_* modules - ``username`` options have been deprecated in favor of ``workspace`` and will be removed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/2045). -- dnsimple - python-dnsimple < 2.0.0 is deprecated and support for it will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2946#discussion_r667624693). -- gitlab_group_members - setting ``gitlab_group`` to ``name`` or ``path`` is deprecated. Use ``full_path`` instead (https://github.com/ansible-collections/community.general/pull/3451). -- keycloak_authentication - the return value ``flow`` is now deprecated and will be removed in community.general 6.0.0; use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/3280). -- keycloak_group - the return value ``group`` is now deprecated and will be removed in community.general 6.0.0; use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/3280). -- linode - parameter ``backupsenabled`` is deprecated and will be removed in community.general 5.0.0 (https://github.com/ansible-collections/community.general/pull/2410). -- lxd_container - the current default value ``true`` of ``ignore_volatile_options`` is deprecated and will change to ``false`` in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/3429). -- serverless - deprecating parameter ``functions`` because it was not used in the code (https://github.com/ansible-collections/community.general/pull/2845). -- xfconf - deprecate the ``get`` state. The new module ``xfconf_info`` should be used instead (https://github.com/ansible-collections/community.general/pull/3049). - -community.grafana -~~~~~~~~~~~~~~~~~ - -- grafana_dashboard lookup - Providing a mangled version of the API key is no longer preferred. - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault collection - support for Python 2 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). -- hashi_vault collection - support for Python 3.5 will be dropped in version ``2.0.0`` of ``community.hashi_vault`` (https://github.com/ansible-collections/community.hashi_vault/issues/81). -- lookup hashi_vault - the ``[lookup_hashi_vault]`` section in the ``ansible.cfg`` file is deprecated and will be removed in collection version ``3.0.0``. Instead, the section ``[hashi_vault_collection]`` can be used, which will apply to all plugins in the collection going forward (https://github.com/ansible-collections/community.hashi_vault/pull/144). - -community.kubernetes -~~~~~~~~~~~~~~~~~~~~ - -- The ``community.kubernetes`` collection is being renamed to ``kubernetes.core``. All content in the collection has been replaced by deprecated redirects to ``kubernetes.core``. If you are using FQCNs starting with ``community.kubernetes``, please update them to ``kubernetes.core`` (https://github.com/ansible-collections/community.kubernetes/pull/439). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vmware_guest_vnc - Sphere 7.0 removed the built-in VNC server (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#productsupport). - -inspur.sm -~~~~~~~~~ - -- add_ad_group - This feature will be removed in inspur.sm.add_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- add_ldap_group - This feature will be removed in inspur.sm.add_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- add_user - This feature will be removed in inspur.sm.add_user 3.0.0. replaced with inspur.sm.user. -- add_user_group - This feature will be removed in inspur.sm.add_user_group 3.0.0. replaced with inspur.sm.user_group. -- del_ad_group - This feature will be removed in inspur.sm.del_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- del_ldap_group - This feature will be removed in inspur.sm.del_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- del_user - This feature will be removed in inspur.sm.del_user 3.0.0. replaced with inspur.sm.user. -- del_user_group - This feature will be removed in inspur.sm.del_user_group 3.0.0. replaced with inspur.sm.user_group. -- edit_ad_group - This feature will be removed in inspur.sm.edit_ad_group 3.0.0. replaced with inspur.sm.ad_group. -- edit_ldap_group - This feature will be removed in inspur.sm.edit_ldap_group 3.0.0. replaced with inspur.sm.ldap_group. -- edit_user - This feature will be removed in inspur.sm.edit_user 3.0.0. replaced with inspur.sm.user. -- edit_user_group - This feature will be removed in inspur.sm.edit_user_group 3.0.0. replaced with inspur.sm.user_group. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Deprecated router_id from ospfv2 resource module. -- Deprecated router_id from ospfv3 resource module. -- The junos_logging module has been deprecated in favor of the new junos_logging_global resource module and will be removed in a release after '2023-08-01'. - -vyos.vyos -~~~~~~~~~ - -- The vyos_logging module has been deprecated in favor of the new vyos_logging_global resource module and will be removed in a release after "2023-08-01". diff --git a/docs/docsite/rst/porting_guides/porting_guide_6.rst b/docs/docsite/rst/porting_guides/porting_guide_6.rst deleted file mode 100644 index d7a0e98dd46..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_6.rst +++ /dev/null @@ -1,964 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.13.rst) - -.. _porting_6_guide: - -======================= -Ansible 6 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 6 is based on Ansible-core 2.13. - - -We suggest you read this page along with the `Ansible 6 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -* Templating - You can no longer perform arithmetic and concatenation operations outside of the jinja template. The following statement will need to be rewritten to produce ``[1, 2]``: - - .. code-block:: yaml - - - name: Prior to 2.13 - debug: - msg: '[1] + {{ [2] }}' - - - name: 2.13 and forward - debug: - msg: '{{ [1] + [2] }}' - -* The return value of the ``__repr__`` method of an undefined variable represented by the ``AnsibleUndefined`` object changed. ``{{ '%r'|format(undefined_variable) }}`` returns ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` in 2.13 as opposed to just ``AnsibleUndefined`` in versions 2.12 and prior. - -* The ``finalize`` method is no longer exposed in the globals for use in templating. To convert ``None`` to an empty string the following expression can be used: ``{{ value if value is not none }}``. - - -Command Line -============ - -No notable changes - - -Deprecated -========== - -No notable changes - - -Modules -======= - -* To use ansible-core 2.13 for module execution, you must use Python 2 version 2.7 or Python 3 version 3.5 or newer. Any code utilizing ``ansible.module_utils.basic`` will not function with lower Python versions. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Breaking Changes ----------------- - -* ``ansible.module_utils.urls.fetch_url`` will now return the captured ``HTTPError`` exception as ``r``. ``HTTPError`` is a response like object that can offer more information to module authors. Modules should rely on ``info['status'] >= 400`` to determine if there was a failure, instead of using ``r is None`` or catching ``AttributeError`` when attempting ``r.read()``. - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v6.7.0 -======================== - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131). -- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131). - -Major Changes -------------- - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_l7_firewall - New module -- meraki_webhook_payload_template - New module - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate -- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate - -containers.podman -~~~~~~~~~~~~~~~~~ - -- New become plugin - podman_unshare -- Podman generate systemd module - -fortinet.fortimanager -~~~~~~~~~~~~~~~~~~~~~ - -- Fix compatibility issue for ansible 2.9.x and ansible-base 2.10.x. -- support Ansible changelogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- Please note that some tools, like the VScode plugin (https://github.com/ansible/vscode-ansible/issues/573), or ``ansible-doc --list --type module``, suggest to replace the correct FQCNs for modules and actions in community.general with internal names that have more than three components. For example, ``community.general.ufw`` is suggested to be replaced by ``community.general.system.ufw``. While these longer names do work, they are considered **internal names** by the collection and are subject to change and be removed at all time. They **will** be removed in community.general 6.0.0 and result in deprecation messages. Avoid using these internal names, and use general three-component FQCNs (``community.general.``) instead (https://github.com/ansible-collections/community.general/pull/5373). - -Porting Guide for v6.6.0 -======================== - -Added Collections ------------------ - -- lowlydba.sqlserver (version 1.0.4) - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- The ``community.routeros.command`` module claims to support check mode. Since it cannot judge whether the commands executed modify state or not, this behavior is incorrect. Since this potentially breaks existing playbooks, we will not change this behavior until community.routeros 3.0.0. - -Breaking Changes ----------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- newrelic_deployment - ``revision`` is required for v2 API (https://github.com/ansible-collections/community.general/pull/5341). - -Major Changes -------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- newrelic_deployment - removed New Relic v1 API, added support for v2 API (https://github.com/ansible-collections/community.general/pull/5341). - -fortinet.fortimanager -~~~~~~~~~~~~~~~~~~~~~ - -- Many fixes for Ansible sanity test warnings & errors. -- Support FortiManager Schema 7.2.0 , 98 new modules - -Deprecated Features -------------------- - -- The mellanox.onyx collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/136). - -cisco.mso -~~~~~~~~~ - -- The mso_schema_template_contract_filter contract_filter_type attribute is deprecated. The value is now deduced from filter_type. - -community.general -~~~~~~~~~~~~~~~~~ - -- ArgFormat module utils - deprecated along ``CmdMixin``, in favor of the ``cmd_runner_fmt`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdMixin module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdStateModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- django_manage - support for Django releases older than 4.1 has been deprecated and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - support for the commands ``cleanup``, ``syncdb`` and ``validate`` that have been deprecated in Django long time ago will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - the behavior of "creating the virtual environment when missing" is being deprecated and will be removed in community.general version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5405). -- newrelic_deployment - ``appname`` and ``environment`` are no longer valid options in the v2 API. They will be removed in community.general 7.0.0 (https://github.com/ansible-collections/community.general/pull/5341). - -Porting Guide for v6.5.0 -======================== - -Major Changes -------------- - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Feature for extra layer security , with `cert` and `key` parameters in playbooks for authenticating using certificate and key ``*.pem`` file absolute path `#154 `_ -- Fix to remove issue causing due to template attr in deleting network using Ansible module nios network `#147 `_ - -Deprecated Features -------------------- - -- The dellemc.os10 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/134). -- The dellemc.os6 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/132). -- The dellemc.os9 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/133). - -community.general -~~~~~~~~~~~~~~~~~ - -- lxc_container - the module will no longer make any effort to support Python 2 (https://github.com/ansible-collections/community.general/pull/5304). - -Porting Guide for v6.4.0 -======================== - -Added Collections ------------------ - -- inspur.ispim (version 1.0.1) -- vultr.cloud (version 1.1.0) - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- proxmox - deprecated the current ``unprivileged`` default value, will be changed to ``true`` in community.general 7.0.0 (https://github.com/pull/5224). - -Porting Guide for v6.3.0 -======================== - -Major Changes -------------- - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_db - the ``pipefail`` argument's default value will be changed to ``true`` in community.mysql 4.0.0. If your target machines do not use ``bash`` as a default interpreter, set ``pipefail`` to ``false`` explicitly. However, we strongly recommend setting up ``bash`` as a default and ``pipefail=true`` as it will protect you from getting broken dumps you don't know about (https://github.com/ansible-collections/community.mysql/issues/407). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support Diff feature in check_mode. -- Support Fortios 7.2.0. - -Deprecated Features -------------------- - -- The google.cloud collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/105). -- The servicenow.servicenow collection has been deprecated by its maintainers (https://github.com/ServiceNowITOM/servicenow-ansible/pull/69) and will be removed from Ansible 7. It can still be installed manually, but it is suggested to switch to `servicenow.itsm `__ instead (https://github.com/ansible-community/community-topics/issues/124). - -Porting Guide for v6.2.0 -======================== - -Added Collections ------------------ - -- ibm.spectrum_virtualize (version 1.9.0) - -Known Issues ------------- - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_snapshot - added documentation to use UTC format for ``expiry_time``. - -Major Changes -------------- - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_user - the ``groups`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_membership`` module to specify group/role memberships instead (https://github.com/ansible-collections/community.postgresql/issues/277). - -Deprecated Features -------------------- - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- vault_kv2_get lookup - the ``engine_mount_point option`` in the ``vault_kv2_get`` lookup only will change its default from ``kv`` to ``secret`` in community.hashi_vault version 4.0.0 (https://github.com/ansible-collections/community.hashi_vault/issues/279). - -Porting Guide for v6.1.0 -======================== - -Added Collections ------------------ - -- purestorage.fusion (version 1.0.2) - -Known Issues ------------- - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -Major Changes -------------- - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added bootstrap_script option to allow users to target a script URL for installing Chocolatey on clients. -- win_chocolatey_facts - Added outdated packages list to data returned. - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Update `text` field of TXT Record `#128 `_ -- Update operation using `old_name` and `new_name` for the object with dummy name in `old_name` (which does not exist in system) will not create a new object in the system. An error will be thrown stating the object does not exist in the system `#129 `_ - -Deprecated Features -------------------- - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_linkagg_module in favor of ios_lag_interfaces. - -community.aws -~~~~~~~~~~~~~ - -- aws_codebuild - The ``tags`` parameter currently uses a non-standard format and has been deprecated. In release 6.0.0 this parameter will accept a simple key/value pair dictionary instead of the current list of dictionaries. It is recommended to migrate to using the resource_tags parameter which already accepts the simple dictionary format (https://github.com/ansible-collections/community.aws/pull/1221). -- route53_info - The CamelCase return values for ``HostedZones``, ``ResourceRecordSets``, and ``HealthChecks`` have been deprecated, in the future release you must use snake_case return values ``hosted_zones``, ``resource_record_sets``, and ``health_checks`` instead respectively". - -community.crypto -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.crypto 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.crypto/pull/460). - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Docker API version 1.20 to 1.24 has been deprecated and will be removed in community.docker 3.0.0. The first Docker version supporting API version 1.25 was Docker 1.13, released in January 2017. This affects the modules ``docker_container``, ``docker_container_exec``, ``docker_container_info``, ``docker_compose``, ``docker_login``, ``docker_image``, ``docker_image_info``, ``docker_image_load``, ``docker_host_info``, ``docker_network``, ``docker_network_info``, ``docker_node_info``, ``docker_swarm_info``, ``docker_swarm_service``, ``docker_swarm_service_info``, ``docker_volume_info``, and ``docker_volume``, whose minimally supported API version is between 1.20 and 1.24 (https://github.com/ansible-collections/community.docker/pull/396). -- Support for Python 2.6 is deprecated and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with Python 2.6, but we will no longer try to ensure compatibility (https://github.com/ansible-collections/community.docker/pull/388). - -community.general -~~~~~~~~~~~~~~~~~ - -- cmd_runner module utils - deprecated ``fmt`` in favour of ``cmd_runner_fmt`` as the parameter format object (https://github.com/ansible-collections/community.general/pull/4777). - -Porting Guide for v6.0.0 -======================== - -Added Collections ------------------ - -- cisco.dnac (version 6.4.0) -- community.sap (version 1.0.0) -- community.sap_libs (version 1.1.0) -- vmware.vmware_rest (version 2.1.5) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- get_url - document ``check_mode`` correctly with unreliable changed status (https://github.com/ansible/ansible/issues/65687). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- eos - When using eos modules on Ansible 2.9, tasks will occasionally fail with ``import_modules`` enabled. This can be avoided by setting ``import_modules: no`` - -community.general -~~~~~~~~~~~~~~~~~ - -- pacman - ``update_cache`` cannot differentiate between up to date and outdated package lists and will report ``changed`` in both situations (https://github.com/ansible-collections/community.general/pull/4318). -- pacman - binaries specified in the ``executable`` parameter must support ``--print-format`` in order to be used by this module. In particular, AUR helper ``yay`` is known not to currently support it (https://github.com/ansible-collections/community.general/pull/4312). - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_console_preferences - Issue(224690) - The module does not display a proper error message when an unsupported value is provided for the parameters report_row_limit, email_sender_settings, and metric_collection_settings, and the value is applied on OpenManage Enterprise. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_power_settings - Issue(212679) - The module errors out with the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_admin - Once `max_login` and `lockout` have been set there is currently no way to rest these to zero except through the FlashArray GUI - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- Module Python Dependency - Drop support for Python 2.6 in module execution. -- Templating - it is no longer allowed to perform arithmetic and concatenation operations outside of the jinja template (https://github.com/ansible/ansible/pull/75587) -- The ``finalize`` method is no longer exposed in the globals for use in templating. - -amazon.aws -~~~~~~~~~~ - -- aws_caller_facts - Remove deprecated ``aws_caller_facts`` alias. Please use ``aws_caller_info`` instead. -- cloudformation_facts - Remove deprecated ``cloudformation_facts`` alias. Please use ``cloudformation_info`` instead. -- ec2_ami_facts - Remove deprecated ``ec2_ami_facts`` alias. Please use ``ec2_ami_info`` instead. -- ec2_eni_facts - Remove deprecated ``ec2_eni_facts`` alias. Please use ``ec2_eni_info`` instead. -- ec2_group_facts - Remove deprecated ``ec2_group_facts`` alias. Please use ``ec2_group_info`` instead. -- ec2_instance_facts - Remove deprecated ``ec2_instance_facts`` alias. Please use ``ec2_instance_info`` instead. -- ec2_snapshot_facts - Remove deprecated ``ec2_snapshot_facts`` alias. Please use ``ec2_snapshot_info`` instead. -- ec2_vol_facts - Remove deprecated ``ec2_vol_facts`` alias. Please use ``ec2_vol_info`` instead. -- ec2_vpc_dhcp_option_facts - Remove deprecated ``ec2_vpc_dhcp_option_facts`` alias. Please use ``ec2_vpc_dhcp_option_info`` instead. -- ec2_vpc_endpoint_facts - Remove deprecated ``ec2_vpc_endpoint_facts`` alias. Please use ``ec2_vpc_endpoint_info`` instead. -- ec2_vpc_igw_facts - Remove deprecated ``ec2_vpc_igw_facts`` alias. Please use ``ec2_vpc_igw_info`` instead. -- ec2_vpc_nat_gateway_facts - Remove deprecated ``ec2_vpc_nat_gateway_facts`` alias. Please use ``ec2_vpc_nat_gateway_info`` instead. -- ec2_vpc_net_facts - Remove deprecated ``ec2_vpc_net_facts`` alias. Please use ``ec2_vpc_net_info`` instead. -- ec2_vpc_route_table_facts - Remove deprecated ``ec2_vpc_route_table_facts`` alias. Please use ``ec2_vpc_route_table_info`` instead. -- ec2_vpc_subnet_facts - Remove deprecated ``ec2_vpc_subnet_facts`` alias. Please use ``ec2_vpc_subnet_info`` instead. - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- httpapi - Change default value of ``import_modules`` option from ``no`` to ``yes`` -- netconf - Change default value of ``import_modules`` option from ``no`` to ``yes`` -- network_cli - Change default value of ``import_modules`` option from ``no`` to ``yes`` - -arista.eos -~~~~~~~~~~ - -- eos_command - new suboption ``version`` of parameter ``command``, which controls the JSON response version. Previously the value was assumed to be "latest" for network_cli and "1" for httpapi, but the default will now be "latest" for both connections. This option is also available for use in modules making their own device requests with ``plugins.module_utils.network.eos.eos.run_commands()`` with the same new default behavior. (https://github.com/ansible-collections/arista.eos/pull/258). -- httpapi - the ``eos_use_sessions`` option is now a boolean instead of an integer. - -community.aws -~~~~~~~~~~~~~ - -- aws_acm_facts - Remove deprecated alias ``aws_acm_facts``. Please use ``aws_acm_info`` instead. -- aws_kms_facts - Remove deprecated alias ``aws_kms_facts``. Please use ``aws_kms_info`` instead. -- aws_kms_info - Deprecated ``keys_attr`` field is now ignored (https://github.com/ansible-collections/community.aws/pull/838). -- aws_region_facts - Remove deprecated alias ``aws_region_facts``. Please use ``aws_region_info`` instead. -- aws_s3_bucket_facts - Remove deprecated alias ``aws_s3_bucket_facts``. Please use ``aws_s3_bucket_info`` instead. -- aws_sgw_facts - Remove deprecated alias ``aws_sgw_facts``. Please use ``aws_sgw_info`` instead. -- aws_waf_facts - Remove deprecated alias ``aws_waf_facts``. Please use ``aws_waf_info`` instead. -- cloudfront_facts - Remove deprecated alias ``cloudfront_facts``. Please use ``cloudfront_info`` instead. -- cloudwatchlogs_log_group_facts - Remove deprecated alias ``cloudwatchlogs_log_group_facts``. Please use ``cloudwatchlogs_log_group_info`` instead. -- dynamodb_table - deprecated updates currently ignored for primary keys and global_all indexes will now result in a failure. (https://github.com/ansible-collections/community.aws/pull/837). -- ec2_asg_facts - Remove deprecated alias ``ec2_asg_facts``. Please use ``ec2_asg_info`` instead. -- ec2_customer_gateway_facts - Remove deprecated alias ``ec2_customer_gateway_facts``. Please use ``ec2_customer_gateway_info`` instead. -- ec2_eip_facts - Remove deprecated alias ``ec2_eip_facts``. Please use ``ec2_eip_info`` instead. -- ec2_elb_facts - Remove deprecated alias ``ec2_elb_facts``. Please use ``ec2_elb_info`` instead. -- ec2_elb_info - The ``ec2_elb_info`` module has been removed. Please use ``the ``elb_classic_lb_info`` module. -- ec2_lc_facts - Remove deprecated alias ``ec2_lc_facts``. Please use ``ec2_lc_info`` instead. -- ec2_placement_group_facts - Remove deprecated alias ``ec2_placement_group_facts``. Please use ``ec2_placement_group_info`` instead. -- ec2_vpc_nacl_facts - Remove deprecated alias ``ec2_vpc_nacl_facts``. Please use ``ec2_vpc_nacl_info`` instead. -- ec2_vpc_peering_facts - Remove deprecated alias ``ec2_vpc_peering_facts``. Please use ``ec2_vpc_peering_info`` instead. -- ec2_vpc_route_table_facts - Remove deprecated alias ``ec2_vpc_route_table_facts``. Please use ``ec2_vpc_route_table_info`` instead. -- ec2_vpc_vgw_facts - Remove deprecated alias ``ec2_vpc_vgw_facts``. Please use ``ec2_vpc_vgw_info`` instead. -- ec2_vpc_vpn_facts - Remove deprecated alias ``ec2_vpc_vpn_facts``. Please use ``ec2_vpc_vpn_info`` instead. -- ecs_service_facts - Remove deprecated alias ``ecs_service_facts``. Please use ``ecs_service_info`` instead. -- ecs_taskdefinition_facts - Remove deprecated alias ``ecs_taskdefinition_facts``. Please use ``ecs_taskdefinition_info`` instead. -- efs_facts - Remove deprecated alias ``efs_facts``. Please use ``efs_info`` instead. -- elasticache_facts - Remove deprecated alias ``elasticache_facts``. Please use ``elasticache_info`` instead. -- elb_application_lb_facts - Remove deprecated alias ``elb_application_lb_facts``. Please use ``elb_application_lb_info`` instead. -- elb_classic_lb_facts - Remove deprecated alias ``elb_classic_lb_facts``. Please use ``elb_classic_lb_info`` instead. -- elb_target_facts - Remove deprecated alias ``elb_target_facts``. Please use ``elb_target_info`` instead. -- elb_target_group_facts - Remove deprecated alias ``elb_target_group_facts``. Please use ``elb_target_group_info`` instead. -- iam - Removed deprecated ``community.aws.iam`` module. Please use ``community.aws.iam_user``, ``community.aws.iam_access_key`` or ``community.aws.iam_group`` (https://github.com/ansible-collections/community.aws/pull/839). -- iam_cert_facts - Remove deprecated alias ``iam_cert_facts``. Please use ``iam_cert_info`` instead. -- iam_mfa_device_facts - Remove deprecated alias ``iam_mfa_device_facts``. Please use ``iam_mfa_device_info`` instead. -- iam_role_facts - Remove deprecated alias ``iam_role_facts``. Please use ``iam_role_info`` instead. -- iam_server_certificate_facts - Remove deprecated alias ``iam_server_certificate_facts``. Please use ``iam_server_certificate_info`` instead. -- lambda_facts - Remove deprecated module lambda_facts``. Please use ``lambda_info`` instead. -- rds - Removed deprecated ``community.aws.rds`` module. Please use ``community.aws.rds_instance`` (https://github.com/ansible-collections/community.aws/pull/839). -- rds_instance_facts - Remove deprecated alias ``rds_instance_facts``. Please use ``rds_instance_info`` instead. -- rds_snapshot_facts - Remove deprecated alias ``rds_snapshot_facts``. Please use ``rds_snapshot_info`` instead. -- redshift_facts - Remove deprecated alias ``redshift_facts``. Please use ``redshift_info`` instead. -- route53_facts - Remove deprecated alias ``route53_facts``. Please use ``route53_info`` instead. - -community.general -~~~~~~~~~~~~~~~~~ - -- Parts of this collection do not work with ansible-core 2.11 on Python 3.12+. Please either upgrade to ansible-core 2.12+, or use Python 3.11 or earlier (https://github.com/ansible-collections/community.general/pull/3988). -- The symbolic links used to implement flatmapping for all modules were removed and replaced by ``meta/runtime.yml`` redirects. This effectively breaks compatibility with Ansible 2.9 for all modules (without using their "long" names, which is discouraged and which can change without previous notice since they are considered an implementation detail) (https://github.com/ansible-collections/community.general/pull/4548). -- a_module test plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- archive - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- git_config - remove Ansible 2.9 and early ansible-base 2.10 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- java_keystore - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- lists_mergeby and groupby_as_dict filter plugins - adjust filter plugin filename. This change is not visible to end-users, it only affects possible other collections importing Python paths (https://github.com/ansible-collections/community.general/pull/4625). -- lists_mergeby filter plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- maven_artifact - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- memcached cache plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- path_join filter plugin shim - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- redis cache plugin - remove Ansible 2.9 compatibility code (https://github.com/ansible-collections/community.general/pull/4548). -- yarn - remove unsupported and unnecessary ``--no-emoji`` flag (https://github.com/ansible-collections/community.general/pull/4662). - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_replication - remove ``Is_Slave`` and ``Is_Master`` return values (were replaced with ``Is_Primary`` and ``Is_Replica`` (https://github.com/ansible-collections /community.mysql/issues/145). -- mysql_replication - remove the mode options values containing ``master``/``slave`` and the master_use_gtid option ``slave_pos`` (were replaced with corresponding ``primary``/``replica`` values) (https://github.com/ansible-collections/community.mysql/issues/145). -- mysql_user - remove support for the `REQUIRESSL` special privilege as it has ben superseded by the `tls_requires` option (https://github.com/ansible-collections/community.mysql/discussions/121). -- mysql_user - validate privileges using database engine directly (https://github.com/ansible-collections/community.mysql/issues/234 https://github.com/ansible-collections/community.mysql/pull/243). Do not validate privileges in this module anymore. - -community.vmware -~~~~~~~~~~~~~~~~ - -- The collection now requires at least ansible-core 2.11.0. Ansible 3 and before, and ansible-base versions are no longer supported. -- vmware_cluster_drs - The default for ``enable`` has been changed from ``false`` to ``true``. -- vmware_cluster_drs - The parameter alias ``enable_drs`` has been removed, use ``enable`` instead. -- vmware_cluster_ha - The default for ``enable`` has been changed from ``false`` to ``true``. -- vmware_cluster_ha - The parameter alias ``enable_ha`` has been removed, use ``enable`` instead. -- vmware_cluster_vsan - The default for ``enable`` has been changed from ``false`` to ``true``. -- vmware_cluster_vsan - The parameter alias ``enable_vsan`` has been removed, use ``enable`` instead. -- vmware_guest - Virtualization Based Security has some requirements (``nested_virt``, ``secure_boot`` and ``iommu``) that the module silently enabled. They have to be enabled explicitly now. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- HTTPS SSL certificate validation is a **breaking change** and will require modification in the existing playbooks. Please refer to `SSL Certificate Validation `_ section in the `README.md `_ for modification to existing playbooks. - -theforeman.foreman -~~~~~~~~~~~~~~~~~~ - -- Set use_reports_api default value to true for the inventory plugin -- Support for Ansible 2.8 is removed - -Major Changes -------------- - -- Add a ``ansible-community`` CLI tool that allows to print the version of the Ansible community distribution. Use ``ansible-community --version`` to print this version. - -Ansible-core -~~~~~~~~~~~~ - -- Jinja2 Controller Requirement - Jinja2 3.0.0 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/75881) -- Templating - remove ``safe_eval`` in favor of using ``NativeEnvironment`` but utilizing ``literal_eval`` only in cases when ``safe_eval`` was used (https://github.com/ansible/ansible/pull/75587) - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- cli_parse - this module has been moved to the ansible.utils collection. ``ansible.netcommon.cli_parse`` will continue to work to reference the module in its new location, but this redirect will be removed in a future release -- network_cli - Change default value of `ssh_type` option from `paramiko` to `auto`. This value will use libssh if the ansible-pylibssh module is installed, otherwise will fallback to paramiko. - -arista.eos -~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `eos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/arista.eos/issues/306). - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added choco_args option to pass additional arguments directly to Chocolatey. - -cisco.asa -~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -cisco.ios -~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- facts - default value for gather_subset is changed to min instead of !config. - -cisco.iosxr -~~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `facts` - default value for `gather_subset` is changed to min instead of !config. - -cisco.ise -~~~~~~~~~ - -- Update ciscoisesdk requirement to 1.2.0 -- anc_endpoint_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- anc_policy_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- backup_last_status_info - change return value, it returns response content. -- device_administration_authentication_rules - deletes parameter identitySourceId. -- device_administration_authentication_rules_info - change return value, it returns response content. -- device_administration_authorization_rules_info - change return value, it returns response content. -- device_administration_conditions - deletes parameter attributeId. -- device_administration_conditions_for_authentication_rule_info - change return value, it returns response content. -- device_administration_conditions_for_authorization_rule_info - change return value, it returns response content. -- device_administration_conditions_for_policy_set_info - change return value, it returns response content. -- device_administration_conditions_info - change return value, it returns response content. -- device_administration_dictionary_attributes_authentication_info - change return value, it returns response content. -- device_administration_dictionary_attributes_authorization_info - change return value, it returns response content. -- device_administration_dictionary_attributes_policy_set_info - change return value, it returns response content. -- device_administration_global_exception_rules_info - change return value, it returns response content. -- device_administration_network_conditions_info - change return value, it returns response content. -- device_administration_time_date_conditions - deletes parameter attributeId. -- device_administration_time_date_conditions_info - change return value, it returns response content. -- egress_matrix_cell_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- network_access_authentication_rules - deletes parameter identitySourceId. -- network_access_conditions - deletes parameter attributeId. -- network_access_time_date_conditions - deletes parameter attributeId. -- node_deployment - update parameters. -- node_deployment_info - add filter and filterType parameters. -- node_group - fixes response recollection. -- node_group_info - fixes response recollection. -- repository_files_info - change return value, it returns response content. -- repository_info - change return value, it returns response content. -- sg_acl_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sg_mapping_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sg_mapping_group_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sg_mapping_group_info - change return value, it returns BulkStatus content. -- sg_to_vn_to_vlan_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sgt - change generationId type from int to str. -- sgt_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sxp_connections_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sxp_local_bindings_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- sxp_vpns_bulk_monitor_status_info - change return value, it returns BulkStatus content. -- system_certificate - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject. -- system_certificate - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject. -- system_certificate - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject. -- system_certificate_import - new parameters portalTagTransferForSameSubject and roleTransferForSameSubject. -- system_certificate_import - portalTagTransferForSameSubject parameter renamed to allowPortalTagTransferForSameSubject. -- system_certificate_import - roleTransferForSameSubject parameter renamed to allowRoleTransferForSameSubject. -- trustsec_nbar_app_info - change type from str to list. -- trustsec_vn_info - change type from str to list. - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_radio - New module - -cisco.nxos -~~~~~~~~~~ - -- The minimum required ansible.netcommon version has been bumped to v2.6.1. -- Updated base plugin references to ansible.netcommon. -- `nxos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/cisco.nxos/issues/418). -- nxos_file_copy has been rewritten as a module. This change also removes the dependency on pexpect for file_pull operation. Since this now uses AnsibleModule class for argspec validation, the validation messages will be slightly different. Expect changes in the return payload in some cases. All functionality remains unchanged. - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - The community.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/809). -- s3_bucket_notifications - refactor module to support SNS / SQS targets as well as the existing support for Lambda functions (https://github.com/ansible-collections/community.aws/issues/140). - -community.general -~~~~~~~~~~~~~~~~~ - -- The community.general collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove a lot of compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.general/pull/4548). - -community.mysql -~~~~~~~~~~~~~~~ - -- The community.mysql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.mysql/pull/343). - -community.network -~~~~~~~~~~~~~~~~~ - -- The community.network collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.network/pull/426). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- The community.postgresql collection no longer supports ``Ansible 2.9`` and ``ansible-base 2.10``. While we take no active measures to prevent usage and there are no plans to introduce incompatible code to the modules, we will stop testing against ``Ansible 2.9`` and ``ansible-base 2.10``. Both will very soon be End of Life and if you are still using them, you should consider upgrading to the ``latest Ansible / ansible-core 2.11 or later`` as soon as possible (https://github.com/ansible-collections/community.postgresql/pull/245). -- postgresql_privs - the ``usage_on_types`` feature have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``type`` option with the ``type`` value to explicitly grant/revoke privileges on types (https://github.com/ansible-collections/community.postgresql/issues/207). -- postgresql_query - the ``path_to_script`` and ``as_single_query`` options as well as the ``query_list`` and ``query_all_results`` return values have been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``community.postgresql.postgresql_script`` module to execute statements from scripts (https://github.com/ansible-collections/community.postgresql/issues/189). -- postgresql_query - the default value of the ``as_single_query`` option changes to ``yes``. If the related behavior of your tasks where the module is involved changes, please adjust the parameter's value correspondingly (https://github.com/ansible-collections/community.postgresql/issues/85). -- postgresql_user - the ``priv`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_privs`` module to grant/revoke privileges instead (https://github.com/ansible-collections/community.postgresql/issues/212). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Drop VCSIM as a test target (https://github.com/ansible-collections/community.vmware/pull/1294). - -containers.podman -~~~~~~~~~~~~~~~~~ - -- Add podman_tag module -- Add secrets driver and driver opts support - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- All modules can read custom or organizational CA signed certificate from the environment variables. Please refer to `SSL Certificate Validation `_ section in the `README.md `_ for modification to existing playbooks or setting environment variable. -- All modules now support SSL over HTTPS and socket level timeout. -- idrac_server_config_profile - The module is enhanced to support export, import, and preview the SCP configuration using Redfish and added support for check mode. - -f5networks.f5_modules -~~~~~~~~~~~~~~~~~~~~~ - -- bigip_device_info - pagination logic has also been added to help with api stability. -- bigip_device_info - the module no longer gathers information from all partitions on device. This change will stabalize the module by gathering resources only from the given partition and prevent the module from gathering way too much information that might result in crashing. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS 7.0.2, 7.0.3, 7.0.4, 7.0.5. - -frr.frr -~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -ibm.qradar -~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `junos_facts` - change default gather_subset to `min` from `!config`. - -ovirt.ovirt -~~~~~~~~~~~ - -- manageiq - role removed (https://github.com/oVirt/ovirt-ansible-collection/pull/375). - -splunk.es -~~~~~~~~~ - -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. - -vyos.vyos -~~~~~~~~~ - -- Add 'pool' as value to server key in ntp_global. -- Minimum required ansible.netcommon version is 2.5.1. -- Updated base plugin references to ansible.netcommon. -- `vyos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/vyos.vyos/issues/231). - -Removed Collections -------------------- - -- community.kubernetes (previously included version: 2.0.1) -- community.kubevirt (previously included version: 1.0.0) - -Removed Features ----------------- - -- The community.kubernetes collection has been removed from Ansible 6. It has been deprecated since Ansible 4.2, and version 2.0.0 included since Ansible 5 is only a set of deprecated redirects from community.kubernetes to kubernetes.core. If you still need the redirects, you can manually install community.kubernetes with ``ansible-galaxy collection install community.kubernetes`` (https://github.com/ansible-community/community-topics/issues/93). -- The community.kubevirt collection has been removed from Ansible 6. It has not been working with the community.kubernetes collection included since Ansible 5.0.0, and unfortunately nobody managed to adjust the collection to work with kubernetes.core >= 2.0.0. If you need to use this collection, you need to manually install community.kubernetes < 2.0.0 together with community.kubevirt with ``ansible-galaxy collection install community.kubevirt 'community.kubernetes:<2.0.0'`` (https://github.com/ansible-community/community-topics/issues/92). - -Ansible-core -~~~~~~~~~~~~ - -- Remove deprecated ``Templar.set_available_variables()`` method (https://github.com/ansible/ansible/issues/75828) -- cli - remove deprecated ability to set verbosity before the sub-command (https://github.com/ansible/ansible/issues/75823) -- copy - remove deprecated ``thirsty`` alias (https://github.com/ansible/ansible/issues/75824) -- psrp - Removed fallback on ``put_file`` with older ``pypsrp`` versions. Users must have at least ``pypsrp>=0.4.0``. -- url_argument_spec - remove deprecated ``thirsty`` alias for ``get_url`` and ``uri`` modules (https://github.com/ansible/ansible/issues/75825, https://github.com/ansible/ansible/issues/75826) - -community.general -~~~~~~~~~~~~~~~~~ - -- ali_instance_info - removed the options ``availability_zone``, ``instance_ids``, and ``instance_names``. Use filter item ``zone_id`` instead of ``availability_zone``, filter item ``instance_ids`` instead of ``instance_ids``, and filter item ``instance_name`` instead of ``instance_names`` (https://github.com/ansible-collections/community.general/pull/4516). -- apt_rpm - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- compose - removed various deprecated aliases. Use the version with ``_`` instead of ``-`` instead (https://github.com/ansible-collections/community.general/pull/4516). -- dnsimple - remove support for dnsimple < 2.0.0 (https://github.com/ansible-collections/community.general/pull/4516). -- github_deploy_key - removed the deprecated alias ``2fa_token`` of ``otp`` (https://github.com/ansible-collections/community.general/pull/4516). -- homebrew, homebrew_cask - removed the deprecated alias ``update-brew`` of ``update_brew`` (https://github.com/ansible-collections/community.general/pull/4516). -- linode - removed the ``backupsenabled`` option. Use ``backupweeklyday`` or ``backupwindow`` to enable backups (https://github.com/ansible-collections/community.general/pull/4516). -- opkg - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- pacman - if ``update_cache=true`` is used with ``name`` or ``upgrade``, the changed state will now also indicate if only the cache was updated. To keep the old behavior - only indicate ``changed`` when a package was installed/upgraded -, use ``changed_when`` as indicated in the module examples (https://github.com/ansible-collections/community.general/pull/4516). -- pacman - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- proxmox, proxmox_kvm, proxmox_snap - no longer allow to specify a VM name that matches multiple VMs. If this happens, the modules now fail (https://github.com/ansible-collections/community.general/pull/4516). -- serverless - removed the ``functions`` option. It was not used by the module (https://github.com/ansible-collections/community.general/pull/4516). -- slackpkg - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- urpmi - removed the deprecated alias ``no-recommends`` of ``no_recommends`` (https://github.com/ansible-collections/community.general/pull/4516). -- urpmi - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- xbps - removed the deprecated alias ``update-cache`` of ``update_cache`` (https://github.com/ansible-collections/community.general/pull/4516). -- xfconf - the ``get`` state has been removed. Use the ``xfconf_info`` module instead (https://github.com/ansible-collections/community.general/pull/4516). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- aws_iam auth - the deprecated alias ``aws_iam_login`` for the ``aws_iam`` value of the ``auth_method`` option has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/194). -- community.hashi_vault collection - support for Ansible 2.9 and ansible-base 2.10 has been removed (https://github.com/ansible-collections/community.hashi_vault/issues/189). -- hashi_vault lookup - the deprecated ``[lookup_hashi_vault]`` INI config section has been removed in favor of the collection-wide ``[hashi_vault_collection]`` section (https://github.com/ansible-collections/community.hashi_vault/issues/179). -- the "legacy" integration test setup has been removed; this does not affect end users and is only relevant to contributors (https://github.com/ansible-collections/community.hashi_vault/pull/191). - -community.network -~~~~~~~~~~~~~~~~~ - -- aireos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aireos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vcenter_extension_facts - The deprecated module ``vcenter_extension_facts`` has been removed, use ``vcenter_extension_info`` instead. -- vmware_about_facts - The deprecated module ``vmware_about_facts`` has been removed, use ``vmware_about_info`` instead. -- vmware_category_facts - The deprecated module ``vmware_category_facts`` has been removed, use ``vmware_category_info`` instead. -- vmware_cluster - Remove DRS configuration in favour of module ``vmware_cluster_drs``. -- vmware_cluster - Remove HA configuration in favour of module ``vmware_cluster_ha``. -- vmware_cluster - Remove VSAN configuration in favour of module ``vmware_cluster_vsan``. -- vmware_cluster_facts - The deprecated module ``vmware_cluster_facts`` has been removed, use ``vmware_cluster_info`` instead. -- vmware_datastore_facts - The deprecated module ``vmware_datastore_facts`` has been removed, use ``vmware_datastore_info`` instead. -- vmware_drs_group_facts - The deprecated module ``vmware_drs_group_facts`` has been removed, use ``vmware_drs_group_info`` instead. -- vmware_drs_rule_facts - The deprecated module ``vmware_drs_rule_facts`` has been removed, use ``vmware_drs_rule_info`` instead. -- vmware_dvs_portgroup - The deprecated parameter ``portgroup_type`` has been removed, use ``port_binding`` instead. -- vmware_dvs_portgroup_facts - The deprecated module ``vmware_dvs_portgroup_facts`` has been removed, use ``vmware_dvs_portgroup_info`` instead. -- vmware_guest_boot_facts - The deprecated module ``vmware_guest_boot_facts`` has been removed, use ``vmware_guest_boot_info`` instead. -- vmware_guest_customization_facts - The deprecated module ``vmware_guest_customization_facts`` has been removed, use ``vmware_guest_customization_info`` instead. -- vmware_guest_disk_facts - The deprecated module ``vmware_guest_disk_facts`` has been removed, use ``vmware_guest_disk_info`` instead. -- vmware_guest_facts - The deprecated module ``vmware_guest_facts`` has been removed, use ``vmware_guest_info`` instead. -- vmware_guest_snapshot_facts - The deprecated module ``vmware_guest_snapshot_facts`` has been removed, use ``vmware_guest_snapshot_info`` instead. -- vmware_host_capability_facts - The deprecated module ``vmware_host_capability_facts`` has been removed, use ``vmware_host_capability_info`` instead. -- vmware_host_config_facts - The deprecated module ``vmware_host_config_facts`` has been removed, use ``vmware_host_config_info`` instead. -- vmware_host_dns_facts - The deprecated module ``vmware_host_dns_facts`` has been removed, use ``vmware_host_dns_info`` instead. -- vmware_host_feature_facts - The deprecated module ``vmware_host_feature_facts`` has been removed, use ``vmware_host_feature_info`` instead. -- vmware_host_firewall_facts - The deprecated module ``vmware_host_firewall_facts`` has been removed, use ``vmware_host_firewall_info`` instead. -- vmware_host_ntp_facts - The deprecated module ``vmware_host_ntp_facts`` has been removed, use ``vmware_host_ntp_info`` instead. -- vmware_host_package_facts - The deprecated module ``vmware_host_package_facts`` has been removed, use ``vmware_host_package_info`` instead. -- vmware_host_service_facts - The deprecated module ``vmware_host_service_facts`` has been removed, use ``vmware_host_service_info`` instead. -- vmware_host_ssl_facts - The deprecated module ``vmware_host_ssl_facts`` has been removed, use ``vmware_host_ssl_info`` instead. -- vmware_host_vmhba_facts - The deprecated module ``vmware_host_vmhba_facts`` has been removed, use ``vmware_host_vmhba_info`` instead. -- vmware_host_vmnic_facts - The deprecated module ``vmware_host_vmnic_facts`` has been removed, use ``vmware_host_vmnic_info`` instead. -- vmware_local_role_facts - The deprecated module ``vmware_local_role_facts`` has been removed, use ``vmware_local_role_info`` instead. -- vmware_local_user_facts - The deprecated module ``vmware_local_user_facts`` has been removed, use ``vmware_local_user_info`` instead. -- vmware_portgroup_facts - The deprecated module ``vmware_portgroup_facts`` has been removed, use ``vmware_portgroup_info`` instead. -- vmware_resource_pool_facts - The deprecated module ``vmware_resource_pool_facts`` has been removed, use ``vmware_resource_pool_info`` instead. -- vmware_tag_facts - The deprecated module ``vmware_tag_facts`` has been removed, use ``vmware_tag_info`` instead. -- vmware_target_canonical_facts - The deprecated module ``vmware_target_canonical_facts`` has been removed, use ``vmware_target_canonical_info`` instead. -- vmware_vm_facts - The deprecated module ``vmware_vm_facts`` has been removed, use ``vmware_vm_info`` instead. -- vmware_vmkernel_facts - The deprecated module ``vmware_vmkernel_facts`` has been removed, use ``vmware_vmkernel_info`` instead. -- vmware_vmkernel_ip_config - The deprecated module ``vmware_vmkernel_ip_config`` has been removed, use ``vmware_vmkernel`` instead. -- vmware_vswitch_facts - The deprecated module ``vmware_vswitch_facts`` has been removed, use ``vmware_vswitch_info`` instead. - -Deprecated Features -------------------- - -- The collection ``community.sap`` has been renamed to ``community.sap_libs``. For now both collections are included in Ansible. The content in ``community.sap`` will be replaced with deprecated redirects to the new collection in Ansible 7.0.0, and these redirects will eventually be removed from Ansible. Please update your FQCNs for ``community.sap``. - -Ansible-core -~~~~~~~~~~~~ - -- ansible-core - Remove support for Python 2.6. -- ansible-test - Remove support for Python 2.6. -- ssh connection plugin option scp_if_ssh in favor of ssh_transfer_method. - -amazon.aws -~~~~~~~~~~ - -- ec2_instance - The default value for ```instance_type``` has been deprecated, in the future release you must set an instance_type or a launch_template (https://github.com/ansible-collections/amazon.aws/pull/587). -- module_utils - support for the original AWS SDK `boto` has been deprecated in favour of the `boto3`/`botocore` SDK. All `boto` based modules have either been deprecated or migrated to `botocore`, and the remaining support code in module_utils will be removed in release 4.0.0 of the amazon.aws collection. Any modules outside of the amazon.aws and community.aws collections based on the `boto` library will need to be migrated to the `boto3`/`botocore` libraries (https://github.com/ansible-collections/amazon.aws/pull/575). - -cisco.ios -~~~~~~~~~ - -- Deprecates lldp module. -- ios_acls - Deprecated fragment attribute added boolean alternate as enable_fragment. - -cisco.nxos -~~~~~~~~~~ - -- Deprecated nxos_snmp_community module. -- Deprecated nxos_snmp_contact module. -- Deprecated nxos_snmp_host module. -- Deprecated nxos_snmp_location module. -- Deprecated nxos_snmp_traps module. -- Deprecated nxos_snmp_user module. - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.docker/pull/361). -- The dependency on docker-compose for Execution Environments is deprecated and will be removed in community.docker 3.0.0. The `Python docker-compose library `__ is unmaintained and can cause dependency issues. You can manually still install it in an Execution Environment when needed (https://github.com/ansible-collections/community.docker/pull/373). -- Various modules - the default of ``tls_hostname`` that was supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). -- docker_stack - the return values ``out`` and ``err`` that were supposed to be removed in community.docker 2.0.0 will now be removed in version 3.0.0 (https://github.com/ansible-collections/community.docker/pull/362). - -community.general -~~~~~~~~~~~~~~~~~ - -- ansible_galaxy_install - deprecated support for ``ansible`` 2.9 and ``ansible-base`` 2.10 (https://github.com/ansible-collections/community.general/pull/4601). -- dig lookup plugin - the ``DLV`` record type has been decommissioned in 2017 and support for it will be removed from community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4618). -- gem - the default of the ``norc`` option has been deprecated and will change to ``true`` in community.general 6.0.0. Explicitly specify a value to avoid a deprecation warning (https://github.com/ansible-collections/community.general/pull/4517). -- mail callback plugin - not specifying ``sender`` is deprecated and will be disallowed in community.general 6.0.0 (https://github.com/ansible-collections/community.general/pull/4140). -- module_helper module utils - deprecated the attribute ``ModuleHelper.VarDict`` (https://github.com/ansible-collections/community.general/pull/3801). -- nmcli - deprecate default hairpin mode for a bridge. This so we can change it to ``false`` in community.general 7.0.0, as this is also the default in ``nmcli`` (https://github.com/ansible-collections/community.general/pull/4334). -- pacman - from community.general 5.0.0 on, the ``changed`` status of ``update_cache`` will no longer be ignored if ``name`` or ``upgrade`` is specified. To keep the old behavior, add something like ``register: result`` and ``changed_when: result.packages | length > 0`` to your task (https://github.com/ansible-collections/community.general/pull/4329). -- proxmox inventory plugin - the current default ``true`` of the ``want_proxmox_nodes_ansible_host`` option has been deprecated. The default will change to ``false`` in community.general 6.0.0. To keep the current behavior, explicitly set ``want_proxmox_nodes_ansible_host`` to ``true`` in your inventory configuration. We suggest to already switch to the new behavior by explicitly setting it to ``false``, and by using ``compose:`` to set ``ansible_host`` to the correct value. See the examples in the plugin documentation for details (https://github.com/ansible-collections/community.general/pull/4466). -- vmadm - deprecated module parameter ``debug`` that was not used anywhere (https://github.com/ansible-collections/community.general/pull/4580). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.hashi_vault 3.0.0) next spring (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.hashi_vault/issues/189). -- aws_iam_login auth method - the ``aws_iam_login`` method has been renamed to ``aws_iam``. The old name will be removed in collection version ``3.0.0``. Until then both names will work, and a warning will be displayed when using the old name (https://github.com/ansible-collections/community.hashi_vault/pull/193). -- token_validate options - the shared auth option ``token_validate`` will change its default from ``True`` to ``False`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``True`` (https://github.com/ansible-collections/community.hashi_vault/issues/248). -- token_validate options - the shared auth option ``token_validate`` will change its default from ``true`` to ``false`` in community.hashi_vault version 4.0.0. The ``vault_login`` lookup and module will keep the default value of ``true`` (https://github.com/ansible-collections/community.hashi_vault/issues/248). - -community.network -~~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.network 4.0.0) this spring. While most content will probably still work with ansible-base 2.10, we will remove symbolic links for modules and action plugins, which will make it impossible to use them with Ansible 2.9 anymore. Please use community.network 3.x.y with Ansible 2.9 and ansible-base 2.10, as these releases will continue to support Ansible 2.9 and ansible-base 2.10 even after they are End of Life (https://github.com/ansible-community/community-topics/issues/50, https://github.com/ansible-collections/community.network/pull/382). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module. - -purestorage.flasharray -~~~~~~~~~~~~~~~~~~~~~~ - -- purefa_sso - Deprecated in favor of M(purefa_admin). Will be removed in Collection 2.0 diff --git a/docs/docsite/rst/porting_guides/porting_guide_7.rst b/docs/docsite/rst/porting_guides/porting_guide_7.rst deleted file mode 100644 index d5a94f260eb..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_7.rst +++ /dev/null @@ -1,1152 +0,0 @@ -.. - THIS DOCUMENT IS AUTOMATICALLY GENERATED BY ANTSIBULL! PLEASE DO NOT EDIT MANUALLY! (YOU PROBABLY WANT TO EDIT porting_guide_core_2.14.rst) - -.. _porting_7_guide: - -======================= -Ansible 7 Porting Guide -======================= - -.. contents:: - :local: - :depth: 2 - - -Ansible 7 is based on Ansible-core 2.14. - - -We suggest you read this page along with the `Ansible 7 Changelog `_ to understand what updates you may need to make. - - -Playbook -======== - -* Variables are now evaluated lazily; only when they are actually used. For example, in ansible-core 2.14 an expression ``{{ defined_variable or undefined_variable }}`` does not fail on ``undefined_variable`` if the first part of ``or`` is evaluated to ``True`` as it is not needed to evaluate the second part. One particular case of a change in behavior to note is the task below which uses the ``undefined`` test. Prior to version 2.14 this would result in a fatal error trying to access the undefined value in the dictionary. In 2.14 the assertion passes as the dictionary is evaluated as undefined through one of its undefined values: - - .. code-block:: yaml - - - assert: - that: - - some_defined_dict_with_undefined_values is undefined - vars: - dict_value: 1 - some_defined_dict_with_undefined_values: - key1: value1 - key2: '{{ dict_value }}' - key3: '{{ undefined_dict_value }}' - - -Command Line -============ - -* Python 3.9 on the controller node is a hard requirement for this release. -* At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. If you were previously using the ``C`` or ``POSIX`` locale, you may be able to use ``C.UTF-8``. If you were previously using a locale such as ``en_US.ISO-8859-1``, you may be able to use ``en_US.UTF-8``. For simplicity it may be easiest to export the appropriate locale using the ``LC_ALL`` environment variable. An alternative to modifying your system locale is to run Python in UTF-8 mode; See the `Python documentation `_ for more information. - - -Deprecated -========== - -No notable changes - - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -Porting Guide for v7.4.0 -======================== - -Breaking Changes ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Integration tests which depend on specific file permissions when running in an ansible-test managed host environment may require changes. Tests that require permissions other than ``755`` or ``644`` may need to be updated to set the necessary permissions as part of the test run. - -Major Changes -------------- - -community.hrobot -~~~~~~~~~~~~~~~~ - -- firewall - Hetzner added output rules support to the firewall. This change unfortunately means that using old versions of the firewall module will always set the output rule list to empty, thus disallowing the server to send out packets (https://github.com/ansible-collections/community.hrobot/issues/75, https://github.com/ansible-collections/community.hrobot/pull/76). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Use true/false (lowercase) for boolean values in documentation and examples (https://github.com/ansible-collections/community.vmware/issues/1660). - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Add annotations of member operation for every module. -- Update ``fortios.py`` for higher performance; -- supports temporary session key and pre/post login banner; -- update the examples on how to use member operation in Q&A. - -purestorage.fusion -~~~~~~~~~~~~~~~~~~ - -- Patching of resource properties was brought to parity with underlying Python SDK, meaning the collection can create/update/delete all resource properties the SDK can -- fusion_volume - fixed and reorganized, arguments changed - -Deprecated Features -------------------- - -amazon.aws -~~~~~~~~~~ - -- support for passing both profile and security tokens through a mix of environment variables and parameters has been deprecated and support will be removed in release 6.0.0. After release 6.0.0 it will only be possible to pass either a profile or security tokens, regardless of mechanism used to pass them. To explicitly block a parameter coming from an environment variable pass an empty string as the parameter value. Support for passing profile and security tokens together was originally deprecated in release 1.2.0, however only partially implemented in release 5.0.0 (https://github.com/ansible-collections/amazon.aws/pull/1355). - -community.aws -~~~~~~~~~~~~~ - -- ecs_service - In a release after 2024-06-01, tha default value of ``purge_placement_constraints`` will be change from ``false`` to ``true`` (https://github.com/ansible-collections/community.aws/pull/1716). -- ecs_service - In a release after 2024-06-01, tha default value of ``purge_placement_strategy`` will be change from ``false`` to ``true`` (https://github.com/ansible-collections/community.aws/pull/1716). -- iam_role - All top level return values other than ``iam_role`` and ``changed`` have been deprecated and will be removed in a release after 2023-12-01 (https://github.com/ansible-collections/community.aws/issues/551). -- iam_role - In a release after 2023-12-01 the contents of ``assume_role_policy_document`` will no longer be converted from CamelCase to snake_case. The ``assume_role_policy_document_raw`` return value already returns the policy document in this future format (https://github.com/ansible-collections/community.aws/issues/551). -- iam_role_info - In a release after 2023-12-01 the contents of ``assume_role_policy_document`` will no longer be converted from CamelCase to snake_case. The ``assume_role_policy_document_raw`` return value already returns the policy document in this future format (https://github.com/ansible-collections/community.aws/issues/551). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- hashi_vault lookup - in ``v5.0.0`` duplicate term string options will raise an exception instead of showing a warning (https://github.com/ansible-collections/community.hashi_vault/issues/356). - -purestorage.fusion -~~~~~~~~~~~~~~~~~~ - -- fusion_hw - hardware module is being removed as changing hardware type has never been supported by Pure Storage Fusion -- fusion_info - nigs subset is deprecated in favor of network_interface_groups and will be removed in the version 1.7.0 (https://github.com/Pure-Storage-Ansible/Fusion-Collection/pull/46). -- fusion_info - placements subset is deprecated in favor of placement_groups and will be removed in the version 1.7.0 (https://github.com/Pure-Storage-Ansible/Fusion-Collection/pull/62). -- fusion_pg - placement_engine option is deprecated because Fusion API does not longer support this parameter It will be removed in the version 2.0.0 (https://github.com/Pure-Storage-Ansible/Fusion-Collection/pull/53). -- fusion_se - parameters "addresses", "gateway" and "network_interface_groups" are deprecated in favor of "iscsi" and will be removed in version 2.0.0 -- fusion_tn - tenant networks are being replaced by storage endpoints ```fusion_se``` and Network Interface Groups ```fusion_nig``` - -Porting Guide for v7.3.0 -======================== - -Breaking Changes ----------------- - -hetzner.hcloud -~~~~~~~~~~~~~~ - -- inventory plugin - Python v3.5+ is now required. - -Major Changes -------------- - -kubernetes.core -~~~~~~~~~~~~~~~ - -- refactor K8sAnsibleMixin into module_utils/k8s/ (https://github.com/ansible-collections/kubernetes.core/pull/481). - -Deprecated Features -------------------- - -- Since the google.cloud collection seems to be maintained again, we `cancelled the removal process `__. So contrary to an earlier announcement, this collection is NOT deprecated and will NOT be removed from Ansible 8 (https://github.com/ansible-community/community-topics/issues/105). - -community.general -~~~~~~~~~~~~~~~~~ - -- gitlab_runner - the option ``access_level`` will lose its default value in community.general 8.0.0. From that version on, you have set this option to ``ref_protected`` explicitly, if you want to have a protected runner (https://github.com/ansible-collections/community.general/issues/5925). - -Porting Guide for v7.2.0 -======================== - -Added Collections ------------------ - -- dellemc.powerflex (version 1.5.0) -- dellemc.unity (version 1.5.0) - -Known Issues ------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Additional configuration may be required for certain container host and container combinations. Further details are available in the testing documentation. -- ansible-test - Custom containers with ``VOLUME`` instructions may be unable to start, when previously the containers started correctly. Remove the ``VOLUME`` instructions to resolve the issue. Containers with this condition will cause ``ansible-test`` to emit a warning. -- ansible-test - Systems with Podman networking issues may be unable to run containers, when previously the issue went unreported. Correct the networking issues to continue using ``ansible-test`` with Podman. -- ansible-test - Using Docker on systems with SELinux may require setting SELinux to permissive mode. Podman should work with SELinux in enforcing mode. - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_network - Updated documentation for `local_status_page_enabled` and `remote_status_page_enabled` as these no longer work. - -Breaking Changes ----------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- ModuleHelper module utils - when the module sets output variables named ``msg``, ``exception``, ``output``, ``vars``, or ``changed``, the actual output will prefix those names with ``_`` (underscore symbol) only when they clash with output variables generated by ModuleHelper itself, which only occurs when handling exceptions. Please note that this breaking change does not require a new major release since before this release, it was not possible to add such variables to the output `due to a bug `__ (https://github.com/ansible-collections/community.general/pull/5765). - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- ansible-test - Docker Desktop on WSL2 is now supported (additional configuration required). -- ansible-test - Docker and Podman are now supported on hosts with cgroup v2 unified. Previously only cgroup v1 and cgroup v2 hybrid were supported. -- ansible-test - Podman now works on container hosts without systemd. Previously only some containers worked, while others required rootfull or rootless Podman, but would not work with both. Some containers did not work at all. -- ansible-test - Podman on WSL2 is now supported. -- ansible-test - When additional cgroup setup is required on the container host, this will be automatically detected. Instructions on how to configure the host will be provided in the error message shown. - -ansible.windows -~~~~~~~~~~~~~~~ - -- Set the minimum Ansible version supported by this collection to Ansible 2.12 - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Allow users to select the TLS versions used for bootstrapping Chocolatey installation. - -Deprecated Features -------------------- - -- The cisco.nso collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/155). -- The community.fortios collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/162). -- The community.google collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/160). -- The community.skydive collection is considered unmaintained and will be removed from Ansible 9 if no one starts maintaining it again before Ansible 9. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/171). - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Deprecate side-by-side installs. - -cisco.ios -~~~~~~~~~ - -- ios_bgp_address_family - deprecate neighbors.address/tag/ipv6_adddress with neighbor_address which enables common attributes for facts rendering -- ios_bgp_address_family - deprecate neighbors.password with password_options which allows encryption and password -- ios_bgp_address_family - deprecate slow_peer with slow_peer_options which supports a dict attribute - -community.dns -~~~~~~~~~~~~~ - -- The default of the newly added option ``txt_character_encoding`` will change from ``octal`` to ``decimal`` in community.dns 3.0.0. The new default will be compatible with `RFC 1035 `__ (https://github.com/ansible-collections/community.dns/pull/134). - -community.general -~~~~~~~~~~~~~~~~~ - -- consul - deprecate using parameters unused for ``state=absent`` (https://github.com/ansible-collections/community.general/pull/5772). -- gitlab_runner - the default of the new option ``access_level_on_creation`` will change from ``false`` to ``true`` in community.general 7.0.0. This will cause ``access_level`` to be used during runner registration as well, and not only during updates (https://github.com/ansible-collections/community.general/pull/5908). -- manageiq_policies - deprecate ``state=list`` in favour of using ``community.general.manageiq_policies_info`` (https://github.com/ansible-collections/community.general/pull/5721). -- rax - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cbs - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cbs_attachments - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cdb - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cdb_database - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_cdb_user - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_clb - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_clb_nodes - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_clb_ssl - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_dns - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_dns_record - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_facts - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_files - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_files_objects - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_identity - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_keypair - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_meta - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_alarm - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_check - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_entity - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_notification - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_mon_notification_plan - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_network - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_queue - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_scaling_group - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). -- rax_scaling_policy - module relies on deprecates library ``pyrax``. Unless maintainers step up to work on the module, it will be marked as deprecated in community.general 7.0.0 and removed in version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5733). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- ansible-core - support for ``ansible-core`` versions ``2.11`` and ``2.12`` will be dropped in collection version ``5.0.0``, making ``2.13`` the minimum supported version of ``ansible-core`` (https://github.com/ansible-collections/community.hashi_vault/issues/340). -- hvac - the minimum version of ``hvac`` to be supported in collection version ``5.0.0`` will be at least ``1.0.2``; this minimum may be raised before ``5.0.0`` is released, so please subscribe to the linked issue and look out for new notices in the changelog (https://github.com/ansible-collections/community.hashi_vault/issues/324). - -Porting Guide for v7.1.0 -======================== - -Added Collections ------------------ - -- grafana.grafana (version 1.1.0) - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131). -- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131). - -Major Changes -------------- - -cisco.meraki -~~~~~~~~~~~~ - -- meraki_mr_l7_firewall - New module -- meraki_webhook_payload_template - New module - -community.zabbix -~~~~~~~~~~~~~~~~ - -- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate -- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate - -containers.podman -~~~~~~~~~~~~~~~~~ - -- New become plugin - podman_unshare -- Podman generate systemd module - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2. - -Deprecated Features -------------------- - -community.general -~~~~~~~~~~~~~~~~~ - -- The ``sap`` modules ``sapcar_extract``, ``sap_task_list_execute``, and ``hana_query``, will be removed from this collection in community.general 7.0.0 and replaced with redirects to ``community.sap_libs``. If you want to continue using these modules, make sure to also install ``community.sap_libs`` (it is part of the Ansible package) (https://github.com/ansible-collections/community.general/pull/5614). - -Porting Guide for v7.0.0 -======================== - -Added Collections ------------------ - -- ibm.spectrum_virtualize (version 1.10.0) -- inspur.ispim (version 1.2.0) -- lowlydba.sqlserver (version 1.0.4) -- purestorage.fusion (version 1.1.1) -- vultr.cloud (version 1.3.1) - -Known Issues ------------- - -community.routeros -~~~~~~~~~~~~~~~~~~ - -- The ``community.routeros.command`` module claims to support check mode. Since it cannot judge whether the commands executed modify state or not, this behavior is incorrect. Since this potentially breaks existing playbooks, we will not change this behavior until community.routeros 3.0.0. - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- idrac_user - Issue(192043) The module may error out with the message ``unable to perform the import or export operation because there are pending attribute changes or a configuration job is in progress``. Wait for the job to complete and run the task again. -- ome_application_alerts_smtp - Issue(212310) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_application_alerts_syslog - Issue(215374) - The module does not provide a proper error message if the destination_address is more than 255 characters. -- ome_device_local_access_configuration - Issue(215035) - The module reports ``Successfully updated the local access setting`` if an unsupported value is provided for the parameter timeout_limit. However, this value is not actually applied on OpenManage Enterprise Modular. -- ome_device_local_access_configuration - Issue(217865) - The module does not display a proper error message if an unsupported value is provided for the user_defined and lcd_language parameters. -- ome_device_network_services - Issue(212681) - The module does not provide a proper error message if unsupported values are provided for the parameters- port_number, community_name, max_sessions, max_auth_retries, and idle_timeout. -- ome_device_power_settings - Issue(212679) - The module displays the following message if the value provided for the parameter ``power_cap`` is not within the supported range of 0 to 32767, ``Unable to complete the request because PowerCap does not exist or is not applicable for the resource URI.`` -- ome_device_quick_deploy - Issue(216352) - The module does not display a proper error message if an unsupported value is provided for the ipv6_prefix_length and vlan_id parameters. -- ome_smart_fabric_uplink - Issue(186024) - The module does not allow the creation of multiple uplinks of the same name even though it is supported by OpenManage Enterprise Modular. If an uplink is created using the same name as an existing uplink, the existing uplink is modified. - -netapp.ontap -~~~~~~~~~~~~ - -- na_ontap_snapshot - added documentation to use UTC format for ``expiry_time``. - -Breaking Changes ----------------- - -- Ansible 7 requires Python 3.9 on the controller, same as ansible-core 2.14. - -Ansible-core -~~~~~~~~~~~~ - -- Allow for lazy evaluation of Jinja2 expressions (https://github.com/ansible/ansible/issues/56017) -- The default ansible-galaxy role skeletons no longer contain .travis.yml files. You can configure ansible-galaxy to use a custom role skeleton that contains a .travis.yml file to continue using Galaxy's integration with Travis CI. -- ansible - At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible - Increase minimum Python requirement to Python 3.9 for CLI utilities and controller code -- ansible-test - At startup the filesystem encoding is checked to verify it is UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible-test - At startup the locale is configured as ``en_US.UTF-8``, with a fallback to ``C.UTF-8``. If neither encoding is available the process exits with an error. If the fallback is used, a warning is displayed. In previous versions the ``en_US.UTF-8`` locale was always requested. However, no startup checking was performed to verify the locale was successfully configured. -- ansible-test validate-modules - Removed the ``missing-python-doc`` error code in validate modules, ``missing-documentation`` is used instead for missing PowerShell module documentation. -- strategy plugins - Make ``ignore_unreachable`` to increase ``ignored`` and ``ok`` and counter, not ``skipped`` and ``unreachable``. (https://github.com/ansible/ansible/issues/77690) - -amazon.aws -~~~~~~~~~~ - -- Tags beginning with ``aws:`` will not be removed when purging tags, these tags are reserved by Amazon and may not be updated or deleted (https://github.com/ansible-collections/amazon.aws/issues/817). -- amazon.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/amazon.aws/pull/1087). -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/934). -- amazon.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834). -- aws_az_info - the module alias ``aws_az_facts`` was deprecated in Ansible 2.9 and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/832). -- aws_s3 - the default value for ``ensure overwrite`` has been changed to ``different`` instead of ``always`` so that the module is idempotent by default (https://github.com/ansible-collections/amazon.aws/issues/811). -- aws_ssm - on_denied and on_missing now both default to error, for consistency with both aws_secret and the base Lookup class (https://github.com/ansible-collections/amazon.aws/issues/617). -- doc_fragments - remove minimum collection requirements from doc_fragments/aws.py and allow pulling those from doc_fragments/aws_boto3.py instead (https://github.com/ansible-collections/amazon.aws/pull/985). -- ec2 - The ``ec2`` module has been removed in release 4.0.0 and replaced by the ``ec2_instance`` module (https://github.com/ansible-collections/amazon.aws/pull/630). -- ec2_ami - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_ami - the parameter aliases ``DeviceName``, ``VirtualName`` and ``NoDevice`` were previously deprecated and have been removed, please use ``device_name``, ``virtual_name`` and ``no_device`` instead (https://github.com/ansible-collections/amazon.aws/pull/913). -- ec2_eni_info - the mutual exclusivity of the ``eni_id`` and ``filters`` parameters is now enforced, previously ``filters`` would be ignored if ``eni_id`` was set (https://github.com/ansible-collections/amazon.aws/pull/954). -- ec2_instance - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_key - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vol - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vpc_dhcp_option_info - the parameter aliases ``DhcpOptionIds`` and ``DryRun`` were previously deprecated and have been removed, please use ``dhcp_options_ids`` and ``no_device`` instead (https://github.com/ansible-collections/amazon.aws/pull/913). -- ec2_vpc_endpoint - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vpc_igw_info - The default value for ``convert_tags`` has been changed to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/835). -- ec2_vpc_net - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- ec2_vpc_route_table - the default value for ``purge_tags`` has been changed from ``False`` to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/916). -- elb_classic_lb - the ``ec2_elb`` fact has been removed (https://github.com/ansible-collections/amazon.aws/pull/827). -- module_utils - Support for the original AWS SDK aka ``boto`` has been removed, including all relevant helper functions. All modules should now use the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/amazon.aws/pull/630) -- s3_bucket - the previously deprecated alias ``S3_URL`` for the ``s3_url`` parameter has been removed. Playbooks shuold be updated to use ``s3_url`` (https://github.com/ansible-collections/amazon.aws/pull/908). -- s3_object - the previously deprecated alias ``S3_URL`` for the ``s3_url`` parameter has been removed. Playbooks should be updated to use ``s3_url`` (https://github.com/ansible-collections/amazon.aws/pull/908). - -check_point.mgmt -~~~~~~~~~~~~~~~~ - -- cp_mgmt_access_role - the 'machines' parameter now accepts a single str and a new parameter 'machines_list' of type dict has been added. the 'users' parameter now accepts a single str and a new parameter 'users_list' of type dict has been added. -- cp_mgmt_access_rule - the 'vpn' parameter now accepts a single str and a new parameter 'vpn_list' of type dict has been added. the 'position_by_rule' parameter has been changed to 'relative_position' with support of positioning above/below a section (and not just a rule). the 'relative_position' parameter has also 'top' and 'bottom' suboptions which allows positioning a rule at the top and bottom of a section respectively. a new parameter 'search_entire_rulebase' has been added to allow the relative positioning to be unlimited (was previously limited to 50 rules) -- cp_mgmt_administrator - the 'permissions_profile' parameter now accepts a single str and a new parameter 'permissions_profile_list' of type dict has been added. -- cp_mgmt_publish - the 'uid' parameter has been removed. - -community.aws -~~~~~~~~~~~~~ - -- Tags beginning with ``aws:`` will not be removed when purging tags, these tags are reserved by Amazon and may not be updated or deleted (https://github.com/ansible-collections/amazon.aws/issues/817). -- acm_certificate - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- autoscaling_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group``. -- autoscaling_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group_info``. -- aws_secret - tags are no longer removed when the ``tags`` parameter is not set. To remove all tags set ``tags={}`` (https://github.com/ansible-collections/community.aws/issues/1146). -- cloudfront_distribution - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- cloudtrail - The module has been migrated to the ``amazon.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``. -- cloudwatch_metric_alarm - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatch_metric_alarm``. -- cloudwatchevent_rule - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchevent_rule``. -- cloudwatchlogs_log_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group``. -- cloudwatchlogs_log_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_info``. -- cloudwatchlogs_log_group_metric_filter - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_metric_filter``. -- community.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/community.aws/pull/1541). -- community.aws collection - The ``community.aws`` collection has now dropped support for and any requirements upon the original ``boto`` AWS SDK, and now uses the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/community.aws/pull/898). -- community.aws collection - The community.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/1362). -- community.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834). -- ec2_eip - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip``. -- ec2_eip_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip_info``. -- ec2_vpc_route_table - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table``. -- ec2_vpc_route_table_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_route_table_info``. -- ec2_vpc_vpn - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- elb_application_lb - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb``. -- elb_application_lb_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb_info``. -- elb_instance - the ``ec2_elbs`` fact has been removed, ``updated_elbs`` has been added the return values and includes the same information (https://github.com/ansible-collections/community.aws/pull/1173). -- elb_network_lb - the default value of ``state`` has changed from ``absent`` to ``present`` (https://github.com/ansible-collections/community.aws/pull/1167). -- execute_lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.execute_lambda``. -- iam_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy``. -- iam_policy_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy_info``. -- iam_server_certificate - Passing file names to the ``cert``, ``chain_cert`` and ``key`` parameters has been removed. We recommend using a lookup plugin to read the files instead, see the documentation for an example (https://github.com/ansible-collections/community.aws/pull/1265). -- iam_server_certificate - the default value for the ``dup_ok`` parameter has been changed to ``true``. To preserve the original behaviour explicitly set the ``dup_ok`` parameter to ``false`` (https://github.com/ansible-collections/community.aws/pull/1265). -- iam_user - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user``. -- iam_user_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user_info``. -- kms_key - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key``. -- kms_key - managing the KMS IAM Policy via ``policy_mode`` and ``policy_grant_types`` was previously deprecated and has been removed in favor of the ``policy`` option (https://github.com/ansible-collections/community.aws/pull/1344). -- kms_key - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- kms_key_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key_info``. -- lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda``. -- lambda_alias - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_alias``. -- lambda_event - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_event``. -- lambda_execute - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_execute``. -- lambda_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_info``. -- lambda_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_policy``. -- rds_cluster - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster``. -- rds_cluster_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_info``. -- rds_cluster_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_snapshot``. -- rds_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance``. -- rds_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_info``. -- rds_instance_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_snapshot``. -- rds_option_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group``. -- rds_option_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group_info``. -- rds_param_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_param_group``. -- rds_param_group - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- rds_snapshot_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_snapshot_info``. -- rds_subnet_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_subnet_group``. -- route53 - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53``. -- route53_health_check - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_health_check``. -- route53_health_check - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- route53_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_info``. -- route53_zone - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_zone``. -- route53_zone - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). -- script_inventory_ec2 - The ec2.py inventory script has been moved to a new repository. The script can now be downloaded from https://github.com/ansible-community/contrib-scripts/blob/main/inventory/ec2.py and has been removed from this collection. We recommend migrating from the script to the amazon.aws.ec2 inventory plugin. (https://github.com/ansible-collections/community.aws/pull/898) -- sqs_queue - the previously deprecated default value of ``purge_tags=False`` has been updated to ``purge_tags=True`` (https://github.com/ansible-collections/community.aws/pull/1343). - -community.docker -~~~~~~~~~~~~~~~~ - -- This collection does not work with ansible-core 2.11 on Python 3.12+. Please either upgrade to ansible-core 2.12+, or use Python 3.11 or earlier (https://github.com/ansible-collections/community.docker/pull/271). -- docker_container - ``exposed_ports`` is no longer ignored in ``comparisons``. Before, its value was assumed to be identical with the value of ``published_ports`` (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``log_options`` can no longer be specified when ``log_driver`` is not specified (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``publish_all_ports`` is no longer ignored in ``comparisons`` (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``restart_retries`` can no longer be specified when ``restart_policy`` is not specified (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - ``stop_timeout`` is no longer ignored for idempotency if told to be not ignored in ``comparisons``. So far it defaulted to ``ignore`` there, and setting it to ``strict`` had no effect (https://github.com/ansible-collections/community.docker/pull/422). -- modules and plugins communicating directly with the Docker daemon - when connecting by SSH and not using ``use_ssh_client=true``, reject unknown host keys instead of accepting them. This is only a breaking change relative to older community.docker 3.0.0 pre-releases or with respect to Docker SDK for Python < 6.0.0. Docker SDK for Python 6.0.0 will also include this change (https://github.com/ansible-collections/community.docker/pull/434). - -community.general -~~~~~~~~~~~~~~~~~ - -- newrelic_deployment - ``revision`` is required for v2 API (https://github.com/ansible-collections/community.general/pull/5341). -- scaleway_container_registry_info - no longer replace ``secret_environment_variables`` in the output by ``SENSITIVE_VALUE`` (https://github.com/ansible-collections/community.general/pull/5497). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- auth - the default value for ``token_validate`` has changed from ``true`` to ``false``, as previously announced (https://github.com/ansible-collections/community.hashi_vault/issues/248). -- vault_kv2_get lookup - as previously announced, the default value for ``engine_mount_point`` in the ``vault_kv2_get`` lookup has changed from ``kv`` to ``secret`` (https://github.com/ansible-collections/community.hashi_vault/issues/279). - -community.vmware -~~~~~~~~~~~~~~~~ - -- Removed support for ansible-core version < 2.13.0. -- vmware_dvs_portgroup - Add a new sub-option `inherited` to the `in_traffic_shaping` parameter. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup - Add a new sub-option `inherited` to the `out_traffic_shaping` parameter. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup - Change the type of `net_flow` to string to allow setting it implicitly to inherited or to keep the value as-is. This means you can keep the setting as-is by not defining the parameter, but also that while `true` or `no` still work, `True` or `Off` (uppercase) won't (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup - Remove support for vSphere API less than 6.7. -- vmware_dvs_portgroup - Remove the default for `network_policy` and add a new sub-option `inherited`. This means you can keep the setting as-is by not defining the parameter, but also that you have to define the setting as not `inherited` if you want to override it at the PG level (https://github.com/ansible-collections/community.vmware/pull/1483). -- vmware_dvs_portgroup_info - Remove support for vSphere API less than 6.7. -- vmware_dvswitch - Remove support for vSphere API less than 6.7. -- vmware_dvswitch_uplink_pg - Remove support for vSphere API less than 6.7. -- vmware_guest_boot_manager - Remove default for ``secure_boot_enabled`` parameter (https://github.com/ansible-collections/community.vmware/issues/1461). -- vmware_vm_config_option - Dict item names in result are changed from strings joined with spaces to strings joined with underlines, e.g. `Guest fullname` is changed to `guest_fullname` (https://github.com/ansible-collections/community.vmware/issues/1268). -- vmware_vspan_session - Remove support for vSphere API less than 6.7. - -dellemc.enterprise_sonic -~~~~~~~~~~~~~~~~~~~~~~~~ - -- bgp_af - Add the route_advertise_list dictionary to the argspec to replace the deleted, obsolete advertise_prefix attribute used for SONiC 3.x images on the 1.x branch of this collection. This change corresponds to a SONiC 4.0 OC YANG REST compliance change for the BGP AF REST API. It enables specification of a route map in conjunction with each route advertisement prefix (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/63). -- bgp_af - remove the obsolete 'advertise_prefix' attribute from argspec and config code. This and subsequent co-req replacement with the new route advertise list argument structure require corresponding changes in playbooks previoulsly used for configuring route advertise prefixes for SONiC 3.x images. (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/60) -- bgp_neighbors - Replace the previously defined standalone "bfd" attribute with a bfd dictionary containing multiple attributes. This change corresponds to the revised SONiC 4.x implementation of OC YANG compatible REST APIs. Playbooks previously using the bfd attributes for SONiC 3.x images must be modified for useon SONiC 4.0 images to use the new definition for the bfd attribute argspec structure (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/72). -- bgp_neighbors - Replace, for BGP peer groups, the previously defined standalone "bfd" attribute with a bfd dictionary containing multiple attributes. This change corresponds to the revised SONiC 4.x implementation of OC YANG compatible REST APIs. Playbooks previously using the bfd attributes for SONiC 3.x images must be modified for useon SONiC 4.0 images to use the new definition for the bfd attribute argspec structure (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/81). - -Major Changes -------------- - -Ansible-core -~~~~~~~~~~~~ - -- Move handler processing into new ``PlayIterator`` phase to use the configured strategy (https://github.com/ansible/ansible/issues/65067) -- ansible - At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible - Increase minimum Python requirement to Python 3.9 for CLI utilities and controller code -- ansible-test - At startup the filesystem encoding is checked to verify it is UTF-8. If not, the process exits with an error reporting the errant encoding. -- ansible-test - At startup the locale is configured as ``en_US.UTF-8``, with a fallback to ``C.UTF-8``. If neither encoding is available the process exits with an error. If the fallback is used, a warning is displayed. In previous versions the ``en_US.UTF-8`` locale was always requested. However, no startup checking was performed to verify the locale was successfully configured. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574). -- autoscaling_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group``. -- autoscaling_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group_info``. -- cloudtrail - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``. -- cloudwatch_metric_alarm - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatch_metric_alarm``. -- cloudwatchevent_rule - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchevent_rule``. -- cloudwatchlogs_log_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group``. -- cloudwatchlogs_log_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_info``. -- cloudwatchlogs_log_group_metric_filter - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_metric_filter``. -- ec2_eip - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip``. -- ec2_eip_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip_info``. -- elb_application_lb - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb``. -- elb_application_lb_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.elb_application_lb_info``. -- execute_lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.execute_lambda``. -- iam_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy``. -- iam_policy_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_policy_info``. -- iam_user - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user``. -- iam_user_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.iam_user_info``. -- kms_key - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key``. -- kms_key_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.kms_key_info``. -- lambda - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda``. -- lambda_alias - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_alias``. -- lambda_event - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_event``. -- lambda_execute - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_execute``. -- lambda_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_info``. -- lambda_policy - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.lambda_policy``. -- rds_cluster - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster``. -- rds_cluster_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_info``. -- rds_cluster_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_cluster_snapshot``. -- rds_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance``. -- rds_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_info``. -- rds_instance_snapshot - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_instance_snapshot``. -- rds_option_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group``. -- rds_option_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_option_group_info``. -- rds_param_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_param_group``. -- rds_snapshot_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_snapshot_info``. -- rds_subnet_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.rds_subnet_group``. -- route53 - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53``. -- route53_health_check - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_health_check``. -- route53_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_info``. -- route53_zone - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.route53_zone``. - -arista.eos -~~~~~~~~~~ - -- Remove following EOS dprecated modules -- Use of connection: local and the provider option are no longer valid on any modules in this collection. -- eos_interface -- eos_l2_interface -- eos_l3_interface -- eos_linkagg -- eos_static_route -- eos_vlan - -check_point.mgmt -~~~~~~~~~~~~~~~~ - -- plugins/httpapi/checkpoint - Support for Smart-1 Cloud with new variable 'ansible_cloud_mgmt_id' - -chocolatey.chocolatey -~~~~~~~~~~~~~~~~~~~~~ - -- win_chocolatey - Added bootstrap_script option to allow users to target a script URL for installing Chocolatey on clients. -- win_chocolatey_facts - Added outdated packages list to data returned. - -cisco.asa -~~~~~~~~~ - -- Please use either of the following connection types - network_cli, httpapi or netconf. -- This includes the following modules: -- This release drops support for `connection: local` and provider dictionary. -- This release removes all deprecated plugins that have reached their end-of-life. -- Use of connection: local and the provider option are no longer valid on any modules in this collection. -- asa_acl -- asa_og - -cisco.ios -~~~~~~~~~ - -- Only valid connection types for this collection is network_cli. -- This release drops support for `connection: local` and provider dictionary. - -cisco.iosxr -~~~~~~~~~~~ - -- Only valid connection types for this collection are network_cli and netconf. -- This release drops support for `connection: local` and provider dictionary. - -cisco.nxos -~~~~~~~~~~ - -- Please use either of the following connection types - network_cli, httpapi or netconf. -- This release drops support for `connection: local` and provider dictionary. - -community.aws -~~~~~~~~~~~~~ - -- community.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/956). - -community.docker -~~~~~~~~~~~~~~~~ - -- The collection now contains vendored code from the Docker SDK for Python to talk to the Docker daemon. Modules and plugins using this code no longer need the Docker SDK for Python installed on the machine the module or plugin is running on (https://github.com/ansible-collections/community.docker/pull/398). -- docker_api connection plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/414). -- docker_container - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container - the module was completely rewritten from scratch (https://github.com/ansible-collections/community.docker/pull/422). -- docker_container_exec - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/401). -- docker_container_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/402). -- docker_containers inventory plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/413). -- docker_host_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/403). -- docker_image - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/404). -- docker_image_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/405). -- docker_image_load - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/406). -- docker_login - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/407). -- docker_network - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/408). -- docker_network_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/409). -- docker_plugin - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/429). -- docker_prune - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/410). -- docker_volume - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/411). -- docker_volume_info - no longer uses the Docker SDK for Python. It requires ``requests`` to be installed, and depending on the features used has some more requirements. If the Docker SDK for Python is installed, these requirements are likely met (https://github.com/ansible-collections/community.docker/pull/412). - -community.general -~~~~~~~~~~~~~~~~~ - -- The internal structure of the collection was changed for modules and action plugins. These no longer live in a directory hierarchy ordered by topic, but instead are now all in a single (flat) directory. This has no impact on users *assuming they did not use internal FQCNs*. These will still work, but result in deprecation warnings. They were never officially supported and thus the redirects are kept as a courtsey, and this is not labelled as a breaking change. Note that for example the Ansible VScode plugin started recommending these internal names. If you followed its recommendation, you will now have to change back to the short names to avoid deprecation warnings, and potential errors in the future as these redirects will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5461). -- newrelic_deployment - removed New Relic v1 API, added support for v2 API (https://github.com/ansible-collections/community.general/pull/5341). - -community.mysql -~~~~~~~~~~~~~~~ - -- mysql_db - the ``pipefail`` argument's default value will be changed to ``true`` in community.mysql 4.0.0. If your target machines do not use ``bash`` as a default interpreter, set ``pipefail`` to ``false`` explicitly. However, we strongly recommend setting up ``bash`` as a default and ``pipefail=true`` as it will protect you from getting broken dumps you don't know about (https://github.com/ansible-collections/community.mysql/issues/407). - -community.network -~~~~~~~~~~~~~~~~~ - -- The community.network collection no longer supports Ansible 2.9 and ansible-base 2.10. While we take no active measures to prevent usage, we will remove compatibility code and other compatility measures that will effectively prevent using most content from this collection with Ansible 2.9, and some content of this collection with ansible-base 2.10. Both Ansible 2.9 and ansible-base 2.10 will very soon be End of Life and if you are still using them, you should consider upgrading to ansible-core 2.11 or later as soon as possible (https://github.com/ansible-collections/community.network/pull/426). -- The internal structure of the collection was changed for modules and action plugins. These no longer live in a directory hierarchy ordered by topic, but instead are now all in a single (flat) directory. This has no impact on users *assuming they did not use internal FQCNs*. These will still work, but result in deprecation warnings. They were never officially supported and thus the redirects are kept as a courtsey, and this is not labelled as a breaking change. Note that for example the Ansible VScode plugin started recommending these internal names. If you followed its recommendation, you will now have to change back to the short names to avoid deprecation warnings, and potential errors in the future as these redirects will be removed in community.network 8.0.0 (https://github.com/ansible-collections/community.network/pull/482). - -community.postgresql -~~~~~~~~~~~~~~~~~~~~ - -- postgresql_user - the ``groups`` argument has been deprecated and will be removed in ``community.postgresql 3.0.0``. Please use the ``postgresql_membership`` module to specify group/role memberships instead (https://github.com/ansible-collections/community.postgresql/issues/277). - -dellemc.enterprise_sonic -~~~~~~~~~~~~~~~~~~~~~~~~ - -- Added 'static_routes' module to collection (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/82). -- Added a resource module for NTP support (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/99). -- Added a resource module for support of prefix lists (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/100). -- Updated backend REST API request formats in all applicable modules for compatibility with SONiC 4.x openconfig YANG compliant REST APIs. (https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/53) - -dellemc.openmanage -~~~~~~~~~~~~~~~~~~ - -- Added collection metadata for creating execution environments. -- Refactored the Markdown (MD) files and content for better readability. -- The share parameters are deprecated from the following modules - idrac_network, idrac_timezone_ntp, dellemc_configure_idrac_eventing, dellemc_configure_idrac_services, dellemc_idrac_lc_attributes, dellemc_system_lockdown_mode. -- idrac_bios - The module is enhanced to support clear pending BIOS attributes, reset BIOS to default settings, and configure BIOS attribute using Redfish. -- idrac_boot - Support for configuring the boot settings on iDRAC. -- idrac_redfish_storage_controller - This module is enhanced to support LockVirtualDisk operation. -- idrac_virtual_media - This module allows to configure Remote File Share settings. -- ome_device_group - The module is enhanced to support the removal of devices from a static device group. -- ome_devices - Support for performing device-specific operations on OpenManage Enterprise. - -fortinet.fortimanager -~~~~~~~~~~~~~~~~~~~~~ - -- Fix compatibility issue for ansible 2.9.x and ansible-base 2.10.x. -- Many fixes for Ansible sanity test warnings & errors. -- Support FortiManager Schema 7.2.0 , 98 new modules -- support Ansible changelogs. - -fortinet.fortios -~~~~~~~~~~~~~~~~ - -- Support Diff feature in check_mode. -- Support Fortios 7.2.0. - -infoblox.nios_modules -~~~~~~~~~~~~~~~~~~~~~ - -- Feature for extra layer security , with `cert` and `key` parameters in playbooks for authenticating using certificate and key ``*.pem`` file absolute path `#154 `_ -- Fix to remove issue causing due to template attr in deleting network using Ansible module nios network `#147 `_ -- Update `text` field of TXT Record `#128 `_ -- Update operation using `old_name` and `new_name` for the object with dummy name in `old_name` (which does not exist in system) will not create a new object in the system. An error will be thrown stating the object does not exist in the system `#129 `_ - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Use of connection: local and the provider option are no longer valid on any modules in this collection. - -vyos.vyos -~~~~~~~~~ - -- Use of connection: local and the provider option are no longer valid on any modules in this collection. - -Removed Collections -------------------- - -- servicenow.servicenow (previously included version: 1.0.6) - -Removed Features ----------------- - -Ansible-core -~~~~~~~~~~~~ - -- PlayIterator - remove deprecated ``PlayIterator.ITERATING_*`` and ``PlayIterator.FAILED_*`` -- Remove deprecated ``ALLOW_WORLD_READABLE_TMPFILES`` configuration option (https://github.com/ansible/ansible/issues/77393) -- Remove deprecated ``COMMAND_WARNINGS`` configuration option (https://github.com/ansible/ansible/issues/77394) -- Remove deprecated ``DISPLAY_SKIPPED_HOSTS`` environment variable (https://github.com/ansible/ansible/issues/77396) -- Remove deprecated ``LIBVIRT_LXC_NOSECLABEL`` environment variable (https://github.com/ansible/ansible/issues/77395) -- Remove deprecated ``NETWORK_GROUP_MODULES`` environment variable (https://github.com/ansible/ansible/issues/77397) -- Remove deprecated ``UnsafeProxy`` -- Remove deprecated ``plugin_filters_cfg`` config option from ``default`` section (https://github.com/ansible/ansible/issues/77398) -- Remove deprecated functionality that allows loading cache plugins directly without using ``cache_loader``. -- Remove deprecated functionality that allows subclassing ``DefaultCallback`` without the corresponding ``doc_fragment``. -- Remove deprecated powershell functions ``Load-CommandUtils`` and ``Import-PrivilegeUtil`` -- apt_key - remove deprecated ``key`` module param -- command/shell - remove deprecated ``warn`` module param -- get_url - remove deprecated ``sha256sum`` module param -- import_playbook - remove deprecated functionality that allows providing additional parameters in free form - -amazon.aws -~~~~~~~~~~ - -- cloudformation - the ``template_format`` option has been removed. It has been ignored by the module since Ansible 2.3 (https://github.com/ansible-collections/amazon.aws/pull/833). -- ec2_key - the ``wait_timeout`` option had no effect, was deprecated in release 1.0.0, and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/830). -- ec2_key - the ``wait`` option had no effect, was deprecated in release 1.0.0, and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/830). -- ec2_tag - the previously deprecated state ``list`` has been removed. To list tags on an EC2 resource the ``ec2_tag_info`` module can be used (https://github.com/ansible-collections/amazon.aws/pull/829). -- ec2_vol - the previously deprecated state ``list`` has been removed. To list volumes the ``ec2_vol_info`` module can be used (https://github.com/ansible-collections/amazon.aws/pull/828). -- module_utils.batch - the class ``ansible_collections.amazon.aws.plugins.module_utils.batch.AWSConnection`` has been removed. Please use ``AnsibleAWSModule.client()`` instead (https://github.com/ansible-collections/amazon.aws/pull/831). - -ansible.netcommon -~~~~~~~~~~~~~~~~~ - -- napalm - Removed unused connection plugin. -- net_banner - Use _banner instead. -- net_interface - Use _interfaces instead. -- net_l2_interface - Use _l2_interfaces instead. -- net_l3_interface - Use _l3_interfaces instead. -- net_linkagg - Use _lag_interfaces instead. -- net_lldp - Use _lldp_global instead. -- net_lldp_interface - Use _lldp_interfaces instead. -- net_logging - Use _logging_global instead. -- net_static_route - Use _static_routes instead. -- net_system - Use _system instead. -- net_user - Use _user instead. -- net_vlan - Use _vlans instead. -- net_vrf - Use _vrf instead. - -cisco.ios -~~~~~~~~~ - -- ios_interface - use ios_interfaces instead. -- ios_l2_interface - use ios_l2_interfaces instead. -- ios_l3_interface - use ios_l3_interfaces instead. -- ios_static_route - use ios_static_routes instead. -- ios_vlan - use ios_vlans instead. - -cisco.iosxr -~~~~~~~~~~~ - -- iosxr_interface - use iosxr_interfaces instead. - -cisco.nxos -~~~~~~~~~~ - -- This release removes the following deprecated plugins that have reached their end-of-life. -- nxos_acl -- nxos_acl_interface -- nxos_interface -- nxos_interface_ospf -- nxos_l2_interface -- nxos_l3_interface -- nxos_linkagg -- nxos_lldp -- nxos_ospf -- nxos_ospf_vrf -- nxos_smu -- nxos_static_route -- nxos_vlan - -community.aws -~~~~~~~~~~~~~ - -- aws_kms_info - the unused and deprecated ``keys_attr`` parameter has been removed (https://github.com/ansible-collections/amazon.aws/pull/1172). -- data_pipeline - the ``version`` option has always been ignored and has been removed (https://github.com/ansible-collections/community.aws/pull/1160" -- ec2_eip - The ``wait_timeout`` option has been removed. It has always been ignored by the module (https://github.com/ansible-collections/community.aws/pull/1159). -- ec2_lc - the ``associate_public_ip_address`` option has been removed. It has always been ignored by the module (https://github.com/ansible-collections/community.aws/pull/1158). -- ec2_metric_alarm - support for using the ``<=``, ``<``, ``>`` and ``>=`` operators for comparison has been dropped. Please use ``LessThanOrEqualToThreshold``, ``LessThanThreshold``, ``GreaterThanThreshold`` or ``GreaterThanOrEqualToThreshold`` instead (https://github.com/ansible-collections/amazon.aws/pull/1164). -- ecs_ecr - The deprecated alias ``delete_policy`` has been removed. Please use ``purge_policy`` instead (https://github.com/ansible-collections/community.aws/pull/1161). -- iam_managed_policy - the unused ``fail_on_delete`` parameter has been removed (https://github.com/ansible-collections/community.aws/pull/1168) -- s3_lifecycle - the unused parameter ``requester_pays`` has been removed (https://github.com/ansible-collections/community.aws/pull/1165). -- s3_sync - remove unused ``retries`` parameter (https://github.com/ansible-collections/community.aws/pull/1166). - -community.azure -~~~~~~~~~~~~~~~ - -- azure_rm_aks_facts, azure_rm_aks_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_aks_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_aksversion_facts, azure_rm_aksversion_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_aksversion_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_applicationsecuritygroup_facts, azure_rm_applicationsecuritygroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_applicationsecuritygroup_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_appserviceplan_facts, azure_rm_appserviceplan_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_appserviceplan_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_automationaccount_facts, azure_rm_automationaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_automationaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_autoscale_facts, azure_rm_autoscale_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_autoscale_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_availabilityset_facts, azure_rm_availabilityset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_availabilityset_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_cdnendpoint_facts, azure_rm_cdnendpoint_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cdnendpoint_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_cdnprofile_facts, azure_rm_cdnprofile_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cdnprofile_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_containerinstance_facts, azure_rm_containerinstance_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_containerinstance_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_containerregistry_facts, azure_rm_containerregistry_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_containerregistry_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_cosmosdbaccount_facts, azure_rm_cosmosdbaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_cosmosdbaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_deployment_facts, azure_rm_deployment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_deployment_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlab_facts, azure_rm_devtestlab_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlab_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabarmtemplate_facts, azure_rm_devtestlabarmtemplate_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabarmtemplate_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabartifact_facts, azure_rm_devtestlabartifact_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabartifact_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabartifactsource_facts, azure_rm_devtestlabartifactsource_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabartifactsource_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabcustomimage_facts, azure_rm_devtestlabcustomimage_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabcustomimage_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabenvironment_facts, azure_rm_devtestlabenvironment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabenvironment_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabpolicy_facts, azure_rm_devtestlabpolicy_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabpolicy_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabschedule_facts, azure_rm_devtestlabschedule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabschedule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabvirtualmachine_facts, azure_rm_devtestlabvirtualmachine_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabvirtualmachine_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_devtestlabvirtualnetwork_facts, azure_rm_devtestlabvirtualnetwork_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_devtestlabvirtualnetwork_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_dnsrecordset_facts, azure_rm_dnsrecordset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_dnsrecordset_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_dnszone_facts, azure_rm_dnszone_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_dnszone_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_functionapp_facts, azure_rm_functionapp_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_functionapp_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_hdinsightcluster_facts, azure_rm_hdinsightcluster_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_hdinsightcluster_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_image_facts, azure_rm_image_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_image_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_loadbalancer_facts, azure_rm_loadbalancer_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_loadbalancer_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_lock_facts, azure_rm_lock_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_lock_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_loganalyticsworkspace_facts, azure_rm_loganalyticsworkspace_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_loganalyticsworkspace_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_managed_disk, azure_rm_manageddisk - the deprecated modules have been removed. Use azure.azcollection.azure_rm_manageddisk instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_managed_disk_facts, azure_rm_manageddisk_facts, azure_rm_manageddisk_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_manageddisk_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbconfiguration_facts, azure_rm_mariadbconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbdatabase_facts, azure_rm_mariadbdatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbdatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbfirewallrule_facts, azure_rm_mariadbfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mariadbserver_facts, azure_rm_mariadbserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mariadbserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqlconfiguration_facts, azure_rm_mysqlconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqldatabase_facts, azure_rm_mysqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqlfirewallrule_facts, azure_rm_mysqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_mysqlserver_facts, azure_rm_mysqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_mysqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_networkinterface_facts, azure_rm_networkinterface_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_networkinterface_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqlconfiguration_facts, azure_rm_postgresqlconfiguration_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlconfiguration_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqldatabase_facts, azure_rm_postgresqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqlfirewallrule_facts, azure_rm_postgresqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_postgresqlserver_facts, azure_rm_postgresqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_postgresqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_publicipaddress_facts, azure_rm_publicipaddress_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_publicipaddress_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_rediscache_facts, azure_rm_rediscache_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_rediscache_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_resource_facts, azure_rm_resource_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_resource_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_resourcegroup_facts, azure_rm_resourcegroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_resourcegroup_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_roleassignment_facts, azure_rm_roleassignment_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_roleassignment_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_roledefinition_facts, azure_rm_roledefinition_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_roledefinition_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_routetable_facts, azure_rm_routetable_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_routetable_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_securitygroup_facts, azure_rm_securitygroup_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_securitygroup_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_servicebus_facts, azure_rm_servicebus_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_servicebus_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_sqldatabase_facts, azure_rm_sqldatabase_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqldatabase_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_sqlfirewallrule_facts, azure_rm_sqlfirewallrule_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqlfirewallrule_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_sqlserver_facts, azure_rm_sqlserver_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_sqlserver_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_storageaccount_facts, azure_rm_storageaccount_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_storageaccount_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_subnet_facts, azure_rm_subnet_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_subnet_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_trafficmanagerendpoint_facts, azure_rm_trafficmanagerendpoint_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_trafficmanagerendpoint_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_trafficmanagerprofile_facts, azure_rm_trafficmanagerprofile_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_trafficmanagerprofile_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_extension, azure_rm_virtualmachineextension - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineextension instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_facts, azure_rm_virtualmachine_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachine_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_scaleset, azure_rm_virtualmachinescaleset - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescaleset instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachine_scaleset_facts, azure_rm_virtualmachinescaleset_facts, azure_rm_virtualmachinescaleset_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescaleset_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachineextension_facts, azure_rm_virtualmachineextension_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineextension_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachineimage_facts, azure_rm_virtualmachineimage_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachineimage_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachinescalesetextension_facts, azure_rm_virtualmachinescalesetextension_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescalesetextension_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualmachinescalesetinstance_facts, azure_rm_virtualmachinescalesetinstance_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualmachinescalesetinstance_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualnetwork_facts, azure_rm_virtualnetwork_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualnetwork_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_virtualnetworkpeering_facts, azure_rm_virtualnetworkpeering_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_virtualnetworkpeering_info instead (https://github.com/ansible-collections/community.azure/pull/31). -- azure_rm_webapp_facts, azure_rm_webapp_info - the deprecated modules have been removed. Use azure.azcollection.azure_rm_webapp_info instead (https://github.com/ansible-collections/community.azure/pull/31). - -community.docker -~~~~~~~~~~~~~~~~ - -- Execution Environments built with community.docker no longer include docker-compose < 2.0.0. If you need to use it with the ``docker_compose`` module, please install that requirement manually (https://github.com/ansible-collections/community.docker/pull/400). -- Support for Ansible 2.9 and ansible-base 2.10 has been removed. If you need support for Ansible 2.9 or ansible-base 2.10, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400). -- Support for Docker API versions 1.20 to 1.24 has been removed. If you need support for these API versions, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400). -- Support for Python 2.6 has been removed. If you need support for Python 2.6, please use community.docker 2.x.y (https://github.com/ansible-collections/community.docker/pull/400). -- Various modules - the default of ``tls_hostname`` (``localhost``) has been removed. If you want to continue using ``localhost``, you need to specify it explicitly (https://github.com/ansible-collections/community.docker/pull/363). -- docker_container - the ``all`` value is no longer allowed in ``published_ports``. Use ``publish_all_ports=true`` instead (https://github.com/ansible-collections/community.docker/pull/399). -- docker_container - the default of ``command_handling`` was changed from ``compatibility`` to ``correct``. Older versions were warning for every invocation of the module when this would result in a change of behavior (https://github.com/ansible-collections/community.docker/pull/399). -- docker_stack - the return values ``out`` and ``err`` have been removed. Use ``stdout`` and ``stderr`` instead (https://github.com/ansible-collections/community.docker/pull/363). - -community.general -~~~~~~~~~~~~~~~~~ - -- bitbucket* modules - ``username`` is no longer an alias of ``workspace``, but of ``user`` (https://github.com/ansible-collections/community.general/pull/5326). -- gem - the default of the ``norc`` option changed from ``false`` to ``true`` (https://github.com/ansible-collections/community.general/pull/5326). -- gitlab_group_members - ``gitlab_group`` must now always contain the full path, and no longer just the name or path (https://github.com/ansible-collections/community.general/pull/5326). -- keycloak_authentication - the return value ``flow`` has been removed. Use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/5326). -- keycloak_group - the return value ``group`` has been removed. Use ``end_state`` instead (https://github.com/ansible-collections/community.general/pull/5326). -- lxd_container - the default of the ``ignore_volatile_options`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/5326). -- mail callback plugin - the ``sender`` option is now required (https://github.com/ansible-collections/community.general/pull/5326). -- module_helper module utils - remove the ``VarDict`` attribute from ``ModuleHelper``. Import ``VarDict`` from ``ansible_collections.community.general.plugins.module_utils.mh.mixins.vars`` instead (https://github.com/ansible-collections/community.general/pull/5326). -- proxmox inventory plugin - the default of the ``want_proxmox_nodes_ansible_host`` option changed from ``true`` to ``false`` (https://github.com/ansible-collections/community.general/pull/5326). -- vmadm - the ``debug`` option has been removed. It was not used anyway (https://github.com/ansible-collections/community.general/pull/5326). - -community.network -~~~~~~~~~~~~~~~~~ - -- aireos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aireos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- aruba modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ce modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- enos modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- ironware modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``connection: local`` support. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). -- sros modules - removed deprecated ``provider`` option. Use ``connection: network_cli`` instead (https://github.com/ansible-collections/community.network/pull/440). - -community.vmware -~~~~~~~~~~~~~~~~ - -- vca_fw - The deprecated module ``vca_fw`` has been removed. -- vca_nat - The deprecated module ``vca_nat`` has been removed. -- vca_vapp - The deprecated module ``vca_vapp`` has been removed. -- vmware_dns_config - The deprecated module ``vmware_dns_config`` has been removed, you can use ``vmware_host_dns`` instead. -- vmware_guest_network - The deprecated parameter ``networks`` has been removed, use loops to handle multiple interfaces (https://github.com/ansible-collections/community.vmware/pull/1459). -- vmware_guest_vnc - The deprecated module ``vmware_guest_vnc`` has been removed. The VNC support has been dropped with vSphere 7 and later (https://github.com/ansible-collections/community.vmware/pull/1454). -- vmware_host_firewall_manager - The module doesn't accept a list for ``allowed_hosts`` anymore, use a dict instead. Additionally, ``all_ip`` is now a required sub-option of ``allowed_hosts`` (https://github.com/ansible-collections/community.vmware/pull/1463). -- vsphere_copy - The deprecated parameters ``host`` and ``login`` have been removed. Use ``hostname`` and ``username`` instead (https://github.com/ansible-collections/community.vmware/pull/1456). - -junipernetworks.junos -~~~~~~~~~~~~~~~~~~~~~ - -- Remove following deprecated Junos Modules. -- junos_interface -- junos_l2_interface -- junos_l3_interface -- junos_linkagg -- junos_lldp -- junos_lldp_interface -- junos_static_route -- junos_vlan - -vyos.vyos -~~~~~~~~~ - -- vyos_interface - use vyos_interfaces instead. -- vyos_l3_interface - use vyos_l3_interfaces instead. -- vyos_linkagg - use vyos_lag_interfaces instead. -- vyos_lldp - use vyos_lldp_global instead. -- vyos_lldp_interface - use vyos_lldp_interfaces instead. -- vyos_static_route - use vyos_static_routes instead. - -Deprecated Features -------------------- - -- The dellemc.os10 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/134). -- The dellemc.os6 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/132). -- The dellemc.os9 collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/133). -- The google.cloud collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/105). -- The mellanox.onyx collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works `__ (https://github.com/ansible-community/community-topics/issues/136). - -Ansible-core -~~~~~~~~~~~~ - -- Deprecate ability of lookup plugins to return arbitrary data. Lookup plugins must return lists, failing to do so will be an error in 2.18. (https://github.com/ansible/ansible/issues/77788) -- Encryption - Deprecate use of the Python crypt module due to it's impending removal from Python 3.13 -- PlayContext.verbosity is deprecated and will be removed in 2.18. Use ansible.utils.display.Display().verbosity as the single source of truth. -- ``DEFAULT_FACT_PATH``, ``DEFAULT_GATHER_SUBSET`` and ``DEFAULT_GATHER_TIMEOUT`` are deprecated and will be removed in 2.18. Use ``module_defaults`` keyword instead. -- ``PlayIterator`` - deprecate ``cache_block_tasks`` and ``get_original_task`` which are noop and unused. -- ``Templar`` - deprecate ``shared_loader_obj`` option which is unused. ``ansible.plugins.loader`` is used directly instead. -- listify_lookup_plugin_terms, deprecate 'loader/dataloader' parameter as it not used. -- vars plugins - determining whether or not to run ansible.legacy vars plugins with the class attribute REQUIRES_WHITELIST is deprecated, set REQUIRES_ENABLED instead. - -amazon.aws -~~~~~~~~~~ - -- amazon.aws collection - Support for the ``EC2_ACCESS_KEY`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``access_key`` parameter or ``AWS_ACCESS_KEY_ID`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_REGION`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``region`` parameter or ``AWS_REGION`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_SECRET_KEY`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``secret_key`` parameter or ``AWS_SECRET_ACCESS_KEY`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_SECURITY_TOKEN`` environment variable has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` parameter or ``AWS_SESSION_TOKEN`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - Support for the ``EC2_URL`` and ``S3_URL`` environment variables has been deprecated and will be removed in a release after 2024-12-01. Please use the ``endpoint_url`` parameter or ``AWS_ENDPOINT_URL`` environment variable instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``access_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``aws_security_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``ec2_access_key`` alias for the ``access_key`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``access_key`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``ec2_region`` alias for the ``region`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``region`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``ec2_secret_key`` alias for the ``secret_key`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``secret_key`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - The ``security_token`` alias for the ``session_token`` parameter has been deprecated and will be removed in a release after 2024-12-01. Please use the ``session_token`` name instead (https://github.com/ansible-collections/amazon.aws/pull/1172). -- amazon.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in a release after 2023-05-31 (https://github.com/ansible-collections/amazon.aws/pull/935). -- aws_s3 - The ``S3_URL`` alias for the s3_url option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - The ``DeviceName`` alias for the device_name option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - The ``NoDevice`` alias for the no_device option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - The ``VirtualName`` alias for the virtual_name option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_ami - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_instance - The default value for ```instance_type``` has been deprecated, in the future release you must set an instance_type or a launch_template (https://github.com/ansible-collections/amazon.aws/pull/587). -- ec2_instance - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/849). -- ec2_key - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_security_group - support for passing nested lists to ``cidr_ip`` and ``cidr_ipv6`` has been deprecated. Nested lists can be passed through the ``flatten`` filter instead ``cidr_ip: '{{ my_cidrs | flatten }}'`` (https://github.com/ansible-collections/amazon.aws/pull/1213). -- ec2_vol - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_vpc_dhcp_option_info - The ``DhcpOptionIds`` alias for the dhcp_option_ids option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_vpc_dhcp_option_info - The ``DryRun`` alias for the dry_run option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- ec2_vpc_endpoint - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- ec2_vpc_net - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/848). -- ec2_vpc_route_table - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True`` (https://github.com/ansible-collections/amazon.aws/pull/846). -- inventory/aws_ec2 - the ``include_extra_api_calls`` is now deprecated, its value is silently ignored (https://github.com/ansible-collections/amazon.aws/pull/1097). -- module_utils.cloud - removal of the ``CloudRetry.backoff`` has been delayed until release 6.0.0. It is recommended to update custom modules to use ``jittered_backoff`` or ``exponential_backoff`` instead (https://github.com/ansible-collections/amazon.aws/pull/951). -- module_utils.url - ``ansible_collections.amazon.aws.module_utils.urls`` is believed to be unused and has been deprecated and will be removed in release 7.0.0. -- s3_bucket - The ``S3_URL`` alias for the s3_url option has been deprecated and will be removed in release 5.0.0 (https://github.com/ansible-collections/community.aws/pull/795). -- s3_object - Support for creation and deletion of S3 buckets has been deprecated. Please use the ``amazon.aws.s3_bucket`` module to create and delete buckets (https://github.com/ansible-collections/amazon.aws/pull/869). - -cisco.ios -~~~~~~~~~ - -- Deprecated ios_linkagg_module in favor of ios_lag_interfaces. - -cisco.mso -~~~~~~~~~ - -- The mso_schema_template_contract_filter contract_filter_type attribute is deprecated. The value is now deduced from filter_type. - -community.aws -~~~~~~~~~~~~~ - -- aws_acm - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- aws_codebuild - The ``tags`` parameter currently uses a non-standard format and has been deprecated. In release 6.0.0 this parameter will accept a simple key/value pair dictionary instead of the current list of dictionaries. It is recommended to migrate to using the resource_tags parameter which already accepts the simple dictionary format (https://github.com/ansible-collections/community.aws/pull/1221). -- aws_glue_connection - the ``connection_parameters`` return key has been deprecated and will be removed in a release after 2024-06-01, it is being replaced by the ``raw_connection_parameters`` key (https://github.com/ansible-collections/community.aws/pull/518). -- aws_kms - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- cloudfront_distribution - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- community.aws collection - due to the AWS SDKs announcing the end of support for Python less than 3.7 (https://aws.amazon.com/blogs/developer/python-support-policy-updates-for-aws-sdks-and-tools/) support for Python less than 3.7 by this collection has been deprecated and will be removed in a release after 2023-05-31 (https://github.com/ansible-collections/community.aws/pull/1361). -- ec2_vpc_vpn - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- iam_policy - the ``policies`` return value has been renamed ``policy_names`` and will be removed in a release after 2024-08-01, both values are currently returned (https://github.com/ansible-collections/community.aws/pull/1375). -- lambda_info - The ``function`` return key returns a dictionary of dictionaries and has been deprecated. In a release after 2025-01-01, this key will be removed in favor of ``functions``, which returns a list of dictionaries (https://github.com/ansible-collections/community.aws/pull/1239). -- rds_param_group - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- route53_health_check - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- route53_info - The CamelCase return values for ``DelegationSets``, ``CheckerIpRanges``, and ``HealthCheck`` have been deprecated, in the future release you must use snake_case return values ``delegation_sets``, ``checker_ip_ranges``, and ``health_check`` instead respectively" (https://github.com/ansible-collections/community.aws/pull/1322). -- route53_info - The CamelCase return values for ``HostedZones``, ``ResourceRecordSets``, and ``HealthChecks`` have been deprecated, in the future release you must use snake_case return values ``hosted_zones``, ``resource_record_sets``, and ``health_checks`` instead respectively". -- route53_zone - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. -- sqs_queue - the current default value of ``False`` for ``purge_tags`` has been deprecated and will be updated in release 5.0.0 to ``True``. - -community.crypto -~~~~~~~~~~~~~~~~ - -- Support for Ansible 2.9 and ansible-base 2.10 is deprecated, and will be removed in the next major release (community.crypto 3.0.0). Some modules might still work with these versions afterwards, but we will no longer keep compatibility code that was needed to support them (https://github.com/ansible-collections/community.crypto/pull/460). - -community.docker -~~~~~~~~~~~~~~~~ - -- Support for Docker API version 1.20 to 1.24 has been deprecated and will be removed in community.docker 3.0.0. The first Docker version supporting API version 1.25 was Docker 1.13, released in January 2017. This affects the modules ``docker_container``, ``docker_container_exec``, ``docker_container_info``, ``docker_compose``, ``docker_login``, ``docker_image``, ``docker_image_info``, ``docker_image_load``, ``docker_host_info``, ``docker_network``, ``docker_network_info``, ``docker_node_info``, ``docker_swarm_info``, ``docker_swarm_service``, ``docker_swarm_service_info``, ``docker_volume_info``, and ``docker_volume``, whose minimally supported API version is between 1.20 and 1.24 (https://github.com/ansible-collections/community.docker/pull/396). -- Support for Python 2.6 is deprecated and will be removed in the next major release (community.docker 3.0.0). Some modules might still work with Python 2.6, but we will no longer try to ensure compatibility (https://github.com/ansible-collections/community.docker/pull/388). -- docker_container - the ``ignore_image`` option is deprecated and will be removed in community.docker 4.0.0. Use ``image: ignore`` in ``comparisons`` instead (https://github.com/ansible-collections/community.docker/pull/487). -- docker_container - the ``purge_networks`` option is deprecated and will be removed in community.docker 4.0.0. Use ``networks: strict`` in ``comparisons`` instead, and make sure to provide ``networks``, with value ``[]`` if all networks should be removed (https://github.com/ansible-collections/community.docker/pull/487). - -community.general -~~~~~~~~~~~~~~~~~ - -- ArgFormat module utils - deprecated along ``CmdMixin``, in favor of the ``cmd_runner_fmt`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdMixin module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- CmdStateModuleHelper module utils - deprecated in favor of the ``CmdRunner`` module util (https://github.com/ansible-collections/community.general/pull/5370). -- cmd_runner module utils - deprecated ``fmt`` in favour of ``cmd_runner_fmt`` as the parameter format object (https://github.com/ansible-collections/community.general/pull/4777). -- django_manage - support for Django releases older than 4.1 has been deprecated and will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - support for the commands ``cleanup``, ``syncdb`` and ``validate`` that have been deprecated in Django long time ago will be removed in community.general 9.0.0 (https://github.com/ansible-collections/community.general/pull/5400). -- django_manage - the behavior of "creating the virtual environment when missing" is being deprecated and will be removed in community.general version 9.0.0 (https://github.com/ansible-collections/community.general/pull/5405). -- gconftool2 - deprecates ``state=get`` in favor of using the module ``gconftool2_info`` (https://github.com/ansible-collections/community.general/pull/4778). -- lxc_container - the module will no longer make any effort to support Python 2 (https://github.com/ansible-collections/community.general/pull/5304). -- newrelic_deployment - ``appname`` and ``environment`` are no longer valid options in the v2 API. They will be removed in community.general 7.0.0 (https://github.com/ansible-collections/community.general/pull/5341). -- proxmox - deprecated the current ``unprivileged`` default value, will be changed to ``true`` in community.general 7.0.0 (https://github.com/pull/5224). -- xfconf - deprecated parameter ``disable_facts``, as since version 4.0.0 it only allows value ``true`` (https://github.com/ansible-collections/community.general/pull/4520). - -community.hashi_vault -~~~~~~~~~~~~~~~~~~~~~ - -- vault_kv2_get lookup - the ``engine_mount_point option`` in the ``vault_kv2_get`` lookup only will change its default from ``kv`` to ``secret`` in community.hashi_vault version 4.0.0 (https://github.com/ansible-collections/community.hashi_vault/issues/279). diff --git a/docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst b/docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst deleted file mode 100644 index 275de7250ef..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst +++ /dev/null @@ -1,92 +0,0 @@ - -.. _porting_2.10_guide_base: - -******************************* -Ansible-base 2.10 Porting Guide -******************************* - -.. warning:: - - In preparation for the release of 2.10, many plugins and modules have migrated to Collections on `Ansible Galaxy `_. For the current development status of Collections and FAQ see `Ansible Collections Community Guide `_. We expect the 2.10 Porting Guide to change frequently up to the 2.10 release. Follow the conversations about collections on our various :ref:`communication` channels for the latest information on the status of the ``devel`` branch. - -This section discusses the behavioral changes between Ansible 2.9 and Ansible-base 2.10. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible-base. - -We suggest you read this page along with the `Ansible-base Changelog for 2.10 `_ to understand what updates you may need to make. - -Ansible-base is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install ansible. - -The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - - -Playbook -======== - -* Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean - Example: ``diff: yes-`` was returning ``False``. -* A new fact, ``ansible_processor_nproc`` reflects the number of vcpus - available to processes (falls back to the number of vcpus available to - the scheduler). - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth is being shut down. Publishing roles or - collections to Galaxy through ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI through a token file (default location - ``~/.ansible/galaxy_token``) or (insecurely) through the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -* Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`. - - -Modules -======= - -.. warning:: - - Links on this page may not point to the most recent versions of modules. We will update them when we can. - -* Version 2.10.0 of ansible-base changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.10.1, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible. -* If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1. -* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it. - -* ``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task. - - -Noteworthy module changes -------------------------- - -* Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves. -* Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``. - - -Plugins -======= - -Lookup plugin names case-sensitivity ------------------------------------- - -* Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked through ``with_``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive. - -Noteworthy plugin changes -------------------------- - -* Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching. -* Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``. - -Action plugins which execute modules should use fully-qualified module names ----------------------------------------------------------------------------- - -* Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended. - -Porting custom scripts -====================== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.11.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.11.rst deleted file mode 100644 index e55482e53ad..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.11.rst +++ /dev/null @@ -1,136 +0,0 @@ - -.. _porting_2.11_guide_core: - -******************************* -Ansible-core 2.11 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-base`` 2.10 and ``ansible-core`` 2.11. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they work with this version of ``ansible-core``. - -We suggest you read this page along with the `ansible-core Changelog for 2.11 `_ to understand what updates you may need to make. - -``ansible-core`` is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install Ansible. - -The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: - -Playbook -======== - -* The ``jinja2_native`` setting now does not affect the template module which implicitly returns strings. For the template lookup there is a new argument ``jinja2_native`` (off by default) to control that functionality. The rest of the Jinja2 expressions still operate based on the ``jinja2_native`` setting. - - -Command Line -============ - -* The ``ansible-galaxy login`` command has been removed, as the underlying API it used for GitHub auth has been shut down. Publishing roles or collections to Galaxy with ``ansible-galaxy`` now requires that a Galaxy API token be passed to the CLI using a token file (default location ``~/.ansible/galaxy_token``) or (insecurely) with the ``--token`` argument to ``ansible-galaxy``. - - -Deprecated -========== - -The constant ``ansible.module_utils.basic._CHECK_ARGUMENT_TYPES_DISPATCHER`` is deprecated. Use :const:`ansible.module_utils.common.parameters.DEFAULT_TYPE_VALIDATORS` instead. - - -Breaking Changes -================ - -Changes to ``AnsibleModule`` ----------------------------- - -With the move to :class:`ArgumentSpecValidator ` for performing argument spec validation, the following private methods in :class:`AnsibleModule ` have been removed: - - - ``_check_argument_types()`` - - ``_check_argument_values()`` - - ``_check_arguments()`` - - ``_check_mutually_exclusive()`` --> :func:`ansible.module_utils.common.validation.check_mutually_exclusive` - - ``_check_required_arguments()`` --> :func:`ansible.module_utils.common.validation.check_required_arguments` - - ``_check_required_by()`` --> :func:`ansible.module_utils.common.validation.check_required_by` - - ``_check_required_if()`` --> :func:`ansible.module_utils.common.validation.check_required_if` - - ``_check_required_one_of()`` --> :func:`ansible.module_utils.common.validation.check_required_one_of` - - ``_check_required_together()`` --> :func:`ansible.module_utils.common.validation.check_required_together` - - ``_check_type_bits()`` --> :func:`ansible.module_utils.common.validation.check_type_bits` - - ``_check_type_bool()`` --> :func:`ansible.module_utils.common.validation.check_type_bool` - - ``_check_type_bytes()`` --> :func:`ansible.module_utils.common.validation.check_type_bytes` - - ``_check_type_dict()`` --> :func:`ansible.module_utils.common.validation.check_type_dict` - - ``_check_type_float()`` --> :func:`ansible.module_utils.common.validation.check_type_float` - - ``_check_type_int()`` --> :func:`ansible.module_utils.common.validation.check_type_int` - - ``_check_type_jsonarg()`` --> :func:`ansible.module_utils.common.validation.check_type_jsonarg` - - ``_check_type_list()`` --> :func:`ansible.module_utils.common.validation.check_type_list` - - ``_check_type_path()`` --> :func:`ansible.module_utils.common.validation.check_type_path` - - ``_check_type_raw()`` --> :func:`ansible.module_utils.common.validation.check_type_raw` - - ``_check_type_str()`` --> :func:`ansible.module_utils.common.validation.check_type_str` - - ``_count_terms()`` --> :func:`ansible.module_utils.common.validation.count_terms` - - ``_get_wanted_type()`` - - ``_handle_aliases()`` - - ``_handle_no_log_values()`` - - ``_handle_options()`` - - ``_set_defaults()`` - - ``_set_fallbacks()`` - -Modules or plugins using these private methods should use the public functions in :mod:`ansible.module_utils.common.validation` or :meth:`ArgumentSpecValidator.validate() ` if no public function was listed above. - - -Changes to :mod:`ansible.module_utils.common.parameters` --------------------------------------------------------- - -The following functions in :mod:`ansible.module_utils.common.parameters` are now private and should not be used directly. Use :meth:`ArgumentSpecValidator.validate() ` instead. - - - ``list_no_log_values`` - - ``list_deprecations`` - - ``handle_aliases`` - - -Other -====== - -* **Upgrading**: If upgrading from ``ansible < 2.10`` or from ``ansible-base`` and using pip, you must ``pip uninstall ansible`` or ``pip uninstall ansible-base`` before installing ``ansible-core`` to avoid conflicts. -* Python 3.8 on the controller node is a soft requirement for this release. ``ansible-core`` 2.11 still works with the same versions of Python that ``ansible-base`` 2.10 worked with, however 2.11 emits a warning when running on a controller node with a Python version less than 3.8. This warning can be disabled by setting ``ANSIBLE_CONTROLLER_PYTHON_WARNING=False`` in your environment. ``ansible-core`` 2.12 will require Python 3.8 or greater. -* The configuration system now validates the ``choices`` field, so any settings that violate it and were ignored in 2.10 cause an error in 2.11. For example, ``ANSIBLE_COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH=0`` now causes an error (valid choices are ``ignore``, ``warn`` or ``error``). -* The ``ansible-galaxy`` command now uses ``resolvelib`` for resolving dependencies. In most cases this should not make a user-facing difference beyond being more performant, but we note it here for posterity and completeness. -* If you import Python ``module_utils`` into any modules you maintain, you may now mark the import as optional during the module payload build by wrapping the ``import`` statement in a ``try`` or ``if`` block. This allows modules to use ``module_utils`` that may not be present in all versions of Ansible or a collection, and to perform arbitrary recovery or fallback actions during module runtime. - - -Modules -======= - -* The ``apt_key`` module has explicitly defined ``file`` as mutually exclusive with ``data``, ``keyserver`` and ``url``. They cannot be used together anymore. -* The ``meta`` module now supports tags for user-defined tasks. Set the task's tags to 'always' to maintain the previous behavior. Internal ``meta`` tasks continue to always run. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -* facts - On NetBSD, ``ansible_virtualization_type`` now tries to report a more accurate result than ``xen`` when virtualized and not running on Xen. -* facts - Virtualization facts now include ``virtualization_tech_guest`` and ``virtualization_tech_host`` keys. These are lists of virtualization technologies that a guest is a part of, or that a host provides, respectively. As an example, if you set up a host to provide both KVM and VirtualBox, both values are included in ``virtualization_tech_host``. Similarly, a podman container running on a VM powered by KVM has a ``virtualization_tech_guest`` of ``["kvm", "podman", "container"]``. -* The parameter ``filter`` type is changed from ``string`` to ``list`` in the :ref:`setup ` module in order to use more than one filter. Previous behavior (using a ``string``) still remains and works as a single filter. - - -Plugins -======= - -* inventory plugins - ``CachePluginAdjudicator.flush()`` now calls the underlying cache plugin's ``flush()`` instead of only deleting keys that it knows about. Inventory plugins should use ``delete()`` to remove any specific keys. As a user, this means that when an inventory plugin calls its ``clear_cache()`` method, facts could also be flushed from the cache. To work around this, users can configure inventory plugins to use a cache backend that is independent of the facts cache. -* callback plugins - ``meta`` task execution is now sent to ``v2_playbook_on_task_start`` like any other task. By default, only explicit meta tasks are sent there. Callback plugins can opt-in to receiving internal, implicitly created tasks to act on those as well, as noted in the plugin development documentation. -* The ``choices`` are now validated, so plugins that were using incorrect or incomplete choices issue an error in 2.11 if the value provided does not match. This has a simple fix: update the entries in ``choices`` to match reality. - -Porting custom scripts -====================== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst deleted file mode 100644 index 4e33e84247f..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst +++ /dev/null @@ -1,126 +0,0 @@ - -.. _porting_2.12_guide_core: - -******************************* -Ansible-core 2.12 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.11 and ``ansible-core`` 2.12. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.12 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -* When calling tasks and setting ``async``, setting ``ANSIBLE_ASYNC_DIR`` under ``environment:`` is no longer valid. Instead, use the shell configuration variable ``async_dir``, for example by setting ``ansible_async_dir``: - -.. code-block:: yaml - - tasks: - - dnf: - name: '*' - state: latest - async: 300 - poll: 5 - vars: - ansible_async_dir: /path/to/my/custom/dir - -* The ``undef()`` function is added to the templating environment for creating undefined variables directly in a template. Optionally, a hint may be provided for variables which are intended to be overridden. - -.. code-block:: yaml - - vars: - old: "{{ undef }}" - new: "{{ undef() }}" - new_with_hint: "{{ undef(hint='You must override this variable') }}" - -Python Interpreter Discovery -============================ - -The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``. - -``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable. - -See :ref:`interpreter discovery documentation ` for more details. - - -Command Line -============ - -* Python 3.8 on the controller node is a hard requirement for this release. The command line scripts will not function with a lower Python version. -* ``ansible-vault`` no longer supports ``PyCrypto`` and requires ``cryptography``. - -Deprecated -========== - -* Python 2.6 on the target node is deprecated in this release. ``ansible-core`` 2.13 will remove support for Python 2.6. -* Bare variables in conditionals: ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any variable containing a non-empty string is considered true. This was previously configurable with the ``CONDITIONAL_BARE_VARS`` configuration option (and the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable). This setting no longer has any effect. Users can work around the issue by using the ``|bool`` filter: - -.. code-block:: yaml - - vars: - teardown: 'false' - - tasks: - - include_tasks: teardown.yml - when: teardown | bool - - - include_tasks: provision.yml - when: not teardown | bool - -* The ``_remote_checksum()`` method in ``ActionBase`` is deprecated. Any action plugin using this method should use ``_execute_remote_stat()`` instead. - -Modules -======= - -* ``cron`` now requires ``name`` to be specified in all cases. -* ``cron`` no longer allows a ``reboot`` parameter. Use ``special_time: reboot`` instead. -* ``hostname`` - On FreeBSD, the ``before`` result will no longer be ``"temporarystub"`` if permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``hostname`` - On OpenRC and Solaris based systems, the ``before`` result will no longer be ``"UNKNOWN"`` if the permanent hostname file does not exist. It will instead be ``""`` (empty string) for consistency with other systems. -* ``pip`` now uses the ``pip`` Python module installed for the Ansible module's Python interpreter, if available, unless ``executable`` or ``virtualenv`` were specified. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -* ``unique`` filter with Jinja2 < 2.10 is case-sensitive and now raise coherently an error if ``case_sensitive=False`` instead of when ``case_sensitive=True``. -* Set theory filters (``intersect``, ``difference``, ``symmetric_difference`` and ``union``) are now case-sensitive. Explicitly use ``case_sensitive=False`` to keep previous behavior. Note: with Jinja2 < 2.10, the filters were already case-sensitive by default. -* ``password_hash``` now uses ``passlib`` defaults when an option is unspecified, for example ``bcrypt_sha256`` now default to the "2b" format and if the "2a" format is required it must be specified. - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst deleted file mode 100644 index a60b3b2cfde..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst +++ /dev/null @@ -1,98 +0,0 @@ - -.. _porting_2.13_guide_core: - -******************************* -Ansible-core 2.13 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.12 and ``ansible-core`` 2.13. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.13 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -* Templating - You can no longer perform arithmetic and concatenation operations outside of the jinja template. The following statement will need to be rewritten to produce ``[1, 2]``: - - .. code-block:: yaml - - - name: Prior to 2.13 - debug: - msg: '[1] + {{ [2] }}' - - - name: 2.13 and forward - debug: - msg: '{{ [1] + [2] }}' - -* The return value of the ``__repr__`` method of an undefined variable represented by the ``AnsibleUndefined`` object changed. ``{{ '%r'|format(undefined_variable) }}`` returns ``AnsibleUndefined(hint=None, obj=missing, name='undefined_variable')`` in 2.13 as opposed to just ``AnsibleUndefined`` in versions 2.12 and prior. - -* The ``finalize`` method is no longer exposed in the globals for use in templating. To convert ``None`` to an empty string the following expression can be used: ``{{ value if value is not none }}``. - - -Command Line -============ - -No notable changes - - -Deprecated -========== - -No notable changes - - -Modules -======= - -* To use ansible-core 2.13 for module execution, you must use Python 2 version 2.7 or Python 3 version 3.5 or newer. Any code utilizing ``ansible.module_utils.basic`` will not function with lower Python versions. - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Breaking Changes ----------------- - -* ``ansible.module_utils.urls.fetch_url`` will now return the captured ``HTTPError`` exception as ``r``. ``HTTPError`` is a response like object that can offer more information to module authors. Modules should rely on ``info['status'] >= 400`` to determine if there was a failure, instead of using ``r is None`` or catching ``AttributeError`` when attempting ``r.read()``. - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guide_core_2.14.rst b/docs/docsite/rst/porting_guides/porting_guide_core_2.14.rst deleted file mode 100644 index c1325f74b83..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guide_core_2.14.rst +++ /dev/null @@ -1,91 +0,0 @@ - -.. _porting_2.14_guide_core: - -******************************* -Ansible-core 2.14 Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` 2.13 and ``ansible-core`` 2.14. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for 2.14 `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -* Variables are now evaluated lazily; only when they are actually used. For example, in ansible-core 2.14 an expression ``{{ defined_variable or undefined_variable }}`` does not fail on ``undefined_variable`` if the first part of ``or`` is evaluated to ``True`` as it is not needed to evaluate the second part. One particular case of a change in behavior to note is the task below which uses the ``undefined`` test. Prior to version 2.14 this would result in a fatal error trying to access the undefined value in the dictionary. In 2.14 the assertion passes as the dictionary is evaluated as undefined through one of its undefined values: - - .. code-block:: yaml - - - assert: - that: - - some_defined_dict_with_undefined_values is undefined - vars: - dict_value: 1 - some_defined_dict_with_undefined_values: - key1: value1 - key2: '{{ dict_value }}' - key3: '{{ undefined_dict_value }}' - - -Command Line -============ - -* Python 3.9 on the controller node is a hard requirement for this release. -* At startup the filesystem encoding and locale are checked to verify they are UTF-8. If not, the process exits with an error reporting the errant encoding. If you were previously using the ``C`` or ``POSIX`` locale, you may be able to use ``C.UTF-8``. If you were previously using a locale such as ``en_US.ISO-8859-1``, you may be able to use ``en_US.UTF-8``. For simplicity it may be easiest to export the appropriate locale using the ``LC_ALL`` environment variable. An alternative to modifying your system locale is to run Python in UTF-8 mode; See the `Python documentation `_ for more information. - - -Deprecated -========== - -No notable changes - - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes diff --git a/docs/docsite/rst/porting_guides/porting_guides.rst b/docs/docsite/rst/porting_guides/porting_guides.rst deleted file mode 100644 index 1e8f6a434bd..00000000000 --- a/docs/docsite/rst/porting_guides/porting_guides.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _porting_guides: - -********************** -Ansible Porting Guides -********************** - -This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of Ansible to the next. - -.. toctree:: - :maxdepth: 1 - :glob: - - porting_guide_7 - porting_guide_6 - porting_guide_5 - porting_guide_4 - porting_guide_3 - porting_guide_2.10 - porting_guide_2.9 - porting_guide_2.8 - porting_guide_2.7 - porting_guide_2.6 - porting_guide_2.5 - porting_guide_2.4 - porting_guide_2.3 - porting_guide_2.0 diff --git a/docs/docsite/rst/reference_appendices/.rstcheck.cfg b/docs/docsite/rst/reference_appendices/.rstcheck.cfg deleted file mode 100644 index 5b33c0765eb..00000000000 --- a/docs/docsite/rst/reference_appendices/.rstcheck.cfg +++ /dev/null @@ -1,2 +0,0 @@ -[rstcheck] -ignore_directives=autoclass,automodule diff --git a/docs/docsite/rst/reference_appendices/YAMLSyntax.rst b/docs/docsite/rst/reference_appendices/YAMLSyntax.rst deleted file mode 100644 index 13f08ef4c2c..00000000000 --- a/docs/docsite/rst/reference_appendices/YAMLSyntax.rst +++ /dev/null @@ -1,285 +0,0 @@ -.. _yaml_syntax: - - -YAML Syntax -=========== - -This page provides a basic overview of correct YAML syntax, which is how Ansible -playbooks (our configuration management language) are expressed. - -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. - -You may also wish to read :ref:`working_with_playbooks` at the same time to see how this -is used in practice. - - -YAML Basics ------------ - -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. - -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. - -All members of a list are lines beginning at the same indentation level starting with a ``"- "`` (a dash and a space): - -.. code:: yaml - - --- - # A list of tasty fruits - - Apple - - Orange - - Strawberry - - Mango - ... - -A dictionary is represented in a simple ``key: value`` form (the colon must be followed by a space): - -.. code:: yaml - - # An employee record - martin: - name: Martin D'vloper - job: Developer - skill: Elite - -More complicated data structures are possible, such as lists of dictionaries, dictionaries whose values are lists or a mix of both: - -.. code:: yaml - - # Employee records - - martin: - name: Martin D'vloper - job: Developer - skills: - - python - - perl - - pascal - - tabitha: - name: Tabitha Bitumen - job: Developer - skills: - - lisp - - fortran - - erlang - -Dictionaries and lists can also be represented in an abbreviated form if you really want to: - -.. code:: yaml - - --- - martin: {name: Martin D'vloper, job: Developer, skill: Elite} - fruits: ['Apple', 'Orange', 'Strawberry', 'Mango'] - -These are called "Flow collections". - -.. _truthiness: - -Ansible doesn't really use these too much, but you can also specify a :ref:`boolean value ` (true/false) in several forms: - -.. code:: yaml - - create_key: true - needs_agent: false - knows_oop: True - likes_emacs: TRUE - uses_cvs: false - -Use lowercase 'true' or 'false' for boolean values in dictionaries if you want to be compatible with default yamllint options. - -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: - -.. code:: yaml - - include_newlines: | - exactly as you see - will appear these three - lines of poetry - - fold_newlines: > - this is really a - single line of text - despite appearances - -While in the above ``>`` example all newlines are folded into spaces, there are two ways to enforce a newline to be kept: - -.. code:: yaml - - fold_some_newlines: > - a - b - - c - d - e - f - -Alternatively, it can be enforced by including newline ``\n`` characters: - -.. code:: yaml - - fold_same_newlines: "a b\nc d\n e\nf\n" - -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: - -.. code:: yaml - - --- - # An employee record - name: Martin D'vloper - job: Developer - skill: Elite - employed: True - foods: - - Apple - - Orange - - Strawberry - - Mango - languages: - perl: Elite - python: Elite - pascal: Lame - education: | - 4 GCSEs - 3 A-Levels - BSc in the Internet of Things - -That's all you really need to know about YAML to start writing `Ansible` playbooks. - -Gotchas -------- - -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. - -Because of this, the following is going to result in a YAML syntax error: - -.. code:: text - - foo: somebody said I should put a colon here: so I did - - windows_drive: c: - -...but this will work: - -.. code:: yaml - - windows_path: c:\windows - -You will want to quote hash values using colons followed by a space or the end of the line: - -.. code:: yaml - - foo: 'somebody said I should put a colon here: so I did' - - windows_drive: 'c:' - -...and then the colon will be preserved. - -Alternatively, you can use double quotes: - -.. code:: yaml - - foo: "somebody said I should put a colon here: so I did" - - windows_drive: "c:" - -The difference between single quotes and double quotes is that in double quotes -you can use escapes: - -.. code:: yaml - - foo: "a \t TAB and a \n NEWLINE" - -The list of allowed escapes can be found in the YAML Specification under "Escape Sequences" (YAML 1.1) or "Escape Characters" (YAML 1.2). - -The following is invalid YAML: - -.. code-block:: text - - foo: "an escaped \' single quote" - - -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: - -.. code:: yaml - - foo: "{{ variable }}" - -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: - -.. code:: yaml - - foo: "{{ variable }}/additional/string/literal" - foo2: "{{ variable }}\\backslashes\\are\\also\\special\\characters" - foo3: "even if it's just a string literal it must all be quoted" - -Not valid: - -.. code:: text - - foo: "E:\\path\\"rest\\of\\path - -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: ``[] {} > | * & ! % # ` @ ,``. - -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. - -In Flow Collections, the rules are a bit more strict: - -.. code:: text - - a scalar in block mapping: this } is [ all , valid - - flow mapping: { key: "you { should [ use , quotes here" } - -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: - -.. code:: yaml - - non_boolean: "yes" - other_string: "False" - - -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: - -.. code:: yaml - - version: "1.0" - - -.. seealso:: - - :ref:`working_with_playbooks` - Learn what playbooks can do and how to write/run them. - `YAMLLint `_ - YAML Lint (online) helps you debug YAML syntax if you are having problems - `GitHub examples directory `_ - Complete playbook files from the github project source - `Wikipedia YAML syntax reference `_ - A good guide to YAML syntax - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups - :ref:`communication_irc` - How to join Ansible chat channels (join #yaml for yaml-specific questions) - `YAML 1.1 Specification `_ - The Specification for YAML 1.1, which PyYAML and libyaml are currently - implementing - `YAML 1.2 Specification `_ - For completeness, YAML 1.2 is the successor of 1.1 diff --git a/docs/docsite/rst/reference_appendices/automationhub.rst b/docs/docsite/rst/reference_appendices/automationhub.rst deleted file mode 100644 index 5ebedb5cba5..00000000000 --- a/docs/docsite/rst/reference_appendices/automationhub.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _automation_hub: - -Ansible Automation Hub -====================== - -.. important:: - - Red Hat Ansible Automation Platform will soon be available on Microsoft Azure. `Sign up to preview the experience `_. - -`Ansible Automation Hub `_ is the official location to discover and download supported :ref:`collections `, included as part of an Ansible Automation Platform subscription. These content collections contain modules, plugins, roles, and playbooks in a downloadable package. - -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. - -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 `_. Ansible Automation Hub is part of the Red Hat Ansible Automation Platform subscription, and comes bundled with support from Red Hat, Inc. diff --git a/docs/docsite/rst/reference_appendices/common_return_values.rst b/docs/docsite/rst/reference_appendices/common_return_values.rst deleted file mode 100644 index 04f57ac3d6c..00000000000 --- a/docs/docsite/rst/reference_appendices/common_return_values.rst +++ /dev/null @@ -1,251 +0,0 @@ -.. _common_return_values: - -Return Values -------------- - -.. contents:: Topics - -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`). - -This document covers return values common to all modules. - -.. note:: Some of these keys might be set by Ansible itself once it processes the module's return information. - - -Common -^^^^^^ - -backup_file -``````````` -For those modules that implement `backup=no|yes` when manipulating files, a path to the backup file created. - - .. code-block:: console - - "backup_file": "./foo.txt.32729.2020-07-30@06:24:19~" - - -changed -``````` -A boolean indicating if the task had to make changes to the target or delegated host. - - .. code-block:: console - - "changed": true - -diff -```` -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. - - .. code-block:: console - - "diff": [ - { - "after": "", - "after_header": "foo.txt (content)", - "before": "", - "before_header": "foo.txt (content)" - }, - { - "after_header": "foo.txt (file attributes)", - "before_header": "foo.txt (file attributes)" - } - -failed -`````` -A boolean that indicates if the task was failed or not. - - .. code-block:: console - - "failed": false - -invocation -`````````` -Information on how the module was invoked. - - .. code-block:: console - - "invocation": { - "module_args": { - "_original_basename": "foo.txt", - "attributes": null, - "backup": true, - "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709", - "content": null, - "delimiter": null, - "dest": "./foo.txt", - "directory_mode": null, - "follow": false, - "force": true, - "group": null, - "local_follow": null, - "mode": "666", - "owner": null, - "regexp": null, - "remote_src": null, - "selevel": null, - "serole": null, - "setype": null, - "seuser": null, - "src": "/Users/foo/.ansible/tmp/ansible-tmp-1596115458.110205-105717464505158/source", - "unsafe_writes": null, - "validate": null - } - -msg -``` -A string with a generic message relayed to the user. - - .. code-block:: console - - "msg": "line added" - -rc -`` -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. - - .. code-block:: console - - "rc": 257 - -results -``````` -If this key exists, it indicates that a loop was present for the task and that it contains a list of the normal module 'result' per item. - - .. code-block:: console - - "results": [ - { - "ansible_loop_var": "item", - "backup": "foo.txt.83170.2020-07-30@07:03:05~", - "changed": true, - "diff": [ - { - "after": "", - "after_header": "foo.txt (content)", - "before": "", - "before_header": "foo.txt (content)" - }, - { - "after_header": "foo.txt (file attributes)", - "before_header": "foo.txt (file attributes)" - } - ], - "failed": false, - "invocation": { - "module_args": { - "attributes": null, - "backrefs": false, - "backup": true - } - }, - "item": "foo", - "msg": "line added" - }, - { - "ansible_loop_var": "item", - "backup": "foo.txt.83187.2020-07-30@07:03:05~", - "changed": true, - "diff": [ - { - "after": "", - "after_header": "foo.txt (content)", - "before": "", - "before_header": "foo.txt (content)" - }, - { - "after_header": "foo.txt (file attributes)", - "before_header": "foo.txt (file attributes)" - } - ], - "failed": false, - "invocation": { - "module_args": { - "attributes": null, - "backrefs": false, - "backup": true - } - }, - "item": "bar", - "msg": "line added" - } - ] - -skipped -``````` -A boolean that indicates if the task was skipped or not - - .. code-block:: console - - "skipped": true - -stderr -`````` -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. - - .. code-block:: console - - "stderr": "ls: foo: No such file or directory" - -stderr_lines -```````````` -When `stderr` is returned we also always provide this field which is a list of strings, one item per line from the original. - - .. code-block:: console - - "stderr_lines": [ - "ls: doesntexist: No such file or directory" - ] - -stdout -`````` -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. - - .. code-block:: console - - "stdout": "foo!" - -stdout_lines -```````````` -When `stdout` is returned, Ansible always provides a list of strings, each containing one item per line from the original output. - - .. code-block:: console - - "stdout_lines": [ - "foo!" - ] - - -.. _internal_return_values: - -Internal use -^^^^^^^^^^^^ - -These keys can be added by modules but will be removed from registered variables; they are 'consumed' by Ansible itself. - -ansible_facts -````````````` -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. - -exception -````````` -This key can contain traceback information caused by an exception in a module. It will only be displayed on high verbosity (-vvv). - -warnings -```````` -This key contains a list of strings that will be presented to the user. - -deprecations -```````````` -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. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - `GitHub modules directory `_ - Browse source of core and extras modules - `Mailing List `_ - Development mailing list - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/faq.rst b/docs/docsite/rst/reference_appendices/faq.rst deleted file mode 100644 index cb490edd696..00000000000 --- a/docs/docsite/rst/reference_appendices/faq.rst +++ /dev/null @@ -1,930 +0,0 @@ -.. _ansible_faq: - -Frequently Asked Questions -========================== - -Here are some commonly asked questions and their answers. - -.. _collections_transition: - -Where did all the modules go? -+++++++++++++++++++++++++++++ - -In July, 2019, we announced that collections would be 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 `_ and placed them in :ref:`collections `. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository `_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core`` (it was briefly called ``ansible-base`` for version 2.10). - -* To learn more about using collections, see :ref:`collections`. -* To learn more about developing collections, see :ref:`developing_collections`. -* 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. - -.. _find_my_module: - -Where did this specific module go? -++++++++++++++++++++++++++++++++++ - -IF you are searching for a specific module, you can check the `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 `_ or ask on one of our :ref:`chat channels `. - -.. _slow_install: - -How can I speed up Ansible on systems with slow disks? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Ansible may feel sluggish on systems with slow disks, such as Raspberry PI. See `Ansible might be running slow if libyaml is not available `_ for hints on how to improve this. - - - -.. _set_environment: - -How can I set the PATH or any other environment variable for a task or entire play? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Setting environment variables can be done with the `environment` keyword. It can be used at the task or other levels in the play. - -.. code-block:: yaml - - shell: - cmd: date - environment: - LANG=fr_FR.UTF-8 - -.. code-block:: yaml - - hosts: servers - environment: - PATH: "{{ ansible_env.PATH }}:/thingy/bin" - SOME: value - -.. note:: 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. - -.. _faq_setting_users_and_ports: - -How do I handle different machines needing different user accounts or ports to log in with? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Setting inventory variables in the inventory file is the easiest way. - -For instance, suppose these hosts have different usernames and ports: - -.. code-block:: ini - - [webservers] - asdf.example.com ansible_port=5000 ansible_user=alice - jkl.example.com ansible_port=5001 ansible_user=bob - -You can also dictate the connection type to be used, if you want: - -.. code-block:: ini - - [testcluster] - localhost ansible_connection=local - /path/to/chroot1 ansible_connection=chroot - foo.example.com ansible_connection=paramiko - -You may also wish to keep these in group variables instead, or file them in a group_vars/ file. -See the rest of the documentation for more information about how to organize variables. - -.. _use_ssh: - -How do I get ansible to reuse connections, enable Kerberized SSH, or have Ansible pay attention to my local SSH config file? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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. - -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. - -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. - -.. _use_ssh_jump_hosts: - -How do I configure a jump host to access servers that I have no direct access to? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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: - -.. code-block:: ini - - [gatewayed] - foo ansible_host=192.0.2.1 - bar ansible_host=192.0.2.2 - -You can create `group_vars/gatewayed.yml` with the following contents: - -.. code-block:: yaml - - ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q user@gateway.example.com"' - -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``.) - -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. - -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``. - -.. _ssh_serveraliveinterval: - -How do I get Ansible to notice a dead target in a timely manner? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -You can add ``-o ServerAliveInterval=NumberOfSeconds`` with the ``ssh_args`` parameter in `SSH connection plugin `_. 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. - -.. _cloud_provider_performance: - -How do I speed up run of ansible for servers from cloud providers (EC2, openstack,.. )? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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. - -.. _python_interpreters: - -How do I handle not having a Python interpreter at /usr/bin/python on a remote machine? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -While you can write Ansible modules in any language, most Ansible modules are written in Python, -including the ones central to letting Ansible work. - -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. - -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. - -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 through -``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 through -``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 -`_ so that the incompatibility can be fixed in a future release. - -Do not replace the shebang lines of your python modules. Ansible will do this for you automatically at deploy time. - -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. - -Keep in mind that if you put ``env`` in your module shebang line (``#!/usr/bin/env ``), -this facility will be ignored so you will be at the mercy of the remote `$PATH`. - -.. _installation_faqs: - -How do I handle the package dependencies required by Ansible package dependencies during Ansible installation ? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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). - -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. - -Refer to the documentation of the respective package for such dependencies and their installation methods. - -Common Platform Issues -++++++++++++++++++++++ - -What customer platforms does Red Hat support? ---------------------------------------------- - -A number of them! For a definitive list please see this `Knowledge Base article `_. - -Running in a virtualenv ------------------------ - -You can install Ansible into a virtualenv on the controller quite simply: - -.. code-block:: shell - - $ virtualenv ansible - $ source ./ansible/bin/activate - $ pip install ansible - -If you want to run under Python 3 instead of Python 2 you may want to change that slightly: - -.. code-block:: shell - - $ virtualenv -p python3 ansible - $ source ./ansible/bin/activate - $ pip install ansible - -If you need to use any libraries which are not available through 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: - -* When you create the virtualenv, specify ``--system-site-packages`` to make use of any libraries - installed in the system's Python: - - .. code-block:: shell - - $ virtualenv ansible --system-site-packages - -* Copy those files in manually from the system. For instance, for SELinux bindings you might do: - - .. code-block:: shell - - $ virtualenv ansible --system-site-packages - $ cp -r -v /usr/lib64/python3.*/site-packages/selinux/ ./py3-ansible/lib64/python3.*/site-packages/ - $ cp -v /usr/lib64/python3.*/site-packages/*selinux*.so ./py3-ansible/lib64/python3.*/site-packages/ - - -Running on macOS ----------------- - -When executing Ansible on a system with macOS as a controller machine one might encounter the following error: - - .. error:: - +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. - ERROR! A worker was found in a dead state - -In general the recommended workaround is to set the following environment variable in your shell: - - .. code-block:: shell - - $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES - - -Running on BSD --------------- - -.. seealso:: :ref:`working_with_bsd` - - -Running on Solaris ------------------- - -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: - -* 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`, :ref:`fish shell`, - and :ref:`Powershell`). For example, in the ansible config file you can set: - - .. code-block:: ini - - remote_tmp=$HOME/.ansible/tmp - - In Ansible 2.5 and later, you can also set it per-host in inventory like this: - - .. code-block:: ini - - solaris1 ansible_remote_tmp=$HOME/.ansible/tmp - -* You can set :ref:`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: - - .. code-block:: ini - - solaris1 ansible_shell_executable=/usr/xpg4/bin/sh - - (bash, ksh, and zsh should also be POSIX compatible if you have any of those installed). - -Running on z/OS ---------------- - -There are a few common errors that one might run into when trying to execute Ansible on z/OS as a target. - -* Version 2.7.6 of python for z/OS will not work with Ansible because it represents strings internally as EBCDIC. - - To get around this limitation, download and install a later version of `python for z/OS `_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work. - -* When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode through sftp however execution of python fails with - - .. error:: - 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 - - To fix it set ``pipelining = True`` in `/etc/ansible/ansible.cfg`. - -* Python interpret cannot be found in default location ``/usr/bin/python`` on target host. - - .. error:: - /usr/bin/python: EDC5129I No such file or directory - - To fix this set the path to the python installation in your inventory like so:: - - .. code-block:: ini - - zos1 ansible_python_interpreter=/usr/lpp/python/python-2017-04-12-py27/python27/bin/python - -* Start of python fails with ``The module libpython2.7.so was not found.`` - - .. error:: - EE3501S The module libpython2.7.so was not found. - - 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``: - - .. code-block:: ini - - zos1 ansible_shell_executable=/usr/lpp/bash/bin/bash - - -Running under fakeroot ----------------------- - -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). - -For example, in the ansible config file (or through environment variable) you can set: - -.. code-block:: ini - - remote_tmp=$HOME/.ansible/tmp - - - -.. _use_roles: - -What is the best way to make content reusable/redistributable? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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. - -If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended. - -.. _configuration_file: - -Where does the configuration file live and what can I configure in it? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - - -See :ref:`intro_configuration`. - -.. _who_would_ever_want_to_disable_cowsay_but_ok_here_is_how: - -How do I disable cowsay? -++++++++++++++++++++++++ - -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: - -.. code-block:: shell-session - - export ANSIBLE_NOCOWS=1 - -.. _browse_facts: - -How do I see a list of all of the ansible\_ variables? -++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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: - -.. code-block:: shell-session - - ansible -m setup hostname - -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'. - - -.. _browse_inventory_vars: - -How do I see all the inventory variables defined for my host? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -By running the following command, you can see inventory variables for a host: - -.. code-block:: shell-session - - ansible-inventory --list --yaml - - -.. _browse_host_vars: - -How do I see all the variables specific to my host? -+++++++++++++++++++++++++++++++++++++++++++++++++++ - -To see all host specific variables, which might include facts and other sources: - -.. code-block:: shell-session - - ansible -m debug -a "var=hostvars['hostname']" localhost - -Unless you are using a fact cache, you normally need to use a play that gathers facts first, for facts included in the task above. - - -.. _host_loops: - -How do I loop over a list of hosts in a group, inside of a template? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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: - -.. code-block:: jinja - - {% for host in groups['db_servers'] %} - {{ host }} - {% endfor %} - -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: - -.. code-block:: yaml - - - hosts: db_servers - tasks: - - debug: msg="doesn't matter what you do, just that they were talked to previously." - -Then you can use the facts inside your template, like this: - -.. code-block:: jinja - - {% for host in groups['db_servers'] %} - {{ hostvars[host]['ansible_eth0']['ipv4']['address'] }} - {% endfor %} - -.. _programatic_access_to_a_variable: - -How do I access a variable name programmatically? -+++++++++++++++++++++++++++++++++++++++++++++++++ - -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 -through a role parameter or other input. Variable names can be built by adding strings together using "~", like so: - -.. code-block:: jinja - - {{ hostvars[inventory_hostname]['ansible_' ~ which_interface]['ipv4']['address'] }} - -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. - -In the example above, if your interface names have dashes, you must replace them with underscores: - -.. code-block:: jinja - - {{ hostvars[inventory_hostname]['ansible_' ~ which_interface | replace('_', '-') ]['ipv4']['address'] }} - -Also see dynamic_variables_. - - -.. _access_group_variable: - -How do I access a group variable? -+++++++++++++++++++++++++++++++++ - -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. - -That said, you could just access the variable by selecting a host that is part of that group, see first_host_in_a_group_ below for an example. - - -.. _first_host_in_a_group: - -How do I access a variable of the first host in a group? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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 AWX or the :ref:`Red Hat Ansible Automation Platform `, it will use database order, so this isn't a problem even if you are using cloud -based inventory scripts). - -Anyway, here's the trick: - -.. code-block:: jinja - - {{ hostvars[groups['webservers'][0]]['ansible_eth0']['ipv4']['address'] }} - -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: - -.. code-block:: yaml+jinja - - - set_fact: headnode={{ groups['webservers'][0] }} - - - debug: msg={{ hostvars[headnode].ansible_eth0.ipv4.address }} - -Notice how we interchanged the bracket syntax for dots -- that can be done anywhere. - -.. _file_recursion: - -How do I copy files recursively onto a target host? -+++++++++++++++++++++++++++++++++++++++++++++++++++ - -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. - -.. _shell_env: - -How do I access shell environment variables? -++++++++++++++++++++++++++++++++++++++++++++ - - -**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: - -.. code-block:: yaml+jinja - - --- - # ... - vars: - local_home: "{{ lookup('env','HOME') }}" - - -**On target machines :** Environment variables are available through facts in the ``ansible_env`` variable: - -.. code-block:: jinja - - {{ ansible_env.HOME }} - -If you need to set environment variables for TASK execution, see :ref:`playbooks_environment` -in the :ref:`Advanced Playbooks ` section. -There are several ways to set environment variables on your target machines. You can use the -:ref:`template `, :ref:`replace `, or :ref:`lineinfile ` -modules to introduce environment variables into files. The exact files to edit vary depending on your OS -and distribution and local configuration. - -.. _user_passwords: - -How do I generate encrypted passwords for the user module? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Ansible ad hoc command is the easiest option: - -.. code-block:: shell-session - - ansible all -i localhost, -m debug -a "msg={{ 'mypassword' | password_hash('sha512', 'mysecretsalt') }}" - -The ``mkpasswd`` utility that is available on most Linux systems is also a great option: - -.. code-block:: shell-session - - mkpasswd --method=sha-512 - - -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 `_ -password hashing library is installed: - -.. code-block:: shell-session - - pip install passlib - -Once the library is ready, SHA512 password values can then be generated as follows: - -.. code-block:: shell-session - - python -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))" - -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. - -In OpenBSD, a similar option is available in the base system called ``encrypt (1)`` - -.. _dot_or_array_notation: - -Ansible allows dot notation and array notation for variables. Which notation should I use? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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. - -.. code-block:: jinja - - item[0]['checksum:md5'] - item['section']['2.1'] - item['region']['Mid-Atlantic'] - It is {{ temperature['Celsius']['-3'] }} outside. - -Also array notation allows for dynamic variable composition, see dynamic_variables_. - -Another problem with 'dot notation' is that some keys can cause problems because they collide with attributes and methods of python dictionaries. - -* Example of incorrect syntax when ``item`` is a dictionary: - -.. code-block:: jinja - - item.update - -This variant causes a syntax error because ``update()`` is a Python method for dictionaries. - -* Example of correct syntax: - -.. code-block:: jinja - - item['update'] - - -.. _argsplat_unsafe: - -When is it unsafe to bulk-set task arguments from a variable? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - - -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: - -.. code-block:: yaml+jinja - - #... - vars: - usermod_args: - name: testuser - state: present - update_password: always - tasks: - - user: '{{ usermod_args }}' - -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: - -* 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) -* disable the :ref:`inject_facts_as_vars` configuration setting to prevent fact values from colliding - with variables (this will also disable the original warning) - - -.. _commercial_support: - -Can I get training on Ansible? -++++++++++++++++++++++++++++++ - -Yes! See our `services page `_ for information on our services -and training offerings. Email `info@ansible.com `_ for further details. - -We also offer free web-based training classes on a regular basis. See our -`webinar page `_ for more info on upcoming webinars. - - -.. _web_interface: - -Is there a web interface / REST API / GUI? -++++++++++++++++++++++++++++++++++++++++++++ - -Yes! The open-source web interface is Ansible AWX. The supported Red Hat product that makes Ansible even more powerful and easy to use is :ref:`Red Hat Ansible Automation Platform `. - - -.. _keep_secret_data: - -How do I keep secret data in my playbook? -+++++++++++++++++++++++++++++++++++++++++ - -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`. - -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: - -.. code-block:: yaml+jinja - - - name: secret task - shell: /usr/bin/do_something --value={{ secret_value }} - no_log: True - -This can be used to keep verbose output but hide sensitive information from others who would otherwise like to be able to see the output. - -The ``no_log`` attribute can also apply to an entire play: - -.. code-block:: yaml - - - hosts: all - no_log: True - -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 through -the :envvar:`ANSIBLE_DEBUG` environment variable. - - -.. _when_to_use_brackets: -.. _dynamic_variables: -.. _interpolate_variables: - -When should I use {{ }}? Also, how to interpolate variables or dynamic variable names -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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 ``{{ }}``. - -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. - -Another rule is 'moustaches don't stack'. We often see this: - -.. code-block:: jinja - - {{ somevar_{{other_var}} }} - -The above DOES NOT WORK as you expect, if you need to use a dynamic variable use the following as appropriate: - -.. code-block:: jinja - - {{ hostvars[inventory_hostname]['somevar_' ~ other_var] }} - -For 'non host vars' you can use the :ref:`vars lookup` plugin: - -.. code-block:: jinja - - {{ lookup('vars', 'somevar_' ~ other_var) }} - -To determine if a keyword requires ``{{ }}`` or even supports templating, use ``ansible-doc -t keyword ``, -this will return documentation on the keyword including a ``template`` field with the values ``explicit`` (requires ``{{ }}``), -``implicit`` (assumes ``{{ }}``, so no needed) or ``static`` (no templating supported, all characters will be interpreted literally) - -.. _ansible_host_delegated: - -How do I get the original ansible_host when I delegate a task? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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 through ``hostvars``: - -.. code-block:: yaml+jinja - - original_host: "{{ hostvars[inventory_hostname]['ansible_host'] }}" - -This works for all overridden connection variables, like ``ansible_user``, ``ansible_port``, and so on. - - -.. _scp_protocol_error_filename: - -How do I fix 'protocol error: filename does not match request' when fetching a file? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Since release ``7.9p1`` of OpenSSH there is a `bug `_ -in the SCP client that can trigger this error on the Ansible controller when using SCP as the file transfer mechanism: - -.. error:: - - failed to transfer file to /tmp/ansible/file.txt\r\nprotocol error: filename does not match request - -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: - -* Use SFTP instead of SCP by setting ``scp_if_ssh`` to ``smart`` (which tries SFTP first) or to ``False``. You can do this in one of four ways: - * Rely on the default setting, which is ``smart`` - this works if ``scp_if_ssh`` is not explicitly set anywhere - * Set a :ref:`host variable ` or :ref:`group variable ` in inventory: ``ansible_scp_if_ssh: False`` - * Set an environment variable on your control node: ``export ANSIBLE_SCP_IF_SSH=False`` - * Pass an environment variable when you run Ansible: ``ANSIBLE_SCP_IF_SSH=smart ansible-playbook`` - * Modify your ``ansible.cfg`` file: add ``scp_if_ssh=False`` to the ``[ssh_connection]`` section -* If you must use SCP, set the ``-T`` arg to tell the SCP client to ignore path validation. You can do this in one of three ways: - * Set a :ref:`host variable ` or :ref:`group variable `: ``ansible_scp_extra_args=-T``, - * Export or pass an environment variable: ``ANSIBLE_SCP_EXTRA_ARGS=-T`` - * Modify your ``ansible.cfg`` file: add ``scp_extra_args=-T`` to the ``[ssh_connection]`` section - -.. note:: 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. - -.. _mfa_support: - -Does Ansible support multiple factor authentication 2FA/MFA/biometrics/finterprint/usbkey/OTP/... -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -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. - -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. -With AWX or the :ref:`Red Hat Ansible Automation Platform `, administrators can set up RBAC access to inventory, along with managing credentials and job execution. - - -.. _complex_configuration_validation: - -The 'validate' option is not enough for my needs, what do I do? -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Many Ansible modules that create or update files have a ``validate`` option that allows you to abort the update if the validation command fails. -This uses the temporary file Ansible creates before doing the final update. In many cases this does not work since the validation tools -for the specific application require either specific names, multiple files or some other factor that is not present in this simple feature. - -For these cases you have to handle the validation and restoration yourself. The following is a simple example of how to do this with block/rescue -and backups, which most file based modules also support: - -.. code-block:: yaml - - - name: update config and backout if validation fails - block: - - name: do the actual update, works with copy, lineinfile and any action that allows for `backup`. - template: src=template.j2 dest=/x/y/z backup=yes moreoptions=stuff - register: updated - - - name: run validation, this will change a lot as needed. We assume it returns an error when not passing, use `failed_when` if otherwise. - shell: run_validation_commmand - become: true - become_user: requiredbyapp - environment: - WEIRD_REQUIREMENT: 1 - rescue: - - name: restore backup file to original, in the hope the previous configuration was working. - copy: - remote_src: true - dest: /x/y/z - src: "{{ updated['backup_file'] }}" - always: - - name: We choose to always delete backup, but could copy or move, or only delete in rescue. - file: - path: "{{ updated['backup_file'] }}" - state: absent - -.. _jinja2_faqs: - -Why does the ``regex_search`` filter return `None` instead of an empty string? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Until the jinja2 2.10 release, Jinja was only able to return strings, but Ansible needed Python objects in some cases. Ansible uses ``safe_eval`` and only sends strings that look like certain types of Python objects through this function. With ``regex_search`` that does not find a match, the result (``None``) is converted to the string "None" which is not useful in non-native jinja2. - -The following example of a single templating action shows this behavior: - -.. code-block:: Jinja - - {{ 'ansible' | regex_search('foobar') }} - -This example does not result in a Python ``None``, so Ansible historically converted it to "" (empty string). - -The native jinja2 functionality actually allows us to return full Python objects, that are always represented as Python objects everywhere, and as such the result of a single templating action with ``regex_search`` can result in the Python ``None``. - -.. note:: - - Native jinja2 functionality is not needed when ``regex_search`` is used as an intermediate result that is then compared to the jinja2 ``none`` test. - - .. code-block:: Jinja - - {{ 'ansible' | regex_search('foobar') is none }} - - -.. _docs_contributions: - -How do I submit a change to the documentation? -++++++++++++++++++++++++++++++++++++++++++++++ - -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 `_. Thanks! - - -.. _legacy_vs_builtin: - -What is the difference between ``ansible.legacy`` and ``ansible.builtin`` collections? -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Neither is a real collection. They are virtually constructed by the core engine (synthetic collections). - -The ``ansible.builtin`` collection only refers to plugins that ship with ``ansible-core``. - -The ``ansible.legacy`` collection is a superset of ``ansible.builtin`` (you can reference the plugins from builtin through ``ansible.legacy``). You also get the ability to -add 'custom' plugins in the :ref:`configured paths and adjacent directories `, with the ability to override the builtin plugins that have the same name. - -Also, ``ansible.legacy`` is what you get by default when you do not specify an FQCN. -So this: - - .. code-block:: yaml - - - shell: echo hi - -Is really equivalent to: - - .. code-block:: yaml - - - ansible.legacy.shell: echo hi - -Though, if you do not override the ``shell`` module, you can also just write it as ``ansible.builtin.shell``, since legacy will resolve to the builtin collection. - - -.. _i_dont_see_my_question: - -I don't see my question here -++++++++++++++++++++++++++++ - -If you have not found an answer to your questions, you can ask on one of our mailing lists or chat channels. For instructions on subscribing to a list or joining a chat channel, see :ref:`communication`. - -.. seealso:: - - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! diff --git a/docs/docsite/rst/reference_appendices/general_precedence.rst b/docs/docsite/rst/reference_appendices/general_precedence.rst deleted file mode 100644 index a94f4a64f15..00000000000 --- a/docs/docsite/rst/reference_appendices/general_precedence.rst +++ /dev/null @@ -1,150 +0,0 @@ -.. _general_precedence_rules: - -Controlling how Ansible behaves: precedence rules -================================================= - -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. - -These precedence rules apply to any setting that can be defined in multiple ways (by configuration settings, command-line options, playbook keywords, variables). - -.. contents:: - :local: - -Precedence categories ---------------------- - -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: - - * Configuration settings - * Command-line options - * Playbook keywords - * Variables - -Each category overrides any information from all lower-precedence categories. For example, a playbook keyword will override any configuration setting. - -Within each precedence category, specific rules apply. However, generally speaking, 'last defined' wins and overrides any previous definitions. - -Configuration settings -^^^^^^^^^^^^^^^^^^^^^^ - -:ref:`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: - - * ``ANSIBLE_CONFIG`` (environment variable if set) - * ``ansible.cfg`` (in the current directory) - * ``~/.ansible.cfg`` (in the home directory) - * ``/etc/ansible/ansible.cfg`` - -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. - -Command-line options -^^^^^^^^^^^^^^^^^^^^ - -Any command-line option will override any configuration setting. - -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. - -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`. - -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` will connect as ``carol``, not as ``mike``: - -.. code:: shell - - ansible -u mike -m ping myhost -u carol - -Some parameters allow multiple values. In this case, Ansible will append all values from the hosts listed in inventory files inventory1 and inventory2: - -.. code:: shell - - ansible -i /path/inventory1 -i /path/inventory2 -m ping all - -The help for each :ref:`command-line tool` lists available options for that tool. - -Playbook keywords -^^^^^^^^^^^^^^^^^ - -Any :ref:`playbook keyword` will override any command-line option and any configuration setting. - -Within playbook keywords, precedence flows with the playbook itself; the more specific wins against the more general: - -- play (most general) -- blocks/includes/imports/roles (optional and can contain tasks and each other) -- tasks (most specific) - -A simple example: - -.. code:: yaml - - - hosts: all - connection: ssh - tasks: - - name: This task uses ssh. - ping: - - - name: This task uses paramiko. - connection: paramiko - ping: - -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. - -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. - -.. _general_precedence_variables: - -Variables -^^^^^^^^^ - -Any variable will override any playbook keyword, any command-line option, and any configuration setting. - -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. - -Connection variables, like all variables, can be set in multiple ways and places. You can define variables for hosts and groups in :ref:`inventory`. You can define variables for tasks and plays in ``vars:`` blocks in :ref:`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 ` as any other variables. - -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: - -.. code:: yaml - - - hosts: cloud - gather_facts: false - become: true - vars: - ansible_become_user: admin - tasks: - - name: This task uses admin as the become user. - dnf: - name: some-service - state: latest - - block: - - name: This task uses service-admin as the become user. - # a task to configure the new service - - name: This task also uses service-admin as the become user, defined in the block. - # second task to configure the service - vars: - ansible_become_user: service-admin - - name: This task (outside of the block) uses admin as the become user again. - service: - name: some-service - state: restarted - -Variable scope: how long is a value available? -"""""""""""""""""""""""""""""""""""""""""""""" - -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. - -Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact` and :ref:`include_vars`, are available to all plays. These 'host scope' variables are also available through the ``hostvars[]`` dictionary. - -.. _general_precedence_extra_vars: - -Using ``-e`` extra variables at the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -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``: - -.. code:: shell - - ansible -u carol -e 'ansible_user=brian' -a whoami all - -You must specify both the variable name and the value with ``--extra-vars``. diff --git a/docs/docsite/rst/reference_appendices/glossary.rst b/docs/docsite/rst/reference_appendices/glossary.rst deleted file mode 100644 index 1f7d945bf9d..00000000000 --- a/docs/docsite/rst/reference_appendices/glossary.rst +++ /dev/null @@ -1,543 +0,0 @@ -Glossary -======== - -The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation. - -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. - -.. glossary:: - - Action - 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. - - Ad Hoc - 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 ` and playbooks can also glue - lots of other operations together. - - Ansible (the package) - A software package (Python, deb, rpm, and so on) that contains ansible-core 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-.build` file in the release-specific directory at `ansible-build-data `_ for a list of collections included in Ansible, as well as the included ``ansible-core`` version. - - ansible-base - Used only for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. See ``ansible-core``. - - ansible-core - Name used starting with 2.11. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository `_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-core`` package includes a few modules and plugins and allows you to add others by installing collections. - - Ansible Galaxy - An `online distribution server `_ for finding and sharing Ansible community content, sometimes referred to as community Galaxy. Also, the command-line utility that lets users install individual Ansible Collections, for example ``ansible-galaxy collection install community.crypto``. - - Async - 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`. - - Callback Plugin - 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. - - Check Mode - 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. - - Collection - A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-core`` 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 ``. - - Collection name - 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. - - community.general (collection) - A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do not have their own dedicated Collection. See `community.general `_ on Galaxy. - - community.network (collection) - Similar to ``community.general``, focusing on network content. `community.network `_ on Galaxy. - - Connection Plugin - 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 `. 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. - - Conditionals - 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`. - - Declarative - 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. - - Diff Mode - 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. - - Distribution server - A server, such as Ansible Galaxy or Red Hat Automation Hub where you can distribute your collections and allow others to access these collections. See :ref:`distributing_collections` for a list of distribution server types. Some Ansible features are only available on certain distribution servers. - - Executor - 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 `. The - Executor is something Ansible developers may talk about, but it's not - really user land vocabulary. - - Facts - 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 ` 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 through 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 through - ``gather_subset:``) - - Filter Plugin - 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 `. - - Forks - 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. - - Fully Qualified Collection Name (FQCN) - The full definition of a module, plugin, or role hosted within a collection, in the form . 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. - - Gather Facts (Boolean) - :term:`Facts` are mentioned above. Sometimes when running a multi-play - :term:`playbook `, 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. - - Globbing - 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. - - Group - 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. - - Group Vars - 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 `. - - Handlers - Handlers are just like regular tasks in an Ansible - :term:`playbook ` (see :term:`Tasks`) but are only run if - the Task contains a ``notify`` keyword 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. - - Host - 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. - - Host Specifier - Each :term:`Play ` in Ansible maps a series of :term:`tasks` (which define the role, - purpose, or orders of a system) to a set of systems. - - This ``hosts:`` keyword in each play is often called the hosts specifier. - - It may select one system, many systems, one or more groups, or even - some hosts that are in one group and explicitly not in another. - - Host Vars - 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. - - Idempotency - 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. - - Includes - The idea that :term:`playbook ` 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``. - - Inventory - A file (by default, Ansible uses a simple INI format) that describes - :term:`Hosts ` and :term:`Groups ` in Ansible. Inventory - can also be provided through an :term:`Inventory Script` (sometimes called - an "External Inventory Script"). - - Inventory Script - A very simple program (or a complicated one) that looks up - :term:`hosts `, :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. - - Jinja2 - 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. - - JSON - Ansible uses JSON for return data from remote modules. This allows - modules to be written in any language, not just Python. - - Keyword - The main expressions that make up Ansible, which apply to playbook objects - (Play, Block, Role and Task). For example 'vars:' is a keyword that lets - you define variables in the scope of the playbook object it is applied to. - - Lazy Evaluation - In general, Ansible evaluates any variables in - :term:`playbook ` 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. - - Library - A collection of modules made available to :command:`/usr/bin/ansible` - or an Ansible :term:`playbook `. - - Limit Groups - By passing ``--limit somegroup`` to :command:`ansible` or - :command:`ansible-playbook`, the commands can be limited to a subset - of :term:`hosts `. For instance, this can be used to run - a :term:`playbook ` that normally targets an entire set of - servers to one particular server. - - Local Action - This keyword is an alias for ``delegate_to: localhost``. - Used when you want to redirect an action from the remote to - execute on the controller itself. - - Local Connection - By using ``connection: local`` in a :term:`playbook `, or - passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates - that we are executing a local fork instead of executing on the remote machine. - You probably want ``local_action`` or ``delegate_to: localhost`` instead - as this ONLY changes the connection and no other context for execution. - - Lookup Plugin - 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. - - Loops - 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 ` and :ref:`apt `, 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. - - Modules - 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 take advantage of 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`. - - Multi-Tier - 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. - - Namespace - 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 `_ on the Galaxy docsite for namespace requirements. - - Notify - The act of a :term:`task ` registering a change event and - informing a :term:`handler ` task that another - :term:`action` needs to be run at the end of the :term:`play `. 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. - - Orchestration - 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. - - paramiko - 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. - - Playbooks - 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 :) - - Plays - A :term:`playbook ` is a list of plays. A play is - minimally a mapping between a set of :term:`hosts ` selected by a host - specifier (usually chosen by :term:`groups ` but sometimes by - hostname :term:`globs `) 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. - - Pull Mode - 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 `. Most Ansible users use push - mode, but pull mode is included for variety and the sake of having - choices. - - :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. - - Pulp 3 Galaxy - A self-hosted distribution server based on the `GalaxyNG codebase `_, based on Pulp version 3. Use it to find and share your own curated set of content. You can access your content with the ``ansible-galaxy collection`` command. - - - Push Mode - 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. - - Register Variable - The result of running any :term:`task ` 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. - - Resource Model - Ansible modules work in terms of resources. For instance, the - :ref:`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 ` 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. - - Roles - Roles are units of organization in Ansible. Assigning a role to - a group of :term:`hosts ` (or a set of :term:`groups `, - or :term:`host patterns `, 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. - - Rolling Update - 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. - - Serial - .. seealso:: - - :term:`Rolling Update` - - Sudo - 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 `, :ref:`template `, and - :ref:`fetch ` modules while running in sudo mode. - - SSH (Native) - Native OpenSSH as an Ansible transport is specified with ``-c ssh`` - (or a config file, or a keyword in the :term:`playbook `) - and can be useful if wanting to login through 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. - - Tags - Ansible allows tagging resources in a :term:`playbook ` - 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. - - Task - :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 keywords `). :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. - - Tasks - A list of :term:`Task`. - - Templates - 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. - - Transport - 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 ` (using OpenSSH), and - :term:`local `. - - When - An optional conditional statement attached to a :term:`task ` 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. - - Vars (Variables) - 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). - - YAML - Ansible does not want to force people to write programming language - code to automate infrastructure, so Ansible uses YAML to define - :term:`playbook ` 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). - -.. seealso:: - - :ref:`ansible_faq` - Frequently asked questions - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_best_practices` - Tips and tricks for playbooks - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/interpreter_discovery.rst b/docs/docsite/rst/reference_appendices/interpreter_discovery.rst deleted file mode 100644 index 23d1d970929..00000000000 --- a/docs/docsite/rst/reference_appendices/interpreter_discovery.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _interpreter_discovery: - -Interpreter Discovery -===================== - -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. - -To control the discovery behavior: - -* for individual hosts and groups, use the ``ansible_python_interpreter`` inventory variable -* globally, use the ``interpreter_python`` key in the ``[defaults]`` section of ``ansible.cfg`` - -Use one of the following values: - -auto_legacy : - 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. - -auto : (default in 2.12) - 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. - -auto_legacy_silent - Same as ``auto_legacy``, but does not issue warnings. - -auto_silent - Same as ``auto``, but does not issue warnings. - -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. diff --git a/docs/docsite/rst/reference_appendices/logging.rst b/docs/docsite/rst/reference_appendices/logging.rst deleted file mode 100644 index 5adac5c8e10..00000000000 --- a/docs/docsite/rst/reference_appendices/logging.rst +++ /dev/null @@ -1,14 +0,0 @@ -********************** -Logging Ansible output -********************** - -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: - -* To save Ansible output in a single log on the control node, set the ``log_path`` :ref:`configuration file setting `. You may also want to set ``display_args_to_stdout``, which helps to differentiate similar tasks by including variable values in the Ansible output. -* To save Ansible output in separate logs, one on each managed node, set the ``no_target_syslog`` and ``syslog_facility`` :ref:`configuration file settings `. -* To save Ansible output to a secure database, use AWX or :ref:`Red Hat Ansible Automation Platform `. You can then review history based on hosts, projects, and particular inventories over time, using graphs and/or a REST API. - -Protecting sensitive data with ``no_log`` -========================================= - -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. diff --git a/docs/docsite/rst/reference_appendices/module_utils.rst b/docs/docsite/rst/reference_appendices/module_utils.rst deleted file mode 100644 index 29cf23106e4..00000000000 --- a/docs/docsite/rst/reference_appendices/module_utils.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _ansible.module_utils: -.. _module_utils: - -*************************************************************** -Ansible Reference: Module Utilities -*************************************************************** - -This page documents utilities intended to be helpful when writing -Ansible modules in Python. - - -AnsibleModule --------------- - -To use this functionality, include ``from ansible.module_utils.basic import AnsibleModule`` in your module. - -.. autoclass:: ansible.module_utils.basic.AnsibleModule - :members: - :noindex: - -Basic ------- - -To use this functionality, include ``import ansible.module_utils.basic`` in your module. - -.. automodule:: ansible.module_utils.basic - :members: - - -Argument Spec ---------------------- - -Classes and functions for validating parameters against an argument spec. - -ArgumentSpecValidator -===================== - -.. autoclass:: ansible.module_utils.common.arg_spec.ArgumentSpecValidator - :members: - -ValidationResult -================ - -.. autoclass:: ansible.module_utils.common.arg_spec.ValidationResult - :members: - :member-order: bysource - :private-members: _no_log_values # This only works in sphinx >= 3.2. Otherwise it shows all private members with doc strings. - -Parameters -========== - -.. automodule:: ansible.module_utils.common.parameters - :members: - - .. py:data:: DEFAULT_TYPE_VALIDATORS - - :class:`dict` of type names, such as ``'str'``, and the default function - used to check that type, :func:`~ansible.module_utils.common.validation.check_type_str` in this case. - -Validation -========== - -Standalone functions for validating various parameter types. - -.. automodule:: ansible.module_utils.common.validation - :members: - - -Errors ------- - -.. automodule:: ansible.module_utils.errors - :members: - :member-order: bysource diff --git a/docs/docsite/rst/reference_appendices/python_3_support.rst b/docs/docsite/rst/reference_appendices/python_3_support.rst deleted file mode 100644 index e7196d2aaa4..00000000000 --- a/docs/docsite/rst/reference_appendices/python_3_support.rst +++ /dev/null @@ -1,95 +0,0 @@ -================ -Python 3 Support -================ - -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. - -See :ref: `Control Node Requirements ` and :ref: `Managed Node Requirements ` for the specific versions supported. - -On the controller side ----------------------- - -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: - -.. code-block:: shell - - $ pip3 install ansible - $ ansible --version | grep "python version" - python version = 3.10.5 (main, Jun 9 2022, 00:00:00) [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] (/usr/bin/python) - -If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your -command through ``python3``. For example: - -.. code-block:: shell - - $ source ./hacking/env-setup - $ python3 $(which ansible) localhost -m ping - $ python3 $(which ansible-playbook) sample-playbook.yml - -.. note:: 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 - (through a separate package or through some commands that are run after install). You'll need to check - with your distro to see if that applies in your case. - - -Using Python 3 on the managed machines with commands and playbooks ------------------------------------------------------------------- - -* 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``. - -.. seealso:: :ref:`interpreter_discovery` for more information. - -.. code-block:: ini - - # Example inventory that makes an alias for localhost that uses Python3 - localhost-py3 ansible_host=localhost ansible_connection=local ansible_python_interpreter=/usr/bin/python3 - - # Example of setting a group of hosts to use Python3 - [py3_hosts] - ubuntu16 - fedora27 - - [py3_hosts:vars] - ansible_python_interpreter=/usr/bin/python3 - -.. seealso:: :ref:`intro_inventory` for more information. - -* Run your command or playbook: - -.. code-block:: shell - - $ ansible localhost-py3 -m ping - $ ansible-playbook sample-playbook.yml - - -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: - -.. code-block:: shell - - $ ansible localhost -m ping -e 'ansible_python_interpreter=/usr/bin/python3' - $ ansible-playbook sample-playbook.yml -e 'ansible_python_interpreter=/usr/bin/python3' - -What to do if an incompatibility is found ------------------------------------------ - -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. - -If you find a bug running under Python 3 you can submit a bug report on `Ansible's GitHub project -`_. Be sure to mention Python3 in the bug report so -that the right people look at it. - -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. diff --git a/docs/docsite/rst/reference_appendices/release_and_maintenance.rst b/docs/docsite/rst/reference_appendices/release_and_maintenance.rst deleted file mode 100644 index 551ff25fd31..00000000000 --- a/docs/docsite/rst/reference_appendices/release_and_maintenance.rst +++ /dev/null @@ -1,395 +0,0 @@ -.. _release_and_maintenance: - -************************ -Releases and maintenance -************************ - -This section describes release cycles, rules, and maintenance schedules for both Ansible community projects: the Ansible community package and ``ansible-core``. The two projects have different versioning systems, maintenance structures, contents, and workflows. - -==================================================== ======================================================== -Ansible community package ansible-core -==================================================== ======================================================== -Uses new versioning (2.10, then 3.0.0) Continues "classic Ansible" versioning (2.11, then 2.12) -Follows semantic versioning rules Does not use semantic versioning -Maintains only one version at a time Maintains latest version plus two older versions -Includes language, runtime, and selected Collections Includes language, runtime, and builtin plugins -Developed and maintained in Collection repositories Developed and maintained in ansible/ansible repository -==================================================== ======================================================== - -Many community users install the Ansible community package. The Ansible community package offers the functionality that existed in Ansible 2.9, with more than 85 Collections containing thousands of modules and plugins. The ``ansible-core`` option is primarily for developers and users who want to install only the collections they need. - -.. contents:: - :local: - -.. _release_cycle: - -Release cycle overview -====================== - -The two community releases are related - the release cycle follows this pattern: - -#. Release of a new ansible-core major version, for example, ansible-core 2.11 - - * New release of ansible-core and two prior versions are now maintained (in this case, ansible-base 2.10, Ansible 2.9) - * Work on new features for ansible-core continues in the ``devel`` branch - -#. Collection freeze (no new Collections or new versions of existing Collections) on the Ansible community package -#. Release candidate for Ansible community package, testing, additional release candidates as necessary -#. Release of a new Ansible community package major version based on the new ansible-core, for example, Ansible 4.0.0 based on ansible-core 2.11 - - * Newest release of the Ansible community package is the only version now maintained - * Work on new features continues in Collections - * Individual Collections can make multiple minor and major releases - -#. Minor releases of three maintained ansible-core versions every four weeks (2.11.1) -#. Minor releases of the single maintained Ansible community package version every four weeks (4.1.0) -#. Feature freeze on ansible-core -#. Release candidate for ansible-core, testing, additional release candidates as necessary -#. Release of the next ansible-core major version, cycle begins again - -Ansible community package release cycle ---------------------------------------- - -The Ansible community team typically releases two major versions of the community package per year, on a flexible release cycle that trails the release of ``ansible-core``. This cycle can be extended to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`ansible_roadmaps` for upcoming release details. Between major versions, we release a new minor version of the Ansible community package every four weeks. Minor releases include new backwards-compatible features, modules and plugins, as well as bug fixes. - -Starting with version 2.10, the Ansible community team guarantees maintenance for only one major community package release at a time. For example, when Ansible 4.0.0 gets released, the team will stop making new 3.x releases. Community members may maintain older versions if desired. - -.. note:: - - Each Ansible EOL version may issue one final maintenance release at or shortly after the first release of the next version. When this happens, the final maintenance release is EOL at the date it releases. - - -.. note:: - - Older, unmaintained versions of the Ansible community package might contain unfixed security vulnerabilities (*CVEs*). If you are using a release of the Ansible community package that is no longer maintained, we strongly encourage you to upgrade as soon as possible to benefit from the latest features and security fixes. - -Each major release of the Ansible community package accepts the latest released version of each included Collection and the latest released version of ansible-core. For specific schedules and deadlines, see the :ref:`ansible_roadmaps` for each version. Major releases of the Ansible community package can contain breaking changes in the modules and other plugins within the included Collections and in core features. - -The Ansible community package follows semantic versioning rules. Minor releases of the Ansible community package accept only backwards-compatible changes in included Collections, that is, not Collections major releases. Collections must also use semantic versioning, so the Collection version numbers reflect this rule. For example, if Ansible 3.0.0 releases with community.general 2.0.0, then all minor releases of Ansible 3.x (such as Ansible 3.1.0 or Ansible 3.5.0) must include a 2.x release of community.general (such as 2.8.0 or 2.9.5) and not 3.x.x or later major releases. - -Work in Collections is tracked within the individual Collection repositories. - -You can refer to the :ref:`Ansible package porting guides` for tips on updating your playbooks to run on newer versions of Ansible. For Ansible 2.10 and later releases, you can install the Ansible package with ``pip``. See :ref:`intro_installation_guide` for details. You can download older Ansible releases from ``_. - - -Ansible community changelogs ----------------------------- - -This table links to the changelogs for each major Ansible release. These changelogs contain the dates and significant changes in each minor release. - -================================== ============================================== ========================= -Ansible Community Package Release Status Core version dependency -================================== ============================================== ========================= -8.0.0 In development (unreleased) 2.15 -`7.x Changelogs`_ Current 2.14 -`6.x Changelogs`_ Unmaintained (end of life) after Ansible 6.7.0 2.13 -`5.x Changelogs`_ Unmaintained (end of life) 2.12 -`4.x Changelogs`_ Unmaintained (end of life) 2.11 -`3.x Changelogs`_ Unmaintained (end of life) 2.10 -`2.10 Changelogs`_ Unmaintained (end of life) 2.10 -================================== ============================================== ========================= - -.. _7.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/7/CHANGELOG-v7.rst -.. _6.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/6/CHANGELOG-v6.rst -.. _5.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/5/CHANGELOG-v5.rst -.. _4.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/4/CHANGELOG-v4.rst -.. _3.x Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/3/CHANGELOG-v3.rst -.. _2.10 Changelogs: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst - - -ansible-core release cycle --------------------------- - -``ansible-core`` is developed and released on a flexible release cycle. We can extend this cycle to properly implement and test larger changes before a new release is made available. See :ref:`ansible_core_roadmaps` for upcoming release details. - -``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. - -.. note:: - - Older, unmaintained versions of ``ansible-core`` can contain unfixed security vulnerabilities (*CVEs*). If you are using a release of ``ansible-core`` that is no longer maintained, we strongly encourage you to upgrade as soon as possible to benefit from the latest features and security fixes. ``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. - -You can refer to the :ref:`core_porting_guides` for tips on updating your playbooks to run on newer versions of ``ansible-core``. - -You can install ``ansible-core`` with ``pip``. See :ref:`intro_installation_guide` for details. - -.. _release_schedule: -.. _support_life: - -``ansible-core`` support matrix -------------------------------- - -This table links to the changelogs for each major ``ansible-core`` release. These changelogs contain the dates and significant changes in each minor release. -Dates listed indicate the start date of the maintenance cycle. - -.. list-table:: - :header-rows: 1 - - * - Version - - Support - - End Of Life - - Controller Python - - Target Python / PowerShell - * - `2.15`_ - - | GA: 22 May 2023 - | Critical: 06 Nov 2023 - | Security: 20 May 2024 - - Nov 2024 - - | Python 3.9 - 3.11 - - | Python 2.7 - | Python 3.5 - 3.11 - | PowerShell 3 - 5.1 - * - `2.14`_ - - | GA: 07 Nov 2022 - | Critical: 22 May 2023 - | Security: 06 Nov 2023 - - 20 May 2024 - - | Python 3.9 - 3.11 - - | Python 2.7 - | Python 3.5 - 3.11 - | PowerShell 3 - 5.1 - * - `2.13`_ - - | GA: 23 May 2022 - | Critical: 07 Nov 2022 - | Security: 22 May 2023 - - 06 Nov 2023 - - | Python 3.8 - 3.10 - - | Python 2.7 - | Python 3.5 - 3.10 - | PowerShell 3 - 5.1 - * - `2.12`_ - - | GA: 08 Nov 2021 - | Critical: 23 May 2022 - | Security: 07 Nov 2022 - - 22 May 2023 - - | Python 3.8 - 3.10 - - | Python 2.6 - | Python 3.5 - 3.10 - | PowerShell 3 - 5.1 - * - `2.11`_ - - | GA: 26 Apr 2021 - | Critical: 08 Nov 2021 - | Security: 23 May 2022 - - | **EOL** - | 07 Nov 2022 - - | Python 2.7 - | Python 3.5 - 3.9 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.9 - | PowerShell 3 - 5.1 - * - `2.10`_ - - | GA: 13 Aug 2020 - | Critical: 26 Apr 2021 - | Security: 08 Nov 2021 - - | **EOL** - | 23 May 2022 - - | Python 2.7 - | Python 3.5 - 3.9 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.9 - | PowerShell 3 - 5.1 - * - `2.9`_ - - | GA: 31 Oct 2019 - | Critical: 13 Aug 2020 - | Security: 26 Apr 2021 - - | **EOL** - | 23 May 2022 - - | Python 2.7 - | Python 3.5 - 3.8 - - | Python 2.6 - 2.7 - | Python 3.5 - 3.8 - | PowerShell 3 - 5.1 -.. * - 2.16 -.. - 06 Nov 2023 -.. - 20 May 2024 -.. - Nov 2024 -.. - May 2025 -.. - | Python 3.10 - 3.12 -.. - | Python 3.6 - 3.12 -.. | PowerShell TBD -.. * - 2.17 -.. - 20 May 2024 -.. - Nov 2024 -.. - May 2025 -.. - Nov 2025 -.. - | Python 3.10 - 3.12 -.. - | Python 3.6 - 3.12 -.. | PowerShell TBD -.. * - 2.18 -.. - Nov 2024 -.. - May 2025 -.. - Nov 2025 -.. - May 2026 -.. - | Python 3.11 - 3.13 -.. - | Python 3.6 - 3.13 -.. | PowerShell TBD -.. * - 2.19 -.. - May 2025 -.. - Nov 2025 -.. - May 2026 -.. - Nov 2026 -.. - | Python 3.11 - 3.13 -.. - | Python 3.6 - 3.13 -.. | PowerShell TBD -.. * - 2.20 -.. - Nov 2025 -.. - May 2026 -.. - Nov 2026 -.. - May 2027 -.. - | Python 3.12 - 3.14 -.. - | Python 3.8 - 3.14 -.. | PowerShell TBD -.. * - 2.21 -.. - May 2026 -.. - Nov 2026 -.. - May 2027 -.. - Nov 2027 -.. - | Python 3.12 - 3.14 -.. - | Python 3.8 - 3.14 -.. | PowerShell TBD -.. * - 2.22 -.. - Nov 2026 -.. - May 2027 -.. - Nov 2027 -.. - May 2028 -.. - | Python 3.13 - 3.15 -.. - | Python 3.8 - 3.15 -.. | PowerShell TBD -.. * - 2.23 -.. - May 2027 -.. - Nov 2027 -.. - May 2028 -.. - Nov 2028 -.. - | Python 3.13 - 3.15 -.. - | Python 3.8 - 3.15 -.. | PowerShell TBD -.. * - 2.24 -.. - Nov 2027 -.. - May 2028 -.. - Nov 2028 -.. - May 2029 -.. - | Python 3.14 - 3.16 -.. - | Python 3.8 - 3.16 -.. | PowerShell TBD -.. * - 2.25 -.. - May 2028 -.. - Nov 2028 -.. - May 2029 -.. - Nov 2029 -.. - | Python 3.14 - 3.16 -.. - | Python 3.8 - 3.16 -.. | PowerShell TBD - - -.. _2.9: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst -.. _2.10: https://github.com/ansible/ansible/blob/stable-2.10/changelogs/CHANGELOG-v2.10.rst -.. _2.11: https://github.com/ansible/ansible/blob/stable-2.11/changelogs/CHANGELOG-v2.11.rst -.. _2.12: https://github.com/ansible/ansible/blob/stable-2.12/changelogs/CHANGELOG-v2.12.rst -.. _2.13: https://github.com/ansible/ansible/blob/stable-2.13/changelogs/CHANGELOG-v2.13.rst -.. _2.14: https://github.com/ansible/ansible/blob/stable-2.14/changelogs/CHANGELOG-v2.14.rst -.. _2.15: https://github.com/ansible/ansible/blob/stable-2.15/changelogs/CHANGELOG-v2.15.rst - - -Preparing for a new release -=========================== - -.. _release_freezing: - -Feature freezes ---------------- - -During final preparations for a new release, core developers and maintainers focus on improving the release candidate, not on adding or reviewing new features. We may impose a feature freeze. - -A feature freeze means that we delay new features and fixes unrelated to the pending release so we can create the new release as soon as possible. - - - -Release candidates ------------------- - -We create at least one release candidate before each new major release of Ansible or ``ansible-core``. Release candidates allow the Ansible community to try out new features, test existing playbooks on the release candidate, and report bugs or issues they find. - -Ansible and ``ansible-core`` tag the first release candidate (RC1) which is usually scheduled to last five business days. If no major bugs or issues are identified during this period, the release candidate becomes the final release. - -If there are major problems with the first candidate, the team and the community fix them and tag a second release candidate (RC2). This second candidate lasts for a shorter duration than the first. If no problems have been reported for an RC2 after two business days, the second release candidate becomes the final release. - -If there are major problems in RC2, the cycle begins again with another release candidate and repeats until the maintainers agree that all major problems have been fixed. - - -.. _development_and_stable_version_maintenance_workflow: - -Development and maintenance workflows -===================================== - -In between releases, the Ansible community develops new features, maintains existing functionality, and fixes bugs in ``ansible-core`` and in the collections included in the Ansible community package. - -Ansible community package workflow ----------------------------------- - -The Ansible community develops and maintains the features and functionality included in the Ansible community package in Collections repositories, with a workflow that looks like this: - - * Developers add new features and bug fixes to the individual Collections, following each Collection's rules on contributing. - * Each new feature and each bug fix includes a changelog fragment describing the work. - * Release engineers create a minor release for the current version every four weeks to ensure that the latest bug fixes are available to users. - * At the end of the development period, the release engineers announce which Collections, and which major version of each included Collection, will be included in the next release of the Ansible community package. New Collections and new major versions may not be added after this, and the work of creating a new release begins. - -We generally do not provide fixes for unmaintained releases of the Ansible community package, however, there can sometimes be exceptions for critical issues. - -Some Collections are maintained by the Ansible team, some by Partner organizations, and some by community teams. For more information on adding features or fixing bugs in Ansible-maintained Collections, see :ref:`contributing_maintained_collections`. - -ansible-core workflow ---------------------- - -The Ansible community develops and maintains ``ansible-core`` on GitHub_, with a workflow that looks like this: - - * Developers add new features and bug fixes to the ``devel`` branch. - * Each new feature and each bug fix includes a changelog fragment describing the work. - * The development team backports bug fixes to one, two, or three stable branches, depending on the severity of the bug. They do not backport new features. - * Release engineers create a minor release for each maintained version every four weeks to ensure that the latest bug fixes are available to users. - * At the end of the development period, the release engineers impose a feature freeze and the work of creating a new release begins. - -We generally do not provide fixes for unmaintained releases of ``ansible-core``, however, there can sometimes be exceptions for critical issues. - -For more information about adding features or fixing bugs in ``ansible-core`` see :ref:`community_development_process`. - -.. _GitHub: https://github.com/ansible/ansible - -.. _release_changelogs: - -Generating changelogs ----------------------- - -We generate changelogs based on fragments. When creating new features for existing modules and plugins 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. - -To add changelog fragments to Collections in the Ansible community package, we recommend the `antsibull-changelog utility `_. - -To add changelog fragments for new features and bug fixes in ``ansible-core``, see the :ref:`changelog examples and instructions` in the Community Guide. - -Deprecation cycles -================== - -Sometimes we 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. - -Ansible community package deprecation cycle --------------------------------------------- - -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 3.1.0 and do not remove the feature until 5.0.0 or 4.0.0 at the earliest. Collections should use semantic versioning, such that the major collection version cannot be changed within an Ansible major version. Therefore, the removal should not happen before the next major Ansible community package release. This is up to each collection maintainer and cannot be guaranteed. - -ansible-core deprecation cycle -------------------------------- - -The deprecation cycle in ``ansible-core`` is normally across 4 feature releases (2.x. where the x marks a feature release). The feature is normally removed in the 4th release after we announce the deprecation. For example, something deprecated in 2.10 will be removed in 2.14. The tracking is tied to the number of releases, not the release numbering itself. - -.. seealso:: - - :ref:`community_committer_guidelines` - Guidelines for Ansible core contributors and maintainers - :ref:`testing_strategies` - Testing strategies - :ref:`ansible_community_guide` - Community information and contributing - `Development Mailing List `_ - Mailing list for development topics - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/special_variables.rst b/docs/docsite/rst/reference_appendices/special_variables.rst deleted file mode 100644 index 73bd07c0866..00000000000 --- a/docs/docsite/rst/reference_appendices/special_variables.rst +++ /dev/null @@ -1,173 +0,0 @@ -.. _special_variables: - -Special Variables -================= - -Magic variables ---------------- -These variables cannot be set directly by the user; Ansible will always override them to reflect internal state. - -.. glossary:: - - ansible_check_mode - Boolean that indicates if we are in check mode or not - - ansible_config_file - The full path of used Ansible configuration file - - ansible_dependent_role_names - The names of the roles currently imported into the current play as dependencies of other plays - - ansible_diff_mode - Boolean that indicates if we are in diff mode or not - - ansible_forks - Integer reflecting the number of maximum forks available to this run - - ansible_inventory_sources - List of sources used as inventory - - ansible_limit - Contents of the ``--limit`` CLI option for the current execution of Ansible - - ansible_loop - A dictionary/map containing extended loop information when enabled through ``loop_control.extended`` - - ansible_loop_var - The name of the value provided to ``loop_control.loop_var``. Added in ``2.8`` - - ansible_index_var - The name of the value provided to ``loop_control.index_var``. Added in ``2.9`` - - ansible_parent_role_names - When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` 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. - - 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']``. - - ansible_parent_role_paths - When the current role is being executed by means of an :ref:`include_role ` or :ref:`import_role ` action, this variable contains a list of all parent roles paths, 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. - - ansible_play_batch - List of active hosts in the current play run limited by the serial, aka 'batch'. Failed/Unreachable hosts are not considered 'active'. - - ansible_play_hosts - List of hosts in the current play run, not limited by the serial. Failed/Unreachable hosts are excluded from this list. - - ansible_play_hosts_all - List of all the hosts that were targeted by the play - - ansible_play_role_names - The names of the roles currently imported into the current play. This list does **not** contain the role names that are - implicitly included through dependencies. - - ansible_playbook_python - The path to the python interpreter being used by Ansible on the controller - - ansible_role_names - The names of the roles currently imported into the current play, or roles referenced as dependencies of the roles - imported into the current play. - - ansible_role_name - The fully qualified collection role name, in the format of ``namespace.collection.role_name`` - - ansible_collection_name - The name of the collection the task that is executing is a part of. In the format of ``namespace.collection`` - - ansible_run_tags - 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"]``. - - ansible_search_path - Current search path for action plugins and lookups, in other words, where we search for relative paths when you do ``template: src=myfile`` - - ansible_skip_tags - Contents of the ``--skip-tags`` CLI option, which specifies which tags will be skipped for the current run. - - ansible_verbosity - Current verbosity setting for Ansible - - ansible_version - Dictionary/map that contains information about the current running version of ansible, it has the following keys: full, major, minor, revision and string. - - group_names - List of groups the current host is part of - - groups - A dictionary/map with all the groups in inventory and each group has the list of hosts that belong to it - - hostvars - A dictionary/map with all the hosts in inventory and variables assigned to them - - inventory_hostname - The inventory name for the 'current' host being iterated over in the play - - inventory_hostname_short - The short version of `inventory_hostname` - - inventory_dir - The directory of the inventory source in which the `inventory_hostname` was first defined - - inventory_file - The file name of the inventory source in which the `inventory_hostname` was first defined - - omit - Special variable that allows you to 'omit' an option in a task, for example ``- user: name=bob home={{ bobs_home|default(omit) }}`` - - play_hosts - Deprecated, the same as ansible_play_batch - - ansible_play_name - The name of the currently executed play. Added in ``2.8``. (`name` attribute of the play, not file name of the playbook.) - - playbook_dir - The path to the directory of the current playbook being executed. NOTE: This might be different than directory of the playbook passed to the ``ansible-playbook`` command line when a playbook contains a ``import_playbook`` statement. - - role_name - The name of the role currently being executed. - - role_names - Deprecated, the same as ansible_play_role_names - - role_path - The path to the dir of the currently running role - -Facts ------ -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. - -.. glossary:: - - ansible_facts - Contains any facts gathered or cached for the `inventory_hostname` - Facts are normally gathered by the :ref:`setup ` module automatically in a play, but any module can return facts. - - ansible_local - Contains any 'local facts' gathered or cached for the `inventory_hostname`. - The keys available depend on the custom facts created. - See the :ref:`setup ` module and :ref:`local_facts` for more details. - -.. _connection_variables: - -Connection variables ---------------------- -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`, :ref:`command-line options`, and :ref:`playbook keywords`. - -.. glossary:: - - ansible_become_user - The user Ansible 'becomes' after using privilege escalation. This must be available to the 'login user'. - - ansible_connection - The connection plugin actually used for the task on the target host. - - ansible_host - The ip/name of the target host to use instead of `inventory_hostname`. - - ansible_python_interpreter - The path to the Python executable Ansible should use on the target host. - - ansible_user - The user Ansible 'logs in' as. diff --git a/docs/docsite/rst/reference_appendices/test_strategies.rst b/docs/docsite/rst/reference_appendices/test_strategies.rst deleted file mode 100644 index fa28f76b7f0..00000000000 --- a/docs/docsite/rst/reference_appendices/test_strategies.rst +++ /dev/null @@ -1,303 +0,0 @@ -.. _testing_strategies: - -Testing Strategies -================== - -.. _testing_intro: - -Integrating Testing With Ansible Playbooks -`````````````````````````````````````````` - -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. - -.. note:: 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. - -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 used 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. - -The Right Level of Testing -`````````````````````````` - -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. - -.. code-block:: yaml - - tasks: - - ansible.builtin.service: - name: foo - state: started - enabled: true - -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). - -.. _check_mode_drift: - -Check Mode As A Drift Test -`````````````````````````` - -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. - -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: - -.. code:: yaml - - - roles: - - webserver - - tasks: - - ansible.builtin.script: verify.sh - check_mode: false - -Modules That Are Useful for Testing -``````````````````````````````````` - -Certain playbook modules are particularly good for testing. Below is an example that ensures a port is open: - -.. code:: yaml - - tasks: - - - ansible.builtin.wait_for: - host: "{{ inventory_hostname }}" - port: 22 - delegate_to: localhost - -Here's an example of using the URI module to make sure a web service returns: - -.. code:: yaml - - tasks: - - - action: uri url=https://www.example.com return_content=yes - register: webpage - - - fail: - msg: 'service is not happy' - when: "'AWESOME' not in webpage.content" - -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: - -.. code:: yaml - - tasks: - - - ansible.builtin.script: test_script1 - - ansible.builtin.script: test_script2 --parameter value --parameter2 value - -If using roles (you should be, roles are great!), scripts pushed by the script module can live in the 'files/' directory of a role. - -And the assert module makes it very easy to validate various kinds of truth: - -.. code:: yaml - - tasks: - - - ansible.builtin.shell: /usr/bin/some-command --parameter value - register: cmd_result - - - ansible.builtin.assert: - that: - - "'not ready' not in cmd_result.stderr" - - "'gizmo enabled' in cmd_result.stdout" - -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: - -.. code:: yaml - - tasks: - - - ansible.builtin.stat: - path: /path/to/something - register: p - - - ansible.builtin.assert: - that: - - p.stat.exists and p.stat.isdir - - -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. - -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. - -Testing Lifecycle -````````````````` - -If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy. - -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. - -Your workflow may be something like this: - -.. code:: text - - - Use the same playbook all the time with embedded tests in development - - Use the playbook to deploy to a staging environment (with the same playbooks) that simulates production - - Run an integration test battery written by your QA team against staging - - Deploy to production, with the same integrated tests. - -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. - -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. - -Integrating Testing With Rolling Updates -```````````````````````````````````````` - -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. - -This is the great culmination of embedded tests: - -.. code:: yaml - - --- - - - hosts: webservers - serial: 5 - - pre_tasks: - - - name: take out of load balancer pool - ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - - tasks: - - - ansible.builtin.include_role: - name: "{{ item }}" - loop: - - common - - webserver - - - name: run any notified handlers - ansible.builtin.meta: flush_handlers - - - name: test the configuration - ansible.builtin.include_role: - name: apply_testing_checks - - post_tasks: - - - name: add back to load balancer pool - ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - -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. - -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. - -Read the delegation chapter about "max_fail_percentage" and you can also control how many failing tests will stop a rolling update -from proceeding. - -This above approach can also be modified to run a step from a testing machine remotely against a machine: - -.. code:: yaml - - --- - - - hosts: webservers - serial: 5 - - pre_tasks: - - - name: take out of load balancer pool - ansible.builtin.command: /usr/bin/take_out_of_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - - roles: - - - common - - webserver - - tasks: - - ansible.builtin.script: /srv/qa_team/app_testing_script.sh --server {{ inventory_hostname }} - delegate_to: testing_server - - post_tasks: - - - name: add back to load balancer pool - ansible.builtin.command: /usr/bin/add_back_to_pool {{ inventory_hostname }} - delegate_to: 127.0.0.1 - -In the above example, a script is run from the testing server against a remote node prior to bringing it back into -the pool. - -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. - -Achieving Continuous Deployment -``````````````````````````````` - -If desired, the above techniques may be extended to enable continuous deployment practices. - -The workflow may look like this: - -.. code:: text - - - Write and use automation to deploy local development VMs - - Have a CI system like Jenkins deploy to a staging environment on every code change - - The deploy job calls testing scripts to pass/fail a build on every deploy - - If the deploy job succeeds, it runs the same deploy playbook against production inventory - -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. - -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'. - -Conclusion -`````````` - -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. - -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. - -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. - -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. - -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. - -.. seealso:: - - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`working_with_playbooks` - An introduction to playbooks - :ref:`playbooks_delegation` - Delegation, useful for working with load balancers, clouds, and locally executed steps. - `User Mailing List `_ - Have a question? Stop by the google group! - :ref:`communication_irc` - How to join Ansible chat channels diff --git a/docs/docsite/rst/reference_appendices/tower.rst b/docs/docsite/rst/reference_appendices/tower.rst deleted file mode 100644 index 3537d606b1e..00000000000 --- a/docs/docsite/rst/reference_appendices/tower.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _ansible_platform: - -Red Hat Ansible Automation Platform -=================================== - -.. important:: - - Red Hat Ansible Automation Platform is available on multiple cloud platforms. See `Ansible on Clouds `_ for details. - -`Red Hat Ansible Automation Platform `_ (RHAAP) is an integrated solution for operationalizing Ansible across your team, organization, and enterprise. The platform includes a controller with a web console and REST API, analytics, execution environments, and much more. - -RHAAP gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model complex processes. - -RHAAP 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. - -RHAAP incorporates the downstream Red Hat supported product version of Ansible AWX, the downstream Red Hat supported product version of Ansible Galaxy, and multiple SaaS offerings. Find out more about RHAAP features and on the `Red Hat Ansible Automation Platform webpage `_. A Red Hat Ansible Automation Platform subscription includes support from Red Hat, Inc. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst b/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst deleted file mode 100644 index 72fdc9cfb3a..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst +++ /dev/null @@ -1,51 +0,0 @@ -==================== -Ansible project 2.10 -==================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_10` for the most recent updates on ansible-base. - -.. contents:: - :local: - -Release Schedule ----------------- - -.. note:: Dates subject to change. -.. note:: We plan to post weekly alpha releases to the `PyPI ansible project `_ for testing. - -.. warning:: - We initially were going to have feature freeze on 2020-08-18. We tried this but decided to - change course. Instead, we'll enter feature freeze when ansible-2.10.0 beta1 is released. - -- 2020-06-23: ansible-2.10 alpha freeze. - No net new collections will be added to the ``ansible-2.10`` package after this date. -- 2020-07-10: Ansible collections freeze date for content shuffling. - Content should be in its final collection for the ansible-2.10 series of releases. No more content should move out of the ``community.general`` or ``community.network`` collections. -- 2020-08-13: ansible-base 2.10 Release date, see :ref:`base_roadmap_2_10`. -- 2020-08-14: final ansible-2.10 alpha. -- 2020-09-01: ansible-2.10.0 beta1 and feature freeze. - - - No new modules or major features will be added after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-1.1.0; ansible-2.10.0 could ship with community-crypto-1.1.1. It would not ship with community-crypto-1.2.0. - -- 2020-09-08: ansible-2.10.0 beta2. -- 2020-09-15: ansible-2.10.0 rc1 and final freeze. - - - After this date only changes blocking a release are accepted. - - Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at the community meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_. - -** Additional release candidates to be published as needed as blockers are fixed ** - -- 2020-09-22: ansible-2.10 GA release date. - -Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0). - - -.. note:: - - Minor releases will stop when :ref:`Ansible-3 ` is released. See the :ref:`Release and Maintenance Page ` for more information. - - -Breaking changes may be introduced in ansible-3.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_3_0.rst b/docs/docsite/rst/roadmap/COLLECTIONS_3_0.rst deleted file mode 100644 index e40d49c0315..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_3_0.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _ansible_3_roadmap: - -=================== -Ansible project 3.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-base `_ package as well. All dates are subject to change. Ansible 3.x.x includes ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for the most recent updates on ``ansible-base``. - -.. contents:: - :local: - -Release schedule -================= - -.. note:: - - Ansible is switching from its traditional versioning scheme to `semantic versioning `_ starting with this release. So this version is 3.0.0 instead of 2.11.0. - - - -:2020-12-16: Finalize rules for net-new collections submitted for the ansible release. -:2021-01-27: Final day for new collections to be **reviewed and approved**. They MUST be - submitted prior to this to give reviewers a chance to look them over and for collection owners - to fix any problems. -:2021-02-02: Ansible-3.0.0-beta1 -- feature freeze [1]_ -:2021-02-09: Ansible-3.0.0-rc1 -- final freeze [2]_ [3]_ -:2021-02-16: Release of Ansible-3.0.0 -:2021-03-09: Release of Ansible-3.1.0 (bugfix + compatible features: every three weeks) - -.. [1] No new modules or major features accepted after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_. - - -.. note:: - - Breaking changes may be introduced in Ansible 3.0.0, although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before the breaking change happens. - - -Ansible minor releases -======================= - -Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-3.0.0 ships with community-crypto-2.1.0; Ansible-3.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0). - - -.. note:: - - Minor releases will stop when :ref:`Ansible-4 ` is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. - - -ansible-base release -==================== - -Ansible 3.x.x works with ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_4.rst b/docs/docsite/rst/roadmap/COLLECTIONS_4.rst deleted file mode 100644 index 2bcebb54cbd..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_4.rst +++ /dev/null @@ -1,55 +0,0 @@ -.. _ansible_4_roadmap: - -=================== -Ansible project 4.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_11` for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2021-01-26: New Collections will be reviewed for inclusion in Ansible 4. Submit a request to include a new collection in this `GitHub Discussion `_. -:2021-03-03: Ansible-4.0.0 alpha1 (biweekly ``ansible`` alphas. These are timed to coincide with the start of the ``ansible-core-2.11`` pre-releases). -:2021-03-16: Ansible-4.0.0 alpha2 -:2021-03-30: Ansible-4.0.0 alpha3 -:2021-04-13: Last day for new collections to be submitted for inclusion in Ansible 4. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion. -:2021-04-13: Ansible-4.0.0 alpha4 -:2021-04-14: Community Meeting topic: list any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate. -:2021-04-21: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2021-04-26: Last day for new collections to be **reviewed and approved** for inclusion in Ansible 4. -:2021-04-26: Last day for collections to make backwards incompatible releases that will be accepted into Ansible 4. -:2021-04-27: Ansible-4.0.0 beta1 -- feature freeze [1]_ (weekly beta releases. Collection owners and interested users should test for bugs). -:2021-05-04: Ansible-4.0.0 beta2 -:2021-05-11: Ansible-4.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed. Test and alert us to any blocker bugs). -:2021-05-18: Ansible-4.0.0 release -:2021-06-08: Release of Ansible-4.1.0 (bugfix + compatible features: every three weeks) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a Community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda `_. - - -.. note:: - - Breaking changes will be introduced in Ansible 4.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 4.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.11.x. Ansible 4.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-4.0.0 ships with community-crypto-2.1.0; Ansible-4.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0). - - -.. note:: - - Minor releases will stop when Ansible-5 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_5.rst b/docs/docsite/rst/roadmap/COLLECTIONS_5.rst deleted file mode 100644 index 9789cd8b934..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_5.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _ansible_5_roadmap: - -=================== -Ansible project 5.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See :ref:`core_roadmap_2_12` for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - -:2021-04-14: New Collections can be reviewed for inclusion in Ansible 5. Submit a request to include a new collection in this `GitHub Discussion `_. -:2021-09-24: ansible-core feature freeze. -:2021-09-27: Start of ansible-core 2.12 betas (weekly, as needed). -:2021-10-05: Ansible-5.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.12`` pre-releases). -:2021-10-12: Last day for new collections to be submitted for inclusion in Ansible-5. Collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion. -:2021-10-13: Community Meeting topic: List any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate. -:2021-10-18: First ansible-core release candidate, stable-2.12 branch created. -:2021-10-19: Ansible-5.0.0 alpha2. -:2021-10-26: Last day for new collections to be **reviewed and approved** for inclusion in Ansible-5. -:2021-10-27: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2021-11-02: Ansible-5.0.0 alpha3. -:2021-11-08: Ansible-core-2.12 released. -:2021-11-08: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-5. -:2021-11-09: Create the ansible-build-data directory and files for Ansible-6. New collection approvals will target this. -:2021-11-09: Ansible-5.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2021-11-16: Ansible-5.0.0 beta2. -:2021-11-23: Ansible-5.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2021-11-30: Ansible-5.0.0 release. -:2021-12-21: Release of Ansible-5.1.0 (bugfix + compatible features: every three weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.1.0; Ansible-5.0.0 could ship with community.crypto 2.1.1. It would not ship with community.crypto 2.2.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 5.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 5.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.12.x. Ansible 5.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-5.0.0 ships with community.crypto 2.1.0; Ansible-5.1.0 may ship with community.crypto 2.2.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor releases will stop when Ansible-6 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_6.rst b/docs/docsite/rst/roadmap/COLLECTIONS_6.rst deleted file mode 100644 index 957c989df5f..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_6.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _ansible_6_roadmap: - -=================== -Ansible project 6.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.13 Roadmap `_ for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2022-03-28: ansible-core feature freeze, stable-2.13 branch created. -:2022-04-11: Start of ansible-core 2.13 betas (biweekly, as needed). -:2022-04-12: Ansible-6.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.13`` pre-releases). -:2022-04-27: Community Meeting topic: List any backwards incompatible collection releases that beta1 should try to accommodate. -:2022-05-02: First ansible-core release candidate. -:2022-05-03: Ansible-6.0.0 alpha2. -:2022-05-11: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2022-05-16: Ansible-core-2.13 released. -:2022-05-17: Ansible-6.0.0 alpha3. -:2022-05-23: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-6. This includes adding new collections to Ansible 6.0.0; from now on new collections have to wait for 6.1.0 or later. -:2022-05-24: Create the ansible-build-data directory and files for Ansible-7. -:2022-05-24: Ansible-6.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2022-05-31: Ansible-6.0.0 beta2. -:2022-06-07: Ansible-6.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2022-06-21: Ansible-6.0.0 release. -:2022-07-12: Release of Ansible-6.1.0 (bugfix + compatible features: every three weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-6.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 6.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 6.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.13.x. Ansible 6.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-6.0.0 ships with community.crypto 2.3.0; Ansible-6.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor releases will stop when Ansible-7 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. - -Planned work -============ - -More details can be found in `the community-topics planning issue `_. - -* Remove compatibility code which prevents parallel install of Ansible 6 with Ansible 2.9 or ansible-base 2.10 -* Stop installing files (such as tests and development artifacts like editor configs) we have no use for -* Ship Python wheels (as ansible-core 2.13 will likely also do) to improve installation performance diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_7.rst b/docs/docsite/rst/roadmap/COLLECTIONS_7.rst deleted file mode 100644 index dcd9262142b..00000000000 --- a/docs/docsite/rst/roadmap/COLLECTIONS_7.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. _ansible_7_roadmap: - -=================== -Ansible project 7.0 -=================== - -This release schedule includes dates for the `ansible `_ package, with a few dates for the `ansible-core `_ package as well. All dates are subject to change. See the `ansible-core 2.14 Roadmap `_ for the most recent updates on ``ansible-core``. - -.. contents:: - :local: - - -Release schedule -================= - - -:2022-09-19: ansible-core feature freeze, stable-2.14 branch created. -:2022-09-26: Start of ansible-core 2.14 betas (biweekly, as needed). -:2022-09-27: Ansible-7.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.14`` pre-releases). -:2022-10-12: Community topic: List any backwards incompatible collection releases that beta1 should try to accommodate. -:2022-10-17: First ansible-core 2.14 release candidate. -:2022-10-25: Ansible-7.0.0 alpha2. -:2022-10-26: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. -:2022-11-07: Ansible-core-2.14.0 released. -:2022-11-07: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-7. This includes adding new collections to Ansible 7.0.0; from now on new collections have to wait for 7.1.0 or later. -:2022-11-08: Create the ansible-build-data directory and files for Ansible-8. -:2022-11-08: Ansible-7.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs). -:2022-11-15: Ansible-7.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. -:2022-11-18: Last day to trigger an Ansible-7.0.0rc2 release because of major defects in Ansible-7.0.0rc1. -:2022-11-22: Ansible-7.0.0rc2 when necessary, otherwise Ansible-7.0.0 release. -:2022-11-29: Ansible-7.0.0 release when Ansible-7.0.0rc2 was necessary. -:2022-12-05: Release of ansible-core 2.14.1. -:2022-12-06: Release of Ansible-7.1.0 (bugfix + compatible features: every four weeks.) - -.. [1] No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-7.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. - -.. [2] After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. - -.. [3] Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda `_. - -.. note:: - - Breaking changes will be introduced in Ansible 7.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. - - -Ansible minor releases -======================= - -Ansible 7.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.14.x. Ansible 7.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-7.0.0 ships with community.crypto 2.3.0; Ansible-7.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. - - -.. note:: - - Minor releases will stop when Ansible-8 is released. See the :ref:`Release and Maintenance Page ` for more information. - - -For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_10.rst b/docs/docsite/rst/roadmap/ROADMAP_2_10.rst deleted file mode 100644 index d303ca4682c..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_10.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _base_roadmap_2_10: - -================= -Ansible-base 2.10 -================= - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-base release. - -.. note:: There is no Alpha phase in 2.10. -.. note:: Dates subject to change. - -- 2020-06-16 Beta 1 **Feature freeze** - No new functionality (including modules/plugins) to any code - -- 2020-07-21 Release Candidate 1 (bumped from 2020-07-14) -- 2020-07-24 Release Candidate 2 -- 2020-07-25 Release Candidate 3 -- 2020-07-30 Release Candidate 4 -- 2020-08-13 Release - -Release Manager ---------------- - -@sivel - -Planned work -============ - -- Migrate non-base plugins and modules from the ``ansible/ansible`` repository to smaller collection repositories -- Add functionality to ease transition to collections, such as automatic redirects from the 2.9 names to the new FQCN of the plugin -- Create new ``ansible-base`` package representing the ``ansible/ansible`` repository - -Additional Resources -==================== - -The 2.10 release of Ansible will fundamentally change the scope of plugins included in the ``ansible/ansible`` repository, by -moving much of the plugins into smaller collection repositories that will be shipped through https://galaxy.ansible.com/ - -The following links have more information about this process: - -- https://groups.google.com/d/msg/ansible-devel/oKqgCeYTs-M/cHrOgMw8CAAJ -- https://github.com/ansible-collections/overview/blob/main/README.rst diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_11.rst b/docs/docsite/rst/roadmap/ROADMAP_2_11.rst deleted file mode 100644 index 3fa3b6bab5f..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_11.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _base_roadmap_2_11: - -================= -Ansible-core 2.11 -================= - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: There is no Alpha phase in 2.11. -.. note:: Dates subject to change. - -- 2021-02-12 Feature Freeze - No new functionality (including modules/plugins) to any code - -- 2021-03-02 Beta 1 -- 2021-03-15 Beta 2 (if necessary) - -- 2021-03-29 Release Candidate 1 (and ``stable-2.11`` branching from ``devel``) -- 2021-04-12 Release Candidate 2 (if necessary) - -- 2021-04-26 Release - -Release Manager ---------------- - - Ansible Core Team - -Planned work -============ - -- Rename ``ansible-base`` to ``ansible-core``. -- Improve UX of ``ansible-galaxy collection`` CLI, specifically as it relates to install and upgrade. -- Add new Role Argument Spec feature that will allow a role to define an argument spec to be used in - validating variables used by the role. -- Bump the minimum Python version requirement for the controller to Python 3.8. There will be no breaking changes - to this release, however ``ansible-core`` will only be packaged for Python 3.8+. ``ansible-core==2.12`` will include - breaking changes requiring at least Python 3.8. -- Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from - dependencies on the target. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_12.rst b/docs/docsite/rst/roadmap/ROADMAP_2_12.rst deleted file mode 100644 index c0a7ccdbdc8..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_12.rst +++ /dev/null @@ -1,50 +0,0 @@ -.. _core_roadmap_2_12: - -================= -Ansible-core 2.12 -================= - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: There is no Alpha phase in 2.12. -.. note:: Dates subject to change. - -- 2021-09-24 Feature Freeze (and ``stable-2.12`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2021-09-27 Beta 1 -- 2021-10-04 Beta 2 (if necessary) - -- 2021-10-18 Release Candidate 1 -- 2021-10-25 Release Candidate 2 (if necessary) - -- 2021-11-08 Release - -Release Manager ---------------- - - Ansible Core Team - -Planned work -============ - -- Bump the minimum Python version requirement for the controller to Python 3.8. This will be a hard requirement. -- Deprecate Python 2.6 support for managed/target hosts. The release of ``ansible-core==2.13`` will remove Python 2.6 support. -- Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from dependencies on the target. -- Extend the functionality of ``module_defaults`` ``action_groups`` to be created and presented by collections. - -Delayed work -============ - -The following work has been delayed and retargeted for a future release - -- Implement object proxies, to expose restricted interfaces between parts of the code, and enable deprecations of attributes and variables. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_13.rst b/docs/docsite/rst/roadmap/ROADMAP_2_13.rst deleted file mode 100644 index 00b994a5706..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_13.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _core_roadmap_2_13: - -***************** -Ansible-core 2.13 -***************** - -.. contents:: - :local: - -Release Schedule -================ - -Expected --------- - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: There is no Alpha phase in 2.13. -.. note:: Dates subject to change. - -Development Phase -^^^^^^^^^^^^^^^^^ - -The ``milestone`` branch will be advanced at the start date of each development phase. - -- 2021-09-27 Development Phase 1 -- 2021-12-13 Development Phase 2 -- 2022-02-14 Development Phase 3 - -Release Phase -^^^^^^^^^^^^^ - -- 2022-03-28 Feature Freeze (and ``stable-2.13`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2022-04-11 Beta 1 -- 2022-04-25 Beta 2 (if necessary) - -- 2022-05-02 Release Candidate 1 - -- 2022-05-16 Release - -Release Manager -=============== - - Ansible Core Team - -Planned work -============ - -* ``ansible-doc`` extended dump support for devtools integration -* ``ansible-galaxy`` CLI collection verification, source, and trust -* ``jinja2`` 3.0+ dependency -* Consolidate template handling to always use ``jinja2`` native -* Drop Python 2.6 support for module execution -* Update the collection loader to Python 3.x loader API, due to removal of the Python 2 API in Python 3.12 -* Modernize python packaging and installation - -Delayed work -============ - -The following work has been delayed and retargeted for a future release - -* Data Tagging -* Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_14.rst b/docs/docsite/rst/roadmap/ROADMAP_2_14.rst deleted file mode 100644 index 0f0bbea8219..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_14.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _core_roadmap_2.14: - -***************** -Ansible-core 2.14 -***************** - -.. contents:: - :local: - -Release Schedule -================ - -Expected --------- - -PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. - -.. note:: Dates subject to change. - -Development Phase -^^^^^^^^^^^^^^^^^ - -The ``milestone`` branch will be advanced at the start date of each development phase. - -- 2022-05-02 Development Phase 1 -- 2022-06-27 Development Phase 2 -- 2022-08-08 Development Phase 3 - -Release Phase -^^^^^^^^^^^^^ - -- 2022-09-19 Feature Freeze (and ``stable-2.14`` branching from ``devel``) - No new functionality (including modules/plugins) to any code - -- 2022-09-26 Beta 1 - -- 2022-10-17 Release Candidate 1 - -- 2022-11-07 Release - -.. note:: The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. - -Release Manager -=============== - - Ansible Core Team - -Planned work -============ - -* Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules -* Proxy Display over queue from forks -* Move handler processing into new PlayIterator phase to use the configured strategy -* Convert FieldAttribute to data descriptors to avoid complex meta classes -* Drop Python 3.8 support for controller -* Enforce running controller code with the Python locale and filesystem encoding set to UTF-8 - -Delayed work -============ - -The following work has been delayed and retargeted for a future release: - -* Data Tagging diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_5.rst b/docs/docsite/rst/roadmap/ROADMAP_2_5.rst deleted file mode 100644 index 802a4790f1d..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_5.rst +++ /dev/null @@ -1,142 +0,0 @@ -=========== -Ansible 2.5 -=========== -**Core Engine Freeze and Module Freeze: 22 January 2018** - -**Core and Curated Module Freeze: 22 January 2018** - -**Community Module Freeze: 7 February 2018** - -**Release Candidate 1 will be 21 February, 2018** - -**Target: March 2018** - -**Service Release schedule: every 2-3 weeks** - -.. contents:: Topics - -Release Manager ---------------- -Matt Davis (IRC/GitHub: @nitzmahone) - - -Engine improvements -------------------- -- Assemble module improvements - - assemble just skips when in check mode, it should be able to test if there is a difference and changed=true/false. - - The same with diff, it should work as template modules does -- Handle Password reset prompts cleaner -- Tasks stats for rescues and ignores -- Normalize temp dir usage across all subsystems -- Add option to set playbook dir for adhoc, inventory and console to allow for 'relative path loading' - - -Ansible-Config --------------- -- Extend config to more plugin types and update plugins to support the new config - -Inventory ---------- -- ansible-inventory option to output group variable assignment and data (--export) -- Create inventory plugins for: - - aws - -Facts ------ -- Namespacing fact variables (via a config option) implemented in ansible/ansible PR `#18445 `_. - Proposal found in ansible/proposals issue `#17 `_. -- Make fact collectors and gather_subset specs finer grained -- Eliminate unneeded deps between fact collectors -- Allow fact collectors to indicate if they need information from another fact collector to be gathered first. - -Static Loop Keyword -------------------- - -- A simpler alternative to ``with_``, ``loop:`` only takes a list -- Remove complexity from loops, lookups are still available to users -- Less confusing having a static directive vs a one that is dynamic depending on plugins loaded. - -Vault ------ -- Vault secrets client inc new 'keyring' client - -Runtime Check on Modules for Disabling --------------------------------------- -- Filter on things like "supported_by" in module metadata -- Provide users with an option of "warning, error or allow/ignore" -- Configurable via ansible.cfg and environment variable - -Windows -------- -- Implement gather_subset on Windows facts -- Fix Windows async + become to allow them to work together -- Implement Windows become flags for controlling various modes **(done)** - - logontype - - elevation behavior -- Convert win_updates to action plugin for auto reboot and extra features **(done)** -- Spike out changing the connection over to PSRP instead of WSMV **(done- it's possible)** -- Module updates - - - win_updates **(done)** - - - Fix win_updates to detect (or request) become - - Add enable/disable features to win_updates - - win_dsc further improvements **(done)** - -General Cloud -------------- -- Make multi-cloud provisioning easier -- Diff mode will output provisioning task results of ansible-playbook runs -- Terraform module - -AWS ---- -- Focus on pull requests for various modules -- Triage existing merges for modules -- Module work - - - ec2_instance - - ec2_vpc: Allow the addition of secondary IPv4 CIDRS to existing VPCs. - - AWS Network Load Balancer support (NLB module, ASG support, and so on) - - rds_instance - -Azure ------ -- Azure CLI auth **(done)** -- Fix Azure module results to have "high-level" output instead of raw REST API dictionary **(partial, more to come in 2.6)** -- Deprecate Azure automatic storage accounts in azure_rm_virtualmachine **(breaks on Azure Stack, punted until AS supports managed disks)** - -Network Roadmap ---------------- -- Refactor common network shared code into package **(done)** -- Convert various nxos modules to use declarative intent **(done)** -- Refactor various modules to use the cliconf plugin **(done)** -- Add various missing declarative modules for supported platforms and functions **(done)** -- Implement a feature that handles platform differences and feature unavailability **(done)** -- netconf-config.py should provide control for deployment strategy -- Create netconf connection plugin **(done)** -- Create netconf fact module -- Turn network_cli into a usable connection type **(done)** -- Implements jsonrpc message passing for ansible-connection **(done)** -- Improve logging for ansible-connection **(done)** -- Improve stdout output for failures whilst using persistent connection **(done)** -- Create IOS-XR NetConf Plugin and refactor iosxr modules to use netconf plugin **(done)** -- Refactor junos modules to use netconf plugin **(done)** -- Filters: Add a filter to convert XML response from a network device to JSON object **(done)** - -Documentation -------------- -- Extend documentation to more plugins -- Document vault-password-client scripts. -- Network Documentation - - - New landing page (to replace intro_networking) **(done)** - - Platform specific guides **(done)** - - Walk through: Getting Started **(done)** - - Networking and ``become`` **(done)** - - Best practice **(done)** - -Contributor Quality of Life ---------------------------- -- Finish PSScriptAnalyer integration with ansible-test (for enforcing Powershell style) **(done)** -- Resolve issues requiring skipping of some integration tests on Python 3. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_6.rst b/docs/docsite/rst/roadmap/ROADMAP_2_6.rst deleted file mode 100644 index 7d8226e2097..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_6.rst +++ /dev/null @@ -1,82 +0,0 @@ -=========== -Ansible 2.6 -=========== - -.. contents:: Topics - -Release Schedule ----------------- - -Actual -====== - -- 2018-05-17 Core Freeze (Engine and Core Modules/Plugins) -- 2018-05-21 Alpha Release 1 -- 2018-05-25 Community Freeze (Non-Core Modules/Plugins) -- 2018-05-25 Branch stable-2.6 -- 2018-05-30 Alpha Release 2 -- 2018-06-05 Release Candidate 1 -- 2018-06-08 Release Candidate 2 -- 2018-06-18 Release Candidate 3 -- 2018-06-25 Release Candidate 4 -- 2018-06-26 Release Candidate 5 -- 2018-06-28 Final Release - - -Release Manager ---------------- -* 2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay) -* 2.6.13+ Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) - - -Engine improvements -------------------- - -- Version 2.6 is largely going to be a stabilization release for Core code. -- Some of the items covered in this release, but are not limited to are the following: - - - ``ansible-inventory`` - - ``import_*`` - - ``include_*`` - - Test coverage - - Performance Testing - -Core Modules ------------- -- Adopt-a-module Campaign - - - Review current status of all Core Modules - - Reduce backlog of open issues against these modules - -Cloud Modules -------------- - -Network -------- - -Connection work -================ - -* New connection plugin: eAPI `proposal#102 `_ -* New connection plugin: NX-API -* Support for configurable options for network_cli & netconf - -Modules -======= - -* New ``net_get`` - platform independent module for pulling configuration via SCP/SFTP over network_cli -* New ``net_put`` - platform independent module for pushing configuration via SCP/SFTP over network_cli -* New ``netconf_get`` - Netconf module to fetch configuration and state data `proposal#104 `_ - -Other Features -================ - -* Stretch & tech preview: Configuration caching for network_cli. Opt-in feature to avoid ``show running`` performance hit - - -Windows -------- - - - - diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_7.rst b/docs/docsite/rst/roadmap/ROADMAP_2_7.rst deleted file mode 100644 index bf65dcf79fd..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_7.rst +++ /dev/null @@ -1,109 +0,0 @@ -=========== -Ansible 2.7 -=========== - -.. contents:: Topics - -Release Schedule ----------------- - -Expected -======== - -- 2018-08-23 Core Freeze (Engine and Core Modules/Plugins) -- 2018-08-23 Alpha Release 1 -- 2018-08-30 Community Freeze (Non-Core Modules/Plugins) -- 2018-08-30 Beta Release 1 -- 2018-09-06 Release Candidate 1 (If needed) -- 2018-09-13 Release Candidate 2 (If needed) -- 2018-09-20 Release Candidate 3 (If needed) -- 2018-09-27 Release Candidate 4 (If needed) -- 2018-10-04 General Availability - -Release Manager ---------------- -Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) - - -Cleaning Duty -------------- - -- Drop Py2.6 for controllers `Docs PR #42971 `_ and - `issue #42972 `_ -- Remove dependency on simplejson `issue #42761 `_ - - -Engine Improvements -------------------- - -- Performance improvement invoking Python modules `pr #41749 `_ -- Jinja native types will allow for users to render a Python native type. `pr #32738 `_ - - -Core Modules ------------- - -- Include feature changes and improvements - - - Create new argument ``apply`` that will allow for included tasks to inherit explicitly provided attributes. `pr #39236 `_ - - Create "private" functionality for allowing vars/default to be exposed outside of roles. `pr #41330 `_ -- Provide a parameter for the ``template`` module to output to different encoding formats `pr - #42171 `_ -- ``reboot`` module for Linux hosts (@samdoran) `pr #35205 `_ - -Cloud Modules -------------- - -General -======= -* Cloud auth plugin `proposal #24 `_ - -AWS -=== -* Inventory plugin for RDS `pr #41919 `_ -* Count support for `ec2_instance` -* `aws_eks` module `pr #41183 `_ -* Cloudformation stack sets support (`PR#41669 `_) -* RDS instance and snapshot modules `pr #39994 `_ `pr #43789 `_ -* Diff mode improvements for cloud modules `pr #44533 `_ - -Azure -===== - -* Azure inventory plugin `issue #42769 `__ - - -Network -------- - -General -======= - -* Refactor the APIs in cliconf (`issue #39056 `_) and netconf (`issue #39160 `_) plugins so that they have a uniform signature across supported network platforms. **done** - (`PR #41846 `_) (`PR #43643 `_) (`PR #43837 `_) - (`PR #43203 `_) (`PR #42300 `_) (`PR #44157 `_) - -Modules -======= - -* New ``cli_config`` module `issue #39228 `_ **done** `PR #42413 `_. -* New ``cli_command`` module `issue #39284 `_ -* Refactor ``netconf_config`` module to add additional functionality. **done** `proposal #104 `_ (`PR #44379 `_) - -Windows -------- - -General -======= - -* Added new connection plugin that uses PSRP as the connection protocol `pr #41729 `__ - -Modules -======= - -* Revamp Chocolatey to fix bugs and support offline installation `pr #43013 `_. -* Add Chocolatey modules that can manage the following Chocolatey features - - * `Sources `_ `pr #42790 `_ - * `Features `_ `pr #42848 `_ - * `Config `_ `pr #42915 `_ diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_8.rst b/docs/docsite/rst/roadmap/ROADMAP_2_8.rst deleted file mode 100644 index 04977aa7358..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_8.rst +++ /dev/null @@ -1,38 +0,0 @@ -=========== -Ansible 2.8 -=========== - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release. - -- 2019-04-04 Alpha 1 **Core freeze** - No new features to ``support:core`` code. - Includes no new options to existing Core modules - -- 2019-04-11 Beta 1 **Feature freeze** - No new functionality (including modules/plugins) to any code - -- 2019-04-25 Release Candidate 1 -- 2019-05-02 Release Candidate 2 -- 2019-05-10 Release Candidate 3 -- 2019-05-16 Release - - - -Release Manager ---------------- - -Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) - -Planned work -============ - -See the `Ansible 2.8 Project Board `_ diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_9.rst b/docs/docsite/rst/roadmap/ROADMAP_2_9.rst deleted file mode 100644 index 370930ac137..00000000000 --- a/docs/docsite/rst/roadmap/ROADMAP_2_9.rst +++ /dev/null @@ -1,39 +0,0 @@ -=========== -Ansible 2.9 -=========== - -.. contents:: - :local: - -Release Schedule ----------------- - -Expected -======== - -PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release. - -.. note:: There is no Alpha phase in 2.9. - -- 2019-08-29 Beta 1 **Feature freeze** - No new functionality (including modules/plugins) to any code - -- 2019-09-19 Release Candidate 1 -- 2019-10-03 Release Candidate 2 -- 2019-10-10 Release Candidate 3 -- 2019-10-17 Release Candidate 4 (if needed) -- 2019-10-24 Release Candidate 5 (if needed) -- 2019-10-31 Release - - - -Release Manager ---------------- -TBD - -Temporarily, Matt Davis (@nitzmahone) or Matt Clay (@mattclay) on IRC or github. - -Planned work -============ - -See the `Ansible 2.9 Project Board `_ diff --git a/docs/docsite/rst/roadmap/ansible_core_roadmap_index.rst b/docs/docsite/rst/roadmap/ansible_core_roadmap_index.rst deleted file mode 100644 index 18f8c3a131d..00000000000 --- a/docs/docsite/rst/roadmap/ansible_core_roadmap_index.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _roadmaps: -.. _ansible_core_roadmaps: - -ansible-core Roadmaps -===================== - -The ``ansible-core`` team develops a roadmap for each major and minor ``ansible-core`` release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not. - -We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions. - -Each roadmap offers a *best guess*, based on the ``ansible-core`` team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on. - -Each roadmap is published both as an idea of what is upcoming in ``ansible-core``, and as a medium for seeking further feedback from the community. - -You can submit feedback on the current roadmap in multiple ways: - -- Edit the agenda of an `Core Team Meeting `_ (preferred) -- Post on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) -- Email the ansible-devel list - -See :ref:`Ansible communication channels ` for details on how to join and use the email lists and chat channels. - -.. toctree:: - :maxdepth: 1 - :glob: - :caption: ansible-core Roadmaps - - ROADMAP_2_14 - ROADMAP_2_13 - ROADMAP_2_12 - ROADMAP_2_11 - ROADMAP_2_10 diff --git a/docs/docsite/rst/roadmap/ansible_roadmap_index.rst b/docs/docsite/rst/roadmap/ansible_roadmap_index.rst deleted file mode 100644 index 0bdd69df126..00000000000 --- a/docs/docsite/rst/roadmap/ansible_roadmap_index.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. _roadmaps: -.. _ansible_roadmaps: - -Ansible Roadmap -=============== - -The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not. - -We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions. - -Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on. - -Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. - -You can submit feedback on the current roadmap in multiple ways: - -- Edit the agenda of an `Ansible Community Meeting `_ (preferred) -- Post on the ``#ansible-community`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat `_) - -See :ref:`Ansible communication channels ` for details on how to join and use our chat channels. - -.. toctree:: - :maxdepth: 1 - :glob: - :caption: Ansible Release Roadmaps - - COLLECTIONS_7 - COLLECTIONS_6 - COLLECTIONS_5 - COLLECTIONS_4 - COLLECTIONS_3_0 - COLLECTIONS_2_10 - old_roadmap_index diff --git a/docs/docsite/rst/roadmap/index.rst b/docs/docsite/rst/roadmap/index.rst deleted file mode 100644 index 0b5b4bd11b6..00000000000 --- a/docs/docsite/rst/roadmap/index.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. _roadmaps: - -Roadmaps -=============== - -.. toctree:: - :maxdepth: 1 - :glob: - - ansible_roadmap_index - ansible_core_roadmap_index - old_roadmap_index diff --git a/docs/docsite/rst/roadmap/old_roadmap_index.rst b/docs/docsite/rst/roadmap/old_roadmap_index.rst deleted file mode 100644 index 78769f17584..00000000000 --- a/docs/docsite/rst/roadmap/old_roadmap_index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. _old_roadmaps: - -Older Roadmaps -=============== - -Older roadmaps are listed here to provide a history of the Ansible project. - -See :ref:`roadmaps` to find current Ansible and ``ansible-base`` roadmaps. - -.. toctree:: - :maxdepth: 1 - :glob: - :caption: Older Roadmaps - - ROADMAP_2_9 - ROADMAP_2_8 - ROADMAP_2_7 - ROADMAP_2_6 - ROADMAP_2_5 diff --git a/docs/docsite/rst/scenario_guides/cloud_guides.rst b/docs/docsite/rst/scenario_guides/cloud_guides.rst deleted file mode 100644 index a0e6e8ed975..00000000000 --- a/docs/docsite/rst/scenario_guides/cloud_guides.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. _cloud_guides: - -************************** -Legacy Public Cloud Guides -************************** - -The legacy guides in this section may be out of date. They cover using Ansible with a range of public cloud platforms. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -Guides for using public clouds are moving into collections. We are migrating these guides into collections. Please update your links for the following guides: - -:ref:`ansible_collections.amazon.aws.docsite.aws_intro` - -.. toctree:: - :maxdepth: 1 - - guide_alicloud - guide_cloudstack - guide_gce - guide_azure - guide_online - guide_oracle - guide_packet - guide_rax - guide_scaleway - guide_vultr diff --git a/docs/docsite/rst/scenario_guides/guide_aci.rst b/docs/docsite/rst/scenario_guides/guide_aci.rst deleted file mode 100644 index e2e66138971..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_aci.rst +++ /dev/null @@ -1,659 +0,0 @@ -.. _aci_guide: - -Cisco ACI Guide -=============== - - -.. _aci_guide_intro: - -What is Cisco ACI ? -------------------- - -Application Centric Infrastructure (ACI) -........................................ -The Cisco Application Centric Infrastructure (ACI) allows application requirements to define the network. This architecture simplifies, optimizes, and accelerates the entire application deployment life cycle. - - -Application Policy Infrastructure Controller (APIC) -................................................... -The APIC manages the scalable ACI multi-tenant fabric. The APIC provides a unified point of automation and management, policy programming, application deployment, and health monitoring for the fabric. The APIC, which is implemented as a replicated synchronized clustered controller, optimizes performance, supports any application anywhere, and provides unified operation of the physical and virtual infrastructure. - -The APIC enables network administrators to easily define the optimal network for applications. Data center operators can clearly see how applications consume network resources, easily isolate and troubleshoot application and infrastructure problems, and monitor and profile resource usage patterns. - -The Cisco Application Policy Infrastructure Controller (APIC) API enables applications to directly connect with a secure, shared, high-performance resource pool that includes network, compute, and storage capabilities. - - -ACI Fabric -.......... -The Cisco Application Centric Infrastructure (ACI) Fabric includes Cisco Nexus 9000 Series switches with the APIC to run in the leaf/spine ACI fabric mode. These switches form a "fat-tree" network by connecting each leaf node to each spine node; all other devices connect to the leaf nodes. The APIC manages the ACI fabric. - -The ACI fabric provides consistent low-latency forwarding across high-bandwidth links (40 Gbps, with a 100-Gbps future capability). Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch. - -The ACI fabric object-oriented operating system (OS) runs on each Cisco Nexus 9000 Series node. It enables programming of objects for each configurable element of the system. The ACI fabric OS renders policies from the APIC into a concrete model that runs in the physical infrastructure. The concrete model is analogous to compiled software; it is the form of the model that the switch operating system can execute. - -All the switch nodes contain a complete copy of the concrete model. When an administrator creates a policy in the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the intermediate step of creating a fully elaborated policy that it pushes into all the switch nodes where the concrete model is updated. - -The APIC is responsible for fabric activation, switch firmware management, network policy configuration, and instantiation. While the APIC acts as the centralized policy and network management engine for the fabric, it is completely removed from the data path, including the forwarding topology. Therefore, the fabric can still forward traffic even when communication with the APIC is lost. - - -More information -................ -Various resources exist to start learning ACI, here is a list of interesting articles from the community. - -- `Adam Raffe: Learning ACI `_ -- `Luca Relandini: ACI for dummies `_ -- `Cisco DevNet Learning Labs about ACI `_ - - -.. _aci_guide_modules: - -Using the ACI modules ---------------------- -The Ansible ACI modules provide a user-friendly interface to managing your ACI environment using Ansible playbooks. - -For instance ensuring that a specific tenant exists, is done using the following Ansible task using the aci_tenant module: - -.. code-block:: yaml - - - name: Ensure tenant customer-xyz exists - aci_tenant: - host: my-apic-1 - username: admin - password: my-password - - tenant: customer-xyz - description: Customer XYZ - state: present - -A complete list of existing ACI modules is available on the content tab of the `ACI collection on Ansible Galaxy `_. - -If you want to learn how to write your own ACI modules to contribute, look at the :ref:`Developing Cisco ACI modules ` section. - -Querying ACI configuration -.......................... - -A module can also be used to query a specific object. - -.. code-block:: yaml - - - name: Query tenant customer-xyz - aci_tenant: - host: my-apic-1 - username: admin - password: my-password - - tenant: customer-xyz - state: query - register: my_tenant - -Or query all objects. - -.. code-block:: yaml - - - name: Query all tenants - aci_tenant: - host: my-apic-1 - username: admin - password: my-password - - state: query - register: all_tenants - -After registering the return values of the aci_tenant task as shown above, you can access all tenant information from variable ``all_tenants``. - - -Running on the controller locally -................................. -As originally designed, Ansible modules are shipped to and run on the remote target(s), however the ACI modules (like most network-related modules) do not run on the network devices or controller (in this case the APIC), but they talk directly to the APIC's REST interface. - -For this very reason, the modules need to run on the local Ansible controller (or are delegated to another system that *can* connect to the APIC). - - -Gathering facts -``````````````` -Because we run the modules on the Ansible controller gathering facts will not work. That is why when using these ACI modules it is mandatory to disable facts gathering. You can do this globally in your ``ansible.cfg`` or by adding ``gather_facts: false`` to every play. - -.. code-block:: yaml - :emphasize-lines: 3 - - - name: Another play in my playbook - hosts: my-apic-1 - gather_facts: false - tasks: - - name: Create a tenant - aci_tenant: - ... - -Delegating to localhost -``````````````````````` -So let us assume we have our target configured in the inventory using the FQDN name as the ``ansible_host`` value, as shown below. - -.. code-block:: yaml - :emphasize-lines: 3 - - apics: - my-apic-1: - ansible_host: apic01.fqdn.intra - ansible_user: admin - ansible_password: my-password - -One way to set this up is to add to every task the directive: ``delegate_to: localhost``. - -.. code-block:: yaml - :emphasize-lines: 8 - - - name: Query all tenants - aci_tenant: - host: '{{ ansible_host }}' - username: '{{ ansible_user }}' - password: '{{ ansible_password }}' - - state: query - delegate_to: localhost - register: all_tenants - -If one would forget to add this directive, Ansible will attempt to connect to the APIC using SSH and attempt to copy the module and run it remotely. This will fail with a clear error, yet may be confusing to some. - - -Using the local connection method -````````````````````````````````` -Another option frequently used, is to tie the ``local`` connection method to this target so that every subsequent task for this target will use the local connection method (hence run it locally, rather than use SSH). - -In this case the inventory may look like this: - -.. code-block:: yaml - :emphasize-lines: 6 - - apics: - my-apic-1: - ansible_host: apic01.fqdn.intra - ansible_user: admin - ansible_password: my-password - ansible_connection: local - -But used tasks do not need anything special added. - -.. code-block:: yaml - - - name: Query all tenants - aci_tenant: - host: '{{ ansible_host }}' - username: '{{ ansible_user }}' - password: '{{ ansible_password }}' - - state: query - register: all_tenants - -.. hint:: For clarity we have added ``delegate_to: localhost`` to all the examples in the module documentation. This helps to ensure first-time users can easily copy&paste parts and make them work with a minimum of effort. - - -Common parameters -................. -Every Ansible ACI module accepts the following parameters that influence the module's communication with the APIC REST API: - - host - Hostname or IP address of the APIC. - - port - Port to use for communication. (Defaults to ``443`` for HTTPS, and ``80`` for HTTP) - - username - User name used to log on to the APIC. (Defaults to ``admin``) - - password - Password for ``username`` to log on to the APIC, using password-based authentication. - - private_key - Private key for ``username`` to log on to APIC, using signature-based authentication. - This could either be the raw private key content (include header/footer) or a file that stores the key content. - *New in version 2.5* - - certificate_name - Name of the certificate in the ACI Web GUI. - This defaults to either the ``username`` value or the ``private_key`` file base name). - *New in version 2.5* - - timeout - Timeout value for socket-level communication. - - use_proxy - Use system proxy settings. (Defaults to ``yes``) - - use_ssl - Use HTTPS or HTTP for APIC REST communication. (Defaults to ``yes``) - - validate_certs - Validate certificate when using HTTPS communication. (Defaults to ``yes``) - - output_level - Influence the level of detail ACI modules return to the user. (One of ``normal``, ``info`` or ``debug``) *New in version 2.5* - - -Proxy support -............. -By default, if an environment variable ``_proxy`` is set on the target host, requests will be sent through that proxy. This behaviour can be overridden by setting a variable for this task (see :ref:`playbooks_environment`), or by using the ``use_proxy`` module parameter. - -HTTP redirects can redirect from HTTP to HTTPS so ensure that the proxy environment for both protocols is correctly configured. - -If proxy support is not needed, but the system may have it configured nevertheless, use the parameter ``use_proxy: false`` to avoid accidental system proxy usage. - -.. hint:: Selective proxy support using the ``no_proxy`` environment variable is also supported. - - -Return values -............. - -.. versionadded:: 2.5 - -The following values are always returned: - - current - The resulting state of the managed object, or results of your query. - -The following values are returned when ``output_level: info``: - - previous - The original state of the managed object (before any change was made). - - proposed - The proposed config payload, based on user-supplied values. - - sent - The sent config payload, based on user-supplied values and the existing configuration. - -The following values are returned when ``output_level: debug`` or ``ANSIBLE_DEBUG=1``: - - filter_string - The filter used for specific APIC queries. - - method - The HTTP method used for the sent payload. (Either ``GET`` for queries, ``DELETE`` or ``POST`` for changes) - - response - The HTTP response from the APIC. - - status - The HTTP status code for the request. - - url - The url used for the request. - -.. note:: The module return values are documented in detail as part of each module's documentation. - - -More information -................ -Various resources exist to start learn more about ACI programmability, we recommend the following links: - -- :ref:`Developing Cisco ACI modules ` -- `Jacob McGill: Automating Cisco ACI with Ansible `_ -- `Cisco DevNet Learning Labs about ACI and Ansible `_ - - -.. _aci_guide_auth: - -ACI authentication ------------------- - -Password-based authentication -............................. -If you want to log on using a username and password, you can use the following parameters with your ACI modules: - -.. code-block:: yaml - - username: admin - password: my-password - -Password-based authentication is very simple to work with, but it is not the most efficient form of authentication from ACI's point-of-view as it requires a separate login-request and an open session to work. To avoid having your session time-out and requiring another login, you can use the more efficient Signature-based authentication. - -.. note:: Password-based authentication also may trigger anti-DoS measures in ACI v3.1+ that causes session throttling and results in HTTP 503 errors and login failures. - -.. warning:: Never store passwords in plain text. - -The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information. - - -Signature-based authentication using certificates -................................................. - -.. versionadded:: 2.5 - -Using signature-based authentication is more efficient and more reliable than password-based authentication. - -Generate certificate and private key -```````````````````````````````````` -Signature-based authentication requires a (self-signed) X.509 certificate with private key, and a configuration step for your AAA user in ACI. To generate a working X.509 certificate and private key, use the following procedure: - -.. code-block:: bash - - $ openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout admin.key -out admin.crt -subj '/CN=Admin/O=Your Company/C=US' - -Configure your local user -````````````````````````` -Perform the following steps: - -- Add the X.509 certificate to your ACI AAA local user at :guilabel:`ADMIN` » :guilabel:`AAA` -- Click :guilabel:`AAA Authentication` -- Check that in the :guilabel:`Authentication` field the :guilabel:`Realm` field displays :guilabel:`Local` -- Expand :guilabel:`Security Management` » :guilabel:`Local Users` -- Click the name of the user you want to add a certificate to, in the :guilabel:`User Certificates` area -- Click the :guilabel:`+` sign and in the :guilabel:`Create X509 Certificate` enter a certificate name in the :guilabel:`Name` field - - * If you use the basename of your private key here, you don't need to enter ``certificate_name`` in Ansible - -- Copy and paste your X.509 certificate in the :guilabel:`Data` field. - -You can automate this by using the following Ansible task: - -.. code-block:: yaml - - - name: Ensure we have a certificate installed - aci_aaa_user_certificate: - host: my-apic-1 - username: admin - password: my-password - - aaa_user: admin - certificate_name: admin - certificate: "{{ lookup('file', 'pki/admin.crt') }}" # This will read the certificate data from a local file - -.. note:: Signature-based authentication only works with local users. - - -Use signature-based authentication with Ansible -``````````````````````````````````````````````` -You need the following parameters with your ACI module(s) for it to work: - -.. code-block:: yaml - :emphasize-lines: 2,3 - - username: admin - private_key: pki/admin.key - certificate_name: admin # This could be left out ! - -or you can use the private key content: - -.. code-block:: yaml - :emphasize-lines: 2,3 - - username: admin - private_key: | - -----BEGIN PRIVATE KEY----- - <> - -----END PRIVATE KEY----- - certificate_name: admin # This could be left out ! - - -.. hint:: If you use a certificate name in ACI that matches the private key's basename, you can leave out the ``certificate_name`` parameter like the example above. - - -Using Ansible Vault to encrypt the private key -`````````````````````````````````````````````` -.. versionadded:: 2.8 - -To start, encrypt the private key and give it a strong password. - -.. code-block:: bash - - ansible-vault encrypt admin.key - -Use a text editor to open the private-key. You should have an encrypted cert now. - -.. code-block:: bash - - $ANSIBLE_VAULT;1.1;AES256 - 56484318584354658465121889743213151843149454864654151618131547984132165489484654 - 45641818198456456489479874513215489484843614848456466655432455488484654848489498 - .... - -Copy and paste the new encrypted cert into your playbook as a new variable. - -.. code-block:: yaml - - private_key: !vault | - $ANSIBLE_VAULT;1.1;AES256 - 56484318584354658465121889743213151843149454864654151618131547984132165489484654 - 45641818198456456489479874513215489484843614848456466655432455488484654848489498 - .... - -Use the new variable for the private_key: - -.. code-block:: yaml - - username: admin - private_key: "{{ private_key }}" - certificate_name: admin # This could be left out ! - -When running the playbook, use "--ask-vault-pass" to decrypt the private key. - -.. code-block:: bash - - ansible-playbook site.yaml --ask-vault-pass - - -More information -```````````````` -- Detailed information about Signature-based Authentication is available from `Cisco APIC Signature-Based Transactions `_. -- More information on Ansible Vault can be found on the :ref:`Ansible Vault ` page. - - -.. _aci_guide_rest: - -Using ACI REST with Ansible ---------------------------- -While already a lot of ACI modules exists in the Ansible distribution, and the most common actions can be performed with these existing modules, there's always something that may not be possible with off-the-shelf modules. - -The aci_rest module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly. - - -Built-in idempotency -.................... -Because the APIC REST API is intrinsically idempotent and can report whether a change was made, the aci_rest module automatically inherits both capabilities and is a first-class solution for automating your ACI infrastructure. As a result, users that require more powerful low-level access to their ACI infrastructure don't have to give up on idempotency and don't have to guess whether a change was performed when using the aci_rest module. - - -Using the aci_rest module -......................... -The aci_rest module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require the path to end with ``.json``. - -When you're making modifications, you can use the POST or DELETE methods, whereas doing just queries require the GET method. - -For instance, if you would like to ensure a specific tenant exists on ACI, these below four examples are functionally identical: - -**XML** (Native ACI REST) - -.. code-block:: yaml - - - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - - method: post - path: /api/mo/uni.xml - content: | - - -**JSON** (Native ACI REST) - -.. code-block:: yaml - - - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - - method: post - path: /api/mo/uni.json - content: - { - "fvTenant": { - "attributes": { - "name": "customer-xyz", - "descr": "Customer XYZ" - } - } - } - -**YAML** (Ansible-style REST) - -.. code-block:: yaml - - - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - - method: post - path: /api/mo/uni.json - content: - fvTenant: - attributes: - name: customer-xyz - descr: Customer XYZ - -**Ansible task** (Dedicated module) - -.. code-block:: yaml - - - aci_tenant: - host: my-apic-1 - private_key: pki/admin.key - - tenant: customer-xyz - description: Customer XYZ - state: present - - -.. hint:: The XML format is more practical when there is a need to template the REST payload (inline), but the YAML format is more convenient for maintaining your infrastructure-as-code and feels more naturally integrated with Ansible playbooks. The dedicated modules offer a more simple, abstracted, but also a more limited experience. Use what feels best for your use-case. - - -More information -................ -Plenty of resources exist to learn about ACI's APIC REST interface, we recommend the links below: - -- `The ACI collection on Ansible Galaxy `_ -- `APIC REST API Configuration Guide `_ -- Detailed guide on how the APIC REST API is designed and used, incl. many examples -- `APIC Management Information Model reference `_ -- Complete reference of the APIC object model -- `Cisco DevNet Learning Labs about ACI and REST `_ - - -.. _aci_guide_ops: - -Operational examples --------------------- -Here is a small overview of useful operational tasks to reuse in your playbooks. - -Feel free to contribute more useful snippets. - - -Waiting for all controllers to be ready -....................................... -You can use the below task after you started to build your APICs and configured the cluster to wait until all the APICs have come online. It will wait until the number of controllers equals the number listed in the ``apic`` inventory group. - -.. code-block:: yaml - - - name: Waiting for all controllers to be ready - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - method: get - path: /api/node/class/topSystem.json?query-target-filter=eq(topSystem.role,"controller") - register: topsystem - until: topsystem|success and topsystem.totalCount|int >= groups['apic']|count >= 3 - retries: 20 - delay: 30 - - -Waiting for cluster to be fully-fit -................................... -The below example waits until the cluster is fully-fit. In this example you know the number of APICs in the cluster and you verify each APIC reports a 'fully-fit' status. - -.. code-block:: yaml - - - name: Waiting for cluster to be fully-fit - aci_rest: - host: my-apic-1 - private_key: pki/admin.key - method: get - path: /api/node/class/infraWiNode.json?query-target-filter=wcard(infraWiNode.dn,"topology/pod-1/node-1/av") - register: infrawinode - until: > - infrawinode|success and - infrawinode.totalCount|int >= groups['apic']|count >= 3 and - infrawinode.imdata[0].infraWiNode.attributes.health == 'fully-fit' and - infrawinode.imdata[1].infraWiNode.attributes.health == 'fully-fit' and - infrawinode.imdata[2].infraWiNode.attributes.health == 'fully-fit' - retries: 30 - delay: 30 - - -.. _aci_guide_errors: - -APIC error messages -------------------- -The following error messages may occur and this section can help you understand what exactly is going on and how to fix/avoid them. - - APIC Error 122: unknown managed object class 'polUni' - In case you receive this error while you are certain your aci_rest payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (for example, the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload, which are easier to construct correctly and modify later. - - - APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag - Although the JSON specification allows unordered elements, the APIC REST API requires that the JSON ``attributes`` element precede the ``children`` array or other elements. So you need to ensure that your payload conforms to this requirement. Sorting your dictionary keys will do the trick just fine. If you don't have any attributes, it may be necessary to add: ``attributes: {}`` as the APIC does expect the entry to precede any ``children``. - - - APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A "legacy" network' - Some values in the APIC have strict format-rules to comply to, and the internal APIC validation check for the provided value failed. In the above case, the ``description`` parameter (internally known as ``descr``) only accepts values conforming to Regex: ``[a-zA-Z0-9\\!#$%()*,-./:;@ _{|}~?&+]+``, in general it must not include quotes or square brackets. - - -.. _aci_guide_known_issues: - -Known issues ------------- -The aci_rest module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of this module. - -All below issues either have been reported to the vendor, and most can simply be avoided. - - Too many consecutive API calls may result in connection throttling - Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific threshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended. - - **NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules. - - - Specific requests may not reflect changes correctly (`#35401 `_) - There is a known issue where specific requests to the APIC do not properly reflect changed in the resulting output, even when we request those changes explicitly from the APIC. In one instance using the path ``api/node/mo/uni/infra.xml`` fails, where ``api/node/mo/uni/infra/.xml`` does work correctly. - - **NOTE:** A workaround is to register the task return values (for example, ``register: this``) and influence when the task should report a change by adding: ``changed_when: this.imdata != []``. - - - Specific requests are known to not be idempotent (`#35050 `_) - The behaviour of the APIC is inconsistent to the use of ``status="created"`` and ``status="deleted"``. The result is that when you use ``status="created"`` in your payload the resulting tasks are not idempotent and creation will fail when the object was already created. However this is not the case with ``status="deleted"`` where such call to an non-existing object does not cause any failure whatsoever. - - **NOTE:** A workaround is to avoid using ``status="created"`` and instead use ``status="modified"`` when idempotency is essential to your workflow.. - - - Setting user password is not idempotent (`#35544 `_) - Due to an inconsistency in the APIC REST API, a task that sets the password of a locally-authenticated user is not idempotent. The APIC will complain with message ``Password history check: user dag should not use previous 5 passwords``. - - **NOTE:** There is no workaround for this issue. - - -.. _aci_guide_community: - -ACI Ansible community ---------------------- -If you have specific issues with the ACI modules, or a feature request, or you like to contribute to the ACI project by proposing changes or documentation updates, look at the Ansible Community wiki ACI page at: https://github.com/ansible/community/wiki/Network:-ACI - -You will find our roadmap, an overview of open ACI issues and pull-requests, and more information about who we are. If you have an interest in using ACI with Ansible, feel free to join! We occasionally meet online (on the #ansible-network chat channel, using Matrix at ansible.im or using IRC at `irc.libera.chat `_) to track progress and prepare for new Ansible releases. - - -.. seealso:: - - `ACI collection on Ansible Galaxy `_ - View the content tab for a complete list of supported ACI modules. - :ref:`Developing Cisco ACI modules ` - A walkthrough on how to develop new Cisco ACI modules to contribute back. - `ACI community `_ - The Ansible ACI community wiki page, includes roadmap, ideas and development documentation. - :ref:`network_guide` - A detailed guide on how to use Ansible for automating network infrastructure. - `Network Working Group `_ - The Ansible Network community page, includes contact information and meeting information. - `User Mailing List `_ - Have a question? Stop by the google group! diff --git a/docs/docsite/rst/scenario_guides/guide_alicloud.rst b/docs/docsite/rst/scenario_guides/guide_alicloud.rst deleted file mode 100644 index fd78bf19cfb..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_alicloud.rst +++ /dev/null @@ -1,133 +0,0 @@ -Alibaba Cloud Compute Services Guide -==================================== - -.. _alicloud_intro: - -Introduction -```````````` - -Ansible contains several modules for controlling and managing Alibaba Cloud Compute Services (Alicloud). This guide -explains how to use the Alicloud Ansible modules together. - -All Alicloud modules require ``footmark`` - install it on your control machine with ``pip install footmark``. - -Cloud modules, including Alicloud modules, execute on your local machine (the control machine) with ``connection: local``, rather than on remote machines defined in your hosts. - -Normally, you'll use the following pattern for plays that provision Alicloud resources: - -.. code-block:: yaml - - - hosts: localhost - connection: local - vars: - - ... - tasks: - - ... - -.. _alicloud_authentication: - -Authentication -`````````````` - -You can specify your Alicloud authentication credentials (access key and secret key) by passing them as -environment variables or by storing them in a vars file. - -To pass authentication credentials as environment variables: - -.. code-block:: shell - - export ALICLOUD_ACCESS_KEY='Alicloud123' - export ALICLOUD_SECRET_KEY='AlicloudSecret123' - -To store authentication credentials in a vars_files, encrypt them with :ref:`Ansible Vault` to keep them secure, then list them: - -.. code-block:: yaml - - --- - alicloud_access_key: "--REMOVED--" - alicloud_secret_key: "--REMOVED--" - -Note that if you store your credentials in a vars_files, you need to refer to them in each Alicloud module. For example: - -.. code-block:: yaml - - - ali_instance: - alicloud_access_key: "{{alicloud_access_key}}" - alicloud_secret_key: "{{alicloud_secret_key}}" - image_id: "..." - -.. _alicloud_provisioning: - -Provisioning -```````````` - -Alicloud modules create Alicloud ECS instances, disks, virtual private clouds, virtual switches, security groups and other resources. - -You can use the ``count`` parameter to control the number of resources you create or terminate. For example, if you want exactly 5 instances tagged ``NewECS``, -set the ``count`` of instances to 5 and the ``count_tag`` to ``NewECS``, as shown in the last task of the example playbook below. -If there are no instances with the tag ``NewECS``, the task creates 5 new instances. If there are 2 instances with that tag, the task -creates 3 more. If there are 8 instances with that tag, the task terminates 3 of those instances. - -If you do not specify a ``count_tag``, the task creates the number of instances you specify in ``count`` with the ``instance_name`` you provide. - -.. code-block:: yaml - - # alicloud_setup.yml - - - hosts: localhost - connection: local - - tasks: - - - name: Create VPC - ali_vpc: - cidr_block: '{{ cidr_block }}' - vpc_name: new_vpc - register: created_vpc - - - name: Create VSwitch - ali_vswitch: - alicloud_zone: '{{ alicloud_zone }}' - cidr_block: '{{ vsw_cidr }}' - vswitch_name: new_vswitch - vpc_id: '{{ created_vpc.vpc.id }}' - register: created_vsw - - - name: Create security group - ali_security_group: - name: new_group - vpc_id: '{{ created_vpc.vpc.id }}' - rules: - - proto: tcp - port_range: 22/22 - cidr_ip: 0.0.0.0/0 - priority: 1 - rules_egress: - - proto: tcp - port_range: 80/80 - cidr_ip: 192.168.0.54/32 - priority: 1 - register: created_group - - - name: Create a set of instances - ali_instance: - security_groups: '{{ created_group.group_id }}' - instance_type: ecs.n4.small - image_id: "{{ ami_id }}" - instance_name: "My-new-instance" - instance_tags: - Name: NewECS - Version: 0.0.1 - count: 5 - count_tag: - Name: NewECS - allocate_public_ip: true - max_bandwidth_out: 50 - vswitch_id: '{{ created_vsw.vswitch.id}}' - register: create_instance - -In the example playbook above, data about the vpc, vswitch, group, and instances created by this playbook -are saved in the variables defined by the "register" keyword in each task. - -Each Alicloud module offers a variety of parameter options. Not all options are demonstrated in the above example. -See each individual module for further details and examples. diff --git a/docs/docsite/rst/scenario_guides/guide_aws.rst b/docs/docsite/rst/scenario_guides/guide_aws.rst deleted file mode 100644 index f2931556399..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_aws.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Amazon Web Services Guide -========================= - -The content on this page has moved. Please see the updated :ref:`ansible_collections.amazon.aws.docsite.aws_intro` in the AWS collection. diff --git a/docs/docsite/rst/scenario_guides/guide_azure.rst b/docs/docsite/rst/scenario_guides/guide_azure.rst deleted file mode 100644 index 41bdab3c24f..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_azure.rst +++ /dev/null @@ -1,484 +0,0 @@ -Microsoft Azure Guide -===================== - -.. important:: - - Red Hat Ansible Automation Platform will soon be available on Microsoft Azure. `Sign up to preview the experience `_. - -Ansible includes a suite of modules for interacting with Azure Resource Manager, giving you the tools to easily create -and orchestrate infrastructure on the Microsoft Azure Cloud. - -Requirements ------------- - -Using the Azure Resource Manager modules requires having specific Azure SDK modules -installed on the host running Ansible. - -.. code-block:: bash - - $ pip install 'ansible[azure]' - -If you are running Ansible from source, you can install the dependencies from the -root directory of the Ansible repo. - -.. code-block:: bash - - $ pip install .[azure] - -You can also directly run Ansible in `Azure Cloud Shell `_, where Ansible is pre-installed. - -Authenticating with Azure -------------------------- - -Using the Azure Resource Manager modules requires authenticating with the Azure API. You can choose from two authentication strategies: - -* Active Directory Username/Password -* Service Principal Credentials - -Follow the directions for the strategy you wish to use, then proceed to `Providing Credentials to Azure Modules`_ for -instructions on how to actually use the modules and authenticate with the Azure API. - - -Using Service Principal -....................... - -There is now a detailed official tutorial describing `how to create a service principal `_. - -After stepping through the tutorial you will have: - -* Your Client ID, which is found in the "client id" box in the "Configure" page of your application in the Azure portal -* Your Secret key, generated when you created the application. You cannot show the key after creation. - If you lost the key, you must create a new one in the "Configure" page of your application. -* And finally, a tenant ID. It's a UUID (for example, ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your - application. You will find it in the URL from within the Azure portal, or in the "view endpoints" of any given URL. - - -Using Active Directory Username/Password -........................................ - -To create an Active Directory username/password: - -* Connect to the Azure Classic Portal with your admin account -* Create a user in your default AAD. You must NOT activate Multi-Factor Authentication -* Go to Settings - Administrators -* Click on Add and enter the email of the new user. -* Check the checkbox of the subscription you want to test with this user. -* Login to Azure Portal with this new user to change the temporary password to a new one. You will not be able to use the - temporary password for OAuth login. - -Providing Credentials to Azure Modules -...................................... - -The modules offer several ways to provide your credentials. For a CI/CD tool such as Ansible AWX or Jenkins, you will -most likely want to use environment variables. For local development you may wish to store your credentials in a file -within your home directory. And of course, you can always pass credentials as parameters to a task within a playbook. The -order of precedence is parameters, then environment variables, and finally a file found in your home directory. - -Using Environment Variables -``````````````````````````` - -To pass service principal credentials through the environment, define the following variables: - -* AZURE_CLIENT_ID -* AZURE_SECRET -* AZURE_SUBSCRIPTION_ID -* AZURE_TENANT - -To pass Active Directory username/password through the environment, define the following variables: - -* AZURE_AD_USER -* AZURE_PASSWORD -* AZURE_SUBSCRIPTION_ID - -To pass Active Directory username/password in ADFS through the environment, define the following variables: - -* AZURE_AD_USER -* AZURE_PASSWORD -* AZURE_CLIENT_ID -* AZURE_TENANT -* AZURE_ADFS_AUTHORITY_URL - -"AZURE_ADFS_AUTHORITY_URL" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs. - -Storing in a File -````````````````` - -When working in a development environment, it may be desirable to store credentials in a file. The modules will look -for credentials in ``$HOME/.azure/credentials``. This file is an ini style file. It will look as follows: - -.. code-block:: ini - - [default] - subscription_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - client_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - secret=xxxxxxxxxxxxxxxxx - tenant=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - -.. note:: If your secret values contain non-ASCII characters, you must `URL Encode `_ them to avoid login errors. - -It is possible to store multiple sets of credentials within the credentials file by creating multiple sections. Each -section is considered a profile. The modules look for the [default] profile automatically. Define AZURE_PROFILE in the -environment or pass a profile parameter to specify a specific profile. - -Passing as Parameters -````````````````````` - -If you wish to pass credentials as parameters to a task, use the following parameters for service principal: - -* client_id -* secret -* subscription_id -* tenant - -Or, pass the following parameters for Active Directory username/password: - -* ad_user -* password -* subscription_id - -Or, pass the following parameters for ADFS username/password: - -* ad_user -* password -* client_id -* tenant -* adfs_authority_url - -"adfs_authority_url" is optional. It's necessary only when you have own ADFS authority like https://yourdomain.com/adfs. - - -Other Cloud Environments ------------------------- - -To use an Azure Cloud other than the default public cloud (for example, Azure China Cloud, Azure US Government Cloud, Azure Stack), -pass the "cloud_environment" argument to modules, configure it in a credential profile, or set the "AZURE_CLOUD_ENVIRONMENT" -environment variable. The value is either a cloud name as defined by the Azure Python SDK (for example, "AzureChinaCloud", -"AzureUSGovernment"; defaults to "AzureCloud") or an Azure metadata discovery URL (for Azure Stack). - -Creating Virtual Machines -------------------------- - -There are two ways to create a virtual machine, both involving the azure_rm_virtualmachine module. We can either create -a storage account, network interface, security group and public IP address and pass the names of these objects to the -module as parameters, or we can let the module do the work for us and accept the defaults it chooses. - -Creating Individual Components -.............................. - -An Azure module is available to help you create a storage account, virtual network, subnet, network interface, -security group and public IP. Here is a full example of creating each of these and passing the names to the -``azure.azcollection.azure_rm_virtualmachine`` module at the end: - -.. code-block:: yaml - - - name: Create storage account - azure.azcollection.azure_rm_storageaccount: - resource_group: Testing - name: testaccount001 - account_type: Standard_LRS - - - name: Create virtual network - azure.azcollection.azure_rm_virtualnetwork: - resource_group: Testing - name: testvn001 - address_prefixes: "10.10.0.0/16" - - - name: Add subnet - azure.azcollection.azure_rm_subnet: - resource_group: Testing - name: subnet001 - address_prefix: "10.10.0.0/24" - virtual_network: testvn001 - - - name: Create public ip - azure.azcollection.azure_rm_publicipaddress: - resource_group: Testing - allocation_method: Static - name: publicip001 - - - name: Create security group that allows SSH - azure.azcollection.azure_rm_securitygroup: - resource_group: Testing - name: secgroup001 - rules: - - name: SSH - protocol: Tcp - destination_port_range: 22 - access: Allow - priority: 101 - direction: Inbound - - - name: Create NIC - azure.azcollection.azure_rm_networkinterface: - resource_group: Testing - name: testnic001 - virtual_network: testvn001 - subnet: subnet001 - public_ip_name: publicip001 - security_group: secgroup001 - - - name: Create virtual machine - azure.azcollection.azure_rm_virtualmachine: - resource_group: Testing - name: testvm001 - vm_size: Standard_D1 - storage_account: testaccount001 - storage_container: testvm001 - storage_blob: testvm001.vhd - admin_username: admin - admin_password: Password! - network_interfaces: testnic001 - image: - offer: CentOS - publisher: OpenLogic - sku: '7.1' - version: latest - -Each of the Azure modules offers a variety of parameter options. Not all options are demonstrated in the above example. -See each individual module for further details and examples. - - -Creating a Virtual Machine with Default Options -............................................... - -If you simply want to create a virtual machine without specifying all the details, you can do that as well. The only -caveat is that you will need a virtual network with one subnet already in your resource group. Assuming you have a -virtual network already with an existing subnet, you can run the following to create a VM: - -.. code-block:: yaml - - azure.azcollection.azure_rm_virtualmachine: - resource_group: Testing - name: testvm10 - vm_size: Standard_D1 - admin_username: chouseknecht - ssh_password_enabled: false - ssh_public_keys: "{{ ssh_keys }}" - image: - offer: CentOS - publisher: OpenLogic - sku: '7.1' - version: latest - - -Creating a Virtual Machine in Availability Zones -.................................................. - -If you want to create a VM in an availability zone, -consider the following: - -* Both OS disk and data disk must be a 'managed disk', not an 'unmanaged disk'. -* When creating a VM with the ``azure.azcollection.azure_rm_virtualmachine`` module, - you need to explicitly set the ``managed_disk_type`` parameter - to change the OS disk to a managed disk. - Otherwise, the OS disk becomes an unmanaged disk. -* When you create a data disk with the ``azure.azcollection.azure_rm_manageddisk`` module, - you need to explicitly specify the ``storage_account_type`` parameter - to make it a managed disk. - Otherwise, the data disk will be an unmanaged disk. -* A managed disk does not require a storage account or a storage container, - unlike an unmanaged disk. - In particular, note that once a VM is created on an unmanaged disk, - an unnecessary storage container named "vhds" is automatically created. -* When you create an IP address with the ``azure.azcollection.azure_rm_publicipaddress`` module, - you must set the ``sku`` parameter to ``standard``. - Otherwise, the IP address cannot be used in an availability zone. - - -Dynamic Inventory Script ------------------------- - -If you are not familiar with Ansible's dynamic inventory scripts, check out :ref:`Intro to Dynamic Inventory `. - -The Azure Resource Manager inventory script is called `azure_rm.py `_. It authenticates with the Azure API exactly the same as the -Azure modules, which means you will either define the same environment variables described above in `Using Environment Variables`_, -create a ``$HOME/.azure/credentials`` file (also described above in `Storing in a File`_), or pass command line parameters. To see available command -line options execute the following: - -.. code-block:: bash - - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/azure_rm.py - $ ./azure_rm.py --help - -As with all dynamic inventory scripts, the script can be executed directly, passed as a parameter to the ansible command, -or passed directly to ansible-playbook using the -i option. No matter how it is executed the script produces JSON representing -all of the hosts found in your Azure subscription. You can narrow this down to just hosts found in a specific set of -Azure resource groups, or even down to a specific host. - -For a given host, the inventory script provides the following host variables: - -.. code-block:: JSON - - { - "ansible_host": "XXX.XXX.XXX.XXX", - "computer_name": "computer_name2", - "fqdn": null, - "id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Compute/virtualMachines/object-name", - "image": { - "offer": "CentOS", - "publisher": "OpenLogic", - "sku": "7.1", - "version": "latest" - }, - "location": "westus", - "mac_address": "00-00-5E-00-53-FE", - "name": "object-name", - "network_interface": "interface-name", - "network_interface_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkInterfaces/object-name1", - "network_security_group": null, - "network_security_group_id": null, - "os_disk": { - "name": "object-name", - "operating_system_type": "Linux" - }, - "plan": null, - "powerstate": "running", - "private_ip": "172.26.3.6", - "private_ip_alloc_method": "Static", - "provisioning_state": "Succeeded", - "public_ip": "XXX.XXX.XXX.XXX", - "public_ip_alloc_method": "Static", - "public_ip_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/publicIPAddresses/object-name", - "public_ip_name": "object-name", - "resource_group": "galaxy-production", - "security_group": "object-name", - "security_group_id": "/subscriptions/subscription-id/resourceGroups/galaxy-production/providers/Microsoft.Network/networkSecurityGroups/object-name", - "tags": { - "db": "mysql" - }, - "type": "Microsoft.Compute/virtualMachines", - "virtual_machine_size": "Standard_DS4" - } - -Host Groups -........... - -By default hosts are grouped by: - -* azure (all hosts) -* location name -* resource group name -* security group name -* tag key -* tag key_value -* os_disk operating_system_type (Windows/Linux) - -You can control host groupings and host selection by either defining environment variables or creating an -azure_rm.ini file in your current working directory. - -NOTE: An .ini file will take precedence over environment variables. - -NOTE: The name of the .ini file is the basename of the inventory script (in other words, 'azure_rm') with a '.ini' -extension. This allows you to copy, rename and customize the inventory script and have matching .ini files all in -the same directory. - -Control grouping using the following variables defined in the environment: - -* AZURE_GROUP_BY_RESOURCE_GROUP=yes -* AZURE_GROUP_BY_LOCATION=yes -* AZURE_GROUP_BY_SECURITY_GROUP=yes -* AZURE_GROUP_BY_TAG=yes -* AZURE_GROUP_BY_OS_FAMILY=yes - -Select hosts within specific resource groups by assigning a comma separated list to: - -* AZURE_RESOURCE_GROUPS=resource_group_a,resource_group_b - -Select hosts for specific tag key by assigning a comma separated list of tag keys to: - -* AZURE_TAGS=key1,key2,key3 - -Select hosts for specific locations by assigning a comma separated list of locations to: - -* AZURE_LOCATIONS=eastus,eastus2,westus - -Or, select hosts for specific tag key:value pairs by assigning a comma separated list key:value pairs to: - -* AZURE_TAGS=key1:value1,key2:value2 - -If you don't need the powerstate, you can improve performance by turning off powerstate fetching: - -* AZURE_INCLUDE_POWERSTATE=no - -A sample azure_rm.ini file is included along with the inventory script in -`here `_. -An .ini file will contain the following: - -.. code-block:: ini - - [azure] - # Control which resource groups are included. By default all resources groups are included. - # Set resource_groups to a comma separated list of resource groups names. - #resource_groups= - - # Control which tags are included. Set tags to a comma separated list of keys or key:value pairs - #tags= - - # Control which locations are included. Set locations to a comma separated list of locations. - #locations= - - # Include powerstate. If you don't need powerstate information, turning it off improves runtime performance. - # Valid values: yes, no, true, false, True, False, 0, 1. - include_powerstate=yes - - # Control grouping with the following boolean flags. Valid values: yes, no, true, false, True, False, 0, 1. - group_by_resource_group=yes - group_by_location=yes - group_by_security_group=yes - group_by_tag=yes - group_by_os_family=yes - -Examples -........ - -Here are some examples using the inventory script: - -.. code-block:: bash - - # Download inventory script - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/azure_rm.py - - # Execute /bin/uname on all instances in the Testing resource group - $ ansible -i azure_rm.py Testing -m shell -a "/bin/uname -a" - - # Execute win_ping on all Windows instances - $ ansible -i azure_rm.py windows -m win_ping - - # Execute ping on all Linux instances - $ ansible -i azure_rm.py linux -m ping - - # Use the inventory script to print instance specific information - $ ./azure_rm.py --host my_instance_host_name --resource-groups=Testing --pretty - - # Use the inventory script with ansible-playbook - $ ansible-playbook -i ./azure_rm.py test_playbook.yml - -Here is a simple playbook to exercise the Azure inventory script: - -.. code-block:: yaml - - - name: Test the inventory script - hosts: azure - connection: local - gather_facts: false - tasks: - - debug: - msg: "{{ inventory_hostname }} has powerstate {{ powerstate }}" - -You can execute the playbook with something like: - -.. code-block:: bash - - $ ansible-playbook -i ./azure_rm.py test_azure_inventory.yml - - -Disabling certificate validation on Azure endpoints -................................................... - -When an HTTPS proxy is present, or when using Azure Stack, it may be necessary to disable certificate validation for -Azure endpoints in the Azure modules. This is not a recommended security practice, but may be necessary when the system -CA store cannot be altered to include the necessary CA certificate. Certificate validation can be controlled by setting -the "cert_validation_mode" value in a credential profile, through the "AZURE_CERT_VALIDATION_MODE" environment variable, or -by passing the "cert_validation_mode" argument to any Azure module. The default value is "validate"; setting the value -to "ignore" will prevent all certificate validation. The module argument takes precedence over a credential profile value, -which takes precedence over the environment value. diff --git a/docs/docsite/rst/scenario_guides/guide_cloudstack.rst b/docs/docsite/rst/scenario_guides/guide_cloudstack.rst deleted file mode 100644 index 6d3f2b4d5ec..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_cloudstack.rst +++ /dev/null @@ -1,377 +0,0 @@ -CloudStack Cloud Guide -====================== - -.. _cloudstack_introduction: - -Introduction -```````````` -The purpose of this section is to explain how to put Ansible modules together to use Ansible in a CloudStack context. You will find more usage examples in the details section of each module. - -Ansible contains a number of extra modules for interacting with CloudStack based clouds. All modules support check mode, are designed to be idempotent, have been created and tested, and are maintained by the community. - -.. note:: Some of the modules will require domain admin or root admin privileges. - -Prerequisites -````````````` -Prerequisites for using the CloudStack modules are minimal. In addition to Ansible itself, all of the modules require the python library ``cs`` https://pypi.org/project/cs/ - -You'll need this Python module installed on the execution host, usually your workstation. - -.. code-block:: bash - - $ pip install cs - -Or alternatively starting with Debian 9 and Ubuntu 16.04: - -.. code-block:: bash - - $ sudo apt install python-cs - -.. note:: cs also includes a command line interface for ad hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``. - -Limitations and Known Issues -```````````````````````````` -VPC support has been improved since Ansible 2.3 but is still not yet fully implemented. The community is working on the VPC integration. - -Credentials File -```````````````` -You can pass credentials and the endpoint of your cloud as module arguments, however in most cases it is a far less work to store your credentials in the cloudstack.ini file. - -The python library cs looks for the credentials file in the following order (last one wins): - -* A ``.cloudstack.ini`` (note the dot) file in the home directory. -* A ``CLOUDSTACK_CONFIG`` environment variable pointing to an .ini file. -* A ``cloudstack.ini`` (without the dot) file in the current working directory, same directory as your playbooks are located. - -The structure of the ini file must look like this: - -.. code-block:: bash - - $ cat $HOME/.cloudstack.ini - [cloudstack] - endpoint = https://cloud.example.com/client/api - key = api key - secret = api secret - timeout = 30 - -.. Note:: The section ``[cloudstack]`` is the default section. ``CLOUDSTACK_REGION`` environment variable can be used to define the default section. - -.. versionadded:: 2.4 - -The ENV variables support ``CLOUDSTACK_*`` as written in the documentation of the library ``cs``, like ``CLOUDSTACK_TIMEOUT``, ``CLOUDSTACK_METHOD``, and so on. has been implemented into Ansible. It is even possible to have some incomplete config in your cloudstack.ini: - -.. code-block:: bash - - $ cat $HOME/.cloudstack.ini - [cloudstack] - endpoint = https://cloud.example.com/client/api - timeout = 30 - -and fulfill the missing data by either setting ENV variables or tasks params: - -.. code-block:: yaml - - --- - - name: provision our VMs - hosts: cloud-vm - tasks: - - name: ensure VMs are created and running - delegate_to: localhost - cs_instance: - api_key: your api key - api_secret: your api secret - ... - -Regions -``````` -If you use more than one CloudStack region, you can define as many sections as you want and name them as you like, for example: - -.. code-block:: bash - - $ cat $HOME/.cloudstack.ini - [exoscale] - endpoint = https://api.exoscale.ch/compute - key = api key - secret = api secret - - [example_cloud_one] - endpoint = https://cloud-one.example.com/client/api - key = api key - secret = api secret - - [example_cloud_two] - endpoint = https://cloud-two.example.com/client/api - key = api key - secret = api secret - -.. Hint:: Sections can also be used to for login into the same region using different accounts. - -By passing the argument ``api_region`` with the CloudStack modules, the region wanted will be selected. - -.. code-block:: yaml - - - name: ensure my ssh public key exists on Exoscale - cs_sshkeypair: - name: my-ssh-key - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - api_region: exoscale - delegate_to: localhost - -Or by looping over a regions list if you want to do the task in every region: - -.. code-block:: yaml - - - name: ensure my ssh public key exists in all CloudStack regions - local_action: cs_sshkeypair - name: my-ssh-key - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - api_region: "{{ item }}" - loop: - - exoscale - - example_cloud_one - - example_cloud_two - -Environment Variables -````````````````````` -.. versionadded:: 2.3 - -Since Ansible 2.3 it is possible to use environment variables for domain (``CLOUDSTACK_DOMAIN``), account (``CLOUDSTACK_ACCOUNT``), project (``CLOUDSTACK_PROJECT``), VPC (``CLOUDSTACK_VPC``) and zone (``CLOUDSTACK_ZONE``). This simplifies the tasks by not repeating the arguments for every tasks. - -Below you see an example how it can be used in combination with Ansible's block feature: - -.. code-block:: yaml - - - hosts: cloud-vm - tasks: - - block: - - name: ensure my ssh public key - cs_sshkeypair: - name: my-ssh-key - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - - - name: ensure my ssh public key - cs_instance: - display_name: "{{ inventory_hostname_short }}" - template: Linux Debian 7 64-bit 20GB Disk - service_offering: "{{ cs_offering }}" - ssh_key: my-ssh-key - state: running - - delegate_to: localhost - environment: - CLOUDSTACK_DOMAIN: root/customers - CLOUDSTACK_PROJECT: web-app - CLOUDSTACK_ZONE: sf-1 - -.. Note:: You are still able overwrite the environment variables using the module arguments, for example ``zone: sf-2`` - -.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ignored in the CLI ``cs``. - -Use Cases -````````` -The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start. - -Use Case: Provisioning in a Advanced Networking CloudStack setup -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host. - -This is how our inventory looks like: - -.. code-block:: none - - [cloud-vm:children] - webserver - db-server - jumphost - - [webserver] - web-01.example.com public_ip=198.51.100.20 - web-02.example.com public_ip=198.51.100.21 - - [db-server] - db-01.example.com - db-02.example.com - - [jumphost] - jump.example.com public_ip=198.51.100.22 - -As you can see, the public IPs for our web servers and jumphost has been assigned as variable ``public_ip`` directly in the inventory. - -The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifying the defaults of our cloud infrastructure. - -.. code-block:: yaml - - # file: group_vars/cloud-vm - --- - cs_offering: Small - cs_firewall: [] - -Our database servers should get more CPU and RAM, so we define to use a ``Large`` offering for them. - -.. code-block:: yaml - - # file: group_vars/db-server - --- - cs_offering: Large - -The web servers should get a ``Small`` offering as we would scale them horizontally, which is also our default offering. We also ensure the known web ports are opened for the world. - -.. code-block:: yaml - - # file: group_vars/webserver - --- - cs_firewall: - - { port: 80 } - - { port: 443 } - -Further we provision a jump host which has only port 22 opened for accessing the VMs from our office IPv4 network. - -.. code-block:: yaml - - # file: group_vars/jumphost - --- - cs_firewall: - - { port: 22, cidr: "17.17.17.0/24" } - -Now to the fun part. We create a playbook to create our infrastructure we call it ``infra.yml``: - -.. code-block:: yaml - - # file: infra.yaml - --- - - name: provision our VMs - hosts: cloud-vm - tasks: - - name: run all enclosed tasks from localhost - delegate_to: localhost - block: - - name: ensure VMs are created and running - cs_instance: - name: "{{ inventory_hostname_short }}" - template: Linux Debian 7 64-bit 20GB Disk - service_offering: "{{ cs_offering }}" - state: running - - - name: ensure firewall ports opened - cs_firewall: - ip_address: "{{ public_ip }}" - port: "{{ item.port }}" - cidr: "{{ item.cidr | default('0.0.0.0/0') }}" - loop: "{{ cs_firewall }}" - when: public_ip is defined - - - name: ensure static NATs - cs_staticnat: vm="{{ inventory_hostname_short }}" ip_address="{{ public_ip }}" - when: public_ip is defined - -In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``delegate_to: localhost`` to execute the API calls locally from our workstation. - -In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again. - -In the second task we ensure the ports are opened if we give a public IP to the VM. - -In the third task we add static NAT to the VMs having a public IP defined. - - -.. Note:: The public IP addresses must have been acquired in advance, also see ``cs_ip_address`` - -.. Note:: For some modules, for example ``cs_sshkeypair`` you usually want this to be executed only once, not for every VM. Therefore you would make a separate play for it targeting localhost. You find an example in the use cases below. - -Use Case: Provisioning on a Basic Networking CloudStack setup -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -A basic networking CloudStack setup is slightly different: Every VM gets a public IP directly assigned and security groups are used for access restriction policy. - -This is how our inventory looks like: - -.. code-block:: none - - [cloud-vm:children] - webserver - - [webserver] - web-01.example.com - web-02.example.com - -The default for your VMs looks like this: - -.. code-block:: yaml - - # file: group_vars/cloud-vm - --- - cs_offering: Small - cs_securitygroups: [ 'default'] - -Our webserver will also be in security group ``web``: - -.. code-block:: yaml - - # file: group_vars/webserver - --- - cs_securitygroups: [ 'default', 'web' ] - -The playbook looks like the following: - -.. code-block:: yaml - - # file: infra.yaml - --- - - name: cloud base setup - hosts: localhost - tasks: - - name: upload ssh public key - cs_sshkeypair: - name: defaultkey - public_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" - - - name: ensure security groups exist - cs_securitygroup: - name: "{{ item }}" - loop: - - default - - web - - - name: add inbound SSH to security group default - cs_securitygroup_rule: - security_group: default - start_port: "{{ item }}" - end_port: "{{ item }}" - loop: - - 22 - - - name: add inbound TCP rules to security group web - cs_securitygroup_rule: - security_group: web - start_port: "{{ item }}" - end_port: "{{ item }}" - loop: - - 80 - - 443 - - - name: install VMs in the cloud - hosts: cloud-vm - tasks: - - delegate_to: localhost - block: - - name: create and run VMs on CloudStack - cs_instance: - name: "{{ inventory_hostname_short }}" - template: Linux Debian 7 64-bit 20GB Disk - service_offering: "{{ cs_offering }}" - security_groups: "{{ cs_securitygroups }}" - ssh_key: defaultkey - state: Running - register: vm - - - name: show VM IP - debug: msg="VM {{ inventory_hostname }} {{ vm.default_ip }}" - - - name: assign IP to the inventory - set_fact: ansible_ssh_host={{ vm.default_ip }} - - - name: waiting for SSH to come up - wait_for: port=22 host={{ vm.default_ip }} delay=5 - -In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accessing the VMs with their DNS name. - -In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure. diff --git a/docs/docsite/rst/scenario_guides/guide_docker.rst b/docs/docsite/rst/scenario_guides/guide_docker.rst deleted file mode 100644 index 8fe81112a0b..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_docker.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Docker Guide -============ - -The content on this page has moved. Please see the updated :ref:`ansible_collections.community.docker.docsite.scenario_guide` in the `community.docker collection `_. diff --git a/docs/docsite/rst/scenario_guides/guide_gce.rst b/docs/docsite/rst/scenario_guides/guide_gce.rst deleted file mode 100644 index 54071040e2d..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_gce.rst +++ /dev/null @@ -1,302 +0,0 @@ -Google Cloud Platform Guide -=========================== - -.. gce_intro: - -Introduction --------------------------- - -Ansible + Google have been working together on a set of auto-generated -Ansible modules designed to consistently and comprehensively cover the entirety -of the Google Cloud Platform (GCP). - -Ansible contains modules for managing Google Cloud Platform resources, -including creating instances, controlling network access, working with -persistent disks, managing load balancers, and a lot more. - -These new modules can be found under a new consistent name scheme "gcp_*" -(Note: gcp_target_proxy and gcp_url_map are legacy modules, despite the "gcp_*" -name. Please use gcp_compute_target_proxy and gcp_compute_url_map instead). - -Additionally, the gcp_compute inventory plugin can discover all -Google Compute Engine (GCE) instances -and make them automatically available in your Ansible inventory. - -You may see a collection of other GCP modules that do not conform to this -naming convention. These are the original modules primarily developed by the -Ansible community. You will find some overlapping functionality such as with -the "gce" module and the new "gcp_compute_instance" module. Either can be -used, but you may experience issues trying to use them together. - -While the community GCP modules are not going away, Google is investing effort -into the new "gcp_*" modules. Google is committed to ensuring the Ansible -community has a great experience with GCP and therefore recommends adopting -these new modules if possible. - - -Requisites ---------------- -The GCP modules require both the ``requests`` and the -``google-auth`` libraries to be installed. - -.. code-block:: bash - - $ pip install requests google-auth - -Alternatively for RHEL / CentOS, the ``python-requests`` package is also -available to satisfy ``requests`` libraries. - -.. code-block:: bash - - $ yum install python-requests - -Credentials ------------ -It's easy to create a GCP account with credentials for Ansible. You have multiple options to -get your credentials - here are two of the most common options: - -* Service Accounts (Recommended): Use JSON service accounts with specific permissions. -* Machine Accounts: Use the permissions associated with the GCP Instance you're using Ansible on. - -For the following examples, we'll be using service account credentials. - -To work with the GCP modules, you'll first need to get some credentials in the -JSON format: - -1. `Create a Service Account `_ -2. `Download JSON credentials `_ - -Once you have your credentials, there are two different ways to provide them to Ansible: - -* by specifying them directly as module parameters -* by setting environment variables - -Providing Credentials as Module Parameters -`````````````````````````````````````````` - -For the GCE modules you can specify the credentials as arguments: - -* ``auth_kind``: type of authentication being used (choices: machineaccount, serviceaccount, application) -* ``service_account_email``: email associated with the project -* ``service_account_file``: path to the JSON credentials file -* ``project``: id of the project -* ``scopes``: The specific scopes that you want the actions to use. - -For example, to create a new IP address using the ``gcp_compute_address`` module, -you can use the following configuration: - -.. code-block:: yaml - - - name: Create IP address - hosts: localhost - gather_facts: false - - vars: - service_account_file: /home/my_account.json - project: my-project - auth_kind: serviceaccount - scopes: - - https://www.googleapis.com/auth/compute - - tasks: - - - name: Allocate an IP Address - gcp_compute_address: - state: present - name: 'test-address1' - region: 'us-west1' - project: "{{ project }}" - auth_kind: "{{ auth_kind }}" - service_account_file: "{{ service_account_file }}" - scopes: "{{ scopes }}" - -Providing Credentials as Environment Variables -`````````````````````````````````````````````` - -Set the following environment variables before running Ansible in order to configure your credentials: - -.. code-block:: bash - - GCP_AUTH_KIND - GCP_SERVICE_ACCOUNT_EMAIL - GCP_SERVICE_ACCOUNT_FILE - GCP_SCOPES - -GCE Dynamic Inventory ---------------------- - -The best way to interact with your hosts is to use the gcp_compute inventory plugin, which dynamically queries GCE and tells Ansible what nodes can be managed. - -To be able to use this GCE dynamic inventory plugin, you need to enable it first by specifying the following in the ``ansible.cfg`` file: - -.. code-block:: ini - - [inventory] - enable_plugins = gcp_compute - -Then, create a file that ends in ``.gcp.yml`` in your root directory. - -The gcp_compute inventory script takes in the same authentication information as any module. - -Here's an example of a valid inventory file: - -.. code-block:: yaml - - plugin: gcp_compute - projects: - - graphite-playground - auth_kind: serviceaccount - service_account_file: /home/alexstephen/my_account.json - - -Executing ``ansible-inventory --list -i .gcp.yml`` will create a list of GCP instances that are ready to be configured using Ansible. - -Create an instance -`````````````````` - -The full range of GCP modules provide the ability to create a wide variety of -GCP resources with the full support of the entire GCP API. - -The following playbook creates a GCE Instance. This instance relies on other GCP -resources like Disk. By creating other resources separately, we can give as -much detail as necessary about how we want to configure the other resources, for example -formatting of the Disk. By registering it to a variable, we can simply insert the -variable into the instance task. The gcp_compute_instance module will figure out the -rest. - -.. code-block:: yaml - - - name: Create an instance - hosts: localhost - gather_facts: false - vars: - gcp_project: my-project - gcp_cred_kind: serviceaccount - gcp_cred_file: /home/my_account.json - zone: "us-central1-a" - region: "us-central1" - - tasks: - - name: create a disk - gcp_compute_disk: - name: 'disk-instance' - size_gb: 50 - source_image: 'projects/ubuntu-os-cloud/global/images/family/ubuntu-1604-lts' - zone: "{{ zone }}" - project: "{{ gcp_project }}" - auth_kind: "{{ gcp_cred_kind }}" - service_account_file: "{{ gcp_cred_file }}" - scopes: - - https://www.googleapis.com/auth/compute - state: present - register: disk - - name: create a address - gcp_compute_address: - name: 'address-instance' - region: "{{ region }}" - project: "{{ gcp_project }}" - auth_kind: "{{ gcp_cred_kind }}" - service_account_file: "{{ gcp_cred_file }}" - scopes: - - https://www.googleapis.com/auth/compute - state: present - register: address - - name: create a instance - gcp_compute_instance: - state: present - name: test-vm - machine_type: n1-standard-1 - disks: - - auto_delete: true - boot: true - source: "{{ disk }}" - network_interfaces: - - network: null # use default - access_configs: - - name: 'External NAT' - nat_ip: "{{ address }}" - type: 'ONE_TO_ONE_NAT' - zone: "{{ zone }}" - project: "{{ gcp_project }}" - auth_kind: "{{ gcp_cred_kind }}" - service_account_file: "{{ gcp_cred_file }}" - scopes: - - https://www.googleapis.com/auth/compute - register: instance - - - name: Wait for SSH to come up - wait_for: host={{ address.address }} port=22 delay=10 timeout=60 - - - name: Add host to groupname - add_host: hostname={{ address.address }} groupname=new_instances - - - - name: Manage new instances - hosts: new_instances - connection: ssh - become: True - roles: - - base_configuration - - production_server - -Note that use of the "add_host" module above creates a temporary, in-memory group. This means that a play in the same playbook can then manage machines -in the 'new_instances' group, if so desired. Any sort of arbitrary configuration is possible at this point. - -For more information about Google Cloud, please visit the `Google Cloud website `_. - -Migration Guides ----------------- - -gce.py -> gcp_compute_instance.py -````````````````````````````````` -As of Ansible 2.8, we're encouraging everyone to move from the ``gce`` module to the -``gcp_compute_instance`` module. The ``gcp_compute_instance`` module has better -support for all of GCP's features, fewer dependencies, more flexibility, and -better supports GCP's authentication systems. - -The ``gcp_compute_instance`` module supports all of the features of the ``gce`` -module (and more!). Below is a mapping of ``gce`` fields over to -``gcp_compute_instance`` fields. - -============================ ========================================== ====================== - gce.py gcp_compute_instance.py Notes -============================ ========================================== ====================== - state state/status State on gce has multiple values: "present", "absent", "stopped", "started", "terminated". State on gcp_compute_instance is used to describe if the instance exists (present) or does not (absent). Status is used to describe if the instance is "started", "stopped" or "terminated". - image disks[].initialize_params.source_image You'll need to create a single disk using the disks[] parameter and set it to be the boot disk (disks[].boot = true) - image_family disks[].initialize_params.source_image See above. - external_projects disks[].initialize_params.source_image The name of the source_image will include the name of the project. - instance_names Use a loop or multiple tasks. Using loops is a more Ansible-centric way of creating multiple instances and gives you the most flexibility. - service_account_email service_accounts[].email This is the service_account email address that you want the instance to be associated with. It is not the service_account email address that is used for the credentials necessary to create the instance. - service_account_permissions service_accounts[].scopes These are the permissions you want to grant to the instance. - pem_file Not supported. We recommend using JSON service account credentials instead of PEM files. - credentials_file service_account_file - project_id project - name name This field does not accept an array of names. Use a loop to create multiple instances. - num_instances Use a loop For maximum flexibility, we're encouraging users to use Ansible features to create multiple instances, rather than letting the module do it for you. - network network_interfaces[].network - subnetwork network_interfaces[].subnetwork - persistent_boot_disk disks[].type = 'PERSISTENT' - disks disks[] - ip_forward can_ip_forward - external_ip network_interfaces[].access_configs.nat_ip This field takes multiple types of values. You can create an IP address with ``gcp_compute_address`` and place the name/output of the address here. You can also place the string value of the IP address's GCP name or the actual IP address. - disks_auto_delete disks[].auto_delete - preemptible scheduling.preemptible - disk_size disks[].initialize_params.disk_size_gb -============================ ========================================== ====================== - -An example playbook is below: - -.. code:: yaml - - gcp_compute_instance: - name: "{{ item }}" - machine_type: n1-standard-1 - ... # any other settings - zone: us-central1-a - project: "my-project" - auth_kind: "service_account_file" - service_account_file: "~/my_account.json" - state: present - loop: - - instance-1 - - instance-2 diff --git a/docs/docsite/rst/scenario_guides/guide_infoblox.rst b/docs/docsite/rst/scenario_guides/guide_infoblox.rst deleted file mode 100644 index c7227c50b53..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_infoblox.rst +++ /dev/null @@ -1,292 +0,0 @@ -.. _nios_guide: - -************************ - Infoblox Guide -************************ - -.. contents:: Topics - -This guide describes how to use Ansible with the Infoblox Network Identity Operating System (NIOS). With Ansible integration, you can use Ansible playbooks to automate Infoblox Core Network Services for IP address management (IPAM), DNS, and inventory tracking. - -You can review simple example tasks in the documentation for any of the :ref:`NIOS modules ` or look at the `Use cases with modules`_ section for more elaborate examples. See the `Infoblox `_ website for more information on the Infoblox product. - -.. note:: You can retrieve most of the example playbooks used in this guide from the `network-automation/infoblox_ansible `_ GitHub repository. - -Prerequisites -============= -Before using Ansible ``nios`` modules with Infoblox, you must install the ``infoblox-client`` on your Ansible control node: - -.. code-block:: bash - - $ sudo pip install infoblox-client - -.. note:: - You need an NIOS account with the WAPI feature enabled to use Ansible with Infoblox. - -.. _nios_credentials: - -Credentials and authenticating -============================== - -To use Infoblox ``nios`` modules in playbooks, you need to configure the credentials to access your Infoblox system. The examples in this guide use credentials stored in ``/group_vars/nios.yml``. Replace these values with your Infoblox credentials: - -.. code-block:: yaml - - --- - nios_provider: - host: 192.0.0.2 - username: admin - password: ansible - -NIOS lookup plugins -=================== - -Ansible includes the following lookup plugins for NIOS: - -- :ref:`nios ` Uses the Infoblox WAPI API to fetch NIOS specified objects, for example network views, DNS views, and host records. -- :ref:`nios_next_ip ` Provides the next available IP address from a network. You'll see an example of this in `Creating a host record`_. -- :ref:`nios_next_network ` - Returns the next available network range for a network-container. - -You must run the NIOS lookup plugins locally by specifying ``connection: local``. See :ref:`lookup plugins ` for more detail. - - -Retrieving all network views ----------------------------- - -To retrieve all network views and save them in a variable, use the :ref:`set_fact ` module with the :ref:`nios ` lookup plugin: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: fetch all networkview objects - set_fact: - networkviews: "{{ lookup('nios', 'networkview', provider=nios_provider) }}" - - - name: check the networkviews - debug: - var: networkviews - - -Retrieving a host record ------------------------- - -To retrieve a set of host records, use the ``set_fact`` module with the ``nios`` lookup plugin and include a filter for the specific hosts you want to retrieve: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: fetch host leaf01 - set_fact: - host: "{{ lookup('nios', 'record:host', filter={'name': 'leaf01.ansible.com'}, provider=nios_provider) }}" - - - name: check the leaf01 return variable - debug: - var: host - - - name: debug specific variable (ipv4 address) - debug: - var: host.ipv4addrs[0].ipv4addr - - - name: fetch host leaf02 - set_fact: - host: "{{ lookup('nios', 'record:host', filter={'name': 'leaf02.ansible.com'}, provider=nios_provider) }}" - - - name: check the leaf02 return variable - debug: - var: host - - -If you run this ``get_host_record.yml`` playbook, you should see results similar to the following: - -.. code-block:: none - - $ ansible-playbook get_host_record.yml - - PLAY [localhost] *************************************************************************************** - - TASK [fetch host leaf01] ****************************************************************************** - ok: [localhost] - - TASK [check the leaf01 return variable] ************************************************************* - ok: [localhost] => { - < ...output shortened...> - "host": { - "ipv4addrs": [ - { - "configure_for_dhcp": false, - "host": "leaf01.ansible.com", - } - ], - "name": "leaf01.ansible.com", - "view": "default" - } - } - - TASK [debug specific variable (ipv4 address)] ****************************************************** - ok: [localhost] => { - "host.ipv4addrs[0].ipv4addr": "192.168.1.11" - } - - TASK [fetch host leaf02] ****************************************************************************** - ok: [localhost] - - TASK [check the leaf02 return variable] ************************************************************* - ok: [localhost] => { - < ...output shortened...> - "host": { - "ipv4addrs": [ - { - "configure_for_dhcp": false, - "host": "leaf02.example.com", - "ipv4addr": "192.168.1.12" - } - ], - } - } - - PLAY RECAP ****************************************************************************************** - localhost : ok=5 changed=0 unreachable=0 failed=0 - -The output above shows the host record for ``leaf01.ansible.com`` and ``leaf02.ansible.com`` that were retrieved by the ``nios`` lookup plugin. This playbook saves the information in variables which you can use in other playbooks. This allows you to use Infoblox as a single source of truth to gather and use information that changes dynamically. See :ref:`playbooks_variables` for more information on using Ansible variables. See the :ref:`nios ` examples for more data options that you can retrieve. - -You can access these playbooks at `Infoblox lookup playbooks `_. - -Use cases with modules -====================== - -You can use the ``nios`` modules in tasks to simplify common Infoblox workflows. Be sure to set up your :ref:`NIOS credentials` before following these examples. - -Configuring an IPv4 network ---------------------------- - -To configure an IPv4 network, use the :ref:`nios_network ` module: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: Create a network on the default network view - nios_network: - network: 192.168.100.0/24 - comment: sets the IPv4 network - options: - - name: domain-name - value: ansible.com - state: present - provider: "{{nios_provider}}" - -Notice the last parameter, ``provider``, uses the variable ``nios_provider`` defined in the ``group_vars/`` directory. - -Creating a host record ----------------------- - -To create a host record named `leaf03.ansible.com` on the newly-created IPv4 network: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: configure an IPv4 host record - nios_host_record: - name: leaf03.ansible.com - ipv4addrs: - - ipv4addr: - "{{ lookup('nios_next_ip', '192.168.100.0/24', provider=nios_provider)[0] }}" - state: present - provider: "{{nios_provider}}" - -Notice the IPv4 address in this example uses the :ref:`nios_next_ip ` lookup plugin to find the next available IPv4 address on the network. - -Creating a forward DNS zone ---------------------------- - -To configure a forward DNS zone use, the ``nios_zone`` module: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: Create a forward DNS zone called ansible-test.com - nios_zone: - name: ansible-test.com - comment: local DNS zone - state: present - provider: "{{ nios_provider }}" - -Creating a reverse DNS zone ---------------------------- - -To configure a reverse DNS zone: - -.. code-block:: yaml - - --- - - hosts: nios - connection: local - tasks: - - name: configure a reverse mapping zone on the system using IPV6 zone format - nios_zone: - name: 100::1/128 - zone_format: IPV6 - state: present - provider: "{{ nios_provider }}" - -Dynamic inventory script -======================== - -You can use the Infoblox dynamic inventory script to import your network node inventory with Infoblox NIOS. To gather the inventory from Infoblox, you need two files: - -- `infoblox.yaml `_ - A file that specifies the NIOS provider arguments and optional filters. - -- `infoblox.py `_ - The python script that retrieves the NIOS inventory. - -.. note:: - - Please note that the inventory script only works when Ansible 2.9, 2.10 or 3 have been installed. The inventory script will eventually be removed from `community.general `_, and will not work if `community.general` is only installed with `ansible-galaxy collection install`. Please use the inventory plugin from `infoblox.nios_modules `_ instead. - -To use the Infoblox dynamic inventory script: - -#. Download the ``infoblox.yaml`` file and save it in the ``/etc/ansible`` directory. - -#. Modify the ``infoblox.yaml`` file with your NIOS credentials. - -#. Download the ``infoblox.py`` file and save it in the ``/etc/ansible/hosts`` directory. - -#. Change the permissions on the ``infoblox.py`` file to make the file an executable: - -.. code-block:: bash - - $ sudo chmod +x /etc/ansible/hosts/infoblox.py - -You can optionally use ``./infoblox.py --list`` to test the script. After a few minutes, you should see your Infoblox inventory in JSON format. You can explicitly use the Infoblox dynamic inventory script as follows: - -.. code-block:: bash - - $ ansible -i infoblox.py all -m ping - -You can also implicitly use the Infoblox dynamic inventory script by including it in your inventory directory (``etc/ansible/hosts`` by default). See :ref:`dynamic_inventory` for more details. - -.. seealso:: - - `Infoblox website `_ - The Infoblox website - `Infoblox and Ansible Deployment Guide `_ - The deployment guide for Ansible integration provided by Infoblox. - `Infoblox Integration in Ansible 2.5 `_ - Ansible blog post about Infoblox. - :ref:`Ansible NIOS modules ` - The list of supported NIOS modules, with examples. - `Infoblox Ansible Examples `_ - Infoblox example playbooks. diff --git a/docs/docsite/rst/scenario_guides/guide_meraki.rst b/docs/docsite/rst/scenario_guides/guide_meraki.rst deleted file mode 100644 index 94c5b161b35..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_meraki.rst +++ /dev/null @@ -1,193 +0,0 @@ -.. _meraki_guide: - -****************** -Cisco Meraki Guide -****************** - -.. contents:: - :local: - - -.. _meraki_guide_intro: - -What is Cisco Meraki? -===================== - -Cisco Meraki is an easy-to-use, cloud-based, network infrastructure platform for enterprise environments. While most network hardware uses command-line interfaces (CLIs) for configuration, Meraki uses an easy-to-use Dashboard hosted in the Meraki cloud. No on-premises management hardware or software is required - only the network infrastructure to run your business. - -MS Switches ------------ - -Meraki MS switches come in multiple flavors and form factors. Meraki switches support 10/100/1000/10000 ports, as well as Cisco's mGig technology for 2.5/5/10Gbps copper connectivity. 8, 24, and 48 port flavors are available with PoE (802.3af/802.3at/UPoE) available on many models. - -MX Firewalls ------------- - -Meraki's MX firewalls support full layer 3-7 deep packet inspection. MX firewalls are compatible with a variety of VPN technologies including IPSec, SSL VPN, and Meraki's easy-to-use AutoVPN. - -MR Wireless Access Points -------------------------- - -MR access points are enterprise-class, high-performance access points for the enterprise. MR access points have MIMO technology and integrated beamforming built-in for high performance applications. BLE allows for advanced location applications to be developed with no on-premises analytics platforms. - -Using the Meraki modules -======================== - -Meraki modules provide a user-friendly interface to manage your Meraki environment using Ansible. For example, details about SNMP settings for a particular organization can be discovered using the module `meraki_snmp `. - -.. code-block:: yaml - - - name: Query SNMP settings - meraki_snmp: - api_key: abc123 - org_name: AcmeCorp - state: query - delegate_to: localhost - -Information about a particular object can be queried. For example, the `meraki_admin ` module supports - -.. code-block:: yaml - - - name: Gather information about Jane Doe - meraki_admin: - api_key: abc123 - org_name: AcmeCorp - state: query - email: janedoe@email.com - delegate_to: localhost - -Common Parameters -================= - -All Ansible Meraki modules support the following parameters which affect communication with the Meraki Dashboard API. Most of these should only be used by Meraki developers and not the general public. - - host - Hostname or IP of Meraki Dashboard. - - use_https - Specifies whether communication should be over HTTPS. (Defaults to ``yes``) - - use_proxy - Whether to use a proxy for any communication. - - validate_certs - Determine whether certificates should be validated or trusted. (Defaults to ``yes``) - -These are the common parameters which are used for most every module. - - org_name - Name of organization to perform actions in. - - org_id - ID of organization to perform actions in. - - net_name - Name of network to perform actions in. - - net_id - ID of network to perform actions in. - - state - General specification of what action to take. ``query`` does lookups. ``present`` creates or edits. ``absent`` deletes. - -.. hint:: Use the ``org_id`` and ``net_id`` parameters when possible. ``org_name`` and ``net_name`` require additional behind-the-scenes API calls to learn the ID values. ``org_id`` and ``net_id`` will perform faster. - -Meraki Authentication -===================== - -All API access with the Meraki Dashboard requires an API key. An API key can be generated from the organization's settings page. Each play in a playbook requires the ``api_key`` parameter to be specified. - -The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information. - -Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first. - -Returned Data Structures -======================== - -Meraki and its related Ansible modules return most information in the form of a list. For example, this is returned information by ``meraki_admin`` querying administrators. It returns a list even though there's only one. - -.. code-block:: json - - [ - { - "orgAccess": "full", - "name": "John Doe", - "tags": [], - "networks": [], - "email": "john@doe.com", - "id": "12345677890" - } - ] - -Handling Returned Data -====================== - -Since Meraki's response data uses lists instead of properly keyed dictionaries for responses, certain strategies should be used when querying data for particular information. For many situations, use the ``selectattr()`` Jinja2 function. - -Merging Existing and New Data -============================= - -Ansible's Meraki modules do not allow for manipulating data. For example, you may need to insert a rule in the middle of a firewall ruleset. Ansible and the Meraki modules lack a way to directly merge to manipulate data. However, a playlist can use a few tasks to split the list where you need to insert a rule and then merge them together again with the new rule added. The steps involved are as follows: - -1. Create blank "front" and "back" lists. - :: - - vars: - - front_rules: [] - - back_rules: [] -2. Get existing firewall rules from Meraki and create a new variable. - :: - - - name: Get firewall rules - meraki_mx_l3_firewall: - auth_key: abc123 - org_name: YourOrg - net_name: YourNet - state: query - delegate_to: localhost - register: rules - - set_fact: - original_ruleset: '{{rules.data}}' -3. Write the new rule. The new rule needs to be in a list so it can be merged with other lists in an upcoming step. The blank `-` puts the rule in a list so it can be merged. - :: - - - set_fact: - new_rule: - - - - comment: Block traffic to server - src_cidr: 192.0.1.0/24 - src_port: any - dst_cidr: 192.0.1.2/32 - dst_port: any - protocol: any - policy: deny -4. Split the rules into two lists. This assumes the existing ruleset is 2 rules long. - :: - - - set_fact: - front_rules: '{{front_rules + [ original_ruleset[:1] ]}}' - - set_fact: - back_rules: '{{back_rules + [ original_ruleset[1:] ]}}' -5. Merge rules with the new rule in the middle. - :: - - - set_fact: - new_ruleset: '{{front_rules + new_rule + back_rules}}' -6. Upload new ruleset to Meraki. - :: - - - name: Set two firewall rules - meraki_mx_l3_firewall: - auth_key: abc123 - org_name: YourOrg - net_name: YourNet - state: present - rules: '{{ new_ruleset }}' - delegate_to: localhost - -Error Handling -============== - -Ansible's Meraki modules will often fail if improper or incompatible parameters are specified. However, there will likely be scenarios where the module accepts the information but the Meraki API rejects the data. If this happens, the error will be returned in the ``body`` field for HTTP status of 400 return code. - -Meraki's API returns a 404 error if the API key is not correct. It does not provide any specific error saying the key is incorrect. If you receive a 404 error, check the API key first. 404 errors can also occur if improper object IDs (ex. ``org_id``) are specified. diff --git a/docs/docsite/rst/scenario_guides/guide_online.rst b/docs/docsite/rst/scenario_guides/guide_online.rst deleted file mode 100644 index 2c181a949c1..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_online.rst +++ /dev/null @@ -1,41 +0,0 @@ -**************** -Online.net Guide -**************** - -Introduction -============ - -Online is a French hosting company mainly known for providing bare-metal servers named Dedibox. -Check it out: `https://www.online.net/en `_ - -Dynamic inventory for Online resources --------------------------------------- - -Ansible has a dynamic inventory plugin that can list your resources. - -1. Create a YAML configuration such as ``online_inventory.yml`` with this content: - -.. code-block:: yaml - - plugin: online - -2. Set your ``ONLINE_TOKEN`` environment variable with your token. - You need to open an account and log into it before you can get a token. - You can find your token at the following page: `https://console.online.net/en/api/access `_ - -3. You can test that your inventory is working by running: - -.. code-block:: bash - - $ ansible-inventory -v -i online_inventory.yml --list - - -4. Now you can run your playbook or any other module with this inventory: - -.. code-block:: console - - $ ansible all -i online_inventory.yml -m ping - sd-96735 | SUCCESS => { - "changed": false, - "ping": "pong" - } diff --git a/docs/docsite/rst/scenario_guides/guide_oracle.rst b/docs/docsite/rst/scenario_guides/guide_oracle.rst deleted file mode 100644 index 170ea9031ba..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_oracle.rst +++ /dev/null @@ -1,103 +0,0 @@ -=================================== -Oracle Cloud Infrastructure Guide -=================================== - -************ -Introduction -************ - -Oracle provides a number of Ansible modules to interact with Oracle Cloud Infrastructure (OCI). In this guide, we will explain how you can use these modules to orchestrate, provision and configure your infrastructure on OCI. - -************ -Requirements -************ -To use the OCI Ansible modules, you must have the following prerequisites on your control node, the computer from which Ansible playbooks are executed. - -1. `An Oracle Cloud Infrastructure account. `_ - -2. A user created in that account, in a security group with a policy that grants the necessary permissions for working with resources in those compartments. For guidance, see `How Policies Work `_. - -3. The necessary credentials and OCID information. - -************ -Installation -************ -1. Install the Oracle Cloud Infrastructure Python SDK (`detailed installation instructions `_): - -.. code-block:: bash - - pip install oci - -2. Install the Ansible OCI Modules in one of two ways: - -a. From Galaxy: - -.. code-block:: bash - - ansible-galaxy install oracle.oci_ansible_modules - -b. From GitHub: - -.. code-block:: bash - - $ git clone https://github.com/oracle/oci-ansible-modules.git - -.. code-block:: bash - - $ cd oci-ansible-modules - - -Run one of the following commands: - -- If Ansible is installed only for your user: - -.. code-block:: bash - - $ ./install.py - -- If Ansible is installed as root: - -.. code-block:: bash - - $ sudo ./install.py - -************* -Configuration -************* - -When creating and configuring Oracle Cloud Infrastructure resources, Ansible modules use the authentication information outlined `here `_. -. - -******** -Examples -******** -Launch a compute instance -========================= -This `sample launch playbook `_ -launches a public Compute instance and then accesses the instance from an Ansible module over an SSH connection. The sample illustrates how to: - -- Generate a temporary, host-specific SSH key pair. -- Specify the public key from the key pair for connecting to the instance, and then launch the instance. -- Connect to the newly launched instance using SSH. - -Create and manage Autonomous Data Warehouses -============================================ -This `sample warehouse playbook `_ creates an Autonomous Data Warehouse and manage its lifecycle. The sample shows how to: - -- Set up an Autonomous Data Warehouse. -- List all of the Autonomous Data Warehouse instances available in a compartment, filtered by the display name. -- Get the "facts" for a specified Autonomous Data Warehouse. -- Stop and start an Autonomous Data Warehouse instance. -- Delete an Autonomous Data Warehouse instance. - -Create and manage Autonomous Transaction Processing -=================================================== -This `sample playbook `_ -creates an Autonomous Transaction Processing database and manage its lifecycle. The sample shows how to: - -- Set up an Autonomous Transaction Processing database instance. -- List all of the Autonomous Transaction Processing instances in a compartment, filtered by the display name. -- Get the "facts" for a specified Autonomous Transaction Processing instance. -- Delete an Autonomous Transaction Processing database instance. - -You can find more examples here: `Sample Ansible Playbooks `_. diff --git a/docs/docsite/rst/scenario_guides/guide_packet.rst b/docs/docsite/rst/scenario_guides/guide_packet.rst deleted file mode 100644 index 512620c2454..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_packet.rst +++ /dev/null @@ -1,311 +0,0 @@ -********************************** -Packet.net Guide -********************************** - -Introduction -============ - -`Packet.net `_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) through a dynamic inventory script and two cloud modules. The two modules are: - -- packet_sshkey: adds a public SSH key from file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys. -- packet_device: manages servers on Packet. You can use this module to create, restart and delete devices. - -Note, this guide assumes you are familiar with Ansible and how it works. If you're not, have a look at their :ref:`docs ` before getting started. - -Requirements -============ - -The Packet modules and inventory script connect to the Packet API using the packet-python package. You can install it with pip: - -.. code-block:: bash - - $ pip install packet-python - -In order to check the state of devices created by Ansible on Packet, it's a good idea to install one of the `Packet CLI clients `_. Otherwise you can check them through the `Packet portal `_. - -To use the modules and inventory script you'll need a Packet API token. You can generate an API token through the Packet portal `here `__. The simplest way to authenticate yourself is to set the Packet API token in an environment variable: - -.. code-block:: bash - - $ export PACKET_API_TOKEN=Bfse9F24SFtfs423Gsd3ifGsd43sSdfs - -If you're not comfortable exporting your API token, you can pass it as a parameter to the modules. - -On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or through one of the available `CLIs `_. - - -If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as: - -.. code-block:: bash - - $ ssh-keygen -t rsa -f ./id_rsa - -If you want to use an existing key pair, just copy the private and public key over to the playbook directory. - - -Device Creation -=============== - -The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters through a `CLI client `_. - -.. code-block:: yaml - - # playbook_create.yml - - - name: create ubuntu device - hosts: localhost - tasks: - - - packet_sshkey: - key_file: ./id_rsa.pub - label: tutorial key - - - packet_device: - project_id: - hostnames: myserver - operating_system: ubuntu_16_04 - plan: baremetal_0 - facility: sjc1 - -After running ``ansible-playbook playbook_create.yml``, you should have a server provisioned on Packet. You can verify through a CLI or in the `Packet portal `__. - -If you get an error with the message "failed to set machine state present, error: Error 404: Not Found", please verify your project UUID. - - -Updating Devices -================ - -The two parameters used to uniquely identify Packet devices are: "device_ids" and "hostnames". Both parameters accept either a single string (later converted to a one-element list), or a list of strings. - -The 'device_ids' and 'hostnames' parameters are mutually exclusive. The following values are all acceptable: - -- device_ids: a27b7a83-fc93-435b-a128-47a5b04f2dcf - -- hostnames: mydev1 - -- device_ids: [a27b7a83-fc93-435b-a128-47a5b04f2dcf, 4887130f-0ccd-49a0-99b0-323c1ceb527b] - -- hostnames: [mydev1, mydev2] - -In addition, hostnames can contain a special '%d' formatter along with a 'count' parameter that lets you easily expand hostnames that follow a simple name and number pattern; in other words, ``hostnames: "mydev%d", count: 2`` will expand to [mydev1, mydev2]. - -If your playbook acts on existing Packet devices, you can only pass the 'hostname' and 'device_ids' parameters. The following playbook shows how you can reboot a specific Packet device by setting the 'hostname' parameter: - -.. code-block:: yaml - - # playbook_reboot.yml - - - name: reboot myserver - hosts: localhost - tasks: - - - packet_device: - project_id: - hostnames: myserver - state: rebooted - -You can also identify specific Packet devices with the 'device_ids' parameter. The device's UUID can be found in the `Packet Portal `_ or by using a `CLI `_. The following playbook removes a Packet device using the 'device_ids' field: - -.. code-block:: yaml - - # playbook_remove.yml - - - name: remove a device - hosts: localhost - tasks: - - - packet_device: - project_id: - device_ids: - state: absent - - -More Complex Playbooks -====================== - -In this example, we'll create a CoreOS cluster with `user data `_. - - -The CoreOS cluster will use `etcd `_ for discovery of other servers in the cluster. Before provisioning your servers, you'll need to generate a discovery token for your cluster: - -.. code-block:: bash - - $ curl -w "\n" 'https://discovery.etcd.io/new?size=3' - -The following playbook will create an SSH key, 3 Packet servers, and then wait until SSH is ready (or until 5 minutes passed). Make sure to substitute the discovery token URL in 'user_data', and the 'project_id' before running ``ansible-playbook``. Also, feel free to change 'plan' and 'facility'. - -.. code-block:: yaml - - # playbook_coreos.yml - - - name: Start 3 CoreOS nodes in Packet and wait until SSH is ready - hosts: localhost - tasks: - - - packet_sshkey: - key_file: ./id_rsa.pub - label: new - - - packet_device: - hostnames: [coreos-one, coreos-two, coreos-three] - operating_system: coreos_beta - plan: baremetal_0 - facility: ewr1 - project_id: - wait_for_public_IPv: 4 - user_data: | - #cloud-config - coreos: - etcd2: - discovery: https://discovery.etcd.io/ - advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001 - initial-advertise-peer-urls: http://$private_ipv4:2380 - listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001 - listen-peer-urls: http://$private_ipv4:2380 - fleet: - public-ip: $private_ipv4 - units: - - name: etcd2.service - command: start - - name: fleet.service - command: start - register: newhosts - - - name: wait for ssh - wait_for: - delay: 1 - host: "{{ item.public_ipv4 }}" - port: 22 - state: started - timeout: 500 - loop: "{{ newhosts.results[0].devices }}" - - -As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect. - -The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified by the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter. - -The ``packet_device`` module has a ``wait_for_public_IPv`` that is used to specify the version of the IP address to wait for (valid values are ``4`` or ``6`` for IPv4 or IPv6). If specified, Ansible will wait until the GET API call for a device contains an Internet-routeable IP address of the specified version. When referring to an IP address of a created device in subsequent module calls, it's wise to use the ``wait_for_public_IPv`` parameter, or ``state: active`` in the packet_device module call. - -Run the playbook: - -.. code-block:: bash - - $ ansible-playbook playbook_coreos.yml - -Once the playbook quits, your new devices should be reachable through SSH. Try to connect to one and check if etcd has started properly: - -.. code-block:: bash - - tomk@work $ ssh -i id_rsa core@$one_of_the_servers_ip - core@coreos-one ~ $ etcdctl cluster-health - -Once you create a couple of devices, you might appreciate the dynamic inventory script... - - -Dynamic Inventory Script -======================== - -The dynamic inventory script queries the Packet API for a list of hosts, and exposes it to Ansible so you can easily identify and act on Packet devices. - -You can find it in Ansible Community General Collection's git repo at `scripts/inventory/packet_net.py `_. - -The inventory script is configurable through an `ini file `_. - -If you want to use the inventory script, you must first export your Packet API token to a PACKET_API_TOKEN environment variable. - -You can either copy the inventory and ini config out from the cloned git repo, or you can download it to your working directory like so: - -.. code-block:: bash - - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/packet_net.py - $ chmod +x packet_net.py - $ wget https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/packet_net.ini - -In order to understand what the inventory script gives to Ansible you can run: - -.. code-block:: bash - - $ ./packet_net.py --list - -It should print a JSON document looking similar to following trimmed dictionary: - -.. code-block:: json - - { - "_meta": { - "hostvars": { - "147.75.64.169": { - "packet_billing_cycle": "hourly", - "packet_created_at": "2017-02-09T17:11:26Z", - "packet_facility": "ewr1", - "packet_hostname": "coreos-two", - "packet_href": "/devices/d0ab8972-54a8-4bff-832b-28549d1bec96", - "packet_id": "d0ab8972-54a8-4bff-832b-28549d1bec96", - "packet_locked": false, - "packet_operating_system": "coreos_beta", - "packet_plan": "baremetal_0", - "packet_state": "active", - "packet_updated_at": "2017-02-09T17:16:35Z", - "packet_user": "core", - "packet_userdata": "#cloud-config\ncoreos:\n etcd2:\n discovery: https://discovery.etcd.io/e0c8a4a9b8fe61acd51ec599e2a4f68e\n advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001\n initial-advertise-peer-urls: http://$private_ipv4:2380\n listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001\n listen-peer-urls: http://$private_ipv4:2380\n fleet:\n public-ip: $private_ipv4\n units:\n - name: etcd2.service\n command: start\n - name: fleet.service\n command: start" - } - } - }, - "baremetal_0": [ - "147.75.202.255", - "147.75.202.251", - "147.75.202.249", - "147.75.64.129", - "147.75.192.51", - "147.75.64.169" - ], - "coreos_beta": [ - "147.75.202.255", - "147.75.202.251", - "147.75.202.249", - "147.75.64.129", - "147.75.192.51", - "147.75.64.169" - ], - "ewr1": [ - "147.75.64.129", - "147.75.192.51", - "147.75.64.169" - ], - "sjc1": [ - "147.75.202.255", - "147.75.202.251", - "147.75.202.249" - ], - "coreos-two": [ - "147.75.64.169" - ], - "d0ab8972-54a8-4bff-832b-28549d1bec96": [ - "147.75.64.169" - ] - } - -In the ``['_meta']['hostvars']`` key, there is a list of devices (uniquely identified by their public IPv4 address) with their parameters. The other keys under ``['_meta']`` are lists of devices grouped by some parameter. Here, it is type (all devices are of type baremetal_0), operating system, and facility (ewr1 and sjc1). - -In addition to the parameter groups, there are also one-item groups with the UUID or hostname of the device. - -You can now target groups in playbooks! The following playbook will install a role that supplies resources for an Ansible target into all devices in the "coreos_beta" group: - -.. code-block:: yaml - - # playbook_bootstrap.yml - - - hosts: coreos_beta - gather_facts: false - roles: - - defunctzombie.coreos-boostrap - -Don't forget to supply the dynamic inventory in the ``-i`` argument! - -.. code-block:: bash - - $ ansible-playbook -u core -i packet_net.py playbook_bootstrap.yml - - -If you have any questions or comments let us know! help@packet.net diff --git a/docs/docsite/rst/scenario_guides/guide_rax.rst b/docs/docsite/rst/scenario_guides/guide_rax.rst deleted file mode 100644 index 439ba187250..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_rax.rst +++ /dev/null @@ -1,809 +0,0 @@ -Rackspace Cloud Guide -===================== - -.. _rax_introduction: - -Introduction -```````````` - -.. note:: Rackspace functionality in Ansible is not maintained and users should consider the `OpenStack collection `_ instead. - -Ansible contains a number of core modules for interacting with Rackspace Cloud. - -The purpose of this section is to explain how to put Ansible modules together -(and use inventory scripts) to use Ansible in a Rackspace Cloud context. - -Prerequisites for using the rax modules are minimal. In addition to ansible itself, -all of the modules require and are tested against pyrax 1.5 or higher. -You'll need this Python module installed on the execution host. - -``pyrax`` is not currently available in many operating system -package repositories, so you will likely need to install it through pip: - -.. code-block:: bash - - $ pip install pyrax - -Ansible creates an implicit localhost that executes in the same context as the ``ansible-playbook`` and the other CLI tools. -If for any reason you need or want to have it in your inventory you should do something like the following: - -.. code-block:: ini - - [localhost] - localhost ansible_connection=local ansible_python_interpreter=/usr/local/bin/python2 - -For more information see :ref:`Implicit Localhost ` - -In playbook steps, we'll typically be using the following pattern: - -.. code-block:: yaml - - - hosts: localhost - gather_facts: False - tasks: - -.. _credentials_file: - -Credentials File -```````````````` - -The `rax.py` inventory script and all `rax` modules support a standard `pyrax` credentials file that looks like: - -.. code-block:: ini - - [rackspace_cloud] - username = myraxusername - api_key = d41d8cd98f00b204e9800998ecf8427e - -Setting the environment parameter ``RAX_CREDS_FILE`` to the path of this file will help Ansible find how to load -this information. - -More information about this credentials file can be found at -https://github.com/pycontribs/pyrax/blob/master/docs/getting_started.md#authenticating - - -.. _virtual_environment: - -Running from a Python Virtual Environment (Optional) -++++++++++++++++++++++++++++++++++++++++++++++++++++ - -Most users will not be using virtualenv, but some users, particularly Python developers sometimes like to. - -There are special considerations when Ansible is installed to a Python virtualenv, rather than the default of installing at a global scope. Ansible assumes, unless otherwise instructed, that the python binary will live at /usr/bin/python. This is done through the interpreter line in modules, however when instructed by setting the inventory variable 'ansible_python_interpreter', Ansible will use this specified path instead to find Python. This can be a cause of confusion as one may assume that modules running on 'localhost', or perhaps running through 'local_action', are using the virtualenv Python interpreter. By setting this line in the inventory, the modules will execute in the virtualenv interpreter and have available the virtualenv packages, specifically pyrax. If using virtualenv, you may wish to modify your localhost inventory definition to find this location as follows: - -.. code-block:: ini - - [localhost] - localhost ansible_connection=local ansible_python_interpreter=/path/to/ansible_venv/bin/python - -.. note:: - - pyrax may be installed in the global Python package scope or in a virtual environment. There are no special considerations to keep in mind when installing pyrax. - -.. _provisioning: - -Provisioning -```````````` - -Now for the fun parts. - -The 'rax' module provides the ability to provision instances within Rackspace Cloud. Typically the provisioning task will be performed from your Ansible control server (in our example, localhost) against the Rackspace cloud API. This is done for several reasons: - - - Avoiding installing the pyrax library on remote nodes - - No need to encrypt and distribute credentials to remote nodes - - Speed and simplicity - -.. note:: - - Authentication with the Rackspace-related modules is handled by either - specifying your username and API key as environment variables or passing - them as module arguments, or by specifying the location of a credentials - file. - -Here is a basic example of provisioning an instance in ad hoc mode: - -.. code-block:: bash - - $ ansible localhost -m rax -a "name=awx flavor=4 image=ubuntu-1204-lts-precise-pangolin wait=yes" - -Here's what it would look like in a playbook, assuming the parameters were defined in variables: - -.. code-block:: yaml - - tasks: - - name: Provision a set of instances - rax: - name: "{{ rax_name }}" - flavor: "{{ rax_flavor }}" - image: "{{ rax_image }}" - count: "{{ rax_count }}" - group: "{{ group }}" - wait: true - register: rax - delegate_to: localhost - -The rax module returns data about the nodes it creates, like IP addresses, hostnames, and login passwords. By registering the return value of the step, it is possible used this data to dynamically add the resulting hosts to inventory (temporarily, in memory). This facilitates performing configuration actions on the hosts in a follow-on task. In the following example, the servers that were successfully created using the above task are dynamically added to a group called "raxhosts", with each nodes hostname, IP address, and root password being added to the inventory. - -.. code-block:: yaml - - - name: Add the instances we created (by public IP) to the group 'raxhosts' - add_host: - hostname: "{{ item.name }}" - ansible_host: "{{ item.rax_accessipv4 }}" - ansible_password: "{{ item.rax_adminpass }}" - groups: raxhosts - loop: "{{ rax.success }}" - when: rax.action == 'create' - -With the host group now created, the next play in this playbook could now configure servers belonging to the raxhosts group. - -.. code-block:: yaml - - - name: Configuration play - hosts: raxhosts - user: root - roles: - - ntp - - webserver - -The method above ties the configuration of a host with the provisioning step. This isn't always what you want, and leads us -to the next section. - -.. _host_inventory: - -Host Inventory -`````````````` - -Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle this is to use the "rax" inventory plugin, which dynamically queries Rackspace Cloud and tells Ansible what nodes you have to manage. You might want to use this even if you are spinning up cloud instances through other tools, including the Rackspace Cloud user interface. The inventory plugin can be used to group resources by metadata, region, OS, and so on. Utilizing metadata is highly recommended in "rax" and can provide an easy way to sort between host groups and roles. If you don't want to use the ``rax.py`` dynamic inventory script, you could also still choose to manually manage your INI inventory file, though this is less recommended. - -In Ansible it is quite possible to use multiple dynamic inventory plugins along with INI file data. Just put them in a common directory and be sure the scripts are chmod +x, and the INI-based ones are not. - -.. _raxpy: - -rax.py -++++++ - -To use the Rackspace dynamic inventory script, copy ``rax.py`` into your inventory directory and make it executable. You can specify a credentials file for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable. - -.. note:: Dynamic inventory scripts (like ``rax.py``) are saved in ``/usr/share/ansible/inventory`` if Ansible has been installed globally. If installed to a virtualenv, the inventory scripts are installed to ``$VIRTUALENV/share/inventory``. - -.. note:: Users of :ref:`ansible_platform` will note that dynamic inventory is natively supported by the controller in the platform, and all you have to do is associate a group with your Rackspace Cloud credentials, and it will easily synchronize without going through these steps:: - - $ RAX_CREDS_FILE=~/.raxpub ansible all -i rax.py -m setup - -``rax.py`` also accepts a ``RAX_REGION`` environment variable, which can contain an individual region, or a comma separated list of regions. - -When using ``rax.py``, you will not have a 'localhost' defined in the inventory. - -As mentioned previously, you will often be running most of these modules outside of the host loop, and will need 'localhost' defined. The recommended way to do this, would be to create an ``inventory`` directory, and place both the ``rax.py`` script and a file containing ``localhost`` in it. - -Executing ``ansible`` or ``ansible-playbook`` and specifying the ``inventory`` directory instead -of an individual file, will cause ansible to evaluate each file in that directory for inventory. - -Let's test our inventory script to see if it can talk to Rackspace Cloud. - -.. code-block:: bash - - $ RAX_CREDS_FILE=~/.raxpub ansible all -i inventory/ -m setup - -Assuming things are properly configured, the ``rax.py`` inventory script will output information similar to the -following information, which will be utilized for inventory and variables. - -.. code-block:: json - - { - "ORD": [ - "test" - ], - "_meta": { - "hostvars": { - "test": { - "ansible_host": "198.51.100.1", - "rax_accessipv4": "198.51.100.1", - "rax_accessipv6": "2001:DB8::2342", - "rax_addresses": { - "private": [ - { - "addr": "192.0.2.2", - "version": 4 - } - ], - "public": [ - { - "addr": "198.51.100.1", - "version": 4 - }, - { - "addr": "2001:DB8::2342", - "version": 6 - } - ] - }, - "rax_config_drive": "", - "rax_created": "2013-11-14T20:48:22Z", - "rax_flavor": { - "id": "performance1-1", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/flavors/performance1-1", - "rel": "bookmark" - } - ] - }, - "rax_hostid": "e7b6961a9bd943ee82b13816426f1563bfda6846aad84d52af45a4904660cde0", - "rax_human_id": "test", - "rax_id": "099a447b-a644-471f-87b9-a7f580eb0c2a", - "rax_image": { - "id": "b211c7bf-b5b4-4ede-a8de-a4368750c653", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/images/b211c7bf-b5b4-4ede-a8de-a4368750c653", - "rel": "bookmark" - } - ] - }, - "rax_key_name": null, - "rax_links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/v2/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "self" - }, - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "bookmark" - } - ], - "rax_metadata": { - "foo": "bar" - }, - "rax_name": "test", - "rax_name_attr": "name", - "rax_networks": { - "private": [ - "192.0.2.2" - ], - "public": [ - "198.51.100.1", - "2001:DB8::2342" - ] - }, - "rax_os-dcf_diskconfig": "AUTO", - "rax_os-ext-sts_power_state": 1, - "rax_os-ext-sts_task_state": null, - "rax_os-ext-sts_vm_state": "active", - "rax_progress": 100, - "rax_status": "ACTIVE", - "rax_tenant_id": "111111", - "rax_updated": "2013-11-14T20:49:27Z", - "rax_user_id": "22222" - } - } - } - } - -.. _standard_inventory: - -Standard Inventory -++++++++++++++++++ - -When utilizing a standard ini formatted inventory file (as opposed to the inventory plugin), it may still be advantageous to retrieve discoverable hostvar information from the Rackspace API. - -This can be achieved with the ``rax_facts`` module and an inventory file similar to the following: - -.. code-block:: ini - - [test_servers] - hostname1 rax_region=ORD - hostname2 rax_region=ORD - -.. code-block:: yaml - - - name: Gather info about servers - hosts: test_servers - gather_facts: False - tasks: - - name: Get facts about servers - rax_facts: - credentials: ~/.raxpub - name: "{{ inventory_hostname }}" - region: "{{ rax_region }}" - delegate_to: localhost - - name: Map some facts - set_fact: - ansible_host: "{{ rax_accessipv4 }}" - -While you don't need to know how it works, it may be interesting to know what kind of variables are returned. - -The ``rax_facts`` module provides facts as following, which match the ``rax.py`` inventory script: - -.. code-block:: json - - { - "ansible_facts": { - "rax_accessipv4": "198.51.100.1", - "rax_accessipv6": "2001:DB8::2342", - "rax_addresses": { - "private": [ - { - "addr": "192.0.2.2", - "version": 4 - } - ], - "public": [ - { - "addr": "198.51.100.1", - "version": 4 - }, - { - "addr": "2001:DB8::2342", - "version": 6 - } - ] - }, - "rax_config_drive": "", - "rax_created": "2013-11-14T20:48:22Z", - "rax_flavor": { - "id": "performance1-1", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/flavors/performance1-1", - "rel": "bookmark" - } - ] - }, - "rax_hostid": "e7b6961a9bd943ee82b13816426f1563bfda6846aad84d52af45a4904660cde0", - "rax_human_id": "test", - "rax_id": "099a447b-a644-471f-87b9-a7f580eb0c2a", - "rax_image": { - "id": "b211c7bf-b5b4-4ede-a8de-a4368750c653", - "links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/images/b211c7bf-b5b4-4ede-a8de-a4368750c653", - "rel": "bookmark" - } - ] - }, - "rax_key_name": null, - "rax_links": [ - { - "href": "https://ord.servers.api.rackspacecloud.com/v2/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "self" - }, - { - "href": "https://ord.servers.api.rackspacecloud.com/111111/servers/099a447b-a644-471f-87b9-a7f580eb0c2a", - "rel": "bookmark" - } - ], - "rax_metadata": { - "foo": "bar" - }, - "rax_name": "test", - "rax_name_attr": "name", - "rax_networks": { - "private": [ - "192.0.2.2" - ], - "public": [ - "198.51.100.1", - "2001:DB8::2342" - ] - }, - "rax_os-dcf_diskconfig": "AUTO", - "rax_os-ext-sts_power_state": 1, - "rax_os-ext-sts_task_state": null, - "rax_os-ext-sts_vm_state": "active", - "rax_progress": 100, - "rax_status": "ACTIVE", - "rax_tenant_id": "111111", - "rax_updated": "2013-11-14T20:49:27Z", - "rax_user_id": "22222" - }, - "changed": false - } - - -Use Cases -````````` - -This section covers some additional usage examples built around a specific use case. - -.. _network_and_server: - -Network and Server -++++++++++++++++++ - -Create an isolated cloud network and build a server - -.. code-block:: yaml - - - name: Build Servers on an Isolated Network - hosts: localhost - gather_facts: False - tasks: - - name: Network create request - rax_network: - credentials: ~/.raxpub - label: my-net - cidr: 192.168.3.0/24 - region: IAD - state: present - delegate_to: localhost - - - name: Server create request - rax: - credentials: ~/.raxpub - name: web%04d.example.org - flavor: 2 - image: ubuntu-1204-lts-precise-pangolin - disk_config: manual - networks: - - public - - my-net - region: IAD - state: present - count: 5 - exact_count: true - group: web - wait: true - wait_timeout: 360 - register: rax - delegate_to: localhost - -.. _complete_environment: - -Complete Environment -++++++++++++++++++++ - -Build a complete webserver environment with servers, custom networks and load balancers, install nginx and create a custom index.html - -.. code-block:: yaml - - --- - - name: Build environment - hosts: localhost - gather_facts: False - tasks: - - name: Load Balancer create request - rax_clb: - credentials: ~/.raxpub - name: my-lb - port: 80 - protocol: HTTP - algorithm: ROUND_ROBIN - type: PUBLIC - timeout: 30 - region: IAD - wait: true - state: present - meta: - app: my-cool-app - register: clb - - - name: Network create request - rax_network: - credentials: ~/.raxpub - label: my-net - cidr: 192.168.3.0/24 - state: present - region: IAD - register: network - - - name: Server create request - rax: - credentials: ~/.raxpub - name: web%04d.example.org - flavor: performance1-1 - image: ubuntu-1204-lts-precise-pangolin - disk_config: manual - networks: - - public - - private - - my-net - region: IAD - state: present - count: 5 - exact_count: true - group: web - wait: true - register: rax - - - name: Add servers to web host group - add_host: - hostname: "{{ item.name }}" - ansible_host: "{{ item.rax_accessipv4 }}" - ansible_password: "{{ item.rax_adminpass }}" - ansible_user: root - groups: web - loop: "{{ rax.success }}" - when: rax.action == 'create' - - - name: Add servers to Load balancer - rax_clb_nodes: - credentials: ~/.raxpub - load_balancer_id: "{{ clb.balancer.id }}" - address: "{{ item.rax_networks.private|first }}" - port: 80 - condition: enabled - type: primary - wait: true - region: IAD - loop: "{{ rax.success }}" - when: rax.action == 'create' - - - name: Configure servers - hosts: web - handlers: - - name: restart nginx - service: name=nginx state=restarted - - tasks: - - name: Install nginx - apt: pkg=nginx state=latest update_cache=yes cache_valid_time=86400 - notify: - - restart nginx - - - name: Ensure nginx starts on boot - service: name=nginx state=started enabled=yes - - - name: Create custom index.html - copy: content="{{ inventory_hostname }}" dest=/usr/share/nginx/www/index.html - owner=root group=root mode=0644 - -.. _rackconnect_and_manged_cloud: - -RackConnect and Managed Cloud -+++++++++++++++++++++++++++++ - -When using RackConnect version 2 or Rackspace Managed Cloud there are Rackspace automation tasks that are executed on the servers you create after they are successfully built. If your automation executes before the RackConnect or Managed Cloud automation, you can cause failures and unusable servers. - -These examples show creating servers, and ensuring that the Rackspace automation has completed before Ansible continues onwards. - -For simplicity, these examples are joined, however both are only needed when using RackConnect. When only using Managed Cloud, the RackConnect portion can be ignored. - -The RackConnect portions only apply to RackConnect version 2. - -.. _using_a_control_machine: - -Using a Control Machine -*********************** - -.. code-block:: yaml - - - name: Create an exact count of servers - hosts: localhost - gather_facts: False - tasks: - - name: Server build requests - rax: - credentials: ~/.raxpub - name: web%03d.example.org - flavor: performance1-1 - image: ubuntu-1204-lts-precise-pangolin - disk_config: manual - region: DFW - state: present - count: 1 - exact_count: true - group: web - wait: true - register: rax - - - name: Add servers to in memory groups - add_host: - hostname: "{{ item.name }}" - ansible_host: "{{ item.rax_accessipv4 }}" - ansible_password: "{{ item.rax_adminpass }}" - ansible_user: root - rax_id: "{{ item.rax_id }}" - groups: web,new_web - loop: "{{ rax.success }}" - when: rax.action == 'create' - - - name: Wait for rackconnect and managed cloud automation to complete - hosts: new_web - gather_facts: false - tasks: - - name: ensure we run all tasks from localhost - delegate_to: localhost - block: - - name: Wait for rackconnnect automation to complete - rax_facts: - credentials: ~/.raxpub - id: "{{ rax_id }}" - region: DFW - register: rax_facts - until: rax_facts.ansible_facts['rax_metadata']['rackconnect_automation_status']|default('') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Wait for managed cloud automation to complete - rax_facts: - credentials: ~/.raxpub - id: "{{ rax_id }}" - region: DFW - register: rax_facts - until: rax_facts.ansible_facts['rax_metadata']['rax_service_level_automation']|default('') == 'Complete' - retries: 30 - delay: 10 - - - name: Update new_web hosts with IP that RackConnect assigns - hosts: new_web - gather_facts: false - tasks: - - name: Get facts about servers - rax_facts: - name: "{{ inventory_hostname }}" - region: DFW - delegate_to: localhost - - name: Map some facts - set_fact: - ansible_host: "{{ rax_accessipv4 }}" - - - name: Base Configure Servers - hosts: web - roles: - - role: users - - - role: openssh - opensshd_PermitRootLogin: "no" - - - role: ntp - -.. _using_ansible_pull: - -Using Ansible Pull -****************** - -.. code-block:: yaml - - --- - - name: Ensure Rackconnect and Managed Cloud Automation is complete - hosts: all - tasks: - - name: ensure we run all tasks from localhost - delegate_to: localhost - block: - - name: Check for completed bootstrap - stat: - path: /etc/bootstrap_complete - register: bootstrap - - - name: Get region - command: xenstore-read vm-data/provider_data/region - register: rax_region - when: bootstrap.stat.exists != True - - - name: Wait for rackconnect automation to complete - uri: - url: "https://{{ rax_region.stdout|trim }}.api.rackconnect.rackspace.com/v1/automation_status?format=json" - return_content: true - register: automation_status - when: bootstrap.stat.exists != True - until: automation_status['automation_status']|default('') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Wait for managed cloud automation to complete - wait_for: - path: /tmp/rs_managed_cloud_automation_complete - delay: 10 - when: bootstrap.stat.exists != True - - - name: Set bootstrap completed - file: - path: /etc/bootstrap_complete - state: touch - owner: root - group: root - mode: 0400 - - - name: Base Configure Servers - hosts: all - roles: - - role: users - - - role: openssh - opensshd_PermitRootLogin: "no" - - - role: ntp - -.. _using_ansible_pull_with_xenstore: - -Using Ansible Pull with XenStore -******************************** - -.. code-block:: yaml - - --- - - name: Ensure Rackconnect and Managed Cloud Automation is complete - hosts: all - tasks: - - name: Check for completed bootstrap - stat: - path: /etc/bootstrap_complete - register: bootstrap - - - name: Wait for rackconnect_automation_status xenstore key to exist - command: xenstore-exists vm-data/user-metadata/rackconnect_automation_status - register: rcas_exists - when: bootstrap.stat.exists != True - failed_when: rcas_exists.rc|int > 1 - until: rcas_exists.rc|int == 0 - retries: 30 - delay: 10 - - - name: Wait for rackconnect automation to complete - command: xenstore-read vm-data/user-metadata/rackconnect_automation_status - register: rcas - when: bootstrap.stat.exists != True - until: rcas.stdout|replace('"', '') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Wait for rax_service_level_automation xenstore key to exist - command: xenstore-exists vm-data/user-metadata/rax_service_level_automation - register: rsla_exists - when: bootstrap.stat.exists != True - failed_when: rsla_exists.rc|int > 1 - until: rsla_exists.rc|int == 0 - retries: 30 - delay: 10 - - - name: Wait for managed cloud automation to complete - command: xenstore-read vm-data/user-metadata/rackconnect_automation_status - register: rsla - when: bootstrap.stat.exists != True - until: rsla.stdout|replace('"', '') == 'DEPLOYED' - retries: 30 - delay: 10 - - - name: Set bootstrap completed - file: - path: /etc/bootstrap_complete - state: touch - owner: root - group: root - mode: 0400 - - - name: Base Configure Servers - hosts: all - roles: - - role: users - - - role: openssh - opensshd_PermitRootLogin: "no" - - - role: ntp - -.. _advanced_usage: - -Advanced Usage -`````````````` - -.. _awx_autoscale: - -Autoscaling with AWX or Red Hat Ansible Automation Platform -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -The GUI component of :ref:`Red Hat Ansible Automation Platform ` also contains a very nice feature for auto-scaling use cases. In this mode, a simple curl script can call -a defined URL and the server will "dial out" to the requester and configure an instance that is spinning up. This can be a great way -to reconfigure ephemeral nodes. See `the documentation on provisioning callbacks `_ for more details. - -A benefit of using the callback approach over pull mode is that job results are still centrally recorded -and less information has to be shared with remote hosts. - -.. _pending_information: - -Orchestration in the Rackspace Cloud -++++++++++++++++++++++++++++++++++++ - -Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other piece of software in an environment. Complex deployments might have previously required manual manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additional nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example: - -* Servers that are removed from a Cloud Load Balancer one-by-one, updated, verified, and returned to the load balancer pool -* Expansion of an already-online environment, where nodes are provisioned, bootstrapped, configured, and software installed -* A procedure where app log files are uploaded to a central location, like Cloud Files, before a node is decommissioned -* Servers and load balancers that have DNS records created and destroyed on creation and decommissioning, respectively - - - - diff --git a/docs/docsite/rst/scenario_guides/guide_scaleway.rst b/docs/docsite/rst/scenario_guides/guide_scaleway.rst deleted file mode 100644 index 0baf58a5e26..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_scaleway.rst +++ /dev/null @@ -1,293 +0,0 @@ -.. _guide_scaleway: - -************** -Scaleway Guide -************** - -.. _scaleway_introduction: - -Introduction -============ - -`Scaleway `_ is a cloud provider supported by Ansible, version 2.6 or higher through a dynamic inventory plugin and modules. -Those modules are: - -- :ref:`scaleway_sshkey_module`: adds a public SSH key from a file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys. -- :ref:`scaleway_compute_module`: manages servers on Scaleway. You can use this module to create, restart and delete servers. -- :ref:`scaleway_volume_module`: manages volumes on Scaleway. - -.. note:: - This guide assumes you are familiar with Ansible and how it works. - If you're not, have a look at :ref:`ansible_documentation` before getting started. - -.. _scaleway_requirements: - -Requirements -============ - -The Scaleway modules and inventory script connect to the Scaleway API using `Scaleway REST API `_. -To use the modules and inventory script you'll need a Scaleway API token. -You can generate an API token through the Scaleway console `here `__. -The simplest way to authenticate yourself is to set the Scaleway API token in an environment variable: - -.. code-block:: bash - - $ export SCW_TOKEN=00000000-1111-2222-3333-444444444444 - -If you're not comfortable exporting your API token, you can pass it as a parameter to the modules using the ``api_token`` argument. - -If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as: - -.. code-block:: bash - - $ ssh-keygen -t rsa -f ./id_rsa - -If you want to use an existing key pair, just copy the private and public key over to the playbook directory. - -.. _scaleway_add_sshkey: - -How to add an SSH key? -====================== - -Connection to Scaleway Compute nodes use Secure Shell. -SSH keys are stored at the account level, which means that you can re-use the same SSH key in multiple nodes. -The first step to configure Scaleway compute resources is to have at least one SSH key configured. - -:ref:`scaleway_sshkey_module` is a module that manages SSH keys on your Scaleway account. -You can add an SSH key to your account by including the following task in a playbook: - -.. code-block:: yaml - - - name: "Add SSH key" - scaleway_sshkey: - ssh_pub_key: "ssh-rsa AAAA..." - state: "present" - -The ``ssh_pub_key`` parameter contains your ssh public key as a string. Here is an example inside a playbook: - - -.. code-block:: yaml - - - name: Test SSH key lifecycle on a Scaleway account - hosts: localhost - gather_facts: false - environment: - SCW_API_KEY: "" - - tasks: - - - scaleway_sshkey: - ssh_pub_key: "ssh-rsa AAAAB...424242 developer@example.com" - state: present - register: result - - - assert: - that: - - result is success and result is changed - -.. _scaleway_create_instance: - -How to create a compute instance? -================================= - -Now that we have an SSH key configured, the next step is to spin up a server! -:ref:`scaleway_compute_module` is a module that can create, update and delete Scaleway compute instances: - -.. code-block:: yaml - - - name: Create a server - scaleway_compute: - name: foobar - state: present - image: 00000000-1111-2222-3333-444444444444 - organization: 00000000-1111-2222-3333-444444444444 - region: ams1 - commercial_type: START1-S - -Here are the parameter details for the example shown above: - -- ``name`` is the name of the instance (the one that will show up in your web console). -- ``image`` is the UUID of the system image you would like to use. - A list of all images is available for each availability zone. -- ``organization`` represents the organization that your account is attached to. -- ``region`` represents the Availability Zone which your instance is in (for this example, par1 and ams1). -- ``commercial_type`` represents the name of the commercial offers. - You can check out the Scaleway pricing page to find which instance is right for you. - -Take a look at this short playbook to see a working example using ``scaleway_compute``: - -.. code-block:: yaml - - - name: Test compute instance lifecycle on a Scaleway account - hosts: localhost - gather_facts: false - environment: - SCW_API_KEY: "" - - tasks: - - - name: Create a server - register: server_creation_task - scaleway_compute: - name: foobar - state: present - image: 00000000-1111-2222-3333-444444444444 - organization: 00000000-1111-2222-3333-444444444444 - region: ams1 - commercial_type: START1-S - wait: true - - - debug: var=server_creation_task - - - assert: - that: - - server_creation_task is success - - server_creation_task is changed - - - name: Run it - scaleway_compute: - name: foobar - state: running - image: 00000000-1111-2222-3333-444444444444 - organization: 00000000-1111-2222-3333-444444444444 - region: ams1 - commercial_type: START1-S - wait: true - tags: - - web_server - register: server_run_task - - - debug: var=server_run_task - - - assert: - that: - - server_run_task is success - - server_run_task is changed - -.. _scaleway_dynamic_inventory_tutorial: - -Dynamic Inventory Script -======================== - -Ansible ships with :ref:`scaleway_inventory`. -You can now get a complete inventory of your Scaleway resources through this plugin and filter it on -different parameters (``regions`` and ``tags`` are currently supported). - -Let's create an example! -Suppose that we want to get all hosts that got the tag web_server. -Create a file named ``scaleway_inventory.yml`` with the following content: - -.. code-block:: yaml - - plugin: scaleway - regions: - - ams1 - - par1 - tags: - - web_server - -This inventory means that we want all hosts that got the tag ``web_server`` on the zones ``ams1`` and ``par1``. -Once you have configured this file, you can get the information using the following command: - -.. code-block:: bash - - $ ansible-inventory --list -i scaleway_inventory.yml - -The output will be: - -.. code-block:: yaml - - { - "_meta": { - "hostvars": { - "dd8e3ae9-0c7c-459e-bc7b-aba8bfa1bb8d": { - "ansible_verbosity": 6, - "arch": "x86_64", - "commercial_type": "START1-S", - "hostname": "foobar", - "ipv4": "192.0.2.1", - "organization": "00000000-1111-2222-3333-444444444444", - "state": "running", - "tags": [ - "web_server" - ] - } - } - }, - "all": { - "children": [ - "ams1", - "par1", - "ungrouped", - "web_server" - ] - }, - "ams1": {}, - "par1": { - "hosts": [ - "dd8e3ae9-0c7c-459e-bc7b-aba8bfa1bb8d" - ] - }, - "ungrouped": {}, - "web_server": { - "hosts": [ - "dd8e3ae9-0c7c-459e-bc7b-aba8bfa1bb8d" - ] - } - } - -As you can see, we get different groups of hosts. -``par1`` and ``ams1`` are groups based on location. -``web_server`` is a group based on a tag. - -In case a filter parameter is not defined, the plugin supposes all values possible are wanted. -This means that for each tag that exists on your Scaleway compute nodes, a group based on each tag will be created. - -Scaleway S3 object storage -========================== - -`Object Storage `_ allows you to store any kind of objects (documents, images, videos, and so on). -As the Scaleway API is S3 compatible, Ansible supports it natively through the modules: :ref:`s3_bucket_module`, :ref:`aws_s3_module`. - -You can find many examples in the `scaleway_s3 integration tests `_. - -.. code-block:: yaml+jinja - - - hosts: myserver - vars: - scaleway_region: nl-ams - s3_url: https://s3.nl-ams.scw.cloud - environment: - # AWS_ACCESS_KEY matches your scaleway organization id available at https://cloud.scaleway.com/#/account - AWS_ACCESS_KEY: 00000000-1111-2222-3333-444444444444 - # AWS_SECRET_KEY matches a secret token that you can retrieve at https://cloud.scaleway.com/#/credentials - AWS_SECRET_KEY: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee - module_defaults: - group/aws: - s3_url: '{{ s3_url }}' - region: '{{ scaleway_region }}' - tasks: - # use a fact instead of a variable, otherwise template is evaluate each time variable is used - - set_fact: - bucket_name: "{{ 99999999 | random | to_uuid }}" - - # "requester_pays:" is mandatory because Scaleway doesn't implement related API - # another way is to use aws_s3 and "mode: create" ! - - s3_bucket: - name: '{{ bucket_name }}' - requester_pays: - - - name: Another way to create the bucket - aws_s3: - bucket: '{{ bucket_name }}' - mode: create - encrypt: false - register: bucket_creation_check - - - name: add something in the bucket - aws_s3: - mode: put - bucket: '{{ bucket_name }}' - src: /tmp/test.txt # needs to be created before - object: test.txt - encrypt: false # server side encryption must be disabled diff --git a/docs/docsite/rst/scenario_guides/guide_vagrant.rst b/docs/docsite/rst/scenario_guides/guide_vagrant.rst deleted file mode 100644 index f49477b0400..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_vagrant.rst +++ /dev/null @@ -1,136 +0,0 @@ -Vagrant Guide -============= - -.. _vagrant_intro: - -Introduction -```````````` - -`Vagrant `_ is a tool to manage virtual machine -environments, and allows you to configure and use reproducible work -environments on top of various virtualization and cloud platforms. -It also has integration with Ansible as a provisioner for these virtual -machines, and the two tools work together well. - -This guide will describe how to use Vagrant 1.7+ and Ansible together. - -If you're not familiar with Vagrant, you should visit `the documentation -`_. - -This guide assumes that you already have Ansible installed and working. -Running from a Git checkout is fine. Follow the :ref:`installation_guide` -guide for more information. - -.. _vagrant_setup: - -Vagrant Setup -````````````` - -The first step once you've installed Vagrant is to create a ``Vagrantfile`` -and customize it to suit your needs. This is covered in detail in the Vagrant -documentation, but here is a quick example that includes a section to use the -Ansible provisioner to manage a single machine: - -.. code-block:: ruby - - # This guide is optimized for Vagrant 1.8 and above. - # Older versions of Vagrant put less info in the inventory they generate. - Vagrant.require_version ">= 1.8.0" - - Vagrant.configure(2) do |config| - - config.vm.box = "ubuntu/bionic64" - - config.vm.provision "ansible" do |ansible| - ansible.verbose = "v" - ansible.playbook = "playbook.yml" - end - end - -Notice the ``config.vm.provision`` section that refers to an Ansible playbook -called ``playbook.yml`` in the same directory as the ``Vagrantfile``. Vagrant -runs the provisioner once the virtual machine has booted and is ready for SSH -access. - -There are a lot of Ansible options you can configure in your ``Vagrantfile``. -Visit the `Ansible Provisioner documentation -`_ for more -information. - -.. code-block:: bash - - $ vagrant up - -This will start the VM, and run the provisioning playbook (on the first VM -startup). - - -To re-run a playbook on an existing VM, just run: - -.. code-block:: bash - - $ vagrant provision - -This will re-run the playbook against the existing VM. - -Note that having the ``ansible.verbose`` option enabled will instruct Vagrant -to show the full ``ansible-playbook`` command used behind the scene, as -illustrated by this example: - -.. code-block:: bash - - $ PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit="default" --inventory-file=/home/someone/coding-in-a-project/.vagrant/provisioners/ansible/inventory -v playbook.yml - -This information can be quite useful to debug integration issues and can also -be used to manually execute Ansible from a shell, as explained in the next -section. - -.. _running_ansible: - -Running Ansible Manually -```````````````````````` - -Sometimes you may want to run Ansible manually against the machines. This is -faster than kicking ``vagrant provision`` and pretty easy to do. - -With our ``Vagrantfile`` example, Vagrant automatically creates an Ansible -inventory file in ``.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory``. -This inventory is configured according to the SSH tunnel that Vagrant -automatically creates. A typical automatically-created inventory file for a -single machine environment may look something like this: - -.. code-block:: none - - # Generated by Vagrant - - default ansible_host=127.0.0.1 ansible_port=2222 ansible_user='vagrant' ansible_ssh_private_key_file='/home/someone/coding-in-a-project/.vagrant/machines/default/virtualbox/private_key' - -If you want to run Ansible manually, you will want to make sure to pass -``ansible`` or ``ansible-playbook`` commands the correct arguments, at least -for the *inventory*. - -.. code-block:: bash - - $ ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml - -Advanced Usages -``````````````` - -The "Tips and Tricks" chapter of the `Ansible Provisioner documentation -`_ provides detailed information about more advanced Ansible features like: - - - how to execute a playbook in parallel within a multi-machine environment - - how to integrate a local ``ansible.cfg`` configuration file - -.. seealso:: - - `Vagrant Home `_ - The Vagrant homepage with downloads - `Vagrant Documentation `_ - Vagrant Documentation - `Ansible Provisioner `_ - The Vagrant documentation for the Ansible provisioner - `Vagrant Issue Tracker `_ - The open issues for the Ansible provisioner in the Vagrant project - :ref:`working_with_playbooks` - An introduction to playbooks diff --git a/docs/docsite/rst/scenario_guides/guide_vmware_rest.rst b/docs/docsite/rst/scenario_guides/guide_vmware_rest.rst deleted file mode 100644 index e93e352254f..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_vmware_rest.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _vmware_rest_scenarios: - -**************************** -VMware REST Scenarios -**************************** - -These scenarios teach you how to accomplish common VMware tasks using the REST API and the Ansible ``vmware.vmware_rest`` collection. To get started, please select the task you want to accomplish. - -.. toctree:: - :maxdepth: 1 - - vmware_rest_scenarios/installation - vmware_rest_scenarios/authentication - vmware_rest_scenarios/collect_information - vmware_rest_scenarios/create_vm - vmware_rest_scenarios/vm_info - vmware_rest_scenarios/vm_hardware_tuning - vmware_rest_scenarios/run_a_vm - vmware_rest_scenarios/vm_tool_information - vmware_rest_scenarios/vm_tool_configuration diff --git a/docs/docsite/rst/scenario_guides/guide_vultr.rst b/docs/docsite/rst/scenario_guides/guide_vultr.rst deleted file mode 100644 index a946c91dc2e..00000000000 --- a/docs/docsite/rst/scenario_guides/guide_vultr.rst +++ /dev/null @@ -1,171 +0,0 @@ -Vultr Guide -=========== - -Ansible offers a set of modules to interact with `Vultr `_ cloud platform. - -This set of module forms a framework that allows one to easily manage and orchestrate one's infrastructure on Vultr cloud platform. - - -Requirements ------------- - -There is actually no technical requirement; simply an already created Vultr account. - - -Configuration -------------- - -Vultr modules offer a rather flexible way with regard to configuration. - -Configuration is read in that order: - -- Environment Variables (eg. ``VULTR_API_KEY``, ``VULTR_API_TIMEOUT``) -- File specified by environment variable ``VULTR_API_CONFIG`` -- ``vultr.ini`` file located in current working directory -- ``$HOME/.vultr.ini`` - - -Ini file are structured this way: - -.. code-block:: ini - - [default] - key = MY_API_KEY - timeout = 60 - - [personal_account] - key = MY_PERSONAL_ACCOUNT_API_KEY - timeout = 30 - - -If ``VULTR_API_ACCOUNT`` environment variable or ``api_account`` module parameter is not specified, modules will look for the section named "default". - - -Authentication --------------- - -Before using the Ansible modules to interact with Vultr, you need an API key. -If you don't yet own one, log in to `Vultr `_ go to Account, then API, enable API then the API key should show up. - -Ensure you allow the usage of the API key from the proper IP addresses. - -Refer to the Configuration section to find out where to put this information. - -To check that everything is working properly run the following command: - -.. code-block:: console - - #> VULTR_API_KEY=XXX ansible -m vultr_account_info localhost - localhost | SUCCESS => { - "changed": false, - "vultr_account_info": { - "balance": -8.9, - "last_payment_amount": -10.0, - "last_payment_date": "2018-07-21 11:34:46", - "pending_charges": 6.0 - }, - "vultr_api": { - "api_account": "default", - "api_endpoint": "https://api.vultr.com", - "api_retries": 5, - "api_timeout": 60 - } - } - - -If a similar output displays then everything is setup properly, else please ensure the proper ``VULTR_API_KEY`` has been specified and that Access Controls on Vultr > Account > API page are accurate. - - -Usage ------ - -Since `Vultr `_ offers a public API, the execution of the module to manage the infrastructure on their platform will happen on localhost. This translates to: - -.. code-block:: yaml - - --- - - hosts: localhost - tasks: - - name: Create a 10G volume - vultr_block_storage: - name: my_disk - size: 10 - region: New Jersey - - -From that point on, only your creativity is the limit. Make sure to read the documentation of the `available modules `_. - - -Dynamic Inventory ------------------ - -Ansible provides a dynamic inventory plugin for `Vultr `_. -The configuration process is exactly the same as for the modules. - -To be able to use it you need to enable it first by specifying the following in the ``ansible.cfg`` file: - -.. code-block:: ini - - [inventory] - enable_plugins=vultr - -And provide a configuration file to be used with the plugin, the minimal configuration file looks like this: - -.. code-block:: yaml - - --- - plugin: vultr - -To list the available hosts one can simply run: - -.. code-block:: console - - #> ansible-inventory -i vultr.yml --list - - -For example, this allows you to take action on nodes grouped by location or OS name: - -.. code-block:: yaml - - --- - - hosts: Amsterdam - tasks: - - name: Rebooting the machine - shell: reboot - become: True - - -Integration tests ------------------ - -Ansible includes integration tests for all Vultr modules. - -These tests are meant to run against the public Vultr API and that is why they require a valid key to access the API. - -Prepare the test setup: - -.. code-block:: shell - - $ cd ansible # location the ansible source is - $ source ./hacking/env-setup - -Set the Vultr API key: - -.. code-block:: shell - - $ cd test/integration - $ cp cloud-config-vultr.ini.template cloud-config-vultr.ini - $ vi cloud-config-vultr.ini - -Run all Vultr tests: - -.. code-block:: shell - - $ ansible-test integration cloud/vultr/ -v --diff --allow-unsupported - - -To run a specific test, for example vultr_account_info: - -.. code-block:: shell - - $ ansible-test integration cloud/vultr/vultr_account_info -v --diff --allow-unsupported diff --git a/docs/docsite/rst/scenario_guides/guides.rst b/docs/docsite/rst/scenario_guides/guides.rst deleted file mode 100644 index 8b6c54fbcae..00000000000 --- a/docs/docsite/rst/scenario_guides/guides.rst +++ /dev/null @@ -1,44 +0,0 @@ -:orphan: - -.. unified index page included for backwards compatibility - -****************** -Scenario Guides -****************** - -The guides in this section are migrating into collections. Remaining guides may be out of date. - -These guides cover integrating Ansible with a variety of platforms, products, and technologies. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -We are migrating these guides into collections. Please update your links for the following guides: - -:ref:`ansible_collections.amazon.aws.docsite.aws_intro` - -.. toctree:: - :maxdepth: 1 - :caption: Legacy Public Cloud Guides - - guide_alicloud - guide_cloudstack - guide_gce - guide_azure - guide_online - guide_oracle - guide_packet - guide_rax - guide_scaleway - guide_vultr - -.. toctree:: - :maxdepth: 1 - :caption: Network Technology Guides - - guide_aci - guide_meraki - guide_infoblox - -.. toctree:: - :maxdepth: 1 - :caption: Virtualization & Containerization Guides - - guide_vagrant diff --git a/docs/docsite/rst/scenario_guides/network_guides.rst b/docs/docsite/rst/scenario_guides/network_guides.rst deleted file mode 100644 index 2b538ff05ed..00000000000 --- a/docs/docsite/rst/scenario_guides/network_guides.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. _network_guides: - -************************* -Network Technology Guides -************************* - -The guides in this section cover using Ansible with specific network technologies. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -.. toctree:: - :maxdepth: 1 - - guide_aci - guide_meraki - guide_infoblox - -To learn more about Network Automation with Ansible, see :ref:`network_getting_started` and :ref:`network_advanced`. diff --git a/docs/docsite/rst/scenario_guides/scenario_template.rst b/docs/docsite/rst/scenario_guides/scenario_template.rst deleted file mode 100644 index 14695bed648..00000000000 --- a/docs/docsite/rst/scenario_guides/scenario_template.rst +++ /dev/null @@ -1,53 +0,0 @@ -:orphan: - -.. _scenario_template: - -************************************* -Sample scenario for Ansible platforms -************************************* - -*Use this ``rst`` file as a starting point to create a scenario guide for your platform. The sections below are suggestions on what should be in a scenario guide.* - -Introductory paragraph. - -.. contents:: - :local: - -Prerequisites -============= - -Describe the requirements and assumptions for this scenario. This should include applicable subsections for hardware, software, and any other caveats to using the scenarios in this guide. - -Credentials and authenticating -============================== - -Describe credential requirements and how to authenticate to this platform. - -Using dynamic inventory -========================= - -If applicable, describe how to use a dynamic inventory plugin for this platform. - - -Example description -=================== - -Description and code here. Change the section header to something descriptive about this example, such as "Renaming a virtual machine". The goal is that this is the text someone would search for to find your example. - - -Example output --------------- - -What the user should expect to see. - - -Troubleshooting ---------------- - -What to look for if it breaks. - - -Conclusion and where to go next -=============================== - -Recap of important points. For more information please see: links. diff --git a/docs/docsite/rst/scenario_guides/virt_guides.rst b/docs/docsite/rst/scenario_guides/virt_guides.rst deleted file mode 100644 index bc9007861c7..00000000000 --- a/docs/docsite/rst/scenario_guides/virt_guides.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _virtualization_guides: - -****************************************** -Virtualization and Containerization Guides -****************************************** - -The guides in this section cover integrating Ansible with popular tools for creating virtual machines and containers. They explore particular use cases in greater depth and provide a more "top-down" explanation of some basic features. - -.. toctree:: - :maxdepth: 1 - - guide_docker - guide_vagrant - guide_vmware_rest diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/authentication.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/authentication.rst deleted file mode 100644 index 4f09cbe1012..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/authentication.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _vmware_rest_authentication: - -******************************************* -How to configure the vmware_rest collection -******************************************* - -.. contents:: - :local: - - -Introduction -============ - -The vcenter_rest modules need to be authenticated. There are two different - -Environment variables -===================== - -.. note:: - This solution requires that you call the modules from the local machine. - -You need to export some environment variables in your shell before you call the modules. - -.. code-block:: shell - - $ export VMWARE_HOST=vcenter.test - $ export VMWARE_USER=myvcenter-user - $ export VMWARE_password=mypassword - $ ansible-playbook my-playbook.yaml - -Module parameters -================= - -All the vcenter_rest modules accept the following arguments: - -- ``vcenter_hostname`` -- ``vcenter_username`` -- ``vcenter_password`` - - -Ignore SSL certificate error -============================ - -It's common to run a test environment without a proper SSL certificate configuration. - -To ignore the SSL error, you can use the ``vcenter_validate_certs: no`` argument or -``export VMWARE_VALIDATE_CERTS=no`` to set the environment variable. diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/collect_information.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/collect_information.rst deleted file mode 100644 index d6c2b86afd1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/collect_information.rst +++ /dev/null @@ -1,108 +0,0 @@ -.. _vmware_rest_collect_info: - -************************************************* -How to collect information about your environment -************************************************* - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to utilize Ansible to collect information about your environment. -This information is useful for the other tutorials. - -Scenario requirements -===================== - -In this scenario we've got a vCenter with an ESXi host. - -Our environment is pre-initialized with the following elements: - -- A datacenter called ``my_dc`` -- A cluster called ``my_cluster`` -- An ESXi host called ``esxi1`` is in the cluster -- Two datastores on the ESXi: ``rw_datastore`` and ``ro_datastore`` -- A dvswitch based guest network - -Finally, we use the environment variables to authenticate ourselves as explained in :ref:`vmware_rest_authentication`. - -How to collect information -========================== - -In these examples, we use the ``vcenter_*_info`` module to collect information about the associated resources. - -All these modules return a ``value`` key. Depending on the context, this ``value`` key will be either a list or a dictionary. - -Datacenter ----------- - -Here we use the ``vcenter_datacenter_info`` module to list all the datacenters: - -.. literalinclude:: task_outputs/collect_a_list_of_the_datacenters.task.yaml - -Result -______ - -As expected, the ``value`` key of the output is a list. - -.. literalinclude:: task_outputs/collect_a_list_of_the_datacenters.result.json - -Cluster -------- - -Here we do the same with ``vcenter_cluster_info``: - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_clusters.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_clusters.result.json - -And we can also fetch the details about a specific cluster, with the ``cluster`` parameter: - -.. literalinclude:: task_outputs/Retrieve_details_about_the_first_cluster.task.yaml - -Result -______ - -And the ``value`` key of the output is this time a dictionary. - - -.. literalinclude:: task_outputs/Retrieve_details_about_the_first_cluster.result.json - -Datastore ---------- - -Here we use ``vcenter_datastore_info`` to get a list of all the datastores: - -.. literalinclude:: task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Retrieve_a_list_of_all_the_datastores.result.json - -Folder ------- - -And here again, you use the ``vcenter_folder_info`` module to retrieve a list of all the folders. - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders.result.json - -Most of the time, you will just want one type of folder. In this case we can use filters to reduce the amount to collect. Most of the ``_info`` modules come with similar filters. - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/create_vm.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/create_vm.rst deleted file mode 100644 index 0e64bd0310e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/create_vm.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _vmware_rest_create_vm: - -******************************* -How to create a Virtual Machine -******************************* - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to use Ansible to create a virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_collect_info` and you've got the following variables defined: - -- ``my_cluster_info`` -- ``my_datastore`` -- ``my_virtual_machine_folder`` -- ``my_cluster_info`` - -How to create a virtual machine -=============================== - -In this example, we will use the ``vcenter_vm`` module to create a new guest. - -.. literalinclude:: task_outputs/Create_a_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Create_a_VM.result.json - -.. note:: - ``vcenter_vm`` accepts more parameters, however you may prefer to start with a simple VM and use the ``vcenter_vm_hardware`` modules to tune it up afterwards. It's easier this way to identify a potential problematical step. diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/installation.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/installation.rst deleted file mode 100644 index 7516d0fd455..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/installation.rst +++ /dev/null @@ -1,44 +0,0 @@ -.. _vmware_rest_installation: - -***************************************** -How to install the vmware_rest collection -***************************************** - -.. contents:: - :local: - - -Requirements -============ - -The collection depends on: - -- Ansible >=2.9.10 or greater -- Python 3.6 or greater - -aiohttp -======= - -aiohttp_ is the only dependency of the collection. You can install it with ``pip`` if you use a virtualenv to run Ansible. - -.. code-block:: shell - - $ pip install aiohttp - -Or using an RPM. - -.. code-block:: shell - - $ sudo dnf install python3-aiohttp - -.. _aiohttp: https://docs.aiohttp.org/en/stable/ - -Installation -============ - -The best option to install the collection is to use the ``ansible-galaxy`` command: - -.. code-block:: shell - - - $ ansible-galaxy collection install vmware.vmware_rest diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst deleted file mode 100644 index be723866e78..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/run_a_vm.rst +++ /dev/null @@ -1,52 +0,0 @@ -.. _vmware_rest_run_a_vm: - -**************************** -How to run a virtual machine -**************************** - -.. contents:: - :local: - - -Introduction -============ - -This section covers the power management of your virtual machine. - -Power information -================= - -Use ``vcenter_vm_power_info`` to know the power state of the VM. - -.. literalinclude:: task_outputs/Get_guest_power_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_power_information.result.json - - -How to start a virtual machine -============================== - -Use the ``vcenter_vm_power`` module to start your VM: - -.. literalinclude:: task_outputs/Turn_the_power_of_the_VM_on.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Turn_the_power_of_the_VM_on.result.json - -How to wait until my virtual machine is ready -============================================= - -If your virtual machine runs VMware Tools, you can build a loop -around the ``center_vm_tools_info`` module: - -.. literalinclude:: task_outputs/Wait_until_my_VM_is_ready.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Wait_until_my_VM_is_ready.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.result.json deleted file mode 100644 index c4bf5cd0e22..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.result.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "value": { - "start_connected": false, - "backing": { - "auto_detect": true, - "type": "HOST_DEVICE", - "host_device": "" - }, - "allow_guest_control": true, - "label": "Floppy drive 1", - "state": "NOT_CONNECTED" - }, - "id": "8000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.task.yaml deleted file mode 100644 index d6bcbf806a0..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Add_a_floppy_disk_drive.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Add a floppy disk drive - vmware.vmware_rest.vcenter_vm_hardware_floppy: - vm: '{{ test_vm1_info.id }}' - allow_guest_control: true - register: my_floppy_drive \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.result.json deleted file mode 100644 index fbb5a6f15d9..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.result.json +++ /dev/null @@ -1,23 +0,0 @@ -{ - "value": { - "start_connected": false, - "pci_slot_number": 4, - "backing": { - "connection_cookie": 2145337177, - "distributed_switch_uuid": "50 33 88 3a 8c 6e f9 02-7a fd c2 c0 2c cf f2 ac", - "distributed_port": "2", - "type": "DISTRIBUTED_PORTGROUP", - "network": "dvportgroup-1649" - }, - "mac_address": "00:50:56:b3:49:5c", - "mac_type": "ASSIGNED", - "allow_guest_control": false, - "wake_on_lan_enabled": false, - "label": "Network adapter 1", - "state": "NOT_CONNECTED", - "type": "VMXNET3", - "upt_compatibility_enabled": false - }, - "id": "4000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml deleted file mode 100644 index 48c759f1f2e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml +++ /dev/null @@ -1,9 +0,0 @@ -- name: Attach a VM to a dvswitch - vmware.vmware_rest.vcenter_vm_hardware_ethernet: - vm: '{{ test_vm1_info.id }}' - pci_slot_number: 4 - backing: - type: DISTRIBUTED_PORTGROUP - network: "{{ my_portgroup_info.dvs_portgroup_info.dvswitch1[0].key }}" - start_connected: false - register: vm_hardware_ethernet_1 \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json deleted file mode 100644 index ee456cb1fe6..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json +++ /dev/null @@ -1,19 +0,0 @@ -{ - "value": { - "start_connected": true, - "backing": { - "iso_file": "[ro_datastore] fedora.iso", - "type": "ISO_FILE" - }, - "allow_guest_control": false, - "label": "CD/DVD drive 1", - "state": "NOT_CONNECTED", - "type": "SATA", - "sata": { - "bus": 0, - "unit": 2 - } - }, - "id": "16002", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml deleted file mode 100644 index 29d748895b3..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml +++ /dev/null @@ -1,12 +0,0 @@ -- name: Attach an ISO image to a guest VM - vmware.vmware_rest.vcenter_vm_hardware_cdrom: - vm: '{{ test_vm1_info.id }}' - type: SATA - sata: - bus: 0 - unit: 2 - start_connected: true - backing: - iso_file: '[ro_datastore] fedora.iso' - type: ISO_FILE - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.result.json deleted file mode 100644 index 3415fae6f6e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.result.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "value": [ - { - "drs_enabled": false, - "cluster": "domain-c1636", - "name": "my_cluster", - "ha_enabled": false - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.task.yaml deleted file mode 100644 index d819fa2b8f6..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_clusters.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: Build a list of all the clusters - vmware.vmware_rest.vcenter_cluster_info: - register: all_the_clusters \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.result.json deleted file mode 100644 index 516234d4c69..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": [ - { - "folder": "group-d1", - "name": "Datacenters", - "type": "DATACENTER" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.task.yaml deleted file mode 100644 index ea8d5ce5f79..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: Build a list of all the folders - vmware.vmware_rest.vcenter_folder_info: - register: my_folders \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json deleted file mode 100644 index ecf53f73ebb..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": [ - { - "folder": "group-v1631", - "name": "vm", - "type": "VIRTUAL_MACHINE" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml deleted file mode 100644 index d7e47467ede..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Build_a_list_of_all_the_folders_with_the_type_VIRTUAL_MACHINE_and_called_vm.task.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- name: Build a list of all the folders with the type VIRTUAL_MACHINE and called vm - vmware.vmware_rest.vcenter_folder_info: - filter_type: VIRTUAL_MACHINE - filter_names: - - vm - register: my_folders \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml deleted file mode 100644 index 010dd41994b..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Change vm-tools upgrade policy to MANUAL - vmware.vmware_rest.vcenter_vm_tools: - vm: '{{ test_vm1_info.id }}' - upgrade_policy: MANUAL - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml deleted file mode 100644 index c4e3891dce4..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Change vm-tools upgrade policy to UPGRADE_AT_POWER_CYCLE - vmware.vmware_rest.vcenter_vm_tools: - vm: '{{ test_vm1_info.id }}' - upgrade_policy: UPGRADE_AT_POWER_CYCLE - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.result.json deleted file mode 100644 index d0f17cbb719..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.result.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "value": { - "instant_clone_frozen": false, - "cdroms": [], - "memory": { - "size_MiB": 1024, - "hot_add_enabled": true - }, - "disks": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 0 - }, - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 1", - "type": "SCSI", - "capacity": 17179869184 - }, - "key": "2000" - } - ], - "parallel_ports": [], - "sata_adapters": [], - "cpu": { - "hot_remove_enabled": false, - "count": 1, - "hot_add_enabled": false, - "cores_per_socket": 1 - }, - "scsi_adapters": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 7 - }, - "label": "SCSI controller 0", - "sharing": "NONE", - "type": "PVSCSI" - }, - "key": "1000" - } - ], - "power_state": "POWERED_OFF", - "floppies": [], - "identity": { - "name": "test_vm1", - "instance_uuid": "5033c296-6954-64df-faca-d001de53763d", - "bios_uuid": "42330d17-e603-d925-fa4b-18827dbc1409" - }, - "nvme_adapters": [], - "name": "test_vm1", - "nics": [], - "boot": { - "delay": 0, - "retry_delay": 10000, - "enter_setup_mode": false, - "type": "BIOS", - "retry": false - }, - "serial_ports": [], - "boot_devices": [], - "guest_OS": "DEBIAN_8_64", - "hardware": { - "upgrade_policy": "NEVER", - "upgrade_status": "NONE", - "version": "VMX_11" - } - }, - "id": "vm-1650", - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.task.yaml deleted file mode 100644 index ea00f7cba14..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_information_about_a_specific_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Collect information about a specific VM - vmware.vmware_rest.vcenter_vm_info: - vm: '{{ search_result.value[0].vm }}' - register: test_vm1_info \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.result.json deleted file mode 100644 index c2e162c5db2..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.result.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "value": { - "upgrade_policy": "NEVER", - "upgrade_status": "NONE", - "version": "VMX_11" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.task.yaml deleted file mode 100644 index bc9b18bb0e4..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Collect_the_hardware_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Collect the hardware information - vmware.vmware_rest.vcenter_vm_hardware_info: - vm: '{{ search_result.value[0].vm }}' - register: my_vm1_hardware_info \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json deleted file mode 100644 index 62ae281ec05..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": { - "bus": 0, - "pci_slot_number": 34, - "label": "SATA controller 0", - "type": "AHCI" - }, - "id": "15000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml deleted file mode 100644 index 70e564f610e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Create a SATA adapter at PCI slot 34 - vmware.vmware_rest.vcenter_vm_hardware_adapter_sata: - vm: '{{ test_vm1_info.id }}' - pci_slot_number: 34 - register: _sata_adapter_result_1 \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.result.json deleted file mode 100644 index d309d076a04..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.result.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "value": { - "instant_clone_frozen": false, - "cdroms": [], - "memory": { - "size_MiB": 1024, - "hot_add_enabled": true - }, - "disks": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 0 - }, - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 1", - "type": "SCSI", - "capacity": 17179869184 - }, - "key": "2000" - } - ], - "parallel_ports": [], - "sata_adapters": [], - "cpu": { - "hot_remove_enabled": false, - "count": 1, - "hot_add_enabled": false, - "cores_per_socket": 1 - }, - "scsi_adapters": [ - { - "value": { - "scsi": { - "bus": 0, - "unit": 7 - }, - "label": "SCSI controller 0", - "sharing": "NONE", - "type": "PVSCSI" - }, - "key": "1000" - } - ], - "power_state": "POWERED_OFF", - "floppies": [], - "identity": { - "name": "test_vm1", - "instance_uuid": "5033c296-6954-64df-faca-d001de53763d", - "bios_uuid": "42330d17-e603-d925-fa4b-18827dbc1409" - }, - "nvme_adapters": [], - "name": "test_vm1", - "nics": [], - "boot": { - "delay": 0, - "retry_delay": 10000, - "enter_setup_mode": false, - "type": "BIOS", - "retry": false - }, - "serial_ports": [], - "boot_devices": [], - "guest_OS": "DEBIAN_8_64", - "hardware": { - "upgrade_policy": "NEVER", - "upgrade_status": "NONE", - "version": "VMX_11" - } - }, - "id": "vm-1650", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.task.yaml deleted file mode 100644 index 7880b5bae26..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_VM.task.yaml +++ /dev/null @@ -1,14 +0,0 @@ -- name: Create a VM - vmware.vmware_rest.vcenter_vm: - placement: - cluster: "{{ my_cluster_info.id }}" - datastore: "{{ my_datastore.datastore }}" - folder: "{{ my_virtual_machine_folder.folder }}" - resource_pool: "{{ my_cluster_info.value.resource_pool }}" - name: test_vm1 - guest_OS: DEBIAN_8_64 - hardware_version: VMX_11 - memory: - hot_add_enabled: true - size_MiB: 1024 - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.result.json deleted file mode 100644 index 7b4275ca7a1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.result.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "value": { - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1_1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 2", - "type": "SATA", - "sata": { - "bus": 0, - "unit": 0 - }, - "capacity": 320000 - }, - "id": "16000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.task.yaml deleted file mode 100644 index 66e330bea11..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Create_a_new_disk.task.yaml +++ /dev/null @@ -1,7 +0,0 @@ -- name: Create a new disk - vmware.vmware_rest.vcenter_vm_hardware_disk: - vm: '{{ test_vm1_info.id }}' - type: SATA - new_vmdk: - capacity: 320000 - register: my_new_disk \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.result.json deleted file mode 100644 index 8d2169bbb26..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.result.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "value": { - "hot_remove_enabled": false, - "count": 1, - "hot_add_enabled": false, - "cores_per_socket": 1 - }, - "id": null, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.task.yaml deleted file mode 100644 index 0713ea638f3..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Dedicate_one_core_to_the_VM.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Dedicate one core to the VM - vmware.vmware_rest.vcenter_vm_hardware_cpu: - vm: '{{ test_vm1_info.id }}' - count: 1 - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.result.json deleted file mode 100644 index 204ad5f9afb..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.result.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "value": { - "disks": [] - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.task.yaml deleted file mode 100644 index f9a7e759f74..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_VM_storage_policy.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get VM storage policy - vmware.vmware_rest.vcenter_vm_storage_policy_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.result.json deleted file mode 100644 index ad87f76d203..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.result.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "value": [ - { - "value": { - "mappings": [], - "free_space": 774766592, - "capacity": 2515173376 - }, - "key": "/" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.task.yaml deleted file mode 100644 index 836129f36da..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_filesystem_information.task.yaml +++ /dev/null @@ -1,8 +0,0 @@ -- name: Get guest filesystem information - vmware.vmware_rest.vcenter_vm_guest_localfilesystem_info: - vm: '{{ test_vm1_info.id }}' - register: _result - until: - - _result is not failed - retries: 60 - delay: 5 \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.result.json deleted file mode 100644 index 01e8a8fd1c9..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.result.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "value": { - "full_name": { - "args": [], - "default_message": "Red Hat Fedora (64-bit)", - "id": "vmsg.guestos.fedora64Guest.label" - }, - "name": "FEDORA_64", - "ip_address": "192.168.122.242", - "family": "LINUX", - "host_name": "localhost.localdomain" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.task.yaml deleted file mode 100644 index bef332e5c48..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_identity_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest identity information - vmware.vmware_rest.vcenter_vm_guest_identity_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.result.json deleted file mode 100644 index 2c973374afc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.result.json +++ /dev/null @@ -1,23 +0,0 @@ -{ - "value": [ - { - "mac_address": "00:50:56:b3:49:5c", - "ip": { - "ip_addresses": [ - { - "ip_address": "192.168.122.242", - "prefix_length": 24, - "state": "PREFERRED" - }, - { - "ip_address": "fe80::b8d0:511b:897f:65a2", - "prefix_length": 64, - "state": "UNKNOWN" - } - ] - }, - "nic": "4000" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.task.yaml deleted file mode 100644 index d25c6c6b118..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_interfaces_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest network interfaces information - vmware.vmware_rest.vcenter_vm_guest_networking_interfaces_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.result.json deleted file mode 100644 index 68e2033dd73..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.result.json +++ /dev/null @@ -1,31 +0,0 @@ -{ - "value": [ - { - "gateway_address": "192.168.122.1", - "interface_index": 0, - "prefix_length": 0, - "network": "0.0.0.0" - }, - { - "interface_index": 0, - "prefix_length": 24, - "network": "192.168.122.0" - }, - { - "interface_index": 0, - "prefix_length": 64, - "network": "fe80::" - }, - { - "interface_index": 0, - "prefix_length": 128, - "network": "fe80::b8d0:511b:897f:65a2" - }, - { - "interface_index": 0, - "prefix_length": 8, - "network": "ff00::" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.task.yaml deleted file mode 100644 index 8ef1352b9f0..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_network_routes_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest network routes information - vmware.vmware_rest.vcenter_vm_guest_networking_routes_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.result.json deleted file mode 100644 index fe757b647cc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.result.json +++ /dev/null @@ -1,17 +0,0 @@ -{ - "value": { - "dns": { - "ip_addresses": [ - "10.0.2.3" - ], - "search_domains": [ - "localdomain" - ] - }, - "dns_values": { - "domain_name": "localdomain", - "host_name": "localhost.localdomain" - } - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.task.yaml deleted file mode 100644 index 70ae7767c02..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_networking_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest networking information - vmware.vmware_rest.vcenter_vm_guest_networking_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.result.json deleted file mode 100644 index da317782489..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.result.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "value": { - "state": "POWERED_ON" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.task.yaml deleted file mode 100644 index 4064f532c76..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Get_guest_power_information.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Get guest power information - vmware.vmware_rest.vcenter_vm_power_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.task.yaml deleted file mode 100644 index 3710bcc440a..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Increase_the_memory_of_a_VM.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Increase the memory of a VM - vmware.vmware_rest.vcenter_vm_hardware_memory: - vm: '{{ test_vm1_info.id }}' - size_MiB: 1080 - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json deleted file mode 100644 index 3ecaa4bdbcf..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "value": [ - { - "scsi": { - "bus": 0, - "unit": 7 - }, - "label": "SCSI controller 0", - "type": "PVSCSI", - "sharing": "NONE" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml deleted file mode 100644 index e2fc3c0ebdf..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: List the SCSI adapter of a given VM - vmware.vmware_rest.vcenter_vm_hardware_adapter_scsi_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.result.json deleted file mode 100644 index a838aa542fc..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "value": [], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml deleted file mode 100644 index 9dc6f4dec56..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: List the cdrom devices on the guest - vmware.vmware_rest.vcenter_vm_hardware_cdrom_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json deleted file mode 100644 index 3b5e197e5a1..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "value": [ - { - "memory_size_MiB": 1024, - "vm": "vm-1650", - "name": "test_vm1", - "power_state": "POWERED_OFF", - "cpu_count": 1 - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml deleted file mode 100644 index 78a4043167f..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Look up the VM called test_vm1 in the inventory - register: search_result - vmware.vmware_rest.vcenter_vm_info: - filter_names: - - test_vm1 \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json deleted file mode 100644 index aac751af72e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.result.json deleted file mode 100644 index 48c3cf80b78..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.result.json +++ /dev/null @@ -1,26 +0,0 @@ -{ - "value": [ - { - "datastore": "datastore-1644", - "name": "local", - "type": "VMFS", - "free_space": 13523484672, - "capacity": 15032385536 - }, - { - "datastore": "datastore-1645", - "name": "ro_datastore", - "type": "NFS", - "free_space": 24638349312, - "capacity": 26831990784 - }, - { - "datastore": "datastore-1646", - "name": "rw_datastore", - "type": "NFS", - "free_space": 24638349312, - "capacity": 26831990784 - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml deleted file mode 100644 index 838cabce40b..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_a_list_of_all_the_datastores.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: Retrieve a list of all the datastores - vmware.vmware_rest.vcenter_datastore_info: - register: my_datastores \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.result.json deleted file mode 100644 index 7c86727a827..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.result.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "value": { - "name": "my_cluster", - "resource_pool": "resgroup-1637" - }, - "id": "domain-c1636", - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.task.yaml deleted file mode 100644 index ec505aa2005..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_details_about_the_first_cluster.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Retrieve details about the first cluster - vmware.vmware_rest.vcenter_cluster_info: - cluster: "{{ all_the_clusters.value[0].cluster }}" - register: my_cluster_info \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.result.json deleted file mode 100644 index 922250ed0ca..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.result.json +++ /dev/null @@ -1,18 +0,0 @@ -{ - "value": [ - { - "scsi": { - "bus": 0, - "unit": 0 - }, - "backing": { - "vmdk_file": "[local] test_vm1_8/test_vm1.vmdk", - "type": "VMDK_FILE" - }, - "label": "Hard disk 1", - "type": "SCSI", - "capacity": 17179869184 - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml deleted file mode 100644 index eef02509d9e..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Retrieve the disk information from the VM - vmware.vmware_rest.vcenter_vm_hardware_disk_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.result.json deleted file mode 100644 index 88436c13af0..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.result.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "value": { - "size_MiB": 1024, - "hot_add_enabled": true - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml deleted file mode 100644 index 00fa100aad3..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Retrieve the memory information from the VM - vmware.vmware_rest.vcenter_vm_hardware_memory_info: - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json deleted file mode 100644 index 9c0c9c1f407..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": "4000", - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml deleted file mode 100644 index 8f927da5461..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml +++ /dev/null @@ -1,5 +0,0 @@ -- name: Turn the NIC's start_connected flag on - vmware.vmware_rest.vcenter_vm_hardware_ethernet: - nic: '{{ vm_hardware_ethernet_1.id }}' - start_connected: true - vm: '{{ test_vm1_info.id }}' \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.result.json deleted file mode 100644 index a661aa055d3..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.result.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.task.yaml deleted file mode 100644 index 789a585e48d..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Turn_the_power_of_the_VM_on.task.yaml +++ /dev/null @@ -1,4 +0,0 @@ -- name: Turn the power of the VM on - vmware.vmware_rest.vcenter_vm_power: - state: start - vm: '{{ test_vm1_info.id }}' \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.result.json deleted file mode 100644 index e15f41c5fae..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.result.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "id": null, - "changed": true -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.task.yaml deleted file mode 100644 index 46a95a58548..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Upgrade_the_VM_hardware_version.task.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- name: Upgrade the VM hardware version - vmware.vmware_rest.vcenter_vm_hardware: - upgrade_policy: AFTER_CLEAN_SHUTDOWN - upgrade_version: VMX_13 - vm: '{{ test_vm1_info.id }}' - register: _result \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.result.json deleted file mode 100644 index 849bde48318..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.result.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "value": { - "auto_update_supported": false, - "upgrade_policy": "MANUAL", - "install_attempt_count": 0, - "version_status": "UNMANAGED", - "version_number": 10346, - "run_state": "RUNNING", - "version": "10346", - "install_type": "OPEN_VM_TOOLS" - }, - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.task.yaml deleted file mode 100644 index 1ec04f4379f..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/Wait_until_my_VM_is_ready.task.yaml +++ /dev/null @@ -1,9 +0,0 @@ -- name: Wait until my VM is ready - vmware.vmware_rest.vcenter_vm_tools_info: - vm: '{{ test_vm1_info.id }}' - register: vm_tools_info - until: - - vm_tools_info is not failed - - vm_tools_info.value.run_state == "RUNNING" - retries: 60 - delay: 5 \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.result.json b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.result.json deleted file mode 100644 index 1225ad7f93a..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.result.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "value": [ - { - "name": "my_dc", - "datacenter": "datacenter-1630" - } - ], - "changed": false -} \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.task.yaml b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.task.yaml deleted file mode 100644 index f274a974a25..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/task_outputs/collect_a_list_of_the_datacenters.task.yaml +++ /dev/null @@ -1,3 +0,0 @@ -- name: collect a list of the datacenters - vmware.vmware_rest.vcenter_datacenter_info: - register: my_datacenters \ No newline at end of file diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst deleted file mode 100644 index 1af1d5b5af5..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_hardware_tuning.rst +++ /dev/null @@ -1,150 +0,0 @@ -.. _vmware_rest_vm_hardware_tuning: - -******************************* -How to modify a virtual machine -******************************* - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to use Ansible to modify an existing virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_create_vm` and created a VM. - -How to add a CDROM drive to a virtual machine -============================================= - -In this example, we use the ``vcenter_vm_hardware_*`` modules to add a new CDROM to an existing VM. - -Add a new SATA adapter -______________________ - -First we create a new SATA adapter. We specify the ``pci_slot_number``. This way if we run the task again it won't do anything if there is already an adapter there. - -.. literalinclude:: task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Create_a_SATA_adapter_at_PCI_slot_34.result.json - -Add a CDROM drive -_________________ - -Now we can create the CDROM drive: - -.. literalinclude:: task_outputs/Attach_an_ISO_image_to_a_guest_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Attach_an_ISO_image_to_a_guest_VM.result.json - - -.. _vmware_rest_attach_a_network: - -How to attach a VM to a network -=============================== - -Attach a new NIC -________________ - -Here we attach the VM to the network (through the portgroup). We specify a ``pci_slot_number`` for the same reason. - -The second task adjusts the NIC configuration. - -.. literalinclude:: task_outputs/Attach_a_VM_to_a_dvswitch.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Attach_a_VM_to_a_dvswitch.result.json - -Adjust the configuration of the NIC -___________________________________ - -.. literalinclude:: task_outputs/Turn_the_NIC's_start_connected_flag_on.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Turn_the_NIC's_start_connected_flag_on.result.json - -Increase the memory of the VM -============================= - -We can also adjust the amount of memory that we dedicate to our VM. - -.. literalinclude:: task_outputs/Increase_the_memory_of_a_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Increase_the_memory_of_a_VM.result.json - -Upgrade the hardware version of the VM -====================================== - -Here we use the ``vcenter_vm_hardware`` module to upgrade the version of the hardware: - -.. literalinclude:: task_outputs/Upgrade_the_VM_hardware_version.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Upgrade_the_VM_hardware_version.result.json - -Adjust the number of CPUs of the VM -=================================== - -You can use ``vcenter_vm_hardware_cpu`` for that: - -.. literalinclude:: task_outputs/Dedicate_one_core_to_the_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Dedicate_one_core_to_the_VM.result.json - -Remove a SATA controller -======================== - -In this example, we remove the SATA controller of the PCI slot 34. - -.. literalinclude:: task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json - -Result -______ - -.. literalinclude:: task_outputs/Remove_SATA_adapter_at_PCI_slot_34.result.json - -Attach a floppy drive -===================== - -Here we attach a floppy drive to a VM. - -.. literalinclude:: task_outputs/Add_a_floppy_disk_drive.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Add_a_floppy_disk_drive.result.json - -Attach a new disk -================= - -Here we attach a tiny disk to the VM. The ``capacity`` is in bytes. - -.. literalinclude:: task_outputs/Create_a_new_disk.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Create_a_new_disk.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_info.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_info.rst deleted file mode 100644 index 097b69b1a13..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_info.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. _vmware_rest_vm_info: - -*************************************** -Retrieve information from a specific VM -*************************************** - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to use Ansible to retrieve information about a specific virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_create_vm` and you've got create a new VM called ``test_vm1``. - -How to collect virtual machine information -========================================== - -List the VM -___________ - -In this example, we use the ``vcenter_vm_info`` module to collect information about our new VM. - -In this example, we start by asking for a list of VMs. We use a filter to limit the results to just the VM called ``test_vm1``. So we are in a list context, with one single entry in the ``value`` key. - -.. literalinclude:: task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.task.yaml - -Result -______ - -As expected, we get a list. And thanks to our filter, we just get one entry. - -.. literalinclude:: task_outputs/Look_up_the_VM_called_test_vm1_in_the_inventory.result.json - -Collect the details about a specific VM -_______________________________________ - -For the next steps, we pass the ID of the VM through the ``vm`` parameter. This allow us to collect more details about this specific VM. - -.. literalinclude:: task_outputs/Collect_information_about_a_specific_VM.task.yaml - -Result -______ - -The result is a structure with all the details about our VM. You will note this is actually the same information that we get when we created the VM. - -.. literalinclude:: task_outputs/Collect_information_about_a_specific_VM.result.json - - -Get the hardware version of a specific VM -_________________________________________ - -We can also use all the ``vcenter_vm_*_info`` modules to retrieve a smaller amount -of information. Here we use ``vcenter_vm_hardware_info`` to know the hardware version of -the VM. - -.. literalinclude:: task_outputs/Collect_the_hardware_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Collect_the_hardware_information.result.json - -List the SCSI adapter(s) of a specific VM -_________________________________________ - -Here for instance, we list the SCSI adapter(s) of the VM: - -.. literalinclude:: task_outputs/List_the_SCSI_adapter_of_a_given_VM.task.yaml - -You can do the same for the SATA controllers with ``vcenter_vm_adapter_sata_info``. - -Result -______ - -.. literalinclude:: task_outputs/List_the_SCSI_adapter_of_a_given_VM.result.json - -List the CDROM drive(s) of a specific VM -________________________________________ - -And we list its CDROM drives. - -.. literalinclude:: task_outputs/List_the_cdrom_devices_on_the_guest.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/List_the_cdrom_devices_on_the_guest.result.json - -Get the memory information of the VM -____________________________________ - -Here we collect the memory information of the VM: - -.. literalinclude:: task_outputs/Retrieve_the_memory_information_from_the_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Retrieve_the_memory_information_from_the_VM.result.json - -Get the storage policy of the VM --------------------------------- - -We use the ``vcenter_vm_storage_policy_info`` module for that: - -.. literalinclude:: task_outputs/Get_VM_storage_policy.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_VM_storage_policy.result.json - -Get the disk information of the VM ----------------------------------- - -We use the ``vcenter_vm_hardware_disk_info`` for this operation: - -.. literalinclude:: task_outputs/Retrieve_the_disk_information_from_the_VM.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Retrieve_the_disk_information_from_the_VM.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst deleted file mode 100644 index b29447aec52..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_configuration.rst +++ /dev/null @@ -1,45 +0,0 @@ -.. _vmware_rest_vm_tool_configuration: - -************************************************************** -How to configure the VMware tools of a running virtual machine -************************************************************** - -.. contents:: - :local: - - -Introduction -============ - -This section show you how to collection information from a running virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_run_a_vm` and your virtual machine runs VMware Tools. - -How to change the upgrade policy -================================ - -Change the upgrade policy to MANUAL ---------------------------------------------------- - -You can adjust the VMware Tools upgrade policy with the ``vcenter_vm_tools`` module. - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_MANUAL.result.json - - -Change the upgrade policy to UPGRADE_AT_POWER_CYCLE ------------------------------------------------------------------------------------------- - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Change_vm-tools_upgrade_policy_to_UPGRADE_AT_POWER_CYCLE.result.json diff --git a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst b/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst deleted file mode 100644 index 2f92871db37..00000000000 --- a/docs/docsite/rst/scenario_guides/vmware_rest_scenarios/vm_tool_information.rst +++ /dev/null @@ -1,90 +0,0 @@ -.. _vmware_rest_vm_tool_information: - -***************************************************** -How to get information from a running virtual machine -***************************************************** - -.. contents:: - :local: - - -Introduction -============ - -This section shows you how to collection information from a running virtual machine. - -Scenario requirements -===================== - -You've already followed :ref:`vmware_rest_run_a_vm` and your virtual machine runs VMware Tools. - -How to collect information -========================== - -In this example, we use the ``vcenter_vm_guest_*`` module to collect information about the associated resources. - -Filesystem ----------- - -Here we use ``vcenter_vm_guest_localfilesystem_info`` to retrieve the details -about the filesystem of the guest. In this example we also use a ``retries`` -loop. The VMware Tools may take a bit of time to start and by doing so, we give -the VM a bit more time. - -.. literalinclude:: task_outputs/Get_guest_filesystem_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_filesystem_information.result.json - -Guest identity --------------- - -You can use ``vcenter_vm_guest_identity_info`` to get details like the OS family or the hostname of the running VM. - -.. literalinclude:: task_outputs/Get_guest_identity_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_identity_information.result.json - -Network -------- - -``vcenter_vm_guest_networking_info`` will return the OS network configuration. - -.. literalinclude:: task_outputs/Get_guest_networking_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_networking_information.result.json - -Network interfaces ------------------- - -``vcenter_vm_guest_networking_interfaces_info`` will return a list of NIC configurations. - -See also :ref:`vmware_rest_attach_a_network`. - -.. literalinclude:: task_outputs/Get_guest_network_interfaces_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_network_interfaces_information.result.json - -Network routes --------------- - -Use ``vcenter_vm_guest_networking_routes_info`` to explore the route table of your virtual machine. - -.. literalinclude:: task_outputs/Get_guest_network_routes_information.task.yaml - -Result -______ - -.. literalinclude:: task_outputs/Get_guest_network_routes_information.result.json - diff --git a/docs/docsite/rst/shared_snippets/basic_concepts.txt b/docs/docsite/rst/shared_snippets/basic_concepts.txt deleted file mode 100644 index f2648cbf6a9..00000000000 --- a/docs/docsite/rst/shared_snippets/basic_concepts.txt +++ /dev/null @@ -1,69 +0,0 @@ -Control node -============ -The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others). -You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible. -Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features. - - -Managed nodes -============= -Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible. -Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup. - - -Inventory -========= -A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address. -It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment. -To learn more about inventory, see :ref:`the Working with Inventory` section. Sometimes an inventory source file is also referred to as a 'hostfile'. - - -Playbooks -========= -They contain Plays (which are the basic unit of Ansible execution). This is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates. -Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`. - -Plays ------ -The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks. -The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly. -It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them. - -Roles -..... -A limited distribution of reusable Ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play. -To use any Role resource, the Role itself must be imported into the Play. - -Tasks -..... -The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file). -You can execute a single task once with an ad hoc command using ``ansible`` or ``ansible-console`` (both create a virtual Play). - -Handlers -........ -A special form of a Task, that only executes when notified by a previous task which resulted in a 'changed' status. - - -Modules -======= -The code or binaries that Ansible copies to and executes on each managed node (when needed) to accomplish the action defined in each Task. -Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. -You can invoke a single module with a task, or invoke several different modules in a playbook. -Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`. - - -Plugins -======= -Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins), -manipulate data (filter plugins) and even control what is displayed in the console (callback plugins). -See :ref:`working_with_plugins` for details. - - -Collections -=========== -A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy `_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other. - - -AAP -=== -Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on. diff --git a/docs/docsite/rst/shared_snippets/download_tarball_collections.txt b/docs/docsite/rst/shared_snippets/download_tarball_collections.txt deleted file mode 100644 index 045004be271..00000000000 --- a/docs/docsite/rst/shared_snippets/download_tarball_collections.txt +++ /dev/null @@ -1,8 +0,0 @@ - - -To download the collection tarball from Galaxy for offline use: - -#. Navigate to the collection page. -#. Click on :guilabel:`Download tarball`. - -You may also need to manually download any dependent collections. diff --git a/docs/docsite/rst/shared_snippets/galaxy_server_list.txt b/docs/docsite/rst/shared_snippets/galaxy_server_list.txt deleted file mode 100644 index 9991d85899a..00000000000 --- a/docs/docsite/rst/shared_snippets/galaxy_server_list.txt +++ /dev/null @@ -1,78 +0,0 @@ - - -By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). - -You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as a custom Galaxy server): - -* Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`. -* Use the ``--server`` command line argument to limit to an individual server. - -To configure a Galaxy server list in ``ansible.cfg``: - - -#. Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names. -#. Create a new section for each server name. -#. Set the ``url`` option for each server name. -#. Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`. - -.. note:: - The ``url`` option for each server name must end with a forward slash ``/``. If you do not set the API token in your Galaxy server list, use the ``--api-key`` argument to pass in the token to the ``ansible-galaxy collection publish`` command. - - -The following example shows how to configure multiple servers: - -.. code-block:: ini - - [galaxy] - server_list = my_org_hub, release_galaxy, test_galaxy, my_galaxy_ng - - [galaxy_server.my_org_hub] - url=https://automation.my_org/ - username=my_user - password=my_pass - - [galaxy_server.release_galaxy] - url=https://galaxy.ansible.com/ - token=my_token - - [galaxy_server.test_galaxy] - url=https://galaxy-dev.ansible.com/ - token=my_test_token - - [galaxy_server.my_galaxy_ng] - url=http://my_galaxy_ng:8000/api/automation-hub/ - auth_url=http://my_keycloak:8080/auth/realms/myco/protocol/openid-connect/token - client_id=galaxy-ng - token=my_keycloak_access_token - -.. note:: - You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and - the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the - ``--server`` argument. - -**Galaxy server list configuration options** - -The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a -collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and -finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section -``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then -define the following keys: - -* ``url``: The URL of the Galaxy instance to connect to. Required. -* ``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``. -* ``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``. -* ``password``: The password to use, in conjunction with ``username``, for basic authentication. -* ``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, galaxyNG). Mutually exclusive with ``username``. Requires ``token``. -* ``validate_certs``: Whether or not to verify TLS certificates for the Galaxy server. This defaults to True unless the ``--ignore-certs`` option is provided or ``GALAXY_IGNORE_CERTS`` is configured to True. -* ``client_id``: The Keycloak token's client_id to use for authentication. Requires ``auth_url`` and ``token``. The default ``client_id`` is cloud-services to work with Red Hat SSO. - -As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. -The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper -case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for -``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``. - -For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the -``server_list``, unless you pass in an explicit server with the ``--server`` argument. - -.. note:: - ``ansible-galaxy`` can seek out dependencies on other configured Galaxy instances to support the use case where a collection can depend on a collection from another Galaxy instance. diff --git a/docs/docsite/rst/shared_snippets/installing_collections.txt b/docs/docsite/rst/shared_snippets/installing_collections.txt deleted file mode 100644 index 23f5c3e78cc..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_collections.txt +++ /dev/null @@ -1,72 +0,0 @@ - - -By default, ``ansible-galaxy collection install`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the -:file:`ansible.cfg` file under :ref:`galaxy_server`). You do not need any -further configuration. - -See :ref:`Configuring the ansible-galaxy client ` if you are using any other Galaxy server, such as Red Hat Automation Hub. - -To install a collection hosted in Galaxy: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection - -To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection --upgrade - -You can also directly use the tarball from your build: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections - -You can build and install a collection from a local source directory. The ``ansible-galaxy`` utility builds the collection using the ``MANIFEST.json`` or ``galaxy.yml`` -metadata in the directory. - -.. code-block:: bash - - ansible-galaxy collection install /path/to/collection -p ./collections - -You can also install multiple collections in a namespace directory. - -.. code-block:: text - - ns/ - ├── collection1/ - │   ├── MANIFEST.json - │   └── plugins/ - └── collection2/ - ├── galaxy.yml - └── plugins/ - -.. code-block:: bash - - ansible-galaxy collection install /path/to/ns -p ./collections - -.. note:: - The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the - parent directory is already in a folder called ``ansible_collections``. - - -When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is -where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs -the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections`` - -You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure. - -.. code-block:: text - - ./ - ├── play.yml - ├── collections/ - │ └── ansible_collections/ - │ └── my_namespace/ - │ └── my_collection/ - - -See :ref:`collection_structure` for details on the collection directory structure. - diff --git a/docs/docsite/rst/shared_snippets/installing_collections_file.rst b/docs/docsite/rst/shared_snippets/installing_collections_file.rst deleted file mode 100644 index 7c4fbcd9cb4..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_collections_file.rst +++ /dev/null @@ -1,24 +0,0 @@ -Ansible can also install from a source directory in several ways: - -.. code-block:: yaml - - collections: - # directory containing the collection - - source: ./my_namespace/my_collection/ - type: dir - - # directory containing a namespace, with collections as subdirectories - - source: ./my_namespace/ - type: subdirs - -Ansible can also install a collection collected with ``ansible-galaxy collection build`` or downloaded from Galaxy for offline use by specifying the output file directly: - -.. code-block:: yaml - - collections: - - name: /tmp/my_namespace-my_collection-1.0.0.tar.gz - type: file - -.. note:: - - Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file. diff --git a/docs/docsite/rst/shared_snippets/installing_collections_git_repo.txt b/docs/docsite/rst/shared_snippets/installing_collections_git_repo.txt deleted file mode 100644 index ba11d25d3e2..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_collections_git_repo.txt +++ /dev/null @@ -1,105 +0,0 @@ -You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet. - -The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection. - -Installing a collection from a git repository at the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). You can specify a branch, commit, or tag using the comma-separated `git commit-ish `_ syntax. - -For example: - -.. code-block:: bash - - # Install a collection in a repository using the latest commit on the branch 'devel' - ansible-galaxy collection install git+https://github.com/organization/repo_name.git,devel - - # Install a collection from a private github repository - ansible-galaxy collection install git@github.com:organization/repo_name.git - - # Install a collection from a local git repository - ansible-galaxy collection install git+file:///home/user/path/to/repo_name.git - -.. warning:: - - Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere. - - * Use `SSH `_ authentication - * Use `netrc `_ authentication - * Use `http.extraHeader `_ in your git configuration - * Use `url..pushInsteadOf `_ in your git configuration - -Specifying the collection location within the git repository -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files: - -* The top level of the repository. -* Each directory in the repository path (one level deep). - -If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection. - -.. code-block:: text - - ├── galaxy.yml - ├── plugins/ - │   ├── lookup/ - │   ├── modules/ - │   └── module_utils/ - └─── README.md - -If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default: - -.. code-block:: text - - ├── collection1 - │   ├── docs/ - │   ├── galaxy.yml - │   └── plugins/ - │    ├── inventory/ - │   └── modules/ - └── collection2 -    ├── docs/ -    ├── galaxy.yml -    ├── plugins/ -   |   ├── filter/ -    | └── modules/ -    └── roles/ - -If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections: - -.. code-block:: text - - ansible-galaxy collection install git+https://github.com/organization/repo_name.git#/collection2/ - -In some repositories, the main directory corresponds to the namespace: - -.. code-block:: text - - namespace/ - ├── collectionA/ - | ├── docs/ - | ├── galaxy.yml - | ├── plugins/ - | │   ├── README.md - | │   └── modules/ - | ├── README.md - | └── roles/ - └── collectionB/ - ├── docs/ - ├── galaxy.yml - ├── plugins/ - │   ├── connection/ - │   └── modules/ - ├── README.md - └── roles/ - -You can install all collections in this repository, or install one collection from a specific commit: - -.. code-block:: bash - - # Install all collections in the namespace - ansible-galaxy collection install git+https://github.com/organization/repo_name.git#/namespace/ - - # Install an individual collection using a specific commit - ansible-galaxy collection install git+https://github.com/organization/repo_name.git#/namespace/collectionA/,7b60ddc245bc416b72d8ea6ed7b799885110f5e5 diff --git a/docs/docsite/rst/shared_snippets/installing_multiple_collections.txt b/docs/docsite/rst/shared_snippets/installing_multiple_collections.txt deleted file mode 100644 index a1b18b59373..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_multiple_collections.txt +++ /dev/null @@ -1,77 +0,0 @@ - -You can set up a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format: - -.. code-block:: yaml+jinja - - --- - collections: - # With just the collection name - - my_namespace.my_collection - - # With the collection name, version, and source options - - name: my_namespace.my_other_collection - version: ">=1.2.0" # Version range identifiers (default: ``*``) - source: ... # The Galaxy URL to pull the collection from (default: ``--api-server`` from cmdline) - -You can specify the following keys for each collection entry: - - * ``name`` - * ``version`` - * ``signatures`` - * ``source`` - * ``type`` - -The ``version`` key uses the same range identifier format documented in :ref:`collections_older_version`. - -The ``signatures`` key accepts a list of signature sources that are used to supplement those found on the Galaxy server during collection installation and ``ansible-galaxy collection verify``. Signature sources should be URIs that contain the detached signature. The ``--keyring`` CLI option must be provided if signatures are specified. - -Signatures are only used to verify collections on Galaxy servers. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files. - -.. code-block:: yaml - - collections: - - name: namespace.name - version: 1.0.0 - type: galaxy - signatures: - - https://examplehost.com/detached_signature.asc - - file:///path/to/local/detached_signature.asc - -The ``type`` key can be set to ``file``, ``galaxy``, ``git``, ``url``, ``dir``, or ``subdirs``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection. - -When you install a collection with ``type: git``, the ``version`` key can refer to a branch or to a `git commit-ish `_ object (commit or tag). For example: - -.. code-block:: yaml - - collections: - - name: https://github.com/organization/repo_name.git - type: git - version: devel - -You can also add roles to a ``requirements.yml`` file, under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases. - -.. code-block:: yaml - - --- - roles: - # Install a role from Ansible Galaxy. - - name: geerlingguy.java - version: "1.9.6" # note that ranges are not supported for roles - - - collections: - # Install a collection from Ansible Galaxy. - - name: geerlingguy.php_roles - version: ">=0.9.3" - source: https://galaxy.ansible.com - -To install both roles and collections at the same time with one command, run the following: - -.. code-block:: bash - - $ ansible-galaxy install -r requirements.yml - -Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively. - -.. note:: - Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would. diff --git a/docs/docsite/rst/shared_snippets/installing_older_collection.txt b/docs/docsite/rst/shared_snippets/installing_older_collection.txt deleted file mode 100644 index 511dd2a7375..00000000000 --- a/docs/docsite/rst/shared_snippets/installing_older_collection.txt +++ /dev/null @@ -1,25 +0,0 @@ - -You can only have one version of a collection installed at a time. By default ``ansible-galaxy`` installs the latest available version. If you want to install a specific version, you can add a version range identifier. For example, to install the 1.0.0-beta.1 version of the collection: - -.. code-block:: bash - - ansible-galaxy collection install my_namespace.my_collection:==1.0.0-beta.1 - -You can specify multiple range identifiers separated by ``,``. Use single quotes so the shell passes the entire command, including ``>``, ``!``, and other operators, along. For example, to install the most recent version that is greater than or equal to 1.0.0 and less than 2.0.0: - -.. code-block:: bash - - ansible-galaxy collection install 'my_namespace.my_collection:>=1.0.0,<2.0.0' - -Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers: - -* ``*``: The most recent version. This is the default. -* ``!=``: Not equal to the version specified. -* ``==``: Exactly the version specified. -* ``>=``: Greater than or equal to the version specified. -* ``>``: Greater than the version specified. -* ``<=``: Less than or equal to the version specified. -* ``<``: Less than the version specified. - -.. note:: - By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly. diff --git a/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst b/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst deleted file mode 100644 index fa398fce339..00000000000 --- a/docs/docsite/rst/tips_tricks/ansible_tips_tricks.rst +++ /dev/null @@ -1,187 +0,0 @@ -.. _tips_and_tricks: - -General tips -============ - -These concepts apply to all Ansible activities and artifacts. - -Keep it simple --------------- - -Whenever you can, do things simply. Use advanced features only when necessary, and select the feature that best matches your use case. -For example, you will probably not need ``vars``, ``vars_files``, ``vars_prompt`` and ``--extra-vars`` all at once, while also using an external inventory file. -If something feels complicated, it probably is. Take the time to look for a simpler solution. - -Use version control -------------------- - -Keep your playbooks, roles, inventory, and variables files in git or another version control system and make commits to the repository when you make changes. -Version control gives you an audit trail describing when and why you changed the rules that automate your infrastructure. - -Customize the CLI output -------------------------- - -You can change the output from Ansible CLI commands using :ref:`callback_plugins`. - -.. _playbook_tips: - -Playbook tips -============= - -These tips help make playbooks and roles easier to read, maintain, and debug. - -Use whitespace --------------- - -Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan. - -Always name tasks ------------------ - -Task names are optional, but extremely useful. In its output, Ansible shows you the name of each task it runs. -Choose names that describe what each task does and why. - -Always mention the state ------------------------- - -For many modules, the 'state' parameter is optional. -Different modules have different default settings for 'state', and some modules support several 'state' settings. -Explicitly setting 'state=present' or 'state=absent' makes playbooks and roles clearer. - -Use comments ------------- - -Even with task names and explicit state, sometimes a part of a playbook or role (or inventory/variable file) needs more explanation. -Adding a comment (any line starting with '#') helps others (and possibly yourself in future) understand what a play or task (or variable setting) does, how it does it, and why. - -.. _inventory_tips: - -Inventory tips -============== - -These tips help keep your inventory well organized. - -Use dynamic inventory with clouds ---------------------------------- - -With cloud providers and other systems that maintain canonical lists of your infrastructure, use :ref:`dynamic inventory ` to retrieve those lists instead of manually updating static inventory files. -With cloud resources, you can use tags to differentiate production and staging environments. - -Group inventory by function ---------------------------- - -A system can be in multiple groups. See :ref:`intro_inventory` and :ref:`intro_patterns`. -If you create groups named for the function of the nodes in the group, for example *webservers* or *dbservers*, your playbooks can target machines based on function. -You can assign function-specific variables using the group variable system, and design Ansible roles to handle function-specific use cases. -See :ref:`playbooks_reuse_roles`. - -Separate production and staging inventory ------------------------------------------ - -You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. -This way you pick with -i what you are targeting. -Keeping all your environments in one file can lead to surprises! -For example, all vault passwords used in an inventory need to be available when using that inventory. -If an inventory contains both production and development environments, developers using that inventory would be able to access production secrets. - -.. _tip_for_variables_and_vaults: - -Keep vaulted variables safely visible -------------------------------------- - -You should encrypt sensitive or secret variables with Ansible Vault. -However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. -To circumvent this, you can encrypt the variables individually using ``ansible-vault encrypt_string``, or add the following layer of indirection to keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets: - -#. Create a ``group_vars/`` subdirectory named after the group. -#. Inside this subdirectory, create two files named ``vars`` and ``vault``. -#. In the ``vars`` file, define all of the variables needed, including any sensitive ones. -#. Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``. -#. Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: {{ vault_db_password }}``. -#. Encrypt the ``vault`` file to protect its contents. -#. Use the variable name from the ``vars`` file in your playbooks. - -When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. -There is no limit to the number of variable and vault files or their names. - -Note that using this strategy in your inventory still requires *all vault passwords to be available* (for example for ``ansible-playbook`` or `AWX/Ansible Tower `_) when run with that inventory. - -.. _execution_tips: - -Execution tricks -================ - -These tips apply to using Ansible, rather than to Ansible artifacts. - -Try it in staging first ------------------------ - -Testing changes in a staging environment before rolling them out in production is always a great idea. -Your environments need not be the same size and you can use group variables to control the differences between those environments. - -Update in batches ------------------ - -Use the 'serial' keyword to control how many machines you update at once in the batch. -See :ref:`playbooks_delegation`. - -.. _os_variance: - -Handling OS and distro differences ----------------------------------- - -Group variables files and the ``group_by`` module work together to help Ansible execute across a range of operating systems and distributions that require different settings, packages, and tools. -The ``group_by`` module creates a dynamic group of hosts that match certain criteria. -This group does not need to be defined in the inventory file. -This approach lets you execute different tasks on different operating systems or distributions. - -For example, the following play categorizes all systems into dynamic groups based on the operating system name: - -.. literalinclude:: yaml/tip_group_by.yaml - :language: yaml - -Subsequent plays can use these groups as patterns on the ``hosts`` line as follows: - -.. literalinclude:: yaml/tip_group_hosts.yaml - :language: yaml - -You can also add group-specific settings in group vars files. -In the following example, CentOS machines get the value of '42' for `asdf` but other machines get '10'. -You can also use group vars files to apply roles to systems as well as set variables. - -.. code-block:: yaml - - --- - # file: group_vars/all - asdf: 10 - - --- - # file: group_vars/os_CentOS.yml - asdf: 42 - -.. note:: - All three names must match: the name created by the ``group_by`` task, the name of the pattern in subsequent plays, and the name of the group vars file. - -You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks: - -.. literalinclude:: yaml/tip_include_vars.yaml - :language: yaml - -This pulls in variables from the `group_vars/os_CentOS.yml` file. - -.. seealso:: - - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic playbook features - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn how to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete playbook files from the github project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/tips_tricks/index.rst b/docs/docsite/rst/tips_tricks/index.rst deleted file mode 100644 index 36d83252699..00000000000 --- a/docs/docsite/rst/tips_tricks/index.rst +++ /dev/null @@ -1,23 +0,0 @@ -.. _tips_tricks_index: -.. _playbooks_best_practices: - -####################### -Ansible tips and tricks -####################### - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible tips and tricks guide. -These tips and tricks have helped us optimize our Ansible usage and we offer them here as suggestions. -We hope they will help you organize content, write playbooks, maintain inventory, and execute Ansible. -Ultimately, though, you should use Ansible in the way that makes most sense for your organization and your goals. - -.. toctree:: - :maxdepth: 2 - - ansible_tips_tricks - sample_setup \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/sample_setup.rst b/docs/docsite/rst/tips_tricks/sample_setup.rst deleted file mode 100644 index fc8c477169b..00000000000 --- a/docs/docsite/rst/tips_tricks/sample_setup.rst +++ /dev/null @@ -1,295 +0,0 @@ -.. _sample_setup: - -******************** -Sample Ansible setup -******************** - -You have learned about playbooks, inventory, roles, and variables. This section combines all those elements, and outlines a sample setup for automating a web service. You can find more example playbooks that illustrate these patterns in our `ansible-examples repository `_. (NOTE: These examples do not use all of the latest features, but are still an excellent reference.). - -The sample setup organizes playbooks, roles, inventory, and files with variables by function. Tags at the play and task level provide greater granularity and control. This is a powerful and flexible approach, but there are other ways to organize Ansible content. Your usage of Ansible should fit your needs, so feel free to modify this approach and organize your content accordingly. - -.. contents:: - :local: - -Sample directory layout ------------------------ - -This layout organizes most tasks in roles, with a single inventory file for each environment and a few playbooks in the top-level directory: - -.. code-block:: console - - production # inventory file for production servers - staging # inventory file for staging environment - - group_vars/ - group1.yml # here we assign variables to particular groups - group2.yml - host_vars/ - hostname1.yml # here we assign variables to particular systems - hostname2.yml - - library/ # if any custom modules, put them here (optional) - module_utils/ # if any custom module_utils to support modules, put them here (optional) - filter_plugins/ # if any custom filter plugins, put them here (optional) - - site.yml # main playbook - webservers.yml # playbook for webserver tier - dbservers.yml # playbook for dbserver tier - tasks/ # task files included from playbooks - webservers-extra.yml # <-- avoids confusing playbook with task files -.. include:: shared_snippets/role_directory.txt - -.. note:: By default, Ansible assumes your playbooks are stored in one directory with roles stored in a sub-directory called ``roles/``. With more tasks to automate, you can consider moving your playbooks into a sub-directory called ``playbooks/``. If you do this, you must configure the path to your ``roles/`` directory using the ``roles_path`` setting in the ``ansible.cfg`` file. - -Alternative directory layout ----------------------------- - -You can also put each inventory file with its ``group_vars``/``host_vars`` in a separate directory. This is particularly useful if your ``group_vars``/``host_vars`` do not have that much in common in different environments. The layout could look like this example: - - .. code-block:: console - - inventories/ - production/ - hosts # inventory file for production servers - group_vars/ - group1.yml # here we assign variables to particular groups - group2.yml - host_vars/ - hostname1.yml # here we assign variables to particular systems - hostname2.yml - - staging/ - hosts # inventory file for staging environment - group_vars/ - group1.yml # here we assign variables to particular groups - group2.yml - host_vars/ - stagehost1.yml # here we assign variables to particular systems - stagehost2.yml - - library/ - module_utils/ - filter_plugins/ - - site.yml - webservers.yml - dbservers.yml - - roles/ - common/ - webtier/ - monitoring/ - fooapp/ - -This layout gives you more flexibility for larger environments, as well as a total separation of inventory variables between different environments. However, this approach is harder to maintain, because there are more files. For more information on organizing group and host variables, see :ref:`splitting_out_vars`. - -.. _groups_and_hosts: - -Sample group and host variables -------------------------------- - -These sample group and host files with variables contain the values that apply to each machine or a group of machines. For instance, the data center in Atlanta has its own NTP servers. As a result, when setting up the ``ntp.conf`` file, you could use similar code as in this example: - - .. code-block:: yaml - - --- - # file: group_vars/atlanta - ntp: ntp-atlanta.example.com - backup: backup-atlanta.example.com - -Similarly, hosts in the webservers group have some configuration that does not apply to the database servers: - - .. code-block:: yaml - - --- - # file: group_vars/webservers - apacheMaxRequestsPerChild: 3000 - apacheMaxClients: 900 - -Default values, or values that are universally true, belong in a file called ``group_vars/all``: - - .. code-block:: yaml - - --- - # file: group_vars/all - ntp: ntp-boston.example.com - backup: backup-boston.example.com - -If necessary, you can define specific hardware variance in systems in the ``host_vars`` directory: - - .. code-block:: yaml - - --- - # file: host_vars/db-bos-1.example.com - foo_agent_port: 86 - bar_agent_port: 99 - -If you use :ref:`dynamic inventory `, Ansible creates many dynamic groups automatically. As a result, a tag like ``class:webserver`` will load in variables from the file ``group_vars/ec2_tag_class_webserver`` automatically. - -.. note:: You can access host variables with a special variable called ``hostvars``. See :ref:`special_variables` for a list of these variables. The ``hostvars`` variable can access only host-specific variables, not group variables. - - -.. _split_by_role: - -Sample playbooks organized by function --------------------------------------- - -With this setup, a single playbook can define the entire infrastructure. The ``site.yml`` playbook imports two other playbooks. One for the webservers and one for the database servers: - - .. code-block:: yaml - - --- - # file: site.yml - - import_playbook: webservers.yml - - import_playbook: dbservers.yml - -The ``webservers.yml`` playbook, also at the top level, maps the configuration of the webservers group to the roles related to the webservers group: - - .. code-block:: yaml - - --- - # file: webservers.yml - - hosts: webservers - roles: - - common - - webtier - -With this setup, you can configure your entire infrastructure by running ``site.yml``. Alternatively, to configure just a portion of your infrastructure, run ``webservers.yml``. This is similar to the Ansible ``--limit`` parameter but a little more explicit: - - .. code-block:: shell - - ansible-playbook site.yml --limit webservers - ansible-playbook webservers.yml - -.. _role_organization: - -Sample task and handler files in a function-based role ------------------------------------------------------- - -Ansible loads any file called ``main.yml`` in a role sub-directory. This sample ``tasks/main.yml`` file configures NTP: - - .. code-block:: yaml - - --- - # file: roles/common/tasks/main.yml - - - name: be sure ntp is installed - yum: - name: ntp - state: present - tags: ntp - - - name: be sure ntp is configured - template: - src: ntp.conf.j2 - dest: /etc/ntp.conf - notify: - - restart ntpd - tags: ntp - - - name: be sure ntpd is running and enabled - ansible.builtin.service: - name: ntpd - state: started - enabled: true - tags: ntp - -Here is an example handlers file. Handlers are only triggered when certain tasks report changes. Handlers run at the end of each play: - - .. code-block:: yaml - - --- - # file: roles/common/handlers/main.yml - - name: restart ntpd - ansible.builtin.service: - name: ntpd - state: restarted - -See :ref:`playbooks_reuse_roles` for more information. - - -.. _organization_examples: - -What the sample setup enables ------------------------------ - -The basic organizational structure described above enables a lot of different automation options. To reconfigure your entire infrastructure: - - .. code-block:: shell - - ansible-playbook -i production site.yml - -To reconfigure NTP on everything: - - .. code-block:: shell - - ansible-playbook -i production site.yml --tags ntp - -To reconfigure only the webservers: - - .. code-block:: shell - - ansible-playbook -i production webservers.yml - -To reconfigure only the webservers in Boston: - - .. code-block:: shell - - ansible-playbook -i production webservers.yml --limit boston - -To reconfigure only the first 10 webservers in Boston, and then the next 10: - - .. code-block:: shell - - ansible-playbook -i production webservers.yml --limit boston[0:9] - ansible-playbook -i production webservers.yml --limit boston[10:19] - -The sample setup also supports basic ad hoc commands: - - .. code-block:: shell - - ansible boston -i production -m ping - ansible boston -i production -m command -a '/sbin/reboot' - -To discover what tasks would run or what hostnames would be affected by a particular Ansible command: - - .. code-block:: shell - - # confirm what task names would be run if I ran this command and said "just ntp tasks" - ansible-playbook -i production webservers.yml --tags ntp --list-tasks - - # confirm what hostnames might be communicated with if I said "limit to boston" - ansible-playbook -i production webservers.yml --limit boston --list-hosts - -.. _dep_vs_config: - -Organizing for deployment or configuration ------------------------------------------- - -The sample setup illustrates a typical configuration topology. When you do multi-tier deployments, you will likely need some additional playbooks that hop between tiers to roll out an application. In this case, you can augment ``site.yml`` with playbooks like ``deploy_exampledotcom.yml``. However, the general concepts still apply. With Ansible you can deploy and configure using the same utility. Therefore, you will probably reuse groups and keep the OS configuration in separate playbooks or roles from the application deployment. - -Consider "playbooks" as a sports metaphor -- you can have one set of plays to use against all your infrastructure. Then you have situational plays that you use at different times and for different purposes. - -.. _ship_modules_with_playbooks: - -Using local Ansible modules ---------------------------- - -If a playbook has a :file:`./library` directory relative to its YAML file, you can use this directory to add Ansible modules automatically to the module path. This organizes modules with playbooks. For example, see the directory structure at the start of this section. - -.. seealso:: - - :ref:`yaml_syntax` - Learn about YAML syntax - :ref:`working_with_playbooks` - Review the basic playbook features - :ref:`list_of_collections` - Browse existing collections, modules, and plugins - :ref:`developing_modules` - Learn how to extend Ansible by writing your own modules - :ref:`intro_patterns` - Learn about how to select hosts - `GitHub examples directory `_ - Complete playbook files from the github project source - `Mailing List `_ - Questions? Help? Ideas? Stop by the list on Google Groups diff --git a/docs/docsite/rst/tips_tricks/shared_snippets/role_directory.txt b/docs/docsite/rst/tips_tricks/shared_snippets/role_directory.txt deleted file mode 100644 index 25aa1784b19..00000000000 --- a/docs/docsite/rst/tips_tricks/shared_snippets/role_directory.txt +++ /dev/null @@ -1,26 +0,0 @@ -.. code-block:: yaml - - roles/ - common/ # this hierarchy represents a "role" - tasks/ # - main.yml # <-- tasks file can include smaller files if warranted - handlers/ # - main.yml # <-- handlers file - templates/ # <-- files for use with the template resource - ntp.conf.j2 # <------- templates end in .j2 - files/ # - bar.txt # <-- files for use with the copy resource - foo.sh # <-- script files for use with the script resource - vars/ # - main.yml # <-- variables associated with this role - defaults/ # - main.yml # <-- default lower priority variables for this role - meta/ # - main.yml # <-- role dependencies and optional Galaxy info - library/ # roles can also include custom modules - module_utils/ # roles can also include custom module_utils - lookup_plugins/ # or other types of plugins, like lookup in this case - - webtier/ # same kind of structure as "common" was above, done for the webtier role - monitoring/ # "" - fooapp/ # "" diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml deleted file mode 100644 index 4c39a63f266..00000000000 --- a/docs/docsite/rst/tips_tricks/yaml/tip_group_by.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- name: talk to all hosts just so we can learn about them - hosts: all - tasks: - - name: Classify hosts depending on their OS distribution - group_by: - key: os_{{ ansible_facts['distribution'] }} \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml deleted file mode 100644 index b4e2fc009fd..00000000000 --- a/docs/docsite/rst/tips_tricks/yaml/tip_group_hosts.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- hosts: os_CentOS - gather_facts: False - tasks: - # Tasks for CentOS hosts only go in this play. - - name: Ping my CentOS hosts - ansible.builtin.ping: \ No newline at end of file diff --git a/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml b/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml deleted file mode 100644 index aae27c34385..00000000000 --- a/docs/docsite/rst/tips_tricks/yaml/tip_include_vars.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- hosts: all - tasks: - - name: Set OS distribution dependent variables - include_vars: "os_{{ ansible_facts['distribution'] }}.yml" - - debug: - var: asdf \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/basic_concepts.rst b/docs/docsite/rst/user_guide/basic_concepts.rst deleted file mode 100644 index b2e20ab578c..00000000000 --- a/docs/docsite/rst/user_guide/basic_concepts.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**************** -Ansible concepts -**************** - -This page has moved to :ref:`Getting started with Ansible`. diff --git a/docs/docsite/rst/user_guide/become.rst b/docs/docsite/rst/user_guide/become.rst deleted file mode 100644 index 94503b19203..00000000000 --- a/docs/docsite/rst/user_guide/become.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************************** -Understanding privilege escalation: become -****************************************** - -This page has moved to :ref:`playbooks_privilege_escalation`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/cheatsheet.rst b/docs/docsite/rst/user_guide/cheatsheet.rst deleted file mode 100644 index a25dda71c7f..00000000000 --- a/docs/docsite/rst/user_guide/cheatsheet.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -********************** -Ansible CLI cheatsheet -********************** - -This page has moved to :ref:`cheatsheet`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/collections_using.rst b/docs/docsite/rst/user_guide/collections_using.rst deleted file mode 100644 index 02c7e95c513..00000000000 --- a/docs/docsite/rst/user_guide/collections_using.rst +++ /dev/null @@ -1,8 +0,0 @@ - -:orphan: - -***************** -Using collections -***************** - -This page has moved to :ref:`collections_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/command_line_tools.rst b/docs/docsite/rst/user_guide/command_line_tools.rst deleted file mode 100644 index 7545f17a3ce..00000000000 --- a/docs/docsite/rst/user_guide/command_line_tools.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Working with command line tools -=============================== - -This page has moved to :ref:`command_line_tools`. diff --git a/docs/docsite/rst/user_guide/complex_data_manipulation.rst b/docs/docsite/rst/user_guide/complex_data_manipulation.rst deleted file mode 100644 index 1cfa0d22f72..00000000000 --- a/docs/docsite/rst/user_guide/complex_data_manipulation.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Data manipulation -################# - -This page has moved to :ref:`complex_data_manipulation`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/connection_details.rst b/docs/docsite/rst/user_guide/connection_details.rst deleted file mode 100644 index 6a54200a181..00000000000 --- a/docs/docsite/rst/user_guide/connection_details.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************** -Connection methods and details -****************************** - -This page has moved to :ref:`connections`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/index.rst b/docs/docsite/rst/user_guide/index.rst deleted file mode 100644 index 9330382f216..00000000000 --- a/docs/docsite/rst/user_guide/index.rst +++ /dev/null @@ -1,26 +0,0 @@ -:orphan: - -.. _user_guide_index: - -########## -User Guide -########## - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible User Guide! -This guide is now deprecated to improve navigation and organization. -You can find all the user guide content in the following sections: - -* :ref:`inventory_guide_index` -* :ref:`command_guide_index` -* :ref:`playbook_guide_index` -* :ref:`vault_guide_index` -* :ref:`modules_plugins_index` -* :ref:`collections_index` -* :ref:`os_guide_index` -* :ref:`tips_tricks_index` diff --git a/docs/docsite/rst/user_guide/intro.rst b/docs/docsite/rst/user_guide/intro.rst deleted file mode 100644 index 124bde65dea..00000000000 --- a/docs/docsite/rst/user_guide/intro.rst +++ /dev/null @@ -1,15 +0,0 @@ -:orphan: - -Introduction -============ - -Before we start exploring the main components of Ansible -- playbooks, configuration management, deployment, and orchestration -- we'll learn how to get Ansible installed and cover some basic concepts. We'll also go over how to execute ad hoc commands in parallel across your nodes using /usr/bin/ansible, and see what modules are available in Ansible's core (you can also write your own, which is covered later). - -.. toctree:: - :maxdepth: 1 - - ../installation_guide/index - ../dev_guide/overview_architecture - ../installation_guide/intro_configuration - intro_bsd - intro_windows diff --git a/docs/docsite/rst/user_guide/intro_adhoc.rst b/docs/docsite/rst/user_guide/intro_adhoc.rst deleted file mode 100644 index d88200541db..00000000000 --- a/docs/docsite/rst/user_guide/intro_adhoc.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******************************* -Introduction to ad hoc commands -******************************* - -This page has moved to :ref:`intro_adhoc`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_bsd.rst b/docs/docsite/rst/user_guide/intro_bsd.rst deleted file mode 100644 index 2dd99efd48d..00000000000 --- a/docs/docsite/rst/user_guide/intro_bsd.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Ansible and BSD -=============== - -This page has moved to :ref:`working_with_bsd`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_dynamic_inventory.rst b/docs/docsite/rst/user_guide/intro_dynamic_inventory.rst deleted file mode 100644 index be573b852e2..00000000000 --- a/docs/docsite/rst/user_guide/intro_dynamic_inventory.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************** -Working with dynamic inventory -****************************** - -This page has moved to :ref:`intro_dynamic_inventory`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_inventory.rst b/docs/docsite/rst/user_guide/intro_inventory.rst deleted file mode 100644 index 6a10b219335..00000000000 --- a/docs/docsite/rst/user_guide/intro_inventory.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************************** -How to build your inventory -*************************** - -This page has moved to :ref:`intro_inventory`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_patterns.rst b/docs/docsite/rst/user_guide/intro_patterns.rst deleted file mode 100644 index c0ba462a4c2..00000000000 --- a/docs/docsite/rst/user_guide/intro_patterns.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Patterns: targeting hosts and groups -==================================== - -This page has moved to :ref:`intro_patterns`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/intro_windows.rst b/docs/docsite/rst/user_guide/intro_windows.rst deleted file mode 100644 index 369888c3c56..00000000000 --- a/docs/docsite/rst/user_guide/intro_windows.rst +++ /dev/null @@ -1,4 +0,0 @@ -Windows Support -=============== - -You can find documentation for using Ansible on Windows at :ref:`os_guide_index`. diff --git a/docs/docsite/rst/user_guide/modules.rst b/docs/docsite/rst/user_guide/modules.rst deleted file mode 100644 index e060f6ed54a..00000000000 --- a/docs/docsite/rst/user_guide/modules.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Working With Modules -==================== - -This page has moved to :ref:`modules_plugins_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/modules_intro.rst b/docs/docsite/rst/user_guide/modules_intro.rst deleted file mode 100644 index cd7006e8ff3..00000000000 --- a/docs/docsite/rst/user_guide/modules_intro.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Introduction to modules -======================= - -This page has moved to :ref:`modules_plugins_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/modules_support.rst b/docs/docsite/rst/user_guide/modules_support.rst deleted file mode 100644 index daeeec4a6ad..00000000000 --- a/docs/docsite/rst/user_guide/modules_support.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**************************** -Module Maintenance & Support -**************************** - -This page has moved to :ref:`modules_plugins_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks.rst b/docs/docsite/rst/user_guide/playbooks.rst deleted file mode 100644 index fe54708cfcd..00000000000 --- a/docs/docsite/rst/user_guide/playbooks.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Working with playbooks -====================== - -This page has moved to :ref:`working_with_playbooks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_advanced_syntax.rst b/docs/docsite/rst/user_guide/playbooks_advanced_syntax.rst deleted file mode 100644 index f30eb86b31d..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_advanced_syntax.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Advanced Syntax -*************** - -This page has moved to :ref:`playbooks_advanced_syntax`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_async.rst b/docs/docsite/rst/user_guide/playbooks_async.rst deleted file mode 100644 index 5ff2da2bcec..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_async.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Asynchronous actions and polling -================================ - -This page has moved to :ref:`playbooks_async`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_best_practices.rst b/docs/docsite/rst/user_guide/playbooks_best_practices.rst deleted file mode 100644 index 6395e391306..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_best_practices.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Tips and tricks -*************** - -This page has moved to :ref:`tips_and_tricks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_blocks.rst b/docs/docsite/rst/user_guide/playbooks_blocks.rst deleted file mode 100644 index 1137d6605f2..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_blocks.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****** -Blocks -****** - -This page has moved to :ref:`playbooks_blocks`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_checkmode.rst b/docs/docsite/rst/user_guide/playbooks_checkmode.rst deleted file mode 100644 index 1b5d51e3897..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_checkmode.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************************************** -Validating tasks: check mode and diff mode -****************************************** - -This page has moved to :ref:`check_mode_dry`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_conditionals.rst b/docs/docsite/rst/user_guide/playbooks_conditionals.rst deleted file mode 100644 index 8d09a29664d..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_conditionals.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************ -Conditionals -************ - -This page has moved to :ref:`playbooks_conditionals`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_debugger.rst b/docs/docsite/rst/user_guide/playbooks_debugger.rst deleted file mode 100644 index 196f3438699..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_debugger.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Debugging tasks -*************** - -This page has moved to :ref:`playbook_debugger`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_delegation.rst b/docs/docsite/rst/user_guide/playbooks_delegation.rst deleted file mode 100644 index f0ff834fd89..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_delegation.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Controlling where tasks run: delegation and local actions -========================================================= - -This page has moved to :ref:`playbooks_delegation`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_environment.rst b/docs/docsite/rst/user_guide/playbooks_environment.rst deleted file mode 100644 index 1527372fe46..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_environment.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Setting the remote environment -============================== - -This page has moved to :ref:`playbooks_environment`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_error_handling.rst b/docs/docsite/rst/user_guide/playbooks_error_handling.rst deleted file mode 100644 index 95c77fd5531..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_error_handling.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************************** -Error handling in playbooks -*************************** - -This page has moved to :ref:`playbooks_error_handling`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_filters.rst b/docs/docsite/rst/user_guide/playbooks_filters.rst deleted file mode 100644 index 57fb4478208..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_filters.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******************************** -Using filters to manipulate data -******************************** - -This page has moved to :ref:`playbooks_filters`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_filters_ipaddr.rst b/docs/docsite/rst/user_guide/playbooks_filters_ipaddr.rst deleted file mode 100644 index 3c3cdb57d54..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_filters_ipaddr.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -.. _playbooks_filters_ipaddr: - -ipaddr filter -````````````` - -This document has moved to :ref:`plugins_in_ansible.utils`. diff --git a/docs/docsite/rst/user_guide/playbooks_handlers.rst b/docs/docsite/rst/user_guide/playbooks_handlers.rst deleted file mode 100644 index 49b3ca5c2fa..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_handlers.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Handlers: running operations on change -====================================== - -This page has moved to :ref:`handlers`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_intro.rst b/docs/docsite/rst/user_guide/playbooks_intro.rst deleted file mode 100644 index cd8bd991e11..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_intro.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -****************** -Intro to playbooks -****************** - -This page has moved to :ref:`playbooks_intro`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_lookups.rst b/docs/docsite/rst/user_guide/playbooks_lookups.rst deleted file mode 100644 index 409555c3855..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_lookups.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******* -Lookups -******* - -This page has moved to :ref:`playbooks_lookups`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_loops.rst b/docs/docsite/rst/user_guide/playbooks_loops.rst deleted file mode 100644 index bbed1cc9921..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_loops.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -***** -Loops -***** - -This page has moved to :ref:`playbooks_loops`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_module_defaults.rst b/docs/docsite/rst/user_guide/playbooks_module_defaults.rst deleted file mode 100644 index 026e6a50a8f..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_module_defaults.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Module defaults -=============== - -This page has moved to :ref:`module_defaults`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_prompts.rst b/docs/docsite/rst/user_guide/playbooks_prompts.rst deleted file mode 100644 index eacf4a3eda3..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_prompts.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************** -Interactive input: prompts -************************** - -This page has moved to :ref:`playbooks_prompts`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_reuse.rst b/docs/docsite/rst/user_guide/playbooks_reuse.rst deleted file mode 100644 index d27b437a5bc..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_reuse.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************** -Re-using Ansible artifacts -************************** - -This page has moved to :ref:`playbooks_reuse`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_reuse_includes.rst b/docs/docsite/rst/user_guide/playbooks_reuse_includes.rst deleted file mode 100644 index ec34700d23c..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_reuse_includes.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Including and importing -======================= - -The content on this page has been moved to :ref:`playbooks_reuse`. diff --git a/docs/docsite/rst/user_guide/playbooks_reuse_roles.rst b/docs/docsite/rst/user_guide/playbooks_reuse_roles.rst deleted file mode 100644 index 31d1ad0aa3d..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_reuse_roles.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -***** -Roles -***** - -This page has moved to :ref:`playbooks_reuse_roles`. diff --git a/docs/docsite/rst/user_guide/playbooks_startnstep.rst b/docs/docsite/rst/user_guide/playbooks_startnstep.rst deleted file mode 100644 index 0503683451f..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_startnstep.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************************************** -Executing playbooks for troubleshooting -*************************************** - -This page has moved to :ref:`playbooks_start_and_step`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_strategies.rst b/docs/docsite/rst/user_guide/playbooks_strategies.rst deleted file mode 100644 index 6c39aa121cd..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_strategies.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Controlling playbook execution: strategies and more -=================================================== - -This page has moved to :ref:`playbooks_strategies`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_tags.rst b/docs/docsite/rst/user_guide/playbooks_tags.rst deleted file mode 100644 index 9bd706f81e5..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_tags.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -**** -Tags -**** - -This page has moved to :ref:`tags`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_tests.rst b/docs/docsite/rst/user_guide/playbooks_tests.rst deleted file mode 100644 index 49687053848..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_tests.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -***** -Tests -***** - -This page has moved to :ref:`playbooks_tests`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_variables.rst b/docs/docsite/rst/user_guide/playbooks_variables.rst deleted file mode 100644 index 8b798710922..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_variables.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -*************** -Using Variables -*************** - -This page has moved to :ref:`playbooks_variables`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/playbooks_vars_facts.rst b/docs/docsite/rst/user_guide/playbooks_vars_facts.rst deleted file mode 100644 index 9305f58be56..00000000000 --- a/docs/docsite/rst/user_guide/playbooks_vars_facts.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************************************ -Discovering variables: facts and magic variables -************************************************ - -This page has moved to :ref:`vars_and_facts`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/plugin_filtering_config.rst b/docs/docsite/rst/user_guide/plugin_filtering_config.rst deleted file mode 100644 index 18a0d769f40..00000000000 --- a/docs/docsite/rst/user_guide/plugin_filtering_config.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Rejecting modules -================= - -This page has moved to :ref:`modules_plugins_index`. diff --git a/docs/docsite/rst/user_guide/sample_setup.rst b/docs/docsite/rst/user_guide/sample_setup.rst deleted file mode 100644 index 40c3df7d37f..00000000000 --- a/docs/docsite/rst/user_guide/sample_setup.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -******************** -Sample Ansible setup -******************** - -This page has moved to :ref:`sample_setup`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/vault.rst b/docs/docsite/rst/user_guide/vault.rst deleted file mode 100644 index ea9c384b1b3..00000000000 --- a/docs/docsite/rst/user_guide/vault.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -************************************* -Encrypting content with Ansible Vault -************************************* - -This page has moved to :ref:`vault_guide_index`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows.rst b/docs/docsite/rst/user_guide/windows.rst deleted file mode 100644 index 922a7309323..00000000000 --- a/docs/docsite/rst/user_guide/windows.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows Guides -============== - -You can find documentation for using Ansible on Windows at :ref:`os_guide_index`. diff --git a/docs/docsite/rst/user_guide/windows_dsc.rst b/docs/docsite/rst/user_guide/windows_dsc.rst deleted file mode 100644 index e8e781e74b8..00000000000 --- a/docs/docsite/rst/user_guide/windows_dsc.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Desired State Configuration -=========================== - -This page has moved to :ref:`windows_dsc`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_faq.rst b/docs/docsite/rst/user_guide/windows_faq.rst deleted file mode 100644 index 0dc92a9f329..00000000000 --- a/docs/docsite/rst/user_guide/windows_faq.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows Frequently Asked Questions -================================== - -This page has moved to :ref:`windows_faq`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_performance.rst b/docs/docsite/rst/user_guide/windows_performance.rst deleted file mode 100644 index 82d8be303f8..00000000000 --- a/docs/docsite/rst/user_guide/windows_performance.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows performance -=================== - -This page has moved to :ref:`windows_performance`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_setup.rst b/docs/docsite/rst/user_guide/windows_setup.rst deleted file mode 100644 index 95ac6457436..00000000000 --- a/docs/docsite/rst/user_guide/windows_setup.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Setting up a Windows Host -========================= - -This page has moved to :ref:`windows_setup`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_usage.rst b/docs/docsite/rst/user_guide/windows_usage.rst deleted file mode 100644 index 2d637408799..00000000000 --- a/docs/docsite/rst/user_guide/windows_usage.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Using Ansible and Windows -========================= - -This page has moved to :ref:`windows_usage`. \ No newline at end of file diff --git a/docs/docsite/rst/user_guide/windows_winrm.rst b/docs/docsite/rst/user_guide/windows_winrm.rst deleted file mode 100644 index 5ecb89d5acc..00000000000 --- a/docs/docsite/rst/user_guide/windows_winrm.rst +++ /dev/null @@ -1,6 +0,0 @@ -:orphan: - -Windows Remote Management -========================= - -This page has moved to :ref:`windows_winrm`. \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/index.rst b/docs/docsite/rst/vault_guide/index.rst deleted file mode 100644 index ae7ad68db85..00000000000 --- a/docs/docsite/rst/vault_guide/index.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _vault_guide_index: - -############################################ -Protecting sensitive data with Ansible vault -############################################ - -.. note:: - - **Making Open Source More Inclusive** - - Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message `_. - -Welcome to the Ansible vault documentation. -Ansible vault provides a way to encrypt and manage sensitive data such as passwords. -This guide introduces you to Ansible vault and covers the following topics: - -* Managing vault passwords. -* Encrypting content and files with Ansible vault. -* Using encrypted variables and files. - -.. toctree:: - :maxdepth: 2 - - vault - vault_managing_passwords - vault_encrypting_content - vault_using_encrypted_content \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/vault.rst b/docs/docsite/rst/vault_guide/vault.rst deleted file mode 100644 index 3fa8d161877..00000000000 --- a/docs/docsite/rst/vault_guide/vault.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _vault: - -************* -Ansible Vault -************* - -Ansible Vault encrypts variables and files so you can protect sensitive content such as passwords or keys rather than leaving it visible as plaintext in playbooks or roles. -To use Ansible Vault you need one or more passwords to encrypt and decrypt content. -If you store your vault passwords in a third-party tool such as a secret manager, you need a script to access them. -Use the passwords with the :ref:`ansible-vault` command-line tool to create and view encrypted variables, create encrypted files, encrypt existing files, or edit, re-key, or decrypt files. -You can then place encrypted content under source control and share it more safely. - -.. warning:: - * Encryption with Ansible Vault ONLY protects 'data at rest'. - Once the content is decrypted ('data in use'), play and plugin authors are responsible for avoiding any secret disclosure, see :ref:`no_log ` for details on hiding output and :ref:`vault_securing_editor` for security considerations on editors you use with Ansible Vault. - -You can use encrypted variables and files in ad hoc commands and playbooks by supplying the passwords you used to encrypt them. -You can modify your ``ansible.cfg`` file to specify the location of a password file or to always prompt for the password. \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/vault_encrypting_content.rst b/docs/docsite/rst/vault_guide/vault_encrypting_content.rst deleted file mode 100644 index 5c46309c81a..00000000000 --- a/docs/docsite/rst/vault_guide/vault_encrypting_content.rst +++ /dev/null @@ -1,353 +0,0 @@ -.. _vault_encrypting_content: - -Encrypting content with Ansible Vault -===================================== - -Once you have a strategy for managing and storing vault passwords, you can start encrypting content. You can encrypt two types of content with Ansible Vault: variables and files. Encrypted content always includes the ``!vault`` tag, which tells Ansible and YAML that the content needs to be decrypted, and a ``|`` character, which allows multi-line strings. Encrypted content created with ``--vault-id`` also contains the vault ID label. For more details about the encryption process and the format of content encrypted with Ansible Vault, see :ref:`vault_format`. This table shows the main differences between encrypted variables and encrypted files: - -.. table:: - :class: documentation-table - - ====================== ================================= ==================================== - .. Encrypted variables Encrypted files - ====================== ================================= ==================================== - How much is encrypted? Variables within a plaintext file The entire file - - When is it decrypted? On demand, only when needed Whenever loaded or referenced [#f1]_ - - What can be encrypted? Only variables Any structured data file - - ====================== ================================= ==================================== - -.. [#f1] Ansible cannot know if it needs content from an encrypted file unless it decrypts the file, so it decrypts all encrypted files referenced in your playbooks and roles. - -.. _encrypting_variables: -.. _single_encrypted_variable: - -Encrypting individual variables with Ansible Vault --------------------------------------------------- - -You can encrypt single values inside a YAML file using the :ref:`ansible-vault encrypt_string ` command. For one way to keep your vaulted variables safely visible, see :ref:`tip_for_variables_and_vaults`. - -Advantages and disadvantages of encrypting variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -With variable-level encryption, your files are still easily legible. You can mix plaintext and encrypted variables, even inline in a play or role. However, password rotation is not as simple as with file-level encryption. You cannot :ref:`rekey ` encrypted variables. Also, variable-level encryption only works on variables. If you want to encrypt tasks or other content, you must encrypt the entire file. - -.. _encrypt_string_for_use_in_yaml: - -Creating encrypted variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The :ref:`ansible-vault encrypt_string ` command encrypts and formats any string you type (or copy or generate) into a format that can be included in a playbook, role, or variables file. To create a basic encrypted variable, pass three options to the :ref:`ansible-vault encrypt_string ` command: - - * a source for the vault password (prompt, file, or script, with or without a vault ID) - * the string to encrypt - * the string name (the name of the variable) - -The pattern looks like this: - -.. code-block:: bash - - ansible-vault encrypt_string '' --name '' - -For example, to encrypt the string 'foobar' using the only password stored in 'a_password_file' and name the variable 'the_secret': - -.. code-block:: bash - - ansible-vault encrypt_string --vault-password-file a_password_file 'foobar' --name 'the_secret' - -The command above creates this content: - - .. code-block:: yaml - - the_secret: !vault | - $ANSIBLE_VAULT;1.1;AES256 - 62313365396662343061393464336163383764373764613633653634306231386433626436623361 - 6134333665353966363534333632666535333761666131620a663537646436643839616531643561 - 63396265333966386166373632626539326166353965363262633030333630313338646335303630 - 3438626666666137650a353638643435666633633964366338633066623234616432373231333331 - 6564 - -To encrypt the string 'foooodev', add the vault ID label 'dev' with the 'dev' vault password stored in 'a_password_file', and call the encrypted variable 'the_dev_secret': - -.. code-block:: bash - - ansible-vault encrypt_string --vault-id dev@a_password_file 'foooodev' --name 'the_dev_secret' - -The command above creates this content: - - .. code-block:: yaml - - the_dev_secret: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 30613233633461343837653833666333643061636561303338373661313838333565653635353162 - 3263363434623733343538653462613064333634333464660a663633623939393439316636633863 - 61636237636537333938306331383339353265363239643939666639386530626330633337633833 - 6664656334373166630a363736393262666465663432613932613036303963343263623137386239 - 6330 - -To encrypt the string 'letmein' read from stdin, add the vault ID 'dev' using the 'dev' vault password stored in `a_password_file`, and name the variable 'db_password': - -.. code-block:: bash - - echo -n 'letmein' | ansible-vault encrypt_string --vault-id dev@a_password_file --stdin-name 'db_password' - -.. warning:: - - Typing secret content directly at the command line (without a prompt) leaves the secret string in your shell history. Do not do this outside of testing. - -The command above creates this output: - - .. code-block:: console - - Reading plaintext input from stdin. (ctrl-d to end input, twice if your content does not already have a new line) - db_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 61323931353866666336306139373937316366366138656131323863373866376666353364373761 - 3539633234313836346435323766306164626134376564330a373530313635343535343133316133 - 36643666306434616266376434363239346433643238336464643566386135356334303736353136 - 6565633133366366360a326566323363363936613664616364623437336130623133343530333739 - 3039 - -To be prompted for a string to encrypt, encrypt it with the 'dev' vault password from 'a_password_file', name the variable 'new_user_password' and give it the vault ID label 'dev': - -.. code-block:: bash - - ansible-vault encrypt_string --vault-id dev@a_password_file --stdin-name 'new_user_password' - -The command above triggers this prompt: - -.. code-block:: text - - Reading plaintext input from stdin. (ctrl-d to end input, twice if your content does not already have a new line) - -Type the string to encrypt (for example, 'hunter2'), hit ctrl-d, and wait. - -.. warning:: - - Do not press ``Enter`` after supplying the string to encrypt. That will add a newline to the encrypted value. - -The sequence above creates this output: - - .. code-block:: yaml - - new_user_password: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 37636561366636643464376336303466613062633537323632306566653533383833366462366662 - 6565353063303065303831323539656138653863353230620a653638643639333133306331336365 - 62373737623337616130386137373461306535383538373162316263386165376131623631323434 - 3866363862363335620a376466656164383032633338306162326639643635663936623939666238 - 3161 - -You can add the output from any of the examples above to any playbook, variables file, or role for future use. Encrypted variables are larger than plain-text variables, but they protect your sensitive content while leaving the rest of the playbook, variables file, or role in plain text so you can easily read it. - -Viewing encrypted variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can view the original value of an encrypted variable using the debug module. You must pass the password that was used to encrypt the variable. For example, if you stored the variable created by the last example above in a file called 'vars.yml', you could view the unencrypted value of that variable like this: - -.. code-block:: console - - ansible localhost -m ansible.builtin.debug -a var="new_user_password" -e "@vars.yml" --vault-id dev@a_password_file - - localhost | SUCCESS => { - "new_user_password": "hunter2" - } - - -Encrypting files with Ansible Vault ------------------------------------ - -Ansible Vault can encrypt any structured data file used by Ansible, including: - - * group variables files from inventory - * host variables files from inventory - * variables files passed to ansible-playbook with ``-e @file.yml`` or ``-e @file.json`` - * variables files loaded by ``include_vars`` or ``vars_files`` - * variables files in roles - * defaults files in roles - * tasks files - * handlers files - * binary files or other arbitrary files - -The full file is encrypted in the vault. - -.. note:: - - Ansible Vault uses an editor to create or modify encrypted files. See :ref:`vault_securing_editor` for some guidance on securing the editor. - - -Advantages and disadvantages of encrypting files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -File-level encryption is easy to use. Password rotation for encrypted files is straightforward with the :ref:`rekey ` command. Encrypting files can hide not only sensitive values, but the names of the variables you use. However, with file-level encryption the contents of files are no longer easy to access and read. This may be a problem with encrypted tasks files. When encrypting a variables file, see :ref:`tip_for_variables_and_vaults` for one way to keep references to these variables in a non-encrypted file. Ansible always decrypts the entire encrypted file when it is when loaded or referenced, because Ansible cannot know if it needs the content unless it decrypts it. - -.. _creating_files: - -Creating encrypted files -^^^^^^^^^^^^^^^^^^^^^^^^ - -To create a new encrypted data file called 'foo.yml' with the 'test' vault password from 'multi_password_file': - -.. code-block:: bash - - ansible-vault create --vault-id test@multi_password_file foo.yml - -The tool launches an editor (whatever editor you have defined with $EDITOR, default editor is vi). Add the content. When you close the editor session, the file is saved as encrypted data. The file header reflects the vault ID used to create it: - -.. code-block:: text - - ``$ANSIBLE_VAULT;1.2;AES256;test`` - -To create a new encrypted data file with the vault ID 'my_new_password' assigned to it and be prompted for the password: - -.. code-block:: bash - - ansible-vault create --vault-id my_new_password@prompt foo.yml - -Again, add content to the file in the editor and save. Be sure to store the new password you created at the prompt, so you can find it when you want to decrypt that file. - -.. _encrypting_files: - -Encrypting existing files -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To encrypt an existing file, use the :ref:`ansible-vault encrypt ` command. This command can operate on multiple files at once. For example: - -.. code-block:: bash - - ansible-vault encrypt foo.yml bar.yml baz.yml - -To encrypt existing files with the 'project' ID and be prompted for the password: - -.. code-block:: bash - - ansible-vault encrypt --vault-id project@prompt foo.yml bar.yml baz.yml - - -.. _viewing_files: - -Viewing encrypted files -^^^^^^^^^^^^^^^^^^^^^^^ - -To view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view ` command: - -.. code-block:: bash - - ansible-vault view foo.yml bar.yml baz.yml - - -.. _editing_encrypted_files: - -Editing encrypted files -^^^^^^^^^^^^^^^^^^^^^^^ - -To edit an encrypted file in place, use the :ref:`ansible-vault edit ` command. This command decrypts the file to a temporary file, allows you to edit the content, then saves and re-encrypts the content and removes the temporary file when you close the editor. For example: - -.. code-block:: bash - - ansible-vault edit foo.yml - -To edit a file encrypted with the ``vault2`` password file and assigned the vault ID ``pass2``: - -.. code-block:: bash - - ansible-vault edit --vault-id pass2@vault2 foo.yml - - -.. _rekeying_files: - -Changing the password and/or vault ID on encrypted files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To change the password on an encrypted file or files, use the :ref:`rekey ` command: - -.. code-block:: bash - - ansible-vault rekey foo.yml bar.yml baz.yml - -This command can rekey multiple data files at once and will ask for the original password and also the new password. To set a different ID for the rekeyed files, pass the new ID to ``--new-vault-id``. For example, to rekey a list of files encrypted with the 'preprod1' vault ID from the 'ppold' file to the 'preprod2' vault ID and be prompted for the new password: - -.. code-block:: bash - - ansible-vault rekey --vault-id preprod1@ppold --new-vault-id preprod2@prompt foo.yml bar.yml baz.yml - - -.. _decrypting_files: - -Decrypting encrypted files -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have an encrypted file that you no longer want to keep encrypted, you can permanently decrypt it by running the :ref:`ansible-vault decrypt ` command. This command will save the file unencrypted to the disk, so be sure you do not want to :ref:`edit ` it instead. - -.. code-block:: bash - - ansible-vault decrypt foo.yml bar.yml baz.yml - - -.. _vault_securing_editor: - -Steps to secure your editor -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Ansible Vault relies on your configured editor, which can be a source of disclosures. Most editors have ways to prevent loss of data, but these normally rely on extra plain text files that can have a clear text copy of your secrets. Consult your editor documentation to configure the editor to avoid disclosing secure data. The following sections provide some guidance on common editors but should not be taken as a complete guide to securing your editor. - - -vim -... - -You can set the following ``vim`` options in command mode to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the ``vim`` documentation. - - -1. Disable swapfiles that act like an autosave in case of crash or interruption. - -.. code-block:: text - - set noswapfile - -2. Disable creation of backup files. - -.. code-block:: text - - set nobackup - set nowritebackup - -3. Disable the viminfo file from copying data from your current session. - -.. code-block:: text - - set viminfo= - -4. Disable copying to the system clipboard. - -.. code-block:: text - - set clipboard= - - -You can optionally add these settings in ``.vimrc`` for all files, or just specific paths or extensions. See the ``vim`` manual for details. - - -Emacs -...... - -You can set the following Emacs options to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the Emacs documentation. - -1. Do not copy data to the system clipboard. - -.. code-block:: text - - (setq x-select-enable-clipboard nil) - -2. Disable creation of backup files. - -.. code-block:: text - - (setq make-backup-files nil) - -3. Disable autosave files. - -.. code-block:: text - - (setq auto-save-default nil) diff --git a/docs/docsite/rst/vault_guide/vault_managing_passwords.rst b/docs/docsite/rst/vault_guide/vault_managing_passwords.rst deleted file mode 100644 index 3d286c61958..00000000000 --- a/docs/docsite/rst/vault_guide/vault_managing_passwords.rst +++ /dev/null @@ -1,104 +0,0 @@ -.. _vault_managing_passwords: - -Managing vault passwords -======================== - -Managing your encrypted content is easier if you develop a strategy for managing your vault passwords. A vault password can be any string you choose. There is no special command to create a vault password. However, you need to keep track of your vault passwords. Each time you encrypt a variable or file with Ansible Vault, you must provide a password. When you use an encrypted variable or file in a command or playbook, you must provide the same password that was used to encrypt it. To develop a strategy for managing vault passwords, start with two questions: - - * Do you want to encrypt all your content with the same password, or use different passwords for different needs? - * Where do you want to store your password or passwords? - -Choosing between a single password and multiple passwords ---------------------------------------------------------- - -If you have a small team or few sensitive values, you can use a single password for everything you encrypt with Ansible Vault. Store your vault password securely in a file or a secret manager as described below. - -If you have a larger team or many sensitive values, you can use multiple passwords. For example, you can use different passwords for different users or different levels of access. Depending on your needs, you might want a different password for each encrypted file, for each directory, or for each environment. For example, you might have a playbook that includes two vars files, one for the dev environment and one for the production environment, encrypted with two different passwords. When you run the playbook, select the correct vault password for the environment you are targeting, using a vault ID. - -.. _vault_ids: - -Managing multiple passwords with vault IDs ------------------------------------------- - -If you use multiple vault passwords, you can differentiate one password from another with vault IDs. You use the vault ID in three ways: - - * Pass it with :option:`--vault-id ` to the :ref:`ansible-vault` command when you create encrypted content - * Include it wherever you store the password for that vault ID (see :ref:`storing_vault_passwords`) - * Pass it with :option:`--vault-id ` to the :ref:`ansible-playbook` command when you run a playbook that uses content you encrypted with that vault ID - -When you pass a vault ID as an option to the :ref:`ansible-vault` command, you add a label (a hint or nickname) to the encrypted content. This label documents which password you used to encrypt it. The encrypted variable or file includes the vault ID label in plain text in the header. The vault ID is the last element before the encrypted content. For example: - - .. code-block:: yaml - - my_encrypted_var: !vault | - $ANSIBLE_VAULT;1.2;AES256;dev - 30613233633461343837653833666333643061636561303338373661313838333565653635353162 - 3263363434623733343538653462613064333634333464660a663633623939393439316636633863 - 61636237636537333938306331383339353265363239643939666639386530626330633337633833 - 6664656334373166630a363736393262666465663432613932613036303963343263623137386239 - 6330 - -In addition to the label, you must provide a source for the related password. The source can be a prompt, a file, or a script, depending on how you are storing your vault passwords. The pattern looks like this: - -.. code-block:: bash - - --vault-id label@source - -If your playbook uses multiple encrypted variables or files that you encrypted with different passwords, you must pass the vault IDs when you run that playbook. You can use :option:`--vault-id ` by itself, with :option:`--vault-password-file `, or with :option:`--ask-vault-pass `. The pattern is the same as when you create encrypted content: include the label and the source for the matching password. - -See below for examples of encrypting content with vault IDs and using content encrypted with vault IDs. The :option:`--vault-id ` option works with any Ansible command that interacts with vaults, including :ref:`ansible-vault`, :ref:`ansible-playbook`, and so on. - -Limitations of vault IDs -^^^^^^^^^^^^^^^^^^^^^^^^ - -Ansible does not enforce using the same password every time you use a particular vault ID label. You can encrypt different variables or files with the same vault ID label but different passwords. This usually happens when you type the password at a prompt and make a mistake. It is possible to use different passwords with the same vault ID label on purpose. For example, you could use each label as a reference to a class of passwords, rather than a single password. In this scenario, you must always know which specific password or file to use in context. However, you are more likely to encrypt two files with the same vault ID label and different passwords by mistake. If you encrypt two files with the same label but different passwords by accident, you can :ref:`rekey ` one file to fix the issue. - -Enforcing vault ID matching -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default the vault ID label is only a hint to remind you which password you used to encrypt a variable or file. Ansible does not check that the vault ID in the header of the encrypted content matches the vault ID you provide when you use the content. Ansible decrypts all files and variables called by your command or playbook that are encrypted with the password you provide. To check the encrypted content and decrypt it only when the vault ID it contains matches the one you provide with ``--vault-id``, set the config option :ref:`DEFAULT_VAULT_ID_MATCH`. When you set :ref:`DEFAULT_VAULT_ID_MATCH`, each password is only used to decrypt data that was encrypted with the same label. This is efficient, predictable, and can reduce errors when different values are encrypted with different passwords. - -.. note:: - Even with the :ref:`DEFAULT_VAULT_ID_MATCH` setting enabled, Ansible does not enforce using the same password every time you use a particular vault ID label. - -.. _storing_vault_passwords: - -Storing and accessing vault passwords -------------------------------------- - -You can memorize your vault password, or manually copy vault passwords from any source and paste them at a command-line prompt, but most users store them securely and access them as needed from within Ansible. You have two options for storing vault passwords that work from within Ansible: in files, or in a third-party tool such as the system keyring or a secret manager. If you store your passwords in a third-party tool, you need a vault password client script to retrieve them from within Ansible. - -Storing passwords in files -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To store a vault password in a file, enter the password as a string on a single line in the file. Make sure the permissions on the file are appropriate. Do not add password files to source control. - -.. _vault_password_client_scripts: - -Storing passwords in third-party tools with vault password client scripts -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can store your vault passwords on the system keyring, in a database, or in a secret manager and retrieve them from within Ansible using a vault password client script. Enter the password as a string on a single line. If your password has a vault ID, store it in a way that works with your password storage tool. - -To create a vault password client script: - - * Create a file with a name ending in either ``-client`` or ``-client.EXTENSION`` - * Make the file executable - * Within the script itself: - * Print the passwords to standard output - * Accept a ``--vault-id`` option - * If the script prompts for data (for example, a database password), display the prompts to the TTY. - -When you run a playbook that uses vault passwords stored in a third-party tool, specify the script as the source within the ``--vault-id`` flag. For example: - -.. code-block:: bash - - ansible-playbook --vault-id dev@contrib/vault/vault-keyring-client.py - -Ansible executes the client script with a ``--vault-id`` option so the script knows which vault ID label you specified. For example a script loading passwords from a secret manager can use the vault ID label to pick either the 'dev' or 'prod' password. The example command above results in the following execution of the client script: - -.. code-block:: bash - - contrib/vault/vault-keyring-client.py --vault-id dev - -For an example of a client script that loads passwords from the system keyring, see the `vault-keyring-client script `_. \ No newline at end of file diff --git a/docs/docsite/rst/vault_guide/vault_using_encrypted_content.rst b/docs/docsite/rst/vault_guide/vault_using_encrypted_content.rst deleted file mode 100644 index 476e4a9d22a..00000000000 --- a/docs/docsite/rst/vault_guide/vault_using_encrypted_content.rst +++ /dev/null @@ -1,184 +0,0 @@ -.. _vault_using_encrypted_content: -.. _playbooks_vault: -.. _providing_vault_passwords: - -Using encrypted variables and files -=================================== - -When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or by setting a default password source in a config option or an environment variable. - -Passing a single password -------------------------- - -If all the encrypted variables and files your task or playbook needs use a single password, you can use the :option:`--ask-vault-pass ` or :option:`--vault-password-file ` cli options. - -To prompt for the password: - -.. code-block:: bash - - ansible-playbook --ask-vault-pass site.yml - -To retrieve the password from the :file:`/path/to/my/vault-password-file` file: - -.. code-block:: bash - - ansible-playbook --vault-password-file /path/to/my/vault-password-file site.yml - -To get the password from the vault password client script :file:`my-vault-password-client.py`: - -.. code-block:: bash - - ansible-playbook --vault-password-file my-vault-password-client.py - - -.. _specifying_vault_ids: - -Passing vault IDs ------------------ - -You can also use the :option:`--vault-id ` option to pass a single password with its vault label. This approach is clearer when multiple vaults are used within a single inventory. - -To prompt for the password for the 'dev' vault ID: - -.. code-block:: bash - - ansible-playbook --vault-id dev@prompt site.yml - -To retrieve the password for the 'dev' vault ID from the :file:`dev-password` file: - -.. code-block:: bash - - ansible-playbook --vault-id dev@dev-password site.yml - -To get the password for the 'dev' vault ID from the vault password client script :file:`my-vault-password-client.py`: - -.. code-block:: bash - - ansible-playbook --vault-id dev@my-vault-password-client.py - -Passing multiple vault passwords --------------------------------- - -If your task or playbook requires multiple encrypted variables or files that you encrypted with different vault IDs, you must use the :option:`--vault-id ` option, passing multiple ``--vault-id`` options to specify the vault IDs ('dev', 'prod', 'cloud', 'db') and sources for the passwords (prompt, file, script). . For example, to use a 'dev' password read from a file and to be prompted for the 'prod' password: - -.. code-block:: bash - - ansible-playbook --vault-id dev@dev-password --vault-id prod@prompt site.yml - -By default the vault ID labels (dev, prod and so on) are only hints. Ansible attempts to decrypt vault content with each password. The password with the same label as the encrypted data will be tried first, after that each vault secret will be tried in the order they were provided on the command line. - -Where the encrypted data has no label, or the label does not match any of the provided labels, the passwords will be tried in the order they are specified. In the example above, the 'dev' password will be tried first, then the 'prod' password for cases where Ansible doesn't know which vault ID is used to encrypt something. - -Using ``--vault-id`` without a vault ID ---------------------------------------- - -The :option:`--vault-id ` option can also be used without specifying a vault-id. This behavior is equivalent to :option:`--ask-vault-pass ` or :option:`--vault-password-file ` so is rarely used. - -For example, to use a password file :file:`dev-password`: - -.. code-block:: bash - - ansible-playbook --vault-id dev-password site.yml - -To prompt for the password: - -.. code-block:: bash - - ansible-playbook --vault-id @prompt site.yml - -To get the password from an executable script :file:`my-vault-password-client.py`: - -.. code-block:: bash - - ansible-playbook --vault-id my-vault-password-client.py - -Configuring defaults for using encrypted content -================================================ - -Setting a default vault ID --------------------------- - -If you use one vault ID more frequently than any other, you can set the config option :ref:`DEFAULT_VAULT_IDENTITY_LIST` to specify a default vault ID and password source. Ansible will use the default vault ID and source any time you do not specify :option:`--vault-id `. You can set multiple values for this option. Setting multiple values is equivalent to passing multiple :option:`--vault-id ` cli options. - -Setting a default password source ---------------------------------- - -If you don't want to provide the password file on the command line or if you use one vault password file more frequently than any other, you can set the :ref:`DEFAULT_VAULT_PASSWORD_FILE` config option or the :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` environment variable to specify a default file to use. For example, if you set ``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt``, Ansible will automatically search for the password in that file. This is useful if, for example, you use Ansible from a continuous integration system such as Jenkins. - -The file that you reference can be either a file containing the password (in plain text), or it can be a script (with executable permissions set) that returns the password. - -When are encrypted files made visible? -====================================== - -In general, content you encrypt with Ansible Vault remains encrypted after execution. However, there is one exception. If you pass an encrypted file as the ``src`` argument to the :ref:`copy `, :ref:`template `, :ref:`unarchive `, :ref:`script ` or :ref:`assemble ` module, the file will not be encrypted on the target host (assuming you supply the correct vault password when you run the play). This behavior is intended and useful. You can encrypt a configuration file or template to avoid sharing the details of your configuration, but when you copy that configuration to servers in your environment, you want it to be decrypted so local users and processes can access it. - -.. _vault_format: - -Format of files encrypted with Ansible Vault -============================================ - -Ansible Vault creates UTF-8 encoded txt files. The file format includes a newline terminated header. For example: - - .. code-block:: text - - $ANSIBLE_VAULT;1.1;AES256 - -or - - .. code-block:: text - - $ANSIBLE_VAULT;1.2;AES256;vault-id-label - -The header contains up to four elements, separated by semi-colons (``;``). - - 1. The format ID (``$ANSIBLE_VAULT``). Currently ``$ANSIBLE_VAULT`` is the only valid format ID. The format ID identifies content that is encrypted with Ansible Vault (via vault.is_encrypted_file()). - - 2. The vault format version (``1.X``). All supported versions of Ansible will currently default to '1.1' or '1.2' if a labeled vault ID is supplied. The '1.0' format is supported for reading only (and will be converted automatically to the '1.1' format on write). The format version is currently used as an exact string compare only (version numbers are not currently 'compared'). - - 3. The cipher algorithm used to encrypt the data (``AES256``). Currently ``AES256`` is the only supported cipher algorithm. Vault format 1.0 used 'AES', but current code always uses 'AES256'. - - 4. The vault ID label used to encrypt the data (optional, ``vault-id-label``) For example, if you encrypt a file with ``--vault-id dev@prompt``, the vault-id-label is ``dev``. - -Note: In the future, the header could change. Fields after the format ID and format version depend on the format version, and future vault format versions may add more cipher algorithm options and/or additional fields. - -The rest of the content of the file is the 'vaulttext'. The vaulttext is a text armored version of the -encrypted ciphertext. Each line is 80 characters wide, except for the last line which may be shorter. - -Ansible Vault payload format 1.1 - 1.2 --------------------------------------- - -The vaulttext is a concatenation of the ciphertext and a SHA256 digest with the result 'hexlifyied'. - -'hexlify' refers to the ``hexlify()`` method of the Python Standard Library's `binascii `_ module. - -hexlify()'ed result of: - -- hexlify()'ed string of the salt, followed by a newline (``0x0a``) -- hexlify()'ed string of the crypted HMAC, followed by a newline. The HMAC is: - - - a `RFC2104 `_ style HMAC - - - inputs are: - - - The AES256 encrypted ciphertext - - A PBKDF2 key. This key, the cipher key, and the cipher IV are generated from: - - - the salt, in bytes - - 10000 iterations - - SHA256() algorithm - - the first 32 bytes are the cipher key - - the second 32 bytes are the HMAC key - - remaining 16 bytes are the cipher IV - -- hexlify()'ed string of the ciphertext. The ciphertext is: - - - AES256 encrypted data. The data is encrypted using: - - - AES-CTR stream cipher - - cipher key - - IV - - a 128 bit counter block seeded from an integer IV - - the plaintext - - - the original plaintext - - padding up to the AES256 blocksize. (The data used for padding is based on `RFC5652 `_) diff --git a/docs/docsite/sphinx_conf/2.10_conf.py b/docs/docsite/sphinx_conf/2.10_conf.py deleted file mode 100644 index 7e3327e711a..00000000000 --- a/docs/docsite/sphinx_conf/2.10_conf.py +++ /dev/null @@ -1,306 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = '2.10' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'porting_guides/core_porting_guides', -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '2.10', - # list specifically out of order to make latest work - 'available_versions': ('latest', '2.9', '2.9_ja', '2.8', 'devel'), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_2_10': ('https://docs.ansible.com/ansible/2.10/', (None, '../ansible_2_10.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - 'ansible_2_8': ('https://docs.ansible.com/ansible/2.8/', (None, '../ansible_2_8.inv')), - 'ansible_2_7': ('https://docs.ansible.com/ansible/2.7/', (None, '../ansible_2_7.inv')), - 'ansible_2_6': ('https://docs.ansible.com/ansible/2.6/', (None, '../ansible_2_6.inv')), - 'ansible_2_5': ('https://docs.ansible.com/ansible/2.5/', (None, '../ansible_2_5.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/all_conf.py b/docs/docsite/sphinx_conf/all_conf.py deleted file mode 100644 index 58db693aadb..00000000000 --- a/docs/docsite/sphinx_conf/all_conf.py +++ /dev/null @@ -1,299 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = 'devel' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': 'devel', - # list specifically out of order to make latest work - 'available_versions': ('devel',), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Core Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mapping to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/ansible_conf.py b/docs/docsite/sphinx_conf/ansible_conf.py deleted file mode 100644 index 1fa8cab8d2e..00000000000 --- a/docs/docsite/sphinx_conf/ansible_conf.py +++ /dev/null @@ -1,309 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = '7' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'dev_guide/ansible_index.rst', - 'dev_guide/core_index.rst', - 'dev_guide/core_branches_and_tags.rst', - 'porting_guides/core_porting_guides.rst', - 'porting_guides/porting_guide_base_2.10.rst', - 'porting_guides/porting_guide_core_*', - 'roadmap/index.rst', -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '7', - # list specifically out of order to make latest work - 'available_versions': ('latest', '2.9', 'devel'), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/core_conf.py b/docs/docsite/sphinx_conf/core_conf.py deleted file mode 100644 index a1ce0ee18c3..00000000000 --- a/docs/docsite/sphinx_conf/core_conf.py +++ /dev/null @@ -1,349 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = '2.14' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'network', - 'scenario_guides', - 'community/collection_contributors/test_index.rst', - 'community/collection_contributors/collection_integration_about.rst', - 'community/collection_contributors/collection_integration_updating.rst', - 'community/collection_contributors/collection_integration_add.rst', - 'community/collection_contributors/collection_test_pr_locally.rst', - 'community/collection_contributors/collection_integration_tests.rst', - 'community/collection_contributors/collection_integration_running.rst', - 'community/collection_contributors/collection_reviewing.rst', - 'community/collection_contributors/collection_requirements.rst', - 'community/collection_contributors/collection_unit_tests.rst', - 'community/maintainers.rst', - 'community/contributions_collections.rst', - 'community/create_pr_quick_start.rst', - 'community/reporting_collections.rst', - 'community/contributing_maintained_collections.rst', - 'community/collection_development_process.rst', - 'community/collection_contributors/collection_release_without_branches.rst', - 'community/collection_contributors/collection_release_with_branches.rst', - 'community/collection_contributors/collection_releasing.rst', - 'community/maintainers_guidelines.rst', - 'community/maintainers_workflow.rst', - 'community/steering/community_steering_committee.rst', - 'community/steering/steering_committee_membership.rst', - 'community/steering/steering_committee_past_members.rst', - 'community/steering/steering_index.rst', - 'dev_guide/ansible_index.rst', - 'dev_guide/core_index.rst', - 'dev_guide/platforms/aws_guidelines.rst', - 'dev_guide/platforms/openstack_guidelines.rst', - 'dev_guide/platforms/ovirt_dev_guide.rst', - 'dev_guide/platforms/vmware_guidelines.rst', - 'dev_guide/platforms/vmware_rest_guidelines.rst', - 'porting_guides/porting_guides.rst', - 'porting_guides/porting_guide_[1-9]*', - 'roadmap/index.rst', - 'roadmap/ansible_roadmap_index.rst', - 'roadmap/old_roadmap_index.rst', - 'roadmap/ROADMAP_2_5.rst', - 'roadmap/ROADMAP_2_6.rst', - 'roadmap/ROADMAP_2_7.rst', - 'roadmap/ROADMAP_2_8.rst', - 'roadmap/ROADMAP_2_9.rst', - 'roadmap/COLLECTIONS*' -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '2.15', - # list specifically out of order to make latest work - 'available_versions': ('2.15', '2.14', '2.13', 'devel',), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [ - 'css/core-color-scheme.css', -] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Core Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/sphinx_conf/core_lang_conf.py b/docs/docsite/sphinx_conf/core_lang_conf.py deleted file mode 100644 index 2d4ecc14e0c..00000000000 --- a/docs/docsite/sphinx_conf/core_lang_conf.py +++ /dev/null @@ -1,349 +0,0 @@ -# -*- coding: utf-8 -*- -# -# documentation build configuration file, created by -# sphinx-quickstart on Sat Sep 27 13:23:22 2008-2009. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# The contents of this file are pickled, so don't put values in the namespace -# that aren't pickleable (module imports are okay, they're removed -# automatically). -# -# All configuration values have a default value; values that are commented out -# serve to show the default value. - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import sys -import os - -# If your extensions are in another directory, add it here. If the directory -# is relative to the documentation root, use os.path.abspath to make it -# absolute, like shown here. -# sys.path.append(os.path.abspath('some/directory')) -# -sys.path.insert(0, os.path.join('ansible', 'lib')) - -# We want sphinx to document the ansible modules contained in this repository, -# not those that may happen to be installed in the version -# of Python used to run sphinx. When sphinx loads in order to document, -# the repository version needs to be the one that is loaded: -sys.path.insert(0, os.path.abspath(os.path.join('..', '..', '..', 'lib'))) - -VERSION = '2.14_ja' -AUTHOR = 'Ansible, Inc' - - -# General configuration -# --------------------- - -# Add any Sphinx extension module names here, as strings. -# They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -# TEST: 'sphinxcontrib.fulltoc' -extensions = [ - 'sphinx.ext.autodoc', - 'sphinx.ext.intersphinx', - 'notfound.extension', - 'sphinx_antsibull_ext', # provides CSS for the plugin/module docs generated by antsibull -] - -# Later on, add 'sphinx.ext.viewcode' to the list if you want to have -# colorized code generated too for references. - - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['../.templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -root_doc = master_doc = 'index' # Sphinx 4+ / 3- - -# General substitutions. -project = 'Ansible' -copyright = "Ansible project contributors" - -# The default replacements for |version| and |release|, also used in various -# other places throughout the built documents. -# -# The short X.Y version. -version = VERSION -# The full version, including alpha/beta/rc tags. -release = VERSION - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# today = '' -# Else, today_fmt is used as the format for a strftime call. -today_fmt = '%B %d, %Y' - -# List of documents that shouldn't be included in the build. -# unused_docs = [] - -# List of directories, relative to source directories, that shouldn't be -# searched for source files. -# exclude_dirs = [] - -# A list of glob-style patterns that should be excluded when looking -# for source files. -exclude_patterns = [ - '2.10_index.rst', - 'ansible_index.rst', - 'core_index.rst', - 'network', - 'scenario_guides', - 'community/collection_contributors/test_index.rst', - 'community/collection_contributors/collection_integration_about.rst', - 'community/collection_contributors/collection_integration_updating.rst', - 'community/collection_contributors/collection_integration_add.rst', - 'community/collection_contributors/collection_test_pr_locally.rst', - 'community/collection_contributors/collection_integration_tests.rst', - 'community/collection_contributors/collection_integration_running.rst', - 'community/collection_contributors/collection_reviewing.rst', - 'community/collection_contributors/collection_requirements.rst', - 'community/collection_contributors/collection_unit_tests.rst', - 'community/maintainers.rst', - 'community/contributions_collections.rst', - 'community/create_pr_quick_start.rst', - 'community/reporting_collections.rst', - 'community/contributing_maintained_collections.rst', - 'community/collection_development_process.rst', - 'community/collection_contributors/collection_release_without_branches.rst', - 'community/collection_contributors/collection_release_with_branches.rst', - 'community/collection_contributors/collection_releasing.rst', - 'community/maintainers_guidelines.rst', - 'community/maintainers_workflow.rst', - 'community/steering/community_steering_committee.rst', - 'community/steering/steering_committee_membership.rst', - 'community/steering/steering_committee_past_members.rst', - 'community/steering/steering_index.rst', - 'dev_guide/ansible_index.rst', - 'dev_guide/core_index.rst', - 'dev_guide/platforms/aws_guidelines.rst', - 'dev_guide/platforms/openstack_guidelines.rst', - 'dev_guide/platforms/ovirt_dev_guide.rst', - 'dev_guide/platforms/vmware_guidelines.rst', - 'dev_guide/platforms/vmware_rest_guidelines.rst', - 'porting_guides/porting_guides.rst', - 'porting_guides/porting_guide_[1-9]*', - 'roadmap/index.rst', - 'roadmap/ansible_roadmap_index.rst', - 'roadmap/old_roadmap_index.rst', - 'roadmap/ROADMAP_2_5.rst', - 'roadmap/ROADMAP_2_6.rst', - 'roadmap/ROADMAP_2_7.rst', - 'roadmap/ROADMAP_2_8.rst', - 'roadmap/ROADMAP_2_9.rst', - 'roadmap/COLLECTIONS*' -] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'ansible' - -highlight_language = 'YAML+Jinja' - -# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything. -# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and section levels, such as qi_start_: -# |br| is useful for formatting fields inside of tables -# |_| is a nonbreaking space; similarly useful inside of tables -rst_epilog = """ -.. |br| raw:: html - -
    -.. |_| unicode:: 0xA0 - :trim: -""" - - -# Options for HTML output -# ----------------------- - -html_theme_path = [] -html_theme = 'sphinx_ansible_theme' -html_show_sphinx = False - -html_theme_options = { - 'canonical_url': "https://docs.ansible.com/ansible/latest/", - 'hubspot_id': '330046', - 'satellite_tracking': True, - 'show_extranav': True, - 'swift_id': 'yABGvz2N8PwcwBxyfzUc', - 'tag_manager_id': 'GTM-PSB293', - 'vcs_pageview_mode': 'edit' -} - -html_context = { - 'display_github': 'True', - 'show_sphinx': False, - 'is_eol': False, - 'github_user': 'ansible', - 'github_repo': 'ansible', - 'github_version': 'devel/docs/docsite/rst/', - 'github_module_version': 'devel/lib/ansible/modules/', - 'github_root_dir': 'devel/lib/ansible', - 'github_cli_version': 'devel/lib/ansible/cli/', - 'current_version': version, - 'latest_version': '2.14', - # list specifically out of order to make latest work - 'available_versions': ('2.14_ja', '2.13_ja', '2.12_ja',), -} - -# Add extra CSS styles to the resulting HTML pages -html_css_files = [ - 'css/core-color-scheme.css', -] - -# The style sheet to use for HTML and HTML Help pages. A file of that name -# must exist either in Sphinx' static/ path, or in one of the custom paths -# given in html_static_path. -# html_style = 'solar.css' - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -html_title = 'Ansible Core Documentation' - -# A shorter title for the navigation bar. Default is the same as html_title. -html_short_title = 'Documentation' - -# The name of an image file (within the static path) to place at the top of -# the sidebar. -# html_logo = - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# html_favicon = 'favicon.ico' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['../_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# html_additional_pages = {} - -# If false, no module index is generated. -# html_use_modindex = True - -# If false, no index is generated. -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# html_split_index = False - -# If true, the reST sources are included in the HTML build as _sources/. -html_copy_source = False - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# html_use_opensearch = 'https://docs.ansible.com/ansible/latest' - -# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = '' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'Poseidodoc' - -# Configuration for sphinx-notfound-pages -# with no 'notfound_template' and no 'notfound_context' set, -# the extension builds 404.rst into a location-agnostic 404 page -# -# default is `en` - using this for the sub-site: -notfound_default_language = "ansible" -# default is `latest`: -# setting explicitly - docsite serves up /ansible/latest/404.html -# so keep this set to `latest` even on the `devel` branch -# then no maintenance is needed when we branch a new stable_x.x -notfound_default_version = "latest" -# makes default setting explicit: -notfound_no_urls_prefix = False - -# Options for LaTeX output -# ------------------------ - -# The paper size ('letter' or 'a4'). -# latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -# latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, document class -# [howto/manual]). -latex_documents = [ - ('index', 'ansible.tex', 'Ansible Documentation', AUTHOR, 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# latex_use_parts = False - -# Additional stuff for the LaTeX preamble. -# latex_preamble = '' - -# Documents to append as an appendix to all manuals. -# latex_appendices = [] - -# If false, no module index is generated. -# latex_use_modindex = True - -autoclass_content = 'both' - -# Note: Our strategy for intersphinx mappings is to have the upstream build location as the -# canonical source and then cached copies of the mapping stored locally in case someone is building -# when disconnected from the internet. We then have a script to update the cached copies. -# -# Because of that, each entry in this mapping should have this format: -# name: ('http://UPSTREAM_URL', (None, 'path/to/local/cache.inv')) -# -# The update script depends on this format so deviating from this (for instance, adding a third -# location for the mappning to live) will confuse it. -intersphinx_mapping = {'python': ('https://docs.python.org/2/', (None, '../python2.inv')), - 'python3': ('https://docs.python.org/3/', (None, '../python3.inv')), - 'jinja2': ('http://jinja.palletsprojects.com/', (None, '../jinja2.inv')), - 'ansible_7': ('https://docs.ansible.com/ansible/7/', (None, '../ansible_7.inv')), - 'ansible_6': ('https://docs.ansible.com/ansible/6/', (None, '../ansible_6.inv')), - 'ansible_2_9': ('https://docs.ansible.com/ansible/2.9/', (None, '../ansible_2_9.inv')), - } - -# linckchecker settings -linkcheck_ignore = [ -] -linkcheck_workers = 25 -# linkcheck_anchors = False diff --git a/docs/docsite/variables.dot b/docs/docsite/variables.dot deleted file mode 100644 index f5860dcbf8c..00000000000 --- a/docs/docsite/variables.dot +++ /dev/null @@ -1,38 +0,0 @@ -digraph G { - - subgraph cluster_0 { - "command line variables" -> "--extra-args" - } - - subgraph cluster_1 { - "role variables" -> "roles/rolename/vars.yml" -> "parameters passed to role" -> "parameters from dependent roles" - } - - subgraph cluster_2 { - "top-level playbook variables" -> "vars: directives" -> "vars_files: directives"; - } - - subgraph cluster_3 { - "inventory variables" -> "group_vars/all" -> "group_vars/grandparent1" -> "group_vars/parent1" -> "host_vars/myhostname"; - "group_vars/all" -> "group_vars/grandparent2"; - "group_vars/grandparent1" -> "group_vars/parent2" - "group_vars/grandparent2" -> "host_vars/myhostname"; - "group_vars/parent2" -> "host_vars/myhostname" - } - - subgraph cluster_4 { - "facts" -> "gathered host facts" - "facts" -> "host facts from /etc/ansible/facts.d" - "facts" -> "set_fact" - "facts" -> "include_vars" - } - - subgraph cluster_5 { - "role defaults" -> "roles/rolename/defaults.yml" - } - - "command line variables" -> "role variables" -> "top-level playbook variables" -> "inventory variables" -> "role defaults" -> "facts" - - - -} diff --git a/docs/man/.gitignore b/docs/man/.gitignore deleted file mode 100644 index 81a33679397..00000000000 --- a/docs/man/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -*.xml -*.asciidoc diff --git a/docs/man/man3/.gitdir b/docs/man/man3/.gitdir deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/docs/templates/collections_galaxy_meta.rst.j2 b/docs/templates/collections_galaxy_meta.rst.j2 deleted file mode 100644 index 09d11c3d9bc..00000000000 --- a/docs/templates/collections_galaxy_meta.rst.j2 +++ /dev/null @@ -1,98 +0,0 @@ -.. _collections_galaxy_meta: - -************************************ -Collection Galaxy metadata structure -************************************ - -A key component of an Ansible collection is the ``galaxy.yml`` file placed in the root directory of a collection. This -file contains the metadata of the collection that is used to generate a collection artifact. - -Structure -========= - -The ``galaxy.yml`` file must contain the following keys in valid YAML: - - -.. rst-class:: documentation-table - -.. list-table:: - :header-rows: 1 - :widths: auto - - * - Key - - Comment - -{%- for entry in options %} - - - * - .. rst-class:: value-name - - @{ entry.key }@ |br| - - .. rst-class:: value-type - - @{ entry.type | documented_type }@ |_| - - {% if entry.get('required', False) -%} - .. rst-class:: value-separator - - / |_| - - .. rst-class:: value-required - - required - {%- endif %} - - {% if 'version_added' in entry -%} - - .. rst-class:: value-added-in - - |br| version_added: @{ entry.version_added }@ - - |_| - - {%- endif %} - - - {% for desc in entry.description -%} - @{ desc | trim | rst_ify }@ - - {% endfor -%} -{%- endfor %} - - -Examples -======== - -.. code-block:: yaml - - namespace: "namespace_name" - name: "collection_name" - version: "1.0.12" - readme: "README.md" - authors: - - "Author1" - - "Author2 (https://author2.example.com)" - - "Author3 " - dependencies: - "other_namespace.collection1": ">=1.0.0" - "other_namespace.collection2": ">=2.0.0,<3.0.0" - "anderson55.my_collection": "*" # note: "*" selects the highest version available - license: - - "MIT" - tags: - - demo - - collection - repository: "https://www.github.com/my_org/my_collection" - -.. seealso:: - - :ref:`developing_collections` - Develop or modify a collection. - :ref:`developing_modules_general` - Learn about how to write Ansible modules - :ref:`collections` - Learn how to install and use collections. - `Mailing List `_ - The development mailing list - `irc.libera.chat `_ - #ansible IRC chat channel diff --git a/docs/templates/config.rst.j2 b/docs/templates/config.rst.j2 deleted file mode 100644 index 34b2b849518..00000000000 --- a/docs/templates/config.rst.j2 +++ /dev/null @@ -1,242 +0,0 @@ -.. _ansible_configuration_settings: - -{% set name = 'Ansible Configuration Settings' -%} -{% set name_slug = 'config' -%} - -{% set name_len = name|length + 0-%} -{{ '=' * name_len }} -{{name}} -{{ '=' * name_len }} - -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. - -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. - -.. _ansible_configuration_settings_locations: - -The configuration file -====================== - -Changes can be made and used in a configuration file which will be searched for in the following order: - - * ``ANSIBLE_CONFIG`` (environment variable if set) - * ``ansible.cfg`` (in the current directory) - * ``~/.ansible.cfg`` (in the home directory) - * ``/etc/ansible/ansible.cfg`` - -Ansible will process the above list and use the first file found, all others are ignored. - -.. note:: - - 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:: - - # some basic default values... - inventory = /etc/ansible/hosts ; This points to the file that lists your hosts - - -.. _generating_ansible.cfg: - -Generating a sample ``ansible.cfg`` file ------------------------------------------ - -You can generate a fully commented-out example ``ansible.cfg`` file, for example:: - - $ ansible-config init --disabled > ansible.cfg - -You can also have a more complete file that includes existing plugins:: - - $ ansible-config init --disabled -t all > ansible.cfg - -You can use these as starting points to create your own ``ansible.cfg`` file. - -.. _cfg_in_world_writable_dir: - -Avoiding security risks with ``ansible.cfg`` in the current directory ---------------------------------------------------------------------- - - -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. - -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: - -* for Vagrant, the `Vagrant documentation `_ covers synced folder permissions. -* for WSL, the `WSL docs `_ - and this `Microsoft blog post `_ cover mount options. - -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. - - -Relative paths for configuration --------------------------------- - -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 ``{%raw%}{{CWD}}{%endraw%}`` 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``. - - -Common Options -============== - -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. - -{% if config_options %} - - -{% for config_option in config_options|sort %} -{% set config_len = config_option|length -%} -{% set config = config_options[config_option] %} -.. _{{config_option}}: - -{{config_option}} -{{ '-' * config_len }} - -{% if config['description'] and config['description'] != [''] %} -{% if config['description'] != ['TODO: write it'] %} -:Description: {{' '.join(config['description'])}} -{% endif %} -{% endif %} -{% if config['type'] %} -:Type: {{config['type']}} -{% endif %} -{% if 'default' in config %} -:Default: ``{{config['default']}}`` -{% endif %} -{% if config.get('choices', False) %} -:Choices: -{% if config['choices'] is mapping %} -{% for key in config['choices'].keys() %} - - :{{key}}: {{ config['choices'][key] }} -{% endfor %} -{% else %} -{% for key in config['choices'] %} - - {{key}} -{% endfor %} -{% endif %} -{% endif %} -{% if config['version_added'] %} -:Version Added: {{config['version_added']}} -{% endif %} -{% if config.get('ini', False) %} -:Ini: -{% for ini_map in config['ini']|sort(attribute='section') %} - {% if config['ini']|length > 1 %}- {% endif %}:Section: [{{ini_map['section']}}] - {% if config['ini']|length > 1 %} {% endif %}:Key: {{ini_map['key']}} -{% if ini_map['version_added'] %} - :Version Added: {{ini_map['version_added']}} -{% endif %} -{% if ini_map['deprecated'] %} - :Deprecated in: {{ini_map['deprecated']['version']}} - :Deprecated detail: {{ini_map['deprecated']['why']}} -{% if ini_map['deprecated']['alternatives'] %} - :Deprecated alternatives: {{ini_map['deprecated']['alternatives']}} -{% endif %} -{% endif %} -{% endfor %} -{% endif %} -{% if config.get('env', False) %} -:Environment: -{% for env_var_map in config['env']|sort(attribute='name') %} - {% if config['env']|length > 1 %}- {% endif %}:Variable: :envvar:`{{env_var_map['name']}}` -{% if env_var_map['version_added'] %} - :Version Added: {{env_var_map['version_added']}} -{% endif %} -{% if env_var_map['deprecated'] %} - :Deprecated in: {{env_var_map['deprecated']['version']}} - :Deprecated detail: {{env_var_map['deprecated']['why']}} -{% if env_var_map['deprecated']['alternatives'] %} - :Deprecated alternatives: {{env_var_map['deprecated']['alternatives']}} -{% endif %} -{% endif %} -{% endfor %} -{% endif %} -{% if config.get('vars', False) %} -:Variables: -{% for a_var in config['vars']|sort(attribute='name') %} - {% if config['vars']|length > 1 %}- {%endif%}:name: `{{a_var['name']}}` -{% if a_var['version_added'] %} - :Version Added: {{a_var['version_added']}} -{% endif %} -{% if a_var['deprecated'] %} - :Deprecated in: {{a_var['deprecated']['version']}} - :Deprecated detail: {{a_Var['deprecated']['why']}} -{% if a_var['deprecated']['alternatives'] %} - :Deprecated alternatives: {{a_var['deprecated']['alternatives']}} -{% endif %} -{% endif %} -{% endfor %} -{% endif %} -{% if config['deprecated'] %} -:Deprecated in: {{config['deprecated']['version']}} -:Deprecated detail: {{config['deprecated']['why']}} -{% if config['deprecated']['alternatives'] %} -:Deprecated alternatives: {{config['deprecated']['alternatives']}} -{% endif %} -{% endif %} - -{% endfor %} - -Environment Variables -===================== - -.. envvar:: ANSIBLE_CONFIG - - - Override the default ansible config file - - -{% for config_option in config_options %} -{% for env_var_map in config_options[config_option]['env'] %} -.. envvar:: {{env_var_map['name']}} - -{% if config_options[config_option]['description'] and config_options[config_option]['description'] != [''] %} -{% if config_options[config_option]['description'] != ['TODO: write it'] %} - {{ ''.join(config_options[config_option]['description']) }} -{% endif %} -{% endif %} - - See also :ref:`{{config_option}} <{{config_option}}>` - -{% if env_var_map['version_added'] %} - :Version Added: {{env_var_map['version_added']}} -{% endif %} -{% if env_var_map['deprecated'] %} - :Deprecated in: {{env_var_map['deprecated']['version']}} - :Deprecated detail: {{env_var_map['deprecated']['why']}} -{% if env_var_map['deprecated']['alternatives'] %} - :Deprecated alternatives: {{env_var_map['deprecated']['alternatives']}} -{% endif %} -{% endif %} - -{% endfor %} - -{% endfor %} - -{% endif %} diff --git a/docs/templates/modules_by_category.rst.j2 b/docs/templates/modules_by_category.rst.j2 deleted file mode 100644 index 77635284484..00000000000 --- a/docs/templates/modules_by_category.rst.j2 +++ /dev/null @@ -1,17 +0,0 @@ -.. _modules_by_category: - -{# avoids rST "isn't included in any toctree" errors for module index docs #} -:orphan: - -Module Index -============ - - -.. toctree:: :maxdepth: 1 - -{% for name in categories %} -{# strip out empty category names as a result flattening the dir structure #} -{% if name %} - list_of_@{ name }@_modules -{% endif %} -{% endfor %} diff --git a/docs/templates/playbooks_keywords.rst.j2 b/docs/templates/playbooks_keywords.rst.j2 deleted file mode 100644 index 8d42267f24b..00000000000 --- a/docs/templates/playbooks_keywords.rst.j2 +++ /dev/null @@ -1,33 +0,0 @@ -.. _playbook_keywords: - -Playbook Keywords -================= - -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. - - -.. note:: Please note: - - * 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. - * The keywords do not have ``version_added`` information at this time - * Some keywords set defaults for the objects inside of them rather than for the objects - themselves - - -.. contents:: - :local: - :depth: 1 - -{% for name in playbook_class_names %} - -{{ name }} -{{ '-' * name|length }} -{#.. glossary::#} - -{% for attribute in pb_keywords[name]|sort %} - {{ attribute }} - {{ pb_keywords[name][attribute] |indent(8) }} - -{% endfor %} -{% endfor %} diff --git a/examples/DOCUMENTATION.yml b/examples/DOCUMENTATION.yml deleted file mode 100644 index 86d577affc9..00000000000 --- a/examples/DOCUMENTATION.yml +++ /dev/null @@ -1,33 +0,0 @@ ---- -# If a key doesn't apply to your module (ex: choices, default, or -# aliases) you can use the word 'null', or an empty list, [], where -# appropriate. -# See https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_documenting.html for more information -# -module: modulename -short_description: This is a sentence describing the module -description: - - Longer description of the module. - - You might include instructions. -version_added: "X.Y" -author: "Your AWESOME name (@awesome-github-id)" -options: -# One or more of the following - option_name: - description: - - Description of the options goes here. - - Must be written in sentences. - required: true or false - default: a string or the word null - choices: - - enable - - disable - aliases: - - repo_name - version_added: "1.X" -notes: - - Other things consumers of your module should know. -requirements: - - list of required things. - - like the factor package - - zypper >= 1.0 diff --git a/examples/ansible.cfg b/examples/ansible.cfg deleted file mode 100644 index 8670215c2fb..00000000000 --- a/examples/ansible.cfg +++ /dev/null @@ -1,11 +0,0 @@ -# Since Ansible 2.12 (core): -# To generate an example config file (a "disabled" one with all default settings, commented out): -# $ ansible-config init --disabled > ansible.cfg -# -# Also you can now have a more complete file by including existing plugins: -# ansible-config init --disabled -t all > ansible.cfg - -# For previous versions of Ansible you can check for examples in the 'stable' branches of each version -# Note that this file was always incomplete and lagging changes to configuration settings - -# for example, for 2.9: https://github.com/ansible/ansible/blob/stable-2.9/examples/ansible.cfg diff --git a/examples/hosts b/examples/hosts deleted file mode 100644 index e84a30cd984..00000000000 --- a/examples/hosts +++ /dev/null @@ -1,44 +0,0 @@ -# This is the default ansible 'hosts' file. -# -# It should live in /etc/ansible/hosts -# -# - Comments begin with the '#' character -# - Blank lines are ignored -# - Groups of hosts are delimited by [header] elements -# - You can enter hostnames or ip addresses -# - A hostname/ip can be a member of multiple groups - -# Ex 1: Ungrouped hosts, specify before any group headers: - -## green.example.com -## blue.example.com -## 192.168.100.1 -## 192.168.100.10 - -# Ex 2: A collection of hosts belonging to the 'webservers' group: - -## [webservers] -## alpha.example.org -## beta.example.org -## 192.168.1.100 -## 192.168.1.110 - -# If you have multiple hosts following a pattern, you can specify -# them like this: - -## www[001:006].example.com - -# Ex 3: A collection of database servers in the 'dbservers' group: - -## [dbservers] -## -## db01.intranet.mydomain.net -## db02.intranet.mydomain.net -## 10.25.1.56 -## 10.25.1.57 - -# Here's another example of host ranges, this time there are no -# leading 0s: - -## db-[99:101]-node.example.com - diff --git a/examples/hosts.yaml b/examples/hosts.yaml deleted file mode 100644 index 4470504c55e..00000000000 --- a/examples/hosts.yaml +++ /dev/null @@ -1,69 +0,0 @@ -# This is the default ansible 'hosts' file. -# -# It should live in /etc/ansible/hosts -# -# - Comments begin with the '#' character -# - Blank lines are ignored -# - Top level entries are assumed to be groups, start with 'all' to have a full hierarchy -# - Hosts must be specified in a group's hosts: -# and they must be a key (: terminated) -# - groups can have children, hosts and vars keys -# - groups are unique and global - if you define a group in multiple locations, Ansible aggregates all the data to the global name. -# - If you define a group as a child of 2 different groups, it will be the child of both, any hosts and variables assigned will not be dependent on the parents, they will all be associated with the group. -# - Anything defined under a host is assumed to be a var -# - You can enter hostnames or IP addresses -# - A hostname/IP can be a member of multiple groups - -# Ex 1: Ungrouped hosts, put them in 'all' or 'ungrouped' group, defines 4 hosts, one with 2 variables -##all: -## hosts: -## green.example.com: -## ansible_ssh_host: 191.168.100.32 -## anyvariable: value -## blue.example.com: -## 192.168.100.1: -## 192.168.100.10: - -# Ex 2: A collection of hosts belonging to the 'webservers' group, with shared group var -##webservers: -## hosts: -## alpha.example.org: -## beta.example.org: -## 192.168.1.100: -## 192.168.1.110: -## vars: -## http_port: 8080 - -# Ex 3: You can create hosts using ranges and add children groups and vars to a group -# The child group can define anything you would normally add to a group. -# Hosts in child groups inherit all variables from parent, parents include all hosts in child groups. -# webservers is added as a child group of testing, so all gamma hosts (1-3) are added -# to the 'webservers' group, including gamma3, which is defined in the tree of another parent group. -# All references to webservers will get any hosts defined under webservers. -# References to testing will get all of those hosts plus any host matching www[001:006].example.com - -##webservers: -## hosts: -## gamma1.example.org: -## gamma2.example.org: -##testing: -## hosts: -## www[001:006].example.com: -## vars: -## testing1: value1 -## children: -## webservers: -##other: -## children: -## webservers: -## gamma3.example.org - -# From above, the testing group contains: gamma1.example.org gamma2.example.org gamma3.example.org www001.example.com www002.example.com www003.example.com www004.example.com www005.example.com www006.example.com - -# Ex 4: all vars -# keeping within 'all' group you can define common 'all' vars here with lowest precedence - - -##all: -## vars: -## commontoall: thisvar diff --git a/examples/hosts.yml b/examples/hosts.yml deleted file mode 120000 index bd6024a93be..00000000000 --- a/examples/hosts.yml +++ /dev/null @@ -1 +0,0 @@ -hosts.yaml \ No newline at end of file diff --git a/examples/inventory_script_schema.json b/examples/inventory_script_schema.json deleted file mode 100644 index c68b7f82700..00000000000 --- a/examples/inventory_script_schema.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "$schema": "http://json-schema.org/draft-06/schema#", - "title": "Ansible Inventory", - "description" : "Ansible Inventory for the script inventory plugin", - "type": "object", - "patternProperties": { - "^\\w$":{ - "type": "object", - "properties": { - "hosts": { - "description" : "list of hosts that are part of this group", - "type": "array", - "items": { "type": "string" } - }, - "vars": { - "type": "object", - "description": "Variables to assign to hosts that are part of this group" , - "patternProperties": { - "^\\w$":{ "type": "object", "description" : "Vars for this hosts in this group" } - } - }, - "children": { - "description" : "list of groups that are children of this group, their hosts will be added to this group", - "type": "array", - "items": { "type": "string" } - } - }, - "additionalProperties": false - }, - "_meta":{ - "type": "object", - "description" : "Key that avoids calling the script per host", - "required": ["hostvars"], - "properties": { - "hostvars": { - "type": "object", - "description" : "Each key is a hostname and the value is a dictionary of the variables for that host", - "patternProperties": { - "^\\w$":{ - "type": "object", - "description" : "Hosts with their associated vars", - "patternProperties": { - "^\\w$":{ "type": "object", "description" : "Vars for this host" } - } - } - } - } - }, - "additionalProperties": false - } - }, - "additionalProperties": false -} diff --git a/examples/play.yml b/examples/play.yml deleted file mode 100644 index b0dee7d757f..00000000000 --- a/examples/play.yml +++ /dev/null @@ -1,525 +0,0 @@ -#!/usr/bin/env ansible-playbook -# ^ Trick: the above line can be used to make your play an executable -# you also must add 'x' permissions to the file -# -# this file is based on phred's 'pedantically commented playbook' -# https://github.com/phred/ansible-examples/blob/master/pedantically_commented_playbook.yml -# ---- -# ^^^ YAML documents can begin with the document separator "---" -# and end with the "...", neither is needed for Ansible # as it does not -# support multiple YAML documents per file, but some linters incorrectly insist -# you must have it .... -# -# The '#' is a comment character, so any line starting with it will be ignored by Ansible. - -# Blank lines are ignored, so can be used # to create spacing to your taste. - -# Note about YAML: like Python, cares about whitespace, it requires actual spaces, tabs won't work. -# Indent consistently throughout. -# Two-space or four space indents is what most users prefer, but do whatever you like. -# -# If you're new to YAML, keep in mind that YAML documents, like XML -# documents, represent a tree-like structure of nodes and text. More -# familiar with JSON? Think of YAML as a strict (with spaces) but also more flexible -# JSON (fewer significant characters, e.g., :, "", {}, [] and liberal quoting). -# Also, JSON is a subset of YAML, so most YAML parser can read JSON just the same. -# -# The curious may read more about YAML at: -# http://www.yaml.org/spec/1.1/current.html -# there is a 1.2, but Ansible uses pyyaml which is mostly 1.1 - -# the following line configures 'vim' to handle 2 space indents. -# vim:ff=unix ts=2 sw=2 ai expandtab - -### -# Notice the minus (-) on the line below, this is the start of a 'list' in YAML -# In Ansible this is the 'list of plays' which starts this playbook. -# Plays map the inventory hosts to the tasks, the most minimal play you can have -# just requires 'hosts' - -- hosts: all - ########### - # Play keyword: hosts - # Required: yes - # Description: - # The selection of hosts (or host) that the tasks in this play play should apply to. - # - ## Example values: - # hosts: all -- applies to all hosts - # hosts: host1 -- apply ONLY to the host that inventory defines as 'host1' - # hosts: group1 -- apply to all hosts in group1 - # hosts: group1,group2 -- apply to hosts in group1 & group2 - # hosts: group1,host1 -- hosts in group1 AND host - # - ## now using host patterns (TODO: url) - # hosts: group1,!group3 -- hosts in group1 that are not in group3 - # hosts: group1,&group3 -- hosts in group1 that are also in group3 - # hosts: group1:&group3 -- same as above, but using : instead of , as separator - # hosts: group1:!group2:&group3 -- hosts in group1 what are not in group2 but are also in group3 - # - ## Using a variable value for 'hosts' - # - # You can, in fact, set hosts to a variable, for example: - # - # hosts: '{{mygroups}}' -- apply to all hosts specified in the variable 'mygroups' - # - # This is handy for testing playbooks, running the same playbook against a - # staging environment before running it against production, occasional - # maintenance tasks, and other cases where you want to run the playbook - # against just a few systems rather than a whole group. - # Note that the variable cannot be set in inventory, since we need to know the hosts - # before we can use inventory variables. So normally 'extra vars' are used, as you can - # see below. - # - # If you set hosts as shown above, then you can specify which hosts to - # apply the playbook to on each run as so: - # - # ansible-playbook playbook.yml --extra-vars="mygroups=staging" - # - # Use --extra-vars to set the variable to any combination of groups, hostnames, - # or host patterns just like the examples in the previous section. - # - - name: my heavily commented play - ########### - # Play keyword: name - # Default: play### - # Required: no - # Description: Just a description to document the play - - gather_facts: yes - ########### - # Play keyword: gather_facts - # Default: None - # Required: no - # Description: - # This controls if the play will trigger a 'fact gathering task' (aka 'gather_facts' or 'setup' action) to get information about the remote target. - # These facts normally provide useful variables on which to base decisions and task inputs. For example `ansible_os_distribution` can tell us if - # the target is a RHEL, Ubuntu or FreeBSD machine (among others), number of CPUs, RAM, etc. - # TODO: url to fact gathering - - remote_user: login_user - ########### - # Play keyword: user - # Default: depends on connection plugin, for ssh it is 'current user executing Ansible' - # Required: no - # Description: - # Remote user to login on remote targets and 'normally' execute the tasks as - - become: True - ########### - # Play keyword: become - # Default: False - # Required: no - # Description: - # If True, always use privilege escalation to run tasks from this play, just like passing the - # --become flag to ansible or ansible-playbook. - - - become_user: root - ########### - # Play keyword: become_user - # Default: None - # Required: no - # Description: - # When using privilege escalation this is the user you 'become' after login with the remote_user - # for example you login to the remote as 'login_user' then you 'become' root to execute the tasks - - become_method: sudo - ########### - # Play keyword: become_method - # Default: sudo - # Required: no - # Description: - # When using privilege escalation this chooses the become plugin to use for privilege escalation. - # use `ansible-doc -t become -l` to list all the options. - - connection: ssh - ########### - # Play keyword: connection - # Default: ssh - # Required: no - # Description: - # This sets which connection plugin Ansible will use to try to communicate with the target host. - # notable options are paramiko (python implementation of ssh, mostly useful in corner cases in which the ssh cli - # does not work well with the target. Also 'local' which forces a 'local fork' to execute the task, but normally - # what you really want is `delegate_to: localhost` see examples below in 'Run things locally!' entry. - # use `ansible-doc -t connection -l` to list all the options. - - vars: - ########### - # Play keyword: vars - # Default: none - # Required: no - # Description: - # Mapping of variables defined for this play, normally for use in templates or as variables for tasks. - - # to get the value just use {{color}} to reference that value - color: brown - - # Mapping structures allow complex variables structures, to use you can reference - # the variable name with {{web['memcache']}} when using nested key value or {{web}} - # when using the whole structure.. - web: - memcache: 192.168.1.2 - httpd: apache - - # lists use a slightly different notation {{ mylist[1] }} to get 'b', they are 0 indexed. - mylist: - - a - - b - - c - - # Variables can be dynamically set via Jinja templates, to be filled when consumed. - # - # In this playbook, this will always evaluate to False, because 'color' - # is set to 'brown' above. - # - # When ansible interprets the following, it will first expand 'color' to - # 'brown' and then evaluate 'brown' == 'blue' as a Jinja expression. - is_color_blue: "{{ color == 'blue' }}" - - # TODO: (url variables) - - vars_files: - ########## - # Play keyword: vars_files - # Required: no - # Description: - # Specifies a list of YAML files to load variables from. - # - # Always evaluated after the 'vars' section, no matter which section - # occurs first in the playbook. Examples are below. - # - # Example YAML for a file to be included by vars_files: - # --- - # monitored_by: phobos.mars.nasa.gov - # fish_sticks: "good with custard" - # ... # (END OF DOCUMENT) - # - # Remove the indentation & comments of course, the '---' should be at - # the left margin in the variables file. - # - # Include a file from this absolute path - - /srv/ansible/vars/vars_file.yml - - # Include a file from a path relative to this playbook - - vars/vars_file.yml - - # By the way, variables set in 'vars' or as extra vars are available here. - - vars/{{something}}.yml - - # It's also possible to pass an array of files, in which case - # Ansible will loop over the array and include the first file that - # exists. If none exist, ansible-playbook will halt with an error. - # - # An excellent way to handle platform-specific differences. - - [ 'vars/{{platform}}.yml', vars/default.yml ] - - # Files in vars_files process in order, so later files can - # provide more specific configuration: - - [ 'vars/{{host}}.yml' ] - - # Hey, but if you're doing host-specific variable files, you might - # consider setting the variable for a group in your inventory and - # adding your host to that group. Just a thought. - - - vars_prompt: - ########## - # Play keyword: vars_prompt - # Required: no - # Description: - # A list of variables that Ansible will prompt for manual input each time this playbook - # runs. Used for sensitive data and also things like release numbers that - # vary on each deployment. - # - # Ansible won't prompts for this value if already provided, like when - # passed through --extra-vars, but not from inventory. - # - # Also it won't prompt if it detects that it is a non interactive session. - # For example, when called from cron. - # - - name: passphrase - prompt: "Please enter the passphrase for the SSL certificate" - private: yes - # The input won't be echoed back to the terminal when private (default yes) - - # Not sensitive, but something that should vary on each playbook run. - - name: release_version - prompt: "Please enter a release tag" - private: no - - # you can even have a default - - name: package_version - prompt: "Please enter a package version" - default: '1.0' - - # You can find more advanced features in https://docs.ansible.com/ansible/latest/user_guide/playbooks_prompts.html - - roles: - ########## - # Play keyword: roles - # Required: no - # Description: A list of roles to import and execute in this play. Executes AFTER pre_tasks and play fact gathering, but before 'tasks'. - # TODO url roles + url to 'play stages' - - tasks: - ########## - # Play keyword: tasks - # Required: no - # Description: A list of tasks to perform in this play. Executes AFTER roles and before post_tasks - - # A simple task - # Each task must have an action. 'name' is optional but very useful to document what the task does - - name: Check that the target can execute Ansible tasks - action: ping - - ########## - # Ansible modules do the work!, 'action' is not needed, you can use the 'action itself' as part of the task - - file: path=/tmp/secret mode=0600 owner=root group=root - # - # Format 'action' like above: - # : - # - # Test your parameters using: - # ansible -m -a "" - # - # Documentation for the stock modules: - # http://ansible.github.com/modules.html - - # normally most will want to use 'k: v' notation instead of 'k=v' used above (but useful for adhoc execution). - # while both formats are mostly interchangable, `k: v` is more explicit, 'type friendly' and simpler to escape. - - name: Ensure secret is locked down - file: - path: /tmp/secret - mode: '0600' - owner: root - group: root - - # note that 'action options' are indented inside the option, while 'task keywords' stay on the top level - - ########## - # Use variables in the task! It expands on use. - - name: Paint the server - command: echo {{color}} - - # you can also define variables at the task level - - name: Ensure secret is locked down - file: - path: '{{secret_file}}' - mode: '0600' - owner: root - group: root - vars: - secret_file: /tmp/secret - - ########## - # Trigger handlers when things change! - # - # Most Ansible actions can detect and report when something changed. - # Like if file permissions were not the same as requested, - # a file's content is different or a package was installed (or removed) - # When a change is reported, the task assumes the 'changed' status. - # Ansible can optionally notify one or more Handlers. - # Handlers are like normal tasks, the main difference is that they only - # run when notified. - # A common use is to restart a service after updating it's configuration file. - # https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change - - # TODO: explain handler per stage execution - - # This will call the "Restart Apache" handler whenever 'copy' alters - # the remote httpd.conf. - - name: Update the Apache config - copy: - src: httpd.conf - dest: /etc/httpd/httpd.conf - notify: Restart Apache - - # Here's how to specify more than one handler - - name: Update our app's configuration - copy: - src: myapp.conf - dest: /etc/myapp/production.conf - notify: - - Restart Apache - - Restart Redis - - ########## - # Include tasks from another file! - # - # Ansible can insert a list of tasks from another file. The file - # must represent a list of tasks, which is different than a play. - # - # Task list format: - # --- - # - name: create user - # user: name={{myuser}} color={{color}} - # - # - name: add user to group - # user: name={{myuser}} groups={{hisgroup}} append=true - # ... # (END OF DOCUMENT) - # - # A 'tasks' YAML file represents a list of tasks. Don't use playbook - # YAML for a 'tasks' file. - # - # Remove the indentation & comments of course, the '---' should be at - # the left margin in the variables file. - - # TODO: point at import_playbook, includes and roles - # In this example the user will be 'sklar' - # and 'color' will be 'red' inside new_user.yml - - import_tasks: tasks/new_user.yml - vars: - myuser: sklar - color: red - - # In this example the user will be 'mosh' - # and $color will be 'mauve' inside new_user.yml - - import_tasks: tasks/new_user.yml - vars: - myuser: mosh - color: mauve - - - ########## - # Run a task on each thing in a list! - # - # Ansible provides a simple loop facility. If 'loop' is provided for - # a task, then the task will be run once for each item in the provided - # list. Each iteration will create the 'item' variable with a different value. - - name: Create a file named via variable in /tmp - file: path=/tmp/{{item}} state=touched - loop: - - tangerine - - lemon - - - name: Loop using a variable - file: path=/tmp/{{item}} state=touched - loop: '{{mylist}}' - vars: - # defined here, but could be anywhere before the task runs - # also note that YAML lists can be flush with their key, - # we normally indent for clarity, but this form is also correct. - mylist: - - tangerine - - lemon - ########## - # Conditionally execute tasks! - # - # Sometimes you only want to run an action when a under certain conditions. - # Ansible supports using conditional Jinja expression, executing the task only when 'True'. - # - # If you're trying to run an task only when a value changes, - # consider rewriting the task as a handler and using 'notify' (see below). - # - - name: "shutdown all ubuntu" - command: /sbin/shutdown -t now - when: '{{is_ubuntu|bool}}' - - - name: "shutdown the if host is in the government" - command: /sbin/shutdown -t now - when: "{{inventory_hostname in groups['government']}}" - - # another way to write the same. - - name: "shutdown the if host is in the government" - command: /sbin/shutdown -t now - when: "{{'government' in group_names}}" - - # Ansible has some built in variables, you can check them here (TODO url) - # inventory_hostname is the name of the current host the task is executing for (derived from the hosts: keyword) - # group_names has the list of groups the current host (inventory_hostname) is part of - # groups is a mapping of the inventory groups with the list of hosts that belong to them - - ########## - # Run things as other users! - # - # Each task has optional keywords that control which - # user a task should run as and whether or not to use privilege escalation - # (like sudo or su) to switch to that user. - - - name: login in as postgres and dump all postgres databases - shell: pg_dumpall -w -f /tmp/backup.psql - remote_user: postgres - become: False - - - name: login normally, but sudo to postgres to dump all postgres databases - shell: pg_dumpall -w -f /tmp/backup.psql - become: true - become_user: postgres - become_method: sudo - - ########## - # Run things locally! - # - # Each task can also be delegated to the control host - - name: create tempfile - local_action: shell dd if=/dev/urandom of=/tmp/random.txt count=100 - - # which is equivalent to the following - - name: create tempfile - shell: dd if=/dev/urandom of=/tmp/random.txt count=100 - delegate_to: localhost - # delegate_to can use any target, but for the case above, it is the same as using local_action - # TODO url to delegation and implicit localhost - - handlers: - ########## - # Play keyword: handlers - # Required: no - # Description: - # Handlers are tasks that run when another task has changed something. - # See above for examples on how to trigger them. - # The format to define a handler is exactly the same as for tasks. - # Note that if multiple tasks notify the same handler in a playbook run - # that handler will only run once for that host. - # - # Handlers are referred to by name or using the listen keyword. - # They will be run in the order declared in the playbook. - # For example: if a task were to notify the handlers in reverse order like so: - # - # - task: ensure file does not exist - # file: - # name: /tmp/lock.txt - # state: absent - # notify: - # - Restart application - # - Restart nginx - # - # The "Restart nginx" handler will still run before the "Restart application" - # handler because it is declared first in this playbook. - - # this one can only be called by name - - name: Restart nginx - service: - name: nginx - state: restarted - - # this one can be called by name or via any entry in the listen keyword - - name: redis restarter - service: - name: redis - state: restarted - listen: - - Restart redis - - # Any module can be used for the handler action - # even though this can be triggered multiple ways and times - # it will only execute once per host - - name: restart application that should really be a service - command: /srv/myapp/restart.sh - listen: - - Restart application - - restart myapp - - # It's also possible to include handlers from another file. Structure is - # the same as a tasks file, see the tasks section above for an example. - - import_tasks: handlers/site.yml - - -# NOTE: this is not a complete list of all possible keywords in a play or task (TODO: url playbook object and keywords), just an example of very common options. - -# below is the "totally optional" YAML "End of document" marker. -... diff --git a/examples/plugin_filters.yml b/examples/plugin_filters.yml deleted file mode 100644 index b089a4d1f89..00000000000 --- a/examples/plugin_filters.yml +++ /dev/null @@ -1,6 +0,0 @@ ---- -filter_version: '1.0' -module_blacklist: - # List the modules to blacklist here - #- easy_install - #- s3 diff --git a/examples/scripts/ConfigureRemotingForAnsible.ps1 b/examples/scripts/ConfigureRemotingForAnsible.ps1 deleted file mode 100644 index 7cc86abd7ce..00000000000 --- a/examples/scripts/ConfigureRemotingForAnsible.ps1 +++ /dev/null @@ -1,435 +0,0 @@ -#Requires -Version 3.0 - -# Configure a Windows host for remote management with Ansible -# ----------------------------------------------------------- -# -# This script checks the current WinRM (PS Remoting) configuration and makes -# the necessary changes to allow Ansible to connect, authenticate and -# execute PowerShell commands. -# -# IMPORTANT: This script uses self-signed certificates and authentication mechanisms -# that are intended for development environments and evaluation purposes only. -# Production environments and deployments that are exposed on the network should -# use CA-signed certificates and secure authentication mechanisms such as Kerberos. -# -# To run this script in Powershell: -# -# [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -# $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1" -# $file = "$env:temp\ConfigureRemotingForAnsible.ps1" -# -# (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) -# -# powershell.exe -ExecutionPolicy ByPass -File $file -# -# All events are logged to the Windows EventLog, useful for unattended runs. -# -# Use option -Verbose in order to see the verbose output messages. -# -# Use option -CertValidityDays to specify how long this certificate is valid -# starting from today. So you would specify -CertValidityDays 3650 to get -# a 10-year valid certificate. -# -# Use option -ForceNewSSLCert if the system has been SysPreped and a new -# SSL Certificate must be forced on the WinRM Listener when re-running this -# script. This is necessary when a new SID and CN name is created. -# -# Use option -EnableCredSSP to enable CredSSP as an authentication option. -# -# Use option -DisableBasicAuth to disable basic authentication. -# -# Use option -SkipNetworkProfileCheck to skip the network profile check. -# Without specifying this the script will only run if the device's interfaces -# are in DOMAIN or PRIVATE zones. Provide this switch if you want to enable -# WinRM on a device with an interface in PUBLIC zone. -# -# Use option -SubjectName to specify the CN name of the certificate. This -# defaults to the system's hostname and generally should not be specified. - -# Written by Trond Hindenes -# Updated by Chris Church -# Updated by Michael Crilly -# Updated by Anton Ouzounov -# Updated by Nicolas Simond -# Updated by Dag Wieërs -# Updated by Jordan Borean -# Updated by Erwan Quélin -# Updated by David Norman -# -# Version 1.0 - 2014-07-06 -# Version 1.1 - 2014-11-11 -# Version 1.2 - 2015-05-15 -# Version 1.3 - 2016-04-04 -# Version 1.4 - 2017-01-05 -# Version 1.5 - 2017-02-09 -# Version 1.6 - 2017-04-18 -# Version 1.7 - 2017-11-23 -# Version 1.8 - 2018-02-23 -# Version 1.9 - 2018-09-21 - -# Support -Verbose option -[CmdletBinding()] - -Param ( - [string]$SubjectName = $env:COMPUTERNAME, - [int]$CertValidityDays = 1095, - [switch]$SkipNetworkProfileCheck, - $CreateSelfSignedCert = $true, - [switch]$ForceNewSSLCert, - [switch]$GlobalHttpFirewallAccess, - [switch]$DisableBasicAuth = $false, - [switch]$EnableCredSSP -) - -Function Write-ProgressLog { - $Message = $args[0] - Write-EventLog -LogName Application -Source $EventSource -EntryType Information -EventId 1 -Message $Message -} - -Function Write-VerboseLog { - $Message = $args[0] - Write-Verbose $Message - Write-ProgressLog $Message -} - -Function Write-HostLog { - $Message = $args[0] - Write-Output $Message - Write-ProgressLog $Message -} - -Function New-LegacySelfSignedCert { - Param ( - [string]$SubjectName, - [int]$ValidDays = 1095 - ) - - $hostnonFQDN = $env:computerName - $hostFQDN = [System.Net.Dns]::GetHostByName(($env:computerName)).Hostname - $SignatureAlgorithm = "SHA256" - - $name = New-Object -COM "X509Enrollment.CX500DistinguishedName.1" - $name.Encode("CN=$SubjectName", 0) - - $key = New-Object -COM "X509Enrollment.CX509PrivateKey.1" - $key.ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider" - $key.KeySpec = 1 - $key.Length = 4096 - $key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)" - $key.MachineContext = 1 - $key.Create() - - $serverauthoid = New-Object -COM "X509Enrollment.CObjectId.1" - $serverauthoid.InitializeFromValue("1.3.6.1.5.5.7.3.1") - $ekuoids = New-Object -COM "X509Enrollment.CObjectIds.1" - $ekuoids.Add($serverauthoid) - $ekuext = New-Object -COM "X509Enrollment.CX509ExtensionEnhancedKeyUsage.1" - $ekuext.InitializeEncode($ekuoids) - - $cert = New-Object -COM "X509Enrollment.CX509CertificateRequestCertificate.1" - $cert.InitializeFromPrivateKey(2, $key, "") - $cert.Subject = $name - $cert.Issuer = $cert.Subject - $cert.NotBefore = (Get-Date).AddDays(-1) - $cert.NotAfter = $cert.NotBefore.AddDays($ValidDays) - - $SigOID = New-Object -ComObject X509Enrollment.CObjectId - $SigOID.InitializeFromValue(([Security.Cryptography.Oid]$SignatureAlgorithm).Value) - - [string[]] $AlternativeName += $hostnonFQDN - $AlternativeName += $hostFQDN - $IAlternativeNames = New-Object -ComObject X509Enrollment.CAlternativeNames - - foreach ($AN in $AlternativeName) { - $AltName = New-Object -ComObject X509Enrollment.CAlternativeName - $AltName.InitializeFromString(0x3, $AN) - $IAlternativeNames.Add($AltName) - } - - $SubjectAlternativeName = New-Object -ComObject X509Enrollment.CX509ExtensionAlternativeNames - $SubjectAlternativeName.InitializeEncode($IAlternativeNames) - - [String[]]$KeyUsage = ("DigitalSignature", "KeyEncipherment") - $KeyUsageObj = New-Object -ComObject X509Enrollment.CX509ExtensionKeyUsage - $KeyUsageObj.InitializeEncode([int][Security.Cryptography.X509Certificates.X509KeyUsageFlags]($KeyUsage)) - $KeyUsageObj.Critical = $true - - $cert.X509Extensions.Add($KeyUsageObj) - $cert.X509Extensions.Add($ekuext) - $cert.SignatureInformation.HashAlgorithm = $SigOID - $CERT.X509Extensions.Add($SubjectAlternativeName) - $cert.Encode() - - $enrollment = New-Object -COM "X509Enrollment.CX509Enrollment.1" - $enrollment.InitializeFromRequest($cert) - $certdata = $enrollment.CreateRequest(0) - $enrollment.InstallResponse(2, $certdata, 0, "") - - # extract/return the thumbprint from the generated cert - $parsed_cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 - $parsed_cert.Import([System.Text.Encoding]::UTF8.GetBytes($certdata)) - - return $parsed_cert.Thumbprint -} - -Function Enable-GlobalHttpFirewallAccess { - Write-Verbose "Forcing global HTTP firewall access" - # this is a fairly naive implementation; could be more sophisticated about rule matching/collapsing - $fw = New-Object -ComObject HNetCfg.FWPolicy2 - - # try to find/enable the default rule first - $add_rule = $false - $matching_rules = $fw.Rules | Where-Object { $_.Name -eq "Windows Remote Management (HTTP-In)" } - $rule = $null - If ($matching_rules) { - If ($matching_rules -isnot [Array]) { - Write-Verbose "Editing existing single HTTP firewall rule" - $rule = $matching_rules - } - Else { - # try to find one with the All or Public profile first - Write-Verbose "Found multiple existing HTTP firewall rules..." - $rule = $matching_rules | ForEach-Object { $_.Profiles -band 4 }[0] - - If (-not $rule -or $rule -is [Array]) { - Write-Verbose "Editing an arbitrary single HTTP firewall rule (multiple existed)" - # oh well, just pick the first one - $rule = $matching_rules[0] - } - } - } - - If (-not $rule) { - Write-Verbose "Creating a new HTTP firewall rule" - $rule = New-Object -ComObject HNetCfg.FWRule - $rule.Name = "Windows Remote Management (HTTP-In)" - $rule.Description = "Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]" - $add_rule = $true - } - - $rule.Profiles = 0x7FFFFFFF - $rule.Protocol = 6 - $rule.LocalPorts = 5985 - $rule.RemotePorts = "*" - $rule.LocalAddresses = "*" - $rule.RemoteAddresses = "*" - $rule.Enabled = $true - $rule.Direction = 1 - $rule.Action = 1 - $rule.Grouping = "Windows Remote Management" - - If ($add_rule) { - $fw.Rules.Add($rule) - } - - Write-Verbose "HTTP firewall rule $($rule.Name) updated" -} - -# Setup error handling. -Trap { - $_ - Exit 1 -} -$ErrorActionPreference = "Stop" - -# Get the ID and security principal of the current user account -$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent() -$myWindowsPrincipal = new-object System.Security.Principal.WindowsPrincipal($myWindowsID) - -# Get the security principal for the Administrator role -$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator - -# Check to see if we are currently running "as Administrator" -if (-Not $myWindowsPrincipal.IsInRole($adminRole)) { - Write-Output "ERROR: You need elevated Administrator privileges in order to run this script." - Write-Output " Start Windows PowerShell by using the Run as Administrator option." - Exit 2 -} - -$EventSource = $MyInvocation.MyCommand.Name -If (-Not $EventSource) { - $EventSource = "Powershell CLI" -} - -If ([System.Diagnostics.EventLog]::Exists('Application') -eq $False -or [System.Diagnostics.EventLog]::SourceExists($EventSource) -eq $False) { - New-EventLog -LogName Application -Source $EventSource -} - -# Detect PowerShell version. -If ($PSVersionTable.PSVersion.Major -lt 3) { - Write-ProgressLog "PowerShell version 3 or higher is required." - Throw "PowerShell version 3 or higher is required." -} - -# Find and start the WinRM service. -Write-Verbose "Verifying WinRM service." -If (!(Get-Service "WinRM")) { - Write-ProgressLog "Unable to find the WinRM service." - Throw "Unable to find the WinRM service." -} -ElseIf ((Get-Service "WinRM").Status -ne "Running") { - Write-Verbose "Setting WinRM service to start automatically on boot." - Set-Service -Name "WinRM" -StartupType Automatic - Write-ProgressLog "Set WinRM service to start automatically on boot." - Write-Verbose "Starting WinRM service." - Start-Service -Name "WinRM" -ErrorAction Stop - Write-ProgressLog "Started WinRM service." - -} - -# WinRM should be running; check that we have a PS session config. -If (!(Get-PSSessionConfiguration -Verbose:$false) -or (!(Get-ChildItem WSMan:\localhost\Listener))) { - If ($SkipNetworkProfileCheck) { - Write-Verbose "Enabling PS Remoting without checking Network profile." - Enable-PSRemoting -SkipNetworkProfileCheck -Force -ErrorAction Stop - Write-ProgressLog "Enabled PS Remoting without checking Network profile." - } - Else { - Write-Verbose "Enabling PS Remoting." - Enable-PSRemoting -Force -ErrorAction Stop - Write-ProgressLog "Enabled PS Remoting." - } -} -Else { - Write-Verbose "PS Remoting is already enabled." -} - -# Ensure LocalAccountTokenFilterPolicy is set to 1 -# https://github.com/ansible/ansible/issues/42978 -$token_path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -$token_prop_name = "LocalAccountTokenFilterPolicy" -$token_key = Get-Item -Path $token_path -$token_value = $token_key.GetValue($token_prop_name, $null) -if ($token_value -ne 1) { - Write-Verbose "Setting LocalAccountTOkenFilterPolicy to 1" - if ($null -ne $token_value) { - Remove-ItemProperty -Path $token_path -Name $token_prop_name - } - New-ItemProperty -Path $token_path -Name $token_prop_name -Value 1 -PropertyType DWORD > $null -} - -# Make sure there is a SSL listener. -$listeners = Get-ChildItem WSMan:\localhost\Listener -If (!($listeners | Where-Object { $_.Keys -like "TRANSPORT=HTTPS" })) { - # We cannot use New-SelfSignedCertificate on 2012R2 and earlier - $thumbprint = New-LegacySelfSignedCert -SubjectName $SubjectName -ValidDays $CertValidityDays - Write-HostLog "Self-signed SSL certificate generated; thumbprint: $thumbprint" - - # Create the hashtables of settings to be used. - $valueset = @{ - Hostname = $SubjectName - CertificateThumbprint = $thumbprint - } - - $selectorset = @{ - Transport = "HTTPS" - Address = "*" - } - - Write-Verbose "Enabling SSL listener." - New-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset -ValueSet $valueset - Write-ProgressLog "Enabled SSL listener." -} -Else { - Write-Verbose "SSL listener is already active." - - # Force a new SSL cert on Listener if the $ForceNewSSLCert - If ($ForceNewSSLCert) { - - # We cannot use New-SelfSignedCertificate on 2012R2 and earlier - $thumbprint = New-LegacySelfSignedCert -SubjectName $SubjectName -ValidDays $CertValidityDays - Write-HostLog "Self-signed SSL certificate generated; thumbprint: $thumbprint" - - $valueset = @{ - CertificateThumbprint = $thumbprint - Hostname = $SubjectName - } - - # Delete the listener for SSL - $selectorset = @{ - Address = "*" - Transport = "HTTPS" - } - Remove-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset - - # Add new Listener with new SSL cert - New-WSManInstance -ResourceURI 'winrm/config/Listener' -SelectorSet $selectorset -ValueSet $valueset - } -} - -# Check for basic authentication. -$basicAuthSetting = Get-ChildItem WSMan:\localhost\Service\Auth | Where-Object { $_.Name -eq "Basic" } - -If ($DisableBasicAuth) { - If (($basicAuthSetting.Value) -eq $true) { - Write-Verbose "Disabling basic auth support." - Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $false - Write-ProgressLog "Disabled basic auth support." - } - Else { - Write-Verbose "Basic auth is already disabled." - } -} -Else { - If (($basicAuthSetting.Value) -eq $false) { - Write-Verbose "Enabling basic auth support." - Set-Item -Path "WSMan:\localhost\Service\Auth\Basic" -Value $true - Write-ProgressLog "Enabled basic auth support." - } - Else { - Write-Verbose "Basic auth is already enabled." - } -} - -# If EnableCredSSP if set to true -If ($EnableCredSSP) { - # Check for CredSSP authentication - $credsspAuthSetting = Get-ChildItem WSMan:\localhost\Service\Auth | Where-Object { $_.Name -eq "CredSSP" } - If (($credsspAuthSetting.Value) -eq $false) { - Write-Verbose "Enabling CredSSP auth support." - Enable-WSManCredSSP -role server -Force - Write-ProgressLog "Enabled CredSSP auth support." - } -} - -If ($GlobalHttpFirewallAccess) { - Enable-GlobalHttpFirewallAccess -} - -# Configure firewall to allow WinRM HTTPS connections. -$fwtest1 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS" -$fwtest2 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS" profile=any -If ($fwtest1.count -lt 5) { - Write-Verbose "Adding firewall rule to allow WinRM HTTPS." - netsh advfirewall firewall add rule profile=any name="Allow WinRM HTTPS" dir=in localport=5986 protocol=TCP action=allow - Write-ProgressLog "Added firewall rule to allow WinRM HTTPS." -} -ElseIf (($fwtest1.count -ge 5) -and ($fwtest2.count -lt 5)) { - Write-Verbose "Updating firewall rule to allow WinRM HTTPS for any profile." - netsh advfirewall firewall set rule name="Allow WinRM HTTPS" new profile=any - Write-ProgressLog "Updated firewall rule to allow WinRM HTTPS for any profile." -} -Else { - Write-Verbose "Firewall rule already exists to allow WinRM HTTPS." -} - -# Test a remoting connection to localhost, which should work. -$httpResult = Invoke-Command -ComputerName "localhost" -ScriptBlock { $using:env:COMPUTERNAME } -ErrorVariable httpError -ErrorAction SilentlyContinue -$httpsOptions = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck - -$httpsResult = New-PSSession -UseSSL -ComputerName "localhost" -SessionOption $httpsOptions -ErrorVariable httpsError -ErrorAction SilentlyContinue - -If ($httpResult -and $httpsResult) { - Write-Verbose "HTTP: Enabled | HTTPS: Enabled" -} -ElseIf ($httpsResult -and !$httpResult) { - Write-Verbose "HTTP: Disabled | HTTPS: Enabled" -} -ElseIf ($httpResult -and !$httpsResult) { - Write-Verbose "HTTP: Enabled | HTTPS: Disabled" -} -Else { - Write-ProgressLog "Unable to establish an HTTP or HTTPS remoting session." - Throw "Unable to establish an HTTP or HTTPS remoting session." -} -Write-VerboseLog "PS Remoting has been successfully configured for Ansible." diff --git a/examples/scripts/my_test.py b/examples/scripts/my_test.py deleted file mode 100644 index 16aac8934dc..00000000000 --- a/examples/scripts/my_test.py +++ /dev/null @@ -1,134 +0,0 @@ -#!/usr/bin/python - -# Copyright: (c) 2018, Terry Jones -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -DOCUMENTATION = r''' ---- -module: my_test - -short_description: This is my test module - -# If this is part of a collection, you need to use semantic versioning, -# i.e. the version is of the form "2.5.0" and not "2.4". -version_added: "1.0.0" - -description: This is my longer description explaining my test module. - -options: - name: - description: This is the message to send to the test module. - required: true - type: str - new: - description: - - Control to demo if the result of this module is changed or not. - - Parameter description can be a list as well. - required: false - type: bool -# Specify this value according to your collection -# in format of namespace.collection.doc_fragment_name -extends_documentation_fragment: - - my_namespace.my_collection.my_doc_fragment_name - -author: - - Your Name (@yourGitHubHandle) -''' - -EXAMPLES = r''' -# Pass in a message -- name: Test with a message - my_namespace.my_collection.my_test: - name: hello world - -# pass in a message and have changed true -- name: Test with a message and changed output - my_namespace.my_collection.my_test: - name: hello world - new: true - -# fail the module -- name: Test failure of the module - my_namespace.my_collection.my_test: - name: fail me -''' - -RETURN = r''' -# These are examples of possible return values, and in general should use other names for return values. -original_message: - description: The original name param that was passed in. - type: str - returned: always - sample: 'hello world' -message: - description: The output message that the test module generates. - type: str - returned: always - sample: 'goodbye' -''' - -from ansible.module_utils.basic import AnsibleModule - - -def run_module(): - # define available arguments/parameters a user can pass to the module - module_args = dict( - name=dict(type='str', required=True), - new=dict(type='bool', required=False, default=False) - ) - - # seed the result dict in the object - # we primarily care about changed and state - # changed is if this module effectively modified the target - # state will include any data that you want your module to pass back - # for consumption, for example, in a subsequent task - result = dict( - changed=False, - original_message='', - message='' - ) - - # the AnsibleModule object will be our abstraction working with Ansible - # this includes instantiation, a couple of common attr would be the - # args/params passed to the execution, as well as if the module - # supports check mode - module = AnsibleModule( - argument_spec=module_args, - supports_check_mode=True - ) - - # if the user is working with this module in only check mode we do not - # want to make any changes to the environment, just return the current - # state with no modifications - if module.check_mode: - module.exit_json(**result) - - # manipulate or modify the state as needed (this is going to be the - # part where your module will do what it needs to do) - result['original_message'] = module.params['name'] - result['message'] = 'goodbye' - - # use whatever logic you need to determine whether or not this module - # made any modifications to your target - if module.params['new']: - result['changed'] = True - - # during the execution of the module, if there is an exception or a - # conditional state that effectively causes a failure, run - # AnsibleModule.fail_json() to pass in the message and the result - if module.params['name'] == 'fail me': - module.fail_json(msg='You requested this to fail', **result) - - # in the event of a successful module execution, you will want to - # simple AnsibleModule.exit_json(), passing the key/value results - module.exit_json(**result) - - -def main(): - run_module() - - -if __name__ == '__main__': - main() diff --git a/examples/scripts/my_test_facts.py b/examples/scripts/my_test_facts.py deleted file mode 100644 index 555f878efb4..00000000000 --- a/examples/scripts/my_test_facts.py +++ /dev/null @@ -1,96 +0,0 @@ -#!/usr/bin/python - -# Copyright: (c) 2020, Your Name -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -DOCUMENTATION = r''' ---- -module: my_test_facts - -short_description: This is my test facts module - -version_added: "1.0.0" - -description: This is my longer description explaining my test facts module. - -author: - - Your Name (@yourGitHubHandle) -''' - -EXAMPLES = r''' -- name: Return ansible_facts - my_namespace.my_collection.my_test_facts: -''' - -RETURN = r''' -# These are examples of possible return values, and in general should use other names for return values. -ansible_facts: - description: Facts to add to ansible_facts. - returned: always - type: dict - contains: - foo: - description: Foo facts about operating system. - type: str - returned: when operating system foo fact is present - sample: 'bar' - answer: - description: - - Answer facts about operating system. - - This description can be a list as well. - type: str - returned: when operating system answer fact is present - sample: '42' -''' - -from ansible.module_utils.basic import AnsibleModule - - -def run_module(): - # define available arguments/parameters a user can pass to the module - module_args = dict() - - # seed the result dict in the object - # we primarily care about changed and state - # changed is if this module effectively modified the target - # state will include any data that you want your module to pass back - # for consumption, for example, in a subsequent task - result = dict( - changed=False, - ansible_facts=dict(), - ) - - # the AnsibleModule object will be our abstraction working with Ansible - # this includes instantiation, a couple of common attr would be the - # args/params passed to the execution, as well as if the module - # supports check mode - module = AnsibleModule( - argument_spec=module_args, - supports_check_mode=True - ) - - # if the user is working with this module in only check mode we do not - # want to make any changes to the environment, just return the current - # state with no modifications - if module.check_mode: - module.exit_json(**result) - - # manipulate or modify the state as needed (this is going to be the - # part where your module will do what it needs to do) - result['ansible_facts'] = { - 'foo': 'bar', - 'answer': '42', - } - # in the event of a successful module execution, you will want to - # simple AnsibleModule.exit_json(), passing the key/value results - module.exit_json(**result) - - -def main(): - run_module() - - -if __name__ == '__main__': - main() diff --git a/examples/scripts/my_test_info.py b/examples/scripts/my_test_info.py deleted file mode 100644 index 64da3c7b8a8..00000000000 --- a/examples/scripts/my_test_info.py +++ /dev/null @@ -1,111 +0,0 @@ -#!/usr/bin/python - -# Copyright: (c) 2020, Your Name -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -DOCUMENTATION = r''' ---- -module: my_test_info - -short_description: This is my test info module - -version_added: "1.0.0" - -description: This is my longer description explaining my test info module. - -options: - name: - description: This is the message to send to the test module. - required: true - type: str - -author: - - Your Name (@yourGitHubHandle) -''' - -EXAMPLES = r''' -# Pass in a message -- name: Test with a message - my_namespace.my_collection.my_test_info: - name: hello world -''' - -RETURN = r''' -# These are examples of possible return values, and in general should use other names for return values. -original_message: - description: The original name param that was passed in. - type: str - returned: always - sample: 'hello world' -message: - description: The output message that the test module generates. - type: str - returned: always - sample: 'goodbye' -my_useful_info: - description: The dictionary containing information about your system. - type: dict - returned: always - sample: { - 'foo': 'bar', - 'answer': 42, - } -''' - -from ansible.module_utils.basic import AnsibleModule - - -def run_module(): - # define available arguments/parameters a user can pass to the module - module_args = dict( - name=dict(type='str', required=True), - ) - - # seed the result dict in the object - # we primarily care about changed and state - # changed is if this module effectively modified the target - # state will include any data that you want your module to pass back - # for consumption, for example, in a subsequent task - result = dict( - changed=False, - original_message='', - message='', - my_useful_info={}, - ) - - # the AnsibleModule object will be our abstraction working with Ansible - # this includes instantiation, a couple of common attr would be the - # args/params passed to the execution, as well as if the module - # supports check mode - module = AnsibleModule( - argument_spec=module_args, - supports_check_mode=True - ) - - # if the user is working with this module in only check mode we do not - # want to make any changes to the environment, just return the current - # state with no modifications - if module.check_mode: - module.exit_json(**result) - - # manipulate or modify the state as needed (this is going to be the - # part where your module will do what it needs to do) - result['original_message'] = module.params['name'] - result['message'] = 'goodbye' - result['my_useful_info'] = { - 'foo': 'bar', - 'answer': 42, - } - # in the event of a successful module execution, you will want to - # simple AnsibleModule.exit_json(), passing the key/value results - module.exit_json(**result) - - -def main(): - run_module() - - -if __name__ == '__main__': - main() diff --git a/examples/scripts/upgrade_to_ps3.ps1 b/examples/scripts/upgrade_to_ps3.ps1 deleted file mode 100644 index 64867bede89..00000000000 --- a/examples/scripts/upgrade_to_ps3.ps1 +++ /dev/null @@ -1,84 +0,0 @@ - -# Powershell script to upgrade a PowerShell 2.0 system to PowerShell 3.0 -# based on http://occasionalutility.blogspot.com/2013/11/everyday-powershell-part-7-powershell.html -# -# some Ansible modules that may use Powershell 3 features, so systems may need -# to be upgraded. This may be used by a sample playbook. Refer to the windows -# documentation on docs.ansible.com for details. -# -# - hosts: windows -# tasks: -# - script: upgrade_to_ps3.ps1 - -# Get version of OS - -# 6.0 is 2008 -# 6.1 is 2008 R2 -# 6.2 is 2012 -# 6.3 is 2012 R2 - - -if ($PSVersionTable.psversion.Major -ge 3) { - Write-Output "Powershell 3 Installed already; You don't need this" - Exit -} - -$powershellpath = "C:\powershell" - -function download-file { - param ([string]$path, [string]$local) - $client = new-object system.net.WebClient - $client.Headers.Add("user-agent", "PowerShell") - $client.downloadfile($path, $local) -} - -if (!(test-path $powershellpath)) { - New-Item -ItemType directory -Path $powershellpath -} - - -# .NET Framework 4.0 is necessary. - -#if (($PSVersionTable.CLRVersion.Major) -lt 2) -#{ -# $DownloadUrl = "http://download.microsoft.com/download/B/A/4/BA4A7E71-2906-4B2D-A0E1-80CF16844F5F/dotNetFx45_Full_x86_x64.exe" -# $FileName = $DownLoadUrl.Split('/')[-1] -# download-file $downloadurl "$powershellpath\$filename" -# ."$powershellpath\$filename" /quiet /norestart -#} - -#You may need to reboot after the .NET install if so just run the script again. - -# If the Operating System is above 6.2, then you already have PowerShell Version > 3 -if ([Environment]::OSVersion.Version.Major -gt 6) { - Write-Output "OS is new; upgrade not needed." - Exit -} - - -$osminor = [environment]::OSVersion.Version.Minor - -$architecture = $ENV:PROCESSOR_ARCHITECTURE - -if ($architecture -eq "AMD64") { - $architecture = "x64" -} -else { - $architecture = "x86" -} - -if ($osminor -eq 1) { - $DownloadUrl = "http://download.microsoft.com/download/E/7/6/E76850B8-DA6E-4FF5-8CCE-A24FC513FD16/Windows6.1-KB2506143-" + $architecture + ".msu" -} -elseif ($osminor -eq 0) { - $DownloadUrl = "http://download.microsoft.com/download/E/7/6/E76850B8-DA6E-4FF5-8CCE-A24FC513FD16/Windows6.0-KB2506146-" + $architecture + ".msu" -} -else { - # Nothing to do; In theory this point will never be reached. - Exit -} - -$FileName = $DownLoadUrl.Split('/')[-1] -download-file $downloadurl "$powershellpath\$filename" - -Start-Process -FilePath "$powershellpath\$filename" -ArgumentList /quiet diff --git a/examples/scripts/uptime.py b/examples/scripts/uptime.py deleted file mode 100755 index d77a5fb5660..00000000000 --- a/examples/scripts/uptime.py +++ /dev/null @@ -1,130 +0,0 @@ -#!/usr/bin/env python - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import json -import shutil - -import ansible.constants as C -from ansible.executor.task_queue_manager import TaskQueueManager -from ansible.module_utils.common.collections import ImmutableDict -from ansible.inventory.manager import InventoryManager -from ansible.parsing.dataloader import DataLoader -from ansible.playbook.play import Play -from ansible.plugins.callback import CallbackBase -from ansible.vars.manager import VariableManager -from ansible import context - - -# Create a callback plugin so we can capture the output -class ResultsCollectorJSONCallback(CallbackBase): - """A sample callback plugin used for performing an action as results come in. - - If you want to collect all results into a single object for processing at - the end of the execution, look into utilizing the ``json`` callback plugin - or writing your own custom callback plugin. - """ - - def __init__(self, *args, **kwargs): - super(ResultsCollectorJSONCallback, self).__init__(*args, **kwargs) - self.host_ok = {} - self.host_unreachable = {} - self.host_failed = {} - - def v2_runner_on_unreachable(self, result): - host = result._host - self.host_unreachable[host.get_name()] = result - - def v2_runner_on_ok(self, result, *args, **kwargs): - """Print a json representation of the result. - - Also, store the result in an instance attribute for retrieval later - """ - host = result._host - self.host_ok[host.get_name()] = result - print(json.dumps({host.name: result._result}, indent=4)) - - def v2_runner_on_failed(self, result, *args, **kwargs): - host = result._host - self.host_failed[host.get_name()] = result - - -def main(): - host_list = ['localhost', 'www.example.com', 'www.google.com'] - # since the API is constructed for CLI it expects certain options to always be set in the context object - context.CLIARGS = ImmutableDict(connection='smart', module_path=['/to/mymodules', '/usr/share/ansible'], forks=10, become=None, - become_method=None, become_user=None, check=False, diff=False, verbosity=0) - # required for - # https://github.com/ansible/ansible/blob/devel/lib/ansible/inventory/manager.py#L204 - sources = ','.join(host_list) - if len(host_list) == 1: - sources += ',' - - # initialize needed objects - loader = DataLoader() # Takes care of finding and reading yaml, json and ini files - passwords = dict(vault_pass='secret') - - # Instantiate our ResultsCollectorJSONCallback for handling results as they come in. Ansible expects this to be one of its main display outlets - results_callback = ResultsCollectorJSONCallback() - - # create inventory, use path to host config file as source or hosts in a comma separated string - inventory = InventoryManager(loader=loader, sources=sources) - - # variable manager takes care of merging all the different sources to give you a unified view of variables available in each context - variable_manager = VariableManager(loader=loader, inventory=inventory) - - # instantiate task queue manager, which takes care of forking and setting up all objects to iterate over host list and tasks - # IMPORTANT: This also adds library dirs paths to the module loader - # IMPORTANT: and so it must be initialized before calling `Play.load()`. - tqm = TaskQueueManager( - inventory=inventory, - variable_manager=variable_manager, - loader=loader, - passwords=passwords, - stdout_callback=results_callback, # Use our custom callback instead of the ``default`` callback plugin, which prints to stdout - ) - - # create data structure that represents our play, including tasks, this is basically what our YAML loader does internally. - play_source = dict( - name="Ansible Play", - hosts=host_list, - gather_facts='no', - tasks=[ - dict(action=dict(module='shell', args='ls'), register='shell_out'), - dict(action=dict(module='debug', args=dict(msg='{{shell_out.stdout}}'))), - dict(action=dict(module='command', args=dict(cmd='/usr/bin/uptime'))), - ] - ) - - # Create play object, playbook objects use .load instead of init or new methods, - # this will also automatically create the task objects from the info provided in play_source - play = Play().load(play_source, variable_manager=variable_manager, loader=loader) - - # Actually run it - try: - result = tqm.run(play) # most interesting data for a play is actually sent to the callback's methods - finally: - # we always need to cleanup child procs and the structures we use to communicate with them - tqm.cleanup() - if loader: - loader.cleanup_all_tmp_files() - - # Remove ansible tmpdir - shutil.rmtree(C.DEFAULT_LOCAL_TMP, True) - - print("UP ***********") - for host, result in results_callback.host_ok.items(): - print('{0} >>> {1}'.format(host, result._result['stdout'])) - - print("FAILED *******") - for host, result in results_callback.host_failed.items(): - print('{0} >>> {1}'.format(host, result._result['msg'])) - - print("DOWN *********") - for host, result in results_callback.host_unreachable.items(): - print('{0} >>> {1}'.format(host, result._result['msg'])) - - -if __name__ == '__main__': - main() diff --git a/hacking/build-ansible.py b/hacking/build-ansible.py deleted file mode 100755 index 717cf1c1ce0..00000000000 --- a/hacking/build-ansible.py +++ /dev/null @@ -1,130 +0,0 @@ -#!/usr/bin/env python -# coding: utf-8 -# PYTHON_ARGCOMPLETE_OK -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import importlib -import inspect -import os.path -import pkgutil -import sys -import typing as t - -try: - import argcomplete -except ImportError: - argcomplete = None - -C = t.TypeVar('C') - - -def build_lib_path(this_script=__file__): - """Return path to the common build library directory.""" - hacking_dir = os.path.dirname(this_script) - libdir = os.path.abspath(os.path.join(hacking_dir, 'build_library')) - - return libdir - - -def ansible_lib_path(this_script=__file__): - """Return path to the common build library directory.""" - hacking_dir = os.path.dirname(this_script) - libdir = os.path.abspath(os.path.join(hacking_dir, '..', 'lib')) - - return libdir - - -sys.path.insert(0, ansible_lib_path()) -sys.path.insert(0, build_lib_path()) - - -from build_ansible import commands, errors - - -def create_arg_parser(program_name): - """ - Creates a command line argument parser - - :arg program_name: The name of the script. Used in help texts - """ - parser = argparse.ArgumentParser(prog=program_name, - description="Implements utilities to build Ansible") - return parser - - -def load(package: str, subclasses: t.Type[C]) -> list[t.Type[C]]: - """Load modules in the specified package and return concrete types that derive from the specified base class.""" - for module in pkgutil.iter_modules(importlib.import_module(package).__path__, f'{package}.'): - try: - importlib.import_module(module.name) - except ImportError: - pass # ignore plugins which are missing dependencies - - types: set[t.Type[C]] = set() - queue: list[t.Type[C]] = [subclasses] - - while queue: - for child in queue.pop().__subclasses__(): - queue.append(child) - - if not inspect.isabstract(child): - types.add(child) - - return sorted(types, key=lambda sc: sc.__name__) - - -def main(): - """ - Start our run. - - "It all starts here" - """ - subcommands = load('build_ansible.command_plugins', subclasses=commands.Command) - - arg_parser = create_arg_parser(os.path.basename(sys.argv[0])) - arg_parser.add_argument('--debug', dest='debug', required=False, default=False, - action='store_true', - help='Show tracebacks and other debugging information') - subparsers = arg_parser.add_subparsers(title='Subcommands', dest='command', - help='for help use build-ansible.py SUBCOMMANDS -h') - - for subcommand in subcommands: - subcommand.init_parser(subparsers.add_parser) - - if argcomplete: - argcomplete.autocomplete(arg_parser) - - args = arg_parser.parse_args(sys.argv[1:]) - if args.command is None: - print('Please specify a subcommand to run') - sys.exit(1) - - for subcommand in subcommands: - if subcommand.name == args.command: - command = subcommand - break - else: - # Note: We should never trigger this because argparse should shield us from it - print('Error: {0} was not a recognized subcommand'.format(args.command)) - sys.exit(1) - - try: - retval = command.main(args) - except (errors.DependencyError, errors.MissingUserInput, errors.InvalidUserInput) as e: - print(e) - if args.debug: - raise - sys.exit(2) - - sys.exit(retval) - - -if __name__ == '__main__': - main() diff --git a/hacking/build_library/__init__.py b/hacking/build_library/__init__.py deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/hacking/build_library/build_ansible/__init__.py b/hacking/build_library/build_ansible/__init__.py deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/hacking/build_library/build_ansible/announce.py b/hacking/build_library/build_ansible/announce.py deleted file mode 100644 index c245bfb97b9..00000000000 --- a/hacking/build_library/build_ansible/announce.py +++ /dev/null @@ -1,293 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import asyncio -import datetime -import hashlib - -import aiohttp -from jinja2 import Environment, DictLoader - - -VERSION_FRAGMENT = """ -{%- if versions | length > 1 %} - {% for version in versions %} - {% if loop.last %}and {{ pretty_version(version) }}{% else %} - {% if versions | length == 2 %}{{ pretty_version(version) }} {% else %}{{ pretty_version(version) }}, {% endif -%} - {% endif -%} - {% endfor -%} -{%- else %}{{ pretty_version(versions[0]) }}{% endif -%} -""" - -LONG_TEMPLATE = """ -{% set plural = False if versions | length == 1 else True %} -{% set latest_ver = (versions | sort(attribute='ver_obj'))[-1] %} - -To: ansible-releases@redhat.com, ansible-devel@googlegroups.com, ansible-project@googlegroups.com, ansible-announce@googlegroups.com -Subject: New release{% if plural %}s{% endif %}: {{ version_str }} - -{% filter wordwrap %} -Hi all- we're happy to announce that the general release of {{ version_str }}{% if plural %} are{%- else %} is{%- endif %} now available! -{% endfilter %} - - - -How to get it -------------- - -{% for version in versions %} -$ pip install ansible{% if is_ansible_base(version) %}-base{% endif %}=={{ version }} --user -{% if not loop.last %} -or -{% endif %} -{% endfor %} - -The tar.gz of the release{% if plural %}s{% endif %} can be found here: - -{% for version in versions %} -* {{ pretty_version(version) }} -{% if is_ansible_base(version) %} - https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{{ version }}.tar.gz -{% else %} - https://pypi.python.org/packages/source/a/ansible/ansible-{{ version }}.tar.gz -{% endif %} - SHA256: {{ hashes[version] }} -{% endfor %} - - -What's new in {{ version_str }} -{{ '-' * (14 + version_str | length) }} - -{% filter wordwrap %} -{% if plural %}These releases are{% else %}This release is a{% endif %} maintenance release{% if plural %}s{% endif %} containing numerous bugfixes. The full {% if plural %} changelogs are{% else %} changelog is{% endif %} at: -{% endfilter %} - - -{% for version in versions %} -* {{ version }} - https://github.com/ansible/ansible/blob/stable-{{ version.split('.')[:2] | join('.') }}/changelogs/CHANGELOG-v{{ version.split('.')[:2] | join('.') }}.rst -{% endfor %} - - -What's the schedule for future maintenance releases? ----------------------------------------------------- - -{% filter wordwrap %} -Future maintenance releases will occur approximately every 3 weeks. So expect the next one around {{ next_release.strftime('%Y-%m-%d') }}. -{% endfilter %} - - - -Porting Help ------------- - -{% filter wordwrap %} -We've published a porting guide at -https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_{{ latest_ver.split('.')[:2] | join('.') }}.html to help migrate your content to {{ latest_ver.split('.')[:2] | join('.') }}. -{% endfilter %} - - - -{% filter wordwrap %} -If you discover any errors or if any of your working playbooks break when you upgrade to {{ latest_ver }}, please use the following link to report the regression: -{% endfilter %} - - - https://github.com/ansible/ansible/issues/new/choose - -{% filter wordwrap %} -In your issue, be sure to mention the version that works and the one that doesn't. -{% endfilter %} - - -Thanks! - --{{ name }} - -""" # noqa for E501 (line length). -# jinja2 is horrid about getting rid of extra newlines so we have to have a single per paragraph for -# proper wrapping to occur - -SHORT_TEMPLATE = """ -{% set plural = False if versions | length == 1 else True %} -{% set version = (versions|sort(attribute='ver_obj'))[-1] %} -@ansible -{{ version_str }} -{% if plural %} - have -{% else %} - has -{% endif %} -been released! Get -{% if plural %} -them -{% else %} -it -{% endif %} -on PyPI: pip install ansible{% if is_ansible_base(version) %}-base{% endif %}=={{ version }}, -the Ansible PPA on Launchpad, or GitHub. Happy automating! -""" # noqa for E501 (line length). -# jinja2 is horrid about getting rid of extra newlines so we have to have a single per paragraph for -# proper wrapping to occur - -JINJA_ENV = Environment( - loader=DictLoader({'long': LONG_TEMPLATE, - 'short': SHORT_TEMPLATE, - 'version_string': VERSION_FRAGMENT, - }), - extensions=['jinja2.ext.i18n'], - trim_blocks=True, - lstrip_blocks=True, -) - - -async def calculate_hash_from_tarball(session, version): - tar_url = f'https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{version}.tar.gz' - tar_task = asyncio.create_task(session.get(tar_url)) - tar_response = await tar_task - - tar_hash = hashlib.sha256() - while True: - chunk = await tar_response.content.read(1024) - if not chunk: - break - tar_hash.update(chunk) - - return tar_hash.hexdigest() - - -async def parse_hash_from_file(session, version): - filename = f'ansible-base-{version}.tar.gz' - hash_url = f'https://releases.ansible.com/ansible-base/{filename}.sha' - hash_task = asyncio.create_task(session.get(hash_url)) - hash_response = await hash_task - - hash_content = await hash_response.read() - precreated_hash, precreated_filename = hash_content.split(None, 1) - if filename != precreated_filename.strip().decode('utf-8'): - raise ValueError(f'Hash file contains hash for a different file: {precreated_filename}') - - return precreated_hash.decode('utf-8') - - -async def get_hash(session, version): - calculated_hash = await calculate_hash_from_tarball(session, version) - precreated_hash = await parse_hash_from_file(session, version) - - if calculated_hash != precreated_hash: - raise ValueError(f'Hash in file ansible-base-{version}.tar.gz.sha {precreated_hash} does not' - f' match hash of tarball from pypi {calculated_hash}') - - return calculated_hash - - -async def get_hashes(versions): - hashes = {} - requestors = {} - async with aiohttp.ClientSession() as aio_session: - for version in versions: - requestors[version] = asyncio.create_task(get_hash(aio_session, version)) - - for version, request in requestors.items(): - await request - hashes[version] = request.result() - - return hashes - - -def next_release_date(weeks=3): - days_in_the_future = weeks * 7 - today = datetime.datetime.now() - numeric_today = today.weekday() - - # We release on Thursdays - if numeric_today == 3: - # 3 is Thursday - pass - elif numeric_today == 4: - # If this is Friday, we can adjust back to Thursday for the next release - today -= datetime.timedelta(days=1) - elif numeric_today < 3: - # Otherwise, slide forward to Thursday - today += datetime.timedelta(days=(3 - numeric_today)) - else: - # slightly different formula if it's past Thursday this week. We need to go forward to - # Thursday of next week - today += datetime.timedelta(days=(10 - numeric_today)) - - next_release = today + datetime.timedelta(days=days_in_the_future) - return next_release - - -def is_ansible_base(version): - ''' - Determines if a version is an ansible-base version or not, by checking - if it is >= 2.10.0. Stops comparing when it gets to the first non-numeric - component to allow for .dev and .beta suffixes. - ''' - # Ignore .beta/.dev suffixes - ver_split = [] - for component in version.split('.'): - if not component.isdigit(): - if 'rc' in component: - ver_split.append(int(component.split('rc')[0])) - if 'b' in component: - ver_split.append(int(component.split('b')[0])) - continue - ver_split.append(int(component)) - return tuple(ver_split) >= (2, 10, 0) - - -# Currently only use with a single element list, but left general for later -# in case we need to refer to the releases collectively. -def release_variants(versions): - if all(is_ansible_base(v) for v in versions): - return 'ansible-base' - - if all(not is_ansible_base(v) for v in versions): - return 'Ansible' - - return 'Ansible and ansible-base' - - -def pretty_version(version): - return '{0} {1}'.format( - release_variants([version]), - version, - ) - - -def create_long_message(versions, name): - hashes = asyncio.run(get_hashes(versions)) - - version_template = JINJA_ENV.get_template('version_string') - version_str = version_template.render(versions=versions, - pretty_version=pretty_version).strip() - - next_release = next_release_date() - - template = JINJA_ENV.get_template('long') - message = template.render(versions=versions, version_str=version_str, - name=name, hashes=hashes, next_release=next_release, - is_ansible_base=is_ansible_base, - pretty_version=pretty_version) - return message - - -def create_short_message(versions): - version_template = JINJA_ENV.get_template('version_string') - version_str = version_template.render(versions=versions, - pretty_version=pretty_version).strip() - - template = JINJA_ENV.get_template('short') - message = template.render(versions=versions, version_str=version_str, - is_ansible_base=is_ansible_base, - pretty_version=pretty_version) - message = ' '.join(message.split()) + '\n' - return message diff --git a/hacking/build_library/build_ansible/change_detection.py b/hacking/build_library/build_ansible/change_detection.py deleted file mode 100644 index 22e21d3c253..00000000000 --- a/hacking/build_library/build_ansible/change_detection.py +++ /dev/null @@ -1,33 +0,0 @@ -# Copyright: (c) 2018, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -def update_file_if_different(filename, b_data): - """ - Replace file content only if content is different. - - This preserves timestamps in case the file content has not changed. It performs multiple - operations on the file so it is not atomic and may be slower than simply writing to the file. - - :arg filename: The filename to write to - :b_data: Byte string containing the data to write to the file - """ - try: - with open(filename, 'rb') as f: - b_data_old = f.read() - except IOError as e: - if e.errno != 2: - raise - # File did not exist, set b_data_old to a sentinel value so that - # b_data gets written to the filename - b_data_old = None - - if b_data_old != b_data: - with open(filename, 'wb') as f: - f.write(b_data) - return True - - return False diff --git a/hacking/build_library/build_ansible/command_plugins/collection_meta.py b/hacking/build_library/build_ansible/command_plugins/collection_meta.py deleted file mode 100644 index 41b10778516..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/collection_meta.py +++ /dev/null @@ -1,72 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import os -import os.path -import pathlib - -import yaml -from ansible.module_utils.six import string_types -from ansible.module_utils._text import to_bytes -from antsibull_docs.jinja2.environment import doc_environment - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_FILE = 'collections_galaxy_meta.rst.j2' -DEFAULT_TEMPLATE_DIR = pathlib.Path(__file__).parents[4] / 'docs/templates' - - -def normalize_options(options): - """Normalize the options to make for easy templating""" - for opt in options: - if isinstance(opt['description'], string_types): - opt['description'] = [opt['description']] - - -class DocumentCollectionMeta(Command): - name = 'collection-meta' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Generate collection galaxy.yml documentation from shared metadata') - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, - help="Jinja2 template to use for the config") - parser.add_argument("-T", "--template-dir", action="store", dest="template_dir", - default=str(DEFAULT_TEMPLATE_DIR), - help="directory containing Jinja2 templates") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", default='/tmp/', - help="Output directory for rst files") - parser.add_argument("collection_defs", metavar="COLLECTION-OPTION-DEFINITIONS.yml", type=str, - help="Source for collection metadata option docs") - - @staticmethod - def main(args): - output_dir = os.path.abspath(args.output_dir) - template_file_full_path = os.path.abspath(os.path.join(args.template_dir, args.template_file)) - template_file = os.path.basename(template_file_full_path) - template_dir = os.path.dirname(template_file_full_path) - - with open(args.collection_defs) as f: - options = yaml.safe_load(f) - - normalize_options(options) - - env = doc_environment(template_dir) - - template = env.get_template(template_file) - output_name = os.path.join(output_dir, template_file.replace('.j2', '')) - temp_vars = {'options': options} - - data = to_bytes(template.render(temp_vars)) - update_file_if_different(output_name, data) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/docs_build.py b/hacking/build_library/build_ansible/command_plugins/docs_build.py deleted file mode 100644 index 50b0f903f45..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/docs_build.py +++ /dev/null @@ -1,255 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2020, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import absolute_import, division, print_function - -import glob -import os -import os.path -import pathlib -import shutil -from tempfile import TemporaryDirectory - -import yaml - -from ansible.release import __version__ as ansible_core__version__ - -# Pylint doesn't understand Python3 namespace modules. -# pylint: disable=relative-beyond-top-level -from ..commands import Command -from ..errors import InvalidUserInput, MissingUserInput -# pylint: enable=relative-beyond-top-level - - -__metaclass__ = type - - -DEFAULT_TOP_DIR = pathlib.Path(__file__).parents[4] -DEFAULT_OUTPUT_DIR = pathlib.Path(__file__).parents[4] / 'docs/docsite' - - -class NoSuchFile(Exception): - """An expected file was not found.""" - - -# -# Helpers -# - -def find_latest_ansible_dir(build_data_working): - """Find the most recent ansible major version.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - from packaging.version import InvalidVersion, Version - - ansible_directories = glob.glob(os.path.join(build_data_working, '[0-9.]*')) - - # Find the latest ansible version directory - latest = None - latest_ver = Version('0') - for directory_name in (d for d in ansible_directories if os.path.isdir(d)): - try: - new_version = Version(os.path.basename(directory_name)) - except InvalidVersion: - continue - - # For the devel build, we only need ansible.in, so make sure it's there - if not os.path.exists(os.path.join(directory_name, 'ansible.in')): - continue - - if new_version > latest_ver: - latest_ver = new_version - latest = directory_name - - if latest is None: - raise NoSuchFile('Could not find an ansible data directory in {0}'.format(build_data_working)) - - return latest - - -def parse_deps_file(filename): - """Parse an antsibull .deps file.""" - with open(filename, 'r', encoding='utf-8') as f: - contents = f.read() - lines = [c for line in contents.splitlines() if (c := line.strip()) and not c.startswith('#')] - return dict([entry.strip() for entry in line.split(':', 1)] for line in lines) - - -def write_deps_file(filename, deps_data): - """Write an antsibull .deps file.""" - with open(filename, 'w', encoding='utf-8') as f: - for key, value in deps_data.items(): - f.write(f'{key}: {value}\n') - - -def find_latest_deps_file(build_data_working, ansible_version): - """Find the most recent ansible deps file for the given ansible major version.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - from packaging.version import Version - - data_dir = os.path.join(build_data_working, ansible_version) - deps_files = glob.glob(os.path.join(data_dir, '*.deps')) - if not deps_files: - raise Exception('No deps files exist for version {0}'.format(ansible_version)) - - # Find the latest version of the deps file for this major version - latest = None - latest_ver = Version('0') - for filename in deps_files: - deps_data = parse_deps_file(filename) - new_version = Version(deps_data['_ansible_version']) - if new_version > latest_ver: - latest_ver = new_version - latest = filename - - if latest is None: - raise NoSuchFile('Could not find an ansible deps file in {0}'.format(data_dir)) - - return latest - - -# -# Subcommand core -# - -def generate_core_docs(args): - """Regenerate the documentation for all plugins listed in the plugin_to_collection_file.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - from antsibull_docs.cli import antsibull_docs - - with TemporaryDirectory() as tmp_dir: - # - # Construct a deps file with our version of ansible_core in it - # - modified_deps_file = os.path.join(tmp_dir, 'ansible.deps') - - # The _ansible_version doesn't matter since we're only building docs for core - deps_file_contents = {'_ansible_version': ansible_core__version__, - '_ansible_core_version': ansible_core__version__} - - with open(modified_deps_file, 'w') as f: - f.write(yaml.dump(deps_file_contents)) - - # Generate the plugin rst - return antsibull_docs.run(['antsibull-docs', 'stable', '--deps-file', modified_deps_file, - '--ansible-core-source', str(args.top_dir), - '--dest-dir', args.output_dir]) - - # If we make this more than just a driver for antsibull: - # Run other rst generation - # Run sphinx build - - -# -# Subcommand full -# - -def generate_full_docs(args): - """Regenerate the documentation for all plugins listed in the plugin_to_collection_file.""" - # imports here so that they don't cause unnecessary deps for all of the plugins - import sh - from antsibull_docs.cli import antsibull_docs - - with TemporaryDirectory() as tmp_dir: - sh.git(['clone', 'https://github.com/ansible-community/ansible-build-data'], _cwd=tmp_dir) - # If we want to validate that the ansible version and ansible-core branch version match, - # this would be the place to do it. - - build_data_working = os.path.join(tmp_dir, 'ansible-build-data') - if args.ansible_build_data: - build_data_working = args.ansible_build_data - - ansible_version = args.ansible_version - if ansible_version is None: - ansible_version = find_latest_ansible_dir(build_data_working) - params = ['devel', '--pieces-file', os.path.join(ansible_version, 'ansible.in')] - else: - latest_filename = find_latest_deps_file(build_data_working, ansible_version) - - # Make a copy of the deps file so that we can set the ansible-core version we'll use - modified_deps_file = os.path.join(tmp_dir, 'ansible.deps') - shutil.copyfile(latest_filename, modified_deps_file) - - # Put our version of ansible-core into the deps file - deps_data = parse_deps_file(modified_deps_file) - - deps_data['_ansible_core_version'] = ansible_core__version__ - - # antsibull-docs will choke when a key `_python` is found. Remove it to work around - # that until antsibull-docs is fixed. - deps_data.pop('_python', None) - - write_deps_file(modified_deps_file, deps_data) - - params = ['stable', '--deps-file', modified_deps_file] - - # Generate the plugin rst - return antsibull_docs.run(['antsibull-docs'] + params + - ['--ansible-core-source', str(args.top_dir), - '--dest-dir', args.output_dir]) - - # If we make this more than just a driver for antsibull: - # Run other rst generation - # Run sphinx build - - -class CollectionPluginDocs(Command): - name = 'docs-build' - _ACTION_HELP = """Action to perform. - full: Regenerate the rst for the full ansible website. - core: Regenerate the rst for plugins in ansible-core and then build the website. - named: Regenerate the rst for the named plugins and then build the website. - """ - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, - description='Generate documentation for plugins in collections.' - ' Plugins in collections will have a stub file in the normal plugin' - ' documentation location that says the module is in a collection and' - ' point to generated plugin documentation under the collections/' - ' hierarchy.') - # I think we should make the actions a subparser but need to look in git history and see if - # we tried that and changed it for some reason. - parser.add_argument('action', action='store', choices=('full', 'core', 'named'), - default='full', help=cls._ACTION_HELP) - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default=DEFAULT_OUTPUT_DIR, - help="Output directory for generated doc files") - parser.add_argument("-t", "--top-dir", action="store", dest="top_dir", - default=DEFAULT_TOP_DIR, - help="Toplevel directory of this ansible-core checkout or expanded" - " tarball.") - parser.add_argument("-l", "--limit-to-modules", '--limit-to', action="store", - dest="limit_to", default=None, - help="Limit building module documentation to comma-separated list of" - " plugins. Specify non-existing plugin name for no plugins.") - parser.add_argument('--ansible-version', action='store', - dest='ansible_version', default=None, - help='The version of the ansible package to make documentation for.' - ' This only makes sense when used with full.') - parser.add_argument('--ansible-build-data', action='store', - dest='ansible_build_data', default=None, - help='A checkout of the ansible-build-data repo. Useful for' - ' debugging.') - - @staticmethod - def main(args): - # normalize and validate CLI args - - if args.ansible_version and args.action != 'full': - raise InvalidUserInput('--ansible-version is only for use with "full".') - - if not args.output_dir: - args.output_dir = os.path.abspath(str(DEFAULT_OUTPUT_DIR)) - - if args.action == 'full': - return generate_full_docs(args) - - if args.action == 'core': - return generate_core_docs(args) - # args.action == 'named' (Invalid actions are caught by argparse) - raise NotImplementedError('Building docs for specific files is not yet implemented') - - # return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/dump_config.py b/hacking/build_library/build_ansible/command_plugins/dump_config.py deleted file mode 100644 index 33591b47310..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/dump_config.py +++ /dev/null @@ -1,82 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import os -import os.path -import pathlib - -import yaml -from jinja2 import Environment, FileSystemLoader -from ansible.module_utils._text import to_bytes - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_FILE = 'config.rst.j2' -DEFAULT_TEMPLATE_DIR = pathlib.Path(__file__).parents[4] / 'docs/templates' - - -def fix_description(config_options): - '''some descriptions are strings, some are lists. workaround it...''' - - for config_key in list(config_options.keys()): - - # drop internal entries - if config_key.startswith('_'): - del config_options[config_key] - continue - - description = config_options[config_key].get('description', []) - if isinstance(description, list): - desc_list = description - else: - desc_list = [description] - config_options[config_key]['description'] = desc_list - return config_options - - -class DocumentConfig(Command): - name = 'document-config' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Generate module documentation from metadata') - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, - help="Jinja2 template to use for the config") - parser.add_argument("-T", "--template-dir", action="store", dest="template_dir", - default=str(DEFAULT_TEMPLATE_DIR), - help="directory containing Jinja2 templates") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", default='/tmp/', - help="Output directory for rst files") - parser.add_argument("config_defs", metavar="CONFIG-OPTION-DEFINITIONS.yml", type=str, - help="Source for config option docs") - - @staticmethod - def main(args): - output_dir = os.path.abspath(args.output_dir) - template_file_full_path = os.path.abspath(os.path.join(args.template_dir, args.template_file)) - template_file = os.path.basename(template_file_full_path) - template_dir = os.path.dirname(template_file_full_path) - - with open(args.config_defs) as f: - config_options = yaml.safe_load(f) - - config_options = fix_description(config_options) - - env = Environment(loader=FileSystemLoader(template_dir), trim_blocks=True,) - template = env.get_template(template_file) - output_name = os.path.join(output_dir, template_file.replace('.j2', '')) - temp_vars = {'config_options': config_options} - - data = to_bytes(template.render(temp_vars)) - update_file_if_different(output_name, data) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/dump_keywords.py b/hacking/build_library/build_ansible/command_plugins/dump_keywords.py deleted file mode 100644 index e9379317f96..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/dump_keywords.py +++ /dev/null @@ -1,121 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - -import importlib -import os.path -import pathlib -import re -from ansible.module_utils.compat.version import LooseVersion - -import jinja2 -import yaml -from jinja2 import Environment, FileSystemLoader - -from ansible.module_utils._text import to_bytes - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_DIR = str(pathlib.Path(__file__).resolve().parents[4] / 'docs/templates') -TEMPLATE_FILE = 'playbooks_keywords.rst.j2' -PLAYBOOK_CLASS_NAMES = ['Play', 'Role', 'Block', 'Task'] - - -def load_definitions(keyword_definitions_file): - docs = {} - with open(keyword_definitions_file) as f: - docs = yaml.safe_load(f) - - return docs - - -def extract_keywords(keyword_definitions): - pb_keywords = {} - for pb_class_name in PLAYBOOK_CLASS_NAMES: - if pb_class_name == 'Play': - module_name = 'ansible.playbook' - else: - module_name = 'ansible.playbook.{0}'.format(pb_class_name.lower()) - module = importlib.import_module(module_name) - playbook_class = getattr(module, pb_class_name, None) - if playbook_class is None: - raise ImportError("We weren't able to import the module {0}".format(module_name)) - - # Maintain order of the actual class names for our output - # Build up a mapping of playbook classes to the attributes that they hold - pb_keywords[pb_class_name] = {k: v for (k, v) in playbook_class.fattributes.items() - # Filter private attributes as they're not usable in playbooks - if not v.private} - - # pick up definitions if they exist - for keyword in tuple(pb_keywords[pb_class_name]): - if keyword in keyword_definitions: - pb_keywords[pb_class_name][keyword] = keyword_definitions[keyword] - else: - # check if there is an alias, otherwise undocumented - alias = getattr(playbook_class.fattributes.get(keyword), 'alias', None) - if alias and alias in keyword_definitions: - pb_keywords[pb_class_name][alias] = keyword_definitions[alias] - del pb_keywords[pb_class_name][keyword] - else: - pb_keywords[pb_class_name][keyword] = ' UNDOCUMENTED!! ' - - # loop is really with_ for users - if pb_class_name == 'Task': - pb_keywords[pb_class_name]['with_'] = ( - 'The same as ``loop`` but magically adds the output of any lookup plugin to' - ' generate the item list.') - - # local_action is implicit with action - if 'action' in pb_keywords[pb_class_name]: - pb_keywords[pb_class_name]['local_action'] = ('Same as action but also implies' - ' ``delegate_to: localhost``') - - return pb_keywords - - -def generate_page(pb_keywords, template_dir): - env = Environment(loader=FileSystemLoader(template_dir), trim_blocks=True,) - template = env.get_template(TEMPLATE_FILE) - tempvars = {'pb_keywords': pb_keywords, 'playbook_class_names': PLAYBOOK_CLASS_NAMES} - - keyword_page = template.render(tempvars) - if LooseVersion(jinja2.__version__) < LooseVersion('2.10'): - # jinja2 < 2.10's indent filter indents blank lines. Cleanup - keyword_page = re.sub(' +\n', '\n', keyword_page) - - return keyword_page - - -class DocumentKeywords(Command): - name = 'document-keywords' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Generate playbook keyword documentation from' - ' code and descriptions') - parser.add_argument("-T", "--template-dir", action="store", dest="template_dir", - default=DEFAULT_TEMPLATE_DIR, - help="directory containing Jinja2 templates") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default='/tmp/', help="Output directory for rst files") - parser.add_argument("keyword_defs", metavar="KEYWORD-DEFINITIONS.yml", type=str, - help="Source for playbook keyword docs") - - @staticmethod - def main(args): - keyword_definitions = load_definitions(args.keyword_defs) - pb_keywords = extract_keywords(keyword_definitions) - - keyword_page = generate_page(pb_keywords, args.template_dir) - outputname = os.path.join(args.output_dir, TEMPLATE_FILE.replace('.j2', '')) - update_file_if_different(outputname, to_bytes(keyword_page)) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/file_deprecated_issues.py b/hacking/build_library/build_ansible/command_plugins/file_deprecated_issues.py deleted file mode 100644 index 139ecc4d947..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/file_deprecated_issues.py +++ /dev/null @@ -1,153 +0,0 @@ -# -*- coding: utf-8 -*- -# (c) 2017, Matt Martz -# (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import os -import time - -from collections import defaultdict - -from ansible.release import __version__ as ansible_version - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level -from .. import errors # pylint: disable=relative-beyond-top-level - -ANSIBLE_MAJOR_VERSION = '.'.join(ansible_version.split('.')[:2]) - - -def get_token(token_file): - if token_file: - return token_file.read().strip() - - token = os.getenv('GITHUB_TOKEN').strip() - if not token: - raise errors.MissingUserInput( - 'Please provide a file containing a github oauth token with public_repo scope' - ' via the --github-token argument or set the GITHUB_TOKEN env var with your' - ' github oauth token' - ) - return token - - -def parse_deprecations(problems_file_handle): - deprecated = defaultdict(list) - deprecation_errors = problems_file_handle.read() - for line in deprecation_errors.splitlines(): - path = line.split(':')[0] - if path.endswith('__init__.py'): - component = os.path.basename(os.path.dirname(path)) - else: - component, dummy = os.path.splitext(os.path.basename(path).lstrip('_')) - - title = ( - '%s contains deprecated call to be removed in %s' % - (component, ANSIBLE_MAJOR_VERSION) - ) - deprecated[component].append( - dict(title=title, path=path, line=line) - ) - return deprecated - - -def find_project_todo_column(repo, project_name): - project = None - for project in repo.projects(): - if project.name.lower() == project_name: - break - else: - raise errors.InvalidUserInput('%s was an invalid project name' % project_name) - - for project_column in project.columns(): - column_name = project_column.name.lower() - if 'todo' in column_name or 'backlog' in column_name or 'to do' in column_name: - return project_column - - raise Exception('Unable to determine the todo column in' - ' project %s' % project_name) - - -def create_issues(deprecated, body_tmpl, repo): - issues = [] - - for component, items in deprecated.items(): - title = items[0]['title'] - path = '\n'.join(set((i['path']) for i in items)) - line = '\n'.join(i['line'] for i in items) - body = body_tmpl % dict(component=component, path=path, - line=line, - version=ANSIBLE_MAJOR_VERSION) - - issue = repo.create_issue(title, body=body, labels=['deprecated']) - print(issue) - issues.append(issue) - - # Sleep a little, so that the API doesn't block us - time.sleep(0.5) - - return issues - - -class FileDeprecationTickets(Command): - name = 'file-deprecation-tickets' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='File tickets to cleanup deprecated features for' - ' the next release') - parser.add_argument('--template', default='deprecated_issue_template.md', - type=argparse.FileType('r'), - help='Path to markdown file template to be used for issue ' - 'body. Default: %(default)s') - parser.add_argument('--project-name', default='', type=str, - help='Name of a github project to assign all issues to') - parser.add_argument('--github-token', type=argparse.FileType('r'), - help='Path to file containing a github token with public_repo scope.' - ' This token in this file will be used to open the deprcation' - ' tickets and add them to the github project. If not given,' - ' the GITHUB_TOKEN environment variable will be tried') - parser.add_argument('problems', type=argparse.FileType('r'), - help='Path to file containing pylint output for the ' - 'ansible-deprecated-version check') - - @staticmethod - def main(args): - try: - from github3 import GitHub - except ImportError: - raise errors.DependencyError( - 'This command needs the github3.py library installed to work' - ) - - token = get_token(args.github_token) - args.github_token.close() - - deprecated = parse_deprecations(args.problems) - args.problems.close() - - body_tmpl = args.template.read() - args.template.close() - - project_name = args.project_name.strip().lower() - - gh_conn = GitHub(token=token) - repo = gh_conn.repository('abadger', 'ansible') - - if project_name: - project_column = find_project_todo_column(repo, project_name) - - issues = create_issues(deprecated, body_tmpl, repo) - - if project_column: - for issue in issues: - project_column.create_card_with_issue(issue) - time.sleep(0.5) - - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/generate_man.py b/hacking/build_library/build_ansible/command_plugins/generate_man.py deleted file mode 100644 index a155b28f9b8..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/generate_man.py +++ /dev/null @@ -1,302 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import os.path -import pathlib -import sys - -from jinja2 import Environment, FileSystemLoader - -from ansible.module_utils._text import to_bytes - -# Pylint doesn't understand Python3 namespace modules. -from ..change_detection import update_file_if_different # pylint: disable=relative-beyond-top-level -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -DEFAULT_TEMPLATE_FILE = pathlib.Path(__file__).parents[4] / 'hacking/templates/man.j2' - - -# from https://www.python.org/dev/peps/pep-0257/ -def trim_docstring(docstring): - if not docstring: - return '' - # Convert tabs to spaces (following the normal Python rules) - # and split into a list of lines: - lines = docstring.expandtabs().splitlines() - # Determine minimum indentation (first line doesn't count): - indent = sys.maxsize - for line in lines[1:]: - stripped = line.lstrip() - if stripped: - indent = min(indent, len(line) - len(stripped)) - # Remove indentation (first line is special): - trimmed = [lines[0].strip()] - if indent < sys.maxsize: - for line in lines[1:]: - trimmed.append(line[indent:].rstrip()) - # Strip off trailing and leading blank lines: - while trimmed and not trimmed[-1]: - trimmed.pop() - while trimmed and not trimmed[0]: - trimmed.pop(0) - # Return a single string: - return '\n'.join(trimmed) - - -def get_options(optlist): - ''' get actual options ''' - - opts = [] - for opt in optlist: - res = { - 'desc': opt.help, - 'options': opt.option_strings - } - if isinstance(opt, argparse._StoreAction): - res['arg'] = opt.dest.upper() - elif not res['options']: - continue - opts.append(res) - - return opts - - -def dedupe_groups(parser): - action_groups = [] - for action_group in parser._action_groups: - found = False - for a in action_groups: - if a._actions == action_group._actions: - found = True - break - if not found: - action_groups.append(action_group) - return action_groups - - -def get_option_groups(option_parser): - groups = [] - for action_group in dedupe_groups(option_parser)[1:]: - group_info = {} - group_info['desc'] = action_group.description - group_info['options'] = action_group._actions - group_info['group_obj'] = action_group - groups.append(group_info) - return groups - - -def opt_doc_list(parser): - ''' iterate over options lists ''' - - results = [] - for option_group in dedupe_groups(parser)[1:]: - results.extend(get_options(option_group._actions)) - - results.extend(get_options(parser._actions)) - - return results - - -# def opts_docs(cli, name): -def opts_docs(cli_class_name, cli_module_name): - ''' generate doc structure from options ''' - - cli_name = 'ansible-%s' % cli_module_name - if cli_module_name == 'adhoc': - cli_name = 'ansible' - - # WIth no action/subcommand - # shared opts set - # instantiate each cli and ask its options - cli_klass = getattr(__import__("ansible.cli.%s" % cli_module_name, - fromlist=[cli_class_name]), cli_class_name) - cli = cli_klass([cli_name]) - - # parse the common options - try: - cli.init_parser() - except Exception: - pass - - # base/common cli info - cli_options = opt_doc_list(cli.parser) - docs = { - 'cli': cli_module_name, - 'cli_name': cli_name, - 'usage': cli.parser.format_usage(), - 'short_desc': cli.parser.description, - 'long_desc': trim_docstring(cli.__doc__), - 'actions': {}, - 'content_depth': 2, - 'options': cli_options, - 'arguments': getattr(cli, 'ARGUMENTS', None), - } - option_info = {'option_names': [], - 'options': cli_options, - 'groups': []} - - groups_info = get_option_groups(cli.parser) - shared_opt_names = [] - for opt in cli_options: - shared_opt_names.extend(opt.get('options', [])) - - option_info['option_names'] = shared_opt_names - - option_info['groups'].extend(groups_info) - - docs.update(option_info) - - # now for each action/subcommand - # force populate parser with per action options - - def get_actions(parser, docs): - # use class attrs not the attrs on a instance (not that it matters here...) - try: - subparser = parser._subparsers._group_actions[0].choices - except AttributeError: - subparser = {} - - depth = 0 - - for action, parser in subparser.items(): - action_info = {'option_names': [], - 'options': [], - 'actions': {}} - # docs['actions'][action] = {} - # docs['actions'][action]['name'] = action - action_info['name'] = action - action_info['desc'] = trim_docstring(getattr(cli, 'execute_%s' % action).__doc__) - - # docs['actions'][action]['desc'] = getattr(cli, 'execute_%s' % action).__doc__.strip() - action_doc_list = opt_doc_list(parser) - - uncommon_options = [] - for action_doc in action_doc_list: - # uncommon_options = [] - - option_aliases = action_doc.get('options', []) - for option_alias in option_aliases: - - if option_alias in shared_opt_names: - continue - - # TODO: use set - if option_alias not in action_info['option_names']: - action_info['option_names'].append(option_alias) - - if action_doc in action_info['options']: - continue - - uncommon_options.append(action_doc) - - action_info['options'] = uncommon_options - - depth = 1 + get_actions(parser, action_info) - - docs['actions'][action] = action_info - - return depth - - action_depth = get_actions(cli.parser, docs) - docs['content_depth'] = action_depth + 1 - - return docs - - -class GenerateMan(Command): - name = 'generate-man' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(name=cls.name, - description='Generate cli documentation from cli docstrings') - - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, help="path to jinja2 template") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default='/tmp/', help="Output directory for rst files") - parser.add_argument("-f", "--output-format", action="store", dest="output_format", - default='man', - help="Output format for docs (the default 'man' or 'rst')") - parser.add_argument('cli_modules', help='CLI module name(s)', metavar='MODULE_NAME', nargs='*') - - @staticmethod - def main(args): - template_file = args.template_file - template_path = os.path.expanduser(template_file) - template_dir = os.path.abspath(os.path.dirname(template_path)) - template_basename = os.path.basename(template_file) - - output_dir = os.path.abspath(args.output_dir) - output_format = args.output_format - - cli_modules = args.cli_modules - - # various cli parsing things checks sys.argv if the 'args' that are passed in are [] - # so just remove any args so the cli modules dont try to parse them resulting in warnings - sys.argv = [sys.argv[0]] - - allvars = {} - output = {} - cli_list = [] - cli_bin_name_list = [] - - # for binary in os.listdir('../../lib/ansible/cli'): - for cli_module_name in cli_modules: - binary = os.path.basename(os.path.expanduser(cli_module_name)) - - if not binary.endswith('.py'): - continue - elif binary == '__init__.py': - continue - - cli_name = os.path.splitext(binary)[0] - - if cli_name == 'adhoc': - cli_class_name = 'AdHocCLI' - # myclass = 'AdHocCLI' - output[cli_name] = 'ansible.1.rst.in' - cli_bin_name = 'ansible' - else: - # myclass = "%sCLI" % libname.capitalize() - cli_class_name = "%sCLI" % cli_name.capitalize() - output[cli_name] = 'ansible-%s.1.rst.in' % cli_name - cli_bin_name = 'ansible-%s' % cli_name - - # FIXME: - allvars[cli_name] = opts_docs(cli_class_name, cli_name) - cli_bin_name_list.append(cli_bin_name) - - cli_list = allvars.keys() - - doc_name_formats = {'man': '%s.1.rst.in', - 'rst': '%s.rst'} - - for cli_name in cli_list: - - # template it! - env = Environment(loader=FileSystemLoader(template_dir)) - template = env.get_template(template_basename) - - # add rest to vars - tvars = allvars[cli_name] - tvars['cli_bin_name_list'] = cli_bin_name_list - tvars['cli'] = cli_name - if '-i' in tvars['option_names']: - tvars['inventory'] = True - print('uses inventory') - if '-M' in tvars['option_names']: - tvars['library'] = True - print('uses library') - - manpage = template.render(tvars) - filename = os.path.join(output_dir, doc_name_formats[output_format] % tvars['cli_name']) - update_file_if_different(filename, to_bytes(manpage)) diff --git a/hacking/build_library/build_ansible/command_plugins/porting_guide.py b/hacking/build_library/build_ansible/command_plugins/porting_guide.py deleted file mode 100644 index 431485b153c..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/porting_guide.py +++ /dev/null @@ -1,138 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -from jinja2 import Environment, DictLoader - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level - - -PORTING_GUIDE_TEMPLATE = """ -.. _porting_{{ ver }}_guide_core: - -******************************* -Ansible-core {{ ver }} Porting Guide -******************************* - -This section discusses the behavioral changes between ``ansible-core`` {{ prev_ver }} and ``ansible-core`` {{ ver }}. - -It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible. - -We suggest you read this page along with `ansible-core Changelog for {{ ver }} `_ to understand what updates you may need to make. - -This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides `. - -.. contents:: Topics - - -Playbook -======== - -No notable changes - - -Command Line -============ - -No notable changes - - -Deprecated -========== - -No notable changes - - -Modules -======= - -No notable changes - - -Modules removed ---------------- - -The following modules no longer exist: - -* No notable changes - - -Deprecation notices -------------------- - -No notable changes - - -Noteworthy module changes -------------------------- - -No notable changes - - -Plugins -======= - -No notable changes - - -Porting custom scripts -====================== - -No notable changes - - -Networking -========== - -No notable changes - -""" # noqa for E501 (line length). -# jinja2 is horrid about getting rid of extra newlines so we have to have a single line per -# paragraph for proper wrapping to occur - -JINJA_ENV = Environment( - loader=DictLoader({'porting_guide': PORTING_GUIDE_TEMPLATE, - }), - extensions=['jinja2.ext.i18n'], - trim_blocks=True, - lstrip_blocks=True, -) - - -def generate_porting_guide(version): - template = JINJA_ENV.get_template('porting_guide') - - version_list = version.split('.') - version_list[-1] = str(int(version_list[-1]) - 1) - previous_version = '.'.join(version_list) - - content = template.render(ver=version, prev_ver=previous_version) - return content - - -def write_guide(version, guide_content): - filename = 'docs/docsite/rst/porting_guides/porting_guide_core_{0}.rst'.format(version) - with open(filename, 'w') as out_file: - out_file.write(guide_content) - - -class PortingGuideCommand(Command): - name = 'porting-guide' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description="Generate a fresh porting guide template") - parser.add_argument("--version", dest="version", type=str, required=True, action='store', - help="Version of Ansible to write the porting guide for") - - @staticmethod - def main(args): - guide_content = generate_porting_guide(args.version) - write_guide(args.version, guide_content) - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/release_announcement.py b/hacking/build_library/build_ansible/command_plugins/release_announcement.py deleted file mode 100644 index edc928a0ec9..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/release_announcement.py +++ /dev/null @@ -1,78 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import sys -from collections import UserString -from ansible.module_utils.compat.version import LooseVersion - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level -from .. import errors # pylint: disable=relative-beyond-top-level - - -class VersionStr(UserString): - def __init__(self, string): - super().__init__(string.strip()) - self.ver_obj = LooseVersion(string) - - -def transform_args(args): - # Make it possible to sort versions in the jinja2 templates - new_versions = [] - for version in args.versions: - new_versions.append(VersionStr(version)) - args.versions = new_versions - - return args - - -def write_message(filename, message): - if filename != '-': - with open(filename, 'w') as out_file: - out_file.write(message) - else: - sys.stdout.write('\n\n') - sys.stdout.write(message) - - -class ReleaseAnnouncementCommand(Command): - name = 'release-announcement' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, - description="Generate email and twitter announcements from template") - - parser.add_argument("--version", dest="versions", type=str, required=True, action='append', - help="Versions of Ansible to announce") - parser.add_argument("--name", type=str, required=True, help="Real name to use on emails") - parser.add_argument("--email-out", type=str, default="-", - help="Filename to place the email announcement into") - parser.add_argument("--twitter-out", type=str, default="-", - help="Filename to place the twitter announcement into") - - @classmethod - def main(cls, args): - if sys.version_info < (3, 6): - raise errors.DependencyError('The {0} subcommand needs Python-3.6+' - ' to run'.format(cls.name)) - - # Import here because these functions are invalid on Python-3.5 and the command plugins and - # init_parser() method need to be compatible with Python-3.4+ for now. - # Pylint doesn't understand Python3 namespace modules. - from .. announce import create_short_message, create_long_message # pylint: disable=relative-beyond-top-level - - args = transform_args(args) - - twitter_message = create_short_message(args.versions) - email_message = create_long_message(args.versions, args.name) - - write_message(args.twitter_out, twitter_message) - write_message(args.email_out, email_message) - return 0 diff --git a/hacking/build_library/build_ansible/command_plugins/update_intersphinx.py b/hacking/build_library/build_ansible/command_plugins/update_intersphinx.py deleted file mode 100644 index 9337859f325..00000000000 --- a/hacking/build_library/build_ansible/command_plugins/update_intersphinx.py +++ /dev/null @@ -1,101 +0,0 @@ -# -*- coding: utf-8 -*- -# (c) 2020, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import importlib -import os -import pathlib -import time -import urllib.parse - -from collections import defaultdict - -from ansible.module_utils.common.collections import is_iterable -from ansible.module_utils.urls import Request - -# Pylint doesn't understand Python3 namespace modules. -from ..commands import Command # pylint: disable=relative-beyond-top-level -from .. import errors # pylint: disable=relative-beyond-top-level - - -EXAMPLE_CONF = """ -A proper intersphinx_mapping entry should look like: - intersphinx_mapping = { - 'python3': ('https://docs.python.org/3', (None, 'python3.inv')) - } - -See the intersphinx docs for more info: - https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_mapping -""" - - -class UpdateIntersphinxCache(Command): - name = 'update-intersphinx-cache' - - @classmethod - def init_parser(cls, add_parser): - parser = add_parser(cls.name, description='Update cached intersphinx mappings. This' - ' updates the cached intersphinx mappings for docs to reference' - ' documentation from other projects.') - parser.add_argument('-o', '--output-dir', action='store', - help='Path to directory the cached objects.inv files are stored in') - parser.add_argument('-c', '--conf-file', action='store', - help='Path to a sphinx config file to retrieve intersphinx config from') - - @staticmethod - def main(args): - # Retrieve the intersphinx information from the sphinx config file - conf_dir = pathlib.Path(args.conf_file).parent - - conf_module_spec = importlib.util.spec_from_file_location('sphinxconf', args.conf_file) - conf_module = importlib.util.module_from_spec(conf_module_spec) - conf_module_spec.loader.exec_module(conf_module) - intersphinx_mapping = conf_module.intersphinx_mapping - - for intersphinx_name, inventory in intersphinx_mapping.items(): - if not is_iterable(inventory) or len(inventory) != 2: - print('WARNING: The intersphinx entry for {0} must be' - ' a two-tuple.\n{1}'.format(intersphinx_name, EXAMPLE_CONF)) - continue - - url = cache_file = None - for inv_source in inventory: - if isinstance(inv_source, str) and url is None: - url = inv_source - elif is_iterable(inv_source) and cache_file is None: - if len(inv_source) != 2: - print('WARNING: The fallback entry for {0} should be a tuple of (None,' - ' filename).\n{1}'.format(intersphinx_name, EXAMPLE_CONF)) - continue - cache_file = inv_source[1] - else: - print('WARNING: The configuration for {0} should be a tuple of one url and one' - ' tuple for a fallback filename.\n{1}'.format(intersphinx_name, - EXAMPLE_CONF)) - continue - - if url is None or cache_file is None: - print('WARNING: Could not figure out the url or fallback' - ' filename for {0}.\n{1}'.format(intersphinx_name, EXAMPLE_CONF)) - continue - - url = urllib.parse.urljoin(url, 'objects.inv') - # Resolve any relative cache files to be relative to the conf file - cache_file = conf_dir / cache_file - - # Retrieve the inventory and cache it - # The jinja CDN seems to be blocking the default urllib User-Agent - requestor = Request(headers={'User-Agent': 'Definitely Not Python ;-)'}) - with requestor.open('GET', url) as source_file: - with open(cache_file, 'wb') as f: - f.write(source_file.read()) - - print('Download of new cache files complete. Remember to git commit -a the changes') - - return 0 diff --git a/hacking/build_library/build_ansible/commands.py b/hacking/build_library/build_ansible/commands.py deleted file mode 100644 index 826799349e5..00000000000 --- a/hacking/build_library/build_ansible/commands.py +++ /dev/null @@ -1,50 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -from abc import ABCMeta, abstractmethod, abstractproperty - - -class Command(metaclass=ABCMeta): - """ - Subcommands of :program:`build-ansible.py`. - - This defines an interface that all subcommands must conform to. :program:`build-ansible.py` - will require that these things are present in order to proceed. - """ - @staticmethod - @abstractproperty - def name(): - """Name of the subcommand. It's the string to invoked it via on the command line""" - - @staticmethod - @abstractmethod - def init_parser(add_parser): - """ - Initialize and register an argparse ArgumentParser - - :arg add_parser: function which creates an ArgumentParser for the main program. - - Implementations should first create an ArgumentParser using `add_parser` and then populate - it with the command line arguments that are needed. - - .. seealso: - `add_parser` information in the :py:meth:`ArgumentParser.add_subparsers` documentation. - """ - - @staticmethod - @abstractmethod - def main(arguments): - """ - Run the command - - :arg arguments: The **parsed** command line args - - This is the Command's entrypoint. The command line args are already parsed but from here - on, the command can do its work. - """ diff --git a/hacking/build_library/build_ansible/errors.py b/hacking/build_library/build_ansible/errors.py deleted file mode 100644 index a53d1fb1c8e..00000000000 --- a/hacking/build_library/build_ansible/errors.py +++ /dev/null @@ -1,19 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -class DependencyError(Exception): - """A dependency was unmet""" - - -class MissingUserInput(Exception): - """The user failed to provide input (via cli arg or interactively""" - - -class InvalidUserInput(Exception): - """The user provided invalid input""" diff --git a/hacking/templates/man.j2 b/hacking/templates/man.j2 deleted file mode 100644 index 8bd3644cbd5..00000000000 --- a/hacking/templates/man.j2 +++ /dev/null @@ -1,128 +0,0 @@ -{% set name = ('ansible' if cli == 'adhoc' else 'ansible-%s' % cli) -%} -{{name}} -{{ '=' * ( name|length|int ) }} - -{{ '-' * ( short_desc|default('')|string|length|int ) }} -{{short_desc|default('')}} -{{ '-' * ( short_desc|default('')|string|length|int ) }} - -:Version: Ansible %VERSION% -:Manual section: 1 -:Manual group: System administration commands - - - -SYNOPSIS --------- -{{ usage|replace('%prog', name) }} - - -DESCRIPTION ------------ -{{ long_desc|default('', True)|wordwrap }} - -{% if options %} -COMMON OPTIONS --------------- -{% for option in options|sort(attribute='options') %} -{% for switch in option['options'] %}**{{switch}}**{% if option['arg'] %} '{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ option['desc'] }} -{% endfor %} -{% endif %} - -{% if arguments %} -ARGUMENTS ---------- - -{% for arg in arguments %} -{{ arg }} - -{{ (arguments[arg]|default(' '))|wordwrap }} - -{% endfor %} -{% endif %} - -{% if actions %} -ACTIONS -------- -{% for action in actions %} -**{{ action }}** - {{ (actions[action]['desc']|default(' ')) |replace('\n', ' ')}} - -{% if actions[action]['options'] %} -{% for option in actions[action]['options']|sort(attribute='options') %} -{% for switch in option['options'] if switch in actions[action]['option_names'] %} **{{switch}}**{% if option['arg'] %} '{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ (option['desc']) }} -{% endfor %} -{% endif %} -{% endfor %} -{% endif %} - - -{% if inventory %} -INVENTORY ---------- - -Ansible stores the hosts it can potentially operate on in an inventory. -This can be an YAML file, ini-like file, a script, directory, list, etc. -For additional options, see the documentation on https://docs.ansible.com/. - -{% endif %} -ENVIRONMENT ------------ - -The following environment variables may be specified. - -{% if inventory %} -ANSIBLE_INVENTORY -- Override the default ansible inventory sources - -{% endif %} -{% if library %} -ANSIBLE_LIBRARY -- Override the default ansible module library path - -{% endif %} -ANSIBLE_CONFIG -- Specify override location for the ansible config file - -Many more are available for most options in ansible.cfg - -For a full list check https://docs.ansible.com/. or use the `ansible-config` command. - -FILES ------ - -{% if inventory %} -/etc/ansible/hosts -- Default inventory file - -{% endif %} -/etc/ansible/ansible.cfg -- Config file, used if present - -~/.ansible.cfg -- User config file, overrides the default config if present - -./ansible.cfg -- Local config file (in current working directory) assumed to be 'project specific' and overrides the rest if present. - -As mentioned above, the ANSIBLE_CONFIG environment variable will override all others. - -AUTHOR ------- - -Ansible was originally written by Michael DeHaan. - - -COPYRIGHT ---------- - -Copyright © 2018 Red Hat, Inc | Ansible. -Ansible is released under the terms of the GPLv3 license. - - -SEE ALSO --------- - -{% for other in cli_list|sort %}{% if other != cli %}**ansible{% if other != 'adhoc' %}-{{other}}{% endif %}** (1){% if not loop.last %}, {% endif %}{% endif %}{% endfor %} - -Extensive documentation is available in the documentation site: -. -IRC and mailing list info can be found in file CONTRIBUTING.md, -available in: diff --git a/hacking/update-sanity-requirements.py b/hacking/update-sanity-requirements.py index 34a5f102f89..5861590beaf 100755 --- a/hacking/update-sanity-requirements.py +++ b/hacking/update-sanity-requirements.py @@ -49,7 +49,19 @@ class SanityTest: subprocess.run(pip + ['install', 'wheel'], env=env, check=True) # make bdist_wheel available during pip install subprocess.run(pip + ['install', '-r', self.source_path], env=env, check=True) - pip_freeze = subprocess.run(pip + ['freeze'], env=env, check=True, capture_output=True, text=True) + keep_setuptools = any(line.startswith('setuptools ') for line in self.source_path.read_text().splitlines()) + + exclude_packages = ['pip', 'distribute', 'wheel'] + + if not keep_setuptools: + exclude_packages.append('setuptools') + + freeze_options = ['--all'] + + for exclude_package in exclude_packages: + freeze_options.extend(('--exclude', exclude_package)) + + pip_freeze = subprocess.run(pip + ['freeze'] + freeze_options, env=env, check=True, capture_output=True, text=True) self.write_requirements(pip_freeze.stdout) diff --git a/packaging/cli-doc/build.py b/packaging/cli-doc/build.py new file mode 100755 index 00000000000..878ba8eabf5 --- /dev/null +++ b/packaging/cli-doc/build.py @@ -0,0 +1,279 @@ +#!/usr/bin/env python +# PYTHON_ARGCOMPLETE_OK +"""Build documentation for ansible-core CLI programs.""" + +from __future__ import annotations + +import argparse +import dataclasses +import importlib +import inspect +import io +import itertools +import json +import pathlib +import sys +import typing as t +import warnings + +import jinja2 + +if t.TYPE_CHECKING: + from ansible.cli import CLI # pragma: nocover + +SCRIPT_DIR = pathlib.Path(__file__).resolve().parent +SOURCE_DIR = SCRIPT_DIR.parent.parent + + +def main() -> None: + """Main program entry point.""" + parser = argparse.ArgumentParser(description=__doc__) + subparsers = parser.add_subparsers(required=True, metavar='command') + + man_parser = subparsers.add_parser('man', description=build_man.__doc__, help=build_man.__doc__) + man_parser.add_argument('--output-dir', required=True, type=pathlib.Path, metavar='DIR', help='output directory') + man_parser.add_argument('--template-file', default=SCRIPT_DIR / 'man.j2', type=pathlib.Path, metavar='FILE', help='template file') + man_parser.set_defaults(func=build_man) + + rst_parser = subparsers.add_parser('rst', description=build_rst.__doc__, help=build_rst.__doc__) + rst_parser.add_argument('--output-dir', required=True, type=pathlib.Path, metavar='DIR', help='output directory') + rst_parser.add_argument('--template-file', default=SCRIPT_DIR / 'rst.j2', type=pathlib.Path, metavar='FILE', help='template file') + rst_parser.set_defaults(func=build_rst) + + json_parser = subparsers.add_parser('json', description=build_json.__doc__, help=build_json.__doc__) + json_parser.add_argument('--output-file', required=True, type=pathlib.Path, metavar='FILE', help='output file') + json_parser.set_defaults(func=build_json) + + try: + # noinspection PyUnresolvedReferences + import argcomplete + except ImportError: + pass + else: + argcomplete.autocomplete(parser) + + args = parser.parse_args() + kwargs = {name: getattr(args, name) for name in inspect.signature(args.func).parameters} + + sys.path.insert(0, str(SOURCE_DIR / 'lib')) + + args.func(**kwargs) + + +def build_man(output_dir: pathlib.Path, template_file: pathlib.Path) -> None: + """Build man pages for ansible-core CLI programs.""" + if not template_file.resolve().is_relative_to(SCRIPT_DIR): + warnings.warn("Custom templates are intended for debugging purposes only. The data model may change in future releases without notice.") + + import docutils.core + import docutils.writers.manpage + + output_dir.mkdir(exist_ok=True, parents=True) + + for cli_name, source in generate_rst(template_file).items(): + with io.StringIO(source) as source_file: + docutils.core.publish_file( + source=source_file, + destination_path=output_dir / f'{cli_name}.1', + writer=docutils.writers.manpage.Writer(), + ) + + +def build_rst(output_dir: pathlib.Path, template_file: pathlib.Path) -> None: + """Build RST documentation for ansible-core CLI programs.""" + if not template_file.resolve().is_relative_to(SCRIPT_DIR): + warnings.warn("Custom templates are intended for debugging purposes only. The data model may change in future releases without notice.") + + output_dir.mkdir(exist_ok=True, parents=True) + + for cli_name, source in generate_rst(template_file).items(): + (output_dir / f'{cli_name}.rst').write_text(source) + + +def build_json(output_file: pathlib.Path) -> None: + """Build JSON documentation for ansible-core CLI programs.""" + warnings.warn("JSON output is intended for debugging purposes only. The data model may change in future releases without notice.") + + output_file.parent.mkdir(exist_ok=True, parents=True) + output_file.write_text(json.dumps(collect_programs(), indent=4)) + + +def generate_rst(template_file: pathlib.Path) -> dict[str, str]: + """Generate RST pages using the provided template.""" + results: dict[str, str] = {} + + for cli_name, template_vars in collect_programs().items(): + env = jinja2.Environment(loader=jinja2.FileSystemLoader(template_file.parent)) + template = env.get_template(template_file.name) + results[cli_name] = template.render(template_vars) + + return results + + +def collect_programs() -> dict[str, dict[str, t.Any]]: + """Return information about CLI programs.""" + programs: list[tuple[str, dict[str, t.Any]]] = [] + cli_bin_name_list: list[str] = [] + + for source_file in (SOURCE_DIR / 'lib/ansible/cli').glob('*.py'): + if source_file.name != '__init__.py': + programs.append(generate_options_docs(source_file, cli_bin_name_list)) + + return dict(programs) + + +def generate_options_docs(source_file: pathlib.Path, cli_bin_name_list: list[str]) -> tuple[str, dict[str, t.Any]]: + """Generate doc structure from CLI module options.""" + import ansible.release + + if str(source_file).endswith('/lib/ansible/cli/adhoc.py'): + cli_name = 'ansible' + cli_class_name = 'AdHocCLI' + cli_module_fqn = 'ansible.cli.adhoc' + else: + cli_module_name = source_file.with_suffix('').name + cli_name = f'ansible-{cli_module_name}' + cli_class_name = f'{cli_module_name.capitalize()}CLI' + cli_module_fqn = f'ansible.cli.{cli_module_name}' + + cli_bin_name_list.append(cli_name) + + cli_module = importlib.import_module(cli_module_fqn) + cli_class: type[CLI] = getattr(cli_module, cli_class_name) + + cli = cli_class([cli_name]) + cli.init_parser() + + parser: argparse.ArgumentParser = cli.parser + long_desc = cli.__doc__ + arguments: dict[str, str] | None = getattr(cli, 'ARGUMENTS', None) + + action_docs = get_action_docs(parser) + option_names: tuple[str, ...] = tuple(itertools.chain.from_iterable(opt.options for opt in action_docs)) + actions: dict[str, dict[str, t.Any]] = {} + + content_depth = populate_subparser_actions(parser, option_names, actions) + + docs = dict( + version=ansible.release.__version__, + source=str(source_file.relative_to(SOURCE_DIR)), + cli_name=cli_name, + usage=parser.format_usage(), + short_desc=parser.description, + long_desc=trim_docstring(long_desc), + actions=actions, + options=[item.__dict__ for item in action_docs], + arguments=arguments, + option_names=option_names, + cli_bin_name_list=cli_bin_name_list, + content_depth=content_depth, + inventory='-i' in option_names, + library='-M' in option_names, + ) + + return cli_name, docs + + +def populate_subparser_actions(parser: argparse.ArgumentParser, shared_option_names: tuple[str, ...], actions: dict[str, dict[str, t.Any]]) -> int: + """Generate doc structure from CLI module subparser options.""" + try: + # noinspection PyProtectedMember + subparsers: dict[str, argparse.ArgumentParser] = parser._subparsers._group_actions[0].choices # type: ignore + except AttributeError: + subparsers = {} + + depth = 0 + + for subparser_action, subparser in subparsers.items(): + subparser_option_names: set[str] = set() + subparser_action_docs: set[ActionDoc] = set() + subparser_actions: dict[str, dict[str, t.Any]] = {} + + for action_doc in get_action_docs(subparser): + for option_alias in action_doc.options: + if option_alias in shared_option_names: + continue + + subparser_option_names.add(option_alias) + subparser_action_docs.add(action_doc) + + depth = populate_subparser_actions(subparser, shared_option_names, subparser_actions) + + actions[subparser_action] = dict( + option_names=list(subparser_option_names), + options=[item.__dict__ for item in subparser_action_docs], + actions=subparser_actions, + name=subparser_action, + desc=trim_docstring(subparser.get_default("func").__doc__), + ) + + return depth + 1 + + +@dataclasses.dataclass(frozen=True) +class ActionDoc: + """Documentation for an action.""" + desc: str | None + options: tuple[str, ...] + arg: str | None + + +def get_action_docs(parser: argparse.ArgumentParser) -> list[ActionDoc]: + """Get action documentation from the given argument parser.""" + action_docs = [] + + # noinspection PyProtectedMember + for action in parser._actions: + if action.help == argparse.SUPPRESS: + continue + + # noinspection PyProtectedMember, PyUnresolvedReferences + args = action.dest.upper() if isinstance(action, argparse._StoreAction) else None + + if args or action.option_strings: + action_docs.append(ActionDoc( + desc=action.help, + options=tuple(action.option_strings), + arg=args, + )) + + return action_docs + + +def trim_docstring(docstring: str | None) -> str: + """Trim and return the given docstring using the implementation from https://peps.python.org/pep-0257/#handling-docstring-indentation.""" + if not docstring: + return '' # pragma: nocover + + # Convert tabs to spaces (following the normal Python rules) and split into a list of lines + lines = docstring.expandtabs().splitlines() + + # Determine minimum indentation (first line doesn't count) + indent = sys.maxsize + + for line in lines[1:]: + stripped = line.lstrip() + + if stripped: + indent = min(indent, len(line) - len(stripped)) + + # Remove indentation (first line is special) + trimmed = [lines[0].strip()] + + if indent < sys.maxsize: + for line in lines[1:]: + trimmed.append(line[indent:].rstrip()) + + # Strip off trailing and leading blank lines + while trimmed and not trimmed[-1]: + trimmed.pop() + + while trimmed and not trimmed[0]: + trimmed.pop(0) + + # Return a single string + return '\n'.join(trimmed) + + +if __name__ == '__main__': + main() diff --git a/packaging/pep517_backend/_templates/man.j2 b/packaging/cli-doc/man.j2 similarity index 98% rename from packaging/pep517_backend/_templates/man.j2 rename to packaging/cli-doc/man.j2 index e159ba1a56c..adb80936957 100644 --- a/packaging/pep517_backend/_templates/man.j2 +++ b/packaging/cli-doc/man.j2 @@ -26,7 +26,7 @@ {{short_desc|default('')}} {{ '-' * ( short_desc|default('')|string|length|int ) }} -:Version: Ansible %VERSION% +:Version: Ansible {{ version }} :Manual section: 1 :Manual group: System administration commands diff --git a/docs/templates/cli_rst.j2 b/packaging/cli-doc/rst.j2 similarity index 65% rename from docs/templates/cli_rst.j2 rename to packaging/cli-doc/rst.j2 index 8f5a8db3379..4a25653ab15 100644 --- a/docs/templates/cli_rst.j2 +++ b/packaging/cli-doc/rst.j2 @@ -1,4 +1,33 @@ -:source: {{ cli }}.py +{%- set heading = ['-', '+', '#', '*', '^', '"', "'"] -%} +{% macro render_action(parent, action, action_docs) %} + +.. program:: {{cli_name}} {{parent + action}} +.. _{{cli_name|replace('-','_')}}_{{parent|replace(' ','_')}}{{action}}: + +{{ parent + action }} +{{ heading[parent.count(' ')] * (parent + action)|length }} + +{{ (action_docs['desc']|default(' ')) }} + +{% if action_docs['options'] %} + + +{% for option in action_docs['options']|sort(attribute='options') %} +.. option:: {% for switch in option['options'] if switch in action_docs['option_names'] %}{{switch}} {% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} + + {{ (option['desc']) }} +{% endfor %} +{% endif %} +{%- set nested_actions = action_docs['actions'] -%} +{% if nested_actions %} + +{% for nested_action in nested_actions %} +{{ render_action(parent + action + ' ', nested_action, nested_actions[nested_action]) }} + +{% endfor %} +{%- endif %} +{%- endmacro -%} +:source: {{ source }} {% set name = cli_name -%} {% set name_slug = cli_name -%} @@ -67,47 +96,9 @@ Actions ======= {% for action in actions %} +{{- render_action('', action, actions[action]) }} -.. program:: {{cli_name}} {{action}} -.. _{{cli_name|replace('-','_')}}_{{action}}: - -{{ action}} -{{ '-' * action|length}} - -{{ (actions[action]['desc']|default(' '))}} - -{% if actions[action]['options'] %} - - -{% for option in actions[action]['options']|sort(attribute='options') %} -.. option:: {% for switch in option['options'] if switch in actions[action]['option_names'] %}{{switch}} {% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - {{ (option['desc']) }} -{% endfor %} -{% endif %} - -{% for sub_action in actions[action]['actions'] %} - - -.. program:: {{cli_name}} {{action}} {{sub_action}} -.. _{{cli_name|replace('-','_')}}_{{action}}_{{sub_action}}: - -{{ action + " " + sub_action }} -{{ '+' * (action|length + sub_action|length + 1) }} - -{{ (actions[action]['actions'][sub_action]['desc']|default(' '))}} - -{% if actions[action]['actions'][sub_action]['options'] %} - - -{% for option in actions[action]['actions'][sub_action]['options']|sort(attribute='options') %} -.. option:: {% for switch in option['options'] if switch in actions[action]['actions'][sub_action]['option_names'] %}{{switch}} {% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %} - - {{ (option['desc']) }} -{% endfor %} -{% endif %} - -{% endfor %} {% endfor %} .. program:: {{cli_name}} diff --git a/packaging/pep517_backend/__init__.py b/packaging/pep517_backend/__init__.py deleted file mode 100644 index 1d3bc14c823..00000000000 --- a/packaging/pep517_backend/__init__.py +++ /dev/null @@ -1 +0,0 @@ -"""PEP 517 build backend for optionally pre-building docs before setuptools.""" diff --git a/packaging/pep517_backend/_backend.py b/packaging/pep517_backend/_backend.py deleted file mode 100644 index 5086645d242..00000000000 --- a/packaging/pep517_backend/_backend.py +++ /dev/null @@ -1,170 +0,0 @@ -"""PEP 517 build backend wrapper for optionally pre-building docs for sdist.""" - -from __future__ import annotations - -import os -import re -import subprocess -import sys -import typing as t -from configparser import ConfigParser -from contextlib import contextmanager, suppress -from importlib import import_module -from io import StringIO -from pathlib import Path -from shutil import copytree -from tempfile import TemporaryDirectory - -try: - from contextlib import chdir as _chdir_cm -except ImportError: - @contextmanager - def _chdir_cm(path: os.PathLike) -> t.Iterator[None]: - original_wd = Path.cwd() - os.chdir(path) - try: - yield - finally: - os.chdir(original_wd) - -from setuptools.build_meta import ( - build_sdist as _setuptools_build_sdist, - get_requires_for_build_sdist as _setuptools_get_requires_for_build_sdist, -) - -with suppress(ImportError): - # NOTE: Only available for sdist builds that bundle manpages. Declared by - # NOTE: `get_requires_for_build_sdist()` when `--build-manpages` is passed. - from docutils.core import publish_file - from docutils.writers import manpage - - -__all__ = ( # noqa: WPS317, WPS410 - 'build_sdist', 'get_requires_for_build_sdist', -) - - -BUILD_MANPAGES_CONFIG_SETTING = '--build-manpages' -"""Config setting name toggle that is used to request manpage in sdists.""" - - -@contextmanager -def _run_in_temporary_directory() -> t.Iterator[Path]: - with TemporaryDirectory(prefix='.tmp-ansible-pep517-') as tmp_dir: - with _chdir_cm(tmp_dir): - yield Path(tmp_dir) - - -def _make_in_tree_ansible_importable() -> None: - """Add the library directory to module lookup paths.""" - lib_path = str(Path.cwd() / 'lib/') - sys.path.insert(0, lib_path) # NOTE: for the current runtime session - - -def _get_package_distribution_version() -> str: - """Retrieve the current version number from setuptools config.""" - setup_cfg_path = Path.cwd() / 'setup.cfg' - setup_cfg = ConfigParser() - setup_cfg.read_string(setup_cfg_path.read_text()) - cfg_version = setup_cfg.get('metadata', 'version') - importable_version_str = cfg_version.removeprefix('attr: ') - version_mod_str, version_var_str = importable_version_str.rsplit('.', 1) - _make_in_tree_ansible_importable() - return getattr(import_module(version_mod_str), version_var_str) - - -def _generate_rst_in_templates() -> t.Iterable[Path]: - """Create ``*.1.rst.in`` files out of CLI Python modules.""" - generate_man_cmd = ( - sys.executable, - Path(__file__).parent / '_generate_man.py', - '--output-dir=docs/man/man1/', - '--output-format=man', - *Path('lib/ansible/cli/').glob('*.py'), - ) - subprocess.check_call(tuple(map(str, generate_man_cmd))) - return Path('docs/man/man1/').glob('*.1.rst.in') - - -def _convert_rst_in_template_to_manpage( - rst_doc_template: str, - destination_path: os.PathLike, - version_number: str, -) -> None: - """Render pre-made ``*.1.rst.in`` templates into manpages. - - This includes pasting the hardcoded version into the resulting files. - The resulting ``in``-files are wiped in the process. - """ - templated_rst_doc = rst_doc_template.replace('%VERSION%', version_number) - - with StringIO(templated_rst_doc) as in_mem_rst_doc: - publish_file( - source=in_mem_rst_doc, - destination_path=destination_path, - writer=manpage.Writer(), - ) - - -def build_sdist( # noqa: WPS210, WPS430 - sdist_directory: os.PathLike, - config_settings: dict[str, str] | None = None, -) -> str: - build_manpages_requested = BUILD_MANPAGES_CONFIG_SETTING in ( - config_settings or {} - ) - original_src_dir = Path.cwd().resolve() - with _run_in_temporary_directory() as tmp_dir: - tmp_src_dir = Path(tmp_dir) / 'src' - copytree(original_src_dir, tmp_src_dir, symlinks=True) - os.chdir(tmp_src_dir) - - if build_manpages_requested: - Path('docs/man/man1/').mkdir(exist_ok=True, parents=True) - version_number = _get_package_distribution_version() - for rst_in in _generate_rst_in_templates(): - _convert_rst_in_template_to_manpage( - rst_doc_template=rst_in.read_text(), - destination_path=rst_in.with_suffix('').with_suffix(''), - version_number=version_number, - ) - rst_in.unlink() - - Path('pyproject.toml').write_text( - re.sub( - r"""(?x) - backend-path\s=\s\[ # value is a list of double-quoted strings - [^]]+ - ].*\n - build-backend\s=\s"[^"]+".*\n # value is double-quoted - """, - 'build-backend = "setuptools.build_meta"\n', - Path('pyproject.toml').read_text(), - ) - ) - - built_sdist_basename = _setuptools_build_sdist( - sdist_directory=sdist_directory, - config_settings=config_settings, - ) - - return built_sdist_basename - - -def get_requires_for_build_sdist( - config_settings: dict[str, str] | None = None, -) -> list[str]: - build_manpages_requested = BUILD_MANPAGES_CONFIG_SETTING in ( - config_settings or {} - ) - build_manpages_requested = True # FIXME: Once pypa/build#559 is addressed. - - manpage_build_deps = [ - 'docutils', # provides `rst2man` - 'jinja2', # used to generate man pages - 'pyyaml', # needed for importing in-tree `ansible-core` from `lib/` - ] if build_manpages_requested else [] - - return _setuptools_get_requires_for_build_sdist( - config_settings=config_settings, - ) + manpage_build_deps diff --git a/packaging/pep517_backend/_generate_man.py b/packaging/pep517_backend/_generate_man.py deleted file mode 100644 index c22b4fca9a6..00000000000 --- a/packaging/pep517_backend/_generate_man.py +++ /dev/null @@ -1,311 +0,0 @@ -# coding: utf-8 -# Copyright: (c) 2019, Ansible Project -# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt) -"""Generate cli documentation from cli docstrings.""" - -# Make coding more python3-ish -from __future__ import (absolute_import, division, print_function) -__metaclass__ = type - - -import argparse -import os.path -import pathlib -import sys - -from jinja2 import Environment, FileSystemLoader - -DEFAULT_TEMPLATE_FILE = pathlib.Path(__file__).parent / '_templates/man.j2' - - -# from https://www.python.org/dev/peps/pep-0257/ -def trim_docstring(docstring): - if not docstring: - return '' - # Convert tabs to spaces (following the normal Python rules) - # and split into a list of lines: - lines = docstring.expandtabs().splitlines() - # Determine minimum indentation (first line doesn't count): - indent = sys.maxsize - for line in lines[1:]: - stripped = line.lstrip() - if stripped: - indent = min(indent, len(line) - len(stripped)) - # Remove indentation (first line is special): - trimmed = [lines[0].strip()] - if indent < sys.maxsize: - for line in lines[1:]: - trimmed.append(line[indent:].rstrip()) - # Strip off trailing and leading blank lines: - while trimmed and not trimmed[-1]: - trimmed.pop() - while trimmed and not trimmed[0]: - trimmed.pop(0) - # Return a single string: - return '\n'.join(trimmed) - - -def get_options(optlist): - ''' get actual options ''' - - opts = [] - for opt in optlist: - if opt.help == argparse.SUPPRESS: - continue - res = { - 'desc': opt.help, - 'options': opt.option_strings - } - if isinstance(opt, argparse._StoreAction): - res['arg'] = opt.dest.upper() - elif not res['options']: - continue - opts.append(res) - - return opts - - -def dedupe_groups(parser): - action_groups = [] - for action_group in parser._action_groups: - found = False - for a in action_groups: - if a._actions == action_group._actions: - found = True - break - if not found: - action_groups.append(action_group) - return action_groups - - -def get_option_groups(option_parser): - groups = [] - for action_group in dedupe_groups(option_parser)[1:]: - group_info = {} - group_info['desc'] = action_group.description - group_info['options'] = action_group._actions - group_info['group_obj'] = action_group - groups.append(group_info) - return groups - - -def opt_doc_list(parser): - ''' iterate over options lists ''' - - results = [] - for option_group in dedupe_groups(parser)[1:]: - results.extend(get_options(option_group._actions)) - - results.extend(get_options(parser._actions)) - - return results - - -# def opts_docs(cli, name): -def opts_docs(cli_class_name, cli_module_name): - ''' generate doc structure from options ''' - - cli_name = 'ansible-%s' % cli_module_name - if cli_module_name == 'adhoc': - cli_name = 'ansible' - - # WIth no action/subcommand - # shared opts set - # instantiate each cli and ask its options - cli_klass = getattr(__import__("ansible.cli.%s" % cli_module_name, - fromlist=[cli_class_name]), cli_class_name) - cli = cli_klass([cli_name]) - - # parse the common options - try: - cli.init_parser() - except Exception: - pass - - # base/common cli info - cli_options = opt_doc_list(cli.parser) - docs = { - 'cli': cli_module_name, - 'cli_name': cli_name, - 'usage': cli.parser.format_usage(), - 'short_desc': cli.parser.description, - 'long_desc': trim_docstring(cli.__doc__), - 'actions': {}, - 'content_depth': 2, - 'options': cli_options, - 'arguments': getattr(cli, 'ARGUMENTS', None), - } - option_info = {'option_names': [], - 'options': cli_options, - 'groups': []} - - groups_info = get_option_groups(cli.parser) - shared_opt_names = [] - for opt in cli_options: - shared_opt_names.extend(opt.get('options', [])) - - option_info['option_names'] = shared_opt_names - - option_info['groups'].extend(groups_info) - - docs.update(option_info) - - # now for each action/subcommand - # force populate parser with per action options - - def get_actions(parser, docs): - # use class attrs not the attrs on a instance (not that it matters here...) - try: - subparser = parser._subparsers._group_actions[0].choices - except AttributeError: - subparser = {} - - depth = 0 - - for action, parser in subparser.items(): - action_info = {'option_names': [], - 'options': [], - 'actions': {}} - # docs['actions'][action] = {} - # docs['actions'][action]['name'] = action - action_info['name'] = action - action_info['desc'] = trim_docstring(parser.get_default("func").__doc__) - - # docs['actions'][action]['desc'] = getattr(cli, 'execute_%s' % action).__doc__.strip() - action_doc_list = opt_doc_list(parser) - - uncommon_options = [] - for action_doc in action_doc_list: - # uncommon_options = [] - - option_aliases = action_doc.get('options', []) - for option_alias in option_aliases: - - if option_alias in shared_opt_names: - continue - - # TODO: use set - if option_alias not in action_info['option_names']: - action_info['option_names'].append(option_alias) - - if action_doc in action_info['options']: - continue - - uncommon_options.append(action_doc) - - action_info['options'] = uncommon_options - - depth = 1 + get_actions(parser, action_info) - - docs['actions'][action] = action_info - - return depth - - action_depth = get_actions(cli.parser, docs) - docs['content_depth'] = action_depth + 1 - - return docs - - -class GenerateMan: - name = 'generate-man' - - @classmethod - def init_parser(cls, parser: argparse.ArgumentParser): - parser.add_argument("-t", "--template-file", action="store", dest="template_file", - default=DEFAULT_TEMPLATE_FILE, help="path to jinja2 template") - parser.add_argument("-o", "--output-dir", action="store", dest="output_dir", - default='/tmp/', help="Output directory for rst files") - parser.add_argument("-f", "--output-format", action="store", dest="output_format", - default='man', - help="Output format for docs (the default 'man' or 'rst')") - parser.add_argument('cli_modules', help='CLI module name(s)', metavar='MODULE_NAME', nargs='*') - - @staticmethod - def main(args): - template_file = args.template_file - template_path = os.path.expanduser(template_file) - template_dir = os.path.abspath(os.path.dirname(template_path)) - template_basename = os.path.basename(template_file) - - output_dir = os.path.abspath(args.output_dir) - output_format = args.output_format - - cli_modules = args.cli_modules - - # various cli parsing things checks sys.argv if the 'args' that are passed in are [] - # so just remove any args so the cli modules dont try to parse them resulting in warnings - sys.argv = [sys.argv[0]] - - allvars = {} - output = {} - cli_list = [] - cli_bin_name_list = [] - - # for binary in os.listdir('../../lib/ansible/cli'): - for cli_module_name in cli_modules: - binary = os.path.basename(os.path.expanduser(cli_module_name)) - - if not binary.endswith('.py'): - continue - elif binary == '__init__.py': - continue - - cli_name = os.path.splitext(binary)[0] - - if cli_name == 'adhoc': - cli_class_name = 'AdHocCLI' - # myclass = 'AdHocCLI' - output[cli_name] = 'ansible.1.rst.in' - cli_bin_name = 'ansible' - else: - # myclass = "%sCLI" % libname.capitalize() - cli_class_name = "%sCLI" % cli_name.capitalize() - output[cli_name] = 'ansible-%s.1.rst.in' % cli_name - cli_bin_name = 'ansible-%s' % cli_name - - # FIXME: - allvars[cli_name] = opts_docs(cli_class_name, cli_name) - cli_bin_name_list.append(cli_bin_name) - - cli_list = allvars.keys() - - doc_name_formats = {'man': '%s.1.rst.in', - 'rst': '%s.rst'} - - for cli_name in cli_list: - - # template it! - env = Environment(loader=FileSystemLoader(template_dir)) - template = env.get_template(template_basename) - - # add rest to vars - tvars = allvars[cli_name] - tvars['cli_bin_name_list'] = cli_bin_name_list - tvars['cli'] = cli_name - if '-i' in tvars['option_names']: - tvars['inventory'] = True - print('uses inventory') - if '-M' in tvars['option_names']: - tvars['library'] = True - print('uses library') - - manpage = template.render(tvars) - filename = os.path.join(output_dir, doc_name_formats[output_format] % tvars['cli_name']) - pathlib.Path(filename).write_text(manpage) - - -def main() -> None: - parser = argparse.ArgumentParser(description=__doc__) - - GenerateMan.init_parser(parser) - - args = parser.parse_args() - - sys.path.insert(0, str(pathlib.Path(__file__).parent.parent.parent / 'lib')) - - GenerateMan.main(args) - - -if __name__ == '__main__': - main() diff --git a/packaging/pep517_backend/hooks.py b/packaging/pep517_backend/hooks.py deleted file mode 100644 index b834338a6dc..00000000000 --- a/packaging/pep517_backend/hooks.py +++ /dev/null @@ -1,9 +0,0 @@ -# -*- coding: utf-8 -*- - -"""PEP 517 build backend for optionally pre-building docs before setuptools.""" - -from setuptools.build_meta import * # Re-exporting PEP 517 hooks # pylint: disable=unused-wildcard-import,wildcard-import - -from ._backend import ( # noqa: WPS436 # Re-exporting PEP 517 hooks - build_sdist, get_requires_for_build_sdist, -) diff --git a/packaging/release.py b/packaging/release.py index 795e3336b01..05c29faa80b 100755 --- a/packaging/release.py +++ b/packaging/release.py @@ -1280,7 +1280,7 @@ def build(allow_dirty: bool = False) -> None: git("worktree", "add", "-d", temp_dir) try: - run("python", "-m", "build", "--config-setting=--build-manpages", env=env, cwd=temp_dir) + run("python", "-m", "build", env=env, cwd=temp_dir) create_reproducible_sdist(get_sdist_path(version, dist_dir), sdist_file, commit_time) get_wheel_path(version, dist_dir).rename(wheel_file) @@ -1314,20 +1314,12 @@ def test_sdist() -> None: sdist.extractall(temp_dir) - man1_dir = temp_dir / sdist_file.with_suffix("").with_suffix("").name / "docs" / "man" / "man1" - man1_pages = sorted(man1_dir.glob("*.1")) - - if not man1_pages: - raise ApplicationError(f"No man pages found in the sdist at: {man1_dir.relative_to(temp_dir)}") - pyc_glob = "*.pyc*" pyc_files = sorted(path.relative_to(temp_dir) for path in temp_dir.rglob(pyc_glob)) if pyc_files: raise ApplicationError(f"Found {len(pyc_files)} '{pyc_glob}' file(s): {', '.join(map(str, pyc_files))}") - display.show(f"Found man1 pages: {', '.join([path.name for path in man1_pages])}") - test_built_artifact(sdist_file) diff --git a/packaging/release/Makefile b/packaging/release/Makefile deleted file mode 100644 index d1ff8f8851b..00000000000 --- a/packaging/release/Makefile +++ /dev/null @@ -1,61 +0,0 @@ -version ?= $(shell python versionhelper/version_helper.py --raw) - -.PHONY: all -all: - @echo "USAGE:" - @echo - @echo "make release version={version} # current version is '${version}'" - @echo "make publish" - @echo - @echo "NOTE: Make sure to source hacking/env-setup before running these targets." - -.PHONY: release -release: version summary changelog commit-release - git show -p - git status - @echo - @echo 'Run `git push` if you are satisfied with the changes.' - -.PHONY: version -version: - sed -i.bak "s/^__version__ = .*$$/__version__ = '${version}'/" ../../lib/ansible/release.py - rm ../../lib/ansible/release.py.bak - -.PHONY: summary -summary: - @printf '%s\n%s\n%s\n' \ - 'release_summary: |' \ - ' | Release Date: $(shell date '+%Y-%m-%d')' \ - ' | `Porting Guide `__' > \ - ../../changelogs/fragments/v${version}_summary.yaml - -.PHONY: changelog -changelog: - antsibull-changelog release -vv --use-ansible-doc && antsibull-changelog generate -vv --use-ansible-doc - ansible-test sanity changelogs/ - -.PHONY: commit-release -commit-release: - git add ../../changelogs/ ../../lib/ansible/release.py - git commit -m "New release v${version}" - -.PHONY: publish -publish: tag postversion commit-postversion - git show -p - git status - @echo - @echo 'Run `git push --follow-tags` if you are satisfied with the changes.' - -.PHONY: tag -tag: - git tag -a v${version} -m "New release v${version}" - -.PHONY: postversion -postversion: - sed -i.bak "s/^__version__ = .*$$/__version__ = '${version}.post0'/" ../../lib/ansible/release.py - rm ../../lib/ansible/release.py.bak - -.PHONY: commit-postversion -commit-postversion: - git add ../../lib/ansible/release.py - git commit -m "Update Ansible release version to v${version}." diff --git a/packaging/release/tests/__init__.py b/packaging/release/tests/__init__.py deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/packaging/release/tests/version_helper_test.py b/packaging/release/tests/version_helper_test.py deleted file mode 100644 index ff14bd4d64f..00000000000 --- a/packaging/release/tests/version_helper_test.py +++ /dev/null @@ -1,47 +0,0 @@ -from __future__ import absolute_import, division, print_function -__metaclass__ = type - -import pytest - -from packaging.version import InvalidVersion -from versionhelper.version_helper import AnsibleVersionMunger - - -@pytest.mark.parametrize('version,revision,codename,output_propname,expected', [ - ('2.5.0.dev1', None, None, 'raw', '2.5.0.dev1'), - ('2.5.0a0.post0', None, None, 'raw', '2.5.0a0.post0'), - ('2.5.0', None, None, 'raw', '2.5.0'), - ('2.5.0.dev1', None, None, 'major_version', '2.5'), - ('2.5.0', None, None, 'major_version', '2.5'), - ('2.5.0.dev1', None, None, 'base_version', '2.5.0'), - ('2.5.0', None, None, 'base_version', '2.5.0'), - ('2.5.0.dev1', None, None, 'deb_version', '2.5.0~dev1'), - ('2.5.0b1', None, None, 'deb_version', '2.5.0~b1'), - ('2.5.0b1.dev1', None, None, 'deb_version', '2.5.0~b1~dev1'), - ('2.5.0b1.post0', None, None, 'deb_version', '2.5.0~b1~post0'), - ('2.5.0', None, None, 'deb_version', '2.5.0'), - ('2.5.0.dev1', None, None, 'deb_release', '1'), - ('2.5.0b1', 2, None, 'deb_release', '2'), - ('2.5.0.dev1', None, None, 'rpm_release', '0.1.dev1'), - ('2.5.0a1', None, None, 'rpm_release', '0.101.a1'), - ('2.5.0a1.post0', None, None, 'rpm_release', '0.101.a1.post0'), - ('2.5.0b1', None, None, 'rpm_release', '0.201.b1'), - ('2.5.0rc1', None, None, 'rpm_release', '0.1001.rc1'), - ('2.5.0rc1', '0.99', None, 'rpm_release', '0.99.rc1'), - ('2.5.0.rc.1', None, None, 'rpm_release', '0.1001.rc.1'), - ('2.5.0.rc1.dev1', None, None, 'rpm_release', '0.1001.rc1.dev1'), - ('2.5.0', None, None, 'rpm_release', '1'), - ('2.5.0', 2, None, 'rpm_release', '2'), - ('2.5.0', None, None, 'codename', 'UNKNOWN'), - ('2.5.0', None, 'LedZeppelinSongHere', 'codename', 'LedZeppelinSongHere'), - ('2.5.0x1', None, None, None, InvalidVersion) -]) -def test_output_values(version, revision, codename, output_propname, expected): - try: - v = AnsibleVersionMunger(version, revision, codename) - assert getattr(v, output_propname) == expected - except Exception as ex: - if isinstance(expected, type): - assert isinstance(ex, expected) - else: - raise diff --git a/packaging/release/versionhelper/__init__.py b/packaging/release/versionhelper/__init__.py deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/packaging/release/versionhelper/version_helper.py b/packaging/release/versionhelper/version_helper.py deleted file mode 100644 index 163494b6aeb..00000000000 --- a/packaging/release/versionhelper/version_helper.py +++ /dev/null @@ -1,195 +0,0 @@ -from __future__ import absolute_import, division, print_function -__metaclass__ = type - -import argparse -import os -import re -import sys - -from packaging.version import Version, VERSION_PATTERN - - -class AnsibleVersionMunger(object): - tag_offsets = dict( - dev=0, - a=100, - b=200, - rc=1000 - ) - - # TODO: allow overrides here for packaging bump etc - def __init__(self, raw_version, revision=None, codename=None): - self._raw_version = raw_version - self._revision = revision - self._parsed_version = Version(raw_version) - self._codename = codename - self._parsed_regex_match = re.match(VERSION_PATTERN, raw_version, re.VERBOSE | re.IGNORECASE) - - @property - def deb_version(self): - v = self._parsed_version - - match = self._parsed_regex_match - - # treat dev/post as prerelease for now; treat dev/post as equivalent and disallow together - if v.is_prerelease or match.group('dev') or match.group('post'): - if match.group('dev') and match.group('post'): - raise Exception("dev and post may not currently be used together") - if match.group('pre'): - tag_value = match.group('pre') - tag_type = match.group('pre_l') - if match.group('dev'): - tag_value += ('~%s' % match.group('dev').strip('.')) - if match.group('post'): - tag_value += ('~%s' % match.group('post').strip('.')) - elif match.group('dev'): - tag_type = "dev" - tag_value = match.group('dev').strip('.') - elif match.group('post'): - tag_type = "dev" - tag_value = match.group('post').strip('.') - else: - raise Exception("unknown prerelease type for version {0}".format(self._raw_version)) - else: - tag_type = None - tag_value = '' - - # not a pre/post/dev release, just return base version - if not tag_type: - return '{base_version}'.format(base_version=self.base_version) - - # it is a pre/dev release, include the tag value with a ~ - return '{base_version}~{tag_value}'.format(base_version=self.base_version, tag_value=tag_value) - - @property - def deb_release(self): - return '1' if self._revision is None else str(self._revision) - - @property - def rpm_release(self): - v = self._parsed_version - match = self._parsed_regex_match - - # treat presence of dev/post as prerelease for now; treat dev/post the same and disallow together - if v.is_prerelease or match.group('dev') or match.group('post'): - if match.group('dev') and match.group('post'): - raise Exception("dev and post may not currently be used together") - if match.group('pre'): - tag_value = match.group('pre') - tag_type = match.group('pre_l') - tag_ver = match.group('pre_n') - if match.group('dev'): - tag_value += match.group('dev') - if match.group('post'): - tag_value += match.group('post') - elif match.group('dev'): - tag_type = "dev" - tag_value = match.group('dev') - tag_ver = match.group('dev_n') - elif match.group('post'): - tag_type = "dev" - tag_value = match.group('post') - tag_ver = match.group('post_n') - else: - raise Exception("unknown prerelease type for version {0}".format(self._raw_version)) - else: - tag_type = None - tag_value = '' - tag_ver = 0 - - # not a pre/post/dev release, just append revision (default 1) - if not tag_type: - if self._revision is None: - self._revision = 1 - return '{revision}'.format(revision=self._revision) - - # cleanse tag value in case it starts with . - tag_value = tag_value.strip('.') - - # coerce to int and None == 0 - tag_ver = int(tag_ver if tag_ver else 0) - - if self._revision is None: - tag_offset = self.tag_offsets.get(tag_type) - if tag_offset is None: - raise Exception('no tag offset defined for tag {0}'.format(tag_type)) - pkgrel = '0.{0}'.format(tag_offset + tag_ver) - else: - pkgrel = self._revision - - return '{pkgrel}.{tag_value}'.format(pkgrel=pkgrel, tag_value=tag_value) - - @property - def raw(self): - return self._raw_version - - # return the x.y.z version without any other modifiers present - @property - def base_version(self): - return self._parsed_version.base_version - - # return the x.y version without any other modifiers present - @property - def major_version(self): - return re.match(r'^(\d+.\d+)', self._raw_version).group(1) - - @property - def codename(self): - return self._codename if self._codename else "UNKNOWN" - - -def main(): - parser = argparse.ArgumentParser(description='Extract/transform Ansible versions to various packaging formats') - - group = parser.add_mutually_exclusive_group(required=True) - group.add_argument('--raw', action='store_true') - group.add_argument('--majorversion', action='store_true') - group.add_argument('--baseversion', action='store_true') - group.add_argument('--debversion', action='store_true') - group.add_argument('--debrelease', action='store_true') - group.add_argument('--rpmrelease', action='store_true') - group.add_argument('--codename', action='store_true') - group.add_argument('--all', action='store_true') - - parser.add_argument('--revision', action='store', default='auto') - - args = parser.parse_args() - - mydir = os.path.dirname(__file__) - release_loc = os.path.normpath(mydir + '/../../../lib') - - sys.path.insert(0, release_loc) - - from ansible import release - - rev = None - if args.revision != 'auto': - rev = args.revision - - v_raw = release.__version__ - codename = release.__codename__ - v = AnsibleVersionMunger(v_raw, revision=rev, codename=codename) - - if args.raw: - print(v.raw) - elif args.baseversion: - print(v.base_version) - elif args.majorversion: - print(v.major_version) - elif args.debversion: - print(v.deb_version) - elif args.debrelease: - print(v.deb_release) - elif args.rpmrelease: - print(v.rpm_release) - elif args.codename: - print(v.codename) - elif args.all: - props = [name for (name, impl) in vars(AnsibleVersionMunger).items() if isinstance(impl, property)] - - for propname in props: - print('{0}: {1}'.format(propname, getattr(v, propname))) - - -if __name__ == '__main__': - main() diff --git a/packaging/sdist/check-link-behavior.py b/packaging/sdist/check-link-behavior.py deleted file mode 100755 index 34e05023d48..00000000000 --- a/packaging/sdist/check-link-behavior.py +++ /dev/null @@ -1,51 +0,0 @@ -#!/usr/bin/env python -"""Checks for link behavior required for sdist to retain symlinks.""" - -from __future__ import (absolute_import, division, print_function) - -__metaclass__ = type - -import os -import platform -import shutil -import sys -import tempfile - - -def main(): - """Main program entry point.""" - temp_dir = tempfile.mkdtemp() - - target_path = os.path.join(temp_dir, 'file.txt') - symlink_path = os.path.join(temp_dir, 'symlink.txt') - hardlink_path = os.path.join(temp_dir, 'hardlink.txt') - - try: - with open(target_path, 'w'): - pass - - os.symlink(target_path, symlink_path) - os.link(symlink_path, hardlink_path) - - if not os.path.islink(symlink_path): - abort('Symbolic link not created.') - - if not os.path.islink(hardlink_path): - # known issue on MacOS (Darwin) - abort('Hard link of symbolic link created as a regular file.') - finally: - shutil.rmtree(temp_dir) - - -def abort(reason): - """ - :type reason: str - """ - sys.exit('ERROR: %s\n' - 'This will prevent symbolic links from being preserved in the resulting tarball.\n' - 'Aborting creation of sdist on platform: %s' - % (reason, platform.system())) - - -if __name__ == '__main__': - main() diff --git a/pyproject.toml b/pyproject.toml index 4a583ee5a39..e047bea4500 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,4 +1,3 @@ [build-system] -requires = ["setuptools >= 39.2.0", "wheel"] -backend-path = ["packaging"] # requires 'Pip>=20' or 'pep517>=0.6.0' -build-backend = "pep517_backend.hooks" # wraps `setuptools.build_meta` +requires = ["setuptools >= 45.2.0"] +build-backend = "setuptools.build_meta" diff --git a/setup.cfg b/setup.cfg index 34016d462eb..5761c40ab7f 100644 --- a/setup.cfg +++ b/setup.cfg @@ -1,4 +1,4 @@ -# Minimum target setuptools 39.2.0 +# Minimum target setuptools 45.2.0 [metadata] name = ansible-core @@ -38,13 +38,56 @@ classifiers = [options] zip_safe = False python_requires = >=3.9 -include_package_data = True # keep ansible-test as a verbatim script to work with editable installs, since it needs to do its # own package redirection magic that's beyond the scope of the normal `ansible` path redirection # done by setuptools `develop` scripts = bin/ansible-test +[options.package_data] +ansible = + config/*.yml + executor/powershell/*.ps1 + galaxy/data/*.yml + galaxy/data/*/*.j2 + galaxy/data/*/*.md + galaxy/data/*/*/*.cfg + galaxy/data/*/*/*.j2 + galaxy/data/*/*/*.md + galaxy/data/*/*/*/*.j2 + galaxy/data/*/*/*/*.yml + galaxy/data/*/*/*/.git_keep + galaxy/data/*/*/*/inventory + galaxy/data/*/*/.git_keep + galaxy/data/*/*/inventory + keyword_desc.yml + module_utils/csharp/*.cs + module_utils/powershell/*.psm1 + plugins/*/*.yml +ansible_test = + _data/*/*.in + _data/*/*.ps1 + _data/*/*.txt + _data/*/*.yml + _data/*/*/*.ini + _data/ansible.cfg + _data/coveragerc + _util/*/*/*.ps1 + _util/*/*/*.py + _util/*/*/*.sh + _util/*/*/*/*.ini + _util/*/*/*/*.json + _util/*/*/*/*.ps1 + _util/*/*/*/*.psd1 + _util/*/*/*/*.py + _util/*/*/*/*.txt + _util/*/*/*/*/*.cfg + _util/*/*/*/*/*.ps1 + _util/*/*/*/*/*.py + _util/*/*/*/*/*.yml + config/*.template + config/*.yml + # setuptools 51.0.0 # [options.entry_points] # console_scripts = diff --git a/test/integration/targets/canonical-pep517-self-packaging/aliases b/test/integration/targets/canonical-pep517-self-packaging/aliases deleted file mode 100644 index 4667aa4f570..00000000000 --- a/test/integration/targets/canonical-pep517-self-packaging/aliases +++ /dev/null @@ -1,3 +0,0 @@ -shippable/posix/group3 -context/controller -packaging diff --git a/test/integration/targets/canonical-pep517-self-packaging/minimum-build-constraints.txt b/test/integration/targets/canonical-pep517-self-packaging/minimum-build-constraints.txt deleted file mode 100644 index 3ba47aeb4b6..00000000000 --- a/test/integration/targets/canonical-pep517-self-packaging/minimum-build-constraints.txt +++ /dev/null @@ -1,15 +0,0 @@ -# Lowest supporting Python 3.9 and 3.10: -setuptools == 57.0.0; python_version == "3.9" or python_version == "3.10" - -# Lowest supporting Python 3.11: -setuptools == 60.0.0; python_version >= "3.11" - - -# An arbitrary old version that was released before Python 3.9.0: -wheel == 0.33.6 - -# Conditional dependencies: -docutils == 0.16 -Jinja2 == 3.0.0 -MarkupSafe == 2.0.0 -PyYAML == 5.3 diff --git a/test/integration/targets/canonical-pep517-self-packaging/modernish-build-constraints.txt b/test/integration/targets/canonical-pep517-self-packaging/modernish-build-constraints.txt deleted file mode 100644 index 5de287375c1..00000000000 --- a/test/integration/targets/canonical-pep517-self-packaging/modernish-build-constraints.txt +++ /dev/null @@ -1,10 +0,0 @@ -setuptools == 67.4.0 - -# Wheel-only build dependency -wheel == 0.38.4 - -# Conditional dependencies: -docutils == 0.19 -Jinja2 == 3.1.2 -MarkupSafe == 2.1.2 -PyYAML == 6.0.1 diff --git a/test/integration/targets/canonical-pep517-self-packaging/runme.sh b/test/integration/targets/canonical-pep517-self-packaging/runme.sh deleted file mode 100755 index 028348f8fe6..00000000000 --- a/test/integration/targets/canonical-pep517-self-packaging/runme.sh +++ /dev/null @@ -1,31 +0,0 @@ -#!/usr/bin/env bash - -if [[ "${ANSIBLE_DEBUG}" == true ]] # `ansible-test` invoked with `--debug` -then - PYTEST_VERY_VERBOSE_FLAG=-vvvvv - SET_DEBUG_MODE=-x -else - ANSIBLE_DEBUG=false - PYTEST_VERY_VERBOSE_FLAG= - SET_DEBUG_MODE=+x -fi - - -set -eEuo pipefail - -source virtualenv.sh - -set "${SET_DEBUG_MODE}" - -export PIP_DISABLE_PIP_VERSION_CHECK=true -export PIP_NO_PYTHON_VERSION_WARNING=true -export PIP_NO_WARN_SCRIPT_LOCATION=true - -python -Im pip install 'pytest ~= 7.2.0' -python -Im pytest ${PYTEST_VERY_VERBOSE_FLAG} \ - --basetemp="${OUTPUT_DIR}/pytest-tmp" \ - --color=yes \ - --showlocals \ - -p no:forked \ - -p no:mock \ - -ra diff --git a/test/integration/targets/canonical-pep517-self-packaging/runme_test.py b/test/integration/targets/canonical-pep517-self-packaging/runme_test.py deleted file mode 100644 index 86b0f7532a8..00000000000 --- a/test/integration/targets/canonical-pep517-self-packaging/runme_test.py +++ /dev/null @@ -1,385 +0,0 @@ -"""Smoke tests for the in-tree PEP 517 backend.""" - -from __future__ import annotations - -from filecmp import dircmp -from os import chdir, environ, PathLike -from pathlib import Path -from shutil import rmtree -from subprocess import check_call, check_output, PIPE -from sys import executable as current_interpreter, version_info -from tarfile import TarFile -import typing as t - -try: - from contextlib import chdir as _chdir_cm -except ImportError: - from contextlib import contextmanager as _contextmanager - - @_contextmanager - def _chdir_cm(path: PathLike) -> t.Iterator[None]: - original_wd = Path.cwd() - chdir(path) - try: - yield - finally: - chdir(original_wd) - -import pytest - - -DIST_NAME = 'ansible_core' -DIST_FILENAME_BASE = 'ansible-core' -OUTPUT_DIR = Path(environ['OUTPUT_DIR']).resolve().absolute() -SRC_ROOT_DIR = OUTPUT_DIR.parents[3] -GENERATED_MANPAGES_SUBDIR = SRC_ROOT_DIR / 'docs' / 'man' / 'man1' -LOWEST_SUPPORTED_BUILD_DEPS_FILE = ( - Path(__file__).parent / 'minimum-build-constraints.txt' -).resolve().absolute() -MODERNISH_BUILD_DEPS_FILE = ( - Path(__file__).parent / 'modernish-build-constraints.txt' -).resolve().absolute() -RELEASE_MODULE = SRC_ROOT_DIR / 'lib' / 'ansible' / 'release.py' -VERSION_LINE_PREFIX = "__version__ = '" -PKG_DIST_VERSION = next( - line[len(VERSION_LINE_PREFIX):-1] - for line in RELEASE_MODULE.read_text().splitlines() - if line.startswith(VERSION_LINE_PREFIX) -) -EXPECTED_SDIST_NAME_BASE = f'{DIST_FILENAME_BASE}-{PKG_DIST_VERSION}' -EXPECTED_SDIST_NAME = f'{EXPECTED_SDIST_NAME_BASE}.tar.gz' -EXPECTED_WHEEL_NAME = f'{DIST_NAME}-{PKG_DIST_VERSION}-py3-none-any.whl' - -IS_PYTHON310_PLUS = version_info[:2] >= (3, 10) - - -def wipe_generated_manpages() -> None: - """Ensure man1 pages aren't present in the source checkout.""" - # Cleaning up the gitignored manpages... - if not GENERATED_MANPAGES_SUBDIR.exists(): - return - - rmtree(GENERATED_MANPAGES_SUBDIR) - # Removed the generated manpages... - - -def contains_man1_pages(sdist_tarball: Path) -> Path: - """Check if the man1 pages are present in given tarball.""" - with sdist_tarball.open(mode='rb') as tarball_fd: - with TarFile.gzopen(fileobj=tarball_fd, name=None) as tarball: - try: - tarball.getmember( - name=f'{EXPECTED_SDIST_NAME_BASE}/docs/man/man1', - ) - except KeyError: - return False - - return True - - -def unpack_sdist(sdist_tarball: Path, target_directory: Path) -> Path: - """Unarchive given tarball. - - :returns: Path of the package source checkout. - """ - with sdist_tarball.open(mode='rb') as tarball_fd: - with TarFile.gzopen(fileobj=tarball_fd, name=None) as tarball: - tarball.extractall(path=target_directory) - return target_directory / EXPECTED_SDIST_NAME_BASE - - -def assert_dirs_equal(*dir_paths: t.List[Path]) -> None: - dir_comparison = dircmp(*dir_paths) - assert not dir_comparison.left_only - assert not dir_comparison.right_only - assert not dir_comparison.diff_files - assert not dir_comparison.funny_files - - -def normalize_unpacked_rebuilt_sdist(sdist_path: Path) -> None: - top_pkg_info_path = sdist_path / 'PKG-INFO' - nested_pkg_info_path = ( - sdist_path / 'lib' / f'{DIST_NAME}.egg-info' / 'PKG-INFO' - ) - entry_points_path = nested_pkg_info_path.parent / 'entry_points.txt' - - # setuptools v39 write out two trailing empty lines and an unknown platform - # while the recent don't - top_pkg_info_path.write_text( - top_pkg_info_path.read_text().replace( - 'Classifier: Development Status :: 5', - 'Platform: UNKNOWN\nClassifier: Development Status :: 5', - ) + '\n\n' - ) - nested_pkg_info_path.write_text( - nested_pkg_info_path.read_text().replace( - 'Classifier: Development Status :: 5', - 'Platform: UNKNOWN\nClassifier: Development Status :: 5', - ) + '\n\n' - ) - - # setuptools v39 write out one trailing empty line while the recent don't - entry_points_path.write_text(entry_points_path.read_text() + '\n') - - -@pytest.fixture -def venv_python_exe(tmp_path: Path) -> t.Iterator[Path]: - venv_path = tmp_path / 'pytest-managed-venv' - mkvenv_cmd = ( - current_interpreter, '-m', 'venv', str(venv_path), - ) - check_call(mkvenv_cmd, env={}, stderr=PIPE, stdout=PIPE) - yield venv_path / 'bin' / 'python' - rmtree(venv_path) - - -def run_with_venv_python( - python_exe: Path, *cli_args: t.Iterable[str], - env_vars: t.Dict[str, str] = None, -) -> str: - if env_vars is None: - env_vars = {} - full_cmd = str(python_exe), *cli_args - return check_output(full_cmd, env=env_vars, stderr=PIPE) - - -def build_dists( - python_exe: Path, *cli_args: t.Iterable[str], - env_vars: t.Dict[str, str], -) -> str: - return run_with_venv_python( - python_exe, '-m', 'build', - *cli_args, env_vars=env_vars, - ) - - -def pip_install( - python_exe: Path, *cli_args: t.Iterable[str], - env_vars: t.Dict[str, str] = None, -) -> str: - return run_with_venv_python( - python_exe, '-m', 'pip', 'install', - *cli_args, env_vars=env_vars, - ) - - -def test_installing_sdist_build_with_modern_deps_to_old_env( - venv_python_exe: Path, tmp_path: Path, -) -> None: - pip_install(venv_python_exe, 'build ~= 0.10.0') - tmp_dir_sdist_w_modern_tools = tmp_path / 'sdist-w-modern-tools' - build_dists( - venv_python_exe, '--sdist', - '--config-setting=--build-manpages', - f'--outdir={tmp_dir_sdist_w_modern_tools!s}', - str(SRC_ROOT_DIR), - env_vars={ - 'PIP_CONSTRAINT': str(MODERNISH_BUILD_DEPS_FILE), - }, - ) - tmp_path_sdist_w_modern_tools = ( - tmp_dir_sdist_w_modern_tools / EXPECTED_SDIST_NAME - ) - - # Downgrading pip, because v20+ supports in-tree build backends - pip_install(venv_python_exe, 'pip ~= 19.3.1') - - # Smoke test — installing an sdist with pip that does not support - # in-tree build backends. - pip_install( - venv_python_exe, str(tmp_path_sdist_w_modern_tools), '--no-deps', - ) - - # Downgrading pip, because versions that support PEP 517 don't allow - # disabling it with `--no-use-pep517` when `build-backend` is set in - # the `[build-system]` section of `pyproject.toml`, considering this - # an explicit opt-in. - if not IS_PYTHON310_PLUS: - pip_install(venv_python_exe, 'pip == 18.0') - - # Smoke test — installing an sdist with pip that does not support invoking - # PEP 517 interface at all. - # In this scenario, pip will run `setup.py install` since `wheel` is not in - # the environment. - if IS_PYTHON310_PLUS: - tmp_dir_unpacked_sdist_root = tmp_path / 'unpacked-sdist' - tmp_dir_unpacked_sdist_path = tmp_dir_unpacked_sdist_root / EXPECTED_SDIST_NAME_BASE - with TarFile.gzopen(tmp_path_sdist_w_modern_tools) as sdist_fd: - sdist_fd.extractall(path=tmp_dir_unpacked_sdist_root) - - pip_install( - venv_python_exe, 'setuptools', - env_vars={ - 'PIP_CONSTRAINT': str(LOWEST_SUPPORTED_BUILD_DEPS_FILE), - }, - ) - with _chdir_cm(tmp_dir_unpacked_sdist_path): - run_with_venv_python( - venv_python_exe, 'setup.py', 'sdist', - env_vars={'PATH': environ['PATH']}, - ) - else: - pip_install( - venv_python_exe, str(tmp_path_sdist_w_modern_tools), '--no-deps', - env_vars={ - 'PIP_CONSTRAINT': str(LOWEST_SUPPORTED_BUILD_DEPS_FILE), - }, - ) - - # Smoke test — installing an sdist with pip that does not support invoking - # PEP 517 interface at all. - # With `wheel` present, pip will run `setup.py bdist_wheel` and then, - # unpack the result. - pip_install(venv_python_exe, 'wheel') - if IS_PYTHON310_PLUS: - with _chdir_cm(tmp_dir_unpacked_sdist_path): - run_with_venv_python( - venv_python_exe, 'setup.py', 'bdist_wheel', - env_vars={'PATH': environ['PATH']}, - ) - else: - pip_install( - venv_python_exe, str(tmp_path_sdist_w_modern_tools), '--no-deps', - ) - - -def test_dist_rebuilds_with_manpages_premutations( - venv_python_exe: Path, tmp_path: Path, -) -> None: - """Test a series of sdist rebuilds under different conditions. - - This check builds sdists right from the Git checkout with and without - the manpages. It also does this using different versions of the setuptools - PEP 517 build backend being pinned. Finally, it builds a wheel out of one - of the rebuilt sdists. - As intermediate assertions, this test makes simple smoke tests along - the way. - """ - pip_install(venv_python_exe, 'build ~= 0.10.0') - - # Test building an sdist without manpages from the Git checkout - tmp_dir_sdist_without_manpages = tmp_path / 'sdist-without-manpages' - wipe_generated_manpages() - build_dists( - venv_python_exe, '--sdist', - f'--outdir={tmp_dir_sdist_without_manpages!s}', - str(SRC_ROOT_DIR), - env_vars={ - 'PIP_CONSTRAINT': str(MODERNISH_BUILD_DEPS_FILE), - }, - ) - tmp_path_sdist_without_manpages = ( - tmp_dir_sdist_without_manpages / EXPECTED_SDIST_NAME - ) - assert tmp_path_sdist_without_manpages.exists() - assert not contains_man1_pages(tmp_path_sdist_without_manpages) - sdist_without_manpages_path = unpack_sdist( - tmp_path_sdist_without_manpages, - tmp_dir_sdist_without_manpages / 'src', - ) - - # Test building an sdist with manpages from the Git checkout - # and lowest supported build deps - wipe_generated_manpages() - tmp_dir_sdist_with_manpages = tmp_path / 'sdist-with-manpages' - build_dists( - venv_python_exe, '--sdist', - '--config-setting=--build-manpages', - f'--outdir={tmp_dir_sdist_with_manpages!s}', - str(SRC_ROOT_DIR), - env_vars={ - 'PIP_CONSTRAINT': str(LOWEST_SUPPORTED_BUILD_DEPS_FILE), - }, - ) - tmp_path_sdist_with_manpages = ( - tmp_dir_sdist_with_manpages / EXPECTED_SDIST_NAME - ) - assert tmp_path_sdist_with_manpages.exists() - assert contains_man1_pages(tmp_path_sdist_with_manpages) - sdist_with_manpages_path = unpack_sdist( - tmp_path_sdist_with_manpages, - tmp_dir_sdist_with_manpages / 'src', - ) - - # Test re-building an sdist with manpages from the - # sdist contents that does not include the manpages - tmp_dir_rebuilt_sdist = tmp_path / 'rebuilt-sdist' - build_dists( - venv_python_exe, '--sdist', - '--config-setting=--build-manpages', - f'--outdir={tmp_dir_rebuilt_sdist!s}', - str(sdist_without_manpages_path), - env_vars={ - 'PIP_CONSTRAINT': str(MODERNISH_BUILD_DEPS_FILE), - }, - ) - tmp_path_rebuilt_sdist = tmp_dir_rebuilt_sdist / EXPECTED_SDIST_NAME - # Checking that the expected sdist got created - # from the previous unpacked sdist... - assert tmp_path_rebuilt_sdist.exists() - # NOTE: The following assertion is disabled due to the fact that, when - # NOTE: building an sdist from the original source checkout, the build - # NOTE: backend replaces itself with pure setuptools in the resulting - # NOTE: sdist, and the following rebuilds from that sdist are no longer - # NOTE: able to process the custom config settings that are implemented in - # NOTE: the in-tree build backend. It is expected that said - # NOTE: `pyproject.toml` mutation change will be reverted once all of the - # NOTE: supported `ansible-core` versions ship wheels, meaning that the - # NOTE: end-users won't be building the distribution from sdist on install. - # NOTE: Another case, when it can be reverted is declaring pip below v20 - # NOTE: unsupported — it is the first version to support in-tree build - # NOTE: backends natively. - # assert contains_man1_pages(tmp_path_rebuilt_sdist) # FIXME: See #80255 - rebuilt_sdist_path = unpack_sdist( - tmp_path_rebuilt_sdist, - tmp_dir_rebuilt_sdist / 'src', - ) - assert rebuilt_sdist_path.exists() - assert rebuilt_sdist_path.is_dir() - normalize_unpacked_rebuilt_sdist(rebuilt_sdist_path) - assert_dirs_equal(rebuilt_sdist_path, sdist_with_manpages_path) - - # Test building a wheel from the rebuilt sdist with manpages contents - # and lowest supported build deps - tmp_dir_rebuilt_wheel = tmp_path / 'rebuilt-wheel' - build_dists( - venv_python_exe, '--wheel', - f'--outdir={tmp_dir_rebuilt_wheel!s}', - str(sdist_with_manpages_path), - env_vars={ - 'PIP_CONSTRAINT': str(LOWEST_SUPPORTED_BUILD_DEPS_FILE), - }, - ) - tmp_path_rebuilt_wheel = tmp_dir_rebuilt_wheel / EXPECTED_WHEEL_NAME - # Checking that the expected wheel got created... - assert tmp_path_rebuilt_wheel.exists() - - -def test_pep660_editable_install_smoke(venv_python_exe: Path) -> None: - """Smoke-test PEP 660 editable install. - - This verifies that the in-tree build backend wrapper - does not break any required interfaces. - """ - pip_install(venv_python_exe, '-e', str(SRC_ROOT_DIR)) - - pip_show_cmd = ( - str(venv_python_exe), '-m', - 'pip', 'show', DIST_FILENAME_BASE, - ) - installed_ansible_meta = check_output( - pip_show_cmd, - env={}, stderr=PIPE, text=True, - ).splitlines() - assert f'Name: {DIST_FILENAME_BASE}' in installed_ansible_meta - assert f'Version: {PKG_DIST_VERSION}' in installed_ansible_meta - - pip_runtime_version_cmd = ( - str(venv_python_exe), '-c', - 'from ansible import __version__; print(__version__)', - ) - runtime_ansible_version = check_output( - pip_runtime_version_cmd, - env={}, stderr=PIPE, text=True, - ).strip() - assert runtime_ansible_version == PKG_DIST_VERSION diff --git a/test/integration/targets/packaging_cli-doc/aliases b/test/integration/targets/packaging_cli-doc/aliases new file mode 100644 index 00000000000..1d28bdb2aa3 --- /dev/null +++ b/test/integration/targets/packaging_cli-doc/aliases @@ -0,0 +1,2 @@ +shippable/posix/group5 +context/controller diff --git a/test/integration/targets/packaging_cli-doc/runme.sh b/test/integration/targets/packaging_cli-doc/runme.sh new file mode 100755 index 00000000000..9218b0a4f06 --- /dev/null +++ b/test/integration/targets/packaging_cli-doc/runme.sh @@ -0,0 +1,38 @@ +#!/usr/bin/env bash + +set -eux + +source virtualenv.sh + +mkdir -p "${JUNIT_OUTPUT_DIR}" # ensure paths relative to this path work + +cli_doc="${JUNIT_OUTPUT_DIR}/../../../packaging/cli-doc" +build="${cli_doc}/build.py" +template="template.j2" + +# Test `rst` command + +pip install jinja2 + +rst_dir="${OUTPUT_DIR}/rst" + +python.py "${build}" rst --output-dir "${rst_dir}" && ./verify.py "${rst_dir}" +python.py "${build}" rst --output-dir "${rst_dir}" --template "${template}" && ./verify.py "${rst_dir}" + +# Test `man` command (and the argcomplete code path) + +pip install docutils argcomplete + +man_dir="${OUTPUT_DIR}/man" + +python.py "${build}" man --output-dir "${man_dir}" && ./verify.py "${man_dir}" +python.py "${build}" man --output-dir "${man_dir}" --template "${template}" && ./verify.py "${man_dir}" + +# Test `json` command + +python.py "${build}" json --output-file docs.json && ls -l docs.json + +# Ensure complete coverage of the main conditional + +echo "import sys; sys.path.insert(0, '${cli_doc}'); import build" > cover.py +python.py cover.py diff --git a/test/integration/targets/packaging_cli-doc/template.j2 b/test/integration/targets/packaging_cli-doc/template.j2 new file mode 100644 index 00000000000..697e7527e0a --- /dev/null +++ b/test/integration/targets/packaging_cli-doc/template.j2 @@ -0,0 +1 @@ +{{ version }} diff --git a/test/integration/targets/packaging_cli-doc/verify.py b/test/integration/targets/packaging_cli-doc/verify.py new file mode 100755 index 00000000000..7793fa8c24b --- /dev/null +++ b/test/integration/targets/packaging_cli-doc/verify.py @@ -0,0 +1,23 @@ +#!/usr/bin/env python + +import os +import pathlib +import sys + +exclude_programs = { + 'ansible-connection', + 'ansible-test', +} + +bin_dir = pathlib.Path(os.environ['JUNIT_OUTPUT_DIR']).parent.parent.parent / 'bin' +programs = set(program.name for program in bin_dir.iterdir() if program.name not in exclude_programs) +docs_dir = pathlib.Path(sys.argv[1]) +docs = set(path.with_suffix('').name for path in docs_dir.iterdir()) + +print('\n'.join(sorted(docs))) + +missing = programs - docs +extra = docs - programs + +if missing or extra: + raise RuntimeError(f'{missing=} {extra=}') diff --git a/test/lib/ansible_test/_internal/classification/__init__.py b/test/lib/ansible_test/_internal/classification/__init__.py index bca02403b3c..deda27ee71f 100644 --- a/test/lib/ansible_test/_internal/classification/__init__.py +++ b/test/lib/ansible_test/_internal/classification/__init__.py @@ -721,17 +721,6 @@ class PathMapper: if path.startswith('changelogs/'): return minimal - if path.startswith('docs/'): - return minimal - - if path.startswith('examples/'): - if path == 'examples/scripts/ConfigureRemotingForAnsible.ps1': - return { - 'windows-integration': 'connection_winrm', - } - - return minimal - if path.startswith('hacking/'): return minimal @@ -753,8 +742,12 @@ class PathMapper: return minimal if path.startswith('packaging/'): - if path.startswith('packaging/pep517_backend/'): - return packaging + packaging_target = f'packaging_{os.path.splitext(path.split(os.path.sep)[1])[0]}' + + if packaging_target in self.integration_targets_by_name: + return { + 'integration': packaging_target, + } return minimal diff --git a/test/lib/ansible_test/_internal/classification/python.py b/test/lib/ansible_test/_internal/classification/python.py index 7036de1aced..c074d348d83 100644 --- a/test/lib/ansible_test/_internal/classification/python.py +++ b/test/lib/ansible_test/_internal/classification/python.py @@ -256,7 +256,6 @@ class ModuleUtilFinder(ast.NodeVisitor): # The mapping is a tuple consisting of a path pattern to match and a replacement path. # During analysis, any relative imports not covered here will result in warnings, which can be fixed by adding the appropriate entry. path_map = ( - ('^hacking/build_library/build_ansible/', 'build_ansible/'), ('^lib/ansible/', 'ansible/'), ('^test/lib/ansible_test/_util/controller/sanity/validate-modules/', 'validate_modules/'), ('^test/units/', 'test/units/'), diff --git a/test/lib/ansible_test/_internal/commands/sanity/sanity_docs.py b/test/lib/ansible_test/_internal/commands/sanity/sanity_docs.py deleted file mode 100644 index 48f1b0b100a..00000000000 --- a/test/lib/ansible_test/_internal/commands/sanity/sanity_docs.py +++ /dev/null @@ -1,61 +0,0 @@ -"""Sanity test for documentation of sanity tests.""" -from __future__ import annotations - -import os - -from . import ( - SanityVersionNeutral, - SanityMessage, - SanityFailure, - SanitySuccess, - SanityTargets, - sanity_get_tests, -) - -from ...test import ( - TestResult, -) - -from ...config import ( - SanityConfig, -) - -from ...data import ( - data_context, -) - - -class SanityDocsTest(SanityVersionNeutral): - """Sanity test for documentation of sanity tests.""" - - ansible_only = True - - @property - def can_ignore(self) -> bool: - """True if the test supports ignore entries.""" - return False - - @property - def no_targets(self) -> bool: - """True if the test does not use test targets. Mutually exclusive with all_targets.""" - return True - - def test(self, args: SanityConfig, targets: SanityTargets) -> TestResult: - sanity_dir = 'docs/docsite/rst/dev_guide/testing/sanity' - sanity_docs = set(part[0] for part in (os.path.splitext(os.path.basename(path)) for path in data_context().content.get_files(sanity_dir)) - if part[1] == '.rst') - sanity_tests = set(sanity_test.name for sanity_test in sanity_get_tests()) - - missing = sanity_tests - sanity_docs - - results = [] - - results += [SanityMessage( - message='missing docs for ansible-test sanity --test %s' % r, - path=os.path.join(sanity_dir, '%s.rst' % r), - ) for r in sorted(missing)] - - if results: - return SanityFailure(self.name, messages=results) - - return SanitySuccess(self.name) diff --git a/test/lib/ansible_test/_internal/provider/source/unversioned.py b/test/lib/ansible_test/_internal/provider/source/unversioned.py index 699de889d3e..54831c99e4a 100644 --- a/test/lib/ansible_test/_internal/provider/source/unversioned.py +++ b/test/lib/ansible_test/_internal/provider/source/unversioned.py @@ -48,9 +48,6 @@ class UnversionedSource(SourceProvider): 'tests': ( 'output', ), - 'docs/docsite': ( - '_build', - ), } kill_sub_file = { diff --git a/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 b/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 index 7cc86abd7ce..c1cb91e49fd 100644 --- a/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 +++ b/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1 @@ -15,7 +15,7 @@ # To run this script in Powershell: # # [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -# $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1" +# $url = "https://raw.githubusercontent.com/ansible/ansible/devel/test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1" # $file = "$env:temp\ConfigureRemotingForAnsible.ps1" # # (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file) diff --git a/test/sanity/code-smell/configure-remoting-ps1.json b/test/sanity/code-smell/configure-remoting-ps1.json deleted file mode 100644 index 593b765d14a..00000000000 --- a/test/sanity/code-smell/configure-remoting-ps1.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "no_targets": true, - "output": "path-message" -} diff --git a/test/sanity/code-smell/configure-remoting-ps1.py b/test/sanity/code-smell/configure-remoting-ps1.py deleted file mode 100644 index fe678008c1e..00000000000 --- a/test/sanity/code-smell/configure-remoting-ps1.py +++ /dev/null @@ -1,52 +0,0 @@ -from __future__ import annotations - -import os - - -def main(): - # required by external automated processes and should not be moved, renamed or converted to a symbolic link - original = 'examples/scripts/ConfigureRemotingForAnsible.ps1' - # required to be packaged with ansible-test and must match the original file, but cannot be a symbolic link - # the packaged version is needed to run tests when ansible-test has been installed - # keeping the packaged version identical to the original makes sure tests cover both files - packaged = 'test/lib/ansible_test/_util/target/setup/ConfigureRemotingForAnsible.ps1' - - copy_valid = False - - if os.path.isfile(original) and os.path.isfile(packaged): - with open(original, 'rb') as original_file: - original_content = original_file.read() - - with open(packaged, 'rb') as packaged_file: - packaged_content = packaged_file.read() - - if original_content == packaged_content: - copy_valid = True - - if not copy_valid: - print('%s: must be an exact copy of "%s"' % (packaged, original)) - - for path in [original, packaged]: - directory = path - - while True: - directory = os.path.dirname(directory) - - if not directory: - break - - if not os.path.isdir(directory): - print('%s: must be a directory' % directory) - - if os.path.islink(directory): - print('%s: cannot be a symbolic link' % directory) - - if not os.path.isfile(path): - print('%s: must be a file' % path) - - if os.path.islink(path): - print('%s: cannot be a symbolic link' % path) - - -if __name__ == '__main__': - main() diff --git a/test/sanity/code-smell/docs-build.json b/test/sanity/code-smell/docs-build.json deleted file mode 100644 index a43fa923b2b..00000000000 --- a/test/sanity/code-smell/docs-build.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "disabled": true, - "no_targets": true, - "output": "path-line-column-message" -} diff --git a/test/sanity/code-smell/docs-build.py b/test/sanity/code-smell/docs-build.py deleted file mode 100644 index aaa69378c7f..00000000000 --- a/test/sanity/code-smell/docs-build.py +++ /dev/null @@ -1,152 +0,0 @@ -from __future__ import annotations - -import os -import re -import shutil -import subprocess -import sys -import tempfile - - -def main(): - base_dir = os.getcwd() + os.path.sep - docs_dir = os.path.abspath('docs/docsite') - - # TODO: Remove this temporary hack to constrain 'cryptography' when we have - # a better story for dealing with it. - tmpfd, tmp = tempfile.mkstemp() - requirements_txt = os.path.join(base_dir, 'requirements.txt') - shutil.copy2(requirements_txt, tmp) - lines = [] - with open(requirements_txt, 'r') as f: - for line in f.readlines(): - if line.strip() == 'cryptography': - line = 'cryptography < 3.4\n' - lines.append(line) - - with open(requirements_txt, 'w') as f: - f.writelines(lines) - - try: - cmd = ['make', 'core_singlehtmldocs'] - sphinx = subprocess.run(cmd, stdin=subprocess.DEVNULL, capture_output=True, cwd=docs_dir, check=False, text=True) - finally: - shutil.move(tmp, requirements_txt) - - stdout = sphinx.stdout - stderr = sphinx.stderr - - if sphinx.returncode != 0: - sys.stderr.write("Command '%s' failed with status code: %d\n" % (' '.join(cmd), sphinx.returncode)) - - if stdout.strip(): - stdout = simplify_stdout(stdout) - - sys.stderr.write("--> Standard Output\n") - sys.stderr.write("%s\n" % stdout.strip()) - - if stderr.strip(): - sys.stderr.write("--> Standard Error\n") - sys.stderr.write("%s\n" % stderr.strip()) - - sys.exit(1) - - with open('docs/docsite/rst_warnings', 'r') as warnings_fd: - output = warnings_fd.read().strip() - lines = output.splitlines() - - known_warnings = { - 'block-quote-missing-blank-line': r'^Block quote ends without a blank line; unexpected unindent.$', - 'literal-block-lex-error': r'^Could not lex literal_block as "[^"]*". Highlighting skipped.$', - 'duplicate-label': r'^duplicate label ', - 'undefined-label': r'undefined label: ', - 'unknown-document': r'unknown document: ', - 'toc-tree-missing-document': r'toctree contains reference to nonexisting document ', - 'reference-target-not-found': r'[^ ]* reference target not found: ', - 'not-in-toc-tree': r"document isn't included in any toctree$", - 'unexpected-indentation': r'^Unexpected indentation.$', - 'definition-list-missing-blank-line': r'^Definition list ends without a blank line; unexpected unindent.$', - 'explicit-markup-missing-blank-line': r'Explicit markup ends without a blank line; unexpected unindent.$', - 'toc-tree-glob-pattern-no-match': r"^toctree glob pattern '[^']*' didn't match any documents$", - 'unknown-interpreted-text-role': '^Unknown interpreted text role "[^"]*".$', - } - - for line in lines: - match = re.search('^(?P[^:]+):((?P[0-9]+):)?((?P[0-9]+):)? (?PWARNING|ERROR): (?P.*)$', line) - - if not match: - path = 'docs/docsite/rst/index.rst' - lineno = 0 - column = 0 - code = 'unknown' - message = line - - # surface unknown lines while filtering out known lines to avoid excessive output - print('%s:%d:%d: %s: %s' % (path, lineno, column, code, message)) - continue - - path = match.group('path') - lineno = int(match.group('line') or 0) - column = int(match.group('column') or 0) - level = match.group('level').lower() - message = match.group('message') - - path = os.path.abspath(path) - - if path.startswith(base_dir): - path = path[len(base_dir):] - - if path.startswith('rst/'): - path = 'docs/docsite/' + path # fix up paths reported relative to `docs/docsite/` - - if level == 'warning': - code = 'warning' - - for label, pattern in known_warnings.items(): - if re.search(pattern, message): - code = label - break - else: - code = 'error' - - print('%s:%d:%d: %s: %s' % (path, lineno, column, code, message)) - - -def simplify_stdout(value): - """Simplify output by omitting earlier 'rendering: ...' messages.""" - lines = value.strip().splitlines() - - rendering = [] - keep = [] - - def truncate_rendering(): - """Keep last rendering line (if any) with a message about omitted lines as needed.""" - if not rendering: - return - - notice = rendering[-1] - - if len(rendering) > 1: - notice += ' (%d previous rendering line(s) omitted)' % (len(rendering) - 1) - - keep.append(notice) - # Could change to rendering.clear() if we do not support python2 - rendering[:] = [] - - for line in lines: - if line.startswith('rendering: '): - rendering.append(line) - continue - - truncate_rendering() - keep.append(line) - - truncate_rendering() - - result = '\n'.join(keep) - - return result - - -if __name__ == '__main__': - main() diff --git a/test/sanity/code-smell/docs-build.requirements.in b/test/sanity/code-smell/docs-build.requirements.in deleted file mode 100644 index 02c3bfc946c..00000000000 --- a/test/sanity/code-smell/docs-build.requirements.in +++ /dev/null @@ -1,9 +0,0 @@ -jinja2 -pyyaml -resolvelib < 0.9.0 -sphinx == 4.2.0 -sphinx-notfound-page -sphinx-ansible-theme -straight.plugin -rstcheck < 4 # match version used in other sanity tests -antsibull-docs == 1.7.0 # currently approved version diff --git a/test/sanity/code-smell/docs-build.requirements.txt b/test/sanity/code-smell/docs-build.requirements.txt deleted file mode 100644 index 15bb85cae9e..00000000000 --- a/test/sanity/code-smell/docs-build.requirements.txt +++ /dev/null @@ -1,52 +0,0 @@ -# edit "docs-build.requirements.in" and generate with: hacking/update-sanity-requirements.py --test docs-build -# pre-build requirement: pyyaml == 6.0 -# pre-build constraint: Cython < 3.0 -aiofiles==22.1.0 -aiohttp==3.8.3 -aiosignal==1.2.0 -alabaster==0.7.12 -ansible-pygments==0.1.1 -antsibull-core==1.2.0 -antsibull-docs==1.7.0 -async-timeout==4.0.2 -asyncio-pool==0.6.0 -attrs==22.1.0 -Babel==2.10.3 -certifi==2022.9.14 -charset-normalizer==2.1.1 -docutils==0.17.1 -frozenlist==1.3.1 -idna==3.4 -imagesize==1.4.1 -Jinja2==3.1.2 -MarkupSafe==2.1.1 -multidict==6.0.2 -packaging==21.3 -perky==0.5.5 -pydantic==1.10.2 -Pygments==2.13.0 -pyparsing==3.0.9 -pytz==2022.2.1 -PyYAML==6.0 -requests==2.28.1 -resolvelib==0.8.1 -rstcheck==3.5.0 -semantic-version==2.10.0 -sh==1.14.3 -six==1.16.0 -snowballstemmer==2.2.0 -Sphinx==4.2.0 -sphinx-ansible-theme==0.9.1 -sphinx-notfound-page==0.8.3 -sphinx-rtd-theme==1.0.0 -sphinxcontrib-applehelp==1.0.2 -sphinxcontrib-devhelp==1.0.2 -sphinxcontrib-htmlhelp==2.0.0 -sphinxcontrib-jsmath==1.0.1 -sphinxcontrib-qthelp==1.0.3 -sphinxcontrib-serializinghtml==1.1.5 -straight.plugin==1.5.0 -Twiggy==0.5.1 -typing_extensions==4.3.0 -urllib3==1.26.12 -yarl==1.8.1 diff --git a/test/sanity/code-smell/package-data.json b/test/sanity/code-smell/package-data.json index 0aa70a3c9b7..f7ecd010a50 100644 --- a/test/sanity/code-smell/package-data.json +++ b/test/sanity/code-smell/package-data.json @@ -1,5 +1,6 @@ { "disabled": true, "all_targets": true, + "include_symlinks": true, "output": "path-message" } diff --git a/test/sanity/code-smell/package-data.py b/test/sanity/code-smell/package-data.py index 43c69021378..1cf7924db93 100644 --- a/test/sanity/code-smell/package-data.py +++ b/test/sanity/code-smell/package-data.py @@ -4,6 +4,7 @@ import contextlib import fnmatch import glob import os +import pathlib import re import shutil import subprocess @@ -11,6 +12,10 @@ import sys import tarfile import tempfile +import packaging.version + +from ansible.release import __version__ + def assemble_files_to_ship(complete_file_list): """ @@ -56,21 +61,7 @@ def assemble_files_to_ship(complete_file_list): 'test/lib/ansible_test/_internal/commands/sanity/integration_aliases.py', '.cherry_picker.toml', '.mailmap', - # Generated as part of a build step - 'docs/docsite/rst/conf.py', - 'docs/docsite/rst/index.rst', - 'docs/docsite/rst/dev_guide/index.rst', # Possibly should be included - 'examples/scripts/uptime.py', - 'examples/scripts/my_test.py', - 'examples/scripts/my_test_info.py', - 'examples/scripts/my_test_facts.py', - 'examples/DOCUMENTATION.yml', - 'examples/play.yml', - 'examples/hosts.yaml', - 'examples/hosts.yml', - 'examples/inventory_script_schema.json', - 'examples/plugin_filters.yml', 'hacking/env-setup', 'hacking/env-setup.fish', 'MANIFEST', @@ -84,21 +75,12 @@ def assemble_files_to_ship(complete_file_list): # These files are generated and then intentionally added to the sdist - # Manpages - ignore_script = ('ansible-connection', 'ansible-test') - manpages = ['docs/man/man1/ansible.1'] - for dirname, dummy, files in os.walk('bin'): - for filename in files: - if filename in ignore_script: - continue - manpages.append('docs/man/man1/%s.1' % filename) - # Misc misc_generated_files = [ 'PKG-INFO', ] - shipped_files = manpages + misc_generated_files + shipped_files = misc_generated_files for path in complete_file_list: if path not in ignore_files: @@ -145,7 +127,7 @@ def clean_repository(file_list): """Copy the repository to clean it of artifacts""" # Create a tempdir that will be the clean repo with tempfile.TemporaryDirectory() as repo_root: - directories = set((repo_root + os.path.sep,)) + directories = {repo_root + os.path.sep} for filename in file_list: # Determine if we need to create the directory @@ -170,8 +152,13 @@ def clean_repository(file_list): def create_sdist(tmp_dir): """Create an sdist in the repository""" + # Make sure a changelog exists for this version when testing from devel. + # When testing from a stable branch the changelog will already exist. + version = packaging.version.Version(__version__) + pathlib.Path(f'changelogs/CHANGELOG-v{version.major}.{version.minor}.rst').touch() + create = subprocess.run( - ['make', 'snapshot', 'SDIST_DIR=%s' % tmp_dir], + [sys.executable, '-m', 'build', '--sdist', '--no-isolation', '--outdir', tmp_dir], stdin=subprocess.DEVNULL, capture_output=True, text=True, @@ -179,9 +166,10 @@ def create_sdist(tmp_dir): ) stderr = create.stderr + stdout = create.stdout if create.returncode != 0: - raise Exception('make snapshot failed:\n%s' % stderr) + raise Exception('make snapshot failed:\n%s' % stderr + '\n' + stdout) # Determine path to sdist tmp_dir_files = os.listdir(tmp_dir) @@ -341,33 +329,12 @@ def check_installed_files_are_wanted(install_dir, to_install_files): return results -def _find_symlinks(): - symlink_list = [] - for dirname, directories, filenames in os.walk('.'): - for filename in filenames: - path = os.path.join(dirname, filename) - # Strip off "./" from the front - path = path[2:] - if os.path.islink(path): - symlink_list.append(path) - - return symlink_list - - def main(): """All of the files in the repository""" - complete_file_list = [] - for path in sys.argv[1:] or sys.stdin.read().splitlines(): - complete_file_list.append(path) - - # ansible-test isn't currently passing symlinks to us so construct those ourselves for now - for filename in _find_symlinks(): - if filename not in complete_file_list: - # For some reason ansible-test is passing us lib/ansible/module_utils/ansible_release.py - # which is a symlink even though it doesn't pass any others - complete_file_list.append(filename) - - # We may run this after docs sanity tests so get a clean repository to run in + complete_file_list = sys.argv[1:] or sys.stdin.read().splitlines() + + # Limit visible files to those reported by ansible-test. + # This avoids including files which are not committed to git. with clean_repository(complete_file_list) as clean_repo_dir: os.chdir(clean_repo_dir) diff --git a/test/sanity/code-smell/package-data.requirements.in b/test/sanity/code-smell/package-data.requirements.in index 6b58f7557ac..b45e479e2bb 100644 --- a/test/sanity/code-smell/package-data.requirements.in +++ b/test/sanity/code-smell/package-data.requirements.in @@ -1,7 +1,7 @@ -docutils < 0.18 # match version required by sphinx in the docs-build sanity test +build jinja2 pyyaml # ansible-core requirement resolvelib < 0.9.0 rstcheck < 4 # match version used in other sanity tests -straight.plugin antsibull-changelog +setuptools == 45.2.0 # minimum supported setuptools diff --git a/test/sanity/code-smell/package-data.requirements.txt b/test/sanity/code-smell/package-data.requirements.txt index cf8f7c48326..626ec718736 100644 --- a/test/sanity/code-smell/package-data.requirements.txt +++ b/test/sanity/code-smell/package-data.requirements.txt @@ -2,13 +2,16 @@ # pre-build requirement: pyyaml == 6.0 # pre-build constraint: Cython < 3.0 antsibull-changelog==0.16.0 +build==0.10.0 docutils==0.17.1 Jinja2==3.1.2 MarkupSafe==2.1.1 packaging==21.3 +pyproject_hooks==1.0.0 pyparsing==3.0.9 PyYAML==6.0 resolvelib==0.8.1 rstcheck==3.5.0 semantic-version==2.10.0 -straight.plugin==1.5.0 +setuptools==45.2.0 +tomli==2.0.1 diff --git a/test/sanity/code-smell/rstcheck.json b/test/sanity/code-smell/rstcheck.json deleted file mode 100644 index 870c19ffddd..00000000000 --- a/test/sanity/code-smell/rstcheck.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "output": "path-line-column-message", - "extensions": [ - ".rst" - ] -} diff --git a/test/sanity/code-smell/rstcheck.py b/test/sanity/code-smell/rstcheck.py deleted file mode 100644 index 99917ca80ef..00000000000 --- a/test/sanity/code-smell/rstcheck.py +++ /dev/null @@ -1,62 +0,0 @@ -"""Sanity test using rstcheck and sphinx.""" -from __future__ import annotations - -import re -import subprocess -import sys - - -def main(): - paths = sys.argv[1:] or sys.stdin.read().splitlines() - - encoding = 'utf-8' - - ignore_substitutions = ( - 'br', - ) - - cmd = [ - sys.executable, - '-m', 'rstcheck', - '--report', 'warning', - '--ignore-substitutions', ','.join(ignore_substitutions), - ] + paths - - process = subprocess.run(cmd, - stdin=subprocess.DEVNULL, - stdout=subprocess.PIPE, - stderr=subprocess.PIPE, - check=False, - ) - - if process.stdout: - raise Exception(process.stdout) - - pattern = re.compile(r'^(?P[^:]*):(?P[0-9]+): \((?PINFO|WARNING|ERROR|SEVERE)/[0-4]\) (?P.*)$') - - results = parse_to_list_of_dict(pattern, process.stderr.decode(encoding)) - - for result in results: - print('%s:%s:%s: %s' % (result['path'], result['line'], 0, result['message'])) - - -def parse_to_list_of_dict(pattern, value): - matched = [] - unmatched = [] - - for line in value.splitlines(): - match = re.search(pattern, line) - - if match: - matched.append(match.groupdict()) - else: - unmatched.append(line) - - if unmatched: - raise Exception('Pattern "%s" did not match values:\n%s' % (pattern, '\n'.join(unmatched))) - - return matched - - -if __name__ == '__main__': - main() diff --git a/test/sanity/code-smell/rstcheck.requirements.in b/test/sanity/code-smell/rstcheck.requirements.in deleted file mode 100644 index 5b93841d36b..00000000000 --- a/test/sanity/code-smell/rstcheck.requirements.in +++ /dev/null @@ -1,3 +0,0 @@ -sphinx == 4.2.0 # required for full rstcheck functionality, installed first to get the correct docutils version -rstcheck < 4 # match version used in other sanity tests -jinja2 # ansible-core requirement diff --git a/test/sanity/code-smell/rstcheck.requirements.txt b/test/sanity/code-smell/rstcheck.requirements.txt deleted file mode 100644 index 81d5c4f0fc3..00000000000 --- a/test/sanity/code-smell/rstcheck.requirements.txt +++ /dev/null @@ -1,25 +0,0 @@ -# edit "rstcheck.requirements.in" and generate with: hacking/update-sanity-requirements.py --test rstcheck -alabaster==0.7.12 -Babel==2.10.3 -certifi==2022.9.14 -charset-normalizer==2.1.1 -docutils==0.17.1 -idna==3.4 -imagesize==1.4.1 -Jinja2==3.1.2 -MarkupSafe==2.1.1 -packaging==21.3 -Pygments==2.13.0 -pyparsing==3.0.9 -pytz==2022.2.1 -requests==2.28.1 -rstcheck==3.5.0 -snowballstemmer==2.2.0 -Sphinx==4.2.0 -sphinxcontrib-applehelp==1.0.2 -sphinxcontrib-devhelp==1.0.2 -sphinxcontrib-htmlhelp==2.0.0 -sphinxcontrib-jsmath==1.0.1 -sphinxcontrib-qthelp==1.0.3 -sphinxcontrib-serializinghtml==1.1.5 -urllib3==1.26.12 diff --git a/test/sanity/ignore.txt b/test/sanity/ignore.txt index 1a588c0af90..869522b1102 100644 --- a/test/sanity/ignore.txt +++ b/test/sanity/ignore.txt @@ -1,9 +1,4 @@ .azure-pipelines/scripts/publish-codecov.py replace-urlopen -docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst no-smart-quotes -docs/docsite/rst/locales/ja/LC_MESSAGES/dev_guide.po no-smart-quotes # Translation of the no-smart-quotes rule -examples/scripts/ConfigureRemotingForAnsible.ps1 pslint:PSCustomUseLiteralPath -examples/scripts/upgrade_to_ps3.ps1 pslint:PSCustomUseLiteralPath -examples/scripts/upgrade_to_ps3.ps1 pslint:PSUseApprovedVerbs lib/ansible/cli/scripts/ansible_connection_cli_stub.py shebang lib/ansible/config/base.yml no-unwanted-files lib/ansible/executor/playbook_executor.py pylint:disallowed-name