Ubuntu安装后初始化、SSH配置与Docker部署实战

装 Ubuntu 这件事，第一次做的人大多会卡在同一个地方：安装界面能走过去，重启之后就不知道下一步干什么了。真正让人头疼的从来不是那十几个安装步骤，而是装完之后的第一天——网卡没驱动、SSH 连不上、apt 更新卡在 0%、Python 版本对不上、服务起了又挂、日志在哪都找不到。这些问题在教程里往往被一句“安装完成”带过，但它们才是决定你能不能把这台机器用起来的关键。

所以这篇文章不会只给你一份安装向导。我把内容拆成三段：先把系统和分区装对，再把一台裸机配置成能远程管理的生产可用环境，最后用一个真实的 Python 服务加上 Docker 容器化，把“装完到跑起来”这条路完整走一遍。中间穿插的就是那些教程里不写、但你会遇到的具体报错和排查路径。

我的判断是：Ubuntu 的安装门槛已经很低，真正拉开差距的是初始化的规范程度。同样一台机器，有人装完就能当开发服务器长期用，有人装完三天就要重装，区别全在第 5 章那些看起来琐碎的配置上。如果你正在准备一台开发机、虚拟机、云服务器，或者打算把旧笔记本改造成常开的小服务器，下面的流程可以直接照着做。

1. 为什么 Ubuntu 值得认真学一遍

先说清楚一个现实：绝大多数后端服务、CI 流水线、容器镜像的最终运行环境都是 Linux，而 Ubuntu 是其中出现频率最高的发行版之一。这意味着你在 Windows 或者 macOS 上写代码时觉得“没问题”的东西，到了服务器上可能完全是另一回事——路径大小写敏感、换行符差异、文件权限模型、时区设置、环境变量加载顺序，任何一项没处理好，都会变成线上那个“本地明明能跑”的经典事故。

第二个现实是工具链。Docker、Kubernetes、绝大多数开源中间件的官方文档，默认示例环境都是 Ubuntu 或 Debian 系。你用 Ubuntu 学这些东西，遇到的坑最少，搜到的答案最多，社区里贴出来的报错信息也最容易和你自己的对上。这不是技术优劣问题，纯粹是生态惯性，但对学习者来说，惯性就是效率。

第三个现实是成本。一台旧笔记本、一台闲置的小主机、一个几百块的单板计算机，装上 Ubuntu Server 就能变成 7×24 小时的开发服务器、内网 Git 仓库、定时任务机、家庭 NAS 前端。这种“把闲置硬件变成基础设施”的能力，是很多开发者真正缺的一环，而它对入门的要求其实很低。

需要提前说明的是，这篇文章的读者画像是这样的：你会用命令行，但不熟；你装过软件，但没配过服务；你知道 sudo 是提权，但说不清 /etc 和 /usr/local 的区别。如果你已经是常年维护 Linux 服务器的运维，下面的内容对你来说会偏基础，但第 6、7 章的服务托管和容器化部分仍然值得扫一眼，里面有几个容易忽略的细节。

2. Ubuntu 版本选择与核心概念

2.1 LTS 版本和普通版本怎么选

Ubuntu 的版本号是「年份.月份」的格式，比如 22.04 就是 2022 年 4 月发布。所有 .04 结尾的偶数年份版本是 LTS（Long Term Support，长期支持版），桌面版支持 3 年、服务器版支持 5 年，可以付费延长。夹在中间的 .10 版本是过渡版本，支持周期只有 9 个月。

对绝大多数人来说，答案很明确：选 LTS。原因不是 LTS 更“稳”，而是它的软件源、驱动、第三方仓库的适配都是最充分的。你随便搜一个问题，答案默认都是针对 LTS 版本的；你随便装一个第三方软件，它给出的安装命令也大概率是按 LTS 的代号写的。用过渡版本会遇到大量“文档对不上”的情况，而这些情况对你学习 Linux 本身没有任何帮助。

