PhpStormと僕

日々周りを巻き込むことをモットーに。気まぐれでJetBrains製のIDEネタとか書いてます。

株式会社アクトキャットの取締役に就任しました

長らく更新止めちゃってましたが久しぶりの近況報告です。

7/1付で株式会社アクトキャットの取締役に就任いたしました。

私自身はSideCI自体は最初期のユーザとして利用していたんですが、IVS CTO Night的なイベントで代表の角と知り合うキッカケがあり、 エンジニアに対する文化や組織へ内側から強くコミットメントできるような仕事をしたい、そういったサービスに携わりたいという思いが強くあったため去年の10月に正社員としてJOINしていました。

入社してからはSideCIの対応言語の拡充や正式サービス化、アーキテクチャ刷新などに携わってきました。

エンジニア界隈で話しているとよく「SideCIって静的解析 as a Serviceみたいなものでしょ?」みたいに言っていただくことがあります。

現状はまだその域を脱せていない部分も多いですが、私たちは「エンジニアをエンパワーメントすることで生産性を上げる」、SideCIは「コードレビューの自動化」をミッションとして掲げています。

「静的解析では検出できないようなセマンティックなコードレビューの領域」や「そもそもコードレビューがまだまだ文化と浸透していないようなチーム、個人」に対しても開発の効率化を支援できるようなアプローチも今後はやっていければと思っています。

最近は採用活動にもかなり力を入れており、おかげ様でフルタイムやアルバイトメンバー、入社予定メンバー含めて類稀なほど優秀なメンバーが集まり始めています。

こんな働き方にご興味ある方ぜひお声がけください!とりあえず飯/日本酒でもというお誘いも歓迎です!

http://www.actcat.co.jp/jobs

今後ともどうぞよろしくお願い致します!!

IntelliJ IDEAのSplash Screenを集めてみた

IntelliJ IDEAの15 EAP使い始めてスプラッシュスクリーンかっこいいなーと思って、 ふと思いついたので過去のバージョンのも集めてみた。

下に行くほど新しいバージョンのやつ。バージョン9以降はUltimate EditionとCommunity Editionあるけど、とりあえずごちゃまぜで。

色々探しまわったけどバージョン4以前のはどうしても見当たらず・・・。

バージョン12辺りから急に洗練され始めた感。 最近のバージョンのスプラッシュスクリーンはEAPと製品版でも違ったりと凝ってるのでおもしろい。

f:id:rinrin900:20051119033542j:plain f:id:rinrin900:20150814121631g:plain f:id:rinrin900:20150814121632p:plain f:id:rinrin900:20150814121635p:plain f:id:rinrin900:20150814121637j:plain f:id:rinrin900:20150814121638j:plain f:id:rinrin900:20150814121639j:plain f:id:rinrin900:20150814121640j:plain f:id:rinrin900:20150814121641p:plain f:id:rinrin900:20150814121642p:plain f:id:rinrin900:20150814121644p:plain f:id:rinrin900:20150814121645p:plain

Scalaコップ本メモ

そんなわけで最近Scalaを書き始めているわけですが、1ヶ月ほど前に今更ながらScalaスケーラブルプログラミング(通称コップ本)読んだので、その過程のメモ書きをまとめてみます。

ちなみに全部じゃなくて17章まで読みました。

実際書き始めてみると全然理解しきれてないところも多いのでもう一周読みなおそう・・・

Scalaスケーラブルプログラミング第2版

Scalaスケーラブルプログラミング第2版

