てくなべ

ネットワーク、自動化などの技術的なことを書いていきます。

Ansible 2.5 の情報を一足早く掴むために読みたいページたち

はじめに

現在(2018/02/19)、Ansible 次期バージョンの 2.5 は beta2 となっています。正式リリースは 3月の予定のようです。 この記事では、Ansible 2.5 の情報を一足早く掴むために読んでおきたいページたちをご紹介します。 公式ドキュメントはすべて devel バージョンへのリンクを掲載しています。

CHANGELOG

一番はじめにこちらの CHANGELOG を読むのがよいと思います。

https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG_v2.5.rst

以下の情報が記載されています。

  • 主な変更点 (loop など)
  • 軽微な変更点
  • Deprecated になった点(2.9で削除されるまでの猶予)
  • 削除されるモジュール
  • 追加されるプラグイン、モジュール


■ 新モジュール一覧

新モジュールの一覧を紹介しているページです。削除されるモジュールも 紹介しています。

Ansible 2.5 新モジュール一覧awsbloglink.wordpress.com


■ 移行ガイド

Ansibe 2.4 から 2.5 へ移行する際に注意するべき事項が記載されている、公式の移行ガイドです。

http://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.5.html


■ ネットワークモジュールの新機能

ネットワークモジュールの新機能を紹介しているAnsible 公式ブログ記事です。 2.4 までのPlaybook の書き方と 2.5 での書き方の比較などが記載されていて分かりやすいです。

www.ansible.com


■ ネットワークモジュールのドキュメント

f:id:akira6592:20180219151517p:plain

ついに 公式ドキュメントの見出しに「Ansible Networking Guide」が登場しました。

以下の情報が記載されています。

(2018/02/19追記) 公式ドキュメント内の become を説明するページにも、Ansible 2.5 での特権モードの扱いについて記載されています。

Understanding Privilege Escalation — Ansible Documentation


■ stable-2.5 ブランチ

GitHub Ansible リポジトリstable-2.5 ブランチです。 すでに devel ブランチは 2.6 用になっています。 github.com


■ おまけ: Asnble 2.5 のインストール方法

現在、普通にインストールすると 2.4系がインストールされます。 ベータ版である、Ansible 2.5 をインストールするためには、 pip であれば以下のようにブランチを指定します。

pip install git+https://github.com/ansible/ansible.git@stable-2.5


■ まとめ

今回も、多数のモジュール追加や、機能の追加があるようです。 ネットワークモジュール方面でも、コネクションタイプの追加やベストプラクティスの公開といった大きめトピックがあります。 試したものは本ブログで公開したいと思います。

Ansible の Junos 対応モジュールは標準モジュールとGalaxyモジュールの2種類ある

はじめに

Ansible は ネットワーク機器にも対応していて、Juniper の Junos にも対応しています。 Junos対応モジュールは大きく分けて以下の2の種類があります。

  • Ansible本体に組み込まれているモジュール(以下、標準モジュール)
  • Ansible Galaxy からインストールして利用するモジュール(以下、Galaxy モジュール)

このため、見るべきドキュメントを間違えてしまったりすることがあります。 この記事では、これら2種類のモジュールの入手方法やドキュメントの場所などについてまとめます。 (すべて 2018/02/10 現在)

比較

標準モジュール Galaxy モジュール
入手方法 Ansibleインストール時に同時に入る ansible-galaxy install Juniper.junos
公式ドキュメント Ansilbe全体 Ansible for Junos OS
モジュール名プレフィックス junos_ juniper_junos_ (*1)
モジュール一覧 Junos Juniper.junos Ansible Modules
 モジュール例1 junos_facts juniper_junos_facts
 モジュール例2 junos_config juniper_junos_config
 モジュール例3 junos_l3_interface juniper_junos_srx_cluster
Playbook記述例 junos_config の利用例 juniper_junos_config の利用例
最新stableバージョン 2.4.3.0 2.0.1
GitHub リポジトリ ansible/ansible Juniper/ansible-junos-stdlib
  • (*1): Galaxy モジュールの1.xまでは、標準モジュールと同じ junos_ というプレフィックスでした。2.0 からは混同を避けるため、juniper_junos_ というプレフィックスに変更されました。中には「junos_cli」→「juniper_junos_command」のように、ガラッと名前変更されたモジュールもあります。詳細はGalaxyモジュールの2.0.0のリリースノートをご参照ください。

Azure 初心者が最初の1カ月でやったこと

はじめに

