利用 AWS Elastic Beanstalk 部署 Wordpress 环境

1. 准备 wordpress 代码

从https://wordpress.org/download/ 将代码压缩包下载到本地，
解压，会有一个 wordpress 目录
复制 wp-config-sample.php 为 wp-config.php，修改。将下面的代码

define('DB_NAME', 'database_name_here');

define('DB_USER', 'username_here');

define('DB_PASSWORD', 'password_here');

define('DB_HOST', 'localhost');

修改为：

define('DB_NAME',     $_SERVER["RDS_DB_NAME"]);

define('DB_USER',     $_SERVER["RDS_USERNAME"]);

define('DB_PASSWORD', $_SERVER["RDS_PASSWORD"]);

define('DB_HOST',     $_SERVER["RDS_HOSTNAME"]);

4. 将 wordpress 目录中的代码打包为一个新的 zip 文件（注意不能直接打包 wordpress 目录）

2. AWS 操作

2.1 准备工作

创建一个 VPC，带至包括在两个AZ内的两个 subnet；创建一个 internet gateway 并绑定到VPC；设置默认 route table 中到 IGW 的 rule
创建一个 key pair

2.2 创建一个单实例 wordpress 测试环境

（1）进入 AWS Beanstalk 节点，点击 Create Application，输入

（2）点击 Create Now 创建 Environment

（3）选择 Web server environment

（4）配置 Environment

Platform 选择 PHP：

上传前面打包好的代码zip文件，该文件会被保存到S3中。

点击 Create Environment 按钮，开始创建 Environment。

经过几分钟，Environment 创建好以后，点击下图顶上的 URL 链接，

出现下面的页面：

这是因为没有配置数据库。

2.3 重新创建带RDS的Environment

在点击 Create Environment 之前，点击 Configure more options 按钮来进行更多配置。

点击 Database 下面的 Modify 按钮来修改 Database配置。下面的配置使用一个 RDS 实例：

点击 Security 下面的 Modify，设置 EC2 Key Pair，以便将来能够登录到虚机。

点击 Network Tab 下面的 Modify 按钮来修改 Network。选择 VPC 和 subnet：

回到 Network 配置，设置 RDS 实例的 subnet，需要设置在两个AZ中的至少两个subnet：

配置完成，点击 Create Environment，开始创建过程。从Events 能看出大概的过程包括

创建一个 RDS 实例
创建一个 EIP，会绑定到 EC2
创建一个 EC2 实例

2.4 更新代码

修改 wordpress 代码，打包成一个新的zip 文件。点击 Upload and Deploy：

上传文件，点击 Deploy：

新版本部署成功。

2.5 升级架构

在 Configuration 页面中，分别做下面的配置修改：

在 Capacity Modify 页面中，配置 ASG：

在 Load Banlancer 页面中配置 LB。

在 Security 页面中配置 EC2 Kay Pair，以便将来登录进虚机。

在 Network 页面中修改虚机所在的 subnet。

在 Software 页面中配置日志相关，将日志保存到 S3 和导入到 CloudWatch：

点击 Apply Configuration 开始应用配置改动。

3. 一点心得

以上只是简单地从AWS界面上尝试使用了该功能的一些步骤。一点感受如下：

速度较慢。创建一个很小的环境就需要十几分钟。
Configuration 中的部分配置互相有影响，修改了一处后往往需要在别的地方做修改，但是页面上没有提示。
预定义好的Platforms 的架构太简单，无法满足生产需求。
用户定制Platform 过程很复杂。
Configuration 难以扩展。只支持 ec2，rds，elb，asg，vpc 等，但是一个应用往往还需要其它资源。可选途径包括 EBExtensions 和 CloudFormation，但使用似乎较难。
ELB 还在使用快被淘汰的Classic类型，我估计基于虚机的PaaS 估计 AWS 也不打算继续整了，还是转到容器比较实际一些。