• 喜剧。
    2018-02-10
    如果多套环境多套编译感觉在效率上有点低。针对java程序,我们能否统一打成jar包,然后利用启动参数来控制你是在使用什么样的配置文件呢?如果使用的是微服务架构,我们是否最好将配置文件剥离出来,使用配置中心来管理?

    作者回复: 有很多配置是启动时就会依赖的,特别是跟环境相关的这些,比如数据库连接不上可能就直接启动异常了,进程无法正常启动,那读取配置中心的配置也就无从谈起了。

    
     3
  • 赵丹
    2018-05-15
    我们公司用的svn进行代码管理,jenkins,ant工具实现的自动化构建部署,我们使用的工具部署方式需要调整吗,怎么调整会更好些,希望老师给点建议。
    
     1
  • 海格
    2018-04-04
    我们就是使用的配置中心,编译完打包车docker镜像,然后调用接口进行部署,启动容器,在启动容器的时候会传入几个参数,会先拉取配置文件,然后在运行jar包。
    
     1
  • Adam
    2019-03-26
    我是这样做的。pod里面initcontainer配置一个拉取config的程序(程序得开发写好封装成镜像),初始化容器运行完成后才会开始运行业务容器。initcontainer传入不同的环境变量以及应用名就可以拉取对应的配置。
    
    
  • 松花皮蛋me
    2019-02-17
    我们是只打包一次,然后发布时根据环境将配置文件更换,配置文件和启动脚本和库都是分文件夹存放的。另外docker镜像发布是趋势,不需要先申请机器,快速扩容
    
    
  • 快乐就好
    2018-08-18
    现在kubernetes 可以说已经足够完善了,对于应用的发布,我们发布是直接发布应用打包到容器的容器吗?是否有什么缺陷?
    
    
  • 森馫鑫
    2018-07-15
    可能有读者会问:为什么不直接生成 Docker 镜像,后续直接发布镜像?

    这里我能想到一个场景就是客户端的持续发布,这个是无法用镜像代替的。
    
    
  • 天使
    2018-05-24
    通过环境变量配置docker,应用读取环境变量获得应用配置;通过config server为应用提供代码配置;docker 的好处在于开发机器上可以迅速启动进行调试;依赖太多的话,启动docker的时候将依赖连到线上dev或qa环境
    
    
  • 江龙
    2018-03-01
    实现一套配置中心服务,每个环境独立的一套配置中心,服务起来时会相应的去对应的配置中心中动态请求配置。这样就能实现只一次构建,且代码与配置分离

    作者回复: 有些配置是启动时就依赖的,这种配置只能在构建时打入软件包

    
    
我们在线,来聊聊吧