我是新接触docker的,我已经在docker上做了一些基础工作,比如如何构建镜像,如何创建容器,什么是dockerfile.yml,docker-compose.yml文件做什么等等。当使用docker进行实时开发时,我有以下问题。
1)团队中的每个开发者都必须在docker上进行开发,并在本地机器上创建镜像并将其推送到docker注册表中吗?或者开发人员在没有docker的情况下工作,一个人将从提交的代码中创建最终图像?
2)对于每个版本,我们是维护该版本的容器还是镜像?
3)维护数据库的最佳实践是什么?是将数据库合并到镜像中并构建容器,还是只包含与应用程序相关的内容并构建镜像和容器,此容器将与外部容器中的数据库或物理数据库服务器进行通信?
提前谢谢。
发布于 2019-03-29 21:10:40
像这样的问题通常没有明确的答案。这在很大程度上取决于您的公司、您的团队、正在使用的工具、软件堆栈等。最好的做法是依靠您组织中的高级开发资源和高级技术领导来帮助确定此类问题的答案。
将以下答案视为盐的筒仓,因为没有办法确切地回答这些问题。
1)取决于什么对开发人员最方便,以及您使用的是什么语言。一些开发人员发现全容器工作流很方便,一些开发人员发现他们可以使用现有的IDE/CLI工作流更快地迭代,并最后测试运行的容器映像。
在大多数情况下,您会希望让CI/CD工具来处理用于生产的构建。
2)可以。您可以使用容器标签来实现此目的。
3)在容器中运行数据库是可能的,但除非您的团队对容器和容器编排有经验,否则我会将数据库放在传统的裸机或VM上。
容器是单个linux进程的花哨包装器。一般来说,经验法则是一个进程使用一个容器。你不应该在一个容器中组合多个东西。(当您转到Red、OpenShift或Kubernetes之类的东西时,这个故事会变得稍微复杂一些,因为讨论的焦点是每个pod有多少容器)。
发布于 2019-03-29 21:22:51
node_modules目录或Python的虚拟环境这样的工具可以帮助将子项目彼此隔离。任何开发人员都应该能够运行docker build来构建映像,但通常在测试特定更改的最后阶段之前不需要这样做。你应该部署一个持续集成系统,它将负责测试和构建每个提交的最终Docker镜像。没有什么技术原因你不能使用Docker Compose进行生产,但是如果你最终需要在多个物理服务器上部署你的应用程序,你可能会发现它是有限的。Kubernetes更复杂,但似乎是该领域当前的赢家;Docker Swarm有一些势头;Hashicorp Nomad就在那里;或者您可以手动构建一个手动部署系统。(请注意,至少Kubernetes和Nomad都非常重视“某些东西发生了变化,所以我要删除并重新创建一个容器”的概念,而且两者都使得在准生产环境中进行实时开发变得非常棘手。)
还要注意,我所说的“部署”有所有这些东西的公共云版本(Docker Hub、CircleCI、端到端解决方案,包括注册表和构建在亚马逊网络服务、Azure或GCP之上的Kubernetes ),如果您对在构建/部署链中使用外部服务的成本权衡和影响感到满意,那么这些可以帮助您更快地开始
https://stackoverflow.com/questions/55417761
复制相似问题