使用 AWS 云服务搭建 WordPress 博客 (上篇)

一、前言

搭建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格式图。

使用AWS搭建Wordpress博客
图:整体架构

本图是使用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记录也一并迁移过来。

在智能DNS方便,AWS Route53提供了多种策略,如下截图。

分别是:简单策略(直接出IP)、权重策略(域名负载均衡)、延迟策略(自动找速度快的)、故障切换策略(主备站点切换)、GEO策略(地理位置分布)、多重答案(等于简单策略+主备策略+多记录支持)。 具体信息,参考官网文档

在几个策略里边,第三方如DNSPOD等智能DNS都很常见。有意思的一点就是GEO策略,AWS不但支持按国家设置,还能设置经纬度做偏移量。有点车联网的地图导航坐标系的意思。

例如,下图,手工配置GEO策略。

如果设置4个区域规则,那么页面预览效果图如下。

如果继续配置更多的区域呢,例如美东、美西、加拿大,都独立出来。那么效果如下。

这一系列地理位置图都是Route53的GEO策略生成的,具体配置方法参考官方文档

五、小结

至此,blog转起来了。

本文主要记录了在AWS上搭建wordpress的主要架构思路和过程。对于一些详细的功能对比、操作、脚本、方法、界面交互,因时间关系都不能一次写全,后续会逐渐补充。

本系列的下一篇预告:在AWS上搭建Wordpress的一些Tips和踩过的坑。

谢谢观看。

PCMAN / 2019-08-18

更新@2019-08-30,本文中篇点击这里访问

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.