[Ansible] assert モジュールと ansible.utils.fact_diff フィルターを組み合わせてエラーメッセージをわかりやすくする

はじめに

以前の記事でもご紹介した、ansible.utils.fact_diff フィルター のちょっとした活用方法です。

ansible.utils.fact_diff 「モジュール」ではなく「フィルター」なので、別のモジュールのオプションに組み込めます。

この特性を活用して、ansible.builtin.assert モジュールとの組わせ例を試します。

• 検証環境
  • ansible-core 2.16.0
  • ansible.utils 3.0.0

サンプル

Playbook は以下の通り。 ディクショナリー dict1 と dict2 を定義し、それが同じかどうかを ansible.builtin.assert モジュール で確認します。

デフォルトでは条件を満たさなかった（ここでは同じでない場合）場合は、割とシンプルなエラーメッセージになります。

そこで、ansible.utils.fact_diff フィルターを利用して、どこが異なるかの差分をエラーメッセージとして表示します。

---
- hosts: localhost
  gather_facts: false
  connection: local

  vars:
    dict1:
      name: sakana
      size: 23
      memo: hoghoge
    dict2:
      name: sakana
      size: 24
      memo: hoghoge

  tasks:
    - name: assert test
      ansible.builtin.assert:
        that:
          - dict1 == dict2
        fail_msg: "{{ dict1 | ansible.utils.fact_diff(dict2) }}"

結果は以下の通りです。両 ディクショナリ内の size が異なることが分かります。

TASK [assert test] ********************************************************************************************************
fatal: [localhost]: FAILED! => {
    "assertion": "dict1 == dict2",
    "changed": false,
    "evaluated_to": false,
    "msg": [
        "--- before",
        "+++ after",
        "@@ -1,5 +1,5 @@",
        " {",
        "     \"memo\": \"hoghoge\",",
        "     \"name\": \"sakana\",",
        "-    \"size\": 23",
        "+    \"size\": 24",
        " }",
        ""
    ]
}

なお、failed_msg を定義しない場合は以下のようなメッセージになります。

TASK [assert test] *********************************************************
fatal: [localhost]: FAILED! => {
    "assertion": "dict1 == dict2",
    "changed": false,
    "evaluated_to": false,
    "msg": "Assertion failed"
}

[Ansible] パス文字列からディレクトリ名や親ディレクトリ名を遡って抽出する

はじめに

Ansible には、パス文字列からディレクトリを抽出するための ansible.builtin.dirname というフィルターがあります。

正規表現などのパターンマッチングするより、こういう専用のフィルターがあるならそれを使うのが良いかなと思います。

応用すると、ファイルからみて親の親の親の・・ディレクトリ名を抽出できたりもします。

簡単ですが検証結果をまとめます。

• 検証環境
  • ansible-core 2.16.0

サンプル

---
- hosts: localhost
  gather_facts: false
  connection: local

  vars:
    # 対象のパス文字列
    file_path: /dir1/dir2/dir3/file.txt

  tasks:
    - name: dirname test 1
      ansible.builtin.debug:
        msg: "{{ file_path | dirname }}"           # /dir1/dir2/dir3

    - name: dirname test 2
      ansible.builtin.debug:
        msg: "{{ file_path | dirname | dirname }}" # /dir1/dir2

「Pythonとネットワークの自動化基礎検定」を受験してきました

はじめに

周囲のエンジニアは息を吸うように色々受験（そして合格）されているようなのですが、私はしばらく何もやっていませんでした。確か直近は、4年前の DevNet Associates（失効）。

久々に、なにかやってみとうと思っていたところ「Pythonによるネットワーク自動化の教科書」といいう書籍経由で「Pythonとネットワークの自動化基礎検定」という検定があることを知りました。

興味がある分野だったので受けることにしました。

「Pythonとネットワークの自動化基礎検定」とは

