shibayu36: orchestrationむずい ★0
kentaro: MCollectiveみたいなのイメージするといいよ ★0
shibayu36: MCollectiveしらない ★0
kentaro: capとかも、どこにホストもってるか、管理してるかは別として ★0
kentaro: サーバたちに対してコマンド実行したり等 ★0
kentaro: リモートからなんかするのが中央集権的orchestration ★0
kentaro: というか、オーケストレーションという言葉自体が中央集権的 ★0
shibayu36: ふむー ★0
shibayu36: じゃあ認識がちょい違ってたって感じかな ★0
shibayu36: Immutableになると ★0
shibayu36: これまではまず管理票で割り当てを決めてからサーバを立てられていた(これまでのサーバ管理ツール)けど ★0
shibayu36: これからはどこにサーバが立つかわからないから、建てたサーバからうまく中央にここにいますって通知できないと管理できないよなーという感じで ★0
shibayu36: orchestrationが出てきたと思ったけど、ちょっと違うっぽい ★0
kentaro: うん ★0
kentaro: で、それはorchestrationとはいわない ★0
shibayu36: へー ★0
kentaro: けど、mizzyさんの紹介した整理の枠組みでstanakaさんも話をしているから ★0
kentaro: serfとかmesosとかがorchestrationに分類されている ★0
kentaro: だから僕がiiircでかいたように http://iiirc.org/snippets/320 ★0
kentaro: 別の言葉を使うほうがよい ★0
kentaro: という流れです ★0
shibayu36: なるほど ★0
kentaro: オーケストラって、指揮者がいてみんなをコントロールするイメージでしょ ★0
shibayu36: あーいや僕もそのイメージなんですよね ★0
kentaro: しばゆーがいってる新しい状況は、指揮者いないじゃんすか ★0
kentaro: 指揮者がいなくてもなんかうまいことまわるようにしよう、ってことでしょ？ ★0
shibayu36: あー、書き方が悪いですね ★0
shibayu36: memcachedとかが自動的に入るってやつは ★0
shibayu36: そういう考えで ★0
shibayu36: んーでもうまくまとまってないな ★0
kentaro: しばゆーがなにをいってるのかわかrない＞＜ ★0
shibayu36: memcachedとかhaproxyが、そのクラスタ内でいい感じにやるっていうのは、指揮者いないですね ★0
kentaro: うん ★0
kentaro: それはそうですね ★0
shibayu36: でもcapがorchestrationっていうのが違和感持ったのは ★0
shibayu36: 統合管理とConfigurationみたいなのの間くらいに、デプロイみたいなところがあるよなーと思ったので ★0
shibayu36: なんとなく違和感があったってだけでした ★0
kentaro: デプロイってのはアプリケーションのデプロイ？ ★0
shibayu36: そうです ★0
shibayu36: インフラの構築はまさにConfigurationというところで ★0
kentaro: アプリのデプロイかどうかはわりとどうでもよくて ★0
kentaro: 動的な要素をリモートからコマンド実行してなんかする ★0
kentaro: ってのが本質じゃないですかね ★0
shibayu36: そういう意味でorchestrationという言葉があるんだったら、capかなあという感じだった ★0
shibayu36: capもorchestration ★0
kentaro: そういう意味って？w ★0
shibayu36: なんかorchestrationの言葉を最初に見たのがserfだったから ★0
shibayu36: どちらかと言うとサーバ同士のコミュニケーションとそれを最終的に管理している人がいるっていうのを想像してた ★0
shibayu36: もちろんserf自体は管理者を持たないけど ★0
kentaro: orchestrationってのは、インフラ構成における動的な領域に対する名前なのだけど ★0
kentaro: serfみたいなツールは、便宜上そこにいれられているだけで ★0
kentaro: serfまでくるとそれはorchestrationじゃないでしょ → じゃあ別の名前にしたほうがいいのでは？ ★0
kentaro: なので、 ★0
kentaro: エントリを読む順番がわるかったのではw ★0
shibayu36: そういうのはありそう ★0
shibayu36: 動的っていうのと静的っていうののちがいもいまいち理解してないんだよな ★0
kentaro: というわけで、orchestrationに変わるかっこいい言葉をかんがえてください ★0
shibayu36: サーバによって変わる部分とか?? ★0
kentaro: はてなでいうと、cronでなんか実行してサーバ管理ツールから情報とってきて設定かきかえる、とかそういうあれかな ★0
kentaro: たとえば。 ★0
shibayu36: 例えばこのサーバはちょっと性能悪いんで、process数は10くらいでお願いしますとかは動的? ★0
kentaro: そうじゃない？ ★0
shibayu36: なるほどー ★0
kentaro: そういうのchefとかでかきたくないw ★0
shibayu36: とすると、アプリケーションのデプロイは全部が全部動的ではないという感じもする ★0
shibayu36: コードの配置は静的だし ★0
shibayu36: 逆にConfig::ENV的な環境を変えてサーバを起動したりするのは動的か ★0
kentaro: コードは次々に上書きされていくでしょ ★0
kentaro: immutableじゃない ★0
shibayu36: コードは次々に上書きされていくというのは、単に頻度の問題だと思ってた ★0
kentaro: んー、なんか違う気もしてきた ★0
shibayu36: むずい ★0
kentaro: でもそんな細かいことはどうでもいい感じもするけどw ★0
shibayu36: というか ★0
shibayu36: 静的な部分はimageとして作れる部分ですよね ★0
shibayu36: dockerの ★0
kentaro: でするね ★0
shibayu36: processは入ってない ★0
shibayu36: なので、コードは含められるけど、どう動かすかは含められない ★0
shibayu36: ここが分けられると、imageの段階で何を入れられるか分かりやすいな～って思っただけだった ★0
kentaro: どう動かすかは、imageを配置して、そいつを動かすひとが決める、ってこと？ ★0
shibayu36: ちゃんと理解できてないから文字で説明するのが難しすぎるw ★0
kentaro: なんか細かい話になるとケースバイケースっぽいから ★0
shibayu36: まあそうですね ★0
kentaro: あんま区分してもしかたないきもするw ★0
shibayu36: なんかこれをずっと考えてたのは ★0
kentaro: 考えが整理されれて、コミュニケーションの訳にたてばいい ★0
shibayu36: コンテナデプロイになると、これまで本番サーバが動いている状態にデプロイしないといけなかったのが、そうでなくなるなーと思ってボーっと考えてただけなので ★0
shibayu36: とはいえ、インフラ的にこれまでどうだったか分かってなくてモヤモヤしてるというだけです ★0
kentaro: ↑もよくわからないが… ★0
shibayu36: なんか分かった、capっていうのがコードのアップロードっていうイメージが強すぎて、orchestrationに違和感があったってだけだった ★0
kentaro: コマンドのリモート実行のほうが本質感 ★0
shibayu36: 実際にはどういうプロセスを立ち上げるかとか、いくつ立ち上げるかとか、そういうのもcapでするからってことですね ★1
shibayu36: そりゃそうだ ★0
kentaro: ご納得いただけたようで。 ★0
shibayu36: 申し訳ございませんでした ★0
shibayu36: まあでもrebuildfm聞いてると ★0
shibayu36: orchestrationの意味合いが二つほど混ざってて ★0
shibayu36: mizzyさんはMCollectiveな話をしてて、naoyaさんはserf的な話をしてたのかって思った ★0
kentaro: それは僕が↑でいったような整理がされていなかったからでしょうね ★0
shibayu36: で、stanakaさんもserf的な話をしている ★0
shibayu36: だからrebuildfmでその部分が噛み合ってないように聞こえたのか ★0
shibayu36: という感じだった ★0
kentaro: そうおもう ★0
kentaro: ってiiircにかいた！ ★3