如何访问 Service?- 每天5分钟玩转 Docker 容器技术(99)
前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性。不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题。
为了便于分析,我们重新部署 web_server。
① docker service rm
删除 web_server,service 的所有副本(容器)都会被删除。
② 重新创建 service,这次直接用 --replicas=2
创建两个副本。
③ 每个 worker node 上运行了一个副本。
好了,现在 service 已经在那里了,我们如何访问呢?
要访问 http 服务,最起码网络得通吧,服务的 IP 我们得知道吧,但这些信息目前我们都不清楚。不过至少我们知道每个副本都是一个运行的容器,要不先看看容器的网络配置吧。
在 swarm-worker1 上运行了一个容器,是 web_server 的一个副本,容器监听了 80
端口,但并没有映射到 Docker Host,所以只能通过容器的 IP 访问。查看一下容器的 IP。
容器 IP 为 172.17.0.2
,实际上连接的是 Docker 默认 bridge
网络。
我们可以直接在 swarm-worker1 上访问容器的 http 服务。
但这样的访问也仅仅是容器层面的访问,服务并没有暴露给外部网络,只能在 Docker 主机上访问。换句话说,当前配置下,我们无法访问 service web_server。
从外部访问 service
要将 service 暴露到外部,方法其实很简单,执行下面的命令:
docker service update --publish-add 8080:80 web_server
如果是新建 service,可以直接用使用
--publish
参数,比如:
docker service create --name web_server --publish 8080:80 --replicas=2 httpd
容器在 80 端口上监听 http 请求,--publish-add 8080:80
将容器的 80 映射到主机的 8080 端口,这样外部网络就能访问到 service 了。
大家可能会奇怪,为什么 curl 集群中任何一个节点的 8080 端口,都能够访问到 web_server?
这实际上就是使用 swarm 的好处了,这个功能叫做 routing mesh,我们下一节重点讨论。
书籍:
1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html
2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html
本文转自CloudMan6 51CTO博客,原文链接:http://blog.51cto.com/cloudman/2045500

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
神奇的 routing mesh - 每天5分钟玩转 Docker 容器技术(100)
接上一节案例,当我们访问任何节点的 8080 端口时,swarm 内部的 load balancer 会将请求转发给 web_server 其中的一个副本。 这就是 routing mesh 的作用。 所以,无论访问哪个节点,即使该节点上没有运行 service 的副本,最终都能访问到 service。 另外,我们还可以配置一个外部 load balancer,将请求路由到 swarm service。比如配置 HAProxy,将请求分发到各个节点的 8080 端口。 ingress 网络 当我们应用--publish-add 8080:80时,swarm 会重新配置 service,我们看看容器都发生了哪些重要变化。 是不是觉得很诧异?之前的所有副本都被 Shutdown,然后启动了新的副本。我们查看一下新副本的容器网络配置。 容器的网络与--publish-add之前已经大不一样了,现在有两块网卡,每块网卡连接不同的 Docker 网络。 实际上: eth0 连接的是一个 overlay 类型的网络,名字为ingress,其作用是让运行在不同主机上的容器可以相互通信。 eth1 ...
- 下一篇
Swarm 如何实现 Failover?- 每天5分钟玩转 Docker 容器技术(98)
故障是在所难免的,容器可能崩溃,Docker Host 可能宕机,不过幸运的是,Swarm 已经内置了 failover 策略。 创建 service 的时候,我们没有告诉 swarm 发生故障时该如何处理,只是说明了我们期望的状态(比如运行3个副本),swarm 会尽最大的努力达成这个期望状态,无论发生什么状况。 以上一节我们部署的 Service 为例,当前 3 个副本分布在swarm-worker1 和swarm-worker2 上。 现在我们测试 swarm 的 failover 特性,关闭 swarm-worker1。 Swarm 会检测到 swarm-worker1 的故障,并标记为Down。 Swarm 会将swarm-worker1 上的副本调度到其他可用节点。我们可以通过docker service ps观察这个 failover 过程。 可以看到,web_server.1和web_server.2已经从 swarm-worker1 迁移到了 swarm-worker2,之前运行在故障节点 swarm-worker1 上的副本状态被标记为Shutdown。 Servi...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS关闭SELinux安全模块
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Hadoop3单机部署,实现最简伪集群