てくなべ (tekunabe)

ansible / network automation / 学習メモ

[Ansible] ドキュメントを修正、ビルド、確認してプルリクエストを出すまでにやったこと

はじめに

Ansible のドキュメントは Sphinx で生成されるようになっています。

これまでちょっとした文言修正は、ちゃんとビルドして確認してこなかったのですが、先日書式レベルで修正したことがありました。そのため、ビルドする方法をしらべて試しました。

公式ドキュメントとしては、以下のページにまとめられています。

docs.ansible.com

このブログ記事では、私が実行した手順をまとめます。あくまで、今回私はこうやった、という記録だけです。詳細は前述の公式ドキュメントしてください。

git clone

予め GitHubansible/ansible リポジトリを、自分のアカウントに fork しておきます。

fork したほうを git clone します。

$ git clone git@github.com/akira6592/ansible
$ cd ansible
$ git status
On branch devel

今回のドキュメント修正用のブランチを devel から作成します。

$ git checkout -b fix-development_process

Python 環境の準備

Sphinx でビルドするために Python 環境を準備する必要があります。今回は専用の venv を作成します。

$ python3.9 -m venv ~/envs/adoc 
$ source ~/envs/adoc/bin/activate

clone した中の docs/docsite ディレクトリに、requirements.txt があるので、これをもとに pip install します。

$ cd docs/docsite
$ pip install -r requirements.txt

ドキュメント修正

実際にドキュメントを修正します。今回は、docs/docsite/rst/community/development_process.rst です。

ちょっとした修正です。

github.com

このリンクの書式

:ref:`backported <backport_process>`

の動作を確認したくて、ビルドしようと思った次第です。

この書式は、Ansible 側でもきちんと説明されていました。

なお、生成されているのは以下のページです。

The Ansible Development Cycle — Ansible Documentation

チェック

次に、rstcheck によるチェックです。

$ pwd
/Users/sakana/Documents/git/ansible/docs/docsite
$ rstcheck  rst/community/development_process.rst 
rst/community/development_process.rst:1: (INFO/1) Hyperlink target "community-development-process" is not referenced.
rst/community/development_process.rst:30: (INFO/1) Hyperlink target "community-pull-requests" is not referenced.
rst/community/development_process.rst:144: (INFO/1) Hyperlink target "community-changelogs" is not referenced.
rst/community/development_process.rst:168: (INFO/1) Hyperlink target "changelogs-how-to" is not referenced.
rst/community/development_process.rst:258: (INFO/1) Hyperlink target "changelogs-how-to-format" is not referenced.
rst/community/development_process.rst:302: (INFO/1) Hyperlink target "changelogs-how-to-format-playbooks" is not referenced.
rst/community/development_process.rst:320: (INFO/1) Hyperlink target "backport-process" is not referenced.
Error! Issues detected.

あれれ・・。今回修正したリンクとにたような文言 backport-process が表示されてしまいました。ちゃんと参照関係は通るはずなのですが。実際の動作はビルドして確認することにします。

(なお、修正前の状態でも同じ表示がされていました。)

ビルド

いよいよビルドです。ここでいうビルドは HTML の生成です。

ビルドする対象の範囲によってビルドする方法もいくつかあるようですが、今回は htmlsingle にしました。

内部で sphinx-build コマンドなどが実行されるようです。

コマンドとしては、make htmlsingle rst=rstファイルのパス なのですが、rst オプションで指定したパスに対して rst ディレクトリが補完されるので、rst ディレクトリを覗いた形で指定します。

