它属于一种数据编排工具。在无服务器架构所依托的云平台环境里, 使用者无需费力去搭建本地的编程开发氛围或者设立云端的根基体系, 就能顺利进行代码编写和程序投放的动作。每当有人向平台递交版本更新的内容时, 这个后台系统就会立刻动手编译你的程序指令, 并把这些成果直接安放好到相对应的云端空间当中。同时, 大家也能够通过那个可视化的操作面板, 去浏览以及干预自己创建的那些功能模块。靠着这套云服务体系的支持, 一般来讲远程的工作区间经常被拿来当作一种渠道, 目的是让那些依靠自动生成的过渡性演练场所, 方便地把最终安装好的东西分享给一起合作搞项目的人。个人在本地进行开发, 与共享远程环境相结合, 这样就形成了一个功能强大的开发周期。在最开始的时候, 我们在这个上面使用了基于标准构建流程。但是, 我们马上就发现, 这个方法会让编辑代码、部署上线和运行测试这一整个周期的工作变得非常繁杂, 而且速度也很慢。为了能把时间缩短, 我们把事情提上去做, 我们搭建了一个系统, 这个系统可以在镜像外面把代码运送过去。这篇文章会详细讲述我们是怎么分析这些问题, 确定了什么样的解决方案, 还有在整个过程中我们做出了哪些方面的权衡。分享了关于Cloud平台新推出的快速部署功能所涉及到的那些较为专业的概括性内容, 如果想要了解更多更为详细信息的具体情况的话, 那么建议大家还是去观看一下对应的视频来了解具体情况。镜像的问题当我们在平台上构建镜像并将这些镜像部署到云端的时候, 每次进行提交操作的话, 都需要消耗三到五分钟的时间才能在用户界面上将结果显示出来。无服务器类型的开发人员他们通常会在每一种迭代过程里面去对代码作出稍微一点点的改变, 可是却每次都必须等待三分钟以上才能够去看清楚那些改动所产生出来的效果, 这种纯粹就是毫无意义的等待时间, 确实是非常容易让人产生厌烦情绪的。然后我们去仔细分析了一个特定的问题, 这个具体的问题是这样的, 也就是问你, 当你仅仅只是修改行代码并且将其提交上去之后到底会引发哪些结果的出现呢。发现了一个以下的状况。我们对“当您改动了一行代码并且将变更进行提交操作的时候, 系统内部究竟会触发怎样的过程”这一主题展开了分析工作, 由此我们识别并总结了下面列出的几种具体状况。当缓存功能被启用的情况下, 如果相关的依赖关系没有发生改变的话, 那么所需的时间是60秒但如果依赖关系发生了变化, 这种情况下所需的时间就得超过90秒。正如你所看见的那样, 所花费时间最长的两件事情分别是:所以, 接下来我们将对这两件事情各自所做的具体工作情况进行细致的查看与分析。构建 镜像关于构建镜像这件事, 有一些方面是需要大家注意的。镜像是由堆栈中的多个层堆叠而成的, 其中每一层都是由文件中的一个命令子集构建出来的。每一层都有一个对应的哈希值来进行识别。当上传镜像到注册表的时候, 只有那些注册表中还不存在的层会被上传, 而这些层是由哈希值来识别的。在使用缓存在构建机上重建镜像的时候, 它会把所有没有受到变动影响的那些层从缓存里面直接拉到构建机上来。你要特别注意一下, 要是你的那个项目里面存在着大量完全没有被改动过的依赖关系的话, 那么在构建过程进行期间, 它们是一起从一个地方被复制到构建机器上去的。它的构建过程并不是绝对准确的。假如你用一模一样的内容去建立镜像两次, 那么每一次得到的哈希值都有可能是不一样的。尽管这一点和主要问题没有直接的联系, 但是我们还是想把这种偶然的发现记录下来。可以把它当成一个极端的例子来看待, 那就是即使一个刚刚构建完成的大体积数据层, 和已经在注册表里面存在的数据层是完全一样的它依然有可能被当作一个新的数据层进行上传操作。把这个容器给启动起来。关于启动容器需要注意, 因为我们使用的是AWS平台, 所以它需要耗费45到90秒的时间来执行配置并启动镜像。该系统不提供任何形式的图像缓存功能, 因此一旦开始启动新的容器, 系统就必须从头下载所有的层级数据, 并将其装载到已配置的容器实例里面去。其他限制在镜像建立和启动以后, 我们来运行用户的代码, 以便提取元数据, 然后把元数据显示在用户界面上。这一步是无法避免的, 可能需要花费几秒钟的时间, 或者30秒的时间, 甚至花更久的时间, 具体需要多少时间, 这得看元数据的计算方式是怎样的, 比如这个计算过程它可以连接到数据库来读取模式信息。这个代码服务器会保持活动的状态, 它用来为元数据请求提供服务, 直到推送新版本的代码为止, 这个时候它会启动一个新的容器。我们有一个非常关键的要求, 就是可重复性, 因此我们需要能够多次去重新部署完全相同的代码以及环境, 通过使用镜像的哈希值来作为代码和环境的标识符, 这样可以很好地满足这一要求。备选方案综述除了上述的那些方案之外, 我们还有去进行了探索, 同时我们也对这些内容进行过讨论, 也就是去寻找一些可以作为替代的解决方案。我们从某个地方切换到了EC2, 目的是为了加快容器的启动速度。这样做会增加我们的运营负担, 因为我们要求提前提供资源、对集群进行监控并且要进行扩展操作。我们依然会遭遇构建缓慢的问题。更换为不同的构建系统, 例如 AWS , 这会增加部署方面的工作量, 并且还需要进行更深层次的整合。现在无法明确这样的做法能够带来的回报是否足够充分以令人感到值得去这样做。当把服务切换到 AWS 这个云平台之后, 启动过程的速度会变得非常快。可是, 该环境自带的基础镜像在应对各种自定义需求的时候, 并不是非常友好。此外, 它的执行程序时间还受到15分钟的这个严格限制, 如果遇到那些运行周期特别长的服务器任务, 就得想办法用一些复杂的变通手段来解决这个问题。通过构建并只上传修改后的代码到同一服务器来实现重新使用长期运行的代码服务器。这里的挑战是实现打包和运行机制, 以确保有一个可靠和可重复的执行环境。我们研究了各种打包和分析分发途径的方法, 这些途径包括rsync、nix、shiv和pex。同时还考虑了使用EFS卷来挂载运行环境的策略, 并且将这一策略与上述工具结合起来使用。我们之所以作出最终的决定, 背后有一个关键的因素在起作用。就是我们已经意识到了这样的情况。镜像这东西确实是行业标准。但是我们如果仅仅需要同步一个很小的变化。那么如果我们去搬运上百兆的镜像数据的话。这就显得是一个非常没有必要的繁重的操作了。我们需要考虑到的是 Git 这个东西的情况。Git 只提供差异的部分。但是通过这些差异却能够产生一个完整的、一致的存储库数据。基于以上这些考虑。所以我们更倾向于方案 4。因为我们只要找一个合适的工具出来。让这个工具去做那些大部分的工作就好。经过进行了一些实验活动, 我们是发现到了pex这个技术工具, 它的许多个功能方面, 是对于我们当下的具体使用案例来说, 是非常有效地起到了作用。什么是 PEXpex 是某个词组的缩写, 它是一种将包捆绑到一起的工具, 捆绑后的结果称为 pex 文件。这些 pex 文件是可执行文件类型, 其中包含所需的包以及一些用于启动的引导代码。例如, 我们可以把指定包以及它所依赖的其他所有包一起捆绑成单个文件, 之后就可以直接运行这个文件了。这是 pexo 命令的输出结果, 显示当前使用的 pex 版本号为 3.8.16, 该版本的编译时间为 2022年12月7日 01点24分57秒。这是 Clang 14.0.0, 它的编号是 clang-1400.0.29.202。在输入“帮助”、、或时, 可以显示更多相关信息。()。将整体运行的环境配置整合到单个文件内进行处理, 这样会方便后续的移动传输操作, 以及存储于亚马逊的S3云存储系统中。pex这个工具所提供的能力并不局限于创建一个“存在于文件里的虚拟运行环境”这一单一功能, 接下来我们将具体列举说明在我们实际应用场景中使用到的其他几项相关技术特性与辅助功能。隔离在系统运行的时候, Pex这个环境和其他那些整个网站级别的软件包之间是完全相互隔离的。在这个环境内部, 仅存在于其中的只有那些被打包捆绑在Pex文件里面的软件包。我们把许多个Pex文件都运输并且放置到同一台机器上去, 在这个过程中完全不用去担忧关于环境隔离会出现任何安全问题。确定性如果使用的输入包是完全一样的那么最终生成的 pex 文件也会实现位对位的完全一致性。执行命令, 然后生成一个输出文件, 该文件的名称为out.pex。这就使得我们有信心, 能够采用内容寻址这种方法去识别出这些 pex 文件。并且为了能够实现可重复性, 在操作的过程中, 我们除了会用到镜像的哈希值之外, 还会使用 pex 文件的哈希值。组成多个 pex 文件能够在程序运行过程中实现合并操作, 这种操作可以将原本分散的环境整合到一块儿去, 其最终的效果就是相当于把各种环境融合变成了一个统一的整体。% pex -o .pex% pex -o .pex% .pex ./. 3.8.16 (, Dec 7 2022, 01:24:57)Clang 14.0.0 (clang-1400.0.29.202)在输入“ help ”、 或者 之后, 将会获取更多相关的信息。接着显示为两对括号然后三个大于号, 再后面是 。我们使用它, 将代码分割成两个部分, 等到运行的时候, 再把这两个部分合并到一起, 其中一个部分是包含了所有依赖关系的dep.pex文件, 另一个部分则是只包含了用户自己编写的代码的pex文件。跨平台的构建我们在无服务器云中使用Linux :*-slim衍生的基础镜像, 只要软件包的轮子可用, pex工具可以在任何平台上为Linux构建pex文件。快速部署我们把 pex 文件和 S3 服务连起来用作存储空间, 然后搭建了一套系统。这套系统的快速处理路线, 直接躲过了那个用来构建和启动镜像所产生的额外负担。我们的系统是这样工作的, 当您将代码提交到指定的仓库时, 系统将执行构建操作, 该操作属于全量构建或快速构建类型之一, 此选择基于您的依赖关系自上一次部署以来是否发生过变化这一条件来确定, 并且我们负责跟踪由 setup.py 文件和 .txt 文件所指定的相关依赖项。对于一个完整的构建过程, 会把项目的依赖条件给构建进到那个名为 deps.pex 的文件里, 同时再把代码部分给构建成到 .pex 文件里头。这两样东西, 最后都被统一上传到了云端那边。要是遇到快速构建这种情况了的话呢, 那就仅仅只去构建和上传那一个 .pex 文件就好了。在云平台的环境中, 大家能够重新启用一个现存的容器实例, 或者也可以直接提供一个新的容器实例, 来扮演代码服务器的角色。之后, 需要把 deps.pex 文件以及相关的 .pex 文件下载到这个被指定的代码服务器里面去。有了这些文件之后, 就可以借助它们在一个完全隔离的运行环境里让代码跑起来。我们始终不会采取在多个不同类型的用户群体之间共享同一个容器的做法。这是因为任何一个特定的容器内部所包含的所有执行环境资源, 在逻辑上都应该归属于单一的那个用户所独有。关于快速部署这项工作, 其预期的最顺利情况和可能的最差情况所涉及的时间线具体数据如下所示。其结果是, 在走快速构建Fast Build这条路径的时候, 我们在进行快速构建并且重用已经存在的容器的时候, 整个过程实际上只需要花费40秒的时间, 而不像从前那样必须花费超过3分钟的时间才能完成。我们来给这个功能起个名字, 这个名字就叫【快速部署】。现在, 所有新进行注册操作的无服务器用户, 都会默认把这个功能打开。权衡与问题快速地进行部署操作, 让部署的速度得到了极大的提升, 达到了以前的四到五倍之多, 但是呢, 这也带来了一些需要我们好好权衡考虑的问题, 同时还有其他的一些各种因素存在, 对于这些情况, 我们已经做出了一些相应的调整:目前, 我们确实能够在同一台代码服务器上同时运行多个环境。从代码层面来说, 这些环境之间是彼此隔离的。但是它们仍然要共享相同的内存资源和CPU资源。如果我们在这个容器里面安排了过多的环境, 并且其中的某一个环境占用了太多内存, 那么这样做的结果, 会对运行在同一个容器的其他环境, 产生不利的影响。可以在任何操作系统上为 Linux 构建 包因为目标 Linux 操作系统和 解释器在构建过程中是可用的。pex 只能为 Linux 构建提供轮子的包的 pex 文件。作为退路我们在构建过程中使用 容器来处理源码分发。这个步骤可以在未来被移到一个单独的共享服务中在构建镜像时, 可以进行深度的定制。你可以指定一个自定义的基础镜像, 而不是使用那些默认的*-slim镜像之一。为了实现功能上完全一致, 我们必须实施一种特定的方法。这种做法允许用户去指定他们自己所拥有的基础镜像。我们会在快速部署的过程中使用这种由用户指定的镜像。工作流程和 pex不少朋友估计都已经看到了, 在原图的那个画面里, 过去那种按照特定方式进行的下载操作, 大致需要耗费10秒钟的时间。那么问题来了, 我们究竟是通过什么巧妙的方法, 把这个原本存在的步骤给彻底地、完全地消除掉的呢以前, 我们的做法是把代码打包成镜像, 然后借助容器来进行操作。而现在的做法则是, 我们把动作代码打包成为一个 pex 文件, 把这个 pex 文件检入到动作仓库中去, 直接在运行器上面进行运行。这一变化省去了下载动作镜像以及启动该镜像所带来的时间成本, 与此同时, 我们仍然能够实现将所有依赖项一并打包的目的。另外, 我们还做了另一件小事, 就是干脆只用一个工作流作业。因为在每个工作启动的时候, 都得花10秒钟的功夫, 去重新配好一个新的运行环境。结论我们把部署的时间从三分钟以上给减少了, 现在只需要四十秒。这是一个非常巨大的加速效果, 所以我们对这样的结果感到非常满意, 尤其是当我们在自己测试自己的服务的时候。通过使用pex, 我们能够搭建出一个可以重复使用的、保持一致性的那种环境。我们对于使用这种把和某个系统给结合起来的组合方式感到十分高兴, 因为这样可以让我们有机会去探索其他的一些不一样的可能性。