Ubuntu零基础入门与Web服务部署实战：安装、命令、Nginx排错

很多人第一次接触 Linux，都是从 Ubuntu 开始的，它的名字常被读成“乌班图”，也是很多公司服务器和开发者笔记本上的默认系统。这篇文章把从镜像下载、虚拟机安装、系统初始化、常用命令到真实部署一个 Web 服务的完整链路串起来，零基础可以照着一步步做，有经验的开发者也可以直接跳到命令、部署和排错章节查阅。下面所有命令都在 Ubuntu 22.04 LTS 上实测过，24.04 的步骤基本一致，只有个别安装向导界面的文字差异，遇到不一致的地方按自己系统的提示操作即可。

1. Ubuntu 是什么：从概念到使用场景

1.1 Ubuntu 与 Linux 发行版的关系

Linux 严格来说只是一个内核，它负责管理 CPU、内存、磁盘、网络这些底层资源，但它本身并不提供我们日常使用的命令行工具、软件包管理器和桌面环境。把内核和一大堆上层软件打包在一起，就形成了“发行版”。Ubuntu 就是众多 Linux 发行版中的一个，它基于 Debian 发展而来，由 Canonical 公司主导维护，最大的特点是安装体验友好、软件源丰富、社区文档多。

对开发者来说，理解“发行版”这个概念很重要，因为它决定了你后续查资料的方向。同样是装一个软件，在 CentOS 上要用 yum 或 dnf，在 Ubuntu 上要用 apt；同样是配置文件，路径可能是 /etc/nginx/nginx.conf 而不是 /etc/nginx/conf/nginx.conf。很多新手照着某篇博客操作却报“命令找不到”，根本原因往往是发行版不匹配，而不是命令写错了。

1.2 桌面版与服务器版的区别

Ubuntu 官方提供两个主要形态：Desktop（桌面版）和 Server（服务器版）。桌面版带图形界面，预装了浏览器、办公套件、文件管理器，适合日常办公、学习和本地开发；服务器版没有图形界面，只提供命令行和 SSH 远程登录能力，占用资源少，稳定性更好，是部署线上服务的标准选择。

两者的内核和软件源是同一套，所以桌面版能装的软件服务器版基本都能装，只是服务器版默认不安装图形界面相关的包。如果你只是想在本地熟悉 Linux 操作，装桌面版更直观；如果你想模拟真实的生产环境，建议装服务器版，逼自己在纯命令行下完成任务，这个习惯对后续运维和排障能力的提升非常明显。

1.3 LTS 版本与支持周期该怎么选

Ubuntu 的版本号用“年份.月份”表示，比如 22.04 表示 2022 年 4 月发布。每两年会有一个 LTS（Long Term Support，长期支持）版本，LTS 版本提供更长的安全更新周期，适合生产环境；中间的普通版本支持周期较短，更适合尝鲜新特性。

选择建议很直接：生产环境和学习环境都优先选 LTS。你在网上看到的绝大多数教程、第三方软件包、Docker 镜像，都是围绕 LTS 版本适配的。如果你用的是非 LTS 版本，遇到依赖不兼容的概率会明显上升。本文以 Ubuntu 22.04 LTS 为例，如果你装的是 24.04 LTS，包管理器的部分配置文件格式有些变化，后文会专门说明。

1.4 哪些场景真的需要 Ubuntu

Ubuntu 在实际工作中的位置比很多人想象得更靠前。常见的场景包括：公司内网服务器和云主机，绝大多数云厂商都提供 Ubuntu 镜像；后端服务的运行环境，Java、Python、Node.js 的服务端程序基本都优先适配 Linux；容器与编排，Docker 在 Linux 上的表现远好于其他平台；数据与算法环境，很多机器学习框架的官方安装说明默认就是 Ubuntu。

掌握 Ubuntu 并不是要你成为运维专家，而是要具备三项能力：能独立装好一台可用的系统、能在命令行里完成日常操作、能把一个自己写的服务部署上去并保证它能长期运行。本文的章节安排就是围绕这三点展开的。

2. 安装前的环境准备

2.1 硬件资源与虚拟机方案选择

如果你打算把 Ubuntu 装成双系统或直接覆盖硬盘，务必先备份数据，并确认重要文件已经从目标分区转移出去。对大多数读者来说，更推荐先用虚拟机跑一遍全流程，熟悉之后再考虑物理机安装，这样即使分区选错，损失也只是重建一个虚拟机。

资源规划上，桌面版建议至少分配 2 核 CPU、4GB 内存、25GB 磁盘；服务器版可以降到 1 核、2GB 内存、20GB 磁盘。如果后续要在里面跑 Docker 和数据库，建议给到 4 核、8GB 内存、60GB 磁盘，否则很容易在构建镜像时因为磁盘不足而中断。虚拟机软件用 VirtualBox 或 VMware Workstation 都可以，操作逻辑大同小异，本文的步骤描述不绑定具体某一款。

