企业官网建设流程全解析

1. 安装前的思路准备：在线安装为什么是首选

Ubuntu 16.04是一套老牌长期支持系统，虽然它已经退出主流维护周期，但不少生产环境、个人服务器、学习实验机上仍然在跑。很多开发者手里都有一台这样的机器，里面跑着旧业务、爬虫任务或者正在练手的项目，而MongoDB往往是这套体系里绕不开的存储组件。我接触过不少朋友，最开始都在纠结一件事：同一台机器上，MongoDB到底该用在线安装还是离线安装。

这个问题的答案从表面上看并没有那么绝对，但我在实际部署过几十次之后，态度越来越明确：只要网络环境允许，在线安装永远是优先级最高的方案。原因很简单，MongoDB从4.x版本开始，安装包的依赖关系越来越复杂，尤其是libssl、libcurl这类基础库，它们和操作系统自带版本的兼容性直接决定数据库能否正常启动。在线安装最大的价值在于，包管理器会帮你自动解析依赖树，把所有缺失的底层库一并拉下来装好，整个过程几乎不用人工干预。

离线安装的坑我在早期踩过不少。你辛辛苦苦拿到一个deb安装包，结果一执行安装命令，就提示缺少libssl.so.1.0.0或者libcurl4-openssl-dev这类依赖。这时候你被迫手动去下载各种版本的依赖包，装完一个又冒出来下一个，层层嵌套，运气好十几分钟能折腾完，运气不好整个下午都耗在里面。更麻烦的是，如果你下载的deb包版本和系统架构、内核版本不完全匹配，还会引发动态库链接错误，到时候排查起来远比在线安装痛苦。

在线安装的另一个好处是便于后续升级。MongoDB官方仓库或者PPA源会持续推送小版本更新，一个apt upgrade就能同步到最新补丁，不用再费劲去官网盯更新日志。对于运维来说，这种可维护性是实打实的加分项。所以本篇博文的整个操作流程都围绕在线安装展开，从源配置到服务验证，再到故障排查，一步一步带着你走通。

提示：如果你是在跳板机、内网隔离环境里部署，那离线安装是不得已的选择，但只要有得选，优先在线装。

在开始动手之前，我建议你先把自己的服务器环境梳理一遍，比如确认系统版本、确认root或者sudo权限、确认网络出口能够访问外网，这些准备工作看起来不起眼，却直接影响后续的安装效率。下一篇内容我开始拆解具体怎么操作，每一步都给到实测过的信息和参数。

2. 环境检查与安装源配置

2.1 确认系统版本和权限

Ubuntu 16.04有一个很明显的识别特征，它的代号叫Xenial Xerus，对应的版本号是16.04.x。在安装MongoDB之前，第一件事就是确认当前系统确实是你预期中的版本。执行下面的命令查看：

lsb_release -a cat /etc/os-release

如果输出里能看到Distributor ID: Ubuntu和Description: Ubuntu 16.04.7 LTS之类的字样，说明版本没问题。这里我多说一句，16.04的小版本号并不关键，关键是内核和软件源版本要匹配，你不需要折腾内核升级，保持原样就行。

接下来确认权限。MongoDB的安装过程需要把软件包写入系统目录、注册systemd服务，所以必须要root权限或者具备sudo权限的普通用户。在继续任何操作之前，先验证一下你的权限：

sudo whoami

如果返回root，说明权限没有问题。如果提示用户不在sudoers中，那你得先联系服务器管理员把权限开了再继续，不然下面的步骤没法执行。

注意：整个安装过程请全程使用一个固定用户操作，不要一会儿用root，一会儿用普通用户，后面配置文件和目录权限会变得混乱。

2.2 配置MongoDB官方源

Ubuntu 16.04自带的默认apt源里是没有MongoDB包的，所以直接执行apt install mongodb，装到的是一个过时的社区编译版本，甚至可能根本没有这个包。正确做法是优先把MongoDB官方源接入到系统的软件源列表中。

MongoDB官方源对应的源地址格式是deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.4 multiverse。这里面有两个关键点需要理解：第一个是xenial，它必须和你的系统代号完全对应，Ubuntu 16.04就是xenial，如果是Ubuntu 18.04就得换成bionic，写错任何一个单词源都会失效；第二个是4.4，我把版本号固定在4.4，这是MongoDB官方对Ubuntu 16.04提供完整支持的最后一代长期稳定版本，4.4以上的版本官方源里对xenial的支持就开始变得不完整，强行安装会出现各种奇怪的兼容问题。

