docker服务发现——最终测试

简介: 最终测试 首先启动confd,按照前面的命令,去掉onetime参数,放到后台最为守护进程长期运行,确保etcd注册目录修改之后,能准实时生成haproxy的配置文件。 然后在两台slave,一台启动两个nginx容器,一台启动一台,模拟上面的a.abc.com和b.abc.com两个域名。

最终测试

首先启动confd,按照前面的命令,去掉onetime参数,放到后台最为守护进程长期运行,确保etcd注册目录修改之后,能准实时生成haproxy的配置文件。

然后在两台slave,一台启动两个nginx容器,一台启动一台,模拟上面的a.abc.com和b.abc.com两个域名。

docker run -P -v `pwd`/html:/var/www/html -d dockerfile/nginx

这里暴露所有的端口(80和443),然后挂载当前的html目录给该容器,再html目录中创建一个1.html文件,
包含容器id、内部ip、外部ip作为测试。同样启动两个之后,通过master上的etcdctl配置这几个启动的容器:

etcdctl set /services/web/a.abc.com/server1/ip 10.211.55.12
etcdctl set /services/web/a.abc.com/server1/port 49154
etcdctl set /services/web/a.abc.com/server2/ip 10.211.55.12
etcdctl set /services/web/a.abc.com/server2/port 49156
etcdctl set /services/web/b.abc.com/server1/ip 10.211.55.13
etcdctl set /services/web/b.abc.com/server1/port 49154

confd会间歇性检查目录修改状态:

INFO /home/babydragon/haproxy/haproxy.cfg has md5sum c8fb4ae9c10086b9f94cd11d0edecec1 should be 048c844d73c062014c0fd77d9548c47d

2015-02-09T11:42:00+08:00 master confd[3781]: INFO Target config /home/babydragon/haproxy/haproxy.cfg out of sync

2015-02-09T11:42:00+08:00 master confd[3781]: INFO Target config /home/babydragon/haproxy/haproxy.cfg has been updated

然后haproxy被更新:

acl is_a.abc.com hdr(host) -i a.abc.com

acl is_b.abc.com hdr(host) -i b.abc.com



use_backend a.abc.com_cluster if is_a.abc.com

use_backend b.abc.com_cluster if is_b.abc.com



backend a.abc.com_cluster
cookie SERVERID insert indirect nocache

server server1 10.211.55.12:49154 cookie server1 check

server server2 10.211.55.12:49156 cookie server2 check


backend b.abc.com_cluster
cookie SERVERID insert indirect nocache

server server1 10.211.55.13:49154 cookie server1 check

重新启动haproxy的容器(没有配置直接加载haproxy.cfg),查看status页面,两个backend都已经生效。通过curl模拟下:

curl -H "Host: a.abc.com" http://10.211.55.11:49154/1.html

I am a80b37f78259 on 172.17.0.4 (Host: 10.211.55.12)

curl -H "Host: a.abc.com" http://10.211.55.11:49154/1.html

I am 209b20bab7ce on 172.17.0.3 (Host: 10.211.55.12)

由于配置了负载均衡为轮询方式,两次请求被落到了不同的容器上,haproxy正确的将请求分发到了两个容器中。


转载自:https://coolex.info/blog/485.html

目录
相关文章
|
关系型数据库 测试技术 数据库
使用Docker搭建测试用例管理平台TestLink:简易指南
使用Docker搭建TestLink测试管理软件的步骤如下:首先,拉取`bitnami/mariadb`和`bitnami/testlink-archived`镜像。然后,启动MariaDB容器,创建数据库。接着,启动TestLink容器并连接到MariaDB。检查容器状态确保它们已启动。最后,访问`localhost:8099`以使用TestLink,默认用户名为`user`,密码为`bitnami`。这样,你就能在本地便捷地进行测试管理了。
|
负载均衡 网络协议 算法
Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式
本文探讨了Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式,以及软件负载均衡器、云服务负载均衡、容器编排工具等实现手段,强调两者结合的重要性及面临挑战的应对措施。
573 4
|
负载均衡 网络协议 调度
Docker Swarm服务发现与负载均衡
【10月更文挑战第8天】
885 1
|
存储 NoSQL 大数据
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
250 3
|
负载均衡 网络协议 算法
【Docker 专栏】Docker 容器内服务发现与负载均衡
【5月更文挑战第8天】本文探讨了Docker容器中的服务发现与负载均衡。服务发现通过环境变量、DNS或集中式系统(如Consul、Zookeeper)来定位服务实例。负载均衡则采用轮询、随机等算法,可通过软件负载均衡器、云服务或容器编排工具(如Kubernetes)实现。服务发现与负载均衡结合使用,确保请求有效分发和系统稳定性。面对动态性、网络延迟及大规模部署的挑战,需采取相应措施优化。选择合适技术并持续优化,能提升Docker容器应用的性能和可靠性。
770 5
【Docker 专栏】Docker 容器内服务发现与负载均衡
|
消息中间件 测试技术 RocketMQ
docker部署RockerMQ单机测试环境
docker部署RockerMQ单机测试环境
|
IDE 前端开发 时序数据库
【Docker项目实战】使用Docker部署speedtest-tracker速度测试追踪器
【6月更文挑战第4天】使用Docker部署speedtest-tracker速度测试追踪器
1480 1
|
关系型数据库 MySQL 测试技术
使用docker部署MySQL测试环境
使用docker部署MySQL测试环境
408 0
|
网络安全 Docker 容器
测试开发环境下centos7.9下安装docker的minio
测试开发环境下centos7.9下安装docker的minio
898 1
|
分布式计算 大数据 Hadoop
最快方式搭建docker大数据 测试集群
【8月更文挑战第5天】快速搭建Docker大数据测试集群可采用预构建镜像与Compose文件、利用云服务如AWS的ECS、自动化工具如Ansible或参考在线教程。只需简单配置如内存分配及路径,运行`docker-compose up`即可启动含NameNode、DataNode等组件的Hadoop集群。根据需求与资源选择合适方法。
291 0

热门文章

最新文章