これは何

Elasticbeanstalk（以下EB）のOSやPHPのバージョンを上げるための手順。特にMajor versionのアップグレードの場合。
Minor version の場合にはEBのWebコンソールで設定すれば良い。

可能な限り無停止でやるためのBlue/Greenな方法だけど、多少停止していいなら後述するupdate-environmentコマンドを叩けば終わり。

手順

手元とテスト環境のPHPのバージョンを変更して確認

このドキュメントの本質的なところではないですが、動くことを確認してからバージョンアップする方が良いでしょう。
手元開発環境のPHPバージョンと、自動テストの環境のバージョンを変更する。

EB環境をクローンする

単にClone Environmentの方でも良い。ここで”Clone With Latest Platform” と書かれていてもMinorの中での最新だったので意味がなかった。ちょっとしたハマりどころなのでここに記録しておく。

Security Group（以下SG） を付け替える

EBが勝手に作ったSGにポリシーを設定している場合のみ。この場合には新しいSGが別途発行されるようで、DBなどにアクセスできなくなっているので、古いSGを新しくCloneで作った環境にも付ける。

自分で手動で作ったSGの場合には旧環境から引き継いでくれそう。なので不要な手順かも。

新環境に対して CLIの update-environment コマンドでバージョンを指定してアップグレード

今回の話のキモである。

aws elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2017.09 v2.6.2 running PHP 7.1" --environment-id "x-xxxxxxxxxx" --region "xxxxxx"

environment-id はEB Application のコンソールの上部に小さく書かれていた。
region についてはここら辺を参考に　https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html

solution stack はこちらのコマンドでリストを得られる。

$ aws elasticbeanstalk list-available-solution-stacks

動作確認

新しいEBのエンドポイントに対してアクセスして通常動作しているか確認する。ざっくりでOK。SGの設定がミスってないかくらいの意味合い。

URLの張り替え

swapしておしまい。2つの環境のEBのURLが置き換わる。
Route53からCNAME張っていればTTLの時間の後、旧環境に向いていた参照が新環境に向くはず。

動作確認はdigコマンドででも行う。
例えば、ユーザに露出しているドメインが example.com で、新環境のEBのエンドポイントが hogehoge.ap-northeast-1.elasticbeanstalk.com だった場合に、

$ dig example.com +short 

で得られるIPと

$ dig hogehoge.ap-northeast-1.elasticbeanstalk.com +short 

で得られるIPが一致していれば良い。