2015年7月4日土曜日

ネットワークプログラマビリティ勉強会 #5

開催概要

OpenStack CongressとDatalog

  • @motonori_shindo さん
  • 今回のタイトルの背景
    • 前々々回の宣言的言語に触発された。
  • OpenStack Congressとは
    • Policy as a Service をになうプロジェクト
    • Congress = 議会 というところから、Policy を制定するところ というイメージ。
    • Standaloneでも動作するが、OpenStackと一緒に動作するのが、もっとも効果的。
    • https://github.com/openstack/congress
  • Policyとは？
    • 何かしらによって課される制約に対して、どうあるべきかを規定するもの
      • 法律
      • ビジネスルール
      • セキュリティ要件
      • など
  • 汎用的なPolicy Language
    • Datalog
    • 一階述語論理に基づいた宣言的論プログラミング言語
      • DSL
    • 1970年代からある
    • Prologに似ている
      • 会場でPrologを5行以上書いたことある人
        • 多少いた
      • PrologとDatalogの違い
        • 停止することが保証されている
        • Function symbolがない
        • 節の順序は無関係
        • リストの概念がない
        • カット(!)やfail(強制させる)オペレータがない
    • 書式
      • ヘッド :- ボディ
      • <atom> :- <literal 1>, <literal 2>, <literal 3>, .. <literal N>
      • literal 1, 2, .. Nがなりたてばatomがなりたつ
    • Safty Properties
    • Datalog(Prolog)書き方
      • ファクト
      • ルール
      • そして問い合わせ
    • 用途
      • Monitoring
        • ポリシーを照らしあわして、もしミスマッチがあればレポートする
      • Enforcement
        • 違反があったら回避するアクションをとる
      • Audiing
        • PolicyやPolicy違反の履歴管理
    • 制約
      • いまは再帰のルールはできない
    • サポートしているCongress 用ドライバ
      • OpenStackファミリ
      • :
      • vCenter

QA

  • 性能は？
    • ちょっと前まではすごく遅かった。最近大幅向上している。何百台。
  • だれがかくのか？
    • クラウド管理者がかく。ユーザーがかくものではない
  • メリットは？
    • 意図した状態を保つのは難しい。システムでなんとかしたい
  • なぜVMWareが力をいれている
    • VMWareが最初スタートしたからかな。

感想

OpenStackでないシステムであれば、ZabbixとかNagiosが監視、アクションをやっている。 ここではSNMPだったり、サーバにエージェント入れたりして、いろいろやっている。 OpenStackで統一的なポリシー管理の仕組みを作ると統一できるってことかな。 OpenStackを目指して、vendorが仕組みを統一できるといろいろメリットはありそうな気がした。 (NETCONFとかも一緒か)

クラウドを活用したシステム構築における、ネットワークのInfrastructure as Code

  • @qb0C80aE さん
  • 今日の話
    • SDN
    • オーケストレーション
    • その他
  • Infrastructure as a Code
    • 管理されたコードが正
  • Infrastructure as a Codeおさらい
    • Chef, Puppet, Ansible とか
    • 最近の概念
      • Immutable
      • Blue-Green Deployment
        • Immutable、Blue-Greenなら冪等性いらないよね→シンプルになる
  • AWS、OpenStackとかIaaS
    • APIで制御できる
    • この場合のコード化は
      • 利用側からみたもの
      • IaaSが隠蔽している
      • OpenStack Neutron API
        • Extentionで拡張できる
        • プログラムを書いて、丸投げして、
      • オーケストレータ
        • コードを宣言的 or 一部手続き的に記述し、書いたとおりにリソースを積み上げて実現
        • CloudFormation
          • JSONでかくとできる
      • テストも自動化でできる
        • ServerspecとかInfratasterとか
      • オーケストレーションの発展
        • 使いたいクラウドをうまく組み合わせてシステムを構築できる
        • Terraform
          • provisionerで定義
            • 使えるモノが変わってくる
        • resourceで定義
  • ネットワークの構成要素
    • ネットワークの構成要素とは。
      • Node?Link?Patch?…
      • 人によって全然違う。
  • CloudFormationみたいなモノ
    • OdenOS
      • トポロジのコントロールが主体
  • コード記述の標準フォーマット
    • ないのかな？
    • 作りたいなということで動き始めた
    • 上から下まで設定できたらいいな

QA

  • ネットワークを管理する目線で言語、記載方式とかの概念をがんばって、いまのやつでできるのか？
    • オーケストレーションとかでけっこうできる。ありものはありものでかけるっていうのができるといいな と。
  • ネットワークの設定とかは共通的になってきたのかな。ネットワークがなぜ宣言的になったほうがよい？
    • 手続きだと辛い。インフラ(ネットワーク含む)が宣言的にできるといいな。でもなかなか難しい。

