CentOS 7 单机拉起 Elasticsearch 7.17.29：从内核报错到公网可达的全链路记录

在 CentOS 7 上部署 Elasticsearch，最卡人的往往不是解压那一步，第一次启动就被 vm.max_map_count 拦在门外，调完内核又撞上 401 认证，终于 curl 通了，外部机器却死活连不上 9200。

常见的"下载---解压---启动"三步教程，默认环境干净、安全认证关闭、网络全在内网，可真实单机里这三条同时不成立，缺一项就走不到最后。

本文分享一套可直接落地的完整路径：内核与权限前置调优 + xpack 安全开关与 CRUD 双向验证 + 固定公网地址的三层配置，照做即可交付。

一、部署前盘点：版本与资源底线先对齐

先把硬件、内核、版本三件事查清楚，任何一项不达标后面都会返工：

检查项	建议值	一键检查
可用内存	≥ 8G	free -h
堆内存	≤ 物理内存 50%，≤ 31G	jvm.options 中 -Xms/-Xmx
内核参数	vm.max_map_count ≥ 262144	sysctl vm.max_map_count
磁盘余量	≥ 50G，优先 SSD	df -h
运行 JDK	解压包自带 OpenJDK 11	bin/elasticsearch --version

• 内存底线：堆内存取物理内存一半，留给系统和页缓存的余量不能为零。
• 版本对齐：7.17.29 压缩包自带 JDK 11，再装系统 JDK 反而容易出现双版本冲突。
• 内核余量 ：CentOS 7 默认 vm.max_map_count 只有 65530，离推荐的 262144 差得很远。

核心结论：环境不达标就别急着启动，先把上面这张表逐项跑一遍。

二、安装落地：解压建用户与目录权限

包就位只是表象，属主与权限才是能不能启动的真正门槛：

• 专用账号 ：ES 拒绝 root 启动，必须新建 esuser 并把目录整体移交。
• 目录规划：data、logs、config 三处分开，后续换盘和排错都省事。
• 锁定内存 ：bootstrap.memory_lock: true 生效的前提是 limits 里 memlock 解锁。

下面这段脚本完成建用户、解压、赋权三步，适配 CentOS 7 的 yum 环境：

useradd -r -m -s /bin/bash esuser
mkdir -p /opt/es && tar -zxf elasticsearch-7.17.29-linux-x86_64.tar.gz -C /opt/es --strip-components=1
chown -R esuser:esuser /opt/es
cat >> /etc/security/limits.conf <<'EOF'
esuser soft nofile 65536
esuser hard nofile 65536
esuser soft memlock unlimited
esuser hard memlock unlimited
EOF

属主正确 + 句柄解锁，是后面所有启动动作的前提。

三、启动首错：内核与句柄的调优闭环

第一次 bin/elasticsearch 十有八九会卡在 bootstrap 检查，先把这段调优跑完：

sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' >> /etc/sysctl.conf
sysctl -p
su - esuser -c '/opt/es/bin/elasticsearch -d -p /opt/es/es.pid'
curl -s localhost:9200 | head -n 5

常见报错与处置对照：

报错关键字	根因	处置
max virtual memory areas	vm.max_map_count 过小	写入 sysctl.conf 后 sysctl -p
file descriptors too low	ES_NOFILE 小于 65536	limits.conf 两段同时写 soft/hard
memory locking failed	memlock 未解锁	limits.conf 增加 memlock unlimited
cluster not bootstrapped	单节点首次未指定主节点	配置 node.name 与 cluster.initial_master_nodes

• 先改内核后启动：调完参数必须让进程重新读取，老进程不会自动生效。
• 先看日志再猜原因 ：9 成问题都能在 logs/elasticsearch.log 里找到第一行堆栈。

核心结论：内核参数与文件句柄是启动失败的两大数据源，先调优再谈排查。

四、服务拉起：systemd 托管与日志定位

