ref="/tag/2019/" style="color:#874873;font-weight:bold;">Docker容器适合跑什么
很多人刚开始接触Docker时，总在纠结：这玩意到底适合跑啥？其实，Docker不是万能的，但它特别擅长处理一些特定场景下的应用部署问题。
最常见的用途就是跑Web服务。比如你写了个用Node.js写的博客后台，或者Python Flask写的接口服务，打包成镜像后，扔到任何装了Docker的机器上都能跑，不用再操心“在我电脑上好好的”这种问题。
docker run -d -p 3000:3000 my-node-app这条命令一跑，服务就起来了，端口映射也配好了，简单直接。
数据库也能跑，但得小心
有人会把MySQL、PostgreSQL这些数据库也丢进容器里跑。技术上完全可行，开发测试阶段尤其方便，几秒就能起一个带数据的实例。
不过要注意数据持久化的问题。容器一旦删了，里面的数据默认就没了。所以跑数据库的时候一定要挂载外部卷：
docker run -d --name mysql-db -e MYSQL_ROOT_PASSWORD=123456 -v /my/data:/var/lib/mysql mysql:8.0这样即使容器重建，数据还在宿主机上留着。
微服务是Docker的主场
现在公司搞微服务架构，每个功能模块独立部署，Docker几乎是标配。订单服务、用户服务、支付服务各自打成镜像，用Docker Compose或者Kubernetes管理，互相隔离又协同工作。
比如一个docker-compose.yml文件就能定义多个服务：
version: '3'
services:
web:
build: ./web
ports:
- "8000:8000"
redis:
image: redis
db:
image: postgres
environment:
POSTGRES_DB: myapp一键启动整套环境，省得一个个手动配置。
CI/CD流水线里的常客
很多团队的自动化构建任务也是基于Docker做的。Jenkins、GitLab CI这些工具可以直接在容器里跑测试、编译代码、生成产物。环境干净一致，不会因为某台机器装了奇怪的依赖导致构建失败。
你本地改完代码，推到仓库，自动触发构建，跑完测试再推送到生产镜像仓库，整个过程容器全程参与。
不适合跑什么？
图形界面-heavy的应用就不合适了，比如Photoshop这种。虽然技术上可以跑，但需要复杂配置，体验很差。还有对性能要求极高的计算任务，比如高频交易系统，容器的网络和I/O开销可能成为瓶颈。
另外，单体大型应用如果没做拆分，硬塞进一个大容器里，维护起来反而更麻烦，失去了轻量灵活的优势。
说白了，Docker最适合那些需要快速部署、环境一致、可复制性强的应用。小到一个API接口，大到整套微服务集群，只要设计得当，它都能扛得住。