Elasticsearch 8.x 在 GitLab CI 中的正确配置方法

本文详解如何在 gitlab ci 中成功启动并连接 elasticsearch 8.x（如 8.10.2），重点解决因默认启用安全特性（如 tls/ssl 和内置用户认证）导致的连接拒绝与协议错误问题。

Elasticsearch 自 8.0 版本起，默认启用安全功能（xpack.security.enabled=true），强制要求 httpS 访问、TLS 证书验证及用户身份认证。这使得原本适用于 7.x 的直连 http://elasticsearch:9200 方式在 8.x 中直接失败——表现为 Connection refused 或 Protocol Error，即使服务已启动。

在 gitLab CI 的 services 中运行 Elasticsearch 8.x 时，必须显式禁用安全模块（开发/测试场景下推荐），并确保使用单节点发现模式。以下是经过验证的正确配置：

lint_and_test:   stage: test   services:     - postgis/postgis:14-3.4     - name: docker.elastic.co/elasticsearch/elasticsearch:8.10.2       alias: elasticsearch       command:         - bash         - -c         - >           exec /usr/local/bin/docker-entrypoint.sh           elasticsearch           -Ediscovery.type=single-node           -Expack.security.enabled=false   tags:     - healthcloud-multi   script:     - timeout 60 bash wait_for_service_up.sh elasticsearch:9200 || false     - curl -s "http://elasticsearch:9200/_cat/health?v"

✅ 关键要点说明：

• 使用官方镜像地址 docker.elastic.co/elasticsearch/elasticsearch:8.10.2（更稳定，避免社区镜像兼容性问题）；
• alias: elasticsearch 确保 dns 解析可靠（gitlab CI 内部网络依赖别名）；
• -Expack.security.enabled=false 是核心修复项，关闭所有内置安全层，恢复 HTTP 明文通信；
• -Ediscovery.type=single-node 仍为必需，避免集群启动失败；
• 不再需要手动修改 jvm.options（新版 entrypoint 已优化内存策略，且自定义 JVM 参数易引发启动异常）；
• wait_for_service_up.sh 应基于 curl -f http://elasticsearch:9200/ 实现健康探测（注意：禁用安全后无需 -k 或认证头）。

⚠️ 注意事项：

• 此配置仅适用于 CI 集成测试等受控、非生产环境；生产环境必须启用并正确配置 TLS 与 RBAC；
• Elasticsearch 8.x 不再支持 http.port 单独设置，若需变更端口，应配合 -Ehttp.port=9201 并同步更新 wait_for_service_up.sh 及应用配置；
• 若后续需模拟真实安全环境（如测试认证逻辑），建议改用 docker-compose 启动带自签名证书的集群，或利用 Elasticsearch 提供的 elasticsearch-setup-passwords 工具生成凭证。

通过上述配置，即可在 GitLab CI 中无缝迁移至 Elasticsearch 8.x，保障依赖 ES 的集成测试持续稳定运行。