Docker Swarm

导读： 随着 K8s 不断更新迭代，使用 K8s 日志系统建设的开发者，逐渐遇到了各种复杂的问题和挑战。本篇文章中，作者结合自己多年经验，分析 K8s 日志系统建设难点，期待为读者提供有益参考。 在 Logging 这块做了几年，最近 1 年来越来越多的同学来咨询如何为 Kubernetes 构建一个日志系统，或者是来求助在这过程中遇到一系列问题如何解决，授人以鱼不如授人以渔，于是想把我们这些年积累的经验以文章的形式发出来，让看到这篇文章的同学能少走弯路。这个系列文章定位为长篇连载，内容偏向落地实操以及经验分享，且内容会随着技术的迭代而不定期更新。 前言 第一次听到 Kubernetes 的名字是在 2016 年，那个时候 Kubernetes 还处于和 Docker Swarm、Mesos 方案的“三国鼎立时代”，Kubernetes 由于一系列优势（可扩展、声明式接口、云友好）在这一竞争中崭露头角，最终获得统治地位。 Kubernetes 作为 CNCF 最核心的项目（没有之一），是 Cloud Native（云原生）落地的底座，目前阿里已经全面基于 Kubernetes 在开展全站的云原生改造，在 1-2 年内，阿里巴巴 100% 的业务都将跑在公有云上。 CloudNative 在 CNCF 的定义 的核心是：在公有云、私有云、混合云等环境中，通过 Containers

导读：随着 K8s 不断更新迭代，使用 K8s 日志系统建设的开发者，逐渐遇到了各种复杂的问题和挑战。本篇文章中，作者结合自己多年经验，分析 K8s 日志系统建设难点，期待为读者提供有益参考。 在 Logging 这块做了几年，最近 1 年来越来越多的同学来咨询如何为 Kubernetes 构建一个日志系统，或者是来求助在这过程中遇到一系列问题如何解决，授人以鱼不如授人以渔，于是想把我们这些年积累的经验以文章的形式发出来，让看到这篇文章的同学能少走弯路。这个系列文章定位为长篇连载，内容偏向落地实操以及经验分享，且内容会随着技术的迭代而不定期更新。 前言 第一次听到 Kubernetes 的名字是在 2016 年，那个时候 Kubernetes 还处于和 Docker Swarm、Mesos 方案的“三国鼎立时代”，Kubernetes 由于一系列优势（可扩展、声明式接口、云友好）在这一竞争中崭露头角，最终获得统治地位。 Kubernetes 作为 CNCF 最核心的项目（没有之一），是 Cloud Native（云原生）落地的底座，目前阿里已经全面基于 Kubernetes 在开展全站的云原生改造，在 1-2 年内，阿里巴巴 100% 的业务都将跑在公有云上。 CloudNative 在 CNCF 的定义 的核心是：在公有云、私有云、混合云等环境中，通过 Containers

作者 | 元乙 阿里云日志服务数据采集客户端负责人，目前采集客户端 logtail 在集团百万规模部署，每天采集上万应用数 PB 数据，经历多次双 11、双 12 考验。 导读： 随着 K8s 不断更新迭代，使用 K8s 日志系统建设的开发者，逐渐遇到了各种复杂的问题和挑战。本篇文章中，作者结合自己多年经验，分析 K8s 日志系统建设难点，期待为读者提供有益参考。 在 Logging 这块做了几年，最近 1 年来越来越多的同学来咨询如何为 Kubernetes 构建一个日志系统，或者是来求助在这过程中遇到一系列问题如何解决，授人以鱼不如授人以渔，于是想把我们这些年积累的经验以文章的形式发出来，让看到这篇文章的同学能少走弯路。这个系列文章定位为长篇连载，内容偏向落地实操以及经验分享，且内容会随着技术的迭代而不定期更新。 前言 第一次听到 Kubernetes 的名字是在 2016 年，那个时候 Kubernetes 还处于和 Docker Swarm、Mesos 方案的“三国鼎立时代”，Kubernetes 由于一系列优势（可扩展、声明式接口、云友好）在这一竞争中崭露头角，最终获得统治地位。 Kubernetes 作为 CNCF 最核心的项目（没有之一），是 Cloud Native（云原生）落地的底座，目前阿里已经全面基于 Kubernetes 在开展全站的云原生改造，在 1-2

在爬虫开发过程中，你肯定遇到过需要把爬虫部署在多个服务器上面的情况。此时你是怎么操作的呢？逐一SSH登录每个服务器，使用git拉下代码，然后运行？代码修改了，于是又要一个服务器一个服务器登录上去依次更新？ 有时候爬虫只需要在一个服务器上面运行，有时候需要在200个服务器上面运行。你是怎么快速切换的呢？一个服务器一个服务器登录上去开关？或者聪明一点，在Redis里面设置一个可以修改的标记，只有标记对应的服务器上面的爬虫运行？ A爬虫已经在所有服务器上面部署了，现在又做了一个B爬虫，你是不是又得依次登录每个服务器再一次部署？ 如果你确实是这么做的，那么你应该后悔没有早一点看到这篇文章。看完本文以后，你能够做到： 2分钟内把一个新爬虫部署到50台服务器上： docker build -t localhost:8003/spider:0.01 . docker push localhost:8002/spider:0.01 docker service create --name spider --replicas 50 --network host 45.77.138.242:8003/spider:0.01 30秒内把爬虫从50台服务器扩展到500台服务器： docker service scale spider=500 30秒内批量关闭所有服务器上的爬虫： docker

