修改app数据的软件es(修改app里面的数据)

　　在Docker实践过程中，这些场景下需要用到容器应用配置文件管理：

　　1.多环境之间交付应用配置参数不同时;

　　2.想增加应用参数时；

　　3.修改应用配置参数时不重新构建镜像时；

　　4.容器部署后想修好应用配置信息时；

　　5.容器数目多修改配置文件即可一键下发；

　　6.应用迁移至容器中成本低；

　　7.更加自动化

　　等等。

　　社区最近组织活动“实践Docker过程中应用配置文件管理技术讨论”，由社区专家张春源整理活动中分享的知识点，供大家了解参考。

　　张春源，擅长利用Docker构建整个DevOps自动化平台，专研Dockerfile及docker周边技术，对CoreOS有深入研究。是国内最早期的Docker实践者，就职于希云cSpher。

　　以下内容分享者：张春源、wanggeng、zhubingbing、bryan_sd、nexpose 等

　　一、Docker应用配置文件的作用都有哪些？

　　观点一：

　　我先来理一下问题的思路：

　　1.docker应用应该是指的在容器中运行的服务（tomcat）；

　　2.应用配置文件那就是指的在容器中运行服务的配置文件(tomcat的配置文件)；

　　问题理清楚后，那在用docker过程中管理应用配置文件的价值就比较大；

　　我列举几个：

　　1.容器镜像是只读的，构建完成之后如果发现配置文件的中想增加环境变量此时如果没有配置文件管理的功能就需要重新构建build镜像；有个配置文件以后，直接在配置文件中增加就行。

　　2.基于镜像部署容器后，后续运维过程中会对应用配置的参数做一些修整，那直接可以修改配置文件的内容即可；有的配置文件修改后是要重新启动服务的，但至少不需要再重新构建打包镜像了；有些配置文件修改后是不用重启服务的修改后应用即可很方便。

　　3.如果一个对Docker容器不懂或者是重心关注在应用层的人来说，我觉得有配置文件的话使用容器就更容易一些。此时我们就可以把镜像看成是一个程序包，基于容器的模式进行封装后，剩下的工作就是修改应用的配置文件，调整容器配额，日志文件、数据文件存储路径等事宜。能将重心从系统底层上升到应用层。

　　4.实践发现在应用迁移过程中调试成本会降低。

　　5.线上运维运营方便。

　　观点二：

　　观点一回答的很好，Docker应用配置文件的作用就是给docker的服务提供配置，我就在他的基础之上，说说我的看法：

　　应用配置文件应该需要做到以下几点：

　　1.docker应用配置文件能够保持能够支持针对不同环境作出更改。

　　2.配置文件支持在线更改，重启就生效。

　　二、基于镜像部署容器后，应用配置文件如何做变更？

　　观点一：

　　容器部署后配置文件变更是一个强需求；

　　简单说一下我的分析：

　　1.使用docker自身带的环境变量方式

　　docker自身带的环境变量的方式如已部署完成后，再修改基本上就是重新创建容器了。我个人觉得比较生硬，对应用层不够友好。

　　2.程序自动去获取

　　这种模式有点类似springcloud微服务的实践方式，配置文件都存放到config server中，程序配置文件有更新后config server会将更新后的配置文件下发到容器中。如果没有config server实现起来比较困难一些。

　　3.容器管理平台自动下发

　　容器管理平台自动下发这种模式我觉得会比较通用，目前我接触的企业客户中，客户有很多业务系统不是基于微服务架构开发的但也想用容器来部署和管理。做个广告希云cSphere平台的配置文件管理我觉得做的挺不错的，哪位同事的公司有需求可以多沟通。

　　观点二：

　　两种实现方式

　　1. 对于需要变更的参数在启动容器时通过-e传入，相当于export 定义变量，然后在容器中读取这个变量；

　　2. 专门制作一个config server,Spring Cloud Config可以满足你的需求

　　观点三：

　　上面的各位解答的已经很全面了，我说一下我们的特殊做法，因为我们的场景比较特殊，要动态修改系统，web，中间件，消息服务等多种情况，我们采用了在build的镜像的时候在里面注入了agent通过它来修改容器中的各种配置文件和启动停止各种服务。

　　三、应用配置文件和docker环境变量的区别是什么？