ざっくり、Python の基礎と、netmiko、NAPALM などネットワーク機器の操作に便利なライブラリと、Excelファイルを読み書きできるライブラリの基本的な使い方といったところです。

範囲としてはそこまで広くないと思います。

詳細は公式サイトまで。

network-engineer.jp

勉強方法

前述の「Pythonによるネットワーク自動化の教科書」が公式テキストという扱いなので、これをベースに進めていきました。

本書のサンプルプログラムで扱うネットワーク機器は Cisco IOS と YAMAHA です。

Pythonによるネットワーク自動化の教科書

ライブラリの使い方は眺めてるだけだと覚えられないので、実際に書いて動かしました。

netmikoや NAPALM については、チュートリアルレベルでは動かしたことがあるのでとっつきやすかったです。（古い資料。当時は netmiko は YAMAHA未対応）

subprocess、telnetlib、openpyxl は多分触るのがはじめでした。

書籍には「オブジェクト」や「インスタンス」という言葉が説明なく出てきますので、ピンとこない場合はネットや他書籍などで補足が必要そうです。

受験日当日

テストセンター的なところで CBT で受験しました。

会場で受け取る紙のレポートに合否が書いてなくて不安ですが、点数的には合格ラインを超えていたのでたぶん大丈夫だと思います。

[2024/01/08 追記] CBT-S 受験者専用サイトの試験履歴の合否欄もしばらく「-」という表記でしたが、翌日には合格と書かれたPDFが見れるようになってました。

どんな人におすすめか

Python やプログラミングに興味があるけど、普段はネットワーク機器を触っているから、ネットワークに関係あるプログラムのほうがモチベーションが湧く、という人には良いかなと思いました。

他の資格を基準にすると「Python 3 エンジニア認定基礎試験」に合格されている方（または相当）は、だいぶ有利だと思います。求められる Python 自身の知識は「Python 3 エンジニア認定基礎試験」より少なくて良い印象です。

知らないライブラリは・・、触るしかないですかね。

おわりに

久々に受験しました。

あらためて、息を吸うようにいろいろ受験されている方々はすごいなぁと思いました。

[Ansible] コミュニティから公開されている Execution Environment（ただし2023年12月現在用途は限定的）

はじめに

ここ数年で、Ansible をコンテナ上で動かそうという動きが加速しています。

logmi.jp

そうは言われても、自分でビルドするにはまだハードルが・・、という方もいらっしゃるかもしれません。Ansible Community として GitHub Container Registory で公開されているイメージがあるのでご紹介します。

Ansible ecosystem documentation のページでも紹介されています。

ただし、リポジトリでは現状、以下の注意書きがあります。

Please note that this repository is very much a proof of concept and a work in progress at this time.

また、開発やテスト、CI 目的であり、本番環境では使わないで、とのことです。

Images provided by this repository are tailored for development, testing and CI purposes. They are maintained by the community and are not supported by Red Hat: they can and will break or run out of maintenance. Do not use these images for production!

以上の位置付けであることをご留意ください。

Minimal Ansible Community Execution Environment

Package community-ee-minimal · GitHub

ansible-core が入っています。Minimal なのでコレクションは入っていません。

元ネタの execution-environment.yml はこちらのようです。

images/execution-environments/community-ee-minimal/execution-environment.yml at main · ansible-community/images · GitHub

今回はタグ 2.16.1-1 の中身を見ていきます。

Fedora 39 ベース:

$ ansible-navigator images --eei ghcr.io/ansible-community/community-ee-minimal:2.16.1-1 -m stdout -d os_release 

