Reach Over The Sky, Tear The Sky

先日、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の基本的な設定基本的にはググって出てくるサイトを参考にしてよい。Alternate Domain Names には、テスト用に確保しておいたドメ…

概要
暗号スイートという、暗号化技術の利用セットみたいな概念があります。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のより良い書き方を学ぶ

今の会社に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のグラフやスクリーン機能を利用することにより、プロダクトマネージャの上司が提携先に性能監視状況を説明することができるようになっ…