Docker 小记 — MySQL 与 Redis 配置

时间 2019-11-16

原文原文链接

前言

本篇随笔是继 “Docker Engine” 与 “Compose & Swarm” 以后的一个实例补充，初衷是记录测试环境中的一次 MySQL 事故，就当作 “Docker 系列” 的一个小收尾吧。其实在生产环境中不推荐使用 Docker 部署 MySQL 和 Redis，那但是 The First Domino，倒一个挂一片呀，不过在本地和测试环境中就随意了。
php

1. 部署准备

通常部署这些 db_service 容器都应该配套其管理工具（我不否定能够经过命令行完成全部的操做，并且功能更多，权限更大，可是非 DBA 的童鞋仍是乖乖使用 UI 吧，耍酷浪费太多时间也不值当🤣)，所以，这里我选择的镜像组合是 mysql、adminer 与 redis、erikdubbelboer/phpredisadmin。html

Ps：这节过短了，就插一些题外话吧。如今爽 Docker 的同时其实也在为过去的本身默哀，想当年初入编程的时候还没普及云服务器和各类打包好的云服务方案，固然也没有 Docker，想作点什么实验和测试都得在本机。本本性能不行还得一天到晚折腾各类安装环境，就拿 db_service 来讲吧，当时选择的是 SQL Server，流行的版本是 0五、08 和 08 r2 等，客户要求啥版本的都有。那开发的时候得在本地装呀，要命的是这家伙根本没法完全卸载，版本之间还有兼容问题，啥错误都遇到过，解决不了最后的终极方案就是重装系统，而后呢... 还得再装呀... 这一会儿就是半天到一天的时间。使用虚拟机吧，打开几个 IDE 再启动几个虚拟机，不要说那时候了，就是如今的主流机也扛不动呀，编程体验几乎为零。这里算是忆苦思甜了，想一想那时候，如今简直太幸福了。mysql

2. 配置

adminer 与 phpredisadmin 均可以在集群内访问须要代理的服务，若是是在服务器上也不用额外暴露 3306 和 6379 端口，如下是个人 docker-compose 配置：程序员

MySQL

mysql:
  image: mysql
  networks:
    - proxy
    - youclk
  volumes:
    - /mnt/nas/db/mysql:/var/lib/mysql
  environment:
    MYSQL_ROOT_PASSWORD: db_password
  deploy:
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g

mysql_admin:
  image: adminer
  networks:
    - proxy
    - youclk
  depends_on:
    - mysql
  deploy:
    labels:
      - com.df.notify=true
      - com.df.port=8080
      - com.df.serviceDomain=mysql.youclk.com
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g

启动后 UI 展现以下：

redis

Redis

redis:
  image: redis
  networks:
    - proxy
    - youclk
  deploy:
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g

redis_admin:
  image: erikdubbelboer/phpredisadmin
  networks:
    - proxy
    - youclk
  environment:
    - REDIS_1_HOST=redis
    - REDIS_1_NAME=redis
  depends_on:
    - redis
  deploy:
    labels:
      - com.df.notify=true
      - com.df.port=80
      - com.df.serviceDomain=redis.youclk.com
    restart_policy:
      condition: any
      max_attempts: 3
    update_config:
      delay: 5s
      order: start-first
    resources:
      limits:
        cpus: '0.50'
        memory: 1g

启动后 UI 展现以下：
sql

若是看过我以前的两篇博文或者对 Compose 有必定了解的话，以上参数一目了然，此处不作过多赘述。docker

但若是是部署在本地的话，各类 db_service 工具或者是集群外的其余服务也可能须要链接 db，因此得暴露其各自的端口，我倾向于再编写一个 docker-compose.local.yml ，用于放置本地配置，以下：编程

