Docker系列(十一)-docker-swarm模式
以下所有内容, 全部针对个人项目, 在工作环境中请不要这样使用.
为什么我使用了sawarm模式
启用swarm主要有以下几点:
仅仅使用
docker run
启动项目, 在更新服务时, 服务端口会关闭再启动, 除非每个版本使用单独的端口. 如果每个版本端口均不同, 那么, 我们还要去设计算法来维护可用的端口列表, 而且面对扩容的需要时, 这个算法就更加复杂了. swarm有个好处是升级时可以无缝的进行迁移, 大大减小了部署成本. 相比于docker run
, 它提供了更加全面的功能如果使用Kubernetes这样的编排系统, 当然也是可以做到无缝升级, 但是对于简单的个人项目来讲, 没有必要使用Kubernetes, swarm模式小巧, 而且已经够用了. 当然, 你仍然可以选择minikube, 只是我个人选择了swarm而已.
具体的功能请查看官方文档: Swarm mode overview
在单机环境中, 安装好docker之后, docker swarm init
即可开启.
docker-compose文件
compose是一个可以定义, 运行多个容器的工具, 语法是yaml文件的形式:
1 | version: '2.0' |
建议书写该文件的时候注意版本号. 并且, 不要过分依赖一些黑科技. 简单的映射端口, 挂载文件就好. 过于复杂的功能请提前思考一下是不是有必要.
docker stack部署应用以及持续集成
平时我在写好compose.yaml配置文件后, 不会直接使用docker-compose启动, 而是使用docker stack deploy
来操作.
1 | # 指定使用的compose文件以及stack名称 |
持续集成问题也因为docker stack
而变得简化, 当我在部署应用时, 只需要将配置文件中的image版本更换, 重新deploy就可以了. 以此文件为例:
1 | version: '3' |
当我在书写CI/CD
规则时, 考虑的就是将image位置换掉, 用在azure-pipeline
中,
可以使用sed
将特定的行进行替换, 兼顾了开发以及部署, 个人觉得这个方案还是比较实用且简单.
1 | - script: | |
docker stack局限
如果你详细阅读compose file书写这篇博客, 就会发现, 有一些注意事项, 某些选项会被docker stack
启动时忽略. 比如: devices, links, restart, cap_add, … 很多配置项是没有被支持的.
个人建议你, 这些不支持的选项使用时三思而后行, 简单的web应用不应该对这些服务有所依赖.
总结
本文简要介绍了一下docker的swarm
模式在个人项目中的使用, 这是一种轻量级的CI/CD手段,
而且对各种pipeline语法的兼容也相当优秀, 完全可以快速的接入到现有的项目中.
如果对于用法方面还有疑问可以在评论区讨论.