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 from Yutaka Matsubara
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はマニフェストがない、自由
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しかない、っていう現状が結構つらみ。
IGNITIONチームの開発フローについて話してきた #nanapi_study #hatenatech
こんにちは！だいぶ久々の投稿です。
今週は台風18号、来週は台風19号が来ていますが、そんな台風の合間を縫って東京と京都の勉強会で話してきました。
nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper
【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass
ブログを書くまでが勉強会！既にこれらの勉強会についてのまとめはいくつかブログが上がっていましたので、このエントリでは懇親会で話したり聞かれたネタとか、スライドの補足とかを諸々書いてみます。
物理カンバン廃止について
最初は物理カンバンを使ってタスク管理してましたが、途中からIGNITIONチームでは物理カンバンを使わない、という選択肢を取りました。
理由としてはいくつかありますが、一番の理由は「管理が面倒＆無駄が多い」っていうところです。 バーンダウンチャートを作るなりログに残すにしても結局別のタスク管理ツールとの二重管理が必須になってました。
あと、振り返りMTGをやるときにも物理カンバンを別の会議室まで引っ張って行くのも正直面倒というのもあります。日々の開発の中でだるいなーと思う箇所を排除したい（という意識を共有できるメンバーが多い）チームだったのでそういう選択を取りました。
もちろん物理カンバンの一覧性＆視認性は捨てがたいところではあるんですが。 リモート開発をいつでも出来るような環境を想定した開発フロー選定、というのもちょっと意識しました。
Jenkinsを使わない
語弊がありそうなので最初に書いておきますが、Jenkins自体はとても良いツールだと思いますし、nanapi.jpや他サービスの方では一部では現在も使っています。
が、IGNITIONチームではJenkinsは使わない、という選択肢を取りました。 理由としてはいくつかあって
- メンテコストが非常に高い
- 属人性が高くなりすぎる
- 社内のメンテナが固定されがち
- 結果、各ジョブが秘伝のタレ化する
- 社内のJenkins職人（通称Jenkinsおじさん）しかメンテできない
というのを問題視しています。
個人的意見ですが、クックパッドさんのデベロッパープロダクティビティ のように、それらをミッションとした専属チームがメンテをし続けられるのであればJenkinsも良いのかなあと思っています。
nanapiの規模だと個人が管理し続けるのはとてもしんどいので、そういったジョブはすべてSaaSに寄せる方向で検討している、といった感じです。
PhpStormの話
とりあえず言いたいことはすべて去年のPhpStorm Advent Calendarに書きました！
IntelliJ IDEAとかRubyMineでもPHP周りの独自機能を除けば基本は同じなので、ショートカットとか便利機能とか参考にして頂ければと思います。 全部読むのだるい方は、とりあえず25日目の記事を見ると大体幸せになれます。
ちなみに今年はAdventCalendarは書かないです。（予定）
Mackerelチームについて
発表者の id:motemen さんの記事が参考になります！
開発フローに正解なんてないので、気に入った＆チームに合いそうな部分を取り入れていけば良いのかなあと思います。
うちでは早速 Mackerelチームの 式次第 のやり方を振り返りMTGに取り入れてみました。
関連リンク
nanapi勉強会vol4でパネリストしてきた | おそらくはそれさえも平凡な日々
「nanapi勉強会 vol4」に参加してきました - 勉強会ログ
ちょっと面白いプラグイン Referencer
今日見つけたちょっとおもしろプラグイン。 http://plugins.jetbrains.com/plugin/7104
- Ctrl+Shift+Alt+C, Ctrl+Shift+Alt+C
- Ctrl+Shift+Alt+V, Ctrl+Shift+Alt+V
とかで動きます。
それぞれ、
- 現在のファイルから、いい感じの文字列を選択してクリップボードにコピー
- 現在のファイルから、いい感じの文字列を選択して貼り付け
が出来たりします。
具体的には、現在の時刻とかUnixTimeとか、現在のファイルパスとか開いてるファイルパス一覧とか、ファイル内の変数とかメソッド名とか、コード内のテキストとか色々取ってこれます。
絞り込みできないからあんまり使い道思い浮かばないけど、ちょっと使ってみる。
PhpStormからPull Requestが発行出来るよー
PhpStorm7からの新機能。
Find Action -> Create Pull Request から、Pull Requestが発行出来るよ！
OKすると、
こんなポップアップ出るので、リンククリックでGithubに直に飛べます。
PhpStorm内で完結できることが増えましたね！超便利。
ノリでブログのタイトル変えてみたよ
どうかな。
「PhpStormで始める快適なWebアプリケーション開発」について話してきた #phpcon2013
先日のPHP Conference 2013でPhpStormの便利な機能とか、フレームワーク開発での小ネタとかについて話してきました。 限られた時間だったので矢継ぎ早になってしまって、こちらで詳細書いてみます。
PhpStorm × Framework
Symfony2
強力なコード補完をサポートしてくれるSymfony2用のプラグインです。 xml/yamlファイル内でのジャンプとかもサポートしてくれます。
こんな感じで、サービスコンテナから取得したクラスに対してもコード補完してくれたりします。
詳しい設定や使い方はこちらが参考になります。
PhpStromのSymfony2 Pluginによる入力補完が便利すぎる
CakePHP
私が個人的に作っているCakePHP用のプラグインです。1.3系、2系共に動きます。
Controller⇔View、View⇔Element、Model/Controller⇔TestCaseなどのファイル間ジャンプや$this->render()しているテンプレートファイルへのジャンプをサポートします。
詳細の使い方はこちらを参照してください。
PhpStormのCakePHPプラグイン、CakeStormを作ってみました
Laravel
一手間掛かりますが、上のHelperを設定しておくと各種クラスでのコード補完をしてくれます。
その他フレームワークなど
専用プラグインがないフレームワークでも、PhpDocをしっかり書けば特殊な呼び出し方をしているクラスからもコード補完してくれます。
例えば、CodeIgniterとかでは
@property Search_model $Search_model
のような形で、@propertyアノテーションを指定しておくと、
このように、$this->Search_modelのような呼び出しの形でもコード補完してくれます。
PhpStormで便利な機能
便利機能はめちゃくちゃ多いんですが、「高機能すぎて把握しきれない･･･」というような方は多いと思います。 そこで、個人的によく使うコマンドや、 マイナーだけど便利だなーって思う機能を幾つか紹介します。
また、機能は全てアクションの正式名称のまま表記しているので、 気になったショートカットなどは[Preferences]-[Keymap]から検索するとすぐ見つかると思います。
機能名の横の()はWindows環境でのデフォルトショートカットを表しています。
Find Action (Ctrl+Shift+A)
PHPエンジニア養成読本
例えば、GitにPUSHしたいときはCtrl+Shift+A → "push"と入力すると
このようになり、置換や一括置換を行いたいときはCtrl+Shift+A → "replace"と入力すると
このような形で、実行可能なアクションを一覧で表示してくれます。
Jump to Class (Ctrl+N) / Jump to File (Ctrl+Shift+N)
それぞれクラス名やファイル名を指定して直にファイルにジャンプ出来る機能です。 1文字入力毎にファイル一覧を高速でサジェストしてくれます。 個人的にはJetBrains系IDEの醍醐味と言っても過言ではないくらいの超有用機能だと思います。 ちなみにPhpStorm7からファイルのサジェストが超高速になってます。
それぞれ"Account"という単語を、上がJump to Class、下がJump to Fileで絞り込んだ状態です。 機能の名前の通り、Jump to Classはクラス名にAccountが含まれるファイル、 Jump to Fileはファイル名にAccountが含まれるファイルを一覧で表示してくれます。
Go to Decralation (Ctrl+B)
変数やクラス、メソッドの定義元にジャンプする機能です。Vim界でいうところの"gf"コマンドに相当します。
例えば、CakeEventクラス上のCtrl+Bを押すことにより、CakeEventクラスの定義箇所までジャンプすることが出来ます。 同様にメソッドや変数も、参照可能な範囲であればジャンプ出来ます。
Recent Files (Ctrl+E)
PhpStorm上で直近に開いたファイル履歴を表示してくれます。 普段開発をしていると同じようなファイルを何回も行き来することは多いので、使用頻度はかなり高めです。
類似コマンドでRecent Changed Filesというものもあり、こちらは「直近に編集したファイル」履歴を表示してくれるので、用途を分けて使い分けるといいです。
自動アップロード
私は「ローカルのMac上でPhpStormを立ちあげて開発」、「開発用のサーバにコードを置いて実行」のようなスタイルで開発していますが、 ファイルを編集する度に手動でアップロードしなければならないのは死ぬほど苦痛です。
PhpStorm上では、"ファイルに差分が発生したら自動的にアップロード"してくれる機能があるので、そちらを設定しておくと便利です。
上記なように、サーバに合わせた形でDeployment Serverを設定しておき、 [Tools]-[Deployment]-[Automatic Upload(always)]にチェックを入れておけばokです。
また、Git上でブランチを移動した際に、ブランチの差分ファイルのみを自動アップロードしてくれる機能もあります。 その際は、以下のように[Tools]-[Deployment]-[Options]から[Upload external changes]にチェックを入れておけば有効になります。
Local History
PhpStorm上で編集したファイルを、ファイル毎に時系列で編集履歴を閲覧することが出来ます。 「Gitにコミットしてなかったけど、今朝の時点に戻したい・・・」みたいなときにも便利です。 また、こういう機能があることを知っておくだけでもいざというときの保険になりますので是非押さえておきましょう。
リモートデバッグ
EclipseやNetbeansなどのIDEと同様、PhpStormでもリモートデバッグが可能です。 面倒な設定がほぼ不要なのと、コードの動的実行が可能な点が他より優れています。
リモートデバッグの設定についてはこちらが参考になります。
Zero-configuration Web Application Debugging with Xdebug and PhpStorm
コードの動的実行は、「ブレイクポイントで停止した箇所で任意のPHPコードを実行出来る」機能です。 どんな形式で返ってくるのか試したい関数や、複雑なコードでどういう途中結果が帰ってきてるのか知りたいような場合に便利です。 もちろん、停止箇所で保持している変数を参照して実行することも可能です。
例えば、CakePHPではfind()メソッドでDatabaseから任意のデータを取得出来ますが、「取得条件を変えた時にどんな値が返ってくるのか試したい」みたいなことは多々あります。 そのようなときは、任意の箇所をブレークポイントを貼って止めておき、実行中のプラグラムで
$this->Search->find('all', array(
'contain' => false,
'conditions' => array(
'Search.created <' => $today
)
));
のような箇所を選択し、[Evaluate Expression]のコマンドを実行すると
このような形で実行結果が見れます。
