新年あけましておめでとうございます。

新年あけましておめでとうございます。

昨年は新年早々修理やっていましたが、今年はコーディングで年を越しました。
まぁ年末年始は毎年恒例自宅待機でサーバ監視なんですがね・・・

本業としてはAWSを主にやってきているのですが、人がいないので自動化が簡単なスクリプトでサクサクできるのが楽しいですね。従量課金で自腹検証にも優しいですし
昨年はSTSやOrganizationsが楽しくてあれこれ突きまくって、年末なのに何度も特別処理をサポートにお願いしたりしました。（BASICプランなのにスミマセン・・）
AzureやGCPも少し触りましたが、両クラウドとAWSの差はUIが開発者向けかユーザ向けかという点が大きいと感じています。どちら側を向いているか。と言い換えることもできるかと思います。
特にAzureの横長UIやJSTなのかUTCなのかよくわからなかったり、突然出てくるJSONなエラーコードとか消せないリソースとかetc.....
GCPはAzureほどではないのですが、UIがどこに何があるかわからない。あとサブネットやFWの設定もなくいきなりSSHつながるのが怖いｗ
いやまぁ開発者からすれば便利なんでしょうけど。
逆にAWSはオンプレの知識というか、物理ネットワーク組んだことないと入口にすら立たせてもらえないハードルの高さはあります。

しかし、コンパネの使いやすさ、レスポンスの良さは圧倒的です。あとドキュメントが豊富にあります。SlideShareや公式ブログもありますし、クラスメソッドさんのブログがある。という点が圧倒的ですね。

個人的にはSDKが豊富。特にRubyで使えるのが良いです。
PHP、Ruby、node.js、Pythonと試してみましたが、Rubyが一番書きやすいと感じました（個人の感想です）
まぁSDK使ってAPIバシバシ叩いているインフラ屋さんって珍しいのかもしれませんが・・

という訳で、今まで触ってきたものを一覧から列挙してみます。

• EC2
• S3
• RDS
• DynamoDB
• ElastiCache
• VPC
• CloudFront
• Route 53
• Direct Connect
• CloudWatch
• CloudTrail
• System Manager
• IAM
• Inspector
• Certificate Manager
• Directory Service
• Simple Notification Service
• Simple Queue Service
• Simple Email Service

結構使ったことあるなぁ。まぁAWS全体のサービスからすればごく一部なんですけど。
今年はいよいよ（やっと？）サーバレスというかラムダを勉強しようと思います。
残念なことに、ラムダではRubyが動きません。コンテナで動いているのだから対応してくれてもいいのですが、AWSの中の人曰く対応する予定はないとのこと・・・
しかもサポートしている言語はどれもやったことないものばかり。（これがラムダを避けていた理由）
どうせ最初から学ぶのならどの言語を選んでも同じなので、node.jsとpythonで書いてみました。
この時はPythonの意味不明なエラー。送られてくるデータにまさかJSONが混入しているとは予想していなくてパースエラーで数時間を溶かす。などでnode.jsでやるかと思ったのですが、非同期処理が良く分からない。書いていたらコールバック地獄で根本的に間違っている気が激しくするものが出来上がり、これは独学はキツいと断念。

その足でnode.jsの本を探しに書店で探すも見当たらず、結局
AWS Lambda実践ガイドを購入。実践とあるので難しいかと思ったが、内容を見るとほぼ自分がやった内容なのですんなり理解。（なんと試行錯誤したSESのバウンスメール処理がサンプルで乗っていた。JSONの件も当然記載があり最初から本漁れば時間を無駄にしなくて済んだOrz）

というあたりで、年末年始にやった成果を置いておきます。

• wiki
• STSについて
• AWS Orgnizationsを使ってみる
• CloudWatchEventと連携して定期実行させたい
• S3バケットで静的コンテンツを配信したい
• 国別にアクセスを振り分けたい
• gist
• sesバウンスメール処理ラムダテスト(node.js)
• Node.JS勉強がてら作成した、RDSのログファイルを一括ダウンロードするスクリプト
• Python勉強がてら作成した、RDSのログファイルを一括ダウンロードするスクリプト(ローカルファイル版)
• Python勉強がてら作成した、RDSのログファイルを一括ダウンロードするスクリプト(S3保存版)
• github
• サーバレスフレームワークのサンプルとして、EC2インスタンスのAMIバックアップを作りました。

