はじめに 2020/02/24 にシスコ認定技術者試験の制度が大きく改定されました。 それに伴い新しく始まった、ネットワーク自動化、プログラマビリティに関する資格である DevNet Associate Exam v1.0 (DEVASC 200-901) を受験して合格しました。 この記事では私の勉強方法や感想をまとめます。 ■ 勉強方法 試験範囲はこちらで確認できます。(PDF) https://www.cisco.com/c/dam/global/ja_jp/training-events/training-certifications/exam-topics/200-901-DEVASC.pdf Python、API、開発手法、自動化、セキュリティ、Git、Ansible(!)、ネットワーク基礎などなど、なかなか範囲は広いです。 勉強を始める前 勉強を始める前はこんな状態でした。目

はじめに Visual Studio Code（以下、VS Code）で Ansible の Playbook を書く時に、私が便利に利用させてもらっている拡張をご紹介します。 「自分は Windows で VS Code 使ってて、Ansible は SSH 先の Linux だから関係ないや。」という方も、最後の「Remote Developement」まで見ていただけると幸いです。手元が Windows でも通用します。 動作確認環境: VS Code 1.38.1 その前に・・標準ではどんな感じに？ VS Code では特に拡張を入れなくてもある程度は Playbook が書きやすいようになっています。 具体的には Playbook の拡張子を .yml または .yaml にするこことで、言語として YAML が選択されます。 これにより、シンタックスハイライトが効くようになり、

はじめに サーバーのテスト自動化といえば、 Serverspec や Testinfra 、infrataster などが有名ですが、ネットワークのテスト自動化については、みんなが口をそろえて名前を出すものがないような印象です。一方で、リスクの観点から設定変更の自動化より先にテストや状態確認の自動化からはじめたいというケースもあるのではないでしょうか。 この記事では、どんなツールや組み合わせがネットワークのテストの自動化に使えそうかをまとめます。 ざっくりとした内容となっていますが、もし誤りや不足などありましたら @akira6592 までご連絡いただけると幸いです。 一覧 名前 タイプ 実機接続 主なテスト内容 言語 NetTester フレームワーク 要 物理ネットワークの受入テスト Ruby pyATS フレームワーク 要 疎通や show コマンド実行結果の妥当性 Python A

■ Batfish とは: 実機に接続することなくコンフィグを検証 Batfish は、ネットワーク機器のコンフィグの様々な検証ができるツールです。 実機に接続する必要はありません。 準備したコンフィグファイルを読み込んでパースし、解析して内部でネットワーク機器が動作するようなイメージです。 本体は Java で書かれていて、Python から扱うためのクライアントである pybatfishもあります。 設定変更のコンフィグの妥当性を、あらかじめ Batfish で確認してから実機に投入する、というようなことが実現できるのではないかと、最近興味を持ちました。 明日調べる / Batfish "An open source network configuration analysis tool" https://t.co/eoAHh8QW0l— よこち(yokochi) (@akira659

■ はじめに 2018/06/13 -15 に幕張メッセで開催された Interop Tokyo 2018 に参加してきました。 www.interop.jp 今回は、Ansible というキーワードを中心にしてブースを回ってみました。 回ってみた各ブースなどで紹介していただいた内容を簡単ですがまとめます。 ■ Show Net 一括設定 現物は見逃してしまいましたが、以下のツイートを後で見かけました。 一括設定に Ansible Tower が利用されていたそうです。 Ansible Towerで一括設定！！(≧∇≦)#interop18 pic.twitter.com/RlOxoBExHP— もりはや (@morihaya55) 2018年6月15日 ■ セイコーソリューションズさん SmartCS と Ansible の連携（参考出展） コンソールサーバー SmartCS とAnsi