コップ本メモ

  • Scalaは、配列から式に至るまで、あらゆるものがメソッドを持つオブジェクトだとすることによって、概念を単純化している(P62)

  • メソッドは副作用を持っていてはならない」というのは、関数型プログラミングの考え方の大きな特徴である。メソッドの作用は、計算して値を返すことだけでなければならない。このアプローチをとると、メソッドが入り組んだものにならないため、信頼性が上がり、再利用しやすくなる。(P63)

  • (関数型スタイルに慣れる)第一歩は、コードに現れる2つのスタイルの違いを理解することである。簡単な見分け方が1つある。コードにvarが含まれていたら、それはおそらく命令形のスタイルで書かれている。コードにvarが含まれていなければ、つまりvalだけが使われていれば、それはたぶん関数型のスタイルで書かれている。だから、関数型のスタイルに近づくための1角方法は、varを使わずにプログラムを書く努力をすることだ。(P72)

  • 関数が副作用を持つかどうかを簡単に見分けるには、結果がたがUnitかどうかを見ればよい。Unitとなっていれば副作用がある。Unitという結果がたは関数が意味のある値を返さないことを意味する。(P73)

  • Scalaは、toStringやHashSetといったキャメルケースの識別子を使うというJavaの習慣に従っている。アンダースコアは識別子の中で使ってよいことになっているが、Javaとの一貫性を保つため、またScalaコードではアンダースコアが識別子以外の目的でよく使われているため、Scalaプログラムの識別子にはあまりアンダースコアを使わない。(P121)

  • Scalaでは定数という単語はvalを意味するわけではない。valは初期化された後は一定だが、それでも変数と呼ばれる。たとえば、メソッドのパラメーターはvalだが、メソッドが呼び出されるたびに、これらのvalは異なる値を保持して良い。(P121)

  • valを使うチャンスを探そう。valはコードを読みやすく、リファクタリングしやすいものにしてくれる。(P129)

  • 一般に、varを避けるのと同じように、whileループも避けることをお勧めする。実際、whileループとvarはセットになっていることが多い。コードの中のwhileループには、疑いの目を向けてみるべきだ。whileやdo-whileを使う正当な理由が説明できないときは、これらを使わない方法を探してみよう (P131)

  • files <- filesHere というような構文はジェネレーター(generator)と呼ばれ、filesHereからの要素に対する反復処理に使う (P132)

    • はじめて呼び方出てきた
  • breakやcontinueを使わずにプログラムを書く方法はいくらもある。そして、関数リテラルを利用すれば、元のコードよりも短いコードが書けることが多い。もっとも簡単な解決方法は、すべてのcontinueをifに、すべてのbreakをBoolean変数に置き換えることだ。 (P141)

  • Scalaのスコープ規則はJavaのものとほとんど同じだということが分かるだろう。JavaScalaの違いは、Scalaでは入れ子になったスコープで同じ名前の変数を定義できることである。 (P143)

  • ScalaJavaの違いとして注意すべきなのは、Javaでは、外側のスコープ変数と同じ名前を持つ変数を内側のスコープでは作れないことである。Scalaプログラムでは、外側の変数は内側のスコープでは見えなくなるので、内側の変数は同じ名前の外側の変数をシャドウイング(shadow)するということができる。(中略)通常は、外側の変数をシャドウイングするよりも、新しい意味のある変数名を選んだほうがよい (P145)

  • 部分適用された関数とは、関数が必要とするすべての引数を渡していない関数呼び出し式である。必要な引数を一部または全く渡していないのである。部分適用関数式を作るにはメソッド名のうしろにアンダースコア書く。 (P157)

  • 最後の処理として自分を呼び出す再帰関数を末尾再帰(tail recursion)と呼ぶ。Scalaコンパイラーは、末尾再帰を検知したら、パラメーターを新しい値に更新した後、再帰呼び出しを関数の冒頭にジャンプするコードに書き換える。解が末尾再帰になっていれば、実行時に余分なオーバーヘッドがかかったりはしない (P167)

  • パラメーターなしメソッドは、Scalaでは頻繁に見られるものだ。それとは対照的に、 def height(): Int のように、空括弧付きで定義されているメソッドは、空括弧メソッドと呼ぶ。パラメーターがなく、ミュータブルな状態へのアクセスがオブジェクトのフィールドの読み出しだけなら、パラメーターなしメソッドを使うべきだとされている(特にミュータブルな状態を書き換えないことが大切)。この方法は、「属性をフィールドとメソッドのどちらで実装するかによってクライアントコードが影響を受けてはならない」という統一形式アクセスの原則に従っている。 (P184)

  • 原則として、Scalaの関数呼び出しでは、全ての空括弧を省略できる。しかし、呼び出されるメソッドがレシーバーオブジェクトのプロパティ以上のものを表す場合は、空括弧を書くほうが良いとされている。たとえば、メソッドがI/Oを実行したり、再代入できる変数(var)に書き込みを行ったり、ミュータブルなオブジェクトを直接または間接的に使って、レシーバーのフィールド以外のvarを読み出したりする場合には、空括弧を付けるようにすべきである。 (P185)

  • 合成と継承は、既存の他クラスから新しいクラスを定義するための2種類の方法である。主としてコードの再利用を追求する場合には、一般に継承よりも合成を選んだほうがよい。継承は脆弱な基底クラス問題を抱えており、スーパークラスを書き換えると、サブクラスが利用できなくなることがある。 (P196)

  • 配列の ++ 操作は、2つの配列を連結する(P197)

  • case修飾子が付けられたクラスをケースクラスと呼ぶ。この修飾子を使うと、Scalaコンパイラーはこのクラスの構文に適切な変更を加えるようになる。第1にコンパイラーはクラスと同じ名前のファクトリーメソッドを追加する。そのため、Varオブジェクトを作るのに、 new Var("x") と書く代わりに、少し簡潔に Var("x") と書くこともできる。第2にコンパイラーは、ケースクラスのパラメータリスト内の全てのパラメーターに暗黙のうちにvalプレフィックスをつける。そのため、パラメーターはフィールドとして管理される。第3に、コンパイラーがクラスにtoString, hashCode, equalsメソッドの「自然な」実装を追加してくれる。最後に、コンパイラーは変更を加えたcopyを作成するために、クラスにcopyメソッドを追加する。このメソッドは、1つか2つの属性が異なるだけでほぼ同じクラスのインスタンスを新たに作成する場合に便利だ。

  • headやtailはともに一定の時間で実行されるが、initとlastはリスト全体をたどらないと結果値を計算できないので、リストの長さに比例する計算時間を要する。データ構造を設計するときには、リストの末尾ではなく、先頭にアクセスして操作できるようにするとよい。(P297)