本年が良い年でありますように。

自分が所有するSnapShotで、AMIがないものを探索するスクリプトを作ってみた

AWSを使っていて、気軽にEC2をスナップショットとったり、消したりしているのですが、
AMI削除したのに、何故かスナップショットが残ることがあり、地味に課金されていたので、
気が付いたら消していたのですが、そもそも自動で消えない仕様ということらしいので、
探索するスクリプトを作成してみました。

スクリプトはここらあたりにあります。

まぁ実はコンパネから全スナップショットを選択して削除すれば、
AMIがあるやつはエラーになるので、結果的に消せるんですが、警告無視した結果もろとも消してしまったので・・・

AWS SDK for RubyでELBの作成や証明書の更新をするスクリプトを作成してみた。

クラウドを使う醍醐味はAPIでインフラを制御できる征服感だとおもっています。

というわけで、自動化、省力化をぼちぼち進めているのですが、前回S3＋CloudFrontをやったので、

今度はELBに挑戦です。

といっても本業ではまだ実は使ったことがなかったりしますが・・・

今回もAWS SDK for Ruby V2をつかっています。

ELBの証明書更新作業は、早くAWS Certificate Managerが東京リージョンに来てくれれば開放されるのですが・・・

ELBの証明書更新スクリプトはここにあります。

また、ELBの作成スクリプトはここです。

EC2の作成スクリプトは既につくってあるので、これと組み合わせればちょっとしたオーケストレーションツールが作成できます。

あとはオートスケールとAnsibleスクリプトを組み合わせれば、ほぼ自動化できます。パチパチ～

ま、効率上げても首絞まるだけなんだけどね（ボソッ・・・

AWS SDK for Rubyを用いて、S3+CloudFrontでCache Distributionパターンを構築するスクリプトを作成してみた。

相変わらず慢性的なアレやコレやで、無駄に忙しいのですが（ぉぉ
そんな中、忙しければ省力化、自動化だろ。ということでS3＋CloudFrontでCache Distributionパターンを構築するスクリプトを作成しました。

CloudFrontって、設定箇所がかなり多く、またS3との連携設定もあり、どうしても手数が多くなり、
手順書を作成してもなかなか大変です。
しかも、設定変更したら反映されるまで数十分待つ羽目になりますしね。

こんな所は自動化するに限ります。
インフラ構築を自動化するツールは俗にオーケストレーションツールと呼ばれ、
AWS純正のCloudFormationとか、Terraformとかがあります。
Terraformは昔試してみたことがあるのですが、バグが酷かったり、メッセージが謎だったりと。ちょっと実用に耐えれないな。という印象があるので、以前から興味があったCloudFormationを試してみました。
・・・・が、一般人の私には山のようなJSONをインデントを見失わず手打ちするのは無理がありすぎました。
RubyっぽくかけるDSLも有るみたいなのですが。

なので、早々にあきらめて、API叩くことにします。
ですが、AWS SDK for RubyのVer2は正直使いづらい使い方がリファレンスを見ても良く分からないし、
ましてCloudFrontの設定パラメタの多いこと！
おまけにマネコンでの設定名称とパラメタの名称が違っていたりするし（汗
というわけで、CloudFormationの付属のツール（？）である、cloudformerを使いました。

このCloudFormerというのは、構築済みのAWS環境を解析し、CloudFormationで使用するJSON形式で出力するツールです。
ただし、ツールといってもEC2インスタンス内で動くアプライアンスみたいなもので、t2.mediumインスタンスだったりするので地味に課金が怖かったり（ぉ

使い方はクラスメソッドさんのブログを参考にしていただければいいのですが、1点。
AWSではデフォルトのVPCが存在します。
このVPCを削除して自前でVPCの設定をした場合、CloudFormerは起動に失敗します。

対処法は簡単で、バージニアなど別リージョンで起動させる。です。
CloudFormerはWebからアクセスするアプリなので、実はリージョン依存ではありません。

S3＋CloudFrontの環境をAWS上にマネコンでぽちぽち作成後、CloudFormerでJSON化すると、
こんな感じになります。
まぁマネコンもCloudFormationも裏ではAPIを叩いているでしょうから、内容がほぼAPIと対応します。

これで、必要なパラメタとその内容が分かりました。あとはAPIリファレンスを参照しながらコーディングするだけです。

というわけで、作成したスクリプトはこちらになります。

最後に、かかった課金のほうですが、現時点で0.14$となっています。
CloudFormerは削除すると関連するリソースを全て削除してくれるのですが、デバックのためS3やCloudFrontを消したり追加したりした結果地味にカウントされます。

このあたり、さくらのクラウドみたいにAPI試すようサンドボックス環境が欲しくなります。
あと、AWSさん。マネコンで作成したら、その操作をJSONなりでダウンロード出来る機能つけてくれませんかねぇ。
CloudFormerでは全部が解析できるわけではなさそうで、それであれば、ウイザードの段階からJSONなりを作成してくれればいいのにな。

AWS SESのバウンスメール通知をSNSで受けて、それをSQSと連携させてみた

AWSではSESと呼ばれるメールサービスがあります。Azureで言うところのSendGridみたいな、APIからメールが送れたり、MTAからリレーできたりする便利な奴なんですが、スパムに利用されないように、バウンスメール（ようするに不達で帰ってくるメール）が多いとスパマーと判定されてペナルティを食らうらしい・・・
参考：Amazon SES のバウンスに関するよくある質問

そのための仕組みとして、SESではバウンスメールアドレスを通知する仕組みがあります。
この仕組みを利用して、SNS経由で用意したAPIを叩いてDBの消しこみをする。なんて例が良く出てきます。
たとえばこんなのとか。

ただ、当然というか、外部にAPIを晒すという事は、悪戯されたり不正アクセスをされたりするわけで、ちゃんと電子証明書の検証をしないといけない。

これはこれで面倒そう・・・・
なので、SNSからさらにSQSを連携させ、バウンスメール処理をキューで処理する仕組みを構築してみました。
キューに貯める事により、複数台のサーバで並列して処理したりできますし、APIを作ったり外部へ晒したりしなくてよいです。

具体的な構築手順は例によってWiKiに記載しています。

今回、あまりAWS SDK for RubyでSQS処理するプログラムを見かけなかったので、作ってみました。
勿論SDKのVer2対応です！！

AWS Certificate Managerを試してみた。

Amazonが無料の証明書サービス、AWS Certificate Managerが発表されたので、早速試してみました。
具体的な取得方法については、例によってWiKiにまとめています。
アスタリスク証明書も取得できるのが地味にうれしいです。

基本的には普通のドメイン認証と同じ手順なのですが、確認するメールアドレスを選択できない。という地味な制限のため、転送設定とかCatchAll的な設定をしていたりするとちょっと悲しいことになります・・・・

まだ始まったばかりのサービスですので、バージニアリージョンしか使えません。
そして、取得した証明書を外部にDLすることは出来ません。
使えるのはELBとCloudFrontなどACMに対応しているもののみとなります。
つまり、EC2に入れて使う。なんてことは出来ません。
また、現在のところ使えるのはバージニアリージョンのみであり、東京リージョンのELBにセットすることは出来ませんでした。
ELBにセットしてアクセスしてみました。ちゃんとAmazonになっています。

証明書の有効期限は1年固定のようですが、自動的に更新されるそうです。
また、証明書の発行自体は無料ですが、CloudFrontにセットしたときの料金は通常通りかかると思います。（未確認ですが、SNI証明書にすれば通信料のみ課金だと思います。）

rsyncがあればlsyncもある。

ロードバランサ配下などで、複数のサーバ間でコンテンツの同期を取りたいときがあります。
いつまでたってもAWSのEFSが東京リージョンにこないし、個人的にNFSには過負荷時の謎の挙動など辛い思い出が多い。
かといって、Cronで定期的にrsyncというのもラグがあるしスマートじゃないなと調べていたところ、
ぴったりな記事を発見！

