てくなべ (tekunabe)

ansible / network automation / 学習メモ

カラビナでラックのケーブルを整線する

はじめに

自宅にいくつかネットワーク機器があり、家具であるメタルラックを利用しています。

だんだんとケーブルの本数も増えてくると、きれいに整線したくなってきます。

データセンターのようなきちんとした場所であれば、ケーブルマネジメントのような専用の部品を使うところです。

www.panduit.com

ですが、ここは一般的な自宅です。本格的なものほどではなくとも、それなりにできないかと考えています。

100円ショップをふらついているときにふと目にはいったカラビナが使えるのではと思い、試してみました。思いの外よい感じでしたのでご紹介します。

カラビナケーブリング

こんな感じです。

f:id:akira6592:20210425111905p:plain
ケーブルを下に流す

f:id:akira6592:20210425112306p:plain
上に流す
かんたんにケーブルを着脱でき、ほどよい束ね感もあります。これは 2個で100円のものです。

サイズは少し余裕を持ったもののほうが良いかもしれません。


■ その他の方法

カラビナ以外の方法を比較のためにご紹介します。

面ファスナー

こちらは別の用途でよく使っていますが、リング状にすると同じようにケーブルを整線できます。

f:id:akira6592:20210425111955p:plain
面ファスナー
安上がりなのが一番のメリットでしょうか。

着脱の際、剥がしたりくっつけたりするのが少し手間なのと、他のケーブルが一緒にとれてしまわないよう、少し気をつける必要があります。

カードリンク

カードリンク(単語帳などを束ねるもの)も良さそうです。@ipv6labsさん、ご紹介ありがとうございます。

f:id:akira6592:20210425113609p:plain
カードリンク

手元には直径3cm位のものしかありませんでしたが、もう少し大きいものがいいかもしれません。安上がりなのと、見た目がスッキリしてるのがいいですね。

S字フック

これは少し辛いです。着脱は楽ですが、その分つられて他のケーブルが脱線しやすいです。

f:id:akira6592:20210425112038p:plain
S字フック
また、写真のようにケーブルを下に流す分にはまだいいのですが、上に流すときには使えません、

比較

主観による比較です。

方法 着脱のしやすさ  ホールド感 コスパ 見た目のスッキリ感
カラビナ
面ファスナー
カードリンク
S字フック

あれ、あとから教えていただいた、カードリンクが結構よい・・・?

[GitLab] CI が成功しないと Merge できないようにする

はじめに

GitLab には GitLab CI という機能があり、git push のような更新のタイミングで CI を実行できます。

デフォルトでは、マージリクエストの画面で CI の成功/失敗に関わらず Merge ボタンが押せます。

柔軟といえば柔軟ですが、厳密にしたい場合は少し不安が残るかもしれません。

そこで、この記事では CI が成功しないと Merge できないようにする設定を紹介します。

  • 動作確認環境
    • gitlab.com (GitLab Enterprise Edition 13.11.0-pre)

デフォルトでは CI 失敗時でも Merge 可

比較のため、デフォルトの挙動を説明します。

以下のように、CI に失敗しても Merge ボタン自体は押せるようになっています。

f:id:akira6592:20210420222627p:plain
デフォルトではCI失敗時でも Merge できる

CI が成功しないと Merge できないようにする

CI が成功しないと Merge できないようにするには設定変更が必要です。

設定変更

プロジェクトの Setting > General 画面を開きます。

f:id:akira6592:20210420222709p:plain:w300
Setting > General

Merge requests セクションの Expand をクリックして設定項目を開きます。

f:id:akira6592:20210420222744p:plain
Merge requests セクションの Expand

Pipelines must succeed にチェックを入れて、Save change をクリックします。

f:id:akira6592:20210420222831p:plain
Pipelines must succeed にチェック

これで設定変更は完了です。

動作確認

以下のように、CI 失敗次は Merge ボタンが押せないようになります。

f:id:akira6592:20210420222907p:plain
CI 失敗時は Merge できないようになった

参考

docs.gitlab.com

[Python] システムワイドのパッケージを利用できるように venv を作成するオプション --system-site-packages

はじめに

venv はデフォルトでは、システムワイド(グローバル、OSレベル)な Python 環境を参照しません。

venv 作成時に --system-site-packages オプションを参照するようになります。 これにより、venv にないパッケージでもシステムワイドに入っていれば venv から使えるようになります(個人的には使ったことありませんが)。

