企业官网建设流程全解析

如果你手头有一台Windows电脑，想学Linux服务器或者搭建一套Java Web运行环境，最常见的做法就是开一台虚拟机。我自己早年间在VMware里装CentOS，总被防火墙命令和包管理差异折腾得够呛，后来转换到Ubuntu Server反而顺利很多。这篇就把Ubuntu Server 22.04这条链路完整拆开：先看它和CentOS在真实使用中的差别，再讲VMware里的完整安装过程、SSH远程连接怎么配，最后把JDK和Tomcat装起来跑通。内容适合刚接触Linux服务器的同学，也适合原本用CentOS想对比一下Ubuntu的运维朋友，整个流程按顺序执行就能复现。

1. Ubuntu与CentOS的核心差异与选型参考

很多人纠结“到底学Ubuntu还是CentOS”，与其听别人说，不如先看清楚两者本质上的差异。这两者虽然都是Linux发行版，但血缘不同，导致包管理、默认防火墙、网络配置、内核更新节奏都有明显区别。

1.1 底层来源决定的第一层差异

Ubuntu源自Debian系，而CentOS基于企业级Linux发行版（RHEL系）的源代码重新编译。这个出身决定了它们的软件包生态完全不一样。最直接的感受是包管理命令：Ubuntu用apt和dpkg，CentOS传统上用yum，新版本用dnf。同样是装一个软件包，apt install和dnf install背后的依赖解析机制、软件包格式都不同。Ubuntu的软件源里很多包更新更快、分类更细，对开发者场景来说，会感觉“想要的东西基本一条apt就能搞定”。

CentOS的优势则在于稳定的企业基因，它长期跟踪RHEL的稳定性，软件包更新偏保守，一般不会出现太激进的版本跳变。这个特性在服务器场景是优点，但对需要新功能新特性的开发环境来说，有时候反而成了限制。

1.2 包管理、防火墙、网络配置等使用感受对比

我在实际操作中感知最明显的区别有这几个：

• 包管理器：Ubuntu用apt，CentOS 7用yum，CentOS 8及以上用dnf，语法上yum install xxx和dnf install xxx很像，但和apt install xxx完全是两套体系。
• 防火墙：CentOS默认使用firewalld，启动之后还要记得放行端口，新手经常在防火墙这里卡住；Ubuntu Server默认并不强制启用防火墙，有需要时可以用ufw，规则简洁很多。
• 网卡配置：CentOS传统上习惯改ifcfg文件或者用NetworkManager，Ubuntu Server用的是netplan，通过一个YAML文件管理网络，格式直观。
• 内核和软件更新速度：Ubuntu的内核更新和软件包升级更频繁，对新硬件兼容性更好；CentOS系整体更保守。
• 用户管理：CentOS里直接useradd再passwd设置密码，Ubuntu里用adduser向导式创建用户，后台逻辑略有不同，同样一个命令在两个系统上的体验是有差别的。

这几点不是谁绝对比谁好，而是使用习惯的差异。如果你习惯了改/etc/sysconfig/network-scripts/ifcfg-ens33，切到Ubuntu之后突然变成一个YAML文件，第一反应确实会不适应。

1.3 开发与运维场景下怎么选

我的判断标准很简单：如果是个人学习、新项目启动、跑Java/Python/Node.js这类应用，优先选Ubuntu Server LTS，因为操作顺手、软件源更新及时、社区资料丰富，遇到问题能搜到的方案多。如果是企业里已经有了一套成熟的RHEL系运维体系，自动化脚本都是基于yum写的，那就继续用CentOS系或者兼容RHEL的发行版，没必要因为盲目追新而迁移。

另外要提醒一点：从维护周期看，Ubuntu 22.04属于LTS版本，有明确的支持窗口，对服务器来说有保障。CentOS 7已经走完生命周期，继续用的话要注意源站和补丁更新的变化。所以不管是新装还是改造，我更倾向于把Ubuntu Server LTS作为新虚拟机的主要选择。