こちらのツイートの詳細です。

これまで、パブリッククラウドはあまり使ったことがなかったのですが「何か環境作るなら〇〇でやるかな」という手札が欲しかったので、何かをやることにしました。

もともと、ASP.NET などマイクロソフトのプロダクト周辺で開発をしていた時期があったので、なんとなく流れで マイクロソフトの Azure にしました。

始めたのが2017年12月なのですが、ちょうどそのころ Azure 関連の新しい本が複数発売されていたので、本をベースにしました。冬休みを挟んだので比較的捗りました。

大まかな流れとしては以下の通りです。

  • 概要を知る
  • 手を動かしてみる
  • もう少し詳しく知る
  • 知っている他のツールと組み合わせる

なお、Azure については、Azure Functions を少し試したことがある程度でした。


■ 1. どんなものかを知る

Azureテクノロジ入門 2018

eb.store.nikkei.com

「Azureテクノロジ入門 2016」の改訂版です。 どういうサービスがあるのか、可用性の考え方、各基本的なサービスの特徴を知ることができました。 特に「第2章 AzureのインフラとIaaS 〜 仮想マシン、ストレージ、ネットワーク」各サービスを利用する際のベースとなる知識と思ったので念入りに読みました。 Azure Stack の章までがったのが驚きでした。


■ 2. 軽く一人ハンズオン

ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築

ec.nikkeibp.co.jp

VMの作成、イメージの作成と展開、仮想ネットワークの操作、バックアップなど一通りハンズオンを行いました。 画面キャプチャが豊富なので操作に迷うことなく進めることができました。 簡単な作業であればサクサク進められるようになりました。


■ 3. もう少し詳細を知る

Microsoft Azure実践ガイド

book.impress.co.jp

前述の「Azureテクノロジ入門 2018」より分厚い本になります。 読むのをベースにして、興味が向いたところは実際に試してみました。 具体的には、Visual Studio から WebApp のデプロイや、ARMテンプレートの利用です。

ARMテンプレートについては以下のスライドも参考にさせていただきました。

www.slideshare.net

この本は「第14章 リファレンスアーキテクチャと構築テクニック」という章が特徴的だと思います。 ここまでの章で「何ができるか」を説明して、第14章で「どう使うか」を説明しています。素敵です。


■ 4. Ansibleと組み合わせてみる

Ansible は Azure にも対応していて、ドキュメントも用意されています。

試しにAnsibleからAzureのVMの作成を試してみました。


■ おまけ(ひとりごと)


まとめ

こちらにあげた本は、すべて私のような初心者から読める本だったので、とても助かりました。 一方で、少々本に頼りすぎた面もあるので、せっかく充実している公式ドキュメントも活用できるようにしたいと思います。

docs.microsoft.com

JANOG41で「勉強会のフィードバックから得られた自動化への壁」という発表をしてきました

■ はじめに

2018/01/24-26 に開催された JANOG41 Meeting のネットワーク運用自動化BoFの枠の中で「勉強会のフィードバックから得られた自動化への壁」というLTをさせていただきました。 この記事では、発表資料の共有と、私なりのディスカッションのおさらいをします。

なお、私が参加したその他のプログラムについては JANOG41 Meeting in Hiroshima 参加メモ をご参照ください。


■ 概要

去年1年間、社内外の勉強会でネットワーク自動化ツールについての発表を数回行いました。頂いたフィードバックなどから自動化への壁を改めて感じましたので、その共有をさせていだきます。また、壁を壊すアイディアや、ほかに感じている課題などありましたら、皆さんからも意見を頂戴したいと思います。

せっかく様々な方が集まる場なので、一方的な情報発信だけではなく、ディスカッション的なことを行いたいと考えていました。


■ 使用した資料

www.slideshare.net


■ ディスカッション

後半に設けたディスカッションの時間で皆様から頂いたご意見を、自分なりに解釈しながらまとめました。

どこから始めたらよい?

確認系

  • 手作業の手順書は設定より確認のほうが多い。確認から自動化してみてはどうか
  • 手作業がしんどい作業を自動化すると効果的
  • 手作業による確認は疲弊しやすい→ミスの元
  • サービス正常性確認は自動化に適している

情報取得系

  • サポートへ問い合わせする際に必要なログ一式を取得してメール送信まで自動化したら効果があった。手作業だと取得漏れが起きやすい。

割り切り

  • 割り切って、失敗しても大丈夫な作業から初めてはどうか

