17370845950

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