2. 在VMware Workstation里安装Ubuntu Server 22.04

安装这件事本身不难，但很多人在前几步就选错了选项，后面越走越别扭。这一部分把关键参数和安装选项逐个说清楚。

2.1 准备ISO镜像和创建虚拟机的关键参数

先去官方渠道下载Ubuntu Server 22.04的ISO镜像，注意别和桌面版混了。Server版采用的是安装向导式界面，没有图形桌面，后续运维都是命令行操作，这正是服务器该有的样子。

在VMware里新建虚拟机时，我建议选“自定义”，不要用“典型”。典型向导虽然方便，但有时会忽略内存、磁盘、网络等细节控制。主要参数可以参考以下范围：

• 操作系统类型选择Linux，版本选择Ubuntu 64位。
• 内存2GB起步，如果后面要跑Tomcat和多个服务，建议4GB。
• CPU至少2核，4核更舒服。
• 磁盘20GB是最低线，我给这台虚拟机分的是40GB，避免后期日志、应用包一多就捉襟见肘。
• 网络先保持NAT模式，等环境都部署好后，再根据实际需要改桥接。

这里有一个我踩过的坑：如果新建虚拟机时把操作系统版本选成了其他Linux版本，后面VMware的虚拟硬件兼容和驱动支持可能不匹配，网络和磁盘识别都可能出问题，所以这一项要看仔细。

2.2 安装流程中的关键选项其实只有几个

虚拟机开机后进入Ubuntu Server安装界面，你会发现它不是图形鼠标操作，而是基于文本的向导式界面。整个过程并不复杂，但有几个选项会影响后续。

语言我建议选择英文。不是中文不能用，而是服务器场景下英文环境能避免很多编码、路径和控制台显示问题，之后安装软件包也更顺利。键盘布局保持默认English即可。

网络配置这一步，虚拟机默认通过DHCP获取IP，一般直接就能拿到地址。如果你希望远程连接时IP地址固定不变，也可以在这一步手动配置静态IP。等以后SSH连接时，固定的地址会省去很多麻烦。

Ubuntu Archive镜像源会默认指向官方源，如果当前网络访问官方源速度不稳定，安装过程中就会一直卡在下载软件包那一步。这种情况可以手动切换到国内镜像站，一个常见做法是安装时选择镜像站地址，后续系统里的软件源也会指向它，apt update的速度会快很多。

磁盘分区直接选择使用整块磁盘并启用LVM。LVM是逻辑卷管理的思路，相当于把磁盘划分成可以随时调整的逻辑卷，之后空间不够不用重装系统，可以动态扩展。新手阶段不要手动进行分区，分区表、挂载点这些东西一时半会儿理不清，默认方案更安全。

接下来设置服务器名称和用户名密码。关键点是会有一个“Install OpenSSH server”的勾选项，这一步千万要勾上。如果漏掉了，安装完成后再手动补装也不是不行，但远不如这一步顺手，而且补装后还要额外处理服务启动和防火墙规则。

安装进度走完后会提示移除安装介质并重启，重启后进入命令行登录界面，输入用户名和密码即可进入系统。

2.3 网络模式选NAT还是桥接，直接决定后面SSH连法

在VMware里装Linux，很多人第一次SSH连不上，原因经常不是系统问题，而是网络模式没搞清。VMware提供了几种虚拟网络模式，其中我们常用的是NAT和桥接。

NAT模式下，虚拟机在宿主机内部的虚拟网段里，比如192.168.x.x。虚拟机可以通过宿主机共享的网络访问外网，但从局域网里的其他电脑看，虚拟机是不存在的，它们访问不到它。想在本机做实验，NAT完全够用，宿主机通过VMware的虚拟网卡就能跟虚拟机互通。

