host

一、案例环境 二、部署Gitlab 1）部署Gitlab 2） 配置免密登录 3）测试免密登录 三、部署Jenkins 四、Jenkins集成Gitlab 五、部署Nginx 六、Jenkins实现代码自动上线 七、Jenkins实现代码自动部署与回退及重复构建 一、案例环境 系统 IP地址 主机名 所运行的服务 Centos 7 192.168.1.6 gitlab gitlab Centos 7 192.168.1.7 Jenkins jenkins Centos 7 192.168.1.8 Nginx nginx 二、部署Gitlab 1）部署Gitlab [root@gitlab ~]# yum -y install epel-release curl openssh-server openssh-clients postfix cronie policycoreutils-python patch #安装所需依赖 [root@gitlab ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-12.3.5-ce.0.el7.x86_64.rpm #对gitlab的版本并没有什么特殊的限制 [root@gitlab ~]# yum -y localinstall gitlab-ce

安装 jdk安装 jdk下载地址：http://www.oracle.com/technetwork/java/javase/downloads/index.html 1）解压并配置环境变量 #cd /usr/local/src/ #tar xf jdk-8u231-linux-x64.tar.gz #ln -s jdk1.8.0_231/ jdk #cat > /etc/profile.d/jdk.sh << EOF export JAVA_HOME=/usr/local/src/jdk export CLASSPATH=.:\$JAVA_HOME/jre/lib/rt.jar:\$JAVA_HOME/lib/dt.jar:\$JAVA_HOME/lib/tools.jar export PATH=\$PATH:\$JAVA_HOME/bin EOF #source /etc/profile.d/jdk.sh 2）查看jdk版本 #java -version java version "1.8.0_231" Java(TM) SE Runtime Environment (build 1.8.0_231-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode) tomcat安装 安装包下载地址

在 MySQL高可用之MHA部署 这篇博文中，已经将MHA的基础架构部署完成，但是并没有解决一个虚拟IP的问题，因为当master宕机后，新的master顶上来，这时前端APP要连接的数据库IP已经发生了变化，为了解决这个问题，必然要引入虚拟IP，谈起虚拟IP，首先想到的应该是keepalived这个工具，但这个工具有个弊端，就是有一个脑裂的问题，所以更建议在生产中使用脚本的方式来控制这个VIP。 1、在manager节点写入此脚本 [root@manager scripts]# cat /scripts/master_ip_failover #!/usr/bin/env perl use strict; use warnings FATAL => 'all'; use Getopt::Long; my ( $command,$ssh_user,$orig_master_host,$orig_master_ip,$orig_master_port, $new_master_host,$new_master_ip,$new_master_port ); my $vip = '192.168.20.100'; #这里指定VIP地址 my $key = '0'; my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";

MySQL高可用集群之MMM 一、MMM简介 MMM即Multi-Master Replication Manager for MySQL（mysql多主复制管理器） ,基于perl实现,关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），MMM也能对从服务器进行读负载均衡，所以可以用它来在一组用于复制的服务器启动虚拟IP，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。MySQL本身没有提供replication failover的解决方案，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。MMM不仅能提供浮动IP的功能，如果当前的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。这个方案是目前比较成熟的解决方案。详情请看官网： http://mysql-mmm.org 优点： 高可用性，扩展性好，出现故障自动切换。 对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。 当主服务器挂掉以后，另一个主立即接管，其他的从服务器能自动切换，不用人工干预。 缺点： monitor节点是单点，不过这个也可以结合keepalived或者haertbeat做成高可用; 至少三个节点，对主机的数量有要求，需要实现读写分离,还需要在前端编写读写分离程序。

配置文件在项目中常用于信息管理，例如数据库信息、服务器信息等，也可以用于环境切换。 配置文件主要有.ini和.conf两种类型。 这里我们使用Python的第三方库模块configparser实现.ini配置文件管理。 首先，准备好配置文件，文件名为conf.ini，文件内容如下： [mysql] host=127.0.0.1 port=3306 user=admin password=123456 这里需要说明一下，ini的文件内容主要有两部分组成，一个是section，一个是option，上面内容中[]内的mysql就是section，而下面的host、port、user、password都是option。 既然有了配置文件，我们如何进行管理呢？ 首先安装configparser模块： pip install configparser 然后导入： from configparser import ConfigParser 实例化ConfigParser操作对象： conf = ConfigParser() 读取配置文件内容： conf.read('conf.ini', encoding='utf-8') 获取mysql的host： conf.get('mysql', 'host') get()方法的第一个参数是section，第二个参数是option，得到的结果默认是字符串类型

tomcat的核心配置在conf/server.xml中。 <Server> 根元素 <Server>即Catalina Servlet组件。 <Server port="8005" shutdown="SHUTDOWN"> 常用属性 Address—Tomcat监听shutdown命令的地址，默认为localhost className—指定实现org.apache.catalina.Server接口的类，默认值为org.apache.catalina.core.StandardServer port－Tomcat监听shutdown命令的端口。设置为-1，则禁止通过端口关闭Tomcat，同时shutdown.bat也不能使用 shutdown－通过指定的地址（Address）、端口（port）关闭Tomcat所需的字符串。 shutdown属性使用示例 启用Telnet：（Telnet是windows自带的与其它主机通信的程序） win+s，输入telnet，匹配“启用或关闭windows功能”，回车，勾选telent 命令行输入 telnet 启动Telnet 输入 telnet localhost 8005 连接到指定主机（此处为本地主机） 输入 SHUTDOWN 即可关闭Tomcat 输入 quit 可退出Telnet <Server>有3个子元素：<Listener>、

