A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation
新年あけましておめでとうございます。本年もよろしくお願いします。 えー、もう明日になってしまって今更宣伝してもという感じではあるのですが、明日開催される CROSS 2014 で、12:00 から 60分ほどセッションを開催します。「現場に聞く！テスト/CI/DevOps、実際のところどうなの」というタイトルでのパネルディスカッションです。 http://www.cross-party.com/programs/testcidevops/ 自分が司会で、他はクックパッドの id:secondlife (@hotchpotch)、KAIZEN platform Inc. CTO の @iandeth、はてなの id:hakobe932 (@hakobe) の4人と話します。 パネルディスカッション、というとテーマをあげてそれぞれの思うところを喋って貰う、みたいな形式もありますが、明日は自社ア
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
追記：μOSvはOSv本家にマージされました。 こちらのWikiの「OSvをビルドしてより多くのアプリを試す」以下を参照して下さい。 μOSvというものをgithubで公開したので、ここに簡単な説明を書いておきます。 実行イメージ動画： これは何？（OSvを知らない人向けの説明） ローカルマシン上のKVM・Xenや一部のIaaSサービス・VPSなどで走る、mrubyスクリプトを実行する事のみに特化されたOSです。 mrubyインタプリタの実行に汎用OSを必要としないため、とても少ないメモリ使用量（今のところ90MB以上なら動く）・ディスクイメージサイズ（今のところ26MB）・とても速い起動時間（今のところ2秒くらい）で動作します。 mrubyなのでRubyで使えるAPIが全て使えるわけではありませんが、ネットワークアクセスを行う小さなアプリケーションであればLinux上で動作するRubyス
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
As a developer and sometimes system administrator, one of the scariest things I ever encounter is a server that’s been running for ages which has seen multiple upgrades of system and application software. Why? Because an old system inevitably grows warts. They start as one-time hacks during outages. A quick edit to a config file saves the day. “We’ll put it back into Chef later,” we say, as we fin
We treat all our virtual servers as immutable. When we upgrade our system we create brand new servers and destroy the old ones, rather than upgrading them in-place. This is a logical extension of the phoenix server approach in which servers are regularly recreated from scratch. Our adoption of immutable servers was inspired by an anecdote that when physical servers play up in Google’s data centers
Automated configuration tools (such as CFEngine, Puppet, or Chef) allow you to specify how servers should be configured, and bring new and existing machines into compliance. This helps to avoid the problem of fragile SnowflakeServers. Such tools can create PhoenixServers that can be torn down and rebuilt at will. An Immutable Server is the logical conclusion of this approach, a server that once de
It can be finicky business to keep a production server running. You have to ensure the operating system and any other dependent software is properly patched to keep it up to date. Hosted applications need to be upgraded regularly. Configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. This requires some mix of c
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く