感想

ネットワーク機器のマネジメントについては、既存の機器を考えるとなかなか難しいな。 基本的な部分だけでも(どこまでが基本的な部分か というのが人によって違うのだろうけど。)、 統一的に設定できるようになるとうれしいかもしれない。 そういう意味では、TerraformとかServerspec(Specinfra)のようにprovidorというか、実装は 泥臭いことをしているけど、ユーザーはJSONを書けばそれなりにできるとかがあるといいのかもしれない。 (過去機種もCLIとかでいろいろやれば、なんとかなるだろうし。(基本的なところは！))

エンタープライズにおけるOpenflowユースケースを考える

  • @Clorets8lack さん

− 資料

  • 会場の情シス担当者は？
    • ほとんどいない。。
  • エンタープライズ運用担当者の特徴
    • 既存のネットワークを置き換えるという発想はない
      • もどせるとうれしい
    • 「可視化」がキーワード
      • 運用定量化と効果計測のため数値化を常に考えている
  • SDN
    • プログラミングは解決手段の一つ
  • ユースケース2つ
    • 冗長システムのコントロール
      • 問題点
        • 切り替えがうまくできないコトがある
          • ハングアップなど、ダウン検知が難しい障害がある
          • 情シス担当者には最悪
            • 2倍払って、なに？これ？ と経営からいわれる。
      • 解決方法
        • サービス監視を高度化する
          • 自動テストを書いて、それを流す(高度な死活監視)
        • 切り替え処理を単純/確実化
          • 抜線と一緒にする(ポートStateの制御)
        • なぜフロー制御でなく、ポートStateの制御なのか？
          • 現時点で状態が把握しやすい LEDとかで見やすい
          • 他の担当に動作を説明しやすい
          • アナログな手段で容易に再現可能(本当に線を抜くとか)
        • 具体的な切り替え手順
          • NICチーミングを使う
          • 優先I/Fをあらかじめダウンさせておく
        • 使いどころ
          • 冗長機能がない製品を無理矢理冗長構成をする
          • HAクラスタ製品のだめ押し
        • やってみた感想
          • 障害状態の保存という移管点では、ポートダウンが使いづらい
    • パケットキャプチャによるエビデンスベースの障害対応
      • 海外情シスあるある
        • 「エラーログが出ていないのでこちらに問題はありません」
        • 「ログがないのでこれ以上調べられません」
      • エラーログが正しく出されているとは限らない
      • それなら
        • パケットキャプチャで証拠を突きつけて「短く」会話する
        • 詳しそうなオーラを出して押し切る
      • 運用上の問題
        • 再現できない
      • 解決方法
        • 容量を大きめのリングバッファでパケットをキャプチャしておく
        • 問題が発生したらそのパケットを保存しておく
          • Sonarmanというものを作りました
        • OpenFlowでミラーポートを制御
        • ポートごとにVLAN TAGをつけるとあとでわかりやすい
          • 海外だと元の配線にしないで帰るとかあるので、これで助かる

QA

  • 引き継ぎの話をどうするの？
    • ドキュメント書きましょう。現場の人しかわからないことが多いので、現場で伝えられるように。
  • 昔のやつでいろいろやったら、すべてのポートがシャットダウンしたことがあった、気をつけていることは？
    • 全部が切れることはなかった
    • 5本入っています、全部、5本切り替える とか気にするところはある
  • 運用と自分でのプログラムするのの両立は？
    • 情シスは現場のやりたいというのい弱い。
    • ニーズありきで、どうやるか。同じ居室の会議室を2社でどのように利用するか など、そういうときに課題解決できるかな。
    • これからどう両立するかは考えないといけない

感想

前回に引き続き、非常におもしろい話だった。 情シスのひとはあまりこういう勉強会にはでてこないのかな。 情シスのひとで、運用のためにコード書いている人はあまりみないし。 (外部の業者さんが書いていたりするのだろう)

運用の自動化のためにプログラム書いたりすると、属人性があがってしまうところは、もどかしい。 情シスで「高度自動化チーム」とかを作って、そこのチームでは使用言語とか仕組みを統一する とかがいいのかもしれない。 (このチームもどのくらい効果があるか、とかを可視化しないといけないのか。。。)

