Reach Over The Sky, Tear The Sky

MECE目指して書き始めたけど全然無理でした。多分、初心者向けです。 仕事で書いたドキュメントの流用です。 会社にはインフラでズバッと意見を出す人がいないので、こういう割と広いこと見れてそうな入門ドキュメントを会社のドキュメントとしてためておくことで、将来誰か監視システムを刷新するときとかの方向性になれればという考えです。 持つべきか、もたざるべきか まず大枠の設計として、監視システムを持つべきか、持たざるべきかという点について考える必要があると思います。 これは監視をするかしないかという意味ではなく、監視システムのサーバを持つかどうかという意味を指します。 つまりZabbixやmuninといった監視サーバを構築して運用していくのか、それともMackerelやNew Relicといった SaaS監視システムにお金を払って利用するのか、という監視システム運用の方向性の問題です。 私の場合は、会社でインフラエンジニアが私一人だったので、私の興味からZabbixを立てることにしました。 Zabbixに惹かれたのは主に「ネット上に先人の記事がそれなりに上がってる」「カスタムスクリプト書けばなんでもできる」「成長したイケてるベンチャーも使ってて実はダサくない」という3点で、とくにスクリプトを書けばなんでもできそうというのは、私自身のコーディング経験の足しにもできるし、アプリケーションエンジニアにも説明すれば監視業務にコミットしてもらえそうという期待からでした。  CTOは新しくてイケてるSaaSを使うのが大好きだったので、実はすでにNew Relicが入っていました。しかし有料プランは結構高く、財布事情が許してくれなかったので、私の提案をしぶしぶ飲んで、Zabbixとの並行運用になりました。 そしていま運用して一年ちょいになりますが、Zabbixでできることが増えてきたので、New Relicはほとんど見ていません。 エージェント自体は残っているけど…。 監視システムに欲しい機能 監視システムには下にあげる機能が基本的に存在しているでしょう。 一部の特化型システムにはないものもあるかもしれないですが…。 そして、それらができるだけ自動化されていることが望ましいです。 ここでいう自動化とは、少ない手作業で必要な多くの作...

一部のユーザから、HTTPSのURLにアクセスできなくなったという連絡を受けました。 なんでも攻撃される恐れのあるサイトですとかなんとか…。 ブラウザのスクリーンショットをもらってみたら、こんな表示が。 Google Chromeでも同じ感じのエラーメッセージが表示されていました。（サイト名が出るので省略…） Chromeの方のエラーメッセージをよく見ると、 NET::ERR_CERT_REVOKED と書かれています。ファッ！？証明書が失効している…！？ そんな馬鹿なと思い手元でアクセスしてみたら普通に繋がる…HTTPSできてるよ？なんで？何が起こってるんだろう…。 結論を言うと、 SSL証明書業者が手違いで中間CA証明書を失効させてしまった ことにより、私たちが購入して使っている証明書が一時的に利用不可能になり、そのネガティブキャッシュをユーザが参照している 、というお話でした。 解消のための新しい中間CA証明書が公開されていたので、そちらを使って更新してみると、問題は解消されました。 ただ、自社が買っていたのはクイックSSL証明書だとばかり思っていたので、更新に失敗しまくって時間がかかりました。違うやつだった…。 SSL証明書とかドメインの周りのメンテナンスは多くても年に数回とかっていう頻度なので、いろいろ思い出すのに苦労しますね。 ていうか、そういうことあるんですね、中間証明書間違って消しちゃった！とか。 レジストラのDNSサーバダウンと合わせて、「 うちのせいじゃないんだけどご迷惑をおかけしてごめんなさい案件 」って感じで覚えておきたい…。

あー、なんか環境一式作ってくれるやつねー知ってるー使ったことないけどー…。 え？新しいアプリをElasticBeanstalkでローンチするの？それの運用やれ？ アプリはもうできている…？？ ということで速習にチャレンジ。 これを社内ドキュメントシステムにも残して、他のメンバーにも運用させる目論見…ｗ Environment Type（環境タイプ） Webサーバ　と ワーカーがある WebサーバタイプはHTTPポートを解放して外部からアクセスを受けるようなシステム全て。ユーザがブラウザでアクセスするタイプのソースコードを動かす場合は全部これ。 ワーカーはバックエンドのアプリのこと。SQSを使って他アプリというかシステムのワークフロー上の前後の機能とやりとりする。 DBの構築 RDSのインスタンスをElasticBeanstalkの構成の一部として起動することができる アプリを消すとDBも自動的に削除される。もちろん最終スナップショットは取れる 既存のRDSのスナップショットからRDSインスタンスを作成してそれをElasticBeanstalkアプリのDBにすることもできる ElasticBeanstalkの構成の一部としないDBを作成することもできる。その場合は、ElasticBeanstalkアプリを削除してもDBが残る。作り方は多分RDSインスタンスを普通に作り、ElasticBeanstalkからそこへ接続する。 その他のDBに関する仕様はRDSを参照 VPC内への構築 自分の既存のVPC内に構築することができる Elastic Beanstalk は、Linux プロキシ設定（HTTP_PROXY、HTTPS_PROXY および NO_PROXY）をサポートしていない。 直接インターネットからアクセスさせる（外部公開）するかNAT経由にする必要がある VPC全般に言えるがUDP123番ポートを利用してNTPで時刻同期している。なのでNTPが利用できるように解放しておく必要がある。 明示的にVPCを指定しないと自分のVPCを作ってそこに生まれる。 サービスロール、インスタンスプロファイル、ユーザーポリシー サービスロール は １個のサービスを正常に動かすために必要なポリシーをまとめたもの ...

