使用 AWS 云服务搭建 WordPress 博客（上篇） – PCMAN的技术博客

一、前言

搭建Blog有很多种方式，可以选择：

自己开发代码。是个很好的代码学习过程，但时间长，日后还要自己维护代码。
用SaaS的平台。最简单，最快速，最适合企业IT的方式，后续也不用维护。但是缺点是，很多知识没学到，没办法练手。
用成熟的blog程序搭建IaaS和PaaS资源。难度较低，过程中可以学习到大量IaaS和PaaS平台的支持，丰富的第三方插件可以调用，后续也可以结合云服务商的特点，自己给自己加戏。就举一个例子来说，上传到S3的图片加水印，写段Lambda代码以server-less无服务器方式触发，done。这种扩展性，适合没太多时间维护代码，却又想动手玩点什么的方式。

本例子中，所有服务都尽可能使用AWS原生服务来实现。AWS公有云业内的地位无须再详细介绍了。值得一说的是，为什么不选择微软Azure和Google Cloud来搭建呢？时间关系，暂时没来得及深入研究，因此先选业内品牌最大最响的就没错啦，以后再研究下把一些其他小系统搭建在Azure和Google Cloud上。

搭建新的blog，不仅仅是把好几年不写blog的习惯拯救回来，更重要的一个意义就是，Blog可以具备一定量仿真数据，在存储、数据库、日志、流量方面都是一个很好的lab，继续可以扩展学习Lambda、Kinesis等大量新的AWS服务，与他们很好的集成和对接。如果没这个blog，每次需要自己制造假数据，自己发明需求，Lab做个测试都很不方便。另外，搭好blog方便把日常工作一些笔记写出来，比放在电脑上的KB目录里边或者微软OneNote上要好多了。

下面我们来开始正题。

二、分阶段配置

本次搭建的blog分成几个阶段：

1、基础平台搭建（已完成）

这个阶段搭建的内容有，IaaS虚拟机，ELB负载均衡，RDS数据库，DNS域名解析。通过本阶段搭建后，Blog可以用公有IP或者域名的方式提供访问。截至本贴编写时候，已经完成。

2、扩展的存储访问能力（已完成)

本阶段搭建的内容有，S3对象式存储（上传附件图床），源站CDN，图床CDN。本阶段完成后，Blog可以用域名方式访问，且主贴和图片等附件都获得CDN加速的效果。截至本贴编写时候，已经完成。

3、增强访问能力（下一步计划）

本阶段搭建的内容有，全站SSL，WAF。截至本贴编写时候，本步骤尚未启动。未来还可以扩展的包括：Global Replication 全球数据复制容灾等。

三、总体架构图

整个系统架构图如下图所示。点击如下链接下载SVG格式图。

Use-aws-to-setup-wordpress-Architecture Download

本图是使用SaaS方式的第三方绘图工具 Lucidchart 绘制的，原图通过这个链接可以打开。在体验了Draw.io和许多在线绘图工具后，我发现互联网SaaS服务商的易用性已经甩微软Visio几条街了。资本的推动下，很快能做出取悦用户的好东西。Draw.io还是开源免费的，还有offline的版本可以下载到mac上。不过体验没有Lucidchart好，Lucidchart给人一种在用“Fluck”网络测量仪器画拓扑的感觉，适合工程机械爱好者使用。

好了，话题回到我们的架构。

四、各部分组件简单介绍

1、计算部分

计算节点选了两台EC2，配置t2.medium就可以，不需要太高，2vCPU+4GB内存。以后访问量大了，可以换最新的C5系列计算优化型实例，Intel Xeon第五代8175白金处理器的规格摆在哪里，现在云这么普及，就是因为计算性能过剩。注：阿里云是8163处理器，AWS的8175主频更高。当然，谁都希望自己用i7的机器，越快越好。先选t2系列规格把平台跑起来，以后再upgrade。

AWS在2019年提供的新的5系列规格，m5通用计算性规格如下截图。网址在这里。

