#Persistent Connect(2.4以前)について
Ansible 2.4以前のNWモジュールにはPersistent Connectという機能があり、
初回でSSHセッションを確立したらその後のPlaybook内の後続タスクや別Playbookにおいても
SSHセッションが引き継がれるので、セッション確立のオーバーヘッドが削減できてNW機器側にも負荷
かけずにNW機器へのコマンド投入ができる。
参照：akira6592さんのPersistentConnectionについて解説記事
Ansible ネットワークモジュールの Persistent Connections 利用方法と注意点
###2.4のPersistent Connectの問題について
2.4以前のPersistent Connectに関しては同一機器に対して、別々に実行するPlaybookでの同時実行に
問題があり、同一セッション上で処理を流すためステートの一貫性が崩れて処理エラーを起こす不具合があった。
#####概要
Playbook実行プロセスAおよびBが同一機器に対して、ほぼ同タイミングで実行していた。
A) configure session 123 [global->conf]
A) int eth 1/1 [conf->int eth 1/1]
B) configure session 123 [int eth 1/1->conf]
A) lacp priority 32768 [incorrect command for conf]
B) int eth 1/2 [conf->int eth 1/2]
A) abort [int eth 1/2 -> ?]
B) lacp priority 32768 [incorrect command for ?]
→Bの「configure session 123」で、同一セッションなのでconfモードにステートが戻ってしまい、
Aの後続の「 lacp priority 32768」でコマンド実行が失敗してしまった。
→2.4以前では同一機器に対する複数Playbookの同時実行は担保されない仕組みとなっているので、
上位側でシリアライズする機構の実装が必須となる。
#Persistent Connect(2.5以後)について
Ansible blogにて以下のアナウンスがあり、
2.5以降はplaybookごとにSSHコネクションが切断される仕様となる方針となった。
2.4で抱えていた問題を改修したため、複数Playbookでの同一機器への処理実行に関してはSSHコネクションの再利用性がなくなり、
セッション確立のオーバーヘッドおよびNW機器側へのコネクションの切断・接続の負荷がかかる仕様となっている。
以下、Ansible blog記事の原文
Additional SSH behavior improvements have also been included. With Ansible 2.3 and
2.4, the persistent SSH connection remained open for 30 seconds after
the playbook completed. In Ansible 2.5, this socket is shut down
immediately at the end of a playbook run. This removes the possibility
that the socket could be exploited or misused by another program or process.
###当該のバグチケットおよびコミットログ
本方針になる過程には二つのコミットがあった。
socketファイルをPlaybookの実行プロセスIDごとに生成する改修のコミット
https://github.com/ansible/ansible/pull/33518
Playbookが終わるたびにPersistent Connectionを切るコミット
https://github.com/ansible/ansible/pull/32825