前台跑只适合调试，长期运行必须交给 systemd 托管：

cat > /etc/systemd/system/elasticsearch.service <<'EOF'
[Unit]
Description=Elasticsearch 7.17.29
After=network.target
[Service]
Type=simple
User=esuser
LimitNOFILE=65536
ExecStart=/opt/es/bin/elasticsearch
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload && systemctl enable --now elasticsearch
systemctl status elasticsearch --no-pager | head -n 12

• Unit 要点 ：User 必须是 esuser，LimitNOFILE 要和 limits.conf 对齐，否则以 systemd 为准。
• 日志三处 ：主日志 logs/elasticsearch.log、stdout 输出 _server.out、服务级 journalctl -u elasticsearch。
• 端口先自查 ：9200 不通时先 ss -lntp | grep 9200，确认到底绑没绑、绑在哪。

核心结论：systemd 接管后，"服务状态 + 主日志 + 端口监听"三件套就是排错最短路径。

五、安全开关：xpack 认证带来的连锁反应

7.x 默认开启 security，此时直接 curl 只会拿到一串 401：

# 方案A：保留认证，重置内置账号密码（适合要上公网的场景）
/opt/es/bin/elasticsearch-reset-password -u elastic

# 方案B：单机自测临时关闭认证（切勿在公网执行）
sed -i 's/^xpack.security.enabled:.*/xpack.security.enabled: false/' /opt/es/config/elasticsearch.yml
systemctl restart elasticsearch
curl -s localhost:9200

• 公网场景选 A：密码是后面固定公网地址的前置条件，关掉认证等于裸奔。
• 内网联调选 B：先跑通链路再开认证，但必须写进待办，不能遗忘。
• 改配置必重启 ：elasticsearch.yml 不支持热加载，改完必须 restart。

核心结论：认证不是可选项，而是决定你敢不敢把 9200 暴露到公网的分水岭。

六、CRUD 验证：五类请求打通一条数据链

服务变绿只是及格线，用最小请求集确认读写真的通：

动作	方法	路径	语义
写入	PUT	/books/_doc/1	指定 id 创建文档
读取	GET	/books/_doc/1	按 id 取回原文
更新	POST	/books/_update/1	局部字段合并
删除	DELETE	/books/_doc/1	按 id 删除
计数	GET	/books/_count	统计文档总数

# 先建带 mapping 的索引，再走增查改删全链路
curl -X PUT localhost:9200/books -H 'Content-Type: application/json' -d '{
  "mappings": {"properties": {
    "title": {"type": "text"},
    "price": {"type": "half_float"},
    "tags":  {"type": "keyword"}}}}'
curl -X PUT localhost:9200/books/_doc/1 -H 'Content-Type: application/json' \
  -d '{"title":"CentOS运维实战","price":69,"tags":["linux","ops"]}'
curl -X POST localhost:9200/books/_update/1 -H 'Content-Type: application/json' \
  -d '{"doc":{"price":59}}'
curl -s localhost:9200/books/_count

增 → 查 → 改 → 计数 四步全返回 result 与正确 version，CRUD 才算验证通过。

七、查询体检：从 match 到 terms 的聚合验证

单条 CRUD 只证明通路，聚合才证明 mapping 类型没设错：

# 关键词检索 + 分面聚合，一次跑完
curl -s localhost:9200/books/_search -H 'Content-Type: application/json' -d '{
  "query": {"match": {"title": "运维"}},
  "aggs": {
    "avg_price": {"avg": {"field": "price"}},
    "by_tag": {"terms": {"field": "tags", "size": 10}}}}'

• text 与 keyword 的区别 ：title 用 text 才能被 match 分词命中，tags 必须是 keyword 才能聚合。
• 聚合报错怎么判 ：出现 Fielddata is disabled 就说明该字段类型被当成 text 写进去了。
• 验证顺序 ：先 _count 确认有数据，再 _search 确认能命中，最后跑聚合确认结构。

