做者 | 李冬梅、核子可乐
多年来,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 BalancerAWS ECS → Fly.io NomadAWS 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 登台情况时,手艺团队很快碰到了以下障碍。好在那些问题都有简单的修复法子。
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,进一步坚决了手艺团队用短时间停机换简单迁徙的决心。
快速迁徙快速迁徙就很曲不雅了:
用低 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 的应用法式就能奇异地存在于多个区域中。那些区域能够随时变动,无需停机。对其他云办事商来说,同样的效果可没那么容易实现。
简洁的 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
发表评论