当前的 LTS 版本中，22.04（代号 jammy）和 24.04（代号 noble）是主力。22.04 生态最成熟，几乎所有教程和第三方源都覆盖到了；24.04 更新一些，默认软件版本更高，但个别老旧工具可能还没跟上。如果你不确定，选 22.04 的踩坑概率最低；如果你要用比较新的语言运行时或者想少折腾版本升级，选 24.04。具体的版本号和支持周期请以 Ubuntu 官方发布页面为准，这里不做精确断言。

2.2 桌面版和服务器版的真实差别

很多人以为这两个版本只是“有没有图形界面”的区别，实际差别比这大。Desktop 版默认安装 GNOME 桌面、显示管理器、音频栈、一堆办公和浏览器软件，开机启动的服务多、内存占用高；Server 版默认没有图形界面，装完就是一个纯命令行环境，占用极小。

但更关键的是安装器不同。Desktop 版用的是一个图形化的安装器，分区选项相对简化；Server 版用的是基于文本的安装器（新版叫 Subiquity），分区、网络、SSH、存储布局这些选项暴露得更完整，也更适合脚本化。

实际选择建议是：如果你要在这台机器上写代码、看浏览器、用 IDE，装 Desktop；如果这台机器只负责跑服务、你通过 SSH 远程操作，装 Server。还有一种常见做法是在 Desktop 版上装完再关掉图形界面，我不太推荐——那等于白白背了一堆用不上的依赖，还会在系统更新时引入额外的变量。

2.3 目录结构和权限模型

在动手之前，先把几个最常打交道的目录搞清楚，后面所有的配置都会落在这里：

权限方面只需要记住三条规则：Linux 里一切皆文件，文件有三组权限（属主、属组、其他人），每组有读（r）、写（w）、执行（x）三种。chmod 755 意味着属主可读写执行、其他人可读可执行；chmod 600 意味着只有属主能读写，后面配置 SSH 私钥时会用到。

还有一个新手常踩的坑：sudo 不是“切换到 root”，而是“以 root 身份执行这一条命令”。它不会改变你当前 shell 的身份，所以 sudo cd /root 这种写法是无效的，因为 cd 是 shell 内建命令，sudo 找不到对应的可执行文件。

3. 安装前的环境准备与分区规划

3.1 硬件与虚拟化准备

如果装虚拟机，先确认宿主机开了硬件虚拟化。Windows 上打开任务管理器 → 性能 → CPU，看有没有“虚拟化：已启用”；如果没有，需要进 BIOS 打开 VT-x 或 AMD-V。这一步不做，虚拟机软件会报错或者跑得极慢。

虚拟机配置建议：内存至少 4GB（跑 Docker 建议 8GB），CPU 给 2 核，磁盘 40GB 起。磁盘类型选动态分配，不要预分配，这样实际占用会随使用增长。网络模式选 NAT 就能上网，如果需要宿主机之外的设备访问这台虚拟机，再考虑桥接模式。

如果装物理机，需要确认两件事：一是网卡和无线网卡型号是否被内核支持（近几年的主流硬件基本没问题，老旧或特别新的网卡可能需要在安装后额外装驱动）；二是如果机器预装了 Windows，需要先处理 BitLocker 和快速启动——加密状态下改分区会导致 Windows 无法启动，这是双系统用户最常见的翻车点。

3.2 安装介质制作

物理机安装需要一个 U 盘启动盘。官方推荐的写盘工具在 Windows 上是 Rufus，在 macOS/Linux 上可以用 dd。Rufus 写入时有一个选项要注意：分区类型选 GPT（对应 UEFI 启动），目标系统选 UEFI（非 CSM）。如果选错，装完之后会出现启动项里看不到 Ubuntu 的情况。

用 dd 写盘的话命令是这样，注意 of= 后面的设备名一定要确认清楚，写错盘会直接毁掉那块盘上的数据：

bash复制# 查看当前所有磁盘，确认 U 盘对应的设备名（如 /dev/sdb）
lsblk

# 卸载 U 盘的所有分区
sudo umount /dev/sdb*

