てくなべ (tekunabe)

ansible / network automation / 学習メモ

[ansible] ansible-runner で複数のインベントリファイルを扱う

この記事は、Ansible Advent Calendar 2021 (Adventar版) 10日目の記事です。

はじめに

ansible-runner では、インベントリやPlaybook、設定などの資材類のディレクトリ構造の基本が決まっています。

ansible-runner.readthedocs.io

インベントリは inventory/hosts です。デモディレクトリにもあります。

ansible-runner run --help の結果には --inventory オプションがあり、default=<private_data_dir>/inventory とのことです。hosts まで指定するものではないようです。

Ansible Runner Options:
  configuration options for controlling the ansible-runner runtime environment.

...(略)...
  --inventory INVENTORY
                        optional path for the location of the inventory content directory (default=<private_data_dir>/inventory)

ふと、複数のインベントリファイルを扱うにはどうしたらいいのだろうと思い、調べたり試したりしていたら、inventory/hosts というファイルではなく「ディレクトリ」の中に複数のインベントリファイルを置いたらできました。

もともと ansible-playbook コマンドの -i オプションでは、ファイルだけはなくディレクトリも指定できるので、この仕様を利用しています。

この記事では簡単なサンプルで説明します。

  • 動作確認
    • ansible-runner 2.1.1
    • ansible-core 2.12.1(Execution Environment のコンテナ側)

ファイル構成

一覧

.
├── env
│   └── settings                  # (1)
├── inventory
│   └── hosts
│       ├── group_vars
│       │   └── all.yml           # (2) 変数ファイル
│       ├── inventory_network     # (3) インベントリ1
│       └── inventory_server.yml  # (4) インベントリ2
└── project
    └── playbooks
        └── test.yml              # (4) Playbook

(1) env/settings

---
process_isolation: true
container_image: localhost/my-ee   # 手元でビルドしたもの ansible-core は 2.12.1

(2) inventory/hosts/group_vars/all.yml

変数定義ファイルです。ここに配置すれば適用される、ということを確認するために、おいてます。

---
greeting: default greeting

(3) inventory/hosts/inventory_network

インベントリファイル1つめ。ini 形式のものです。ファイル名に .ini をつけないのがポイントです。

.ini は、ディレクトリ単位でインベントリを指定した場合の読み込み除外対象の拡張子になっているためです。

[ios]
ios01
ios02

(4) inventory/hosts/inventory_server.yml

インベントリファイル2つめ。形式も複数にしてみたかったので YAML 形式にしてみます。.yml は、除外対象になっていないので、拡張子を普通につけて大丈夫です。

---
all:
  hosts:
    sv01:
    sv02:

(5) project/playbook/test

ansible-runner 経由で実行する Playbook です。

hosts: all なので、今回の場合は、4つのホストが対象になる想定です。

---
- hosts: all
  gather_facts: false
  connection: local

  tasks:
    - name: test debug 1
      ansible.builtin.debug:
        msg: "{{ greeting }}"

Playbookの実行

ansible-runner 経由で、Playbook を実行します。--inventory オプションはつけずに、デフォルのままとします。

$ ls -1   # 実行するディレクトリと資材類の位置関係のデバッグ
env
inventory
project
$ ansible-runner run . -p playbooks/test.yml 

PLAY [all] *********************************************************************

TASK [test debug 1] ************************************************************
ok: [sv01] => {
    "msg": "default greeting"
}
ok: [sv02] => {
    "msg": "default greeting"
}
ok: [ios01] => {
    "msg": "default greeting"
}
ok: [ios02] => {
    "msg": "default greeting"
}

PLAY RECAP *********************************************************************
ios01                      : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ios02                      : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
sv01                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
sv02                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

4つのホスト分が実行されました。2つのインベントリファイルが扱われることが分かります。

おわりに

私自身は試せていませんが、ダイナミックインベントリもいけるそうです。

他、ansible-runner のドキュメントの Inventory の説明 ansible-runner.readthedocs.io

Ansible Automation Platform に含まれる Automation Controller (旧 Ansible Tower) などのバージョンを確認できるページ

先日 Red Hat Ansible Automation Platform 2.1 (以下 AAP2.1)がリリースされたようです。

Introducing Red Hat Ansible Automation Platform 2.1

翻訳版も助かります。

Ansible Automation Platform 2.1 がリリースされました - 赤帽エンジニアブログ

AAP2.1に含まれる Ansible Controller (旧 Ansible Tower) のバージョン表記が気になっていたので調べていると、製品ライフサイクルページに辿り着きました。

access.redhat.com

どのバージョンのAnsible Automation Platform に、どのバージョンのAutomation Controller (またはAnsible Tower)が含まれているか、ぱっと出てこないときに上記ページを確認したいと思います。