注册源之前，需要先把官方GPG公钥导入系统。MongoDB官方源发布的所有软件包都会用这个公钥做签名验证，如果公钥没导入，apt会拒绝安装来自该源的任何软件包。导入公钥的命令如下：

wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -

执行完之后可以再执行一次sudo apt-key list查看公钥信息是否已经出现在列表里。以前我见过有人在网上直接复制一条命令就去执行，结果把公钥URL写成了旧版的server-4.2.asc，虽然也能用，但版本锚定不准，后面容易埋雷。

接下来创建源列表文件。在/etc/apt/sources.list.d/目录下新建一个专门给MongoDB用的源文件，这样做的好处是后期如果你要移除MongoDB，直接删掉这个文件就行，不用去动系统主源文件，风险小得多。

echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.4.list

2.3 PPA源和官方源的选型差异

我在给开发者做方案咨询的时候，总有人会问：能不能直接用PPA源装MongoDB？确实，在Ubuntu生态里有很多个人维护的MongoDB PPA，比如mongodb这个PPA，一条add-apt-repository ppa:mongodb/ppa就能搞定，看起来更简单。但我的建议是，正式环境一律绕开PPA，只用官方源。

原因有这么几条。第一，PPA源的维护者不一定是MongoDB官方团队，更新节奏不确定，版本滞后是常态，补丁推送也不及时。第二，PPA源的打包参数有时候和官方不一致，编译选项、依赖关系都会有偏差，这会导致你装好的MongoDB行为和官方文档描述不一致。第三，一旦出了安全问题或者bug，你通过PPA装的版本，很难第一时间拿到官方修复补丁，而这个等待期里你的数据其实处在风险中。

官方源的更新是紧跟主干版本的，安全通告发布之后，源里对应的修复版本几乎是同步上架，从运维角度这是最稳妥的选择。如果你只是在自己本机做实验，PPA可能无伤大雅，但正式服务器务必使用官方源。

2.4 更新源索引并校验可用性

源配置文件写好后，需要让apt重新读取软件源列表，把MongoDB仓库里的包索引下载到本地：

sudo apt-get update

这一步执行过程中你需要注意观察输出信息，重点看有没有404 Not Found或者Failed to fetch之类的报错。我在16.04上配置源的时候，偶尔会因为网络原因导致repo.mongodb.org连接超时，这时候多重复几次apt-get update通常就能通过。如果一直失败，检查一下服务器DNS配置和外网连通性。

更新完成之后，可以用下面这条命令快速确认MongoDB源是否已经生效：

apt-cache policy mongodb-org

如果源配置正确，你会看到输出里有候选版本一栏，显示的是4.4.x的版本号，这说明软件源已经识别到了MongoDB的安装包。到这一步，环境准备阶段就全部完成了。

心得：这一步output里如果显示的是4.2.x或者更老的版本，大概率是你的源地址里写错了版本号，回去检查一下mongodb-org/4.4这一段。

3. 核心安装步骤实战拆解

3.1 安装命令与版本锁定的重要性

环境卷好后，正式安装只需要一条命令：

sudo apt-get install -y mongodb-org

这条命令执行的过程里，apt会从刚配置好的官方源拉取mongodb-org元包及其依赖组件。这个mongodb-org元包本身不包含具体二进制文件，它依赖几个子包：mongodb-org-server（核心数据库服务）、mongodb-org-mongos（路由服务，用于分片集群）、mongodb-org-shell（命令行客户端）、mongodb-org-tools（导入导出等工具集）。一次性装上这套全家桶，后面做任何管理操作都不用再单独补组件，省心。

在安装的时候，如果输出里出现了libcurl3、libssl1.0.0之类的依赖提示，请不要慌张，这是正常现象，apt会自动从Ubuntu源里把这些依赖拉下来，你只需要确认apt给出的安装计划里没有明显冲突就行。

安装完成后，建议立刻锁定版本，防止后续系统更新时MongoDB被意外升级。Ubuntu的unattended-upgrades机制有时会自动执行安全更新，如果你不锁定版本，某天突然发现MongoDB被升级到了不兼容的版本，服务起不来了，那就非常被动了。

锁定版本的方法是，把下面这些包设置成hold状态：

sudo apt-mark hold mongodb-org sudo apt-mark hold mongodb-org-server sudo apt-mark hold mongodb-org-shell sudo apt-mark hold mongodb-org-mongos sudo apt-mark hold mongodb-org-tools

这样设置之后，即使执行apt-get upgrade，这些包也不会被改动。后面想升级的时候，执行sudo apt-mark unhold解除锁定，再更新即可。