<br />作者 | 元乙 阿里云日志服务数据采集客户端负责人，目前采集客户端 logtail 在集团百万规模部署，每天采集上万应用数 PB 数据，经历多次双 11、双 12 考验。 **导读：**随着 K8s 不断更新迭代，使用 K8s 日志系统建设的开发者，逐渐遇到了各种复杂的问题和挑战。本篇文章中，作者结合自己多年经验，分析 K8s 日志系统建设难点，期待为读者提供有益参考。 <br />在 Logging 这块做了几年，最近 1 年来越来越多的同学来咨询如何为 Kubernetes 构建一个日志系统，或者是来求助在这过程中遇到一系列问题如何解决，授人以鱼不如授人以渔，于是想把我们这些年积累的经验以文章的形式发出来，让看到这篇文章的同学能少走弯路。这个系列文章定位为长篇连载，内容偏向落地实操以及经验分享，且内容会随着技术的迭代而不定期更新。<br /> <a name="hJh8E"></a> 前言 <br />第一次听到 Kubernetes 的名字是在 2016 年，那个时候 Kubernetes 还处于和 Docker Swarm、Mesos 方案的“三国鼎立时代”，Kubernetes 由于一系列优势（可扩展、声明式接口、云友好）在这一竞争中崭露头角，最终获得统治地位。<br /> <br />Kubernetes 作为 CNCF 最核心的项目（没有之一），是

关于Docker Swarm Docker Swarm由两部分组成： Docker集群：将一个或多个Docker节点组织起来，用户就能以集群的方式进行管理； 应用编排：有一套API用来部署和管理容器； 官方资料： https://docs.docker.com/swarm/ 网络图 下图是个典型的Docker Swarm集群部署图，来自Docker官网： 接下来照着上图来搭建一个Docker Swarm集群。 准备工作 本次实战一共用到了5台机器，配置信息全部相同，如下： 操作系统：CentOS Linux release 7.6.1810 Docker服务版本：1.13.1 防火墙都已经关闭； 机器的信息如下表所示： | IP地址 | 主机名 | 身份 | |--|--|--| | 192.168.121.142 | m0 | 管理节点 | | 192.168.121.139 | m1 | 管理节点 | | 192.168.121.140 | m2 | 管理节点 | | 192.168.121.141 | w0 | 工作节点 | | 192.168.121.138 | w1 | 工作节点 | 为什么要三个管理节点？ 从官方图可见，管理节点集群之间的内部管理协调使用了Raft共识算法，这样就保证了管理节点高可用（HA），一般情况下会参考以下两个原则： 部署奇数个管理节点

关于Docker Swarm Docker Swarm由两部分组成： Docker集群：将一个或多个Docker节点组织起来，用户就能以集群的方式进行管理； 应用编排：有一套API用来部署和管理容器； 官方资料： https://docs.docker.com/swarm/ 网络图 下图是个典型的Docker Swarm集群部署图，来自Docker官网： 接下来照着上图来搭建一个Docker Swarm集群。 准备工作 本次实战一共用到了5台机器，配置信息全部相同，如下： 操作系统：CentOS Linux release 7.6.1810 Docker服务版本：1.13.1 防火墙都已经关闭； 机器的信息如下表所示： | IP地址 | 主机名 | 身份 | |--|--|--| | 192.168.121.142 | m0 | 管理节点 | | 192.168.121.139 | m1 | 管理节点 | | 192.168.121.140 | m2 | 管理节点 | | 192.168.121.141 | w0 | 工作节点 | | 192.168.121.138 | w1 | 工作节点 | 为什么要三个管理节点？ 从官方图可见，管理节点集群之间的内部管理协调使用了Raft共识算法，这样就保证了管理节点高可用（HA），一般情况下会参考以下两个原则： 部署奇数个管理节点

先看一个docker-comose的yml文件 version: "3.2" services: docker-test: hostname: docker-test image: '${DOCKER_REGISTRY_URL}/dockerteam/docker-test:1.0' ports: - "9118" env_file: .env deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role== worker] resources: limits: # cpus: '1' memory: 1GB reservations: # cpus: '0.2' memory: 512M 如上文件中，env_file在docker-comose 命令里是支持的，只需要提供对应的.env文件，在.env文件中设置${DOCKER_REGISTRY_URL}变量即可。 但是如果线上在docker swarm 集群环境中docker-comose使用env_file是无效的，那这时候怎么办？这时候不能再去使用.env文件了，我尝试了一下把变量加入到宿主机的环境变量里: export DOCKER_REGISTRY_URL=docker.sifu.cn:12135