$ pwd
/Users/sakana/Documents/git/ansible/docs/docsite
$ make htmlsingle rst=community/development_process.rst
Creating symlinks in gettext_structure
ln -sf ../rst/core_index.rst rst/index.rst
ln -sf ../rst/dev_guide/core_index.rst rst/dev_guide/index.rst
ln -sf ../sphinx_conf/all_conf.py rst/conf.py
sphinx-build -j 4 -b html -d _build/doctrees ./rst _build/html rst/community/development_process.rst
Sphinx v5.1.1 を実行中
出力先ディレクトリを作成しています... 完了
/Users/sakana/Documents/git/ansible/docs/docsite/rst/dev_guide/index.rst: WARNING: ドキュメントを読めません。無視します。
https://docs.python.org/2/objects.inv から intersphinx インベントリをロード中...
https://docs.python.org/3/objects.inv から intersphinx インベントリをロード中...
http://jinja.palletsprojects.com/objects.inv から intersphinx インベントリをロード中...
https://docs.ansible.com/ansible/6/objects.inv から intersphinx インベントリをロード中...
...(略)...
ビルド中 [mo]: 指定された 0 件のpoファイル
ビルド中 [html]: コマンドラインで指定された1件のソースファイル
環境データを更新中[新しい設定] 9345 件追加, 0 件更新, 0 件削除
ソースを読み込み中...[  1%] 2.10_index .. collections/ansible/builtin/items_lookup    
ソースを読み込み中...[  3%] collections/ansible/builtin/jsonfile_cache .. collections/ansible/posix/debug_callback     
ソースを読み込み中...[  4%] collections/ansible/posix/firewalld_info_module .. collections/arista/eos/eos_linkagg_modul
...(略)...
ソースを読み込み中...[100%] scenario_guides/vmware_rest_scenarios/create_vm .. win_guide/windows_winrm                          
/Users/sakana/Documents/git/ansible/docs/docsite/rst/dev_guide/index.rst: WARNING: ドキュメントを読めません。無視します。
/Users/sakana/Documents/git/ansible/docs/docsite/rst/index.rst:65: WARNING: toctree に存在しないドキュメントへの参照が含まれています 'dev_guide/index'
...(略)...
/Users/sakana/Documents/git/ansible/docs/docsite/rst/dev_guide/core_index.rst: WARNING: ドキュメントはどの toctree にも含まれていません
完了
ドキュメントの出力準備中... WARNING: 検索インデックスを読み込めず、ドキュメントビルドの一部が不完全です。
完了
出力中...[100%] index                                                                                                     
索引を生成中... genindex py-modindex 完了
追加のページを出力中... search 完了
ダウンロードファイルをコピー中...[100%] network/getting_started/sample_files/first_playbook_ext.yml                                   
静的ファイルをコピー中... 完了
extraファイルをコピー中... 完了
English (code: en) の検索インデックスを出力... 完了
オブジェクト インベントリを出力... 完了
ビルド 成功, 982 警告.

HTMLページは_build/htmlにあります。
Output is in _build/html/community/development_process.html
$ 

私の環境では結構時間がかかりました。警告が表示さていていて少しもやもやしますが、エラーではないようです。

表示と確認

ビルド実行結果の最後にあるように、HTML ファイルが _build/html/community/development_process.html に生成されました。

リポジトリトップからのパスだと docs/docsite/_build/html/community/development_process.html です。これを実際にブラウザで表示して、修正したリンクや表示を確認します。

ビルドして生成されたHTML(ローカル)

あとは、CI でのテストに任せたいと思います。

git push と PR

通常と同じく、git push して PR を出します。

CI も通ってくれて、内容も問題ないと判断され、マージしていただきました。

今回 PR を出した devel ブランチは、現在 2.14 開発向けです。stable-2.13 へのバックポートは、別途まとめて出していただきました。最近は 週に一度程度 bulk backport されているようです。

まとめ

Ansible の公式ドキュメントを修正して、ビルド、確認、プルリクエストをだすまでやったことをまとめました。

これまでは、ビルドする方法が分からなかったので、書式レベルの修正は億劫だったのですが、今回できてよかったです。

ドキュメントの修正方法自体がちゃんとドキュメントにまとまってるのもとても助かりました。

docs.ansible.com

[ansible] 各コレクションを管理しているリポジトリの調べ方

はじめに

コレクションの不具合を調べたりする際、どのリポジトリで管理されてるかを特定する必要があります。その方法はいくつかありますが、2つご紹介します。

コレクション詳細ページから

コレクション詳細ページ(azure.azcollection であればここ)に、リポジトリへのリンクがあります。ここをクリックするとリポジトリ名がわかります。

コレクション詳細ページから

Ansible Galaxy のページから