写経しながらメモってたやつ

  • Scala Worksheetが便利。IntelliJ IDEAから立ち上げられる。RubyのPry的な感じでガンガン使ってる。

  • 再帰構造の基本形

def approximage(guess: Double): Double =
  if (isGoodEnough(guess)) guess
  else approximage(improve(guess))
  • カリー化を使うことによってクライアントプログラマーが中括弧の間に関数リテラルを書き込めるようにできる
withPrintWriter(
  new File("data.txt"),
  writer => writer.println(new java.util.Date)
)

val file = new File("date.txt")
withPrintWriter(file) { writer => writer.println(new java.util.Date) 

株式会社nanapiを退職しました。

個人的な近況報告です。 7月下旬を持って株式会社nanapiを退職しました。

2013年1月に4人目のエンジニアとして入社したので約2年半ほど在籍してたことになります。

在職中は色んなところに手を出していて主に

・・・とか、大企業ではあまり経験できないようなスピード感の中いろんな業務を経験させて頂きました。今年からはリードエンジニアという立場でチームや組織を俯瞰して見ることが増えて、様々な面で成長出来たなーと実感出来る日々でした。

辞める理由は大きくネガティブな理由はなく、自分の技術的な興味の移り変わりが大きな理由です。優秀な同僚が多く、切磋琢磨し合える環境で働くことができたのはとても感謝しています。

エンジニアの採用サイトがリニューアルしていたので、せっかくなので貼っておきます。 辞めた身でこういうこと言うのも変な話ですが、nanapiはエンジニア以外の人のマネージャ・経営層も技術に対して理解があるので、新しいことにチャレンジし続けたい人にはとても働きやすい環境なんじゃないかなあと思います。

ちなみにあまり表に出てなかったですが、1年ごとに5万円までデバイス端末を購入補助される制度とか、入社時に2万円までPC周辺機器を自由に購入できる制度とかもあったりします。

recruit.nanapi.co.jp

次はフリークアウトで働きます。Scalaを書くのでPhpStormRubyMineも使わなくなりますが、引き続きがんばります。(もちろんIntelliJ IDEAは使う予定)

Wishlist貼っておきます。

http://www.amazon.co.jp/registry/wishlist/2NSGRH85BZA7E

IVS CTO Night & Day 2015 Spring powered by AWS Staff Report

M1100033.JPG

これはなに?

6月10日〜12日で宮崎のシーガイアで開催された IVS CTO Night & Day 2015 Spring powered by AWSAmazonさんと一緒にスタッフとして参加してきました。

スタッフという形ですが、発表やアンカンファレンスはほぼ全て見ることができました。めちゃくちゃ濃くて、そして心身共に疲れ果てた3日間でした。

同じようにスタッフ枠という形での参加があるかどうかわからないですが、今後同じような枠を頂いたときにエントリする人に「スタッフがどんなことするのか?」「IVS CTO Nightってどんな雰囲気なのか?」を触りだけでも伝えるということがこのレポートの目的です。

なお、具体的にどんな内容の発表があったかなどはAWSソリューションアーキテクトの篠原さんの以下のブログが参考になります。

【開催報告】IVS CTO Night & Day 2015 Spring powered by AWS

スタッフとしての仕事

Amazonさんが9名と、外部スタッフ(自分たち)が3名の合計12名。 基本的な大枠の進行やMCはAmazonさんが持っていたので、自分たち外部スタッフ3名で以下を分担しました。

  • 受付関連
  • LT/各発表のタイムキーパー
  • LT/各発表のモニタ接続確認
  • 会場移動時の誘導
  • ビデオ撮影

開催がまだ2回目ということもあり体系だった形になっていないので、状況を見て臨機応変に動きまわることが大事だなーという感じでした。

いろんなパネルを固定したり、会場設営したり、マイク回したり、後片付けしたりetc... みたいな細々したことをやってました。

(余談ですが、2日目は一日中立ちっぱなしだったのでエンジニアになって始めて足が棒になる感覚を味わいました。感無量。)

3日間の流れ

初日は基本的にウェルカムパーティなので受付及び入り口の確認がメイン。稀にIVS(CTO Nightじゃない方)の方が間違って会場来てしまうことがあるので常に出入口を見ている感じ。

二日目は朝8時〜受付とかモーニングセッション準備とか。 基調講演とメインセッションが10時〜で60分くらいの登壇が4本くらい。 夕方からはアンカンファレンス形式で複数あるテーマのうち、自分が議論したいテーマごとに分かれてテーブルで話し合う形式。 19時半くらいからはCTO Nightパーティ二日目。22時くらいに解散。

三日目は朝8時半〜IVSのメインイベント(多分)のLaunchPad。 誰か一人常に受付にいる必要があるが、基本的にはローテーションで会場内の発表に注視。

11時〜午前中いっぱいTechPitchという形式の、CTOによる技術LT。 午後は各テーマごとのパネルディスカッション*4つ。 最終日は18時半〜CTO Nightパーティ三日目。最終日だけ会場が別で、受付に人が要らないので自分たちも混ざって他のCTOと少し話した。

印象に残っていること

スピード感

kobito.1435137746.688501.png

面白いなと思って一番印象に残っているのが2日目のアンカンファレンスの「エンジニアの交換留学」について。 元ネタは今年の4月に行われていたpixivさんとドリコムさんの社会人交換留学について。

このテーマの元にどう思うか、自分たちの会社だったらどうか、という話が繰り広げられていた。 かなりポジティブに話が進んでいたらしく、具体的にそのアンカンファレンスの参加者の数社で交換留学をやってみよう、 という結論を1時間の中で出して、具体的なタスク化まで落としこんでいた。

コードを書き続けている人が多い

CTOが約100名と言っても会社規模はバラバラで、エンジニアは自分ひとりという会社もあったりするのでコードを書いているのは当たり前な部分もあるが、上場企業とかエンジニア規模百人以上の企業のCTOでも今でも日常的に(そして業務外で)コードを書き続けている人が多くとても刺激になった。

最近なんだかんだ言いつつ本とか(あとゲームとか)ばっかでコードから離れ気味になっている自分への戒めになった。

CTOは超パワフル

一部のCTOを中心に夜二次会、三次会〜に行って、朝4時くらいまでカラオケした後帰ってきて、その後朝8時半のLaunchPadには普通に参加しててすごかった。

食べ物が豪華

宮崎牛のローストビーフとかステーキとか食べた。

まとめ

とにかく刺激の連続なので、特に現場のエンジニアこそ機会があれば是が非にでも参加すべき、というのが個人的結論でした。 刺激だけじゃなく、CTOが感じていること・考えていることの高さまで強制的に目線を上げることができる3日間なので、コードを書いている以上に得られるものはとても多いと思う。 (1日中気を張っているからめちゃくちゃ疲れるけど!)

現場からは以上です。

2015初夏のKindle散財メモ

初夏というよりもはやもはや真夏の暑さだけど。 Kindleで50%オフ、というか厳密には50%ポイント還元してたので久しぶりに散財した。 最近もっぱらオーディオブックばっかりであまり紙の本とか電子書籍読む習慣がなくなってるので暫く積ん読になりそうではある。

組織パターン

組織パターン

Effective Ruby

Effective Ruby

AWK実践入門

AWK実践入門

The DevOps 逆転だ!究極の継続的デリバリー

The DevOps 逆転だ!究極の継続的デリバリー

ヒストリエ(1)

ヒストリエ(1)

ヒストリエ(2)

ヒストリエ(2)

ヒストリエ(3)

ヒストリエ(3)

ヒストリエ(4)

ヒストリエ(4)

ヒストリエ(5)

ヒストリエ(5)

ヒストリエ(6)

ヒストリエ(6)

ヒストリエ(7)

ヒストリエ(7)

ヒストリエ(8)

ヒストリエ(8)

ヒストリエ(9)

ヒストリエ(9)

CoreOS Meetup Tokyo #1 に参加してきた #coreosjp

参加してきたので個人的メモをまとめました。 k8sは自分で触ってなくて、調べながら聞いてたのでほとんどメモ取ってません。 最後に個人的な所感をまとめてます。

Opening & Overview of CoreOS (@deeeet)

speakerdeck.com

CoreOSとは

Motivation

  • インターネットのセキュリティを根本的に改善したい
    • 常にソフトウェアをupdateを出来る仕組みを持つOS

特徴

  • Minimal(シンプル)
    • No package manager
    • No language runtime
  • Update System
    • Omaha(OS自身のBlue-Green Deployment)
  • Container
  • Clustering
    • Data Center as a Computer

提供している機能

  • etcd
    • 分散型KVS
  • fleet(flt)
    • 分散initシステム
    • etcdで作ったクラスタに対してスケジューラ的に
  • Rocket(rkt)
    • AppC runtime
  • flannel
    • kubernetes

Latest News

  • TECHTONIC
    • CoreOS Stack + Kubernetes
    • 商用パッケージ

CoreOS/Rocket (@mopemope)

www.slideshare.net

rktとは?

  • Application Containerを動かすためのもの
  • 2つのコンポーネントを持つ
    • Application Container Executor(ACE)
    • Metadata Service
      • コンテナ外にCredential情報を置く仕組み

キーワード

  • App Container Image
  • App Container Image Discovery
    • イメージを配信するための仕組み
  • App Container Pod
    • Containerをひとまとめにする仕組み
    • まとめて配信
  • App Container Executor
 - Runtime

Manifest

  • jsonで持つ
  • pod manifestも同様

Dockerとの違い

Composable

  • no central daemon
  • docker formatではなく共通formatでupload/download

Security

  • イメージを暗号化、認証

Image distribution

rktでできること

  • Application Container Imageをダウンロード
    • Docker imageもDL化
  • セキュリティ証明書
  • コンテやなPodを立ち上げる
  • 動いているコンテナの中に入れる(Docker exec的な)
  • Private network
    • private(NAT)
    • bridge
    • macvlan
  • Metadata Service

CoreOS OEM on NIFTY Cloud (@higebu)

www.slideshare.net

  • 爬虫類大好き

CoreOS OEMとは

  • CoreOSをいろんなプラットフォームで動かせる仕組み
  • Nifty Cloud
    • Community-Supported Platformsの中

      CoreOSのOEMをするには

  • 自身のプラットフォームで動くイメージを作成するための修正をPRしてMergeしてもらう
  • ドキュメントを書いてPRしてMergeしてもらう

OpenShift v3 でDockerのPaaSを作る話 (@jacopen)

www.slideshare.net

OpenShiftの機能

  • Kubeternetes
    • 適した場所へコンテナを配備(スケジューリング)
    • Docker image指定してのデプロイ
  • Multi Tenant
  • source-to-image
    • githubのURLからdocker buildしてregistryに送る→kubernetesが配備
  • Request Routing
    • HAProxy
  • Trigger

まとめ

  • OpenShift3=Docker+Kubernetes+PaaSの機能
  • PaaSとしてはまだまだ未完成
    • 現時点ではβ
    • 正式リリースは2015夏くらい?

OpenShiftの構成

  • docker
  • kubernetes
  • PROJECT ATOMIC
    • 今回CoreOSで動かした

CoreOS運用の所感 (@spesnova)

speakerdeck.com

  • CoreOS on EC2
  • 画像リサイズのホストに使っている
  • &ElasticSearch

デプロイ

  • ELB配下でBlue-Green

ログ

  • logentries
  • systemdのjournalを全部送る

モニタリング

  • Datadogを全台に

etcd / fleet

  • 全部使っていない
  • ダイナミックオーケストレーション
    • リソースマネジメントは?
  • 使っていなくてもメリットはある
    • ホストマシン構築タスクはほぼない
    • AMI焼く必要すらない
    • コンテナとホストの分離が楽

自動アップデート

  • 今はオフ
    • 今は手動アップデート
  • locksmith(依存でetcd)が必要
    • etcdの安定運用が前提条件

遭遇した問題

  • CoreOSがEC2でクラッシュ

CoreOS channel選び

  • alphaは品質的にalphaではない
    • アップデートの頻度を表している
    • ただしalphaは致命的なアップデートもくる

やりたいこと

  • Opsボトルネックでスピード感落としたくない
    • セルフサービス化で対応
      • DevがDockerfileを書く、イメージをビルド
      • Devがコンテナをデプロイ
    • Dev, Opsをいい意味で分離
      • Opsはプラットフォーム側を
      • Devはコンテナ内部に責務を持つ

まとめ

  • etcd, fleetオフでもメリットある
  • もちろんバグもある
  • Ops behind the APIにチャレンジ

Docker + Checkpoint/Restore (@kawamuray)

  • Checkpoint/Restore(CRIU)を用いてコンテナの起動を高速化

Checkpoint/Restore(CRIU)

  • VMのスナップショットみたいなイメージ

使い道

  • Startup acceleration
  • Live migration

使う目的

  • 起動の遅いサービスの高速化
  • リソースの効率の最大化
    • n台のサーバで構成されるPaaSクラスタのサービスキャパシティの最大化
    • かつ低コスト

Kubernetes on CoreOS (@ianmlewis)

Kubernetesとは?

  • クラスタのマネジメントシステム
    • 0.14.2 released
    • 200over contributors


#### Labels - Podに対して付ける

Kubetenetes on CoreOS

  • kubernetes-apiserver
    • kube-controller-manager
    • kube-scheduler

CoreOSで運用する際に考えないといけないこと (@harukasan)

pixivにおけるCoreOS

  • Release 554くらいから使い始めた
  • IDCFクラウド上に構築
  • pixivマンガで使用中
    • Scala / PlayFramework & Docker

デプロイ

  • fleetctlをキックしてquay.ioからpullしてデプロイ
  • デプロイ職人によるローリングデプロイ
  • コンテナの外の状態を気にする必要がない
    • 依存関係をOpsではなくDevの人が管理できる

モニタリング

  • dd-agent

なぜCoreOSを採用したか

  • アプリケーショの依存管理をコンテナ内に閉じ込めたかった
  • コンテナしか動かさない運用をしたい
  • なるべく状態を気にしたくない
    • Immutable
      • コンテナの状態は変えない
    • Disposable
      • コンテナをいつでも捨てることができる

        CoreOSをどう捉えているか

  • systemd + etcd/fleet/docker
  • サービスの管理はすべてsystemd
    • だいたいのことはsystemdがやる
  • fleetを使ってデプロイ
  • 開発時のDockerコンテナを動かすインスタンスとして便利

CoreOSを使う上で考えないといけないこと

  • 外部に依存しない状態を作るか
    • まだうまい方法が見つかってない
  • デプロイメント
    • fleetだとローリングリスタートできない
  • システムオーケストレーション
    • fleetでできるのは「このsystemdのサービスをクラスタ内でいくつ動かすか」
      • このサービスメンバをオートスケーリングとかは管理できない
      • kubernetesならできそう
  • etcdにおける最小構成
    • 最低4台
    • 3台だと1台落ちるとスプリットブレインが起こる
  • コンテナに対するロードバランシング
    • コンテナのstart/stop時にLBのAPIを叩く
    • etcdはキーが変更されたときにフックできるので、それをフックにしてLBの設定を変更
  • モニタリング
    • コンテナごとにモニタリングしないといけない
      • コンテナ名つけずにやるとデプロイごとにモニタルング対象が増えていく
    • DataDog
    • なにをモニタリングしないといけないか
      • サービスレベル
      • ノードレベル
      • コンテナレベル
      • 本当に全部見ないといけないか?
  • ログ転送
    • 各ノードにtd-agentを立てている
    • ※CoreOS上にtd-agentインストールして動かしてるっぽい?
  • 障害対応
    • 今のところホスト依存の障害は遭遇していない

個人的所感

  • rktはimage distribution周りの自由度が高い分、本番運用を考えた時にイメージの取り回しや配信でとても悩みそう
  • CheckPoint/Restore(というかCRIU)の話、色々すごすぎてついていけなかった
  • Kubernetes周りは自分で触ってないのでほとんどついていけず... いきなり本番で使うのは厳しいっていう話を @spesnova さんも話していた。とはいえうちもずっとCapistrano使い続けるのはどうなのかなあっていう感じだったので試してみる。
  • DevとOpsをいい意味で分離という切り口は確かにとてもおもしろい。今までDockerを触ってこなかったエンジニアへのアプローチにもなる。
  • そういえばうち今CoreOSはalphaチャンネルのもので動かしてた。@spesnovaさん曰くCoreOSのチャンネルは現状beta使うのが良さそうとのこと。チャンネル周りはalphaもstableも一長一短で消去法的にbetaしかない、っていう現状が結構つらみ。