溜溜直播注册从 3 分以上到 40 秒Docker 容器 5 倍速

　　【CSDN 编者案】利用 pex 使我们可以在 Docker 之上成立一个可反复的、分歧的情况，我们很快乐利用这个 pex-on-docker 组合来探究其他的能够性。

　　Dagster 是一个数据编排器。在无效劳器 Dagster 云上，不需求成立当地开辟情况或云根底设备，就可以够开辟和布置 Dagster 代码。当你向 GitHub 提交修正时，GitHub Action 会间接构建和布置你的代码到 Dagster 云。你能够在用户界面中检察和互动你的 Dagster 工具。借助 Dagster 云，长途情况凡是用于让利用主动创立的暂存情况与协作者同享布置。小我私家当地开辟和同享长途情况相分离，构成了一个壮大的开辟周期。

　　当我们在 GitHub 上构建 Docker 镜像并将其布置到 Dagster 云时，每次提交都需求 3 到 5 分钟才气在 Dagster 用户界面上显现出来。无效劳器开辟职员凡是会在每次迭代中对代码停止小的窜改，但却每次都要等候 3 分钟以上才气看到窜改的结果，这类偶然义的等候很简单让人腻烦。我们阐发了一个成绩： 当你修正一行代码并提交后，会发作甚么？ 发明了以下的状况。

　　* 在启用缓存的状况下需求 60 秒（假如没有改动依靠干系的话）；假如依靠干系有变革，则需求 90 秒以上。

　　Docker 镜像是由仓库中的多个层堆叠而成的，此中每层都是由 Docker 文件中的一个号令子集构建的；

　　利用 GitHub Actions 缓存在 GitHub 构建机上重修镜像时，会将一切未受影响的层从缓存中拉到构建机上。请留意，假如你的项目中有大批的依靠干系没有改动，它们会在构建过程当中从缓存中一同被复制到构建机械上；