# 写入镜像，if 是镜像路径，of 是 U 盘设备（不要带数字后缀）
sudo dd if=~/Downloads/ubuntu-22.04-desktop-amd64.iso of=/dev/sdb bs=4M status=progress oflag=sync

bs=4M 是块大小，status=progress 显示进度，oflag=sync 确保数据刷到设备再返回。这几个参数不加也能写，但你会等很久且看不到任何反馈。

3.3 分区方案怎么定

这是安装过程中最容易犹豫的一步。先明确一个前提：如果是整盘安装、不保留其他系统，直接用安装器的“清除整个磁盘”选项就好，它会自动分出一个 EFI 分区和一个根分区，够用且不会出错。只有当你要双系统、或者想给不同目录独立空间时，才需要手动分区。

手动分区的推荐方案：

把 /home 独立出来的价值在重装时会体现得非常明显：系统崩了、要换发行版、要升级大版本，只要不格式化 /home，你的代码、配置、浏览器数据全都还在。这是一个几乎零成本、收益极高的习惯。

如果内存足够（16GB 以上）且不需要休眠，可以不用 swap 分区，改用一个 swap 文件，后续调整大小更灵活：

bash复制# 创建一个 4GB 的 swap 文件
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 写入 fstab，保证重启后自动挂载
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# 验证
free -h

chmod 600 这一步不能省，权限不对的话 mkswap 会直接拒绝执行，因为 swap 文件里可能有内存残留数据。

3.4 双系统的三个前置检查

如果你要在已有 Windows 的机器上装双系统，这三件事必须先做，顺序不能乱：

第一，关闭 Windows 的快速启动。这个功能会让 Windows 关机时不完全释放文件系统，Ubuntu 挂载 NTFS 分区时会报“分区未干净卸载”的错误，只读不写。

第二，处理 BitLocker。如果 Windows 盘启用了设备加密，先在 Windows 里暂停或关闭它，装完 Ubuntu 再决定是否恢复。装了 Ubuntu 之后修改引导会影响 BitLocker 的度量值，可能导致要求输入恢复密钥。

第三，检查磁盘控制器模式。部分笔记本默认使用 Intel RST（RAID）模式，这种模式下 Linux 安装器看不到硬盘。需要在 BIOS 里改成 AHCI，但直接改会导致 Windows 无法启动，正确做法是先在 Windows 里用安全模式引导一次完成驱动切换，再改 BIOS 设置。

4. 系统安装完整流程拆解

4.1 虚拟机安装的简化路径

虚拟机的流程比物理机简单很多，因为分区和引导都由虚拟化层兜底。以 VirtualBox 为例，新建虚拟机时选择 Linux → Ubuntu (64-bit)，内存 4GB 以上，磁盘 40GB 动态分配。挂载 ISO 后启动，安装器会自动识别整块虚拟磁盘。

在安装类型那一步，选择“清除整个磁盘并安装 Ubuntu”是最省事的。如果虚拟机只用来做实验，不需要考虑保留数据，这是最优解。文件系统用默认的 ext4 就行，LVM 在虚拟机里没什么必要，反而会增加排查复杂度。

安装过程中会要求设置用户名和密码。这里的用户名建议用全小写、不含特殊字符的短名字，比如 dev、ops，因为后面 SSH、Docker 组、家目录路径都会用到它，带大写字母或空格会在某些工具里引发诡异问题。

4.2 物理机安装的关键节点

物理机安装有几个节点需要停下来确认：

启动菜单。开机按 F2/F12/Del（不同品牌不同）进启动菜单，选择 U 盘设备。如果是 UEFI 模式启动，菜单里通常会显示“UEFI: 你的U盘名”，尽量选带 UEFI 前缀的那一项。

安装类型选择。双系统场景选“安装 Ubuntu，与 Windows Boot Manager 共存”，安装器会自动缩小 Windows 分区并创建 Ubuntu 分区。但这个自动方案给 Ubuntu 的空间通常偏小，如果你打算长期用，建议选“其他选项”手动分区，按第 3.3 节的方案来。