デフォルトの場合と--system-site-packages オプション不可時の挙動をそれぞれ確認します。

  • 動作確認環境: Python 3.6.8

デフォルト

特に特別なオプションを指定せずに venv を作成します。 システムワイドにのみ paramiko をイントールした状態で、paramiko を import しようとするとエラーになります、

[admin@gitlab ~]$ python3 -m venv venv1
[admin@gitlab ~]$ source venv1/bin/activate
(myvenv) [admin@gitlab ~]$ 
(myvenv) [admin@gitlab ~]$ python -c "import paramiko"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'paramiko'

--system-site-packages オプション付加

--system-site-packages オプションを付加して venv を作成します。

今度は paramiko が import できました。

[admin@gitlab ~]$ python3 -m venv venv2 --system-site-packages
[admin@gitlab ~]$ source venv2/bin/activate
(venv2) [admin@gitlab ~]$ python -c "import paramiko"
(venv2) [admin@gitlab ~]$ 

参考

知ったきっかけ

--system-site-packages オプションは、Software Design 2021年2月号の連載「Ansible問題解決マップ」の 「Ansibleの実行環境」で知りました。

著者の@saito_hidekiさん、ありがとうございました。

パスやバージョンもあわせて確認

ありがとうございます。

(venv2) [admin@gitlab ~]$ python -c "import paramiko; print(paramiko.__file__); print(paramiko.__version__)"
/usr/local/lib/python3.6/site-packages/paramiko/__init__.py
2.7.2

Cisco IOS で 平文パスワード指定時にハッシュ化するアルゴリズムを指定する

はじめに

ログインユーザーのパスワードや enable secret に対するハッシュアルゴリズムがいくつかあります。

ハッシュアルゴリズムを指定しない場合は自動で選択されますが、algorithm-type というオプションで明示的にも指定できます(昨日知りました)。

この記事では、指定しない場合と指定する場合それぞれの動作例を紹介します。

  • 動作確認環境: Cisco IOSv 15.9(3)M2

指定なし

ユーザーパスワード

ios01(config)#username kingyo secret ?            
  0     Specifies an UNENCRYPTED secret will follow
  5     Specifies a MD5 HASHED secret will follow
  8     Specifies a PBKDF2 HASHED secret will follow
  9     Specifies a SCRYPT HASHED secret will follow
  LINE  The UNENCRYPTED (cleartext) user secret

この環境では、上記3つのハッシュアルゴリズムに対応しています。

このコマンド上で、59 を指定するのは、あくまでもその形式でハッシュ化された文字列をセットで指定するということです。

一方で、平文を指定して、ハッシュしたうえでコンフィグに保存しておきたい場合は、ここで平文を指定しいます。

ios01(config)#username kingyo secret dummpypassword
ios01(config)#do sh run | inc kingyo
username kingyo secret 9 $9$ZmV3mHR2JNE...(略)...fmQ/q6RVVt3Q

ハッシュアルゴリズムを特に指定しない場合は、今回は SCRYPT でハッシュ化されました。

enable secret

ios01(config)#enable secret himitsu 
ios01(config)#do sh run | inc enable
enable secret 9 $9$TGudhy8wblij6s$KCVMA...(略)...br4rpnNTO5EEKy6AiLnDhrXQ6HG6

同じく SCRYPT でハッシュ化されました。

algorithm-type による指定

平文指定と同時に algorithm-type オプションでハッシュアルゴリズムを指定します。

MD5

algorithm-typemd5 を指定します。

ユーザーパスワード

ios01(config)#username kingyo algorithm-type ?
  md5     Encode the password using the MD5 algorithm
  scrypt  Encode the password using the SCRYPT hashing algorithm
  sha256  Encode the password using the PBKDF2 hashing algorithm

ios01(config)#username kingyo algorithm-type md5 sec
ios01(config)#username kingyo algorithm-type md5 secret dummpypassword
ios01(config)#do sh run | inc kingyo                                  
username kingyo secret 5 $1$26Rc$Udv...(略)...MFnil7oS2/

投入後のコンフィグには、algorithm-type オプションは表示されず、代わりに、例の数字とハッシュ化文字列の組み合わせになります。

enable secret

