Skip to content

bind9

部署于 10.190.150.57 - test.cluster.gm上。

配置文件: /etc/bind/

需要注意 /etc/bind/named.conf.options 使用了白名单,只有白名单中的主机可以使用该dns服务器。

重启方式: service bind9 restart

openvpn

部署于 10.251.164.84 - worker1.cluster.gm上。

配置文件: /etc/openvpn/server.conf

所有使用vpn的用户用的是同一个key,使用方式参见在gm_deploy/guanmai-vpn

重启方式: service openvpn restart

docker运维环境

docker环境由 mesos + marathon 实现。

在每一台环境上都装有docker守护服务。环境的安装使用ansible完成的,详见 gm_deploy/demon_hunter 目录。

ansible使用方式:ansible最佳实践

mesos

mesos是整个docker任务云行的基础。 整个环境分成 3台master + 5台slave。

mesos-master 运行于 db.main.cluster.gm, db.alt.cluster.gm, db.old.cluster.gm三台主机上

mesos-slave运行于除db.main.cluster.gm的所有主机上。

db.old和db.alt同时运行着mesos-master和mesos-slave。

zookeeper

zookeeper和mesos-master运行在相同的主机上。

marathon

marathon用于运行服务,如web app, mysql等等。

管理地址是: http://marathon.cluster.gm:8080

marathon采用了HA模式运行,使用 host marathon.cluster.gm将会看到三台主机。 每台主机都是用docker命令手动运行marathon实现的,详见三台主机的 /root/run-marathon-gm-latest.sh启动文件。

marathon-lb

marathon-lb 是集服务发现和负载均衡于一体的代理,核心用haproxy实现。

目前只运行了一个实例: external-lb,用于负载外网可直接访问的服务。

external-lb是一个有状态的应用,运行于 external.lb.cluster.gm 主机,占用了9090管理端口,对外提供80, 443等服务端口,占用10000~11000之间的端口用于服务发现。

在主机目录 /opt/marathon-lb/haproxy有haproxy的配置: ssl证书,letsencrypt生成证书的配置,docker.guanmai.cn的白名单等。

运行时的haproxy配置: http://external.lb.cluster.gm:9090/_haproxy_getconfig

如何重启?

external-lb界面将instance设为0,等部署结束后再设为1即可。

由于这会造成一段时间的终端,所以目前还没有把重要的服务迁移到marathon上。后续需要运行两个marathon-lb的external-lb实例。

gitlab

gitlab 服务也是使用marathon运行的(链接),它也是一个有状态应用,在主机上保留了数据库文件。因此被限制在worker3.cluster.gm上运行。

配置文件及数据目录:/data/gitlab,ssl证书配置在external-lb的haproxy中。

gitlab服务对外提供了22端口,但这个端口在主机上对应的是10007端口(服务端口),腾讯云lb上配置了22端口转发到该10007端口。

docker registry服务

docker registry 跟 gitlab服务运行方式非常相似,运行于 db.alt.cluster.gm 上。配置文件位于 /data/docker/repository/registry

其它服务

external-haproxy-reloader

更新ssl证书后,external-lb中的haproxy需要reload,通过重启该服务来触发 external-lb中haproxy进行reload

db类管理

要优化的事情

external-nginx 上线

doc.guanmai.cn 从测试机上移走,扔marathon上运行

自动ssl证书更新