自動でできるかな？

  • @_norin_ さん
    • データセンターの中のひと
  • きょうの話
    • 定型作業の自動化、その結果
    • 機械と話をするところ
  • シナリオ
    • L2-ホスト間のInterfaceを設定して、L3でping確認する
  • How
    • CLI
      • 最強。人間には優しいが、自動化はやりにくい。
    • SNMP
      • Link UP/Down
        • snmpset … IF-MIB::ifAdminStatus
      • Duplexなど他はほとんどreadonly
        • VLANはprivate MIBにある
      • 敗北。。
    • NETCONF
      • 古い機器にはない。
      • 新しいのも結構ばらばら
      • CLI over NETCONFみたいのがあるが、結局これで十分？
    • REST
      • 3750ではHTTPでコマンドをいれられる
      • マニュアルとかでは見つからなからない？
    • Web UI
      • LiveHTTPHeaderとかで見て、やればいける。
  • 今後の課題
    • メッセージボディの規格がまとまっていない
    • 古い機械をどうやってすくっていくか。

QA

  • 時間不足のためQAは懇親会パートで！

感想

新しいネットワーク機器だと、だいぶ、自動化やりやすくなっているのかなと思う。 EsxiとかもRubyのライブラリでけっこう簡単にいろいろできる。 利用シーンを限定すれば、L2スイッチとかでも自動化はまぁまぁいけるのかな。 なかなか汎用的なものは作れないので、ネットワーク技術者が利用シーンに応じて、 プログラミングして、自動化するのが現実的なのかもしれない。 ただ、このあたりは情シスの課題と同じかな。(属人的になるとその人がいなくなると終わる。。)

投稿者 時刻: 0 件のコメント:
ラベル:

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!!!
投稿者 時刻: 0 件のコメント:
ラベル: , , , ,

2014年9月29日月曜日

vagrant-proxyconf(1.4.0) supports docker (en)

Hello, proxy fans in the world,

Finally,vagrant-proxyconfdocker has been released!(version 1.4.0).So, you can run docker easily behind a corporate proxy.

docker

You can use vagrant-proxy docker support for docker hosts on ubuntu, RHEL(6,7), CoreOS, boot2docker and so on.

It is easy to use. Install vagrant-proxyconf, then add your proxy configuration to Vagrantfile. If you already use vagrant-proxyconf, you don't need extra configuration for vagrant-proxy docker support.

vagrant-proxyconf installation

Install vagrant-proxyconf

$ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$

If you can't install vagrant plugin because of proxy server. Try the followings.

$ http_proxy=http://myproxy:3128/ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$

Vagrantfile

Add configuration.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  if Vagrant.has_plugin?("vagrant-proxyconf")
    config.proxy.http     = "http://myproxy:3128/"
    config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"
  end
  # ... other stuff
end

Running docker

After vagrant up, try to run docker.

vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker.io pull -t 14.04 ubuntu 
Pulling repository ubuntu
ad892dd21d60: Download complete 
vagrant@vagrant-ubuntu-trusty-64:~$

If you set http_proxy, it will affect for https communication for docker. You can use private repositories in your intranet, because you can set no_proxy.
docker/registry/registry.go
docker/registry/auth.go
The Go Programming Language Source file src/pkg/net/http/transport.go

Happy proxy life!!

Docker logo and marks usage

投稿者 時刻: 0 件のコメント:
ラベル: , ,

vagrant-proxyconf(1.4.0) supports docker

全国のproxy愛好家みなさん、こんにちは。

ついに、vagrantを使う上で欠かすことのできないvagrant-proxyconfにdockerサポートが加わりました(version 1.4.0)。これでproxyの内側でも気軽にvagrant上でdockerが使えるようになりました。

docker

対応している主なゲスト(dockerのホスト)としては、ubuntu, RHEL(6,7), CoreOS, boot2dockerなどです。

使い方は簡単です。vagrant-proxyconfをインストールし、Vagrantfileに以下のようにproxyの設定をして起動するだけです。(いまvagrant-proxyconfを利用しているひとはpluginをupdateすればそのまま使えます。)

vagrant-proxyconf のinstall

vagrant-proxyconfをインストールします。

$ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$

ここでproxyが理由でインストールできない場合は。。こんな感じですね。

$ http_proxy=http://myproxy:3128/ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$

Vagrantfile

こんな感じでproxyの設定を書いてください。

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  if Vagrant.has_plugin?("vagrant-proxyconf")
    config.proxy.http     = "http://myproxy:3128/"
    config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"
  end
  # ... other stuff
end

dockerを使う

vagrant upでVagrantを起動したら、dockerを使ってみてください。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker.io pull -t 14.04 ubuntu 
Pulling repository ubuntu
ad892dd21d60: Download complete 
vagrant@vagrant-ubuntu-trusty-64:~$