核心结论：聚合不报错，才说明 mapping 设计与写入数据是自洽的。

八、固定公网地址：绑定与放行的三层改法

让外部稳定访问，要把"绑在哪、放不放、怎么转"三层一次对齐：

层级	配置位置	建议值
绑定层	elasticsearch.yml	network.host: 公网IP
放行层	firewalld / 云安全组	只放 9200，9300 仅内网
转发层	nginx 反向代理	443 → 9200，附带认证

# 绑定固定公网 IP，并放开集群内部端口
cat >> /opt/es/config/elasticsearch.yml <<'EOF'
network.host: 192.168.10.20
http.port: 9200
discovery.seed_hosts: ["192.168.10.20"]
cluster.initial_master_nodes: ["node-1"]
EOF
# 防火墙只放 HTTP 端口，9300 留在内网
firewall-cmd --permanent --add-port=9200/tcp && firewall-cmd --reload
systemctl restart elasticsearch

• 绑定公网 IP 而非 0.0.0.0：后者会同时监听所有网卡，意外暴露面更大。
• 改 network.host 触发完整检查：绑定非回环地址会把 bootstrap check 全部激活，前面的调优此时见真章。
• 9300 绝不外放：它是节点通信端口，暴露后可被直接探测集群拓扑。

核心结论：绑定地址 + 端口放行 + 反代兜底，三者缺一个就谈不上"固定公网地址"。

九、访问加固：证书、白名单与密码轮换

9200 一暴露就会被全网扫描器盯上，加固必须和开放同步上线：

# 生成自签证书并启用 HTTPS
/opt/es/bin/elasticsearch-certutil http --silent --pem -out /opt/es/http.zip -in /opt/es/config/elasticsearch.yml
unzip /opt/es/http.zip -d /opt/es/config/certs
# 白名单：只放办公网段访问 9200
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=203.0.113.0/24 port port=9200 protocol=tcp accept'
firewall-cmd --reload

• 强制 TLS ：xpack.security.http.ssl.enabled: true 后，明文 curl 会被直接拒绝。
• 来源白名单：用 rich-rule 限定源 IP 段，比全局开 9200 安全一个量级。
• 密码轮换 ：elasticsearch-reset-password 定期更换 elastic 密码，配合审计日志留痕。

核心结论：公网暴露的端口，防护必须是"证书 + 白名单 + 密码"三层叠加。

十、长期运行：自启、快照与回归清单

部署完成只是起点，把可重复性固化下来才算真正交付：

# 注册快照仓库并按天备份关键索引
curl -X PUT localhost:9200/_snapshot/backup -H 'Content-Type: application/json' \
  -d '{"type":"fs","settings":{"location":"/opt/es/backup"}}'
curl -X PUT "localhost:9200/_snapshot/backup/snap_$(date +%F)?wait_for_completion=true"

• 开机自启 ：systemctl enable elasticsearch，避免重启后服务静默消失。
• 定期快照 ：快照仓库落到独立磁盘，配合 wait_for_completion 拿到确定性结果。
• 回归清单 ：每次改 elasticsearch.yml 后固定复查内核参数、端口监听、9200 状态码、磁盘水位四项。

核心结论：能被脚本重复执行的部署，才叫交付，否则只是一次性实验。

结语

这套流程把 CentOS 7 单机部署 Elasticsearch 7.17.29 拆成了可验证的十个环节：环境盘点先行，内核与权限前置，启动报错按表排查，CRUD 与聚合双重验证，最后再做公网绑定与三层加固。每一步都有明确的命令、判定标准和回滚位置，照着执行就能从空白机器走到外部可访问、数据可备份的稳定状态。

真正决定成败的不是装包，而是把"报错---修复---验证"做成闭环，再把开放公网与安全加固绑在同一时间点上。

先让本地通，再让公网通，最后让公网值得信任。