如何在 DevOps 生命周期的开发阶段使用 docker? [英] How to use docker in the development phase of a devops life cycle?

问题描述

我有几个关于在开发阶段使用 Docker 的问题.

I have a couple of questions related to the usage of Docker in a development phase.

我将提出三种不同的方案，说明我认为 Docker 可以在开发环境中使用的方式.假设我们正在用 Java 和 Spring Boot 创建一个 REST API.为此，我需要一个 MySQL 数据库.

I am going to propose three different scenarios of how I think Docker could be used in a development environment. Let's imagine that we are creating a REST API in Java and Spring Boot. For this I will need a MySQL database.

1. 第一个场景是使用 docker-compose 使用 MySQL 容器进行开发，并使用另一个容器中的 MySQL 和 Java 应用程序 (jar) 进行生产 docker-compose.为了开发，我启动 docker-compose-dev.yml 以仅启动数据库.使用 IDE(例如 IntelliJ Idea)启动和调试应用程序.对代码所做的任何更改，IDE 将通过应用更改来识别并重新启动应用程序.

1. The first scenario is to have a docker-compose for development with the MySQL container and a production docker-compose with MySQL and the Java application (jar) in another container. To develop I launch the docker-compose-dev.yml to start only the database. The application is launched and debugged using the IDE, for example, IntelliJ Idea. Any changes made to the code, the IDE will recognize and relaunch the application by applying the changes.

第二个场景是，对于开发和生产环境，都有一个带有数据库和应用程序容器的 docker-compose.这样，每次我对代码进行更改时，我都必须重建映像，以便将更改加载到映像中并再次启动容器.这种场景可能是最典型的，用于使用 Docker 进行开发，但由于每次发生变化时都需要重建映像，因此看起来很慢.

The second scenario is to have, for both the development and production environment, a docker-compose with the database and application containers. That way, every time I make a change in the code, I have to rebuild the image so that the changes are loaded in the image and the containers are lauched again. This scenario may be the most typical and used for development with Docker, but it seems very slow due to the need to rebuild the image every time there is a change.

第三种情况是前两种情况的混合.两个 docker-compose.开发 docker-compose 包含两个容器，但具有允许实时重新加载应用程序、映射卷和使用例如 Spring Dev Tools 的机制.通过这种方式，启动容器，如果文件发生任何更改，应用程序容器将检测到更改并重新启动.对于生产，docker-compose 将简单地使用两个容器创建，但没有实时重新加载的功能.在我看来，这将是理想的情况，但我认为这非常依赖于所使用的技术，因为并非所有技术都允许实时重新加载.

The third scenario consists of the mixture of the previous two. Two docker-compose. The development docker-compose contains both containers, but with mechanisms that allow a live reload of the application, mapping volumes and using, for example, Spring Dev Tools. In this way, the containers are launched and, in case of any change in the files, the application container will detect that there is a change and will be relaunched. For production, a docker-compose would be created simply with both containers, but without the functionality of live reload. This would be the ideal scenario, in my opinion, but I think it is very dependent on the technologies used since not all allow live reload.

问题如下.

• 在使用 Docker 进行阶段时，这些场景中哪些最典型?

• Which of these scenarios is the most typical when using Docker for phase?

情景 1 提出得好吗?即仅dockerize外部服务，如数据库、队列等，使用IDE进行应用的开发和调试，不使用Docker.

Is scenario 1 well raised? That is, dockerize only external services, such as databases, queues, etc. and perform the development and debugging of the application with the IDE without using Docker for it.

在我提出场景2的问题之后，我提出的疑问和场景就出现了.随着代码的每次更改，必须重新构建映像并再次启动容器是对时间的重大浪费.简而言之，一个问题是:如何避免这种情况?

The doubts and the scenarios that I raise came up after I raised the problem that scenario 2 has. With each change in the code, having to rebuild the image and start the containers again is a significant waste of time. In short, a question would be: How to avoid this?

提前感谢您的时间.

注意:这可能是一个受制于意见的问题，但了解开发人员通常如何处理这些问题会很好.

推荐答案

免责声明:这是我对 Mars 先生提出的问题的看法.尽管我已尽力用实际来源来支持我的回答，但这主要是基于我自己的经验和一些常识

在使用 Docker 进行开发时，这些场景中最典型的是哪个?

Which of these scenarios is the most typical when using Docker for development?

我已经在几个项目中看到了所有 3 个场景，每个场景都有其优点和缺点.但是，我认为使用 Docker Compose 允许动态代码重新加载的场景 3 在灵活性和一致性方面是最有利的:

I have seen all 3 scenarios iin several projects, each of them with their advantages and drawbacks. However I think scenario 3 with a Docker Compose allowing for dynamic code reload is the most advantageous in term of flexibility and consistency:

• Dev 和 Prod Docker Compose 非常匹配，这意味着 Dev 环境尽可能接近 Prod 环境
• 开发时不必不断重建映像，但在需要时很容易做到
• 很多技术都支持这种场景，比如你提到的 Spring Dev Tools，还有 Python Flask 等.
• 您可以轻松利用 Docker Compose 扩展又名配置共享机制(也可以使用场景2)

• Dev and Prod Docker Compose are close matches, meaning Dev environment is as close as possible to Prod environment
• You do not have to rebuild the image constantly when developping, but it's easy to do when you need to
• Lots of technologies support such scenario, such as Spring Dev Tools as you mentionned, but also Python Flask, etc.
• You can easily leverage Docker Compose extends a.k.a configuration sharing mechanism (also possible with scenario 2)

场景 1 提出得好吗?即仅dockerize外部服务，如数据库、队列等，使用IDE进行应用的开发和调试，不使用Docker.

Is scenario 1 well raised? That is, dockerize only external services, such as databases, queues, etc. and perform the development and debugging of the application with the IDE without using Docker for it.

场景 1 很常见，但是 IDE 环境可能与 Docker 容器中的环境不同(并且很难为从 IDE 环境到 Docker 环境的每个库、依赖项等维护版本匹配).在进入生产环境之前，可能还需要在开发和生产之间经历一个中间步骤，以实际测试开发工作后构建的 Docker 映像.

Scenario 1 is quite common, but the IDE environment would probably be different than the one from the Docker container (and it would be difficult to maintain a match of version for each libs, dependencies, etc. from IDE environment to Docker environment). It would also probably require to go through an intermediate step between Dev and Production to actually test the Docker image built after Dev is working before going to Production.

根据我自己的经验，当您在实际进行开发时不想过多地处理 Docker 和/或您使用的语言或技术不适用于场景 3 中所述的动态重新加载时，这样做非常有用.但在最终它只会增加您的环境之间的偏差以及 Dev 和 Prod 部署方法之间的更多复杂性.

In my own experience doing this is great when you do not want to deal too much with Docker when actually doing dev and/or the language or technology you use is not adapted for dynamic reload as described in scenario 3. But in the end it only adds a drift between your environments and more complexity between Dev and Prod deployment method.

不得不重新构建镜像并再次启动容器是一种严重的时间浪费.简而言之，一个问题是:如何避免这种情况?

having to rebuild the image and start the containers again is a significant waste of time. In short, a question would be: How to avoid this?

除了您描述的场景之外，您还可以通过利用 Docker 构建缓存并设计您的 Dockerfile.例如，Python 应用程序通常会将代码复制为构建的最后(或几乎最后)步骤以避免使缓存无效，而对于 Java 应用程序，可以拆分代码以避免每次编译整个应用程序代码更改 - 这将取决于您的实际设置.

Beside the scenarios you describe, you have ways to decently (even drastically) reduce image build time by leveraging Docker build cache and designing your Dockerfile. For example, a Python application would typically copy code as the last (or almost last) step of the build to avoid invalidating the cache, and for Java app it would be possible to split code so as to avoid compiling the entire application everytime a bit of code changes - that would depend on your actual setup.

我个人使用的工作流程大致匹配场景3，例如:

I personally use a workflow roughly matching scenario 3 such as:

• 对应我的生产环境的docker-compose.yml文件
• a docker-compose.dev.yml 它将覆盖我的主要 Docker Compose 文件的某些方面，例如从我的机器安装代码，向命令添加开发特定标志等 - 它会是运行如

• a docker-compose.yml file corresponding to my Production environment
• a docker-compose.dev.yml which will override some aspect of my main Docker Compose file such as mouting code from my machine, adding dev specific flags to commands, etc. - it would be run such as

docker-compose -f docker-compose.yml -f docker-compose.dev.yml 

但也可以将 docker-compose.override.yml 设为 Docker Compose 默认使用覆盖

在某些情况下，我必须针对特定情况使用其他覆盖，例如我的 CI 上的 docker-compose.ci.yml，但通常主要的 Docker Compose 文件足以描述我的 Prod 环境(如果不是这种情况，docker-compose.prod.yml 可以解决问题)

but it would also be possible to have a docker-compose.override.yml as Docker Compose uses by default for override

in some situation I would have to use other overrides for specific situations such as docker-compose.ci.yml on my CI, but usually the main Docker Compose file is enough to describe my Prod environment (and if that's not the case, docker-compose.prod.yml does the trick)

这篇关于如何在 DevOps 生命周期的开发阶段使用 docker?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！