桥接模式下，虚拟机直接和宿主机接入同一个局域网，会从路由器或者上级DHCP获取一个独立的局域网IP。这种模式下，公司局域网或家里的其他设备都能直接访问虚拟机，适合部署演示或者需要多人访问的场景。

远程连接之前，先弄清楚这台虚拟机处于哪种网络模式，就不会在“为什么连不上”这件事上浪费太多时间。后续如果要从外部访问Tomcat页面，网络模式的选择非常关键。

3. 配置SSH远程连接Ubuntu服务器的完整步骤

Ubuntu Server装好后，接下来就是让宿主机可以远程操作它。这一步的最终目标是从Windows或者Mac终端登录到Ubuntu的命令行，之后敲命令就都在终端里完成了，再也不用盯着VMware的虚拟机窗口。

3.1 连接前先确认SSH服务和IP地址

如果安装时勾选了OpenSSH server，SSH服务默认已经装好并启动。可以先用下面的命令确认一下：

systemctl status ssh

如果状态显示active（running），SSH服务就没问题。如果没装也没关系，手动补救：

sudo apt update sudo apt install openssh-server -y sudo systemctl enable ssh sudo systemctl start ssh

确认服务之后，查看虚拟机当前IP地址。Ubuntu Server上默认没有ifconfig，所以用ip命令：

ip addr

更快捷的方式是：

hostname -I

这个命令会直接列出IP，比如192.168.150.128，后面SSH连接时用的就是这个地址。

3.2 宿主机执行SSH连接

以Windows为例，打开Windows Terminal或PowerShell，输入：

ssh 用户名@IP地址

第一次连接会出现主机指纹确认的提示，输入yes后回车，输入密码就进入远程终端了。这个主机指纹是为了防止中间人攻击，相当于对方把它的身份证明给你看一次，确认无误后记住。

如果你觉得纯命令行终端不够直观，也可以使用MobaXterm或Termius这类工具，它们在界面上提供了会话管理、文件传输等功能，用起来更省心。但底层都是SSH协议，原理并没有不同。可以简单理解为：SSH客户端和服务器之间先协商加密参数，建立一条加密隧道，之后的用户名密码和所有命令的数据都在这个隧道里传输，避免明文暴露在网络上。

如果SSH连接失败，别急着重装系统，按照下面的排查顺序处理。

3.3 SSH连不上的排查路径

我总结了一个实用的排查顺序：

• 先在宿主机ping虚拟机IP，如果ping不通，说明网络连通性有问题，重点检查VMware网络模式和虚拟网卡设置。
• 如果ping通但SSH端口连不上，检查SSH服务是否运行，命令是systemctl status ssh。
• 如果服务正常但还是连不上，检查虚拟机的防火墙状态，用sudo ufw status确认是否有规则阻断了22端口。
• 如果是桥接模式下连不上，检查局域网是否有多IP冲突，或者路由器是否开启了AP隔离。

还有一个比较隐蔽的情况：如果之前用NAT模式连过，后来切换到了桥接模式，IP地址会变化，SSH连接工具里保存的旧IP自然失效。所以建议虚拟机网络模式固定下来，不要频繁切换。

3.4 从密码登录升级到密钥登录

密码登录适合刚开始熟悉SSH时使用，但为了安全且方便，我更推荐换成密钥登录。整个过程是：宿主机本地生成一对密钥，公钥放到服务器上，私钥留在本地。登录时服务器用公钥验证客户端的私钥签名，验证通过后无需再输入密码。

在Windows上用命令生成密钥：

ssh-keygen -t ed25519

一路回车即可，默认会在用户目录下生成.ssh目录，里面有.pub结尾的即是公钥。然后复制公钥到服务器：

ssh-copy-id 用户名@IP地址

如果你的Windows终端没有这个命令，也可以把id_ed25519.pub文件内容手动追加到服务器上的~/.ssh/authorized_keys里，效果是一样的。

配置好密钥登录之后，日常操作只需要ssh 用户名@IP地址就能直接进入，比输密码高效很多。

