ときどきAnsible日記

主にITインフラ基盤の自動化に関する事を書いているブログです

whenで処理を分岐させる

お疲れ様です。伊藤です。

4月も2週目を回り、新生活もいよいよ本格化してきましたが、皆様いかがお過ごしでしょうか。社会人1年目の方も20年目の方も色々ありますががんばっていきましょう。

さてPlaybookで処理をしてると往々にして処理の分岐がしたくなる時があります。たとえばひとつ前の処理の結果によって実行させたりさせたくなかったり。まあプログラムで言うとif的な感じになると思うのですが、Ansibleでこれにあたるのがwhenです。ちょっとif文とはニュアンスが違うのですが、処理の実行条件をつけられる、といったものになります。
たとえば下記のようなplaybookを作成して実行してみましょう。

---
- hosts: localhost

  tasks:
    - name: test ping
      ping:
      register: ret

    - name: ping is ping
      debug: var=ret
      when: ret.ping == "ping"

    - name: ping is pong
      debug: var=ret
      when: ret.ping == "pong"

pingモジュールはコントロールサーバに対してpingを打ち、正常終了した場合にpongを返します。ピンポンですね。

pingの結果はregisterを使いretに入れています。
で、retの中のpingの項目にpongが入っているのでwhenの中でそれを判定しています。

実行すると以下のような結果になります。

[root@test ansible]# ansible-playbook playbook.yml

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

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [test ping] ***************************************************************
ok: [localhost]

TASK [ping is ping] ************************************************************
skipping: [localhost]

TASK [ping is pong] ************************************************************
ok: [localhost] => {
    "ret": {
        "changed": false,
        "failed": false,
        "ping": "pong"
    }
}

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=0    unreachable=0    failed=0

ping is ping ではpingの戻り値がpingだった場合のみ実行されますが、こんなの帰ってくるわけ無いのでスルーします。結果上はskippingとなってますね。
で結果がpongだった場合はdebugでretの中身を表示させています。中を見るとやっぱりpingにpongが入っていると。

見た感じシェルとかプログラムに慣れている人には下のほうにwhenがあるので違和感があるかと思います(私はありました)が、こういうものなので直に慣れます(笑
whenが書かれた上の処理が分岐の対象になります。イメージとしては-nameの配下にいるものはひとつの塊としてみてもらって、その中での実行部と制御部に分かれている感じです。


ごくごく簡単に使うとこんな感じになります。非常に使う機会が多い...ってかこれ知らないと多分Playbook書けません。あと何故かはわからないのですが、本来変数を使用する場合(ここではretが変数)は{{ ret }}見たいな表現をしないといけないのですが、whenの中では無しで表現できています。ってか逆に{{}}つけるとエラーになります。(そーユー意味ではdebugも{{}}無しだ....この辺の切り分けは機能の設計者によって違うんでしょうねぇ...)

という感じで今回は終了です。お疲れ様でした。

インターミッション~バズワードのはなし~

お疲れ様です。伊藤です。

皆さんバズワード御存知ですか?流行に敏感なSEの方であれば常にチェックされているかと思いますが、まあ流行の用語ですね。ちょっと前には一般的にもバズるなんて言葉自体も流行りました。一般的にはそのときに流行った言葉のことを指すのかと思いますが、個人的には一回流行ってその後廃れて言った言葉がバズワードになる認識ですねぇ...いわゆる死語ですね。これだとデスワードか....これ系のワードを連発する営業さんは個人的には信じてません...

ちょっとネットで調べると出るわ出るわ。あったなーこんなん、という言葉のオンパレードです。やはりITとバズワードは切っても切り離せない存在。どんなんがあったか見てみましょう。というかこちらを参照させていただきました。
バズワードから眺めるIT業界の流行 - Qiita

あるわあるわ、たくさん出てきます。個人的にはこの中でも特にバズワードっぽいのはこちら

  • ウェアラブル
  • IoT
  • ロボティクス・プロセス・オートメーション(RPA)

あくまで個人的見解ですので反論は受け付けません。m(__)m
RPAなんて言いたいだけちゃうんかと。ロボットって言いたいだけなんじゃないかと思ってしまいます(笑

そもそもなぜ今回こんなことを考えたかというと、Infrastrucer as Code(IaC)がバズワードになりそうでちょっとやだ。。と思ったからなんですねぇ。IaCは一般的に浸透していく言葉になるといいなぁ.....

以上です。お疲れ様でした。