3.2 验证安装结果的正确姿势

安装完成之后，很多人习惯性地执行mongod --version来看版本号，这个命令确实能验证二进制文件是否存在，但还不够全面。我更推荐用下面这个命令查看系统的实际软件包状态：

dpkg -l | grep mongodb

这条命令会列出所有已安装的MongoDB相关包和版本号，你一眼就能确认每个子包的版本是否一致。版本号不一致的情况在手动安装时很容易出现，通过官方源在线装通常不会出这种问题，但养成检查的习惯总没坏处。

同时确认一下MongoDB的二进制文件路径和默认数据目录是否存在：

which mongod ls -la /var/lib/mongodb ls -la /etc/mongod.conf

正常情况下，/var/lib/mongodb和/etc/mongod.conf应该已经自动创建好。数据目录和配置文件的路径对后面所有操作都至关重要，你写systemd服务、改存储路径、配日志策略的时候都要用到它们。

提示：我在16.04上第一次安装后，发现/var/lib/mongodb目录不存在，排查一圈是安装顺序问题——旧版本的残留配置干扰了新版本安装。遇到这种问题别急着手动创建目录，先彻底清理旧版本再重新安装。

3.3 安装过程中常见的网络问题及应对

在线安装最怕的就是网络波动导致的半截安装状态。有一次我在一台海外服务器上装MongoDB，apt下载到一半突然断连，再次执行apt-get install -y mongodb-org时，apt提示有未完成的安装，需要先执行dpkg --configure -a修复。

这种情况下，我的处理套路是这样的：

sudo dpkg --configure -a sudo apt-get install -f sudo apt-get install -y mongodb-org

第一句修复未完成的包配置，第二句自动修复依赖关系，第三句重新执行安装。大部分半截安装状态都能通过这三连修复回来。如果还是报错，看具体错误信息，常见的是锁文件冲突，执行sudo rm /var/lib/dpkg/lock-frontend再重试即可。

4. 服务启动配置与核心参数调优

4.1 systemd服务单元解析

Ubuntu 16.04默认使用systemd管理服务，MongoDB官方包安装完成后会自动注册一个名为mongod的服务。执行启动命令：

sudo systemctl start mongod sudo systemctl enable mongod

start是启动服务，enable是把服务设置成开机自启，这两条命令组合起来使用，服务器重启后MongoDB会自动拉起，省去人工干预。

启动之后，立刻检查服务状态：

sudo systemctl status mongod

如果输出里有active (running)字样，说明服务正常。如果出现failed，就需要往下看日志排查。查看MongoDB自身运行日志的命令是：

sudo journalctl -u mongod -f

也可以直接查看MongoDB的配置文件里指定的日志文件路径，默认位于/var/log/mongodb/mongod.log。我在定位问题的时候，习惯直接tail -n 200 /var/log/mongodb/mongod.log，把最新日志拉出来，看有没有exception in initAndListen或者Address already in use之类的关键行。

4.2 修改绑定IP和端口的安全考量

MongoDB安装完成后，默认配置只允许本地连接，监听地址是127.0.0.1。这个配置对本地开发和单机部署没问题，但如果需要远程连接，就必须修改/etc/mongod.conf中的bindIp配置。

net: port: 27017 bindIp: 127.0.0.1,你的服务器内网IP

这里有个安全原则必须强调：除非你非常清楚自己在做什么，否则不要把bindIp改成0.0.0.0直接暴露公网。MongoDB在开启认证之前，默认是完全信任所有连接的，如果你把服务暴露到公网又没有开启认证，那你的数据等于裸奔，任何人都可以连接你的27017端口执行任意读写操作。网上被勒索、被删库的案例大多数就是这么来的。

正确做法是，如果确实需要外网访问，务必同时修改配置开启认证，也就是添加以下内容到/etc/mongod.conf：

security: authorization: enabled

然后在客户端访问时，通过mongodb://用户名:密码@IP:27017/库名这种格式连接。

4.3 数据目录和日志策略的规划

在正式使用之前，我建议你先审视一下MongoDB的默认存储位置是否合理。默认数据目录是/var/lib/mongodb，如果你的根分区空间不足，数据库写满了之后会直接报错，甚至导致服务崩溃。

规划存储，我推荐的方式是这样：把数据目录挂载到独立的数据盘或空间足够的分区，然后修改配置文件和systemd服务定义。

先在目标位置创建新数据目录：

sudo mkdir -p /data/mongodb sudo chown -R mongodb:mongodb /data/mongodb

