为什么要有Docker?

问题本质：你的代码/项目在你的电脑能跑，到测试环境就崩了，为什么？

原因：环境差异。你的电脑是python3.13，测试机是3.9；你的数据库是MySQL8.0,测试机是5.7；你装了某个依赖，测试机没装

Docker解决思路：不是只把代码搬到测试机，而是把你的整个电脑环境（代码+依赖+系统库+配置）打包成一个“集装箱”，测试机只需要能运行这个集装箱，里面不管装什么都一致。这就是docker的思路

容器 VS 虚拟机

对比项	虚拟机 (VMware/VirtualBox)	Docker 容器
本质	模拟一整套电脑（硬件+操作系统）	共享宿主机的操作系统内核，只隔离进程
启动速度	分钟级（要开机）	秒级（只是一个进程启动）
占用资源	几个 GB（完整操作系统）	几十 MB（只打包必要文件）
性能损耗	高（经过虚拟化层）	接近原生（直接跑在宿主机内核上）
测试场景	需要测不同操作系统兼容性	快速部署/销毁测试环境，隔离依赖

三个核心概念

Image 镜像

类似于一个打包好的安装包，装着程序和环境，而且只读不能改

Container 容器

镜像的运行实例，是镜像跑出来的样子。类似于一个安装包可以装出来很多个一样的软件。

基于一个镜像生成的容器相互隔离，互不影响。一个挂了之后其他的照样跑

Registry 仓库

类似于Docker世界的应用商店，最有名的是docker官方的Docker Hub

Nginx、MySQL这些镜像都可以直接从Docker下载来用

主线：仓库拉取镜像，再从镜像运行实例

镜像 VS 容器

镜像是只读的，容器是在镜像上加一个可写层。所以你在容器里改东西，既不影响镜像，也不影响别的容器

Docker命令

docker ps   只显示运行的容器

docker ps -a  含已停止的全部容器

docker images 查看镜像

容器的生命周期

docker run 创建并启动一个容器跑起来

docker stop  暂停运行的容器

docker start 启动容器

docker rm 删除容器

docker logs  程序出问题查看日志排错（docker logs -f mysql：实时跟踪查看mysql容器的日志）

docker exec -it 钻进正在运行的程序内部

端口映射 -p

假设我们用容器跑起了网站，服务监听在容器内部的80端口。但是在浏览器是打不开的。因为容器是隔离的，外面进不去

解决办法是端口映射，用-p参数给里外搭一条通道，例如：

docker run -p 8080:80 nginx

宿主机端口：容器端口

数据卷 -V

容器是用完即弃的，产生的数据都在容器的可写层里，一旦容器被删除，这些数据就一起消失了。数据库等数据怎么能说没就没？这可不行

解决办法是数据卷，核心思路是把重要数据存到容器外面去。

用-v操作把宿主机的一个目录挂在容器的内部路径上

宿主机目录 ：容器里的目录

自己构建镜像

Dockerfile

前面用的都是别人的镜像，那么自己的项目怎么写一个镜像？

答案是自己写一个Dockerfile，它就是一张打包说明书，一行一条指令

构建

docker build -t myapp .

讲dockerfile构建成真正的镜像 ，

-t给镜像起名字叫myapp 

.表示用当前目录构建

分层缓存

真实项目不会只有一个容器，还要配置数据库和缓存等等

手动的化还要一个一个docker run 太麻烦

docker-compose.yml就是为此而生

Compose 高频命令：

# 1. 启动所有服务（在 docker-compose.yml 所在目录执行）
docker-compose up -d
# -d = 后台运行（detach），不占用你的 CMD 窗口

# 2. 查看所有服务状态
docker-compose ps

# 3. 查看某个服务的日志
docker-compose logs -f litemall

# 4. 停止所有服务（保留容器，下次可以 docker-compose start 启动）
docker-compose stop

# 5. 停止并删除所有容器（数据卷保留，除非加了 -v）
docker-compose down

# 6. 停止并删除所有容器 + 数据卷（彻底清空，慎用！）
docker-compose down -v

# 7. 重启某个服务
docker-compose restart litemall

# 8. 重新构建镜像（如果你修改了 Dockerfile）
docker-compose build