rsyncがあるんだからlsyncがあっても不思議ではないよね。と思いながら、いざ検証しようとするも、lsyncのバージョンが違うので、設定ファイルの記述がそもそも違う。とか実はrsyncやxinetdはいらないんじゃないか？とか色々はまりました・・・

同期の罠については、ここが参考になりました。
また、lsyncの2.1系での設定についてはここが参考になりました。

いきなり双方向同期の設定は理解するのが難しいので、まずは検証ということで片方の同期を例に挙げます。

構成としてはこんな感じです。

サーバOYABUNに加えられた変更（追加や削除、編集など）を検知し、KOBUNサーバに反映させます。

反映させる通信手段としてSSH経由でrsyncかけます。ので、OYABUNとKOBUNの間でSSH接続を許可するのと、KOBUNサーバへ接続する秘密鍵をOYABUNサーバに設置しておきます。

ここまでがKOBUNサーバでやっておくことです。

以下はOYABUNサーバでの作業になります。

まずは、OYABUNサーバにlsyncをインストールします。

yum install --enablerepo=epel lsyncd

次にlsyncの設定をします。

前提条件として、

• KOBUNへ接続するユーザはwebmaster
• 秘密鍵はOYABUNサーバの/home/webmaster/.ssh/webmaster_id_rsa
• 同期するディレクトリは/var/www/html/images/と/var/www/somecontents/の２つ

とします。

/etc/lsync.confに設定がありますので、以下のように設定します。

KOBUNのところは実際はIPアドレスになります。

settings{
        statusFile = "/var/log/lsyncd.status",
        logfile = "/var/log/lsyncd/lsyncd.log",
        nodaemon = false,
        insist = 1,
}
sync {
    default.rsync,
    delay = 0,
    source = "/var/www/html/images/",
    target = "webmaster@KOBUN:/var/www/html/images/",
    delete = 'running',
    rsync = {
        rsh = "/usr/bin/ssh -i /home/webmaster/.ssh/webmaster_id_rsa -o StrictHostKeyChecking=no"
    }
}
sync {
    default.rsync,
    delay = 0,
    source = "/var/www/somecontents/",
    target = "webmaster@KOBUN:/var/www/somecontents/",
    delete = 'running',
    rsync = {
        rsh = "/usr/bin/ssh -i /home/webmaster/.ssh/webmaster_id_rsa -o StrictHostKeyChecking=no"
    }
}

このように、syncのところに複数書くと、複数のディレクトリを監視し、同期を取ることが出来ます。

今回はデーモンで動かしたいので、nodaemonはfalseにしています。

なお、rsync以外にも、S3で同期など色々出来るようです。参考

また、設定ファイルの=はちゃんと両端にスペースを入れないと反映されなかったり挙動がおかしくなるので注意です。あとrsyncと同様最後は/で終わらせておくのが無難です。

設定が終わりましたら、起動と自動起動設定をします。

/etc/rc.d/init.d/lsync start
chkconfig lsync on

では、OYABUNサーバの/var/www/somecontentsに何か適当なファイルを作成してみましょう。

ほぼリアルタイムでファイル作成を検知し、rsyncにてKOBUNサーバに反映されます。

この設定をKOBUN側からOYABUN側に設定すれば、双方向同期ができます。

・・・が、2台ならいいですが、3台以上になると、双方向同期はカオスになるので、素直にNFSなりにしましょう。

sendmailでリレーサーバを構築するメモ

AWSなどで、ロードバランサ配下に複数台のサーバを配置し負荷分散と冗長構成をとった場合、はて、メールの送信どうするんだ？と悩んだのでメモ。
AWSに限らず、CentOSなんかで、メール送信をリレーサーバ経由にしたい場合にも使えます。


ロードバランサ配下のサーバにそれぞれEIPというかグローバルIPを割り当ててもいいのですが、
オートスケールをした場合グローバルIPが不定だったりして、SPFどうするんだ？という問題があります。
じゃぁAWSのSESつかうか。という方法が一番いい気がするのですが、バウンスメール処理をちゃんとしないといけないなど、結構手間な感じです。
GmailやSendGridなどをつかうのもいいのですが、手っ取り早く解決するにはメールサーバ用EC2を立てて、そこを中継させてあげればよさそうです。
また、その場合各サーバにはEIPを割り当てなくてもいい（別途SSH接続用踏み台サーバがいりますが）ので、セキュリティ面でもよさそうです。

