本文以技术栈 Redis 为例，列举并解释了一些面向 Docker 进行应用程序开发和系统搭建中所需要注意的问题和技巧，以及 Caicloud 平台在 Docker 管理和帮助企业应用向 Docker 转化中的作用。由于应用程序千差万别，应用场景层出不穷，本文仅起到抛砖引玉的作用。

我们总结基于 Docker 的 Redis 组件的使用注意事项如下：

Redis 的外部存储挂载

Persistence 被开启：无论是 RDB 还是 AOF 模式，都会需要在硬盘上进行存储。以 RDB 为例，会自动存在本地硬盘一个叫 dump.rdb 的文件。如果没有挂载外部存储，这些数据在 docker 销毁后会消失。

主从设置下 Replication 对硬盘的需求：在 Redis 2.8 以前， Master 与 Slave 的同步需要用存储（硬盘）作为中间媒介（自 2.8 此同步可不经过硬盘，但还属于试验内容）。在 Docker 环境下需要挂载 Volume 以保证这个步骤能正常运行。

Redis 不能跑在 daemonize 的模式

Docker 的容器需要其中的主进程一直在前端运行，使用 daemonize 的模式会使得 container 在运行后立即退出。幸运的是在 Redis 的配置文件中 daemonize 模式默认被关闭。如需运行 daemon 模式，应该在 docker 层面通过-d 命令来进行。

Redis 的日志文件目录应置为空

Docker 的容器所产生的日志会被系统自动接收和管理；同时 Caicloud 的集群管理平台更会监测和聚合系统中所有容器的日志。因此在配置文件中将 logfile 设为空会享受 Docker 和 Caicloud 的自动日志收集和管理。

Redis Snapshot 的注意事项

在主从结构下 Snapshot 应开启：如果在 Redis 的 Master 节点上配置了 Persistenceoff (数据不会自动存储到硬盘上)，那么我们同时还应该关掉 Master 节点的自动重启功能。由于 Caicloud 的自动修复功能会重启实效的容器（包括 RedisMaster ），我们应开启 Snapshot 功能。

对 Persistence 的需求： Redis 会把 Snapshot 产生的 rdb 文件写在指定的目录中。默认情况下这个对应在 Docker 内部的一个目录，会随着 Docker 的销毁而销毁。如果有 Persistence 的需求，应该在生成 Dockerfile 和运行 Redis 容器时同时挂载外部的存储。

Redis 的端口映射

Docker 的容器在运行时默认会将容器内的应用端口映射成一个随机的主机端口，但这样会打破一些 Redis 服务。比如 sentinel 需要根据默认端口规则 (26379) 来进行自动发现。因此在 Docker 下运行 Redis 一定要使用 – p port:port 的格式来明确使用默认的 Redis 端口规则。

Redis 主从结构中的 Master 节点的发现

在主从结构中，从节点（ slave ）需要在配置文件中使用 Master 节点的 IP ，来实现与 Master 节点的互连。传统架构中这个 IP 可以预先通过静态绑定。在 Caicloud 体系中，系统不需要静态绑定具体的 IP 地址，而是可以通过 DNS 动态地发现，并通过运行 Docker 时的 CMD 命令来使用特定的脚本将 Master IP 动态添加到配置中。

多个 Redis 集群共存的情况

Caicloud 下不会出现两个 Redis Cluster 混为一起( https://www.oschina.net/news/67037/container-redis-accident) 的情况，因为 Caicloud 的独特网络特性（扁平化，每个机器有自己的网段）。如例子中提到的两个 Redis 集群混在一起需要如下条件：

在某一个物理机上运行来自两个 Redis 集群的 server 实例（ from cluster A and cluster B ）； 在两个 Redis 集群中存在两个 server 实例（ from cluster A and cluster B ）碰巧有同样的 IP （在纯 Docker 环境下有可能，因为每个主机上的 Docker 会随机分配网段和 IP ）

在 Caicloud 环境下，每个 Redis server 都会被分配一个不同的 IP ，每两个 Redis server 的 IP 必定不相同（每个机器有自己的网段，所以不同机器上的 Docker 在给 container 分配地址的时候不会撞车）。

（如果需要转载，请联系我们哦，尊重知识产权人人有责）