部署含自定义SPI的Keycloak镜像到Elastic Beanstalk陷入无限循环

1. 端口映射与启动命令不匹配 #

Bitnami官方Keycloak镜像默认监听的是8080端口，而非EB默认检查的5000端口。如果你的多阶段Dockerfile没有明确修改端口映射，也未调整EB的健康检查配置，Nginx会一直尝试连接不存在的5000端口，触发502错误。EB会判定服务未就绪，不断重启容器，形成循环。

检查点：

• 确认Dockerfile中是否通过EXPOSE指定了正确端口，或通过ENTRYPOINT/CMD修改了Keycloak的监听端口
• 查看EB环境的健康检查配置，是否将目标端口改为Keycloak实际监听的8080

2. 自定义SPI加载失败导致启动卡住 #

本地运行正常不代表EB环境下SPI能正常加载：

• EB容器的文件权限可能和本地不同，Bitnami镜像默认以bitnami用户运行，如果复制的SPI JAR包权限为root只读，会导致Keycloak无法读取加载
• SPI依赖的第三方库可能在多阶段构建时被遗漏，比如Gradle编译阶段只复制了SPI本身的JAR，没把依赖的依赖包一同复制到镜像中
• 网络环境差异导致SPI初始化时无法访问依赖服务（比如数据库），进程卡住但未退出

检查点：

• 通过eb logs命令拉取容器内的Keycloak日志，查找SPI加载相关的报错（如类找不到、权限拒绝）
• 检查镜像中SPI文件的权限，确保bitnami用户有读取权限
• 对比本地和EB容器内SPI目录的文件完整性，确认所有依赖JAR都已复制

3. EB健康检查配置不合理 #

Keycloak加载自定义SPI后启动时间会变长，如果EB的健康检查超时时间过短，会在Keycloak完全就绪前判定服务异常，触发重启。另外，EB默认的健康检查路径可能不符合Keycloak的就绪检查规则，导致误判。

检查点：

• 调整EB健康检查的超时时间和重试次数，给Keycloak足够的启动时间
• 将健康检查路径改为Keycloak的官方就绪端点（如/health/ready），确保检查逻辑准确

4. 容器资源不足 #

EB默认实例的CPU/内存配额可能低于本地环境，Keycloak加载SPI时需要更多资源，导致启动缓慢甚至卡住。此时容器进程仍在运行，但服务未就绪，EB会持续重启。

检查点：

• 查看EB实例的监控数据，确认CPU、内存使用率是否超标
• 升级EB实例规格，或修改Keycloak的JVM参数（如JAVA_OPTS="-Xmx512m"）降低内存占用

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