4. 安装JDK与Tomcat，跑通第一个Java环境

远程连接已经正常，接下来就到了重头戏：把JDK和Tomcat装好，并让Tomcat成功跑起来。这套环境是很多Java Web应用的基础，后续部署war包就是往Tomcat的webapps目录里放文件这么简单。

4.1 我还是推荐用apt安装OpenJDK

在Ubuntu上安装JDK有几种方式，常见的有apt安装、从官网下载二进制包、用SDKMAN管理多个版本。如果目标是把环境快速跑起来，apt安装最省事。Ubuntu 22.04的软件源里自带OpenJDK 17，和当前Tomcat版本搭配也很合适。

执行更新和安装：

sudo apt update sudo apt install openjdk-17-jdk-headless -y

这里选择headless版本的原因是服务器没有图形界面，不需要那些和图形库相关的组件，headless版本体积更小、更干净。安装完成后验证：

java -version javac -version

能看到版本信息输出就说明JDK已经可用。

如果你有特殊原因要装特定版本的JDK，可以用官网提供的tar包解压安装，后续手动配置环境变量。但从维护角度看，apt安装的JDK由apk包管理器统一管理，升级方便，不会在系统里散落一堆解压目录。

4.2 配置JAVA_HOME环境变量

很多Java程序，尤其Tomcat，启动时会找JAVA_HOME环境变量。apt安装OpenJDK之后，java命令虽然可以直接运行，但JAVA_HOME往往没有被定义，所以需要手动配置。

先找到JDK实际安装路径：

readlink -f $(which java)

这个命令会把软链接一层层解析到真实的JDK目录，输出结果类似/usr/lib/jvm/java-17-openjdk-amd64。

然后创建环境变量配置文件：

sudo tee /etc/profile.d/java.sh > /dev/null <<EOF export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 export PATH=\$PATH:\$JAVA_HOME/bin EOF

之后让配置立即生效：

source /etc/profile.d/java.sh

放在/etc/profile.d/目录下的好处是，只要是这个系统上的用户，登录时都会自动加载这些变量，不用每个用户单独配。Linux环境变量这块的逻辑很简单：shell在启动时读取一系列配置文件，/etc/profile又会加载/etc/profile.d/下的所有脚本，所以只要往这个目录放脚本，重启后也不会丢。

4.3 下载Tomcat并用systemd托管

Tomcat是运行Java Web应用的容器。我们需要的是一个tar.gz的二进制包，官方渠道下载即可。下载时需要选择合适版本，Tomcat 10系列对Java版本要求比较高，Java 17可以很好地配合。

把Tomcat解压到有意义的路径，我习惯放在/opt下：

sudo tar -xzf apache-tomcat-10.x.x.tar.gz -C /opt sudo mv /opt/apache-tomcat-10.x.x /opt/tomcat

直接解压后的目录归属是root，而Tomcat默认的启动脚本建议不要以root身份运行，因为权限太大，一旦web应用被入侵，系统会受到更大威胁。所以创建一个普通用户来运行Tomcat：

sudo useradd -r -s /usr/sbin/nologin tomcat sudo chown -R tomcat:tomcat /opt/tomcat

-r表示创建系统用户，-s /usr/sbin/nologin表示该用户不允许登录shell，只能用来运行服务。这样既保证了运行身份，也限制了登录风险。

接下来用systemd来管理Tomcat，创建服务文件：

sudo tee /etc/systemd/system/tomcat.service > /dev/null <<EOF [Unit] Description=Apache Tomcat Web Application Container After=network.target [Service] Type=forking User=tomcat Group=tomcat Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64" Environment="CATALINA_HOME=/opt/tomcat" ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh [Install] WantedBy=multi-user.target EOF

之前我用过直接执行startup.sh的方式，但那只是在前台跑进程，关掉终端就没了。用systemd托管后，Tomcat可以被开机自启、崩溃自动重启，还能通过journalctl查看日志，这才是服务器服务的标准管理方式。

