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

　　作者李冬梅、核子可乐
　　多年来，AWS凭借其快速部署、快速调整、多区域部署、灵活、稳定等特性在市场上备受好评，根据SynergyResearchGroup的2022年第二季度统计数据，全球云服务器市场本季度营收547亿美金，过去12个月营收达到2050亿美金。各大云服务供应商中，亚马逊云以接近34的市占率排名第一，比第二、第三名加起来都高。
　　但优势明显的AWS却并非适合所有企业，对于很多全公司员工甚至不足10人的小型初创公司来讲，AWS的使用成本还是超出了他们的预期，无奈之下，这些企业不得不另辟蹊径，选择一些更加经济实惠的代替方案。
　　相比于AWS，Fly。io带来了卓越的开发者体验，且上手难度很低。当然，Fly。io也有一些仍显粗糙的部分。如果大家愿意自己打理基础设施，并能够接受缺乏一流技术支持的现实，那Fly。io的确值得关注。
　　总的来说，主流云服务商的产品更花里胡哨，Fly。io则更加简单务实。Terrateam公司简介
　　Terrateam是一个CICD平台，该公司由实践经验丰富的软件工程师创立，对于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组件匹配起来。
　　AWSALBFly。ioLoadBalancerAWSECSFly。ioNomadAWSRDSFly。ioPostgres（大差不差）下一步，则是创建Fly。io应用程序和配置文件。
　　Fly。io拥有强大的CLI，允许用户为每个应用程序指定相应的fly。toml配置文件。使用此配置，Terrateam团队创建了应用程序并轻松完成必要配置。整体体验相当不错。
　　来看看Terrateam的登台fly。toml：
　　appterrateamappstagingkillsignalSIGINTkilltimeout60〔env〕DBHOSTterrateamdbstaging。internalDBNAMEterrateamDBPORT5432DBUSERappTERRATPORT8180TERRATPYTHONEXECusrbinpython3〔〔services〕〕internalport8080protocoltcp〔services。concurrency〕hardlimit25softlimit20typeconnections〔〔services。httpchecks〕〕graceperiod10sinterval10smethodgetpathhealthprotocolhttprestartlimit0timeout3stlsskipverifyfalse〔services。httpchecks。headers〕〔〔services。ports〕〕forcehttpstruehandlers〔http〕port80〔〔services。ports〕〕handlers〔tls，http〕port443〔deploy〕strategyrolling测试
　　在着手构建Terrateam登台环境时，技术团队很快遇到了以下障碍。好在这些问题都有简单的修复办法。IPv6
　　Fly。io应用端点会解析为IPv6地址。
　　joshelmer：flysshconsoleappterrateamappstagingConnectingtofdaa：0：c037：a7b：c6ef：47dd：247：2。。。completedigterrateamdbstaging。internalAterrateamdbstaging。internalAAAAshortfdaa：0：c037：a7b：c207：e395：9a80：2
　　但Terrateam的应用程序并不支持IPv6。这是Terrateam团队自身的问题，但用上HappyEyeballs算法后，麻烦立马解决。Postgres与SSL
　　数据库连接不正常。虽然Terrateam团队可以通过应用程序解析并抵达数据库端点，但却始终无法连接。技术团队使用的数据库强制要求用SSL建立安全连接。当然可以直接覆盖掉这项要求，但这里用SSL配置Postgres明显更安全。
　　搜索Fly。io文档，似乎没找到用fly。toml文件来配置SSL的简便方法。经过进一步调查，Terrateam团队意识到Fly。ioPostgres跟AWSRDS还是有一定区别。官方文档也明确提到，这不是托管Postgres。
　　Fly。ioCLI提供对创建新数据库的特别支持，但也就只限于创建环节。后续的管理、扩展、升级、故障转移和配置都得由用户亲自动手。这并不是在抱怨，毕竟Fly。io的态度非常诚恳坦率，会明确说他们能实现什么、不能实现什么。
　　要用SSL配置Postgres，首先需要创建证书，之后是在postgresql。conf中部署正确配置。到这里，第二个问题顺利解决。正式迁移
　　在解决了登录环境中的问题之后，是时候创建TerrateamFly。io生产应用程序并正式启动迁移了。
　　Terrateam团队讨论了两种迁移方法：
　　零停机实时迁移尽可能缩短停机时间的快速迁移实时迁移
　　根据个人经验，每次谈起迁移时，大家都会先讨论零应用停机完成迁移的实施难度。Terrateam团队后来整理了一份涉及复杂Nginx配置的方案，但最终没有采用。
　　与实时迁移所对应的努力和复杂程度相比，Terrateam团队觉得还不如选择短暂停一会儿机的快速迁移。有些事情确实是越简单、越傻瓜越好。再加上能够重新发送期间错过的GitHubwebhook，进一步坚定了技术团队用短时间停机换简单迁移的决心。快速迁移
　　快速迁移就很直观了：
　　用低DNSTTL更新app。terrateam。io阻断AWSALB上的传入连接将AWSRDS数据库迁移至新的Fly。io数据库更新app。terrateam。io以指向新的Fly。io应用端点重新发送遗漏的GitHubwebhook（事实证明并不存在遗漏）优势
　　在用Fly。io托管Terrateam之后，技术团队表示体会到了不少优势，而且都跟Fly。io组织有关。事实证明，Fly。io非常了解典型工程团队的基础设施构建需求。可观察性
　　Fly。io免费提供良好的可观察性。创建新应用程序时，系统会自动提供Grafana仪表板，其中包含各种常用图表。此外，还能轻松在现有图表和仪表板之上，创建更多新型图表和仪表板，大大降低应用程序的观察难度。与AWSCloudWatch，这简直就是一股清新的空气。
　　另外，如果将应用程序配置为公开Prometheus端点，这些指标也能自动显示在Grafana仪表板上。
　　远程访问
　　跟AWS相比，这又是Fly。io另一个大放异彩的特性。Terrateam经常需要远程访问运行中的容器，特别是在首次构建基础设施或解决持续存在的问题时。有时候，只需要一个shell。
　　Fly。ioCLI提供一种非常简单的访问权限获取方式：
　　joshelmer：flysshconsoleappterrateamappstagingConnectingtofdaa：0：c037：a7b：c6ef：47dd：247：2。。。complete
　　这样做真是太棒了，终于不用受VPN、SSH密钥、堡垒主机的折磨，flysshconsole命令才是真正的便利！IPv6专用网络
　　每位Fly。io客户都会收到一个带有IPv6端点的自动安全专用网络。对于像Terrateam这样的简单应用，这可太方便了。用不着自己建立单独的专用网络，也不必担心CIDR、子网、路由及网络复杂性带来的其他问题。一切都正常运行，一切都刚刚好。多区域可扩展性
　　Fly。io的多区域可扩展性表现极佳。通过在fly。toml中指定多个区域，Terrateam的应用程序就能神奇地存在于多个区域中。这些区域可以随时变更，无需停机。对其他云服务商来说，同样的效果可没这么容易实现。简洁的UI
　　Fly。io的仪表板非常简洁、条理清晰且易于导航。它不像其他云厂商的仪表板那样杂乱无章。事技术团队总能在其中轻松找到自己需要的条目，请务必保持下去。
　　短板Terraform提供程序
　　当然，免费的软件也有其自身短板。技术团队原本想用Terraform创建所有内容，但很快意识到根本不行。Fly。ioTerraform的提供程序不够强大，无法创建完整环境。虽然令人失望，但技术团队还是决定继续前进。请注意，这对Terrateam是个大问题，因为Terrateam是一家强调易用性的公司。但技术团队已经定下计划，后续会逐渐为Fly。ioTerraform提供程序做贡献。Postgres的可用性问题
　　Fly。io使用Stolon集群管理器来实现Postgres的故障转移。技术团队表示：Stolon的故障转移可靠性并不好。这是个问题，毕竟它就是专为这事而存在的。
　　技术团队成员表示，自己曾经历过一次事故，被迫以手动方式创建新数据库并从备份中恢复。Fly。io已经收到反馈，并努力用更强大的方案取代Stolon。日志记录
　　Fly。io提供的容器日志方案确实有点简陋了。虽然用Fly。ioCLI和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。ioblogflyingawayfromaws