配置管理

博文结构 配置和连接数据库 控住文件的管理 日志文件的管理 归档日志的管理 数据字典 一.配置数据库 在实际生产环境中, Oracle 一般都是通过远程方式进行管理及维护, Oracle 远程操作除了对客户端工具的使用外，它的通信原理也是需要掌握的。 Oracle客户端与服务器端 无论是使用SQL*Plus工具还是使用第三方工具连接远程数据库,都必须建立客户端与服务器端 之间的连接。Oracle 提供了Oracle Net Services 组件，用于方便地配置和管理网络连接。这些组件不 需要单独安装，在安装Oracle服务器或客户端软件时会自动安装。 开启监听 [oracle@Oracle ~] $ lsnrctl start 1.Oracle Net协议 如图所示，Oracle 通过Oracle Net协议实现客户端与服务器端的连接及数据传递。Oracle Net 是同时驻留在Oracle服务器端和客户端上的一一个软件层，它封装了TCP/IP 协议，负责建立和维护客 户端应用程序到数据库服务器的连接。 2.客户端与服务器端的连接过程 在分析客户端与服务器端的连接机制之前，先要了解两个概念:一个是Oracle Net监听器，另一个是Oracle网络服务名。 案例：客户机远程连接oracle [root@oracle ~]# systemctl stop firewalld

一、进入DNS管理器： 打开DNS管理器，如图所示： 正向解析：通过域名找到IP的过程。 反向解析：通过IP找到域名的过程。 推荐个网址：http://dns.aizhan.com/，这个网站就是反向解析，通过IP找域名。 DNS资源记录： 1）SOA 资源记录(全区唯一) 每个区在区的开始处都包含了一个起始授权记录（Start of Authority Record），简称SOA 记录。 SOA 定义了域的全局参数，进行整个域的管理设置.一个区域文件只允许存在唯一的SOA 记录。 2）NS 资源记录 NS（Name Server）记录是域名服务器记录，用来指定该域名由哪个DNS服务器来进行解析，每个区在区根处至少包含一个NS 记录。 3）A 资源记录 地址（A）资源记录把FQDN 映射到IP 地址.。因为有此记录，所以DNS服务器能解析FQDN域名对应的IP 地址。 4）PTR 资源记录 相对于A 资源记录，指针（PTR）记录把IP地址映射到FQDN.。用于反向查询,通过IP地址，找到域名。 5）CNAME 资源记录 别名记录（CNAME）资源记录创建特定FQDN 的别名。用户可以使用CNAME记录来隐藏用户网络的实现细节，使连接的客户机无法知道真正的域名。 6）MX 资源记录 邮件交换（MX）资源记录,为DNS 域名指定邮件交换服务器。 邮件交换服务器是为DNS

如果原来的代码和文档已经用Windows下的Svn管起来了，在安装了oKit后，你可以将原Svn的数据全部迁移到oKit。 迁移后会代理以下好处： （1）您不用再为Svn用户和授权犯愁了。迁移到oKit后，原来的使用方式不变，用户名和密码使用oKit的用户名和密码，授权也能在图形界面上方便实现； （2）查看和使用配置库更加方便。即使用户没有安装TortoiseSVN或Eclipse插件，也能在任何位置通过网页访问配置库，提交文件，查询文件，调整配置库目录结构等等； （3）可以实现开发库、受控库和产品库三库分离。分离后更方便管理和控制，并提供丰富的报表功能； 迁移方法： 注：oKit2.7版及之前版本兼容Subversion1.5.3版本库，如果原来的库是更新版本的，需要进行相应处理。具体处理方法可以到群 198062542 中讨论。 （1）在oKit项目的相应库中创建配置项； （2）选中新建配置项，右键菜单，如下图： （3）找到oKit的安装目录，进入\oKit\svn\data\，找到上步中的地址，删除 （4）将原Svn库目录拷贝到这个目录下，并重命为之前记下的目录名称。 来源： oschina 链接： https://my.oschina.net/u/226430/blog/110813