　　Docker 的构建不是肯定性的。假如你用完整不异的内容构建一个镜像两次，每次都能够发生差别的哈希值。 ( 固然不间接相干，但我们想记载一下这个不测的察看成果。作为一个极度案例，思索到一个新构建的大层与曾经在注册表中的层不异，仍旧能够作为一个新的层被上传）。

　　在 Docker 镜像成立和启动后，我们运转用户的代码来提取元数据，显现在用户界面上。这一步没法制止，能够需求几秒钟到 30 秒，以至更久，这取决于元数据的计较方法（好比它能够毗连到数据库来读取形式）。这个代码效劳器连结举动形态，为元数据恳求供给效劳，溜溜直播注册直到推送新版本的代码，然后启动一个新的容器。

　　我们的一个枢纽请求是可反复性：我们需求可以屡次从头布置完整不异的代码和情况。利用 Docker 镜像的哈希值作为代码和情况的标识符，能够很好地满意这一请求。

　　从 Fargate 切换到 EC2，以放慢容器的启动。这将增长我们的运营承担，请求我们预先供给、监控和扩大我们的集群。我们仍旧会碰到 Docker 构建迟缓的成绩；

　　换成差别的 Docker 构建体系，如 AWS CodeBuild。这将需求更多的布置事情，并与 GitHub 停止更深化的整合。今朝还不分明如许做的报答能否值得；

　　切换到 AWS Lambda，启开工夫快很多。Lambda 情况有本人的根底镜像，关于自界说需求来讲不太友爱。并且它的施行工夫另有 15 分钟的限定，这对运转工夫较长的效劳器来讲，需求庞大的变通办法；

　　经由过程构建并只上传修正后的代码到统一效劳器，从头利用持久运转的代码效劳器。这里的应战是完成打包和运转机制，以确保一个牢靠和可反复的施行情况。我们研讨了各类打包和分发 Python 情况的办法，包罗 rsync、poetry、nix、shiv 和 pex。还思索了利用 EFS 卷来挂载 Python 情况，与这些东西相分离。

　　我们作出终极决议背后的有一个枢纽身分，是意想到固然 Docker 镜像是行业尺度，但假如我们只需求同步一个小的变革时，就去挪动 100 多兆的镜像，是很没必要要的沉重操纵。思索到 Git 只供给差别，但却能发生完好而分歧的存储库。因而我们偏向于计划 4，只需求能找到一个适宜的东西来做大部门的事情。颠末一些尝试，我们发明 pex 的很多功用对我们的用例十分有用。

　　pex 是 Python Executable 的缩写，它是一种将 Python 包到称为 pex 文件的东西。这些是可施行文件，此中包罗 Python 包和一些指导代码。比方，我们能够把 dagster 包和它的依靠项成一个文件，然后运转它。

　　将全部情况放在一个文件中，便于运输和存储在 S3 中。pex 供给的不单单是一个 文件中的假造情况 ，以下是我们利用的其他功用。

　　在运转时，pex 情况与其他网站范畴内的包完整断绝。情况中独一存在的包是那些在 pex 文件中的包。我们将多个 pex 文件输送到统一台机械上，而没必要担忧情况断绝成绩。

　　这让我们有自信心用内容寻址来辨认这些 pex 文件。为了完成可反复性，除 Docker 镜像的哈希值，还利用 pex 文件哈希值。

　　我们用它把代码分红两部门，在运转时兼并：一个包罗一切依靠干系的 deps.pex 文件和一个只包罗用户代码的 source.pex 文件。

　　我们在无效劳器云中利用 Linux python :*-slim 衍生的根底镜像。只需软件包的轮子可用， pex 东西能够在任何平台上为 Linux 构建 pex 文件。

　　我们利用 pex 与 S3 相分离来存储 pex 文件，成立了一个别系，此中快速途径制止了构建和启动 Docker 镜像的开消。

　　我们的体系是如许事情的：当你向 GitHub 提交接码时，GitHub Action 要末停止完整构建，要末停止快速构建，这取决于你的依靠干系自前次布置后能否有变革。我们跟踪 setup.py 和 requirements.txt 中指定的依靠项。

　　关于一个完好的构建，将项目依靠性构建到 deps.pex 文件，将代码构建到 source.pex 文件。二者都被上传到 Dagster 云端。关于快速构建，只构建和上传 source.pex 文件。

　　快速布置极大地进步了布置速率（4-5 倍），但它伴跟着一些需求衡量的成绩和其他身分，我们曾经停止了调解：

　　固然我们如今能够在一个代码效劳器上运转多个情况，而且它们在代码上是断绝的，但它们仍旧同享不异的内存和 CPU。假如我们在一个容器上放了太多的情况，并且一个情况占用了太多的内存，就会对统一容器中的其他运转情况发生倒霉的影响；

　　Docker 能够在任何操纵体系上为 Linux 构建 Python 包，由于目的 Linux 操纵体系和 Python 注释器在构建过程当中是可用的。pex 只能为 Linux 构建供给轮子的包的 pex 文件。作为退路，我们在构建过程当中利用 Docker 容器来处置源码分发。这个步调能够在将来被移到一个零丁的同享效劳中；

　　在构建 Docker 镜像时，能够停止深度定制，比方，你能够指定一个自界说的根底镜像，而不是默许的 python :*-slim 镜像之一。为了完成功用上的对等，我们必需施行一种办法，让用户指定他们本人的根底 Docker 镜像，我们在快速布置时利用这类镜像。

　　我们做的另外一个小优化是，只利用一个 GitHub 事情流功课。在 GitHub 中的每个事情启动都需求 10 秒钟来设置一个新的运转器。

　　将布置工夫从 3 分钟以上削减到 40 秒，是一个明显的加快，我们对这个成果十分合意，出格是当测试本人的效劳时。利用 pex 使我们可以在 Docker 之上成立一个可反复的、分歧的情况，我们很快乐利用这个 pex-on-docker 组合来探究其他的能够性。