■ はじめに 2018/07/11 - 13 に三重県津市で開催された JANOG42 Meeting in Mie（ホスト：株式会社ZTV様）で「Ansible ネットワーク自動化チュートリアル」を発表してきました。 Ansible ネットワーク自動化 チュートリアル :: JANOG42 Ansibleの初心者向けのチュートリアルとなります。 主にサーバ向けの構成管理ツールとして利用されるAnsibleですが、近年はネットワークの構成管理および自動化ツールとしても利用されるようになっております。 今回はこれからAnsibleを始められる方や初心者向けに、概要/基礎から簡単なプレイブックの書き方などを紹介して参ります。 ありがたいことにご縁がありまして、レッドハットの北山さんからのお誘いで共同セッションという形になりました。 ■ 資料（デモ動画付き） Ansible ネットワーク自動化チ

■ debug モジュール - debug: msg: "{{ var1 }}" のようにすると var1 変数の内容が 表示されます。 公式ドキュメント debug – Print statements during execution — Ansible Documentation ■ -v オプション ansible-playbook コマンドの -v オプションでデバッグ的な情報が画面に表示されるようになります。 -v、-vv、-vvv といったように、 v の数が多いほど詳細な表示となります。 ■ --step でステップ実行 playbook 中のタスクを一つ一つステップ実行していきたい場合はありませんでしょうか。 ansible-playbook コマンドに --step オプションを指定することでステップ実行ができます。 実行例 [vagrant@centos7 vagra

はじめに Ansible 2.1 から ansible-console という、REPL のような対話型コンソール機能があります。 モジュール名やオプションのTAB補完ができて便利なので、動画付きでご紹介します。 デモ動画 以下のデモ動画でお分かりになるかと思います。 補足 確認したバージョンは Ansible 2.4.0 です。 上記で指定しているオプションは ansible-playbook コマンドと共通です。 インベントリの指定オプションでは "-i 172.16.0.3," のようにカンマを含めていますが、この場合はインベントリファイルではなく、直接ホスト名を指定することになります。 host_list - Parses a‘host list’string 参考 qiita.com ansible-console — Ansible Documentation

■ 1. はじめに Ansibleのネットワークモジュールを使いたいとき、試す環境がなくて困るケースはないでしょうか。 https://labs.networktocode.com/ といった有料のラボサービスもありますが、手元に無料で構築したいこともあるかと思います。 この記事では、仮想Junos4台とAnsibleホストをVagrantで気軽に構築する方法をご紹介します。 以前書いた以下の記事の応用編です。 tekunabe.hatenablog.jp なお、私が試した環境は以下の通りです。 Windows 10 VirtualBox 5.2.26 Vagrant 1.9.5 (大変参考にさせていただいた海外のエントリがあったのですが失念してしまいました・・) ■ 2. 構成図 以下の構成の環境を構築します。 ■ 3. Vagrantfile の用意 以下の内容のVagrantfile

2017/10/06 にレッドハットさんを会場として開催された 「3社共催 Ansible セミナー "経験から学ぶ Ansible の活用方法" Part 3」 に参加してきました、参加メモを掲載いたします。 殴り書きに近い箇所もあるため、貼り付け付けたPDF資料もあわせてご参照していただければと思います。 （資料の掲載も主催の方から許可をいただいております。） [目次] ■ 1. Ansible 最新情報 (by レッドハット） 【発表資料】 Ansible とは 9/7 Ansible Fest での発表 いままで これから Ansible Engine とは Ansible 2.4 Ansible Tower 3.2 新機能 トレーニング ■2. みんなで使おう Ansible 応用編 （by ライトウェル） 【発表資料】 インベントリ kintone との連携の概要 Dnyami

Ansibleでshowコマンドの結果をパースする方法が増えてきています。 この記事ではCisco IOSを対象として、標準でできるかどうか、どういう情報をパースできるかなどの観点で、4つの方法を簡単にまとめます。 ■ 概要 parse_cli_textfsm フィルター Ansible 2.4 から標準で利用可能。TextFSMテンプレートを利用して拡張可能。 ansible_helpers フィルター サードパーティ製。TextFSMテンプレートを利用。 ios_facts モジュール Ansible 2.2 から利用可能。パース可能情報は少なめ。 napalm_get_facts モジュール サードパーティ製。 ■ 1. parse_cli_textfsm フィルター ・タイプ 標準のフィルタープラグイン Filters — Ansible Documentation ・利用可能バー

2017/09/01 に Ansible Meetup in Tokyo 2017.09 が開催され、参加とLT登壇してきました。 ansible-users.connpass.com テーマは「ネットワークをAnsibleで自動化せよ！」 簡単ですが、個人的な気付きやメモです。 ■「ここまでできるぞ F5! Powered by Ansible」 F5 Networks テレンスさん/岡本さん Ansible 2.4 では F5 モジュールが結構な数に増えるようです。 github.com いろいろ試すことができるsuper-netops-containerというDocker環境があるようです。 github.com ■「Ansibleで挑むInfrastructure as Codeへの道」 リアルグローブ 廣川さん (h-hirokawa) オライリーの「Infrastructure

■ はじめに Juniper社は、検証用に仮想ファイアウォール(firefly perimeter/vSRX)のイメージファイルを提供しています。 イメージファイルはVagrant Cloud上(旧Atlas)にあります。 app.vagrantup.com この記事では、ちょっとした操作感を簡単に試したり、ネットワーク自動化ツールとの連携を試したりする目的でローカルに環境を構築してCLI、Web GUIでログインできるところまでの手順を説明します。 環境 OS: Windows 10 64 bit 仮想化ソフトウェア: Virtualbox 仮想環境構築ソフトウェア: Vagrant ■ Virtual Box のインストール 今回は仮想化ソフトウェアとして Virtualboxを利用します。インストールしていない場合は以下のページからダウンロードしてインストールしておきます。 http

2017/07/21 に 「ネットワークの自動化、何つかう？～自動化ツール紹介～」という発表をしました。 8a1-apc.connpass.com 発表に使用した資料はこちらです。 ネットワーク自動化、なに使う？ ～自動化ツール紹介～　(2017/07/21開催) from akira6592 www.slideshare.net 質疑応答ではsaltに関する質問が多かったように思います。まだ日本ではマイナーだからでしょうか。 なお、同じ内容を8/18にも開催する予定です。 8a1-apc.connpass.com

■ はじめに マルチベンダー対応のネットワーク機器制御ライブラリのNAPALMには、ansibleと連携するための napalm-ansible というモジュール群があります。 今回はその中の napalm_get_facts というモジュールを利用して Cisco IOS 機器の様々な情報を取得してみます。 [githubリポジトリ] GitHub - napalm-automation/napalm-ansibleGitHub - napalm-automation/napalm-ansible [参考情報(Aristaでの例)] AnsibleとNAPALMの連携を試してみた – ネットワークエンジニアが日々の出来事を語る なお、標準モジュールである ios_facts を利用する場合は、以下の記事をご参照ください。 tekunabe.hatenablog.jp ■ 準備 NAPAL

先日、オライリー「Infrastructure as Code」の日本語版が発売されました。 www.oreilly.co.jp 副題にある通り「原則とプラクティス」をメインに書かれていて、特定のツールに依存しない内容になっています。 特に1章「課題と原則」は何度も読み直したくなる内容でした。（さらに言うと"1.2.1 Infrastructure as Code の目標" は壁に貼っておきたいような内容） 全体としては 「 予防より復旧 」が重要という印象をうけました。 一通り読んでみましたので、個人的に印象に残ったポイントをまとめます。 1. 大きな変更より小さな変更を日常的にする 小さな変更のほうが失敗したときに問題を特定しやすく、戻しやすい。 小さな変更のほうが確実に改善でき、モチベーションも保たれる。 2. システムを絶えず変更し、改良しているチームの方が大小の障害に対処できる力