作者 | 李冬梅、核子可乐
多年来,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 需要的是一个体量较小的简单基础设施堆栈,具体包括:
经过快速实验和概念验证之后,Terrateam 把目光投向了 Fly.io,并决定建立一套登台环境来充实更多细节。
准备工作在建立登台环境时,Terrateam 想要一一映射现有 AWS 基础设施中的所有部分,把它们跟 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 登台环境时,技术团队很快遇到了以下障碍。好在这些问题都有简单的修复办法。
IPv6Fly.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,进一步坚定了技术团队用短时间停机换简单迁移的决心。
快速迁移快速迁移就很直观了:
在用 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 的应用程序就能神奇地存在于多个区域中。这些区域可以随时变更,无需停机。对其他云服务商来说,同样的效果可没这么容易实现。
简洁的 UIFly.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
Copyright © 2024 妖气游戏网 www.17u1u.com All Rights Reserved