おまけ

Automation controller 4.1.0 のリリースノート

Release Notes — Automation Controller Release Notes v4.1.0

Jinja2 にコメントを入れる

これは エーピーコミュニケーションズ Advent Calendar 2021 の3日目の記事です。

はじめに

Ansible などで利用されるテンプレートエンジン Jinja2には、コメントのシンタックスが用意されています。

jinja.palletsprojects.com

コメントのシンタックス

{# ここにコメントを入れる #}
{#
ここに
コメントを入れる
#}

複数行まとめてコメントアウトする、というときにも便利そうですね。

おためし

Ansible で試してみます。(環境: Ansible 2.9.19、Jinja2 3.0.1)

Playbook

Playbook は以下の通り。template モジュールでファイルを書き出すだけです。

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

  tasks:
    - name: jinja2 test
      template:
        src: test.j2
        dest: test.txt

パターン1: 1行コメント

Jinja2 テンプレート test.j2 側はいくつかのパターンで試します。

まずは、テキスト内にコメントをいれるパターンです。

111
222
{# ここにコメントを書く #}
333

Playbook を実行して出力されるファイル test.txt は以下のようになります。

111
222
333

コメントを書いた行は、空行にならず無視された形です。

パターン2: インラインコメント

111
222
aa{# bb #}cc
333

はこうなります。

111
222
aacc
333

パターン3: 複数行コメント

テンプレートはこちら。

111
222
{# 
  いろんな
  ことを
  ここにコメントに書く
#}
333

出力先ファイルはこちら。1行のときと同じですね。

111
222
333

パターン4 制御文を複数行コメントアウト

まずコメントアウトしない場合

111
222
{% for i in ["a", "b", "c"] %}
{{ i }}
{% endfor %}
333

では、for文によって、以下のようになります。

111
222
a
b
c
333

これを、for文をまるごとコメントアウト

111
222
{#
{% for i in ["a", "b", "c"] %}
{{ i }}
{% endfor %}
#}
333

すると、以下のようになります。

111
222
333

for文が有効でないことがわかります。

パターン5: Whitespace Control との組み合わせ

- による Whitespace Control との組み合わせもできることを知りました

いくつか試したものを掲載します。

5-1

111
222

{#- ここにコメントを書く #}

333

は以下の通り。

111
222
333

5-2

111
222

{# ここにコメントを書く -#}

333

111
222

333

5-3

111
222
{#- ここにコメントを書く -#}
333

111
222333

5-4

111
222{#- ここにコメントを書く -#}
333

111
222333

おわりに

テンプレート内で for 文などのロジックにちょっとした説明を書いたり、デバッグ時に一時的に処理を無効化しておきたいときに便利そうですね。

Internet Week 2021「C6 どう使う?データセンターネットワーキング最前線 Yahoo! JAPAN実用例]」参加メモ

はじめに

2021/11/16 - 26 開催の Internet Week 2021で「C6 どう使う?データセンターネットワーキング最前線 Yahoo! JAPAN実用例」というプログラムを拝聴しました。

ZTPの実装方法や、Ansible のロール、テンプレート、変数ファイルの作り方について興味があったため、注目していました。

司会や講演者より特に案内がない限りは、プログラムの内容については基本的に投稿OKである旨の案内が休憩中にありましたので、拝聴中にツイートしていました。この記事では自分のツイートをまとめる形で残しておきます。所々 typo 失礼します・・。

(公開可能な資料は例年通りであれば翌年2月頃に公開されます)

C6 どう使う?データセンターネットワーキング最前線 Yahoo! JAPAN実用例

ヤフーのデータセンタネットワークあらまし

Clos Network 構築

ONIE、ZTP、コンフィグデプロイ

スペルミス失礼しました。正しくは「BGP Unnumbered」

ネットワーク監視体制

質疑応答

  • (私から)IPアドレスからAS番号を計算するロジックを、Playbook内ではなくコマンドにした理由はどんなところでしょうか。
    • 深い理由はないが、コマンドにしたらPlaybook外でも利用できるなどの副次的なメリットがあった。

おわりに

特に以下の点についてとても参考になりました。

  • BGP Unnumbered や、AS番号の自動生成などのネットワーク設計レベルの工夫をすることで、自動化の変数を少なくする
  • テンプレートファイルは、数を多くし過ぎてもいけないけど、なんでもできるものを作ってもいけなし。うまく使いまわす工夫をする(今回の場合は profile.yml によるテンプレートの紐づけ)

発表者の高橋さん、スタッフみなさま、ありがとうございました!

JANOG48 Meeting 参加レポート

はじめに

2021/07/14-16 に岐阜県大垣市で開催(オンラインも)された JANOG48 Meeting に(オンラインで)参加ました。

ものすごく遅れたタイミングで、かつ、ものすごくちょっとした内容ですが、見たプログラムのメモや感想などを残しておきます。

資料は公開されているので、気になったプログラムがあればリンク先から詳細をご覧いただければと思います。


IaC文化を広く根付かせる

www.janog.gr.jp

  • 初心者の気持ちはレビューに活かせる
  • 開発者をチームに招き入れて異文化を持ち込む、一人いるだけでも捗る

レガシー組織における運用標準化に向けた取り組み

www.janog.gr.jp

  • 作業カタログ重要

導入したNW運用自動化をどのように拡大しますか。開発が担当?運用が担当?それとも?

www.janog.gr.jp

  • 自動化拡大のためには、スキルだけでなく共通の認識やチーム、時間が必要

L(レイヤ):ゼロからはじめるインフラ建設 -都内データセンター直結のキャンパスネットワークをゼロから構築してみた-

www.janog.gr.jp

モダンな⾃動化⼿法という重機は使い方に慣れないと余計時間かかることも。かといってねじ回しではもなく、電動工具を探す例えがわかりやすかったです。 Ansibleは重機。

EyeballとCDNの幸せなトラフィックエンジニアリング

www.janog.gr.jp

そもそもEyeballという言葉をここで初めて知りました。

OCNにネットワークコントローラ入れてみたよ

www.janog.gr.jp

  • メールが挟まると自動化が大変そう
  • 人の判断す必要性が残る箇所はある
  • 質問 設定を非同期処理にしてる理由は?
    • 回答 ルーターに設定がたくさん入ってるから重い、レスポンスに時間がかかる。何秒以上かかる場合は非同期でという方針を持っている。

■ おわりに

現地のみ、オンラインのみ、ハイブリット開催、どんなかたちでも JANOG は毎回楽しみにしています。

いつも登壇者の皆様、スタッフ皆様、ホストや協賛各社様、ありがとうございます!

次回は、2022/01/26 - 28 JANOG49 Meeting in Kagoshima

参考

show int チャンネルによるふりかえり・レポート

www.youtube.com

www.youtube.com

私と JANOG

[ansible] ansible 関連のリリース情報まとめRSS(ansible、molecule、各種コレクションなど)

はじめに

Ansible のニュースレターである The Bullhorn の Issue #34で知ったのですが、ansible や molecule、それから各種コレクション(おそらくansible community package内)のリリース情報をまとめて取得できる RSS フィードがあります。

特にコレクションについては、各リポジトリにリリース情報を追っていくのも大変なので、ひとつにまとまった RSS フィードがあるのはとても助かります。

フィード

こちらから

rss.community.eng.ansible.com

[AWS] サイト間VPNの設定がどの段階で課金されるのか調べた

はじめに

サイト間 VPN の設定をした時に、どのタイミングで料金が発生するのか、分からなかったので調べました。

結果としては、対向のVPN装置のとのトンネル状態にかかわらず、AWS側のサイト間VPNの設定をした段階のようです。

AWS VPN の料金

https://aws.amazon.com/jp/vpn/pricing/

AWS サイト間 VPN 接続では、接続がアクティブな時間ごとに 1 時間単位で課金されます。

「接続がアクティブ」というのが、AWS上で設定した段階で課金されるのか、それとも対向 VPN 機器とのトンネルがアップした状態なのか分からなかったので、もう少し調べました。

VPN 接続の作成画面

そういえば、VPN 接続の作成画面の下の方には以下の記述があります。

f:id:akira6592:20210930184913p:plain
このステップを完了すると、VPN 接続料金が発生します。

なので、これを作った時点で、トンネルのアップやダウンとは関係なく課金されるのだろうと予想しました。

もう少し調べることにします。

FAQ

FAQ には少し違う表現の記述がありました。

https://aws.amazon.com/jp/vpn/faqs/?nc1=h_ls

VPN 接続時間によるご請求は、VPN 接続が「利用可能」状態であった時間に対して発生します。

「利用可能」というのは VPN 接続の画面の「状態」欄でしょうか。

日本語の画面では「利用可能」ではなく「使用可能」となっていました。

f:id:akira6592:20210930185001p:plain
「使用」可能

念のため、英語のFAQを確認すると available とありました。 https://aws.amazon.com/vpn/faqs/?nc1=h_ls

VPN connection-hours are billed for any time your VPN connections are in the "available" state.

画面も英語にしたところ stateavailable となっていました。どうやらこの状態で課金ということのようです。

f:id:akira6592:20210930185139p:plain
available

おためし

たまたま

という状態で数カ月放置していたアカウントがあり、9月にサイト間のVPN接続を設定しました。対向のVPN装置は未設定です。

f:id:akira6592:20210930185223p:plain
課金された

すると想定通り課金されました。