はじめに

YAML書いてて何が間違ってるのかわからない時。ありませんか？ありますねぇ！
Ansibleの理念だか何かに「シンプル」って言葉があって、
シンプル＝簡単なんだな！と思ってほいほい触ってみたら、シンプルすぎて逆にわかりづらい！
恐縮ながらまだAnsible触り始めて二週間も経ってないので、
ベストプラクティスではきっとないのだろうけど
あくまで私ならわからない時はこうやって確認する。
というのを本記事に執筆したいと思います。

テストコード

- hosts: localhost
  tasks:
  - shell: ip a
    register: result
    debug:
      msg:{{ result }}

こちらがテストコードです。
本来は「- debug:」と書くべきであり、このままでは使えません。
試しに通してみると…。

The error appears to have been in '/var/ansible/test.yml': line 3, column 5, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  tasks:
  - shell: ip a
    ^ here

このようなエラーメッセージが帰ってきます。
似たようなメッセージなので全文は掲載しませんが、
まぁ、読んだら明らかに「- shell: ip a」の行が悪いんだな。
と普通だったら思いますよね？なので余計にハマってしまいます。

解決策

Online YAML parserを通す

参考にさせて頂いた記事：https://qiita.com/YumaInaura/items/8e4c08821b6940299a27

本当は、ここでばっちりエラーが表示されてこれでもうバッチリですね！で終わる予定だったのですが、幸か不幸かYAML的にはOKという結果でした。（ソシャゲ早くやりたいのにこのような結果になり残念です。あと、インデントのズレとかはしっかり見つけてくれるので実際有用です。）

補足：エディタとしてNotepad++やVScodeも紹介しようと思いましたが、新規にソフトウェアをインストールするよりもネットで一発！のほうがやりやすいかと思い、こちらを紹介しました（そもそもNotepad++はともかく、VScodeもYAMLとしての文法チェックしてくれてるのか不明でした。）

--syntax-checkを通す

playbook実行時に--syntax-checkとオプションをつける事でYAMLのチェックをしてくれます。実際に動きはしないので安心です。Ansibleの構文チェックが当てにならないからその解決策を探しとるんやないかーい！ってなりますが、とりあえず上記のOnline YAML Parserを通せばYAML的にはOKなので、後はAnsibleとしてもOKか確認するだけです。

YAML文法はOKだけど、AnsibleはNGな時。

上記にてYAMLの文法的には問題なさそうだけど、Ansibleの構文としてはNGという結果になったとしましょう。
vars_filesとかwith_itemsとかならその後に続くのは変数だとすぐわかるのでインデントの必要性も容易に把握できるのですが、shellとかdebugとか。あのあたりは何処で手続きが分かれてるのかわかりにくすぎですよね。きっとここでつまずく人多いと思うんです。

で、どうするのか？私の考えたやり方は…
……サンプルコードをコピペして、そこに少しずつマージしていく…？

カラム位置まで指定してくれるので、そこにしか目に行かないのですが
そこのブロックが悪いんだな～程度の情報として受け取る。
ぐらいが良いんだと思います。

そもそもAnsibleを自動化ツールだと思っていないか？

ふと疑問が氷解したので、以下追記しました。
私はAnsibleは自動化ツールだと思ってました。
Redhatのサイトにも大きくAUTOMATION！って書いてあるぐらいですからね。
自動化して作業効率アップだ！改善だ！！って。
自動化もできます。しかし本質はそこではなかったのです。

Ansibleは自動化ツールではなく、構成管理ツールであるということです。
私はYAMLにサーバ構築の処理（手続き）を書こうとしてたけど、
本当は手続きではなく設定を書くためのもの。
そもそもYAMLとは構造化されたデータを表現するためのフォーマットである。

データを表現するためのフォーマット！！！
そのような言語でプログラムを書こうとしたらわかりにくいに決まってますよね。
あくまでYAMLはデータを表現するためのフォーマット。

そうなってくると私の書いたコードの何が悪いかが見えてきますね。
・意味不明な位置での改行（通常のプログラムであればこれでも全然良いと思いますけど、これが設定を書くためなのだとしたら、１つ１つの項目は１行にまとめられるべきですよね。）
・debugの不要な指定（機器の設定とは関係ないので要らないですね。-vvvv等の詳細出力パラメータを使えば大抵は問題ない筈です。
むしろここまでわかってくると、自分の書いたテストコードがAnsibleの用途をちゃんと理解してる人であれば、書きようが無いってこともワンチャン見えてきますね…（無くはないだろうけど、設定を書くという本筋からずれてる。）