特殊オーダーの難しさ

  • 定型オーダー作業は自動化しやすいが、特殊オーダー作業は自動化しにくい

Jupyter Notebook の活用

  • Jupyter Notebook で自動化をしている事例がある。
  • 過去に利用したNotebookをコピーしてパラメータ変更して再利用するといったことができる
  • (参考)Day3 プログラム Literate Computing for Reproducible Infrastructure

「確認」とは

  • 大きく分けて2つ(特に個人的な解釈が入っています)
    • サービス正常性確認
      • ≒ 監視
      • 監視項目は障害が起こるたびに穴をふさぐように増えていく
      • 穴のふさぎ方のナレッジが共有されるといいのでは
    • 作業の妥当性確認
      • 作業が正しく行われ、想定通りの状態になったかを確認する
        • 例)OSPFのコストを100から20に変更し、自身と周辺のルーターの show コマンドにより、想定するコストになったかを確認
      • サービス正常性確認が正常でも、隠れた想定外設定が入っている場合に後でサービス異常になる可能性がある

テスト駆動

  • テストしながら開発しましょう
  • ステージング環境の監視はテストになるのではないか


■ 詳細

詳細はtwitterモーメントととしてまとめさせていただきました。実況ツイートありがとうございました。

twitter.com


■ まとめ

自動化の対象を検討するうえで、リスクや効果といった軸が見えてきました。 リスクが少なく効果が高い「地味に効く」ような自動化も意外とありそうな気もしてきました。 また、ひとくちに確認といっても、立場や考え方によって何を指すかが異なることもあるようなので、会話や議論する際は少々注意が必要と思いました。

この度は発表や貴重なディスカッションの場をいただき、誠にありがとうございました。

Terraform 初心者が最初の2週間でやったこと

はじめに

Terraform は触ったことがなかったのですが、Ansible のことを調べているとたまに一緒に見かけるツールなので、どんなものかと思っていました。 概要やAnsibleとの使い分けについて知りたかったので、知識ゼロの状態からインプットしました。 あくまで個人の経験ですが最初の2週間でやったことを共有します。


■ 1. どんなもの?

2017年12月に HashiCorp Japan による Terrafrom の日本語の ウェビナーがあったので録画分を拝見しました。

https://register.gotowebinar.com/register/7880841238881662210

概要、ほかのHashiCorpプロダクトとの関係などがざっくり知ることができて良かったです。 興味が出たタイミングと、このウェビナーが開催されたタイミングがあったのは幸運でした。

・参考 tekunabe.hatenablog.jp


■ 2. 類似ツールとの比較

たまたまAzureも触り始めていたので以下の資料を拝見しました。

www.slideshare.net

比較という点では P16 の「ツールの特徴(Azure視点」) がとても参考になりました。

クラウドプロバイダ純正ツールには最新機能への対応の速さや広さなどがメリットとしてあることを理解しました。


■ 3. 試してみる

Terraform: Up and Running: Writing Infrastructure as Code

Terraform: Up and Running: Writing Infrastructure as Code

「Terraform: Up and Running: Writing Infrastructure as Code」という本で、軽くハンズオンをしました。 この本は、AWS を使って試しながら読めるような構成になっているところがあるので、それに沿いました。 AWS 状の操作(IAMなどの下準備)についても操作説明があるので、AWSにあまり慣れていなくても苦労することはありませんでした。

今回は以下の章だけ読みました。

1. Why Terraform
2. Getting Started with Terraform 
3. How to Manage Terraform State

なお、本書で使用されるサンプルコードは以下にあります。 github.com

まとめ

まだまだ、何も見ずに Terraform で何かできる状態にはなっていませんが、当初の目的である、概要やAnsible等の他のツールとの使い分けについてはなんとなく分かりました。 とりあえず、なにか他のことを調べているときに「では、~の準備としてここではTerraformを使います」という説明に出会った時でも「ウッ」とならない状態にはなったかと思います。

自動化を考える前に読んでおきたい本たち

はじめに

自動化のことを考えると、ついつい素敵なツールの使い方に興味が行ってしまうのですが、業務に適用するためには、組織文化や業務プロセスなどその他の事柄にも目を向ける必要があると感じています。このような経緯で、個人的にこれから読んでおきたいと思っている本を簡単にご紹介します。 他にもおすすめの本があれば、@akira6592 まで教えていたけると嬉しいです。



■ はじめよう!プロセス設計 要件定義のその前に

gihyo.jp

プロセス設計ありきの自動化、が正しいと考えています。


■ Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

正しさだけでは人は動きません。 紹介文を引用したところ興味を持たれた方が一定数いらっしゃるようでした。

監訳者によるチートシートもご紹介します。 kawaguti.hateblo.jp


■ 組織パターン チームの成長によりアジャイルソフトウェア開発の変革を促す

www.shoeisha.co.jp アジャイル関連の本ですが、新しいことをするときにも参考になると思います。


■ エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング

gihyo.jp

2018年2月22日発売です。「不確実性を取り除く」ではなく「不確実性に向き合う」というサブタイトルになっているあたりが気になっています。


■ Safety‐1 & Safety‐2―安全マネジメントの過去と未来

Safety‐1 & Safety‐2―安全マネジメントの過去と未来

Safety‐1 & Safety‐2―安全マネジメントの過去と未来

  • 作者: エリックホルナゲル,Eric Hollnagel,北村正晴,小松原明哲
  • 出版社/メーカー: 海文堂出版
  • 発売日: 2015/11/01
  • メディア: 単行本
  • この商品を含むブログを見る

Safety‐1 & Safety‐2 とは安全マネジメントの考え方の分類です。自動化のリスクをどう考えるか、のヒントになりそうだと思っています。

JANOG41 Meeting in Hiroshima 参加メモ

はじめに

2018/01/24-26 に JANOG41 Meeting が広島国際会議場で開催されましました。 f:id:akira6592:20180203200809j:plain