引导器安装位置。UEFI 系统上，引导器应该装到 EFI 分区（通常是 /dev/sda1 或 /dev/nvme0n1p1，类型为 EFI System Partition），而不是整块磁盘 /dev/sda。装错位置会导致开机直接进 Windows，看不到 Ubuntu。

时区。安装器会问你在哪个时区，这个设置会影响系统时间。双系统用户这里有一个已知问题：Ubuntu 默认把硬件时钟当 UTC，Windows 默认当本地时间，切换系统时时间会差 8 小时。解决方式是在 Ubuntu 里执行一条命令，让硬件时钟按本地时间走：

bash复制# 让 Linux 把硬件时钟当作本地时间（与 Windows 行为一致）
timedatectl set-local-rtc 1 --adjust-system-clock

# 查看当前时间状态
timedatectl status

反过来让 Windows 用 UTC 也可以，但需要改注册表，对普通用户来说改 Linux 这边更简单。

4.3 首次登录后的第一件事

装完重启，第一次登录后不要急着装软件，先做三件事确认系统状态：

bash复制# 1. 确认系统版本和内核
lsb_release -a
uname -r

# 2. 确认磁盘和分区挂载是否符合预期
df -h
lsblk

# 3. 确认网络和 DNS 是否正常
ip addr show
ping -c 3 mirrors.tuna.tsinghua.edu.cn

lsb_release -a 输出的 Codename 很关键，后面换源、加第三方仓库都要用到它。df -h 用来确认 /home 是不是独立分区、swap 有没有生效。ping 用来确认 DNS 解析和外网连通性，如果这一步失败，后面的 apt update 一定失败，先解决网络再往下走。

5. 系统初始化与基础配置实战

这一章是本文的重点。同样的安装流程，做完这一章和没做，机器的可用性差距非常大。

5.1 换源与系统更新

官方源在国内访问速度经常很慢，apt update 卡在某个百分比不动是最常见的抱怨。换成本地镜像源可以显著改善。先备份原文件，再替换：

bash复制# 备份原始源文件
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%F)

# 以 Ubuntu 22.04 (jammy) 为例，替换为国内镜像源
sudo tee /etc/apt/sources.list > /dev/null <<'EOF'
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-security main restricted universe multiverse
EOF

# 更新软件索引并升级已安装的包
sudo apt update
sudo apt upgrade -y

这里有两个细节。第一，jammy 这个代号要换成你自己系统的代号，24.04 是 noble，20.04 是 focal，写错了 apt update 会直接报 404。第二，universe 和 multiverse 这两个组件不能漏，很多常用软件（比如 Docker 的一部分依赖、某些编解码库）都在里面，漏了会出现“明明包名对却装不上”的情况。

另外，24.04 开始默认使用 deb822 格式的源配置，文件位置变成了 /etc/apt/sources.list.d/ubuntu.sources，格式也和上面不同。新版系统上不要去改 sources.list，改那个文件是无效的，先 ls /etc/apt/sources.list.d/ 看一下实际文件再动手。

5.2 用户、权限与 sudo 配置

安装器创建的第一个用户默认就在 sudo 组里，可以提权。但直接拿这个账号跑所有东西不是好习惯。更规范的做法是：日常操作用普通账号，需要提权时用 sudo，服务运行用独立的系统账号。

bash复制# 创建一个日常使用的普通用户
sudo adduser dev

# 加入 sudo 组，允许提权
sudo usermod -aG sudo dev

# 验证该用户是否能提权
su - dev -c 'sudo whoami'

最后一条命令输出 root 就说明配置成功。如果输出的是权限被拒绝的提示，检查 /etc/sudoers 里 %sudo 那一行是否被注释掉了。注意，改 sudoers 一定要用 sudo visudo，它会在保存时做语法检查；直接用编辑器改，一旦写错语法，整个系统的 sudo 都会失效，那时候只能进恢复模式救。

服务专用账号则不应该能登录，也不应该有家目录：

