Docker学习总结之跨主机进行link

Docker学习总结之跨主机进行link

  Docker的功能非常强大,但要想驾驭好Docker却不是一件很容易的事情。下面就介绍一种日常工作中会遇到的一个user case。比如现在有两台host,分别标记为hostA和hostB。hostA用来运行oracle服务,hostB用来运行app服务。

  hostB中app产生的数据需要实时写入hostA中的oracle数据库。也就是hostB中的docker container需要link hostA中的docker container。

  为了解决这个问题,有两个解决方案:

  方案一:

  将hostA中的oracle container对外expose 1521(我们假定此处对外expose 1521),然后在hostB中的app container中修改/etc/hosts文件,将hostA的IP添加到hosts文件中。

  Docker 部署图如下:

  

  这种方案的优点就是可以根据实际情况自由配置,"自己的app掌控在自己手中"。

  但是缺点也很严重,首先每次run container时都需要修改hosts文件,而且每次host环境发生变化,都需要维护hosts文件,因此后续的维护成本很高。其次,如果遇到其他人开发的docker image,我们未必有权限来修改hosts文件。

  所以此方案也仅仅用作开发测试使用,不推荐正式采用。

  方案二:

  Docker官方提供了一种ambassador的agent方案。此方案借助一个名为svendowideit/ambassador的image,将不同host进行解耦合。

  Docker 部署图如下:

  具体实施步骤如下:

  首先我们要在hostA和hostB之间pull svendowideit/ambassador。

1 docker pull svendowideit/ambassador

  根据部署图可得知,是hostB要link hostA的container,因此我们需要先启动hostA的container(此时可以理解hostA为server段,hostB为client段)。

docker run  -d  --name oracle tirtool/oracle11g:latest

  然后启动hostA中的ambassador container。

docker run  -d --link oracle:oracle -p 1521:1521 --name ambassador svendowideit/ambassador:latest

  标红的部分是需要重点注意的地方,这个命令也就是将hostA中的oracle container直接暴露在ambassador之中,这样ambassador才能将访问请求转发到oracle container中。

  此刻,hostA中的事情都已经处理完了,我们开始处理hostB。

  与hostA的container启动顺序不用,我们需要先start hostB的ambassador。因为依据部署图可知,hostB中是app container调用ambassador container,所以需要先保证ambassador已经启动,才能启动app container。

docker run -d --name ambassador-oracle --expose 1521 -e ORACLE_PORT_1521_TCP=tcp://<<hostA IP>>:1521 svendowideit/ambassador

  标红的部分很重要,直接决定了hostB和hostA是否可以直接通讯。稍后,我们可以来解读一下这部分参数。

  当hostB中的ambassador启动成功后,我们开始启动app container。

docker run --link ambassador-oracle:oracle  --name bw base/ubuntu:14.04

  大家注意到我们在app container中将ambassador-oracle alias为oracle,这样在app container中的/etc/hosts文件中会出现一条记录:

    10.1.0.3        oracle

  此刻app container中app产生数据后,如果调用oracle:1521,那么首先将请求发往hostB的ambassador的1521端口。hostB的ambassador会将数据转发到hostA的1521端口。而此时hostA中的ambassador在listen 1521端口,接收到请求后会将数据转发至hostA的oracle container中。oracle container处理完毕后将response返回值ambassador,ambassador再依次回传。从而达到不同host中container相互访问的目的。

  我们再看一下在hostB中执行 --expose 1521 -e ORACLE_PORT_1521_TCP=tcp://<<hostA IP>>:1521 时发生了什么事情。ambassador最重要的一项任务就是将hostB的1521端口同hostA的1521端口进行了端口映射。

  其实执行的是下面的命令:

  socat TCP4-LISTEN:1521,fork,reuseaddr TCP4:<hostA IP>:1521

  这条命令采取fork模式,将本机的1521的数据转发到hostA的1521端口。而这条命令所需的参数来自于一个shell脚本:

  env | grep _TCP= | sed ‘s/.*_PORT_\([0-9]*\)_TCP=tcp:\/\/\(.*\):\(.*\)/socat TCP4-LISTEN:\1,fork,reuseaddr TCP4:\2:\3 \&/‘  | sh && top

  这条命令在env中找寻所有*_TCP的环境变量,我们在启动时设定-e ORACLE_PORT_1521_TCP=tcp://<<hostA IP>>:1521 所以可以找到ORACLE_PORT_1521_TCP这条变量。找到后执行正则表达式"s/.*_PORT_\([0-9]*\)_TCP=tcp:\/\/\(.*\):\(.*\)/socat TCP4-LISTEN:\1,fork,reuseaddr TCP4:\2:\3 \&/" 替换后的shell command就是socat TCP4-LISTEN:1521,fork,reuseaddr TCP4:<hostA IP>:1521。

  因此ambassador方案就是很巧妙的将不同host的port进行了桥接,而这些对docker使用者都是透明的。但这个方案也是有一些瑕疵的,就是如果新增container之后,需要重启或者新增ambassador,所以如果一个ambassador同时对应多个container,那么在维护上面就会稍许麻烦些,但维护成本比方案一低了很多。

 
时间: 2024-07-30 05:18:47

Docker学习总结之跨主机进行link的相关文章

