Docker容器5倍速度部署实战.docx

《Docker容器5倍速度部署实战.docx》由会员分享，可在线阅读，更多相关《Docker容器5倍速度部署实战.docx（8页珍藏版）》请在第一文库网上搜索。

1、Docker容器5倍速度部署实战1无服务器开发和反馈循环Dagster是一个数据编排器。在无服务器Dagster云上，不需要建立本地开发环境或云基础设施，就可以开发和部署Dagster代码。当你向GitHub提交修改时，GitHubAction会直接构建和部署你的代码到Dagster云。你可以在用户界面中查看和互动你的Dagster对象。借助Dagster云，远程环境通常用于让使用自动创建的暂存环境与合作者共享部署。个人本地开发和共享远程环境相结合，形成了一个强大的开发周期。最初，我们在这上面使用了基于Docker的标准构建流程。然而我们很快发现，这让编辑-部署-运行的周期变得非常繁琐缓慢。为

2、了加快速度，我们构建了一个系统，实现在Docker镜像之外运送代码。这篇文章描述了我们分析的问题、确定的解决方案，以及在这个过程中做出的各种权衡。2.Docker镜像的问题当我们在GitHub上构建Docker镜像并将其部署到Dagster云时，每次提交都需要3到5分钟才能在Dagster用户界面上显示出来。无服务器开发人员通常会在每次迭代中对代码进行小的改动，但却每次都要等待3分钟以上才能看到改动的效果，这种无意义的等待很容易让人厌烦。我们分析了一个问题：“当你修改一行代码并提交后，会发生什么？”发现了以下的情况。我们分析了当你改变一行代码并提交时会发生什么，发现了以下情况。20sTProv

3、isionGitHubrunneranddown1oadactions10s-Down1oadDockerbasedaction60sTBui1dandup1oaduser*sDockerimage*90sTRunuser,sDockerimageinAWS180sruntime,Takes60swithcachingenab1ed,ifnodependencieshavechanged.Takes90s+ifdependencieshavechanged. 20s提供GitHub运行器并下载动作 IOs下载基于DoCker的行动 60s建立并上传用户的Docker镜像*。 90s在AWS中运

4、行用户的Docker镜像 180s的运行时间*在启用缓存的情况下需要60秒（如果没有改变依赖关系的话）；如果依赖关系有变化，则需要90秒以上。如你所见，花费时间最长的两件事是：构建一个Docker镜像（60-90多秒）部署Docker容器（90秒）那就让我们来看看这两件事都做了些什么。3 .构建Docker镜像关于构建Docker镜像需要注意的一些事情。1 .Docker镜像是由堆栈中的多个层堆叠而成的，其中每一层都是由Docker文件中的一个命令子集构建的；2 .每一层都由一个哈希值来识别；3 .当上传镜像到注册表时，只有不存在于注册表中的层（由哈希值识别）被上传；4,使用GitHubAct

5、ions缓存在GitHub构建机上重建镜像时，会将所有未受影响的层从缓存中拉到构建机上。请注意，如果你的项目中有大量的依赖关系没有改变，它们会在构建过程中从缓存中一起被复制到构建机器上；5 .Docker的构建不是确定性的。如果你用完全相同的内容构建一个镜像两次，每次都可能产生不同的哈希值。（虽然不直接相关，但我们想记录一下这个意外的观察结果。作为一个极端案例，考虑到一个新构建的大层与已经在注册表中的层相同，仍然可能作为一个新的层被上传）。4 .启动DoCker容器关于启动Docker容器需要注意的是，我们使用AWSFargate,它需要45到90秒的时间来配置和启动一个镜像。且不提供任何图像

6、缓存。启动一个新的容器会从注册表中下载所有的层到配置的容器上。5 .其他限制在Docker镜像建立和启动后，我们运行用户的代码来提取元数据，显示在用户界面上。这一步无法避免，可能需要几秒钟到30秒，甚至更久，这取决于元数据的计算方式（比如它可以连接到数据库来读取模式）。这个代码服务器保持活动状态，为元数据请求提供服务，直到推送新版本的代码，然后启动一个新的容器。我们的一个关键要求是可重复性：我们需要能够多次重新部署完全相同的代码和环境。使用Docker镜像的哈希值作为代码和环境的标识符，可以很好地满足这一要求。6 .备选方案综述除了上述的方案以外，我们还探索和讨论了一些替代方案。1 .从Far

7、gate切换到EC2,以加快容器的启动。这将增加我们的运营负担，要求我们预先提供、监控和扩展我们的集群。我们仍然会遇到Docker构建缓慢的问题；2 .换成不同的Docker构建系统，如AWSCodeBui1do这将需要更多的部署工作，并与GitHub进行更深入的整合。目前还不清楚这样做的回报是否值得；3 .切换到AWS1ambda,启动时间快得多。1ambda环境有自己的基础镜像，对于自定义需求来说不太友好。而且它的执行时间还有15分钟的限制，这对运行时间较长的服务器来说，需要复杂的变通方法；4 .通过构建并只上传修改后的代码到同一服务器，重新使用长期运行的代码服务器。这里的挑战是实现打包和