まずは、メールリレーサーバにするEC2を用意します。
AmazonLinuxでは、デフォルトでSendMailが起動しています。初期設定では自分自身から送信のみできる状態になっています。

まずは、sendmailの設定である、sendmail.cfを作成するためのツールをインストールします。

 yum -y install sendmail-cf m4

次に念のためsendmail.mc及びsendmail.cfのバックアップを取ったうえで、sendmail.mcの設定を以下のように修正します。

dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

頭にdnlをつけてこの設定を無効化することにより、よそからのメール転送を許可するようになります。

しかし、このままですと、だれでもこのサーバを踏み台にメールを送れる要するにオープンリレーサーバ状態になりますので、リレーを受け付けるサーバを制限します。

なお、この設定はsendmail.mcに以下の記述がある前提になります。

FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl

同じディレクトリ(/etc/mail/)にaccessというファイルがあります。(access.dbではありません)

これに

connect:10.0.0.100 RELAY

のように、リレーを許可するサーバのIPを列挙します。

調べた感じ、10.0.0.0/24のような指定はできないようですが、

connect:10.0.0. RELAY

のような指定はできるようです。

さて、ご存知の通り、sendmailはPostfixなどと違い、設定ファイルをコンパイル（？）しないといけません。

以下のコマンドを実行し、sendmail.cfファイルを作成します。

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

作成したら、sendmailを再起動させ、設定を有効化します。

/etc/rc.d/init.d/sendmail restart

では、実際にリレーメールサーバにメールを送信し、リレーされることを確認します。

自分はお手軽にrubyでメール送信プログラムを作成しました。

# -*- encoding: utf-8 -*-
require 'mail'
mail = Mail.new
options = { :address => "10.0.0.20", #リレーメールサーバのIP
            :port => 25,
            :authentication => :plain,
            :enable_starttls_auto => true }
mail.charset = "utf-8"
mail.from "test@example.com"
mail.to "hogehoge@gmail.com"
mail.subject "タイトル"
mail.body "本文"
mail.delivery_method(:smtp, options)
mail.deliver

これをリレーする元サーバ、つまりaccessファイルで許可したサーバ内で実行します。

DNSの設定やSPFの設定が正しければ、メールが届いているはずです。

ちゃんと中継されたかはメールのヘッダ情報にリレーメールサーバのIPが記録されているはずですので、そこで確認する事が出来ます。

AWS-SDK For Ruby V2に対応してみた。

AWS SDK For Rubyのバージョンが2にあがってはや一年がたとうとしています。
AWSなどのクラウドサービスはAPIを叩いて自動化が出来るのがメリットのひとつでして、
自分も簡単なスクリプトを作成して自動化、省力化をしています。

そんな中、AWS SDK For Rubyのバージョンが２に上がり、これまでのバージョン１とは互換性がない為、絶賛稼働中のものや、作りこんだChefのレシピなどは簡単に移行できませんし、
テストも容易ではなかったりします。

しかし、いつまでもバージョン１を使い続けると、いつかは切られてしまうので、練習がてらGitHubにあげているものをバージョン２に対応させてみました。

一応バージョン１とのDIFFはこの辺りにあります。
バージョン２でcoreとリソースに分離したのですが、いまいちリソースの使い方というか使い勝手が分からなかったので、coreのみで作成しています。

バージョン１と２での大きな違いは、バージョン１では大抵戻り値としてインスタンスのオブジェクトが返っていたのですが、バージョン２では単なる構造体が返って来ます。
あと、バージョン１ではステータスの変化を検知するためにウエイトをかけたりループをまわしたりしていましたが、バージョン２ではwait_untilという専用メソッドが追加されています。

今まではいろんなリソースタイプやコレクションをそれぞれ組み合わせて叩いていたので結構大変でしたが、バージョン２では引数として文字列か数値がとシンプルになっていますし、Filterオプションが強力になっているので、全体的に短い行数で書けるようです。
ただ、今まで戻り値がオブジェクトだったので、チェーンメソッドが書けたのですが、そういうわけには行かなくなりました。

