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 部署图如下:

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

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

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

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

  方案二:

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

  Docker 部署图如下:

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

  具体实施步骤如下:

  首先我们要在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,那么在维护上面就会稍许麻烦些,但维护成本比方案一低了很多。

 

 

你可能感兴趣的:(docker)