【问题标题】:Docker setting upDocker 设置
【发布时间】:2015-05-19 06:06:03
【问题描述】:

这几天我读了很多关于 Docker 的文章,我什至尝试用 Vagrant 在我的笔记本电脑上运行它。但我仍然不清楚为什么,尤其是如何将它介绍给我的团队。只是我没有看到用例。

我了解您可以为 Web 服务器和数据库创建容器。所以你们可以说,你们好,现在我们正在使用我创建的 custom-tomcat-1.0 和 custom-mysql-1.4 容器。 到目前为止很清楚。我遇到的问题是那些“数据容器”。

我仍然可以以某种方式理解我将拥有 DB-data-1.4,其中包含更新到当前模式的 DB 容器的数据文件,我可以将 WEB-app-3.5 与我的可部署文件一起使用,这将以某种方式与 DB-相对应数据图像。

Java 呢?如果我有 java DB,我需要在所有使用它的容器上安装 JVM?

到目前为止,这有意义吗?现在有几件事我看不清楚它们的位置。

  1. 本地开发人员将如何使用它?他会创建一些WEB-app图像快照并启动它吗?或者会以某种方式跳过使用 WEB 应用程序映像并以某种方式将构建文件直接提供给服务器映像?

  2. 对于 jenkins,我想它会从 git 下载代码。构建它并创建一些 WEB 应用程序图像快照。开始一切。现在我可以运行一些集成测试,以某种方式从外部使用应用程序,但是如何?

基本上是两个问题:您如何使用 docker 进行本地开发,以及您如何执行集成测试。我需要真正的用例,所以我可以看到它的大图。我们正在使用 maven、java、spring、sql db、jenkins、junit。

【问题讨论】:

标签: java docker containers development-environment


【解决方案1】:

docker 迫使您认真思考应用程序的不可变和可变部分是什么。不可变部分构建为基础镜像,而可变部分构建为容器(并且可能作为镜像持久化)。 例如,您可能决定为特定的开发发布周期锁定操作系统版本和 Java 版本。这是不可变的部分,因此您可以基于此构建应用程序的基本映像。您的应用程序代码将添加到基础映像并作为容器运行。

稍后,当开发和测试完成并准备投入生产时,您可能需要针对最新的操作系统补丁和 Java 更新重新测试应用程序。此时,您可以从新版本的基础映像开始并重新运行测试。如果测试成功,这将成为您构建的新基准。

在类似的行中,如果您的数据库包含预定义的架构和/或预加载的数据(不可变),则可以将其设计为仅数据卷并以只读方式安装在容器上。在应用程序测试运行期间对数据库进行的任何更新都将保留为容器文件系统层的一部分。