http_proxyを設定すればhttpsの通信もそれを使うようです。また、no_proxyも使えると思いますので、プライベートのレポジトリがあっても大丈夫ですね。
docker/registry/registry.go
docker/registry/auth.go
The Go Programming Language Source file src/pkg/net/http/transport.go

Happy proxy life!!

Docker logo and marks usage

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2014年9月22日月曜日

Ruby Hiroba 2014に参加してきた

概要

  • 日時: 2014/9/21(日) 09:15～17:00
  • 会場: CyberAgent, Inc. SHIBUYA MARK CITY WEST 13th floor
  • ホームページ: rubyhiroba.org/2014/

全体感想

今回、初めて、Ruby関連のイベントに参加しました。 RubyKaigi2014の一連の会議ということで、Rubyコミッタのかたもいらっしゃって、 Ruby愛を感じました。(RubyKaigiでそうとうお疲れだったのだと思いますが。)

友人から地域コミュニティいったらというおすすめもらったので、 その視点でもいろいろ見ていました。 さすがに遠くて難しいですが、toRuby, guRubyの出張版でなんとなく感じがつかめました。 地域的にはtokyu.rbが家から近くて、良さそうだと思いました。 (ということで、時間があえば次回とかに参加しようかと思っています。ML登録しました)

自分の発表

他のかたのLT見てたら、自分もしてみたくなり、急遽スライド作りました。 内容がうすいものでしたが、興味をもっていただければ幸いです。 このLTのgemはgithub/otahi/pacproxyにあります。

他の発表？などの感想など

あんまりメモできていないのと、そろそろ朝ご飯作らないといけない時間なので、 すみません。。

guRuby

メタプログラミングRubyの読書会ということで、本を持っていなかったので、 電子書籍でMetaprogramming Ruby 2: Program Like the Ruby Prosを購入して臨みました。

`method_missing` のところを呼んで、irbでうってという形式で、 わからないところを共有して、という感じで一歩一歩やっていきました。

method_missingはRubyを始めた当初に出会って、混乱の窮地に陥ったことがあったので、 感慨深かったです。(rspec-dnsというgemのコードで)

toRuby

こちらはなるほどUnixプロセス ― Rubyで学ぶUnixの基礎の読書会ということで、 こちらも電子書籍で早速購入しました。

ここでは、シグナルハンドリングのところを読みながら、理解を深めていきました。

LTで話したpacproxyというのを作っているので、とても参考になるところでした。 ちゃんとしたUNIXのサービスを作るのには、きっても切れないところですね。

LTthon

多くありすぎて、ぜんぜんかけません。。

多様性のあるすばらしいLTthonだったと思います。 LTthonということで、長時間お疲れ様でした。

投稿者 時刻: 0 件のコメント:
ラベル:

2014年6月29日日曜日

hbstudy #55 「Docker勉強会」リターンズ に参加してきた

概要

  • 日時: 2014/6/27(金) 19:00～21:30
  • 会場: ハロー会議室 新宿 C+D
  • スピーカー： 中井悦司さん @enakai00

他のかたのまとめなど

感想

最近は、Dockerについて、多く情報をInputして、自分の中でイメージを構築しようとしています。(英語とかの多聴に近いかも。) そのなかで、今回の勉強会での気づきは、DockerがLXCなどの他のシステムと違うのは さまざまな既存の技術を「一連の仕組み」としているところだな ということです。

これまでのLinux上の技術を組み合わせて、 CPU、メモリ、ネットワーク、ストレージなど一括して切り出せるようにしているので、 人によって、かゆいところが違ってくるのだと思います。

また、サーバの種類によって、Dockerを使ったほうがよいか、否かがかわってくると思います。 Dockerの技術はデバイスを隠蔽しているので、直接ハードを扱いたい場合などには利用できないのと、 DBもやり方によっては、実現できるのかもしれませんが、あまりメリットが多くないのかな と思います。 なので、実際にはアプリケーションサーバなどの状態を持たないサーバをDockerで 構築するのが最初になるのかな と思いました。

ただ、自分の興味のあるネットワーク周辺については、Dockerの思想からはずれるとことがあるかもしれませんが、 いろいろ小細工していきたいな と思いました。 (今回、@enakai00 さんがネットワーク周りの操作をデモでやっていただいて、なんとなくイメージが持てました。)

内容メモ

ちょこっとしたまとめです。スライド見るとだいたい書いてあるので。。