version: '3.5'
services:

  mysql:
    ports:
      - 3306:3306
    volumes:
      - /Users/Jermey/Documents/data/db/mysql:/var/lib/mysql
  mysql_admin:
    deploy:
      labels:
        - com.df.notify=true
        - com.df.port=8080
        - com.df.serviceDomain=local-mysql.youclk.com

  redis:
    ports:
      - 6379:6379
  redis_admin:
    deploy:
      labels:
        - com.df.notify=true
        - com.df.port=80
        - com.df.serviceDomain=local-redis.youclk.com

而后再编写一个启动脚本，根据当前的系统环境判断是否合并多个配置文件（个人写法比较粗暴，如有更优雅的方案欢迎留言交流）：服务器

if [ -z "`uname -a | grep 'Linux'`" ];then
    docker-compose -f ../src/docker-compose.yml \
        -f ../src/docker-compose.local.yml \
        config > docker-stack.yml
    docker stack deploy -c docker-stack.yml --with-registry-auth db
else
    docker stack deploy -c ../src/docker-compose.yml --with-registry-auth db
fi

3. MySQL 异常事故记录

开门见山先说结果吧，最后确认是致使异常的缘由是使用 NFS 存储 MySQL 的数据。起初服务一直能很是稳定在我本地的集群中运行，但在测试服务器上却时不时忽然挂掉且没法重启，开始的时候一头雾水，本地和测试环境的配置文件彻底一致呀，并且都是 Docker Swarm 集群，不该该有任何系统因素相关的干扰。并且它不是启动事后立马会挂，而是运行一段时间以后，期间我发了疯地去排除一个个可能致使 MySQL 宕机的其余服务，而因 NFS 可以正常挂载却被我最早排除(期间的心塞程度有 BUG 经历的工友应当能理解)。ide

直到我在 MySQL 官网看到了这则申明：

Caution is advised when considering using NFS with MySQL. Potential issues, which vary by operating system and NFS version, include:

MySQL data and log files placed on NFS volumes becoming locked and unavailable for use. Locking issues may occur in cases where multiple instances of MySQL access the same data directory or where MySQL is shut down improperly, due to a power outage, for example. NFS version 4 addresses underlying locking issues with the introduction of advisory and lease-based locking. However, sharing a data directory among MySQL instances is not recommended.

Data inconsistencies introduced due to messages received out of order or lost network traffic. To avoid this issue, use TCP with hard and intr mount options.

Maximum file size limitations. NFS Version 2 clients can only access the lowest 2GB of a file (signed 32 bit offset). NFS Version 3 clients support larger files (up to 64 bit offsets). The maximum supported file size also depends on the local file system of the NFS server.

Using NFS within a professional SAN environment or other storage system tends to offer greater reliability than using NFS outside of such an environment. However, NFS within a SAN environment may be slower than directly attached or bus-attached non-rotational storage.

If you choose to use NFS, NFS Version 4 or later is recommended, as is testing your NFS setup thoroughly before deploying into a production environment.

官方文档很是直白地警告 NFS 有风险，使用需谨慎。这下总算松了一口气，终于知道问题源头了，反正是测试环境，随便指定 MySQL 挂载集群中一个节点的目录就行。但不死心的我又尝试了下先将 NFS 挂载到主机，而后由 MySQL 容器再去挂载已经挂载了 NFS 的主机目录，如今是已经正常运行好几天了没有再宕机。

Ps：能够将挂载的命令写入初始配置脚本，新服务器到手以后只需执行一行代码就能够愉快地玩耍了，有兴趣能够看我这篇随笔：“Ubuntu 自动化配置”。

结语

编程的乐趣非程序员不能体会，一行行代码造就了这缤纷多彩的世界，并且其最大的魅力在于咱们的产品复用几乎是无成本的。也正因如此，不管我现此生活质量如何，我都能始终怀揣带有一些梦幻色彩的理想，并为之奋斗。而程序员的悲哀也非他人能轻易理解，你可能认为你在处理一个伟大的问题，到头来，可能仅仅是一个符号在做祟。本篇随笔抒情的废话比较多，感谢阅读 :)

个人公众号《有刻》，咱们共同成长！