てくなべ (tekunabe)

ansible / network automation / 学習メモ

はてなブログで目次を生成する見出しレベルをCSSで調整する

目次機能とは

はてなブログには目次を簡単に生成できる目次機能があります。

[:contents]

と差し込むだけです。

f:id:akira6592:20220306110301p:plain
ボタンもある

目次の対象にされるのは markdown でいう # 見出し による見出しです。## 見出し`### 見出し のような下のレベルまで目次の対象になります。

レベルが深いとノイジーな目次になってしまいます。Word ではどのレベルまでの目次を表示するか設定できるので、同じことをしたいなと思っていました。

ためしたら、デザインCSSで、少しスタイルを追加するだけでできました。(ただし仕様上、スマホ表示には非対応)

調整方法

レベル3まである目次を生成すると以下のように <ur> <li> によるリストになってました。(少し整形しています)

    <!-- 略 -->
    <div class="entry-content">
      <ul class="table-of-contents">
        <li><a href="#はじめに">はじめに</a></li>
        <li><a href="#動画">動画</a></li>
        <li><a href="#ロールと変数とチェック">ロールと変数とチェック</a></li>
        <li><a href="#Role-argument-validation">Role argument validation</a>
          <ul>
            <li><a href="#必須チェック">必須チェック</a>
              <ul>
                <li><a href="#エラーになるケース">エラーになるケース</a></li>
                <li><a href="#正常なケース">正常なケース</a></li>
              </ul>
            </li>
            <li><a href="#チェックの無効化">チェックの無効化</a></li>
            <li><a href="#型チェック">型チェック</a></li>
            <li><a href="#選択肢チェック">選択肢チェック</a></li>
          </ul>
        </li>
    <!-- 略 -->

なのでトップの <ul>table-of-contents までクラス名で追いつつ、非表示にしたいレベルの <ul>display: none を指定します。

レベル1までのみ表示

.entry-content .table-of-contents li ul {
    display: none;
}

f:id:akira6592:20220306112112p:plain
レベル1まで表示

レベル2までのみ表示

.entry-content .table-of-contents li ul li ul {
    display: none;
}

f:id:akira6592:20220306112145p:plain
レベル2まで表示

レベル3以降は、さらにセレクタの末尾に li ul を追加していくだけです。

[Ansible] 「つまずき Ansible 【Part35】ロールの実行に必要な変数をチェック」ふりかえり

はじめに

2022/03/05 に、YouTube Live で「つまずき Ansible 【Part35】ロールの実行に必要な変数をチェック」という配信をしました。

tekunabe.connpass.com

今回は、ロールの実行に必要な変数のバリデーションができる「Role argument validation」を試します。

ansible-core 2.11 から利用できる機能です。


動画

youtu.be

ロールと変数とチェック

ロール内で変数を利用する場合は、あらじめ必要な変数が定義されているかなどをチェックしたいところです。

古くから使える方法としては、assert モジュールがあり、柔軟なチェックができます。

一方 ansible-core 2.11 からは Role argument validation という機能が利用できます(正確な機能名はわからないですが、ドキュメントの見出しからとっています)。 assert モジュールのよいな汎用的な機能ではなく、ロールの argument (内部で利用する変数と解釈しています)専用のチェック機能です。

Role argument validation

Role argument validation では、チェックするルールをロール内の meta/argument_specs.yml 内に定義します。

必須チェック

エラーになるケース

必要な変数だと定義しているのに、定義してない場合です。

meta/argument_specs.yml を以下のようにします。myapp_intmyapp_strrequired: true で必須としています。

---
argument_specs:
  main:
    short_description: The main entry point for the myapp role
    options:
      myapp_int:
        type: "int"
        required: true
        description: "The integer value"

      myapp_str:
        type: "str"
        required: true
        description: "The string value"

以下の Playbook を実行することにします。myapp_intmyapp_str も未定義です。

---
- hosts: localhost
  gather_facts: false

  tasks:
    - name: import test
      ansible.builtin.import_role:
        name: test

ロールの処理の中身も変数を利用するだけです。

---
- name: debug test 1
  debug:
    msg: "{{ myapp_int }}"

- name: debug test 2
  debug:
    msg: "{{ myapp_str }}"

この状態で、Playbook を実行します。(エラーを改行表示するために -vvv を付けてます。)

$ ansible-playbook -i localhost, site.yml -vvv 
...(略)...