---
image_name: ghcr.io/ansible-community/community-ee-minimal:2.16.1-1
os_release:
  details:
  - ansi-color: 0;38;2;60;110;180
    bug-report-url: https://bugzilla.redhat.com/
    cpe-name: cpe:/o:fedoraproject:fedora:39
    default-hostname: fedora
    documentation-url: https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/
    home-url: https://fedoraproject.org/
    id: fedora
    logo: fedora-logo-icon
    name: Fedora Linux
    platform-id: platform:f39
    pretty-name: Fedora Linux 39 (Container Image)
    redhat-bugzilla-product: Fedora
    redhat-bugzilla-product-version: '39'
    redhat-support-product: Fedora
    redhat-support-product-version: '39'
    support-end: '2024-05-14'
    support-url: https://ask.fedoraproject.org/
    variant: Container Image
    variant-id: container
    version: 39 (Container Image)
    version-codename: ''
    version-id: '39'

ansible-core 2.16.1:

$ ansible-navigator images --eei ghcr.io/ansible-community/community-ee-minimal:2.16.1-1 -m stdout -d ansible_version
---
ansible_version:
  details: ansible [core 2.16.1]
image_name: ghcr.io/ansible-community/community-ee-minimal:2.16.1-1

community-ee-minimal にはコレクションがないのでエラー

$ ansible-navigator images --eei ghcr.io/ansible-community/community-ee-minimal:2.16.1-1 -m stdout -d ansible_collections
---
ansible_collections:
  details: {}
  errors:
  - |-
    ERROR! - None of the provided paths were usable. Please specify a valid path with --collections-path
image_name: ghcr.io/ansible-community/community-ee-minimal:2.16.1-1

Python 3.12.0:

$ ansible-navigator images --eei ghcr.io/ansible-community/community-ee-minimal:2.16.1-1 -m stdout -d python_version
---
image_name: ghcr.io/ansible-community/community-ee-minimal:2.16.1-1
python_version:
  details:
    version: 3.12.0 (main, Oct  2 2023, 00:00:00) [GCC 13.2.1 20230918 (Red Hat 13.2.1-3)]

Base Ansible Community Execution Environment

Package community-ee-base · GitHub

元ネタの execution-environment.yml はこちらのようです。

images/execution-environments/community-ee-base/execution-environment.yml at main · ansible-community/images · GitHub

Mnimam にはない、以下の3つのコレクションが入っています。

$ ansible-navigator images --eei ghcr.io/ansible-community/community-ee-base:2.16.1-1 -m stdout -d ansible_collections
---
ansible_collections:
  details:
    ansible.posix: 1.5.4
    ansible.utils: 2.11.0
    ansible.windows: 2.1.0
image_name: ghcr.io/ansible-community/community-ee-base:2.16.1-1

おまけ

ほか、よく見かけるのは以下のイメージあたりでしょうか

• ghcr.io/ansible/creator-ee
• quay.io/ansible/awx-ee

参考

経緯

forum.ansible.com

Forumの紹介

Ansible Community Forum でも New & Announcements にて新しいーメージ公開のお知らせがされます。

例:

forum.ansible.com

リリースプロセス

現在、イメージのリリースプロセスうに関するドキュメントの記述の PR がでています。

github.com

[Ansible] ansible-core 2.16 で --ask-vault-passowrd と同機能の -J が使えるようになった

はじめに

ansible-vault で暗号化したファイルを復号してPlaybook内で利用する際、復号パスワードを対話的に入力するためのオプションとして、--ask-vault-password、--ask-vault-pass があります。

ansible-core 2.16.0 でこれらと同じ用途として -J オプションが追加されました。

 % ansible-playbook -h
...(略)...
  -J, --ask-vault-password, --ask-vault-pass
                        ask for vault password
...(略)...

2.16.0 changelogより

