来自ECS的AWS上的Redis命令永远挂起

Question

我有使用Fargate和ElastiCache Redis实例管理的ECS容器。 ECS和Redis都部署在私有VPC中。我想要的是从ECS容器连接到Redis。所有子网和安全组似乎都配置正确，发送auth命令后会有“就绪”事件，但所有其他命令（例如信息）都会永久挂起。这是在容器中运行的代码（带有ioredis的Node.js）：

const client = new IoRedis(process.env.REDIS_URL, {
  connectTimeout: 5000,
  enableOfflineQueue: false,
  enableReadyCheck: false,
});

setInterval(() => {
  client
    .info()
    .then(info => {
      console.log('info received', info);
    })
    .catch(err => {
      console.error('error received', err);
    });
}, 5000);

日志输出是：

12:14:00
{"name":"app","hostname":"ip-10-0-103-126.us-east-2.compute.internal","pid":1,"appName":"api","level":30,"msg":"Server listening on 5000","time":"2019-04-03T12:14:00.176Z","v":0}

12:14:00
2019-04-03T12:14:00.181Z ioredis:redis status[master.ab-cache.hp48ph.use2.cache.amazonaws.com:6379]: [empty] -> connecting

12:14:00
2019-04-03T12:14:00.263Z ioredis:redis status[10.0.31.100:6379]: connecting -> connect

12:14:00
2019-04-03T12:14:00.264Z ioredis:redis write command[10.0.31.100:6379]: 0 -> auth([ '**************************************************' ])

12:14:00
2019-04-03T12:14:00.265Z ioredis:redis status[10.0.31.100:6379]: connect -> ready

12:14:05
2019-04-03T12:14:05.185Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:10
2019-04-03T12:14:10.184Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:15
2019-04-03T12:14:15.190Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:20
2019-04-03T12:14:20.194Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:25
2019-04-03T12:14:25.195Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:30
2019-04-03T12:14:30.197Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:35
2019-04-03T12:14:35.200Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:40
2019-04-03T12:14:40.200Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:45
2019-04-03T12:14:45.202Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:50
2019-04-03T12:14:50.202Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:14:55
2019-04-03T12:14:55.203Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:00
2019-04-03T12:15:00.204Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:05
2019-04-03T12:15:05.205Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:10
2019-04-03T12:15:10.204Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:15
2019-04-03T12:15:15.205Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:20
2019-04-03T12:15:20.206Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:25
2019-04-03T12:15:25.206Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:30
2019-04-03T12:15:30.208Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:35
2019-04-03T12:15:35.207Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:40
2019-04-03T12:15:40.207Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

12:15:45
2019-04-03T12:15:45.207Z ioredis:redis write command[10.0.31.100:6379]: 0 -> info([])

上面的行来自IoRedis调试信息。它似乎正确连接和验证，但进一步的命令永远挂起，永远不会返回响应（既不成功也不错误）。这可能有什么问题？

---

还使用“redis”打包（而不是“ioredis”）进行测试：

console.log('creating redis client'); // tslint:disable-line
    const redisClient = redis.createClient(redisConfig.url, {
      connect_timeout: 5000,
      enable_offline_queue: false,
      no_ready_check: true,
    });

    redisClient.on('error', err => {
      console.error('redis error', err); // tslint:disable-line
    });

    setInterval(() => {
      console.log('sending redis command'); // tslint:disable-line
      redisClient.info((err, result) => {
        console.log('redis response', { err, result }); // tslint:disable-line
      });
    }, 10000);

同样的问题 - 永远不会调用命令回调：

Answer 1

它是由ElastiCache param“transit_encryption_enabled”引起的。它需要隧道连接到redis。关闭此参数后，一切都按预期工作。

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/in-transit-encryption.html