bash复制# 创建系统账号，-r 表示系统用户，-s 指定不可登录的 shell
sudo useradd -r -s /usr/sbin/nologin -d /opt/myapp myapp

/usr/sbin/nologin 是关键，它让这个账号无法通过 SSH 或 su 登录，即使密码泄露也不会成为入口。这是最小权限原则在账号层面的落地。

5.3 SSH 服务配置

服务器版安装时可以勾选安装 OpenSSH Server。桌面版默认没装，需要手动装：

bash复制sudo apt install -y openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh --no-pager

status 输出里看到 active (running) 就说明服务起来了。如果显示 failed，先看日志：sudo journalctl -u ssh -n 50 --no-pager，最常见的原因是配置文件语法错误或 22 端口被占用。

接下来做两件事提升安全性。第一，禁用 root 直接登录和密码登录，改用密钥认证：

bash复制# 在客户端生成密钥对（如果还没有）
ssh-keygen -t ed25519 -C "dev@laptop"

# 把公钥上传到服务器
ssh-copy-id dev@192.168.1.100

第二，编辑服务器上的 /etc/ssh/sshd_config，修改这几项：

ini复制# 文件路径：/etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

改完必须重启服务才生效：sudo systemctl restart ssh。这里有个操作顺序的坑：一定要在确认密钥登录已经可用之后再关密码登录，否则你重启完服务就把自己锁在外面了。稳妥的做法是保留当前已连接的会话不要断开，新开一个终端测试密钥登录成功，再去改配置。

5.4 时间同步、防火墙与基础工具

时间不准会导致日志时间错乱、HTTPS 证书校验失败、分布式任务调度异常，属于典型的“小配置引发大问题”。Ubuntu 默认用 systemd-timesyncd，检查一下状态即可：

bash复制timedatectl status
# 关注 System clock synchronized 是否为 yes

防火墙 Ubuntu 上默认用 ufw，它比直接写 iptables 规则友好得多：

bash复制# 先放行 SSH，再启用防火墙，顺序不能反
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 启用
sudo ufw enable

# 查看规则和状态
sudo ufw status verbose

ufw enable 之后如果没有放行 SSH 端口，当前连接虽然不会立刻断开，但下次就连不上了——这是新手最常见的自锁操作，务必按上面的顺序执行。

最后装一组日常必备工具：

bash复制sudo apt install -y build-essential curl wget git vim htop net-tools \
                    unzip tree jq ca-certificates gnupg lsb-release

build-essential 提供 gcc、make 这些编译工具，装 Python 包或者编译任何源码都需要它；ca-certificates 少了会导致 curl 报证书错误；gnupg 是后面加第三方 apt 仓库时要用的。这些包一次装完，能省掉后面十几次“命令找不到”的排查。

6. 完整实战：用 systemd 和 Nginx 部署一个 Python 服务

前面的配置都是铺垫，这一章把它变成一个真正能对外提供服务的环境。选 Python 是因为它的部署流程最短，能把注意力集中在“服务托管”这件事本身。

6.1 项目结构设计

先规划目录。生产环境的代码和数据要分开，代码放 /opt，数据放 /var/lib，配置放 /etc：

bash复制sudo mkdir -p /opt/myapp
sudo mkdir -p /var/lib/myapp/data
sudo chown -R myapp:myapp /opt/myapp /var/lib/myapp

目录归属要设成服务账号，不然后面应用写日志、写数据文件会因为权限不足失败。这个错误的表现通常是一句 Permission denied 的堆栈，新手容易误以为是代码问题，实际上就是目录归属不对。

6.2 应用代码与虚拟环境

写一个最小可用的服务，用 Flask 演示，同时提供一个健康检查接口用于后面验证：

python复制# 文件路径：/opt/myapp/app.py
import os
import time
from flask import Flask, jsonify

app = Flask(__name__)
START_TIME = time.time()


@app.get("/")
def index():
    return jsonify({
        "service": "myapp",
        "message": "hello from ubuntu",
    })


