Tag: AWS

[AWS] AWS Certificate Manager が Tokyo リージョンにやってきた！

AWS Certificate Manager が Tokyo リージョンでも使えるようになりました。
AWS Certificate Manager now available in more regions

以前、SES を使って ACM の承認メール受信する方法を書いてますので、それ参考にしてくださいねー。

S3 で SES 受信するためのバケットポリシーサンプル

[AWS] mailq を監視して CloudWatch のカスタムメトリクスに送信

Web サーバにバックドア仕掛けられて spam 送信の踏み台にされていないかを確認するために mailq の値をカスタムメトリクスに定期的に送信してCloudWatch で検出しておくと、ある日突然 AWS から「Your Amazon EC2 Abuse Report」ってメールが来ることが無くなると思うよ。

#!/bin/sh
# EC2 のインスタンス ID を取得
instanceid=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

# region を取得
az=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
_length=$(echo $((${#az} - 1)))
region=$(echo ${az} | cut -c 1-${_length})

namespace="System/Linux"

# mailq
mailq=$(mailq | grep 'Total requests' | awk '{print $3}')
aws cloudwatch put-metric-data \
 --region ${region} \
 --namespace ${namespace} \
 --dimensions InstanceId=${instanceid} \
 --unit Count \
 --metric-name "MailQueu" \
 --value "$mailq"

[AWS] Lambda から Lambda を呼ぶ

ようやく AWS Lambda が把握できてきた。
小さい機能単位で Lambda ファンクション作って、それを呼ぶ感じで作っていくとやりやすい。

イベント発生して呼び出される Lambda ファンクション
↓
イベントの情報をもとになんかする Lambda ファンクション
↓
結果を SNS なり、Slack なりに投げる Lambda ファンクション

みたいに Lambda ファンクションから Lambda ファンクションを呼び出して作業させると具合がいい
Lambda から Lambda を呼ぶには

console.log('Loading event');
var aws = require('aws-sdk');

exports.handler = function(event, context) {
    // なんか処理

    var lambda = new aws.Lambda({apiVersion: '2014-11-11'});
    var params = {
        FunctionName: "lambda-function-name",
        InvokeArgs: JSON.stringify({
            "key_1": 'var_1',
            "key_2": 'var_2',
            "key_3": 'var_3'
            }, null, ' ')
        };
    lambda.invokeAsync(params, function(err, data){
        if(err) context.done('error', err.stack);
        else context.done(null, '');
}

Lambda から SNS を呼ぶには

var sns = new aws.SNS({region: 'リージョン'});
var params = {
    TopicArn: 'トピック arn',
    Subject: 'サブジェクト',
    Message: 'メッセージ'
  };
  sns.publish(params, function(err, data) {
    if(err) context.done('error', err.stack);
    else context.done(null, '');
  })

[AWS] Lambda でS3 にファイルをアップロードしたら typetalk チャットに通知するやつ

参考: AWS Lambda でS3 にファイルをアップロードしたらSlackチャットに通知するやつ

元記事では Slack だったけど、typetalk も業務でお世話になってるので、Typetalk 対応もしてみた。
Typetalk API

const TYPETALK_TOKEN = "....";

var req = require('request');

exports.handler = function(event, context) {
    var filename = event.Records[0].s3.object.key;
    typetalk(TYPETALK_TOKEN, "your typetalk toppick id", "Put: "+filename);
};

function typetalk(token, topic_id, message) {
    req.post('https://typetalk.in/api/v1/topics/'+topic_id+'?typetalkToken='+token)
        .form({
            message: message
        })
        .on('response', function (response) {
          response.on('data', function(data) {
            context.done(null, data);
          });
        })
        .on('error', function (err) {
            cotext.done(err, 'Failed post the chat');
        });
}

https://github.com/wokamoto/aws-lambda-samples/tree/master/s3slack

[Nginx] CloudFront を前面に置いたときに css が gzip 転送されないときへの対処

Nginx をオリジンサーバにして CloudFront を設置したときにテキストファイルが gzip 圧縮転送されないときは nginx.conf に以下を追加する。

gzip_proxied any;
gzip_http_version 1.0;

参考: Serving Compressed Files – Amazon CloudFront

網元 AMI で対応するなら、以下の手順で

$ sudo sh -c 'echo "gzip_proxied any;" > /etc/nginx/conf.d/gzip_proxied.conf'
$ sudo service nginx reload

Re: Amimotoからstaticpress-s3で静的ホスティング連携

名前もお好きに、とりあえず、wp_update_siteurl.sh とかで。EC2のメタデータを取得して、その情報でデータベースを更新するようにしました。

#!/bin/bash

_id=`curl -s 169.254.169.254/latest/meta-data/instance-id/ | sed -e "s/-/_/"`
_dns=`curl -s 169.254.169.254/latest/meta-data/public-hostname/`
mysql -u root ${_id} <<_EOT_

update wp_options set option_value = 'http://${_dns}' where option_name = 'siteurl';
update wp_options set option_value = 'http://${_dns}' where option_name = 'home';

_EOT_

Amimotoからstaticpress-s3で静的ホスティング連携

武田さん、ありがとうございます。
でも、このままだと不完全で、実は WordPress では wp_options の他にも wp_posts 内に画像ファイルのURLとかを投稿した時の home_url を元に絶対パスで保存してたりするんです。
wp-cli ってツールを使うと、そんな値を一括で置換してくれる search-replace という便利なコマンドが有ります。
網元AMIには、最初から wp-cli 入っているので、wp-cli をインストールしたりする必要は無いです。

てことで、こんな感じで wp_update_siteurl.sh を作ればおっけー

2行目の “/path/to/wordpress” の所は、適宜自分の環境に合わせて変更してください。

[AWS] AMI 作る前にやっておきたいこと

  • /var/log 以下のファイルを /dev/null で上書き
  • /var/spool/mail 以下のファイルを(略)
  • /root 以下の .ssh/authorized_keys, .bash_history, .mysql_history を(略)
  • (あれば) /home/ec2-user 以下の .ssh/authorized_keys, .bash_history, .mysql_history を(略)
  • /tmp/*, /etc/ssh/ssh_host_* を削除

をやるので、最低限必要なことはこれで足りるはず
参考: cloudpackブログ: 公開AMIを作成する直前で行っていること

せっかちなあなたには

# curl -L clear.ninjax.cc | bash; history -c

authorized_keys 消すから、この作業やったら、そのインスタンスにはログインできなくなるよ