ALBでSSL TerminateしているEC2で稼働するfuelphpをいい感じに動かしていい感じにhttpsで喋らす方法なお俺は喋るのが下手です

俺です。

ちょっとだけハマったピーエッチピーネタです。

ALB/ELB ClassicでSSL Terminateしている環境で動作するFuel PHPなWebページがあったときに、
トップページはhttpsでアクセスできるのに、他のページに遷移しようとするとhttpになっちゃうって現象たまーにありますよね。
そんなときはallow_x_headersでXヘッダを利用できるよう、有効にしておきましょう。

  • fuel/app/config/config.php
security.allow_x_headers

ドキュメントはこれ

おわり

続きを読む

private docker registry のはまりどころ(S3連携、SSL)

AWSでprivate docker registryをコンテナで立てた際のハマったポイントをメモ。

ケース

・AWS EC2(Amazon Linux)上にコンテナで実現
・コンテナイメージはdocker registry 2.1
・ボリュームはS3に設定
・SSLはオレオレ証明書で対応
・外部インターネットとの接続は原則ない(クローズド環境)

ハマった点

① docker push/pullで以下のようなエラーとなる

x509: certificate signed by unknown authority

opensslでオレオレ証明書(crtファイル)を作成し、pull/pushするクライアント側に格納するが、/etc/docker/certs.d/配下に格納してしまうと、dockerがOSのroot証明書を参照しなくなり、S3など他のSSL接続ができなくなる。
今回のようにボリュームをS3に指定する場合は特に注意が必要。
crtファイルは[registryのドメイン名].crtとして、/etc/pki/ca-trust/source/anchors配下に格納する。

その後、設定を反映し、dockerを再起動する。

sudo update-ca-trust
sudo service restart docker

これでエラーは解決した。

② docker push/pullでio.timeoutとなる

SSLの設定が解決したところで、クライアントからpush/pullをすると、以下のようなエラーとなる。

tcp XX.XX.XX.XX:443: i/o timeout.

IPアドレスを逆引きしてみると、s3-ap-northeast-1.amazonaws.comと判明。

どうやらクライアントは、push/pushの際、docker registryサーバだけでなく、S3に直接イメージpull/pushのための接続を行っている模様。
つまり、docker registryでボリュームをS3に指定した場合、当然registryを立てたEC2から、ボリュームとして指定したS3バケットへのアクセス権(ポリシーやROLEなど)は必須だが、同時にクライアント側も対象S3バケットへアクセスできる必要がある。
オンプレミスとのハイブリッド環境など、クローズドな環境の場合は特に注意が必要。

スクリーンショット 2017-01-18 20.54.28.png

参考

https://ishiis.net/2017/01/12/docker-distribution-install/

http://dev.classmethod.jp/cloud/docker-registry-recipes/

https://docs.docker.com/registry/deploying/#configure-tls-on-a-registry-server

http://qiita.com/suzukihi724/items/c8135fcfbf74fcbc80d0

続きを読む

EC2(Python3)->BigQuery

前提

・GCPのアカウントが準備できていること
・BigQueryに接続可能なtableが存在すること

実行環境の準備

ec2
-pyenv
-naconda3-4.0.0
-pandas
-httplib2
-google-api-python-client

モジュール追加

sudo su -
pyenv global naconda3-4.0.0
pip install httplib2
pip install google-api-python-client

GoogleCloudSDKの導入(python2.x環境で実行)と認証

pyenv global system
curl https://sdk.cloud.google.com | bash
~/google-cloud-sdk/bin/gcloud auth login

※認証情報は~/.config配下に出力される

ごく少ないレコードのテーブルで実行

import pandas as pd
query = 'SELECT * FROM dataset_name.table_name'
pd.read_gbq(query, 'your_project_ID')

→pd.read_gbqで認証が走るが、EC2が実行元となるため、
 localhostでリスンする認証用URLがうまく受け取れない

Oauth2での認証情報生成

from oauth2client.client import OAuth2WebServerFlow
from oauth2client.file import Storage
flow = OAuth2WebServerFlow(client_id='your_client_id',
                           client_secret='your_client_secret',
                           scope='https://www.googleapis.com/auth/bigquery',
                           redirect_uri='urn:ietf:wg:oauth:2.0:oob')
storage = Storage('bigquery_credentials.dat')
authorize_url = flow.step1_get_authorize_url()
print 'Go to the following link in your browser: ' + authorize_url
code = raw_input('Enter verification code: ')
credentials = flow.step2_exchange(code)
storage.put(credentials)

※your_client_id、your_client_sercretは~/.config配下から

上記処理実行後、カレントディレクトリに「bigquery_credentials.dat」が作成される。
→pandas.read_gbqは上記を認証情報として利用

ごく少ないレコードのテーブルで実行

import pandas as pd
query = 'SELECT * FROM dataset_name.table_name'
pd.read_gbq(query, 'your_project_ID')

参考

https://developers.google.com/api-client-library/python/guide/aaa_oauth
http://stackoverflow.com/questions/37792709/accessing-big-query-from-cloud-datalab-using-pandas