修改/etc/mongod.conf中的storage.dbPath指向新目录：

storage: dbPath: /data/mongodb

然后你需要确认systemd服务定义文件授权的路径范围。执行sudo systemctl cat mongod你会发现，服务定义里通过ProtectSystem=full和ReadWritePaths=限制了MongoDB只能写入某些指定路径。如果你只改了配置文件而不改服务定义，启动时大概率会被systemd拦截，报出类似Permission denied的错误。

正确做法是把新的数据目录加入服务定义的读写路径里：

sudo systemctl edit mongod

在弹出的编辑窗口里添加：

[Service] ReadWritePaths=/data/mongodb

保存后重载服务配置，再启动MongoDB。这个细节很少在教程里被提到，但很多开发者换存储位置后启动失败，根因就在这里。

4.4 创建管理员账号和业务账号

无论你是本地测试还是生产部署，第一件事都是先给MongoDB设置访问控制。MongoDB的用户权限体系和关系型数据库不太一样，它必须先连接到admin库，在admin库下创建带root角色的用户。

先重启服务让认证配置生效：

sudo systemctl restart mongod

然后进入mongosh（4.4版本默认的交互式Shell）：

mongo --host 127.0.0.1 --port 27017

接着切换到admin数据库：

use admin

创建管理员账号：

db.createUser({ user: "admin", pwd: "这里填一个强密码", roles: [ { role: "root", db: "admin" } ] })

root角色拥有整个MongoDB实例的最高权限，包括管理其他用户、创建删除数据库、执行所有读写操作。这个账号创建好之后，后续所有管理操作都要用它登录验证。

接下来创建业务数据库专用账号。假设你的应用要使用mydb这个数据库，先切换到这个库再创建账号：

use mydb db.createUser({ user: "appuser", pwd: "这里填另一个强密码", roles: [ { role: "readWrite", db: "mydb" } ] })

这样appuser只能在mydb里执行读写操作，无法影响其他数据库，权限边界非常清晰。

创建完成之后，退出当前无认证会话，用账号信息重新登录验证：

mongo --host 127.0.0.1 --port 27017 -u admin -p 你的密码 --authenticationDatabase admin

能正常执行show dbs说明认证已经生效。

心得：生产环境里数据库账号密码不要明文出现在命令行历史或代码仓库中，推荐用环境变量或密钥管理服务读取账号信息。

5. 常见问题与排查技巧实录

5.1 依赖缺失与libssl版本冲突

Ubuntu 16.04系统自带的OpenSSL版本偏老，而MongoDB官方包在不同版本里对libssl的依赖并不一致。MongoDB 4.4版本依赖的是libssl1.1，如果你的系统里已经装了libssl1.0.2，很容易出现版本冲突。

我在一台老机器上装MongoDB时，就遇到过这样的报错：

mongod: error while loading shared libraries: libssl.so.1.1: cannot open shared object file

这个问题的根源是系统里没有libssl1.1的动态库。解决办法有两个，第一是手动下载libssl1.1的deb包并安装，第二是执行sudo apt-get update && sudo apt-get install libssl1.1直接从源里装。前者面对离线环境更有效，后者在线环境更省事。

装完之后执行ldd $(which mongod) | grep ssl确认动态库链接正常，如果输出里出现libssl.so.1.1，就说明链接成功。

5.2 服务启动失败的三类高频原因

我整理了服务启动失败的最高频原因，基本可以归为三类，按出现概率排序：

第一类是端口占用。MongoDB默认端口27017，如果服务器上已经有其他进程占用了这个端口，mongod启动时会在日志里输出Address already in use。排查命令：

sudo lsof -i :27017 sudo netstat -tlnp | grep 27017

如果确实被占用，要么改MongoDB的监听端口，要么处理掉占用进程。

第二类是数据目录权限不对。前面提到过，/var/lib/mongodb目录的属主必须保持为mongodb:mongodb。有时候你为了操作方便，用root往这个目录里写文件，整个目录的属主就变了，MongoDB启动时会因为无法写入数据文件而报错：

exception in initAndListen: 98 Unable to create/open lock file: Permission denied

修复方式就是重新授权：

sudo chown -R mongodb:mongodb /var/lib/mongodb

第三类是配置文件语法错误。YAML文件对缩进非常敏感，少一个空格或者多一个Tab，都有可能导致配置解析失败。我用一个简单方法检查YAML语法：用Python执行python3 -c "import yaml; yaml.safe_load(open('/etc/mongod.conf'))"，如果输出没有任何报错，说明语法没有问题。