Docker:使用Ambassador进行跨主机间容器通信

由于Docker自身的网络的原因,想要在多主机间的容器之间进行通信是比较麻烦的事情.可以利用Ambassador容器来实现这一功能. 基本原理: 利用Ambassador来实现主机间容器进行通信时,需要在两台需要通信的容器的主机上都启动Ambassador容器.由Ambassador容器提供数据转发服务. 当客户端主机上的容器client_container想要同服务器端主机上的容器server_container通信时,client_container容器直接访问同一台主机上运行的client

docker部署Macvlan实现跨主机网络通信

基本概念: Macvlan工作原理: Macvlan是Linux内核支持的网络接口.要求的Linux内部版本是v3.9–3.19和4.0+: 通过为物理网卡创建Macvlan子接口,允许一块物理网卡拥有多个独立的MAC地址和IP地址.虚拟出来的子接口将直接暴露在相邻物理网络中.从外部看来,就像是把网线隔开多股,分别接受了不同的主机上一样: 物理网卡收到包后,会根据收到包的目的MAC地址判断这个包需要交给其中虚拟网卡. 当容器需要直连入物理网络时,可以使用Macvlan.Macvlan本身不创建网

centos7下安装docker(15.3跨主机网络-macvlan)

除了ovrlay,docker还开发了另一个支持跨主机容器的driver:macvlan macvlan本身是linu kernel模块,其功能是允许在同一物理网卡上配置多了MAC地址,即:多个interface,每个interface可以配置自己的ip.macvlan本身是一种网卡虚拟化技术,Docker用macvlan实现容器网络就不奇怪了 macvlan最大的优点是性能极好,相比其他方案,macvlan不需要创建Linux bridge,而是直接通过以太interface连接到物理网络.

centos7下安装docker(14.2跨主机网络-overlay)

为支持容器跨主机通信,Docker提供了overlay driver,使用户可以创建基于VxLAN的overlay网络.VxLAN可将二层数据封装到UDP进行传输,VxLAN提供与VLAN相同的以太网二层服务,但是拥有更强的扩展性和灵活性. Docker overlay网络需要一个key-value数据库用于保存网络信息状态,包括Network,Endpoint,IP等.Consul,Etcd和Zookeeper都是docker支持的key-value软件,今天讨论的是consul 试验环境描述

Docker网络之部署跨主机网络overlay

dcoker网络: none网络:什么都没有的网络.它的是使用常见:封闭空间意味着隔离,安全,比如生成随机码.host网络:网络配置与dockerhost完全相同.应用场景:性能好,但是没有灵活性,容易出现端口冲突问题.brigde网络: 默认的网络驱动默认,用以实现主机网络接口与虚拟网络接口间的通信. 部署网络的基本操作命令: //查看docker服务器中的网络:[[email protected] ~]# docker network ls//查看桥接网络:[[email protected

centos7下安装docker(15.6docker跨主机网络---Weave)

Weave是weaveworks开发的容器网络解决方案.weave创建的虚拟网络可以将部署在多个主机上的容器连接起来.对于容器来说,weave就像一个巨大的网络交换机,容器可以直接通信,无需NAT和端口映射.除此之外,weave的DNS模块是容器可以通过hostname访问 weave不依赖分布式数据库(例如:consul和etcd)交换网络信息,每个主机上只需要运行weave组件就能建立起跨主机容器网络,weave网络能够穿透防火墙并运行在部分连接的网络上,weave支持加密网络接连,用户可以

Docker容器跨主机通信之:OVS+GRE

一.概述 由于docker自身还未支持跨主机容器通信,需要借助docker网络开源解决方案 OVS OpenVSwich即开放式虚拟交换机实现,简称OVS,OVS在云计算领域应用广泛,值得我们去学习使用. OpenVSwich OpenVSwich是一种开源软件,通过软件的方式实现二层交换机功能,专门管理多租赁云计算网络环境,提供虚拟网络中的访问策略.网络隔离.流量监控等. 既然是虚拟交换机,自然与传统的物理交换机有着相同的特性,操作中可以按照理解物理交换机的方式去操作,有助于对虚拟交换机的认识

Docker compose v3版本构建跨主机容器编排构建wordpress集群

在Docker 1.13版本之后,可以说Docker 对于compose容器调度编排实现了飞跃,可以使得在编排容器的时候可以结合Docker swarm集群和跨主机通讯的概念.在Docker swarm 的基础之上引入stack对service镜像管理和编排.下面我们实战一下用之前构建wordpress集群来测试一下: 环境要求: 1.存在了Docker swarm集群: [[email protected] ~]# docker node ls ID                      

利用虚拟网桥实现Docker容器的跨主机访问

最近在研究Docker,Docker的网络配置是比较令人头疼的部分,尤其是跨主机的容器间通信,很多解决方案都比较复杂,这里,我只用虚拟网桥来实现Docker的跨主机访问,分享出来,希望对Docker学习的各位有一定的启发. 基本思想: 由于Docker容器通过docker0 网桥实现同一主机间中,容器的ip地址分配和访问,所以,如果希望Docker跨主机访问,最简单的方式就是将不同主机的docker0 设置为同一网段. 那么怎么实现跨主机呢?我这里将本机网卡也通过网桥来连接,那么,整体网络拓扑结