2.2 镜像下载与完整性校验

镜像一定要从官方渠道获取，不要随便找网盘里的“优化版”。下载完成后建议做一次哈希校验，确认文件在传输过程中没有损坏，否则安装过程可能出现各种莫名其妙的报错，排查起来非常浪费时间。

bash复制# 下载完成后，在镜像所在目录执行，计算 SHA256 值
sha256sum ubuntu-22.04.4-desktop-amd64.iso

# 将输出结果与官方发布页给出的 SHA256 值逐字符比对
# 如果两者完全一致，说明镜像文件完整可用

校验通过之后再进行下一步。这一步看起来很琐碎，但在实际排障中价值很高：一旦安装中途报“无法读取介质”之类的错误，你至少能立刻排除镜像损坏这个变量。

2.3 制作启动 U 盘的关键注意事项

如果是物理机安装，需要把 ISO 写入 U 盘。这个动作会清空整个 U 盘的数据，所以先确认盘里没有需要保留的文件，并且一定要选对目标磁盘，别把移动硬盘或者系统盘当成 U 盘格式化掉。写盘工具用 Rufus、balenaEtcher 之类的都可以，写入模式选默认即可。

写完盘后，在目标机器的 BIOS 或 UEFI 里调整启动顺序，把 U 盘调到第一位。这一步经常被忽略，导致重启后还是进入原来的系统。另外注意 Secure Boot 选项：部分机器开启 Secure Boot 后，第三方驱动（尤其是显卡驱动）会有兼容提示，如果安装过程卡住，可以先在 BIOS 里临时关闭它，装完系统再按需处理。

2.4 分区规划的思路

分区是安装过程中最容易出问题的一步。简单起见，可以掌握两套方案。

第一种是“自动分区”，安装向导提供一个“清除整个磁盘并安装”的选项，适合虚拟机或整盘专用的机器，它会自动创建 EFI 分区、根分区和交换空间，新手最省心。

第二种是“手动分区”，适合需要保留其他系统或者对磁盘有规划的场景。一个够用的方案是：EFI 系统分区 512MB 到 1GB（FAT32 格式，类型选 EFI System Partition）、根分区 / 剩余空间的绝大部分（ext4）、交换空间 swap 根据内存大小给 2GB 到 8GB。如果要做服务器，还可以单独划分 /var 和 /home，这样日志暴涨或用户数据增长时，不会把根分区撑爆导致系统起不来。

3. Ubuntu 安装全过程拆解

3.1 虚拟机创建与虚拟磁盘设置

以虚拟机安装为例，新建虚拟机时选择“使用 ISO 映像”，指向刚才校验过的镜像文件。操作系统类型选 Linux，版本选 Ubuntu 64-bit。内存和 CPU 按前面说的规划给足，虚拟磁盘建议选“动态分配”，避免一上来就占满宿主机磁盘。

网络模式默认的 NAT 就够用，能访问外网即可。如果你希望宿主机之外的其他设备也能访问这台虚拟机（比如后面要测 Nginx 的访问），可以改成桥接模式，但要注意桥接后虚拟机会占用局域网 IP，某些公司网络环境下会有限制。

3.2 安装向导逐屏说明

启动虚拟机后，会依次经过几个界面，下面按顺序说明每一屏的作用和选择建议。

第一屏是语言选择，选“中文（简体）”或“English”都可以，但如果你的目标是服务器运维，建议直接选英文，因为绝大多数报错信息和日志都是英文的，中文界面下复制粘贴错误信息去搜索时反而会出问题。

第二屏是键盘布局，默认的 English (US) 一般没问题，如果输入字符和显示不一致，再改成 Chinese。

第三屏是网络配置，桌面版会尝试通过 DHCP 自动获取地址，正常情况下几秒就完成。如果卡在这一步，检查虚拟机的网络适配器是否已连接。

第四屏是安装类型，会出现“正常安装”和“最小安装”的选项，还会问是否下载更新、是否安装第三方驱动。虚拟机里可以取消“安装时下载更新”，因为这会显著拉长安装时间，装完系统再手动更新更可控。

第五屏是分区，按 2.4 节的方案处理。

第六屏是时区、用户名、密码、主机名设置。这里的用户名会成为你的登录账号，密码用于 sudo 提权，建议设置一个你自己能记住的强密码，不要用 123456，也不要用生日。主机名建议起一个有意义的名称，比如 dev-server-01，后续多机管理时能一眼区分。

之后就是复制文件的过程，通常需要 5 到 20 分钟，取决于磁盘和 CPU 性能。结束后会提示重启，重启前系统会要求移除安装介质。

3.3 首次登录与基础状态检查

第一次进入系统后，建议先做几项状态确认，把问题发现在最开始。

bash复制# 查看系统版本，确认装的是哪个 LTS
lsb_release -a

# 查看内核版本
uname -r

# 查看磁盘分区和挂载情况，确认根分区容量够用
df -h

# 查看内存使用情况
free -h

# 查看 IP 地址，SSH 连接时会用到
ip addr show

df -h 的输出要重点看 / 那一行，如果可用空间只剩几个 G，说明分区时给根分区留得太少，后续装 Docker 和大一点的依赖很容易撑爆。ip addr 的输出里找到 state UP 的网卡，看它拿到的 IPv4 地址，记下来备用。

3.4 快照与备份习惯

在虚拟机里，安装完成后立刻打一个快照，命名为“系统初始状态”。这个习惯能帮你省下大量重装时间：后面无论是改配置改坏了、装软件把依赖搞崩了，还是误删了系统文件，都可以在几十秒内回滚到一个干净可用的状态。

物理机上没有快照，但可以用 timeshift 这类工具做系统级备份，或者至少把重要的配置文件（/etc 下的内容）定期打包备份到外部存储。系统备份这件事的价值不在于“会不会用”，而在于“出事的时候有没有”，等真出问题时再想备份就已经晚了。

4. 安装后的基础配置

4.1 系统更新与软件源

新装的系统里的软件包通常不是最新的，第一件事就是更新索引并升级已安装的包。

bash复制# 更新软件包索引
sudo apt update

# 升级已安装的软件包（-y 表示自动确认）
sudo apt upgrade -y

# 可选：清理不再需要的依赖包，释放磁盘空间
sudo apt autoremove -y

执行 apt update 时如果看到 Could not resolve 或长时间卡住，通常是 DNS 或网络问题，而不是源配置错了。可以先 ping 一个域名确认网络是否通，再排查 /etc/resolv.conf 里的 DNS 设置。

4.2 更换镜像源的思路与操作

官方源在国内访问速度可能不理想，很多教程会建议换成国内镜像站。换源本身是常规操作，但要注意两点：一是必须先备份原文件，二是发行版代号必须对应正确，写错代号会导致 apt update 直接报 404。

bash复制# 备份原有的源配置文件
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

# 查看当前系统的发行版代号（22.04 是 jammy，24.04 是 noble）
lsb_release -cs

拿到代号之后，去你选定的镜像站官方说明页复制对应的配置内容，覆盖到 /etc/apt/sources.list 中，然后再次执行 sudo apt update 验证。这里不建议直接抄某篇博客里写死的地址，因为镜像站的域名、协议（http 或 https）和目录结构可能会调整，以镜像站当期说明为准最稳妥。

需要特别提醒的是，Ubuntu 24.04 开始，默认的源配置文件改成了 /etc/apt/sources.list.d/ubuntu.sources，使用的是新的 DEB822 格式，语法和旧的 sources.list 完全不同。如果你照着 22.04 的教程改 24.04 的源，会出现“配置被忽略”的现象。这时候用 apt modernize-sources 或者直接按镜像站提供的新格式文件覆盖即可。

4.3 中文环境与输入法配置

桌面版如果安装时选了中文，界面应该已经是中文了。如果没有，可以在“设置 - 区域与语言”里添加中文语言包并应用到整个系统。服务器版一般不需要中文界面，但如果你要处理中文文件名，建议至少确认 locale 配置正确。

bash复制# 查看当前语言环境
locale

# 安装中文语言包（桌面版常用）
sudo apt install -y language-pack-zh-hans

# 生成 UTF-8 编码的本地化配置
sudo locale-gen zh_CN.UTF-8

输入法方面，桌面版常用的是系统自带的 iBus 配合拼音引擎。安装后在“区域与语言 - 输入源”里添加“中文（智能拼音）”，然后用 Super + Space 切换。如果切换没反应，检查是否在输入源列表里真的添加成功了，很多人的问题是装完包但没添加输入源。

4.4 常用工具一次性装齐

刚装好的系统里很多常用工具都没有，一次性装好可以省去后面反复中断工作流。

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

这里逐个说明一下用途：vim 是命令行编辑器，改配置文件必备；curl 和 wget 用于下载文件和调接口；git 用于拉代码；net-tools 提供 ifconfig、netstat 这些老命令，虽然新系统推荐用 ip 和 ss，但很多脚本还在用老命令；htop 是比 top 更友好的进程查看工具；tree 用于查看目录结构；build-essential 包含 gcc、make 等编译工具链，装 Python 包或编译源码时经常需要。

4.5 开启 SSH 服务实现远程登录

服务器版默认就带 SSH 服务，桌面版需要手动安装。即使你只在本地用，装上 SSH 也有好处：可以从宿主机用终端连进去，复制粘贴命令比在虚拟机窗口里操作方便得多。

bash复制# 安装 SSH 服务端
sudo apt install -y openssh-server

# 查看服务状态
sudo systemctl status ssh

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

装好之后，在宿主机上执行 ssh 用户名@虚拟机IP 即可登录。第一次连接会提示确认主机指纹，输入 yes 继续，然后输入密码。

这里顺便说一个安全习惯：如果这台机器后面要暴露在不可信网络里，建议把密码登录关掉，改成密钥登录。修改 /etc/ssh/sshd_config 中的 PasswordAuthentication no 和 PermitRootLogin no，改完用 sudo systemctl restart ssh 生效。改之前一定要先确认密钥登录已经能用，否则可能把自己锁在门外。

4.6 用户与 sudo 权限管理

Ubuntu 默认禁止直接用 root 账号登录，日常操作通过 sudo 临时提权，这是一个很好的安全设计。安装时创建的第一个用户会自动加入 sudo 组，后续新建的用户需要手动加进去。

bash复制# 新建一个用户，并按提示设置密码
sudo adduser deploy

# 将用户加入 sudo 组，使其可以使用 sudo
sudo usermod -aG sudo deploy

# 查看某个用户所属的组
groups deploy

usermod -aG 中的 -a 非常重要，它表示“追加”，如果漏写就变成“覆盖”，会把用户原有的其他附加组全部清掉。这个细节在实际操作中坑过不少人，尤其是在给服务账号配权限的时候。

5. Ubuntu 常用命令实战

5.1 文件与目录操作

命令行操作的核心是路径和权限两个概念。先记住几个最常用的命令，然后通过组合完成实际任务。

bash复制# 查看当前所在目录的绝对路径
pwd

# 列出目录内容，-l 显示详情，-a 显示隐藏文件，-h 让大小更易读
ls -lah

# 创建多级目录，-p 表示父目录不存在时自动创建
mkdir -p /opt/myapp/logs

# 递归复制目录，-r 表示递归，-v 显示过程
cp -rv /opt/myapp /opt/myapp-backup

# 移动或重命名
mv /opt/myapp/logs/app.log /opt/myapp/logs/app.log.bak

# 删除文件（不可恢复，务必确认路径）
rm /opt/myapp/logs/app.log.bak

# 删除目录及其内容（危险操作，执行前先 ls 确认）
rm -rf /opt/myapp-backup

rm -rf 是 Linux 里最需要敬畏的命令之一，它不进入回收站，删掉就没了。一个实用技巧是：执行前先把命令里的 rm -rf 换成 ls，确认列出来的确实是你想删的东西，再改回去执行。这个习惯花不了几秒钟，但能避免绝大多数误删事故。

5.2 权限、属主与常见误区

Linux 的权限分三组：属主（user）、属组（group）、其他（other），每组有读（r=4）、写（w=2）、执行（x=1）三个位。理解数字表示法之后，看 chmod 755 这类命令就一目了然了。

bash复制# 查看文件权限
ls -l /opt/myapp/app.py
# 输出示例：-rw-r--r-- 1 root root 1024 Jan 1 10:00 app.py

# 755 表示属主可读写执行，属组和其他可读可执行
chmod 755 /opt/myapp/start.sh

# 644 表示属主可读写，其他只读，适合普通配置文件
chmod 644 /opt/myapp/config.ini

# 修改属主和属组
sudo chown -R www-data:www-data /var/www/mysite

一个高频误区是遇到权限报错就无脑 chmod 777。这确实能让报错消失，但等于把文件对所有用户开放写权限，在服务器上是明显的安全隐患。正确的做法是先搞清楚“哪个进程以哪个用户身份访问这个文件”，然后只给这个用户或用户组必要的权限。比如 Nginx 以 www-data 身份运行，那么站点目录的属主就应该是 www-data，而不是把权限开到 777。

5.3 进程、端口与服务管理

排查问题时，最常问的两个问题是“进程还在不在”和“端口有没有被占用”。

bash复制# 查看所有进程，配合 grep 过滤关键字
ps aux | grep python

# 用 htop 交互式查看，按 F9 可以结束进程
htop

# 查看端口占用情况，ss 是 netstat 的现代替代
sudo ss -tulnp

# 只看 8000 端口
sudo ss -tulnp | grep 8000

# 按进程名结束进程（先用 ps 确认 PID）
kill -15 12345

# 强制结束（仅在前面的方式无效时使用）
kill -9 12345

kill -15 发送的是 SIGTERM 信号，进程收到后可以做清理工作再退出；kill -9 是 SIGKILL，进程无法拦截，直接被杀。所以优先用 -15，只有在进程卡死时才用 -9，否则可能造成数据没来得及落盘。

服务管理统一用 systemctl：

bash复制# 查看服务状态
sudo systemctl status nginx

# 启动、停止、重启
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

# 重新加载配置而不中断服务（Nginx 等支持热加载的服务适用）
sudo systemctl reload nginx

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

# 查看服务最近 100 行日志
sudo journalctl -u nginx -n 100 --no-pager

5.4 软件包管理 apt 的正确用法

apt 是 Ubuntu 的核心包管理工具，围绕它有几个必须分清的命令：apt update 更新软件包索引（不升级软件），apt upgrade 升级已安装的软件，apt install 安装新包，apt search 搜索包。