Ansible Galaxy 側のコレクション詳細ページ(azure,azcollection であればここ)に、リポジトリへのリンクがありますので、ここをクリックするとリポジトリ名がわかります。

Ansible Galaxy のページから

[ansible] 未リリース状態のコレクションをインストールする

インストール方法

コレクションは各リポジトリで開発が進んでいて、適宜リリースされます。

リリースされたものは ansible-gallaxy collection install コレクション名 でインストールできます。

一方、バグ修正されたり、機能追加されたけどまだリリースされてない状態のものをインストールして試したいときもあります。

そんなときのインストール方法も公式ドキュメントに記載があります。

docs.ansible.com

例えば、azure.azcollection コレクションを管理しているリポジトリ ansible-collections/azuredev ブランチのものをインストールしたい場合は、以下のコマンドです。

ansible-galaxy collection install git+https://github.com/ansible-collections/azure.git,dev

実行例

$ ansible-galaxy collection install git+https://github.com/ansible-collections/azure.git,dev  
Cloning into '/Users/sakana/.ansible/tmp/ansible-local-28835hg8drawd/tmptdx3qd1l/azure36ypna5u'...
remote: Enumerating objects: 5834, done.
remote: Counting objects: 100% (625/625), done.
remote: Compressing objects: 100% (422/422), done.
remote: Total 5834 (delta 364), reused 312 (delta 147), pack-reused 5209
Receiving objects: 100% (5834/5834), 2.76 MiB | 4.73 MiB/s, done.
Resolving deltas: 100% (3832/3832), done.
Already on 'dev'
Your branch is up to date with 'origin/dev'.
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Installing 'azure.azcollection:1.13.0' to '/Users/sakana/.ansible/collections/ansible_collections/azure/azcollection'
Created collection for azure.azcollection:1.13.0 at /Users/sakana/.ansible/collections/ansible_collections/azure/azcollection
azure.azcollection:1.13.0 was installed successfully
$ 

バージョン表記状は 1.13.0 とありますが、中身はそれ以降のものになっています。

リポジトリの調べ方

この方法は、コレクション名ではなくリポジトリ名を知っておく必要があります。

以下の記事を参考にどうぞ。

tekunabe.hatenablog.jp

[ansible] ansible-core 2.14 でコントロールノードで Python 3.9 以上が必要になる模様

こんな変更がありました。

github.com

コントロールノードで Python 3.9 以上を必要とするようになるようです。これまでは 3.8 以上でした。

devel ブランチへのマージのみです。おそらくこのまま行けば、2022年11月リリース予定の ansible-core 2.14が、この要件になるはずです。

まだポーティングガイドにはこの旨の記述が見当たりません。

