前言:
Jenkins作为众多CI/CD中的佼佼者相信大家并不陌生,在各大互联网公司广泛使用,并二次开发将jenkins的某些功能封装到了自己公司所开发的运维平台中,省去很多不必要操作提高发布效率,避免很多在发布中的出现的误操作。
简介:
由于本人最近在学习Python在百无聊赖之时写了一个基于Python-Jenkins API的自动部署脚本,该脚本满足日常常用的需求。
Jenkins是一个免费且开源的自动化工具,提供持续集成、持续交付以及持续部署,无论你使用任何平台Jenkins都可以处理任何类型的构建和部署。
CentOS Linux release 7.4.1708 (Core)
java-1.8.0-openjdk.x86_64 1:1.8.0.171-8.b10.el7_5 //2.54(2017-04)和更新版本:java1.8+
最低硬件要求:
256MB的RAM
1GB的磁盘空间(如果将Jenkins作为Docker容器运行,建议最小值为10GB)
小团队的推荐硬件配置:
1GB+RAM
50GB+的磁盘空间
以上内容来自Jenkins官网:https://jenkins.io/doc/book/installing/
假如让你在一组服务器安装某个软件,服务器少的话还可以接受,但如果有上百台服务器的话,这样会耗费大量时间,在这时候Ansible就由此而生;
ansible是新出现的自动化运维工具,基于Python开发,集合了众多运维工具(puppet、cfengine、chef、func、fabric)的优点,实现了批量系统配置、批量程序部署、批量运行命令等功能。
ansible是基于模块工作的,本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块,ansible只是提供一种框架。主要包括:
(1)、连接插件connection plugins:负责和被监控端实现通信;
(2)、host inventory:指定操作的主机,是一个配置文件里面定义监控的主机
(3)、各种模块核心模块、command模块、自定义模块;
(4)、借助于插件完成记录日志邮件等功能;
(5)、playbook:剧本执行多个任务时,非必需可以让节点一次性运行多个任务。
前言:
有时候由于我们都不当操作导致数据库为完全关闭的过程中将进程终止,在终止后数据库无法正常使用,在这个时候如果你没有经验将会慌张失措,可能会导致更加严重的后果,例如:数据丢失,数据文件损坏等等;
现象:
SQL>shutdown immediate
当你执行完这条命令后(或其他模式),在数据库没有完全关闭的情况下你执行了ctrl+c或者终止了该命令,当你下次登陆数据库是就会出现报错。
$sqlplus /nolog
SQL>conn /as sysdba
Connected to an idle instance.
连接到了一个空闲的实例,你以为没有报错是正常的准备开始你的查询,发现
SQL>select status from v$instance;
ORA-01012: not logged on
Process ID: 0
Session ID: 0 Serial number: 0
报错了,这里给出了一个很明显的错误代码ORA-01012,我们拿着这个错误代码去到oracle的官方网站查询这个导致这个错误的原因,可以导致这个问题原因有很多这里就不一一说明了,直接给出本文问题的解决方法吧。
顾名思义就是指复制一个或多个和主库完全一样的数据库环境,当然我们也称其为从数据库,多个数据库备份不仅可以加强数据的安全性,通过其他手段(例如:读写分离)还能提升数据库的负载性能。
MySQL之间数据复制的基础是二进制日志文件(binary log file)。一台MySQL数据库一旦启用二进制日志后,其作为master,它的数据库中所有操作都会以“事件”的方式记录在二进制日志中,其他数据库作为slave通过一个I/O线程与主服务器保持通信,并监控master的二进制日志文件的变化,如果发现master二进制日志文件发生变化,则会把变化复制到自己的中继日志中,然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中,以此实现从数据库和主数据库的一致性,也就实现了主从复制。
172.16.47.144 master
172.16.47.143 salve
程序版本:5.6.38
安装目录:/application/mysql-5.6.38
数据目录:/application/mysql-5.6.38/data
软件包存放目录:/tools
下载链接:https://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.38.tar.gz
消息队列,提供了FIFO的处理机制,具有缓存消息的能力。rabbitmq中,队列消息可以设置为持久化,临时或者自动删除。
1. 设置为持久化的队列,queue中的消息会在server本地硬盘存储一份,防止系统crash,数据丢失
2. 设置为临时队列,queue中的数据在系统重启之后就会丢失
3. 设置为自动删除的队列,当不存在用户连接到server,队列中的数据会被自动删除
Exchange类似于数据通信网络中的交换机,提供消息路由策略。rabbitmq中,producer不是通过信道直接将消息发送给queue,而是先发送给Exchange。一个Exchange可以和多个Queue进行绑定,producer在传递消息的时候,会传递一个ROUTING_KEY,Exchange会根据这个ROUTING_KEY按照特定的路由算法,将消息路由给指定的queue。和Queue一样,Exchange也可设置为持久化,临时或者自动删除。
Exchange有4种类型:direct(默认),fanout, topic, 和headers,不同类型的Exchange转发消息的策略有所区别:
1. Direct
直接交换器,工作方式类似于单播,Exchange会将消息发送完全匹配ROUTING_KEY的Queue
2. fanout
广播是式交换器,不管消息的ROUTING_KEY设置为什么,Exchange都会将消息转发给所有绑定的Queue。
3. topic
主题交换器,工作方式类似于组播,Exchange会将消息转发和ROUTING_KEY匹配模式相同的所有队列,比如,ROUTING_KEY为user.stock的Message会转发给绑定匹配模式为 * .stock,user.stock, * . * 和#.user.stock.#的队列。( * 表是匹配一个任意词组,#表示匹配0个或多个词组)
4. headers
消息体的header匹配(ignore)
所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来。Exchange 和Queue的绑定可以是多对多的关系。
在rabbitmq server上可以创建多个虚拟的message broker,又叫做virtual hosts (vhosts)。每一个vhost本质上是一个mini-rabbitmq server,分别管理各自的exchange,和bindings。vhost相当于物理的server,可以为不同app提供边界隔离,使得应用安全的运行在不同的vhost实例上,相互之间不会干扰。producer和consumer连接rabbit server需要指定一个vhost。
假设P1和C1注册了相同的Broker,Exchange和Queue。P1发送的消息最终会被C1消费。基本的通信流程大概如下所示:
1. P1生产消息,发送给服务器端的Exchange
2. Exchange收到消息,根据ROUTINKEY,将消息转发给匹配的Queue1
3. Queue1收到消息,将消息发送给订阅者C1
4. C1收到消息,发送ACK给队列确认收到消息
5. Queue1收到ACK,删除队列中缓存的此条消息
Consumer收到消息时需要显式的向rabbit broker发送basic.ack消息或者consumer订阅消息时设置auto_ack参数为true。在通信过程中,队列对ACK的处理有以下几种情况:
1. 如果consumer接收了消息,发送ack,rabbitmq会删除队列中这个消息,发送另一条消息给consumer。
2. 如果cosumer接受了消息, 但在发送ack之前断开连接,rabbitmq会认为这条消息没有被deliver,在consumer在次连接的时候,这条消息会被redeliver。
3. 如果consumer接受了消息,但是程序中有bug,忘记了ack,rabbitmq不会重复发送消息。
4. rabbitmq2.0.0和之后的版本支持consumer reject某条(类)消息,可以通过设置requeue参数中的reject为true达到目地,那么rabbitmq将会把消息发送给下一个注册的consumer。
GitLab是利用Ruby On Rails开发的一个开源版本管理系统,实现了一个自托管的Git项目仓库,是集代码托管,测试,部署于一体的开源git仓库管理软件,可通过web界面来进行访问公开的或私人项目。与Github类似,GitLab能够浏览代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本,并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后需要的时候查找。
操作系统:CentOS Linux release 7.4.1708 (Core)
Gitlab 版本:gitlab-ce-10.3.3
安装方式:由于源代码的安装需要安装很多软件包在过程中可能会出错,所以此用官方推荐的omnibus软件包安装方式,Omnibus软件包更可靠的一个原因是它使用Runit重新启动任何GitLab进程以防万一崩溃。在大量使用的GitLab实例上,Sidekiq后台工作的内存使用量将随着时间的推移而增长。Omnibus软件包通过让Sidekiq如果使用太多内存而终止来解决这个问题。在这个终止之后,Runit会检测到Sidekiq有没有运行,如果没有会启动它。由于从源代码安装没有Runit,Sidekiq无法终止,其内存使用量将随着时间的推移而增长。