开机需要注意的另外一个是AWS的机器必须用密钥登陆。不像国内阿里云、华为云，普遍都是通过控制台UI开机，或者是命令行API开机，可以传输一个root密码的参数进去，开机后就不需要证书登陆了，可以直接root密码登陆。AWS不行！证书ONLY！安全必须的。Windows用户就更麻烦了，拿出puttygen还要把.pem格式转换为putty认的ppk格式。然后掏出一堆破解的SecureCRT各种版本登陆。掩面……

2、存储

磁盘方面，AWS默认都是GP2规格的SSD了，系统盘一律SSD。机械盘只在跑Hadoop等特定的需要顺序读写的场景下。因此就默认GP2规格就可以了。不需要选择承诺IO压力的io1规格，因为我们的数据库会走RDS专用服务，不会用EC2虚拟机手工安装MySQL包这种方式，所以对磁盘是没压力的。

AWS EBS主要规格和参数如下截图。网址在这里。

【本章节更新 @2019-08-29】

磁盘另外还有个有意思的，如果使用的实例磁盘（也就是本地硬盘），每次对虚拟机shutdown，系统盘根卷将会被重置为镜像模板的初始状态。这是因为root卷用的是Copy-On-Write，即COW，为了提升性能，缩小磁盘占用，快速做快照等。因此在关机时候，数据会被抛弃，重置为初始镜像。不过：重启时候不会的，只在关机不开时候会发生。例如，周五晚上把机器关掉，周一早上再开，系统盘上的用户自生成数据就没了。

怎么合理使用呢？目前主要规格的实例，系统盘都已经是EBS了，EBS是分布式存储的块磁盘，关机不会丢数据的。不过，对于把实例Terminate 终止了这种场景，还是会删除数据，且不可恢复。另外在系统盘上避免存状态敏感型数据，最好是无状态配置文件，然后把EC2的系统盘直接copy为AMI镜像模板，以后创建新的机器都可以带着应用数据直接创建。

又来注意了，如果使用的是上文方式1，外挂了EBS磁盘，注意，不要把挂载点文件 /etc/fstab 搞挂了，里边写错的话，虚拟机就启动不起来了。而且AWS不提供虚拟机Console的！！！重要的事情说三遍！不提供Console！不提供Console！不提供Console！

更新 @2019-08-29：如果系统盘搞坏了，可以走如下方法挂盘修复。点击这里阅读。

很多人看到这里详细懵了，确实，这就是国际和国内的差别。国内阿里云、华为云、金山云，或者走KVM暴露console，或者根本就是Openstack的NoVNC暴露Console，为的就是给开发者和运维调试用。国外AWS却根本不提供。因为AWS认为专业人员不应该把自己的虚拟机弄坏啊，弄坏了就重新拿镜像开新机器重新配置呗。这让我联想起2007年SWsoft在国内和万网、新网等作为国内第一代VPS服务商吃螃蟹，哪个时候不叫“云”，就是虚拟专用服务器（VPS），使用LXC/Docker前身的OpenVZ和Virtuozzo技术。结果呢，技术支持受理各种问题排第一的是，用户把网卡禁用了或者防火墙关闭了22和3389，把用户自己堵在外边，请求云服务商给解锁。这么多年过去了，恐怕以AWS的产品逼格，还是不怎么接国内的地气哈……

3、数据库

数据库搭建方式以前主要是虚拟机内自行安装MySQL，虽然自由度高，但是性能、成本、安全性都不好控制。现在各家服务商都是推荐用PaaS平台方式的数据库。

本例搭建Blog选的是Aurora 5.7版本，是在MySQL基础上深度开发的增强版本。Aurora与MySQL的关系，类似于阿里云上PolarDB与MySQL的关系，都是深度增强定制的版本，对高可用、数据复制等结构做了大量修改，SQL上有极少量不兼容。可以查看这个网址列出了兼容性问题的清单。装个wordpress不用怕不兼容，标准的很。如下截图所示，AWS RDS可提供的数据库引擎清单。