【讨论】:

    【解决方案2】:

    上面有很多查询。据我了解,您正在尝试为开发人员创建一个环境,并且您正在尝试集成 jenkins 和 docker。

    这是我处理相同情况的方法

    1) 首先,我们创建一个镜像(比如 myimage),其中包含所有依赖项 db、java 等。这个镜像是我们的基础镜像,开发人员可以多次使用。

    2)开发人员可以创建自己的代码并将其合并到 git 中。

    3)创建一个 jenkins 作业,该作业创建一个快照文件(例如:.zip),其中包括所有依赖项,如 jar 和包。

    4) 使用 docker 中的 ssh 插件将此 zip 移动到目标服务器。

    5)然后 Jenkins 应该触发 Dockerfile 将文件 (.zip) 移动到 myimage 容器中,并使您的 Web 应用程序启动并运行。

    6) 将您的各种测试包含在 docker 内的一个目录中,并让 Dockerfile 为您触发它们。

    7)确保在 Jenkins 中触发新构建时,之前的 Docker 容器已停止。

    您可以使用 docker -v 中的挂载点来移入和移出文件。

    希望这个答案可以帮助您解决您正在寻找的任何问题。 这对我有用。让我们知道它是否也对你有用。 万事如意

    【讨论】:

    • 您所说的是创建包含所有必要内容的容器。如果我们正在处理多种类型的项目怎么办,这将强制创建多个“基础图像”。您的方法如何与版本控制配合使用。我想在您将可部署文件上传到“myimage”后,您将提交图像以供测试人员拉取和测试,对吗?然后它是如何转移到生产中的?您将在生产服务器 VM 上安装特定版本的整个“myimage”?
    • 是的,它基本上是为不同种类的项目创建多个基础镜像。如果我们使用的是类似类型的项目,那么我们可以多次使用相同的基础图像。
    • 话虽如此,你总是可以选择 Dockerfile 而不是基础镜像。(这是一个替代方案)
    • 如果您在 docker 注册表中提交图像,则可以维护版本控制。您可以使用java.dzone.com/articles/create-your-own-private-docker 创建自己的注册表。您可以在注册表中为每个构建提交图像。
    • 这里供测试人员使用。我们在单独的容器中创建第二个具有相同 docker 映像的 jenkins 项目。
    【解决方案3】:

    速成课程

    从概念上讲,您可以将 docker 容器视为一个新创建的虚拟机,其中包含操作系统的基本要素。

    docker 镜像就像一个虚拟机模板。容器是图像的实时实例。我们指定如何使用Dockerfile 构建图像,很像vagrantfile。它包含我们需要运行我们希望在容器中运行的任何应用程序的库、程序和配置。

    考虑这个来自nginx的简化示例:

    # Choose base image (in this case ubuntu OS)
    FROM dockerfile/ubuntu
    
    # Install nginx
    RUN apt-get update && apt-get install nginx
    
    # Define default command to run when the container starts.
    # i.e the nginx webserver
    CMD ["nginx"]
    
    # Expose ports. Allowing our webserver to be accessible outside the container.
    EXPOSE 80
    EXPOSE 443
    

    dockerfile 非常简单 - 快速安装和一些小配置。真正的 nginx dockerfile 有更多的优化,以及设置权限、环境变量等配置步骤。

    为什么图像有用?

    图像/容器的用处在于它们可以在任何运行 docker 守护进程的机器上共享和部署。这对于开发工作流程非常有用。我们可以将容器保存为映像并传递它,而不是尝试复制生产、登台、开发环境来重现错误等。

    JVM 的东西

    Docker 镜像就像构建块,共享相同的部分,并且只添加新的位(这意味着我们使用更少的磁盘空间!)。如果您有多个需要 JVM 的应用程序,您将使用 java 基础映像。这确实意味着 JVM 的多个实例正在运行,但这是您在选择 docker 时会做出的权衡/设计问题。

    数据容器

    这些有点令人困惑,它们基本上允许您的数据像您的应用程序容器一样变得可移植。 它们不是必需的,只是另一个设计决策。您仍然可以将数据库数据导出到 CSV 以及从应用程序容器中移动它的所有常用方法。我个人不会在我的工作流程中使用数据容器,因为我正在处理 TB 的数据,并且数据可移植性并不是一个大问题。我改用volumes,您可以告诉 docker 使用主机文件系统目录来存储其数据。这样,无论 docker 容器或映像的生命周期如何,数据都会永久存储在主机上。

    构建

    我们将首先讨论这一点,然后开发人员的工作流程才会更有意义。 实际上有两种主要方法可以解决这个问题:

    如果您的目标是持续集成,我发现卷是您的必经之路。您的 docker 容器将使用卷将其应用程序源代码挂载到主机文件系统上。这样,您所要做的就是拉取源代码,重新启动容器(以确保获取对源代码的更改),然后运行您的测试。构建过程实际上与没有 docker 没有什么不同。我更喜欢这种方法,因为它速度快,其次是应用程序的依赖项、环境等通常不会改变,因此重建图像是多余的。挂载源代码还意味着您可以在紧急情况下进行适当的更改

    较慢的替代方法,就像您描述的那样,是在构建时将源代码“烘焙”到映像中。您将提取新的源代码、构建映像(可选 - 推送到私有 docker 注册表)、部署容器,然后运行测试。这具有完全可移植的优点,但是为每个小的代码更改重建和分发映像的周转时间可能很费力。

    工作流程

    Docker 的目的是指定应用程序运行的环境。从这个角度来看,开发人员应该继续照常处理应用程序代码。如果开发人员想在容器中测试代码,他们会在本地构建映像并从中部署容器。如果他们想在生产或临时映像中进行测试,您可以将其分发给他们。

    最后,关于使用容器的最简单的专业提示 :) 要登录到容器并探索正在发生的事情,您可以运行 docker exec -it container-name bash

    免责声明

    我知道我的解释有些过于简单化。我的目标是尽可能少地添加混淆和新术语。我发现这只会使远离 OP 似乎最关心的核心思想、用例等任务变得复杂。

    【讨论】:

      猜你喜欢
      • 2017-03-21
      • 1970-01-01
      • 2021-02-02
      • 1970-01-01
      • 1970-01-01
      • 2020-08-10
      • 1970-01-01
      • 2021-05-03
      相关资源
      最近更新 更多