背景 近期,公司网络要迁移到新的网段,所以原来在服务器上面搭建的docker swarm需要重新构建... 拿到新的服务器地址看了一下,“10.xxx.xxx.xxx" ... 纳尼,这IP赶脚是子网的地址段呀,居然用到了服务器上面!唉,算了吧,当时也没多想,可能是自己少见多怪吧...于是就把几台服务启动swarm搭建好,配置好了manager和work节点,然后创建了Overlay网络,在上面用2个busybox的container做了 个小测试,container之间可以连接,于是把之前停止

我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭遇了恐怖的路由服务(acsrouting)路由错乱问题 —— 请求被随机路由到集群中的任一容器,虽然后来阿里云修复了这个问题,但我们对容器服务失去了信心,走上了用阿里云服务器自建 docker swarm 集群的道路. 用上自建 docker swarm 集群之后,本以为可以在云上容器中过上安稳的日

1.作用 当在 任何 一个 swarm 节点去访问 端口服务的时候 会通过 本节点 的 IPVS ( ip virtual service ) 到 真正的 swarm 节点上 当访问 docker host 3 的 端口 8080 时, 会把 请求转发到 另外两台host 上去 , 然后把 响应返回给用户 2. 功能 外部访问的均衡负载 服务端口被暴露到哥哥swarm节点 内部通过 IPVS 进行均衡负载 3. 实验 创建 一个 名为 demo 的 overlay 网络 另外 创建 client

1. 两个 service 是如何通信的 通过内置的 DNS 服务发现的功能  相互通信的 2. 创建一个 overlay 的 网络 docker network create -d overlay demo 3. 创建一个 whoami 的service  访问 当访问 该容器 的 8000 端口的 返回 容器的 host docker service create --name whoami -p 8000:8000 --network demo -d jwilder/whoami 查看创建

非常抱歉,10:00~10:30 左右博客站点出现故障,给您带来麻烦了,请您谅解. 故障原因与博文中谈到的部署变更有关,但背后的问题变得非常复杂,复杂到我们都在怀疑与阿里云服务器 CPU 特性有关. 这篇博文本来准备 9:30 左右发布的,但发布博文时出现了 docker swarm 部署异常情况,切换到 docker-compose 部署后问题依旧,一直到 10:30 左右才恢复正常,继续发布这篇博文,在标题中加上了“翻车记”. 原先的博文正文开始: 周一向大家汇报车况之后,我们的 .NET

问题:当我们在本地部署了一台Zabbix服务器后,想要对云上的服务器做监控.但是zabbix一个在内网,云服务器一个在公网,网络环境不同该如何解决?能否检测到云服务器数据? 思路:使用NAT技术,将本地的zabbix服务器的内网地址映射成一个固定的公网地址解决网络问题.(NAT:网络地址转换技术) 步骤:出口防火墙--NAT地址转换--云服务器安全组放通端口-云服务器安装zabbix客户端-zabbix管理页面创建主机-查看监控数据 环境介绍: zabbix服务器:zabbix4.0 内网-IP

docker swarm 集群服务通信 前置要求 服务需要在同一个docker swarm集群中 服务需要处于同一个overlay网络上 服务需要暴露容器端口 有2个以上服务名不同的服务 服务部署流程(手动方式) 1. 创建overlay网络 1 2 docker network create docker network ls 2. 创建swarm服务 1 2 docker service create --name ai_voice_engine-development --network

非常非常抱歉,由于我们的疏忽 —— docker swarm 集群中的 2 台服务器没有及时续费,造成在夜里0点被自动关机,从而引发整个 docker swarm 集群故障,造成今天凌晨 0:30 ~ 7:50 左右跑在集群上的站点无法访问,由此给您带来很大很大的麻烦,恳请您的谅解.受这次故障影响的站点有 闪存,博问,班级,园子,短信息,招聘,小组,网摘,openapi . 昨天下午 14: 30 左右我们收到了阿里云的服务器到期通知,由于打算更换这2台到期的服务器,所以没有立即进行续费,准备安

在上周六遭遇阿里云容器服务 swarm 版的故障之后,我们决定还是走自建 docker swarm 之路,只要不是阿里云底层的问题,我们相信会找到办法解决或避开自建 docker swarm 不稳定的问题. 以下是我们即将采用的 docker swarm 集群部署优化措施. 1)2 个 overlay 网络合并为 1 个,以减少维护多个 overlay 网络的开销 之前用了 2 个 overlay 网络 cnblogs 与 proxy ,路由容器 docker-flow-proxy 只加入 pr

2017年12月29日 10:18 ~ 11:00 左右,由于整个 docker swarm 集群宕机,造成我们迁移至 .net core 跑在 docker swram 上的所有站点无法正常访问,由此给您带来很大很大的麻烦,请您谅解.受这次故障影响的站点有 闪存,博问,班级,园子,短信息,招聘,小组,openapi ... 2017年,随着将一个一个项目从 .net framework 迁移至 .net core ,我们兴奋地在部署上迈出了重要的一步——终于可以进行 docker 部署了.对于

