容器化Django+Redis+HAProxy应用栈搭建备忘

最近参照浙江大学SEL实验室所著的《Docker容器与容器云》体验了一把使用Docker构建Django+Redis+HAProxy应用栈。由于包括docker的以上几种软件持续更新的原因，按照原书中一些步骤是无法得出期望结果的，解决问题后作此记录备查。
以下步骤需要对照原书内容参看。

目录

应用栈架构

应用栈包含6个docker容器节点，3个Redis数据库节点，1主2从；2个Django应用节点和1个HAProxy节点。

首先pull所需的docker镜像：django, redis及haproxy。由于众所周知的原因，需要使用国内容器厂商的镜像加速功能，这里使用daocloud的镜像加速

    $ docker pull django    $ docker pull redis    $ docker pull haproxy

镜像获取到之后如果按照书上步骤立即启动容器会导致后续工作比较麻烦。这是因为需要在host环境下修改配置文件并映射到容器中相应的文件夹，先作好配置文件的准备再使用正确的Volumes映射参数来启动容器才容易得到预期的结果。

Redis主从服务的搭建

原书中给出的redis容器启动命令应该是遗漏了数据卷映射的参数”-v /data”，所以后面如果使用docker inspect --format "{{ .Volumes }} <container id> 命令去查看映射/data到host的/var/lib/docker下哪个文件夹时会出错。加了“-v /data”映射后使用上述命令仍然查看不到/data数据卷映射的位置。
原书的意图是通过数据卷把redis.conf配置文件拷进容器内供启动redis-server使用，所以可以直接把host的/etc/redis/redis.conf映射入容器。
首先在host安装一个redis，得到redis.conf模板
$sudo apt-get install redis-server
然后编辑/etc/redis/redis.conf文件，分成两个版本，一个redis-master.conf，一个redis-slave.conf，因为我们的redis主数据库和两个从数据库配置是不同的。下面仅列出不同之处：
redis-master.conf:

    port 6379    bind 0.0.0.0

redis-slave.conf

    slaveof master 6379    bind 127.0.0.1

这里master节点的bind参数要设置成0.0.0.0，如果设置成127.0.0.1会报错。
slaveof master是用利用docker的–link选项的机制，将master解析为对应的容器IP地址。
其他还需要注意的参数有logfile和dir，分别指定输出log的文件夹和redis的工作目录，注意目录事先要存在。
接下来就可以启动应用了：

1. 先启动master节点

   $docker run -it -v /etc/redis:/etc/redis --name redis-master /bin/bashroot@<redis-master id># redis-server /etc/redis/redis-master.confroot@<redis-master id># tail -F /var/log/redis-server.log

   启动后在容器内运行redis-server并观察日志输出。

2. 换个终端启动两个slave节点

   $docker run -it -v /etc/redis:/etc/redis --name redis-slave1 --link redis-master:master redis /bin/bashroot@<redis-slave1 id># redis-server /etc/redis/redis-slave.conf

   第二个slave节点除了–name redis-slave2 其他与第一个slave节点相同

3. 确认redis主从节点同步正常
   如果从master节点日志中看到

   ... * Synchronization with slave <redis-slave1 ip>:6379 succeeded... * Synchronization with slave <redis-slave2 ip>:6379 succeeded

   说明同步正常。
   也可以按照书上步骤测试数据在主从节点间的传输。

Django应用的搭建

应用容器的启动和使用django框架生成helloworld应用的步骤和书上一致。此处不再赘述。有差别的地方在于：
1. 新版本的django.conf.urls不再支持patterns对象，所以urls.py文件内容如下
Python
from django.conf.urls import include, url
from django.contrib import admin
from helloworld.views import hello
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^helloworld$',hello),
]

2. manage.py中没有syncdb方法了，执行完makemirgrations后直接执行migrate即可

root@<django app1>#python manage.py makemigrations
root@<django app1>#python manage.py migrate


HAProxy的配置

HAProxy的设置和redis的设置类似，也是先创建好配置文件，再映射到容器数据卷中去。不同之处是配置文件中listen一节需要修改为：

listen redis_proxy    bind *:6301    stats enable    stats url /haproxy-stats    server APP1 APP1:8001 check inter 2000 rise 2 fall 5    server APP2 APP2:8002 check inter 2000 rise 2 fall 5

然后启动HAProxy容器(配置文件在host上的路径为/etc/HAProxy/haproxy.cfg)

$docker run -it --name HAProxy --link APP1:APP1 --link APP2:APP2 -p 6301:6301 -v /etc/HAProxy:/tmp haproxy /bin/bashroot@<haproxy id>#haproxy -f /tmp/haproxy.cfg

启动应用栈并测试连接

分别访问 http://127.0.0.1:6301/admin， http://127.0.0.1:6301/helloworld 以及 http://127.0.0.1:6301/haproxy-stats 测试Django+Redis+HAProxy应用栈是否可以正常访问

小结

将应用栈的各个节点容器化的好处是显而易见的，但在容器中创建整个应用栈的过程并不轻松。问题主要在于django, redis和haproxy标准镜像中都缺少shell下常见的工具，需要利用volume映射机制在host上完成节点配置，再进入容器利用该配置启动相应的服务，来回进入6个容器是个很繁琐的过程。虽然可以docker exec直接在host上运行容器内的服务，但手动启动这些服务仍然需要不少工作量。或许这就是docker compose存在的理由？