Dockerfile 应该提交到哪个代码存储库? [英] What code-repository should the Dockerfile get committed to?
问题描述
我应该在哪里提交 Dockerfile?在项目代码库中还是在 devops 代码库中?
Where should I commit the Dockerfile? In the project codebase or in the devops codebase?
推理细节:
在古代，当开发具有多个代码库的复杂应用程序时，人们通常希望每个项目有一个 repo，并将所有密码、凭据和 dev/test/pre/prod 配置与代码分开.
In the ancient times, when developing a complex application with multiple code-bases, one normally wanted to have one repo per project and have all the passwords, credentials and dev/test/pre/prod configurations separated from the code.
+-----------------------------------------------------------------------+
| |
| +---------+ +---------+ +---------+ +---------+ |
| | app-1 | | app-2 | | app-3 | | app-4 | |
| +---------+ +---------+ +---------+ +---------+ |
| |
| +----+ |
| | |\ |
| | +-+ |
| | conf | |
| | files| |
| +------+ |
| |
+-----------------------------------------------------------------------+
在古代，一个系统管理员在服务器中安装了软件，然后复制了配置文件.早在 90 年代，系统管理员通常将这些文件放在他自己的目录中，仅与老板共享.
In the old-ancient times one sysadmin installed the software in the server and then later copied the config files. Back in the 90's usually the sysop had those files in a directory of his own, shared only with the boss.
后来我们改进了循环:在 Continuos 开发/集成环境中，系统"本身需要能够克隆所有这些存储库并能够构建"应用程序并将它们配置为准备运行.然后将构建复制到服务器并相应地配置它们.
Later we improved the cycle: in Continuos development/integration environments, "the system" itself needs to be able to clone all those repos and be able to "build" the applications and configure them to be ready to be run. Then copy the build into the servers and configure them accordingly.
这使所有开发人员都可以在生产中触发部署，同时不会泄露密钥.
This enables all the developers to trigger deploys at production, still not compromising the secret keys.
在容器出现之前，公司通常有一个额外的devops"(AKA CI repo)，我们将所有这些配置文件组织起来并通过脚本了解.CI 服务器(docker 前)知道所有源代码存储库，知道目标网络拓扑，拥有云的密码，并复制/构建/部署其目标中的所有内容并对其进行配置，从而无需人工在服务器启动并运行的情况下进行干预.
Before containers, typically the companies had an extra "devops" (AKA CI repo) where we had all those config files organized and know by an script. The CI server (pre-docker) knows all the source-code repos, knows the destination-network-topology, has the passwords to the cloud, and copies/builds/deploys everything in its destination and also configures it, making unnecessary the human intervention provided the servers are up and running.
+-----------------------------------------------------------------------+
| |
| +---------+ +---------+ +---------+ +---------+ |
| | app-1 | | app-2 | | app-3 | | app-4 | |
| +---------+ +---------+ +---------+ +---------+ |
| |
| +----------------+ |
| | devops | |
| +----------------+ |
| | config-1-devel | |
| | config-1-pre | |
| | config-1-prod | |
| | config-2-devel | |
| | [...] | |
| | config-4-prod | |
| +----------------+ |
| |
+-----------------------------------------------------------------------+
使用 Docker 进行 CI
当谈到让 docker 在等式中发挥作用时，我想知道 Dockerfile 的正确位置是在应用程序 CVS 存储库中还是在 devops 存储库中.
CI with Docker
When it comes to make docker play a role in the equation, I wonder if the correct place to have the Dockerfile is inside the application CVS repository or in the devops repository.
除非我们做一个需要在多个平台上运行的开源代码，否则通常公司会建立一个目标平台，编码人员事先知道"目标系统将是 Ubuntu 或 CentOs 左右.
Unless we do an open-source code that needs to run in many platforms, usually the companies establish a target platform and the coders "know" the target system will be an Ubuntu, or a CentOs or so beforehand.
另一方面，现在编码人员自己将 Dockerfile 作为一个 moe 源代码文件.这促使我们认为 Dockerfile 适合每个代码库，因为应用程序和它运行的系统将 - 可能 - 需要某些要求来耦合.
On the other hand it is now that the coders themselves touch the Dockerfile as one moe source-code file. This pushes us to think that the Dockerfile fits in each code-base as the app and the system it runs in will be -probably- coupled by needing certain requirements.
+-----------------------------------------------------------------------+
| |
| +-------------+ +-------------+ +-------------+ +-------------+ |
| | app-1 | | app-2 | | app-3 | | app-4 | |
| +-------------+ +-------------+ +-------------+ +-------------+ |
| |Dockerfile-1 | |Dockerfile-2 | |Dockerfile-3 | |Dockerfile-4 | |
| +-------------+ +-------------+ +-------------+ +-------------+ |
| |
| +----------------+ |
| | devops | |
| +----------------+ |
| | config-1-devel | |
| | config-1-pre | |
| | config-1-prod | |
| | config-2-devel | |
| | [...] | |
| | config-4-prod | |
| +----------------+ |
| |
+-----------------------------------------------------------------------+
或者 Dockerfile 是否会进入 devops 代码库(也称为 CI 服务器代码库)?
但似乎程序员也应该执行相同的代码行，例如，如果他正在编写 Web 应用程序，尽管它是在 apache、nginx 或 caddy 服务器下运行的......所以决定"运行时的代码似乎应该被编码到 devops 代码库中:
Or will the Dockerfile go into the devops code-base (AKA the CI server code-base)?
But also it seems the programmer should do the very same lines of code, for example if he is coding a web application, despite it is run under an apache, an nginx or a caddy server... so the "decission" of the runtime seems it should be coded into the devops code-base:
+-----------------------------------------------------------------------+
| |
| +-------------+ +-------------+ +-------------+ +-------------+ |
| | app-1 | | app-2 | | app-3 | | app-4 | |
| +-------------+ +-------------+ +-------------+ +-------------+ |
| |
| +----------------+ |
| | devops | |
| +----------------+ |
| | Dockerfile-1 | |
| | Dockerfile-2 | |
| | Dockerfile-3 | |
| | Dockerfile-4 | |
| +----------------+ |
| | config-1-devel | |
| | config-1-pre | |
| | config-1-prod | |
| | config-2-devel | |
| | [...] | |
| | config-4-prod | |
| +----------------+ |
| |
+-----------------------------------------------------------------------+
在团队中，我们无法阐明正确的方法，我已经进行了搜索，但我无法找到证明不同的 Dockerfile 是否应该提交到应用程序存储库或 devops 存储库(AKA CI 存储库)中的文档.
In the team we can't clarify the proper way and I've searched but I am unable to find documentation that demonstrates if the different Dockerfiles should be committed into the app repos or in the devops repo (AKA CI repo).
我应该在哪里提交它们?
Where should I commit them?
推荐答案
也许如果组织有几个应用程序，将 Dockerfile 放入应用程序代码库就足够了.
Maybe if the organization have a few applications, a Dockerfile into app codebase could be enough.
但是，如果我们谈论的是数十种微服务、微前端、单体应用、遗留应用程序等，会发生什么?
But what happen if we are talking about dozens of microservices, microfrontends, monolithics, legacy apps, etc ?
让我们想象一个 Dockerfile、entrypoint.sh 和其他必需文件，它们是同一组织中的许多具有相同性质的应用程序(如 Java 微服务)的基础.如果 Dockerfile 进入代码库，这里需要考虑一些问题:
Let's imagine a Dockerfile, entrypoint.sh and other required files that are the base for dozens of applications with same nature like java microservices in the same organization. Here some issues to consider if the Dockerfile is into the code-base:
- 如果您需要更改此 Dockerfile 中的某些内容，则必须在每个微服务 git 存储库中进行更改.
- 您必须付出额外的努力来验证开发人员不会破坏此 Dockerfile，因为对于所有其他微服务都是一样的.我们能想象出几十个微服务，使用不同的 Dockerfile，我的意思是每个微服务都有自己的架构吗?
- 如果所有的微服务都需要一个通用的docker build文件，你必须把这个文件放在每个git仓库中！示例:ssh-key、tokens 等
- If you need to change something in this Dockerfile, you must will need to change in every microservice git repository.
- You must put an extra effort to validate developers don't break this Dockerfile, because is the same for all the others microservices. Can we imaginate dozens of microservices, with different Dockerfiles, I mean each of those with its own architecture?
- If the all microservices needs a common file for docker build, you must put this file in every git repository! Example : ssh-key, tokens, etc
基于我的数十个应用程序，我的建议正是您提到的.这里有一些优点:
My advice, based on my dozens of applications, is just what you mentioned. Here some advantages:
- 只需一个 Dockerfile 即可用于我的所有微服务(例如).
- 如果我需要升级或修复某些东西，我只需要更改一个 Dockerfile 即可.
- 开发人员可以看到并理解这个 Dockerfile，但永远不会破坏它.
如果您选择将 Dockerfile 放入 devops 代码库，而不是放入组织中的每个 git 存储库，您必须开发如下流程:
If you choose to put Dockerfile into the devops code-base instead into every git repository in your organization, you must need to develop a flow something like this:
- 开发者将代码推送到 git 仓库
- C.I 平台收到通知
- C.I 平台克隆应用程序 git 存储库
- C.I Platform 克隆了 devops 代码库，其中包含您组织的所有 Dockerfile
- C.I 平台确定应用程序的性质，选择正确的 Dockerfile 和其他文件，如 entry-point.sh 等
- C.I 平台将 Dockerfile 复制到应用源代码根文件夹中.
- C.I 平台执行 docker build ...
- C.I 平台执行 docker push ... 如果您有私有 docker 注册表(推荐)
- 最后，C.I 平台在任何远程服务器(预先安装了 docker)中执行 docker 镜像的实例化(docker run)
- Developer pushes code to git repository
- C.I Platform receive the notification
- C.I Platform clones the app git repository
- C.I Platform clones the devops code base, which contains all of Dockerfile of your organization
- C.I Platform determine the nature of app, to select the correct Dockerfile and other files like entry-point.sh, etc
- C.I Platform copy the Dockerfile into the app source code root folder.
- C.I Platform performs a docker build ...
- C.I Platform performs a docker push ... if you have a private docker registry (recommended)
- Finally, C.I Platform performs an instantiation (docker run) of the docker image in any of remote server (with docker previously installed)
我可以向您推荐 Jenkins，因为它易于使用
I could recommend you Jenkins, due to its ease of use
如果可能，我建议您不要在应用程序的构建阶段使用复杂的文件.开源技术可以很好地做到这一点，但如果您使用的是某些专有语言，那就太棒了 :S
I advice you, if possible, do not use complex files at build stage of your applications. Open source technologies are good to do that, but if you are using some proprietary language, you're toast :S
无论如何，如果您在构建阶段需要配置文件，您可以使用:
Anyway, if you need config files at build stage, you could use:
- https://zookeeper.apache.org 将纯文件存储为每个应用程序的节点文本
- https://github.com/software-architect-tools/configurators如果您只需要集中应用程序的配置变量
- 这里有一些与应用程序配置外化相关的信息:https://stackoverflow.com/a/51268633/3957754
- https://zookeeper.apache.org to store the plain files as node text for every application
- https://github.com/software-architect-tools/configurators if you just need centralize configuration variables of your applications
- Here some information related to externalization of applications configurations: https://stackoverflow.com/a/51268633/3957754
这篇关于Dockerfile 应该提交到哪个代码存储库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