需求是研发类项目的重中之重，管好需求就意味着项目成功了一半，oKit V2.7提供了灵活强大的需求管理功能可以为您的项目管理提供鼎力支持。 您可以 用oKit V2.7版 规划产品线，而且需求、缺陷、测试用例都可以跟踪到产品信息！ 出现问题！切屏 —> 新建缺陷 —> Ctrl-V—>指派处置人 —> 提交。oKit V2.7版的缺陷处理就是这么简单！ 统御项目管理系统2.7版于2013年2月6日正式发布，简称oKit 2.7。 oKit 2.7在oKit 2.5基础上做了以下主要工作： （1）全面改进需求管理功能。支持需求变更管理、自动影响标记、通知管理、细化权限控制、增加标题、提供统一的条目展示、与产品/版本/模块关联、细化与任务关联、文档支持目录、支持多对多跟踪矩阵、优化列表视图。 （2）将原“系统构成”改为“产品规划”。支持一个项目管理多个产品，每个产品可以进行版本规划，每个版本可以维护模块构成。 （3）改进缺陷管理功能。增加缺陷模板功能，增加了缺陷的出现频率、产品、版本、模块、计划解决版本、对应需求等属性，优化了页面布局和工作流设置，新建缺陷即可直接指派或处置缺陷。 （4）改进了测试管理功能。增加了测试用例与需求条目和产品信息的关联，支持测试用例覆盖分析，测试活动中能够查看之前的测试结果。 （5）支持图片直接粘贴。支持直接将Visio、单个Word、图片文件

1 场景描述 参考 http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html ，实现自己的集中配置管理系统。 术语：配置管理（ Configuration Management ） 一个带配置的服务程序，部署在若干台机器上，如果配置发生了变化，接下去要进行的操作是停止所有机器上的该程序，修改每一台机器上该程序对应的配置文件。 这个情景会有两个问题：第一，机器多了，逐个修改配置是一件不合理的运维；第二，配置一般是程序启动时读入的，所以配置修改后，程序应该重启。 配置管理在某些场合称“数据发布与订阅”，顾名思义就是将数据发布到 zk 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。 实际应用环境： 1. 索引信息和集群中机器节点状态存放在 zk 的一些指定节点，供各个客户端订阅使用。 2. 系统日志（经过处理后的）存储，这些日志通常 2-3 天后被清除。 3. 应用中用到的一些配置信息集中管理，在应用启动的时候主动来获取一次，并且在节点上注册一个 Watcher ，以后每次配置有更新，实时通知到应用，获取最新配置信息。 4. 业务逻辑中需要用到的一些全局变量，比如一些消息中间件的消息队列通常有个 offset ，这个 offset

在本文中，我们讨论如何快速地从更高的层面理解DevOps，介绍准备改变文化的最佳实践。我们将讨论DevOps的目标以及从组织管理层得到支持的方法，为DevOps的概念打下基础。我们将试着从根本上介绍使应用程序生命期管理简单、高效的DevOps实践。 DevOps不是一种框架、工具或者技术，理解这一点非常重要。它更多的是与组织的文化有关。DevOps还是人们在组织中使用预先定义的过程、利用自动化工具，使日常工作更加高效、手工工作更少的一种方法。 为了理解DevOps的重要性，我们在本文中将包含如下主题： DevOps的必要性； 如何发展DevOps文化； PPT（人、过程和技术）的重要性； 为什么DevOps不全和工具有关； DevOps评估问题。 1.1　DevOps的必要性 每个伟大的梦想都源于梦想家。永远铭记，你拥有的力量、耐心和热情，可以令你摘星揽月、改变世界。 改变是生命的法则，也适用于组织机构。如果任何组织或者个人只盯着过去或者现有的模式、文化或实践，他们就肯定会错失未来的最佳实践。在动态的IT世界中，我们必须赶上技术革新的步伐。 我们可以参考乔治•萧伯纳的名言： 不改变就不可能进步，无法改变自己的想法，就不能改变任何东西。 现在，我们关注的是应用程序生命期管理方法的改变。重要的是，我们是否真的需要这种改变？我们是否真的需要经历改变的痛苦？ 答案是肯定的。 人们可能会说

