Hatena Engineer Seminar #4 に参加してきました #hatenatech
Hatena Engineer Seminar #4 に参加してきました。今年、はてなづいているような。 複数のサービスをもっているはてなならではの話が興味があるので、機会があればまた参加したいです。
#hatenatech
開催挨拶
先ほど発表しましたが、はてな東京オフィスを2倍に増床します! 3月オープン予定です。エンジニアもエンジニア以外も増員していきますので、興味ある方はご連絡お待ちしています!! #hatenatech
— Shinji Tanaka (@stanaka) 2015, 2月 7
Goで書かれたmackerel-agentのOSS化や自動化にまつわるあれこれ
- id: Songmu
- mackerel
資料
オープンソースにしているもの
- agent
- agent-plugins
オープンにしたかったこと
- テストをオープンにすること
- ビルドをオープンにすること
- リリースをオープンにすること
agent
- Goで書かれている
- 公開しない理由がない
- ユーザー環境で動くものなのでソースを開示する
ユーザーがハックできる余地を残しておく
ソースをオープンにして第一段階
- バッチ受け入れ体制
- ちゃんとリポジトリを回していく必要が有る
- p-rを受け入れる
githubの理由
- contributeしてもらう体制を作りやすい
どのようにパッチを受け付け体制を整える
- 放置しない
- 公平に扱う
- CIが必要
CI
- テストが失敗したら戻せる
- CIがないとお互いパッチのクオリティを担保できない
Travis CI
- 慣れている
- gitでtagをトリガーにしてjobが走る
CI でやっていること
- ビルド可能か?
- 社内Jenkins も使っている
golintをCIする
- golint で警告が出たらエラーとして出す
- 書き方による論議を出させない
Windows 対応
- AppVeyor でCI/CD
- テスト&インストラー作成
レビュー体制
- agentは社内の人間の誰かがレビューしている
- 気がついた時にやるになっているのが課題
mackerel-agent-plugins
- リリースプロセスをオープンにする
- リリース用のpull request を自動生成
- tagを打たれたcommitに対してTravisがビルド成果をリリース
ツールをテストする
- 次のバージョンの決定
- ブランチ作成
trabisにtagをgit pushさせる
- deploy key
- github token は細かい権限設定が難しい
課題
- 社内で検証できないミドルウェアの動作確認をどうするか?
- リリースサイクル
- どこまでをコアに同梱するか
- コアのpluginとoptional
まとめ
質疑応答
質問
goを使うことについて
回答
goについてのベストプラクティスが共有されていないという課題があるけれど、これからは出てくるのでは?goは、常駐プロセスに向いていると思うのでいいのでは
はてなのサービスの開発環境
- id:astj
- 新卒で、色んなプロジェクトを渡り歩いている
開発環境のメンテナンス
- Seminar #2 ではてなブックマークの開発環境について話している
- https://speakerdeck.com/aereal/vagrant-to-chef-detukuruhatenabutukumakufalsekai-fa-huan-jing
開発環境
開発者向け
はてなブックマーク
- Vagrant による複雑/レガシーな環境の構築
- 10年経つサービス
- 関連サービス
- B!KUMA
- はてなニュース
- 一部のコードが
- Perl 5.8
- TypeScriptが一部
- gulp
- less/css
- gulp
- apache + ngix
- MySQL
- memcached などなど
本番サーバー環境
あるある
- コマンド一発で環境が立ち上がる
- 色んなものが動かないといかない...
- 多様な手元にある環境
- Carton導入?
- もうCPANにない古いモジュール
- 本番では使わない
Vagrant
Chef cookbook
- 涙ぐましいcookbook
- こんな感じで
$ vagrant up $ vagrant ssh script/bookmark start
- 開発用サーバー + LOCAL で開発する
- テスト用は別環境
Vagrant 導入後
- 放置すると動かなくなる
- aptリポジトリ提供終了
- Perl 5.8のサポート終了
- 本番と開発環境と別で管理するコストの増大
- Chef のレシピは本番と共有が難しいが、本番環境と共有することにする
- 社内rpmサーバー
他アプリケーションで試験導入
- Hatena::Antenna
- mod_perl 1
- ...
はえてなブックマークまとめ
- 本番の環境に近づける
- 手元マシンにを選ばない
- 継続的なメンテナンスの必要性
- はてなブックマークを作り直せたらいいね…話
はてなブログ
セットアップ
VM
質疑応答
- デザイナーも同じ環境を用意して制作してもらっている
- 手元でのprovisioning
はてなブックマークの新機能における自然言語処理の活用
- はてなブックマークトピックページ
- 2/5 にリリース
開発の経緯
- トピック機能の要望は前々からあった
- トピック生成
- クラスタリング精度が低い
- タイトルの問題
重要語抽出
- ElasticSearch
トピック生成の流れ
- トピック生成
- トピックタイトルの生成
トピック生成
- トピックとは?
- キーワードの集合から形成
- トピックモデル
- PLSI
- LDA
- 今回は使っていない。盛り上がっている話題を捉えるもではない
ElasticSearch にひょるトピック生成
- Significant Terms Aggregation
- 重要語を取得できる機能
JLH
- JLH というスコアがある
- JLH 絶対割合変化 x 早退割合変化 絶対割合変化 = 早退割合変化 =
トピックに属するエントリ
- トピックのキーワードが含まれることが大切
- キーワードのスコアの合計が8割以上となるエントリを取得
タイトル生成とは
- 自然言語処理におけるタイトル生成とは要約技術の一種
実際には人間でも複数記事のタイトルの要約は難しい
タイトルはキーワードの羅列でいい?
キーワードを並び替えればいい?
いずれかの記事の使うと上手くいく可能性が高い
- 重要文を利用する
- 媒体名などの不要な部分はいらない
- 媒体名の辞書を作るのはコストが高い
重要語抽出
- TopicSum
- 取得したタイトルの必要な部分のみを取得
- かかり受けに基づく文圧縮
- 重要語を含む先頭文節から末尾の文節まで非文を避けるためヒューリスティックなルールを用意
- 文節境界の前処理が必要「」「:」で強制的に文節境界を用意
はてなのiOSアプリとSwift
- id:yashigani_w
- @yashigani
Swiftでのはてなの事例
なぜShare Extension で試したか?
- AppExtentionはアプリにもう一つアプリをハンドルする形式で分けやすい
- 機能も小さい
- 今後のプロジェクトでは標準的にSwfitを採用
- Objective-C を書きたい!という人がいなくなった
Swift と Objective-C の比較
Generics
- より安全にコードを書くことができる
- Objetecive-C で防御的なコードをかくと冗長
- より柔軟なコードが書ける
関数的 Functional Programing
- map, sort, filter, など
- 言語からのサポート
Closures
- Objective-C のエンジニアはみんあBlocks大好き
- なかった時代に思いを馳せながらありがたく使う
その他
- tuplesがある
- Optionalがある
- playgroundがある
- namespace(classの中にclass/enum/structが書ける)
いけてるところ
- より厳密な静的な言語
- モダン
いけてないところもある
- 過去の資産をそのまま使えないことがある
- Cでかかれたもの
- C++ でかかれたもの
- 最適化で案外壊れる
最適化注意ポイント
- TestFlightでベーター配布したときに初めて気づく
- どう考えてもおかしいところでおちたら最適化
- QA時間はきちんととる
- 最適化レベルをデバッグ実行時に再現可能
- 一次変数を使う
- 再現は簡単
開発ツールがダメ
Swift でiOSアプリ構成
Alamofire vs AFNetworking
- 美しSwiftの世界であればAlamofire
json
- Optionalとの相性がわるい
- Mantleがよい
スマート会
- はてなのモバイルエンジニアチーム
- 開発環境については大きな権限が与えられている
資料
TypeScriptで実現するMVPアーキテクチャパターン
ジャンプルーキー
- SAP/pjax ではない
- 投稿、閲覧は動的・対話的
- TypeScript
- 外部ラブラリはjQueryのみ
- DOM操作
- HTTP 接続など
TypeScriptの特長
- 静的型付け
- 型推論
- 構造的部分
型指定
ビルド
- gulp.js を利用している
- ローカルサーバー起動時にTypeScriptファイルを監視し、変更があれば都度コンパイル
- 本番環境では
- 縮小化、結合化をCIで実現
テスト
JavaScriptからTypeScriptへの移行
- 3人ぐらいで開発していた
- 規模が大きくなるにつれ開発がつらくなる
- 数千業があったが5行の変更で移行
- 外部変数宣言の追加:2行
- any型へのキャスト:2行
- typoの修正:1行
- 徐々に移行していった
JavaScript フレームワーク
- AngularJS
- 学習コストが高い
- パフォーマンスチューニングに不向き
- Vue.js
- Andorid 2.xで動作しなかった
- Lux/ React.js
- 文献が少なかった
やりたかったこと
- DOMに依存せずテストを書きたい
- Viewとそれ以外をきっちり分離したい *既存フレームワークの採用には消極的
- データーバイディング機構の独自実装は非現実
MVPアーキテクチャパターン
- model
- View:表示の更新、ユーザー入力のPresenterへの伝達
- Presenter:プレゼンテーションロジック
MVVM
* ViewModelはViewの存在を知らない
* ViewModelの変更はデーターバイティングによって自動的にViewに反映される
MVP
* Presenterは、Viewのインターフェースを知っている
* Presenterは、自身の変更をViewに
Presenter
- 画面構成要素の位置、サイズ、内容、アニメーション
テスト
- View 自体はテストしていない
- Presenter はテストしている
- TypeScriptではない
テンプレート
- 自作のエンジン
まとめ
TypeScript
- 型の支援により安心して開発を進められる
- 本質的ではない部分に気を取られず済む
MVP アーキテクトパターン
- DOM操作とそれ以外を切り離せる
- トレンドではない
懇親会
- id: nanto_vi さんにずっと話しかけるという...
- はてなのエンジニアとデザイナー合同で勉強会をして、30分程度の発表をするという話を聞きました。それいいなあ
Mackerel Meetup #3 Tokyo #mackerelio に参加してきた
1月22日に「Mackerel Meetup #3 Tokyo #mackerelio」に参加しました。特定のサービスに関するイベントは初めてです。着いたら、id:kiyohero (@kiyohero)さんが見えたりして、「はてなのイベント」っぽかったです。
よいまとめ
すごーーく丁寧にまとめていらっしゃる方がいました。
Mackerel updateと2015年の展望 @stanaka
アーキテクチャ
スクリーンキャプチャー
- 各サーバーの状況についてグラフを重ね合わせられる
- キャパシティープランニングに使用できる
- オートスケールに対応
- サーバーが増減しても履歴が残る
数字
- 6,000エージェントを超える
- 2,400オーガニゼーション
- ユーザー事例
- IDCフロンティア連携
2014.9からのupdate
エージェント安定化
- 最新 0.14
- メトリック再送時の調整
エージェントプラグインの充実
- 0.62
- github上にある
サービスメトリックグラフ
- サーバーには直接紐付かない情報
- 応答時間や、エラーレート、アクティブユーザー数の取得をしてグラフ化
- nginx のログを fulentdに入れてログを可視化している
- サービスメトリックの監視
- 応答時間を監視するとか
通知
- 通知先の拡充
- 通知テストが可能に
監視条件の強化
- 監視条件でブラックリストを指定
- サービスA全体ただしバッチサーバーを除く
- ファイルシステム%監視
- 埋め込みグラフ
- ダッシュボード on Qiita::Team
- 外部のサービスでダッシュボードを作ることができる
SPDY対応
- 表示速度の向上
- spdycheck.org
Commin soon
埋め込みグラフのゲスト閲覧
- サービスレスポンスタイムを共有
Windows 対応
URLの外部監視
- URLに対する監視
- レスポンスタイム
- スタータテスコード
Alert関連API
監視と通知を柔軟に
- 監視ルールごとに通知先を指定
- サービスごとに
- 重要なのは別ルート
オススメ
Mackerelを中心に考える2015年代のサービス運用環境 フリークアウトでの事例
- @myfinder
- エムティーバーン
- http://mtburn.jp/aboutus.html
移行前の環境
- S3+CDN
- 箱物のロードバランサー
- オンプレ環境
調達と実装の課題
変えた
- Mackerelをサーバー管理の中心にした
- マネージドサービスの活用
- ツールオペレーションの改善
- アプリ以外は全部変えた
Mackerelをサーバー管理の中心
- サーバーリストの細かいメンテナンスが不要
- ロールで管理
- オートスケールでの履歴が残る
CloutWatchの対応
- 公式手順でカジュアル
Norikra の活用
- 分速で売り上げ、支払いをみれる
Mackerel + slack
- ケータイがアラートメールで一杯はなくなった
- 監視あるある
BigQuery
- 内部DNSもRoute53で扱えるようになったので移行
- ELB/AutoScaling
- BigQuery
- Hiveと比較して楽
- 車内に置いておく必要がない
ツール/オペレーションの改善
- ログ収集の変更
- fluentdでS3/BigQuery
Pupet廃止、Packer採用
- Packer + Shell で十分
- AutoScaling の時は、Mackerelをリタイアさせることを忘れない
- /etc/init.d 配下のスクリプトを用意している
- sleep を入れて、fluentのフラッシュに対応させている
デプロイの方法の変更
- S3を経由している
- pull型deploy
- S3から各サーバーが取得する
- CapistranoのMackerel連携
- AutoScaling で起動する際はcloud-initで取得処理
- supervisor を止めるとELBに入らない
CapistranoのMackerel連携
- 公式にある
- http://help-ja.mackerel.io/entry/advanced/capistrano-2.x
- デプロイのスケール
結果・まとめ
- 労働集約的な仕事が減った
- 特定のクラウドに合わせて作りこむのが減った
資料
質疑応答
デプロイにかかる時間は
- 1回数十秒〜で差分の同期(rsync)
退役サーバーのメトリックは?
- slackに流しているので、あとで追う時はそこで
インスタンスはどこから?
- AMIから
- インスタンスのコピーではない
- サーバーの設定を変更するときは、新しいグループを作って切り替え
まかれるにあってcloudforcastにない
- 細かいネットワークの状態の監視まわり
運用は?
- 一人で
- 差分はpull requestで
- 専属でやってはいない
- インスタンスがすごい数になったら専属で人が必要なるかも
手元での開発は?
ハマったことは?
- Packer化するときは
- 試行錯誤に時間をかけた
- プロビジョニングツールを捨てるタイミングが難しかった
まかれるにたいする費用効果は?
- 個別に田中さんと相談
- 開発とのフィードバックが早いのと、距離感が近くてよい
シェルスクリプトだとスケールしたときにどうする?テストは?
- 1ファイルが大きくなるときに問題
- テストはserverspecでしようかと
Perlでスクリプトを作ってPerlでのテストとかしてもいいのでは?
- シェルスクリプトといっても、コマンド実行が大半なので今は問題なし
AutoScalingのときに性能の入れ替えをしている?
- 変えてない
- コア単価が安いのを選んでスケールしている
Docker Meetup Tokyo 第4回に参加しました #dockerjp
1月17日に「Docker Meetup Tokyo #4」に参加してきました。ここ1〜2年ぐらいで、Dockerなどのインフラに関する技術が変化してきたことをキャッチアップ出来ないでいたので、コミュニティーも含めて知りたかったので助かりました。
CoreOSの基礎/CoreOSに期待すること
資料
Docker が与えたくれたもの
- Googleなど、インフラの選択肢を与えてくれたもの
Docker が与えてくれないもの
- オーケストレーション
- サービスディスカバリー
- スケジューリング
- デプロイ
- 死活監視
- Dockrホストの統一
- DevとProductionは同じ?
CoreOS 特徴
- minimal
- RAMの使用量は114MB
- 機能をそぎ落とし
- Update System
- 安全かつ容易なOSアップデート機能
- 設定値etcd
- Chefとかも使わなくていい?
- Clustering
- Data Center as a Computer
CoreOS 技術
- etcd
- 分散キーバリューストア
$ etcdctl
fleet
- 分散 init system
- Docker コンテナのスケジューリング、デプロイ
- Docker コンテナの状態を監視する
- systemdのUnitファイルの拡張
xfleet
cloud-config
- CoreOSの初期化
利点
PlayStation: Developing Applications on CoreOS ...
運用
クラスタの構築
- DigtalOcean, Amazon EC2, などで動作する
- TERRAFORM
- インフラの起動、連携
- TERRAFORM + CoreOS
- メンバーの増減管理を楽に
スケール
- ディスカバリーサービス
- confd
デモ
- LBの設定の動的な書き換え
- ELBみたいな感じ?
- アプリけーしょんサーバー
WebアプリケーションにおけるDockerパフォーマンスチューニング
Docker Engin上でアプリケーションを動かして性能劣化しないの?
- Docker デーモンでの話
Linux コンテナ
Linux Contaniners
UNION Filesystem
- Write I/O 最上層まで
- Read I/O 深いところまで
- Docker では UNION Filesystem を選択できる
- Storage drivers
- Device Mapper
Volume
- コンテナ間でディレクトリーを共有するためのもの
- I/O要求が UNION Filesystem を通らない
Dcoker Network
- Portmapper
- コンテナ間での通信や、コンテナ・ホスト間通信
HOST Networking
- docker run するときに使う
Docker のパフォーマンスにおいて重要なことはなにか?
ISUCON
- ISUCON のアプリ
- ISUCON 4 の予選
- m3.xlarge
Dcoker化する
ネットワーク
- NAPTの高速化
- 127.0.0.1 だとDocker のチェーンにはいらない
- ISUCONはlocalで試していた
- なぜuserland の proxy がいるのか?
- Portmapperが重要
Mackerel
- Mackerel の話。鯖の押しずし
Amazon EC2 Container Service(ECS)
ECS
- EC2クラスタ上にDockerコンテナを起動/管理するサービス
- Docker管理を便利にする
ECSの考えかた
- コア部分
- Docker ピュア環境をより生キュアに使える
- AWSのサービスとインテグレーションする
ステータス
- ECS自体は無料
- アメリカのみ
ECSの仕組み
コンテナインスタンス
- EC2、Docker、ECS agent
- Amazon EC2 Container Service Agent
ECS agent
- オープンソース
- Go言語で
- Docker Hubにも登録されている
Cluster
- リソースプール
- リージョンに閉じている
- Container Instanceのプール
Task
ECSの良い点
ECS command line
- シンプルなコマンドライン
$ aws ecs
- クラスタ(cluster)を作成
- EC2をコンテナインスタンスとして起動
- Task Defintion を作成
- インスタンスを確認する
- Container Instance の状況を確認する
- Task Defintion を作成/登録/確認
Task を走らせる(EC2のスケジューラーに任せる or 自分でしたコンテナインスタンス上に登録)
clusterArm:Amazon固有の記法
- aman-ami-2014-09を利用
- マルチAZにあるのも利用可能
スケジューラーの拡張
- 現状のECSでは
- ECSは各コンテナの状態管理
Taskを取り除く
- AutoScale との連携は、まだ
ECSの用途
- Dev & test
- Auto deployment
- Microservices
- Batch processing
- 社内 PassS/Sass の提供
今後の予定
- パートナーAMI
- CloudFormationでECS用コンテナインスタンス起動が稼働
- ELBインテグレーション
- CloudWatch
まとめ
- EC2上でDockerコンテナを運用するため
- コア部分はピュなDocker
- プレビューは試せる。24時間ぐらいで返信あり
Kubernetesの機能とデモ、開発体制について
仕事したくない
- サーバーの設定をしたくない
- 色々うまくやってほしい
- オーケストレーション
- サービスディスカバリー
- スケジューリング
- ロードバランサー
- Fail Over / レプリケーション これらのことを Kubernetes で管理する
Kubernetes
サポート
3つの提供するモノ
- サービス
- レプリケーションコントローラー
- Pod
レプリケーションコントローラー
Pod
- コンテナではない
- コンテナとコンテナを合わせたもの
- 同じインスタンスで動かしたいもの
デモ
- 3台のマシン
Architecture
- NAPT
- iptables
Networking
- 同じポートを使うアプリケーションがあってもiptableを利用して自動調整してくれる
- Googleでは、数千台で同じようなことをしている
Impression
- テクノロジーとしては普通
- やろうと思えばできるけれどわりと大変、というのをやってくれるのが、キュウべえ
- バグ報告しようとしたら、わりと直ぐに直っている
- 他のオープンソースも利用している
- Fluentdでログ集計、SkyDNS
- 自分で全てやろうとはしていない
Whats happening(最近見ていて気づいたこと)
cgroupによるリソース隔離入門
資料
Cgroup
- Cgroup を使って Docker コンテナの管理
- プロセス(タスク)をグループ化
- グループ内のプロセスに対してまとめてリソース制限
- プロセス稼働中でも制限は可能
- http://gihyo.jp/admin/serial/01/linux_containers
- Docker から直接指定できる
- CPUなどに限られる
- Docker のグループを見つけたkら直接指定することができる!
- cgroup の知識が必要
- systemd配下でdockerが動いている場合
- cgropuの管理はsystemd経由
- docker で指定
- cgroupfs で指定
- systemd で….
Docker on RHEL & Project Atomic 入門
資料
Fedora、RHEL、CentOSの比較
Red HatとDockerの関係
- RHEL7 ではDockerが正式サポート
- ただし条件あり
- Extrasチャンネルで提供する
- ミッションクリティカル非推奨
- サポートが限定的
- RHEL 7.1からは外れる予定
- コンテナの互換性
- ホストはRHEL 7
- コンテナはRHEL 6以上
- x_86のみ
Getting Started with Docker
- CentOS 7 でも基本同じ
Project Atomic とは?
- CoreOSのライバル
- 小さなOS、コンテナ向けのOS
- Fedora Atomic
- RedHat Enterprise Linux Atomic Host
- CentOS Atomic Host
- Cent OS から作っている
Ubuntu Core の違い
- Ubuntu Core
- Atomic Core
Atomic Core との違い
- ライバル
- 標準ツールが少し違う
- 思想が少し違う
- Core OS 一からコンテナのために出発
- AtomicHost:既存OSをコンテナのために最適化
RHEL と AtomicHostの違い
リソース消費量を比べてみた
- ホスト:VirtualBox 4.3.20、VMware Fusion 7.1.0
- boot2docker
CentOS Atomic Host
用意するファイル
- ファイルをisoにする
- init.isoを起動時にcloud-init
Vargrant で CentOS Atomic
ログの追跡
デモ
まとめ
- Atomic Hostはコンテナ向けOS
- Docker, Kubernetes, Etcdが標準で入っている
- Cocpit
- 平文のパスワードを送るのがイヤ
- RHAL Atomic Hostと、CentOS Atomic Host は別
Docker at Wantedly
Wantedly について
- 15万ユーザー
- 5,000社
- 30人ぐらいの会社
2011〜2014夏 Heroku
- web
- worker
- スケージュール
- On-Off
他はAWS
- Search
- DataBase
- Strageなど
- Chefで管理
Saas
- NewRelic
- DNSsimple
git
- GithubFlow
Heroku
- デプロイ速い(2分)
- スケール速い(1分)
- Dynoの操作簡単
- 東京リージョンない
2014年夏
検討
- Elasitc Beanstalk
- Chef with Docker
など
結果
- Capistrano3
- Chef
- Packer
Docker レジストリ
- Private Registry(S3)
- Capstranoで スタティックオーケストレーション
デプロイ
- Dcokerfileでビルド
- Ningx で新旧コンテナ切り替え
Datadogでモニタリング
Logentries gem で ログ収集
Dcokerfileそのまま使おう
- Chef + Packer でビルド
- キャッシュほしい
- 必要なツールが多い
- Dockerfileで書くのは辛い複雑なアプリケーション
- おそらくコンテナに向かない
- VM向きかも
- 小さいアプリケーション向きなんだと思う
- シンプルさを保つための制約を受け入れる
Dcokerホスト
- 軽量に保とう
- ホストはAMI焼いている
- なにか変えたい
- ホストにいろいろ入れていると単純に管理台数倍増
herokuから学ぼう
- on-offコンテナという使い方
- 設定は環境変数で渡す
- コンテナを乗せる基盤に必要なもの
そのほか
- 1コンテナ1プロセス
- ログはstdout/stderrへ
- モニタリング・ログ収集は専用コンテナ
- restartオプション使う
- できるだけ全てコンテナでやる
- Private Registry オススメしない
2015冬
- CoreOS導入
- capstranoは台数が増えると重い
nginx-image-server
- WebP対応画像サーバー
- コンテナのテスト
- https://github.com/wantedly/nginx-image-server
- http://cloudrop.jp/labs/nginx_image_filter
- werckerからテストしている
- Serverspecでテストすることを検討している
kujira
- kujira(社内ツール)
- etcd/fleet をベースとしたオーケストレーションツール
- railsとsinatraの様な関係
まとめ
- 自動アップデート不安定
- 迷ったらシンプルな方
Development and Deployment with Docker at Dwango
- [twiter:@ixixi]
- ドワンゴ
資料
レコメンドAPI
- cassndra
- 実際の環境で確認したい!
- pull request したらすぐに動いているので確認できる
- jenkns の pull request builder を利用
- Chefを後からDockerにするのは大変
- 既存のプロダクトは大変
- Deploy
- Capstrano
Google Container Engineについて
GCA update
- Google Container Engine はコンテナ
- GKE
- 商用版のキュウべえ
- アルファ版だけれど、今後はGoogleのLBに入る
- fluentd + kubernetes
- ログの機能の比較資料がGoogleにある
- Google Cloud Logingサービス
- Big Queryなどの連携を予定している
- ログコレクターとしてfluentd
Datadog
- Datadog のほったさん
コンテナの状況の把握
- コンテナの状況の把握ができているか?
- Docker Use Cases
- 今まで以上に短いサイクルで動き続ける部品群
- Docker ののインスタンス
- CPUの計算力を中心としたmの
- 平均5つコンテナ/Docker
- 導入の初期では?
- visibilty
モニタリング
- モニタリングの仕組みは最初から必要
- cgroup
- cAdvisor
- Dockerレイヤーから抜いている
- Memoy cpu I/O Network
- run & stopped
- 自作:cAdvisor, InfluxDB, Grafana
- プロプラ:sFlow, Datadog
- Dockrの導入には準備が必要
- 監視を真剣に考える
- @takus
共用スパコンシステム上でデータ解析 with Docker
- @iNut
- データからの研究再現性が大切!
- 自分ができても、他の人もできないとだめ!
資料
TBD
Docker API を GO から使う
Docker Remote API
- KubernetesなどもDocker Remote API を使っている
Go Docker Client
Docker/ECSでIAMロールを利用する
グレデンシャル管理
- http://dev.classmethod.jp/cloud/creds-design-pattern-in-docker/
- 環境変数に確保するのが多いけれど...
- AWS:IAMロール
- GCE:Service Account
- http://qiita.com/j3tm0t0/items/b63d456cafd20b1624fd
GitのコミットごとにQA環境を作成するプロキシを作ってみた
$ vargrant dns —install
Docker でやってみた理由
- 安い
- 速い
- うまい
prevs
- https://prevs.io/
- 2月にベーター版を公開
tutumで雑に包んで雑にデプロイ
tutum
- Dockr as a Service