5.3 远程连接超时或拒绝

本地连接正常，但远程客户端连接不上MongoDB，这通常不是数据库本身的问题，而是服务器防火墙或安全组规则拦截了27017端口。

Ubuntu 16.04上一般用ufw管理防火墙规则，检查当前状态：

sudo ufw status

如果ufw处于激活状态，需要放行27017端口：

sudo ufw allow 27017/tcp

如果你用的是云服务器，还要去云控制台检查安全组规则，确保入站规则里放开了27017端口。我见过不少人折腾了MongoDB半天，最后发现是云安全组没开端口，纯粹做了无用功。

5.4 快速定位问题的三板斧

当MongoDB出现异常时，我的排查思路通常按这个顺序来，防止在问题迷宫里绕圈：

首先看进程是否存在。执行ps -ef | grep mongod，如果进程都没了，一切免谈，先拉起服务。其次看日志尾部报错。执行sudo tail -n 100 /var/log/mongodb/mongod.log，MongoDB的日志非常详细，几乎每个启动失败的原因它都会明明白白写出来，比你自己猜快得多。最后看端口是否监听。执行sudo netstat -tlnp | grep 27017，如果端口都不监听，说明服务没有真正起来，回头检查前面两步。

这三板斧能覆盖绝大多数启动类和连接类问题的排查场景，非常实用。

6. 生产环境长期运行的重要建议

6.1 备份策略的落地

MongoDB默认是不做自动备份的，生产环境不设备份等于把数据安全交给运气。最简单的备份方案是用官方的mongodump工具做逻辑备份，配合cron定时任务即可。

安装mongodump需要通过官方仓库单独安装：

sudo apt-get install -y mongodb-org-tools

然后写一个简单的备份脚本，放到/usr/local/bin/backup_mongodb.sh：

#!/bin/bash BACKUP_DIR="/data/backup/mongodb" DATE=$(date +%Y%m%d_%H%M%S) mongodump --host 127.0.0.1 --port 27017 \ --username admin --password "你的密码" \ --authenticationDatabase admin \ --out "$BACKUP_DIR/$DATE"

为脚本增加执行权限并添加到crontab：

sudo chmod +x /usr/local/bin/backup_mongodb.sh sudo crontab -e

在crontab里添加定时任务，比如每天凌晨2点备份：

0 2 * * * /usr/local/bin/backup_mongodb.sh

6.2 监控磁盘和内存

MongoDB是典型的磁盘和内存消耗型应用，长期运行后数据文件和日志文件会不断膨胀。我建议至少做到两个层面的监控：磁盘使用率和MongoDB进程状态。

磁盘使用率监控用一条命令就能实现：

df -h | grep /data

MongoDB进程状态监控可以看mongostat命令的输出，它会连续显示数据库的操作量、连接数、队列等待等关键指标，是判断数据库健康状态的有效工具。

6.3 版本升级路径

如果后续你决定升级MongoDB，千万不要跳过小版本直接跨大版本升级。从4.4升级到5.0，需要先确认你当前使用的驱动版本、现有数据库特性是否兼容。官方文档里对升级路径做了明确要求：必须从4.4升级到5.0，再从5.0升级到6.0，不允许跨大版本直接跳。

升级前务必先跑一次完整备份，并且在测试环境完整演练一遍升级流程，确认没问题后再操作生产库。

7. 写在最后的实操体会

Ubuntu 16.04上在线安装MongoDB这件事，难度其实不高，所有操作加起来几分钟就能跑完，但真正考验人的是对细节的把控。版本号写错一个字母、数据目录忘了授权、防火墙端口没放行，这些看起来不起眼的因素，每一个都能让整个部署功亏一篑。

我个人在这个部署过程中体会最深的是权限和路径管理：MongoDB对文件权限非常敏感，服务账户就是mongodb用户，所有数据目录、日志文件、配置文件都必须匹配这个账户的运行边界。很多启动失败、写入异常、远程连接受阻，追根溯源都是从这里出去的。

另外也想提醒一下：网上很多安装教程默认你用的是最新Ubuntu版本，所以版本号、源地址、依赖关系都是基于新系统的，当你把教程照搬到16.04上时，一定要以你系统实际版本为准。我在做技术支持的时候，见过太多次因为版本不匹配而卡住的案例，真正理解每一步背后的原理，比背命令重要得多。

希望这份完整流程能帮你少走几步弯路。如果过程中遇到什么奇怪的报错，先别急着重启服务器，多看看MongoDB日志，答案往往就藏在里面。