本文详解如何在 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 的集成测试持续稳定运行。