(2022/08/10 追記 ポーティングガイドに追記しました

なお、ためしに Python 3.8 環境で、devel ブランチのものをインストールしようとしたらこんなエラーになりました。

$ python --version
Python 3.8.6
$
$ pip install pip --upgrade
Collecting pip
  Downloading https://files.pythonhosted.org/packages/1f/2c/d9626f045e7b49a6225c6b09257861f24da78f4e5f23af2ddbdf852c99b8/pip-22.2.2-py3-none-any.whl (2.0MB)
     |████████████████████████████████| 2.0MB 14.6MB/s 
Installing collected packages: pip
  Found existing installation: pip 19.3.1
    Uninstalling pip-19.3.1:
      Successfully uninstalled pip-19.3.1
Successfully installed pip-22.2.2
(py38) [admin@rhel84ac ~]$ pip install  git+https://github.com/ansible/ansible.git@devel
Collecting git+https://github.com/ansible/ansible.git@devel
  Cloning https://github.com/ansible/ansible.git (to revision devel) to /tmp/pip-req-build-j8_s8xtb
  Running command git clone --filter=blob:none --quiet https://github.com/ansible/ansible.git /tmp/pip-req-build-j8_s8xtb
  Resolved https://github.com/ansible/ansible.git to commit 85acf4d1e55e95c266a35c49f74af3c0f251de08
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting cryptography
  Downloading cryptography-37.0.4-cp36-abi3-manylinux_2_24_x86_64.whl (4.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.1/4.1 MB 28.4 MB/s eta 0:00:00
Collecting resolvelib<0.9.0,>=0.5.3
  Downloading resolvelib-0.8.1-py2.py3-none-any.whl (16 kB)
Collecting jinja2>=3.0.0
  Downloading Jinja2-3.1.2-py3-none-any.whl (133 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 133.1/133.1 kB 63.7 MB/s eta 0:00:00
Collecting packaging
  Using cached packaging-21.3-py3-none-any.whl (40 kB)
Collecting PyYAML>=5.1
  Using cached PyYAML-6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl (701 kB)
ERROR: Package 'ansible-core' requires a different Python: 3.8.6 not in '>=3.9'

[ansible] AAP (Ansible Automation Platform) が指すもの

私や私の周辺では、Ansible Automation Platformのことを、よく略して AAP と呼んでいます。

しかし、人によって AAP が指す範囲が微妙に違うように感じることがあります。

特に AAP 2 のリリース以降です。AAP は AAP 1 時代から AAP ですが(変な言い方ですが)、文脈的に AAP 2 以降を指してるときがあります。はたまた、Automation Controller のことを指しているようなときもあります。

私の解釈含め、簡単に図示します。

私の解釈

以下が私の解釈です。

私の解釈

AAP 1も AAP2 も AAP ですし、Ansible Tower や Automation Controller 以外の製品、サービスも含め AAP です。

2系なら AAP 2 などと表現し、Automation Controller は Automation Controller と表現します。

他の表現1

AAP 2系を AAP と表現する場合です。他の方の表現では、文脈上こういうケースがあります。

?

他の表現2

Ansible Tower の後継である、Automation controller を指して、AAP と表現する場合です。たまにこれっぽい時があります。

?

参考

What is included in Red Hat Ansible Automation Platform subscription? - Red Hat Customer Portal

Red Hat Ansible Automation Platform Life Cycle - Red Hat Customer Portal

[Ansible] pip install ansible で一緒にインストールされるコレクション群はどこで議論されて決まるのか

議論される場所

Ansible community package (pip install ansible でインストールされる方)は、ansible-core に加えて、さまざまなコレクションがインストールされます。

インストールされるコレクションは、公式ドキュメントの Collection Indexや、リポジトリ ansible-community /ansible-build-dataで確認できます。

どんなコレクションでも OK というわけではなく、公式ドキュメントに作法が紹介されています。

実態は以下のリポジトリのディスカッションで、同梱するか議論されるようです。

github.com

追加された例

例えば、最近だと ansible 6.2.0 で ibm.spectrum_virtualize というコレクションが 同梱されるようになりました

さかのぼってみると以下で議論されていました。いろんなチェックがありますね。

github.com

除外されるかも知れないケース

逆に、除外されることもあり得るようです。

google.cloud コレクションは、メンテナンスがあまりされていないということで、除外対象として議論されていました。

github.com

ansible 8 で除外するかどうかの vote。どうやら除外に向かっているようです。

github.com

ansible 6.3.0 では depracated 扱いになるようです。

github.com

JANOG50 Meeting in Hakodate 参加・登壇レポート

はじめに

2022/07/13-15 に北海道函館市で開催(オンラインとハイブリッド)された JANOG50 Meeting in Hakodate にオンラインで参加しました。

2020年1月に札幌で開催された JANOG 45以来、久々に現地参加させていただきました。

また、ご縁があって「ネットワーク自動化に必要なデータとその管理方法と活用方法とは?」というプログラムで共同登壇もさせていただきました。

資料は公開されているので、気になったプログラムがあればリンク先から詳細をご覧いただければと思います。動画のアーカイブはしばらくは公開予定とのことです。

当日参加したプログラムや登壇したプログラム、全体的な所感についてレポートします。


■ 参加プログラム

運用を変化しながら継続していくための8つの極意

www.janog.gr.jp

自社のクラウドサービス(NEC Cloud IaaS)の運用を通じて得られた8つの極意が紹介されていました。

特に印象に残った点がいくつもありました。

まず、ポイント2の自動化について。自動化したことを見える化することによって、他チームの状況を知れるようにしたそうです。おもしろいなと思いました。事例を共有することによって、もっと自分たちもやるぞと刺激を受けたり、あの作業が自動化できたなら自分たちのこの作業も自動化できそうだ、といった気づきが得られるのだと思います。

次に、ポイント5のWikiです。ドキュメントを書いても見つからない、見られない状態では意味がないため、とにかくwikiに運用ルールに書き出すことにより探しやすい状態にし、「Wikiを見て」を口癖にして定着をはかったそうです。

私見ですが、WikiはページごとにURLが作られるため、リンクの共有によって参照してもらいやすい状況を作れる特徴があると思います。Wikiに限らずWebに書き込むもののの共通でしょうか。一方、大きなドキュメントの中のとある箇所を参照してもらうのはなかな難しく、埋もれがちな気がします。URLは便利です。

他、口癖というのはとてもおもしろいもので、文化を形成する要素の一つだと思います。口癖が文化をつくるのか、文化が口癖をつくるのか、どっちもありそうです。

ポイント7の教育も私が関心がある点です。

最後の方(資料P27)で、8つの極意をさらっと「IT」「プロセス」「人」に分類されていたのですが、バランスとれていて改めて参考になりました。

質疑応答では、たとえば以下のようなやり取りがありました。

  • [Q] 自動化はブラックボックスになりやすいが、どうやって変化に追従すするか?
    • [A] 一人でやらず、チームでやっている
  • [Q] 教育されてる側のモチベーションの工夫は?
    • [A] 自分たちが楽に、という観点にしている

私自身は、現在運用者というわけではないですが、生の運用者の声や考えには今後もアンテナをはっていきたいと思いました。

貴重な知見のご発表ありがとうございました。

スプリンターネット

スプリンターネットという言葉は、初めて聞いた言葉でした。インターネットの分断のことを指すそうです。ウクライナ紛争の話も交え、インターネットが普及した世界での戦争で何が起こるか、などの話がされました。

以下、特に印象に残ったことをまとめます。

  • フィルターバブル、エコーチェンバー
  • いろんなレイヤーで分断し得る
    • ビジネス、制度、技術
  • インターネットは復元力が高い
  • 善人にとって素晴らしいものは、悪人にとっては超素晴らしい
  • 物理の戦争は戦士同士が戦い、市民は巻き込まない
    • 一方、インターネットではどこからでも攻めることができるし、どこからでも被弾してしまう(論理的に)

お恥ずかしながら、私自身はほとんど考えてこられてなかった分野です。現実社会において、インターネットはどういう役割なのか、どういう位置づけなのか、今一度考えたいと思いました。

ネットワーク自動化の対応チャレンジ

www.janog.gr.jp

セイコーソリューションズさんのコンソールサーバーである SmartCS を、自動化に対応させるための数年間の取り組みについて話をされていました。

大きく分けて、Ansible 対応と REST API 対応の2つ。

Ansible 対応については、既存のエコシステムにのせた配布形態がとてもいいと思いました。具体的には、Ansible Galaxy や Automation Hub によるコレクションの配布です。基本的に、コマンド一発で必要な機能をインストールできます。Ansible 本体へのバージョン追従も大変かもしれませんが、エコシステムにのっていれば素早く利用できるのはとてもメリットだと思います。

もし、申請フォームを入入して、圧縮ファイルがダウンロードして、という流れだとなかなか億劫になってしまうような気もしますので・・。

REST API 対応については、さらに自動化への組み込みやすさを向上させる取り組みだと感じました。

P29からの苦労話は大変興味深かったです。案1: CLI ベースと、案2: URI + Method ベースの2案があり、利用者目線で案2を採用したそうです。

開発者目線では案1のほうが楽だったと思います。案1 だとデーター形式はいじらず、CLI over API といったイメージでしょうか。私自身はこの発表を聞くまでそう思っていました。

利用者としては、たしかに 案2: URI + Method が便利かと思います。

内部実装としては、JSON を返す仕組みが意外でした。CLI 出力の内容を JSON に変換というかたちではなく、REST API からうけたリクエストをもとに内部DBから、既存のモジュールを通じて JSON を生成、とのことでした。

全体的に、想像以上に工夫し、想像以上に苦労されているのだなと言うことが認識できました。

「主機能は何かを忘れてはいけない」という言葉も印象的でした。

NETCON Wrap-up

www.janog.gr.jp

今回は環境面での問題が発生してしまったそうで、その点についても共有されていました。時間に限りがある仲での対処も大変だったと思いますが、Meeting 期間中にこのように資料にまとめて、発表まで至っている素早さすごいなと思いました。

インスタンス作成の API を非同期で利用していて、ステータスコード 200 が返ってきた時点で OK としていたが、API としては無事に受付ができたという意味であって、無事にインスタンスが作成できていたわけではない、ということでした。非同期は難しいですね。

他、優勝者へのインタビューがあったのですが、普段はISPでお客様サポート(コールセンターのオペレーター)をされている方でした。 お客様に回答するにあたって、調査を担当するNOCからの情報をきちんと理解するために勉強を重ねてこられているそうです。素敵な姿勢だなと思いました。

参加者アンケートでは、全員が次回も参加したいと回答し、根強い人気が示されました。

オープンマイク

www.janog.gr.jp

今回の JANAOG の参加者の、登録時のアンケートの共有や、JANOG のあり方などの議論がされました。

現地参加登録 1772 名、リモート参加登録 1240 名、とかなり多くの参加者がいたようです。特に現地参加、多いですね。実際、とても賑わっていました。

初参加が4割もいらっしゃったそうです。参加のきっかけは人づてが最も多いそうです。Webサイトや SNS など、いろいろサービスがあるなかで、人のつながりもとても大きいものなのだなと改めて感じました。

ほか、名刺交換というイベントが発生しました。

「初参加の人と手を上げてください。その周りにいる人、いま名刺交換をしてください。」

こういうのは本当に現地ならではですね。後述もしますが、現地に集まることはきっかけをつくる貴重な場なのだと思いました。


■ 登壇プログラム

ネットワーク自動化に必要なデータとその管理方法と活用方法とは?

ジュニパーネットワークスの塚本さん、DMM.comの大山さんとともに、共同登壇させていただいたプログラムはこちらです。

www.janog.gr.jp

事前にインタビューを受けて、ニュースレターとして公開もしていただきました。

www.janog.gr.jp

これまでも JANOG では、自動化についての議論がたびたびされてきました。一方で、自動化には、対象デバイスや設定する情報(インターフェース、IPアドレス、VLAN IDなど)が必要です。これらの情報をどう管理していけばよいか、どのような活用方法があるのかと観点の議論は多くありませんでした。今回はここにフォーカスをあてました。

過去には JANOG45 で近いプログラム「インフラの運用を楽にする情報管理 ~我々のベストプラクティスはこれだ!~」がありました。その発表をされた大山さんに、運用者として発表に加わっていただきたいと思いお声がけさせていただいたという経緯です。

横地パート: 自動化とデータ管理

まず私のパートでは、そもそも自動化とデータ管理がどのような関係かをまとめました。

  • 自動化は素直であり、インプットが誤っていると誤った結果を招く
  • そのため、基盤として正しいデータ管理が必要

という点を述べました。

また、私自身が直接関わったわけではありませんが、NetBox(DCIM/IPAM)の導入事例として、以下の記事をご紹介しました。既存のスプレッドシートをまず正規化したという点が参考になりました。

creators.oisix.co.jp

NetBox のでもサイトは https://demo.netbox.dev/ です。具体的にデータが入っているので使い方のイメージがわきやすいと思います。データ登録もできますが、定期的にデータがリセットされます。

塚本さんパート: SSoTの活⽤ 編 -Intent-based networking による ⾃動化 & 診断 -

塚本さんのパートでは、データ管理の応用的な話をしていただきました。SSoT(Single Source of Truth)や、IBN(Intent-Based Networking)など、考え方としてとても有用な話だと思います。プロダクトとしては Apstra が取り上げられていて、SSoT がただの入れものにとどまらず、設定や状態診断に利用される世界観が先進的に感じました。

Intent、つまり意図を定義しておき、それ通りに設定がなされるという点では、宣言的という見方もできるのではないかと思います。

大山さんパート: SSoT への道 ~過去・未来・そして現状~

大山さんのパートでは、ここ数年のデータ管理の分散や多重管理などの課題への取り組みについて、実例をお話いただきました。このプログラムに運用者の話を入れたかったため、お話いただけてとてもありがたく思っています。

情報が正しく「管理」されている、とはとういうことかがP13でまとめられていました。管理、管理とよくいってしまいますが、認識統一のためにこのように定義付けしておくのは良いなと思いました。

- 情報が保存・取得できる状態が保たれている
- 保存された情報の整合性が保たれている
- 保存された情報に対する適切な権限が保たれている

このケースでは、自分たちは何が課題で何を解決したいかを見定めた上で、当時は自分たちツール AirOne を開発されたそうです。 現在では、活用も進んでいているそうです。

「用途・運用毎にビューをカスタマイズ」というのは、データをきちんと定義したからならではの応用だと思いました。

部署や担当によって見たいデータが異なるでしょうし、個別にデータとビューをセットで作っていたら効率が良くないでしょうね。

ディスカッション

ディスカッションでは、大山さんのパートへの質問が多くありました。

AirOneについて、SSoT側から機器を設定できだけでなく、逆に機器から上を取ってきて SSoT 側に反映するしくみもあるようだが、この場合機器がマスターになってしまってるいのではないか、というコメントがありました。これはあくまで、実情報を管理情報の間違いを正したい、というユースケースだということでした。すべてを一元管理するのではく、特性に応じて実情報を正とする領域、管理情報を正とする領域をそれぞれ分散管理してるものを整合性を取るというアプローチのようでした。

他、SSoT の Single がどの範囲で Single であればよいのか、組織ごとに SSoT があればいいのでは(多少にダブりがあっても)という点でもコメントがありました。

なお、私にご質問いただいた、NetBox のコミュニティの話はいまだになんのことか思出せていません・・・。なにか巻き込みを大きくする働きかけの案があったような気もするのですが・・。

プログラム詳細ページでは、期間限定でアーカイブも公開されています。ぜひご覧いただければと思います。

今回は貴重な機会をいただき、ありがとうございました。今後もこのテーマの話が JANOG などで出てくるといいなと思います。


アーカイブ視聴予定

当日は参加できなかったのですが、アーカイブが公開されているうちに以下のプログラムを視聴しようと思います。


■ その他

プログラムの内容以外の感想などです。

人と会うこと

久々の現地参加だったので、久々にお会いできた方が多くて嬉しかったです。

やはり合ったついでに色々話すという体験はありがたいものです。

ネットで繋がりのある方がほとんどですが、文字にしにくかったり、そのためだけに時間とってリモートで話すというほどでもない場合は、このように「ついで話」できる機会は良いものだなと思いました。

貸切電車!

貸切電車

なんと、会場までの貸切電車が用意されていました。

外や車内には関係各社の広告があり、JANOG 一色といった感じでした。

車内の広告

このように、会場だけでなく、地域に JANOG が滲み出てる景色はなんだか好きです。

質問は現地優先

LT 以外の各プログラの最後は質疑応答、ディスカッションの時間が設けられています。

現地の方はマイクに並んで、リモート参加の方はZoomの挙手ボタンを押すという形でした。現地優先なので、この点も現地参加のメリットなのかなと思いました。

時間の関係もあり、リモートからの質問があったケースは、私が参加した中ではほとんどありませんでした。


おわりに

開催直前で感染者数が増えてきて、懇親会の中止など変化がありました。関係者みなさんは、たびたび苦しい決断を迫られたのだと思います。 無事に開催ができて嬉しく思います。ありがとうございました。

参加された方でアンケートがまだの方はぜひこちらから! JANOG50ミーティングアンケート JANOG50 Meeting

次回 JANO5G1 Meeting は 2023年1月に山梨県富士吉田市で開催予定です。

近年の開催のたびに思うところではありますが、世の中が落ち着き、安心して現地で開催できる状態になっていることを願っています。

参考

togetter

show int の動画

www.youtube.com

私と JANOG