Type=forking表示启动脚本执行完会返回，真正的Tomcat进程在后台运行。这种模式对应的就是Tomcat的startup.sh脚本行为，systemd需要知道这一点才能正确跟踪服务状态。

配置完成后，重新加载systemd并启动服务：

sudo systemctl daemon-reload sudo systemctl enable tomcat sudo systemctl start tomcat

4.4 验证Tomcat并放行8080端口

启动之后先在本机验证：

curl http://localhost:8080

如果返回一段HTML，里面有Tomcat默认页面的文字，说明Tomcat已经正常运行。接着再用宿主机的浏览器访问：

http://虚拟机IP:8080

看到Tomcat默认主页就是成功了。如果浏览器访问不了，而本机curl正常，问题基本出在虚拟机的网络层。检查一下ufw防火墙状态：

sudo ufw status

如果ufw处于active状态，需要放行8080端口：

sudo ufw allow 8080/tcp

这里需要再次强调固定IP的重要性。Tomcat跑起来后，如果虚拟机IP地址因为重启发生了变化，浏览器访问的地址就得跟着改。所以要么登录路由器给虚拟机做DHCP保留，要么直接在Ubuntu的netplan配置里写静态IP。

4.5 部署老Web应用时留意jakarta包名

如果只是跑通Tomcat的默认页面，后面的部署环节还有个容易忽略的坑。Tomcat 10开始，Java Web应用的标准包名从javax.servlet迁移到了jakarta.servlet。直接把一个基于Tomcat 9编写的war包丢进Tomcat 10的webapps目录，启动时很可能遇到各种类找不到的报错。

解决办法有两个：如果是旧项目沿用老规范，就使用Tomcat 9版本；如果坚持用Tomcat 10，就需要把源码里的javax包名替换成jakarta再重新编译打包。这个知识点在刚开始接触Tomcat时很容易被忽略，但实际部署生产项目时几乎必然遇到。

5. Ubuntu + Tomcat环境高频问题排查手册

环境跑通不是终点，遇到问题能快速定位才是真正提升效率的地方。这里把最常踩的坑整理成一份速查表，以及一个日志优先的排查思路。

5.1 直接对照的问题速查表

这个表格里的场景基本都是我在部署过程中实际遇到过的，或者身边同事踩过的坑。遇到问题先对照现象定位方向，比盲目重装系统高效得多。

5.2 日志优先的排查思路

我在排查问题时的固定顺序是：先看系统状态，再看应用日志，最后查网络链路。系统状态通常一眼就能给出方向。

Tomcat管理类的信息主要看这几个日志文件：

• /opt/tomcat/logs/catalina.out：Tomcat启动和运行的主日志，大多数启动异常都是从这里看到线索。
• /opt/tomcat/logs/localhost.*.log：每个Web应用自己的运行日志，部署war包后的异常往往记录在这里。
• /opt/tomcat/logs/manager.*.log：Manager模块相关的日志。

如果Tomcat由systemd托管，还能用统一的日志命令：

journalctl -u tomcat -f

-f表示持续跟踪最新输出，适合观察启动过程中的实时日志。

SSH相关的问题则可以查看认证日志：

sudo tail -f /var/log/auth.log

比如密钥认证失败、密码错误尝试，都会记录在这里，排查远程登录问题时非常有用。只要养成了先看日志、再动手改配置的习惯，绝大部分问题都能在一两次定位中解决。

最后再分享一个个人习惯。我每次部署完一套Ubuntu + Tomcat环境，都会先在VMware里拍一个快照。后面无论配置改坏、Tomcat被折腾到起不来，还是想验证不同的部署方案，都可以快速回滚到这个干净的初始状态。这个操作在学习和实验阶段尤其值得养成习惯，能让你放心大胆地做各种尝试。