カテゴリー: 技術メモ2

Certbotを使って Conoha+Kusanagi(nginx/centos7) に無料でSSL/TLC証明書をインストール・自動更新する方法は過去に書いた。\"無料でSSL/TLC証明書を手に入れる\" CertbotサイトにOSとWebサーバの組み合わせを入力すると対応するインストール手順が表示される。メジャーな組み合わせであれば証明書の取得から自動更新まで全自動でやってくれる。 2016年7月現在、AWS(EC2)は未対応のため、Certbotツールを使って試行錯誤する必要がある。Certbotの一次情報をもとに何とかやってみたので記録を残しておく。 AWS(EC2)にCertbotでSSL/TLC証明書をインストールする ElasticBeanstalkのロードバランサに取得した証明書を登録しhttpsでアクセスできるようにする 自動更新のセットアップを行う AWS(EC2)にCertbotを使ってSSL/TLC証明書をインストールする いくつか前提がある。 ドメインは取得済みであること。 ドメインがElasticBeanstalkのIPアドレスを指すようにRoute53を設定済みであること。 EC2インスタンスにSSHでログインできるようにしておく。 Certbot利用時、外部からEC2インスタンスにhttpでアクセスを受ける。ElasticBeanstalkにRoutingを変更するようなアプリがデプロイされているとアクセスが失敗するのでDocumentRootにindex.phpがあるだけという状態にしておく。 SSL/TLC証明書をインストールするだけなら443番を開けておく必要はない。ロードバランサはデフォルトの80番だけ開けていれば良い EC2インスタンスのrootパスワードが設定済みであること AWS CLIがインストール済みであること。 IAMで証明書登録ポリシーを付与済みであること。 さっそくEC2インスタンスにログイン。基本的にec2-userで作業する。 一応下記を実行。 $ sudo yum install epel-release Loaded plugins: priorities, update-motd, upgrade-helper Package epel-release-6-8.9.amzn1.noarch already installed and latest version Nothing to do Certbotをダウンロードする。 $ wget https://dl.eff.org/certbot-auto $ chmod a+x certbot-auto Certbotを実行してみる。その際、--debugオプションを付けないと怒られる。would like to work on improving it と言っておきながら --debug がmust。きっと実行内容がCertbotに送られるのだろう。 $ ./certbot-auto WARNING: Amazon Linux support is very experimental at present... if you would like to work on improving it, please ensure you have backups and then run this script again with the --debug flag! 指示通り、--debugオプションを付けて実行してみる。 $ ./certbot-auto --debug ... Installed: augeas-libs.x86_64 0:1.0.0-5.7.amzn1 dialog.x86_64 0:1.1-9.20080819.1.5.amzn1 libffi-devel.x86_64 0:3.0.13-11.4.amzn1 python27-tools.x86_64 0:2.7.10-4.120.amzn1 system-rpm-config.noarch 0:9.0.3-42.27.amzn1 Complete! Creating virtual environment... Installing Python packages... Installation succeeded. Requesting root privileges to run certbot... /home/ec2-user/.local/share/letsencrypt/bin/letsencrypt --debug Version: 1.1-20080819 Version: 1.1-20080819 No installers are available on your OS yet; try running \"letsencrypt-auto certonly\" to get a cert you can install manually いろいろインストールされる。/home/ec2-user/.local/share/letsencrypt/ 以下にPython27 が入る。今回の試行錯誤では自力でPythonを上げなかった。たぶん、自力でPythonのバージョンを上げなくてもコレが使われるんじゃないか。 肝心のインストーラはインストールされず、\"letsencrypt-auto certonly\"というコマンドを実行せよ、と出る。が、これはtypo。 No installers are available on your OS yet; try running \"letsencrypt-auto certonly\" to get a cert you can install manually ディレクトリを移動する。 $ cd /home/ec2-user/.local/share/letsencrypt/bin ここにある certbot コマンドを叩く。ドメイン名、メールアドレスを指定する。 sudo ./certbot certonly -d hoge.com --agree-tos -m hoge@hoge.com --debug すると、中途半端にグラフィカルな画面が表示される。簡易Webサーバを起動するか、現在のWebサーバのDocumentRootを教えるか、2択となる。簡易Webサーバだとどうしても上手くいかなかった。Webサーバを上げたまま(ElasticBeanstalkのヘルスチェックがOKの状態)、DocumentRootを指定すると上手くいった。 うまくいくと、以下のようなメッセージが表示される。 IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/arst.me/fullchain.pem. Your cert will expire on 2016-09-29. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run \"certbot renew\" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let\'s Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le /etc/letsencrypt/live に証明書が作られている。なお、live には ec2-user でアクセスできない。ここでrootに昇格。 $ su - # cd /etc/letsencrypt/live # ls hoge.com # cd hoge.com # ls cert.pem chain.pem fullchain.pem privkey.pem ElasticBeanstalkのロードバランサに証明書を登録する AWS CLI経由で証明書を登録する。その際、IAMにてポリシーを追加しておく必要がある。過去エントリを参照のこと。成功するとJSONで登録情報が返る。ここでは、HogeCertification という名前で登録を行っている。 $ aws iam upload-server-certificate --server-certificate-name HogeCertification --certificate-body file://cert.pem --private-key file://privkey.pem { \"ServerCertificateMetadata\": { \"ServerCertificateId\": \"ASCAI***********A6F5GI\", \"ServerCertificateName\": \"HogeCertification\", \"Expiration\": \"2016-09-29T01:57:00Z\", \"Path\": \"/\", \"Arn\": \"arn:aws:iam::281631559249:server-certificate/HogeCertification\", \"UploadDate\": \"2016-07-01T03:10:18.440Z\" } } ElasticBeanstalkのロードバランサの設定で、証明書欄から HogeCertification を選べるようになる。選んで 443/HTTPS を通すようにすれば、晴れて https://独自ドメイン/ で ElasticBeanstalk の URL が開く。 証明書の自動更新 更新自体はcertbot renewコマンドで行う。certbot renewコマンドは/var/www/html/.well-known/以下にファイルを置いて外部から開きにくる。困ったことに、CakePHPやLaravelアプリをデプロイしているとフレームワークのルーティング機能により上手くいかない。 以下の戦略で対応する。 certbot renew 時だけ、DocumentRoot を アプリ用からcertbot用に切り替える Laravel等のように DocumentRoot がサブディレクトリにオフセットされている場合に対応する ElasticBeanstalkで自動生成される環境を見ると、/var/www/html が /var/app/current へのシンボリックリンクとなっている。Certbot renew を叩くときだけ、シンボリックリンクを差し替える。 $ cd /var/app $ sudo mkdir -p certbot/project/public $ sudo chown -R webapp:webapp certbot $ cd /var/www $ sudo ln -s -f /var/app/certbot html また、certbot用の.well-knownディレクトリが /var/www/html 直下に作られる仕様になっている。DocumentRootはさらに project/public にオフセットされているため、/var/www/html/project/public/.well-known が /var/www/html/.well-known を指すようにシンボリックリンクを作成する。 $ cd /var/app/certbot/project/public $ sudo ln -s ../../.well-known この状態で certbot renew --dry-run を叩くと無事成功する。 $ pwd /home/ec2-user/.local/share/letsencrypt/bin $ sudo certbot renew --dry-run ** DRY RUN: simulating \'certbot renew\' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/ikuty.com/fullchain.pem (success) ** DRY RUN: simulating \'certbot renew\' close to cert expiry ** (The test certificates above have not been saved.) シンボリックリンクの作成は一度だけで良いが、アプリ用とCertbot用のシンボリックリンク張替は都度必要となる。 以下のシェルスクリプトをcronで叩けば良い。 #!/bin/bash cd /var/www sudo unlink html sudo ln -s -f /var/app/certbot html cd ~ pwd sudo ./.local/share/letsencrypt/bin/certbot renew --debug cd /var/www sudo unlink /var/www/html sudo ln -s -f /var/app/current html 不要な更新は実行されないため、1日2回の頻度で実行してよい旨、ドキュメントに記述がある。 Note: if you’re setting up a cron or systemd job, we recommend running it twice per day (it won’t do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let’s Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks.

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編(本エントリ) gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ gitリポジトリからclone 通常 Laravel5 にはデフォルトの .gitignore が作られており、Laravel本体は.gitignoreに登録されている。まず、アプリをcloneし、そのあとでLaravel本体をインストールする。 どこか、Laravel5の要件を満たすところでgitリポジトリからcloneする。 $ pwd /home/ikuty/www/ $ git clone ssh://servername/var/git/project.git project .envの編集 アプリケーションの設定を変更する。/config 内に各種設定ファイルが配置されているが、laravelでは.envを変更することで /config内のenv()関数に展開される仕組みになっている。だから、/config 内の各種ファイルを直接変更する必要はない。/config 内も git の構成管理に含めても良い。 cloneした先でenvを編集する。.env_example をリネームすると楽。 APP_KEY= *** 次項で示すようにキーを生成する DB_HOST : RDS編で設定したRDSエンドポイントを指定する DB_DATABASE, USERNAME, PASSWORD : RDS編で設定した各種設定を指定する APP_ENV=local APP_DEBUG=true APP_KEY=**** APP_URL=http://hoge.com/ DB_CONNECTION=mysql DB_HOST=rds-endpoint DB_PORT=3306 DB_DATABASE=hogedb DB_USERNAME=hoge DB_PASSWORD=fuga CACHE_DRIVER=file SESSION_DRIVER=file QUEUE_DRIVER=sync キーを生成する。以下のコマンドで .env の APP_KEY が差し替わる。 $ php artisan key:generate アプリで使うDBのダンプファイルをRDSにコピー 本来は Migration を使うべきだが...。Migration を利用しないでDBを作ってしまった場合は泥臭くやる...;;まず、ダンプ。 $ mysqldump -u hoge -p appdb > appdb.sql RDS側にDBを作成し権限を付与しておく。 $ mysql -h [rds-endpoint] -u hoge -p $ > CREATE DATABSE appdb; $ > GRANT ALL ON appdb.* to hoge@localhost; $ > FLUSH PRIVILEGES; $ > SHOW DATABSES; $ > ... RDS上のDBにダンプしたsqlを流し込む。 $ mysql -h [rds-endpoint] -u hoge -p -D appdb < appdb.sql Laravelインストーラの準備 composerを利用する。パスを通す。本エントリ作成時の最新は version1.3.3。 $ composer global require \"laravel/installer=~1.1\" $ echo \'export PATH=~/.composer/vendor/laravel/installer:$PATH\' >> ~/.bash_profile $ source .bash_profile $ laravel Laravel Installer version 1.3.3 Laravel本体のインストール composerが準備できたらcomposer installでLaravel本体をインストールする。 $ cd project $ composer install ビルトインサーバでの疎通確認 この状態でビルトインサーバを立ち上げ、疎通確認を行う。 $ cd project php artisan serve --host hoge.com Laravel development server started on http://hoge.com:8000/ Elastic Beanstalkへのデプロイ Elastic Beanstalk構築編にて、環境の準備が出来ているものとする。 eb deploy コマンドにより、カレントディレクトリ以下のファイルをデプロイする。また、.ebextension に DocumentRoot を設定する。カレントディレクトリと DocumentRoot の組み合わせを正しく設定する必要がある。 まず、DocumentRootを設定するため、.ebextensionディレクトリを作成し、設定ファイルを作成する。 $ pwd /home/ikuty/www/ $ mkdir .ebextensions $ cd .ebextensions $ vi 01_documentroot.config 01.documentroot_config は以下の通り。YAMLとして記述する必要がある。空白とタブの扱いがシビアなので、タブが入らないように注意する。ファイルの先頭の\"01\" は、ファイルが解釈される順番を表す。.ebextensions 内に、01,02,... のように設定を複数配置できる。 option_settings: - namespace: aws:elasticbeanstalk:container:php:phpini option_name: document_root value: /project/public DocumentRoot を /project/public と設定した場合に正しい構成になるように、カレントディレクトリを移動し、eb deployを実行する。~/www に移動して、/project 以下をデプロイすれば良い。 $ cd ~/www/ $ eb deploy Creating application version archive \"app-160630_130423\". Uploading: [##################################################] 100% Done... INFO: Environment update is starting. INFO: Deploying new version to instance(s). INFO: New application version was deployed to running EC2 instances. INFO: Environment update completed successfully. 設定が正しければ2分弱で完了する。

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編(本エントリ) 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編 gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ 環境の構築 Elastic Beanstalk の各インスタンスを収める「環境」を作成する。この「環境」の中に、これまで作ってきたVPCの要素を追加する。 $ eb create hoge-production --sample　# アプリケーションのデプロイは後で行う。今はSampleアプリケーションをデプロイ --cname com-sample-production --instance_type t2.micro --region ap-northeast-1 --tier webserver --vpc.ec2subnets subnet-b71eeac1 #VPCに作成したパブリックサブネット --vpc.elbsubnets subnet-b71eeac1 #VPCに作成したパブリックサブネット(同じにする) --vpc.id vpc-cc2b11a9 --vpc.securitygroups sg-23fe8447 #デフォルトセキュリティグループ --vpc.publicip --vpc.elbpublic 3分から5分程度時間を要する。 作成した環境のURLを開く $eb open http://com-sample-production.ap-northeast-1.elasticbeanstalk.com/ .ebextensionsによるカスタマイズ Laravel5アプリケーションをデプロイするにあたって、環境をカスタマイズする。(qiitaを参考にした） $ pwd /home/ikuty/www $ mkdir .ebextensions $ cd .ebextensions # timezoneを変更する vi 01_settimezone.config 各ファイルは以下の通り。なお、各ファイルは yaml形式であり、空白とタブの扱いがシビア。タブでインデントすると簡単に謎のエラーに悩まされる。空文字はタブではなく半角スペース。 01_settimezone.config command: 01-set_timezone: command: cp /usr/share/zoneinfo/Japan /etc/localtime

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編(本エントリ) MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編 gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ MySQLの設定変更 my.cnf等のコンフィグファイルに記述していた内容をRDS風に記述する。RDSでは「DBパラメータ」に設定を記述していく。まず、DBパラメータを作成する。 $ aws rds create-db-parameter-group --db-parameter-group-name mydbparamgroup --db-parameter-group-family mysql5.6 --description \"public rds\" { \"DBParameterGroup\": { \"DBParameterGroupName\": \"mydbparamgroup\", \"DBParameterGroupFamily\": \"mysql5.6\", \"Description\": \"public rds\" } } 文字コード関連の設定 $ aws rds modify-db-parameter-group --db-parameter-group-name --parameters ParameterName=character_set_client,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_connection,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_database,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_results,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_server,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=collation_connection,ParameterValue=utf8mb4_general_ci,ApplyMethod=immediate ParameterName=collation_server,ParameterValue=utf8mb4_general_ci,ApplyMethod=immediate ParameterName=skip-character-set-client-handshake,ParameterValue=0,ApplyMethod=pending-reboot init_connectパラメータの設定。デフォルトの設定をファイルに落とし、ファイルを変更する。 $ aws rds modify-db-parameter-group --generate-cli-skeleton > init_connect.json # 変更後 $ cat init_connect.json { \"DBParameterGroupName\": \"\", \"Parameters\": [ { \"ParameterName\": \"\", \"ParameterValue\": \"\", \"Description\": \"\", \"Source\": \"\", \"ApplyType\": \"\", \"DataType\": \"\", \"AllowedValues\": \"\", \"IsModifiable\": true, \"MinimumEngineVersion\": \"\", \"ApplyMethod\": \"\" } ] } # 出力された設定ファイルを変更する $ vi init_connect.json # 変更内容は以下の通り $ cat init_connect.json { \"DBParameterGroupName\": \"mydbparamgroup\", \"Parameters\": [ { \"ParameterName\": \"init_connect\", \"ParameterValue\": \"SET SESSION time_zone = CASE WHEN POSITION(\'rds\' IN CURRENT_USER()) = 1 THEN \'UTC\' ELSE \'Asia/Tokyo\' END;\", \"Description\": \"\", \"Source\": \"\", \"ApplyType\": \"\", \"DataType\": \"\", \"AllowedValues\": \"\", \"IsModifiable\": true, \"MinimumEngineVersion\": \"\", \"ApplyMethod\": \"immediate\" } ] } # 設定ファイルを読み込む $ aws rds modify-db-parameter-group --cli-input-json file://init_connect.json { \"DBParameterGroupName\": \"mydbparamgroup\" } DBサブネットグループを作成 DB構築編にてAvailabilityZoneが異なるDB用サブネットを2個作成した。それぞれID/tagは\"subnet-131feb65\"/\"subnet public db1\"、\"subnet-d6d2d38f\"/\"subnet public db2\"であった。 DB サブネットグループmydbsubnetgroupを作成する。 aws rds create-db-subnet-group --db-subnet-group-name mydbsubnetgroup --db-subnet-group-description \"DB SubnetGroup for RDS Instance\" --subnet-ids subnet-131feb65 subnet-d6d2d38f { \"DBSubnetGroup\": { \"Subnets\": [ { \"SubnetStatus\": \"Active\", \"SubnetIdentifier\": \"subnet-131feb65\", \"SubnetAvailabilityZone\": { \"Name\": \"ap-northeast-1a\" } }, { \"SubnetStatus\": \"Active\", \"SubnetIdentifier\": \"subnet-d6d2d38f\", \"SubnetAvailabilityZone\": { \"Name\": \"ap-northeast-1c\" } } ], \"DBSubnetGroupName\": \"mydbsubnetgroup\", \"VpcId\": \"vpc-cc2b11a9\", \"DBSubnetGroupDescription\": \"DB SubnetGroup for RDS Instance\", \"SubnetGroupStatus\": \"Complete\" } } RDS用セキュリティグループの作成 RDS用セキュリティグループ myrds を作成する。 $ aws ec2 create-security-group --group-name myrds --description \"RDS security group\" --vpc-id vpc-cc2b11a9 { \"GroupId\": \"sg-b50742d1\" } #タグ付け $ aws ec2 create-tags --resources sg-b50742d1 --tags Key=Name,Value=\"sg rds\" RDS MySQLにVPCから接続するために、RDS用セキュリティグループに3306からのInbound許可設定を行う。(作成済のVPCセキュリティグループのIDはsg-73490c17。) $ aws ec2 authorize-security-group-ingress --group-id sg-b50742d1 --protocol tcp --port 3306 --source-group sg-73490c17 [参考] 下記のようにCIDR標記のアドレスを指定するとVPCの外部からも接続可能になる。 $ aws ec2 authorize-security-group-ingress --group-id sg-b50742d1 --protocol tcp --port 3306 --cidr 0.0.0.0/0 RDSインスタンスの作成 DBパラメータグループ、デフォルトセキュリティグループ、RDS用セキュリティグループを指定する。 外部からの接続を許可する場合 -- publicly-accessible　を指定する必要がある。 $ aws rds create-db-instance --db-instance-identifier hogedb --allocated-storage 5 --db-instance-class db.t2.micro --engine MySQL --engine-version 5.6.22 --master-username hoge --master-user-password fuga --db-name hogedb --db-parameter-group-name mydbparamgroup --db-subnet-group-name mydbsubnetgroup --vpc-security-group-ids sg-23fe8447 sg-b50742d1 --storage-type standard --availability-zone ap-northeast-1a --no-multi-az --region ap-northeast-1 --publicly-accessible --no-auto-minor-version-upgrade 疎通確認 エンドポイントを確認する。予めjqコマンドを利用可能にしておくこと。 # jqがない場合 $ sudo yum install jq $ aws rds describe-db-instances --db-instance-identifier hogedb | jq \'.DBInstances[].Endpoint\' { \"Address\": \"hogedb.c3w6*******5990.ap-northeast-1.rds.amazonaws.com\", \"Port\": 3306 } PublicIp、PublicDnsName を確認する。 $ aws ec2 describe-network-interfaces --filters \"Name=description,Values=RDSNetworkInterface\" { .. \"Description\": \"RDSNetworkInterface\", \"Association\": { \"PublicIp\": \"54.95.100.249\", \"PublicDnsName\": \"ec2-54-92-100-249.ap-northeast-1.compute.amazonaws.com\", \"IpOwnerId\": \"amazon-rds\" }, .. } mysql コマンドでエンドポイントに接続してみる。 $ mysql -h 54.95.100.249 -P 3306 -u hoge -p -D hogedb Enter password: fuga Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 9 Server version: 5.6.22-log MySQL Community Server (GPL) Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. ...

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編(本エントリ) VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編 gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ 前提 aws cli, eb-cli をインストールしておくこと。 $ pwd /home/ikuty $ aws --version aws-cli/1.10.37 Python/2.6.6 Linux/2.6.32-573.22.1.el6.x86_64 botocore/1.4.27 $ eb --version EB CLI 3.7.6 (Python 2.7.9) Administrator AccessポリシーをもつユーザをIAMで作成し、aws-cli から該当ユーザの権限で操作できるようにしておくこと。 $ aws configure AWS Access Key ID [****************] AWS Secret Key [***********************] Default region name [ap-northeast-1] Default output format [json] VPCの環境構築 VPCを作成する。アドレスの範囲をCIDR標記で記述する。ネットワーク部を16bit取る。 vpc-cc2b11a9というIDのVPCが作成されたという報告がjsonで戻る。 $ aws ec2 create-vpc --cidr-block 10.0.0.0/16 { \"Vpc\": { \"VpcId\": \"vpc-cc2b11a9\", \"InstanceTenancy\": \"default\", \"State\": \"pending\", \"DhcpOptionsId\": \"dopt-fec65c9b\", \"CidrBlock\": \"10.0.0.0/16\", \"IsDefault\": false } } vpc-cc2b11a9というVPCにNameタグを付与する。 $ aws ec2 create-tags --resources vpc-cc2b11a9 --tags Key=Name,Value=\"vpc\" VPCとは、クラウド上に閉じたネットワークを構築する機能であり、VPC作成時に、閉じたネットワークを構成する要素が同時に生成される。構成要素は以下の通り。 Routing Table Subnet Network ACL Security group なお、Network ACL、Security group について AWS のドキュメントでは以下の通り説明している。 Amazon VPCのネットワークACL（アクセスコントロールリスト）は、サブネット内外のトラフィックを制御するファイアウォールとして任意のセキュリティを提供します。セキュリティグループの設定と同じようにACLのルールを適応することによって、VPCに追加のセキュリティ層を提供します。EC2はサブネット指定ができませんのでネットワークACLを利用することはできません。 なんのこっちゃ、だが、図を見ると一目瞭然である。NetworkACLを使ってサブネット毎にファイアウォールを定義できる！ NetworkACL、SecurityGroupいずれもファイアウォールのように見えるが、以下のような違いがある。 セキュリティグループ ネットワーク ACL インスタンスレベルで動作します（第 1 保護レイヤー） サブネットレベルで動作します（第 2 保護レイヤー） ルールの許可のみがサポートされます ルールの許可と拒否がサポートされます ステートフル: ルールに関係なく、返されたトラフィックが自動的に許可されます ステートレス: 返されたトラフィックがルールによって明示的に許可されます トラフィックを許可するかどうかを決める前に、すべてのルールを評価します トラフィックを許可するかどうかを決めるときに、順番にルールを処理します インスタンスの起動時に誰かがセキュリティグループを指定した場合、または後でセキュリティグループをインスタンスに関連付けた場合にのみ、インスタンスに適用されます。 関連付けられたサブネット内のすべてのインスタンスに自動的に適用されます（バックアップの保護レイヤーなので、セキュリティグループを指定する人物に依存する必要はありません） Routing tableにタグをつける vpc-cc2b11a9というIDを持ったVPCのRouting tableを確認する。rtb-964da5f2というIDを持ったRouting tableを確認できる。 $ aws ec2 describe-route-tables --filters \"Name=vpc-id,Values=vpc-cc2b11a9\" { \"RouteTables\": [ { \"Associations\": [ { \"RouteTableAssociationId\": \"rtbassoc-b2fd42d6\", \"Main\": true, \"RouteTableId\": \"rtb-964da5f2\" } ], \"RouteTableId\": \"rtb-964da5f2\", \"VpcId\": \"vpc-cc2b11a9\", \"PropagatingVgws\": [], \"Tags\": [], \"Routes\": [ { \"GatewayId\": \"local\", \"DestinationCidrBlock\": \"10.0.0.0/16\", \"State\": \"active\", \"Origin\": \"CreateRouteTable\" } ] } ] } $ aws ec2 create-tags --resources rtb-964da5f2 --tags Key=Name,Value=\"rtb main\" NetworkACLにタグをつける $ aws ec2 describe-network-acls --filters \"Name=vpc-id,Values=vpc-cc2b11a9\" { \"NetworkAcls\": [ { \"Associations\": [], \"NetworkAclId\": \"acl-25fb1a41\", \"VpcId\": \"vpc-cc2b11a9\", \"Tags\": [], \"Entries\": [ { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 100, \"Protocol\": \"-1\", \"Egress\": true, \"RuleAction\": \"allow\" }, { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 32767, \"Protocol\": \"-1\", \"Egress\": true, \"RuleAction\": \"deny\" }, { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 100, \"Protocol\": \"-1\", \"Egress\": false, \"RuleAction\": \"allow\" }, { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 32767, \"Protocol\": \"-1\", \"Egress\": false, \"RuleAction\": \"deny\" } ], \"IsDefault\": true } ] } $ aws ec2 create-tags --resources acl-25fb1a41 --tags Key=Name,Value=\"acl main\" SecurityGroupにタグをつける SecurityGroupを確認する。ID=sg-23fe8447というSecurityGroupが存在することがわかる。 $ aws ec2 describe-security-groups --filters \"Name=vpc-id,Values=vpc-cc2b11a9\" { \"SecurityGroups\": [ { \"IpPermissionsEgress\": [ { \"IpProtocol\": \"-1\", \"IpRanges\": [ { \"CidrIp\": \"0.0.0.0/0\" } ], \"UserIdGroupPairs\": [], \"PrefixListIds\": [] } ], \"Description\": \"default VPC security group\", \"IpPermissions\": [ { \"IpProtocol\": \"-1\", \"IpRanges\": [], \"UserIdGroupPairs\": [ { \"UserId\": \"281631559249\", \"GroupId\": \"sg-23fe8447\" } ], \"PrefixListIds\": [] } ], \"GroupName\": \"default\", \"VpcId\": \"vpc-cc2b11a9\", \"OwnerId\": \"281631559249\", \"GroupId\": \"sg-23fe8447\" } ] } $ aws ec2 create-tags --resources sg-23fe8447 --tags Key=Name,Value=\"sg main\" VPCのDNSホスト名を有効にする VPC内のRDSに外部から接続できるようにDNSホスト名を有効にする。 #有効にする $ aws ec2 modify-vpc-attribute --vpc-id vpc-cc2b11a9 --enable-dns-hostnames #確認する $ aws ec2 describe-vpc-attribute --vpc-id vpc-cc2b11a9 --attribute enableDnsHostnames { \"VpcId\": \"vpc-cc2b11a9\", \"EnableDnsHostnames\": { \"Value\": true } } サブネットを作成する 最初のVPC作成時に、16ビットをネットワーク部として使う意図で、CIDR標記で/16を設定した。さらに、8ビットをサブネットとして利用するため、CIDR標記で/24を設定する。8ビット分(第３オクテット分)がサブネットとして利用でき、そのうち .0、.1、.2 のサブネットを作成する。第4オクテットがホスト部となるが、8ビット全て利用することはできず、利用できる最大数がそれぞれ\"AvailableIpAddressCount\"に書かれてる。なお、各サブネットにそれぞれIDが振られる。 RDSをMultiAZで運用しない場合でもDBサブネットグループを作成する際に2つのAvailabilityZoneが必要なので異なるAvailabilityZoneに対応するサブネットを作成する。 $ aws ec2 create-subnet --vpc-id vpc-cc2b11a9 --cidr-block 10.0.0.0/24 --availability-zone ap-northeast-1a { \"Subnet\": { \"VpcId\": \"vpc-cc2b11a9\", \"CidrBlock\": \"10.0.0.0/24\", \"State\": \"pending\", \"AvailabilityZone\": \"ap-northeast-1a\", \"SubnetId\": \"subnet-b71eeac1\", \"AvailableIpAddressCount\": 251 } } # ap-northeast-1a AvailabilityZone $ aws ec2 create-subnet --vpc-id vpc-cc2b11a9 --cidr-block 10.0.1.0/24 --availability-zone ap-northeast-1a { \"Subnet\": { \"VpcId\": \"vpc-cc2b11a9\", \"CidrBlock\": \"10.0.1.0/24\", \"State\": \"pending\", \"AvailabilityZone\": \"ap-northeast-1a\", \"SubnetId\": \"subnet-131feb65\", \"AvailableIpAddressCount\": 251 } } # ap-northeast-1c AvailabitliyZone $ aws ec2 create-subnet --vpc-id vpc-cc2b11a9 --cidr-block 10.0.2.0/24 --availability-zone ap-northeast-1c { \"Subnet\": { \"VpcId\": \"vpc-cc2b11a9\", \"CidrBlock\": \"10.0.2.0/24\", \"State\": \"pending\", \"AvailabilityZone\": \"ap-northeast-1c\", \"SubnetId\": \"subnet-d6d2d38f\", \"AvailableIpAddressCount\": 251 } } サブネットにタグを付与する 作成したサブネットには、それぞれ、subnet-b71eeac1、subnet-131feb65、subnet-d6d2d38f というIDが振られている。それぞれにタグを付与する。 $ aws ec2 create-tags --resources subnet-b71eeac1 --tags Key=Name,Value=\"subnet public web\" $ aws ec2 create-tags --resources subnet-131feb65 --tags Key=Name,Value=\"subnet public db1\" $ aws ec2 create-tags --resources subnet-d6d2d38f --tags Key=Name,Value=\"subnet public db2\" インターネットゲートウェイの作成 インターネットゲートウェイを作成し、タグを付与する。 $ aws ec2 create-internet-gateway { \"InternetGateway\": { \"Tags\": [], \"InternetGatewayId\": \"igw-5bb8203e\", \"Attachments\": [] } } $ aws ec2 create-tags --resources igw-5bb8203e --tags Key=Name,Value=\"igw main\" インターネットゲートウェイをVPCにアタッチする。 #アタッチ $ aws ec2 attach-internet-gateway --internet-gateway-id igw-5bb8203e --vpc-id vpc-cc2b11a9 #確認 $ aws ec2 describe-internet-gateways --internet-gateway-id igw-5bb8203e { \"InternetGateways\": [ { \"Tags\": [ { \"Value\": \"igw main\", \"Key\": \"Name\" } ], \"InternetGatewayId\": \"igw-5bb8203e\", \"Attachments\": [ { \"State\": \"available\", \"VpcId\": \"vpc-cc2b11a9\" } ] } ] } パブリックサブネット用のRoutingTableを作成する VPC作成時に\"rtb-964da5f2\"というIDを持つRoutingTableが作成されていることを確認した。\"rtb-964da5f2\"にはVPC作成時に自動生成されたデフォルトサブネットが紐付いている。 今回、オリジナルのサブネット、インターネットゲートウェイを新たに作成するのに合わせて、RoutingTableを新規作成する。 # RoutingTable の作成 $ aws ec2 create-route-table --vpc-id vpc-cc2b11a9 { \"RouteTable\": { \"Associations\": [], \"RouteTableId\": \"rtb-fe5cb49a\", \"VpcId\": \"vpc-cc2b11a9\", \"PropagatingVgws\": [], \"Tags\": [], \"Routes\": [ { \"GatewayId\": \"local\", \"DestinationCidrBlock\": \"10.0.0.0/16\", \"State\": \"active\", \"Origin\": \"CreateRouteTable\" } ] } } # タグ付け $ aws ec2 create-tags --resources rtb-fe5cb49a --tags Key=Name,Value=\"rtb public\" パブリックサブネット用RoutingTableにインターネットゲートウェイを関連付ける $ aws ec2 create-route --route-table-id rtb-fe5cb49a --destination-cidr-block 0.0.0.0/0 --gateway-id igw-5bb8203e { \"Return\": true } 新たに作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる $ aws ec2 associate-route-table --route-table-id rtb-fe5cb49a --subnet-id subnet-b71eeac1 { \"AssociationId\": \"rtbassoc-0ce55a68\" } $ aws ec2 associate-route-table --route-table-id rtb-fe5cb49a --subnet-id subnet-131feb65 { \"AssociationId\": \"rtbassoc-c1e45ba5\" } $ aws ec2 associate-route-table --route-table-id rtb-fe5cb49a --subnet-id subnet-d6d2d38f { \"AssociationId\": \"rtbassoc-76c97612\" }

この記事は「AWSでhttpsを使いたい」という要望に5分で応えるために書きます。難しい話は他のサイトを参考にしてください。 AWSでhttpsを使う際のポイントは以下 証明書はPEM形式でないとN.G.。Apacheで使う形式ではダメ。 2016年6月現在、AWSの各種ダッシュボードからは何故かアップロードできない。 AWS CLIを使ってコマンドラインから証明書をアップロードして登録する。 EC2、Beanstalkのロードバランサに対して、ポート番号443をリスナ登録する際に登録済み証明書を設定する。 前提として、AWS CLIがインストール済みであるものとします。まだの人は過去記事(IAM (Identity and Access Management)ユーザの追加と AWS CLIのセットアップ)を参考にしてインストールを済ませてください。 オレオレ証明書(PEM形式)の作成 サーバ証明書の作成 $ pwd /home/ikuty/cert $ openssl req -new -keyout certkey.pem -text -out cert.req -- 秘密鍵のパスワードを入力 Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Tokyo Locality Name (eg, city) []:Minatoku Organization Name (eg, company) [Internet Widgits Pty Ltd]:OreOreCompany Organizational Unit Name (eg, section) []:Tech Common Name (eg, your name or your server\'s hostname) []:oreore.com Email Address []:ikuty@oreore.com Please enter the following \'extra\' attributes to be sent with your certificate request A challenge password []: An optional company name []: -- 次に証明書の自己署名。 $ openssl req -x509 -in cert.req -text -key certkey.pem -out cert.crt 上記の秘密鍵のパスワードを再入力 秘密鍵からパスワードを削除 $ openssl rsa -in certkey.pem -out certnokey.pem 上記の秘密鍵のパスワードを再入力 AWS CLIを使ってオレオレ証明書をアップロード ※改行は見易さのためです。コピペする時は1行にしてください。 $ pwd /home/ikuty/cert $ aws iam upload-server-certificate --server-certificate-name MyOreOreCertification --certificate-body file://cert.crt --private-key file://certnokey.pem 成功するとjsonが返ってくる。 { \"ServerCertificateMetadata\": { \"ServerCertificateId\": \"**********************\", \"ServerCertificateName\": \"MyOreOreCertification\", \"Expiration\": \"2016-07-11T06:10:41Z\", \"Path\": \"/\", \"Arn\": \"*********************************\", \"UploadDate\": \"2016-06-11T06:17:20.991Z\" } } 確認 EC2のロードバランサに443のリスナを追加する画面で、上で追加したMyOreOreCertificationを選択できるようになります。 Elastic Beanstalkのロードバランサでも同様に MyOreOreCertificationを証明書として443のリスナを追加できるようになります。

IAMユーザを追加する AWSのIAMは、Identity and Access Managementの略だそうだ（最初「I am ..」かと思った）。 AWSリソース(EC2やRDS、S3など)に対する権限を持つユーザを1つのAWSアカウントに対して複数追加できる。IAMユーザは、AWS外からAWS CLIを使ってリソースを使う際のIDとしても利用できる。 ドキュメントにはこう書いてある。 AWS アカウントには 1 つ以上の IAM ユーザーを作成できます。組織に新入社員が加わった場合や、AWS への API 呼び出しを実行する必要がある新しいアプリケーションを使用する場合、IAM ユーザーを作成することがあります。 私のような素人Web屋には不要なレイヤーだなー、と思いつつ Windowsで言うところのAdministratorユーザみたいなのが欲しくなる。 いずれにせよ、AWSリソースにアクセスするためには、IAMリソースとしてユーザを追加する必要がある。本エントリではAWSにIAMリソースとしてユーザを追加する方法を記述する。 方法 IAMリソースを編集する画面は、AWSサービス一覧？から「セキュリテイ＆アイデンティティ」というグループの中の「Identity&Access Management」を選ぶ。以下 IAMコンソールと呼ぶ。 IAMコンソールからユーザの作成を行うと作成したユーザ毎に以下が振られる。以下の情報は作成時にしか確認できないため作成時にメモっておく必要がある。（忘れたら再作成できる。）今後、AWS CLI等からユーザの紐付けを行う際に、これらの情報が必要となる。 Access Key Id Secret Access Key 次に今作成したユーザに権限を付与する。AWS風に言うと「IAMユーザに管理ポリシーをアタッチする」。Microsoft程ではないが、なかなかヒドイ日本語のセンスだと思う。 様々なポリシーが用意されているが、Everyone-フルコントロール的なのをイメージして「IAMFullAccess」をアタッチする。 AWS CLIのセットアップ 今作成したユーザを使って外部からAWSリソースにアクセスできるようにする。 AWS CLIはPythonのパッケージ管理ツールpipを使用するが、Python2.6.3以上を要求する。さくらVPSで実験してみた。（ちなみにさくらVPSの標準インストールなCentOS6に入っているPythonは2.6.3でギリギリ。以下のコマンドを実行すると古すぎると警告が出るから先に2.7に上げておくと良いと思う）。 $ curl \"https://bootstrap.pypa.io/get-pip.py\" -o \"get-pip.py\" $ sudo python get-pip.py $ sudo pip install awscli 成功したらAWS CLIのセットアップを実行する。 $ aws configure AWS Access Key ID [None]: *********** (上で作ったユーザの Access Key ID) AWS Secret Access Key [None]: *********** (上で作ったユーザの Secret Access Key) Default region name [None]: Default output format [None]: 今回はここまで。