@app.get("/healthz")
def healthz():
    return jsonify({
        "status": "ok",
        "uptime": round(time.time() - START_TIME, 2),
    })


if __name__ == "__main__":
    port = int(os.environ.get("APP_PORT", "8000"))
    app.run(host="0.0.0.0", port=port)

注意 host="0.0.0.0"，如果写成默认的 127.0.0.1，Nginx 反向代理过来会连不上，表现是 502 Bad Gateway，而 curl localhost:8000 又完全正常，这个现象很容易让人困惑。

然后用虚拟环境装依赖。系统 Python 不要直接 pip 装包，很多发行版已经禁止这种操作（会报 externally-managed-environment）：

bash复制# 创建虚拟环境
sudo -u myapp python3 -m venv /opt/myapp/venv

# 安装依赖
sudo -u myapp /opt/myapp/venv/bin/pip install --upgrade pip
sudo -u myapp /opt/myapp/venv/bin/pip install flask gunicorn

# 验证
sudo -u myapp /opt/myapp/venv/bin/python -c "import flask; print(flask.__version__)"

生产环境不要用 flask run 或者 app.run() 直接对外，应该用 gunicorn 这类 WSGI 服务器：

bash复制# 手动测试 gunicorn 能否启动
sudo -u myapp /opt/myapp/venv/bin/gunicorn \
    --workers 2 \
    --bind 127.0.0.1:8000 \
    --chdir /opt/myapp \
    app:app

--workers 一般设为 CPU 核数的 2 倍加 1，--bind 绑到 127.0.0.1 是因为对外暴露的工作交给 Nginx，应用本身不需要监听公网。测试通了之后 Ctrl+C 停掉，接下来交给 systemd 托管。

6.3 用 systemd 托管服务

手敲命令启动的服务，终端一关就没了，异常退出也不会自动重启。systemd 解决的就是这个问题。创建单元文件：

ini复制# 文件路径：/etc/systemd/system/myapp.service
[Unit]
Description=MyApp Flask Service
After=network.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
Environment="APP_PORT=8000"
Environment="PYTHONUNBUFFERED=1"
ExecStart=/opt/myapp/venv/bin/gunicorn --workers 2 --bind 127.0.0.1:8000 app:app
Restart=always
RestartSec=5

# 安全加固
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

几个关键项要解释一下。After=network.target 保证网络就绪后再启动，但如果你依赖的是数据库这类外部服务，需要改成 After=network-online.target 并加上 Wants=network-online.target。Restart=always 是服务能“自愈”的原因，进程崩溃后 5 秒自动拉起。PYTHONUNBUFFERED=1 让 Python 的输出不缓冲，否则你在 journalctl 里看到的日志会延迟很久才出现，排查时非常误导人。

ProtectSystem=full 这一组是 systemd 提供的沙箱选项，它让 /usr 和 /boot 对服务只读，/home 完全不可见。成本几乎为零，但能挡住相当一部分被利用后的横向移动。这类配置不是可选项，属于该有的默认值。

加载并启动：

bash复制# 重新加载 systemd 配置
sudo systemctl daemon-reload

# 设置开机自启并立即启动
sudo systemctl enable --now myapp

# 查看状态
sudo systemctl status myapp --no-pager

# 实时看日志
sudo journalctl -u myapp -f

daemon-reload 这一步在每次修改 unit 文件后都必须执行，否则 systemd 读的还是旧配置，你会陷入“明明改了没生效”的循环。

6.4 Nginx 反向代理

应用监听在 127.0.0.1:8000，外界访问不到，需要 Nginx 做代理和静态资源处理：

bash复制sudo apt install -y nginx

nginx复制# 文件路径：/etc/nginx/sites-available/myapp
server {
    listen 80;
    server_name _;

    access_log /var/log/nginx/myapp_access.log;
    error_log  /var/log/nginx/myapp_error.log;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }

    location /healthz {
        proxy_pass http://127.0.0.1:8000/healthz;
        access_log off;
    }
}

启用站点并检查配置：