8、运行机制，以确保一个可靠和可重复的执行环境。我们研究了各种打包和分发Python环境的方法，包括rsyncpoetry、nix、shiv和peo还考虑了使用EFS卷来挂载PythOn环境，与这些工具相结合。我们作出最终决定背后的有一个关键因素，是意识到虽然Docker镜像是行业标准，但如果我们只需要同步一个小的变化时，就去移动100多兆的镜像，是很不必要的繁重操作。考虑到Git只提供差异，但却能产生完整而一致的存储库。因此我们倾向于方案4,只需要能找到一个合适的工具来做大部分的工作。经过一些实验，我们发现pex的许多功能对我们的用例非常有效。7 .什么是PEX?pex是PythonExecut

9、ab1e的缩写，它是一种将Python包捆绑到称为pex文件的工具。这些是可执行文件，其中包含Python包和一些引导代码。例如，我们可以把dagster包和它的依赖项捆绑成一个文件，然后运行它。%pexdagster-python=python3.8-odagster.pex%./dagster.pexPython3.8.16(defau1t,Dec72023,01:24:57)C1ang14.0.0(c1ang-1400.0.29,202)ondarwinTypehe1p,copyright,creditsor1icenseformoreinformation.(InteractiveCo

10、nso1e)importdagster将整个环境放在一个文件中，便于运输和存储在S3中。PeX提供的不仅仅是一个文件中的虚拟环境，以下是我们使用的其他功能。1 .隔离在运行时，pex环境与其他网站范围内的包完全隔离。环境中唯一存在的包是那些捆绑在pex文件中的包。我们将多个pex文件运送到同一台机器上，而不必担心环境隔离问题。2 .确定性使用相同的输入包会产生位对位的相同的pex文件。$pexdagsterpandas-oout.pexsha256sume3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855-$pexda

11、gsterpandas-oout.pexsha256sume3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855-这让我们有信心用内容寻址来识别这些pex文件。为了实现可重复性，除了DOCker镜像的哈希值，还使用PeX文件哈希值。3 .组成多个pex文件可以在运行时合并，有效地将环境合并成一个。%pexpandas-opandas.pex%pexdagster-odagster.pex%PEX_PATH=pandas.pex./dagster.pexPython3.8.16(defau1t,Dec72023y01:24

12、:57)C1ang14.0.0(c1ang-1400.0.29.202)ondarwinTypehe1p,copyright,creditsornIicenseformoreinformation.(InteractiveConso1e)importpandasimportdagster我们用它把代码分成两部分，在运行时合并：一个包含所有依赖关系的deps.pex文件和一个只包含用户代码的source.pex文件。4 .跨平台的构建我们在无服务器云中使用1inuxpython:*-SIiin衍生的基础镜像。只要软件包的轮子可用，pex工具可以在任何平台上为1inux构建pex文件。8 .快速部

13、署我们使用pex与S3相结合来存储pex文件，建立了一个系统，其中快速路径避免了构建和启动Docker镜像的开销。我们的系统是这样工作的：当你向GitHub提交代码时，GitHubAction要么进行完全构建，要么进行快速构建，这取决于你的依赖关系自上次部署后是否有变化。我们跟踪setup.py和requirements.txt中指定的依赖项。对于一个完整的构建，将项目依赖性构建到deps.pex文件，将代码构建到source.pex文件。两者都被上传到Dagster云端。对于快速构建，只构建和上传SOUrCe.pex文件。在Dagster云中，可以重新使用一个现有的容器或提供一个新的容器作为

14、代码服务器。将deps.pex和source.pex文件下载到这个代码服务器上，并使用它们在一个隔离的环境中运行代码。我们从不在用户之间共享一个容器，一个容器上的所有环境都属于同一个用户。快速部署的最佳情况和最坏情况的时间线如下。depnRunuserssource.peonacontainerthathasdeps.pex35sruntimenoexistingcontainerfoundFu11Bui1d10s-ProvisionGitHubrunneranddown1oadactionsBui1dandup1oadthesource.pefi1e60s-withuserscodeandt

15、hedeps.pexwithdependencies90s-RUnabasedockerimageinAWSandruntheuser(ssource.peanddeps.pexonit.160sruntime其结果是，在快速构建(FaStBUiId)的路径中，当我们进行快速构建并重用现有容器时，整个过程只需40秒，而不像以前一样需要3分钟以上。我们将这一功能称为【快速部署】，现在所有新注册的无服务器用户都默认开启这一功能。9 .权衡与问题快速部署极大地提高了部署速度(4-5倍)，但它伴随着一些需要权衡的问题和其他因素，我们已经进行了调整:1 .虽然我们现在可以在一个代码服务器上运行多个环境，并且它们在代码上是隔离的，但它们仍然共享相同的内存和CPUo如果我们在一个容器上放了太多的环境，而且一个环境占用了太多的内存，就会对同一容器中的其他运行环境产生不利的影响；2 .Docker可以在任何操作系统上为1inUX构建Python包，因为目标1in