めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

Hatena Engineer Seminar #4 に参加してきました #hatenatech

Hatena Engineer Seminar #4 に参加してきました。今年、はてなづいているような。 複数のサービスをもっているはてなならではの話が興味があるので、機会があればまた参加したいです。

f:id:d4-1977:20150207230150j:plain

#hatenatech

開催挨拶

Goで書かれたmackerel-agentのOSS化や自動化にまつわるあれこれ

  • id: Songmu
  • mackerel

資料

オープンソースにしているもの

  • agent
  • agent-plugins

オープンにしたかったこと

  • テストをオープンにすること
  • ビルドをオープンにすること
  • リリースをオープンにすること

agent

  • Goで書かれている
  • 公開しない理由がない
  • ユーザー環境で動くものなのでソースを開示する

ユーザーがハックできる余地を残しておく

  • 例:Travis-CI の場合
  • cookbookのレシピを公開している
  • 例:github-services の場合

ソースをオープンにして第一段階

  • バッチ受け入れ体制
  • ちゃんとリポジトリを回していく必要が有る
    • 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

まとめ

  • ソースをオープンにすることで一緒にユーザーサービスを作る
  • Travis CI などの外部サービスを利用する
  • 自動化するツールもテストできるようにする

質疑応答

質問

goを使うことについて

回答

goについてのベストプラクティスが共有されていないという課題があるけれど、これからは出てくるのでは?goは、常駐プロセスに向いていると思うのでいいのでは

はてなのサービスの開発環境

  • id:astj
  • 新卒で、色んなプロジェクトを渡り歩いている

開発環境のメンテナンス

開発環境

  • サーバー起動
  • デザイナーの手元にも
  • テストコードの実行環境
  • 調査スクリプトの動作環境
  • less, TypeScriptなどの自動コンパイル

開発者向け

  • 開発者のマシン上で直接実行
  • 環境を仮想マシンの内に構築

はてなブックマーク

本番サーバー環境

あるある

  • コマンド一発で環境が立ち上がる
  • 色んなものが動かないといかない...
  • 多様な手元にある環境
  • Carton導入?
    • もうCPANにない古いモジュール
    • 本番では使わない

Vagrant

  • VMなどによる仮想環境
  • Ubuntu cloud images

Chef cookbook

  • 涙ぐましいcookbook
  • こんな感じで
$ vagrant up
$ vagrant ssh  script/bookmark start
  • 開発用サーバー + LOCAL で開発する
  • テスト用は別環境

Vagrant 導入後

  • 放置すると動かなくなる
  • aptリポジトリ提供終了
  • Perl 5.8のサポート終了
  • 本番と開発環境と別で管理するコストの増大
  • Chef のレシピは本番と共有が難しいが、本番環境と共有することにする
  • 社内rpmサーバー

他アプリケーションで試験導入

はえてなブックマークまとめ

  • 本番の環境に近づける
  • 手元マシンにを選ばない
  • 継続的なメンテナンスの必要性
  • はてなブックマークを作り直せたらいいね…話

はてなブログ

セットアップ

  • brew でインストール
  • 起動
  • /etc/hosts にこれ書いてよいのか?
  • 手元にDNSを置いている
  • 今のところうまくいっている
  • ミドルウェアbrew install で入れいているのは課題?

VM

  • VM に依存しない環境志向
  • 複雑度によってはVMによる手間の削減
    • 複雑度の完全な封じ込みは未達成

質疑応答

  • デザイナーも同じ環境を用意して制作してもらっている
  • 手元でのprovisioning

はてなブックマークの新機能における自然言語処理の活用

開発の経緯

  • トピック機能の要望は前々からあった
  • トピック生成
  • タイトルの問題

重要語抽出

  • ElasticSearch

トピック生成の流れ

  • トピック生成
  • トピックタイトルの生成

トピック生成

  • トピックとは?
  • キーワードの集合から形成
  • トピックモデル
    • PLSI
    • LDA
    • 今回は使っていない。盛り上がっている話題を捉えるもではない

ElasticSearch にひょるトピック生成

  • Significant Terms Aggregation
  • 重要語を取得できる機能

JLH

  • JLH というスコアがある
  • JLH 絶対割合変化 x 早退割合変化 絶対割合変化 = 早退割合変化 =

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html

トピックに属するエントリ

  • トピックのキーワードが含まれることが大切
  • キーワードのスコアの合計が8割以上となるエントリを取得

タイトル生成とは

  • 自然言語処理におけるタイトル生成とは要約技術の一種
  • 実際には人間でも複数記事のタイトルの要約は難しい

  • タイトルはキーワードの羅列でいい?

  • キーワードを並び替えればいい?

  • いずれかの記事の使うと上手くいく可能性が高い

  • 重要文を利用する
  • 媒体名などの不要な部分はいらない
    • 媒体名の辞書を作るのはコストが高い