bash复制# 建立软链接启用站点，删掉默认站点避免冲突
sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp
sudo rm -f /etc/nginx/sites-enabled/default

# 检查配置语法，这一步必做
sudo nginx -t

# 语法通过后再重载
sudo systemctl reload nginx

nginx -t 是必须养成的习惯。直接 restart 一个配置有语法错误的 Nginx，结果是整个服务起不来，而如果本来就承载着其他业务，这一下就把线上打挂了。reload 比 restart 更平滑，它会启动新 worker 再优雅退出旧的。

7. Docker 环境搭建与容器化部署

服务能跑了，接着把环境容器化。容器化解决的是“换一台机器又要重配一遍环境”的问题，对个人项目来说，最直接的价值是：新机器上只需要装一个 Docker，剩下的全部由镜像保证一致。

7.1 安装 Docker Engine

不要用 apt install docker.io，那个版本通常比官方源旧不少。按官方方式加仓库安装：

bash复制# 安装前置依赖
sudo apt install -y ca-certificates curl gnupg

# 添加官方 GPG 密钥
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
    sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 添加软件源
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 安装
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

注意源里的 $(. /etc/os-release && echo "$VERSION_CODENAME") 会动态取当前系统的代号，这样写的好处是升级系统后不用改配置。硬编码 jammy 的话，将来升级到 24.04 就得记着回来改。

装完把当前用户加进 docker 组，这样不用每次敲 sudo：

bash复制sudo usermod -aG docker $USER
newgrp docker

# 验证
docker version
docker run --rm hello-world

docker 组的权限实际上等同于 root 权限，这一点要有清醒认识：加入这个组的用户可以通过挂载宿主机根目录等方式获得完整控制权。个人开发机无所谓，多人共用的机器上要谨慎授权。

7.2 用 Compose 编排服务

把第 6 章的应用容器化，顺便加一个 Redis 演示多服务编排：

yaml复制# 文件路径：/opt/myapp/docker-compose.yml
services:
  app:
    build: .
    container_name: myapp
    restart: unless-stopped
    environment:
      - APP_PORT=8000
      - REDIS_HOST=redis
    ports:
      - "127.0.0.1:8000:8000"
    depends_on:
      redis:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthz"]
      interval: 30s
      timeout: 5s
      retries: 3

  redis:
    image: redis:7-alpine
    container_name: myapp-redis
    restart: unless-stopped
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5

volumes:
  redis-data:

对应的 Dockerfile：

dockerfile复制# 文件路径：/opt/myapp/Dockerfile
FROM python:3.11-slim

WORKDIR /app

# 先拷贝依赖清单，利用镜像层缓存
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

RUN useradd -r -s /usr/sbin/nologin appuser
USER appuser

EXPOSE 8000
CMD ["gunicorn", "--workers", "2", "--bind", "0.0.0.0:8000", "app:app"]

这里有两个工程细节。第一，先 COPY requirements.txt 再 RUN pip install，最后才 COPY 源码，这样改代码不会导致依赖层缓存失效，构建速度快很多。第二，ports 写成 127.0.0.1:8000:8000 而不是 8000:8000，前者只绑定到回环地址，外部无法直接访问，必须经过 Nginx，这样安全边界是清晰的。

启动和验证：

bash复制cd /opt/myapp

# 构建并后台启动
docker compose up -d --build

# 查看容器状态
docker compose ps

# 查看日志
docker compose logs -f app

# 验证服务
curl -s http://127.0.0.1:8000/healthz | jq .

8. 运行结果与效果验证

部署完成之后，需要一套固定的验证顺序，把问题定位在最小范围内。推荐从下往上查：进程 → 端口 → 应用 → 代理 → 外部。

bash复制# 第一层：服务状态
sudo systemctl is-active myapp
sudo systemctl is-active nginx

# 第二层：端口监听情况
sudo ss -tlnp | grep -E '8000|80|443'

# 第三层：应用本身
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/healthz

# 第四层：经过 Nginx
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/healthz

