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?
详细信息：
在远古时代，开发具有多个代码库的复杂应用程序时，通常希望每个项目拥有一个存储库，并拥有所有密码，凭证和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| |
| +------+ |
| |
+-----------------------------------------------------------------------+
在远古时代，一名sysadmin在服务器中安装了该软件，然后又复制了配置文件。早在90年代，sysop通常会将这些文件保存在他自己的目录中，并且仅与老板共享。
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服务器（泊坞窗之前）了解所有源代码存储库，了解目标网络拓扑，将密码输入云，并在目标中复制/构建/部署所有内容并进行配置，从而无需人工干预，前提是服务器已启动并运行。
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或CentO。
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 | |
| +----------------+ |
| |
+-----------------------------------------------------------------------+
在团队中，我们无法弄清正确的方法，因此我进行了搜索，但无法找到证明应将不同的Dockerfiles提交到应用程序存储库还是在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构建的通用文件，则必须将该文件放入每个git仓库！示例：ssh-key，令牌等
- 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存储库
- CI平台收到通知
- CI平台克隆应用程序git存储库
- CI平台克隆devops代码库，其中包含所有您组织的Dockerfile
- CI平台确定应用程序的性质，以选择正确的Dockerfile以及其他文件（例如entry-point.sh等）
- CI平台复制Dockerfile进入应用程序源代码根文件夹。
- CI平台执行 docker build ...
- CI平台执行 docker push ... （如果您有私有docker注册中心（推荐））
- 最后，CI Platform会在任何实例中对docker映像执行实例化（docker运行）远程服务器（预先安装了docker）
- 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/jrichardsz/tachikoma-ops 如果您只需要集中化应用程序的配置变量
- 这里有一些信息与应用程序配置的外部化有关： https://stackoverflow.com/a/51268633/3957754
- https://zookeeper.apache.org to store the plain files as node text for every application
- https://github.com/jrichardsz/tachikoma-ops 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屋！
