小型团队运维架构演进
一个原始的单机架构
- 单台服务器运行着应用程序 + Nginx
- GitHub 托管代码
- 代码开发完毕后直接由本地通过 scp 或 rsync 传到服务器并执行程序 reload 命令
- DNS 将域名解析到服务器 IP 地址
- 使用 crontab 运行 ACME 定时更新免费的 HTTPS 证书
相关工作
- 购置机器
- 将本地机器 SSH 公钥复制到服务器以便免密登录
- 安装程序运行环境,如 Node / PHP
- 安装并配置 Nginx
- 下载 ACME (Automatic Certificate Management Environment) 工具并配置定时任务
- 去域名服务网站添加 DNS 解析记录
相关问题
1. 代码发布不规范
本地直接发布的方式不能保证线上运行的代码在版本控制中的某份代码,存在以下弊端:
- 不能可靠实现指定版本代码回滚
- 在多人协作场景下存在沟通成本
2. 运行环境差异
随着时间的推移,项目相关依赖或多或少会提升版本,部分应用依赖的运行环境有一定概率被迫需要提升,环境差异导致的偶发问题排查成本高且没有业务效益
3. 应用迁移/提升规模工作量大
- 应用绑定在固定的机器上,当机器发生故障被迫需要迁移(或需要加机器)时,单机架构的相关工作基本需要重新执行一遍,耗时费力
- 伴随着特定功能机器数量增加,机器的管理成本也随着上升,部署错误的概率也随之增加
在运维上,大多数重复的人工手动操作除浪费时间外,更大的问题在于其在重复劳动中容易出错,导致更大损失。
解决思路
- 使用持续集成系统进行代码发布
- 使用 Docker 标准化运行环境,弱化应用服务器的特异性
- 使用专门的反向代理网关(网关服务器)进行流量分发,应用服务器不再需要维护 Nginx
- 由持续集成系统管理所有 HTTPS 证书,并按需更新到网关服务器中
持续集成系统
可以使用 GitHub Actions 可以低成本且有效地解决代码发布不规范的问题,相关实践 《GitHub Actions 发布 Hexo》
GitHub Actions 外,Jenkins 也是一个可以考虑的选择,相关实践 《Jenkins 安装和使用》。虽然从相关检索看来,为 GitHub Actions 站台的选手远多于 Jenkins
相关文档:
- 《Github Actions or Jenkins? Making the Right Choice for You》
- 《Github Actions与Jenkins,如何做出正确的选择?》
- 《Is GitHub Action Better than Jenkins?》
- Migrating from Jenkins to GitHub Actions
Docker
直接使用 docker.io 的私有仓库服务或自建私有镜像仓库均可,docker.io 的功能给人一种很单薄的感觉,这里选择使用 Harbor 进行自建私有镜像仓库,在完成 Docker Registry 工作的基础上,还具有用户分级管理及 Web 界面等功能
相关实践:《Harbor 的安装和使用》
网关 Kong
Kong 是一款基于 OpenResty(Nginx + Lua 模块)编写的高可用、易扩展的,由 Mashape 公司开源的 API Gateway 项目。Kong 是基于 NGINX 和 Apache Cassandra 或 PostgreSQL 构建的,能提供易于使用的 RESTful API 来操作和配置 API 管理系统,所以它可以水平扩展多个 Kong 服务器,通过前置的负载均衡配置把请求均匀地分发到各个 Server,来应对大批量的网络请求。
官网:https://konghq.com/
相关实践:《Kong 的安装和使用》
相关文档: