在GitHub Actions中用Testcontainers运行Aerospike偶发连接失败求助

问题根源 #

连接失败的核心原因是：Aerospike容器默认会向客户端返回容器内部的IP和端口，但Testcontainers会将容器端口映射到宿主机的随机端口（比如报错中的32772），客户端用容器内部地址自然无法连接。另外，现有等待条件依赖日志的稳定性不足，可能导致容器未完全就绪就发起连接。

解决方案 #

1. 配置Aerospike返回可访问的客户端地址

修改Aerospike配置文件的network.service段，添加access-address参数，让服务返回宿主机可访问的地址：

network {
    service {
        address any
        port 3000
        # 让Aerospike返回127.0.0.1作为客户端连接地址（适配GitHub Actions runner环境）
        access-address 127.0.0.1
    }
    # 其余配置保持不变
}

如果需要动态适配端口，可以在启动容器时通过命令行参数覆盖：

// 在ContainerRequest的Cmd中追加参数
Cmd: []string{"--config-file", "aerospike.conf", "--service.access-address", "127.0.0.1"},

2. 替换为更可靠的容器就绪等待条件

原有的日志等待逻辑不稳定，改用asinfo命令验证服务状态，确保Aerospike完全就绪：

WaitingFor: wait.ForAll(
    wait.ForListeningPort("3000/tcp"),
    // 执行asinfo命令检查服务状态，返回0表示就绪
    wait.ForExec([]string{"asinfo", "-v", "status"}).WithExitCode(0),
),

3. 确保客户端使用Testcontainers映射的随机端口

连接Aerospike时，必须通过Testcontainers获取实际映射的端口，而非硬编码：

// 在startContainer函数中获取映射端口
port, err := container.MappedPort(ctx, "3000/tcp")
if err != nil {
    return nil, err
}

// 客户端连接时使用该端口
client, err := aerospike.NewClient("127.0.0.1", port.Int())

4. 优化Aerospike单节点集群配置

在service段启用单节点副本限制，避免集群等待其他节点导致的启动延迟：

service {
    user root
    group root
    # 单节点时自动将副本数减为1，无需等待其他节点
    paxos-single-replica-limit 1
    proto-fd-max 15000
    query-threads-limit 100
}

内容的提问来源于stack exchange，提问作者abouttest