Django实现自动发布(4配置文件管理)

新部署一个服务时,除了服务本身,还有它启动依赖的配置文件也要一并发布到目标主机。配置文件从哪里来?如何发送到目标主机?修改后如何同步?

我们可以在页面提供上传或新增功能,为每个服务保存一份默认的配置文件包,新部署时将此包的内容写入etcd,由主机上的守护进程去同步,后续的修改也只是更新etcd里的内容,原理请见 配置文件那些事

实际上服务的配置文件不只有默认包,每次修改内容都会创建一个新的包,这个包里的所有版本号都应可应用到该服务的每个实例,因此需要记录服务有哪些配置文件版本号、实例当前关联的版本号,就是一对多的关系。我们要修改一下模型:

class ConfRevision(models.Model):
    # ...
    service = models.ForeignKey(MicroService, on_delete=models.DO_NOTHING) # 1个服务可以有多个配置文件版本号

class MicroServiceInstance(models.Model):
    # ...
    conf_revision = models.ForeignKey(ConfRevision, null=True, blank=True, on_delete=models.DO_NOTHING) # 1个配置文件可以对应多个实例

页面设计与实现

为了方便录入文件,希望能实现以下功能:

  • 除了手动填写,最好有个从文件上传的功能
  • 页面支持增加、修改、删除某个配置包的文件
  • 内容预览
  • 文件对比,查看修改历史

为了更方便的实现功能,引入vue 和 ui组件 elementui 我们就从DOM中脱离出来,只需要操作数据就好。

前端最后提交到后端的是1个或多个文件,由于配置文件是纯文本格式,所以很方便的用数组来保存内容,使用json传输到后端。

服务的配置文件列表:

支持以下操作:

  • 关联实例
  • 设置为默认配置
  • 修改内容
  • 修改描述

某个具体的配置文件:

  • 支持手动添加文件
  • 支持从文件导入
  • 格式校验

文件对比:

同步到etcd

目前的代码已经在本地数据库实现了一个完整的配置版本管理功能:

  • 浏览器作为统一的修改入口
  • 后端保存文件的修改历史,每一次修改都生成一个新的修订号
  • 简单文件对比,方便查看修改了哪些内容

之后的内容下发就是将内容写入etcd,相对来说比较容易。

相关的页面和代码比以往要多,放到 这里

原文地址:https://www.cnblogs.com/wbjxxzx/p/12112441.html

时间: 2024-10-31 19:55:51

Django实现自动发布(4配置文件管理)的相关文章

Django实现自动发布(2视图-任务接收)

上一篇服务版本的新增,是通过触发 gitlab 任务来实现的,那么如何得到任务的最终状态呢? 好在 gitlab 为我们提供了webhook,也就是消息钩子,可以发送pipeline消息到我们指定的地址. 当我们收到消息后,就可以跟据任务的最终状态(成功or失败)来更新数据库里相应的版本: 失败时直接更新任务状态为失败 成功时除了更新状态,还要记录版本的路径 版本的存储路径 gitlab 的pipeline任务有一个递增的ID号,我们可以直接拿过来使用,以此ID为版本目录,打包好的服务就存放在该

Django实现自动发布(3发布-升级和回退)

发布实际上就是将服务的某个版本和一台主机关联,我用一张表(MicroServiceInstance)记录了主机id.服务id.版本id,目前一台主机只能部署一个版本,所以主机id和服务id要做联合索引. 当我们操作某个实例时(升级.回退),为了防止其他人也进行相关操作,要对实例当前的状态就行判断,这里用 locked 标记. 升级.回退操作类似,都是更新MicroServiceInstance表记录的版本id,可以放在一个视图里实现. 升级回退页面 点击页面的版本管理,则弹出对应服务的版本列表页

Django实现自动发布(2视图-服务版本查找和新增)

前面做好了服务的管理,接下来是服务版本的管理,和服务类似,版本也有增删改查.先在服务的管理页面做一个入口,如下图: 需要在上一步的服务管理页面增加按钮.按钮方法,点击按钮跳转时要打开一个新的页面,所以还要增加对应的页面视图. 页面方法 templates/microservice/service.html 的标签<script type="text/html" id="barDemo">后面 增加内容 <a class="layui-bt

disconf实践(三)基于XML的分布式配置文件管理,自动reload

上一篇介绍了基于xml的非自动reload的分布式配置文件管理,这一篇介绍自动reload的方式(基于disconf实践二). 1. 修改RedisConfig.java 1 package org.springinaction.weather.config; 2 3 public class RedisConfig { 4 5 private String host; 6 7 private String port; 8 9 public String getHost() { 10 retur

disconf实践(四)基于注解的分布式配置文件管理,自动reload

上一篇讲解了基于xml的自动reload的分布式配置文件管理,这一篇讲解基于注解的自动reload的方式(基于disconf实践二). 1. 修改spring配置文件 1 <?xml version="1.0" encoding="UTF-8"?> 2 <beans xmlns="http://www.springframework.org/schema/beans" 3 xmlns:xsi="http://www.w

Openstack配置文件管理的变迁之路

在管理一个Openstack集群时,如何维护配置文件无疑是其中最艰难和繁琐的任务之一.因为你不仅要面对众多的核心服务(nova,keystone,glance,cinder,etc)的配置文件,还需要管理其相关服务的配置文件(mysql,rabbitmq,bind9,etc).并且在Openstack组件式的设计架构,以及将功能抽象为plugin或是pipeline中的一个filter的灵活配置下,使用者可以根据自己的需求来选择适合自己的架构,或者进行调整. 随手举一些例子: 选择使用nova-

Windows下的用户配置文件管理(二)

续Windows下的用户配置文件管理(一) 三.强制用户配置文件 强制用户配置文件也于漫游用户配置文件,不过它是只读的,用户不可以修改. 一般来说,此设置文件的内容由系统管理员事先设置好. 创建过程: 在实际生产环境,系统管理一般会建立一个临时用户登录后,按实际需要修改其工作环境,注销这个用户后,以这个用户的配置文件为模板,复制到所需要设置强制用户配置文件的用户使用. 为了简化操作操作,下面直接用管理的配置文件来复制. 在Windows 2008以前操作系统中,下图的"复制到"按钮是可

【C#进阶系列】03 配置文件管理与程序集的引用版本重定向

先来点与标题不相关的: CLR支持两种程序集:弱命名程序集和强命名程序集. 两者的区别在于强命名程序集使用发布者的公钥和私钥进行签名.由于程序集被唯一性地标识,所以当应用程序绑定到强命名程序集时,CLR可以应用一些已知安全的策略. 程序集可以采用两种方式部署:私有或者全局.弱命名程序集只能以私有方式部署. 在<CLR via C#>的第三章主要讲了私有部署和全局部署的具体内容,以及弱命名程序集和强命名程序集. 但是老实说一般情况下确实用不到这些东西,所以这里就不写了. 还有一个就是对CLR如何

发布/订阅配置

发布/订阅配置 的部分入口声明消息= "消息"意味着组装"消息.dll包含消息模式".特定类型可以配置使用限定名称: namespace.type, assembly. 声明部分端点= " messagebus "告诉订阅者的总线对象,出版商接受订阅请求队列.队列名称"messagebus"简称"队列命名messagebus在本地机器上".来表示一个队列在远程机器上,使用类似于电子邮件的格式:[email