ios01(config)#enable algorithm-type ?
  md5     Encode the password using the MD5 algorithm
  scrypt  Encode the password using the SCRYPT hashing algorithm
  sha256  Encode the password using the PBKDF2 hashing algorithm

ios01(config)#enable algorithm-type md5 secret himitsu
ios01(config)#do sh run | inc enable                  
enable secret 5 $1$HV4O$b7a...(略)...FWAv6KChK.

SCRYPT

algorithm-typescrypt を指定します。

以降、ユーザーパスワードでの例のみ紹介します。

ios01(config)#username kingyo algorithm-type scrypt secret dummpypassword
ios01(config)#do sh run | inc kingyo                                     
username kingyo secret 9 $9$YbDbDq1mN2FjUc$...(略)...D0s4hYLjVAYtay6src

PBKDF2

algorithm-typesha256 を指定します。

ios01(config)#username kingyo algorithm-type sha256 secret dummpypassword
ios01(config)#do sh run | inc kingyo                                     
username kingyo secret 8 $8$kMPJPfu1dkoCaM$...(略)...2ZPJ/USf6.usW9RVPe/dOJE5pe.Hzg

参考

learningnetwork.cisco.com

共有ありがとうございます。

[Ansible] 「つまずき Ansible 【Part33】VS Code で Playbook を書きやすくしたい」ふりかえり

はじめに

2021/03/13 に、YouTube Live で「つまずき Ansible 【Part33】VS Code で Playbook を書きやすくしたい」という配信をしました。

実際に作業しながら(ときには)エラーと戦って進めるシリーズです。

tekunabe.connpass.com

今回は、VS Code にインストールしてる拡張の紹介や、Playbook を書く際、モジュール名などのキーワードを補完しながら書くための設定をしました。

まだお試し中のやり方なので道半ばです。もっといい方法があるかもしれません。

3/8 の VS Code Meetup #10 でお話した内容の一部の補足的な内容です。


動画

youtu.be

  • 0:00 イントロダクション
  • 1:36 気になり Ansible
  • 7:18 標準機能で便利な点
  • 8:55 拡張 indent-rainbow
  • 9:39 拡張 YAML
  • 12:19 拡張 YAML + Ansible 向け JSON Schema
  • 23:17 キーワード補完のデモ
  • 29:45 おわりに

(冒頭のおまけコーナー) 気になり Ansible 👀

ここ一週間くらいで気になった issue や PR、リリースを紹介するコーナーです。

今回は以下を取り上げました。

リリース

PR


以下、本編。

標準機能で便利なところ

https://image.slidesharecdn.com/202012vscodeansible-201218094047/95/ansible-7-638.jpg

インストールしてる拡張

indent-rainbow

marketplace.visualstudio.com

https://image.slidesharecdn.com/202012vscodeansible-201218094047/95/ansible-9-638.jpg

YAML

marketplace.visualstudio.com

https://image.slidesharecdn.com/202012vscodeansible-201218094047/95/ansible-10-638.jpg

キーワード補間するための仕組み

YAML という拡張と、JSON Schema Store にある Ansible 関連の Schema を組み合わせます。

Schema の設定 その1 (https版)

./vscode/setting.json に以下の設定を追加します。

{
    // 略
    "yaml.schemas": {
        "https://json.schemastore.org/ansible-playbook": ["*.yml"],
    },
}

Schema の設定 その2 (ローカル配置)

(このあたりが、もっと良い方法があればなぁとおもっているところです)

ダウンロード

先程の方法では、Schema ファイルのサイズが大きすぎて、動作がもっさりします。

対策として予め以下の Schema を JSON Schema Sote からダウンロードします。

  • Ansible Playbook (ここではファイル名 ansible-playbook.json として保存)
  • Ansible Role (ここではファイル名 ansible-role-2.9.json として保存)

ここでは、2ファイルとも /home/admin/schemas/ 配下に保存します。あとの指定とあっていれば場所は任意です。

参照先の修正

ダウンロードした。ansible-playbook.json は、参照先の Schema として

              "$ref": "https://json.schemastore.org/ansible-role-2.9"

のような指定が何箇所かあります。

これらをすべて、セットでダウンロードした ansible-role-2.9.json に向くように、以下のように修正します。

              "$ref": "./ansible-role-2.9.json"

./vscode/setting.json の修正

前述の「Schema の設定 その1 (https版)」でいれた設定の代わりに、以下の設定をします。