凄く短いコマンドだけどすぐ忘れちゃうのでメモ。 知人から、SELinuxを停止してほしい、できれば指定するフォルダの部分だけ停止してほしい、という依頼を受けました。 話を聞いてみると、どうやらPHPを動かしたいディレクトリがあり、SELinuxのせいで権限エラーになっているようでした。 こういう時はSELinuxを停止するのではなく、 設定を変更しましょう。 コンテキストと呼ばれています。 まず今どんなコンテキストになっているのかを確認します。 ls -Z すると、  「system_u:object_r:httpd_sys_r_content_t:s0」  になっていました。  これだと書き込みができないみたいなので、変更します。 semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/app/*" restorecon -R /var/www/html/app このあと確認してみる と、  「system_u:object_r:httpd_sys_rw_content_t:s0」   に変わってました。 これでphpのエラーが消えました。 どうやらCakePHPでアプリを作るようです。  俺もやろっかなCake。

昔なんかそれっぽい表が必要だったので、書いてみたやつが、チケット整理してたら出てきた。どっかで使いそうなので、備忘録とします。 監視の種類 死活確認 症状確認 傾向確認 ログ監視 ◯ △ △ 性能監視 △ △ ◯ バッチ監視 ◯ △ △ レスポンス監視 ◯ △ △ プロセス監視 ◯ △ × 監視の種類としては ログ監視 性能監視 バッチ監視 レスポンス監視 プロセス監視 の５種類あれば、システムの一通りの状態確認が可能なのかな、と思いました。 で、確認すべき状態ってなんだ？ということになりますが、これは、死活の確認、症状（トラブルの程度）の確認、傾向（リソースの利用量）の確認を行うという方向性で考えればいいのかなと。

先日、Apacheで配信していたWebサイトをS3＋CloudFrontの環境に移行しました。そのときにやったことを備忘録としてまとめました。 個人的にハマって悩んだところや大事だなと思ったところは太字にしています。 0. 前提条件 一通り構成を組んだ後でのテストでは、キャッシュがしぶとくてコンテンツ更新後の状況が再現できないことがあるので、Invalidationしまくったり、ブラウザキャッシュを削除しまくったりする必要がある。 適当なテストドメインを用意できると良い。 たとえば、 www.example.com について構築しようとしているのであれば、 www2.example.com などをテスト用として確保するとよい。 phpやrubyは動きません、 Javascriptは動きます、Basic認証はできません 、会員登録はできません（phpやrubyが必要なページは動かない）、などの制約事項があるので、 非Techの関係者にネゴっとく 必要がある。 1. S3の基本的な設定 なんでもいいのでバケットを作る。 バケット直で自分が持っているドメインを紐付けようと思うなら、ドメイン名と全く同じバケット名（www.example.comのサイトを作りたい場合は、バケット名をwww.example.comにする。ドットは入力できないとエンジニアの直感でなんとなく思いがちだけど、普通に入力できる…。）にする必要がある が、多分不要。（未検証、今回はドメインと同じバケット名にしました…。） 静的ウェブサイトホスティングを有効にする。 インデックスドキュメントはindex.html（他任意のファイル名でもOK）、エラードキュメントはerror.html（他任意ry）にする。 バケットに、html, access-logs, cf-logs のディレクトリを作成する。htmlがコンテンツ置き場、access-logがS3が直接ロギングするログ置き場、cf-logsがCloudFrontがロギングするログ置き場にする。 コンテンツを突っ込んでみて、静的ウェブサイトホスティング用のURLにアクセスして、コンテンツが表示されるかを確認する。 2. CloudFrontの基本的な設定 基本的にはググって出てくるサイトを参考にしてよい。 A...

概要 暗号スイートという、暗号化技術の利用セットみたいな概念があります。 HTTPS（SSL/TLS）通信では、複数の暗号スイートからクライアントとサーバが利用可能なものを自動で選択して利用します。 しかし、場合によっては、弱い暗号化方式を使われてしまい、セキュリティ強度が下がる場合があります。 また、攻撃者はそのような選択が可能な場合、攻撃プログラムに故意にそういう暗号スイートを選択させるようにしたりします。 今回は、セキュリティ強化のために、ELBが、弱い暗号化方式である3DESを利用しないようにします。 しっかり理解したい方は、解説されている方がいらっしゃいますので、そういうブログや、セキュリティ系の書籍等をご覧ください。 理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷 http://tkengo.github.io/blog/2015/12/01/https-details/ 手順 ロードバランサーの画面を開きます 対象のロードバランサータグを選択し、リスナータグを開きます。 HTTPSの行の「暗号」をクリックし、カスタムセキュリティポリシーを選択します。 「SSL暗号」というリストの中から、「 DES-CBC3-SHA」を外します。 「保存」をクリックすると反映されます。 DESを利用した暗号化方式がリストアップされないことを確認します。 以下の記事を参考にさせていただきました。 【小ネタ】cipherscan で対象サイトの SSL cipher suite を確認する https://blog.cloudpack.jp/2014/07/29/cipherscan-ssl-cipher-suite/ ELBの暗号設定画面では、暗号化プロトコルも選択できます。 たとえばTLS1.2以外は使わせたくないぜ！という場合には、 同様にカスタムセキュリティポリシーの画面を開き、 「 SSL プロトコル」から Protocol-TLSv1.2以外のものを外せばいいです。 これで、またひとつシステムがセキュアになりました。