我有几个与 Docker 在开发阶段的使用相关的问题。
我将提出三种不同的场景来说明如何在开发环境中使用 Docker。假设我们正在 Java 和 Spring Boot 中创建一个 REST API。为此,我需要一个 MySQL 数据库。
第一个场景是拥有一个用于使用 MySQL 容器进行开发的 docker-compose,以及一个使用 MySQL 和另一个容器中的 Java 应用程序 (jar) 进行生产的 docker-compose。为了进行开发,我启动了 docker-compose-dev.yml 以仅启动数据库。使用 IDE(例如 IntelliJ Idea)启动和调试应用程序。对代码所做的任何更改,IDE 将识别并通过应用更改来重新启动应用程序。
第二种场景是,对于开发和生产环境,都拥有一个包含数据库和应用程序容器的 docker-compose。这样,每次我对代码进行更改时,我都必须重建映像,以便将更改加载到映像中并再次启动容器。这种场景可能是最典型的,用于使用 Docker 进行开发,但由于每次有变化都需要重建镜像,所以看起来很慢。
第三种情况是前两种情况的混合。两个 docker-compose。开发 docker-compose 包含两个容器,但具有允许实时重新加载应用程序、映射卷和使用 Spring Dev Tools 等机制。通过这种方式,容器被启动,如果文件发生任何更改,应用程序容器将检测到存在更改并将重新启动。对于生产,只需使用两个容器创建一个 docker-compose,但没有实时重新加载的功能。在我看来,这将是理想的场景,但我认为这非常依赖于所使用的技术,因为并非所有技术都允许实时重新加载。
问题如下。
我提出的疑问和场景是在我提出场景2的问题之后出现的。每次更改代码时,都必须重新构建映像并再次启动容器,这会极大地浪费时间。简而言之,一个问题是:如何避免这种情况?
在此先感谢您的时间。
NOTE: 这可能是一个需要征求意见的问题,但了解开发人员通常如何处理这些问题会很高兴。
免责声明:这是我对 Mars 先生提出的问题的个人看法。尽管我尽力用实际来源来支持我的答案,但这主要是基于我自己的经验和一些常识
使用 Docker 进行开发时,以下哪种场景最典型?
我在几个项目中见过这 3 个场景,每个场景都有各自的优点和缺点。不过,我认为使用 Docker Compose 允许动态代码重新加载的场景 3 在灵活性和一致性方面是最有利的:
- Dev 和 Prod Docker Compose 非常匹配,这意味着 Dev 环境尽可能接近 Prod 环境
- 开发时不必不断重建镜像,但在需要时很容易做到
- 很多技术都支持这种场景,比如你提到的 Spring Dev Tools,还有 Python Flask 等。
- 您可以轻松利用Docker Compose 扩展了又名配置共享机制(也可以用于场景 2)
场景 1 提出得好吗?即仅对外部服务(例如数据库、队列等)进行docker化,并使用IDE进行应用程序的开发和调试,而不使用Docker。
场景 1 很常见,但 IDE 环境可能与 Docker 容器中的环境不同(并且很难保持从 IDE 环境到 Docker 环境的每个库、依赖项等的版本匹配)。它还可能需要在开发和生产之间经历一个中间步骤,以在进入生产之前实际测试开发工作后构建的 Docker 映像。
根据我自己的经验,当您在实际进行开发时不想与 Docker 打交道时,并且/或您使用的语言或技术不适合场景 3 中描述的动态重新加载时,这样做非常好。但最终它只是增加了环境之间的偏差以及开发和生产部署方法之间的复杂性。
必须重建镜像并再次启动容器是对时间的极大浪费。简而言之,一个问题是:如何避免这种情况?
除了您描述的场景之外,您还可以通过利用Docker 构建缓存并设计 Dockerfile。例如,Python 应用程序通常会将代码复制为构建的最后(或几乎最后)步骤,以避免使缓存无效,而对于 Java 应用程序,可以拆分代码以避免每次都编译整个应用程序代码更改 - 这取决于您的实际设置。
我个人使用的工作流程大致匹配场景 3,例如:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)