PLAYBOOK: site.yml ******************************************************************************************************************************************************************************
1 plays in site.yml

PLAY [localhost] ********************************************************************************************************************************************************************************
META: ran handlers

TASK [test : Validating arguments against arg spec 'main' - The main entry point for the myapp role] ********************************************************************************************
task path: /home/admin/ansible-ee/site.yml:2
fatal: [localhost]: FAILED! => {
    "argument_errors": [
        "missing required arguments: myapp_int, myapp_str"   # ここがポイント
    ],
    "argument_spec_data": {
        "myapp_int": {
            "description": "The integer value",
            "required": true,
            "type": "int"
        },
        "myapp_str": {
            "description": "The string value",
            "required": true,
            "type": "str"
        }
    },
    "changed": false,
    "msg": "Validation of arguments failed:\nmissing required arguments: myapp_int, myapp_str",
    "validate_args_context": {
        "argument_spec_name": "main",
        "name": "test",
        "path": "/home/admin/ansible-ee/roles/test",
        "type": "role"
    }
}

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

ポイントは "missing required arguments: myapp_int, myapp_str" です。2つの変数の分がいっぺんに表示してくれるのが嬉しいです。

validate が1つのタスクとてログに表示される点も特徴かなと思います。

正常なケース

今度は正常なケースです。myapp_intmyapp_str をきちんと定義します。

どこで定義されててもいいのですが、今回は import_role モジュールのタスクの vars で定義します。

---
- hosts: localhost
  gather_facts: false

  tasks:
    - name: import test
      ansible.builtin.import_role:
        name: test
      vars:
        myapp_int: 123
        myapp_str: hello

これで実行すると成功します。validate のタスクの状態も ok です。

TASK [test : Validating arguments against arg spec 'main' - The main entry point for the myapp role] ********************************************************************************************
task path: /home/admin/ansible-ee/site.yml:2
ok: [localhost] => {
    "changed": false,
    "msg": "The arg spec validation passed",    # 成功
    "validate_args_context": {
        "argument_spec_name": "main",
        "name": "test",
        "path": "/home/admin/ansible-ee/roles/test",
        "type": "role"
    }
}

TASK [test : debug test 1] **********************************************************************************************************************************************************************
task path: /home/admin/ansible-ee/roles/test/tasks/main.yml:2
ok: [localhost] => {
    "msg": 123
}

TASK [test : debug test 2] **********************************************************************************************************************************************************************
task path: /home/admin/ansible-ee/roles/test/tasks/main.yml:6
ok: [localhost] => {
    "msg": "hello"
}

チェックの無効化

ロールに meta/argument_specs.yml があると validate 処理がされますが、無効化もできます。

import_role モジュールで呼び出す場合は rolespec_validate オプションfalse を指定します。デフォルトは true です。

# ...(略)...
    - name: import test
      ansible.builtin.import_role:
        name: test
        rolespec_validate: false

この場合は、validate 処理はされず、ログにも出てきません。

型チェック

次は型チェックです。meta/argument_specs.yml 内では、 myapp_inttype: "int" という指定をしています。

なので、意図的に 文字に指定してエラーになるようにしてみます。

# ...(略)...
    - name: import test
      ansible.builtin.import_role:
        name: test
      vars:
        myapp_int: abc    # 文字列
        myapp_str: hello

こんなエラーになりました。

