docker swarm NFS架构测试

本文详细阐述了如何在Docker Swarm环境下解决跨主机数据共享问题,通过NFS实现MySQL等服务的数据持久化,包括docker-compose配置、自动挂载与手动操作的对比,以及注意事项。

背景:

打算使用docker swarm,由于跨主机了,所以自然而然的,会面临两个问题,一是网络,二是数据共享。问题1,如果各个主机上的容器,不能相互通信,那会很糟糕。问题2,试想一下,以后在布署服务的时候,起初容器是在主机1(换言之所产生的有用的数据,也在主机1上),然后服务更新了,现在跑到主机2上了,那么主机2上是没有主机上1的数据。试想一下,如果容器是mysql数据库的话,那就好玩了,相当于每重启或者布署一次的话,就是个新库了,这样肯定是不行的。恩,有需求,那就有解决方案。本节只讨论问题2,即,数据共享,NFS。

需要具备的知识

1是docke swarm的安装,以及命令行的使用

2是NFS的服务端的搭建,以及客户端的挂载。

名词解释:

1、部署或启动:是指执行 docker stack deploy -c docker-compose.yml mysql 命令

2、事先创建或者提前创建:是指手工执行 docker volume create 命令创建volume。

docker volume create --driver local \ --opt type=nfs \ --opt o=addr=192.168.3.50,rw \ --opt device=:/share/a22 \ --name a22_volume

3、自动创建:是指volume写在docker-compose.yml里,启动时,将会自动创建volume。

4、自动挂载:是指在NFS客户端里,执行 mount -l | grep 3.50,可以看到已经成功挂载的路径

测试过程

涉及到的机器,

192.168.3.47(Manager,以及NFS客户端),

192.168.3.48( work,以及NFS客户端 ),

192.168.3.49 (work,以及NFS客户端 ),

192.168.3.50(NFS服务端)

3.50,发布的NFS路径


[root@centos7-04 share]# cat /etc/exports
/share/mysql 192.168.3.0/24(rw,async,no_all_squash,no_root_squash)
/share/test 192.168.3.0/24(rw,async,no_all_squash,no_root_squash)
/share/a22 192.168.3.0/24(rw,async,no_all_squash,no_root_squash)
[root@centos7-04 share]# 

