|
|
|
|
下载
ssh-keygen
生成带有密码的私钥文件,当想要更改密码,可以通过下面方式更改密码或者将密码置为空。
ssh-keygen
|
|
openssl
|
|
CentOS Linux release 7.1.1503 (Core)
bind bind-libs bind-devel bind-utils bind-chroot
|
|
拷贝 bind 相关文件, 准备 bind chroot 环境
|
|
在 bind chroot 的目录中创建相关文件
|
|
变更目录权限
|
|
拷贝 named.conf 配置文件
|
|
修改 bind 配置文件
|
|
zone 配置
|
|
启动服务
|
|
将 docker 作为本地 web 开发环境是使用 docker 的最简单情况,可以完全实现生产环境,保证开发环境和部署环境一致,下面讲创建一个简单的网站 sample。
|
|
|
|
|
|
Dockerfile 内容主要包含下面几项
/var/www/html
|
|
利用之前的 Dockerfile,可以利用 docker build
命令构建出新的镜像,并将该镜像命名为 czero/nginx:v1
通过 docker history
可以看到构建过程
|
|
使用 czero/nginx:v1 镜像,构建容器
|
|
|
|
在执行docker run
命令时,会创建一个 blog 容器,-v
选项允许将宿主机的目录挂载到容器中,然后会传入 nginx
启动命令,让 ningx 启动后已交互模式在前台运行。
卷在 docker 中非常有用,卷是一个或者多个容器内被选定的目录,可以绕过分层的联合文件系统,为 docker 提供持久数据或者共享数据,对卷的修改会直接生效,并会绕过镜像,当提交或者创建镜像时,卷不会被包含在镜像中。利用卷可以实现不想把代码或者应用等构建到镜像中,或者是希望同时对代码做开发和测试、代码频繁改动,不想在开发过程中重新构建镜像、希望在多个容器中共享代码。
-v
参数指定了卷的源目录和容器里的目的目录,这两个目录通过:
分隔,如果目的目录不存在,docker 会自动创建。也可以在目的目录后面添加rw、ro
来指定目录的读写状态-p
参数指定了将容器内部的端口映射到本地的指定端口,本地端口:容器端口
,可以不指定本地端口。
通过docker ps
命令可以查看正在运行的容器,可以看到 blog 容器正在活跃状态,并将 80 端口映射到本地的 80端口。
现在构建一个更大的 web 应用,一个基于 sinatra 的 web 应用。
|
|
|
|
|
|
|
|
Dockerfile 中的 CMD
指令,会让镜像启动容器时,执行该命令
|
|
在运行 docker logs
命令时,加上-f
参数,会持续食醋胡容器的 stderr
和 stdout
|
|
|
|
sinatra 应用只接受输入参数,并将输入转成 JSON 输出
扩展 sinatra 应用程序,在后端加入 redis 数据库,并在数据库中存入输入参数。构建全新的镜像和容器运行 redis 数据库,通过 docker 管理两个容器。
|
|
|
|
dockerfile 指定安装 redis 服务,开放 6379 端口,并启动 redis 服务
|
|
|
|
连接到 docker 容器有两种方式,
查看 容器 IP 信息
安装docker时,会创建一个名为 docker0
的网卡,主机上的容器都会在这个网卡上分配到一个地址,docker0 网卡,拥有一个私有IP段,172.16~172.30
,网卡是一个虚拟的以太网桥,用于连接本地忘了和容器网络,在容器中,会以veth
开头来命令网卡,并随机分配到一个 ip 地址,当知道了容器的ip,两个容器便可以通过 IP及端口相互访问,但是这种方式有个缺点。由于容器的 ip 地址是由 docker0
网卡分配的 ip 地址,当容器被重启,容器本身的 ip 地址会改变,这样当两个容量使用固定 ip 地址方式访问,这样便会连接不上。
|
|
|
|
|
|
--link
标志创建两连个容器间父子连接,这个标志需要两个参数: 一个是要连接的容器名称,另外一个便是连接后容器的别名 ,上面列子便是连接到 sinatra_redis
容器,并使用 db
作为别名。别名可以访问公开的信息,而无需关注底层容器的名字。连接让父容器可以访问子容器,并且把子容器的一些连接细节分给父容器。
这样会在安全性上得到提高,在启动 redis 时,并没有使用 -p
开放容器端口,当使用--link
时,可以让父容器直接访问子容器的开放端口。在启动容器守护进程时,如果加上 --ice=false
便会关闭所有没有连接的容器通信。被连接的容器要求必须是同一主机上的容器,不同主机上的容器不能连接
在创建两个容器连接后,会在两个地方写入连接信息
|
|
|
|
使用 host 或者 ENV 给应用加入连接信息,例如
在docker run 命令中加入 –dns 或者 –dns-search 标志可以为容器定义dns
再次使用curl
命令测试 sinatra 程序
再次确认 redis 是否收到更新
]]>ubuntu-16.04
中挂载nfs 提示
|
|
解决:
Go For It! 界面透着 Elementary/GNOME HIG 的简洁风格,使用 Vala/GTK3 创建,其待办事项部分以 Todo.txt(更多说明参见文末)格式保存。
这个视频说明了 Go For It! 的工作流程(朝内镜像),简单来说:
Go For It! 提供 Linux 及 Win 平台版本,不久将提供 OS X 版本。
与 Evernote 或 Google Keep 等具备待办事项功能的便笺本相比,Todo.txt 利用预定义纯文本方式记录事项,某种意义上保证了向前兼容性。同时因为是简单的纯文本,它可以方便和各个平台进行集成,包括命令行终端及 Vim 插件。iOS 及 Android 客户端更是不在话下。同步的工作由 Dropbox 实现。
]]>
|
|
|
|
该命令会在~/.password-store
目录中创建一个密码仓库
|
|
|
|
|
|
|
|
|
|
ubuntu server 16.04 LTS
|
|
安装顺序:rvm ruby rails nginx mysql redmine
1. 安装 rvm (用于管理多个 ruby 版本的一个管理器)
2. 载入 rvm 环境
3. 检查 rvm 是否安装成功
4. 安装 ruby 环境
5. 设置 ruby 默认版本
6. 变更镜像
7. 安装 bundler
8. 安装 rails
9. 检查安装包版本
10. 可选升级
1. 安装 passenger
2. 安装 curl 模块
3. 安装 pcre
4. 安装nginx
|
|
5. 配置nginx配置
|
|
|
|
1. 将软件包安装到 /opt
目录下
2. 变更 gem 安装源
3. 设置 redmine 数据库、用户名、口令
4. 设置连接数据库
5. 安装依赖包,根据 bundle install --without development test
的输出提示,安装缺少的依赖包
6. Session 存储密钥
7. 生成 redmine 的数据库表结构和初始化数据
8. 创建上传文件的目录和设置文件夹的权限
9. 测试 redmine
|
|
|
|
|
|
|
|
关于备份,官方提供的方法是
由于 Redmine 的用户和问题等信息存储于 Mysql 数据库,表名为 redmine 而附件等资源存储于 Redmine 安装目录的 files 目录下。
简单来说只需要备份 Mysql 数据库的对应的表和 redmine 软件的 files 目录即可。
|
|
按照上面安装过程,安装 redmine 需要的环境,之后导入数据库(记得要创建 redmine 用户或给 mysql 授权),再将相应软件包解压即可
如果是升级,只拷贝 file
目录。
使用 redmine 运行用户,clone 项目至 redmine 目录,
|
|
项目-配置-版本库:新建
实时、定时更新
下载插件到 plugins 目录,并执行
scrum 插件
参考
python 使用 lambda 创建匿名函数,匿名函数就是不适用 def
语句定义函数,语法
其中,参数是可选的,如果使用参数,参数通常也会在表达式中
|
|
|
|
图注:一张图掌握 Docker 命令 - 完整版
在 docker 镜像的制作过程中,有不少方式可以减少容器的空间占用,甚至镜像可以精简 98%,精简 docker 镜像,既节省了存储空间,又能节省带宽,加快传输。
在开始制作镜像前,首先了解镜像的原理,而这其中最重要的概念就是镜像层(Layers)
在 Dockerfile
中的每条指令都会创建一个镜像层,继而会增加整体镜像的大小。
|
|
在上面例子中,最终容器没有变回,但是新生成的镜像会比原生镜像大。
|
|
通过这个例子,演示如何精简 docker 镜像大小。
选用更小的基础镜像,在常用的 Linux 系统镜像中,Ubuntu、Centos、Debian中,debian 更为轻量。
串联 Dockerfile 指令(一般为 RUN 命令)
docker 自带的一些命令还能协助压缩镜像,比如 export 和 import
麻烦的是需要先将容器运行起来,而且这个过程中你会丢失镜像原有的一些信息,比如:导出端口,环境变量,默认指令。
下载安装
使用 scratch 或者 busybox 作为基础镜像。
关于 scratch
关于 busybox + 只有 1~5M 的大小 + 包含了常用的 UNIX 工具 + 非常方便构建小镜像这些超小的基础镜像,结合能生成静态原生 ELF 文件的编译语言,比如C/C++,比如 Go,特别方便构建超小的镜像。
|
|
|
|
|
|
|
|
|
|
Keepalived 是一种高性能的服务器高可用或热备解决方案,Keepalived可以用来防止服务器单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生,通过配合Nginx可以实现web前端服务的高可用。
|
|
主ningx | 备nginx |
---|---|
172.16.6.245 | 172.16.6.246 |
|
|
|
|
|
|
|
|
|
|
配置完成后就可以运行看下效果了,分别在主从服务器上启动nginx和keepalived
启动之后通过ip -a
命令查看主服务器的网络信息,可以看到在eth0网卡下生成了172.16.6.250
这个虚拟ip,并可通过这个ip访问到nginx
然后我们关闭nginx的进程(如果配置了一次尝试重启那要注意下),然后我们可以通过ps -e查看keepalived进程是否关闭,正常情况下查看网络信息中,可以看到eth0网卡下的虚拟ip已经解除,然后在从服务器的网络信息中可以看到从服务器的eth0网卡绑定了虚拟ip,通过这个ip就访问到了从服务器的nginx去了,这是我们重新启动主服务器的nginx和keepalieved,我们可以发现虚拟ip就绑回到了主服务器。
lVS是Linux Virtual Server的简写,即Linux虚拟服务器,是一个虚拟的服务器集群系统,LVS项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一。目前有三种IP负载均衡技术(VS/NAT、VS/TUN和VS/DR);十种调度算法(rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq)
。
Keepalived是一个类似于layer3,4&5交换机制的软件,主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现。高可用架
##简单负载均衡架构
IP信息列表:
名称 | IP |
---|---|
LVS-VIP | 172.16.7.55 |
LVS-Master | 172.16.7.56 |
LVS-Slave | 172.16.7.57 |
Web-RealServer | 172.16.7.16 |
Web-RealServer | 172.16.7.144 |
IPVS (IP Virtual Server)是整个负载均衡的基础,如果没有这个基础,故障隔离与切换就毫无意义。IPVS基本上是一种高效的Layer-4交换机,它提供负载平衡的功能。当一个TCP连接的初始SYN报文到达时,IPVS就选择一台服务器,将报文转发给它。此后通过查发报文的IP和TCP报文头地址,保证此连接的后继报文被转发到相同的服务器。这样,IPVS无法检查到请求的内容再选择服务器,这就要求后端的服务器组是提供相同的服务,不管请求被送到哪一台服务器,返回结果都应该是一样的。但是在有一些应用中后端的服务器可能功能不一,有的是提供HTML文档的Web服务器,有的是提供图片的Web服务器,有的是提供CGI的Web服务器。这时,就需要基于内容请求分发 (Content-Based Request Distribution),同时基于内容请求分发可以提高后端服务器上访问的局部性。IPVS具体实现是由Ipvsadm这个程序来完成,因此判断一个系统是否具备ipvs功能,只要查看Ipvsadm程序是否安装,最简单的办法便是执行命令ipvsadm。
|
|
|
|
报错:
解决:
|
|
绑定VIP地址到LVS_Master上,并设定LVS工作模式为dr(此脚本不适用在Keepalived方案中,只可单独使用),代码如下
|
|
|
|
|
|
修改/etc/keepalived/keepalived.conf,以下是Master的配置文件,Backup的只需要将红色的子修改即可。
|
|
|
|
|
|
|
|
|
|
|
|
在172.16.7.16和172.16.7.144分别创建以本机IP命令的index.html文件,放到apache的DocumentRoot中(这里放置不同内容是为了方便测试,在生产环境中应该是相同文件)
|
|
用两台不同机器访问VIP
|
|
看到两台机器访问VIP,得到的内容不一样,说明负载均衡成功。
|
|
说明backup已经接管服务,测试访问
web访问并没有受到影响
|
|
在master工作后,backup又将工作交还给master
]]>
|
|
Keepalived 是一个基于VRRP协议来实现服务器高可用或热备解决方案,Keepalived可以用来防止服务器单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生,通过配合Nginx可以实现web前端服务的高可用。
VRRP全称 Virtual Router Redundancy Protocol,即 虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议,即将N台提供相同功能的路由器组成一个路由器组(Router Group),这个组里面有一个master和多个backup,但在外界看来就像一台一样,构成虚拟路由器,拥有一个虚拟IP(vip,也就是路由器所在局域网内其他机器的默认路由),占有这个IP的master实际负责ARP相应和转发IP数据包,组中的其它路由器作为备份的角色处于待命状态。master会发组播消息,当backup在超时时间内收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master,保证路由器的高可用。
在VRRP协议实现里,虚拟路由器使用 00-00-5E-00-01-XX 作为虚拟MAC地址,XX就是唯一的 VRID (Virtual Router IDentifier),这个地址同一时间只有一个物理路由器占用。在虚拟路由器里面的物理路由器组里面通过多播IP地址 224.0.0.18 来定时发送通告消息。每个Router都有一个 1-255 之间的优先级别,级别最高的(highest priority)将成为主控(master)路由器。通过降低master的优先权可以让处于backup状态的路由器抢占(pro-empt)主路由器的状态,两个backup优先级相同的IP地址较大者为master,接管虚拟IP。
Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好,首先我想说明的是,Heartbeat、Corosync是属于同一类型,Keepalived与Heartbeat、Corosync,根本不是同一类型的。Keepalived使用的vrrp协议方式,虚拟路由冗余协议 (Virtual Router Redundancy Protocol,简称VRRP);Heartbeat或Corosync是基于主机或网络服务的高可用方式;简单的说就是,Keepalived的目的是模拟路由器的高可用,Heartbeat或Corosync的目的是实现Service的高可用。
所以一般Keepalived是实现前端高可用,常用的前端高可用的组合有,就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用,常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。总结一下,Keepalived中实现轻量级的高可用,一般用于前端高可用,且不需要共享存储,一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用,且需要共享存储,一般用于多节点的高可用。这个问题我们说明白了。
又有博友会问了,那heartbaet与corosync我们又应该选择哪个好啊,我想说我们一般用corosync,因为corosync的运行机制更优于heartbeat,就连从heartbeat分离出来的pacemaker都说在以后的开发当中更倾向于corosync,所以现在corosync+pacemaker是最佳组合。
Nginx+Keepalived主从方式
多个主机使用一个VIP地址,一个做为主服务器,剩下的为备用服务器,正常下只有一个在工作,只有当主服务器出现故障时,被服务器才会被启用
Nginx+Keepalived双主(多主)方式
要求使用两个或两个以上的VIP地址,两个服务器互为主备或一主多备,同时在工作,当一台出现故障,请求转移到备用服务器,本文采用这种方式
用途 | ip | 备注 |
---|---|---|
CMDB-DB-M | 172.16.8.140 | Ubuntu-16.04 LTS |
CMDB-DB-S | 172.16.8.144 | Ubuntu-16.04 LTS |
CMDB-Calc | 172.16.8.244 | Ubuntu-16.04 LTS |
Gjobs-DB-M | 172.16.8.158 | Ubuntu-16.04 LTS |
Gjobs-DB-S | 172.16.8.169 | Ubuntu-16.04 LTS |
Gjob-Ansible | 172.16.8.176 | Ubuntu-16.04 LTS |
Greports-DB-M | 172.16.8.164 | Ubuntu-16.04 LTS |
Greports-DB-S | 172.16.8.197 | Ubuntu-16.04 LTS |
Greports-Calc | 172.16.8.204 | Ubuntu-16.04 LTS |
Nginx-PHP-M/B | 172.16.8.156 | Ubuntu-16.04 LTS |
Nginx-PHP-B/M | 172.16.8.178 | Ubuntu-16.04 LTS |
Nginx-Django-M/B | 172.16.8.180 | Ubuntu-16.04 LTS |
Nginx-Django-B/M | 172.16.8.243 | Ubuntu-16.04 LTS |
VIP | 172.16.8.209 | 绑定到Nginx-PHP-M/B |
VIP | 172.16.8.208 | 绑定到Nginx-PHP-B/m |
VIP | 172.16.8.212 | 绑定到Nginx-Django-M/B |
VIP | 172.16.8.225 | 绑定到Nginx-Django-B/M |
主备两个服务器都要安装keepalived
|
|
|
|
|
|
先在就可以先尝试启动keepalived服务,不过刚刚拷贝的init脚本并不适用在Ubuntu系统上(适用于CentOS/RHEL),要稍作修改即可使用,下面的是keepalived apt方式安装的init脚本,直接拿来即可使用。
INIT-keepalived
略
|
|
|
|
创建一个使用 Express 框架的、带有 Redis 后端的 Node.js 应用,并完全 Docker 化。应用会创建一系列的镜像来部署多容器应用。
构建 Redis 基础镜像,之后会使用基础镜像构建主从 Redis 镜像
|
|
通过 ENTRYPOINT
指令制定了 Redis
服务的启动命令,Redis
服务的日志文件保存到/var/log/redis/redis-server.log
|
|
|
|
-h
参数用来指定容器的主机名,用来后面从容器正确解析 Redisprimary
--name
指定容器名如果想要查看 redis
日志,直接使用docker logs redis_primary
会发现没有任何输出,因为redis
把日志输出到日志文件中,可以运行另外一个容器来查看日志
|
|
--rm
参数指定的容器,只会运行一次,进程结束之后便会删除--volumes-from=
参数指定挂载那个容器的所有卷
|
|
-h
参数用来指定容器的主机名--name
指定容器名--link
将redis_primary
以别名Redisprimary
连接到 Redis
从容器查看redis_replica
的log,看看主从时候正常
|
|
|
|
[Nodejs Dockerfile](http://ofc9x1ccn.bkt.clouddn.com/upload/docker/nodejs.tar.gz)
|
|
czero/nodejs:latest
镜像创建了一个名为 nodeapp
的新容器-p
将容器的3000
端口映射到宿主机的3000
端口--link
将redis_primary
以Redisprimary
作为别名连接到新建的nodeapp
容器
|
|
当Node
应用返回OK
便表示应用正常,浏览器的会话状态会被记录到Redis
主容器redis_primary
中,然后便会同步到两个从容器redis_replica1、redis_replica2
中
现在应用已经正常运行,使用logstash
来捕获应用日志。
|
|
|
|
--volumes-from
挂载nodeapp
、redis_primary
的卷,用来访问Redis
和Node
的日志
|
|
现在 Node 和 Redis 的日志便都输出到 logstash里面了。
]]>备份脚本
|
|
备份脚本说明
|
|
备份脚本配置文件,原始备份脚本是交互式的,改为读取配置文件了
|
|
|
|