{
    // 略
    "yaml.schemas": {
        "/home/admin/schemas/ansible-playbook.json": ["*.yml"],
    },
}

また、配信時に紹介しきれませんでしたが、以下の設定もいれています。デフォルトは 5000 です。

    "json.maxItemsComputed": 300000,

計算されたアウトライン記号と折りたたまれた領域の最大数 (パフォーマンス上の理由から制限されています)。 というものです。変更せずに試した時にエラーが表示されて、少々乱暴ですがこの設定変更に至りました。

おためし

デモ (23:17​ころから)

www.youtube.com


Part34にむけて

以下のネタを検討中です。気が向いたものをやります。 connpass申込時のアンケートでいただいたものも含めています。

  • connection: local ななにか
  • Windows
  • cli_parse モジュール(Part15 の続き)
  • Ansible 2.10 関連
  • Ansible 3.0.0 関連
  • モジュールのテスト
  • Tower / AWX
  • role と Playbook のリポジトリ分割と読み込み
  • AWXとの共存を念頭に入れたDirectory構成

JANOG47 Meeting in Fukuoka 参加レポート

はじめに

2020/01/27-29 にオンラインで開催された JANOG47 Meeting in Fukuoka に参加ました。

前回の JANOG 46 では、現地とオンラインのハイブリッドでの開催でしたが、今回はオンラインのみとなりました。 このような制約があるなかでも開催されたことがありがたいです。

本記事では、自動化に関する以下の2つプログラムについて簡単にレポートします。

エンタープライズ向けVPNサービスNW 運用自動化への挑戦

★ 現在アーカイブ動画公開中(2021/03/21まで)

www.janog.gr.jp

P10(資料右下の数字) では、自動化後の構成が示されていました。StackStorm で定期的にオーダーを取得しにいく仕組みが興味深いなと思いました。

P20 では、自動化前後のフロー比較がされていました。自動化するとこよって、事後に行っていた設定も当日に行うことができ、負荷軽減やミス撲滅につながったそうです。日を跨ぐか跨がないかというのは、人のアサインにも大きく関わってくると思うので、なかなか大きな違いな気がします。良いですね。

P21 では、クライアントPCからはじめとする処理の流れが示されていました。 AWX を直接の作業インターフェースにせず、API 受付するのも AWX の活用方法の一つですね。 特に必要になるパラメータが大量で複雑になる場合は、AWX の画面で指定するよりも、スクリプトで処理してAPI リクエストを生成するほうが効率がよいかもしれません。

P23 では Ansible のロールの構成が示されていました。特にロールの階層が興味深かったです。 例えば、roles/(NW装置名)/Port/Add。途中まで名詞ベースのロールで、最後は動詞です。

(NW装置名) といういのが、純粋に機器1台ずつのことなのか、それともある程度役割でグループ化されているのかは聞きそびれてしまいました。機器1台だとするとロールの数かなり多くなると思うのですが、どうなのでしょう。

お二人の発表で、自動化する範囲をきちんと決められている点が共通していました。 やはりなんでも自動化しようとするのではなく、難易度や見込める効果などの観点で判断するのが良いとのだと思いました。


走りながら作るネットワークテンプレートシステム

★ 現在アーカイブ動画公開中(2021/03/21まで)

www.janog.gr.jp

P19 の Kubernetes との比較がおもしろかったです。確かにネットワーク機器は、プロトコルレベルで自立分散で動くなぁと。 ただ、そこから「あるべき形の宣言 = ネットワーク装置の設定」であるとの考えまでに私は至らなかったので、なるほどと思いました。

私含めて、私の周りの人が関心を寄せていたのが、P30 の Patch という自由記入欄を設ける考え方です。 標準化できないから自動化をしない、のではなく、標準化できない部分はそれはそれとして自由記入欄で受け入れる余地を残すという考え方。

この折り合いの付け方が素敵だなと思いました。

■ おわりに

はじめにも書きましたが、このような状況下でも開催された事自体が本当にありがとうと思います。

当初は現地開催も予定されていたと記憶していますが、オンラインのみにするという決断も相当大変だったのではないかと思います。

オンラインでも JANOG らしさの一つである、ディスカッションはスムーズになされていました。 このあたりは、前回の JANOG 46 である程度確立されたように思います。

スタッフ、関係者、登壇者みなさま、ありがとうごぎざいました!