[root@centos7-04 share]# exportfs -v
/share/mysql    192.168.3.0/24(async,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/share/test     192.168.3.0/24(async,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/share/a22      192.168.3.0/24(async,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)btree_check,sec=sys,rw,secure,no_root_squash,no_all_squash) 

docker-compose.yml

version: "3.8"
services:
  mysql-01:
    image: mysql:5.7
    #    container_name: mysql-server
    command: --character-set-server=utf8  --interactive_timeout=120 --wait_timeout=120 --log_error_verbosity=1  --collation-server=utf8_bin --sql_mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION --lower_case_table_names=1
    ##  --skip-grant-tables
    #    restart: always
    environment:
      - MYSQL_USER=cpp  # 创建用户
      - MYSQL_PASSWORD=Tl12345678!  #用户密码
      - MYSQL_ROOT_PASSWORD=Tl12345678! # ROOT帐号的密码
    ports:
      - 3306:3306
    volumes:
      - mysql:/var/lib/mysql  ####事先创建的volume
      - test:/opt #  ## 事先创建的volume
      - a22:/usr/src/ # 测试事先创建的volume
      - /etc/localtime:/etc/localtime:ro
    networks:
      - cpp_net


networks:
  cpp_net:
    external: true

volumes:
  mysql:
    driver_opts:
      type: "nfs"
      o: "addr=192.168.3.50,nolock,soft,rw"
      device: ":/share/mysql"
  test:
    driver_opts:
      type: "nfs"
      o: "addr=192.168.3.50,nolock,soft,rw"
      device: ":/share/test"
  a22:
    external: true

测试的结论

1、docker stack deploy -c ./docker-compose.yml时,会自动挂载(没有事先创建volume,直接在文件里配置)。通过 mount -l | grep 3.50可以看到。

2、不能想着NFS只发布一级目录,然后docker-compose里,映射时填写一下级目上录,不可以这样做。比如 发布的时候为/data,device里写上"/data/mysql或者其它目录",这样子是不行的。

3、device里选项,猜想只能和 【exportfs -v】里看到的路径一样。所以【不能想着以此为基础,继继写一下级目录】。

4、如果事先创建好volume(即 docker volume create)NFS类型时,docker stack deploy不会自动挂载(即 mount -l | grep 3.50无内容),需要手工挂载(即mount -t nfs 192.168.3.50:/share/mysql /挂载点,挂截点 为docker volume inspect 名称,然后定位到 Mountpoint 属性)。

5、docker-compose.yml里自动创建的volume,会在服务关闭时,自己消失。而手工创建的volume,就算服务关闭,也不会自动消失。

6、NFS架构不可用,docker也不会报错

<think>好的,用户想了解如何使用Docker Swarm实现GitLab的高可用性部署。我需要先整理一下Docker Swarm的基础知识,然后结合GitLab的高可用需求来设计方案。 首先,Docker SwarmDocker原生的集群管理工具,可以管理多个Docker节点,提供服务的部署、扩展和故障恢复功能。高可用性通常需要多节点部署,避免单点故障。所以,GitLab的高可用可能需要多个实例分布在不同的节点上,并且数据要持久化,避免数据丢失。 接下来,用户的问题可能涉及到几个方面:Swarm集群的搭建、GitLab服务的配置、数据持久化、负载均衡以及故障转移。需要参考用户提供的引用内容,特别是引用[2]和[4]提到Swarm的功能,比如集群管理、动态伸缩和服务发现,这些对高可用部署很重要。 数据持久化是关键,GitLab的数据包括仓库、数据库(PostgreSQL)、Redis等,必须使用卷或者分布式存储来确保数据在容器重启或迁移时不丢失。引用[5]中提到的Mac部署GitLab时遇到的问题,可能涉及到存储配置,需要注意。 然后,服务发现和负载均衡方面,Swarm自带负载均衡,通过ingress网络将请求分发到各个节点。可能需要配置多个GitLab实例,并确保它们共享同一个数据库和Redis,或者使用外部数据库服务,避免单点故障。 另外,健康检查和服务更新策略也是高可用的一部分。Swarm可以监控服务状态,自动重启失败的容器,或者将流量切换到健康的节点。引用[3]中的docker swarm命令,比如初始化集群和加入节点,这些都是基础步骤。 还需要考虑网络配置,确保不同服务之间的通信,比如GitLab、PostgreSQL、Redis之间的网络互通。可能需要创建覆盖网络(overlay network)来实现跨主机的容器通信。 最后,持续集成和部署方面,用户提到Hyperf和Gitlab-runner,可能需要在Swarm集群中部署GitLab Runner,以实现自动化CI/CD流程,这也需要高可用配置。 总结步骤应该是:初始化Swarm集群、配置存储卷、部署数据库和Redis(或者使用外部服务)、部署GitLab服务并配置副本数、设置健康检查、配置负载均衡和网络,最后测试故障转移和数据持久化是否有效。 可能还需要注意版本兼容性和资源分配,比如内存和CPU的限制,避免节点过载。同时,备份和恢复策略也是高可用的一部分,需要规划定期备份GitLab数据。</think>### Docker Swarm 部署高可用 GitLab 方案 #### 一、基础架构设计 1. **Swarm 集群搭建** - 至少包含 3 个管理节点(Manager)和多个工作节点(Worker),确保集群容错能力[^2] - 初始化 Swarm 集群: ```bash docker swarm init --advertise-addr <MANAGER_IP> ``` - 其他节点加入集群: ```bash docker swarm join --token <SWARM_TOKEN> <MANAGER_IP>:2377 ``` 2. **存储方案** - 使用 `nfs` 或分布式存储(如 `glusterfs`)实现数据持久化 - 挂载卷示例: ```yaml volumes: gitlab_data: driver: local driver_opts: type: nfs o: addr=<NFS_SERVER_IP>,rw device: ":/path/to/gitlab_data" ``` #### 二、服务部署配置 1. **编写 Docker Compose 文件** ```yaml version: '3.8' services: gitlab: image: gitlab/gitlab-ce:latest deploy: replicas: 3 placement: constraints: [node.role == worker] restart_policy: condition: on-failure volumes: - gitlab_data:/var/opt/gitlab - gitlab_logs:/var/log/gitlab - gitlab_config:/etc/gitlab networks: - gitlab_network environment: GITLAB_OMNIBUS_CONFIG: | external_url 'http://gitlab.example.com' volumes: gitlab_data: gitlab_logs: gitlab_config: networks: gitlab_network: driver: overlay ``` 2. **关键参数说明** - `replicas:3` 确保至少 3 个实例运行 - `overlay` 网络实现跨节点容器通信[^4] - 环境变量配置需包含 PostgreSQL 和 Redis 连接信息(建议使用独立数据库集群) #### 三、高可用保障措施 1. **数据库高可用** - 建议使用外部 PostgreSQL 集群(如 Patroni 方案) - Redis 部署哨兵模式或使用云服务 2. **负载均衡配置** ```yaml services: traefik: image: traefik:v2.5 command: - "--providers.docker.swarmMode=true" - "--entrypoints.web.address=:80" ports: - "80:80" deploy: mode: global networks: - gitlab_network ``` 3. **健康检查与自动恢复** ```yaml deploy: healthcheck: test: ["CMD", "curl", "-f", "http://localhost/-/health"] interval: 30s timeout: 10s retries: 3 ``` #### 四、部署与验证 1. 部署服务: ```bash docker stack deploy -c gitlab-stack.yml gitlab ``` 2. 验证状态: ```bash docker service ls docker service ps gitlab_gitlab ``` 3. 模拟故障测试: - 主动关闭一个节点观察服务自动迁移 - 使用 `docker node update --availability drain <NODE_ID>` 测试节点维护场景 --- ### 常见问题解决方案 1. **数据一致性** - 使用分布式锁机制(如 Redis 锁) - 定期执行 `gitlab-ctl reconfigure` 2. **性能优化** - 调整 `unicorn['worker_processes']` 参数 - 配置 SSD 存储提升 IO 性能 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值