Organizations kentaro belongs to
cho45: 今 pull してもだめですかね… ★0
kentaro: やってみるお ★0
kentaro: できた! ★0
kentaro: アクセシビリティ設定の画面でて、consoleにもながれたー ★0
cho45: yatta- ★0
cho45: 謎だ！ ★0
kentaro: JSもうごいてるぽぽ ★0
kentaro: AM/PM表示にしてて変換されなくて?ってなったけど、24時間にしたらできた! ★0
cho45: なんだなんだｗ ★0
cho45: ああ、Slack のやつか〜 ★0
kentaro: とゆわけで動いたしiiir.orgにもはれる! https://github.com/cho45/CopyHook 便利だ ★5
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
antipop_: http://shibayu36.hatenablog.com/entry/2013/12/09/095849 ★2
antipop_: オーケストレーションに混乱があるのは ★0
antipop_: mizzyさんのエントリでは、オーケストレーションという単語が示す通り、 ★0
antipop_: 中心があって、そこからなんかするという発想で整理している ★0
antipop_: stanakaさんのほうは中心性がない、あるいは、個体がないもの前提で整理している ★0
antipop_: なので、orchestrationにふたつの軸があると考えるか ★0
antipop_: orchestrationではなく、単にmanagementととらえるか ★0
antipop_: 別の概念にするか ★0
antipop_: という感じをうけた ★0
mizzy: なるほど ★0
antipop_: mizzyさんの整理が旧来的なOrch.で、stanakaさんの方向に発展する ★0
gussan: ドクペ 残5 ★28
antipop_: でもいいけど ★0
mizzy: 元々はあんちぽさんのおっしゃる通り、中心があってそこからなんとかする、って考えっぽいですしねー。参考にしたプレゼンでも、「Command and Control」って言い方してました ★0
mizzy: それがSerfの世界になると、自律協調の世界になるので、発想ががらっと変わりますね ★4
antipop_: なので、stanakaさんのエントリの文脈になってくると ★0
antipop_: orchestrationじゃなくなるので ★0
antipop_: なんか別の言葉つくったほうがよさそう ★0
mizzy: たしかに ★0
antipop_: orchestrationとかいってた頃と状況が違いすぎるw ★0
mizzy: ですねｗ ★0
antipop_: Orchestrationといえば、やっぱMCollective的な発想が代表的ですよね ★0
antipop_: serfとかはもう全然違うし、mesosはいわずもがな ★0
antipop_: serfとmesosなども違っていて、 ★0
antipop_: そっちは個体があるかどうか、みたいな違いもあるとおもう ★0
mizzy: なんかいい言葉ないですかねー ★0
mizzy: Chad FowlerはHomeostasisとか言ってましたね ★0
antipop_: clustering, autonomyとかかなあ ★0
antipop_: homeostasisだと、orchestrationだけじゃなくて、全部まるごと感ある ★0
mizzy: あー、aunonomyはなんかよさそうな感じが ★0
antipop_: まあ、なにかしら言葉作らないと、混乱したままになるのは確実＞＜ ★0
antipop_: かっこいい言葉を考えて英語ブログを書いて世界的に有名になろう！ ★0
antipop_: そういえばPackerもりあがてますね ★0
antipop_: http://mitchellh.com/packer ★0
antipop_: いま、ec2-instance-launcherしてるところ ★0
antipop_: PackerであらかじめAMIつくってそれにpuppetあててくってしたら ★0
antipop_: 起動はやくなるかな ★0
kuroda: packerが何してくれるのかいまいちわかってないす ★0
kuroda: AMIさくっと作れる君でしたっけ？ ★0
antipop_: です ★0
antipop_: さくっと、っていうか、 ★0
antipop_: AMI/Vagrant box/etc.などを ★2
antipop_: 統一的な手順で作れる君 ★3
kuroda: AMIはできるだけ素の状態でおいておきたいので、packerを挟む必要はないかなぁとec2の場合。 ★0
mizzy: PackerもVeeWeeと同じで、インストーラ走らせてるようなので、求めてるものと違うな－、という感じですね ★0
kuroda: vagrantのbox作れるのは便利そうですね。 ★0
mizzy: isoとってきたりインストーラ走らせるの時間かかるのがイヤなんですよね ★0
mizzy: http://mizzy.org/blog/2013/03/11/1/ こんなのをPackerみたいな感じで実現したい ★0
antipop_: それはAMI/boxを作る時? ★0
mizzy: そうですね、つくるとき、ですね。AMIの方は見てないですけど、boxつくるときはisoとってきたりインストーラ走らせてるみたいですね。 ★0
antipop_: なるなる ★0
kuroda: ほむほむー ★0
antipop_: 多分Packerよいという状況って ★0
antipop_: puppet/chefをだいぶあてこんだ状態まで作る ★0
antipop_: って感じなんでしょうね ★0
mizzy: そうですねー ★0
antipop_: それだとAMI数がロール分必要になったりして、煩雑な感じする ★0
mizzy: hbstudyで話したprovisioningの話で言うと、bootstrap と configuration をひとまとめにしてる感じですね、Packer。 ★0
antipop_: バージョナップとかしたりもするだろうし ★0
mizzy: そこは別々でいいんじゃないか、と思ってます。 ★0
antipop_: ですねー ★0
antipop_: なので僕のとらえかたとしては、いまうちでやってるのでいえばcloudinitスクリプトでつっこんでるところの代替かなーと認識したんですが ★0
antipop_: cloudinitでめちゃめちゃ複雑なことやってるならまだしも ★0
antipop_: そういうわけでもないので ★0
antipop_: まあ、いいかなー、とおもった ★0
mizzy: ですね。 ★0
kuroda: すね。 ★0
antipop_: とらえかたがズレてなくてよかったです＞＜ ★0
mizzy: 同じくよかったですｗ ★0
antipop_: naoya the IT ojisanの解説をまつまでもなく認識できた ★4
kentaro: elim: https://github.com/paperboy-all/webistrano/pull/1 ★0
elim: o ★0
elim: なんと... ★0
kentaro: わろわろ ★0
kentaro: 爆笑がおこってる ★0
elim: 「消さないことにします...」って言ってる ★6
kentaro: wwwww ★0
kentaro: 消したらだめだよｗ ★0
kentaro: 次はまともなPRをよろしくお願いいたします ★0
elim: 伝えておきまする... ★0
kentaro: webiのメインラインは↑なので ★0
kentaro: なんか改造したらPRよろ〜 ★0
elim: それも伝えときますー ★0
elim: 身内でなければこのログ http://iiirc.org/ に貼りたいくらいや... ★2
kentaro: じゃあ僕がはるか ★1