cli - Added short option '-J' for asking for vault password (#80523).

今回はこのオプションを試します。

• 検証環境
  • ansible-core 2.16.1

おためし

Playbook:

---
- hosts: localhost
  gather_facts: false
  connection: local

  tasks:
    - name: Debug Vault string
      ansible.builtin.debug:
        msg: "{{ vaulted_msg }}"   # 暗号化済み

-J オプションを指定してみます。

% ansible-playbook -i localhost, vault.yml -J
Vault password:   (パスワードを入力)

PLAY [localhost] **************************************************************************************************

TASK [debug] ******************************************************************************************************
ok: [localhost] => {
    "msg": "himitsuno_mojiretsu"
}

PLAY RECAP ********************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 

一応、従来からあった --ask-vault-pass オプションも確認します。

% ansible-playbook -i localhost, vault.yml --ask-vault-pass
Vault password:   (パスワードを入力)

PLAY [localhost] **************************************************************************************************

TASK [Debug Vault string] *****************************************************************************************
ok: [localhost] => {
    "msg": "himitsuno_mojiretsu"
}

PLAY RECAP ********************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 

おわりに

手動ででよく --ask-vault-pass を入力されていた方にとっては、指定が簡単になって便利かなと思います。

-J というオプションになった理由は、機能提案者が記載しています。

[Ansible] 2023年の Ansible 関連リリースや動向まとめ

この記事は Ansible Advent Calendar 2023 の 24日目の記事です。

はじめに

2023年も例年通り ansible-core や AAP （Ansible Automation Platform）がバージョンアップされました。

他にも、生成AIの波が本格化してきたり、EDA（Event-Driven Ansible）が GA されたり、公式ドキュメントの管理方法が変わったりなどの動きもありました。

この記事では、個人的にポイントだと思った Ansible 関連リリースや動向をまとめます。

2022年版はこちら

リリース

AAP 2.4 リリース

今年は AAP (Ansible Automation Platform) 2.4 がリリースされました。含まれる Automation Controller のバージョンは 4.4 系。

後述する EDA（Event-Driven Ansible）が入ってきたのが特徴です。

ほかにも Molecule 6 が developer preview 扱いで AAP に入りました。

Ansible Molecule 6 is now available as a developer preview with Red Hat Ansible Automation Platform.

Introducing Ansible Molecule with Ansible Automation Platform | Red Hat Developer

EDA（Event-Driven Ansible）が GA

今年リリースされた AAP 2.4 に EDA（Event-Driven Ansible）が含まれるようになりました。

イベント（ログに特定の文字列が含まれていたら、など）をトリガーとして Playbook を実行する仕組みで、人が介在しない世界観の Ansible です。

EDA という言葉自体は 2022 年からあって、ソリューション名というか総称のようなものだと思います。当時は具体的なモノとしては ansible-rulebook という CLI ツールしか見当たりませんでした。

今回は、ansible-rulebook を Web GUI から操作できる EDA Controller というモノが追加されました。ansible-playbook と Auotmation Controller の関係と同じですね。

なお、AAP 2.3 では Preview 扱いでした。

rheb.hatenablog.com

www.ansible.com

tekunabe.hatenablog.jp

Red Hat Ansible Lightspeed with IBM watsonx Code Assistant が GA

生成 AI によって Playbook 作成を効率化する Red Hat Ansible Lightspeed with IBM watsonx Code Assistant が GA になりました。

cloud.watch.impress.co.jp

去年あたりまでは Project Wisdom と呼ばれることがあり、preview 段階を経て今に至りました。

以下の公式記事によると、

Red Hat Ansible Lightspeed は現在、Ansible Automation Platform のサブスクリプションで一般提供されており、IBM watsonx Code Assistant は別途購入できます。

とのことです。

Red Hat、AI主導のエンタープライズIT自動化を実現するRed Hat Ansible Lightspeed with IBM watsonx Code Assistantを発表

rheb.hatenablog.com

AAP 1.2 のサポート終了

2023年9月29日 に「Maintenance support 2」も終りを迎えました。

access.redhat.com

「Extended life cycle support (ELS) add-on 」が新設されたようですが、一定の条件があるようです。

ansible-core 2.14.0 以上が要件のコレクションが続々と

様々なコレクションで、ansible-core 2.14.0 以上を要件とする動きがでてきました。

例えば以下のコレクションです。

• ansible.utils 3.0.0
• ansible.netcommon 6.0.0
• cisco.ios 6.0.0

ansible-core 2.15 / Ansible 8リリース

2023年5月に、ansible-core 2.15 系がリリースされました

• Changelog: ansible/changelogs/CHANGELOG-v2.15.rst at stable-2.15 · ansible/ansible · GitHub
• Porting Guide: Ansible-core 2.15 Porting Guide — Ansible Core Documentation

Ansible Community Package (pip install ansible でインストールされるもの) としても、ansible-core 2.15 系を含む バージョン 8 が続いてリリースされました。

• Changelog: ansible-build-data/8/CHANGELOG-v8.rst at main · ansible-community/ansible-build-data · GitHub
• Porting Guide: Ansible 8 Porting Guide — Ansible Documentation

ansible-core 2.15 の特徴は、vars 直下にリストで変数定義するほう方法が非推奨になったことかなと思います。

tekunabe.hatenablog.jp

サポートされる Python のバージョンには変化がないため、比較的インパクトは小さめと捉えています。

ansible-core 2.16 / Ansible 9リリース

2023年11月に、ansible-core 2.16 系がリリースされました。

• Changelog: ansible/changelogs/CHANGELOG-v2.16.rst at stable-2.16 · ansible/ansible · GitHub
• Porting Guide: Ansible-core 2.16 Porting Guide — Ansible Core Documentation

Ansible Community Package (pip install ansible でインストールされるもの) としても、ansible-core 2.16 系を含む バージョン 9 が続いてリリースされました。

• Changelog: ansible-build-data/9/CHANGELOG-v9.rst at main · ansible-community/ansible-build-data · GitHub
• Porting Guide: Ansible 9 Porting Guide — Ansible Documentation

ansible-core 2.16 の特徴は、サポートされる Python のバージョンが引き上げられたことです。

• コントロールノード（Ansibleをインストールするマシン）での Python 3.9 サポートの削除
• マネージドノード（自動化対象のマシン）での Python 3.5 サポートの削除

なお、2024年リリース予定の ansible-core 2.17 では、マネージドノード側の Python 2.7 サポートが削除される予定です。サーバーを自動化対象にしている場合は、影響がそれなりにあるかもしれません。

サポートされる Python のバージョンは、以下の「ansible-core support matrix」という表がわかりやすいです。

docs.ansible.com

ansible-builder 3.0.0 リリース

1系から2系を飛ばして 3.0.0 がリリースされました。

github.com

大きく変わったのは、ベースイメージとしてバニライメージ（ここでは ansible が入ってないイメージのこと）を選択できるようになったことです。

execution-environment.yml というビルド定義ファイルのフォーマットは version: 3 が最新になりました。

自分で明示的に指定するものが増えた傾向にありますが、柔軟さは増しました。

関連しますが、quay.io/repository/ansible-runnerはメンテナンスされなくなりました。

コミュニティ・ドキュメント

Ansible Galaxy がリニューアル

Ansible Collection の確認、公開、ダウンロードができるサイト、Ansible Galaxy がリニューアルされました。

galaxy.ansible.com

個人的には、バージョンごとにドキュメントを切り替えられるのが便利になったなと思います。

tekunabe.hatenablog.jp

また、リニューアル後はしばらく https://galaxy.ansible.com/ansible/utils のような旧サイト形式のコレクションの URL が自動リダイレクトされず少々不便でした。現在は https://galaxy.ansible.com/ansible/utils であれば、https://galaxy.ansible.com/ui/repo/published/ansible/utils/ にリダイレクトされます。

なお、旧サイトは現状 https://old-galaxy.ansible.com/ で参照できます。

Ansible 公式ドキュメントの管理リポジトリを本体から分離

これまで、ドキュメントは本体と同じく、ansible/ansible というリポジトリの docs ディレクトリを中心に管理していました。

今年、本体から分離しようという提案があり、ansible/ansible-documentation に分離されました。

Ansible Community Forum 公開

Community としてコミュニケーションできる新たな場として、Forum が公開されました。技術的な Q&A やディスカッション、イベント情報などがあります。

forum.ansible.com

私も質問したら回答していただいて、関連したドキュメント追記の PR まで出していただいて、大変有用な場として活用させていただいています。

自己紹介スレッドもあります。

（宣伝）Ansible実践ガイド 第4版［基礎編］が発売

共著で携わった「Ansible実践ガイド 第4版［基礎編］」が2023年6月に発売されました。

book.impress.co.jp

入門者向けに内容を見直し、ボリューム（と価格）を抑えつつ、ansible-core 2.14 に対応しました。

techblog.ap-com.co.jp

おわりに

2023年の Ansible 関連の気になったリリースや動向をまとめました。

大きなリリースもあったり、コミュニティのフォーラムができたり動きがあった一年だったなとふりかえって思いました。

2024年は Lightspeed の強化があるのではないかなと予想しています。ほか、ansible-core 2.17 でのマネージドノードの Python 2.7 サポート削除や、AAP としての molecule の動向も気になっています。

[Ansible] ansible-core 2.16 からタスクの成功を条件とするリトライには until が不要になった

この記事は Ansible Advent Calendar 2023 の 18日目の記事です。

はじめに

これまで、retries を指定していても until の指定がない場合は、リトライ処理が行われませんでした。

ansible-core 2.16 (Ansible community Package としては 9)で、タスクの成功を条件とする場合は until の指定が不要になりました。

CHANGELOG から引用

the retries keyword can be specified without until in which case the task is retried until it succeeds but at most retries times

これまでとの比較や、今回の書き方を試した結果をまとめます。

• 検証環境
  • ansible-core 2.16

そもそも until と retries とは

Anislbe には「タスクの実行結果が○○になるまでそのタスクの実行を繰り返す」機能があります。

条件は until ディレクティブで指定します。例えば以下のような条件を指定できます。

• タスクの実行が成功するまで
• 実行結果内の x の値が true になるまで

また、最大何回リトライするか指定する retries というディレクティブがあります。

たとえば、タスクの実行が成功するまで最大3回リトライするす場合、今までは以下のよう指定する必要がありました。

    - name: Get request until success
      uri:
        url: https://192.168.1.30
        validate_certs: false
        timeout: 5
      register: result_uri
      retries: 3
      until:    # 単純なタスク成功を条件とする場合でもuntil とセットで指定する必要がある
        - result_uri is success

ansible-core 2.16.0 でシンプルにかけるようになった

先程の例の場合、ansible-core 2.16.0 のように until が不要になりました。

    - name: Get request until success
      uri:
        url: https://192.168.1.30
        validate_certs: false
        timeout: 5
      retries: 3

この例では、until の判定のためだけに register を指定していたので register の指定もなくせています。

実行例: （途中で成功している場合）

%  ansible-playbook -i localhost, retries.yml

PLAY [localhost] ******************************************************************

TASK [Get request until success] **************************************************
FAILED - RETRYING: [localhost]: Get request until success (3 retries left).
FAILED - RETRYING: [localhost]: Get request until success (2 retries left).
ok: [localhost]

PLAY RECAP ************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

なお、この Playbook を ansible-2.16 未満で実行すると、リトライせずに1発でエラーになります。

until が不要なケースと必要なケース

あくまでも今回の改善、タスクが成功するまでという条件の場合だけ until が不要になっただけです。 なので、それ以外の条件（例: 実行結果内の x の値が true になるまで）はこれまで同様に until の指定が必要です。

おわりに

タスクの成功を条件とする場合のリトライ、という条件付きではありますが、シンプルな場合にシンプルに書けるようになったのは、地味に嬉しいと思いました。

参考

Retrying a task until a condition is met:

docs.ansible.com

If until is not specified, the task will retry until the task succeeds but at most retries times.

関連 issue:

github.com

関連 PR:

github.com

関連 PR （ドキュメント）:

github.com