Amazon SESではドメインの認証をすることで、そのドメインからのメール送信ができるようになる。
ドメインの認証をするにはSESに指定された値をDNSのTXTレコードに設定する必要がある。
下記のように設定しなさい、と指示されるがValue-Domainの管理画面から設定する場合はどうするのか?
Name: _amazonses.example.com
Type: TXT
Value: <認証コード>
結論。
TXT _amazonses.example.com <認証コード>
で、認証が通りました。
SPFの設定だと v=~~ ~all とか書式があるから、なにかそういう書式が必要なのかと思って迷いました。
DNSは苦手です。
2015年4月26日日曜日
さくらのメールを使おうとしたら「550 5.7.1 Command rejected」と言われてメールを送信できなかった。vultrのせいだった。
さくらのメールボックスを借りてPEAR::Mailでメールを送信しようとしたところ、メールが送信できず困った。
PEAR::MailはMail::factoryの第2引数に渡すパラメーターで 'debug' => true を設定することでSMTPのやりとりを出力してくれる。
これでやりとりを見てみると Authentication OK という文字が見えることから、認証は成功しているようだが、そのあとすぐに「550 5.7.1 Command rejected」というメッセージがでて接続が切れていた。
なんとも不可解な動作にずっと悩んでいたが、どうもvultrというクラウドを使っていたことが原因のようだった。
こちらのブログを見つけられなかったらずっと悩んでいたかもしれない。感謝。
Vultrからメールが送れないのでSendGridを使う
このブログのリンク先の公式サイトにて、下記のメッセージを確認。
解決策としては、やはりクラウドサービスを利用することにした。AWSは使い慣れているのでAWSのSESを使うことにした。EC2以外から使う場合は無料枠がないようなのでちょっと微妙だけれどほとんどメールなんて飛ばないだろうからいいやという判断。
PEAR::MailはMail::factoryの第2引数に渡すパラメーターで 'debug' => true を設定することでSMTPのやりとりを出力してくれる。
これでやりとりを見てみると Authentication OK という文字が見えることから、認証は成功しているようだが、そのあとすぐに「550 5.7.1 Command rejected」というメッセージがでて接続が切れていた。
なんとも不可解な動作にずっと悩んでいたが、どうもvultrというクラウドを使っていたことが原因のようだった。
こちらのブログを見つけられなかったらずっと悩んでいたかもしれない。感謝。
Vultrからメールが送れないのでSendGridを使う
このブログのリンク先の公式サイトにて、下記のメッセージを確認。
Do you allow outbound SMTP?しかし認証までうまくいくのは何故なのか謎すぎる。接続もできない状態であればすぐ気づいたのだけど。。。
Outbound SMTP is blocked by default. To lift this restriction, you must contact our support team and fill out an authorization form.
解決策としては、やはりクラウドサービスを利用することにした。AWSは使い慣れているのでAWSのSESを使うことにした。EC2以外から使う場合は無料枠がないようなのでちょっと微妙だけれどほとんどメールなんて飛ばないだろうからいいやという判断。
2015年4月24日金曜日
Androidでリンクを強制的にChromeで開く方法
リンクを強制的にChromeで開く方法を30分くらい探しまわったところやっとこさStackOverflowで見つけた。
http://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome
とても助かります。。。
フォーマット:
<a href="intent://<URL>#Intent;scheme=http;package=com.android.chrome;end">
実例:
<a href="intent://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome#Intent;scheme=http;package=com.android.chrome;end">テスト</a>
強制的にChromeで開くのではなく、ユーザーにURLを開く方法を選択させる方法。
<a href="intent://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome#Intent;scheme=http;action=android.intent.action.VIEW;end;">テスト</a>
Chromeでしか動かないWebアプリに飛ばす場合なんかに使いたいですね。
ちゃんと理解すると色々応用が効きそうです。
http://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome
とても助かります。。。
フォーマット:
<a href="intent://<URL>#Intent;scheme=http;package=com.android.chrome;end">
実例:
<a href="intent://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome#Intent;scheme=http;package=com.android.chrome;end">テスト</a>
強制的にChromeで開くのではなく、ユーザーにURLを開く方法を選択させる方法。
<a href="intent://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome#Intent;scheme=http;action=android.intent.action.VIEW;end;">テスト</a>
Chromeでしか動かないWebアプリに飛ばす場合なんかに使いたいですね。
ちゃんと理解すると色々応用が効きそうです。
2015年4月22日水曜日
Docker を利用した Web アプリケーションのデプロイ(私の場合)
先日、「クックパッド開発者ブログ」で「Docker を利用した Web アプリケーションのデプロイ」という記事があがっていた。
僕の関わっているプロダクトでもDockerを採用していて、ほとんどデプロイの仕方が同じだった。
・Nginxもコンテナとして起動している
・UnixソケットではなくコンテナのIPを直接してアプリケーション・サーバーと繋げている
というところ。
あと環境変数の共有とかはいまのところ必要性を感じていないのでやっていない。
うちのNginxの設定はちょっとトリッキーかもしれない。
設定ファイルはerbテンプレートから出力する。変数は環境変数として持っておく。
Nginxの向き先を新しいアプリケーション・サーバーに向けるスクリプトはこんな感じだ。
そしてこれがNginxの設定ファイルのテンプレートの一部
Nginxに限らず多くの設定ファイルがerbテンプレートを使用している。
基本的に設定の変数には環境変数を使っていきたいと考えたが、多くの設定ファイルは環境変数を参照するといったことはできない。sedなどでは対応しにくいパターンもある。なのでなるべく柔軟に対応できるようにテンプレートシステムを使うことにした。erbにこだわりがあるわけではなくphpでもよかったと思う。
最初に導入したのがruby製であるfluentdの設定ファイルを作成していたときなので自然と?erbになってしまっただけだ。
だから新しいAPIサーバーをデプロイするには下記のようなコマンドを実行するだけでいい。(versionはコンテナ名のSuffixになる)
ansible-playbookを実行するWebフロントエンドも開発済みで開発環境では既にAnsibleのコマンドを叩く必要もないところまで自動化できている。
ソースを修正して環境に反映するのには下記の手順が必要になる。
たった1行のコード修正であろうと 2~4 の手順にどうしても時間がかかってしまう。
git pullするだけで反映が終わるような仕組みも用意すべきか否か悩んでいる最中だ。
僕の関わっているプロダクトでもDockerを採用していて、ほとんどデプロイの仕方が同じだった。
私の構成
クックパッドさんと異なる点としては・Nginxもコンテナとして起動している
・UnixソケットではなくコンテナのIPを直接してアプリケーション・サーバーと繋げている
というところ。
あと環境変数の共有とかはいまのところ必要性を感じていないのでやっていない。
うちのNginxの設定はちょっとトリッキーかもしれない。
設定ファイルはerbテンプレートから出力する。変数は環境変数として持っておく。
Nginxの向き先を新しいアプリケーション・サーバーに向けるスクリプトはこんな感じだ。
# switch.sh
export WEBAPP_HOST=${1}
erb /docker/etc/nginx.conf.erb > /etc/nginx/nginx.conf
/etc/init.d/nginx reload
そしてこれがNginxの設定ファイルのテンプレートの一部
#
/docker/etc/nginx.conf.erb
location / {
proxy_pass http://<%= ENV['WEBAPP_HOST'] %>/;
}
Nginxに限らず多くの設定ファイルがerbテンプレートを使用している。
基本的に設定の変数には環境変数を使っていきたいと考えたが、多くの設定ファイルは環境変数を参照するといったことはできない。sedなどでは対応しにくいパターンもある。なのでなるべく柔軟に対応できるようにテンプレートシステムを使うことにした。erbにこだわりがあるわけではなくphpでもよかったと思う。
最初に導入したのがruby製であるfluentdの設定ファイルを作成していたときなので自然と?erbになってしまっただけだ。
実際のオペレーション方法
基本的なオペレーションはAnsibleで包んでいる。だから新しいAPIサーバーをデプロイするには下記のようなコマンドを実行するだけでいい。(versionはコンテナ名のSuffixになる)
ansible-playbook -i hosts/production playbooks/api-server-start.yml -e "version=1"
ansible-playbook -i hosts/production playbooks/reverse-proxy-switch.yml -e "version=1"
ansible-playbookを実行するWebフロントエンドも開発済みで開発環境では既にAnsibleのコマンドを叩く必要もないところまで自動化できている。
課題
Dockerによるデプロイ体制は整ってきたが、気になっているのが修正の反映をするのにかかる時間だ。ソースを修正して環境に反映するのには下記の手順が必要になる。
- ソースを修正する
- Dockerイメージをビルドする
- docker pushする
- docker pullする
- イメージを起動する
- リバースプロキシの向き先を変える
たった1行のコード修正であろうと 2~4 の手順にどうしても時間がかかってしまう。
git pullするだけで反映が終わるような仕組みも用意すべきか否か悩んでいる最中だ。
2015年4月21日火曜日
Materialize - マテリアルデザインのためのCSSフレームワーク
Materialize
http://materializecss.com/
Bootstrapに飽きてきたので別の何かを探していて行き着いたのがMaterializeだった。
マテリアルデザイン用のCSSフレームワークだとGoogleが作っているPolymerがあるけどシングルページアプリケーションが前提の設計になってて使いにくい。
さらにBootstrapみたいなグリッドシステムがないのでグリッドシステムが欲しい場合は別途導入する必要がある。
Materializeはシングルページではないウェブアプリケーションでも使えてグリッドシステムも備えている。
Material UIという競合フレームワークがあるけどReactベースなので単純に適用できない。
2015年4月7日火曜日
登録:
投稿 (Atom)