河南网站建站系统平台,架设wordpress,wordpress参数传递的函数,含山县住房和城乡建设局网站在构建容器化的应用时#xff0c;开发人员往往需要某种方法来引导启动目标容器#xff0c;以对其进行代码级别的测试。尽管业界有许多方法可以实现该目的#xff0c;但Docker Compose是目前最受欢迎的一种方法。它能够让如下两个方面变得容易实现#xff1a;指定在开发过程… 在构建容器化的应用时开发人员往往需要某种方法来引导启动目标容器以对其进行代码级别的测试。尽管业界有许多方法可以实现该目的但Docker Compose是目前最受欢迎的一种方法。它能够让如下两个方面变得容易实现指定在开发过程中需要启动的容器。设置一套快速的代码测试调试(code-test-debug)以方便开发循环。通常情况下团队事先编写一个docker-compose.yml文件指定开发所需的所有内容并将其提交给存储库。然后每个开发人员只需运行docker-compose up即可启动测试其代码所需的所有容器。不过要让docker-compose的设置能够达到最佳性能状态例如在不到一分钟之内启动开发环境并且在几秒钟内完成对每个更改的测试这些都需要团队花费大量的工作。在这些准备过程中由于各个开发人员每天花费在测试其代码上的时间各不相同而且任何细微的改动都可能会对整个开发团队的生产力产生巨大的影响。因此我们有必要在此讨论他们在编写Docker Compose时常见的五大错误及其对应的解决方法。错误1频繁地进行容器重建Docker的构建往往比较耗时特别是每次针对代码的变更开展测试的时候。如果能够节省此方面的时间那么对于加快开发周期来说是十分有益的。过去对于非容器化的应用我们通常会采取如下传统的工作流程编写代码构建运行多年来业界持续优化该流程并提出了诸如针对编译语言的增量构建和热重载(hot reloading)等实用技巧。随着容器技术的出现我们在现有的工作流程中增加了docker构建的步骤如下图所示。编写代码构建Docker构建运行当然如果构建得不好那么docker构建步骤也可能会带来额外的时间开销。例如使用apt-get进行依赖项的重载步骤。有时候这些步骤可能会让整个测试过程比添加Docker之前还要慢。解决方案在Docker外部运行代码第一种解决方法是在Docker Compose中启动所有的依赖项然后在本地运行测试代码。此举模仿了非容器化应用开发的工作流程。您只需向localhost公布依赖关系然后将正在使用的服务指向所有的localhost:地址即可。但是该方法并非永远可行如果您正在使用的是代码依赖容器镜像中的内置元素时那么用户电脑就不一定能够访问到具体内容。解决方案最大化缓存以优化Dockerfile如果必须构建Docker镜像那么我们可以编写Dockerfile通过最大化缓存将Docker的构建时间从原来的10分钟压缩至1分钟。在生产环境中Dockerfile的典型模式是通过将单个命令链接到一条RUN语句中来减少层级的数量。毕竟在开发过程中镜像的大小并不重要重要的是层级的数量。下面展示的是在生产环境中的一个Dockerfile文件RUN \ go get -d -v \ go install -v \ go build不过该命令在每次被重新运行时Docker都会重新下载所有的依赖项并重新安装它们。我们可以通过增量构建(incremental build)来提供效率。同时您可以将开发专用的Dockerfile其分成几个短小的步骤从而使得那些经常更改的代码步骤被排到最后而将鲜少更改的步骤(例如拉式依赖关系)被放在首位。因此在重建Dockerfile时您不必构建整个项目而只需构建那些被已更改的少量末尾块即可。有关此方面的案例您可以参阅以下用于Blimp(请参见--https://kelda.io/blimp)开发的Dockerfile。通过遵循上述方法您可以将繁琐的构建过程缩减到了几秒钟之内完成。FROM golang:1.13-alpine as builder RUN apk add busybox-static WORKDIR /go/src/github.com/kelda-inc/blimp ADD ./go.mod ./go.mod ADD ./go.sum ./go.sum ADD ./pkg ./pkg ARG COMPILE_FLAGS RUN CGO_ENABLED0 go install -i -ldflags ${COMPILE_FLAGS} ./pkg/... ADD ./login-proxy ./login-proxy RUN CGO_ENABLED0 go install -i -ldflags ${COMPILE_FLAGS} ./login-proxy/... ADD ./registry ./registry RUN CGO_ENABLED0 go install -i -ldflags ${COMPILE_FLAGS} ./registry/... ADD ./sandbox ./sandbox RUN CGO_ENABLED0 go install -i -ldflags ${COMPILE_FLAGS} ./sandbox/... ADD ./cluster-controller ./cluster-controller RUN CGO_ENABLED0 go install -i -ldflags ${COMPILE_FLAGS} ./cluster-controller/... RUN mkdir /gobin RUN cp /go/bin/cluster-controller /gobin/blimp-cluster-controller RUN cp /go/bin/syncthing /gobin/blimp-syncthing RUN cp /go/bin/init /gobin/blimp-init RUN cp /go/bin/sbctl /gobin/blimp-sbctl RUN cp /go/bin/registry /gobin/blimp-auth RUN cp /go/bin/vcp /gobin/blimp-vcp RUN cp /go/bin/login-proxy /gobin/login-proxy FROM alpine COPY --frombuilder /bin/busybox.static /bin/busybox.static COPY --frombuilder /gobin/* /bin/最后值得一提的是随着多阶段构建(multi-stage builds请参见--https://docs.docker.com/develop/develop-images/multistmuage-build/)的引入我们如今可以创建各种具有良好分层和较小镜像的Dockerfile。不过我们在此并不会展开详细的讨论。解决方案使用主机卷(host volumes)大多数语言都会提供一种方法来监视程序代码并在代码发生更改时自动重新运行。例如nodemon就是JavaScript语言的一种Node自动重启工具(请参见--https://www.npmjs.com/package/nodemon)。由于主机卷可以将您电脑上的目录镜像到正在运行的容器之中因此您在使用文本编辑器来编辑文件时各种更改将会被自动同步到容器中并在容器内被立即执行。最初您可能需要花点时间进行前期准备之后在Docker中您可以在1-2秒内马上看到代码的更改结果。因此我们会选择使用主机卷将代码直接挂载到容器中以便以原生的方式在包含其了运行时依赖项的Docker容器中运行自己的代码。错误2缓慢的主机卷如果您使用过主机卷那么是否已经注意到在Windows和Mac上读写文件的速度可能会非常缓慢?其实对于诸如Node.js和具有复杂依赖性的PHP应用程序之类需要读写大量文件的命令而言这是一个已知的问题。其背后的原因是Docker主要运行在Windows和Mac上的VM中。而我们在进行主机卷的挂载时它必须经过大量的转换才能使文件夹进入容器这有点类似于网络文件系统。而此类额外的开销在Linux本地运行Docker时则不会出现。解决方案放宽强一致性该问题的一个关键原因是文件系统在默认挂载时需要保持强一致性。也就是说所有特定文件的读写进程都必须统一对于文件修改的顺序以便让文件的内容达成最终的一致。可是强一致性的代价非常昂贵它需要所有文件的写入进程之间持续保持协调以确保它们不会干扰或破坏彼此的更改。虽然在生产环境中的数据库需要保持强一致性。但是在开发过程中由于写入进程就是代码文件本身目标就是我们的存储库因此强一致性就不那么必需了。那么我们就可以考虑Docker在挂载卷时放宽强一致性。例如在Docker Compose中我们可以简单地将此cached关键字添加到卷挂载中以获得显著的性能保证。对应的代码如下volumes: - ./app:/usr/src/app/app:cached注意此举仅适合开发环境不适合生产环境。解决方案代码同步另一种处置方法是设置代码的同步。您可以使用工具侦测主机和容器之间的变化通过复制文件来解决差异(类似于rsync)而不是挂载卷。Docker在最新的版本中内置了用来替代卷的缓存模式--Mutagen(请参见--https://mutagen.io/)。此外上文提到的Blimp则使用Syncthing(请参见--https://http//syncthing.net/)实现了类似的功能。解决方案不要挂载软件包Node之类的语言通常会把大部分文件操作放在packages目录中(如node_modules)。那么我们可以试着从卷中去除此类目录以显著提高性能。下列示例是一个将代码挂载到容器中的专属卷它覆盖了node_modules目录。volumes: - .:/usr/src/app - /usr/src/app/node_modules该挂载操作会告诉Docker去使用node_modules目录下的标准卷以使得在npm install运行时不再使用慢速的主机挂载方式。为了使该工作能够正常进行我们应该在容器首次启动时在entrypoint中执行npm install以安装依赖项并更新node_modules目录。具体代码如下entrypoint: - sh - -c - npm install ./node_modules/.bin/nodemon server.js如果您想查看并运行上述完整的示例请参考--https://kelda.io/blimp/docs/examples/#nodejs。错误3脆弱的配置如果您曾深入研究过代码您可能会发现Docker Compose中也充斥着各种大量复制和粘贴而来的代码。显然我们需要干净整洁的Docker Compose文件以方便轻松地按需做出修改。解决方案使用各种env文件Env文件能够将环境变量与Docker Compose主配置分开以实现避免将代码泄露到git的历史记录中。开发人员都能按需自定义设置。例如每个开发人员都可以持有一个唯一的访问密钥。他们通过将配置保存在.env文件中以实现不必修改已提交的docker-compose.yml文件也不必在文件更新时处理各种冲突问题。如果您想使用环境文件只需添加一个.env文件或设置带有env_file字段的显式路径即可(请参见--https://docs.docker.com/compose/environment-variables/#the-env_file-configuration-option)。解决方案使用替代文件替换文件(请参见--https://docs.docker.com/compose/extends/)可以方便您在具有基本配置的基础上在其他文件中指定各项修改。该功能非常适合Docker Swarm及其YAML文件。您可以将生产环境的配置存储在docker-compose.yml中然后在替代文件中指定开发所需的任何修改(例如使用主机卷)。解决方案使用extends如果您使用的是Docker Compose v2那么就可以使用extends关键字在多个位置导入YAML片段。例如您可能会定义公司里所有的服务都需要在开发的Docker Compose文件中带有某五个特定的配置。然后您可以使用extends关键字将其放置到任何需要的地方以实现模块化。当然如果仅在YAML中执行此项操作可能比较繁琐我们完全可以通过编程来实现。虽然Compose v3删除了对于extends关键字的支持。但是您仍然可以使用YAML anchors(请参见--https://support.atlassian.com/bitbucket-cloud/docs/yaml-anchors/)来实现类似的结果。错误4乱序启动(Flaky Boots)如果docker-compose出现了崩溃我们能够仅使用docker-compose restart来重启服务吗?其实此类问题主要与服务错误的启动顺序有关。例如您的Web应用可能依赖于数据库那么在Web应用启动时如果数据库尚未准备就绪就会出现崩溃。解决方案使用depends_ondepends_on使您可以控制启动的顺序。默认情况下depends_on仅判断依赖项是否已经创建而不会判断依赖项是否“健康”。虽然Docker Compose v2能够支持将depends_on与运行状况的检查相结合。不过该功能也在Docker Compose v3中被去除了。当然您可以使用诸如wait-for-it.sh之类的脚本来手动实现类似的功能。和上面提到的放宽强一致性相同虽然Docker文档不建议在生产环境中使用depends_on和wait-for-it.sh来为容器指定特定的启动顺序。但是对于开发而言我们完全可以用到depends_on。错误5资源管理不善如果您碰到开发流程受阻Docker无法全速运行或是无法平稳地获取运行所需的资源那么您可以考虑以下几个方面解决方案更改Docker Desktop的分配Docker Desktop需要大量的RAM和CPU尤其是在Mac和Windows的VM上。Docker Desktop的默认配置往往不会分配足够的RAM和CPU因此我们通常需要调整相关的设置。在开发时我经验是为Docker分配大约8GB的RAM和4个CPU并且在不使用Docker Desktop时及时关闭之。解决方案删除未使用的资源人们在使用Docker时经常会出现数百个卷与旧的容器镜像。这在无形中浪费了各种资源。为了释放这些资源我们建议通过间或运行docker system prune的方式以删除当前未使用到的所有卷、容器和网络。总结总的说来为了改善开发人员在使用Docker Compose时的体验我建议您做到如下五点最小化容器的重建。使用主机卷。像对待代码那样认真配置文件以便于维护。让启动更加可靠。认真分配管理资源。此外您还可以通过链接--https://kelda.io/blog/docker-volumes-for-development/以获悉如何设置主机卷并加快Docker开发。Java帮帮非盈利学习社区官网www.javahelp.com.cn职涯宝帮助职业者成功分享优质内容官网:zhiya360.com九点编程深夜学习未来可期
