Puppeteerで page.$(selector) で絞り込んだ要素から更に子要素指定を行う
最近がっつりとPuppeteerを触っている。 Puppeteer(書きづらい)とは、Headless ChromeをNode.jsから扱うためのライブラリ。
開発が速いのでググって出てくる情報は陳腐化していることがままあるので基本的には公式ドキュメントを読んでもらうのが大前提として、v1.1.1を触っている時点で得られた知見や小ネタちょこちょこと共有したい。
puppeteerの知見ですが、開発の流れが速いのでブログだったりの記事は古くなってるので公式のhttps://t.co/0agihTy0aCを読むのがベストっぽい。 ElementHandleからselector指定でもv0.13.0から取れるようになってる。
— べくさす (@Vexus2) 2018年2月23日
page.$(selector) で絞り込んだ要素から更にselector指定を行う
<div class="row"> <div class="col"> <div class="itemDetail">りんご</div> </div> <p class="price">120円</p> </div> <div class="row"> <div class="col"> <div class="itemDetail">みかん/袋</div> </div> <p class="price">520円</p> </div>
もともと page.$
page.$$
で絞り込んだ子要素 ElementHandle は .$
.$$
メソッドを持っていなかったので、page.$$evalで指定してループ内で取り出す・・・みたいな必要があったが、
v0.13.0 からは以下のように、取得したSelectorのオブジェクト(ElementHandle)から更に絞り込むような書き方ができるので前よりだいぶ直感的に書けるようになった。
const rows = await page.$$('.row') for (const row of rows) { const itemDiv = await row.$('div.col > div.itemDetail') console.log(await (await itemDiv.getProperty('textContent')).jsonValue()) const priceDiv = await row.$('p.price') console.log(await (await priceDiv.getProperty('textContent')).jsonValue()) }
Scalaコップ本メモ
そんなわけで最近Scalaを書き始めているわけですが、1ヶ月ほど前に今更ながらScalaスケーラブルプログラミング(通称コップ本)読んだので、その過程のメモ書きをまとめてみます。
ちなみに全部じゃなくて17章まで読みました。
実際書き始めてみると全然理解しきれてないところも多いのでもう一周読みなおそう・・・
- 作者: Martin Odersky,Lex Spoon,Bill Venners,羽生田栄一,水島宏太,長尾高弘
- 出版社/メーカー: インプレスジャパン
- 発売日: 2011/09/27
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 235回
- この商品を含むブログ (46件) を見る
コップ本メモ
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のものとほとんど同じだということが分かるだろう。JavaとScalaの違いは、Scalaでは入れ子になったスコープで同じ名前の変数を定義できることである。 (P143)
ScalaとJavaの違いとして注意すべきなのは、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)
写経しながらメモってたやつ
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.jpの開発(Rails化、Docker化、モヤモヤnanapiとか)
- IGNITIONの開発
- 継続的インテグレーションの導入、運用
- CTO室な業務(エンジニア組織のこと考えたりとか採用活動とか)
- インターンシップの運営
・・・とか、大企業ではあまり経験できないようなスピード感の中いろんな業務を経験させて頂きました。今年からはリードエンジニアという立場でチームや組織を俯瞰して見ることが増えて、様々な面で成長出来たなーと実感出来る日々でした。
辞める理由は大きくネガティブな理由はなく、自分の技術的な興味の移り変わりが大きな理由です。優秀な同僚が多く、切磋琢磨し合える環境で働くことができたのはとても感謝しています。
エンジニアの採用サイトがリニューアルしていたので、せっかくなので貼っておきます。 辞めた身でこういうこと言うのも変な話ですが、nanapiはエンジニア以外の人のマネージャ・経営層も技術に対して理解があるので、新しいことにチャレンジし続けたい人にはとても働きやすい環境なんじゃないかなあと思います。
ちなみにあまり表に出てなかったですが、1年ごとに5万円までデバイス端末を購入補助される制度とか、入社時に2万円までPC周辺機器を自由に購入できる制度とかもあったりします。
次はフリークアウトで働きます。Scalaを書くのでPhpStormもRubyMineも使わなくなりますが、引き続きがんばります。(もちろんIntelliJ IDEAは使う予定)
Wishlist貼っておきます。
IVS CTO Night & Day 2015 Spring powered by AWS Staff Report
これはなに?
6月10日〜12日で宮崎のシーガイアで開催された IVS CTO Night & Day 2015 Spring powered by AWS にAmazonさんと一緒にスタッフとして参加してきました。
スタッフという形ですが、発表やアンカンファレンスはほぼ全て見ることができました。めちゃくちゃ濃くて、そして心身共に疲れ果てた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と少し話した。
印象に残っていること
スピード感
面白いなと思って一番印象に残っているのが2日目のアンカンファレンスの「エンジニアの交換留学」について。 元ネタは今年の4月に行われていたpixivさんとドリコムさんの社会人交換留学について。
このテーマの元にどう思うか、自分たちの会社だったらどうか、という話が繰り広げられていた。 かなりポジティブに話が進んでいたらしく、具体的にそのアンカンファレンスの参加者の数社で交換留学をやってみよう、 という結論を1時間の中で出して、具体的なタスク化まで落としこんでいた。
コードを書き続けている人が多い
CTOが約100名と言っても会社規模はバラバラで、エンジニアは自分ひとりという会社もあったりするのでコードを書いているのは当たり前な部分もあるが、上場企業とかエンジニア規模百人以上の企業のCTOでも今でも日常的に(そして業務外で)コードを書き続けている人が多くとても刺激になった。
最近なんだかんだ言いつつ本とか(あとゲームとか)ばっかでコードから離れ気味になっている自分への戒めになった。
CTOは超パワフル
一部のCTOを中心に夜二次会、三次会〜に行って、朝4時くらいまでカラオケした後帰ってきて、その後朝8時半のLaunchPadには普通に参加しててすごかった。
食べ物が豪華
宮崎牛のローストビーフとかステーキとか食べた。
まとめ
とにかく刺激の連続なので、特に現場のエンジニアこそ機会があれば是が非にでも参加すべき、というのが個人的結論でした。 刺激だけじゃなく、CTOが感じていること・考えていることの高さまで強制的に目線を上げることができる3日間なので、コードを書いている以上に得られるものはとても多いと思う。 (1日中気を張っているからめちゃくちゃ疲れるけど!)
現場からは以上です。
2015初夏のKindle散財メモ
初夏というよりもはやもはや真夏の暑さだけど。 Kindleで50%オフ、というか厳密には50%ポイント還元してたので久しぶりに散財した。 最近もっぱらオーディオブックばっかりであまり紙の本とか電子書籍読む習慣がなくなってるので暫く積ん読になりそうではある。
- 作者: James O. Coplien,Neil B. Harriosn
- 出版社/メーカー: 翔泳社
- 発売日: 2013/08/23
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
- 作者: Peter J.Jones
- 出版社/メーカー: 翔泳社
- 発売日: 2015/01/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
- 作者: 松尾豊
- 出版社/メーカー: KADOKAWA / 中経出版
- 発売日: 2015/03/10
- メディア: Kindle版
- この商品を含むブログ (8件) を見る
- 作者: 中島雅弘,富永浩之,國信真吾,花川直己
- 出版社/メーカー: 技術評論社
- 発売日: 2015/05/26
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: ジーンキム,ケビンベア,ジョージスパッフォード
- 出版社/メーカー: 日経BP社
- 発売日: 2014/08/12
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
なれる!SE12 アーリー?リタイアメント<なれる!SE> (電撃文庫)
- 作者: 夏海公司
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/12/20
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
- 作者: 酒巻久
- 出版社/メーカー: 朝日新聞出版
- 発売日: 2012/09/01
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- 購入: 1人 クリック: 1回
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2013/08/23
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
- 作者: 岩明均
- 出版社/メーカー: 講談社
- 発売日: 2015/05/22
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
CoreOS Meetup Tokyo #1 に参加してきた #coreosjp
参加してきたので個人的メモをまとめました。 k8sは自分で触ってなくて、調べながら聞いてたのでほとんどメモ取ってません。 最後に個人的な所感をまとめてます。
Opening & Overview of CoreOS (@deeeet)
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)
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はマニフェストがない、自由
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をするには
- Community-Supported Platformsの中
- 自身のプラットフォームで動くイメージを作成するための修正を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
- GitHub Hookとか
まとめ
- OpenShift3=Docker+Kubernetes+PaaSの機能
- PaaSとしてはまだまだ未完成
- 現時点ではβ
- 正式リリースは2015夏くらい?
OpenShiftの構成
- docker
- kubernetes
- PROJECT ATOMIC
- 今回CoreOSで動かした
CoreOS運用の所感 (@spesnova)
- CoreOS on EC2
- 画像リサイズのホストに使っている
- &ElasticSearch
デプロイ
- ELB配下でBlue-Green
ログ
- logentries
- systemdのjournalを全部送る
モニタリング
- Datadogを全台に
etcd / fleet
- 全部使っていない
- ダイナミックオーケストレーション
- リソースマネジメントは?
- 使っていなくてもメリットはある
- ホストマシン構築タスクはほぼない
- AMI焼く必要すらない
- コンテナとホストの分離が楽
自動アップデート
- 今はオフ
- 今は手動アップデート
- locksmith(依存でetcd)が必要
- etcdの安定運用が前提条件
遭遇した問題
- CoreOSがEC2でクラッシュ
CoreOS channel選び
- alphaは品質的にalphaではない
- アップデートの頻度を表している
- ただしalphaは致命的なアップデートもくる
やりたいこと
まとめ
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
デプロイ
- fleetctlをキックしてquay.ioからpullしてデプロイ
- デプロイ職人によるローリングデプロイ
- コンテナの外の状態を気にする必要がない
- 依存関係をOpsではなくDevの人が管理できる
モニタリング
- dd-agent
なぜCoreOSを採用したか
- アプリケーショの依存管理をコンテナ内に閉じ込めたかった
- コンテナしか動かさない運用をしたい
- なるべく状態を気にしたくない
- Immutable
- コンテナの状態は変えない
- Disposable
- コンテナをいつでも捨てることができる
CoreOSをどう捉えているか
- コンテナをいつでも捨てることができる
- Immutable
- systemd + etcd/fleet/docker
- サービスの管理はすべてsystemd
- だいたいのことはsystemdがやる
- fleetを使ってデプロイ
- 開発時のDockerコンテナを動かすインスタンスとして便利
CoreOSを使う上で考えないといけないこと
- 外部に依存しない状態を作るか
- まだうまい方法が見つかってない
- デプロイメント
- fleetだとローリングリスタートできない
- 自前でスクリプトを書く必要
- fleetだとローリングリスタートできない
- システムオーケストレーション
- fleetでできるのは「このsystemdのサービスをクラスタ内でいくつ動かすか」
- このサービスメンバをオートスケーリングとかは管理できない
- kubernetesならできそう
- fleetでできるのは「このsystemdのサービスをクラスタ内でいくつ動かすか」
- etcdにおける最小構成
- 最低4台
- 3台だと1台落ちるとスプリットブレインが起こる
- コンテナに対するロードバランシング
- モニタリング
- ログ転送
- 各ノードに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しかない、っていう現状が結構つらみ。