多节点部署介绍 在生产环境中，搭建kubernetes平台时我们同时会考虑平台的高可用性，kubenetes平台是由master中心管理机制，由master服务器调配管理各个节点服务器，在之前的文章中我们搭建的是单节点（一个master服务器）的部署，当master服务器宕机时，我们的搭建的平台也就无法使用了，这个时候我们就要考虑多节点（多master）的部署，已到平台服务的高可用性。 负载均衡介绍 在我们搭建多节点部署时，多个master同时运行工作，在处理工作问题时总是使用同一个master完成工作，当master服务器面对多个请求任务时，处理速度就会变慢，同时其余的master服务器不处理请求也是一种资源的浪费，这个时候我们就考虑到做负载均衡服务 本次搭建负载均衡使用nginx服务做四层负载均衡，keepalived做地址飘逸 实验部署 实验环境 lb01：192.168.80.19 （负载均衡服务器） lb02：192.168.80.20 （负载均衡服务器） Master01:192.168.80.12 Master01:192.168.80.11 Node01:192.168.80.13 Node02:192.168.80.14 多master部署 master01服务器操作 [root@master01 kubeconfig]# scp -r /opt

0x01 代码审计中的信息收集 一个cms代码量确实不少,通读代码耗时长,效果也不一定好.而一个功能点如果之前出过漏洞,特别是多次出现漏洞的地方,证明开发者对这个漏洞的理解不充分,很容易再次绕过补丁.这样,一整个CMS的代码审计就可以降维到一道ctf题目.特别是对于经常参加ctf的各位大佬来说,这样的代码审计更加简单休闲.我记得之前也有机构统计过,出过漏洞的地方更容易再次出现漏洞,普通CMS的开发者通常不是专业的安全人员,也不一定有专业的安全专家协助修复,再次出现漏洞的可能性就更大了. 我以github上的一个百星icms为例. icms github链接: https://github.com/idreamsoft/iCMS \ 在issue中搜索SSRF https://github.com/idreamsoft/iCMS/issues?utf8=%E2%9C%93&q=is%3Aissue+ssrf 在cve列表中查找,应该对应的就是这三个cve了 可以看到这个功能点已经出现了三次的绕过与过滤. 大致了解下这个功能点,是一个自动更新文章的爬虫,多处都可以控制url参数. 点开issue查看具体信息,我们从最早出现漏洞的版本看起. 通过查看具体的commits,可以找到开发者修复漏洞的思路.这给我们代码审计带来很大的便利. CVE-2018-14514 漏洞分析 commit:

本章内容： 一.inventory主机清单 二.yml语法 三.playbook详解+操作 inventory主机清单 ansible默认的主机清单是/etc/ansible/hosts文件 主机清单可以手动设置，也可以通过Dynamic Inventory动态生成 一般主机名使用FQDN vi /etc/ansible/hosts [webserver] #方括号设置组名 www1.example.org #定义被监控主机，这边可以是主机名也可以是IP地址，主机名需要修改/etc/hosts文件 www2.example.org:2222 #冒号后定义远程连接端口，默认是ssh的22端口 如果是名称类似的主机，可以使用列表的方式标识各个主机 [webserver] www[01:50].example.org ansible_ssh_user=root ansible_ssh_pass=123456 [dbbservers] db-[a:f].example.org 下面是Inventory中变量 （1）主机变量 [webserver] www1.magedu.com http_port=80 maxRequestsChild=808 www2.magedu.com http_port=8080 maxRequestsChild=909 （2）组变量 [servers:vars]

反向代理：在基本服务器的前端加一台代理服务器。客户端将请求发送到服务器（客户端认为是原始服务器，实际是反向代理服务器），反向代理服务器通过一定的策略将请求转发到服务器集群中的服务器上。然后由集群服务器响应结果。反向代理服务去将结果返回给客户端。在反向代理的基础上衍生出负载均衡和高可用。 Proxy和Server同属于一个LAN（局域网中），隐藏了服务端信息。 反向代理，“它代理的是服务端”，主要用于服务器集群分布式部署的情况下， 反向代理隐藏了服务器的信息 。分布式部署也就是通过部署多台服务器来解决访问人数限制的问题；某宝网站中大部分功能也是直接使用Nginx进行反向代理实现的，并且通过封装Nginx和其他的组件之后形成了Tengine。 反向代理的作用： 保证内网的安全，通常将反向代理作为公网访问地址，Web服务器是内网。 负载均衡，通过反向代理服务器来优化网站的负载。 1.示例1 IP域名 192.168.72.49 8081.max.com 192.168.72.49 8082.max.com #upstream表示负载服务器池，定义名字为tomcatserver1 的服务器池 upstream tomcatserver1 { 　　server 192.168.72.49:8081 ; } upstream tomcatserver2 { 　　server 192.168