本文的配置选择t2.meduim的实例。规格是2vCPU 4GB内存。磁盘是完全按数据量计费，运行数据库的系统盘是不收费的。MySQL自己的系统库占用都是不收费，只对用户数据收费。详细规格参考这里的网址。

Aurora在较大压力下，可以达到3-5倍的社区版MySQL的性能。但是，在没有什么压力的单个SQL查询下，速度在毫秒级别上，未必能比单个EC2内手动安装的开源版本MySQL快，甚至要慢5%-10%。由此，对于Aurora的使用，可参考这里这篇性能评测贴。

Aurora选择多可用区的配置，其中的高可用实例主节点和可写入节点，Slave节点即承担了只读节点的功能，也承担了备用节点高可用的功能。这是与普通MySQL的一个巨大区别。普通MySQL配置高可用后，slave节点是不能接受访问的，只能等待Master节点坏了后切换过来。Aurora相当于非常接近双活了，Slave节点在承担备用的角色下，还可以当只读节点用。需要切换时候，还可以随时通过promote提升为主节点。

Aurora的磁盘是纯SSD，三个可用区六份副本，足够安全。另外Aurora还提供了自动备份并可管理数据保留周期。下一阶段，可以打开全球同步复制，在另外的region配置只读副本，做全球范围的广域网容灾。

注意：与阿里云DRDS自动分库分表不同，AWS 的Aurora，可写入数据的主实例和只读实例，使用的是不同的endpoint，也就是连接地址是不同的，不是靠AWS自动流量负载均衡读写分离，而且程序里边要读写分离的。在界面下能到只读实例的endpoint是带有ro（readonly）的字样的。这里，可看到阿里云做了好多面向中国用户的降低门槛的易用方式的优化。

4、负载均衡

负载均衡在AWS上有两个类型，分别是ALB和NLB。ALB可做7层的协议，可配置HTTP头，实现对不同子域名、目录的负载均衡。NLB只到四层协议。健康检查等功能是内置的就不用详细描述了。如下截图，配置负载均衡器的健康检查。

AWS的ALB负载均衡还支持SSL卸载和WAF。也就是说，把SSL证书绑在ALB负载均衡器上，而虚拟机本身都是http光着的，虚拟机不需要handle 443问题，所以虚拟机的CPU负载可以降低下来。另外，AWS自身提供了签署证书的ACM工具，需要把域名NS解析过来托管在AWS的Route53上，才可以申请AWS证书。申请好的证书，在ALB上是下拉框方式就可以直接enable或者disable，配置文件一行都不用沾。

截至本贴编写完成，第一阶段和第二阶段配置完成，SSL证书也签署出来，不过我并未启用全站SSL，还需要准备好各种跳转优化，以及搜索引擎收录等问题。WAF也是下阶段再启用配置，本阶段不配置。

本例中，EC2虚拟机是内网IP，本身不需要公网IP。负载都压在ALB负载均衡器上做NAT，不过呢，这样EC2都记录到负载均衡的内网IP地址了。如果需要让EC2抓取来源IP，可以看Forward-X-Header里边会包含原始IP。

负载均衡器在本Region内是跨多个可用区的高可用，不需要再去管理主备实例。由此可以看到，在云上，一定要尽可能用云原生功能，都是深度集成，非常方便。不要试图自己去在虚拟机上搭建开源解决方案，那样性能差且很难做高可用，也没办法扩展性能。

另外，由于后续要上CDN，AWS的CDN Cloudfront也具有SSL Offload功能，因此这里就提供了多种选择，可以选择把SSL证书放在ALB负载均衡器上，然后CDN来连接源站就已经是SSL了；也可以选择ALB负载均衡器只暴露80，不绑定SSL，然后证书放在CDN上实现。这里主要看对于CDN服务器（AWS的全球Edge节点）到源站这一段，用户是否在意安全加密要求（At-Transit），是否接受这一段不跑SSL了。