JANOGとは (https://www.janog.gr.jp/information/ から引用)

JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。

JANOGでは年に数回ミーティングという形式のイベントが開催されています。 以前から興味があったのですが、今回ようやく初めて参加(とLT登壇)することができました。

私が参加したプログラムの中で特に気になったものをメモします。

  • プログラム一覧
    • 2018年2月23日(金) 12:59 まで録画公開されているプログラムもあります。



【Day1】


■ ネットワーク運用自動化BoF

ネットワーク運用の自動化ついてのBoF(birds of a feather = 同好会 という説明が1日目にありました)です。 計5本のLTがありました。

・自動化されたネットワーク運用のテストを実現しよう

  • リンク
  • 内容メモ
    • 自動化スクリプト、テスト環境ではうまくいったのに本番環境でうまくいかないことがある
    • テスト環境と本番環境の環境差分をなくすというアプローチのアプライアンスを開発した
  • 感想
    • 後述する私の発表の中にある「検証環境ない問題」を解決する方法の一つだと思いました。

・まずはCode化だ!

  • リンク
  • 内容メモ
    • 自動化のメリットはCode化のメリットでもある
    • 必要十分な自動化手段としてCode化がある
    • pexpectというexpect の Python パッケージを利用したCode化サンプル
    • Code化していく中での疑問は、NetOpsCoding の slack の #beginner チャンネルへ (参加はこちらから)
  • 感想
    • teraterm マクロに近い抽象度の方法でした。手動への戻しやすさがあると思いました。

・NetTesterで多拠点テストも自動化!

  • リンク
  • 内容メモ
    • ボトルネックとなっているネットワークのテストを自動化で解消する取り組みをしている
    • NetTester を実際に導入し、ミスの発見や、品質保証、安心感UPなど効果があった。
  • 感想
    • 途中「ソフトウェア開発の知見を拝借」という文言が登場しますが、自動化に限らずこのアプローチは大切だと思っています。感覚的な話ですが新しい知見や手法は「ソフトウェア開発」→「サーバー」→「ネットワーク」という順に流れているような気がしているためです。

・始動編?それLC4RIでできるよ!

・勉強会のフィードバックから得られた自動化への壁(私の発表分)



【Day2】


■ 明日からはじめるネットワーク運用自動化

  • リンク
  • 内容メモ
    • ネットワーク運用の自動化のためのステップ
    • 必要になる Python の基礎、ライブラリ、汎用テンプレートエンジン(jinja2)、データフォーマット(JSON)、テストについての説明
    • ネットワーク機器の操作のためのライブラリやツール(NAPALM、Ansible、各社提供のもの)の紹介
  • 感想
    • 大勢の方々(300人以上でしょうか)が参加されていたため、関心の高さを改めて感じました。
    • 序盤の自動化の失敗パターンの紹介といった理論の話から始まり、具体的なライブラリ名、ツール名、サンプルコードまでカバーした内容で盛りだくさんでした。
    • 自動化の全体像をつかんだ上で「ここからちょっとやってみようかな」と思うような内容だったと思います。
    • また、このプログラム先だって、1/9に始動編(事前オンラインプログラム)が開催され、資料や動画も公開されています。

■ BDD + Pythonによるネットワーク機器のテスト自動化

  • リンク

  • 内容メモ

    • syslogやtrap受信時の挙動をテストする方法
    • 言語はPython、テストフレームワークはBDDな behave を利用
    • Featureファイルでテストケースを、Stepファイルで実装を記述する
  • 感想
    • BDD(Behavior Driven Development)の考え方は、ネットワークの動作のテストと親和性が高いように感じました

■ RENAT(Robotframework Extension for Network AutomationTesting)を用いたネットワーク検証の自動化について

  • リンク
  • 内容メモ
    • RobotFramework をネットワークの自動テストに利用したツール「RENAT」の適用事例
    • 検証手順をシナリオとして記述
    • 実施ログ、レポートはHTMLで出力される
    • 稼働削減や、他システム連携などの効果が得られた
  • 感想
    • ネットワーク機器を操作するライブラリはいくつか知っていましたが、RobotFramework のようなフレームワークは初耳でした。
    • 作業フローを組み上げるときに参考になりそうなので、どんなものかしらべておこうと思います。

■ NFV+SDN標準化/実装動向と運用の課題

  • リンク
  • 内容メモ
    • ESTI NFV Standardとして様々な標準化が進められている
    • 運用の課題としては、NFV基板のオーバーヘッドや既存環境との連携がある
  • 感想
    • サービスを中心としてネットワークを考える場合、ネットワークとサーバーはあまり区別しすぎない方がよいと思いました。

■ 海底ケーブルの日本への陸揚げについて、その意義と現場 - New Cross Pacific Cable Systemの事例から -

  • リンク
  • 感想
    • オフレコ部分があったため、詳細は記載できませんが、私のメモには「ロマン」とだけ書いてありました。

(懇親会)

600人以上の申し込みがあったらしく、ものすごい人口密度でした。 初参加で一人で来ましたが、初参加者用のテーブルや「自動化」や「広島好き」などテーマごとのテーブルなどがあって助かりました。



【Day3】


■ Interface Descriptionがプロジェクトの財産になる日

  • リンク
  • 内容メモ
    • インターフェースの description に、接続情報を記述して、プログラムで読み込み、構成図を生成するアイディア
  • 感想
    • descitptionメタデータの入れ物して使うアイディアは面白いと思いました。
    • 使用できる文字やパースのしやすさ等の事情で苦労された点が伝わってきました。

■ Literate Computing for Reproducible Infrastructure

  • リンク
  • 内容メモ
    • Jupyter Notebook を利用した実行可能な手順書の提案
    • 作業証跡が残る
    • 正解の実行結果も載せられる
  • 感想

Excel/CSV変換ツールのおかげでshow ip routeのコピペ地獄から解放された話

  • リンク

  • 内容メモ

    • PythonTextFSMNTC-Templates を使って、 show ip route の結果をパースしてCSVにした事例
    • ブラウザから試せるように WebFSMというWeb版も公開
  • 感想

    • showコマンド結果をパースするための正規表現をテンプレート化、シェアできるので、TextFSM / NTC-Templates の組み合わせは便利だと思いました。

福岡大学における公開用NTPサービスの現状と課題

  • リンク
  • 内容メモ
    • 福岡大学では日本で初めてNTPサーバーを立てた
    • 研究目的だったが大勢の人が使い始め、負荷が問題となった
    • 福岡大学のNTPサーバーは停止する予定
  • 感想
    • 歴史のあるNTPサーバーの停止宣言の場に立ち会えたことが思い出に残りました。 f:id:akira6592:20180203200915j:plain

まとめ

これまでのJANOG Meeting に比べ、テーマが多岐に渡っていた印象を受けました。 今回は、自動化(情報収集、設定変更、テストなど)を扱うプログラムが多かったです。 現在の私の興味と一致していたため、まだまだ知らないツールや考え方があることに気付いて大変有意義でした。

また、上記のメモにはありませんが、中国の事情にを扱うプログラムも複数ありました。 電子決済がとても普及していることなどを知り、興味深かったです。

次回の JANOG Meeting は 2018/07/11 - 13 に三重県津市で開催される予定です。次回もぜひ参加したいと思います。 運営者の皆様、発表者の皆様、ありがとうございました。

f:id:akira6592:20180203200832j:plain

togetter

実況&まとめ、ありがとうございました。