DKIM導入
概要
送信したメールがSPAM扱いされるので、証明書による送信元証明を付加しました。
インストール
インストール
sudo apt-get install opendkim opendkim-tools
ディレクトリ用意
mkdir -p /etc/opendkim/keys/naked.com
鍵生成
cd /etc/opendkim/keys/naked.com opendkim-genkey -d sample.com -s dkimselector chown -R opendkim:opendkim /etc/opendkim/keys
サーバ設定
Syslog yes SyslogSuccess yes LogWhy yes UMask 002 Mode sv Domain naked.com Selector default SOCKET inet:8891@localhost UserID opendkim:opendkim KeyTable refile:/etc/opendkim/KeyTable SigningTable refile:/etc/opendkim/SigningTable InternalHosts refile:/etc/opendkim/TrustedHosts
SOCKET="inet:8891@localhost"
KeyTable設定
dkimselector._domainkey.naked.com naked.com:dkimselector:/etc/opendkim/keys/naked.com/dkimselector.private
SigningTableの設定
*@naked.com dkimselector._domainkey.naked.com
TrustedHostsの設定 内部でメール転送してくるホストのIPを一つずつ記述する。
10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4 10.10.10.5 10.10.10.6 10.10.10.7 10.10.10.8 10.10.10.9 10.10.10.10 10.10.10.11 10.10.10.12 10.10.10.13 10.10.10.14 10.10.10.15 10.10.10.16 10.10.10.17 10.10.10.18 10.10.10.19 10.10.10.20 10.10.10.21 10.10.10.22 10.10.10.23 10.10.10.24 10.10.10.25 .....
Postfix側の設定
下記を追記
# DKIM smtpd_milters = inet:127.0.0.1:8891 non_smtpd_milters = $smtpd_milters milter_default_action = accept
OpenDKIMを起動、postfix reload
service opendkim start postfix reload
DNS設定
DNSにOpenDKIMの公開鍵を設定
cat /etc/opendkim/keys/naked.com/dkimselector.txt
結果
dkimselector._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC08E9Dos+LX2dZZFwBX2vSTfqAvvsME9rWELT+lxQI+GtuS7ZUIugYEzURX1H1DwDPo+Rm6YRnku9iWX7vdV/CfxFSTbYwwn9XA7DZbGpSCLOS4ySzJJYiOq+cw8Hat17u7pvl6fq4me3NWWCA88XkIVW5HykS5WYBcm3eb9/o1QIDAQAB" ) ; ----- DKIM key dkimselector for naked.com
上記の設定をDNSに設定。あと下記の設定も追加。
Name adsp.domainkey.naked.com Type TXT Value "dkim=unknown"
ゾンビDBの作り方 at GCP
概要
毎朝、前の日に本番DBから取ったバックアップを元に復活するDBをGCPでも作りました。
やってることは、
- mysql止める
- 古いvolumeをアンマウント
- 古いvolumeをdetach
- スナップショットから新しいボリュームを作成
- 新しいvolumeをattach
- 新しいvolumeをマウント
- mysql起動
前提条件
実行シェル
#!/bin/bash date=`date +%Y%m%d%H` DESCRIPTION="db-backup-$date" newdisk="zombi-disk" olddisk="zombi-disk" # Stop mysql sudo /sbin/initctl stop mysql # Unmount sleep 60 sudo /bin/umount -l /var/lib/mysql # Detach old volume sleep 60 gcloud compute -q --project "naked.co.jp:api-project-1234567890" instances detach-disk "zombi-db" --disk "$olddisk" --zone "asia-east1-a" # Delete old volume gcloud compute -q --project "naked.co.jp:api-project-1234567890" disks delete "$olddisk" --zone "asia-east1-a" # Create new DB volume sleep 60 gcloud compute -q --project "naked.co.jp:api-project-1234567890" disks create "$newdisk" --size "150" --zone "asia-east1-a" --source-snapshot "$DESCRIPTION" --type "pd-ssd" # Attach new volume sleep 60 gcloud compute -q --project "naked.co.jp:api-project-1234567890" instances attach-disk "zombi-db" --disk "$newdisk" --zone "asia-east1-a" # Remount volume sudo /bin/mount -a # Start mysql sudo /sbin/initctl start mysql
その他
例によって前処理が終わってない場合があったので適当にsleepを入れています。
ゾンビDBの作り方 at AWS
概要
開発メンバーからの要望で毎日、本番DBから取ったバックアップを元にデータをリフレッシュするDBを作りました。 何度データを壊しても次の朝には復活してるので社内ではコレをゾンビDBと呼んでいます。
やってることは、
1.定期的に取ってるsnapshotからvolumeを作成 2.mysql止める 3.古いvolumeをアンマウント 4.古いvolumeをdetach 5.新しいvolumeをattach 6.新しいvolumeをマウント 7.mysql起動
やりたいことはシンプルですが、awsから必要な情報を取ってくるのが少々面倒です。
前提条件
シェルスクリプト
#!/bin/bash
date=`date +%Y%m%d%H`
DESCRIPTION="DB_backup_$date"
instance=`curl http://169.254.169.254/latest/meta-data/instance-id`
# Create new DB volume
snap=`/usr/local/bin/aws ec2 describe-snapshots --filters Name=description,Values=$DESCRIPTION"*" --query Snapshots[*].SnapshotId --output text`
VAR="$snap"
ary=($VAR)
attach_volume=`/usr/local/bin/aws ec2 create-volume --availability-zone us-east-1d --volume-type gp2 --snapshot-id ${ary[0]} --query VolumeId --output text`
# Stop mysql
sleep 10
sudo /usr/sbin/service mysql stop
#/sbin/swapoff /var/lib/mysql/swap
# Unmount
sleep 10
sudo /bin/umount -f /var/lib/mysql
# Detach old volume
sleep 10
detach_volume=`/usr/local/bin/aws ec2 describe-volumes --filters Name=attachment.instance-id,Values=$instance Name=attachment.device,Values=/dev/sdf --query Volumes[].Attachments[].[VolumeId] --output text`
/usr/local/bin/aws ec2 detach-volume --volume-id $detach_volume --instance-id $instance
# Attach new volume
sleep 60
/usr/local/bin/aws ec2 attach-volume --volume-id $attach_volume --instance-id $instance --device /dev/sdf
# Remount volume
sleep 60
sudo /bin/mount -a
# Start mysql
sleep 10
sudo /usr/sbin/service mysql start
# Delete old volume
/usr/local/bin/aws ec2 delete-volume --volume-id $detach_volume
その他
前の処理が完全に終わってなかったりするので適当にsleepを入れてます。
capistranoでデバッグのため、ダミータスクを動かしてみる
概要
デプロイの処理を1個づつ試しながら確認したい場合が多々有ります。 そんな時はCapfileにダミータスクを追加して、そのタスクを直接動かして動作を確認してみましょう。
Capfile
例)GCPのインスタンスリストをコマンドから取得する処理を確かめてみる。
namespace "hoge" do
task :moge do
run_locally do
value = %x[ gcloud compute instances list ]
print value,"\n"
end
end
end
実行
怖いので実行するstageはstagingとかが良いと思います。
bundle exec cap staging hoge:moge
結果
コマンドの結果が変数に入って出力できました。
$ bundle exec cap staging hoge:moge DEBUG [9cfe186a] Running /usr/bin/env [ -d /usr/local/rbenv/versions/2.2.3 ] on staging DEBUG [9cfe186a] Command: [ -d /usr/local/rbenv/versions/2.2.3 ] DEBUG [9cfe186a] Finished in 0.296 seconds with exit status 0 (successful). nativeapi-fix nativeapi-newrelic nativeapi-us-201510271040-bpvl nativeapi-us-201510271040-li6e nativeapi-us-201510271040-ptgw nativeapi-us-201510271040-vqhe nativeapi-us-201510271040-vy9v nativeapi-us-201510271040-w804 nativeapi-us-201510271040-wo6y nativeapi-us-201510271040-xqg8 nativeapi-us-201510271040-y0f4 nativeapi-us-201510271040-y5cf nativeapi-us-201510271040-y79p nativeapi-us-201510271040-ye7b nativeapi-us-201510271040-yvoe nativeapi-us-201510271040-zgbc
Google cloud shell使ってみました
Google cloud shellって？
日本語だと下記のページで概要を掴めるかと思います。
Google Cloud Platform Japan 公式ブログ: Google Cloud Shell の無料期間が 2016 年末まで延長
使ってみました
特に設定の必要も無くGCPのコマンドが使えますし、普通にlinuxとしても使えてSSHで他のサーバにログインなんてことも出来ました。
cronも使えました
crontabで一分ごとにloglogというファイルに日付を出力してみました。 コンソールからログアウトしている時間帯もちゃんと動いていたようです。
$ cat loglog Wed Dec 23 09:23:01 UTC 2015 Wed Dec 23 09:24:01 UTC 2015 Wed Dec 23 09:25:01 UTC 2015 Wed Dec 23 09:26:01 UTC 2015 Wed Dec 23 09:27:01 UTC 2015 Wed Dec 23 09:28:01 UTC 2015 Wed Dec 23 09:29:01 UTC 2015 $ date Wed Dec 23 18:29:42 TLT 2015
あとがき
定期的にGCPのコマンドが実行できるので、バッチサーバでやっていた定期バックアップとかの処理をgoogle cloud shellにまかせるとサーバレス環境に一歩近づけそうですね。
local-ssdを積んだインスタンスのサイズ変更はできない
概要
local-ssdを積んだインスタンスのサイズ変更はできないので、気をつけましょう。
（local-ssdについては下記を見てもらうと雰囲気はつかめるかと思います。）
Google for Work Japan 公式ブログ: [GCP] Local SSD がどなたでも利用できるようになりました。
そもそもstop出来ない
local-ssdを積んだインスタンスはstopしてサイズ変更しようとしても、そもそも「stop」がグレーアウトして実行できません。
強引に起動しようとすると
マネージコンソールからはstop出来ないようになっていますが、実際にインスタンスにログインしてshutdownすることは可能です。しかし、起動しようとすると下記のようなエラーが発生します。
どうやら一度落とすと再度立ち上げることはできないようです。
まとめ
爆速で有名なGCPのlocal-ssdですが、local-ssdを積んだインスタンスはサイズ変更ができなくなるので使いどころを考えて利用しましょう。
あとがき
ちなみにどうしてもインスタンスサイズを変更したければ、
という手も考えられますが、面倒ですね。
GCPでサブネットが使えるようになった。
概要
AWSでは「VPC内でサブネットを切ってAPPのネットワークとDBのネットワークを分ける」みたいなことができますが、GCPでは出来ませんでした。が、いつの間にかGCPでもサブネットを切ることが出来るようになったようです。
GCPのnetworks
- 新規作成時だけでなく、後からメンテナンスも出来るようです。
ただし、昔作ったネットワークは置いてけぼり。
- しかし、以前に作ったネットワークを見てみると・・「add subnetworks」が無い・・・。既存ネットワークをサブネットで切れないのは既にネットワークに散らばったインスタンスのIPをどうするか？が難しいからでしょうかね。
あとがき
引き続き、昔作ったネットワークでもサブネットが使えるようになるのを期待したいところです。