続きを読む

[JAWS-UG CLI] AWS Batch #3 環境の破棄(Unmanaged 編)

前提条件

EC2への権限

EC2、ECS、AWS Batch などに対してフル権限があること。

0. 準備

0.1. ジョブの作成と実行の完了

AWS Batch #2 ジョブの作成と実行 が終わっていること

0.2. 変数の確認

#1, #2 から引き続き利用する変数を確認します

コマンド
cat << ETX

    CFN_STACK_NAME:       ${CFN_STACK_NAME}
    COMPUTE_ENV_NAME:     ${COMPUTE_ENV_NAME}
    JOB_QUEUE_NAME:       ${JOB_QUEUE_NAME}
    JOB_DEFINITION_NAME:  ${JOB_DEFINITION_NAME}

    CONRAINER_PROPS_FILE: ${CONRAINER_PROPS_FILE}

ETX
結果(例)

    CFN_STACK_NAME:       aws-batch-xxxxxxxxxx
    COMPUTE_ENV_NAME:     aws-batch-refarch
    JOB_QUEUE_NAME:       aws-batch-job-queue-xxxxxxxxxx
    JOB_DEFINITION_NAME:  aws-batch-job-def-xxxxxxxxxx

    CONRAINER_PROPS_FILE: aws_batch_container_props.json

0.3. AWS CLIのバージョン

以下のバージョンで動作確認済

  • AWS CLI 1.11.36
コマンド
aws --version
結果(例)
 aws-cli/1.11.36 Python/2.7.5 Darwin/13.4.0 botocore/1.4.93

バージョンが古い場合は最新版に更新しましょう。

コマンド
sudo -H pip install -U awscli

0.4. AWS アカウントの属性

EC2-Classic が見えない AWS アカウントであること。

コマンド
AWS_SUPPORT_PLATFORMS=$( 
         aws ec2 describe-account-attributes 
           --query 'AccountAttributes[?AttributeName == `supported-platforms`].AttributeValues[].AttributeValue' 
           --output text 
) && echo ${AWS_SUPPORT_PLATFORMS}
結果
 VPC

1. リソースの削除

1.1. 定義ファイルの削除

コマンド
rm -f ${CFN_STACK_NAME}.yaml ${CFN_STACK_NAME}-ecs.yaml 
    ${CONRAINER_PROPS_FILE}

1.2. ジョブ定義の無効化

コマンド
for arn in $( aws batch describe-job-definitions 
    --job-definition-name ${JOB_DEFINITION_NAME} 
    --status ACTIVE 
    --query 'jobDefinitions[].jobDefinitionArn' 
    --output text)
do
  aws batch deregister-job-definition 
    --job-definition $arn
done
結果
返り値なし

1.3. ジョブキューの削除

ジョブキューを削除するには、まずキューを無効化します。

コマンド
aws batch update-job-queue 
  --job-queue ${JOB_QUEUE_NAME} 
  --state DISABLED
結果(例)
{
    "jobQueueArn": "arn:aws:batch:us-east-1:xxxxxxxxxxxx:job-queue/aws-batch-job-queue-xxxxxxxxxx", 
    "jobQueueName": "aws-batch-job-queue-xxxxxxxxxx"
}

その上で削除します

コマンド
aws batch delete-job-queue 
  --job-queue ${JOB_QUEUE_NAME}
結果
返り値なし

[ 重要!!]
AWS Batch にはまだ wait コマンドがなく不便なのですが、
順序よく消さないと INVALID な状態となりリソースが消せない
可能性があります。なので、確実に消えたことを確かめます。

コマンド
aws batch describe-job-queues 
  --job-queues ${JOB_QUEUE_NAME}
結果
{
    "jobQueues": []
}

1.4 ECS クラスタの削除

コマンド
aws cloudformation delete-stack 
  --stack-name ${CFN_STACK_NAME}-ecs

削除が完了するまで待機します

コマンド
aws cloudformation wait stack-delete-complete 
  --stack-name ${CFN_STACK_NAME}-ecs

1.5. コンピューティング環境の削除

コンピューティング環境も、削除するにはまず無効化が必要です。

コマンド
aws batch update-compute-environment 
  --compute-environment ${COMPUTE_ENV_NAME} 
  --state DISABLED
結果(例)
{
    "computeEnvironmentName": "aws-batch-refarch", 
    "computeEnvironmentArn": "arn:aws:batch:us-east-1:xxxxxxxxxxxx:compute-environment/aws-batch-refarch"
}

その上で削除します

コマンド
aws batch delete-compute-environment 
  --compute-environment ${COMPUTE_ENV_NAME}
結果
返り値なし

[ 重要!!] しばらく待ち、こちらも正常に消えたことを確認します。

コマンド
aws batch describe-compute-environments 
  --compute-environments ${COMPUTE_ENV_NAME}
結果
{
    "computeEnvironments": []
}

1.6. VPC や IAM の削除

コマンド
aws cloudformation delete-stack 
  --stack-name ${CFN_STACK_NAME}