5、对象存储

对象存储是云上最有意思的地方。以前文件都是放本机磁盘，或者NFS共享卷。上云后，尽可能一切都上对象存储。AWS叫S3，阿里云叫OSS。对于一个blog，主要是上传附件（如PPT、PDF资料分享）或者是图片，这时候S3就是所谓的图床。tong

上S3做图床的意义在于，如果上传个几万张图片，会对虚拟机自身磁盘的EBS文件系统造成较大压力，读写IO和文件管理都没有优势，一旦需要迁移环境，那么EC2虚拟机里边数以万级别的小文件，在迁移阶段tar-gz打包就是噩梦。这种迁移，每次折腾论坛、blog等上传附件多的环境已经领教过了。上了S3对象存储呢，分布式，不用管高可用了，按对象调用，完全独立的权限管理。比如可以配置lifecycle将大于30天不访问的文件自动转到低性能存储，例如S3每个文件就是自带HTTP的访问URL，且文件所在bucket桶的名字全球唯一，自带域名直接可访问。还可以与CDN深度集成设置各种session key到期时间保护等。

除去适合图床外，AWS S3还提供了Lambda无服务器计算的集成，可以实现自动触发打水印，或者是自行编写Lambda代码并以触发器方式关联到S3。S3还可以作为大数据湖，海量日志和垃圾都往这里存储就好了。以后要分析的话，也不用ETL还要抽取出来，直接在AWS Athena上跑SQL脚本做分析就好了，后台通过EMRFS直接拿S3当存储卷读。

为了让wordpress的上传能自动进S3，可以装第三方plugin插件，实现与S3集成。

读写S3最简单的方式是去AWS IAM里边，新创建一个用户，给用户生成Access Key，然后把Key作为config文件写入代码中。这样是不安全的。如果计算环境在EC2虚拟机上，那么是不需要生成Access Key的。那么另有一个IAM Role的机制可以免Access Key密钥授权访问。

最佳安全实践场景是：去AWS IAM里边新建立一个policy，允许对某个S3的Bucket做读写操作（列出、读取、查询权限等细节可配置）；然后新建立一个role，把刚才的policy绑定到这个role上。

同时，去S3的Bucket管理里边，进入Policy，把本S3的访问授权给刚才新建立的role id（AWS管这种ID叫ARN）。好了，这就配置好了。

如下截图，为S3 Bucket绑定IAM Role的ID。

那么，哪个虚拟机要读写S3，只要在EC2实例管理下，更多操作下拉框中，选择IAM profile，把刚才设置好的具有S3读写权限的role赋予给这个虚拟机，这个虚拟机就可以操作S3了。

如下截图，在EC2实例中，选择更多操作，可对EC2实例绑定IAM Profile。

如下截图，对EC2实例绑定IAM Role。

上述配置完成后，要验证起来配置是否成功也很简单。执行如下命令在要授权的虚拟机内装一个AWS CLI命令行。

yum install awscli

然后通过AWS CLI命令行，发起对S3的bucket查询。

aws s3 ls

然后即可用cp命令，配合S3的bucket name，向S3内复制文件。

aws s3 cp /home/ec2-user/hehe.txt s3://bucket-name/dir-name/

这条命令把本机上的hehe.txt文件直接copy到S3的bucket内。如此几个简单命令，就可以快速确定刚才的IAM Policy、Role、S3 Policy、EC2 Instance IAM Profile这一系列配置是或否正确。

另外，S3存储还有很有意思的地方，例如EC2在一个Private Subnet，是内网，EC2的外网入口访问是靠ALB负载均衡做的NAT。这个时候，其实EC2是上不去外网的，连基本的yum update都没有外网可执行，只能用内部镜像。那么要读写S3文件，S3是全球服务，API都跑在公网上的。怎么能让没有外网路由的内网EC2去访问S3？AWS考虑的非常周到，建立一个VPC Endpoint，流量可以到达了，全过程流量都在AWS的内网，不暴露在Internet。

