ラベル serverspec の投稿を表示しています。 すべての投稿を表示
ラベル serverspec の投稿を表示しています。 すべての投稿を表示

2015年11月6日金曜日

NetOpsCoding #1 参加メモ

開催概要

  • 日時: 2015/10/30 (金) 19:00 to 21:00 (実際には22:00ごろまででした)
  • ビッグローブ株式会社(品川シーサイドパークタワー 3F)
  • ハッシュタグ: #netopscoding

他の方のまとめなど

まとめ・感想

Network 運用のためのCodingの話でした。

似ている勉強会にネットワークプログラマビリティ勉強会(#npstudy)というのがありますが、非常に分野が近いというかOverrapしています。 #npsutdy がネットワークの仕組みとかがメイン(かなぁ)である一方で、 このNetOpsCodingは運用からの視点で見ています。

この勉強会のよいところとしては、運用の視点から具体的な困りごとをベースに議論ができるところかな と思いました。 いろいろな困りごとから出発して、共通的な仕組みができるとうれしいです。

今回の発表では、Microsoftさんの取り組みがありましたが、圧巻でした(資料は2015/11/06現在 見つけられていません)。 最終的にはここまでいくといいと思いますが、規模が大きくない現場ではなかなかここまで作り込むのは大変だと思います。 NetOpsCodingを通して共通的なフレームワークが作れると管理規模が小さい環境でも効率的に管理できてうれしいです。 現状でもCLI, SNMP, NETCONF, Rest APIといろいろなやりかたがあるので、そこを吸収する必要性を再認識しました。

また、今回はLTで5分だけNetwork Test Automationという発表をさせてもらいました。(#npstudyの発表の再構成ですが。) NetOpsCodingを始めるところの敷居が下げられるといいなぁ と思っています。

Introduction of NetOpsCoding

ネットワーク運用者が自動化して、楽して、ミスを減らして、楽しいことに時間を使うために、 どうしたらよいのか?ベストプラクティスを共有したい という趣旨でした。 ネットワーク運用者、ソフトウェア開発者、Network機器メーカーいろいろな立場から、 自動化を進めていきたい という話でした。

ネットワークAPI作成30分Coding

Rubyはじめて半年くらいという井上さんがvSRX(のルータ機能)を NetConfで設定するという話でした。

通信系のデモとしては珍しく(?)、pingではなく、descriptionを設定する ということでした。

Qiitaの記事 をベースに進んでいきました。

今回の例では、最終的にはCLI over NETCONFというような感じだったので、 まずは、これができると、いまの運用との一貫性を築くことができるので、よいと思いました。 (結局、これがないと、いろいろなところで実装しなくなるのでつらいですね。)

Microsoftにおけるネットワーク自動化とそれを支えるソフトウェア群について

  • 発表者: Microsoft 北島さん
  • 発表資料:
    • 見つけられていません。

いくつかのソフトウェア群についての紹介がありました。非常に刺激的で有用なものが多いです。 一方で、これを規模の小さいうちの環境では工数かけられないなぁ とか、そう思うところもありました。 けっこう、一般化できるかもしれないので、仕組みをNetOpsCodingで作っていったら、 みんなで幸せになれるのかもなと 思いました。

ソフトウェア群はこんな感じでした。

  • SES(Standard Enforcement Script)
    • Perlスクリプト
    • 機器のConfigがテンプレートと一致していなければNGとする
    • Model Driven ではなく、Adaptive
  • Pre/Post-change Validation
    • 事前の状態と事後の状態を比較する
    • 事後の状態がテンプレートとマッチしていなくても、事前も同じだったら、今回のオペレーションによるものではない
    • 差分がでたところだけ確認して、問題なければ、そのままにする
  • MPLS Autobandwidth Automation
    • MPLSのBandwidthの制御をするための話
  • Monitoring Intelligence
    • 複数のグラフを時間軸で相関を見る。
    • FibrecutでCPU負荷が上がったり、QoSのプライオリティごとの通信が変化したり、しなかったり
    • CLI, SNMP, Syslogをアグリゲートしている
    • Ping meshでsrc/dstのメッシュをしておくと、どのあたりに問題があるかわかりやすい

YANG modelの話など

NETCONFのデータモデルを記述できるYANGというモデリング言語の話でした。 NETCONF自体はYANGでのモデリングと切り離して考えられる。 しかし、統一したオペレーション(設定と監視)を考えると、YANGでモデリングされている必要があるということでした。(たぶん)

いろいろな機器が統一した記述で(ある程度)設定できるとうれしいです。

ネットワーク運用自動化お悩み相談室

会場の参加者がどのようなところに興味があるかを聞き出す、面白い内容でした。 NetOpsの自動化のイメージが全然違うので、それぞれのイメージを共有したい という意図です。 会場では、まずは設定とチェックのところの自動化をやりたい という感じだったような気がしていますが、記憶が曖昧です。。

ライトニングトーク

Model driven automation!

  • 発表者:
    • CISCO 河野 美也さん

YANGモデルとかの話だったと思います。自分のLTの準備とかしていて、 あまり聞けませんでした。

Network Test Automation

Networkの自動化の第一歩として、基本の動作確認の仕組みの共有です。 Config系の自動化は、ミスすると通信できなくなりますが、 基本動作確認を自動化しても、基本的には通信できなくなることはありません。 なので、そこから最初に手をつけるのがよいのかな という話です。

テストツールとしては次のようなものを紹介しました。(自家製ツールの紹介が多いです。) 使ってみて、Issue、Pull Requestもらえるとうれしいです。

Test Tool対象備考
ServerspecServers(static)
InfratasterServers(dynamic)
Infrataster-plugin-dns (Rspec-dns)DNS servers
Infrataster-plugin-firewallFirewallsTraget serverにtcpdump, netcat が必要
LbspecLoad Balancers(L4-L7)Target serverにngrep, netcat が必要
Rspec-ssltlsSSL/TLS

機能的なテスト以外(性能系のテストなど)は、ここではできていないので、 性能などを計測したい という場合は、別途そのようなツールが必要です。

テスト駆動型ネットワーク

ItamaeとServerspecを使ってテスト駆動でCumulus Linuxの設定を作っていく事例でした。 本番環境以外に開発環境がある場合は、このやり方でやりたいです。

インフラ屋の友:Tera Term

Skypeでの参加ということで、驚きました。 内容はTeraTerm のスクリプトを使った自動化でした。 expectやこの手のツールも、使うのと、使わないのとで大きな差があるので、 ここのあたりも共有できるとよいのでしょうか。 (私はTeraTerm使っていないですが。)

2015年4月26日日曜日

ネットワークプログラマビリティ勉強会 #4 @GMO Yours

ネットワークプログラマビリティ勉強会 #4 @GMO Yours

開催概要

他のかたのまとめ

いろいろまとめられているので、全体的なのは他のかたのメモを参照してください。

感想

今回は、LTの発表をしたせいで、あまり他の人の発表をこころの余裕をもって聞くことができませんでしたが、 自分としては発表することで自分が知りたい内容がしれたのでよかったと思います。
一番大きい収穫は、この勉強会にどのような人が来ているか?ということがわかったことです。 「ネットワークエンジニア」というのは、範囲が非常に広いので、発表者がどのような人をターゲットに話をしたら いいのかが難しいと思っていたからです。
今回の超おおざっぱな私の集計によると、次のようになっています。(重複含む。全体人数は100人くらい)
TypeRelated toHow many people at this study?
SDNOpenFlow, OpenStack20 people
InternetBGP10 people
IntranetWAN, Inter DC15 people
DC internalFirewall, Load balancer,L2/L3 switch30 people
Platform ServiceDNS, mail, proxy20 people
ServerLinux, Windows,20 people
ApplicationWeb Service, Mail Service10 people
全体として、SDNとかをいま使っている人は20%くらいで、80%の人はSDNとかに興味はあるけど、 いまの活動としてはあまり使っていないということでした。 DNS, mailとかの基盤サービスをやっている人も結構いて、「ネットワークエンジニア」が広いということがわかりました。 (自分の中の仮説どおりです。)
よかったことと、改善できたらいいな ということをまとめるとこんな感じです。

よかったこと

  • #npstudy というハッシュタグがついたことで、いろいろ情報がまとまったこと
  • どんな人が参加しているかがわかったこと
  • 具体的なプログラミングのことになると、けっこう、一歩引いてしまうということがわかったこと
  • 会場設備がよくて、Wifiやドリンクも提供していただいたこと(GMOさんありがとうございます)

改善できたらいいな ということ

  • 終了がギリギリになってしまって、懇親があまりできなかったこと
    • LTでは質問を受け付けず、会場での懇親の場(30分でも)で聞いてくださいのほうがよかったかもですね

発表

自分の気持ち的に、全体の発表はあまり見れなかったので、自分の発表のところだけ。。

ネットワークのテスト自動化(Network Test Automation) @otahi


ネットワークテストの自動化して、インシデント対応などでの「ダブルチェック」の再発防止を減らしていきたい。 そういう感じで話をしました。
自前のテスト自動化ツールなどの紹介をしたので、「なんだ」と思ったかたもいたと思いますが、 OSSなので、自分で書き換えれば、もっとよくなりますよ! ということで。。
今回紹介したツールは、以下のとおりです。(上の2つ以外は自作ツールです。)
TypeTest targetRemarks
ServerspecServers(static)
InfratasterServers(dynamic)
Infrataster-plugin-dnsDNS servers
Infrataster-plugin-firewallFirewallsTraget server needs: tcpdump, netcat
LbspecLoad Balancers(L4-L7)Target server needs: ngrep, netcat
RSpec-ssltlsSSL/TLS

今回紹介しなかったですが、RSpec-proxypac というproxy.pacをテストするツールもあります。

将来的にはOpenFlowを使って、TDDできるとおもしろいかなと思っています。
Trema に興味をもって、Rubyを始めたので、そろそろTremaに恩返しをしたいとは思っています。

スライドは適当な「英語」で書いていますが、私のボキャブラリの範囲なので、 難しいことはないと思います(英語的に意味がわからないことはあるかもしれませんが)。
なぜ、英語で書いたかというと、せっかく書くのだから 「スライドだけ」でも他の人にも見てもらえたらな と思ったからです。 OSSのツールを広めるのであれば、英語圏(全世界)の人が見てくれたほうがいいですよね。
このスライドに対して、2015/4/23に発表して、2015/4/26 07:22現在で、USからのアクセスもそれなりにありますので、 英語で書いておいて、効果はあったかな と(とはいえ、このblog記事を英語ではかけなかった。。)。
  • Top countries
NameViews
Japan464
United States68
Canada5
France4
Philippines2


Happy network life!!!

2013年6月22日土曜日

hbstudy#45「serverspecが拓いたサーバテストの世界」に参加してきた

開催概要

  • hbstudy#45
  • 2013/06/21(金) 19:00〜
  • ハロー会議室新宿
  • 第45回: serverspecが拓いたサーバテストの世界

感想

  • 宮下さんを見習って、子供と一緒にがんばろうと思う。
  • まずは自分の担当するところでまずは試してみよう。
  • 最後にテストを回すというスタイルから、できあがったときにはテストは終わっているという状態にしていきたい。

全体まとめ

  • serverspecは
    • 機能が欲しい人が実装するという基本
    • puppet, chefとかの仕組みと疎結合
      • できあがったserver自体をテストするので
    • 「読みやすい、書きやすい、わかりやすい」を大切にしている
    • spechelperを書き換えればいろいろできる
  • 気軽にpull requestしてほしい
  • やりたいことがあれば各自実装を!

追加情報(2013/06/23追加)

paperboy&co. Technical Manager 宮下 剛輔さん [twitter: @gosukenator]

serverspecの位置づけ、serverspecとは、使い方

  • 宮下さん @gosukenator
    • paperboy&co
      • ロリポップなどのレンタルサーバなどで有名
  • サーバプロビジョニングとは
    • いろいろな領域が含まれる(大きくは3つ)
      • Application Service - Orchestration
        • 方法
          • Capistrano
          • Fabric
        • テスト
          • 外から見る
            • zabbix
            • Nagios
      • System config - Configration(きょうはここが中心)
        • 方法
          • puppet
          • chef
        • テスト
          • serverspec
            • サーバ自身を見る
            • パッケージとかもみる
      • os, vm - BootStrapping
        • EC2
        • OpenStack
    • 監視とは継続的なテストである @kazuho
    • Zabbixとかあれば、serverspecいらない ともいえなくはない
      • Zabbixで継続して監視ししながら実装できるのであれば
  • System configとテスト
    • これまでは?
      • shell script?
      • 実際のサービスの確認だった?
  • Configuration Management Framework(CMF)
    • puppet
    • chef
    • ansible
      • orchestrationも含んでいるツール
  • CMFとテスト
    • これまでは?
      • shell script?
    • 界隈のツール
      • シンタックスチェック
        • foodcritic
        • knife cookbook test
      • ユニットテスト
        • chefspec
          • 実際のサーバでやるのではない
          • chefの正当性を確認するためのツール
        • rspec-puppet
      • 結合テスト
        • Minitest Chef Handler
        • Cucumber Chef
        • Test Kitchen
        • rspec-system
          • puppet用
        • serverspec
          • puppetでもchefでも
    • なぜ serverspecを作ったの?
      • 余計な機能が多い
      • chef,puppetなどのツールに依存している
    • TestKitchenと合わせると良さそう
    • そもそもserverspecが必要なの?
      • 一度だけ書いて、修正しないなら不要
      • マニフェスト、レシピを継続的に更新するなら必要
        • これの自動化のために必要
      • テストコードの書きやすさ、読みやすさも重要
      • テストツールのシンプルさが重要
        • なので、serverspec
  • serverspecについて
    • サーバのテストを「簡潔に」書くための仕組み
      • RSpecで書く
        • 読みやすい
          • 最近expectで書くのがよいとされている→少し読みにくい
      • しかし、shouldのほうが見やすい
        • serverspecではshould全部のオブジェクトにshouldメソッドをつける必要がないのでよい
    • serverspecはshellからコマンドたたいているだけ
    • コマンドのパターン
      • ローカル
      • ssh接続
        • エージェントをいる必要はない
        • コマンドを実行するだけなのでテスト対象にはrubyすらいらない
  • severspecのはじめかた
    • # yum install rubygems
    • # gem install serverspec rake
    • # serverspec-init
      • ssh or local?
      • ファイル、ディレクトリができる
    • # rake spec
      • .rspec で–colour で色つく
      • –format S で文字列で表示
      • まさにテスト駆動でできる

serverspecについて

  • serverspecが生まれた経緯
    • 2007年 puppetを使い始めた
    • puppetで構築は自動化できた
    • テストをどうするか?
    • テスト報告を簡単に作りたい
    • Assurerというperlツール作った
      • テスト駆動サーバ構築! 2007年
      • 面倒。。
        • レポーティング機能をつけたので重くなった
      • 実用にいたらなかった
    • puppetのマニフェストのリファクタリングをしようと思った
    • テストが必要だろう
    • rspec-testはモジュール型になっているマニフェストのテストにしか使えない。。
      • モジュールかされていないものにはテストがかけない
    • マニフェストをテストではなくて、実際のサーバの状態をテストすればよい
    • @hibomaがやっていたこと をパクッてgem化した
    • sshでできるように、rubyなくていいようにした
    • local実行、OS判別などを追加してもらった
  • なにができる?
    • いろいろマッチャがある
    • 任意のコマンドがたたける
    • sshのときはstderrとstdoutが混ざる
  • serverspec.orgをみて
  • サポートOS
    • サポートしている
      • Redhat系
      • Debian
      • Gentoo
      • Solaris
      • Darwin
    • サポートしていない
      • BSD
        • 利用者がいないから??
      • Windows
        • 以前移植しようとしている人がいたがまだpull requestがきていない。。
  • serverspecはsudoしてrootで実行している
    • sshのみ
    • Localではsudoはしない(たたくときにできるから)
  • パスの追加設定もできる
    • spec helperで
    • システムが違うとだめだから
  • 一部パスを追加することもできる
  • precommandでテストコマンドの前に実行して&;&で実行できる
    • 今後サポートするかは不明
  • サーバーごとにディレクトリを掘る
  • ロール単位とかもできるserverspec.orgのadvanced tipsにある
  • テストを常に実行する環境を作りたかった
    • Ukigomo
      • IRCでもできる
  • 一部を変更したときに全体を壊していないことを確認できる
    • CIできる

serverspecのコントリビュータを増やすための話(メモれていない。。)

  • プログラムの内部の話 github-mizzy/serverspec
    • fileの例(コードを読むと結構わかりやすい気がした。)
    • beinstalledの例
  • serverspecのテストの話(十分理解はできなかった。。)
  • 全部実装していなくてもpull requestしてほしい
    • 作業中の場合はWIP(work in progress)とつけておく
    • 自分のOSで動けばOK(他のOSを気にしているときつくなるので)
    • お気軽にpull requestしてください

まとめ

  • 読みやすい、書きやすい、わかりやすい
    • 簡潔
      • 簡潔さ重要
  • 要件が変わる
    • 継続的なテストが必要
    • テストも複雑になる
      • 簡潔にし続ける

質問

  • Q. ユーザーはサーバに対して固定?
    • spechelperが固定になっているが、対応付けすればOK
  • Q. このユーザーはこれができて、このユーザーはこれができない というのはできない?
    • 基本はやりたい人が実装してもらえれば。。
    • コマンドをかけるので、sudoを使ってコマンドで書いてもよいかも
  • Q. paperboyも実運用で使っている?
    • まだあまりない
  • Q. 量が多くなると、時間かかる?
    • RSpecの並列化ができるのではないか?

イベント告知(馬場さんより)

  • 立て続きにあるので、各自確認を
  • hbstudy#46 トラブル☆しゅーたーず#06 ~chain reaction~
    • 日時: 2013/6/29(土) 13:30~20:00
    • 会場: ニフティ株式会社 ラウンジ&会議室
  • hbstudy#47 July Tech Festa 2013 コードの中のインフラ(Infrastructure as Programming)
    • 日時: 2013/7/14(日) 10:00~21:00
    • 会場: 産業技術大学院大学(AIIT)
  • hbstudy#48 インフラ+セキュリティ=楽しい? 他2本
    • 日時: 2013/7/19(金) 19:00~21:30
    • 会場: ハロー会議室 新宿 B+C (東京都新宿区西新宿1丁目5-11 新宿三葉ビル6F)
    • DeNA茂岩さん がいろいろとお話を。