投稿

2016の投稿を表示しています

小さな会社で一人で監視サーバ立てて運用して一年以上たったのでそのまとめ

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

一部のユーザだけ NET::ERR_CERT_REVOKED でサイトにアクセスできない

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

ElasticBeanstalkの速習にチャレンジ

あー、なんか環境一式作ってくれるやつねー知ってるー使ったことないけどー…。 え?新しいアプリをElasticBeanstalkでローンチするの?それの運用やれ? アプリはもうできている…?? ということで速習にチャレンジ。 これを社内ドキュメントシステムにも残して、他のメンバーにも運用させる目論見…w 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を作ってそこに生まれる。 サービスロール、インスタンスプロファイル、ユーザーポリシー サービスロール は 1個のサービスを正常に動かすために必要なポリシーをまとめたもの

PHPで書き込みができないからSELinuxを停止してと言われた

凄く短いコマンドだけどすぐ忘れちゃうのでメモ。 知人から、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。

監視の種類とカバーできる範囲について考えてみた

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

ウェブサイトを HTTPS + CloudFront + S3 の環境に移行したのでその振り返り

先日、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

ELBのHTTPS暗号化方式から弱い方式を除外する方法

概要 暗号スイートという、暗号化技術の利用セットみたいな概念があります。 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以外のものを外せばいいです。 これで、またひとつシステムがセキュアになりました。

条件判定値を引数にそのまま流用できないかを考える

イメージ
自分向けのプログラミングTipsメモです。大した内容ではありません。 Gistにサンプルコードを書いてみたので、まずそれを貼りたいと思います。 コードは、AWSを操作するための Python版 AWS SDK(Boto3)を利用したプログラムの一部です。 仕事で書いているBoto3プログラムで、こういう場面がありました。 取得した配列のある要素の値がTrueかFalseかで後続で実行する関数の引数を変えたい。 関数の引数にはTrueかFalseを用いる 当たり前といえば当たり前ですが、条件判定しているTureかFalseを、そのまま関数の引数として与えれば、条件判定する必要がないんですよね。 こういう小さな省力化(短いコードで書く努力)を積み重ねることで、一個のサービスが出来上がった時に体感できるような差が生まれるのかなぁなどと思いました。 普段はサーバ管理みたいな仕事が多いので、こういう風にプログラミングに対して自分で「おっ、こうした方がいいじゃん?」みたいな思考ができたこと自体がなんだかとても嬉しくなりました。 こういう気持ちはたとえ小さくてもきちんと表現したり記録しておくことが精神衛生上、そして今後の技術力向上のモチベーション管理上も良いのかなぁと思って、ブログに書いておこうと思った次第です。 こういうTipsがまとまった本とか、あるのかな、普通にありそうだな。 プログラミングをもっと業務でできるようになりたいです。 スマートPythonプログラミング: Pythonのより良い書き方を学ぶ

転職して1年経ったので振り返ってみた2016年5月

イメージ
今の会社に2015年5月に入社してから1年経ちました。 あっという間だった気もするし、すごく長かった気もします。 自分がどのくらいの仕事をして、何が新しくできるようになったのかを整理したいと思い、箇条書き形式でまとめてみました。 今の会社ではAWSを使っていて、AWSを使ったインフラ全般の構築運用を行うエンジニアとして働いています。 入社前はAWSもEC2をちょっと触ったことがあるぐらいで、インフラの知識もそんなに自信がない状態でした。(今もないですが…w) AWSエンジニアとしてはまだまだジュニアだと思いますが、1年前には何もできなかったことを考えると、少しはできることが増えてきたなぁと思います。 会社の体制も大分変わり、1年前はエンジニアがCTOとインターンのみでしたが、私の他複数名のエンジニアが採用され、エンジニアチームができ、外部委託している部分を大幅に巻き取って、自分たちのプロダクトを自分たちで責任を持って育てる土壌ができたのかなと思います。 できるようになったこと 日々の設定変更作業 Ansibleの初歩的な利用法を学び、初歩的にAnsibleを導入して設定業務が効率化された。 サーバ新規構築時のエンジニアのアカウント作成、公開鍵配布、sudo可能化、個人ファイル配布がAnsibleで自動実行できるようになった。 Python AWS SDK (Boto3) を利用して、AWSの管理効率化スクリプトを幾つか作成できた。 毎日すべてのEC2のAMIを自動バックアップ 指定した世代より古いAMIとEBS Snapshotを自動削除 各ELBに紐付いているEC2インスタンスの表示名、Public IP、ヘスルステータスを表示 ELBに紐付いているサーバを切り離したり、紐付いていいないサーバを接続させる 指定したEC2のAMIを取得し、そのAMIから任意の台数のEC2インスタンスを作成 監視 Zabbixを導入し、一元的な監視が可能になった。 Zabbixが検知したトリガーをSlackに流し、タイムリーに社内に報告される体制ができた。 一部のエラーに対してはZabbixで検知した障害をトリガーに復旧スクリプトを実行して自動復旧をすることができた。 Zabbixのグラフやスクリーン機能を利用することに

AWS EC2 の インスタンスIDにマッチする正規表現が欲しかったので試行錯誤した結果

得られた正規表現 '^i-([a-zA-Z0-9A0-zZ9]{8}|[a-zA-Z0-9A0-zZ9]{17})$' 背景 今の勤務先ではAWS系インフラエンジニアとしてAWSの管理全般を行っています。 昨今のクラウド全盛期においては運用業務の各種自動化が大事ということで、Python + AWS SDK(Boto3)で、AWS管理自動化プログラミングを少しずつ進めています。 AWSの操作はEC2に関するものが多く、EC2のインスタンスIDを引数に与えるものが多くなっているので、インスタンスIDが正しく入力に与えられているかをバリデーションできたらいいなと思い、ちょっと探してみた結果、以下のような正規表現を得ることができました。もっといい案がありましたら教えてください。 数ヶ月前に、インスタンスID及びAMI IDの文字数拡張がアナウンスされています。なので、「i-(英数字8桁)」の場合と、「i-(英数字17桁)」の場合に対応する必要がありました。今回はそれに対応できるようになりました。 得られた正規表現をPythonで使いたい Pythonで使う時には、 標準で用意されている re というモジュールをインポート して、 search() を使うことで、与えられた文字列が正規表現にマッチしているかどうかを確認することができます。 「i-」の後ろが8桁の英数字か、17文字の英数字の時のみ、オブジェクトが返ってくるので、そのオブジェクトの存在を確認すれば、インスタンスIDが実在するかはどうであれ、少なくとも形式に沿った値であるということがわかります。 >>> >>> re.search('^i-([a-zA-Z0-9A0-zZ9]{8}|[a-zA-Z0-9A0-zZ9]{17})$', 'i-0') >>> re.search('^i-([a

AWSでPostgreSQLを前から使っている方はアップグレードメンテナンスが必要です

イメージ
AWSのサポートからこんなメールが届きました。 Dear Amazon RDS Customer, A system update is now available for any Amazon RDS PostgreSQL database instances you created before 13 October 2015. We recommend installing this update to take advantage of several performance improvements and security fixes. You may choose to install this update immediately, or during your next scheduled maintenance window. After approximately six weeks, your RDS instance will be automatically upgraded during your maintenance window. To learn more about scheduling or installing an upgrade, please refer to the RDS documentation: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.OSUpgrades.html. Installing this update will have an availability impact for a few minutes on your RDS instance (60-120 seconds for Multi-AZ instances). To reduce downtime, you may consider converting your Single-AZ instances to Multi-AZ. If you have any questions or concerns, please contact your TAM or AWS Support. Sincerely, The