ただ、バージョン１と２でのメソッドの対比表みたいなものは無いので、バージョン１でのこのメソッドに該当するメソッドはどれか探すのが地味に大変です。
同じメソッド名のものもあれば、ec2.instance.create->ec2.client.run_instancesのようにまったく違うものもあります。

単純に置き換えは難しそうですが、この記事が少しでも役に立てればと思います。

AWSのMicrosoft-ADを試してみた。

2015/12/3に発表されたAWSのクラウド上のマネージド型MicrosoftActiveDirectoryを触ってみました。
といっても、触った感じSimple-ADとの違いが分からない（汗


例によってWiKiにまとめています。

AMIからEC2インスタンスを起動するスクリプトを作ってみた。

毎回毎回AmazonLinuxのAMIからぽちぽちEC2インスタンスを作成するのが面倒なのでスクリプトを作りました。

https://github.com/akira345/create-ec2

かなり荒削りだけど、とりあえず目的は達成。

コードはこのあたりから参考にしました。

https://github.com/･･･/master/bin/ec2_create_instance.rb

インフラの自動化って楽しいですね！

（・・・人ふやせよ・・・）

最近自動化がマイブーム。

明日の早朝に対応してそのまま出社。という例によってアレな事案のため、
某所の結婚式二次会的なイベントで岡山へ行く電車内で開発したEBSのディスク容量を拡張してくれるスクリプトです。

https://github.com/akira345/ebs-extension

ただし、作りがおかしいのか、AWS-SDKの仕様なのか、AWSコンソール上ではステータスが変わっているのに、時々ステータスが取得できない。スクリプト処理中にAWSコンソール上で別のEBS操作すると、それのステータスがどうも帰ってきているっぽい。など、若干怪しい部分があるのと、resize2fsなどは手動でやる必要があります。

しかし、インフラ自動化って楽しいですね。

SimpleADでWindowsを参加させる

あけましておめでとうございます。

新年早速ですが、昨年検証したかったのに日々の業務に忙殺されていじれなかったAWSの新サービス、SimpleADをテストしてみました。

構築手順などは別途WiKiにまとめてあります。

あ、個人的理由により、AWSのデフォルトVPCを使っていません（汗

デフォルトのVPCを消すと色々苦労するらしいけど・・・

注意点としては、VPCのDHCPオプションでDNSの設定をするので、VPC全体に影響する点と、
RDSのMulti-AZと同様異なるAZのサブネットが必要というところでしょうか。

ユーザ認証だけでしたら、サクッと出来た感じです。
嵌まりどころというか、勘違いしてたのは、ユーザ登録などもAWSのコンパネ上からできると思っていたのですが、そうはいかないようで、ユーザの追加削除には別途ドメインに参加したWindowsマシンが必要です。

Azureと比べまして、AWSはインフラ屋さんよりなんだなと感じますね。
最初にVPCやサブネット、ルーティングやセキュリティグループなどインフラというかネットワーク周りを少しかじっていないと厳しい気がします。

逆にAzureは割と簡単にできるんですが、細かい設定をやろうとすると、すぐPowerShellが出てきたりとプログラマよりなんだなと。ネットワークやIPとかをあまり気にしなくても構築できてしまうあたりは流石というかMSらしいというか（笑）
Azure Webサイトなんて、スケールするレンサバと思えばすごく便利なんですよね。
お値段はレンサバと思ってはいけませんが・・・

AWSのEC2インスタンスをスケールアップ、ダウンするRubyスクリプトを作成してみた。

GW中のサーバ高負荷に対応するため、実質自宅待機を命ぜられたので昨夜ついカットなって作ってしまった。(ほぼ丸パクリですがw)
AWSでオートスケールでない単独サーバをいったんストップし、インスタンスタイプを変更して起動させます。
ソースはここにおいておきます。



これのいい点は、オートスケール組める程の予算がない又はアプリの制約で複数台構成が取れない場合で、予めイベントなどでアクセス集中が予想される場合、従来は深夜ゼロ時に手動切り替えしていたものがスケジュール化出来ます。