一圈学习下来，在这些方面，AWS确实有自己独到之处，很多方面阿里云都没有这么细致。例如阿里云的CLI API我也装了，很多产品都不全不能操作，没办法从CLI命令行发起。

6、CDN

AWS提供的CDN叫做Cloudfront，在设计上，与ELB负载均衡器和S3对象存储集成。也就是说，使用场景上都是给源站（或者叫Origin）在AWS云内的资源做加速，AWS之外的资源就暂时不用考虑了。

用于给网站主站加速的话，需要创建一个分发（Distribution），然后把主站EC2使用的ELB负载均衡器（可以是ALB也可以是NLB，7层或4层都可以）绑定上，系统会自动分配一个cloudfront自己的cname域名，就可以开始生效了。不过此时，要访问网站，必须用cloudfront给出的cname域名，是不能用客户自己希望的域名的。例如，给我分配的cname是http://d26cy98vxrbe8k.cloudfront.net 这个域名。

要想绑定客户自己需要的域名，要先把域名托管到AWS Route53上，然后去AWS ACM里边生成SSL证书。有了SSL证书，就可以在Cloudfront上绑定自己的域名了。也就是说，网站所有人希望用自己的域名替代掉Cloudfront分配的随机字符串一样的域名，那么无论是否打开HTTPS协议的加速，哪怕最终用户访问根本不使用HTTPS，而那也要生成证书才可以绑定自己的域名。也就是说，给主站都要用自己的域名，买AWS ACM提供的证书都是跑不了的事情了。

如下截图，购买绑定证书后，就可以绑定自己的域名了。

效果呢，就像现在大家看到的效果，访问本站 https://blog.bitipcman.com/ 是用我自己的域名，而不是CDN提供的cloudfront域名。虽然大家访问的还是http，没有带SSL，完全不访问https，但是我还是要生成SSL证书才可以。这个强制规则，有点强制捆绑购买的意思。这也可以看出HTTPS Everywhere是个趋势，各家都在推广SSL的普遍使用。启用全站SSL是另一个话题，这里先不描述。

给S3加速更加简单粗暴，新建一个distribution，下拉框就可以看到现在已经存在的S3。如下截图。

这里我做了屏蔽哈，因为走了CDN后，S3的Bucket原始名称就看不到啦，就没办法去扫这个Bucket里边的内容。

给S3图床做加速，就可以不买SSL证书了，也不用绑定自己的域名，就直接把图片image写成Cloudfront提供的域名即可。

对S3的集成和支持，Cloudfront还体现在可以做OAI，即Origin Access Identity，即可以限制S3只能从CDN访问。在没有CDN时候，特定的S3 Bucket对外开放要打开Public Access权限，允许从Internet访问。这样文件访问授权不好控制。用户既可以访问CDN地址，也可以直接用S3地址访问bucket。当启用了OAI后，用户就只能通过CDN去访问S3了，避免了直接调用S3的Public URL不能获取全球加速的问题。

Cloudfront还有很多有趣的配置，可以详细控制CDN策略，如下截图。

这里篇幅所限，不展开叙述了。

7、DNS

最后一个要介绍的服务就是Route53 DNS解析服务。AWS也提供域名注册服务，在哪里注册不重要，比如我在Godaddy注册，把NS服务器指过来到Route53就可以了。

把NS记录指过来很重要：

1）是生效快，既然云服务都在AWS上，那么使用Route53生效速度更快
2）是由ACM生成SSL证书，放在一起联合调试，验证域名所有人身份等都比较方便
3）是Route53支持各种策略，各种GEO策略，完全能实现dnspod这种过去好多年完全是第三方DNS服务商才运营的智能DNS的概念。这一点，就干死一片小公司了。当然国内，阿里和腾讯的云服务也早已支持这一特点。

如下图，把DNS记录迁移过来，同时，还得把Google Gmail的邮件解析MX记录也一并迁移过来。