bash复制# 搜索某个包（比如想找 Redis 相关的包）
apt search redis | head -20

# 查看包的信息和版本
apt show nginx

# 安装软件（-y 自动确认）
sudo apt install -y nginx

# 卸载软件，但保留配置文件
sudo apt remove -y nginx

# 彻底卸载，包括配置文件
sudo apt purge -y nginx

# 查看某个包安装了哪些文件
dpkg -L nginx

remove 和 purge 的区别在排障时很有用：如果你怀疑是残留配置导致了问题，用 purge 彻底清掉再重装，比反复改配置更省时间。另外，apt install 装完某个服务后，很多服务会自动启动，如果你只是想装个包而不想它占端口，可以先 systemctl stop 再决定要不要 disable。

5.5 磁盘、日志与系统信息

bash复制# 查看磁盘使用率，重点看 / 那一行
df -h

# 查看某个目录下各子目录占用的空间，按大小排序
sudo du -sh /var/* | sort -rh | head -10

# 查看系统运行时间和负载
uptime

# 查看系统日志最后 50 行
sudo journalctl -n 50 --no-pager

# 查看登录历史和失败记录
last | head -10
sudo lastb | head -10

磁盘占满是最常见的线上故障之一，而罪魁祸首通常是 /var/log 下的日志文件。上面那条 du -sh /var/* | sort -rh 能快速定位到具体是哪个目录在膨胀，配合 journalctl --vacuum-size=200M 可以把系统日志压缩到指定大小，属于应急处理的标准动作。

6. 开发环境搭建实战

6.1 Python 环境与虚拟环境隔离

Ubuntu 自带 Python，但不建议直接用系统 Python 装项目依赖，因为系统本身的一些工具依赖它的包版本。标准做法是使用 venv 创建独立的虚拟环境。

bash复制# 确认 Python 版本
python3 --version

# 安装 venv 和 pip（部分精简系统默认没有）
sudo apt install -y python3-venv python3-pip

# 创建虚拟环境
python3 -m venv /opt/myapp/venv

# 激活虚拟环境
source /opt/myapp/venv/bin/activate

# 确认 pip 指向的是虚拟环境内的版本
which pip

# 退出虚拟环境
deactivate

which pip 这一步值得养成习惯。如果输出的是 /usr/bin/pip 而不是 /opt/myapp/venv/bin/pip，说明虚拟环境没激活成功，这时候装包会污染系统环境，后面排查依赖冲突会非常痛苦。

6.2 Java 环境安装与版本切换

如果项目是 Spring Boot 后端的，需要装 JDK。Ubuntu 的源里有 OpenJDK 的多个版本，可以共存并通过 update-alternatives 切换。

bash复制# 查看可用的 JDK 版本
apt search openjdk | grep -E "^openjdk-(8|11|17|21)-jdk"

# 安装（以 17 为例，具体版本按项目要求调整）
sudo apt install -y openjdk-17-jdk

# 验证
java -version
javac -version

# 如果系统里有多个 JDK，列出并切换默认版本
sudo update-alternatives --config java

选择 JDK 版本时务必看项目的构建配置，Spring Boot 2.x 常用 JDK 8 或 11，3.x 要求 JDK 17 及以上。版本装错了，编译期可能还能过，运行期报 UnsupportedClassVersionError，报错信息里会直接写出“class file version 61.0”这类数字，对照 Java 版本表就能确认问题。

6.3 Docker 安装与基本验证

Docker 在 Ubuntu 上的安装有官方脚本和 apt 仓库两种方式。生产环境建议用 apt 仓库方式，便于版本控制和升级管理；本地学习用官方脚本更快。

bash复制# 方式一：官方仓库安装（推荐生产使用）
sudo apt install -y ca-certificates curl gnupg
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

安装完成后做两件事：把当前用户加入 docker 组，避免每条命令都要 sudo；验证 Docker 能正常拉取和运行镜像。

bash复制# 将当前用户加入 docker 组
sudo usermod -aG docker $USER

# 使组变更生效（也可以直接退出重新登录）
newgrp docker

# 验证 Docker 版本和运行状态
docker --version
docker info | head -20

# 跑一个测试容器验证功能
docker run --rm hello-world

docker run --rm hello-world 能正常输出欢迎信息，说明 Docker 的安装、守护进程、镜像拉取链路全部正常。如果这一步失败，问题基本集中在守护进程未启动（systemctl status docker）或者网络无法访问镜像仓库，按这两个方向查即可，不用去怀疑 Docker 本身装坏了。

6.4 Git 配置与代码拉取

bash复制# 配置全局用户名和邮箱（提交记录会用到）
git config --global user.name "your-name"
git config --global user.email "your-email@example.com"

# 查看配置是否生效
git config --list

# 拉取代码
cd /opt
git clone https://example.com/your-repo.git myapp

如果代码仓库是私有的，需要配置 SSH 密钥。用 ssh-keygen -t ed25519 -C "备注" 生成密钥对，然后把 ~/.ssh/id_ed25519.pub 的内容添加到代码平台的公钥设置里。注意私钥文件绝对不能泄露，也不建议把它复制到多台共享机器上。

7. 实战项目：部署一个 Flask 服务到生产可用

前面都是准备工作，这一节把零件组装起来，完整部署一个 Python Web 服务。技术选型是 Flask + Gunicorn + systemd + Nginx，这是 Ubuntu 上非常经典的一套组合：Gunicorn 负责多进程运行应用，systemd 负责进程守护和开机自启，Nginx 负责监听 80 端口并做反向代理。

7.1 项目目录结构

先把目录规划定下来，路径清晰后续维护成本会低很多。

text复制/opt/flask-demo/
├── app.py                 # 应用入口
├── requirements.txt       # 依赖清单
└── venv/                  # 虚拟环境（安装时创建）

/etc/systemd/system/flask-demo.service   # 服务单元文件
/etc/nginx/sites-available/flask-demo    # Nginx 站点配置

应用代码放在 /opt 下，服务配置交给 systemd，站点配置交给 Nginx，各司其职。不要把所有东西都塞在 /root 或用户主目录里，那不是服务器上的规范做法。

7.2 编写应用代码与依赖清单

python复制# 文件路径：/opt/flask-demo/app.py
from flask import Flask, jsonify, request
import datetime

app = Flask(__name__)


@app.get("/")
def index():
    """首页接口，返回服务基本信息。"""
    return jsonify({
        "service": "flask-demo",
        "status": "running",
        "time": datetime.datetime.now().isoformat()
    })


@app.get("/health")
def health():
    """健康检查接口，供 Nginx 或监控系统探测。"""
    return jsonify({"healthy": True})


@app.get("/echo")
def echo():
    """回显接口，用于验证反向代理是否正确透传参数。"""
    name = request.args.get("name", "guest")
    return jsonify({"message": f"hello, {name}"})


if __name__ == "__main__":
    # 仅用于本地调试，生产环境由 Gunicorn 启动
    app.run(host="127.0.0.1", port=8000, debug=True)

代码里用了 @app.get 这种装饰器写法，它要求 Flask 2.0 及以上版本。如果你的项目依赖 Flask 1.x，改成 @app.route("/", methods=["GET"]) 即可。保留一个 /health 接口是个好习惯，后面接监控、负载均衡健康检查都靠它。

text复制# 文件路径：/opt/flask-demo/requirements.txt
Flask>=2.2,<4.0
gunicorn>=21.0

依赖版本用范围约束而不是写死，既能避免拉到不兼容的大版本，又不会因为锁死小版本而错过安全修复。如果是生产项目，更严谨的做法是用 pip freeze 生成完整锁定文件。

7.3 创建虚拟环境并安装依赖

bash复制# 创建项目目录（如果还没有）
sudo mkdir -p /opt/flask-demo
sudo chown -R $USER:$USER /opt/flask-demo

# 进入目录并创建虚拟环境
cd /opt/flask-demo
python3 -m venv venv

# 激活并安装依赖
source venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

# 验证 Flask 是否可用
python -c "import flask; print(flask.__version__)"

# 本地快速验证应用能否启动
python app.py

最后启动后，另开一个终端执行 curl http://127.0.0.1:8000/health，如果返回 {"healthy": true}，说明应用本身没问题。确认后按 Ctrl + C 停掉，因为生产环境我们要交给 Gunicorn 启动，不能占用同一个端口。

7.4 用 systemd 托管服务

直接 python app.py 跑在后台是撑不住生产环境的：终端一关进程就没了，进程崩了也没人拉起来，服务器重启后更不会自动启动。systemd 解决的就是这三个问题。

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

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/flask-demo
Environment="PATH=/opt/flask-demo/venv/bin"
ExecStart=/opt/flask-demo/venv/bin/gunicorn \
    --workers 2 \
    --bind 127.0.0.1:8000 \
    --access-logfile - \
    --error-logfile - \
    app:app
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

逐项说明关键配置的含义。After=network.target 表示等网络就绪后再启动，避免服务启动时网络还没准备好。User 和 Group 指定运行身份为 www-data，用非 root 账号跑服务是基本的安全要求。WorkingDirectory 指定工作目录，否则相对路径会找不到。Environment 把虚拟环境的 bin 目录加进 PATH，保证 gunicorn 命令能被解析。ExecStart 里的 --workers 2 是工作进程数，经验值是 CPU 核数的 1 到 2 倍，--bind 127.0.0.1:8000 只监听本地，外部访问全部交给 Nginx。Restart=always 让进程异常退出后自动重启，RestartSec=3 是重启间隔。

配置写好后，先确认 www-data 用户对项目目录有读权限：

bash复制# 把项目目录的属主改成 www-data，保证服务账号能读取代码
sudo chown -R www-data:www-data /opt/flask-demo

# 重新加载 systemd 配置（新增或修改 unit 文件后必须执行）
sudo systemctl daemon-reload

# 启动服务并设置开机自启
sudo systemctl enable --now flask-demo

# 查看状态，确认是 active (running)
sudo systemctl status flask-demo --no-pager

# 查看实时日志
sudo journalctl -u flask-demo -f

sudo systemctl status 的输出里要重点看最后几行日志，如果出现 ModuleNotFoundError，说明依赖没装进虚拟环境；如果是 Permission denied，检查目录权限和属主；如果是 Address already in use，说明 8000 端口被别的进程占了，用 sudo ss -tulnp | grep 8000 找出来处理掉。

7.5 配置 Nginx 反向代理

bash复制# 安装 Nginx
sudo apt install -y nginx

# 确认服务已启动
sudo systemctl status nginx --no-pager

然后添加站点配置：

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

    # 访问日志和错误日志分开存放，便于按站点排查
    access_log /var/log/nginx/flask-demo.access.log;
    error_log  /var/log/nginx/flask-demo.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 10s;
        proxy_read_timeout 60s;
    }
}

这里几个 proxy_set_header 的作用值得说清楚：Host 让后端能拿到原始请求的域名，很多应用生成跳转链接时依赖它；X-Real-IP 和 X-Forwarded-For 用于传递真实客户端 IP，如果不设置，后端日志里看到的全是 127.0.0.1，排查谁在访问时会完全失去线索；X-Forwarded-Proto 传递原始协议，后端判断是否 HTTPS 时要用到。

启用站点并验证配置：

bash复制# 建立软链接启用站点
sudo ln -s /etc/nginx/sites-available/flask-demo /etc/nginx/sites-enabled/

# 删除默认站点，避免它抢占 80 端口
sudo rm -f /etc/nginx/sites-enabled/default

# 先检查配置语法，确认无误再重载
sudo nginx -t

# 重载配置
sudo systemctl reload nginx

sudo nginx -t 这一步非常关键。Nginx 的配置写错一个分号，直接 reload 会导致服务起不来；而 nginx -t 会先把语法错误指出来，包括行号，改起来非常快。所以任何 Nginx 配置改动，正确顺序永远是：改文件 → nginx -t → reload。

7.6 完整验证与日志排查

bash复制# 本机验证，返回 JSON 说明链路通了
curl http://127.0.0.1/

# 验证带参数的接口，确认代理透传正常
curl "http://127.0.0.1/echo?name=csdn"

# 从另一台机器验证（把 IP 换成目标服务器地址）
curl http://192.168.1.100/health

# 如果访问不通，按下面顺序排查
sudo systemctl status flask-demo --no-pager    # 后端服务是否在跑
sudo systemctl status nginx --no-pager         # Nginx 是否在跑
sudo ss -tulnp | grep -E "80|8000"             # 端口是否在监听
sudo tail -50 /var/log/nginx/flask-demo.error.log   # Nginx 错误日志
sudo journalctl -u flask-demo -n 50 --no-pager     # 后端应用日志

排障的核心思路是“从内到外逐层验证”：先确认后端进程活着，再确认端口在监听，再确认本机 curl 通，最后确认外部能访问。如果本机 curl 通但外部不通，问题在网络层或防火墙；如果本机 curl 都不通，问题在服务本身。这个分层思路比盲目改配置高效得多。

8. 常见问题与排查思路

下面这张表整理的是安装和使用 Ubuntu 过程中出现频率最高的问题，可以当作速查手册使用。

除了表格里的通用问题，还有几个值得单独展开的坑点。

第一个是 Permission denied 的误判。很多人看到权限报错第一反应是 chmod 777，但真正的原因可能完全不是权限位：比如 SELinux 或 AppArmor 的策略限制、目录的上级路径缺少 x 权限、或者服务运行用户根本没有访问该路径的能力。正确做法是用 namei -l /path/to/file 逐级检查路径权限，先确认是哪一层挡住的。

第二个是“改了配置但不生效”。Linux 上的服务大多有自己的配置加载时机，改完文件后必须显式重载或重启。而且要注意有些服务（比如 systemd）改了 unit 文件后需要 daemon-reload，只 restart 是不生效的。养成“改完就 reload，reload 前先检查语法”的习惯，能省掉大量“为什么没变化”的困惑。

第三个是时间不同步导致的各种诡异问题。比如 HTTPS 证书校验失败、日志时间戳错乱、分布式任务调度异常。检查 timedatectl status 里的时钟同步状态，如果显示未同步，执行 sudo systemctl restart systemd-timesyncd 重新同步。

9. 最佳实践与工程建议

9.1 安全基线：从装完系统就开始

安全不是上线前才考虑的事，从系统装完就该建立基线。核心原则是最小权限：能用普通用户完成的事，绝不用 root；服务能用专用账号跑，绝不用 root 跑；SSH 能关密码登录，就改成密钥登录。

bash复制# 查看当前登录用户和提权记录
who
sudo journalctl -u ssh --since "1 hour ago" --no-pager

# 检查系统有无可升级的安全补丁
sudo apt update && sudo apt list --upgradable

另外，防火墙建议至少做基础配置。Ubuntu 自带 ufw，启用前一定要先放行 SSH 端口，否则会把自己关在外面。

bash复制# 放行 SSH，这一步必须在 enable 之前做
sudo ufw allow 22/tcp

# 放行 HTTP 和 HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 启用防火墙
sudo ufw enable

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

9.2 备份、快照与变更管理

服务器上任何涉及删除、覆盖、修改系统配置的操作，都应该先备份。这条规则听起来很基础，但真正能坚持的人不多。一个实用的做法是给所有配置文件改动加上统一的备份后缀，并在文件名里带上时间戳。

bash复制#!/usr/bin/env bash
# 文件路径：/usr/local/bin/bak-conf.sh
# 用途：备份指定配置文件，生成带时间戳的副本
set -euo pipefail

if [ $# -lt 1 ]; then
    echo "用法: $0 <配置文件路径>"
    exit 1
fi

TARGET="$1"
if [ ! -f "$TARGET" ]; then
    echo "错误: 文件不存在 -> $TARGET"
    exit 1
fi

STAMP=$(date +%Y%m%d%H%M%S)
BACKUP="${TARGET}.${STAMP}.bak"
cp -p "$TARGET" "$BACKUP"
echo "已备份: $TARGET -> $BACKUP"

有了这个脚本，改 /etc/nginx/nginx.conf 之前先执行 sudo bak-conf.sh /etc/nginx/nginx.conf，出问题时直接改回备份文件即可。set -euo pipefail 这行的作用是让脚本在出错时立即退出、引用未定义变量时报错、管道中任一环节失败都算失败，是写 shell 脚本的推荐开头。

9.3 日志规范与可观测性

生产服务没有日志就等于没有眼睛。日志方面至少要保证三点：日志有地方落（文件或 journald）、日志有轮转（避免撑爆磁盘）、日志能定位（带上时间戳和请求标识）。

用 journald 的服务天然有轮转，只需要控制总量：

bash复制# 查看当前日志占用的磁盘空间
journalctl --disk-usage

# 将系统日志压缩到 200MB 以内
sudo journalctl --vacuum-size=200M

# 只保留最近 7 天的日志
sudo journalctl --vacuum-time=7d

用文件日志的服务则需要配 logrotate。Nginx 自带的轮转配置已经足够，自定义服务可以参照 /etc/logrotate.d/ 下的现有配置写一份，指定按天切割、保留份数、切割后是否压缩。

9.4 可维护性：让下一个人看得懂

工程实践里最容易被忽视的是可维护性。几条具体建议：所有自定义脚本开头写清楚用途、作者、参数说明；所有配置文件改动旁边加注释说明“为什么这么改”；部署步骤写成可执行的 shell 脚本或者文档，而不是只存在于某个人的记忆里。

目录结构也要有约定。应用放 /opt，数据放 /data 或 /var/lib，日志放 /var/log，配置放 /etc。不要出现“这个项目的代码在 /root/test2，日志在 /tmp，备份在某人桌面”这种局面。约定本身就是一种效率。

另外，命令历史也是排查问题的宝贵资料。可以在 ~/.bashrc 里加上记录时间戳的配置，这样回看历史时能知道每条命令是什么时候执行的，对复现问题很有帮助。

bash复制# 追加到 ~/.bashrc，让 history 显示执行时间
export HISTTIMEFORMAT="%F %T "
export HISTSIZE=5000
export HISTFILESIZE=10000

10. 继续深入的方向

走到这里，你已经具备了一台 Ubuntu 从零到跑起一个可访问服务的完整能力。接下来可以按三条线继续深入。

第一条是运维线：学习 systemd 的更多能力（定时任务 timer、资源限制 cgroup）、rsync 增量备份、cron 定时任务、日志分析和基础监控。这些是保证服务长期稳定运行的基础。

第二条是容器线：把第 7 节的 Flask 应用写成 Dockerfile，用 Docker Compose 编排应用和数据库，再用 Nginx 做入口。容器化的好处是环境一致性，一次构建处处运行，能显著减少“我本地是好的”这类问题。

第三条是安全线：HTTPS 证书配置、SSH 加固、防火墙策略细化、最小权限账号体系、定期漏洞扫描。这部分不产生直接功能，但决定了系统能扛住多少风险。

如果这篇文章帮你把环境跑通了，建议顺手做两件事：把本文里的部署流程整理成自己的脚本放到仓库里，下次换机器直接执行；给虚拟机或服务器打一个当前状态的快照，标记清楚这个状态是“可用的基线”。这两件小事在后续反复折腾的过程中，会一次次帮你把时间省回来。