結果
返り値なし

完了

お疲れさまでした

続きを読む

ドメインをAWSに移管した

そもそも

ドメインの管理はムームードメインで行っていました。
ネームサーバなどもムームードメインにあり、自分のサイトのホスティングはEC2でウェブサーバをたてて運営していました。
ですが、IPを固定しているとEC2の値段が高い(月2000円超)のと、EC2を始めた動機も

  1. クラウドサーバってカッコイイ
  2. Linux勉強したい
  3. WEBサーバたててみたい
  4. ソースコード管理サーバたててみたい

等の勉強のモチベーションもあったからでした。
ですが運用期間も長くなり必要な知識も得られ、ウェブサーバをS3に移動して安く済ませたくなりました。
そこで表題とはちょっと違う「EC2で公開しているサイトをS3で公開しなおしてみたい」という動機で始めました。

実際に必要だったこと

先にまとめると、

  1. Route53 にドメインの移管をする
  2. ネームサーバ切り替え
  3. S3にデータのアップロード
  4. S3とRoute53の連携設定
  5. 独自ドメインでメール送受信するためにRoute53とSES(WorkMail)の連携設定

でした。
誤算は、ドメインを移管せざるを得なくなり、メール関連も引っ越す必要が出たことでした。
終わってみての感想は、「うーん、いまいち。WorkMailが微妙」でした。

まずは

Amazon S3
Amazon Route53
Amazon Simple Email Serviece(SES)
これらをいつでも開ける準備をしましょう。
特にSESはメール送受信でサンプルを試すのに死ぬほど見ます。

次に参考になるサイトですが、

  1. ドメイン移管に関しては 更新間近なドメインをRoute53へ移管する(serverworks)
  2. ネームサーバ設定に関しては はじめてのAmazon Route 53(Qiita)
  3. 独自ドメインを使ってAmazon S3で静的Webサイトをホストする(Qiita)

以下はそこにたどりつくまでの変遷とやり方になります。
番号は上の数字とは関係ありません。

1. Route53の利用に至るまで

私のサイトは http://xhift.com/ というアドレスで、サブドメインがない状態で運営していました。
どうもこういうルートドメインを公開するためにはRoute53にドメインを移管する必要があるらしく
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/WebsiteHosting.html
ドメインの移管の予定はなかったのですが移管することになりました。
ドメインは1度移管すると60日後にしか次の移管が出来ないので、やっぱり戻そうが許されない点に注意が必要です。
移管の手順的には難しいところはないので各自頑張ってください。

2. ネームサーバ設定について

最初のはまりポイントでした。
ネームサーバの設定はRoute53の方でやりましょう。
ムームードメインの方で設定項目がうっかり見えてしまっていたのでドハマリしました。
Route53の方でnsの項目を4つ埋めましょう。(私の時は4つでした)
やり方は割愛します。

3. EC2のウェブサーバを止めましょう

S3のバケットとRoute53の連携がうまくいっているかわからなくなります。

4. WorkMailを使うならSESの設定はギリギリまでタッチしないようにしましょう

おそらくWorkMailの方で設定してくれるはずです。
自分でいじるとちゃんと理解していないと設定しなおせなくなりかねません。

5. SESの設定を行うのなら、ルールセットをちゃんと設定すること

受信が出来ないor送信者にエラーが返る場合、ルールセットが上手くいってなさそうです。
私の場合はS3への保存も失敗するしWorkMail側も受信出来ていない絶望的な状況でしたが、ルールセット見直しで修正できました。
それぞれ受信時のActionで

  1. S3への書込みの失敗はObject key prefixを空にしたこと(どっかでそうしてみようと見た気がした…)
  2. WorkMailへの連携失敗はそもそもActionを追加していないかったこと。

という状況でした。
WorkMailの設定の仕方ですが、Organization ARN が何なのか見つけるまで時間がかかりました…疲れていたのです。 https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/receiving-email-action-workmail.html

6. 任意のアドレスにメールが送信できない場合は

Amazonさんにちゃんとサンドボックスから出してもらっているか確認してみましょう。
プログラムで大量送信するわけでもない、と放っておくと、verifyが済んだアドレスにしか送信できなくなります。
ちゃんと申請しましょう。
申請の文章もちゃんとすると許可が下りる可能性が高いと書かれていますが、余程のことがない限りは常識的な範囲は許可が下りるのではないでしょうか。
Amazon SESの送信制限を解除する(SandBoxの外へ移動する)(infoscoop)

まとめ

  1. やりたかったことは全部出来た
  2. メールも移行しなくてはいけなくなったのが誤算だった
  3. ドメインは60日間移動出来なくなるのでそもそも取組むのかよく検討すること
  4. WorkMailはインターフェースは良い
  5. だが高い(1人400円/月)し、機能少なくちょいちょいバグる
  6. Gmailに転送できなそう

結論

びみょう…
メールは今までのままで良かった。

お仕事募集しております
http://xhift.com/
北千住でコワーキングスペースも運営しております
http://xhift.com/bonopri/

続きを読む