fatal: [localhost]: FAILED! => {
    "argument_errors": [
        "argument 'myapp_int' is of type <class 'ansible.parsing.yaml.objects.AnsibleUnicode'> and we were unable to convert to int: <class 'ansible.parsing.yaml.objects.AnsibleUnicode'> cannot be converted to an int"
    ],

unable to convert to int とあるので、変換しようとしてエラー、ということのようです。 なお、myapp_int: "123" という指定はエラーになりませんでした。

選択肢チェック

AかBであること、のような選択肢のチェックです。meta/argument_specs.yml に以下を追加します。

# ...(略)...
      kind:
        type: "str"
        choices:
          - kingyo
          - ugui
        required: true
        description: "kind of sakana"

この場合は、kind の値は kingyougui のいずれかであること、という指定です。

Playbook 側の vars では、意図的にエラーになるように、kind: buri を指定します。

# ...(略)...
    - name: import test
      ansible.builtin.import_role:
        name: test
      vars:
        myapp_int: 123
        myapp_str: hello
        kind: buri

こんなエラーになりました。"value of kind must be one of: kingyo, ugui, got: buri" と表示されています。

...(略)...
TASK [test : Validating arguments against arg spec 'main' - The main entry point for the myapp role] ***
task path: /home/admin/ansible-ee/site.yml:2
fatal: [localhost]: FAILED! => {
    "argument_errors": [
        "value of kind must be one of: kingyo, ugui, got: buri"  # ポイント
    ],
    "argument_spec_data": {
        "kind": {
            "choices": [
                "kingyo",
                "ugui"
            ],
            "description": "kind of sakana",
            "required": true,
            "type": "str"
        },
        "myapp_int": {
            "description": "The integer value",
            "required": true,
            "type": "int"
        },
        "myapp_str": {
            "description": "The string value",
            "required": true,
            "type": "str"
        }
    },
    "changed": false,
    "msg": "Validation of arguments failed:\nvalue of kind must be one of: kingyo, ugui, got: buri",
    "validate_args_context": {
        "argument_spec_name": "main",
        "name": "test",
        "path": "/home/admin/ansible-ee/roles/test",
        "type": "role"
    }
}

validate_argument_spec モジュール

Role argument validation は、ロール読み込み時に meta/argument_specs.yml があるとチェックするという動作でした。

似たようなものとして、ansible.builtin.validate_argument_specモジュールがあります。 これは、任意のタイミングで、 meta/argument_specs.yml のような定義(厳密には meta/argument_specs.ymloptions 配下のみ) を利用してチェックするモジュールです。

タイミングが任意の代わりに、ファイルを明示的に指定する必要があります。

[2024/01/13 追記] 別の記事で書きました。

tekunabe.hatenablog.jp

チェックモードでもvalidateされる

Role argument validation は ansible-playbook コマンドの -C または --check によるチェックモードによる実行でもvalidateしてくれます。

ansible-docによるargument情報の表示

meta/argument_specs.yml に定義した情報は、ansible-doc コマンドで表示できあます。

ロール一覧

ロール一覧の表示では、short_description に定義した情報が表示されまます。

$ ansible-doc -t role -r roles -l
...(略)...
test                                                main         The main entry point for the myapp role!!!!

ロール個別表示

ロールと指定すると書く argument のタイプ、説明なども表示されます。

$ ansible-doc -t role -r roles test
> TEST    (/home/admin/ansible-ee/roles/test)

ENTRY POINT: main - The main entry point for the myapp role

OPTIONS (= is mandatory):

= kind
        kind of sakana
        (Choices: kingyo, ugui)
        type: str

= myapp_int
        The integer value

        type: int

= myapp_str
        The string value

        type: str

まとめ

ロールの実行に必要な変数をチェックする Role argument validation 機能をためしてみました。

柔軟さでは assert や ansible.utils.validate`モジュールのほうが勝ると思いますが、meta/argument_specs.ymlドキュメンテーションも兼ねる点は便利かなと思います。


Part36にむけて

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

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

[Ansible] 安全側に倒す ansible.cfg の設定

はじめに

意図しないまま実行を進めないようにするため、ちょっとしたことでもエラーに倒して早めに処理を止める設定の紹介です。インベントリ周りが中心です。

  • ansible.cfg
[defaults]
duplicate_dict_key=error

[inventory]
host_pattern_mismatch=error
any_unparsed_is_failed=True

要件などに合わせて調整は必要かと思いますが、このあたりからベースにすると良いのではないかと思っています。

インベント周りはデフォルトでは結構ゆるい印象があります。

以下詳細(ansible 2.9.23 で確認)です。

YAMLのキーの重複時の挙動の指定(DUPLICATE_YAML_DICT_KEY

DUPLICATE_YAML_DICT_KEY

YAMLのキーの重複時の挙動を指定する。デフォルトは warn で、警告を表示して処理を継続する。

例えば以下の Playbook では、モジュール名である debug が重複している。

---
- hosts: ios
  gather_facts: false

  tasks:
    - name:
      debug:
        msg: msg1
      debug:
        msg: msg2

これを実行すると、警告が表示されるが処理を続ける。後に定義したキーが優先される。

$ ansible-playbook -i inventory.ini test.yml 
[WARNING]: While constructing a mapping from /home/ansible/test.yml, line 10, column 7, found a duplicate dict key (debug). Using last defined value only.

PLAY [ios] ********************************************************************************************************

TASK [debug] ******************************************************************************************************
ok: [ios01] => {
    "msg": "msg2"
}

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

$ echo $?
0

キーの重複時にエラーとしたい場合は error を指定する。

[defaults]
duplicate_dict_key=error

この設定で Playbook を実行すると以下のようにエラーとなる。エラーメッセージは分かりにくい。

$ ansible-playbook -i inventory.ini test.yml 
ERROR! Unexpected Exception, this is probably a bug: 'NoneType' object has no attribute 'line'
to see the full traceback, use -vvv
$ echo $?
250

なお、モジュール指定の重複だけでなく、オプションや変数名の重複(同一YAML内)でもエラーになる。

hosts の指定が誤っている場合の挙動の指定(HOST_PATTERN_MISMATCH

HOST_PATTERN_MISMATCH

Playbook の hosts: の指定したホストやグループ名が、インベントリ内に見つからない場合の挙動。デフォルトは warning で、警告を表示するのみ。ansible-playbook コマンドのリターンコードは正常 0 となる。

$ ansible-playbook -i inventory.ini test.yml 
[WARNING]: Could not match supplied host pattern, ignoring: not_existed

PLAY [not_existed] ************************************************************************************************
skipping: no hosts matched

PLAY RECAP ********************************************************************************************************

$ echo $?
0

この場合、Ansible Tower のワークフローとしても正常扱いで次のジョブテンプレートへと進む。

hosts の指定先がインベントリ内に見つからない状況は、その後に想定外の状況を引き起こしかねないので、エラーとして扱って処理を中止した場合もある。特に hosts: "{{ target_host }}" のように変数で指定する場合は、起こりやすい。

エラーとして扱う場合は ansible.cfg で以下のように設定する。defaultsセクションではないので注意。

[inventory]
host_pattern_mismatch=error

以下のように、エラー扱い(リターンコード 1)となる。

$ ansible-playbook -i inventory.ini test.yml 
ERROR! Could not match supplied host pattern, ignoring: not_existed
$ echo $?
1

パースできないインベントリがある場合にエラーとするかの指定(INVENTORY_ANY_UNPARSED_IS_FAILED

INVENTORY_ANY_UNPARSED_IS_FAILED

インベントリファイルの書式の誤りで、正しくパースできないインベントリがある場合にエラーとするかどうかの指定。デフォルトは False で、エラーとしない扱い。

例えば、以下は書式が誤っているインベントリファイル(inventory2.ini)。

[ios2]
ios02 ansible_host=192.168.1.11

# vars とすべきところ var
[ios2:var] 
ansible_network_os=ios
ansible_connection=network_cli

このインベントリを指定して Playbook を実行すると、警告は表示されるがPlaybookの処理は続行しようとする。

$ ansible-playbook -i inventory.ini -i inventory2.ini test.yml 
[WARNING]:  * Failed to parse /home/ansible/inventory2.ini with ini plugin: /home/ansible/inventory2.ini:5: Section [ios:var] has unknown type: var
[WARNING]: Unable to parse /home/ansible/inventory2.ini as an inventory source

PLAY [ios] ********************************************************************************************************

TASK [debug] ******************************************************************************************************
ok: [ios01] => {
    "msg": "Hello Ansible!"
}

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

$ echo $?
0

早めにエラーとして処理を中止したい場合は True に設定する。

[inventory]
any_unparsed_is_failed=True

以下のように、Playbookの実行前にエラーで処理が止まる。

$ ansible-playbook -i inventory.ini -i inventory2.ini test.yml 
[WARNING]:  * Failed to parse /home/ansible/inventory2.ini with ini plugin: /home/ansible/inventory2.ini:5: Section [ios:var] has unknown type: var
ERROR! Completely failed to parse inventory source /home/ansible/inventory2.ini
$ echo $?
1

ダイナミックインベントリにも有効。なので、認証情報に誤りがあってインベントリを取得できないときは処理を中止する」という使い方もできる。(aws_ec2 で確認)

補足

似た設定に INVENTORY_UNPARSED_IS_FAILEDもあるが、これは指定されたインベントリのうち1つでもパースできればエラーにしない。 一方、INVENTORY_ANY_UNPARSED_IS_FAILEDは、全てのインベントリがパースできれば正常、1つでもパースできなければエラーとするため、より安全。

[Ansible] --vault-password-file で指定するファイルはスクリプトでも可なので環境変数も参照できる

--vault-password-file オプションとは

Ansible にはパスワードなどの機密情報を暗号化する ansible-vault という機能があります。

Playbook 実行時には何かしらの方法で復号パスワードを指定する必要があります。ansible-playbook コマンドにも関連オプションがいくつかあります。

パスワードを書いたファイル名を指定するには --vault-password-file というオプションがあります。

テキストだけでなくスクリプトも指定可

最近知ったのですが、この --vault-password-file オプションは、パスワードを書いたテキストファイルだけでなく、パスワードを標準出力する.py などスクリプトも指定できます。

公式ドキュメントには以下のコマンド例があります。

ansible-playbook --vault-password-file my-vault-password-client.py

別システムに格納されたパスワードをとってきて利用するなんてこともできそうですね。

工夫次第で環境変数の参照も可

この性質を利用すると、パスワードを環境変数に仕込んでそれを参照することもできるようです。以下のサンプルをみたときに、なるほど!と思いました。

Ansible Vault Environment Variable · GitHub

実行権限を与えることお忘れなく。

[ansible] ansible-navigator で --step や vars_prompt によるインタラクティブな操作をする

はじめに

ansible-navigator は、Playbookの実行、ドキュメントなどの情報が表示できる TUI ツールです。

Playbook の実行に関しては、ansible-playbook コマンドでできることはだいたいできると思ってよさそうです。 ansible-playbook コマンドの各オプションも ansible-navigator コマンド経由で渡るようです

ただし、ユーザーからの操作を受けてのインタラクティブな操作が一部できません。

私が分かっている範囲では、--step オプションによる Playbook のステップ実行や、vars_promptディレクティブによる変数の値の入力などです。Playbook の実行が途中で止まることは止まりますが、ユーザーの入力値を拾ってくれません。

何かか対処方法はあるかなと調べたらたら、ドキュメントの Frequently asked questions に掲載されていました。

playbook-artifact を無効化して、モードを stdout にするといいようです。

試してみたのでまとめます。

  • 環境
    • ansible-navigator 1.1.0

playbook-artifact の無効化と、stdout モードへの変更

デフォルトでは playbook-artifact が有効で、モードは interactive (TUI) なのでそれぞれ変更する必要があります。

挙動の指定方法は以下の3通りあります。

  1. ansible-navigator の設定ファイルである ansible-navigator.yml による指定
  2. ansible-navigator コマンドのオプションによる指定
  3. 環境変数による指定

各設定値や方法詳細はこちら

指定方法1: ansible-navigator.yml

ansible-navigator.yml による指定の場合は、以下のように定義します。

---
ansible-navigator:
   # ...(略)...
   playbook-artifact:
     enable: False       # playbook-artifact の無効化
   mode: stdout         # モードを stdout に変更

指定方法2: ansible-navigator コマンドのオプション

オプション 説明 指定例
--pae または --playbook-artifact-enable playbook-artifact の有効、無効 --pae False
-m または --mode モードの指定 -m stdout

指定方法3: 環境変数

export ANSIBLE_NAVIGATOR_PLAYBOOK_ARTIFACT_ENABLE=False
export ANSIBLE_NAVIGATOR_MODE=stdout

おためし1: --step によるステップ実行

ここでは ansible-navigator コマンドのオプション(-m stdout --pae False)で指定します。加えて、ステップ実行の --step オプションも指定します。

$ ansible-navigator run plyabooks/step.yml -i inventory --step -m stdout --pae False
PLAY [localhost] **********************************************************************************
Perform task: TASK: task1 (N)o/(y)es/(c)ontinue: y   # ここで一時停止するので、実行するための y を指定してエンター

Perform task: TASK: task1 (N)o/(y)es/(c)ontinue: **************************************************

TASK [task1] **************************************************************************************
ok: [localhost] => {
    "msg": "this is task1"
}
Perform task: TASK: task2 (N)o/(y)es/(c)ontinue: y  # 同上

Perform task: TASK: task2 (N)o/(y)es/(c)ontinue: **************************************************

TASK [task2] **************************************************************************************
ok: [localhost] => {
    "msg": "this is task2"
}

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

参考: playbook-artifact を有効なままの場合

なお、playbook-artifact を有効なままの場合、以下のところでとまって入力も受け付けられません。(さすがにCtrl+Cで抜けられます)

$ ansible-navigator run plyabooks/step.yml -i inventory --step -m stdout  # playbook-artifact を有効なまま

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

おためし2: vars_prompt による変数値指定

以下の Playbook で試します。

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

  vars_prompt:   # 変数の値をインタラクティブにユーザーに指定してもらう
    - name: msg
      prompt: Input msg
      private: false

  tasks:
    - name: task1
      ansible.builtin.debug:
        msg: "{{ msg }}"

先ほどと同じく、 ansible-navigator コマンドのオプション(-m stdout --pae False)で指定します。

$ ansible-navigator run plyabooks/step.yml -i inventory  -m stdout --pae False
Input msg: sakana sakana sakana         # 変数の値を聞かれるので入力する

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

TASK [task1] ***************************************************************************************
ok: [localhost] => {
    "msg": "sakana sakana sakana"
}

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

参考: playbook-artifact を有効なままの場合

playbook-artifact を有効なままの場合、以下のところでとまって入力も受け付けられません。(さすがにCtrl+Cで抜けられます)事情を知らないと何が起こったかわからないですね・・

$ ansible-navigator run plyabooks/step.yml -i inventory  -m stdout 

--stepvars_prompt を別々で試しました、組み合わせも大丈夫でした。

おわりに

今回ご紹介した設定変更では、当初とは別の制約があります。

  • playbook-artifact を無効化するため ansible-navigator replay によるリプレイ機能が利用できない
  • stdout モードにするためTUI ではなくなる

だったら普通に ansible-playbook コマンドでいいんじゃないかというケースもありますが、Execution Environment をコマンドから使うにはやはり ansible-navigator を使うことになると思います。

上記2点の制約が特に問題ではなく、インタラクティブな操作が必要な場合は、有効な手段になるかと思います。

JANOG49 Meeting in Kagoshima 参加レポート

はじめに

2022/01/26-28 に鹿児島県鹿児島市で開催(オンラインとハイブリッド)された JANOG49 Meeting にオンラインで参加しました。

見たプログラムについて、感想やメモ書きレベルですが残しておきます。

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

アーカイブは2022/03/07まで公開予定とのことです(JANOG ML [janog:15225] (JANOG49)アンケートとアーカイブ配信について より)。


■ Day1

ネットワーク運用自動化(NetOps)の実運用: 苦労/解決/妥協した話

www.janog.gr.jp

P14 で、設計で意識しないといけなかったこととして、以下2点があげられていました。

  • 事業の特性
  • 要員の特性

「他社の正解事例が自社の正解とは限らない」というのは悩ましい話だなと思いました。自分たちのことを知る、というのは思いのほか難しそうです。

P24では、作業全体の自動化は難しいと語られていました。完璧を求めないための視点は重要そうです。

P26、今後の展望の一つは検証の自動化や効率化とのことでした。検証、判定自体は、本来は人間よりも機械が得意とする類のものもだとは思うのですが、組み合わせが多くなると、作り込みが大変になりそうですね・・。

本プログラム全体としては、自分たちを知ることと、落とし所が重要なのだと感じました。

モバイルバックホール作業自動化への挑戦

www.janog.gr.jp

P8、作業自動化 拡大の "本当の" 壁として、以下3点が挙げられていました。

  • 作業品質の低下
  • ノウハウの属人化
  • 保守的な環境

これらを乗り越えるために、実行環境の整備や、マニュアルの作成、ハンズオンの開催などをされたそうです。取っ付きやすいマニュアルの作成というのは個人的に盲点でした。

P14、自動化拡大のために重要なのは「ストレスフリーな環境作り」。使うのは人間なので、こういうところに働きかけるのは重要なのだなと思いました。

■ Day2

Clos Network Topology を運用するために、どのような取り組みをしていますか

www.janog.gr.jp

プログラムの内容そのものもとても素晴らしかったですし、質疑応答や Slack でのやりとりもとても良かったです。

JANOG Meeting では、発表者と参加者という区切りはあるものの、二者間で質疑応答したり、議論したりします。このプログラムではさらに、Slack 内での参加者同士の意見交換も活発で、いいなと思いました。Clos アーキテクチャに限定しない、教育やオンボーディングに関する話が多かった印象でした。

今更ながらRFC5549でIXピアしてみよう

www.janog.gr.jp

参加者から RFC 5549 のとある箇所の解釈についての意見が出てきて、数人で意見交換されていました。こういう場があるのもなんだかいいですね。

■ Day3

L1トラブルシューティング

www.janog.gr.jp

ケーブルの天敵の一つはセミだそうです。セミが卵を生んでしまうそうです。知らなかった・・。

NETCON Wrap-up

www.janog.gr.jp

自動採点の仕組みがすごいなと思いました。

クラウドオペレーティングモデルはネットワークの世界でどこまでできるか?

www.janog.gr.jp

私はよく Ansible を利用するのですが、ときどき Terraform のような宣言的な指定をしたくなります。 ネットワーク関連の Provider の今後の動向に注目していきたいと思います。

KDDI固定電話ネットワーク、NFV化の5年間の道のり

www.janog.gr.jp

P35の「オープンソース利用の見極め」。PoCのPoCというのは、なんとなくやっていたことではありますが、言語化するとたしかにそうかも知れないという納得感がありました。いきなり実運用を見据えた検討は難しいでしょうし、まずは物を知るというステップを明示的に設けるのは良いなと思いました。

一番印象的だったのが P37 の所感です。

運用の課題は、運用しないとわからないから
完璧を目指すより「改善しやすい仕組み」「管理しやすいルール」
「運用者が改善にガッツリ取り組める雰囲気」が必要だと感じた

単なる「やってみないとわからない」だけでなく、改善、管理、仕組みを見据えた観点がとても参考になりました。

閉会宣言/次回予告

www.janog.gr.jp

本編ではないですが、式が始まる前のスタッフさん同士の会話が、ラジオのようで心地よかったです。

■ おわりに

今回もハイブリッド開催となりました。かなり難易度高いのではないでしょうか・・。感謝です。

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

特に、今回は新しい取り組みとして、アーカイブ公開がかなり早くてありがたかったです。見逃した人に紹介するときも紹介しやすかったです。

次回の JANOG50 Meeting は 2022/07/13 - 15 に北海道で開催予定です。

おまけ

私と JANOG

Azure の公式ドキュメントを修正してみた

はじめに

Azure の公式ドキュメントには、Ansible から操作するための情報が多く載っていてありがたいです。

docs.microsoft.com

眺めていたら、Get Started: Configure Ansible on an Azure VMというページで、インデントがおかしいところがありました。

f:id:akira6592:20220202090558p:plain
インデントがおかしい箇所が複数

気になって修正方法を調べました。

これまたありがたいことに、twitterで詳細をおしえていただきました

おかげさまで、実際に修正までできたので、そのときのことをまとめます。

修正とプルリクエス

修正の基本的な流れは、以下のページに掲載されていまる。

docs.microsoft.com

GitHub アカウントがあれば、プルリクエストを出した経験がない方でもわかるくらいのていねいな説明になっています。

上記のページでは、暗黙的に fork してブランチ作成する手軽な手順になってます。この場合、patch-1 というブランチになるのですね。

もちろん、明示的に fork してはじめても良いはずです。

出したプルリクエストがこちら。

github.com

CLA の同意

プルリクエストを出した後に、他のページにも類似のインデント誤りがあったので修正してコミットしました。

すると、microsoft-cla bot さんから、CLA(Contribution License Agreement)同意お願いのコメントがつきました。

共同作成者ガイドにも書かれていましたが、

お客様が Microsoft の従業員ではない場合、新規または大幅な変更を加えると、オンラインの貢献者使用許諾契約書 (CLA) のご提出をお願いするコメントが pull request 内に生成されます。

に該当したようです。

内容を確認し、とくに問題なかったので同意しました。

すると、signed に更新されました。

f:id:akira6592:20220202090126p:plain
CLA同意済み

マージ

修正内容にも特に問題なかったようで、暫く待つと main ブランチにマージしていただきました。

反映

翌日には無事に、ドキュメント上にも反映されていました。

f:id:akira6592:20220202090705p:plain
インデント修正が反映された

ちょっとした修正でしたが、この記事にコントリビュートした人の一覧に載って嬉しいです。

f:id:akira6592:20220202090833p:plain
コントリビューター

終わりに

思いの外簡単にできました。

もしまた自分に修正できそうなところがあったら、またやってみたいと思います。

docs.microsoft.com