　　观点一：

　　1.docker环境变量是在制作镜像的时候就需要提前想好，有哪些参数是部署容器的时候会经常更改，然后把这些参数抽出来做成容器的环境变量，然后在部署的容器的时候填入不同的参数即可。

　　（如果后续发现有一些参数不同场景下部署的时候也会修改，那就需要再重新制作镜像了。）

　　2.应用配置文件可以有多种管理方法，上述的管理方式不太灵活。灵活的管理方式是将配置文件和镜像剥离开，这样就不会被镜像给绑定了。

　　观点二：

　　应用配置文件如果配好后写到镜像，那么以后启动的每个实例都会有相同值，但是如果使用环境变量，则启动容器时直接通过-e输入，就无需在改变应用参数配置时重新制作镜像。

　　四、如何修改运行中容器的配置？

　　我开启一个docker容器：

　　容器中配置项目IP是：10.241.93.21。现在由于网络环境的问题，ip地址变化了。需要将容易的IP换成10.241.61.20。

　　ps：要求不删除现有的容器，下次重启后ip地址还是10.241.61.20。怎么配置？求方法？

　　观点一：

　　你的使用方式错了。容器不应该是长久性的东西，要保持容器的可抛弃性，有问题就应该rm掉，数据保存在容器外，然后直接run新的容器。参数修改是那个时候进行的。

　　另外，你应该使用DNS，如果是内部的机器，则使用内部DNS也可以，而不应该写死IP。

　　这两个做法都有问题。至于说修改容器内的配置，这是不推荐的做法，容器不是虚拟机，不应该修改其内的配置。

　　观点二：

　　docker就是一个容器引擎，类似kvm是虚拟机引擎。docker官方最厉害的地方是提出了镜像打包的概念，但想把容器用好还有很多问题要求解决，容器网络就是其中的一块。

　　一个企业想把容器用起来或者说是能基于容器来支持业务系统网络方面一般都要达到几个要求：

　　1.容器网络性能（我接触过的公司对网络要求都比较严格的）

　　2.容器固定ip地址（这个已经有很多种实现方式了）

　　3.容器跨主机之间通信（有很多中网络模式）

　　4.不同容器之间通信，这个场景中使用容器和vm是不一样的地方。容器对底层资源环境是解耦的，所以不要把容器的ip给固定死，不同环境的网络也不同，所以应用层要通过dns来解决。

　　五、修改无法启动的容器中的内容（如配置文件信息），应该如何处理？

　　方案一：创建新镜像

　　把这个问题容器用docker commit提交到一个新的镜像，然后用docker run -it 基于新镜像运行一个新的容器进去改变（修复）配置文件。

　　再通过新的容器再提交一个新的镜像，然后在基于新的镜像重新启动容器（同最初的容器）。

　　这个方法是可行的，但问题是步骤多，而且提交了新的镜像，对于后续维护增加了复杂性。

　　方案二：

　　直接修改容器的文件

　　所有的容器数据都存在/var/lib/docker/aufs/diff/路径下。比如：

　　root@ubuntu:~# ls /var/lib/docker/aufs/diff/ -l

　　total 176

　　drwxr-xr-x 2 root root 4096 Mar 6 05:13 040bf8e0842564e26e62f3e3a30785bd9651c82c52ed99115cd5360ce979e680

　　drwxr-xr-x 6 root root 4096 Mar 6 05:13 04f7e78a2c8ac9664503f4ea5a1d94bf27b94620987f241cfb9fd6631f761113

　　drwxr-xr-x 2 root root 4096 Mar 11 01:07 0c666375883f81ba0fc3962368766e93710f59c072a4b80cdf5640323018ccdb

　　drwxr-xr-x 4 root root 4096 Mar 11 07:53 0d7fc1722e459b242140ec45faec754d4967d72ea2ddf321f8606c837f8e8d4f

　　drwxr-xr-x 6 root root 4096 Mar 11 07:53 0d7fc1722e459b242140ec45faec754d4967d72ea2ddf321f8606c837f8e8d4f-init

　　drwxr-xr-x 3 root root 4096 Mar 6 05:13 0dc5e226a795507723362cc16046cf16650f8f70dc7bb721b799a5f2a40512ce

　　drwxr-xr-x 2 root root 4096 Mar 6 05:13 0fd3b6e125673affc1f348cdb0c071782bde7d7ab4748bea3e30bc2d1d7ea7ab

　　......................

　　一个容器的数据对应这其中的一个或多个目录 。其中目录名的前几位就是容器的ID，通过这知道容器和目录的对应关系。

　　注意这个目录需要用root用户执行。

　　具体的操作步骤如下：

　　1、设置当前目录 cd /var/lib/docker/aufs/diff

　　2、查找要修改的配置文件所在容器中的位置

　　find ./ -name 'nginx.conf'

　　假设我们要修改的是 nginx.conf文件，可能的结果如：

　　./eb531927ba243b59f0db78848809423f7debe148a9ef972088ea41be73c2aa81/etc/nginx/nginx.conf

　　./4975acfb30f3f729ac08a9c1bd642f735298a47057fc7c414c7479696b80f36a/etc/nginx/nginx.conf

　　./6fce3cb01e3c9b8cc4e1fc270c012b1d0b666fe49ad8b6bededb99e295c5da4c/etc/nginx/nginx.conf

　　这时我们通过比较要修改容器的ID 与上面几个目录的前缀，就知道是要修改哪个配置文件了。

　　如果我们进入类似4975acfb30f3f729ac08a9c1bd642f735298a47057fc7c414c7479696b80f36a 目录，会发现这个目录下的内容和linux跟目录下的目录结构非常类似。我们可以找到相关的配置文件直接修改。

　　说明：因为一个容器的文件系统包括不可修改的镜像层和可修改的读写层，这个目录下其实就是读写层的内容。

　　3、修改完毕后用 docker start 容器名/ID 即可重新启动容器。

　　六、基础镜像的继承管理和如何处理多个技术栈的应用版本？

　　有两个问题，基础镜像的继承管理和如何处理多个技术栈的应用版本。举个例子，我们对于CentOS 7，做了公司级别的基础OS镜像A，基于这个镜像加入了JDK成为镜像B，基于B加入了JBOSS成为C，在C的基础上再构建项目的APP镜像D。

　　问题来了：1，有没有办法针对A镜像修改了，B，C和D去级连更新。2，由于是继承关系，各层软件的版本不同，导致镜像种类就特别多，例如JDK有3种，jboss有三种，那么镜像C就有九种，技术栈深了，命名又成为了问题。

　　求指导解决思路？

　　观点一：

　　由于镜像是分层管理，层级越深，IO性能会降低，因此最好的办法就是各种环境分别制作不同image，如果有一些类似需求的，比如所有环境都使用java7，那么在base先构建java7，再在此基础上建构更上层的技术，一个原则：越通用的东西越先构建

　　1.尽量将Dockerfile放在空目录中，如果目录中必须有其他文件，则使用.dockerignore文件。

　　2.避免安装不必须的包

　　3.每个容器尽量只关注一个功能点。

　　4.尽量减少最小化镜像层数

　　观点二：

　　你的提的这个问题非常好，这个问题是每个企业中大量使用容器的时候都会遇到的。

　　第一个问题：针对A镜像修改了，B，C和D去级连更新。

　　提到容器大家都在提持续集成持续部署CI/CD,每个镜像都是由Dockerfile来定义，最终执行docker build命令来镜像构建。推荐选择1-2台服务器专门用来做应用镜像的构建，避免在运行业务容器的服务器上构建镜像影响业务。

　　系统架构：gitlab存放dockerfile--jenkins job1（A镜像）---jenkins job2（等A构建完成后构建B）--- jenkins job3（等B构建完成后构建C）依次类推......

　　第二个问题：由于是继承关系，各层软件的版本不同，导致镜像种类就特别多，例如JDK有3种，jboss有三种，那么镜像C就有九种，技术栈深了，命名又成为了问题。

　　镜像树是这样：baseos--jdk--jbosstomcatweblogic---applications，因为dockerfile在gitlab中进行管理，所以不妨你在增加一个文件IMAGE_VERSION=xx，docker build时可以取这个文件中的值，版本号你可以取jboss的版本号（在dockerfile中增加一个EVN jboss-version=xxx就行）。这样即使后面有再多的镜像命名都很好管理了，提前规划好是非常有必要的。