OpscodeのChefとは何なのかを中級者以上向けに説明します。 普通のHow to とは方向性が違うので注意。Read less
![What is chef](https://cdn-ak-scissors.b.st-hatena.com/image/square/3b8872538200817636980036fece29d9d9e19d37/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fwhatischef201303-130304054510-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Chefはリポジトリをバージョン管理する仕組みを持っていますが、チームでの協調作業を考えるとバージョン管理システムを使う方が運用しやすいと考えます。本稿では、GitとJenkinsを使ってChefを運用するための1つのパターンを考えます。 以下があることを前提とします。 Chef Server Chef Client Gitリポジトリ Jenkins 基本的な考え方 CookbookをGitリポジトリで管理します。開発者がgit pushすると同時にChef ServerのCookbookが更新されるようにします。これにより、GitリポジトリとChef Serverが同期されるようになります。 また、後続ジョブとして各サーバでChef Clientが実行されるようにします。ビルドパイプラインを組むことで、Staging EnvironmentにおけるChef Client、Producti
本連載の第1回から第3回までは、主にmoonlinxのインフラ技術を説明してきました。今回からはmoonlinxのウェブアプリケーション技術に着目して解説していきたいと思います。 デプロイツール「Capistrano」の魅力 ウェブメディア「moonlinx」では、moonlinx Membership Centerと呼ばれるクリエイター向けの登録制会員サービスを運営しています。これは、デザイナーや音楽活動を行うアーティストをターゲットとしたサービスであり、クリエイター自身の活動をプロモーションするツールとして活用できるサービスです。 このMembership Centerでは、フレームワークとしてRuby on Railsを利用して開発しています。また、PhusionのPassengerを利用して、Apache2上で動作させています。 Railsの運用環境は、MongrelとMongre
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
11月25日、「mobidec 2011」においてコナミデジタルエンタテインメントのスタジオITセンター長である正延光弘氏によるセッション「大ヒットSNSゲーム『ドラゴンコレクション』を支えるコナミのクラウド技術の活用」が行われました。 ドラゴンコレクションは、GREEで提供されている携帯電話向けのカードゲームタイプのRPG。プレイヤーは、エリアごとにある複数のクエストをクリアしていき、モンスターカードや「秘宝」を手に入れ、さらに「ドラゴンカード」を集めていきます。また、ほかのプレイヤーとバトルすることでも秘宝を入手できるというSNS要素も取り入れられていました。2010年9月のサービス開始後、順調にプレイヤー数を伸ばし、現在では登録人数が500万人を超えています。 サービス開始当初は社内でサーバを構築し、フロントエンドに6台のサーバ、バックエンドに3台のデータベースサーバ、そしてロードバ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
開発部・システム運用グループの長野です。最近は「サーバ/インフラを支える技術」を読みながら通勤しています。今回はmixiの画像配信について書かせて頂きたいと思います。1回目は画像配信の課題について説明させて頂きます。 ■画像配信の種類 これまで画像の配信は大きく分けて2種類あると考え、システムを構築してきました。1つは1ファイルあたりへのアクセスが非常に多くなりますが、ファイル数が少ないもの。もう一つはファイル数が膨大になる代わりに、1つのファイルへのアクセスは少ないものになります。 前者はmixiの中で使われるロゴ画像やメニューの画像等のページ部品、また広告画像や絵文字画像になり、後者はユーザがアップロードする日記やアルバムの画像にあたります。ページの部品の画像はファイル数はそれほど多くないものの、サーバへのアクセス数が最大で秒間に数万リクエストにもなります。逆にアルバムや日記の画像は全
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く