タグ

2013年9月2日のブックマーク (10件)

  • upstartでプロセスを自動再起動させる。 - ペンギンと愉快な機械の日々

    Unix/Linux, Debianおぷすたでインスタンスを作成した際に、自動でDNSにAレコードを登録するデーモンが(チーム内で作って)あるのですが、これが落ちていたためインスタンス起動時にレコードが登録されない、ということがありました。プロセスが死んだとしても勝手に再起動させればよいので、inittabかdaemontoolsかmonitあたりでやろうかなぁと考えていたら、@matsuu matsuu [誰?][要出典]ああ、もうdaemontoolsいらないね。落ちた時の自動起動だけならupstartで実現できる。Debianは6以降、RHELも6以降は標準でインストールされてる。Amazon Linuxも標準装備。ただしGentooでは使えません。 12 hours ago via web ·  Reply ·  Retweet ·  Favorite · powered by @

    ntaoo
    ntaoo 2013/09/02
  • 15分で始めるmonitによるサーバ監視

    サーバ管理者の間ではプロセス監視なら「daemontools」が定番ですが、個人的には設定が面倒で(慣れればどうという事は無いのですが)あまり利用していません。シャノンではプロセス監視の新定番として「monit」を激しくお勧め致します。設定が簡単でそれこそ誰でもプロセス監視ができる代物です。 総合監視デーモンとしてファイルシステムからHTTPレスポンス内容・プロセス監視などの機能を持っています。GPLライセンスでLinux/BSD/Solaris上で動作可能です。CentOSならDAGリポジトリからyum installもでき、configも簡潔ですので15分程度で導入ができます。

  • Quickstart for Python/WSGI applications — uWSGI 2.0 documentation

    Quickstart for Python/WSGI applications¶ This quickstart will show you how to deploy simple WSGI applications and common web frameworks. Python here is meant as CPython, for PyPy you need to use the specific plugin: The PyPy plugin, Jython support is under construction. Note You need at least uWSGI 1.4 to follow the quickstart. Anything older is no longer maintained and is highly buggy! Tip When y

  • Amazon EC2を使う前に知っておきたいこと色々:phpspot開発日誌

    Amazon EC2を使う前に知っておきたいこと色々。 仕事でEC2を使っているのですが、やって見る前に思い描いていたことと、実際にやってみると相違があったりしました。やる前に知っておくといいことをまとめてみました。 EC2を使う予定の方は参考まで。 それでは早速。 インスタンスの 32bit か 64 bit に注意する EC2では負荷が高くなったらハイスペックなインスタンスに変えればいいというのがありますが、32bitのOSイメージを64bitのインスタンスに入れることは出来ません。 最初はsmallインスタンス(最近ではmicro)から始まると思いますが、32bit でいうとハイスペックなもので High CPU のインスタンスまでになっています。それ以降は64bitなので、そこで環境を作り替えないといけなくなります。 とはいえ64bit環境はLargeからで安いとはいえないので、こ

    ntaoo
    ntaoo 2013/09/02
  • AWSについてまとめてみた(EC2編) - Mandy Code

    あいも変わらず不定期投稿ですが! とある方が「AWSコンサルとか絶対儲かりそうだよなー」とおっしゃっておりましたし、最近仕事でも勉強会でもAWSに触れる機会が非常に多いので、備忘録的に自分がどのようにAWSを使っているのかをまとめて行きたいと思います。 使い方自体を書いたブログはいっぱいあるのでTipsだけにします。 AWSの向き不向き まず総論ですが、AWSを使うメリットとデメリットを簡単に書いておきます。 メリット データセンターがいらない ある程度スケルトンが組まれている 維持管理にかかる人月が低い デメリット サービスが多い 細かいカスタマイズが難しい サービスによっては結構高い こんなところでしょうか。この前のAWSpadでも言われていましたが「スタートアップがAWSを使わない理由がない」、これはまぁそうだろうと思います。 しかしやはりサービスにちょっとした癖があるのと、罠もい

    AWSについてまとめてみた(EC2編) - Mandy Code
    ntaoo
    ntaoo 2013/09/02
  • AWSにおける可用性の考え方 | DevelopersIO

    よく訓練されたアップル信者、都元です。今回はコードや操作手順などなく。 オンプレミス環境等と比較すると、AWS上で稼働させるシステムには、サーバアーキテクチャはもちろん、アプリケーションのアーキテクチャにも色々考えるべきポイントが多々あります。AWS仕事をしていると当たり前過ぎてなかなか記事として言及する機会がないのですが、これらのアーキテクチャを組み上げる基礎知識となる、AWSにおける可用性の考え方をまとめてみました。 サーバは落ちるもの、データセンタは止まるもの AWSにおいては、単体のEC2インスタンスは「突如として落ちるかもしれない」という前提があります。さらに、何らかの障害や災害等で「AZ(availability-zone)も丸ごと落ちるかもしれない」という前提があります。突然落ちるというのは大げさ(でもないのですが…)にしても、時にEC2インスタンスはAWSから強制的に「再

    AWSにおける可用性の考え方 | DevelopersIO
    ntaoo
    ntaoo 2013/09/02
  • Railsアプリケーションを公開するならAssets on Cloudパターンを使おう - 働かないプログラマのメモ帳

    Assets on Cloudパターンとは 「Assets on Cloudパターン」*1はRailsデザインパターン*2の一つ。Railsアプリケーションの静的なコンテンツ(Assets)をクラウドに配置するパターンである。ファイルサイズの大きい画像などをクラウドに配置することでウェブサーバへのリクエストを減らし、ネットワークリソースを節約する。 Assetsの配置先はAmazon S3を推奨する。 asset_syncの使い方 「Assets on Cloudパターン」はasset_syncというgemを利用する。 Amazon S3の設定方法 asset_syncを設定する前にAmazon S3でバケットを作っておく。バケット名を自分が持ってるドメインのサブドメインと同じにしておくと少しだけ幸せになれる。ドメインを持っていない場合、適当なバケット名でもいいが、全世界で一意にする必要が

    Railsアプリケーションを公開するならAssets on Cloudパターンを使おう - 働かないプログラマのメモ帳
  • ぽんぽんぺいんなう\(^O^)/

    ntaoo
    ntaoo 2013/09/02
  • Apache Sparkってどんなものか見てみる(その1 - 夢とガラクタの集積場

    こんにちは。 Kafkaを試している最中で微妙ですが、最近使えるのかなぁ、と情報を集めているのが「Apache Spark」です。 MapReduceと同じく分散並行処理を行う基盤なのですが、MapReduceよりも数十倍速いとかの情報があります。 ・・・んな阿呆な、とも思ったのですが、内部で保持しているRDDという仕組みが面白いこともあり、 とりあえず資料や論文を読んでみることにしました。 まず見てみた資料は「Overview of Spark」(http://spark.incubator.apache.org/talks/overview.pdf)です。 というわけで、読んだ結果をまとめてみます。 Sparkとは? 高速でインタラクティブな言語統合クラスタコンピューティング基盤 Sparkプロジェクトのゴールは? 以下の2つの解析ユースケースにより適合するようMapReduceを拡張

    Apache Sparkってどんなものか見てみる(その1 - 夢とガラクタの集積場
  • ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策

    既に報道されているように、ロリポップ!レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備

    ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策