次回 JANOG48 は、2021/07/14-16 に岐阜県大垣市にて開催予定(ホスト: 株式会社ミライコミュニケーションネットワーク)です。

今度こそ、安心して現地開催ができる世の中になっていればよいなと願っております。

参加された方でアンケートがまだの方はぜひこちらから。 アンケート | JANOG47

参考

私と JANOG

[Ansible] 「つまずき Ansible 【Part32】凡ミスTOP5」ふりかえり

はじめに

2021/02/27 に、YouTube Live で「つまずき Ansible 【Part32】凡ミスTOP5」という配信をしました。

実際に作業しながら(ときには)エラーと戦って進めるシリーズです。

tekunabe.connpass.com

今回は、私がよくやりがちな Playbook 上のミスを6個ほど紹介しました。

TOP5というタイトルですが、厳密につまずき回数をカウントしているわけではなく、なんとなくです。


動画

www.youtube.com

  • 0:00 オープニング
  • 1:30 気になり Ansible
  • 3:15 1.Python キーワードの利用
  • 9:38 2.モジュール名間違い
  • 13:32 3.パラメーター名間違い
  • 17:52 4.)閉じ忘れ
  • 22:46 5.インデント間違い
  • 26:40 6.変数のみ定義
  • 28:42 おわりに

(冒頭のおまけコーナー) 気になり Ansible 👀

ここ一週間くらいで気になった issue や PR、リリースを紹介するコーナーです。

今回は以下を取り上げました。

気になり リリース


以下、本編。

1. Python 的なキーワードを変数のキーとして使ってしまう

問題のある Playbook

- hosts: ios
  gather_facts: false

  vars:
    targets:
      items:
        - dest: 192.168.1.1
          count: 4
        - dest: 192.168.1.2
          count: 4

  tasks:
    - name: ping
      cisco.ios.ios_ping:
        dest: "{{ item.dest }}"
        count: "{{ item.count }}"
      loop: "{{ targets.items }}"

エラー

loop では リストの指定が期待されているが、リストでない。

TASK [ping] *************************************************************************************************************************************************************************************
fatal: [ios01]: FAILED! => {"msg": "Invalid data passed to 'loop', it requires a list, got this instead: <built-in method items of dict object at 0x7f1e6c33ba68>. Hint: If you passed a list/dict of just one element, try adding wantlist=True to your lookup invocation or use q/query instead of lookup."}

items

https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#referencing-key-value-dictionary-variables

に掲載されているように、ドットのキーの指定はできない。

--syntax-check では検出できない。

対処

自分で変数の構造を変えられる場合は、問題ないキーに変更する。

APIからの応答などにより、自分で構造を変えられない場合は、targets.itemstargets['items'] のように指定する。


2. モジュール名のスペルミス

問題のある Playbook

- hosts: ios
  gather_facts: false

  tasks:
    - name: configure lldp
      cisco.ios.ios_lldp_interface:
        config:
          - name: GigabitEthernet0/1
            receive: true
            transmit: true
            state: merge

エラー

ios_lldp_interface ではなく、ios_lldp_interfacesが正しい。

(a210) [admin@gitlab stumble]$ ansible-playbook -i inventory.ini bonmiss02.yml
ERROR! couldn't resolve module/action 'cisco.ios.ios_lldp_interface'. This often indicates a misspelling, missing collection, or incorrect module path.

The error appears to be in '/home/admin/general/vagrant/nwlab/stumble/bonmiss02.yml': line 5, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  tasks:
    - name: configure lldp
      ^ here

--syntax-check でも検出できる。

対処

正しいモジュール名、ios_lldp_interfacesに修正する。


3. オプション名のミス

問題のある Playbook

- hosts: ios
  gather_facts: false

  tasks:
    - name: configure interface
      cisco.ios.ios_interfaces:
        config:
          - name: GigabitEthernet0/1
            description: pukupuku
            state: merge

エラー

cisco.ios.ios_interfaces モジュールの config 内で、state が指定されたがサポートされていない。

TASK [configure interface] **********************************************************************************************************************************************************************
fatal: [ios01]: FAILED! => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python"}, "changed": false, "msg": "Unsupported parameters for (cisco.ios.ios_interfaces) module: state found in config. Supported parameters include: description, duplex, enabled, mtu, name, speed"}

--syntax-check では検出できない。

