Ansible2.6 から Ansible 2.7
Python で実装された構成管理ツール Ansibleについて、
各バージョンでの違いをまとめた "Ansible Migration Guide" を翻訳しています。
コマンドライン
コマンドラインで --tags または --skip-tags を複数回指定すると、Ansible は指定されたタグをまとめます。 以前のバージョンの Ansible では、最後に指定された --tags だけを残したい場合、merge_multiple_cli_tags を False に設定することができました。 この設定オプションは下位互換性のために存在しました。 上書きの動作は Ansible 2.3で廃止されていて、デフォルトの挙動は Ansible 2.4で変更されました。 Ansible 2.7 では config のオプションが削除されます。複数タグはいつもまとめられるようになりました。
merge_multiple_cli_tags を False に設定することに依存しているシェルスクリプトをお持ちの場合は、スクリプトを修正して、Ansible 2.7にアップグレードする前に実際に必要な --tags を追加するようにしてください。
Python との互換性
Ansibleは Python 2.6との互換性はなくなっています。（/usr/bin/ansible または /usr/bin/ansible-playbook が実行されるホストでの制限）。 Ansible に同梱されているモジュールは、Python 2.6 のみを持つホストの管理にも使用できますが、Ansible を実行するホストには Python 2.7 または Python 3.5以上が必要となります。
これが影響するのは、Python 2.6を持つホストを管理するために /usr/bin/ansible-pull を使用しているときです。 ansible-pull は管理対象のホスト上で動作しますが、モジュールではなくコントローラスクリプトであるため、更新されたPythonが必要になります。積極的に開発されているいLinuxディストリビューションには、新しいPythonバージョンをインストールする方法があります（たとえば、Python-2.7をRHEL 6のSCLでインストールできます）。 （RHEL 6では、更新された Pythonのインストールのためにselinuxバインディングと yum をインストールする必要があります）。
多くの依存ライブラリが利用できなくなっているため、Python 2.6サポートをしないこと決定されました。特に、Python 2.6では python-cryptography が使用できなくなり、pycryptoの最後のリリース（python-cryptographyの代替）には決して修正されないセキュリティバグの存在が知られています。
プレイブック
ロールの読み込み中のロールの優先順位の修正
Ansible 2.7では、ロールの読み込み時に変数の優先順位が少し変更されて、バグを解決しロールの読み込みがvars 優先順位の期待値と一致するようになりました。
以前のバージョンでは、ロールの tasks/main.yml ファイルを解析するときに、ロールのロード時に、ロールの vars/main.yml とdefaults/main.yml で定義された変数を使用できませんでした。 これは、import_tasks または import_role がロールの変数またはデフォルトで定義された変数とともに使用されたときに問題が発生するために、パース時にこれらの変数を利用することができませんでした。
Ansible 2.7では、ロール の vars と defaults は task/main.yml の前に解析されるようになりました。 これにより、import_tasks または import_role を利用してインポートするロールまたはファイルを定義すると、同じ変数が実行時のレベルとにロールレベルで異なる値で定義されるため動作が変更される可能性があります。
include_roleおよびimport_role での変数の扱い
Ansible 2.7では、public という名前の新しいモジュール引数がinclude_role モジュールに追加されていて、ロールのdefaultsとvars がロール外に公開されるかどうかが決定されて、それらの変数を後のタスクで使用できるようになりました。 この値のデフォルトは public : False で、現在の動作に一致します。
import_role は public 引数をサポートしておらず、無条件にロールの defaults と vars をプレイブックの他の部分に公開します。この機能により、import_role は、実行中のロールヘッダー内にリストされているロールと同じ内容になります。
import_role（静的）ではなく、include_role（動的）がロールの変数を公開する方法には重要な違いがあります。 import_role はプリプロセッサであり、defaults および vars は、プレイブックの解析時に評価され、実行中の任意のポイントにリストされたタスクとロールで使用可能な変数になります。 include_role は条件付きタスクで、実行時に defaults と vars が評価され、タスクとロールで使用可能な変数が include_role タスクの後にリストされます。
include_roleとinclude_tasks / import_tasksのインライン変数
Ansible 2.7の時点で、include_tasks と import_tasks はインライン変数を受け入れなくなりました。 インライン変数を使用する代わりに、タスクは変数を vars キーワードで指定する必要があります。
旧: Ansible 2.6（およびそれ以前）では、変数を指定するための有効な構文は次のとおりです。
code: ansible
- include_tasks: include_me.yml variable=value
新: Ansible 2.7 では、変数は vars キーワードで指定するようになりました。
code: ansible
- include_tasks: include_me.yml
vars:
variable: value
未知のアルゴリズムでの vars_prompt
暗号化で指定されたハッシュアルゴリズムがコントローラによってサポートされていない場合、vars_prompt はエラーとなりましう。 このことは、アルゴリズムが未知の場合に、以前では None を返していたので、 vars_prompt の安全性を向上させます。 一部のモジュール、特にuserモジュールは、パスワードを設定しないときに、None をパスワードとして扱いました。 このため、プレイブックでエラーが発生した場合は、このフィルタで使用されているハッシングアルゴリズムを変更するようにしてください。
廃止予定
非推奨が早められました：AnsibleModuleでの__file__の使用
__file__ 変数の使用はAnsible 2.7では非推奨となり、Ansible 2.8では廃止されます。
これは、通常の4リリースおきの非推奨サイクルよりも大幅に早められています。
現在実行中のコードを含むファイルを参照するために__file__ 変数を使用することは非推奨となります。 ファイルシステムのパスを見つけるための一般的なPythonのテクニックは、（オリジナルのPythonでさえも）うまくいくとは限りません。 場合によっては、Pythonモジュールを仮想的な場所（zipファイルの中など）からインポートすることもできます。 これが起こると、__file__変数はzipファイルの内部を指す仮想的な場所となってしまいます。 例えば、コードが__file__ を使用して、一時的な情報を書き込むためのpythonモジュールを含むディレクトリを見つけようとしていた場合、これは問題を引き起こす可能性があります。
Ansible 2.1 で AnivesBallZを が導入される以前では、 __file__ を使用してもAnsibleModuleで動作することがありましたが、パイプラインがオンになったときにモジュールを使用したモジュールは失敗します（モジュールはPythonインタプリタの標準入力にパイプされるため、__file__ には ファイルパスが存在しない）。 AnsiBallZは意図的に__file__ を使用して作成され、AnipalModuleが常駐する一時ファイルを常に作成します。
Ansible 2.8は、AnipalModuleの一時ファイルを作成しなくなります。 代わりに、zipファイルからファイルを読み込みます。 この変更はモジュールの実行を高速化するはずですが、Ansible 2.8 からは、__file__を参照すると、常にAnsibleModuleで失敗することになります。
AnifyingModuleで__file__を使用しているようなサードパーティ製モジュールの開発者であれば、__file__の使用は非推奨であるもののまだ利用可能ですが、そうでなければモジュールを今すぐ更新するようにしてください。 __file__ の最も一般的な使い方は、一時ファイルを書き込むディレクトリを見つけることです。
Ansible 2.5以降では、apt モジュールのこのコードに示すように、代わりにAnsibleModuleインスタンスのtmpdir 属性を使用できます。
code: 変更箇前
tempdir = os.path.dirname(__file__)
package = os.path.join(tempdir, to_native(deb.rsplit('/', 1)1)) code: 変更後
package = os.path.join(module.tmpdir, to_native(deb.rsplit('/', 1)1)) squash_actionsによるパッケージモジュールのループの使用
yum のようなパッケージモジュールを呼び出すための squash_actions の使用は非推奨となり、Ansible 2.11では削除されます。
暗黙的なsquash_actions ではなく、タスクは、モジュールの名前、パッケージ、パッケージパラメータを設定する必要があります。 この機能は、Ansible 2.3 以降、ほとんどのモジュールでサポートされています。
旧: Ansible 2.6（およびそれ以前のバージョン）では、以下のタスクは "yum"モジュールを1回だけ呼び出して複数のパッケージをインストールします
code: ansible
- name: Install packages
yum:
name: "{{ item }}"
state: present
with_items: "{{ packages }}"
新: Ansible 2.7 では次のように変更する必要があります。
code: ansible
- name: Install packages
yum:
name: "{{ packages }}"
state: present
モジュール
一般的なモジュールの主な変更点について説明します。
DEFAULT_SYSLOG_FACILITY 設定オプションは、すべての管理対象マシンの情報を記録するときに、特定のsyslog ファシリティーを使用するように Ansible モジュールに指示します。 以前のバージョンのAnsible ではバグのため、この設定は、システム にインストールされている Python と journald を使用するマシンには効果がありませんでした。 これらのマシンでは、DEFAULT_SYSLOG_FACILITY を設定しても、Ansibleログメッセージが /var/log/messages に送信されていました。 Ansible 2.7 ではこのバグが修正されて、DEFAULT_SYSLOG_FACILITY に設定された値に従ってすべてのAnsibleログメッセージを処理します。 DEFAULT_SYSLOG_FACILITY が設定されている場合、journaldを使用するシステム上のリモートログの場所が変更されることがあります。
廃止されてたモジュール
このバージョンで廃止されたモジュールはありません。
非推奨のモジュール
以下のモジュールは、Ansible 2.11で削除されます。 既存のプレイブックを修正するようにしてください。
na_cdot_aggregate : 代わりに na_ontap_aggregate を使うように。
na_cdot_license : 代わりに na_ontap_license を使うように。
na_cdot_lun : 代わりに na_ontap_lun を使うように。
na_cdot_qtree : 代わりに na_ontap_qtree を使うように。
na_cdot_svm : 代わりに na_ontap_svm iを使うように。
na_cdot_user : 代わりに na_ontap_user を使うように。
na_cdot_user_role : 代わりに na_ontap_user_role iを使うように。
na_cdot_volume : 代わりに na_ontap_volume を使うように。
sf_account_manager : 代わりに na_elementsw_account を使うように。
sf_check_connections : 代わりに na_elementsw_check_connections を使うように。
sf_snapshot_schedule_manager : 代わりに na_elementsw_snapshot_schedule を使うように。
sf_volume_access_group_manager : 代わりに na_elementsw_access_group を使うように。
sf_volume_manager : 代わりに na_elementsw_volume を使うように。
注目すべきモジュールの変更点
チェックモードが commnd と shell モジュールでサポートされるようになりました。 ただし、creates もしくは removes が指定されている場合のみ利用可能です。 このどちらかが指定されている場合、モジュールはファイルの存在をチェックし、正しい変更された状態を報告します。含まれていない場合、モジュールは以前のようにスキップします。
win_chocolatey モジュールは、もともと proxy_usernameとproxy_password の値としての二重引用符をエスケープする必要がありました。 これは必要なくなっていますので、エスケープすることで余計な問題が生じる可能性があります。
win_uri module は削除され、オプション use_basic_parsing は非推奨となっています。Ansible 2.5 からこのオプションは存在していません。
win_scheduled_task モジュールは次の非推奨のオプションが削除されています：
executable : アクションでは代わりに path 使うこと。
argument : アクションでは代わりに arguments を使うこと。
store_password : 代わりに logon_type: password を使うこと。
days_of_week : トリガーでは代わりに monthlydow を使うこと。
frequency : トリガーでは代わりに type を使うこと。
time : トリガーでは代わりに start_boundary を使うこと。
na_ontap_net_vlan の interface_nameモジュールオプションは削除されているため、プレイブックから削除する必要があります
win_disk_imageモジュールの戻り値 mount_path は非推奨になりました。代わりに mount_paths [0] を使用するようにしてください。 mount_path は Ansible 2.11で削除されます。
include_role と include_tasks は （限定的に) Ansible と ansible-console から直接使えるようになりました。
code: commandline
# ansible -m include_role -a 'name=myrole' all
プレグイン
指定されたハッシュアルゴリズムがコントローラによってサポートされていない場合、hash_password フィルタはエラーを発行するようになりました。 これにより、アルゴリズムが未知の場合には、以前は None が 返されていたことが、フィルターの安全性が向上します。 一部のモジュール、特に user モジュールは、パスワードを設定しない場合、None をパスワードとして扱っていました。 プレイブックでエラーが発生した場合は、このフィルタで使用されているハッシングアルゴリズムを変更するようにしてください。
ネットワーキング
このバージョンで変更された項目はありません。