在上次遭遇 docker swarm 集群故障后,我们将 docker 由 17.10.0-ce 升级为最新稳定版 docker 17.12.0-ce . 前天晚上22:00之后集群中的2个节点突然出现CPU波动,在CPU波动之后,在凌晨夜深人静.访问量极低的时候,整个集群出现了故障,访问集群上的所有站点都出现了502,过了一段时间后自动恢复正常. ECS实例:swarm1-node5,CPU百分比于00:52发生告警,值为96.14%,持续时间0分钟 ... 昨天早上发现访问部分节点中的容器应

为了迎接春节假期后的访问高峰,我们今天对 docker swarm 集群进行了变更操作,购买了1台阿里云4核8G的服务器作为 worker 节点,由原来的  3 manager nodes + 2 worker nodes 变为  3 manager nodes + 3 worker nodes . 晚上,我们对已经持续运行一段的5个节点逐一进行重启操作,重启方式如下: 1)docker node update --availability drain 让节点下线2)阿里云控制台重启服务器3)d

今天 11:29 - 11:39 左右,docker swarm 集群 3 个 manager 节点同时出现异常,造成整个集群宕机,由此给您带来很大的麻烦,请您谅解. 受此次故障影响的站点有:博问,闪存,班级,园子,短信息,招聘,小组,网摘,新闻,openapi 最近我们刚刚确认我们所有遇到的 docker swarm 不稳定问题都与部分节点的异常状况有关,即使是一直让我们非常头疼的 docker-flow-proxy 路由问题,也是因为路由容器所在的节点出现异常状况,只要通过阿里云控制台重启这

针对这周 docker swarm 集群的频繁故障(详见故障一 .故障二.故障三),我们今天对 docker swarm 集群的部署进行了如下调整. 将 docker engine 由  “17.12.0-ce, build c97c6d6”  升级至  “17.12.1-ce, build 7390fc6” ,这是 docker 在 2 月 27 日发布的最新稳定版. ~# docker -v Docker version 17.12.1-ce, build 7390fc6 将之前的 “5 个

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

对于有多台服务器来讲,如果每一台都去手动操控,那将会是一件非常浪费时间的事情,毕竟时间这东西,于我们而言,十分宝贵,或许在开始搭建环境的时候耗费点时间,感觉是正常的,我也如此,花费大堆时间在采坑和填坑的路上,但是当你踩完后,还通过手动管理的方式去维护,那便是折磨,因此对于多台服务器下的容器编排管理,借助工具将会节省着大把时间,现如今有名的容器编排工具,K8s.Docker Swarm,甚至功能更强大的Rancher,本次我将使用且是我唯一使用过的Docker Swarm工具搭建Docker集群并

非常抱歉,今天 10:05-10:20 左右,我们用阿里云服务器搭建的 docker swarm 集群又出现故障,又是因为突然的节点 CPU 波动. 受这次故障影响的站点有 闪存,博问,班级,园子,短信息,招聘,小组,网摘,openapi ,由此给您带来很大的麻烦,请您谅解. 故障前先是有一个 worker 节点出现 CPU 100% 报警: 云服务器ECS实例:swarm1-node5,CPU使用率于10:00发生告警,值为100%,持续时间1分钟 收到报警后,我们将这个节点下线并重启: do

非常非常抱歉!16:30 ~ 17:00 左右我们用于跑 ASP.NET Core 站点的 docker swarm 集群再次出现宕机,由此给您带来了很大很大的麻烦,恳请您的谅解! 受此次故障影响的站点有:博问,闪存,班级,园子,短信息,招聘,小组,网摘,新闻,openapi 故障的经过是这样的. 一开始只是访问时偶尔出现 503 ,然后 503 逐渐增多.登录到集群的各个节点,发现有节点 ssh 登录响应慢,登录进去后执行 docker 命令也慢,于是将这个节点下线并重启,但是这样操作后又有新

今天中午我们在 docker swarm 集群上发布应用时遇到了一个奇怪的 docker swarm 内置负载均衡的问题,该应用的 2 个新容器成功启动后,在容器内访问正常,但通过服务名访问时一会正常一会缓慢或超时,似乎 docker swarm 内置负载均衡与其中某个容器的网络通信有问题,而没有进行发布操作的应用都正常,重启这2个容器也不能解决问题,后来只能将这个应用部署到备用集群上才临时解决. 我们遇到的 docker swarm 问题也得到了阿里云容器服务团队的关注,今天和他们进行了交流.

最近在淘宝上学习springcloud教程,其中有几节课是讲解讲本地springboot服务打包成镜像并推送到云服务器私有仓库,但是教程里面用的事Mac环境,我的是Windows环境,而且课程里面没有讲解docker本地打包所需要的必备环境,最后我是利用三个晚上终于解决了这个问题,故写此文章总结一下,有写的不对的地方,请多包涵 先建立一个spring boot 服务,这个服务比较简单,我也是根据教程上面建立的,使用的事idea工具 new 一个project 下一步,取名docker-demo