state オプションは、config と同じならびが正しいので一旦修正。

    - name: configure interface
      cisco.ios.ios_interfaces:
        config:
          - name: GigabitEthernet0/1
            description: pukupuku
        state: merge

ただし、これでもまだ以下のエラー。

TASK [configure interface] **********************************************************************************************************************************************************************
fatal: [ios01]: FAILED! => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python"}, "changed": false, "msg": "value of state must be one of: merged, replaced, overridden, deleted, rendered, parsed, gathered, got: merge"}

やはり、--syntax-check では検出できない。

state オプションが取りうる値は、

  • merged
  • replaced
  • overridden
  • deleted
  • rendered
  • parsed
  • gathered

であるのに対して、merge が指定された。

対処

正しいオプションの位置、正しい値に修正。

- hosts: ios
  gather_facts: false

  tasks:
    - name: configure interface
      cisco.ios.ios_interfaces:
        config:
          - name: GigabitEthernet0/1
            description: pukupuku
        state: merged


4. ) の閉じ忘れ

問題のある Playbook

- hosts: ios
  gather_facts: false

  vars:
    default:
      a:
        x: default_x
        y: default_x
      b: default_b
      c: default_c
    patch:
      a:
        y: patch_y
        z: patch_x
      b: patch_b

  tasks:
    - name: debug
      ansible.builtin.debug:
        msg: "{{ default | combine(patch, recursive=True }}"

エラー

) を期待している箇所に } がある。

TASK [debug] ************************************************************************************************************************************************************************************
fatal: [ios01]: FAILED! => {"msg": "template error while templating string: unexpected '}', expected ')'. String: {{ default | combine(patch, recursive=True }}"}

--syntax-check では検出できない。(おそらく文字列として扱われている中のため)

対処

以下のように修正。

        msg: "{{ default | combine(patch, recursive=True) }}"

ちなみに、以下の結果になる。

TASK [debug] ***************************************************
ok: [ios01] => {
    "msg": {
        "a": {
            "x": "default_x",
            "y": "patch_y",
            "z": "patch_x"
        },
        "b": "patch_b",
        "c": "default_c"
    }
}

5. インデント間違い

問題のある Playbook

- hosts: ios
  gather_facts: false

  tasks:
    - name: debug
      debug:
        msg: "hello {{ item }}"
     loop:
        - 1
        - 2
        - 3

エラー

loop のインデント位置がおかしい。

(a210) [admin@gitlab stumble]$ ansible-playbook -i inventory.ini bonmiss05.yml 
ERROR! We were unable to read either as JSON nor YAML, these are the errors we got from each:
JSON: Expecting value: line 1 column 1 (char 0)

Syntax Error while loading YAML.
  did not find expected '-' indicator

The error appears to be in '/home/admin/general/vagrant/nwlab/stumble/bonmiss05.yml': line 8, column 6, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

        msg: "hello {{ item }}"
     loop:
     ^ here

--syntax-check でも検出できる。

対処

インデントを正しく修正する。

- hosts: ios
  gather_facts: false

  tasks:
    - name: debug
      debug:
        msg: "hello {{ item }}"
      loop:
          - 1
          - 2
          - 3

6. 変数のみ定義

問題のある Playbook

- hosts: ios
  gather_facts: false

  vars:
    msg: pukupuku

  tasks:
    - name: debug
      debug:
        msg: "hello {{ mgs }}"

エラー

msg 変数を定義したのに対して、誤って mgs を参照しようとしている。

TASK [debug] ************************************************************************************************************************************************************************************
fatal: [ios01]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'mgs' is undefined\n\nThe error appears to be in '/home/admin/general/vagrant/nwlab/stumble/bonmiss06.yml': line 8, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n  tasks:\n    - name: debug\n      ^ here\n"}

--syntax-check では検出できない。

対処

変数名を正しく修正。

    - name: debug
      debug:
        msg: "hello {{ msg }}"


Part33にむけて

以下のネタを検討中です。気が向いたものをやります。 connpass申込時のアンケートでいただいたものも含めています。

  • connection: local ななにか
  • Windows
  • cli_parse モジュール(Part15 の続き)
  • Ansible 2.10 関連
  • Ansible 3.0.0 関連
  • モジュールのテスト
  • Tower / AWX
  • role と Playbook のリポジトリ分割と読み込み
  • AWXとの共存を念頭に入れたDirectory構成