Docker入門(Docker クイックツアー)

  • コンテナの仕組み
    • Linux上でのコンテナは、昔(といっても、そんなに昔ではない)からある技術を組み合わせ
    • ホスト側から、ひとまとまりにして、切り離せる
  • Dockerの仕組み
    • これまで実現するためには、一生懸命組み合わせないといけなかったものを簡単にできるようにしたもの
    • インターネット上のレポジトリにコンテナをイメージを置き、利用できるようにしている
    • ホスト側の環境がある程度そろっていると、コンテナの動きもかわらないようにできる
  • Docekrを動かしてみる
    • デモでいろいろ見せていただきました
      • ちゃんとFedoraの上で、CentOSのtracerouteも動きました

Docker を支える技術

  • Linuxコンテナの実態
    • namespaceを使っていろいろなリソースを分離している
    • コンテナ内部からは見えないが、ホスト側からは見える(操作できる)
    • コンテナではpid 1のプロセスが落ちると、コンテナとして落ちる
    • ネットワークのnamespeceCentOS 6.4とかだと使えない-> 6.5では入っている)
    • これまでaufs依存だったが、Device Mapper Thin-Provisioningという仕組みが入って、aufs依存しなくなった
      • Red Hatさんが作り込んだようです
    • ホスト側からは、いろいろ設定が変更できる
      • Docekrでは固定でも、そとから変更すれば変更できる
        • ただし、Dockerの思想とは反するのと、ホストによって振る舞いが違ってくることもある
投稿者 時刻: 0 件のコメント:
ラベル: ,

2014年6月23日月曜日

JTF2014に参加してきた

JTF2014に参加してきたので、メモを残します。 もうご飯作る時間になってしまったので、ここまでです。。

概要

感想

Serverspec のような「成功」を成し遂げるには他者を巻き込む

Serverspecのmizzyさんの話でしたが、とても楽しく、また、参考になりました。 (というか、参考にしてがんばります!!) 構成管理+仮想化+テスト+CIやGithubなどの環境の変化があったところに、 Serverspecがぴったりとはまったということでした。 (あと、@naoyaito さんに広めてもらうことが、日本での普及の鍵だったそうです。。) その土台には、プロダクトを「KISS」にする、他者を巻き込みやすいようにする というようなことを やり続ける ということがある。と。 たしかに、自分がコミットしたOSSは愛着がわきますね。

Serverspecとrspec-dnsにインスパイアされてLbspecというものを作っているので、 今回の話を参考にして、がんばっていきたいと思います。

docker関連

  • dockerがいま暑い

    JTF2014の中心はdockerだったように思います。 docker関連のセッションの数も多く、また、セッションには立ち見がでるほど人がきていました。 ただ、会場では「本番運用」までを期待していたものの、docker入門の部分が大きく、 ちょっと物足りなかったかかな と思います。 入門も必要なところなので、セッションごとの役割分担ができていたらよかったですね。 そもそも、本番運用までやっているところもほとんどないと思うので、自分で開拓するしかないですね。きっと。

  • dockerは「秘伝のたれ」を取り除く銀の弾丸ではない
    これまでのサーバ構築が職人の「秘伝のたれ」で構成されていることに対するカウンターとして、 dockerでコンテナ作って、CI回して・・・というのをやっているのだと思うのですが、 dockerコンテナに「秘伝のたれ」が入り込む余地はあって、 結局、ある「ゴールデンコンテナ」からの子孫を大事に守り続けることになるかもしれない という風に思いました。 ただ、hyper visor上のVMに比べたら、生成、消滅を繰り返してやれる分、 CIを速く回していけるので、思いました。

DMM.comさんはお客様にコンテンツを速く提供するためには、「なんでもする」

DMM ツチノコブログで最近情報発信を活発にされているDMM.comさんのインフラ(ネットワーク周り)の 話をお聞きすることできました。(このようにDMM.comさんが話をするのは10年ぶりだそうです。) お客様にコンテンツを速く提供するためには、「なんでもする」という話がとても印象に残りました。 「稟議も即決」「自分たちの責任でそのときのベストと思うシステムで構成する」というところが とてもかっこよかったです。 これからの情報発信にも期待です。

フロントエンドでビルドツール特にgulpが活躍

自分とはあまり関係ないところも聴いてみようと思って、このセッションを聴いたのですが、 デザインのところでもだいぶ自動化で環境が変わってきているな と思いました。

デザイナーがやるべきところに注力できるようにする ツールが進化しているというのがとてもおもしろかったです。 あとでもう一度、調べてみようと思います。

主催者、スポンサーに感謝

とても濃いセッションが多くあり、とても楽しく1日すごせました。 懇親会はでられなかったのですが、事前に申し込むと1000円以下で、 おいしい昼食と飲み物とお菓子がいただけるという。。 それだけで1000円の価値があります。。 ありがとうございました。

投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)