过去，应用程序部署意味着将开发人员提供的大量组件移动到由运营管理的大量服务器、数据库等。对于 docker 和容器，我们经常听到这样的说法：“现在一切都消失了——开发人员只需提供一个随时可用的 docker 镜像，我们就完成了！不再需要像 xl deploy 这样的应用程序部署工具！”
在与许多转向基于容器的部署的用户合作后，事实证明这种说法根本不正确：虽然 docker 和容器肯定可以使打包和部署的某些方面变得更容易，但 xl deploy 等工具可以帮助解决许多挑战。
就是这样：
传统应用程序的打包取决于它是如何编写的：操作系统（linux、windows）、语言（java、c#、ruby python、js..）、它的行为（前端、后端、web、处理）、使用与否数据库（sql、nosql）……相关环境及其基础设施也是如此：主机（虚拟、云）、操作系统（linux、windows）、中间件（tomcat、apache httpd、iis、ibm websphere、.. )、数据（mysql、mongodb）。
在 xl deploy 中，我们将进行以下经典部署，其中
- petportal 版本 2.0-89 包含：petclinic (jee.war)、petclinic-backedn (jee.war)、petdatasource (jee.datasource)、sql (sql.sqlfolder)、logger（配置 log4j.properties 的自定义类型）
- tomcat-dev环境包含：tomcat-dev（tomcat.server）、tomcat.vh（tomcat.virtualhost）、sql-dev（sql.mysqlclient）、smoke-test（smoketest.runner）。
传统部署应用
docker 的承诺如下：“包中的一种项目 (docker.image) 将部署在一种目标 (docker.machine) 上，成为一个正在运行的 docker 容器。”
如果我使用 docker 打包和部署我的 petportal 应用程序，会有哪些修改？
- 在包中，我没有 2 个 jee.war 文件（petclinic、petclinic-backend），而是有 2 个基于来自 docker hub 的 tomcat:8.0 的 docker.image，它 包含 war 文件及其配置，但我会保留我的“冒烟测试”和我的“sql”文件夹。此外，我需要将属性文件从外部打包到我的图像中（图像就像一个提交，不要修改它！）
- 在环境中，我将仅用单个“docker-machine”替换“tomcat.server”和“tomcat.virtualhost”，我会保留我的“sql-dev”mysql sql 客户端，test-runner-1（smoketest .runner）。
最后，几乎没有什么变化，但是 xl deploy 生成的部署任务与使用“docker”命令有点不同：
- 不再有“war copy”步骤，而是“docker pull”步骤
- 不再有“启动 tomcat 进程”步骤，而是“docker 运行”步骤
使用 xl 部署的 dockerized 应用程序
如果我们详细了解 xl deploy 及其 xld-docker-plugin 生成的 docker run 2 命令：
-
对于“petclinic-backend”容器，命令很简单，我们可以在任何 docker 博客文章或文档中阅读：
docker run -d --name petclinic-backend petportal/petclinic-backend:1.1-20150909055821 -
对于“petclinic”容器，该命令有点复杂，因为我们需要对其进行配置——根据文档，“docker run”命令最多可以接受
56 个参数
，其中许多参数可以添加多次。在我们的
简单
案例中：我们需要
- 将它与 petclinic-backend 链接起来，
- 管理暴露的端口，
- 挂载卷以应用配置，
- 设置环境变量：
-
所以生成
docker run -d -p 8888:8080 --link=petclinic-backend:petclinic-backend -v /home/docker/volumes/petportal:/application/properties -e "loglevel=debug" --name petclinic petportal/petclinic:3.1-20150909055821
由于“petclinic”容器需要链接到“petclinic-backend”， xld-docker-plugin 会按照正确的顺序生成步骤，首先运行链接的容器，然后运行另一个容器。
与其他中间件一样，主要的痛点不是调用远程命令，而是以正确的顺序使用正确的配置生成正确的命令。
两个电源方向立即到来：
- 容器配置及其 50 多个参数，包括网络、操作系统、安全设置：tcp 端口映射、与其他容器的链接、内存、权限……cf docker run 文档
- 卷管理，例如：容器配置通常是通过提供一组文件来完成的，这些文件需要先上传到docker-machine，然后将卷挂载到容器中；当您运行管理数据的容器（例如：sql 数据库）时，情况相同
在以下场景中，配置由包含 .properties 文件中的占位符的“config”docker.folder 管理。修改值时，应上传文件夹并重新启动容器。
使用 xl deploy 进行依赖管理
因此，管理给定环境的配置可能很困难，但应用程序仍需要部署在多个环境中。 xl deploy 的字典可以帮助你。此外，转向 docker 意味着大部分时间转向微服务架构，这意味着更多的部署。请参阅 xl 部署 docker 微服务示例应用程序 。
本文最初出现在 benoit moussaud 的 xebia 实验室博客 上。