配置管理工具 配置管理工具（SCM，Software Configuration Management）可以将代码、软件方式实现的基础设施配置信息保存，也可以根据需求变化反复进行变更。 相关工具包括Ansible、Chef、Puppe、SaltStack等，版本管理工具有Git、Subversion等。 省时省力：通过自动化进行快速设置 声明式：通过配置信息对当前配置对象的具体状态进行明确描述 抽象化：配置信息能涵盖细微的环境差异 收敛性：不管对象的状态如何，最终都会达到期望的状态 幂等性：不管执行多少次，都能得到相同的结果 Ansible Ansible是基于python语言开发的一种开源的自动化运维工具和平台，集合了众多运维工具的优点，实现了批量配置管理、批量应用部署和运行命令执行特定任务等功能。 Ansible基于SSH来和远程主机通讯，不需要在远程主机上安装client/agents。 Ansible只是提供一种框架，本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块。主要包括： 连接插件connection plugins：负责和被监控端实现通信 host inventory：指定操作的主机，是一个配置文件里面定义监控的主机 各种模块核心模块、command模块、自定义模块 借助于插件完成记录日志邮件等功能 playbook：剧本执行多个任务时

#salt的配置文件要遵守YAML格式； #添加file root [root@linux-node1 salt]# vim master file_roots: base: - /srv/salt/base dev: - /ser/salt/dev test: - /srv/salt/test prod: - /srv/salt/prod #手敲，不建议复制，注意空格不要用tab键 #创建相应的目录 [root@linux-node1 salt]# mkdir -p /srv/salt/{base,dev,test,prod} [root@linux-node1 salt]# systemctl restart salt-master #重启后检查服务是否正常 [root@linux-node1 salt]# salt '*' test.ping linux-node2: True linux-node1: True #如果服务异常查看日志 [root@linux-node1 salt]# tailf /var/log/salt/master #通过salt安装apache #创建状态文件 [root@linux-node1 base]# vim apache.sls apache-install: pkg.installed: - name: httpd apache

2.1 Software Lifecycle and Configuration Management 概论 软件开发过程 传统的软件开发过程模型 敏捷开发 软件配置管理 Git 软件开发的生命周期 版本管理 传统软件开发模型 两种基本的类型 线性过程 迭代过程 目前常用的模型 瀑布过程 增量过程 V模型 原型过程 螺旋过程 选择类型的依据 用户参与程序开发有多大 开发效率 管理复杂度 开发出的软件的质量 瀑布过程 几个特点 线性推进 阶段划分过程 整体推进 无迭代 管理简单 无法适应需求的改变 增量过程 每次只开发一点点 开发过程被分割为几个小的功能 需求可变 几个特点 线性推进 增量式(多个瀑布的串行) 没有迭代 比较容易适应需求的增加 V模型 软件生命周期 计划 需求 设计 构造 测试 部署 运营 计划 需求:产品经理 设计:架构师 构造:程序员 部署 运营:运维 原型过程 在原型上进行进行迭代 时刻发现用户需求 时间代价高 程序质量高 螺旋模型 复杂的开发过程 多轮次迭代 基本符合瀑布 每轮次迭代有明确目标 遵循原型过程 进行严格的风险控制 才可以进行下一轮次迭代 敏捷开发 敏捷开发 :通过快速的迭代和效果的持续改进 以快速适应变化 类似于增量和原型的叠加 敏捷开发的特点 对用户需求反应及时 流程短 开发灵活 敏捷开发过程 特征 极致的用户参与 极致的小步骤迭代

登录访问 http://ip　　　　　　#root用户/密码（第一次登录重置的密码） group管理 一个开发团队或者一个项目组对应一个group 组，一个组内会有多个仓库，对应团队的代码都放在这个组内，通过授权控制其他用户对组内信息的访问。 创建 点击管理设置 新建组 选择项目的私密级别，一般为private 用户管理 新建 New user 其他信息填写 授权管理 可以针对组授权，也可以针对仓库授权，如果是组的话那么组内所有仓库都继承了该权限。 创建项目仓库 用户账号密码管理 生产环境一般使用LDAP管理用户账户密码。如果没有LADP可以通过管理员编辑用户，配置临时密码，用户通过临时密码登录系统后提示重置密码登录即可。 项目仓库的连接 通过ssh 方式的话需要在项目上添加密钥。 点击图标 选择如下选项 每个git客户端开发者都有一个对应的gitlab仓库的用户账号，通过此账号管理其对应的仓库，在git客户端服务器上生成密钥对，把生成的公钥通过gitlab账号复制到gitlab上面即可。 git 客户端连接gitlab git clone git@192.168.67.130:sign_group/project-hjs.git notice: 　　一般都不用管理员去gitlab上添加公钥，都是普通用户。 　　如果不添加密钥，git客户端通过ssh 访问gitlab