白嫖完AWS后，为了节省成本，我们最终选择了Fly。io

　　作者 | 李冬梅、核子可乐
　　多年来，AWS 凭借其快速部署、快速调整、多区域部署、灵活、稳定等特性在市场上备受好评，根据 Synergy Research Group 的 2022 年第二季度统计数据，全球云服务器市场本季度营收 547 亿美金，过去 12 个月营收达到 2050 亿美金。各大云服务供应商中，亚马逊云以接近 34%的市占率排名第一，比第二、第三名加起来都高。
　　但优势明显的AWS却并非适合所有企业，对于很多全公司员工甚至不足 10 人的小型初创公司来讲，AWS 的使用成本还是超出了他们的预期，无奈之下，这些企业不得不另辟蹊径，选择一些更加经济实惠的代替方案。
　　相比于 AWS，Fly.io 带来了卓越的开发者体验，且上手难度很低。当然，Fly.io也有一些仍显粗糙的部分。如果大家愿意自己打理基础设施，并能够接受缺乏一流技术支持的现实，那 Fly.io 的确值得关注。
　　总的来说，主流云服务商的产品更＂花里胡哨＂，Fly.io 则更加简单务实。 Terrateam 公司简介
　　Terrateam 是一个 CI/CD 平台，该公司由实践经验丰富的软件工程师创立，对于 Terrateam 来说，保持简单而有效很重要。
　　跟其他初创公司一样，Terrateam 刚刚起步的时候，大家都想快速行动、看看业务方向有没有搞头。AWS 当然是最直观的选择，能帮 Terrateam 在短时间内站稳脚跟。只用一点免费积分，整整一年都不用担心基础设施了，简直堪称完美。
　　但时间过得很快，免费积分用完了。看着 AWS 的账单，Terrateam 团队发现这样的开销对一家全靠自己的初创公司来说实在太高了。于是 Terrateam 团队开始四下寻找更便宜的替代品，同时又不能影响稳定性、安全性和可扩展性。 为什么要＂逃离＂AWS？
　　迁移的主要动机当然是成本。AWS可不便宜，Terrateam 团队表示：＂其中很多功能我们也用不上。也许未来用得上吧，但目前没必要＂。
　　在设计上，Terrateam 需要的是一个体量较小的简单基础设施堆栈，具体包括：
　　一套 Postgres 数据库； Web 服务：一个简单的 Docker 容器，负责监听一个端口，需要能横向扩展且保持轻量化。这样一套简单堆栈的好处，就是能为他们提供很多供应商选项。Terrateam 知道自己的需求：便宜的 PaaS，同时剔除一切非必要元素。Terrateam 需要的其实是一种类似于现代版 Heroku 的产品。
　　经过快速实验和概念验证之后，Terrateam 把目光投向了 Fly.io，并决定建立一套登台环境来充实更多细节。 准备工作
　　在建立登台环境时，Terrateam 想要一一映射现有 AWS 基础设施中的所有部分，把它们跟 Fly.io 组件匹配起来。
　　AWS ALB → Fly.io Load Balancer AWS ECS → Fly.io Nomad AWS RDS → Fly.io Postgres (大差不差)下一步，则是创建 Fly.io 应用程序和配置文件。
　　Fly.io 拥有强大的 CLI，允许用户为每个应用程序指定相应的 fly.toml 配置文件。使用此配置，Terrateam 团队创建了应用程序并轻松完成必要配置。整体体验相当不错。
　　来看看 Terrateam 的登台 fly.toml:
　　app = ＂terrateam-app-staging＂ kill_signal = ＂SIGINT＂ kill_timeout = 60   [env]   DB_HOST = ＂terrateam-db-staging.internal＂   DB_NAME = ＂terrateam＂  DB_PORT = ＂5432＂   DB_USER = ＂app＂   TERRAT_PORT = ＂8180＂   TERRAT_PYTHON_EXEC = ＂/usr/bin/python3＂   [[services]]   internal_port = 8080   protocol = ＂tcp＂   [services.concurrency]     hard_limit = 25     soft_limit = 20     type = ＂connections＂    [[services.http_checks]]      grace_period = ＂10s＂      interval = ＂10s＂      method = ＂get＂      path = ＂/health＂      protocol = ＂http＂      restart_limit = 0      timeout = ＂3s＂      tls_skip_verify = false      [services.http_checks.headers]    [[services.ports]]      force_https = true      handlers = [＂http＂]      port = 80       [[services.ports]]      handlers = [＂tls＂, ＂http＂]      port = 443     [deploy]    strategy = ＂rolling＂  测试
　　在着手构建 Terrateam 登台环境时，技术团队很快遇到了以下障碍。好在这些问题都有简单的修复办法。 IPv6
　　Fly.io 应用端点会解析为 IPv6 地址。
　　josh@elmer:~ $ fly ssh console --app terrateam-app-stagingConnecting to fdaa:0:c037:a7b:c6ef:47dd:247:2... complete/ # dig terrateam-db-staging.internal A terrateam-db-staging.internal AAAA +shortfdaa:0:c037:a7b:c207:e395:9a80:2/ #
　　但 Terrateam 的应用程序并不支持 IPv6。这是 Terrateam 团队自身的问题，但用上 Happy Eyeballs 算法后，麻烦立马解决。 Postgres 与 SSL
　　数据库连接不正常。虽然 Terrateam 团队可以通过应用程序解析并抵达数据库端点，但却始终无法连接。技术团队使用的数据库强制要求用 SSL 建立安全连接。当然可以直接覆盖掉这项要求，但这里用 SSL 配置 Postgres 明显更安全。
　　搜索 Fly.io 文档，似乎没找到用 fly.toml 文件来配置 SSL 的简便方法。经过进一步调查，Terrateam 团队意识到 Fly.io Postgres 跟 AWS RDS 还是有一定区别。官方文档也明确提到，＂这不是托管 Postgres。＂
　　Fly.io CLI 提供对创建新数据库的特别支持，但也就只限于创建环节。后续的管理、扩展、升级、故障转移和配置都得由用户亲自动手。这并不是在抱怨，毕竟 Fly.io 的态度非常诚恳坦率，会明确说他们能实现什么、不能实现什么。
　　要用 SSL 配置 Postgres，首先需要创建证书，之后是在 postgresql.conf 中部署正确配置。到这里，第二个问题顺利解决。 正式迁移
　　在解决了登录环境中的问题之后，是时候创建 Terrateam Fly.io 生产应用程序并正式启动迁移了。
　　Terrateam 团队讨论了两种迁移方法：
　　零停机实时迁移 尽可能缩短停机时间的快速迁移 实时迁移
　　根据个人经验，每次谈起迁移时，大家都会先讨论零应用停机完成迁移的实施难度。Terrateam 团队后来整理了一份涉及复杂 Nginx 配置的方案，但最终没有采用。
　　与实时迁移所对应的努力和复杂程度相比，Terrateam 团队觉得还不如选择短暂停一会儿机的快速迁移。有些事情确实是越简单、越＂傻瓜＂越好。再加上能够重新发送期间错过的 GitHub webhook，进一步坚定了技术团队用短时间停机换简单迁移的决心。 快速迁移
　　快速迁移就很直观了：
　　用低 DNS TTL 更新 app.terrateam.io 阻断 AWS ALB 上的传入连接 将 AWS RDS 数据库迁移至新的 Fly.io 数据库 更新 app.terrateam.io 以指向新的 Fly.io 应用端点 重新发送遗漏的 GitHub webhook（事实证明并不存在遗漏）优势
　　在用 Fly.io 托管 Terrateam 之后，技术团队表示体会到了不少优势，而且都跟 Fly.io 组织有关。事实证明，Fly.io 非常了解典型工程团队的基础设施构建需求。 可观察性
　　Fly.io 免费提供良好的可观察性。创建新应用程序时，系统会自动提供 Grafana 仪表板，其中包含各种常用图表。此外，还能轻松在现有图表和仪表板之上，创建更多新型图表和仪表板，大大降低应用程序的观察难度。与 AWS CloudWatch，这简直就是一股清新的空气。
　　另外，如果将应用程序配置为公开 Prometheus 端点，这些指标也能自动显示在 Grafana 仪表板上。
　　远程访问
　　跟 AWS 相比，这又是 Fly.io 另一个大放异彩的特性。Terrateam 经常需要远程访问运行中的容器，特别是在首次构建基础设施或解决持续存在的问题时。有时候，只需要一个 shell。
　　Fly.io CLI 提供一种非常简单的访问权限获取方式：
　　josh@elmer:~ $ fly ssh console --app terrateam-app-stagingConnecting to fdaa:0:c037:a7b:c6ef:47dd:247:2... complete/ #
　　这样做真是太棒了，终于不用受 VPN、SSH 密钥、堡垒主机的折磨，fly ssh console 命令才是真正的便利！ IPv6 专用网络
　　每位 Fly.io 客户都会收到一个带有 IPv6 端点的自动安全专用网络。对于像 Terrateam 这样的简单应用，这可太方便了。用不着自己建立单独的专用网络，也不必担心 CIDR、子网、路由及网络复杂性带来的其他问题。一切都正常运行，一切都刚刚好。 多区域可扩展性
　　Fly.io 的多区域可扩展性表现极佳。通过在 fly.toml 中指定多个区域，Terrateam 的应用程序就能神奇地存在于多个区域中。这些区域可以随时变更，无需停机。对其他云服务商来说，同样的效果可没这么容易实现。 简洁的 UI
　　Fly.io 的仪表板非常简洁、条理清晰且易于导航。它不像其他云厂商的仪表板那样杂乱无章。事技术团队总能在其中轻松找到自己需要的条目，请务必保持下去。
　　短板Terraform 提供程序
　　当然，免费的软件也有其自身短板。技术团队原本想用 Terraform 创建所有内容，但很快意识到根本不行。Fly.io Terraform 的提供程序不够强大，无法创建完整环境。虽然令人失望，但技术团队还是决定继续前进。请注意，这对 Terrateam 是个大问题，因为 Terrateam 是一家强调易用性的公司。但技术团队已经定下计划，后续会逐渐为 Fly.io Terraform 提供程序做贡献。 Postgres 的可用性问题
　　Fly.io 使用Stolon集群管理器来实现 Postgres 的故障转移。技术团队表示：＂Stolon 的故障转移可靠性并不好。这是个问题，毕竟它就是专为这事而存在的。＂
　　技术团队成员表示，自己曾经历过一次事故，被迫以手动方式创建新数据库并从备份中恢复。Fly.io 已经收到反馈，并努力用更强大的方案取代 Stolon。 日志记录
　　Fly.io 提供的容器日志方案确实有点简陋了。虽然用 Fly.io CLI 和 Fly.io 仪表板都能轻松查看日志，但其中只保留少部分内容。所以，技术团队只能在应用之内或将日志发送至外部服务，借此为各 Fly.io 应用程序建立单独的远程日志记录方案。这会带来额外的运营开销，希望以后会有改善。
　　技术支持
　　Fly.io 并不是那种服务很周到的企业，如果大家特别需要随时获取技术支持，但 Fly.io 恐怕不太合适。
　　在通过电子邮件发送支持时（目前只提供邮件联络选项），往往要几个小时甚至几天后才能得到回复。有时候 Fly.io 那边干脆没有跟进，感觉他们的支持水平不如其他云服务商。
　　但毕竟 Fly.io 强调的就是客户自主运营基础设施，他们只负责提供构建块。有良好的服务支持当然好，但他们认为环境的管理工作最终还是客户的事。
　　Terrateam 团队表示，对于 Fly.io 还是充满了期待的，还是希望未来能有更好的支持体验。即使没法直接从工作人员那得到具体答案，至少也应该得到一点指引。 写在最后
　　没有哪套平台真正完美无缺，而且在 Terrateam 看来，Fly.io 甚至已经在可能的范围内做得足够好。Terrateam 团队在使用后表示对它没有太多抱怨，特别是考虑到他们明确解释了自己的产品能做什么、不能做什么。
　　Terrateam 的堆栈设计非常简单，也许这才是 Fly.io 特别契合需求的原因。Terrateam 不需要太多活动部件或基础设施，最核心的元素就是数据库加容器。
　　但各位读者朋友的需求可能并非如此，如果大家需要消息中间件、S3 存储桶、IAM 等更完备的服务组件，那 Fly.io 可能不适合你。
　　参考链接：
　　https://terrateam.io/blog/flying-away-from-aws