寻羊冒险记
0%

aws s3部署hexo博客

发表于

博客搭完之后, 博文还没写几篇, 站点托管的事情倒是折腾了很久. 在这通折腾之前 ,这个博客是架在aws ec2上, 用hexo自带的http server启动. 看起来用一个vps来部署博客看起来已经足够了, 为什么要这么折腾呢. 简单分析一下, 用静态托管的方式来做网站还是有不少好处的:

  1. 运维的时间成本, 需要管理的是纯粹的站点文件, 不需要关心服务器是什么
  2. 运维的金钱成本, s3托管按照文件大小和流量计费, 要比vps整机便宜
  3. s3结合cdn使用, 在访问速度上必然要好过固定机房的

当然一台vps除了做站点以外还可以提供其他应用, 这一点是静态托管做不到的. 这里就不详细展开了.

除了aws以外, 阿里云也提供对象存储(oos)做静态站点托管. 不过限于国内政策的原因, 需要网站备案才可以使用. 而由于我用的这个me域名在国内没有备案, 所以暂时没有选择阿里云来做站点托管, 不过从实现上来讲都是类似的.

下面是做静态站点托管的主要步骤:

注册域名

托管在s3上的文件, 默认会使用s3的域名(与区域有关), 在实际使用中, 一般会使用自己注册的域名. 原来我这个域名是托管在godaddy上, 为了配合aws的相关功能使用, 也顺势转到了aws 的router 53上, 在实际配置中还是有一定便利性. 另外如果是部署在阿里云上, 自定义域名是必须的, 阿里云oos默认的域名在访问时, 会被作为文件下载, 而不是网站.

域名注册的流程避开不谈, 不过强烈建议使用云服务商自带的域名托管.(比如aws就用router 53, 阿里云就用阿里云的域名托管). 在实际使用中肯定会方便不少.

创建s3 bucket托管站点

整体步骤都可以参考aws官方提供的指南

  1. 首先创建s3 bucket. 可以先评估一下各个机房的访问速度再做决定.(如果后续还使用cdn的就没有必要的). 注意这里有个小坑, s3 bucket的名字必须取成和站点域名一样的名字, 否则在router 53注册别名时会检索不到

  2. 创建完成之后先在bucket设置中将权限->访问控制列表中Everyone组加上读取权限. 并在属性中配置静态网站托管.选择使用此存储桶托管网站, 并设置索引文档(如index.html).

  3. 由于s3上传文件在默认情况下是私有的, 因此还需要在权限->存储桶策略中配置访问权限

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "AddPerm",
                "Effect": "Allow",
                "Principal": "*",
                "Action": "s3:GetObject",
                "Resource": "arn:aws:s3:::example.com/*"
            }
        ]
    }

  4. 设置完成之后就可以上传站点文件了, 直接在网页上操作就好了. 后续自动部署的事情以后再做介绍.

  5. 此时应该已经可以使用s3自带的域名进行访问了. 地址格式为:<bucket-name>.s3-website-<AWS-region>.amazonaws.com. 要注意的一点是, s3自带的域名可能会被墙, 需要科学上网来验证是地址被墙了, 还是配置没生效.

  6. 到此, 部署到s3上的步骤结束, 如果测试没有问题, 那么接下来可以配置自定义的域名解析

配置域名解析

以router 53为例, 在管理界面的托管区域中选择自己要使用的域名, 选择创建记录集,名称中设置自己想要使用的子域名(如果想直接使用顶级域名, 那么名称可以不写), 类型选择A - IPv4地址, 勾选别名, 选择刚才创建的s3bucket即可.

注意这里创建的域名名字必须和s3 bucket名字一样, 否则在别名中是无法检索到的. 如果使用的而不是router 53而是其他服务, 那么我理解这里应该选择创建的是一个CNAME, 然后配置s3的域名即可.

DNS生效可能需要一点时间, 可以通过ping 域名的方式检查dns解析是否生效. 生效以后, 就可以通过自己的站点域名访问s3的资源了.

(可选) 配置CDN加速

在配置完S3以后, 我简单测试了访问的速度, 感觉上比预想的要差. 于是想到了结合cdn做加速. 以下依旧以aws的cloud front为例, 阿里云的cdn加速也可以实现类似的功能(而且可能在国内访问会更快).

  1. 如果网站想支持https访问, 那么需要在cloud front中配置ssl证书. aws也有提供ssl证书服务. 在证书管理中申请就好. 选择dns验证, 如果使用的是router 53, 那么界面上点击即可配置验证dns的cname. 如果是其他dns服务商, 那么需要自行配置cname. 配置完成后, 同样是等待一段时间等dns生效验证即可. 此时域名对应的证书就已经生成好了.(建议申请泛域名证书, 即*.example.com这种格式的域名证书, 否则申请的单个证书只针对单域名有效, 子域名还需要重新申请.

  2. 在aws控制台登录cloud front控制页面, 在分配菜单中选择创建分配, 然后选择Web. **注意这里不要直接选列出的s3存储桶.**这里的一个小问题是, hexo生成的所有页面, 都遵从default root=index.html这一规则. 在s3的静态站点托管中, 我们已经配置了这一规则. 但是cloudfront中的default root object只适用于根目录, 而对于子目录(比如每天博文的独立页面)是不生效的. 手动输入s3的endpoint地址可以避免这个问题.(可以看到这个地址和自动列出的s3 bucket地址存在一些不同)

  3. 在分配设置的备用域名中, 填入自定义的域名, 并选择自定义SSL证书, 可以直接检索到创建的证书, 直接点选即可. 其他选项可以都使用默认配置, 或者自己按需修改.

  4. 配置完成后, 需要等待一段时间等cdn分发完成.

  5. 此时会获得一个cdn的地址, 如xxxxxxx.cloudfront.net这样的格式. 需要在域名解析中用这个地址, 替换原来s3的别名.

  6. 等cdn生效以后, 就可以再次访问, 可以看看速度有没有提升.

如何验证结果是从cdn发来的呢?

打开浏览器的控制台窗口, 在网络标签下, 在response headers中查看X-cache一项, 从could front发来的数据带有Hit from cloudfont的标签, 如果缓存没有命中, 数据从s3获取, 则会有类似miss from cloudfront的标记.

后续优化

上面这些都做完以后, 访问速度还是不理想怎么办呢, 其实还是有不少内容可以优化的, 最近也在逐项实践, 等有时间会再发上来.