$shibayu36->blog;スマートフォン用の表示で見る$shibayu36->blog;株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。bloghttp://rebuild.fm/25/この辺りを読んだ。Infrastructureについてはここ一週間で調べただけであり、解説などは出来ないが、とりあえず自分用のメモとして自分の思ったことなどを書いていく。コンテナベースのデプロイDockerなどが出てきたことにより、Dockerのイメージをそのままアップロードし、それを本番でも動かすということが出来そうというのが面白かった*1。いう風なフローになるとすると、これまでのデプロイ手順とは全く違うようになりそう。balancerの切り替えにより、新しいコードを使うという流れだった。server起動のような流れになりそう。この時、これまではコードの反映などを起動中サーバに行わなければならなかったものが、コンテナのimageに対して行えるようになるというのは手順として大きく違うように思う。このような手順になると、本番と完全に同じ状態のimageに対し、jenkinsでアプリケーションのテストを走らせ、それが通ったらそのimageをそのままアップロードするという事もできそう。Infrastructureでは、必ず一から作りなおすのかというのはそうではないという話のようだった。作ったものにはもう触らない、いつでも捨てられるという考え方にすることで管理を容易にしようという話のように聞こえた。実際にデプロイごとに毎回まっさらな状態からchefを走らせて、アプリケーションの配置を行ってってやってるとすごい時間かかりそうだし、デメリットも多そう。具体的にどうするのがいいのかなと想像してた。インフラの構成管理という部分と、アプリケーションの反映という部分は分けられるんじゃないかなーと思う。インフラの構成全ての冪等性は難しいchefとかの難しさを見てるとそういう感じアプリケーションコード反映のみの冪等性は結構簡単コード自体は最新の状態で配置すればよいだけ依存モジュール管理もbundlerやcartonに任せられる?こう考えると、冪等性が難しい部分の変更があった時は最初から作り直す、簡単なところは差分で作るというふうにしてもいいのかなと思った。commitするだけコードの反映、アプリケーションの依存モジュールインストールなどこのくらいだと、毎デプロイの段階で作りなおすことはしないけど、一から作り直すのも簡単なのかなと思った。Orchestration?Orchestrationという部分が結構難しかった。僕の中ではmizzyさんのエントリを見た時、Orchestrationにcapistranoやfabricが入っているというのは非常に違和感があった。そのあとstanakaさんのエントリのOrchestrationの説明がしっくり来た。Infrastructure的なことをしようとすると、これまでのようにサーバの管理表を作って管理するということが出来なくなる(?)ので、いろんな場所に作られたサーバから自分はここにいるという通知をしたり、そのイベントを使ってアクションする必要が出てくるのかなと思った。ある構成の一部分だけ入れ替えたいときに便利だったりしそう。あるアプリケーション構成のmemcachedだけ置き換えたい時に、置き換えた後アプリケーションの該当部分の設定を書き換えてデプロイするというのではなく、置き換えた通知を受けたアプリケーションサーバが自動で設定を書き換えて再起動するみたいに。いえまだまだ良く分かってない。追記)別のエントリでもう少し書きました。Infrastructureについて調べたので、その時に感じたものを自分の備忘録として記録してみた。FoundページやISEページをカスタマイズする月別アーカイブはてなブログをはじめよう!shiba_yu36さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。