重要語抽出

  • TopicSum
  • 取得したタイトルの必要な部分のみを取得
  • かかり受けに基づく文圧縮
  • 重要語を含む先頭文節から末尾の文節まで非文を避けるためヒューリスティックなルールを用意
  • 文節境界の前処理が必要「」「:」で強制的に文節境界を用意

はてなiOSアプリとSwift

Swiftでのはてなの事例

なぜShare Extension で試したか?

  • AppExtentionはアプリにもう一つアプリをハンドルする形式で分けやすい
  • 機能も小さい
  • 今後のプロジェクトでは標準的にSwfitを採用
  • Objective-C を書きたい!という人がいなくなった

SwiftObjective-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時間はきちんととる
  • 最適化レベルをデバッグ実行時に再現可能
  • 一次変数を使う
  • 再現は簡単

開発ツールがダメ

  • IDE機能がほぼ使えない
  • やたらクラッシュする
  • リフレクションがまだない

SwiftiOSアプリ構成

  • CocoaPods vs Carthage(カルタゴ
  • CocoaPods 0.36よりSwift対応
  • 過去の資産が使えるCocoaPods を使うのが無難

Alamofire vs AFNetworking

  • 美しSwiftの世界であればAlamofire

json

  • Optionalとの相性がわるい
  • Mantleがよい

スマート会

  • はてなのモバイルエンジニアチーム
  • 開発環境については大きな権限が与えられている

資料

TypeScriptで実現するMVPアーキテクチャパターン

ジャンプルーキー

  • SAP/pjax ではない
  • 投稿、閲覧は動的・対話的
  • TypeScript
  • 外部ラブラリはjQueryのみ
    • DOM操作
    • HTTP 接続など

TypeScriptの特長

型指定

ビルド

  • gulp.js を利用している
  • ローカルサーバー起動時にTypeScriptファイルを監視し、変更があれば都度コンパイル
  • 本番環境では
    • 縮小化、結合化をCIで実現

テスト

  • 主にプレゼンテーションロジックをテスト
  • DOMを触るテストはない
  • ローカル環境ではブラウザ実行
  • CI環境ではgulp-qunitで実行

JavaScriptからTypeScriptへの移行

  • 3人ぐらいで開発していた
  • 規模が大きくなるにつれ開発がつらくなる
  • 数千業があったが5行の変更で移行
    • 外部変数宣言の追加:2行
    • any型へのキャスト:2行
    • typoの修正:1行
  • 徐々に移行していった

JavaScript フレームワーク

  • AngularJS
    • 学習コストが高い
    • パフォーマンスチューニングに不向き
  • Vue.js
    • Andorid 2.xで動作しなかった
  • Lux/ React.js
    • 文献が少なかった

やりたかったこと

  • DOMに依存せずテストを書きたい
  • データーバイディング機構の独自実装は非現実

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 (@)さんが見えたりして、「はてなのイベント」っぽかったです。

f:id:d4-1977:20150125233416j:plain

よいまとめ

すごーーく丁寧にまとめていらっしゃる方がいました。

Mackerel updateと2015年の展望 @stanaka

アーキテクチャ

スクリーンキャプチャー

  • 各サーバーの状況についてグラフを重ね合わせられる
  • キャパシティープランニングに使用できる
  • オートスケールに対応
    • サーバーが増減しても履歴が残る

数字

  • 6,000エージェントを超える
  • 2,400オーガニゼーション
  • ユーザー事例
  • IDCフロンティア連携

2014.9からのupdate

エージェント安定化

  • 最新 0.14
    • メトリック再送時の調整

エージェントプラグインの充実

サービスメトリックグラフ

  • サーバーには直接紐付かない情報
  • 応答時間や、エラーレート、アクティブユーザー数の取得をしてグラフ化
    • nginx のログを fulentdに入れてログを可視化している
  • サービスメトリックの監視

通知

  • 通知先の拡充
  • 通知テストが可能に

監視条件の強化

  • 監視条件でブラックリストを指定
    • サービスA全体ただしバッチサーバーを除く
  • ファイルシステム%監視
  • 埋め込みグラフ
    • ダッシュボード on Qiita::Team
    • 外部のサービスでダッシュボードを作ることができる

SPDY対応

  • 表示速度の向上
  • spdycheck.org

Commin soon

埋め込みグラフのゲスト閲覧

  • サービスレスポンスタイムを共有

Windows 対応

URLの外部監視

  • URLに対する監視
    • レスポンスタイム
    • スタータテスコード

Alert関連API

監視と通知を柔軟に

  • 監視ルールごとに通知先を指定
    • サービスごとに
    • 重要なのは別ルート

オススメ

Mackerelを中心に考える2015年代のサービス運用環境 フリークアウトでの事例

移行前の環境

調達と実装の課題

  • 急速にサービスが立ち上がっている
  • オンプレ環境なのでキャパシティーの見極めが難しい
  • 調達リードタイムがかかる
  • クラウドに移れば半分ぐらい解決
  • クラウドを使うには考え方と仕組みを変える必要がある

変えた

  • 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連携

結果・まとめ

  • 労働集約的な仕事が減った
  • 特定のクラウドに合わせて作りこむのが減った

資料

質疑応答

  • デプロイにかかる時間は

    • 1回数十秒〜で差分の同期(rsync
  • 退役サーバーのメトリックは?

    • slackに流しているので、あとで追う時はそこで
  • インスタンスはどこから?

    • AMIから
    • インスタンスのコピーではない
    • サーバーの設定を変更するときは、新しいグループを作って切り替え
  • まかれるにあってcloudforcastにない

    • 細かいネットワークの状態の監視まわり
  • 運用は?

    • 一人で
    • 差分はpull requestで
    • 専属でやってはいない
    • インスタンスがすごい数になったら専属で人が必要なるかも
  • 手元での開発は?

    • plackで手元で開発
    • テスト環境をつくって
    • AWSで…というときは、独自で
  • ハマったことは?

    • Packer化するときは
    • 試行錯誤に時間をかけた
    • プロビジョニングツールを捨てるタイミングが難しかった
  • まかれるにたいする費用効果は?

    • 個別に田中さんと相談
    • 開発とのフィードバックが早いのと、距離感が近くてよい
  • シェルスクリプトだとスケールしたときにどうする?テストは?

    • 1ファイルが大きくなるときに問題
    • テストはserverspecでしようかと
  • Perlスクリプトを作ってPerlでのテストとかしてもいいのでは?

  • AutoScalingのときに性能の入れ替えをしている?

    • 変えてない
    • コア単価が安いのを選んでスケールしている

Docker Meetup Tokyo 第4回に参加しました #dockerjp

1月17日に「Docker Meetup Tokyo #4」に参加してきました。ここ1〜2年ぐらいで、Dockerなどのインフラに関する技術が変化してきたことをキャッチアップ出来ないでいたので、コミュニティーも含めて知りたかったので助かりました。

f:id:d4-1977:20150117233148j:plain

CoreOSの基礎/CoreOSに期待すること

資料

Docker が与えたくれたもの

  • Googleなど、インフラの選択肢を与えてくれたもの

Docker が与えてくれないもの

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の初期化

利点

  • オケーストレーション
  • etcd
  • サービスディスカバリー
  • etcd, fleet
  • 死活監視
  • fleet
  • Docker
  • cloud-config
  • PlaystatinのチームのYouTubeの動画


PlayStation: Developing Applications on CoreOS ...

運用

クラスタの構築

  • DigtalOcean, Amazon EC2, などで動作する
  • TERRAFORM
  • インフラの起動、連携
  • TERRAFORM + CoreOS
  • メンバーの増減管理を楽に

スケール

デモ

  • LBの設定の動的な書き換え
  • ELBみたいな感じ?
  • アプリけーしょんサーバー

WebアプリケーションにおけるDockerパフォーマンスチューニング

Docker Engin上でアプリケーションを動かして性能劣化しないの?

  • Docker デーモンでの話

Linux コンテナ

Linux Contaniners

  • Hypervisorのように各リソースを二重管理しなくて良い
  • コピーオーバーヘッドを少なくする実装はある
  • 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化する

  • NginxとMySQLをそれぞれDocker化
  • Nginx だけDocker 化
  • MySQL だけDocker 化
  • MySQL だけをDocker化
  • VolumeをON/OFFで変わらない

ネットワーク

  • NAPTの高速化
  • 127.0.0.1 だとDocker のチェーンにはいらない
  • ISUCONはlocalで試していた
  • なぜuserland の proxy がいるのか?
  • Portmapperが重要

Mackerel

  • Mackerel の話。鯖の押しずし

Amazon EC2 Container Service(ECS)

  • @
  • id:shot6
  • アマゾンの人
  • ソリューションアーキテクト、絶賛採用中!

ECS

  • EC2クラスタ上にDockerコンテナを起動/管理するサービス
  • Docker管理を便利にする

ECSの考えかた

  • コア部分
  • Docker ピュア環境をより生キュアに使える
  • AWSのサービスとインテグレーションする

ステータス

  • ECS自体は無料
  • アメリカのみ

ECSの仕組み

コンテナインスタンス

  • EC2、Docker、ECS agent
  • Amazon EC2 Container Service Agent

ECS agent

Cluster

  • リソースプー
  • リージョンに閉じている
  • Container Instanceのプール

Task

  • 関係するコンテナの集合
  • WordPressのコンテナとMySQLのコンテナ
  • Task Definition
  • json

ECSの良い点

  • AWSのセキュリティ機構が使える
  • 今までのノウハウを無駄にしない
  • パブリックリポジトリでも、プレイベートなリポジトリでも
  • AWSのサービスをそのまま利用できる
  • AWS + でできる

ECS command line

$ aws ecs
  1. クラスタ(cluster)を作成
  2. EC2をコンテナインスタンスとして起動
  3. Task Defintion を作成
  4. インスタンスを確認する
  5. Container Instance の状況を確認する
  6. Task Defintion を作成/登録/確認
  7. Task を走らせる(EC2のスケジューラーに任せる or 自分でしたコンテナインスタンス上に登録)

  8. clusterArm:Amazon固有の記法

  9. aman-ami-2014-09を利用
  10. マルチ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の機能とデモ、開発体制について

仕事したくない

Kubernetes

サポート

  • いろんなところで動く
  • AWSとかGoogle Computer Engineとか

3つの提供するモノ

  1. サービス
  2. レプリケーションコントローラー
  3. Pod

レプリケーションコントローラー

Pod

  • コンテナではない
  • コンテナとコンテナを合わせたもの
  • 同じインスタンスで動かしたいもの

デモ

  • 3台のマシン

Architecture

Networking

  • 同じポートを使うアプリケーションがあってもiptableを利用して自動調整してくれる
  • Googleでは、数千台で同じようなことをしている

Impression

  • テクノロジーとしては普通
  • やろうと思えばできるけれどわりと大変、というのをやってくれるのが、キュウべえ
  • バグ報告しようとしたら、わりと直ぐに直っている
  • 他のオープンソースも利用している
  • Fluentdでログ集計、SkyDNS
  • 自分で全てやろうとはしていない

Whats happening(最近見ていて気づいたこと)

  • internal DNS
  • Namespaces
  • Master as a Service
  • Bootstrap
  • Easier Setup
  • Google の公式見解ではないです

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 入門

資料

FedoraRHELCentOSの比較

  • Fedora
  • RedHatEnterpriseLinux(RHEL:レル)
  • 企業向け。サポートあり
  • CentOS

Red HatとDockerの関係

  • RHEL7 ではDockerが正式サポート
  • ただし条件あり
  • Extrasチャンネルで提供する
  • ミッションクリティカル非推奨
  • サポートが限定的
  • RHEL 7.1からは外れる予定
  • コンテナの互換性
  • ホストはRHEL 7
  • コンテナはRHEL 6以上
  • x_86のみ

Getting Started with Docker

Project Atomic とは?

Ubuntu Core の違い

Atomic Core との違い

  • ライバル
  • 標準ツールが少し違う
  • 思想が少し違う
  • Core OS 一からコンテナのために出発
  • AtomicHost:既存OSをコンテナのために最適化

RHEL と AtomicHostの違い

  • yumがない
  • OS自体はrpm-ostreeでupgrade/rollback
  • Docker, etcd, Kubermetesが標準で入る

リソース消費量を比べてみた

CentOS Atomic Host

  • CentOS
  • Docker, Kubernetes, Cockpit, Etcd, cloud-initが入っている
  • KVMで使うか、変換して使う

用意するファイル

  • ファイルを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
  • Vimerだけれど、Atomの記事がQiitaで人気

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 レジストリ

デプロイ

  • 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

kujira

まとめ

  • 自動アップデート不安定
  • 迷ったらシンプルな方

Development and Deployment with Docker at Dwango

資料

レコメンド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の導入には準備が必要
  • 監視を真剣に考える
  • @

共用スパコンシステム上でデータ解析 with Docker

  • @
  • データからの研究再現性が大切!
  • 自分ができても、他の人もできないとだめ!

資料

TBD

Docker API を GO から使う

Docker Remote API

  • KubernetesなどもDocker Remote API を使っている

Go Docker Client

Docker/ECSでIAMロールを利用する

グレデンシャル管理

GitのコミットごとにQA環境を作成するプロキシを作ってみた

$ vargrant dns —install
  • vargrant dns というプラグインがあり、名前解決する
  • Pull Request に反応してURLを貼るbot

Docker でやってみた理由

  1. 安い
  2. 速い
  3. うまい

prevs

tutumで雑に包んで雑にデプロイ

tutum

  • Dockr as a Service