继续折腾

看来你不懂生命的可贵

之前很长一段时间,我的网站都是在VPS上手动部署的,主要是在一台Linode上人工运维。虽然网站规模不大,但是人工运维无疑是一颗定时炸弹,说不定啥时候我就变成首席删库官了。

另一方面,前两天终于到手了一张Visa信用卡。于是立刻去Google Cloud和AWS上利用免费的额度各开了一台小配置的机器。Google Compute Engine(GCE)上在asia-east1-c区(实际上就是台湾彰化数据中心)开了一台f1-micro(1 个 vCPU,0.6 GB 内存),AWS EC2上在ap-northeast-1区(实际上就是日本东京数据中心)开了一台t2.micro(1 个 vCPU,1 GB 内存)。虽然两台机器单独看配置都不高,但是加起来也有差不多1.6GB的内存了。之前是一台Linode 2048,即1核2GB的配置。几个月的观察下来,实际上大部分时间资源利用率都不会超过50%。所以目前GCE和EC2两台机器的性能之和是能够满足我现有的需求的。

为了彻底解决人工运维的问题,作出了一个艰难的决定,采用Docker将网站的部署全面容器化,同时利用自家的公有云服务DCS实现自动化。网站的各个部分的架构实际上并不复杂。

  • https://jinwei.me,纯静态页面,之前部署在GitHub Pages上,容器化非常简单,把静态文件丢到一个Nginx内即可。
  • https://blog.jinwei.me,一个标准的Wordpress,之前部署在Linode上,采用Nginx+Php7-fpm+MySQL的方案。把这三个组件分别容器化,然后通过Docker Compose来组织即可。
  • https://hzres.jinwei.me,也是一个纯静态页面,Nginx即可。
  • https://rss.jinwei.me,一个极简RSS阅读器,也是一个PHP应用。
  • 理论上,只要将各网站分别作成Docker镜像,借助DCS在主机上部署即可。部署完成之后默认通过ip:port的形式访问。那么接下来如何方便地处理域名的问题呢?

    由于我一直在使用Cloudflare管理DNS和使用Flexible SSL。而Cloudflare的URL Redirect需要通过Page Rules的方式实现,而Page Rules是一个收费项目,免费额度只有3条,显然是不够用的。因此经过考虑,决定在各网站的最前端加一个Nginx作为Proxy,通过它进行流量的分发。

    简单来说,首先在GCE上部署一个Nginx监听80端口,然后在Cloudflare上将各域名的DNS A记录指向该Nginx所在机器的IP。然后在Nginx上通过配置/etc/nginx/conf.d目录下的各*.conf文件,将流量引到各网站容器对应的ip:port。另外,由于启用了Flexible SSL,所以当用户访问 https://blog.jinwei.me 的时候,实际上经过了N层Nginx。最前端是Cloudflare CDN的cloudflare-nginx负载均衡,然后到达我部署在GCE上的Nginx,然后才确定了该往AWS走。到了AWS之后,终于访问到Wordpress,博客的文字等内容可能由AWS提供,最终到达用户浏览器,但是诸如js/css/图片之类的文件,又是从cdn.clarkzjw.cn这个七牛的融合CDN分发的哦。

    这样的架构对于网站的性能是否会产生明显的影响,我并没有做非常细致的测试。但是对我自己来说,是极大降低了运维的成本。如果要修改某个站点的Nginx配置,我只需将修改后的配置文件push到GitHub上,然后DCS会自动完成镜像构建到持续部署等所有的动作。即使假设某一天,GCE和AWS的免费额度都用完了,需要将网站迁移到新的主机,也只需在新的主机上安装Docker,并接入DCS公有云,然后将应用迁移到新的主机即可。当然了,像Wordpress这样的存在数据持久化需求的网站,目前采用的解决方案是通过Docker的Volume,将容器内的文件系统挂载到宿主机上。所以当应用跨宿主机迁移的时候,理论上只需将对应的文件夹迁移即可。

    继续折腾》上有1条评论

    发表评论

    电子邮件地址不会被公开。 必填项已用*标注