# 第五层：从另一台机器访问
curl -s http://192.168.1.100/healthz

预期结果：第一层两个都是 active；第二层能看到 127.0.0.1:8000 和 0.0.0.0:80；第三、四层都返回 200；第五层能拿到 JSON。

如果第四层失败而第三层成功，问题一定在 Nginx 配置；如果第五层失败而第四层成功，问题在防火墙或网络层，先去 sudo ufw status 看 80 端口有没有放行。这种分层排除法能避免“到处乱改”的情况，也是排查任何服务的通用思路。

9. 常见问题与排查思路

下面是实际使用中频率最高的一批问题，按现象归类：

除了表格，再补三个经常被问到的场景。

第一个是“改完配置不生效”。Ubuntu 上几乎所有的系统级服务都走 systemd，改完配置必须 systemctl daemon-reload（unit 文件变了）或 systemctl restart 服务名（配置文件变了）。只改文件不重启，是最常见的无效操作。

第二个是“日志在哪”。systemd 托管的服务统一用 journalctl -u 服务名；Nginx 在 /var/log/nginx/；系统级内核和启动日志用 dmesg 或 journalctl -k。找日志的能力基本等于排错能力，这个习惯值得早点建立。

第三个是“磁盘莫名满了”。df -h 看到某个分区满了，但 du -sh 挨个目录算又对不上——这通常是文件被删了但进程还持有句柄。用 sudo lsof | grep deleted 能找到这类文件，重启对应进程就能释放空间。

10. 最佳实践与后续学习方向

把前面所有内容压缩成几条能长期受益的原则，这几条比任何单个命令都重要。

第一，系统盘和数据盘分开，/home 独立分区。这条建议的价值在第 3 次重装系统的时候会体现得淋漓尽致。同理，数据库的数据目录、Docker 的数据目录（/var/lib/docker）也尽量挂在独立分区上，避免镜像和日志把根分区撑爆导致整机不可用。

第二，所有服务都用 systemd 或容器托管，不要用 nohup、screen 这类方式跑长期服务。它们在你退出登录或者机器重启后就不管了，也没法自动拉起，更没法统一查日志。systemd unit 文件写一次，后面几十个服务都是同一个模式，这是可维护性的来源。

第三，配置改动前先备份，尤其涉及 /etc/ssh、/etc/fstab、/etc/sudoers 这三个文件。它们出问题的后果分别是连不上、开不了机、提不了权，都属于需要进恢复模式才能救的情况。备份的成本是一条 cp，不备份的成本是半小时以上的抢救。

第四，安全配置从第一天就做，不要想着“先跑通再加固”。密钥登录、禁用 root 登录、最小权限账号、防火墙白名单，这四件事加起来不到十分钟，但拖到后面往往会因为“怕影响业务”而永远不做。尤其是把机器暴露到公网的情况，密码爆破是全天候自动进行的，不存在“没人会盯上我这台小机器”。

第五，版本信息写进文档。系统版本、内核版本、Python 版本、Docker 版本，这些在出问题时是判断兼容性的第一手依据。个人项目也建议在仓库里放一个 README 记下来，半年后回头看会感谢当时的自己。

接下来可以从这几个方向继续深入。一是 shell 脚本自动化，把第 5 章的初始化步骤写成一个 init.sh，新机器一条命令完成配置，这是从“会敲命令”到“会做工程”的分水岭。二是 Nginx 的 HTTPS 配置和证书自动续期，这是把服务真正对外提供的前提。三是 systemd 的 timer 替代 cron，做定时任务的日志和依赖管理更清晰。四是监控和告警，node_exporter 加 Prometheus 的组合足够覆盖个人项目的需求。

这套流程本身不复杂，复杂的是每一步背后的“为什么”。装系统只是入口，把这台机器变成你能信任、能远程管理、能长期运行服务的基础设施，才是这篇内容想讲清楚的东西。建议把第 5 章的配置和第 6 章的 systemd 单元文件保存下来，下次装机器时直接复用，省下的时间可以花在更有价值的事情上。