chefからansibleに乗り換えた5つの理由｜TechRacho by BPS株式会社
1年くらいchefを使ってサーバ構築をしていたのですが、最近ansibleに乗り換えたので紹介記事を書いてみます 1. サーバ側に何もインストールする必要がない chefは管理対象ノードにchef-clientをインストールする必要がありますが、ansibleはPython 2.4が入っていて、sshでログインできればOKです。 chefもパッケージや,knife bootstrapコマンド等があるので始めやすいですが、何もする必要がないansibleの方が敷居が低いのかなと思ってます。 例えばsshでログインできれば、以下のコマンドを打てば10.0.10.1～10.0.10.3サーバの情報をとってくれます(カーネルバージョン,CPU,メモリ,ディスクサイズ,ディストリビューション等)。 この機能はchefで使われているohai相当のことをしてくれます。 echo 10.0.10.1 >
なんかサーバ構築にやたらと時間かかるんだけど何で時間かかるのか考えてみた - tumblr
最近サーバ構築を仕事でやっているんだけど、どうにも時間がかかってしょうがない。 色々と面倒な制限があるため、それに合わせるように通常の手順を色々変更しなければならないんだけど、それにしても自分の見積もりより大幅に時間がかかっている。自分の見積もり精度は確かに良くはないんだけどもそれを差っ引いても時間がかかっている気がしてしょうがない。 何故かと考えてみた。 1. 何をやったらいいのか分からない 自分でサーバ構築した経験はあるものの、ほとんど全て自分の開発サーバや勉強用や社内で使うようなものだ。apache入れて終わり、iptablesとか面倒なものは使わない、みたいな場合が多い。なのでいくつかの要件を満たすように複数のミドルウェアの設定に一貫性を持たせた上で構築するということはしたことがなかった。 自分の開発マシン内で使うVMであればcurlを叩けばレスポンスが返ってくるもので普通は十分だ
間違いだらけのWEBサーバ Keep-Alive - 新・浅く広くをモットーに - WEBプログラマ メモ
14:30 | Keep-Alive on / off に関する文献の多くが曖昧であることが気になっていたので、まとめてみました。Apacheのドキュメントから、Keep-Aliveの説明を拝借しますと、HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、複数のリクエストが同じTCPの接続で送られる、長時間持続する HTTP セッションを提供します。つまり、Keep-Aliveは、『TCP 3ウェイハンドシェイクの節約』であるという点を理解しなければなりません。たいていの文献は『画像やCSSが多いサイトでは、接続を使い回すことにより無駄遣いをなくす』という説明をしていますが、この接続を使い回すという表現も曖昧な気がします。何となく分かった気になってしまう人も多いのではないでしょうか。それでは、まずは以下のようなhttpd.confで、Apacheの動
Nginx で Elastic Load Balancing などの Proxy の内側で正しい IP アドレスを取得する - Craftworks Tech Blog - Branch
EC2 だと ELB の内側では、nginx のアクセスログに ELB の IP アドレスが記載されてしまうので、HttpRealIpModule を使って Apache の mod_rpaf、lighttpd の mod_extforward と同じような挙動を設定します。 configure オプションに --with-http_realip_moduleが必要ですので、nginx -V で configure オプションを確認して、入っていなかったらコンパイルし直しましょう。 実際の設定は以下です。set_real_ip_from に ELB など Proxy やロードバランサーの IP を指定します。real_ip_header には、X-Real-IP や X-FORWARDED-FOR など Proxy が追加するヘッダーを指定してください。 http { set_real_i
怒涛のSyntax Error
Tweet 前回の記事で組み立てたサーバーをお見せしましたが、 それぞれのパーツを今回は紹介したいと思います。 本当はよく検討しながら買わなきゃいけなかったのですが、 時間があまりなかったので、”ノリ”で発注してしまいました。 まとめて発注したので、パーツがこんなに！ 個人ではこんなダイナミックなことできないですね。 選定したパーツはこれです まずはマザーボード Intel DQ57TM（Socket1156）です。 IntelAMT対応です。 \11,670円也 乗っけるCPUはこれ Core i5 660 BOX これもIntelAMT対応です。 \17,480也 これも試しに買ってみた。(クアッドコアだから) Core i7 870 BOX IntelAMT対応 \23,800也 ※ちょと高い。 ※これ買ったの失敗です↓ マザーボードDQ57TMはグラフィックチップを積んでいないので
とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
