SSH是什么？
SSH = Secure Shell（安全外壳）
- 本质： 一种网络协议
- 用途： 在不安全的网络环境中安全地访问远程计算机
- 类比： 就像给你的网络连接装了一个"加密隧道"
SSH的三大安全机制
1. 数据加密传输
2. 身份认证
方式一：密码认证（基础） 方式二：公钥认证（更安全，推荐）
3. 数据完整性保护
安全对比表
| 协议 | 数据加密 | 身份认证 | 完整性保护 | 安全性 |
|---|---|---|---|---|
| Telnet | ❌ 明文 | 密码（明文） | ❌ | ⭐ |
| FTP | ❌ 明文 | 用户名密码（明文） | ❌ | ⭐ |
| SSH | ✅ 加密 | 密码/公钥 | ✅ MAC | ⭐⭐⭐⭐⭐ |
为什么经常和HTTP/HTTPS一起提？
SSH、HTTP、HTTPS 都是网络传输协议，但它们的安全级别和使用场景不同。
核心原因：它们都是"传输协议"，但用途不同
详细对比
| 特性 | HTTP | HTTPS | SSH |
|---|---|---|---|
| 全称 | HyperText Transfer Protocol | HTTP Secure | Secure Shell |
| 用途 | 网页浏览 | 安全网页浏览 | 远程登录/文件传输 |
| 端口 | 80 | 443 | 22 |
| 加密 | ❌ | ✅ (SSL/TLS) | ✅ (SSH协议) |
| 典型场景 | 访问普通网站 | 网上银行、登录 | 服务器管理、Git |
| 用户感知 | 浏览器地址栏 | 浏览器显示锁图标 | 命令行工具 |
构建镜像 (打包你的系统) docker build -t xxx . 构建； 也可以使用 docker compose build - 构建 docker compose 文件。有什么区别吗？
| 特性 | docker build |
docker compose build |
|---|---|---|
| 作用范围 | 单个镜像 | 多个服务（根据 compose 文件） |
| 配置来源 | Dockerfile | docker-compose.yml + Dockerfile |
| 使用场景 | 构建单一应用镜像 | 构建多容器应用的所有镜像 |
| 底层原理 | 直接调用 Docker 引擎 | 内部调用 docker build |
| 灵活性 | 高（可指定任意参数） | 中（受 compose 文件约束） |
能不能不使用Dockerfile，直接用docker build？
答案：不能！ docker build 必须要有构建指令
服务器三种部署方式的比较
服务器是有一个docker，docker里面装了nginx和java服务镜像，每一个前端代码，都是本地打包之后直接把dist包放到服务器上的docker的nginx下面，Java服务每次也是本地打包之后直接把jar包放到服务器的docker的Java服务下面，服务器重启之后，不会重新run上一个版本的镜像了，因为nginx镜像只是用来启动前端服务的，但是Java服务为什么不会run docker里面的镜像？
| 维度 | 混合方式 | 完整Docker部署 |
|---|---|---|
| 镜像内容 | 只有Java环境（openjdk） | 包含应用代码（jar包） |
| jar包位置 | 宿主机 ./app/ 目录 | 镜像内部 /app/ 目录 |
| 重启行为 | 运行宿主机最新jar包 | 运行镜像中打包的jar包 |
| 版本管理 | 通过宿主机文件管理 | 通过镜像标签管理 |
| 回滚方式 | 替换宿主机jar包 | 切换镜像标签 |
| 存储占用 | 小（只存基础镜像） | 大（每个版本一个镜像） |
| 部署速度 | 快（秒级） | 慢（分钟级） |
| 环境一致性 | 依赖宿主机环境 | 完全一致 |
传统部署 没有docker，直接把前端、后端放到服务器上
完整Docker部署 是在服务器上部署一个docker，每次都把前后端都打包构建镜像，然后在服务器上拉取镜像，更新
混合方式 是在服务器上部署一个docker，在docker中部署nginx，每次把前端打包替换nginx中的文件，然后构建一个基础的Java8镜像，通过卷挂载的方式，每次将后端的代码打包替换app中的Jar包，然后容器就会更新，这样即使服务器重启，也不会导致镜像运行的容器变成了旧版本的容器。
| 维度 | 方式1：传统部署 | 方式2：完整Docker部署 | 方式3：混合方式 |
|---|---|---|---|
| 部署位置 | 服务器文件系统 | 新容器（基于新镜像） | 运行中的容器内部 |
| 部署速度 | 快（秒级） | 慢（分钟级） | 最快（秒级） |
| 学习成本 | 低 | 中 | 低 |
| 资源占用 | 少 | 多（镜像存储） | 中 |
| 环境一致性 | 差 | 最好 | 中 |
| 版本管理 | 困难 | 容易（镜像标签） | 困难 |
| 回滚能力 | 困难 | 容易 | 困难 |
| 容器重启 | 不适用 | 内容一致 | 可能丢失修改 |
| 符合Docker哲学 | 不适用 | ✅ | ❌ |
| 适合场景 | 小项目、稳定环境 | 生产环境、微服务 | 开发/测试环境 |
混合方式（使用volumes）：
宿主机: ./app/app.jar
容器: /usr/local/app/app.jar (挂载自宿主机)
docker restart container
容器重启后，
/usr/local/app/app.jar 仍然是宿主机的文件
修改不会丢失！
混合方式：
修改代码 → 打包jar → 替换宿主机jar → 重启容器
耗时：10-30秒
镜像：openjdk:8u111-jre
这个镜像永远不会改变（官方基础镜像）
只需要替换宿主机的jar包，镜像不需要更新
总结
1、这个ssh和https一样是一个协议，只不过https是ssl/tls加密,SSH 是SSH协议)；更安全了；
2、docker build -t xxx . 构建；与docker compose build - 构建 docker compose 文件区别就是docker build -t xxx . 适合单个服务构建；docker compose build 适合构建多个服务；
3、在一个新项目，没有存在的容器，没有现有镜像的情况下，必须要先docker build -t xxx . 或者docker compose build 构建镜像，然后docker build构建的时候，必须有Dockerfile；
4、只有一个免费docker账号，只能创建1个私有仓库，但是又不想让我的其他仓库变成公开的，所以要用完整Docker部署的方式，要么使用自建私有镜像仓库，要么使用其他免费私有仓库 ，比如阿里云、腾讯云、华为云，要么就是采用这种混合的方式，最方便并且不用付费。